SDJ_09_2008_PL_Bazy danych

09/20082

Bazy danych

4 09/2008 5www.sdjournal.org

Le périodique hakin9 est publié par Software-Wydawnictwo Sp. z o.o.Bokserska, 02-682 Varsovie, PologneTél. +48 22 887 10 10, Fax. +48 22 887 10 11www.phpsolmag.org

Directeur de la publication : Jarosław Szumski

Imprimerie, photogravure : 101 Studio, Firma Tęgi Ekonomiczna 30/36, 93-426 ŁódźImprimé en Pologne/Printed in Poland

Abonnement (France métropolitaine, DOM/TOM) : 1 an (soit 6 numéros) 38 €

Dépôt légal : à parutionISSN : 1731-7037Distribution : MLP Parc d’activités de Chesnes, 55 bd de la Noirée BP 59 F - 38291 SAINT-QUENTIN-FALLAVIER CEDEX(c) 2005 Software-Wydawnictwo, tous les droits réservés

PHP Solutions jest wydawany przez Software-Wydawnictwo Sp. z o.o.

Dyrektor wydawniczy: Sylwia Pogroszewska

Redaktor naczelny: Patrycja Wądołowska [email protected]

Redaktorzy prowadzący: Anna Kozioł [email protected] Magdalena Sobiś [email protected]

Projekt okładki: Agnieszka Marchocka

DTP Manager: Robert Zadrożny [email protected]

Kierownik produkcji: Marta Kurpiewska [email protected]

Korekta: Mateusz Lipiński [email protected]óżnieni betatesterzy: P. Bańka, A. Poniedziałek, R.Zacharczyk

Dział reklamy: [email protected]: Marzena Dmowska [email protected]

Nakład: 6 000 egz.

SPIS TREŚCI30 Oracle 11g– platforma przetwarzania danychMichał Jerzy KostrzewaBaza danych Oracle 11g to technologia wspierająca klientów w tworzeniu skalowalnych, bezpiecznych systemów sprawnie do-pasowujących się do zmiennych potrzeb. W oparciu o trzydzieści lat doświadczeń na polu tworzenia niezawodnych baz danych, Oracle 11g umożliwia budowę elastycznej, łatwej w zarządzaniu infrastruktury, jaką będziemy mogli prosto, bezpiecznie i plano-wo dopasować do zmieniających się wymagań.

TESTOWANIE OPROGRAMOWANIA34 Była sobie inspekcjaArkadiusz MertaArkadiusz w pierwszej części artykułu skoncentrował się na wprowadzeniu do zagadnień z dziedziny inspekcji oraz na skon-struowaniu odpowiedniego procesu. Proces ten został oparty na modelu PDAC, który można odnaleźć m.in. w ISO 9001. Podsta-wowymi jego wyróżnikami są elastyczność, skalowalność i uni-wersalność. Choć większość przykładów odnosi się do imple-mentacji oprogramowania, autor pokazuje, że takie same regu-ły dotyczą np. inspekcji dokumentów. W następnym artykule zo-staną zamieszczone uwagi dotyczące sposobów realizacji opisa-nego procesu.

42 Rzeczywisty czas czy rzeczywisty Linux? Racjonalny wybórPaul N. Leroux, Romain SahaAutorzy prezentują że pomimo tego, że system operacyjny QNX Neutrino stanowi doskonałą platformę dla aplikacji czasu rzeczy-wistego, nie ma konieczności dokonywania definitywnego wybo-ru między QNX Neutrino a systemem Linux. Projektanci, którzy korzystają z API standardu POSIX, mogą tworzyć programy dla obu systemów operacyjnych, wykorzystując każdy z nich tam, gdzie jest to najbardziej efektywne.

06 AKTUALNOŚCIRafał Kocisz

12 OPIS CD

BIBLIOTEKA MIESIĄCA14 C5 – nowoczesna biblioteka kolekcji dla .NETMaciej PaczewskiMaciej opisuje C5, czyli nową bibliotekę kolekcji dla .NET stworzoną na Uniwersytecie IT w Kopenhadze. C5 nie tylko jest użyteczną bi-blioteką kolekcji ale również nowym podejściem do wykorzystania kontenerów w .NET. Mimo swojego niewielkiego wieku jest ona wy-korzystywana w przemyśle gier komputerowych, sektorze banko-wym, instytucjach finansowych oraz nawet w US Naval Research.

BAZY DANYCH22 Optymalizacja bazy danychMarek KrokiewiczKażda aplikacja funkcjonuje w ramach ograniczonych zasobów sys-temu, takich jak – pamięć, czas procesora, przepustowość sieci itp. Słaba wydajność SZBD to zwykle problem zużycia dostępnego za-sobu. Należy więc unikać takich sytuacji, uwzględniając możliwe, chwilowe obciążenie systemu dodatkową pracą.

26 Inżynieria baz danychAndrzej DąbrowskiAndrzej przeprowadza analizę narzędzi Embarcadero wskazując jed-noznacznie na to, że producentowi zależy na jak największej wszech-stronności narzędzi. Są one przydatne w firmach, gdzie wykorzystuje się wiele serwerów baz danych oraz dokonuje się migracji pomiędzy różnymi typami platform bazodanowych. Rozwiązania te rewolucjo-nizują sposób pracy z wieloma serwerami, pozwalając użytkownikom na znaczne ograniczenie czasu potrzebnego na wykonanie powierzo-nych im zadań oraz sprawniejsze ich zrealizowanie.

Miesięcznik Software Developer’s Journal (12 numerów w roku)jest wydawany przez Software-Wydawnictwo Sp. z o.o.

Dyrektor wydawniczy: Sylwia Małecka

Redaktor naczelny: Iwona Chwedoruk [email protected]

Kierownik produkcji: Marta Kurpiewska [email protected]

Skład i łamanie: Grzegorz Laskowski

Projekt okładki: Agnieszka Marchocka

Korekta: Piotr Ozaist

Wyróżnieni betatesterzy: Ł. Lechert, S. Nieszwiec, R.Zacharczyk

Nakład: 6 000 egz.

Artykuły pt. „Oracle 11g – platforma przetwarzania danych” oraz „Inżynieria baz danych” są artykułami sponsorowanymi.

Dział reklamy: [email protected]: Marzena Dmowska [email protected], tel. +48 22 427 36 79; +48 22 427 36 53

Adres korespondencyjny:Software-Wydawnictwo Sp. z o.o., ul. Bokserska 1, 02-682 Warszawa, Polskatel. +48 22 427 36 91, fax +48 22 244 24 59www.sdjournal.org [email protected]

Dołączoną do magazynu płytę CD przetestowano programem AntiVirenKit firmy G DATA Software Sp. z o.o.

Redakcja dokłada wszelkich starań, by publikowane w piśmie i na towarzyszących mu nośnikach informacje i programy były poprawne, jednakże nie bierze odpowiedzialności za efekty wykorzystania ich; nie gwarantuje także poprawnego działania programów shareware, freeware i public domain.

09/2008 (165)

4 09/2008 5www.sdjournal.org

PROGRAMOWANIE JAVA48 Swing Application Framework – GUI na nowoPiotr KochańskiTechnologia Java Swing, pozwalająca tworzyć graficzny interfejs użytkownika w języku Java, od samego początku swojego istnienia, czyli od ponad 10 lat, była bardzo pechowa. Pierwsze implementa-cje były mało wydajne i uciążliwe w użyciu, kolejne wersje tego in-terfejsu powoli wprowadzały potrzebne ulepszenia, ale nigdy Swing nie stał się czymś lubianym i docenianym.

PROGRAMOWANIE URZĄDZEŃ MOBILNYCH

54 Podstawy tworzenia gier w JMEJacek ZagrodzkiCelem artykułu Jacka jest wprowadzenie w tematykę tworzenia apli-kacji JME, a w szczególności gier. Artykuł podzielony jest na dwie części. Pierwsza ma formę tutoriala z jasno określonymi krokami, które należy wykonać aby otrzymać podstawową aplikację, która może być stosowana jako punkt wyjściowy do tworzenia gier.

66 Programowanie gier dla Symbian OS– szkielet aplikacjiRafał KociszRafał tym tekstem rozpoczyna cykl artykułów traktujących o progra-mowaniu gier dla Symbian OS – jednego z czołowych graczy na ryn-ku mobilnych systemów operacyjnych. Na dzień dzisiejszy, za cał-kiem rozsądną cenę otrzymujemy urządzenie wyposażone w kame-rę o wysokiej rozdzielczości, kolorowy wyświetlacz, dostęp do sze-rokopasmowego internetu, zintegrowany moduł GPS, wysokiej ja-kości odtwarzacz dźwięku stereo, akcelerometr i układ wspomaga-jący renderowanie grafiki 3D w czasie rzeczywistym. No i przy oka-zji – aparat telefoniczny. Ten szalony pęd technologiczny tworzy ogromną, otwartą przestrzeń dla nowych aplikacji, zaś lwią ich część stanowią gry.

WYWIAD76 Wywiad z przedstawicielami firmy Gamelion

Uszkodzone podczas wysyłki płyty wymienia redakcja.

Wszystkie znaki firmowe zawarte w piśmie są własności odpowiednich firm zostały użyte wyłącznie w celach informacyjnych.

Redakcja używa systemu automatycznego składu

Osoby zainteresowane współpracą prosimy o kontakt:[email protected]

Druk: 101studio DTP

Wysokość nakładu obejmuje również dodruki. Redakcja nie udziela pomocy technicznej w instalowaniu i użytkowaniu programów zamieszczonych na płycie CD-ROM dostarczonej razem z pismem.

Sprzedaż aktualnych lub archiwalnych numerów pisma po innej cenie niż wydrukowana na okładce – bez zgody wydawcy – jest działaniem na jego szkodę i skutkuje odpowiedzialnością sądową.

9/2008

Aktualności

6 www.sdjournal.pl

Aktualności

7

Ważna fuzja w świecie mobilnego LinuksaOrganizacje Linux Phone Standard Forum (LiPS) oraz Linux Mobile Foundation (LiMo), zajmujące się na co dzień rozwojem linuk-sowych rozwiązań dla urządzeń mobilnych połączyły siły, bym móc stawić czoła swoim rynkowym konkurentom – platformie Andro-id oraz Symbianowi. Obie wspomniane fun-dacje od początku swojego istnienia praco-wały nad ułatwieniem wprowadzenia syste-mu operacyjnego Linux do urządzeń prze-nośnych. LiPS zajmowała się opracowaniem API, które umożliwiłoby rozwój oprogramo-wania dedykowanego dla mobilnych rozwią-zań. Z kolei LiMo skupiało się nad stworze-niem platformy, która umożliwiłaby progra-mistom łatwe kreowanie oprogramowania dla smartphone'ów. Teraz natomiast człon-kowie LiPS wraz z realizowanymi przez siebie projektami trafią do LiMo, które na chwilę obecną jest największą organizacją zajmu-jącą się rozwojem mobilnych wersji platfor-my Linux. Obserwując ostatnie poczynania na rynku urządzeń przenośnych, fuzja orga-nizacji LiPS oraz LiMo ma jak największy sens. Z jednej strony zmniejszy się ilość przedsię-wzięć, których głównym celem jest tworze-nie konkurencyjnych rozwiązań, a z drugiej umożliwi opracowanie innowacyjnych tech-nologii, które będą w stanie rywalizować na rynku z oprogramowaniem komercyjnym.http://www.limofoundation.org/

Microsoft wyróżnia polskie firmyLaureatami tegorocznego konkursu Micro-soft Partner Program Awards w regio-nie Europy Środkowo-Wschodniej zostały cztery polskie firmy. W tym roku jury kon-kursu doceniło krakowski Axence za opro-gramowanie do zarządzania siecią nVision, krakowski Comarch za system klasy ERP do zarządzania przedsiębiorstwem Comarch ALTUM, warszawską firmę DCS Computer Consultants Group za aplikację Orange E-mail Box, zaimplementowaną u operatora Orange oraz wrocławski IT-Dev za rozwiąza-nie IT-Dev SharePoint DSL ToolKit for Visual Studio. Ciekawostką jest, że jedno z rozwią-zań – Comarch ALTUM – w chwili obecnej nie jest jeszcze w ogóle oferowane w Polsce. System ten powstał z myślą o rynkach zagra-nicznych – przede wszystkim Niemczech, Ukrainie, Włoszech, Stanach Zjednoczo-nych oraz Wielkiej Brytanii. Wersja dostoso-wana do polskich wymagań ma pojawić się w 2009 roku pod nazwą CDN Altum. Micro-soft Partner Program Awards to konkurs w którym wyróżniane są firmy oferujące innowacyjne rozwiązania przygotowane na bazie narzędzi i rozwiązań firmy Microsoft. Zwycięzcy i finaliści konkursu zostali oficjal-nie nagrodzeni podczas Microsoft Worldwi-de Partner Conference 2008 – ogólnoświa-towej konferencji dla partnerów firmy, która odbyła się w tym roku w Houston, w dniach 7-10 lipca. Warto dodać, że w ubiegłorocz-nej edycji konkursu Microsoft Partner Pro-gram Awards nie została nagrodzona żadna firma z Polski.http://dobreprogramy.pl

Microsoft przejmuje firmy

Po porażce w negocjacjach mających na celu zakup Yahoo!, zarząd Microso-ftu nie spoczął na przysłowiowych lau-

rach i szykuje się do kolejnych zakupów. W jednym z wywiadów przedstawiciele Micro-softu poinformowali o planach koncernu, do-tyczących nabycia portugalskiej firmy Mobi-Camp. Firma MobiCamp została założona w roku 2000 w Bradze w Portugalii, specjalizuje się w dostarczaniu rozwiązań dla rynku urzą-dzeń mobilnych. Opracowała i ciągle rozwija oprogramowanie MobileKeeper Backup & Re-store, MobileKeeper Sharing & Communities i Active mTicker, które używane jest przez du-że przedsiębiorstwa do tworzenia kopii zapaso-wych danych zgromadzonych na smartfonach, publikacji ich zawartości w serwisach społecz-nościowych, jak np. Facebook itp. Microsoft wraz z przejęciem MobiCamp wiąże duże na-dzieje na polepszenie jakości i funkcjonalno-ści swoich produktów oraz usług, świadczą o tym słowa Todda Petersa, wiceprezesa działu Mobile Communications Business w Micro-sofcie – „Użytkownicy oczekują od swoich te-lefonów, by te dostarczały im najlepsze funk-cjonalności znane z komputerów stacjonar-nych oraz dawały możliwość surfowania w In-ternecie”. Peters dodał także, iż Microsoft in-westując we właściwe rozwiązania takich firm jak np. MobiCamp zwiększy potencjał produk-

tów Windows Mobile i Windows Live w dostar-czaniu innowacyjnych i bezprzewodowych spo-sobów na stałą łączność. Na chwilę obecną nie są znane szczegóły dotyczące terminu i warun-ków ewentualnego przejęcia portugalskiej kor-poracji, wiadomo natomiast, iż po przejęciu zo-stanie ona częścią microsoftowego działu Mo-bile Communications Business i wesprze pra-ce nad rozwiązaniami dla platformy Windows Mobile oraz usługami sieciowymi Windows Li-ve. Microsoft zamierza również kupić firmę Po-werset specjalizującą się w mechanizmach wy-szukiwawczych wykorzystujących zapytania se-mantyczne, oparte na języku naturalnym. Fir-ma ma zostać przejęta za co najmniej 100 mi-lionów dolarów. Oficjalne ogłoszenie pojawi się w ciągu miesiąca. Na razie ani Microsoft ani Po-werset nie chcą komentować transakcji. Czemu mają służyć te wszystkie zakupy? Tego do koń-ca nie wie zapewne nikt, poza kluczowymi pra-cownikami korporacji z Redmond. Faktem jest jednak to, że Microsoft ciągle nie potrafi stwo-rzyć wyszukiwarki, która byłaby konkurencją dla Google. Nie pomagają zapewnienia Ballme-ra, że programiści Live Search są tylko o krok od sukcesu. Konieczne są więc zakupy. Ponieważ nie wyszło z Yahoo!, Microsoft musi rozglądać się za innymi firmami. Być może nowe nabytki okażą się tym, czego w Redmond brakowało.http://news.zdnet.co.uk/

MSN.pl oficjalnie uruchomiony

Po kilku miesiącach testów Microsoft oficjalnie uruchomił polską wersję por-talu MSN. Jest to 21 wersja językowa

portalu utrzymywana przez Microsoft. Wielu rodzimych użytkowników czekało na nią od dawna, zwłaszcza biorąc pod uwagę fakt, że dotąd brakowało obecnej za granicą integracji usług Windows Live z witryną MSN. Co znaj-dziemy w portalu MSN.pl? Serwis stawia na informację i rozrywkę. Najnowsze wiadomo-ści z kraju i ze świata dostarczać będzie Agora, wydawca Gazety Wyborczej. Część rozrywko-wa i zawartość multimedialna tworzona bę-dzie z pomocą Sony BMG, MTV i Starlounge. Na razie portal jest dość ubogi w treść i póki co sporą powierzchnię zajmują reklamy (głów-nie usług Microsoftu) – firma zapowiada jed-nak, że zawartość będzie stale poszerzana. W ramach jedynej premierowej atrakcji urucho-miono 1 lipca konkursu na najlepszy mini klip wideo. Do wygrania była konsola Xbox 360. Na świecie z różnych wersji językowych MSN korzysta miesięcznie ponad 465 milio-nów unikalnych użytkowników. Polska wer-

sja MSN jest pierwszym samodzielnym porta-lem z rodziny MSN w Europie Środkowej, fir-ma podchodzi więc do niej na razie ostrożnie. Michał Kostrzewa, kierownik działu produk-tów MSN w polskim oddziale Microsoft, wy-powiedział się, iż wierzę, że portal MSN znaj-dzie swoje miejsce na rynku, a jego popular-ność pozwoli korporacji z Redmond dołączyć w perspektywie kilku lat do czołówki polskie-go rynku internetowego – powiedział. Warto przypomnieć, że pod koniec ubiegłego roku uruchomiony został inny portal przeniesio-ny z amerykańskiego rynku – AOL.pl. Mimo upływu miesięcy nie zdobył on jednak więk-szej oglądalności i jak na razie nic nie wskazu-je aby miało się to zmienić. Podobnie stało się zresztą z serwisem aukcyjnym eBay.pl, który po szumnych zapowiedziach dogorywa. Czy z MSN.pl będzie inaczej? Na pewno Micro-soft, za sprawą ugruntowanej pozycji na pol-skim rynku, ma dużo szersze możliwości pro-mocji swojego portalu. Czy to wystarczy – po-każe czas.http://www.microsoft.com/poland

9/2008

Aktualności

6 www.sdjournal.pl

Aktualności

7

Chiny blokują SourceForge.netNiedługo od zniesienia przez chińskie władze blokady na anglojęzyczną wersję internetowej encyklopedii Wikipedia, chińscy decydenci zdecydowali się dla odmiany zablokować dostęp do stron projektu SourceForge. Decyzja chińskich władz może bezpośrednio odnosić się do niedawnych protestów przeciw letnim Igrzyskom Olimpijskim rozgrywanym w Pekinie, stolicy Chin. Kilka dni wcześniej autor popularnego edytora dla programi-stów Notepad++, dostępnego na łamach SourceForge.net rozpoczął bojkot Pekinu, tłumacząc, iż nie kieruje on swojego sprze-ciwu przeciwko ludziom w Chinach, a rzą-dowi chińskiemu. Bojkot dotyczy sytuacji politycznej w Chinach, ale odnosi się także do tamtejszego problemu praw człowie-ka. Władze chińskie regularnie bloku-ją dostęp do stron, poruszających wrażli-we tematy polityczne Chin, ale czy sprze-ciw twórcy jednej z aplikacji dostępnej na łamach strony SourceForge jest powodem do całkowitej blokady dostępu do tegoż projektu?http://www.moon-blog.com/

Google pozwane na prawie miliard dolarówFirma LimitNone oskarżyła Google o kra-dzież jej pomysłów i zażądała 950 milio-nów dolarów odszkodowania. LimitNone uważa, że Google bezprawnie wykorzysta-ło w swojej aplikacji Google Email Uplo-ader rozwiązania z jej programu gMove. Program ten służył do migracji poczty i kalendarza. Ray Glassmann, szef Limit-None, uważa, że choć dewizą Google jest aby nie być złym, Google zaprosiło Limit-None do współpracy, a potem ukradło jej technologię. Podkreśla, iż pomimo tego, że jego firma jest mała to jej działalność powodowała wzrost sprzedaży produk-tów Google.http://betanews.com/

Google zaprzecza opóźnieniu AndroidaZa sprawą publikacji The Wall Street Jour-nal, świat opanowała informacja o rzeko-mym opóźnieniu premiery nowego sys-temu Google dla urządzeń mobilnych – Android. Powodem takie stanu rzeczy miały być problemy po stronie operatorów T-Mobile i Sprint Nextel. Android na rynku miał być więc tak naprawdę widoczny dopiero w 2009 roku. Google po raz kolej-ny oficjalnie zaprzecza takim informacjom. Firma stanowczo stwierdza, że pierwsze urządzenia mobilne z systemem Android na pokładzie zadebiutują jeszcze w drugiej połowie tego roku. Google zaznacza rów-nież, że obserwuje duże zainteresowanie Androidem ze strony producentów sprzę-tu. Taki obraz sytuacji wydaje się potwier-dzać słowa Kevina Chena z HTC, który kilka dni temu zapowiedział premierę pierwsze-go smartfonu HTC z systemem Android na koniec 2008 roku.http://betanews.com/

Fiji nie na sprzedaż

Nazwa kodowa „Fiji” w kontekście produktów Microsoftu funkcjonuje już od dosyć dawna. Odkąd świat o

niej usłyszał, nie słabną spekulacje na temat te-go, co też firma z Redmond przygotowuje pod tym kryptonimem. Do tej pory udało się usta-lić, że będzie to najprawdopodobniej coś zwią-zanego z Media Center, ale korporacja nie-chętnie chwaliła się swoją pracą. Niezależnie od tego, całą sprawą najwyraźniej bardzo prze-jął się rząd Fiji, który poprzez swoich prawni-ków wystosował oficjalne i bardzo stanowcze pismo, w którym oświadcza, że nie zgadza się na jakiekolwiek wykorzystanie nazwy kraju do celów marketingowych, a w razie koniecz-ności jest przygotowany do obrony swoich praw. Na list natychmiast odpowiedział Ben Green z działu Windows Client firmy Micro-soft, przy okazji – chcąc, nie chcąc – ujawnia-jąc rąbka tajemnicy na temat nowego produk-tu. Zapewnił on, że Fiji to po prostu nazwa ko-dowa aktualizacji do Windows Media Center,

która będzie dodawać obsługę nowych stan-dardów telewizyjnych, zapewni nowe inte-raktywne funkcje oraz ulepszy interfejs użyt-kownika i proces instalacji Media Center. Jak nietrudno się domyślić, Green poinformował też, że ostateczna nazwa produktu będzie zu-pełnie inna, niż kryptonim obowiązujący w fazie beta. Zachowanie rządu Fiji może wyda-wać się nieco dziwne – Microsoft, jak i wie-le innych firm na świecie wykorzystuje rozma-ite nazwy kodowe dla swoich projektów. Przy-kładowo, Whistler (później Windows XP) to szczyt w Kanadzie, a Longhorn (Windows Vi-sta) to bar położony u podnóża gór Whistler i Blackcomb (początkowo następca Visty, póź-niej nazwę porzucono). Nazwy wysp, pasm górskich czy nawet miast np. Windows Vien-na) są więc często używane. Pytanie – gdzie leży granica? Widocznie w oczach urzędni-ków Fiji została ona przekroczona. Właściciele Longhorn Saloon byli innego zdania.http://news.zdnet.co.uk/

Hyper-V oficjalnie wydany

Microsoft opublikował w centrum prasowym oficjalną informację, że platforma wirtualizacyjna Hy-

per-V została skierowana do produkcji. W be-ta testach aktywnie brało udział ponad 250 firm partnerskich Microsoftu, a także wiele innych – na własną rękę. Łącznie wersję be-ta pobrano półtora miliona razy. Hyper-V to platforma wirtualizacyjna o architekturze ty-pu 1 (hypervisor) i rozmiarze około 1 MB, za-rządzająca systemami wirtualnymi w party-cjach, gdzie na partycji podstawowej pracu-je system Windows Server 2008 (w wersji pełnej lub Server Core). Obsługuje systemy wirtualne 32- i 64-bitowe, do 4 wirtualnych procesorów i do 64 GB pamięci RAM na sys-tem. Oficjalnie jako systemy wirtualne wspie-rane są Windows 2000/2003/2008, Win-dows XP/Vista oraz Novell SUSE Enterpri-se Linux. Hyper-V posiada dodatkowo funk-cję szybkiej migracji maszyn wirtualnych po-między fizycznymi serwerami (choć wyma-ga to niestety wcześniejszego ich wstrzyma-nia – migracja na żywo, podobnie jak możli-wość modyfikowania parametrów fizycznych maszyny w trakcie pracy zostały wycięte z fi-nalnego produktu ponad rok temu). W usłu-dze Windows Update dla systemów Windows Server 2008 w wersjach 64-bitowych z licen-cją na Hyper-V nowy produkt pojawi się w postaci aktualizacji w okolicach 8 lipca. Sze-reg producentów sprzętu zapowiedziało tak-

że wprowadzenie do sprzedaży zintegrowa-nych serwerów, już zawierających wbudowa-ny Hyper-V. Są wśród nich HP, Dell, IBM, Fu-jitsu, Hitachi, NEC oraz Unisys. Cena Hy-per-V w takiej konfiguracji będzie wynosić 28 dolarów. Kupując natomiast licencję na Win-dows Server 2008 zawierającą Hyper-V otrzy-muje się dodatkowe licencje na systemy wir-tualne pracujące w ramach pierwszej, fizycz-nej instancji – jedną w przypadku edycji Stan-dard, cztery dla edycji Enterprise i nieograni-czoną ilość dla edycji Datacenter. Te dodatko-we licencje nie ograniczają jednak użytkowni-ka do platformy Hyper-V.http://www.techit.pl/

9/2008

Aktualności

8 www.sdjournal.pl

Aktualności

9

Linuksowe repozytorium firm i specjalistówStowarzyszenie Linux Profesjonalny urucho-miło pierwsze w Polsce repozytorium osób i firm specjalizujących się w zagadnieniach związanych z systemem Linux. Serwis http://www.linuxpro.org.pl rozpoczął swoją działal-ność i w pierwszym etapie zaprasza do reje-stracji osoby bądź firmy, które mogą pomóc we wdrożeniu Linuksa w domu lub firmie. Linuksowe repozytorium firm i specjalistów to serwis internetowy, który powstał w celu ułatwienia komunikacji pomiędzy osoba-mi i firmami specjalizującymi się w zagad-nieniach dotyczących systemu Linux, a ich potencjalnymi klientami z pobliskiego miasta czy regionu. Podstawą serwisu jest baza kon-taktów do firm i osób prywatnych, które spe-cjalizują się w dziedzinie Wolnego Oprogra-mowania. Korzystając z wyszukiwarki na stro-nie można będzie znaleźć fachowca, który nie tylko wdroży Linuksa w domu czy firmie, ale także w razie potrzeby zajmie się administra-cją serwerami i zadba o ich bezpieczeństwo. Jeżeli nie znajdzie się specjalisty spełniające-go określone wymagania, można wówczas zamieścić ogłoszenie, które ukaże się na stro-nie i w kanałach RSS. Firmy oraz osoby pry-watne zajmujące się Wolnym Oprogramowa-niem i zainteresowane obecnością w serwisie mogą się rejestrować na specjalnej podstro-nie: http://www.linuxpro.org.pl/rejestracja.http://www.linuxpro.org.pl/o-stowarzyszeniu

Red Hat pracuje nad linuksowym hypervisoremRed Hat ogłosił, że pracuje nad wbudowanym linuksowym hypervisorem, który według pro-ducenta ma być uzupełnieniem, a nie konku-rencją dla istniejącego już rozwiązania Xen. Aktualnie Embedded LInux Hypervisor znaj-duje się w fazie beta i nie ma jeszcze informa-cji co do planowanego terminu ukończenia prac i metody dystrybucji. To będzie pierwszy linuksowy hypervisor open-source – mówił Paul Cormier, jeden z szefów działów Red Hat. To system operacyjny następnej generacji – dodaje tłumacząc, że mówiąc o wirtualizacji i systemach operacyjnych powinno się myśleć o nich jak o całości. Fundamentem nowego hypervisora będzie projekt Kernel-based Vir-tual Machine, już zintegrowany z jądrem Linuksa od 2006 roku. KVM umożliwia m.in. migrację wirtualnych maszyn on-line i oferu-je rozbudowane funkcje wysokiej dostępno-ści. Wysiłek Red Hata w dziedzinie wirtualizacji skupiony był jak dotąd na projekcie Xen. Teraz jest to produkt Citrixa. Na pytanie, czy podję-cie prac nad nowym hypervisorem oznacza, że firma widzi dla siebie mizerne perspektywy w technologii Xen, Red Hat wymijająco odpo-wiada, że chciałby udostępnić klientom obie platformy i wybór najlepszego dla nich roz-wiązania. Niejasny jest też sposób dystrybucji hypervisora – być może będzie zintegrowany z Red Hat Enterprise Linux (tak jak w tej chwili w wersji 5 zintegrowano Xen). Póki co wersję beta Embedded Linux Hypervisor można pobrać z witryny oVirt (http://ovirt.org/).http://www.techit.pl/

Korporacje – „nie” dla Visty!

Firmy Intel oraz General Motors dołączyły do grona korporacji, które rezygnują z cał-kowitej migracji na platformę Windows

Vista. Takie informacje podał do wiadomości dziennik New York Times powołując się na rze-komo sprawdzonych informatorów. Decyzja ta podjęta została po analizie kosztów i korzyści mi-gracji do najnowszego systemu operacyjnego Mi-crosoftu, który swoją premierę miał już 18 mie-sięcy temu. Zarząd Intela planuje wstrzymać się z migracją do momentu wydania środowiska Win-dows 7, czyli do roku 2010. Pomimo tego, iż fir-ma Intel korzysta z Visty w swoich pojedynczych oddziałach, to całkowita aktualizacja wszystkich stanowisk komputerowych do tego systemu ope-racyjnego nie wchodzi na chwilę obecną w grę i około 80 tys. pracowników nadal korzystać będą na swoich komputerach z Windowsa XP. Z ba-dań przeprowadzonych przez analityków rynko-wych wynika, iż około 30 procent klientów biz-nesowych decyduje się na „przeskoczenie” któ-rejś z edycji systemu Windows. Zdaniem Mi-chaela Silvera, analityka z firmy Gartner, w przy-padku Visty takich właśnie przedsiębiorstw bę-dzie o wiele więcej. Jedną z głównych przyczyn braku zainteresowania Vistą przez duże firmy jest fakt, iż system ten posiada duże wymagania sprzętowe, co w dzisiejszych realiach wiąże się z gigantycznymi wydatkami, które przecież mogą zostać dużo lepiej zaplanowane. Do grona kor-poracji, które najnowszemu systemowi Micro-softu mówią stanowcze „nie” dołączyła firma Da-imler. Nie byłoby w tym fakcie nic niezwykłego, gdyby oprócz rezygnacji z Visty nie pojawiła się

także informacja o rezygnacji z migracji do pa-kietu biurowego Microsoft Office 2007. Warto przypomnieć, że w gronie przedsiębiorstw, które nie przeprowadzą migracji do Windows Vista, a wstrzymają się do wydania jego następcy znaleźć można m.in. firmy Intel i General Motors. Przed-stawiciele korporacji Daimler oznajmili, iż firma nie zamierza rozpoczynać migracji do Visty, a za-trzyma się z aktualizacją środowiska operacyjne-go na stanowiskach komputerowych do momen-tu wydania Windowsa 7, czyli do roku 2010. Po-dobne stanowisko przyjął motoryzacyjny poten-tat w sprawie „przeskoczenia” pakietu Office 2007 i wstrzymania się z migracją do wydania kolejnej wersji. Pomimo tych deklaracji przed-stawiciele Daimler zapewnili, że na chwilę obec-ną nie rozważają opcji zmiany dostawcy oprogra-mowania i usług.http://www.nytimes.com/http://www.heise.de/

Eclipse 3.4

Ukazała się nowa wersja popularne-go darmowego środowiska programi-stycznego Eclipse, które zgodnie z tra-

dycją otrzymało nazwę kolejnego księżyca Jowi-sza – Ganymede. Aktualizacja powiązana jest z wydaniem pakietów od 23 zespołów zrzeszo-nych w projekcie Eclipse. Projekt Eclipse powstał w roku 2001 z inicjatywy firmy IBM, aktualnie

składa się on z siedmiu różnych pakietów opro-gramowania, które zostały przystosowane do zastosowań na szeroką skalę. Wśród nich zna-lazły się m.in. Eclipse IDE for Java EE Develo-pers, Eclipse Classic, Eclipse IDE for Java Deve-lopers, Eclipse IDE for C/C++ Developers, Eclip-se Modeling Tools, Eclipse for RCP/Plug-in De-velopers oraz nowy pakiet Eclipse IDE for Java and Report Developers. Z racji tego, iż platforma jest bardzo elastyczna, każdy użytkownik za po-średnictwem systemu wtyczek może ją niemal dowolnie dostosować do swoich potrzeb. Obec-nie obsługuje ona następujące języki programo-wania – Java, C/C ++, Perl, PHP, Python, Cobol oraz HTML. W nowej odsłonie Eclipse wprowa-dzono cały szereg usprawnień mających na celu ułatwienie pracy i zwiększenie produktywności programistów. Opis wspomnianych usprawnień znaleźć można na witrynie projektu.http://www.eclipse.org/

9/2008

Aktualności

8 www.sdjournal.pl

Aktualności

9

Java wolna w 100% Proces otwierania Javy trwa od ponad dwóch lat. W jego efekcie Java zosta-ła wydana na licencji GPL. Pozostało jednak około 5% kodu, które nie zosta-ło uwolnione. Free Software Founda-tion nazwała to pułapką Javy. W celu jej ominięcia powstał projekt IcedTea. Pro-jekt ten bazuje na GNU Classpath i ma na celu stworzenie wolnej implementa-cji własnościowego fragmentu Javy w OpenJDK. Najnowsza wersja OpenJDK zawarta w linuksowej dystrybucji Fedora 9 spełniła rygorystyczne wymogi Java Test Compatibility Kit (TCK). Oznacza to, że dostarcza wszystkie wymagane API Javy i działa dokładnie tak jak inne imple-mentacje Javy SE 6. Java TCK jest wszech-stronnym testem, mającym ponad milion linii kodu, który sprawdza czy dana implementacja Javy jest zgodna ze spe-cyfikacją. W tej chwili wymogi Java TCK spełnia tylko Fedora 9, ale można się spo-dziewać, że jej śladami pójdą też inne sys-temy Linuksowe.http://www.osnews.com/

Microsoft znów Najlepszym PracodawcąMicrosoft zdobył tytuł Najlepszego Pra-codawcy w Europie Środkowo-Wschod-niej, w corocznym rankingu przeprowa-dzonym wśród ponad 500 firm z dwuna-stu krajów naszego regionu. Firma zosta-ła uhonorowana tytułem po raz trzeci z rzędu. W tegorocznej edycji rankingu Microsoft znalazł się na czołowych miej-scach w siedmiu krajach – w tym w Polsce. Wyniki opracowano na podstawie kwe-stionariuszy wypełnionych przez niemal 120 tys. pracowników oraz 3 tys. przed-stawicieli najwyższej kadry menedżerskiej z firm z całego regionu. Ocenie podlega-ło zaangażowanie osób zatrudnionych w firmie oraz stosowane praktyki w zakre-sie zarządzania zasobami ludzkimi. Bada-nie przeprowadziła firma doradztwa stra-tegicznego – Hewitt Associates. Najlep-szy Pracodawca jest konkursem, w którym pracodawcę oceniają jego pracownicy. Od innych tego typu inicjatyw konkurs Najlepszy Pracodawca wyróżnia metodo-logia, bazująca na audycie stosowanych w organizacji systemów, programów i prak-tyk z zakresu zarządzania zasobami ludz-kimi, analizie zaangażowania pracowni-ków oraz ocenie roli funkcji personalnej z perspektywy najwyższej kadry menedżer-skiej. W naszym regionie udział w badaniu wzięło udział 591 firm z dwunastu krajów: Austrii, Bułgarii, Chorwacji, Czech, Węgier, Słowacji, Słowenii, Turcji, Polski, Rumunii, Rosji i Ukrainy. Konkurs na Najlepszego Pracodawcę jest przeprowadzany przez Hewitt Associates w kilkudziesięciu kra-jach na całym świecie. Pierwsza edycja miała miejsce w Stanach Zjednoczonych w 1994 r. http://www.microsoft.com/poland

Nokia otworzy Symbiana

Najwięksi światowi producenci tele-fonów komórkowych, w tym Nokia, Sony Ericsson, Motorola i NTT DO-

COMO poinformowali o planach połączenia Symbiana, UIQ oraz MOAP(S), w celu utwo-rzenia jednej otwartej platformy. Nokia za-mierza przejąć wybrane części Symbian Limi-ted nie będące jeszcze w posiadaniu przez niko-go, a następnie przekazać Symbiana i S60 nowo powstałej Fundacji. Tym samym, otwarcie Sym-biana przez Nokię wydaje się ciosem skierowa-nym w stronę Androida, nowego systemu pro-dukcji Google dla urządzeń mobilnych. Acz-kolwiek już teraz, także użytkownicy mobil-

ni mają możliwość wyboru pomiędzy różny-mi platformami. Poza samą Nokią, Fundację planują wesprzeć również takie firmy jak Sony Ericsson, Motorola, LG Electronics, Samsung Electronics i STMicroelectronics oraz najwięk-si światowi giganci telekomunikacyjni – NTT DoCoMo, AT&T Texas Instruments, czy też Vodafone. Fundacja ma zacząć pracować tuż po całkowitym przejęciu Symbiana przez No-kię, czyli w pierwszej połowie 2009 roku. Ser-wis Slashdot podaje, że kod Symbiana ma być dostępny na wolnej licencji Eclipse Public Li-cense (EPL) 1.0.http://osnews.pl/

List Microsoftu do klientów Windows – co dalej?

Ponad miliard komputerów na świe-cie pracuje dzisiaj pod kontrolą syste-mu Windows – za to Microsoft dzię-

kuje swoim klientom na początku listu otwar-tego, jaki Bill Veghte, Senior Vice President wystosował do użytkowników swojego flago-wego produktu. Zbliżając się do znaczącej da-ty 30 czerwca 2008, kiedy zakończona zosta-nie sprzedaż detaliczna i dystrybucja do part-nerów OEM systemu Windows XP, Microsoft informuje o skutkach tej decyzji oraz planach na najbliższe lata. Zakończenie sprzedaży Win-dows XP przypada na 30 czerwca. Po tym ter-minie Microsoft przestanie dostarczać partne-rom paczki z systemem, podobnie zamknięty zostanie kanał sprzedaży OEM. Firma przypo-mina jednak, że takie rozwiązanie nie zamyka drogi do użytkowania Windows XP na nowych komputerach – wystarczy zakupić Windows Vista w edycjach Business lub Ultimate, które posiadają prawo do downgrade'u do Windows XP Professional. Sprzedaż Windows XP Ho-me i Starter będzie też kontynuowana wraz ze

specjalnymi, niskobudżetowymi notebookami. Co ze wsparciem technicznym i aktualizacjami zabezpieczeń? Również tutaj nic się nie zmie-ni. Jeszcze ponad rok temu Microsoft wydłu-żył okres wsparcia technicznego do 2014 ro-ku. Przez blisko sześć następnych lat Windows XP pozostanie więc bezpieczny. Microsoft w li-ście dzieli się też informacjami na temat Win-dows Vista. Firma chwali się, że system obsłu-guje już ponad 77 tysięcy urządzeń i 98 z listy Top 100 aplikacji na świecie. Filtr antyphishin-gowy Internet Explorera blokuje natomiast po-nad milion szkodliwych stron tygodniowo. Vi-sta to jednak nie wszystko. Microsoft zapowia-da wydanie kolejnego systemu z rodziny Win-dows – na razie oznaczonego kodowo jako „7”. W liście oficjalnie podano, że jego premiery na-leży oczekiwać około trzy lata po premierze Windows Vista. Termin ten przypada zatem na styczeń 2010. Nowy system będzie zbudowany na fundamentach Windows Vista – nie będzie żadnych spektakularnych zmian w jądrze.http://www.microsoft.com/poland

9/2008

Aktualności

10 www.sdjournal.pl

Aktualności

11

92% programistów ignoruje VistęWedług badania Evans Data (http://www.evansdata.com/) zaledwie 8% pro-gramistów tworzyło aplikacje dla systemu Windows Vista w kwietniu. Dla porówna-nia dla XP pisze około 49% programistów. Vista jest wśród programistów mniej popu-larna od GNU/Linuksa. Oprogramowanie na ten system tworzy 9%-11% programistów. Większym powodzeniem od Visty cieszy się też Windows Server 2003, który osiągnął wynik 11%. Przewiduje się, że w przyszłym roku popularność Visty wzrośnie do pozio-mu 24% i zbliży się do wyniku Windows XP: 29%. Udział Linuksa ma wzrosnąć do 15%. Ze względu na szereg krytycznych opinii o najnowszym klienckim systemie operacyj-nym Microsoftu wielu programistów przy-jęło postawę wyczekującą. Niektórzy z nich chcą nawet przeczekać Vistę i zacząć pisać pod Windows 7. Innym czynnikiem odstra-szającym autorów oprogramowania jest fakt, że pisanie dla Visty jest trudniejsze. Jest to spowodowane mechanizmami zabezpiecza-jącymi, a także mniejszą kompatybilnością.http://www.cnet.com/

Opera nawiązuje współpracę z AllegroFirma Opera Software, producent jednej z najpopularniejszych przeglądarek interneto-wych, poinformowała tuż po premierze naj-nowszej wersji swojego produktu o nawiąza-niu współpracy z największym polskim ser-wisem aukcyjnym – Allegro.pl. Efektem tej współpracy ma być promowanie polskiego serwisu aukcyjnego za pośrednictwem naj-nowszej wersji Opery 9.5 oraz Opery Mini 4.1. Na karcie szybkiego wyboru domyślnie pojawi się wpis dotyczący Allegro, ponad-to mechanizm wyszukiwania wbudowany w przeglądarkę obsługiwał będzie przeszukiwa-nie stron serwisu aukcyjnego autorstwa QXL Poland. Jon von Tetzchner, szef Opera Softwa-re, tłumaczy, iż Polska to dla jego firmy ważny rynek, dlatego zdecydowała się ona na doda-nie usługi Allegro do najnowszej wersji Opery.http://opera.com/

IBM otworzy kod DB2?Całkiem możliwe, że za jakiś czas IBM wyda swój serwer bazodanowy DB2 na licencji open-source. Chris Livesey, dyrektor ds. opro-gramowania do zarządzania informacją w brytyjskim oddziale IBM zaznacza, że w naj-bliższej przyszłości nie ma co do tego kon-kretnych planów, ale już wkrótce takie posu-nięcie może wymusić sam rynek. Już teraz IBM udostępnia bezpłatną, oferującą pod-stawową funkcjonalność edycję DB2 Express. Livesey wspomina, że firma zawsze starała się wspierać open-source, a nawet aspirowała do bycia liderem na tym rynku. Otwarcie kodu DB2 wydaje się naturalnym posunięciem i IBM z pewnością to rozważy. Priorytetem dla IBM w dalszym rozwoju DB2 jest ścisła inte-gracja silnika baz danych z narzędziami Busi-ness Intelligence. W drugiej kolejności firma planuje wprowadzenie nowej technolo-gii kompresji danych oraz kolejne funkcje w zakresie bezpieczeństwa i ochrony danych.http://www.cnet.com/

Firefox 3

Stało się! Miesiąc po wydaniu pierwszej wersji kandydującej światło dzienne oficjalnie ujrzała stabilna wersja prze-

glądarki Firefox 3. Nowy Ognisty Lisek w po-równaniu do wersji 2.0.0.14 wnosi całkiem sporo nowości. Pierwsze co rzuca się w oczy to odświeżony interfejs, integrujący się z wy-glądem używanego systemu i nowa domyśl-na skórka. Prócz tego rozwinięto mechanizm ochrony przed różnego rodzaju złośliwym oprogramowaniem, zwiększono integrację z zainstalowanymi programami zabezpieczają-cymi oraz dodano wsparcie dla certyfikatów Extended Validation SSL i modułu kontroli rodzicielskiej systemu Windows Vista. Prze-pisano także zupełnie od nowa mechanizm odpowiedzialny za zarządzanie pamięcią, dzięki czemu nowy Firefox nie pobiera tak dużo pamięci RAM jak swój poprzednik. Do-datkowo w „trójce” znajdziemy usprawnio-nego menadżera przechowywania haseł, ob-sługę wznawiania pobierania plików i pełny zoom. Wiele zmian zostało wprowadzonych w silniku aplikacji. Wśród nich znaleźć moż-na nową architekturę wyświetlania czcionek i grafik, obsługę JavaScript 1.8, kilka zmian w sposobie renderowania HTML, styli CSS i grafik SVG, menadżera profili kolorów i wsparcie dla aplikacji uruchamianych w try-bie offline. Dodano również możliwość przy-stosowania lokalizacji i wielkości panelu wy-szukiwania, instalacji rozszerzeń bezpośred-nio z poziomu menadżera dodatków, a tak-że nowe strony błędów SSL z czytelniejszy-mi informacjami. Przy okazji premiery trze-

ciej odsłony Ognistego Liska nie da się po-minąć planowanej przez Mozillę próby usta-nowienia nowego rekordu Guinnessa w licz-bie pobrań aplikacji w ciągu 24 godzin. Z tej właśnie okazji, dzień wydania trzeciej odsło-ny Firefox'a nazwany został „Dniem Pobiera-nia” (ang. Download Day). Już od przeszło paru tygodni przed wypuszczeniem „trój-ki”, korporacja przekonywała członków swo-jej globalnej społeczności do rozpowszech-niania informacji i włączenia się do akcji, po-przez organizowanie specjalnych imprez, czy też umieszczania na swoich stronach interne-towych przycisków promujących akcję. Jed-ną z form było również składanie deklara-cji online, na czele listy których, pod wzglę-dem ilości osób, Polska uplasowała się w czo-łówce, tuż obok Stanów Zjednoczonych, Bra-zylii i Włoch. Niestety, wynik ten nie przeło-żyło się na faktyczne wyniki. że Polska uplaso-wała się na 11 miejscu za Stanami Zjednoczo-nymi (3.252.673), Niemcami (852.432), Ja-ponią (533.369), Wielką Brytanią (367.773), Hiszpanią (355.335), Francją (346.319), Li-twą (328.785), Kanadą (294.933), Włocha-mi (291.305) i Iranem (264.804) z wyni-kiem 242.649 pobrań, zaś liczba wszystkich wyniosła blisko jedenaście milionów, co daje 83 terabajty pobranych danych i transfer na poziomie 20 Gb/s. Nad przebiegiem całej ak-cji czuwał komitet Guinessa pilnując, aby nie doszło do nieprawidłowości. Szczegółowy ranking poszczególnych państw znaleźć moż-na na oficjalnej stronie akcji.http://www.mozilla-europe.org/pl/firefox/

9/2008

Aktualności

10 www.sdjournal.pl

Aktualności

11

Microsoft wypuszcza Open XML SDK 1.0Microsoft udostępnił pierwszą wersję Softwa-re Development Kit dla formatu Open XML. SDK zawiera interfejs programowy aplika-cji (API), który ma ułatwić tworzenie progra-mów przeszukujących, tworzących oraz wali-dujących dokumenty. Oferuje też funkcjonal-ność związaną z modyfikacją danych oraz wykonywaniem innych zadań. Z API będzie można korzystać z poziomu każdego języka wspieranego przez .NET Framework. Obecna wersja SDK obsługuje wersję Office Open XML zawartą w MS Office 2007, a więc nieco inną od tej, która stała się standardem ISO.http://www.slashdot.org/

Polska szóstym spamerem świataZ Polski pochodziło aż 3% majowego ruchu spamowego na świecie – wynika z opubliko-wanego raportu firmy Symantec, The State of Spam. Stawia to nasz kraj na szóstym miejscu wśród światowej czołówki – wyżej niż Niemcy, Włochy, Tajlandię, czy Wielką Brytanię. Pierw-szą pozycję zajęły Stany Zjednoczone (28% wszystkich niechcianych wiadomości), daleko prześcigając pod tym względem inne państwa – m.in. Rosję (7%), Turcję (6%), Chiny (4%), Bra-zylię (4%). Specjaliści już dawno ostrzega-li przed spamem wykorzystującym bieżące wydarzenia do uwiarygodnienia przekazu. W maju użytkownicy w Stanach Zjednoczonych otrzymywali niechciane wiadomości od fik-cyjnej firmy pożyczkowej. Ze względu na złą sytuację gospodarczą byli oni zachęcani do zaciągania szybkich pożyczek w przypadku problemu ze spłatą bieżących wydatków. Ci, którzy wypełnili formularz na stronie firmy, w rzeczywistości przekazywali swoje dane oso-biste do nieznanego źródła. Według najnow-szego raportu w maju spam osiągnął poziom ponad 80% wszystkich wysyłanych wiadomo-ści. Oznacza to, że tylko jedna na pięć wiado-mości e-mail odebranych przez użytkowni-ków nie była spamem. 27% spamu dotyczyło tematyki produktowej, 17% – usług interneto-wych, zaś 16% – tematyki finansowej.http://dobreprogramy.pl

Google Docs z obsługą plików PDFFirma Google udostępniła nową wersję pakie-tu biurowego Google Docs, oferującego moż-liwość edycji dokumentów tekstowych i arku-szy kalkulacyjnych, poprzez przeglądarkę, wzbogacając ją o jedną z najbardziej oczeki-wanych funkcjonalności – wsparcie dla plików PDF. Aktualnie Google Docs pozwala na wykonywanie podstawowych operacji zwią-zanych z obsługą tego typu plików, takich jak podgląd, przesyłanie, czy udostępnianie. Acz-kolwiek, nie jest możliwa ich edycja, a jedy-nie przenoszenie pochodzących z nich treści do innych dokumentów. Działanie pierwszej z nich prezentuje się bardzo podobnie do dostępnej w sąsiedniej usłudze Google Books natomiast jej działanie przypomina typowe, okienkowe aplikacje. Dodatkowo użytkowni-cy, którym został udostępniony dany doku-ment mogą go pobrać na twardy dysk swo-jego komputera. Niewykluczone, że podobna funkcjonalność trafi też do Gmaila.http://mashable.com/

NetSprint walczy o przetrwanie

Polska wyszukiwarka NetSprint.pl oraz portal Wirtualna Polska połączy-ły platformy sprzętowe. Jak deklarują

obaj partnerzy, w wyniku tej operacji inter-nauci będą mieli możliwość przeszukiwania znacznie większej bazy polskich dokumen-tów. Czy powstrzyma to ekspansję Google na polskim rynku? Wirtualna Polska współ-pracuje z firmą NetSprint od 2002 roku. Mi-mo stosowania tej samej technologii wyszuki-wawczej dotąd firmy utrzymywały jednak od-dzielne platformy sprzętowe oraz stosowały zróżnicowane algorytmy wpływające na po-zycję stron w wynikach wyszukiwania. Te-raz zacieśniają współpracę – celem jest ujed-nolicenie wyników wyszukiwania w porta-lu WP.pl z tymi znajdującymi się w serwi-sie Netsprint.pl oraz w serwisach korzystają-cych z tej wyszukiwarki. Połączenie instancji wyszukiwarek ma pozwolić użytkownikom otrzymywać bardziej trafne i bardziej aktual-ne wyniki wyszukiwania, m.in. dzięki więk-szej mocy obliczeniowej serwerów. W efekcie zmian zbieranie i indeksowanie dokumen-tów ma przebiegać znacznie szybciej. Wspól-na instancja ma być też podstawą do znaczne-go powiększenia liczby indeksowanych do-kumentów. NetSprint oraz WP.pl zakładają, że do końca roku 2008 wzrośnie ona o oko-ło 300%. To oczywiście nie jedyne deklarowa-

ne plusy tej operacji – łatwiej będzie pozycjo-nować witryny, ma być także mniej spamu w wynikach wyszukiwania. Nie należy jednak oczekiwać, że zmiany te zagrożą pozycji Go-ogle w Polsce na rynku wyszukiwarek. We-dług ostatnich danych badania gemiusTraf-fic, udostępnianych w serwisie Ranking.pl, Google jest już na tym polu praktycznie mo-nopolistą – aż 91,7% z wizyt z wyszukiwarek na polskie strony objęte badaniem pochodzi bezpośrednio z domeny Google.com. Do tego doliczyć trzeba czołowe polskie portale hory-zontalne, które poza wspomnianą Wirtualną Polską, również korzystają mechanizmów wy-szukiwawczych opartych o rozwiązania Go-ogle. Z kolei z wyszukiwarki na łamach WP.pl generowanych jest jedynie 2,2% wizyt, a bez-pośrednio z NetSprint.pl poniżej 0,1%. Dane te należy traktować oczywiście orientacyjnie, niemniej oddają proporcje udziałów w pol-skim rynku. Wydaje się, że dla tandemu WP i NetSprint, jedyną szansą na przynajmniej za-trzymanie ekspansji wyszukiwarki Google na polskim rynku może być właśnie koncentra-cja na jak najbardziej trafnych i rzetelnych wy-nikach wyszukiwania polskiego Internetu. Je-żeli wierzyć obu firmom – pierwszy krok w tym kierunku został już uczyniony. Pytanie tylko – czy nie za późno?http://netsprint.pl/

ICANN zatwierdza plany uwolnienia domen

W czerwcu bieżącego roku ICANN (The Internet Corporation for Assi-gned Names and Numbers) głoso-

wał nad planami uwolnienia domen najwyż-szego poziomu (TLD) i umożliwienia ich reje-stracji. Wynik głosowania okazał się pomyślny dla zwolenników nowej koncepcji. W związku z tym można spodziewać się, że już niedługo możliwe będzie rejestrowanie nie tylko domen z aktualnie dostępnymi rozszerzeniami taki-mi jak .com, .pl lub .net, ale także ze swoim wła-snym rozszerzeniem. W sieci pojawią się więc nazwy zakończone na przykład .google, .ebay czy .microsoft. Zaakceptowany plan musi teraz przerodzić się w oficjalny dokument, ostatecz-nie definiujący zasady rejestracji TLDs. Taki dokument ma powstać na początku 2009 ro-ku i jeśli zostanie zatwierdzony przez zarząd ICANN, rejestracja domen rozpocznie się w pierwszym kwartale przyszłego roku. Wygląda jednak na to, że proces rejestracji będzie zdecy-

dowanie bardziej skomplikowany, niż dzisiaj w przypadku zwykłych domen. Po złożeniu apli-kacji do ICANN i pomyślnym zweryfikowaniu nazwy (czy nie jest obraźliwa lub nie narusza praw firm i osób trzecich) trzeba będzie jesz-cze słono zapłacić, znacznie więcej, niż speku-lowano wcześniej – od 100 do 500 tysięcy do-larów. Dodatkowo podmiot rejestrujący będzie musiał wykazać, że jest w stanie technicznie utrzymać nową końcówkę – albo samodziel-nie, albo z pomocą firmy partnerskiej. Podczas konferencji w Paryżu ICANN debatował tak-że nad umożliwieniem rejestracji domen naj-wyższego poziomu zawierających znaki spoza alfabetu łacińskiego. Dzięki temu realna była-by rejestracja końcówek np. z chińskimi znaka-mi. Dyskusja, na razie bez konkretnych wnio-sków, będzie kontynuowana na kolejnym po-siedzeniu, które odbędzie się w listopadzie bieżącego roku.http://arstechnica.com/

09/200812 www.sdjournal.org 13

Opis CD

Delphi for PHP 2.0 – pierwsze wizualne środowisko RAD dla PHP

Delphi for PHP rewolucjonizuje tworzenie aplikacji interneto-wych wprowadzając w pełni zintegrowane, wizualne podejście ty-pu RAD do programowania PHP oraz dostarczając liczne kompo-nenty. Rozbudowany edytor PHP, debugger oraz nowe możliwo-ści optymalizacji znacznie zwiększają szybkość oraz wydajność tworzonego kodu. Tworzenie połączeń z czołowymi bazami da-nych w tym MySQL, Oracle, Microsoft SQL Server, PostgreSQL oraz InterBase jest łatwe a zintegrowana biblioteka komponentów VCL for PHP pomaga programistom w szybkim i wizualnym two-rzeniu Webowych aplikacji PHP oraz łatwym integrowaniu PHP, JavaScript/AJAX oraz komponentów i kodu open source.

Jedynie Delphi for PHP dostarcza zarówno możliwość wglądu w sam kod aplikacji PHP, jak też wgląd w jej projekt bezpośrednio z po-ziomu środowiska IDE. Wgląd w projekt aplikacji pozwala progra-mistom na tworzenie interfejsów użytkowników, połączeń bazoda-nowych oraz wielu innych elementów poprzez przenoszenie odpo-wiednich komponentów dostępnych na Palecie Narzędzi (Tool Palet-ce) na formatkę. Właściwości i zdarzenia (properties and events) mogą być określane poprzez Inspektora Obiektów (Object Inspektor) a zmia-ny we właściwościach, dotyczące np. rodzaju czcionki, koloru oraz jej rozmiaru są natychmiast odzwierciedlane w widoku projektu.

Delphi for PHP wykorzystuje zintegrowana bibliotekę PHP o na-zwie VCL for PHP. VCL for PHP jest biblioteką przechowującą prak-tycznie każdy kod źródłowy PHP, strukturę (framework) lub inną bi-bliotekę w postaci wizualnych komponentów wielokrotnego wyko-rzystania. Wystarczy umieścić komponent na formatce i wykorzystać go w swojej aplikacji. Komponenty znajdujące się w bibliotece VCL for PHP mają wbudowane właściwości, metody i zdarzenia czyniąc z tworzenia interfejsów Webowych proste i szybkie zadanie. Biblioteka VCL for PHP jest w pełni elastyczna i rozszerzalna, pozwalając użyt-kownikowi na łatwe dodawanie nowych klas lub komponentów.

Zaawansowany edytor oraz debuger mogą uczynić żmudny i ner-wowy procesu śledzenia i wyłapywania błędów w kodzie szybkim i bezbolesnym. Delphi for PHP posiada dostosowywany edytor kodu źródłowego pozwalający na podświetlanie składni, tworzenie zakła-dek do nawigowania po dużych plikach oraz technologię Code Insi-ght wspierającą określanie metod i właściwości. Zintegrowany debu-ger pomaga w znajdowaniu i naprawie błędów, przeglądaniu break-pointów oraz lokalnych i zdalnych zmiennych. Nowy zintegrowany profiler Delphi for PHP umożliwia łatwe wyszukiwanie wąskich gar-deł w aplikacjach Webowych PHP optymalizując ich wydajność.

GFI EventsManagerZarządzanie logami zdarzeń z sieci rozległej – nie wymaga stania się specjalistą! GFI EventsManager jest prostym w użyciu rozwiązaniem, zbierającym informacje ze wszystkich urządzeń, które są odnotowane w rejestrze zdarzeń systemu Windows, W3C i Syslog. Chwalony jest za zaawansowane procesy obróbki zdarzeń z zastosowaniem dostar-czonych reguł i filtrów, dając tym samym informację co się wydarzy-ło w infrastrukturze IT. Umożliwia to ocenienie jak pracownicy wyko-rzystują swój czas pracy np. kiedy włączają swoje komputery i z jakich plików korzystają. Ponadto zapewnia maksymalną efektywność pra-cy sieci dzięki wczesnemu powiadamianiu o wszelkich potencjalnych

uszkodzeniach sprzętu i oprogramowania, a podczas monitoringu za-wiadamia o możliwych naruszeniach zasad bezpieczeństwa.Korzyści:

• centralizuje zdarzenia Syslog, W3C i Windows, generowane przez firewall, serwery, routery, stacje robocze i inne urzą-dzenia pracujące w sieci;

• asystent upraszczający instalację, konfigurację i zarządzanie;• bezkonkurencyjne skanowanie zdarzeń z wydajnością do po-

nad 6 milionów na godzinę;• wstępnie skonfigurowane reguły przetwarzania zawarte w

produkcie zapewniają efektywną klasyfikację i zarządzanie zdarzeniami;

• automatyczne monitorowanie zdarzeń oraz powiadamianie;• zaawansowane raporty do efektywnego monitorowania ak-

tywności w sieci, dające szybki zwrot inwestycji.

IntelliJ IDEAPrzeznaczone do wykonania wydajnych opracowań – zintegrowa-ne środowisko intelektualne Java, zapewniające stabilny zestaw rozbudowanych środków narzędziowych. Możliwości funkcjonal-ne IntelliJ IDEA są przeznaczone dla użytkowników oraz innych osób chcących korzystać z funkcji programu.Cechy kluczowe programu:

• pomoc intelektualna przy kodowaniu – potężny edytor, roz-poznający Java, HTML/XHTML, XML/XSL, CSS, Ruby oraz JavaScript, obsługuje struktury podobnie jak Rails i GWT, za-pewniając środowisko dla zaawansowanego kodowania. Nieza-leżnie od stosowanego przez Państwa języka, rozbudowane za-bezpieczenie kodu, weryfikacja poprawności, formatowanie i modelowanie – zawsze pozostają w Państwa rękach;

• nawigacja i przeszukiwanie – rozbudowana projektowa na-wigacja struktury kodu, ułatwia analizę nawet dużych pli-ków, zapewniając wygodny sposób ich przeglądania. System przeszukiwania rozpoznaje elementy języków, wyświetlając wyniki na interaktywnym panelu nawigacyjnym i pomaga Państwu przeanalizować wszystkie znalezione pliki;

• pojemny refaktoring – duży zestaw refaktoringu (50+) rzeczy-wiście obejmuje każdy aspekt przetwarzania kodu i pozwala sku-tecznie obsługiwać i modernizować projekty. Wszystkie refak-toringi obsługują języki i technologie Java, XML, JSP, EJB, Java-script i Ruby oraz zapewniają elastyczne sterowanie kodem;

• analiza kodu – wbudowany analizator dynamicznego kodu, zawierający ponad 600 rodzajów weryfikacji, wykonuje w lo-cie analizę kodu i ujawnia wspólne błędy syntaktyczne oraz inne błędy, ujawnione w procesie kompilacji. Analiza staty-styczna kodu wykrywa krytyczne parametry pracy, „mar-twe” kody, zależności i inne problemy dotyczące kodów;

09/200812 www.sdjournal.org 13

Opis CD

• kompilacja, wykonanie, uruchamianie – IntelliJ IDEA współ-pracuje z licznymi kompilatorami Java. Mogą Państwo kompilo-wać projekty, stosując swój ulubiony kompilator bez konieczno-ści instalowania zintegrowanego środowiska do wykonania opra-cowań. IntelliJ IDEA zawiera najlepszy w generacji JPDA moduł przygotowania do pracy, posiadający prosty i wygodny interfejs użytkownika. Unikatowa technologia HotSwap pozwala Pań-stwu na modyfikowanie i rekompilację elementów kodu w pro-cesie uruchamiania (przygotowania do pracy), bez konieczności uruchamiania procesu w całości;

• API i pluginy – istnieje ponad 300 dodatków do programu In-telliJ IDEA, które poszerzają jego możliwości funkcjonalne i dodają różne wartościowe funkcje do procedury weryfikacji kodu i refaktoringu, edytory i narzędzia, obsługę języków i ser-werów aplikacji, itd.

Wymagania systemowe:

• Intel Pentium III/800 MHz or higher (or compatible);• 256 MB RAM minimum;• 1 GB RAM recommended;• 300 MB hard disk space + at least 200 MB for caches;• 1024x768 minimum screen resolution.

Windows:

• Microsoft Windows Vista/2003/XP/2000/NT 4.0 SP6a.

Linux:

• Red Hat Linux Fedora/9.x/8.x/7.3;• GNOME or KDE desktop;• JDK 1.6.

Mac OS X:

• Mac OS X 10.4 (Tiger);• 1.42 GHz G4, G5 or Intel-based Mac recommended.

ReSharperDodatkowy moduł dla środowiska developerskiego dla C#, Visual Ba-sic .NET, XML, XAML, i ASP.NET. Dostęp do funkcji ReSharper po-chodzi bezpośrednio z interfejsu Visual Studio, co znacznie upraszcza tworzenie programów o dobrej jakości przez indywidualnych dewelo-perów lub grupy. ReSharper jest dostępny w trzech wersjach – pełna, C# i Visual Basic .NET. Daje deweloperom innowacyjne narzędzia do refaktoringu, udoskonalone mechanizmy testowania modułowego i wiele innych opcji. JetBrains ReSharper gwarantuje podniesienie efek-tów pracy programistów, zapewniając im inteligentne narzędzia uła-twiające wpisywanie kodu, narzędzia do wykrywania i szybkiego po-prawiania błędów, a także opcje projektowania wstecznego.


• Operating System – Microsoft Windows 2000/XP/Vista;• Processor – Pentium III 850 Mhz minimum;

• Memory – 512 Mb minimum (1Gb recommended);• Disk space – 100 Mb;• Microsoft Visual Studio 2005 with Service Pack 1 or Micro-

soft Visual Studio 2008 codename "Orcas" Beta

DotTrace 3.1Profiler wysokiej jakości, przy pomocy którego deweloperzy będą mo-gli dokonywać profilowania aplikacji .NET i ASP.NET, a także wykry-wać fragmenty kodu programowego, ograniczającego wydajność syste-mu, szybciej i dokładniej niż wcześniej. Najważniejszą z funkcji odno-wionej wersji jest profil pamięci . Dzięki niemu, użytkownik może ob-serwować dynamiczną zmianę stanu pamięci w czasie wykorzystywa-nia aplikacji .NET. do optymalizacji zasobów. Teraz możliwe jest rów-nież tworzenie migawek różnych momentów używania pamięci, w ce-lu dalszej analizy, w dziewięciu różnych etapach. Kolejna widoczna in-nowacja to funkcja integracji z Microsoft Visual Studio i obróbka przy pomocy programu serwisów Windows.

Znaczącą innowacją jest również opcja szybkiego przeglądu pro-filu Quick Info, przeznaczona do natychmiastowego przeglądu migawek pamięci z ulepszoną filtracją.


• Windows 32-bit;• Processor with IA32 architecture;• Microsoft Windows 2000, XP or 2003 Server;• Microsoft .NET Framework 1.1 or 2.0;• Internet Explorer 6;• 512 megabytes of RAM or more is recommended;• 40 megabytes of hard drive space;• Please note – Memory profiling works only with Microsoft

.NET Framework 2.0 applications

for Windows 64-bit (x64)

• A processor with x64 architecture;• Microsoft Windows XP x64 or 2003 Server x64;• Microsoft .NET Framework 2.0 x64;• Internet Explorer 6;• 512 megabytes of RAM or more is recommended;• 40 megabytes of hard drive space• Please note – Memory profiling works only with Microsoft

.NET Framework 2.0 applications

TeamCity 3.1Innowacyjne, niezależne środowisko deweloperskie do stałej integracji i efektywnej pracy nad kodem aplikacji Java i .NET. Pakiet TeamCity za-wiera wtyczki Eclipse, Microsoft Visual Studio, i IntelliJ IDEA, które za-bezpieczają funkcje zintegrowanych środowisk deweloperskich.Team-City automatyzuje i koordynuje kluczowe procesy współdziałania, za-cieśnia integrację z wieloma środowiskami deweloperskimi, jak również przyspiesza i upraszcza procesy testowania i analizy kodów aplikacji.

Nowa wersja zawiera wiele proponowanych przez użytkowników funkcji, takich jak wsparcie Microsoft Visual SourceSafe 2005 i 6.0, in-tegracja z pakietem Microsoft Visual Studio 2005, opcja pozwalająca na szybkie przejście z testu do właściwego fragmentu kodu wyjściowego.

09/200814

Biblioteka miesiącaC5 – nowoczesna biblioteka kolekcji dla .NET

www.sdjournal.org 15

Mimo swojego niewielkiego wieku (wersja 1.0 została opublikowana na początku 2006 a 1.1 w lutym

2008) jest ona wykorzystywana w przemyśle gier komputerowych, sektorze bankowym, in-stytucjach finansowych oraz nawet w US Na-val Research. Autorzy projektując i implemen-tując bibliotekę wykorzystali bagaż doświad-czeń i obserwacji wywodzących się jeszcze z ję-zyka Smalltalk, Java oraz obecnych kolekcji w .NET. Co w połączeniu ze wsparciem ze strony Microsoft Research przyczyniło się do powsta-nia sporo ponad 25000 linii kodu implemen-tujących bardzo zaawansowaną bibliotekę, jaką jest C5, wspartą równie obszerną ilością testów jednostkowych.

Czym jest biblioteka kolekcji oraz jakie jest jej przeznaczenie nie trzeba nikomu spe-cjalnie wyjaśniać. Biblioteka taka dostarcza struktury oraz metody ułatwiające manipu-lowanie kolekcjami danych. Musi być na ty-le ogólna by mogła być użyta w wielu dziedzi-nach oraz na tyle szczegółowa, aby była wydaj-na i pozwalała na efektywne tworzenie aplika-cji niezależnie od tego, czy stosujemy bibliote-kę kolekcji w grach komputerowych, bazach danych, kompilatorach czy podczas tworze-niu aplikacji WWW. Większość bibliotek po-siada implementacje wektorów, list połączo-

nych, kolejek priorytetowych, stosów, zbio-rów, wielozbiorów czy słowników. Dodatko-wo kolekcje, które są generyczne (ang. gene-ric), pozwalają na bezpieczeństwo typu i pa-rametryzacje poszczególnych implementacji klas (unikami rzutowania z i na typ object jak w .NET 1.1). Niniejszy artykuł dotyczyć bę-dzie jednej z takich kolekcji napisanej całko-wicie w C# i dostępnej dla wszystkich języ-ków .NET od wersji 2.0 oraz Mono od 1.2. Jest to C5, której nazwa pochodzi (najpraw-dopodobniej, bo sami autorzy nie są pewni) od Copenhagen Comprehensive Collection Clas-ses for C#, mimo że, wbrew nazwie, do C# jej użycie się nie ogranicza.

Po tym krótkim wstępie opisującym kon-cepcję biblioteki kolekcji nasuwa się na myśl następujące stwierdzenie – przecież dla każ-dego języka czy framework’u mamy dostępne gotowe biblioteki kolekcji. Po co więc tworzyć nowe? Jest kilka takich bibliotek dla .NET, z których najważniejszymi (poza C5) są Win-tellect Power Collections oraz dostępne wraz z BCL (Base Class Libraries) kolekcje z prze-strzeni nazw System.Collections.Generic. Wadami SCG, jak dalej nazywać będę System.Collections.Generic, jest m.in. ograniczona ilość struktur danych. Co więcej niektóre kla-sy mają podobną funkcjonalność a nie są do-stępne za pomocą wspólnego interfejsu, np. listy połączone a tablice. Dodatkowo autorzy C5 zarzucają SCG, że brak spójnych interfej-sów powoduje wydłużenie czasu nauki kolek-cji oraz naukę interfejsu poszczególnych klas a nie ogólnych interfejsów implementowanych

przez te kolekcje. Co więcej SCG zostały za-projektowane w celu przyspieszenia operacji na niewielkich ilościach danych (dbając o sta-łe współczynniki przy złożoności obliczenio-we operacji). W C5 zdecydowano się nie dbać o stałe współczynniki w złożoności obliczenio-wej dając bardziej bogate właściwości. Niedo-ciągnięcia SCG miała uzupełnić biblioteka Po-wer Collections Peter’a Golde z firmy Wintel-lect. Biblioteka ta wniosła dodatkowe struktu-ry danych oraz algorytmy, co jest zauważalną zaletą. Niemniej jednak jej wadą jest sam fakt, że została ona zbudowana na bazie SCG i tym samym większość problemów SCG jest nadal aktualna w PowerCollections. O Power Col-lections oraz System.Collections.Generic w dalszej części artykułu.

Biorąc pod uwagę wady i problemy związa-ne z istniejącymi kolekcjami powstały założe-nia projektowe biblioteki C5. O założeniach tych traktuje kolejny rozdział a tymczasem warto jeszcze wspomnieć o tym, że biblioteka ta dostępna jest zarówno w postaci binarnej jak i kodu źródłowego. Biblioteka rozpowszechnia-na jest na licencji zbliżonej do BSD a to ozna-cza, że można modyfikować ją w dowolny spo-sób nawet w celach komercyjnych bez potrze-by zgłaszania tego autorom pod warunkiem za-chowania wszystkich nagłówków dotyczących praw autorskich.

Założenia projektowe bibliotekiZanim poznamy szczegóły biblioteki, jak jej używać oraz jak jest zbudowana, przyjrzyjmy się podstawowym założeniom projektowym i implementacyjnym C5. Założenia te są jedno-cześnie charakterystyką tej biblioteki. A to dla-tego ponieważ wszystkie podstawowe postula-ty postawione w 2004 roku, kiedy to biblioteka zaczęła się dynamicznie rozwijać, zostały zre-alizowane. Rozdział ten jednocześnie stanowi opis cech biblioteki i właściwości.

Jednym z podstawowych założeń projekto-wych było, oczywiście, wsparcie dla najczę-

C5

Artykuł ten dotyczy C5, czyli nowej biblioteki kolekcji dla .NET stworzonej na Uniwersytecie IT w Kopenhadze w Danii przez Niels’a Kokholm oraz Peter’a Sestoft. C5 nie tylko jest użyteczną biblioteką kolekcji ale również nowym podejściem do wykorzystania kontenerów w .NET.

Dowiesz się:• Czym jest biblioteka kolekcji C5 i jakie są jej

zastosowania;

• Jak efektywnie użyć kontenerów dostępnych

w ramach tej biblioteki;

• Jakie są wady i zalety C5.

Powinieneś wiedzieć:• Czytelnik powinien znać podstawy programo-

wania w języku C#;

• Czytelnik powinien posiadać podstawową

wiedzę z zakresu struktur danych i algoryt-

mów.

Poziom trudności

nowoczesna biblioteka kolekcji dla .NET

09/200814



ściej używanych kolekcji, czyli m.in. list, ko-lejek priorytetowych, zbiorów, wielozbiorów (ang. multiset lub bag) czy słowników. Kolek-cje uwzględniają wzorce wykorzystywane w .NET (np. enumeracje z wykorzystaniem foreach w C#). Dodatkowo kolekcje poza iteratorami wspierają wyjątki (dziedziczenie z klasy System.Exception) oraz, co jest jedną z ich cech charakterystycznych, posiadają za-implementowane zdarzenia! Zakodowane są również bardzo przydatne (a nieco trudne i drobiazgowe do implementacji) właściwości jak enumeracja kolekcji w odwrotnej kolejno-ści czy bardzo przydatna cecha zwana upda-teable view, o której nieco później w dalszej części artykułu. Kolejną i bardzo ważną ce-chą jest programowanie bazujące na interfej-sie, a nie implementacji. Innymi słowy biblio-teka zaprojektowana jest z wykorzystaniem jednej z dwóch głównych zasad projektowych przedstawionej w klasycznej już pracy Design Patterns: Elements of Reusable Object-Oriented

Software autorstwa Bandy Czworga. Zasada ta to w oryginale program to an interface, not an implementation. Innymi słowy autorzy bi-blioteki odseparowali właściwą implementa-cję kolekcji od implementowanych przez nie interfejsów. Interfejsy ułożone są w logiczną strukturę dziedziczenia na dole której znaj-dują się konkretne kolekcje. Każdy z inter-fejsów (np. IList<T> czy ICollection<T>) ma minimalny niezbędny zestaw właściwo-ści i metod. Dzięki temu osiągnięto to, że za pomocą tego samego interfejsu możemy korzystać z wielu zupełnie inaczej zaimple-mentowanych kolekcji. Dla przykładu za po-mocą IList<T> możemy korzystać zarów-no z tablicy (listy opartej o tablicę) jak i li-sty połączonej, czyli odpowiednio z kolekcji ArrayList<T> oraz LinkedList<T>. Ostatnią z ważniejszych cech było udokumentowanie złożoności obliczeniowej operacji wszystkich kolekcji. Dokumentacja ta dostępna jest na stronie projektu.

Pisząc o założeniach implementacyjnych Peter Sestoft i Niels Kokholm zdecydowali się użyć najlepszych możliwie struktur da-nych i algorytmów. Wybór ten oznacza, że C5 niekoniecznie korzysta z łatwych do za-implementowania algorytmów – wręcz prze-ciwnie. Źródła projektu są dostępne, więc za-praszam do ciekawej lektury. Na samym po-czątku postanowiono również, że najważniej-sza jest wydajność kolekcji w ujęciu asympto-tycznym oraz bogate właściwości kolekcji. In-nymi słowy algorytmy nie są zoptymalizo-wane pod kątem małej ilości elementów. W porównaniu do kolekcji z System.Collections.Generic C5 może wypaść nieco wolniej przy niewielkiej ilości elementów, lecz szyb-ciej w przypadku olbrzymiej ich ilości. Nie-mniej jednak nie zapomniano o wydajnej im-plementacji i profilowano użycie struktur w porównaniu do obiektów w algorytmach. Oczywiście całość została napisana tylko w kodzie zarządzanym bez ani jednego bloku

Rysunek 1. Diagram hierarchii interfejsów kolekcji C5

��

��

�

��

��

��

��

��

��

��

��

�

��

��

��

�

��

��

��

�

��

��

��

�

��

��

�

��

��

�

��

��

�

��

��

�

��

��

�

��

��

��

��

��

�

��

��

��

�

��

��

��

�

��

��

��

�

09/200816



unsafe. Ostatnim z założeń implementa-cyjnych jest odcięcie się od istniejących im-plementacji kolekcji i zaimplementowanie wszystkiego od zera. Oznacza to, że C5 nie jest rozszerzeniem kolekcji z System.Collections.Generic. Piszę o tym, ponieważ in-na biblioteka kolekcji czyli Wintellect .NET Power Collections jest swego rodzaju rozsze-rzeniem System.Collections.Generic w konwencji istniejących już w tej przestrzeni nazw kolekcji .NET, co do wielu zastosowań może być ograniczeniem.

Budowa indeksu dla pliku tekstowego – przykładPrzyjrzyjmy się bardzo prostej aplikacji za-mieszczonej na Listingu 1. Zadaniem apli-kacji jest dla zadanego pliku (w tym przy-padku file.txt) stworzyć indeks. Indeks ten ma przedstawiać posortowaną listę wyra-zów oraz numery linii, w jakich one wystę-pują. Funkcja CreateIndex tworzy indeks natomiast funkcja PrintIndex wyświetla in-deks na konsoli. Elementem głównym jest obiekt index typu TreeDictionary<string,

TreeSet<uint>>. Jak widać, wyrazy są kluczami identyfikującymi zbiór nume-rów linii (typ TreeSet<uint>). Użycie TreeDictionary<K,V> pozwala nam wyeli-minować duplikaty słów w prosty sposób. Dla każdego słowa zapisujemy obiekt kolek-cji przechowującej numery linii (uint). Apli-kacja najpierw tworzy obiekt index, następ-nie korzystając z funkcji BCL otwieramy plik i czytając linia po linii dzielimy go na słowa. Następnie każde słowo sprawdzamy, czy jest już w naszym indeksie czy jeszcze nie. Je-

Listing 1. Program budujący indeks pliku

using System;

using SCG = System.Collections.Generic;

using C5;

using System.Text.RegularExpressions;

using System.IO;

namespace SDJ

{

class IndexProgram

{

static TreeDictionary<string, TreeSet<uint>> index =

null;

// Uwaga: obsluga bledow celowo pominieta

static void Main(string[] args)

{

CreateIndex("file.txt");

PrintIndex();

PrintIndex2();

}

static void CreateIndex(string fileName)

{

index = new TreeDictionary<string,

TreeSet<uint>>();

// Wyrazenie regularne nie uwzgledniajace polskich

// znakow diakrytycznych

Regex sepRegex = new Regex("[^a-zA-Z0-9]+");

using (TextReader reader = new

StreamReader(fileName))

{

uint lineNumber = 0;

string line;

while ( (line = reader.ReadLine()) != null)

{

lineNumber++;

string[] words = sepRegex.Split(line);

foreach ( string word in words )

if (word.Length > 0)

{

if (!index.Contains(word))

index.Add(word, new

TreeSet<uint>());

index[word].Add(lineNumber);

}

}

}

}

static void PrintIndex()

{

foreach (string word in index.Keys)

{

Console.Write("{0}: ", word);

foreach (uint lineNumber in index[word])

Console.Write("{0} ", lineNumber);

Console.WriteLine();

}

}

static void PrintIndex2()

{

Act<KeyValuePair<string, TreeSet<uint>>> act =

new Act<KeyValuePair<string, TreeSet<uint>

>>(PrintKVP);

index.Apply(act);

}

static void PrintKVP(KeyValuePair<string,

TreeSet<uint>> kvp)

{

Console.Write("{0}: ", kvp.Key);

kvp.Value.Apply(new Act<uint>(delegate(uint

number) { Console.Write("{0} ", number);

}));


}

}

}

09/200816



żeli nie to dodajemy nową parę <string, TreeSet<uint>>. Jak możemy wyświetlić tak stworzony indeks? Otóż napisałem dwie funkcje (PrintIndex oraz PrintIndex2). Jedna korzysta z foreach a druga z metody Apply interfejsu ICollectionValue. O inter-fejsach kolekcji i słowników dalej w artyku-le. Natomiast metoda void Apply(Act<T>

act) pobiera jako argument delegata przyj-mującego argument typu T czyli kolejno KeyValuePair<string, TreeSet<uint>> oraz uint. Metoda ta wykonuje kod delega-ta dla każdego elementu kolekcji. Dzięki te-

mu, że jest ona dostępna w interfejsie już ICollectionValue (czyli wysoko w hierar-chii dziedziczenia) to implementowana jest przez wszystkie kolekcje C5. Stanowi ona

bardzo wygodny sposób na polimorficzne manipulowanie elementami kolekcji. Efekt działania programu podobny będzie do Li-stingu 2.

Rysunek 2. Interfejs ICollectionValue. Jeden z podstawowych interfejsów C5

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Rysunek 3. Interfejs ICollection

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Power CollectionsBiblioteka Power Collections jest projektem open source mającym na celu stworzenie biblioteki generycznych kolekcji dla .NET. Podstawowym założeniem projektu było rozszerzenie klas z .NET BCL (Base Class Libraries) w przeciwieństwie do tworzenia własnych rozwiązań od początku (jak w przypadku C5). Biblioteka ta została stworzona przez firmę Wintellect i obecnie do pobrania jest w portalu http://www.codeplex.com. Zawiera kolekcje i słowniki:

• Set;• Bag;• MultiDictionary;• OrderedDictionary;• OrderedMultiDictionary;• OrderedSet;• OrderedBag;• Dequeue;• PriorityQueue.

Więcej o Power Collections na stronie http://www.codeplex.com/PowerCollections, gdzie dostępna również jest dokumentacja.

Listing 2. Wynik działania programu z Listingu 1 (fragment)

a: 2 5

an: 2

anagram: 1 2 3 4

and: 1 3 4 5

before: 4

belong: 2

check: 4

class: 2 3 4

classes: 1

create: 5

dictionary: 2

...

09/200818



Przegląd interfejsów kolekcjiInterfejs jest to definicja operacji, które są im-plementowane przez daną klasę. Z racji, że jed-nym z podstawowych założeń projektowych C5 jest programowanie na bazie interfejsu, in-terfejsy i ich zrozumienie jest bardzo ważnym elementem poznawania biblioteki. Rysunek 1 przedstawia hierarchię dziedziczenia. Z szesna-stu prezentowanych interfejsów czternaście po-chodzi z C5 natomiast dwa (IEnumerable<T> oraz IShowable) są interfejsami z .NET Frame-work. Na Rysunku widać zależności pomiędzy interfejsami. Poniżej opisałem wybrane inter-fejsy prezentując ich cechy charakterystyczne.

IEnumarable<T> na samej górze Rysunku 1 jest interfejsem kolekcji o nieznanej wielko-ści i niewielu specyficznych właściwościach. Jest to interfejs pochodzący z SCG. Ważnym członkiem interfejsu jest GetEnumerator(), która to metoda zwraca obiekt klasy SCG.IE-numerator<T> pozwalający na iterowanie po elementach kolekcji za pomocą słowa kluczo-wego foreach (w C#). Warto zauważyć, że każda z kolekcji implementuje ten interfejs i dlatego też w każdej z kolekcji możliwe jest użycie foreach.

ICollectionValue<T> z biblioteki C5 jest jednym z ważniejszych interfejsów dziedzi-

czących bezpośrednio po interfejsach z .NET Framework. ICollectionValue<T> jest ko-lekcją o znanej wielkości lecz niepozwala-jącą na zmianę elementów w kolekcji. Roz-szerza IEnumerable<T> o metody CopyTo() oraz ToArray(), które kopiują elementy ko-lekcji do istniejącej lub nowej tablicy. Kolejny-mi nowymi członkami interfejsu są właściwo-ści Count oraz IsEmpty. Metody i właściwo-ści ICollectionValue<T> są widoczne na Ry-sunku 2.

Interfejs ICollection<T> jest implemento-wany przez wiele kolekcji C5. ICollection<T> implementuje interfejs SCG.ICollection<T> oraz C5.IExtensible<T>. Kolekcja taka jest rozszerzalna (interfejs C5.IExtensible<T>), czyli pozwala na dodawanie, usuwanie ele-mentów i grup elementów, pozwala na sprawdzanie przynależności elementu do kolekcji oraz inne metody charakterystycz-ne dla większości kolekcji. Listing 3 pre-zentuje proste użycie kolekcji implemen-tującej C5.ICollection<T> w postaci kla-sy C5.ArrayList<T> (oraz zakomentowanej C5.LinkedList<T>).

Na tym krótkim Listingu widzimy uży-cie zdarzeń, właściwości ActiveEvents z C5.ICollectionValue<T> oraz Apply z te-go samego interfejsu. Dzięki metodzie Apply oraz delegatowi Act<T> możemy w prosty spo-sób wyświetlić zawartość kolekcji na konsolę. Diagram interfejsu jest prezentowany na Ry-sunku 3.

Kolejnym godnym uwagi interfejsem z bi-blioteki C5 jest IStack<T>. Jest to ukierunko-

Rysunek 4. Interfejs IStack

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Listing 3. ICollection

using System;


using C5;

namespace CollectionApplication

{

class ICollectionProgram

{

static ICollection<string> collection = null;


{

collection = new ArrayList<string>();

//collection = new LinkedList<string>();

collection.ItemsAdded += new ItemsAddedHandler<string>(list_ItemsAdded);

collection.ItemsRemoved += new ItemsRemovedHandler<string>(list_

ItemsRemoved);

EventTypeEnum events = collection.ActiveEvents;

// if ( events ...

collection.Add("jeden");

collection.Add("dwa");

collection.AddAll(new string[] { "trzy", "cztery", "piec" });

collection.Remove("trzy");

collection.Apply(new Act<string>(Console.WriteLine));

}

static void list_ItemsRemoved(object sender, ItemCountEventArgs<string>

eventArgs)

{

// obsluga zdarzenia

}

static void list_ItemsAdded(object sender, ItemCountEventArgs<string>

eventArgs)

{

// obsluga zdarzenia

}

}

}

09/200818



wana kolekcja implementującą zachowanie sto-su, czyli innymi słowy FIFO (First-In-First-Out). Jak widać z diagramu na Rysunku 4 IStack<T> rozszerza IDirectedCollectionValue<T> o metody charakterystyczne dla stosu, czy-li Pop i Push. Listing 4 prezentuje proste uży-cie interfejsu IStack<T> wobec implementacji C5.LinkedList oraz C5.ArrayList. Prezentu-je to elastyczność C5 – stos zaimplementowany zarówno jako lista połączona lub tablica.

Więcej szczegółowych i wyczerpujących in-formacji o interfejsach znajduje się w doku-mentacji a szczególnie w książce pod tytulem The C5 Generic Collection Library dostępnej na stronie projektu.

Kolekcje – implementacjeW rozdziale tym przyjrzymy się wybranym im-plementacjom kolekcji C5. Jest to uzupełnie-nie rozdziału traktującego o interfejsach i ce-lem jego jest ułatwienie zrozumienia budowy całej biblioteki i przedstawienie dostępnych kolekcji. C5 posiada następujące implementa-cje kolekcji:

• CircularQueue<T>, • LinkedList<T>, • ArrayList<T>,

• HashedLinkedList<T>, • HashedArrayList<T>, • WrappedArray<T>, • SortedArray<T>, • TreeBag<T>, • TreeSet<T>, • HashSet<T>, • HashBag<T>

• oraz IntervalHeap<T>.

Poniżej skupiłem się na kolejce cyklicznej (cir-cular queue), tablicy oraz liście połączonej. Reszta kolekcji jest opisana w materiałach on-line, do których podałem linki w Ramce.

CircularQueue<T> (znany również jako bu-for cykliczny) jest kolekcją implementującą IStack<T> oraz IQueue<T>. Jej diagram prezen-towany jest na Rysunku 5. Jak można sprawdzić w kodzie źródłowym kolekcji CicularQueue<T> używa tablicy elementów T[] i implementu-je metody Push i Pop oraz Enqueue i Dequeue do nawigacji po elementach tablicy. Pary me-tod Push i Enqueue oraz Pop i Dequeue są sobie odpowiednikami. CircularQueue<T> korzysta z tablicy elementów T[] stąd też posiada stałą prędkość dostępu do elementów za pomocą in-deksu, czyli O(1), w porównaniu do dostępu do bufora cyklicznego zbudowanego na liście połą-czonej, czyli O(n).

ArrayList<T> jest kolekcją implementują-cą aż 3 interfejsy – IList<T>, IStack<T> oraz IQueue<T>. Jest to kolejna kolekcja, która ko-rzysta z tablicy elementów. Stąd też dostęp do poszczególnych elementów za pomocą indek-su ma stałą prędkość, czyli O(1). Należy jed-nak pamiętać, że wstawienie elementu na po-

czątku lub w środku tablicy powoduje przesu-nięcie elementów znajdujących się pomiędzy miejscem wstawiania nowego elementu a koń-cem tablicy, czyli mówimy tutaj o liniowej zło-żoności tej operacji. Dodatkowo ArrayList<T> implementuje metodę Sort, która korzysta z al-gorytmu quicksort.

LinkedList<T> tak samo jak ArrayList<T> implementuje interfejsy IList<T>, IStack<T> oraz IQueue<T>. W odróżnieniu jednak od dwóch poprzednich kolekcji nie korzysta z ta-blicy elementów lecz wewnętrznie wykorzystu-je podwójnie połączoną listę węzłów, z których każdy przechowuje elementy kolekcji. Stąd też wstawienie elementu w dokowanym miejscu listy zajmuje stały czas – O(1), lecz dostęp do elementu za pomocą indeksu już stały – O(n). Niemniej jednak dostęp do elementów znajdu-jących się w pobliżu jednego z końców jest w praktyce dosyć szybki.

Celem tego krótkiego rozdziału było przed-stawienie wstępu do implementacji kolekcji C5 oraz zaprezentowanie podejścia do opisu ko-lekcji, jakie zostało zaprezentowane przez au-torów kolekcji. W dokumentacji C5 stawiany jest bowiem nacisk na implementowane inter-fejsy, sposób w jaki przechowywane są elemen-ty oraz złożoność obliczeniową poszczególnych operacji (a w szczególności tych wykonywa-nych najczęściej). Reszta kolekcji, jak już pisa-łem, jest wyczerpująco opisana w dokumenta-cji projektu.

Słowniki Słowniki jako struktury danych działają analo-gicznie do słowników znanym nam z życia. Po-

Rysunek 6. Słownik

��

��

��

��

��

��

��

��

��

��

Rysunek 5. Klasa CircularQueue

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

09/200820



zwalają dla zadanego klucza odnaleźć odpowia-dające jemu elementy. Dobrym przykładem może być słownik angielsko – polski. Dla za-danego słowa (klucza) otrzymujemy odpowia-dające hasło (wartość). C5 jak System.Collections.Generic oraz Power Collections posiada również słowniki. Na Rysunku 6 przedstawi-łem drzewo dziedziczenia słowników. Jak wi-dać mamy dostępne dwie implementacje, czyli HashDictionary<T> oraz TreeDictionary<T>. Obydwa implementują IDictionary<T> nato-miast TreeDictionary<T> implementuje rów-nież ISortedDictionary<T>.

HashDictionary<T> reprezentuje pary [klucz, wartość] używając do tego celu tabli-cy mieszającej (ang. hash table). Dostęp do ele-mentów korzystając z klucza oraz wstawianie

elementów jest stałej złożoności obliczeniowej, tzn. O(1). Warto również pamiętać, że enume-racja elementów w słowniku nie gwarantuje za-chowania żadnego specjalnego porządku.

TreeDictionary<T> implementuje ISortedDictionary<T>. Słownik ten do reprezentacji par [klucz, wartość] używa zbalansowanego drzewa czerwono-czarnego (ang. balanced red black binary tree). Dostęp do elementów, doda-wanie i ich usuwanie jest złożoności O(log n). Enumeracja słownika zwraca elementy posor-towane zgodnie z uporządkowaniem klucza w drzewie.

Zaawansowane elementy C5Poznaliśmy już podstawy kolekcji i słowni-ków C5. W poprzednich rozdziałach przed-

stawiłem cechy i założenia biblioteki, inter-fejsy oraz implementacje. Nie jest to jednak wszystko, co ma do zaoferowania bibliote-ka C5.

Autorzy postanowili wzbogacić bibliote-kę o dodatkowe, zaawansowane i użyteczne elementy. W rozdziale tym wspomnę o naj-ważniejszych z nich. Elementy te to – list view, read-only wrappers, sortowanie ta-blic, formatowanie kolekcji, zdarzenia, klono-wanie kolekcji oraz serializacja. Poniżej skupi-łem się na list view, zdarzeniach oraz na se-rializacji.

List view jest w zasadzie tym, co mówi sama nazwa. Jest to widok listy, czyli inny-mi słowy ciągły fragment dowolnej listy czy tablicy, na którym można dokonywać wszel-kich operacji, które są de facto wykonywa-ne na kolekcji, dla której stworzyliśmy list view. Listing 5 prezentuje przykład użycia list view. W najbardziej podstawowy spo-sób stworzenie list view polega na wywo-łaniu metody View. Metoda ta należy do in-terfejsu IList<T>. Elementem zwracanym z metody jest obiekt typu IList<T>, który spełnia warunki określone za pomocą argu-mentów do IList<T>.View(int start, int count).

Pierwszy z nich określa numer elementu początkowego listy a drugi ilość elementów, które wejdą w skład widoku listy. Na pierw-szy rzut oka jest to po prostu kolejna lista, lecz dzięki swoim właściwościom pozwala na wygodną implementację algorytmów wy-magających operacji na fragmentach kolek-cji (niezależnie od tego czy jest to lista po-łączona czy tablica). Jak widać na Listingu collection.View(0, 1) powoduje zwróce-nie widoku listy z pierwszym elementem. Dla kontrastu collection.View(0, 0) byłby to widok z zerową ilością elementów wskazu-jący na początek listy. Za pomocą widoków można wstawiać, usuwać i edytować elemen-ty kolekcji. Dodatkowo nie jest problemem operowanie na jednej kolekcji za pomocą wie-lu widoków nawet jeżeli część z nich zawiera te same elementy.

Zdarzeń w .NET nie trzeba przedstawiać. Jest to standardowy mechanizm powiada-miania części systemu o zmianach w innej jego części. Odbywa się to za pomocą me-chanizmu łączącego zdarzenia z metoda-mi reagującymi na te zdarzania przy pomo-cy delegatów. C5 jest biblioteką, której ele-menty sygnalizują zdarzenia w przeciwień-stwie do SCG czy innych mniej znanych ko-lekcji. Przykład użycia zdarzeń znajduje się na Listingu 3.

Jak widać z przykładu metody list_

ItemsAdded i list_ItemsRemoved są powiąza-ne ze zdarzeniami odpowiednio ItemsAdded oraz ItemsRemoved. Dodatkowo dzięki in-terfejsowi ICollectionValue<T> mamy dostępne właściwości ActiveEvents oraz

Listing 4. IStack

using System;


using C5;

namespace StackApplication

{

class IStackProgram

{

static IStack<int> stack = null;


{

stack = new LinkedList<int>();

PushValues(stack, new int[] { 1, 2, 3, 4, 5 });

stack = new ArrayList<int>();

PushValues(stack, new int[] { 1, 2, 3, 4, 5 });

}

static void PushValues<T>(IStack<T> stack, T[] collection)

{

foreach (T i in collection)

stack.Push(i);

}

}

}

System.Collections.GenericSCG jest przestrzenią nazw w .NET Framework od wersji 2.0 włącznie. Zawiera klasy, struktury i interfejsy kolekcji i słowników generycznych. Z racji, że jest elementem .NET Framework nie wy-maga dodatkowych bibliotek i jest dokładnie opisana w dokumentacji MSDN. Klasy kontenerów to:

• Dictionary;• LinkedList;• List;• Queue;• SortedDictionary;• SortedList;• Stack.

09/200820



ListenableEvents. Właściwości te pozwala-ją na odczyt zdarzeń, które są aktywne (jest przypisany odpowiedni event handler) oraz jakie w ogóle są dostępne dla danej imple-mentacji kolekcji.

Kolejnym zaawansowanym elementem jest serializacja. Celem serializacji jest transfor-macja kolekcji do postaci szeregowej (np. ta-blica bajtów) z zachowaniem aktualnego sta-

nu obiektu w celu zapisania jej na innym me-dium. Może być to na przykład zapis na dys-ku albo przesył przez sieć. Wszystkie klasy kolekcji, słowników oraz wyjątków są seriali-zowalne za pomocą binarnych formaterów z System.Runtime.Serialization.Formatter

.Binary. Należy jednak pamiętać, że C5 nie wspiera serializacji XML, czyli serializacji za pomocą klas z System.Xml.Serialization.

Powodem tego jest fakt, że po pierwsze to wy-magałoby implementacji metody Add(object obj) co spowodowałoby, że C5 nie wspiera-łoby bezpieczeństwa typów (ang. type safe-ty). Dodatkowo serializer XML nie wspiera współdzielenia w grafie obiektów i tym sa-mym powodowałoby to niespójność większo-ści wewnętrznych struktur.

PodsumowanieW artykule tym przedstawiłem wstęp do bi-blioteki C5 opisując różne elementy, jak in-terfejsy, implementacje kolekcji i słowników oraz wspominając o elementach zaawan-sowanych. C5 jest na pewno godnym uwa-gi rozwiązaniem, gdy potrzebujemy inten-sywnie korzystać i przetwarzać duże ilości danych.

Nie jest jednak ona pozbawiona wad, o czym należy pamiętać decydując się na jej użycie. Wady te, jak na przykład brak zgod-ności z interfejsami z .NET, rzutują na utrud-nione łączenie kolekcji z kontrolkami GUI dostępnymi w .NET. Dodatkowo należy pa-miętać, że przy niewielkiej ilości danych ko-lekcje C5 bywają mniej wydajne niż odpo-wiedniki z SCG.

Problemy te, jak zapewnia Peter Sestoft, ma-ją zostać wkrótce rozwiązane – zostały zgło-szone odpowiednie feature requests. C5 jest tak rozbudowaną biblioteką, iż można by na-pisać o niej książkę. Na stronie projektu moż-na pobrać szczegółową dokumentację, która przypomina książkę poświeconą poszczegól-nym problemom użycia biblioteki. Dokumen-tacja ta zawiera dokładny opis każdego z inter-fejsów czy implementacji. Dodatkowo zawiera wiele przykładów użycia oraz ponad sto wzor-ców i antywzorców, jak korzystać a jak nie z klas biblioteki!

Uważam, że C5 jest godnym uwagi roz-wiązaniem, które dzięki doskonałej doku-mentacji i logicznemu projektowi jest pro-stą do nauki i kompletną biblioteką i, moż-na zaryzykować stwierdzenie, że w przyszło-ści C5 mogłoby śmiało zastąpić klasy z .NET Framework.

Listing 5. List view

using System;


using C5;

namespace ListViewApplication

{

class ListViewProgram

{

static IList<string> collection = null;


{

collection = new LinkedList<string>();

//collection = new ArrayList<string>();

collection.AddAll(new string[] { "raz", "dwa", "trzy", "cztery", "piec"

});

IList<string> view1 = collection.View(0, 1);

Console.Write("view1: ");

foreach (string str in view1)

Console.Write(str);


// na konsoli:

// view1: raz

IList<string> view2 = collection.View(3, 0);

view2.Insert(0, "view2_insert");

Console.Write("collection: ");

foreach (string str in collection)

Console.Write("{0} ", str);


// na konsoli:

// collection: raz dwa trzy view2_insert cztery piec

}

}

}

MACIEJ PACZEWSKIAutor tekstu pracuje w firmie BLStream Sp. z o. o.

na stanowisku Senior Software Specialist. Na co

dzień zajmuje się m.in. .NET, Windows Mobile oraz

technologiami pokrewnymi. Programuje najczę-

ściej w językach C++, C oraz C#. Firma BLStream

wchodzi w skład Grupy BLStream, która powstała

by efektywniej wykorzystywać potencjał dwóch,

szybko rozwijających się producentów oprogra-

mowania – BLStream i Gamelion. Firmy wchodzą-

ce w skład grupy specjalizują się w wytwarzaniu

oprogramowania dla klientów korporacyjnych, w

rozwiązaniach mobilnych oraz produkcji i testo-

waniu gier.

Kontakt z autorem: [email protected].

W Sieci

• http://www.itu.dk/research/c5/ – Strona główna projektu C5. Na stronie dostępne źródła oraz binarka

• http://www.itu.dk/research/c5/Release1.1/ITU-TR-2006-76.pdf – Książka opisująca C5 w wersji 1.1• http://channel9.msdn.com/ShowPost.aspx?PostID=370368 – Interesujący wywiad ze współ-

twórcą biblioteki C5 (Peter Sestoft) na Channel 9 • http://www.codeplex.com/PowerCollections – Wintellect .NET Power Collections na Codeplex • http://msdn.microsoft.com/en-us/library/system.collections.generic.aspx – Dokumentacja Sys-

tem.Collections.Generic (MSDN)

09/200822

Bazy danych Optymalizacja bazy danych


Optymalizacja SZBD angażuje admini-stratora, a więc sprzęt, konfiguracja i utrzymanie oraz programistę, a więc

projekt bazy danych oraz implementacja aplika-cji. Artykuł jest wstępem do programistycznego aspektu optymalizacji. Stanowi ogólny przegląd teoretycznych oraz praktycznych elementów, ja-kie należy wziąć pod uwagę, optymalizując bazę danych. Wymaga od czytelnika znajomości pod-stawowych pojęć, jak baza danych, tabela, trans-akcja, relacja, zapytanie SQL, itp. Jako podstawę przyjęto Oracle 10g Express Edition. Jednakże większość z przedstawionych tu zagadnień ma charakter ogólny i nie zależy od SZBD.

Cele optymalizacji są różne, zależnie od ro-dzaju systemu, np:

• OLTP (ang. On-Line Transaction Processing, system bieżącego przetwarzania transak-cji, np. system sprzedaży), zwykle optyma-lizacja czasu odpowiedzi systemu. Arty-kuł skupia się na tego typu rozwiązaniach;

• OLAP (ang. On-Line Analytical Processing, hurtownie danych, zastosowania anali-tyczne), zwykle optymalizacja czasu odpo-wiedzi, technik agregacji danych oraz zu-życia zasobów.

Problem niskiej wydajności może dotyczyć do-wolnego składnika systemu bazy danych, np:

• reguły biznesowe i projekt bazy danych;• operacje wykonywane na bazie danych;• dostępna wolna pamięć operacyjna i czas

procesora;• intensywność operacji dyskowych;• konflikty dostępu do zasobów;• inne aplikacje działające na serwerze;• platforma sprzętowa i system operacyjny;• sieć komputerowa.

Normalizacja schematu bazy danychPo ustaleniu reguł biznesowych, projekt sche-matu bazy danych jest pierwszym elementem optymalizacji. Projektowanie skupia się na od-wzorowaniu wybranych obiektów i ich relacji ze świata rzeczywistego na encje (zwykle encja = tabela w bazie danych) i ich powiązań w sys-temie bazy danych. Zasady poprawnej budowy schematu, czyli normalizacji schematu danych,

definiują tzw. postacie normalne(jest ich pięć, wyższy numer oznacza większe restrykcje).

Co daje normalizacja danych?Z praktycznego punktu widzenia najistotniej-sze jest to, że normalizacja chroni przed po-wielaniem tej samej informacji (np. nazwa producenta) w tej samej lub w różnych tabe-lach. Brak normalizacji, prowadzi to do wielu poważnych utrudnień, w trakcie użytkowania system i modyfikacji danych, tzw. anomalie.

Problemy braku normalizacji danychBłędny projekt bazy danych skutkuje wielo-ma ograniczeniami (Rysunek 1). Poniżej kil-ka przykładów:

• anomalia modyfikacji danych, chcąc po-prawić np. Nazwę producenta trzeba by ją poprawiać we wszystkich miejscach gdzie występuje. Może to prowadzić do szeregu pomyłek;

• anomalia usuwania danych, chcąc usunąć zabawkę musimy również usunąć infor-macje o producencie;

• redundancja, niepotrzebnie powtórzone nazwa i kraj producenta.

Kiedy stosować normalizację danych?W praktyce schemat bazy danych normalizuje się do trzeciej postaci normalnej (Rysunek 2).

Optymalizacja bazy danych

Każda aplikacja funkcjonuje w ramach ograniczonych zasobów systemu, takich jak – pamięć, czas procesora, przepustowość sieci itp. Słaba wydajność SZBD (System Zarządzania Bazą Danych) to zwykle problem zużycia dostępnego zasobu. Należy więc unikać takich sytuacji, uwzględniając możliwe, chwilowe obciążenie systemu dodatkową pracą.

Dowiesz się:• Jakie elementy wpływają na wydajność bazy

danych;

• Jak projektant/programista może poprawić

wydajność systemu.

Powinieneś wiedzieć:• Czym jest system zarządzania bazą danych;

• Czym jest tabela oraz więzy integralności;

• Czym jest zapytanie SQL.

Poziom trudności

Wprowadzenie

Rysunek 1. Schemat przed normalizacją, obarczony anomaliami

ZABAWKA

NazwaZabawki NazwaProducenta KrajProducenta

Klocki

Lalka

Rower

Piłka

P.H.U. Blok

Kubuś sp. z.o.o.

Biker

Kubuś sp. z.o.o.

Polska

Polska

Polska

Francja

09/200822



Czasem, aby poprawić szybkość działania apli-kacji, dopuszcza się pewne odstępstwa od tej zasady, ale tylko jako wyjątek od reguły. Istnieje ścisła definicja każdej postaci normalnej. Prak-tyczna normalizacja do trzeciej postaci normal-nej sprowadza się głównie do:

• wszystkie rozpoznawalne obiekty (ZA-BAWKA , PRODUCENT, KRAJ) umieścić w osobnych tabelach z unikalnym klu-czem głównym. Realizuje się to przez usuwanie wszystkich pól nie związa-nych bezpośrednio z kluczem głów-nym (np: IdZabawki(tu klucz główny) i NazwaProducenta nie mogą być w jednej tabeli bo ten sam producent może być też producentem innych zabawek, a więc z podania producenta nie wynika bezpo-średnio IdZabawki);

• wszędzie gdzie odwołujemy się do innego obiektu (referencja), należy podać tylko jego klucz główny, który pełni wtedy rolę klucza obcego (np. powiązanie zabawka – producent).

Obiekty w bazie danychPrzygotowanie prawidłowego projektu sche-matu bazy danych jest podstawą do praktycz-nej realizacji systemu. Tak więc, w dalszej czę-ści artykułu opisane zostaną wybrane obiek-ty bazy danych oraz ich wpływ na wydajność SZBD.

IndeksowanieZałóżmy, że mamy tabelę dokumentów maga-zynowych z dziesiątkami tysięcy a nawet mi-lionami rekordów (rekord = wiersz w tabeli). Dane z tabeli przechowywane są w plikach da-nych (ang. datafile) na dysku. Pliki te czytane są z dysku blokami (ang. data block). Chcemy po-brać z tabeli tylko dokumenty wybranego klien-ta. Zwykłe czytanie kolejnych bloków danych z dysku, celem odnalezienia rekordów spełniają-cych warunek byłoby szalenie nieefektywne. Należy więc ograniczać ilość odczytów z dysku.

Co daje indeksowanie?Utworzenie indeksu na wybranym polu tabe-li oznacza, że w osobnym miejscu zapisywana jest informacja (adres), w jakich blokach danych można odnaleźć rekord zawierający konkretną, indeksowaną wartość, np. Rekordy z dokumenta-mi klienta o identyfikatorze K znajdują się na dys-ku twardym, w blokach danych o numerach B1 i B2. Dzięki temu wybierając indeksowane rekor-dy można czytać z dysku tylko wymagane bloki danych, ograniczając powolne operacje dyskowe (operacje I/O). Indeksy wykorzystywane są głów-nie w zapytaniach typu SELECT z klauzulą WHERE oraz przy złączeniach tabel.

W praktyce zrealizowane jest to tak, że każdy re-kord w bazie danych ma przypisany unikalny iden-tyfikator wiersza w tabeli, tzw. RowId. Równocze-śnie wartość RowId jest wskazaniem kolejno do pli-

ku danych, bloku danych i pozycji tego rekordu w bloku danych. W indeksie zapamiętany jest wła-śnie ten RowId. Przez to dostęp do rekordu zloka-lizowanego przez indeks jest bardzo szybki i efek-tywny. Dodatkowo, jeżeli zapytanie SQL wymaga tylko pól zawartych w indeksie, czytanie plików danych może okazać się zbyteczne, ponieważ wy-starczyć może informacja zawarta w indeksie.

Najpopularniejsze typy indeksów (różniące się algorytmem działania) to:

• B-Tree, domyślny typ indeksu, najefektyw-niejszy przy wysoce selektywnych danych jak klucze główne i obce. Używany także, gdy indeks obejmuje kilka pól w tabeli;

• Bitmap, stosowany do nisko selektywnych danych jak np. płeć. W połączeniu z me-chanizmem kompresji tabeli, umożliwia zwrócenie dużej liczby rekordów przy mi-nimalnym odczycie z dysku. Indeks może być szczególnie wydajny przy zapytaniach typu COUNT(), gdzie wystarczyć może tyl-ko odczyt danych z samego indeksu (bez czytania danych tabeli).

Kiedy stosować indeksy?Zastosowanie indeksowania daje najlepsze rezul-taty przy wybieraniu małej liczby rekordów z du-żego zbioru. Wtedy najlepiej widać korzyść z ogra-niczenia ilości bloków danych, które muszą zo-stać odczytane z dysku. Zwykle przyjmuje się, że indeks jest opłacalny, gdy z tabeli czytane jest nie

więcej niż około 15% rekordów. Indeksy odgrywa-ją także istotną rolę przy zapytaniach ze złączenia-mi tabel. W typowych aplikacjach biznesowych indeksuje (B-Tree) się zwykle klucze główne i obce. Dla pozostałych pól poszukuje się kompromisu.

Ile kosztuje indeks?Zastosowanie indeksu przyspiesza odczyt da-nych. Spowalnia jednak modyfikowanie danych (INSERT, DELETE, UPDATE), ponieważ wymagana jest odpowiednia aktualizacja informacji w in-deksach. Wg dokumentacji Oracle, utrzymanie jednego indeksu w tabeli, w przybliżeniu trzy-krotnie wydłuża czas operacji modyfikacji da-nych na tej tabeli. Jeżeli tabela zawiera trzy indek-sy to czas modyfikacji danych może być w przy-bliżeniu 9 razy dłuższy w porównaniu z aktuali-zacją tej tabeli bez indeksów. Paradoksalnie, jeże-li aplikacja np. tylko dodaje nowe dane, użycie in-deksów może wręcz spowolnić jej działanie.

Po co w ogóle zapisywać dane na dysk skoro operacja odczytu to wąskie gardło systemu? Po-wody są co najmniej dwa:

• dysk jest znacznie pojemniejszy niż pamięć operacyjna;

• jest to wymóg, aby po awarii zasilania od-tworzyć aktualny i spójny stan danych.

Więzy integralnościJeżeli dane gromadzone w bazie danych mają być poprawne musi istnieć mechanizm, który

Rysunek 3. Schemat przykładowej bazy danych

KLIENT KLIENT_GRUPA GRUPA

Nazwa char

Klient_ID bigint <pk> Grupa_ID

Klient_ID

bigint

bigint

Grupa_ID

Nazwa

bigint

char

<pk>

Rysunek 2. Schemat znormalizowany do trzeciej postaci normalnej

PRODUCENT

IdZabawki NazwaZabawki IdProducenta

1

2

3

P.H.U. Blok

Kubuś sp. z o.o.

Biker

1

1

2

ZABAWKA

IdZabawki NazwaZabawki IdProducenta

1

2

3

4

Klocki

Lalka

Rower

Piłka

1

2

2

3

KRAJ

IdKraju NazwaKraju

1

2

Polska

Francja

09/200824



będzie tą poprawność kontrolował. Dane moż-na sprawdzać na poziomie aplikacji użytkow-nika (często stosowane jako uzupełnienie) lub bezpośrednio w bazie danych, definiując odpo-wiednie reguły.

Co dają więzy integralności?Podstawowym zadaniem więzów integralno-ści (ang. integrity constraints) jest wymuszenie przestrzegania narzuconych reguł poprawno-ści danych. Tak więc nie są one narzędziem do przyspieszania aplikacji. Stanowią jednak istot-ny element wydajności w rozumieniu szer-szym. Wydajna baza danych to również taka, która działa pewnie i broni się przed logicznie niespójnymi informacjami. Ograniczenia zde-finiowane bezpośrednio na bazie danych, po-zwalają bezpiecznie podłączać do źródła da-nych różne systemy. Gdy ograniczenie zadziała, do aplikacji wysyłany jest wyjątek, który moż-na odpowiednio obsłużyć. Typowe zadania wię-zów integralności to:

• ochrona powiązań (referencji) między ta-belami;

• podstawowa walidacja danych wpisywa-nych do danego pola w tabeli (np. określe-nie zakresu dopuszczalnych wartości).

Ile kosztują więzy integralności i kiedy je stosować?Jakkolwiek istnienie w bazie danych więzów in-tegralności narzuca pewne koszt można przy-jąć, że w typowej aplikacji biznesowej ich stoso-wanie jest nieodzowne.

WyzwalaczeCzasem może zaistnieć potrzeba wykonania ja-kiejś dodatkowej czynności w trakcie edycji da-nych w tabeli. Przykładowo może być konieczne, aby każdą zmianę danych w tabeli odnotowywać w osobnym dzienniku (tabeli).

Co dają wyzwalacze?Podstawowym zadaniem wyzwalaczy (ang. trig-gers) jest wykonanie dodatkowego kodu na sku-

tek edycji danych w tabeli. Załóżmy, że wykona-na jest operacja:

UPDATE KLIENT SET KRAJ=2 WHERE KOD=’PL’

Zmodyfikowane zostaną wszystkie wiersze spełniające zadany warunek. Ważne jest, że tworząc wyzwalacz można określić jak ma być uruchomiony, tj:

• CREATE TRIGGER ... kod wyzwalacza będzie wykonany tylko jeden raz dla całej operacji UPDATE

• CREATE TRIGGER ... FOR EACH ROW... kod wyzwalacza będzie wykonany dla każde-go modyfikowanego rekordu osobno, tzn. wszędzie gdzie KOD=’PL’ Ile kosztują wy-zwalacze i kiedy je stosować?

Tworząc wyzwalacz należy pamiętać, że jego kod będzie wykonany dla każdej, powiązanej z tym wyzwalaczem operacji na danych. W typowych aplikacjach biznesowych wyzwala-cze stosowane są często ze względu na ich uży-teczność. Zwykle do utrzymania bardziej zło-żonych więzów integralności lub reguł bizne-sowych.

TransakcjaNieodzownym składnikiem typowego SZBD jest transakcja, czyli niepodzielny zbiór opera-cji na bazie danych. Cała transakcja może być zatwierdzona (COMMIT) lub wycofana (ROLL-BACK). Wszystkie operacje w bazie danych wy-konywane są w ramach jakiejś transakcji. Sama transakcja nie jest narzędziem optymalizacji, natomiast może mieć na nią wpływ.

Ile kosztuje transakcja?Co do kosztów należy głównie pamiętać, że:

• zatwierdzenie transakcji (COMMIT) zmusza SZBD do utrwalenia dokonanych zmian, czyli zapis na dysk;

• odwlekanie zatwierdzenia transakcji zmu-sza SZBD do utrzymywania rosnącego

zbioru oryginalnych wartości danych, na wypadek wycofania zmian (ROLLBACK).

W praktyce, zakres transakcji zwykle wymusza logika biznesowa systemu, a nie względy optyma-lizacji. Jedynie w przypadkach wyjątkowych, np. aktualizacja danych w bardzo dużej tabeli, moż-na rozważyć wykonanie częstszych COMMIT, np. co 200 zaktualizowanych rekordów.

Optymalizacja zapytań SQLPoniższy rozdział ma jedynie na celu zaprezento-wanie wagi optymalizacji zapytań SQL. Dokład-ny opis zagadnienia to materiał na książkę. Na początek wyjaśnienie podstawowych zagadnień.

Plan wykonania (ang. execution plan) – aby wykonać zapytanie SQL, SZBD musi je prze-analizować i przygotować tzw. plan zapytania. Plan zawiera dokładny opis użytych indeksów, sposób dostępu do danych z tabeli, sposób i ko-lejność łączenia tabel, uwzględnienie warun-ków z sekcji WHERE. Aby plan wykonania był wydajny, SZBD wykorzystuje tzw. optymaliza-tor zapytań. Analiza wygenerowanego planu to ważny element optymalizacji zapytań.

Optymalizator zapytań (ang. query optimizer) – mechanizm SZBD, którego zadaniem jest wy-generowanie możliwie optymalnego planu wy-konania (o najmniejszym wskaźniku kosztów wykonania zapytania). Domyślnie dla Oracle, optymalny znaczy zużywający najmniej zaso-bów. System Oracle udostępnia mechanizm pod-powiedzi (ang. hints), który pozwala dodatkowo wpływać na działanie optymalizatora. Obecnie dostępne są dwa rodzaje optymalizatora:

• regułowy, bazuje na ustalonych zasadach budowy planu zapytania. Mniej dyna-miczny, ale bardziej przewidywalny w śro-dowisku produkcyjnym (obecnie Oracle odchodzi od tego rozwiązania);

• kosztowy, bazuje na luźniejszych zasadach budowy planu oraz na dostępnych staty-stykach dotyczących tabel, indeksów, itp. Potrafi na bieżąco uwzględniać charak-terystykę przechowywanych danych, ale może być mniej przewidywalny w środo-wisku produkcyjnym.

Należy pamiętać, że mówimy tu o optymali-zacji zapytania SQL głównie w takiej postaci, w jakiej je podano. Właściwe budowanie za-pytań przez użytkownika ma, więc wciąż zna-czenie podstawowe i przebiega następująco:

• przygotowanie lub poprawa zapytania i wygenerowanie planu zapytania;

• analiza planu oraz poszukiwanie operacji czasochłonnych (np. pełny przegląd dużej tabeli);

• opcjonalne uzupełnienie zapytania o pod-powiedzi dla optymalizatora (ang. hints);

• powrót do pkt. 1 aż do osiągnięcia satys-fakcjonującego wyniku.

Optymalizacja zapytań SQL

Planując optymalizację zapytań SQL w systemie Oracle, warto zapoznać się z następującymi te-matami:

• SQLPLUS – narzędzie do wykonywania zapytań SQL (konsola tekstowa);• SQL TRACE, TKPROF – narzędzia do analizy zapytań SQL wykonywanych przez działającą

aplikację.

W Sieci

• ciekawe artykuły dotyczące Oracle – http://www.orafaq.com/,• dokumentacja Oracle 10g XE – http://www.oracle.com/pls/xe102/homepage,• dokumentacja Oracle 10g – http://www.oracle.com/pls/db102/homepage,• dokumentacja Oracle 10g, optymalizacja – http://download.oracle.com/docs/cd/B19306_01/

server.102/b14211/toc.htm

09/200824



Zaprezentowane poniżej przykłady, zreali-zowano przy pomocy programu SQL Com-mands. Jest on udostępniony razem z ca-łym panelem zarządzania Oracle Database Express Edition. Posiada zakładkę Explain, prezentującą zestawienie szczegółów wyko-nania zapytania. Z kolumny Koszt (ang. Cost) odczytać można koszt wykonania bieżącego zapytania.

Optymalizacja SQL, przykład 1Rozpatrzmy następujący przykład. Jest tabela KLIENT z 5 0 000 rekordów oraz tabela KLIENT_GRUPA z 50 rekordów. Klient może należeć do wielu grup. Do danej grupy może należeć wie-lu klientów (Rysunek 3).

Tworzymy zapytanie SQL, którego celem jest wypisanie klientów, którzy należą do więcej niż jednej grupy.

Na Listingu 1. pokazano przykład nieopty-malnego zapytania SQL. Odczytany koszt wy-konania powyższego zapytania wynosi 1572.

Problem w tym zapytaniu polega na ty, że tabela KLIENT ma dużo rekordów i pełni ro-lę tabeli zewnętrznej. Równocześnie wystę-puje tu podzapytanie skorelowane, tzn. od-wołujące się do rekordów z tabeli zewnętrz-nej KLIENT.

knt_grp.klient_id = knt.klient_id.

Powoduje to, że osobno dla każdego rekordu z tabeli KLIENT (50 000 rekordów) należy wykonać podzapytanie skorelowane. A więc dużą ilość razy system musi czytać małe por-cje danych z dysku. To tak jakby na zakupach biegać po każdą rzecz osobno, zamiast napeł-niać koszyk. Tak więc w tym przypadku po-dzapytanie skorelowane, okazało się nieko-rzystne. Oczywiście mechanizmy wbudowa-

ne, jak buforowanie danych, mogą w pew-nym stopniu zniwelować niekorzystny efekt.

Na Listingu 2. to samo zapytanie w wersji poprawionej. Odczytany koszt wykonania po-wyższego zapytania wynosi 54.

Optymalizacja SQL, przykład 2Kolejny przykład zaprezentuje efektywność in-deksu. Załóżmy, że na tabeli KLIENT założony jest indeks na polu NAZWA. Szukamy klienta, któ-ry w swojej nazwie na początku lub końcu zawie-ra słowo SKLEP. Należy pamiętać, że indeks na polu tekstowym analizowany jest od pierwsze-go znaku tekstu, i dalej poprzez kolejne znaki. Poniżej przykład zapytania SQL (indeks nie bę-dzie użyty):

select * from klient

where

nazwa like '%SKLEP'

Odczytany koszt wykonania powyższego za-pytania wynosi 205. SZBD nie mógł użyć in-deksu, ponieważ co prawda, nazwa klienta musi kończyć się słowem SKLEP, ale zaczynać się może od dowolnych znaków (a więc pierw-sze znaki nazwy są nieokreślone). Spowodo-wało to, że konieczny był odczyt pola NAZWA z całej tabeli KLIENT.

Poniżej przykład zapytania SQL (indeks bę-dzie użyty):

select * from klient

where

nazwa like 'SKLEP%'

Odczytany koszt wykonania powyższego za-pytania wynosi 4. SZBD mógł użyć indeksu za pola NAZWA , ponieważ narzucono warunek na pierwsze znaki z nazwy klienta. Pozwoliło to znacząco obniżyć koszt tego zapytania, ponie-waż system odczytał tylko wymagane rekordy z tabeli KLIENT.

Otrzymane wyniki mogą się nieco różnić, za-leżnie od wersji Oracle, ilości i rodzaju przetwa-rzanych danych, itp.

Kiedy stosować optymalizację zapytań SQL?W praktyce, optymalizacja wszystkiego nie ma sensu. Optymalizuje się przede wszystkim za-pytania SQL:

• powiązane z kluczowymi i najczęściej uży-wanymi funkcji systemu;

• uruchamiane przez wielu użytkowników lub wielokrotnie w pętlach.

Inne mechanizmy optymalizacjiCzęsto SZBD oferuje dodatkowe możliwości optymalizacji danych, niezwiązanych bezpo-średnio z koncepcją bazodanową. Również sys-tem Oracle oferuje takie udogodnienia. Przy-kłady poniżej.

Kompresja danychKompresji danych może obejmować całą prze-strzeń tabel lub wybrane tabele. Głównym ce-lem kompresji jest ograniczenie ilości danych czytanych bezpośrednio z dysku, co jak wiado-mo jest operacją czasochłonną.

Mechanizm ten działa w sposób następujący. W bloku danych, przechowującym dane tabe-li, wszystkie powtarzające się dane zastępowa-ne są skróconym ciągiem. Oryginalna wartość zapisywana jest tylko raz. Takie podejście spra-wia, iż skompresowany blok danych jest bardzo podobny to zwykłego bloku i stosunkowo szyb-ki do odtworzenia.

Zastosowanie kompresji daje najlepsze rezul-taty w systemach, obciążonych częstym odczy-tywaniem dużych ilości danych z dysku. Oczy-wiście większa powtarzalność danych daje lep-szy współczynnik kompresji.

Widok zmaterializowanyMechanizm widoku zmaterializowanego ma szerokie zastosowania. Ze względu na wydaj-ność, jego główny cel to przyspieszenie zapytań SELECT odwołujących się do obszernych i wy-magających agregacji (uogólnienia) źródeł da-nych. Przykładem może być zestawienie mie-sięcznych obrotów budowane na podstawie wszystkich operacji sprzedaży.

Ze względu na sposób użycia, widok zma-terializowany jest podobny do tabel czy zwy-kłych widoków. Może on jednak przechowy-wać w sobie gotowy wynik czasochłonnego za-pytania. Dzięki temu pisząc SELECT ... FROM {nazwa widoku zmaterializowanego} uzysku-jemy szybki dostęp do gotowych, odpowiednio spreparowanych danych. Dodatkowo widok zmaterializowany potrafi automatycznie kon-trolować swoje tabele źródłowe i odpowiednio uaktualniać się.

PodsumowanieOptymalizator zapytań, buforowanie danych, analiza statystyk, domyślna konfiguracja, itd, to wszystko już działa w tle. W systemach małej skali, w zasadzie zapewnia to odpowiednią wy-dajność, bez dodatkowych zabiegów.

W systemach dużej skali, jak fabryka, hur-townia, laboratorium wydajność jest bardzo ważna, chwilami pierwszoplanowa. Dodatko-wo jest to proces ciągły, powiązany z ewolu-cją środowiska produkcyjnego. Zadaniem ad-ministratora jest optymalizacja tego środowi-ska, a zadaniem programisty jest dostarczanie wydajnych komponentów w postaci modułów programu. Temat wydajności pojawia się więc na każdym etapie życia projektu.

MAREK KROKIEWICZAutor jest programistą w firmie P.I. KAMSOFT. Zaj-

muje się tworzeniem informatycznych systemów

zarządzania dla przedsiębiorstw.

Kontakt z autorem: [email protected]

Listing 1. Nieoptymalne zapytanie SQL

select knt.klient_id, knt.nazwa

from klient knt

where

exists (

select knt_grp.klient_id

from klient_grupa knt_grp

where knt_grp.klient_id =

knt.klient_id

group by klient_id

having count(*) > 1

)

Listing 2. Poprawione zapytanie SQL

select knt.klient_id, knt.nazwa

from klient knt, klient_grupa knt_grp

where

knt.klient_id = knt_grp.klient_id

group by knt.klient_id, knt.nazwa

having count(*) > 1

09/200826

Bazy danych Wykorzystanie narzędzi Embarcadero


W połowie maja 2008 roku świat kom-puterowy zelektryzowała wiado-mość o sprzedaży przez firmę Bor-

land grupy CodeGear. Nowym właścicielem pro-duktów takich jak: Delphi, C++ Builder, Interbase i JBuilder jest firma Embarcadero. Do tej pory fir-ma Embarcadero oferowała szeroki wachlarz roz-wiązań dla osób zajmujących się bazami danych (architektów danych, administratorów, programi-stów), a więc podobnego kręgu odbiorców, co gru-pa CodeGear. Jak mówią sami przedstawiciele fir-my, programowanie aplikacji i baz danych to dwie strony tej samej monety, a obydwa obszary są za-zwyczaj obsługiwane przez te same osoby. Po zapo-znaniu się z narzędziami Embarcadero pierwszą rzeczą, która rzuca się w oczy jest ich ukierunko-wanie na osobę, a dokładniej na rolę pełnioną w ze-spole. Propozycją dla administratorów baz danych jest DBArtisan, architektom firma oferuje narzę-dzie ER/Studio, a z kolei dla osób zajmujących się kodowaniem oraz logiką biznesową w bazach inte-resujacą propozycją jest RapidSQL. Wszystkie na-rzędzia z oferty firmy Embarcadero są specjalizo-wane i mają służyć konkretnej grupie informaty-ków do łatwej pracy w ich głównym obszarze za-dań. Zarazem specjalizacja nie oznacza zawężenia funkcjonalności, ponieważ typowe zadania moż-na wykonywać za pomocą wszystkich narzędzi. Przykładowo procedurę składowaną można utwo-rzyć przy użyciu każdego z wymienionych progra-mów, przy czym program RapidSQL posiada do-datkowo rozbudowane analizatory składni, dzia-

łające nawet bez połączenia z serwerem bazy da-nych. Drugą istotną zaletą narzędzi Embarcade-ro jest możliwość pracy z różnymi serwerami baz danych. Jedno narzędzie obsługuje wiele serwe-rów baz danych, zaczynając od platform komer-cyjnych, takich jak Oracle, DB2, MS SQL Server, Sybase ASE, a kończąc na darmowych jak Fire-bird, czy MySQL. Dla osób pracujących z wieloma serwerami baz danych stanowi to bardzo wygod-ne rozwiązanie, dzięki wykluczeniu konieczności poznawania i pracowania z różnymi narzędziami, specyficznymi dla każdego z typów serwerów. Wy-mienione rozwiązania są sztandarowymi produk-tami Embarcadero, więc właśnie im się przyjrzyj-my na przykładzie praktycznych zagadnień.

Administracja z DBArtisan Wyobraźmy sobie następującą sytuację: pewne-go dnia w kilku oddziałach banku nie można do-

konać przelewów, a niektórym klientom banko-maty odmawiają wypłaty gotówki pomimo po-siadanych przez nich środków. Klienci są infor-mowani o chwilowej przerwie w pracy systemu, zaś informatycy gorączkowo starają się zdiagno-zować i usunąć problem. Powodem takiej kry-tycznej sytuacji może być działanie któregoś z użytkowników bazy danych, który zmienia-jąc dane nie zakończył transakcji powodując za-blokowanie zmienionych danych. Na potrzeby połączenia aplikacji użytkownika baza danych tworzy proces obsługujący to połączenie. Pro-ces wykonuje kolejne instrukcje i zakłada blo-kady na aktualnie wykorzystywane dane. Dopó-ki transakcja nie zostanie zakończona (tj. nie zo-stanie wykonane polecenie COMMIT lub ROL-LBACK), inne procesy nie mogą zmieniać za-blokowanych danych. Nie jest możliwe wtedy na przykład zmodyfikownie stanu konta, co jest przecież warunkiem niezbędnym do dokonania przelewu, czy wypłaty gotówki w bankomacie.

Przed taką sytuacją trudno się zabezpieczyć. Do problemu może doprowadzić nawet niepra-widłowe zamknięcie aplikacji, nieodpowiednio napisane oprogramowanie lub nadmiar upraw-

Inżynieria baz danych

Programowanie aplikacji i baz danych to dwie strony tej samej monety. Firma Embarcadero, specjalizująca się do tej pory w rozwiązaniach dla baz danych, poszerzyła swoją ofertę o narzędzia dla programistów poprzez przejęcie od firmy Borland grupy CodeGear (Delphi, JBuilder). Przyjrzyjmy się zatem, co firma Embarcadero ma do zaoferowania w swojej dotychczasowej dziedzinie.

Dowiesz się:• Jak narzędzia mogą pomóc w pracy administra-

tora, architekta oraz programisty baz danych.

Powinieneś wiedzieć:• Podstawowe wiadomości na temat baz danych.

Poziom trudności

Wykorzystanie narzędzi Embarcadero

Rysunek 2. DBArtisan – zakładka Processes

Rysunek 1. DBArtisan – zakładka Blocking Lock

09/200826



nień użytkownika w stosunku do jego wiedzy. Jeśli mamy do czynienia z aplikacją do fakturo-wania, wtedy problem trzeba rozwiązać szybko. Jeśli dotyczy systemów finansowych, to trzeba go rozwiązać natychmiast. Skorzystajmy z unika-towej funkcjonalności programu DBArtisan do wykrywania blokujących się procesów i błyska-wicznie rozwiążmy problem.

Na potrzeby tego przykładu użyjemy SQL Se-rver 2005 Express Edition wraz z przykładową bazą Northwind oraz standardowej konsoli SQL Server Management Studio Express. Do wygene-rowania sytuacji testowej wykorzystamy specjal-nie napisany program, który po otwarciu transak-cji modyfikuje dane i nie zakończy transakcji. Na-stępnie spróbujemy dokonać zmian tych samych danych z poziomu konsoli. Zgodnie z oczekiwa-niami Management Studio nie może wykonać in-strukcji UPDATE i pozostaje w stanie oczekiwania wyświetlając komunikat Executing query.

Po uruchomieniu programu DBArtisan i za-logowaniu do serwera „rozwijamy” jego zakład-ki przechodząc do sekcji odpowiedzialnej za wy-dajność (Performance). Sekcja Performance po-zwala obserwować procesy (Processes) oraz zało-żone przez nie blokady (Locks), w tym najistot-niejsze dla nas w tym przypadku blokady, któ-re uniemożliwiają pracę innym procesom (Bloc-king locks). Ponieważ szukamy szkodnika, od ra-zu przechodzimy do zakładki Blocking locks, aby sprawdzić wstrzymywane procesy (Rysunek 1). Jak widać na ilustracji, zakładka ta udostępnia szczegółowe dane o blokujących się wzajemnie procesach ID procesu wstrzymującego i wstrzy-mywanego, nazwy użytkowników tych proce-sów, bazę danych oraz obiekty, których sytuacja konfliktowa dotyczy. Od razu widzimy, że proces nr 54 użytkownika BLOK wstrzymuje proces nr 55 użytkownika SA, a obydwa procesy odwołują się do bazy Northwind. Chcąc dokładnie ziden-tyfikować proces wstrzymujący korzystamy z za-kładki Processes, która udostępnia szczegółowe da-ne o procesach, takie jak ID procesów, ich statusy, użytkowników za nie odpowiedzialnych, nazwy lub adresy IP komputerów z których nawiązano połączenia, typ aktualnie wykonywanej komen-dy, a w niektórych przypadkach nazwę programu użytego do połączenia (Rysunek 2). Warto wspo-mnieć, że mówimy o procesach bazy danych wy-

generowanych przez bazę na potrzeby obsługi po-łączeń użytkowników. Ponieważ DBArtisan ob-sługuje równocześnie wiele rodzajów baz danych, to na przykład dla bazy DB2 z racji jej budowy bę-dziemy mówić o wątkach, a nie procesach. Za-kładki przy podłączeniu programu DBArtisan do DB2 wyglądają nieco inaczej, ale posiadają iden-tyczną funkcjonalność.

Szybka analiza zakładki Processes (Rysunek 2) pozwala stwierdzić, że kłopotliwy proces nr 54 użytkownika BLOK pochodzi z komputera TO-SHIBAA80 i w chwili obecnej oczekuje na po-lecenie (Awaiting command). Oczekujący pro-ces nr 55 użytkownika SA ma status wstrzyma-ny (Suspended), a ostatnią komendą, jaką próbo-wał wykonać było polecenie UPDATE. Jeśli chcie-libyśmy uzyskać dokładniejsze informacje o blo-kadach, które założyły obydwa procesy, możemy skorzystać z zakładki Locks.

Mając wszystkie informacje o procesie blo-kującym przetwarzanie możemy skontaktować się z konkretnym użytkownikiem, a jeśli oceni-my jego proces za niezbyt ważny, od razu termi-nować ten proces poleceniem KILL. Po usunię-ciu procesu nr 54 Management Studio realizu-je w końcu swoje polecenie UPDATE. Po odświe-żeniu zakładek DBArtisana widzimy, że zniknę-ły wszystkie blokady – rozwiązaliśmy problem, bankomaty działają!

Modelowanie danych z ER/StudioPewnego dnia otrzymujemy polecenie dołoże-nia nowej funkcjonalności do istniejącej bazy da-nych. Dowiadujemy się, że nie ma aktualnej spe-cyfikacji dla naszej bazy. Istniejącą dokumenta-cję kierownik projektu wręcza nam z lekkim za-kłopotaniem, bo ostatnia aktualizacja tego doku-mentu odbyła się pięć lat temu. Dokumentacja jest nam niezbędna do pracy z klientem i progra-mistami, dlatego najpierw musimy ją stworzyć.

W praktyce tego typu problemy z dokumen-tacją zdarzają się w wielu firmach. Sprawdźmy, jak łatwo możemy uzyskać dokumentację ist-niejącej bazy danych za pomocą programu ER/

Studio. W programie ER/Studio uruchamiamy funkcję New data model, a następnie wybieramy Reverse engineer an existing database.

Mamy dwie metody dostępu do baz danych – natywny i poprzez sterowniki ODBC. W sposób natywny są obsługiwane serwery – IBM DB2, MS SQL Server, Oracle i Sybase ASE, a posiadając ste-rowniki ODBC możemy pracować z innymi baza-mi danych jak chociażby Interbase, Firebird czy MySQL. W przypadku połączeń natywnych two-rzona dokumentacja będzie zawierała wszystkie typy obiektów dostępne w bazach danych, włącz-nie z specyficznymi dla danego serwera, takimi jak choćby tablespaces, packages, rollback segments czy sequences dla serwerów Oracle. Przy zastoso-waniu połączeń ODBC liczba rozpoznawanych typów obiektów zależy od jakości sterownika. Wszystkie obecnie używane sterowniki ODBC pozwalają nam na utworzenie podstawowej struk-tury danych (tabele, widoki, relacje, itp.).

Po wskazaniu bazy danych pojawia się okno, w którym możemy wybrać, jakiego typu obiek-ty chcemy odczytać z bazy danych. Do wyboru mamy wszystkie typy obiektów znajdujące się w bazie włącznie z tabelami systemowymi. Do-datkowo dla każdego obiektu możemy zdecy-dować, czy ma zostać uwzględniony przy two-rzeniu modelu czy też nie. Istnieje więc możli-wość ustawienia zakresu obiektów do odczytu z dokładnością do każdego obiektu, a nie tylko do typu obiektów.

Po określeniu zakresu prac reinżynieryjnych (ang. reengineering) (Rysunek 3) generujemy mo-del bazy danych (Rysunek 4). Najpierw tworzo-ny jest model fizyczny, który w wybranym wcze-śniej zakresie jest wiernym odwzorowaniem ba-zy danych. Model ten zawiera obiekty z bazy ta-kie jak tabele, procedury składowane, użytkowni-ków, uprawnienia, itp. Typy obiektów, jakie znaj-dują się w modelu fizycznym są zależne od bazy danych, dla której ten model jest dedykowany. Rozbudowane edytory obiektów pozwalają na graficzne modelowanie właściwości obiektów. Na rysunku 5 przedstawiono widok edytora ta-

Rysunek 3. ER/Studio – wybór typów obiektów podczas reinżynierii Rysunek 4. ER/Studio – model danych

09/200828



bel dla tabeli Employees. Za pomocą edytora ta-bel możemy modyfikować nie tylko podstawowe cechy tabel wynikające ze składni SQL samej ta-beli (kolumny, typy danych, klucze obce, indek-sy), ale także inne obiekty wymagające dodatko-wych poleceń SQL (uprawnienia użytkowników dotyczące tej tabeli, powiązania z procedurami składowanymi, triggery, statystyki danych, itp.). Dzięki takiemu ukierunkowaniu modelu fizycz-nego możemy bezpośrednio z niego generować skrypty SQL tworzące bazę danych.

Na podstawie modelu fizycznego automa-tycznie generowany jest model logiczny. Model logiczny jest modelem ogólnym i nie jest zdeter-minowany typem serwera SQL. Z tego modelu logicznego możemy generować modele fizycz-ne dla różnych typów baz danych. Jest to bar-dzo przydatna funkcjonalność podczas migra-cji bazy danych pomiędzy serwerami różnych producentów.

Program ER/Studio przedstawia w sposób graficzny strukturę bazy danych, prezentu-jąc na diagramie wszystkie obiekty i powiąza-nia pomiędzy nimi. Utworzone modele moż-

na modyfikować, a zmiany modelu fizycznego możemy od razu nanosić na bazę danych.

Na podstawie modelu możemy utworzyć dokumentację. W tym celu z menu Tools wy-bieramy Generate reports i ustalamy zakres da-nych, które chcemy umieścić w dokumentacji. Możemy wybrać format HTML, lub RTF, kata-log docelowy oraz bardzo szczegółowo określa-my zakres obiektów, a nawet cech obiektów do umieszczenia w dokumentacji.

Tak duża możliwość wybierania zakresu wszel-kich prac z obiektami baz danych w ER/Studio jest wielką zaletą tego programu. Zakładkowa bu-dowa okien do wyboru obiektów sprawia, że po-mimo tak rozbudowanych możliwości, obsługa programu jest prosta. Możliwość określania za-kresu z dokładnością do pojedynczego obiektu jest bardzo ważna podczas reinżynierii, generacji skryptu SQL czy tworzenia dokumentacji.

Dodatkowymi danymi do wprowadzenia są in-formacje o dokumentacji, czyli nazwa dokumen-tacji, autor, firmowe logo, itp. Po generacji otrzy-mujemy dokumentację w wybranym formacie wyglądającą jak model w ER/Studio (Rysunek 6).

W powyższy sposób, używając dwóch funkcji ER/Studio, odtworzyliśmy szczegółowy model bazy danych i wygenerowaliśmy na jego podsta-wie dokumentację w HTML-u.

Tworzenie kodu bazodanowego z RapidSQLW ramach kontynuacji poprzedniego zadania otrzymaliśmy polecenie utworzenia widoku (View) jako źródła danych raportu dla progra-misty. Szczegóły widoku takie jak lista kolumn, sposób grupowania, oraz wyświetlania ustalamy z programistą. Wiadomo, że najlepiej pracuje się z obrazem, więc na spotkanie zabieramy wyge-nerowaną w poprzednim zadaniu dokumenta-cję. Zamiast tracić czas i energię na ręczne prze-pisywanie ustaleń ze spotkania, wszystkie infor-macje z łatwością przełożymy na instrukcję SQL przy pomocy modułu Query Builder dostępne-go w programie RapidSQL.

Program RapidSQL jest przeznaczony do tworzenia i analizy kodu obiektów bazodano-wych (np. procedur składowanych, wyzwala-czy, instrukcji DDL) oraz pracy ze skryptami. W przykładzie użyjemy podprogramu Query Buil-der, który służy do wizualnego budowania zło-żonych instrukcji SQL.

Podczas tego zadania posłużymy się bazą Nor-thwind umieszczoną na serwerze Oracle. Baza ta jest wynikiem migracji pomiędzy serwerami MS SQL Serwer i ORACLE. Migracji tej z braku miej-sca tutaj nie pokażę, nie jest ona zreszta skompli-kowana – wykorzystałem model utworzony w poprzednim przykładzie i na jego podstawie stworzyłem model fizyczny dla bazy Oracle, a na-stępnie wygenerowałem skrypt SQL, który uru-chomiłem na serwerze jako użytkownik HR.

Po uruchomieniu programu RapidSQL z me-nu Tools wybieramy Query builder. Nowo otwar-te okno pozwala nam przeciągać tabele z listy po lewej stronie na część roboczą po prawej. Pro-gram automatycznie pokazuje relacje pomiędzy tabelami na podstawie kluczy obcych oraz po-kazuje listę kolumn w tabelach (Rysunek 5). Po przeciągnięciu tabel zaznaczamy kolumny, które mają znaleźć się w tworzonym zapytaniu. Ponie-waż domyślnie tworzone jest polecenie SELECT, musimy zmieć typ polecenia na VIEW.

Do bardziej zaawansowanej pracy z SQL uży-jemy zakładki DML. Widzimy tu nasze zapyta-nie w postaci drzewa z pogrupowanymi informa-cjami w zakładkach COLUMNS, FROM, WHE-RE, GROUP BY, HAVING, ORDER BY (dla SE-LECT), SET (dla UPDATE), itp. W zakładkach tych można dokonywać zmian w tworzonym za-pytaniu. Zmiany będą automatycznie przenoszo-ne na model graficzny. Jeśli używamy kilku po-wiązanych tabel, klucze obce automatycznie zo-staną przeniesione do klauzuli WHERE, gdzie musimy samodzielnie określić sposób oraz hie-rarchię łączenia warunków (AND, OR i kolejność nawiasów). W zakładce DML możemy także do-dawać nowe warunki, zmieniać domyślny sposób łączenia tabel (na np. LEFT JOIN), a także uży-

O firmieZałożona w 1993 roku Embarcadero Technologies oferuje szeroką gamę międzyplatformowych narzędzi bazodanowych wspierających wszystkie etapy cyklu życia baz danych: modelowanie, tworzenie, optymalizację, administrację, a także wspierających migrację baz danych pomiędzy serwerami SQL. W połowie 2008 roku firma podpisała porozumienie z Borland Software Corpo-ration i przejęła firmę CodeGear, światowego lidera w dostarczaniu narzędzi programistycznych, w tym Delphi, C++Builder iJBuilder. Obecnie Embarcadero łączy i stale rozwija w swojej ofercie rozwiązania z obszaru narzędzi programistycznych i narzędzi bazodanowych, stając się najwięk-szym na świecie niezależnym dostawcą tych rozwiązań. Firma BSC Polska, przedstawiciel firmy Borland jest także przedstawicielem Embarcadero w naszym kraju. Więcej informacji na stronie http://www.embarcadero.com.pl.

Rysunek 5. ER/Studio – edytor tabel

09/200828



wać bardziej zaawansowanych możliwości SQL jak GROUP BY czy HAVING. Dokładny tekst powstałego polecenie SQL widzimy w dolnym oknie, z możliwością edycji w osobnym oknie.

Utworzyliśmy właśnie widok (View) o na-zwie NOWE. Warto jeszcze dla pewności spraw-dzić jego poprawność składni (check syntax). Ta-ki test wykonuje RapidSQL samodzielnie i nie wymaga łączenia z serwerem. Jeżeli jesteśmy podłączeni do bazy danych, to utworzone po-lecenie SQL możemy uruchomić (execute) od razu. Jak widać na Rysunku 5, polecenie SQL używa przedrostków HR (zalogowanego użyt-kownika), co jest niezbędne dla bazy Oracle, ale może stwarzać problemy dla innych typów baz, np. MS SQL Server. Aby dostosować sposób ge-neracji kodu do wymogów serwera SQL użyje-my zakładki Query Builder/Statement Prospe-rites. Możemy tutaj ustawić szereg parametrów, jak chociażby opcje generate owner names, include row count limits.

Zadanie wykonane – dzięki RapidSQL au-tomatycznie utworzyliśmy widok korzystając z graficznej reprezentacji struktury danych.

Dlaczego warto?Przedstawione przykłady to zaledwie znikoma część funkcjonalności omawianych narzędzi. Ich olbrzymią zaletą jest łatwość i intuicyjność obsłu-gi oraz wsparcie wielu typów serwerów baz da-nych. Zadziwiająco łatwo udało mi się dokonać migracji bazy danych Northwind z MS SQL Ser-wer do serwera Oracle Co więcej mogłem porów-nać modele fizyczne dla obydwu baz i upewnić się, że migracja jest kompletna. Kłopotliwe jest używanie wielu programów wykonujących te sa-me funkcje w inny sposób dla różnych baz. Zuni-fikowanie narzędzi do jednego rozwiązania bar-dzo ułatwia pracę oraz ogranicza liczbę aplika-cji, które trzeba poznać i obsługiwać. Znikają od-wieczne problemy typu: wiem jak to zrobić dla DB2, ale jak to się robi w Oracle?

Pomimo iż Embarcadero nie koncentruje się na obsłudze jednego, wybranego typu bazy da-nych, ale dostarcza zintegrowane rozwiązania wspierające wiele rodzajów baz możliwości na-rzędzi Embarcadero w niczym nie ustępują funkcjonalności oferowanej przez narzędzia firm trzecich. Rozwiązania firmy Embarcadero często

uzupełniają standardowe możliwości interesują-cymi funkcjonalnościami, jak chociażby lista za-blokowanych procesów w DBArtisanie wraz z przejrzystym pokazaniem procesów blokujących i blokowanych. Część ułatwiających pracę funk-cjonalności wprowadzono na zgłaszane poprzez firmowy portal sugestie użytkowników.

Portal internetowy Na koniec niniejszego artykułu kilka słów o wspo-mnianym już firmowym portalu internetowym (http://www.embarcadero.com). Oprócz standar-dowych informacji handlowych, promocji oraz możliwości pobrania produktów w wersjach te-stowych (TRIAL) portal oferuje silne wsparcie dla użytkowników. Znajdziemy w nim bardzo dużo materiałów technicznych, włącznie z obszerny-mi dokumentacjami (np. UserGuide dla ERStu-dio – 603 strony). Inną formą wsparcia są fora te-matyczne dotyczące poszczególnych narzędzi, na których dyskusje służą nie tylko wymianie wiedzy pomiędzy użytkownikami, ale również do komu-nikacji ze specjalistami Embarcadero. Fora te od-wiedzają konsultanci techniczni firmy, odpowia-dając na pytania i udzielając porad technicznych. Dodatkowym ciekawym audiowizualnym wspar-ciem są seminaria internetowe (WEBseminaria), przygotowane dema, oraz szczegółowo opisane przykłady użycia poszczególnych narzędzi.

PodsumowanieAnaliza narzędzi Embarcadero wskazuje jedno-znacznie na to, że producentowi zależy na jak naj-większej wszechstronności narzędzi. Dzięki te-mu są one przydatne w firmach, gdzie wykorzy-stuje się wiele serwerów baz danych oraz dokonu-je się migracji pomiędzy różnymi typami plat-form bazodanowych. Rozwiązania Embarcadero rewolucjonizują bowiem sposób pracy z wieloma serwerami, pozwalając użytkownikom na znacz-ne ograniczenie czasu potrzebnego na wykona-nie powierzonych im zadań oraz sprawniejsze ich zrealizowanie. Dostępność dokumentacji oraz konsultantów technicznych znacznie ułatwia po-znawanie narzędzi oraz wykorzystywanie w peł-ni oferowanych przez nie możliwości.

Nastawienie firmy Embarcadero pozwala również spokojnie patrzeć na przyszłość Del-phi. Możemy nawet oczekiwać interesujących efektów synergii produktów CodeGear i Embar-cadero. Pozostaje nam tylko z niecierpliwością oczekiwać na pierwszy po połączeniu plan stra-tegiczny rozwoju produktów (RoadMap).

ANDRZEJ DĄBROWSKIAndrzej Dąbrowski jest trenerem i konsultantem

technicznym BSC Polska. Pełni obowiązki CodeGe-

ar Technical Evangelist w Polsce. Pracował jako kie-

rownik działu oprogramowania zajmującego się

tworzeniem aplikacji bazodanowych. Zajmował się

zarówno tworzeniem baz danych, jak i oprogramo-

wania korzystającego z tych baz. Ukończył Wydział

Cybernetyki Wojskowej Akademii Technicznej.


Rysunek 6. ER/Studio – dokumentacja w HTML

Rysunek 7. RapidSQL – graficzne tworzenie polecenia SQL.

09/200830

Bazy danych

Służby informatyczne stoją przed wyzwa-niem: jak sprostać nieustannie rosnącym potrzebom składowania i dostępu do in-

formacji, w jaki sposób zapewnić adekwatny poziom usług – niezawodność przetwarzania, bezpieczeństwo, wydajność, jak reagować na zmieniające się potrzeby ich organizacji. Jak sprawić, by mimo wciąż rosnących wymagań oraz złożoności systemów, efektywnie wspierać działalność macierzystej organizacji.

Baza danych Oracle 11g to technologia wspierająca klientów w tworzeniu skalowal-nych, bezpiecznych systemów sprawnie do-pasowujących się do zmiennych potrzeb, ja-kie narzuca rynek. W oparciu o trzydzieści lat doświadczeń na polu tworzenia niezawod-nych baz danych, Oracle 11g umożliwia bu-dowę elastycznej, łatwej w zarządzaniu infra-struktury, jaką będziemy mogli prosto, bez-piecznie i planowo dopasować do zmieniają-cych sie wymagań.

Grid ComputingJednym z naczelnych problemów dla służb informatycznych jest koszt tworzenia i za-rządzania niezawodną infrastrukturą. Kor-poracja Oracle jest twórcą i dostawcą unikal-nej technologii, umożliwiającej budowę skalo-walnej, bezpiecznej infrastruktury w oparciu

o koncepcje Grid Gomputing – współdziele-nia zasobów przetwarzania dla efektywniej-szego wykorzystania posiadanej infrastruk-tury oraz zapewnienia maksymalnej nieza-wodności. Koncepcja Grid Computing w im-plementacji Oracle to jedyna na rynku ofer-ta oferująca równocześnie skalowalność syste-mów, wydajność i niezawodność przetwarza-nia, pełne wykorzystanie już posiadanej infra-struktury IT (tak sprzętu jak i licencji na opro-gramowanie).

Oferta Oracle obejmuje wszystkie elementy niezbędne do stworzenia, wdrożenia i zarzą-dzania środowiska Grid – poczynając od war-stwy składowania danych (Automated Storage Management), poprzez infrastrukturę (Orac-le Clusterware), bazę danych (Oracle Real Ap-plication Clusters), serwer aplikacyjny (Orac-le Fusion Middleware), aż do narzędzi zarzą-dzania i monitoringu (Oracle Enterprise Grid Control, wsparty przez specjalizowane rozsze-rzenia Management Packs, oracz System Mo-nitoring Plug-ins). Co jest szczególnie istotne – oferta korporacji Oracle jest nie tylko uni-kalna na rynku, ale także sprawdzona w prak-tyce przez tysiące klientów na całym świecie, poczynając od wielkich korporacji, poprzez organizacje publiczne, systemy policyjne i in-stalacje wojskowe, na małych i średnich syste-mach kończąc.

Oracle 11g jest kolejną wersją niezawodne-go silnika bazy danych, optymalizowaną z my-ślą o szczególnie ważnych systemach wyma-gających najwyższej niezawodności, a także uproszczenia procedur administracyjnych.

Dostęp do danychEfektywny dostęp do informacji znajdujących się w firmowych systemach wymaga sięgnię-cia zarówno do danych dobrze ustrukturalizo-wanych, takich jak relacyjne bazy danych – jak i nieustrukturalizowanych; przyjęło się szaco-wać, iż około 80% informacji znajdujących się w organizacji to dane zapisane poza bazami re-lacyjnymi, w systemach takich jak poczta elek-troniczna, w dokumentach w systemie plików. Jednym z poważniejszych wyzwań stojących przed działem IT jest zapewnienie efektywne-go dostępu do tychże dokumentów, jak też ła-twość konsolidacji danych pochodzących z róż-nych źródeł.

Oracle 11g oferuje szeroką paletę narzędzi pozwalających korzystać ze zróżnicowanych źródeł informacji, pozwalając na konsolidację tak samych informacji – co umożliwia auto-matyzację procesów organizacyjnych, jak też umożliwia implementację zunifikowanego me-chanizmu zarządzania danymi wraz ze spójną polityką bezpieczeństwa i archiwizacji.

Dane nieustrukturalizowaneBaza danych Oracle od lat posiada wzorcowo sprawną implementację składowania i dostę-pu do nieustrukturalizowanych, takich jak pli-ki i multimedia w bazie danych, dane geogra-ficzne (opcja Spatial), dokumenty XML. Orac-le 11g rozbudowuje te możliwości o nowe tech-nologie jak binary XML oraz XML index, ofe-rujące rewelacyjną poprawę wydajności (wedle wewnętrznych testów – do 1500%).

Kolejne usprawnienia wersji Oracle 11g to dostęp do nowych typów danych, takich jak przetwarzanie obrazów zgodnie ze standar-dem DICOM, łatwa implementacja technolo-gii RFID, wsparcie dla analiz i przechowywa-nia danych przestrzennych Spatial (2D, 3D, To-pology, Networking, TIN, Georaster). Znaczą-

Oracle 11g – platforma przetwarzania danych

W trakcie ostatnich lat globalne znaczenie technologii informatycznych stało się faktem – ich powszechne zastosowanie we wszelkich dziedzinach ludzkiej działalności generuje potrzebę równie powszechnego, niezawodnego i łatwego dostępu do wszelkich danych, jakie są przechowywane w rozmaitych systemach.

Dowiesz się:• Co nowego pojawiło się w silniku bazy danych Oracle 11g;

• Jakie nowe opcje są dostępne wraz z bazą Oracle 11g.

Poziom trudności

Przegląd nowych możliwości oferowanych przez bazę Oracle 11g

REKLAMA

09/200832

Bazy danych

cą innowacją jest także możliwość zarządzania dokumentami w systemie plików za pomocą mechanizmów bazy danych (Secure Files), co umożliwia ujednolicenie mechanizmów dostę-pu (bezpieczeństwo informacji!) bez koniecz-ności fizycznej konsolidacji danych.

Zintegrowana analiza danychWzrastająca waga i ilość danych w bazach pocią-ga za sobą rosnące zapotrzebowanie na dostęp do informacji, tak historycznych jak i bieżących. Użytkownicy oczekują wydajnych mechani-zmów pozwalających na odczyt i analizę dużych zbiorów danych. Wychodząc naprzeciw tym po-trzebom i oczekiwaniom, korporacja Oracle po-siada znakomite narzędzia (takie jak OLAP, Da-ta Mining), silnie zintegrowane z motorem bazo-danowym oraz jego możliwościami analityczny-mi (możliwości PLSQL, materialized views).

Oracle 11g rozbudowuje te możliwości o no-wą funkcjonalność – Cube-organized materia-lized views, unikalną kombinację pozwalającą na wykorzystanie posiadanych systemów, apli-kacji i umiejętności do odczytu danych z bazy wielowymiarowej, z pełną szybkością oferowa-ną przez OLAP. Kolejne innowacje to nowy al-gorytm i sprawniejsze zarządzanie modelami Data Mining,

Te właściwości, wspierane przez kolejne na-rzędzia z oferty korporacji (Oracle Warehouse Builder, Oracle Data Integrator) tworzą kom-pletną, zunifikowaną infrastrukturę dla two-rzenia i zarządzania hurtowniami danych i ba-zami analitycznymi.

Zarządzanie dużą ilością danychSzybko wzrastająca ilość informacji przechowy-wanych w systemach jest coraz większym wy-zwaniem dla służb informatycznych. Korpora-cja Oracle od lat wspiera klientów w efektyw-nym zarządzaniu dużymi bazami danych, dzię-ki innowacyjnym i wydajnym możliwościom oferowanym w ramach opcji partycjonowania danych (Partitioning).

Oracle 11g przynosi znaczące nowości w technologii partycjonowania, oferując nowe sposoby partycjonowania (Interval – automa-tyzujący zarządzanie partycjami w oparciu o predefiniowane reguły oraz REF partitioning wspierający implementację jednolitego party-cjonowania tabel połączonych relacjami).

Uzupełnieniem mechanizmów partycjono-wania jest nowy mechanizm kompresji danych, oferowany jako opcja bazy danych (Compres-sion) – całkowite przezroczysta dla istniejących mechanizmów dostępu do danych.

Zarządzanie cyklem życia danychInformation Lifecycle Management (ILM, zarzą-dzanie cyklem życia danych) to metodyka skon-centrowana na redukcji kosztów infrastruktu-ry przy zachowaniu niezbędnej jakości dostę-pu do danych. ILM opiera się o idee logicznego podziału danych wedle kryteriów dostępności (najczęściej używane dane – bieżące, versus da-ne historyczne, niemodyfikowane i rzadziej od-czytywane).

Zastosowanie technologii partycjonowa-nia oraz kompresji umożliwia daleko sięgają-ce oszczędności w infrastrukturze, co nabie-ra szczególnego znaczenia przy dużych wolu-menach danych i urządzeniach pamięci maso-wej, pozwalając na optymalizację warstwy skła-dowania danych przy daleko idącej (wedle na-szych szacunków – do 94%) redukcji kosztów. Wsparciem tu może być nowe narzędzie – Par-titioning Advisor, upraszczające pracę admini-stratorów bazy.

Najwyższy poziom dostępnościZnakomita większość kosztów utrzymania in-frastruktury IT obraca się wokół zapewnienia bezpieczeństwa, niezawodności i efektywności przetwarzania danych. Implementacja koncepcji Grid Computing dzięki technologii Real Appi-cation Clusters jest unikalną na rynku propozy-cją – co ważniejsze sprawdzoną w codziennym użytkowaniu przez tysiące klientów, uzupełnia-ną przez znaczące innowacje tak w silniku bazy danych jak i specjalizowanych opcjach wspiera-jących wysublimowane możliwości ochrony da-nych, tak w samej bazie jak i poza nią.

Nowością w bazie danych Oracle 11g jest opcja Oracle Total Recall, umożliwiająca imple-mentację repozytorium zmian w danych (histo-ria zmian). Opcja Oracle Total Recall wraz z no-wym modułem SQL Recovery Advisor umożli-wiają także szybki dostęp do danych historycz-nych (stan sprzed zmian).

WydajnośćBaza Oracle od lat dzierży palmę pierwszeń-stwa w testach wydajnościowych, wyznaczając poziom odniesienia dla innych silników bazo-danowych. Wersja Oracle 11g przynosi znaczą-ce usprawnienia i optymalizacje podnosząc po-przeczkę jeszcze wyżej. Znaczące optymalizacje samego to nowe mechanizmy kompilacji zapy-tań (Native Compilers), nowy mechanizm bu-forowania danych (Client-side result caching). Daleko idące usprawnienia zostały wprowadzo-ne także do Real Application Clusters (Oracle RAC), poprawiając wydajność zapytań do 70%.

Usprawniona diagnostyka (Oracle Automatic Database Diagnostic Monitor) pozwala teraz na szczegółową analizę wydajności Oracle RAC.

BezpieczeństwoBezpieczeństwo jest podstawowym wymaga-niem dla systemów naszych klientów – wspomi-nając pierwsze, historyczne wdrożenia dla klien-tów (służby wywiadowcze, wojsko). Wychodząc naprzeciw zapotrzebowaniu klientów oraz wy-maganiom prawnym (SOX, Basel II, PCI) korpo-racja Oracle oferuje kompletny pakiet technolo-gii pozwalających na stworzenie kompleksowe-go, wielowarstwowego systemu zabezpieczeń w przedsiębiorstwie – poczynając od systemów za-rządzania tożsamością (Identity Management), poprzez elastyczne technologie Middleware aż do wysublimowanych technologii zabezpieczeń bazy danych.

Dla bazy Oracle 11g oferujemy szeroką paletę możliwości zabezpieczania dostępu do informa-cji, oprócz standardowych mechanizmów uwie-rzytelniania i autoryzacji opartych o hasło (do-datkowa autoryzacja – Secure Application Ro-les, selektywny dostęp do poszczególnych wier-szy – Virtual Private Database, szczegółowy au-dyt – Fine Grained Auditing). Tym uzupełnie-niem są technologie Oracle Secure Backup (za-bezpieczenie nośników kopii zapasowej), Orac-le Database Vault (umożliwia wprowadzenie separacji uprawnień oraz implementację szcze-gółowej polityki bezpieczeństwa w oparciu o wielostopniowe uwierzytelnienie). Uzupełnie-niem dla powyższych są technologie Oracle Au-dit Vault (dedykowana składnica zdarzeń, moni-toring w oparciu o reguły) oraz Oracle Advan-ced Security (całkowicie przezroczyste dla apli-kacji szyfrowanie danych w bazie oraz w czasie transmisji).

Efektywne zarządzanie zmianamiElastyczna infrastruktura informatyczna umoż-liwia lepsze dostosowanie systemów do potrzeb organizacji, stawiając jednak przed służbami in-formatycznymi istotne wyzwania przy imple-mentacji tychże zmian. W szczególności moż-liwość bezpiecznego – planowego – testowania i wprowadzania zmian w infrastrukturze (tak w warstwie oprogramowania jak i sprzętu) sta-nowiła najważniejsze wyzwanie dla działalno-ści specjalistów.

Oracle 11g przynosi nowe narzędzia ułatwia-jące planowe i bezpieczne testowanie oraz imple-mentację zmian, upraszczając zarządzanie i mo-dyfikację systemów. Opcja Real Application Te-sting wspiera specjalistów w analizie zmian sys-temowych, pozwalając oszacować wpływ zmian na wydajność systemów działających pod rze-czywistym obciążeniem. Dzięki funkcjonalno-ści Database Replay istnieje możliwość weryfi-kacji wprowadzonych zmian oraz szczegółowej analizy wpływu tych zmian na wydajność syste-mu. Moduł SQL Performance Analyzer umoż-liwia szczegółową analizę wydajności zapytań

W Sieci

• http://www.oracle.com/database/index.html – Baza danych Oracle 11g• http://www.oracle.com/technologies/grid/index.html – Oracle Grid computing• http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm – Maximum Availabili-

ty Architecture

Oracle 11g

zmienionej bazy danych, wraz ze szczegółową optymalizacją zapewnianą dzięki SQL Tunning Advisor (dostępny w Enterprise Manager Tun-ning Pack).

Opcja Real Application Testing wraz z nową funkcjonalnością w Oracle Data Guard pozwala na łatwe i bezpieczne wykorzystanie zapasowe-go środowiska przetwarzania danych od testów, przy zachowaniu pełnej funkcjonalności tegoż środowiska (nowa możliwość bazy Oracle 11g – Snapshot Standby).

PodsumowaniePrzez ostatnich trzydzieści lat korporacja Orac-le jest liderem rynku baz danych, wyznaczając dalsze kierunki rozwoju dla całego rynku. Na-sze technologie stanowią efekt lat pracy specjali-stów, tworzących narzędzia dla systemów, jakie

Redakcja nie udziela pomocy technicznej w instalo-

waniu i użytkowaniu programów zamieszczonych na

płytach CD-ROM dostarczonych razem z pismem.

Jeśli nie możesz odczytać zawartości płyty CD, a nie jest ona uszkodzona mechanicznie, sprawdź ją na co najmniej dwóch napędach CD. W razie problemów z płytą, prosimy pisać pod adres: [email protected]

tworzą nasi klienci i nasi partnerzy. Staramy się dostarczyć technologie najlepiej wspierające na-szych klientów, antycypując ich potrzeby oraz re-agując na zgłaszane zapotrzebowania.

Oracle 11g przynosi znaczące usprawnienia w obszarach, które nasi Klienci uznali za istot-ne – największy nacisk to efektywne wsparcie zarządzania informacją, pozwalające na reduk-cję kosztów utrzymania systemów (TCO) oraz łatwą i bezpieczną adaptację do zmiennych po-trzeb organizacji. Kolejne obszary to bezpieczeń-stwo przetwarzania oraz optymalizacja wyko-rzystania posiadanej infrastruktury (Grid Com-puting), a także sprawny i wygodny mechanizm dostępu do wszelkich informacji przechowywa-nych w organizacji.

Baza danych Oracle 11g stanowi kluczowy element oferty korporacji Oracle, stanowiąc bez-

pieczną i skalowalną podstawę dla wszelkiego ty-pu systemów informatycznych. Praktyczne spo-soby implementacji bazy Oracle 11g wraz z po-zostałymi technologiami (Middleware, Identi-ty Management, zabezpieczenia) oferowanymi przez korporację Oracle są opisane w dokumen-tacji Maximum Availability Architecture, do-stępnej na witrynie Oracle.

MICHAŁ JERZY KOSTRZEWASpecjalista IT, 20 lat doświadczeń jako programista

(xBase, C/C++, języki skryptowe, aplikacje intrane-

towe), kierownik działu nowych technologii, specja-

lista baz danych i systemów wysokiej dostępności a

następnie architekt w polskim oddziale Microsoft.

Obecnie zatrudniony w korporacji Oracle jako Dyrek-

tor Regionalny, odpowiada za opcje bazy danych.


09/200834

Testowanie oprogramowaniaByła sobie inspekcja


O roli zarządzania jakością (ang. Qu-ality Management) nie muszę ni-kogo przekonywać. Obecnie więk-

szość firm zajmujących się produkcją oprogra-mowania legitymuje się zgodnością z wytycz-nymi ISO 9001, ewaluacją dojrzałości proce-sów (ang. Capability Maturity Model, CMM) lub podobnymi.

Jakość stała się ważnym narzędziem walki rynkowej – jej formalne zapewnienie jest co-raz częściej warunkiem zawierania kontrak-tów (zwłaszcza na wykonanie usług projek-towania).

Jednym z bardziej istotnych procesów za-pewniania jakości są mechanizmy inspekcji. Przesłanie jest tu proste: lepiej zapobiegać niż leczyć. Zamiast czekać na objawy (pro-blemy podczas wykonania), poszukajmy naj-pierw błędów u źródła (np. w kodzie źródło-wym).

Spróbujmy konstruować rozwiązania zgod-nie ze sztuką (ang. best practices). Spróbujmy zacząć od zapewnienia stabilnej podstawy, później zajmijmy się analizą zachowania pro-duktu. Trudno nie docenić zalet takiego po-dejścia. W projektach, gdzie kompilacja mo-że trwać dziesiątki minut każdy podstawowy błąd oznacza wymierną stratę czasu. Poszu-

kiwanie źródła problemu w źle napisanym, nieprzejrzystym kodzie jest bardzo nieefek-tywne. Niestabilne zachowanie, przypadko-we błędy są często pochodną niechlujnej im-plementacji.

Przeciwnicy podobnej pracy u podstaw podniosą kwestie praco- i czasochłonności procedur inspekcji. Sam widziałem projek-ty, w których inspekcja kodu stawała się pod-stawowym zadaniem zespołu projektowe-go. Oczywiście są dziedziny programowania, gdzie podobne podejście jest pożądane. Tak jest w przypadku produktów od których za-leży życie i zdrowie człowieka. Pozostawmy je jednak wąskiemu gronu specjalistów kon-centrując się na projektach nie związanych z leczeniem, lataniem i podatkami. Spróbujmy wykonać sztukę będącą esencją umiejętności menadżera.

Mając na uwadze znane osiągnięcia – wy-bierzmy z nich to, co najlepsze i najbardziej pasujące do ograniczającej nas rzeczywisto-ści projektu.

Proces a jego aplikacja Poniższy tekst został skonstruowany z myślą rozdzielenia definicji procesu inspekcji, od je-go aplikacji. Podobna metodologia zosta-ła przyjęta np. w przypadku ISO 9001. Sam dokument – norma, jest jedynie zbiorem wy-tycznych. Od konkretnego klienta zależy, w jaki sposób spełni on postawione wymagania. Dzięki takiemu rozdziałowi proces jest uni-wersalny i skalowalny. Możliwa jest jego apli-

kacja do różnych organizacji niezależnie od ich charakteru i rozmiarów.

Zgodnie z tą ideą poniższe opracowanie składa się z części przygotowującej (zawie-rającej podstawowe pojęcia i operacje), de-finicji procesu i przykładowej jego aplikacji. I tak, w części wstępnej znajdziemy określe-nie pojęcia rola, w części procesowej pokaza-ny zostanie zakres obowiązków przyporząd-kowany do poszczególnych ról, a w części aplikacyjnej – przedstawię zależności mię-dzy rolami w procesie inspekcji a rolami w projekcie.

Podobnie, przybliżone we wstępie pojęcie procesu, będzie wykorzystane do zdefinio-wania etapów inspekcji, aby w części aplika-cyjnej zamieścić uwagi do realizowania tych procesów.

Te trzy części stanowią razem pełny obraz (jak ramy, szkic i wypełnienie). Mogą być ska-lowane, dostosowywane do różnych potrzeb (adaptowane) oraz kombinowane w zależno-ści od potrzeb.

Skalowalność pokażę na przykładzie kom-pletnej i osobistej inspekcji. Mimo że ich za-sięg jest różny (odpowiednio cały produkt i pojedyncza zmiana) – w obydwóch przypad-kach wykorzystane mechanizmy (doktryny) są identyczne.

Większość podanych uwag będzie się odno-sić do kodu źródłowego, do fazy implementa-cji oprogramowania. Kod źródłowy jest tu jed-nak używany jako pewien przykład – szczegól-ny przypadek.

Generalne zasady formułowane będą względem produktu (jako rezultatu projek-tu) a nie oprogramowania, przedmiotów in-spekcji a nie kodu źródłowego i wreszcie ele-mentów a nie funkcji. Zamierzeniem takie-go uogólnienia jest zwrócenie uwagi na uni-wersalność przytoczonych reguł. Od same-

Była sobie inspekcja

Inspekcja jest jednym z bardziej kontrowersyjnych sposobów podnoszenia jakości produktu. Wszyscy zgadzają się co do jej pozytywnych skutków, z drugiej strony jest rozpoznawana jako proces kosztowny (w sensie czasu i zasobów) oraz trudny do zarządzania. Okazuje się jednak, że wymienionemu ryzyku można łatwo zapobiec poprzez konstrukcję elastycznego procesu inspekcji i jego odpowiedzialną aplikację.

Dowiesz się:• Czym jest inspekcja;

• Jak stworzyć efektywny proces inspekcji;

• Jak go przystosować do swoich potrzeb.

Powinieneś wiedzieć:• Podstawy zarządzania projektami;

• Podstawy planowania jakości.

Poziom trudności

Określenie, przygotowanie i definicja procesu inspekcji

09/200834



go Czytelnika zależy, czy zastosuje je do ko-du źródłowego, dokumentów projektowych, procesów w swojej firmie – do jakiegokol-wiek tworu, którego natura umożliwia pod-danie inspekcji.

Ostania uwaga dotyczy akcji wprowadzania poprawek (ang. maintenance). W niektórych publikacjach inspekcja i naprawa są rozdzie-lane tak, jakby dokonanie analizy było celem samym w sobie. Niestety praktyka pokazuje, że w takich wypadkach wysiłek poświęcony na inspekcję jest często marnowany. Produkt ewoluuje, dojrzewa, dostosowuje do zmienia-jącego się zapotrzebowania. Inspekcja musi za nim nadążać. Właśnie dlatego wprowadza-nie zmian będących następstwem wniosków z inspekcji rozpatrzę jako integralną część te-go procesu.

Kiedy zacząć?Zwykle pierwsza inspekcja kompletna (IK) po-winna mieć miejsce po wykonaniu 10% całej pracy (Rysunek 1). W większości popularnych cykli życia produktu oznacza to przeglądanie szkieletu rozwiązania. Daje to unikalną moż-liwość weryfikacji struktury (np. podziału na moduły), spójności, konsekwencji w stosowa-niu odpowiednich standardów (np. dla kodu – nazewnictwa funkcji i zmiennych, komen-towania kodu).

Kolejne powtórzenia inspekcji komplet-nej mogą być ograniczane do nowo doda-nych części, nie sprawdzanych wcześniej. Na-leży tu jednak zadbać o ich spójność z resztą rozwiązania.

Bardzo istotne jest przeprowadzenie inspek-cji po wykonaniu 90% pracy nad produktem. Jest to praktycznie ostatnia szansa doszlifowa-nia produktu przed publikacją.

Inspekcja osobistaUżyty powyżej termin inspekcji kompletnej (IK) odnosi się do zakresu przedmiotu anali-zy. Inspekcja kompletna obejmuje swoim za-sięgiem całość rozwiązania. Dla porównania, na Rysunku 1 zaznaczona została inspekcja osobista (IO).

Polega ona na przeprowadzaniu inspekcji przez każdego z członków zespołu w czasie tworzenia nowego fragmentu (lub poprawiania już istniejącego) przed dodaniem go do główne-go rozwiązania. Chodzi tutaj o aplikację takie-go samego procesu jak dla inspekcji komplet-nej w skali ograniczonej do pojedynczej zmia-ny. Każdy z deweloperów jest zobowiązany do rozpatrzenia stworzonego przez siebie frag-mentu (nowej funkcji, rozdziału w dokumen-cie) z punktu widzenia nie tylko wartości doda-nej (nowej funkcjonalności, nowych informa-cji, nowego formatowania), ale i rzemiosła, ja-kości wykonania.

Weryfikacja poszczególnych fragmentów nie pozwala oczywiście na jednoznaczne orzekanie o poprawności całości rozwiązania.

Osobista inspekcja jest na to zbyt lokal-na, odnosi się do niewielkich fragmentów, które do reszty rozwiązania mogą nie paso-wać. Wystarczy, że np. autorowi nieznane by-ły wszystkie powiązania poprawianego frag-mentu – jego kontekst. To co prawidłowe w ograniczonym zakresie, może okazać się zu-pełnie chybione w niektórych aspektach ca-łości – np. ciągu operacji, jednoznaczności przekazu.

Spotykamy tu się również z subiektywno-ścią analizy osobistej. Jakość dostarczanej pra-cy jest ograniczona stopniem zaawansowa-nia jego autora. Kod, z którego student będzie dumny, profesjonalista uzna zapewne za nie-dopracowany.

Podobne zagrożenie może stwarzać dodanie kodu autorstwa osoby dopiero wdrażającej się w projekcie, która nie zna szczegółowych roz-wiązań.

Określiłbym więc, że inspekcja osobista stwarza raczej domniemanie jakości niż jej do-wód. Nie może zastąpić inspekcji kompletnej. IO można traktować jak środek konieczny ale nie wystarczający.

Oczywiście rezultatów wprowadzenia IO nie można nie doceniać. Posiadanie wstępnej wery-fikacji pozwala na wczesne wykrywanie proble-mów, ogranicza wysiłek związany z kompletną inspekcją.

O ile inspekcja osobista może przyczy-nić się do opóźnień poszczególnych zadań w projekcie, wpływ kompletnej inspekcji na harmonogram może być bardziej znaczący (choć, jak twierdzi Brooks, najczęściej opóź-nienia powodują termity, nie tornada – [5]). Sposoby radzenia sobie z jej przeprowadze-niem podam w dalszej części niniejszego opracowania.

W przypadku gdy przedmiotem jest kod źródłowy, inspekcję osobistą można dodat-kowo połączyć z uzupełnianiem dokumen-tacji projektu. Autor kodu ma wtedy obo-wiązek odzwierciedlić wprowadzone zmia-ny w odpowiednich dokumentach (ang. de-tailed design). Konieczność wytłumaczenia

dokonanych zmian, ich logiki, wymaga od autora ponownego przejścia ścieżki wnio-skowania.

Prześledzenie napisanego kodu, powtó-rzenie toku rozumowania, skonfrontowanie z już istniejącymi rozwiązaniami, sprawdze-nie kontekstu pozwoli na odnalezienie wcze-śniej niezauważonych błędów implemen-tacji. Efekt poprawy jakości będzie tym sil-niejszy.

UlepszanieDosłowna aplikacja procesów jest wymienia-na jako jedna z przyczyn porażek projektów. Brak krytycyzmu, ustawianie projektów pod obowiązujący proces czy wręcz jawne celo-wanie w zewnętrzny audyt a nie faktyczne potrzeby podnoszenia jakości są częstymi zjawiskami. A przecież istotą każdego pro-cesu jest jego stałe dostosowywanie i ulep-szanie.

To właśnie tu leży trudność jego prawi-dłowej aplikacji: w dobraniu elementów nie-zbędnych i dostosowywaniu ich do konkret-nych potrzeb.

Taki jest też proces inspekcji. Jego formal-na definicja jest uniwersalna. Szybko widać jednak, że jego aplikacja wymaga znacznie większego nakładu pracy przy wykonaniu i jeszcze większego w zakresie monitorowa-nia postępów.

To jednak nie wszystko. Proces, aby miał sens, musi być stale ulepszany – tak od stro-ny formalnej definicji, jak i aplikacji. Wnio-ski płynące z każdego etapu muszą być anali-zowane nie tylko pod kątem ulepszania pro-duktu (aspekt techniczny), ale i samego pro-cesu inspekcji (aspekt formalny). Taki pro-ces ewoluuje, żyje, dojrzewa wraz z produk-tem; jest aktualny i adekwatny. Powoli prze-staje być pojedynczym aktem, zrywem zwią-zanym z nagle poznanym dodatkowym kryte-rium akceptacji produktu. Staje się ważnym (owocnym, regularnym) elementem mecha-nizmu zapewniania jakości w projekcie (or-ganizacji).

Rysunek 1. Powtarzanie inspekcji kompletnej (IK) w czasie trwania projektu oraz inspekcja osobista (IO)

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

09/200836



Nie dzieje się to jednak samoistnie. Wy-maga całkiem sporego nakładu pracy – ob-serwacji rezultatów inspekcji, wyciągania wniosków z uzyskanych wyników i dokony-wania na ich podstawie odpowiednich akcji naprawczych.

Trzeba zwrócić uwagę, które elemen-ty (aspekty funkcjonowania, dziedziny rze-miosła) wymagają większej uwagi (duża ilość uwag w czasie inspekcji) a które wydają się do-brze opanowane.

Trzeba zdać sobie sprawę z ważności zaob-serwowanych braków oraz ich wpływu na pro-dukt (obecny lub przyszłe wersje). Na tej pod-stawie można decydować o zasięgu akcji na-prawczych – krótkoterminowych (usunięcie zaobserwowanego problemu) lub długoter-minowych (odpowiednie przeprojektowanie eliminujące możliwość ponownego wystąpie-nia). Proces musi za takimi zmianami podą-żać – np. poprzez dostosowane priorytetów inspekcji.

W przypadku kodowania – jeżeli właśnie poprawiliśmy zarządzanie pamięcią, zamiast wycieków pamięci raczej będzie nas intereso-wać jej fragmentacja. Likwidacja strat pamięci była celem pierwszej fazy inspekcji kodu; dru-ga faza ma się koncentrować się na optymali-zacji rozwiązania. W przypadku dokumenta-cji – rozpoznanie rozbieżności w wyglądzie różnych dokumentów może być impulsem do stworzenia wspólnego wzorca (ang. template) i wprowadzenia go do systemu jakości. Uzyska-my wtedy referencję, punkt odniesienia, pod kątem którego będziemy wykonywać kolejne iteracje inspekcji.

Produkt dojrzewa – wymagania stawiane przed nim będą coraz ostrzejsze. Inspekcja mu-si je wspierać.

Powyższe stwierdzenia odzwierciedla szero-ko stosowana metodologia cyklu PDCA, gdzie:

• P (ang. Plan) – zaplanuj, ustal przedmioty, cele i metody pozwalające na ich osiągnię-

cie (w PMBok [7] – ang. inputs, tools and techniques, outputs,ITTO);

• D (ang. Do) – wykonaj to co zaplanowałeś;• C (ang. Check) – kontroluj, monitoruj wy-

konanie, sprawdzaj rezultaty i porównuj je z założonymi celami;

• A (ang. Act) – znając rozbieżności między założeniami i rzeczywistymi efektami po-dejmuj akcje w celu ulepszania.

Kontynuując przykład dokumentacji – uży-wając wzorca stworzonego w wyniku po-przedniej inspekcji oraz listy dokumentów z nim niezgodnych (P) poprawiamy je (D) sprawdzając czy zbieżność ze wzorcem zosta-ła osiągnięta (C).

Jeżeli zauważymy, że wzorzec jest nie do końca adekwatny dla wszystkich posiadanych typów dokumentów, poprawiamy go z zamia-rem użycia jako odnośnika w następnej inspek-cji (A).

Przygotowanie do inspekcjiW poniższym tekście przywołam niejedno-krotnie pojęcie procesu, należy się więc jego przybliżenie. Proces odwołuje się do zarzą-dzanej aktywności angażującej zasoby w ce-lu przekształcania wartości wejściowych w wartości wyjściowe. Grupa procesów powią-zana jest przyczynowo – skutkowo, tzn. wyj-ścia jednego procesu stanowią wejścia dla dru-giego procesu.

Takie podejście pozwala na traktowanie przedmiotu procesów w sposób nie struktu-ralny (komu podlega, jak jest zorganizowa-ny), ale funkcjonalny (jak działa, jak się zacho-wuje). Różnica polega na przejściu z modelu wertykalnego (granice wyznaczone strukturą) na model horyzontalny (granice wyznaczone funkcjonowaniem).

Można to zobrazować na przykładzie za-rządzania pamięcią. Jak pokazano na Ry-sunku 2, przyjęcie podejścia procesowego (horyzontalnego) może znacząco wpłynąć

Rysunek 3. Definiowanie perspektyw

��

��

��

��

��

��

Rysunek 2. Podejście strukturalne i procesowe

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

09/200836



na architekturę rozwiązania. Zamiast pa-trzyć na operacje wykonywane w poszcze-gólnych modułach (punktowe, lokalne), po-dejście procesowe pozwala śledzić zachowa-nie całego produktu, efektywność w wybra-nym horyzoncie (tu: zarządzania pamięcią). Kryterium sukcesu staje się automatycznie poprawność funkcjonowania całego rozwią-zania, a nie jego poszczególnych części. Od-zwierciedla to cel projektu, którym jest sa-tysfakcja klienta.

RoleProces inspekcji wymaga zdefiniowania no-wych ról, do których będą przyporządkowa-ni jego uczestnicy. Kwestią odpowiedniej apli-kacji procesu będzie ich skojarzenie z rolami projektowymi (np. architekt, deweloper, te-ster). Podstawowymi rolami w zespole inspek-cyjnym są:

• kierownik inspekcji (ang. review chair-man);

• inspektor (ang. reviewer);• autor (ang. author).

Potrzebujemy kogoś, kto będzie kierował całym procesem, nadzorował i kontrolo-wał jego wykonanie, zbierał i rozpowszech-niał wyniki, przedstawiał ich interpretacje i płynące z nich wnioski. Konieczni są in-spektorzy, którzy przeprowadzą właściwą analizę.

Aby analiza była efektywna, potrzebny bę-dzie rodzaj konsultanta technicznego, ktoś odpowiedzialny za dany fragment kodu, mo-duł. Niekoniecznie to musi być fizyczny au-tor kodu, chociaż tak tą rolę zwykło się na-zywać.

W zależności od wybranej techniki inspek-cji, zestaw można modyfikować. Należy za-chować jednak ostrożność przy łączeniu tych ról ze sobą. Autor nie będzie przecież obiek-tywnie patrzył na własne dzieło. Kierownik pełniący rolę inspektora musi wybierać po-między zadaniami analizy i kierowania pro-cesem.

Techniki inspekcji Na potrzeby tego opracowania podzieliłem techniki inspekcji na trzy grupy klasyfikowane według wymaganego stopnia wykorzystania ze-społu projektowego.

Pierwsza grupa wymaga zaangażowania całego zespołu. Przykładem takiej techni-ki jest inspekcja formalna (Fagana). Jest to proces opierający się na serii spotkań. W ich trakcie przedstawia się analizowany element (np. fragment kodu) wszystkim zgromadzo-nym, odbywa się dyskusja nad nim i w obec-ności wszystkich rozważane są możliwe po-prawki. Metoda ta pozwala na bardzo szcze-gółową inspekcję ale wiąże się z dużymi na-kładami.

Doświadczenia dowodzą, że średnia wy-dajność będzie się wahać około 200 linii w ciągu 9 godzin ([8])! Konieczne jest rów-nież odpowiednie przygotowanie i przeszko-lenie zespołu.

Kolejna grupa inspekcji odznacza się ogra-niczeniem ilości wykorzystywanych ról do inspektora i autora (faktyczna liczebność in-spektorów i autorów jest tu kwestią obojęt-ną). Komunikacja na danym etapie jest zre-dukowana do osób bezpośrednio zaintereso-wanych. Preferowane są mało formalne spo-tkania.

Rozszerzenie tej metody jest szczególnie często wykorzystywane przy implementacji z użyciem doktryn agile (np. programowa-nie w parach). W przypadku większego roz-proszenia zespołu, komunikacja może odby-wać się za pomocą poczty elektronicznej czy list dyskusyjnych (stanowiących dodatkowo medium dokumentacji). Taką technikę czę-sto stosuje się w przypadku projektów typu OpenSource [2], tworzonych przez luźną spo-łeczność.

Rolę inspektora mogą z powodzeniem peł-nić narzędzia dokonujące statycznej analizy ko-du (skrypty czy specjalistyczne oprogramowa-nie jak PCLint).

Rola człowieka – inspektora ogranicza się wtedy do odpowiedniego przygotowania (skon-figurowania, zainstalowania) narzędzia, wyko-nania go i przetworzenia wygenerowanych wy-ników.

W końcu mamy techniki tzw. inspekcji oso-bistej (IO). Polegają one na tym, że każdy au-tor jest zobowiązany do zweryfikowania wyni-ków swojej pracy zanim ją doda do całego roz-wiązania.

Oczywiście wymaga to odpowiedniego po-ziomu samodyscypliny i jest skażone subiek-tywnością oceny własnej pracy, może rów-nież ograniczać propagację doświadczeń w zespole.

Strategie inspekcjiPodane wyżej techniki inspekcji będziemy uży-wać z dwoma podstawowymi strategiami in-spekcji – perspektywami i listami sprawdzają-cymi (ang. checklist).

Perspektywy pozwalają skoncentrować uwa-gę inspektora na pojedynczym aspekcie. Za-miast patrzeć na przedmiot inspekcji szuka-jąc w nim wszelkich możliwych niedoskonało-ści, inspektor koncentruje swoją uwagę na jed-nej, wybranej kategorii problemów, na aspek-cie (funkcjonalnym, organizacyjnym, estetycz-nym) produktu.

Weźmy dla przykładu następujący fragment kodu:

int FOO(int x, int y){

int a;

if( y > 0 )a = x / y;

return a;}

Inspektor może stwierdzić:

• naruszenie standardów kodowania – brak komentarzy nad funkcją, bloki ko-du niepoprawnie sformatowane lub nie zaznaczone, nic nie mówiąca nazwa funkcji;

• przenośność – natywny dla C typ int mo-że być interpretowany zależnie od rodzaju platformy, na której kod zostanie wykona-ny (8, 16, 32, 64 bity);

• operacje wejścia/wyjścia – zmienna wyj-ściowa nie zainicjowana dla y<=0.

Oczywiście powyższa lista jest całkowicie prawdziwa.

Czy jednak obejmuje wszystkie możliwe przypadki? Problem polega na tym, że in-spektor sprawdza wiele różnych czynników na raz. Jego uwaga jest rozproszona. Jest więc wielce prawdopodobne, że przy dziesiątej funkcji z kolei zapomni zanotować brak ko-mentarzy, przy dwudziestej nie wykaże bra-ku sprawdzania parametrów wejściowych (tu – groźba dzielenia przez zero). A może w ogóle nie pomyślał, ile podobnych funk-cji znajduje się w całym rozwiązaniu (redun-dantny kod)?

Analiza przedstawionej funkcji pod jednym, wybranym kątem byłaby o wiele szybsza. Co więcej, inspektor na pewno zauważyłby moż-liwości zautomatyzowania swojego zadania. I po godzinie pracy nie zapomniałby, co miał sprawdzić.

Oczywiście zanalizowanie wszystkich aspek-tów przedmiotu inspekcji będzie wymagało za-deklarowania wielu perspektyw.

Pokrycie przedmiotu inspekcji jest zależne od ilości i rodzaju zdefiniowanych perspek-tyw. Na przykładzie kodu źródłowego (Ry-sunek 3) – niektóre linie kodu (ang. lines of code, LOC) sprawdzi się tylko raz (przypa-dek A), niektóre wielokrotnie (przypadek B) a niektóre w ogóle (przypadek C). Jedno-krotne sprawdzenie każdej linii kodu (czy-li określenie perspektyw rozłącznych i jed-nocześnie dopełniających się) jest sytuacją idealną i trudną do osiągnięcia. Wielokrot-ne sprawdzanie tych samych LOC jest ma-ło efektywne.

Oczywiście w praktyce najczęściej będzie-my mieli do czynienia z sytuacją, gdy zdefi-niowane perspektywy nie obejmą dokładnie całego kodu. Czy jest to sytuacją akceptowal-na? Z punktu widzenia kompletności inspek-cji (odsetku dotkniętego kodu – ang. code co-verage) – nie.

Z punktu widzenia ograniczeń projekto-wych odpowiedź ta musi być ważona wzglę-dem konkretnych potrzeb. Ale przecież klientowi nie chodzi o ładne słupki w specy-fikacji produktu!

Dla klienta ważne jest, żeby produkt realizo-wał jego wymagania. Jeżeli produktem jest pro-

09/200838



gram – ważne będzie żeby np. zadowalał się niewielką ilością pamięci. Zwiększenie zapo-trzebowania na pamięć oznacza bowiem wyż-sze wymagania w stosunku do sprzętu a więc ograniczenie zysku (zamiast o pececie pomyślcie o telefonie komórkowym). Jeżeli stwierdzamy problemy z konsumpcją pamięci – konstruuje-my perspektywę koncentrującą się jedynie na kwestiach związanych z alokacja, zwalnianiem, fragmentacją pamięci i możliwymi wyciekami. Niepełne pokrycie kodu przez inspekcję opartą na takiej perspektywie nie stanowi problemu. Skuteczność takiego horyzontalnego (przekro-jowego, funkcjonalnego) podejścia do tematu może okazać się kluczem do rynku.

Każdą perspektywę należy określić przez:

• aspekt – czego szukać;

Jakie cechy należy rozważyć? Pod jakim ką-tem powinniśmy patrzeć na przedmiot in-spekcji?

• zakres – gdzie szukać;

Które części przedmiotu zostaną poddane in-spekcji?

• cel – co chcemy osiągnąć;

Jakie efekty ma przynieść inspekcja? Czego powinniśmy się nauczyć? Jakich rezultatów poszukujemy?

Inną funkcję pełnią listy sprawdzające. Są one zbiorem cech, które zawsze należy spraw-dzać. Wybór odbywa się na zasadzie kwalifi-kacji znalezionych błędów według częstotli-wości występowania oraz zagrożenia jakie mo-gą stwarzać. Interpretacja wyników każdej in-spekcji sprawi, że niektóre zagadnienia z listy sprawdzającej będą usuwane (jako wcale lub stosunkowo rzadko występujące) a inne będą się pojawiać.

W ten sposób buduje się bazę podstawo-wych mankamentów produktu. Śledzenie zmian w takich listach może dostarczyć do-datkowych wiadomości o silnych i słabych stronach rzemiosła autorów oraz ich zmia-nach w czasie. Jeżeli np. mimo przeprowa-dzonego szkolenia w listach nadal dominu-ją kwestie związane z zarządzaniem pamię-cią – jest to jasny sygnał, że szkolenie było nie-skuteczne.

Największymi zaletami list sprawdzających jest to, że potrafią one zwrócić uwagę inspekto-ra na konkretne, często powtarzające się proble-my. Dobrze spisują się również w przypadku in-spekcji osobistych. Mogą stanowić materiał do automatyzacji.

Z drugiej jednak strony listy sprawdza-jące, koncentrując się na pewnych szczegó-łach, tracą z widoku szerszy obraz, funkcjo-nalność. Nie można w nich zawrzeć wiedzy eksperckiej, intuicji inspektora. Co więcej – zbyt duże ich uszczegółowienie może spra-wić, że inspektorzy, zamiast dokładnej anali-

zy przedmiotu inspekcji, będą ograniczać się jedynie do ich sprawdzenia.

Proces inspekcjiW tym rozdziale zdefiniujemy inspekcję jako proces wykonywany w ramach procedur za-pewniania jakości produktu. Inspekcja będzie podzielona na kilka faz. Każda faza będzie mia-ła zdefiniowane wejścia przekształcane z uży-ciem zasobów w określone wyjścia. Te fazy to (Rysunek 4):

• analiza;• naprawa;• weryfikacja;• ulepszanie.

W następnych rozdziałach scharakteryzuję każdą z faz.

Podobieństwo modelu przedstawionego na Rysunku 4 do znanej z ISO 9001 PDAC ([3]) jest nieprzypadkowe. Zdefiniowanie procesu inspekcji w ten sposób umożliwia łatwe włączenie inspekcji do obowiązujące-go systemu jakości w organizacji. Analogie można również odnaleźć w PMBok. Analiza w inspekcji odniesie się do grupy procesów związanych z planowaniem (ang. planning); naprawa i weryfikacja do realizacji (ang. exe-cuting) i kontroli (ang. controlling); ulepsza-nie ujęte jest w ramach zamykania procesów (ang. closing).

AnalizaPierwszą fazą inspekcji jest analiza. To etap, podczas którego inspektorzy przegląda-ją przedmiot inspekcji. Zadaniem inspekto-ra jest skoncentrowanie się na wyszczegól-nionym zakresem (pliki, katalogi lub modu-ły) pod kątem pojedynczego aspektu w wy-znaczonym celu – zgodnie z definicję zada-nej perspektywy.

Przeprowadzenie takiej analizy wymaga do-starczenia:

• odpowiedniej dokumentacji;• odpowiednich narzędzi;• przedmiotu analizy (np. kodu źródłowego).

Wymaganą dokumentację możemy podzielić na dwie kategorie – procesową i projektową. Dokumentacja procesowa powinna pomóc in-spektorowi zrozumieć jak ma wypełnić swo-je zadanie.

Stanowi rodzaj kodeksu postępowania, zbio-ru zasad wobec których należy postępować. Częścią dokumentacji procesowej jest np. de-finicja perspektyw.

W przypadku inspekcji kodu ważnym ele-mentem dokumentacji procesowej są stan-dardy kodowania. Stanowią zbiór reguł, któ-rych należy przestrzegać podczas pisania ko-du źródłowego. Odnoszą się do konwencji nazewnictwa, komentarzy ale i samej sztu-Rysunek 4. Etapy procesu inspekcji

��

��

��

��

��

��

��

��

��

��

� �

� �

09/200838



ki kodowania. Przykładowo dla C# najczę-ściej wykorzystuje się standardy sformułowa-ne dla Philips Medical Systems [4]. Z reguły standardy kodowania określa się na poziomie organizacji, jako część obowiązującego syste-mu jakości.

Dokumentacja projektowa powinna z kolei pomóc inspektorowi w zrozumieniu przed-miotu analizy. Wymagane są wszelkie źródła pozwalające na ogarnięcie natury przedmio-tu, sposobu jego działania i przeznaczenia. Mogą to być materiały źródłowe, dokumen-ty zawierające specyfikacje wymagań użyt-kownika, architektury, ogólnych i szczegóło-wych rozwiązań projektowych, interfejsów, konfiguracja projektu (np. reguły używania systemów kontroli wersji) oraz dotyczące te-stowania.

Zakłada się, że inspektor będzie miał rów-nież dostęp do odpowiedniego zestawu na-rzędzi, który umożliwi mu przeprowadze-nie analizy oraz udokumentowanie wnio-sków (komentarzy). Zazwyczaj jest to ze-staw narzędzi używany na co dzień przez autorów do pracy (edytory, systemy kontro-li wersji, systemy raportowania błędów, pa-kiety biurowe, kompilatory, środowisko te-stowe).

Proszę zwrócić uwagę, że w czasie analizy mogą powstać nowe narzędzia (np. skrypty) automatyzujące pracę inspektora. Należy je potem odpowiednio włączyć do konfigura-cji projektu.

Przedmiot analizy ma odpowiadać mini-malnym wymaganiom jakości, np kod źró-dłowy musi się kompilować. Jeżeli podczas kompilacji zgłaszane są ostrzeżenia, dobrym pomysłem jest rozpoczęcie inspekcji od per-spektywy, której celem jest ich usunięcie. Przedmiot poddawany inspekcji powinien być również stabilny w sensie jego rozwoju – nie ma większego sensu inspekcja kodu, który w ciągu najbliższego czasu ma czeka przeprojektowanie (potrzeba taka może być jednak wnioskiem z inspekcji).

W przypadku kodu, wiele źródeł proponu-je dokonywanie inspekcji na wydruku zamiast na ekranie. Nakłada to dodatkowe wymaganie odpowiedniego sformatowania poprzez np. dostosowanie maksymalnej długości linii do możliwości drukarki.

Dbając o efektywność, pozostawiłbym jed-nak wybór osobistym preferencjom inspek-torów.

Sam proces analizy wykonuje inspektor. Przegląda on przedmiot analizy w poszuki-waniu wszelkich naruszeń rzemiosła. Takie naruszenia odnoszą się do typowych błędów w sztuce oraz naruszania przyjętych w pro-jekcie (organizacji) standardów, jak np. ko-dowania, formatowania dokumentów zgod-nie ze wzorcem, gramatyki języka. Wnioski z analizy zapisywane są w postaci komenta-rzy (Tabela 2).

Należy tu zwrócić szczególną uwagę na format ich raportowania. Zazwyczaj jest to

stosunkowo długa lista, musi być więc od-powiednio precyzyjna pod względem okre-ślenia problemu i sposobów jego reproduk-cji. Komentarze mogą zawierać sugestie co do sposobów rozwiązania problemu. Trze-ba jednak podchodzić do nich z pewną re-zerwą – mogą bowiem sugerować rozwiąza-nia lokalne podczas gdy szersza analiza wy-każe konieczność podjęcia bardziej general-nych akcji.

Z podobną ostrożnością należy traktować uwagi o charakterze ogólnym (np. moduł XX powinien zostać przepisany). Mogą one wyni-kać z przesłanek nie mających swojego uspra-wiedliwienia w szerszym kontekście.

Dobrą praktyką jest określanie wpływu opi-sanego problemu na całe rozwiązanie (ang. se-verity). Pozwala to później odpowiednio szere-gować zadania.

Komentarz może zawierać również pytanie lub uwagę do zastosowanego rozwiązania.

Jednoznaczne określenie sposobu repro-dukcji problemu opisywanego przez ko-mentarz warunkuje efektywność naprawy. Identyfikacja miejsca, które sprowokowało komentarz, musi być niezależna od poten-cjalnych zmian (wprowadzanych np. w wy-niku innych komentarzy). Podanie np. sa-mego numeru linii w pliku nie zawsze wy-starczy.

Wszystkie komentarze z inspekcji nale-ży gromadzić. Umożliwia to późniejszą ich analizę pod kątem np. dojrzałości produk-

Tabela 1. Wybrane techniki inspekcji

Technika Opis Zalety Wady

Cały zespół

Formalna(Fagana)

Uczestniczy cały zespółDefiniowane są role• Moderator (prowadzi spotkania)• Inspektor (przeprowadza analizę)• Obserwator (dostarcza wiedzy do-menowej)• Prezenter (pokazuje analizowany fragment)• Autor (fizyczny autor dyskutowane-go fragmentu)

• Bardzo szczegółowa• Bardzo dobra dystrybucja wiedzy

• Wymagająca pod względem zasobów i czasu• Wymaga szkolenia

Inspektor + Autor

Jeden na jeden Uczestniczy jedynie autor i inspektor.Spotkania osobiste, w małym zespo-le lub poprzez wymianę poczty elek-tronicznej

• Prosta, nie wymaga szkolenia• Elastyczna w zasobach wykorzy-stania czasu

• Ograniczony zasięg inspekcji• Autor i inspektor mogą zanalizować jedynie wybrane aspekty, omijają bardziej skomplikowa-ne kwestie• Trudności w śledzeniu postępów• Trudności w dokumentowaniu

Wspomagana narzę-dziami

Rolę inspektora odgrywają narzędzia do statycznej analizy kodu

• Szybkość analizy• Obiektywność• Możliwość śledzenia trendów w analizie

• Narzędzia wymagają szkolenia• Zapewnienie wsparcia dla nich• Koszty zakupu zaawansowanych narzędzi mo-gą być wysokie• Narzędzia są jedynie tak dobre, jak ich autorzy

Autor

Osobista Analiza tworzonego przez siebie ko-du zanim udostępniony zostanie in-nym

• Duża oszczędność czasu• Kod oddawany do rozwiązania jest już wstępnie zweryfikowany

• Ograniczony zasięg inspekcji• Subiektywna (autor nie może w pełni zastąpić inspektora)• Trudności w propagacji doswiadczeń autora na resztę zespołu

09/200840



tu. Na podstawie takiej dokumentacji moż-na wysnuć wnioski co do generalnych środ-ków zapewniających podniesienie jakości produktu. Dla przykładu, może to być ko-nieczność przeszkolenia zespołu w zakresie standardów kodowania, specyfikacji platfor-my docelowej.

W ten sposób komentarze stają się ważną częścią dokumentacji projektowej.

NaprawaNa podstawie komentarzy zgłoszonych przez inspektorów na etapie analizy, można przy-stąpić do poprawiania produktu. Na wstę-pie wszystkie komentarze powinny być ze-brane przez kierownika inspekcji. W konsul-tacji z autorem, każdy z komentarzy klasyfi-kuje się jako:

• zaakceptowany, tzn. uznany za zasadny;• odrzucony, gdy uwaga jest bezpodstawna;• odroczony, w przypadku gdy komentarz

nie ma szans na realizację w najbliższej przyszłości;

• do dyskusji, gdy komentarz wymaga kon-sultacji.

Zaakceptowane komentarze, o ile dotyczą konkretnej zmiany (np. pomyłki w kodzie, błędu merytorycznego w artykule) należy zamieniać na raporty o błędach (ang. pro-blem reports, PR) i zgłosić do systemu kon-troli błędów (np. Bugzilla). Komentarze o charakterze ogólnym (lub wnioski płyną-ce z zebrania komentarzy szczegółowych) powinny zostać ujęte w formie propozycji

zmian (ang. change request, CR) lub nowych wymagań (ang. requirement, REQ). Takie CR i REQ trzeba uwzględnić w przyszłych wer-sjach produktów (np. iteracjach implemen-tacji – w zależności od przyjętego cyklu ży-cia produktu).

Proszę zwrócić uwagę, że komentarze nale-ży zawsze uzupełniać o odpowiednie notatki dotyczące zmiany ich stanu oraz podjętych ak-cji. Jest to konieczne, aby nie zgubić się w ich mnogości.

Efektywność procesu inspekcji wyma-ga, żeby etap analizy i naprawy operowały na tym samym przedmiocie. Jedynie wte-dy wszystkie komentarze będą adekwat-ne i elementy przedmiotu (funkcje w ko-dzie, rozdziały w dokumencie), do które-go się odnoszą, były łatwe do identyfikacji. Im dłużej zwleka się z rozpoczęciem wpro-wadzania zasugerowanych zmian, tym wię-cej komentarzy będzie się odnosić do nie-istniejącego elementów lub zlokalizowanie odpowiedniego fragmentu może być bar-dziej pracochłonne (np. zmieni się numera-cja rozdziałów).

Łatwo w ten sposób zniweczyć cały nakład pracy, który został włożony w fazie analizy. Jest to oczywiście krytyczne jedynie dla PR'ów.

W przypadku CR lub REQ ma mniejsze znaczenie, gdyż odnoszą się one do przyszłych rozwiązań.

Patrząc na model przedstawiony na Ry-sunku 4 widzimy, że etap naprawy powi-nien zakończyć się osiągnięciem wyznaczo-nych przez perspektywę celów. Cele te po-winny być określone w sposób umożliwiają-

cy ich zmierzenie. Jedynie wtedy można bę-dzie zweryfikować czy naprawa osiągnęła za-mierzony efekt.

WeryfikacjaEtap weryfikacji polega na sprawdzeniu, czy komentarze zgłoszone przez inspektorów podczas analizy przedmiotu inspekcji zosta-ły odpowiednio rozwiązane (przez autorów w fazie naprawy). Odpowiednie rozwiązanie oznacza że:

• problem zasygnalizowany przez inspekto-ra nie jest już obserwowany;

• modyfikacja została dokonana zgodnie z kontekstem i przyjętymi standardami dla produktu;

• modyfikacja nie stwarza nowych proble-mów i nie ma negatywnego wpływu na resztę rozwiązania.

Powyższe stwierdzenia, na pierwszy rzut oka trywialne, odnoszą się do realnych, codzien-nych problemów jakości. Pierwsze z nich od-nosi się do konieczność określenia sposobów reprodukcji problemu. W przypadku kodu źródłowego będzie to najczęściej wskazanie pliku, funkcji, linii kodu, charakterystycz-nej sekwencji. Weryfikacja będzie polegać na sprawdzeniu czy odpowiedni fragment został zmieniony. Podobnie łatwo zweryfikować ko-mentarze dotyczące np. błędów gramatycz-nych w dokumencie. Mówimy wtedy, że ko-mentarz był testowalny.

Załóżmy jednak, że inspektor zalecił uszcze-gółowienie opisu. Jeżeli to zrobimy – skąd pew-

Bibliografia

• Project Management Institute, www.pmi.org;[1]• The Cathedral and the Bazaar, Eric Raymond, 1997;[2] • The TickIT Guide, British Standards Institution, 2001;[3] • Coding Standards: C#, Philips Medical Systems – Software / SPI, 2005;[4] • The Mythical Man-Month: Essays on Software Engineering, Fred Brooks, 1995;[5] • The Executive in Action, Peter F. Drucker, 1996; [6] • A Guide to the Project Management Body of Knowledge (Third Edition), Project Management Institute, 2004;[7] • Four ways to a Practical Code Review, Jason Cohen, 2007;[8]

PMBokProject Management Body of Knowledge (PMBok) jest publikacją Project Management Institute (PMI) zawierającą zbiór najlepszych praktyk stosowanych w zarządzaniu projektami. PMBok definiuje etapy projektu (grupy procesów) i określa jakie (w jakiej kolejności) powinny zajść w nich procesy. Każdy z procesów (razem 44) jest określony przez wejścia, narzędzia i techniki oraz wyjścia (ITTO). Procesy są przyporządkowane do obszarów wiedzy aktyw-nych w zależności od etapu projektu [1].

Tabela 2. Przykładowe komentarze z inspekcji kodu

Inspektor Typ Wpływ Plik/Rozdział

Funkcja Opis Status Akcje

arekm Błąd Krytyczny foo.c FOO Zmienna wyjściowa nie zainicjowana dla y<=0

Nowy

arekm Uwaga Ważny foo.c FOO Nazwa funkcji nic nie mówi o jej przeznacze-niu – zob. standardy kodowania rozdz. 3.1.5

Nowy

arekm Uwaga Normalny foo.c FOO Brak komentarzy Nowy

09/200840



ność, że dokonana zmiana jest wystarczająca, tzn. sporny opis po naprawie jest wystarczają-co szczegółowy?

Stąd wniosek, że weryfikacja niektórych komentarzy (np. ogólnych) będzie wyma-gała współpracy z inspektorem. Musi to zo-stać ujęte przy tworzeniu harmonogramu in-spekcji.

Druga uwaga dotyczy integralności produk-tu. Każdy produkt wykonywany jest z pomo-cą zestawu formalnych (standardy) i niefor-malnych (zwyczaje) metod. Żadna wprowa-dzona poprawka nie powinna tego stanu za-kłócać – wewnętrzna spójność produktu mu-si być zachowana.

Trzecia uwaga stanowi odzwierciedlenie częstego problemu kontrolowania kontrolo-wanych.

Polega to na konieczności upewnienia się, że poprawka nie uczyniła więcej zła niż po-dejrzewano o to oryginał. Czasami niewiel-ka zmiana, może mieć bardzo poważne kon-sekwencje – np. doprowadzić do znaczącego spadku wydajności poprzez nieuważne uży-cie muteksów.

Problem ten jest szczególnie ważny w przypadku poprawek przy końcu cyklu pro-dukcji (np. przy inspekcji 90%). Im mniej czasu do publikacji, tym poważniejsze kon-sekwencje popełnienia błędu (brak czasu na poprawki i powtórzenia procedury te-stowania).

Powyższe uwagi powinny być uwzględnione przez obowiązujący w projekcie proces kontro-lowania zmian. Inspekcja powinna ten proces wykorzystywać.

Zestawienie osiągniętych rezultatów z cela-mi wyznaczonymi w perspektywach pozwoli na stworzenie miar określających efektywność przeprowadzonego procesu inspekcji. W ten sposób będziemy mogli upewnić się, że robimy rzeczy dobrze [6].

UlepszanieEtap ulepszania należy wykorzystać do prze-analizowania uzyskanych w czasie pozosta-łych etapów miar. Niezadowalające wyniki bę-dą oznaczać, że albo proces zastosowany przez nas był niewystarczający, albo jego aplikacja by-ła niepoprawna.

Przykładowo niewielka ilość komentarzy zgłoszonych przez inspektorów może ozna-czać, że:

• proces nie zagwarantował wszystkich możliwych referencji;

• proces nie zagwarantował odpowiednich kanałów komunikacji;

• proces nie zagwarantował odpowiedniego przepływu informacji.

Uwaga pierwsza odnosi się do sytuacji, gdy inspektorom nie zostały dostarczone wszystkie źródła, jakie mogły pomóc im w

ich pracy. Dla przykładu – brakowało odpo-wiedniego wzorca dla dokumentów, nie zo-stało określone czy dokument ma być napi-sany z użyciem brytyjskiej czy amerykań-skiej wersji angielskiego. Inspektorzy oparli więc swoją analizę na niepełnych przesłan-kach. Jakość ich pracy (nie z ich winy) mo-że być niższa niż się tego po nich spodzie-wano.

Źródłem problemów może być także spo-sób w jaki porozumiewali się członkowie ze-społu inspekcyjnego. Zbyt duża nieformalność doprowadza do chaosu i niemożności śledze-nia postępów inspekcji. Za duża formalność (np. skomplikowane formularze zgłaszania ko-mentarzy) spowalnia pracę i czyni ją mało efek-tywną.

Trzecia uwaga dotyczy organizacji pracy podczas inspekcji. Jeżeli odpowiedzialność, ja-ka łączy się z każdą z ról, nie zostanie dokład-nie określona, członkowie zespołu inspekcyj-nego nie będą świadomi swoich obowiązków. Nie będą wiedzieli kto np. zleca zadania napra-wy (kierownik inspekcji a może menadżer pro-jektu), kto powinien odbierać od nich raporty itp. Brak znajomości zależności pogorszy efek-tywność.

Patrząc od strony aplikacji procesu, wspo-mniana niewielka ilość komentarzy, może oznaczać, że:

• inspektorzy nie mieli wystarczająco czasu;• inspektorzy otrzymali zadania spoza ich

domeny;• inspektorzy nie zostali dostatecznie zmo-

tywowani.

Pierwszy przypadek odnosi się do sytuacji, gdy inspektor nie był w stanie należycie przygo-tować się do inspekcji z powodu nadmierne-go obciążenia innymi obowiązkami. Najczę-ściej jest tak, że inspektor musi dzielić swój czas miedzy zadania inspekcji i inne zadania projektowe.

Nie jest to dziwne i nie będzie zaskocze-niem, jeżeli codzienne potrzeby projektu bę-dą brały górę nad zadaniami inspekcji (chy-ba że priorytety zostaną celowo ustawione inaczej).

Jeżeli jednak dodatkowo tempo inspekcji narzucone przez kierownika będzie zbyt du-że – materiał zostanie przeanalizowany po-bieżnie.

Możliwe jest również, że dziedzina w któ-rej inspektor jest ekspertem, nie pokrywa się z umiejętnościami wymaganymi do wyznaczo-nego mu zadania. Dociekliwy inspektor posta-nowi zdobyć nową wiedzę (oczywiście jeżeli będzie miał na to wystarczającą ilość czasu).

Leniwy – wystawi kilka poślednich ko-mentarzy dla spokoju sumienia. Dociekli-wy inspektor, zamiast wykorzystywać swoje zdolności, będzie godzinami douczał się w Internecie. Leniwy da fałszywe poczucie wy-

sokiej jakości przedmiotu analizy. Obie te sy-tuacje są negatywne a wynikają ze złej aloka-cji zasobów.

Pozostaje kwestia motywacji: nie łudźmy się, inspekcja nie jest najbardziej efektow-nym z zadań projektowych. To żmudna praca wymagająca wiele samodyscypliny. Jej efekty nie zawsze są od razu widoczne. Brak prze-konania o jej potencjalnych korzyściach mo-że sprawić, że inspektorzy potraktują swoje zadanie bez należytego zaangażowania. Re-zultatami takich działań nie trzeba chyba straszyć.

Przyczyną tego problemu mogą być nie-jasno określone lub słabo mierzalne cele in-spekcji.

Oprócz powyższych korekt, powinniśmy również zadać sobie następujące pytania:

• Czy zastosowane przez nas techniki in-spekcji sprawdziły się? Czy któreś z nich powinniśmy używać częściej (więcej z nich zaczerpnąć)?

• Czy perspektywy są efektywne? Które z nich, ze względu na stan (dojrzałość) pro-duktu, są najważniejsze? Czy mają odpo-wiedni zasięg (cały produkt/najważniejsze moduły)?

• Czy można usprawnić analizę poprzez stosowanie narzędzi? Czy narzędzia uży-te (powstałe) podczas analizy powin-ny być włączone na stałe do konfiguracji projektu?

• Czy komentarze są użyteczne? Czy łatwo odtworzyć problemy, które sygnalizują?

Powyższe rozważania nazywamy walidacją. To jest sprawdzenie, czy robimy dobre rze-czy [6].

Podsumowanie części pierwszejW pierwszej części opracowania skoncentro-wałem się na wprowadzeniu do zagadnień z dziedziny inspekcji oraz na skonstruowaniu odpowiedniego procesu. Proces ten został oparty na modelu PDAC, który można od-naleźć m.in. w ISO 9001. Podstawowymi je-go wyróżnikami są elastyczność, skalowalność i uniwersalność.

Choć większość przykładów odnosiła się do implementacji oprogramowania – pokazałem, że takie same reguły dotyczą np. inspekcji do-kumentów.

W drugiej części opracowania zamieszczę uwagi dotyczące sposobów realizacji opisane-go procesu.

ARKADIUSZ MERTAAutor od 10 lat zajmuje się zagadnieniami pro-

jektowania i realizacji oprogramowania. Aktual-

nie jest pracownikiem Silicon & Software Systems

Polska zatrudnionym na stanowisku menadżera

projektów.


09/200842

Testowanie oprogramowania Rzeczywisty czas czy rzeczywisty Linux?


W celu rozszerzenia funkcjonalności czasu rzeczywistego, których bra-kowało w systemie operacyjnym

Linux, stworzono kilka produktów, które roz-wiązywały ten problem z różnym skutkiem. Na przykład, niektórzy z producentów wykorzy-stali możliwości struktury dwurdzeniowej, któ-ra daje możliwość korzystania z niechronione-go środowiska wykonawczego dla zadań reali-zowanych w czasie rzeczywistym i zmusza pro-gramistów do pisania nowych sterowników i pro-jektowania usług nawet w przypadku obecności ich odpowiedników w systemie Linux. W niniej-szym artykule rozpatrywane jest inne podejście, u którego podstaw leży wykorzystanie systemu operacyjnego czasu rzeczywistego (RTOS), opra-cowanego zgodnie ze standardem POSIX specjal-nie dla aplikacji wbudowanych. Podejście takie pozwala programistom systemu Linux nie tylko korzystać ze znanych sposobów programowania, ale także na wykorzystanie kluczowych zalet mo-delu otwartego kodu źródłowego systemu opera-cyjnego Linux. Oprócz tego takie podejście daje możliwość pracy z wieloma usługami systemo-wymi, których nie ma w standardzie systemu

operacyjnego Linux i jego dodatków, odpowiada-jących za pracę w trybie czasu rzeczywistego.

Możliwości czasu rzeczywistego w systemie operacyjnym LinuxSystem operacyjny Linux stawia programistę systemów wbudowanych przez dylematem. Z jednej strony, Linux pozwala mu na pracę z wie-loma edytorami, wykorzystanie dużej części ist-niejącego kodu źródłowego i interfejsów progra-mowania aplikacji (API) standardu POSIX. Jed-nocześnie standardowe jądro systemu Linux nie daje takich możliwości pracy w trybie cza-su rzeczywistego, jak gwarantowany czas reakcji i mikrosekundowe wstrzymania, koniecznych w wielu urządzeniach.

Przyczyną jest to, że system operacyjny Linux ma architekturę o ogólnym przeznaczeniu. Sys-tem Linux został stworzony w celu zachowania funkcjonalności systemu UNIX i w znacznym stopniu udoskonalony na potrzeby technologii sie-ciowych i informacyjnych. Wymogi tych techno-logii w znacznym stopniu różnią się od wymogów stawianych przez systemy wbudowane, � tym sa-mym rozwiązania kompromisowe, których reali-zacja ma miejsce w systemie Linux, często nie mo-gły być zastosowane w aplikacjach wbudowanych.

Zapoznajmy się dla przykładu z mechanizmem szeregowania procesów. Zamiast korzystać z szere-gowania z wywłaszczaniem opartego na prioryte-tach tak, jak miałoby to miejsce w RTOS, system operacyjny Linux wykorzystuje strategię równo-

uprawnienia, która daje każdemu z procesów moż-liwość wykonania. W efekcie, procesy z wysokim priorytetem, które wymagają szybkiej realizacji, nie zawsze mają możliwość uzyskania natychmia-stowego dostępu do zasobów procesora. W rzeczy-wistości system operacyjny czasami wstrzymuje wykonanie procesu z wysokim priorytetem, aby udostępnić część zasobów procesora procesowi o niskim priorytecie. Co więcej, system operacyjny gubi informacje dotyczące priorytetów, kiedy ste-rownik lub inna usługa systemowa, zwykle reali-zowana poprzez jądro systemu, realizowana jest po stronie wskazanego przez użytkownika wąt-ku. Takie zachowanie powoduje nieprzewidywal-ne opóźnienia i nie pozwala na realizację krytycz-nych procesów na czas.

Należy zaznaczyć, że takiego modelu szerego-wania nie należy traktować jako wady systemu operacyjnego Linux. Przykładowo, model ten zapewnia wysoką wydajność na ogólnym pozio-mie, która potrzebna jest aplikacjom biurowym i serwerowym. Tym niemniej, nie spełnia ocze-kiwań w sytuacji, gdy musi pracować w środowi-skach szeregowania deterministycznego takich, jak routery sieciowe, narzędzia medyczne, ro-boty przemysłowe i aplikacje wykorzystywane w przemyśle motoryzacyjnym, dla których nie był zaprojektowany.

W celu usunięcia mankamentów, które nie pozwalają systemowi operacyjnemu Linux na pracę w czasie rzeczywistym, stworzono kilka produktów. Niektóre z nich opracowane zo-stały przez producentów komercyjnych, in-ne są efektem prac projektowych na otwar-tym kodzie źródłowym. Istnieją także rozwią-zania, w którym połączono te dwa podejścia. Tym niemniej żadna z zastosowanych filozofii nie stała się standardem. Co więcej, niektóre z tych rozwiązań odchodzą od standardowych

Rzeczywisty czas czy rzeczywisty Linux?

Twórcy systemów wbudowanych coraz bardziej interesują się systemem operacyjnym Linux, czego głównym powodem jest otwarta struktura jego kodu źródłowego. Tym niemniej, standardowe jądro Linux nie zapewnia możliwości systemu czasu rzeczywistego, wymaganych w wielu systemach wbudowanych, takich jak przewidywalny czas odpowiedzi i mikrosekundowe wstrzymania.

Dowiesz się:• Jakie są możliwości czasu rzeczywistego Linuxa;

• Jakie są możliwości czasu rzeczywistego RTOS

QNX.

Powinieneś wiedzieć:• Co to jest czas rzeczywisty;

• Czym są systemy operacyjne czasu rzeczywistego.

Poziom trudności

Racjonalny wybór

09/200842

Testowanie oprogramowania Rzeczywisty czas czy rzeczywisty Linux?


zasad programowania dla systemu operacyjne-go Linux i standardu POSIX.

Możliwości czasu rzeczywistego poza systemem LinuxNiektórzy z producentów starają się zapewnić działanie systemu operacyjnego Linux w cza-sie rzeczywistym kosztem jego realizacji w try-bie zadania w jądrze czasu rzeczywistego (Rysu-nek 1). Wszystkie pozostałe zadania, wymagają-ce szeregowania deterministycznego, także reali-zowane są w jądrze pod kontrolą mechanizmu wywłaszczania, jednak posiadają wyższy priory-tet niż sam system operacyjny Linux. W ten spo-sób zadania te wywłaszczają system operacyjny Linux w momencie, w którym muszą zostać zre-alizowane i zwracają mu zasoby procesora po za-kończeniu swojej pracy.

W opisanym modelu dwurdzeniowym jądro czasu rzeczywistego zawsze daje pierwszeństwo przerwaniom sprzętowym. Jeśli przerwanie re-alizowane jest w trybie czasu rzeczywistego, ją-dro zaplanuje wykonanie tego zadania. W prze-ciwnym razie jądro przekaże zadanie do wyko-nania przez system operacyjny Linux. Działa-nia te są transparentne dla aplikacji, działających w środowisku Linux; wyjątek stanowi rzecz ja-sna czas procesora przeznaczony na pracę jądra czasu rzeczywistego i jego zadań. Tym niemniej, opisane podejście ma kilka wad, które zostały opisane w kolejnych rozdziałach.

Zwiększenie natężenia podczas kodowaniaZadania wykonywane w jądrze czasu rzeczywi-stego nie mogą w pełni korzystać z istniejących usług systemu operacyjnego Linux — systemów plików, sieci itd. W rzeczywistości zwrot zadania w czasie rzeczywistym do dowolnej usługi Linux powoduje te same problemu z wywłaszczaniem, które powodują niemożność deterministyczne-go zachowania procesów Linux.

W takim przypadku konieczne jest utworze-nie nowych sterowników i usług systemowych dla jądra czasu rzeczywistego, nawet jeśli analo-giczne usługi istnieją w systemie operacyjnym Linux. O ile liczba takich gotowych sterowni-ków nie jest duża, twórcy oprogramowania dla

systemu operacyjnego Linux zazwyczaj muszą tworzyć potrzebne sterowniki na nowo, często korzystając z nieznanego sobie interfejsu pro-gramowania.

Niezawodne środowisko wykonawczeSystem operacyjny Linux oparty jest o architek-turę z jednolitym jądrem. Oznacza to, że aplika-cje działają w przestrzeni użytkownika z pamię-cią chronioną. Tym niemniej, zadania realizowa-ne w jądrze czasu rzeczywistego nie korzystają z zalet środowiska wykonawczego chronionego przez solidny układ zarządzania pamięcią, które system operacyjny Linux oferuje zwykłym pro-cesom, nie działającym w trybie czasu rzeczywi-stego. Zadania te realizowane są w niechronio-nym obszarze jądra. Co za tym idzie, dowolne zadanie czasu rzeczywistego, które zawiera typo-wy błąd w kodzie, np. błędny znacznik C, zdol-ne jest do spowodowania nieodwracalnej awarii jądra systemu. Cecha taka jest problemem, po-nieważ większość systemów czasu rzeczywiste-go ma bardzo wysokie wymagania dotyczące niezawodności.

Ograniczona przenośnośćW podejściu dwurdzeniowym zadania czasu rzeczywistego są nie procesami systemu opera-cyjnego Linux, a wątkami i interpretatorami sy-gnałów, które stworzone zostały dla wąskiej gru-py interfejsów programowania aplikacji (API) standardu POSIX lub, w niektórych przypad-kach, dla niestandardowych API. Przeniesienie istniejącego kodu i aplikacji systemu Linux do środowiska czasu rzeczywistego jest zadaniem trudnym.

Problem ten zwiększa się także dlatego, że w różnych implementacjach systemów dwurdze-niowych wykorzystywane są różne API. Zada-nia, które zostały stworzone w celu wykorzy-stania w aplikacjach czasu rzeczywistego jedne-go producenta, mogą okazać się nieprzydatne w przypadku aplikacji opracowanej przez inne-go producenta. Zamiast wykorzystania ogólno-dostępnych API systemu operacyjnego Linux, producenci systemów wbudowanych zmusze-ni są do wybierania między konkurencyjnymi standardami.

Niedeterministyczne zachowanie istnie-jących aplikacji i sterowników LinuxPonieważ procesy w systemie operacyjnym Li-nux działają poza jądrem czasu rzeczywistego, ich zachowanie nie jest deterministyczne. Sze-regowanie tych procesów nadal realizowane jest przy pomocy algorytmu ze sprawiedliwym po-działem, który stosowany jest w systemie opera-cyjnym Linux.

Ograniczone możliwości projektowaniaJak już wspomniano, API wspierane przez jądro czasu rzeczywistego oferują tylko część usług API w standardzie POSIX i systemu operacyj-nego Linux. Tym samym programiści otrzymują bardziej ograniczone możliwości projektowania, niż w przypadku wykorzystania systemu opera-cyjnego Linux lub rozwiniętego RTOS.

Połączenie zaletSystem operacyjny czasu rzeczywistego QNX Neutrino jest znacznie bardziej elastycznym i niezawodnym sposobem rozwiązania proble-mów, które rozpatrujemy. Zamiast zmuszać pro-gramistów do korzystania z niepewnych rozwią-zań, QNX Neutrino oferuje sprawdzone środo-wisko operacyjne czasu rzeczywistego, które:

• pozwala programistom oprogramowania dla systemu Linux na korzystanie z istnie-jących API i modeli programowania;

• rekompensuje braki w rozszerzeniach czasu rzeczywistego dla systemu operacyjnego Li-nux dzięki bardziej rygorystycznemu mode-lowi środowiska wykonawczego, rozwinię-tym możliwościom projektowania i jednoli-temu środowisku tworzenia aplikacji czasu rzeczywistego i zwykłych aplikacji;

• stworzone jest w oparciu o takie kluczowe możliwości modelu systemu operacyjnego Linux z otwartym kodem źródłowym, jak łatwość usuwania błędów i dostosowywa-nia systemu operacyjnego do potrzeb użyt-kownika. W rzeczywistości, system opera-cyjny czasu rzeczywistego oparty o mikro-jądrową strukturę taki jak QNX Neutrino oferuje zalety obydwu możliwości;

oferuje różne usługi systemowe (np. bezpiecz-ną partycjonowanie, przetwarzanie rozproszo-ne, rozbudowany system wsparcia procesorów wielordzeniowych), których nie posiadają roz-wiązania oferowane w oparciu o system opera-cyjny Linux.

Pełna zgodność ze standardem POSIXGrupa standardów IEEE pod nazwą POSIX (Portable Operating System Interface – interfejs przenośnych systemów operacyjnych) pierwot-nie została stworzona na potrzeby systemów operacyjnych Unix i określa interfejs programo-wania, który często pozwala na pracę aplikacji, opracowanych dla jednego systemu operacyjne-go zgodnego ze standardem POSIX, w innym

Rysunek 1. W modelu dwurdzeniowym system operacyjny Linux pracuje jako zadanie o niskim priorytecie w osobnym rdzeniu czasu rzeczywistego

��

��

��

��

��

��

��

09/200844

Testowanie oprogramowania

systemie operacyjnym, zgodnym z tym standar-dem, bez konieczności wprowadzania jakichkol-wiek modyfikacji. Należy pamiętać, że standard POSIX określa nie architekturę systemu opera-cyjnego, a interfejs programowania. Z tego po-wodu system operacyjny czasu rzeczywistego zdolny jest do oferowania wsparcia tych samych interfejsów programowania w standardzie PO-SIX, co system operacyjny Linux, a także wiele cech charakterystycznych Linux, bez wykorzy-stania jego niedeterministycznego jądra.

System operacyjny czasu rzeczywistego QNX Neutrino reprezentuje podejście do programo-wania aplikacji, niezależne od realizacji: oferu-je API zgodne ze standardem POSIX, które two-rzone są w oparciu o mikrojądrową architekturę czasu rzeczywistego (Rysunek 2).

Ważną cechą RTOS QNX Neutrino jest to, że POSIX nie jest jego uzupełnieniem. Podstawo-wy składnik systemu QNX Neutrino – mikro-jądro od samego początku opracowywane było w celu zapewnienia wsparcia dla narzędzi stan-dardu POSIX pracujących w trybie czasu rzeczy-wistego, w tym także wątków. Dzięki temu sys-tem operacyjny QNX Neutrino jest maksymal-nie zgodny ze standardem POSIX, a jednocze-śnie z systemem operacyjnym Linux.

Jednolite środowiskoW RTOS QNX Neutrino aplikacje czasu rze-czywistego i pozostałe aplikacje wykonywane są w tym samym środowisku. Aplikacje czasu rzeczywistego mogą w pełni korzystać z API standardu POSIX i mają pełen dostęp do usług systemowych — interfejsów graficznych, syste-mów plików, stosów protokołów itd. Oprócz tego, istniejące aplikacje POSIX i Linux mogą działać w systemie operacyjnym QNX Neutri-no w sposób deterministyczny. I w końcu, w związku z tym, że aplikacje czasu rzeczywiste-go i aplikacje zwykłe działają w tym samym śro-dowisku, komunikacja między procesami jest znacznie prostsza.

Otwartość na rozwiązywanie problemów i dostosowywanie systemu operacyjnegoTym niemniej, zgodność systemu operacyjnego czasu rzeczywistego z systemem Linux jest za-letą pozorną, jeśli RTOS nie tworzy modelu na bazie otwartego kodu źródłowego, dla którego większość programistów wykorzystuje Linux. Otwartość kodów źródłowych programów po-zwala programistom na analizowanie architektu-ry systemu operacyjnego w celu lepszej integracji z nią własnych kodów, adaptowania komponen-tów systemu operacyjnego do specyficznych wy-mogów aplikacji, a także przyspieszenia proce-su usuwania błędów w programach tworzonych przez programistów oraz problemów związa-nych z nieoczekiwanymi efektami wykonania ko-du systemu operacyjnego. Krótko mówiąc, pro-gramiści są w pewnym stopniu niezależni od do-stawcy systemu operacyjnego i mogą pracować z systemem samodzielnie (co nie jest możliwe przy wykorzystaniu modelu „czarnej skrzynki” w wie-lu komercyjnych systemach operacyjnych), choć jednocześnie są zmuszeni do samodzielnego pro-wadzenia własnego systemu operacyjnego.

System operacyjny czasu rzeczywistego QNX Neutrino oferuje te zalety na dwa sposoby: po pierwsze z pomocą rozszerzalnej architektury mikrojądrowej, a po drugie dając dostęp do kodu źródłowego sterowników, bibliotek, usług siecio-wych i pakietów BSP, w tym do dokładnie udo-kumentowanych pakietów projektowania ste-rowników (DDK) do wielu urządzeń.

W związku z tym, że QNX Neutrino jest mi-krojądrowym systemem operacyjnym, można go dostosowywać do potrzeb użytkownika. Za wy-jątkiem niektórych podstawowych usług (takich jak szeregowanie, timery, obsługa przerw), któ-re znajdują się w obrębie jądra, większość usług systemowych (sterowniki, systemy plików, sto-sy protokołów itd.) to aplikacje umieszczone w przestrzeni użytkownika poza jądrem. Dzięki te-mu opracowanie własnych sterowników i wyspe-cjalizowanych rozszerzeń dla systemu operacyj-

nego nie wymaga znajomości jądra i korzystania ze specjalnych debugerów jądra. Opracowywa-nie rozszerzeń systemu operacyjnego jest tak sa-mo łatwe, jak w przypadków zwykłych aplikacji, ponieważ rozszerzenia są programami znajdują-cymi się w przestrzeni użytkownika. Programy te można debugować za pomocą standardowych narzędzi opracowania kodu, znanych każdemu twórcy oprogramowania dla systemu Linux.

Redukcja nakładów pracyJak już wspomniano, zastosowanie dwóch jąder zmusza programistów do pisania własnych ste-rowników, z wykorzystaniem nieznanych inter-fejsów programowania. Jak w większości środo-wisk operacyjnych, opracowanie tych sterowni-ków wymaga zastosowania złożonych narzędzi debugowania jądra, długiej jego kompilacji i ko-rzystania z drogich usług programistów.

System operacyjny czasu rzeczywistego QNX Neutrino pozwala na rozwiązanie tego proble-mu na kilka sposobów. Po pierwsze, QNX Neu-trino należy do zaawansowanych systemów ope-racyjnych z dużą ilością użytkowników i oferuje wsparcie wielu sterowników do standardowych urządzeń. Jak już wspomniano, wszystkie ste-rowniki w systemie QNX Neutrino działają w przestrzeni użytkownika, a co za tym idzie, moż-na je opracowywać za pomocą standardowych narzędzi i metod tworzenia kodu źródłowego. Zadanie to jest prostsze dzięki pakietom projek-towania sterowników firmy QNX, w skład któ-rych wchodzi dokumentacja, biblioteki, pliki na-główkowe i kod źródłowy, na podstawie którego można tworzyć różne sterowniki.

Dodatkowe usługi mikrojądrowePonieważ QNX Neutrino jest mikrojądrowym systemem operacyjnym przeznaczonym dla wbudowanych systemów, w jego skład wcho-dzą usługi, których nie ma zarówno w standar-dowej dystrybucji systemu Linux, jak i w rozsze-rzeniach czasu rzeczywistego dla tego systemu. Usługi te opisane są w kolejnych rozdziałach.

Zaawansowane wsparcie wieloproceso-wości dla procesorów wielordzeniowychSystem operacyjny czasu rzeczywistego QNX Neutrino od początku był budowany z my-

Rysunek 3. Konfigurator systemu QNX Momentics pozwala programistom na wizualizację złożonych zachowań systemu wielordzeniowego i koncentrację wysiłków na obszarach, które gwarantują maksymalną równoległość i wydajność

Rysunek 2. Mikrojądro RTOS QNX Neutrino zawiera tylko podstawowe usługi systemowe. Wszystkie usługi wyższego poziomu, w tym sterowniki i stosy protokołów, działają jako procesy dodatkowe, które umieszczone są w przestrzeni użytkowej. W efekcie tego programiści mogą bez problemów rozszerzać funkcjonalność systemu poprzez usługi specjalistyczne, bez konieczności skomplikowanego programowania i debugowania kodu rdzenia.

��

��

��

��

��

��

��

��

09/200846

Testowanie oprogramowania

ślą o wieloprocesowym przetwarzaniu danych. W 1997 roku firma QNX wprowadziła na ry-nek technologię wieloprocesowości symetrycznej (SMP) i zajmowała się jej rozwojem na przestrzeni ostatniego dziesięciolecia. Niedawno firma QNX zaprezentowała innowacyjną technologię wielo-procesowości hybrydowej (BMP). Wieloproceso-wość hybrydowa pozwala na realizację istnieją-cych aplikacji na procesorach wielordzeniowych bez wprowadzania zmian, a jednocześnie daje aplikacjom, dopuszczającym działanie równole-głe, możliwość działania w pełnym trybie SMP, co zapewnia maksymalną skalowalność. Wieloproce-sowość hybrydowa pozwala na przydzielenie ist-niejącej aplikacji i wszystkich jej wątków do jedne-go jądra, co zapewnia poprawność funkcjonowa-nia aplikacji, nawet jeśli wykorzystywane są w niej metody synchronizacji wątków, nieprzystosowane do pracy w środowisku wielordzeniowym.

Zintegrowane środowisko programistyczne QNX Momentics, utworzone zgodnie ze stan-dardami Eclipse, zawiera także możliwości wie-loprocesowości i daje dostęp do narzędzi wizuali-zacji w celu dokonywania analizy, debugowania i optymalizacji systemów wielordzeniowych (Rysu-nek 3). W odróżnieniu od tradycyjnych narzędzi, to instrumentarium odzwierciedla działania za-chodzące w całym systemie wielordzeniowym, co pozwala programistom na ujawnianie potencjal-nych możliwości obróbki równoległej, zmniejsze-nie ilości zbędnej migracji wątków między rdze-niami, ograniczenie kosztownej komunikacji mię-dzy procesami i lokalizację złożonych problemów rywalizacji o zasoby, często pojawiające się w syste-mach wielordzeniowych. Przedstawienie całego systemu, które umożliwia to instrumentarium, w połączeniu z szerokimi możliwościami wielopro-cesowości systemu operacyjnego QNX Neutrino pozwala na znaczne ograniczenie nakładów pracy, koniecznych podczas przejścia ze środowiska jed-nordzeniowego do wielordzeniowego.

Bezpieczeństwo i dostępność dzięki gwa-rantowanemu wyodrębnieniu zasobów procesoraWiele współczesnych systemów wbudowanych to urządzenia sieciowe, których funkcjonalność rozszerzana jest przy pomocy niestabilnych apli-kacji dodatkowych i składników informacyjnych. Bezpieczeństwo i dostępność systemu mogą być zakłócone, jeśli architektura systemu nie zawiera odpowiednich środków zaradczych. Na przykład, szkodliwe programy mogą spowodować krytyczne awarie podstawowych funkcji systemu, pozbawia-jąc je dostępu do zasobów procesora.

W celu rozwiązania tego problemu, system ope-racyjny QNX Neutrino wspiera technologię inte-ligentnego partycjonowania, która pozwala na łą-czenie aplikacji w bezpieczne rozdziały i przydzie-lenie każdemu z nich gwarantowanej ilości pamię-ci i czasu procesora. Dzięki temu pamięć i proce-sor są dostępne dla najważniejszych procesów na-wet w przypadku dużego obciążenia mocy obli-czeniowych oraz odmowy wykonania poleceń.

Oprócz tego, technologia inteligentnego party-cjonowania firmy QNX może dynamicznie prze-nosić moc procesora z partycji, które nie są zaję-te, do partycji, które wymagają dodatkowym mo-cy procesora, to znaczy ilość obsługiwanych party-cji zmienia się tylko w przypadku pełnego jego ob-ciążenia. Dzięki temu system zachowuje się stabil-nie przy maksymalnym obciążeniu, wykorzystuje 100% mocy procesora, zachowując jednocześnie bezpieczeństwo dzięki gwarantowanemu przy-dzielaniu zasobów obliczeniowych. Aby docenić zalety inteligentnego partycjonowania, wystarczy porównać je z tradycyjnymi metodami szeregowa-nia na bazie partycji, w których niewykorzystana moc obliczeniowa procesora jest tracona, co powo-duje, że projektanci systemów muszą korzystać z droższych jednostek procesorowych.

W związku z tym, że system operacyjny Li-nux ma jednolity charakter, większość sterowni-ków, systemów plików i stosów protokołów przy-pisana jest do jądra. Z tego powodu nawet jeden błąd w którymś z wymienionych komponentów może doprowadzić do nieodwracalnego zakłóce-nia pracy jądra. Składniki systemu operacyjnego QNX Neutrino działają w osobnych przestrze-niach adresowych z chronioną pamięcią, dzię-ki czemu trudniej im zakłócić pracę jądra lub innych składników systemu. W taki sposób sys-tem QNX Neutrino zapewnia kluczowym apli-kacjom czasu rzeczywistego stabilniejsze środo-wisko wykonawcze niż system operacyjny Linux i znacznie bardziej bezpieczne, niż niechronione rdzenie czasu rzeczywistego, na których oparta jest struktura dwurdzeniowa.

Dynamiczna aktualizacja usług systemowychW mikrojądrowym systemie operacyjny można dynamicznie aktualizować praktycznie każdy z komponentów, czy to jest sterownik urządzenia, stos protokołów lub aplikację, nie przerywając przy tym pracy innych składników systemu. Po-zwala to na łatwiejsze zapewnienie współczynni-ka dostępności systemu, wynoszącego lub prze-wyższającego wartość 99,999%. W praktyce sys-temy oparte na technologiach firmy QNX czę-sto działają przez 5-10 lat bez przerwy, chociaż regularnie pojawiają się w nich nowe aplikacje i komponenty systemowe.

Przeźroczyste przetwarzanie rozproszoneSystem operacyjny QNX Neutrino oferuje usługę systemową określaną jako „przeźroczyste przetwa-

rzanie rozproszone (TDP), która zapewnia aplika-cjom przeźroczysty dostęp do sterowników urzą-dzeń, stosów sieciowych i innych usług systemo-wych, działających na innych węzłach sieci. Do-wolny proces, posiadający odpowiednie prawa do-stępu, może korzystać z prawie wszystkich zdal-nych zasobów, jakby były one dostępne lokalnie.

Przezroczystość umiejscowienia usług syste-mowych upraszcza projektowanie stabilnych systemów, oferujących funkcjonalność wyrów-nywania obciążenia. Wyobraźmy sobie na przy-kład, że komputer oferuje usługi obliczeniowe aplikacjom klienta poprzez sieć. W przypadku awarii tego komputera i uruchomienia kompu-tera zapasowego, aplikacje klienta nie muszą być powiadomione o tym, że obróbka ich zapytań dokonywana jest przez nowy komputer, ani nie jest konieczne wykonywanie dodatkowych czyn-ności w celu nawiązania połączenia z tym kom-puterem. Wszystkie komunikaty, które wysyła-ne są przez aplikacje klienta, są automatycznie kierowane pod nowy adres.

Mechanizm przetwarzania rozproszonego fir-my QNX zmniejsza także koszty urządzeń. Na przykład, jeśli jedno z urządzeń samochodowego systemu informacyjno-rozrywkowego wyposażo-ne jest w połączenie Bluetooth, inne urządzenia nie muszą posiadać własnego stosu Bluetooth i urządzenia nadawczo-odbiorczego, ponieważ mo-gą one korzystać z istniejącego połączenia.

Stabilna współpraca sieciowaMechanizm przetwarzania rozproszonego sys-temu operacyjnego QNX Neutrino, który za-pewnia niezależność od sieci, umożliwia prze-źroczystą komunikację aplikacji poprzez zapaso-we linie sieci – w przypadku awarii jednej z linii system operacyjny automatycznie przekierowu-je ruch na inne. Oprócz tego istnieje możliwość wyrównania obciążenia wszystkich linii w sieci, co zwiększa jej przepustowość. Aplikacje mogą korzystać z zalet tej usługi bez konieczności two-rzenia specjalnego kodu sieciowego.

Mniejsze zużycie pamięciW związku z tym, że mikrojądrowa architektura RTOS QNX Neutrino oferuje bardzo precyzyjną skalowalność, QNX Neutrino zapewnia znacznie bardziej kompaktowe środowisko wykonawcze, niż system Linux. To najważniejsza zaleta w przy-padku takich urządzeń, jak multimedialne i mo-toryzacyjne systemy telematyczne, w których spa-dek ceny pamięci o 2 dolary daje miliony dolarów

Rysunek 4. Dzięki technologii inteligentnego partycjonowania każdy z podsystemów otrzymuje gwarantowaną minimalną moc obliczeniową nawet przy pełnym obciążeniu procesora. Model środowiska wykonawczego o podwyższonej pewności

��

��

��

��

��

Rzeczywisty czas czy rzeczywisty Linux?


dodatkowych przychodów. Własny system okien-kowy QNX Neutrino, QNX Photon microGUI, także korzysta z architektury mikrojądrowej, co pozwala programistom na bezproblemowe „odłą-czanie” usługi graficznego interfejsu użytkownika, która nie jest potrzebna w urządzeniach z ograni-czoną ilością pamięci.

Zgodne, przetestowane jądroW odróżnieniu od monolitycznego jądra systemu operacyjnego Linux, którego zawartość zależy od konkretnego systemu wbudowanego, mikrojądro systemu QNX Neutrino można wykorzystać w szerokiej gamie produktów bez konieczności mo-dyfikacji. Praktycznie dla każdej rodziny proceso-rów, wspieranej przez system QNX Neutrino, ist-nieje tylko jedno binarne mikrojądro. Pracując na nim, programiści mogą być pewni, że przeszło ono wszelkie konieczne testy w laboratorium fir-my QNX Software Systems oraz testy eksploata-cyjne u klientów.

Kwestie dotyczące licencjonowaniaWarunki licencyjne, które określają zasady użyt-kowania i rozpowszechniania systemu operacyj-nego, mają duże znaczenie dla każdej firmy zaj-mującej się projektowaniem urządzeń wbudo-wanych. Na przykład, zasady posługiwania się systemem operacyjnym Linux oparte są na Gene-ral Public License (GPL) wersja 2, zgodnie z którą dowolne modyfikacje kodu źródłowego tego sys-temu powinny mieć otwarty charakter.

Licencja GPL wymaga, aby prace pochodne były dostępne bezpłatnie na tych samym warun-kach, jak prace źródłowe. Inaczej rzecz ujmując, jeśli programista tworzy własny kod, który mo-dyfikuje system źródłowy lub system na nim

oparty, cały kod powinien zostać otwarty. Ozna-cza to, że rozwiązania autora mogą być wykorzy-stywane przez jego konkurencję.

W chwili powstawania tego artykułu trze-cia wersja licencji GPL jest dyskutowana przez Free Software Foundation. Jest ona znacznie surowsza od wersji drugiej i, chociaż nie jest to do końca potwierdzone, licencja ta zmusi du-żą liczbę firm do ujawnienia kodu źródłowe-go swoich prac, jeżeli zdecydują się one na ko-rzystanie z programów, które są przedmiotem tej licencji.

Firma QNX Software Systems stara się zrobić wszystko, aby ochronić swoich klientów przed tego rodzaju problemami. QNX oferuje wiele zalet otwartego kodu bez ryzyka związanego z wykorzystaniem programów chronionych suro-wymi warunkami licencji.

Czysta własność intelektualnaOchrona własności intelektualnej to koniecz-ność, której świadomi są producenci systemów wbudowanych. Tym niemniej, ryzyko związane ze złamaniem praw własności intelektualnej in-nych firm często jest ignorowane.

Oprogramowanie z otwartym kodem źródło-wym nie chroni użytkowników przed złama-niem praw patentowych. Dla przykładu, sys-tem operacyjny Linux tworzony jest przez pro-gramistów, którzy nie mają możliwości ostatecz-nie udowodnić, że tworzony przez nich kod nie narusza istniejących lub przedstawionych do za-twierdzenia patentów. Ponieważ licencje na pro-dukty z otwartym kodem źródłowym nie prze-widują możliwości rekompensaty, firmy posłu-gujące się kodem źródłowych w swoich syste-mach są odpowiedzialne za możliwe naruszenie praw patentowych.

Zadanie określenia źródła i czystości otwar-tego kodu leży po stronie firmy, która korzysta z tego kodu. Przez to stosowanie otwartego ko-du nie tylko wprowadza do projektowania ele-menty ryzyka, ale także powoduje bezpośred-ni wzrost nakładów. Ryzyko złamania praw au-torskich zależy bezpośrednio od ilości kodu, a koszty są uwarunkowane koniecznością wyko-nania prawnych i technicznych ekspertyz w ce-lu kontroli czystości kodu.

Ryzyko związane z własnością intelektualną może także pojawić się przy równoległym wy-korzystaniu programów z otwartym kodem źró-dłowym w urządzeniu wbudowanym. Istnieje możliwość, że dwie prace osobno nie łamią żad-nych patentów, jednak połączenie ich prowadzi do złamania prawa własności intelektualnej.

Firma QNX Software Systems nieustannie dokłada starań, które mają na celu zapewnie-nie czystości własności intelektualnej, uwalnia-jąc swoich klientów od konieczności straty czasu i pieniędzy na rozwiązanie tych problemów. W żadnym ze składników środowiska wykonawcze-go firmy QNX nie jest wykorzystany kod, któ-ry chroniony jest licencją General Public Licen-se projektu GNU. Oprócz tego, firma QNX bie-rze na siebie odpowiedzialność za cały kod jądra swoich systemów operacyjnych niezależnie od tego, czy został on stworzony przez ekspertów firmy, czy zapożyczony z otwartych źródeł.

PodsumowaniePomimo tego, że system operacyjny QNX Neu-trino stanowi doskonałą platformę dla aplikacji czasu rzeczywistego, nie ma konieczności doko-nywania definitywnego wyboru między QNX Neutrino a systemem Linux. Projektanci, któ-rzy korzystają z API standardu POSIX, mogą tworzyć programy dla obu systemów operacyj-nych, wykorzystując każdy z nich tam, gdzie jest to najbardziej efektywne. Aby przenieść więk-szość aplikacji spod systemu Linux lub aplika-cji z otwartym kodem do systemu operacyjnego QNX Neutrino, z reguły wystarczy dokonać po-nownej kompilacji kodu źródłowego i przypisać go do bibliotek QNX Neutrino.

Tym niemniej system operacyjny QNX Neu-trino, w odróżnieniu od Linux, od początku tworzony był do pracy w trybie czasu rzeczy-wistego, a co za tym idzie, uwalnia programi-stów od wielu nakładów i problemów, charakte-rystycznych dla rozszerzeń czasu rzeczywistego. Programiści mają dostęp do programów z otwar-tym kodem w standardzie POSIX, a jednocze-śnie mogą korzystać z zalet zgodnego i spraw-dzonego środowiska czasu rzeczywistego.

PAUL N. LEROUX Analityk techniczny firmy QNX Software Systems,

[email protected]

ROMAIN SAHAManager działu systemów sieciowych firmy QNX

Software Systems, [email protected]

Rysunek 5. Przeźroczyste przetwarzanie rozproszone łączy sieć oddzielnych systemów w jedną maszynę logiczną. Pozwala to aplikacji, działającej na jednym z komputerów, na uzyskanie dostępu do zasobów (sieć, systemy plików, portów USB itd.), umieszczonych na innym węźle, bez konieczności przeprogramowania

��

��

��

��

��

��

��

��

09/200848

Programowanie JAVASwing Application Framework – GUI na nowo


W końcu firma SUN podjęła bar-dziej zdecydowane kroki, mające usprawnić działanie Java Swing

zarówno od strony użytkownika końcowego jak i programisty. Java SE w wersji 6.0 wpro-wadziła wiele pozytywnych zmian jeśli cho-dzi o funkcjonalność, szybkość działania i wy-gląd aplikacji tworzonych w Javie. Następnym krokiem, skierowanym głównie do programi-stów, jest uproszczenie tworzenia aplikacji z interfejsem użytkownika przez wprowadze-nie frameworka Swing Application Frame-work (JSR-296).

Swing Application Framework jest dłu-go oczekiwaną nakładką na niskopoziomową funkcjonalność Swinga, która znacznie ułatwia i przyspiesza pracę przy budowie GUI. Artykuł jest poświęcony zwięzłemu omówieniu SAF, w szczególności zobaczymy jak ułatwia on opro-gramowanie typowych elementów aplikacji z GUI (ang. Graphical User Interface) – inicjali-zacji i zamykania aplikacji, programowania wie-lowątkowego, obsługi zdarzeń.

Naszym celem jest utworzenie prostej apli-kacji szukającej plików na dysku, na jej bazie

poznamy najważniejsze elementy interesują-cej nas technologii.

Do czego służy SAFSAF z założenia ma być rozwiązaniem pro-stym, koncentrującym się na zasadniczych problemach, na jakie napotykamy się two-rząc programy z interfejsem użytkownika w Javie.

SAF zajmuje się następującymi aspektami tworzenia aplikacji z interfejsem użytkownika:

• cyklem życia aplikacji od jej uruchomienia po zamknięcie;

• zarządzaniem zasobami: łańcuchami zna-ków, kolorami, ikonami, czcionkami itp. artefaktami, które występują w typowej aplikacji. Oczywiście wszystkie zasoby mogą być internacjonalizowane/lokalizo-wane;

• obsługą zdarzeń (co ma się stać, gdy użyt-kownik naciśnie przycisk X). W szczegól-ności SAF upraszcza znacząco obsługę dłu-gotrwałych zdarzeń, które powinny wy-konywać się w wątkach roboczych, a nie głównym;

• przechowywaniem stanu aplikacji. Po za-mknięciu aplikacji pamięta ona jaki był stan interfejsu użytkownika (rozmiar okien, ich położenie) przed zamknię-ciem.

Żeby nie przedłużać wstępu przejdźmy do rze-czy, czyli przyjrzyjmy się przykładowej aplika-cji Szukacz (Rysunek 1). Szukacz jest napisaną w Javie kulawą i ubogą funkcjonalnie namiast-ką unixowego grep-a, ma za to graficzny inter-fejs użytkownika.

Aplikacja jest skonstruowana inaczej niż w większości demonstracyjnych aplikacji Swing Application Framework, które można zna-leźć w Internecie. Problemem używanych tam przykładów jest ich mała użyteczność w rzeczy-wistej sytuacji. Przykłady te dzielą się na dwie grupy:

• aplikacje wyklikane od początku do koń-ca w środowisku NetBeans, korzystające z kreatorów kodu tam dostępnych – SAF jest produktem firmy SUN, podobnie jak NetBeans, który w najnowszej wersji za-wiera wsparcie dla SAF;

• aplikacje napisane całkowicie ręcznie, włącznie z elementami GUI.

Żadna z tych sytuacji nie jest typowa. Po pierwsze, nie każdy chce używać NetBean-sa (fakt, jest on bardzo dobrym produktem jeśli chodzi o tworzenie GUI), a nawet jeże-li go używamy, to istnieje duża szansa, że ma-my już napisany kawałek kodu, który nie uży-wa SAF i chcielibyśmy go gładko zintegrować frameworkiem.

Co do drugiej sytuacji, jeśli nie jesteśmy maniakalnymi zwolennikami ręcznego pi-sania kodu GUI, co zazwyczaj kończy się mniejszą lub większą katastrofą połączoną z gromami rzucanymi na Swinga i Javę w ogó-le, to pewnie chcemy użyć jakiegoś wizual-nego narzędzia, które pozwoli nam wykli-

Swing Application Framework

Technologia Java Swing, pozwalająca tworzyć graficzny interfejs użytkownika w języku Java, od samego początku swojego istnienia, czyli od ponad 10 lat, była bardzo pechowa. Pierwsze implementacje były mało wydajne i uciążliwe w użyciu, kolejne wersje tego interfejsu powoli wprowadzały potrzebne ulepszenia, ale nigdy Swing nie stał się czymś lubianym i docenianym.

Dowiesz się:• co to jest Swing Application Framework (SAF);

• w jaki sposób tworzyć aplikacje GUI w Java

Swing wykorzystując SAF.

Powinieneś wiedzieć:• czytelnik powinien znać podstawy języka Java

oraz technologii Java Swing.

Poziom trudności

GUI w języku Java na nowo

09/200848



kać strukturę interfejsu użytkownika. Narzę-dzie to na pewno jeszcze nie wspiera SAF, a my oczywiście nie chcemy być zmuszeni do rezygnacji z jego użycia.

Zobaczymy dalej jak tworzyć GUI tak, jak nam jest najwygodniej i móc go w każdej chwili zintegrować z SAF. Zatem do dzieła.

Cykl życia aplikacjiZajmiemy się teraz podstawowym elemen-tem każdej aplikacji SAF, czyli klasą uru-chamiającą interfejs użytkownika. Musi ona dziedziczyć po klasie Application lub SingleFrameApplication frameworka. Kla-sa SingleFrameApplication daje nam kil-ka dodatkowych usług oraz gotową instan-cję klasy reprezentującej okno w Swingu, czyli JFrame.

Z powodów opisanych powyżej będziemy jednak samodzielnie tworzyć okno aplikacji – chcemy używać SAF, ale nie chcemy, żeby nam się on w aplikacji za bardzo panoszył. Kla-sa Application jest abstrakcyjna, dziedzicząc po niej musimy zaimplementować samodziel-nie metodę void startup(), którą za chwilę się zajmiemy.

Popatrzmy na Listing 1, na którym znajduje się główna klasa aplikacji Szukacz, MainApp.

Zacznijmy analizę klasy MainApp od końca, od metody main(String[]). Metoda Application.launch(Application) uruchamia ca-łą aplikację. Jest ona bardzo wygodna, bo dzię-ki niej nie musimy pamiętać o inicjalizacji in-terfejsu użytkownika z poziomu odpowied-niego wątku – wątku EDT (ang. Event dispat-ching thread).

Zróbmy w tym miejscu małą dygresję, żeby ustalić terminologię no i żeby osoby mniej oby-te z tematem wiedziały w czym rzecz.

Trzeba pamiętać, że typowa, ale bardziej zło-żona aplikacja Swingowa, potrzebuje co naj-mniej trzech wątków:

• głównego, który powinien tylko urucho-mić aplikację;

• wątku Event dispatching thread, w którym, i tylko w którym można tworzyć i modyfiko-wać komponenty interfejsu użytkownika;

• wątku lub wątków roboczych, które wy-konują wszystkie dłużej trwające zadania – nie chcemy ich wykonywać w ramach EDT, żeby nie blokować interfejsu użyt-kownika.

Listing 1. Główna klasa aplikacji Szukacz inicjalizuje powstawanie interfejsu użytkownika oraz zawiera obsługę zakończenia działania aplikacji

package pl.xoft.saf.finder.ui;

import java.awt.Component;

import java.util.EventObject;

import javax.swing.JOptionPane;

import org.jdesktop.application.*;

public class MainApp extends SingleFrameApplication{

ResourceMap resource;

ApplicationContext ctxt;

@Override

protected void startup() {

FrameView view = new MainViewFrame(this);

view.setFrame(new MainFrame());

show(view);

addExitListener(new ExitListener() {

public boolean canExit(EventObject e) {

Object[] options = {resource.getString("label.yes"),

resource.getString("label.no")};

Object source = (e != null) ? e.getSource() : null;

Component owner =

(source instanceof Component) ?

(Component)source : null;

boolean mayExit = JOptionPane.showOptionDialog(

owner,

resource.getString("label.exit"),

resource.getString("Application.name"),

JOptionPane.YES_NO_OPTION,

JOptionPane.QUESTION_MESSAGE,

null,

options,

options[1]) == JOptionPane.YES_OPTION;

return mayExit;

}

public void willExit(EventObject event) {

//do nothing

}

});

}

@Override

protected void initialize(String[] args) {

System.out.println("Inicjalizacja... ");

this.ctxt = getContext();

ResourceManager mgr = ctxt.getResourceManager();

resource = mgr.getResourceMap(MainApp.class);

}

@Override

protected void shutdown() {

System.out.println("Koniec pracy!! Czyścimy");

}

public static void main(String[] args) {

Application.launch(MainApp.class, args);

}

}

Rysunek 1. Główny ekran aplikacji Szukacz

09/200850



Często popełnianym błędem jest inicjalizacja GUI z poziomu wątku głównego, a nie EDT; zazwyczaj nie powoduje to problemów, ale zdarza się, że pojawiają się przykre i trudne do wykrycia błędy.

Metoda Application.launch() powoduje rozpoczęcie wywołania kolejnych metod odpo-wiedzialnych za obsługę cyklu życia aplikacji.

Jedyna metoda, którą musimy przesłonić to void startup(), pozostałymi możemy za-jąć się wtedy, gdy są nam do czegoś potrzebne. Przyjrzyjmy się teraz metodom, które mamy do dyspozycji:

• metoda void initialize(String[]). Mo-żemy w niej wykonać różnego rodzaju czynności inicjalizacyjne, które są potrzeb-ne przed konstrukcją interfejsu użytkow-nika. Jako parametr przyjmuje ona automa-tycznie tablicę parametrów uruchomienio-wych aplikacji;

• metodę void startup() musimy prze-słonić obowiązkowo: w tej metodzie

inicjalizujemy tworzenie interfejsu użytkownika. Musi powstać w niej in-stancja klasy FrameView, która jest mo-stem pomiędzy SAF a oknem aplika-cji, reprezentowanym u nas przez klasę MainFrame. Potencjalnie MainFrame nie musi nic wiedzieć o SAF, dzięki czemu mamy dużą swobodę pracy z nią – nie jesteśmy uzależnieni od SAF, ale w każ-dej chwili możemy używać tych jego ele-mentów, które chcemy – demonstruje to diagram na Rysunku 2;

Po lewej stronie diagramu znajdują się klasy zależące silnie od klas interfejsu programistycznego SAF, najważniejsza z nich to główna klasa aplikacji, MainApp. Po prawej stronie diagramu są klasy im-plementujące graficzny interfejs użyt-kownika. Mogą one w ogóle nie zależeć od SAF, albo zależeć w taki sposób, że-by nie przeszkadzało nam to używać do-wolnego narzędzia do graficznego two-rzenia GUI. Klasyczny sposób użycia

SAF polega na tym, że klasa okna aplika-cji dziedziczy po klasie FrameView SAF, czego właśnie chcemy uniknąć

• metody void ready() nie ma na Listingu 1, przesłaniamy ją wtedy, gdy potrzebne są jakieś czynności inicjalizacyjne po utwo-rzeniu GUI, które mogą na przykład za-brać więcej czasu. Zazwyczaj chcemy jak najszybciej pokazać użytkownikowi inter-fejs aplikacji, a gdy się on mu z podziwem przygląda, możemy spokojnie dokończyć inicjalizację;

• metoda void exit() kończy działanie aplikacji. Odbywa się to w ten sposób, że jeśli z poziomu aplikacji wywołane jest zdarzenie żądające zakończenia pracy (np. klikniemy przycisk z krzyżykiem okienka aplikacji), to przejmowane jest ono przez klasę typu ExitListener, która spraw-dza, czy wolno zakończyć działanie apli-kacji. W naszym przypadku w metodzie startup() dodajemy naszą implementa-cję ExitListener -a, który wyświetla okno dialogowe z pytaniem o pozwolenie za-mknięcia aplikacji;

• metoda void shutdown(). Gdy zapadnie decyzja, że możemy zamknąć aplikację, to ostatnią rzeczą, jaka jest robiona, jest wy-wołanie tej metody.

Zarządzanie zasobamiKolejnym elementem, który daje nam SAF jest ustandaryzowane zarządzanie zasoba-mi. Dotyczy to w zasadzie wszystkich skład-ników aplikacji, które nie są kodem Java: na-pisów na etykietach, przyciskach, itp., ikon, używanych czcionek, kolorów. W jaki sposób to się odbywa?

Zasoby dzielą się na globalne i lokalne. Za-łóżmy, że główną klasą naszej aplikacji jest GlownaKlasaAplikacji.

Zasoby globalne są umieszczone wte-dy w pliku GlownaKlasaAplikacji.proper-ties, który musi się znajdować w pakiecie na-zwa.pakietu.resources, przy założeniu, że klasa GlownaKlasaAplikacji znajduje się w pakie-cie nazwa.pakietu. W naszym przypadku za-soby globalne dla języka polskiego znajdzie-my w pliku MainApp.properties, a dla języ-ka angielskiego w MainApp_en_US.proper-ties. Oba pliki są w pakiecie pl.xoft.saf.fin-der.ui.resources.

Zasoby lokalne są przechowywane zgod-nie z tę samą konwencją co powyżej – każ-da klasa ma swój plik z zasobami umieszczo-ny w pliku properties o nazwie takiej samej

Rysunek 2. Architektura aplikacji Szukacz

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Rysunek 3. Fragment menu aplikacji Szukacz, pozwalający zmieniać wielkość czcionki.

09/200850



jak nazwa klasy. Do zasobów dostajemy się tak, jak to demonstruje listing klasy MainApp (Listing 1).

W metodzie initialize(String[]) two-rzymy uchwyt do bardzo użytecznej klasy, ApplicationContext, reprezentującej środo-wisko (kontekst) działania aplikacji. Następ-nie z kontekstu aplikacji wyciągamy klasę za-rządzającą zasobami: ResourceManager. W kla-sie MainApp zasobów używamy przy tworzeniu okna dialogowego, które pojawia się, gdy ktoś chce zamknąć aplikację.

Bardzo użyteczną cechą SAF jest automa-tyczna konwersja niektórych zasobów na kla-sy Java.

Przeanalizujmy pokazany na Listingu 2 frag-ment klasy MainFrame. Interesuje nas element menu pozwalający zwiększyć lub zmniejszyć wielkość czcionki.

Aby menu było czytelniejsze jest tam umieszczona odpowiednia ikona (Rysunek 3). Bez SAF sami byśmy musieli z łańcucha znaków, reprezentującego konkretny zasób, wyprodukować obiekt klasy ImageIcon, a tu-taj wystarczy, że użyjemy metody ResourceMap.getIcon(String). Podobnie konwerto-wane są z łańcuchów znaków definicje czcio-nek i kolory.

Niby drobne udogodnienie, ale jeśli doło-żymy do tego internacjonalizację i pomno-żymy wszystko przez, powiedzmy, 500 wy-stąpień w dużej aplikacji, to okaże się, że jednak trochę rękę i klawiaturę oszczędzi-liśmy.

Akcje – obsługa zdarzeńWreszcie dochodzimy do najciekawszego ele-mentu SAF, uproszczonego definiowania ak-cji. W Swingu jeśli chcemy, żeby jakiś kom-ponent oprócz siedzenia w oknie aplikacji mógł zrobić coś pożytecznego, musieliśmy dodać do niego nasłuchiwacza zdarzeń (Ac-tionListener lub innego), a następnie tegoż nasłuchiwacza zaimplementować jako osob-ną klasę.

SAF całą tę procedurę bardzo upraszcza, po prostu tworzymy metodę, oznaczamy ją meta-daną @Action i dodajemy do mapy akcji infor-mację o tym, że pojawiła się obsługa pewnego zdarzenia.

Popatrzmy na fragment kodu, wzięty z klasy MainPane (Listing 3).

Interesuje nas wyłącznie obsługa przyci-sku Szukaj, dlatego cały kod służący do in-nych celów został usunięty z Listingu 3. W linii 32 zaczyna się metoda search, oznacza-my ją metadaną @Action, żeby zarejestrować ją jako akcję.

Pozostaje jeszcze powiązać odpowiedni przycisk (JButton1) z tę akcją. Robimy to w li-nii 23, wykorzystując klasę javax.swing.Ac-tionMap.

Warto zwrócić uwagę na to, że może-my się odwoływać do akcji zdefiniowanych

Listing 2. Demonstracja automatycznej konwersji definicji zasobów, czyli łańcuchów znaków, na klasy języka Java

66. jMenuItem3.setAction(actionMap.get("makeLarger"));

67. jMenuItem3.setAccelerator(KeyStroke.getKeyStroke(KeyEvent.VK_PAGE_UP,

InputEvent.ALT_MASK | InputEvent.CTRL_MASK));

68. jMenuItem3.setIcon(resourceMap.getIcon("jMenuItem3.icon"));

69. jMenuItem3.setText(resourceMap.getString("jMenuItem3.text"));

70. jMenuItem3.setName("jMenuItem3");

71. jMenu2.add(jMenuItem3);

Listing 3. Demonstracja obsługi zdarzenia polegającego na naciśnięciu przycisku Szukaj w oknie aplikacji

1. //fragmenty klasy MainPane

2. public class MainPane extends javax.swing.JPanel {

3.

4. File f = null;

5.

6. public MainPane() {

7. initComponents();

8. }

9.

10. //w metodzie pozostawiona jest tylko inicjalizacja

//interesujących nas w tej chwili komponentów

11. private void initComponents() {

12. jTextArea1 = new javax.swing.JTextArea();

13. jButton1 = new javax.swing.JButton();

14. jTextField2 = new javax.swing.JTextField();

15.

16. jTextArea1.setColumns(20);

17. jTextArea1.setEditable(false);

18. jTextArea1.setFont(resourceMap.getFont("jTextArea1.font"));

19. jTextArea1.setRows(5);

20. jTextArea1.setName("jTextArea1");

21.

22. ActionMap actionMap = Application.getInstance(MainApp.class).getContext().

getActionMap(MainPane.class, this);

23. jButton1.setAction(actionMap.get("search"));

24. jButton1.setText(resourceMap.getString("jButton1.text"));

25. jButton1.setName("jButton1");

26.

27. jTextField1.setEditable(false);

28. jTextField1.setText(resourceMap.getString("jTextField1.text"));

29. jTextField1.setName("jTextField1");

30. }

31.

32. @Action

33. public void search() {

34. jTextArea1.setText("");

35. Grep g = new Grep(jTextField2.getText());

36. try {

37. if(f != null)

38. g.searchInFiles(f);

39. } catch (FileNotFoundException ex) {

40. Logger.getLogger(MainPane.class.getName()).log(Level.SEVERE, null, ex);

41. } catch (IOException ex) {

42. Logger.getLogger(MainPane.class.getName()).log(Level.SEVERE, null, ex);

43. }

44. getJTextArea1().setText(g.getFormatedSearchResults());

45. }

46. }

09/200852



Uruchomienie przykładów dołączonych do artykułuKod źródłowy wszystkich przykładów jest dostępny razem z czasopismem na płycie oraz na stronie http://www.xoft.pl/wp-content/uploads/2008/03/szukacz.zip. Przykłady są dołączone w postaci projektu środowiska NetBeans. W katalogu zawierającym projekt umieszczone są źródła języka Java (src), w podkatalogu dist z kolei umieszczone jest archiwum Szukacz.jar, zawierający binarną wersję aplikacji. Aby go uruchomić należy mieć zainstalo-waną wersję 6.0 języka Java. Uruchomienie polega na dwukrotnym kliknięciu archiwum JAR lub, jeśli to nie działa, na wykonaniu z linii poleceń komendy java -jar Szukacz.jar.Osoby niecierpliwe mogą bezpośrednio uruchomić aplikację przez Java Web Start wchodząc na stronę http://www.xoft.pl/wp-content/uploads/2008/03/szukacz.jnlp.

BibliografiaSAF jest nową technologią, nie do końca ustandaryzowaną, z tego powodu nie znajdziemy zbyt wielu źródeł informacji. Poniżej jest kilka miejsc war-tych odwiedzenia:

• strona główna projektu: https://appframework.dev.java.net/.• wywiad z Hansem Mullerem, twórcą SAF A Framework for Swing: http://www.artima.com/lejava/articles/swingframework.html.• wprowadzenie do tworzenia aplikacji SAF w NetBeans Introduction to the Swing Application Framework: http://www.netbeans.org/kb/60/java/gui-saf.html.• dwa ciekawe artykuły poświęcone programowaniu z użyciem SAF: Using the Swing Application Framework (http://java.sun.com/developer/

technicalArticles/javase/swingappfr/ ) i Swing Application Framework Hacks Unleashed For Smarty Pantses (http://weblogs.java.net/blog/diverson/archive/2007/04/swing_applicati.html).

• informacje o klasie SwingWorker, służącej do zarządzania wątkami w aplikacjach Swing znajdziemy na stronie http://swingworker.dev.java.net/.

Listing 4. Implementacja wyszukiwania zrobiona w ten sposób, by odbywało się ono w osobnym wątku

1. //fragmenty klasy MainPane

2. public class MainPane extends javax.swing.JPanel {

3.

4. File f = null;

5.

6. public MainPane() {

7. initComponents();

8. }

9. //w metodzie pozostawiona jest tylko inicjalizacja

interesujących nas w tej chwili

komponentów

10. private void initComponents() {

11. ActionMap actionMap = Application.getInstance(MainApp.c

lass).

getContext().getActionMap(MainPane.class, this);

12.

13. jButton2.setAction(actionMap.get("searchNoBlocking")

);

14. jButton2.setText(resourceMap.getString("jButton2.text

"));


16.

17. jTextField2.setText(resourceMap.getString("jTextField2

.text"));

18. jTextField2.setName("jTextField2");

19.

20. jButton4.setAction(actionMap.get("cancel"));

21. jButton4.setText(resourceMap.getString("jButton4.text

"));


23. }

24.

25. @Action(block=Task.BlockingScope.COMPONENT)

26. public Task searchNoBlocking() {

27. searchTask = new SearchNoBlockingTask(Application.getIns

tance(MainApp.class));

28. return searchTask;

29. }

30.

31. private class SearchNoBlockingTask extends Task<String,

Void> {

32. StringBuilder str = null;

33. Grep g = null;

34.

35. SearchNoBlockingTask(Application app) {

36. super(app);

37. jTextArea1.setText("");

38. g = new Grep((jTextField2.getText()));

39. }

40.

41. protected String doInBackground() {

42. try {

43. if(f != null )

44. g.searchInFiles(f);

45. } catch (FileNotFoundException ex) {

46. Logger.getLogger(MainPane.class.getName()).log(Leve

l.SEVERE, null, ex);

47. } catch (IOException ex) {

48. Logger.getLogger(MainPane.class.getName()).log(Leve

l.SEVERE, null, ex);

49. }

50. return g.getFormatedSearchResults();

51. }

52. protected void succeeded(String result) {

53. getJTextArea1().setText(result);

54. }

55. }

56.

57. @Action

58. public void cancel() {

59. if(searchTask != null)

60. searchTask.cancel(true);

61. }

62. }

09/200852



w innych klasach, przekazując odpowiedni obiekt do metody ApplicationContext.getActionMap(Class, Object) – jest to bar-dzo wygodne, gdyż raz zdefiniowaną ak-cję można wykorzystywać w całej aplikacji. Pewnie najwygodniejszy byłby tutaj mecha-nizm wstrzykiwania zależności (ang. depen-dency injection), ale SAF ma być prosty, więc przynajmniej w obecnej wersji wyszukuje-my odpowiednią klasę i metodę z kontek-stu aplikacji.

Opisana implementacja funkcjonalności wyszukiwania jest bardzo prosta, ma jednak-że jedną dosyć zasadniczą wadę: jeżeli wy-szukiwanie trwa dłużej, to blokuje ono in-terfejs użytkownika, w szczególności nie ma możliwości przerwania wyszukiwania. Dla-czego tak się dzieje jest jasne – długotrwa-łe zadanie wykonujemy w wątku EDT, od-powiedzialnym za rysowanie interfejsu użyt-kownika.

Musimy zatem uruchomić wyszukiwanie w osobnym wątku. Brzmi to z pozoru dość pro-sto, ale w praktyce jest uciążliwe, gdyż trzeba zsynchronizować działanie wątku szukające-go z wątkiem EDT, rysującym interfejs użyt-kownika.

Dotychczas najwygodniejszym rozwiąza-niem było wykorzystanie klasy narzędzio-wej SwingWorker. Podobne podejście sto-suje SAF, tyle, że użycie analogicznego me-chanizmu jest prostsze niż w przypadku SwingWorker-a.

Przyjrzymy się jeszcze raz klasie MainPane, tyle, że innemu jej fragmentowi, który znajdu-je się na Listingu 4.

Tak jak wcześniej, do komponentu, w tym przypadku przycisku, przypisujemy akcję searchNoBlocking (linia 13). Metoda obsłu-gująca wyszukiwanie zwraca obiekt typu Task, którego instancję musimy utworzyć w meto-dzie searchNoBlocking (linia 27).

Oczywiście nikt nam nie da gotowej klasy Task – trzeba ją samodzielnie napisać, przesła-niając odpowiednie metody. Nasza implemen-

tacja klasy Task nazywa się SearchNoBlockingTask (linia 31), przesłaniamy w niej trzy me-tody:

• konstruktor, w którym inicjalizujemy po-trzebne obiekty, warto zwrócić uwagę na to, że możemy w nim modyfikować stan GUI;

• doInBackground(), która jest odpowie-dzialna za uruchomienie wyszukiwa-nia – ta metoda działa w osobnym wąt-ku, nie blokuje zatem interfejsu użytkow-nika, nie wolno w tej metodzie odwoły-wać się w związku z tym do elementów GUI. Metoda ta jest automatycznie uru-chomiana, gdy tworzymy instancję klasy SearchNoBlockingTask ;

• succeeded , która jest wywoływana gdy tylko skończy się działanie meto-dy doInBackground() – w tej metodzie możemy zaktualizować interfejs użyt-kownika przy pomocy danych uzyska-nych z metody doInBackground(). Me-toda ta jest oczywiście uruchomiona w wątku EDT, dlatego może modyfikować GUI.

Klasa SearchNoBlockingTask ma jeszcze inne użyteczne metody, z jednej z nich ko-rzystamy w metodzie cancel, umieszczonej na samym końcu Listingu 4, przerywa ona wyszukiwanie po kliknięciu w odpowied-ni przycisk.

Co jeszcze potrafi SAFJest jeszcze kilka rzeczy, o których warto wspomnieć. SAF ułatwia implementację bar-dzo często pożądanej funkcjonalności, czy-li paska postępu dla długotrwałych operacji. SAF zapamiętuje także automatycznie stan GUI – wielkość i położenie okien. Ponieważ nasz przykład nie do końca jest skonstruowa-ny zgodnie z duchem SAF to akurat ta funk-cjonalność nie działa.

Użycie SAF w środowisku NetBeansMimo, że założeniem artykułu jest przeźroczy-stość ze względu na używane środowisko pro-gramistyczne, warto wspomnieć w jaki spo-sób można uprościć sobie życie dzięki NetBe-ansowi.

Środowisko NetBeans w wersji 6.1 daje do ręki programiście narzędzia pozwalające na szybki start ze Swing Application Framework. Przede wszystkim tworząc nowy projekt Java możemy wybrać jako typ projektu Java Desk-top Application.

Kreator projektu utworzy dla nas najważ-niejsze klasy, jakich potrzebuje SAF, czyli kla-sę główną aplikacji i klasę reprezentującą głów-ne okno aplikacji. Dodatkowo dostajemy kilka gotowych składników GUI, takich jak goto-wy szkielet menu aplikacji czy pasek postę-

pu. Gdy będziemy dodawać nowe elementy interfejsu użytkownika NetBeans będzie tak-że automatycznie tworzył odpowiednie pli-ki zasobów.

Dodawanie obsługi zdarzeń odbywa się w bardzo przyjazny sposób, klikamy prawym kla-wiszem na wybranej kontrolce GUI (na przy-kład na przycisku) i wybieramy Set Action. Po-jawia się wtedy okienko (Rysunek 4), w którym możemy przypisać jako akcję istniejącą meto-dę lub utworzyć nową oraz skonfigurować ak-cję – możemy akcji przypisać skrót klawiszo-wy, skonfigurować ją tak, żeby wykonywała się w tle, itp.

PodsumowanieCzy SUN-owi uda się spopularyzowanie SAF? Niewątpliwie Swing potrzebuje tego ty-pu rozwiązania, a jak na razie nie bardzo wi-dać konkurencję na tym polu. SAF musi mieć także dobre wsparcie narzędzi do tworzenia interfejsu użytkownika. Obecnie mamy do dyspozycji tylko NetBeansa, który sprawdza się całkiem dobrze, mimo kilku drobnych uciążliwości.

W szerszym kontekście ciekawsze pyta-nie brzmi, co się będzie działo na polu two-rzenia interfejsu użytkownika, bo ewident-nie szykuje się tutaj mniejszy lub większy przełom.

Z jednej strony tradycyjne aplikacje gru-bego klienta przestają być wystarczające w niektórych zastosowaniach, z drugiej stro-ny webowy interfejs użytkownika, któ-ry można utworzyć przy pomocy HTML/CSS/JavaScript, nawet jeśli wykorzystuje się AJAX, jest daleki od tego, co byśmy chcieli dostać. Jaka więc technologia ma szansę się przebić?

Być może uproszczenie instalacji Javy, które ma być wkrótce dostępne w ramach Java SE 6 Update 10 (zwanego wcześniej 6uN), do łask wrócą applety.

Z technologicznego punktu widzenia są one w wielu zastosowaniach bardzo skutecz-nym rozwiązaniem. Być może zyska popu-larność najnowsze dziecko firmy SUN, Ja-vaFX, który ma zdecydowanie uprościć two-rzenie GUI. Trzeba jednak pamiętać o twar-dych konkurentach na tym polu – Adobe Flex i Adobe Air oraz oczywiście Silverlight od Microsoftu. Niewątpliwie czekają nas cie-kawe czasy.

Uwaga: artykuł bazuje na aktualnej, czyli dość wczesnej wersji SAF, która może się jesz-cze zmieniać, także z czasem niektóre przykła-dy mogą przestać działać.

PIOTR KOCHAŃSKIAutor jest konsultantem firmy Erudis, odpowiedzial-

nym za technologię Java.

Kontakt z autorem: [email protected],

strona WWW: http://www.xoft.plRysunek 4. Kreator NetBeansa służący do przypisywania akcji do kontrolki GUI.

09/200854

Programowanie urządzeń mobilnychPodstawy tworzenia gier w JME


Jak to wynika ze wstępu celem artykułu jest wprowadzenie w tematykę tworze-nia aplikacji JME, a w szczególności gier.

Artykuł podzielony jest na dwie części. Pierw-sza ma formę tutoriala z jasno określonymi kro-kami, które należy wykonać aby otrzymać pod-stawową aplikację, która może być stosowana jako punkt wyjściowy do tworzenia gier. Dru-ga część artykułu stanowi poglądowy opis bu-dowy prostej gry napisanej w JME, opartej na podstawie stworzonej w części tutorialowej. Przy okazji druga część artykułu powinna na-świetlić pewne trudności, z którymi muszą się zmierzyć twórcy gier dla JME.

Artykuł zakłada znajomość podstaw Javy. Nic poza tym. Pomóc może obeznanie z IDE, w którym lubimy pisać, gdyż będziemy dołą-czać zewnętrzne biblioteki. Aczkolwiek moż-na też pisać w notatniku, wtedy nic nie trze-ba dołączać.

Droga, którą przebędziemy tworząc naszą grę jest trochę wyidealizowana dla celów edu-kacyjnych. Idealizacja polega na tym, że nie bę-dziemy się zbytnio przejmować tym co w świat-ku JME określa się jako porting – póki co zakła-damy, że wszystko działa na telefonach tak jak powinno, zgodnie ze specyfikacją i tak samo jak na emulatorze.

Jednakże, będę sygnalizował miejsca, na któ-re trzeba zwrócić szczególną uwagę gdyż pew-

ne rzeczy na prawdziwych telefonach mogą nie działać tak jak się tego spodziewamy.

Do tworzenia gry będziemy używać pakietu WTK (patrz Słowniczek). Stworzymy w nim projekt oraz będziemy go używać do kompilowa-nia, robienia buildów które można wgrać na tele-fon (pliki jad/jar) oraz uruchamiania gry w emu-latorze telefonu.

Aplikacja bazowa

Krok 1: Ściągnij i zainstaluj WTKWTK dostępne jest za darmo ze strony Suna (W Sieci). Instalacja jest banalna i sprowadza się do klikania dalej.

Krok 2: Tworzymy projekt w WTKOdpalamy WTK (Start -> Programy -> Sun Ja-va (TM) Wireless Toolkit 2.5.2 for CLDC -> Wireless Toolkit 2.5.2). Naszym oczom uka-rze się okienko z Rysunku 1.

Aby stworzyć projekt należy wybrać New Project. Pojawi się okienko (Rysunek 2), w któ-rym podajemy nazwę projektu i nazwę klasy, która będzie punktem wejściowym naszej apli-kacji. Aplikacje w JME nazywają się MIDlety. Nazwa klasy może być dowolna ale dobrą prak-tyką jest zawarcie w niej słowa MIDlet.

Gdy podamy nazwy klikamy Create Project i przechodzimy do kolejnego okna (Rysunek 3). Z lewej strony mamy dużo zakładek, w których możemy poustawiać masę opcji. My jednak skupimy się tylko na wyborze platformy doce-lowej, która określi na jakich telefonach nasza aplikacja będzie (a przynajmniej powinna) się uruchamiać oraz jakie API będziemy mieli do dyspozycji w czasie programowania.

Klikamy w pole wyboru wartości Target Plat-form i wybieramy JTWI. Ogólnie można przy-jąć, że są to telefony z MIDP2 i CLDC1.0 (patrz ramka Java Micro Edition) czyli grupa obejmują-ca szeroką gamę telefonów (nie pokrywa starych bardzo ograniczonych urządzeń, ale też nie ogra-nicza się do tylko najnowszych-super-hiper). Po wy-braniu platformy klikamy OK co zakończy two-rzenie projektu. Powinniśmy powrócić do główne-go okna WTK, w którym pojawi się informacja, że stworzony został katalog z projektem i jego lokali-zacja. Znajduje się on domyślnie w:

[Documents and Settings]/[user]/j2mewtk/2.5.2/apps/[nazwa projektu].

Podstawy tworzenia gier w JMEJeśli zawsze chciałeś stworzyć gierkę na swój telefon komórkowy lub po prostu poznać podstawy Javy Micro Edition – to jest artykuł dla ciebie. Najpierw, krok po kroku, stworzymy prostą szkieletową aplikację. Następnie przedstawię trochę tajników tworzenia gier i smaczków związanych z JME.

Dowiesz się:• Co to jest JME;

• Jak stworzyć prostą aplikację JME na telefon,

skompilować, uruchomić w emulatorze i na te-

lefonie;

• Jak można ugryźć zagadnienie tworzenia gier.

Powinieneś wiedzieć:• Jak programować w Javie.

Poziom trudności

Rysunek 1. WTK

09/200854



Krok 3: Konfiguracja IDEKod możemy pisać w Notatniku ale na pewno o wiele wygodniej jest używać dobrego IDE. Istnie-ją różne pluginy do popularnych IDE ułatwiające tworzenie aplikacji JME (np. NetBeans Mobili-ty Pack, EclipseME) jednak my nie będziemy ich używać, do naszych potrzeb nie są one potrzebne.

W naszym ulubionym IDE tworzymy pusty projekt zwykłej aplikacji Javowej. Jako katalog z kodem źródłowym wskazujemy katalog [ka-talog projektów WTK]/SimpleGame/src. Musi-my także podłączyć biblioteki zawierające pa-kiety javax.microedition.*, których będzie-my używać; podłączamy pliki cldcapi10.jar i midpapi20.jar, które można znaleźć w katalo-gu lib pakietu WTK.

Krok 4: Hello World – prosta aplikacjaW tym momencie powinniśmy być gotowi do programowania. Ogólna architektura na-szej gry wyglądać będzie następująco:

• klasa SimpleGameMIDlet – punkt wejścia dla aplikacji, tu odbędzie się podstawowa inicja-lizacja; także tutaj znajduje się główna pętla gry (która nie implementuje funkcjonalności gry, a tylko naprzemiennie wywołuje metody aktualizującą grę i rysującą);

• klasa SimpleGameCanvas – tutaj znajduje się implementacja naszej gry, dwie główne meto-dy to tick (tu się dzieje wszystko co nie jest rysowaniem, np. obsługa wciśniętych klawi-szy, update obiektów na planszy, wykrywa-nie kolizji, liczenie punktów itd.) i paint (od-powiedzialna za rysowanie); metody te będą naprzemiennie wywoływane z pętli głównej znajdującej się w SimpeGameMIDlet.

Na Listingu 1 i Listingu 2 znajdują się obie wspomniane klasy. Jeżeli przepiszemy ich kod to powinno być możliwe skompilowanie i uru-chomienie naszej aplikacji. Ale najpierw przyj-rzyjmy się kodowi.

Klasa SimpleGameMIDlet jest klasą dziedziczą-cą z abstrakcyjnej klasy MIDlet. Każda aplikacja JME (dla precyzji dodam, że profilu MIDP) mu-si posiadać klasę dziedziczącą z MIDlet. W chwili gdy użytkownik z menu telefonu uruchamia nasz program, stworzona zostanie instancja naszej kla-sy dziedziczącej z MIDlet, a następnie midlet zo-stanie wprowadzony w swój cykl życia. Nie będę wchodził w szczegóły dotyczące stanu życia mi-dletu (polecam link z ramki W Sieci), wspomnę tylko, że midlet może znajdować się w stanach Ac-

tive, Paused, Destroyed. Na moment obecny wy-starczy wiedzieć że gdy telefon pomyślnie stwo-rzy instancję midletu wprowadza go w stan Ac-tive, co skutkuje wywołaniem metody startApp. Jest to punkt wejściowy dla naszej gry.

W metodzie startApp tworzony jest obiekt naszej klasy SimpleGameCanvas i ustawiany ja-ko obiekt, który odbierał będzie wywołania me-tody paint (czyli będzie nam służył do rysowa-nia). Ostatnią rzeczą, którą robimy przy uru-chamianiu aplikacji jest wywołanie metody callSerially, która poprosi midlet o wywoła-nie metody run wskazanego obiektu (obiekt ten musi implementować interface Runnable). W naszym przypadku do callSerially przekazu-jemy this, czyli zostanie wywołana metoda run klasy SimpleGameMIDlet.

Kolejne dwie metody to destroyApp i pauseApp. Są to abstrakcyjne metody klasy MI-

Dlet, które muszą zostać zaimplementowane. W naszym bardzo prostym przykładzie ich imple-mentacja ograniczy się do samego faktu ich ist-nienia. Jednak gdy będziemy chcieli dopiąć na-szą grę do końca należy się tymi metodami zająć, a w zasadzie zająć obsługą zmian stanu midletu, które są wynikiem tzw. interrupcji (np. gdy w cza-sie działania gry ktoś do nas zadzwoni).

Ostatnią metodą klasy SimpleGameMIDlet jest run. Stanowić ona będzie główną pętlę naszej gry. Pierwszy raz zostaje ona wywołana pośrednio po wywołaniu callSerially w metodzie startApp.

Metoda run wywołuje metodę tick obiektu canvas (jest on instancją klasy SimpleGameCanvas, a jak wspomniałem wcześniej, klasa ta poza ryso-waniem zajmuje się także całą logiką gry) w ce-lu aktualizacji stanu gry. Następnie, jeśli gra po-winna toczyć się dalej prosimy o przerysowanie ekranu (wywołanie canvas.repaint) oraz po-

Java Micro EditionJava Micro Edition (JME, popularny też jest skrót J2ME) jest wersją języka Java zaprojektowaną z myślą o urządzeniach o ograniczonych możliwościach (najczęściej są to urządzenia przenośne, np. telefony, palmtopy). Od strony programisty na JME można patrzyć jako na Javę w wersji 1.4 z wyciętymi pewnymi pakietami i dodanymi kilkoma innymi, stworzonymi specjalnie z myślą o JME. Co zostało usunięte, a co dodane określają tzw. konfiguracje, które definiują podstawowe wymagania stawiane urządzeniom oraz podstawowe dostępne API. Na bazie konfiguracji two-rzone są tzw. profile, które określają dodatkowe funkcje dostępne dla programistów.Dwie główne konfiguracje: CDC i CLDC (Słowniczek). CLDC jest powszechnie używane w telefo-nach komórkowych. Najpopularniejszym profilem spotykanym u nas jest MIDP, bazujący na CLDC.

Rysunek 2. Podajemy nazwę projektu i nazwę głównej klasy Rysunek 3. Opcje projektu, nam wystarczy tylko wybór platformy

09/200856



nowne wywołanie metody run (przez wywoła-nie metody callSerially). W przypadku gdy gra powinna się zakończyć wywołujemy meto-dę notifyDestroyed, która wprowadzi midlet w stan Destroyed co powinno zaowocować wyłącze-niem i posprzątaniem po midlecie przez oprogra-mowanie telefonu.

Prośby przerysowania i wywołania metody run są wewnętrznie przez midlet kolejkowane, a

następnie odpalane w kolejności ich zgłoszenia. Dzięki temu mechanizmowi otrzymujemy na-przemienne wykonywanie metod tick i paint klasy SimpleGameCanvas.

Wprawka do gryNa tym etapie nasza gra wyświetli żółte tło, ru-chomy napis Hello World!, kod ostatniego naci-śniętego klawisza oraz będzie ją można wyłą-

czyć naciskając RSK (patrz Słowniczek). Przyj-rzyjmy się kodowi klasy SimpleGameCanvas że-by zobaczyć jak to działa (Listing 2).

Pierwszą rzeczą jaka rzuca się w oczy jest dziedziczenie z klasy GameCanvas (która dzie-dziczy z Canvas). W aplikacjach JME klasa, która będzie używana do rysowania musi dzie-dziczyć z klasy Canvas – zawiera ona metodę paint, która jest wywoływana przez telefon w celu przerysowania ekranu.

Nasza klasa dziedziczy z GameCanvas (a zatem i z Canvas). GameCanvas jest dostępna w telefo-nach z profilem MIDP2 i umożliwia (między innymi) włączenie trybu pełnoekranowego na większości telefonów (na np. Motorolach zawsze zostaje widoczny u góry pasek stanu telefonu).

Na początku klasy SimpleGameCanvas de-finiujemy:

• stałą kodu klawisza RSK (omówione dalej w części poświęconej obsłudze klawiatury);

• zmienną lastKeyPressed zawierająca kod ostatnio wciśniętego klawisza;

• zmienną isRunning – przechowuje infor-mację czy należy dalej kontynuować grę;

• zmienną x – pozycja napisu Hello World!, który będziemy wyświetlać.

Następnie mamy konstruktor, w którym wy-wołujemy konstruktor GameCanvas (znacze-nie przekazywanego parametru pozostawiam do samodzielnego zbadania) oraz ustawiamy pełnoekranowy tryb wyświetlania.

Kolejnym elementem jest metoda rysująca. Jak już wspomniałem, wypełnia ona tło żółtym kolorem oraz rysuje napis Hello World! oraz kod ostatniego wciśniętego klawisza. Wydaje mi się, że jej kod jest dość oczywisty. Warto jednak wspomnieć o metodach:

• kolor rysowania ustawiamy meto-dą setColor klasy Graphics, np.: g.setColor(0xFFFF00), kolor podajemy ja-ko jedną liczbę int w formacie 0xAARRG-GBB (alpha, red, green, blue), w większości

Listing 1. Klasa SimpleGameMIDlet

import javax.microedition.lcdui.Display;

import javax.microedition.midlet.MIDlet;

import javax.microedition.midlet.MIDletStateChangeException;

public class SimpleGameMIDlet extends MIDlet implements Runnable

{

SimpleGameCanvas canvas;

protected void startApp() throws MIDletStateChangeException {

if( canvas == null)

{

// create canvas object:

canvas = new SimpleGameCanvas();

// use our canvas for painting:

Display.getDisplay(this).setCurrent(canvas);

// call run()

Display.getDisplay(this).callSerially(this);

}

}

protected void destroyApp(boolean unconditional) throws MIDletStateChangeException

{

}

protected void pauseApp() {

}

public void run()

{

// update game:

canvas.tick();

//

if(canvas.isRunning())

{

// request repaint:

canvas.repaint();

// request to call run() again:

Display.getDisplay(this).callSerially(this);

}

else

{

// tell the phone that we've finished and MIDlet can be destroyed

this.notifyDestroyed();

}

}

} Rysunek 4. Emulator: przed uruchomieniem midletu i po

09/200856



zastosowań możemy pominąć składową alpha (przezroczystość);

• rozmiar ekranu (w pikselach) pobieramy metodami getWidth i getHeight ; warto tu wspomnieć że spora grupa telefonów ma problemy z tą metodą i zwraca złe wymia-ry, nie zdziw się więc jeśli na twoim telefo-nie nie będzie wypełniony cały ekran;

• do wypełnienia prostokątnego obszaru ustawionym wcześniej kolorem służy me-toda fillRect klasy Graphics ;

• do rysowania tekstu ustawionym wcze-śniej kolorem służy metoda drawString klasy Graphics.

Po metodzie rysującej znajduje się metoda tick, której zadaniem jest aktualizacja stanu gry. W tej chwili wykonuje one tylko dwie czynności – zwiększa zmienną x aby napis Hello World! się przesuwał, oraz sprawdza czy wciśnięty został klawisz RSK, jeśli tak to ustawia flagę informu-jącą o tym, że chcemy wyłączyć grę.

Wartość flagi zawierającej informację o wci-śnięciu klawisza RSK jest zmieniana w me-todzie keyPressed. Jest to metoda odziedzi-czona z klasy Canvas i jest ona wywoływana

Listing 2. Klasa SimpleGameCanvas

import javax.microedition.lcdui.Graphics;

import javax.microedition.lcdui.game.GameCanvas;

public class SimpleGameCanvas extends GameCanvas

{

public static final int KEY_RSK = -7;

private boolean isRunning = true; // wheter game should still run

private int x = 10; // x position of "Hello World" string

private int lastKeyPressed; // last key pressed

public SimpleGameCanvas()

{

super(false);

setFullScreenMode(true);

}

public void paint(Graphics g)

{

System.out.println("paint");

// fill background:

g.setColor(0xFFFF00);

int w = getWidth();

int h = getHeight();

g.fillRect(0, 0, w, h);

// draw some texts:

g.setColor(0x0);

g.drawString("key: "+lastKeyPressed, 10, 10, Graphics.TOP | Graphics.LEFT);

g.drawString("Hello World!", x, 30, Graphics.TOP | Graphics.LEFT);

}

public void tick()

{

System.out.println("tick");

x++;

if(x > 200) {

x = 10;

}

}

protected void keyPressed(int key)

{

lastKeyPressed = key;

if(key == KEY_RSK)

{

// this will result in stop calling SimpleGameMIDlet.run

isRunning = false;

}

}

public boolean isRunning()

{

return isRunning;

}

}

Rysunek 5. Elementy gry

Słowniczek

• CLDC – Connected Limited Device Confi-guration, najczęściej spotykana w tele-fonach konfiguracja Javy Microedition;

• JME – Java Micro Edition, wersja Javy na urządzenia o ograniczonych zasobach (mało pamięci, wolne procesory);

• konfiguracja – specyfikacja podstawo-wych wymagań i API które muszą po-siadać telefony;

• MIDP – Mobile Information Device Pro-file, najczęściej stosowanych w telefo-nach profil Javy Microedition, stworzo-ny na bazie CLDC;

• OTA – over the air, metoda wgrywania aplikacji na telefon przez ściągnięcie ich na telefonie z sieci (najczęściej przez in-ternet);

• profil – specyfikacja dodatkowych wy-magań i API zbudowanych na bazie określonej konfiguracji;

• RSK – right soft key, prawy soft key, patrz soft keys;

• soft keys – dwa klawisze (lewy i prawy, czasem jeszcze trzeci środkowy), które najczęściej znajdują się bezpośrednio pod ekranem telefonu i są standardo-wo używane w menu telefonu do wy-borów typu tak/nie;

• WTK – Wireless Toolkit, pakiet firmy Sun potrzebny do tworzenia aplikacji JME.

09/200858

Programowanie urządzeń mobilnych

przez telefon gdy zostanie wciśnięty jakiś kla-wisz. Analogicznie klasa Canvas posiada meto-dę keyReleased, wywoływaną gdy jakiś klawisz przestaje być wciśnięty.

Krok 5: Zrobienie buildaWiemy już jak wygląda kod naszego programu. Czas go skompilować – należy kliknąć przycisk Build w głównym oknie WTK. Jeśli kod nie za-wiera błędów pojawi się napis Build complete. W przypadku błędów zostaniemy o tym poinformo-wani, a błędy zostaną wypisane w oknie WTK.

Krok 6: Uruchomienie w emulatorzeZanim spróbujemy uruchomić naszą grę na te-lefonie warto sprawdzić jej działanie w emula-torze. Jest to bardzo proste – klikamy przycisk Run z głównego okna WTK.

Przed uruchomieniem gry należy ją zbudo-wać. Jest to szczególnie ważne jeżeli dokonamy zmian w kodzie i chcemy zobaczyć ich działa-nie – po każdej zmianie należy ponownie zbu-dować projekt.

Jeżeli wszystko przebiegło sprawnie zobaczy-my okno emulatora, a w nim nazwę naszego midletu. Myszką należy kliknąć na RSK telefo-nu aby uruchomić midlet. Naszym oczom uka-rze się żółty ekran z poruszającym się napisem

Hello World!. Istne szaleństwo (Rysunek 4).Bardzo przydatną cechą emulatora jest kon-

sola. Wszystkie komunikaty normalnie wy-świetlane w konsoli będą widoczne w oknie WTK (np. wywołania System.out.println). Polecam przeprowadzenie eksperymentu i do-danie na początku metod tick i paint wywo-łań, odpowiednio: System.out.println(„tick”) i System.out.println(„paint”). W kon-soli WTK, po uruchomieniu midletu, powinny na przemian wypisywać się te dwa napisy.

Krok 7: Wgranie na telefonAby wgrać midlet na telefon musimy utworzyć pakiet dystrybucyjny (para plików jar/jad). W pasku menu WTK wybieramy Project -> Packa-ge -> Create Package. Spowoduje to skompilowa-nie aplikacji i umieszczenie klas oraz plików za-sobów (obrazki, dźwięki itp.) w pliku jar oraz stworzenie pliku jad. Umieszczone zostaną one w [katalog projektów WTK]/SimpleGame/bin.

Teraz czas na wgranie gotowej do dystrybucji aplikacji na telefon. Sposobów jest kilka, a ten który wybierzesz zależy od twojego telefonu.

BluetoothNajwygodniejszą chyba metodą wgrywania aplikacji na telefony jest Bluetooth (dalej w

skrócie nazywane przeze mnie BT). Oczywiście zarówno telefon jak i komputer muszą posia-dać BT. W przypadku komputera wiele lapto-pów posiada wbudowane urządzenie BT. Moż-na także kupić BT podłączany do komputera przez port USB.

Procedura wgrania midletu na większość tele-fonów polega na wysłaniu do telefonu pliku jar. Niektóre telefony (mniejszość) wymagają także wgrania pliku jad lub połączenia BT przez spe-cjalny program. Jednak w większości wypadków po prosty wgrywamy plik jar na telefon.

Aby tego dokonać należy włączyć Bluetooth w menu telefonu oraz ustawić tryb widoczno-ści (żeby inne urządzenia, np. komputer, mogły wykryć telefon). Jeśli posiadamy dobrze skon-figurowany BT wystarczy (w Windowsie) klik-nąć na pliku jar prawym guzikiem myszy, a na-stępnie z menu kontekstowego wybrać Wyślij do -> Bluetooth. W zależności od sterowników BT w naszym systemie kolejne menu mogą wy-glądać różnie ale najczęściej sprowadzają się do następujących kroków:

• wyszukaj urządzenia BT;• gdy pojawi się spis urządzeń wybieramy

nasz telefon;• zostaniemy poproszeni o podanie hasła

PIN – wpisujemy coś, np. 1234;• telefon powinien zareagować i powiado-

mić nas o przychodzącym połączeniu – akceptujemy połączenie i wpisujemy taki sam kod PIN jak wcześniej na kompute-rze;

• powinniśmy zostać zapytani o chęć zain-stalowania aplikacji;

aplikacja instaluje się na telefonie.

Port podczerwieniProcedura wgrywania przez port podczerwień jest bardzo podobna do wgrywania przez Blu-etooth. Umieszczamy telefon względem kom-putera tak żeby czujniki podczerwieni obu urządzeń były w siebie wycelowane. Następnie musimy nawiązać połączenie między telefo-nem i komputerem. Jeśli się to uda to w menu Wyślij Do dostępna będzie opcja wysłania pliku do podłączonego komputera (ikonka połącze-nia podczerwienią), którym na prawdę będzie nasz telefon. Po przesłaniu pliku na telefon po-winien uruchomiać się proces instalacji.

OTAOver The Air (OTA) to nazwa sposobu dys-trybucji aplikacji poprzez ściągnięcie jej na telefon przez sieć operatora, najczęściej uży-wając połączenia GPRS.

Dla nas oznacza to tyle, że wgrywamy pli-ki jad i jar na jakiś serwer, skąd dostępne będą przez HTTP (czyli w praktyce przez wpisanie adresu pliku w przeglądarce internetowej). Te-lefon musimy skonfigurować aby można było z niego wchodzić na strony internetowe, odpala-my przeglądarkę wbudowaną w telefon i w po-

Listing 3. Stany gry

public static final short STATE_Loading = 1; // ladowanie gry

public static final short STATE_Splash = 2; // ekran z tytulem gry

public static final short STATE_Intro = 3; // tekst informacyjny przed gra

public static final short STATE_Gameplay = 4; // rozgrywka

public static final short STATE_GameOver = 5; // po grze

// obecny stan gry:

protected short state = STATE_Loading;

Rysunek 6. Stany gry

Loading

Splash

3s delay

Introany key pressed

Gameplay

any key pressed [end game conditions]

Game over

Podstawy tworzenia gier w JME


lu adresu strony do otworzenia wpisujemy link to pliku jad. Plik jad powinien się ściągnąć, a te-lefon powinien zainicjować instalację midletu.

Czas na gręNa tym etapie mamy działającą aplikację JME, która coś rysuje i odświeża się, możemy ją zbudo-wać oraz uruchomić w emulatorze i na telefonie. Mamy więc punkt wyjściowy do stworzenia gry.

Czas zatem zabrać się za grę – będzie to pro-sta strzelanka o jakże wysublimowanym tytule Attack of the Killer Space Monsters. Design gry wygląda następująco:

• gracz porusza w prawo/lewo statkiem ko-smicznym znajdującym się na dole ekranu;

• statek gracza posiada dwa działka, z pra-wej i lewej strony;

• gracz wciskając klawisz wyboru na telefo-nie strzela z działek, na przemian z lewego i prawego;

• zadaniem gracza jest strzelanie do potwo-rów, jeden celny strzał zabija potwora;

• potwory pojawiają się u góry ekranu i po-ruszają w dół;

• potwory pojawiają się w falach, każda kolej-na fala generuje większą ilość potworów, po-jawiają się one częściej i poruszają szybciej;

• wystrzał odejmuje 10 punktów graczowi;• trafienie potwora usuwa go z gry i daje gra-

czowi 20 punktów;• gracz przegrywa gdy choć jeden potwór

dotrze do dołu ekranu bądź zderzy się ze statkiem gracza.

Rysunek 5 przedstawia wszystkie elementy gra-ficzne występujące w grze. Kolejno są to: kosmicz-ny potwór, statek gracza i dwie klatki animacji po-cisku plazmowego, którymi strzela gracz.

Architektura gryCały kod gry zajmuje sporo miejsca i nie zmie-ściłby się cały w artykule. Gotowa gra (kod źró-dłowy wraz z projektem WTK oraz pliki jad/jar) dostępna jest na stronie SDJ. Zachęcam do ściągnięcia kodu i analizowanie go wraz z czyta-niem artykułu.

Podstawą gry są stworzone przez nas klasy klasy SimpleGameMIDlet i SimpleGameCanvas. Pierwsza z nich w ogóle się nie zmieni wzglę-dem tego co do tej pory stworzyliśmy. Nato-miast druga będzie stanowić trzon gry odpo-wiedzialny m.in. za: zarządzanie stanami i logi-ką gry, ładowanie potrzebnych zasobów, reago-waniem na input gracza, aktualizowaniem i ry-sowaniem obiektów w świecie gry.

Dodatkowo stworzymy klasy reprezentują-ce obiekty w świecie gry: klasę Actor stanowią-cą klasę bazową dla klas Monster, Projectile i SpaceShip.

Stworzymy także klasy pomocnicze: ResManager (menadżer zasobów) i FP (arytmety-ka stałoprzecinkowa) oraz klasy stanowiące tylko zbiory stałych DeviceConstants (różne stałe spe-

Listing 4. Metoda tick, decydowanie co zaktualizować

public void tick()

{

if (isKeyTyped(KEY_RSK))

{

// wcisniety RSK - wychdzimy z gry

this.isRunning = false;

return;

}

/*

* --- obliczamy czas miedzy klatkami ---

*/

long currentTime = System.currentTimeMillis();

if(this.lastFrameTime == 0) { // to wystapi na samym poczatku dzialania gry

this.lastFrameTime = currentTime;

}

int tickTime = (int)(currentTime – this.lastFrameTime);

/*

* --- aktualizacja gry ---

*/

switch(this.state)

{

case STATE_Loading:

tickLoading();

break;

case STATE_Splash:

tickSplash(tickTime);

break;

case STATE_Intro:

if(isAnyKeyPressed())

{

changeState(STATE_Gameplay);

}

break;

case STATE_Gameplay:

tickGame(tickTime);

break;

case STATE_GameOver:

if(isAnyKeyPressed())

{

changeState(STATE_Intro);

}

break;

}

/*

* --- zapisywanie wartosci z obecnej klatki, beda uzyte w nastepnej klatce ---

*/

this.prevKeysState = this.currKeysState;

this.lastFrameTime = currentTime;

}

09/200860


cyficzne dla telefonu, dla którego tworzymy grę) i ResConstants (identyfikatory zasobów).

Maszyna stanówSama gra na wysokim poziomie abstrakcji jest maszyną stanów (Rysunek 6), która zaimple-mentowana jest w bardzo prosty sposób – sta-ny zdefiniowane są jako niby-enumeracje (Li-sting 3; często stosowane w JME gdzie nie ma

prawdziwych enumeracji) wraz ze zmienną state, określającą aktualny stan gry. Do tego dochodzą metody changeState (zmienia stan), onStateLeave (wywoływana z changeState tuż przed zmianą stanu) oraz onStateEnter (wywoływana z changeState tuż po zmianie stanu). Polecam wyszukanie w kodzie wystą-pień metody changState, da to dobry obraz implementacji przejść między stanami.

Punktami wyjścia dla operacji przeprowadza-nych w każdej klatce są metody tick i paint (wy-woływane naprzemiennie w głównej pętli gry, w klasie SimpleGameMIDlet, patrz Listing 1). W nich na podstawie aktualnego stanu gry podejmo-wana jest decyzja co w danym momencie zrobić.

Przyjrzyjmy się Listingowi 4, zawierającemu nową metodę tick. Wykonuje ona następujące czynności:

• sprawdzanie czy wciśnięty został RSK, je-śli tak ustawia flagę która spowoduje za-mknięcie gry;

• obliczanie czasu pomiędzy klatkami (tzw. tick time); metoda System.currentTime

Millis() zwraca aktualny czas (ilość mili-sekund od 1 stycznia 1970 roku); tick time będziemy używać do poruszania obiektów;

• sprawdzany jest aktualny stan gry i w zależ-ności od niego wywoływane są odpowied-nie metody, specyficzne dla danego stanu.

Analogicznie do metody tick działa metoda paint (Listing 5a) – sprawdzany jest stan gry i wywoływana jest odpowiednia metoda ry-sująca, aczkolwiek część decyzji odnośnie te-go co ma być narysowane trafia to metody paintGame (Listing 5b).

Zasoby – ładowanie i zarządzanieNasza gra ładuje potrzebne jej zasoby (zaledwie cztery obrazki) w metodzie tickLoading. Me-toda ta jest wywoływana co klatkę tak długo jak gra znajduje się w stanie STATE_Loading, a w każdym jej wywołaniu ładujemy kolejne części potrzebnych nam zasobów. Do ładowania uży-wamy obiektu klasy ResManager.

ResManager to menadżer zasobów – w na-szym przypadku kontroluje on obrazki i teksty, i przechowuje referencje do nich. W klasach gry nie będziemy bezpośrednio trzymać refe-rencji do obrazków ani tekstów, w zamian bę-dziemy przechowywać ich identyfikatory (zde-

Listing 5a. Decyzja co narysować w zależności od stanu


{

switch(state)

{

case STATE_Loading:

paintLoading(g);

break;

case STATE_Splash:

paintSplash(g);

break;

default:

paintGame(g);

}

}

Listing 5b. Dalszy ciąg decydowania co narysować

private void paintGame(Graphics g)

{

// narysuj obiekty w swiecie gry:

paintGameField(g);

// narysuj elementy nad obszarem gry:

g.setColor(0xFFFFFF);

switch(state)

{

case STATE_Intro:

paintIntro(g);

break;

case STATE_Gameplay:

paintHUD(g);

break;

case STATE_GameOver:

paintHUD(g);

paintGameOver(g);

break;

}

}

Listing 6. Ładowanie obrazu z pliku znajdującego się w pliku jar gry

// pobieranie strumienia do pliku znajdujacego sie w jar:

in = this.getClass().getResourceAsStream(fileName);

// tworzenie obrazu ze strumienia:

images[imageId] = Image.createImage(in);

Rysunek 7. Screen z gry, z emulatora



finiowane w klasie ResConstants) i na żądanie, używając identyfikatora, pobierać potrzebny obrazek lub tekst z menadżera. W dowolnym momencie możemy też usunąć wszystkie zaso-by przechowywane przez menadżera.

Menadżer wewnętrznie przechowuje obrazy i teksty w zwykłych tablicach. Identyfikatory za-sobów to po prostu indeksy do tablic. Jeśli więc zasób jest załadowany to pobranie go jest bardzo szybkie i odbywa się przez wyciągnięcie elementu tablicy. Należy przy tym uważać bo jeśli zasób nie był załadowany to pobranie go zwróci nam null (stosuje się też menadżery, w których nie trzeba jawnie ładować zasobów, przy pierwszej próbie pobrania zasobu menadżer sam go załaduje).

Schemat używania naszego menadżera za-sobów jest następujący, na przykładzie ładowa-nia obrazów:

• w fazie ładowania (metoda tickLoading) wywołujemy metodę loadImage przeka-zując identyfikator obrazu;

• w kodzie gry, np. podczas rysowania mu-simy dostać obiekt klasy Image, wywołu-jemy więc metodę getImage przekazując identyfikator obrazu;

• w chwili gdy potrzebujemy usunąć obrazki z pamięci (najczęściej gdy przeładowujemy zasoby, np. ładując nową plansze czy prze-chodząc między różnymi modułami gry) wystarczy wywołać freeAllImages, dzięki temu że jedyne referencje do obrazów były trzymane przez menadżera garbage collector będzie mógł usunąć obrazy z pamięci.

Ogromną zaletą używania menadżera za-sobów jest kontrola pamięci. Jeśli będziemy trzymać się schematu, że nasz kod przecho-wuje tylko identyfikatory zasobów zamiast re-ferencji do nich, możemy praktycznie jawnie usuwać zasoby z pamięci.

Co do samych zasobów – aby móc w czasie działania midletu załadować jakiś plik, plik ten musi znajdować się w archiwum jar midletu. Aby to nastąpiło umieszczamy pliki zasobów w podka-talogu res katalogu projektu WTK naszej gry.

A jak odczytać dane z pliku, który znaj-duje się w archiwum jar? Używając metody getResourceAsStream klasy Class, która zwra-ca nam strumień do czytania z pliku. Listing 6 przedstawia przykład ładowania obrazka za-czerpnięty z klasy ResManager.

Jeszcze słowo o obrazkach – standardem w JME jest obsługa obrazów w formacie PNG. Teoretycznie możemy użyć dowolnego takiego pliku, jednak w praktyce stosuje się kilka tech-nik aby uniknąć rozmaitych problemów (patrz Ramka PNG dla JME).

Input z klawiatury i problemy z telefonamiTworząc grę bardzo wygodnie jest posiadać zestaw metod do sprawdzania stanu klawi-szy w danej klatce. Klasa Canvas oferuje nam

co prawda metody keyPressed i keyReleased ale brak metod, które można odpytać w do-wolnym momencie, np. w kodzie decydują-cym o przejściu między stanami gry. Dlatego w SimpleGameCanvas takie metody zostały zaim-plementowane, są to:

• isKeyPressed – czy dany klawisz jest w obecnej klatce wciśnięty;

• isAnyKeyPressed – czy jakikolwiek kla-wisz jest w obecnej klatce wciśnięty;

• isKeyTyped – czy dany klawisz został w obecnej klatce wciśnięty (tzn. w poprzed-niej nie był wciśnięty, a w obecnej jest).

Metod pressed używa się do sprawdzania cią-głego inputu z klawiatury, np. gracz musi ca-ły czas trzymać wciśnięty klawisz prawo/lewo żeby poruszać statkiem kosmicznym. Nato-miast metod typed używa się gdy reakcja na wciśnięcie klawisza jest impulsowa, tzn. gracz musi puścić klawisz i wcisnąć go jeszcze raz że-by ponownie wywołać akcję – np. strzelanie z karabinu.

Analizę implementacji powyższych me-tod zostawiam we własnym zakresie czytel-nikowi. Warto jednak wspomnieć o proble-mie jakim jest fakt, że producenci telefonów stosują różne kody klawiszy. Nasza gra może

PNG dla JMETworząc grafiki do gier JME należy mieć na uwadze kilka rzeczy: rozmiar aplikacji, przezroczy-stość oraz rozmaite niedoskonałości telefonów.

RozmiarW JME zawsze trzeba liczyć się z rozmiarem aplikacji, dlatego praktyką jest tworzenie jak naj-mniejszych plików graficznych (w sensie ilości bajtów).Pierwszą podstawową techniką redukcji rozmiaru jest zapisywanie plików z użyciem palety (za-miast zapisywania dla każdego piksela kanałów RGB). Im mniej kolorów w palecie tym obraz jest mniejszy (czasami walczy się o kilkadziesiąt bajtów). Często stajemy przed dylematem – czy jesz-cze zredukować paletę (kosztem jakości) i zyskać trochę miejsca. Najczęściej stosuje się kompro-mis – redukcja ilości kolorów tak, że prawie nie widać różnicy, a rozmiar jest odczuwalnie mniej-szy od oryginału.Drugą techniką jest stosowanie programów optymalizujących pliki PNG. Bardzo często pliki stworzone w popularnych programach graficznych posiadają zapisane różne dodatkowe dane, nie będące danymi obrazu, a sam obraz jest zapisany nieoszczędnie. Istnieje kilka narzędzi (naj-częściej w formie programu uruchamianego z linii komend), które służą do czyszczenia i opty-malizacji plików PNG. Polecam poszperanie w sieci i poczytanie o takich programach jak: pngo-ut, pngcrush, pngcrunch czy pngshrink.

PrzezroczystośćFormat PNG daje nam dwie możliwości zapisania informacji o przezroczystości. Możemy albo za-wrzeć w pliku kanał alfa (czyli dla każdego piksela zapisujemy jego stopień przezroczystości, w skali 0-255) albo użyć palety i wskazać jeden dowolny jej kolor z palety jako przezroczysty (tele-fon rysując naszą grafikę nie będzie rysował pikseli o kolorze oznaczonym jako przezroczysty).Jeśli chodzi o kanał alfa to bardzo dużo telefonów sobie z nim nie radzi i najczęściej opcja ta jest pomijana. Jeśli jednak zależy nam na efektach opartych na częściowej przezroczystości to mu-simy liczyć się z tym, że będą dostępne na tylko niektóre telefony. Na pozostałe trzeba będzie tworzyć jakieś techniki zastępcze.Jeśli chodzi o przezroczystość jednego koloru, to wiele telefonów zakłada, że kolor oznaczony jako przezroczysty jest pierwszym kolorem w palecie. Jeśli tak nie jest informacja o przezroczy-stości jest na tych telefonach pomijana. Wymaganie to jest problematyczne gdyż większość po-pularnych programów graficznych nie daje nam możliwości bezpośredniego operowania na pa-lecie. Z tego powodu często zdarza się, ze nie jesteśmy w stanie w łatwy sposób wymusić aby ko-lor przezroczysty znajdował się na pierwszym miejscu.Polecam zapoznanie się z programem GraphicsGale (patrz ramka W Sieci), dzięki któremu można uniknąć wielu frustracji, a który pozwala na różne przydatne operacje dotyczące palety.

SmaczkiPo za opisanymi wcześniej problemami zdarzają się (rzadko, ale się zdarzają, i dotyczą konkret-nych modeli telefonów) różne bardzo dziwne rzeczy. Spotkałem się z kilkoma telefonami, któ-re potrafiły wczytać grafiki PNG tylko o parzystej szerokości obrazu. Pewne telefony traktują ko-lor biały zawsze jako przezroczysty, niezależnie od tego co zapisane jest w pliku. Do tego zawsze trzeba nastawić się na możliwość, że telefon po prostu odmówi wczytania obrazu. Jeżeli przytra-fi ci się taka właśnie sytuacja i mimo wszelkich prób pliku wczytać się nie uda – spróbuj go otwo-rzyć i zapisać w jakimś programie graficznym, którego to dej pory nie używałeś. Zdarzyło mi się kilka razy, gdy to magicznie pomogło.

W Sieci

• http://java.sun.com/products/sjwtoolkit/download.html – strona, z której można ściągnąć WTK• http://developers.sun.com/mobility/learn/midp/lifecycle/ – cykl życia midletu• http://www.humanbalance.net/gale/us/download.html – program GraphicsGale, bardzo do-

bre narzędzie do przygotowywania plików PNG dla gier JME

09/200862


Listing 7. Podstawowe operacje arytmetyki stałoprzecinkowej

Listing 8. Klasa Actor

public class FP

{

// ilosc bitow przeznaczonych na czesc ulamkowa

public final static int BIT_SHIFT = 16;

// zwraca reprezentacje fixed-point podanej wartosci

public static int toFP(int value)

{

return (value << 16);

}

// zwraca reprezentacje fixed-point podanego ulamka

zwyklego (a/b)

public static int toFP(int a, int b)

{

return (a << BIT_SHIFT) / b;

}

// zamienia wartos fixed-point na zwykla liczbe (tracimy

public class Actor

{

// mozliwe tryby rysowania aktora:

public static final byte DRAW_Image = 0;

public static final byte DRAW_Line = 1;

public static final byte DRAW_Box = 2;

public static final byte DRAW_Custom = 10;

public static final byte DRAW_None = 11;

byte drawType = DRAW_Box; // domyslnie aktor rysowany jest

jako kwadrat

int color = 0xFFFFFF; // uzywane przez typy: line, box

short imageId; // uzywane przez typ : image

// pozycja w swiecie:

int fp_posX;

int fp_posY;

// wektor predkosci:

int fp_velX;

int fp_velY;

// punkt referencyjny (offset wzgledem gornego-lewego rogu)

short refX = 10;

short refY = 10;

// rozmiar:

short width = 20;

short height = 20;

// flaga oznaczajaca czy obiekt jest do usuniecia ze swiata gry:

private boolean toBeDestroyed = false;

public void tick(int tickTime, int fp_dt)

{

// na podstawie aktualnej predkosci wyznacz nowe polozenie:

fp_posX += FP.mulFP(fp_dt, fp_velX);

fp_posY += FP.mulFP(fp_dt, fp_velY);

}


{

switch(drawType)

{

case DRAW_Image:

{

int x = FP.toInt(fp_posX) - refX;

int y = FP.toInt(fp_posY) - refY;

Image img = ResManager.getInstance().getImage(im

ageId);

g.drawImage(img, x, y, Graphics.LEFT |

Graphics.TOP);

break;

}

case DRAW_Box:

{



g.setColor(color);

g.drawRect(x, y, width, height);

break;

}

case DRAW_Line:

{



g.setColor(color);

g.drawLine(x, y, x+width, y+height);

break;

}

}

}

public void destroy()

{

toBeDestroyed = true;

}

public boolean isToBeDestroyed()

{

return toBeDestroyed;

}

}

czesc ulamkowa)

public static int toInt(int fp_value)

{

return (fp_value >> 16);

}

// mnozenie dwoch liczb fixed-point, wynik tez jest FP

public static int mulFP(long fp_a, long fp_b)

{

return (int)((fp_a * fp_b) >> BIT_SHIFT);

}

// dzielenie dwoch liczb fixed-point, wynik tez jest FP

public static int divFP(int fp_a, int fp_b)

{

return (int)((long)(fp_a) << BIT_SHIFT / fp_b);

}

}



otrzymywać różne kody w wywołaniach me-tod keyPressed i keyReleased w zależności od telefonu.

Zresztą różnych niespójności pomiędzy pro-ducentami (a często i pomiędzy modelami tej samej firmy) jest dużo więcej. Ponadto, często zdarzają się błędy w implementacji Javy na te-lefonach i niektóre metody nie działają tak jak powinny. Z tych powodów powstała klasa DeviceConstants, która zwiera stałe wartości, które mogą różnić się między telefonami lub ich otrzymanie w czasie działania midletu mo-że być problematyczne. W chwili obecnej znaj-dują się tam:

• rozdzielczość ekranu – tą informację spo-ro telefonów zwraca błędnie w czasie dzia-łania midletu;

• kody klawiszy – tutaj jest duża niespój-ność wśród producentów.

Jeśli na twoim telefonie masz problemy z roz-dzielczością lub klawiszami, spróbuj dostoso-wać stałe z DeviceConstants.

W profesjonalnych build systemach uży-wanych to tworzenia aplikacji i gier JME często stosuje się bazy danych z ogrom-ną ilością parametrów opisujących poszcze-gólne modele telefonów. Kod klas typu DeviceConstants nie zawiera wartości wpi-sanych na sztywno tylko referencje do pól ba-zy. W fazie budowania wstawiane są tam kon-kretne wartości dla telefonu, dla którego robi się builda (najczęściej używa się do tego celu preprocesora).

Arytmetyka stałoprzecinkowaBardzo często w grach potrzebujemy ułamków. Pozycje postaci, prędkości, kod liczący fizykę i wiele innych modułów używa ułamków.

Niestety w konfiguracji CLDC1.0 nie mamy typu float. Co prawda pojawił się w CLDC1.1, ale procesory telefonów najczęściej nie mają jed-nostki FPU do obliczeń zmiennoprzecinkowych więc obliczenia na floatach są strasznie powolne. Ponadto ogromna grupa telefonów na rynku to CLDC1.0.

Bardzo łatwo i wydajnie można poradzić so-bie z tym problemem stosując tzw. arytmety-kę stałoprzecinkową (fixed point). Przeznacza-my pewną ilość bitów zwykłej liczby całkowitej na część ułamkową. Na przykład jeśli przezna-czymy 16 bitów na część ułamkową to liczba 1 będzie reprezentowana przez wartość 65536, liczba 0.5 przez wartość 32768.

Wartości fixed-point można dodawać i odej-mować jak zwykłe liczby: 1+0.5 = 1.5 jest repre-zentowane przez 65536+32768 = 98304. Na-tomiast mnożenie i dzielenie wymaga dodatko-wych operacji.

Do wygodnej obsługi operacji na liczbach fi-xed-point używamy klasy FP. Jej kod znajduje się na Listingu 7. Komentarze metod opisują krót-ko ich zastosowanie.

Jako, że wartości fixed-point są przechowywa-ne w zmiennych typu int problemem staje się rozróżnienie, która liczba jest normalna, a któ-ra jest wartością fixed-pint. Dobrą praktyką jest

dodawanie przedrostka fp_ do nazw wszystkich zmiennych, które będą przechowywać wartości fixed-point. Dzięki temu zawsze wiemy z jaką liczbą mamy do czynienia.

Listing 9a. Fragment metody tickGame, który aktualizuje aktorów

// update monsters:

for(int i=0; i < enemies.size(); i++)

{

Actor monster = (Actor)enemies.elementAt(i);

monster.tick(tickTime, fp_dt);

}

// update projectiles:

for(int i=0; i < projectiles.size(); i++)

{

Actor projectile = (Actor)projectiles.elementAt(i);

projectile.tick(tickTime, fp_dt);

}

// update player ship:

boolean left = isKeyPressed(KEY_LEFT);

boolean right = isKeyPressed(KEY_RIGHT);

boolean fire = isKeyTyped(KEY_SELECT);

playerShip.setSteering(left, right, fire);

playerShip.tick(tickTime, fp_dt);

Listing 9b. Metoda rysująca aktorówprivate void paintGameField(Graphics g)

{

// fill background:

g.setColor(0x0);

g.fillRect(0, 0, DeviceConstants.screenWidth, DeviceConstants.screenHeight);

// paint monsters:

if(enemies != null)

{

for(int i=0; i < enemies.size(); i++)

{

Actor monster = (Actor)enemies.elementAt(i);

monster.paint(g);

}

}

// paint projectiles:

if(projectiles != null)

{

for(int i=0; i < projectiles.size(); i++)

{

Actor projectile = (Actor)projectiles.elementAt(i);

projectile.paint(g);

}

}

// paint player's ship:

if(playerShip != null)

{

playerShip.paint(g);

}

}

09/200864


Obiekty w świecie gryCzas zająć się tym co dzieje się w czasie działa-nia gry. Jak to jest zrobione, że pojawiają się po-twory, gracz może poruszać statkiem i że poci-ski trafiają (lub nie) w przeciwników.

Zacznijmy od klasy Actor (Listing 8). Defi-niuje ona obiekt, który jest elementem świata gry, pewnej wirtualnej przestrzeni. Dalej będę nazywał takie obiekty aktorami. Klasa Actor definiuje takie cechy jak: wygląd, rozmiar, po-zycja w świecie, prędkość poruszania się. Do te-go dochodzą funkcje tick/paint, które mają aktualizować i rysować aktora.

Klasa Actor przewidziana jest by z niej dzie-dziczyć. I robimy to. W naszej grze nie uży-wamy instancji klasy Actor ale jej podklas: Monster, Projectile, SpaceShip.

Chciałbym także zauważyć, że klasa Actor korzysta z pewnych wcześniej opisanych me-chanizmów, np. pozycja i prędkość zapisana jest jako fixed-point, pole imageId definiuje jaki obrazek będzie używany do rysowania aktora, a sam kod rysujący używa resource managera.

Wszyscy aktorzy w naszej grze przechowy-wani są w klasie SimpleGameCanvas. Stwo-rzone są dwa obiekty klasy Vector: enemies i projectiles, oraz referencja do statku kosmicz-nego kontrolowanego przez gracza: playerShip.

W trakcie samej rozgrywki (stan STATE_Gameplay) co klatka na wszystkich aktorach wywoływane są metody tick i paint (Listingi 9a i 9b). Klasy dziedziczące z klasy Actor mogą dodawać funkcjonalność, np. metoda tick kla-

sy SpaceShip odpowiedzialna jest za reagowa-nie na input gracza, poruszanie statku w obrę-bie ekranu i tworzenie nowych pocisków (gry gracz strzeli), a obiekty klasy Projectile w cza-sie swojej aktualizacji obsługują zmianę używa-nego podczas rysowania obrazka, przez co ma-my prosty efekt animacji lecącego pocisku.

Poza tym, w metodzie tickGame, po zaktu-alizowaniu aktorów, dzieje się kilka rzeczy do-tyczących świata gry:

• obliczany jest czas jaki pozostał do wyge-nerowania nowego potwora – co klatka odejmowany jest tick time; jeśli czas do-biegł do zera tworzony jest nowy potwór (metoda spawnMonster, losowane są jego pozycja i parametry);

• sprawdzane jest czy pociski i potwory nie wyszły poza obszar gry – jeśli tak, są za-znaczane do usunięcia ze świata gry (wy-wołanie na nich metody destroy);

• sprawdzane są kolizje (używana metoda actorsIntersect) – kolizje oparte są na te-ście przecięcia dwóch prostokątów; spraw-dzamy kolizje między pociskami i potwora-mi oraz między statkiem gracza i potworami;

• na końcu usuwani są aktorzy, którzy w czasie przebiegu gry zostali oznaczeni jako do usunięcia.

Logika gryWiemy już, że co klatka wszyscy aktorzy są aktu-alizowani i rysowani. Cały czas toczy się swoista

symulacja. Jednak zostaje nam jeszcze jeden ele-ment – coś co decyduje czy gra się skończyła czy nie, ile gracz ma punktów i za co je zdobywa, co się ma stać gry trafimy potwora lub gdy potwór pożre statek gracza – logika gry.

W naszej grze większość logiki zawarta jest w kilku zdefiniowanych stałych i kilku metodach (Listing 10) wywoływanych w czasie trwania symulacji gdy zaistnieją pewne okoliczności.

Inaczej mówiąc, tocząca się w czasie gry sy-mulacja informuje o wystąpieniu pewnych zda-rzeń, a kod logiki gry reaguje – zmienia ilość punktów, usuwa aktorów, zmienia stan gry.

Podsumowanie i co dalejNauczyliśmy się jak stworzyć prostą aplika-cję JME, którą można wykorzystać jako bazę do tworzenia własnych projektów. Mam tak-że nadzieję, że przybliżyłem pewne zagadnie-nia dotyczące szeroko pojętego programowania gier, w szczególności w aspekcie JME. Ponadto przedstawiłem przykład architektury prostej gry (oszałamiający efekt na Rysunku 7).

Jeszcze raz zachęcam do analizy kodu (jak już wspomniałem w trakcie artykułu, kod do-stępny jest na stronie SDJ) gdyż zawiera on peł-ną działającą grę, a niestety nie wszystko dało się zmieścić w artykule i na listingach.

Kończąc chciałbym jeszcze wspomnieć o rze-czywistym świecie, w którym praktycznie na każ-dy telefon (ewentualnie grupę kilku telefonów) trzeba wykonać porting, tzn. dostosować grę tak żeby wszystko działało jak trzeba na konkretnym telefonie. A niestety bardzo często pojawiają się niespodziewane bugi mimo iż gra chodzi wspa-niale w emulatorze, a nawet na kilku telefonach – na kilku innych na pewno coś się zepsuje.

Dlatego jeśli zainteresowało cię robienie gier w JME zachęcam do zapoznania się z jakimś build systemem (np. J2ME Polish) oraz do testowania swoich gier na prawdziwych telefonach. No i oczy-wiście do rozwijania swojej wiedzy o tworzeniu gier – wiele technik znanych z pecetów lub konsol można stosować z powodzeniem także w medium jakim są telefony komórkowe.

Listing 10. Obsługa różnych zdarzeń w czasie gry

private static final int MONSTER_KILL_AWARD = 20;

private static final int FIRE_PENALTY = -10;

// gdy gracz wystrzelil pocisk

void onProjectileFired(Projectile projectile)

{

projectiles.addElement(projectile);

score += FIRE_PENALTY;

}

// gdy jakis potwor ma kolizje z jakims pociskiem

void onMonsterHit()

{

score += MONSTER_KILL_AWARD;

}

// gdy jakis potwor doszedl do dolu planszy

void onMonsterEscaped()

{

changeState(STATE_GameOver);

}

// gdy jakis potwor ma kolizje ze statkiem gracza

void onPlayerHit()

{

changeState(STATE_GameOver);

}

JACEK ZAGRODZKIJacek Zagrodzki od długiego czasu interesuje się sze-

roko pojętą tematyką tworzenia gier komputerowych.

W sferze zawodowej Jacek pracuje na stanowisku Se-

nior Java Developer w firmie Gamelion, wchodzącej

w skład grupy BLStream, gdzie zajmuje się tworzeniem

gier w Javie na telefony komórkowe. Grupa BLStream

powstała by efektywniej wykorzystywać potencjał

dwóch, szybko rozwijających się producentów opro-

gramowania - BLStream i Gamelion. Firmy wchodzące

w skład grupy specjalizują się w wytwarzaniu oprogra-

mowania dla klientów korporacyjnych, w rozwiąza-

niach mobilnych oraz produkcji i testowaniu gier.


Autor pragnie podziękować swojej ukochanej na-

rzeczonej Ani, która wspierała go w trakcie pisa-

nia artykułu.

09/200866

Programowanie urządzeń mobilnychProgramowanie gier dla Symbian OS – szkielet aplikacji


Maszyny, które jeszcze kilkadziesiąt lat temu stanowiły jedynie mrzon-kę wąskiej garstki specjalistów, dziś

mieszczą się w naszych kieszeniach. Mowa tu oczywiście o nowoczesnych telefonach komór-kowych. Na dzień dzisiejszy, za całkiem rozsąd-ną cenę otrzymujemy urządzenie wyposażone w kamerę o wysokiej rozdzielczości, kolorowy wyświetlacz, dostęp do szerokopasmowego in-ternetu, zintegrowany moduł GPS, wysokiej ja-kości odtwarzacz dźwięku stereo, akcelerometr i układ wspomagający renderowanie grafiki 3D w czasie rzeczywistym. No i przy okazji – apa-rat telefoniczny. Ten szalony pęd technologicz-ny tworzy ogromną, otwartą przestrzeń dla no-wych aplikacji, zaś lwią ich cześć stanowią gry. Niniejszy tekst rozpoczyna cykl artykułów traktujących o programowaniu gier dla Sym-bian OS – jednego z czołowych graczy na ryn-ku mobilnych systemów operacyjnych.

Zanim zaczniemy......kilka słów wstępu. Tak jak wspomniano wy-żej, niniejszy artykuł traktuje o programowa-

niu gier na telefony komórkowe działające pod kontrolą Symbian OS. Cykl poświęcony jest przede wszystkim dla programistów języka C++, którzy nie znają, lub znają słabo system operacyjny Symbian, a chcieliby na poważnie zainteresować się programowaniem gier na urządzenia mobilne pracujące pod jego kon-trolą. Symbian jest tworem potężnym i z pro-gramistycznego punktu widzenia dość kon-trowersyjnym (ciekawą dyskusję na ten temat przedstawia artykuł pt. Unix – piszemy pro-gram na komórkę autorstwa Bartosza Taudula, przedstawiony w numerze 06/2008 Software Developer's Journal). Cykl moich artykułów ma na celu przedstawienie tych udogodnień oferowanych przez Symbiana, które są klu-czowe przy programowaniu gier. Aby nieco uprościć to niełatwe zadanie, przedstawione rozważania ograniczać się będą do dziewiątej wersji wspomnianego systemu oraz platformy Series60. W niniejszym tekście przedstawiony zostanie szkielet aplikacji dostosowany do po-trzeb mobilnych gier, stanowiący bazę dla ko-lejnych, bardziej zaawansowanych rozważań. W ramach omówienia wspomnianego szkie-letu przeanalizowane zostaną takie zagadnie-nia jak implementacja głównej pętli gry, ryso-wanie, obsługa interakcji aplikacji z użytkow-nikiem poprzez klawiaturę, oraz obsługa pod-stawowych zdarzeń systemowych.

Środowisko pracyPrzygodę z programowaniem gier dla Sym-bian OS rozpoczniemy od przygotowania środowiska pracy. Zakładam, że Czytelnik posiada system operacyjny Windows XP. Na początek musimy zainstalować dystrybu-cję Perl'a oraz środowisko uruchomieniowe języka Java. W dalszej kolejności będziemy potrzebowali SDK (Software Development Kit), zawierającego podstawowy zestaw na-rzędzi potrzebnych do tworzenia aplikacji dla Symbian OS. Nasz wybór pada w tym przypadku na pakiet S60 3rd Edition SDK for Symbian OS, Feature Pack 2. Pakiet ten dostępny jest za darmo na portalu Forum No-kia – przed jego ściągnięciem wymagana jest jednak rejestracja (ramka W Sieci). Aby roz-począć instalację wystarczy rozpakować po-brane archiwum z SDK i uruchomić plik se-tup.exe. Proces powinien odbyć się bezpro-blemowo. Na sam koniec instalator zapyta się o zgodę na doinstalowanie zestawu na-rzędzi kompilacyjnych dla procesora ARM. Na pytanie to należy odpowiedzieć twierdzą-co – bez tego zestawu nie będziemy w sta-nie zbudować naszej aplikacji w wersji dzia-łającej na urządzeniu. Jeśli chodzi o wymaga-nia dla SDK, to przed jego instalacją powin-niśmy uzbroić się w około 1GB wolnej prze-strzeni dyskowej oraz odrobinę wolnego cza-su (ze względu na dużą liczbę małych pli-ków w archiwum instalacja trwa dość dłu-go). Pracę ze środowiskiem warto rozpocząć od uruchomienia emulatora. Można to zro-bić wybierając odpowiednią opcję z Menu Start lub – prościej – wpisując z linii pole-ceń komendę epoc. Jeśli wszystko poszło do-brze, to nasze dotychczasowe wysiłki nagro-dzone zostaną uruchomieniem się emulatora (Rysunek 1).

Po uruchomieniu emulatora należy zareje-strować SDK wybierając z menu opcję Help

Programowanie gier dla Symbian OSNiniejszy tekst rozpoczyna cykl artykułów traktujących o programowaniu gier na telefony komórkowe działające pod kontrolą Symbian OS. W pierwszym odcinku cyklu przedstawiona jest implementacja szkieletu aplikacji zawierającego takie podstawowe udogodnienia jak pętla gry, rysowanie, a także przechwytywanie i obsługa zdarzeń klawiatury oraz interakcja z systemem.

Dowiesz się:• Jak rozpocząć pracę z narzędziami do progra-

mowania aplikacji dla Symbian OS;

• Jak zaimplementować pętlę gry w aplikacji dla

Symbian OS;

• Jak w grach pisanych pod Symbian OS efek-

tywnie renderować grafikę, obsługiwać zda-

rzenia klawiatury i przechwytywać podstawo-

we zdarzenia systemowe.

Powinieneś wiedzieć:• Średnio zaawansowana wiedza ogólna z za-

kresu programowania w języku C++;

• Podstawowa wiedza z zakresu programowa-

nia orientowanego obiektowo w języku C++.

Poziom trudności

Szkielet aplikacji

09/200866



–>Register. Drugim narzędziem składającym się na nasze środowisko pracy – w odniesie-niu do tego artykułu – będzie Carbide.C++ v1.3. Carbide to IDE stworzone w oparciu o platformę Eclipse, dedykowane jako wspar-cie dla programistów tworzących aplikacje pod Symbian OS. Narzędzie to w darmowej wersji Express można pobrać z portalu Fo-rum Nokia (ramka W Sieci).

Przy pierwszym uruchomieniu Carbide prosi o ustalenie folderu roboczego – najwy-godniej jest w tym celu stworzyć sobie kata-log przeznaczony na symbianowe projekty (najlepiej na tym samym dysku, na którym zainstalowane było SDK). Po uruchomieniu IDE automatycznie załaduje wtyczki z SDK i poprosi o restart. Po ponownym urucho-mieniu IDE nasze środowisko będzie goto-we do pracy.

Szkielet aplikacji – przeglądRozważania przedstawione w dalszej czę-ści artykułu opierać się będą na kodach źró-dłowych przykładowej aplikacji – GameSke-leton. Kody te można pobrać z witryny SDJ. Kluczowe fragmenty wspomnianych ko-dów przedstawione będą na listingach w ni-niejszym artykule, aczkolwiek gorąco nama-wiam do pobrania całej paczki, chociażby w celu uruchomienia przykładowego progra-mu i poeksperymentowania z kodem źró-dłowym.

Symbian uważany jest za system trudny do nauki. Wynika to chociażby z faktu, że apli-kacja typu Hello World składa się z około 50 kilobajtów kodu i konfiguracji rozmieszczo-nych w kilkunastu plikach. Dodatkowo Sym-bian narzuca pewne specyficzne idiomy ko-

Rysunek 1. Okno emulatora przy pierwszym uruchomieniu po instalacji SDK

Listing 1. Definicja klasy CGameSkeletonApplication

class CGameSkeletonApplication

: public CAknApplication

{

public:

TUid AppDllUid() const;

protected:

CApaDocument* CreateDocumentL();

}; // class CGameSkeletonApplication

Listing 2. Implementacja metod klasy CGameSkeletonApplication

const TUid KUidGameSkeletonApp = { 0xA000958F };

CApaDocument* CGameSkeletonApplication::CreateDocumentL()

{

return ( static_cast< CApaDocument* >(

CGameSkeletonDocument::NewL( *this ) ) );

}

TUid CGameSkeletonApplication::AppDllUid() const

{

return KUidGameSkeletonApp;

}

Listing 3. Interfejs klasy CGameSkeletonDocument

class CGameSkeletonDocument

: public CAknDocument

{

public:

static CGameSkeletonDocument* NewL(

CEikApplication& aApp );

static CGameSkeletonDocument* NewLC(

CEikApplication& aApp );

virtual ~CGameSkeletonDocument();

CEikAppUi* CreateAppUiL();

private:

CGameSkeletonDocument( CEikApplication& aApp );

void ConstructL();

}; // class CGameSkeletonDocument

Listing 4. Interfejs klasy CGameSkeletonAppUi

class CGameSkeletonAppUi

: public CAknAppUi

{

public:

CGameSkeletonAppUi();

virtual ~CGameSkeletonAppUi();

void ConstructL();

private:

void HandleCommandL( TInt aCommand );

TKeyResponse HandleKeyEventL(

const TKeyEvent& aKeyEvent,

TEventCode aType );

private:

CGameSkeletonContainer* iAppContainer;

}; // class CGameSkeletonAppUi

09/200868



dowania, które mocno odbiegają od standar-du języka C++. W przypadku pisania progra-mów dla Symbian OS stosuje się często kre-atory generujące szkielety aplikacji. W dal-szej części artykułu opiszę właśnie taki szkie-let, stanowiący punkt wyjścia przy progra-mowaniu gier. Symbian oferuje cały szereg architektur aplikacji z graficznym interfej-sem (np. architektura jednowidokowa lub wielowidokowa). Z punktu widzenia pro-gramisty gier, dużą cześć wiedzy na temat wspomnianych architektur można pominąć. W naszej szkieletowej aplikacji zastosujemy bardzo prostą architekturę bazującą na jed-nej, pełnoekranowej kontrolce. Osoby zainte-resowane szczegółami technicznymi związa-nymi z architekturą aplikacji w Symbian OS zapraszam do ramki Bibliografia gdzie przed-stawiłem tytuły nawiązujące do tego tematu. W niniejszym podpunkcie przedstawię jedy-nie to, co konieczne jest do zrozumienia pre-zentowanego przykładu. Na początek – szyb-ki przegląd klas wchodzących w skład naszej przykładowej aplikacji. Zacznijmy od klasy CGameSkeletonApplication. definicja tej kla-sy przedstawiona jest na Listingu 1.

Jak widać na wspomnianym Listingu, de-finicja ta nie jest specjalnie skomplikowana. Klasa CXXXApplication (gdzie wedle kon-wencji Symbianowej XXX to nazwa projek-tu) odgrywa rolę punktu wejścia aplikacji (ang. entry point). Kluczowa jest tu metoda fabrykująca CreateDocumentL(), która od-powiada za tworzenie dokumentu aplikacji (CApaDocument). Osoby zaciekawione zna-czeniem magicznych prefiksów i postfiksów (np. C lub L) w nazwach prezentowanych klas oraz ich metod zapraszam do przeczytania

Listing 5. Definicja konstruktora klasy CGameSkeletonAppUi

void CGameSkeletonAppUi::ConstructL()

{

CAknAppUiBase::SetFullScreenApp( ETrue );

BaseConstructL();

CAknAppUi::SetKeyBlockMode();

iAppContainer

= new ( ELeave ) CGameSkeletonContainer;

iAppContainer->ConstructL( ApplicationRect() );

AddToStackL( iAppContainer );

}

Listing 6. Definicja destruktora klasy CGameSkeletonAppUi

CGameSkeletonAppUi::~CGameSkeletonAppUi()

{

if ( iAppContainer )

{

RemoveFromStack( iAppContainer );

delete iAppContainer;

}

}

Listing 7. Definicja metody HandleCommandL

void CGameSkeletonAppUi::HandleCommandL( TInt aCommand )

{

switch ( aCommand )

{

case EEikCmdExit:

{

Exit();

break;

}

default: break;

}

}

Listing 8. Funkcje zdefiniowane w pliku GameSkeleton.cpp

LOCAL_C CApaApplication* NewApplication()

{

return new CGameSkeletonApplication;

}

GLDEF_C TInt E32Main()

{

return EikStart::RunApplication( NewApplication );

}

Listing 9. Schemat pętli gry

while ( Gra trwa )

{

1. Oblicz czas który minął od poprzedniego

przebiegu pętli.

2. Uaktualnij model gry na podstawie różnicy czasu,

który upłynął od ostatniego przebiegu pętli czasu.

3. Narysuj na podstawie modelu kolejną ramkę gry

i wyświetl ją na ekranie.

4. Zsynchronizuj dźwięk z modelem gry.

}Rysunek 2. Efekt działania aplikacji GameSkeleton

09/200868



ramki zatytułowanej Idiomy kodowania przy programowaniu aplikacji dla Symbian OS. Wracając do metody CreateDocumentL(), w jej ciele (Listing 2) jest dynamicznie two-rzona i jednocześnie zwracana instancja kla-sy CGameSkeletonDocument. Druga meto-da klasy CGameSkeletonApplication, czyli AppDllUid() zwraca tzw. UID aplikacji. Pi-sząc w uproszczeniu, UID to niepowtarzal-ny identyfikator aplikacji. Skąd i w jaki spo-sób taki UID można pobrać, to już odręb-na kwestia – będę o tym pisał w dalszej czę-ści artykułu. Dociekliwi Czytelnicy zaintere-sują się zapewne dlaczego instancja obiektu CGameSkeletonDocument tworzona jest przy pomocy tajemniczej metody statycznej NewL. Tychże Czytelników odsyłam tym razem do ramki zatytułowanej Idiomy kodowania przy programowaniu aplikacji dla Symbian OS.

W dalszej kolejności warto zainteresować się klasą CGameSkeletonDocument. Interfejs tej klasy przedstawiony jest na Listingu 3.

Według nomenklatury symbianowej klasa CXXXDocument reprezentuje część M (model) z wzorca MVC (ang. Model-View-Controller) na którym bazuje architektura aplikacji UI. Innymi słowy – klasa ta odpowiada za zarzą-dzanie danymi tej aplikacji (np. wczytywanie i zapisywanie danych na dysk w przypadku tzw. aplikacji opartych na plikach). W przy-padku naszego szkieletu gry nie będziemy ko-rzystać z klasycznego MVC i w tym kontek-ście klasa CGameSkeletonDocument ma cha-rakter pomocniczy. To co nas w tej klasie inte-resuje to metoda fabrykująca CreateAppUiL, która istnieje jedynie po to, aby zwrócić in-stancję obiektu klasy CGameSkeletonAppUi. Klasa ta (jej interfejs pokazany jest na Li-stingu 4) odpowiada za zarządzanie graficz-nym interfejsem użytkownika – reprezentu-je część V (ang. view, czyli widok) we wspo-mnianym wcześniej wzorcu MVC.

Klasa CGameSkeletonAppUi nawiązuje do interesujących nas tematów, więc przeanali-zujemy ją bardziej szczegółowo. Gdyby nasz szkielet reprezentował aplikację z systemo-wym interfejsem graficznym dla Symbia-na, to właśnie ta klasa byłaby odpowiedzial-na za przechowywanie i kontrolę jej widoku (lub widoków). Widoki, z kolei odgrywają ro-lę kontenerów kontrolek. W przypadku pi-sania gry niepotrzebny nam jest cały ten na-rzut, dlatego skorzystamy z prostego konte-nera (CGameSkeletonContainer), który re-prezentuje prostą kontrolkę przykrywają-cą cały wyświetlacz urządzenia. Do szcze-gółów samej kontrolki przejdziemy w dal-szej części artykułu – teraz skupmy się na implementacji poszczególnych metod klasy CGameSkeletonAppUi. Na początek konstruk-tor ConstructL() (Czytelników zdziwio-nych dlaczego nazywam zwyczajną metodę konstruktorem, zapraszam do lektury ram-ki Idiomy kodowania przy programowaniu na-

Listing 10. Interfejs klasy CGameSkeletonContainer

class CGameSkeletonContainer

: public CCoeControl

{

public:

static TInt Tick( TAny* aCallback );

~CGameSkeletonContainer();

void ConstructL( const TRect& aRect );

void FocusChanged( TDrawNow aDrawNow );

void SizeChanged();

TInt CountComponentControls() const;

CCoeControl* ComponentControl( TInt aIndex ) const;

TKeyResponse OfferKeyEventL(


TEventCode aType );

private:

void Draw( const TRect& aRect ) const;

void StartTickGenerator();

void StopTickGenerator();

void OnTick();

void Draw( CGraphicsContext& aGc ) const;

void Update( TInt64 aDt );

CWsBitmap* iBackupBitmap;

CFbsBitmapDevice* iBitmapDevice;

CFbsBitGc* iBitmapGc;

CFpsCounter* iFpsCounter;

CPeriodic* iTickGenerator;

TTime iTickStart;

TTime iTickStop;

TKeyState iKeyState;

}; // class CGameSkeletonContainer

Listing 11. Definicja metody CGameSkeletonContainer::ConstructL

void CGameSkeletonContainer::ConstructL( const TRect& aRect )

{

CreateWindowL();

SetBlank();

SetRect( aRect );

iBackupBitmap

= new ( ELeave ) CWsBitmap( iCoeEnv->WsSession() );

iBackupBitmap->Create(

Rect().Size(),

iEikonEnv->DefaultDisplayMode() );

iBitmapDevice

= CFbsBitmapDevice::NewL( iBackupBitmap );

User::LeaveIfError(

iBitmapDevice->CreateContext( iBitmapGc ) );

iTickGenerator

= CPeriodic::NewL( CActive::EPriorityStandard );

iFpsCounter = CFpsCounter::NewL(

KFpsCounterIntervalInSeconds );

ActivateL();

}

09/200870



tywnych aplikacji dla Symbian OS). Ciało tej funkcji przedstawione jest na Listingu 5.

Pierwsza instrukcja tej metody, czy-li wywołanie funkcji SetFullScreenApp() z klasy bazowej CAknAppUiBase odpowia-da za przełączenie aplikacji w tryb pełno-

ekranowy. Kolejna instrukcja (wywołanie BaseConstructL()) odpowiada za inicjali-zację składowych kontrolki odziedziczonych z klasy bazowej. Cel wywoływania funkcji SetKeyBlockMode() opisany będzie w dalszej części artykułu. W następnym kroku mo-

żemy zaobserwować dwufazową konstruk-cję naszej kontrolki (patrz: Idiomy kodowa-nia przy programowaniu natywnych aplikacji dla Symbian OS). Na końcu metody umiesz-czono kod odpowiedzialny za bardzo istotną operację – dodanie wspomnianej kontrolki do stosu kontrolek. Gdybyśmy pominęli ten krok, to nasza kontrolka nie otrzymywałaby systemowych powiadomień związanych z ob-sługą klawiatury i nie bylibyśmy w stanie ob-służyć interakcji użytkownika z aplikacją.

W destruktorze klasy CGameSkeletonAppUi (Listing 6) nie dzieje się nic ciekawego oprócz zdjęcia naszego kontenera ze stosu kontrolek oraz zniszczenia go przy pomocy operato-ra delete.

Definicja metody HandleCommandL (Listing 7) może wydawać się mało ciekawa, ale warto przeanalizować jej treść.

W systemie Symbian, w kontekście interak-cji z użytkownikiem mamy do czynienie z dwo-ma typami komunikatów: są to komendy oraz zdarzenia klawiatury. Komendy reprezentu-ją pewne zdarzenie logiczne, związane z sys-temowymi komponentami graficznego inter-fejsu użytkownika (np. wybór opcji w menu). W przypadku programowania gier, z kompo-nentów tych rzadko się korzysta. Jeśli potrze-bujemy menu w grze, to raczej narysujemy je ręcznie i obsłużymy przy pomocy niskopozio-mowych zdarzeń klawiatury. W tej sytuacji po-wstaje pytanie: po co implementujemy metodę HandleCommandL() w naszym szkielecie? Otóż istnieje ku temu konkretny powód. Chodzi o to, że każda aplikacja symbianowa musi w po-prawny sposób obsłużyć systemową komendę EEikCmdExit. Komenda ta przychodzi do apli-kacji od systemu w takich sytuacjach jak zabi-cie aplikacji:

• z poziomu listy aktywnych zadań syste-mowych;

• przy pomocy czerwonego klawisza;• z powodu jej deinstalacji;• z powodu niskiego poziomu pamięci w

systemie.

Zignorowanie tej komendy nie przynosi ra-czej nic dobrego. Teoretycznie moglibyśmy nie przeładowywać definicji HandleCommandL() z klasy bazowej, która poprawnie obsługuje ten komunikat, aczkolwiek w takiej sytuacji traci-my możliwość reakcji na to istotne zdarzenie (można przy tej okazji spróbować np. zapisać stan gry na dysk, aby następnym razem nie za-czynać rozgrywki od początku).

Na końcu pozostaje nam rozważyć definicję metody HandleKeyEventL(). Metoda ta służy do obsługi niskopoziomowych zdarzeń genero-wanych przez klawiaturę. W naszym przypad-ku implementacja tej metody jest trywialna i mieści się w jednej linii:

return EKeyWasNotConsumed;

Listing 12. Definicja metody StartTickGenerator odpowiedzialnej za uruchomienie timera

void CGameSkeletonContainer::StartTickGenerator()

{

if ( !iTickGenerator->IsActive() )

{

iTickGenerator->Start(

KDesiredFramesPerSecond,

KDesiredFramesPerSecond,

TCallBack( CGameSkeletonContainer::Tick,

this ) );

iTickStart.HomeTime();

}

}

Listing 13. Definicja metody CGameSkeletonContainer::Tick()

TInt CGameSkeletonContainer::Tick( TAny* aCallback )

{

ASSERT( aCallback );

CGameSkeletonContainer* gameSkeletonContainer =

static_cast< CGameSkeletonContainer* >( aCallback );

gameSkeletonContainer->OnTick();

return ETrue;

}

Listing 14. Implementacja metody CGameSkeletonContainer::Draw()

void CGameSkeletonContainer::Draw( const TRect& aRect )

const

{

CWindowGc& gc = SystemGc();

gc.BitBlt( aRect.iTl, iBackupBitmap, aRect );

}

Listing 15. Implementacja metody CGameSkeletonContainer::OnTick()

void CGameSkeletonContainer::OnTick()

{

iTickStop.HomeTime();

TInt64 dt = iTickStart.Int64() - iTickStop.Int64();

iTickStart = iTickStop;

Update( dt );

Draw( *iBitmapGc );

DrawNow();

iFpsCounter->Update();

}

09/200870



Listing 16. Implementacja metody uaktualniającej zawartość tylnego bufora

void CGameSkeletonContainer::Draw(

CGraphicsContext& aGc ) const

{

aGc.Reset();

aGc.SetBrushColor( KRgbBlack );

aGc.SetBrushStyle( CGraphicsContext::ESolidBrush );

aGc.DrawRect( Rect() );

TBuf< KFpsMessageMaxLength > fpsMessage;

fpsMessage.Format( KFpsMessageFormatString,

iFpsCounter->Fps() );

aGc.UseFont( iEikonEnv->NormalFont() );

aGc.SetPenColor( KRgbWhite );

aGc.DrawText( fpsMessage,

TPoint( KFpsMessagePosX,

KFpsMessagePosY ) );

aGc.DiscardFont();

}

Listing 17. Obsługa zdarzeń klawiatury

TKeyResponse CGameSkeletonContainer::OfferKeyEventL(


TEventCode aType )

{

TKeyResponse response = EKeyWasConsumed;

TKeyState input = KKeyNull;

switch ( aKeyEvent.iScanCode )

{

case EStdKeyDevice0: input = KKeySoftLeft; break;

case EStdKeyDevice1: input = KKeySoftRight; break;

case EStdKeyUpArrow: input = KKeyUp; break;

case EStdKeyDownArrow: input = KKeyDown; break;

case EStdKeyLeftArrow: input = KKeyLeft; break;

case EStdKeyRightArrow: input = KKeyRight; break;

case EStdKeyDevice3: input = KKeyFire; break;

case '0': input = KKey0; break;










default: response = EKeyWasNotConsumed; break;

}

if ( EEventKeyDown == aType )

{

iKeyState |= input;

}

else if ( EEventKeyUp == aType )

{

iKeyState &= ~input;

}

return response;

}

09/200872



Zwrócenie takiej wartości przez tę funkcję jest sygnałem dla silnika aplikacji, że zda-rzenia klawiatury będą obsługiwane gdzie indziej – w naszym przypadku będą one przekierowywane bezpośrednio do naszej kontrolki.

Tak oto przebrnęliśmy przez klasy stanowią-ce fundament szkieletu gry. Ostatnia klasa z tego zestawu, czyli CGameSkeletonContainer zawiera to, co stanowi istotę niniejszego ar-tykułu – czyli wszystkie podstawowe mecha-nizmy obsługi gry. Wspomniane mechani-zmy będą opisywane w kolejnych podpunk-tach artykułu.

Aby zakończyć przegląd prezentowanego szkieletu aplikacji, warto wyjaśnić znacznie funkcji zdefiniowanych w pliku GameSkele-ton.cpp (Listing 8).

Funkcje te definiują główny punkt wejścia całego projektu – taki odpowiednik funk-cji main() w konsolowych programach pisa-nych w języku C lub C++. Prawdziwa funk-cja main() ukryta jest w systemowym silni-ku aplikacji (ang. application framework), któ-ry wykorzystuje funkcje przedstawione na Li-stingu 8 w celu stworzenia instancji naszej aplikacji.

Duża część przedstawionego wyżej kodu ma charakter powtarzalny – przy tworze-niu nowego projektu trzeba go napisać od no-wa, podmieniając jedynie pewne jego części. Aby uprościć ten proces, przy tworzeniu no-wych projektów aplikacji symbianowych, wy-korzystuje się różnego rodzaju generatory ko-du. W drugiej części cyklu artykułów o pro-gramowaniu gier dla Symbian OS, w którym będę między innymi pokazywał, jak na przy-kładzie zaprezentowanego tu szkieletu stwo-rzyć prostą grę, zaprezentuję narzędzie auto-matyzujące ten proces.

Pętla gryWiększość aplikacji przeznaczonych dla Sym-bian OS działa w oparciu o zdarzenia gene-rowane na bazie interakcji z użytkownikiem. Typowa aplikacja symbianowa (na przykład program do pisania SMS-ów) czeka na reak-cję użytkownika (np. wciśnięcie klawisza). Jeśli wspomniana reakcja nie następuje, to aplikacja po prostu nie robi nic. Podejście ta-kie jest jak najbardziej uzasadnione w przy-padku programów dedykowanych systemom mobilnym. Przy jego stosowaniu, w sytuacji kiedy użytkownik nie generuje żadnych zda-rzeń, wątek aplikacji może być zawieszony, dzięki czemu urządzenie zużywa mniej cen-nej energii. W przypadku gier sytuacja wy-gląda nieco inaczej: wnika to z faktu, że w przypadku tego rodzaju aplikacji tematem przewodnim jest zazwyczaj akcja. Jeśli użyt-kownik nie reaguje, to (zazwyczaj) przegry-wa, gdyż akcja w międzyczasie toczy się da-lej. Innymi słowy – brak reakcji użytkowni-ka w grze nie oznacza, że będzie ona stać bez-czynnie. W przypadku tego rodzaju aplikacji – wymagających ciągłej aktualizacji zarówno w warstwie graficznej (widok) jak i logicznej (model) – jako mechanizm sterujący stosuje się tzw. pętlę gry. Pętla taka przedstawiona jest w postaci pseudokodu na Listingu 9.

W dalszej części tego podpunktu przedsta-wię, w jaki sposób można zrealizować wspo-mnianą pętlę w aplikacji dedykowanej dla Symbian OS. Już na samym początku trzeba mocno podkreślić, że blokująca pętla while, podobna do tej, którą pokazałem na Listingu 9, absolutnie nie wchodzi w rachubę. Gdy-by ktoś pokusił się o jej zastosowanie, to po kilkunastu sekundach miałby okazję zaob-serwować skutki wystąpienia niechlubnego, systemowego panika EVwsViewEventTimeOut

(panik to w nomenklaturze Symbian OS pe-wien rodzaj assercji), stanowiącego zmorę wielu programistów symbianowych. W prak-tyce fakt ten objawia się wystąpieniem sys-temowej notki z napisem ViewSrv 11 i za-trzymaniem aplikacji. Aby w pełni zrozu-mieć skąd bierze się ten komunikat, należa-ło by wyjaśnić ideę tzw. aktywnych obiektów (ang. active objects), czyli mechanizmu lek-kich wątków zaimplementowanych w syste-mie Symbian. Temat ten wykracza jednak poza ramy niniejszego artykułu, zaś jego zro-zumienie nie jest konieczne do pisania gier bazujących na przedstawionym tu szkielecie. Osoby zainteresowane pogłębieniem swojej wiedzy w zakresie aktywnych obiektów odsy-łam do ramki Bibliografia, w której przedsta-wiłem listę tytułów zgłębiających między in-nymi i tę tematykę.

Pisząc w dużym uproszczeniu, opisany wyżej problem wynika z faktu, że aktywne obiekty, na których opiera się wielowątko-wość w Symbian OS, nie podlegają wywłasz-czaniu i kręcąca się bez końca pętla while() sprawiłaby, iż inne wątki działające w sys-temu nie mogłyby dojść do głosu. Kluczem do rozwiązania tego problemu jest wyko-rzystanie tzw. timera (będącego w rzeczywi-stości aktywnym obiektem), czyli mechani-zmu, który powoduje cykliczne wywoływa-nie funkcji zwrotnej (ang. callback). W na-szym przypadku, każde takie wywołanie od-powiadać będzie jednemu przebiegowi opisa-nej wyżej pętli gry. W tym momencie, w gło-wach niektórych Czytelników może pojawić się myśl o tym, aby wykorzystać wielokrotne timery do kontroli logiki aplikacji. Pomysły takie należy raczej odrzucić – ich stosowanie prowadzi do powstawania trudnych proble-mów synchronizacyjnych, zaś wynikowy kod trudno się rozwija i pielęgnuje. Dodatkowo, używanie wielu aktywnych obiektów pro-wadzi do zużywania zasobów jądra systemu i znacznie obniża wydajność aplikacji. Jeden timer stanowiący serce naszej gry będzie jak najbardziej wystarczający. W tym momencie proponuję spojrzeć na Listing 10 zawierający interfejs klasy CGameSkeletonContainer.

Do zawartości wspomnianego Listingu będę odnosił się wielokrotnie. W tym miej-scu proponuję zwrócić uwagę na wskaź-nik do obiektu CPeriodic. Obiekt ten, two-rzony dynamicznie w konstruktorze klasy CGameSkeletonContainer (Listing 11) repre-zentuje wspomniany timer.

Dostęp do obiektu otrzymujemy przez wskaźnik iTickGenerator. Działanie timera jest bardzo proste. Tuż po stworzeniu jest on nieaktywny. Sposób jego uruchomienia przed-stawiony jest na Listingu 12.

Na początek musimy sprawdzić czy ti-mer nie jest przypadkiem już uruchomio-ny. Jeśli ten warunek jest spełniony to mo-żemy rozpoczynać pracę. Uruchomienie ti-

Listing 18. Obsługa zdarzenia utraty aktywności

void CGameSkeletonContainer::FocusChanged(

TDrawNow aDrawNow )

{

if ( IsFocused() )

{

StartTickGenerator();

}

else

{

if ( iTickGenerator->IsActive() )

{

StopTickGenerator();

}

}

if ( aDrawNow )

{

DrawNow();

}

}

09/200872



mera wykonujemy za pośrednictwem funk-cji Start(). Funkcja ta przyjmuje trzy argu-menty – pierwszy z nich określa po jakim czasie timer ma ruszyć, druga definiuje in-terwał pomiędzy kolejnymi tyknięciami zaś ostatni opakowuje funkcję zwrotną. Obiekt opakowujący przyjmuje adres funkcji (w na-szym przykładzie jest to statyczna metoda CGameSkeletonContainer::Tick) oraz adres obiektu, który do tej metody będzie przeka-zywany przy każdym jej uruchomieniu. W naszym przypadku jest to wskaźnik na siebie samego (this). Ten prosty trik pozwala nam przekazać do funkcji zwrotnej obiekt, który kontroluje timer. Spójrzmy teraz na defini-cję funkcji CGameSkeletonContainer::Tick (Listing 13).

Ta statyczna metoda rzutuje otrzymany wskaźnik typu TAny* (symbianowy odpo-wiednik typu void* – ramka zatytułowana Symbian a definicje typów) na wskaźnik do kontenera (CGameSkeletonContainer*) i wy-wołuje na nim metodę OnTick(). Ta ostatnia jest już zwyczajną metodą niestatyczną i ja-ko taka posiada dostęp do wszystkich skład-ników klasy. W metodzie tej możemy umie-ścić ciało pętli gry.

Uważni czytelnicy analizujący implemen-tację metod klasy CGameSkeletonContainer zauważyli być może pewien potencjalny de-fekt. Chodzi o to, że w konstruktorze kla-sy nie występuje inicjacja wszystkich skła-dowych (np. iTickStart, iTickStop czy iKeyState). Wbrew pozorom, efekt ten jest zamierzony i wiąże się z tym, że składowe w klasach oznaczonych prefiksem C, czyli – we-dług symbianowych konwencji kodowania – dziedziczących po klasie bazowej CBase, są automatycznie zerowane przez konstruk-tor CBase.

Zanim przejdziemy do omawiania kolej-nych zagadnień, warto jeszcze ustosunkować się do wykorzystania stałej KDesiredFramesPerSecond. Stała ta określa częstotliwość tyka-nia naszego timera i co za tym idzie – maksy-malną liczbę ramek rysowanych w trakcie jed-nej sekundy, czyli tzw. współczynnik FPS (ang. Frames Per Second). W przypadku prezentowa-nego przykładu wartość wspomnianej stałej wynosi 1000000/30. 1000000 określa licz-bę mikrosekund w jednej sekundzie (timer przyjmuje interwały zapisane w mikrosekun-dach). W tej sytuacji zakładamy, że timer uru-chomi funkcję OnTick() około trzydziestu razy w trakcie jednej sekundy. Dociekliwi czytelni-cy mogą zastanawiać się dlaczego dobrałem tę wartość w taki, a nie inny sposób. Oto wyjaśnie-nie. W systemie Symbian w wersji 9 standardo-wa rozdzielczość timera wynosi 1/64 sekundy (dokładnie 15.625 milisekund) – ogranicze-nie to dotyczy zarówno emulatora jak i sprzę-tu. Inaczej mówiąc – timer nie jest w stanie ty-kać szybciej niż 64 razy na sekundę. W tej sytu-acji, jeśli ustawimy interwał timera na 20 mili-

sekund, to tyknięcia i tak będą występować co około 30 milisekund (2 x 15.625 milisekund). Stąd wniosek, że w celu uzyskania równomier-nego tykania warto przydzielać interwały o wielokrotności 15 milisekund. Dobrana prze-ze mnie wartość daje stosunkowo równomier-ną częstotliwość odświeżania ekranu na pozio-mie 30/31 FPS. Częstotliwość ta jest stosunko-wo optymalna dla większości gier uruchamia-nych na telefonach komórkowych. Pętlę gry, w zależności od potrzeb, można zaimplemento-wać na bazie innych timerów, np. CHeartBeat, CTimer czy CIdle. Niektóre, alternatywne roz-wiązania w tym zakresie przedstawię w kolej-nych artykułach z cyklu Programowanie Gier Dla Symbian OS.

Rysowanie System Symbian oferuje cały szereg API prze-znaczonych do rysowania. Najprostszy spo-sób renderowania grafiki wiąże się z wyko-rzystaniem standardowego kontekstu gra-ficznego (CWindowGc). Dostęp do tego kon-tekstu można uzyskać następująco:

CWindowGc& gc = SystemGc();

Za odrysowanie kontrolki na ekranie odpo-wiada funkcja Draw() w klasie ją reprezen-tującej.

Do funkcji tej przekazywany jest prostokąt określający fragment ekranu, na którym kon-trolka może rysować (w naszym przypadku jest to pełny obszar wyświetlacza). Na Listingu 14 przedstawiona jest implementacja metody CGameSkeletonContainer::Draw(). Do zawar-tości tego Listingu powrócimy za moment.

Kolejna alternatywna metoda rysowania polega na bezpośrednim odwoływaniu się do bufora ekranu przy pomocy dedykowane-

go API (DSA, czyli Direct Screen Access), bądź wykorzystaniu biblioteki OpenGL ES. W na-szym przykładzie wykorzystane jest jeszcze inne podejście, powszechnie znane jako po-dwójne buforowanie (ang. double buffering). Podejście to w kontekście Symbian OS może być z powodzeniem wykorzystywane zarów-no przy implementacji stosunkowo statycz-nych gier logicznych, jak i szybkich, dyna-micznych gier akcji. W przypadku stosowa-nia tej techniki aplikacja wykorzystuje tzw. tylny bufor (ang. back buffer), na którym ry-suje się scenę. Później bufor ten jest przeno-szony do bufora ramki (czytaj: na ekran) przy pomocy jednej, szybkiej operacji binarnego kopiowania (ang. blitting). Z racji tego, że po-jedyncze operacje rysowania w buforze ram-ki są zazwyczaj bardzo czasochłonne, to ryso-wanie poszczególnych elementów sceny gry bezpośrednio na ekran jest zazwyczaj wą-skim gardłem wydajnościowym i na doda-tek powoduje nieprzyjemne dla oka migota-nie. Korzystając z techniki podwójnego bu-forowania unikamy obydwu problemów. W przypadku aplikacja GameSkeleton, do imple-mentacji opisanej wyżej techniki wykorzy-stamy klasę CWsBitmap, która posłuży nam ja-ko tylny bufor. Kod odpowiedzialny za two-rzenie i inicjację obiektu tej klasy znajduje się w metodzie CGameSkeletonContainer::ConstructL (Listing 11). Oprócz samej bit-mapy (iBackupBitmap) potrzebne są nam dwie dodatkowe składowe: iBitmapDevice oraz iBitmapGc. Obiekty reprezentowane przez te składowe niezbędne są do stworze-nia kontekstu graficznego związanego z bit-mapą reprezentującą tylny bufor. W rezulta-cie możemy używać iBitmapGc jak zwyczaj-nego kontekstu graficznego, zaś wyniki prze-prowadzanych na nim operacji zostaną zapi-

Konwencje oraz idiomy kodowaniaprzy programowaniu aplikacji dla Symbian OS

Symbian narzuca na swoich programistów cały szereg konwencji oraz idiomów kodowa-nia, które dość znacząco wpływają na postać kodu źródłowego aplikacji tworzonych pod ten system. Jeśli chodzi o konwencje kodowania, to najbardziej w oczy rzucają się defini-cje typów podstawowych (TInt, TReal itd.); prefiksy w nazwach klas, atrybutów i składowych oraz postfiksy w nazwach funkcji. Co do nazw klas – wyróżniane są cztery podstawowe ich rodzaje i w tym kontekście stosuje się różne nazewnictwo. Klasy T reprezentują typu pod-stawowe oraz ich złożenia, klasy C alokują zasoby, klasy M reprezentują interfejsy zaś kla-sy R – uchwyty do zasobów. Najczęściej spotykany postfiks w nazwach funkcji to L – ozna-cza on tzw. funkcje leave'ujace. Mechanizm ucieczki (ang. leave) to symbianowa podróbka wyjątków. Z mechanizmem tym wiąże się idiom dwufazowej konstrukcji obiektów (metody NewL()/NewLC()/ConstructL()) oraz tzw. stos czyszczenia (ang. cleanup stack). Wszystkie te konstrukcje stosuje się o to, aby uniknąć gubienia zasobów systemowych (głównie pamię-ci). Co do symbianowych konwencji kodowania, to trzeba przyznać, że posiadają one swo-je plusy (np. narzucają spójność i porządek w kodach źródłowych). Idiomy kodowania nie-stety wypadają nieco gorzej – stanowią one zazwyczaj źródło nadmiarowej pracy i utrudnia-ją pielęgnację programów. Pozytywne jest to, że Symbian dostrzega powoli potrzebę stoso-wania alternatyw w odniesieniu do idiomatycznego sposobu kodowania i wspiera nowe roz-wiązania (np. wtyczki Open C/C++). W kolejnych odsłonach cyklu przedstawię bliżej te spo-śród symbianowych idiomów kodowania, które są niezbędne dla programistów gier. Opo-wiem także o wspomnianych wtyczkach (Open C/C++), które dla tychże programistów są szczególnie ciekawe.

09/200874



sane (czytaj: narysowane) w iBackupBitmap. W tym miejscu warto wrócić do przedsta-wionej wcześniej funkcji odrysowującej za-wartość kontrolki na ekranie (Listing 14). Jak widać na wspomnianym listingu, funk-cja ta odpowiada jedynie za skopiowanie za-wartości tylnego bufora na ekran. Operację tę realizujemy przy pomocy funkcji BitBlit(). W tym momencie warto przeanalizować ko-lejność operacji związanych z rysowaniem w naszej przykładowej aplikacji. Kluczową rolę w tym procesie odgrywa kod zawarty w me-todzie CGameSkeletonContainer::OnTick() (Listing 15).

Na początku tej metody wyliczamy różnicę czasu, na podstawie której uaktualniać będzie-my logikę gry – zakładamy, że odpowiadać bę-dzie za to funkcja Update(), która jest wywoły-wana w dalszej kolejności. Następnie mamy wy-wołanie funkcji Draw(). Warto w tym miejscu zauważyć, że wywołana funkcja ma sygnaturę:

void CGameSkeletonContainer::Draw( CGra-

phicsContext& aGc ) const;

Innymi słowy – nie jest to systemowa funkcja rysująca zawartość kontrolki na ekranie, tyl-ko zdefiniowana przez użytkownika metoda służąca do renderowania tylnego bufora. Ge-neralnie, przy programowaniu gier w Sym-bian OS dobrze jest definiować w klasach re-prezentujących wizualne elementy aplikacji metody rysujące, które przyjmują argument o typie CGraphicsContext, stanowiący klasę bazową dla wszystkich kontekstów graficz-nych. Jeśli skorzystamy z tego interfejsu, to wynikowy kod źródłowy będzie niezależny od zastosowanej metody renderowania.

Analizując zawartość klasy CGameSkele

tonContainer, warto zwrócić uwagę na skła-dową iFpsCounter. Składowa ta jest wskaźni-

kiem do obiektu klasy CFpsCounter. W ra-mach tej klasy zaimplementowano prosty mechanizm zliczania ilości narysowanych klatek na sekundę (ang. frames per second, FPS). Z punktu widzenia klientów tej klasy najistotniejsze jest wywoływanie na jej obiek-cie metody Update() po narysowaniu każdej, kolejnej klatki (co też czynimy w prezento-wanym przykładzie – Listing 15). Na Listin-gu 16 pokazana jest implementacja metody Draw(), odpowiedzialnej za uaktualnianie za-wartości tylnego bufora.

Pierwsza część metody Draw() odpowia-da za zamalowanie całego prostokąta ekra-nu czarnym kolorem. Część druga odpowia-da za rysowanie licznika FPS (wartość liczni-ka pobierana jest z obiektu reprezentowane-go przez składową iFpsCounter). Rysowanie za pomocą kontekstu graficznego (CGraphic-sContext) jest stosunkowo nieskomplikowa-ne i nie odbiega specjalnie od konwencji spo-tykanych na innych platformach. Ciekawość Czytelników może pobudzić za to zmienna lokalna zdefiniowana jako:

TBuf< KFpsMessageMaxLength > fpsMessage;

Zmienna ta jest przykładem tzw. deskrypto-ra – czyli obiektu reprezentującego napis w programach pisanych pod Symbian OS. W porównaniu do standardowego szablonu re-prezentującego napisy w języku C++ (std::string), deskryptory to dość skompliko-wany twór i na tym etapie pominiemy ich szczegółowy opis. Do tematu wrócimy w ko-lejnych odcinkach cyklu.

Podsumowując zawartość tego podpunk-tu warto zauważyć, że przedstawiony tu me-chanizm rysowania nie jest najbardziej efek-tywnym z możliwych, aczkolwiek reprezen-tuje złoty środek pomiędzy prostotą imple-

mentacji, a wydajnością. Bardziej zaawanso-wane techniki renderowania w Symbian OS planuję zaprezentować w jednym z kolejnych odcinków cyklu.

Interakcja z użytkownikiemInterakcja z użytkownikiem w systemie Symbian OS odbywa się przede wszystkim przy pomocy klawiatury. Jak już wcześniej wspominałem, w naszym szkielecie gry za obsługę tejże interakcji odpowiada klasa CGameSkeletonContainer. Implementacja tego mechanizmu umieszczona jest w funk-cji OfferKeyEventL (Listing 17).

Funkcja ta jest asynchronicznie wywo-ływana przez silnik aplikacji w przypad-ku występowania kolejnych zdarzeń klawia-tury. W naszym przypadku system obsłu-gi wspomnianych zdarzeń opiera się na uak-tualnianiu odpowiednich bitów w składowej iKeyState. W przypadku gdy dany klawisz jest wciśnięty, to odpowiedni bit w tej skła-dowej zostaje zapalony. W sytuacji odwrotnej – bit jest gaszony. Maski dla poszczególnych klawiszy zdefiniowane są w oddzielnym pli-ku nagłówkowym (KeyState.h), tak aby moż-na było je wykorzystywać wielu plikach źró-dłowych. Testowanie wciśnięcia danego kla-wisza można łatwo zrealizować przy pomo-cy operatorów bitowych. Dla przykładu, na-stępujący fragment kodu testuje czy wciśnię-ty został klawisz 7:

if ( iKeyState & KKey7 ) { /* ... */ }

Prezentowana aplikacja obsługuje klawisze kierunkowe oraz enter, a także klawisze ste-rujące (tzw. softkeys – duże klawisze znajdu-jące się zazwyczaj bezpośrednio pod wyświe-tlaczem telefonu komórkowego) oraz klawi-sze numeryczne. Warto w tym miejscu dodać, że w aplikacjach Symbian OS równoczesna ob-sługa wielu klawiszy jest domyślnie wyłączo-na. Aby włączyć tę obsługę, należy dodać w konstruktorze klasy CGameSkeletonAppUi (Li-sting 4) wywołanie:

CAknAppUi::SetKeyBlockMode( ENoKeyBlock );

Niestety, metoda ta dostępna jest tylko na platformie Series60.

Interakcja z systememDość specyficzną cechą dotyczącą progra-mowania gier na urządzenia mobilne, jest obsługa tzw. przerwań (bądź interrupcji). Wyobraźmy sobie, że podczas trwania akcji gry dzwoni telefon. W tej sytuacji warto by wstrzymać pętlę gry – przynajmniej do cza-su zakończenia rozmowy. Powodów ku temu jest wiele. Najważniejsze z nich to:

• automatyczna ochrona użytkownika przed skutkami nagłego wyrwania się z akcji gry –

W Sieci

• ftp://ftp.activestate.com/ActivePerl/Windows/5.6/ActivePerl-5.6.1.635-MSWin32-x86.msi – dystrybucja Perla potrzebna do tworzenia aplikacji dla Symbian OS

• http://java.sun.com/ – stąd można pobrać środowisko uruchomieniowe języka Java• http://www.forum.nokia.com/ – portal dla programistów piszących oprogramowania dla

telefonów firmy Nokia; można stąd pobrać bezpłatne narzędzia programistyczne wyko-rzystywane w niniejszym artykule

• http://www.newlc.com/ – portal programistów aplikacji dla Symbain OS; można tu zna-leźć cały szereg interesujących informacji – zarówno dla początkujących jak i zaawanso-wanych

Bibliografia

• Developing Software for Symbian OS: An Introduction to Creating Smartphone Applications in C++; Steve Babin; John Wiley & Sons, 2005. Ta pozycja dobra jest dla Czytelników, któ-rzy chcieliby stosunkowo szybko poznać podstawy programowania aplikacji dla Sym-bian OS

• Symbian OS Explained: Effective C++ Programming for Smartphones; Jo Stichbury; John Wiley & Sons, 2004. Ta pozycja dobra jest dla czytelników, którzy chcieli by poznać bar-dziej specjalistyczne tematy związane z programowaniem Symbian OS, np. szczegóły dotyczące implementacji i korzystania z aktywnych obiektów

09/200874



można w tym przypadku założyć, że mało kto będzie w stanie kontynuować grę w trak-cie rozmowy;

• oszczędzanie energii telefonu – wszak kręcąca się pętla gry tę cenną energię zu-żywa.

Na dodatek, Symbian jest systemem wielo-zadaniowym i użytkownik może w każdej chwili przeskoczyć do innej aplikacji – w tej sytuacji spauzowanie pętli gry byłoby rów-nież jak najbardziej na miejscu. Wszystkie omówione powyżej sytuacje można uogól-nić do jednego systemowego zdarzenia ja-kim jest utrata aktywności (ang. focus). Zda-rzenie to występuje w aplikacji wtedy, gdy inna aplikacja przejmuje kontrolę (mogliby-śmy użyć analogii ze świata Windows i po-wiedzieć: kiedy inne okienko wyskakuje na wierzch). Tak właśnie dzieje się, kiedy w tele-fonie symbianowym rozpoczyna się rozmo-wa (za obsługę połączenia głosowego odpo-wiada dedykowana aplikacja), tak samo jest gdy użytkownik wybierze z listy zadań in-ny program.

Zdarzenie utraty aktywności obsługuje-my z poziomu klasy kontrolki (CGameSke-letonContainer). W przypadku wystąpie-nia tego zdarzenia, silnik aplikacji asyn-chronicznie wywoła na kontrolce funkcję FocusChanged(). Przyjrzyjmy się, jak funkcja ta jest zaimplementowana w naszej kontrol-ce (Listing 18).

Implementacja jest prosta: na począt-ku sprawdzamy czy aplikacja utraciła bądź odzyskała kontrolę (służy do tego funk-cja IsFocused()). W pierwszym z tych dwóch przypadków wywołujemy pomocni-czą funkcję StopTickGenerator(), spraw-dziwszy uprzednio czy aby nasz timer wcześniej był uruchomiony (iTickGenera-tor->IsActive()). Implementacja funkcji StopTickGenerator() jest trywialna i spro-wadza się do wywołania funkcji Cancel() na obiekcie timera, co powoduje jego zatrzy-manie:

void CGameSkeletonContainer::StopTickGe-

nerator()

{ iTickGenerator->Cancel(); }

W przypadku odwrotnym (tj. kiedy apli-kacja odzyskuje kontrolę) wywołuje-my omówioną już wcześniej funkcję StartTickGenerator(), odpowiedzialną za uruchomienie timera (Listing 12). Dzięki temu prostemu zabiegowi, jesteśmy w sta-nie obsłużyć cały szereg wydarzeń zakłóca-jących naszą grę.

Oczywiście, interakcja z systemem nie kończy się na obsłudze zdarzenia utraty kontroli przez aplikację. Kolejne przydatne mechanizmy związane z tą tematyką (mię-dzy innymi obsługę zmiany orientacji ekra-

nu oraz wykrywanie braku aktywności użyt-kownika) będę omawiał w kolejnych artyku-łach z cyklu.

Testujemy!Nadszedł wreszcie upragniony moment przetestowania naszej przykładowej aplika-cji. Aby tego dokonać, należy wykonać nastę-pujący szereg czynności. Na początek aplika-cję trzeba zbudować. W tym celu posłużymy się środowiskiem Carbide.C++. Archiwum z aplikacją należy rozpakować, a następnie za-importować do Carbide korzystając z opcji File –> Import –> Symbian OS –> Symbian OS Bld.inf file. Wspomniany plik Bld.inf znaj-duje się w podkatalogu group projektu. Ro-lę tego, oraz pozostałych plików konfigura-cyjnych w projektach symbianowych omó-wię w kolejnym odcinku z serii moich ar-tykułów. Teraz skupimy się na uruchomie-niu aplikacji. Po zaimportowaniu projek-tu należy go zbudować (Project –> Build Pro-ject). Jako, że domyślnie ustawioną konfigu-racją w tym projekcie jest Emulator Debug, to efektem naszego ostatniego działania bę-dzie stworzenie binarnej wersji naszej aplika-cji działającej pod emulatorem. Przy pomocy komendy Run –> Run (Ctrl + F11) możemy obejrzeć efekt działania aplikacji GameSkele-ton (Rysunek 2).

Wspomniany efekt – czyli czarny ekran z narysowanym licznikiem FPS – nie jest mo-że porażający, aczkolwiek mając na uwadze przedstawioną wyżej analizę, wiemy, że stoi za nim dość obszerna mechanika.

W dalszej kolejności warto by zająć się uruchomieniem naszego przykładu na fi-zycznym urządzeniu. Niestety, ze wzglę-du na dość skomplikowany proces certyfi-kacji (Symbiana wymaga, by każda aplikacja działająca na telefonie została podpisana od-powiednim certyfikatem bezpieczeństwa), kwestię tę chwilowo pominiemy (wrócimy do niej w kolejnym artykule z cyklu).

Zadanie domowePrzedstawiony wyżej szkielet aplikacji sta-nowi solidny wstęp do bardziej zaawanso-wanych i ciekawszych tematów związanych z programowaniem gier. Czytelników, którym przypadł do gustu niniejszy tekst i planują kontynuować lekturę mojego cyklu w kolej-nym numerze SDJ, zachęcam do wykonania kilku ćwiczeń związanych z przedstawiony-mi tu materiałami. Po pierwsze, warto zapo-znać się bliżej z narzędziem Carbide, a szcze-gólnie z debuggerem. Jako pierwszą część za-dania domowego zalecam powstawianie w różnych miejscach naszej przykładowej apli-kacji punktów wstrzymania (ang. breakpo-ints), uruchomienie jej w trybie debug (F11) i przeprowadzenie praktycznych obserwacji mechaniki działania szkieletu (pętla głów-na, zdarzenia itd.). Jako drugie zadanie, pro-

ponuję zapoznać się z metodami dostępny-mi w ramach klasy CGraphicsContext. Ko-rzystając ze wspomnianych metod warto w ramach ćwiczenia zaimplementować me-chanizm wizualizacji zdarzeń klawiatury. W tym celu można narysować zbudowaną z prymitywów graficznych oraz tekstów imita-cję klawiatury telefonu i w zależności od sta-nu zmiennej iKeyState podświetlać (np. ry-sować innym kolorem) te jej fragmenty, dla których wystąpiło naciśnięcie klawisza. Me-chanizm ten można wykorzystać do przete-stowania systemu obsługi zdarzeń klawiatu-ry – warto zaimplementować go tak, aby we-ryfikował obsługę wciśnięć wielu klawiszy jednocześnie.

PodsumowanieW niniejszym artykule przedstawiłem szkie-let aplikacji dla Symbian OS, stanowiący so-lidny punkt wyjścia przy pisaniu gier. W ko-lejnych podpunktach pokazałem jak oprogra-mować pętlę gry, renderowanie zawartości ekranu, prosty system obsługi zdarzeń kla-wiatury oraz podstawowe mechanizmy inte-rakcji z systemem. W kolejnym artykule z cy-klu pokażę jak:

• zaimplementować prostą grę bazującą na przedstawionym szkielecie;

• zaprogramować operacje odczytu i zapi-su danych z/do plików;

• dołączyć do przedstawionego szkieletu obsługę dźwięku;

• wykorzystać idiomy programistyczne Symbian OS przy tworzeniu gier;

• uruchomić grę na telefonie.

Na koniec chciałbym wymienić osoby, któ-re dzięki swoim wnikliwym recenzjom przy-czyniły się do znacznej poprawy jakości ni-niejszego artykułu. Wspomniane osoby to: David de Rosier, Jacek Noe Cybularczyk oraz Mateusz Kula. Chciałbym również podzięko-wać mojej ukochanej żonie – Oli, za cierpli-wość, którą okazała mi w trakcie pisania te-go artykułu.

RAFAŁ KOCISZPracuje na stanowisku Dyrektora Techniczne-

go w firmie Gamelion, wchodzącej w skład Gru-

py BLStream. Rafał specjalizuje się w technolo-

giach związanych z produkcją oprogramowa-

nia na platformy mobilne, ze szczególnym na-

ciskiem na tworzenie gier. Grupa BLStream po-

wstała by efektywniej wykorzystywać potencjał

dwóch, szybko rozwijających się producentów

oprogramowania – BLStream i Gamelion. Firmy

wchodzące w skład grupy specjalizują się w wy-

twarzaniu oprogramowania dla klientów korpo-

racyjnych, w rozwiązaniach mobilnych oraz pro-

dukcji i testowaniu gier.


Programowanie gier dla Symbian OS – szkielet aplikacji

Wywiad

09/200876

Wywiad


SDJ: Panie Sebastianie, czy mógłby Pan po-krótce przedstawić naszym Czytelnikom charakterystykę rynku mobilnych gier? Sebastian Szczygieł: Aby zapewnić sukces na rynku gier mobilnych niezbędnym jest zagwa-rantowanie najwyższego pokrycia rynku urzą-dzeń mobilnych. Wielu operatorów sieci ko-mórkowych po prostu odmawia sprzedaży gry jeśli nie wspiera ona dostatecznej liczby tele-fonów z oferty przezeń prezentowanej. To jest największe wyzwanie dla firm oraz różnica w stosunku do innych rynków gier, jak rynek PC czy konsol, gdzie gry są tworzone zwykle na określoną platformę. Skalę tego wyzwania ilu-struje fakt, iż najwięksi wydawcy mobilnych gier, np. Gameloft czy Electronic Arts, publikują tytuły wspierające ponad 800 telefonów.

SDJ: Jaką rolę na tym rynku odgrywa Ga-melion?SS: Gamelion jest największym europejskim niezależnym twórcą gier na platformy mobil-ne. Posiada trzy studia w trzech polskich mia-stach (Szczecin, Bydgoszcz i Łódź) oraz studio we Lwowie na Ukrainie, zatrudniając łącznie po-nad 140 osób. Ponadto Gamelion posiada jed-ną z największych baz telefonów wśród firm te-go rodzaju. Składa się ona z ponad 1000 urzą-dzeń, nie tylko europejskich, ale także amery-kańskich, południowoamerykańskich i australij-skich. Klienci Gamelion wywodzą się z dziesiąt-ki najlepszych wydawców gier, włączając po-wszechnie znane firmy, jak Electronic Arts, Sony Pictures, Disney, Namco Bandai czy Nokia. War-to również w tym miejscu wspomnieć, że Ga-melion wchodzi w skład Grupy BLStream. Gru-pa ta powstała by efektywniej wykorzystywać potencjał dwóch, szybko rozwijających się pro-ducentów oprogramowania – BLStream i Ga-melion. Firmy wchodzące w skład grupy specja-lizują się w wytwarzaniu oprogramowania dla klientów korporacyjnych, w rozwiązaniach mo-bilnych oraz produkcji i testowaniu gier.

SDJ: Jak według Pana wygląda najpew-niejsza droga do sukcesu w biznesie gier na telefony komórkowe?SS: Gry odnoszące największy sukces na rynku, to konwersje dobrze znanych klasycznych tytu-łów, jak Tetris czy Pacman, gry oparte na licen-cjach filmowych (dla przykładu Gamelion stwo-rzył grę mobilną na bazie filmu Hancock, świe-żej produkcji w której wystąpił Will Smith), al-bo konwersje najnowszych tytułów z platform PC lub konsolowych. Patrząc na wyniki sprze-daży łatwo zauważyć, że większość użytkow-ników telefonów kupuje gry bazujące na tytu-łach, które już znają. Jest to częściowo związane

z metodą sprzedaży gier mobilnych. Najwięk-sza część przychodów pochodzi bezpośred-nio z portali operatorów komórkowych, zwy-kle łatwo dostępnych, możliwych do pobrania za pomocą jednokrotnego wciśnięcia klawisza, a także z telefonów dystrybuowanych przez da-nego operatora. Ze względu na małe rozmia-ry ekranu i ograniczoną przestrzeń na prezen-tację nowej produkcji, często tytuł gry zostaje tym czynnikiem, który decyduje o powodze-niu marketingowym gry. Gry tworzone wyłącz-nie na telefony komórkowe odnoszą sukces ko-mercyjny tylko wtedy, jeśli są najwyższej jakości i wydawca zainwestował w działania marketin-gowe na portalach operatorów. Dobrym przy-kładem są produkcje lidera rynku, firmy Game-loft, chociażby gra samochodowa Asphalt któ-ra jest najlepszą grą wyścigową na telefony ko-mórkowe.

SDJ: Jakich zagrożeń można się spodzie-wać w tej branży? SS: Chociaż rynek gier mobilnych ciągle się roz-wija, wyraźnie widać, iż branża ta stawia sta-le rosnące wymagania i coraz mniej nowych firm pojawia się na rynku. Wyróżnić można dwa główne powody takiego stanu rzeczy. Po pierwsze, koszty portingu na setki urządzeń stają się wyższe z każdym rokiem i tylko nie-liczne firmy w branży (włączając Gamelion) są w posiadaniu wszystkich niezbędnych po te-mu urządzeń. Po drugie, operatorzy zmniejsza-ją liczbę wydawców i dostawców treści z który-mi współpracują. Wydawca, który chce nadal współpracować bezpośrednio z operatorem komórkowym, musi zapewniać nie tylko sta-łą wysoką jakość swoich gier na wszystkie wy-magane modele telefonów, ale być zdolnym do spełnienia wszystkich wymagań operatora w jak najkrótszym czasie.

SDJ: Czy na rynku Polskim istnieje zapo-trzebowanie na mobilne gry? SS: Polska jest największym z nowych kra-jów Unii Europejskiej i ma potężny poten-cjał aby stać się ważnym rynkiem dla wydaw-ców gier mobilnych. Jednakże w tym wyścigu nadal znajdujemy się daleko w tyle za konku-rentami pokroju Wielkiej Brytanii, Niemiec czy Francji, które są wiodącymi krajami w Europie pod względem przychodów z produktów na telefony komórkowe. Główną przyczyną ta-kiego stanu rzeczy jest fakt, że na dzień dzi-siejszy Polacy nie są przyzwyczajeni do kupo-wania oprogramowania do swoich telefonów. Na tym polu operatorzy komórkowi, dostaw-cy treści i wydawcy w Polsce ciągle mają do odrobienia pracę domową pod tytułem: mak-

Wywiad z przedstawicielami firmy Gamelion

Sebastian SzczygiełSebastian Szczygieł pracuje w firmie Gamelion

(http://www.game-lion.com/) na stanowisku Kie-

rownika Produkcji. Jest odpowiedzialny za kom-

pleksowe zarządzanie pracami projektowymi, któ-

re są wykonywane w ramach czterech niezależnych

Studio, wchodzących w skład firmy. Sebastian jest

od siedmiu lat zawodowo związany z produkcją

oprogramowania (o charakterze zarówno bizneso-

wym jak i rozrywkowym) dla urządzeń mobilnych,

tworzonego na bazie takich technologii jak Sym-

bian, Windows Mobile, BREW oraz Java.

Kontakt: [email protected]

Rafał KociszRafał Kocisz pracuje w firmie Gamelion (http://

www.game-lion.com/) na stanowisku Dyrekto-

ra Technicznego. Jest odpowiedzialny za komplek-

sowe zarządzanie technicznym pionem firmy, na

co składa się kontrola rozwoju firmowej bazy ko-

du, równoważenie wewnętrznego portfolio wie-

dzy, wyznaczanie kierunków technologicznego

rozwoju, utrzymywanie wysokiej jakości technicz-

nej produktów oraz oraz zarządzanie personelem

technicznym w ramach czterech niezależnych Stu-

dio, wchodzących w skład firmy. Rafał jest od sied-

miu lat zawodowo związany z produkcją oprogra-

mowania (o charakterze zarówno biznesowym jak

i rozrywkowym) dla urządzeń mobilnych, tworzo-

nego na bazie takich technologii jak Symbian, Win-

dows Mobile, BREW oraz Java.

Kontakt: [email protected]

Wywiad

09/200876

Wywiad


symalizacja przychodów z treści dostarcza-nych na telefony komórkowe.

SDJ: Jak w Pańskiej opinii rynek mobil-nych gier będzie rozwijał się w najbliż-szych latach? SS: Wraz z następną generacją telefonów mo-bilnych w Europie i Stanach Zjednoczonych, jak również stałej poprawie zasięgu sieci 3G, bę-dziemy mogli obserwować więcej zaawanso-wanych technicznie gier w przyszłości. Nie tylko jakość gier będzie ulegać poprawie, ale gry bę-dą coraz intensywniej wykorzystywały połącze-nie telefonów z siecią komórkową do wymia-ny danych. Najprostszym sposobem, aby zoba-czyć, czego można się spodziewać w przyszło-ści, jest spojrzenie na obecny rozwój w Japonii. Nie tylko telefony są tam bardziej zaawansowa-ne, ale znacznie więcej gier korzysta aktywnie z połączenia sieciowego, zarówno do łączenia użytkownika z innymi graczami, jak też do po-bierania dodatkowych materiałów do gier.

SDJ: Panie Rafale, jakie trendy technolo-giczne dominują na rynku gier mobilnych? Rafał Kocisz: Rynek gier mobilnych zdomino-wały obecnie dwa trendy: programowanie natywne oraz programowanie multiplatfor-mowe w oparciu o technologię JME. W pierw-szym przypadku gry pisane są pod konkret-ne platformy mobilne (np. Symbian, Windows Mobile czy BREW) w języku C++, z wykorzy-staniem systemowych API, bądź na bazie mul-tiplatformowych bibliotek opakowujących te API. W drugim przypadku mamy do czynienia z programowaniem w Javie.

SDJ: Którą z opisanych wyżej technologii proponowałby Pan naszym Czytelnikom ja-ko punkt startowy? Czego warto się uczyć, aby móc zaistnieć na rynku gier mobilnych? RK: Obydwa podejścia są ciekawe i na pewno warto uczyć się ich obydwu. W przypadku pro-gramowania w Javie na pewno dużo łatwiej jest rozpocząć naukę, aczkolwiek mi osobiście bardziej interesujące wydają się technologie natywne. Pracując z takim technologiami ma-my o wiele większe pole do popisu. Wynika to z faktu, że korzystając z natywnych API uzyskuje-my bezpośredni dostęp do zasobów systemo-wych i możemy w pełni wykorzystać możliwo-ści urządzenia. Nie musimy się również zmagać z ograniczeniami, które ze względu na wymo-gi przenośności nakłada platforma JME. Przy wyborze kierunku nauki warto też pamiętać o równoważeniu portfolio wiedzy poprzez roz-wijanie swoich umiejętności z zakresu wiedzy ogólnej. Technologie ewoluują i zmieniają się z dnia na dzień, zaś wiedza ogólna deaktualizuje się znacznie wolniej. Programiście gier mobil-nych na pewno przyda się zaawansowana zna-jomość obiektowych języków programowania (C++/Java), umiejętność stosowania wzorców projektowych czy specjalizacja w obszarach

związanych z programowaniem gier (np. gra-fika 2D/3D, matematyka, fizyka, AI).

SDJ: Z jakimi technicznymi problemami potykają się programiści gier dedykowa-nych na platformy mobilne? Jak można ich uniknąć? RK: Problemów zdecydowanie nie brakuje. Jak już było wcześniej wspomniane, największym wyzwaniem firm egzystujących na rynku mo-bilnych gier jest zapewnienie przenośności na jak największą liczbę urządzeń. Wyzwanie to poza warstwą biznesową ma również swój wy-miar technologiczny. W przypadku produkcji gier natywnych stosuje się zazwyczaj tzw. multi-platformowe wrappery, tj. biblioteki, które ukry-wają pod ujednoliconym interfejsem szczegó-ły systemowe poszczególnych platform doce-lowych zapewniając w ten wygodną warstwę abstrakcji. Programiści korzystający z takiego narzędzia mogą skupić się na programowaniu warstwy gry, bez zawracania sobie głowy szcze-gółami systemowymi. Dodatkową zaletą takie-go rozwiązania jest przenośność – na bazie jed-nego kodu źródłowego można zbudować bi-narne wersje danej gry działające na odmien-nych platformach. Niestety, budowanie i utrzy-mywanie takich rozwiązań jest bardzo trudne i drogie. Biblioteki tego rodzaju są zazwyczaj roz-wiązaniami komercyjnymi (na przykład FUSE firmy Polarbit) bądź wewnętrznymi projektami firm produkujących oprogramowanie mobilne. Gamelion, dla przykładu, rozwija swoją własną warstwę abstrakcji o nazwie CLAW. Biblioteka ta została użyta przy produkcji takich tytułów jak Fifa 08 na platformy Symbian S60 oraz N-Gage. W przypadku rozwiązań opartych na platformie JME sytuacja nie wygląda wcale lepiej. Co praw-da JME zapewnia podstawowy poziom przeno-śności, jednakże przy projektach, które mają za-pewniać wsparcie dla kilkuset urządzeń, wystę-puje cała masa problemów wynikających z róż-nic sprzętowych oraz software’owych na po-ziomie implementacji maszyny wirtualnej. Kło-pot w tym, że różne implementacje JME w od-mienny sposób obsługują dźwięk czy przerwa-nia systemowe. Przerwania to kolejny poważ-ny problem, z którym muszą borykać się pro-gramiści gier mobilnych. W przypadku aplikacji desktopowych nie trzeba kłopotać się tym, że w trakcie pracy programu rozpocznie się połącze-nie głosowe bądź przyjdzie SMS. Przerwań te-go typu występuje na urządzeniach mobilnych bardzo dużo i co gorsza, na rożnych telefonach (często nawet w ramach jednej serii) trzeba je obsługiwać w odmienny sposób. Ze względu na opisane wyżej problemy, proces produkcji gier dzieli się zazwyczaj na dwie fazy: progra-mowanie – gdzie powstaje bazowa wersja apli-kacji obsługująca wąski zakres urządzeń refe-rencyjnych, oraz porting – gdzie przystosowuje się grę do pracy z resztą urządzeń. Podsumowu-jąc – trudno jest zaistnieć na rynku gier mobil-nych w pojedynkę. Szansę na wybicie się mają

dynamiczne, rozwojowe firmy, zdolne do zaofe-rowania pełnego pakietu usług – zarówno pro-gramistycznych jak i portingowych. Ważne jest również posiadanie w swoich szeregach ela-stycznych technologicznie i chętnych do nauki pracowników. Ten ostatni warunek jest szcze-gólnie istotny ze względu na szalony pęd tech-nologiczny we wspomnianym segmencie ryn-ku. W Gamelion cały czas jesteśmy otwarci na zatrudnianie zdolnych i otwartych ludzi, speł-niających powyższe warunki.

SDJ: Jak widzi Pan przyszłość branży gier mobilnych w kontekście technicznym? Czy gry mobilne mają szansę dogonić swoje desktopowe odpowiedniki? RK: To trudne pytanie. Jeszcze kilkanaście lat temu mało kto przewidywał tak dynamiczny rozwój technologii mobilnych z jakim mamy aktualnie do czynienia. Pytanie o rozwój gier mobilnych jest w zasadzie pytaniem o rozwój technologii komórkowych samych w sobie. W bliskiej perspektywie należy spodziewać się przypływu coraz to bardziej technologicznie zaawansowanych urządzeń mobilnych, a co za tym idzie coraz bardziej rozbudowanych gier, zarówno pod kątem ilości treści jak i ja-kości grafiki oraz dźwięku. Takie tytuły jak Fifa 08 czy Assassin’s Creed w wersji mobilnej mó-wią same za siebie. Pomimo stosunkowo dużej mocy, która drzemie pod maską urządzeń mo-bilnych, ich głównym ograniczeniem pozosta-je mały wyświetlacz i stosunkowo niewygod-ny kontroler. Dopóki te problemy nie będą roz-wiązane, trudno mówić o tożsamości gier de-sktopowych i mobilnych. Aczkolwiek, możli-we jest, że w nieco dalszej przyszłości telefony zaczną zastępować komputery osobiste i wte-dy owa bariera zostanie przełamana. Aktualnie można by raczej dyskutować o podobieństwie gier mobilnych do ich odpowiedników na kie-szonkowe konsole pokroju Sony PSP czy Nin-tendo DS. Myślę, że na dzień dzisiejszy jest to główne wyzwanie zarówno dla producentów mobilnych urządzeń jak i gier, aczkolwiek na jego osiągniecie zapewne przyjdzie nam jesz-cze trochę poczekać. Kolejnym dużym wyzwa-niem jest unifikacja narzędzi i bibliotek do bu-dowy oprogramowania na komórki. Sądzę, że najbliższe lata przyniosą nam jakieś pozy-tywne zmiany w tym zakresie. Dla przykładu, bardzo interesująco zapowiada się inicjaty-wa Khronos Group, w ramach której tworzo-ny jest zestaw standardów wspierających opi-sany wyżej cel. Dla przykładu, aktualnie trwają prace nad implementacją standardu OpenGL ES 2.0 w telefonach komórkowych. Standard ten oferując programowalny potok graficzny w postaci sprzętowo wspomaganych shade-rów przybliży nasze kieszonkowe cuda do ich PC’towych odpowiedników. Jedno jest pewne – przyszłość mobilnych gier, zarówno w kon-tekście technologicznym jak i biznesowym za-powiada się bardzo ekscytująco.

KLUB PROOferta skierowana dla firm

Jeżeli Twoja firma jest prenumeratorem Software Developer’s Journal za comiesięczną dopłatą 50 PLN +VAT możesz dodatkowo otrzymać reklamę.

Wystarczy tylko, aby profil Twojej firmy pokrywał się z naszym magazynem.

Wyślij do nas: logo firmy, dane kontaktowe i informację o firmie

Reklama przez 12 kolejnych numerów tylko za 600 PLN +VAT.

Jeżeli nie posiadasz jeszcze prenumeraty możesz ją zamówić w atrakcyjnej cenie.

Dla nowych prenumeratorów specjalna oferta – 690 PLN.

Skontaktuj się z nami:[email protected] tel. 22 427 36 91

[email protected] http://buyitpress.com

FRONTLINE STUDIOSFrontline Studios – amerykańsko-polski twórca gier konsolowych oraz PC – szuka utalentowanych ko-derów (bardzo dobra znajomość C/C++; Java, Del-phi, UML), doświadczonych grafików (2D, 3D) oraz zespołów developerskich. Oferujemy długotermi-nową pracę nad poważnymi projektami. Nie prze-gap tej okazji!

[email protected]

Future ProcessingFuture Processing to dynamiczna firma techno-logiczna działająca na globalnym rynku opro-gramowania. Jesteśmy zespołem wysokiej klasy specjalistów posiadających wiedzę i doświadcze-nie niezbędne do realizacji ambitnych projektów informatycznych. Jeśli programowanie to Twoja pasja dołącz do nas! (możliwość pracy zdalnej).

http://www.future-processing.pl

Intercon Sp. z o.o.Dostawca zaawansowanych rozwiązań informa-tycznych, nowoczesnych systemów sprzedażo-wych, systemów e-commerce oraz programów partnerskich. Oferujemy systemy wspierające za-rządzanie przedsiębiorstwem oraz wielokanałową sprzedaż, rozwiązania typu e-CRM, systemy typu work-flow, zaawansowane wnioski internetowe, roz-wiązania portalowe.http://www.intercon.pl

Kei.plKei.pl działa na rynku usług hostingowych od 2000 roku. Do naszych zadowolonych Klientów z du-mą możemy zaliczyć wiele przedsiębiorstw sekto-ra MSP, instytucji oraz osób prywatnych. W ofer-cie Kei.pl znajdują się pakiety hostingowe, a także usługi dla wymagających Użytkowników – platfor-my e-Biznes oraz serwery fizyczne.

http://www.kei.pl

Opera SoftwareOpera Software’s vision is to deliver the best In-ternet experience on any device. We are offering browser for PC/desktops and embedded pro-ducts that operates across devices, platforms and operating systems. Our browser can deliver a faster, more stable and flexible Internet expe-rience than its competitors.

http://www.opera.com

Architektury systemów ITTwórca frameworków JUVE i serwera aplikacji AVAX oferuje usługi, doradztwo, rozwiązania do tworzenia nowoczesnych, dużych systemów i roz-wiązań informatycznych/internetowych, integrują-ce architektury ery post-J2EE/.NET, wykorzystu-jące MDD/MDA dla dziedzin – bankowość, teleko-munikacja, handel, e-commerce, ERP/Workflow/CRM, rozwiązania internetowe, portalowe.www.mpsystem.com [email protected]

KLUB PRO

Osmosys Technologies Sp. z o.o.Dostarczamy kompletne rozwiązania dla rynku cy-frowej telewizji interaktywnej. Oferujemy oprogra-mowanie typu middleware, aplikacje JAVA, syste-my nadawcze oraz usługi „pod klucz”. Nowe obsza-ry działalności firmy to: odtwarzacze Blu-ray Disc, DLNA/Home Networking, akceleratory 3D, systemy ‘Video on Demand’, Push VoD oraz systemy rekla-my interaktywnej. http://www.osmosys.tv

SWD Software Sp. z o.oSystem operacyjny czasu rzeczywistego RTOS QNX. Oficjalny dystybutor w Polsce.Zakres działalności: lokalizacja produktów QNX, dostawy sprzętu i oprogramowania, doradztwo przedsprzedażowe, wsparcie techniczne, certyfi-kowane szkolenia, opracowania na zamówienie.

http://www.swdsoft.pl

StatConsultingStatConsulting to firma o znaczącej pozycji na ryn-ku usług analitycznych oraz Data Mining. Nasza oferta obejmuje m.in. modele scoringowe, rozwią-zania Fraud Detection oraz modelowanie ryzyka. Tworzymy także własne rozwiązania informatycz-ne na potrzeby projektów Data Mining, Data Quali-ty, zarządzania ryzykiem itd.

http://www.statconsulting.com.pl

TTS Company Sp. z o.o.Sprzedaż i dystrybucja oprogramowania komputero-wego. Import programów na zamówienie. Ponad 200 producentów w standardowej ofercie. Chcesz kupić oprogramowanie i nie możesz znaleźć polskiego do-stawcy? Skontaktuj się z nami – sprowadzimy nawet pojedyncze licencje.

http://www.OprogramowanieKomputerowe.pl

IT SOLUTIONSWdrożenia i szkolenia z zakresu:• SQL Server• SharePoint Services• MS Project / Server• Tworzenie aplikacji w technologii .NET

http://[email protected]

IT SOLUTIONS

Softline rozwiązania mobilneWiodący producent systemów mobilnych, do-stawca aplikacji użytkowych dla biznesu (Sym-bian OS, Windows Mobile, J2ME ) zaprasza do współpracy. Zostań naszym partnerem. Dołącz do zespołu.

http://www.softline.com.pl

Transition Technologies S.A.Firma w branży high-tech od 1991. Producent opro-gramowania dla przemysłu (ponad 350 referencji z instalacji na całym świecie). Usługi z zakresu: hur-townie danych i Business Intelligence, rozwiązania eBusiness, optymalizacja, integracja danych, aplika-cji oraz procesów biznesowych, portale korporacyj-ne, consulting i outsourcing usług IT, zaawansowa-na automatyka cyfrowa.http://www.tt.com.pl

EPRONaszą misją jest projektowanie najwyższej jako-ści dedykowanych systemów IT, które cechuje wysoka niezawodność, wydajność, ergonomicz-ność i intuicyjność w obsłudze oraz administracji.Głównym elementem oferty EPRO jest oprogra-mowanie sklepu internetowego oraz identyfika-cja wizualna.tel. 085 743 66 38http://www.epro.com.pl

v

Kontakt 1. Telefon+48 22 427 36 91+48 22 427 36 79+48 22 427 36 50

2. Fax+48 22 244 24 59

2. [email protected]

3. AdresBokserska 102-682 WarszawaPolska

Roczna prenumerata

tylko250

Software Developer’s Journal (poprzednio Software 2.0) jest miesięcznikiem głównie dla programistów, którzy li-czą, że dostarczymy im gotowe rozwiązania, oszczędza-jąc im czasu i pracy. Jesteśmy czytani przez tych, któ-rzy chcą być na bieżąco informowani o najnowszych osią-gnięciach w dziedzinie IT i nie chcą, żeby jakiekolwiek istotne wydarzenia umknęły ich uwadze. Aby zadowolić naszych czytelników, prezentujemy zarówno najnowsze rozwiązania, jaki starsze, sprawdzone technologie.

,-

v 1

Zamówienie prenumeraty

Imię i nazwisko ...............................................................................

Nazwa firmy.....................................................................................

Dokładny adres ..............................................................................

.........................................................................................................

Telefon ............................................................................................

E–mail .............................................................................................

ID kontrahenta ................................................................................

Numer NIP firmy .............................................................................

Fax (wraz z nr kierunkowym) .........................................................

Prosimy wypełniać czytelnie i przesyłać faksem na numer: 00 48 22 244 24 59lub listownie na adres: Software-Wydawnictwo Sp. z o. o.ul. Bokserska 102-682 WarszawaPolskaE-Mail: [email protected] też zamównienia telefoniczne:0048 22 427 36 910048 22 427 36 790048 22 427 36 50

Jeżeli chcesz zapłacić kartą kredytową, wejdź na stronę naszego sklepu internetowego www.buyitpress.com.

Prenumerujesz – zyskujeszl oszczędność pieniędzy l szybka dostawa l prezentyl bezpieczna płatność ność on–line

TytułIlość

nume-rów

Ilość zama-

wianych prenume-

rat

Od numeru pisma

lub mie-siąca

Cena

Software Develope-r’s Journal (1 płyta CD) – dawniej Software 2.0

12 180*/250PLN

□ automatyczne przedłużenie prenumeraty

* cena prenumeraty rocznej dla osób prywatnych

Zadzwoń+48 22 427 36 93

lubzamów

mailowo!

W następnym numerze Software Developer’s Journal 10/2008 (166)

W sprzedaży od 18 września

PROGRAMOWANIE JAVA

TESTOWANIE OPROGRAMOWANIA

PROGRAMOWANIE PHP

NOWE ARTYKUŁY W DZIAŁACH

Obliczenia numeryczne w programach kompute-rowych

Inteligentne partycjono-wanie zasobów w syste-mach czasu rzeczywistego

Zaawansowana obróbka grafiki w PHP

Porównanie opensource-owych platform blogowych opartych o PHP i bazy danych

Biblioteka miesiąca

XML

I wiele innych artykułów, których nie możesz przeoczyć!

Redakcja zastrzega sobie możliwość zmiany zawartości pisma.

SDJ_09_2008_PL_Bazy danych

Documents

Transcript of SDJ_09_2008_PL_Bazy danych