rozdział 1

Testowanie programów

1. Testowanie programów

1. Cel ćwiczenia

Celem ćwiczenia jest zapoznanie się z wybranymi metodami testo­wania oprogra­mo­wania i typowymi środkami pomocnymi w testowa­niu oraz wykorzystanie ich w praktyce, w wybranym systemie progra­mowania.

2. Podstawy teoretyczne

Każdy program powinien być przede wszystkim niezawodny. Pojęcie nieza­wodności można rozumieć, w pewnym uproszczeniu, jako brak po­datności na awarie oprogramowania. Przyjmijmy jako defini­cję awarii określenie sfor­muł­owane przez J. Goode­nougha:

Awaria to każdy efekt lub zacho­wanie, którego wystąpienie jest niedo­pu­szczal­ne w normalnych warunkach działania, gdzie to, co „niedo­pu­szczalne” i „nor­malne”, musi być określone dla każdego syste­mu.

Wówczas przykładami awarii mogą być błędne wyniki lub brak wyników, zmniejszenie efektywności programu (zaskakująco długie przetwarzanie dla pewnych danych) lub niszczenie danych użytkownika. Działania takie mogą być spowodowane błędami w strukturze programu lub niepoprawnym wypeł­nianiem specyfikacji.

Niezawodność łączy się ściśle z poprawnością programu. Najogólniej można po­wie­dzieć, że program jest poprawny, jeżeli zawsze działa zgodnie z sensownymi oczekiwaniami użytkownika i intencją programisty. Definicja taka jest bardzo ogólna i elastyczna, bo bazuje na pojęciach wysoce subiektywnych. Program prawidłowo zaprojektowany i napisany powinien być zgodny ze swoją specyfikacją. Należy więc upewnić się, czy badany program istotnie tę specyfikację spełnia. Z drugiej strony, czasami sama specyfikacja może nie obejmować pewnych sytuacji lub być niedoskonała albo niespójna w inny sposób, i wówczas w pełni z nią zgodny program także może ulec awarii. Należy więc sprawdzić i specyfikację.

3. Definicja testowania

Testowanie jest to zbiór czynności wykonywanych z intencją wykry­cia w programie jak największej liczby błędów. Jednym z jego głównych składników jest obserwacja zgodności produkowanych przez program wyników z wcześniej przygotowanymi poprawnymi wyni­ka­mi odniesienia. Proces ten może prowa­dzić do uznania, że dany program działa poprawnie we wszystkich przypadkach, w których ma działać, lub do wykrycia błędu.

Celem testowania programu jest upewnienie się, że program rozwią­zuje to zadanie, do którego został zaprojektowany, i że w każdych warunkach daje poprawne wyniki. Jest to proces różny od procesu uruchamiania programu. Program uruchomiony nie zawiera błędów sygnalizowanych przez translator i jawnie niepoprawnych fragmentów kodu oraz daje jakieś wyniki. Czy wyniki te są poprawne, zgodne z oczekiwaniami ustalonymi w specyfikacji, pozwala ocenić tes­towanie.

Nie jest możliwe dokładne określenie, jak powinno przebiegać testowa­nie konkretnego programu. Można jednak sformułować kilka wskazó­wek dotyczących organizacji procesu testowania, które mogą pomóc w prawi­dłowym przetes­towa­niu programu.

Należy dążyć do:

• sprowokowania błędu, tzn. stworzenia sytuacji, w której błąd może się ujawn­ić (odpo­wie­dnie środowisko, dobrane dane testowe, przygotowane poprawne wyniki od­niesie­nia);

• sporządzenia dokładnego opisu okolicz­ności, które doprowadzi­ły do błędu, co umożliwi przejście do fazy uruchamiania w celu poszuki­wania przyczyny niewłaściwej pracy programu.

Określając granice procesu testowania trzeba wspomnieć o licz­bie wykonywanych testów. Chcąc starannie przetestować cały program, należałoby wykonać testowanie gruntowne. Polega ono na wykonaniu programu dla wszystkich możliwych kombinacji danych wejściowych. Jest to prawie zawsze niemożliwe ze względu na niezbędny w tym celu czas i wysiłek, choć byłby to jedyny sposób udowodnienia całkowitej poprawności programu. W praktyce, ze względu na efektywność testowa­nia, należy stosować możliwie małą, lecz dostateczną liczbę zestawów danych tes­towych, przy czym powinny być one dobie­rane z odrobiną wyobraźni i podej­rzli­wości w stosunku do działania programu. Mimo istnienia wielu formalnych metod, w praktyce programista powinien bazować w znacznym stopniu na swoim sprycie i intuicji.

Testując dany program nal­eży przeprowadzić dwa rodzaje testów. Po pier­wsze, trzeba przekonać się, czy program rea­lizuje właśnie to zada­nie, które zosta­ło sformułowane. Po wtóre, nale­ży uzyskać pewność, że działa poprawnie.

Możliwe są dwa skrajnie odmienne podejścia do testowania progra­mu: względem struktury wewnętrznej (kodu) i względem specyfikacji zewnętrznej.

Można jako podstawę w cza­sie testowania potraktować kod programu. Wtedy zabezpie­czymy się przed błędami wykonania (ang. run-time errors) i wszystkie instrukcje będą się wykonywały poprawnie, jednak nie wykryjemy faktu, że program jest niezgodny ze spe­cy­fi­kacją, tzn. robi nie to, co należało.

Jeśli zaś nie będziemy inte­resować się kodem, możemy testowaniem objąć jedynie spe­cyfika­cję. Wówczas mamy sytuację odwrotną - jeżeli umiejętnie dobierzemy dane testowe, możemy wy­kryć wiele błędów logicznych, jednak nie możemy gwarantować, że program nie zakończy się błę­dem wykonania. Wynika stąd, że dla właści­wego przetestowania programu konieczna jest znajo­mość i sprawdzenie zarówno specyfikacji, jak i kodu programu.

1. Testowanie struktury wewnętrznej

Przy testowaniu struktury wewnętrznej pojedynczego modułu (testowaniu względem kodu) konieczna jest znajomość tekstu źródłowego programu. Generalnie przyjmuje się, że warun­kami koniecznymi zakończenia testowania względem kodu są:

1. Doprowadzenie do wykonania każdej instrukcji co najmniej raz, lub - równoważnie - do przejścia każdej z gałęzi przepływu sterowania w module. Chodzi o to, aby każdy wa­runek (punkt w programie, gdzie sterowanie rozgałęzia się, czyli zaczyna się nowa ga­łąź) podczas wykonywania testów przyjął wartość zarówno prawda, jak i fałsz. Trudno powiedzieć, ile razy należy powtórzyć wykonanie programu, aby powyższe warunki spełnić - zależy to od za­dania, które program wykonuje.

2. Wykonanie wnętrza każdej pętli minimalną liczbę razy, małą liczbę razy oraz bardzo dużą (lub maksymalną, o ile można taką określić) liczbę razy. Osiąga się to przez dobór od­powiednich danych testowych.

Przygotowując dane testowe dla testowania względem kodu korzystamy z diagramów prze­pływu sterowania (DPS) i tworzonych na ich podstawie macierzy pokrycia gałęzi. Tech­nika posłu­giwania się nimi została przedstawiona w Dodatku A. Szerzej o zasadach doboru danych testowych traktuje punkt 1.6.

1. Testowanie specyfikacji zewnętrznej

W przypadku testowania specyfikacji zewnętrznej program traktujemy jako „czarną skrzynkę”. Znamy jedynie liczbę i rodzaj danych podawanych na wejściu, liczbę i rodzaj da­nych wyjściowych oraz zdefiniowaną w specyfikacji zależność pomiędzy danymi wejścio­wymi a wyjściowymi.

W tym przypadku dobór danych testowych, a szczególnie moment, w którym uznamy te­stowa­nie za zadowalające i wiarygodne, w jeszcze większym stopniu zależy od doświadcze­nia i intuicji testującego. Wskazówki na temat doboru danych testowych znajdują się w punkcie 1.6.

W czasie przygotowywania zestawów danych testowych należy brać pod uwagę:

• specyfikację zewnętrzną programu,

• funkcje realizowane przez program,

• strukturę programu,

• przepływ sterowania.

1. Testowanie programu

Testowanie programu trzeba rozpoczynać bardzo wcześnie, właściwie już na etapie projektowania. Należy przede wszystkim sprawdzić, czy poprawnie zaprojektowano rozwiąza­nie sformułowanego zadania, to znaczy, czy program będzie rzeczy­wiście rozwiązywał takie zadanie, jakie należy, i czy wzięto pod uwagę wszystkie przypadki bez niejednoznaczności. Można to zrobić jeszcze przed rozpo­częciem kodo­wania za pomocą „ręcznej symulacji” przygotowa­nego algorytmu. Pomocny tu jest udział klienta zlecającego wykonanie programu. Nazywamy to testowaniem specyfi­ka­cji lub projektu.

Testowanie projektu pozwoli na uniknięcie poważ­niejszych błędów wynika­jących z niejasności lub niekonsekwencji w sfor­mułowa­niu zadania i specyfi­ka­cji zewnętrznej programu.

W czasie pisania programu należy pamiętać, że będzie on testo­wa­ny. Struktura programu powinna być taka, by jego testowanie (także testo­wa­nie poszczególnych fragmentów) było łatwe. Jeśli dla wygody testowa­nia do pro­gramu źródłowego wstawia się dodatkowe instrukcje, to należy je odpo­wiednio skomen­to­wać. Wygodnie jest je umieszczać wewnątrz dyrektyw kompilacji warunkowej. Po sprawdzeniu poprawności programu będzie je można bez kłopotu usu­nąć lub dezaktywować.

Testowanie modułów (procedur, fragmentów programu) przeprowadza się poje­dyn­czo, w środowisku nie korzystającym z innych modułów, także przed powsta­niem tych innych modułów. Jeżeli testowany moduł odwołuje się do modułów, które jeszcze nie istnieją, stosuje się symulację tych brakujących części systemu lub programu. Można tu wykorzystać moduły - makiety posiadające jedynie punkt wejścia i punkt po­wrotu oraz jakąś instrukcję sygnalizującą fakt wywołania modułu. Innym roz­wiąza­niem jest utworzenie modułu zastępcze­go realizujące­go w sposób uprosz­czony niezbędne do testowania funkcje.

Jeżeli testowaniu podlega oprogramowanie numeryczne, należy pamię­tać o sprawdzeniu zachowania się modułu w przypadkach:

• błędnych danych wejściowych (dla każdego modułu);

• ograniczonego zakresu dokładności obliczeń związanych z nie­skoń­czonymi procesami matematycznymi (występuje to w przypa­dku stoso­wania algorytmów nume­rycznych, np. rozwija­nie funk­cji w sze­regi nie­skończo­ne);

• błędów zaokrągleń maszyny cyfrowej.

Testowanie modułu polega głównie na znalezieniu rozbież­no­ści między logiką i pośrednictwami modułu a jego specyfi­kacją. Podczas testowania modułów wy­korzystuje się często diagramy przepływu sterowa­nia. Szersze informacje na ten temat znaj­dują się w dodatku A.

Testowanie integracyjne (test scalania) jest weryfikacją pośre­dnictw między częściami systemu (także programu). Przeprowadza się je na ogół po napisaniu całości lub znacznej części systemu.

Sprawdzenie zgodności zachowania się programu (wszystkich funkcji ze­wnętrzny­ch) z je­go specyfikacją zewnętrzną odbywa się w czasie testowa­nia funk­cjo­nal­nego. Wy­ma­gana jest do tego dokładna specyfi­kacja ze­wnętrzna. Testowanie opiera się na wykonywaniu pro­gramu z uwzględnieniem wszystkich warunków wejściowych i opcji oraz na badaniu zachowa­nia się poszcze­gólnych funkcji na grani­cach dziedzin wejściowych i wyniko­wych. Sprawdza się także wyniki dla niepo­prawnych lub nie­spo­dziewanych danych. Do pro­jek­to­wa­nia zesta­wów danych wykorzystywanych w teś­cie funkcjona­lnym stosuje się czasem grafy przyczynowo-skutkowe (por. [1]).

W przypadku sprawdzania poprawności działania systemu ko­niecz­ne jest jeszcze wykonanie testów systemu, testów akceptacyj­nych i insta­lacyj­ny­ch.

Testowanie systemu polega na wykonywaniu programu w środo­wis­ku sztucz­nym (symulowanym) lub rzeczywistym i próbie wykrycia błędów lub niezgodności w stosunku do celów początkowych produktu. Celami początkowymi produktu mogą być takie wytyczne, jak przenośność kodu, użycie określonego typu komunikacji z użytkownikiem (typu Windows, Turbo Vision) itd.

Podczas testowania akceptacyjnego wykonuje się program w śro­do­wisku rzeczywistym i kontroluje zgodność jego działania z wyma­ga­niami użyt­kownika, który tym razem sam wykonuje test na przygotowanych przez siebie danych. Często jednocześnie konfrontuje się dokumen­tację użytkową z zachowaniem się systemu.

Testowanie instalacyjne polega na wykrywaniu błędów popełnio­nych pod­czas instalowania systemu w środowisku, w którym przewidy­wane jest jego używa­nie.

1. Metody testowania

Istnieją dwie przeciwstawne koncepcje dotyczące testowania systematycznego:

• testowanie tradycyjne, metodą wstępującą - syntetyczną,

• testowanie nowocześniejsze, metodą zstępującą - analityczną.

Możliwe są metody wprost wynikające z jednej i drugiej koncepcji, jak również wiele praktycznie stosowanych metod, które są w mniejszym lub większym stopniu kombinacjami dwu podstawowych, i których wady i zalety są w związku z tym kombinacjami wad i zalet metod podstawowych. W metodach testowania systematycznego przeplatają się elemen­ty scharakteryzowanego w poprzednim punkcie testowania integracyj­nego i testowania składowych.

Trudno jest ściśle określić, który ze sposobów testowania progra­mu jest najlepszy. Za­leży to od konkretnego projektu, wiel­koś­ci i złożo­no­ści pro­gramu bądź systemu. Wyboru musi dokonać testujący, kierując się przy tym znajomością technicznej realizacji projektu oraz zasobami czasu i środ­ków wspomaga­jących tes­towanie, jakimi dysponuje.

Poniżej opisano w sposób ogólny kilka głównych metod testowa­nia.

1. Testowanie wstępujące

Metoda opiera się na sukcesywnym pisaniu i testowaniu fragmentów programu w kolejności od dołu do góry. Najpierw pisane i testowane są moduły najniższego poziomu, potem moduły poziomu bez­po­średnio wyższego, i tak dalej, aż do głównego modułu programu, na którym cykl prac się kończy. Moduły wyższego rzędu są testo­wane, gdy sprawdzone są już moduły rzędu niższego.

Wadą takiego podejścia jest możliwość bardzo późnego ujawnie­nia się poważnych błędów całego projektu i pośrednictw. Skutkiem tego może być konieczność zmiany koncepcji pod sam koniec realizacji proje­ktu. Oprócz tego trzeba także tworzyć środowisko testowe (obwody sterujące i odpowiednie dane) dla każdego sprawdzanego modułu. Obwodem sterującym nazywamy krótki program, który pozwala na przetestowanie modułu przez zadanie określonych danych wejściowych, wywołanie wszystkich procedur modułu i obserwację dostarczonych przez nie wyników. Tworzenie obwodów sterujących i danych testowych powoduje wzrost kosztu projektu, jednak w przypadku elementów najniższego poziomu - procedur - trudno sobie wyobrazić rezygnację z ich przetestowania w krótkim programie przed włączeniem do dużego projektu.

2. Testowanie zstępujące

Metoda jest ściśle związana z techniką projektowania i kodowa­nia zstę­pującego. Testowanie zstępujące opiera się na zasa­dzie sprawdzania i łączenia fragmentów programu w  kolejności z góry na dół. Testuje się najpierw program główny, używając zaśle­pek zamiast do­tychczas nie zakodowa­nych modułów niższego pozio­mu. Kolejne fazy testowa­nia polegają na wykony­wa­niu programu przy stop­niowym dołączaniu pełnych wersji wywoływa­nych modułów. Proces jest powta­rzany do momentu złożenia i przetesto­wania wszystkich modułów.

Zaślepka (namiastka) modułu jest zastępczym modułem realizującym funkcje modułu właściwego w sposób uproszczony. Uproszczenie to może być mniejsze lub większe. Najbardziej uproszczony kod zaślepki może się ograniczać tylko do dostarczania pewnych prawidłowych, ustalonych lub łatwo wyznaczalnych wartości, lub wypisywania komunikatu.

Zaletą testowania zstępującego jest brak konieczności tworzenia programów testujących. Nie trzeba także opracowywać nowych danych testowych dla każdego modułu - wystarczy do istnie­ją­cego zestawu dodać dane dla kolej­nych badanych modułów. Tes­towanie zstępu­jące umożliwia także wczesne spraw­dzenie kompozycji programu i po­średnictw międzymodułowych. Poza tym, łącząc w sobie elementy testów modułów, testów scalania, a częściowo także testów funkcjo­nalnych, skraca czas powstania systemu.

Metoda ta jednak ma również wady. Testujący, podając testowe dane wejściowe dla całego systemu, nie ma bezpośredniego wpływu na dane przekazywane sobie przez poszczególne moduły, a w szczególności nie może spowodować wywołania konkretnej procedury z wszystkimi wartościami danych, jakie go interesują. Zamiast obwodów sterujących należy stwarzać zaślepki (rolę globalnego obwodu sterującego pełni szkielet modułu głównego). Ponadto może się także okazać, że napisanie zapla­no­wa­nego modułu niższego poziomu nie jest możliwe, a późne stwier­dze­nie tego faktu prowadzi do poważ­nych kłopotów.

3. Zmodyfikowane testowanie zstępujące

Metoda ta łączy w sobie zalety dwu poprzednich. Jest podobna do testowania zstę­pujące­go, przy czym wymaga osobnego przetestowania każdego modułu przed jego włączeniem do programu (czyli tak, jak w metodzie wstępującej).

W tym przypadku zaletą jest, nie występująca w zwykłej meto­dzie testowania zstępującego, możliwość tes­towania wybranych konstrukcji logicznych wewnątrz modułu. Dotyczy to szczególnie sprawdzania poprawności danych, progra­mowania defensywnego (por. rozdział 2: Uruchamianie) oraz badania kon­kretnych warunków logicz­nych występu­jących wewnątrz kodu. Fragmen­ty tego typu da się przetes­tować jedynie wtedy, gdy moduł istnie­jący o szczebel wyżej przekazuje nieprawidłowe albo specyficzne dane. Po włączeniu badanego modułu do programu taka sytuacja może być trudno osiągalna. Powodem tego jest na ogół wykorzystywanie modułu w ogra­niczonym kontekście (gdy nie otrzy­mu­je on pełnej dziedziny swoich danych wejściowych) lub też występowa­nie trudnoś­ci w okre­śleniu rodzaju danych testowych (jeżeli są one wprowa­dzane w punk­cie znacznie oddalonym od badanego warunku).

Metoda dziedziczy również wady czy też niedogodności swoich poprzedniczek. Wadą zmodyfikowanej metody testowania zstępującego jest koniecz­ność przygotowywania obwodów sterujących oraz namiastek każdego modułu.

4. Testowanie mieszane

Testowanie mieszane stanowi kompromis między te­sto­waniem wstępującym i zstępującym. Testowanie zstępujące rozpoczynamy od najwyższej warstwy projektu - programu głównego; testowanie zstępujące - od najniższej warstwy - modułów podstawowych, aż do spotkania pośrodku. Linia spotkania powinna zostać wyznaczona przed rozpo­częciem testowania na podsta­wie znajomości struktury programu. Metodę tę stosuje się głównie do scalania dużych programów (systemy operacyjne i spe­cjalizowane systemy użytkowe). Zaletą tego sposobu testowania jest wczesne scalanie modułów, czyli szybkie uzyskanie szkieletowego, ale już działającego progra­mu. Poza tym zachowane są zalety zarówno testowania zstępu­jącego, jak i testo­wa­nia wstę­pującego, przy równoczesnej częściowej neutrali­zacji ich wad.

Za istotną wadę metody uważa się niemożność pełnego przetes­towania części modułów, związaną z testowaniem zstępującym. Co prawda dotyczy to tylko górnych warstw programu, jednak czasem może okazać się kłopotliwe.

5. Zmodyfikowane testowanie mieszane

Metoda ta jest połączeniem metody wstępującej i zmodyfikowa­nej metody zstępującej. Przy zmodyfikowanym testowaniu mieszanym niższe poziomy te­stu­jemy w sposób ściśle wstępujący, natomiast moduły pozio­mów wyższych naj­pierw testujemy osobno, a następnie scalamy stosując testowanie zstępujące. Takie podejście do modułów poziomów wyż­szych pozwala ustrzec się wad metody testowania miesza­nego.

6. Testowanie big-bang

Metoda big-bang (wielki wybuch) jest najpospolitszą metodą scalania modu­łów. Pierw­szą jej fazą jest testowanie poszczególnych modułów w izolacji od pozosta­łych. Następnie wszystkie moduły scala się naraz i testuje cały program.

Testowanie big-bang ma stosunkowo wiele wad i niewiele zalet. Ko­nieczne jest napisanie modułów sterujących i namiastek każdego modułu. Sca­lanie odbywa się w późnym stadium testowania, więc błędy pośre­dnictw mię­dzymodułowych pozostają długo nie wykryte. Jednoczesne scalenie wszystkich modułów może sprawić dość poważne kłopoty z wykry­ciem winnego, w przypadku nagłego wystą­pienia błędu.

Metoda big-bang może jednak okazać się przydatna w przy­padku testowania niewielkich i dobrze zaprojektowa­nych programów.

7. Uwagi końcowe o przebiegu procesu testowania

W wyniku testowania często dokonuje się w programie zmian wynika­ją­cych z wykrytych błędów. Zmiany te mogą, niestety, powodować pojawie­nie się kolej­nych, nowych błędów. Konieczne jest zatem ponowne testo­wanie, nazywane tes­towaniem redundantnym lub testowa­niem powrotnym. Do jego przeprowadzenia stosuje się zestawy danych testowych wykorzysty­wane podczas testowania pier­wotnego. Należy zwrócić uwagę na możliwość rozpoczynania testowania powro­tnego od bardziej złożonych zestawów danych i cofania się do testów prostszych dopiero w przypadku, gdy te testy zawiodą.

