[ Pobierz całość w formacie PDF ]
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 p0tencjalnych błędów i 0cena 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
R0zdział 6. Plan0wanie 0bsł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 zródła błędów:
1. Sprawdzenie, czy k0mpletne są wszystkie inf0rmacje stan0wią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 cyklu projektowego.
2. Sprawdzenie danych d0tyczących d0stawy
Operacje: Wewnętrzna reguła biznesowa
Czynniki ryzyka: Uszkodzenie danych, nieprawidłowy przepływ sterowania
Ocena ryzyka: Niskie
Kolejna operacja wykonywana wewnętrznie. Chociaż reguła sprawdzająca poprawność
może być bardziej złożona od poprzedniej (sprawdzenie sposobu dostawy i weryfikacja da-
nych adresowych), czynność ta nie wiąże się z poważnym ryzykiem utraty integralności
danych. Oczywiście pewność taką uzyskamy dopiero po wykonaniu odpowiedniej liczby
szczegółowych testów.
3. Sprawdzenie danych d0tyczących płatn0ści
Operacje: Wewnętrzna reguła biznesowa, zewnętrzna weryfikacja
Czynniki ryzyka: Komunikacja w środowisku rozproszonym, uszkodzenie danych, nieprawi-
dłowy przepływ sterowania
Ocena ryzyka: Zrednie
108 Część II Plan0wanie 0bsługi wyjątków
Operacja obarczona jest większym ryzykiem niż dwie poprzednie. Weryfikacja informacji
dotyczących płatności realizowana jest na zewnątrz systemu, dlatego istnieje prawdopodo-
bieństwo awarii związanej z komunikacją pomiędzy systemami. Co więcej, błąd pojawiający
się na tym etapie może pózniej odbić się niekorzystnie na całym procesie zamawiania. Jednak
ewentualny problem nie stanowi zagrożenia dla danych systemu i dotyczy wyłącznie poje-
dynczego zamówienia. Dlatego też ryzyko operacji oceniamy na średnie.
4. Tw0rzenie zamówienia, rezerwacja t0waru
Operacje: Proces biznesowy, współpraca z bazą danych
[ Pobierz całość w formacie PDF ]