Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00072 006620 13598424 na godz. na dobę w sumie
JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW - książka
JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW - książka
Autor: Liczba stron: 384
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-2656-4 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> java - programowanie
Porównaj ceny (książka, ebook (-20%), audiobook).

Dobry interfejs aplikacji WWW to połowa jej sukcesu. Osiągnij go z JavaServer Faces! Język Java od lat zdobywa i ugruntowuje swoją popularność wśród programistów i twórców aplikacji WWW, a rozmaite platformy i rozwiązania, w których jest on wykorzystywany, zostały na stałe włączone do pakietu narzędzi stosowanych przez wielu z nich na co dzień. Jednym z najbardziej popularnych tego typu narzędzi jest JavaServer Faces. Można dzięki niemu w prosty sposób tworzyć interfejsy użytkownika aplikacji, wykorzystujące platformę Java EE. Ten spójny i kompletny szkielet programistyczny jest obecnie najbardziej elastycznym, najlepiej dopracowanym i najprostszym w użyciu rozwiązaniem, opartym na technologii serwletów.

Jednak 'najprostszy' wcale nie musi oznaczać 'prosty', o czym z pewnością miało okazję przekonać się wielu studentów kierunków informatycznych i profesjonalnych programistów, którzy postanowili praktycznie zapoznać się z możliwościami tej technologii. Nieocenioną pomocą okaże się dla nich książka 'JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW ', dzięki której można uniknąć wielu typowych błędów i nauczyć się biegle korzystać z JSF, zdobywając przy tym kompletną wiedzę na temat mechanizmów i rozwiązań zapewniających działanie tej platformy. Co więcej, opisano tu nie tylko samą technologię, lecz również sposób jej praktycznego wykorzystania w konkretnych projektach, co w przyszłości zaowocuje z pewnością opracowaniem niejednej doskonałej i cieszącej oko aplikacji WWW.

Naucz się szybko i sprawnie tworzyć rozbudowane interfejsy użytkownika aplikacji WWW za pomocą szkieletu programistycznego JavaServer Faces.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW Autor: Andrzej Marciniak ISBN: 978-83-246-2656-4 Format: 158×235, stron: 384 • Jak projektować estetyczne i wygodne interfejsy użytkownika aplikacji WWW? • Od czego zacząć projekt wykorzystujący JavaServer Faces? • Co oferuje środowisko Eclipse Galileo, a co narzędzia Web Tools Platform? Dobry interfejs aplikacji WWW to połowa jej sukcesu. Osiągnij go z JavaServer Faces! Język Java od lat zdobywa i ugruntowuje swoją popularność wśród programistów i twórców aplikacji WWW, a rozmaite platformy i rozwiązania, w których jest on wykorzystywany, zostały na stałe włączone do pakietu narzędzi stosowanych przez wielu z nich na co dzień. Jednym z najbardziej popularnych tego typu narzędzi jest JavaServer Faces. Można dzięki niemu w prosty sposób tworzyć interfejsy użytkownika aplikacji, wykorzystujące platformę Java EE. Ten spójny i kompletny szkielet programistyczny jest obecnie najbardziej elastycznym, najlepiej dopracowanym i najprostszym w użyciu rozwiązaniem, opartym na technologii serwletów. Jednak „najprostszy” wcale nie musi oznaczać „prosty”, o czym z pewnością miało okazję przekonać się wielu studentów kierunków informatycznych i profesjonalnych programistów, którzy postanowili praktycznie zapoznać się z możliwościami tej technologii. Nieocenioną pomocą okaże się dla nich książka „JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW”, dzięki której można uniknąć wielu typowych błędów i nauczyć się biegle korzystać z JSF, zdobywając przy tym kompletną wiedzę na temat mechanizmów i rozwiązań zapewniających działanie tej platformy. Co więcej, opisano tu nie tylko samą technologię, lecz również sposób jej praktycznego wykorzystania w konkretnych projektach, co w przyszłości zaowocuje z pewnością opracowaniem niejednej doskonałej i cieszącej oko aplikacji WWW. • Mechanizmy działania aplikacji WWW i sposoby ich projektowania w oparciu o język Java • Podstawowe informacje na temat szkieletu programistycznego JSF • Realizacja praktycznego projektu z wykorzystaniem JavaServer Faces • Rozszerzanie standardowej implementacji JSF i tworzenie niestandardowych interfejsów użytkownika • Opis środowiska programistycznego Eclipse Galileo oraz pakietu narzędzi Web Tools Platform Naucz się szybko i sprawnie tworzyć rozbudowane interfejsy użytkownika aplikacji WWW za pomocą szkieletu programistycznego JavaServer Faces Idź do • Spis treści • Przykładowy rozdział Katalog książek • Katalog online • Zamów drukowany katalog Twój koszyk • Dodaj do koszyka Cennik i informacje • Zamów informacje o nowościach • Zamów cennik Czytelnia • Fragmenty książek online Kontakt Helion SA ul. Kościuszki 1c 44-100 Gliwice tel. 32 230 98 63 e-mail: helion@helion.pl © Helion 1991–2010 Spis treĈci Wstöp .............................................................................................. 7 Geneza ksiąĪki .................................................................................................................. 7 Cele .................................................................................................................................. 9 Czytelnicy ....................................................................................................................... 10 Ukáad zagadnieĔ ............................................................................................................. 10 Materiaáy pomocnicze .................................................................................................... 11 PodziĊkowania ................................................................................................................ 12 Rozdziaä 1. Przed przystñpieniem 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 serwletów .................................................................... 40 1.3.2. Instalacja Ğrodowiska Eclipse Galileo .......................................................... 40 1.3.3. Integracja kontenera serwletów 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 wspierającego ................................................... 54 1.3.8. Utworzenie strony do wprowadzania danych ............................................... 56 1.3.9. Utworzenie strony do wyĞwietlania wyniku ................................................ 59 1.3.10. Deklarowanie reguá nawigacji .................................................................... 62 1.3.11. Uruchamianie aplikacji .............................................................................. 63 1.3.12. Podsumowanie przykáadu .......................................................................... 65 Rozdziaä 2. Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java EE ..................................................................... 67 2.1. Modelowanie interfejsu uĪytkownika przy wykorzystaniu techniki scenopisu ....... 68 2.1.1. Przypadki uĪycia .......................................................................................... 69 2.1.2. Model ekranów interfejsu uĪytkownika ....................................................... 70 2.1.3. Model nawigacji .......................................................................................... 72 2.1.4. Prototypy ekranów ....................................................................................... 73 2.1.5. Diagram maszyny stanowej ......................................................................... 75 4 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 trwaáoĞci danych ......................................................... 85 2.3. Organizacja kodu aplikacji w Eclipse ...................................................................... 95 2.3.1. Projekty i moduáy Java EE w Eclipse .......................................................... 95 2.3.2. Zastosowanie projektu uĪytkowego do przechowywania kodu warstwy biznesowej .......................................... 96 2.3.3. Moduáy zaleĪne ............................................................................................ 99 Rozdziaä 3. UĔywanie JSF ............................................................................... 101 3.1. Komponenty zarządzane ........................................................................................ 101 3.1.1. Deklaracja komponentu ............................................................................. 102 3.1.2. ZasiĊg komponentów ................................................................................. 105 3.1.3. Inicjalizacja wáaĞciwoĞci komponentów .................................................... 106 3.1.4. Odwoáania do komponentów zarządzanych ............................................... 113 3.1.5. Komponenty referowane ............................................................................ 115 3.1.6. Komponenty wspierające ........................................................................... 116 3.1.7. JĊzyk wyraĪeĔ UEL ................................................................................... 118 3.1.8. Konfiguracja komponentów i innych zasobów .......................................... 123 3.2. Obsáuga zdarzeĔ .................................................................................................... 127 3.2.1. Typy zdarzeĔ i metody ich obsáugi ............................................................ 127 3.2.2. Natychmiastowe wykonywanie metod obsáugi zdarzeĔ ............................. 136 3.2.3. Parametryzacja komponentów 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 niejednoznacznoĞci w reguáach .......................................... 144 3.3.4. Przekierowanie i nawigacja poza JSF ........................................................ 144 3.4. Przetwarzanie pakietów zasobów i internacjonalizacja ......................................... 146 3.4.1. Lokalizatory ............................................................................................... 147 3.4.2. Pakiety zasobów ........................................................................................ 150 3.4.3. Pakiety komunikatów ................................................................................. 154 3.4.4. Internacjonalizacja w warstwie biznesowej ............................................... 157 3.5. Konwersja .............................................................................................................. 159 3.5.1. Standardowe konwertery ............................................................................ 159 3.5.2. Obsáuga báĊdów konwersji ......................................................................... 162 3.6. Walidacja ............................................................................................................... 164 3.6.1. Implementacja metod walidacji ................................................................. 165 3.6.2. Standardowe walidatory ............................................................................. 168 3.6.3. Kombinowanie róĪnych walidatorów ........................................................ 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 obsáugi ĪądaĔ ......................................................................... 211 4.1.2. Standardowy cykl przetwarzania Īądania JSF ........................................... 214 4.1.3. Kolejka zdarzeĔ ......................................................................................... 225 4.1.4. Kolejka komunikatów ................................................................................ 228 4.2. Konfigurowanie i rozszerzanie standardowej implementacji ................................. 229 4.2.1. Infrastruktura aplikacji JSF ........................................................................ 229 4.2.2. Mechanizm nawigacji ................................................................................ 238 Spis treĈci 5 4.2.3. Mechanizm zarządzania widokami ............................................................ 238 4.2.4. Mechanizm zarządzania stanem ................................................................. 239 4.2.5. Mechanizm przetwarzania wyraĪeĔ EL ..................................................... 239 4.2.6. Mechanizm obsáugi akcji ........................................................................... 243 4.3. Model komponentów ............................................................................................. 243 4.3.1. Struktura klas ............................................................................................. 244 4.3.2. Identyfikatory komponentów ..................................................................... 251 4.4. Praktyczne zastosowania obiektów PhaseListener ................................................ 255 4.4.1. Wzorzec POST-Redirect-GET ................................................................... 256 4.4.2. Generowanie danych binarnych ................................................................. 258 4.5. ZáoĪone tabele ....................................................................................................... 260 4.5.1. Modele danych ........................................................................................... 260 4.5.2. Przykáad tabeli interaktywnej ..................................................................... 261 4.6. JSF i bezpieczeĔstwo ............................................................................................. 264 4.6.1. BezpieczeĔstwo zarządzane przez kontener ............................................... 265 4.6.2. BezpieczeĔstwo zarządzane przez aplikacjĊ .............................................. 270 Rozdziaä 5. Tworzenie komponentów uĔytkownika ........................................... 275 5.1. Komponenty interfejsu uĪytkownika (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 obsáuga zdarzeĔ ................................................................. 282 5.1.5. Integracja z JSP .......................................................................................... 284 5.2. Renderery .............................................................................................................. 289 5.2.1. Podstawy implementacji rendererów ......................................................... 290 5.2.2. Renderery i JavaScript ............................................................................... 291 5.2.3. Rejestracja rendererów ............................................................................... 295 5.3. Konwertery ............................................................................................................ 296 5.3.1. Podstawy implementacji konwerterów ...................................................... 297 5.3.2. Rejestracja konwerterów ............................................................................ 300 5.3.3. Integracja konwerterów z JSP .................................................................... 302 5.4. Walidatory ............................................................................................................. 304 5.4.1. Podstawy implementacji walidatorów ....................................................... 305 5.4.2. Rejestracja walidatorów ............................................................................. 306 5.4.3. Integracja walidatorów 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. Narzödzia wsparcia i integracja z innymi szkieletami ..................... 327 6.1. NarzĊdzia Web Tools Platform .............................................................................. 327 6.1.1. Zarządzanie serwerem aplikacji ................................................................. 328 6.1.2. Monitorowanie portów ............................................................................... 330 6.1.3. NarzĊdzia uáatwiające 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 6 JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW Dodatek A Standardy kodowania IANA ........................................................... 353 Dodatek B ZaäoĔenia JSF 2.0 ......................................................................... 355 Dodatek C Wspólne elementy konfiguracji ..................................................... 357 Dodatek D Komunikaty o bäödach .................................................................. 359 Komunikaty o báĊdach komponentów .......................................................................... 359 Komunikaty o báĊdach konwerterów ............................................................................ 359 Komunikaty o báĊdach walidatorów ............................................................................. 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 wiadomoĞciami na temat architektury i moĪliwo- Ğci szkieletu JSF moĪemy przejĞü do zagadnieĔ związanych z wytwarzaniem realnych aplikacji WWW w Ğrodowisku programistycznym Eclipse Galileo. W niniejszym rozdziale wybrane fazy wytwarzania aplikacji są zilustrowane na przykáadzie Inter- netowego Systemu Recenzowania Publikacji (w skrócie ISRP), przeznaczonego do zapewnienia obsáugi informatycznej pracy redakcji czasopism naukowych oraz wspomagania organizacji konferencji naukowych. Zakres funkcjonalnoĞci projekto- wanego systemu obejmuje obsáugĊ rejestracji artykuáów zgáaszanych przez autorów, proces recenzji artykuáów oraz administrowanie kontami uĪytkowników. Nie jest intencją autora zamieszczenie w tym miejscu peánej dokumentacji systemu ISRP jako záoĪonego studium przypadku uĪycia JSF (ang. case study), ale raczej przedsta- wienie pewnych praktyk projektowych związanych z architekturą i projektowaniem aplikacji JSF na platformie Java EE. Prezentowane rozwiązania są wypadkową do- ĞwiadczeĔ wielu osób w zakresie wykorzystania szkieletu JSF do wytwarzania war- stwy prezentacji w aplikacjach o architekturze wielowarstwowej. Szczególna uwaga poĞwiĊcona jest wybranym aspektom związanym z czynnoĞciami fazy przedimple- mentacyjnej projektu, takim jak modelowanie interfejsu uĪytkownika oraz projekto- wanie aplikacji oparte na architekturze wielowarstwowej. Zamieszczone w tym rozdziale model i zaáoĪenia projektowe bĊdą rozwijane w dalszej czĊĞci ksiąĪki i stanowiü jed- noczeĞnie odniesienie dla kolejnych przykáadów ilustrujących elementy technologii JSF. 68 JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW 2.1. Modelowanie interfejsu uĔytkownika przy wykorzystaniu techniki scenopisu JakoĞü modelu projektowanego systemu czĊsto decyduje o powodzeniu projektu in- formatycznego, a jego najbardziej poĪądaną cechą jest kompromisowoĞü. Model po- winien byü jednoczeĞnie zrozumiaáy dla klientów, którzy na jego podstawie oceniają funkcjonalnoĞü systemu, jak teĪ zawieraü wszystkie niezbĊdne dane dla zespoáu pro- jektowego, który z niego korzysta w fazie projektowania. Z jednej strony model powinien byü dopasowany do technologii stosowanych w fazach projektowania i implementacji (przy zaáoĪeniu, Īe są one znane wczeĞniej i wynikają np. z wymagaĔ niefunkcjonal- nych), a jednoczeĞnie nie powinien wymagaü rozlegáej wiedzy na ich temat od ana- lityków wytwarzających model. Ze wzglĊdu na komponentowy charakter szkieletu JSF, scenopis wydaje siĊ techniką modelowania, która doskonale speánia opisane wyĪej kryteria. Scenopis specyfikuje model zawierający analizĊ funkcjonalną, komponenty funkcjonalne oraz interakcje pomiĊdzy nimi na ekranach oraz przepáywy i projekty ekranów. NajwiĊkszą zaletą scenopisu jest to, Īe jest on zrozumiaáy dla osób spoza branĪy informatycznej, co za- pewniają diagramy przypadków uĪycia i prototypy ekranów. W dalszej czĊĞci roz- dziaáu zaprezentowane zostaną poszczególne elementy scenopisu, ilustrowane wybra- nymi fragmentami modelu aplikacji ISRP. Scenopis i metodyki modelowania, projektowania i dokumentowania systemów informatycznych Metodyki wytwarzania systemów informatycznych stanowią jeden z gáównych nur- tów inĪynierii oprogramowania. Obecnie standardowym narzĊdziem do modelowania systemów informatycznych jest jĊzyk UML w wersji 2.1, który stanowi jednoczeĞnie system wizualizacji, specyfikowania oraz dokumentowania elementów systemu in- formatycznego. UML jest uĪywany wraz z jego reprezentacją graficzną — jego ele- mentom przypisane są symbole, które wiązane są ze sobą na diagramach. Ze wzglĊdu na to Īe UML zostaá stworzony z myĞlą o opisie Ğwiata w analizie obiektowej, jego specyfikacja nie definiuje gotowych rozwiązaĔ dla specyficznych zastosowaĔ, takich jak modelowanie interfejsu uĪytkownika. PoniewaĪ nie powstaá zunifikowany stan- dard dla modelowania zachowania i struktury aplikacji WWW, np. w zakresie mode- lowania nawigacji, przepáywów sterowania na ekranach czy projektów ekranów, róĪ- ne organizacje i firmy forsują wáasne rozszerzenia jĊzyka UML w tym zakresie. Opierając siĊ na UML, stworzono metodykĊ projektowania oprogramowania RUP (Rational Unified Process), która definiuje szablon procesu iteracyjnego wytwarzania oprogramowania opracowany przez firmĊ Rational Software Corporation. Szablon RUP pozwala na korzystanie z jego elementów w zaleĪnoĞci od potrzeb projektowych. SpoĞród najlepszych praktyk i zasad inĪynierii oprogramowania, które są w nim za- warte, 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 zarządzanie wymaganiami (ang. Requirement Management), uĪywanie archi- tektury bazującej na komponentach (ang. Component-based Architecture) czy gra- ficzne projektowanie oprogramowania. Scenopis (ang. storyboard) jest modelem projektowym, zwykle tworzonym przez analityków biznesowych i projektantów interfejsu uĪytkownika, dostarczonym ze- spoáowi deweloperów jako czĊĞü specyfikacji funkcjonalnej. Idea scenopisu wywodzi siĊ z przedstawionej wyĪej metodyki RUP, która definiuje m.in. model projektowania interakcji oparty na doĞwiadczeniu uĪytkownika (ang. User-eXperience — UX) w po- staci ekranów, ich dynamicznej zawartoĞci i sposobu nawigacji. Typowy scenopis zawiera piĊü elementów:  przypadki uĪycia opisujące wymagania funkcjonalne i przepáywy zdarzeĔ,  model ekranów UI specyfikujący ekrany, komponenty i elementy UX,  diagram nawigacji ilustrujący związki pomiĊdzy ekranami (przede wszystkim reguáy nawigacji), oparty na notacji graficznej diagramu klas,  makiety ekranów (ang. mock-up) pokazujące szczegóáowo elementy funkcjonalne interfejsu GUI, tj. kontrolki i ich rozmieszczenie,  diagramy maszyny stanowej dla kaĪdego ekranu ilustrujące interakcjĊ warstwy kontrolera ekranu z warstwą modelu aplikacji. 2.1.1. Przypadki uĔycia Wygodnym narzĊdziem stosowanym na potrzeby identyfikacji i dokumentacji wyma- gaĔ funkcjonalnych są diagramy przypadków uĪycia (ang. Use Case — UC) w jĊzy- ku UML. Ilustrują one funkcjonalnoĞü systemu poprzez wyszczególnienie i przedsta- wienie za pomocą symboli graficznych: aktorów inicjujących dziaáania, przypadków uĪycia systemu oraz wystĊpujących pomiĊdzy nimi związków. DziĊki swojej prosto- cie oraz abstrahowaniu od rozwiązaĔ technicznych, diagramy przypadków uĪycia są zrozumiaáe nawet dla osób, które nie posiadają wyksztaácenia informatycznego. Z zaáo- Īenia stanowią one czytelne narzĊdzie pozwalające na komunikacjĊ pomiĊdzy twórcami systemu i jego potencjalnymi odbiorcami czy inwestorami. Podsumowując, przypadki uĪycia opisują, co system powinien robiü, a nie jak ma to robiü. Na rysunku 2.1 przedstawiono diagram przypadków uĪycia modelujący aktorów, przy- padki uĪycia oraz powiązania pomiĊdzy nimi, wystĊpujące w systemie ISRP. Sche- matyczny rysunek postaci ludzkiej záoĪony z kilku kresek jest symbolem graficznym aktora, definiującego spójny zbiór ról odgrywanych przez uĪytkowników przypadku uĪycia w czasie jego realizacji. Przypadki uĪycia oznaczone są przy wykorzystaniu wypeánionych elips, a ich realizacje zwykáymi liniami. Relacje rozszerzania i zawie- rania dla przypadków uĪycia opisane są przy zastosowaniu stereotypów umieszczo- nych w cudzysáowach ostrokątnych. Relacje uogólniania (w sensie związku taksono- micznego, opisującego dziedziczenie cech) przedstawione zostaáy za pomocą linii zakoĔczonych strzaáką z pustym grotem. 70 JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW Zaloguj Odzyskaj hasáo WyĞwietl szczegóáy recenzji Edytuj dane osobowe UĪytkownik uwierzytelniony (from Actors) Recenzent (from Actors) WyĞwietl listĊ recenzji PokaĪ szczegóáy pracy WyĞwietl listĊ prac «include» Autor (from Actors) Dodaj pracĊ «extend» Edytuj pracĊ Zarejestruj Dodaj recenzjĊ Zarządzaj pracami Przypisz recenzenta do pracy Dodaj recenzenta Administrator (from Actors) Zarządzaj uĪytkownikami «include» WyĞwietl listĊ uĪytkowników Rysunek 2.1. Diagram przypadków uĪycia dla ISRP Dokáadny opis wykorzystania diagramów UC do modelowania funkcjonalnoĞci sys- temu Czytelnik znajdzie w ksiąĪce JĊzyk UML 2.0 w modelowaniu systemów infor- matycznych, a wyczerpujący opis scenariuszy przypadków uĪycia (tekstowej formy prezentacji UC) znajduje siĊ w ksiąĪce Writing Effective Use Cases1. 2.1.2. Model ekranów interfejsu uĔytkownika Model ekranów UI stanowi centralny punkt wyjĞciowy dla równolegáego rozwoju apli- kacji, prowadzonego w zespoáach projektantów stron WWW i programistów aplikacji, stanowiąc jednoczeĞnie interfejs umoĪliwiający integracjĊ kodu wytwarzanego przez 1 Polskie wydanie: Alistair Cockburn, Jak pisaü efektywne przypadki uĪycia, táum. Krzysztof Stencel, Warszawa 2004. Rozdziaä 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java 71 oba zespoáy. Model ekranów UI definiuje zbiór ekranów (wraz z ich zawartoĞcią) nie- zbĊdnych do zrealizowania wymagaĔ funkcjonalnych okreĞlonych przez przypadki uĪycia. W przypadku zawartoĞci ekranów model definiuje wyáącznie elementy funk- cjonalne, jakie powinny znaleĨü siĊ na nich, bez okreĞlania szczegóáów dotyczących typów kontrolek (np. pola tekstowego albo listy rozwijanej) czy ich rozmieszczenia. W technice scenopisów standardowym elementom UML nadawane są nowe znaczenia poprzez uĪycie stereotypów przedstawionych w tabeli 2.1. Tabela 2.1. Stereotypy modelu UI wykorzystywane w technice scenopisów Stereotyp Screen Rozszerzany element UML Class Compartment Class Form Input Submit Class Attribute Operation Reprezentuje Ekran (w postaci strony WWW). Fragment ekranu (strony WWW) przeznaczony do wykorzystania na wielu stronach aplikacji WWW (definiujący sekcjĊ strony np. stopkĊ, nagáówek itp.). Formularz strony WWW. Pole wejĞciowe formularza. Element zatwierdzający formularz i generujący akcjĊ. Statyczne informacje takie jak etykiety, obrazki czy panele nie są w ogóle reprezen- towane w modelu UI. Dane biznesowe są przedstawiane na ekranie przy uĪyciu atry- butów. JeĞli atrybut opatrzony jest stereotypem input , oznacza to, Īe sáuĪy on do wprowadzania danych. Peány opis atrybutu prezentowany jest wedáug nastĊpującego formatu: widocznoħè nazwa :typ liczebnoħè =domyħlna_wartoħè {wđaħciwoħci}. ZaáóĪ- my, Īe mamy ekran sáuĪący do tworzenia konta nowego uĪytkownika, dostĊpny wy- áącznie dla administratora systemu. Pole sáuĪące do wprowadzania uprawnieĔ dla no- wego uĪytkownika moĪe zostaü opisane w nastĊpujący sposób: input +role :String 1 =reviewer {user.role==admin} PowyĪszy zapis informuje nas, Īe atrybut role reprezentuje pole wejĞciowe dla da- nych typu String, wypeániane przez uĪytkowników z uprawnieniami administratora. WidocznoĞü elementu okreĞla, czy jego zawartoĞü jest wyĞwietlana na ekranie (+), czy teĪ jest ukryta (-). Nazwa atrybutu powinna identyfikowaü pole wprowadzania danych (np. wartoĞü atrybutu name dla odpowiedniego pola formularza). Typem atrybutu mo- Īe byü dowolny typ prymitywny lub obiektowy, wáącznie z abstrakcyjnymi typami danych, reprezentującymi záoĪone struktury danych (takie jak listy czy mapy, które mogą byü reprezentowane przez klasy abstrakcyjne List bądĨ Map). Pozostaáe wáaĞci- woĞci atrybutu są opcjonalne i nie muszą byü definiowane. LiczebnoĞü okreĞla, ile in- stancji elementu moĪe byü renderowanych na ekranie, wartoĞü domyĞlna jest wartoĞcią uĪywaną dla elementów, które nie są inicjowane, a nawiasy klamrowe umoĪliwiają zamieszczenie dodatkowych wáaĞciwoĞci bądĨ ograniczeĔ dotyczących atrybutu, np. w zakresie dostĊpu do pola danych. Zdarzenia generowane przez interfejs uĪytkownika oraz akcje uĪytkownika reprezen- towane są za pomocą operacji. JeĞli operacja jest dodatkowo opatrzona stereotypem submit , oznacza to, Īe wskazany element UI sáuĪy do zatwierdzania formularza 72 JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW i generowania akcji, której wynik moĪe wpáywaü na nawigacjĊ aplikacji. Peány opis ope- racji prezentowany jest wedáug nastĊpującego formatu: widocznoħè nazwa (lista_ parametrów) :zwracany_typ {wđaħciwoħci}. Na przykáad element wyzwalający akcjĊ polegającą na przejĞciu do okna edycji bieĪącego uĪytkownika moĪe byü opisany w na- stĊpujący sposób: submit + edit ():String {current.user==notEmpty} Nazwa operacji powinna byü powiązana z nazwą metody sáuĪącej do obsáugi zdarze- nia wygenerowanego przez operacjĊ lub nazwą powiązanego z operacją pola (np. gdy operacja dotyczy walidacji danych wprowadzanych do pola wejĞciowego po stronie klienta). WidocznoĞü elementu okreĞla, czy akcja ma byü podjĊta po stronie klienta (-), czy po stronie serwera (+). WáaĞciwoĞci dodatkowo charakteryzujące operacje za- mieszczane są w opcjonalnych nawiasach klamrowych. Na rysunku 2.2 zaprezentowano model ekranu realizującego dwa przypadki uĪycia systemu ISRP — rejestracjĊ nowego uĪytkownika i edycjĊ danych uĪytkownika uwie- rzytelnionego. Obie funkcjonalnoĞci systemu są doĞü podobne i operują na jednym zbiorze danych, wiĊc do ich obsáugi zamodelowany zostaá jeden ekran. Ekran skáada siĊ z trzech czĊĞci: nagáówka (topMenu) zawierającego przyciski nawigacji, menu dla uwierzytelnionych uĪytkowników (leftMenu) i formularza danych uĪytkownika. W przy- padku rejestracji nowego uĪytkownika elementy menu leftMenu oraz przycisk zapi- sywania 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 scenopisów diagramy nawigacji nie koncentrują siĊ na konkretnym prze- páywie zdarzeĔ, ale pokazują związki pomiĊdzy ekranami. Model nawigacji zawiera graficzną ilustracjĊ przepáywów nawigacji dla wszystkich przypadków uĪycia. Prze- páywy nawigacji dla poszczególnych przypadków mogą byü prezentowane na od- dzielnych diagramach bądĨ jednym diagramie zbiorczym, jak pokazano na rysunku 2.3. Jak moĪna zauwaĪyü, przedstawiony diagram nawigacji jest bardziej szczegóáowy niĪ opisana w rozdziale 1. graficzna reprezentacja reguá nawigacji w Eclipse WTP. Niemniej podczas tworzenia diagramu moĪna wykorzystaü gotowe obiekty ekranów, stanowiące zawartoĞü utworzonego wczeĞniej modelu ekranów interfejsu uĪytkownika. WystĊpujące na diagramie asocjacje skierowane wskazują kierunek przepáywu stero- wania pomiĊdzy dwoma ekranami. W szczególnych przypadkach asocjacje mogą byü wyprowadzane do formularza ( form ), ale zawsze miejscem docelowym jest ekran. KaĪda asocjacja powinna posiadaü powiązaną z docelowym ekranem unikatową na- zwĊ, która bĊdzie mogáa zostaü wykorzystana podczas definiowania reguá nawigacji JSF (jako wartoĞü elementu from-outcome ). Rozdziaä 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java 73 «screen» addEditUser + globalMessage: String [0..*] «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 «submit» + save {currentUser==notEmpty}() : String + registration {currentUser==empty}() : String «compartment» includes::leftMenu «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 + + usersList {user.role==admin}() : String reviewersPapersList {user.role==reviewer}() : String «compartment» includes::topMenu + userName {user==authorized}: String + english() : void + polish() : void «submit» + + + login {user==notAuthorized}() : String logout {user==authorized}() : String registration {user==notAuthorized}() : String Rysunek 2.2. Model ekranu rejestracji i edycji danych uĪytkownika 2.1.4. Prototypy ekranów Zrozumiaáy, ergonomiczny i przejrzysty interfejs uĪytkownika jest jednym z kluczo- wych czynników decydujących o sukcesie aplikacji WWW. Konsultowanie wyglądu interfejsu przez potencjalnych uĪytkowników systemu w fazie przedimplementacyjnej lub w trakcie implementacji pozwala ten sukces osiągnąü. Celem przeanalizowania preferencji uĪytkowników w zakresie funkcjonalnoĞci interfejsu stosuje siĊ tzw. pro- totypowanie, polegające na wytwarzaniu makiet ekranów (ang. mock-up). PojĊcie makiety jest maáo precyzyjne i charakteryzuje wszelkie projekty ekranów, począwszy od odrĊcznych szkiców, poprzez projekty szkieletowe ekranu (ang. wireframes), aĪ po gotowe interaktywne prototypy ekranów posiadające bogatą szatĊ graficzną i umoĪli- wiające testowanie ekranu na faászywych danych. Projekty szkieletowe nie uwzglĊd- niają szaty graficznej, a ich celem jest przedstawienie ogólnej funkcjonalnoĞci poszcze- gólnych ekranów oraz sposobu prezentacji danych biznesowych. 74 «screen» assignReviewer {user.role==admin} + paper.title: String «input» + reviewers: select «submit» + assign() : String JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW «screen» forgotPassword + globalMessage: String [0..*] «input» + email: text «submit» + getNewPassword() : String «screen» login forgot_password + globalMessage: String [0..*] «submit» + + notRegistered() : String forgotPassword() : String login_success login registration aprove/reject assign_reviewer assign_success «screen» papersList {user.role==admin} + globalMessages: String [0..*] delete get_password_success logout_success «screen» index «compartment» :topMenu registration + welcomeMessage: String registration_success all_papers_list «screen» addEditUser + globalMessage: String [0..*] paper_details «screen» addReview {user.role==reviewer} + globalMessages: String [0..*] «compartment» :leftMenu add_user edit_user add_success edit_success «screen» paperDetails + paper.abstract: String + paper.acronym: String + paper.authors: String + paper.title: String «submit» + downloadFile() : void review_details add_success add_review reviewer_papers_list author_papers_list papers_details «screen» reviewerPaperList + globalMessages: Strin [0..*] review_details paper_details «screen» auhtorPaperList {user.role==author} + globalMessages: String [0..*] all_users_list «screen» usersList {user.role==admin} + globalMessages: String [0..*] delete «screen» reviewDetails + review.commentToAdmin {user.role==admin || user.role==reviewer}: String + review.commentToAuthor {user.role==author || user.role==reviewer}: String + review.grade: String review_details add_new_version add_success edit_paper add_paper «screen» addNewVersion {user.role==author} edit_success add_success «screen» addEditPaper {user.role==author} «input» + paper.file: file «submit» + addNewVersion() : String Rysunek 2.3. Diagram nawigacji dla aplikacji ISRP W technice scenopisów generalnie zaleca siĊ stosowanie projektów szkieletowych, które mogą byü wytwarzane zarówno odrĊcznie, z wykorzystaniem narzĊdzi graficznych (doĞü popularny jest pakiet MS PowerPoint), jak i za pomocą specjalnych narzĊdzi dostĊpnych w pakietach do modelowania, np. Microsoft Visio Toolkit for Wireframe, MockupScreens czy Screen Architect for Sparx Enterprise Architect. W Ğrodowisku Eclipse warto rozwaĪyü wykorzystanie edytora stron WWW pakietu WTP — utworzo- ne w ten sposób projekty mogą byü póĨniej stosowane podczas implementacji. Rozdziaä 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java 75 Przykáad projektu szkieletowego dla ekranu rejestracji uĪytkownika w systemie ISRP zostaá pokazany na rysunku 2.4. Projekt stanowi rozwiniĊcie modelu ekranu zamiesz- czonego na rysunku 2.2 zarówno w zakresie specyfikacji kontrolek realizujących ele- menty funkcjonalne, jak i rozmieszczenia elementów wizualnych, mających uáatwiü korzystanie ze strony. Rysunek 2.4. Projekt szkieletowy ekranu rejestracji aplikacji ISRP 2.1.5. Diagram maszyny stanowej W technice scenopisów diagram maszyny stanowej sáuĪy do opisania zachowania ekra- nu w trakcie realizacji przypadku uĪycia. Diagram modeluje stan znajdującego siĊ po stronie serwera kontrolera ekranu oraz jego zmiany nastĊpujące w wyniku interakcji uĪytkownika z ekranem. Na rysunku 2.5 zamieszczony zostaá przykáad diagramu ma- szyny stanowej, ilustrujący zmiany stanów kontrolera ekranu rejestracji (przedstawio- nego na rysunku 2.4). 76 JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW «ControllerState» Rejestracja nieaktywna start + entry / dezaktywuj przycisk Zarejestruj wyjĞcie po klikniĊciu przycisku nawigacji Final zaznaczenie pola wyboru [pole=true] zaznaczenie pola wyboru [pole=false] zatwierdzenie formularza [walidacja poprawna] /dodaj uĪytkownika «ControllerState» Rejestracja aktywna + entry / uaktywnij przycisk Zarejestruj + exit / waliduj dane formularza zatwierdzenie formularza [walidacja niepoprawna] /pokaĪ báĊdy Rysunek 2.5. Diagram maszyny stanowej dla ekranu rejestracji Stan początkowy reprezentuje stan kontrolera po utworzeniu jego instancji i jest oznaczony przez strzaákĊ wychodzącą od elementu start. KaĪde przejĞcie (tranzycja) na diagramie definiuje relacjĊ miĊdzy dwoma stanami kontrolera, wskazującą, Īe kontro- ler znajdujący siĊ w pierwszym stanie wykona pewne akcje i przejdzie do drugiego stanu, ilekroü zajdzie okreĞlone zdarzenie i bĊdą speánione okreĞlone warunki. Opis przejĞcia skáada siĊ z trzech opcjonalnych elementów: wyzwalacza (ang. trigger), dozoru (ang. guard) i aktywnoĞci (ang. activity), które opisywane są wedáug nastĊpującej skáadni: wyzwalacz [dozór] /aktywnoħè. Wyzwalaczem jest zazwyczaj pojedyncze zdarzenie, które moĪe spowodowaü przejĞcie i zmianĊ stanu. Dozór okreĞla warunek logiczny, jaki musi byü speániony, aby przejĞcie zostaáo wykonane; warunek ten jest obliczany w momencie pojawienia siĊ wyzwalacza. AktywnoĞü definiuje operacjĊ wykonywaną w momencie przejĞcia ze stanu do stanu; nawet jeĪeli akcja przejĞcia jest záoĪona z wielu akcji elementarnych, jest ona wykonywana niepodzielnie. PrzejĞcia są oznaczane za pomocą strzaáek áączących dwa stany kontrolera i mogą byü postrzegane jako zmiany na ekranie, które nie powodują uaktywnienia reguá nawiga- cji skutkujących wyĞwietleniem innego ekranu. Podobnie jak w zwykáym diagramie maszyny stanowej, równieĪ tutaj mogą wystĊpowaü szczególne przypadki przejĞü, których wykonanie nie prowadzi do zmiany danego stanu, tj. przejĞcia wewnĊtrzne lub zwrotne. W przypadku przejĞcia zwrotnego są wykonywane czynnoĞci wejĞciowe oraz wyjĞciowe danego stanu, w przypadku przejĞü wewnĊtrznych są one pomijane. Rozdziaä 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java 77 PrzejĞcia wewnĊtrzne nie mają odrĊbnego oznaczenia graficznego, lecz są specyfiko- wane w obszarze stanu, obok definicji nastĊpujących czynnoĞci:  entry — czynnoĞci wykonywane w momencie, gdy obiekt przyjmuje dany stan;  do — czynnoĞci wykonywane nieprzerwanie w czasie, gdy obiekt przebywa w danym stanie;  exit — czynnoĞci wykonywane w momencie opuszczenia stanu. PrzejĞcia wewnĊtrzne lub zwrotne wystĊpują w sytuacjach, gdy kompozycja ekranu zmienia siĊ tylko nieznacznie lub wcale. Stan koĔcowy (ang. final) wskazuje, Īe maszyna stanów jest kompletna, a obiekt kontrolera oraz wszystkie przechowywane w nim zmien- ne mogą zostaü usuniĊte. 2.2. Warstwa biznesowa W rozdziale 1.2.4, „Implementacja MVC w JSF”, przedstawiono ogólny schemat im- plementacji wzorca MVC w aplikacjach opartych na JSF oraz korzyĞci páynące z izolo- wania warstwy biznesowej i prezentacji. W tym punkcie zostaną omówione dobre praktyki projektowe, rozwiązania i technologie związane z tworzeniem samej warstwy biznesowej. 2.2.1. Rola i elementy warstwy biznesowej PojĊcie warstwy biznesowej doĞü sugestywnie okreĞla rolĊ tej warstwy, w której mo- delowane są obiekty i reguáy biznesowe. Stanowi ona zazwyczaj rdzeĔ aplikacji i jest najbardziej rozlegáą jej warstwą, z jednej strony Ğwiadcząc usáugi dla warstwy pre- zentacji, z drugiej strony korzystając z zewnĊtrznych Ĩródeá danych, takich jak bazy danych, korporacyjne systemy informacyjne (ang. Enterprise Information Systems — EIS) czy zewnĊtrzne systemy informatyczne. Separowanie warstwy biznesu od prezen- tacji uáatwia implementacjĊ reguá biznesowych i umoĪliwia uĪycie obiektów bizneso- wych w dowolnym Ğrodowisku uruchomieniowym (strona 29 „KorzyĞci wynikające z izolowania warstw widoku i logiki biznesowej”). Ze wzglĊdu na rozlegáoĞü warstwy biznesowej dobrze jest podzieliü ją na podwarstwy, które są od siebie logicznie od- dzielone i posiadają ĞciĞle zdefiniowane zakresy odpowiedzialnoĞci, tj. model dzie- dzinowy, warstwĊ usáug i interfejs do warstwy trwaáoĞci danych (patrz rysunek 2.6), omówione w kolejnych punktach. Najpopularniejsze podejĞcia do tworzenia warstwy biznesowej w aplikacjach WWW oparte są na wykorzystaniu:  zarządzanych przez kontener komponentów,  zwykáych obiektów Javy (ang. Plain Old Java Objects — POJO). 78 JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW Rysunek 2.6. Warstwowy model architektury wykorzystany w aplikacji ISRP Warstwa prezentacji Warstwa biznesowa Warstwa usáugowa (fasady) Model dziedzinowy (POJO) Interfejs do warstwy trwaáoĞci (DAO) Warstwa trwaáoĞci Programowanie komponentowe jest naturalnym rozszerzeniem programowania zo- rientowanego obiektowo — nie posiada ono zupeánie nowych atrybutów w stosunku do programowania obiektowego, a jedynie konsekwentnie i w peáni wykorzystuje ce- chy obiektowoĞci. Komponenty oferują hermetycznie opakowane, wysokopoziomowe funkcje realizujące logikĊ biznesową. Zarządzaniem komponentami zajmuje siĊ kon- tener, który kontroluje róĪne aspekty ich Īycia, m.in. tworzenie instancji, wprowadza- nie zaleĪnoĞci pomiĊdzy nimi czy teĪ zarządzanie cyklem ich Īycia. Kontener po- zwala na ograniczenie zadaĔ stojących przed komponentami do realizacji jedynie funkcji biznesowych, dziĊki czemu są one áatwe do zrozumienia, mają czytelne inter- fejsy i mogą byü rozproszone w sieci. Programowanie komponentowe boryka siĊ jednak z wieloma problemami implementacyjnymi, przede wszystkim z duĪą róĪnorodnoĞcią protokoáów komponentowych i jĊzyków interfejsów, problemami ze wzajemnym poro- zumiewaniem siĊ komponentów czy záoĪonoĞcią infrastruktur Ğrodowisk uruchomienio- wych. Popularnymi technologiami komponentów są Enterprise Java Beans czy Spring. Do implementacji warstwy biznesowej w zawartych w ksiąĪce przykáadach wykorzy- stywane jest podejĞcie oparte na klasach POJO. Zaletą tego podejĞcia jest brak zaleĪ- noĞci od technologii EJB czy Java EE oraz moĪliwoĞü uĪycia i testowania jej kodu bez potrzeby korzystania ze Ğrodowiska uruchomieniowego serwera. Klasy POJO i komponenty JavaBean Termin Plain Old Java Objects okreĞla obiekty zwykáych klas Javy, które nie są ograniczone Īadnymi specjalnymi restrykcjami i nie muszą implementowaü Īadnych specjalnych zachowaĔ w odróĪnieniu od np. komponentów EJB 2.x. Klasy POJO nie powinny dziedziczyü po wczeĞniej predefiniowanych klasach, implementowaü predefi- niowanych interfejsów czy zawieraü predefiniowanych adnotacji, jeĞli te nie są związane z ich podstawową funkcjonalnoĞcią (choü nawet tych wymagaĔ nie naleĪy traktowaü zbyt rygorystycznie). PojĊcie POJO zostaáo wprowadzone przez Martina Fowlera, RebeccĊ Parsons i Josha McKenziego w 2000 roku, którzy poprzez wprowadzenie atrakcyjnie brzmiącej nazwy dla zwykáych obiektów Javy chcieli wyróĪniü ideĊ wy- korzystania prostych technik projektowych w programowaniu obiektowym. Rozdziaä 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java 79 PoniewaĪ w aplikacjach korporacyjnych Java EE (J2EE) wymagane są dodatkowe usáugi, takie jak zarządzanie transakcjami, utrzymywanie bezpieczeĔstwa czy trwaáo- Ğci danych (w alternatywnym podejĞciu usáugi te zapewniają kontenery EJB), po- wstaáy specjalne lekkie szkielety programistyczne (ang. lightweight frameworks), udo- stĊpniające wybrane usáugi obiektom POJO. Przykáadami lekkich szkieletów są Spring, Hibernate czy iBatis. Pozytywne doĞwiadczenia ze stosowania lekkich szkieletów i klas POJO skáoniáy równieĪ projektantów technologii EJB do gruntownej przebudowy ich rozwiązania. Począwszy od wersji EJB 3.0, komponenty EJB są w zasadzie klasami POJO, które zawierają adnotacje specyfikujące dodatkowe wáaĞciwoĞci obiektów tych klas (poza kontenerem EJB adnotacje nie są interpretowane, wiĊc moĪna stwierdziü, Īe EJB 3.0 to POJO). Komponenty JavaBean są to napisane w odpowiedniej konwencji klasy POJO, bĊdące niezaleĪnymi moduáami wielokrotnego uĪytku w programach Javy. NarzĊdzia do tworzenia oprogramowania są w stanie áączyü i wykorzystywaü komponenty JavaBeans oraz manipulowaü nimi dziĊki przyjĊciu odpowiednich konwencji w nazywaniu me- tod, konstrukcji klasy i jej zachowania, a mianowicie:  klasa musi posiadaü publiczny i bezparametrowy konstruktor;  hermetyzowane wáaĞciwoĞci klasy muszą byü dostĊpne do odczytu i modyfikacji za pomocą specjalnych metod publicznych (tzw. getters setters), które muszą mieü odpowiednio skonstruowane nazwy, zawierające przedrostki get-, set- i opcjonalnie is- dla typu boolean, np.: public int getTemperature(), public void setTemperature(int t), public boolean isFinished() — dla wáaĞciwoĞci temperature i finished;  klasa powinna byü serializowalna (implementowaü interfejs Serializable lub Externalizable);  klasa nie powinna zawieraü metod obsáugi zdarzeĔ. Przykáadowymi komponentami JavaBean są komponenty wspierające. 2.2.1.1. Model dziedzinowy Na podstawie analizy przypadków uĪycia moĪemy zidentyfikowaü podstawowe klasy konceptualne (pojĊcia, rzeczy bądĨ obiekty) wystĊpujące w projektowanym systemie. Model konceptualny stanowi punkt wyjĞciowy generowania obiektowego modelu dziedzinowego oraz modelu relacyjnego (fizycznego). Diagram konceptualny na rysunku 2.7 przedstawia podstawowe pojĊcia wystĊpujące w systemie ISRP. Dokáadne odwzorowanie obiektowe koncepcji biznesowych wystĊpujących w mode- lowanym Ğrodowisku zapewnia tzw. model drobnoziarnisty (ang. fine-grained model), oparty na wykorzystaniu wielu prostych obiektów POJO, reprezentujących istotne koncepcje biznesowe. Modele drobnoziarniste znakomicie speániają swoje funkcje, o ile nie wystĊpuje potrzeba rozproszenia obiektów na róĪnych serwerach. W modelu drobno- ziarnistym wystĊpuje mnóstwo wzajemnych odwoáaĔ pomiĊdzy obiektami, co stanowi problem w systemach rozproszonych, gdyĪ zdalne wywoáania są doĞü kosztowne. 80 JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW java.io.Serializable UĪytkownik wykonuje java.io.Serializable Recenzja mieszka nadsyáa java.io.Serializable Kraj java.io.Serializable Artykuá java.io.Serializable Pytanie java.io.Serializable OdpowiedĨ Rysunek 2.7. Diagram konceptualny systemu ISRP W takich systemach podejĞcie komponentowe moĪe byü przydatniejsze, a kontenery Java EE mogą dodatkowo zapewniü bezpieczeĔstwo, transakcyjnoĞü czy poáączenia w systemach heterogenicznych. Model dziedzinowy aplikacji ISRP zaimplementowany jest w postaci klas POJO. Przykáad obiektu biznesowego dla koncepcji uĪytkownika zostaá przedstawiony na li- stingu 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) { Rozdziaä 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java 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;} /* ...Pozostaáe gettery i settery ...*/ } PodejĈcie polegajñce na wyprowadzeniu implementacji logiki biznesowej poza mo- del dziedzinowy i obiekty reprezentujñce dane okreĈlane jest w literaturze mianem anemicznego modelu dziedzinowego. Wprowadziä je Martin Fowler, który traktuje takie rozwiñzanie jako antywzorzec. NajwaĔniejszym zarzutem, jaki stawia Fowler takiemu modelowi, jest naruszenie zasad OOP w zakresie enkapsulacji i hermety- zacji kodu — przetwarzaniem stanu obiektów dziedzinowych czy teĔ ich walidacjñ zajmujñ siö zewnötrzne klasy. Inne istotne mankamenty to zmniejszenie czytelnoĈci kodu oraz zwiökszenie moĔliwoĈci wystöpowania duplikacji w kodzie. Mimo tych wad (wyjaĈnionych dokäadnie w artykule pod adresem http://www.martinfowler.com/bliki/ AnemicDomainModel.html) rozwiñzanie to jest czösto i chötnie stosowane, zwäaszcza gdy obiektowy model dziedzinowy jest generowany automatycznie, za pomocñ na- rzödzi ORM, na podstawie istniejñcego wczeĈniej modelu fizycznego. 2.2.1.2. Warstwa usäugowa Bardzo waĪne na etapie projektowania jest rozróĪnienie dwóch aspektów funkcjonal- noĞci systemu wystĊpujących w warstwie biznesowej: modelu dziedzinowego i logiki biznesowej. Model dziedzinowy reprezentuje koncepcje biznesowe i ich zachowanie, podczas gdy logika biznesowa reprezentuje procesy i przepáywy sterowania odpowia- dające scenariuszom przypadków uĪycia. Oddzielenie logiki biznesowej od modelu dziedzinowego jest moĪliwe poprzez wprowadzenie warstwy usáugowej (ang. service layer) odpowiedzialnej za:  zdefiniowanie uproszczonego interfejsu dla klientów modelu dziedzinowego,  implementacjĊ záoĪonych obiektów usáug zdefiniowanych przez wyĪej wymieniony interfejs. Obiekty usáug mogą zapewniaü fasady dla modelu dziedzinowego (strona 83 „Wzo- rzec fasady”) oraz implementowaü procesy biznesowe. 82 JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW Na przykáad na diagramie przypadków uĪycia systemu ISRP wystĊpuje przypadek Przypisz recenzenta do pracy, który reprezentuje záoĪony proces biznesowy. W ra- mach tego procesu zachodzi nastĊpująca sekwencja czynnoĞci: redaktor z uprawnie- niami administratora wybiera z listy recenzenta, do którego automatycznie wysyáane jest zawiadomienie (pocztą elektroniczną — SMTP), i zapisywany jest stan procesu w bazie danych. Zamiast wywoáywaü wiele metod dla obiektów modelu dziedzinowego w warstwie prezentacji, moĪemy wywoáaü jedną metodĊ void assignReviewer(Paper paper,int reviewerId), zdefiniowaną w fasadzie PaperService, której kod zostaá za- mieszczony na listingu 2.2. Zgodnie z dobrą praktyką programowania obiektowego, polegającą na przedkáadaniu interfejsów nad implementacje, wszystkie metody wy- magane dla realizacji procesów biznesowych związanych z przetwarzaniem artykuáów konferencyjnych są okreĞlone w interfejsie PaperService. Listing 2.2. Kod Ĩródáowy 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 caáego kodu klasy jest obszerny, na listingu 2.3 zamieszczony zo- staá wyáącznie jego fragment, zawierający deklaracjĊ klasy oraz implementacjĊ metody odpowiedzialnej za przypisanie recenzenta i wysáanie powiadomienia pocztą elektro- niczną. Listing 2.3. Implementacja interfejsu PaperService public class PaperServiceImpl implements PaperService{ public PaperServiceImpl() {}// bezargumentowy konstruktor public void assignReviewer(Paper paper, int reviewerId, EmailConfiguration emailConfiguration) { Rozdziaä 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java 83 /* pobranie obiektów dostĊpowych 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 /* wysáanie potwierdzenia pocztą elektroniczną*/ EmailSender eSender = new EmailSender(emailConfiguration); eSender.sendEMail(EmailMessagesUtil .assignReviewerMessageToReviewer(reviewer, paper)); } /* ... implementacje pozostaáych metod interfejsu PaperService*/ } Wzorzec fasady Wzorzec fasady jest jednym z podstawowych i jednoczeĞnie najprostszych struktural- nych wzorców projektowych. Zapewnia on dostĊp do záoĪonych systemów, prezentując uproszczony lub uporządkowany interfejs programistyczny. Wzorzec fasady pozwala:  ukryü záoĪonoĞü tworzonego systemu poprzez dostarczenie prostego interfejsu API,  uproĞciü interfejs istniejącego systemu poprzez stworzenie nakáadki, która dostarcza nowy interfejs API. Obiekt fasady jest prostym obiektem poĞredniczącym pomiĊdzy obiektem klasy klienta Īądającym okreĞlonej funkcjonalnoĞci a klasami dostarczającymi elementów do uzy- skania tej funkcjonalnoĞci. 2.2.1.3. Lokalizatory usäug Usáugi biznesowe powinny byü áatwo dostĊpne dla wszelkiego typu klientów, nieza- leĪnie od tego, czy są one klientami lokalnymi, czy teĪ zdalnymi. Gdy w warstwie biznesowej wystĊpuje wiele fasad, korzystanie z usáug biznesowych moĪemy uáatwiü poprzez zastosowanie uproszczonej wersji wzorca lokalizatora usáug (czĊĞciowo opi- sanego w rozdziale 1., w ramce „Wzorzec delegata biznesowego”). Obiekt lokalizato- ra tworzy jeden punkt dostĊpowy do kodu warstwy biznesowej, jednoczeĞnie zmniej- szając zaleĪnoĞü klienta od implementacji mechanizmów wyszukiwania usáug. Zazwyczaj lokalizator jest implementowany jako pojedynczy obiekt (singleton), chyba Īe stosowany jest w Ğrodowisku rozproszonym. Na przykáad w systemie ISRP istnieją zdefiniowane odrĊbne fasady dla usáug związanych z przetwarzaniem artykuáów, uĪytkowników, recenzentów, formularzy z pytaniami oraz danych sáownikowych. Przedstawiony na listingu 2.4 interfejs ServiceLocator zawiera deklaracje metod, które udostĊpniają obiekty implementujące interfejsy tych fasad. Operowanie na interfejsach pozwala na uniezaleĪnienie siĊ od jednej konkretnej implementacji zestawu fasad, dziĊki czemu áatwo moĪemy dostarczyü implementacje zoptymalizowane pod kątem wydajnoĞci czy bezpieczeĔstwa. 84 JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW Listing 2.4. Kod Ĩródáowy interfejsu lokalizatora usáug 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, definiującego metody dostĊpowe zwracające obiekty fasad. Aby tak prosty lokalizator wykonywaá swoje zadanie, naleĪy wáaĞciwie zainicjowaü i przechowaü jego instancjĊ w kontenerze, co jest opisane w nastĊpnym punkcie. Listing 2.5. Kod Ĩródáowy lokalizatora usáug 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 PaperService paperService; private UserService userService; private ReviewService reviewService; private CountryService countryService; private 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;} } Rozdziaä 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java 85 2.2.1.4. Integracja warstwy usäugowej z warstwñ prezentacji JSF Wygodnym sposobem integracji warstwy usáugowej z warstwą prezentacji aplikacji JSF jest wykorzystanie mechanizmu komponentów zarządzanych. Na przykáad obiekt lokalizatora usáug moĪe zostaü zarejestrowany w aplikacji jako komponent zarządzany o zasiĊgu aplikacji. BĊdzie on wówczas automatycznie tworzony w momencie pierw- szego odwoáania siĊ do niego, a nastĊpnie przechowywany w kontekĞcie aplikacji JSF aĪ do koĔca jej dziaáania. Deklaratywny sposób rejestracji obiektu lokalizatora w pliku faces-config.xml zostaá zaprezentowany na listingu 2.6. Pokazane na przykáadzie rozwiązanie umoĪliwia do- stĊp do obiektu lokalizatora poprzez wykorzystanie jego identyfikatora — service ´LocatorImpl lub wáaĞciwoĞci komponentu uĪytkowego utilBean (opis komponentów zarządzanych znajduje siĊ w rozdziale 3.). W omawianym przykáadzie lokalizatorem jest obiekt zaprezentowanej na listingu 2.5 klasy ServiceLocatorImpl, ale dziĊki sto- sowaniu interfejsów fasad moĪe on zostaü áatwo zamieniony na inny obiekt bĊdący lokalizatorem, do czego wystarcz
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: