JavaServer Faces I Eclipse Galileo. Tworzenie Aplikacji WWW

Id do
Spis treci
Przykadowy rozdzia
Katalog ksiek
JavaServer Faces i Eclipse

Galileo. Tworzenie
aplikacji WWW
Autor: Andrzej Marciniak
ISBN: 978-83-246-2656-4
Format: 158235, stron: 384
Katalog online
Zamw drukowany
katalog
Twj koszyk
Dodaj do koszyka
Cennik i informacje
Zamw informacje
o nowociach
Zamw cennik
Czytelnia
Fragmenty ksiek
online
Kontakt
Helion SA
ul. Kociuszki 1c
44-100 Gliwice
tel. 32 230 98 63
e-mail: helion@helion.pl
Helion 19912010
Jak projektowa estetyczne i wygodne interfejsy uytkownika aplikacji WWW?

Od czego zacz projekt wykorzystujcy JavaServer Faces?
Co oferuje rodowisko Eclipse Galileo, a co narzdzia Web Tools Platform?
Dobry interfejs aplikacji WWW to poowa jej sukcesu. Osignij go z JavaServer Faces! Jzyk Java
od lat zdobywa i ugruntowuje swoj popularno wrd programistw i twrcw aplikacji WWW,
a rozmaite platformy i rozwizania, w ktrych jest on wykorzystywany, zostay na stae wczone
do pakietu narzdzi stosowanych przez wielu z nich na co dzie. Jednym z najbardziej popularnych
tego typu narzdzi jest JavaServer Faces. Mona dziki niemu w prosty sposb tworzy interfejsy
uytkownika aplikacji, wykorzystujce platform Java EE. Ten spjny i kompletny szkielet
programistyczny jest obecnie najbardziej elastycznym, najlepiej dopracowanym i najprostszym
w uyciu rozwizaniem, opartym na technologii serwletw.
Jednak najprostszy wcale nie musi oznacza prosty, o czym z pewnoci miao okazj
przekona si wielu studentw kierunkw informatycznych i profesjonalnych programistw,
ktrzy postanowili praktycznie zapozna si z moliwociami tej technologii. Nieocenion
pomoc okae si dla nich ksika JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW,
dziki ktrej mona unikn wielu typowych bdw i nauczy si biegle korzysta z JSF,
zdobywajc przy tym kompletn wiedz na temat mechanizmw i rozwiza zapewniajcych
dziaanie tej platformy. Co wicej, opisano tu nie tylko sam technologi, lecz rwnie sposb jej
praktycznego wykorzystania w konkretnych projektach, co w przyszoci zaowocuje z pewnoci
opracowaniem niejednej doskonaej i cieszcej oko aplikacji WWW.
Mechanizmy dziaania aplikacji WWW i sposoby ich projektowania w oparciu o jzyk Java
Podstawowe informacje na temat szkieletu programistycznego JSF
Realizacja praktycznego projektu z wykorzystaniem JavaServer Faces
Rozszerzanie standardowej implementacji JSF i tworzenie niestandardowych interfejsw
uytkownika
Opis rodowiska programistycznego Eclipse Galileo oraz pakietu narzdzi Web Tools
Platform
Naucz si szybko i sprawnie tworzy rozbudowane interfejsy uytkownika aplikacji
WWW za pomoc szkieletu programistycznego JavaServer Faces
Spis treci
Wstp .............................................................................................. 7
Geneza ksiki .................................................................................................................. 7
Cele .................................................................................................................................. 9
Czytelnicy ....................................................................................................................... 10
Ukad zagadnie ............................................................................................................. 10
Materiay pomocnicze .................................................................................................... 11
Podzikowania ................................................................................................................ 12
Rozdzia 1. Przed przystpieniem do pracy z JSF ............................................... 13

1.1. Dlaczego JSF? ......................................................................................................... 13
1.1.1. Wersje JSF ................................................................................................... 15
1.2. JSF i Java EE (J2EE) ............................................................................................... 17
1.2.1. Serwlety i strony JSP ................................................................................... 19
1.2.2. Technologie prezentacji ............................................................................... 23
1.2.3. MVC w aplikacjach webowych ................................................................... 27
1.2.4. Implementacja MVC w JSF ......................................................................... 32
1.2.5. Kluczowe elementy JSF podsumowanie ................................................. 38
1.3. Pierwsza aplikacja JSF w rodowisku Eclipse ......................................................... 38
1.3.1. Instalacja kontenera serwletw .................................................................... 40
1.3.2. Instalacja rodowiska Eclipse Galileo .......................................................... 40
1.3.3. Integracja kontenera serwletw ze rodowiskiem Eclipse ........................... 43
1.3.4. Tworzenie projektu JSF ............................................................................... 44
1.3.5. Praca z JSF w oknie roboczym .................................................................... 48
1.3.6. Definiowanie modelu ................................................................................... 53
1.3.7. Definiowanie komponentu wspierajcego ................................................... 54
1.3.8. Utworzenie strony do wprowadzania danych ............................................... 56
1.3.9. Utworzenie strony do wywietlania wyniku ................................................ 59
1.3.10. Deklarowanie regu nawigacji .................................................................... 62
1.3.11. Uruchamianie aplikacji .............................................................................. 63
1.3.12. Podsumowanie przykadu .......................................................................... 65
Rozdzia 2. Planowanie, modelowanie i projektowanie aplikacji JSF

na platformie Java EE ..................................................................... 67
2.1. Modelowanie interfejsu uytkownika przy wykorzystaniu techniki scenopisu ....... 68
2.1.1. Przypadki uycia .......................................................................................... 69
2.1.2. Model ekranw interfejsu uytkownika ....................................................... 70
2.1.3. Model nawigacji .......................................................................................... 72
2.1.4. Prototypy ekranw ....................................................................................... 73
2.1.5. Diagram maszyny stanowej ......................................................................... 75
JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW

2.2. Warstwa biznesowa ................................................................................................. 77
2.2.1. Rola i elementy warstwy biznesowej ........................................................... 77
2.2.2. Interfejs do warstwy trwaoci danych ......................................................... 85
2.3. Organizacja kodu aplikacji w Eclipse ...................................................................... 95
2.3.1. Projekty i moduy Java EE w Eclipse .......................................................... 95
2.3.2. Zastosowanie projektu uytkowego
do przechowywania kodu warstwy biznesowej .......................................... 96
2.3.3. Moduy zalene ............................................................................................ 99
Rozdzia 3. Uywanie JSF ............................................................................... 101

3.1. Komponenty zarzdzane ........................................................................................ 101
3.1.1. Deklaracja komponentu ............................................................................. 102
3.1.2. Zasig komponentw ................................................................................. 105
3.1.3. Inicjalizacja waciwoci komponentw .................................................... 106
3.1.4. Odwoania do komponentw zarzdzanych ............................................... 113
3.1.5. Komponenty referowane ............................................................................ 115
3.1.6. Komponenty wspierajce ........................................................................... 116
3.1.7. Jzyk wyrae UEL ................................................................................... 118
3.1.8. Konfiguracja komponentw i innych zasobw .......................................... 123
3.2. Obsuga zdarze .................................................................................................... 127
3.2.1. Typy zdarze i metody ich obsugi ............................................................ 127
3.2.2. Natychmiastowe wykonywanie metod obsugi zdarze ............................. 136
3.2.3. Parametryzacja komponentw UI .............................................................. 137
3.3. Nawigacja .............................................................................................................. 140
3.3.1. Definiowanie regu nawigacji .................................................................... 140
3.3.2. Nawigacja statyczna i dynamiczna ............................................................ 143
3.3.3. Rozstrzyganie niejednoznacznoci w reguach .......................................... 144
3.3.4. Przekierowanie i nawigacja poza JSF ........................................................ 144
3.4. Przetwarzanie pakietw zasobw i internacjonalizacja ......................................... 146
3.4.1. Lokalizatory ............................................................................................... 147
3.4.2. Pakiety zasobw ........................................................................................ 150
3.4.3. Pakiety komunikatw ................................................................................. 154
3.4.4. Internacjonalizacja w warstwie biznesowej ............................................... 157
3.5. Konwersja .............................................................................................................. 159
3.5.1. Standardowe konwertery ............................................................................ 159
3.5.2. Obsuga bdw konwersji ......................................................................... 162
3.6. Walidacja ............................................................................................................... 164
3.6.1. Implementacja metod walidacji ................................................................. 165
3.6.2. Standardowe walidatory ............................................................................. 168
3.6.3. Kombinowanie rnych walidatorw ........................................................ 168
3.6.4. Wymuszanie wprowadzania danych .......................................................... 169
3.6.5. Pomijanie weryfikacji ................................................................................ 169
3.7. Standardowe znaczniki i komponenty UI .............................................................. 169
3.7.1. Komponenty i znaczniki biblioteki html .................................................... 170
3.7.2. Komponenty i znaczniki biblioteki core .................................................... 201
Rozdzia 4. Dopasowywanie JSF ..................................................................... 211

4.1. Przetwarzanie da .............................................................................................. 211
4.1.1. Scenariusze obsugi da ......................................................................... 211
4.1.2. Standardowy cykl przetwarzania dania JSF ........................................... 214
4.1.3. Kolejka zdarze ......................................................................................... 225
4.1.4. Kolejka komunikatw ................................................................................ 228
4.2. Konfigurowanie i rozszerzanie standardowej implementacji ................................. 229
4.2.1. Infrastruktura aplikacji JSF ........................................................................ 229
4.2.2. Mechanizm nawigacji ................................................................................ 238
Spis treci
5
4.2.3. Mechanizm zarzdzania widokami ............................................................ 238
4.2.4. Mechanizm zarzdzania stanem ................................................................. 239
4.2.5. Mechanizm przetwarzania wyrae EL ..................................................... 239
4.2.6. Mechanizm obsugi akcji ........................................................................... 243
4.3. Model komponentw ............................................................................................. 243
4.3.1. Struktura klas ............................................................................................. 244
4.3.2. Identyfikatory komponentw ..................................................................... 251
4.4. Praktyczne zastosowania obiektw PhaseListener ................................................ 255
4.4.1. Wzorzec POST-Redirect-GET ................................................................... 256
4.4.2. Generowanie danych binarnych ................................................................. 258
4.5. Zoone tabele ....................................................................................................... 260
4.5.1. Modele danych ........................................................................................... 260
4.5.2. Przykad tabeli interaktywnej ..................................................................... 261
4.6. JSF i bezpieczestwo ............................................................................................. 264
4.6.1. Bezpieczestwo zarzdzane przez kontener ............................................... 265
4.6.2. Bezpieczestwo zarzdzane przez aplikacj .............................................. 270
Rozdzia 5. Tworzenie komponentw uytkownika ........................................... 275

5.1. Komponenty interfejsu uytkownika (UI) ............................................................. 275
5.1.1. Implementacja komponentu ....................................................................... 276
5.1.2. Przechowywanie stanu komponentu .......................................................... 280
5.1.3. Rejestracja komponentu ............................................................................. 282
5.1.4. Generowanie i obsuga zdarze ................................................................. 282
5.1.5. Integracja z JSP .......................................................................................... 284
5.2. Renderery .............................................................................................................. 289
5.2.1. Podstawy implementacji rendererw ......................................................... 290
5.2.2. Renderery i JavaScript ............................................................................... 291
5.2.3. Rejestracja rendererw ............................................................................... 295
5.3. Konwertery ............................................................................................................ 296
5.3.1. Podstawy implementacji konwerterw ...................................................... 297
5.3.2. Rejestracja konwerterw ............................................................................ 300
5.3.3. Integracja konwerterw z JSP .................................................................... 302
5.4. Walidatory ............................................................................................................. 304
5.4.1. Podstawy implementacji walidatorw ....................................................... 305
5.4.2. Rejestracja walidatorw ............................................................................. 306
5.4.3. Integracja walidatorw z JSP ..................................................................... 308
5.5. Komponenty JSF i AJAX ...................................................................................... 309
5.5.1. Podstawy AJAX-a ...................................................................................... 310
5.5.2. Biblioteka AJAX4JSF ................................................................................ 313
5.5.3. Biblioteki AJAX-a ..................................................................................... 315
Rozdzia 6. Narzdzia wsparcia i integracja z innymi szkieletami ..................... 327

6.1. Narzdzia Web Tools Platform .............................................................................. 327
6.1.1. Zarzdzanie serwerem aplikacji ................................................................. 328
6.1.2. Monitorowanie portw ............................................................................... 330
6.1.3. Narzdzia uatwiajce prac z bazami danych ........................................... 333
6.2. Technologie widoku .............................................................................................. 338
6.2.1. Facelets ...................................................................................................... 339
6.2.2. Apache Tiles 2 ........................................................................................... 344
6.2.3. Smile .......................................................................................................... 350
Dodatek A Standardy kodowania IANA ........................................................... 353

Dodatek B Zaoenia JSF 2.0 ......................................................................... 355
Dodatek C Wsplne elementy konfiguracji ..................................................... 357
Dodatek D Komunikaty o bdach .................................................................. 359
Komunikaty o bdach komponentw .......................................................................... 359
Komunikaty o bdach konwerterw ............................................................................ 359
Komunikaty o bdach walidatorw ............................................................................. 360
Dodatek E
Atrybuty przekazywane HTML i zdarzenia DHTML ........................... 361

Literatura ..................................................................................... 363
Skorowidz .................................................................................... 365
Rozdzia 2.
Planowanie, modelowanie
i projektowanie aplikacji
JSF na platformie Java EE
Po zapoznaniu si z podstawowymi wiadomociami na temat architektury i moliwoci szkieletu JSF moemy przej do zagadnie zwizanych z wytwarzaniem realnych
aplikacji WWW w rodowisku programistycznym Eclipse Galileo. W niniejszym
rozdziale wybrane fazy wytwarzania aplikacji s zilustrowane na przykadzie Internetowego Systemu Recenzowania Publikacji (w skrcie ISRP), przeznaczonego do
zapewnienia obsugi informatycznej pracy redakcji czasopism naukowych oraz
wspomagania organizacji konferencji naukowych. Zakres funkcjonalnoci projektowanego systemu obejmuje obsug rejestracji artykuw zgaszanych przez autorw,
proces recenzji artykuw oraz administrowanie kontami uytkownikw.
Nie jest intencj autora zamieszczenie w tym miejscu penej dokumentacji systemu ISRP
jako zoonego studium przypadku uycia JSF (ang. case study), ale raczej przedstawienie pewnych praktyk projektowych zwizanych z architektur i projektowaniem
aplikacji JSF na platformie Java EE. Prezentowane rozwizania s wypadkow dowiadcze wielu osb w zakresie wykorzystania szkieletu JSF do wytwarzania warstwy prezentacji w aplikacjach o architekturze wielowarstwowej. Szczeglna uwaga
powicona jest wybranym aspektom zwizanym z czynnociami fazy przedimplementacyjnej projektu, takim jak modelowanie interfejsu uytkownika oraz projektowanie aplikacji oparte na architekturze wielowarstwowej. Zamieszczone w tym rozdziale
model i zaoenia projektowe bd rozwijane w dalszej czci ksiki i stanowi jednoczenie odniesienie dla kolejnych przykadw ilustrujcych elementy technologii JSF.
68
2.1. Modelowanie interfejsu

uytkownika przy wykorzystaniu
techniki scenopisu
Jako modelu projektowanego systemu czsto decyduje o powodzeniu projektu informatycznego, a jego najbardziej podan cech jest kompromisowo . Model powinien by jednoczenie zrozumiay dla klientw, ktrzy na jego podstawie oceniaj
funkcjonalno systemu, jak te zawiera wszystkie niezbdne dane dla zespou projektowego, ktry z niego korzysta w fazie projektowania. Z jednej strony model powinien
by dopasowany do technologii stosowanych w fazach projektowania i implementacji
(przy zaoeniu, e s one znane wczeniej i wynikaj np. z wymaga niefunkcjonalnych), a jednoczenie nie powinien wymaga rozlegej wiedzy na ich temat od analitykw wytwarzajcych model.
Ze wzgldu na komponentowy charakter szkieletu JSF, scenopis wydaje si technik
modelowania, ktra doskonale spenia opisane wyej kryteria. Scenopis specyfikuje
model zawierajcy analiz funkcjonaln, komponenty funkcjonalne oraz interakcje
pomidzy nimi na ekranach oraz przepywy i projekty ekranw. Najwiksz zalet
scenopisu jest to, e jest on zrozumiay dla osb spoza brany informatycznej, co zapewniaj diagramy przypadkw uycia i prototypy ekranw. W dalszej czci rozdziau zaprezentowane zostan poszczeglne elementy scenopisu, ilustrowane wybranymi fragmentami modelu aplikacji ISRP.
Scenopis i metodyki modelowania,

projektowania i dokumentowania systemw informatycznych
Metodyki wytwarzania systemw informatycznych stanowi jeden z gwnych nurtw inynierii oprogramowania. Obecnie standardowym narzdziem do modelowania
systemw informatycznych jest jzyk UML w wersji 2.1, ktry stanowi jednoczenie
system wizualizacji, specyfikowania oraz dokumentowania elementw systemu informatycznego. UML jest uywany wraz z jego reprezentacj graficzn jego elementom przypisane s symbole, ktre wizane s ze sob na diagramach. Ze wzgldu
na to e UML zosta stworzony z myl o opisie wiata w analizie obiektowej, jego
specyfikacja nie definiuje gotowych rozwiza dla specyficznych zastosowa, takich
jak modelowanie interfejsu uytkownika. Poniewa nie powsta zunifikowany standard dla modelowania zachowania i struktury aplikacji WWW, np. w zakresie modelowania nawigacji, przepyww sterowania na ekranach czy projektw ekranw, rne organizacje i firmy forsuj wasne rozszerzenia jzyka UML w tym zakresie.
Opierajc si na UML, stworzono metodyk projektowania oprogramowania RUP
(Rational Unified Process), ktra definiuje szablon procesu iteracyjnego wytwarzania
oprogramowania opracowany przez firm Rational Software Corporation. Szablon
RUP pozwala na korzystanie z jego elementw w zalenoci od potrzeb projektowych.
Spord najlepszych praktyk i zasad inynierii oprogramowania, ktre s w nim zawarte, warto wskaza do istotne z punktu widzenia specyfiki aplikacji tworzonych
Rozdzia 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java
69
w JSF zarzdzanie wymaganiami (ang. Requirement Management), uywanie architektury bazujcej na komponentach (ang. Component-based Architecture) czy graficzne projektowanie oprogramowania.
Scenopis (ang. storyboard) jest modelem projektowym, zwykle tworzonym przez
analitykw biznesowych i projektantw interfejsu uytkownika, dostarczonym zespoowi deweloperw jako cz specyfikacji funkcjonalnej. Idea scenopisu wywodzi
si z przedstawionej wyej metodyki RUP, ktra definiuje m.in. model projektowania
interakcji oparty na dowiadczeniu uytkownika (ang. User-eXperience UX) w postaci ekranw, ich dynamicznej zawartoci i sposobu nawigacji. Typowy scenopis
zawiera pi elementw:
przypadki uycia opisujce wymagania funkcjonalne i przepywy zdarze,
model ekranw UI specyfikujcy ekrany, komponenty i elementy UX,
diagram nawigacji ilustrujcy zwizki pomidzy ekranami (przede wszystkim
reguy nawigacji), oparty na notacji graficznej diagramu klas,

makiety ekranw (ang. mock-up) pokazujce szczegowo elementy
funkcjonalne interfejsu GUI, tj. kontrolki i ich rozmieszczenie,

diagramy maszyny stanowej dla kadego ekranu ilustrujce interakcj warstwy
kontrolera ekranu z warstw modelu aplikacji.
2.1.1. Przypadki uycia

Wygodnym narzdziem stosowanym na potrzeby identyfikacji i dokumentacji wymaga funkcjonalnych s diagramy przypadkw uycia (ang. Use Case UC) w jzyku UML. Ilustruj one funkcjonalno systemu poprzez wyszczeglnienie i przedstawienie za pomoc symboli graficznych: aktorw inicjujcych dziaania, przypadkw
uycia systemu oraz wystpujcych pomidzy nimi zwizkw. Dziki swojej prostocie oraz abstrahowaniu od rozwiza technicznych, diagramy przypadkw uycia s
zrozumiae nawet dla osb, ktre nie posiadaj wyksztacenia informatycznego. Z zaoenia stanowi one czytelne narzdzie pozwalajce na komunikacj pomidzy twrcami
systemu i jego potencjalnymi odbiorcami czy inwestorami. Podsumowujc, przypadki
uycia opisuj, co system powinien robi , a nie jak ma to robi .
Na rysunku 2.1 przedstawiono diagram przypadkw uycia modelujcy aktorw, przypadki uycia oraz powizania pomidzy nimi, wystpujce w systemie ISRP. Schematyczny rysunek postaci ludzkiej zoony z kilku kresek jest symbolem graficznym
aktora, definiujcego spjny zbir rl odgrywanych przez uytkownikw przypadku
uycia w czasie jego realizacji. Przypadki uycia oznaczone s przy wykorzystaniu
wypenionych elips, a ich realizacje zwykymi liniami. Relacje rozszerzania i zawierania dla przypadkw uycia opisane s przy zastosowaniu stereotypw umieszczonych w cudzysowach ostroktnych. Relacje uoglniania (w sensie zwizku taksonomicznego, opisujcego dziedziczenie cech) przedstawione zostay za pomoc linii
zakoczonych strzak z pustym grotem.
70
Zaloguj
Odzyskaj haso
Wywietl szczegy
recenzji
Edytuj dane osobowe
Autor
(from Actors)
Poka szczegy
pracy
Dodaj prac
Uytkownik
uwierzytelniony
Wywietl list prac
(from Actors)
extend
Zarejestruj
Edytuj prac
include
Recenzent
(from Actors)
Dodaj recenzj
Zarzdzaj pracami
Wywietl list
recenzji
Przypisz recenzenta
do pracy
Dodaj recenzenta
Administrator
(from Actors)
Zarzdzaj
uytkownikami
include
Wywietl list
uytkownikw
Rysunek 2.1. Diagram przypadkw uycia dla ISRP
Dokadny opis wykorzystania diagramw UC do modelowania funkcjonalnoci systemu Czytelnik znajdzie w ksice Jzyk UML 2.0 w modelowaniu systemw informatycznych, a wyczerpujcy opis scenariuszy przypadkw uycia (tekstowej formy
prezentacji UC) znajduje si w ksice Writing Effective Use Cases1.
2.1.2. Model ekranw interfejsu uytkownika

Model ekranw UI stanowi centralny punkt wyjciowy dla rwnolegego rozwoju aplikacji, prowadzonego w zespoach projektantw stron WWW i programistw aplikacji,
stanowic jednoczenie interfejs umoliwiajcy integracj kodu wytwarzanego przez
1
Polskie wydanie: Alistair Cockburn, Jak pisa efektywne przypadki uycia, tum. Krzysztof Stencel,
Warszawa 2004.
71
oba zespoy. Model ekranw UI definiuje zbir ekranw (wraz z ich zawartoci) niezbdnych do zrealizowania wymaga funkcjonalnych okrelonych przez przypadki
uycia. W przypadku zawartoci ekranw model definiuje wycznie elementy funkcjonalne, jakie powinny znale si na nich, bez okrelania szczegw dotyczcych
typw kontrolek (np. pola tekstowego albo listy rozwijanej) czy ich rozmieszczenia.
W technice scenopisw standardowym elementom UML nadawane s nowe znaczenia
poprzez uycie stereotypw przedstawionych w tabeli 2.1.
Tabela 2.1. Stereotypy modelu UI wykorzystywane w technice scenopisw
Stereotyp
Rozszerzany element UML
Reprezentuje
Screen
Class
Ekran (w postaci strony WWW).
Compartment
Class
Fragment ekranu (strony WWW) przeznaczony do

wykorzystania na wielu stronach aplikacji WWW
(definiujcy sekcj strony np. stopk, nagwek itp.).
Form
Class
Formularz strony WWW.
Input
Attribute
Pole wejciowe formularza.
Submit
Operation
Element zatwierdzajcy formularz i generujcy akcj.
Statyczne informacje takie jak etykiety, obrazki czy panele nie s w ogle reprezentowane w modelu UI. Dane biznesowe s przedstawiane na ekranie przy uyciu atrybutw. Jeli atrybut opatrzony jest stereotypem <<input>>, oznacza to, e suy on do
wprowadzania danych. Peny opis atrybutu prezentowany jest wedug nastpujcego
formatu: widoczno nazwa :typ liczebno =domylna_warto {waciwoci}. Zamy, e mamy ekran sucy do tworzenia konta nowego uytkownika, dostpny wycznie dla administratora systemu. Pole suce do wprowadzania uprawnie dla nowego uytkownika moe zosta opisane w nastpujcy sposb:
<<input>> +role :String 1 =reviewer {user.role==admin}
Powyszy zapis informuje nas, e atrybut role reprezentuje pole wejciowe dla danych typu String, wypeniane przez uytkownikw z uprawnieniami administratora.
Widoczno elementu okrela, czy jego zawarto jest wywietlana na ekranie (+),
czy te jest ukryta (-). Nazwa atrybutu powinna identyfikowa pole wprowadzania danych
(np. warto atrybutu name dla odpowiedniego pola formularza). Typem atrybutu moe by dowolny typ prymitywny lub obiektowy, wcznie z abstrakcyjnymi typami
danych, reprezentujcymi zoone struktury danych (takie jak listy czy mapy, ktre
mog by reprezentowane przez klasy abstrakcyjne List bd Map). Pozostae waciwoci atrybutu s opcjonalne i nie musz by definiowane. Liczebno okrela, ile instancji elementu moe by renderowanych na ekranie, warto domylna jest wartoci
uywan dla elementw, ktre nie s inicjowane, a nawiasy klamrowe umoliwiaj
zamieszczenie dodatkowych waciwoci bd ogranicze dotyczcych atrybutu, np.
w zakresie dostpu do pola danych.
Zdarzenia generowane przez interfejs uytkownika oraz akcje uytkownika reprezentowane s za pomoc operacji. Jeli operacja jest dodatkowo opatrzona stereotypem
<<submit>>, oznacza to, e wskazany element UI suy do zatwierdzania formularza
72
i generowania akcji, ktrej wynik moe wpywa na nawigacj aplikacji. Peny opis operacji prezentowany jest wedug nastpujcego formatu: widoczno nazwa (lista_
parametrw) :zwracany_typ {waciwoci}. Na przykad element wyzwalajcy akcj
polegajc na przejciu do okna edycji biecego uytkownika moe by opisany w nastpujcy sposb:
<<submit>> + edit ():String {current.user==notEmpty}
Nazwa operacji powinna by powizana z nazw metody sucej do obsugi zdarzenia wygenerowanego przez operacj lub nazw powizanego z operacj pola (np. gdy
operacja dotyczy walidacji danych wprowadzanych do pola wejciowego po stronie
klienta). Widoczno elementu okrela, czy akcja ma by podjta po stronie klienta (-),
czy po stronie serwera (+). Waciwoci dodatkowo charakteryzujce operacje zamieszczane s w opcjonalnych nawiasach klamrowych.
Na rysunku 2.2 zaprezentowano model ekranu realizujcego dwa przypadki uycia
systemu ISRP rejestracj nowego uytkownika i edycj danych uytkownika uwierzytelnionego. Obie funkcjonalnoci systemu s do podobne i operuj na jednym
zbiorze danych, wic do ich obsugi zamodelowany zosta jeden ekran. Ekran skada
si z trzech czci: nagwka (topMenu) zawierajcego przyciski nawigacji, menu dla
uwierzytelnionych uytkownikw (leftMenu) i formularza danych uytkownika. W przypadku rejestracji nowego uytkownika elementy menu leftMenu oraz przycisk zapisywania formularza nie s widoczne, podobnie jak przyciski nawigacji (patrz rysunek
2.4). Z kolei w przypadku korzystania z ekranu przez administratora wszystkie jego
elementy s widoczne.
2.1.3. Model nawigacji

W technice scenopisw diagramy nawigacji nie koncentruj si na konkretnym przepywie zdarze, ale pokazuj zwizki pomidzy ekranami. Model nawigacji zawiera
graficzn ilustracj przepyww nawigacji dla wszystkich przypadkw uycia. Przepywy nawigacji dla poszczeglnych przypadkw mog by prezentowane na oddzielnych diagramach bd jednym diagramie zbiorczym, jak pokazano na rysunku
2.3. Jak mona zauway , przedstawiony diagram nawigacji jest bardziej szczegowy
ni opisana w rozdziale 1. graficzna reprezentacja regu nawigacji w Eclipse WTP.
Niemniej podczas tworzenia diagramu mona wykorzysta gotowe obiekty ekranw,
stanowice zawarto utworzonego wczeniej modelu ekranw interfejsu uytkownika.
Wystpujce na diagramie asocjacje skierowane wskazuj kierunek przepywu sterowania pomidzy dwoma ekranami. W szczeglnych przypadkach asocjacje mog by
wyprowadzane do formularza (<<form>>), ale zawsze miejscem docelowym jest ekran.
Kada asocjacja powinna posiada powizan z docelowym ekranem unikatow nazw, ktra bdzie moga zosta wykorzystana podczas definiowania regu nawigacji
JSF (jako warto elementu <from-outcome>).
screen
addEditUser
+
73
compartment
includes::leftMenu
globalMessage: String [0..*]

submit
+ addPaper {user.role==author}() : String
+ addUser {user.role==admin}() : String
+ allPapersList {user.role==admin}() : String
+ authorsPapersList {user.role==author}() : String
+ editAccount{currentUser==notEmpty}(): String
+ reviewersPapersList {user.role==reviewer}() : String
+ usersList {user.role==admin}() : String
form
addEditUserForm
input
+ city: text
+ country: select
+ department: text
+ firstName: text
+ gender: radio
+ lastName: text
+ password: text
+ phone: text
+ role {user.role==admin}: select
+ street: text
+ title: text
+ zipCode: text
compartment
includes::topMenu
+
userName {user==authorized}: String
+
+
english() : void
polish() : void
submit
+ login {user==notAuthorized}() : String
+ logout {user==authorized}() : String
+ registration {user==notAuthorized}() : String
submit
+ save {currentUser==notEmpty}() : String
+ registration {currentUser==empty}() : String
Rysunek 2.2. Model ekranu rejestracji i edycji danych uytkownika
2.1.4. Prototypy ekranw

Zrozumiay, ergonomiczny i przejrzysty interfejs uytkownika jest jednym z kluczowych czynnikw decydujcych o sukcesie aplikacji WWW. Konsultowanie wygldu
interfejsu przez potencjalnych uytkownikw systemu w fazie przedimplementacyjnej
lub w trakcie implementacji pozwala ten sukces osign . Celem przeanalizowania
preferencji uytkownikw w zakresie funkcjonalnoci interfejsu stosuje si tzw. prototypowanie, polegajce na wytwarzaniu makiet ekranw (ang. mock-up). Pojcie
makiety jest mao precyzyjne i charakteryzuje wszelkie projekty ekranw, poczwszy
od odrcznych szkicw, poprzez projekty szkieletowe ekranu (ang. wireframes), a po
gotowe interaktywne prototypy ekranw posiadajce bogat szat graficzn i umoliwiajce testowanie ekranu na faszywych danych. Projekty szkieletowe nie uwzgldniaj szaty graficznej, a ich celem jest przedstawienie oglnej funkcjonalnoci poszczeglnych ekranw oraz sposobu prezentacji danych biznesowych.
74
screen
forgotPassword
screen
assignReviewer
{user.role==admin}
+ globalMessage: String [0..*]

input
+ email: text
+ paper.title: String
input
+ reviewers: select
submit
+ forgotPassword() : String
+ notRegistered() : String
login
assign_reviewer
assign_success
registration
compartment
:topMenu
logout_success
registration
screen
index
globalMessages: String [0..*]
+ welcomeMessage: String
paper_details
screen
addEditUser
registration_success
delete
all_papers_list
compartment
:leftMenu
screen
addReview
{user.role==reviewer}
add_user
edit_user
+ globalMessages: String [0..*]
screen
paperDetails
+
+
+
+
login_success
get_password_success
screen
papersList {user.role==admin}
+
forgot_password
submit
+ getNewPassword() : String
submit
+ assign() : String
aprove/reject
screen
login
paper.abstract: String
paper.acronym: String
paper.authors: String
paper.title: String
add_success
author_papers_list
papers_details
all_users_list
screen
reviewerPaperList
+ globalMessages: Strin [0..*]
screen
usersList {user.role==admin}
submit
+ downloadFile() : void
review_details
review_details
edit_success
add_success reviewer_papers_list
add_review
+ globalMessages: String [0..*]
paper_details
screen
auhtorPaperList
{user.role==author}
screen
reviewDetails
delete
globalMessages: String [0..*]
+ review.commentToAdmin {user.role==admin || user.role==reviewer}: String

+ review.commentToAuthor {user.role==author || user.role==reviewer}: String
+ review.grade: String
add_success
edit_paper
review_details
add_paper
add_new_version
edit_success
screen
addNewVersion
{user.role==author}
add_success
screen
addEditPaper
{user.role==author}
input
+ paper.file: file
submit
+ addNewVersion() : String
Rysunek 2.3. Diagram nawigacji dla aplikacji ISRP
W technice scenopisw generalnie zaleca si stosowanie projektw szkieletowych,

ktre mog by wytwarzane zarwno odrcznie, z wykorzystaniem narzdzi graficznych
(do popularny jest pakiet MS PowerPoint), jak i za pomoc specjalnych narzdzi
dostpnych w pakietach do modelowania, np. Microsoft Visio Toolkit for Wireframe,
MockupScreens czy Screen Architect for Sparx Enterprise Architect. W rodowisku
Eclipse warto rozway wykorzystanie edytora stron WWW pakietu WTP utworzone w ten sposb projekty mog by pniej stosowane podczas implementacji.
75
Przykad projektu szkieletowego dla ekranu rejestracji uytkownika w systemie ISRP

zosta pokazany na rysunku 2.4. Projekt stanowi rozwinicie modelu ekranu zamieszczonego na rysunku 2.2 zarwno w zakresie specyfikacji kontrolek realizujcych elementy funkcjonalne, jak i rozmieszczenia elementw wizualnych, majcych uatwi
korzystanie ze strony.
Rysunek 2.4. Projekt szkieletowy ekranu rejestracji aplikacji ISRP
2.1.5. Diagram maszyny stanowej

W technice scenopisw diagram maszyny stanowej suy do opisania zachowania ekranu w trakcie realizacji przypadku uycia. Diagram modeluje stan znajdujcego si po
stronie serwera kontrolera ekranu oraz jego zmiany nastpujce w wyniku interakcji
uytkownika z ekranem. Na rysunku 2.5 zamieszczony zosta przykad diagramu maszyny stanowej, ilustrujcy zmiany stanw kontrolera ekranu rejestracji (przedstawionego na rysunku 2.4).
76
ControllerState
Rejestracja nieaktywna
wyjcie po
klikniciu przycisku
nawigacji
Final
entry / dezaktywuj przycisk Zarejestruj
start
zaznaczenie
pola wyboru
[pole=true]
zaznaczenie pola
wyboru
[pole=false]
zatwierdzenie
formularza [walidacja
poprawna]
/dodaj uytkownika
ControllerState
Rejestracja aktywna
+
+
entry / uaktywnij przycisk Zarejestruj

exit / waliduj dane formularza
zatwierdzenie formularza
[walidacja niepoprawna]
/poka bdy
Rysunek 2.5. Diagram maszyny stanowej dla ekranu rejestracji
Stan pocztkowy reprezentuje stan kontrolera po utworzeniu jego instancji i jest

oznaczony przez strzak wychodzc od elementu start. Kade przejcie (tranzycja)
na diagramie definiuje relacj midzy dwoma stanami kontrolera, wskazujc, e kontroler znajdujcy si w pierwszym stanie wykona pewne akcje i przejdzie do drugiego
stanu, ilekro zajdzie okrelone zdarzenie i bd spenione okrelone warunki. Opis
przejcia skada si z trzech opcjonalnych elementw: wyzwalacza (ang. trigger), dozoru
(ang. guard) i aktywnoci (ang. activity), ktre opisywane s wedug nastpujcej
skadni: wyzwalacz [dozr] /aktywno. Wyzwalaczem jest zazwyczaj pojedyncze
zdarzenie, ktre moe spowodowa przejcie i zmian stanu. Dozr okrela warunek
logiczny, jaki musi by speniony, aby przejcie zostao wykonane; warunek ten jest
obliczany w momencie pojawienia si wyzwalacza. Aktywno definiuje operacj
wykonywan w momencie przejcia ze stanu do stanu; nawet jeeli akcja przejcia
jest zoona z wielu akcji elementarnych, jest ona wykonywana niepodzielnie.
Przejcia s oznaczane za pomoc strzaek czcych dwa stany kontrolera i mog by
postrzegane jako zmiany na ekranie, ktre nie powoduj uaktywnienia regu nawigacji skutkujcych wywietleniem innego ekranu. Podobnie jak w zwykym diagramie
maszyny stanowej, rwnie tutaj mog wystpowa szczeglne przypadki przej ,
ktrych wykonanie nie prowadzi do zmiany danego stanu, tj. przejcia wewntrzne
lub zwrotne. W przypadku przejcia zwrotnego s wykonywane czynnoci wejciowe
oraz wyjciowe danego stanu, w przypadku przej wewntrznych s one pomijane.
77
Przejcia wewntrzne nie maj odrbnego oznaczenia graficznego, lecz s specyfikowane w obszarze stanu, obok definicji nastpujcych czynnoci:
entry czynnoci wykonywane w momencie, gdy obiekt przyjmuje dany stan;
do czynnoci wykonywane nieprzerwanie w czasie, gdy obiekt przebywa
w danym stanie;
exit czynnoci wykonywane w momencie opuszczenia stanu.
Przejcia wewntrzne lub zwrotne wystpuj w sytuacjach, gdy kompozycja ekranu

zmienia si tylko nieznacznie lub wcale. Stan kocowy (ang. final) wskazuje, e maszyna
stanw jest kompletna, a obiekt kontrolera oraz wszystkie przechowywane w nim zmienne mog zosta usunite.
2.2. Warstwa biznesowa

W rozdziale 1.2.4, Implementacja MVC w JSF, przedstawiono oglny schemat implementacji wzorca MVC w aplikacjach opartych na JSF oraz korzyci pynce z izolowania warstwy biznesowej i prezentacji. W tym punkcie zostan omwione dobre
praktyki projektowe, rozwizania i technologie zwizane z tworzeniem samej warstwy
biznesowej.
2.2.1. Rola i elementy warstwy biznesowej

Pojcie warstwy biznesowej do sugestywnie okrela rol tej warstwy, w ktrej modelowane s obiekty i reguy biznesowe. Stanowi ona zazwyczaj rdze aplikacji i jest
najbardziej rozleg jej warstw, z jednej strony wiadczc usugi dla warstwy prezentacji, z drugiej strony korzystajc z zewntrznych rde danych, takich jak bazy
danych, korporacyjne systemy informacyjne (ang. Enterprise Information Systems
EIS) czy zewntrzne systemy informatyczne. Separowanie warstwy biznesu od prezentacji uatwia implementacj regu biznesowych i umoliwia uycie obiektw biznesowych w dowolnym rodowisku uruchomieniowym (strona 29 Korzyci wynikajce
z izolowania warstw widoku i logiki biznesowej). Ze wzgldu na rozlego warstwy
biznesowej dobrze jest podzieli j na podwarstwy, ktre s od siebie logicznie oddzielone i posiadaj cile zdefiniowane zakresy odpowiedzialnoci, tj. model dziedzinowy, warstw usug i interfejs do warstwy trwaoci danych (patrz rysunek 2.6),
omwione w kolejnych punktach.
Najpopularniejsze podejcia do tworzenia warstwy biznesowej w aplikacjach WWW
oparte s na wykorzystaniu:
zarzdzanych przez kontener komponentw,
zwykych obiektw Javy (ang. Plain Old Java Objects POJO).
78
Rysunek 2.6.
Warstwowy model
architektury
wykorzystany
w aplikacji ISRP
Warstwa prezentacji
Warstwa biznesowa
Warstwa usugowa (fasady)
Model dziedzinowy (POJO)
Interfejs do warstwy trwaoci (DAO)

Warstwa trwaoci
Programowanie komponentowe jest naturalnym rozszerzeniem programowania zorientowanego obiektowo nie posiada ono zupenie nowych atrybutw w stosunku
do programowania obiektowego, a jedynie konsekwentnie i w peni wykorzystuje cechy obiektowoci. Komponenty oferuj hermetycznie opakowane, wysokopoziomowe
funkcje realizujce logik biznesow. Zarzdzaniem komponentami zajmuje si kontener, ktry kontroluje rne aspekty ich ycia, m.in. tworzenie instancji, wprowadzanie zalenoci pomidzy nimi czy te zarzdzanie cyklem ich ycia. Kontener pozwala na ograniczenie zada stojcych przed komponentami do realizacji jedynie
funkcji biznesowych, dziki czemu s one atwe do zrozumienia, maj czytelne interfejsy i mog by rozproszone w sieci. Programowanie komponentowe boryka si jednak
z wieloma problemami implementacyjnymi, przede wszystkim z du rnorodnoci
protokow komponentowych i jzykw interfejsw, problemami ze wzajemnym porozumiewaniem si komponentw czy zoonoci infrastruktur rodowisk uruchomieniowych. Popularnymi technologiami komponentw s Enterprise Java Beans czy Spring.
Do implementacji warstwy biznesowej w zawartych w ksice przykadach wykorzystywane jest podejcie oparte na klasach POJO. Zalet tego podejcia jest brak zalenoci od technologii EJB czy Java EE oraz moliwo uycia i testowania jej kodu
bez potrzeby korzystania ze rodowiska uruchomieniowego serwera.
Klasy POJO i komponenty JavaBean

Termin Plain Old Java Objects okrela obiekty zwykych klas Javy, ktre nie s
ograniczone adnymi specjalnymi restrykcjami i nie musz implementowa adnych
specjalnych zachowa w odrnieniu od np. komponentw EJB 2.x. Klasy POJO nie
powinny dziedziczy po wczeniej predefiniowanych klasach, implementowa predefiniowanych interfejsw czy zawiera predefiniowanych adnotacji, jeli te nie s zwizane
z ich podstawow funkcjonalnoci (cho nawet tych wymaga nie naley traktowa
zbyt rygorystycznie). Pojcie POJO zostao wprowadzone przez Martina Fowlera,
Rebecc Parsons i Josha McKenziego w 2000 roku, ktrzy poprzez wprowadzenie
atrakcyjnie brzmicej nazwy dla zwykych obiektw Javy chcieli wyrni ide wykorzystania prostych technik projektowych w programowaniu obiektowym.
79
Poniewa w aplikacjach korporacyjnych Java EE (J2EE) wymagane s dodatkowe

usugi, takie jak zarzdzanie transakcjami, utrzymywanie bezpieczestwa czy trwaoci danych (w alternatywnym podejciu usugi te zapewniaj kontenery EJB), powstay specjalne lekkie szkielety programistyczne (ang. lightweight frameworks), udostpniajce wybrane usugi obiektom POJO. Przykadami lekkich szkieletw s Spring,
Hibernate czy iBatis. Pozytywne dowiadczenia ze stosowania lekkich szkieletw i klas
POJO skoniy rwnie projektantw technologii EJB do gruntownej przebudowy ich
rozwizania. Poczwszy od wersji EJB 3.0, komponenty EJB s w zasadzie klasami
POJO, ktre zawieraj adnotacje specyfikujce dodatkowe waciwoci obiektw tych
klas (poza kontenerem EJB adnotacje nie s interpretowane, wic mona stwierdzi ,
e EJB 3.0 to POJO).
Komponenty JavaBean s to napisane w odpowiedniej konwencji klasy POJO, bdce
niezalenymi moduami wielokrotnego uytku w programach Javy. Narzdzia do
tworzenia oprogramowania s w stanie czy i wykorzystywa komponenty JavaBeans
oraz manipulowa nimi dziki przyjciu odpowiednich konwencji w nazywaniu metod, konstrukcji klasy i jej zachowania, a mianowicie:
klasa musi posiada publiczny i bezparametrowy konstruktor;
hermetyzowane waciwoci klasy musz by dostpne do odczytu i modyfikacji
za pomoc specjalnych metod publicznych (tzw. getters & setters), ktre musz
mie odpowiednio skonstruowane nazwy, zawierajce przedrostki get-, seti opcjonalnie is- dla typu boolean, np.: public int getTemperature(), public
void setTemperature(int t), public boolean isFinished() dla waciwoci
temperature i finished;
klasa powinna by serializowalna (implementowa interfejs Serializable
lub Externalizable);
klasa nie powinna zawiera metod obsugi zdarze.
Przykadowymi komponentami JavaBean s komponenty wspierajce.
2.2.1.1. Model dziedzinowy

Na podstawie analizy przypadkw uycia moemy zidentyfikowa podstawowe klasy
konceptualne (pojcia, rzeczy bd obiekty) wystpujce w projektowanym systemie.
Model konceptualny stanowi punkt wyjciowy generowania obiektowego modelu
dziedzinowego oraz modelu relacyjnego (fizycznego). Diagram konceptualny na rysunku
2.7 przedstawia podstawowe pojcia wystpujce w systemie ISRP.
Dokadne odwzorowanie obiektowe koncepcji biznesowych wystpujcych w modelowanym rodowisku zapewnia tzw. model drobnoziarnisty (ang. fine-grained model),
oparty na wykorzystaniu wielu prostych obiektw POJO, reprezentujcych istotne
koncepcje biznesowe. Modele drobnoziarniste znakomicie speniaj swoje funkcje, o ile
nie wystpuje potrzeba rozproszenia obiektw na rnych serwerach. W modelu drobnoziarnistym wystpuje mnstwo wzajemnych odwoa pomidzy obiektami, co stanowi
problem w systemach rozproszonych, gdy zdalne wywoania s do kosztowne.
80
java.io.Serializable
Uytkownik
mieszka
wykonuje
Recenzja
nadsya
Kraj
Artyku
Pytanie
Odpowied
Rysunek 2.7. Diagram konceptualny systemu ISRP
W takich systemach podejcie komponentowe moe by przydatniejsze, a kontenery

Java EE mog dodatkowo zapewni bezpieczestwo, transakcyjno czy poczenia
w systemach heterogenicznych.
Model dziedzinowy aplikacji ISRP zaimplementowany jest w postaci klas POJO.
Przykad obiektu biznesowego dla koncepcji uytkownika zosta przedstawiony na listingu 2.1.
Listing 2.1. Kod klasy User
package isrp.hibernate.model.businessobject;
import java.util.Date;
public class User implements java.io.Serializable {
private Integer id;
private int countryId;
private String title;
private String firstName;
private String lastName;
private String organization;
private String department;
private String street;
private String zipCode;
private String city;
private String email;
private String password;
private String phone;
private boolean gender;
private Date entryDate;
private Byte role;
public User() { //konstruktor na potrzeby serializacji
}
public User(int countryId, String title, String firstName, String lastName,

String organization, String department, String street,
String zipCode, String city, String email, String password,
String phone, boolean gender, Date entryDate, Byte role) {
81
this.countryId = countryId;
this.title = title;
this.firstName = firstName;
this.lastName = lastName;
this.organization = organization;
this.department = department;
this.street = street;
this.zipCode = zipCode;
this.city = city;
this.email = email;
this.password = password;
this.phone = phone;
this.gender = gender;
this.entryDate = entryDate;
this.role = role;
}
public Integer getId() {return this.id;}
public void setId(Integer id) {this.id = id;}
/* ...Pozostae gettery i settery ...*/
}
Podejcie polegajce na wyprowadzeniu implementacji logiki biznesowej poza model dziedzinowy i obiekty reprezentujce dane okrelane jest w literaturze mianem
anemicznego modelu dziedzinowego. Wprowadzi je Martin Fowler, ktry traktuje
takie rozwizanie jako antywzorzec. Najwaniejszym zarzutem, jaki stawia Fowler
takiemu modelowi, jest naruszenie zasad OOP w zakresie enkapsulacji i hermetyzacji kodu przetwarzaniem stanu obiektw dziedzinowych czy te ich walidacj
zajmuj si zewntrzne klasy. Inne istotne mankamenty to zmniejszenie czytelnoci
kodu oraz zwikszenie moliwoci wystpowania duplikacji w kodzie. Mimo tych wad
(wyjanionych dokadnie w artykule pod adresem http://www.martinfowler.com/bliki/
AnemicDomainModel.html) rozwizanie to jest czsto i chtnie stosowane, zwaszcza
gdy obiektowy model dziedzinowy jest generowany automatycznie, za pomoc narzdzi ORM, na podstawie istniejcego wczeniej modelu fizycznego.
2.2.1.2. Warstwa usugowa

Bardzo wane na etapie projektowania jest rozrnienie dwch aspektw funkcjonalnoci systemu wystpujcych w warstwie biznesowej: modelu dziedzinowego i logiki
biznesowej. Model dziedzinowy reprezentuje koncepcje biznesowe i ich zachowanie,
podczas gdy logika biznesowa reprezentuje procesy i przepywy sterowania odpowiadajce scenariuszom przypadkw uycia. Oddzielenie logiki biznesowej od modelu
dziedzinowego jest moliwe poprzez wprowadzenie warstwy usugowej (ang. service
layer) odpowiedzialnej za:
zdefiniowanie uproszczonego interfejsu dla klientw modelu dziedzinowego,
implementacj zoonych obiektw usug zdefiniowanych przez wyej
wymieniony interfejs.
Obiekty usug mog zapewnia fasady dla modelu dziedzinowego (strona 83 Wzorzec fasady) oraz implementowa procesy biznesowe.
82
Na przykad na diagramie przypadkw uycia systemu ISRP wystpuje przypadek

Przypisz recenzenta do pracy, ktry reprezentuje zoony proces biznesowy. W ramach tego procesu zachodzi nastpujca sekwencja czynnoci: redaktor z uprawnieniami administratora wybiera z listy recenzenta, do ktrego automatycznie wysyane
jest zawiadomienie (poczt elektroniczn SMTP), i zapisywany jest stan procesu
w bazie danych. Zamiast wywoywa wiele metod dla obiektw modelu dziedzinowego
w warstwie prezentacji, moemy wywoa jedn metod void assignReviewer(Paper
paper,int reviewerId), zdefiniowan w fasadzie PaperService, ktrej kod zosta zamieszczony na listingu 2.2. Zgodnie z dobr praktyk programowania obiektowego,
polegajc na przedkadaniu interfejsw nad implementacje, wszystkie metody wymagane dla realizacji procesw biznesowych zwizanych z przetwarzaniem artykuw
konferencyjnych s okrelone w interfejsie PaperService.
Listing 2.2. Kod rdowy interfejsu PaperService
package isrp.model.service;
import java.util.List;
import org.apache.myfaces.custom.fileupload.UploadedFile;
import isrp.hibernate.model.businessobject.Paper;
import isrp.hibernate.model.businessobject.User;
import isrp.hibernate.model.util.email.EmailConfiguration;
public interface PaperService {
boolean addPaperNewVersion(Paper paper,User author,UploadedFile
uploadedFile,String uploadPath,EmailConfiguration emailConfiguration);
void update(Paper paper);
void assignReviewer(Paper paper,int reviewerId,EmailConfiguration
emailConfiguration);
boolean addPaper(Paper paper,User author,UploadedFile uploadedFile,String
uploadPath,EmailConfiguration emailConfiguration);
Paper findById(int id);
void delete(Paper paper);
void approvePaper(Paper paper,EmailConfiguration emailConfiguration);
void rejectPaper(Paper paper,EmailConfiguration emailConfiguration);
List<Paper> getReviewerPapers(int reviewerId, String sortColumn);
List<Paper> getAuthorPapers(int userId, String sortColumn);
List<Paper> getAllPapers(String sortColumn);
List<Paper> getAllPapers(String sortColumn,Integer userId, Integer role);
}
Implementacja metod interfejsu PaperService znajduje si w klasie PaperServiceImpl.

Poniewa rozmiar caego kodu klasy jest obszerny, na listingu 2.3 zamieszczony zosta wycznie jego fragment, zawierajcy deklaracj klasy oraz implementacj metody
odpowiedzialnej za przypisanie recenzenta i wysanie powiadomienia poczt elektroniczn.
Listing 2.3. Implementacja interfejsu PaperService
public class PaperServiceImpl implements PaperService{
public PaperServiceImpl() {}// bezargumentowy konstruktor
public void assignReviewer(Paper paper, int reviewerId,
EmailConfiguration emailConfiguration) {
83
/* pobranie obiektw dostpowych do tabel patrz listing 2.11*/

PaperDao pDao = DaoFactory.getInstance().getPaperDao();
UserDao uDao = DaoFactory.getInstance().getUserDao();
pDao.saveOrUpdate(paper);
User author=(User) uDao.findById(paper.getAuthorId());//pobranie obiektu autora
User reviewer=(User) uDao.findById(reviewerId);//pobranie obiektu recenzenta
/* wysanie potwierdzenia poczt elektroniczn*/
EmailSender eSender = new EmailSender(emailConfiguration);
eSender.sendEMail(EmailMessagesUtil
.assignReviewerMessageToReviewer(reviewer, paper));
}
/* ... implementacje pozostaych metod interfejsu PaperService*/
}
Wzorzec fasady
Wzorzec fasady jest jednym z podstawowych i jednoczenie najprostszych strukturalnych wzorcw projektowych. Zapewnia on dostp do zoonych systemw, prezentujc
uproszczony lub uporzdkowany interfejs programistyczny. Wzorzec fasady pozwala:
ukry zoono tworzonego systemu poprzez dostarczenie prostego interfejsu API,
uproci interfejs istniejcego systemu poprzez stworzenie nakadki, ktra
dostarcza nowy interfejs API.

Obiekt fasady jest prostym obiektem poredniczcym pomidzy obiektem klasy klienta
dajcym okrelonej funkcjonalnoci a klasami dostarczajcymi elementw do uzyskania tej funkcjonalnoci.
2.2.1.3. Lokalizatory usug

Usugi biznesowe powinny by atwo dostpne dla wszelkiego typu klientw, niezalenie od tego, czy s one klientami lokalnymi, czy te zdalnymi. Gdy w warstwie
biznesowej wystpuje wiele fasad, korzystanie z usug biznesowych moemy uatwi
poprzez zastosowanie uproszczonej wersji wzorca lokalizatora usug (czciowo opisanego w rozdziale 1., w ramce Wzorzec delegata biznesowego). Obiekt lokalizatora tworzy jeden punkt dostpowy do kodu warstwy biznesowej, jednoczenie zmniejszajc zaleno klienta od implementacji mechanizmw wyszukiwania usug.
Zazwyczaj lokalizator jest implementowany jako pojedynczy obiekt (singleton), chyba
e stosowany jest w rodowisku rozproszonym.
Na przykad w systemie ISRP istniej zdefiniowane odrbne fasady dla usug zwizanych
z przetwarzaniem artykuw, uytkownikw, recenzentw, formularzy z pytaniami
oraz danych sownikowych. Przedstawiony na listingu 2.4 interfejs ServiceLocator
zawiera deklaracje metod, ktre udostpniaj obiekty implementujce interfejsy tych
fasad. Operowanie na interfejsach pozwala na uniezalenienie si od jednej konkretnej
implementacji zestawu fasad, dziki czemu atwo moemy dostarczy implementacje
zoptymalizowane pod ktem wydajnoci czy bezpieczestwa.
84
Listing 2.4. Kod rdowy interfejsu lokalizatora usug

package isrp.model.service.factory;
import isrp.model.service.CountryService;
import isrp.model.service.PaperService;
import isrp.model.service.QuestionService;
import isrp.model.service.ReviewService;
import isrp.model.service.UserService;
public interface ServiceLocator {
PaperService getPaperService();
UserService getUserService();
ReviewService getReviewService();
CountryService getCountryService();
QuestionService getQuestionService();
}
Na listingu 2.5 przedstawiono kod klasy lokalizatora ServiceLocatorImpl, definiujcego

metody dostpowe zwracajce obiekty fasad. Aby tak prosty lokalizator wykonywa
swoje zadanie, naley waciwie zainicjowa i przechowa jego instancj w kontenerze,
co jest opisane w nastpnym punkcie.
Listing 2.5. Kod rdowy lokalizatora usug ServiceLocatorImpl
package isrp.model.service.factory;
import org.apache.commons.logging.*;
import isrp.model.service.*;
import isrp.model.service.impl.*;
public class ServiceLocatorImpl implements ServiceLocator{
private
private
private
private
private
PaperService paperService;
UserService userService;
ReviewService reviewService;
CountryService countryService;
QuestionService questionService;
private Log log = LogFactory.getLog(this.getClass());

public ServiceLocatorImpl() {
this.paperService = new PaperServiceImpl();
this.userService = new UserServiceImpl();
this.reviewService = new ReviewServiceImpl();
this.countryService = new CountryServiceImpl();
this.questionService = new QuestionServiceImpl();
this.log.info("Service locator bean is initialized");
}
public PaperService getPaperService() {return paperService;}
public UserService getUserService() {return userService;}
public ReviewService getReviewService() {return reviewService;}
public CountryService getCountryService() {return countryService;}
public QuestionService getQuestionService() {return questionService;}
}
85
2.2.1.4. Integracja warstwy usugowej z warstw prezentacji JSF

Wygodnym sposobem integracji warstwy usugowej z warstw prezentacji aplikacji
JSF jest wykorzystanie mechanizmu komponentw zarzdzanych. Na przykad obiekt
lokalizatora usug moe zosta zarejestrowany w aplikacji jako komponent zarzdzany
o zasigu aplikacji. Bdzie on wwczas automatycznie tworzony w momencie pierwszego odwoania si do niego, a nastpnie przechowywany w kontekcie aplikacji JSF
a do koca jej dziaania.
Deklaratywny sposb rejestracji obiektu lokalizatora w pliku faces-config.xml zosta
zaprezentowany na listingu 2.6. Pokazane na przykadzie rozwizanie umoliwia dostp do obiektu lokalizatora poprzez wykorzystanie jego identyfikatora service
LocatorImpl lub waciwoci komponentu uytkowego utilBean (opis komponentw
zarzdzanych znajduje si w rozdziale 3.). W omawianym przykadzie lokalizatorem
jest obiekt zaprezentowanej na listingu 2.5 klasy ServiceLocatorImpl, ale dziki stosowaniu interfejsw fasad moe on zosta atwo zamieniony na inny obiekt bdcy
lokalizatorem, do czego wystarczy zmiana wartoci elementu <managed-bean-class>.
Moe si to okaza przydatne, np. gdy bdziemy chcieli zapewni buforowanie przesyanych danych czy zdalny dostp do usug.
Listing 2.6. Integracja warstwy usugowej w pliku faces-config.xml
<managed-bean>
<description> Komponent lokalizatora </description>
<managed-bean-name>serviceLocatorImpl</managed-bean-name>
<managed-bean-class>isrp.model.service.factory.ServiceLocatorImpl</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
</managed-bean>
<managed-bean>
<managed-bean-name>utilBean</managed-bean-name>
<managed-bean-class>isrp.viewbeans.UtilBean</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
<managed-property>
<property-name>serviceLocator</property-name>
<value>#{serviceLocatorImpl}</value>
</managed-property>

</managed-bean>
2.2.2. Interfejs do warstwy trwaoci danych

Cho wspczesne aplikacje WWW mog korzysta z wielu moliwoci w zakresie
utrwalania danych, to wci najpopularniejsz z nich jest stosowanie relacyjnych baz danych. Interfejs do warstwy trwaoci powinien cakowicie oddziela szczegy technologii relacyjnych od warstwy biznesu, jednoczenie zapewniajc nastpujce operacje:
funkcje CRUD, tj. ang. Create, Retrieve, Update, Delete (utwrz, odczytaj,
modyfikuj i usu obiekty w pamici trwaej),

tworzenie i uruchamianie zapyta do bazy danych,
zarzdzanie poczeniami, transakcjami, buforowaniem i wydajnoci.
86
Korzystajc z relacyjnych baz danych, naley zapewni odwzorowania obiektw Javy

na tabele, kolumny i rekordy, podobnie jak mapowanie wzajemnych relacji pomidzy
obiektami na powizania tabel i rekordw. W tym celu mona zastosowa :
interfejs JDBC API,
komponenty encji dostpne w technologii Java Persistence API,
technologie odwzorowa obiektowo-relacyjnych (ORM).
W zasadzie dwa ostatnie rozwizania s do podobne JPA byo wzorowane na

szkieletach ORM Hibernate i TopLink. Technologie ORM pozwalaj zarwno utrwala
obiekty POJO w bazie danych, jak i generowa model dziedzinowy na podstawie
schematu bazy danych (tzw. reverse engineering). Dziki temu stanowi wygodne
rozwizanie, ktre moemy wykorzysta niezalenie od scenariusza, wedug jakiego
wytwarzana jest warstwa trwaoci, a mianowicie gdy:
istnieje kod Javy i naley zapewni przechowywanie obiektw Javy w bazie
danych,
istnieje zaprojektowana (lub odziedziczona z innego systemu) baza danych
i naley napisa kod aplikacji. Model dziedzinowy w Javie jest dopasowywany

do schematu bazy danych,
istnieje zarwno baza danych, jak i cz kodu Javy, ktre naley powiza .
W dalszych punktach przyblione zostan najwaniejsze informacje dotyczce wykorzystania biblioteki Hibernate w celu zapewnienia dostpu do danych.
2.2.2.1. Interfejs warstwy danych oparty na Hibernate

Hibernate jest darmowym szkieletem programistycznym, sucym do realizacji warstwy dostpu do danych i zapewniajcym translacj danych pomidzy relacyjn baz
danych a wiatem obiektowym. Uycie Hibernate powoduje, e z punktu widzenia
programisty baza danych zawiera zwyke obiekty Javy (POJO). Hibernate zapewnia
poczenia z baz danych i obsug podstawowych operacji na nich z uwzgldnieniem
przenonoci midzy rnymi dialektami SQL.
Zasada dziaania Hibernate opiera si na zastosowaniu plikw konfiguracyjnych definiowanych w jzyku XML oraz uyciu mechanizmu refleksji do pobierania obiektw
i waciwoci klas. Plik konfiguracyjny o nazwie hibernate.cfg.xml zawiera globalne
ustawienia parametrw szkieletu oraz poczenia do bazy danych. Przykad pliku konfiguracyjnego dla aplikacji ISRP zosta przedstawiony na listingu 2.7. Znaczenie poszczeglnych elementw opisane jest w komentarzach do kodu.
Listing 2.7. Plik konfiguracji Hibernate
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
87


<property name="hibernate.connection.driver_class">com.mysql.
jdbc.Driver</property>
<property name="hibernate.connection.url">jdbc:mysql:
//localhost/isrp</property>
<property name="hibernate.connection.useUnicode">yes</property>
<property name="hibernate.connection.characterEncoding">UTF-8</property>
<property name="hibernate.connection.username">root</property>
<property name="hibernate.dialect">org.hibernate.dialect.
MySQLDialect</property>
<property name="current_session_context_class">thread</property>

<property name="hibernate.show_sql">true</property>

<mapping resource="isrp/hibernate/model/businessobject/Answer.hbm.xml" />
<mapping resource="isrp/hibernate/model/businessobject/User.hbm.xml" />
<mapping resource="isrp/hibernate/model/businessobject/Country.hbm.xml" />
<mapping resource="isrp/hibernate/model/businessobject/Paper.hbm.xml" />
<mapping resource="isrp/hibernate/model/businessobject/Question.hbm.xml" />
<mapping resource="isrp/hibernate/model/businessobject/Review.hbm.xml" />
<mapping resource="isrp/hibernate/model/businessobject/
Answersquestions.hbm.xml" />
</session-factory>
</hibernate-configuration>
Pliki mapowa Hibernate odpowiadaj za translacj danych znajdujcych si w tabeli

na obiekty Javy i odwrotnie. Oznaczane s przyrostkiem .hbm.xml, gdzie pierwszy element przyrostka jest skrtem od wyraenia HiBernate Mapping. Poniej zamieszczono
fragment pliku mapowania User.hbm.xml. Diagram penego mapowania przykadowej klasy User do tabeli user, wygenerowany przy uyciu narzdzia HibernateTools,
zaprezentowano na rysunku 2.8.
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping>
<class name="isrp.hibernate.model.businessobject.User" table="user" catalog="isrp">
<id name="id" type="java.lang.Integer">
<column name="id" />
<generator class="identity" />
</id>
<property name="countryId" type="int">
<column name="countryId" not-null="true" />
</property>
</class>
</hibernate-mapping>
Instalacja Hibernate sprowadza si do pobrania i rozpakowania pakietw instalacyjnych,

dostpnych na stronie http://sourceforge.net/projects/hibernate/files/hibernate3/. Po
rozpakowaniu pliki bibliotek powinny zosta umieszczone w ciece przeszukiwania
klas projektu. Najwaniejsze klasy Hibernate znajduj si w pliku hibernate3.jar, a klasy
pomocnicze w plikach bibliotek: commons-collections.jar, commons-logging.jar,
dom4j.jar, hsqldb.jar, jta.jar, c3p0.jar, ehcache.jar, cglib.jar i antlr.jar.
88
Rysunek 2.8. Przykadowy diagram mapowania wygenerowany w HibernateTools
Hibernate Tools
Wsparcie korzystania z biblioteki Hibernate w rodowisku Eclipse zapewnia wtyczka
programistyczna Hibernate Tools, udostpniana za darmo przez Red Hat Inc. Hibernate
Tools dostarcza zestaw widokw i kreatorw zawierajcy m.in.:
kreator dla realizacji procesu inynierii wstecznej (ang. reverse engineering),
umoliwiajcy wygenerowanie modelu obiektowego na podstawie tabel i kolumn

istniejcej bazy danych,
kreator konfiguracji hibernate.cfg.xml,
w peni funkcjonalny edytor dla jzyka Hibernate HQL,
okno komend jzyka SQL,
podpowiadanie skadni SQL,
w peni funkcjonalny edytor plikw odwzorowa .hbm.xml.
Wtyczk Hibernate Tools moemy zainstalowa wedug opisu w ramce Wtyczki programistyczne w Eclipse. Wwczas w polu Work with menedera instalacji wpisujemy nastpujcy adres:
http://download.jboss.org/jbosstools/updates/stable.
2.2.2.2. Obiekty dostpu do danych DAO

Obiekty implementujce interfejs do warstwy trwaoci s zazwyczaj okrelane jako
obiekty dostpu do danych (ang. Data Access Objects DAO). Dobr praktyk projektow wynikajc ze stosowania tego wzorca jest tworzenie pojedynczego obiektu
DAO dla kadej utrwalanej klasy. Generalnie do najwaniejszych zada DAO nale
tworzenie (pobieranie) sesji Hibernate oraz zapisywanie (pobieranie) obiektw.
89
Poniewa pewne operacje (zapis, odczyt czy wyszukiwanie) powtarzaj si we wszystkich
DAO, celem uniknicia powielania kodu moemy zdefiniowa wsplny interfejs oraz
klas abstrakcyjn zawierajc definicj powtarzajcych si dla rnych typw operacji.
Generyczny interfejs zosta zaprezentowany na listingu 2.8, a implementujca jego
metody klasa abstrakcyjna GenericDao na listingu 2.9.
Listing 2.8. Interfejs definiujcy podstawowe operacje dla DAO
package isrp.hibernate.model.dao;
public interface GenericDaoInterface {
public abstract Object findById(int id);//wyszukiwanie po id
public abstract void save(Object object);//zapisywanie nowego obiektu
public abstract void saveOrUpdate(Object object);//zapisywanie lub modyfikowanie
//obiektu, jeli istnieje
public abstract void delete(Object object);//usuwanie obiektu
public abstract List findAll();//wyszukiwanie wszystkich obiektw
}
Listing 2.9. Implementacje podstawowych operacji dostpnych w DAO

import isrp.hibernate.model.util.HibernateUtil;
import org.hibernate.SessionFactory;
import org.hibernate.Session;
import org.hibernate.Criteria;
public abstract class GenericDao implements GenericDaoInterface {
protected Class persistedClass;
protected Session session;
public GenericDao(Class persistedClass) {
/* pobranie sesji Hibernate z obiektu klasy uytkowej, zaprezentowanej na listingu 2.14*/
SessionFactory factory = HibernateUtil.getSessionFactory();
this.session = factory.getCurrentSession();
this.persistedClass = persistedClass;
}
public Object findById(int id) {
Object object = (Object) session.get(persistedClass, id);
return object;
}
public void save(Object object) {
session.save(object);
}
public void saveOrUpdate(Object object) {
session.saveOrUpdate(object);
}
public void delete(Object object) {
session.delete(object);
}
public List findAll() {
Criteria criteria = session.createCriteria(persistedClass);
return criteria.list();
}
}
90
Zastosowanie klasy abstrakcyjnej GenericDao pozwala na znaczne uproszczenie implementacji konkretnych obiektw DAO. Na listingu 2.10 znajduje si kod rdowy
klasy UserDao, w ktrym zaimplementowane zostay wycznie operacje specyficzne
dla utrwalania obiektw User.
Listing 2.10. Kod rdowy klasy UserDao
import org.hibernate.Query;
import org.hibernate.criterion.Order;
import org.hibernate.criterion.Restrictions;
import isrp.hibernate.model.businessobject.User;
import isrp.hibernate.model.util.Md5HashCode;
public class UserDao extends GenericDao {
public UserDao() {
super(User.class);//
}
public String getAdministratorEmail(){
User user = null;
Query query = session.createQuery("FROM User where role=?")
.setByte(0, new Byte("1"));
user = (User) query.uniqueResult();
return user.getEmail();
}
public List getReviewers(){
return session.createCriteria(persistedClass)
.add(Restrictions.eq("role", new Byte("3")))
.list();
}
public User authenticate(String email, String password) {
password = Md5HashCode.getMd5HashCode(password);
return (User) session.createCriteria(persistedClass)
.add(Restrictions.eq("email", email))
.add(Restrictions.eq("password", password))
.uniqueResult();
}
public User checkIfEmailExistInDB(String email) {
Query query = session.createQuery("FROM User where email=?")
.setString(0, email);
return (User) query.uniqueResult();
}
public List<User> getUsers(String sortColumn){
if (sortColumn==null){
sortColumn="firstName";
}
return (List<User>) session.createCriteria(persistedClass)
.addOrder(Order.asc(sortColumn))
.list();
}
}
91
Automatyczne generowanie DAO w Hibernate Tools

Hibernate umoliwia automatyczne generowanie obiektw DAO z wykorzystaniem
narzdzia Ant (opis znajduje si w dokumentacji Hibernate) bd wymienionej ju w tym
rozdziale wtyczki Hibernate Tools. Korzystajc z wtyczki Hibernate Tools, w rodowisku Eclipse w grupie menu Run pojawi si nowa opcja Hibernate Code Generation
Configurations, bdca konfiguracj uruchomieniow automatycznego generowania
kodu przy uyciu Hibernate. Wybr tej opcji powoduje wywietlenie okna kreatora
Create, manage and run configurations, ktre w zakadce Exporters pozwala ustawi
opcj automatycznego generowania kodu rdowego klas DAO (opcja DAO code).
Automatycznie generowane w ten sposb klasy bd jednak opiera si na wykorzystaniu
interfejsu JNDI i obiektw klasy javax.naming.InitialContext. Nie jest to problemem w przypadku serwerw aplikacji, ale przy korzystaniu z prostych kontenerw
serwletw, takich jak Tomcat, stanowi to utrudnienie, gdy naley samodzielnie zapewni kontekst pocztkowy. Tomcat wprawdzie dostarcza wasny obiekt kontekstowy
JNDI, ale nie mona go modyfikowa z poziomu kodu aplikacji (jest tylko do odczytu), co powoduje, e nie moe on by wykorzystany przez Hibernate. Rozwizaniem
tego problemu jest uycie biblioteki Sun FS Context, dostpnej w pliku fscontext.jar,
ktra umoliwia przechowanie kontekstu aplikacji w postaci plikw.
2.2.2.3. Fabrykowanie obiektw DAO

Analogicznie do problemu lokalizacji fasad w warstwie usugowej w przypadku uycia DAO rwnie istotnym problemem jest zapewnienie atwej lokalizacji obiektw
poprzez centralizacj dostpu. W przypadku interfejsu do warstwy trwaoci centralizacja ma za zadanie uatwienie tworzenia obiektw DAO oraz zamiany ich implementacji. Dostarczenie interfejsu do tworzenia rnych obiektw implementujcych
wsplny interfejs bez specyfikowania ich konkretnych klas zapewnia wzorzec projektowy fabryki abstrakcyjnej (ang. abstract factory). Umoliwia on jednemu obiektowi
tworzenie rnych, powizanych ze sob reprezentacji podobiektw, okrelajc ich
typy podczas dziaania programu.
Przykadowa fabryka abstrakcyjna dla obiektw DAO uyta w aplikacji ISRP zaprezentowana zostaa na listingu 2.11, a jej implementacja na listingu 2.12. Przykady
wykorzystania fabryki obiektw do tworzenia DAO w warstwie usugowej zaprezentowano na listingu 2.13.
Listing 2.11. Fabryka abstrakcyjna obiektw DAO
package isrp.hibernate.model.dao.factory;
import isrp.hibernate.model.dao.*;
public abstract class DaoFactory {
private static DaoFactory instance = new HibernateDaoFactory();
public static DaoFactory getInstance() {
return instance;
}
92

public
public
public
public
public
public
abstract
abstract
abstract
abstract
abstract
abstract
UserDao getUserDao();
CountryDao getCountryDao();
PaperDao getPaperDao();
QuestionDao getQuestionDao();
ReviewDao getReviewDao();
AnswersquestionsDao getAnswersquestionsDao();
Listing 2.13. Implementacja fabryki obiektw DAO

package isrp.hibernate.model.dao.factory;
import isrp.hibernate.model.dao.*;
public class HibernateDaoFactory extends DaoFactory {
public UserDao getUserDao() {return new UserDao();}
public CountryDao getCountryDao() {return new CountryDao();}
public PaperDao getPaperDao() {return new PaperDao();}
public QuestionDao getQuestionDao() {return new QuestionDao();}
public ReviewDao getReviewDao() {return new ReviewDao();}
public AnswersquestionsDao getAnswersquestionsDao() {return new
AnswersquestionsDao();}
}
Listing 2.13. Kod filtru umoliwiajcego automatyczne zarzdzanie sesj Hibernate

package isrp.filters;
import isrp.util.HibernateUtil;
import java.io.IOException;
import javax.servlet.*;
import org.apache.commons.logging.*;
import org.hibernate.*;
public class HibernateSessionFilter implements Filter {
private SessionFactory factory = null;
private static final Log log = LogFactory.getLog(HibernateSessionFilter.class);
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
Session session = factory.getCurrentSession();
try {
session.beginTransaction();
log.debug("<< HIBERNATE START");
chain.doFilter(request, response);
log.debug(">> HIBERNATE END");
session.getTransaction().commit();
} catch (Throwable e) {
try {
if (session.getTransaction().isActive()) {
session.getTransaction().rollback();
}
} catch (HibernateException e1) {
log.error("Niemoliwe wykonanie operacji rollback", e1);
e1.printStackTrace();
}
throw new ServletException(e);
93
}
}
public void destroy() {}
public void init(FilterConfig filterConfig) throws ServletException{
factory = HibernateUtil.getSessionFactory();
if (filterConfig == null) {
log.error("HibernateSessionFilter: Nie zainicjowano filtru");
throw new ServletException();
}
}
}
2.2.2.4. Zarzdzanie sesj Hibernate w warstwie widoku

W celu zapewnienia zarzdzania poczeniem z baz danych (tzw. sesj Hibernate)
moemy wykorzysta wzorzec Open Session in View (OSIV), ktrego idea opiera si
na zaoeniu, e zawsze do wygenerowania odpowiedzi HTTP niezbdne s informacje
przechowywane w bazie danych. Sesja Hibernate otwierana jest po pojawieniu si dania HTTP i jest dostpna przez cay proces generowania strony widoku. Wprowadzone
zmiany do bazy zatwierdzane s dopiero po realizacji caego dania, tj. wygenerowaniu dokumentu odpowiedzi HTTP. Nie jest to jedyna moliwa do zastosowania tutaj
strategia; warto wspomnie o rozwizaniach polegajcych na wprowadzaniu zmian do
bazy danych w trybie automatycznego zatwierdzania transakcji (autocommit) czy te
inicjowaniu sesji i pobieraniu danych niezbdnych do generowania warstwy widoku
jeszcze przed przekazaniem sterowania do niej. Strategie zarzdzania sesj Hibernate
opisane s wyczerpujco w ksikach POJOs in Action. Developing Enterprise Applications with Lightweight Frameworks2 oraz Java Persistence with Hibernate3. Wzorzec
OSIV pozwala na realizacj wielu operacji w trakcie jednej sesji z Hibernate. Na listingu
2.13 przedstawiono uyty w aplikacji ISRP filtr implementujcy wzorzec OSIV. Filtr
przechwytuje wszystkie dania pynce do aplikacji i dla kadego z nich rozpoczyna
now transakcj, w ktrej realizowane s wszystkie operacje na bazie danych, realizowane w trakcie przetwarzania dania HTTP. Transakcja jest zatwierdzana dopiero
po zakoczeniu przetwarzania dania. Filtr zawiera obsug wszelkich wyjtkw i bdw, ktre mog wystpi podczas przetwarzania dania. Jeli istnieje aktywna sesja
Hibernate, to po wystpieniu bdw lub wyjtkw zmiany w bazie danych s wycofywane (rollback). W kodzie do pobrania biecej sesji Hibernate uyto klasy pomocniczej HibernateUtil, zaprezentowanej na listingu 2.14. Interakcje wystpujce
pomidzy elementami implementacji wzorca OSIV przedstawione zostay na rysunku 2.9.
Rejestracja filtru w pliku web.xml w najprostszym schemacie bdzie mie nastpujc
posta :
Chris Richardson, POJOs in Action. Developing Enterprise Applications with Lightweight Frameworks,
Manning 2006.
Christian Bauer, Gavin King, Java Persistence with Hibernate, Manning 2006.
94

<filter>
<filter-name>HibernateSessionFilter</filter-name>
<filter-class>isrp.filters.HibernateSessionFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>HibernateSessionFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Jak atwo zauway , w powyszym kodzie wykonano mapowanie filtru na wszystkie

zasoby URL, co jest rozwizaniem wysoce niewydajnym sesja Hibernate jest tworzona zawsze, rwnie dla tych da HTTP, ktrych przetwarzanie nie wymaga poczenia do bazy danych. Uytkownik w tym miejscu w zalenoci od potrzeb moe
zmieni mapowanie na wybrane dania lub filtracj da obsugiwanych tylko
przez wybrany serwlet (np. poprzez wstawienie w miejsce znacznikw <url-pattern>
znacznika <servlet-name>Faces Servlet</servlet-name> do obsugi da przez aplikacj JSF).
Listing 2.14. Kod klasy uytkowej HibernateUtil
package isrp.hibernate.model.util;
import org.hibernate.cfg.AnnotationConfiguration;
import org.hibernate.SessionFactory;
public class HibernateUtil {
private static final SessionFactory sessionFactory;
private static final Log log = LogFactory.getLog(HibernateUtil.class);
static {
try {// Tworzy SessionFactory na podstawie konfiguracji w pliku hibernate.cfg.xml
sessionFactory = new AnnotationConfiguration()
.configure().buildSessionFactory();
} catch (Throwable ex) {
log.error("Nie mona pobra sesji Hibernate " + ex);
throw new ExceptionInInitializerError(ex);
}
}
public static SessionFactory getSessionFactory() {
return sessionFactory;
}
}
Organizujc kod aplikacji, naley pamita, e HibernateSessionFilter jest elementem warstwy widoku aplikacji WWW, podczas gdy klasa HibernateUtil zapewnia
dostp do warstwy trwaoci.
Klient
Kontener Web
Hibernate Filter
HibernateUtil
95
FacesServlet
JSF Request()
doFilter()
getSessionFactory()
beginTransaction()
service()
commit()
Rysunek 2.9. Diagram sekwencji wzorca OSIV dla aplikacji JSF
2.3. Organizacja kodu aplikacji

w Eclipse
Kod aplikacji WWW opartych na technologii Java EE zazwyczaj jest wytwarzany
w postaci wielu moduw, rozwijanych niezalenie przez rne zespoy projektowe.
Rozproszenie kodu aplikacji w wielu projektach uatwia m.in.:
zarzdzanie kodem rdowym i plikami zasobw,
podzia pracy w zespoach,
zautomatyzowanie procesu wytwarzania i testowania aplikacji.
W dalszej czci rozdziau znajduje si opis rozwiza, jakie zapewnia Eclipse WTP
w zakresie organizacji kodu rdowego oraz integracji i wdraania skompilowanych
moduw aplikacji na serwerze.
2.3.1. Projekty i moduy Java EE w Eclipse

Zanim zajmiemy si planowaniem rozmieszczenia kodu aplikacji ISRP, warto przybliy
podstawowe koncepcje zwizane z wytwarzaniem i wdraaniem aplikacji Java EE w rodowisku Eclipse Web Tools Platform, a mianowicie projekt i modu aplikacji.
96
Wszystkie pliki rdowe oraz inne zasoby aplikacji bd biblioteki musz by umieszczone w projekcie skadajcym si z jednego lub wielu zagniedonych katalogw.
Projekt stanowi podstawow jednostk organizacyjn kodu aplikacji i jest zapisywany
w przestrzeni projektw (ang. workspace). Projekt opisywany jest za pomoc metadanych, ktre zawieraj pomocnicze informacje o wymaganych zasobach zewntrznych, sposobie kompilacji czy rodowisku uruchomieniowym. Logiczna struktura
prezentowanych w oknie Project Explorer katalogw i zasobw projektu jest zoptymalizowana pod ktem uatwienia pracy deweloperom.
Modu aplikacji (ang. module) reprezentuje gotowy do wdroenia na serwerze aplikacji kod wynikowy projektu (powstay po jego skompilowaniu), ktry moe by reprezentowany przy uyciu plikw archiwalnych, np. WAR lub JAR. Moduy Java EE
posiadaj okrelon przez specyfikacj Java EE fizyczn struktur katalogw oraz
plikw. Moduy mog by wdraane w kontenerze Java EE zarwno w postaci spakowanych plikw archiwum, jak te rozpakowanych struktur katalogw. Eclipse
WTP wspiera wytwarzanie i wdraanie nastpujcych moduw Java EE (w nawiasach
podano typy archiwum oraz nazwy odpowiadajcych im projektw Eclipse po mylniku):
Enterprise application (EAR) Enterprise application Project,
Enterprise application client (JAR) Application Client Project,
Enterprise JavaBean (JAR) EJB Project,
Web application (WAR) Dynamic Web Project,
Resource adapter for JCA (RAR) Connector Project,
Utility module (JAR) Utility Project.
Pierwszych pi wymienionych typw moduw jest okrelonych w specyfikacji Java

EE, natomiast ostatni typ zosta wprowadzony przez rodowisko Eclipse i stanowi
modu uytkowy (Utility module) oglnego przeznaczenia, umoliwiajcy podzia
kodu aplikacji na oddzielne projekty. Kady projekt WTP moe generowa tylko jeden
modu aplikacji, ale w kodzie rdowym projektu mona odwoywa si do kodu
umieszczonego w innych moduach. Odwoywanie si do kodu znajdujcego si w innych
moduach wymaga jednak jawnego zdefiniowania zalenoci pomidzy projektami,
co jest zilustrowane przykadem w dalszej czci rozdziau.
2.3.2. Zastosowanie projektu uytkowego

do przechowywania kodu warstwy biznesowej
Zamy, e chcemy umoliwi rozwijanie aplikacji ISRP w dwch projektach, tak
by kod warstwy prezentacji opartej na szkielecie JSF znajdowa si w jednym projekcie, a kod pozostaych warstw (biznesowej i dostpu do danych) w innym. Zalet takiego podziau bdzie moliwo wielokrotnego wykorzystania moduu zawierajcego
warstw biznesow w aplikacjach zawierajcych interfejsy oparte na rnych technologiach (np. JSF i Swing).
97
W materiaach pomocniczych do ksiki Czytelnik znajdzie m.in. kod moduu uytkowego ISRPModel, zawierajcy implementacj warstwy biznesowej, udostpniony
w postaci zarchiwizowanego pliku projektu Eclipse oraz skompilowanej wersji moduu w pliku JAR. Czytelnik, ktry chciaby pomin zagadnienia wytwarzania warstwy biznesowej, moe skorzysta z gotowego do uycia moduu ISRPModel i skupi
si wycznie na implementacji interfejsu uytkownika wedug wskazwek zamieszczonych w nastpnych rozdziaach.
Na rysunku 2.10 przedstawiono struktur aplikacji ISRP, ktra skada si z moduw
Web Application oraz Utility Module. Modu Web Application zawiera kod warstwy
prezentacji i jest tworzony w rodowisku Eclipse przy uyciu projektu typu Dynamic
Web Project (przykad takiego projektu zosta zaprezentowany w rozdziale 1.). Modu
Utility Module przechowuje warstw biznesow aplikacji ISRP i jest tworzony w rodowisku Eclipse przy uyciu projektu typu Utility Project.
Dynamic Web Project (WAR)
library
JavaServer Faces
Komponenty
wspierajce
Komponenty
zarzdzane
Zasoby
Widoki JSP
Walidatory i
konwertery
Filtry
Utility Project (JAR)
Warstwa biznesowa
interface
Interfejsy warstwy usugowej
Implementacje
usug
Model dziedzinowy
(obiekty biznesowe)
Warstwa dostpu do danych
library
Hibernate
Obiekty DAO
Odwzorowania OR
Rysunek 2.10. Struktura moduw aplikacji ISRP oraz zalenoci wystpujce pomidzy nimi
98
Projekt typu Java EE Utility Project jest bardzo podobny do zwykego projektu Javy
w rodowisku Eclipse, ale posiada dodatkowy pakiet rozszerze (tzw. facet) Utility
Module (idea pakietw rozszerze Eclipse zostaa omwiona w rozdziale 1., w ramce
JSF Facet). Utility Module stanowi cz konfiguracji uruchomieniowej projektu
i umoliwia wykorzystanie skompilowanego kodu projektu w innych moduach aplikacji
korporacyjnej (Java EE). Gdy zmiany w projekcie zostan zapisane, Eclipse automatycznie go skompiluje i spakuje kod wynikowy do pliku JAR, ktry nastpnie jest publikowany (bd aktualizowany) na serwerze oraz w innych projektach, ktre z niego
korzystaj.
Ze wzgldu na opisane wyej waciwoci Utility Project znakomicie nadaje si do
przechowywania kodu warstwy biznesowej oraz interfejsu warstwy trwaoci, oczywicie pod warunkiem, e model dziedzinowy nie jest oparty na komponentach EJB
(w takim przypadku wymagany jest EJB Module).
W celu utworzenia nowego projektu Java EE Utility Project naley wykona nastpujce
kroki:
1. Z menu aplikacji wybieramy opcj File/New/Project. Pojawi si okno kreatora
New Project, w ktrym wywietli si lista typw projektw.

2. Na licie wskazujemy grup projektw korporacyjnych (Java EE). Po rozwiniciu
elementw grupy wybieramy opcj Utility Project i zatwierdzamy przyciskiem Next.

Wywietli si okno kreatora New Java Utility Module, pokazane na rysunku 2.11.
Rysunek 2.11.
Tworzenie projektu
typu Utility Project
99
3. W polu Project name wpisujemy nazw projektu. Nastpnie z listy rozwijanej
Target Runtime wybieramy rodowisko uruchomieniowe serwera, na ktrym

ma by publikowany kod wynikowy projektu. Aby doda kolejne pakiety
rozszerze Eclipse do projektu (np. dla szkieletu Spring), naley w sekcji
Configuration klikn przycisk Modify i w nowym oknie kreatora zaznaczy
odpowiednie pola wyboru. Wszystko zatwierdzamy przyciskiem Next
i przechodzimy do kolejnego okna, w ktrym moemy zaczy do projektu
dodatkowe rda. Cao zatwierdzamy przyciskiem Finish.
2.3.3. Moduy zalene

Istniej dwa sposoby wykorzystania gotowego moduu uytkowego w aplikacji, a mianowicie:
bezporednie wdroenie moduu uytkowego w rodowisku uruchomieniowym
serwera (opisane w poprzednim punkcie),

ustawienie zalenoci pomidzy projektami i wykorzystanie moduu uytkowego
podczas budowy innego moduu.

W drugim przypadku we waciwociach projektu Utility Project ustawiamy warto
<None> w polu Target Runtime. Aby doczy modu Utility Module do dowolnego
innego projektu Java EE, w oknie Project Explorer zaznaczamy projekt docelowy i z menu
kontekstowego wybieramy opcj Properties. Nastpnie w oknie waciwoci wybieramy stron Java EE Module Dependencies, po czym zaznaczamy pole wyboru przy
nazwie projektu, ktrego skompilowany kod chcemy doczy , jak pokazano na rysunku 2.12.
Rysunek 2.12.
Ustawianie zalenoci
pomidzy projektami
Java EE
100
Na przykad do budowy aplikacji ISRP wykorzystamy dwa projekty projekt Dynamic

Web Project (DWP) do rozwijania kodu warstwy prezentacji oraz Utility Project (UP)
do rozwijania warstwy biznesowej oraz warstwy dostpu do danych. Poniewa oczekiwanym moduem wynikowym aplikacji ma by aplikacja WWW, projekt DWP bdzie zaleny od UP. Po kadej kompilacji wynikowy modu Utility Module bdzie
automatycznie dodawany (zamieniany) do wynikowego pliku WAR oraz sekcji Web
App Libraries w ciece przeszukiwania projektu DWP. Jednoczenie kada zmiana
pliku WAR bdzie powodowa automatyczn publikacj nowej wersji aplikacji WWW
na serwerze, chyba e uytkownik zmieni domylne ustawienia dotyczce publikowania (patrz rozdzia 6., rysunek 6.2).
Wszystkie klasy i doczone do projektu uytkowego biblioteki s widoczne w projekcie
zalenym. Klasy i biblioteki projektu zalenego nie s jednak widoczne w projekcie
uytkowym. Niestety, nie moemy zdefiniowa odwrotnej zalenoci, gdy spowodowaoby to powstanie cyrkularnoci, ktra jest przez rodowisko Eclipse automatycznie wykrywana i traktowana jako bd. Do powszechnym rozwizaniem tego
problemu jest umieszczenie kodu niezbdnych dla obu projektw klas w oddzielnym projekcie uytkowym (Utility Project). W takim przypadku dwa projekty s zalene od trzeciego i nie powstaje pomidzy nimi zaleno cyrkularna.

JavaServer Faces I Eclipse Galileo. Tworzenie Aplikacji WWW

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

JavaServer Faces I Eclipse Galileo. Tworzenie Aplikacji WWW

Uploaded by

Copyright:

Available Formats

Id do

JavaServer Faces i Eclipse

Jak projektowa estetyczne i wygodne interfejsy uytkownika aplikacji WWW?

Rozdzia 1. Przed przystpieniem do pracy z JSF ............................................... 13

Rozdzia 2. Planowanie, modelowanie i projektowanie aplikacji JSF

JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW

Rozdzia 3. Uywanie JSF ............................................................................... 101

Rozdzia 4. Dopasowywanie JSF ..................................................................... 211

Rozdzia 5. Tworzenie komponentw uytkownika ........................................... 275

Rozdzia 6. Narzdzia wsparcia i integracja z innymi szkieletami ..................... 327

JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW

Dodatek A Standardy kodowania IANA ........................................................... 353

Atrybuty przekazywane HTML i zdarzenia DHTML ........................... 361

JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW

2.1. Modelowanie interfejsu

Scenopis i metodyki modelowania,

Rozdzia 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java

reguy nawigacji), oparty na notacji graficznej diagramu klas,

funkcjonalne interfejsu GUI, tj. kontrolki i ich rozmieszczenie,

kontrolera ekranu z warstw modelu aplikacji.

2.1.1. Przypadki uycia

JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW

Edytuj dane osobowe

Rysunek 2.1. Diagram przypadkw uycia dla ISRP

2.1.2. Model ekranw interfejsu uytkownika

Rozdzia 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java

Rozszerzany element UML

Ekran (w postaci strony WWW).

Fragment ekranu (strony WWW) przeznaczony do

Formularz strony WWW.

Pole wejciowe formularza.

Element zatwierdzajcy formularz i generujcy akcj.

JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW

2.1.3. Model nawigacji

Rozdzia 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java

globalMessage: String [0..*]

userName {user==authorized}: String

Rysunek 2.2. Model ekranu rejestracji i edycji danych uytkownika

2.1.4. Prototypy ekranw

JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW

+ globalMessage: String [0..*]

globalMessages: String [0..*]

+ globalMessage: String [0..*]

+ globalMessages: String [0..*]

+ globalMessage: String [0..*]

+ globalMessages: String [0..*]

globalMessages: String [0..*]

+ review.commentToAdmin {user.role==admin || user.role==reviewer}: String

Rysunek 2.3. Diagram nawigacji dla aplikacji ISRP

W technice scenopisw generalnie zaleca si stosowanie projektw szkieletowych,

Rozdzia 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java

Przykad projektu szkieletowego dla ekranu rejestracji uytkownika w systemie ISRP

Rysunek 2.4. Projekt szkieletowy ekranu rejestracji aplikacji ISRP

2.1.5. Diagram maszyny stanowej

JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW

entry / dezaktywuj przycisk Zarejestruj

entry / uaktywnij przycisk Zarejestruj

Rysunek 2.5. Diagram maszyny stanowej dla ekranu rejestracji

Stan pocztkowy reprezentuje stan kontrolera po utworzeniu jego instancji i jest

Rozdzia 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java

Przejcia wewntrzne lub zwrotne wystpuj w sytuacjach, gdy kompozycja ekranu

2.2. Warstwa biznesowa

2.2.1. Rola i elementy warstwy biznesowej

Rozdzia 3. Uywanie JSF ............................................................................... 101

Rozdzia 5. Tworzenie komponentw uytkownika ........................................... 275

kontrolera ekranu z warstw modelu aplikacji.

2.1.1. Przypadki uycia

2.1.2. Model ekranw interfejsu uytkownika

Element zatwierdzajcy formularz i generujcy akcj.

W technice scenopisw generalnie zaleca si stosowanie projektw szkieletowych,

Stan pocztkowy reprezentuje stan kontrolera po utworzeniu jego instancji i jest

Przejcia wewntrzne lub zwrotne wystpuj w sytuacjach, gdy kompozycja ekranu

Poniewa w aplikacjach korporacyjnych Java EE (J2EE) wymagane s dodatkowe

Przykadowymi komponentami JavaBean s komponenty wspierajce.

Na przykad na diagramie przypadkw uycia systemu ISRP wystpuje przypadek

Implementacja metod interfejsu PaperService znajduje si w klasie PaperServiceImpl.

/* pobranie obiektw dostpowych do tabel patrz listing 2.11*/

Listing 2.4. Kod rdowy interfejsu lokalizatora usug

Na listingu 2.5 przedstawiono kod klasy lokalizatora ServiceLocatorImpl, definiujcego

2.2.2. Interfejs do warstwy trwaoci danych

modyfikuj i usu obiekty w pamici trwaej),

Korzystajc z relacyjnych baz danych, naley zapewni odwzorowania obiektw Javy

W zasadzie dwa ostatnie rozwizania s do podobne JPA byo wzorowane na

Pliki mapowa Hibernate odpowiadaj za translacj danych znajdujcych si w tabeli

Instalacja Hibernate sprowadza si do pobrania i rozpakowania pakietw instalacyjnych,

Rysunek 2.8. Przykadowy diagram mapowania wygenerowany w HibernateTools

umoliwiajcy wygenerowanie modelu obiektowego na podstawie tabel i kolumn

Listing 2.9. Implementacje podstawowych operacji dostpnych w DAO

Pierwszych pi wymienionych typw moduw jest okrelonych w specyfikacji Java

2.3.2. Zastosowanie projektu uytkowego

New Project, w ktrym wywietli si lista typw projektw.

elementw grupy wybieramy opcj Utility Project i zatwierdzamy przyciskiem Next.