Wydział Informatyki i Zarządzaniakierunek studiów: Informatykaspecjalność: Systemy Informacyjne

Praca dyplomowa - magisterska

Web frameworks do budowy aplikacjizgodnych z J2EE

Jacek Panachida

słowa kluczowe:Spring MVC

JavaServer Facesinternetowe szkielety programistyczne

krótkie streszczenie:Praca stanowi analizę porównawczą najpopularniejszych internetowychszkieletów programistycznych dostępnych dla platformy Java. Celempracy jest przedstawienie nowoczesnego środowiska pracy dostosowa-nego do wytwarzania aplikacji internetowych oraz umożliwienie doko-nania wyboru odnośnie używanej ramy projektowej.

Promotor: dr Dariusz Król............................................ ...................... .......................

imię i nazwisko ocena podpis

Wrocław 2007

Spis treści

Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1. Wstęp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1. Ewolucja szkieletów programistycznych . . . . . . . . . . . . . . . . . . . . . . . 61.1.1. Historia i rozwój . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.1.2. Wzorce projektowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1.3. Rozwiązania alternatywne . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2. Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2.1. Model 1 – strona JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2.2. Model 2 – centralny kontroler . . . . . . . . . . . . . . . . . . . . . . . . 141.2.3. Model komponentowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.3. Zadania szkieletów programistycznych . . . . . . . . . . . . . . . . . . . . . . . . 19

2. Nowoczesne środowisko pracy programisty . . . . . . . . . . . . . . . . . . . . . 22

2.1. Narzędzia integrujące . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.1. Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.2. Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.3. Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.4. Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.1.5. Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2. Narzędzia testujące . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.2.1. Spring Mock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.2.2. EasyMock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.2.3. JUnit 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2.4. Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3. Przegląd internetowych szkieletów programistycznych . . . . . . . . . . . . . . 43

3.1. Struts 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.1.1. Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.1.2. Znaczniki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.1.3. Interceptory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.1.4. Implementacja wzorca MVC . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2. Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.2.1. Obiekt nadzorujący . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.2. Znaczniki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.2.3. Zasada konwencji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.3. Tapestry 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.3.1. Zasady . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.3.2. Moduły . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.4.1. Specyfikacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.4.2. Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.4.3. Składowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.4.4. Implementacja wzorca MVC . . . . . . . . . . . . . . . . . . . . . . . . . 54

4. Porównanie Spring MVC oraz JavaServer Faces . . . . . . . . . . . . . . . . . . 55

1

4.1. Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.1.1. Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.1.2. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.1.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2. Model programistyczny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.1. Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2.2. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.3. Cykl życia żądania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.3.1. Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.3.2. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.3.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.4. Walidacja i konwersja typów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.4.1. Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.4.2. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.4.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.5. Internacjonalizacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.5.1. Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.5.2. JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.5.3. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5. Aplikacja Peclinic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.1. Opis aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.1.1. Wykorzystane technologie . . . . . . . . . . . . . . . . . . . . . . . . . . 705.1.2. Encje bazy danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2. Moduły aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.2.1. Petclinic-data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.2.2. Petclinic-core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.2.3. Petclinic-web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.3. Zaimplementowana funkcjonalność . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6. Eksperymenty z wykorzystaniem aplikacji Petclinic . . . . . . . . . . . . . . . 76

6.1. Przebieg badania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.1.1. Fazy implementacji aplikacji Petclinic . . . . . . . . . . . . . . . . . . . . 766.1.2. Badanie wydajności . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.1.3. Pomiar metryk kodu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.1.4. Badanie łatwości wprowadzania zmian . . . . . . . . . . . . . . . . . . . 806.1.5. Badanie dostępności komponentów Triniad . . . . . . . . . . . . . . . . . 81

6.2. Analiza wyników . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.2.1. Wydajność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.2.2. Metryki kodu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.2.3. Dostępność komponentów Trinidad . . . . . . . . . . . . . . . . . . . . . 886.2.4. Łatwość wprowadzania zmian . . . . . . . . . . . . . . . . . . . . . . . . 90

7. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

2

StreszczeniePraca stanowi analizę porównawczą najpopularniejszych internetowych szkieletówprogramistycznych o otwartym kodzie źródłowym, dostępnych dla platformy Java.Celem pracy jest przedstawienie nowoczesnego środowiska pracy dostosowanego dowytwarzania aplikacji internetowych oraz umożliwienie dokonania wyboru odnośnieużywanej ramy projektowej. Analizie zostały poddane frameworki Spring MVC orazJavaServer Faces. Uzyskane wyniki bazują na analizie teoretycznej udostępnionychprzez szkielety rozwiązań oraz eksperymentach dokonanych na zaimplementowanejaplikacji służącej do zarządzania kliniką weterynaryjną. Praca zaleca stosowanieSpring MVC w tradycyjnych aplikacjach do zarządzania danymi.

AbstractA comaparative analysis of chosen open source web frameworks for Java platformis done. The aim of the thesis is to present modern software enviroment designedfor implementing web applications and also to enable making final choice aboutweb framework, which is to be used in developing web application. The subjects ofthe analysis are Spring MVC and JavaServer Faces. The solution of the problemrelies upon theoretical analysis of available framework features and upon underwentexperiments on implemented application designed to support managing pet clinic.The thesis indicates Spring MVC application in traditional CRUD web systems.

3

Wprowadzenie

Jednym z najpopularniejszych zastosowań języka Java jest tworzenie aplikacji interne-towych. Początkowo wystarczyły rozwiązania ograniczające się jedynie do zastosowaniaserwletów1 w połączeniu ze stronami JavaServer Pages. Szybko okazało się jednak żewzrastające potrzeby rynku wymagają zastosowania bardziej kompleksowych rozwiązań,pozwalających na odciążeniu programisty w wielu aspektach związanych z tworzeniemaplikacji internetowych.Odpowiedzią na rosnące potrzeby rynku oraz chęci uproszczenia procesu wytwarza-

nia aplikacji internetowych stało się stworzenie wielu tzw. ram projektowych (ang. webframeworks). Głównym zadaniem stawianym ramom projektowym jest pomoc programi-ście w tworzeniu, rozwoju i testowaniu powstającej aplikacji. Aktualnie istnieje ponad 40szkieletów programistycznych z otwartym kodem dostępnych dla platformy Java,2 nowewciąż powstają.Wybór spośród wielu dostępnych ram projektowych nie jest z pewnością prosty. Pod-

czas przeglądu dostępnych opracowań nie napotkałem takiego, które omawia w przedsta-wionym w pracy zakresie wybrane przeze mnie biblioteki. Niniejsza praca ma za zadanieułatwić dokonanie właściwego wyboru poprzez przedstawienie oraz porównanie wybranychszkieletów programistycznych.Programista stojący przed wyborem nowego narzędzia pracy zwraca uwagę na wie-

le aspektów z nim związanych. Zbiera informacje między innymi na temat dojrzałości,dostępności wsparcia społeczności czy popularności rozwiązania. Niniejsza praca stanowiwsparcie w ostatnim stadium podejmowania decyzji, w momencie w którym programistastoi przed wyborem dwóch spośród nich Spring MVC bądź JavaServer Faces. Poprzezanalizę teoretyczną wsparcia oferowanego przez wspomniane frameworki autor bada ichprzydatność podczas tworzenia aplikacji typu CRUD (ang. create, read, update and dele-te).W związku z mnogością dostępnych opcji dokonano zawężenia liczby badanych projek-

tów do aplikacji o otwartym kodzie źródłowym, których licencja jest zaaprobowana przezorganizację Open Source Initiative3. Na ostateczny kształt listy miała również wpływpopularność wybranej ramy projektowej, jej dojrzałość oraz dostępność mechanizmówumożliwiających integrację ze Spring Framework4.Porównanie wybranych ram projektowych zostało dokonane z wykorzystaniem przy-

kładowej aplikacji internetowej zaimplementowanej specjalnie na potrzeby niniejszej pra-cy magisterskiej. Na jej podstawie został zbadany praktyczny aspekt użycia wybranegoszkieletu programistycznego.Praca została podzielona na dwie części, poprzedzone wprowadzeniem. Pierwsza z czę-

1 Komponenty działające po stronie serwera. Specyfikacja dostępna na stronie http://java.sun.com/products/servlet.

2 Dane według serwisu Java-Source.net (marzec 2007) dostępnego pod adresem http://www.java-source.net.

3 Organizacja zajmująca się promocją oprogramowania open source.4 Szkielet wytwarzania aplikacji w języku Java dla platformy J2EE.

4

ści opisuje teoretyczną stronę związaną z zastosowaniem i działaniem poszczególnych ramprojektowych. Druga omawia przebieg oraz wyniki badań przeprowadzonych z zastosowa-niem przykładowej aplikacji.Rozdział wprowadzający ma za zadanie zapoznanie czytelnika z historią rozwoju szkie-

letów programistycznych, wyjaśnia podstawowe pojęcia wykorzystywane w dalszej czę-ści pracy. Opisuje stosowane architektury aplikacji internetowych oraz funkcje oferowaneprzez ramy projektowe.Pierwszy rozdział części teoretycznej został poświęcony zagadnieniom związanym z no-

woczesnym środowiskiem pracy programisty aplikacji internetowych z podziałem na na-rzędzia służące do wytwarzania oraz testowania aplikacji. W kolejnym został dokonanyprzegląd czterech popularnych szkieletów programistycznych. W następnym rozdziale po-równującym wybrane ramy projektowe, Spring MVC oraz JavaServer Faces, zwróconouwagę na ich architekturę, model programistyczny, cykl życia żądania bądź zdarzenia(w przypadku aplikacji opartej o JavaServer Faces), walidację wraz z konwersją typówwprowadzanych przez użytkownika danych. Ostatnia cześć dotyczy procesu związanegoz lokalizacją aplikacji.Część praktyczną rozpoczyna opis przykładowej aplikacji internetowej, jej modułów

oraz zaimplementowanej funkcjonalności. Następny rozdział składający sie z dwóch czę-ści przedstawia trzy fazy implementacji przykładowej aplikacji, sposób przeprowadzeniaeksperymentów oraz wyniki badań wraz ich analizą.Ostatnią część pracy stanowi podsumowanie badań dwóch wybranych szkieletów pro-

gramistycznych.Mam nadzieję, iż wysiłek włożony przeze mnie w realizację pracy, pozwoli osobą sto-

jącym przed dylematem wyboru właściwej dla nich ramy projektowej na podjęcie prawi-dłowej decyzji.

5

1. Wstęp

Niniejszy rozdział stanowi wprowadzenie do tematu szkieletów programistycznych do-stępnych dla platformy Java. Pierwsza część przedstawia ewolucję oraz rozwój ram pro-jektowych jak i samych aplikacji internetowych związanych nierozerwalnie z tworzeniemaplikacji internetowych od początków ich istnienia. Dodatkowo prezentuje alternatywnerozwiązania internetowe dostępne dla platformy Java. Następny rozdział stanowi prze-gląd i opis stosowanych architektur programistycznych, wraz z przedstawieniem jedenegoz fundamentalnych wzorców projektowych związanych z internetowymi szkieletami pro-gramistycznymi, wzorca Model-Widok-Kontroler. W ostatniej z części opisano podstawo-we funkcjonalności, realizowane przez twórców ram projektowych.

1.1. Ewolucja szkieletów programistycznych

Wraz z rozwojem technologi World Wide Web okazało się iż statycznie serwowane stro-ny nie spełniają oczekiwań użytkowników. W odpowiedzi powstawały różnorodne techno-logie umożliwiające zwiększenie dynamizmu prezentowanej treści. Pierwsze rozwiązaniawykorzystywały interfejs Common Gateway Interface (CGI), w połączeniu z popularny-mi ówcześnie językami programowania, takimi jak C czy Perl. Niewystarczające interfejsyprogramistyczne (API) dostarczane przez wspomniane opcje czy zbyt mała wydajnośćdziałających w ten sposób aplikacji doprowadziły do powstawania nowych, ulepszonychrozwiązań. Równocześnie rosnące potrzeby dotyczące aplikacji, wykorzystującej sieć In-ternet do swojego działania spowodowała, iż obecnie istnieje wiele gotowych rozwiązańumożliwiających serwowanie dynamicznej treści. Język Java jest tylko jednym z alterna-tyw pośród stron tworzonych w technologiach takich jak ASP.NET [58], Adobe Flash [1]czy PHP [44].

1.1.1. Historia i rozwój

Początki istnienia ram projektowych sięgają początków pierwszych aplikacji inter-netowych [42]. Podstawą działania wszystkich aplikacji napisanych przy wykorzystaniuplatformy Java w środowisku webowym są serwlety – niewielkie programy działające postronie serwera, nadające dynamiczny charakter działającej aplikacji.Idea serwletów zrodziła się w 1995 roku, czyli rok przed wydaniem pierwszej wersji

języka Java [12]. Pomysłodawcami i pierwszymi realizatorami technologi serwletów byliJames Gosling oraz Pavani Diwanji. Pierwsza specyfikacja Java Servlet API nosząca wersję1.0 powstała w maju 1997 roku. Dwa lata później, wydano specyfikację JavaServer Pagesmająca również zastosowanie przy tworzeniu aplikacji internetowych. Różnica pomiędzyserwletami a stronami JSP polega na tym, iż w przypadku serwletów programista skupiasię na kodzie języka Java generując odpowiedź w postaci tworzonych, często konkatenowa-nych napisów, w przypadku stron wykonanych w technologi JavaServer Pages użytkowniktworzy odpowiedź, najczęściej stronę HTML, w której używa wstawek języka Java. Osta-

6

tecznie strony JSP są kompilowane do serwletów, zatem jedyna różnica dotyczy sposobuich tworzenia.Szybko okazało się iż dla wielu programistów, ustandaryzowane rozwiązania są niewy-

starczające. Jednym z powodów był zbyt mały poziom abstrakcji w stosunku do warstwyprotokołu HTTP. Powstała specyfikacja wprowadziła pojęcie żądania (ang. request), odpo-wiedzi (ang. response) oraz obiektu zwanego serwletem (ang. servlet), odpowiedzialnego zainterakcję z użytkownikiem. Dodatkowo wprowadzono do bezstanowego protokołu jakimjest HTTP pojęcie stanowości za pomocą obiektu sesji (ang. session). Możliwe się stałowypisanie odpowiedzi użytkownika wprost z poziomu serwletu wykorzystując odpowied-nie metody, fragment przykładowego kodu został przedstawiony na listingu 1.1. Tworzyon odpowiedź o charakterze powitalnym na stronie zatytułowanej „Prosty serwlet”. Dlaprzejrzystości kodu zrezygnowano z wymaganej, w poprawnej aplikacji SGML, deklaracjiDOCTYPE.�

1 public class SimpleServlet extends HttpServlet {2 public void doGet(HttpServletRequest req, HttpServletResponse res)3 throws ServletException, IOException {4

5 // Ustawiamy typ zwracanego dokumentu (strona HTML)6 res.setContentType("text/html");7

8 // Pobieramy strumien do zapisu9 PrintWriter out = res.getWriter();10

11 // Zapisujemy odpowiedz na wyjscie12 out.println("<html>");13 out.println("<head><title> Prosty serwlet </title></head>");14 out.println("<body>");15 out.println("<h1> Witaj </h1>");16 out.println("</body>");17 out.println("</html>");18

19 // Zamykamy strumien, zwracamy odpowiedz20 out.close();21 }22 }� �

Listing 1.1: Serwlet wysyłający odpowiedź do klienta

Zastosowanie serwletów po stronie serwera umożliwia generowanie dynamicznej zawar-tości w zależności od odebranego żądania skierowanego przez przeglądarkę użytkownika.Zwyczajowo generowaną zawartością jest HTML, ale nie istnieją techniczne ograniczeniado zwracania dowolnej zawartości, takiej jak XML.Serwlety działają w środowisku określanym mianem kontenera serwletów. Kontener

serwletów stanowi element pośredniczący pomiędzy serwletem a serwerem internetowym.Zarządza cyklem życia serwletów. Mapuje adresy URL żądań do poszczególnych serwletóww celu ich obsłużenia. Ostatnią z ważniejszych funkcji kontenera jest dbałość o bezpie-czeństwo aplikacji internetowej poprzez autoryzację żądań użytkownika.Implementacja serwletu wymaga rozszerzenia abstrakcyjnej klasy HttpServlet z pa-

kietu javax.servlet.http oraz nadpisania co najmniej jednej z jej metod w zależności

7

od używanych metod. Prezentowany przykład nadpisuje w klasie SimpleServlet metodęo nazwie doGet, zatem serwlet wspiera żądania wysłane z użyciem metody HTTP GET.Listing 1.1 prezentuje działanie serwletu, generującego odpowiedź w postaci kodu

HTML. Możemy wyróżnić cztery etapy odpowiedzi:1. Ustalenie typu zwracanego dokumentu (typ mediów), w naszym przypadku text/html,który jest używany przy zwracaniu dokumentu HTML.

2. Utworzenia strumienia do którego nastąpi zapis zwracanego wyniku.3. Zapis odpowiedzi do strumienia.4. Zamknięcie strumienia, czyli wysłanie odpowiedzi o ustalonym typie mediów do klien-ta.Zamieszczony przykład dobrze obrazuje następujące cechy serwletów w kontekście

użycia ich do bezpośredniego wygenerowania odpowiedzi:— kod serwletu to kod języka Java pomimo że formatem wyjściowym jest HTML,— generacja kodu HTML została rozrzucona po różnych miejscach w pliku, rezultat za-stosowania obiektu PrintWriter,

— sposób formatowania charakterystyczny dla kodu Javy sprawia trudności w zoriento-waniu się w strukturze dokumentu i wyklucza zastosowanie edytorów szablonów,

— następuje wymieszanie kodu odpowiedzialnego za logikę aplikacji z kodem odpowie-dzialnym za stworzenie wyglądu strony.

W odpowiedzi na zaprezentowane powyżej braki serwletów, opracowano specyfikację Ja-vaServer Pages, która stanowi niejako odwrócenie zasady działania serwletów. Zamiastw środowisku dynamicznym (kodzie Javy) tworzyć statyczną zawartość znaczników HTML,postanowiono zawartość dynamiczną zanurzyć w statycznym języku np. HTML. Listing1.2 prezentuje różne możliwości zanurzenia kodu Javy w stronie JSP. Linia pierwsza przed-stawia definicję zmiennej var. W linii drugiej umieszczono przykład wstawki języka Java(ang. scriptlet), która zostanie wykonana w momencie obsługi żądania. Ostatnia liniaprezentuje wyrażenie, które zostanie odzwierciedlone bezpośrednio w generowanym kodziestrony (brak znaku średnika na końcu wyrażenia).�

1 <%! int var = 1; %>2 <% int var1 = 1; int var = 2; int var3 = var1 + var2 %>3 <%= "numer wizyty " + 1 %>� �

Listing 1.2: Zanurzanie elementów języka Java w stronie JSP

Pomimo wprowadzenia technologi JavaServer Pages generowanie widoku wciąż po-siadało wadę związaną z przemieszaniem logiki biznesowej z kodem odpowiedzialnym zaprezentację danych. Ponadto zawieranie kodu języka programowania, takiego jak np. Java,w znacznikach powodowało, iż twórcy szablonów musieli być obeznani z jego stosowaniem,co często okazywało się niepraktyczne.Wyjściem z sytuacji stało się opracowanie, w wersji JSP 1.1, biblioteki tzw. custom

tags, których zadaniem było wydzielenie kodu aplikacji z warstwy widoku i zamknięcie jejw specjalne znaczniki. Najpowszechniej używaną biblioteką znaczników jest JavaServerPages Standard Tag Library (JSTL), która zawiera w sobie wsparcie między innymi dla:— wyrażeń warunkowych,— iteracji,— internalizacji i lokalizacji,— języka zapytań SQL,— języka znaczników XML,

8

— walidacji.Biblioteka JSTL stanowi część platformy J2EE i została opracowana pod nadzorem JavaCommunity Process (JCP). Aktualna wersja wydana w maju 2006 roku nosi numer 1.2.Obecna specyfikacja JEE w wersji 5.0 nie posiada w swoich zasobach opisu ustan-

daryzowanej ramy projektowej, służącej do budowy aplikacji biznesowych. Jednym zesposobów pisania aplikacji internetowych z użyciem prostej abstrakcji jest bezpośredniewykorzystanie serwletów i stron JSP w połączeniu z biblioteką znaczników. Takie podej-ście ma wiele zalet, jeżeli budujemy prostą aplikację webową. Podczas pracy z większymisystemami wydaje się konieczne skorzystanie z jednego ze szkieletów programistycznych.Opisywane w pracy szkielety programistyczne należą do najliczniejszej grupy tzw.

szkieletów specjalizowanych, gdyż skupiają w sobie jedynie wsparcie przy tworzeniu war-stwy kodu widoku, pozostawiając pozostałe warstwy tradycyjnej aplikacji trójwarstwowejdo dyspozycji programisty. Do frameworków próbujących scalić w sobie wiele warstwnależy np. biblioteka Rife [47] czy Roma [52].Na osobną uwagę zasługuje framework Seam, opracowany przez firmę JBoss, który

nazywany jest „zaginionym Gralem platformy JEE”. Łączy w sobie biblioteki JavaServerFaces (JSF), Facelets, Enterprise Java Beans (EJB3), Java Persistence API (JPA). Zewzględu na jego odrębność w stosunku do najpopularniejszych szkieletów specjalizowa-nych, nie został opisany w pracy.

1.1.2. Wzorce projektowe

Trudność w zarządzaniu kodu nieczytelnego, korzystającego z niejasnych rozwiązańarchitektonicznych oraz chęć wprowadzenia uniwersalnych, sprawdzonych w praktyce roz-wiązań, doprowadziła do stworzenia wzorców projektowych [19]. Wzorce projektowe majązastosowanie w wielu dziedzinach informatyki, takich jak programowanie aplikacji mobil-nych czy sieciowych. Poniższe dwa podrozdziały opisują jedynie najczęściej stosowanewzorce wykorzystywane przy projektowaniu szkieletów programistycznych dla platformyJava w technologi J2EE [40]. Wzorcowi Model-Widok-Kontroler, ze względu na jego szcze-gólne znaczenie, został poświęcony osobny rozdział 1.2.2.

Front Controller

Aplikacje działające w sieci Internet zmuszone są, ze swojej natury, obsługiwać wieluużytkowników jednocześnie. W jednym czasie do systemu napływają żądania klientówrealizujących swoje, często odmienne, potrzeby biznesowe. Wzorzec Front Controller [19,strony 145-157] stanowi element, który w sposób scentralizowany nadzoruje napływająceżądania do aplikacji.Istnieje również rozwiązanie alternatywne, które stosuje zdecentralizowany sposób ob-

sługi żądań. Przedstawione podejście wprowadza jednak do aplikacji zbędną duplikacjękodu związaną z tym, iż każdy widok systemu zmuszony jest do implementacji swojegomodułu odpowiedzialnego za przetwarzanie nadchodzących żądań. Ponadto opisywanerozwiązanie komplikuje kwestię nawigacji, gdyż brak jest nadrzędnego elementu, któryzarządza poszczególnymi widokami i przełącza użytkownika między nimi. Ostatnią sprawąjest zmniejszona zarządzalność kodu powstałego w ten sposób spowodowana bezpośrednioduplikacją kodu.Zadaniem Front Controllera zaimplementowanego w postaci serwletu, może być mię-

dzy innymi zapewnienie wsparcia dla integracji usług systemowych, pomoc w pozyski-waniu treści czy zarządzanie samymi widokami i nawigacją między nimi. Zastosowanieelementu centralnego pozwala w elegancki sposób rozwiązać kwestię autoryzacji i uwie-

9

Rysunek 1.1: Diagram sekwencji dla Front Controllera w momencie odebrania żądania [19]

rzytelnienia w aplikacji – jest tylko jedno wejście do systemu. Wykorzystywana strategiapozwala na wielokrotne wykorzystanie widoków pełniących podobną funkcję. Kontrolęnad żądaniami umieszczoną w jednym miejscu systemu można łatwo wykorzystać do lo-gowania działalności użytkowników aplikacji i sprawdzania sposobu przemieszczania siępo stronie, co może być szczególne przydatne w sklepach internetowych badających za-chowanie swoich klientów.Front Controller stanowi pierwszy punkt styku żądania wysłanego przez użytkownika

z tworzoną aplikacją, w związku z tym wykorzystany jest do następujących zadań:— odebranie żądania,— autoryzacja i uwierzytelnienie,— delegacja zadań do innych usług systemowych,— wybór odpowiedniego widoku,— zarządzanie błędami aplikacji.Użycie scentralizowanego kontrolera pozwala na redukcję kodu Javy zawartego w stronachwidoku. Rysunek 1.1 przedstawia diagram sekwencji w momencie odebrania żądania odużytkownika systemu. W interakcji przedstawionej na rysunku biorą udział następującyuczestnicy:— Controller pierwszy punkt styku wysłanego żądania z systemem. Zarządza wyboremwidoku jaki zostanie przedstawiony użytkownikowi. Może skorzystać z pomocy innegouczestnika np. Helper w celu autoryzacji klienta.

— Dispatcher odpowiedzialny za zarządzanie widokami i nawigacją między nimi. Decy-duje o wyborze widoku jaki zostanie przedstawiony użytkownikowi. Może stanowićosobny element systemu, jak w opisywanym przypadku, bądź być zawarty w kontro-lerze. Używa obiektu RequestDispatcher w celu przekazania sterowania do widoku.

— Helper odpowiedzialny za pomoc kontrolerowi w jego działaniach. W zależności odsystemu jego działanie może być inne, najczęściej jest odpowiedzialny za zbieraniedanych potrzebnych do wygenerowania widoku.

10

Rysunek 1.2: Diagram sekwencji dla wzorca View Helper w momencie odebrania żądania [19]

— View reprezentuje wynik działania aplikacji, który otrzymuje klient. Może wykorzy-stywać uczestnika Helper w celu enkapsulacji związanej z wyświetlaniem danych.Katalog wzorców zawiera dziewięć różnych implementacji wzorca Front Controller.

Najpopularniejszy z nich nosi nazwę Servlet Front i bazuje na serwlecie.

View Helper

Zastosowanie wzorca View Helper ma miejsce podczas wyświetlania treści, która zmie-nia się w sposób dynamiczny. Częsta zmiana warstwy widoku, powodowana względamibiznesowymi, komplikuje się w momencie przemieszania jej z kodem Javy w postaci tzw.scripletów. Rezultatem jest zmniejszenie elastyczności systemu.Nadużycie kodu Javy w warstwie widoku negatywnie wpływa na zarządzalność syste-

mu. Pojawia się tendencja do kopiowania fragmentów kodu na stronach JSP, co prowadziw konsekwencji od zwiększonej liczby błędów. Wzorzec View Helper promuje separacjękodu odpowiedzialnego za logikę aplikacji od kodu związanego z widokiem.Przedstawiany wzorzec polega na oddelegowaniu kodu związanego z logiką biznesową

aplikacji do elementów pomocniczych, zaimplementowanych za pomocą komponentów Ja-vaBean bądź poprzez użycie specjalnych tagów tzw. custom tags. Wpływa to pozytywniena modularyzację aplikacji. Istnieje wiele sposobów implementacji opisywanej idei, najczę-ściej za element widoku służą strony JSP i jest to w większości przypadków preferowanerozwiązanie. Użycie pomocników ułatwia ponowne wykorzystanie kodu, gdy zajdzie takapotrzeba. Kod umieszczony w widokach można propagować wyłącznie poprzez kopiowaniejego fragmentów, co czyni system trudnym w utrzymaniu, gdyż nawet drobne modyfikacjewymagają zmian w wielu miejscach.Rysunek 1.2 przedstawia diagram sekwencji obsługiwanego żądania dla systemu wyko-

rzystującego wzorzec View Helper. W swojej zredukowanej postaci pozbawionej elementupomocnika żądanie odebrane od klienta może być skierowane bezpośrednio do widoku,ma to jedynie sens, gdy strona jest w głównej semistatyczna i nie zawiera w sobie dużokodu Javy. Diagram sekwencji przedstawia następujących uczestników podczas procesuprzetwarzania żądania odebranego od klienta:— View reprezentuje widok zwracany użytkownikowi systemu. Dynamiczne dane użytepodczas generowania strony pobierane są z modelu, pomocnicy są odpowiedzialni zaenkapsulację pobierania i przetwarzania danych.

11

— Helper jest odpowiedzialny za pomoc uczestnikowi View w wygenerowaniu widoku.Pomocnicy w zależności od rodzaju systemu mogą pełnić różna funkcję, najczęściejgromadzą dane na potrzeby widoku oraz odpowiedniu je przygotowują. Widok możekorzystać z wielu pomocników jednocześnie.

— ValueBean jest to inna nazwa dla pomocnika, którego rola ogranicza się do prze-chowywania stanu modelu na potrzeby widoku. W typowym zastosowaniu pełni rolęprzedstawioną na rysunku 1.2, zwraca żądaną wartość wykorzystując z ustalonej usłu-gi.

— BusinessService pełni role usługową w stosunku do aplikacji, jego celem jest wykony-wanie zadań powierzonych mu przez kontroler.

Istnieje sześć różnych implementacji opisywanego wzorca. Preferowaną ze względu nałatwość użycia i zarządzalność jest JavaBean Helper.

1.1.3. Rozwiązania alternatywne

Ważne miejsce w historii aplikacji internetowych miały również aplety. Jest to dosyćskrajny przykład aplikacji internetowej, który polega na tym iż program stworzony z wy-korzystaniem J2SE ściągany jest przez przeglądarkę na dysk komputera użytkownika, przyczym działa w kontekście strony internetowej go zawierającej. Pracując z apletem mamywrażenie pracy z aplikacją napisaną w technologi Swing, wprasowaną niejako w stronę in-ternetową. Aplety są technologicznie młodsze od serwletów – ich pierwsza wersja zostaładostarczona wraz z wersją 1.0 języka Java, w 1995 roku. Należy zaznaczyć iż aplety pomi-mo działania po stronie klienta są niezależne od platformy sprzętowej i programistycznejna której pracuje użytkownik, jest to bezpośrednia konsekwencja użycia platformy Java,którą główną cechą jest właśnie wieloplatformowość. Do działania apletu w przeglądar-ce konieczny jest specjalny program tzw. wtyczka. W celu zwiększenia bezpieczeństwaużytkowników aplikacji opartej o aplety, działa ona w specjalnym ograniczonym środowi-sku zwanym piaskownicą (ang. sandbox ), które między innymi nie pozwala na dostęp dozasobów lokalnych. Obecnie aplety po fazie fascynacji nimi przez użytkowników straciłyznacznie na popularności. Alternatywami dla nich są wcześniej opisane aplikacje wyko-rzystujące dynamiczny HTML lub aplikacje napisane z wykorzystaniem Adobe Flash.Kolejnym standardem platformy Java wykorzystywanym w środowisku internetowym

jest technologia Java Web Start. Jest to rama projektowa, której pierwsza wersja zostałaopublikowana w marcu 2001 roku, umożliwiająca uruchomienie aplikacji Javy bezpośred-nio z poziomu przeglądarki użytkownika. Wraz z wydaniem Java Runtime Environmentw wersji 1.4 została standardowo włączona do dystrybucji. W odróżnieniu od wspomnia-nych wcześniej apletów, pobrany w taki sposób program nie działa w środowisku przeglą-darki lecz poza nią. Ma to bezpośredni związek ze wspomnianą piaskownicą, która nie musibyć aż tak restrykcyjna jak w przypadku aplikacji opartych o aplety. Programy wykonanew technologi Java Web Start nie posiadają możliwości łatwej komunikacji z przeglądarką,po uruchomieniu, stanowią program który jest nie do odróżnienia ze standardową aplikacjąstworzoną z wykorzystaniem Swinga.W celu ułatwienia migracji dopuszczalne jest również uruchomianie aplikacji opartych

o aplety w opisywanej technologi. Przy prawidłowo skonfigurowanej przeglądarce, istniejemożliwość uruchomienia aplikacji bezpośrednio ze strony internetowej, po jej automatycz-nym ściągnięciu na dysk. Elementem odróżniającym aplikacje JWS od apletów jest wyko-rzystanie specjalnie opracowanego protokołu Java Network Launching Protocol (JNLP),opisującego sposób uruchomienia aplikacji w systemie użytkownika. W przypadku nieposiadania przez użytkownika wymaganej wersji biblioteki uruchomieniowej (JRE), na-

12

Rysunek 1.3: Różnorodność technologi platformy Java a środowisko działania

stępuje automatycznie jej ściągnięcie i instalacja. Program podczas uruchomienia rezydujew lokalnej pamięci podręcznej.Najpowszechniejszym zastosowaniem aplikacji wykorzystujących technologię JWS są

dema programów, które użytkownik może ściągnąć bezpośrednio na dysk, bez potrzebyinstalacji jak również część grubych klientów, gdy istnieje uzasadnienie dla zastosowaniaopisanej technologi.Wszystkie opisywane wcześniej rozwiązania działają w środowisku internetowym. Na

jednym z biegunów są aplikacje napisane za pomocą serwletów, na drugim samodzielneaplikacje oparte na technologi Java Web Start, które wykorzystują sieć jedynie do dystry-bucji. Aplikacje internetowe w powszechnej opinii należą do pierwszej ze wspomnianychgrup. Czynnikiem różnicującym w tym przypadku jest sposób wykorzystania przeglądar-ki do pracy z aplikacją. W przypadku systemów opartych o serwlety, przeglądarka jestelementem niezbędnym do pracy z aplikacją. Inaczej przedstawia się ma sprawa zwią-zana z apletami. Aplikacje oparte o aplety można uruchamiać w poziomu przeglądarkiale równie dobrze mogą zostać uruchomione z wykorzystaniem programu standardowodołączonego wraz z Java SE Development Kit (JDK).Kolejną z opisanych technologi jest Java Web Start, w swojej istocie bardzo podobna

do idei apletów. Programem służącym do uruchomiania aplikacji tego typu jest javaws,dostarczana standardowo ze środowiskiem uruchomieniowym i operujący na plikach JNLP,opisujących daną aplikację.Rysunek 1.3 przedstawia różnorodność sieciowych technologii wspieranych przez firmę

Sun w kontekście zastosowania ich w określonym środowisku. Najbardziej rozpowszech-nione aplikacje internetowe swoje działanie ograniczają do przeglądarki, przeglądarka jestim niezbędna do prawidłowego funkcjonowania.Aplety w głównej mierze działają w środowisku przeglądarki, takie jest ich głów-

ne zastosowanie, mogą jednak również funkcjonować poza nią, przy użyciu dodatkowegooprogramowania.Ostatnią grupę stanowią aplikacje napisane z wykorzystaniem technologi Java Web

Start (JWS), które po uruchomieniu działaja na zasadzie standardowej aplikacji Swing.Protokół JNLP służy im jedynie do dystrybucji.

1.2. Architektura

Wraz z upływającym czasem, zmieniało się podejście do tworzenia aplikacji interne-towych. Ma to szczególne odzwierciedlenie w architekturze [30], wykorzystywanej przez

13

projektowane szkieletety programistyczne. Ewolucja była związana również z postępemtechnologicznym, dopiero wydanie JavaServer Pages, w dwa lata po pierwszej specyfikacjiJava Servlet API, wraz w połączeniu z biblioteką JSTL pozwoliło na rzeczywiste odsepa-rowanie poszczególnych warstw aplikacji a tym samym na opracowanie najdogodniejszejarchitektury aplikacji, wykorzystywanej po dzień dzisiejszy.Niniejszy rozdział prezentuje modele aplikacji związane z projektowaniem aplikacji

webowych, począwszy od stosowanych najwcześniej.

1.2.1. Model 1 – strona JSP

Architektura aplikacji stosująca Model 1 jest najprostszą z opisywanych. Serwlet bądźstrona JSP odbierająca żądanie jest odpowiedzialna za wszelkie przetwarzanie prowadzącedo zwrócenia odpowiedzi użytkownikowi aplikacji. W typowej aplikacji omawiane zadaniasprowadzają sie do:— odebrania i przetworzenia żądania,— walidacji danych,— przeprowadzenia procesów biznesowych,— wygenerowaniu odpowiedzi.Pomimo swojej prostoty opisywana architektura nie sprawdza się pod względem ska-

lowalności, gdyż znaczący stopień funkcjonalności jaką oferuje porozrzucana jest po wieluduplikujących się plikach jsp. Ponadto przedstawiany model niepotrzebnie miesza logikębiznesową i logikę prezentacji aplikacji.Trudno jest wprowadzić w aplikacji budowanej według Modelu 1 nową, odmienną

warstwę widoku, np. w postaci XML-a, gdyż oznaczałoby to duplikację logiki biznesowejw stosunku do systemu opartego o stary widok np. HTML.Pewną modyfikację Modelu 1 wprowadza użycie obiektów JavaBean, których zagnież-

dżenie w kodzie strony JSP sprawia, iż logika biznesowa zostaje oddzielona w znacznymstopniu od logiki prezentacji. Rozwiązanie takie ma jednak pewne wady, związane z dużąilością kodu Javy umieszczonego w szablonach. Nie ma to takiego dużego znaczenia jakw przypadku pierwotnej wersji Modelu 1 jednak wprowadza pewne zamieszanie, szcze-gólnie w większych firmach gdzie nad aplikacją pracuje wielu grup programistów. W tegotypu sytuacjach następuje podział pracy pomiędzy programistami a twórcami szablonów,jeżeli kod szablonu zawiera w sobie dużo kodu języka Javy to stanowi to utrudnieniedla webmastera i jednocześnie rozmywa granicę w odpowiedzialności pomiędzy kodemtworzonym przez programistów i projektantów stron internetowych.Rysunek 1.4 przedstawia architekturę aplikacji opartej o Model 1. Żądanie odebrane

od użytkownika aplikacji kierowane jest to strony JSP, która zajmuje się dalszym przetwa-rzaniem żądania. Operacje na modelu oddelegowywane są do obiektów JavaBean, któresą odpowiedzialne za pobranie i przetworzenie modelu. Gotowy model znajduje miejscew zwracanej odpowiedzi, która zostaje skierowana do przeglądarki użytkownika, któryzainicjował żądanie.

1.2.2. Model 2 – centralny kontroler

Jednym z niezwykle ważnych aspektów podczas tworzenia aplikacji internetowej jestseparacja poszczególnych części aplikacji o różnym przeznaczeniu. Esencją wspomnianejzasady jest wzorzec Model-Widok-Kontroler przedstawiony w dalszej części rozdziału.Zdecydowana liczba frameworków których celem jest pomoc przy tworzeniu aplikacji in-ternetowych, implementują właśnie ten wzorzec. Pouczające może się okazać próba zasto-

14

Rysunek 1.4: Architektura aplikacji internetowej według modelu prostego

sowania opisywanego wzorca z wykorzystaniem czystych serwletów i stron JSP. Propo-nowane rozwiązanie bazujące na samych serwletach nie może konkurować pod względemfunkcjonalności zastosowania z rozwiązaniem wykorzystującym szkielety programistyczne,jednakże w wielu przypadkach może być wystarczające, dodatkowo pomaga w zrozumieniuzasady działania frameworków dedykowanych.Model 1 ze względu na swoją prostotę, jest stosowany w prostych aplikacjach, nato-

miast architektury opartej o Model 2 zaleca się używanie w aplikacjach złożonych. Model 2to w rzeczywistości model wykorzystujący wzorzec projektowy Model-Widok-Kontroler(MVC). W skrócie, praca aplikacji opartej o ten model składa się z serwletu odbierają-cego i przetwarzającego żądanie oraz decydującego o użytym widoku. Szerzej o wzorcuMVC traktuje następny rozdział.Rysunek 1.5 przedstawia szczegółowo zasadę działania Modelu 2. Żądanie (krok 1)

wysłane przez klienta z użyciem przeglądarki internetowej kierowane jest do serwletu teninicjalizuje potrzebne do pracy obiekty JavaBean (krok 2). Sterowanie zostaje przekazanew następnej kolejności do strony JSP (krok 3), która korzysta z wcześniej przygotowanychobiektów, w celu pobrania danych modelu z bazy danych bądź innego systemu odpowie-dzialnego za przechowywanie danych (krok 4 i 5). Kiedy strona jest wypełniona danymiuzyskanymi z modelu następuje odpowiedź systemu (krok 6).

Wzorzec Model-Widok-Kontroler

Początki zastosowanie wzorca MVC sięgają języka Smalltalk-80. Podstawowym celemwzorca Model-Widok-Kontroler (MVC) jest oddzielenie warstwy widoku związanej z pre-zentacją interfejsu użytkownikowi a logiką biznesową zwaną również logiką domeny (ang.domain logic). Separacja wspomnianych warstw i ich odpowiedzialności (ang. separationof concerns) sprawia, iż są one niezależnie – ma to znaczący wpływ podczas wprowadzaniazmian w jednej z nich.Opisywany wzorzec dzieli aplikację na trzy części w zależności od pełnionej w niej

funkcji:— model, enkapsuluje dane na których operuje aplikacja,— widok, odpowiedzilany za pozyskiwanie danych z modelu i prezentacji ich użytkowni-kowi,

— kontroler, odpiera i przetwarza żądania korzystając z pozostałych elementów.

15

Rysunek 1.5: Architektura aplikacji internetowej według modelu złożonego

Przedstawiony wzorzec został zainspirowany mechanizmem przetwarzania informacji, gdziekontroler reprezentuje wejście, model przetwarzane dane a widok wyjście systemu.Założeniem modelu jest jego niezależność od pozostałych składowych wzorca MVC,

widoku i kontrolera. Możliwe jest wykorzystanie jednego modelu w wielu aplikacjach posia-dających inne widoki bądź używające innych kontrolerów. Możemy wyróżnić dwa rodzajemodeli, model pasywny i aktywny.Wmodelu pasywnym obiekty nie mają najmniejszej świadomości uczestniczenia w tria-

dzie MVC. Kontroler informuje widok w momencie dokonania zmian, które powodująkonieczność jego aktualizacji. Model pasywny jest najbardziej popularnym modelem w za-stosowaniach MVC, szczególnie w aplikacjach internetowych które pracują według cyklużądanie – odpowiedź, aktualizując za każdym razem wyświetlany widok, bez względu nadokonane zmiany.Model aktywny zawiera mechanizm notyfikacji, który pozwala na informowanie pozo-

stałych uczestników triady o zaistniałych zmianach, najczęściej stosując wzorzec Observer.Podejście takie wymaga rejestracji widoku i kontrolera w modelu, jakkolwiek nie ma onświadomości ich istnienia – nie narusza to zasad opisywanego wzorca.Widok pozyskuje dane z użyciem modelu i prezentuje je użytkownikowi, reprezentując

wyjście aplikacji. Pomimo posiadania dostępu do modelu, widok nie powinien dokonywaćw nim żadnych zmian a jedynie dokonywać operacji odczytu. W modelu aktywnym widokma możliwość rejestracji a tym samym szansę na otrzymywanie informacji o dokonanychw nim zmianach.Kontroler otrzymuje żądania użytkownika i przetwarza je z użyciem modelu i widoku.

W standardowej implementacji opisywanego wzorca kontroler wywołuje metody modeluw celu jego uaktualnienia. W modelu aktywnym po dokonaniu zmiany w modelu wi-dok zostaje automatycznie powiadomiony o dokonanych zmianach, w modelu pasywnymzadanie to spoczywa bezpośrednio na kontrolerze.Element kontrolera nie pełni funkcji mediatora pomiędzy widokiem a modelem. Kon-

troler i widok mają równe prawa w dostępnie do modelu. Rola kontrolera nie polega rów-nież na kopiowaniu danych z modelu i osadzaniu ich w widoku a jedynie na informowaniu,w przypadku modelu pasywnego, o aktualizacjach.Rysunek 1.6 przedstawia relacje pomiędzy poszczególnymi składowymi wzorca MVC.

Zależność pomiędzy kontrolerem a widokiem jest bezpośrednia. Dane wejściowe użyte

16

Rysunek 1.6: Zależności pomiędzy poszczególnymi składowymi wzorca MVC

w formularzach mają swoje odzwierciedlenie w prezentowanym widoku. Często się zdarza,iż w wielu szkieletach programistycznych implementujących opisywany wzorzec, widoki kontroler są połączone razem tworząc tzw. Document View. Użycie pasywnego modeludodaje kontrolerowi zadanie poinformowania widoku o zmianach w nim dokonanych.W wielu obecnie używanych szkieletach programistycznych kontroler ma znacznie

większe, niż przedstawione znaczenie. Jest on odpowiedzialny dodatkowo za stworzeniei wybranie odpowiedniego widoku oraz przekazaniu mu odpowiednich danych w celu wy-świetlenia.Zależność modelu i widoku odbywa się na zasadzie zależności widoku od modelu.

Zmiany dokonane w modelu wymagają aktualizacji widoku.Ostatnią z opisywanych zależności dotyczy modelu i kontrolera. Kontroler zależy od

modelu, zmiany dokonane w modelu mogą wymagać dokonania zmian w samym kontro-lerze.

Implementacja wzorca MVC

Niniejsza sekcja prezentuje prostą implementacja wzorca MVC wykorzystującą nastę-pujące składniki:— serwlet, w roli kontrolera,— stronę wykonaną w technologi JSP, w roli widoku,— obiekt użytkownika, reprezentującego model.Celem aplikacji jest wyświetlenie informacji powitalnej dla użytkownika o podanym

w żądaniu id. Zakładamy, iż obiekt klienta user posiada pole name oraz unikalny numeridentyfikacyjny id i spełnia zasady konwencji dla JavaBean.Kod fragmentu serwletu przedstawiony na listingu 1.3, składający się z metody doGet

pobiera numer id (uid) użytkownika przekazany za pomocą metody HTTP GET. Na-stępnie przy wykorzystaniu usługi userService pobiera określoną osobę z zewnętrzne-go źródła danych (linia 4), np. z relacyjnej bazy danych. W kolejnym kroku umiesz-cza obiekt użytkownika w żądaniu (linia 5). Poźniej tworzy widok, wykorzystując stronęwelcome.jsp do której nastąpi przekierowanie w ostatniej linii skryptu.Zadaniem strony będzie wyświetlenie powitania wraz z imieniem użytkownika, który

został przekazany przez kontroler. Kod strony prezentuje listing 1.4. Rezultatem prezen-towanej strony będzie wyświetlenie kominikatu „Witaj Adam!”, w przypadku podaniaw żądaniu inicjalizującym id użytkownika o imieniu Adam.

17

�1 public void doGet(HttpServletRequest request, HttpServletResponse response)2 throws ServletException, IOException {3 Long userId = Long.parseLong(request.getParameter("uid"));4 User user = userService.getUser(userId);5 request.setAttribute("user", user);6

7 RequestDispatcher view = request.getRequestDispatcher("/welcome.jsp");8 view.forward(request, response);9 }� �

Listing 1.3: Kontroler aplikacji opartej o wzorzec MVC

�1 <jsp:useBean id="user" type="User" scope="request" />2 <html>3 <head><title>Strona powitalna</title></head>4 <body>5 <h2>Witaj <jsp:getProperty name="user" property="name" />!</h2>6 </body>7 </html>� �

Listing 1.4: Widok aplikacji opartej o wzorzec MVC

Przedstawiony sposób obrazuje oddzielenie danych i sposobu ich przetwarzania odwarstwy prezentacji, w tym przypadku strony HTML. Bez trudu można byłoby stwo-rzyć inny widok, osadzający dane pobranego użytkownika np. w treści bedącej XML-em.Osadzenie logiki biznesowej w kontrolerze pozwala równocześnie na zmiany w sposobieprzetwarzania pobranych danych bez modyfikacji szablonów widoku. Przykładowa zmianakolejności liter w imieniu użytkownika, skutkowałaby wyłącznie zmianą w kodzie serwletu,szablon którego jedynym celem jest przedstawienie imienia użytkownika wraz z powita-niem, pozostałby bez zmian.

1.2.3. Model komponentowy

Model komponentowy [17] stanowi zastosowanie idei komponentowego tworzenia apli-kacji w zastosowaniu do warstwy prezentacji. Bazuje na wcześniej opisanym modelu zło-żonym, wprowadzając zasady komponentowego tworzenia interfejsu użytkownika.Szkielety programistyczne stosujące model komponentowy mają wiele wspólnego ze

środowiskami typu Rapid Application Development (RAD) które mają na celu uspraw-nienie procesu tworzenia aplikacji desktopowych. Wspomniane komponenty, zwane rów-nież kontrolkami, są składowymi interfejsu użytkownika, mogą to być np. przyciski bądźskomplikowane tabele. Ważną cechą komponentów jest możliwość ich zawierania w sobie.Istnieją komponenty niewizualne, których rolą może być między innymi tworzenie ukła-du strony bądź grupowanie innych komponentów. Ważnym elementem wyróżniającymkomponenty jest posiadanie przez nie wewnętrznego stanu.W podejściu klasycznym stosującym pierwotną wersję Modelu 2 aplikacja składa się

z szablonów, które są kierowane w odpowiedzi do przeglądarki, po uprzednim otrzymaniużądania do kontrolera, który podaje widokowi dane. Model komponentowy prezentuje innepodejście do prezentowanego zagadnienia. Strona składa się z komponentów, które reagująna zdarzenia, których źródłem jest najczęściej użytkownik aplikacji. Do zdarzeń można

18

Rysunek 1.7: Model komponentowy w implementacji JavaServer Faces

zaliczyć naciśniecie przycisku, wypełnienia pola, wybrania pozycji z menu. Odpowiedniemetody są odpowiedzialne następnie za przechwycenie powstałego zdarzenia.Rysunek 1.7 przedstawia schemat modelu opartego o podejście komponentowe, zaim-

plementowane w szkielecie programistycznym JavaServer Faces [26]. Model (ang. Model)reprezentuje własności obiektów domenowych na których operuje aplikacja, np. imię wy-świetlanego użytkownika. Komponenty (ang. components) interfejsu użytkownika dekla-rują zdarzenia, które użytkownik z ich użyciem może wygenerować. Wychwytywaniempojawiających zdarzeń zajmują się metody nasłuchujące (ang. event listeners), którychzadaniem jest reakcja na otrzymane zdarzenia. Do przykładowych zadań metody na-słuchującej może być przetworzenie odebranych danych bądź wyświetlenie szczegółówwybranej osoby w systemie. Osobna klasa odpowiedzialna za widok tworzy poszczególnekomponenty użytkownika. Możliwa jest zmiana klasy renderującej (ang. renderer) w przy-padku, gdy chcielibyśmy np. wyświetlić naszą stronę z użyciem innego języka znaczników.Efektem wprowadzenia komponentowego modelu tworzenia interfejsu użytkownika

z wykorzystaniem ramy projektowej, otrzymujemy dostęp do gotowego zbioru komponen-tów, które mogą zostać wykorzystane podczas pracy nad aplikacją, począwszy od prostychprzycisków po skomplikowane, stronicowane tabele.Obecnie na rynku szkieletów programistycznych jedynie niektóre stosują opisywany

model. Ma to związek z między innymi wykorzystaniem stosunkowo nowego podejścia,nie rozpowszechnionego jeszcze wśród programistów Javy.

1.3. Zadania szkieletów programistycznych

Internetowe szkielety programistyczne stanowią zbiór bibliotek i narzędzi mających nacelu ułatwienie programiście zrealizowanie zamierzonego celu w zakresie budowy aplikacjiwebowej.Opisywane narzędzia mogą stanowić pewien ograniczony, niewielki zbiór ułatwiają-

cy pracę np. z bazami danych poprzez aplikacje pomocne przy implementacji warstwy

19

prezentacji tworzonego systemu po frameworki, które dostarczają kompleksowej pomocypodczas budowania aplikacji internetowej, dostarczając rozwiązań w postaci utrwalaniadanych, tworzenia warstwy biznesowej czy warstwy prezentacji. Do ostatniej grupy należyszkielet JBoss Seam [34], który wykorzystuje odpowiednio bibliotekę Hibernate [27] jakomaper obiektowo-relacyjny, Enterprise JavaBean 3.0 do enkapsulacji logiki biznesoweji JavaServer Faces do budowy warstwy prezentacji.Opisywane w pracy szkielety programistyczne należą do grupy pośredniej i zajmu-

ją się jedynie wsparciem w implementacji warstwy prezentacji tworzonego systemu. Donajczęściej implementowanych funkcjonalności frameworków webowych należą:— zapewnienie mapowania nadchodzących żądań do odpowiednich kontrolerów, a w przy-padku szkieletów opartych o model komponentowy do odpowiednich metod nasłuchu-jących,

— stworzenie systemu nawigacji między stronami aplikacji,— umożliwienie dostępu do warstwy modelu aplikacji z uwzględnieniem konwersji i wali-dacji wprowadzanych danych,

— integracja z językami znaczników, pomocnymi przy tworzeniu szablonów stron,— dostarczenie zbioru komponentów (w przypadku frameworków komponentowych),— pomoc w internacjonalizacji i lokalizacji tworzonych stron,— wsparcie dla alternatywnych technologii widoku takich jak FreeMaker,— przełączanie motywów wyglądu aplikacji (ang. theme).Zdecydowana większość szkieletów korzysta również z Modelu 2 w celu separacji poszcze-gólnych składowych aplikacji.Mapowanie nadchodzących żądań najczęściej odbywa się z udziałem wcześniej opi-

sywanego obiektu tzw. Front Controllera, który przechwytuje wszystkie kierowane doaplikacji żądania i decyduje o ich późniejszym losie. Spotykane podejścia rozwiązująceopisywany problem sprowadzają się do stworzenia konfiguracji, najczęściej w postaci plikuXML, z mapowaniami adresów URL do poszczególnych kontrolerów i ich metod. We fra-meworkach opartych o komponenty, które są sterowane zdarzeniami, stosuje się przejściamiędzy stronami oparte o komunikaty, zwracane przez poszczególne metody nasłuchujące.Typowe użytkowanie aplikacji internetowej sprowadza się do wysyłania żądania przez

jej użytkowników oraz udzielania odpowiedzi przez system. W celu sprawnego porusza-nia się po aplikacji, szkielety programistyczne dostarczają wsparcia dla nawigacji. Mato szczególne znaczenie w przypadku skomplikowanych ciągów zdarzeń nawigacyjnychwykorzystujących pojęcie stanowości.Bardzo ważnym aspektem aplikacji internetowych jest interakcja z użytkownikiem,

odbywająca się najczęściej z wykorzystaniem formularzy. Rolą szkieletu programistycz-nego pozostaje wówczas przekształcanie własności obiektów modelu na pola formularzaoraz tworzenie z wypełnionych przez użytkownika pól formularza obiektów dziedziny. Nie-odzowną funkcjonalnością związaną z formularzami jest walidacja wprowadzonych przezużytkownika danych, zarówno po stronie klienta jak i serwera.Podczas tworzenia aplikacji, również webowych, korzystna jest separacja pracy po-

szczególnych grup osób. Ma to szczególne znaczenie w oddzieleniu pracy twórców sza-blonów od programistów implementujących logikę aplikacji. Najczęściej jest to osiąganepoprzez użycie znaczników ze specjalnymi atrybutami, które są następnie przekształca-ne po stronie serwera w gotową do wyświetlenia stronę. Pożądaną cecha jest równieżmożliwość dziedziczenia szablonów, co skutkuje znacznie łatwiejszą w utrzymaniu baząszablonów.W przypadku frameworków komponentowych możliwe jest użycie komponentów w ce-

20

lu przyspieszenia budowy interfejsu użytkownika. Komponenty te biorą na siebie wszelkieaspekty związane z poprawnym wyświetlaniem ich w różnych przeglądarkach, zaoszczę-dzając tym samym czas programisty, który nie musi już rozwiązywać problemów nie-kompatybilności poszczególnych przeglądarek. Ujemną stroną takiego rozwiązania jestograniczony wpływ programisty na kod tworzonej strony, gdyż głównymi jej elementamisą gotowe komponenty.Jednym z wyróżników aplikacji internetowych jest łatwość ich użycia przez ludzi z róż-

nych stron świata – wystarczy jedynie przeglądarka, przy braku wymogu co do instalacjijakiegokolwiek innego oprogramowania. Dlatego często niezbędna jest internacjonaliza-cja/lokalizacja tworzonych stron, obejmująca takie aspekty prezentowanej treści jak:— tłumaczenie treści i komunikatów systemu,— poprawne formatowanie daty, liczb i walut,— uwzględnienie stref czasowych w których działa użytkownik,— zmianę kolorów bądź grafiki w zależności od zasad kulturowych klienta,— zmianę kolejności sortowania elementów.W zależności od prezentowanej treści często jest wygodniej używać alternatywnych,

w stosunku do stron JavaServer Pages technologi, takich jak szablony FreeMaker czy XMLpołączony z transformacjami XSLT. Czasami zachodzi również konieczność przedstawieniatreści w specyficzny sposób z użyciem formatu PDF czy arkuszy Excela.Ostatnią z przedstawianych funkcji szkieletów programistycznych jest wsparcie dla

możliwości zmiany motywu wyglądu aplikacji. Funkcjonalność ta może mieć szczególneznaczenie w przypadku serwisów, których celem jest maksymalne dopasowanie serwowanejtreści do preferencji użytkownika, np. w systemach rekomendujących [38].

21

2. Nowoczesne środowisko pracy programisty

Celem niniejszego rozdziału jest opis środowiska pracy wraz z wybranymi narzędziamiużytymi podczas procesu tworzenia przykładowej aplikacji, przedstawionej w rozdziale 5.Pierwszy z podrozdziałów przedstawia narzędzia, tworzące platformę do budowy apli-

kacji webowych w środowisku Java. Przeznaczeniem narzędzia Subversion jest wersjono-wanie kodu źródłowego systemu, z możliwością powrotu do poprzedniego stanu. AplikacjęMaven można uważać za następcę Anta, służącą do zarządzania tworzonym projektem.Potrafi uczestniczyć w procesie budowy, raportowania i dokumentowania projektu. Biblio-teka Hibernate stanowi najpopularniejsze obecnie narzędzie służące do translacji obiekto-wo-relacyjnej dostępnej na platforme Java. Spring Framework to szkielet programistycznyusprawniający tworzenie aplikacji poprzez użycie, między innymi, wzorca odwróconegosterowania (ang. Inversion of Control).W drugiej części zostały zaprezentowane narzędzia wspomagające pracę programisty

podczas testowania tworzonego oprogramowania. Spring-mock jest jedną ze składowychszkieletu Spring Framework, służącą do przeprowadzania testów integracyjnych na apli-kacjach tworzonych za pomocą tego narzędzia. EasyMock to biblioteka pomocna w testo-waniu warstwy biznesowej aplikacji, tworząca obiekty zastępcze (ang. mock objects) napodstawie już istniejących. JUnit 4 stanowi sztandarowe narzędzie wykorzystywane pod-czas testów jednostkowych. Selenium jest biblioteką wspomagającą testowanie aplikacjiwebowych w środowisku przeglądarki internetowej.

2.1. Narzędzia integrujące

Obecnie na rynku istnieją narzędzia wspomagające tworzenie oprogramowana prak-tycznie na każdym stadium rozwoju aplikacji. Począwszy od systemów wersjonowaniakodu (ang. source code management) po specjalizowane szkielety programistyczne. W roz-dziale zostaną przedstawione jedynie wybrane z nich, użyte podczas tworzenia przykła-dowej aplikacji.

2.1.1. Subversion

Aplikacja Subversion (svn) stanowi przykład systemu kontroli wersji (ang. revisioncontrol system), umożliwiającego śledzenie zmian dokonanych w kodzie źródłowym (w przy-padku projektów informatycznych) oraz pomocnej podczas łączenia zmian dokonywanychprzez wielu programistów podczas wspólnej pracy nad projektem.Subversion nie jest w ścisłym sensie aplikacją typu SCM (ang. Software Configuration

Management), gdyż nie zawiera w sobie funkcji specyficznych dla zarządzania kodem pro-jektów informatycznych. Do wspomnianych funkcji można zaliczyć zrozumienie językówprogramowania, których kod jest składowany w repozytorium czy wsparcie w zakresienarzędzi do budowy aplikacji na podstawie kodu przechowywanego w repozytorium. Sub-version jest narzędziem uniwersalnym, nadaje się równie dobrze do wersjonowania kodu

22

źródłowego aplikacji webowej jak do wersjonowania notatek sporządzanych podczas pisa-nia pracy dyplomowej.Subversion stanowi scentralizowany system kontroli wersji, kod przechowywany jest

we wspólnym repozytorium, dostępnym dla wszystkich aplikacji klienckich. Dane składo-wane są w postaci wirtualnego, drzewiastego systemu plików, który w trakcie dokonywaniazmian, podlega ciągłemu wersjonowaniu. Aplikacje kliencie łączące się z repozytoriummają możliwość pobierania jego treści lub jego modyfikacji.Opisywany system działa według zasady pobierz-zmodyfikuj -dołącz, która jest sto-

sowana również przez CVS, stanowi zarazem alternatywę dla blokowania plików podczasedycji. Programiści wyrażający chęć pracy nad kodem, składowanym w wspólnym re-pozytorium tworzą swoją własną lokalną kopię repozytorium, będącą odzwierciedleniemrepozytorium centralnego. Następnie każdy z nich wprowadza swoje modyfikacje będącewynikiem pracy nad kodem. Ostatnim krokiem jest wprowadzenie dokonanych zmian dorepozytorium.

Historia

Prace w CollabNet, kolebce Subversion, rozpoczęły się w lutym 2000 roku, jako po-szukiwania następcy CVS-a. Budowany system nie miał stanowić rewolucji dla standardude facto jakim był darmowy Concurrent Versions System (CVS), miał jedynie poprawićjego braki i niedociągnięcia.Do niedostatków systemu (CVS), które były bezpośrednimi powodami rozpoczęcia

pracy nad opisywanym projektem należą:— zmiany w repozytorium nie są operacjami atomowymi co może doprowadzić do powsta-wania niespójności w kodzie repozytorium w przypadku wystąpienia błędu podczaswprowadzania zmian do repozytorium,

— operacje przenoszenia plików lub zmiany ich nazwy nie maja swojego odzwierciedleniaw systemie wersjonowania,

— brak wersjonowania dowiązań symbolicznych (ang. symbolic links),— ograniczone wsparcie dla standardu Unicode.Przy projekcie, od jego początków, uczestniczyli Karl Fogel, autor książki „Open Sour-

ce Development with CVS” oraz Jimy Blandy, którzy już wcześniej zaczęli poszukiwanianowego systemu wersjonowania, a poproszeni przez CollabNet wyrazili chęć współpracy.Wraz z końcem sierpnia 2001 roku projekt osiągnął stan w którym mógł sam prze-

chowywać swoje własne źródła. Programiści pracujący nad Subversion zawiesili używaniesystemu CVS do składowania kodu projektu Subversion.Firma CollabNet przez cały czas trwania projektu, opłaca pracę wybranych progra-

mistów tworzący nowy system wersjonowania. Posiada do niego prawa licencyjne, któresą jednak w pełni zgodne z wytycznymi Debian Free Software Guidelines [18]. Każdy maprawo do bezpłatnego pobierania, modyfikacji oraz używania kodu projektu Subversion,zgoda CollabNet nie jest wymagana.

Funkcjonalność

Subversion dostarcza wiele usprawnień w stosunku do systemu CVS, który był jegopierwowzorem, niektóre spośród nich to:— Wersjonowanie katalogów, podczas gdy CVS potrafił tylko wersjonować jedynie po-jedyncze pliki, Subversion wprowadza pojęcie wersjonowanego, wirtualnego systemuplików. Wszystkie operacje podejmowane w jego obrębie są rejestrowane. Dotyczy to

23

plików jak i samych katalogów. Można w dowolnej chwili cofnąć się do poprzedniejwybranej wersji systemu.

— Usprawnione wersjonowanie, dziennik systemu CVS obejmuje wyłącznie zmiany do-konywane na zawartości plików. Subversion potrafi wersjonować operacje kopiowania,zmiany nazwy, przenoszenia plików jak i katalogów. Ponadto jest możliwe stworzenienowego pliku o nazwie pliku już istniejącego, który nie dziedziczy jego historii.

— Atomowe dokonywanie zmian, podczas wprowadzania zmian do większej liczby plików,zmiany wprowadzane są wszystkie albo żadne. Nie ma możliwości, aby do repozytoriumbyły wprowadzone tylko częściowe zmiany.

— Metadane, z każdym plikiem bądź katalogiem w repozytorium można skojarzyć me-tadane, w postaci pary klucz–wartość. Własności te są wersjonowane tak samo jakzawartość plików. Najczęściej definiują typ pliku lub jego autora.

— Efektywne tworzenie nowych rozgałęzień (ang. branches) i znaczników (ang. tags),tworzenie nowych rozgałęzień zajmuje stałą ilość czasu, wykorzystuje koncepcję po-dobną do twardych dowiązań (ang. hard links).System Subversion składa się z wielu komponentów, które w połączeniu z podkomen-

dami realizują odmienne cele, do ważniejszych z nich należą:— svn, aplikacja kliencka wykorzystywana między innymi do pobierania kodu źródłowegoz repozytorium,

— svnlook, służy do przeglądania zawartości repozytorium,— svnserve samodzielny serwer svn, który może być uruchomiony jako demon systemowylub usługa typu inetd.

Praca z repozytorium

Podczas wspomnianego modelu pracy może się zdarzyć, że dojdzie do konfliktu w mo-mencie, gdy dwóch programistów wprowadziło rozbieżne zmiany w tym samym fragmenciekodu. Rozwiązaniem jest proces scalenia kodu, który dokonuje programista chcący wpro-wadzić nowy kod, pozostający w konflikcie z kodem już istniejącym. Do programisty należywówczas decyzja o postaci kodu wprowadzonej do repozytorium. Kluczowym czynnikiempomagającym rozwiązywać konflikty jest komunikacja pomiędzy programistami pracują-cymi nad wspólnym projektem.Pobranie kodu z repozytorium odbywa się za pomocą polecenia svn wraz z użyciem

podkomendy checkout. Następujący kod (listing 2.1) tworzy lokalną wersję projektuo nazwie calc na podstawie centralnego repozytorium, w katalogu bieżącym o nazwiekalkulator. Podczas łączenia z repozytorium został wykorzystany protokół svn.�

1 svn checkout svn://dev.firma.com/repos/calc/trunk kalkulator� �Listing 2.1: Pobranie kodu z repozytorium

Wraz ze wprowadzonymi zmianami (ang. revisions) następuje inkrementacja numeruwersji dla repozytorium. Opisywany numer jest wspólny dla wszystkich projektów, któredzielą jeden wersjonowany system plików – wspomniane repozytorium. Prowadzi to dosytuacji w której aktywny projekt zwiększa numer zmian projektów mniej aktywnych,dzielących wspólne repozytorium. W większości przypadków nie ma to znaczenia i niewprowadza zamieszania wśród twórców różnych projektów. Rozwiązaniem jest stworzenieróżnych repozytoriów dla projektów o odmiennym przeznaczeniu. Należy jednak pamiętać,iż Subversion wersjonuje jedynie zmiany dokonane w obrębie projektów znajdujących sięw jednym repozytorium.

24

Rysunek 2.1: Inkrementacja numeru rewizji a zmiany w repozytorium

Podczas wprowadzania zmian następuje zróżnicowanie numerów zmian poszczególnychplików przechowywanych w repozytorium, gdyż akcja wprowadzania zmian nie implikujeakacji pobrania kodu z centralnego repozytorium. W momencie modyfikacji przykłado-wego pliku plik.txt, przechowywanego w repozytorium oznaczonego numerem wersji10, po wprowadzeniu zmian wersja repozytorium zostaje inkrementowana, jednak tylkozmodyfikowany plik otrzymuje nowy numer zmiany 11. Reszta plików posiada numer 10bądź jedne z wcześniejszych.Sprawę wprowadzanych zmian w repozytorium i ich skutków na numery zmian (rewi-

zji) poszczególnych plików jak i całego projektu, prezentuje rysunek 2.1. Liczba w kwadra-cie oznacza numer zmiany dla całego repozytorium, jeżeli nie oznaczono inaczej. Literą Zzostał oznaczony etap zmiany nazwy pliku. Liczba w okręgu oznacza numer rewizji plikubezpośrednio się przy nim znajdującego.W trakcie wprowadzania modyfikacji polegającej na zmianie nazwy jednego z plików

przechowywanych w repozytorium, zostają wykonane dwie operacje. Jedna dodaje dorepozytorium plik o nowej nazwie, druga usuwa dotychczas istniejący. Pomimo wykonaniadwóch operacji, rewizja zmienianego pliku zmienia się o jeden, z 5 na 6. Numer zmiany dlapozostałej części projektu pozostaje bez zmian, wynosi 5. Przykładowy zapis wykonanychpoleceń został przedstawiony na listingu 2.2. Duże litery A i B zaczynające odpowiedniodrugą i trzecią linię oznaczają odpowiednio dodanie pliku do repozytorium oraz usunięciepoprzednio istniejącego pliku noszącego starą nazwę.�

1 svn commit "/project/Calc/a" "/project/Calc/b" -m "Zmiana nazwy pliku"2 A /project/Calc/b3 D /project/Calc/a4 Transmitting file data: /project/Calc/a5 Committed revision 6� �

Listing 2.2: Zmiana nazwy pliku w repozytorium Subversion

W trakcie budowy aplikacji może zajść potrzeba stworzenia odmiennej gałęzi od głów-nej linii kodu, np. w celu wprowadzenia nowej czasochłonnej funkcjonalności. Tworzenienowej gałęzi odbywa się poprzez skopiowanie głównego kodu do nowego katalogu, zwy-czajowo podkatalogu katalogu branches. Do przełączania się pomiędzy poszczególnymigałęziami służy komenda switch. Po zakończeniu procesu tworzenia nowej funkcjonalnościnastępuje scalenie jej (ang. merge) z główną linią kodu.Równie częstą praktyką jest znakowanie projektu tzw. tagami. Tag wskazuje na okre-

ślony, konkretny moment w cyklu życia projektu. Kod oznaczony znacznikiem, w przeci-

25

wieństwie do kodu znajdującego się w gałęzi, nie ulega zmianom. Typowym przykłademużycia znakowania jest przypadek wydania kolejnej wersji oprogramowania. Tworzonyjest wówczas tag o nazwie stworzonej wersji, reprezentujący kod aplikacji w momenciekolejnego wydania.

2.1.2. Maven

Maven jest narzędziem zaliczanym do grupy określanej mianem szkieletów wspomaga-jących zarządzanie projektem (ang. project managment framework). Według [60] opisy-wane narzędzie stanowi zbiór standardów, formatów repozytoriów oraz oprogramowaniaużywanych w celu zarządzania i opisu projektów. Uczestniczy w definiowaniu standardo-wych etapów życia oprogramowania od budowy poprzez testy po wdrożenie. Wprowadzamodularność, pozytywnie wpływającą na możliwość ponownego użycia poszczególnychelementów tworzonego oprogramowania z użyciem Mavena.

Historia

Idea projektu Maven zrodziła się z potrzeby posiadania wspólnej platformy wytwarza-nia oprogramowania przez Apache Software Foundation (ASF). Wcześniej każdy z pro-jektów realizował własną wizję procesu tworzenia oprogramowania, począwszy od budowyoprogramowania po tworzenie strony domowej projektu. W rezultacie, pomimo istnieniapewnych wspólnych elementów, każdy z projektów istniał jako samotna wyspa.Brak standardowego narzędzia zarządzającego cyklem życia tworzonego oprogramo-

wania prowadził do tego, iż każdy z nowych projektów był zmuszony do powtórnegotworzenia własnego systemu. Często odbywało się to na zasadzie kopiowania pomysłówpodpatrzonych w innych projektach. Kłopoty przeżywały projekty, które wymagały szcze-gólnie skomplikowanego systemu budowy oprogramowania, takie jak Jakarta Taglibs [57].Uwaga programistów skupiała się w dużej części na zapewnieniu infrastruktury dla pro-jektu kosztem pracy nad funkcjonalnością tworzonego produktu.Bezpośrednim powodem powstania Mavena był niezadowalający proces budowy in-

nego projektu, Turbine [32]. Programiści szybko zrozumieli zalety stosowania szkieletuwytwarzania oprogramowania jakim jest Maven. Wprowadzenie usystematyzowanego pro-cesu spowodowało iż zrozumienie zasad działania jednego projektu skutkuje poznaniemwszystkich pozostałych stosujących ten sam proces. Zakres wpływu Mavena sięga od pro-cesu budowy, testowania, wdrażania, po przeprowadzanie testów zarówno jednostkowychjak i integracyjnych, generowanie dokumentacji i raportów.Wersja Mavena oznaczona wersją 1.0 wydano w lipcu 2004 roku, szybko została za-

aprobowane przez społeczność Codehaus. Obecne stabilne wydanie Mavena nosi wersję2.0.5, zostało wydane w lutym 2007 roku.Maven często jest porównywany do innego standardu w zakresie budowy aplikacji,

Anta. Maven stanowi nadzbiór funkcjonalności jaką oferuje Ant [5], stanowi narzędzieo szerszym zakresie działania. Wprowadza pojęcie wzorców stosowanych przy budowieaplikacji, definiując między innymi standardowe rozmieszczenie katalogów w projekcie.Maven może w sposób całkowity zastąpić Anta.

Podstawy

Maven wprowadza nowy poziom abstrakcji w procesie budowy oprogramowania. O ilekażdy z projektów informatycznych posiada indywidualną naturę, wszystkie je łączy pe-wien określony cykl życia, nad którym Maven stara się zapanować. Elementy specyficzne

26

dla danego projektu deklaruje się w pliku POM (Project Object Model), który jest wy-rażony za pomocą składni języka XML.Zasady, którymi kieruje się projekt Maven zostały zaczerpnięte z dzieła Christopera

Alexandra pod tytułem „A Pattern Language” [3], należą do nich:— konwencja względem konfiguracji,— tworzenie w sposób deklaratywny,— nacisk na ponowne wykorzystanie istniejących już elementów,— spójne zarządzanie zależnościami.Jedną z największych zalet tworzenia oprogramowania z użyciem Mavena jest możli-

wość szybkiego skorzystania z gotowego systemu budowy dla tworzonego systemu, dziękiskorzystaniu z domyślnych ustawień oferowanych przez Mavena. Ważną informacją jestmożliwość zmiany domyślnych ustawień, poprzez nadpisanie ustawień standardowych.Takie praktyki są jednak niezalecane. Zaleca się przestrzeganie domyślnych ustawień dlaprojektu. Opisana praktyka pozytywnie wpływa na łatwość sposobu opisu zachowaniai struktury systemu budowania wśród programistów stosujących domyślne ustawienia.Projekty tworzone z użyciem Mavena posiadają standardowe rozmieszczenie katalogów

dla źródeł, plików zasobów (ang. resources), plików konfiguracyjnych, dokumentacji czytworzonego projektu. Ta prosta na pozór zasada, pozwala w drastyczny sposób skrócićczas potrzebny za zaznajomienie się z nowym projektem.Kolejną zasadą którą stosuje Maven jest zasada podziału odpowiedzialności (ang. se-

paration of concerns), która w zastosowaniu do opisywanego systemu powoduje, iż nawyjściu każdego z projektów znajduje się zawsze jeden plik wyjściowy jar, lub w przy-padku aplikacji webowych plik war. Powoduje to, że dany projekt skupia się na jednejgłównej funkcjonalności, korzystając równocześnie w razie potrzeby z innych projektów.W przypadku aplikacji (projektów) tworzonych z wykorzystaniem Mavena, separacja od-bywa się na poziomie jednostek zwanych modułami. Każdy moduł może być uważanyza osobny projekt dostarczający innej funkcjonalności, a w połączeniu dających pełnąfunkcjonalność końcową.Maven stara się również wprowadzić wspólne zasady nazewnicze dla zarządzanych ele-

mentów, ma to bezpośrednie odzwierciedlenie np. w nazwach tworzonych projektów któresą zapisywane w formacie, reprezentowanym przez następujący przykład log4j-1.2.14.jar,który oznacza plik biblioteki Log4j w wersji 1.2.14.Ponowne użycie komponentów, oprócz wspomnianych modułów, jest również realizo-

wane przez wtyczki (ang. plugins), które dostarczają opisywanej funkcjonalności Mavena.Wszystkie funkcjonalności jakie oferuje Maven są implementowane z wykorzystaniem wty-czek. Z listą dostępnych wtyczek można się zapoznać na stronie http://maven.apache.org/plugins/. Istnieją pluginy pomocne przy kompilacji, wdrażaniu, przeprowadzaniutestów, generowaniu raportów czy plików projektu specyficznych dla środowisk programi-stycznych takich jak Eclipse czy IDEA. Ostatnia ze wspomnianych możliwości, umożliwiapracę nad projektem stworzonym z wykorzystaniem Mavena w wybranym środowiskuprogramistycznym, gdyż standardowo wygenerowany projekt nie posiada plików charak-terystycznych dla żadnego z nich.Maven wprowadza do projektu ściśle określony cykl życia projektu (ang. build life cyc-

le). Poszczególne etapy składają się z faz, do których mogą zostać przypisane określoneakcje, dostarczane za pomocą wtyczek. Przykładowo jeżeli zleci się Mavenowi kompilacjęprojektu za pomocą komendy compile, wówczas zostaną wykonane następujące fazy:walidacja, inicjalizacja, generowanie źródeł, przetworzenie źródeł, przetworzenie plikówzasobów oraz kompilacja. Z każdą z przedstawionych faz skojarzone są konkretne akcje

27

dostarczane przez wtyczki. Obecnie domyślny cykl życia projektu składa się z 21 faz,począwszy od wspomnianej walidacji po końcowe wdrożenie aplikacji. Dodatkowo istnie-ją inne cykle życia związane z czyszczeniem projektu (clean) czy generowaniem stronydomowej (site).

Project Object Model

Akcje podejmowane przez Mavena są sterowane w sposób deklaratywny zawartościąpliku projektu POM, o standardowej nazwie POM.xml. Każdy z projektów/modułów po-siada dokładnie jeden taki plik, opisujący jego cechy.Listing 2.3 prezentuje przykład poprawnego pliku POM, który umożliwia przepro-

wadzenie kompilacji, testów i wygenerowaniu dokumentacji. Wszystkie te czynności sąmożliwe dzięki możliwości dziedziczenia pomiędzy plikami POM. Każdy z tworzonych�

1 <project>2 <modelVersion>4.0.0</modelVersion>3 <groupId>com.mycompany.app</groupId>4 <artifactId>my-app</artifactId>5 <packaging>jar</packaging>6 <name>Maven Project</name>7 <version>1.0-SNAPSHOT</version>8 <dependencies>9 <dependency>10 <groupId>junit</groupId>11 <artifactId>junit</artifactId>12 <version>3.8.1</version>13 <scope>test</scope>14 </dependency>15 </dependencies>16 </project>� �

Listing 2.3: Zawartość pliku pom.xml projektu Mavena

plików POM dziedziczy domyślnie ustawienia z predefiniowanego pliku POM o nazwieSuper POM. Definiuje on wszystkie wspomniane wcześniej standardowe ustawienia dlaprojektu. W zrozumieniu jego istoty, pomaga analogia do nadrzędnego obiektu językaJava java.lang.Object.Listing 2.3 przedstawia zawartość pliku POM. Znacznik project stanowi znacznik

będący korzeniem całego dokumentu. W linii drugiej podano zastosowaną wersję plikuPOM. W liniach od 3 do 7 podano informacje na temat projektu. Element groupId maznaczenie podobne do pakietów znanych z języka Java i służy do grupowania powiązanychpakietów w repozytorium Mavena bądź lokalnym. Znacznik artifactId symbolizuje na-zwę projektu, wygenerowany projekt będzie posiadał nazwę my-app-1.0-SNAPSHOT.jar.Element packaging definiuje typ aplikacji. Pozostałe znaczniki reprezentują krótką nazwęprojektu oraz jego wersję. Znacznik dependency symbolizuje konkretną zależność z jakiejkorzysta dany projekt, w tym wypadku jest to biblioteka JUnit, w wersji 3.8.1.

Zarządzanie zależnościami

Jednolite zarządzanie zależnościami jest jedną z kluczowych zalet stosowania projektuMaven przy budowie tworzonej aplikacji. Na listingu 2.3, za pomocą znacznika dependency

28

została wyrażona zależność budowanego projektu. Najpopularniejszym artefaktem plat-formy Java, służącym dystrybucji programów są pliki jar. Wspomniana zależność jestreferencją do artefaktu znajdującego się w repozytorium. Położenie artefaktu jest jed-noznacznie definiowane poprzez jego groupId oraz artifactId. Maven powiadomionyo potrzebie spełnienia zależności łączy się z serwerem i na podstawie wspomnianych da-nych ściąga go do lokalnego repozytorium.Deklaracja zależności polega na tym iż programista jest zwolniony z obowiązku fi-

zycznego wskazywania wymaganej zależności. Wystarczy iż opisze potrzebne bibliotekiw pliku mieszczącym opis specyficznych cech projektu a Maven zajmie się resztą. Progra-mista przestaje operować niskopoziomowymi pojęciami takimi jak pliki jar, deklaruje poprostu potrzebę użycia biblioteki JUnit w określonej wersji.Pobrana ze zdalnego serwera zależność zostaje umieszczona w repozytorium lokalnym,

które pełni również funkcję pamięci podręcznej. Jeżeli żądana zależność nie znajduje sięw lokalnym repozytorium wówczas Maven sięga do repozytorium zdalnego. Szkielet lokal-nego repozytorium jest tworzony podczas pierwszego uruchomienia Mavena. Opisywanabiblioteka nie zawiera w sobie żadnych z domyślnych bibliotek ani bibliotek wykorzysty-wanych wtyczek. Uruchomienie po raz pierwszy komendy czyszczącej projekt mvn cleanspowoduje pobranie wtyczki o nazwie clean z repozytorium i umieszczeniu jej na dyskulokalnym w strukturze repozytorium lokalnego.W procesie poszukiwania zależności najpierw jest sprawdzane repozytorium lokalne,

gdy zależność nie zostanie spełniona wówczas Maven przystępuje do sprawdzenia repozy-toriów zdalnych, gdy zostały zdefiniowane dodatkowe sprawdzane są wszystkie w kolejno-ści ich definicji w pliku POM. Jeżeli zależność zostanie spełniona w jednym z opisywanychmiejsc, jest zapisywana do repozytorium lokalnego a proces ulega zakończeniu. Od tegomomentu każdy projekt żądający pobranej wcześniej zależności będzie używał tej z repo-zytorium lokalnego.Zaprezentowane podejście sprawia, iż wszystkie zależności tworzonych projektów defi-

niowane są w jednym miejscu, lokalnym repozytorium, ma to szczególne znaczenie podczaspracy nad wieloma projektami, gdyż nie ma potrzeby dublowania tych samych bibliotekw wielu projektach co wielokrotnie ma miejsce. Projekt składowany w repozytorium ko-du jest pozbawiony zależności, które są pobierane ze wspólnego repozytorium Mavena.Częstą praktyką jest zakładanie oprócz repozytoriów lokalnych, również repozytorium napoziomie firmy, do którego wszyscy programiści mają szybki dostęp. Repozytorium opróczfunkcji typowej dla pamięci podręcznej służy również do składowania artefaktów produko-wanych przez samych programistów. Artefakt umieszczony zdalnie w repozytorium firmysprawia iż wszyscy pozostali mają do niego ułatwiony dostęp i mogą pracować zawszez najnowszymi elementami systemu.Domyślnie dostępność nowszych wersji bibliotek jest sprawdzana raz dziennie. W przy-

padku zależności oznaczonych sufiksem SNAPSHOT, obecność nowszej wersji jest spraw-dzana za każdym razem gdy zajdzie taka potrzeba.

2.1.3. Eclipse

Efektywna praca wykorzystująca platformę Java nie jest możliwa bez wsparcia ze stro-ny odpowiedniego środowiska programistycznego. Niniejszy podrozdział stanowi wprowa-dzenie do środowiska rozwijanego przez Eclipse Foundation [2].Idea zintegrowanego środowiska wytwarzania oprogramowania (IDE) polega na połą-

czeniu wymaganych podczas pracy narzędzi w formie jednolitego, autonomicznego pakietuoprogramowania. Integracja narzędzi wspierających budowę, kompilację, diagnozowanie

29

projektu czyni pracę bardziej efektywną oraz zwalnia z potrzeby korzystania z innychczęsto niekompatybilnych zewnętrznych narzędzi.Dla prostych projektów użycie zintegrowanych środowisk programistycznych nie jest

warunkiem koniecznym. Skuteczną alternatywą może być edytor tekstu, wzbogaconyo możliwość kolorowania składni bądź wspomagający poruszanie się po strukturze pro-jektu. Dodatkowym wsparciem może być narzędzie do automatycznej budowy aplikacjitakie jak Ant czy Maven.Praca nad projektem złożonym zgodnym z J2EE wymaga szerokiego wsparcie od stro-

ny środowiska programistycznego. Do kluczowych funkcjonalności należą:— wsparcie dla używanych w projekcie języków oprogramowania takich jak Java, Python,SQL czy XML,

— obecność konfigurowalnych generatorów kodu jak i określonych artefaktów programi-stycznych,

— pomoc w zakresie używanych interfejsów programistycznych,— możliwość skorzystania z operacji refaktoryzacji kodu,— integracja z systemami kontroli wersji takimi jak CVS czy Subversion,— wsparcie w testowaniu i diagnozie tworzonego systemu.Z wszystkich z wymienionych funkcjonalności można skorzystać używając środowiska Ec-lipse, część z nich wymaga instalacji dodatkowych wtyczek.Nazwą Eclipse przyjęło się nazywać popularne wśród programistów języka Java śro-

dowisko programistyczne. Jednak pod tą nazwą, kryje się cała platforma programistycz-na mająca na celu wspomaganie przy wytwarzaniu oprogramowania. Obecnie platformaEclipse dostarcza rozwiązań w zakresie tworzenia aplikacji korporacyjnych, przeznaczo-nych do urządzeń typu embedded, desktopowych. Dostarcza wsparcia w programowaniuz użyciem takich języków jak Java, C, Cobol, PHP. Dodatkowo stanowi podstawę wieluszkieletów wykorzystywanych podczas projektowania, testowania czy raportowania.

Cechy środowiska

Platforma Eclipse wprowadziła koncepcję obszarów roboczych (ang. workspace), którefunkcjonują na poziomie projektów i pozwalają na grupowanie ich w logiczne jednostki.Podczas uruchomiania środowiska użytkownik ma możliwość wyboru obszaru roboczegoz którym chce pracować. Dodatkowo z wyborem obszaru roboczego wiąże się dostępnośćposzczególnych wtyczek. Środowisko wykorzystywane do tworzenia projektów skupionychw obszarze roboczym wykorzystującym język Python będzie korzystało z innych kompo-nentów niż projekty wykorzystujące język Java.Na poziomie interfejsu użytownika wprowadzono pojęcie perspektyw (ang. perspecti-

ves), które pomagają przy wykonywaniu różnych prac związanych z wytwarzaniem opro-gramowania. Użycie określonej perspektywy wpływa na wygląd menu, obecności i rozkładokien. Istnieją perspektywy wykorzystywane podczas pisania kodu, podczas przeglądaniaplików projektu, testowania, śledzenia błędów czy pracy z systemem wersjonowania kodu.Zalętą platformy Eclipse jest możliwość użycia wtyczek w celu zwiększenia, rozbu-

dowania możliwości środowiska. Strona projektu Eclipse Plugin Central (EPIC) http://www.eclipseplugincentral.com zawiera katalog wtyczek dostępnych dla opisywanejplatformy. Obecnie jest ich prawie 1000 pogrupowanych w kategoriach począwszy od wty-czek wspomagających projektowanie po wtyczki związane z wdrożeniem.Wsparcie dla języka Java jest implementowane przez projekt Java Development Tools

(JDT), dostarczające między innymi następujących elementów: obsługi składni, adnotacji,przyrostową kompilację kodu, refaktoryzację, śledzenie błędów czy wsparcie w operacjach

30

związanych z zarządzaniem kodem. Projektem wspierającym programistę podczas budo-wy aplikacji J2EE z wykorzystaniem platformy Eclipse jest Web Tools Platform (WTP)Project.Wspomniane cechy Eclipse realizuje z wykorzystaniem następujących elementów:

— współpraca z CVS jest wbudowana w środowisko, pracę z repozytoriami Subversionzapewnia wtyczka Subversive,

— wsparcie dla języków SQL, XML, HTML zapewnia projekt WTP,— pozostałe z wymienionych elementów (testy, kreatory, diagnoza) zapewniają odpo-wiednie projekty, charakterystyczne dla danego języka bądź środowiska, w przypadkuJavy jest to JDT, w przypadku języka Ruby – RDT.

Istnieje również możliwość dodania własnych wtyczek poprzez mechanizm Update Site,wykorzystując protokół HTTP. Instalacja oraz ewentualne dalsze uaktualnienia zostanąprzeprowadzone automatycznie poprzez platformę Eclipse.

2.1.4. Hibernate

Hibernate [36] jest narzędziem wspomagającym proces odwzorowania obiektowo-rela-cyjnego. W przeciwieństwie do znanych z wersji EJB 2.0 ciężkich komponentów encyjnych,opisywana biblioteka umożliwia operację na zwykłych obiektach Javy (ang. Plain Old Ja-va Object), oferując przeźroczyste wsparcie w zakresie składowania i odczytu obiektówz magazynu danych.Przedstawiana biblioteka posiada wsparcie dla aplikacji korporacyjnych, obsługuje

transakcje, obiekty wartości, pule połączeń. Posiada również swój własny język zapytańHibernate Query Language (HQL), który w przeciwieństwie do języka SQL [?] operuje naobiektach. Oprócz tego biblioteka oferuje wsparcie w przypadku klas stosujących dziedzi-czenie, asocjacje czy złożenie. Hibernate posiada wsparcie w zakresie współpracy z ponaddwudziestoma różnymi dialektami języka SQL, począwszy od bazy HSQLDB po Oracle.Oznacza to iż teoretycznie, zmiana silnika bazodanowego nie będzie się wiązała ze zmianąkodu w samej aplikacji.Konfiguracje mapowań można przeprowadzić w dwojaki sposób. Pierwszy z nich jest

szerzej znany i sprowadza się do zastosowania plików wykorzystujących język XML w celuopisania mapowań pomiędzy obiektami i tabelami w bazie danych jak również pól klasdo kolumn w tabelach bazy danych. Drugi sposób konfiguracji polega na wykorzystaniu,wprowadzonej w wersji 5.0 języka Java, adnotacji za pomocą których opisuje się zwykłeobiekty Java, nadając im charakter obiektów trwałych.Podstawą architektury systemu Hibernate jest obiekt SessionFactory, który posiada

informację o wszystkich mapowaniach aplikacji związanych z pojedynczą używaną baządanych, jest obiektem o bezpiecznych wątkach (ang. thread-safe). Jego tworzenie jestkosztowne, przeznaczony jest do wielokrotnego użycia.Obiektem wytwarzanym przez opisaną wcześniej fabrykę jest Session, który reprezen-

tuje konwersację pomiędzy obsługiwanymi obiektami a magazynem danych. Jest obiektemkrótkotrwałym, jednowątkowym, przeznaczonym do wykonywania operacji na obiektachtrwałych. Obiekty trwałe stanowią reprezentację danych pobranych z magazynu danych,przeważnie są to zwykłe obiekty Java.W typowym scenariuszu aplikacja posiada jeden obiekt SessionFactory, który w razie

potrzeby jest wykorzystywany do tworzenia obiektów typu Session, które służą z koleido wykonywania operacji na obiektach trwałych.Obiekty w czasie pracy z biblioteką Hibernate mogą przybierać w danym czasie jeden

z następujących trzech stanów:

31

— Ulotny (ang. transient), obiekt nigdy nie został skojarzony z żadną sesją Hibernate, nieposiada przypisanego mu identyfikatora. Typowym przykładem jest nowo stworzonybądź odebrany obiekt.

— Trwały (ang. persistent), obiekt jest reprezentowany przez otwartą sesję oraz posiadaswój identyfikator oraz odpowiadający mu wiersz w bazie danych. W opisywanymstanie Hibernate gwarantuje zgodność obiektu przechowywanego w pamięci z jegopostacią w magazynie danych. Typowym przykładem jest obiekt świeżo pobrany zmagazynu bądź niedawno tam zapisany.

— Odłączony (ang. detached), obiekt był już w zasięgu sesji jednak utracił z nią kon-takt bądź został przekazany do innego procesu. Posiada swój identyfikator oraz od-powiadający mu wiersz w bazie danych. Dla obiektów tego typu Hibernate nie możezagwarantować spójności z ich odpowiednikiem w bazie danych.Programista używający narzędzia Hibernate musi być świadomy stanu obiektów z któ-

rymi pracuje. Domyślnie włączona opcja leniwego pobierania kolekcji (ang. lazy fetching)może spowodować rzucenie wyjątku związanego z brakiem żądanej kolekcji, gdy obiektznajduje się w stanie odłączonym.

Przykład mapowania obiektów

Niniejsza sekcja prezentuje prosty przykład mapowania pomiędzy dwoma obiektamiPOJO z wykorzystaniem adnotacji. Obiekt właściciela Ownermoże posiadać wiele zwierzątPet, przy czym dane zwierze może posiadać tylko jednego właściciela. Jest to typowyprzykład relacji n–m, prezentowana relacja dodatkowo jest dwustronna.Listing 2.4 przedstawia mapowanie obiektu POJO odpowiadającemu właścicielowi.

W bazie danych zostanie zapisane nazwisko name właściciela oraz jego kolekcja zwierząt.�1 @Entity2 @Table(name = "owners")3 public class {4 private String name;5 private Set<Pet> pets = new HashSet<Pet>();6

7 @Column(name = "pets")8 @OneToMany(targetEntity = org.company.domain.Pet.class,9 cascade = { CascadeType.ALL }, mappedBy = "owner")10 @Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN)11 @JoinColumn(name = "owner_id")12 public Set<Pet> getPets() {13 return pets;14 }15 }� �

Listing 2.4: Mapowanie obiektu właściciela

Obiekty właściciela zostaną zmapowane do tabeli o nazwie wskazywanej przez adnotacjęTable. Relacja jeden do wielu została wyrażona adnotacją OneToMany z użyciem zależno-ści kaskadowej. Skasowanie właściciela skutkuje automatycznym skasowaniem wszystkichnależących do niego zwierząt.Listing 2.5 prezentuje encję zwierzęcia, zawierającą imię oraz referencję do swojego

właściciela. Adnotacja ManyToOne reprezentuje relację wiele do jednego. Nie możliwe jest

32

�1 @Entity2 @Table(name = "pets")3 public class Pet {4 private String name;5 private Owner owner;6

7 @ManyToOne8 @JoinColumn(nullable = false)9 @ForeignKey(name = "fk_owner")10 public Owner getOwner() {11 return owner;12 }13 }� �

Listing 2.5: Mapowanie obiektu zwierzęcia

zapisanie obiektu w magazynie danych nie posiadającego referencji do właściciela, dbao to właściwość nullable należąca do adnotacji JoinColumn. Właściwość name adno-tacji ForeignKey nadpisuje automatycznie generowaną nazwę dla klucza obcego relacjiwłaściciel–zwierzę.

2.1.5. Spring Framework

Szkielet programistyczny Spring Framework powstał, według autora Roda Johnsona,w reakcji na niedostatki związane z zastosowaniem ciężkiego modelu jaki wiązał się z użyt-kowaniem technologi Enterprise JavaBeans w wersji 2.0 [51]. Pierwsze wydanie biblioteki,noszące numer wersji 1.0 pojawiło się w marcu 2004 roku. Obecnie Spring jest wymienia-ny wśród najczęściej stosowanych frameworków warstwy środkowej, używanych podczastworzenia aplikacji webowych z wykorzystaniem platformy Java.Spring do swojego działania nie wymaga serwera aplikacji takie jak np. JBoss [33],

wystarczy kontener serwletów, Tomcat [8] bądź Jetty [37]. Użycie lekkich środowisk skra-ca znacznie czas potrzebny na wdrożenie aplikacji, co ma szczególne znaczenie podczastworzenia oprogramowania, podczas częstych zmian kodu. Skrócony czas potrzebny nawdrożenie aplikacji oznacza szybką informację zwrotną. Programista nie musi długo cze-kać żeby zobaczyć rezultaty swojej pracy.

Wzorzec odwróconego sterowania

Podstawowymi obiektami wykorzystywanymi podczas tworzenia aplikacji z wykorzy-staniem frameworka Spring są zwykłe obiekty Javy. Całość integrowana jest z wyko-rzystaniem wzorca odwrócenia sterowania (ang. Inversion of Control) a dokładniej jegoodmiany noszącej nazwę wstrzykiwania zależności (ang. Dependency Injection) [23]. Uży-wany wzorzec pozwala na usunięcie bezpośrednich powiązań pomiędzy obiektami wpły-wając pozytywnie na stan luźnego powiązania obiektów (ang. loose coupling), pożądanegow aplikacjach dowolnego typu.Odpowiedzialność zapewnienia wzajemnego powiązania pomiędzy obiektami używa-

nymi w aplikacji spoczywa na tzw. kontenerze IoC. Jego zadanie polega na udostępnia-niu wcześniej zdefiniowanych obiektów i dostarczaniu ich wraz z zależnościami zwracane-go obiektu. Istnieją dwie metody wstrzykiwania zależności, jedna z nich (wstrzykiwaniekonstruktorem) wykorzystuje konstruktor tworzonego obiektu do dostarczenia zależności,

33

druga (wstrzykiwanie metodami modyfikującymi) polega na wykorzystaniu standardo-wych metod ustawiających dla obiektów spełniających specyfikację JavaBeans.Opisywane podejście wykorzystujące wstrzykiwanie zależności wpływa pozytywnie na

łatwość testowania aplikacji. Luźno powiązane obiekty łatwiej jest testować. Osiągane jestto poprzez definicję odpowiednich interfejsów które implementują określone obiekty Java.Poszczególne zależne od siebie obiekty opierają się w swoich relacjach na wyspecyfiko-wanych interfejsach. Ułatwia to zastosowanie obiektów zastępczych (ang. mock objects).Wzorzec odwróconego sterowania pozwala w łatwy sposób podmieniać współpracujące zesobą obiekty.W przypadku szkieletu Spring zależności są deklarowane poza kodem w postaci plików

wykorzystujących do opisu powiązań język XML.

Moduły

Spring składa się z szeregu niewielkich modułów o ściśle określonych funkcjach, do-piero użycie ich razem pozwala na zbudowanie aplikacji oferującej pełną funkcjonalność.W związku z posiadaniem ściśle określonych zadań przez każdy z opisywanych modułów,możliwe jest również użycie ich oddzielnie. Do najważniejszych modułów opisywanegoszkieletu zaliczają się:— kontener odwróconego sterowania, którego zadaniem jest dostarczanie skonfigurowa-nych obiektów oraz zarządzanie ich cyklem życia,

— szkielet Aspect-oriented programming (AOP), niezwykle ważna część frameworka Springużywana między innymi przy implementacji deklaratywnego zarządzania transakcjami,

— szkielet dostępu do danych enkapsuluje standardowe mechanizmy JDBC, używającwspólnej hierarchii niesprawdzalnych wyjątków. Równocześnie wprowadza możliwośćintegracji tworzonej aplikacji z bibliotekami typu Hibernate czy SQL iBATIS [29],

— szkielet zarządzania transakcjami, nie wymaga do działania serwera aplikacji. Dostar-cza różnych strategi zapewnienia spójności transakcyjnych danych,

— własny szkielet warstwy prezentacji implementujący wzorzec MVC o nazwie SpringWeb MVC, jego największą zaletą jest łatwość integracji z reszta infrastruktury do-starczanej przez Springa,

— szkielet wspomagający testowanie aplikacji z wykorzystaniem testów jednostkowychjak i integracyjnych.W architekturze frameworka Spring ważna rolę tworzą szablony, które ułatwiają im-

plementację określonych zadań. Przykładowo istnieje szablon HibernateTemplate, którywspiera programistę w użyciu szkieletu Hibernate. Listing 2.6 prezentuje metodę pobiera-jącą listę produktów loadProductsByCategory wykorzystującą opisywany szablon. Dlaprzejrzystości kodu zrezygnowano z deklaracji generowanych wyjątków. Linia druga za-wiera utworzenie nowego szablonu, w kolejnej linii następuje wywołanie metody execute,która jako parametr przyjmuje anonimową klasą wewnętrzną HibernateCallback będącąinterfejsem implementowanym z wykorzystaniem metody doInHibernate. Ciało metody(linie 5 do 8) tworzy kod charakterystyczny dla frameworka Hibernate. Wynik będącylistą produktów z żądanej kategorii zostaje zwrócony w linii 8.

Wzorzec Dependency Injection

Celem niniejszej części jest przedstawienie odmiany wzorca Inversion of Control zwane-go Dependency Injection. Podstawowym zastosowaniem wzorca wstrzykiwania zależnościjest zmniejszenie zależności występujących w kodzie pomiędzy obiektami systemu orazumożliwienie łatwej wymiany poszczególnych elementów systemu.

34

�1 public Collection loadProductsByCategory(String category) {2 HibernateTemplate ht = new HibernateTemplate(this.sessionFactory);3 return (Collection) ht.execute(new HibernateCallback() {4 public Object doInHibernate(Session session) {5 Query query = session.createQuery(6 "from test.Product product where product.category=?");7 query.setString(0, category);8 return query.list();9 }10 });11 }� �

Listing 2.6: Użycie szablonu HibernateTemplate

W przykładzie ilustrującym opisywany wzorzec występują dwie, zależne od siebie klasyMessageRenderer oraz SimpleMessageProvider. Pierwsza z nich jest odpowiedzialna zawyświetlenie komunikatu, który uzyska od drugiej klasy.Klasa MessageRenderer 2.7 posiada referencję do interfejsu MessageProvider z me-

todą getMessage(), wykorzystywaną podczas wyświetlania wiadomości.�1 public class MessageRenderer {2 private MessageProvider messageProvider;3 MessageRenderer(MessageProvider messageProvider) {4 this.messageProvider = messageProvider;5 }6 public void render() {7 System.out.println(messageProvider.getMessage());8 }9 }� �

Listing 2.7: Klasa wyświetlająca komunikat

Rola klasy SimpleMessageProvider (listing 2.8) polega na dostarczeniu określonejwiadomości. Dla uproszczenia przykładu wiadomość posiada stałą treść. Inne implemen-tacje interfejsu MessageProvider mogą pobierać wiadomość z zewnętrznego źródła np.bazy danych.�

1 public class SimpleMessageProvider implements MessageProvider{2 public String getMessage() {3 return "Hello World!";4 }5 }� �

Listing 2.8: Klasa dostarczająca komunikat do wyświetlenia

Rola kontenera IoC ogranicza się do dostarczania żądanych zależności. W opisywanymprzypadku należy połączyć instancję klasy SimpleMessageProvider z polem messageProviderw ramach procesu zwanego wstrzykiwaniem zależności. Ponieważ klasa posiadająca zależ-ność posiada konstruktor, wykorzystane zostanie wstrzykiwanie zależności z wykorzysta-

35

niem konstruktora. Listing 2.9 prezentuje plik konfiguracyjny odpowiedzialny za określeniezależności pomiędzy obiektami. Bean simpleProvider jest przekazywany jako argumentkonstruktora beanowi renderer.�

1 <beans>2 <bean id="simpleProvider" class="SimpleMessageProvider" />3 <bean id="renderer" class="MessageRenderer">4 <constructor-arg ref="simpleProvider" />5 </bean>6 </beans>� �

Listing 2.9: Konfiguracja zależności

Zbiór beanów umieszczono w pliku beans.xml. Uruchomienie kodu zaprezentowanegona listingu 2.10 spowoduje wyświetlenie oczekiwanego komunikatu.�

1 public static void main(String[] args) {2 BeanFactory fact = new XmlBeanFactory(new ClassPathResource("beans.xml"));3 MessageRenderer renderer = (MessageRenderer) fact.getBean("renderer");4 renderer.render();5 }� �

Listing 2.10: Użycie skonfigurowanego obiektu wyświetlającego komunikat

2.2. Narzędzia testujące

Niezmienność wymagań podczas wytwarzania oprogramowania jest niemożliwa doutrzymania. Zmiany dokonywane są na każdym z etapów życia oprogramowania. Mo-gą wynikać ze zmiany wymagań, nowej wizji produktu bądź poprawy niezauważonychwcześniej błędów. Niniejszy rozdział przedstawia rozwiązania, które starają się reagowaćw sposób dynamiczny na pojawiające się w projekcie systemu zmiany. Prezentowane po-dejście wspomaga zastosowanie techniki wytwarzania oprogramowania sterowaną testami(ang. Test-Driven Development).

2.2.1. Spring Mock

Biblioteka Spring Mock [50] jest składową szkieletu Spring Framework i stanowi plat-formę dla testowania aplikacji tworzonych z wykorzystaniem wspomnianej biblioteki. O jejdojrzałości może świadczyć fakt, iż jest ona używana przez autorów Springa podczas two-rzenia projektu.Spring Mock wspomaga testy integracyjne z wykorzystaniem bazy danych przepro-

wadzane na aplikacji wykorzystującej infrastrukturę Spring Framework. Najczęściej jeststosowany przy testowaniu warstwy Data Access Object (DAO), zapewniającej jednolityinterfejs między warstwą usług a magazynem danych.Kluczową funkcjonalnością dostarczaną przez opisywaną bibliotekę jest dodanie aspek-

tu transakcyjnego do testowanych obiektów DAO. W typowym przypadku podczas testo-wania obiektów DAO, wywołuje się wybrane metody testowanego obiektu mające od-zwierciedlenie w operacjach na obiektach domeny.

36

Jedną z zasad przeprowadzania testów jest dbałość o to, aby wynik działania jednegotestu nie wpływał na działanie testu drugiego. W przypadku testowania obiektu DAOoznacza to, iż wcześniej wykonana operacja na obiekcie domeny w jednym z przypadkówtestowych nie może mieć wpływu na później wykonywany przypadek testowy. Sprowadzasię do operacji testowania, które podczas działania dokonują zmian w używanej baziedanych. Najczęściej operacje tego typu polegają na usunięciu określonych obiektów z bazypodczas operacji testowania. Rola opisywanej biblioteki polega na przywróceniu stanusprzed wykonania przypadku testowego, dzięki temu wykonywane testy zyskują poczucieizolacji.

Przykład

Testowane obiekty DAO muszą korzystać z klasy TransactionProxyFactoryBean,która w sposób przeźroczysty dodaje transakcyjność do używanych obiektów, opisanafunkcjonalność jest wykorzystywana podczas odwracania zmian dokonanych w bazie da-nych podczas wykonywania testu. Kolejne przypadki testowe uruchomiane są w ramachizolowanych transakcji, po zakończeniu każdego z nich zmiany są wycofywane.Klasą odpowiedzialną za przeprowadzanie testów w środowisku transakcyjnym jest

klasa AbstractDependencyInjectionSpringContextTests, po której bezpośrednio dzie-dziczą klasy testujące obiekty DAO.�

1 public class HibernateUserDaoTests extends2 AbstractDependencyInjectionSpringContextTests {3

4 // zaleznosc wstrzykiwana zewnetrznie5 private HibernateUserDao userDao;6

7 // metoda ustawiajaca wykorzystywana podczas wstrzykiwania zaleznosci8 public void setUserDao(HibernateUserDao userDao) {9 this.userDao = userDao;10 }11

12 // test przeprowadzany w srodowisku izolowanym13 public void testLoadUser() throws Exception {14 User user = this.userDao.loadUser(new Long(17));15 assertNotNull(user);16 }17

18 // metoda ladujaca plik konfiguracyjny przygotowany na potrzeby testu19 protected String[] getConfigLocations() {20 return new String[] { "classpath:com/daos.xml" };21 }22

23 }� �Listing 2.11: Test integracyjny w środowisku transakcyjnym

Przykład klasy używającej wspomnianą klasę prezentuje listing 2.11. Przedstawionaklasa ma za zadanie przetestowanie obiektu UserDao, którego zadaniem jest wykonywanieoperacji na obiekcie domeny User. Linia 5 zawiera referencję do testowanego obiektu DAO,który jest wstrzykiwany za pomocą metody ustawiającej w linii 8. Metoda testLoadUser

37

została przygotowana w celu przetestowania procesu pobrania obiektu User z magazynudanych. Warunkiem sukcesu pobrania użytkownika posiadającego id równego 17, jestuzyskanie referencji do niego (linia 14). Metoda z linii 19 ładuje plik konfiguracyjny za-wierający definicję obiektów DAO, które zostały wzbogacone aspektem transakcyjności.

2.2.2. EasyMock

Biblioteka EasyMock jest przykładem implementacji idei obiektów zastępczych (ang.mock objects) podczas przeprowadzania testów jednostkowych. Rola obiektów zastępczychpolega na symulowaniu zachowania obiektów rzeczywistych w sposób kontrolowany. Ich ro-lę można przyrównać do roli manekina używanych podczas testów zderzeniowych podczastestowania samochodów. W obu przypadkach, testowania oprogramowania i samochodu,wykorzystywany jest pewien obiekt pozorny, który pozwala na przeprowadzenie i weryfika-cję powodzenia przeprowadzonego testu. Pierwotnie możliwe było wyłącznie zastępowanieinterfejsów. Obecnie większość popularnych bibliotek wspomagających przeprowadzanietestów z użyciem obiektów pozornych, umożliwia zastępowanie również obiektów.Użycie obiektów pozornych ma uzasadnienie podczas przeprowadzania testów jednost-

kowych obiektów, które muszą w określony sposób współpracować z innymi klasami w celuzrealizowania powierzonego mu zadania. Często działanie obiektów z którymi koniecznajest współpraca jest skomplikowane, bądź samo ich zastosowanie nie jest możliwe w śro-dowisku testowym. Sytuacje wymagające zastosowania obiektów zastępczych, pojawiająsię w przypadku wystąpienia następujących zależności:— użycie niedeterministycznych w czasie wartości, takich jak czas bądź temperatura,— testowanie trudnych do powtórzenia stanów aplikacji, występujących np. w przypadkubłędu sieci,

— potrzeby skrócenia czasu wykonywania testów, gdy używane zależności wykonują dłu-gotrwałe prace wiążące się np. z otwarciem połączenia z bazą danych.

Zastosowanie obiektów zastępczych we wszystkie opisanych powyżej przypadkach pozwalana zwiększenie izolacji poszczególnych testów.

Przykład

Testowanie z wykorzystaniem obiektów zastępczych wymaga przestrzegania ściśle okre-ślonych faz podczas testowania. Listing 2.12 przedstawia przykładową metodą wykorzy-stującą podczas testów obiekt pozorny. Prezentowana metoda testuje metodę usługi, zwią-zanej z zarządzaniem wizytami w przychodni weterynaryjnej, pobierającą trzy najbliższewizyty. Obiekt usługi visitService jest zależny od obiektu DAO VisitDao, któregorola polega na pobraniu z magazyny danych żądanych wizyt. W związku z tym, że pre-zentowany test ma charakter jednostkowy, wykluczone jest korzystanie z bazy danych.Rozwiązaniem jest skorzystanie z obiektu zastępczego dla rzeczywistego obiektu DAOo nazwie visitDaoMock, utworzonego w linii trzeciej. W następnej linii następuje utwo-rzenie testowanego obiektu usługi z wykorzystaniem obiektu pozornego. Linia 6 zawieraoczekiwane zachowanie względem obiektu zależnego, polegające na wywołaniu metodygetMostRecent z odpowiednim parametrem oraz zwróceniu obiektu odpowiedniego typuw tym przypadku ArrayList. W linii 8 następuje aktywacja obiektu zastępczego, po czymodbywa się wywołanie testowanej metody serwisu. Weryfikacja poprawności wywołań orazprzekazywanych typów odbywa się w linii 10.Na podstawie zaprezentowanej metody można wyróżnić następujące etapy stosowane

przy budowaniu testów opartych o obiekty pozorne:1. Utworzenie obiektu pozornego.

38

�1 public void testAddDocument() {2 control = EasyMock.createStrictControl();3 visitDaoMock = control.createMock(VisitDao.class);4 visitService = new DefaultVisitService<Visit, Long>(visitDaoMock);5

6 expect(visitDaoMock.getMostRecent(3)).andReturn(new ArrayList<Visit>());7

8 replay(visitDaoMock);9 visitService.getMostRecentFrom(3);10 verify(visitDaoMock);11 }� �

Listing 2.12: Testowanie z użyciem obiektu pozornego

2. Zastąpienie rzeczywistej zależności obiektem pozornym.3. Wyrażenie za pomocą interfejsu biblioteki EasyMock, oczekiwanej interakcji z obiek-tem pozornym (metoda expect).

4. Wywołanie metody obiektu testowanego.5. Weryfikacja poprawności wykonania wcześniej zdefiniowanego scenariusza.Błąd weryfikacji scenariusza wywołań skutkuje wygenerowaniem błędu typu AssertionErrori przerwaniem wykonywania dalszych testów.

2.2.3. JUnit 4

Celem testów jednostkowych jest zapewnienie zgodności testowanego komponentuz wytycznymi projektu. Testy jednostkowe stanowią podstawę techniki określanej mia-nem programowania sterowanego testami (ang. Test-Driven Development) [39]. Celemtworzonego testu jest zazwyczaj weryfikacja poprawności działania publicznych metodpojedynczej klasy bądź komponentu.Narzędzie JUnit [4] stanowi standard de facto podczas przeprowadzania testów jed-

nostkowych na platformie Java. Jego idea została przeniesiona również na inne językiprogramowania takie jak C#, Python czy Ruby. Wspólnym terminem xUnit określane sąwszystkie narzędzia służące do przeprowadzania testów jednostkowych charakterystycz-ne dla danej platformy programistycznej. Pierwsze służące testom jednostkowym nosiłonazwę SUnit i służyło do testowania kodu napisanego w języku Smalltalk.Pozytywne wyniki działania testów jednostkowych zapewniają poprawność działania

poszczególnych, możliwie jak najmniejszych, komponentów systemu. Zaletą testów jed-nostkowych jest możliwość ich użycia podczas testów regresywnych, ujawniających błędywprowadzone zazwyczaj podczas dodawania nowej funkcjonalności. Dobre testy jednost-kowe posiadają wysoki stopień pokrycia kodu (ang. code coverage), obejmują wszystkielub prawie wszystkie możliwe ścieżki wykonania programu.Stosowanie testów jednostkowych ułatwia integrację całości projektu, gdyż pracujący

nad nim programiści mają pewność poprawności działania poszczególnych jego części.Łatwość automatyzacji testów jednostkowych sprawia, iż można je przeprowadzać wy-starczająco często aby wykryć wkradające się zmiany wynikające ze zmian dokonanychw systemie. W określonych sytuacjach może być pożądane przeprowadzania testów pokażdej kompilacji oprogramowania, w celu natychmiastowego wykrycia wprowadzonychbłędów.

39

Kolejną cechą testów jednostkowych jest dostarczenie informacji na temat funkcjo-nowania poszczególnych komponentów oprogramowania. Dokumentacja w postaci testówjednostkowych ma tę zaletę, że jest zawsze aktualna i odzwierciedla sposób użycia testo-wanych jednostek.Testy jednostkowe nie są w stanie zazwyczaj wychwycić wszystkich błędów tworzo-

nego systemu. Stanowią jednak podstawę dla pozostałych typów testów, takich jak testyintegracyjne, funkcjonalne czy regresyjne [2, rozdział 14].

Przykład

Kod przedstawiony na listingu 2.14 prezentuje przykład zastosowania testu jednost-kowego do weryfikacji poprawności działania klasy Adder, której zadaniem jest zwróceniesumy podanych dwóch liczb.W przykładzie zastosowano bibliotekę JUnit w wersji 4, która wprowadza wiele uspraw-

nień w porównaniu z poprzednią wersją. Do najważniejszych zaliczają się dodanie obsługiadnotacji oraz specjalnych metod typu BeforeClass oraz AfterClass. Nowa bibliotekaposiada tryb zgodności przy przetwarzaniu testów przygotowanych z poprzednią wersjąbiblioteki.Klasa sumatora (listing 2.13) składa się z metody add, której zadaniem jest dodanie

dwóch przekazanych jej liczb. Klasa przypadku testowego została przedstawiona na li-�1 public class Adder {2 public static int add(int x, int y) {3 return x + y;4 }5 }� �

Listing 2.13: Klasa sumatora

stingu 2.14. Składa się z jednej metody, której zadaniem jest przetestowanie statycznejmetody klasy Adder. W odróżnieniu od poprzedniej wersji biblioteki nie ma potrzeby dzie-�

1 public class AdderTest {2 @Test3 public void testAdd() {4 assertEquals("Dodawanie dwoch liczb", 7, Adder.add(2, 3));5 }6 }� �

Listing 2.14: Klasa testowa sumatora

dziczenia przypadku testowego po klasie junit.framework.TestCase, wystarczy jedynieoznaczyć odpowiednie metody klasy testującej adnotacją Test. Kluczowym elementemmetody testujących są asercje, wykorzystywane do badania określonych warunków. Wy-korzystywana metoda assertEquals ma za zadanie porównanie przekazanej jej wartościz wynikiem metody add, przekazanej jako trzeci argument. Napis przekazany jako pierwszyargument ma zadanie jedynie informacyjne i jest wyświetlany w przypadku niepowodzeniatestu, w formie przedstawionej na listingu 2.15. Do metody dodającej sumatora zostałyprzekazany liczby 2 i 3, jednak w metodzie przypadku testowego wprowadzono błędną spo-dziewaną wartość wynoszącą 7. W związku z niespełnieniem asercji, sprawdzającej wynik

40

�1 java.lang.AssertionError: Dodawanie dwoch liczb expected:<7> but was:<5>� �

Listing 2.15: Komunikat o błędzie asercji szkieletu JUnit

rzeczywisty ze spodziewanym został wygenerowany błąd. Wspomniany napis pozwala naszybkie zorientowanie się o miejscu wystąpienia błędu.

2.2.4. Selenium

Biblioteka Selenium [53] stanowi przykład narzędzia wykorzystywanego podczas te-stów akceptacyjnych, zwanych również testami funkcjonalnymi, aplikacji webowych. Testyakceptacyjne działają na zasadzie czarnej skrzynki i wykonywane są zazwyczaj podczasprzekazywania gotowego oprogramowania odbiorcy.Wykonanie testów akceptacyjnych zazwyczaj składa się z określonego zbioru testów

pokrywających żądane przez zleceniodawcę funkcjonalności systemu [28]. Wynik testówjest prezentowany w postaci dwuelementowego zbioru określającego sukces bądź porażkękażdego z testów.Mianem testów akceptacyjnych w programowaniu ekstremalnym określa się testy funk-

cjonalne, używane do weryfikacji tworzonych historii użytkownika (ang. user stories).Odbiorca systemu specyfikuje scenariusze, które mogą obejmować kilka scenariuszy testo-wych w celu weryfikacji poprawności zachowania się aplikacji. Postępy w pracy mierzonesą liczbą zatwierdzonych przez klienta testów akceptacyjnych.Specyficzną cechą biblioteki Selenium jest fakt iż działa wewnątrz przeglądarki in-

ternetowej. Obecnie wspierane są między innymi Internet Explorer, Firefox oraz Ope-ra. Stopień wsparcia jest uzależniony od platformy na której działa dana przeglądarka.Działanie systemu Selenium polega na dodaniu do testowanych stron języka JavaScriptw celu umożliwienia przeprowadzenia testów. Testy przebiegają w sposób automatycznyi polegają na wykonywaniu następujących czynności: klikanie w linki bądź wypełnianiei wysyłanie formularzy.Opisywany system składa się z wyspecjalizowanych komponentów pomocnych w two-

rzeniu i przeprowadzeniu testów. Selenium IDE (wcześniej znane pod nazwą SeleniumRecorder) jest wtyczką przeglądarki Firefox, umożliwiającą rejestrowanie, edycję oraz śle-dzenie tworzonych testów. Selenium Core jest podstawowym serwerem działającym bez-pośrednio i tylko w przeglądarce, wykorzystuje język selense. Rozszerzeniem komponentuSelenium Core jest Selenium Remote Control, który stanowi serwer proxy przyjmującykomendy wysłane za pomocą protokołu HTTP, utworzone za pomocą dowolnego językaprogramowania. W celu dalszego uproszczenia procesu tworzenia testów udostępniono APIdla popularnych języków programowania takich jak Java, Python czy PHP, umożliwiającedostęp do obiektów obudowujących (ang. wrapper objects).Podczas testów zapytania HTTP kierowane są do serwera Selenium Remote Control

i tłumaczone na język selense. Łącznikiem pomiędzy silnikiem, przeprowadzającym testya badaną stroną jest serwer proxy, które wzbogaca przetwarzaną stronę o wyrażenia językaJavaScript. Użycie proxy jest konieczne z powodu funkcjonowania różnych implementacjijęzyka JavaScript w różnych przeglądarkach.

Przykład

Niniejsza sekcja prezentuje użycie biblioteki Selenium z wykorzystaniem komponentuSelenium Remote Control, umożliwiającego użycie języka Java do skonstruowania testu.

41

Tworzony test wspierany jest przez użycie dodatkowej biblioteki JUnit. Przypadek te-�1 import com.thoughtworks.selenium.*;2 import junit.framework.*;3 public class GoogleTest extends TestCase {4 private Selenium sel;5 public void setUp() {6 sel = new DefaultSelenium("localhost", 4444, "*firefox",7 "http://www.google.com");8 sel.start();9 }10

11 public void testGoogle() {12 sel.open("http://www.google.com/webhp");13 sel.type("q", "hello world");14 sel.click("btnG");15 sel.waitForPageToLoad("5000");16 assertEquals("hello world - Google Search", sel.getTitle());17 }18

19 public void tearDown() {20 sel.stop();21 }22 }� �

Listing 2.16: Test Selenium Remote Control w języku Java

stowy zawiera referencję do obiektu sel, który odpowiada za wysyłanie odpowiednichpoleceń protokołu HTTP do serwera testującego. Metoda setUp jest metodą specyficz-ną dla JUnita wykonywaną przed każdym z testów. Położenie serwera testującego zostałozdefiniowane w linii 6, znajduje się maszynie lokalnej i nasłuchuje na porcie 4444. Instruk-cja umieszczona w linii 8 startuje przeglądarkę Firefox i rozpoczyna sesję. Badaną stronąjest strona wyszukiwarki www.google.com1. Metoda testująca znajduje się w linii 11.W pierwszej instrukcji zostaje wczytana żądana strona. W linii 13 następuje wypełnienieformularza wyszukiwawczego, o nazwie q tekstem „hello world”. Po pięciu sekundachnastępuje weryfikacja obecności w tytule pobranej stronie tekstu „hello world - GoogleSearch”.Jeżeli asercja zwróci wartość true, test uznaje się za zakończony pozytywnie. Ostatnia

metoda tearDown jest przeciwieństwem pierwszej metody prezentowanej klasy i służy dooczyszczenia środowiska po wykonanym teście, w tym przypadku jej rola sprowadza się dozamknięcia sesji testowej i zakończeniu pracy przeglądarki wykorzystanej podczas testów.

1 Przykład zaczerpnięty ze strony http://www.openqa.org/selenium-rc/tutorial.html

42

3. Przegląd internetowych szkieletówprogramistycznych

W niniejszym rozdziale przedstawiono przegląd najpopularniejszych bibliotek imple-mentujących zadania typowe dla szkieletów programistycznych przeznaczonych do two-rzenia aplikacji internetowych, wymienione w rozdziale 1.3. Dwa z przedstawionych fra-meworków stosują Model 2. Dwa pozostałe wykorzystują model komponentowy, któryw założeniach ma uczynić tworzenie aplikacji internetowych podobnym do tworzenia apli-kacji desktopowych.Rozdział rozpoczyna opis niedawno1 wydanej biblioteki Struts 2, która stanowi kon-

tynuację projektu WebWork w połączeniu z biblioteką Struts 1. W kolejnej części zo-stał przedstawiony framework Spring MVC, będący częścią biblioteki Spring Frame-work, wspomagający programistę podczas tworzenia warstwy prezentacji z wykorzysta-niem wspomnianej biblioteki. Tematem przedostatniej części jest biblioteka Tapestry 5,która stosuje model komponentowy podczas tworzenia warstwy prezentacji. Ostatna częśćprzedstawia standard JavaServer Faces, będący częścią specyfikacji JEE, wykorzystywanyprzy tworzeniu interfejsu użytkownika.

3.1. Struts 2

Struts 2 [7] jest projektem, którego początki sięgają roku 2005, konferencji JavaOne2005. Wówczas powstał pomysł na dalszy rozwój znanego frameworka Struts. ProgramiściMartin Cooper, Don Brown wraz z Richem Feitem zaproponowali powstanie projektuStruts Ti, którego celem było dodanie elementów, które stworzyła społeczność szkieletuStruts do jego głównej części. Jednocześnie Jason Carreira zaproponował wykorzystanieszkieletu WebWork. Zbieżność rozwiązań stosowanych w tym frameworku oraz pomysłówosób rozwijających Struts 2, doprowadziła do powstania kolejnej wersji szkieletu Struts.Opisywany framework do sprawnego działania wymaga implementacji serwletów zgod-

nych z wersją API 2.4, stron JSP w wersji 2.0 oraz platformy Javy w wersji 5.0.

3.1.1. Architektura

Rozwiązanie bazujące na Struts 2, w warstwie kontrolera, wykorzystuje takie technolo-gie jak: filtry, JavaBeans, XML, XWork, Locales. W warstwie danych opisywany szkieletumożliwia wykorzystanie JDBC, EJB, jak również translatorów obiektowo-relacyjnychtakich jak Hibernate czy iBatis. Warstwa prezentacji bazuje na stronach JavaServer Pa-ges, ze wsparciem w postaci znaczników JSTL, dodatkowo możliwe jest wykorzystanieszablonów FreeMarker [24], Velocity [9] bądź generowanie stron w postaci plików PDF.Możliwa jest definicja procedury obsługi sytuacji wyjątkowych (ang. exception han-

dlers), których rola polega na wychwytywaniu sytuacji potencjalnie niebezpiecznych dla

1 Pierwsze oficjalne wydanie biblioteki Struts 2, oznaczone numerem wersji 2.0.6, miało miejsce22 lutego 2007 roku.

43

Rysunek 3.1: Architektura szkieletu programistycznego Struts 2

działania aplikacji i wyświetleniu zdefiniowanej strony. Interceptory umożliwiają doda-wanie akcji po lub przed wykonaniem akcji, głównej związanej bezpośrednio z obsługążądania.Podczas wykonywania standardowego scenariusza obsługi żądania (rysunek 3.1), żą-

danie przechodzi w pierwszej kolejności przez zestaw predefiniowanych filtrów, które moż-na wykorzystać między innymi podczas tworzenia kompozycji stron. Następnie trafia doobiektu FilterDispatcher, który konsultuje się z obiektem ActionMapper w celu okre-ślenie czy z danym żądaniem została skojarzona akcja. Jeżeli obiekt odpowie twierdząco,sterowanie jest przekazywane do obiektu ActionProxy. Zadaniem ostatnio wspomnianegoobiektu jest wygenerowanie, na podstawie plików konfiguracyjnych, akcji oraz poprzedza-jących ją interceptorów (wykorzystanie wzorca command pattern). Opisany ciąg zdarzeńwykonuje obiekt ActionInvocation, który jest dodatkowo odpowiedzialny za skojarzeniewyniku akcji z odpowiednim szablonem, najczęściej stroną JSP. Ostatnim z kroków jestponowne wywołanie interceptorów, tym razem w odwrotnej kolejności i zwrócenie obiektutypu HttpServletResponse. Podczas pierwszego wywołania interceptorów, wywoływanyjest warunek before. Natomiast podczas powrotu, warunek after.Do elementów tworzonych przez użytkownika należą: akcje, szablony, oraz pliki kon-

figuracyjne takie jak struts.xml. Interceptory oraz filtry są elementami opcjonalnymi.Pozostałe z wymienionych elementów zapewnia szkielet Struts 2.

3.1.2. Znaczniki

Struts 2 wyposaża programistę w zestaw gotowych do wykorzystania znaczników (ang.tags), za pomocą których można tworzyć szablony w oderwaniu od używanej technolo-gii widoku takiej jak strony JSP czy szablony Velocity. Większość ze znaczników jestuniwersalna, jednak niektóre z nich są charakterystyczne dla określonego języka wykorzy-stywanego podczas tworzenia warstwy widoku.

44

Rola znaczników polega na wyświetlaniu danych dynamicznych. W celu wyświetleniapola zawierającego kod pocztowy, można wykorzystać fragment kodu przedstawiony nalistingu 3.1. Jeżeli przekazany widokowi obiekt będzie zawierał opisywane pole, zosta-�

1 <s:textfield name="postalCode" />� �Listing 3.1: Znacznik Struts 2 przedstawiający pole kodu pocztowego

nie ono automatycznie wyświetlone we wskazanym miejscu, podobnie podczas wysłaniaformularza pole obiektu zostanie uaktualnione.Można wyróżnić dwa typy znaczników: generyczne (ang. generic) oraz znaczniki inter-

fejsu (ang. UI tags). Różnica, poza funkcją i implementowaną odpowiedzialnością, polegana tym iż znaczniki interfejsu, zwane również znacznikami HTML, posiadają wsparcie dlaszablonów i motywów.Znaczniki generyczne kontrolują przepływ wykonania podczas generowania strony. Po-

zwalają również na wydobywanie danych z niestandardowych miejsc takich jak obiektylokalizacji czy JavaBeans. W celu kontroli przepływu zawierają wyrażenia if, else czyiteratory. Przy manipulowaniu danymi wykorzystywane są znaczniki typu bean, push czyi18n.W przeciwieństwie do znaczników generycznych, znaczniki interfejsu nie posiadają

wpływu nad logikę czy strukturę kontroli. Ich celem jest wyświetlanie przekazanych imdanych. Wszystkie znaczniki interfejsu są sterowane szablonami bądź motywami. Podczasgdy znaczniki generyczne wyświetlają (w razie konieczności) zawartość w niesformatowanysposób, znaczniki interfejsu wykorzystują do tego celu szablony.Domyślnie Struts 2 dostarcza znaczników dla takich języków jak JSP, Velocity czy

FreeMarker. Szablony, najczęściej tworzone z wykorzystaniem biblioteki FreeMarker, sągrupowane w motywy (ang. theme) w celu zwiększenia ich funkcjonalności. Istnieją rów-nież znaczniki zaprojektowane do tworzenia formularzy.Standardowa dystrybucja opisywanego szkieletu, dostarcza szablony generujące stro-

ny oparte o język XHTML, wykorzystujące kaskadowe arkusze stylów bądź używającetechnologii AJAX [25]. Możliwe jest również skorzystanie z prostego szablonu, który wy-korzystuje proste elementy HTML-a, jednak bez wsparcia dla walidacji, raportowaniao błędach czy pomocy w formatowaniu treści.

3.1.3. Interceptory

Wiele z użytych w aplikacji akcji wymaga zastosowania wspólnych rozwiązań. Przy-kładowo wiele akcji wymaga walidacji danych wprowadzonych przez użytkownika bądźprzeprowadzenia wstępnej obróbki pliku umieszczanego na serwerze. Na osobną uwagęmoże zasługiwać problemem związany z podwójnym wysłaniem danych.Idea interceptorów wprowadza rozwiązanie pozwalające na współdzielenie rozwiązań,

dotyczących wspomnianych wcześniej czynności. Podczas wysłania żądania, przed wyko-naniem głównej akcji, następuje wywołanie metod ciągu obiektów. Podobna możliwość,w razie zaistnienia takiej potrzeby, jest możliwa po wywołaniu akcji głównej.Większość funkcjonalności dostarczanych ze szkieletem Struts 2 jest zaimplementowa-

nych w postaci interceptorów. To wspomnianych funkcjonalności można zaliczyć: problempodwójnego wysłania danych, konwersję typów, automatyczne wyświetlanie własnościobiektów, walidację, wsparcie w umieszczaniu plików na serwerze czy przygotowanie stro-

45

ny do wyświetlenia. Każdego z interceptorów wykorzystywanych do wymienionych zadańmożna dowolnie wyłączyć.Domyślny cykl wywołań interceptorów przedstawia się w sposób następujący:

1. Obiekt ServletDispatcher tworzy instancję nowego obiektu ActionProxy i wywołujejego metodę execute().

2. Poszczególne interceptory przechwytują żądanie wysłane do głównej akcji oraz powra-cające z niej. Za drugim razem ciąg wywołań interceptorów jest odwrotny w stosunkudo pierwszego wywołania.

3. Kiedy ciąg wywołań interceptorów ulegnie zakończeniu, żądanie przesyłane jest doobiektu Result w celu wygenerowania odpowiedzi.Konfiguracja interceptorów odbywa się w pliku konfiguracyjnym struts.xml z wyko-

rzystaniem języka XML. Możliwe jest łączenie interceptorów, implementujących określonąwspólną funkcjonalność , z wykorzystaniem elementu zwanego Interceptor Stack. Domyśl-ny stos interceptorów jest wystarczający do działania większości aplikacji.

3.1.4. Implementacja wzorca MVC

Struts 2 stanowi przykład szkieletu programistycznego implementującego wzorzec Mo-del-Widok-Kontroler. Dostarcza obiektów kontrolerów, komponentów widoku oraz zapew-nia wsparcie w zakresie integracji z innymi technologiami operującymi na modelu.W celu efektywniejszego wyświetlania dynamicznych danych, szkielet oferuje wsparcie

w postaci znaczników. Rola znaczników polega na interakcji z frameworkiem i zapewnieniuwalidacji oraz internacjonalizacji wprowadzanych i wyświetlanych danych. Wspomnianeznaczniki mogą być wykorzystane z technologiami stron JSP czy szablonami FreeMa-ker bądź Velocity. Możliwe jest również wykorzystanie znaczników JSTL oraz technologiiAJAX. Ponadto Struts 2 oferuje wsparcie podczas użycia komponentów JavaServer Faces.Po otrzymaniu żądania przez kontroler, wywoływana jest odpowiednia akcja, która

przeprowadza aktualizację modelu. Podczas transferu danych z modelu do widoku, mogązostać wykorzystane własności akcji bądź obiekty JavaBean. Szkielet zapewnia wsparciew zakresie transformacji, tekstowej postaci własności przedstawionych jako pola formula-rza HTML do własności obiektów domeny.

3.2. Spring MVC

Niniejsza sekcja stanowi wprowadzenie do biblioteki Spring MVC, jako iż została onawybrana jako biblioteka przeznaczona do badań, znacząca część informacji jest umiesz-czona w dalszych rozdziałach.Działanie frameworka Spring MVC [48], części biblioteki Spring Framework imple-

mentującej Model 2, skupiona jest wokół obiektu DispatcherServlet, który przetwarzanadchodzące żądania i wywołuje odpowiednie kontrolery w celu ich obsłużenia.Jedną z zasad projektowych, stosowanych przy implementacji opisywanego szkieletu

jest otwartość na rozszerzalność (ang. extension) przy jednoczesnej zamkniętości na zmia-ny. Wspomniana zasada została zaimplementowana poprzez zastosowanie słowa kluczo-wego final na wielu jego klasach. Świadomą decyzję autorów wprowadzającą opisywanąmetodę, wyjaśnia artykuł [49].Spring MVC promuje użycie obiektów biznesowych podczas interakcji z formularza-

mi. Błędy związane z walidacją wprowadzanych danych stara się rozwiązać na poziomieaplikacji. Zwracany przez kontroler obiekt modelu powiązany z wybranym widokiem nosi

46

nazwę ModelAndView. Jest to mapa poszczególnych obiektów modelu przekazywanych dowidoku.Jedną z zalet opisywanego szkieletu jest jego integracja z biblioteką Spring Frame-

work, która dostarcza rozwiązania dla warstwy środkowej architektury trójwarstwowej.Do kluczowych funkcjonalności szkieletu Spring MVC należy:— separacja ról kontrolera, modelu, widoku, walidatora – każdej z ról odpowiada osobnywyspecjalizowany w działaniu obiekt,

— możliwość ponownego użycia kodu związanego z logiką biznesową aplikacji poprzezunifikację obiektów biznesowych z obiektami formularzy,

— konfigurowalność bindowania obiektów i ich walidacji,— przygotowany zestaw znaczników JSP.Ponadto możliwe jest wykorzystanie biblioteki Spring Web Flow, której rola polega nazarządzaniu nawigacją między poszczególnymi stronami, z zachowaniem stanu pomiędzywywoływaniami kolejnych stron.

3.2.1. Obiekt nadzorujący

Opisywany framework implementuje Model 2, oparty na przetwarzaniu kierowanychdo aplikacji żądań użytkownika. Rola obiektu DispatcherServlet polega na scentralizo-wanym przetwarzaniu nadchodzących żądań jak również oferowaniu innego wsparcia dlatworzenia aplikacji internetowych, poprzez wykorzystanie modułu Spring IoC, do któregoma dostęp.DispatcherServlet implementuje wzorzec zwany Front Controller, który oddelego-

wuje żądanie do odpowiedniego kontrolera, który w rezultacie swojego działania zwracaobiekty modelu wraz z wybranym widokiem.Więcej informacji na temat prezentowanego obiektu można znaleźć w następnym ro-

dziale, szczegółowo opisującym framework Spring MVC.Szczegóły konfiguracyjne standardowo umieszczone są w pliku o nazwie, będącej po-

łączeniem nazwy opisywanego pliku, zdefiniowanego w pliku web.xml oraz przyrostka-servlet.xml. Przykładowo dla obiektu dispatchera noszącego nazwę golfing, plik kon-figuracyjny aplikacji opartej o Spring MVC będzie nosił nazwę golfing-servlet.xml.We wspomnianym pliku konfiguracyjnym możliwe jest zdefiniowanie obiektów Springa

zwanych beans, tj.:— obiekty kontrolerów,— obiekty odpowiedzialne za wybór określonego kontrolera po odebraniu żądania skiero-wanego do aplikacji przez użytkownika, zwane handler mappings,

— obiekty które tłumaczą nazwy widoków do plików zawierających żądany szablon, naj-częściej w postaci pliku JSP, zwane view resolvers,

— obiekty umożliwiające internacjonalizację serwowanej strony, zwane locale resolvers,— obiekty pozwalające na szybką zmianę wystroju strony, zwane theme resolver,— ponadto istnieje możliwość zdefiniowania obiektów odpowiedzialnych za odbieranienadesłanych, za pomocą formularza plików (multipart file resolvers) czy obiekty prze-chwytujące wyjątki aplikacji (handler exception resolvers).

Lista obejmuje jedynie ziarna charakterystyczne dla warstwy widoku implementowanejz użyciem biblioteki Spring MVC. Obiekt DispatcherServlet posiada ponadto możli-wość, zwracania atrybutu last-modification-date, opisanego w specyfikacji Servlet API,zwracającego datę ostatniej modyfikacji żądanego zasobu.Definicje opisanych obiektów przechowywane są we wspomnianym pliku konfiguracyj-

nym, który posiada również odpowiednik w postaci klasy Java o nazwie specyficznej dla

47

aplikacji internetowej WebApplicationContext. Każda z instancji obiektu nadzorującegoposiada własną kopię wspomnianego obiektu, którego obiektu automatycznie dziedzicząpo obiektach zdefiniowanych domyślnie.WebApplicationContext stanowi rozszerzenie standardowego kontekstu aplikacji no-

szącego nazwę ApplicationContext, wzbogacony o elementy przydatne podczas działa-nia aplikacji internetowej, np. zmienianie motywu wyglądu.

3.2.2. Znaczniki

Począwszy od wersji 2.0 biblioteki Spring Framework wprowadzono zbiór znaczników,ułatwiających pracę nad tworzeniem szablonów. Generowany, przez bibliotekę, kod znacz-ników jest zgodny z specyfikacją HTML 4.01/XHTML 1.0.Działanie wszystkich znaczników jest podobne. Spring MVC posiada odpowiedniki

następujących znaczników znanych ze specyfikacji HTML: form, input (checkbox, radio,password), select, option, textarea. Ponadto posiada znacznik errors służący dowyświetlania błędów związanych z przetwarzaniem formularza.Zastosowanie znaczników dostarczanych wraz ze Springiem ułatwia przede wszystkim,

operowaniu ma obiektach formularza. Przykładowo formularz umieszczony na listingu 3.2,powoduje automatyczną obsługę obiektu user przekazanego widokowi przez kontroler.

�1 <form:form commandName="user">2 <table>3 <tr>4 <td>Imie:</td>5 <td><form:input path="firstName" /></td>6 </tr>7 <tr>8 <td>Nazwisko:</td>9 <td><form:input path="lastName" /></td>10 </tr>11 <tr>12 <td colspan="3">13 <input type="submit" value="Zapisz zmiany" />14 </td>15 </tr>16 </table>17 </form:form>� �

Listing 3.2: Zastosowanie znacznika form biblioteki Spring MVC

Znaczniki dodatkowo wprowadzają rozróżnienie poszczególnych elementów formularzy.W specyfikacji HTML duża część znaczników stosowanych przy formularzy nosi po pro-stu nazwę input, dopiero atrybut type, wprowadza rozróżnienie na pola typu password,radio czy checkbox. Spring MVC zawiera intuicyjne nazwy dla każdego ze wspomnia-nych wcześniej elementów.Innym elementem związanym z zastosowaniem znaczników jest obsługa pól typu checkbox,

które mogą być mapowane w zależności od potrzeb do zmiennych logicznych, kolekcji bądźobiektów.

48

3.2.3. Zasada konwencji

Jedną z nowości drugiego wydania biblioteki Spring, było wprowadzenie elementów,które wykorzystują określone konwencje względem konfiguracji (ang. convention over con-figuration). Jest to wzorzec, który propaguje określony porządek rzeczy, wynikiem czegojest znacznie uproszczona konfiguracja lub często pozbycie się jej całkowicie. Podobnyzabieg można zauważyć w opisanej wcześniej bibliotece Maven.Pierwsza z opisywanych konwencji dotyczy nazewnictwa dla kontrolerów przy odbie-

raniu żądań. Przykładowo kontroler noszący nazwę WelcomeController będzie odpowie-dzialny za odbieranie żądań pasujących do wyrażenia URL ’/welcome*’.Kolejna konwencja dotyczy nazewnictwa dla przekazywanego do widoku modelu. Przy-

kładowo obiekt reprezentowany przez klasę User, będzie dostępny w szablonie widoku podnazwą user, a lista kotów (obiektów typu Cat), zaimplementowana w postaci ArrayListbędzie nosiła nazwę catList.Ostatnia z proponowanych konwencji dotyczy powiązania nazwy kontrolera, obsługu-

jącego żądanie z widokiem. Kontroler posiadający uzgodnioną przez konwencję, nazwęRegistrationController, będzie domyślnie używał szablonu widoku o nazwie registra-tion, co w połączeniu z innymi elementami konfiguracyjnymi prowadzi do uzyskania wi-doku znajdującego się w następującej lokalizacji ’/WEB-INF/jsp/registration.jsp’.

3.3. Tapestry 5

Tapestry jest przedstawicielem frameworków, stosujących model komponentowy pod-czas tworzenia warstwy prezentacji. Wprowadza podział aplikacji internetowej na poszcze-gólne strony, składających się z komponentów. Biblioteka odciąża użytkownika od sprawzwiązanych z zarządzaniem adresami URL, zajmuje się utrzymaniem stanu zarządzanychobiektów, zarówno po stronie serwera jak i klienta. Tworzenie aplikacji sprowadza się dotworzenia szablonów oraz wsparcia ich w postaci kodu języka Java. Programista używa-jący Tapestry operuje pojęciami obiektów, ich metod oraz własności, tworząc abstrakcjęobejmującą adresy URL czy parametry żądania.Udostępniona wersja biblioteki nosi numer 4, opisywana wersja 5 [56] wciąż jest w fazie

rozwoju. Planowane wydanie wersji jest zapowiadane na jesień 2007 roku. W wersji 5w stosunku do wersji poprzedniej wprowadzono następujące zmiany:— nie jest wymagane rozszerzanie klas szkieletu przez klasy komponentów,— klasy komponentów nie są klasami abstrakcyjnymi, lecz zwykłymi obiektami Javy,— zastąpiono konfigurację w postaci plików XML, adnotacjami umieszczanymi w kodziejęzyka Java,

— zmiany dokonywane na komponentach mają natychmiastowe odzwierciedlenie w dzia-łającej aplikacji, nie jest wymagany restart serwera,

— zwiększono szybkość działania samej biblioteki.Wprowadzone zmiany mają głównie za zadanie zwiększenie produktywności uzyskiwanejw pracy z opisywaną biblioteką oraz naprawiają błędy zgłaszane przez użytkownikówpoprzedniej wersji (obowiązek dziedziczenia w klasach komponentów).Działanie opisywanej biblioteki zostało zweryfikowane na serwerach Jetty, w wersji 5,

6 oraz Tomcat w wersji 5.5.20.

49

3.3.1. Zasady

Celem autora biblioteki jest utrzymanie wysokiej skalowalności tworzonego systemu.Możliwe jest to do osiągnięcia poprzez zastosowanie zasady statycznej struktury orazdynamicznego zachowania.Idea statycznej struktury została wyrażona poprzez wykorzystanie statycznych stron

szablonów, rozwiązanie korzystne w momencie tworzenia puli stron. Raz utworzona stronajest przechowywana w puli stron gotowa do ponownego użycia. Możliwe jest wykorzystaniedowolnego serwera do przetworzenia żądania, w przypadku użycia klastra. W porównaniudo JavaServer Faces strona jest mniej dynamiczna, konsekwencją tego jest mniejsza ilośćdanych przechowywanych w sesji, co w rezultacie daje większą skalowalność.Różnicą w stosunku do poprzedniej wersji jest wprowadzenie separacji między API

publicznym a prywatnym biblioteki Tapestry. Stosowane uprzednio dziedziczenie spra-wiało iż klasy komponentów były nieumyślnie wzbogacone o zbędne dla nich metody.Rozwiązaniem okazało się wprowadzenie interfejsów. Klasy znajdujące się w pakiecieorg.apache.tapestry.internal stanowią wewnętrzne API biblioteki.Tapestry w nadchodzącej wersji będzie bazowało wyłącznie na klasach języka Java

oraz adnotacjach. Za pomocą adnotacji będzie możliwe zarządzanie stanem obiektów czywstrzykiwaniem zasobów.

3.3.2. Moduły

Autorzy Tapestry 5, korzystają z Mavena podczas tworzenia swojej aplikacji. Pośredniąkonsekwencją takiego wyboru jest zdefiniowanie modułów, będących częścią frameworka,posiadających ściśle określone zadania. Lista modułów wraz z krótkim opisem przedstawiasię następująco:— tapestry-core, główna część biblioteki Tapestry, zawierająca wszystkie najważniejszeelementy potrzebne przy korzystaniu z niej,

— tapestry-hibernate, moduł odpowiedzialny za integrację z biblioteką Hibernate,— tapestry-ioc, kontener odwróconego sterowania, wykorzystywany przez moduł core,— tapestry-spring, moduł odpowiedzialny za integrację z biblioteką Spring Framework,— tapestry-test, narzędzia związane z przeprowadzaniem testów.W chwili obecnej (kwiecień 2007) najbardziej zaawansowany stan wykazują moduły

tapestry-core oraz tapestry-ioc.

Tapestry-core

Tapestry-core zapewnia interfejsy oraz adnotacje składające się na bibliotekę Tape-stry 5. Podczas działania wykorzystuje moduł tapestry-ioc. Opisywany moduł wprowa-dza pojęcie adaptacyjnego API. Podczas programowania z wykorzystaniem tradycyjnegoszkieletu programistycznego, użytkownik musi wpasować się niejako w struktury oferowa-ne przez dany framework, poprzez dziedziczenie czy implementację określonej klasy bądźinterfejsu. Tapestry wprowadza adaptacyjność poprzez wykorzystanie adnotacji języka Ja-va sprawiając, iż programista może dowolnie nazywać tworzone metody bądź parametry.Listing 3.3 prezentuje przykład komponentu wykorzystywanego na stronie z logowa-

niem użytkownika. Dla przejrzystości kodu, zrezygnowano z metod ustawiających i mo-dyfikujących. Używane strony oraz serwisy wstrzykiwane są za pomocą adnotacji Inject.Adnotacja OnEvent znaczy metodę która ma zostać wywołana w przypadku wysłaniaprzez stronę zdarzenia o nazwie submit. W przypadku otrzymania wspomnianego zda-rzenia, komponent sprawdza wprowadzony identyfikator i hasło, wykorzystując serwis

50

�1 public class Login2 {3 @Persist4 private String userId;5 private String password;6 @Component7 private Form form;8 @InjectPage9 private Start startPage;10 @Inject11 private LoginAuthenticator authenticator;12

13 @OnEvent("submit")14 private Object doLogin()15 {16 if(authenticator.isValidLogin(userId, password))17 return _startPage;18 form.recordError("Niepoprawny login badz haslo");19 return null;20 }21 }� �

Listing 3.3: Komponent logowania wykorzystujący bibliotekę Tapestry 5

authenticator. W przypadku poprawnych danych użytkownik zostaje przeniesiony dostrony startowej, w przeciwnym przypadku następuje wyświetlenie komunikatu o wpro-wadzeniu niepoprawnych danych.Ważnym uwaga dotyczy separacji przetwarzanej akcji oraz renderowania strony, z wy-

korzystaniem osobnych żądań. Przykładowo wciśnięcie przez użytkownika przycisku wy-syłającego formularz, powoduje przekierowanie użytkownika na nową stronę. Opisanezdarzenie redirect after post sprawia, iż adres w oknie przeglądarki ulega zmianie podokonaniu akcji wysłania formularza. Poprawia to użyteczność strony, gdyż każda stronajest identyfikowana przez indywidualny adres URL. Konsekwencją użycia podwójnegożądania jest konieczność użycia adnotacji Persist, która sprawia iż oznaczona własność,jest składowana w sesji między żądaniami.Tapestry-core definiuje również zbiór gotowych do użycia komponentów. W obecnie

zaimplementowanym zbiorze znajdują się komponenty związane z obsługą pól formularza,linków, raportowaniem błędów oraz wyświetlaniem obrazków. Z wykorzystaniem ostatniododanego komponentu grid można tworzyć stronicowane listy wraz z sortowaniem pokolumnach.

Tapestry-ioc

Wnętrze biblioteki Tapestry 5 bazuje na wzorcu odwróconego sterowania, pozwalają-cego na budowaniu aplikacji z niewielkich części posiadających ściśle określone zadania.Rozwiązanie takie sprawia iż poszczególne części aplikacji można łatwiej modyfikowaćbądź rozszerzać, poprzez zastępowanie bądź nadpisywanie dotychczas istniejących.Śledząc zmiany frameworka, począwszy od wersji 3, można zauważyć postępujące zmia-

ny w stosowaniu wzorca odwróconego sterowania. Tapestry 3 praktycznie nie używało

51

opisywanego wzorca, kolejna wersja wprowadziła kontener HiveMind. Tapestry 5 zrezy-gnowało z wykorzystania biblioteki HiveMind na rzecz dedykowanego rozwiązania.Podczas gdy obecnie stosowane kontenery IoC, takie jak HiveMind czy Spring, używają

konfiguracji wyrażającej zależność poszczególnych elementów z wykorzystaniem XML-a,Tapestry wykorzystuje w tym celu adnotacje użyte wprost w kodzie języka Java.Wprowadzenie do aplikacji wzorca odwróconego sterowania pozwala na wprowadzenie

zasady podziału odpowiedzialności, rozdziału ról oraz ogranicza powiązania poszczegól-nych komponentów systemu.Podstawową jednostką wykorzystywaną w Tapestry IoC jest usługa (ang. service).

Każdy z serwisów składa się z interfejsu oraz jego implementacji. Usługi są identyfiko-wane za pomocą unikalnych identyfikatorów (id), standardowo id usługi jest tożsamez niekwalifikowaną nazwą interfejsu usługi.Poszczególne serwisy są grupowane w moduły. Definicję modułów wprowadzają bu-

downiczowie modułów (ang.module builders), którzy za pomocą metod statycznych i obiek-tu definiuję poszczególne serwisy, dekorują oraz wprowadzają do konfiguracji serwisów.Metody konfigurujące serwisy noszą nazwę service builder methods.Rejestr (ang. registry) stanowi magazyn modułów i serwisów. Za pomocą identyfikato-

ra jest możliwość pobrania wybranego serwisu. Metody serwisów mogą być dekorowane,wprowadzając aspekty związane z logowaniem, bezpieczeństwem czy transakcyjnością.Istnieje możliwość dodatkowej konfiguracji serwisów, z wykorzystaniem map lub kolekcji.Serwisy są inicjalizowane w razie potrzeby, domyślnie są reprezentowane w postaci

proxy, które implementuje wskazany interfejs serwisu. Podczas pierwszego wywołania,serwis jest tworzony i zwracany. Domyślnym cyklem życia dla serwisów jest singleton.

3.4. JavaServer Faces

JavaServer Faces [22] stanowi framework, którego celem jest uproszczenie tworzeniainterfejsu użytkownika na platformie JEE. Standardowo JSF używa stron JSP jako tech-nologii widoku, jest jego rozwinięciem. Możliwa jest jednak integracja z inną technologiąwidoku np. XUL [63]. Szkielet obsługuje cykl życia aplikacji internetowej z wykorzysta-niem technologii serwletów.JavaServer Faces w zamierzeniach autorów specyfikacji ma stać się odpowiednikiem

Swinga dla systemów internetowych, umożliwiając tworzenie aplikacji z wykorzystaniemgotowych komponentów. Możliwe jest również wykorzystanie znaczników wchodzącychw skład biblioteki JSTL.Najpopularniejszą implementacją specyfikacji JSF jest biblioteka MyFaces, implemen-

tująca specyfikację JSR 127. Bezpośrednią konkurencją dla JSF są aplikacje napisanew technologii .NET.

3.4.1. Specyfikacja

JavaServer Faces stanowi jedynie specyfikację, która jest implementowana przez po-szczególnych dostawców. Najważniejsze warunki wymagające spełnienia, przedstawia po-niższy spis:— Szkielet aplikacji posiadający standardowe komponenty interfejsu użytkownika, z moż-liwością ich edycji w zewnętrznym programie.

52

— Zbiór klas języka Java posiadających odzwierciedlenie w komponentach interfejsu użyt-kownika, ich stanów, czy zdarzeń generowanych przez użytkownika. Rolą obiektówwspomnianych klas jest zarządzanie cyklem życia komponentów.

— Zastosowanie obiektów JavaBean do przesyłania zdarzeń generowanych po stronieklienta a akcją po stronie serwera.

— Interfejs programistyczny umożliwiający walidację danych wejściowych.— Wsparcie w zakresie internacjonalizacji aplikacji.— Automatyczne generowanie stanu oraz wyglądu aplikacji w zależności od używanejprzez klienta przeglądarki.

— Zachowanie zasad użyteczności oraz dostępności definiowanych przez WAI [61].Specyfikacja JSF jest tworzona w ramach procesu Java Community Process oznaczonegosygnaturą JSR 127, definiującą wersję 1.0 oraz 1.1. Najnowszą wersję 1.2, wydaną w maju2006 roku definiuje proces JSR 252.

3.4.2. Architektura

Poniższa sekcja zawiera wyłącznie wprowadzenie do architektury aplikacji opartej o Ja-vaServer Faces. Więcej szczegółów znajduje się w kolejnym rozdziale.Do najważniejszych zadań składowych elementów szkieletu JavaServer Faces należą:

reprezentacja komponentów użytkownika oraz obsługa ich stanów, obsługa generowanychzdarzeń, zapewnienie walidacji po stronie klienta oraz serwera, konwersja typów pomiędzyformularzami a obiektami Javy, definiowanie nawigacji pomiędzy stronami, obsługa inter-nacjonalizacji, wsparcie w zakresie rozszerzania możliwości aplikacji (nowe komponenty).JSF zawiera w sobie dwie biblioteki znaczników, służące tworzeniu komponentów

umieszczonych na stronach JSP jak i służących powiązaniu stanu komponentów do obiek-tów po stronie serwera.Typowymi składowymi aplikacji opartej o szkielet JSF są komponenty interfejsu użyt-

kownika, biblioteka znaczników pomocnych przy tworzeniu, obiektów przechwytującychzdarzenia bądź walidatorów, tzw. managed beans tworzące powiązanie pomiędzy obiekta-mi aplikacji i interfejsu, obiekty konfiguracji aplikacji oraz pozostałe takie jak walidatoryczy konwertery.W typowym scenariuszu obsługi żądania, żądanie po dotarciu do kontenera serwletów

wywołuje odpowiednią akcję, która jest przetwarzana z wykorzystaniem odpowiednichkomponentów strony, które wraz ze wspierającymi je obiektami Javy, zwracają odpowiedź.Standardowo zdefiniowane komponenty posiadają odpowiednik większości istotnych

znaczników dostępnych w specyfikacji HTML. Możliwe jest również napisanie własnychkomponentów, w celu realizacji skomplikowanego elementu interfejsu użytkownika.Komponenty JSF wykorzystują podczas działania kompozycję, przykładowo wybór

dnia w postaci kalendarza składa się z trzech rozwijanych list, pozwalających wybraćkolejno dzień, miesiąc i roku.

3.4.3. Składowe

Warstwa widoku oparta jest domyślnie na stronach JSP, do ich wyświetlania wymaga-ny jest obiekt ViewHandler, którego implementacja jest dostarczana przez poszczególnychdostawców.Składowymi stron są komponenty. Do zadań domyślnie wyznaczonych komponentom

należą: wyświetlanie siebie, obsługa otrzymywanych zdarzeń oraz walidacja wprowadza-nych przez użytkownika danych.

53

Wiązanie obiektów z widokiem realizowane jest z wykorzystaniem języka wyrażeń(EL), którego zadaniem jest łączenie obiektów JavaBean z kodem strony JSP. Listing 3.4przedstawia różne formy wiązania obiektów.�

1 <!-- wiazanie wlasnosci obiektu -->2 <h:inputText value="#{user.name}" />3

4 <!-- wiazanie z metoda w polaczeniu z walidacja -->5 <h:inputText id="userId" value="#{User.id}" validator="#{User.validate}" />6

7 <!-- wiazanie nawigacji miedzy stronami -->8 <h:commandLink action="#{Nawigacja.nastStrona}">� �Listing 3.4: Wiązanie obiektów Javy z wykorzystaniem języka Unified Expression Language

Obsługa zdarzeń możliwa jest na dwa sposoby. Jeden polega na implementacji interfej-su Listener oraz użyciu odpowiedniego znacznika. Drugi sposób polega na implementacjimetody w obiekcie JavaBean i późniejszym odwołaniu się do niego przez własność kom-ponentu.Definiowanie nawigacji między stronami odbywa się w pliku konfiguracyjnym z wy-

korzystaniem składni języka XML. Standardowo definiowana jest strona do wczytaniaw przypadku powodzenia przetworzenia żądania oraz strona wejściowa.Walidacja jest możliwa zarówno po stronie serwera jak i klienta, z użyciem standar-

dowych walidatorów bądź zdefiniowanych przez użytkownika.

3.4.4. Implementacja wzorca MVC

JavaServer Faces stosuje model komponentowy, wzbogacając tradycyjny Model 2. Opi-sywana biblioteka pozwala na zbudowanie abstrakcji nad żądaniami protokołu HTTPi oparciu aplikacji o komponenty i generowane z ich wykorzystaniem zdarzenia.JSF modyfikuje architekturę prezentowaną przez Model 2, pozwalając na łatwiejszą

separację logiki biznesowej oraz prezentacji poza obręb kontrolera oraz wyodrębnieniulogiki biznesowej poza strony JSP.W implementacji wzorca MVC, stosowanej przez bibliotekę JSF, ziarna zarządzane

(ang. managed beans) pośredniczą pomiędzy widokiem a modelem. Z tego powodu należydbać o ograniczenie ich roli w zakresie implementacji logiki biznesowej aplikacji czy logikązwiązaną z utrwaleniem danych. Jedną z alternatyw jest przesunięcie logiki biznesowejdo modelu aplikacji, w tym scenariuszu zarządzane ziarna są również odpowiedzialne zamapowanie obiektów modelu do widoku, gdzie mogą zostać wyświetlone.W odróżnieniu do technologii JSP, widok implementowany w postaci stron JSF jest

stanowy, składa się z dwóch części: widoku korzenia oraz stron JSP. Korzeń składa się zezbioru komponentów, zarządzających stanem interfejsu użytkownika, podobnie jak Swingczy AWT. Zadaniem strony JSP jest połączenie komponentów ze stronami JSP oraz stwo-rzeniu możliwości interakcji pomiędzy polami komponentów a ziarnami wspierającymi(ang. backing beans).

54

4. Porównanie Spring MVC oraz JavaServerFaces

Celem poniższego rozdziału jest analiza porównawcza funkcjonalności oferowanej przezwybrane szkielety programistyczne. W porównaniu zostały uwzględnione framework SpringMVC oraz standard platformy JEE, JavaServer Faces.Rozdział został podzielony na pięć części, w każdej został opisany osobny aspekt dzia-

łania badanych szkieletów programistycznych. Pierwsza część zawiera charakterystykęarchitektury. W następnej opisano model programistyczny, czyli czynności wykonywaneprzez programistę tworzącego aplikację internetową, z uwzględnieniem sposobu definicjiprzejść między stronami. W kolejnej przedstawiono cykl życia nadchodzącego do apli-kacji żądania oraz jego obsługę w ramach przedstawianych frameworków. W następnejkolejności opisano sposoby walidacji danych wprowadzanych przez użytkownika oraz ichkonwersję na typy języka Java. Tematem ostatniej części jest internacjonalizacja i lokali-zacja aplikacji.

4.1. Architektura

Poniższa część skupia się na opisie elementów składowych opisywanych szkieletówprogramistycznych, interakcji jakie zachodzą między nimi oraz wyjaśnia ich przeznaczeniana tle całego systemu.

4.1.1. Spring MVC

Warstwa prezentacji implementowana przez framework Spring MVC wpasowuje sięw większy obraz aplikacji tworzonej z użyciem szkieletu Spring Framework [10]. Kontroleryodpowiedzialne za zarządzanie modelem aplikacji komunikują się z użyciem usług, niemają bezpośredniego dostępu do modelu aplikacji.Rysunek 4.1 prezentuje architekturę szkieletu Spring MVC. Jak wspomniano we wcze-

śniejszych rozdziałach, opisywany framework realizuje implementację Modelu 2, wykorzy-stując wzorzec projektowy MVC. Dostęp do modelu jest realizowany z wykorzystanimusług zdefiniowanych w warstwie biznesowej. Dostępem do widoku zajmują się obiektyzwane resolverami. Pozostałe elementy, takie jak walidatory czy elementy internacjonali-zujące, uważane często za składowe szkieletów implementujących wzorzec MVC, zostałyzdefiniowane w innym warstwach Springa.Typowa aplikacja realizowana z wykorzystaniem szkieletu Spring Framework składa

się z pięciu warstw, zgrupowanych w trzy inne warstwy wyższego poziomu:— interfejsu użytkownika,— webowej,— usług,— obiektów domeny,— utrwalania.

55

Rysunek 4.1: Architektura szkieletu Spring MVC

Interfejs użytkownika wraz z warstwą webową należą do najwyższej warstwy wyższegopoziomu. Warstwa usług i obiektów domeny mieszczą się w warstwie środkowej. Na samymdole znajduje się warstwa związana z utrwalaniem modelu aplikacji. Obiekty warstwydomeny jako jedyne są rozproszone po pozostałych warstwach.Separacja poszczególnych warstw sprzyja zwiększeniu elastyczności aplikacji oraz uła-

twia ich testowanie. Najlepszą metodą jest zapewnienie aby poszczególne warstwy posia-dały zależności wyłącznie w warstie znajdującej się bezpośrednio pod nią.Rolą warstwy interfejsu użytkownika jest prezentacja wizerunku aplikacji użytkowni-

kowi końcowemu. Zwraca odpowiedź wygenerowaną przez warstwę niższą w formie żądanejprzez użytkownika. Odpowiedź zwracana użytkownikowi telefonu komórkowego jest przed-stawiana zwykle za pomocą języka WML, natomiast użytkownik komputera stacjonarnegooczekuje strony interpretowalnej za pomocą przeglądarki, najczęściej strony HTML.Warstwa interfejsu użytkownika sprawia, iż możliwa jest zamiana używanych technolo-

gii widoku, począwszy od wyboru stron JSP, szablonów Velocity a kończąc na transforma-cjach XSLT [21]. Innym ważnym aspektem jest odmienność narzędzi wykorzystywanychpodczas tworzenia opisywanej warstwy, co wiąże się ze specjalizacją ról osób nad niąpracujących.Strona związana z warstwą interfejsu jest reprezentowana przez interfejs View, jest to

element posiadający całkowice generyczny charakter, nie związany z żadną z technologiiwidoku. Spring standardowo dostarcza wsparcie dla stron w postaci: JSP, szablonów Ve-locity, FreeMaker, XSLT, JasperReports oraz plików PDF. Obiekt Resolver wprowadzaużyteczną abstrakcję związaną z wyborem widoku dla serwowanej odpowiedzi.Głównym zadaniem warstwy webowej jest zapewnienie poprawnej nawigacji w apli-

kacji, poprzez wykorzystanie obiektu Handler, przedstawionego na rysunku 4.1. Dru-gim zadaniem opisywanej warstwy jest zapewnienie komunikacji pomiędzy warstwą usługa protokołem HTTP, reprezentowanym poprzez parametry żądania czy pliki ciasteczek(ang. cookies). Warstwa webowa jest implementowana przeważnie z użyciem serwletów,których rola polega na transformacji parametrów żądania do obiektów języka Java, zrozu-miałych przez warstwę usług, jak również zamianie błędów warstw niższych na zrozumiałedla użytkownika komunikaty.Interfejsem używanym w opisywanej warstwie dostarczanym wraz z Springiem jest

Controller. Rolą wspomnianego interfejsu jest odbiór żądania i wygenerowanie na je-go podstawie odpowiedzi. Odpowiedź jest prezentowana przez obiekt ModelAndView, za-

56

Rysunek 4.2: Architektura szkieletu JavaServer Faces

wierający widok oraz mapę danych wykorzystywanych poprzez warstwę interfejsu przyformatowaniu odpowiedzi.

4.1.2. JavaServer Faces

Rysunek 4.2 przedstawia poszczególne komponenty składające się na architekturę bi-blioteki JavaServer Faces. Trzon frameworka składa się z sześciu różnych warstw, o ściślewyznaczonym przeznaczeniu.Głównym zadaniem warstwy komponentów interfejsu jest definicja funkcjonalności

jakie oferują dostępne na stronie elementy. Składa się z obiektów JavaBean reprezentują-cych różne własności poszczególnych komponentów. Istniejąca klasa abstrakcyjna wspólnadla wszystkich elementów interfejsu definiuje zachowanie i stan, który jest przestrzeganyprzez każdy z komponentów potomnych. Każdy z komponentów posiada swój identyfi-kator, zmienne lokalne oraz pewien zbiór atrybutów generycznych. Ich zachowanie jestdefiniowane za pomocą zdarzeń, poprzez które zostają związane z modelem zdarzeń. Każ-dy z elementów interfejsu użytkownika może zostać dodatkowo powiązany z wymiennymiwalidatorami, których zadaniem jest weryfikacja danych podanych przez użytkownika,przed wywołaniem właściwej logiki aplikacji.W skład komponentów użytkownika zdefiniowanych w specyfikacji JavaServerPages

można znaleźć komponenty odpowiedzialne za generowanie zdarzeń, np. poprzez naciśnię-cie przycisku wysyłającego dane formularza, komponenty związane z obsługą formularzy,wyświetlaniem rysunków, pobieraniem danych od użytkownika, wyświetlające dane czyformatujące wygląd strony.Model wyglądu definiuje sposób renderowania poszczególnych komponentów interfejsu

użytkownika. Każdy z komponentów umieszczonych w aplikacji może posiadać inny wy-gląd w zależności od wykorzystywanych obiektów renderujących. Przykładowo elementSubmit wysyłający dane formularza, może zostać przedstawiony albo za pomocą przyci-sku albo z wykorzystaniem linka. Opisywane rozwiązanie wprowadza separację zachowaniai funkcji komponentu od jego wyglądu. Możliwe jest przez podmianę obiektów renderują-cych wyświetlenie aplikacji zarówno na ekranie komputera, z użyciem języka HTML, jaki na ekranie telefonu komórkowego, posługując się językiem WML. Opisywane obiektyrenderujące pełnią podobną funkcję co XSLT w przypadku dokumentów XML.

57

Model zdarzeń funkcjonujący w aplikacjach opartych o JavaServer Faces, jest podobnydo tego oferowanego przez obiekty JavaBean. Definiuje zdarzenia oraz obiekty nasłuchu-jące, które są odpowiedzialne za odbiór zdarzenia wygenerowanego z użyciem pewnegokomponentu interfejsu użytkownika. Obiekt zdarzenia posiada informację o komponencie,będącym źródłem zdarzenia oraz dane związane z samym zdarzeniem. Aby obiekt zainte-resowany pewnym zdarzeniem mógł podjąć akcję w momencie jej wywołania, koniecznejest dokonanie jego rejestracji w obiekcie generującym zdarzenie. W momencie aktywacjizdarzenia, np. poprzez naciśnięcie przycisku, wszystkie zgłoszone metody nasłuchujące sąwywoływane. Opisywany model jest kopią zachowania dostępnego w aplikacjach Swingo-wych i opiera się na wzorcu Obserwatora.Aplikacje wykorzystujące JavaServer Faces wspierają dwa typy zdarzeń. Do pierwszej

grupy zaliczają się zdarzenia związane ze zmianą stanu elementów interfejsu, poprzeznp. zaznaczenie chceckboxa i zmianie jego wartości z true na false. Drugą grupę zdarzeństanowią akcje podejmowane przez użytkownika poprzez kliknięcie przycisku bądź linka.Szkielet walidacji dostarcza mechanizmów za pomocą których możliwe jest podpięcie

walidatorów pod określone komponenty interfejsu użytkownika. Walidatory są zwykłymiobiektami implementującymi określony interfejs. Dodatkowo opisywany szkielet dostar-cza rozwiązań pozwalających na wyświetlenie błędów związanych z walidacją. Istniejemożliwość definiowania własnych walidatorów jak i skorzystania z już gotowych. Domyśl-nie dostarczane walidatory umożliwiają określenie obowiązkowości wystąpienia wartościdla określonego komponentu, podania napisu o określonej długości czy liczby o wartościz zadanego zakresu.Szkielet nawigacji umożliwia definicję przejść pomiędzy poszczególnymi stronami apli-

kacji za pomocą składni języka XML. Przejścia definiowane są w obrębie określonych zasadnawigacyjnych (ang. navigation rules), posiadających standardowo wartości i powiązanez nimi strony JSP. Zaletą opisywanego rozwiązania jest separacja zagadnień związanychz nawigacją i procesem wyświetlania stron.Ostatnim z opisywanych elementów jest szkielet dostarczający wsparcia w zakresie

internacjonalizacji stron, poprzez dostosowywanie interfejsu aplikacji do potrzeb użyt-kownika. Dostarczane informacje statyczne tłumaczone są z wykorzystaniem określonychkluczy, posiadających wartości w różnych językach. Internacjonalizacja treści dynamicznejjest zarządzana przez ziarna modelu.Elementy pomocnicze zaznaczone na rysunku 4.2 składają się w głównej mierze z obiek-

tów wspomagających (ang. backing beans) oraz klas pomocniczych takich jak walidatorybądź konwertery, stanowiących implementację wspomnianych wcześniej warstw. Obiektywspierające mają postać obiektów JavaBean, które pośredniczą w wymianie informacjipomiędzy warstwą interfejsu użytkownika a modelem biznesowym, poprzez wykorzystanieuniwersalnego języka wyrażeń (UEL). Możliwy jest dostęp do modelu aplikacji z poziomuobiektów wspomagających. W związku z tym, iż opisywane obiekty pełnią rolę pośredni-ka między widokiem a modelem, przypisuje się im funkcję kontrolerów, choć w zasadzieaplikacje oparte o JavaServer Faces są aplikacjami zorientowanymi na strony i nawigacjępomiędzy nimi.Strona JavaServer Faces składa się z obiektów umieszczonych po stronie serwera oraz

komponentów interfejsu użytkownika, zgrupowanych w strukturze drzewiastej. Informacjao stanie w jakim znajduje się aplikacja może być przechowywana zarówno po stronieklienta jak i serwera, w zależności od dokonanej konfiguracji. We wspomnianej strukturzedrzewiastej, każdy z komponentów jest adresowany za pomocą unikalnego identyfikatora.

58

4.1.3. Podsumowanie

Oba szkielety programistyczne posiadają podobną funkcjonalność, zaimplementowanąjednak w odmienny sposób. Podstawową różnicą jest typ zaimplementowanego modelu.Spring MVC jest typowym przedstawicielem frameworka realizującego Model 2, JavaSe-rver Faces prezentuje model komponentowy.Spring MVC realizuje koncepcję aplikacji internetowej opartej o żądania i odpowiedź.

Używa w tym celu kontrolerów operujących na modelu, z wykorzystaniem warstwy usługi zwracającym dane osadzone na wybranym widoku (najczęściej stronie JSP). W składopisywanej biblioteki wchodzą wyłącznie elementy realizujące wzorzec MVC, pozostałesą zdefiniowane w innych warstwach szkieletu Spring Framework. Opisywana sytuacjawynika z faktu, iż Spring MVC jest jedynie częścią frameworka warstwy środkowej jakimjest Spring Framework.JavaServer Faces stanowi standard specyfikacji JEE, umożliwiający tworzenie aplikacji

internetowych z naciskiem na interfejs użytkownika zbudowany w sposób komponentowy.JSF posiada w swojej ofercie wszystkie elementy potrzebne do budowy zaawansowanejaplikacji internetowej. Różnica w stosunku do Spring MVC polega na użyciu innego mo-delu, JSF jest szkieletem zorientowanym przede wszystkim na strony (ang. page-oriented).Budowa aplikacji opartej o architekturę zastosowaną w szkielecie JavaServer Faces do-

starcza programiście wyższy poziom abstrakcji powodując, iż programista operuje pojęcia-mi zdarzeń i komponentów, a nie jak w przypadku Spring MVC – żądaniami i znacznikamiJSP.

4.2. Model programistyczny

Niniejsza część przedstawia model programistyczny stosowany w obu badanych biblio-tekach. Prezentuje spojrzenie z punktu widzenia programisty pracującego z opisywanąbiblioteką, pozwalając czytelnikowi na zorientowanie się w sposobie konfiguracji i roz-mieszczenia poszczególnych części aplikacji. Dodatkowo uwzględniono aspekt związanyz nawigacją między stronami aplikacji, jako nieodłączną część modelu programistycznego.Opisywane przypadki pochodzą z implementacji przykładowej aplikacji, która w dalszejczęści pracy posłuży do praktycznego porównania badanych bibliotek.

4.2.1. Spring MVC

W przypadku tworzenia aplikacji opartej o Spring MVC zadanie biblioteki polega naodbiorze żądań użytkownika i kierowaniu ich w dalszej kolejności do obsłużenia przezwybrany kontroler, który w wyniku swojego działania zwraca model wraz z widokiemwykorzystanym do wyświetlenia danych modelu.Całość konfiguracji aplikacji opartej o Spring MVC mieści się w pliku o nazwie cha-

rakterystycznej dla aplikacji petclinic-servlet.xml. Zawiera on elementy niezbędne doprawidłowej pracy aplikacji wykorzystującej opisywaną bibliotekę.Najważniejszą częścią obsługującą żądania jest bean typu SimpleUrlHandlerMapping

grupujący obsługę podobnych zadań w jeden kontroler. Mapowania nazw widoków zwra-canych przez metodę obsługującą żądanie jest implementowane z użyciem elementu typuResourceBundleViewResolver, który do realizacji powierzonego mu zadania wykorzystu-je, edytowany przez programistę, plik properties. Ostatnim ważnym elementem głównegopliku konfiguracyjnego są beany typu PropertiesMethodNameResolver, które mapująadresy URL do konkretnych metod określonych kontrolerów.

59

Listing 4.1 prezentuje bean odpowiedzialny za grupowanie podobnych funkcjonalnieakacji w jeden kontroler typu MultiActionController. Każdy z wymienienionych w plikukonfiguracyjnym kontrolerów jest odpowiedzialny za obsługę innej encji.�

1 <bean id="urlMapping"2 class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">3 <property name="mappings">4 <props>5 <prop key="/welcome.xhtml">petclinicController</prop>6 <prop key="/vets/*">vetsController</prop>7 <prop key="/search/*">searchController</prop>8 <prop key="/visits/*">visitsController</prop>9 <prop key="/owners/*">ownersController</prop>10 </props>11 </property>12 </bean>� �

Listing 4.1: Bean Spring MVC mapujący adresy URL do kontrolerów

Kontroler mogący podejmować wiele akcji, zmapowany na wiele adresów URL zostałprzedstawiony na listingu 4.2. W definicji beana znajduje się referencja do beana usłu-gi, związanej z obsługą weterynarzy. Usługa ta jest wykorzystywana podczas realizacjizapytania skierowanego przez użytkownika, np. o listę wszystkich weterynarzy leczącychw klinice.�

1 <bean id="vetsController"2 class="org.panachida.webcream.web.springmvc.web.VetsController">3 <property name="vetService" ref="vetService" />4 <property name="methodNameResolver" ref="vetsControllerResolver" />5 </bean>� �

Listing 4.2: Bean Spring MVC opisujący kontroler

Ostatnim z elementów pliku konfiguracyjnego, który został przedstawiony na listin-gu 4.3 jest resolver. Jego funkcja polega na mapowaniu adresów URL do metod kon-trolera typu MultiActionController w celu obsłużenia żądania. W wyniku przedsta-�

1 <bean id="vetsControllerResolver"2 class="org.springframework...mvc.multiaction.PropertiesMethodNameResolver">3 <property name="mappings">4 <props>5 <prop key="/vets/vets.xhtml">vetsHandler</prop>6 <prop key="/vets/vet-details.xhtml">vetDetailsHandler</prop>7 </props>8 </property>9 </bean>� �

Listing 4.3: Bean Spring MVC mapujący żądania do metod kontrolera

60

wionej konfiguracji żądanie użytkownika skierowane pod adres zakończony ciągiem zna-ków /vets/vet-details.xhtml zostanie obsłużone przez metodę posiadającą nazwievetDetailsHandler znajdującą się w kontrolerze o nazwie vetsController.Wspomniana metoda vetDetailsHandler została przedstawiona na listingu 4.4 (w ce-

lu zwiększenia przejrzystości kodu, pominięto zgłoszenie wygenerowanego wyjątku). Podczas�1 public ModelAndView vetDetailsHandler(HttpServletRequest request,2 HttpServletResponse response) {3 ModelAndView mav = new ModelAndView("vetDetailsView");4 Long vetId = ServletRequestUtils.getRequiredLongParameter(request, "vetId");5 Vet vet = vetService.getById(vetId);6 mav.addObject(vet);7 List<Visit> scheduledVisits = vetService.getScheduledVisits(vet);8 mav.addObject(scheduledVisits);9 return mav;10 }� �

Listing 4.4: Metoda szkieletu Spring MVC obsługująca żądanie

tworzenia modelu wykorzystywany został widok o nazwie vetDetailsView, którego defi-nicja znajduje się w pliku properties (listing 4.5). Fragment definiujący opisywaną nazwęwidoku wskazuje na konkretny plik JSP wykorzystywany do przedstawienia danych mo-delu.�

1 vetDetailsView.(class)=org.springframework.web.servlet.view.JstlView2 vetDetailsView.url=/WEB-INF/pages/vets/vet-details.jsp� �

Listing 4.5: Fragment pliku views.properties aplikacji Spring MVC

4.2.2. JavaServer Faces

W celu obsłużenia nadchodzących żądań specyfikacja JavaServer Faces wprowadziładodatkowy poziom abstrakcji, próbujący upodobnić proces tworzenia aplikacji interneto-wych do procesu tworzenia aplikacji desktopowych.JSF pozwala na korzystanie z gotowych komponentów, potrafi wyświetlić informację

użytkownikowi o włączonej blokadzie wyskakujących okien, w przypadku gdy mogłobyto zakłócić pracę z aplikacją, automatycznie generuje pliki JavaScript oraz kaskadowycharkuszy stylów dopasowane do języka użytkownika i wykorzystywanej przeglądarki.Domyślnie konfiguracja aplikacji opartej o JSF zawarta jest w pliku noszącym na-

zwę faces-config.xml. Zawiera przede wszystkim definicje beanów wykorzystywanychpodczas działania aplikacji, mogących mieć opcjonalnie odzwierciedlenie w komponentachinterfejsu użytkownika jak również definicję przejść między stronami aplikacji.Przykład beanu powiązanego z elementem interfejsu odpowiedzialnego za tabelarycz-

ne przedstawienie weterynarzy kliniki znajduje się na listingu 4.6. Poprzez konstruk-cję #{vetServiceBean}, następuje powiązanie beana JSF z beanem zarządzanym przezSpringa (wymagane jest użycie elementu DelegatingVariableResolver).Kolejnym elementem pliku konfiguracyjnego są definicje związane z nawigacją w apli-

kacji. Przykład elementu nawigacyjnego prezentuje listing 4.7.

61

�1 <managed-bean>2 <managed-bean-name>vetsTable</managed-bean-name>3 <managed-bean-class>4 org.panachida.webcream.web.jsf.tables.VetsTableBean5 </managed-bean-class>6 <managed-bean-scope>session</managed-bean-scope>7 <managed-property>8 <property-name>vetServiceBean</property-name>9 <value>#{vetServiceBean}</value>10 </managed-property>11 </managed-bean>� �

Listing 4.6: Bean zarządzany JavaServer Faces

�1 <navigation-case>2 <from-outcome>vetDetails</from-outcome>3 <to-view-id>/pages/vets/vet-details.jspx</to-view-id>4 <redirect />5 </navigation-case>� �

Listing 4.7: Element definiujący nawigację aplikacji JSF

Tworzenie stron polega na korzystaniu z gotowych komponentów, które zostają wy-rażone w kodzie strony poprzez odpowiednie znaczniki. Do ustawiania własności kom-ponentów służą wartości atrybutów używanych znaczników. W przypadku tabeli mamynp. możliwość ustawienia liczby wierszy prezentowanych na jednym ekranie. Jeżeli liczbaobiektów jest większa niż ustalona wielkość, komponent JavaServer Faces dodaje elementynawigacyjne ułatwiające przemieszczanie się po wyświetlanym zbiorze danych.Komponenty stron są ograniczone do korzystania wyłącznie z beanów zdefiniowanych

w pliku faces-config.xml. Komponent reprezentujący tabelę odpytuje beana o zbiórweterynarzy, który później zostaje zwrócony jako odpowiedź. Praktycznie każdy używanyw aplikacji komponent posiada wspierającego go beana (ang. backing bean).

4.2.3. Podsumowanie

Oba z przedstawionych szkieletów programistycznych charakteryzują się odmiennymmodelem programistycznym. Model oparty o Spring MVC jest bardziej zbliżony do trady-cyjnego modelu, prezentowanego np. przez framework Struts. JavaServer Faces prezentujemodel oparty o tworzenie komponentów oraz obsługi zdarzeń generowanych z jego pomocą.W aplikacji opartej o Spring MVC, użytkownik definiuje mapowania żądań do nad-

zorujących aplikację kontrolerów. Kontroler po wykonaniu operacji na modelu, zwracapobrane z niego dane wraz z wybranym widokiem. Użytkownik tworzący aplikację widzibezpośrednio zależność od wzorca MVC.Aplikacja wykorzystująca JavaServer Faces, skupia się na szablonach, tworzonych

z komponentów, umożliwiając podejmowanie akcji użytkownikowi poprzez zainicjowanieprzez niego określonych zdarzeń, z wykorzystaniem wspomnianych komponentów. Niema jasno wydzielonego kontrolera, są tylko metody, których zadaniem jest reakcja naotrzymane zdarzenia.

62

Rysunek 4.3: Procedura obsługi żądania szkieletu Spring MVC

4.3. Cykl życia żądania

Celem niniejszej sekcji jest przedstawienie opisu cyklu życia żądania kierowanego przezużytkownika aplikacji. W przypadku szkieletu opartego o komponenty, żądania zostałyzamienione na zdarzenia generowane z użyciem poszczególnych komponentów umieszczo-nych na stronie.

4.3.1. Spring MVC

Obsługa nadchodzącego żądania została przedstawiona na rysunku 4.3. Centralnymelementem zarządzającym obsługą otrzymanego żądania jest obiekt DispatcherServlet,który koordynuje pracę całego cyklu żądania. Jego konfiguracja odbywa się w standardo-wym deskryptorze aplikacji internetowej, pliku web.xml.Obiekt implementujący interfejs HandlerMapping wskazuje obiektowi nadzorującemu,

który kontroler należy wywołać w celu obsłużenia otrzymanego żądania. Spring dostar-cza wielu implementacji wspomnianego interfejsu, pozwalając mapować kontrolery ponazwach beanów ich reprezentujących bądź w zależności od potrzeb za pomocą plikówproperties.Krok trzeci obsługi żądania polega na wywołaniu wybranego kontrolera. Zadaniem

kontrolera jest przetworzenie otrzymanego żądania oraz przeprowadzenie wymaganychprocesów biznesowych. Kontroler stanowi obiekt implementujący interfejs Controllerlub jeden z interfejsów pochodnych. Zwraca obiekt ModelAndView oznaczony na rysunkusłowem Model. Wspomniany obiekt zawiera dane pomocnicze, które zostały uzyskanez warstwy usług w celu zaspokojenia żądania oraz obiekt widoku będący wskazaniem naokreślony zasób bądź implementujący interfejs View.Rolą obiektu implementującego interfejs ViewResolver jest zamiana logicznej nazwy

zwracanego przez kontroler widoku na fizyczny plik zawierający szablon strony interneto-wej. Tak jak w poprzednich przypadkach Spring dostarcza wielu implementacji wspomnia-nego interfejsu, pozwalając definiować mapowania logicznych nazw widoków za pomocąokreślonych przedrostków i przyrostków jak i z wykorzystaniem pliku properties.Ostatnim elementem obsługi żądania, zaznaczony na rysunku w kroku szóstym, jest

widok reprezentowany przez interfejs View. Jego rola polega na sformatowaniu odpowiedzina podstawie otrzymanych danych pomocniczych. Domyślnie Spring posiada wsparcie dlawidoków będących stronami JSP, transformacjami XSLT, szablonami Velocity bądź Fre-

63

Rysunek 4.4: Procedura obsługi żądania szkieletu JavaServer Faces

eMaker, jak również arkuszami Excela, raportami JasperReports, czy plikami w formaciePDF.

4.3.2. JavaServer Faces

Cykl życia żądania aplikacji JavaServer Faces składa się z sześciu ściśle określonych fazprzedstawionych na rysunku 4.4. W swojej istocie są zbliżone do przetwarzania zdarzeńznanych z aplikacji desktopowych. Możliwa jest zmiana kolejności wykonywania poszcze-gólnych faz jak również pominięcie niektórych z nich. Jednakże logika i konsekwencja jakąkierowali się autorzy opisywanej biblioteki sprawia iż w większości przypadków standar-dowe ustawienie faz jest wystarczające.Poszczególne fazy obsługi żądania można przyporządkować do dwóch odmiennych po-

ziomów. Faza pierwsza i ostatnia, zajmujące się utworzeniem widoku oraz odpowiedzinależą do poziomu systemowego. Pozostałe cztery mieszczą się w poziomie zwanym po-ziomem aplikacji.W fazie pierwszej obejmującej utworzenie widoku, następuje odebranie żądania przez

obiekt kontrolera FacesServlet. Kontroler przetwarza otrzymane żądanie oraz pobieraidentyfikator widoku, który jest wyznaczany na podstawie żądanej strony JSP. Posiadanyidentyfikator służy do wyboru komponentów składających się na wybrany widok. Jeżeliżądany widok istnieje, wówczas zostaje pobrany do dalszego przetwarzania, w przeciwnymprzypadku jest tworzony nowy widok.Cykl życia jest związany z trzema różnymi instancjami widoku: nowym, inicjującym

bądź ponownie wczytanym (ang. postback). W przypadku widoku określanego mianemnowy, kontroler JSF tworzy widok z komponentów podłączając do nich metody nasłuchu-jące oraz walidatory, po czym składuje w obiekcie FacesContext. Wspomniany obiektposiada wszystkie informacje związane z zarządzaniem stanami komponentów interfejsuużytkownika podczas przetwarzania żądania przechowywanych w strukturze drzewiastej.W przypadku widoku inicjującego, podczas pierwszego wczytania strony, kontroler two-rzy pusty widok, który jest zapełniany podczas akcji podejmowanych przez użytkownika.Ostatni z instancji widoków jest używany podczas ponownego wczytania widoku, ponieważwidok już wcześniej był używany wymagane jest jedynie odnowienie strony (ang. restore).Przeznaczeniem drugiej fazy życia żądania jest pobranie stanu aktualnie wybranych

komponentów. W celu skorzystania z komponentów muszą one zostać najpierw pobranelub utworzone przy pomocy obiektu FacesContext. Standardowo pobranie komponentówodbywa się na podstawie parmetrów żądania, jego nagłówków bądź sesji.

64

Jeżeli natychmiastowe wychwycenie zdarzeń jest wyłączone, poszczególne parametryżądania zostają przekonwertowane do odpowiadającym im obiektom języka Java. W raziewystąpienia błędu generowana jest informacja umieszczana w obiekcie FacesContext,która zostanie wyświetlona w ostatniej fazie obsługi żądania wraz z innymi błędami.W przypadku włączenia natychmiastowego wychwycenia zdarzeń, parametr jest poddawa-ny walidacji. W przypadku wystąpienia błędu, następuje wygenerowanie odpowiedniegokomunikatu.Rolą kolejnej fazy jest walidacja wartości związanych z poszczególnymi komponenta-

mi. Część z reguł walidujących jest predefiniowana, istnieje również możliwość stworzeniawłasnych walidatorów. W przypadku niespełnienienia przez komponent przypisanych muzasad walidujących, komponent zaznaczany jest jako niepoprawny i wyświetlony w odpo-wiedni sposób podczas fazy tworzenia widoku.Jeżeli wszystkie z komponentów przeszły poprawnie przez fazę walidacji następuje faza

związana z aktualizacją modelu. Następuje powiązanie nowych wartości z własnościamiodpowiednich beanów wspomagających. Wiedząc iż faza walidacji przeszła poprawnie,możemy mieć pewność iż operujemy na poprawnych wartościach.W przedostatniej fazie związanej z obsługą żądania następuje wykonanie określonej

akcji. Wykonanie opisywanej fazy wiąże się ściśle z wykonaniem logiki biznesowej systemuoraz zdefiniowaniu prezentowanego użytkownikowi widoku. Mapowania logicznych nazwwidoków na zasoby szablonów definiowane są w pliku faces-config.xml.Ostatnią z opisywanych faz jest wygenerowanie odpowiedzi, czyli wyświetlenie widoku

uwzględniającego aktualny stan komponentów.

4.3.3. Podsumowanie

Celem obu zaprezentowanych rozwiązań jest przetworzenie żądania użytkownika i zwró-cenie wyniku.Spring MVC w szablonowy sposób stosuje do obsługi żądania model oparty o wzorzec

MVC z podziałem na widok, model i kontroler. Obsługa żądania jest wspierana przezobiekty pomocnicze wspierające obiekt nadzorujący w prawidłowym doborze kontroleraoraz mapowaniu logicznej nazwy widoku ja jego rzeczywistą postać. Dodatkowo możliwejest użycie obiektów pełniących rolę konwerterów bądź walidatorów.W aplikacjach opartych o technologię JavaServer Faces, obsługa żądania jest ściśle

powiązana z komponentami tworzącymi stronę aplikacji. W przypadku aplikacji opar-tych o model komponentowy żądanie często jest nazywane zdarzeniem, które inicjujeklient z użyciem wybranego komponentu. Poszczególne fazy obsługi zdarzenia są dobrzezdefiniowane i korzystają z wszystkich możliwości opisywanej biblioteki zaczynając odkonwersji, walidacji a kończąc na wyświetleniu odpowiedzi.

4.4. Walidacja i konwersja typów

Z zagadnieniami związanymi z walidacją i konwersją typu programista spotyka sięnajczęściej podczas pracy z formularzami. Poprawnie skonstruowana aplikacja nie po-zwoli na zapisanie do modelu niepoprawnych bądź błędnych danych. Ponadto korzystającz biblioteki możnemy poinformować użytkownika o miejscu wystąpienia błędu a następnieumożliwić wprowadzenie poprawnych danych. Konwersja typów dotyczy zamiany danychmodelu składowanych w obiektach języka Java na postać tekstową dostępną poprzez polaformularza oraz w drugą stronę, z obiektu do postaci tekstowej.

65

4.4.1. Spring MVC

Zagadnienia związane z walidacją autorzy biblioteki Spring umieścili w warstwie logikibiznesowej. Konsekwencją dokonanego wyboru jest z formalnego punktu widzenia brakobiektów walidujących w warstwie widoku implementowanego przez Spring MVC.Do walidacji służą obiekty implementujące interfejs Validator, który wymaga imple-

mentacji metod supports oraz validate. Pierwsza z metod określa czy dany walidatornadaje się do walidacji obiektu podanego jako argument zwracając wartość logiczną. Dru-ga metoda przeprowadza proces walidacji. Błędy związane z niepoprawną walidacją sązwracane w postaci obiektu Errors, który jest przekazywany jako jeden z parametrów.Podczas implementacji logiki walidacji przydatne może być skorzystanie z klasy pomocni-czej zwanej ValidationUtils, która zawiera metody badające między innymi zawartośćokreślonego pola względem wartości pustej.Informacje na temat popełnionych błędów podczas wypełniania formularza użytkow-

nik dostaje poprzez wykorzystanie specjalnego znacznika <spring:bind /> wyświetlają-cego w sformatowany sposób zawartość obiektu Errors.Konwersja typów odbywa się z wykorzystaniem tzw. edytorów własności (ang. Pro-

pertyEditors). Rola edytorów polega na zamianie własności obiektów języka Java na ichreprezentację czytelną dla użytkownika. Jednym z przykładów takiej własności może byćobiekt Date, który standardowo zawiera bardzo szczegółowe informacje, co może być nie-przydatne w momencie użycia go w polu przyjmującym wyłącznie datę. W celu użyciawłasnego edytora należy go wcześniej zarejestrować, czyli powiadomić system o sposobiekonwersji określonej własności.Spring domyślnie dostarcza ponad dziesięć różnych edytorów pomocnych w przypad-

kach wymagających konwersji napisów do typów numerycznych takich jak Integer czyFloat czy zamianie adresów URL na odpowiadające im obiekty.

4.4.2. JavaServer Faces

W aplikacji opartej o JavaServer Faces proces walidacji i konwersji typów na swojeścisłe miejsce w cyklu życia żądania. Proces walidacji odbywa się przez powiązanie war-tości komponentu z beanem wspomagającym. Natomiast konwersja typów ma miejscew drugiej fazie, przed czynnościami związanymi z walidacją.W przypadu komponentów posiadających ustawioną opcję natychmiastowego wychwy-

cenia zdarzeń, walidacja oraz konwersja typów odbywa się wspólnie na wcześniejszymetapie pobrania stanu.Zadaniem konwersji typów jest zapewnienie iż podane dane są właściwego typu. W przy-

padku podania w polu wymagającym liczby zmiennoprzecinkowej, napisu nie będącegoliczbą, obiekt dokonywujący konwersji powinien zgłosić błąd. Zadaniem walidacji nato-miast jest sprawdzenie zasad biznesowych na obiekcie poprawnego typu.JavaServer Faces dostarcza szeregu domyślnych konwerterów począwszy od obiektów

zajmujących się konwersją liczb i napisów po obiekty konwertujące daty. Możliwe jestrównież utworzenie własnych konwerterów poprzez implementację interfejsu Converter.Utworzenie własnych konwerterów jest potrzebne w momencie użycia w aplikacji obiek-

tów specyficznych dla danego systemu, takich jak np. numer telefonu czy kod produktu.Obiekt konwertera musi implementować wspomniany interfejs, poprzez implementacjędwóch metod zamieniających obiekt na napis i odwrotnie. Ponadto przed użyciem wła-snego konwertera jest wymagane zainstalowanie go w obiekcie FacesContext.

66

JavaServer Faces dostarcza czterech różnych form walidacji: dostępnych za pomocąstandardowych komponentów, wbudowanych na poziomie aplikacji (ang. application-levelvalidation), niestandardowych, stworzonych poprzez implementacje interfejsu Validatororaz metod walidujących znajdujących się w beanach wspomagających.Walidacja za pomocą standardowych komponentów odbywa się poprzez umieszczenie

odpowiednich znaczników w kodzie strony szablonu. Walidatory standardowo dołączanedo biblioteki JSF pozwalają na sprawdzenie poprawności podanego przedziału liczbowegoczy długości napisu.Walidacja dostępna na poziomie aplikacji w rzeczywistości dotyczy walidacji zasad

logiki biznesowej zawartej w kontrolerze aplikacji. Przykładem zastosowania opisywane-go typu walidacji może być sprawdzenie zdolności kredytowej klienta, chcącego wybraćdodatkowe pieniądze. Jeżeli okaże się, iż klient nie posiada wystarczających środków,kontroler umieści stosowne informacje w kontekście aplikacji i przekieruje użytkownika dostrony informującej o zaistniałej sytuacji.JavaServer Faces umożliwia tworzenie niestandardowych walidatorów, które można

wykorzystać w zawartości szablonu. Przykładowe walidatory tego typu mogą walidowaćpoprawność numeru telefonu, adresu e-mail czy kodu pocztowego. Po zarejestrowaniuzostaną udostępnione poprzez znacznik <f:validator />.Ostatni sposób walidacji polega na wykorzystaniu metody beana wspomagającego,

którego sygnatura jest zgodna z metodą validate interfejsu Validator.

4.4.3. Podsumowanie

Walidacja oraz konwersja typów stanowią ważny aspekt aplikacji internetowej po-bierającej bądź wyświetlającej własności obiektów domeny. Obiekty walidujące dbająo poprawność składniową podawanych przez użytkownika danych. Obiekty konwertującezapewniają zamianę obiektów języka Java na postać napisu oraz konwertują z powrotempola formularza na obiekty.Spring MVC stosuje czysto obiektowe podejście do opisywanego zagadnienia. Wpro-

wadza pojęcia interfejsów odpowiedzialnych za walidację oraz obiekty edytorów własności,które są rozszerzeniem standardowych obiektów konwertujących, mogących mieć zastoso-wanie w różnych warstwach aplikacji opartej o Spring Framework.Rozwiązanie oferowane przez JavaServer Faces spełnia swoje zadanie, oferuje odpo-

wiednie interfejsy dla walidatorów i konwerterów oraz uwzględnia ich zastosowanie w pro-cesie obsługi żądania.Oba omawiane zagadnienia pozwalają na definiowanie własnych obiektów oraz do-

starczają własnych podstawowych obiektów walidujących i konwertujących. Informacjeo zaistniałych błędach są wyświetlane w sposób czytelny, możliwy do modyfikacji.

4.5. Internacjonalizacja

Celem internacjonalizacji aplikacji webowej [43] jest zlikwidowanie barier związanychz lokalizacją produktu. Obie biblioteki posiadają mechanizmy wspomagające ten proces.

4.5.1. Spring MVC

Najważniejszymi komponentami służącymi do lokalizacji aplikacji tworzonej z uży-ciem Spring MVC są następujące komponenty o następujących nazwach: MessageSource,LocaleResolver, LocaleContextHolder oraz LocalChangeInterceptor.

67

Pierwszy z wymienionych komponentów służy do lokalizacji statycznych elementówstron. Jest częścią kontekstu nazywanego ApplicationContext. Wspomniany komponentdostarcza trzech przeładowanych metod getMessage, służących do wczytania napisóww zależności od danych użytkownika.Domyślnie Spring dostarcza dwóch implementacji komponentu MessageSource. Jed-

na z nich umożliwia programową obsługę wiadomości lokalizacyjnych. Druga znacznieczęściej używana, składa się z serii plików properties, zawierających zlokalizowane wia-domości podzielone według ustawień regionalnych (ang. locale) [55]. Za pomocą wspo-mnianego komponentu możliwe jest określenie przedrostka plików zawierającego wiado-mości. W przypadku podania przykładowej nazwy exceptions, wiadomości będą szukanew plikach posiadających nazwy zbliżone do podanych: exceptions_en_GB.propertiesbądź exceptions_pl_PL.properties, w zależności od ustawień przeglądarki użytkowni-ka. Opisywany komponent służy również do lokalizacji komunikatów o błędach.Komponent LocaleResolverma za zadanie rozpoznać ustawienia regionalne użytkow-

nika aplikacji. Dostępne dwie wersje korzystają z atrybutu accept-language nagłówkażądania HTTP, zawartości ciasteczka lub atrybutu sesji. Deklaracja opisywanego kompo-nentu sprowadza się do dokonania wpisu w pliku konfiguracyjnym.Pozostałe komponenty służą do składowania elementów lokalizacyjnych w sposób moż-

liwy do uzyskania z dowolnego miejsca aplikacji.

4.5.2. JavaServer Faces

Lokalizacja w aplikacjach opartych o JavaServer Faces opiera się o pliki wiadomościlokalizacyjnych [20] pobieranych z wnętrza aplikacji za pomocą odpowiednich kluczy.Format plików zawierających wiadomości lokalizacyjne jest formatem plików proper-

ties. Nazwa plików definiowana jest poprzez znacznik <message-bundle> umieszczonyw pliku konfiguracyjnym JavaServer Faces. Poszczególne pliki wiadomości lokalizacyj-nych posiadają przyrostek składający się z podkreślenia oraz nazwy ustawień regionalnychz rozszerzeniem properties. Przykładowy plik zawierający wiadomości w języku polskimmoże nosić nazwę komunikaty_pl.properties.W plikach stron JSP, programista chcący wyświetlić określony komunikat korzysta

z odpowiedniego klucza, który posiada swój odpowiednik w pliku properties.

4.5.3. Podsumowanie

Oba opisane powyżej rozwiązania opierają się na takich samych rozwiązaniach. Wyko-rzystują serię plików stosujących format properties, składających się z par klucz wartość.Obiekt przetwarzający plik szablonu w momencie natrafienia na odwołanie do klu-

cza, korzysta z informacji przekazywanych w nagłówku żądania i szuka wiadomości lo-kalizacyjnej w pliku properties noszącym nazwę odwołującą się do pobranych ustawieńregionalnych.

68

5. Aplikacja Peclinic

Poniższy rozdział opisuje aplikację Petclinic zaimplementowaną w celu empirycznegoporównania wybranych szkieletów programistycznych. Pierwsza z części zawiera ogólnyopis i przeznaczenie aplikacji w kontekście przeprowadzanych eksperymentów. Następnyrozdział opisuje poszczególne moduły składowe aplikacji . Ostatnia część rozdziału przed-stawia zaimplementowaną funkcjonalność.

5.1. Opis aplikacji

Aplikacja Petclinic została wzorowana na aplikacji dostarczanej standardowo ze szkie-letem Spring Framework jako demonstracja jego możliwości [59]. Prezentowany systemzostał napisany od podstaw wraz z wprowadzeniem dodatkowych elementów, które miałyza zadanie zwiększenie stopnia jego złożoności. Kod źródłowy aplikacji umieszczono napołączonym do pracy nośniku.Elementami aplikacji Petclinic, które różnią ją od oryginału dostarczanego wraz ze

Spring Framework są:— dodanie encji lekarstwo, przepisane lekarstwo oraz grupa lekarstwa,— dodanie i uzupełnienie funkcjonalności obsługującej dotychczasowe, i nowo dodane doaplikacji encje.Prezentowana aplikacja służy do wspomagania pracy niewielkiej przychodni wetery-

naryjnej. Jej funkcjonalność jednak nie jest pełna i system nie nadaje się do zastosowaniaw warunkach rzeczywistych. Zasadniczym celem systemu jest praktyczne zaprezentowa-nie działania mechanizmów dostarczanych przez badane szkielety programistyczne orazumożliwienie porównania ich w sytuacji możliwie zbliżonej do rzeczywistej.System Petclinic składa się z szeregu stron na których użytkownik może zarządzać

pracą kliniki. Wyróżniono trzy główne działy, które operują na obiektach klientów, wete-rynarzy i wizyt. Każdy z działów zawiera stronicowaną listę obiektów. Rysunki 5.1 oraz5.2 przedstawiają listę klientów w aplikacji zaimplementowane odpowiednio za pomocąSpring MVC oraz JavaServer Faces.

Rysunek 5.1: Lista planowanowanych wizyt w aplikacji Spring MVC

69

Rysunek 5.2: Lista klientów kliniki w aplikacji JavaServer Faces

Podczas implementacji aplikacji skupiono się na rozwiązaniu najczęstszych problemówjakie napotyka programista podczas budowy aplikacji internetowej. Wspomniane proble-my obejmują następujące elementy:— stworzenie nawigacji pomiędzy stronami,— walidacja wprowadzanych danych i ich konwersję na obiekty języka Java,— lokalizacja aplikacji.We wszystkich wymienionych elementach programista otrzymuje wsparcie ze strony szkie-letu programistycznego. Zaimplementowana aplikacja stara się zatem wprowadzić możli-wie dużo sytuacji, w których wsparcie ramy projektowej okazuje się pożądane, jedno-cześnie ograniczając ich nadmiar w celu zachowania możliwej do utrzymania prostoty.Wprowadzona miejscami nadmiarowość polegająca na powielaniu elementów systemu podkątem wykorzystania wsparcia funkcjonalności ramy projektowej, np. możliwość edycjiwięcej niż jednej encji, została wprowadzona w celu zwiększenia realizmu aplikacji orazzbudowania wystarczającej podstawy dla testów wydajnościowych.

5.1.1. Wykorzystane technologie

Podczas implementacji aplikacji zostały wykorzystane narzędzia i technologie opisanew rozdziale 2. W niniejszej części wyjaśniono sposób wykorzystania niektórych z nichw projekcie Petclinic.Cały kod projektu był składowany w repozytorium Subversion. Sytuacja taka pozwala-

ła na wersjonowanie dokonywanych zmian oraz łatwe ich przenoszenie pomiędzy gałęziamikodu aplikacji stworzonymi do przeglądania i zarządzania obiektami kliniki. Dodatkowązaletą była łatwa możliwość udostępnienia zainteresowanym ciągłego wglądu do kodu.Przy zarządzaniu kodu użyto systemu Maven, który okazał się pomocny podczas roz-

woju aplikacji. Został użyty bezpośrednio również podczas generowania raportów doty-czących metryk kodu.Hibernate został użyty do stworzenia mapowania pomiędzy obiektami domeny a ta-

blicami relacyjnej bazy danych. W projekcie najpierw utworzono obiekty języka Java,następnie opatrzono je odpowiednimi adnotacjami. Pozwoliło to w rezultacie na wyge-nerowanie odpowiedniego schematu bazy danych, pozwalającego na utrwalenie obiektówdomeny należących aplikacji.Podczas implementacji aplikacji skorzystano z bazy danych HSQLDB 8 do składo-

wania stanu aplikacji. Do jej największych zalet należy niewielki rozmiar oraz szybkośćstartu, co znacząco wpływa na komfort wykonywania testów, w których jest wymaga-ny wielokrotny start silnika bazy danych. W procesie implementacji uniknięto częstych

70

startów serwera bazodanowego poprzez wykorzystanie wspomnianej w rozdziale 2 klasyAbstractDependencyInjectionSpringContextTests z pakietu Spring Mock.Szkielet Spring Framework posłużył do złączenia poszczególnych warstw aplikacji.

Znacznie uprościł użycie Hibernate’a w aplikacji. Poprzez zastosowanie wzorca wstrzyki-wania zależności uzyskano rozluźnienie połączeń pomiędzy poszczególnymi komponentamiaplikacji. Poprzez użycie programowania aspektowego (ang. aspect-oriented programming)wprowadzono w wymagane miejsca aplikacji transakcyjność.Biblioteka EasyMock została wykorzystana przy testowaniu jednostkowym wybranych

obiektów warstwy biznesowej.Do końcowych testów akceptacyjnych posłużyła biblioteka Selenium, którą wykorzy-

stano do testowania poprawności zaimplementowania interfejsu użytkownika.

5.1.2. Encje bazy danych

Aplikacja Petclinic służy do zarządzania niewielką przychodnią weterynaryjną. Poniż-sza część opisuje wykorzystane encje oraz ich powiązania między sobą.Prezentowany sposób implementacji rozszerzył zbiór oryginalnej aplikacji Petclinic

o encje związane z lekarstwami, które lekarz weterynarii może przypisać pacjentowi.Poniżej umieszczono spis tabel używanych w bazie danych, które posłużyły do imple-

mentacji aplikacji:— Medicines przechowuje informacje na temat leków dostępnych do przepisania w kli-nice. Zawiera informacje na temat nazwy leku oraz przynależności do jednej z grupylekarstw.

— Medicines_groups wykorzystano do składowania nazw grup lekarstw.— Owners utożsamia właścicieli leczonych zwierząt. Zawiera informacje na temat ichdanych osobowych: imię, nazwisko, adres (ulica, miasto), numer telefonu, e-mail.

— Pets reprezentuje zwierzęta leczone w przychodni. Gromadzi dane odnośnie ich nazwy,daty urodzin. Posiada odniesienia do klucza głównego właściciela oraz typu zwierzęcia(encja pet_types).

— Prescribed_medicines składuje informacje na temat przypisanych lekarstw. Posiadaodniesienia do lekarstwa, oraz informacje na temat dawki oraz wizyty, w czasie którejprzepisano lekarstwo.

— Vets przechowuje informacje na temat lekarzy leczących w klinice oraz ich danychosobowych.

— Vets_specialties przechowuje połączenie pomiędzy weterynarzami a ich specjaliza-cjami, wprowadzona w wyniku relacji n:m łączy obie wspomniane encje.

— Visits wykorzystano do składowania informacji odnośnie planowanych bądź odby-wających się wizyt. Zawiera informacje odnośnie nazwy wizyty, jej daty oraz opis.Ponadto posiada odniesienia do zwierzęcia, które było leczone podczas wizyty orazweterynarza leczącego wspomniane zwierzę.Powiązania pomiędzy tabelami bazy danych zawiera rysunek 5.3. Zdecydowana więk-

szość relacji jest typu 1:n, jedynie relacja specjalizacji z weterynarzami, które je posiadająjest typu n:m.

71

Rysunek 5.3: Tabele bazodanowe aplikacji Petclinic

5.2. Moduły aplikacji

Każda z dwóch implementacji aplikacji Peclinic składa się z trzech wydzielonych mo-dułów o jasno sprecyzowanych zadaniach. Opisywane jednostki są odpowiednikami częścisystemu zarządzanego przez Mavena.Dwa moduły implementujące warstwę dostępu do danych oraz logikę biznesową stano-

wią podstawę i są wspólne dla obu implementacji. Jedyna różnica występuje w warstwienajwyższej, implementującej interfejs użytkownika. W tych warstwach zostały wykorzy-stane rozdzielnie oba badane szkielety programistyczne, dając w rezultacie dwie osobneaplikacje.

5.2.1. Petclinic-data

Moduł noszący nazwę petclinic-data jest warstwą dostępu do danych. Zawieraobiekty domeny na których operuje aplikacja takie jak owner, vet czy visit. Ponadtoudostępnia dostęp do obiektów DAO (ang. Data Access Object), które oferują możliwośćzarządzania obiektami domeny niezależnie od wykorzystywanego mechanizmu składowa-nia danych.Obiekty domeny są to zwykłe obiekty języka Java, które zostały wzbogacone o odpo-

wiednie adnotacje umożliwiające mapowanie ich na odpowiadające im tabele bazy danych.Przykład obiektu domeny utożsamianego ze zwierzęciem został przedstawiony na rysun-ku 2.5. Przedstawia on klasę Pet oraz jej relację względem właściciela.Warstwa obiektów DAO została zbudowana na typach generycznych, podstawowym

interfejsem jest GenericDao, który udostępnia operacje zapisywania, usuwania oraz pobie-rania obiektów domeny. Jego specjalizacje w postaci interfejsów GenericNamedDao orazGenericPersonDao służą do obsługi obiektów posiadających tylko nazwę czyli np. Petczy Medicine bądź osób jak w przypadku obiektów Owner. Obiekty DAO zostały zaim-plementowane wyłącznie dla głównych encji aplikacji, operacje na pozostałych encjachwykonywane są za ich pomocą.

5.2.2. Petclinic-core

Opisywany moduł zawiera logikę biznesową aplikacji zaimplementowaną w postaciusług. Ta część aplikacji pełni funkcję abstrakcji dla wykonywanych w aplikacji zadań,podobnie jak warstwa DAO w przypadku operacji związanych z utrwaleniem obiektów.

72

Rysunek 5.4: Lista planowanowanych wizyt w aplikacji Spring MVC

Rysunek 5.5: Lista planowanowanych wizyt w aplikacji JavaServer Faces

Cechą charaktertyczą opisywanego modułu jest bezpośrednie użycie niższej warstwyzaimplementowanej w postaci modułu petclinic-data. Operacje biznesowe wymagajączęsto podczas realizacji dostępu do wielu obiektów DAO, poszczególne metody biznesowedają taką możliwość przy pojedynczym ich wywołaniu.Podobnie jak poprzednia warstwa korzysta z klas generycznych dla zwiększenia ela-

styczności oraz zmniejszenia powtórzeń w kodzie.

5.2.3. Petclinic-web

Najwyższa warstwa zaimplementowana w postaci modułów petclinic-springmvc-weboraz petclinic-jsf-web implementuje interfejs użytkownika. Implementacja w postacidwóch modułów wynika z użycia dwóch szkieletów programistycznych odpowiednio SpringMVC oraz JavaServer Faces.Eksperymenty opisane w kolejnym rozdziale bazują na najwyższej warstwie osobno

dla każdej z aplikacji.Zadaniem opisywanej warstwy jest implementacja interfejsu użytkownika. Do podsta-

wowych elementów należą:— klasy edytorów i konwerterów mających za zadanie zamiany reprezentacji tekstowejna obiekty domeny,

— klasy operujące na formularzach i przetwarzające wprowadzane przez użytkownikadane,

— walidatory dbające o poprawność wprowadzanych danych.Do zadań prezentowanego modułu należą również zapewnienie nawigacji między stronamiaplikacji oraz mapowania nadchodzących żądań do kontrolerów.

5.3. Zaimplementowana funkcjonalność

Funkcjonalność aplikacji Petclinic została zaimplementowana osobno w dwóch wer-sjach aplikacji wykorzystującej różne szkielety programistyczne, Spring MVC oraz Java-Server Faces.

73

Rysunek 5.6: Walidacja formularza dodawania klienta w aplikacji Spring MVC

Rysunek 5.7: Walidacja formularza dodawania klienta w aplikacji JavaServer Faces

Poniższy wykaz funkcjonalności zawiera podział wprowadzony na etapie przeprowa-dzania eksperymentów z podziałem na przeglądanie obiektami aplikacji, zarządzanie nimioraz lokalizację.W pierwszym etapie zaimplementowano możliwość przeglądania danych, do tego celu

użyto między innymi stronicowanych list. Aplikacja umożliwia przeglądanie:— Informacji o trzech najbliższych wizytach (tabela umieszczona na stronie głównej).Rysunki 5.4 oraz 5.5 przedstawiają odpowiednio listy stworzone w aplikacji opartejo Spring MVC oraz JavaServer Faces.

— Wyszukiwanie klientów po fragmencie nazwiska.— Wyświetlanie klientów wraz z ich szczegółami dotyczącymi posiadanych zwierząt orazich wizyt.

— Wyświetlanie historii wszystkich wizyt kliniki wraz z ich szczegółami.— Wyświetlanie listy weterynarzy pracujących w klinice wraz z ich szczegółami.Wspomniane szczegóły najczęściej dotyczą atrybutów obiektów takich jak nazwa czy imięi nazwisko w przypadku osób.Funkcjonalność zaimplementowana w drugim etapie pozwala na zarządzanie obiektami

aplikacji, w szczególności umożliwia dodawanie, usuwanie i modyfikację klientów, zwierzątoraz wizyt. Walidację formularza służącego do dodawania klienta przedstawiają rysunki5.6 oraz 5.7.W trzeciej fazie skupiono się na zlokalizowaniu aplikacji w dwóch językach polskim

i angielskim. Lokalizacji zostały poddane:

74

— komunikaty niepowodzenia walidacji danych formularza,— treść stron.Ponadto dodano możliwość przełączania się między wersjami stron we wspomnianychwersjach językowych.

75

6. Eksperymenty z wykorzystaniem aplikacjiPetclinic

Poniższy rozdział przedstawia sposób przeprowadzenia oraz wyniki analizy ekspery-mentów [64, 11] dokonanych na aplikacji wspomagającej pracę przychodni weterynaryjnejo nazwie Petclinic.Pierwsza z części opisuje proces w jaki zgromadzono i przetworzono dane uzyskane

w wyniku eksperymentów. Druga część rozdziału skupia się na opisie i analizie danychuzyskanych w wyniku przeprowadzonych eksperymentów.

6.1. Przebieg badania

Zadaniem prezentowanego podrozdziału jest opis przebiegu implementacji aplikacjiPetclinic oraz przedstawienie sposobu przeprowadzenia eksperymentów.

6.1.1. Fazy implementacji aplikacji Petclinic

Implementacja przykładowej aplikacji została podzielona na trzy odrębne fazy. Apli-kacja powstała w wyniku każdej z nich posiada ściśle określoną funkcjonalność.Po zakończeniu implementacji modułów petclinic-data oraz petclinic-core za-

wierających odpowiednio kod związany z dostępem do danych oraz logiką biznesową(szczegóły zawarte zostały w rozdziale 5.2) zaczęła się właściwa faza polegająca na im-plementacji modułów odpowiedzialnych za warstwę internetową aplikacji.Implementacja ostatniej z faz projektu została podzielona na trzy etapy związane

z rozwojem każdej z dwóch wersji aplikacji Petclinic, opartej o framework Spring MVCoraz JavaServer Faces. Poszczególne etapy pracy wraz z zawartą w nich funkcjonalnościązostały opisane w rozdziale 5.3.Czas potrzebny na implementację każdego etapu obu wersji aplikacji okazał się zbliżony

do siebie. Jednocześnie znaczna większość czasu została poświęcona na naukę i poszukiwa-nie rozwiązań problemów specyficznych dla danego frameworka. W rezultacie trudno byłowyodrębnić czas poświęcony na rzeczywistą implementację aplikacji. Powyższa sytuacjaspowodowała, iż w końcowej analizie czas implementacji nie został uwzględniony.Autor implementując aplikację dążył do osiągnięcia takiego samego poziomu końcowej

funkcjonalności w obu systemach.Podczas pracy po zakończeniu pierwszej i drugiej fazy tworzono nową gałąź w repozy-

torium kodu, w ktorej umieszczano dotychczasowo napisany kod. W rezultacie aplikacjapowstająca w każdym z etapów zawierała kod już istniejący oraz dodawała swój własnyzwiązany z zarządzaniem obiektów bądź lokalizacją.Końcowym efektem prac nad aplikacją Petclinic było powstanie czterech modułów:

— dostępu do danych, petclinic-data,— logiki biznesowej, petclinic-core,— warstwy aplikacji internetowej opartej o Spring MVC petclinic-springmvc-web,

76

Rysunek 6.1: Drzewo komponentów aplikacji JMeter

— warstwy aplikacji internetowej z wykorzystaniem JavaServer Faces petclinic-jsf-web.Każdy z dwóch ostatnich modułów posiada implementację bazującą na opisanych wcze-śniej trzech etapach budowy.

6.1.2. Badanie wydajności

Wydajność stworzonych aplikacji zostanie zmierzona poprzez użycie narzędzia symu-lującego jednoczesną pracę wielu użytkowników.Do przeprowadzenia testów został wybrany JMeter [6], projekt fundacji Apache So-

ftware Foundation. Aplikacja pozwala na przeprowadzenie testów funkcjonalnych jak i wy-trzymałościowych. Działa na zasadzie symulacji pracy określonych grup użytkowników.JMeter oprócz protokołu HTTP potrafi również badać aplikacje wykorzystujące FTP czyLDAP.Rysunek 6.1 przedstawia drzewo komponentów stworzone w celu testowania wydajno-

ści aplikacji podczas dodawania klientów. Komponent „Add owner” jest odpowiedzialnyza wysyłanie określonej liczby żądań z wykorzystaniem elementów podrzędnych. Elementpróbkujący wysyła odpowiednie żądanie metodą POST dodając tym samym nowych klien-tów do bazy. Komponenty oznaczone przedrostkiem „[CSV]” odpowiadają za dostarczeniedanych dodawanych klientów. Pozostałe gromadzą dane dane uzyskane z pomiarów.

Plan pomiaru

W celu przeprowadzenia eksperymentów wydajnościowych zostały przeprowadzonetrzy grupy testów różniące się charakterystyką osób biorących w nich udział.Pierwszą grupę stanowiły osoby przeprowadzające wyłącznie operację odczytu da-

nych, czyli nie podejmujących żądanych akcji mogących mieć wpływ na stan wewnętrznyaplikacji.W skład drugiej grupy testowej wchodziły wyłącznie osoby, które przeprowadzają ope-

rację mające odzwierciedlenie w stanie wewnętrznym aplikacji. Do operacji tego typumożna zaliczyć operacje dodawania użytkowników, modyfikacji ich danych osobowychczy ciągu operacji związanych z obsługą wizyty użytkownika.Grupa użytkowników składającą się na trzeci eksperyment zawierała zarówno użyt-

kowników z pierwszego testu jak i drugiego. Trzeci test miał za zadanie odzwierciedlenierzeczywistej pracy użytkowników aplikacji. Większość z nich będzie przeprowadzać wy-łącznie operację przeglądania i wyszukiwania danych, mniejszość operację modyfikującestan aplikacji.

77

Sposób przeprowadzenia pomiaru

Użyte narzędzie JMeter pozwala na zdefiniowanie żądanej w testach liczby użytkow-ników oraz całkowitego czasu potrzebnego na ich wystartowanie.W przypadku testów zastosowano serwer pośredniczący, który posłużył do nagrania

planowanych żądań działań użytkowników.Podczas testów zostały wykorzystane dwa komputery połączone w ramach sieci lo-

kalnej. Jeden z komputerów zawierał testowaną aplikację i przetwarzał żądania użytkow-ników. Druga maszyna zawierająca instancję JMetera była odpowiedzialna za wysyłaniestrumienia żądań i gromadzenie wyników.Eksperymenty przeprowadzono w trzech opisanych seriach. Liczba jednocześnie pracu-

jących osób została dobrana z uwzględnieniem charakterystyk połączenia sieciowego orazmocy obliczeniowej komputerów biorących udział w teście. Ze względu na brak rzeczywi-stych danych odnośnie proporcji grup użytkowników, w teście trzecim została wybranaproporcja 4/1, użytkowników grupy pierwszej do użytkowników grupy drugiej.Dla każdej z badanej grupy zostały zmierzone dwie wartości:

— maksymalna liczba użytkowników mogących korzystać z systemu, przy zapewnieniujego stabilnej pracy.

— maksymalna liczba użytkowników mogących jednocześnie korzystać z aplikacji przyzapewnieniu stabilnej pracy systemu (próg czasu reakcji),

Stabilna praca systemu jest rozumiana jako praca bez błędów ze strony serwera. Podczastestów wydajnościowych najczęściej spotykana błędy związane są z przekroczeniem czasupołączenia.

6.1.3. Pomiar metryk kodu

Metryki kodu [14, 13] są podstawowym miernikiem jego jakości. Podczas pomiaru jako-ści kodu projektu zostaną wykorzystane elementy raportujące narzędzia Maven JDepend[35] oraz wtyczki platformy Eclipse o nazwie Metrics [41].

Plan pomiaru

Plan testów kodu projektu obejmuje zarówno kod języka Java modułu warstwy prezen-tacji projektu jak i kod szablonów. W celu uzyskania miarodajnego wyniku kody źródłoweobu aplikacji przed pomiarem został zweryfikowane przez aplikację PMD [45].Rodzaje metryk zostały podzielone na dwa rodzaje:

— metryki proste,— metryki złożone.Podczas badania jakości kodu zostały wykorzystane następujące metryki zaliczone do

grupy metryk prostych:— Liczba dzieci (ang. number of children) (NSC) czyli, całkowita liczba bezpośrednichdzieci (podklas) danej klasy. Klasy implementujące określony interfejs również zalicza-ne są do bezpośrednich jego dzieci.

— Głębokość drzewa dziedziczenia (ang. depth of inheritance tree) (DIT), czyli odległość(liczba rodziców) od klasy bazowej języka Java (klasy Object).

— Liczba przeciążonych metod (ang. number of overridden methods) (NORM), czyli cał-kowita liczba metod, posiadających określoną widoczność, które przeciążają odziedzi-czone metody przodków.

— Liczba metod (ang. number of methods) (NOM), czyli całkowita liczba metod klasy.— Liczba pól (ang. number of attributes) (NOF), czyli całkowita liczba pól klasy.— Liczba linii kodu (ang. lines of code), w tym:

78

— TLOC, całkowita liczba niepustych linii kodu nie będących komentarzami na jed-nostkę kompilacji,

— MLOC, całkowita liczba niepustych linii kodu nie będących komentarzami we-wnątrz ciała metod.

— Liczba klas (ang. number of classes) (NOC), czyli całkowita liczba konkretnych i abs-trakcyjnych klas danego pakietu; miara wyznaczająca rozszerzalność danego pakietu.

— Liczba interfejsów (ang. number of interfaces) (NOI), czyli całkowita liczba interfejsówdanego pakietu.

— Liczba pakietów (ang. number of packages)(NOP).W grupie metryk złożonych uwzględniono następujące metryki wchodzące do oceny

kodu aplikacji:— Indeks specjalizacji (ang. specialization index ) (SIX), czyli miara definiowana jako wy-nik NORM * DIT / NOM. Działa na poziomie klas, charakteryzuje miarę specjalizacjidanej klasy.

— Skojarzenia dośrodkowe (ang. Afferent Couplings) (CA), czyli liczba innych pakietów,których klasy korzystają z klas danego pakietu. Im większa, tym większa odpowie-dzialność pakietu.

— Skojarzenia odśrodkowe (ang. efferent couplings) (CE), czyli liczba innych pakietów,których klasy wykorzystywane są przez klasy danego pakietu. Im większa, tym większazależność pakietu.

— Abstrakcyjność (ang. abstractness) (RMA), czyli stosunek liczby klas abstrakcyjnychdo pozostałych w pakiecie. Metryka przyjmuje wartości od 0 do 1. A=0 oznacza pakietcałkowicie ukonkretniony, A=1 oznacza pakiet całkowicie abstrakcyjny.

— Niestabilność (ang. instability) (RMI), czyli stosunek skojarzeń odśrodkowych do wszyst-kich skojarzeń wyrażona równaniem I = CE / (CE + CA). Wskaźnik przyjmuje war-tości od 0 do 1. I=0 oznacza pakiet całkowicie stabilny, I=1 oznacza pakiet całkowicieniestabilny.

— Znormalizowana odległość kategorii od ideału (ang. distance from the main sequence)(RMD), czyli odległość od prostej wyznaczonej przez równanie RMA + RMI = 1. Me-tryka jest wskaźnikiem wyważenia pakietu pomiędzy abstrakcyjnością i stabilnością.Pakiet którego wartość metryki znajduje się na linii ideału uznaje się za optymalniezrównoważony względem abstrakcyjności i stabilności. Idealnie zrównoważony pakietjest albo całkowicie abstrakcyjny i stabilny (x=0, y=1) albo całkowicie konkretnyi niestabilny (x=1, y=0). Wskaźnik przyjmuje wartości z zakresu od 0 do 1. RMD=0wskazuje na pakiet idealny, RMD=1 wskazuje na pakiet maksymalnie oddalony odideału.W przypadku kodu szablonów zmierzono liczbę znaczników dynamicznej treści po-

trzebnych do zaimplementowania zadania związanego ze stworzeniem listy stronicowanej,widoku ze szczegółami obiektu, formularza modyfikacji obiektu, formularza dodawaniawizyty czy prostej listy prezentującej najbliższe spotkania.

Sposób przeprowadzenia pomiaru

Pomiar metryk kodu został przeprowadzony z wykorzystaniem narzędzi o ogólnodo-stępnym kodzie źródłowym, wtyczki raportującej projektu Maven o nazwie JDepend orazwtyczki środowiska Eclipse o nazwie Metrics.Proces pomiaru dotyczył głównie warstwy klienta, dla porównania zmierzono jednak

również pozostałe warstwy: dostępu do danych i logiki bizesowej.

79

Zmierzone metryki kodu zawierają informacje odnośnie trzech etapów budowy warstwyklienta dla aplikacji Petclinic:— umożliwiającym przegląd danych,— umożliwiającym manipulację zarządzanymi danymi,— posiadającym lokalizację dla języka polskiego i angielskiego.Ostatnim z elementów związanym z pomiarem metryk kodu było przedstawienie wpływurozwoju projektu na ich zmiany.

6.1.4. Badanie łatwości wprowadzania zmian

Model jakościowy zdefiniowany przez standard ISO/IEC 9126-1:2001 [31] definiujesześć charakterystyk, które mają za zadanie opisać wymagania pozafunkcjonalne systemu.Do wymienionych w standardzie charakterystyk zaliczają się: funkcjonalność, niezawod-ność, użyteczność, wydajność, łatwość konserwacji oraz przenośność.Łatwość konserwacji stanowi zbiór atrybutów opisujących nakład pracy niezbędny

w celu wprowadzenia zmian w oprogramowaniu. Każda z charakterystyk składa się z sze-regu tzw. atrybutów. Jeden z nich porusza kwestię łatwości wprowadzania zmian (ang.changeability). Łatwość wprowadzania zmian została zdefiniowana jako nakład pracy ko-nieczny do implementacji nowej funkcjonalności, usunięcia istniejącego błędu bądź dosto-sowania aplikacji do nowych warunków zewnętrznych.

Plan pomiaru

Atrybut łatwości wprowadzania zmian w systemie został zmierzony poprzez obserwacjęzmian dokonywanych w projekcie podczas jego modyfikacji, w poszczególnych jego etapachwyróżnionych w rozdziale 5.3.Pierwszą z czynności poddanych ocenie łatwości wprowadzania zmian było stworzenie

widoku listy obiektów, w postaci stronicowanej tabeli. Drugi badany przypadek doty-czył zbudowania formularza mającego za zadanie dodanie nowego obiektu do aplikacji.Ostatnie zadanie polegało na lokalizacji komunikatów i treści aplikacji.

Sposób przeprowadzenia pomiaru

Pomiar opisywanego atrybutu będzie zmierzony poprzez zliczenie liczby plików projek-tu, które w wyniku przeprowadzanego działania zostały dodane, zmodyfikowane bądź uzu-pełnione. Różnica między modyfikacją a uzupełnieniem polega na tym, iż podczas wpro-wadzania modyfikacji dotychczasowa treść pliku ulega częściowej lub całkowitej zmianie.Uzupełnienie polega natomiast wyłącznie na dodaniu nowej zawartości bez modyfikacjitreści wcześniej istniejących.Do pomiaru łatwości wprowadzania zmian bazujących na etapie przeglądania danych

wybrano tabelę stronicową służącą do prezentacji historii wizyt. Omawiana tabela skła-da się z sześciu kolumn opisujących dzień, godzinę, imię i nazwisko właściciela, nazwęzwierzęcia, nazwę wizyty oraz dodatkowej kolumny zawierającej spis operacji, możliwejdo wykonania na każdej z wizyt takich jak pokazanie szczegółów, zmienienie danych czyusunięcie wizyty. Podczas tego etapu zostanie zmierzona praca włożona w:— stworzenie odpowiednich mapowań pomiędzy adresami URL żądania a kontrolerami,— stworzenie szablonu strony,— modyfikacji plików konfiguracyjnych aplikacji.W drugim etapie została oceniona praca polegająca na stworzeniu formularza umożli-

wiającego dodanie nowego klienta, wraz z walidacją wprowadzanych danych.

80

Pomiar trzeciego etapu dokonano przy zadaniu polegającym na lokalizacji treści komu-nikatów o błędach oraz dodaniu możliwości przełączania się między wersjami językowymiaplikacji.

6.1.5. Badanie dostępności komponentów Triniad

Dostępność jest nauką oraz zbiorem standardów definiujących wytyczne w zakresietworzenia stron WWW w celu zwiększenia ich dostępności dla jak najszerszej grupy użyt-kowników, w tym również użytkowników niedosłyszących czy niedowidzących.Mianem WAI (ang. Web Accessibility Initiative) [61] określa się inicjatywę W3C [62],

tworzącą między innymi zbiór standardów dotyczących dostępności dla aplikacji interne-towych.W swoich wytycznych WAI odnosi się między innymi do spraw związanych z:

— formą prezentowania zawartości stron internetowych,— aplikacjami służącymi do tworzenia stron internetowych,— przeglądarkami internetowymi,— aplikacjami internetowymi.Ze względu na charakter aplikacji w dalszej części opisu zostaną uwzględnione wytycznezwiązane z formą prezentacji.Badaniu dostępności została poddana aplikacja zaimplementowana z wykorzystaniem

frameworka JavaServer Faces, gdyż wykorzystanie tej technologii powoduje, iż wiele ele-mentów interfejsu jest tworzonych automatycznie bez możliwości ingerencji programisty.W przypadku wykorzystania Spring MVC, programista sam musi zadbać o zgodność apli-kacji z wytycznymi dostępności. Automatyczne generowanie zawartości strony, na pod-stawie szablonu z wykorzystaniem JavaServer Faces wpływa na zmniejszoną kontrolą nadzawartości strony.Celem pomiaru badającego dostępność komponentów aplikacji opartej o JavaServer

Faces było wykazanie poprawności automatycznie generowanych komponentów pod wzglę-dem ich dostępności. Pomiar dostępności dotyczył wyłącznie elementów generowanychautomatycznie przez badany szkielet.

Plan i sposób przeprowadzenia pomiaru

Podczas testów zostały zmierzone kwestie opisane w dokumencie Web Content Acces-sibility Guidelines [16], wersja 1.0, związane w szczególności z:— poprawnością kodu strony,— poprawnością w kontekście pracy w środowisku różnych przeglądarek internetowych.Wymienione elementy mieszczą się w części specyfikacji określonej mianem Core Techni-ques for WCAG 1.0 [15].Poprawność walidacji kodu strony, która jest przetwarzana przez przeglądarkę użyt-

kownika zostanie zmierzona względem deklaracji poprawności autorów komponentów, czy-li specyfikacją HTML 4.01 Transitional [46]. W końcowym wyniku zostanie uwzględnionaliczba ostrzeżeń oraz błędów zgłaszanych przez walidator.Poprawność działania komponentów zweryfikowano manualnie z użyciem przeglądarek

Internet Explorer 6, Firefox 2 oraz Opera 9. Podczas badania możliwe było uzyskaniejednej z trzech wartości, przyporządkowanych w następujący sposób:— 0, komponent nie jest wyświetlany poprawnie przez co uniemożliwia prawidłową pracę,— 1, renderowanie komponentu nie przebiega prawidłowo jednak jest możliwe uzyskaniezamierzonego rezultatu,

— 2, komponent działa w pełni poprawnie.

81

Tabela 6.1: Komponenty Triniad poddane badaniu dostępności

breadCrumbs chart chooseColorchooseDate commandButton commandLinkcommandNavigationItem goButton goLinkinputColor inputData inputFiletable inputListOfValues inputNumberSpinboxinputText legend messagesnavigationPane navigationTree outputFormattedoutputLabel outputText selectBooleanCheckboxselectBooleanRadio selectManyCheckbox selectManyListboxselectManyShuttle selectOneChoice selectOneListboxselectOneRadio selectOrderShuttle selectRangeChoiceBarshowDetail showManyAccordion showOneAccordionsingleStepButtonBar treeTable

Badaniu zostały poddane wyłącznie komponenty wizualne wymienione w tabeli 6.1.Stanowią one 55% wszystkich dostępnych komponentów. Reszta to elementy niewizualnegrupujące elementy bądź formujące stronę w inny sposób.

6.2. Analiza wyników

Niniejsza część przedstawia analizę wyników uzyskanych w wyniku przeprowadzonycheksperymentów z wykorzystaniem aplikacji Petclinic.

6.2.1. Wydajność

Eksperymenty dotyczące wydajności zostały przeprowadzone na ostatecznych wersjachobu badanych aplikacji. W testach uczestniczyły opisane w części 6.1.2 trzy grupy osób.Testy zostały przeprowadzone wielokrotnie dla każdego z przypadków. Prezentowane

wartości stanowią wartość średnią uzyskanych wyników. Dla zwiększenia pewności wyni-ków eksperymentu, czas trwania wszystkich testów ustalono na pół godziny.Tabela 6.2 przedstawia liczbę żądań uzyskaną dla każdej z grup. Przed znakiem uko-

śnika podano wartości dla aplikacji opartej o Spring MVC, po znaku podano wartośćdla aplikacji wykorzystującej JSF. Pierwszy wiersz przedstawia maksymalną liczbę uzy-skanych żądań, które zakończyły się powodzeniem. Drugi prezentuje liczbę żądań, którabyła możliwa do wykonania w ustalonym czasie 3 sekund na odpowiedź. W przypadkunie zwrócenia odpowiedzi w żądanym czasie bądź zwrócenia odpowiedzi błędnej test byłkończony.W pierwszym teście składającym się z użytkowników pierwszej grupy widoczna jest

znacząca różnica pomiędzy wartością maksymalną liczby żądań obsługiwanych jednocze-śnie przez serwer, różnica jest ponad dwukrotna. Wynika to bezpośrednio z faktu, iż apli-kacje oparte o JavaServer Faces starają się upodobnić do aplikacji desktopowych. Wiążesię to jednak z obciążeniem wszystkich żądań danymi składowanymi w sesji. Każde żą-danie kierowane do aplikacji wykorzystującej szkielet JavaServer Faces posiada ciasteczkoo średnim rozmiarze 5 kB. Wpływa to znacząco na wydajność aplikacji, w analizowa-nych przypadku ponad dwukrotnie. Wysyłane dane przechowują stan często złożonychkomponentów między poszczególnymi żądaniami HTTP.

82

Tabela 6.2: Liczba żądań w zależności od badanej grupy użytkowników

Pomiar Grupa 1 Grupa 2 Grupa 3Maks. liczba żądań 478/190 263/172 317/184Maks. liczba żądań w 3 sek. 54/38 52/35 37/26Wielkość w liczniku dotyczy Spring MVC, w mianowniku – JavaServer Faces

Tabela 6.3: Średni czas odpowiedzi aplikacji w zależności od badanej grupy użytkowników

Pomiar Grupa 1 Grupa 2 Grupa 3Maks. liczba żądań 0,4/1,9 0,6/0,8 0,54/1,4Maks. liczba żądań w 3 sek. 0,25/0,5 0,12/0,27 0,19/0,36Wielkość w liczniku dotyczy Spring MVC, w mianowniku – JavaServer Faces

W drugiej z badanych grup uczestniczyły osoby modyfikujące wyłącznie dane aplikacji.W związku z wykonywaniem czynności mających odzwierciedlenie w bazie danych aplika-cji, wydajność znacząco spadła. Żądania, które skutkują wykonaniem operacji modyfiku-jących na danych składowanych w bazie danych są znacznie bardziej kosztowne od stan-dardowych żądań, które pobierają dane. O ile w przypadku aplikacji petclinic-springmvcspadek był znaczny to aplikacja petclinic-jsf zanotowała jedynie niewielki spadek ze 190do 172 żądań. Ta sytuacja ma prawdopodobnie miejsce z powodu wielkości przesyłanegociasteczka, które przy zwiększonej liczbie żądań zaczyna odgrywać znaczącą rolę.W trzeciej grupie składającej się z dwóch poprzednich w proporcji 4/1 uzyskane wy-

niku plasują się między wynikami opisywanych wcześniej grup. Liczba żądań aplikacjiopartej o Spring MVC nie uległa spodziewanemu zwiększeniu i pomimo proporcji prefe-rujących użytkowników przeglądających dane, wynik jest zbliżony badziej do liczby żądańw przypadku drugiej grupy.W drugim wierszu przedstawiono wartości średnie dla zmierzonej liczby żądań z usta-

lonym limitem czasowym na odpowiedź. Również podczas tego testu lepsza okazała sięaplikacja wykorzystująca framework Spring MVC, charakteryzują ca się większą liczbęobsłużonych żądań. Na uwagę zasługuje stały we wszystkich grupach stosunek żądańaplikacji opartej o Spring MVC oraz JavaServer Faces wynoszący około 1,4.Kolejna tabela 6.3 przedstawia, w sekundach, wielkości średnie czasów odpowiedzi dla

żądań z poprzedniej tabeli. Przed znakiem ukośnika podano wartości dla aplikacji opartejo Spring MVC, po znaku podano wartość dla aplikacji wykorzystującej JSF.Ponownie aplikacja wykorzystująca Spring MVC wypada korzystniej w prezentowa-

nym porównaniu. Największa różnica średniego czasu odpowiedzi dotyczy testu mierzące-go maksymalną możliwą do obsłużenia liczbę żądań z wykorzystaniem grupy 1. Pozostałewielkości różnią się w większości przypadków o 50%. Najbardziej zbliżony czas odpowiedziwystępuje w teście wykorzystującą grupę drugą. Świadczy to o tym, iż aplikacja opartao szkielet JavaServer Faces o niewielkiej liczbie różnych żądań upodabnia się pod względemwydajnościowym do aplikacji wykorzystującej Spring MVC.

6.2.2. Metryki kodu

Celem pomiaru metryk kodu było porównanie wielkości zaimplementowanych pro-jektów jak również jakości powstałego kodu. Podczas eksperymentów uwzględniono kod

83

Tabela 6.4: Metryki kodu modułów aplikacji

Metryka data core springmvc jsfLiczba linii kodu 1048 450 1195 977Liczba linii kodu metod 259 93 477 407Liczba klas 23 10 29 21Liczba interfejsów 9 9 0 1Liczba pakietów 5 3 7 7Liczba metod 137 47 115 130Liczba pól 29 20 29 41

projektu w języku Java jak również kod stron, odpowiedzialny za wizualne przedstawieniedanych. Obie grupy metryk zostaną przedstawione poniżej.

Kod Javy

Tabela 6.4 ma za zadanie pokazać wielkość zaimplementowanych projektów. Zmierzo-no liczbę linii kodu, artefaktów oraz elementów klas poszczególnych modułów projektu.W analizie uwzględniono moduł odpowiedzialny za dostęp do danych, logikę biznesowąaplikacji jak również moduły implementujące warstwę aplikacji internetowej zaimplemen-towane z wykorzystaniem szkieletów Spring MVC oraz JavaServer Faces.W przypadku linii kodu zostały zmierzone dwie metryki. Pierwsza z nich jest związana

z całkowitą liczbą linii kodu całej aplikacji, druga dotyczy wyłącznie kodu umieszczonegow metodach. Projekt oparty o Spring MVC zawiera więcej linii kodu niż projekt opartyo JavaServer Faces. Stosunek wielkości ulega jedynie nieznacznemu zmniejszeniu przy po-równaniu metryki zliczającej liczbę linii kodu w metodach. Wartym zauważenia jest fakt,iż najmniejszy z modułów dotyczy logiki biznesowej. Jest on ponad czterokrotnie mniejszyod modułów warstwy aplikacji internetowej. Zauważona różnica świadczy o charakterzeaplikacji służącej do zarządzania danymi (aplikacja typu CRUD [54]), w której nie mapotrzeby istnienia rozwiniętej logiki biznesowej.Liczba artefaktów projektu tzn. liczba klas, interfejsów bądź pakietów w porównywa-

nych warstwach aplikacji internetowej jest w przybliżeniu taka sama, z wyjątkiem liczbyklas, która jest większa w projekcie wykorzystującym Spring MVC. Ponownie moduł lo-giki biznesowej (kolumna core) zawiera najmniejszą ilość elementów. Na uwagę zasługujeinterfejs wykorzystany w aplikacji opartej o JavaServer Faces, który posłużył jako klasanarzędziowa gromadząca nazwy beanów, potrzebne w celu późniejszego odwołania się donich z aplikacji.Ostatnim elementem wskazującym na wielkości modułów jest liczba pól i metod. Są

to jedyne metryki, w których Spring MVC posiada niższe wartości w porównaniu z Ja-vaServer Faces. Wynika to, ze sposobu tworzenia aplikacji z wykorzystaniem JavaServerFaces, która opiera się na zastosowaniu komponentów. Tworzone komponenty są zwykły-mi obiektami Javy (POJO), które udostępniają swój wewnętrzny stan poprzez metodydostępowe. Wspomniane metody wykorzystywane są głównie z poziomu kodu szablonów,poprzez odpowiednie ich wywołania. Zastosowanie modelu komponentowego powodujezwiększenie liczby pól w klasach oraz metod dostępowych.Kolejne porównanie dotyczy metryk kodu z podziałem funkcjonalnym pakietów według

pełnionych funkcji. Wprowadzono podział na kod walidacji (VAL), kontrolerów (WEB),

84

Tabela 6.5: Metryki kodu pakietów według pełnionych funkcji

Metryka VAL WEB UT CON LST FORMLiczba linii kodu 59/– 233/109 67/149 150/63 93/336 573/300Liczba linii kodu metod 34/– 91/31 30/68 64/28 32/156 223/121Liczba klas 2/– 6/4 2/3 3/2 7/6 9/5Liczba interfejsów 0/– 0/0 0/1 0/0 0/0 0/0Liczba metod 4/– 22/22 0/3 20/4 0/54 60/45Liczba pól 0/– 7/4 0/1 7/0 7/17 15/19Wielkość w liczniku dotyczy Spring MVC, w mianowniku – JavaServer Faces

narzędziowy (UT), konwersji (CON), wyświetlania listy obiektów (LST) oraz związany zobsługą formularzy (FORM).Tebela 6.5 przedstawia wielkości odpowiednich metryk. Przed ukośnikiem podano

wartość metryki dla aplikacji opartej o Spring MVC, po dla aplikacji wykorzystującejJavaServer Faces.Aplikacja oparta o JavaServer Faces nie posiadała w kodzie aplikacji logiki związanej

z walidacją wprowadzanych danych. Wszystkie aspekty weryfikacji wprowadzanych da-nych udało się zaimplementować z wykorzystaniem tagów biblioteki Trinidad w kodzieszablonów.W przypadku kodu narzędziowego zawierającego klasy pomocnicze aplikacji, porówna-

nie wypada na korzyść aplikacji wykorzystującej Spring MVC. Wymagana liczba linii kodujest dwukrotnie mniejsza. W przypadku JavaServer Faces konieczna była implementacjaklas pomocniczych związanych z dostępem do zarządzanych beanów z poziomu aplikacjijak również klas przechowujących informacje potrzebne do lokalizacji.Czynność związana z konwersją wprowadzanych danych na obiekty języka Java, była

łatwiejsza do zaimplementowania z wykorzystaniem szkieletu JSF. Na ponad dwukrotnejróżnicy w liczbie linii kodu zaważył brak konieczności implementacji konwertera wyświe-tlającego listę leków.Porównanie dalszych funkcjonalności jest utrudnione ze względu na zastosowanie zróż-

nicowanego modelu, wynikającego z natury użytych szkieletów programistycznych. Modułkontrolerów (WEB) w przypadku aplikacji opartej o Spring MVC stanowi klasyczny zbiórkontrolerów odbierających żądania od użytkownika. W przypadku aplikacji JavaServerFaces rolę kontrolerów w znacznej części pełnią komponenty, których kod został uwzględ-niony w kolumnie LST. Kontrolery aplikacji opartej o szkielet JSF pełnią rolę fasady logikibiznesowej, używanych pomocniczo przez klasy komponentów.Ostatnim opisywanym elementem jest kod związany z obsługą formularzy (FORM).

Podejście zastosowane w JavaServer Faces, które jest bardziej podobne do tworzenia apli-kacji desktopowych skutkuje prawie dwukrotnie mniejszą liczbą linii kodu. W rzeczywisto-ści część logiki znajduje się również w kodzie związanym z wyświetleniem listy obiektów.Wyniki pozostałych metryk prostych (nie zostały przedstawione w tabeli) tj. liczba

dzieci, głębokość drzewa dziedziczenia czy liczba przeciążonych metod wskazują na cha-rakterystyczne elementy poszczególnych projektów. W projekcie opartym o Spring MVCelementem wyróżniającym się są klasy formularzy, które mają największą wartość głę-bokości drzewa dziedziczenia, średnio równą 8,78 oraz posiadają najwięcej przeciążonychmetod, średnio 3,11. W przypadku projektu wykorzystującego JavaServer Faces śred-nia głębokość drzewa dziedziczenia wynosi 1. Podobne wartości wskazują metryki liczby

85

Tabela 6.6: Metryki złożone aplikacji opartej o Spring MVC oraz JavaServer Faces

Metryka Spring MVC JavaServer FacesIndeks specjalizacji 1,862 0Skojarzenia dośrodkowe 0,857 2,429Skojarzenia odśrodkowe 4,143 2,714Abstrakcyjność 0,016 0,036Niestabilność 0,829 0,664Znormalizowana odległość 0,187 0,3

przeciążonych metod oraz liczby dzieci, które wynoszą 0. Ma to ścisły związek z brakiemkonieczności dziedziczenia po klasach frameworka JSF, skutkujący mniejszą inwazyjnościąszkieletu.Wynik pomiaru metryk złożonych przedstawia tabela 6.6. Przedstawiono wartości

średnie obliczone na podstawie metryk pakietów każdej z aplikacji.Indeks specjalizacji bazuje na stosunku ilorazu liczby przeciążonych metod oraz głę-

bokości drzewa dziedziczenia do liczby metod w klasie. W związku z tym, iż aplikacjaoparta o JavaServer Faces nie posiada przeciążonych metod wynik ilorazu wynosi 0.Metryka skojarzenia dośrodkowego wskazuje na średnią wartość odpowiedzialności dla

pakietów (ang. package’s responsibility). W przypadku Spring MVC jest ona ponad dwu-krotnie mniejsza, co oznacza iż pakiety tej aplikacji posiadają mniejszą odpowiedzialnośćw porównaniu z aplikacją korzystającą z JavaServer Faces. W aplikacji opartej o SpringMVC największą odpowiedzialność posiadają pakiety narzędziowe oraz pakiety konwer-terów, w aplikacji wykorzystującej szkielet JSF pakiety narzędziowe oraz pakiety kontro-lerów.Metryka skojarzenia odśrodkowego wskazuje średnią wartość zależności od innych pa-

kietów. W przypadku aplikacji wykorzystującej Spring MVC najbardziej zależne są pa-kiety formularzy, kontrolerów oraz list obiektów. Dla aplikacji opartej o JSF największewartości opisywanej metryki posiadają pakiety kontrolerów oraz listy obiektów.Stosunek skojarzenia odśrodkowego oraz skojarzenia dośrodkowego w przypadku obu

analizowanych projektów jest różny. Dla projektu petclinic-springmvc wynosi prawie 5a dla petclinic-jsf nieco ponad 1. Prowadzi to do wniosku, iż w aplikacji opartej o SpringMVC znaczna liczba klas umieszczonych we wspomnianych pakietach zależy od niewielkiejliczby innych klas. W przypadku aplikacji wykorzystującej JavaServer Faces mniej więcejpodobna liczba klas zgrupowanych w pakiety korzysta i udostępnia swoje usługi.Abstrakcyjność obu projektów jest na podobnie niskim poziomie, zdiagnozo wano

znacznie większą liczbę klas konkretnych w porównaniu do liczby klas abstrakcyjnychbądź interfejsów.Niestabilność będąca ilorazem skojarzeń odśrodkowych do sumy wszystkich skoja-

rzeń jest większa w przypadku aplikacji petclinic-springmvc. Jest to konsekwencja war-tości opisywanych wcześniej skojarzeń. W przypadku aplikacji petclinic-springmvc jaki petclinic-jsf najbardziej niestabilnymi są pakiety narzędziowe.Ostatnią z metryk złożonych jest metryka dotycząca znormalizowanej odległości kate-

gorii od ideału wskazującą na wyważenie pakietu pomiędzy abstrakcyjnością a jego sta-bilnością. W tym przypadku lepiej wypada projekt oparty o Spring MVC, gdyż wartośćmetryki jest bliższa zeru. Wynika to z większej niestabilności projektu przy niewielkiejabstrakcyjności.

86

Rysunek 6.2: Zmiana wartości metryk podczas kolejnych etapów implementacji aplikacji

Ostatnim elementem bazującym na metrykach kodu projektów jest przedstawieniezmian wartości metryk kodu na przykładzie artefaktów projektu, podczas implementacjikolejnych etapów projektu. Zmiany prezentuje rysunek 6.2.Wyróżniono trzy etapy implementacji związane z przeglądaniem danych (browsing),

zarządzaniem danymi (managing) oraz lokalizacją aplikacji (web). Teoretycznie proceslokalizacji aplikacji powinien przebiegać niezależnie od procesu implementacji aplikacji.Rysunek 6.2 wskazuje, iż w obu badanych aplikacjach procesowi lokalizacji towarzyszyłnieznaczny wzrost liczby artefaktów. Dowodzi to poprawności obu rozwiązań w zakresieinternacjonalizacji.

Kod szablonów

Badaniu metryk kodu został również poddany kod szablonów formatujących wyświe-tlane dane. Wprowadzono podział na następujące typy widoków:— lista stronicowana,— szczegóły obiektu,— formularz modyfikacji,— formularz dodawania wizyty,— prosta lista posiadająca ustaloną liczbę wierszy.Pierwszy z przeprowadzonych eksperymentów dotyczył liczby znaczników, generują-

cych treść w dynamiczny sposób potrzebnych do zaimplementowania widoku o określonymcharakterze. Rysunek 6.3 przedstawia średnią liczbę znaczników wyliczoną na podstawiewidoków obu aplikacji.Z wykresu bezpośrednio wynika, iż liczba znaczników potrzebna do wyświetlenia dyna-

micznej treści jest większa w przypadku aplikacji wykorzystującej JavaServer Faces. Naj-większa różnica występuje w przypadku prostej listy, która w aplikacji petclinic-jsf zostałazaimplementowana na bazie listy stronicowanej. Narzut takiego rozwiązania, pod wzglę-dem liczby znaczników, wydaje się duży, jednak biblioteka Trinidad nie posiada prostszegokomponentu przeznaczonego do tego celu. Podobnie duża różnica istnieje w przypadkulisty stronicowanej jednak tutaj wynikowa lista jest bardziej złożona od analogicznej li-sty w aplikacji petclinic-springmvc. Najmniejszą różnica dotyczy formularza modyfikacji

87

Rysunek 6.3: Liczba znaczników wg rodzaju widoków

Rysunek 6.4: Wielkość wygenerowanej strony HTML

obiektu. Biorąc pod uwagę dodatkowy narzut w postaci znaczników walidujących w apli-kacji opartej o szkielet JSF sumarycznie mierzona złożoność jest porównywalna.Rysunek 6.4 przedstawia wielkość wygenerowanej strony HTML. Wielkość wszystkich

zmierzonych stron szablonów z obu aplikacji była podobna i mieściła się w granicach 7kB. Dopiero zamienienie dynamicznych znaczników na statyczną treść wprowadziło kilkukrotną różnicę na niekorzyść stron utworzonych z wykorzystaniem biblioteki Trinidad.Największa różnica występuje w przypadku list, jest to uzasadnione po części stopniemzłożoności wygenerowanej listy stronicowanej. Różnica w wielkości powstałych stron wy-nika w głównej mierze z dodanych elementów języka JavaScript.

6.2.3. Dostępność komponentów Trinidad

Kolejny z przeprowadzonych eksperymentów dotyczył pomiaru dostępności kompo-nentów Trinidad wykorzystywanych w aplikacji opartej o JavaServer Faces.W pierwszym z testów zmierzono poprawność komponentów według przedstawionej

88

Tabela 6.7: Poprawność działania komponentów Triniadad

Przeglądarka internetowa Liczba punktówInternet Explorer 6.0 SP2 62Internet Explorer 7.0.6000.16441 62Firefox 2.0.0.3 59Opera 9.20 50

wcześniej trójstopniowej skali, w zależności od użytej przeglądarki internetowej. Wynikiprzedstawia tabela 6.7Rysunek 6.5 prezentuje udział komponentów według poprawności działania w wybra-

nych przeglądarkach internetowych.

Rysunek 6.5: Poprawność działania komponentów wg przeglądarek internetowych

W wyniku przeprowadzonego testu okazało się, iż komponenty działają bezbłędniejedynie w przeglądarkach Internet Explorer w wersji 6 oraz 7. Nieznacznie gorzej wypadłykomponenty podczas pracy z przeglądarką Firefox 2.0. Jedynie trzy elementy interfejsuużytkownika (chooseDate, inputData oraz inputListOfValuesnie) działały we właściwysposób. Podczas wyświetlania okna modalnego możliwa była modyfikacja zawartości po-przednio wyświetlanego okna, usterka ta jednak nie miała wpływu na pracę z aplika-cją. Najgorzej wypadły komponenty podczas pracy z przeglądarką Opera w wersji 9.20.Trzy komponenty (chooseDate, inputData oraz selectBooleanCheckbox) pracowały nie-właściwie zwracając kod wewnętrznego błędu serwera. Dwa kolejne (navigationTree orazinputNumberSpinbox) nie działały w pełni poprawnie – posiadały nieprawidłowy wygląd.Kolejny test dotyczył walidacji komponentów Triniad z wykorzystaniem oficjalnego

walidatora organizacji W3C dla specyfikacji HTML 4.01 Transitional.Podczas testów walidacja części z komponentów kończyła się komunikatem o wewnętrz-

nym błędzie serwera o następującej treści „the server encountered an internal error() thatprevented it from fulfilling this request”. Ograniczyło to badaną grupę komponentówo sześć elementów. Dodatkowo komponent selectOneChoice podczas pracy zgłaszał ko-munikat błędu o treści „ javax.faces.FacesException: SelectItem with no value” co równieżwykluczyło go z badanej puli komponentów. Ostatecznie w testach walidacyjnych wzięłoudział 31 komponentów.

89

Rysunek 6.6: Udział błędów określonego typu w komponentach Trinidad

W wyniku przeprowadzonych testów okazało się, iż znalezione błędy w ponad 95%należą do jednej z czterech grup. Rysunek 6.6 przedstawia procentowy udział błędóww badanych komponentach. Do najczęściej spotykanych błędów należała niepoprawnawartość atrybutu id znaczników, które zaczynały się od znaku dolara bądź podkreśle-nia. Braku atrybuty type w znaczniku script. Niepoprawnym umieszczeniu znacznika,najczęściej dotyczyło to znacznika tr. Braku odpowiadającego znacznika zamykającego,najczęściej dla znaczników caption oraz table.Ponad 1/3 ze zbadanych komponentów nie posiadała błędów, 13% posiadało jeden

błąd a 20% dwa błędy. Komponenty z liczbą błędów mieszczącą się między trzy a siedemstanowiły około 1/4 wszystkich komponentów. Ponad 6% elementów interfejsu użytkow-nika posiadało ponad siedem błędów. Średnia liczba błędów przypadająca na komponentwyniosła 2,81. Walidator nie stwierdził w żadnym z badanych komponentów treści gene-rującej ostrzeżenia.Do komponentów o największej liczbie błędów należą w kolejności inputColor z 19

błędami, chooseColor z 13 błędami oraz selectManyCheckbox z 7 błędami.Należy zauważyć, iż wychwycone błędy można łatwo usunąć poprzez poprawnienie

metody generującej identyfikatory dla znaczników id, aby nie umieszczały na początkuniedozwolonych znaków, dodanie odpowiednich znaczników zamykających czy uzupełnie-nie wybranych znaczników o wymagane atrybuty.

6.2.4. Łatwość wprowadzania zmian

Pomiar łatwości wprowadzania zmian w aplikacji bazuje na liczbie plików które należyzmodyfikować, uzupełnić lub dodać w celu wykonania określonego zadania. Definicje akcjiwraz z opisem zadań zostały zamieszczone w części 6.1.4.Tabela 6.8 przedstawia wynik eksperymentu mierzącego łatwość wprowadzania zmian

na podstawie liczby plików, w których należy dokonać zmian. Wartość przed ukośnikiemodnosi się do aplikacji opartej o Spring MVC, wartość po do aplikacji wykorzystującejJavaServer Faces. Zmierzone czynności dotyczą dodania do aplikacji listy stronicowanej,formularza oraz lokalizacji aplikacji.Podczas dodania kolejnej listy stronicowanej w aplikacji opartej o Spring MVC należy

zmodyfikować plik petclinic-servlet.xml, dodać nowe mapowanie do kontrolera orazzdefiniować metodę odpowiedzialną za obsługę żądania wyświetlenia listy wizyt. Wspo-mniane operacje mają charakter uzupełnienia wspomnianego pliku konfiguracyjnego. Ko-

90

Tabela 6.8: Łatwość wprowadzania zmian a liczba zmienionych plików

Czynność Lista stronicowana Formularz LokalizacjaDodawanie 2/2 3/1 1/2Uzupełnienie 2/1 2/1 1/1Modyfikacja 0/0 0/0 0/0Wielkość w liczniku dotyczy Spring MVC, w mianowniku – JavaServer Faces

lejne zadanie polega na dodaniu nowego pliku kontrolera do projektu oraz zaimplemento-wania zadeklarowanej wcześniej metody. Następne zadanie sprowadza się do utworzeniaodpowiedniego pliku szablonu przedstawiającego stronicową listę wizyt. W ostatnim krokunależy zdefiniować mapowanie logicznej nazwy widoku do pliku z szablonem za pomocąwpisu w pliku views.properties.W przypadku aplikacji opartej o szkielet JSF dodanie kolejnej listy stronicowanej

zaczyna się od deklaracji zarządzanego beana zwracającego listę obiektów w pliku kon-figuracyjnym faces-config.xml. Nie ma potrzeby definiowania dodatkowych mapowań,gdyż wywołanie zasobu skutkuje automatycznym odwołaniem do odpowiedniego szablo-nu. W następnym kroku tworzony jest kod zadeklarowanego beana. Następnie tworzymyszablon z wykorzystaniem komponentów Trinidad (m.in. listy stronicowanej) oraz zdefi-niowanego wcześniej odwołania do beana.W porównaniu do aplikacji opartej o Spring MVC aplikacja petclinic-jsf wymaga mniej-

szego nakłady pracy. Modyfikacja pliku konfiguracyjnego odbywa się jedynie w jednymmiejscu. Nie istnieje również potrzeba definiowania mapowania logicznej nazwy widoku.Dodanie formularza modyfikacji klienta w aplikacji petclinic-springmvc polega tak jak

w poprzedniej czynności na stworzeniu odpowiednich mapowań oraz kontrolerów. Dodat-kowo należy stworzyć obiekt walidatora, który zweryfikuje wprowadzone przez użytkow-nika dane.Utworzenie formularza w aplikacji wykorzystującej szkielet JSF, polega na dodaniu

odpowiedniej metody do wcześniej już stworzonego komponentu zajmującego się obsługąużytkowników. Utworzeniu nowego szablonu. W przypadku prostych formularzy wystar-czające okazuje się skorzystanie z walidatorów zaimplementowanych w postaci znacznikówbiblioteki Triniadad.Podsumowując czynność utworzenia formularza, framework JavaServer Faces wypada

lepiej. W aplikacji petclinic-springmvc należy wykonać wszystkie kroki znane z czynnościdodawania listy stronicowanej oraz dodatkowo zdefiniować klasę walidującą i dodać wpiso tym do pliku konfiguracyjnego. Aplikacja petclinic-jsf wymaga dodania jedynie nowegopliku szablonu oraz uzupełnienia beana o dodatkową metodę dodającą nowego użytkow-nika. Ma to również swoje odbicie w metrykach kodu. W aplikacji opartej o Spring MVCjest więcej klas, natomiast w aplikacji wykorzystującej szkielet JSF klas jest mniej, jednakposiadają większą liczbę metod i pól.Ostatnią z przedstawianych czynności jest lokalizacja aplikacji. W aplikacji opartej

o Spring MVC należy najpierw dodać odpowiednie beany do pliku konfiguracyjnego.Następna czynność polega już na podaniu plików z przetłumaczonymi komunikatami,w osobnych plikach dla każdego z obsługiwanych języków. Przełączanie między wersjamijęzykowymi aplikacji jest rozwiązane za pomocą wpisów w pliku konfiguracyjnym.Lokalizacja aplikacji wykorzystującej JavaServer Faces polega na dodaniu odpowied-

niego wpisu w pliku konfiguracyjnym informującym o obsługiwanych przez aplikację języ-

91

kach. Następna czynność polega tak jak w przypadku poprzedniej biblioteki na dodawaniuplików z tłumaczeniem komunikatów. Jest to jednak czynność opcjonalna, gdyż bibliotekaTriniadad posiada polskie tłumaczenia komunikatów o błędach walidacji w formularzach.Bardziej pracochłonną czynnością jest dodanie przełącznika wersji językowych. JavaServerFaces nie posiada domyślnie wsparcia w tym zakresie. Wymagane jest dodanie nowegopliku, który będzie przechowywał informację na temat wybranego języka oraz uzupełnieniepliku konfiguracyjnego.Czynność lokalizacji w przypadku aplikacji opartej o JavaServer Faces jest znacznie

bardziej przystępna. Komunikaty są domyślnie wyświetlane w języku użytkownika, niema więc potrzeby samodzielnej ich lokalizacji. Spring MVC wypada lepiej w czynnościzwiązanej z dodaniem możliwości przełączania się pomiędzy wersjami językowymi apli-kacji, wymagane jest jedynie dodanie odpowiedniego beana do pliku konfiguracyjnego.JSF nie posiada takiej możliwości, można to rozwiązać poprzez dodanie nowego beana,przechowującego informację o wybranej wersji językowej.Opisane czynności dotyczyły dodawania nowych elementów do aplikacji. Zadowalający

zatem jest fakt, iż nie była koniecza modyfikacja istniejących już plików, zmiana ichzawartość polegała jedynie na uzupełnieniu treści.

92

7. Podsumowanie

Celem niniejszej pracy było przedstawienie nowoczesnego środowiska programistycz-nego przeznaczonego do implementacji aplikacji internetowych oraz dokonanie analizydwóch szkieletów programistycznych Spring MVC oraz JavaServer Faces. Zamieszczonew pracy porównanie miało za zadanie ułatwienie programiście dokonanie wyboru międzydwoma alternatywnymi rozwiązaniami.

Realizacja celów pracy

Opisane nowoczesne środowisko programisty pozwala na tworzenie zaawansowanychaplikacji internetowych zgodnie z praktyką TDD. Opisano narzędzia integracyjne jak rów-nież służące do przeprowadzania testów jednostkowych i funkcjonalnych. W opisie narzędzizawarto podstawowe informacje wprowadzające czytelnika do tematu wraz ze wskazaniemumiejscowienia aplikacji w warsztacie programisty. Tam gdzie to było możliwe umieszczo-no przykłady ilustrujące ideę funkcjonowania opisywanej aplikacji.Analiza teoretyczna przedstawiła zagadnienia związane z funkcjonowaniem badanych

szkieletów programistycznych. Wskazała podobieństwa oraz różnice w działaniu obu ramprojektowych. Omawiając równocześnie mocne i słabe strony każdego z rozwiązań w sy-tuacjach typowych dla działania aplikacji internetowych, w analizie zwrócono uwagę nanajważniejsze aspekty związane z działaniem ram projektowych począwszy od architek-tury a kończąc na zagadnieniach związanych z walidacją i lokalizacją aplikacji.Implementacja aplikacji służącej do zarządzania kliniką weterynaryjną pozwoliła na

empiryczne sprawdzenie zachowania się obu szkieletów programistycznych w rzeczywistymprojekcie typu CRUD. Podczas implementacji systemu skorzystano z przedstawionychw pracy narzędzi, dowodząc ich przydatności podczas procesu budowy aplikacji inter-netowych. W systemie zaimplementowano podstawowe elementy służące do zarządzaniadanymi.Eksperymenty przeprowadzone z udziałem zaimplementowanych aplikacji pozwoliły

głębiej spojrzeć na analizowane zagadnienie związane z budową aplikacji. Przedstawio-no analizę wyników pomiaru metryk prostych oraz złożonych. Badania wydajnościowewykorzystano do oceny zachowania się aplikacji w sytuacji dużego obciążenia, niezwykleważnego zagadnienia w przypadku aplikacji dostępnych dla szerokiego grona użytkowni-ków. W części poświęconej łatwości wprowadzania zmian opisano pracę jaką musi wykonaćprogramista stojący przed określonymi zadaniami opierając się na liczbie plików, które mu-szą zostać zmodyfikowane. Badanie dostępności komponentów Trinidad dało odpowiedźna pytanie związane z możliwością szerokiego zastosowania aplikacji opartej o JavaSe-rver Faces i bibliotekę Trinidad przez użytkowników wykorzystujących różne przeglądarkiinternetowe.

Rezultat przeprowadzonej analizy i badań

Wynik analizy teoretycznej badanych szkieletów programistycznych pozwolił na:1. Określenie różnic pomiędzy tradycyjnym modelem MVC szkieletu Spring MVC orazmodelem komponentowym realizowanym przez framework JavaServer Faces. JSF jest

93

szkieletem zorientowanym na strony (ang. page-oriented), Spring MVC na obsługężądań przez kontrolery.

2. Omówienie odmiennych modeli programistycznych. Spring MVC zaczyna od mapowa-nia żądań użytkownika a JavaServer Faces od definicji używanych w aplikacji kompo-nentów z uwzględnieniem ich integracji z użytkownikiem.

3. Wskazanie różnić między cyklem życia żądania w aplikacjach opartych o różne biblio-teki. W aplikacjach opartych o Spring MVC stosowane jest pojęcie żądania, znanez tradycyjnych aplikacji internetowych. Aplikacje oparte o JavaServer Faces używająpojęcia zdarzenia odbieranego przez komponenty umieszczone na stronie internetowej.

4. Opisanie aspektów związanych z walidacją i konwersją typów. Obie biblioteki są podob-ne pod tym względem. JavaServer Faces poprzez bibliotekę Trinidad posiada dodatko-wo znaczniki walidacyjne, które często prowadzą do sytuacji, w której implementacjaosobnych klas walidujących okazuje się zbędna.

5. Przedstawienie zagadnienia związanego z lokalizacją aplikacji. Spring MVC posiadalepsze wsparcie w omawianym zakresie, oferując wbudowane przełączanie się międzywersjami językowymi aplikacji. JavaServer Faces poprzez bibliotekę Trinidad oferujegotowe komunikaty w języku polskim, nie oferuje jednak, w przeciwieństwie do biblio-teki Spring MVC, możliwości lokalizacji całych stron aplikacji.Implementacja aplikacji Petclinic wraz z przeprowadzonymi eksperymentami pozwoliły

na wyciągnięcie następujących wniosków:1. Oba szkielety programistyczne spełniły swoją rolę w stopniu umożliwiającym w pełnipoprawną implementację wcześniejszych założeń.

2. Spring MVC stosuje tradycyjne podejście związane z tworzeniem aplikacji interneto-wych znane choćby ze szkieletu Struts. JavaServer Faces wprowadził pojęcie kompo-nentowości zbliżone do technologii ASP.NET. Implementacja aplikacji za pomocą JSFjest podobna do tworzenia tradycyjnych aplikacji desktopowych. Elementy interfejsuposiadają swój wewnętrzny stan oraz reagują na określone zdarzenia.

3. Eksperymenty badające wydajność aplikacji jednoznacznie potwierdziły większą wy-dajność aplikacji opartych o Spring MVC. Ma to ścisły związek z tym, iż aplikacjewykorzystujące szkielet Spring MVC domyślnie są bezstanowe a aplikacje oparte o Ja-vaServer Faces przechowują stan komponentów pomiędzy żądaniami, znacznie zwięk-szając ilość danych wymienianych pomiędzy żądaniami

4. Badania metryk kodu wskazały, iż projekt wykorzystujący Spring MVC jest większypod względem liczby linii kodu oraz artefaktów programistycznych. Klasy projektuopartego o JavaServer Faces posiadały większą liczbę pól i metod. Wynik ten potwier-dza sposób funkcjonowania modelu komponentowego, w którym elementy udostępniająswój wewnętrzny stan za pomocą metod. Obecnie na rynku istnieje szereg narzędziwspomagających tworzenie aplikacji JSF i czerpiących korzyści z modelu komponen-towego.

5. Pomiar metryk złożonych wykazał większą zgodność z zasadami dotyczącymi obiekto-wości projektu wykorzystującego Spring MVC . Jest to jedna z wyróżniających cechframeworka Spring MVC – zgodność z zasadami projektowania obiektowego. Aplika-cja wykorzystująca JavaServer Faces ze względu na zastosowany model komponentowybiblioteki wypadła gorzej pod tym względem.

6. W pomiarze metryk szablonów wskazano, iż strony generowane przez szkielet Java-Server Faces są nawet czterokrotnie większe niż analogiczne strony aplikacji SpringMVC.

7. Badanie łatwości wprowadzania zmian wykazało, iż JavaServer Faces lepiej sprawuje

94

się w przypadku tworzenia formularzy a gorzej w aspekcie kompleksowej lokalizacjiaplikacji.

8. Badanie dostępności komponentów Trinidad pozwoliło stwierdzić wysoką kompatybil-ność elementów interfejsu użytkownika. Zbadane elementy sprawują się bez zarzutuw większości przeglądarek internetowych. Znalezione błędy mogą zostać naprawionew prosty sposób.W mojej ocenie JavaServer Faces sprawdza się lepiej w aplikacjach mających wie-

le złożonych elementów interfejsu użytkownika, podobnych w działaniu do tradycyjnychaplikacji desktopowych. Spring MVC wypada lepiej w projektach integrujących wiele tech-nologii, gdzie ważne jest zastosowanie modelu obiektowego w rozwoju aplikacji.

Dalszy kierunek prac

Przedstawione wyniki badań należy traktować jako wskazówki podczas wyboru doce-lowego szkieletu programistycznego. Zaimplementowana aplikacja posiadała jedynie pod-stawowe elementy aplikacji służącej do zarządzania danymi.Proponowany jest dalszy rozwój aplikacji w celu zwiększenia jej złożoności dążąc do

implementacji rzeczywistych wymogów biznesowych stawianych przed tego typu systema-mi. Sugerowane jest dołączenie elementów raportujących oraz uwierzytelniających użyt-kowników aplikacji. Możliwe jest również poszerzenie zbioru eksperymentów o aspektyzwiązane z samymi bibliotekami takie jak badanie popularności, jakości dokumentacjiczy liczby dostępnych narzędzi. Ułatwiających podjęcie wyboru na wcześniejszym etapieanalizy alternatywnych rozwiązań.

Bibliografia

[1] Adobe - Flash CS3 Professional. Adres http://www.adobe.com/products/flash/. Po-brano 8 maja 2007.

[2] Alan M. J2EE. Podstawy programowania aplikacji korporacyjnych. Helion, listopad 2005.[3] Alexander C. A Pattern Language: Towns, Buildings, Construction (Center for Environ-mental Structure Series). Oxford University Press, 1977.

[4] Andy H., Dave T. JUnit. Pragmatyczne testy jednostkowe w Javie. Helion, lipiec 2006.[5] Apache Ant. Adres http://ant.apache.org/. Pobrano 9 maja 2007.[6] Apache JMeter. Adres http://jakarta.apache.org/jmeter/. Pobrano 15 maja 2007.[7] Apache Struts 2. Adres http://struts.apache.org/2.x/. Pobrano 15 maja 2007.[8] Apache Tomcat. Adres http://tomcat.apache.org/. Pobrano 15 maja 2007.[9] Apache Velocity. Adres http://velocity.apache.org/. Pobrano 15 maja 2007.[10] Arthur J., Azadegan S. Spring Framework for Rapid Open Source J2EE Web ApplicationDevelopment: A Case Study. W Chung L., Song Y., red., SNPD, strony 90–95. IEEEComputer Society, 2005.

[11] Basili V. R., Briand L. C., Melo W. L. A Validation of Object-Oriented Design Metrics asQuality Indicators. IEEE Trans. Software Eng., 22(10):751–761, 1996.

[12] Bruce T. Beyond Java. O’Reilly Media, wrzesień 2005.[13] Chidamber S. R., Kemerer C. F. Towards a Metrics Suite for Object Oriented Design. WOOPSLA, strony 197–211, 1991.

[14] Chidamber S. R., Kemerer C. F. A Metrics Suite for Object Oriented Design. IEEE Trans.Software Eng., 20(6):476–493, 1994.

[15] Chisholm W., Vanderheiden G., Jacobs I. Core Techniques for Web Content Accessibili-ty Guidelines 1.0. Adres http://www.w3.org/TR/WCAG10-CORE-TECHS/. Pobrano 4 maja2007.

[16] Chisholm W., Vanderheiden G., Jacobs I. Web Content Accessibility Guidelines 1.0. Adreshttp://www.w3.org/TR/WCAG10/. Pobrano 4 maja 2007.

[17] Chusho T., Ishigure H., Konda N., Iwata T. Component-based application development onarchitecture of a model, UI and components. W APSEC, strony 349–358. IEEE ComputerSociety, 2000.

[18] Debian Social Contract. Adres http://www.debian.org/social_contract.en.html. Po-brano 9 maja 2007.

[19] Deepak A., John C., Dan M. J2EE. Wzorce projektowe. Helion, wydanie drugie, luty 2004.[20] Deugo D. Techniques for Handling JSF Exceptions, Messages and Contexts. W ArabniaH. R., red., International Conference on Internet Computing, strony 100–106. CSREAPress, 2006.

[21] Dunkel J., Bruns R., Holitschke A. Comparison of JavaServer Pages and XSLT: a softwareengineering perspective. Softw., Pract. Exper., 34(1):1–13, 2004.

[22] Eric J., Jennifer B., Debbie C., Ian E., Scott F., Kim H. The java ee 5 tutorial. Adreshttp://java.sun.com/javaee/5/docs/tutorial/doc/. Pobrano 12 kwietnia 2007.

[23] Fowler M. Inversion of Control Containers and the Dependency Injection pattern. Adreshttp://www.martinfowler.com/articles/injection.html. Pobrano 15 maja 2007.

[24] Freemaker. Adres http://freemarker.sourceforge.net/. Pobrano 15 maja 2007.

96

[25] Garrett J. Ajax: A New Approach toWeb Applications. Adres http://www.adaptivepath.com/publications/essays/archives/000385.php. Pobrano 15 maja 2007.

[26] Hans B. JavaServer Faces. O’Reilly Media, kwiecień 2004.[27] Hibernate. Adres http://www.hibernate.org/. Pobrano 9 maja 2007.[28] Holmes A., Kellogg M. Automating Functional Tests Using Selenium. W AGILE, strony270–275. IEEE Computer Society, 2006.

[29] iBATIS. Adres http://ibatis.apache.org/. Pobrano 15 maja 2007.[30] Inderjeet S. Designing Enterprise Applications with the J2EE Platform. Prentice HallPTR, wydanie drugie, czerwiec 2002.

[31] International Standard ISO/IEC 9126-1:2001(E), Software Engineering – Product Quality.Part 1: Quality model. Technical report, ISO copyright office, Geneva, 2001.

[32] Jakarta Turbine Web Application Framework. Adres http://jakarta.apache.org/turbine/. Pobrano 9 maja 2007.

[33] JBoss. Adres http://www.jboss.com/. Pobrano 15 maja 2007.[34] JBoss Seam. Adres http://www.jboss.com/products/seam/. Pobrano 9 maja 2007.[35] JDepend. Adres http://www.clarkware.com/software/JDepend.html. Pobrano 15 maja2007.

[36] Jeff L., Dave M. Hibernate. Od nowicjusza do profesjonalisty. PowerNet, 2007.[37] Jetty. Adres http://www.mortbay.org/. Pobrano 15 maja 2007.[38] Konstan J. Introduction to recommender systems: Algorithms and Evaluation. ACM Trans.Inf. Syst., 22(1):1–4, 2004.

[39] Louridas P. JUnit: Unit Testing and Coding in Tandem. IEEE Software, 22(4):12–15, 2005.[40] Lucca G. A. D., Distante D., Bernardi M. L. Recovering conceptual models from webapplications. W Huang S., Pierce R., Jr. J. W. S., red., SIGDOC, strony 113–120. ACM,2006.

[41] Metrics. Adres http://metrics.sourceforge.net/. Pobrano 15 maja 2007.[42] Neal F. Art of Java Web Development: Struts, Tapestry, Commons, Velocity, JUnit, Axis,Cocoon, InternetBeans, WebWork. Manning Publications, listopad 2003.

[43] Parr T. J. Web application internationalization and localization in action. W Wolber D.,Calder N., Brooks C., Ginige A., red., ICWE, strony 64–70. ACM, 2006.

[44] PHP: Hypertext Preprocessor. Adres http://php.net/. Pobrano 8 maja 2007.[45] PMD. Adres http://pmd.sourceforge.net/. Pobrano 15 maja 2007.[46] Raggett D., Hors A., Jacobs I. Html 4.01 specification. Adres http://www.w3.org/TR/1999/REC-html401-19991224/. Pobrano 4 maja 2007.

[47] RIFE, a full-stack web application framework. Adres http://rifers.org/. Pobrano 8maja 2007.

[48] Rob H., Jan M. Pro Spring. Apress, styczeń 2005.[49] Robert M. The open-closed principle. C++ Report, styczeń 1996.[50] Rod J., Juergen H., Alef A., Risberg T., Sampaleanu C. Spring Framework. Profesjonalnetworzenie oprogramowania w Javie. Helion, czerwiec 2006.

[51] Rod J., Jurgen H. J2EE Development Without EJB. Wiley, czerwiec 2004.[52] RomaFramework. Adres http://romaframework.xwiki.com/xwiki/bin/view/Main/.Pobrano 8 maja 2007.

[53] Selenium. Adres http://www.openqa.org/selenium/. Pobrano 15 maja 2007.[54] Selfa D. M., Carrillo M., Boone M. D. R. A Database and Web Application Based on MVCArchitecture. W CONIELECOMP, strona 48. IEEE Computer Society, 2006.

[55] Tags for Identifying Languages. Adres http://tools.ietf.org/html/rfc4646. Pobrano15 maja 2007.

[56] Tapestry 5. Adres http://tapestry.apache.org/tapestry5/. Pobrano 15 maja 2007.[57] The Jakarta Taglibs Project. Adres http://jakarta.apache.org/taglibs/index.html.Pobrano 9 maja 2007.

97

[58] The Official Microsoft ASP.NET 2.0 Site. Adres http://www.asp.net/. Pobrano 8 maja2007.

[59] The Spring Petclinic Application. Adres http://www.springframework.org/docs/petclinic.html. Pobrano 15 maja 2007.

[60] Vincent M., Jason Z. Better Builds with Maven. Mergere Library Press, wydanie 1.0.1,czerwiec 2006.

[61] Web Accessibility Initiative. Adres http://www.w3.org/WAI/. Pobrano 15 maja 2007.[62] World Wide Web Consortium. Adres http://www.w3.org/. Pobrano 15 maja 2007.[63] XML User Interface Language. Adres http://developer.mozilla.org/en/docs/XUL. Po-brano 15 maja 2007.

[64] Zelkowitz M. V., Wallace D. R. Experimental Models for Validating Technology. IEEEComputer, 31(5):23–31, 1998.

98