Testowanie należy powtarzać po każdej zmianie tekstu progra­mu.

1. Dane testowe

Właściwy wybór danych wykorzystywanych do testowania programu może w znacznym stopniu ułatwić wykrywanie błędów. Dobry test pozwala czasem usta­lić także ich źródło.

Pierwsze zestawy testowe powinny być jak najprostsze. Począ­tkowo chodzi tylko o to, by stwierdzić, czy program w ogóle pracu­je. W ten sposób można zweryfikować jego podstawową organiza­cję. Kolejne testy powinny przebiegać dla danych coraz bardziej złożo­nych. Stopniowe testowanie ułatwia precy­zyjne wyśledzenie błędu, gdy wyniki są niepo­prawne.

1. Kategorie danych testowych

Dane testowe można ze względu na ich pochodzenie podzielić na kategorie:

• dane spreparowane,

• dane faktyczne z odpowiednimi modyfikacjami,

• dane faktyczne w odpowiedniej ilości.

Spreparowane dane testowe to dane dobrane w celu przetestowania programu. Mogą być sterowane lub losowe.

Dane sterowane poma­gają w sprawdzeniu sytuacji, które mogłyby się zda­rzać rzadko. Ich za­letą jest także to, że odpowiednio dobrane minimalizują pracę konieczną do rę­cznego sprawdzenia wyników testowa­nia. Za wadę stero­wa­nych danych można uznać fakt, że programista dobiera tylko takie dane, które według jego su­biekty­wnego poglądu mogą stwarzać problemy.

Dane losowe tworzy się na ogół za pomocą specjalnych progra­mów. Do zalet tego typu testów można zaliczyć możliwość wykrycia błędów, które bez ich stosowania nie byłyby zauważone. Jest to związane z tym, że programista nie ma bezpośredniego wpływu na dobór tych danych. Podsta­wową wadę danych losowych stanowi trud­ność w ręcznym sporządza­niu wyników służących do wery­fikacji poprawności działania pro­gramu.

Zmodyfikowane dane faktyczne wnoszą element realności do pro­ce­su tes­towania. Selektywne modyfikacje rzeczywistych danych dają możliwość two­rze­nia specyficznych testów. W tym przypadku istnieje także możli­wość zauwa­żenia problemów, których nie pokażą dane spreparowane. Rozmyślne wprowa­dza­nie błędów w tak przygotowa­nych testach pozwala sprawdzić jakość fragmen­tów programu odpowie­dzial­nych za kontrolę danych.

Dane rzeczywiste testują właściwą pracę programu w warunkach, w jakich ma być on wykorzystywany. Niestety, istnieje tu problem oceny poprawności gene­rowanych wyników. Niewątpliwą zaletą jest możliwość ujawnienia nieporozu­mień, jakie mogły zdarzyć się między użytkowni­kiem i programistą w trakcie uzga­dniania specyfikacji programu, nie wykrytych podczas testowania specyfikacji.

Przy stosowaniu wszystkich rodzajów danych testowych należy zwracać szczególną uwagę na poprawne wyznaczanie oczekiwa­nych wyników dla każdego zestawu danych. Błędy w ręcznym obliczaniu rezultatów mogą spowodować pozorne wykrycie błędu i skierować tok uruchamiania na niewłaściwe tory, zaburzyć lub znacznie wydłużyć ten proces.

1. Klasy danych testowych

Przetestowanie programu dla wszystkich możliwych zestawów danych nie jest wykonalne. Należy więc podzielić dane na określone klasy. Jako kryte­rium stosuje się rodzaj przynależności do dziedzi­ny danych. Do różnych klas będą należały dane:

• z dziedziny (z uwzględnieniem przypadków szcze­gól­nych),

• spoza tej dziedziny (z lewej i z prawej strony, lub - jak kto woli - z gó­ry i z dołu),

• z krańców dziedziny.

Każdy test powinien reprezentować jedną z wyodrębnionych klas. Jeśli program prawidłowo obsłuży sprawdzane dane z jakiejś klasy, możemy uważać, że podob­nie zachowa się w stosunku do pozostałych danych w tej klasie.

1. Praktyczne zasady dobierania zestawów danych testowych

W trakcie faktycznego testowania programu można wyróżnić trzy fazy:

• testowanie sytuacji normalnych,

• testowanie sytuacji krańcowych,

• testowanie wyjątków.

Celem jest tu upewnienie się, że wszystkie dozwolone dane gwaran­tu­ją uzys­kanie poprawnych wyników, a dane niepoprawne spowodują wyprowadze­nie od­po­wied­niego komunikatu o błędzie lub podjęcie odpowiedniej akcji awaryjnej.

Testowanie sytuacji normalnych odbywa się dla najbardziej po­wszech­nych danych, dla których program był zaplanowany. Ma ono na celu wykazanie, że generowane rezultaty są poprawne.

Testowanie sytuacji krańcowych obejmuje sprawdzenie zachowa­nia się programu na krańcach przedziałów akceptowalności danych. Wykonuje się je wtedy, gdy z wynikiem pozytywnym przetestowano sytuacje normal­ne. W przy­padku danych numerycznych testuje się dolną i górną granicę zbio­ru wartości dopu­szczalnych. Dane nienu­meryczne powinny, na przykład, zawierać tylko jedną z wymaga­nych cech lub wszystkie cechy razem. Należy też spraw­dzić zachowanie się progra­mu, gdy danych nie ma lub jest ich bardzo dużo. Na ogół testowanie sytuacji krań­cowych pozwala na wykrycie największej liczby błę­dów.

Testowanie wyjątków stanowi ostatnią fazę sprawdzania po­prawności dzia­łania programu. Zestawy testowe obejmują dane nie mieszczące się w dopu­sz­czalnym zakresie.

Szczególną uwagę należy zwrócić na możliwość akceptowania przez program błędnych danych i zwracania niepoprawnych wyników (mogących czasem wyglądać prawdopodobnie!). Każda sytuacja, której specyfikacja nie przewiduje, powin­na być przez program zauważona i odpowiednio obsłużona (komunikatem lub przyjęciem zastępczej poprawnej wartości).

1. Środki pomocne w testowaniu

Wśród środków pomocnych w testowaniu szczególne miejsce zajmują programy pomagające zautomaty­zować pro­ces testowania. W niektórych systemach oprogramowania mogą znajdować się gotowe pro­gramy dostarczające danych do testowania (generatory danych testo­wych), programy tworzące pliki informacyjne, kom­parato­ry plików, programy profilu­jące, obwody testujące. Jeśli programy tego typu nie są dostępne, warto stwo­rzyć je włas­noręcznie. Przy od­powiedniej budowie będą mogły służyć wielo­krotnie, zarówno do testowania programów podobnej klasy, jak i programów w ogóle.

Obecnie podstawowym i uniwersalnym narzędziem do testowania, stosowanym w laboratorium, są debuggery wbudowane w zintegrowane środowiska języków pro­gra­mo­wa­nia firmy Borland lub dostarczane z nimi. Potrafią one z powodzeniem zastąpić wiele wyżej wspomnianych mechanizmów i narzędzi.

Pytania kontrolne

1. Co to jest testowanie? Jaki jest jego cel, przebieg?

2. Jaka jest istotna różnica między testowaniem a uruchamianiem?

3. Podaj zalety i wady testowania względem kodu.

4. Podaj zalety i wady testowania względem specyfikacji.

5. Podaj warunki konieczne zakończenia testowania względem kodu.

6. Na czym polega testowanie wstępujące?

7. Na czym polega testowanie zstępujące?

8. Jakie są inne, poza testowaniem wstępującym i zstępującym, metody testowania?

9. Co to są zaślepki? W jakiej metodzie testowania występują?

10. Co to są obwody sterujące? W jakiej metodzie testowania występują?

11. Podaj podział danych testowych ze względu na ich pochodzenie.

12. Podaj podział danych testowych ze względu na dziedzinę.

13. Do czego służą diagramy przepływu sterowania (DPS)?

Zadania dla ćwiczących

1. Zapoznanie się z podstawowymi i bardziej zaawansowanymi mechanizmami diagno­stycznymi wbudowanymi w środowisko zintegrowane IDE Borland C lub Pascala:

• możliwością pracy krokowej,

• pułapkami (również warunkowymi),

• zwykłym (watch) i obiektowym (inspect) oknem podglądu,

• możliwością modyfikacji wartości zmiennych i kontynuowania przerwanego pro­gramu.

2. Zapoznanie się z mechanizmami automatycznej kontroli poprawności wykonania pro­gramu i sygnalizowania błędów wykonania, wbudowanymi w kompilator (sprawdza­nie zakresów, przepełnienia stosu, błędów wejścia-wyjścia).

3. Zapoznanie się ze specyfikacją zewnętrzną i zasadą działania przykładowego pro­gramu lub modułu.

4. Poprawienie sygnalizowanych błędów kompilacji (syntaktycznych i semantycznych) w przy­kładowym programie lub module.

5. Przygotowanie systematycznych danych testowych.

6. Wykonanie testowania przykładowego modułu (modułów) wybraną metodą.

7. Wykonanie testowania całego programu przykładowego.

8. Wykrycie i usunięcie błędów wszystkich typów z programu przykładowego.

Zawartość sprawozdania

W sprawozdaniu powinny znaleźć się:

1. Lista błędów kompilacji programu przykładowego (wyjaśnienie przyczyn błędu, spo­sób po­prawy, ewentualnie omówienie różnych sposobów poprawy danego błędu).

2. Systematyczne dane testowe, względem kodu lub specyfikacji, zgodnie z instrukcjami pro­wadzącego wraz z uzasadnieniem doboru danych na podstawie przedstawionych metod lub zasad doboru danych testowych oraz spodziewane wyniki odniesienia.

3. Opis przebiegu testowania i uruchamiania, obejmujący zestaw danych testowych, efekt uru­chomienia programu dla tych danych, hipotezę o błędzie i jego kategorii, propozy­cję po­prawy i efekt testowania powrotnego.

4. Listing poprawionego programu lub modułu.

5. Uwagi na temat specyfikacji, ewentualne jej zmiany i uściślenia powstałe w toku uru­chamia­nia.

6. Omówienie wskazanego przez prowadzącego mechanizmu diagnostycznego, wbudo­wa­nego w środowisko IDE i sposobu posługiwania się nim w toku uruchamiania.

7. Wnioski.

Literatura

1. G. J. Myers: Projektowanie niezawodnego oprogramowania. WNT, War­szawa 1980.

2. A. Jaszkiewicz: Inżynieria oprogramowania. Helion, Gliwice 1997.

3. D. Van Tassel: Praktyka programowania. WNT, Warszawa 1989.

4. P. Naur: Zarys metod informatyki. WNT, Warszawa 1979.

5. W. M. Turski: Metodologia programowania. WNT, Warsza­wa 1982.




rozdział 2

Uruchamianie programów

2. Uruchamianie programów

1. Cel ćwiczenia

Opisane w tej instrukcji ćwiczenie ma na celu praktyczne zapo­znanie się:

• z typowymi systemowymi środkami wspoma­gającymi urucha­mianie programów;

• z innymi, uzupełnia­jącymi (indywi­dualnymi) środkami ułat­wiającymi ten proces;

• z metodami i tech­niką uruchamiania programów poprzez poszukiwanie i poprawianie umie­szczonych w podanym programie przykła­dowym błędów.

1. Istota uruchamiania

W przypadkach gdy program działając nie spełnia sensownych oczekiwań użytkownika, mamy do czynienia z błędami w tym progra­mie. Mówiąc o błędzie można mieć na myśli objawy niepoprawnej pracy programu (błąd wtórny) bądź określone odstępstwo treści programu od postaci zapewniają­cej poprawne działanie (błąd pierwotny). Obecność w programie błędów pier­wotnych ujawnia się w postaci błędów wtórnych, choć - niestety - zaobserwowane błędne zachowanie programu rzadko jednoznacznie wskazuje, z jaką przyczyną (błędem pierwotnym) mamy do czynienia.

Uruchamianie to proces znajdowania i usuwania z programu błędów pierwotnych (w zasadzie tych, które ujawniły się w czasie wykonywania programu). Do uruchamiania przystępujemy zwykle po stwierdzeniu dowodów lub symptomów istnienia błędu. Obecność błędów wykrywana jest zazwyczaj w czasie procesu testo­wania. Bardziej kłopotliwą sytuacją jest wystąpienie błędu po przekazaniu programu do eksploatacji. Dlatego należy dążyć poprzez właściwe i rzetelne testowanie programu do wykrycia jak naj­większej liczby błędów jeszcze przed przekazaniem programu użytkownikowi. Problemy testowania zostały rozpatrzone w rozdziale pierwszym.

2. Kategorie i przyczyny błędów

W programach wystąpić mogą różnorakie błędy. Można zaproponować ich podział ze względu na wiele kryteriów: moment ich ujawnienia się, przyczynę itd.

Ze względu na moment ujawnienia się błędy można podzielić na:

• Błędy kompilacji, sygnalizowane podczas kompilacji przez kompilator;

• Błędy wykonania (ang. run-time errors), sygnalizowane podczas wykonywania programu przez sam program lub system operacyjny. Ich bezpośrednie przyczyny są różne. Błędy są najczęściej powodowane:

• usiłowaniem wykonania niedozwolonej operacji arytmetycznej (np. dzielenie przez zero, pierwiastek z liczby ujemnej),

• usiłowaniem wykonania niedozwolonej lub bezsensownej w danej chwili operacji wejścia-wyjścia (otwieranie nie istniejącego pliku do czytania, odwołanie do nie istniejącego lub niegotowego urządzenia),

• uzyskaniem niedopuszczalnego wyniku (nadmiar arytmetyczny, przekroczenie zakresu typu),

• brakiem kontroli danych wejściowych (rozróżnienie danych liczbo­wych i alfa­numerycznych). W niektórych systemach operacyjnych, jak w nie używanym już systemie maszyn ICL 1900/ODRA 1300, błąd wykonania powodowało również przekroczenie przez zadanie przyznanego czasu procesora (np. z powodu zapętlenia programu lub zastosowania nieoptymalnego algorytmu).

• Błędne wyniki, nie są one nigdy jawnie sygnalizowane - powinny być dostrzeżone podczas testowania, natomiast jeżeli nie wykonamy testowania rzetelnie, to zapewne ujawnią się podczas eksploatacji programu, co pociąga za sobą poważne następstwa.

Zaobserwowanie błędnej pracy programu rozpoczyna proces jego uruchamiania.

Przyczyna błędu może zaistnieć na określonym etapie pracy nad programem, natomiast symp­tomy mogą ujawnić się dopiero dużo później. Dlatego w trakcie uruchamiania szukając błędu należy liczyć się z koniecznością sięgnięcia głęboko wstecz. Na kolejnych etapach produkcji programu mogą zaistnieć błędy takie jak:

• Błędy spowodowane złym sformułowaniem treści zadania. Wynikają one z niezrozumienia przez programistę potrzeb przyszłego użytkownika programu. Błędnie zostaje wów­czas sformułowana specyfikacja zewnętrzna programu. W celu uniknięcia tego typu błędów specyfi­kacja zew­nętrzna powinna być zapisana i przetes­towana przed napisa­niem programu (por. punkt 2.3.2).

• Błędy analizy zadania, polegające najczęściej na wyborze niewłaściwego algorytmu, który rozwiązuje zadanie niewła­ściwie lub niedobrze, lub na przeoczeniu pewnych przypadków, na przykład możliwości podania liczby ujemnej, napisu pustego, górnego ograniczenia jakiegoś przedziału mniejszego niż dolne ograniczenie (max < min) itp. Przykładem złego algorytmu może być roz­bieżna metoda itera­cyjnego rozwiązywania równania, użycie nieodpowiedniego wzoru (np. obliczanie wartości wyróżnika trójmianu kwadratowego ze wzoru: delta := b*b+4*a*c) bądź też algorytm obliczający wyniki poprawnie, ale zbyt wolno (co prowadzi do błędu wykonania - przekroczenia zadanego czasu wykonania). Błąd popełniony podczas analizy ujawni się w tekście programu jako błąd logiczny.

• Błędy wynikające z niepoprawnego zakodowania algorytmu, to znaczy niepoprawnego przejścia z abstrakcyjnego opisu ciągu operacji, jakim jest algorytm, na tekst konkretnego programu w konkretnym języku programowania. Jest to kategoria, z którą najczęściej mamy do czynienia i która będzie omówiona później.

• Błędy zaokrągleń spowodowane ograniczoną dokładnością repre­zentacji liczb rzeczywistych. Występują również przy nie kontro­lowanych konwersjach typów.

• Błędna postać dokumentacji dla użytkownika, gdzie opis działa­nia programu nie w pełni zgodny jest ze stanem faktycznym. Najczę­stszą tego przyczyną jest nieuaktualnienie dokumentacji na bieżąco przy wprowadza­niu zmian w programie. Skutkiem może być na przykład podawanie na wejście programu w dobrej wierze danych o niewłaściwej postaci.

Na etapie kodowania (pisania tekstu programu) programista może popełnić najwięcej błędów. Można tu wspomnieć o takich kategoriach, jak:

Błędy syntaktyczne, czyli nieprzestrzeganie zasad składni języka programowania. Są to błędy bardzo popularne:

• brak średnika, nawiasu, innego znaku interpunkcyjnego lub wymaganego słowa klu­czowego czy deklaracji,

• nieprawidłowy symbol, nawias lub niedozwolony znak w identyfikatorze.

Wykrywanie tych błędów jest jednym z naj­ważniejszych zadań kompi­latora, więc obja­wiają się zawsze jako błędy kompilacji. Muszą one być poprawione jeszcze przed próbą wy­ko­na­nia pro­gramu.

Błędy seman­tyczne są to błędy inne niż składniowe, lecz również wykrywalne przez me­chani­zmy języka programowania. Błędy te wynikają z niezro­zumienia znaczenia zapisu. Se­mantyka języka to zbiór reguł opisujących znaczenie konstrukcji języka programowania. Błędy semantyczne powo­duje niepeł­na znajomość lub niezrozumie­nie języka programo­wania i architek­tury komputera. Błę­dami semantycznymi są:

• brak deklaracji,

• niezgodność typów w wyrażeniu,

• przekroczenie zakresu wartości w typie,

• niedozwolona wartość argumentu operacji.

Inne błędy, nie należące do powyższych dwu kategorii, niewykrywalne przez mechani­zmy ję­zyka programowania, zaliczamy do ogólnej kategorii błędów logicznych. Są one rów­nież często powodowane przez niedostateczną znajomość języka czy biblioteki. Błędy lo­giczne w programie prowadzą do błędnych wyników, czasami są również przyczyną błędów wykonania. Przykłady błę­dów logicznych:

• użycie pętli repeat zamiast while;

• użycie nieodpowiedniej procedury bibliotecznej;

• użycie nieodpowiedniego wzoru;

• brak nadania wartości początkowych zmiennym (np. trudne do wykrycia jest nie­zainicjowanie zmien­nych wskaźniko­wych, szczegól­nie po użyciu procedury dispose);

• brak inicjalizacji, niewłaściwe indeksowanie lub zakończenie pętli;

• zamiana dróg po rozgałęzieniu w programie (if-then-else).

Cały szereg błędów ma charakter przeoczenia lub pomyłki podczas wprowadzania tekstu pro­gramu do komputera i jego edycji. Błędy przepisywa­nia mogą wykazywać cechy błędów syntak­tycznych, semanty­cznych lub logi­cznych.

1. Testowanie a uruchamianie

Testowanie i uruchamianie są procesami często mylonymi. Być może dlatego, że pod ko­niec procesu produkcji programu przeplatają się. Istotą różnicy jest to, że testując nie wiemy, czy w pro­gramie znajdują się jakieś błędy, natomiast uruchamiając wiemy, że błąd jest.

Po napisaniu całego programu, gdy kompilator dostarczy już kod wynikowy, najczęściej nastę­puje testowanie „na dym”. Dane testowe są często proste. Wykrywamy wtedy pewne grube, oczy­wiste błędy. Następnie przechodzimy do uruchamiania, kiedy to lokalizujemy błędy, staramy się je zrozumieć i wreszcie je usuwamy. Z kolei powracamy do testowania, przygotowując bardziej fine­zyjne dane testowe, co pozwala na ujawnienie drobniejszych lub rzadziej występujących (jednak przez to nie mniej ważnych) błędów. Po wykryciu kolejnych błędów powracamy do uruchamiania i w ten sposób testowanie przeplata się z urucha­mia­niem, przy czym dane testowe i błędy stają się coraz bardziej wyrafinowane.

2. Niektóre symptomy błędów i najczęstsze powody ich wy­stępowania

W ramach testowania wykonujemy program. Efekty mogą być różne. Jeżeli program nie działa poprawnie, to objawy mogą być następujące:

• Program wykonuje się, lecz nie daje żadnych wyników. Sytuacja taka może wskazywać na istnienie pewnego błędu logicznego, np. skok do końca programu przed wyprowadze­niem wyników.

• Program wykonuje się, ale kończy działanie sygna­lizując pewien błąd wykonania (dzielenie przez zero, niepoprawne indeksy w tablicy, wyjście poza zakres wartości danego typu, błąd operacji wejścia-wyjścia, nadmiar lub niedo­miar numeryczny itp.).

• Program kończy działanie nie sygnalizując błędów wykonania, ale wyprowadza błędne wyniki. Jest to najczęstszy objaw istnienia błędu lub błędów różnego typu w programie. Należy wtedy zwrócić uwagę, czy kompilator generuje specjalny kod sprawdzający zakresy, przepełnienia itp. i czy sygnalizuje odpowiedni błąd wykonania. Jeżeli opcje kompilatora, kontrolujące automatyczne generowanie takiego kodu sprawdzającego, nie były włączone, należy je włączyć, a następnie kontynuować uruchamianie.

• Program nie kończy działania i brak jest postępów wyko­nania. Oznacza to zazwyczaj, że program wykonuje nies­kończoną pętlę - jak mówimy, zawiesza się.

1. Metody znajdowania błędów

Istnieje wiele różnych metod poszukiwania błędów w progra­mie i technik do tego wykorzystywanych. Najczę­ściej stosuje się kombinację kilku z podanych niżej.

Metoda badania symptomów błędu (Browna i Sampsona) pozwala na zbadanie sprzeczności w wynikach. Metoda ta pomocna jest przy formułowaniu dokładniej­szej hipotezy o błędzie lub przy ustalaniu istnie­nia więcej niż jednego błędu. Dane o błędzie wpisuje się do spe­cjalnego formularza:

? Jest	Jest	Nie ma
Co
Gdzie
Kiedy
W jakim stopniu

W rubryce Co opisuje się podstawowe symptomy błędu. W rubry­ce Gdzie precyzuje się, gdzie je zauważono Na początkowym etapie może tu chodzić o umiejscowienie błędu w wynikach. Później, w miarę rozwijania i pogłębiania hipotezy na temat umiejscowienia błędu można tu wpisywać obszar kodu programu, w którym znajduje się domniemana przyczyna. Rubry­ka Kiedy zawiera wskazówki mówiące o tym, kiedy symptomy występują, a kiedy nie, natomiast w rubryce W jakim stopniu wyznacza się zasięg symptomów. Porównanie zawar­tości kolumn Jest i Nie ma stanowi sedno tej metody, ponieważ ukazują one różnice i sprzeczności, na podstawie których zbuduje się hipotezę tłumaczącą przyczyny błędu.

Czasami niezastąpione jest czytanie i analizowanie napisanego programu. Dokładne przejrze­nie sformułowania zadania, dokumentacji pro­jektowej, algorytmu i samego programu zaraz po wpro­wadzeniu go do komputera pozwala znaleźć znaczny odsetek błędów. Analiza kodu programu jest nieunik­niona po stwier­dzeniu wystąpienia błędu. Problem stanowi ograniczenie objętości fragmentu prog­ramu, który trzeba będzie badać. Zastosowanie wymie­nionych dalej metod ułatwia rozwiązanie tego problemu.

Programowanie defensywne jest praktyką pisania pro­gramów w taki sposób, aby pojawienie się błędu było wcześnie wykryte i zasyg­nalizowane, i aby nie dopuścić do dalszego przetwarzania danych niepoprawnych w wybranych punktach programu, a w szczególności na początku przetwarzania w obrębie poszczególnych modułów. Sprawdza się postać, zakresy i długość danych wejściowych, sensowność wartości zmie­nnych, warto­ści różnorodnych sum kontrol­nych, liczników transa­kcji itp., i natychmiast sygnalizuje wykryte błędy. Programowanie defensywne wydatnie ułatwia wykrycie, lokalizację i zrozumienie istoty błędów.

Do głównych zasad programowa­nia defensywnego należy:

• wzajemna nieufność - każdy moduł zakłada, że wszelkie otrzymywane przez niego dane mogą być niepo­prawne, trzeba je więc sprawdzić,

• bezzwłoczne wykrywanie błędów - najlepiej wykryć błąd możliwie najwcześniej, ponieważ ułatwia to zlokalizowanie jego źródła,

• izolowanie błędów - stosuje się w tym celu w niektórych częściach systemu „grodzie”, dzięki którym błąd nie może spowodo­wać szkód w innych częściach systemu; po prostu dane błędne nie są dalej przekazywane.

Istnieją środki techniczne lub metody stosowane podczas uruchamiania pozwalające na zgromadzenie informacji niezbędnej w celu lokalizacji błędu i rozpoznania jego przyczyn.

Dostępnym dla każdego środkiem jest umieszczanie w programie wydruków kontrol­nych za­wierających ślad wykonania pro­gramu, dalej - tzw. echo-test danych wej­ściowych, czy też infor­mację, jak przebiegają bieżące obli­czenia. Instrukcje generujące takie wydruki mogą wyglądać na­stępująco:

begin

writeln ('Początek procedury sortuj');

… {ciało procedury }

writeln ('Koniec procedury sortuj');

end;

lub:

writeln ('Podano x = ', x);

writeln ('Podano c: ', c, ' (kod: ', ord(c), ')');

lub też:

writeln ('Wykonanie pętli dla i = ', i, ' j = ', j);

Najlepiej jest umieszczać wydruki kontrolne już na etapie pisania określo­nego fragmentu pro­gramu, kiedy programista może je rozmieś­cić w sposób bar­dziej prze­myślany, niż później - dopiero podczas uru­chamia­nia całego programu.

Przy lokalizowaniu błędu przydatne bywają wydruki generowane automatycznie, do których należą między innymi: komunikaty systemowe, ślad wykonania programu i zrzut zawar­tości pamięci. Obecnie na laboratorium (jak również szerzej) rzadko stykamy się z systemami ge­ne­ru­ją­cymi takie informacje, pozostaje więc samodzielne generowanie potrzebnych informacji w spo­sób podany wyżej. Wydruki kontrolne wprowadzane przez samego programi­stę na eta­pie projektowania programu są zazwyczaj bardziej pomocne i efektywne niż wydruki osią­gal­ne przy użyciu syste­mowych środków śladu automatycznego. Otrzymu­jemy wówczas mniej­­szą porcję danych wyjściowych, które można lepiej wyko­rzystać w procesie poszu­ki­wa­nia błędów.

Uruchamianie interakcyjne jest procesem wykonywania programu pod kontrolą innego specjalnego programu (debuggera) umożli­wiają­cego zwykle:

• ustawianie pułapki w dowo­lnym miejscu programu i zamrożenie jego stanu,

• zatrzymanie wykonania programu po wystąpieniu błędu,

• zbadanie i modyfikację wartości dowolnej zmie­nnej po zatrzymaniu programu,

• modyfikację treści programu wynikowego (nie­kiedy także źródłowego),

• wznowienie wykonania programu od dowolnej ins­truk­cji.

1. Sposób postępowania przy uruchamianiu

Uruchamianie rozpoczyna się od stwierdzenia istnienia pewnych symptomów błędu i polega na umiejscowieniu błędu i na jego popra­wieniu. Proces ten można ogólnie podzie­lić na kilka kroków:

• Zrozumienie problemu, czyli dokładne zbadanie tego, co program zrobił poprawnie, i tego, co zrobił niepo­praw­nie, a następnie postawienie jednej lub więcej hipotez na temat natury błędu. Należy określić, czy otrzymane dane wynikowe pozwalają umiej­scowić błąd. Jeśli nie, to trzeba napisać i wykonać dodatkowe testy. Ważne przy tym jest ustalenie danych wejścio­wych prowadzących do wystą­pienia błędu (może być potrzebna rejestracja tych danych, gdy dane nie są powta­rzalne lub reakcje programu są przypadkowe). Poży­teczną metodą przy lokalizacji błędu jest zbadanie występujących sprzecz­ności w wynikach, z wykorzystaniem omówionego wyżej sposobu analizy sympto­mów błędu.

• Przemyślenie planu działania. Krok ten polega na zbudowa­niu hipotezy tłumaczącej przyczy­ny błędu i obmy­śleniu planu postępowania spraw­dzają­cego słuszność tej hipotezy.

• Realizacja planu, mającego na celu zbadanie słusz­ności hipotezy. Polega to głównie na napisaniu i wykonaniu odpowie­dnich testów.

• Przemyślenie i ewentualna weryfikacja hipotezy. Jeżeli ustaliliśmy już domniemany błąd pierwotny, to przed próbą popra­wienia trzeba przeanalizo­wać ten błąd i upewnić się, czy rzeczywiś­cie on jest powodem zauwa­żonych symptomów. Przy­czyna błędu może nie leżeć bezpośrednio w instru­kcji, w której ujawnił się symptom, a mieć związek z wcześniejszymi działaniami prog­ramu (np. błąd dziele­nia przez zero w danym wyraże­niu może być spowodowany przez wcześ­niej­sze błędne przypisa­nie wartości zmiennej). Konieczne jest również spraw­dzenie, czy poprawienie tego błędu nie spowoduje wystą­pienia nowego błędu. Główną przy­czyną trudności w uru­chamianiu jest nastawienie psychiczne programisty, w wyniku którego widzi on to, co chce widzieć, nie zaś to, co jest w rzeczywistości. Jednym ze sposobów walki z tą postawą jest sceptycyzm wobec wszystkiego, co jest badane, a zwłaszcza wobec komentarzy i dokumentacji programu, oraz wcześniejsze określenie przewidywanych wy­ników testów progra­mu.

• Dokonanie poprawki w progra­mie. Po precyzyj­nym umiejscowieniu błędu przystępuje­my do jego popra­wienia. Nie należy ograniczać się tylko do likwidacji symptomów błędu, jak również należy unikać poprawek nieprze­myśla­nych, eksperymentalnych. Poprawek powinno się dokonywać z co najmniej taką systematy­czno­ścią, z jaką sporządziliśmy pro­jekt. Poprawki wnosimy w tekst źródłowy programu, po czym kompilujemy i linkujemy program. W większości środowisk programisty istnieją środki umożliwiające automatyczną kompilację wszystkich modułów zależnych od właśnie zmienionego. Należy pamiętać, że w pewnych szczególnych przypadkach bywają one zawodne; co za tym idzie, rozsądne bywa przekompilowanie całego projektu.

• Sprawdzenie skuteczności popra­wy. Jest to ostatni, bardzo ważny krok. Wiąże się on z wykonaniem całego programu lub odpo­wiedniego fragmentu.

1. Środki pomocne w uruchamianiu

Niemal zawsze programista ma dostęp do różnych środków wspomagających uruchamianie programów zapisanych w określonym języku. Stanowią one część środowiska danego języka programowania lub wchodzą w skład oddzielnych pakietów programowych.

Do środków ułatwiających uruchamianie programów należą:

• debuggery,

• mechanizmy nadzorujące poprawność wykonania programu lub poszczególnych operacji,

• mechanizmy do generacji i interpretacji informacji diagnostycznej o przebiegu wyko­na­nia programu.

Debugger to program kontro­lujący wykona­nie innych pro­gramów; pozwala on na uruchamianie tych pro­gramów w sposób interakcyjny, śledzenie i gromadzenie różnorodnych informacji diagnostycznych. Typowy debugger umożliwia rozpo­częcie pracy programu, wstrzymywanie jej w wybranym pun­kcie lub pod określonym warunkiem, kontrolę i ewentu­al­nie zmianę zawartości zmien­nych oraz wznawianie obli­czeń. Debugger języka wysokiego poziomu powinien mieć możliwość pokazania tekstu źródłowego uruchamianego programu z wyróżnioną instrukcją właśnie wykonywaną oraz zgodnego ze składnią i semantyką języka wyświetlania symbolicznej nazwy zmiennej lub wyrażenia wraz z jej aktualną wartością w odpowiedniej, czytelnej reprezentacji.

Mechanizmy nadzorujące poprawność wykonania programu wprowadza się do kodu programu na czas jego uruchamiania. Znaczną ich część usuwa się zwykle przed wytworzeniem wersji ostatecznej, przetestowanej, przeznaczonej do dystrybucji i eksploatacji. Ten dodatkowy kod nie realizuje bezpośredniego zadania programu, a jedynie kontroluje poprawność wykonania podstawowego kodu. Po jego usunięciu, a przed ostatecznym skierowaniem programu do użytkowania, należy przeprowadzić dodatkowe, końcowe testowanie, gdyż usunięcie dodatkowego kodu czasami może powodować uaktywnienie się błędów, które nie ujawniły się wcześniej.

Duże znaczenie ma kontrola indeksów tablic i zakresów zmiennych, która polega na sprawdzeniu, czy wartości poszczególnych indeksów mieszczą się w zadeklarowanym zakresie tablic, oraz czy wartości zmiennych mieszczą się w dopuszczalnych zakresach (np. typy okrojone w Pascalu). Najczęściej instrukcje realizujące tę operację wstawiane są automa­tycznie przez kompilator (w wyniku użycia odpowiedniej dyrektywy lub opcji kompilatora). Kompilatory dostarczają również standardowych procedur obsługi wykrytych w ten sposób błędów wykonania. Polegają one prawie zawsze na wypisaniu komunikatu informującego o błędzie wykonania i zakończeniu działania programu. Istnieje możliwość zdefiniowania własnych procedur obsługi poszczególnych typów błędów wykonania.

W wersji programu przeznaczonej do testowania i uruchamiania należy włączyć wszystkie mechanizmy automatycznego wykrywania błędów. Zupełnie niewłaściwe jest przekonanie, że wystarczy je wyłączyć, a błąd przestanie występować (czyli - jakby został usunięty). W takim przypadku błąd przestanie jedynie być sygnalizowany, ale program dalej będzie działał błędnie, na przykład zwiększany jednobajtowy licznik po stanie 255 przyjmie stan 0, zmienne dynamiczne będą używać wspólnego lub w ogóle nie przydzielonego obszaru pamięci, wyniki będą kierowane do pliku, który nie został utworzony i tak dalej. Wcześniej czy później, w takim programie lub jego wynikach da się zauważyć błąd, z tym, że będzie go o wiele trudniej zlokalizować.

Informacja diagnostyczna może być generowana ręcznie lub automatycznie. Istnieją narzędzia pozwalające na automatyczne gromadzenie informacji o wykonaniu uruchamianego programu, a następnie na ich interpreta­cję. Do najczę­ściej występujących rodzajów informacji diagnostycznych należą:

1. Zrzut, który jest zapisem informacji o stanie progra­mu w danym momencie czasu. Programując w języku wyższego poziomu ko­rzystamy zwykle ze zrzutu sym­boliczne­go (zapisu danych: nazwy w postaci symbolicznej, a wartości w reprezentacji odpowied­niej dla danego typu danej), a gdy nie jest on dostę­pny - ze zrzutu binarnego (zapisu danych w postaci ciągu liczb binarnych lub szesna­stkowych). Jednym z ty­pów zrzutu jest tzw. wydruk post-mortem, obejmu­jący wartości, jakie miały wszystkie zmienne w chwili zakoń­czenia programu (zwykle w związku z błędem).

2. Ślad sterowania, który stanowi zapis drogi wykonania progra­mu. Stosuje się go do sprawdzenia, czy instrukcje programu wykonują się w takiej kolejności, jak było prze­widzia­ne. Najczęściej drukowane są nazwy kolejno wywoły­wa­nych procedur lub funkcji.

3. Ślad zmiennych, polegający na kontrolowaniu i druko­waniu wartości kolejno przyjmowanych przez wybrane zmienne.

W przypadku braku programów pomocniczych do automatycznej generacji informacji diagnostycznej oraz debuggera możemy do programu jawnie wprowadzić instrukcje dodatkowe (na zasadzie takiej, jak w przypadku mechanizmów nadzoru), służące do wyprowadzania interesującej nas informacji diagnostycznej. Wygodne jest stosowanie instrukcji pokazu pozwala­jącej na wydrukowanie wartoś­ci zmiennej w ściśle określo­nym miejscu programu. Drukowana jest zwykle nazwa zmien­nej wraz z jej wartością.

1. Program przykładowy

Poniżej prezentujemy krótki program zawierający szereg błędów, w tym zarówno błędy wykrywane przez kompilator, jak i błędy logiczne. Przedstawimy przykładowy przebieg uruchamiania tego programu.

Program ma za zadanie przeczytać z pliku o nazwie podanej jako parametr wywołania ciąg wyrazów i wypisać go na ekran po posortowaniu alfabetycznym. W każdej linii pliku wejściowego znajduje się jeden wyraz, którego długość nie przekracza 20 znaków. Ilość linii nie jest określona.

Program umieszcza przeczytane wyrazy w posortowanym drzewie binarnym zgodnie z regułą, że węzły o kluczu mniejszym znajdują się w lewym poddrzewie, a pozostałe w prawym. Kluczem węzła jest wyraz. Wyrazy są przechowywane bez straty pamięci. Drzewo budowane jest przez rekurencyjną funkcję wpisz. Drzewo jest wypisywane na wyjściu przez funkcję wypisz w naturalny, rekurencyjny sposób, tzn.: najpierw lewe poddrzewo, później dany węzeł i prawe poddrzewo, co daje rosnący porządek wyrazów na wyjściu.

Oto wyjściowa postać programu:

1. #include <fstream.h>

2. struct elem

3. { char *s;

4. int n;

5. elem *lewy, *prawy;

6. } korzen

7. typedef elem * wsk;

8. void wpisz( char *s, elem **akt, int n ) // elem* przekazany

// "przez zmienną"

9. {

10. elem *p= *akt;

11. if (!p)

12. {

13. int n;

14. p = malloc( elem );

15. p->lewy = nil;

16. p->prwy = nil;

17. (*p).s = s;

18. p->n = n;

19. }

20. else

21. {

22. if ( p->s > s )

23. {

24. wpisz( s, &p->prawy, n++ );

25. }

26. else

27. if ( p->s != s ) )

28. {

29. wpisz( s, &p->lewy, n++ )

30. }

31. }

32. }

33. void wypisz( wsk p )

34. {

35. wypisz( p->lewy );

36. if (!p)

37. {

38. cout << p->numer << ": ";

39. wypisz( p->s );

40. }

41. wypisz( p->prawy );

42. }

43. void main (int argc, char *argv[])

44. {

45. int numer;

46. if (argc<1) return;

47. ifstream fin( argv[1] );

48. if (!fin) return;

49. char buf[2];

50. while (fin >> buf)

51. wpisz( buf, &korzen, numer );

52. wypisz( &korzen );

53. }

W pierwszej kolejności rozpatrzymy błędy wykrywane przez kompilator BC++ 3.1. Błędy pokazane są tutaj w celu praktycznej ilustracji wiadomości z poprzednich podrozdziałów. W praktyce większość błędów sygnalizowanych przez kompilator (jako że kompilatory języka C nie przerywają kompilacji po napotkaniu pierwszego błędu) jest spowodowana błędami występującymi w kodzie wcześniej. W związku z tym po poprawieniu pierwszych kilku sensownie jest skompilować tekst powtórnie. Przytoczone i omówione niżej błędy zostały otrzymane w ramach kilku kolejnych kompilacji, więc Czytelnik, samodzielnie wykonując ćwiczenie, może nie otrzymać niektórych komunikatów lub otrzymać inne. Celem naszym było jednak nie ścisłe prześledzenie procesu usuwania błędów z poniższego programu, lecz pod takim pretekstem pokazanie błędów, komunikatów i problemów, które najczęściej zdarzają się programistom języka C.

Linia: 7

Komunikat: Declaration syntax error

Analiza: Ogólny błąd składni jest sygnalizowany w wielu przypadkach. Najczęstszym i naj­banalniejszym z nich jest brak jakiegoś znaku, np. ; , lub {}. W przypadkach prostych do rozpoznania kompilator sygnalizuje bardziej konkretnie “; expected” lub “) expected”. Niniejszy komunikat spowodowany jest brakiem średnika zamykającego deklarację struktury i zmiennej korzen.

Po poprawie:

Linia 6: korzen;

Linia: 14

Komunikat: Function 'malloc' should have a prototype

Analiza: Komunikat oznacza, że użyto pewnego identyfikatora w kontekście wskazującym na użycie funkcji, ale funkcja ta nie została jeszcze zadeklarowana (nie napotkano na jej prototyp). Jeżeli jest to funkcja napisana przez programistę, jej prototyp powinien znaleźć się po­wy­żej pierwszego użycia, jeżeli jest to funkcja biblioteczna (a tak jest w tym przypadku), należy na początku pliku w dyrektywie #include włączyć plik nagłówkowy zawierający deklarację tej funkcji. Funkcja malloc zadeklarowana jest w pliku nagłówkowym alloc.h i stdlib.h

Po poprawie:

Linia 2 (wstawiona): #include <alloc.h>

Linia: 15

Komunikat: Undefined symbol 'nil'

Analiza: Komunikat oznacza, że ten identyfikator nie jest znany kompilatorowi. Najczęściej chodzi o brak deklaracji tego obiektu lub o pomyłkę literową. (W języku C wielkie i małe litery są rozróżniane - to również może być powodem.) W tej linii słowo kluczowe nil języka Pascal (oznaczające puste wskazanie) zostało pomyłkowo użyte zamiast stałej NULL używanej w C.

Po poprawie:

Linia 15: p->lewy = NULL;

Linia: 16

Komunikat: 'prwy' is not a member of 'elem'

Analiza: Identyfikator prwy został użyty w kontekście odwołania do składowej struktury elem, jednak w tej strukturze nie ma takiego pola. Jest to prosty błąd literowy.

Po poprawie:

Linia 16: p->prawy = NULL;

Linia: 27

Komunikat: Expression syntax

Analiza: Ogólny błąd składni wyrażeń. Najczęściej spowodowany jest błędnym położeniem lub ilością nawiasów, sąsiedztwem dwu operatorów lub brakiem średnika kończącego poprzednią konstrukcję. W tym przypadku chodzi o powód pierwszy - o jeden nawias zamykający za dużo.

Po poprawie:

Linia 27: if ( p->s != s )

Linia: 31

Komunikat: Statement missing ;

Analiza: Choć treść komunikatu oznacza najbanalniejszy błąd braku średnika zamykającego instrukcję, w tym przypadku tak nie jest. Jak wspomnieliśmy wyżej, wiele komunikatów błędów może być powodowanych błędami znajdującymi się powyżej. Komunikaty takie często mogą również być mylące. Uzupełnianie średnika w linii wskazywanej przez kompilator nic nie da. Dopiero usunięcie nadmiarowego nawiasu (co omówiono powyżej) i uzupełnienie średnika w linii 29 jest prawidłowym rozwiązaniem.

Linia: 33

Komunikaty: Size of 'wypisz' is unknown or zero

Undefined symbol 'wsk'

) expected

Analiza: Wszystkie te (mylące) komunikaty są spowodowane niezinterpretowaniem definicji typu wsk w linii 7 z powodu błędu w linii wyżej. W przypadku zupełnie niezrozumiałych komunikatów błędów, a szczególnie, gdy wiele dotyczy tej samej linii, należy przede wszystkim zająć się poprawieniem błędów poprzednich. Tu po poprawnym przetworzeniu linii 7 błędy te już nie wystąpią.

Inny przykład nieprawidłowych komunikatów:

Linia: 53 (ostatnia):

Declaration syntax error

Declaration missing ;

Compound statement missing }

Linia: 14

Komunikat: Improper use of typedef 'elem'

Analiza: Ten błąd jest najczęściej spowodowany użyciem identyfikatora typu w miej­scu, gdzie należy użyć identyfikatora zmiennej. Sprawdzając prototyp funkcji malloc widzi­­my, że pobiera ona jeden parametr całkowitego typu size_t. Tu należy sięgnąć do seman­tyki, aby stwierdzić, że parametr ten oznacza rozmiar dynamicznie alokowanego ob­sza­ru, a instrukcja w linii 14 ma za zadanie utworzyć kolejną strukturę typu elem, więc należy jedynie dodać operator sizeof, pobierający rozmiar zmiennej podanego typu w bajtach.

Po następnej kompilacji w tej samej linii otrzymamy kolejny błąd:

Komunikat: Cannot convert 'void *' to 'elem *'

Analiza: Język C wymaga jawnego rzutowania typu zwracanego przez funkcję malloc (czyli void *) na odpowiedni typ wskaźnikowy.

Po poprawie:

Linia 14: p = (elem *) malloc( sizeof(elem) )

Nie zawsze na wymieniony komunikat (Cannot convert...) należy reagować mecha­nicznie. W linii 39 zastosowane jest kolejne wywołanie rekurencyjne funkcji wypisz, jednak po krótkim zastanowieniu widać, że funkcja ta powinna być wywołana rekurencyjnie dla le­wego i prawego poddrzewa, natomiast napis p->s powinien być zwyczajnie wyprowadzony na wyjście. Poprawna funkcja wypisz znajduje się na wydruku poprawionej wersji programu.

Po poprawieniu większości prostych błędów syntaktycznych należy zająć się błędami, które wymagają poprawek w wielu liniach. Spójrzmy na linie zawierające odwołanie do zmiennej korzeń:

6: } korzen

8: void wpisz( char *s, elem **akt, int n ) // elem* przekazany

// "przez zmienną"

51: wpisz( buf, &korzen, numer );

W linii 51 sygnalizowany jest błąd niezgodności typów, jednak nie sposób podwójnie pobrać adresu zmiennej korzen (&&korzen), aby “dopasować” ją do wymagań funkcji. Pochopne utworzenie dodatkowej zmiennej typu elem* (której adres można pobrać i będzie on typu elem **) również nie jest rozwiązaniem słusznym. Należy bowiem raczej zmienić typ zmiennej korzen w linii 6 - pełni ona rolę korzenia drzewa, a taka zmienna zawsze jest typu “wskaźnik do węzła”. Spowoduje to również konieczność usunięcia operatora & w linii 52. W myśl zasad bezpiecznego programowania można wskaźnikowi nadać wartość NULL, mimo że C zapewnia zerowanie zmiennych statycznych.

Po usunięciu błędów kompilacji otrzymaliśmy program pozwalający się uruchomić i generujący pewne wyniki. Można było przystąpić do testowania. W wyniku testowania ustaliliśmy, że program zawiera dalsze błędy nie wykrywane przez kompilator - błędy logiczne. Poprawienie takich błędów wymaga już znajomości logiki konkretnego programu, podczas gdy dotąd bazowaliśmy na wiadomościach ogólnych o języku i komunikatach kompilatora.

W liniach 17, 22 i 27 znajdują się błędy semantyczne, polegające na błędnym posługiwaniu się napisami (char *). Błędy takie są charakterystyczne dla początkujących programistów w C, znających już język Pascal, a są szczególnie niebezpieczne, ponieważ nie są w ogóle sygnalizowane przez kompilator. W C operując na napisach powinniśmy posługiwać się tylko funkcjami z biblioteki string.h. Linie:

17: (*p).s = s;

22: if ( p->s > s )

są poprawne w C, ale oznaczają odpowiednio przypisanie i porównanie wskaźników do napisów, a nie samych napisów. Odpowiednie wywołania funkcji powinny wyglądać tak:

17: strcpy((*p).s,s);

22: if (strcmp( p->s, s ) > 0 )

Ta pierwsza instrukcja jest poprawna, jeżeli istnieje już odpowiednio duży obszar przydzielony wskaźnikowi s. Jeżeli nie (a tak jest w naszym programie przykładowym), należy najpierw przydzielić pamięć:

17: (*p).s = (char *) malloc( strlen(s)+1 );

strcpy((*p).s,s);

Zwracamy uwagę na parametr funkcji malloc. Funkcja strlen zwraca długość napisu bez kończącego go w pamięci bajtu `\0', natomiast przydzielając pamięć musimy go również wziąć pod uwagę. Zapominanie o tym jest kolejnym częstym i niebezpiecznym błędem w posługiwaniu się napisami w C. W linii 17 można było również zastosować funkcję, która tworzy nową kopię napisu i zwraca wskaźnik do przydzielonego obszaru:

17: (*p).s = strdup( s );

W pierwszej części funkcji wpisz znajdują się jeszcze dwa błędy logiczne. Po pierwsze, w linii 11 znajduje się warunek (!p), natomiast powinno być (p). Po drugie, w linii 14 nadajemy nową wartość zmiennej tymczasowej p i na niej operujemy, podczas gdy powinniśmy wykonywać operacje na przekazanym przez wskaźnik polu *akt. Należy w liniach 14-19 zamienić odwołania do zmiennej p wyrażeniami (*akt). We frazie else posługiwanie się zmienną p jest poprawne, ponieważ nie nadajemy jej nowej wartości, a jedynie korzystamy z wartości zainicjowanej wyżej.

Testując program można stwierdzić, że ewentualne powtórzenia wyrazów ma wejściu są ignorowane. Nie jest to właściwe w przypadku programu sortującego. W drugiej części funkcji wpisz znajdują się instrukcje warunkowe, powodujące dopisanie do drzewa wyrazów większych oraz mniejszych od danego, natomiast pozostałe (w tym przypadku równe) są ignorowane. Należy dopisać wywołanie rekurencyjne wpisujące również powtarzające się wyrazy. Podobnie zauważamy, że wyrazy są sortowane malejąco, a nie rosnąco. Należy zmienić znaki nierówności w tej funkcji.

Wątpliwości może budzić istnienie i użycie zmiennej numer i pola n. Kompilator nie sygnalizuje żadnych błędów, ponieważ wszystkie konstrukcje z użyciem tych obiektów są składniowo i semantycznie poprawne, lecz nie są sensowne. Intencją było, aby razem z wyrazem wyprowadzać numer linii, w której wystąpił w pliku wejściowym. Tak więc należy zwiększać go w programie głównym, a nie modyfikować przy każdym wywołaniu rekurencyjnym funkcji wpisz.

Nie tyle błędem, co niekonsekwencją jest niestosowanie zdefiniowanego w linii 7 typu wsk.

Oto postać programu po usunięciu wszystkich błędów:

#include <fstream.h>

#include <alloc.h>

#include <string.h>

struct elem

{ char *s;

int n;

elem *lewy, *prawy;

} *korzen = NULL;

typedef elem * wsk;

void wpisz( char *s, wsk *akt, int n )

{

wsk p = *akt;

if (!p)

{

*akt = (elem *) malloc( sizeof(elem) );

(*akt)->lewy = NULL;

(*akt)->prawy = NULL;

(*akt)->s = (char *) malloc (strlen(s)+1);

strcpy( (*akt)->s, s );

(*akt)->n = n;

}

else

{

if (strcmp( p->s, s ) <= 0 )

{

wpisz( s, &p->prawy, n );

}

else

{

wpisz( s, &p->lewy, n );

}

}

}

void wypisz( wsk p )

{

if (p)

{

wypisz( p->lewy );

cout << p->s << " [" << p->n << ′]′ << endl;

wypisz( p->prawy );

}

}

void main (int argc, char *argv[])

{

int numer=1;

if (argc<2) return;

ifstream fin( argv[1] );

if (!fin) return;

char buf[20];

while (!fin.eof() && fin >> buf)

wpisz( buf, &korzen, numer++ );

wypisz( korzen );

}

Pytania kontrolne

1. Co to jest uruchamianie, z jakich etapów się składa? Kiedy do niego przystępujemy?

2. Co to jest błąd pierwotny, a co wtórny?

3. Jaka jest istotna różnica między testowaniem a uruchamianiem?

4. Podaj podział błędów, ze względu na moment pojawienia się. Wyjaśnij każdą katego­rię.

5. Podaj podział błędów popełnianych na kolejnych etapach tworzenia oprogramowania.

6. Podaj podział błędów, jakie występują w kodzie źródłowym programu. Wyjaśnij i podaj przykłady każdej kategorii.

7. Na czym polega programowanie defensywne?

8. Podaj mechanizmy i środki programowe wspomagające uruchamianie.

9. Podaj możliwości debuggera. W jaki sposób ułatwiają one uruchamianie?

Zadania dla ćwiczących

1. Zapoznanie się z mechanizmami automatycznej kontroli poprawności wykonania pro­gramu i sygnalizowania błędów wykonania, wbudowanymi w kompilator (sprawdza­nie zakresów, przepełnienia stosu, błędów wejścia-wyjścia).

2. Zapoznanie się ze specyfikacją zewnętrzną i zasadą działania przykładowego pro­gramu lub modułu.

3. Poprawienie sygnalizowanych błędów kompilacji (syntaktycznych i semantycznych) w przy­kładowym programie lub module.

4. Przygotowanie systematycznych danych testowych.

5. Wykonanie testowania przykładowego modułu (modułów) wybraną metodą.

6. Wykonanie testowania całego programu przykładowego.

7. Wykrycie i usunięcie błędów wszystkich typów z programu przykładowego.

Zawartość sprawozdania

W sprawozdaniu powinny się znaleźć:

1. Lista błędów kompilacji programu przykładowego (wyjaśnienie przyczyn błędu, spo­sób po­prawy, ewentualnie omówienie różnych sposobów poprawy danego błędu).

2. Systematyczne dane testowe, względem kodu lub specyfikacji, zgodnie z instrukcjami pro­wadzącego wraz z uzasadnieniem doboru danych na podstawie przedstawionych metod lub zasad doboru danych testowych oraz spodziewane wyniki odniesienia.

3. Opis przebiegu testowania i uruchamiania, obejmujący zestaw danych testowych, efekt uru­chomienia programu dla tych danych, hipotezę o błędzie i jego kategorii, propozy­cję po­prawy i efekt testowania powrotnego.

4. Listing poprawionego programu lub modułu.

5. Uwagi na temat specyfikacji, ewentualne jej zmiany i uściślenia powstałe w toku uru­chamia­nia.

6. Omówienie wskazanego przez prowadzącego mechanizmu diagnostycznego, wbudo­wa­nego w środowisko IDE i sposobu posługiwania się nim w toku uruchamiania.

7. Wnioski.

Literatura

1. D. Van Tassel: Praktyka programowania. WNT, Warszawa 1989.

2. G. J. Myers: Projektowanie niezawodnego oprogramowania. WNT, War­szawa 1980.

3. A. Jaszkiewicz: Inżynieria oprogramowania. Helion, Gliwice 1997.




rozdział 3

Optymalizacja czasowa programów

3. Optymalizacja czasowa programów

1. Wstęp

Program, który nie musi być poprawny,
można uczynić tak sprawnym, jak tylko dusza zapragnie
Dennie Van Tassel

Pisząc programy zwykle chcemy, by były one sprawne. Przytoczona powyżej zasada Van Tas­sela przypomina jednak, że w dążeniu do usprawniania (optymalizacji) programów mu­simy zawsze mieć na uwadze, że podstawowym wymaganiem, jakie stawiamy programom, jest niezawodność. Gdy coś nie działa, jego sprawność nie ma żadnego znaczenia - to jeszcze jedna maksyma Van Tassela spośród zebranych w książce Praktyka programowania.

Programy należy dobrze projektować i pisać, przede wszystkim mając na uwadze ich po­praw­ność i niezawodność, a niekoniecznie zważając zbytnio na sprawność. Następnie, jeżeli program jest rzeczywiście pożyteczny, jeżeli będzie wielokrotnie używany, jeżeli mieści się to w celach całego przedsięwzięcia - wtedy (i tylko wtedy) powinno się pomyśleć o optymalizacji. Projektując pro­gram należy zaplanować, jak sprawny musi on być. Progra­mistycznym tandeciarzem jest ktoś, kto skraca o 10 mikrosekund czas wykonywania rzadko używanego programu, tracąc na to wiele go­dzin i ryzykując wprowadzenie błędów.

W sytuacjach, gdy działający program ma niezadowalającą efek­tywność czasową i wymagane jest jego przyspieszenie, możliwe są dwa podejścia:

1. zaprojektowanie programu od nowa z użyciem lepszych algoryt­mów bądź innych struktur danych,

2. próba usprawnienia fragmentów programu bez zmiany całego projektu.

Podejście (a) na ogół daje lepsze wyniki, ale wymaga wię­kszego nakładu czasu programi­sty. Czasami podejście (b) daje już zadowalające efekty przy mniejszym wysiłku programisty i właśnie tym podejściem zajmiemy się w niniej­szym opracowaniu.

1. Kryteria wyboru fragmentu do optymalizacji

Jeżeli decydujemy się na optymalizację programu, przede wszystkim musimy ustalić, co należy w nim usprawnić. Podstawowym pytaniem, jakie zadać sobie należy przed przystąpie­niem do optymalizacji programu, jest czy wysiłek, czas i koszty realizacji planowanych usprawnień znajdują uzasadnienie w odpowiednim zwiększeniu funkcjonalnej lub rynkowej wartości programu.

Optymalizując program warto jest mieć na uwadze następujące cztery aspekty:

1. Profil dynamiczny programu, czyli procent czasu zużywany przez każdy podprogram lub inny fragment programu. Nie warto ulepszać podprogramów, których wykonanie stanowi nie­wielki ułamek całkowitego czasu wykonania programu.

2. Procent optymalizacji możliwy do osiągnięcia w poszczególnych fragmentach pro­gramu. Nie warto ulepszać tych fragmentów programu, w których można uzyskać je­dynie stosunkowo niewielką optymalizację wysokim kosztem.

3. Celowość optymalizacji różnych fragmentów programu: na przykład czasami rezy­gnuje się z usprawniania rzadko używanych opcji programu. Dla programów komer­cyjnych na opłacal­ność optymalizacji mogą mieć wpływ takie czynniki, jak konkuren­cyjność, atrakcyjność, re­klama. W pewnych zastosowaniach, jak systemy czasu rze­czywistego, a także niektóre pro­gramy interakcyjne, zakłada się maksymalny dopusz­czalny czas reakcji systemu, co może wymusić konieczność optymalizacji.

4. Czas (lub liczbę osobogodzin), który trzeba spędzić nad usprawnianiem poszczegól­nych fragmentów. Czas jest czynnikiem decydującym o opłacalności optymalizacji tych fragmentów.

W celu uzyskania pożądanej poprawy czasowej należy wybrać taki fragment, którego optymali­zacja da istotne zmniejszenie czasu pracy programu. W wyniku badań stwierdzono, że w bardzo wielu programach występuje tzw. region krytyczny - stosunkowo niewielki objętościowo frag­ment kodu (ok. 10% całości), który jest wykonywany przez przeważającą część całego czasu pracy programu (ok. 90% całości). Wynik tych analiz jest znany jako
reguła 90­-10.

Można podać trzy metody znajdowania regionów krytycznych:

1. wyznaczenie profilu dynamicznego,

2. pomiar czasu wykonywania pewnych fragmentów, np. podprogramów,

3. wygenerowanie histogramu z wykorzystaniem przerwań zegarowych.

Profil dynamiczny zawiera informację o częstości wykonywania poszczególnych instruk­cji pro­gramu źródłowego dla określonego zestawu danych wejściowych. Jego wyznaczenie jest tą  spośród wymienionych metod, którą stosunkowo najefektywniej da się zrealizować automatycznie, za po­mocą specjalnie do tego celu przeznaczonego oprogramowania. W systemie Turbo Pascal profil uzysku­je się z wykorzystaniem programu Turbo Profiler. Czas wykonania fragmentów programu w systemie Turbo Pascal można zmierzyć używając wbudowanej procedury bibliotecznej GetTime oraz używając własnej funkcji skalującej od­stęp czasu.

Po oszacowaniu procentowego udziału fragmentów programu w całym czasie działania (po­przez profil lub pomiar czasu) należy oszacować możliwe procen­towe skrócenie czasu działania poszcze­gólnych fragmentów. Na tej podstawie należy wybrać fragment do optyma­lizacji.

Przykład 3.1

Oto sposób pomiaru czasu wykonania pewnej procedury za pomocą podprogramu biblio­tecz­nego Turbo Pascala, GetTime:

type

czas = record

godz, min, sek, sek100: word

end;

var

tp, tk: czas;

…

begin

with tp do

GetTime (godz, min, sek, sek100);

sort(tab);

with tk do

GetTime (godz, min, sek, sek100);

writeln('Czas wykonania procedury sort wynosi ',

OdstepCzasu (tk, tp) * 100);

end;

Oszacowanie procentu możliwych ulepszeń jest zadaniem trudnym i wymagającym od progra­misty doświadczenia. Jako wskazówkę proponuje się przeanalizowa­nie wybranych fragmentów pod kątem opisanych poniżej metod optymalizacji i stwierdzenie, które z nich można zastosować.

Czynnikiem utrudniającym ocenę sprawności programów jest zależność czasu realizacji (złożoności) algorytmów od danych wejściowych. Rozróżnia się złożoność optymistyczną, pesymi­styczną i średnią. Warto jest dokonać osobnych pomiarów sprawności programu dla różnych ze­stawów danych, by określić minimalny, maksymalny i średni czas wykonania oraz rozrzut (odchylenie standardowe).

Przykład 3.2

Oto wyniki analizy pewnego hipotetycznego programu:

		% czasu wyko­nania	% możliwych ulep­szeń	zysk w %
	Fragment A	50	5	2.5
	Fragment B	10	25	2.5
	Fragment C	1	100	1

O wyborze fragmentu do optymalizacji powinien zadecydować czynnik ekonomiczny; z tabeli wynika, że optymalizacja fragmentu C jest najmniej opłacalna.

1. Wybrane metody optymalizacji czasowej

W tym punkcie zostaną krótko scharakteryzowane niektóre metody optymalizacji.

1. Zwijanie

Zwijanie polega na wykonywaniu pewnych czynności na etapie kompila­cji, a nie na etapie wy­konywania programu. Takie czynności to np. inicjalizowanie zmiennych (w Turbo Pas­calu możliwe dla zmiennych global­nych skalarnych i strukturalnych poprzez użycie odmiany deklaracji const), wy­liczanie wartości wyrażeń, w których występują tylko stałe.

2. Zmniejszanie siły operacji

Metoda ta polega na zastępowaniu operacji czasochłonnych operacjami szybszymi, np. zamiast potęgowania używać mnożenia (np. a^3 zastąpić przez a*a*a), zamiast mnożenia uży­wać dodawania (np. a*2 zastąpić przez a+a).

3. Usuwanie wyrażeń nadmiarowych

W metodzie tej powtarzające się wyrażenia lub podwyrażenia oblicza się tylko raz, ich wartość przypisuje się zmiennej, a następnie odwołuje się do wartości tej zmiennej.

Przykład 3.3

Ciąg instrukcji:

x := sqrt(z) / sin(y) + 16;

w := sqrt(z);

u := fun (sqrt(z) / sin(y));

zastępujemy przez:

t1 := sqrt(z);

t2 := t1 / sin(y);

x := t2 + 16;

w := t1;

u := fun (t2);

4. Usuwanie wyrażeń niezmienniczych

Metoda ta polega na jednokrotnym wyliczeniu przed pętlą wartości wyrażenia, którego wartość nie zależy od zmiennej sterującej, ani od innych zmiennych modyfikowanych w pętli.

Przykład 3.4

Konstrukcję:

for i := 1 to 100 do

a[i] := sin(y) * a[i];

zastępujemy przez:

t1 := sin(y);

for i := 1 to 100 do

a[i] := t1 * a[i];

5. Rozszczepianie

Metoda ta stosowana jest w przypadku, gdy wewnątrz pętli występuje instrukcja warun­kowa, a wartość warunku nie zależy od zmiennej sterującej pętli.

Przykład 3.5

Konstrukcję:

for i := 1 to 100 do

if dodaj

then a := a + n

else a := a - n;

zastępujemy przez:

if dodaj then

for i := 1 to 100 do

a := a + n

else

for i := 1 to 100 do

a := a - n

6. Rozwijanie pętli

Rozwijanie polega na zwiększeniu kroku pętli w celu zmniej­szenia liczby sprawdzeń wa­runku zakończenia pętli.

Przykład 3.6

Ciąg instrukcji:

i := 0;

while i < 300 do

begin

a[i] := 0;

i := i + 1;

end;

zastępujemy przez:

i := 0;

while i < 300 do

begin

a[i] := 0;

a[i+1] := 0;

a[i+2] := 0;

i := i + 3;

end;

7. Łączenie pętli

Przykład 3.7

Ciąg instrukcji:

for i := 1 to 100 do

a[i] := 0;

for i := 1 to 100 do

b[i] := 0;

zastępujemy przez:

for i := 1 to 100 do

begin

a[i] := 0;

b[i] := 0;

end;

8. Optymalizacja pętli zagnieżdżonych przez reorganizację

O ile jest to możliwe, należy pętle zorganizować w ten sposób, by pętle zewnętrzne były powtarzane najmniej razy.

Przykład 3.8

Konstrukcję:

for i := 1 to 20 do { otwarcie pętli 1 raz }

for j := 1 to 10 do { otwarcie pętli 20 razy }

for k := 1 to 5 do { otwarcie pętli 200 razy }

begin

…

end; { zamknięcie pętli dla k 1000 razy }

{ zamknięcie pętli dla j 200 razy }

{ zamknięcie pętli dla i 20 razy }

zastępujemy przez:

for k := 1 to 5 do { otwarcie pętli 1 raz }

for j := 1 to 10 do { otwarcie pętli 5 razy }

for i := 1 to 20 do { otwarcie pętli 50 razy }

begin

…

end; { zamknięcie pętli dla i 1000 razy }

{ zamknięcie pętli dla j 50 razy }

{ zamknięcie pętli dla k 5 razy }

W pierwszym przypadku było 221 otwarć pętli i 1220 zamknięć pętli, w przypadku dru­gim 56 otwarć i 1055 zamknięć pętli.

9. Optymalizacja instrukcji warunkowych

W instrukcjach warunkowych należy stosować człon else.

Przykład 3.9

Ciąg instrukcji:

if x = 1 then p1;

if x = 2 then p2;

if x = 3 then p3;

zastępujemy przez:

if x = 1 then p1 { jeśli x = 1 reszta nie jest wykonywana }

else if x = 2 then p2

else if x = 3 then p3;

W sytuacji, gdy kompilator generuje dla złożonych wyrażeń logicznych taki kod, że war­tościo­wanie wyrażenia jest przerywane w momencie, gdy znana jest wartość wyrażenia, na­leży:

1. dla wyrażeń z operatorem and - podwyrażenie, które zazwyczaj ma wartość false, umieścić na początku wyrażenia,

2. dla wyrażeń z operatorem or - podwyrażenie, które zazwyczaj ma wartość true, umie­ścić na początku wyrażenia.

1. Odwołania do elementów tablic

W przypadku wielokrotnego odwołania do tego samego elementu tablicy, należy wartość tego elementu podstawić pod zmienną prostą (jest to szczególny przypadek metod opisanych w punktach 3.3.3 i 3.3.4).

Przykład 3.10

Instrukcję:

x := a[i] + a[i] * a[i];

zastępujemy przez:

ai := a[i];

x := ai + ai * ai;

Przykład 3.11

Konstrukcję:

for i := 1 to 100 do

a[i] := b[ k + 2 * j ];

zastępujemy przez:

bb := b[ k + 2 * j ];

for i := 1 to 100 do

a[i] := bb;

2. Odwołania do pól rekordów

W przypadku wielokrotnego odwołania do pojedynczego pola rekordu, którego adres musi być obliczany w trakcie wykonania programu, należy jego war­tość podstawić pod zmienną prostą (jest to przypadek szczególny metody opisanej w punkcie 3.3.3). Adres miej­sca w pamięci skojarzonego z polem rekordu jest obliczany jako suma adresu pierwszego pola w rekordzie i przesunięcia, które dla każdego z pól ma ustaloną wartość. Na ogół oba składniki adresu pola są ustalane na etapie kompilacji, przez co proponowana zmiana de facto spowalnia wykonanie programu, zamiast je przyspieszać. Konieczność obliczania adresu w czasie wykonywania programu zachodzi wyłącznie wtedy, gdy dostęp do danej typu rekor­dowego realizowany jest pośrednio - za pomocą zmiennej wskaźnikowej lub tablicowej, i tylko wtedy opisywana metoda może przyspieszyć wykonywanie programu.

W przypadku odwołania do wielu pól tego samego rekordu można używać instrukcji wiążącej with.

Przykład 3.12

Instrukcje:

x := 2 * a^[i].pole1;

y := 1 / a^[i].pole1;

z := a^[i].pole1 * a^[i].pole1;

zastępujemy przez:

pole1 := a^[i].pole1;

x := 2 * pole1;

y := 1 / pole1;

z := pole1 * pole1;

3. Rozwijanie procedur i funkcji

Istnieje metoda optymalizacji wywołań procedur i funkcji, która nosi nazwę rozwijania. Stosuje się ją dla krótkich podprogramów wywoływanych w niewielu miejscach. Polega ona na wstawie­niu w miejsce wywołania podpro­gramu jego ciała po podstawieniu wartości para­metrów.

4. Zastosowanie kompilatora optymalizującego

Zastosowanie kompilatora optymalizującego powoduje, że wiele spośród opisanych wy­żej me­tod optymalizacji jest implementowanych automatycznie na etapie kompilacji, zwal­niając programi­stę z konieczności modyfikowania swoich programów. Jest to szczególnie cenne z uwagi na fakt, że niektóre metody optymalizacji negatywnie wpływają na przejrzy­stość kodu źródłowego programów.

Większość współczesnych kompilatorów posiada bardzo zaawansowane funkcje optyma­lizacji kodu. Należy zwrócić uwagę na fakt, że często domyślnie stosowane są parametry pracy wyłącza­jące niektóre lub nawet wszystkie metody optymalizacji - po to, by przyspie­szyć kompilację na eta­pie uruchamiania i wstępnego testowania programu. Należy więc pa­miętać o załączeniu odpowied­niego zestawu opcji optymalizujących, i to nie tylko przed wy­puszczeniem końcowej wersji opro­gramowania, ale przed przejściem do fazy zaawansowane­go testowania. Jest to bardzo ważne: to, że przetestowałeś program kompilo­wany bez opty­malizacji nie oznacza, że program zoptymalizo­wany również będzie poprawny. Włączenie optymalizacji kodu może zmienić zachowanie się programu w tych sytuacjach, w których to zachowanie nie jest jasno zdeterminowane; krótko mówiąc, może spowodować uaktywnienie się tych błędów programu, które w poprzedniej wersji przez przypadek nie dawały za­uważal­nych symptomów.

5. Podsumowanie

Znaczenie takich metod, jak: zwijanie wyrażeń, zmniejszanie siły operacji, usuwanie wy­rażeń nadmiarowych i niezmienniczych, rozszczepianie, niektóre aspekty optymalizacji in­strukcji warun­kowych i odwołań do tablic i rekordów może być znikome w przypadku zasto­sowania kompilatora optymalizującego - przyjrzyj się opcjom, jakim dysponuje twój kompi­lator i wyciągnij z tego wnio­ski.

Niektóre metody optymalizacji mają negatywny wpływ na przejrzystość kodu źródło­wego, a tym samym mogą wpłynąć na obniżenie niezawodności oprogramowania. Należy tu wymienić przede wszystkim rozwijanie pętli, a także procedur i funkcji, łączenie pętli, a w mniejszym stopniu również zwijanie wyrażeń, zmniejszanie siły operacji, czasami też nadmierne usuwanie wyrażeń nadmiarowych i niezmienniczych. Z drugiej strony wiele czyn­ności optymalizujących może też wpły­nąć na lepsze uporządkowanie tekstu programu; może to dotyczyć takich metod, jak usuwanie wy­rażeń nadmiarowych i niezmienniczych, rozszcze­pianie, optymalizacja odwołań do elementów tablic i rekordów.

Najistotniejsze są optymalizacje dotyczące dużych i często wykonywanych fragmentów pro­gramów, szczególnie pętli. Zaakcentować tu należy optymalizację poprzez usuwanie wy­rażeń nie­zmienniczych, rozszczepianie, a także optymalizację pętli i instrukcji warunkowych. Niektóre opty­malizacje tego typu nie są wykonywane przez kompilator!

1. Czynniki uboczne wpływające na sprawność
   pro­gra­mów

Wpływ na sprawność programów może mieć szereg czynników nie wynikających bezpo­średnio z treści programu. W wielu takich przypadkach metody przedstawione w poprzednim punkcie nie znajdują zastosowania.

Należy się liczyć z możliwością zafałszowania pomiarów sprawności programów przez opisy­wane czynniki. Niektóre z nich mogą mieć charakter niedeterministyczny, co szczegól­nie utrudnia ich ocenę, a nawet wykrycie. Wiarygodność pomiarów można zwiększyć wyko­nując pomiary większej liczby wykonań analizowanych grup instrukcji, i określając średni czas wykonania oraz odchylenie standardowe (jeśli nie ścisłymi metodami statystycznymi - to chociaż „na oko”).

Eliminacja opóźnień wynikających z występowania czynników nie wynikających bezpo­średnio z treści programu może na tyle skutecznie poprawić parametry programu, że dalsza jego optymaliza­cja może nie być konieczna (szczególnie polecamy analizę konfiguracji translatora - por. punkt 3.5). Z drugiej strony, program uznany za dostatecznie sprawny może, np. po przeniesieniu do nowego śro­dowiska, znów wymagać optymalizacji.

Poniżej zostały opisane czynniki uboczne wpływające na sprawność programów. Opis rozpo­czyna się od czynników najistotniejszych.

1. Operacje wejścia-wyjścia

Operacje wejścia-wyjścia są szczególnie czasochłonne. Czas ich wykonywania często w spo­sób istotny wpływa na czas działania programu. Skrajnym przykładem są operacje inter­akcyjne (np. wprowadzanie tekstu lub dialog z użytkownikiem).

Ze względu na wyjątkowo długi czas wykonywania operacje wejścia-wyjścia należy zaw­sze optymalizować oddzielnie od reszty kodu. Do ich optymalizacji można zasto­sować więk­szość z opisanych w punkcie 3.3 metod.

Optymalizacja kodu towarzyszącego wywołaniom operacji wejścia-wyjścia jest najczę­ściej mało opłacalna. Na przykład, efekt zastosowania metody rozszczepiania (por. punkt 3.3.7) do nastę­pującego fragmentu programu:

for i:=1 to 100 do

if pisz then writeln(a[i])

else readln(a[i]);

nie będzie zauważalny, gdyż czas wykonywania instrukcji warunkowej jest zaniedbywalnie mały w porównaniu z czasem wykonywania instrukcji wejścia-wyjścia.

Bardzo się natomiast opłaca optymalizować same operacje wejścia-wyjścia. Szczególnie ko­rzystna jest eliminacja niektórych operacji wejścia-wyjścia, możliwa dzięki zbuforowaniu raz wczy­tanych danych w pamięci. Wiele systemów programowych oferuje również mecha­nizmy symulujące działanie urządzeń wejścia-wyjścia za pomocą tzw. strumieni pamięcio­wych.

2. Dodatkowe czynniki wpływające na sprawność operacji wejścia-wyj­ścia

Czas wykonywania operacji wejścia-wyjścia, a w szczególności operacji dyskowych oraz gra­ficznych, zależy zarówno od parametrów sprzętowych systemu komputerowego, w któ­rym wykonujemy program, jak i od konfiguracji programowej. Do tej ostatniej zaliczyć można: sposób buforowania danych, wielkość bufora, potrzebę i rodzaj formatowania danych (zmiany reprezentacji danych), sprawność usług oferowanych przez system operacyjny (lub inne środowisko pracy pro­gramu). W zależności od środowiska i stosowanych narzędzi, pro­gramista może mieć wpływ na niektóre z tych czynników.

Bardzo często czas trwania operacji wejścia-wyjścia nie może być zdeterminowany. Do­tyczy to operacji interakcyjnych, których czas trwania zależy od reakcji użytkownika; opera­cji dyskowych z zastosowaniem tzw. pamięci cache - czas ich trwania zależy od zawartości tej pamięci; operacji na dyskach sieciowych, na które wpływa obciążenie sieci, czy wreszcie operacji graficznych w śro­dowiskach okienkowych, których czas realizacji jest zależny od chwilowego układu okienek na ekranie.

2. Translator i jego konfiguracja

Jest dość oczywiste, że o sprawności programu w dużej mierze decyduje użyty translator.

Translatory zwykle zawierają pewne opcje wspomagające uruchamianie programów, czę­sto wprowadzające jednak dość znaczny - i zupełnie niepotrzebny w gotowym produkcie - narzut cza­sowy. I tak, sprawność programu można poprawić usuwając dyrektywy kompila­tora wprowadza­jące dodatkowe informacje dla debuggera, a także kontrolę za­kresu tablic, stosu, przepełnienia itp. (oczywiście, powinniśmy to zrobić dopiero po ukończe­niu procesu uruchamiania programu). Niektóre dyrektywy kompilatorów pozwalają na wyko­rzystanie cech charakterystycz­nych dla procesora, jak efektywniejsze tryby adresacji, wyrów­nywanie adre­sów do granicy słów i ich wielokrotności, zastosowanie rozkazów z nowszej serii proce­sora, czy wreszcie wykorzystanie koprocesora. Opcje włączające generowanie zopty­ma­li­zo­wa­nego kodu wynikowego opisaliśmy w punkcie 3.3.13.

1. Narzut wprowadzany przez system operacyjny

Nawet nie licząc jawnych odwołań do usług systemu operacyjnego, sam fakt istnienia i funkcjo­nowania systemu operacyjnego wpływa na czas wykonywania programu. Większość systemów operacyjnych wykonuje określone operacje równolegle z działaniem programu, w tak zwanym tle. W systemie MS-DOS obsługiwane są przerwania zegarowe; swój udział mają też tak zwane pro­gramy rezydentne (TSR). Nie jest to jednak duży narzut.

Zupełnie inaczej rzecz się ma z systemami graficznymi, jak Microsoft Windows, oraz systemami wielodostępnymi, jak Unix. Działanie programów może być czasem znacznie spowolnione, gdyż zarówno aktywność systemu operacyjnego, jak i uruchomione jednocze­śnie w systemie inne pro­cesy użytkowe mogą wprowadzać znaczny narzut.

Obciążenie wprowadzane przez system operacyjny czasami się obniża poprzez rezygna­cję z niektórych usług lub warstw systemu i odwoływanie się wprost do operacji na niższym po­ziomie (np. bezpośredni dostęp do pamięci obrazu w MS-DOS lub tzw. 32-bitowy dostęp do dysku w Windows).

2. Wielozadaniowość i wielodostęp

Wiele systemów operacyjnych zapewnia wielozadaniowość i wielodostęp. Wiąże się to z po­działem czasu procesora pomiędzy różne procesy i zmniejsza sprawność poszczegól­nych wykonywanych programów. Zmniejszenie sprawności ma często charakter niedetermi­ni­styczny.

3. Pamięć wirtualna i nakładkowanie

Pamięć wirtualna to mechanizm umożliwiający procesorowi dostęp do przestrzeni adre­sowej większej niż wielkość zainstalowanej pamięci operacyjnej. Część zawartości pamięci wirtualnej, która nie mie­ści się w pamięci operacyjnej, jest przechowywana w pamięci dyskowej i może być załadowana w razie potrzeby do pamięci operacyjnej. Ten właśnie proces jest przyczyną dość znacznego i całkowicie niedeterministycz­nego obniżenia sprawności programów.

Podobny wpływ na obniżenie sprawności programów ma nakładkowanie.

4. Gospodarka pamięcią dynamiczną

Dynamiczne tworzenie i usuwanie zmiennych wprowadza pewien, stosunkowo niewielki, narzut czasowy. Dynamiczne utworzenie zmiennej wymaga przeglądania wolnych pozycji na stogu. Algo­rytmy przydziału pamięci dynamicznej, które minimalizują zjawisko tzw. fragmentacji pa­mięci, są realizo­wane nieco dłużej, a wydłużenie czasu ich trwania ma charakter niedetermi­ni­styczny.

Dostęp do zmiennych dynamicznych (za pomocą wskaźników) może być minimalnie wolniejszy od dostępu do zmiennych statycznych. Różnice są jednak na tyle niewielkie, że sprawność z tym związana nie powinna decydować o wyborze pomiędzy statycznym a dynamicznym przydziałem pamięci.

Niektóre systemy z dynamicznym przydziałem pamięci dla zmiennych, jak Lisp, Java, Small­talk czy Clipper, realizują dodatkowe operacje związane ze zwalnianiem nie używa­nych już zmien­nych (tzw. garbage collection).

5. Zmienne lokalne a zmienne globalne

Dostęp do zmiennych lokalnych trwa nieco dłużej niż dostęp do zmiennych globalnych. Wynika to z faktu, że zmienne globalne mają ustalone, bezwzględne adresy w pamięci, pod­czas gdy zmienne lokalne są tworzone dynamicznie w obszarze stosu maszynowego. Adres zmiennej lokalnej jest przy każdym dostępie obliczany na podstawie położenia stosu oraz przesunięcia charaktery­stycznego dla danej zmiennej.

Różnice są jednak na tyle niewielkie, że poza sytuacjami wyjątkowymi sprawność roz­wiązania nie powinna decydować o zastosowaniu zmiennej globalnej zamiast lokalnej.

3. Uwagi końcowe

Pomiędzy optymalizacją programów a dążeniem do stworzenia przejrzystego (a więc bar­dziej nie­zawod­nego) programu zachodzi głęboka sprzeczność. Na programiście spoczywa ciężar znalezie­nia rozwiąza­nia kompromisowego.

Niemal każda z opisanych metod optymalizacji może ograniczyć zrozumiałość programu a na­wet pogorszyć jakość konstrukcji całego programu. Do skrajnych przykładów należy po­dyktowana względami sprawnościowymi redukcja zmiennych lokalnych na rzecz zmiennych globalnych.

Najlepszym rozwiązaniem jest stosowanie nowoczesnych kompilatorów optymalizują­cych (np. kompilatory języka C/C++ firm Borland i Microsoft), które wprowadzają wiele spośród opi­sanych metod optymalizacji w sposób automatyczny, reorganizując wynikowy kod programu. Chroni to nie tylko przed pomyłkowym lub wynikającym z braku doświad­czenia nieuwzględnie­niem możliwości optymalizacji kodu. Programista może też świadomie unikać pewnych optymaliza­cji, zachowując większą przejrzystość kodu programu i jednocześnie wiedząc, że stosowna opty­malizacja zostanie wprowadzona automatycznie przez kompilator. Należy się jednak zapoznać z możliwościami stosowanego kompilatora.

4. Programy przykładowe

Poniżej prezentujemy krótki program przykładowy, wyznaczający i wyświetlający wszystkie liczby pierwsze w zakresie od 1 do 1000, oraz kilka możliwych do przeprowadzenia w tym programie sposobów optymalizacji.

Oto wyjściowa postać programu:

#include <stdio.h>

int pierwsza(int n)

{

int i;

for (i = 2; i < n; i++)

if (n % i == 0)

return 0;

return 1;

}

void main(void)

{

int i, n = 1000;

for (i = 2; i <= n; i++)

if (pierwsza(i))

printf("%d\n", i);

}

Jak widać, program, aby stwierdzić, czy jakaś liczba jest, czy nie jest liczbą pierwszą, próbuje znaleźć jakiś jej podzielnik rozpatrując wszystkie liczby z przedziału 2..n-1. Program można dość znacznie usprawnić wykorzystując fakt, że podzielniki liczby n wykrywane są zawsze parami: n = p₁ * p₂. Szukając systematycznie różnych par podzielników można brać pod uwagę tylko te pary p₁ i p₂, w których p₁
p₂. Ponieważ wartość mniejszego podzielnika p₁ nie może być większa niż
, zatem bezpiecznie można zmniejszyć zakres pętli, definiując ją w sposób następujący:

for (i = 2; i <= (int)sqrt(n); i++)

Następnie, usuwając wyrażenie niezmiennicze sqrt(n), oszczędzamy na wielokrotnym obliczaniu dość złożonej funkcji, i w efekcie otrzymujemy następujący program:

#include <stdio.h>

#include <math.h>

int pierwsza(int n)

{

int i, limit;

limit =(int)sqrt((float)n);

for (i = 2; i <= limit; i++)

if (n % i == 0)

return 0;

return 1;

}

void main(void)

{

int i, n = 1000;

for (i = 2; i <= n; i++)

if (pierwsza(i))

printf("%d\n", i);

}

Kolejna modyfikacja znowu bazuje na pewnej własności algorytmu: mianowicie po stwierdzeniu, że liczba nie jest podzielna przez 2, można już nie sprawdzać podzielności przez żadną inną liczbę parzystą. W poniższym programie zastosowano ponadto częściowe rozwinięcie pętli: dla liczb podzielnych przez 2, 3 lub 5 instrukcja pętli w ogóle nie będzie wykonywana:

#include <stdio.h>

int pierwsza(int n)

{

int i;

if (n % 2 == 0)

return (n==2);

if (n % 3 == 0)

return (n==3);

if (n % 5 == 0)

return (n==5);

for (i=7; i*i <= n; i+=2)

if (n % i == 0)

return 0;

return 1;

}

void main(void)

{

int i, n = 1000;

for (i=2; i<=n; i++)

if (pierwsza(i))

printf("%d\n", i);

}

Zauważ, że dość czasochłonne obliczenie pierwiastka kwadratowego zastąpiono dużo szybszym wyrażeniem warunkowym i * i <= n; nie może ono jednak zostać wyłączone z pętli jako wyrażenie niezmiennicze; takie rozwiązanie sprawdza się tylko wtedy, gdy liczba iteracji nie jest wielka. W przedstawionym algorytmie, przy poszukiwaniu liczb z zakresu 1..1000, założenie to jest na ogół słuszne, choć dopiero eksperyment wykazać może przewagę jednego lub drugiego podejścia w danej implementacji; wszak wszystko zależy od tego, z jak dobrej biblioteki korzystamy, by wyliczyć pierwiastek kwadratowy.

Podsumowując, należy zauważyć, że bardzo często znacznie lepszy skutek uzyskujemy stosując wydajniejszy algorytm (w tym przypadku wydatnie zmniejszyliśmy liczbę iteracji), podczas gdy drobne usprawnienia, jak usuwanie wyrażeń niezmienniczych czy rozwijanie pętli, mają mniejsze znaczenie dla sprawności programu. Na zakończenie przedstawiamy jeszcze jedno rozwiązanie, oparte na tzw. algorytmie Euklidesa. Jest ono znacznie wydajniejsze czasowo, wymaga jednak zastosowania dodatkowej tablicy (zatem jest mniej efektywne pamięciowo):

#include <stdio.h>

int pierwsze[1000];

#define MAX 1000

void main(void)

{

int j, poprzednia, aktualna;

pierwsze[0] = 2;

pierwsze[1] = 3;

poprzednia = 1;

aktualna = 3;

printf("Pierwsza %d = %d\n", 0, pierwsze[0]);

printf("Pierwsza %d = %d\n", 1, pierwsze[1]);

while(aktualna < MAX)

{

for(j = 0; j <= poprzednia; j++)

if ((aktualna % pierwsze[j]) == 0)

{

aktualna += 2;

break;

}

if(j <= poprzednia)

continue;

poprzednia++;

printf("Pierwsza %d = %d\n", poprzednia, aktualna);

pierwsze[poprzednia] = aktualna;

aktualna += 2;

}

}

Pytania kontrolne

1. Co to jest region krytyczny i reguła 90­-10?

2. Podaj metody znajdowania regionu krytycznego.

3. Na czym polega zwijanie?

4. Co to jest zmniejszanie siły operacji?

5. Na czym polega usuwanie wyrażeń nadmiarowych i niezmien­niczych?

6. Podaj metody optymalizacji pętli.

7. Na czym polega optymalizacja instrukcji warunkowych?

8. W jaki sposób można optymalizować odwołania do elementów tablic i do pól rekor­dów?

9. Podaj sposób optymalizacji podprogramów.

10. Po co stosuje się wielokrotne pomiary czasu wykonania tych samych instrukcji?

11. Dlaczego operacje wejścia-wyjścia należy optymalizować oddzielnie?

12. Od czego zależy czas wykonywania operacji wejścia-wyjścia?

13. Omów nie wynikające z treści programu czynniki, które mogą wpływać na czas wy­ko­nania programu?

14. Jak system operacyjny może wpływać na czas wykonania programów?

15. Jaka jest zależność między lokalnością obiektu a czasem odwołania do tego obiektu?

16. Podaj zalety korzystania z kompilatorów optymalizujących.

Zadania dla ćwiczących

1. Zmierzyć i porównać czasy wykonania wskazanego programu dla wybra­nych zesta­wów da­nych wejściowych i różnych kombinacji opcji kompilacji.

2. Zmierzyć i porównać czasy wykonania:

• programu w postaci pierwotnej,

• programu z pominięciem operacji wyprowadzania danych,

• programu, w którym zastosowano głównie zmienne global­ne, zmienne lokalne, zmienne nielokalne,

• programu, w którym wykonano inne zmiany określone przez prowadzącego.

Pomiary przeprowadzić dla tych samych zestawów danych wejściowych i opcji kompilacji.

3. Zoptymalizować badany program. Prace rozpocząć od sporządzenia profilu i jego ana­lizy.

Zawartość sprawozdania

W sprawozdaniu powinny się znaleźć:

1. Wyniki pomiarów zrealizowanych w zadaniach 1 i 2 oraz ich dyskusja.

2. Treść badanego programu w wersji początkowej.

3. Raport kompilacji programu po optymalizacji z zaznaczeniem wprowadzonych zmian.

4. Opis wprowadzonych zmian wraz z uzasadnieniem oraz ocena osiągniętego efektu.

LITERATURA

1. D. Van Tassel: Praktyka programowania. WNT, Warszawa 1989.

2. A. Jaszkiewicz: Inżynieria oprogramowania. Helion, Gliwice 1997.




DODATEK A

Diagramy przepływu sterowania

1. Diagramy przepływu sterowania

Jedną z faz testowania modułu jest sprawdzenie jego logiki. Odpowiedni dobór danych testo­wych często stanowi dość poważny problem. Chodzi o to, by przy jak najmniejszej licz­bie testów doprowadzić do co najmniej jednorazowego wykonania każdej instrukcji w module. Należy więc tak przygotować dane testowe, by spowodować wykonanie każdego rozgałęzienia w schemacie modułu. Można do tego wykorzystać diagram przepływu sterowa­nia.

Diagram przepływu sterowania (ang. flow diagram) jest to graf skierowany obrazujący strukturę rozgałęzień programu.

Każdy węzeł (oznaczany kółkiem) reprezentuje sekwencyjny fragment programu. Przez poję­cie se­kwencyjnego fragmentu programu rozumiemy ciąg instrukcji znajdujących się między punktami decyzyj­nymi i skokami, którego wykonanie zaczyna się zawsze od pierw­szej in­strukcji.

Krawędzie grafu odpowiadają połączeniom między segmentami programu, tworzonym po­przez przepływ sterowania podczas wykonania programu. Dla węzłów, po których nastę­puje rozgałęzie­nie kodu, przyjmuje się, że gałąź górna jest wybierana w przypadku spełnienia wa­runku, gałąź dolna, gdy wynik testu jest negatywny.







test






Dla przykładowego fragmentu modułu zapisanego w technice pseudokodu:

...

<< fragment A >>

if (x = y) and (w = z) then

<< fragment B >>

else

<< fragment C >>

endif;

<< fragment D >>

...

diagram przepływu sterowania ma postać:







2 B







A 1 D


C

Na podstawie diagramu buduje się tablicę rozgałęzień, w której umieszczony jest opis warun­ków sprawdzanych w czasie wykonywania programu (oznaczenie węzła i decyzja).

W rozważanym przypadku tablica ma następującą postać:

węzeł	decyzja
1	x = y
2	w = z

Tablica rozgałęzień jest następnie wykorzystywana do sporządzenia macierzy pokrycia gałęzi. W macierzy tej oprócz opisu decyzji znajdują się dodatkowe kolumny oznaczone nu­merami zesta­wów danych testowych.

Przykładowa macierz wygląda następująco:

	węzeł	decyzja	testy	1	2	3
	1	x = y	TRUE
			FALSE
	2	w = z	TRUE
			FALSE

Należy także przygotować zbiór zestawów danych testowych. Każdy zestaw powinien posia­dać swój numer w celu identyfikacji. Oto przykładowy zbiór zestawów testowych:

		wartości zmiennej
		x	y	z
	zestaw 1	3	2	1
	zestaw 2	1	2	3
	zestaw 3	2	2	3

Wypełnianie macierzy odbywa się poprzez śledzenie przebiegów każdego testu przez strukturę sterowania. Jeżeli dany test sprawdza warunek - w odpowiednie miejsce macierzy wpisuje się krzy­żyk.

Po umieszczeniu w macierzy pokrycia wszystkich zestawów danych i zaznaczeniu spraw­dzanych przez nie testów trzeba sprawdzić, czy jest ona kompletna. Macierz uważamy za kompletną, jeżeli wszystkie gałęzie kodu zostały przynajmniej jeden raz wykonane, to zna­czy wtedy, gdy w każdym jej wierszu znajduje się przynajmniej jeden krzyżyk.

Jeśli zachodzi taka konieczność, uzupełnia się macierz opracowując zestawy danych te­stowych, dobrane tak, by pokryć gałęzie dotychczas puste. Poniżej przedstawiona została wy­pełniona przy­kładowa macierz pokrycia oraz uzupełniony zbiór zestawów testowych.

	węzeł	decyzja	testy	1	2	3		4
	1	x = y	TRUE			x		x
			FALSE	x	x
	2	w = z	TRUE					x
			FALSE			x

gałąź nie pokryta przez zestawy 1, 2 oraz 3

		wartości zmiennej
		x	y	z
	zestaw 1	3	2	1
	zestaw 2	1	2	3
	zestaw 3	2	2	3
	zestaw 4	2	2	2

dla pokrycia gałęzi dotychczas pustej

Na podstawie uzupełnionej macierzy pokrycia można ocenić, czy zaprojektowane dane testowe są wystarczające do sprawdzenia wszystkich ścieżek.

Aby uniknąć niekorzystnej sytuacji przedłużania się procesu testowania sprawdza się także nadmiarowość zestawów testowych. Dane, których użycie nie wnosi w testowanie nic nowego - tzn. wykorzystujące tylko gałęzie pokrywane również przez inne testy, należy usu­nąć.

Rozpatrzmy to na przykładzie przedstawionej wyżej macierzy pokrycia:

	węzeł	decyzja	testy	1	2	3	4
	1	x = y	TRUE			x	x
			FALSE	x	x
	2	w = z	TRUE				x
			FALSE			x



jeden z tych zestawów danych testowych jest nadmiarowy

Ponieważ w diagramie przepływu sterowania mogą znajdować się także pętle, do mini­malnego zestawu testów dla ścieżek dodaje się testy sprawdzające poprawność pętli. Na ogół liczba zesta­wów w pełni testujących pętle jest bardzo duża. Zachodzi więc potrzeba roz­sądnego dobrania da­nych, tak by przy niewielkiej liczbie testów takie fragmenty programu można było sprawdzić i uznać za poprawne.

Każda pętla powinna być wykonana zero, jeden i maksymalną liczbę razy (oczywiście, je­śli struktura programu dopuszcza te przypadki). Jeśli nie da się określić ostatniej z tych wiel­kości, przyjmuje się jakąś odpowiednio dużą wartość. Po zaprojektowaniu zestawów danych testowych spełniających powyższe warunki umieszcza się je również w macierzy pokrycia gałęzi.

Może się zdarzyć, że któryś z nowo utworzonych testów jest równoważny wcześniej­szemu. Wobec tego konieczne jest ponowne sprawdzenie nadmiarowości zestawów testo­wych.

Zgodnie z podstawowymi zasadami testowania, przed przystąpieniem do wykonywania programu, dla którego przygotowano diagram przepływu sterowania i zestawy danych testo­wych, należy przy­gotować spodziewane wyniki, by można je było porównać z rzeczywiście otrzymanymi.




Dodatek b

Wyznaczanie profilu dynamicznego
pro­gramów za pomocą Turbo Profilera

2. Wyznaczanie profilu dynamicznego pro­gramów za pomocą Turbo Profilera

Turbo Profiler firmy Borland International jest przykładem programu pozwalającego na wy­znaczenie profilów dynamicznych.

Turbo Profiler pozwala na gromadzenie danych dotyczących czasu i częstości wykony­wania różnych fragmentów programu (poszczególnych podprogramów, linijek programu źródło­wego lub do­wolnych innych fragmentów określonych przez użytkownika). Ponadto możliwe jest zbieranie da­nych na temat wykorzystania systemu plików, przerwań, nakładek, oraz kompletnych ścieżek wy­wołań podprogramów. Wszystko to dostępne jest w środowisku przyjaznym dla użytkownika, z wykorzystaniem techniki okienkowej i kontekstowych pod­powiedzi.

Turbo Profiler można wykorzystać do optymalizacji programów kompilowanych za po­mocą dowolnego kompilatora firmy Borland International (np. Borland/Turbo Pascal, C/C++ i As­sembler), przy braku ograniczeń na rozmiar programu. Istnieje specjalna wersja programu przezna­czona do analizy programów pracujących w środowisku Microsoft Win­dows.

• B.1. Czynności przygotowawcze

Przed przystąpieniem do analizy programu za pomocą Turbo Profilera należy wykonać pewne czynności przygotowawcze.

Aby wyznaczenie profilu dynamicznego programu przebiegało efektywnie i w sposób od­dający istotne cechy programu, często trzeba dokonać niewielkich modyfikacji programu źró­dło­wego. Dane testowe powinny być na tyle duże, aby program wykonany został w możliwie pełnym zakresie swo­ich możliwości. Jeżeli to tylko możliwe, należy zmodyfikować program tak, aby działał w sposób niezależny od klawiatury, myszki i innych urządzeń wejściowych, wprowadzających opóźnienia cza­sowe nieadekwatne do zastosowanych algorytmów.

Program należy skompilować z pełną informacją symboliczną. W Turbo/Borland Pascalu (wersja 7.0) wymaga to włączenia pozycji Debug information i Local symbols w gronie Debug­ging okna dialogowego Options|Compiler oraz opcji Standalone debugging w oknie dia­logo­wym Options|Debugger lub opcji kompilacji {$D+,L+}. W Borland C/C++ należy włą­czyć opcje: Debug info in OBJs w dialogu Options|Compiler|Advanced code generation oraz Source Debugging/Standalone w dialogu Options|Debugger. Stosując kompilator li­nio­wy należy włączyć przełączniki -y i -v.

W trakcie pracy Turbo Profiler wykorzystuje zarówno plik zawierający postać wyni­kową programu, jak i pliki źródłowe. Pliki źródłowe poszukiwane są kolejno:

1. w katalogu, gdzie program został skompilowany;

2. w katalogach zapisanych w opcji programu Options|Path for source;

3. w bieżącym katalogu;

4. w katalogu zawierającym program wynikowy, podlegający aktualnie analizie.

Jeżeli plik zawierający program źródłowy nie zostanie znaleziony, wówczas Profiler au­to­matycznie otwiera okno Disassembly zawierające kod zapisany w assemblerze. W praktyce oznacza to, że albo nie skompilowano programu z pełną informacją symboliczną, albo że plik źródłowy jest zapi­sany w nieodpowiednim katalogu dyskowym.

• B.2. Konfiguracja Turbo Profilera

Przed podjęciem pracy z programem Turbo Profiler należy zadbać o kilka ustawień kon­figura­cyjnych.

• B.2.1. Wstępna konfiguracja Turbo Profilera - ustalenie znaczników
  ob­sza­rów (areas)

Po uruchomieniu Turbo Profilera należy załadować plik z programem przeznaczonym do ana­lizy. W tym celu wybieramy z głównego menu programu opcję File|Open. Turbo Profiler ładuje główny moduł źródłowy programu do okna o nazwie Module i ustawia kursor na po­czątku głów­nego bloku wykonywalnego tego modułu. Od tej chwili program jest już właści­wie gotowy do te­stowego wykonania i ustalenia profilu dynamicznego. W większości zasto­sowań niezbędne jest jed­nak odpowiednie skonfigurowanie programu.

Proces wstępnego konfigurowania programu polega na określeniu elementów tekstu pro­gramu, o których mają być gromadzone informacje, oraz określeniu rodzaju tych informacji i sposobu ich gromadzenia.

W tekście źródłowym programu wyznaczane są tzw. obszary. Przed instrukcją­ - wier­szem pro­gramu, od której zaczyna się obszar, umieszcza się znacznik obszaru. Wszystkie wiersze znajdujące się za danym znacznikiem należą do danego obszaru, aż po następny taki znacz­nik.

Znaczniki rozpoczynające obszary można porównać do rogatek drogowych. Wykonywa­nie programu kontrolowanego przez Turbo Profiler polega na przechodzeniu kolejnych ta­kich rogatek. Przekroczenie rogatki równoważne jest z wejściem na odcinek drogi kontrolo­wanej przez tę ro­gatkę (posterunek). Odcinek ten kończy się na następnym posterunku­ - ro­gatce. Każda rogatka reje­struje, jak długo przebywało się na drodze przez nią kontrolowanej oraz ile razy przekraczało się tę rogatkę.

Po załadowaniu nowego programu Turbo Profiler automatycznie wprowadza znaczniki ob­szarów, czyli, mówiąc innymi słowy, dzieli program na obszary. W zależności od rozmiaru programu (a właściwie jego tablicy symboli) obszary te pokrywają się bądź to z kolejnymi wierszami programu źró­dłowego, bądź też z całymi podprogramami.

Znaczniki początków obszarów wyświetlane są w postaci strzałek na lewo od odpowied­nich li­nijek programu. Wskazując strzałki za pomocą myszy można usunąć niepotrzebne ob­szary. W ana­logiczny sposób można wprowadzać nowe znaczniki. Obie operacje wykonać też można umiesz­czając kursor tekstowy w odpowiedniej linijce i naciskając F2.

Znaczniki można efektywniej ustawiać i usuwać korzystając z tzw. menu lokalnego. Menu lo­kalne uzyskuje się za pomocą prawego przycisku myszy (w czasie, gdy kursor myszy znajduje się ponad okienkiem Module), lub używając klawisza Alt-F10. Opcja Add areas po­zwala na dodanie obszarów odpowiadających wszystkim podprogramom w programie lub module, wszystkim wierszom w module lub podprogramie, wskazanemu podprogramowi lub wskazanemu wierszowi. Opcja Re­move areas pozwala usunąć wszystkie istniejące obszary lub tylko odpowiadające wszystkim uprzednio zaznaczonym podprogramom w programie lub module, wszystkim wierszom w module lub podprogramie, czy wreszcie wskazanemu pod­pro­gramowi lub wierszowi.

Znacznik obszaru stanowi rodzaj pułapki na sterowanie. Kiedykolwiek Turbo Profiler wyko­nując program natrafi na taką pułapkę, realizuje związane z daną pułapką (obszarem) działania. Najczęściej jest to po prostu zarejestrowanie danych określających czas przebywa­nia programu w poprzedzającym znacznik obszarze.

Za pomocą menu lokalnego można określić, jaka operacja powinna zostać wykonana po natra­fieniu na pułapkę - znacznik obszaru. Służy do tego opcja Operation, której aktywacja powoduje rozwinięcie okienka dialogowego Area Options. Oprócz standardowego trybu re­akcji (Normal), który polega na prostym zarejestrowaniu danych statystycznych dotyczących obszaru kontrolowa­nego przez znacznik, można spowodować chwilowe wstrzymanie wyko­nywania programu po natra­fieniu na znacznik (Stop), a także wstrzymanie i wznowienie reje­strowania danych (Disable i Ena­ble), co pozwala na wyłączenie pewnych obszarów z analizy realizowanej przez Turbo Profiler.

Za pomocą tego samego okienka dialogowego można znacznikowi obszaru przypisać je­den z dwóch systemów rejestracji i pomiaru czasu. Podczas rejestracji rozdzielnej (Separate Timing) na konto danego obszaru zaliczany jest wyłącznie czas wykonania instrukcji znajdu­jących się w obrębie tego obszaru, to znaczy pomiędzy znacznikiem początkowym i końcowym. W trybie łączonym (Combined Timing) na konto obszaru jest również zaliczany czas wykonania podprogramów wy­wołanych z wnętrza tego obszaru (mimo że treść tych podprogramów należy do innych obszarów). Zwykle bardziej przydatny jest tryb rozdzielny (i taki jest też ustawiany domyślnie przez Turbo Pro­filer), gdyż pozwala na precyzyjniejsze wy­znaczenie regionu krytycznego. Tryb łączony pozwala zaś na całościowe spojrzenie na wy­daj­ność danego podprogramu, abstrahując od tego, na jakie mniej­sze podprogramy jest on rozbity.

• B.2.2. Uzupełniająca konfiguracja Turbo Profilera - tryb gromadzenia
  da­nych

Dodatkową możliwość skonfigurowania procesu gromadzenia danych przez Turbo Pro­filer dają opcje zebrane w okienku dialogowym Profiling Options, generowanym przez opcję o tej sa­mej nazwie, w podmenu Statistics w głównym menu programu. Przełączniki zebrane w gronie Pro­file mode pozwalają na wybór jednego z niżej opisanych trybów gromadzenia danych statystycz­nych o programie:

• Tryb aktywny (active mode) oznacza gromadzenie pełnego zestawu informacji (czas wyko­nywania obszarów, liczba wykonań i ścieżka wywołań dla podprogramów) kosz­tem spo­wolnienia programu;

• Tryb bierny (passive mode) oznacza gromadzenie danych wyłącznie na temat czasów wy­konywania obszarów, pozwala jednak na wykonywanie programów z prawie pełną szybko­ścią.

Za pomocą tego samego okienka dialogowego można zwiększyć liczbę przebiegów pro­gramu realizowanych w celu pomiaru czasu. Ograniczona rozdzielczość używanego zegara może prowa­dzić do błędnych wyników pomiarów bardzo krótkich odcinków czasowych; zwielokrotnienie po­miaru pozwoli uzyskać wyniki obarczone mniejszym błędem.

• B.3. Tworzenie i przeglądanie statystyk

Po zaplanowaniu położenia i właściwości obszarów Turbo Profiler jest gotowy do zebra­nia danych statystycznych na temat czasu wykonania rozmaitych jego obszarów, a także czę­stości wykonania tych obszarów. Możliwe jest także zbieranie innych typów statystyk, co zwykle wy­maga podjęcia dodatkowych czynności przygotowawczych. W kolejnych punk­tach omówione zo­staną następujące typy generowanych przez Turbo Profiler statystyk:

• profil dynamiczny - na jak długo i jak często sterowanie zostało przekazane do róż­nych ob­szarów;

• częstości i ścieżki wywołań - jak często były wywoływane poszczególne podprogramy i ja­kie podprogramy je wywoływały;

• statystyka nakładek - z jakich nakładek, jak często i kiedy korzystał analizowany pro­gram;

• statystyka przerwań - z jakich przerwań, jak często i jak długo korzystał analizowany pro­gram;

• statystyka plików - z jakich plików, w jaki sposób, jak często i jak długo korzystał anali­zowany program.

Aby zebrać jakiekolwiek dane statystyczne należy rozpocząć wykonywanie analizo­wanego programu za pomocą opcji Run|Run lub klawisza F9. Program zostanie wówczas wykonany (ze względu na narzut cza­sowy Turbo Profilera może to być nieco zwolnione).

Dla każdego typu statystyk, a także danych o charakterze niestatystycznym, Turbo Profi­ler re­zerwuje osobny typ okienek. Okienka takie otworzyć można za pomocą opcji z podmenu Views, znajdującego się na belce głównego menu programu. Z każdym typem okienka związane jest spe­cjalne menu lokalne, które otrzymuje się za pomocą kombinacji klawiszy Alt-F10 lub prawego przycisku myszy. Menu lokalne zawierają zestaw opcji repre­zentujących operacje charaktery­styczne dla obrazowanych w okienku danych. Część opcji służy też do przełączania pomiędzy okienkami, w szczególności obrazowania za pomocą in­nego typu środków (tj. w okienku innego typu) elementu danych zaznaczonego w okienku bieżącym. Nazewnictwo opcji tego rodzaju nie jest jednolite: w niektórych okienkach nazy­wają się one Inspect, a w innych przyjmują nazwy okienek, które otwierają.

• B.3.1. Profil dynamiczny programu (Execution Profile)

Okienko przeznaczone do wyświetlania profilu dynamicznego (Execution Profile) znaj­duje się zwykle na ekranie od chwili aktywizacji Turbo Profilera. Jeśli mimo to okienka o takiej nazwie nie ma, wystarczy wybrać opcję menu głównego View|Execution Profile.

Okienko profilu dynamicznego jest podzielone na dwie części. W górnej znajdują się dane na temat całkowitego czasu wykonania programu (Total time), procentowego udziału sumy czasów wykonania obszarów ujętych w statystyce w całkowitym czasie wykonania pro­gramu (% of Total), a także dodatkowych informacji dotyczących sposobu skonfigurowa­nia okienka.

W dolnej części okienka wyświetlane są (po wykonaniu programu) dane statystyczne do­tyczące poszczególnych obszarów programu, obejmujące nazwę obszaru (numer wiersza programu źródłowego lub nazwę podprogramu), odpowiednie wartości liczbowe bez­względne i względne (procentowe) oraz ilustrację w formie wykresu słupkowego.

Jeżeli jednocześnie w środowisku Turbo Profilera otwarte są okna Module (z tekstem źró­dło­wym modułu) i Execution Profile, to oba te okna są ze sobą sprzęgnięte, tak że ustawienie kursora w określonym obszarze w oknie Module powoduje podświetlenie staty­styki tego obszaru w oknie Execution Profile i odwrotnie.

Profil dynamiczny obejmuje analizę danych statystycznych różnego rodzaju:

• Time to statystyka czasowa (w milisekundach);

• Counts to statystyka zdarzeniowa, tj. liczba wykonań poszczególnych obszarów;

• Both to obie powyższe statystyki pokazane jednocześnie;

• Per call to statystyka czasu średniego, tj. wartość ilorazu czasu wykonania przez liczbę wy­konań;

• Longest to statystyka najdłuższego czasu pojedynczego wykonania danego obszaru;

• Module to prezentacja, dla każdego obszaru w module, czasu przez jaki sterowanie prze­bywało w danym module (ten tryb ma znaczenie jedynie przy tzw. pasywnej anali­zie pro­gramu).

Wyboru jednej z powyższych statystyk dokonuje się za pomocą lokalnego menu związa­nego z oknem Execution Profile. Opcja Display powoduje wyświetlenie okienka dialogo­wego, pozwa­lającego określić jeden z wyżej opisanych typów statystyk, a także sposób sor­towania wyświetla­nych danych - alfabetycznie (Name), według położenia w pamięci opera­cyjnej (Address) oraz we­dług wartości danych statystycznych związanych z obszarami (Frequency).

W razie potrzeby można ograniczyć liczbę wyświetlanych danych (tj. liczbę obszarów, o któ­rych wyświetlane są informacje) za pomocą filtrów (opcje Filter|All, Module i Current lokalnego menu). Wyświetlane mogą być dane na temat wszystkich obszarów (All) lub tylko obszarów nale­żących do wskazanego modułu (Module). Możliwe jest też wyłączenie tego obszaru, który jest ak­tualnie podświetlony (opcja Current).

• B.3.2. Statystyka częstości i ścieżek wywołań podprogramów (Callers)

Okienko Callers, w którym wyświetlana jest statystyka częstości i ścieżek wywołań pod­pro­gramów, otrzymuje się za pomocą opcji menu głównego View|Callers.

Aby Turbo Profiler zgromadził dane niezbędne do wyświetlenia tego rodzaju statystyki, należy go wpierw odpowiednio skonfigurować. Przede wszystkim trzeba załączyć (Enable) gromadzenie danych do tego rodzaju statystyki, za pomocą opcji menu głównego Stati­stics|Callers (Turbo Pro­filer domyślnie blokuje tę funkcję). Precyzyjniejszą konfigurację można otrzymać za pomocą menu lokalnego okienka Module, zawierającego tekst źródłowy programu. Wybieramy opcję Callers. Powoduje to rozwinięcie okienka dialogowego Stack trace. Ustalamy, czy tryb zbierania informacji zostanie określony tylko dla bieżącego pod­pro­gramu, dla wszystkich podprogramów bieżącego modułu, czy dla wszystkich podprogra­mów w programie (opcje: This routine, This module, All routines), po czym włączamy odpo­wiedni tryb. Opcja All callers pozwala na zgromadzenie danych o pełnej ścieżce wywołań (to jest o liście podprogramów, których kolejne wywołania spowodowały wywołanie danego). Opcja Immediate caller ogranicza zapamiętywane dane do podprogramu bezpośrednio wy­wołują­cego dany podprogram, a opcja None wyłącza zbieranie danych. Po uru­chomieniu Turbo Profiler w sposób domyślny włącza tryb zbierania danych o pełnej ścieżce wy­wołań dla wszystkich podprogramów.

Po wykonaniu analizowanego programu okienko Callers będzie zawierało gotową staty­stykę, na którą składa się lista wywoływanych w obrębie programu podprogramów. Dla każ­dego podpro­gramu dana jest liczba wywołań oraz nazwa podprogramu lub podprogramów (z ewentualną pełną ścieżką wywołań), które dany podprogram wywołały.

Za pomocą opcji Sort z menu lokalnego prawej części okienka Callers można ustalić ko­lejność wyświetlania elementów w okienku: chronologicznie, to jest według kolejności wy­woływania w pro­gramie (opcja Called) lub według liczby odwołań.

• B.3.3. Statystyka nakładek (Overlays)

Okienko Overlays, w którym wyświetlana jest statystyka częstości odwołań do podpro­gramów nakładkowanych, otrzymuje się za pomocą opcji menu głównego View|Overlays.

Aby Turbo Profiler zgromadził dane niezbędne do wyświetlenia tego rodzaju statystyki, należy załączyć (Enable) gromadzenie danych na temat nakładkowania za pomocą opcji menu głównego Statistics|Overlays (Turbo Profiler domyślnie blokuje tę funkcję). Dodajmy, że uaktywnienie za­równo opcji View|Overlays, jak i Statistics|Overlays nie jest możliwe, je­śli załadowany program nie korzysta z systemu nakładkowania.

Po wykonaniu analizowanego programu okienko Overlays zawiera statystykę opisującą spo­sób wykorzystania systemu nakładek w dwóch ujęciach:

• liczbowym (Count) - ile razy program ładował każdą nakładkę. Dodatkowo podawany jest rozmiar nakładek (dane są prezentowane w postaci liczb oraz histogramu);

• historycznym (History) - kiedy program ładował poszczególne nakładki i w jakiej ko­lejności - opcja szczególnie przydatna przy wykrywaniu "migotania" nakładek.

Wyboru pomiędzy powyższymi dwoma sposobami ujęcia statystyki dokonuje się za po­mocą opcji Display menu lokalnego okienka Overlays. Druga z opcji, Inspect, pozwala na załadowanie do okienka Module tekstu źródłowego zawierającego nakładkowany moduł.

• B.3.4. Statystyka przerwań (Interrupts)

Okienko Interrupts, w którym wyświetlana jest statystyka częstości i sposobu odwołań do systemu przerwań, otrzymuje się za pomocą opcji menu głównego View|Interrupts.

Aby Turbo Profiler zgromadził dane niezbędne do wyświetlenia tego rodzaju statystyki, należy załączyć (Enable) gromadzenie danych na temat przerwań za pomocą opcji menu głównego Stati­stics| Interrupts (Turbo Profiler domyślnie włącza tę funkcję).

Po wykonaniu analizowanego programu okienko Interrupts zawiera statystykę, opisującą spo­sób i zakres wykorzystania przerwań.

W górnej lewej części okienka Interrupts wyświetlane są identyfikatory (numer oraz ro­dzaj, np. Video) poszczególnych przerwań wykorzystywanych przez program, dla których gromadzone są dane statystyczne. Listę tę można poszerzyć, wykorzystując opcję Add menu lokalnego górnej czę­ści okienka Interrupts i podając numer przerwania lub też opcję Pick, i wybierając z listy nazwę predefiniowanego przerwania (dostępne są: Video, Disk, Keyboard, DOS i Mouse). Opcje Re­move i Delete All pozwalają na usunięcie jednego lub wszystkich przerwań. Ponadto, za pomocą menu lokalnego można określić, czy dane o wywołaniach przerwań w ogóle mają być gromadzone (opcja Collection) oraz czy zapa­miętywać dane o wywołaniach poszczególnych podfunkcji (opcja Subfunctions).

Po zaznaczeniu kursorem jednego z przerwań w górnej lewej części okienka, w prawej części okienka pojawiają się informacje dotyczące tego przerwania: sposób gromadzenia da­nych (por. opcje Collections i Subfunctions) oraz liczba i łączny czas wykonania odwołań.

W dolnej części okienka Interrupts wyświetlane są szczegółowe informacje o przerwaniach, jakie nastąpiły podczas wykonania programu, z dokładnością do po­szcze­gólnych podfunkcji (por. opcję Subfunctions opisaną wyżej). Zestaw wyświetlanych infor­macji, poza identyfikatorem przerwania (podfunkcji), zależy od trybu wyświetlania:

• Time - podawane są dane (liczbowe i w formie histogramu) o czasie przebywania ste­rowa­nia w procedurach obsługi poszczególnych przerwań;

• Calls - podawane są dane (liczbowe i w formie histogramu) o liczbie wystąpień (od­wołań) poszczególnych przerwań (podfunkcji);

• Both Time and Calls - kombinacja obu powyższych trybów;

• Events - prezentacja kolejnych wywołań poszczególnych przerwań (podfunkcji) w porządku chronologicznym.

Wyboru jednego z powyższych trybów dokonuje się za pomocą opcji Display lokalnego menu dolnej części okienka Interrupts.

• B.3.5. Statystyka plików (Files)

Okienko Files, w którym wyświetlana jest statystyka częstości i sposobu odwołań do systemu plików, otwiera się za pomocą opcji menu głównego View|Files.

Aby Turbo Profiler zgromadził dane niezbędne do wyświetlenia tego rodzaju statystyki, należy załączyć (Enable) gromadzenie danych na temat operacji plikowych za pomocą opcji menu głów­nego Statistics|Files (Turbo Profiler domyślnie włącza tę funkcję).

Po wykonaniu analizowanego programu okienko Files zawiera statystykę opisującą spo­sób wykorzystania systemu plików.

W górnej lewej części okienka jest wyświetlana lista plików, dla których gromadzone są dane statystyczne. Lista ta zawiera również pliki odpowiadające standardowym strumieniom wej­ścia-wyjścia. Wybór pliku przez umieszczenie kursora na nazwie pliku powoduje wy­świetlenie w prawej części okienka informacji dotyczących tego pliku, obejmujących:

• deskryptor pliku;

• kiedy i na jak długo plik został otwarty;

• czas trwania operacji otwarcia pliku;

• liczba odczytów z pliku, liczba wczytanych bajtów i łączny czas trwania operacji od­czytu;

• liczba zapisów do pliku, liczba zapisanych bajtów i łączny czas trwania operacji za­pisu;

• czas trwania operacji zamknięcia pliku.

Za pomocą menu lokalnego górnej części okienka Files można wyłączyć zbieranie infor­macji o poszczególnych plikach (opcja Collection Disabled) lub przełączyć stopień szcze­gó­łowości da­nych (opcja Details Disabled powoduje, że dane dotyczące czasu odczytu lub za­pisu nie będą groma­dzone dla każdego pliku osobno). Ustawienie opcji When Full decy­duje o reakcji Turbo Profilera na sytuację, w której brakuje pamięci na dalsze gromadzenie da­nych statystycznych: wykonywanie programu może zostać wówczas wstrzymane (Stop) lub nowe dane mogą być zapamiętywane w miejscu poprzednio zebranych (Wrap).

Dolna część okienka Files zawiera zestawienie danych o poszczególnych operacjach pli­ko­wych. Kolejno wykonywane operacje traktowane są jako zdarzenia i każde z nich (spośród zare­jestrowanych, por. wyżej opisane opcje Collection i Details) znajduje tu swoje odzwier­ciedlenie. Dane o poszczególnych operacjach mogą być wyświetlane w dwóch trybach:

• Graph - obok nazwy operacji (Open, Read itd.) podawany jest numer tzw. uchwytu (ang. handler) pliku, a także czas realizacji w formie liczbowej oraz jako histogram;

• Detail - obok nazwy operacji (Open, Read itd.) podawane są te same dane, co powy­żej, oraz określenie czasu, w którym operacja została wykonana. Brakuje prezentacji gra­ficznej, informacja tekstowa jest jednak podawana w postaci pełnego zdania angiel­skiego (w prze­ciwieństwie do skrótowej formy w po­przednim trybie).

Wyboru pomiędzy powyższymi trybami dokonuje się za pomocą opcji Display menu lo­kalnego dolnej części okienka Files, które wyświetla specjalne okienko dialogowe. Można tu jeszcze wy­brać sposób ułożenia poszczególnych zdarzeń: chronologicznie (Sort: Start time) lub według czasu trwania (Sort: Duration).

• B.4. Przeglądanie danych niestatystycznych

Poza opisywanymi powyżej różnymi rodzajami zestawień statystycznych generowanych przez Turbo Profiler, wykorzystuje się też pewne rodzaje okienek przeznaczonych do wy­świetlania in­formacji nie będących statystykami. Z jednym z takich okienek, przeznaczonym do wyświetlania tekstów źródłowych (Module), zetknęliśmy się już przy opisywaniu wstęp­nej konfiguracji Turbo Profilera.

• B.4.1. Teksty źródłowe modułów - okienka typu Module

Po uruchomieniu Turbo Profilera i załadowaniu programu do analizy automatycznie wy­świe­tlane jest okienko typu Module, zawierające tekst źródłowy głównego modułu programu. Analo­giczne okienko można otworzyć w każdej chwili za pomocą opcji głównego menu pro­gramu View|Module lub naciskając klawisz F3. Turbo Profiler zapyta, który z należących do programu modułów źródłowych należy wczytać. Tej samej opcji menu używa się też w celu zmiany modułu znajdującego się w okienku Module.

Opisując wstępną konfigurację Turbo Profilera omówiono opcje dotyczące podziału pro­gramu na obszary, znajdujące się w menu lokalnym okienek Module. Opis jeszcze innych opcji znajduje się w rozdziale poświęconym statystykom częstości i ścieżek wywołań pod­programów. Obecnie opiszemy pewne opcje wspomagające pracę z samym tekstem źródło­wym.

Opcja Line pozwala na szybkie umieszczenie kursora w wierszu tekstu o podanym nume­rze. Opcja Search wyszukuje w tekście podany łańcuch i umieszcza przy nim kursor, a opcja Next wy­szukuje kolejne wystąpienie tego łańcucha. Opcja Goto umieszcza kursor w tym miejscu tekstu źródłowego modułu, który odpowiada rozkazowi znajdującemu się pod wska­za­nym przez użytkow­nika adresem.

Opcja Module zmienia wyświetlany w okienku moduł na inny spośród należących do pro­gramu modułów źródłowych (identycznie jak opcja głównego menu View|Module). Opcja File pozwala załadować jeden z plików źródłowych dla aktualnie analizowanego modułu (np. Plik typu include). Opcja Edit wywołuje zewnętrzny edytor (wybrany w trakcie konfiguro­wania). Edycji podda­wany jest plik z okna Module.

• B.4.2. Podział programu na obszary - okienka typu Areas

Za pomocą opcji menu głównego View|Areas tworzy się okienka prezentujące pełną in­formację na temat podziału programu na obszary. Wyszczególnione są identyfikatory wszyst­kich obszarów (numery linijek lub nazwy podprogramów) wraz z położeniem w pliku źró­dłowym, długością (w li­nijkach) i trybem gromadzenia danych.

Tryby gromadzenia danych w obszarach omówiono w punkcie poświęconym wstępnej konfi­guracji Turbo Profilera. Opisane tam opcje menu lokalnego okienek z tekstem źródło­wym: Add Areas, Remove Areas i Options są dostępne również w okienkach typu Areas. Opcja Sort menu lokalnego okienek Areas pozwala ustalić sposób sortowania elementów wy­świetlanych w okienku.

• B.4.3. Podprogramy - okienka typu Routines

Za pomocą opcji menu głównego View|Routines tworzy się okienka zawierające wy­szczegól­nienie wszystkich podprogramów analizowanego programu.

• B.4.4. Treść programu w formie kodu maszynowego 80x86 - okienka
  typu Disassembly

Za pomocą opcji menu głównego View|Disassembly tworzy się okienka CPU 80x86 za­wie­rające kod programu w formie rozkazów procesorów 80x86.

Menu lokalne okienka CPU 80x86 pozwala na przesunięcie kursora w miejsce odpo­wia­dające podanemu przez użytkownika adresowi (opcja Goto) lub zawartości rejestru licznika rozkazów CS:IP podczas zatrzymania programu na pułapce (opcja Origin), przeniesienie kur­sora na adres docelowy zawarty w aktualnie wskazywanej instrukcji skoku, przerwania itp. (opcja Forward) lub poprzedni adres sprzed wykonania takiej instrukcji (opcja Previous).

• B.4.5. Pliki tekstowe - okienka typu Text File

Za pomocą opcji menu głównego View|Text File tworzy się okienka zawierające do­wolny, wskazany przez użytkownika plik tekstowy.

W menu lokalnym okienek tekstowych dostępne są opcje Goto, Search, Next, File i Edit, osiągalne również w okienku --> Module[Author:ZO] .

Opcje menu programu Turbo Profiler

Tabela B.1

Menu	Opcje	Opis
≡		Menu informacji systemowej
	Repaint desktop	Odświeżenie zawartości ekranu
	Restore stan­dard	Odtworzenie domyślnego stanu środowiska IDE
	About	Wyświetlenie informacji o wersji Turbo Profilera
File		Menu operacji plikowych
	Open	Otwarcie pliku z programem (*.EXE) przeznaczonym do analizy
	Change dir	Zmiana aktualnego katalogu dyskowego
	Get info	Wyświetlenie informacji o analizowanym programie i wyko­rzysta­niu pamięci operacyjnej (nazwa pliku progra­mowego, status wy­konania, tryb działania Turbo Profilera, raport o wykorzystaniu pamięci, wersja systemu operacyj­nego oraz aktualny czas i data systemowa)

		cd. tabeli B.1
Menu	Opcje	Opis
	DOS shell	Tymczasowe przekazanie sterowania do systemu operacyj­nego. Powrót przez wprowadzenie polecenia EXIT
	Quit (Alt-X)	Zakończenie działania Turbo Profilera
View		Menu przeglądania statystyk i innych danych
	Module (F3)	Otwarcie okienka Module z tekstem źródłowym modułów
	Execution pro­file	Otwarcie okna Execution Profile przedstawiającego profil dy­namiczny programu
	Callers	Otwarcie okienka Callers zawierającego statystykę częstości i ścieżek wywołań podprogramów
	Overlays	Otwarcie okna Overlays zawierającego statystykę systemu na­kładek
	Interrupts	Otwarcie okna Interrupts zawierającego statystykę systemu przerwań
	Files	Otwarcie okna Files zawierającego statystykę operacji pliko­wych
	Areas	Otwarcie okna Areas zawierającego specyfikację podziału pro­gramu na obszary
	Routines	Otwarcie okna Routines zawierającego wyszczególnienie pod­programów w analizowanym programie
	Disassembly	Otwarcie okna CPU 80x86 zawierającego kod analizowa­nego programu w w asemblerze 80x86
	Text file	Otwarcie okienka tekstowego zawierającego treść dowolnego pliku tekstowego
Run		Menu aktywizacji i wykonywania analizowanych progra­mów
	Run (F9)	Uruchomienie analizowanego programu i inicjalizacja gro­madzenia danych statystycznych lub wznowienie programu po zatrzymaniu na pułapce
	Program reset (Ctrl-F2)	Zakończenie wykonywania analizowanego programu i przygoto­wanie do ponownego uruchomienia programu od początku
	Arguments	Ustalenie parametrów wykonania analizowanego programu
Statistics		Menu konfiguracyjne gospodarki rezultatami analiz
	Callers	Przełącznik gromadzenia danych statystycznych o częstości i ścieżkach wywołań podprogramów
	Files	Przełącznik gromadzenia danych statystycznych o systemie pli­ków
	Interrupts	Przełącznik gromadzenia danych statystycznych o systemie przerwań
	Overlays	Przełącznik gromadzenia danych statystycznych o systemie nakła­dek
	Profiling options	Ogólna konfiguracja procesu gromadzenia danych statystycz­nych.
	Accumulation	Przełącznik gromadzenia informacji
	Delete all	Kasowanie wszystkich statystyk zapisanych dla danej sesji
	Save	Zachowanie w pliku dyskowym wszystkich statystyk z bieżącej sesji oraz informacji o zaznaczonych obszarach
	Restore	Odtworzenie zawartości uprzednio zachowanego pliku da­nych statystycznych
Print		Menu obsługi drukowania raportów
	Statistics	Wydrukowanie zawartości okien ze statystykami
	Module	Wydrukowanie jednego z modułów źródłowych ana­lizo­wa­nego programu
	Options	Konfiguracja postaci wydruku. Ustalić tu można rozmiar druko­wanej strony, skierować wydruk do pliku oraz określić postać graficzną wydruku
Options		Menu konfiguracji środowiska pracy Turbo Profilera
	Macro	Rozwinięcie podmenu tworzenia i usuwania makropoleceń; obej­muje podopcje: Create - stworzenie nowego makropolecenia Stop recording - zakończenie rejestracji makropolecenia Remove - usunięcie wskazanego makropolecenia Delete all - usunięcie wszystkich makropoleceń
	Display options	Konfiguracja parametrów graficznych środowiska IDE - spo­sób przełączania ekranu między IDE a analizowanym pro­gramem, rozdzielczość ekranu, rozmiar tabulatora i dopuszczalna długość identyfikatorów
	Path for source	Wprowadzenie listy katalogów, w których Turbo Profiler będzie poszukiwał plików źródłowych analizowanych pro­gramów
	Save options	Zapis różnych elementów konfiguracji Turbo Profilera (opcje, układ okienek na ekranie lub makropolecenia) do pliku konfi­guracyjnego
	Restore options	Odtworzenie uprzednio zapamiętanej konfiguracji systemu
Window		Menu obsługi okienek zintegrowanego środowiska pracy Turbo Profilera
	Zoom (F5)	Zmiana rozmiaru aktywnego okienka na maksymalny lub przy­wrócenie do normalnej wielkości
	Next (F6)	Aktywizacja następnego spośród otwartych okienek
	Next pane (Tab)	Aktywizacja następnego elementu (fragmentu) aktywnego okienka
	Size/move (Ctrl-F5)	Zmiana rozmiaru i położenia aktywnego okienka
	Iconize/restore	Sprowadzenie aktywnego okienka do postaci ikony na ekranie lub przywrócenie do normalnej wielkości
	Close (Alt-F3)	Zamknięcie aktywnego okienka
	Undo close (Alt-F6)	Odtworzenie ostatnio usuniętego okienka
	User screen (Alt-F5)	Przełączenie na ekran używany przez analizowany program
	...	Szybkie przełączenie do dowolnego otwartego okienka
Help		Menu podpowiedzi systemowych - podpowiedzi kontek­stowe dostępne przez F1
	Index (Shift-F1)	Prezentacja listy haseł dla których przewidziano teksty z podpo­wiedziami
	Previous topic (Alt-F1)	Powrót do ostatnio wyświetlonego tekstu podpowiedzi
	Help to help	Otwarcie okna zawierającego informacje o sposobach korzy­sta­nia z systemu podpowiedzi




DODATEK C

Środki ułatwiające uruchamianie
w sys­temACH Turbo Pascal 6.0/7.0
i Borland Pascal 7.0

1. Środki ułatwiające uruchamianie w sys­temACH Turbo Pascal 6.0/7.0 i Borland Pascal 7.0

Usunięcie błędów składniowych jest jedynie warunkiem koniecznym utworzenia popraw­nego programu. Przygotowanie programu, którego działanie ściśle odpowiada założonym specyfikacjom, najczęściej wymaga jego uruchomienia. Zadanie to wspomaga symboliczny program uruchomie­niowy wchodzący w skład środowiska zintegrowanego, nazywany dalej debuggerem wbudowa­nym lub po prostu debuggerem.

Do najważniejszych właściwości debuggera należy zaliczyć:

• możliwość śledzenia przebiegu wykonania programu,

• możliwość analizowania wyników wykonania w miarę ich generowania,

• możliwość obserwowania przebiegu zmian wartości zmiennych i wyrażeń,

• możliwość dynamicznego modyfikowania wartości zmiennych, w zależności od prze­biegu wykonania programu.

Dzięki temu, że debugger stanowi część systemu zintegrowanego (obok edytora i kompi­la­tora), typowy cykl uruchomieniowy składający się z edycji, kompilacji i uruchamiania może odby­wać się bez opuszczania systemu. W przypadku, gdy możliwości debuggera są niewystarczające lub rozmiar programu jest zbyt duży, można posłużyć się de­buggerem zewnętrznym.

• C.1. Tworzenie informacji dla debuggera

Przed przystąpieniem do uruchamiania niezbędne jest wygenerowanie programu binar­nego z dodat­kowymi informacjami dla debuggera. W tym celu należy skompilować program z odpowiednimi opcjami kompilacji. Można ustawić je poprzez zaznaczenie odpowiednich pozycji w oknie dialogo­wym w menu Options|Compiler.

W czasie kompilacji kompilator tworzy listę używanych identyfikatorów, zwaną tablicą symboli. Lista ta zawiera nazwy zmiennych, stałych, typów, procedur i funkcji. Do urucha­miania potrzebna jest dodatkowa informacja o numerach wierszy w programie źródłowym dla każdego z symboli. Kom­pilator dodaje te informacje, jeśli zaznaczone jest pole Debug Infor­mation w oknie dialogowym Options|Compiler lub gdy w programie zostanie użyta dy­rek­tywa kompilatora $D+.

• C.1.1. Debugger wbudowany czy zewnętrzny

W oknie dialogowym Options|Debugger możemy wskazać kompilatorowi, czy ma gene­rować informacje dla debuggera wbudowanego lub zewnętrznego (np. Turbo Debuggera).

• C.1.2. Informacje o modułach

Przy uruchamianiu dużych programów zbudowanych z wielu modułów może okazać się, że in­formacja dla debuggera jest zbyt duża i nie mieści się w pamięci operacyjnej, unie­moż­liwiając uruchamianie. W tym przypadku można usunąć informację o symbolach lokal­nych w modułach. Aby to uzyskać, należy wyłączyć opcję Local Symbols w oknie dialogo­wym Compiler Options lub umieścić w programie dyrektywę $L-.

Po wyłączeniu generacji informacji dla lokalnych symboli, nadal jest generowana pełna informa­cja dla symboli z sekcji interface, co umożliwia symboliczne uruchamianie progra­mów korzystają­cych z danego modułu.

• C.2. Sterowanie wykonaniem programu

Jedną z najważniejszych zalet wbudowanego debuggera jest umożliwienie sterowania wyko­nywaniem programu. Dzięki możliwości sterowania wykonywaniem programu łatwiej można wy­dzielić część programu, która jest przyczyną problemów. Debugger udostępnia pięć podstawo­wych środków ułatwiających kontrolę wykonywania programu. Pozwala na:

• wykonanie kroku zwykłego,

• wykonanie kroku z wnikaniem,

• wykonanie programu do wiersza z kursorem,

• zastawienie pułapek,

• przerwanie sesji uruchamiania programu.

Najmniejszą jednostką wykonania programu w czasie uruchamiania jest wiersz tekstu pro­gramu. Oznacza to, że można kontrolować wykonanie programu z dokładnością do poje­dyn­czych wierszy pro­gramu. Jeśli więc w jednej wierszu programu zapisano więcej niż jedną instrukcję, niemożliwe jest wy­konanie ich oddzielnie. Debugger zawsze informuje o tym, który wiersz bę­dzie wykonywany jako następny przez jego wyróżnienie.

• C.2.1. Krok zwykły

Krok zwykły (Step Over) jest najprostszą metodą wykonywania małych fragmentów pro­gramu. Wybranie opcji Run|Step Over lub naciśnięcie klawisza F8 powoduje wykonanie za­znaczonego wiersza programu (włączając wszystkie funkcje i procedury); w szczególności zapisana w jednym wierszu instrukcja pętli wykona się w całości. Po wykonaniu wyróżniany jest następny wiersz.

• C.2.2. Krok z wnikaniem

Krok z wnikaniem (Trace Into/Step Into), podobnie jak krok zwykły, umożliwia wykona­nie jednego wiersza programu. Jeśli jednak wyrażenie zawiera wywołanie podprogramu, to nastę­puje jego wywołanie i możliwe jest krokowe wykonanie jego ciała. Analogicznie, jeżeli wiersz zawiera pętlę za­pisaną w całości w tym wierszu, krok wykonany w tym trybie spowo­duje wykonanie jed­nej iteracji. Krok z wnikaniem zostaje wykonany w wyniku wybrania opcji Run|Trace lub po naciśnięciu klawisza F7.

W przypadku kroku z wnikaniem odmiennie przebiega również proces rozpoczęcia wy­konania programu oraz modułu. Wykonanie wiersza zawierającego słowo kluczowe begin z głównego bloku pro­gramu powoduje wywołanie kodu inicjalizacji (jeśli taki istnieje) dla każdego z modułów używanych przez program, w takiej kolejności, w jakiej występują one w wyrażeniu uses. Analogicznie, rozkaz wykonania begin z głównego bloku modułu powo­duje wykonanie sekcji inicjalizacji każdego innego modułu przez niego użytego. Krok z wnikaniem umożliwia analizę pracy sekcji inicjalizacyjnych każ­dego z modułów.

Jeśli w programie używane są obiekty, debugger traktuje ich metody dokładnie tak, jak wy­wołanie zwykłej funkcji czy procedury. Wykonanie kroku w wierszu, w którym występuje wy­wołanie metody obiektu, spowoduje w kroku zwykłym jej wykonanie, a w kroku z wnikaniem umożliwi śle­dzenie wykonywania jej kodu.

• C.2.3. Wykonywanie fragmentu programu do wiersza z kursorem

Z reguły nie chcemy wykonywać całego programu krokowo. Wtedy w celu przyspie­szenia wyko­nywania fragmentów w danej chwili nieistotnych możemy nakazać wykonanie pro­gramu do miejsca określonego pozycją kursora tekstowego. Dokonujemy tego używając opcji Run|Go To Cursor, lub prościej - naciskając klawisz F4. Przed wykonaniem wiersza z kursorem nastąpi zatrzymanie i moż­liwe jest dalsze śledzenie lub praca krokowa. Za­uważmy, że jest to bardzo wygodny sposób na dojście do miejsca, od którego rozpoczniemy dokładną analizę zachowania się programu.

• C.2.4. Używanie pułapek

W systemie Turbo Pascal istnieje bardzo wygodne narzędzie do wstrzymywania wyko­nywania programu w zadanym miejscu, z możliwością określenia dodatkowych warunków. Miejsce zatrzy­mania określa tzw. pułapka, czyli wiersz zawierający wykonywalny kod (nie może to być komentarz lub deklaracja). Żeby zastawić pułapkę, należy przemieścić kursor tekstowy do wiersza, przed którym ma się zatrzymać wykonywanie programu. Zastawienie pułapki następuje przez wybranie operacji Toggle Breakpoint z lokalnego menu edytora (Debug|Toggle Breakpoints w wersji 6.0) lub przez naciśnięcie kombinacji Ctrl-F8. Wiersz, w którym zastawiona jest pułapka, zostaje wyróżniony. Pu­łapkę usuwamy poprzez ponowne wykonanie wyżej opisanej operacji. Można także określić wa­runki aktywizowania się pu­łapki. Warunkiem może być wyrażenie logiczne lub liczba przejść przez daną pułapkę bez zatrzymania. Po spełnieniu warunku program zostanie zatrzymany. System umoż­liwia rów­nież edycję opisu pułapek w oknie dialogowym aktywizowanym przez wybranie operacji De­bug|Breakpoints|Edit.

• C.2.5. Przerwanie sesji uruchamiania programu

Przerwanie sesji uruchamiania programu, na przykład w celu wznowienia uruchamiania pro­gramu, następuje w wyniku wybrania polecenia Run|Reset Program (Ctrl-F2).

• C.3. Wyszukiwanie określonych punktów w programie

W systemie Turbo Pascal istnieją dwie (w Borland Pascalu trzy) metody wyszukiwania okre­ślonych punktów w programie. Pierwszą z nich jest wykonanie operacji Search|Find Procedure, która znajduje miejsce definicji szukanej procedury lub funkcji. Szczególnie przydatne jest to w przypadku uruchamiania danej procedury.

Druga metoda pozwala na prześledzenie historii wywołań podprogramów (wraz z parametrami aktualnymi) oraz na znalezienie miejsca ich wywołań w programie źródło­wym. Jest to szczególnie przydatne, jeżeli przez pomyłkę zaczęliśmy śledzić kod podpro­gramu zamiast wykonać go kro­kowo. Wystarczy wówczas korzystając z historii wywołań znaleźć miejsce jego wywołania i po ustawieniu kursora w następnym wierszu wykonać pro­gram do tego wiersza (Run|Go to Cursor - F4). Okno dialogowe historii wywołań aktywizo­wane jest poprzez wybór Debug|Call Stack (Ctrl-F3). W pakiecie Borland Pascal w wersji 7.0 wpro­wadzono dodatkowe narzędzie, które nazywamy prze­glądarką obiektów (Object Browser). Pozwala ona na znajdowanie definicji i odwołań do zmien­nych, stałych, procedur, funkcji i obiektów. Ponadto może pokazywać hierarchię klas. Odpowied­nie okno przeglą­darki poja­wia się w wyniku wybrania w menu Search jednej z opcji Object, Globals, Units lub Sym­bols. Pozwalają one na obserwację odpowiednio: wszystkich obiektów, wszystkich symboli globalnych i modułów w programie. Opcja Search|Symbol pozwala na podanie na­zwy sym­bolu, o którym informacje chcemy uzyskać. Przeglądarka może pokazywać w zależności od rodzaju symbolu informacje w trzech typach widoków. Są to:

• widok zakresu (scope view) - pokazuje informacje o wszystkich symbolach zadekla­rowa­nych w zakresie programu, modułu lub obiektu,

• widok odniesienia (reference view) - pokazuje miejsca, w których występują odwoła­nia do danego symbolu; informacja ta zawiera nazwę pliku źródłowego oraz numer wiersza, w którym występuje,

• widok dziedziczenia (inheritance view) - pokazuje hierarchię klas użytych w programie

Przełączanie pomiędzy widokami odbywa się poprzez naciśnięcie kombinacji odpowied­nio Ctrl-I, Ctrl-S, Ctrl-O.

• C.4. Obserwacja wyników działania programu

W trakcie uruchamiania programu bardzo użyteczna jest możliwość obserwacji wyników poja­wiających się na ekranie.

System Turbo Pascal w każdym momencie uruchamiania pozwala przełączyć się pomię­dzy ekranem środowiska a ekranem użytkownika. Efekt ten można uzyskać wybierając ope­rację De­bug|User Screen lub naciskając kombinację Alt-F5. Powrót do ekranu środowiska następuje po naciśnięciu dowolnego klawisza.

Dostępne są również trzy tryby przełączania automatycznego na ekran użytkownika na czas wykonania pojedynczego kroku. Wybór trybu następuje w oknie dialogowym pojawiają­cym się po wybraniu opcji Options|Debugger w sekcji Display swapping. Standardowo wy­brane jest przełą­czanie inteligentne (Smart), które powoduje przełączanie się na ekran użyt­kownika tylko w przy­padku wykonywania operacji generujących wyniki na ekran lub wywo­ływania procedur (nawet jeśli procedury te nie operują na ekranie). Po zakończeniu wykona­nia operacji ekran przełącza się na ekran środowiska. Można też nakazać przełączanie dla każdej instrukcji (Always) lub wyłączyć je całkowicie (None). W przypadku wykorzystywa­nia procedur graficznych tej ostatniej opcji nie na­leży używać. Aktywizacja przełączania bezwa­runkowego jest przydatna w przypadku używania operacji zapisujących bezpośrednio do pa­mięci ekranu.

System Turbo Pascal umożliwia również obserwację tekstowych wyników działania pro­gramu w dodatkowym oknie środowiska. Aby stworzyć takie okno lub uczynić je widocznym (nie przy­krytym przez inne okna środowiska) należy wybrać operację Debug|Output.

W komputerach z dwoma kartami graficznymi możliwe jest całkowite rozdzielenie ekranu śro­dowiska systemu od ekranu, na który program generuje swoje wyniki. Każdy z ekranów jest wtedy związany z jedną kartą graficzną. Pracę w tym trybie włączamy uak­tywniając system Turbo Pascal z parametrem /D. Możliwość ta jest niezwykle przydatna w przypadku uruchamiania programów graficznych.

• C.5. Obserwacja wartości wyrażeń i modyfikacja wartości zmiennych

Środowisko Turbo Pascala ma dwa narzędzia do badania wartości wyrażeń - okno ob­serwa­cyjne (Watches) i okno dialogowe obserwacji i modyfikacji (Evaluate and Modify). Analizowane wyrażenia mogą zawierać: stałe, zmienne wszystkich typów (łącznie z definiowanymi przez użytkow­nika), operatory i funkcje wbudowane takie jak abs, chr, succ, itp. (nb. w Turbo Pascalu funkcji tej grupy można używać w definicji stałych). W środowisku mamy dodatkowo możliwość pod­glądania wartości rejestrów procesora. Od­powiednie okno pojawia się po wywołaniu De­bug|Register (w wersji 6.0 Window|Register).

• C.5.1. Okno obserwacyjne

W oknie tym są pokazywane aktualne wartości wybranych przez użytkownika wyrażeń. Otwar­cie okna następuje przez wybranie operacji Debug|Watch (Window|Watch w wersji 6.0) lub po nakazaniu podglądu wyrażenia. Dodanie wyrażenia do okna obserwacyjnego na­stępuje przez wy­branie operacji Debug|Add Watch (Debug|Watches|Add Watch w wersji 6.0) lub przez naciśnię­cie sekwencji Ctrl-F7. Jeżeli aktywnym oknem jest okno obserwacyjne, wy­starczy nacisnąć kla­wisz Ins. W oknie, które się w tym momencie pojawia, należy wpisać wybrane wyrażenie. Domyśl­nie przyjmowane jest słowo w pozycji kursora. Usunięcie wyra­żenia z okna obserwacji polega na jego wybraniu i naciśnięciu klawisza Del lub Ctrl-Y. Można też usunąć wszystkie wyrażenia wybie­rając operację Clear all z lokalnego menu okna obserwacyjnego (Alt-F10) (tylko w wersji 7.0). Obserwowane wyrażenia można również poddawać edycji przez naciśnięcie Enter po wcześniej­szym ich wybraniu.

• C.5.2. Okno dialogowe wartościowania i modyfikacji

Aby zwartościować wyrażenie należy wybrać operację Debug|Evaluate lub nacisnąć kombi­nację Ctrl-F4. Wyświetlone zostanie okno dialogowe, po czym należy wprowadzić wy­rażenie do modyfikacji. Domyślnie przyjmowane jest słowo wskazane kursorem (słowa na­stępne można wczytać naciskając strzałkę w prawo). Jeżeli wyrażeniem jest zmienna typu prostego, skalarny ele­ment tablicy, skalarne pole rekordu itp., to wartość wyrażenia można zmienić, wpisując nową war­tość w polu New Value. Przypisywana wartość może być wyra­żona stałą, zmienną lub wyrażeniem. Należy zachować szczególną ostrożność przy modyfi­kacji indeksów tablic i wskaźników.

• C.5.3. Format wydruku obserwowanych wyrażeń

Turbo Pascal pozwala na określenie sposobu wyświetlania informacji w oknach obserwa­cyj­nych. W celu zmiany formatu należy po wyrażeniu (po przecinku) umieścić specyfikator formatu. W jego skład wchodzi opcjonalny licznik powtórzenia (liczba naturalna), za którym występują (również opcjonalnie) znaki formatujące przedstawione w tabeli C.1.

Tabela C.1

Znak forma­tujący	Typy, dla których jest możliwa kon­wersja	Funkcja
$,H,X	całkowite	Przedstawia wartości w zapisie szesnastkowym. Wła­ściwa wartość jest poprzedzona przedrostkiem $
C	char, łańcuchy	Przedstawia znaki specjalne ASCII o kodach z przedziału 0..31. Domyślnie pokazywane są one w formacie #xx
D	całkowite	Przedstawia wartości dziesiętnie
Fn	Rzeczywiste	Pokazuje liczbę rzeczywistą z dokładnością do n cyfr znaczących (n jest z zakresu 2..18, domyślnie n=11)
NM	wszystkie	Przedstawia n bajtów rozpoczynając od adresu wska­zywanego przez wyrażenie w postaci ciągu liczb szes­nastkowych (zrzut pamięci). Ten znak formatujący może występować z innymi znakami: D - liczby przedstawiane są wtedy dziesiętnie, $, H, X - szesnastkowo, przy czym liczba jest po­przedzona przedrostkiem $. W przy­padku użycia S lub C - ob­szar pamięci traktowany jest jak łańcuch znaków (ze znakami sterującymi lub bez)
P.	wskaźniki	Przedstawia wskaźniki w formacie segment:offset za­miast Ptr(segment:offset)
R	rekordy, obiekty	Poprzedza wartości pól ich nazwami
S	char, łańcuchy	Pokazuje znaki specjalne ASCII 0..31 jako #xx. Jest to domyślny sposób wyświetlania łańcuchów i znaków. Użyteczny przy modyfikacji zrzutu pa­mięci (w połącze­niu z nM)

Dyrektywa warunkowa w Turbo Pascalu to {$IFDEF}, a w języku C - #ifdef.

Ćwiczenia Testowanie i Uruchamianie, ze względu na ścisły związek tych dwu czynności, są w aktualnym programie Laboratorium połączone i przeprowadzane jednocześnie, wobec czego pytania i zadania uzupełniają się wzajemnie i częściowo pokrywają.

Trudno jest zdefiniować wykrywalność błędów przez mechanizmy języków programowania. Na przykład w języku C, oprócz komunikatów o błędach, generowane są ostrzeżenia (ang. warnings) w wielu wątpliwych przypadkach, które mogą okazać się błędami różnych kategorii.

W niektórych systemach programowania brak nadania wartości początkowej jest traktowany jak błąd semantyczny, wykrywalny w czasie wykonywania programu.

Błędy przepisywania miały olbrzymie znaczenie w epoce kart dziurkowanych, dziś łatwiej je znaleźć i poprawić.

Należy unikać dokonywania poprawek bezpośrednio w kodzie wynikowym, uzyskanym z kompilacji programu, choć istnieją narzędzia to umożliwiające.

W środowiskach firmy Borland opcja Compile|Build all

W IDE Turbo Pascala dostępne opcje to: Options|Compiler|Range checking, Stack checking, IO, Overflow checking; W Borland C jedynie Options|Compiler|Entry/Exit Code|Stack options.

W systemie programowania Logitech Modula-2, przy błędzie wykonania generowany był tzw. post-mortem dump. Istniał również specjalny post-mortem debugger.

Ćwiczenia Testowanie i Uruchamianie, ze względu na ścisły związek tych dwu czynności, są w aktualnym programie Laboratorium połączone i przeprowadzane jedno­cześnie, wobec czego pytania i zadania uzupełniają się wzajemnie i częściowo pokrywają.

Program Turbo Profiler jest opisany w dodatku B.

Numer podfunkcji wyznaczany jest na podstawie zawartości rejestru AH procesora w momencie wywołania procedury obsługi przerwania.

Turbo Profiler konfiguruje się za pomocą osobnego programu o nazwie TFINST. Pozwala on, między innymi, zmodyfikować kolory elementów wizualnych Turbo Profilera, określić położenie plików, z którymi współpracuje program oraz zmienić parametry zintegrowanego środowiska programu.

14 Inżynieria programowania. Metody i ćwiczenia laboratoryjne

Rozdział 1: Testowanie programów 13

20 Inżynieria programowania. Metody i ćwiczenia laboratoryjne

Rozdział 2: Uruchamianie programów 19

80 Inżynieria programowania. Metody i ćwiczenia laboratoryjne

Rozdział 3: Optymalizacja czasowa programów 49

Dodatek A: Diagramy przepływu sterowania 57

Dodatek B: Wyznaczanie profilu dynamicznego programów za pomocą Turbo Profilera 71

Dodatek C: Środki ułatwiające uruchamianie w systemach Turbo Pascal 6.0/7.0... 79

Gromadzone przez Profiler dane to: czas wykonania programu oraz, dla każdego obszaru osobno, łączny czas wykonania działań 'związanych' z obszarem, współczynnik procentowego udziału 'czasu obszaru' w 'czasie programu', a także liczba 'wywołań' obszaru.

W trakcie sesji gromadzone są również informacje umożliwiające odtworzenie śladu wywołań procedur/funkcji danego programu, m.in. kompletne ścieżki (historie) wywołań tychże podprogramów. ścieżka taka jest zapisem drogi przekazywania sterowania w programie, prowadzącej do wywołania danego podprogramu. Historia wywołania danego podprogramu zawiera nazwy wszystkich podprogramów wywołujących kolejno siebie, aż do wywołania tego 'danego' podprogramu.

Pomiar czasu w środowisku Turbo Profiler'a odbywa się na zasadzie zliczania taktów zegarowych, generowanych przez zegar systemowy, lub (w trybie pasywnym analizy) przez lokalny generator ustawiany przez użytkownika (Statistics|Profiling options).

Czas spędzony w danym obszarze obliczany (timearea) jest według wzoru:

timearea = timertotal * countsarea / countstotal.

gdzie countsarea — liczba wykonań danego obszaru,

countstotal — globalna liczba wywołań obszarów,

timerglobal — globalna liczba taktów zegara.

true

false

---