84

SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

Embed Size (px)

Citation preview

Page 1: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5
Page 2: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5
Page 3: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5
Page 4: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

4 10/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ŚCInąć wielu błędów w sztuce, zapewnia weryfikację na wczesnym sta-dium. Zachęca zespół projektowy do współpracy, dzielenia się wie-dzą, wprowadza dobre nawyki. Zapewnia produktowi stabilną pod-stawę a członkom zespołu sposób podnoszenia umiejętności.

38 Wstęp do IBM WebSphere MQ v6.0Paweł PietraszPaweł opisuje IBM WebSphere MQ jako rozwiązanie pozwalające na inte-grację różnych systemów informatycznych poprzez dostarczenie mechani-zmów pozwalających na łatwą wymianę komunikatów pomiędzy nimi.

42 Wyzwalacze w aplikacjach biznesowychArtur MościckiArtur omawia kwestie związane z wykorzystaniem wyzwalaczy (trig-gerów) w aplikacjach biznesowych. Oprócz typów wyzwalaczy, ta-bel INSERTED i DELETED prezentuje sposoby identyfikacji rodzaju triggera, sposoby wywołania rekurencyjnych i zagnieżdżonych wy-zwalaczy. Omawia również triki pozwalające na nieuruchamianie wyzwalacza dla określonych wierszy oraz niezwykle istotną z punk-tu widzenia aplikacji biznesowych kwestię wykorzystywania wy-zwalaczy na perspektywach.

BAZY DANYCH50 Lokal zamienię od zarazArtur OpalińskiArtur opisuje jakie problemy występują podczas przeróbki aplika-cji do funkcjonowania w nowej wersji systemu operacyjnego. Nawet jeśli same zmiany w aplikacji nie są skomplikowane, przejście przez stosowną część cyklu jej rozwoju zajmuje czas – przeważnie naj-cenniejszy zasób w projektach informatycznych. Niestety, nierzad-ko oprócz przerabiania kodu samej aplikacji typu enterprise, trze-ba uwzględnić jej integrację z nowym środowiskiem operacyjnym – nowe metody startowania, zmiany niektórych komend systemu operacyjnego i formatu ich wyników, ponowną instalację i konfigu-rację usług pomocniczych, itd

06 AKTUALNOŚCIRafał Kocisz

12 OPIS CD

BIBLIOTEKA MIESIĄCA14 OVal – walidacja spójności danych w aplikacjach korporacyjnychSebastian PiotrowskiWalidacja spójności danych to mało lubiany temat w społeczności programistycznej, zazwyczaj kojarzy się z monotonną, powtarzalną i mało kreatywną pracą. Z drugiej strony – w kontekście wymagań jakościowych w aplikacjach korporacyjnych, spójność danych to je-den z kluczowych aspektów, którego nie można pominąć. W niniej-szym artykule pokażemy jak usprawnić i uprzyjemnić sobie pracę związaną z walidacją spójności danych w aplikacjach biznesowych pisanych w języku Java, przy pomocy biblioteki OVal.

NARZĘDZIA PROGRAMISTYCZNE22 Joomla 1.0.do 1.5 – migracja krok po krokuStefan WajdaWprawdzie Joomla 1.5 jest następcą 1.0, ale różnice między obu wyda-niami są tak istotne, że Joomla 1.0.x nie można unowocześnić do Joom-la 1.5 przy pomocy łatki aktualizującej. Jedyną możliwą drogą jest migra-cja – założenie nowej witryny na Joomla 1.5 i przeniesienie danych z Jo-omla 1.0.x. Migracja przebiega w dużej mierze automatycznie. Ten arty-kuł przeprowadzi Cię krok po kroku przez cały proces migracji.

TESTOWANIE OPROGRAMOWANIA28 Była sobie inspekcja – aplikacja procesu inspekcjiArkadiusz MertaInspekcja kodu jest jednym z ważniejszych procesów jakościowych, które powinny być prowadzone w ramach projektu. Pomaga unik-

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

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

Nakład: 6 000 egz.

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.

10/2008 (166)

Page 5: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

4 10/2008 5www.sdjournal.org

SYSTEMY OPERACYJNE54 Inteligentne partycjonowanie zasobów w syste-mach czasu rzeczywistegoRoman KońszynRoman opisuje technologię inteligentnego partycjonowania zaso-bów – rozszerzenie systemu operacyjnego czasu rzeczywistego na poziomie jądra. Technologia ta pozwala na tworzenie bezpiecznych grup składających się z kilku aplikacji i wątków, pozwalając jednocze-śnie na maksymalnie efektywne wykorzystanie zasobów procesora. W niniejszym artykule przyjrzymy się dokładniej, co to jest inteligentne partycjonowanie zasobów i jakie zalety ma ono dla programistów i projektantów wbudowanych systemów czasu rzeczywistego.

PROGRAMOWANIE UML58 Język UML 2.x w dydaktyce akademickiej Stanisław Wrycza, Bartosz MarcinkowskiAutorzy zaprezentowali założenia metodologiczne dotychczas sto-sowanego programu nauczania języka UML. Artykuł zawiera uwa-runkowania oraz wyniki badania ankietowego oraz wnioski, ściśle związane z modyfikacjami, poczynionymi w dotychczas stosowa-nym programie nauczania języka UML. Treść niniejszego artykułu oparto na doświadczeniach uczelni wyższych w Gdańsku, zebranych w ramach wykładów i laboratoriów, wspieranych studiami przypad-ków, narzędziami CASE i treściami e-learningowymi.

WARSZTATY64 Własny „słup ogłoszeniowy” – konta użytkowni-ków oraz administracjaPiotr PlenikPiotr w poprzednim artykule utworzył serwis ogłoszeniowy, który spełnia swoją podstawową funkcję – umożliwia przeglądanie oraz samodzielne dodawanie ogłoszeń. Jednak nie wróży mu sprawnego działania bez kont użytkowników z możliwością dodawania ogło-szeń tylko po zalogowaniu, zarządzania ogłoszeniami oraz użytkow-nikami przez administratora oraz krótszych i czytelniejszych adre-sów URL. W tym artykule zajmiemy się wszystkimi w/w kwestiami, pozostawiając na koniec kwestie kończenia aplikacji oraz ostatecz-ną publikację na serwerze.

ZESTAWIENIE70 Zestawienie narzędzi do testowania oprogra-mowania

WYWIAD74 Wywiad z Kevinem Parkerem

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ą.

Page 6: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

Aktualności

6 10/2008

Aktualności

7www.sdjournal.org

Del.icio.us szybsze i bez kropekYahoo! wprowadził zmiany w del.icio.us – hostowanej usłudze do przechowywa-nia, opisywania i współdzielenia łącz do witryn internetowych (zwanych popular-nie odnośnikami). Najważniejszą zmianą według firmy są modyfikacje silnika strony, które mają sprawić, że witryna będzie dzia-łać szybciej pod rosnącym obciążeniem – aktualnie z del.icio.us korzysta około pięciu milionów użytkowników. Użyt-kownikom jednak nie to rzuci się w oczy, przynajmniej nie od razu – inna zmiana polega bowiem na... rezygnacji z kropek w nazwie i adresie serwisu. Yahoo! na ofi-cjalnym blogu usługi przyznaje, że kropki były dla większości użytkowników ogrom-nym utrudnieniem. Ludzie często mylili nazwę, wpisując różne kombinacje – np. de.licio.us, del.icio.us.com albo del.licio.us. Serwis był więc łakomym kąskiem dla scammerów. Teraz nazwa i adres brzmi po prostu delicious.com i jest prostsza do zapamiętania. Obecni użytkownicy ser-wisu oczywiście będą musieli się do niej przyzwyczaić, a także ponownie zalogo-wać. Inne, już nie tak zauważalne zmiany w serwisie to między innymi wydłużenie opisów zakładek z 255 do tysiąca znaków. Nowych funkcji i widoków doczekał się także interfejs serwisu.http://yahoo.com/

Gears ze wsparciem dla Gmail i Google CalendarFirma Google poinformowała o planach przedstawienia nowych odsłon GMail i Google Calendar, obsługujących wtycz-kę Gears, co ma pozwolić na pracę z tymi aplikacjami bez aktywnego połą-czenia z Internetem. Kolejną nowością w obydwu aplikacjach będzie obsługa stan-dardu SyncML do synchronizacji kontak-tów. Zapowiedź ta jest najprawdopodob-niej próbą popularyzacji produktów kor-poracji na rynku biznesowym, a szczegól-nie wśród niewielkich przedsiębiorstw. Mało który pracodawca zaryzykował-by brak dostępu do tak podstawowych usług jak poczta, czy kalendarz, wskutek awarii sieci. Co ciekawe, niektórzy konku-renci Google, np. Zimbra czy Zoho, oferu-ją już niektóre z wymienionych funkcjo-nalności, właśnie w oparciu o produkt giganta z Mountain View, zapewniając dostęp do swoich aplikacji w trybie offi-line. Wprowadzenie obsługi protoko-łu SyncML (Synchronization Markup Lan-guage) jest również warte podkreślenia. Dzięki niemu możliwe stanie się synchro-nizowanie informacji pomiędzy różnymi urządzeniami, głównie za sprawą uzna-nia go przez gigantów komórkowych, w tym Nokię, Sony, LG, IBM-a i Siemensa, implementując wsparcie dla niego, przy-najmniej w części produktów. W najbliż-szym czasie standard SyncML ma umożli-wiać też również eksport wiadomości, co czyni go tym bardziej interesującym roz-wiązaniem.http://www.readwriteweb.com/

Microsoft wesprze Fundację Apache

Podczas odbywającej się w USA konferen-cji Otwartego Oprogramowania, Funda-cja Apache poinformowała o pozyskaniu

nowego sponsora, jakim jest Microsoft. Gigant z Redmond zobowiązał się bowiem do wspierania fundacji kwotą 100 tys. dolarów rocznie, przy-łączając się tym samym do grona platynowych sponsorów, tuż obok Google i Yahoo!. Zdaniem Justina Erenkrantza, prezesa fundacji, nowa ini-cjatywa Microsoftu jest kolejnym krokiem w za-kresie zwiększenia interoperacyjności. Wierzy, że przedsięwzięcie to jest wyłącznie podyktowa-ne uzasadnioną chęcią polepszenia współpracy pomiędzy Apache, a rozwiązaniami spółki. Jako przykład wskazuje projekt Apache POI, będący zbiorem bibliotek Javy, pozwalający na zapisy-wanie i odczytywanie dokumentów w formacie MS Office. Twierdzi ponadto, że społeczność skupiona wokół serwera, na ogół pragmatycz-na i otwarta na udział zewnętrznych korpora-cji, nie powinna mieć nic przeciwko uczestnic-twu Microsoftu. Nie wiadomo na razie, czy opi-

sane wyżej posunięcie jest częścią szerszej inicja-tywy Microsoftu w celu zwiększenia kompaty-bilności Apache z platformą .NET. Pomimo za-pewnień Erenkrantz'a, informacja na temat ru-chu Microsoftu spotkała się w środowisku Open Source z dużym dystansem, nutką podejrzliwo-ści, oraz – z zadowoleniem. Najprawdopodob-niej, wiele osób, w dalszym ciągu będzie po-strzegało całą sytuację jako swego rodzaju pułap-kę, aczkolwiek – jak zapewnia jeden z przedsta-wicieli Fundacji – model zarządzania organiza-cją nie pozostawia miejsca na jakiekolwiek nad-użycia. Sam Ramji, szef działu do spraw wolne-go oprogramowania w Microsofcie, równocze-śnie zapewnił, że wspomniany krok w żaden sposób nie wiąże się z rezygnacją z rozwijania serwera IIS. Korporacja nie ukrywa przy tym, że korzyści płynące z nawiązanej współpracy, mogą przełożyć się na implementację nowych, cieka-wych funkcji w nadchodzącym IIS8, w tym na wsparcia dla języka PHP.http://www.techit.pl/

Zawirowania wokół Yahoo!

Lipiec i początek sierpnia bieżącego roku były dla koncernu Yahoo! gorącymi mie-siącami. Czas ten był pełen emocji szcze-

gólnie dla zarządu korporacji. Całe zamieszanie zaczęło się od tego, że inwestor Carl Icahn po od-mownej odpowiedzi Yahoo! na kolejną propozycję sfinalizowania transakcji z Microsoftem złożył w Securities and Exchange Commision (odpowied-nik Komisji Nadzoru Finansowego sprawujący w USA kontrolę nad obrotem giełdowym) infor-macje co do planowanych zmian w zarządzie fir-my. Analitycy zastanawiali się, czy Icahn sprzyja-jący Microsoftowi będzie chciał wymienić cały za-rząd Yahoo!, czy tylko jego część. Okazało się, że chodzi o wszystkie dziewięć osób. Jeśli Icahnowi udałoby się przeforsować tę zmianę podczas wal-nego zgromadzenia akcjonariuszy, to wtedy nawet bez większościowego pakietu akcji, ale ze swoimi ludźmi w zarządzie mógłby kontrolować całą fir-mę i najprawdopodobniej doprowadziłby do fu-zji Yahoo! z Microsoftem na warunkach propo-nowanych przez giganta z Redmond. Tymczasem pojawiły się informacje, że możliwy jest kompro-mis. Akcjonariusze zrzeszeni w grupę nazywanej Yahoo Plan B, na czele której stanął Ironfire Capi-tal zaproponowani, by uniknąć agresywnej i po-tencjalnie szkodliwej dla firmy batalii i zawczasu zawrzeć z Icahnem kompromis – zgodzić się na czterech proponowanym przez niego członków zarządu, a pięć miejsc obsadzić dotychczasowymi

dyrektorami. Równolegle pojawiła się kolejna cie-kawa informacja, że przybywa akcjonariuszy, któ-rzy proponują całkowite odparcie nacisków Icah-na. Wśród nich jest fundusz Legg Mason Capital Management, jeden z najbardziej znaczących ak-cjonariuszy Yahoo!. Posiada on około 6,5% akcji firmy – dwadzieścia razy więcej, niż grupa Plan B. W tym momencie wizja przejęcia całkowitej kon-troli nad internetowym koncernem przez Carla Icahna zaczęła tracić realne kształty. W końcu za-rządowi Yahoo! udało się zawrzeć kompromis z in-westorem. W ramach ugody Carl Icahn wycofał się z dążenia do wymiany całego zarządu. Ośmiu jego dotychczasowych członków ma zostać wybra-nych ponownie, w tym prezes Jerry Yang. Jedyną osobą, która zrezygnuje będzie Robert Kotick. W jego miejsce wejdzie nie kto inny, tylko sam Carl Icahn. Dodatkowo skład zarządu będzie rozsze-rzony o dwie osoby, które wskaże sprzyjający Mi-crosoftowi inwestor. Oznacza to, że firmą Yahoo! będzie niedługo zarządzać nie dziewięć, a jedena-ście osób. Nie wiadomo jeszcze, jaka będzie polity-ka nowego zarządu względem Microsoftu. Icahn nawet mając po swojej stronie dwóch innych członków raczej nie ma zbyt wiele do powiedze-nia. Być może jednak kompromis zakrojony jest na szerszą skalę i poczyniono już pewne ustalenia w tej kwestii. O szczegółach dowiemy się zapewne w niedalekiej przyszłości.http://betanews.com/

Page 7: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

Aktualności

6 10/2008

Aktualności

7www.sdjournal.org

Google będzie inwestował w rozwijające się firmyThe Wall Street Journal donosi, że Google stworzy fundusz venture capital i będzie inwestować w małe, rozwijające się przedsię-wzięcia. Działanie funduszy tego typu polega na wykupywaniu części udziałów w niewiel-kich firmach, co zwykle właścicielom daje spory zastrzyk gotówki niezbędny do rozwi-nięcia działalności, a funduszowi gwarantu-je zyski – oczywiście w przypadku sukcesu firmy, w którą wcześniej zainwestował. Grupa pracująca nad projektem założenia funduszu w Google kierowana jest przez Davida Drum-monda, jednego z wysoko postawionych dyrektorów firmy. Nad wyborem firm, w które fundusz będzie inwestować czuwać ma Wil-liam Maris, 33-letni inwestor giełdowy, który na koncie ma już szereg sukcesów inwestycyj-nych z bardzo dużymi zyskami. Informacja nie została jeszcze oficjalnie potwierdzona przez Google, nie wiadomo też jaka będzie struktu-ra funduszu. Jest to jednak ważny krok w ogól-niejszym kontekście – pokazuje nowe pode-ście dużych firm do start-upów, gdzie zamiast zwykłego przejmowania ich i wcielania we własne struktury, inwestuje się w nie i rozwija ich działalność pod dotychczasową marką.http://www.techcrunch.com/

Mojave – Vista wcale nie taka straszna?Mojave to nazwa kodowa nowej wersji sys-temu operacyjnego Windows, bezpośred-niego następcy Visty, który ma rozwiązywać wszystkie problemy i niedociągnięcia aktual-nego systemu – tak Microsoft mówił uczestni-kom doświadczenia. W rzeczywistości Mojave to bezprecedensowy eksperyment, w którym udział wzięło ponad 120 użytkowników Win-dowsa, Linuksa i Mac OS X należących do naj-bardziej zagorzałych sceptyków i krytykan-tów Visty. Zamiast nowego systemu pokazy-wano im właśnie... Windows Vista. W trakcie 10-minutowej demonstracji i po niej kamery nagrywały reakcje i komentarze uczestników. Eksperyment jest może nieco kontrowersyj-ny, ale efekty mówią same za siebie. Zdecy-dowana większość uczestników była bardzo zadowolona z tego, co zobaczyli. Niektórzy po prostu nie umieli wyjść z podziwu, jaki postęp dokonał się od czasów Visty. Innym wręcz brakowało słów. Wszystkie te reakcje można obejrzeć w klipach wideo, które poja-wiły się na witrynie projektu Mojave (http://www.mojaveexperiment.com/). Projekt był realizowany przez trzy dni w lipcu w San Fran-cisco. Komputer, który był wykorzystywa-ny do demonstracji to notebook HP Pavilion DV2000 z 2 GB pamięci RAM. Nie jest to wcale maszyna o bardzo wygórowanych możliwo-ściach sprzętowych. Wytłumaczeniem takie-go wyniku eksperymentu jest raczej fakt, że większość z tych, którzy najbardziej krytykują nowy system Microsoft po prostu go nie uży-wało, a spora część nigdy nawet nie widzia-ło w akcji. Microsoft zapowiada, że planuje wykorzystać wyniki eksperymentu w przy-szłych kampaniach marketingowych Visty. Ciekawe czy to doświadczenie zmieni wize-runek systemu?http://www.microsoft.com/poland

Bilion adresów stron zindek-sowanych przez Google

Stale rośnie ilość publikowanych w In-ternecie informacji. Jak wynika z pierwszego raportu przygotowanego

przez Google w 1998 roku, ilość witryn oscy-lowała wówczas w graniach 26 milionów. Na przestrzeni ostatnich ośmiu lat widywaliśmy już wiele dużych liczb. Bilion jest ogromną liczbą niepowtarzalnych adresów URL, a ty-le właśnie, jak twierdzi Google, zindeksowa-nych zostało w ich wyszukiwarce. Czy jed-nak tak duża ilość zindeksowanych doku-mentów faktycznie oznacza ich istnienie i ja-ka jest liczba stron na całym świecie? Google z uśmiechem odpowiada, że nie wie, gdyż nie ma czasu spojrzeć na nie wszystkie. Ściślej mówiąc, ich liczba jest tak naprawdę nieskoń-czona. Przykładowo miejsca zawierające tzw. automatycznie generowaną treść, jak kalen-darze internetowe, w których obecne są lin-ki do następnych dni, mogłyby być traktowa-ne za każdym razem jako nowa strona. Tak się jednak nie dzieje, ponieważ nie wynikają z te-go żadne korzyści. Przykład ten pokazuje tak-że, że nie ma jednej, ścisłej definicji określa-jącej co jest użyteczną witryną, a co nie. Acz-kolwiek korporacja jest dumna z posiadania największego indeksu spośród wszystkich wyszukiwarek, a jej celem jest zindeksowa-nie wszystkich danych świata. Dwaj inżynie-rowie Google, Jesse Alpert i Nissan Hajajlm, wspominają natomiast same początki, kie-

dy Sieć nie była jeszcze tak duża i nie każdy miał do niej swobodny dostęp, co też wyraź-nie przekładało się na ilość publikowanych in-formacji. Wówczas bowiem jedna stacja robo-cza była w stanie obliczyć wykres Page Rank na 26 milionów na przestrzeni kilku godzin, a następnie wykorzystaniu tak przygotowane-go zbioru przez określoną ilość czasu. Dzisiaj, wyszukiwarka giganta z Mountain View, na bieżąco indeksuje zasoby sieci, gromadząc i aktualizując informacje o stronach, przetwa-rzając grafy połączeń wiele razy w ciągu dnia. Zdaniem korporacji, wykres biliona adresów idealnie oddaje porównanie z mapą przedsta-wiającą identyczną ilość skrzyżowań. Zatem, aby przedstawić ogrom pracy wykonywanej przez klastry obliczeniowe, Google za przy-kład podaje, iż każdorazowe obliczenie wy-kresu jest równoważne z określeniem na ma-pie miasta skrzyżowania, które są obecne na każdej drodze w Stanach Zjednoczonych, z tą różnicą, że mapa ta jest blisko 50 tysięcy razy większa od rzeczywistej mapy USA z 50 tysią-cami razy większą liczbą dróg i skrzyżowań. Niewątpliwe wynik Google przyprawia zwy-kłego zjadacza chleba o lekki ból głowy. Pozo-staje mieć nadzieję, że firma nie spocznie na laurach, wkraczając na coraz to nowsze ryn-ki internetowego biznesu i świadcząc nowa-torskie usługi.http://www.google.com/

Google bliskie przejęcia Digg.com

W okolicach marca br. pojawiły się pierwsze informacje na temat przejęcia Digg.com przez Go-

ogle. Na początku dyrektor zarządzający ser-wisu agregującego newsy, Jay Adelson, sta-nowczo zaprzeczał tym informacjom. Jed-nakże kilka miesięcy później sprawa nabra-ła szybkiego tempa – podpisane zostało na-wet wstępne porozumienie określające wa-runki przejęcia i wydawało się, że sprawa jest bardzo bliska pozytywnego finału. Do-celowo, serwis Digg miał stać się częścią Go-ogle News. Google było gotowe za to zapłacić 200 milionów dolarów. Okazało się jednak, że gigant z Mountain View w ostatniej chwi-li zdecydował się odejść od rozmów, zabiera-jąc 200 mln dolarów. Do zerwania transak-cji doszło na etapie końcowego badania tech-nologii wykorzystywanych przez Digg'a oraz

kontroli jego raportów finansowych, pod-czas którego wydarzyło się coś, co spowodo-wało podjęcie tak drastycznych decyzji. Dwa niezależne źródła zbliżone do jednej ze spół-ek podają natomiast, iż faktycznym powo-dem zerwania rozmów były problemy tech-niczne, które wyszły na jaw w wyniku owej kontroli. Inne źródło ujawnia zaś, że przy-czyną była niezgodność charakterów po-szczególnych zespołów obu korporacji. Tym samym, w mocno niesprzyjającej atmosfe-rze, trudno najprawdopodobniej będzie zna-leźć Digg'owi kupca. W tym celu wynajął on bank inwestycyjny Allen & Co. Wiadomo jednak, że jest on jednak znany głównie z za-mykania powierzonych mu przedsiębiorstw. Czy to oznacza że również i Digg niebawem zniknie z Sieci?http://www.techcrunch.com/

Page 8: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

Aktualności

8 10/2008

Aktualności

9www.sdjournal.org

DNSSEC zabezpieczy domeny .orgICANN jednogłośnie zatwierdził propo-zycję Public Interest Registry, operato-ra domen .org, by zarządzana przez nich globalna domena najwyższego pozio-mu była pierwszą, która wdrożyła proto-kół zabezpieczeń DNSSEC. W ramach tego porozumienia PIR będzie również aktyw-nie pracować na rzecz stworzenia planu edukacyjnego i adopcyjnego DNSSEC w pozostałych strukturach Internetu. Ideą DNSSEC jest rozwiązanie fundamental-nych problemów zabezpieczeń liczącego już ćwierć wieku systemu DNS. Niedawno patchowane przez szereg producentów luki umożliwiające atak typu cache poiso-ning nie mają prawa bytu po implemen-tacji DNSSEC m.in. za sprawą wykorzy-stania podpisów cyfrowych. Umożliwia-ją one sprawdzenie, czy otrzymane infor-macje pochodzą z prawidłowego serwe-ra. DNSSEC jest rozwijany od 1997 roku. Wczesne wersje miały poważne proble-my architekturalne, które uniemożliwia-ły szerokie zastosowanie w strukturach Internetu. Wkrótce większość problemów została rozwiązana, ale pojawiły się kolej-ne – tym razem o charakterze formalno-prawnym. Również i na tym polu DNSSEC obronił się, ale najważniejsze części spe-cyfikacji zostały opublikowane dopiero w marcu bieżącego roku. Tak naprawdę domena .org nie jest pierwszą TLD, która wdroży DNSSEC. Wcześniej zrobiły to nie-które inne krajowe domeny najwyższego poziomu. Wdrożenie DNSSEC przez .org de facto oprócz korzyści rodzi także kolej-ny problem – ICANN (i tylko ICANN) uzyska w ten sposób dostęp do głównych kluczy szyfrujących, a nie wszyscy są zgodni co do tego, czy amerykańska instytucja może być godna zaufania w tak delikatnej kwe-stii, jaką jest światowy Internet.http://www.techit.pl/

ContentID – pies na pirackie materiałyFirma Anvato zaprezentowała technolo-gię o nazwie ContentID, która z założe-nia pomóc ma w walce z rozpowszech-nianiem nielegalnych materiałów wideo. W skład wspomnianej technologii wcho-dzą dwa moduły – Perceptual Signature, oraz Perceptual Search. Pierwszy z nich w opinii producenta jest narzędziem, które umożliwi symulację ludzkiej percepcji. Drugi natomiast to wyszukiwarka podo-bieństw pomiędzy oryginalnymi materia-łami, a tymi publikowanymi w popular-nych serwisach pokroju YouTube. Avanto dumnie informuje, że mechanizm w prze-ciągu zaledwie pięciu sekund potrafi prze-skanować około miliona minut, czyli prze-szło 16,6 tys. godzin ścieżek wideo, zacho-wując przy tym skuteczność na poziomie 99%. Jeśli technologia ContentID w prak-tyce okaże się tak skuteczna, jak zachwa-la ją obecnie producent, może oznaczać to znaczny przełom w ochronie praw autor-skich, ale jednocześnie koniec takich serwi-sów jak YouTube czy DailyMotion.http://mashable.com/

Microsoft skierował SQL Server 2008 do produkcji

Podczas konferencji Wednesday Micro-soft podał do wiadomości, że SQL Se-rver 2008 osiągnął status RTM (Release

to Manufacturing), co oznacza, że produkt skie-rowany został do produkcji. Wraz z nową wer-sją aplikacji wydano także jej edycję Web. Wer-sja Web pojawiła się stosunkowo późno, na żą-danie klientów, którym nie odpowiadała żadna z pozostałych edycji serwera. SQL Server 2008 znajdował się w fazie betatestów od ponad ro-ku i prace nad oprogramowaniem zostały wła-śnie ukończone. Microsoft wstępnie udostęp-nił produkt posiadaczom subskrypcji progra-mów MSDN oraz TechNet. Microsoft SQL Se-rver 2008 to nowy system do zarządzania i ana-lizy danych. SQL Server 2008 oferuje nowe, rozbudowane możliwości, takie jak efektywne zarządzanie w oparciu o reguły, audyty, obsłu-ga bardzo dużych hurtowni danych, dane geo-graficzne i przestrzenne oraz zaawansowane usługi raportowania i analizy. SQL Server 2008 jest bezpieczną, efektywną i inteligentną plat-formą niezbędną do obsługi aplikacji o znacze-niu krytycznym dla działalności firmy. Baza da-nych Microsoftu udostępniona została w sze-ściu edycjach, każda dopasowana do preferen-cji i wymagań odrębnego segmentu odbiorców: Compact, Express, Web, Standard, Enterrpri-se, oraz Workgroup. Nowa wersja – SQL Se-rver 2008 Web – została wydana po raz pierw-szy wraz z tą edycją produktu Microsoftu. Skie-rowana jest do przedsiębiorstw hostujących da-ne. Zawiera narzędzia niezbędne wsparciu ni-skobudżetowych, wielkoskalowych aplikacji Webowych oraz środowisk przechowywania danych. Podczas spotkania Wednesday Micro-soft przekonywał zaproszonych gości o korzy-

ściach płynących z wdrożenia nowego SQL Se-rvera podając 10 konkretnych przyczyn prze-mawiających za adaptacją nowej wersji w środo-wisku korporacyjnym. Mowa była między in-nymi o lepszej skalowalności nowej edycji oraz wzroście wydajności. Gigant z Redmond pod-kreślił także, iż opinie otrzymywane od użyt-kowników starszej edycji programu pozytyw-nie wpłynęły na rozwój programu. Pozwoliło to rozwinąć nową wersję aplikacji bazodanowej w przeciągu zaledwie trzech lat. W oficjalnej not-ce prasowej Microsoft pochwalił się także kil-koma wielkimi przedsiębiorstwami testujący-mi SQL Server 2008, m.in. były to Xerox, Sie-mens, Fidelity Investments czy Clear Channel Communications. Kampania reklamowa no-wej wersji produktu opatrzona została trzema słowami – inteligentny, zaufany i produktyw-ny. Microsoft mówi także, iż nowy SQL Server 2008 to nie tylko ulepszona baza danych, lecz także centralne repozytorium dla Microsofto-wego modelu strategii zarządzania danymi oraz inteligentnego biznesu w firmie. Użytkownicy starszych edycji SQL Server chcący wdrożyć najnowszą wersję oprogramowania powinni za-interesować się narzędziem Microsoft SQL Se-rver 2008 Upgrade Advisor. Jako ciekawostkę warto dodać, że radość w Microsofcie z okazji ukończenia nowego SQL Server była tak duża, że Ted Kummert, viceprezes korporacji, prze-farbował włosy na jasno pomarańczowo. Więcej informacji na temat SQL Server 2008 można znaleźć na oficjalnej stronie produktu znajdu-jącej się pod adresem http://www.microsoft.com/sqlserver/2008/en/us/default.aspx.http://www.idg.pl/http://www.techit.pl/

Inteligentne blacklisty przyszłością zabezpieczeń?

Naukowcy z instytutu SANS i SRI In-ternational stworzyli eksperymen-talną wersję algorytmu do inteligent-

nego, dynamicznego tworzenia blacklist. Algo-rytm przypomina ten używany przez Google podczas określania wskaźnika PageRank. Usłu-ga została nazwana Highly Predictable Blackli-sting. Jak działa nowatorski algorytm? W skrócie blacklista tworzona jest indywidualnie dla każ-dego członka obsługiwanej przez SANS Internet Storm Center sieci DShield na podstawie oce-ny prawdopodobieństwa, że atakujący odwiedzi właśnie tę konkretną witrynę. Ocena dokonywa-

na jest na podstawie analizy logów firewalla ty-sięcy innych biorących udział w projekcie. Ogól-na idea polega na przewidywaniu, jakie sieci i wi-tryny mogą być atakowane w przyszłości na pod-stawie danych o podobnych atakach w przeszło-ści. Usługa HPB została oficjalnie zademonstro-wana zostanie podczas konferencji Usenix Secu-rity Symphosium. Zainteresowani mogą zapi-sać się do sieci DShield i samodzielnie przetesto-wać działanie usługi wysyłając swoje logi w odpo-wiednim formacie, stosując się do instrukcji za-wartych na stronach projektu.http://www.techit.pl/

Page 9: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

Aktualności

8 10/2008

Aktualności

9www.sdjournal.org

Midori – przyszłość systemów operacyjnych?Serwis SDTimes podzielił się informacja-mi uzyskanymi z wewnętrznych doku-mentów Microsoftu na temat projektu Midori – systemu operacyjnego nowej generacji, który być może za kilkanaście lat zostanie następcą Windows. System ten oparty jest na mikrojądrze Singula-rity. Pracuje nad nim zespół podlegają-cy Craigowi Mundiemu, zajmującemu stanowisko Chief Research and Strate-gy Officer w firmie Microsoft. Midori to system o zupełnie innej architektu-rze, niż znany dzisiaj Windows. Jest to system rozproszony, bez wątpienia wpi-sujący się w realizowaną od niedaw-na przez Microsoft strategię Software + Services. Potencjalny następca Okie-nek będzie składał się z kodu zarządza-nego (opartego o .NET Framework) i nie-zarządzanego. Aplikacje pracować będą na wyższym poziomie, który będzie war-stwą abstrakcji dla fizycznych maszyn i procesorów. Ten model wewnętrznie przez Microsoft nazywany jest Asyn-chronous Promise Architecture. Z doku-mentacji Midori wynika także, że będzie on posiadał obiektowe API pracujące w podwyższonym modelu bezpieczeństwa. Duże zmiany pojawią się również w war-stwie graficznego interfejsu użytkow-nika – chociaż ze wspomnianej wynika, że Microsoft nie zdecydował się jeszcze na konkretne rozwiązania. Nie wiadomo również, czy Midori w ogóle kiedykol-wiek ujrzy światło dzienne. Na razie pro-jekt jest dopiero w fazie inkubacji, rodzi się w głowach inżynierów Microsoftu i pewnie dopiero w ciągu kilku najbliż-szych lat wyjaśni się, czy zostanie sko-mercjalizowany.http://www.techit.pl/

VIA otwiera dokumentację chipsetówVIA Technologies – największy tajwań-ski producent obwodów scalonych znany głównie z chipsetów do płyt głównych, procesorów i pamięci – opublikował nie-zwykle obszerne wytyczne dla progra-mistów tworzących otwarte sterowniki. Ponad ośmiuset stronicowa dokumenta-cja udostępniona na stronach VIA opisu-je technologię PadLock – generatora liczb losowych i zaawansowanego, sprzętowe-go silnika kryptograficznego obsługujące-go między innymi algorytmy RSA, wbudo-wanego w procesory VIA Eden, C3 oraz C7, technologię układów VX800/820 – czyli między innymi pierwszego zintegrowane-go procesora graficznego VIA wspierają-cego DirectX 9.0 oraz technologię chipse-tu mobilnego CX700. Krok ten jest częścią zapowiedzianej wcześniej strategii popra-wy wizerunku firmy w środowisku Open Source i nastąpił w ślad za zatrudnieniem Heralda Weltego – programisty pracują-cego nad jądrem Linuksa oraz założycie-la GPL-Violations.org – w roli łącznika ze społecznością.http://www.slashdot.org/

Google Knol – poważny konkurent Wikipedii?

Parę miesięcy temu pojawiła się informa-cja o rozpoczęciu zamkniętego, wyma-gającego zaproszenia, programu beta

nowej usługi Google, której zadaniem jest zbie-ranie naukowych i specjalistycznych publikacji, pisanych przez samych użytkowników. Usłu-ga nosi nazwę Google Knol i niedawno zosta-ła udostępniona publicznie. Ideą przyświecają-cą Google Knol jest przede wszystkim umożli-wienie użytkownikom pisania, a następnie do-dawania, poprawiania i komentowania treści na tematy, w których są specjalistami. Podsta-wową cechą odróżniającą go od Wikipedii jest przywiązywanie wielkiej uwagi do autorstwa. Autorzy są wymieniani z imienia i nazwiska z opcjonalnym zdjęciem obok. Metoda mode-rowanej współpracy (ang. moderated collabo-ration) pozwala natomiast każdemu czytelni-kowi dokonać dowolnej edycji, którą pierwot-ny autor tekstu może zaakceptować, odrzucić bądź zmodyfikować, zanim zmiany staną się widoczne publicznie, co ma pomóc w walce z wandalizmem. Od strony edytorskiej nie widać wielu zmian w porównaniu z edytorem Google Docs. Możliwe jest między innymi ustawienie formatowania oraz wstawienie grafik, cyta-tów, linków i przypisów. Serwis pozwala rów-nież na zdefiniowanie licencji na jakiej publi-kowany jest przez nas tekst, a także umieszcze-nie reklam AdSense, dzięki czemu kiedy autor zdecyduje się umieścić je przy swoim artykule, otrzyma część zysków pochodzących z reklam. Usługa daje też możliwość oceniania, czy zre-cenzowania przez zaproszonego specjalistę da-

nego hasła, przed jego publikacją. Witryna jest dostępna pod adresem http://knol.google.com/. Jako ciekawostkę związaną z nowym serwisem warto wspomnieć o pewnym drobnym proble-mie firmy Google. Otóż wszystko byłoby w po-rządku, gdyby nie fakt, iż domena Knol.com, pod którą miałaby funkcjonować usługa jest już zajęta. Obecnie usługa funkcjonuje pod ad-resem knol.google.com, natomiast domena, któ-rą Google jest zainteresowane należy do holen-derskiej firmy, specjalizującej się w dystrybu-cji odkurzaczy. Wspomniany adres został za-rejestrowany przez Hilco Knola, właściciela przedsiębiorstwa w 2002 roku za kilka EUR. Jeśli transakcja zostanie sfinalizowana, ozna-czać to może dla niego interes życia. Przedsta-wiciele korporacji z Mountain View skontakto-wali się już z Knolem w sprawie zakupu wspo-mnianej domeny. Koncern zaoferował w za-mian okrągłą sześciocyfrową sumę. Holender-ski przedsiębiorca odrzucił jednak propozycję wyszukiwarkowego giganta, tłumacząc, iż po-datek dochodowy w Holandii nie dał by mu zy-sku jakiego oczekuje. Dodał także, że gotów jest odstąpić domenę za kwotę 1 miliona Euro, któ-ra pozwoli mu opłacić zmianę całego wizerun-ku jego firmy. Google uważa, że adres postaci knol.com byłby dużo atrakcyjniejszy dla usługi, niż dotychczasowa subdomena. Teraz pytanie, czy koncern zdecyduje się za tą atrakcyjność w postaci domeny położonej najwyżej w hierar-chii gTLD zapłacić tak dużą sumę?http://www.google.com/http://domainnews.com/

ICANN otwiera rejestrację domen .me

Organizacja ICANN sprawująca kon-trolę nad światowym systemem do-men otworzyła ogólnodostępną,

światową rejestrację domen zakończonych rozszerzeniem .me. Rozszerzenie to zostało przyznane Czarnogórze jako krajowa domena najwyższego poziomu, po uzyskaniu przez nią niepodległości. Z tego faktu ucieszą się nie tyl-ko osoby chcące podkreślić swoją tożsamość w Internecie, ale przede wszystkim firmy, któ-re od momentu uruchomienia prerejestracji w maju wydały majątek na rezerwację takich domen, jak buy.me, love.me, date.me czy con-tact.me. Później te i inne domeny robiły furo-rę na serwisach aukcyjnych. Od teraz pod no-wymi domenami będą uruchamiane serwisy,

a kolejne adresy będą mogły być rejestrowa-ne bez ograniczeń. Według rejestru ICANN, do tej pory przyjęto ponad 30 tysięcy wnio-sków rejestracyjnych dla domen .me. ICANN w 2008 roku ma sporo pracy. Najpierw orga-nizacja zmniejszyła ograniczenia w rejestracji domen .pro, dotąd zastrzeżonych dla specjali-stów wykonujących wolne zawody. Później za-decydowano o totalnym uwolnieniu domen najwyższego poziomu tak, by wkrótce możli-we było rejestrowanie dowolnych rozszerzeń – oczywiście za spore pieniądze. Dla chiń-skich użytkowników Internetu opracowano także możliwość używania chińskich znaków zamiast rozszerzenia .cn.http://betanews.com/

Page 10: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

Aktualności

10 10/2008

Aktualności

11www.sdjournal.org

MPAA planuje serwis z legalnymi treściamiOrganizacja MPAA (Motion Picture Asso-ciation of America) próbowała dotąd wielu sposobów walki z piractwem – jej ostatni pomysł ma jednak szansę okazać się pierwszym posunięciem nio-sącym faktyczne korzyści dla użytkowni-ków. Według różnych źródeł, MPAA pra-cuje nad witryną informującą o legal-nych możliwościach nabywania w sieci filmów bez konieczności uciekania się do rozwiązań nielegalnych. Witryna, która nie ma jeszcze nazwy, pozwoli wyszu-kać interesujące pozycje, po czym skie-ruje użytkowników do pobliskich (dla nas raczej dość odległych, bo pewnie wyłącz-nie za oceanem) miejsc, gdzie można nabyć bilety lub wypożyczyć bądź kupić płyty DVD, a także do serwisów interne-towych pozwalających legalnie pobrać cyfrowe treści. Jak informuje serwis Ars Technica powołując się na anonimowe źródła gazety Variety, za inicjatywą stoją wszystkie główne wytwórnie filmowe oraz większość internetowych przedsię-wzięć sprzedających filmy online. Sam serwis będzie przedsięwzięciem nieko-mercyjnym. Pomysł na serwis powstał w wyniku badań, które wskazały, że wielu przeciętnych użytkowników ma proble-my z odróżnieniem w sieci... treści legal-nych oraz nielegalnych. Zaawansowa-nym internautom odróżnienie iTunes od serwisów torrentowych z pewnością nie przysparza najmniejszych trudności, widać jednak że nie dla wszystkich są to rzeczy oczywiste – sporo ludzi wpisuje po prostu w Google poszukiwane tytuły i bez większego zastanowienia udaje się w zaproponowane, nie zawsze legal-ne miejsca. Póki co, pracownicy MPAA wstrzymują się od komentarzy na temat tego pomysłu.http://arstechnica.com/

DirectX 11 zapowiedzianyPodczas tegorocznego GameFest (http://www.xnagamefest.com/) firma Micro-soft oficjalnie zapowiedziała kolejną, jede-nastą już wersję bibliotek DirectX. Naj-nowsza edycja, podobnie jak poprzednia, przeznaczona będzie tylko pod Windows Vista. Kiedy wypuszczono DX10, użytkow-nicy zmuszeni zostali do zmiany kart gra-ficznych na obsługujące nowy standard. Jedenastka na szczęście takiej rewolucji nie wprowadza – jest kompatybilna z poprzed-nią wersją bibliotek, a więc także z obsłu-gującym je sprzętem. DX11 niesie ze sobą nowe technologie, które pozwolą na użycie kart GPU jako równoległego procesora o ogólniejszym zastosowaniu (nie tylko odpowiedzialnego za grafikę), czy popra-wią rozłożenie mocy na wątkach w maszy-nach wielordzeniowych. Dojdzie również sprzętowe wsparcie dla teselacji, co umoż-liwi twórcom gier pokazanie w swoich tytu-łach ładniejszych, mniej kanciastych brył przy oglądaniu modeli z bliska. http://www.gamikaze.pl/

Oprogramowanie Open Source zagrożeniem dla firm?

Firma Fortify Software, specjalizująca się w przeprowadzaniu audytu oprogramowa-nia, przetestowała 11 aplikacji Open So-

urce, napisanych w Javie, przeznaczonych do pra-cy w firmie. Jak się okazało, każda z nich zawie-rała luki w bezpieczeństwie. Według Jacoba We-sta, szefa grupy odpowiedzialnej za przygotowa-nie raportu, fakt występowania licznych usterek bezpieczeństwa jest niepokojący. Korporacje po-winny traktować oprogramowania Open Sour-ce jako poważne zagrożenie. Howard Schmidt, były doradca do spraw bezpieczeństwa informa-tycznego Białego Domu, twierdzi natomiast, że otwarte oprogramowanie stanowi piętę achilleso-wą współczesnych przedsiębiorstw. Jego wdroże-nie powinno być wcześniej dokładnie przemyśla-ne, rozważając wszystkie jego zalety i wady, gdyż nie posiada ono narzędzi do szybkiego elimino-wania wykrywanych błędów. Twórca jądra Linuk-sa, Linus Torvalds, w odpowiedzi na opublikowa-ny raport, stwierdził, że osoby zajmujące się bez-

pieczeństwem sieciowym, postrzegają na ogół ota-czający ich świat jedynie w barwach białych bądź czarnych, jednocześnie krytykując taką postawę. Niezwykle mocno skrytykował też programistów systemu OpenBSD, który z założenia ma być naj-bezpieczniejszą dystrybucją Uniksa. Stwierdził on bowiem, iż będąc skoncentrowanym tak moc-no na łataniu usterek bezpieczeństwa, nie zaj-mują się niczym innym. Według Fortify Softwa-re, postawa Torvaldsa, w kwestiach bezpieczeń-stwa jest wspólna w społeczności Open Source, która wyraźnie nie ignoruje tych kwestii, nie sta-wia ich jednak za priorytet. Przedstawiony w ra-porcie obraz wydaje się tym bardziej ważny, bio-rąc pod uwagę fakt, że wiele firm już teraz patrzy w stronę wdrożenia bezpłatnych rozwiązań. Rów-nież najnowsze badania Gartnera wskazują, że do 2011 roku aż 80% przedsiębiorstw, wykorzysty-wane oprogramowanie, przynajmniej częściowo, będzie opierać się o otwarte komponenty.http://www.darkreading.com/

Polskie domeny .eu w czołówce

Polacy zarejestrowali do tej pory po-nad 150 tys. domen Unii Europejskiej (.EU). Daje nam to 5 miejsce w Europie

i potwierdza rosnące zainteresowanie domena-mi w naszym kraju. Przed nami są tylko tacy gi-ganci rynku internetowego jak: Niemcy (876 tys.), Holendrzy (387 tys.), Brytyjczycy (361 tys.) i Francuzi (224 tys.). W Polsce szczegól-nie silny wzrost rejestracji .eu nastąpił w ostat-nim półroczu. W grudniu zeszłego roku było 100 tysięcy polskich domen .eu. W ciągu pół

roku nastąpił więc 50-procentowy wzrost. Jak zaznacza Marcin Majerek z serwisu Domeny.pl dodając do tego 1,1 mln polskich domen naro-dowych i ponad 300 tysięcy innych adresów zagranicznych rejestrowanych przez Polaków, czyni to z naszego kraju silnego gracza na ryn-ku internetowym. Domeny .eu rejestrowane są od grudnia 2005 roku. To dziewiąty pod wzglę-dem ilości adres na świecie. W sumie jest ich – na dzień dzisiejszy – około 2,85 miliona.http://domeny.pl/

Microsoft otworzy kolejne laboratorium Open Source

Microsoft zapowiedział otwarcie kolej-nego laboratorium badawczego do spraw interoperacyjności i produk-

tów Open Source, tym razem – na Filipinach. In-auguracja nowego oddziału korporacji odbyła się we wrześniu br., w którym różnego rodzaju entu-zjaści i pasjonaci otwartego oprogramowania, bę-dą mogli zajmować się wspieraniem działań na rzecz interoperacyjności w produktach korpora-cji, w tym implementacji formatu Open Docu-ment Format (ODF). Zdaniem dyrektora gene-ralnego NNC, stanowić ono będzie doskonałe miejsce do wykazania się kreatywnością, z kolei sam Microsoft uważa, że prace te torują drogę dla

zachowania jeszcze lepszej współpracy technolo-gii korporacji z innymi rozwiązaniami. Oddział ten nie jest pierwszym w historii Microsoftu; fir-ma posiada wiele podobnych placówek zlokalizo-wanych w różnych częściach globu.http://www.gmanews.tv/

Page 11: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

Aktualności

10 10/2008

Aktualności

11www.sdjournal.org

Aurora – nowy kształt webowego interfejsu użytkownika?Firma Adaptive Path, przy współpracy z Mozilla Labs, zaprezentowała na począt-ku sierpnia br. w San Francisco, projekt kolejnej koncepcji interfejsu webowego o nazwie Aurora. Jego głównym autorem jest Jesse James Garrett, znany między innymi z popularnej ostatnimi czasy techniki two-rzenia aplikacji WWW – AJAX. Ideą przy-świecającą Aurorze jest przywrócenie kilku podstawowych cech współcześnie rzadko spotykanych, w tym świadomości kontek-stu, naturalnej interakcji, ciągłości, czy też możliwości pracy z aplikacjami przez wielu użytkowników jednocześnie, dzięki czemu możliwe stałoby się zastosowanie wspólne-go interfejsu użytkownika bez względu na wykorzystywany typ urządzenia czy para-metry jego ekranu, a także łatwość przy-stosowania przeglądarki do użytkownika, a zarazem do trudności w zarządzaniu inte-rakcją z siecią Web. Jeśli chodzi o zarządza-nie, różnego rodzaju dane takie jak ludzie, miejsca i rzeczy są przedstawiane w posta-ci obiektów w trójwymiarowej przestrzeni. Ich położenie jest ściśle powiązane z działa-niami ze strony użytkownika. W przypadku, gdy korzysta on z danego obiektu, zbliża się on do niego, w przeciwnym wypadku, powoduje to jego oddalanie. Zmiana poło-żenia odbywa się natomiast za pomocą specjalnego paska przypominającego w działaniu dock z systemu Mac OS X, umiej-scowionego w dolnej części ekranu. Projekt jest udostępniony na licencji Creative Com-mons Attribution-Noncommercial-Share Alike w wersji trzeciej. Dostępny jest rów-nież krótki film (http://www.vimeo.com/1450211?pg=embed&sec=1450211) przed-stawiający praktyczne wykorzystanie inter-fejsu. Jak ponadto zapewnia Adaptive Path, jego nowy produkt jest zaledwie puntem wyjścia dla otwartej dyskusji na temat przy-szłości interfejsów użytkownika.http://www.adaptivepath.com/

Google znów zyskuje na rynku wyszukiwarek w USAWedług najnowszych statystyk opublikowa-nych przez Hitwise, na rynku wyszukiwarek w Stanach Zjednoczonych Google jeszcze bardziej umacnia swoją niekwestionowaną pozycję lidera. Google w czerwcu br. uzyskał wynik blisko 70%, o jeden procent więcej, niż w maju. W tym samym czasie wyszukiwarki dwóch największych rywali, Yahoo! i Microso-ftu, traciły udział w rynku. Yahoo! tradycyjnie uplasowało się na drugim miejscu z wynikiem około 19%, a Live Search jak zwykle musiał zadowolić się jednocyfrowym wynikiem na poziomie nieco ponad 5%. Na czwartym, ostatnim monitorowanym miejscu w statysty-kach Hitwise za czerwiec znalazł się Ask.com z wynikiem niewiele ponad 4%. Wyniki zostały opracowane na podstawie danych zebranych od 10 milionów użytkowników w USA. Warto zauważyć, że Google utrzymuje wynik powy-żej 60% od września 2006 roku i nic nie wska-zuje na to, by miało się to szybko zmienić.http://www.cnet.com/

Google pozwane za kampa-nię reklamową w AdWords

Kalifornijski prawnik Hal Levitte skie-rował do sądu pozew przeciwko fir-mie Google, zarzucając jej oszustwo

i naruszenie etyki biznesowej. Sprawa dotyczy wykupionej przez niego w systemie AdWords reklamy usług jego poradni prawniczej Levit-te International. Pozew trafił do sądu 11 lipca br., prawnik zarzuca w nim firmie Google, iż został oszukany poprzez wyświetlanie promo-cyjnych tekstów jego poradni prawniczej na ni-skiej jakości stronach parkingowych, czyli stwo-rzonych głównie z myślą o gromadzeniu i prze-chowywaniu masowo linków. Twierdzi on, iż nie został należycie poinformowany o fakcie, że wykupiona przez niego kampania reklamo-wa w AdWords będzie wyświetlana na tego ty-pu stronach. Według ekspertów zatrudnionych przez Levitte’a zarówno reklamy wyświetlane na łamach serwisów parkingowych, oraz stro-nach błędów, na których promocyjne teksty również były wyświetlane, nie działają popraw-nie. Proceder pierwszy dał 202 528 odsłon, 668 kliknięć i ani jednej konwersji. Drugi na-

tomiast to 1009 wyświetleń reklamy, 25 klik-nięć i podobnie jak w poprzednim przypadku żadnej konwersji. Łącznie za tą bezwartościową kampanię promującą Levitte zapłacił około 140 USD, czyli około 15% całego budżetu, przezna-czonego na reklamę swoich usług. Aktualnie prawnicy Levitte’a starają się nadać sprawie sta-tus pozwu zbiorowego. Są oni przekonani, iż sprawa nie dotyczy tylko ich klienta, ale rów-nież wielu innych oszukanych w ten sposób. Jeśli sędzia prowadzący sprawę nada jej status pozwu zbiorowego i znajdzie się odpowiednia liczba oszukanych klientów może to oznaczać dla giganta z Mountain View ogromne proble-my i konieczność wypłaty wysokich kar. http://informationweek.com/

Cuil konkurencją dla Google?

Pod koniec lipca br. ruszyła nowa wy-szukiwarka internetowa Cuil, któ-ra chwali się indeksem zawierają-

cym ponad 120 mld unikalnych stron. Bio-rąc pod uwagę fakt, że indeks Google jest nie-mal dziesięciokrotnie większy, warto przyj-rzeć się, czym Cuil zamierza przekonać do siebie użytkowników – jest to bowiem pro-jekt ambitny, spekulacje na jego temat cią-gnęły się już od kilku lat, a szczegóły utrzy-mywane były dotąd w wyjątkowo dużej ta-jemnicy. Co czyni Cuil unikalnym i wartym uwagi przedsięwzięciem? Po pierwsze, jest to dziecko byłych pracowników Google, którzy nie odeszliby raczej z firmy z naiwnym po-stanowieniem zbudowania w garażu auten-tycznej konkurencji bez oryginalnego pomy-słu. Otóż Cuil opracował rzekomo wielokrot-nie tańszą w utrzymaniu technologię indek-sowania zasobów w sieci i obsługi zapytań użytkowników, która dodatkowo zapewniać ma bardziej dokładne wyniki wyszukiwania. Tego można się było spodziewać, pytanie czy idą za tym większe konkrety... Cuil twierdzi, że nie kataloguje stron wyłącznie na podsta-wie wyrwanych z kontekstu słów kluczowo występujących w treści, ale także w oparciu o relacje między nimi. Jest to podejście seman-tyczne, nie używa ono jednak technik sztucz-

nej inteligencji do zgadywania znaczeń in-deksowanych zdań – jak to czynią rozwiąza-nia konkurencyjne, a dużo prostszego i przez to skuteczniejszego algorytmu pozwalające-go po prostu precyzyjniej kategoryzować wi-tryny. Dodatkowo, Cuil opracował dość ory-ginalny interfejs użytkownika prezentujący wyniki wyszukiwania w trzech kolumnach zawierających znacznie szerszy opis witryn, a także zdjęcia. W prawym górnym rogu znaj-duje się kontrolka pozwalająca zawęzić wyni-ki wyszukiwania do konkretnych kategorii. Firma twierdzi, że prywatność użytkowni-ków jest jej oczkiem w głowie – adresy IP łą-czących się z Cuil komputerów nie są nigdzie zapisywane. Cuil nie wykorzystuje również ciastek do kojarzenia konkretnych maszyn z zapytaniami. Być może ten właśnie aspekt funkcjonowania Cuil okaże się jego najwięk-szym atutem, tak jak kiedyś atutem Google nad Altavistą okazało się odejście od znie-nawidzonych przez użytkowników praktyk pozycjonowania wyników oraz zanieczysz-czania wyników wyszukiwania spamem. W chwili obecnej dość trudno dobić się do ser-wisu Cuil ze względu na częste przeciążenia serwerów związane z wyjątkowo dużym za-interesowaniem usługą.http://www.techcrunch.com/

Page 12: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

12 13

Opis CD

TurboDemo 6.5Wciąż myślisz jak zrobić prezentację inną niż wszystkie? Nie trać czasu TurboDemo 6.5 to program stworzony z myślą o Tobie!

TurboDemo to skuteczny i prosty w użyciu program, który prze-chwytuje ekran i tworzy interaktywne dema, samouczki, symula-cje oprogramowania oraz filmy w kilka minut. Nie wymaga znajo-mości programowania i co najważniejsze dostępny jest w polskiej wersji językowej.

Przy rozpowszechnianiu nowego produktu często zadawane jest pytanie: jak dotrzeć do jak największej liczby odbiorców? Pro-fesjonalna prezentacja w tym wypadku to dopiero początek. Wów-czas najlepszym rozwiązaniem jest umieszczenie prezentacji w In-ternecie. Jednak zwykle są one zbyt duże… i tutaj pomoże Ci tak-że TurboDemo. Jednym kliknięciem zmieni prezentację na Flasha, a następnie dzięki zaawansowanej kompresji umieści ją na stronie internetowej.

To doskonałe narzędzie dla specjalistów ds. marketingu, szkole-niowców wielu branż, twórców różnych stron i portali interneto-wych oraz dla indywidualnego użytkownika.

TurboDemo 6.5 to program do tworzenia interaktywnych dem. Przygotowanie prezentacji składa się z trzech podstawo-wych etapów: rejestrowanie obrazów oraz dźwięków, dodawa-nie do zapisanego materiału efektów specjalnych (m.in. animo-wane notatki, dymki i rollovery, obiekty interaktywne o kon-figurowalnych kształtach, stylach, kolorach i formatowaniu), a na końcu opublikowanie w wybranym formacie. A jest z cze-go wybierać. TurboDemo potrafi dodawać interaktywne efek-ty do prezentacji, a następnie zapisywać gotową wersję w for-matach: Flash, Java, EXE, AVI, ASF, PDF, animowanych GIF, BMP i JPEG. W każdej chwili można skorzystać z kreatora, a wspaniałą zaletą jest przejrzysty interfejs programu. Wszystko to sprawia, że w każdej chwili możemy przedstawić swoją pre-zentację, a następnie przesłać ją pocztą elektroniczną, zyskując czas i pieniądze.

Funkcjonalność programu sprawia, że można dowolnie kształ-tować graficznie każdą prezentację i zmieniać jej opisy tekstowe, tworząc na przykład różnego rodzaju materiały poglądowe, testy, quizy czy konkursy z wyświetlaną punktacją i statystyką. To spra-wia, że program cieszy się uznaniem zarówno uczniów, jak na-uczycieli oraz wykładowców, ułatwia proces nauczania i czyni go bardziej atrakcyjnym.

Nowością w wersji 6.5 jest możliwość ustawienia jakości dźwię-ku przy formacie do ASF, nowe paski postępu dla formatu Flash, a także nowe skórki dla baloników i notatek. Program dostępny jest w wersjach: Standard, Professional, Studio oraz Enterprise.

Program TurboDemo to profesjonalne narzędzie dla twór-ców, specjalistów oraz indywidualnych użytkowników, jednym słowem dla wszystkich.

Więcej informacji: http://www.turbodemo.pl

TOxygenSMS Component for Borland Delphi and Borland C++ BuilderTOxygenSMS Component – to moduł do zarządzania telefona-mi Nokia. Moduł SMS pozwala wysyłać i otrzymywać SMS-wia-

domości, ustalać numer centrum SMS, określać ilość przechowy-wanych wiadomości, czytać i usuwać zawartość folderów SMS. Oprócz tego otrzymują Państwo dostęp do różnych parametrów telefonu: IMEI, model telefonu, wersję, jak również poziom sy-gnału, stan baterii i in. Dany moduł umożliwia wysyłkę zwykłego tekstu, tekstu w formacie Unicode, wiadomości z załącznikami takimi jak obrazki, dzwonki, logotypy grup abonentów i operato-rów. Po otrzymaniu wiadomości lub potwierdzenia jej dostarcze-nia komponent automatycznie generuje odpowiednie zdarzenie. Moduł pozwala także automatycznie usuwać wchodzące wiado-mości. Moduł Kalendarz jest przeznaczony do pracy z kalenda-rzem telefonu – pozwala on czytać, dodawać, zmieniać i usuwać notatki w kalendarzu.

TOxygenSMS Component pracuje w operacyjnych systemach Microsoft Windows 95, 98, NT i 2000 i obsługuje następujące GSM telefony Nokia: Moduł SMS: 3210, 3310, 3330, 3390, 3350, 3410, 3510, 5110, 5130, 5190, 5210, 6110, 6130, 6150, 6190, 6210, 6250, 6310, 6310i, 6510, 7110, 7190, 8210, 8290, 8250, 8310, 8390, 8850, 8855, 8890, 8910; Opcja Kalendarz: 6210, 6250, 7110, 7160, 7190.

TOxygenDirectorySpy Component for Borland Delphi and C++ BuilderTOxygen Directory Spy, komponent przeznaczony dla Bor-land Delphi wersji 3, 4, 5 i 6 – pozwala obserwować modyfi-kacje systemu plików (na przykład: tworzenie pliku lub kata-logu, dostęp do nich, ich usuwanie, zmiany rozmiaru i atrybu-tów). Osobliwość tego komponentu polega na tym, że w odróż-nieniu od wielu podobnych narzędzi zwraca on dokładną na-zwę katalogu lub pliku, w którym dokonane zostały zmiany, razem z dotychczasowymi jak i aktualnymi wartościami zmo-dyfikowanych parametrów. Można śledzić zmiany w katalo-gach i ich podkatalogach nie tylko na dyskach lokalnych ale i sieciowych.

Podstawowe możliwości:

• obserwacja zmian systemu plików w odrębnych wątkach;• zawsze znana jest dokładna nazwa katalogu lub pliku, który

został zmodyfikowany;• zawsze znane są dotychczasowe oraz aktualne wartości

zmodyfikowanych parametrów;• obserwacja wielu katalogów i ich podkatalogów;• obserwacja zmian systemu plików nawet na dyskach sie-

ciowych.

Oxygen Directory Spy ActiveX ControlOxygen Directory Spy ActiveX Control pozwala obserwować modyfikacje systemu plików takie jak tworzenie pliku lub kata-logu, dostęp do nich, ich usuwanie czy zmiany rozmiaru i atry-butów.

Osobliwość ActiveX Control polega na tym, że w odróżnieniu od podobnych narzędzi zwraca on dokładną nazwę katalogu lub pliku, w którym dokonane zostały zmiany, razem z dotychczaso-wymi jak i aktualnymi wartościami zmodyfikowanych parame-

10/2008

Page 13: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

12 13

Opis CD

trów. Można śledzić zmiany w katalogach i ich podkatalogach nie tylko na dyskach lokalnych ale i sieciowych.

Podstawowe możliwości:

• obserwacja zmian systemu plików w odrębnych wątkach;• zawsze znana jest dokładna nazwa katalogu lub pliku, któ-

ry został zmodyfikowany;• zawsze znane są dotychczasowe oraz aktualne wartości

zmodyfikowanych parametrów;• obserwacja wielu katalogów i ich podkatalogów;• obserwacja zmian systemu plików nawet na dyskach sie-

ciowych;• ActiveX Control jest kompatybilny z Microsoft Visual Ba-

sic, Microsoft Visual C++, Microsoft Access, Borland Del-phi, Borland C++ Builder oraz innymi narzędziami pro-gramowania wspierającymi ActiveX.

Xandros Server 2Xandros to profesjonalna dystrybucja przeznaczona głównie dla firm i instytucji . Jest to kompleksowe rozwiązanie serwerowe wyposażone w narzędzia znacznie usprawniające i przyspieszające administrację sys-temem. Xandors Server dostarczany jest z elementami, które ułatwiają jego integrację z już istniejącymi sieciami opartymi na produktach Mi-crosoft, Solaris czy innymi dystrybucjami Linux. Producenci tworząc system postawili na jego jak największą skalowalność, łatwość konfigu-racji i kompatybilność z innymi produktami.System dostarczany jest w kilku wersjach, dzięki temu wszyscy klien-ci mogą wybrać rozwiązanie najlepiej pasujące do ich potrzeb. Na dołą-czonej płycie znajduje się serwerowa wersja Xandrosa, która jest prze-znaczona do zastosowań w firmach i instytucjach, w szczególności ta-kich które korzystają z rozwiązań Microsoft (R). Xandros Server 2 za-wiera implementacje protokołów komunikacyjnych tej firmy oraz ser-wer Scalix, który potrafi współpracować z MS Exchange.

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]

Redakcja nie udziela pomocy technicznej w instalowaniu i użytkowaniu programów zamieszczonych na płytach CD-ROM dostarczonych razem z pismem.

www.sdjournal.org

Page 14: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200814

Biblioteka miesiącaOVal 1.0

www.sdjournal.org 15

Witaj, Czytelniku! Czeka Cię wy-cieczka po grząskim gruncie spój-ności danych, nie obędzie się rów-

nież bez indoktrynacji i krzewienia wiary w ist-nienie wysokiej jakości kodu. Gotowy?

Aplikacja korporacyjna (enterprise applica-tion) wspomaga i automatyzuje procedury da-nego przedsiębiorstwa. Istnieje tylko w jednym celu, aby zaspokajać wymagania biznesu. Po-siada zespół cech, które wyróżniają ją od zwy-kłych programów. Uzbrojona jest w narzędzia zwiększające jej niezawodność, łatwość obsługi, konfigurowalność i bezpieczeństwo. Świadczy usługi (gromadzi, przetwarza, prezentuje da-ne) realizując logikę biznesową. Jest to zwykle kilka kroków z życia danego biznesu (np. reje-stracja sprzedanej książki poprzedzona spraw-dzeniem jej stanu).

Metoda (usługa) biznesowa w odróżnieniu od zwykłej metody jest wzbogacona m.in. o:

• wsparcie dla transakcji (ACID);• bezpieczeństwo (uwierzytelnienie i auto-

ryzacja);• audyt (kto i kiedy wprowadzi zmiany);• logowanie (śledzenie wykonania);• politykę obsługi wyjątków (śledzenie nie-

powodzeń);• ochronę spójności danych (walidacja i wa-

runki poprawnego wykonania).

Wszystkie aspekty związane z podniesie-niem jakości i bezpieczeństwa oprogramo-wania są interesujące, zajmiemy się aspekta-mi zachowaniem spójności danych (pospoli-tą walidacją).

Skąd się biorą reguły aplikacji?Każdy produkt wytwarzany na potrzeby klien-ta musi zmierzyć się z ograniczeniami nakła-danymi przez biznes, infrastrukturę i uży-tą technologię. Słyszymy o regułach bizneso-wych, niezmiennikach, ograniczeniach, wa-runkach itp. Wiele podobnych pojęć jest uży-wanych w różnych kontekstach. Uporządkuj-my zatem nazewnictwo, reguła lub ogranicze-nie, które będzie implementowane w aplika-cji nazwiemy regułą aplikacji (application ru-le). Reguły aplikacyjne będą powstawały w wy-niku dostarczonych wymagań biznesowych (re-

guł biznesowych), ograniczeń systemu bazoda-nowego (reguł bazodanowych), wymagań za-chowania spójności systemu i innych czynni-ków wziętych pod uwagę podczas projektowa-nia systemu.

Warstwy i gradacjaJak wiemy ze Shreka, ogry, cebula oraz aplika-cje mają warstwy. Dla aplikacji są to – warstwa prezentacji aplikacji, usług, dostępu do danych oraz trwałego magazynu danych. W której z nich chronić spójność danych? Odpowiedź jest prosta, najlepiej w każdej:

• warstwa prezentacji – nie pozwól by użyt-kownik wprowadził złe dane (walidacja wprowadzanych danych przez użytkow-nika);

• warstwa aplikacji – walidacja parametrów przepływu sterowania w aplikacji;

• warstwa usług – nie pozwól by prezentacja/inny system dostarczył nie-spójnych danych (walidacja modelu oraz warunków wykonania);

• warstwa trwałego magazynu danych – ograniczenia i niezmienniki w bazie da-nych.

OVal

W niniejszym artykule pokazane jest jak usprawnić i uprzyjemnić sobie pracę związaną z walidacją spójności danych w aplikacjach biznesowych pisanych w języku Java, przy pomocy biblioteki OVal.

Dowiesz się:• Co to jest spójność danych i jaką rolę pełni w

świecie aplikacji biznesowych;

• Jak wspomóc proces kontrolowania spójności

danych przy pomocy biblioteki OVal.

Powinieneś wiedzieć:• Podstawy programowania w języku Java.

Poziom trudności

Walidacja spójności danych w aplikacjach korporacyjnych

Listing 1. Wstępna implementacja modelu biznesowego opisanego w przypadku Pani Zosi

public class Employee1 implements Serializable {

private static final long serialVersionUID = 1L;

private Long id;

private String firstName;

private String lastName;

private String pesel;

private Date employmentStart;

private Date employmentEnd;

}

Page 15: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200814

Biblioteka miesiącaOVal 1.0

www.sdjournal.org 15

Koszt implementacji walidacji w każdej war-stwie jest wysoki, najlepiej by było użyć tej sa-mej implementacji w każdej z warstw. DDD (Domain Driven Development) – pojęcie opar-te na modelu domenowym pozwala na po-dróż obiektów z danymi przez wszystkie war-stwy aplikacji. Jest to najlepsze miejsce do im-plementacji reguł aplikacji. Modelujemy tutaj problem jako klasy reprezentujące odpowied-nie pojęcia biznesowe wraz z wymaganym za-kresem informacji.

Wydzielmy trzy stopnie walidacji obiektu biznesowego, będą one trochę inaczej imple-mentowane:

• 1 stopień: walidacja zawartości pola tego samego obiektu;

• 2 stopień: walidacja pomiędzy polami tego samego obiektu;

• 3 stopień: walidacja pomiędzy polami dwóch różnych obiektów w modelu.

Podział ten pozwala lepiej zrozumieć kom-pleksowy model zabezpieczenia spójności da-nych w systemie. Dość tego przydługiego wstępu, zabierzmy się do walidacji danych za-mkniętych w obiektach biznesowych.

Przypadek Pani ZosiOkreślmy dziedzinę w kontekście, której bę-dziemy budować model.

Pewna mało znana korporacja potrzebuje auto-matyzacji kartoteki pracowniczej przechowywa-nej w części na kartach papierowych i w plikach arkuszy kalkulacyjnych. Specjalistka w tej dziedzi-nie pani Zosia przekazała nam wymagania:

Potrzebujemy przechowywać informacje o pra-cowniku, jego pesel, imię, nazwisko, datę zatrud-nienia, datę zwolnienia. Ponadto chcemy by pesel składał się z 11 cyfr oraz data zatrudnienia była wcześniejsza od daty zwolnienia.

Zastanawiamy się przez chwilę nad wybo-rem metodologi w której będziemy rozwijać nasz produkt, wybór padł na jedną ze zwin-nych metodyk (Cowboy Coding). Bierzemy wy-magania na warsztat i po dwóch łykach kawy mamy model implementacyjny dla naszego sys-temu (Listing 1).

Podczas prac nad modelem dostaliśmy in-formacje od pani Zosi, że wszystkie informa-cje oprócz daty zakończenia są niezbędne w ze-stawieniach dla Pana Prezesa, postanowiliśmy uwzględnić to w naszych pracach. Zaimple-mentujmy najpierw wymagania dotyczące obo-wiązkowych pól. Wykorzystamy w tym celu ad-notacje @NotNull z przybornika OVala. Określa ona iż dane pole łamie regułę aplikacji jeżeli je-go wartością jest null.

@NotNull

private String firstName;

Oznaczyliśmy nasze pole (walidacja pierwsze-go poziomu) jako wymagane. Co zyskujemy?

Podczas sprawdzania poprawności obiektu ty-pu Employee w przypadku gdy pole firstName będzie zawierać null zostanie zwrócona in-formacja o złamaniu reguły wymagalności te-go pola. Jak przyjrzymy się parametrom tej adnotacji dostrzeżemy tam bardzo pożytecz-ne opcje jak np. message. Możemy określić ja-ki komunikat będzie zwracany w przypadku złamania reguły:

@NotNull(message = "Imię jest wymagane")

private String firstName;

Niestety w korporacyjnych aplikacjach, gdzie komunikaty są zmieniane dosyć często lub

zachodzi potrzeba wprowadzenia lokaliza-cji, parametr message jest mało pożyteczny. OVal dostarcza inny bardziej odpowiedni: errorCode. Możemy tam wpisać tekstową re-prezentację kodu, który zostanie zwrócony w przypadku złamania reguły:

@NotNull(errorCode = "firstName.notNull")

private String firstName;

kod ten możemy wykorzystać do odczytania komunikatu z pliku właściwości (properties). Dobrze aby kod błędu był znaczący więc war-to zastosować nazwę pola wraz z nazwą spraw-dzanej reguły (np. „mojePole.lenght”).

Listing 2. Model z Listingu 1 udekorowany adnotacjami OVal

public class Employee1 implements Serializable {

private static final long serialVersionUID = 1L;

@NotNull(errorCode = "id.notNull", profiles = {"model"})

private Long id;

@NotNull(errorCode = "firstName.notNull", profiles = {"view", "model"})

@MaxLength(errorCode = "firstName.Length", value = 2, profiles = {"view", "model"})

private String firstName;

@NotNull(errorCode = "lastName.notNull", profiles = {"view", "model"})

@MaxLength(errorCode = "lastName.Length", profiles = {"view", "model"}, value = 200)

private String lastName;

@NotNull(errorCode = "pesel.notNull", profiles = {"view", "model"})

@MatchPattern(errorCode = "pesel.matchPattern", pattern = "^\\d{11}$", profiles =

{"view", "model"})

private String pesel;

@NotNull(errorCode = "employmentStart.notNull", profiles = {"view", "model"})

private Date employmentStart;

private Date employmentEnd;

}

Listing 3. Metoda sprawdzająca czy pracownik nie zwalnia się przed zatrudnieniem

@AssertTrue(errorCode = "employmentEnd.valid", profiles = {"view", "model"})

@IsInvariant

public boolean validateEmploymentEnd() {

boolean isValid = true;

if (this.employmentStart != null && this.employmentEnd != null) {

isValid = this.employmentStart.before(this.employmentEnd);

}

return isValid;

}

Page 16: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200816

Biblioteka miesiącaOVal 1.0

www.sdjournal.org 17

W naszym modelu mamy ciekawy przypadek jest to pole id. Nie było one wymienione przez Panią Zosię jednak my dodaliśmy je aby nadać każdemu pracownikowi unikatowy identyfika-tor w naszym systemie. Pole to jest wymagane, ale dopiero w warstwie usług, przed zapisaniem do bazy. Chcąc zgodnie z założeniem wykorzy-stywać walidację we wszystkich warstwach apli-kacji mamy pewien dylemat. Na szczęście twór-ca OVala przewidział nasze potrzeby, rozwiąza-niem jest tu mechanizm profili. Ten prosty i użyteczny mechanizm pozwala określić, która z sprawdzanych reguł jest brana pod uwagę. Zde-finiujmy dwa profile view (reguły z tej grupy bę-dą sprawdzane w warstwie widoku) oraz model (reguły z tej grupy będą brane pod uwagę w war-stwie usług). Mamy więc:

@NotNull(errorCode = "firstName.notNull",

profiles = {"view",

"model"})

private String firstName;

a w przypadku id:

@NotNull(errorCode = "id.notNull", profiles

= {"model"})

private Long id;

Zerknijmy na pozostałe parametry. Mamy severity, możemy go użyć aby określić jaką wagę ma nasza reguła (np. w przypadku zła-mania z niskim priorytetem można wyświe-tlić okno z ostrzeżeniem i pozwolić na kon-tynuację działania). Następny jest doo, nie mam pojęcia do czego służy więc go pominę. OVal wyposażony jest w dużą liczbę adnota-cji reprezentujących walidację dla różnych ty-pów pól i sposobów walidacji. Jestem w sta-nie zaprezentować tylko parę co do reszty od-syłam do podręcznika i javadoców. Wróćmy do naszego imienia, biznes mówi, że jest wy-magane, a baza (którą odziedziczyliśmy po sta-rej aplikacji) wymaga by pole to miało maksy-malnie 200 znaków. Zaimplementujemy to wymaganie za pomocą adnotacji @MaxLenght, mamy więc:

@NotNull(errorCode = "firstName.notNull",

profiles = {"view",

"model"})

@MaxLength(errorCode = "firstName.Length",

value = 2, profiles =

{"view", "model"})

private String firstName;

Wprawne oko dostrzeże tu pluskiew (bug) od-nośnie długości pola, na razie zostawmy ten problem.

Podobna do @MaxLenght jest adnotacja @Lenght w której możemy określić minimalny i maksymalny zakres długości dla tekstu.

Dla pola pesel mamy specjalne wymaga-nie, Pani Zosia prosiła aby zawartość składała

Listing 4. Implementacja prostej klasy narzędziowej, wspomagającej proces walidacji

public class ValidationUtil {

public static List<String> getErrorCodes(String[] profiles, Object entity) {

List<String> errorCodes = new ArrayList<String>();

List<ConstraintViolation> violations = executeValidation(profiles, entity);

for(ConstraintViolation violation : violations) {

errorCodes.add(violation.getErrorCode());

}

return errorCodes;

}

private static List<ConstraintViolation> executeValidation(String[] profiles, Object

entity) {

Validator validator = new Validator();

validator.disableAllProfiles();

for (String profile : profiles) {

validator.enableProfile(profile);

}

return validator.validate(entity);

}

public static String getMessageByErrorCode(String errorCode) {

Properties appRulesProperties = new Properties();

try {

appRulesProperties.load(ValidationUtil.class.getResourceAsStream("/app-

rules.properties"));

} catch (IOException e) {

e.printStackTrace();

}

return appRulesProperties.getProperty(errorCode);

}

}

Listing 5. Implementacja metody getErrorCodes

public List<String> getErrorCodes(String[] profiles) {

// generic validation

List<String> errorCodes = ValidationUtil.getErrorCodes(profiles, this);

return errorCodes;

}

Listing 6. Implementacja klasy reprezentującej identyfikator działu

public class Department implements Serializable, ValidationSupport {

private static final long serialVersionUID = 1L;

@NotNull(errorCode = "id.notNull", profiles = {"model"})

private Long id;

@NotNull(errorCode = "code.notNull", profiles = {"view", "model"})

@Length(errorCode = "code.length", min = 2, max = 2, profiles = {"view", "model"})

private String code;

public List<String> getErrorCodes(String[] profiles) {

List<String> errorCodes = ValidationUtil.getErrorCodes(profiles, this);

return errorCodes;

}

}

Page 17: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200816

Biblioteka miesiącaOVal 1.0

www.sdjournal.org 17

się z jedenastu cyfr. Postępując zgodnie z zasa-dą klient nasz pan dodajmy taką regułę. Użyje-my potężnego narzędzia dostarczanego przez OVal jakim jest adnotacja @MatchPattern. Wa-liduje ona pole tekstowe za pomocą wyrażeń regularnych. Jeżeli nie znajdziemy odpowied-niej dla siebie adnotacji dla pola tekstowego to @MatchPattern załatwi każde wysublimowane wymaganie:

@NotNull(errorCode = "pesel.notNull",

profiles = {"view",

"model"})

@MatchPattern(errorCode =

"pesel.matchPattern",

pattern = "^\d{11}$",

profiles = {"view",

"model"})

private String pesel;

Zgodnie z zasadami sztuki walidacji udekoro-waliśmy też pozostałe pola (Listing 2).

Wszystkie nasze reguły były pierwszego poziomu (opisujące pole). Następnym ro-dzajem są reguły dotyczące zależności po-między polami w danym obiekcie. W naszym jednoklasowym modelu mamy datę rozpo-częcia i datę zakończenia pracy. Pani Zosia ewidentnie upierała się przy sprawdzeniu czy aby ktoś nie zwalnia się przed zatrudnie-niem. Innymi słowy kolejne wymaganie mó-wi: data zwolnienia musi być późniejsza od daty zatrudnienia. Użyjemy zestawu narzę-dzi przygotowanych do walidacji drugiego stopnia, są to między innymi: @AssertTrue i @AssertFalse.

Dla każdej z tych adnotacji potrzebujemy metody która sprawdzi określone przez nas wa-runki, dla @AssertTrue każda metoda walidu-jąca, która zwróci false dodaje złamaną regu-łę, odwrotnie w przypadku @AssertFalse me-toda która zwróci true oznacza złamanie regu-ły (Listing 3).

Mamy ładną, tłustą definicję klasy obiektu biznesowego. Najwyższy czas zabrać się za te-sty naszego rozwiązania (odwrotnie jak to ra-dzą w TDD). Mamy definicję klasy, mamy do-dany aspekt walidacji, brakuje nam jeszcze na-rzędzia, które sprawdzi nasze warunki na dzia-łającym obiekcie. OVal dostarcza klasy narzę-dziowej, której zadaniem jest sprawdzić po-prawność danego obiektu.

Validator validator = new Validator();

BusinessObject bo = new BusinessObject();

List<ConstraintViolation> violations =

validator.validate(bo);

Jest to silne narzędzie ale związu-je nas z implementacją OVala (klasa ConstraintViolation). Chcemy opakować je-go funkcjonalność aby proces walidacji koń-czył się zwróceniem listy złamanych kodów, aby można je później przetłumaczyć na odpo-

wiednie wiadomości i wyświetlić użytkowni-kowi. Następny dylemat, jaką klasę obdarzyć odpowiedzialnością za sprawdzenie popraw-ności? Mamy do wyboru klasę narzędziową,

która wykona walidację na zewnątrz obiek-tu, lub klasę obiektu biznesowego, która sa-ma przeprowadzi ten proces na sobie i zależ-nych od siebie obiektach. Ze względu na to,

Listing 7. Kaskadowe sprawdzanie powiązanych obiektów biznesowych

public List<String> getErrorCodes(String[] profiles) {

// generic validation

List<String> errorCodes = ValidationUtil.getErrorCodes(profiles, this);

// custom validation

if (this.department != null) {

List<String> departmentErrorCodes = ValidationUtil.getErrorCodes(profiles,

this.department);

for (String departmentErrorCode : departmentErrorCodes) {

errorCodes.add("department." + departmentErrorCode);

}

}

return errorCodes;

}

Listing 8. Implementacja klasy testów dla rozważanego modelu

public class ModelTest {

@Test

public void validateViewModelTest() throws Exception {

Employee employee = new Employee();

List<String> errorCodes = employee.getErrorCodes(new String[] {"widok"});

printErrorCodes(errorCodes);

Assert.assertTrue("errorCodes = 0", errorCodes.size() == 0);

}

private void printErrorCodes(List<String> errorCodes) {

if (errorCodes.size() == 0) {

System.out.println("Test passed");

} else {

System.out.println("Broken rules:");

int i = 1;

for (String error : errorCodes) {

System.out.println("\t" + i + ") " + error);

i++;

}

}

}

}

Listing 9. Efekt działania metody pomocniczej wypisującej zestaw złamanych reguł

Broken rules:

1) firstName.notNull

2) employmentStart.notNull

3) pesel.notNull

4) lastName.notNull

Page 18: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200818

Biblioteka miesiącaOVal 1.0

www.sdjournal.org 19

że łatwiej jest kaskadowo wywoływać spraw-dzanie na obiektach zależnych (kompozy-tach i kolekcjach) wybieramy drugie rozwią-zanie. Dodatkowym plusem tego rozwiąza-nia jest możliwość dodania do tej metody swojej dodatkowej logiki i ewentualnych no-wych kodów błędów (np. po ręcznej imple-mentacji walidacji trzeciego stopnia). Od tej chwili obiekt biznesowy sam umie wskazać

swoje wybrakowane reguły. Do roboty, w ce-lu wykonania spójnego sposobu walidacji we wszystkich obiektach biznesowych dodamy interfejs wspomagający takie zachowanie:

public interface ValidationSupport {

public List<String> getErrorCodes(String[] profiles);

}

Podczas implementacji interfejsu w naszej kla-sie (i sprawdzeniu kto nas ostatnio odwiedzał) dostrzegliśmy, że w każdej klasie trzeba bę-dzie dodać podobną funkcjonalność. Proste operacje przeniesiemy do klasy narzędziowej aby zmniejszyć powtarzalność kodu (ujemny wpływ dziedziczenia metodą copy'ego-paste'a). Spójrzmy na Listing 4.

Teraz gdy sobie ułatwiliśmy pracę możemy dodać naszą implementację getErrorCodes (Listing 5).

W ostatniej chwili Prezes zażądał od Pani Zo-si by w zestawieniu obok nazwiska pracowni-ka pojawił się kod wydziału. Po szybkim telefo-nie do kierownika naszego projektu Pani Zosia zajęła się swoimi ważkimi sprawami, a my do-staliśmy kukułcze jajo pod postacią nowej kla-sy w naszym modelu. Wymagania podpowia-dają nam iż wydział jest obowiązkowy i musi mieć poprawny numer składający się z 2 zna-ków. Kawa wystygła więc bierzemy się za robo-tę, zaimplementujemy wydział jako nową kla-sę (Listing 6).

Klasa została udekorowana adnotacjami i przyszykowana do przyszłej walidacji. Obiekt klasy Department będzie kompozytem w kla-sie Emploee, tak więc dodajemy tam odpowied-nie pole:

@NotNull(errorCode = "department.notNull",

profiles = {"model"})

private Department department;

W naszym przypadku informacje z obiek-tów dwóch klas będą prezentowane na jed-nym ekranie, jak więc zwalidować za jed-nym zamachem obiekt klasy Emploee oraz odpowiadający mu Department? OVal do-starcza pewne narzędzie, jest to adnota-cja @AssertValid, niestety sprawdza tyl-ko czy dany obiekt jest poprawny, w przy-padku złamania reguły wewnątrz obiektu jest zwracany pojedynczy errorCode przy-pisany do tej adnotacji, a nie lista złama-nych reguł osadzonego obiektu. Potrzebu-jemy listy wszystkich złamanych reguł po to by wyświetlić je w postaci komunikatów pod odpowiadającymi im polami. Na szczę-ście mamy naszą metodę getErrorCodes i to jest dobre miejsce by wywołać kaskadowo sprawdzanie powiązanych obiektów bizne-sowych. Dodatkowo sposób ten rozwiązuje problem powielania się errorCodów, gdyż do każdego errorCodu pozyskanego z kla-sy Department dodamy dodatkowy identy-fikator department. Zmodyfikowaną meto-dę można zobaczyć na Listingu 7.

Nadszedł czas aby sprawdzić przydatność na-szego modelu. Przetestujemy wymagania za po-mocą popularnego narzędzia jakim jest JUnit (klasa testów na Listingu 8).

Tworzymy nowy, czysty obiekt klasy pra-cowniczej i sprawdzamy czy zawiera spójne i poprawne dane. Uruchamiamy test, meto-

Listing 10. Rozszerzenie klasy testów: niepoprawna data zatrudnienia

@Test

public void validateViewModelTest() throws Exception {

SimpleDateFormat sdf = new SimpleDateFormat("yyyy.MM.dd");

Employee employee = new Employee();

employee.setDepartment(new Department());

employee.setFirstName("Jan");

employee.setLastName("Kowal");

employee.setEmploymentStart(sdf.parse("2008.01.01"));

employee.setEmploymentEnd(sdf.parse("2007.01.01"));

employee.setPesel("12345678911");

List<String> errorCodes = employee.getErrorCodes(new String[] {"view"});

printErrorCodes(errorCodes);

Listing 11. Opis złamanych reguł dla testu opisanego na Listingu 10

Broken rules:

1) firstName.Length

2) employmentEnd.valid

3) department.code.notNull

Listing 12. Implementacja metody uzyskiwania komunikatu według podanego kodu błędu

public static String getMessageByErrorCode(String errorCode) {

Properties appRulesProperties = new Properties();

try {

appRulesProperties.load(ValidationUtil.class.getResourceAsStream("/app-

rules.properties"));

} catch (IOException e) {

e.printStackTrace();

}

return appRulesProperties.getProperty(errorCode);

}

Listing 13. Opis złamanych reguł z dołączonymi komunikatami dla użytkownika

Broken rules:

1) firstName.Length

Messages:

1) Pole 'Imię' może zawierać maks. 200 znaków

W Sieci

• http://oval.sourceforge.net/ – strona domowa biblioteki OVal;• http://oval.sourceforge.net/userguide.html – podręcznik użytkownika biblioteki OVal;• http://oval.sourceforge.net/api/index.html – opis interfejsu programistycznego (API) bibliote-

ki OVal w postaci javadoców;• http://jcp.org/en/jsr/detail?id=303 – szczegółowe informacje na temat specyfikacji JSR 303:

Bean Validation.

Page 19: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200818

Biblioteka miesiącaOVal 1.0

www.sdjournal.org 19

Listing 14a. Finalna postać klas modelu i testów dla przypadku Pani Zosi

public class Employee implements Serializable, ValidationSupport

{

private static final long serialVersionUID = 1L;

@NotNull(errorCode = "id.notNull", profiles = {"model"})

private Long id;

@NotNull(errorCode = "firstName.notNull", profiles = {"view",

"model"})

@MaxLength(errorCode = "firstName.Length", value = 2, profiles

= {"view", "model"})

private String firstName;

@NotNull(errorCode = "lastName.notNull", profiles = {"view",

"model"})

@MaxLength(errorCode = "lastName.Length", profiles = {"view",

"model"}, value = 200)

private String lastName;

@NotNull(errorCode = "pesel.notNull", profiles = {"view",

"model"})

@MatchPattern(errorCode = "pesel.matchPattern", pattern = "^\

\d{11}$", profiles = {"view", "model"})

private String pesel;

@NotNull(errorCode = "employmentStart.notNull", profiles =

{"view", "model"})

private Date employmentStart;

private Date employmentEnd;

@NotNull(errorCode = "department.notNull", profiles =

{"model"})

private Department department;

@AssertTrue(errorCode = "employmentEnd.valid", profiles =

{"view", "model"})

@IsInvariant

public boolean validateEmploymentEnd() {

boolean isValid = true;

if (this.employmentStart != null && this.employmentEnd !=

null) {

isValid = this.employmentStart.before(this.employment

End);

}

return isValid;

}

public List<String> getErrorCodes(String[] profiles) {

// generic validation

List<String> errorCodes = ValidationUtil.getErrorCodes(pro

files, this);

// custom validation

if (this.department != null) {

List<String> departmentErrorCodes = ValidationUtil.getE

rrorCodes(profiles, this.department);

for (String departmentErrorCode : departmentErrorCodes)

{

errorCodes.add("department." + departmentErrorCode);

}

}

return errorCodes;

}

// properties

}

public class Department implements Serializable,

ValidationSupport {

private static final long serialVersionUID = 1L;

@NotNull(errorCode = "id.notNull", profiles = {"model"})

private Long id;

@NotNull(errorCode = "code.notNull", profiles = {"view",

"model"})

@Length(errorCode = "code.length", min = 2, max = 2, profiles

= {"view", "model"})

private String code;

public List<String> getErrorCodes(String[] profiles) {

List<String> errorCodes = ValidationUtil.getErrorCodes(pro

files, this);

return errorCodes;

}

// properties

}

public class ModelTest {

@Test

public void validateViewModelTest() throws Exception {

SimpleDateFormat sdf = new SimpleDateFormat("yyyy.MM.dd");

Employee employee = new Employee();

employee.setDepartment(new Department());

employee.setFirstName("Jan");

employee.setLastName("Kowal");

employee.setEmploymentStart(sdf.parse("2008.01.01"));

employee.setEmploymentEnd(sdf.parse("2009.01.01"));

employee.setPesel("12345678911");

employee.getDepartment().setCode("KD");

employee.setId(1L);

employee.getDepartment().setId(1L);

List<String> errorCodes = employee.getErrorCodes(new

String[] {"view", "model"});

printErrorCodes(errorCodes);

printErrorMessages(errorCodes);

Assert.assertTrue("errorCodes = 0", errorCodes.size() ==

0);

}

private void printErrorCodes(List<String> errorCodes) {

Page 20: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200820

Biblioteka miesiąca

da pomocnicza wypisuje nam zestaw wszyst-kich złamanych reguł (Listing 9).

Pierwsze spostrzeżenie, testowaliśmy tylko re-guły z grupy view więc pole id nie zostało wy-pisane jako niepoprawne. Drugie spostrzeżenie, tylko reguły wymagalności (@NotNull) zostały sprawdzone. Jest to logiczne zachowanie, skąd można wiedzieć czy pole ma zadaną długość skoro zawiera wartość nieokreśloną. Uzupełnij-my nasz obiekt o parę informacji (wpiszmy złą datę końca zatrudnienia), Listing 10.

Nasz niezawodny tester (JUnit) wskazuje na-stępujące niezgodności (Listing 11).

Jak widzimy zadziałała walidacja dla osadzone-go obiektu klasy wydziałowej. Walidacja drugiego stopnia określająca zależności pomiędzy datą roz-poczęcia pracy i zakończenia wskazuje błędną da-tę zakończenia pracy. Podczas rozwijania naszego modelu wkradł się defekt (pani Zosia wyraźnie prosiła aby długość pola imię miało wystarczającą długość). Naprawiamy to zwiększając maksymal-ną długość do 200 znaków. Dodamy też nazwę wydziału dla naszego pracownika i poprawiamy datę zwolnienia. Po ponownym uruchomieniu testu otrzymujemy komunikat Test passed.

Zapomnieliśmy jednak o naszym drugim profilu który będziemy wykorzystywać w war-stwie usług, a więc dodajmy go do testu:

List<String> errorCodes = employee.getErro

rCodes(new String[]

{"view", "model"});

Bezwzględny tester mówi:

Broken rules:

1) id.notNull

2) department.id.notNull

Ok, pozostaje nam ponadawać identyfikato-ry dla tych obiektów i już możemy bezpiecz-nie utrwalić obiekt w bazie. Zazwyczaj identy-fikatory są generowane przez system (np. me-todą autoinkrementacji w bazie danych) ale dla pokazania mechanizmu profili wstawimy je ręcznie.

employee.setId(1L);

employee.getDepartment().setId(1L);

Dostajemy informacje od JUnit, że teraz jest wszystko ok.

Pozostaje nam odwzorować kody błędów na komunikaty dla użytkownika. Komunikaty bę-dziemy przechowywać w plikach właściwości (properties). Struktura pliku wygląda tak:

firstName.Length=Pole 'Imi\u0119' mo\

u017Ce zawiera\u0107 maks. 200 znak\

u00F3w

Trzeba pamiętać aby polskie znaki były zapi-sywane w standardzie unicode. Do klasy na-rzędziowej ValidationUtil dodajemy metodę uzyskiwania komunikatu według podanego ko-du błędu – Listing 12.

Na potrzeby testów tego rozwiązania naru-szymy integralność pola firstName przekracza-jąc jego zakres (lub zmniejszając maksymalną dopuszczalną długość tekstu). Wynikowy ko-munikat przedstawiony jest na Listingu 13.

Ostatecznie model i klasa z testem wygląda jak Listingu 14.

Z dumą udajemy się do pani Zosi obwieścić, iż robota zrobiona. Jakże zaskoczeni jesteśmy gdy pani Zosia drapie się po głowie oglądając w notatniku naszego świeżo wypieczonego JAR'a. No cóż chyba zapomnieliśmy o jakimś istotnym elemencie aplikacji (GUI).

Dla każdego rozwiązania dedykowanego dla technologii webowych (spring, free mar-ker, jsf) należy dopisać kawałek kodu integra-cyjnego łączącego daną technologię z rozwią-zaniami OVala (OVal dostarcza klas integru-jących, które implementują standard walida-cji dla Spring, jednak nadaje się on do pro-stych rozwiązań, bardziej skomplikowane

zmuszą nas do własnej implementacji inter-fejsu Validator).

Problem sprawdzania poprawności danych jest na tyle powszechny, że został zgłoszony wniosek o standaryzację (JSR 303). W dostęp-nym już szkicu dokumentu dostępny jest opis technologii i proponowane nazewnictwo. Za-powiada się na kawał pożytecznej specyfikacji.

Oval nie jest jedynym szeryfem w mieście. Dla Javy mamy – Beans Validation (Spring modules) i Hibernate annotations. Dot NET nie jest tu bied-niejszy i doczekał się implementacji .NET Valida-tion Framework. Każdy z tych zrębów projekto-wych ma wady i zalety. OVal jako jedyny obsłu-guje profile (W JSR 303 nazwane grupami), nie-stety dokumentacja użytkownika jest dość skąpa. Przeznaczenia adnotacji i ich parametrów trzeba zazwyczaj poszukiwać w dokumentacji javadoc oraz dostarczonym kodzie źródłowym.

PodsumowanieTo dopiero początek drogi przez szuwary wa-lidacji, proponuję zerknąć do dokumenta-cji OVala. Jest on nie tylko zrębem projekto-wym do walidacji POJO wspiera DBC (projek-towanie przez kontrakty) za pomocą adnota-cji i AspectJ. Zawiera silny mechanizm połą-czenia języków interpretowanych tj. mvel i be-anshell z aspektami spójności danych. Adno-tacje są tylko jednym ze sposobów określenia reguł walidacji w OVal. Innym mniej związa-nym z kodem Javy sposobem jest użycie pli-ków konfiguracyjnych XML. Ale o tym mo-że kiedy indziej...

Czytelniku dotarłeś tutaj, więc powinieneś dostać model za wytrwałość, niech moc walida-cji będzie z Tobą!

Listing 14b. Finalna postać klas modelu i testów dla przypadku Pani Zosi

if (errorCodes.size() == 0) {

System.out.println("Test passed");

} else {

System.out.println("Broken rules:");

int i = 1;

for (String error : errorCodes) {

System.out.println("\t" + i + ") " + error);

i++;

}

}

}

private void printErrorMessages(List<String> errorCodes) {

if (errorCodes.size() != 0) {

System.out.println("Messages:");

int i = 1;

for (String error : errorCodes) {

System.out.println("\t" + i + ") " + ValidationUtil.getMessageByErrorCode

(error));

i++;

}

}

}

}

SEBASTIAN PIOTROWSKISebastian Piotrowski pracuje na stanowisku Senior

Software Developer w firmie

BLStream wchodzącej w skład Grupy BLStream.

Grupa BLStream powstała by efektywniej wykorzy-

stywać potencjał dwóch, szybko rozwijających się

producentów oprogramowania – BLStream i Ga-

melion. Firmy wchodzące w skład grupy specjali-

zują się w wytwarzaniu oprogramowania dla klien-

tów korporacyjnych, w rozwiązaniach mobilnych

oraz produkcji i testowaniu gier.

Kontakt z autorem:

[email protected]

Page 21: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

REKLAMA

Page 22: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200822

Narzędzia programistyczneMigracja Joomla 1.0 do 1.5

www.sdjournal.org 23

Nie ma co zawracać kijem wody w Wiśle, ani młyńskiego koła ręka-mi zatrzymywać. Nowy Joomla po-

wstał także i po to, by zastąpić starszego. A że rzeczy niemożliwych w informatyce chyba nie ma, to i możliwa jest doskonała migracja z Joomla 1.0 do 1.5. Doskonała, czyli bezstrat-na, bez frustracji, że coś zepsujemy, trwają-ca tak krótko, że użytkownicy naszej witry-ny nawet się nie spostrzegą, kiedy jej dokona-my. Tak czy owak, wcześniej czy później trze-ba ją przeprowadzić.

Ale czy na pewno? Promotorowi Joom-la! w Polsce nie wypada ani wątpić w słusz-ność takiego zabiegu, ani tym bardziej znie-chęcać do migracji. Wręcz przeciwnie – wy-pada przekonywać że warto i objaśnić, jak jej dokonać najbezpieczniej i najprościej. Nie będziemy zatem zbytnio na temat korzyści i strat dywagować, ale też nie możemy prze-milczeć, że:

• migracja nie zawsze jest zupełnie bez-stratna – może pociągać za sobą ko-nieczność zmodyfikowania oryginalnej treści, a nawet rezygnacji z niektórych dawniejszych rozszerzeń, które nie ze-chcą się dobrze sprawować nawet mi-mo włączenia trybu zgodności wstecz-nej (legacy);

• migracja nie zawsze skutkuje rzeczywi-stym unowocześnieniem i poprawą wy-

dajności witryny, tryb zgodności wstecz-nej umożliwia wprawdzie działanie star-szych rozszerzeń w nowym Joomla!, ale walory nowego oprogramowania będą odczuwalne wtedy jedynie, gdy unowo-cześnimy także dodatkowe składniki, a ze starszych rozszerzeń będziemy korzy-stać wyjątkowo;

• migracja wymaga niekiedy sporego na-kładu czasu i pracy oraz takiej znajo-mości obu systemów, by poradzić sobie z koniecznością ręcznego przenoszenia części danych – nie wszystkie bowiem dane są przenoszone automatycznie;

• migracja niesie ze sobą ryzyko niepowo-dzenia.

Generalnie rzecz biorąc – opłacalne jest mi-growanie z witryn małych, z niewielką ilo-ścią danych, z niewielką ilością rozszerza-jących rdzeń komponentów, modułów i in-nych dodatków.

Na pewno warto migrować duże witryny nawet z dużą ilością danych, jeśli obsługiwa-ne są przez standardowe komponenty, a dla nielicznych rozszerzeń istnieją nowsze wer-sje lub rozwiązania alternatywne.

Głęboko natomiast trzeba się zastanowić nad migracją rozbudowanej, a dobrze działa-jącej witryny z wieloma dodatkowymi skład-nikami, dla których nie opracowano jesz-cze unowocześnionych wersji. Być może na-wet w ogóle nie należy z takich witryn mi-grować.

BezpiecznieMigracja jest bezpieczna, dopóty zachowujemy standardowe środki ostrożności. A zatem:

• stwórz pełną zapasową kopię działają-cej witryny – systemu plików i bazy da-nych;

• przetestuj migrację na replice witryny, najlepiej na serwerze produkcyjnym;

• starą witrynę usuń dopiero wówczas, gdy nabędziesz pewności że nowa dzia-ła poprawnie.

Ponadto przed migracją warto najpierw zaktualizować swoją witrynę Joomla 1.0.x do najnowszej wersji w tej serii (aktualnie 1.0.15). Pełnego sukcesu taki krok nie za-pewni, ale może zaoszczędzić niespodziewa-nych sytuacji.

Dwa etapyMigracja przebiega w dwóch etapach. W pierwszym etapie trzeba:

• zgromadzić potrzebne pakiety instala-cyjne (Joomla!, komponentów i innych rozszerzeń);

• sporządzić kopię bezpieczeństwa prze-noszonej witryny (systemu plików i ba-zy danych);

• przygotować do przeniesienia dane – usta-wienia i treści przenoszonej witryny.

W drugim etapie trzeba:

• zainstalować Joomla 1.5 z migrowanymi danymi;

• doinstalować rozszerzenia, z których ko-rzystaliśmy w Joomla 1.0;

• przetestować i skorygować działanie no-wej witryny.

Warto sobie w tym momencie uświadomić, że w nowej witrynie nie odtworzymy wszyst-kiego w 100 %, chociażby dlatego, że nie-których rozwiązań w Joomla 1.5 po prostu nie ma albo zostały zastąpione innymi. Do-brym przykładem jest polecenie {mosimage}

Joomla 1.0 do 1.5

Wprawdzie Joomla 1.5 jest następcą 1.0, ale różnice między obu wydaniami są tak istotne, że Joomla 1.0.x nie można unowocześnić do Joomla 1.5 przy pomocy łatki aktualizującej. Jedyną możliwą drogą jest migracja – założenie nowej witryny na Joomla 1.5 i przeniesienie danych z Joomla 1.0.x.

Dowiesz się:• Jak krok po kroku przejść przez cały proces mi-

gracji.

Powinieneś wiedzieć:• Podstawowe informacje o Joomla 1.0.

Poziom trudności

Proces migracji krok po kroku

Page 23: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200822

Narzędzia programistyczneMigracja Joomla 1.0 do 1.5

www.sdjournal.org 23

umieszczające w Joomla 1.0 obrazki w arty-kułach. Standardowe wystąpienia tego po-lecenia zostaną przekonwertowane, ale jeśli to polecenie zastosowano także w jakimś in-nym komponencie niż Content (Artykuły), to konwersję trzeba przeprowadzić ręcznie. Na szczęście, takich problemów jest niewiele, a dokładne przetestowanie witryny po migracji pozwoli je zdiagnozować i naprawić.

I etap: Przygotowanie do migracji

Krok 1: Zgromadź potrzebne materiałyPobieranie plików z Internetu nie stano-wi dziś zwykle żadnego problemu, ale po-trzebne pakiety instalacyjne warto zgroma-dzić przed rozpoczęciem migracji. A będą potrzebne:

• najnowszy pakiet instalacyjny Joomla 1.5;• najnowszy pakiet językowy dla Joomla

1.5;• pakiety instalacyjne rozszerzeń, wyko-

rzystywanych w Joomla 1.0, najlepiej już w wersji dla J! 1.5;

• pakiet instalacyjny komponentu Migrator;• pakiety wtyczek ETL i SQL dla kompo-

nentu Migrator.

Krok 2: Sporządź bezpieczną kopię witrynyW to, że dysponujesz aktualną i bezpieczną kopią swojej witryny nawet nie śmiemy wąt-pić. Niemniej – upewnij się, że to najaktual-niejsza kopia. A gdyby było inaczej, uaktual-nij ją:

• przekopiuj na swój komputer w bez-pieczne miejsce cały katalog działającej witryny Joomla 1.0;

• wykonaj najaktualniejszy zrzut bazy da-nych.

Bardzo pomocnym w wykonaniu tych za-dań może być komponent JoomlaPack z http://www.joomlapack.net.

Krok 3: Zainstaluj w Joomla 1.0 komponent MigratorPrzygotowanie danych z przenoszonej witryny zostało zautomatyzowane dzięki pracy dwóch programistów – Haralda Baera, który opraco-wał przed kilku laty komponent eBackup, oraz Samuela Moffatta, który ten komponent prze-projektował do nowego zadania, udostępnia-jąc go pod nazwą Migrator. Komponent wyko-nuje jedno, ale jakże istotne zadanie: generuje zrzut odpowiednio przekonwertowanej bazy danych witryny zbudowanej na Joomla! 1.0.x lub Mambo 4.5.2 0. Dokładniej – dwa zada-nia: konwertuje treści oraz ustawienia konfi-guracyjne, w tym przenosi niektóre ustawie-nia z plików do bazy danych. Ale to już tajem-nice programu niezbyt dla nas istotne.

Najnowszą wersję komponentu migracyj-nego – w chwili pisania artykułu była to wer-sja 1.0 znajdziesz na stronie Pasamio Projec-t's FRS.

Natomiast polskie wydanie komponentu znajdziesz w składnicy Polskiego Centrum Jo-omla!

Komponent instalujemy w standardowy sposób w swojej witrynie Joomla 1.0.x, którą chcemy migrować (albo w Mambo 4.5.2):

• wybierz z menu zaplecza pozycję Insta-latory –> Komponenty;

• kliknij przycisk Przeglądaj i wskaż na dysku swojego komputera pakiet insta-lacyjny;

• naciśnij przycisk Wczytaj plik i zainstaluj.

Po chwili pojawi się komunikat o udanej in-stalacji, a w menu Komponenty znajdziesz nową pozycję –> Migrator. Wywołaj ją.

Na stronie otwierającej znajdziesz zwięzłą instrukcję oraz – na dole – zestaw odnośni-ków, pod którymi kryją się polecenia kom-ponentu lub ekrany z dodatkowymi infor-macjami.

Migrator przenosi do pliku migracyjnego tylko dane gromadzone w rdzennych tabe-lach Joomla!. Aby obsługiwał dane zgroma-

dzone przez komponenty rozszerzające Jo-omla!, potrzebuje dodatkowych wtyczek.

Krok 4: Doinstaluj wtyczki migracyjneNiestety, w tym miejscu – oprócz dobrej wia-domości – mamy i złą: udało nam się znaleźć jedynie wtyczki do komponentu JoomFish. Do innych – nawet śladu. Na dodatek te do JoomFish są tak ukryte, że trudno je znaleźć, nie mówiąc już o tym, iż trzeba wiedzieć, że istnieją. Zajrzyj do sekcji SVN.

Na szczęście, jest i dobra wiadomość: po-trzebne wtyczki szybko się projektuje i łatwo pisze nawet, jeśli nie mamy żadnych doświad-czeń w programowaniu. Można się zresztą bez nich obejść. Natomiast bez wtyczek dla JoomFisha byłoby trudno w przypadku, gdy mamy witrynę wielojęzyczną.

Do migracji danych z nierdzennych kom-ponentów potrzebne są dwa rodzaje wty-czek: ETL i SQL. Pierwsza, wtyczka SQL, jest zwykłym plikiem SQL z poleceniami tworzą-cymi potrzebne tabele. Druga, wtyczka ETL, jest skryptem PHP, generującym odpowied-nie wpisy w pliku SQL. Wtyczka ETL roz-szerza działanie klasy ETLPlugin tak, aby komponent obsługiwał przenoszenie innych danych, niż należące do rdzennych kompo-nentów.

Rysunek 1. Instalacja komponentu w Joomla 1.0

Rysunek 2. Strona główna komponentu Migrator. Zwróć uwagę, że odnośniki do narzędzi komponentu umieszczono na dole ekranu

Page 24: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200824

Narzędzia programistyczneMigracja Joomla 1.0 do 1.5

www.sdjournal.org 25

Wtyczka ETLWtyczki ETL są rzeczywiście niezwykle łatwe do napisania – zwykle wystarczy 5 linii kodu PHP. Przykłady znajdziemy wśród skryptów komponentu, w katalogu /plugins. Wzorcowy kod wtyczki ETL przedstawia Listing 1.

W pierwszej linii definiujemy nową kla-sę rozszerzającą klasę ETLPlugin{}. Następ-nie wywołujemy dwie metody – funkcję get-Name(), która zwraca wykorzystywaną przez komponent opisową nazwę przenoszonej tabe-li, oraz funkcję getAssociatedTable(), która do pliku migracyjnego przenosi zapytania tworzą-ce potrzebną tabelę i zapytania umieszczające w tej tabeli dane komponentu.

Doświadczeni programiści mogą stworzyć wtyczki bogatsze w funkcje, np. opuszczają-ce wskazane kolumny tabel (pola), zmienia-jące nazwy pól czy zmieniające wartości w kolumnach. Pełną listę metod znajdziemy w skrypcie migrator.class.php w definicji klasy

ETLPlugin{}, a przykłady zastosowania funk-cji znajdziemy w skryptach standardowych wtyczek ETL, umieszczonych w katalogu /plugins komponentu.

Aby samodzielnie przygotować potrzebne wtyczki ETL:

• skopiuj podany powyżej kod;• nazwę klasy zastąp nazwą tabeli;• napis Nazwa opisowa zastąp zwięzłym

opisem tabeli;• napis nazwatabeli zastąp rzeczywistą

nazwą tabeli (bez przyrostka jos_ czy in-nego);

• zapisz plik jako skrypt php nazwany: na-zwatabeli.php.

Uwaga: we wszystkich trzech przypadkach – nazwy klasy, opisowej nazwy tabeli i rze-czywistej nazwy tabeli można zastosować dokładnie taki sam tekst.

Pełny przykład skryptu wtyczki Adsmana-ger Ads ETL znajduje się na Listingu 2.

Wtyczka SQLWe wtyczkach SQL umieszczamy zapytanie SQL generujące potrzebną tabelę bazy da-nych. Przykład wtyczki SQL znajduje się na Listingu 3.

Stworzenie wtyczek SQL jest więc rzeczy-wiście banalnie proste – wykonujemy zrzut struktury swojej bazy danych Joomla 1.0, a następnie zapisujemy kod dla każdej tabeli w pliku nazwanym: nazwatabeli.sql

Dodajmy jeszcze, że niekoniecznie każ-dą wtyczkę trzeba zapisywać w odrębnym skrypcie. Wszystkie wtyczki dla jednego komponentu można zapisać w dwóch pli-kach – w jednym definicje klas ETL, w dru-gim kwerendy SQL.

Instalacja wtyczek Pojedyncze wtyczki można zainstalować za pomocą polecenia dostępnego w komponen-cie – jeśli masz tylko jedną czy dwie wtycz-ki, użyj formularza Instalacja rozszerzeń Mi-gratora:

Jeśli jednak masz więcej dodatków i dys-ponujesz dostępem do serwera, możesz przesłać pliki dodatków do ich poszczegól-nych katalogów (/plugins oraz /tables). Kom-ponent używa tylko plików, które istnieją w jego katalogach, więc rejestracja w bazie da-nych nie jest wymagana do zastosowania do-datku.

Krok 5: Stwórz plik migracyjny SQLPo zainstalowaniu wszystkich niezbędnych wtyczek, przystępujemy do właściwego za-dania – wygenerowania pliku migracyjnego SQL. W tym celu:

• na stronie startowej komponentu kliknij polecenie Utwórz plik migracyjny SQL;

• na dole kolejnej strony naciśnij polecenie Rozpocznij migrację.

Przez chwilę potrwa wykonywanie zadań, na ekranie dosłownie zamigoczą dwie stro-ny z informacjami o przebiegu operacji. I w końcu pojawi się komunikat o zakończeniu pracy z nazwą utworzonego pliku SQL i od-nośnikiem do strony z plikami do pobrania.

Po naciśnięciu odnośnika Pobierz pojawi się strona z listą plików migracyjnych. Można tu-taj stworzony plik pobrać lub usunąć. Etykie-ta odnośnika Informacja o SQL ma w zamy-śle projektanta prowadzić do podglądu pliku SQL, ale funkcja najwyraźniej nie została w wydaniu 1.0 zaimplementowana.

Uwaga: Oczywiście, podczas generowania pliku migracyjnego mogą zdarzyć się błędy w działaniu komponentu. Komponent wczytu-je dodane skrypty wszystkich wtyczek ETL i SQL i sprawdza ich poprawność. Jeśli napo-

Listing 1. Wzorcowy kod wtyczki ETL

<?php

class NazwaTabeli_ETL extends ETLPlugin {

function getName() { return “Nazwa opisowa”; }

function getAssociatedTable() { return “nazwatabeli”; }

}

?>

Listing 2. Przykładowy kod wtyczki ETL dla komponentu AdsManager

<?php

/**

* Adsmanager Ads ETL Plugin

* Wtyczka Adsmanager Ads ETL dla tabeli #__adsmanager_ads

* @package Migrator

* @author Stefan Wajda <[email protected]>

* @license GNU/GPL http://www.gnu.org/licenses/gpl.html

* @copyright 2008 Stefan Wajda

* @version SVN: $Id:$

*/

class Adsmanager_Ads_ETL extends ETLPlugin {

function getName() { return "Wtyczka ETL - Adsmanager ads"; }

function getAssociatedTable() { return 'adsmanager_ads'; }

}

?>

Listing 3. Przykład wtyczki SQL dla komponentu AdsManager, tworzącego tabelę

#__adsmanager_categories >>

CREATE TABLE IF NOT EXISTS `jos_adsmanager_categories` (

`id` int(10) unsigned NOT NULL auto_increment,

`parent` int(10) unsigned default '0',

`name` varchar(50) default NULL,

`description` varchar(250) default NULL,

`ordering` int(11) default '0',

`published` tinyint(1) default '0',

PRIMARY KEY (`id`)

) ENGINE=MyISAM;

Page 25: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200824

Narzędzia programistyczneMigracja Joomla 1.0 do 1.5

www.sdjournal.org 25

tka błędy, przerwie działanie i wyświetli od-powiedni komunikat.

II etap: Nowa witryna z przeniesionymi danymiDysponując plikiem migracyjnym, możemy przystąpić do II etapu pracy, obejmującego instalację Joomla 1.5 z danymi migracyjny-mi, dodanie rozszerzeń oraz testowanie no-wej witryny.

Krok 6: Zainstaluj Joomla! 1.5 z danymi migracyjnymiNową witrynę zakładamy w środowisku, w którym będzie ona działała, a więc zwykle na tym samym serwerze co witryna opar-ta na Joomla 1.0. Możemy zainstalować Jo-omla 1.5:

• w tym samym katalogu – zamiast dzia-łającej witryny;

• w podkatalogu, a tym samym w subdo-menie działającej witryny 1.0.

Dopóki jednak nie mamy pewności, że mi-gracja przebiegnie pomyślnie, dotychczaso-wa witryna powinna pozostać nienaruszona. Pierwsze rozwiązanie zatem raczej w rachu-bę nie wchodzi. Nową witrynę instalujemy w nowym, odrębnym katalogu, z nową bazą da-nych albo – jeśli dysponujemy tylko jedną ba-zą danych – z innym przedrostkiem nazw ta-bel. Ale nawet jeśli zdecydujemy się na zastą-pienie starej witryny nową instalacją, to:

• wszystkie pliki starej witryny przenosi-my w bezpieczne miejsce, np. do nowego katalogu;

• pliki instalacyjne umieszczamy w opróż-nionym, pustym katalogu.

W żadnym wypadku nie należy nadpisywać plików starej witryny, skryptami pakietu in-stalacyjnego Joomla 1.5.x. Jedyne, co może-my pozostawić w katalogu instalacyjnym z zasobów starej witryny, to pliki danych (np. grafiki) oraz skrypty szablonów. Wszelkie inne pozostałości mogą być źródłem niepo-prawnej instalacji i błędów w działaniu no-wej witryny.

Przypomnienie: jeśli jeszcze nie masz tego kroku za sobą, sporządź pełną kopię zapaso-wą istniejącej witryny, zarówno systemu pli-ków, jaki bazy danych. Kopię umieść w bez-piecznym miejscu tak, aby podczas testowa-nia nowej instalacji w ogóle nie mieć do niej dostępu.

Pierwsze pięć kroków wykonujemy tak, jak w przypadku zwykłej instalacji Joomla, a więc:

• wybieramy język instalacji;• przeglądamy informacje o środowisku

instalacyjnym;

• zapoznajemy się z licencją, jeśli jej nie znamy;

• konfigurujemy bazę danych;• konfigurujemy – jeśli jest nam potrzeb-

na – warstwę FTP.

Jeśli dysponujemy tylko jedną bazą danych, trzeba pamiętać, aby w 4. kroku ustalić uni-

kalny przedrostek nazw tabel, inny niż uży-wany w witrynie Joomla 1.0.

Po skonfigurowaniu bazy danych i – ewen-tualnie obsługi FTP – dochodzimy do mo-mentu, w którym finalizujemy migrację da-nych.

Komunikaty ekranowe na stronie Konfi-guracja witryny jasno i jednoznacznie infor-

Listing 4. Instrukcja usuwająca tabelę w pliku instalacyjnym .xml

<query>

DROP TABLE IF EXISTS `#__nazwa_tabeli`;

</query>

Listing 5. Instrukcja w pliku instalacyjnym .xml wstawiająca dane

<query>

INSERT INTO `#__nazwa_tabeli` VALUES (1,0,'Jakis_tekst','Jakis_tekst','',0,1,0);

</query>

Rysunek 3. Instalacja rozszerzeń Migratora. Prościej jednak przesłać skrypty wtyczek za pomocą FTP do katalogów /plugins i /tables

Rysunek 4. Na górze - komunikat o pomyślnym stworzeniu pliku migracyjnego. Na dole strona z listą plików migracyjnych do pobrania

Page 26: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200826

Narzędzia programistyczne

www.sdjournal.org 27

mują, że w tym kroku możemy umieścić w witrynie:

• Dane przykładowe;• a. Dane migracyjne ze skryptu SQL

zgodnego z Joomla 1.5;• b. Dane migracyjne ze skryptu SQL

zgodnego z Joomla 1.0.

Oczywiście, nas interesuje trzecia opcja – migracja ze skryptu zgodnego ze struktu-rą bazy danych Joomla 1.0 (a więc i Mambo 4.5.2). Dane migracyjne możemy wczytać ze skryptu SQL:

• przesłanego na serwer za pomocą proto-kołów FTP lub SCP;

• oczekującego na wczytanie za pośred-nictwem protokołu HTTP podczas in-stalacji.

Druga z metod jest wygodniejsza, ale nie za-wsze skuteczna. Zakończy się powodzeniem tylko wtedy, gdy przenosimy niewielką wi-trynę (plik migracyjny SQL jest mniejszy niż 2MB). Jeśli jest większy, trzeba go prze-słać na serwer za pomocą dowolnego klienta FTP lub SCP do katalogu /installation/sql/migration/. Przesyłany plik musi się nazy-

wać migrate.sql. Katalogi /installation/sql/migration/ oraz katalog podręczny (/tmp) muszą być udostępnione do zapisu dla użyt-kownika www ((np. wwwrun, www-data czy apache).

Aby poprawnie migrować dane:

• zaznacz opcję Dane ze skryptu;• w polu Przedrostek nazw tabel w po-

przedniej instalacji wpisz jos_, nawet je-śli był inny;

• podaj standard kodowania poprzedniej witryny – zwykle ISO-8859-2, rzadziej UTF-8;

• zależnie od wybranej metody: • naciśnij przycisk Przeglądaj i wskaż

plik ze skryptem migracyjnym SQL albo;

• zaznacz opcję Skrypt migracyjny jest na serwerze;

• zaznacz opcję: Skrypt migracyjny z Joom-la 1.0.;

• naciśnij przycisk: Wczytaj i uruchom.

Zauważ – w przypadku migracji z Joomla! 1.0 zawsze podajemy, że tabele w pliku mi-gracyjnym mają przyrostek jos_. Autor kom-ponentu Migrator, aby nie komplikować zbytnio swojego rozwiązania, przyjął takie

założenie – wszystkie nazwy tabel w pliku migracyjnym SQL generowanym przez kom-ponent mają przedrostek jos_. Nie oznacza to, że w nowej instalacji tabele muszą mieć również przedrostek jos_. Wręcz przeciw-nie – ustalasz go swobodnie, konfigurując bazę danych, o czym już wspominaliśmy.

Instalator podejmie próbę stworzenia ta-bel bazy danych i jeśli operacja się powie-dzie, otrzymamy na kolejnym ekranie stoso-waną informację.

Migracja nieudanaMoże się wszakże zdarzyć, że otrzymamy nie-zbyt radosny komunikat o napotkanych pod-czas migracji problemach. Jednym z częst-szych problemów jest niepoprawna struktura standardowej tabeli jos_users. Błąd pojawia się w przypadkach, gdy w starej witrynie ko-rzystaliśmy z komponentów, które zmieniają strukturę tej tabeli (należy do nich m.in. fo-rum Fireboard). W przypadku tej i ewentu-alnie innych zmodyfikowanych standardo-wych tabel bazy danych problem jest łatwy do rozwiązania. Trzeba w Joomla 1.0 powtó-rzyć tworzenie pliku migracyjnego, poprze-dzając tę czynność dodaniem wtyczki SQL z poleceniami tworzącymi zmodyfikowaną ta-belę. Pamiętamy, że stworzenie wtyczki SQL wymaga sporządzenia zrzutu bazy danych np. W programie phpMyAdmin i zapisaniu w odrębnym pliku instrukcji tworzących po-trzebną tabelę.

Zakończenie migracjiAby zakończyć instalację:

• naciśnij przycisk Dalej, co spowoduje po-wrót na stronę Konfiguracja witryny;

• w polu Nazwa witryny wpisz nazwę swojej witryny i ponownie naciśnij przy-cisk Dalej (danych administratora nie trzeba podawać);

• usuń katalog /installation (tymczasowo wystarczy zmienić jego nazwę).

Jeśli podamy nowe hasło i adres administrato-ra, instalator spróbuje je zmienić w bazie da-nych, ale operacja ta niekoniecznie musi się za-kończyć powodzeniem. Lepiej nie ryzykować!

Krok 7: Dodaj i skonfiguruj rozszerzeniaZanim zabierzemy się za dokończenie migra-cji, rozejrzyjmy się zarówno po witrynie, jaki zapleczu administracyjnym. Z łatwością za-uważymy, że w nowej witrynie:

• aktywny jest tylko moduł głównego me-nu, pozostałe moduły menu zniknęły bez śladu;

• nie ma żadnych treści udostępnianych przez niestandardowe komponenty;

• wszystkie pozycje menu odwołujące się

Rysunek 5. Krok 5 instalacji Joomla 1.5. – migracja danych

Rysunek 6. Krok 5 instalacji Joomla 1.5. – migracja danych – komunikat o powodzeniu migracji

Page 27: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200826

Narzędzia programistyczne

www.sdjournal.org 27

do niestandardowych komponentów są wyłączone;

• w menu Komponenty na zapleczu nie ma ani jednego niestandardowego kompo-nentu;

• na liście modułów i dodatków są tylko roz-szerzenia należące do rdzenia Joomla!

Czyżby migracja się nie powiodła? Wszak komunikat głosił, że się udała, co więcej – są niektóre treści, można się zalogować na zaplecze.

Oczywiście, że migracja przebiegła po-myślnie, ale Migrator:

• nie przenosi informacji o zainstalowa-nych dodatkowo rozszerzeniach oraz;

• wyłącza pozycje menu umieszczone w innych modułach niż menu główne (a więc np. usermenu, othermenu);

• na stronie frontowej pozostawia włączo-ny jedynie moduł głównego menu oraz nowy w Joomla 1.5 – ścieżki powrotu (breadcrumbs).

Stosunkowo łatwo można uaktywnić wyłą-czone pozycje menu i moduły. Wystarczy zaznaczyć je na listach i opublikować. Nie oznacza to jeszcze, że wszystko zadziała, jak oczekujemy - pozycje menu wywołujące tre-ści komponentów odwołują się do nieistnie-jących rozszerzeń. Nie wystarczy, że je doin-stalujemy. Trzeba jeszcze połączyć je z pozy-cjami menu.

Przed instalacją komponentówNie spiesz się, zwłaszcza gdy sporo czasu za-jęło Ci własnoręczne stworzenie wtyczek ETL i SQL, by migrować dane z komponen-tów. Instalatory wielu komponentów usuwa-ją swoje tabele, jeśli takie istnieją już w bazie danych. Możliwe są dwa rozwiązania:

• dokonać odpowiednich zmian w bazie danych - przed instalacją i po zainstalo-waniu komponentu;

• zmodyfikować pliki instalacyjne kompo-nentu.

Drugi ze sposobów wydaje się prostszy. Przed zainstalowaniem komponentu prze-glądamy plik nazwa_komponentu.xml (ewentualnie także nazwa_komponentu.po-lish.xml) i usuwamy z niego instrukcje na-kazujące usunięcie istniejących w bazie da-nych tabel. Instrukcje usuwające tabele znaj-dują się na Listingu 4.

Przy okazji warto również sprawdzić, czy nie ma instrukcji umieszczających przykła-dowe dane albo przykładowe kategorie. Takie instrukcje również nie są potrzebne - wszak mamy dane z poprzedniej witryny. Usuwamy zatem z plików instalacyjnych .xml instruk-cje wyglądające, jak na Listingu 5.

Po doinstalowaniu komponentówTrzeba je, oczywiście, skonfigurować:

• włączyć tryb zgodności wstecznej (legacy);• przywrócić ustawienia konfiguracyjne

ustalone w poprzedniej witrynie;• poprawić odwołujące się do nich pozycje

menu.

Tryb zgodności wstecznejAby komponenty i inne rozszerzenia napisa-ne dla Joomla 1.0 działały w Joomla 1.5, mu-si być włączony tryb zgodności wstecznej. Z menu zaplecza wybieramy pozycję Rozszerze-nia -> Dodatki, odszukujemy dodatek System - Spuścizna (System – Legacy) i w kolumnie Włączony naciskamy czerwoną ikonę z bia-łym krzyżykiem. W efekcie zmieni się ko-lor i kształt ikony (zielony haczyk), a w pa-sku informacyjnym po prawej stronie menu pojawi się informacja oznaczona ikoną Joom-la! o tym, że witryna działa w trybie zgodno-ści z 1.0.

Przywrócenie ustawień konfiguracyjnychWiele komponentów przechowuje swoje ustawienia w plikach konfiguracyjnych. Naj-prostszym sposobem przywrócenia ustawień dokonanych w poprzedniej wersji witryny jest więc odszukanie potrzebnego pliku kon-figuracyjnego i przekopiowanie go do odpo-wiedniego katalogu w Joomla 1.5. Zwykle jest to katalog /administrator/components/nazwa_komponentu, a plik nosi zwykle na-zwę config.nazwa_komponentu.php. W przypadku, gdy w pliku konfiguracyjnym znajdowały się wartości tekstowe (np. regula-miny), a witryna kodowana była w ISO-8859-2, konieczna może być wcześniejsza konwer-sja pliku do formatu UTF-8.

Krok 8. Popraw odwołania w menuDzięki nowej w Joomla 1.5 funkcji zmiany typu pozycji menu to zadanie jest niezwy-kle łatwe do wykonania. Nie musimy usuwać dawnych pozycji menu – wystarczy otworzyć je do edycji, nacisnąć przycisk Zmień typ i wskazać na liście doinstalowany wcześniej komponent, a następnie sprawdzić na stronie frontowej, czy wszystko działa należycie.

STEFAN WAJDAStefan Wajda [Zwiastun] jest liderem PCJ!, koordy-

natorem Zespołu Tłumaczy i Dokumentacji akre-

dytowanym przy Translation Work Group projektu

Joomla!, wydawcą witryn PCJ, autorem wpełni zlo-

kalizowanych wersji Mambo i Joomla!, komponen-

tów josDirectory i josResource. Spolonizował ponad

150 rozszerzeń dla Joomla!, opublikował w Interne-

cie około 600 artykułów poświęconych wszystkim

aspektom Joomla!.

Kontakt:[email protected]

Page 28: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200828

Testowanie oprogramowaniaByła sobie inspekcja

www.sdjournal.org 29

Pierwsze spotkanie z ISO 9001:2000 za-zwyczaj się wiąże ze sporym zaskocze-niem. Jesteśmy przyzwyczajeni do te-

go, że norma jest synonimem konkretu – za-wiera szczegółowy przepis, jest precyzyjna i jed-noznaczna. Natomiast jeden z początkowych paragrafów ISO 9001 brzmi: Wszystkie wyma-gania niniejszej normy międzynarodowej są uni-wersalne i mają być stosowane do wszystkich or-ganizacji, niezależnie od typu, wielkości i produk-tów [1]. To zdanie bardzo dobrze oddaje jej du-cha. ISO 9001 jest bowiem zbiorem wytycz-nych, a nie rozporządzeń, zawiera wymagania, a nie gotowe rozwiązania. Proces certyfikacji polega tu na stwierdzeniu, czy wymagania te są spełnione.

W podobny sposób skonstruowaliśmy nasz proces inspekcji. Sama definicja opisuje etapy inspekcji, wejścia i wyjścia dla każdego z tych etapów oraz techniki (narzędzia) pozwalające na osiągnięcie zadanych celów. W żaden spo-sób nie wskazuje kategorii zagadnień, do któ-rych proces inspekcji jest wykorzystany (typ), ich skali (wielkości) ani przedmiotu (produktu). Jednak za taką uniwersalność trzeba płacić do-datkowym wysiłkiem, który musi być poświę-cony na zastosowanie teorii do konkretnej po-trzeby. Mówimy wtedy o aplikacji procesu.

Procesy w projekcie (organizacji) nie działa-ją w izolacji. Operują na właściwych dla nich

przedmiotach, ale jednocześnie same są częścią większego systemu (projektu, organizacji). Iden-tyfikacja powiązań w takim systemie jest kluczo-wa dla jego prawidłowego funkcjonowania.

Te dwie płaszczyzny – aplikacja procesu in-spekcji i jego relacje z pozostałymi procesami – będą przedmiotem poniższych rozważań.

Od czego zacząć?Zgodnie z przyjętym założeniem oddzielenia de-finicji procesu od jego aplikacji, niniejsze opraco-wanie składa się z trzech części – przygotowa-nia, definicji procesu oraz uwag do jego aplika-cji. Części te stanowią obraz wyzwania, z którym przyjdzie Wam się zmierzyć. I tak: przygotowanie wprowadza w temat, dostarcza podstawowego słownictwa koniecznego do zrozumienia defi-nicji procesu. Definicja procesu stanowi model, zawiera metodykę na tyle ogólną i uniwersalną, aby pasowała do systemu jakości obowiązującego w Waszej organizacji. Zadaniem trzeciej części, będącej przedmiotem tego artykułu, jest użycie procesu inspekcji w projekcie, którego produk-tem jest oprogramowanie, a przedmiotem in-spekcji – kod źródłowy (Tabela 1).

Aplikacja procesuDefinicja procesu inspekcji zakłada istnienie czterech etapów – analizy, naprawy, weryfika-cji oraz ulepszania. Dla każdego z tych etapów zdefiniowaliśmy warunki rozpoczęcia (wejścia) oraz techniki, których zastosowanie zaowocuje odpowiednimi rezultatami (wyjściami). Dzięki takiej definicji poszczególne etapy inspekcji sa-me stały się procesami. Powiązanie między ni-mi uzyskaliśmy poprzez uzależnienie rozpo-

częcia każdego z etapów od wyników poprzed-niego (Rysunek 1). Stąd, podstawowa ścieżka zadań inspekcyjnych:

• analiza przedmiotu inspekcji (np. kodu źródłowego); dokonywana przez inspek-tora;

• przetwarzanie komentarzy i wprowadza-nie poprawek, wykonywane przez autora;

• weryfikacja poprawek przez inspektora;• ulepszanie procesu, który może postu-

lować każdy z członków zespołu inspek-cyjnego.

Na każdym etapie dodatkowo istnieją możli-wości konsultacji między członkami zespołu inspekcyjnego (rozdział Konsultacje).

Ścieżce zadań towarzyszy odpowiedni prze-pływ informacji:

• komentarze są wynikiem analizy kodu źródłowego;

• przekazywane są autorowi do rozpatrze-nia (etap naprawy);

• jeżeli komentarze nie są jednoznaczne (trudno określić źródło zastrzeżeń, ziden-tyfikować odpowiedni fragment kodu) ko-nieczna jest dodatkowa konsultacja z in-spektorem. Może się okazać, że inspek-tor źle zrozumiał analizowany fragment i komentarz będzie odrzucony lub przeka-zany do ponownego sformułowania (tzn. analiza musi być przeprowadzona ponow-nie). Jeżeli komentarz jest zasadny, od-zwierciedla rzeczywisty problem, zgłoszo-ny zostanie PR (ang. Problem Report). Jeże-li komentarz odnosi się do zmiany lub do-dania funkcjonalności – odpowiednio bę-dzie zgłoszony CR (ang. Change Request) lub REQ (ang. Requirement);

• autor rozwiązuje PR. CR i REQ będą roz-patrzone w trakcie projektowania następ-nych wersji produktu;

• poprawiony przedmiot jest przedstawiany

Była sobie inspekcja

W pierwszej części artykułu zdefiniowaliśmy proces inspekcji. Używając podejścia PDCA (ISO 9001, PMBok) osiągnęliśmy elastyczność, skalowalność i uniwersalność. Teraz nadszedł czas na wykorzystanie teorii do konkretnego zadania – inspekcji kodu źródłowego.

Dowiesz się:• Jak aplikować proces inspekcji do kodu źró-

dłowego;

• Jak efektywnie zarządzać inspekcją;

Powinieneś wiedzieć:• Definicja procesu inspekcji;

• Podstawy zarządzania projektami;

• Podstawy planowania jakości.

Poziom trudności

Aplikacja procesu inspekcji

Page 29: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200828

Testowanie oprogramowaniaByła sobie inspekcja

www.sdjournal.org 29

inspektorowi do weryfikacji. Nie musi to jednak być ten sam inspektor, który doko-nywał analizy. Rolę inspektora może rów-nież spełnić narzędzie do statycznej anali-zy kodu (rozdział Wykorzystanie narzędzi);

• przedstawione do weryfikacji rozwiąza-nie komentarza może nie odpowiadać wyobrażeniom inspektora lub mieć wady uniemożliwiające jego wdrożenie. Należy wtedy powtórzyć naprawę. Może się jed-nak zdarzyć, że rozwiązanie nie zostało zrozumiane przez inspektora i po konsul-tacji będzie zaakceptowane;

• posiadając listę zgłoszonych komentarzy, oceniamy ich jakość i wagę (rozdział Mia-ry projektowe i procesowe). Na podstawie wyciągniętych wniosków wprowadzamy ulepszenia.

Proszę zwrócić uwagę, że w trakcie każdego z etapów, komentarze są uzupełniane o odpo-wiednie informacje, np. status (z nowy na od-rzucony, odroczony lub zaakceptowany), akcje, jakie powinny być podjęte (np. zgłoszony PR, CR lub REQ) itp. Tak uzupełniany rejestr ko-mentarzy jest ważną częścią dokumentacji projektowej.

Role a zasobyW dotychczasowych rozważaniach odnosili-śmy się do trzech podstawowych ról – kierow-nika inspekcji, inspektora oraz autora.

Rola kierownika inspekcji jest szczególna. To jego zadaniem jest przystosowanie procesu in-spekcji do potrzeb projektu. Biorąc pod uwa-gę istniejące ograniczenia projektowe (osiągal-ność zasobów, dojrzałość produktu, jego przy-szłe plany rozwoju), musi on zdecydować, któ-re techniki będą najbardziej odpowiednie, jakie strategie należy zastosować (np. jakie perspek-tywy, początkowe listy kontrolne). Kierownik inspekcji jest również odpowiedzialny za śle-dzenie postępów, zbieranie i rozsyłanie komen-tarzy, zarządzanie dokumentacją procesu oraz dostarczanie miar procesowych i projektowych menadżerowi projektu. Do jego zadań nale-ży również ocena i wprowadzanie usprawnień procesu, perspektyw i list kontrolnych.

Dobrym kandydatem do tej roli jest zatem kierownik techniczny lub architekt projektu. Posiadana przez nich znajomość projektu po-zwoli na rozstrzyganie ewentualnych rozbież-ności w opiniach inspektorów (w ramach kon-sultacji). Doświadczenie pomoże w dostrzeże-niu ogólnych reguł, wyborze standardów i pro-mowaniu najlepszych praktyk implementacji (ang. best practises).

Najbardziej wymagającą jest rola inspektora. Osoba przyporządkowana do tego zadania mu-si dysponować najbardziej specyficznymi pre-dyspozycjami. Chodzi tu nie tylko o eksperta w rzemiośle, ale również o osobę charakteryzują-cą się samodzielnością, samodyscypliną, otwar-tością i komunikatywnością. Jest to wymagane,

szczególnie gdy w ramach oszczędności czasu i zasobów, decydujemy się na ograniczenie for-malizacji procesu inspekcji. Zalecamy, aby in-spektorzy byli wybierani spośród najbardziej doświadczonych osób w zespole.

Również odpowiednie przyporządkowanie roli autora może nie być łatwe. W dużym pro-jekcie pracę wykonuje się zbiorowo, kod jest tworzony przez wielu deweloperów i wielokrot-nie przerabiany. Rzadko można zidentyfikować osobę, która napisała dany fragment kodu (tzn. fizycznego autora). Rolę autora w inspekcji nale-ży więc traktować wirtualnie. Może to być osoba odpowiedzialna za dany moduł, ekspert w kon-kretnym aspekcie funkcjonowania produktu. Często jednak do tej roli wybiera się po prostu jednego z członków zespołu projektowego, być może zajmującego się aktualnie rozwojem innej części produktu. Taki autor będzie potrzebował dodatkowego czasu na zapoznanie się z komen-towanym fragmentem. Z drugiej strony podnosi to poziom świadomości kodu w zespole.

Ilość ról oraz zakres przyporządkowanych im obowiązków mogą być różne w zależności od przyjętej techniki inspekcji (por. inspekcja for-malna). Należy się jednak dobrze zastanowić, czy zwiększanie ilości ról jest opłacalne. Wię-cej ról wymaga większego zespołu inspekcyjne-go. Gdy zabraknie zasobów, jednej osobie będzie przyporządkowywane kilka różnych ról. Roz-mywa to odpowiedzialność, wymaga rozwiązy-wania konfliktów interesów oraz dzielenia cza-su między zadaniami. Jeżeli możliwe jest skom-pletowanie odpowiednio dużego zespołu, radzi-my zwrócić szczególną uwagę na sposób prowa-dzenia konsultacji. Jak stwierdza prawo Brook-sa [5], ilość interakcji między członkami zespo-łu (tu: inspekcyjnego) ma negatywny wpływ na

terminowość wykonania zadania (tu: analizy, na-prawy, weryfikacji, ulepszania). Związane jest to z koniecznością doszkalania (każdy członek ze-społu zna inny fragment kodu, a w dyskusji nad komentarzami uczestniczą wszyscy) oraz cza-sem, jaki wymagają interakcje i zarządzanie nimi (rozdział Konsultacje). Operowanie za pomocą małych, dobrze wyspecjalizowanych zespołów, może tu być o wiele efektywniejsze.

W opracowaniu założyliśmy, że uczestnicy procesu inspekcji rekrutują się z zespołu pro-jektowego pracującego nad przedmiotem in-spekcji. Źródłem członków procesu inspekcyj-nego mogą być jednak nie tylko osoby bezpo-średnio zaangażowane w jego rozwój. Często zatrudnia się w tym celu np. menadżera ds. ja-kości (ang. quality officer), specjalistów od two-rzenia dokumentacji technicznej (ang. technical writer), przedstawicieli klienta i innych. Zaspo-kajanie zasobów może również odbywać się w ramach outsourcingu. Należy wtedy pamiętać o konieczności zawarcia odpowiednich umów re-gulujących zachowanie tajemnicy (ang. non-di-sclosure agreement, NDA).

Rola menadżera projektuOpinie, jakie często słyszymy na temat roli me-nadżera projektu w procesie inspekcji, stawia-ją sprawę jasno – trzymać ich jak najdalej! O ile można zgodzić się, że wpływ na kształt inspek-cji (np. perspektywy) powinien mieć jedynie zespół inspekcyjny, o tyle przydział czasu i zaso-bów (harmonogram, budżet) leży wyłącznie w gestii menadżera projektu.

W idealnym świecie, przyjmując jakość za najwyższe kryterium akceptacji, powinniśmy usprawniać bezustannie. Jedynie produkt o nie-spotykanej jakości byłby w stanie zaspokoić wy-

Tabela 1. Przewodnik po przygotowaniu, procesie inspekcji i jego aplikacji

Przygotowanie Proces inspekcji Zagadnienia aplikacji

Procesy Podejście procesowe w obrębie po-szczególnych etapów inspekcji

Aplikacja procesuMiary projektowe i procesoweWspółpraca między procesami

Role Powiązanie ról z zadaniami dla po-szczególnych etapów inspekcji

Role a zasobyRola menadżera projektu

Techniki inspekcji Wykorzystanie technik inspekcji w procesie inspekcji:• role a etapy w inspekcji;• przepływ zadań i komunikacja między członkami zespołu inspek-cyjnego.

Ograniczenia technik inspekcjiAdaptacja technik inspekcjiWykorzystanie narzędziKonsultacje

Strategie inspekcji: perspektywy

Organizacja inspekcji z wykorzysta-niem perspektyw:• analiza zgodnie z perspektywą; • ulepszanie: dodawanie perspek-tyw w zależności od potrzeb, uści-ślanie aspektów, zakresu i celów per-spektyw.

Wykorzystanie perspektywUlepszanie perspektyw

Strategie inspekcji: li-sty sprawdzające

Organizacja inspekcji z wykorzysta-niem list sprawdzających:• analiza zgodnie z listami spraw-dzającymi; • ulepszanie: uzupełnianie list w oparciu o wyniki inspekcji

Budowanie list sprawdzającychUlepszanie list sprawdzających

Page 30: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200830

Testowanie oprogramowaniaByła sobie inspekcja

www.sdjournal.org 31

magania klientów. Ci, wytrwali w swoim poszu-kiwaniu ideału, płaciliby cierpliwie za kolejne iteracje inspekcji. Kompromis między jakością i czasem nie byłby nawet brany pod rozwagę.

Oczywiście nie żyjemy w idealnym świecie. Wszelkie opóźnienia w dostarczeniu produktu nie są akceptowalne (ang. time to market). Me-nadżer projektu jest osobą, która musi się z po-dobnymi kompromisami zmierzyć.

To właśnie przekonanie o konieczności do-konywania wyboru między czasem/zakresem/kosztami a jakością podsuwa pomysły unikania zaangażowania menadżerów w inspekcję kodu. Ich rola ograniczana jest do popychania projek-tu do przodu z dnia na dzień. Natomiast in-spekcja nakazuje zatrzymać się na chwilę i po-myśleć – rozważyć potencjalne skutki. Mene-dżerzy zaś wydają się pierwszymi z tych, któ-rzy w obliczu zbliżającej się publikacji gotowi są poświęcić długofalowe zyski na korzyść szyb-kich (tymczasowych) korekt pozwalających na dotrzymanie terminów.

Jest to oczywiście prawda. Cała sztuka polega jednak na tym, aby podobnych wyborów nie trze-ba było dokonywać. Chodzi tu o podejście, gdzie proces tworzenia produktu jest skonstruowany w sposób, który będzie gwarantował najwyższą jakość. Jakość nie może być jedną z sił w projek-cie – powinna być wynikiem operowania zakre-sem, czasem i kosztami. Mądry menadżer to wie. Zamiast wymawiać się brakiem czasu i zasobów – promuje techniki osobistej inspekcji, planuje inspekcje kompletne wprzód, poszczególne eta-py inspekcji wplata pomiędzy aktualnie wykony-

wane zadania. Wykorzystuje perspektywy, łączy je z zadaniami rozwoju i naprawy produktu (co zwiększa możliwości harmonogramowania).

Menadżer jest również interfejsem zespołu na zewnętrzny świat. Jego zadaniem jest prze-konanie szefa produktu co do słuszności dzia-łań zespołu inspekcyjnego. Nie chodzi o samą ideę – podnoszenie jakości zawsze się opłaca. Chodzi o znalezienie odpowiednich argumen-tów, które połączą świat inżynierów i biznesu (robienia rzeczy dobrze i robienia dobrych rze-czy – wysokiej jakości i produktów, które moż-na sprzedać [3]). Zadaniem szefów produktu jest postrzeganie projektu przez kontekst szer-szego programu, celów biznesowych organiza-cji. Jakość jest tym, co klienci zakładają, nowa funkcjonalność – tym, czego potrzebują, co po-zwala na zdobywanie rynku.

Potraktujmy więc proces inspekcji jako zmia-nę spotykającą się z oporem przed jej wprowadze-niem. Spójrzmy na nierówność Gleichera [4]:

Dissatisfaction * Vision * First steps >

Resistance to change

Aby przezwyciężyć opór przed zmianą (ang. resistance to change) należy:

• wykazać, że obecny stan nie jest zadowala-jący (ang. dissatisfaction);

• pokazać, jakie pozytywne efekty można oczekiwać (ang. vision);

• przedstawić kroki wymagane do osiągnię-cia tych efektów (ang. first steps).

Niezadowolenie z istniejącego stanu rzeczy mo-że wynikać np. z niespójności kodu, trudności w utrzymywaniu brudnego kodu, błędami wyko-nania, których źródłem są niedostatki w rzemio-śle. Sposobem na rozwiązanie takich problemów jest przeprowadzenie inspekcji kodu. Pierwszy-mi krokami będą analiza istniejących proble-mów, wprowadzenie ich śledzenia i rozpoczę-cie inspekcji. Menadżer wykluczony z procesu inspekcyjnego nie będzie potrafił poprzeć tych działań odpowiednimi argumentami.

Rola menadżera projektu nie kończy się jed-nak na planowaniu. Jest on również odpowie-dzialny za funkcjonowanie zespołu w wymiarze czysto ludzkim. Jego zadaniem jest zapewnienie odpowiedniej atmosfery w pracy, utrzymywa-nie relacji osobistych na poziomie koleżeńskim, przeciwdziałanie konfliktom. Niestety inspekcja kodu niesie za sobą ryzyko przerodzenia się w po-lowanie na czarownice. Wymagane jest więc, aby członkowie zespołu odnieśli się do niej obiek-tywnie, a nie w kategoriach osobistych. Niedo-zwolone są tu analizy zgłaszanych komentarzy względem fizycznego autora kodu. Nie przynio-są one żadnej nowej wiedzy na temat produktu, a mogą doprowadzić do niepotrzebnych napięć w zespole. Zastosowanie ma tu idea programo-wania bezosobowego (ang. egoless programing, zob. [6], [7]). Idea ta opiera się na traktowaniu wyni-ków własnej pracy poprzez pryzmat celu (pro-duktu). Chodzi tu o świadomość, że tworzymy kod nie dla siebie, ale dla innych. Praca, którą wy-konujemy, nie ma na celu zaspokojenia naszych ambicji. Ma służyć wyższemu dobru; tu: jako-

Rysunek 1. Zadania w kontekście ról i etapów inspekcji

��������������������������

������������������� ��������� ����� ������������

�������

�������

�����������

����������

����������������������

������������

�������������������������������������

�����������

���������������������

������������������

�����������������������

�������������������������������

�����������

����������������������

�����������

�������������������

������������

�������� �������� �������������������������������������������������

�������������������������������������������������������������������������������

��������

������������

��������

���������������������������

��������������������

���������

��������������

���������������������������

���������

�������������

�����������

������������

������������������������

���������������������

��������������

���������������������

�������������������

������������������

�����������

�������������������

����������

��

���

��

���������

������

����������

��������������

��������������

�����������������������

����������������������

����

��������

����������

������������������������

�����������������������

Page 31: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200830

Testowanie oprogramowaniaByła sobie inspekcja

www.sdjournal.org 31

ści, powodzeniu produktu. Taka zmiana punk-tu widzenia owocuje bardziej obiektywnym po-dejściem, otwartością na propozycje zmian, go-towością do uczenia się, czerpania z doświad-czeń innych. Nie ma to nic wspólnego z umniej-szaniem własnej wartości – raczej z ukierunko-waniem się na podnoszenie kwalifikacji. Jest to najlepszy sposób, aby zdać sobie sprawę ze słabo-ści, niedostatków w wiedzy i umiejętnościach i otrzymać szansę na szybkie ich nadrobienie. A przecież właśnie to jest jednym z podstawowych celów inspekcji.

Ograniczenia technik inspekcjiCzy możliwe jest bezbolesne wkomponowanie inspekcji kodu w procesy projektowe? Podsta-wowym ograniczeniem jest tu ilość dostępnego czasu i zasobów. Nie ma jednak konieczności ro-bienia całej inspekcji na raz. Skuteczną prakty-ką jest ograniczenie liczności zespołu inspekcyj-nego (zaangażowanych zasobów) oraz poświęca-nie na zadania inspekcyjne nie więcej niż 2 go-dziny dziennie. Inspekcja wymaga bardzo dużej koncentracji, której nie da się utrzymywać przez dłuższy czas. Dodatkowo ograniczamy ilość li-nijek kodu przeglądanych dziennie. Rozsądną granicą jest 200 – 400 linii [8]. Przeglądnięcie 2000 linijek w 2 godziny oznacza, że inspektor poświęcił niecałe 4 sekundy na każdą linijkę. Jest to bardzo pobieżna inspekcja, być może ograni-czoną jedynie do zaliczenia listy sprawdzającej. Mówimy tu przecież o kodzie źródłowym, któ-ry nie jest naturalnym językiem ludzi.

Planowane i kontrolowane zastosowanie po-wyższych ograniczeń nie powinno spowodo-wać większych opóźnień w projekcie. Z drugiej strony efekty wprowadzanych zmian nie będą tak spektakularne. Często nawet trudno będzie wykazać, w jakim stopniu poprawa jakości pro-duktu (wyrażona np. w procentowym powo-dzeniu testów regresyjnych) zawdzięczana jest inspekcji, a w jakim regularnemu usuwaniu błędów znalezionych na podstawie analizy dy-namicznej. Sposób ten jednak jest dobrym kro-kiem w stronę uczynienia inspekcji regular-ną praktyką projektową. Członkowie zespołu, przyzwyczajeni do takiego trybu pracy, z cza-sem zaczną realizować zadania inspekcji sami z siebie w ramach inspekcji osobistej [2].

W zaawansowanym stadium projektu, za-kres przedmiotu inspekcji może się okazać cał-kiem spory. Dla 100 tysięcy linijek kodu i dwóch inspektorów przeglądających po 400 linijek dziennie – będziemy potrzebowali co najmniej 6-7 miesięcy, aby przejrzeć całość (plus urlopy i zwolnienia). Stosowanie perspektyw wspar-tych listami kontrolnymi proces ten znakomi-cie usprawni. Przykładowo, jeżeli obserwujemy wiele problemów związanych z nieodpowied-nim zarządzaniem pamięcią – skoncentrujmy się najpierw na perspektywie rozpatrującej alo-kację i zwalnianie pamięci. Sprawdźmy operacje na buforach (kopiowanie, zerowanie) oraz po-prawność obsługi błędów z tym związanych.

Kolejnym sposobem na ogarnięcie dużej ilo-ści kodu jest użycie narzędzi do analizy statycz-nej. Rozpatrywanie ostrzeżeń kompilatora (np. GCC), uwag zgłaszanych przez narzędzia typu Lint, Valgrind jest bardzo efektywnym sposo-bem znajdywania niektórych kategorii proble-mów (rozdział Wykorzystanie narzędzi).

Istotny jest również wybór sposobu przegląda-nia kodu. Użycie metodologii z góry na dół (ang. top-to-bottom) wymaga dostarczenia poprawnej dokumentacji projektowej. Wszyscy wiemy, że nie zawsze jest to wymaganie realistyczne. Czę-sto zdarza się, że dokumentacja nie jest ani aktu-alna, ani kompletna. Inspekcja jest doskonałym momentem na uzupełnienie jej! W miarę zagłę-biania się w szczegóły funkcjonowania produk-tu, można aktualizować dokumentację, tak aby odpowiadała stanowi faktycznemu.

Jeżeli braki w dokumentacji nie pozwala-ją nam swobodnie przechodzić od ogółów do szczegółów, korzystniejsze jest podejście od do-łu do góry (ang. bottom-to-top). Zaczynanie od szczegółów, od warstw najniższych, pozwala ograniczyć wymagany zakres wiedzy. Pozwa-la angażować członków zespołu o mniejszych umiejętnościach lub mniejszej znajomości pro-duktu. W miarę wspinania się na coraz wyższe poziomy, wiedza (a wraz z nią dokumentacja) jest uzupełniana. Wiąże się to z ryzykiem utra-ty z oczu szerszego kontekstu. Uwzględniając jednak zysk w postaci zapewnienia solidnych podstaw, jest to również podejście skuteczne.

Adaptacja technik inspekcji Porównując ograniczenia projektowe i właści-wości technik inspekcji [2], możemy wybrać z

nich elementy najbardziej nam odpowiadają-ce. W obliczu ograniczonych zasobów, bardziej skłonni będziemy wykorzystywać techniki an-gażujące mniejszą ich ilość. W tym kontekście najkorzystniejsza jest inspekcja osobista (Tabe-la 2). Większość błędów będzie wykryta, zanim zostaną dodane do produktu.

Odpowiedzią na ograniczenia czasowe jest uży-wanie narzędzi do analizy statycznej kodu. Anali-za przez nie wykonywana jest bardzo szybka i po-wtarzalna (rozdział Wykorzystanie narzędzi).

Znaczne straty na czasie będą rezultatem niepoprawnie prowadzonych konsultacji. Na-leży więc dokładnie przemyśleć okoliczności i sposoby ich prowadzenia. Krótki email może wyjaśnić wątpliwości i znacznie usprawnić pra-cę. Przedłużające się w nieskończoność posie-dzenie całego zespołu nie doprowadzi do żad-nych wniosków (rozdział Konsultacje).

Zdecydowanie, pomimo dodatkowych na-kładów zasobów i czasu, należy podjąć starania o formalizację dokumentacji procesu inspekcji. Jest to konieczne do odpowiedniego planowa-nia, śledzenia postępów w pracy, rozumienia wprowadzonych zmian i powodów, dla których zdecydowano się na nie.

Rozważania nad adaptacją technik inspekcji należy uzupełnić o kwestie dynamiki projektu, jego potrzeb. Projekt silnie rozwijany, wzboga-cany o coraz to nowe funkcje, wymaga zwięk-szenia dokładności inspekcji osobistych oraz tych dokonywanych w zakresie dodanego ko-du. Celem będzie tu udowodnienie, że nowe elementy mają odpowiednią jakość i pasują do całości rozwiązania. Projekt stabilny, w któ-rym głównym zadaniem jest podnoszenie jako-

Tabela 2. Adaptacja technik inspekcji

Technika Stopień użycia Elementy użyte Elementy zaniechane/zmienione

Cały zespół

Formalna Ograniczone • formalna dokumentacja Zaniechane:• spotkania całego zespołu;• mnogość ról w zespole in-spekcyjnym;Zmienione:• autor wirtualny;

Inspektor+Autor

Jeden na jeden Częste • konsultacje bezpośred-nio między inspektorem i autorem;• konsultacje mało for-malne;

Zmienione:• konsultacje obowiązkowo dokumentowane (email, notat-ka, wpis w Bugzilli)

Wspomagana narzędziami

Obowiązkowe • integracja narzędzi do analizy statycznej z konfi-guracją projektu;• uzgodniony sposób inter-pretacji wyników;

Autor

Osobista Obowiązkowe • autor dokonuje osobiście inspekcji fragmentu przed dodaniem do całego roz-wiązania;• błędy są wyłapywane na poziomie lokalnym;

Zmienione:• uzupełnianie dokumenta-cji na podstawie inspekcji oso-bistej;

Page 32: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200832

Testowanie oprogramowaniaByła sobie inspekcja

www.sdjournal.org 33

ści, wymagać będzie więcej inspekcji komplet-nych, sprawdzających jak zachowują się różne aspekty rozwiązania. Z kolei inspekcja projek-tu tuż przed publikacją będzie bardziej formal-na, gdyż jej celem jest dostarczenie miar jakości charakteryzujących produkt.

W ramach technik inspekcji operujemy więc – celami, stopniem formalizacji, zakresem oraz ilością inspektorów w stosunku do ilości autorów. Zmiana wartości i wagi tych parametrów jest do-konywana na podstawie potrzeb projektu.

Wykorzystanie perspektywPodstawową strategią wykorzystywaną w pro-ponowanym procesie inspekcji są perspektywy. Pozwalają one skoncentrować uwagę inspekto-ra na pojedynczym aspekcie kodu źródłowego. Zamiast szukać wszystkich możliwych proble-mów, inspektor patrzy na jedną, charaktery-styczną cechę kodu. Pod uwagę brany jest je-dynie materiał określony zakresem perspekty-wy. Zadaniem inspektora jest osiągnięcie wy-znaczonego, mierzalnego celu. Te trzy wartości – aspekt, zakres oraz cel – muszą być uwzględ-nione w opisie perspektywy.

Spróbujmy skonstruować perspektywę, która używa Lint'a – narzędzia do statycznej analizy kodu źródłowego. Aspekt tej perspektywy będzie dotyczył przeglądania kodu w poszukiwaniu od-stępstw od standardów kodowania. Standard ko-dowania odnosi się nie tylko do np. nazewnictwa funkcji, wyglądu kodu (formatowania pliku, ko-mentarzy), ale również do konkretnych elemen-tów rzemiosła – np. inicjowania zmiennych, eks-portowania funkcji, weryfikacji argumentów. Ponieważ niektóre z tych elementów mogą być w różnych standardach różnie definiowane, ko-nieczne jest odpowiednie skonfigurowanie Lin-ta. W pliku konfiguracyjnym określimy stan-dardy, zgodnie z którymi kod ma być sprawdza-ny (np. ANSI C, ISO C, C99), zakres kodu, jaki ma być poddany analizie oraz poziom restrykcyj-ności narzędzia (ilość i rodzaj zgłaszanych uwag, poziom ich wyzwalania).

W zakres inspekcji wchodzi zazwyczaj cały do-stępny kod (inspekcja kompletna). Zdarzają się jednak projekty, które wykorzystują moduły po-chodzące od innych dostawców (ang. third party).

Poprawianie ich może nie być możliwe lub nie le-żeć w interesie projektu (np. zmiana spowodowa-łaby przejęcie odpowiedzialność za nie). Zakres jest wtedy odpowiednio ograniczany. Podobnie, ze względu na harmonogram prac, niektóre z mo-dułów będą analizowane w pierwszej kolejności.

Duża ilość uwag zgłaszanych przez Lint'a wy-musza precyzyjne określenie celu. W ramach opisu perspektywy należy podać:

• jakie kategorie uwag nas interesują?• jaka waga uwag nas interesuje?• jakiego mierzalnego efektu się spodzie-

wamy?

Dla przykładu – podczas analizy powiązań między modułami, interesują nas uwagi doty-czące złego włączania nagłówków (problemy ze słowem kluczowym extern, wielokrotne inkluzje itp.). Poszukujemy jedynie uwag kry-tycznych, ignorując ostrzeżenia i informacje. Naszym celem jest zlikwidowanie wszystkich uwag krytycznych (zob. kryterium S.M.A.R.T w rozdziale Konsultacje).

Inną zaletą stosowania perspektyw jest moż-liwość estymacji pozostałej ilości pracy. Konty-nuując przykład z Lintem – już po kilku dniach będziemy widzieli, że usunięcie 10 uwag zaj-muje średnio godzinę. Na tej podstawie mo-żemy przypuszczać, ile czasu zajmie usunię-cie reszty uwag (ang. duration). Niestety z na-szych obserwacji wynika, że na pierwszy ogień idą uwagi najprostsze do usunięcia. Zastosowa-nie może tu mieć reguła Pareto stwierdzająca, że 80% pracy zajmuje 20% czasu. Szacunki uzy-skane na podstawie wykonania części perspek-tywy mogą być więc bardzo zgrubne. Jest to jednak i tak więcej niż uzyskamy w podejściach polegających na jednoczesnej analizie wszyst-kich możliwych problemów.

Używanie perspektyw ułatwia również ra-portowanie postępu prac. Z punktu widze-nia menadżera projektu (a właściwie public re-lations) prezentowanie informacji 10% kodu poddano inspekcji jest o wiele mniej komforto-we niż komunikat – przeglądnięty został 100% nagłówków (mimo że owe nagłówki mogą fak-tycznie stanowić 10% całości kodu). W drugim

przypadku komunikujemy konkretny sukces (wszystkie pliki nagłówkowe sprawdzone), za-kończenie pewnego etapu, punkt, w którym się znajdujemy. Podobnie spektakularne są rapor-ty z usuwania uwag Lint'a, np. w wersji 2.0 było 1431 uwag, teraz mamy jedynie 302. Postęp im-ponujący, być może wystarczy na usprawiedli-wienie, dlaczego nadal pozostało 300 uwag.

Perspektywy nie będą jednak skuteczne, jeże-li zaniechamy ich stałego uzupełniania do sta-nu produktu i wymagań formułowanych jego względem.

Ulepszanie perspektywProdukt, przedmiot perspektywy, ciągle się zmie-nia. Dodawane są do niego coraz to nowe funkcje, kod jest większy, stawiane są mu coraz bardziej wygórowane wymagania. Perspektywy muszą za takimi zmianami nadążać. Muszą obejmować co-raz to nowe aspekty, dostosowywać swój zakres, zaostrzać stawiane cele. Ulepszanie perspektyw jest procesem koniecznym. Jeżeli zostanie zanie-dbane, w niedługim czasie będą odnosić się one do nieistniejącego przedmiotu. Analiza opierana na nich będzie bezprzedmiotowa.

Innym impulsem do ulepszania perspek-tyw są wnioski z ich przeprowadzenia. Jeżeli inspektor zauważa, że niektóre aspekty nale-ży uściślić lub rozwinąć, opis perspektywy po-winien zostać odpowiednio zmieniony. Może się również okazać, że wybrany zakres skutku-je jedynie lokalną poprawą – w dziedzinie ca-łego produktu postęp nie jest dostatecznie za-dowalający.

W trosce o to, aby aspekt perspektywy nie stał się zbyt ogólny, zestaw perspektyw z cza-sem jest rozszerzany. Przykładowe perspekty-wy mogą odnosić się do:

• używania pamięci, gdzie sprawdzamy alo-kacje i zwalnianie pamięci, zarządzanie błędami;

• wielowątkowości, gdzie sprawdzamy, jak w kodzie realizowane jest zarządzanie wątkami;

• powiązań w kodzie, gdzie analizujemy, jak poszczególne moduły rozwiązania współ-pracują ze sobą, jak są separowane, czy funkcje są potrzebnie eksportowane;

• redundancji w kodzie, gdzie sprawdzamy czy przypadkiem niektóre funkcje nie są duplikowane, implementowane wielokrot-nie lub niewykorzystywane;

• przenośności kodu, gdzie sprawdzamy czy kod może jest tak samo interpretowany na różnych platformach (używanie typów na-tywnych, wyrównywanie typów wylicze-niowych w pamięci);

• komentarzy w kodzie;• komplikacji kodu, gdzie sprawdzamy czy

kod nie jest zbyt zawiły. Może to utrud-niać jego czytelność i wymuszać testowa-nie wielu ścieżek wykonania (np. McCabe Cyclomatic Complexity).

Tabela 3. Przykładowe wyniki uzyskane przez analizę za pomocą narzędzia Lint

Kod uwa-gi

Opis Ilość wystąpień Ocena ważności[mała/średnia/wysoka]

534 Wartość zwracana przez funkcję jest ignorowana

221 Wysoka

525/539 Za płytkie/głębokie wcięcia w stosun-ku do wyszczególnionej linii.

71 Mała

529 Zadeklarowana w funkcji zmienna nigdy nie została użyta.

65 Mała

613 Prawdopodobne użycie zerowego wskaźnika jako argumentu wywołania

11 Wysoka

571 Podejrzane rzutowanie 8 Średnia

644 Użyta zmienna nie została wcześniej zainicjowana

3 Wysoka

Page 33: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200832

Testowanie oprogramowaniaByła sobie inspekcja

www.sdjournal.org 33

Powyższa lista uwidacznia elastyczność per-spektyw. W zależności od potrzeb, można zmieniać ich ilość. Nie muszą odnosić się do całego projektu, nie wszystkie trzeba wyko-rzystywać przy każdej inspekcji. Co więcej – można używać ich nie tylko jako element in-spekcji, ale również przy wspieraniu rozwoju produktu. Koncepcja taka jest popularna pod paradygmatem programowania aspektowego (ang. aspect-oriented programming, AOP). Taki sposób rozwijania produktu pozwala na przej-ście z tradycyjnego podejścia strukturalnego (wertykalnego) na zorientowane na dostarcze-nie funkcjonalności, usługi (horyzontalne).

Budowanie list sprawdzającychKolejną strategią wykorzystywaną w procesie inspekcji są listy sprawdzające. Buduje się je we-dług kryterium prawdopodobieństwa (często-ści) występowania problemu oraz jego wpływu na całość produktu. Obecność wielu nieużywa-nych zmiennych będzie zwiększała rozmiar wy-maganej pamięci. Produkt nie będzie optymal-ny, ale (gdy mimo wszystko spełnione są ogra-niczenia na rozmiar wymaganej pamięci) jest nadal akceptowalny. Natomiast choćby jedno źle obsłużone dzielenie przez zero spowodu-je błąd krytyczny, który uniemożliwi funkcjo-nowanie całego produktu. W tym przypadku ilość ma mniejsze znaczenie niż waga proble-mu. Kryteria te należy więc ostrożnie ważyć.

Przykładowo, dla perspektywy opartej na na-rzędziu Lint, otrzymaliśmy zestaw uwag jak w Tabeli 3. Możemy z niej wyczytać, że w pro-dukcie istnieje generalny problem ze sprawdza-niem wartości zwracanych przez funkcje (uwa-gi o kodzie 534). W takim kodzie brakuje od-powiedniej obsługi błędów (zaimplementowa-ne ścieżki wykonania nie uwzględniają przy-padków negatywnych). Problem jest więc czę-sty i na pewno istotny. Podobnie ma się sytuacja z uwagami o kodzie 613 i 644. Mimo że jest ich znacznie mniej, konsekwencje braku sprawdza-nia stanu zmiennej przed jej wykorzystaniem mogą być bardzo poważne. Z kolei uwagi o ko-dzie 571 sygnalizują problemy z przenośnością kodu na różne platformy. Jeżeli jest to jednym z wymagań w stosunku do produktu – ich waga może wzrosnąć ze średniej do wysokiej. Uwagi o kodzie 525, 539 i 529 świadczą o tym, że kod był wielokrotnie i niezbyt skrupulatnie przera-biany. Choć jest ich dużo, w porównaniu do po-przednich są nieszkodliwe (chyba że produkt polega na dostarczeniu kodu źródłowego, a nie gotowych bibliotek).

Poszczególne elementy listy sprawdzającej (ang. checkpoints) muszą być testowalne, ale nie nazbyt szczegółowe. Wymaganie testowalno-ści (inaczej atomiczności) zapobiega sformuło-waniom typu: czy kod spełnia wymagania stan-dardu kodowania? Trudno w takim przypadku jednoznacznie stwierdzić, co właściwie należy sprawdzić. Z drugiej strony należy pamiętać, że listy powinny być uniwersalne – nie powinny

np. odnosić się do projektu, w którego ramach zostały stworzone. Sprawdzamy tu sztukę, zna-jomość rzemiosła – funkcjonowanie jest dome-ną perspektyw. Dodatkowo, zbytnie uszczegó-łowienie listy może sprawić, że inspektorzy, ufając w jej kompletność, ograniczą się jedynie do sprawdzania elementów przez nią wyszcze-gólnionych.

Dla przykładu z Tabeli 3 listę sprawdzającą przedstawiono w Tabeli 4. Widać tam, że każ-dy element z listy został wzbogacony o dodat-kowe informacje:

• identyfikator, pozwalający na jednoznacz-ne odwoływanie się do elementu listy;

• źródło określające, na jakiej podstawie punkt został dodany. Podanie konkretne-go odniesienia (dokumentu) umożliwia dokładne sprawdzenie stawianych wyma-gań. Informacja taka będzie przydatna na etapie analizy i naprawy;

• sposób weryfikacji, określający możliwości sprawdzenia, czy zasygnalizowany problem (nadal) istnieje. W tym przypadku podane zostały kody błędów Lint'a. Informacja taka zostanie wykorzystana na etapie weryfika-cji: jeżeli naprawa będzie przeprowadzona prawidłowo, podany kod błędu nie powi-nien być więcej sygnalizowany;

• wskazówki – wyjaśnienia dotyczące punk-tu, dodatkowe referencje, wnioski ze wcze-śniejszych inspekcji (przydatne przy ulep-szaniu list).

Proszę zwrócić tu uwagę, że zaprezentowana lista sprawdzająca zawiera elementy z różnych dziedzin. Mamy w niej typowe błędy w sztu-ce (1.1-1.3), potencjalne problemy z przeno-śnością kodu (1.4) oraz problemy z formatowa-niem kodu (1.5). Wszystkie zostały wysnute ja-

ko wnioski z działania jednej perspektywy. W strategii przygotowanej przez zespół inspek-cyjny należy więc określić, czy listy sprawdza-jące powinny zbierać wnioski z różnych per-spektyw (tzn. jedna lista zawierająca ranking najczęstszych/najważniejszych problemów), czy też każda z perspektyw powinna posiadać swoją własną listę. Obie te metody mają swo-je zalety i wady. Do szybkich sprawdzeń (ang. sanity check), osobistych inspekcji i nauki rze-miosła zdecydowanie polecamy pojedynczą li-stę. W przypadku ulepszania procesu korzyst-niejszy jest podział względem perspektyw.

Ulepszanie list sprawdzającychPodobnie jak perspektywy, listy sprawdzające ulepsza się na podstawie mechanizmu sprzę-żenia zwrotnego:

• inspektorzy podczas analizy (lub autorzy podczas inspekcji osobistej) sprawdzają poszczególne problemy znajdujące się na liście;

• jeżeli problem występuje w analizowanym fragmencie, inspektor zgłasza odpowied-ni komentarz z priorytetem odpowiadają-cym pozycji problemu na liście;

• zgodnie z komentarzem, kod jest napra-wiany. Autor widzi, że jest to częsty błąd i postanawia zwrócić na niego szczególną uwagę;

• ponieważ autorzy są świadomi szczególnie częstego występowania problemu, starają się więcej go nie popełniać;

• kolejne inspekcje wykazują, że problem jest dużo rzadszy. Może być przesunięty na dalsze pozycje w liście sprawdzającej.

Obniżanie priorytetu elementu listy spraw-dzającej musi się odbywać zgodnie z zastrzeże-

Rysunek 2. Współdziałanie procesów w projekcie

�������������������

��������������������������������������

�����������������

������������������

�����������

������������

��������������

���������

�����������

����������

�����������

�������������������

�����������

�������

�����

���������

������

�������

��������

������

������

������

������������

��������

����

����������

Page 34: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200834

Testowanie oprogramowaniaByła sobie inspekcja

www.sdjournal.org 35

niami w stosunku do problemów krytycznych sformułowanymi w poprzednim rozdziale.

Zmiany na liście sprawdzającej można użyć np. do weryfikacji skuteczności prowadzonych szkoleń. Popełnianie dużej ilości błędów uję-tych w standardzie kodowania, sugeruje niedo-stateczną znajomość tego dokumentu. Jeżeli mi-mo szkolenia przeprowadzonego w tym zakre-sie, ilość ta nie zmieni się, możemy domniemać, że szkolenie było nieskuteczne. Szkolenie należy powtórzyć, zmieniając jego formułę – np. uwy-puklając, które z zapisów są szczególnie ważne.

Problemy wysoko utrzymujące się na liście sygnalizują też niedostatki w dzieleniu się wie-dzą w zespole. Pomimo że błędy są zauważane, sposoby ich rozwiązywania mogą być niejasne dla wszystkich członków zespołu. Usprawnie-nie mechanizmu dzielenia się wiedzą powinno sytuację tę poprawić.

Wykorzystanie narzędziDzięki zastosowaniu perspektyw i list spraw-dzających praca inspektora jest lepiej ukierun-kowana i bardziej uporządkowana. Mimo to, analiza kodu jest zadaniem wymagającym du-żej wiedzy, samodyscypliny i koncentracji. Dla-tego jest tak mocno obciążona czynnikiem ludz-kim. Jeżeli ten sam fragmentu kodu zosta-nie poddany analizie dwóm różnym inspekto-rom, możemy być pewni, że dostarczone przez nich rezultaty będą różne. Różna będzie ilość komentarzy, ich jakość, różny będzie czas wy-konania takiego zadania. Analiza dokonywa-na przez człowieka nie jest procesem powta-rzalnym.

Takich skutków ubocznych natury ludzkiej jest oczywiście więcej. Samopoczucie, osobi-ste animozje w stosunku do autora przedmio-tu analizy, nadchodzący weekend – wszyst-kie te pozamerytoryczne uwarunkowania mo-gą ujemnie wpływać na obiektywizm pracy in-spektora. Analiza będzie wtedy mało rzetelna, niedokładna.

Tych wad pozbawione są narzędzia do anali-zy statycznej kodu. Uzyskiwane przez nie wy-

niki są powtarzalne, mierzalne (numeryczne) przez co łatwo je analizować pod wieloma ką-tami. Sam proces analizy automatycznej trwa zazwyczaj bardzo krótko. Dodanie takich na-rzędzi do konfiguracji projektu (np. generowa-nie raportów Lint z każdą kompilacją) pozwoli na śledzenie trendów. Umożliwi to weryfikację poprawności naprawy problemów wskazanych w czasie inspekcji.

Niestety nie jest to rozwiązanie idealne. Przyjrzyjmy się kilku potencjalnym proble-mom:

• narzędzie jest tak dobre, jak dobrzy są jego autorzy;

• narzędzie musi być odpowiednio wdrożo-ne;

• różne narzędzia realizujące podobne cele mogą dostarczać sprzeczne wyniki;

• narzędzie może być zbyt restrykcyjne;• narzędzia są kosztowne.

W przypadku oprogramowania o ugruntowa-nej pozycji na rynku stosunkowo rzadko zda-rzają się sytuacje, w których źródłem proble-mów jest samo narzędzie, a nie analizowany przez nie przedmiot. Inaczej bywa z narzędzia-mi konstruowanymi wewnątrz organizacji, w odpowiedzi na potrzeby projektu. Ich jakość jest zazwyczaj niska ze względu na pośpiech, z jakim są tworzone. Często jest to prywatny kod pisany przez deweloperów w jednym, konkret-nym celu. Nie są głównym przedmiotem pro-jektu i nie podlegają tak ścisłej kontroli jakości, jak sam produkt. Bez dokumentacji, przetesto-wane na pojedynczym przypadku – mogą za-wierać błędy. Włączanie ich do mechanizmów zapewniania jakości może wiązać się z ryzy-kiem. Dlatego zalecamy używanie sprawdzo-nych rozwiązań, wykorzystywanych wcześniej w innych projektach (organizacjach), oferowa-nych przez znane firmy i rozwijanych przez wiele lat. Przykładem takiego oprogramowa-nia może być wspomniany wcześniej Lint firmy Gimpel, FXCop (Microsoft) i wiele innych.

Problemy z używaniem narzędzi do statycz-nej analizy kodu związane są najczęściej z błę-dami popełnionym na etapie ich wdrożenia. Może to być np. zła konfiguracja, użycie nie-zgodne z przeznaczeniem, mylna interpreta-cja wyników związana z nieznajomością narzę-dzia. Jedyną radą jest odpowiednie szkolenie.

Znaczna jest pokusa wykorzystania kilku różnych narzędzi. Jeżeli analiza jest tak szyb-ka, spróbujmy wykonać ją z pomocą wszyst-kich dostępnych środków. Każde z narzędzi, trochę inaczej skonstruowane, zwróci uwagę na inne problemy. Rozwiązanie ich uczyni nasz produkt idealnym. Niestety, często jest tak, że wprowadzenie poprawek zgodnie z jednym na-rzędziem, powoduje sygnalizowanie błędów przez inne narzędzie. Skończyć się to może po-prawianiem kodu zgodnie z wymaganiami na-rzędzi.

Podobnie ma się sytuacja z restrykcyjnością narzędzi. Niektóre z nich mają tendencję do zgłaszania setek tysięcy uwag. Konieczna w ta-kim wypadku jest ich odpowiednia kategoryza-cja. Rozwiązywanie powinno odbywać się w ko-lejności od najważniejszych (krytycznych) aż po te o charakterze informacyjnym. Oczywi-ście stan projektu może taki porządek zmienić – np. uzupełnienie komentarzy w obliczu zbli-żającego się terminu publikacji kodu do klien-ta będzie ważniejsze niż usuwanie ostrzeżeń o niekompatybilności typów (wcale nie twierdzi-my, że jest to postępowanie poprawne).

Mnogość uwag prowokuje również ich za-miatanie pod dywan. Może to mieć miejsce, zwłaszcza gdy producent narzędzia umożliwia takie działania. Przyjrzyjmy się następującemu fragmentowi kodu:

/*lint -esym(534, sprintf)*/

char buffer [20];

int a=5, b=3;

sprintf (buffer, "%d plus %d is %d", a, b,

a+b);

Pierwsza linijka listingu powoduje wyłączenie ostrzegania przed brakiem sprawdzania war-tości zwracanej przez funkcję sprintf. Jaką więc będziemy mieli gwarancję, że w zmien-nej buffer znajdzie się przewidziany przez nas łańcuch znaków? Pół biedy, jeżeli podob-na instrukcja znajdzie się w pliku konfigura-cyjnym. Jest to wtedy działanie zaplanowa-ne i zamierzone, którego motywy są znane a wprowadzenie poparte odpowiednimi ustale-niami (np. zaakceptowane przez klienta). Jed-nak sporna linijka umieszczona została bezpo-średnio w kodzie źródłowym. Ciekawe, ile ta-kich instrukcji znalazło się w całym produk-cie? Ile potencjalnych błędów w taki sposób zostało ukrytych?

Ostatnia kwestia odnosi się do kosztów wprowadzania narzędzi do projektów. Wymie-niliśmy już nakłady związane ze szkoleniem, wdrożeniem i zarządzaniem. W przypadku

Tabela 4. Lista sprawdzająca dla wyników analizy z Tabeli 3

ID Do sprawdzenia Źródło Weryfika-cja

Wskazówki

1.1 Wartości zwracane przez funkcje muszą być spraw-dzane.

Standard kodo-wania, 5.1.3

Lint, kod 534

1.2 Argumenty muszą być spraw-dzone przed wywołaniem.

Standardy kodo-wania, 6.2.3

Lint, kod 613

1.3 Zmienne muszą być zainicjo-wane po deklaracji.

Standard kodo-wania, 6.2.1

Lint, kod 644

1.4 Rzutowania zmiennych mu-szą być wykonane każdora-zowo.

Standardy kodo-wania, 7.2.1

Lint, kod 571

Więcej na temat rzutowa-nia zmiennych znajdziesz w <...>

1.5 Poziomy wcięć w kodzie mu-szą być zachowane.

Standardy kodo-wania, 3.3

Lint, kody: 525, 539, 529

Wcięcia muszą być wyko-nane za pomocą znaków tabulatora a nie spacji. Konfiguracja edytora kodu można znaleźć w <...>

Page 35: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200834

Testowanie oprogramowaniaByła sobie inspekcja

www.sdjournal.org 35

oprogramowania komercyjnego należy liczyć się również z kosztami licencji, które dla tej ka-tegorii produktów są zazwyczaj wysokie. W ce-lu ograniczenia wydatków licencyjnych, należy przede wszystkim upewnić się, czy podobne narzędzia nie są już wykorzystywane w naszej organizacji, sprawdzić prawne możliwości dzie-lenia i przenoszenia licencji (używanie poprzez dostęp zdalny, np. Citrix) i oszacować opłacal-ność zakupu względem możliwości wykorzy-stania w innych projektach. Można również po-szukać oprogramowania opartego na licencjach typu OpenSource.

Miary projektowe i procesoweZ racji ilości produkowanych danych, inspek-cja kodu wydaje się wdzięcznym narzędziem do formułowania wniosków projektowych. Pa-trząc na ilość i jakość zgłoszonych komentarzy, możemy zastanawiać się nad stopniem dojrza-łości produktu. W najprostszym podejściu – im mniej komentarzy, tym produkt jest dojrzal-szy. Waga tych komentarzy może być jednak różna. Część z nich zostanie odrzucona, część zakwalifikowana jako propozycje zmian w przyszłych wersjach (CR i REQ), część odnosi się do literówek w komentarzach. Niektóre jed-nak zostaną zarejestrowane jak raporty o błę-dach (PR) do uwzględnienia w fazie naprawy. Nadal – PR'y mogą odnosić się tak do nieuży-tej zmiennej zapomnianej w kodzie (mało ele-ganckie, ale też i nie bardzo szkodliwe), jak i źle zastosowanego muteksu (groźba zakleszczenia, ang. deadlock). Podobnie jest z miarami celów. Usunięcie połowy z tysiąca ostrzeżeń Linta nie-wątpliwie jest sukcesem. Jednak przy takiej ilo-ści szacunek poprawy kodu może być obarczo-ny bardzo dużym błędem – śledzenie jakości usuniętych uwag (ich wagi, typu) będzie zbyt pracochłonne. W takiej sytuacji jedynie usunię-cie wszystkich uwag Lint'a może przyczynić się do obserwowalnej poprawy jakości.

Należy tu wspomnieć o metodach pozwala-jących na szacowanie ilości błędów, które pozo-stały w kodzie, błędów jeszcze nieodkrytych. Pierwsza z nich to wstrzykiwanie defektów [9]. Polega na przekazaniu do analizy spreparowa-nego przedmiotu, do którego wprowadziliśmy C defektów. Jeżeli inspektor znajdzie K nowych defektów i R defektów dodanych przez nas (tzn. razem znajdzie K+R defektów), możemy oszaco-wać, że całkowita liczba defektów w przedmio-cie analizy jest równa:

LiczbaDefektówWD = K * C / R

Inną metodą jest podwójne łowienie (metoda Lincolna – Petersena, ang. mark and recaptu-re), gdzie ten sam fragment kodu poddajemy analizie przez dwóch inspektorów. Jeżeli je-den z nich znajdzie C defektów, a drugi M de-fektów, możemy zastosować wzór:

LiczbaDefektówLP = M * C / R

Wartość R będzie częścią wspólną zbiorów M i C, ilością błędów znalezionych przez oby-dwóch inspektorów. Jest to metoda lepsza niż wstrzykiwanie, gdyż nie wymaga mody-fikowania przedmiotu analizy. Proszę jednak mieć na uwadze, że inspektorzy mogą uznać przeprowadzanie takich doświadczeń za pró-by sprawdzenia ich pracy.

W związku z powyższymi rozważaniami:

• jedynie cele osiągnięte całkowicie mogą bezpośrednio przekładać się na poprawę jakości;

• miary powinny odnosić się tylko i wyłącz-nie do dojrzałości produktu, nigdy do ja-kości pracy inspektorów;

• miary dostarczone przez inspekcję powin-ny być weryfikowane w kontekście popra-wy dynamicznego zachowania produktu (testy regresyjne i systemowe).

Ostatni punkt listy odnosi się do użytego wcześniej określenia obserwowalnej poprawy ja-kości. Inspekcja nie jest celem samym w sobie. Jej celem jest poprawa jakości produktu. W dziedzinie tworzenia oprogramowania jakość produktu odnosimy do zachowania produktu zgodnie z wymaganiami klienta. Inspekcja ko-du źródłowego jest więc jednym ze sposobów poprawy zachowania dynamicznego produk-tu, jego wykonania. Ostateczną miarą jej suk-cesu jest obserwowalna poprawa zachowania – np. zwiększenie ilości zaliczanych testów re-gresyjnych, zwiększenie stabilności produktu. Miary inspekcji odnoszą się głównie do śledze-nia jej przebiegu. Ostateczna weryfikacja efek-tywności procesu inspekcji dokona się w pro-cesie testowania.

Inaczej traktowane są miary procesowe. Ich głównym zadaniem jest wspomaganie organi-zacji procesu inspekcji. Poprzez porównywa-nie czasu zaplanowanego na wykonanie zadań inspekcji z czasem rzeczywiście na nie poświę-conym, uzyskamy możliwość lepszego harmo-nogramowania. Szacunki powstałe w ten spo-sób pomogą lepiej ocenić czas i zasoby wyma-gane w kolejnych iteracjach inspekcji. Sposo-bem na wyznaczenie efektywności procesu in-spekcji jest dokonanie analizy wartości wypra-cowanej (ang. earned value). Polega ona na po-równaniu skumulowanych planowanych i rze-czywistych kosztów zadań inspekcji w stosun-ku do stopnia ich realizacji. Konfrontując ilość i koszt zadań wykonanych w dniu kontroli z wielkościami planowanymi, obliczamy prze-widywane opóźnienie i całkowity koszt proce-su. Na tej podstawie można wnioskować moż-liwości wprowadzania korekt do harmonogra-mu, tak aby zminimalizować odchylenie od za-mierzonego budżetu.

KonsultacjeW niniejszym opracowaniu użyliśmy określe-nia konsultacje zamiast spotkania. Jest to zabieg

mający na celu podkreślenie, że niekoniecznie chodzi o typowe posiedzenie, w którym człon-kowie zespołu inspekcyjnego uczestniczą oso-biście. W przypadku projektów rozproszonych po różnych lokalizacjach może to być w ogóle niemożliwe. Znacznie korzystniejsza jest w ta-kich wypadkach np. wymiana opinii w ramach systemu kontroli zmian (wpisy w Bugzilli), ko-respondencja elektroniczna, czat na Skype lub po prostu rozmowa telefoniczna. Zwłaszcza zalecalibyśmy wszelkie formy pisane, które są źródłem wprawdzie nieformalnej, ale zawsze dokumentacji. Posiadanie takiego materiału umożliwia np. prześledzenie motywów, jakie doprowadziły do takich, a nie innych decyzji. Wraz z upływem czasu takie informacje okażą się bardzo przydatne.

Kłopot z tradycyjnymi spotkaniami pole-ga na tym, że (wbrew pozorom) prowadzenie ich wymaga wiele umiejętności i doświadcze-nia. Proszę zwrócić uwagę, że jest to dość dro-ga metoda komunikacji – zakładając koszt pra-cy jednej osoby na poziomie 200 euro dziennie, dwugodzinne spotkanie 10-osobowego zespołu to wydatek rzędu 500 euro! Czy na pewno de-cyzje podjęte podczas spotkania będą warte ta-kich pieniędzy?

Jeżeli mimo wszystko zdecydujemy się na podobną formę konsultacji, radzimy pamiętać o kilku zasadach, które pozwolą rozsądnie wy-dać wspomniane pieniądze:

• wyznaczcie cel spotkania. Cel powinien być konkretny, jednoznaczny (ang. specific), mierzalny (ang. measurable), realistyczny (ang. achievable), odpowiednio ważny, aby angażować do jego rozwiązania zaproszo-nych uczestników (ang. relevant) i w końcu określony w czasie (ang. timely). Jednym sło-wem – cel powinien być S.M.A.R.T.;

• ustalcie agendę. Agenda powinna być wy-słana do uczestników spotkania odpo-wiednio wcześniej. Agenda powinna za-wierać wskazówki, jak przygotować się do spotkania (co doczytać, na jaki temat wy-robić sobie zdanie);

• w spotkaniu powinny uczestniczyć tylko osoby bezpośrednio zaangażowane w pro-blem. Nie ma sensu trwonić czasu innych – o końcowych ustaleniach wystarczy po-informować ich np. drogą elektroniczną;

• zawsze należy określić i pilnować czasu spo-tkania oraz poszczególnych punktów agen-dy. Spotkania przeciągające się w nieskoń-czoność najczęściej do niczego nie prowadzą;

• każdy punkt agendy podsumowujcie przez wniosek lub akcję do wykonania przez konkretnego członka spotkania. Brak podsumowania oznacza, że dyskusja była bezprzedmiotowa;

• jeden z uczestników spotkania powinien sporządzać notatki (ang. meeting minutes) w celu późniejszego udostępnienia ich in-nym zainteresowanym.

Page 36: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200836

Testowanie oprogramowania

Powyższe zasady powinny być stosowanie do wszystkich spotkań. Specyficzny charakter inspekcji sprzyja stosowaniu tej formy czę-ściej niż w innych procesach (dla inspekcji for-malnej takie konsultacje są wręcz narzędziem podstawowym). Stąd nieumiejętne prowadze-nie spotkań może skutkować znaczącym spad-kiem wydajności.

Współpraca między procesamiZgodnie z definicją ISO 9001, podejściem procesowym nazywamy identyfikację pro-cesów w organizacji oraz zarządzanie tymi procesami (i ich powiązaniami). Wynika z tego, że nie wystarczy poznać, jakie proce-sy funkcjonują w obrębie systemu. Koniecz-ne jest również określenie powiązań, zależ-ności między tymi procesami. Dla naszej inspekcji oba te warunki zostały spełnione. Okazało się bowiem, że etapy inspekcji rów-nież można określić jako procesy. Powiąza-nia między nimi pokazaliśmy na Rysunku 1. i szeroko omówiliśmy w podrozdziałach te-go opracowania.

Jak analiza, naprawa, weryfikacja i ulep-szanie są podprocesami inspekcji, tak pro-ces inspekcji sam jest elementem większego systemu. Konsumuje wyniki jednych proce-sów i dostarcza produkty na potrzeby funk-cjonowania drugich. Weźmy dla przykładu czas i zasoby (Rysunek 2). Ich alokacja na potrzeby inspekcji musi być przewidziana harmonogramem prac. Zadania inspekcji, wedle wskazówek dotyczących ról inspek-cyjnych, muszą być przyporządkowane od-powiednim zasobom. Harmonogram musi więc uwzględnić:

• proces inspekcji: adaptacja procesu inspek-cji (ustalenie zasad inspekcji), zbieranie i

analiza miar projektowych i procesowych, ulepszanie procesu inspekcji;

• techniki inspekcji: przeprowadzenie anali-zy, naprawa i weryfikacja przedmiotu ana-lizy na podstawie zebranych komentarzy, zarządzanie narzędziami (wdrożenie, me-chanizmy interpretacji wyników), konsul-tacje między członkami zespołu inspek-cyjnego;

• strategie inspekcji: tworzenie i ulepszanie perspektyw i list sprawdzających;

Cele inspekcji muszą być zgodne z założe-niami systemu jakości projektu (organi-zacji). Jej mechanizmy muszą odwoływać się do mechanizmów przyjętych w projek-cie, nie mogą ich dublować czy nadpisy-wać. Miary dostarczone przez inspekcję mu-szą należeć do zestawu miar wykorzystywa-nych w projekcie. Jednym słowem – proces inspekcji musi być zbieżny z innymi proce-sami w projekcie.

Podobnie jest z komunikacją w projekcie. Na potrzeby inspekcji nie powinno się two-rzyć żadnych specjalnych form (kanałów) ko-munikacji. Jeżeli jednak sposób komunikacji wymagany przez inspekcję nie istnieje, nale-ży go wdrożyć z zamysłem wykorzystania w innych procesach (tzn. nie w ramach samej inspekcji, ale w ramach procesu komunika-cji w projekcie).

Przykładem może tu być komunika-cja między inspektorem i autorem poprzez pocztę elektroniczną. Taka korespondencja zawiera opis zmian wraz z dyskusją nad ni-mi, tokiem rozumowania, wnioskami. Jeże-li wymienione email'e mają być później trak-towane jako forma dokumentacji, muszą ist-nieć mechanizmy ich jednoznacznej identy-fikacji i lokalizacji. Należy więc umówić się

co do tytułu email'a (np. identyfikator ko-mentarza z nazwą modułu) i sposobu zapi-sywania go na dysku projektowym pod usta-loną ścieżką i nazwą. Jeżeli zostanie to opisa-ne w dokumentacji procesowej i konsekwent-nie przestrzegane – żaden audytor ISO 9001 nie powinien mieć do takiego postępowania zastrzeżeń.

Inspekcja wymaga również interakcji z pro-cesami konfiguracji projektu. Mianem kon-figuracji projektu określamy tu całe otocze-nie projektu oraz mechanizmy wymagane, aby projekt mógł być wykonywany. Będą to np. sposoby przechowywania kodu (repozy-torium CVS), kontroli zmian (np. Bugzilla), obrotu dokumentami (Wiki) aż po zarządza-nie licencjami (kompilatory, środowiska pro-gramistyczne) i środkami trwałymi (kompu-tery, sieć laboratoryjna). Inspekcja, jako jeden z procesów zachodzących w projekcie, będzie częścią tego otoczenia.

Powyższa lista obejmuje jedynie główne i bezpośrednie zależności. W rzeczywistym projekcie mogą być one bardziej skomplikowa-ne, ale również dające większe możliwości ste-rowania.

PodsumowanieInspekcja kodu jest jednym z ważniejszych procesów jakościowych, które powinny być prowadzone w ramach projektu. Pomaga uniknąć wielu błędów w sztuce, zapewnia weryfikację na wczesnym stadium. Zachę-ca zespół projektowy do współpracy, dzie-lenia się wiedzą, wprowadza dobre nawyki. Zapewnia produktowi stabilną podstawę a członkom zespołu sposób podnoszenia umie-jętności.

Inspekcja nie może jednak zastąpić analizy dynamicznej (testowania). Jej zakres ograni-cza się do analizy statycznej. Nie zapewni usu-nięcia błędów powstających podczas interakcji funkcji, różnych modułów, na styku aspektów funkcjonowania.

Wdrażanie inspekcji wymaga również nie-małego wysiłku. Jest procesem, który może po-chłonąć duże zasoby na bardzo długi czas, ła-two przy tym wymknąć się spod kontroli. Ko-nieczne jest dokładne planowanie i ścisła kon-trola postępów.

Na pytanie, czy inspekcję stosować, odpo-wiedź jest jedna: tak! Jednak: odpowiednio do wymogów produktu, ograniczeń projektu i zgodnie z obowiązującym budżetem.

Zapamiętaj

• Inspekcja to kluczowy proces zapewniania jakości produktu;• Wdrożenie inspekcji we wczesnych stadiach projektu zaoszczędzi wiele testowania;• Inspekcja ma na celu poprawę jakości produktu, nie jakości pracy inspektorów;• Efektywność inspekcji weryfikuje poprawa zachowania produktu względem wymagań

klienta;• Klient zakłada jakość, oczekuje funkcjonalności – proces inspekcji musi uwzględniać ograni-

czenia projektowe;

Bibliografia

• [1] ISO 9001:2000, International Organization for Standardization, 2005; • [2] Była sobie inspekcja – określenie, przygotowanie i definicja procesu inspekcji, Arkadiusz

Merta, SDJ 09/2008;• [3] The executive in action, Peter F. Drucker, 1985;• [4] Change Formula, Gleicher, Beckhard and Harris, 1987;• [5] The Mythical Man-Month – Essays on Software Engineering, Peter F. Brooks, 1995;• [6] Peer Reviews in Software – A Practical Guide, Karl E. Wiegers, 2001;• [7] The Cathedral and the Bazaar, Eric Steven Raymond, 2000;• [8] Best Practices for Peer Code Review, SmartBear Software;• [9] Przeglądy oprogramowania i standard IEEE1028, Bartosz Michalik;

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.

Kontakt z autorem: [email protected]

Page 37: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5
Page 38: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200838

Narzędzia programistyczneIBM WebSphere MQ

www.sdjournal.org 39

Wraz z rozwojem systemów informa-tycznych, a co za tym idzie, szere-gu usług coraz częściej pojawia się

konieczność wymiany informacji pomiędzy różnymi systemami. Projektując zupełnie no-we rozwiązanie teoretycznie możemy zintegro-wać dwa duże systemy poprzez implementa-cje komunikacji bezpośredniej pomiędzy nimi, jednak można się spodziewać, że integracja bę-dzie wymagać połączenia więcej niż dwóch sys-temów, z których każdy pracuje na innej plat-formie i został zaimplementowany w różnych językach.

Oczywiście ta druga możliwość jest znacznie bardziej prawdopodobna niż pierwsza, ponie-waż w większości przypadków nowe usługi czy rozwiązania biznesowe to rozwój już istnieją-cych systemów, a nie tworzenie czegoś nowego.

Przyjrzyjmy się komunikacji bezpośredniej (Rysunek 1)

Analizując powyższy rysunek można wy-wnioskować kilka istotnych informacji:

• konieczność implementacji mechanizmów pozwalających tworzyć bezpośrednie połą-czenie pomiędzy dwoma aplikacjami;

• konieczność działania aplikacji A i B w chwili wymiany informacji pomiędzy nimi;

• spory narzut kodu konieczny do obsługi takiej komunikacji;

• w przypadku konieczności integracji wię-cej niż dwóch aplikacji zadanie może być bardzo trudne i podatne na błędy;

• w przypadku problemów z dostępem do sieci komunikat może zostać częściowo lub w całości utracony.

Rozważmy teraz komunikację pośrednią (Ry-sunek 2) w taki sposób, aby odnieść się do wad przedstawionych w metodzie komunikacji bezpośredniej.

Analizując rysunek przedstawiający komuni-kację pośrednią wnioskujemy, że:

• nie mamy konieczności implementacji me-chanizmów pozwalających na komunika-cję bezpośrednią, ponieważ nasza wiado-mość musi zostać dostarczona do MQ, za-tem każda aplikacja uczestnicząca w pro-cesie wysyłania informacji musi mieć me-chanizm wysyłania komunikatu do MQ i nic więcej;

• ponieważ każdy komunikat przechodzi przez MQ nie ma konieczności aby aplika-cja wysyłająca i aplikacja odbierająca dzia-łały w danej chwili;

• poprzez dostarczone biblioteki przez We-bSphere MQ implementacja mechanizmu

wysłania bądź odebrania wiadomości jest znacznie ułatwiona;

• dzięki temu, że MQ jest naszym pośredni-kiem nie ma żadnego problemu aby zinte-grować w ten sposób trzy, cztery i więcej aplikacji;

• dzięki temu, że nie jest wymagana bezpo-średnia komunikacja mamy pewność, że podczas problemów z dostępem do sieci po jednej ze stron, nie stracimy żadnego komunikatu.

Czym zatem jest IBM WebSphere MQ? Pa-trząc od strony biznesowej można powie-dzieć, że MQ jest to rozwiązanie dające nam możliwość integracji różnych systemów in-formatycznych niezależnie od platformy, ję-zyka oraz technologii w jakich zostały napi-sane. Dzięki temu, że działa na zasadzie po-średnika w komunikacji pomiędzy aplikacja-mi, można znacznie mniejszym nakładem sił zintegrować dwie lub więcej dotąd niezależ-nych aplikacji bez konieczności sporych mo-dyfikacji w kodzie.

Podstawowe pojęciaZanim przejdę do przykładów, przedstawię zbiór niezbędnych pojęć, które będą towarzy-szyć nam w dalszej części artykułu.

• Manager Kolejek (ang. Queue Manager) – odpowiada za dostarczenie możliwości ko-rzystania z usług dostarczonych przez We-bSphere MQ. Z poziomu Queue Managera mamy możliwość definiowania kolejek, kanałów itp. Każdą pracę związaną z ob-

Wstęp do IBM WebSphere MQ v6.0IBM WebSphere MQ jest rozwiązaniem pozwalającym na integrację różnych systemów informatycznych poprzez dostarczenie mechanizmów pozwalających na łatwą wymianę komunikatów pomiędzy nimi.

Dowiesz się:• Czym jest MQ i jaka jest jego rola w procesie

integracji systemów;

• Jak uzyskać dostęp do MQ z poziomu języka

Java.

Powinieneś wiedzieć:• Czytelnik powinien mieć podstawową wiedzę

na temat systemów kolejkowych;

• Posiadać podstawową umiejętność programo-

wania w języku Java.

Poziom trudności

Rysunek 1. Schemat komunikacji bezpośredniej

������������� ���������

Page 39: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200838

Narzędzia programistyczneIBM WebSphere MQ

www.sdjournal.org 39

sługą komunikatów musimy rozpocząć od utworzenia Queue Managera;

• Kolejka (ang. Queue) – jest to obiekt w któ-rym składowane są przesyłane komunikaty oraz obiekt z którego można dany komuni-kat pobrać. WebSphere MQ dostarcza nam wiele typów kolejek, natomiast w tym ar-tykule skorzystamy z dwóch typów:

• kolejka lokalna (ang. local queue) – ko-lejka która jest zarządzana przez ma-nagera kolejek do którego aplikacja jest podłączona. Zatem, jeżeli za pomo-cą aplikacji nawiązujemy połączenie z managerem kolejek o nazwie QM1 to lokalna kolejka może być zarządzana tylko przez tego managera;

• kolejka zdalna (ang. remote queue) – kolejka, która może być zarządzana przez innego managera kolejek niż ten do którego jesteśmy podłączeni. Jeże-li za pomocą aplikacji nawiązujemy połączenie z managerem kolejek o na-zwie QM1 to zdalna kolejka daje nam możliwość przeprowadzenia na niej operacji za pomocą QM1 mimo tego, że za zarządzanie tą kolejką odpowie-dzialny jest inny manager kolejek.

Przede wszystkim jest jedna podstawowa róż-nica pomiędzy kolejką lokalną i zdalną. Za-równo do kolejki lokalnej jak i zdalnej może-my wstawić wiadomość, natomiast odczytać możemy jedynie z kolejki lokalnej.

• Kanał (ang. channel) – daje nam możli-wość komunikacji pomiędzy różnymi ma-nagerami kolejek. WebSphere MQ dostar-cza nam dwa typy kanałów:• kanał komunikatów (ang. message

channel) – odpowiada za transfer wia-domości pomiędzy różnymi manage-rami kolejek;

• kanał MQI – odpowiada za wywoła-nia managera kolejek z poziomu apli-kacji podłączonej jako klient.

• Słuchacz (ang. listener) – odpowiada za ak-ceptacje żądań przesyłanych komunikacją sieciową. Żądanie może przyjść albo z ma-nagera kolejek albo aplikacji klienckiej;

• Komunikat (ang. message) – wiadomość przekazywana do kolejki. WebSphere MQ definiuje nam cztery typy wiadomości (Datagram, Request, Reply, Report). W dal-szym przykładzie będziemy korzystać z komunikatu typu Datagram który jest podstawowym komunikatem nie wyma-gającym żadnej odpowiedzi ani potwier-dzenia odebrania.

W oparciu o te podstawowe pojęcia oraz infor-macje zawarte w pierwszym akapicie przejdź-my do zbudowania przykładu w którym wy-korzystamy powyższe pojęcia w praktyce.

Praca z WebSphere MQ ExplorerZakładając, że instalacja WebSphere MQ zakoń-czyła się powodzeniem, możemy przejść do utwo-

rzenia dwóch przykładów, które zaprezentują nam wszystkie pojęcia z drugiego akapitu oraz przygotują odpowiedni podkład pod kolejny aka-

Listing 1. Aplikacja kliencka wysyłająca komunikat do zdalnej kolejki

package mq;

import com.ibm.mq.MQC;

import com.ibm.mq.MQEnvironment;

import com.ibm.mq.MQException;

import com.ibm.mq.MQMessage;

import com.ibm.mq.MQPutMessageOptions;

import com.ibm.mq.MQQueue;

import com.ibm.mq.MQQueueManager;

public class MQSendRemote {

private String channel = "CLIENT.QM2";

private String qManager = "QM2";

private MQQueueManager qMgr;

public void init() {

MQEnvironment.hostname = "localhost";

MQEnvironment.channel = channel;

MQEnvironment.port=1415;

//CCSID, http://www03.ibm.com/systems/i/software/globalization/default_list.html

MQEnvironment.CCSID=1250;

MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY,MQC.TRANSPORT_MQSERIES);

}

public void start() {

try {

qMgr = new MQQueueManager(qManager);

int openOptions =MQC.MQOO_OUTPUT;

MQQueue queue = qMgr.accessQueue("Q1", openOptions);

MQMessage message = new MQMessage();

message.writeUTF("test 1");

message.priority=3; //ustawiamy piorytet wiadomości

MQPutMessageOptions messageoptions = new MQPutMessageOptions();

queue.put(message, messageoptions);

queue.close();

Mgr.disconnect();

} catch (MQException ex) {

System.out.println("An MQSeries error occurred : Completion code "+

ex.completionCode + " Reason code " + ex.reasonCode);

}catch (java.io.IOException ex) {

System.out.println("An error occurred whilst writing to themessage buffer: "+ ex);

}

}

}

Rysunek 2. Schemat komunikacji pośredniej w oparciu o IBM WebSphere MQ

����

����

��������� ����������������

���������

Page 40: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200840

Narzędzia programistyczneIBM WebSphere MQ

www.sdjournal.org 41

pit w którym wykonamy pewne operacje na kolej-kach z poziomu aplikacji napisanej w języku Java.

Przykład 1. Wysłanie i odebranie komunikatu z lokalnej kolejkiKrok 1

Otwieramy WebSphere MQ Explorer i w le-wym oknie Navigator klikamy prawym przyci-skiem myszy na folderze Queue Managers i wy-bieramy opcję New->Queue Manager.

W nowym oknie uzupełnić pole o nazwie Queue manager name wpisując QM1, zazna-czyć opcję Make this the default queue manager i wybrać Next.

Następnie nie dokonujemy żadnych zmian, kli-kamy dalej na Next. W kolejnym oknie zaznacza-my Start queue manager oraz Auto start queue ma-nager i klikamy na Next. W nowym oknie zazna-czamy Create listener configured for TCP/IP oraz wpisujemy port. Domyślnie wpisany jest 1414 i ponieważ jest to nasz pierwszy manager kolejek to możemy zostawić 1414 i kliknąć na Finish.

Po tych czynnościach powinniśmy mieć utworzoną kolejkę o nazwie QM1.Krok 2

Drugim krokiem będzie utworzenie lokalnej kolejki do przechowywania naszych komunika-tów. W tym celu należy rozwinąć QM1 i na fol-derze Queues wybrać New->Local Queue.

W nowym oknie wpisujemy nazwę kolejki Q1 i wybieramy Finish (Rysunek 3)Krok 3

W celu wysłania komunikatu do kolejki Q1 należy kliknąć prawym przyciskiem myszy na Q1 i wybrać opcję Put Text Message, natomiast w celu weryfikacji poprawności wysłanej infor-macji należy wybrać Browse Messages.

Przykład 2. Wysłanie komunikatu do kolejki zdalnejKrok 1

Analogicznie do poprzedniego przykładu na-leży utworzyć drugiego managera kolejek o na-zwie QM2 oraz porcie np. 1415.Krok 2

Analogicznie do poprzedniego przykładu wybierzmy opcję tworzenia kolejki z tą różnicą, że zamiast wybrać Local Queue wybieramy Re-mote Queue Definition. Nadajemy nazwę Q1 dla

naszej zdalnej kolejki i klikamy Next. W nowym oknie musimy zdefiniować parametry określa-jące kolejkę do której nasza kolejka będzie prze-kazywać komunikaty.

W polu Remote queue wpisujemy Q1 nato-miast w polu Remote queue manager należy wpi-sać QM1. Należy upewnić się, że pole Transmis-sion queue jest puste i wybrać Finish.

Następnie, analogicznie jak w poprzednim przykładzie, powinniśmy stworzyć lokalną ko-lejkę.

W tym celu należy rozwinąć QM2 i na fol-derze Queues wybrać New->Local Queue. W no-wym oknie wpisujemy nazwę QM1 i klikamy na Next. W kolejnym polu zaznaczamy pole Usage na Transmission i klikamy Finish (Rysunek 4).Krok 3

W kolejnym kroku musimy zapewnić moż-liwość przekazywania komunikatów przez zdalną kolejkę w QM2 do lokalnej kolejki QM1. W tym celu należy utworzyć dwa ka-nały odpowiedzialne za wysyłanie i odbiera-nie komunikatów. W QM1 utworzymy kanał odbioru (ang. receiver channel). Rozwińmy fol-

der Advanced z QM1 i prawym przyciskiem myszy kliknijmy na Channels. Następnie nale-ży wybrać New->Receiver Channel. W nowym oknie wpiszmy nazwę QM2.QM1 i wybierz-my Finish.

Analogicznie dla QM2 należy utworzyć ka-nał przesyłu (ang. sender channel). Postępując analogicznie jak dla QM1 należy wybrać New->Sender Channel, wpisać nazwę QM2.QM1 i kliknąć na Next.

W nowym oknie w polu Connection name na-leży wpisać nazwę komputera bądź IP kompu-tera gdzie znajduje się QM1. W naszym przy-padku będzie to localhost.

W polu Transmission queue należy wpisać na-zwę kolejki QM_Q1 i wybrać Finish.Krok 4

Po utworzeniu kanału przesyłu klikamy na nim prawym przyciskiem myszy i uruchamia-my go wybierając Start.Krok 5

W tym kroku dokonamy weryfikacji pro-cesu przekazywania komunikatów pomię-dzy dwoma kolejkami. Należy wstawić testo-

W Sieci

• ht tp : //w w w-306 . ibm.com/sof t ware/integration/wmq/

Bibliografia

• WebSphere MQ Application Programing Guide

• WebSphere MQ Application Programing Reference

• WebSphere MQ Using Java

Rysunek 3. Widok po przeprowadzeniu Kroku 1 i Kroku 2

Rysunek 4. Schemat po przeprowadzeniu Kroku 1 i Kroku 2

Page 41: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200840

Narzędzia programistyczneIBM WebSphere MQ

www.sdjournal.org 41

wy komunikat do kolejki Q1 w QM2. Wiado-mość ta powinna zostać przesłana do kolejki Q1 w QM1.

Dostęp do WebSphere MQ z poziomu języka JavaW oparciu o poprzedni paragraf, gdzie przygoto-waliśmy sobie QM1 i QM2 wraz ze zdefiniowany-mi kolejkami i kanałami, omówię teraz metodę do-stępu do MQ z poziomu języka Java jako klient.

Zanim przejdziemy do programowania mu-simy ustawić sobie jeszcze jeden kanał tym ra-zem będzie to kanał typu Server-connection chan-nel. Analogicznie do poprzednich przykładów wybieramy New->Server-connection channel i wpi-sujemy nazwę CLIENT.QM2 i klikamy na Next. W zakładce MCA należy podać login użytkow-nika na którym pracujemy w Windows i kliknąć na Finish.

Korzystając z Eclipse dostarczonego wraz z IBM WebSphere stwórzmy nowy projekt (dzięki temu, że Eclipse jest zintegrowany z MQ to niemal wszyst-kie niezbędne biblioteki zostaną dodane podczas tworzenia projektu). Ponieważ w naszym przykła-dzie oprzemy się o MQ base Java musimy dodać jeszcze jedną bibliotekę com.ibm.mq.jar która znaj-duje się w IBM\WebSphereMQ\Java\lib.

Przykładowy kod programu, który jest odpo-wiedzialny za przesłanie komunikatu do kolejki obsługiwanej przez QM2 przedstawia Listing 1.

Zanim jednak zapoznamy się z kodem źródło-wym, warto zapoznać się za co dana klasa odpo-wiada, dzięki temu zrozumienie poniższych ko-dów źródłowych powinno być łatwiejsze.

• MQC – interfejs, który definiuje wszystkie stałe, za pomocą których możemy definio-wać właściwości pozostałych obiektów;

• MQEnviroment – klasa, która zawiera sta-tyczne pola wykorzystywane do utworze-nia obiektu MQQueueManager. Ustawienie tych zmiennych nie jest konieczne w trybie binding mode, który ma dostęp do systemo-wych zmiennych środowiskowych. Pisząc program w MQ base Java w trybie klienc-kim musimy ustawić część zmiennych za-nim utworzymy obiekt MQQueueManager;

• MQMessage – reprezentuje zarówno dane jak i deskryptor wiadomości przesyłanej do MQ. Posiada metody pozwalające odczytywać wia-domość, dane z deskryptora wiadomości jak i grupę metod pozwalających na zapis danych;

• MQPutMessageOptions – klasa pozwalająca na ustawienie opcji wpływających na wyko-nywanie metody MQQueue.put();

• MQGetMessageOptions – klasa pozwalająca na ustawienie opcji wpływających na wyko-nywanie metody MQQueue.get();

• MQQueue – klasa odpowiedzialna za do-starczenie metod pozwalających na zarzą-dzanie kolejką. W naszych przykładach korzystamy z put(), get() oraz close();

• MQQueueManager – klasa odpowiedzialna za dostarczenie połączenia do managera kolejek w MQ.

Poniżej zamieszczam także kod (Listing 2) który odbiera wiadomość z kolejki umieszczo-nej w QM1 która odbiera wiadomość wysłaną przez QM2. Należy pamiętać o konieczności utworzenia kanału dla QM1 podobnie jak w powyższym przykładzie.

PodsumowaniePowyższe przykłady a zarazem cały artykuł, któ-ry miał pokazać jak postawić pierwsze kroki w tym środowisku, to tylko wstęp do IBM WebSphe-re MQ, który daje nam ogromne możliwości ale zarazem wymaga poznania wielu aspektów zwią-zanych z wykorzystywaniem tego rozwiązania do różnych zadań. Sam przykład programu w Java to jedna z wielu możliwości jakie daje nam MQ i język Java. Jedną z ciekawszych możliwości jest tryb binding mode, który pozwala budować apli-kacje w języku Java komunikujące się z MQ po-przez JNI, a nie jak ma to miejsce w moim przy-kładzie, poprzez połączenie sieciowe.

Zwolennicy JMS mają do dyspozycji imple-mentacje interfejsów JMS dzięki dostarczone-mu rozwiązaniu WebSphere MQ JMS.

Kończąc ten artykuł mogę jedynie zachęcić wszystkich do zapoznania się z MQ i popróbo-wania implementacji w jednym z dostępnych języków. Wszelkie niezbędne informacje moż-na znaleźć na stronie IBM gdzie dostępne są liczne manuale i ebooki.

PAWEŁ PIETRASZAutor jest studentem III roku informatyki na WFMiIS

Politechniki Krakowskiej oraz pracuje na stanowi-

sku programmer w firmie DRQ S.A.

Kontakt z autorem: [email protected]

Listing 2. Aplikacja kliencka odbierająca komunikat z lokalnej kolejki

package mq;

import com.ibm.mq.MQC;

import com.ibm.mq.MQEnvironment;

import com.ibm.mq.MQException;

import com.ibm.mq.MQGetMessageOptions;

import com.ibm.mq.MQMessage;

import com.ibm.mq.MQQueue;

import com.ibm.mq.MQQueueManager;

public class MQGet {

private String channel = "CLIENT.QM1";

private String qManager = "QM1";

private MQQueueManager qMgr;

public void init() {

MQEnvironment.hostname = "localhost";

MQEnvironment.channel = channel;

MQEnvironment.port=1414;

//CCSID, http://www-03.ibm.com/systems/i/software/globalization/default_list.html

MQEnvironment.CCSID=1250;

MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY,MQC.TRANSPORT_MQSERIES);

}

public void start() {

try {

qMgr = new MQQueueManager(qManager);

int openOptions = MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_OUTPUT;

MQQueue queue = qMgr.accessQueue("Q1", openOptions);

MQMessage retrievedMessage = new MQMessage();

MQGetMessageOptions gmo = new MQGetMessageOptions();

queue.get(retrievedMessage, gmo);

String msgText = retrievedMessage.readUTF();

System.out.println("The message is: " + msgText);

queue.close();

qMgr.disconnect();

} catch (MQException ex) {

System.out.println("An MQSeries error occurred : Completion code "+

ex.completionCode + " Reason code " + ex.reasonCode);

}catch (java.io.IOException ex) {

System.out.println("An error occurred whilst writing to themessage buffer: "+ ex);

}

}

}

Page 42: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200842

Aplikacje biznesoweSQL Server 2005/2008

www.sdjournal.org 43

Wyzwalacze (triggery) to obiekty ba-zy danych, które są uruchamia-ne automatycznie, jako następ-

stwo wystąpienia pewnych zdarzeń na serwe-rze SQL Server. SQL Server 2005 i SQL Server 2008 obsługują triggery wyzwalane przez in-strukcje Data Manipulation Language (DML) oraz instrukcje Data Dafinition Language (DDL). Ogólna postać triggera została przed-stawiona w ramce

Triggery, podobnie jak procedury i funk-cje składowane podlegają następującym fazom przetwarzania – analiza składniowa, tłumacze-nie nazw i optymalizacja. Jednak w przeciwień-stwie do procedur i funkcji składowanych trig-gery nie mają swojego interfejsu, czyli nie posia-dają parametrów wejściowych i wyjściowych i nie można wywoływać ich w sposób jawny. Są one uruchamiane w sposób automatyczny, ja-ko reakcja na zdarzenie, które zaszło na serwe-rze baz danych.

Triggery są również częścią transakcji, która spowodowała ich uruchomienie. Oznacza to, że transakcja nie zostanie zakończona, dopóki nie zakończy się działanie wyzwalacza.

Natomiast, jeśli wewnątrz wyzwalacza umieszczona zostanie instrukcja ROLLBACK TRAN, to wycofane zostaną nie tylko skutki

działania triggera, ale także skutki działania innych instrukcji uruchomionych w danej transakcji (czyli od momentu jawnego użycia instrukcji BEGIN TRAN lub od początku wyko-nywanego kodu w przypadku braku instruk-cji BEGIN TRAN).

SQL Server 2005 i SQL Server 2008 po-zwalają na tworzenie triggerów dla instruk-cji INSERT, UPDATE, DELETE (czyli dla instruk-cji DML) oraz dla instrukcji CREATE, ALTER, DROP (czyli instrukcji DDL). Natomiast nie jest możliwe utworzenie wyzwalacza dla in-strukcji SELECT, a także wyzwalacza urucha-mianego przed instrukcją (czyli wyzwalacza typu BEFORE). Najbardziej zbliżone działanie do triggera typy BEFORE można uzyskać stosu-jąc trigger typu INSTEAD OF.

Tabele INSERTED i DELETEDWewnątrz triggera mamy dostęp do sta-rej i nowej wersji modyfikowanych wier-szy – dzieje się tak dzięki tabelom specjal-nym INSERTED i DELETED. Tabela IN-SERTED zawiera nowy obraz modyfikowa-nych wierszy, a tabela DELETED stary ob-raz. Oczywiście tabela INSERTED będzie zawierać dane tylko i wyłącznie w przypad-ku triggerów uruchamianych przez instruk-cje INSERT i UPDATE. Natomiast dla wyzwala-czy uruchamianych przez instrukcję DELETE będzie pusta.

Tabele INSERTED i DELETED mają taką sa-mą strukturę jak tabele, dla których zdefinio-wano wyzwalacz.

Ale trzeba pamiętać, że na tabelach tych nie są założone indeksy, dlatego każde zapy-tanie SELECT uruchomione na takiej tabeli oznacza skanowanie całej tabeli. Istnieją oczy-wiście pewne wyjątki od tej zasady – np. jeśli użyjemy predykatu TOP wraz z klauzulą ORDER BY, to serwer nie będzie musiał skanować ca-łej tabeli.

Tabele INSERTED i DELETED zostały w odmienny sposób zdefiniowane w SQL Se-rver 2000 oraz w kolejnych wersjach SQL Server 2005 i 2008. W SQL Server 2005 i SQL Server 2008 tabele te są widokami opartymi na sekcji dziennika zdarzeń, któ-ry zawiera zapis rekordów modyfikowanych przez instrukcję powodującą uruchomienie wyzwalacza.

Tak więc każde zapytanie skierowane do tabel INSERTED lub DELETED oznacza ko-nieczność skanowania dziennika transakcji, który zapisywany jest w sposób sekwencyj-ny. To może okazać się wąskim gardłem dla systemu biznesowego przetwarzającego du-żą liczbę transakcji. W SQL Serwer 2005 i SQL Server 2008 rozwiązano ten problem poprzez zastosowanie bazy tempdb. Otóż w SQL Server 2005 i SQL Server 2008 tabele INSERTED i DELETED wskazują na ozna-czane numerami wersji wiersze w bazie da-nych tempdb. Samo oznaczanie numerami wersji wierszy w tabelach bazy danych jest nową techniką zastosowaną po raz pierwszy w SQL Server 2005, która wykorzystywana jest przy obsługiwaniu nowych poziomów izolacji obrazów migawkowych, wyzwalaczy, operacji na indeksach.

Jak już wspomniałem technologia ta po-zwala na przechowywanie w bazie tempdb wcześniejszych wersji danych. Na potrze-by wyzwalaczy zapisywane są dane modyfi-kowane przez instrukcję wyzwalającą przed jej uruchomieniem i po jej uruchomieniu. Z tego też względu tabele INSERTED i DE-LETED używają bazy tempdb, a nie dzienni-

Wyzwalacze w aplikacjach biznesowychW artykule zostaną omówione kwestie związane z wykorzystaniem wyzwalaczy w aplikacjach biznesowych – triki pozwalające na nieuruchamianie wyzwalacza dla określonych wierszy oraz niezwykle istotną z punktu widzenia aplikacji biznesowych kwestię wykorzystywania wyzwalaczy na perspektywach.

Dowiesz się:• Jak używać aplikacji biznesowych;

• Jak zapewnić bezpieczeństwo w aplikacjach

biznesowych używając wyzwalaczy;

• Jakie negatywne skutki w aplikacjach bizneso-

wych może powodować używanie dużej liczby.

Powinieneś wiedzieć:• Podstawy SQL;

• Podstawowa znajomość SQL Server 2005/

2008.

Poziom trudności

SQL Server 2005/2008

Page 43: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200842

Aplikacje biznesoweSQL Server 2005/2008

www.sdjournal.org 43

ka transakcji. Dzięki temu wyzwalacze wy-konywane są efektywniej (na bazie tempdb możliwe jest wykonywanie wielu działań, natomiast na dzienniku transakcji możli-we jest wykonywanie działań w sposób se-kwencyjny).

Jednak wykonywanie zbyt wielu wyzwa-laczy w aplikacjach biznesowych może być przyczyną słabej wydajności takich aplika-cji. Tabele INSERTED i DELETED nie są in-deksowane – z tego też względu przy dużej ilości danych operacje SELECT wykonywa-ne na tych tabelach mogą trwać długo. Jed-nak jeśli w aplikacji biznesowej potrzebu-jemy przeskanować całą tabelę INSERTED lub DELETED i potrzebne dane można uzy-skać w pojedynczym zapytaniu, to niewiele da się zrobić w celu poprawienia wydajno-ści. Natomiast jeśli musimy korzystać z ta-beli INSERTED lub DELETED w wielu ite-racjach, to lepszym rozwiązaniem jest sko-piowanie danych do innej tabeli (lub tabeli tymczasowej) za pomocą nielogowanej ope-racji SELECT INTO i założenie na nowej tabe-li indeksu.

SELECT * INTO Tymczasowa FROM Inserted

CREATE UNIQUE CLUSTERED INDEX idx_nazwa_

indeksu

ON Tymczasowa(nazwa_kolumny);

Zrozumienie działania tabel INSERTED i DELETED w SQL Server 2005 i SQL Server 2008 jest kluczem do tworzenia efektywnych aplikacji biznesowych (tak naprawdę efektyw-nie działających wyzwalaczy w tych aplika-cjach). Natomiast złe używanie tabel INSER-TED i DELETED może prowadzić do dużych problemów wydajnościowych, co w aplika-cjach biznesowych jest niedopuszczalne.

Triggery typu AFTERTriggery typu AFTER uruchamiane są po zakoń-czeniu instrukcji powodującej ich wywołanie.

Najczęstszą odmianą wyzwalaczy typu AFTER są wyzwalacze DML AFTER, czyli trigge-ry tworzone dla konkretnych tabel i konkret-nych instrukcji typu UPDATE, INSERT, DELETE. Tego typu wyzwalaczy można używać tylko i wyłącznie do tabel trwałych (nie można ich używać w stosunku do widoków i tabel tym-czasowych).

Jeśli instrukcja DML wywołująca wyzwalacz spowoduje wystąpienie błędu, to wyzwalacz nie zostanie uruchomiony.

Wyzwalacze typu AFTER są wywoływane na poziomie instrukcji, a nie na poziomie wiersza, tak więc ilość wywołań triggera nie zależy od ilości modyfikowanych wierszy.

Dla każdego obiektu i dla każdego typu in-strukcji DML można tworzyć wiele wyzwala-czy typu AFTER. Jeśli dla jednej tabeli i jedne-go typu instrukcji mamy kilka różnych wy-zwalaczy, to będą one uruchamiane sekwen-

cyjnie (jeden za drugim). SQL Server 2005 i SQL Server 2008 umożliwiają za pomocą procedury składowanej sp_settriggerorder wskazanie pierwszego i ostatniego wyzwala-cza – kolejność pozostałych wyzwalaczy nie jest określona.

Głównym zadaniem triggerów typu AFTER jest reagowanie na zmiany wykonywane na serwerze baz danych. Można ich także użyć w odpowiedzi na wykonanie instrukcji wy-zwalającej np. do zapewnienia reguł integral-ności, których nie udało się uzyskać za pomo-cą ograniczeń.

Rozpoznawanie rodzaju triggeraCzasem istnieje konieczność utworzenia jed-nego triggera dla różnych instrukcji, ale w dalszym ciągu istnieje konieczność posiada-nia wiedzy, jaka instrukcja została urucho-miona.

Np. do celów rejestracyjnych można użyć jednego wyzwalacza dla instrukcji INSERT, UPDATE, DELETE, a przy okazji można zapi-sać jaki to był rodzaj instrukcji. W celu iden-tyfikacji instrukcji można sprawdzić zawar-tość tabel INSERTED i DELETED. Jeśli użyt-kownik wykona instrukcję UPDATE, to da-ne będą znajdować się zarówno w tabeli IN-SERTED i DELETED. W przypadku instruk-cji INSERT, dane będą znajdować się tylko w tabeli INSERTED, a w przypadku instrukcji DELETE tylko w tabeli DELETED. Na Listin-gu 1 zaprezentowaliśmy kod źródłowy, któ-ry pozwala na rejestrowanie wykonywanych instrukcji.

Zmienna @@rowcount przechowuje infor-macje na temat liczby dodanych, usuniętych lub zmodyfikowanych wierszy przez ostatnią

instrukcję SQL. Gdy żaden rekord nie został zmieniony, to następuje koniec działania wy-zwalacza. W przeciwnym wypadku spraw-dzane jest, w której z tabel INSERTED lub DELETED są wiersze i wypisywany jest odpo-wiedni komunikat.

W SQL Server 2000 zamiast instrukcji IF ((SELECT COUNT(*) FROM INSERTED)>0) le-piej jest ze względów optymalizacyjnych użyć fragmentu IF EXISTS(SELECT * FROM INSERTED), gdyż sprawdzanie ilości wierszy poprzez COUNT(*) jest zdecydowanie bar-dziej kosztowne niż wykorzystanie EXISTS. Optymalizatory SQL Server 2005 i SQL Se-rver 2008 zdecydowanie lepiej radzą sobie z instrukcjami w stylu IF ((SELECT COUNT(*) FROM INSERTED)>0).

Aby sprawdzić działanie kodu z Listingu 1 należy wykonać instrukcje INSERT, UPDATE, DELETE. Dla instrukcji INSERT

INSERT INTO dbo.Osoby VALUES (Jan,

'Kowalski', 5000, 1);

otrzymamy następujący wynik:

Instrukcja INSERT

(1 row(s) affected)

W przypadku instrukcji UPDATE

UPDATE dbo.Osoby SET pensja=5500

WHERE id=1

w wyniku otrzymamy:

Instrukcja UPDATE

(1 row(s) affected)

Listing 1. Identyfikacja rodzaju wyzwalacza

CREATE TRIGGER trg_Osoby

ON dbo.Osoby

FOR INSERT, UPDATE, DELETE –- wyzwalacz na instrukcje INSERT, UPDATE, DELETE

AS

DECLARE @row_count int;

-- pobieramy ilość wierszy, które zostały dodane, zmienione, usunięte

SET @row_count = @@rowcount;

-- gdy nie zostanie zmieniony żaden wiersz ...

IF (@row_count = 0)

BEGIN

PRINT 'Nie zmieniono danych' -- ... wypisanie komunikatu ...

RETURN; -- ... i koniec triggera

END;

IF ((SELECT COUNT(*) FROM INSERTED)>0) –- jeśli są wiersze w INSERTED ...

IF ((SELECT COUNT(*) FROM DELETED)>0) -- ... i w DELETED ...

PRINT 'Instrukcja UPDATE' -- ... to wykonano instrukcję UPDATE

ELSE -- ... i nie ma wierszy w DELETED

PRINT 'Instrukcja INSERT' -- ... to wykonano instrukcję INSERT

ELSE -- w przypadku, gdy nie ma wierszy w INSERTED

PRINT 'Instrukcja DELETE'; -- to wykonano instrukcję DELETE

Page 44: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200844

Aplikacje biznesoweSQL Server 2005/2008

www.sdjournal.org 45

Natomiast w przypadku uruchomienia in-strukcji DELETE

DELETE FROM dbo.Osoby

WHERE id=1

SQL Server 2005 lub SQL Server 2008 wypi-szą komunikat:

Instrukcja DELETE

(1 row(s) affected)

Gdy wykonana zostanie instrukcja, która nie zmieni żadnych danych,

-- w bazie nie istnieje osoba o id = 300

DELETE FROM Osoby WHERE id = 300

to wyświetlony zostanie komunikat

Nie zmieniono danych

(0 row(s) affected)

Nieuruchamianie triggerów dla konkretnych instrukcji SQLNie istnieją formalne metody pozwalające uniknąć wywołania wyzwalacza dla konkret-nej instrukcji SQL.

Możliwe jest całkowite wyłączenie triggera za pomocą instrukcji

ALTER TABLE DISABLE TRIGGER

Co zrobić jednak w sytuacji, gdy trzeba za-blokować wywoływanie wyzwalacza dla konkretnej instrukcji – co w przypadku aplikacji biznesowych (o dużym poziomie skomplikowania) może być dość często wy-magane?

Trzeba opracować własną metodę – musi-my zasygnalizować, że nie chcemy wywoły-wać wyzwalacza. Jednym z trików pozwala-jących na realizację tego zadania jest użycie tabel o konkretnych nazwach – mogą to być tabele tymczasowe. Jeśli użyjesz tabel tym-czasowych, to musisz pamiętać o trzech za-sadach:

• lokalne tabele tymczasowe o konkretnej nazwie widoczne są dla tworzącej je se-sji, na poziomie wywołującym, oraz na wszystkich poziomach wewnętrznych;

• aby tabela tymczasowa zapobiegła tylko jednej próbie uruchomienia danej instruk-cji SQL, należy po powrocie do zadania wywołującego usunąć tę tabelę;

• tabele tymczasowe tworzone są w ba-zie tempdb – tak więc używając funk-cji OBJECT _ ID do sprawdzenia istnienia tabeli tymczasowej, należy używać na-zwy tabeli kwalifikowanej przy pomo-cy nazwy bazy danych. Wywołanie funk-cji OBJECT _ ID bez przedrostka tempdb w czasie połączenia z inną bazą danych za-wsze zwróci wartość NULL.

Listing 2 prezentuje wyzwalacz uruchamiany dla określonych instrukcji.

Podczas wykonywania instrukcji UPDATE na tabeli dbo.Osoby

UPDATE dbo.Osoby

SET nazwisko = 'Kowalski'

WHERE nazwisko = Nowak

trigger nie zostanie wywołany – wyświetlony zostanie komunikat informujący o tym, że je-den wiersz uległ zmianie.

(1 row(s) affected)

Po usunięciu tabeli dbo.test_update

DROP TABLE dbo.test_update;

i wykonaniu instrukcji UPDATE

UPDATE dbo.Osoby SET nazwisko = 'Abacki'

WHERE nazwisko = 'Kowalski'

zobaczymy komunikat informujący, że trigger zadziałał poprawnie.

Trigger działa

(1 row(s) affected)

Funkcja COLUMNS_UPDATED i predykat UPDATE – selektywne wywoływanie wyzwalaczyTworząc aplikacje biznesowe zdarza się, że chcemy reagować tylko i wyłącznie na zmia-nę wartości niektórych kolumn. SQL Server 2005 i SQL Server 2008 pozwalają na uru-chamianie triggera w sytuacjach, gdy zmie-nione zostały tylko niektóre kolumny (np. gdy ktoś próbuje zmienić wartość klucza głównego). W SQL Server 2005 i SQL Se-rver 2008 mamy dwa mechanizmy zapew-niające selektywne uruchamianie wyzwala-czy. Są to funkcja COLUMNS_UPDATED i predy-kat UPDATE.

W predykacie UPDATE jako parametr wej-ściowy należy podać nazwę kolumny. Wyni-kiem działania instrukcji jest wartość TRUE lub FALSE w zależności od tego, czy podana w para-metrze wejściowym kolumna została zmienio-na w klauzuli SET polecenia UPDATE urucha-miającego wyzwalacz. Predykat UPDATE zwróci wartość TRUE dla każdej kolumny, jeśli polece-niem uruchamiającym wyzwalacz jest instruk-cja INSERT.

Funkcja COLUMNS_UPDATED zwraca łańcuch bajtów, w którym każdej kolumnie odpowia-da jeden bit. Bit przyjmuje wartość 1 w przy-padku, gdy kolumna została zmieniona, lub 0, gdy kolumna nie została zmieniona. Każ-dy bajt w łańcuchu reprezentuje 8 kolejnych kolumn (po jednym bicie na kolumnę) – w ramach każdego bajtu, bity uporządkowa-ne są od prawej do lewej. Oznacza to, że in-formacja o zmianie pierwszej kolumny zapi-sana jest w pierwszym bajcie po lewej stro-nie łańcucha, w pierwszym bicie znajdują-cym się po prawej stronie danego bajtu. Na-tomiast drugą kolumnę reprezentuje dru-gi bit od prawej strony w tym samym bajcie. W celu sprawdzenia, czy określone kolumny zostały zmienione, trzeba posłużyć się opera-torem bitowego iloczynu logicznego (&) po-równując mapę bitową zwróconą przez funk-cję COLUMNS_UPDATED z własną maską bitową, w której należy włączyć bity tylko interesują-cych nas kolumn.

Problemem dla osób używających funk-cji COLUMNS_UPDATED może być fakt, że bi-towy operator iloczynowy w SQL Server 2005 i SQL Server 2008 wymaga poda-nia wartości całkowitoliczbowych (lub war-tości, które można niejawnie przekształ-cić na typ całkowitoliczbowy). Z kolei sa-ma funkcja COLUMNS_UPDATED może zwró-cić wartość dłuższą niż 8 bajtów, czyli war-tość zwracana przez funkcję może nie zmie-ścić się w zmiennej największego typu całko-witoliczbowego – BIGINT. Wtedy koniecz-ne jest wyodrębnienie fragmentu zwracane-go łańcucha poprzez wykorzystanie funkcji SUBSTRING. Np. aby wyciąć kolumnę o pozy-cji @nr_kolumny wystarczy posłużyć się frag-mentem.

Ogólna postać triggera

CREATE TRIGGER [nazwa_schematu_bazy.]nazwa_wyzalacza

ON { tabela | perspektywa }

[ WITH <opcje_wyzwalacza> ]

{ FOR | AFTER | INSTEAD OF }

{ [ INSERT ] [ , ] [ UPDATE ] [ , ] [ DELETE ] }

[ WITH APPEND ]

[ NOT FOR REPLICATION ]

AS { polecenia SQL }

Po słowach kluczowych CREATE TRIGGER należy umieścić nazwę wyzwalacza (można ją poprze-dzić nazwą schematu). Następnie po słowie ON należy wskazać tabelę lub perspektywę, dla której uruchamiany będzie trigger. Wyrażenie WITH <opcje_wyzwalacza> służy do zdefiniowania opcji wyzwalacza. Kolejne dwie linie wskazują, kiedy trigger będzie uruchamiany. Po słowie kluczowym AS znajduje się ciało wyzwalacza.

Page 45: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200844

Aplikacje biznesoweSQL Server 2005/2008

www.sdjournal.org 45

SUBSTRING(COLUMNS_UPDATED(), (@nr_kolumny

– 1) / 8 + 1, 1)

Maskę, którą trzeba przygotować, aby spraw-dzić, czy dany bit ma wartość 1 lub 0, generu-je się poprzez podnoszenie liczby 2 do potęgi o jeden mniejszej niż pozycja danego bitu w baj-cie. Wyrażenie obliczające pozycje bitu o nu-merze @nr _ bitu w bajcie mogłoby wyglądać następująco:

(@nr _ bitu - 1) % 8 + 1

, a wyrażenie generujące maskę:

POWER(2, (@nr _ bitu-1) % 8).

W celu sprawdzenia wartości bitu należy prze-prowadzić operacje bitowego iloczynu pomię-dzy przygotowaną maską, a wartością zwraca-ną przez funkcję COLUMNS _ UPDATED. Wyraże-nie takie może wyglądać następująco:

IF SUBTRING(COLUMNS_UPDATED(), (@nr_kolumny

– 1) / 8 + 1, 1) &

POWER(2, (@nr_bitu - 1) % 8) > 0 -- kolumna

została zmieniona

Po zapoznaniu się z teoretycznymi wiadomo-ściami, nadszedł czas, aby zaprezentować wy-zwalacz, który korzysta z funkcji COLUMNS _

UPDATED (Listing 3). Naszym celem będzie wy-pisanie komunikatu, jeśli w instrukcji UPDATE zmieniona została kolumna pensja.

Kolumna pensja jest czwartą kolumną w ta-beli Osoby, dlatego w wyzwalaczu użyliśmy wyrażenia (4 - 1), choć nic nie stoi na prze-szkodzie, aby zamiast tego działania napisać po prostu liczbę 3. Jednak naszym zdaniem użycie wyrażenia (4 - 1) jest bardziej czytelne dla ko-goś czytającego ten kod.

Aby sprawdzić poprawność działania stwo-rzonego wyzwalacza należy wykonać dowolną instrukcję UPDATE.

UPDATE dbo.Osoby SET pensja=3300

WHERE id=1

W wyniku uruchomienia powyższego zapyta-nia otrzymamy:

Zmieniono kolumnę pensja

(1 row(s) affected)

Natomiast w przypadku zapytania UPDATE mo-dyfikującego inną kolumnę niż pensja

UPDATE dbo.Osoby SET nazwisko = 'Kowalski'

WHERE id=1

Wyzwalacz nie zostanie uruchomiony i w wy-niku otrzymamy tylko następującą informację:

(1 row(s) affected)

Na Listingu 4 zaprezentowano wyzwalacz, który zamiast funkcji COLUMNS _ UPDATED wy-korzystuje predykat UPDATE.

Kod wyzwalacza z predykatem UPDATE jest bardziej czytelny i łatwiejszy do napi-sania. Jednak w sytuacjach, gdy chcemy sprawdzić, czy większa liczba kolumn zo-stała zmieniona, lepiej jest używać funkcji COLUMNS_UPDATED.

Operacje wykonywane w trigge-rze na wybranych wierszachTriggery mogą również wykonywać opera-cje na poszczególnych wierszach, albo odpo-wiednio reagować w zależności od wartości przechowywanych w poszczególnych wier-szach. W wyzwalaczach można używać kur-sorów, tworzyć tabele. W aplikacjach bizne-sowych tego typu możliwości triggerów moż-

Listing 2. Przykład wyzwalacza uruchamianego dla określonej instrukcji

USE test;

GO

-- jeśli istnieje tabela dbo.test_update ...

IF OBJECT_ID('dbo.test_update') IS NOT NULL

DROP TABLE dbo.test_update; -- ... to ją usuwamy

GO

-- tworzymy tabelę, dzięki której nie uruchomimy wyzwalacza

CREATE TABLE dbo.test_update

(

kolumna INT

)

GO

-- jeśli istnieje wyzwalacz dbo.trg_UPDATE ...

IF OBJECT_ID('dbo.trg_UPDATE') IS NOT NULL

DROP TRIGGER dbo.trg_UPDATE; -- ... to go usuwamy

GO

-- tworzymy wyzwalacz ...

CREATE TRIGGER trg_UPDATE

ON dbo.Osoby -- ... na tabeli dbo.Osoby ...

FOR UPDATE -- ... dla instrukcji UPDATE

AS

-- jeśli tabela dbo.test_update istnieje ...

IF OBJECT_ID('dbo.test_update') IS NOT NULL

RETURN; -- ... to kończymy działanie wyzwalacza ...

PRINT 'Trigger działa'; -- ... w przeciwnym wypadku wyzwalacz normalnie działa

GO

Listing 3. Przykład użycia funkcji COLUMNS_UPDATED wewnątrz wyzwalacza

-- jeśli w bazie jest wyzwalacz ...

IF OBJECT_ID('dbo.trg_columns_updated') IS NOT NULL

DROP TRIGGER dbo.trg_columns_updated; -- ... to go usuwamy

GO

-- tworzymy wyzwalacz ...

CREATE TRIGGER dbo.trg_columns_updated

ON dbo.Osoby -- ... na tabeli Osoby ...

FOR UPDATE -- ... na instrukcję UPDATE

AS

-- jeśli bitowy iloczyn wartości zwracanej przez funkcję COLUMNS_UPDATED ...

IF SUBSTRING(COLUMNS_UPDATED(), (4 - 1) / 8 + 1, 1) &

POWER(2, (4 - 1) % 8) > 0 -- ... i maski przygotowanej przez nas ...

-- ... jest większy od 0 to wyświetlany jest komunikat ...

PRINT 'Zmieniono kolumnę pensja'

ELSE -- ... w przeciwnym wypadku

RETURN; -- ... działane wyzwalacza jest kończone

Page 46: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200846

Aplikacje biznesoweSQL Server 2005/2008

www.sdjournal.org 47

na wykorzystać do audytu (śledzenia zmian) niektórych tabel. Na Listingu 5 zaprezento-wano wyzwalacz, który będzie tworzył in-strukcje UPDATE dla poszczególnych wierszy, które zostały zmodyfikowane w tabeli Oso-by dowolną instrukcją UPDATE. Dzięki dzia-łaniu wyzwalacza będziemy w stanie stwier-dzić, w jaki sposób zmienione zostały po-szczególne wiersze w tabeli Osoby i w razie potrzeby przywrócić starą wersję danych w danym wierszu.

Na początku stworzono tabelę, która bę-dzie przechowywać informacje dotyczące daty oraz treść instrukcji zmieniającą po-szczególne wiersze. Po stworzeniu tabe-li, która będzie przechowywała nasze logi, należy stworzyć trigger (Listing 5). W wy-zwalaczu tym zastosowane zostaną różne-go rodzaju triki, które mogą zwiększyć je-go efektywność (poszczególne instrukcje zo-stały opisane w postaci komentarzy na Li-stingu 5).

W wyzwalaczu wykorzystano kilka trików, które mogą przyspieszyć wykonywane dzia-łania:

• skopiowano zawartość tabel INSERTED i DELETED do tabel tymczasowych za po-mocą nielogowanej, a co za tym idzie bar-dzo szybkiej operacji SELECT INTO. Oczy-wiście, aby możliwe było skopiowanie da-nych w ten sposób nie może istnieć tabela docelowa;

• na utworzonych tabelach tymczasowych założone zostały indeksy, które przyspie-szają działania związane z pobieraniem danych;

• kursor wewnątrz wyzwalacza utworzono z opcją FAST _ FORWARD.

Teraz można napisać instrukcje UPDATE na ta-beli Osoby, która zmieni kilka wierszy. Wy-zwalacz powinien zapisać odpowiednie za-pytanie SQL dla każdego z modyfikowanych wierszy.

-- wszystkim osobom zarabiający 3000 zł

i więcej zmieniono pensje na 3500 zł

UPDATE dbo.Osoby SET pensja = 3500

WHERE pensja >= 3000

Powyższa instrukcja zmieniła cztery wier-sze. Dla każdego z wierszy zapisana została w tabeli logów (Osoby _ log _ update) odpo-wiednia instrukcja UPDATE. Oczywiście nie jest to najbardziej optymalny sposób logo-wania operacji (zamiast budować instrukcję UPDATE można zapisać poszczególne wartości pól), ale wskazuje sposób postępowania w ta-kich sytuacjach.

Triggery typu INSTEAD OFTriggery typu INSTEAD OF uruchamiane są zamiast oryginalnej instrukcji SQL przepro-wadzanej na określonym obiekcie. Nie są to triggery działające na zasadzie BEFORE, któ-re są uruchamiane przed oryginalną instruk-cją, ale takie, które są uruchamiane zamiast tej instrukcji. Oryginalna instrukcja nigdy nie zo-stanie wykonana. Wyzwalacze typu INSTEAD OF mają duże znaczenie w przypadku tworze-nia aplikacji biznesowych. Otóż tworząc apli-kacje biznesowe musimy zapewnić bezpie-czeństwo danych. Z tego też względu użyt-kownikom bardzo często udostępniane są wi-doki (zamiast tabel) zawierające tylko wyma-gane do pracy danego użytkownika informa-cje. Czasem jednak zachodzi konieczność, aby ten użytkownik zmodyfikował lub dodał dane do oryginalnej tabeli.

Oczywiście użytkownik nie wie, że dane, które ogląda pochodzą z widoku, a nie tabeli. A więc, jeśli otrzyma polecenie dodania wpi-su, spróbuje tę czynność wykonać na dobrze znanym mu widoku. W takiej sytuacji moż-na użyć wyzwalacza typu INSTEAD OF, któ-ry sprawdza poprawność wprowadzanych danych i wstawia dane do oryginalnej tabe-li (triggery typu INSTEAD OF można tworzyć na widokach w przeciwieństwie do trigge-rów typu AFTER).

Triggery typu INSTEAD OF mają wiele zalet, które są niezwykle przydatne przy tworzeniu aplikacji biznesowych:

• mogą być stosowane do omijania ograni-czeń modyfikacji przeprowadzanych na perspektywach – np. w perspektywach nie można aktualizować kolumn będą-cych wynikiem kalkulacji, lub agregacji. Stosując wyzwalacze typu INSTEAD OF można przeprowadzić analizę instrukcji SQL i wykonać odpowiedni kod na uży-wanych w perspektywie kolumnach tabel źródłowych;

• są uruchamiane przed sprawdzeniem zde-finiowanych ograniczeń – dzięki temu możliwa jest identyfikacja działań, które normalnie nie powiodłyby się i zastąpie-nie tych działań poprawnym kodem, któ-ry nie będzie naruszał ograniczeń.

Listing 6 prezentuje działanie wyzwalacza ty-pu INSTEAD OF. Instrukcję INSERT wstawiają-ca dane do tabeli Osoby zastąpiono wyzwala-czem typu INSTEAD OF, który sprawdza, czy pensja dodawanej osoby jest większa od 0. Je-śli tak nie jest, to instrukcja wstawienia nie jest wykonana.

Próba wykonania instrukcji INSERT

-- próba dodania osoby, z pensją 0 zł

zakończy się niepowodzeniem

INSERT INTO dbo.Osoby

VALUES('Albert', 'Bielecki', 1000, 1);

nie spowoduje dodania wiersza do tabeli Osoby.Zwracamy szczególną uwagę na fakt, że trig-

ger typu INSTED OF działa ZAMIAST wywołu-jącej go instrukcji. Tak więc, jeśli w kodzie wy-zwalacza, zostanie pominięta instrukcja wywo-łująca wyzwalacz (w ciele triggera nie będzie in-strukcji INSERT wstawiającej dane do tabeli), to żadne zmiany nie zostaną wykonane.

Wyzwalacze i perspektywyW aplikacjach biznesowych ze względów bez-pieczeństwa użytkownikom końcowym bar-dzo często udostępniane są perspektywy za-miast oryginalnych tabel. Aktualizacja, do-danie lub usunięcie danych z perspektywy bardzo często nie jest możliwe. I tu z pomo-cą przychodzą wyzwalacze typu INSTEAD OF. Dzięki wyzwalaczom można także sprawdzić poprawność instrukcji próbującej dodać, mo-dyfikować lub usunąć dane z perspektywy. Można także zablokować wpisywanie niepo-prawnych wartości.

Możliwe jest udostępnienie użytkownikowi dodawania danych do tabel, mimo że tabele te mogą nie być widoczne (użytkownikowi udo-stępniona może być tylko perspektywa). Dzię-ki takiemu podejściu funkcjonalność aplikacji nie jest ograniczana, a bezpieczeństwo (co w przypadku aplikacji biznesowych jest bardzo

Listing 4. Przykład użycia predykatu UPDATE wewnątrz wyzwalacza

IF OBJECT_ID('dbo.trg_update') IS NOT NULL

DROP TRIGGER dbo.trg_update;

GO

CREATE TRIGGER dbo.trg_update

ON dbo.Osoby

FOR UPDATE

AS

IF UPDATE(pensja) -- jeśli kolumna pensja została zmieniona ...

PRINT 'Zmieniono kolumnę pensja' -- ... wypisywany jest komunikat

ELSE -- ... w przeciwnym wypadku ...

RETURN; -- ... wyzwalacz jest kończony

Page 47: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200846

Aplikacje biznesoweSQL Server 2005/2008

www.sdjournal.org 47

Listing 5. Kod służący do audytu tabeli

USE test;

GO

-- jeśli tabela istnieje w bazie danych ...

IF OBJECT_ID('dbo.Osoby_log_update') IS NOT NULL

DROP TABLE dbo.Osoby_log_update; -- ... to ją usuwamy

GO

-- tworzymy nową tabelę zawierającą dwie kolumny

CREATE TABLE dbo.Osoby_log_update

(

Data DATETIME,

instrukcja VARCHAR(300)

);

-- jeśli istnieje wyzwalacz w bazie danych ...

IF OBJECT_ID('dbo.trg_log_update') IS NOT NULL

DROP TRIGGER dbo.trg_log_update; -- ... to go usuwamy

GO

-- tworzymy nowy wyzwalacz ...

CREATE TRIGGER dbo.trg_log_update

ON dbo.Osoby -- ... na tabeli Osoby ...

FOR UPDATE -- ... dla instrukcji UPDATE

AS

-- dane z tabel inserted i deleted kopiowane są za pomocą

szybkiej

-- nielogowanej instrukcji SELECT INTO do nowych tabel, na

których

-- zakładany jest indeks w celu przyspieszenia działań w

kursorze

IF OBJECT_ID('dbo.___tmp_deleted') IS NOT NULL

DROP TABLE dbo.___tmp_deleted; -- jeśli istnieje tabela,

to jest usuwana

-- skopiowanie tabeli deleted do nowej tabeli za pomocą

nielogowanej (szybkiej!!!)

-- instrukcji SELECT INTO

SELECT * INTO dbo.___tmp_deleted FROM Deleted;

-- założenie indeksu na tabeli

CREATE UNIQUE CLUSTERED INDEX idx_del

ON ___tmp_deleted(Id);

IF OBJECT_ID('dbo.___tmp_inserted') IS NOT NULL

DROP TABLE dbo.___tmp_inserted;

SELECT * INTO dbo.___tmp_inserted FROM Inserted;

CREATE UNIQUE CLUSTERED INDEX idx_ins

ON ___tmp_inserted(Id);

-- deklaracja zmiennych

DECLARE

@ins_Id INT,

@ins_Imie VARCHAR(20),

@ins_Nazwisko VARCHAR(30),

@ins_Pensja MONEY,

@ins_Id_dzialu INT,

@del_Id INT,

@del_Imie VARCHAR(20),

@del_Nazwisko VARCHAR(30),

@del_Pensja MONEY,

@del_Id_dzialu INT,

@sql VARCHAR(300); -- ... i zmiennej

przechowującej kod zapytania

-- deklaracja kursora, pobierającego dane z tabel

DECLARE cur_del CURSOR FAST_FORWARD FOR

SELECT

ins.Id,

ins.Imie,

ins.Nazwisko,

ins.Pensja,

ins.Id_dzialu,

del.Id,

del.Imie,

del.Nazwisko,

del.Pensja,

del.Id_dzialu

FROM dbo.___tmp_inserted ins, dbo.___tmp_deleted del

WHERE ins.Id = del.Id;

-- otwieranie kursora

OPEN cur_del;

-- pobranie danych z kursora do zmiennych

FETCH NEXT FROM cur_del INTO

@ins_Id, @ins_Imie, @ins_Nazwisko, @ins_Pensja, @ins_Id_dzialu,

@del_Id, @del_Imie, @del_Nazwisko, @del_Pensja, @del_Id_dzialu;

-- dopóki są dane w kursorze

WHILE @@FETCH_STATUS = 0

BEGIN

-- tworzenie instrukcji UPDATE aktualizującej wartości

poszczególnych

-- kolumn w tabeli Osoby – dzięki tej instrukcji będzie można

przywrócić

-- starsze wartości poszczególnych pól

SET @sql = 'UPDATE dbo.Osoby SET '

+ 'Imie = ' + QUOTENAME(@ins_Imie, '''') + ', '

+ 'Nazwisko = ' + QUOTENAME(@ins_Nazwisko ,'''') + ', '

+ 'Pensja = ' + CAST(@ins_Pensja AS VARCHAR) + ', '

+ 'Id_dzialu = ' + cAST(@ins_Id_dzialu AS VARCHAR) + ' '

+ 'WHERE '

+ 'Id = ' + CAST(@ins_Id AS VARCHAR) + ' AND '

+ 'Imie = ' + QUOTENAME(@ins_Imie, '''') + ' AND '

+ 'Nazwisko = ' + QUOTENAME(@ins_Nazwisko, '''') + ' AND '

+ 'Pensja = ' + CAST(@ins_Pensja AS VARCHAR) + ' AND '

+ 'Id_dzialu = ' + CAST(@ins_Id_dzialu AS VARCHAR);

-- wstawienie daty i kodu instrukcji do tabeli logów

INSERT INTO dbo.Osoby_log_update (Data, instrukcja)

VALUES(getdate(), @sql);

-- pobranie kolejnego wiersza z kursora

FETCH NEXT FROM cur_del INTO

@ins_Id, @ins_Imie, @ins_Nazwisko, @ins_Pensja, @ins_Id_

dzialu,

@del_Id, @del_Imie, @del_Nazwisko, @del_Pensja, @del_Id_

dzialu;

END; -- koniec pętli

CLOSE cur_del; -- zamknięcie kursora

DEALLOCATE cur_del; -- zwolnienie zasobów związanych z

kursorem

-- usunięcie tabel tymczasowych

IF OBJECT_ID('dbo.___tmp_deleted') IS NOT NULL

DROP TABLE dbo.___tmp_deleted;

IF OBJECT_ID('dbo.___tmp_inserted’) IS NOT NULL

DROP TABLE dbo.___tmp_inserted;

Page 48: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200848

Aplikacje biznesowe

ważne) jest zdecydowanie większe. Dzięki wy-zwalaczowi typu INSTEAD OF instrukcja SQL pozwoli dodać dane do tabeli (a perspektywa zostanie zaktualizowana)

Rekurencyjne i zagnieżdżone wywoływanie triggerówSQL Server 2005 i SQL Server 2008 obsłu-gują rekurencyjne i zagnieżdżone wywoła-nia triggerów. Z zagnieżdżonym wywoła-niem wyzwalaczy mamy do czynienia, gdy je-den wywołany trigger powoduje uruchomie-nie innego wyzwalacza. Natomiast rekuren-cyjne wywołanie zachodzi wówczas, gdy wy-zwalacz uruchamia sam siebie bezpośrednio lub poprzez inne instrukcje. Domyślnie re-kurencyjne wywoływanie triggerów w SQL Server 2005 i SQL Server 2008 jest wyłączo-ne. Aby więc włączyć rekurencyjne wywoły-wanie wyzwalaczy (np. na bazie test) należy uruchomić polecenie:

ALTER DATABASE test

SET RECURSIVE_TRIGGERS ON

Ponowne wyłączenie rekurencyjnych wywo-łań wyzwalaczy zachodzi po wykonaniu po-lecenia:

ALTER DATABASE test

SET RECURSIVE_TRIGGERS OFF

Używanie rekurencyjnych i zagnieżdżonych wywołań wyzwalaczy w aplikacjach bizneso-

wych powinno być ograniczone – ze wzglę-du na wydajność oraz możliwość popełnienia błędów. Procedury rekurencyjne wymaga-ją kontroli, aby nie były wywoływane w nie-skończoność. Na szczęście SQL Server 2005 i SQL Server 2008 nie pozwolą na urucha-mianie wyzwalaczy w nieskończoność, ponie-waż mają zakodowane ograniczenie do 32 po-ziomów zagnieżdżenia. Gdy następuje próba wywołania po raz 33 wyzwalacza, to zgłasza-ny jest błąd i wszystkie operacje wykonane w remach 32 wywołań są wycofywane. Należy również pamiętać, że wyzwalacze wywoływa-ne są również wtedy, gdy instrukcja wywołu-jąca je, nie zmodyfikuje żadnego wiersza. Je-śli w takim wypadku uruchomione zostanie rekurencyjne wywoływanie wyzwalacza, to cały proces zakończy się po 32 wywołaniu. W aplikacjach biznesowych sytuacja taka nigdy nie powinna następować (ze względu na du-że wymagania dotyczące wydajności takich aplikacji). Oczywiście w aplikacjach bizneso-wych najlepiej jest nie stosować rekurencyj-nych wywołań triggerów. Jednak, gdy nie je-steśmy w stanie uniknąć rekurencyjnego wy-wołania wyzwalacza to konieczne jest wpro-wadzanie kontroli przerywania rekurencji w miejscu, w którym trigger nie powinien być już wywoływany.

Wyzwalacze uruchamiane na poziomie bazy danychWyzwalacze można uruchamiać nie tylko na poziomie obiektu bazy danych. Można je tak-

że uruchamiać na poziomie bazy danych. Ogól-na składnia takiego wyzwalacza wygląda nastę-pująco:

CREATE TRIGGER nazwa_wyzwalacza

ON DATABASE

FOR rodzaj_instrukcji

AS { polecenia SQL }

Rodzaj _ instrukcji może przybierać róż-nego rodzaju wartości np. CREATE _ TABLE, CREATE _ VIEW, DDL _ DATABASE _ LEVEL _

EVENTS itp. Wyzwalacze na poziomie bazy danych mo-

gą pełnić bardzo ważne role w aplikacjach biz-nesowych np. mogą sprawdzać, czy użytkow-nik próbuje tworzyć tabele bez klucza głów-nego (i zgłaszać wyjątek w takich sytuacjach), lub logować operacje DDL wykonywane na ba-zie danych.

Wyzwalacze uruchamiane na poziomie serwera baz danychWyzwalacze można także uruchamiać na po-ziomie serwera baz danych. Funkcjonalność ta może przydać się do logowania operacji wyko-nywanych na poziomie serwera (np. tworze-nie, usuwanie loginów). Aby wyzwalacz dzia-łał na poziomie serwera musi być uruchomio-ny z opcją ON ALL SERVER.

Podsumowanie W artykule tym zaprezentowano kilka trików, których wykorzystanie może znacznie upro-ścić tworzenie rozwiązań biznesowych. Jed-nak samo używanie wyzwalaczy nie przynosi korzyści w postaci dużej wydajności – szcze-gólnie należy unikać rekurencyjnych i za-gnieżdżonych wywołań wyzwalaczy. Rekom-pensatą używania triggerów jest większe bez-pieczeństwo danych i obiektów w aplikacjach biznesowych. Tak więc jeśli chcesz zapewnić bezpieczeństwo i nie zależy Ci na dużej wy-dajności aplikacji – to używaj widoków z połą-czeniu z triggerami. Jeśli priorytetem jest wy-dajność aplikacji biznesowej, to należy unikać wyzwalaczy.

Listing 6. Przykład wyzwalacza typu INSTEAD OF

-- jeśli w bazie jest wyzwalacz ...

IF OBJECT_ID('dbo.trg_osoby_1') IS NOT NULL

DROP TRIGGER dbo.trg_osoby_1; -- ... to usuwamy go

GO

-- tworzymy nowy wyzwalacz ...

CREATE TRIGGER dbo.trg_osoby_1

ON dbo.Osoby -- ... na tabeli Osoby ...

INSTEAD OF INSERT -- ... wykonywany zamiast instrukcji INSERT

AS

-- sprawdzamy, czy pensja jest większa od 0

-- jeśli nie, to kończymy działanie wyzwalacza (instrukcja INSERT

-- nie zostanie wykonana)

IF (SELECT pensja FROM INSERTED) <= 0 RETURN;

-- jeśli pensja jest większa od 0, to piszemy odpowiednią instrukcję INSERT

-- wstawiającą dane do tabeli Osoby

INSERT INTO dbo.Osoby (imie, nazwisko, pensja, id_dzialu)

SELECT imie, nazwisko, pensja, id_dzialu FROM INSERTED;

ARTUR MOŚCICKIArtur Mościcki jest z wykształcenia informaty-

kiem. Obecnie pracuje jako programista baz da-

nych i hurtowni danych. Ma również doświad-

czenie w tworzeniu aplikacji BI dla dużych i śred-

nich firm. Jest współautorem książek: Oracle 10g

i Delphi. Programowanie baz danych,SQL Se-

rver 2005. Zaawansowane rozwiązania bizne-

sowe oraz Photoshop. Pluginy i efekty specjalne.

Oprócz hurtowni i baz danych, jego drugą infor-

matyczną pasją jest fotografia cyfrowa i obrób-

ka zdjęć za pomocą Adobe Photoshop. W wol-

nych chwilach kibicuje piłkarskiej reprezentacji

Argentyny.

Kontakt z autorem: [email protected]

Page 49: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5
Page 50: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200850

Narzędzia programistyczneLokal zamienię od zaraz

www.sdjournal.org 51

Problem przeróbki aplikacji do funkcjo-nowania w nowej wersji systemu ope-racyjnego może okazać się niebagatel-

ny. Nawet jeśli same zmiany w aplikacji nie są skomplikowane, przejście przez stosowną część cyklu jej rozwoju zajmuje czas – prze-ważnie najcenniejszy zasób w projektach in-formatycznych.

Niestety, nierzadko oprócz przerabiania kodu samej aplikacji typu enterprise, trze-ba uwzględnić jej integrację z nowym środo-wiskiem operacyjnym – nowe metody star-towania, zmiany niektórych komend syste-mu operacyjnego i formatu ich wyników, po-nowną instalację i konfigurację usług pomoc-niczych, itp.

W efekcie oprócz zmian w aplikacji typu en-terprise, powstają istotne zmiany w przygoto-wanym dla niej środowisku, co z kolei wymu-sza opracowanie i opisanie procedur obsługi takiego nowego środowiska. To znowu wyma-ga czasu, którego i tak już brakuje.

Tymczasem klient czy użytkownik czę-sto nalega na szybką modernizację systemu operacyjnego ze względu na obsługę nowego sprzętu, utrzymanie jednolitości w swoim śro-dowisku IT, z powodu kończącego się wsparcia serwisowego dla starej wersji, czy chcąc ogra-

niczyć koszta utrzymania przez konsolidację wielu aplikacji na jednym serwerze.

Kwestia modernizacji środowiska operacyj-nego Solaris bez konieczności zmiany aplika-cji została dobrze rozwiązana przez firmę Sun Microsystems w roku 1997 i już od tej pory, czyli od Solaris w wersji 2.6, obowiązuje gwa-rancja zgodności (Solaris Application Guaran-tee [1]) – aplikacja napisana poprawnie dla poprzedniej wersji Solaris będzie mogła dzia-łać bez modyfikacji na każdej kolejnej wer-sji Solaris.

Pozostają jednak otwarte kwestie, co zro-bić, jeśli aplikacja nie spełnia warunków Sola-ris Application Guarantee, albo jeśli pozostaje bardzo ograniczony czas na dopracowanie i te-stowanie środowiska dla aplikacji.

Przeprowadzki w kontenerach z logo SunSun Microsystems zaproponował ostatnio no-watorski sposób na odsunięcie w czasie mo-dernizacji sprzętu i systemu operacyjnego od modernizacji aplikacji i jej środowiska. W po-staci produktów Solaris 8 Containers oraz So-laris 9 Containers (poprzednie nazwy to Sola-ris 8 Migration Assistant, czy Project Etude) wy-korzystano wcześniejsze mechanizmy opraco-wane przez Sun:

• Solaris Zones, czyli możliwość jednocze-snego uruchamiania na jednym kompu-terze wielu oddzielnych, wirtualnych środowisk operacyjnych;

• BrandZ, poszerzające Solaris Zones o moż-liwość uruchamiania środowisk operacyj-nych opartych na odmiennych systemach operacyjnych, nawet pochodzących od różnych producentów;

• Solaris Binary Application Guarantee, któ-ra przekłada się na stabilność API.

Szybkie przenosinyPrzy zastosowaniu Solaris 8 Containers podsta-wowe kroki migracji aplikacji wraz z jej środo-wiskiem wyglądają następująco (Rysunek 1):

• instalacja na sprzęcie nowego serwera śro-dowiska operacyjnego Solaris 10;

• utworzenie w Solaris 10 przynajm-niej jednej pełnej (whole-root) zony typu SUNWsolaris8 i przekopiowanie na nią obrazu istniejącego dotąd środowiska operacyjnego Solaris 8. Obraz istniejące-go środowiska można utworzyć komen-dą cpio(1), można też użyć bardziej za-awansowanych narzędzi Solaris. Obraz dotychczasowego środowiska operacyj-nego może zawierać również dane aplika-cji; jednak dane aplikacji można również przenieść inną metodą – na przykład po-przez przełączenie zawierających je wolu-minów pamięci masowej w sieci SAN do nowego serwera;

• automatyczne uruchomienie narzędzia P2V (Physical to Virtual), które dokona kilku kroków przystosowujących obraz Solaris 8 do działania w środowisku wir-tualnym;

• start zony wraz z całym środowiskiem aplikacji, i start samej aplikacji.

Analogicznie przenosi się aplikację przy sto-sowaniu Solaris 9 Containers.

Ponieważ Solaris 8 Containers czy Solaris 9 Containers działają w zonach typu whole-root, czyli maja własne, kompletne kopie całego śro-dowiska aplikacji, można w ramach jednego

Lokal zamienię od zaraz

Oprócz przystosowania samej aplikacji typu enterprise do nowej wersji systemu operacyjnego, trzeba uwzględnić jej integrację z nowym środowiskiem – metody startowania, zmiany komend systemu operacyjnego, konfigurację usług pomocniczych, itp. Z Solaris można przenosić całe, niezmienione środowiska aplikacji.

Dowiesz się:• Jak wykorzystać środki dostępne w Solaris 10

do stworzenia wydzielonego środowiska dla

aplikacji;

• Jak produkty Solaris 8 Containers i Solaris 9 Con-

tainers zapewniają zgodność środowiska działa-

nia aplikacji z poprzednimi wersjami Solaris.

Powinieneś wiedzieć:• Co to jest Solaris i jak się nim administruje w

podstawowym zakresie;

• Jakie wyzwania pojawiają się przy moderniza-

cji aplikacji typu enterprise;

• Na czym polegają techniki wirtualizacji i emu-

lacji.

Poziom trudności

Jak szybko przenieść aplikację do środowiska operacyjnego Solaris 10

Page 51: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200850

Narzędzia programistyczneLokal zamienię od zaraz

www.sdjournal.org 51

systemu z Solaris 10 równocześnie użytkować wiele Solaris 8 Containers oraz Solaris 9 Conta-iners, i to każdy z nich z odrębnym zakresem poprawek (patches).

Organizacyjnie rzecz biorąc, w opisany po-wyżej sposób dokonuje się częściowa migracja aplikacji do środowiska operacyjnego Solaris 10 – mimo iż sama aplikacja i jej bezpośred-nie środowisko nie ulegają zauważalnej zmia-nie, to pojawia się nowy system operacyjny wynikający z zastosowania Solaris 10 oraz być może nowy serwer. Jest to sytuacja, która ma szanse spełnić podstawowe oczekiwania klien-ta, a wciąż pozostawia dowolnie długi czas na rozpoznanie i przygotowanie pełnej migracji.

Pojawia się okazja do stopniowego zapozna-wania z nowym systemem i np. uaktualnia-nia procedur utrzymania. Otwierają się no-we możliwości oferowane przez Solaris 10 – wykorzystanie dynamicznego systemu pli-ków ZFS, dogłębna analiza wydajności skryp-

tami DTrace, czy zaawansowane automatycz-ne reakcje na awarie sprzętu i oprogramowa-nia (FMA, Predictive Self Healing). Wszyst-ko to zwiększa szanse, że projekt ostatecznej, pełnej migracji będzie sukcesem, i zaowocuje możliwie dużym wykorzystaniem potencjału nowego środowiska (Rysunek 1).

Rzeczy w kontenerachMoże nasunąć się pytanie – w której wersji systemu operacyjnego działa właściwie aplika-cja po przeprowadzce? Aby odpowiedzieć na to pytanie, przyjrzyjmy się bliżej, jak zrealizo-wane jest środowisko Solaris 8 Container (ana-logicznie działa Solaris 9 Container).

Docelowe środowisko aplikacji można po-dzielić wstępnie na dwie części:

• moduł P2V (physical to virtual) urucha-miany w czasie instalacji oraz startu (boot) środowiska;

• środowisko działania () dla aplikacji. Na środowisko dzia-

łania dla aplikacji składają się z kolei:• oryginalne środowisko Solaris 8, prze-

niesione z poprzedniego serwera. Śro-dowisko to jest automatycznie uzu-pełniane o kilka typowych poprawek (patches) Solaris 8, usuwających błędy nieakceptowalne przy pracy w infra-strukturze BrandZ lub Solaris Zones (np. poprawki do linkera, mountera). Ostatecznie są to więc oryginalne pli-ki wykonywalne i konfiguracyjne So-laris 8;

• zmienione niektóre skrypty startowe Solaris 8 z katalogu /etc/init.d. Startu-jąc zona nieglobalna nie jest na przy-kład uprawniona do samodzielnego wykrywania i konfiguracji urządzeń (devfsadm(1m), vxvm(1m)), czy pełnej konfiguracji interfejsów sieciowych. Zona nieglobalna ze względu na ogra-niczenia Solaris Zones nie może tak-że uruchamiać pewnych usług – stąd wyłączane są skrypty startowe do ser-wera NFS, serwera PPP, serwera NTP, montowania wymiennych nośników informacji (volfs(1m)), itp.

• kilka zmienionych komend Solaris 8, które np. próbują czytać informacje o konfiguracji sprzętu (prtconf(1m), prt-diag(1m), psrinfo(1m)). Z założenia So-laris Zones nie mają dostępu do ta-kich informacji. Jednak niegdysiejsi twórcy środowiska aplikacji działają-cej w Solaris 8 nie mogli być świado-mi tego ograniczenia, stąd takie ko-mendy musiały się znaleźć w Solaris 8 Container, a co więcej – mogą wyma-gać bibliotek (np. związanych z dostę-pem do nowych funkcji dzisiejszego sprzętu) dostępnych dopiero w Sola-ris 10. Aby udostępnić te biblioteki, podczas startu zony montuje się w jej katalogu /.SUNWnative, tylko do od-czytu, rodzime (native) katalogi /usr, /lib, i /platform. Oczywiście dostęp do bibliotek w tak nietypowej loka-lizacji można łatwo ograniczyć tylko dla zmodyfikowanych komend, któ-re rzeczywiście tego potrzebują.

W ramach Solaris 8 Container mieści się też jeden ładowany moduł jądra (kernel loadable module, jako /platform/<karch>/kernel/brand/sparcv9/s8_brand) służący przede wszystkim do identyfikacji wersji brandu przez jądro.

Z opisu powyższych składników środowiska działania aplikacji jasno wynika, ze potrzebne jest dodatkowe oprogramowanie, które doko-na niezbędnych przeróbek Solaris 8. I właśnie taką rolę pełni moduł P2V (physical to virtu-al), który przetwarza środowisko operacyjne przystosowane do samodzielnego działania

Rysunek 1. Migracja aplikacji i jej środowiska z wykorzystaniem Solaris 8 Containers

���������

����������

��� ���������

��������������

����������������

�����������

�����������

������������������

�����������������������

���������

���������

������

���������

Rysunek 2. Zmiany oryginalnego środowiska Solaris 8 przy przenoszeniu do Solaris 8 Container

����������������������������

������������������

��������������

����

���

����

����

����

���

����

���

����

� �

���

����

����

������

������������������������������������������

������������������������

�������������������

������������������������

����������������

����������������

�����������������������

���

������������������������������������������

�������������������

����

���

����

����

����

���

����

���

����

��

���

����

����

������

Page 52: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200852

Narzędzia programistyczneLokal zamienię od zaraz

www.sdjournal.org 53

bezpośrednio na sprzęcie, na środowisko dzia-łające w świecie Solaris Zones o ograniczonych uprawnieniach. W tym celu podczas instala-cji moduł P2V między innymi dodaje brakują-ce poprawki (patches) do Solaris 8, modyfiku-je skrypty startowe Solaris 8 z katalogu /etc/in-it.d, oraz przegląda i modyfikuje niektóre pliki konfiguracyjne Solaris 8 (Rysunek 2).

Pliki konfiguracyjne kontrolowane są na przykład w celu dezaktywacji serwera NFS (dfstab(4)), Sun Remote Services (SRS) (cron-tab(1), inittab(4)), czy Solaris Resource Mana-ger (pam.conf(4)), gdyż wiadomo, że to opro-gramowanie nie może działać w środowisku Solaris Zones.

W ramach kontroli plików konfiguracyj-nych, moduł P2V usuwa także zbędne mon-towania. W tablicy montowań (vfstab(4))

wciąż mogą się wszak znajdować wpisy doty-czące nieistniejących w nowym systemie urzą-dzeń, w tym urządzeń tworzonych przez daw-ne wersje menedżerów woluminów (volume managers).

Również plik system(4) jest analizowany, gdyż zawarte w nim ustawienia np. dotyczące komunikacji między procesami przez semafo-ry czy segmenty pamięci dzielonej nie są do-stępne w zonach nieglobalnych, i muszą być sterowane z zony globalnej.

Twórcy modułu P2V postarali się także o automatyczną zmianę nazewnictwa interfej-sów sieciowych przy przenosinach na nowy sprzęt. Maszyny z Solarisem 8 miewały in-terfejsy ethernet ze sterownikami hme czy qfe, podczas gdy współcześnie spotyka się raczej sterowniki e1000g czy ce.

Moduł P2V jest dodatkowo automatycz-nie uruchamiany przed każdym startem (bo-ot) środowiska operacyjnego i weryfikuje, czy np. nieświadome modyfikacje admini-stratora lub dodawanie poprawek (patches) nie zmieniło opisanych powyżej cech środo-wiska. Ewentualne niekorzystne zmiany są przez P2V automatycznie wycofywane.

A zatem od momentu przeprowadzki apli-kacja działa w środowisku, na które składa się jądro Solaris 10 oraz przestrzeń użytkowni-ka (userland) Solaris 8. Aplikacja może ko-rzystać z dotychczasowych usług środowiska operacyjnego Solaris 8 czy dodatkowych apli-kacji przeniesionych wraz ze środowiskiem, których konfiguracja pozostaje niezmienio-na. Aplikacja poprzez oryginalne biblioteki Solaris 8 wywołuje funkcje systemowe jądra Solaris 10. Ponieważ w dzięki Solaris Applica-tion Guarantee stosowne wywołania systemo-we pozostają niezmienione między wersjami Solaris, nie ma problemu przy współpracy starszych bibliotek z nowszym jądrem.

Jak tam na nowym?Ponieważ tak przygotowany system posia-da jądro Solaris 10, to możliwa jest praca ze wszystkimi, również najnowszymi, cecha-mi Solaris 10. Choć aplikacja przeniesiona z poprzedniego systemu nie jest ich świado-ma i nie jest w stanie wprost się do nich od-woływać, to jednak może korzystać np. z no-wych systemów plików (ZFS), podwyższonej wydajności czy niezawodności jądra. Z kolei z zony globalnej można precyzyjnie badać zachowanie aplikacji z użyciem DTrace, czy wykorzystać najnowsze osiągnięcia w zarzą-dzaniu zasobami (resource management).

Taka konstrukcja Solaris 8 Containers (i analogicznie Solaris 9 Containers) wnosi jed-nak również ograniczenia – mogą w nich działać tylko aplikacje funkcjonujące na po-ziomie użytkownika (userland, user space, user-level), a nie jądra Solaris 8. Nie można używać sterowników urządzeń z Solaris 8. Nie można ładować modułów jądra Solaris 8 – na przykład związanych z menedżerem woluminów czy firewallem. Tego typu zada-nia muszą zostać wydzielone do zony global-nej. Oprócz ograniczeń właściwych dla Sola-ris 8 Containers i Solaris 9 Containers należy wziąć pod uwagę mniejsze uprawnienia Sola-ris Zones, które mogą się okazać niewystar-czające dla starych aplikacji. Są to dość rzad-kie przypadki, jednak mogą wymagać głęb-szej analizy.

Jak zwykle przy zmienionym środowisku nasuwa się pytanie, czy działająca w nim apli-kacja może odczuć, że nie funkcjonuje w ory-ginalnym otoczeniu. Otóż nowoczesna apli-kacja, pisana ze świadomością istnienia zon i Solaris 10 jest w stanie to wykryć – wystar-czy że odwoła się do jednej z nowych funk-cji jądra Solaris 10. Stara aplikacja, pocho-

W Sieci

• http://www.sun.com/software/solaris/guarantee.jsp – szczegóły Solaris Application Guaran-tee [1]

• http://www.sun.com/software/solaris/containers/getit.jsp – strona oferująca oprogramowa-nie (21MB Product + 550MB sample Solaris image) [2]

• http://docs.sun.com/app/docs/coll/1759.1 – dokumentacja produktu [3]

Jądro a przestrzeń użytkownika w systemie operacyjnymSystem operacyjny można bardzo precyzyjnie podzielić na dwie części – jądro (kernel) i prze-strzeń użytkownika (userspace, userland). Do zadań jądra należy zarządzanie zasobami systemu, oraz zapewnienie komunikacji między sprzętem a oprogramowaniem. To jądro rozstrzyga, które z aktualnych zadań uzyska dostęp do czasu procesora. Jądro kontroluje, do których obszarów pamięci ma dostęp każde z zadań. Podczas startu (boot) systemu jądro po swojej inicjalizacji uruchamia pierwszy proces (w Unixie – proces init), i od tej pory zwykle nie realizuje zadań bezpośrednio, a tylko reaguje na zewnętrzne zdarzenia – wywołania systemowe (syscalls) ze strony aplikacji w przestrzeni użytkownika, oraz przerwania zgłaszane przez sprzęt. Dodatkowym zadaniem jądra może być wykonywanie nie-skończonej pętli gdy nie są wykonywane użyteczne zadania. Tę pętlę nazywa się procesem bez-czynności systemu (idle process). Od pierwszego uruchomionego procesu sterowanie przekazane jest do przestrzeni użytkownika (userspace, userland). Stanowią ją wszystkie elementy systemu poza jądrem, działające przeważ-nie również w oddzielnej od jądra przestrzeni adresowej. Należą do nich biblioteki do realizacji operacji wejścia-wyjścia, czy do innej interakcji z jądrem, ale także np. shell czy usługi rozwiązy-wania nazw, dzielenia plików, itp.

Co to są Solaris Zones ?W Solaris 10 wprowadzona możliwość tworzenia odizolowanych środowisk wykonania dla apli-kacji, zwanych zonami. Wszystkie zony korzystają ze wspólnego jądra systemu operacyjnego, które działa w tylko jednej kopii. Każda zona posiada jednak własne, niedostępne dla pozosta-łych zon pliki, przestrzeń procesów, urządzenia, konfigurację. Z punktu widzenia użytkownika czy aplikacji, zona wydaje się autonomicznym komputerem.Mechanizm Solaris Zones zapewnia rozdzielenie zon z punktu widzenia bezpieczeństwa, oraz znaczne uniezależnienie od awarii występujących w sąsiednich zonach. Każdy system z Solaris 10 posiada dokładnie jedną zone globalna, nadrzędną w stosunku do zon nieglobalnych, które są równorzędne wobec siebie. Konfiguracja całości systemu odbywa się z zony globalnej. Zony nieglobalne maja mniejsze uprawnienia, i pozwalają tylko na zmianę wła-snej konfiguracji.Każda zona nieglobalna może mieć komplet własnych, oddzielnych systemów plików (who-le-root zone). Jednak ze względu na łatwość utrzymania, możliwe jest współdzielenie tylko do odczytu katalogów odziedziczonych z zony globalnej (sparse-root zones). W ten sposób z zo-ny globalnej jedną operacją można dokonać np. wspólnego uaktualnienia wszystkich zon ty-pu sparse-root.Solaris 8 Containers i Solaris 9 Containers to zawsze zony nieglobalne typu whole-root. Ponieważ ich katalogi mają zawartość specyficzną dla obcego środowiska operacyjnego,więc ich współ-dzielenie z innymi zonami nie wchodzi w grę.

Page 53: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200852

Narzędzia programistyczneLokal zamienię od zaraz

www.sdjournal.org 53

dząca z czasów Solaris 8, nie powinna na-potykać przeszkód w działaniu, o ile jej wy-magania mieszczą się w zakresie wymienio-nych uprzednio możliwości zon i Solaris 8 Containers.

Kolejne zagadnienie rozpatrywane zwy-kle w emulowanych środowiskach to wydaj-ność. W tym wypadku powinna być ona zbli-żona do wydajności aplikacji działającej w So-laris 10 na nowym sprzęcie. Nie wprowadza się wszak żadnego dodatkowego kodu wyko-nywalnego na ścieżce między aplikacją a jej środowiskiem.

PodsumowanieKażdy może wypróbować Solaris 8 Conta-iners czy Solaris 9 Containers za darmo, po-zyskując oprogramowanie [2] i dokumenta-cję [3] ze strony firmy Sun Microsystems. Li-cencja pozwala na 90 dni zabawy z produk-tem. Przy używaniu produkcyjnym wyma-gana jest subskrypcja na wsparcie serwisowe producenta.

Oprogramowanie pozwala migrować tyl-ko środowiska operacyjne Solaris 8 i Sola-ris 9 – starsze wersje Solaris nie są już i tak wspierane przez Sun. Źródłowy system mo-że mieć dowolnie dawną aktualizację Sola-ris SPARC – obsługiwany jest nawet Solaris SPARC 8 FCS – czyli pierwsze wydanie So-laris SPARC 8 z marca roku 2000. Dopusz-czalne są zarówno 32-bitowe jak i 64-bito-we aplikacje.

Jako docelowe serwery mogą służyć maszy-ny z procesorami zgodnymi ze specyfikacją SPARC, z zainstalowanym co najmniej Sola-ris 10 wydanie 8/07 oraz z poprawką (patch) o symbolu 127111-01. W szczególności mo-gą to być serwery Sun CoolThreads z najnow-szymi, wielordzeniowymi i wielowątkowy-mi procesorami UltraSPARC T2, o obniżo-nym zużyciu energii elektrycznej. Tym sa-mym Solaris 8 Containers i Solaris 9 Conta-iners pozwalają w prosty, szybki sposób prze-nieść niezmienioną aplikację wraz z jej środo-wiskiem na najnowocześniejszy sprzęt i sys-tem operacyjny.

Pojawiają się natychmiastowe korzyści z za-stosowania tych nowych komponentów, mi-mo iż dopasowywanie aplikacji do nowego środowiska zostaje odsunięte w czasie. Klient może wcześniej cieszyć się większą jednolito-ścią środowiska IT, czy obniżyć koszta utrzy-mania konsolidując aplikacje z Solaris 8, So-laris 9 i Solaris 10 na jednym systemie, Czas – ważny wróg jakości w projektach informa-tycznych – został pokonany...

ARTUR OPALIŃSKIAutor jest pracownikiem Sun Microsystems. W pra-

cy wdraża elementy platformy Sun. Wolny czas wy-

pełnia mu dwójka małych dzieci.

Kontakt z autorem: [email protected]

Page 54: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200854

Testowanie oprogramowaniaInteligentne partycjonowanie zasobów

www.sdjournal.org 55

Na wystawie Embedded World 2006 firma QNX Software Systems przed-stawiła technologię inteligentnego

partycjonowania zasobów – rozszerzenie sys-temu operacyjnego czasu rzeczywistego na po-ziomie jądra. Technologia ta pozwala na two-rzenie bezpiecznych grup składających się z kilku aplikacji i wątków, pozwalając jednocze-śnie na maksymalnie efektywne wykorzysta-nie zasobów procesora. W niniejszym artyku-le przyjrzymy się dokładniej, co to jest inteli-gentne partycjonowanie zasobów i jakie zalety ma ono dla programistów i projektantów wbu-dowanych systemów czasu rzeczywistego.

Zarządzanie wątkami z zadaniami w systemach wbudowanychZ reguły wiele podsystemów, procesów i wąt-ków, które tworzą nowoczesny system, jest opracowywanych równolegle. Projekt dzie-li się na liczne grupy robocze, z których każ-da w trakcie realizacji ma swoje własne ce-le, schematy wyznaczania priorytetów za-dań i podejście do optymalizacji procesu re-alizacji.

Kiedy podsystemy te integrują się w jednym środowisku roboczym, wszystkie części syste-mu powinny zapewniać otrzymanie wymaga-nej odpowiedzi przy dowolnym scenariuszu wykonania, łącznie z pracą systemu przy stan-

dardowym załadowaniu, podczas maksymalne-go obciążenia oraz w przypadku awarii.

Przy równoległym sposobie opracowania, w procesie integrowania podsystemów stwo-rzonych przez każdą grupę programistów nie-zmiennie powstają problemy związane z wydaj-nością. W rzeczywistości, wiele z tych proble-mów pojawia się dopiero w procesie integracji

i kontrolnego testowania, kiedy wartość prze-projektowania i przekodowania oprogramowa-nia okazuje się nadzwyczaj wysoka. Niestety, niewielu programistów i projektantów potrafi zdiagnozować i rozwiązać te problemy na po-ziomie systemu.

Programiści powinni umiejętnie manipulo-wać priorytetami zadań z możliwą zmianą za-chowania się wątków w systemie, a następnie dokonywać powtórnego testowania i uściśle-nia własnych modyfikacji. Proces ten może za-jąć kilka roboczych tygodni, co doprowadzi do zwiększenia nakładów i opóźnienia we wpro-wadzeniu gotowego produktu do sprzedaży.

Problem komplikuje się w związku z tym, że wiele wbudowanych systemów tworzą dy-

Inteligentne partycjonowanie zasobów

„Złożoność chipów podwaja się co 18 miesięcy, natomiast stopień złożoności oprogramowania podwaja się co 10 miesięcy…”Prof. dr Franz Raming

Dowiesz się:• Czym jest inteligentne partycjonowanie zaso-

bów;

• Jakie daje korzyści.

Powinieneś wiedzieć:• Co to jest system wbudowany;

• Co to jest zarządzanie wątkami;

• Czym są priorytety zadań.

Poziom trudności

Systemy czasu rzeczywistego

Rysunek 1. Priorytetowe planowanie gwarantuje, że najbardziej krytyczne zadania otrzymują dostęp do zasobów procesora, lecz także może być przyczyną problemów w przypadku, kiedy zadanie o wysokim priorytecie niezamierzenie lub zamierzenie korzysta ze wszystkich mocy procesora. Przykładowo, zadanie A przeszkadza wszystkim innym zadaniom w uzyskaniu dostępu do procesora po czasie swojego uruchomienia (czwarta jednostka czasu)

��������

����

���

����������������������������������������������������������������������������������������������������������������������������������������������

����

�������

�����

�������

�������������������

Page 55: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200854

Testowanie oprogramowaniaInteligentne partycjonowanie zasobów

www.sdjournal.org 55

namiczne, pracujące w sieci urządzenia, któ-re mogą (lub powinny) oferować wsparcie no-wych możliwości funkcjonalnych oprogra-mowania podczas całego okresu korzystania z nich. Taka możliwość modernizacji ma wiele zalet, lecz także pociąga za sobą mnóstwo pro-blemów w trakcie projektowania. Na przykład, w jaki sposób urządzenie może ładować i uru-chamiać nowe komponenty programowe, po-mijając tryb pracy i realizację w czasie rzeczy-

wistych aktualnie realizowanych komponen-tów? I jak urządzenie może bezpiecznie doko-nać takiej aktualizacji podczas partycjonowania w systemie operacyjnym, zapewniając stały do-stęp i wysoki poziom niezawodności? W takich przypadkach rzadko udaje się dokonać urucho-mienia nowych komponentów lub mocy obli-czeniowych w celu zapewnienia pewnej pracy nowych komponentów. Tym samym programi-ści powinni posługiwać się najnowszymi tech-

nologiami, aby zagwarantować, że każdy kom-ponent (starszy i nowszy) zawsze będzie miał dostęp do wymaganych mocy obliczeniowych, włączając w to czas procesora.

Dotychczas systemy operacyjne korzystały z planowania wielowątkowego i priorytetowego w celu realizacji kontroli zadań cykli procesora. Programiści mogą dla każdego wątku określić je-go priorytet, a następnie planować ich realizację, korzystając z określonej strategii projektowania, na przykład cyklicznego algorytmu (Round-ro-bin) lub zasady FIFO. Priorytety określają kolej-kę gotowych wątków do realizacji w pierwszej kolejności, a strategia projektowania zaleca, jakie wątki o takich samych priorytetach będą wspól-nie wykorzystywać moc procesora.

Planowanie priorytetowe jest wygodną meto-dą określania priorytetów dla każdego zadania. Powoduje to jednak powstawanie problemów: jeżeli priorytet danego zadania jest o chociaż-by jeden poziom wyższy niż innego, to zada-nie o wyższym priorytecie ma możliwość cał-kowitego zablokowania zasobów procesora za-daniu o niższym priorytecie. Za przykład mo-gą posłużyć dwa procesy – proces A i proces B, gdzie A ma niedużo większy priorytet niż B. Jeżeli w procesie A zawartych jest nadmier-na ilość zadań lub dochodzi do odmowy wyko-nania, to zablokuje on dostęp do procesu B (jak również do każdego innego procesu o niższym priorytecie).

Podobne problemy powstają we wszystkich obszarach, w których korzysta się z oprogramo-wania wbudowanego. W samochodzie proces A może odpowiadać za wyświetlacz systemu nawigacji, a proces B za odtwarzacz mp3; jeże-li system nawigacji używa zbyt wiele cykli pod-czas określania trasy, może on odebrać zasoby, z których powinien korzystać odtwarzacz mp3 i doprowadzi do jego nieprawidłowej pracy. Pod-czas pracy w sieci, proces A może być protoko-łem TCP/IP i przekierowania, a proces B agen-tem protokółu SNMP. W układzie sterowania produkcją, proces A może być obwodem stero-wania manipulatora robota, a proces B interfej-sem HMI (ang. human-machine interface).

Usługi, sterowane wątkami o niższym priory-tecie, łącznie z usługami diagnostycznymi, któ-re bronią systemu przed błędami programistycz-nymi lub awariami, mogą być pozbawione mocy

Rysunek 2 . Podczas gdy planowanie stałych partycji przeszkadza w wykorzystaniu wszystkich cykli procesora przez zadanie o wysokim priorytecie (np. przez zadanie A), może ono także doprowadzić do obniżenia wydajności, marnując nieużywane cykle procesora w danej grupie (np. w grupie 3)

��������

����

���

����������������������������������������������������������������������������������������������������������������������������������������������

����

�������

�����

�������

������������������

����������������������������������������������������������������������������������������������

������

������

Rysunek 3. Inteligentne partycjonowanie przeszkadza w użyciu przez zadania o wysokim priorytecie większej ilości zasobów procesora, niż procentowo dla nich określone, oprócz przypadków, gdy wykorzystywane cykle procesora staną się dostępne w systemie. Na przykład, zadania A i D mogą być realizowane w czasie przydzielonym grupie 3, ponieważ zadania E i F nie wymagają dostępu do przypisanych im cykli procesora. W przypadku planowania stałych partycji ten wolny czas byłby utracony

��������

����

���

����������������������������������������������������������������������������������������������������������������������������������������������

����

�������

�����

�������

���������������������

����������������������������������������������������������������������������������������������

����

������

� �

��������������������

��������������������������

�����������������������

Rysunek 4. Krytyczna aplikacja zajmuje 100% zasobów, pracując jako jedyna

Page 56: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200856

Testowanie oprogramowaniaInteligentne partycjonowanie zasobów

www.sdjournal.org 57

procesora na nieokreślony czas, tym samym po-wodując ryzyko zaistnienia przerw w pracy sys-temu. Niezależnie od tego, dla jakiego rynku przeznaczony jest system, brak zasobów dla za-dań lub procesów jest poważnym problemem.

Aby rozwiązać ten problem, niektóre syste-my operacyjne czasu rzeczywistego, na przy-kład LynxOS, korzystają z mechanizmu stałego przydzielania zasobów procesora grupom wąt-ków, zgodnie ze standardem AIRINC-653. Pro-gramista systemu może dzielić zadania (wąt-ki) na grupy (partycje), i określać procent cza-su procesora dla każdej z grup. Korzystając z te-

go podejścia, żadne z zadań w dowolnej grupie nie będzie mogło użytkować więcej niż na stałe przydzielony tej grupie procent czasu proceso-ra. Na przykład, jeśli grupie przydzielono 30% zasobów procesora, a proces w tej grupie zosta-nie błędnie ukończony, to będzie on mógł wy-korzystać nie więcej niż 30% czasu procesora.

Ponieważ algorytm planowania jest stały, grupa w żadnym przypadku nie będzie mogła wykorzystać cykli procesora przydzielonych in-nym grupom, nawet jeżeli nie wykorzystają one przydzielonych im zasobów. W rezultacie obni-ża się ogólna wydajność systemu.

Inteligentne partycjonowanie zasobówInne podejście, zwane partycjonowaniem inte-ligentnym, usuwa te mankamenty, zapewnia-jąc bardziej dynamiczny algorytm planowania. Podobnie jak w przypadku statycznego podej-ścia do partycjonowania, partycjonowanie in-teligentne daje programiście systemów możli-wość zarezerwowania cykli procesora dla pro-cesu lub grupy procesów. Daje to pewność, że obciążenie jednego z podsystemów lub grupy nie będzie wpływać na dostępność innych pod-systemów.

W odróżnieniu jednak od statycznych me-tod, przy niepełnym obciążeniu procesora pla-nowanie wykonania wątków w procesorze nie różni się od zwykłego planowania wykonania wątków w systemie operacyjnym QNX Neu-trino, tzn. w procesorze umieszcza się gotowy do wykonania wątek o maksymalnie wysokim priorytecie. W rezultacie wątki w jednej grupie mogą mieć dostęp do każdego z cykli procesora, które nie są wykorzystywane przez wątki w do-wolnej innej grupie.

Przy pełnym obciążeniu procesora system inteligentnego partycjonowania ściśle ograni-cza przydzielanie czasu procesora grupom wąt-ków na podstawie ustalonych dla każdej gru-py wartości. Grupie wątków wydziela się gwa-rantowany czas procesora w ramach wartości, które mogą być wykorzystane. Wewnątrz każ-dej grupy wątki konkurują o czas procesora na podstawie ustalonych dla każdego wątku prio-rytetów. Pozwala to programistom na optyma-lizację przydzielania wątkom priorytetów, jed-nak nie w ramach całego systemu, a jedynie we-wnątrz grupy. Zastosowanie technologii inteli-gentnego partycjonowania nie wymaga zmia-ny kodu aplikacji czasu rzeczywistego, nie jest konieczna także zmiana modelu programowa-nia lub metod debugowania, już znanych pro-gramistom.

Podejście to, po raz pierwszy zastosowane przez firmę QNX Software Systems, łączy za-lety wskazanych wcześniej metod i daje progra-mistom systemów następujące możliwości:

• zapewnienie gwarantowanego przydzia-łu czasu procesora, kiedy system jest moc-niej obciążony – gwarantuje to, że wszyst-kie grupy otrzymają przydzielone im zaso-by procesora;

• wykorzystanie planowania priorytetowe-go czasu rzeczywistego, kiedy system nie jest obciążony, co pozwala systemowi na wykorzystanie tego samego trybu plano-wania, z którego korzystają obecnie;

• wykorzystanie wolnych zasobów proceso-ra, zarezerwowanych dla grup, które nie do końca zostały załadowane, co daje moż-liwość przydzielenia ich innym grupom, potrzebującym ich do pracy przy maksy-malnym obciążeniu, i pozwala wykorzy-stać 100% mocy procesora;

Rysunek 5. Aplikacja niekrytyczna Go-Slow odebrała aplikacji krytycznej wymagane zasoby

Rysunek 6. Aplikacja niekrytyczna Go-Slow nie wykorzystuje zasobów procesora, które dzielone są między dwie pozostałe grupy

Page 57: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200856

Testowanie oprogramowaniaInteligentne partycjonowanie zasobów

www.sdjournal.org 57

• łączenie możliwości planowania inteli-gentnego partycjonowania z istniejącymi systemami bez zmian kodu, w rezultacie czego aplikacje i usługi systemowe moż-na po prostu uruchomić w grupie, a pro-gram planujący zagwarantuje, że grupy bę-dą miały dostęp do przydzielonych im za-sobów;

• dynamiczne dodawanie i konfiguracja gru-py w procesie wykonania, pozwalające sys-temowi na regulację zużycia zasobów pro-cesora w odpowiedzi na awarię lub inne sytuacje;

• zagwarantowanie, że operacje przywraca-nia będą mieć do dyspozycji cykle proce-sora, potrzebne im do naprawienia błędów systemowych, poprawiając tym samym średni czas naprawy systemów o wysokim stopniu dostępności;

• wstrzymywanie wykonania kodu mają-cego na celu przechwycenie całego czasu procesora, poprzez odmowę wykonania.

Inteligentne partycjonowanie zasobów po-zwala na tworzenie bezpiecznych grup z kilku aplikacji i wątków. Co to są bezpieczne grupy?

Bez stworzenia grup składających się z kilku aplikacji i wątków, awaryjne aplikacje mogą po-zbawić kluczowe aplikacje niezbędnych zaso-bów procesora. Na przykład, błędy kodu apli-kacji mogą przypadkowo stać się przyczyną po-wstawania takich warunków, które doprowa-dzą do zatrzymania pracy całego systemu. Po-dobnie ataki DoS (Odmowa usługi/Denial of Se-rvice) mogą obciążyć system zadaniami siecio-wymi i tym samym pozbawić kluczowe aplika-cje dostępu do zasobów procesora. Inteligent-ne partycjonowanie zasobów pozwala na ogra-niczenie tych zagrożeń i ochronę kluczowych

aplikacji i usług. Awaryjne komponenty syste-mu są izolowane, tzn. nie będą one mogły wy-korzystać więcej czasu procesora, niż im przy-pisano. W ten sposób system zachowuje goto-wość do pracy w każdej sytuacji.

Wykorzystanie mechanizmu inteligentnego partycjonowania jest bardzo proste. Przy star-cie systemu wspierającego inteligentne party-cjonowanie zasobów automatycznie tworzo-na jest jedna grupa z przydzielonymi 100% za-sobów procesora, która nosi nazwę System. W grupie tej uruchamiane są wszystkie procesy. W każdej chwili można tworzyć inne grupy i przydzielać im zasoby, korzystając z następu-jącego polecenia:

aps create –b40 Critical

aps create –b40 Untrusted

Te polecenia utworzą dwie grupy (Critical, Untrusted) z dostępem do 40 % czasu proce-sora dla każdej.

Aby uruchomić aplikację w konkretnej gru-pie, wystarczy skorzystać z dobrze znanego użytkownikom QNX polecenia on.

on -Xaps=Critical Car

on -Xaps=Untrusted Go_slow

Poniższy przykład ilustruje, w jaki sposób działa inteligentne partycjonowanie zasobów.

Uruchomimy w systemie trzy aplikacje bez inteligentnego partycjonowania zasobów. Pierw-sza aplikacja to monitor zasobów systemowych (APSMonitor), druga aplikacja (Car) to proces krytyczny, (brak przecinka) który prezentuje ruch samochodu, trzeci proces – niekrytyczny, lecz wymagający znacznych zasobów systemo-wych, wykorzystywany do obciążenia systemu

(Go-Slow). Jak widać na ilustracji (Rysunek 4), podczas pracy naszej aplikacji krytycznej zajęte są wszystkie zasoby procesora.

Samochód porusza się z prędkością 83 km/h. Zwiększmy teraz obciążenie systemu, wykorzy-stując aplikację niekrytyczną (Go-Slow). Jak wi-dać na Rysunku 5, wszystkie zasoby procesora są zajęte i aplikacji krytycznej brak zasobów proceso-ra. Samochód porusza się z prędkością 19 km/h.

Uruchamiamy teraz trzy aplikacje z zasto-sowaniem inteligentnego partycjonowania za-sobów. W systemie, jak opisano wyżej, tworzy-my trzy grupy procesów: System o wartości 20 % czasu procesora, Critical i Untrusted z warto-ściami 40% czasu procesora dla każdego z pro-cesów. Aplikację Go-Slow uruchamiamy w gru-pie Untrusted, aplikację krytyczną Car urucha-miamy w grupie Critical, a wszystkie pozostałe procesy i wątki będą pracować w grupie System. Jak widać na Rysunku 6, aplikacja Go-Slow nie wykorzystuje zasobów procesora i wolne zasoby dzielone są między pozostałe dwie grupy proce-sów. Procesor jest wówczas obciążony w 100%.

Zwiększmy obciążenie systemu za pomocą aplikacji Go-Slow. W związku z tym, że inte-ligentne partycjonowanie zapewnia przydziele-nie zasobów procesora grupie aplikacji, aplika-cji Go-Slow będą przydzielone zasoby proceso-ra zgodnie z ustalonymi wartościami. W związ-ku ze zwiększonym obciążeniem systemu i brakiem wolnych zasobów procesora, wszyst-kie grupy aplikacji otrzymują zasoby zgodnie z ustalonymi wartościami (Rysunek 7). Apli-kacja krytyczna Car zaczęła działać wolniej, co możemy zaobserwować po prędkości ruchu sa-mochodu, jednak nasza aplikacja krytyczna działa i nadal ma dostęp do zasobów, które zo-stały jej przydzielone.

Na podstawie zaprezentowanego przykła-du można wywnioskować, że inteligentne partycjonowanie pozwala programistom sys-temów wbudowanych na tworzenie bezpiecz-nych grup z kilku aplikacji lub wątków i gwa-rantuje efektywne przydzielenie czasu proceso-ra tym grupom, którym są one potrzebne. Jeże-li na etapie projektowania przy określaniu prio-rytetów wątków wystąpiły błędy, to przy zasto-sowaniu technologii inteligentnego partycjono-wania można je poprawić na etapie konfigu-rowania systemu, bez konieczności ponownej kompilacji komponentów programowych.

Podsumowując należy powiedzieć, że inteli-gentne partycjonowanie to pierwszy przykład podejścia do partycjonowania zasobów zgodne-go z modelem planowania standardu POSIX. Dzięki temu istniejące systemy na bazie POSIX i QNX Neutrino będą mogły skorzystać z zalet nowatorskiego rozwiązania bez wprowadzania zmian do kodu i architektury aplikacji.

ROMAN KOŃSZYNAutor jest wykładowcą w Centrum Szkoleniowym

firmy SWD Software.

Kontak z autorem: [email protected] 7. Podczas pracy procesowi Go-Slow przydzielona jest ustalona ilość zasobów

Page 58: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200858

UMLJzyk UML 2.x w dydaktyce akademickiej

www.sdjournal.org 59

Język UML (Unified Modeling Language), zaproponowany przez Boocha, Jacobso-na i Rumbaugh, przyciągnął uwagę za-

równo środowisk akademickich, jak również praktyków w środowisku analityków i projek-tantów systemów informatycznych. Specyfi-kacje języka UML pozwalają na dokumen-towanie systemu informatycznego w kate-goriach przypadków użycia, ich scenariuszy, klas, interakcji oraz innych diagramowych kategorii notacyjnych, wybranych do tego ce-lu spośród aktualnego zbioru 13 typów dia-gramów języka UML w wersji 2.1. Narzędzie to sprawdza się w modelowaniu znacznego zakresu rozwiązań z zakresu tworzenia syste-mów informatycznych, odpowiadających po-trzebom gospodarki opartej na wiedzy. Stan-dard jest nieustannie monitorowany, rozwi-jany, modyfikowany i ulepszany przez orga-nizację OMG (Object Management Group). UML jest nie tylko ugruntowanym standar-dem w dziedzinie oprogramowania, lecz rów-nież najpopularniejszym językiem nauczania inżynierii oprogramowania, a w szczególno-ści analizy i projektowania systemów infor-matycznych na różnych poziomach studiów akademickich.

UML 2.x jako całość jest złożonym skła-dniowo i semantycznie językiem graficz-nym, a – co za tym idzie – poważnym wy-

zwaniem w nauczaniu analizy i projektowa-nia systemów informatycznych. Z drugiej strony, ani zastosowania biznesowe ani prak-tyczne studia przypadków nie wykorzystu-ją całego, zróżnicowanego instrumentarium języka UML 2.x. Wprost przeciwnie – wy-daje się, że także w tym przypadku znajduje zastosowanie reguła metodologiczna 20 – 80, stanowiąca, że 20% kategorii UML wystarcza w 80% zastosowań. Pozostałe 80% kategorii modelowania UML wykorzystuje się z silnie zróżnicowaną częstotliwością. Obie te prze-słanki skłoniły badaczy do zaproponowania zwięzłych wersji UML. Wersje uproszczone zwykle poleca się jako podstawowy element kursów wprowadzających w tematykę two-rzenia systemów informatycznych, podczas gdy wersję kompletną – uczestnikom stu-diów na poziomie magisterskim.

Na podstawie rzeczywistych projektów oraz doświadczenia dydaktycznego moż-na stwierdzić, iż jedynie wybrane elementy kompletnego potencjału języka UML znajdu-ją zastosowanie w cyklu życia systemu. Auto-rzy notacji uproszczonych zazwyczaj propo-nują ograniczony zestaw diagramów UML wraz ze zbiorem odpowiednich kategorii po-jęciowych, przypisywanych do tych diagra-mów – zazwyczaj pojęć, które zdaniem au-torów są najbardziej istotne w procesie na-uczania i osiąganiu celów w praktycznych projektach.

Jak zaznaczono wcześniej, nie występu-je wspólne stanowisko autorów w zakresie zawartości uproszczonej wersji UML, a wy-mienione propozycje są niezależne od sie-

bie i stronnicze. Ich mnogość potwierdza te-zę, iż tempo uaktualniania i modyfikowania UML – jak również złożoność tego języka i potencjalne trudności początkujących użyt-kowników, wynikające z tego – zostały nie-doszacowane.

Proces dydaktyczny – założenia metodologiczneIstota nauczania języka UML 2.x na Uniwer-sytecie Gdańskim wynika z doświadczenia i dostępnej wiedzy w zakresie dydaktyki ana-lizy i projektowania systemów informatycz-nych. Podstawowe założenia tego podejścia obejmują:

• zrozumienie istoty procesów biznesowych i systemowych;

• rozwiązywanie postawionych praktycz-nych problemów biznesowych;

• nieustanną aktualizację posiadanych zaso-bów;

• pracę w grupach, zorientowaną na współ-pracę interpersonalną w zakresie specy-fikowania i rozwiązywania problemów (symulacja funkcjonowania rzeczywi-stych zespołów projektowych);

• silne wsparcie profesjonalnego oprogra-mowania typu CASE (Computer-Aided Software Engineering);

• zaangażowanie zasobów e-learningingo-wych w proces dydaktyczny.

Zakres kursu był nieustannie rozwijany, m. in. poprzez włączenie technik i metodologii pokrewnych UML, takich jak:

• modelowanie procesów biznesowych (BPM);

• modelowanie analityczne;• Rational Unified Process (RUP).

Wymienione powyżej założenia procesu dy-daktycznego oraz zasoby zostały wkompo-

Język UML 2.x w dydaktyce akademickiejJęzyk UML to chleb codzienny analityka i projektanta systemów informatycznych. Jak jednak sprawić, by początkujący adepci zawodu nie mieli problemów z jego opanowaniem?

Dowiesz się:• Na jakie elementy języka UML kłaść nacisk

podczas nauki;

• Czym jest wersja Light języka UML;

• Jak zorganizować szkolenie z zakresu UML.

Powinieneś wiedzieć:• Czym jest język UML;

• Z jakich diagramów składa się język UML i jak

się te diagramy stosuje.

Poziom trudności

Page 59: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200858

UMLJzyk UML 2.x w dydaktyce akademickiej

www.sdjournal.org 59

nowane w podejście dydaktyczne, zorien-towane na rozwiązywanie problemów, jak wskazano na Rysunku 1.

Kluczowym elementem omawianego po-dejścia jest naturalnie obszerna wiedza w za-kresie języka UML. Rolę stymulującą pełniły ponadto liczne podręczniki dotyczące UML 2. Tematyka, oparta na języku UML, zosta-

ła uzupełniona o pokrewne metody, techniki i metodologie obiektowe, takie jak BPM, mo-dele analityczne oraz RUP. Materiały źródło-we służyły jako podstawa do autonomicznej działalności dydaktycznej, takiej jak wykła-dy, autorski podręcznik kursowy, zestaw stu-diów przypadku i ćwiczeń oraz content e-le-arningowy. Dzięki niniejszym zasobom dy-

daktycznym, można było zainicjować proces dydaktyczny, realizowany w laboratoriach komputerowych. Wszystkie laboratoria wy-posażono w narzędzie CASE – Enterprise Architect, wspomagające proces nauczania.

Diagramowa dokumentacja UML 2.0 roz-wiązywanych studiów przypadków jest or-ganizowana w oparciu o model architektu-ry 4+1 Kruchtena, jak przedstawiono na Ry-sunku 2.

Tym samym, proces tworzenia systemu ini-cjowany jest w ramach perspektywy przypad-ków użycia, która to perspektywa jest usytu-owana centralnie wobec innych perspektyw. Istotną rolę w specyfikowaniu wymagań peł-nią diagramy przypadków użycia, dokumen-tacja scenariuszy przypadków użycia – a także modele procesów biznesowych i analityczne.

Wychodząc od wyszczególnionych i szcze-gółowo udokumentowanych przypadków uży-cia, można przygotować wybrane diagramy spośród 12 pozostałych ich rodzajów, organi-zując te diagramy w odpowiednie perspekty-wy. Perspektywy obejmują zarówno statykę, jak i dynamikę systemu. Szczegółowe diagra-my dalszych perspektyw są naturalnie wspie-rane przez zastosowane narzędzie CASE.

W rezultacie procesu, przedstawionego na Rysunku 1, generowana jest dokumentacja konkretnego studium przypadku. Dokumen-tacja ta jest następnie iteracyjnie dopracowy-wana, prezentowana przez grupę oraz oce-niana. Należy poruszyć najistotniejsze aspek-ty systemu, podczas gdy liczba godzin, prze-znaczona na przygotowywanie różnych ele-mentów poszczególnych dokumentacji, jest elastyczna i dostosowywana do charaktery-styki danego projektu.

Wybrane rozwiązania studiów przypadku, zaprezentowane przez studentów, włączane są do puli projektów z zakresu UML 2, prze-chowywanej na platformie e-learningowej.

Zasadnicze zalety zastosowanej metody (Rysunek 1) są następujące:

• metoda stymuluje studentów do aktyw-nej i kreatywnej pracy grupowej, jak również zasadniczo zwiększa wiedzę i umiejętności w zakresie UML;

• praca oparta na studiach przypadku daje szansę na symulowanie warunków prak-tycznej pracy projektowej i realizowania zadań, na które studenci mogą natrafić w przyszłej pracy zawodowej;

• ogólna wydajność grupy rośnie, gdyż każ-dy jej członek jest dopingowany i kontrolo-wany przez pozostałych członków grupy.

Wybrane wyniki badaniaKursy z zakresu języka UML (wersja 2.1, 2.0 i wcześniejsze) są realizowane na Uniwersy-tecie Gdańskim od 2001 roku. Wypracowa-ne podejście dydaktyczne było aktualizowa-ne i udoskonalane wraz z każdą kolejną wer-

Rysunek 1. Założenia i rezultaty akademickiego kursu języka UML 2.x

������������

���������

������������

�������

���������

����

����������������������

�����������

��������������������������

��������������������

���������������� ������� ����������

������������������

�������������������

��������������������

����������

�����������

����������������

�����������

����������

��������������������������

������������������

������������������

������������

��������

�������

���������

�������

Rysunek 2. Perspektywy architektury systemu wraz z zalecanymi diagramami Źródło: (Wrycza i in., 2005)

�������������������

����������������

��������������������

�����������������������������������������������������������������

��������������������������������������������������

���������������������������������������

�����������������������������������������

����������������������������������������������

���������������������������

��������������������

����������������

������������

����������������

����������������������������

����������������

�������������������

�����������������

������������������������

����������������������������

����������������

Page 60: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200860

UMLJzyk UML 2.x w dydaktyce akademickiej

www.sdjournal.org 61

sją UML. Autorzy niniejszego artykułu zi-dentyfikowali i przeanalizowali szereg pro-blemów dydaktycznych, wynikających z przeprowadzonego badania. Jednym z pod-stawowych wniosków jest fakt niemożno-ści przyswojenia przez studentów zasad sto-sowania pełnego zestawu diagramów UML. Dodatkowo każdy z rodzajów diagramów UML wyposażono w rozbudowany zestaw kategorii modelowania UML, spośród któ-rych uczestnicy szkoleń wybierają zawężo-ny podzbiór kategorii i stosują je w praktyce, podczas gdy inne są ignorowane. W ramach definiowania założeń przyszłej wersji Light autorzy przyjęli następujące trzy podstawo-we ograniczenia:

• wersja Light powinna składać się wyłącz-nie z najpowszechniej stosowanych w praktyce diagramów, natomiast składnia poszczególnych diagramów powinna być maksymalnie zawężona;

• UML 2.x Light powinna w szerokim za-kresie wspomagać główne dyscypliny metodyki RUP, tj. specyfikację wyma-gań oraz analizę i projektowanie;

• wersja taka powinna być w pełni kompa-tybilna z pełną specyfikacją języka UML 2.x.

Dla określenia zakresu wersji UML 2.x Light autorzy przeprowadzili badanie o charakte-

rze ankietowym wśród studentów specjalno-ści Informatyka Ekonomiczna. Jego rezultaty pozwoliły nie tylko na dogłębną ocenę kursu UML przez jego uczestników, lecz także sta-nowiło podstawę do dokonania rewizji aktual-nie stosowanego podejścia.

Grupa docelowa obejmowała 180 studen-tów, zarówno z uczelni prywatnych, jak i pu-blicznych, posiadających wiedzę i kompe-tencje w zakresie zarówno obiektowego, jak i strukturalnego podejścia do tworzenia sys-temów informatycznych. Kwestionariusz an-kietowy składał się z 17 podstawowych pytań. Pytania dotyczyły głównie pojęć związanych z wersją Light języka UML, wzajemnych zależ-ności pomiędzy podejściem strukturalnym a obiektowym, jak również potencjalnych roz-szerzeń i technik pochodnych w stosunku do UML. W celu dokonania precyzyjnej oceny zakresu proponowanej wersji Light dokonano analizy następujących kwestii:

• oceny poziomu złożoności języka UML;• adekwatności liczby rodzajów diagra-

mów języka UML 2.x;• oceny użyteczności poszczególnych ro-

dzajów diagramów;• identyfikacji diagramów przeciążonych

zaawansowanymi kategoriami pojęcio-wymi;

• wytypowania diagramów przyjaznych użytkownikowi;

• wskazania diagramów stanowiących naj-lepszą podstawę do generowania kodu źródłowego.

Obszerna graficzna analiza statystyczna wraz z komentarzami została zaprezentowana w innych opracowaniach autorów. Poniżej ko-mentowane są jedynie wybrane wyniki.

Kwestionariusz zainicjowano pytaniem o złożoność języka UML (Rysunek 3). Uznanie języka UML za nadmiernie złożony ma funda-mentalne znaczenie z punktu widzenia wpro-wadzania wersji Light języka UML. Odpowie-dzi respondentów potwierdziły hipotezę auto-rów – 51% ankietowanych uważało UML za średnio trudny, 33% za trudny, podczas gdy 7% za bardzo trudny. A zatem dla ponad 90% studentów zawężona wersja języka UML, tj. UML Light, stanowiłaby cenną asystę w przy-swajaniu języka.

Ankietowani studenci mieli możliwość przyswojenia na zajęciach i/lub w praktyce wszystkich 13 rodzajów diagramów języka UML. Liczba diagramów jest w sposób natu-ralny powiązana ze złożonością języka. Więk-szość z badanych (ponad 57%) uznała, iż UML składa się ze zbyt wielu rodzajów diagramów. Pozostali respondenci akceptowali pełny ze-staw diagramów UML, nie odnosząc się jed-nakże do wpływu i znaczenia liczności za-awansowanych kategorii modelowania składa-jących się na poszczególne diagramy.

Skoro poszczególne rodzaje diagramów użytkowane są ze zróżnicowaną intensywno-ścią – niektóre mają charakter uniwersalny, inne stosowane są w specyficznych sytuacjach – postawiono pytanie o użyteczność poszcze-gólnych rodzajów diagramów. Badanie wyka-zało, iż w opinii respondentów najbardziej użyteczne są następujące diagramy:

• diagramy klas (62% pozytywnych wska-zań respondentów);

• diagramy przypadków użycia (56%);• diagramy czynności (26%);• diagramy sekwencji (21%);

Studium potwierdziło powszechnie uznawa-ną rolę przewodnią pełnioną przez dwa rodza-je diagramów – diagramy klas oraz diagramy przypadków użycia. W istocie stanowią one dwa podstawowe graficzne formalizmy mode-lowania odpowiednio struktury oraz dynami-ki systemu informatycznego. Dodatkowo dia-gramy przypadków użycia inicjują iteracyjno-przyrostowy cykl życia metodyki RUP (Ratio-nal Unified Process), pełniąc tym samym spe-cyficzną rolę w każdym projekcie. Z kolei jako najmniej użyteczne postrzegane są:

• diagramy maszyny stanowej (28%);• diagramy harmonogramowania (19%);• diagramy rozlokowania (13%);• diagramy struktur połączonych (12%).Rysunek 4. Ocena stopnia nadmiarowości kategorii modelowania w diagramach języka UML

Rysunek 3. Oszacowanie stopnia trudności UML

Page 61: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200860

UMLJzyk UML 2.x w dydaktyce akademickiej

www.sdjournal.org 61

Niewątpliwie wciąż niedoceniana jest ro-la diagramów maszyn stanowych oraz dia-gramów rozlokowania, choć i tak nie pre-tendują one do roli najbardziej uniwersal-nych. Podczas gdy diagramy maszyny sta-nowej są bogate semantycznie, lecz niechęt-nie stosowane przez początkujących anali-tyków i projektantów, diagramy rozlokowa-nia są bliższe fizycznemu wdrożeniu syste-mu w zgodzie z metodyką RUP. Stąd dwa powyższe rodzaje diagramów należy szcze-gólnie polecić realizującym kursy z zakresu programowania.

W związku z czwartym kryterium, stu-dentów poproszono o wskazanie diagramów przeciążonych zaawansowanymi kategoria-mi modelowania (Rysunek 4). W ocenie stu-dentów cecha ta dotyczy przede wszystkim poszczególnych rodzajów diagramów inte-rakcji. I tak, 32% respondentów uważało, że nadmierność pojęciowa towarzyszy przede wszystkim diagramom sekwencji (32% od-powiedzi), podczas gdy odpowiednio 28% i 27% respondentów oceniło w ten sposób diagramy sterowania interakcją oraz diagra-my komunikacji. Spośród diagramów inte-rakcji wyłącznie diagram harmonogramowa-nia został uznany za stosunkowo nieskompli-kowany. Problem nadmiarowości nie doty-czył również semantycznie bogatych diagra-mów obiektów, diagramów przypadków uży-cia oraz diagramów klas. Tylko odpowiednio 14%, 18% oraz 20% respondentów zakwali-fikowało te diagramy jako nadmiarowe. Ak-ceptacja dla znacznej złożoności diagramów klas wiąże się z doświadczeniem studentów w dziedzinie programowania w języku obiek-towym Java. Kategorie modelowania diagra-

mów klas są tam w szerokim zakresie imple-mentowane praktycznie.

Przyjazność dla użytkownika jest jednym ze słów kluczowych a zarazem wyzwaniem

współczesnej informatyki. Ocena diagramów UML z tego punktu widzenia powinna uła-twić wytypowanie zakresu wersji UML Light. Opierając się na wynikach badania należy

Rysunek 5. Diagramy UML 2.x zakwalifikowane do wersji Light

�������������

����������������

�����������

����������������

�����������

�������

����������

�������

�������

������������������

�������

�������

���������

�������

�������

���������

��������

������������

�������

������������������

�����������������

��������

�����������

�������

�����������������

�����������������

��������������

����������������

�������������������

���������������� ����������������

�������

�����������

Tabela 1. Podstawowe i zaawansowane kategorie modelowania w kontekście wersji Light języka UML 2.x

Diagram klas Diagram przypadków użycia

Diagram czynności Diagram sekwencji

Podstawowe kategorie modelowania

KlasaAtrybutOperacjaAsocjacja binarnaNazwa asocjacjiRoleNawigacjaLiczebnośćAgregacjaKompozycja

Przypadek użyciaAktorAsocjacja binarna

CzynnośćPodczynnośćPoczątekKoniecPrzepływ sterowania

AktorKlasaKlasa granicznaKlasa sterującaKlasa przechowującaLinia życiaOśrodek sterowaniaKomunikat synchroniczny

Zaawansowane kategorie modelowania

ZobowiązanieWidocznośćAtrybut/operacja statycznaAsocjacja n-arnaKlasa asocjacyjnaAsocjacja zwrotnaAsocjacja wielokrotnaKwalifikacjaUogólnienieZależnośćRealizacja

Zależność zawieraniaZależność rozszerzaniaUogólnienieRodzaje aktorówLiczebnośćNawigacjaRealizacja

DecyzjaŁącznikZłączenieAkcjaPrzekaźnik danychParametr czynnościWagaSygnałBufor centralnySkładnica danychPartycjaObszar rozszerzeniaObszar przerwaniaManipulator wyjątków

Komunikat asynchronicznyKomunikat zwrotnyKomunikat utraconyKomunikat znalezionyKomunikat opcjonalnyKomunikat oczekującyWarunekSamowywołanieIteracjaRozgałęzienieFragment wyodrębnionyPrzywoływane wystąpienie interakcjiBrama

Page 62: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200862

UML

podkreślić, że diagramy przypadków użycia zostały uznane za najłatwiejsze do opanowa-nia i zarazem przyjazne użytkownikowi spo-śród 13 diagramów UML 2.x. Niemalże 3⁄4 re-spondentów doceniło tą cechę, tak niezbęd-ną szczególnie w dziedzinach modelowania biznesowego oraz specyfikacji wymagań. W istocie, diagramy te stanowią wspólną plat-formę porozumienia poszczególnych udzia-łowców systemu – tj. właścicieli, menadże-rów, przyszłych użytkowników oraz infor-matyków. Współpraca tych grup udziałow-ców staje się dobrą podstawą dla osiągnięcia poprawności, precyzji, spójności oraz kom-pletności dokumentacji w konsekwencji za-stosowania merytorycznie powiązanych dia-gramów UML.

Wspomniany już wielokrotnie pragmatycz-ny wymiar diagramów klas i ich ścisły związek z programowaniem spowodował, że osiągnęły one również wysoką ocenę – 66% responden-tów zakwalifikowały je jako łatwe lub bardzo łatwe w użytkowaniu. Studenci docenili rów-nież (59%) znaczenie diagramów czynności ja-ko szkieletu dla algorytmów oraz specyfikacji programistycznych. Przyjazność dla użytkow-nika pewnych typów diagramów UML powin-na być ponownie rozważona. Uwaga ta doty-czy w szczególności diagramów sterowania interakcją (43%), diagramów rozlokowania (39%) oraz diagramów struktur połączonych (38%). Wspomniane rodzaje diagramów nale-ży traktować jako naturalnych kandydatów do wykluczenia z wersji Light języka UML 2.x.

Rozwój narzędzi CASE zainspirował bada-nia oraz prace nad generowaniem kodu źró-dłowego na podstawie dokumentacji syste-mowej, przygotowanej z wykorzystaniem ję-zyka UML. Diagramy tego języka dają solid-ną podstawę do generowania kodu źródłowe-go na bazie diagramowej specyfikacji syste-mu. Respondenci uznali następujące rodza-je diagramów za dobra podstawę do tworze-nia specyfikacji programistycznych:

• diagram klas (66% odpowiedzi pozy-tywnych);

• diagramy czynności (42%);• diagramy sekwencji (34%);• diagramy komunikacji (34%);• diagramy komponentów (23%).

PodsumowanieOstatecznie, w wyniku przeprowadzonych badań proponuje się umieszczenie w wer-sji Light języka UML czterech rodzajów dia-gramów:

• diagramów przypadków użycia;• diagramów klas;• diagramów czynności;• diagramów sekwencji.

Wspomniane cztery rodzaje diagramów (Ry-sunek 5) pozwalają na modelowanie wszyst-kich podstawowych aspektów systemu, tj. specyfikacji wymagań oraz analizy i projek-towania zarówno struktury, jak i dynamiki systemu. Dostarczają również odpowiedniej ilości danych pod kątem generowania kodu.

Nie występuje konieczność wprowadza-nia wyczerpującej listy dostępnych kategorii modelowania do specyfikacji systemowych, przygotowanych z wykorzystaniem wersji Li-ght języka UML 2.x. Podstawowe kategorie modelowania są niezbędne do tworzenia dia-gramów na poziomie konceptualnym, pod-czas gdy zaawansowane kategorie modelowa-nia – do tworzenia diagramów na poziomie wdrożeniowym. Propozycja podziału katego-rii modelowania pomiędzy podstawowe oraz zaawansowane może stanowić punkt wyj-ścia w określaniu zakresu pojęciowego po-szczególnych diagramów, jak przedstawiono w Tabeli 1.

Zgodnie z wynikami badania, na Rysunku 5 zaprezentowano wszystkie cztery rodzaje dia-gramów (diagramy klas, przypadków użycia, czynności i sekwencji) oraz towarzyszące im kategorie modelowania w ramach proponowa-nej wersji Light języka UML 2.x.

Bibliografia

• Alphonce C., Ventura P.: QuickUML: A Tool to Support Iterative Design and Code Development, Proceedings of OOPSLA, Anaheim 2003, s. 80-81;

• Ambler S. W.: The Elements of UML 2.0 Style, Cambridge University Press, Cambridge 2003;• Booch G., Rumbaugh J., Jacobson I.: The UML Reference Manual. 2nd edition, Addison-Wesley,

Boston 2004;• Brewer J., Lorenz L.: Using UML and Agile Development Methodologies to Teach Object-Orien-

ted Analysis & Design Tools and Techniques, Proceedings of CITC4, Lafayette 2004, s. 54-57;• Burton P. J., Bruhn R. E.: Using UML to Facilitate the Teaching of Object-Oriented Systems Analy-

sis & Design, Journal of Computing Sciences in Colleges, 2004, 19 (3), s. 278-290;• DeLooze L. L., Minimal UML Diagrams for a Data-Driven Web Site, SIGITE, 2005, s. 229-232;• Dennis A.: Systems Analysis and Design with UML Version 2.0, Wiley, Nowy Jork 2005;• Dobing B., Parsons J.: How UML is Used, Communications of ACM, 2006, 49 (5), s. 109-113.• Eriksson H., Penker M., Lyons B., Fado D.: UML 2 Toolkit, OMG Press, Indianapolis 2004;• Flint S., Gardner H., Boughton C.: Executable/Translatable UML in Computing Education, Confe-

rences in Research and Practice in Information Technology, 2004, s. 69-75; • Kontio M.: Architectural Manifesto: Designing Software Architectures. Part 5. Introducing the 4+1

View Model, http://www-128.ibm.com/developerworks/wireless/library/wi-arch11, 2005 (stan na sierpień 2007);

• Kruchten P.: Architectural Blueprints - the ‘4+1’ View Model of Software Architecture, IEEE So-ftware, 1995, 12 (6), s. 42-50;

• Kruchten P.: The Rational Unified Process, Addison-Wesley, Boston 2004;• LeBlanc C., Stiller E.: UML for Undergraduate Software Engineering, Proceedings of JCSC 15,

Consortium for Computing in Small Colleges, 2000, s. 8-18;• OMG, Object Management Group: The UML 2.1 Superstructure Convenience Document, http://

www.omg.org/cgi-bin/doc?ptc/2006-04-02, 2006 (stan na sierpień 2007);• Poyla G.: How to solve it, Princeton University Press, Nowy Jork 1957;• Sparx Systems Enterprise Architect 7.0, http://www.sparxsystems.com.au (stan na sierpień

2007);• Tabrizi M., Collins C., Ozan E., Li K.: Implementation of Object-Orientation Using UML in Entry

Level Software Development Courses, Proceedings of SIGITE, Salt Lake City 2004, s. 128-131;• Trujillo J.: A Report on the First International Workshop on Best Practices of UML, SIGMOD Re-

cord, 2006, 35 (3), s. 48-50;• Turner S. A., Perez-Quinones M., Edwards S. H.: minimUML: A Minimalist Approach to UML Dia-

gramming for Early Computer Science Education, ACM Journal of Educational Resources in Computing, 2005, s. 1-24;

• Wrycza S. (red.): UML 2.1. Ćwiczenia, Helion, Gliwice 2006;• Wrycza S., Marcinkowski B.: UML 2 Teaching at Postgraduate Studies – Prerequisites and Practi-

ce, Proceedings of ISECON 2005, 22, AITP Foundation for Information Technology Education, Columbus, rekord 5123, 2005, s. 1-7;

• Wrycza S., Marcinkowski B.: UML 2 Academic Course – Methodological Background and Survey Benchmarking, Proceedings of ISECON 2006, 23, AITP Foundation for Information Technolo-gy Education, Columbus, rekord 5125, 2006, s. 1-6;

• Wrycza S., Marcinkowski B.: Towards a Light Version of UML 2.x: Appraisal and Model, Pro-ceedings of the 2nd AIS SIGSAND European Symposium on Systems Analysis and Design, Gdańsk 2007, s. 46-53;

• Wrycza S., Marcinkowski B., Wyrzykowski K.: Język UML 2.0 w modelowaniu systemów informa-tycznych, Helion, Gliwice 2005;

• Wrycza S., Rybiński W.: Information Systems Development Education: Assumptions and Practice, (w) Stowell F. A., West D., Howell J. G. (red), Systems Science. Addressing Global Issues. Ple-num Press, Nowy Jork 1993, s. 475-481.

STANISŁAW WRYCZABARTOSZ [email protected]

[email protected]

Page 63: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

�����������������������������������������������������������������

�������������������������������������������������������������������������������������������������������������������������������������������������������������������������

�����������������������������

������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

����������

������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

���������������������������������������������������������������������������������

�������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

Page 64: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200864

WarsztatSłup ogłoszeniowy w Symfony

www.sdjournal.org 65

W poprzednim artykule utworzyli-śmy serwis ogłoszeniowy, który spełnia swoją podstawową funk-

cję – umożliwia przeglądanie oraz samodziel-ne dodawanie ogłoszeń. Jednak nie wróżyłbym mu dobrego działania bez:

• kont użytkowników, z możliwością doda-wania ogłoszeń tylko po zalogowaniu;

• zarządzania ogłoszeniami oraz użytkow-nikami przez administratora;

• przejrzystych adresów URL.

W tym artykule zajmiemy się wszystkimi ty-mi kwestiami, pozostawiając na sam koniec kwestie kończenia aplikacji oraz ostateczną publikację na serwerze.

Konta użytkowników – sfGuard-Plugin oraz system rejestracjaPo co nam konta użytkowników? Jeśli sporo wolnego czasu i lubimy poświęcać go na bez-produktywne rzeczy – to na nic. Użytkownicy niezalogowani mogą tworzyć ogłoszenia i wziąć na siebie usuwanie niechcianych ogłoszeń. Al-bo możemy prosić użytkowników o przesyłanie loginów i haseł na nasz adres e-mail i samodziel-nie im tworzyć konta. Jednak przy większej liczbie użytkowników staje się to bardzo kłopo-

tliwe lub wręcz niewykonalne. Ale nie musimy się martwić – autoryzacja w Symfony zajmie nam wyjątkowo mało czasu.

Przy mechanizmie autoryzacji oraz upraw-nień skorzystamy z pluginu sfGuardPlu-gin, który możemy znaleźć na stronie http://www.symfony-project.org/plugins/sfGuardPlugin oraz na płycie CD.

Instalacja dodatku sfGuardPluginAby go zainstalować, w katalogu naszego pro-jektu wystarczy podać dla symfony 1.0:

> symfony plugin-install http://

plugins.symfony-project.com/sfGuardPlugin

lub symfony 1.1 dla:

> symfony plugin:install sfGuardPlugin

Po zainstalowaniu pluginu możemy podej-rzeć jego zawartość w katalogu postup/plugins/

sfGuardPlugin. Jeżeli dokładniej przyjrzymy się jego budowie, dostrzeżemy podobieństwo ze strukturą aplikacji (szczegóły zawarliśmy w artykule dotyczącego Pluginów).

Plugin zawiera schemat bazy danych oraz da-ne testowe, dlatego podajemy w symfony 1.0:

> symfony propel-build-model

> symfony propel-build-sql

> symfony propel-insert-sql

> symfony cc

> symfony propel-load-data postup

Komendy te kolejno:

• aktualizują model danych w katalogu/postup/lib/model/;

• generują kod SQL;• wysyłają zapytania do bazy danych;• wprowadzają dane testowe (tworzą konto

administratora).

Następnym krokiem jest włączenie dostę-pu naszej aplikacji dla modułu sfGuardAuth w pliku /postup/apps/postup/config/settings.yml (Listing 1). W pliku tym dodajemy wpis sfGuardAuth w parametrze enabled _

modules oraz ustawiamy domyślne akcje. Akcja login_ wywoływana jest w sytuacji, kie-

dy niezalogowany użytkownik próbuje otworzyć

Własny „słup ogłoszeniowy”Aż trudno uwierzyć, że na 5 stronach artykułu można zadbać o bezpieczeństwo aplikacji, tworząc działający mechanizm rejestracji oraz autoryzacji. Pewnie trudno Ci będzie uwierzyć, że możesz osiągnąć ten efekt w Twoich aplikacjach, przy niewielkich nakładach czasu i pracy.

Dowiesz się:• W jaki sposób stworzyć w pełni funkcjonalny

system autoryzacji;

• Zadbać o przejrzyste adresy stron w aplikacji;

• Stworzyć panel administracyjny.

Powinieneś wiedzieć:• W jaki sposób zainstalować symfony;

• Wszystko, co znajdowało się w części I artykułu.

Poziom trudności

Konta użytkowników oraz administracja

Listing 1. Włączenie modułu sfGuardAuth oraz zdefiniowanie akcji dotyczących autoryzacji – plik settings.yml all:

.settings:

enabled_modules: [default, sfGuardAuth]

.actions:

login_module: sfGuardAuth

login_action: signin

secure_module: sfGuardAuth

secure_action: secure

Page 65: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200864

WarsztatSłup ogłoszeniowy w Symfony

www.sdjournal.org 65

zabezpieczoną stronę, natomiast secure_, gdy użytkownik nie posiada wystarczających upraw-nień (ang. credentials) do otwieranej akcji.

Efekt naszej pracy możemy podejrzeć, wcho-dząc na adres http://postup/postup_dev.php/sfGuardAuth/signin (Rysunek1).

Dostosowanie wyglądu strony logowaniaDomyślna strona formularza logowania nie wy-gląda zachęcająco. Przygotujemy szablon, który będzie bardziej czytelny. Aby nadpisać domyśl-ny szablon w pluginie:

• tworzymy nowy katalog sfGuardAuth w katalogu /postup/apps/postup/modules/;

• w nowo utworzonym katalogu sfGuar-dAuth tworzymy katalogi templates/ oraz validate/;

• w katalogu templates/ tworzymy plik wy-glądu szablonu signinSuccess.php i wprowa-dzamy zawartość (Listing 2);

• w katalogu validate/ tworzymy plik si-gnin.yml (Listing 3).

Po wprowadzeniu tych zmian, możemy podej-rzeć nasz poprawiony wygląd formularza oraz zobaczyć polskie komunikaty błędów po wy-braniu Zaloguj się, bez wypełnienia formula-rza (Rysunek 2).

Dodawania ogłoszeń, tylko przez zalogowanych użytkownikówAby można było ograniczyć logowanie dla ekra-nu dodawania ogłoszeń, będziemy musieli:

• podmienić domyślne rozszerzenie klasy myUser na rozszerzenie oferowane przez sfGuardPlugin;

• dodać w wyglądzie nawigacje do akcji logo-wania się i wylogowania się;

• ustawić zabezpieczenie dostępu dla niezalo-gowanych użytkowników na akcję create w module advertisement, dopisujac do two-rzonego ogłoszenia informację o twórcy.

Podmienienia rozszerzenia klasy doko-nujemy w pliku postup/apps/postup/lib/myUser.class.php, w którym zamieniamy roz-szerzenie z sfBasicSecurityUser na sfGuardSe-curityUser.

<?php

class myUser extends sfBasicSecurityUser

{

}

Wygląd nawigacji umieścimy w głównym sza-blonie wyglądu postup/apps/postup/templates/layout.php. Dodamy go do nagłówka strony ko-ło linku Strona główna” (Listing 6)

Wprowadziliśmy dwa linki, które pokazują się w zależności od tego, czy jesteśmy zalogo-wani czy nie. Ustawienie zabezpieczeń wpro-wadzamy, tworząc katalog config/ w katalogu modułu advertisement (postup/apps/postup/advertisement/), a następnie tworzymy w nim plik security.yml zawierający:

create:

is_secure: on

Po zmianie konfiguracji, pamiętać warto o wy-czyszczeniu zawartości cache, podając w ka-talogu projektu komendę, poznaną wcześniej komendę:

> symfony cc

Rysunek 1. Wygląd aplikacji – domyślny formularz logowania pluginu sfGuardPlugin

Listing 2. Zawartość pliku signinSuccess.php

<?php use_helper('Validation') ?>

<h2>Logowanie</h2>

<p>Tworząc nowe konto, uzyskasz dostęp do dodawania ogłoszeń. </p>

<div id="sf_guard_auth_form">

<?php echo form_tag('@sf_guard_signin') ?>

<fieldset>

<div class="form-row" id="sf_guard_auth_username">

<?php

echo form_error('username'),

label_for('username', 'Nazwa użytkownika'),

input_tag('username', $sf_data->get('sf_params')->get('username'));

?>

</div>

<div class="form-row" id="sf_guard_auth_password">

<?php

echo form_error('password'),

label_for('password', 'Hasło'),

input_password_tag('password');

?>

</div>

</fieldset>

<?php echo submit_tag('Zaloguj się') ?>

</form>

</div>

Page 66: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200866

WarsztatSłup ogłoszeniowy w Symfony

www.sdjournal.org 67

Informację o twórcy ogłoszenia można szybko do-dać, poprzez dopisanie do schematu bazy danych takiego pola, przeładowanie ustawień bazodano-wych oraz dopisanie do akcji tworzenia ogłosze-nia (executeCreate()) zapisu informacji o twór-

cy (w stylu $this->ad->setCreatedBy($this->getUser()->getUsername());. Wykonanie tej pracy pozostawimy Tobie.

Gotowe. Teraz możemy sprawdzić, jak wszystko dobrze działa. Zaloguj się (nazwa

użytkownika: admin, hasło: admin), dodaj ogłoszenie, zobacz, co się stanie po wybraniu Dodaj ogłoszenie, gdy jesteś niezalogowany.

Tworzenie kont użytkownikówZ zagadnień dotyczących kont użytkowników brakuje nam jeszcze rejestracji nowych kont. Przy ich tworzeniu zadbamy również o weryfikację wprowadzanych adresów e-mail. Do tego celu w aplikacji stworzymy nowy moduł o nazwie user.

> symfony init-module postup user

W związku z tym, że w trakcie pisania artyku-łu, formularze były gruntownie przebudowy-wane, nie będziemy dokładnie ich omawiać (gotowy moduł możemy pobrać z płyty, która była dołączona do Software Developer’s Jour-nal 07/2008 – z pliku postup2_user_src.tgz).

Aby go zainstalować, rozpakowywujemy mo-duł user do katalogu postup/apps/postup/modules/ a następnie czyścimy cache (symfony cc), http://postup/index.php/user/register .

Gdy mamy gotową akcję rejestracji, pozostaje tylko utworzyć link w głównym szablonie wy-glądu layout.php.

Zarządzanie ogłoszeniami oraz użytkownika-mi przez administratoraPrzygotowana od tego momentu aplikacja po-winna już działać bez większych niespodzia-nek. Problemów przysporzyć nam może już tylko sam użytkownik, który zechce korzystać z niej nie tak, jak planowaliśmy. A co w sytuacji, w której użytkownik doda ogłoszenie w złej ka-tegorii, zapomni hasła, czy naruszy ustalone za-sady? W tym celu, przygotujemy panel admini-stracyjny, w którym, będziemy zarządzać naj-wrażliwszymi elementami.

Czego potrzebujemy?Na potrzeby tego artykułu skupimy się tylko na najważniejszych aspektach.

Przede wszystkim potrzebna jest nam moż-liwość administrowania zamieszczonymi ogło-szeniami. Poprzez administruję, mamy na myśli głównie edycję i wyłączanie istniejących ogłoszeń.

Kolejną kwestią jest samo zarządzanie użytkow-nikami. Przyda się możliwość zmiany haseł, czy blokowania kont niesfornym użytkownikom.

Na koniec, damy zalogowanym użytkownikom możliwość zgłaszania do administratora proble-matycznych ogłoszeń. Informacja o zgłoszeniach zostanie wysłana na e-mail administratora.

Administracja ogłoszeniamiAby uzyskać oczekiwaną funkcjonalność, mo-żemy skorzystać z admin-generatora, którego dostosujemy do naszych potrzeb.

Generowanie zarządzania ogłoszeniami mo-żemy stworzyć komendą:

> symfony propel-init-admin postup adminAd Ad

Listing 3. Zawartość pliku walidacji – signin.yml

methods:

post: [username, password]

names:

username:

required: true

required_msg: Musisz podać nazwę użytkownika

validators: [userValidator] # zdefiniowanie walidatora userValidator

password:

required: true

required_msg: Musisz podać hasło

userValidator:

class: sfGuardUserValidator # klasa odpowiedzialna za walidację

param:

password_field: password

Listing 4. Kod generator.yml dla modułu adminAd

generator:

class: sfPropelAdminGenerator

param:

model_class: Ad

theme: default

fields: # ZDEFINIOWANIE NAZW DLA PÓL

title: { name: "Tytuł" }

content: { name: "Treść" }

city: { name: "Miejscowość" }

woj: { name: "Województwo" }

contact_name: { name: "Kontakt" }

contact_phone: { name: "Telefon" }

contact_mail: { name: "E-mail" }

is_published: { name: "Opublikowany" }

category_id: { name: "Kategoria" }

created_at: { name: "Data utworzenia" }

updated_at: { name: "Data aktualizacji" }

list: # ZDEFINIOWANE ELEMENTÓW WIDOKU LISTY

title: "Lista ogłoszeń"

display: [=title, contact_name, created_at, is_published, category_id]

filters: [title, category_id, is_published]

max_per_page: 10

edit: # ZDEFINIOWANIE ELEMENTÓW WIDOKU EDYCJI

display: # ustalenie, co i jak należy pokazać w widoku edycji

"Ogłoszenie": [title, content, category_id, city, woj]

"Kontakt": [contact_name, contact_phone, contact_mail]

"Właściwości": [is_published, created_at, updated_at]

fields: # - wyłączenie edycji pól z datami

created_at: { type: plain }

updated_at: { type: plain }

content: { params: size=77x10 } # większe pole dla treści wiadomości

Page 67: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200866

WarsztatSłup ogłoszeniowy w Symfony

www.sdjournal.org 67

gdzie adminAd oznacza nazwę tworzonego przez nas modułu, natomiast Ad klasę ogło-szeń w modelu danych. Efekt możemy podej-rzeć na stronie modułu: http://postup/postup_dev.php/adminAd

Pozostaje nam tylko dostosowanie generowa-nego kodu w pliku postup/apps/postup/modules/adminAd/config/generator.yml do naszych po-trzeb (Listing 4).

Dostosowany wygląd zarządzania ogło-szeniami możemy podejrzeć na stronie http:

//postup/postup_dev.php/adminAd. Nie mo-żemy jednak zapomnieć o nałożeniu dostę-pu do tego modułu tylko dla administrato-ra systemu ogłoszeń. Podobnie jak wcześniej, tworzymy plik security.yml w katalogu konfi-guracji (postup/apps/postup/modules/adminAd/config/). Zawartość konfiguracji opisaliśmy na Listingu 5.

Wpis credentials: admin będzie ograni-czał dostęp tylko dla użytkowników posiadają-cych uprawnienia administratora. Zachęcamy

do przetestowania działania usługi przy logo-waniu się jako zwykły użytkownik.

Na koniec dodamy link w głównym szablo-nie wyglądu (plik layout.php):

<?php if ($sf_user->hasCredential('admin

')): ?>

<li><?php echo link_to('Zarządzaj

ogłoszeniami', 'adminAd/list') ?></li>

<?php endif; ?>

Zarządzanie użytkownikamiPrzy zarządzaniu kontami użytkowni-ków gotowe rozwiązanie dostarcza moduł sfGuardPlugin, który zainstalowaliśmy na po-czątku artykułu.

Plugin sfGuardPlugin oprócz wykorzystane-go wcześniej modułu sfGuardAuth do logowa-nia posiada moduły:

• sfGuardUser – do zarządzania kontami użytkowników;

• sfGuardGroup – do zarządzania grupami użytkowników;

• sfGuardPermission – do zarządzania uprawnieniami, które mogą być przypisywa-ne do grup oraz do poszczególnych użytkow-ników.

Dzięki takiej budowie i możliwości definiowa-nia użytkowników, grup i uprawnień w relacji wiele do wielu, sfGuardPlugin staje się bardzo elastycznym dodatkiem przy różnorodnych rozwiązaniach.

Do naszych potrzeb skorzystamy jedynie z kont użytkowników. Do tego celu włączymy moduł sfGuardUser w poznanym już wcześniej pliku konfiguracji settings.yml, dopisując go do parametru enabled_modules (pamiętając o późniejszym wyczyszczeniu cache). Efekt mo-żemy zaobserwować na stronie http://postup/postup_dev.php/sfGuardUser.

Podobnie jak przy module adminAd, musi-my ograniczyć dostęp do tego modułu tylko dla administratorów. Dokonujemy tego, two-rząc katalog sfGuardUser w postup/apps/postup/modules/, a następnie tworząc w nim katalog config i tworzymy plik settings.yml z zawartością opisaną w Listingu 5.

Na koniec dopisujemy link w głównym sza-blonie wyglądu (plik layout.php) (Listing 7)

Listing 5 – Ograniczenie uprawnień do całego modułu tylko dla administratora – plik settings.yml w konfiguracji modułu

all:

is_secure: on

credentials: admin

Listing 6. Dodanie nagłówka strony koło linku Strona główna

...

<ul>

<li><?php echo link_to('Strona główna', '@homepage') ?></li>

<?php if ($sf_user->isAuthenticated()): ?>

<li><?php echo link_to($sf_user->getUsername() . ' - wyloguj się', 'sfGuardAuth/

signout') ?></li>

<?php else: ?>

<li><?php echo link_to('Logowanie', 'sfGuardAuth/signin') ?></li>

<?php endif; ?>

</ul>

...

Listing 7. Dopisanie linku w głównym szablonie

<?php if ($sf_user->hasCredential('admin')): ?>

<li><?php echo link_to('Zarządzaj ogłoszeniami', 'adminAd/list') ?></li>

<li><?php echo link_to('Zarządzaj użytkownikami', 'sfGuardUser/list') ?></li>

<?php endif; ?>

Rysunek 2. Wygląd aplikacji – przygotowany szablon logowania zawierający polskie komunikaty błędów

W Sieci

O instalacji sfGuardPlugin można przeczy-tać na stronie: http://www.symfony.pl/link/sfGuardPlugin.

Niestety, w artykule tym nie poświęcimy miejsca na używanie wielojęzyczności, do-stępnej w Symfony. Szczegóły dotyczące sposobu korzystania z wielojęzyczności możesz poznać na http://www.symfony.pl/link/i18n

Page 68: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200868

Warsztat

Krótsze adresy stronNajwyższy czas wziąć się za czytelność dłu-gich adresów, które stworzyliśmy. Od same-go początku naszego ciągu artykułów two-rzyliśmy adresy długie i nieczytelne w stylu: http://postup/index.php/advertisement/categoryList/category/praca

Czy nie przyjaźniejsze by były krótsze, czy-telne i po polsku?

Kolejną, równie istotną kwestią jest opty-malizacja w wyszukiwarkach. Z całą pewno-ścią przy pozycjonowaniu nie chcielibyśmy, aby nasza strona pojawiała się przy podaniu w wyszukiwarce np. słów: categoryList czy sfGu-ardPlugin.

Wykorzystujemy routingNajwyższy czas edytować reguły przekierowań. W zależności od tego, czy posiadamy dostęp do konfiguracji mod_rewrite na naszym serwe-rze, adresy mogą być podawane ze skryptem in-dex.php lub też bez niego.

Ustawmy następujące adresy:

• zamiast http://postup/advertisement/show/id/1 zróbmy krótki adres http://postup/ogloszenie/1

• nazwa kategorii niech ma adres np. http://postup/kategoria/praca

• dodawanie ogłoszeń: http://postup/dodaj_oglo-szenie

• rejestracja: http://postup/rejestracja

Otwórzmy sobie plik routing.yml (znajdu-je się w katalogu postup/apps/postup/config/) i dodajmy sobie kilka reguł u góry tego pliku.

• ogloszenie:

url: /ogloszenie/:id

param: { module: advertisement, action:

show }

• kategoria:

url: /kategoria/:category

param: { module: advertisement, action:

categoryList }

• dodaj_ogloszenie:

url: /dodaj_ogloszenie

param: { module: advertisement, action:

create }

• rejestracja:

url: /rejestracja

param: { module: user, action: register }

Po zmianie konfiguracji pamiętajmy wyczy-ścić cache:

> symfony cc

Kiedy zobaczymy ponownie naszą stronę głów-ną, miło zaskoczy nas, że na stronie wszyst-kie zdefiniowane adresy zmieniły się na krót-kie. Dzięki systemowi routingu i korzystania z funkcji link _ to, wszystkie generowane od-syłacze tworzą się zgodnie z zdefiniowanymi przez nas regułami. Zasada ta również będzie działać globalnie dla całej aplikacji, niezależnie, czy będzie to zwykła strona, wysyłany mail czy RSS. Ostateczny test, spróbujmy otworzyć sobie stronę: http://postup/kategoria/praca

Jeżeli chcesz wiedzieć więcej na temat rutin-gu, zapraszamy na stronę http://www.symfony.pl/link/routing.

PodsumowanieJedyne 5 stron, a udało się tak dużo zrobić. Goto-we dzieło zamieściliśmy na płycie dołączonej do SDJ 07/2008 (plik postup_art2_gotowa_src.tgz) Można by jeszcze wymyślać dodatkową funkcjo-nalność, jednak pozostawimy to Twojej pomysło-wości, drogi Czytelniku.

W następnym artykule dokładnie opiszemy ostatni i najważniejszy element – przygotowanie oraz opublikowanie aplikacji na serwerze. Sądzę, że ten temat z pewnością też Cię zainteresuje.

Rysunek 3. Wygląd aplikacji – formularz rejestracji nowego użytkownika

Rysunek 4. Wygląd aplikacji – panel administracji z ogłoszeniami

PIOTR PLENIKWspółzałożyciel firmy TeamLab.pl, specjalizującej

się w wytwarzaniu oprogramowania klasy enterpri-

se. Redaktor serwisu www.symfony.pl. Programista

PHP od ośmiu lat, od dwóch lat tworzący biznesowe

aplikacje w symfony. Programista Stowarzyszenia

Klon/Jawor przy największym Ogólnopolskim Por-

talu dla Organizacji Pozarządowych www.ngo.pl.

Student ostatniego roku Polsko-Japońskiej Wyższej

Szkoły Technik Komputerowych. Interesuje się zarzą-

dzaniem projektami biznesowymi oraz open source,

programowaniem (PHP, ASP.NET, Java), a także ba-

zami danych (MS SQL, Postgres, MySQL).

Kontakt z autorem: [email protected]

Page 69: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5
Page 70: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200870

ZestawienieZestawienie narzędzi do testowania oprogramowania

www.sdjournal.org 71

Microsoft Visual Studio Team System for Testers i Test Load Agent Dzisiejsze systemy oprogramowania korzy-stają z wielu rozproszonych usług, łącząc ze sobą platformy, protokoły oraz języki progra-mowania. Wszystkie te elementy mają zna-czący wpływ na środowisko operacyjne. Ze-społy pracowników osiągają coraz większy stopień specjalizacji i geograficznego rozpro-szenia. Pomyślne wdrożenie nowoczesnych rozwiązań zależy od tego, czy uda się poko-nać dystans komunikacyjny pomiędzy dzia-łem programistycznym i operacyjnym, tak aby cały dział IT był często i już od początku angażowany w prace związane z cyklem życia oprogramowania.

W przeszłości narzędzia do testowania i narzędzia programistyczne były oddzielny-mi narzędziami. Testerzy używali oddziel-nego środowiska, a pisane przez nich skryp-ty testowania były zapisywane w oddziel-nym repozytorium i nie były uwzględniane w kontroli źródła. Wyniki były czasem nie-przewidywalne, śledzenie usterek trudne, a wydajność testowana zazwyczaj w momen-cie, gdy cykl programowania był już prawie zakończony. Z tej przyczyny z cyklem pro-gramistycznym wiązały się dodatkowe kosz-ty, czas i stres. W programie Microsoft Visu-al Studio Team Edition for Software Testers funkcje testowania zostały ściśle połączo-ne z funkcjami współpracy programistycz-nej – wszyscy członkowie zespołu maję do-stęp do ogólnego udostępnionego magazynu umożliwiającego korzystanie z opcji oceny i raportowania.

Poniżej przedstawione jest zestawienie moż-liwości pakietu Microsoft Visual Studio Team Edition for Software Testers:

• dynamiczna analiza kodu, statyczna anali-za kodu, profilowanie kodu – narzędzia z możliwością dostosowywania oraz wyszu-kiwania dowolnych elementów. Można ich używać w ramach procedur rejestrowania na potrzeby kompilacji nocnej, co pozwa-la usuwać usterki przed zarejestrowaniem kodu w drzewie źródłowym; w rezultacie otrzymujemy znaczną redukcję nakładu pracy związanego z przeróbkami przez te-stowanie jakości kodu już na najwcześniej-szych etapach programowania;

• automatyczne, sterowane danymi testo-wanie modułów przez programistów – rozszerzalne środowisko testowe z testa-mi podstawowymi korzystającymi ze sta-rych wersji przypadków testowych oraz dodatkowych typów testów, co pozwala na utworzenie i wbudowanie testów nie-standardowych. W rezultacie otrzymuje-my możliwość ponownego wykorzystania i powtarzania testów co zmniejsza koszty, oszczędza czas i poprawia jakość;

• testowanie obciążenia– wydajne gene-rowanie testów obciążeniowych i pro-ste wdrażanie testowanego kodu, a także wsteczne wdrażanie dzienników i wyni-ków testów; w rezultacie programiści i te-sterzy mogą symulować obciążenia pro-dukcyjne i szybko wykrywać problemy z wydajnością w laboratoriach testowych oraz środowiskach przedprodukcyjnych;

• integracja z programem Team Foundation Server – umożliwia jednoczesne wyświetla-nie testu, kodu oraz metryki wymagań co w rezultacie owocuje zaangażowaniem całego zespołu do wczesnego wykrywania wąskich gardeł w czasie całego cyklu programowania;

• automatycznie generowane testy stron in-ternetowych z możliwością dostosowa-nia – niestandardowe zasady związane ze sprawdzaniem i wydzielaniem oraz do-datkowe narzędzie do testowania stron in-ternetowych, które może wywoływać kod podczas wykonywania testu. Automatycz-ne generowanie kodu na podstawie zareje-strowanych testów i wykorzystanie posia-danych umiejętności programistycznych do tworzenia i poprawiania testów przy wykorzystaniu pełnej integracji z progra-mem Visual Studio i językami z rodziny .NET; w rezultacie otrzymujemy skróce-nie wydłużającego się czasu potrzebnego na tworzenie i wykonywanie testów;

• obsługa wbudowanych metodologii – za-stosowanie wbudowanych technologii Agile i CMMI pozwala zarządzać testami w taki sam sposób, jaki stosowany jest w odniesieniu do kodu w całym okresie cy-klu programowania; w rezultacie narzuco-ne zasady zwiększają wydajność testerów.

Dla programistów aplikacji internetowych Mi-crosoft oferuje dodatkowe, dedykowane roz-wiązanie – Visual Studio Team System Test Load Agent – umożliwiające generowanie te-stowego obciążenie dla aplikacji interneto-wych. W rezultacie Test Load Agent umożli-wia podniesienie jakości obsługi poprzez bar-dziej dokładne testowanie wydajności aplikacji i serwerów internetowych pod obciążeniem. Visual Studio Team System Test Load Agent, na który składa się zarówno oprogramowanie agenta, jak i kontrolera, pozwala na łatwe roz-szerzanie i dostosowywanie funkcjonalności, dając testerom dużą elastyczność oraz możli-wość korzystania z następujących funkcji:

• symulowanie około 1.000 użytkowników na procesor;

Zestawienie narzędzi

Zestawienie ma na celu prezentację najpopularniejszych komercyjnych rozwiązań przeznaczonych do kompleksowego testowania oprogramowania, stanowiących nieocenioną pomoc przy codziennej pracy każdego twórcy oprogramowania. Mam nadzieję, że opisane tu alternatywy zachęcą Czytelników do korzystania z tych narzędzi, a jednocześnie pomogą wybrać rozwiązanie najlepiej dostosowane do Ich indywidualnych potrzeb.

do testowania oprogramowania

Page 71: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200870

ZestawienieZestawienie narzędzi do testowania oprogramowania

www.sdjournal.org 71

• precyzyjne symulowanie obciążenia i te-stowanie wydajności aplikacji i serwerów internetowych;

• licencja pozwalająca na symulację nieogra-niczonej liczby użytkowników w jednym procesie (z obsługą procesorów dwurdze-niowych);

• ścisła integracja z Visual Studio Team Sys-tem Team Foundation Server, co pozwala na integrację danych z testów w różnego rodzaju raportach analitycznych.

Parasoft SOAtestParasoft SOAtest 5.5 dodaje nowe możliwości do obszernego pakietu testowego oferowane-go przez firmę Parasoft i jest zaprojektowane specjalnie pod kątem zwiększenia produktyw-ności oraz efektywności zespołów programi-stycznych, pracujących nad złożonymi archi-tekturami zorientowanymi na usługi (Service Oriented Architectures, SOA) – także tych, które pracują w środowisku Microsoft .NET.

Parasoft SOAtest 5.5 to pierwsze rozwią-zanie do testów SOA, które oferuje pełną obsługę środowisk wieloprotokołowych, w tym Windows Communication Foundation (WCF). Nowością programu jest funkcja, któ-ra pozwala programistom .NET badać komu-nikaty wysyłane za pośrednictwem wielu pro-tokołów, łącznie z zastrzeżonymi formatami Microsoftu. SOAtest 5.5 ściśle integruje się z pakietem Microsoft Visual Studio Team Sys-tem for Software Testers, dzięki czemu pro-gramiści mogą współdzielić, organizować i wykonywać projekty Parasoft SOAtest, odczy-tując wyniki bezpośrednio z poziomu Micro-soft Visual Studio.

Parasoft SOAtest 5.5 zapewnia też zauto-matyzowaną funkcję tworzenia inteligent-nych atrap. Atrapy naśladują działające syste-my, dzięki czemu producenci oprogramowa-nia mogą testować usługi w kontekście rzeczy-wistego działania aplikacji, nie zakłócając dzia-łania systemu produkcyjnego. Oszczędza to mnóstwo czasu i zasobów.

Poniżej przedstawione jest zestawienie moż-liwości Parasoft SOAtest 5.5:

• wsparcie dla .NET WCF – klient SOAP wbudowany w rozwiązanie jest w stenie odwoływać się do usług Windows Com-munication Foundation (.NET 3.0) wyko-rzystujących zarówno TCP jak i HTTP ja-ko warstwę transportu;

• integracja z Microsoft VSTS – SOAtest oferuje wspacie dla użytkowników pakie-tu Microsoft VSTS Software Tester Edi-tion. Integracja obejmuje zarządzanie i wy-

konywanie projektów testowych na pod-stawie rezultatów uzyskanych bezpośred-nio z Visual Studio;

• automatyczne tworzenie i umieszczanie atrap dla istniejących zestawów testów – SOAtest jest w stanie szybko i łatwo au-tomatyzować emulację serwera dla wielu platform co znacznie ułatwia współpracę pomiędzy rozproszonymi grupami i zna-cząco skraca cykl produkcji oprogramowa-nia. Użytkownicy SOAtest mogą przy po-mocy wizualnych narzędzi projektować przebieg obciążenia serwisu i na podsta-wie uzyskanych wyników tworzyć atrapy emulujące zachowanie serwisu.

Dodatkowo SOAtest wspiera:

• weryfikację zgodności z WS-I (na podsta-wie schematów WSDL i weryfikacji se-mantycznej);

• SOAP, PoX (Plain XML) REST, JSON i BPEL;

• testowanie EJB;• testowanie asynchroniczne;• szereg standardów WS-*;• załączniki MTOM(XOP)/MIME/DIME;

• UDDI – weryfikację zapytań, walidację i testowanie obciążenia;

• testowanie oparte na danych;• stosowanie metryk QoS (ang. Quality of

Service) przy testach obciążenia;• automatyczne wykonywanie testów obcią-

żenia i śledzenie metryk wydajności w po-szczególnych fazach cyklu produkcji opro-gramowania;

• penetracyjne testy bezpieczeństwa.

Wymagania:

• Platforma: Windows 2000/XP i Vista, Li-nux bądź Solaris;

• RAM: co najmnije 512 MB pamięci RAM per procesor; do wykonywania testów ob-ciążeniowych zalecane jest minimum 1024 MB RAM.

Pisząc SOAtest warto wspomnieć, iż jest to jeden z całej gamy produktów dedyko-wanych testowaniu oprogramowania ofe-rowanych przez firmę Parasoft. Informa-cje na temat pełnej oferty tej firmy moż-na znaleźć na jej stronie internetowej (http://www.parasoft.com/).

Wypowiedź Hewlett PackardPełny test procesu biznesowego wymaga przetestowania zarów-no interfejsu użytkownika, jak i wspomagających ten proces we-bserwisów. Działy kontroli jakości są na ogół obeznane z testo-waniem interfejsu użytkownika i stosują rozwiązania, które auto-matyzują i przyspieszają ten proces. Mogą one jednak nie radzić sobie z dokładnym testowaniem webserwisów, ponieważ braku-je im interfejsu użytkownika, a użytkownicy nie mają oprogra-mowania testującego. HP Service Test zapewnia testowanie in-terfejsu użytkownika oraz webserwisów, co umożliwia komplek-sowe testowanie procesu biznesowego.

Wypowiedź ParasoftPosiadanie właściwych narzędzi do przeprowadzania testów w architekturze SOA jest niezwykle istotne z uwagi na charakter wyzwań, jakie architektura SOA stawia przed osobami odpo-wiedzialnymi za zapewnienie jakości. Otóż środowiska zorien-towane na usługi (SOA) stają się coraz bardziej heterogeniczne. Współdziałać ze sobą muszą rożne interfejsy i protokoły. Archi-tektura SOA nie redukuje ilości tworzonych usług ani używanych standardów. Nie jest ograniczona też tylko do SOAP. Zawsze ma się do czynienia z wieloma aplikacjami i platformami. W związku z tym, aby zapewnić jakość procesom biznesowym, trzeba je do-kładnie przetestować w takim właśnie heterogenicznym środo-wisku. Używane do tego narzędzia muszą być bardzo elastycz-ne, tak aby nie tylko sterowały procesem i sprawdzały rezulta-ty wykonania, ale także mogły włączać i wyłączać współpracu-jące systemy dziedzinowe, dostarczając dla nich w łatwy sposób inteligentnych zaślepek. Dodatkowo istotny jest czynnik ludzki. Aby móc testować efektywnie w złożonym środowisku SOA bez umiejętności programowania i szerokie wiedzy o standardach i protokołach, narzędzie musi dostarczać łatwego i intuicyjnego interfejsu, który odetnie użytkownika od detali implementacyj-nych. SOAtest został stworzony właśnie z naciskiem na elastycz-ność, łatwość użycia i wspieranie heterogenicznych środowisk.

Marek Kucharski Prezes Zarządu Parasoft S.A.

Lubomir StojekEkspert ds. oprogramowa-nia do zarządzaniaHewlett-Packard Polska

Page 72: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200872

ZestawienieZestawienie narzędzi do testowania oprogramowania

www.sdjournal.org 73

HP QuickTest Professional i Service Test Aby skrócić czas i zmniejszyć koszty zwią-zane z testowaniem aplikacji, potrzebne są rozwiązania zapewniające pełną funkcjonal-ność we wszystkich środowiskach bizneso-wych i procesach. Oprogramowanie HP Qu-ickTest Professional wprowadza automaty-zację testów funkcjonalnych i regresji obej-mujących wszystkie główne aplikacje i śro-dowiska programowe. To rozwiązanie wyko-rzystuje koncepcję testowania sterowanego za pomocą słów kluczowych, co upraszcza tworzenie i obsługę testów. Pozwala ono te-sterom na tworzenie przypadków testowych przez przechwytywanie przepływów bezpo-średnio z ekranów aplikacji za pomocą za-awansowanej technologii przechwytywania. Dzięki zastosowaniu zintegrowanego środo-wiska skryptów i wprowadzania poprawek specjaliści ds. testowania zyskują także pełen dostęp do właściwości testów i obiektów niż-szego poziomu.

Poniżej przedstawione jest zestawienie pod-stawowych funkcji pakietu:

• tworzenie zaawansowanych zestawów testów już po minimalnym przeszkole-niu;

• poprawa współpracy pomiędzy grupami roboczymi dzięki zastosowaniu wspól-nych bibliotek funkcji, zarządzania obiek-tami i elastycznego przechowywania za-sobów;

• redukcja dokumentacji testowej;• szybsza naprawa awarii dzięki wprowa-

dzeniu pełnego dokumentowania i odtwa-rzania awarii dla programistów.

HP QuickTest Professional oferuje wspacie dla następujących technologii:

• Windows® Presentation Foundation;• Serwisy webowe;• Macromedia Flex;• .NET;• JEE;• Aplikacje ERP i CRM.

Dla twórców serwisów webowych HP oferu-je również dodatkowe, dedykowane rozwiąza-nie – HP Service Test. Rozwiązanie to dzięki automatyzacji upraszcza i przyśpiesza funk-cjonalne testowanie serwisów SOA usprawnia cały proces zarządzania jakością w systemach opartych na serwisach.

Borland SilkTestFirma Borland wspiera przedsiębiorstwa w lepszym zarządzaniu procesem produkcji oprogramowania dostarczając rozwiązania w ramach strategii Open Application Lifecyc-le Management (Open ALM). Wykorzysta-nie najlepszych praktyk związanych z two-rzeniem oprogramowania oraz unikatowego podejścia opartego na procesach, pozwala fir-mie Borland na dostarczenie niezależnych od platformy i od posiadanych narzędzi, spraw-dzonych rozwiązań dedykowanych następu-jącym obszarom:

• Zarządzanie Procesem Dostarczania Opro-gramowania (Borland Management Solu-tions);

• Zarządzanie Wymaganiami (Requirements Definition & Management);

• Zarządzania Jakością (Lifecycle Quality Management);

• Zarządzania Zmianą (Change Manage-ment).

Pakiet firmy Borland do zarządzania jakością w projektach informatycznych potrafi spro-stać największym wyzwaniom stojącym przed działami QA w niemal wszystkich firmach so-ftware'owych. Wdrożone w tysiącach korpo-racji na całym świecie rozwiązania firmy Bor-land do automatyzacji testów i integracji, za-rządzania i kontroli jakości pomagają w two-rzeniu wolnych od wad, odpowiadających za-łożeniom, wydajnych aplikacji w założonym czasie i określonym budżecie. Co więcej, raz dopasowane, potrafią zapewnić tę samą ja-kość w procesie wytwarzania oprogramowa-nie pomimo jego zmian, modyfikacji założeń czy środowisk.

Zalety rozwiązań firmy Borland umożliwiają zespołom projektowym:

• reagować na problemy związane z jakością już od samego początku projektu, koncen-trując się na jakości wymagań, modelu i kodu;

• zapewniać pełną widoczność zaawansowa-nie i współpracę wszystkich zespołów pro-jektowych, w tym również strony bizneso-wej;

• wspierać podejście oparte na sprawdzo-nych procesach, mające na celu wyelimi-nowanie powtórnej pracy nad tymi samy-mi elementami projektu.

Narzędzia wspierające działalność zespołów QA oferowane przez firmę Borland:

• Borland SilkCentral Test Manager: otwar-te środowisko do zarządzania testami, wspierającego zespoły QA w całym cyklu powstawania oprogramowania;

• Borland Gauntlet: rozwiązanie do aktyw-nego tworzenia, integrowania i weryfiko-wania kodu zanim trafi do wspólnego re-pozytorium, izolowania usterek, weryfi-kowania pokrycia kodu oraz zapewnienia ciągłości powstawania buildów przy uży-ciu tylko jednego narzędzia;

• Borland SilkTest: rozwiązanie do automa-tyzacji testów funkcjonalnych i regresyj-nych, charakteryzujące się łatwym w ob-słudze graficznym interfejsem użytkowni-ka, modułem nagrywania oraz stworzone-go specjalnie na potrzeby testów automa-tycznych języka;

• Borland SilkPerformer: narzędzie do auto-matyzacji testów obciążeniowych i wydaj-nościowych zapewnia pełna skalowalność systemów, pozwalając na zachowanie sta-bilności i przewidywalności przy różnym stopniu ich obciążenia.

Borland SilkTest jest produktem przeznaczo-nych dla profesjonalnych testerów i specjali-stów od jakości, oczekujących sprawdzonego i wydajnego rozwiązania z zakresu automaty-zacji testów regresyjnych i funkcjonalnych. In-

Wersje ewaluacyjne prezentowanych rozwiązań

• http://www.borland.pl/downloads/marketing/sdj/SilkTest2008SP1_001.exe – wersja testowa SilkTest,

• http://techpubs.borland.com/silk_gauntlet/SilkTest/2008SP1/tutorials/ – tutoriale związane z SilkTest,

• http://www.microsoft.com/downloads/details.aspx?FamilyID =572e1e71-ae6b-4f92-960d-544cabe62162&DisplayLang=en – Test Load Agent,

• http://www.microsoft.com/downloads/details.aspx?FamilyID=d95598d7-aa6e-4f24-82e3-81570c5384cb&DisplayLang=en – Visual Studio Team Suite – najbardziej rozbudowany pakiet VS wraz z rozszerzeniem Team System for testers,

• http://www.microsoft.com/downloads/details.aspx?FamilyID =c7a809d8-8c9f-439f-8147-948bc6957812&DisplayLang=en – maszyna wirtualna zawierająca preinstalowane narzędzia firmy Microsoft przedstawione w niniejszym artykule,

• http://www.parasoft.com/jsp/products/home.jsp?product=SOAP – strona domowa SOAtest; pobranie wersji ewaluacyjnej oprogramowania wymaga rejestracji,

• https://h10078.www1.hp.com/cda/hpdc/display/main/index.jsp?zn=bto&cp=54_4012_100 – wi-tryna z której można pobrać ewaluacyjne wersje oprogramowania firmy HP (wymaga reje-

Page 73: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200872

ZestawienieZestawienie narzędzi do testowania oprogramowania

www.sdjournal.org 73

tuicyjny interfejs graficzny pozwala na łatwe nagrywanie scenariuszy, umożliwiające wie-lokrotne odtwarzanie i modyfikację w dowol-nym momencie, przy użyciu łatwego w obsłu-dze języka skryptowego. SilkTest oferuje pro-stotę tworzenia testów regresyjnych i funk-cjonalnych bez obawy, że raz stworzone prze-staną działać w przypadku zmian w kolejnych wersjach aplikacji – co jest poważnym proble-mem wielu obecnych na rynku rozwiązań. SilkTest oferuje stabilność i kompatybilność z większością środowisk, używanych w firmach i organizacjach, dostarczając funkcjonalno-ści łatwego przeprowadzania testów regresyj-nych i funkcjonalnych o szerokim spektrum zastosowania.

Poniżej przedstawione jest zestawienie moż-liwości Borland SilkTest jako narzędzia do au-tomatycznego testowania regresyjnego i funk-cjonalnego:

• jedno rozwiązanie do tworzenia i urucha-miania wszystkich testów funkcjonalnych i regresyjnych w całym przedsiębiorstwie;

• łatwy w użyciu kreator pomoże początku-jącym użytkownikom tworzyć efektywne testy już za pierwszym razem;

• zaawansowane testy mogą być tworzone przy użyciu elastycznego obiektowego ję-zyka czwartej generacji, stworzonego spe-cjalnie dla testerów;

• pełne wsparcie dla unicode pozwala na pełną swobodę bez względu na lokalizację testowanej aplikacji czy systemu;

• wbudowany system odzyskiwania stanu aplikacji, w przypadku wystąpienia błę-du zwraca system w stanie sprzed usterki i wznawia dalsze kroki testu, w przeciwień-stwie do wielu rozwiązań dostępnych na rynku, które kontynuują wykonywanie te-stu w stanie niestabilnym aplikacji;

• system agentów umożliwia uruchamianie na wielu komputerach i w różnych środo-wiskach bez konieczności kupowania peł-nej licencji dla każdego z nich;

• wizualne raporty oparte na TrueLog™ upraszczają diagnostykę problemów w przypadku wykrycia usterek;

• pełna integracja z narzędziami firmy Bor-land do zarządzania testami oraz do zarzą-dzania zmianą i konfiguracją umożliwia lepszą automatyzację procesów w ramach działań QA.

Testowanie funkcjonalne aplikacji w architek-turze SOA wymaga przeprowadzania testów bez interfejsu użytkownika. Borland oferuje taką możliwość w rozwiązaniu Silk Perfomer SOA Edition.

Wymagania dla Borland SilkTest:

• Platforma: Windows 2000 (wersja 5.0, Se-rvice Pack 4), Windows XP (wersja 5.1, Service Packs 1, 1a, 2), Windows Server 2003 (Service Pack 1), lub Windows Vista, Red Hat Enterprise Linux WS (version 2.1 and3.0) lub Solaris (wersja 9 i 10) dla apli-kacji tworzonych w systemie Motif;

• Procesor: Intel Pentium 1 Ghz;• RAM: 512 MB pamięci RAM dla maszyn

działających pod kontrolą Windows 2000 lub 1 GB RAM dla maszyn działających pod kontrolą Windows XP, 2003, lub Vi-sta. Do tych wymagań należy dodać ilość pamięci RAM potrzebnej do działania te-stowanej aplikacji.

PodsumowanieJak widać po zaprezentowanych opisach, każde z proponowanych narzędzi stanowi pewne roz-wiązanie kompleksowe – dodatkowo osadzone w pewnej większej rodzinie produktów. Ciężko jest porównywać tego typu rozwiązania, jeszcze trudniej wybrać to właściwe. Czytelników, któ-rzy w trakcie czytania niniejszego artykułu za-interesowali się danym produktem, gorąco za-chęcam do pobrania jego wersji ewaluacyjnej i zapoznania się z nim w praktyce – jest to chyba najlepsza droga do stwierdzenia czy dane roz-wiązanie pasuje do konkretnych wymagań, któ-rych jest przecież niezliczona ilość. W ramce Wersje ewaluacyjne prezentowanych rozwiązań umieszczone są konkretne namiary na prezen-towane tu produkty. Jedno jest pewne – warto zainteresować się narzędziami wspomagający-mi proces testowania oprogramowania – dzię-ki nim nasze programy, stają się bardziej nie-zawodne, a życie zarówno programistów jak i użytkowników – łatwiejsze.

RAFAŁ KOCISZ pracuje na stanowisku Dyrektora Technicznego w

firmie Gamelion, wchodzącej w skład Grupy BLStre-

am. Grupa BLStream powstała by efektywniej wy-

korzystywać potencjał dwóch, szybko rozwijają-

cych się producentów oprogramowania – BLStre-

am i Gamelion. Firmy wchodzące w skład grupy

specjalizują się w wytwarzaniu oprogramowania

dla klientów korporacyjnych, w rozwiązaniach mo-

bilnych oraz produkcji i testowaniu gier.

Kontakt z autorem: [email protected]

Page 74: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

Wywiad

10/200874

Wywiad

www.sdjournal.org 75

SDJ: Proszę opowiedzieć o swoich począt-kach w Serena Software.Kevin Parker: Początkowo pracowałem w Serenie jako kierownik produktu. Dość szyb-ko zostałem wicedyrektorem działu badań i rozwoju oprogramowania, prowadziłem ten dział przez 8 lat, współtworzyłem projekt fra-mework dla Eclipse'a do zarządzania cyklem życia aplikacji (który wszyscy nazywają ALF – Aplication Lifecycle Framework), a przez ostatnie trzy i pół roku byłem mentorem dla całej firmy.

SDJ: Rozpoczynając prezentację na kon-ferencji Software Development Giga-Con stwierdził Pan, że to COBOL był Pa-na pierwszym językiem, dlaczego?KP: W mojej pierwszej pracy byłem pro-gramistą COBOL-a. Pisałem aplikacje w CO-BOL-u od 1978 do 1988 roku. A dziś na ca-łym świecie w ciągu roku – co jest zasko-czeniem dla ludzi – powstaje jakieś 15 mi-lionów linii nowego kodu w COBOL-u. Ję-zyk ten jest więc daleki od wyginięcia – po-dobnie jak słychać, że komputery typu ma-inframe są już martwe, a nie są; IBM wy-puszcza coraz więcej komputerów main-frame każdego roku i są one kręgosłupem wielu systemów biznesowych. Z tego wła-śnie się wywodzę. Miałem szczęście w mo-jej karierze i zawsze umiałem dostosować się do każdej fali nowej technologii. Z do-świadczenia wiem, że to co robiło się 30 lat temu, robi się i dziś. Używamy innej termi-nologii, wszystko robimy znacznie szybciej i znacznie łatwiej, ale podstawowe dyscy-pliny są dokładnie takie same, jak to już by-ło 30 lat temu. Bardzo mi się podoba moż-liwość patrzenia z tej perspektywy, bo to pomaga mi przewidzieć, jakie następne problemy zostaną stworzone przez no-we technologie. W Serenie pomagamy lu-dziom rozwiązywać problemy zarówno na komputerach mainframe (od 1980 ro-ku), jak i na platformach Unix czy Micro-soft Windows. Posiadanie doświadczeń we wszystkich tych obszarach oznacza, że je-steśmy rzeczywiście dobrzy w tym, co ro-bimy.

SDJ: Jakie języki programowania i tech-nologie stosuje Serena Software w two-rzeniu aplikacji?KP: Dziś w Serenie tworzymy aplikacje w większości w Javie. Stronę serwerową pisze-my w C++. Wciąż opracowujemy aplikacje dla mainframe w Assemblerze. Zatem uży-wamy tego, co uważamy że jest najodpo-wiedniejszym językiem dla określonej plat-formy i określonego komponentu architek-tury.

SDJ: Czy używacie również .NET?KP: Ogólnie posiadamy dwie najważniej-sze platformy architektoniczne. Jedną z nich jest .NET i jest to jedna z podstawowych plat-form, których używamy dla tworzenia więk-szości kodu strony serwerowej; drugą plat-formą używaną do programowania strony klienckiej jest Eclipse.

SDJ: Jakie jest podejście Serena Software do rozwoju Open Source i Linuksa?KP: Naszą strategią w stosunku do Linuk-sa jest strategia naszych klientów . Jeśli nasi klienci używają Linuksa, to my wspieramy Li-nuksa. Tak samo jak w przypadku systemów IBM AIX, SUN Solaris, HP-UX, czy jakichkol-wiek innych.

Rdzeniem naszego biznesu jest przestrzeń zarządzania cyklem życia aplikacji, to znaczy, pomaganie architektom i programistom w tworzeniu aplikacji w sposób bardziej efek-tywny. A dziś największa część naszych klien-tów to są największe korporacje na świecie. Więc np. 10 największych firm w 10 najwięk-szych sektorach gospodarki używa produk-tów Sereny. Zatem 10 największych banków, 10 największych firm ubezpieczeniowych, 10 największych wytwórców, 10 najwięk-szych firm telekomunikacyjnych na świe-cie, używa produktów Sereny do zarządza-nia cyklem życia aplikacji. A jedną z charak-terystycznych rzeczy dla wielkich firm jest to, że nie mają one zazwyczaj tylko jednej plat-formy systemowej czy deweloperskiej. Nie używają np. tylko .NET, albo tylko Javy, nie mają tylko platformy Linux albo Unix. Musi-my więc wspierać wszystkie platformy sys-

Wywiad z Kevinem Parker’em

Kevin Parker – Wiceprezes i Chief Evangelist w firmie Serena Software. Odpowiada za strategię rozwoju technologii. Posiada 30-letnie doświadczenie w branży, a zaczynał pracę od tworzenia oprogramowania. Jest m.in. posiadaczem trzech patentów technologicznych. Świetny, ceniony i chętnie zapraszany mówca.

Kevin Parker

Wiceprezes firmy Serena Software

Page 75: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

Wywiad

10/200874

Wywiad

www.sdjournal.org 75

temów operacyjnych, wszystkie platformy i narzędzia programistyczne, tak jak musi-my również wspierać wszystkie typy baz da-nych, jakie tam występują – Oracle, Sybase, DB2, SQL Server i MySQL. Musimy wspie-rać IDE, których oni używają, czyli np. Ecli-spe, Microsoft Visual Studio, WebSphere AD Studio, czy JBuilder. Musimy również wspie-rać różne używane przez naszych klientów narzędzia firm trzecich, jak np. HP Quality Center, czy Load Runner. Mamy zatem bar-dzo szeroki zestaw partnerów, a nierzadko i konkurentów, z którymi musimy się inte-grować, żeby wspierać naszych klientów. Za-tem – co powiedziałem na początku – gdzie jest strategia naszych klientów, tam jest i na-sza strategia.

SDJ: Jakie platformy systemowe i dewelo-perskie są zatem popularne wśród klien-tów, czy jest to Linux, czy raczej .NET i Windows?KP: Nie jest nią Linux. Pierwszym jest raczej Windows, drugim pewnie Solaris, a potem – rzekłbym blisko obok siebie – są HP-UX i Linux. Ale ponieważ spory odsetek naszych klientów wciąż używa komputerów mainfra-me, a w tych obszarach jesteśmy z pewnych względów wyjątkowi, to te platformy też wspieramy. Rzekłbym, że trzy najważniejsze systemy operacyjne z punktu widzenia Sere-ny, to Microsoft Windows, SUN Solaris i IBM z/OS na komputerach mainframe.

SDJ: Proszę wyjaśnić czym są narzędzia do tworzenia Mashupów biznesowych?KP: Dobre pytanie. Myślę że są na nie trzy możliwe – wzajemnie się uzupełniające – od-powiedzi.

Przede wszystkim, na rynku IT jest znacz-nie większe zapotrzebowanie na aplikacje, niż rynek jest w stanie dostarczyć. Użytkow-nicy biznesowi starają się nieumiejętnie roz-wiązywać swoje problemy informatyczne za pomocą arkuszy Excela, baz danych Acces-sa, oprogramowania ściąganego z Sieci oraz za pomocą siermiężnych aplikacji otrzyma-nych z gazet. To właśnie Mashupy bizneso-we są metodą na szybkie tworzenie aplikacji. poprzez ich prototypowanie, a potem wdro-żenie prototypu. Nauczyliśmy się z Web 2.0, że to co jest wystarczająco dobre, faktycz-nie jest wystarczająco dobre i wcale nie mu-si być doskonałe. Użytkownicy zwykle są za-dowoleni z najważniejszej funkcjonalności i nie potrzebują wszystkich bajerów i wodo-trysków.

Po drugie, użytkownicy biznesowi czasem nie wiedzą, jak zadać pytanie działom IT. Mu-shupy biznesowe to narzędzia, które pozwa-lają użytkownikowi samemu znaleźć odpo-wiedź. Użytkownik ma wgląd w to, gdzie leży rzeczywisty problem i sam najszybciej znajduje rzeczywiste rozwiązanie swojego

problemu. Najlepszym sposobem na wspar-cie użytkownika biznesowego w rozwiązy-waniu problemów jest udostępnienie im ich własnych danych.. A dane udostępniane w formie webservices są łatwiejsze w użyciu niż Microsoft Excel czy Visio. Serena Software umożliwia stworzenie i uruchomienie front-endu do tych webserwisów. To powoduje, że webserwisy są łatwe w użyciu, a nasza tech-nologia nadaje im ludzką twarz. Zatem użyt-kownicy biznesowi mogą odpowiedzieć na wiele swoich pytań nawet bez zawracania głowy IT. A to skraca listę problemów zgła-szanych działom IT.

Po trzecie, często użytkownicy biznesowi nie mogą dostać pełnej odpowiedzi od dzia-łów IT, bo część odpowiedzi jest informacją znajdującą się na zewnętrz organizacji. Było-by wspaniale, gdyby użytkownicy biznesowi mogli pozyskiwać informacje jednocześnie ze swoich centrów danych oraz z otocze-nia biznesowego, łączyć je ze sobą na swo-im pulpicie i znajdować odpowiedzi na swo-je pytania. I tak właśnie powstaje klasyczny Mashup. Na przykład użytkownik chce zlo-kalizować swoje ciężarówki (co wymaga po-łączenia informacje zawartych we własnych centrach danych z informacjami o położe-niu np. z Google Earth, bądź z map aktualnie wykonywanych prac drogowych na drogach międzymiastowych) żeby móc się z nimi po-łączyć i przekazać im, żeby zmienili trasę ob-jeżdżając Warszawę, bo na ich trasie zdarzył się wypadek i powstała blokada. Dzięki Ma-shupom użytkownicy uzyskują lepsze odpo-wiedzi na biznesowe problemy, stosując in-formację zintegrowaną, łącząc informację, która jest dostępna w Sieci wraz z informacją dostępną w ich systemach biznesowych.

Uważam, że Mashupy pod względem no-watorstwa są podobne do komputerów oso-bistych z czasów ich początków. Gdy pojawi-ły się komputery osobiste, działy IT nie były zachwycone faktem, że, użytkownicy bizne-sowi mają swoje własne komputery. Do dziś nadal mainframe'y są dobre dla wszystkich, są w jednym konkretnym miejscu. Okaza-ło się jednak, że użytkownicy biznesowi po-trzebowali komputerów osobistych. Uwa-żam, że z Mashupami jest tak samo. Mashupy to technologia, która pozwala użytkowniko-wi biznesowemu zebrać w całość wszystkie źródła danych, samodzielnie dokonując po-trzebnych integracji danych i procesów.

SDJ: Jakie pytania najczęściej zadają Se-renie programiści?KP: Często programiści pytają Co my mamy robić, kiedy użytkownicy biznesowi będą two-rzyć własne aplikacje? Pierwsze co dział IT może (i powinien) zrobić w tej chwili dla biz-nesu, to opakować usługi tradycyjnych apli-kacji do postaci webserwisów – im więcej in-formacji możemy dostarczyć do miejsca, w

którym jest ona potrzebna użytkownikom biznesowym, tym lepiej aplikacje wspoma-gają biznes i tym większy sukces osiąga biz-nes. Zatem, zamiast budować aplikację, któ-ra jest dla użytkownika końcowego użytecz-na w 80%, lepiej jest nie budować aplikacji, tylko zbudować zespół webserwisów i niech użytkownicy biznesowi sami wykorzystają je poprzez Mashupy. To im rzeczywiście bar-dziej się przyda. Myślę, że niektórzy progra-miści mogą stwierdzić, że będą mieli całkiem dobrą zabawę jako programiści, jeśli będą pracować dla biznesu. Jeśli będą pracować w kadrach, w produkcji, w sprzedaży, jako pro-gramiści biznesowi dla tych wydziałów, bo wtedy będą oni posiadali dokładną wiedzę o tym, jak ten biznes działa; będą współpra-cownikami, czy doradcami ludzi, którzy pro-wadzą taki biznes. I będziemy mieli rzeczy-wisty wgląd w to, jak wygląda faktyczna wi-zja tego biznesu, jaka jest jego strategia, ja-ka jest polityka, jakie cele i ambicje kierow-nictwa, które prowadzi ten biznes. I będą oni mogli wyrazić te aspiracje poprzez technolo-gię i wdrażać ją w biznesie, mając szczegóło-wą wiedzę o tym biznesie. I myślę, że jest to podstawowa zmiana reguł gry, gdzie nie ma już ustawicznego tłumaczenia tego, co biz-nes chciałby wyartykułować, na to, jak IT ro-zumie i rozwiązuje problem. Dochodzimy te-raz do miejsca, gdzie biznes faktycznie two-rzy rozwiązanie, bez potrzeby tłumaczenia. A dzięki temu – w miarę możliwości – żadne szczegóły nie umkną, bo nie będzie żadnej potrzeby tłumaczenia. I myślę, że dla wielu programistów będzie to bardzo pouczające, a jednocześnie promujące, bo będą się czuli częścią dostarczonego rozwiązania. Będą tak samo dumni z tego, co robią w ramach or-ganizacji, jak wtedy, gdy pracowali jako pro-gramiści w IT. A skutkiem ubocznym takiego przesunięcia będzie chociażby to, że coraz mniej prac nad oprogramowaniem będzie przenoszonych za granicę. Bo znacznie trud-niej jest mieć eksperta biznesowego w Szan-ghaju , czy Bombaju. Łatwiej mieć kogoś ta-kiego tu na miejscu, w centrali w Warszawie, bo siedzi w biurze obok szefa, korytarz dalej od kierownictwa, które jest odpowiedzialne za biznes i kanały komunikacyjne, a linie ko-munikacji są krótkie i rozwiązania są bardziej odpowiadające jako rezultaty. Może to ozna-czać, że niektóre z tych miejsc pracy, które straciliśmy na rzecz Indii, czy Chin, wrócą te-raz jako rezultat tych działań.

SDJ: Czy Serena Software posiada specjal-ny program dla programistów?KP: Nie, to nie jest coś, czym Serena mogłaby się zajmować. Istotą biznesu Sereny jest za-rządzanie cyklem życia aplikacji, zatem pro-gramiści często patrzą na nasze technologie jako w pewnym sensie ograniczające ich kre-atywność, bo my jesteśmy głównie zainte-

Page 76: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

Wywiad

10/200876

Wywiad

www.sdjournal.org 77

resowani rzeczami takimi, jak Software Con-figuration Management, takimi jak kontrola wersji, strzeżenie dostępu do artefaktów, za-rządzaniem buildami itp. Ale myślę że każdy zawodowy programista dzisiaj zdaje sobie sprawę, że jeśli wprowadzi niedobrą zmia-nę w oprogramowaniu, przeniesie się to na niebagatelny efekt dla biznesu, więc posia-danie na miejscu technologii, która pozwoli przewidzieć szkodliwe zmiany i im przeciw-działać, jest jak najbardziej w ich długofalo-wym interesie.

W większości części składowych naszych rozwiązań staramy się zapewnić, aby nasza technologia nie dokładała programistom dodatkowej pracy. Ukrywamy zatem naszą technologię pod kurtyną IDE i jeśli chodzi o programistów, muszą oni tylko wykonywać check-out i check-in, a my wykonujemy cała resztę od tego miejsca. Jeśli jednak pracow-nik pełni rolę Release/Build Manager-a, to na-sza technologia jest dla niego ważna. Bo po-zwala dostrzec cały obraz pracy nad opro-gramowaniem, cokolwiek by się tam działo, nawet jeśli niektóre części dzieją się w Szan-ghaju, czy Bombaju, czy też oprogramowa-nie tworzy się w Kijowie czy Warszawie. Trze-ba być pewnym, że się widzi wszystkie jed-nostki konfiguracji, pewnym że wszystkie rzeczy są oprogramowane spójnie, że są spójnie skompilowane, spójnie przetestowa-ne, spójnie wdrożone. A jeśli cokolwiek pój-dzie naprawdę źle to wszystko będzie mo-gło być też spójnie wycofane. I jeśli ktoś jest Release Managerem, to wszystko to jest dla niego rzeczywiście ważne – dlatego dostar-czamy mu takie narzędzia, a programista w ogóle nie musi widzieć tych narzędzi.

SDJ: Kogo zatrudnia Serena Software?KP: Jesteśmy zupełnie jak każda inna firma i mamy centra programistyczne na całym świecie. Mamy więc centra w Stanach Zjed-noczonych: w Bellevue w Washington, w Hil-lsboro w Oregonie, w Redwood City w pól-nocnej Kaliforni, w Woodland Hills w połu-dniowej Kaliforni, w Colorado Springs w Co-lorado. Mamy też centrum programistyczne w Wielkiej Brytanii w Saint Albans (pierwot-ne centrum w Europie) mamy kilka zespołów programistów w Indiach w różnych miej-scach, mamy też mały zespół w Kijowie. Kra-ków? Jeszcze o tym nie myśleliśmy. Znaczącą większość z tych lokalizacji posiadamy dlate-go, że albo mamy w tych miejscach oddziały przejętych firm, albo mamy tam partnerów posiadających zespoły programistów.

SDJ: Jeśli zatem inżynier oprogramowa-nia z Polski chciałby pracować w Serena Software, powinien wybrać się na Wyspy Brytyjskie?KP: Około 1/2 naszych inżynierów prak-tycznie pracuje ze swojego domu. Jesteśmy

globalną korporacją, gdzie każdy ma lapto-pa, wielu ludzi ma swoje biurka w biurze, ale pracuje trzy dni w tygodniu w biurze, a dwa w domu. Ci pracownicy, którzy miesz-kają daleko od biura pracują cały czas z do-mu. Mamy bardzo wyrafinowaną infrastruk-turę i oczywiście lubimy mówić, że pijemy własnego szampana, co oznacza po prostu, że nasi programiści używają naszych wła-snych narzędzi do tworzenia oprogramo-wania. Zatem na przykład nasze flagowe narzędzie do Software Configuration Ma-nagement nazywa się Dimensions i jedną z najmocniejszych zalet Dimensions jest to, że ma bardzo, bardzo wysoką wydajność w sieci WAN. Więc jeśli zrobi się check-out ka-wałku kodu w Indii albo w Saint Albans, czy w Redwood City, zajmuje to dosłownie mo-ment, nawet jeśli serwer jest w Hillsboro w Oregonie. Serwer jest zatem w jednym mie-ście a programiści na całym świecie. Jest to bardzo wydajny check-out. Jednym z naj-większych problemów związanych z posia-daniem programistów rozrzuconych po ca-łym świecie jest to, że jak przypisze się za-danie do programisty, może on nie być na nogach akurat w tym samym momencie, co jego menedżer. Mamy więc nasze wspania-łe narzędzie, oczywiście stworzone z pomo-cą Serena Business Mashups, które pozwa-la nam przypisywać zadania współpracow-nikom, żeby pracowali i aktualizowali stan prac, a my będziemy widzieli status tego, nad czym pracują nie potrzebując nawet z nimi rozmawiać, ani ich widzieć osobiście. Mamy oczywiście tygodniowe telekonfe-rencje z członkami zespołów i tak dalej, ale zawsze możemy widzieć, w jakim stanie są sprawy. A także dla biura zarządu projektu (Project Management Office) – bo biuro za-rządu projektu też jest rozrzucone po świe-cie – mamy bardzo dobre narzędzie, zwa-ne Mariner. Pozwala ono widzieć nad czym każdy pracuje, widzieć kiedy pracownicy kończą przydzielone zadania, by następnie przypisać ich do przyszłych projektów. Na-rzędzie Mariner wykorzystujemy także do zarządzania pomysłami na projekty, które mogą pochodzić od naszych klientów, od zarządu lub kierowników projektów.

Nasze oprogramowanie także poddajemy rygorom cyklu życia aplikacji, w ramach prac projektowych. I do tego sami używamy tych samych narzędzi, które chcemy, by używa-li nasi klienci. Sami stosujemy przy tym naj-lepsze praktyki w zarządzaniu projektami i cyklem życia oprogramowania. W tym kie-runku kształcimy i przygotowujemy naszych pracowników.

Zdradzę jeszcze jedno – bo chyba niewie-lu o tym wie – jeśli stworzymy nowsze wersje naszych produktów to najpierw wpuszcza-my beta-wersje do naszych własnych środo-wisk produkcyjnych.

W ten sposób mamy naszego pierwsze-go klienta następnego release'u naszego produktu – Serenę. Bo jeśli będą z tym pro-blemy, chcemy się upewnić, że znajdziemy je zanim oddamy to do klienta. I jest to na-prawdę zachwycające, bo kiedy nasi klienci robią beta-testy naszego kodu, my już uży-wamy tej wersji codziennie jako wersji pro-dukcyjnej. I oczywiście oznacza to, że pro-gramiści pracujący w Serenie wiedzą, że je-śli zrobią naprawdę poważny błąd, to pierw-si na tym ucierpią.

SDJ: Jaką rolę widzi Pan dla partnerów i dlaczego warto zostać partnerem Se-reny?KP: To proste: nie możemy być jednocze-śnie wszędzie! Jesteśmy co prawda firmą globalną z biurami rozrzuconymi po całym świecie, ale to dopiero partnerzy wnoszą dodatkową wartość w postaci znajomo-ści lokalnych uwarunkowań rynkowych, kulturowych, językowych, prawnych itd. A ze strategicznego punktu widzenia jest to dla nas bezcenne. Wspomniałem wcze-śniej, że naszą strategią jest strategia na-szych klientów. Zdobycie zatem partne-ra, który już jest u klientów z innymi swo-imi rozwiązaniami, szczególnie w sytuacji, gdy nasze rozwiązania doskonale uzupeł-niają ofertę naszego partnera – to jest dla nas sytuacja idealna. Nasz partner już zna strategie potencjalnego klienta, wie ja-kich platform i technologii używa do bu-dowania aplikacji biznesowych – może za-tem szybko i trafnie zaoferować rozwiąza-nie adresując poprawnie określone potrze-by klienta. Świetnym przykładem jest nasz polski partner – firma CompFort Meridian. Specjalizując się w dostarczaniu rozwiązań do zarządzania IT, dzięki naszym rozwią-zaniom jest w stanie dostarczyć klientowi kompleksową usługę analizy, zaprojekto-wania i wdrożenia zintegrowanego syste-mu zarządzania IT, właśnie z uwzględnie-niem projektowego zarządzania cyklem życia oprogramowania. Wspomniałem tak-że wcześniej o konieczności łatwości inte-gracji oferty różnych producentów opro-gramowania w jedno, spójne rozwiązanie. W takiej sytuacji to rolą partnera jest za-pewnienie skutecznej i działającej integra-cji, co niewątpliwie jest atrakcyjne z punk-tu widzenia klienta, bo nie musi już sam użerać się z wieloma dostawcami, by za-pewnić współdziałanie różnych techno-logii. A partner – oprócz oczywistych wy-miernych korzyści – zyskuje dostęp do na-szej świetnej technologii i sam może wes-przeć swoje wewnętrzne procesy naszymi rozwiązaniami. A najlepszą referencją jest dostawca (w tym wypadku partner), który sam efektywnie używa rozwiązań oferowa-nych swoim klientom.

Page 77: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

Wywiad

10/200876

Wywiad

www.sdjournal.org 77

SDJ: W jaki sposób postrzega Pan rolę cza-sopism takich jak Software Developer's Journal?KP: Myślę, że czasopisma są naprawdę waż-ne dla zespołów programistycznych Sere-ny. Wziąwszy pod uwagę dostawców opro-gramowania, którzy sami tworzą dostarcza-ne aplikacje, często występują uogólnione problemy, istnieją też uogólnione rozwią-zania dla uogólnionych problemów. Więk-szość naszych klientów tworzy specyficzne rozwiązania dla specyficznych problemów. Są to zatem zupełnie inne zestawy umiejęt-ności. I będąc programistą, jest się zwykle za-interesowanym tym, jakie są najnowsze tren-dy w przemyśle, jakie są nowe pułapki w no-wych IDE, czy nowych bazach danych. Dla-tego czasopisma są naprawdę istotne dla nas jako twórcy i dostawcy oprogramowa-nia. Pomagają nam wejrzeć w to, co się dzie-je na świecie.

Robimy w Serenie co możliwe, żeby pro-gramiści byli otwarci na nowe trendy. Przy-kładowo, całkiem dużo programistów Sere-ny bierze udział w naszych dorocznych kon-ferencjach klientów i użytkowników. Jest to dla nas niepowtarzalna okazja, by spotykać się z klientami i dowiadywać się, co robią. Mamy do tego naszą specjalną strefę odpo-wiedzi, gdzie gromadzą się wszyscy kumacze (geeks) Sereny, co to chodzą w białych fartu-chach i oczekują by podszedł klient i powie-dział: jesteś kumaczem z Sereny, mam dla cie-bie pytanie....

Chcemy, aby nasi inżynierowie spotyka-li się bezpośrednio z klientem. Mamy spo-tkania doradztwa produktów, gdzie nasi naj-więksi klienci, którzy używają naszych pro-duktów, spotykają się z zespołami produkto-wymi i w najdrobniejszych szczegółach wy-kładają rzeczy, które chcieliby mieć w przy-szłych wersjach produktu. Mamy znakomitą społeczność użytkowników – Serana Com-munity – mającą też swój portal communi-ty.serena.com, gdzie klienci i ludzie z Sere-ny przesiadują razem. Nasi zawodowi kon-sultanci i inżynierowie wsparcia oraz pro-gramiści czatują z klientami, a klienci mówią: hej, dlaczego to tak ma działać?, a ludzie Se-reny mówią: a, no bo..., a czy wiedzieliście, że... i dzielą się wszystkimi informacjami. I tak sta-raliśmy się uczynić ścianę między klientem a inżynierem możliwie najcieńszą, żeby inży-nier oprogramowania mógł się dowiedzieć dokładnie, jak klient używa produktu i coś z tego wynieść. Bo – niestety – łatwo jest do-stawcy oprogramowania stać się wieżą z ko-ści słoniowej, obwarowanym miastem, z któ-rego nic na zewnątrz się nie dostrzega i do którego żadną miarą nie można się dobić. I mocno się staramy różnymi sposobami, by nasi programiści wiedzieli, co się dzieje u klienta, a także by naszych klientów włączać w tworzenie naszych produktów.

Page 78: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

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]

Page 79: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

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

Page 80: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

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.

,-

Page 81: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

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

Page 82: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5

10/200882

W NASTĘPNYM NUMERZE SOFTWARE DEVELOPER’S JOURNAL 11/2008 167

ECOMMERCESklep internetowy w PHP i SQLiteTextpattern – Wydajny, elastyczny i przyjazny CMS

PROGRAMOWANIE JAVAObliczenia numeryczne w programach komputerowych

PROGRAMOWANIE PHPZaawansowana obróbka grafiki w PHP

Porównanie opensource-owych platform blogowych opartych o PHP i ba-zy danych

TESTOWANIE OPROGRAMOWANIAPlugin – wielokrotne wykorzystanie sprawdzonych narzędzi

NOWE ARTYKUŁY W DZIAŁACHBiblioteka miesiąca

Systemy operacyjne

I WIELE INNYCH ARTYKUŁÓW, KTÓRYCH NIE MOŻESZ PRZEOCZYĆ!

W sprzedaży od 18 października Redakcja zastrzega sobie możliwość zmiany zawartości pisma.

Page 83: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5
Page 84: SDJ_10_2008_PL_Joomla Migracja z 1.0 Do 1.5