Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00596 008243 10457891 na godz. na dobę w sumie
Java. Obsługa wyjątków, usuwanie błędów i testowanie kodu - książka
Java. Obsługa wyjątków, usuwanie błędów i testowanie kodu - książka
Autor: Liczba stron: 376
Wydawca: Helion Język publikacji: polski
ISBN: 83-7361-796-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> java - programowanie
Porównaj ceny (książka, ebook, audiobook).

W każdej aplikacji mogą wystąpić błędy.
Przygotuj się na to pisząc odpowiednią obsługę wyjątków

Żaden kod nie jest idealny -- nawet najbardziej doświadczony programista popełnia błędy. Tym, co w takich przypadkach wyróżnia doświadczonego programistę jest fakt, że jego aplikacje posiadają mechanizmy pozwalające na obsługę tych błędów. Dzięki nim program nie zawiesi się ani nie 'pogubi' żadnych danych. Oczywiście, aby napisać odpowiednią obsługę wyjątków, należy poznać ich typy oraz mechanizmy ich powstawania. Niezbędna jest również znajomość wzorców projektowych oraz narzędzi do testowania kodu.

W książce 'Java. Obsługa wyjątków, usuwanie błędów i testowanie kodu' znajdziesz wszystkie te informacje. Dowiesz się, jak zaimplementować obsługę wyjątków i poprawić jakość kodu źródłowego. Poznasz modele wyjątków i nauczysz się zarządzać mechanizmami ich obsługi na poziomie aplikacji i pojedynczych modułów. Przeczytasz tu także o wzorach projektowych zapewniających prawidłową obsługę wyjątków.

Po przeczytaniu tej książki Twoja wiedza pozwoli Ci na podejmowanie odpowiednich decyzje dotyczące architektury aplikacji i odpowiadającego jej modelu wyjątków.

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

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREĎCI SPIS TREĎCI KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOĎCIACH O NOWOĎCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Java. Obs³uga wyj¹tków, usuwanie b³êdów i testowanie kodu Autor: Stephen Stelting T³umaczenie: Adam Bochenek ISBN: 83-7361-796-5 Tytu³ orygina³u: Robust Java Format: B5, stron: 376 W ka¿dej aplikacji mog¹ wyst¹piæ b³êdy. Przygotuj siê na to pisz¹c odpowiedni¹ obs³ugê wyj¹tków • Poznaj techniki programowania, dziêki którym Twoje aplikacje stan¹ siê odporne na b³êdy • Naucz siê przewidywaæ b³êdy i zapobiegaæ ich wystêpowaniu • Zabezpiecz aplikacje przez skutkami wyst¹pienia b³êdów stosuj¹c odpowiednie wzorce projektowe ¯aden kod nie jest idealny — nawet najbardziej doġwiadczony programista pope³nia b³êdy. Tym, co w takich przypadkach wyró¿nia doġwiadczonego programistê jest fakt, ¿e jego aplikacje posiadaj¹ mechanizmy pozwalaj¹ce na obs³ugê tych b³êdów. Dziêki nim program nie zawiesi siê ani nie „pogubi” ¿adnych danych. Oczywiġcie, aby napisaæ odpowiedni¹ obs³ugê wyj¹tków, nale¿y poznaæ ich typy oraz mechanizmy ich powstawania. Niezbêdna jest równie¿ znajomoġæ wzorców projektowych oraz narzêdzi do testowania kodu. W ksi¹¿ce „Java. Obs³uga wyj¹tków, usuwanie b³êdów i testowanie kodu” znajdziesz wszystkie te informacje. Dowiesz siê, jak zaimplementowaæ obs³ugê wyj¹tków i poprawiæ jakoġæ kodu ĥród³owego. Poznasz modele wyj¹tków i nauczysz siê zarz¹dzaæ mechanizmami ich obs³ugi na poziomie aplikacji i pojedynczych modu³ów. Przeczytasz tu tak¿e o wzorach projektowych zapewniaj¹cych prawid³ow¹ obs³ugê wyj¹tków. • Koncepcje obs³ugi wyj¹tków • Obs³uga wyj¹tków w aplikacjach wielow¹tkowych • Przyczyny wystêpowania wyj¹tków w ró¿nych elementach jêzyka Java • Programowanie rozproszone w Javie • Wyj¹tki w aplikacjach J2EE • Wzorce projektowe • Testowanie kodu i usuwanie b³êdów Po przeczytaniu tej ksi¹¿ki Twoja wiedza pozwoli Ci na podejmowanie odpowiednich decyzje dotycz¹ce architektury aplikacji i odpowiadaj¹cego jej modelu wyj¹tków. Spis treści Wstęp ...................................................z...................................................z................................................... 11 Część I Podstawy obsługi wyjątków 17 Rozdział 1. Obsługa wyjątków. Wprowadzenie...................................................z.................................... 19 Wstęp ...................................................o...................................................o.................. 19 Pojęcie wyjątku ...................................................o...................................................o..... 22 Hierarchia klas reprezentujących wyjątki ...................................................o..................... 24 Opcje związane z przechwytywaniem oraz deklaracją wyjątków.......................................... 25 Przechwytywanie i obsługa wyjątków: bloki try, catch i finally ....................................... 26 Reguły dotyczące stosowania bloków try-catch-finally.................................................. 27 Deklarowanie metod zgłaszających wyjątki ...................................................o............. 28 Reguły dotyczące deklarowania metod zgłaszających wyjątki ....................................... 28 Wyjątki kontrolowane i niekontrolowane ...................................................o...................... 28 Podstawowe własności każdego wyjątku ...................................................o..................... 29 Podsumowanie ...................................................o...................................................o..... 31 Rozdział 2. Obsługa wyjątków. Techniki i praktyka...................................................z............................33 Wstęp ...................................................o...................................................o.................. 33 Kiedy przechwytywać wyjątki, a kiedy je deklarować? ...................................................o.... 34 Typowe sposoby obsługi wyjątków ...................................................o.............................. 35 1. Zapis błędu lub związanej z nim informacji do dziennika ......................................... 36 2. Zwrócenie się do użytkownika z prośbą o podjęcie odpowiedniej decyzji ........................ 38 3. Użycie wartości domyślnych lub alternatywnych ...................................................o.. 39 4. Przekazanie sterowania do innej części aplikacji ...................................................o. 40 5. Konwersja wyjątku do innej postaci ...................................................o................... 40 6. Zignorowanie problemu...................................................o.................................... 41 7. Powtórzenie operacji...................................................o........................................ 41 8. Wywołanie operacji alternatywnej ...................................................o...................... 42 9. Przygotowanie aplikacji do zamknięcia ...................................................o............... 42 Co należy, a czego nie wolno robić w ramach obsługi wyjątków? ....................................... 43 Dobre praktyki ...................................................o...................................................o...... 43 1. Obsługuj wyjątki zawsze, gdy jest to możliwe ...................................................o...... 43 2. Obsługa wyjątku powinna ściśle zależeć od jego typu ............................................. 43 6 Java. Obsługa wyjątków, usuwanie błędów i testowanie kodu 3. Zapisuj do dziennika te wyjątki, które mogą mieć wpływ na działanie aplikacji ........... 44 4. Dokonuj konwersji wyjątków, jeśli tylko dojdziesz do wniosku, że lepiej reprezentują one istotę problemu ...................................................o......... 44 Czego robić nie należy?...................................................o............................................. 44 1. Nie ignoruj wyjątków, chyba że masz absolutną pewność, iż jest to niegroźne dla działania aplikacji ...................................................o.......... 44 2. Nie dopuszczaj do zbyt ogólnego traktowania wyjątków........................................... 45 3. Nie dokonuj konwersji wyjątku polegającej na zmianie typu szczegółowego na ogólny (chyba że przechowasz kontekst zdarzenia w inny sposób) ....................... 46 4. Wyjątków lepiej unikać, niż je obsługiwać ...................................................o........... 47 Rozdział 3. Zaawansowane koncepcje obsługi wyjątków ...................................................z..................49 Wstęp ...................................................o...................................................o.................. 49 Tworzenie własnych wyjątków ...................................................o.................................... 50 1. Definicja klasy wyjątku ...................................................o..................................... 51 2. Deklaracja wyjątku przez metody, które mogą być potencjalnym źródłem błędu ......... 52 3. Znalezienie tych miejsc, które są bezpośrednią przyczyną wystąpienia błędu, wygenerowanie w nich wyjątków i wyrzucenie ich za pomocą instrukcji throw............. 52 Łańcuchy wyjątków ...................................................o...................................................o 54 Lokalizacja wyjątków...................................................o................................................. 55 1. Stworzenie klasy dziedziczącej po ResourceBundle, która będzie przechowywała opis wyjątku ...................................................o...................................................o 56 2. Zdefiniowanie klasy odpowiadającej danemu językowi ............................................ 57 3. Definicja klasy wyjątku, w której pokrywamy metodę getLocalizedMessage ............... 57 Wyjątki a pokrywanie metod ...................................................o...................................... 59 Deklaracja wyjątków w interfejsach i klasach abstrakcyjnych ............................................ 60 Stos wywołań wyjątku ...................................................o............................................... 61 Wyjątki z perspektywy kodu pośredniego ...................................................o..................... 64 Rozdział 4. Obsługa wyjątków w aplikacjach wielowątkowych...................................................z.........69 Wstęp ...................................................o...................................................o.................. 69 Kiedy należy dzielić program na wątki? ...................................................o.................. 70 Wyjątki w systemach wielowątkowych ...................................................o......................... 71 Wyjątki w synchronizowanych blokach kodu ...................................................o................. 72 Praca wielowątkowa a ryzyko wystąpienia wyjątku ...................................................o........ 74 Wyjątki związane z komunikowaniem się wątków...................................................o.......... 75 Zakleszczenie ...................................................o...................................................o....... 78 ThreadDeath...................................................o...................................................o......... 79 Rozdział 5. Zapis do dziennika i asercje...................................................z............................................... 81 Wstęp ...................................................o...................................................o.................. 81 Wprowadzenie do Logging API...................................................o.................................... 81 Kiedy stosować Logging API?...................................................o..................................... 82 Struktura Logging API ...................................................o............................................... 82 Szczegóły dotyczące używania biblioteki...................................................o...................... 83 Konfigurowanie dziennika...................................................o.......................................... 88 Przykład pierwszy: Proste użycie domyślnego obiektu Logger....................................... 88 Przykład drugi: Użycie i konfiguracja kilku obiektów typu Logger ................................... 89 Przykład trzeci: Dziennik rozproszony ...................................................o..................... 90 Asercje ...................................................o...................................................o................ 91 Używanie asercji ...................................................o................................................. 92 Jak i kiedy korzystać z asercji? ...................................................o............................. 92 Część II Planowanie obsługi wyjątków Spis treści 7 95 Rozdział 6. Planowanie obsługi wyjątków ...................................................z...........................................97 Wstęp ...................................................o...................................................o.................. 97 Zasady dobrego projektowania obiektowego ...................................................o................ 98 Projektowanie z uwzględnieniem błędów ...................................................o.............. 103 Etap 1. Identyfikacja przypadku użycia ...................................................o................. 104 Etap 2. Precyzyjny opis procesu i poszczególnych jego składników............................. 105 Etap 3. Identyfikacja potencjalnych błędów i ocena ich ryzyka ................................... 106 Etap 4. Wskazywanie miejsc wystąpienia potencjalnych błędów w ramach operacji...... 110 Etap 5. Przygotowanie strategii obsługi błędów...................................................o..... 111 Projektowanie z myślą o łatwiejszym zarządzaniu — korzyści i wady........................... 113 Identyfikacja błędów ...................................................o.......................................... 114 Podsumowanie ...................................................o...................................................o... 115 Rozdział 7. Wyjątki a podstawowe elementy języka Java...................................................z.................117 Wstęp ...................................................o...................................................o................ 117 Typy podstawowe ...................................................o...................................................o 118 Wprowadzenie ...................................................o.................................................. 118 Stosowanie ...................................................o...................................................o... 118 Potencjalne problemy ...................................................o........................................ 119 Ogólne zalecenia...................................................o............................................... 121 Klasa Object i obiekty tego typu ...................................................o............................... 122 Wprowadzenie ...................................................o.................................................. 122 Potencjalne problemy ...................................................o........................................ 122 Tablice...................................................o...................................................o............... 128 1. Indeksowanie ...................................................o............................................... 129 2. Wielkość tablicy ...................................................o............................................ 129 3. Typ elementów tablicy...................................................o.................................... 129 Interfejsy pakietu java.lang ...................................................o...................................... 130 Klasy String i StringBuffer ...................................................o....................................... 131 Klasa String ...................................................o...................................................o.. 132 Klasa StringBuffer ...................................................o............................................. 132 Klasy BigDecimal i BigInteger ...................................................o.................................. 132 Klasy opakowujące ...................................................o................................................. 133 Rozdział 8. Kolekcje i operacje wejścia-wyjścia...................................................z............................... 135 Wstęp ...................................................o...................................................o................ 135 Biblioteka obsługi kolekcji ...................................................o....................................... 135 Wprowadzenie ...................................................o.................................................. 135 Korzystanie z kolekcji ...................................................o........................................ 136 Problemy i wyjątki typowe dla kolekcji...................................................o.................. 141 System wejścia-wyjścia ...................................................o........................................... 144 Problemy typowe dla operacji wejścia-wyjścia ...................................................o....... 146 Błędy i wyjątki w klasach wejścia-wyjścia...................................................o................... 148 Problemy ogólne ...................................................o............................................... 148 Problemy dotyczące strumieni określonego typu ...................................................o... 149 Biblioteka New I/O (NIO) ...................................................o......................................... 156 Wyjątki w New I/O API...................................................o............................................. 158 Bufory...................................................o...................................................o........... 158 Zestawy znaków...................................................o................................................ 159 Kanały ...................................................o...................................................o.......... 160 Przełączniki ...................................................o...................................................o... 164 8 Java. Obsługa wyjątków, usuwanie błędów i testowanie kodu Rozdział 9. Programowanie rozproszone w Javie ...................................................z........................... 167 Wstęp ...................................................o...................................................o................ 167 Podstawy komunikacji między aplikacjami ...................................................o................. 168 Modele komunikacji w Javie ...................................................o............................... 170 Dodatkowe zagadnienia związane z pracą rozproszoną ............................................. 170 Model obsługi wyjątków ...................................................o..................................... 172 Typowe problemy ...................................................o.............................................. 173 RMI — zdalne wywoływanie metod ...................................................o........................... 174 Model komunikacyjny RMI ...................................................o.................................. 174 Typowe zagadnienia związane z używaniem RMI ...................................................o... 175 Model wyjątków RMI ...................................................o.......................................... 178 Java Naming and Directory Interface, JNDI ...................................................o................ 184 Typowe zagadnienia związane z JNDI ...................................................o................... 185 Model wyjątków JNDI ...................................................o......................................... 186 Java Database Connectivity, JDBC ...................................................o........................... 189 Wyjątki w JDBC ...................................................o................................................. 189 Ogólne zagadnienia dotyczące obsługi baz danych ...................................................o 191 Cykl życia aplikacji korzystającej z JDBC...................................................o............... 193 Podsumowanie ...................................................o...................................................o... 198 Rozdział 10. J2EE...................................................z...................................................z............................... 199 Wstęp ...................................................o...................................................o................ 199 Podstawowy model aplikacji J2EE ...................................................o............................ 200 Model aplikacji J2EE ...................................................o......................................... 202 Wyjątki w J2EE...................................................o.................................................. 203 Warstwa klienta ...................................................o...................................................o.. 204 Warstwa aplikacji sieciowej ...................................................o..................................... 206 Deklaratywna obsługa błędów...................................................o............................. 207 Komponenty aplikacji sieciowej..................................................o............................ 208 Serwlety i filtry: obsługa wyjątków na poziomie programu.......................................... 209 Model wyjątków serwletów i filtrów ...................................................o...................... 210 Typowe zagadnienia i ryzyko związane z używaniem serwletów................................... 211 Model wyjątków JSP ...................................................o.......................................... 215 Bezpośrednie przekierowanie błędów w JSP ...................................................o......... 215 Sposób obsługi wyjątków w JSP ...................................................o.......................... 216 Błędy związane z translacją i uruchamianiem stron JSP ............................................ 217 Biblioteki własnych znaczników ...................................................o........................... 217 Warstwa komponentów EJB...................................................o..................................... 218 Standardowe metody EJB...................................................o................................... 219 Ogólne kwestie związane z obsługą EJB...................................................o............... 221 Zagadnienia związane z typem komponentu ...................................................o......... 223 Model wyjątków EJB ...................................................o.......................................... 225 Zarządzanie cyklem życia komponentów. Metody wywoływane przez klienta ................ 227 Metody komponentu wywoływane przez kontener ...................................................o.. 230 Wyjątki z punktu widzenia kontenera ...................................................o................... 231 Obsługa transakcji...................................................o.................................................. 232 J2EE i obsługa wyjątków — kwestie ogólne ...................................................o............... 236 Czynniki, które należy rozważyć podczas obsługi wyjątków w J2EE................................... 237 Obsługa dziennika...................................................o............................................. 237 Koszty związane ze zgłaszaniem wyjątków...................................................o............ 238 Obciążenie sieci...................................................o................................................ 239 Inne zalecenia dotyczące systemów J2EE ...................................................o............ 239 Spis treści 9 Część III Skuteczne posługiwanie się wyjątkami i ich obsługa 241 Rozdział 11. Architektura i projekt modelu obsługi wyjątków...................................................z......... 243 Wstęp ...................................................o...................................................o................ 243 Dlaczego architekt powinien interesować się obsługą błędów? ....................................... 244 Koszt awarii...................................................o...................................................o... 245 Cena sukcesu...................................................o...................................................o 246 Architektura, projekt i rozwój...................................................o.................................... 246 Role architekta i projektanta: cienka linia na piasku................................................. 247 Programista: na linii frontu ...................................................o................................. 247 Kluczowe decyzje architektoniczne dotyczące modelu wyjątków ...................................... 248 Priorytety i cechy architektury ...................................................o............................. 249 Cechy modelu wyjątków ...................................................o.......................................... 250 Strategia obsługi i propagacji wyjątków...................................................o................ 250 Model klas reprezentujących wyjątki i błędy...................................................o.......... 253 Usługi uniwersalne ...................................................o............................................ 256 Podsumowanie ...................................................o...................................................o... 257 Kilka słów na temat kolejnych rozdziałów ...................................................o............. 258 Rozdział 12. Wzorce...................................................z...................................................z......................... 259 Wstęp ...................................................o...................................................o................ 259 Wzorce architektoniczne (oparta na wzorcach architektura oprogramowania, POSA-ASOP)..... 260 1. Wzorzec warstw ...................................................o............................................ 261 2. Model-widok-kontroler (MVC) ...................................................o.......................... 262 Wzorce projektowe „Bandy czworga” ...................................................o........................ 264 Wzorce konstrukcyjne ...................................................o............................................. 264 1. Builder (budowniczy) ...................................................o...................................... 264 2. Singleton ...................................................o...................................................o.. 266 Wzorce strukturalne...................................................o................................................ 267 1. Adapter...................................................o...................................................o..... 267 2. Composite ...................................................o...................................................o 268 3. Facade (fasada) ...................................................o............................................ 270 4. Proxy (pośrednik) ...................................................o.......................................... 271 Wzorce czynnościowe ...................................................o............................................. 272 1. Chain of Responsibility (łańcuch odpowiedzialności)............................................. 272 2. Command (polecenie)...................................................o.................................... 273 3. Observer (obserwator) ...................................................o................................... 274 4. State (stan) ...................................................o.................................................. 275 5. Strategy (strategia)...................................................o........................................ 276 Wzorce projektowe J2EE ...................................................o......................................... 277 Warstwa integracyjna...................................................o.............................................. 278 1. Data Access Object, DAO (obiekt dostępu do danych) .......................................... 278 Warstwa prezentacyjna ...................................................o........................................... 280 1. Front Controller (sterownik frontalny) ...................................................o............... 280 2. Intercepting Filter (wzorzec przechwytujący) ...................................................o...... 281 Warstwa biznesowa ...................................................o................................................ 282 1. Service Locator (lokalizator usług)...................................................o................... 282 2. Session Facade (fasada sesji)...................................................o........................ 283 Podsumowanie ...................................................o...................................................o... 283 10 Java. Obsługa wyjątków, usuwanie błędów i testowanie kodu Rozdział 13. Testowanie...................................................z...................................................z................... 285 Jaki jest cel testowania i dlaczego jest ono tak ważne? ................................................. 285 Nieprawdziwe opinie na temat testowania...................................................o................. 286 Mit pierwszy: „Nie ma potrzeby, by programiści testowali swój kod”........................... 287 Mit drugi: „Programiści w pełni odpowiadają za poprawność kodu” ............................ 287 Mit trzeci: „Do zweryfikowania aplikacji wystarczy «jeden test»” ................................. 288 Mit czwarty: „Istnieje możliwość kompletnego przetestowania aplikacji”..................... 288 Warianty testowania, czyli na zewnątrz i wewnątrz skrzynki............................................. 289 Co znajduje się w skrzynce? (Typy testów) ...................................................o........... 289 Podział ról i odpowiedzialności w procesie testowania .............................................. 291 „Gdyby to było takie łatwe…”, czyli problemy z testowaniem w Javie ............................... 293 Testowanie w praktyce...................................................o............................................ 294 W jaki sposób zinstytucjonalizować testowanie? ...................................................o... 294 Organizacja struktury testów...................................................o............................... 298 Taktyka i technologia, czyli jak zarządzać testami i jak je przeprowadzać ......................... 303 Gotowe narzędzia obsługi testów ...................................................o........................ 304 Zintegrowane środowiska programistyczne...................................................o........... 305 Miara jakości aplikacji ...................................................o....................................... 306 Kiedy testy należy uznać za zakończone? ...................................................o.................. 306 Ogólna miara testowania ...................................................o................................... 306 Miara testowania stosowana przez programistów ...................................................o. 307 Rozdział 14. Usuwanie błędów ...................................................z........................................................... 309 Wstęp ...................................................o...................................................o................ 309 Zaczarowane słowo: błąd… ...................................................o..................................... 310 Zasady i praktyka debugowania ...................................................o............................... 311 Strategie usuwania błędów...................................................o...................................... 313 Widoczne wyniki oraz sposoby usuwania błędów ...................................................o........ 318 Techniki testowania — poziom niski...................................................o.................... 320 Techniki testowania — poziom średni ...................................................o................. 322 Techniki testowania — poziom wysoki ...................................................o................. 323 Dodatkowe kwestie związane z usuwaniem błędów ...................................................o.... 325 Debugowanie innych technologii ...................................................o......................... 325 Wyjątki zgłaszane na poziomie infrastruktury ...................................................o........ 326 Dodatki 327 Dodatek A Wpływ obsługi i deklarowania wyjątków na szybkość działania aplikacji...................... 329 Dodatek B Krótkie i łatwe wprowadzenie do JUnit ...................................................z.......................... 335 Dodatek C MyBuggyServlet — kwestie poprawności komponentu .................................................. 347 Słownik używanych w książce terminów technicznych ...................................................z................. 349 Bibliografia...................................................z...................................................z....................................... 353 Skorowidz...................................................z...................................................z........................................ 357 6 Planowanie obsługi wyjątków Wstęp W poprzedniej części skoncentrowałem się przede wszystkim na czysto programistycznych aspektach posługiwania się wyjątkami. Są to umiejętności podstawowe, niezbędne każdemu, kto chce w swych aplikacjach obsługiwać sygnalizowane w ten sposób problemy. Jednak sama znajomość pewnych technik programistycznych nie jest jedynym czynnikiem mającym wpływ na skuteczne wykorzystanie możliwości, jakie daje nam mechanizm zgłaszania i obsługi wyjątków. Oprócz wiedzy technicznej, musimy znać bardziej ogólne zasady i wiedzieć, jak i kiedy je stosować. Inaczej mówiąc, bycie doskonałym koderem nie gwarantuje wcale, że pisane przez nas aplikacje będą świetne. Dlatego w niniejszym rozdziale, podobnie jak w całej drugiej części książki, przeniesiemy nasze zainteresowania na nieco wyższy poziom abstrakcji. Zajmiemy się prawi- dłową strukturą obsługi wyjątków wewnątrz metod, pomiędzy metodami a także na poziomie współpracujących ze sobą komponentów aplikacji. Moim zamiarem jest prezentacja sposobów pozwalających dotychczas zdobyte umiejętności zamienić na dobrze zorganizowane i łatwe w utrzymaniu konstrukcje kodu. W tej części książki z programistów zmienimy się w pro- jektantów aplikacji. Ogromny błąd wielu twórców aplikacji polega na tym, że obsługę wyjątków traktują oni jak zło konieczne, przypominając sobie o tym jedynie wtedy, gdy zmuszą ich do tego sygnali- zowane przez kompilator błędy. Tworzenie oprogramowania bez wcześniejszego, starannego rozważenia potencjalnych błędów, które mogą podczas jego eksploatacji wystąpić, przypomi- na konstruowanie samolotu (lub budynku mieszkalnego) bez sporządzenia odpowiednich planów i stosowania powszechnie znanych reguł sztuki. Zakładamy naiwnie, że powinno się udać, choć oczywiście rezultatu takiego zagwarantować nie sposób. Gwoli sprawiedliwości nadmienić jednak należy, że słabość procesów tworzenia software’u polega między innymi na tym, iż wiele tradycyjnych metodyk lekceważy problem obsługi błę- dów. Czy należy się więc dziwić, że aplikacje projektowane przy ich użyciu wykazują w tej dziedzinie braki? 98 Część II n Planowanie obsługi wyjątków Wiele metodologii koncentruje się przede wszystkim na próbie stworzenia wydajnego, uniwersalnego i obiektowego modelu rozwiązania danego problemu. Nie zrozum mnie źle — nie jest to z mej strony żaden zarzut, tak właśnie powinno się podchodzić do projektowa- nia. Jednak pominięcie czynności mających na celu identyfikację potencjalnych zagrożeń występujących podczas pracy systemu czyni ten proces niekompletnym. Każdy dobrze skon- struowany projekt powinien zawierać analizę ryzyka. W niniejszym rozdziale mam nadzieję pokazać Ci, w jaki sposób składniki dobrze zorgani- zowanego projektu aplikacji uzupełnić można o element odpowiadający za poprawną obsługę wyjątków, zaplanowany po analizie potencjalnych problemów. Nie wiąże się to z jakimś ogromnym, dodatkowym nakładem pracy, a w zamian otrzymujemy znacznie bezpieczniejszy, i dzięki temu łatwiejszy w utrzymaniu, kod. Zasady dobrego projektowania obiektowego Często słyszy się, że rozpoczynając dane przedsięwzięcie dobrze jest mieć wizję jego zakoń- czenia. Zastosujmy tę regułę w dziedzinie projektowania aplikacji obiektowych: jakie są główne cele i reguły ich tworzenia? Czym charakteryzuje się dobrze zaprojektowany i napisany, obiektowy kod? Najbardziej podstawowym kryterium, które kod musi spełnić, jest zapewnie- nie założonej funkcjonalności przy dającej się zaakceptować wydajności. Powinien on też być przejrzysty i elastyczny, dając dzięki temu możliwości wykorzystania go w innych projektach. O idealnej sytuacji można mówić, gdy pisząc aplikację, stworzymy zbiór uniwer- salnych modułów, które tworzyć będą funkcjonalne i gotowe do ponownego użycia kompo- nenty o jasno zdefiniowanych funkcjach1. Brzmi wspaniale. Założenia te wydają się rozsądne i nawet możliwe do realizacji. Szczególnie na etapie ich formułowania. Łatwo się o nich mówi, znacznie trudniej wprowadzić je w życie. Nie zważajmy jednak na trudności, zasad tych powinniśmy się trzymać podczas tworzenia każdej klasy, komponentu, systemu czy biblioteki2. Istnieje kilka ogólnych reguł, które cha- rakteryzują dobrze zaprojektowaną aplikację obiektową. Nasza dyskusja będzie łatwiejsza, gdy podczas ich prezentacji założymy, że odnoszą się one do pojedynczej klasy. Pamiętaj jednak, że stosujemy je także przy konstruowaniu bardziej złożonych komponentów. A zatem: projektując klasę, nie wolno nam zapomnieć o następujących zasadach, których istotę stanowi: Abstrakcja: klasa jest modelem określonego pojęcia lub danych. Zasadę tę przenosimy na każdy obiekt danej klasy, dotyczy ona jego stanu i funkcjonowania. n Pole: każde z pól reprezentuje pewien wewnętrzny stan obiektu, spełniając w ten sposób zadania stawiane przed modelem odpowiadającym pewnemu pojęciu i jego cechom. 1 i Dodatkowo kod powinien być kompletnie udokumentowany oraz dostarczony na czas i w ramach założonego budżetu. Co więcej, jasne sprecyzowanie wymagań użytkownika nie powinno zachwiać naszej równowagi psychicznej. 2 Posługując się podczas dyskusji pojęciem komponent, mam na myśli zbiór klas zaprojektowany w taki sposób, by mogły one współpracować ze sobą i tworzyć moduł. Dobrze zaprojektowany komponent, system czy biblioteka posiadać musi te same cechy co dobrze skonstruowana klasa. Rozdział 6. n Planowanie obsługi wyjątków 99 n Metoda: każda metoda reprezentuje operację, którą można na danym obiekcie przeprowadzić. Prowadzić ona może do zmiany stanu obiektu bądź też wykonywać zadanie związane z jego cyklem życia. Enkapsulacja (hermetyzacja): pola i metody, które wspólnie tworzą klasę, podzielić możemy na dwie podstawowe kategorie. n Implementacja: w jej skład wchodzą pola zawarte w klasie i metody zarządzające tymi danymi, mające wpływ na stan obiektu. Implementacja odpowiada za prywatną, niedostępną z zewnątrz część obiektu. n Interfejs: metody stanowiące usługi udostępnione na zewnątrz, do których dostęp mają inne obiekty. Interfejs reprezentuje sposób, w jaki obiekt widziany jest przez pozostałą część aplikacji. Niektóre modele dokonują dalej idącego podziału, wyróżniając interfejs wewnętrzny, odpowiedzialny za sterowanie oraz zewnętrzny, związany z prezentacją. Spójność: klasa ma jasno sprecyzowany cel i charakter. Odpowiada pojedynczemu pojęciu, którego dotyczą wszystkie zdefiniowane w niej operacje. Niezależność: klasa powinna w jak najmniejszym stopniu zależeć od innych klas. Jeśli takich związków łączących klasy jest wiele, może pojawić się wątpliwość co do jakości projektu3. Konsekwentne stosowanie powyższych reguł doprowadzić powinno do powstania dobrze zdefi- niowanych klas, z których powstaną następnie komponenty, podsystemy, a na końcu kompletne aplikacje. Patrząc z bardziej odległej perspektywy, aplikacja obiektowa postrzegana może być jako zbiór współpracujących za sobą obiektów, którym przyświeca pewien wspólny cel. A współ- praca ta to komunikacja realizowana za pomocą wywoływania metod, co czynione jest we- dług odpowiednich zasad i w określonej kolejności. Połączenie tej koncepcji z praktyką do- starczania przez klasy metod o jasno sprecyzowanych funkcjach w konsekwencji daje nam posiadające określoną hierarchię łańcuchy wywołań. Metody niższego poziomu wywoływane są przez metody wyższego poziomu, które to z kolei są używane przez jeszcze inną warstwę aplikacji itd. Struktura ta pozwala łączyć pojedyncze, w miarę proste operacje w czynności bardziej złożone, co ostatecznie doprowadzi nas do kompletnych procesów biznesowych i przypadków użycia, stanowiących podstawowe zadania aplikacji4. Żadna z przedstawionych dotychczas zasad nie dotyczy jednak bezpośrednio zagadnienia obsługi wyjątków. Jaki jest związek tego tematu z dziedziną projektowania aplikacji? 3 i Próba zdefiniowania pożądanych cech, które spełniać powinien dobrze zaprojektowany system obiektowy spowodowała powstanie zbioru zasad. W rezultacie temat ten jest wyczerpująco opisany, a duża część tej dokumentacji znajduje się w sieci. Polecam następujące adresy: http://c2.com./cgi/ wiki?PrinciplesOfObjectOrientedDesign (Wiki Web) oraz http://ootips.org/ood-principles.html (OOTips). 4 W programowaniu strukturalnym proces dzielenia złożonej funkcjonalności na mniejsze operacje nazywany jest dekompozycją funkcjonalną. Podobnie jest w programowaniu obiektowym, ale tutaj odpowiedzialność za poszczególne operacje przypisywana jest klasom, co prowadzi do powstania modułów bardziej elastycznych i gotowych do ponownego użycia. 100 Część II n Planowanie obsługi wyjątków W realnych warunkach są z tym niemałe problemy. Wiele zespołów programistycznych (a tak- że, niestety, metodyk przez nie stosowanych) do obsługi błędów podchodzi w sposób nie dość poważny. O konieczności obsługi błędów myślimy dopiero w momencie, gdy zaczynają nam one rzeczywiście przeszkadzać, a dzieje się tak podczas końcowych etapów realizacji przedsię- wzięcia. Struktura systemu jest już wtedy ustabilizowana i niełatwo wprowadzić do niej zmiany lub rozszerzenia. Większość członków zespołu odczuwa w tym okresie niemałe zmęczenie, które potęgowane jest przez wyjątkowo szybko mnożące się problemy związane z pojawiają- cymi się w wielu miejscach aplikacji błędami. Jak w takiej sytuacji należy się zachować? Mogę zaproponować trzy możliwe rozwiązania polegające na próbie dołączenia obsługi błędów do aplikacji w końcowej fazie jej powstawania: 1. Przechwytywanie i lokalna obsługa wyjątków w tych metodach, w których się one pojawią. Rozwiązanie to nie wpływa na istniejącą już, dotychczasową strukturę aplikacji. Często jednak pociąga za sobą pewien nieład, brak konsekwencji i kojarzy się z cichą obsługą wyjątków, którą porównałem do zamiatania śmieci pod dywan. Inne części aplikacji nie zostaną przez to poinformowane o poważnych zagrożeniach, których zasięg nie musi mieć zawsze jedynie lokalnego charakteru. 2. Zmiana projektu dokonana w ograniczonym zakresie, uwzględniająca modyfikacje konieczne do tego, by zarządzanie problemami przenieść na poziom komponentu. To rodzaj kompromisu, który zwykle nie burzy nam dotychczasowej, ogólnej struktury aplikacji. Podejście to jednak ma dwie wady. Po pierwsze, istnieje niebezpieczeństwo, że zbyt wiele modyfikacji na poziomie komponentu może odbić się niekorzystnie na jego jakości. Po drugie, ciągle istnieje ryzyko, że wyjątki obsługiwane na poziomie pojedynczego komponentu nie poinformują o ważnym zdarzeniu pozostałych elementów całej aplikacji. 3. Reorganizacja całej aplikacji. Decyzja taka pociąga za sobą tak wiele koniecznych zmian, że tak naprawdę cofamy się do jednego z pierwszych etapów powstawania aplikacji. Co więcej, istnieje ryzyko, że nigdy fazy tej nie ukończymy, jeśli zmiana projektu uwzględniać ma pojawiające się na bieżąco błędy. Nietrudno dojść do wniosku, że żaden z przedstawionych powyżej wariantów nie jest zachę- cający. Fakt ten stanowi najlepszy dowód na to, że zagadnień związanych z obsługą błędów nie powinno się ignorować i czekać z tym do ostatniej fazy cyklu projektowego. W takim ję- zyku jak Java, błędy wiążą się z obsługującą je na poziomie aplikacji infrastrukturą, która swą konstrukcją nie odbiega od innych klas reprezentujących np. procesy biznesowe. Model za- rządzający przesyłaniem komunikatów o błędach może więc być dobrze zaprojektowany, oferując tym samym skuteczny sposób ich raportowania i obsługi. Równie dobrze może też być bezładną, losową i zupełnie nieprzejrzystą zbieraniną bloków VT[ECVEJ, a to na pewno nie pomoże nam w procesie testowania, debugowania i późniejszego zarządzania kodem. W poprawnym planowaniu obsługi wyjątków pomoże nam wiedza wynikająca z dotychcza- sowej praktyki, zebrana jak zwykle w zbiór pewnych zasad. Tych reguł jest w sumie dzie- więć. Mam nadzieję, że pozwolą co najmniej na uniknięcie podstawowych błędów popełnia- nych na etapie projektowania aplikacji: 1. Każda sekwencja stanowiąca pewien sposób użycia aplikacji (przypadek użycia, ang. use case) powinna być przeanalizowana i opisana także z punktu widzenia potencjalnych błędów, jakie mogą się tam pojawić. Scenariusze błędów mogą tworzyć hierarchię, w której uwzględnimy zarówno prawdopodobieństwo danego zdarzenia, jak też jego konsekwencje. Rozdział 6. n Planowanie obsługi wyjątków 101 2. Skuteczne projektowanie metod powinno zakładać, że oprócz podstawowych operacji przez nie realizowanych pojawi się dobrze zdefiniowany zbiór punktów wskazujących na potencjalne problemy. Gdy z metod tych budować będziemy proces lub przypadek użycia, listę potencjalnych błędów tej złożonej operacji określimy na podstawie wchodzących w jej skład metod. 3. Istnieją dwa podstawowe podejścia określające sposób, w jaki zajmować się będziemy potencjalnymi błędami. Pierwszy z nich zakłada napisanie takiego kodu, który do sytuacji nie dopuści. Drugi to odpowiednio zaplanowana obsługa błędu. Może to być zdefiniowany lokalnie zbiór czynności neutralizujących problem lub przesłanie informacji o zdarzeniu na zewnątrz metody, do zawierającego ją komponentu, podsystemu bądź całej aplikacji. 4. Nie należy próbować za wszelką cenę obsługiwać wszystkich możliwych błędów, zwiększy to bowiem znacznie czas potrzebny na napisanie kodu i zmniejszy możliwość jego późniejszym zarządzaniem. Dużo lepiej jest skoncentrować się na scenariuszach prawdopodobnych i trudnych w wielu przypadkach do uniknięcia, a także błędach mogących mieć poważny wpływ na działanie całej aplikacji5. 5. Metoda powinna przekazywać na zewnątrz jedynie te wyjątki, które zasługują na szczególną uwagę innych elementów aplikacji bądź też takie, których obsługa wewnątrz metody ze względu na brak znajomości kontekstu zdarzenia, nie jest wskazana. 6. Metoda powinna zgłaszać wyjątki w formie możliwie zrozumiałej dla ich konsumenta6, biorąc pod uwagę rolę i zadania odbiorcy. 7. Metoda może zgłaszać wiele wyjątków tylko w sytuacjach, gdy: a. wzajemnie się one wykluczają (posiadają różne przyczyny), b. mają inne znaczenie dla odbiorców, c. nie dadzą się połączyć w pojedynczy wyjątek, ponieważ odpowiadają zupełnie różnym scenariuszom błędów. 8. Problemy powinny być obsługiwane lub raportowane jak najszybciej od momentu pojawienia się ich w kodzie. Najlepiej, gdy będzie to w tej samej metodzie, w której zostały zgłoszone. Zwlekanie z ich obsługą może być ryzykowne. W przypadkach, gdy takie odroczenie wydaje się niezbędne z powodu określonych wymogów stawianych przez klasę bądź bibliotekę, należy stworzyć metodę, która pozwoli nam uzyskać dostęp do oczekującego wyjątku. 9. Wyjątki dotyczące każdej jednostki stanowiącej część projektu (klasy, komponentu, modułu czy biblioteki) powinny w sposób jasny i formalny określać warunki, na jakich odbywa się ich współpraca ze światem zewnętrznym. 5 i Unikajmy natomiast błędów, których naprawdę da się uniknąć. Pozostałe problemy postarajmy się zapisać do dziennika. 6 Pod pojęciem „konsument” kryje się każdy odbiorca komunikatu, jakim jest zdarzenie. Może być to zarówno kolejna warstwa aplikacji, jak też użytkownik czytający komunikat wyświetlany na ekranie. Dlatego też nadanie mu zrozumiałej formy jest tak samo ważne w przypadku człowieka, jak innego podsystemu aplikacji. 102 Część II n Planowanie obsługi wyjątków Oczywiście klasy nie są jedyną strukturą w ramach pisanych przez nas aplikacji, na poziomie której należy rozważać i planować obsługę wyjątków. Java pozwala nam także korzystać z in- terfejsów i opisywać za ich pomocą pewne ogólne cechy i zachowania7. Zalecenia dotyczące definiowania wyjątków w ramach interfejsów są nieskomplikowane, chociaż wymagają jeszcze większych zdolności przewidywania niż te, jakimi musimy wykazać się tworząc zwykłe meto- dy. Jeśli interfejs ma uczestniczyć w obsłudze wyjątków, należy dość starannie rozważyć jego użycie w ramach budowanego zestawu klas. Bazując na wymaganiach tworzonej konstrukcji i prawdopodobnych sposobach implementacji interfejsu, jego twórca może przewidzieć i za- deklarować pewne wyjątki zgłaszane przez wchodzące w skład interfejsu metody. Popraw- ne dodawanie deklaracji wyjątków w ramach interfejsów powinno być zgodne z dwiema następującymi regułami: 1. Dobrze zaplanowany interfejs zwykle zgłasza tylko jeden rodzaj wyjątku, chyba że istnieje jakaś wyjątkowa przyczyna uzasadniająca większą ich liczbę. Typowy interfejs reprezentuje określony model bądź ściśle zdefiniowany zestaw zachowań. Dlatego dobrze jest przypisać mu jeden rodzaj wyjątku. 2. Wyjątki zgłaszane przez metody interfejsu powinny bezpośrednio dotyczyć zadań, do jakich interfejs został przewidziany — ich znaczenie musi odpowiadać kontekstowi sytuacji, w której mogą się potencjalnie pojawić. Dlatego też definiowanie interfejsów idzie często w parze z tworzeniem własnych wyjątków. Naturalną cechą interfejsów jest to, że nie definiują one dokładnego zachowania. Ich projektant nie posiada kontroli nad tym, jak dokładnie zostaną one w przyszłości zaimplementowane oraz w jaki sposób użyte zostaną zadeklarowane w metodach interfejsu wyjątki. Osoby wyko- rzystujące w swych aplikacjach biblioteki, w których implementowane są te interfejsy, są w lep- szej sytuacji, mają bowiem wpływ i na generowanie wyjątków, i na ich obsługę. Trudno na- tomiast zazdrościć tym programistom, którzy nie mają wpływu ani na sam interfejs, ani na jego implementację8. Twórcy interfejsu naprawdę trudno dobrać odpowiedni poziom ogólności wyjątków genero- wanych przez metody interfejsu, dlatego też błędy mogą być reprezentowane w sposób bardziej elastyczny. Trafiając na problem tego typu, możemy skorzystać z jednego z takich rozwiązań: 1. Tworzymy interfejs ze stałą listą specyficznych dla niego wyjątków i wymuszamy niejako na osobach odpowiedzialnych za implementację wyrzucanie tylko tych wyjątków (bądź ich podzbioru), które zostały przez nas przewidziane. Jest to zwykle najlepsza opcja, gdy zakładamy narzucenie pewnego standardu posługiwania się interfejsem. Dotyczy to zwykle wyjątków związanych z błędami o średnim oraz wysokim priorytecie. 2. Definiujemy interfejs, który nie deklaruje żadnych wyjątków. Ich obsługa musi więc zostać zawarta wewnątrz implementacji metod. Jest to opcja polecana szczególnie w sytuacjach, gdy zadania interfejsu sprecyzowane są w sposób bardzo ogólny i nie 7 i Interfejs jest czasami porównywany w innych językach programowania do koncepcji „kontraktu”. Interfejsy zwiększają możliwości Javy, pozwalają na reprezentowanie pewnych współdzielonych pojęć i zachowań bez uciekania się do mechanizmu dziedziczenia. 8 Dobrym przykładem problemów tego typu jest biblioteka dostępu do baz danych, czyli JDBC. Twórcy interfejsu nie mieli żadnej kontroli ani nad ich implementacją (tworzone niezależnie sterowniki JDBC), ani nad kodem aplikacji (pisanym przez programistów używających JDBC). Rozdział 6. n Planowanie obsługi wyjątków 103 sposób na tym etapie przewidzieć dalszych szczegółów. Dobrym przykładem jest interfejs 4WPPCDNG, który mówi wyłącznie o tym, że jakieś zadanie będzie uruchomione w odrębnym wątku. Miejmy także na uwadze, że implementując interfejs, zawsze możemy wyrzucić wyjątek wy- wodzący się z klasy 4WPVKOG ZEGRVKQP lub TTQT (może się to zdarzyć w sposób zamierzony bądź przypadkowy). Wymienione wyjątki niekontrolowane stanowią pewien problem przy posługiwaniu się interfejsami. Nie wiemy bowiem, które z nich są celowo generowane przez implementację interfejsu, i kiedy możemy się ich spodziewać. Z tego też powodu dobrym po- mysłem jest obsługa również takich wyjątków, na równi z wyjątkami jawnie zadeklarowanymi. Wskazane jest to szczególnie wtedy, gdy chcemy zagwarantować maksimum bezpieczeń- stwa podczas używania implementacji, których zachowania nie da się w pełni przewidzieć. Projektowanie z uwzględnieniem błędów Przestrzeganie zasad dotyczących skutecznej obsługi wyjątków już na etapie projektowania aplikacji pomoże stworzyć program dużo bardziej niezawodny. Oczywiście możliwe jest bezpośrednie włączenie tych zasad w normalny cykl rozwoju aplikacji. Jeśli na dodatek reguły dotyczące projektowania obiektowego połączymy z zaprezentowanymi wcześniej dobrymi praktykami obsługi wyjątków w pisanym przez nas kodzie, otrzymamy w rezultacie technikę, którą nazwać możemy „projektowaniem z uwzględnieniem błędów”9. Praktyka ta nie jest niczym rewolucyjnym — u jej podstaw leży solidne projektowanie obiektowe, przewidujące jednak i uwzględniające już na tym etapie potencjalne problemy, które mogą wystąpić pod- czas działania aplikacji. Dołączenie wyjątków już podczas projektowania kodu może napraw- dę w znaczący sposób przyczynić się do lepszego zarządzania i łatwiejszego utrzymania aplikacji w przyszłości. Powyższe reguły możemy stosować niezależnie od szczegółów preferowanej przez nas meto- dyki rozwoju oprogramowania. Punktem wyjścia jest analiza modelowanych przez nas proce- sów biznesowych. Model ten definiujemy obecnie najczęściej za pomocą przypadków użycia, ale równie dobrze możemy skorzystać z metod strukturalnych i dekompozycji funkcjonal- nej. Schemat tego procesu, wraz z uwzględnieniem sytuacji wyjątkowych, przedstawiony jest na rysunku 6.110. Oczywiście najlepszym sposobem, by poznać daną technikę i docenić jej walory jest de- monstracja, w jaki sposób jej używać. Dlatego każdą fazę schematu zamierzam zilustrować przykładem. Scenariusz całego rozwiązania zakłada sytuację, w której klient chce za pomo- cą aplikacji sieciowej złożyć zamówienie — zadanie typowe dla wielu współczesnych apli- kacji. Problem będzie bardziej interesujący, jeśli założymy, że zamówienie będzie się mo- gło składać z wielu pozycji, a każda z nich określa dowolną ilość danego towaru. Omówię dokładnie każdy z kroków, opisując czynności z nim związane. 9 i Koncepcja „projektowania z uwzględnieniem błędów” w sposób naturalny zawiera w sobie wszystkie zasady projektowania obiektowego. Należy myśleć o niej jako o połączeniu dotychczas stosowanych praktyk i strategii zakładających uwzględnienie kwestii dotyczących przewidywania i obsługi potencjalnych błędów aplikacji. 10 Doświadczeni twórcy aplikacji często w instynktowny sposób wykonują taką właśnie sekwencję czynności, uwzględniając potencjalne błędy i planując strategię ich obsługi. Jednak do rzadkości należy oficjalne i konsekwentne stosowanie podobnych praktyk w zespołach programistycznych. 104 Część II n Planowanie obsługi wyjątków Rysunek 6.1. Proces tworzenia aplikacji uwzględniający obsługę wyjątków Etap 1. Identyfikacja przypadku użycia Na początku zidentyfikujemy przypadek użycia, który opisuje cały proces. Będą nim operacje, które rozpoczną działanie w chwili, gdy użytkownik zdecyduje się przesłać zamówienie, korzystając z odpowiedniego polecenia przeglądarki internetowej. Oczywiście, zakładamy w tym momencie, że użytkownik doprowadzając do takiego stanu, musiał wcześniej wykonać pewną liczbę czynności (przeglądanie i wybór zamawianych artykułów, określenie sposobu płatności itp.). W modelu UML operacje te traktowane są jako warunki wstępne przypadku użycia (często stanowiące inny przypadek użycia). Diagram przypadku użycia reprezentujący typowe wypełnienie zamówienia widzimy na rysunku 6.2. Rysunek 6.2. Diagram przypadków użycia związanych z systemem realizacji zamówień Rozdział 6. n Planowanie obsługi wyjątków 105 Etap 2. Precyzyjny opis procesu i poszczególnych jego składników Podczas tego etapu definiujemy poszczególne akcje związane z naszym przypadkiem użycia. Krok ten polega przede wszystkim na zrozumieniu, jakie dokładnie operacje należy wykonać i jakiej technologii do tego użyć. Oczywiście, im więcej znamy szczegółów, tym lepiej — po- siadając informacje na temat każdej wykonywanej czynności, jesteśmy w stanie przewidzieć ewentualne błędy. Proces biznesowy zwykle powinien być opisany z uwzględnieniem trzech aspektów: n zadań wykonywanych w ramach aplikacji, n zadań wykonywanych pomiędzy aplikacjami, n stosowanych technologii i bibliotek. Wynik tej pracy warto zapisać za pomocą notacji UML: diagramy sekwencji i diagramy ak- tywności wydają się do tego najodpowiedniejsze. Na początku wystarczy przypadek użycia o nazwie „złożenie zamówienia” podzielić na skła- dające się na niego operacje, tak jak to widać poniżej: Proces: Złożenie zamówienia11. Weryfikacja zamówienia: 1. Sprawdzenie, czy kompletne są wszystkie informacje stanowiące zamówienie. 2. Sprawdzenie danych dotyczących dostawy. 3. Sprawdzenie danych dotyczących płatności. Realizacja zamówienia: 1. Tworzenie zamówienia i rezerwacja towaru. Obliczenie ceny końcowej. Sfinalizowanie zamówienia. Patrząc na nasz model biznesowy z innej perspektywy, możemy wskazać te miejsca, które odpowiadają za współpracę z systemami zewnętrznymi: n baza danych towarów (krok 4,, rezerwacja towaru); n baza danych zamówień (krok 4., akceptacja zamówienia); n usługa obsługująca płatność (kroki 3. i 6., operacje finansowe); n usługa związana z dostarczeniem towaru (krok 6., finalizowanie zamówienia). i 11 W przykładzie zakładamy, że pewna wstępna weryfikacja zamówienia ma miejsce jeszcze przed jego złożeniem. Za tą „wczesną walidację” odpowiadać może któraś z wcześniejszych faz procesu, może się to odbywać jeszcze po stronie przeglądarki. My w każdym razie planujemy wykonanie jedynie „później walidacji”. 106 Część II n Planowanie obsługi wyjątków Wiedza na temat tych systemów pozwala zidentyfikować technologie i protokoły komunika- cyjne, które najprawdopodobniej będą używane w aplikacji. To z kolei znowu przybliża nas do wskazania możliwych problemów w ramach realizacji przypadku użycia. W naszym przy- kładzie do obsługi baz danych wykorzystamy najprawdopodobniej bibliotekę JDBC. Wybór API, za pomocą którego będziemy się komunikowali z pozostałymi systemami zależy od sposobu, w jaki oferują one swoje usługi. W przypadku przesyłania komunikatów będzie to najprawdopodobniej JMS, usługi sieciowe to JAXM lub JAX-RPC. Rysunek 6.3 prezentuje diagram aktywności zawierający sześć zdefiniowanych przed chwilą zadań. Możemy traktować go jako model procesu widziany na średnim poziomie szczegółowości. Rysunek 6.3. Diagram aktywności dla przypadku użycia „złożenie zamówienia” Zauważ, że dwie pierwsze fazy procesu odpowiadają czynnościom, które każdy zespół pro- jektowy musi przeprowadzić. I to niezależnie od tego, czy traktowane są one jako ściśle prze- strzegane fazy zdefiniowane w którejś z metodyk, czy też jako intuicyjny i naturalny etap nie- zbędny podczas tworzenia działającego systemu. Kolejna, trzecia faza korzysta z wyników fazy pierwszej i drugiej. Pozwala nam ona zdobytą wiedzę wykorzystać w celu lepszego zi- dentyfikowania potencjalnych błędów, które mogą pojawić się w czasie eksploatacji aplikacji. Etap 3. Identyfikacja potencjalnych błędów i ocena ich ryzyka Gdy proces biznesowy zaczyna przybierać realny i stabilny kształt, możemy rozpocząć wy- szukiwanie podstawowych błędów, które mogą zagrozić całej operacji. Jak już wspominałem, problemy dotyczące przypadku użycia w naturalny sposób związane będą z samym procesem, stosowanymi technologiami i współpracującymi systemami. Zrozumienie poszczególnych Rozdział 6. n Planowanie obsługi wyjątków 107 zadań składających się na proces znacznie pomaga nam uświadomić sobie, jakie ryzyko niesie każde z nich. A znając to ryzyko, możemy przypisać mu priorytet i zastanowić się nad strategią obrony. Znajomość określonych technologii lub API używanych podczas realizacji pozwala jeszcze dokładniej sprecyzować prawdopodobne błędy. Java jest pod tym względem doskonałym językiem, ponieważ miejsca zgłoszenia dużej części błędów definiowane są jawnie w nagłów- kach wywoływanych metod. Znajomość używanego API wiąże się z precyzyjną identyfikacją potencjalnych problemów. Co więcej, umiemy przyporządkować je określonym metodom. Wróćmy teraz do sześciu zadań opisanych już w punkcie 2., starając się tym razem przewidzieć i wyszukać potencjalne źródła błędów: 1. Sprawdzenie, czy kompletne są wszystkie informacje stanowiące zamówienie Operacje: Wewnętrzna weryfikacja w ramach obiektów aplikacji Czynniki ryzyka: Uszkodzenie danych systemu Ocena ryzyka: Niskie Operacja weryfikuje kompletność danych stanowiących zamówienie — sprawdzane są da- ne klienta, lista zamówionych towarów, sposób dostawy i szczegóły dotyczące płatności. Do wykonania tych czynności nie jest konieczne żadne złożone API i odwoływanie do ze- wnętrznych systemów, dlatego jest to operacja o niewielkim stopniu ryzyka. Podstawowe niebezpieczeństwo wiąże się ze zniszczeniem danych. Ten typ ryzyka wskazuje na potrzebę upewnienia się, że reguły biznesowe są poprawnie stosowane, co wymaga wykonania okre- ślonych testów w czasie cy
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Java. Obsługa wyjątków, usuwanie błędów i testowanie kodu
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ą: