Roz14.pdf

Rozdział 14

RENTMAN- po narodzinach

Zakładamy, że skompletowaliście Państwo program RENTMAN zgodnie z planem

opracowanym we wcześniejszych rozdziałach książki. Faza analizy, planowania

i konstruowania aplikacji jest w zasadzie za nami.

Zgodnie z założonym, pięciofazowym modelem pracy nad aplikacją, pozostały

nam jeszcze etapy testowania i konserwacji. Zbadamy i omówimy liczne problemy

związane z życiem aplikacji po jej skonstruowaniu.

Testowanie aplikacji

Istnieją liczne sposoby testowania programów i zapewniania ich jakości, jednakże

kilka ogólnych wytycznych pozostaje prawdziwymi, niezależnie od założonej

drogi postępowania. Oto wskazówki, odnoszące się do testowania aplikacji:

Należy stwierdzić, czy program realizuje całkowicie założone wcześniej

zadania. Nie ograniczajmy się jedynie do wyszukiwania typowych błędów

w oprogramowaniu („pluskiew”); pełny proces sprawdzania wymaga spojrzenia

na aplikację jak na wielki obraz, powinniśmy wiedzieć, co program miał robić,

kiedy go planowaliśmy i porównać z efektem końcowym.

Przyjrzyjmy się kluczowym funkcjom, które program ma realizować

i zastanówmy się, czy aplikacja spełnia swoje zadania, czy jej funkcje są

realizowane tak, jak zaplanowaliśmy. Należy również przemyśleć sposób

zbadania, wjaki każda funkcja realizuje przypisane jej cele. Rzetelne

testowanie wymaga porównania aplikacji zoryginalną specyfikacją jej

właściwości.

Po autorskiej weryfikacji należy przeprowadzić zarówno testy wewnętrzne, jak

i zewnętrzne. Wewnętrzne są prowadzone przez autora i jego zespół programistów.

Zewnętrzne mogą wykonywać ludzie z tej samej grupy, lecz w żaden sposób nie

związani z projektem (członkowie grupy prowadzącej beta testy oraz wszelkie inne

zespoły spoza przedsiębiorstwa). Oto kilka wskazówek przydatnych przy

prowadzeniu testów wewnętrznych:

Sprawdzić, czy więzy nałożone na bazę danych są realizowane prawidłowo.

434

Część II

Sprawdzić obiekty umiejscowione na serwerze, takie jak procedury pamiętane

( stored procedures ) i perspektywy ( views ), upewniając się, czy wykonują

założone zadania.

Przetestować działanie programu podczas pracy z wieloma użytkownikami.

Zweryfikować, czy zdefiniowane prawa dostępu prawidłowo sterują

uprawnieniami.

Sprawdzić program na komputerze możliwie jak najbardziej podobnym do

maszyny użytkownika.

Poniższa lista zawiera kilka dodatkowych wskazówek do testów zewnętrznych:

Ustalić sformalizowaną procedurę raportowania obłędach wprogramie

i zasadach reakcji na takie informacje.

Zaplanować sposób łatwej dystrybucji aktualizacji i pakietów poprawiających

błędy.

Zapewnić pomoc techniczną ludzi nie związanych z testowaniem aplikacji.

Ustanowić małą grupę kluczowych użytkowników do prowadzenia beta testów.

Prowadzić testy przydatności z użytkownikami o różnym poziomie

zaawansowania.

Pamiętać, że to użytkownicy decydują, czy aplikacja im odpowiada oraz spełnia

ich Szczegółowa analiza zewnętrznego testowania programów wykracza poza

ramy tej książki.

Pierwsze i najważniejsze pytanie: Czy aplikacja realizuje zadanie, do którego

została zaprojektowana? W rozdziale 8 określono przeznaczenie programu

RENTMAN: ma być systemem ułatwiającym zarządzanie wynajmowanymi

nieruchomościami.

Czy program wywiązuje się z postawionego zadania? Wydaje się, że tak, ale

jedynie Allodium może naprawdę stwierdzić, czy aplikacja robi to w stopniu

przynajmniej dostatecznym.

Przejdźmy do funkcji kluczowych. Zgodnie z tym, co napisano w rozdziale 8,

aplikacja powinna:

Umożliwiać zapisywanie i konserwowanie danych o wynajmie nieruchomości.

Pozwalać na śledzenie realizacji prac związanych z ich utrzymaniem.

Umożliwiać rozliczanie najemców.

Dostarczać informacji o historii nieruchomości.

RENTMAN- po narodzinach

435

I znów musimy stwierdzić, że RENTMAN wydaje się spełniać wszystkie założone

funkcje oraz że jedynie Allodium może w pełni ocenić w jakim zakresie.

Przed rozpoczęciem testowania aplikacji przyjrzyjmy się oddzielnie każdej

wskazówce do przeprowadzania kontroli wewnętrznej, i zobaczmy, jak mogą być

one zastosowane w przypadku programu RENTMAN.

Sprawdzić więzy nałożone na bazę danych aplikacji

Należy sprawdzić (próbując je złamać), czy nałożone więzy istnieją, są wzajemnie

spójne i działają zgodnie z założeniami. Przy sprawdzaniu programu RENTMAN

powinniśmy spróbować:

Usunąć z pliku tabeli LEASE najemców, którzy utrzymują dzierżawę.

Wprowadzić do pola City tabeli PROPERTY wartość inną niż Richardson,

Dallas, Plano, Norman, Oklahoma City i Edmond.

Usunąć z tabeli PROPERTY rekord, opisujący nieruchomość, która zgodnie

z danymi z tabeli LEASE jest aktualnie wynajmowana.

Pominąć pole Deposit przy wprowadzaniu danych do tabeli PROPERTY.

Wprowadzić niewłaściwą datę do pola StartDate tabeli WORDER.

Dodać do tabeli PROPERTY nieruchomość mającą sześć sypialni.

Nie ma chyba wątpliwości, na czym polega ten etap testowania. Sprawdzamy

warunki konieczne poprawnego działania aplikacji, nałożone poprzez więzy bazy

danych.

Sprawdzić obiekty umiejscowione na serwerze

Jeśli zaimplementowany program wykorzystuje procedury pamiętane ( stored

procedures ), perspektywy ( views ) lub inne obiekty umiejscowione na serwerze, to

należy sprawdzić ich pracę. Testowanie systemów klienta jest dla wszystkich

oczywiste, tymczasem konieczność kontroli działania obiektów osadzonych na

serwerze jest przez wielu programistów aplikacji klient/serwer zaniedbywana lub

minimalizowana. A przecież SQL jest językiem, takim samym jak Object Pascal

czy C++. Oto kilka spraw, na które należy zwrócić uwagę:

Jeśli mamy zbudowany raport końcowy, który jest produkowany przez

procedurę pamiętaną lub inny obiekt umiejscowiony na serwerze, to należy

uruchomić procedurę poza aplikacją lub kreatorem raportów, aby się upewnić,

że działa zgodnie z oczekiwaniami. Nawet jeśli sprawdziliśmy pracę procedury

za pośrednictwem naszego programu, to uruchomienie jej bezpośrednio

pozwala zobaczyć ewentualne komunikaty serwera oraz inne informacje, które

436

Część II

mogą być ignorowane przez aplikację lub oprogramowanie dostępu do bazy

danych.

Jeśli wykonujemy operacje DML ( Data Manipulation Language - język

operowania danymi), wykorzystując procedury pamiętane, to powinniśmy

dokonać zabronionych dla bazy danych lub procedury prób modyfikacji danych

(np. wprowadzić błędną wartość). Umieszczając w procedurach pamiętanych

elementy oprogramowania typu DML, bierzemy odpowiedzialność za

upewnienie się o ich poprawnym działaniu.

Przeprowadzanie testów w środowisku wielodostępnym

Implementując system wielodostępny, musimy uwzględnić przede wszystkim dwa

czynniki. Pierwszy to współbieżność. Duża liczba użytkowników próbujących

uzyskać dostęp do tych samych zasobów bazy danych może powodować

różnorodne problemy, zktórych najważniejsze związane są zzatorami

i blokowaniem dostępu. Użytkownicy mogą sobie wzajemnie blokować dostęp do

zasobów, których potrzebują. Za zatory mogą być również odpowiedzialne

działające w systemie procesy.

Drugim wyzwaniem, stawianym przez środowisko sieciowe, są ograniczenia

zasobów systemu. Układ poprawnie działający przy dziesięciu użytkownikach

może zawieść, gdy korzysta z niego dwadzieścia osób. Podłączenie się każdego

nowego użytkownika obciąża system, nawet jeśli w danej chwili nie korzysta on

z zasobów i nie blokuje połączeń. Istnieją po prostu fizyczne ograniczenia

spowodowane wydajnością przetwarzania danych przez serwer, szybkością

transmisji, oraz maksymalną liczbą transakcji możliwych do zrealizowania w sieci.

W czasie przeprowadzania testów powinno się przyjąć najgorszy scenariusz (jeśli

w systemie docelowym nie będzie pracowało więcej niż dwustu użytkowników, to

w czasie weryfikacji aplikacji należy ją sprawdzać przy czterystu odbiorcach).

Istotną sprawą jest zbadanie granic możliwości konstruowanego systemu. Planując

wydajność aplikacji warto się oprzeć na oszacowaniu zasobów dostępnych dla

użytkownika.

Sterowanie współbieżnością i model klient/serwer

Dostęp do danych na serwerze SQL, inaczej niż w lokalnych bazach danych, nie

jest zazwyczaj możliwy na zasadzie rekord po rekordzie. Niektóre serwery nie są

nawet w stanie blokować dostępu do pojedynczych wierszy, blokowane są większe

obiekty: strony lub segmenty celem zabezpieczenia przed zakłóceniami podczas

modyfikowania danych przez użytkownika.

Uniemożliwia to innym użytkownikom jakiekolwiek zmiany w zbiorze.

RENTMAN- po narodzinach

437

Programista musi wiedzieć, wjaki sposób jest realizowane sterowanie

współbieżnością na platformach DBMS. Powinniśmy ograniczać do minimum

liczbę zatorów. Za wszelką cenę należy unikać przetwarzania danych rekord po

rekordzie. Rozważmy poniższą procedurę, służąca do modyfikacji tabeli LEASE

i ustawiania wartości danych z kolumny LawnService na False :

With taLease do

While not EOF do begin

If taLEASEPetDeposit.AsFloat<>0 then

taLEASELawnservice.AsBoolean:=False;

Next;

end;

To standardowe na lokalnych tabelach rozwiązanie jest jednak powodem

problemów na serwerach baz danych, bowiem powoduje zablokowanie tabeli

Lease w trakcie modyfikacji pola LawnService. Zamyka na chwilę dostęp do

danych dla innych użytkowników i działa relatywnie wolno. Zachodzi również

możliwość, że serwer rozszerzy blokadę rekordów lub strony na całą tabelę,

uniemożliwiając na czas jej trwania jakikolwiek dostęp do tabeli dla innych

użytkowników.

Aby wykonać podobne aktualizacje, należy stosować SQL: zarówno procedury

pamiętane, jak izwykłe zapytania. Należy trzymać się zasady: „Unikać

indywidualnego przetwarzania rekordów”. Niech robi to serwer, tak jest lepiej.

Oto zapytanie w języku SQL, które wykonuje to samo zadanie:

UPDATE LEASE

SET LawnService=’F’

WHERE PetDeposit<>0 AND LawnSerwice<>’F’

Zadanie zostanie wykonane wjednym przejściu, ablokady (blokada) będą

zwolnione tak szybko, jak to jest możliwe.

Transakcje i serwery baz danych

Przypomnijmy, że transakcja to grupa zmian bazy danych przetwarzana jako

pojedyncza porcja ( batch ). Zmiany są wykonywane albo w komplecie, albo wcale.

Zostało to zaimplementowane przy wykorzystaniu protokołów odtwarzania

transakcji ( transaction/redo logs ). Prawidłowe określenie rozmiaru protokołu

transakcji, ostrożność, aby nie przekraczać ich obszaru, wydajne zapisywanie

i odtwarzanie transakcji - to tylko niektóre realne problemy, które muszą być brane

pod uwagę przez projektanta aplikacji klient/serwer.

Delphi umożliwia sterowanie transakcjami, opartymi na serwerze, poprzez

komponent TDatabase . Aby rozpocząć transakcję, należy wywołać metodę

StartTransaction , do jej zakończenia metodę Commit , a do odtworzenia

Rollback . Wywołanie tych metod w środowisku klient/serwer daje ten sam

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: