Cel wykładu: zapoznać się z rodzajami i metodami kontroli i testowania oprogramowania, metodami i narzędziami debugowania programów.
Nie wystarczy zaprojektować i zakodować oprogramowanie; musisz również upewnić się, że spełnia on wymagania i specyfikacje. Wielokrotnie przeprowadzane badania wykazały, że im wcześniej zostaną wykryte pewne niespójności lub błędy, tym większe prawdopodobieństwo, że zostaną one poprawione i tym niższy jest ich koszt. Nowoczesne technologie tworzenia oprogramowania zapewniają wczesne wykrywanie błędów poprzez monitorowanie wyników wszystkich etapów i etapów rozwoju. Na początkowych etapach kontrola odbywa się ręcznie lub za pomocą WALIZKA- fundusze, w tym drugim - ma formę testowania.
Testowanie to proces wykonywania programu, którego celem jest wykrycie błędów. Żadna ilość testów nie może udowodnić braku błędów w złożonym oprogramowaniu, ponieważ wykonanie pełnego testowania staje się niemożliwe i istnieje możliwość, że istnieją nieodkryte błędy. Przestrzeganie podstawowych zasad testowania i dobór testów oparty na nauce może zmniejszyć ich liczbę. Proces rozwoju zgodnie z nowoczesnym modelem cyklu życia oprogramowania obejmuje trzy etapy testowania: autonomiczny Testowanie komponentów oprogramowania; złożony testowanie opracowanego oprogramowania; systemowy lub oceniający testowanie zgodności z głównymi kryteriami jakości. Aby poprawić jakość testów, zaleca się przestrzeganie następujących podstawowych zasad:
oczekiwane wyniki muszą być znane przed badaniem;
należy unikać testowania programu przez autora;
konieczne jest dokładne przestudiowanie wyników każdego testu;
konieczne jest sprawdzenie działania programu na nieprawidłowych danych;
konieczne jest sprawdzenie programu pod kątem nieoczekiwanych skutków ubocznych w przypadku nieprawidłowych danych.
Prawdopodobieństwo niewykrytych błędów w części programu jest proporcjonalne do liczby błędów już znalezionych w tej części. Odnoszący sukcesy rozważ test, który wykrywa przynajmniej jeden błąd. Utworzenie zestawu testów ma ogromne znaczenie, ponieważ testowanie jest jednym z najbardziej czasochłonnych etapów tworzenia oprogramowania. Udział kosztów testowania w całkowitym koszcie rozwoju rośnie wraz ze wzrostem złożoności oprogramowania i wyższymi wymaganiami dotyczącymi jego jakości.
Istnieją dwa zasadniczo różne podejścia do tworzenia zestawów testów: strukturalny i funkcjonalny. Podejście strukturalne na podstawie znanej struktury przetestowane oprogramowanie, w tym jego algorytmy („ szklane pudło”). Testy mają na celu sprawdzenie poprawności implementacji danej logiki w kodzie programu. Funkcjonalnypodejście opiera się na fakcie, że struktura oprogramowania nie jest znana („ czarna skrzynka”). W takim przypadku testy są budowane w oparciu o specyfikacje funkcjonalne. To podejście jest również nazywane podejście oparte na danych ponieważ przy jej użyciu testy budowane są w oparciu o różne metody dekompozycji zbioru danych. Zestawy testów wywodzące się z tych podejść są łączone, aby zapewnić kompleksowe testowanie oprogramowania.
Sterowanie ręczne używane we wczesnych stadiach rozwoju. Wszystkie decyzje projektowe są analizowane pod kątem ich poprawności i stosowności tak wcześnie, jak to możliwe, przy czym można je łatwo zmienić. Rozróżniać statyczny i dynamiczny podejścia do sterowania ręcznego. Ze statycznym podejście, struktura, powiązania kontrolne i informacyjne programu, jego dane wejściowe i wyjściowe są analizowane. Kiedy dynamiczny- wykonać testowanie ręczne(ręcznie zasymuluj proces wykonywania programu na podanych danych początkowych). Wstępnymi danymi do takich kontroli są: specyfikacje techniczne, specyfikacje, schematy strukturalne i funkcjonalne produktu programowego, schematy poszczególnych komponentów, a na późniejszych etapach - algorytmy i teksty programów, a także zestawy testów. Udowodniono, że sterowanie ręczne przyczynia się do znacznego wzrostu produktywności i niezawodności programów oraz może pomóc w wykryciu od 30 do 70% logicznych błędów projektowych i kodowania. Główne metody sterowania ręcznego to: inspekcje kodu źródłowego, widoki od końca do końca, sprawdź przy stole, oceny programów.
W sercu badania strukturalne polega na koncepcji najpełniejszego testowania ze wszystkich trasydostarczane przez algorytm (sekwencja instrukcji programu wykonywanych dla określonej wersji danych początkowych). Wady: zbudowane zestawy testów nie wykrywają brakujących tras i błędów, które zależą od osadzonych danych; nie gwarantujemy, że program jest poprawny.
Innym sposobem sprawdzenia programów jest funkcjonalny testowanie: program jest wyświetlany jako „ czarna skrzynka”, Celem testowania jest ustalenie, kiedy zachowanie programu nie jest zgodne ze specyfikacją. Aby znaleźć wszystkie błędy, musisz uruchomić wyczerpującytestowanie (ze wszystkimi możliwymi zestawami danych), co w większości przypadków jest niemożliwe. Dlatego zazwyczaj wykonują „ rozsądny„lub” do przyjęcia»Testowanie ograniczone do uruchomienia programu na niewielkim podzbiorze wszystkich możliwych wejść. W testowaniu funkcjonalnym wyróżnia się następujące metody tworzenia przypadków testowych: równoważna partycja; analiza wartości brzegowych; analiza przyczynowa; zgadywanie błędów.
Kiedy zintegrowany testowanie stosować testy oparte na metodach równoważnych klas, warunkach brzegowych i założeniach błędu, ponieważ badania strukturalne nie mają do niego zastosowania. Jedną z najtrudniejszych jest kwestia zakończenia testów, ponieważ nie można zagwarantować, że w programie nie pozostały żadne błędy. Testowanie jest często przerywane, ponieważ upłynął czas przeznaczony na jego wykonanie. Jest złożony, porusza się minimalne testy , który zakłada: testowanie wartości granicznych, dokładne sprawdzenie instrukcji, testowanie minimalnej konfiguracji sprzętu, możliwość edycji poleceń i powtarzania ich w dowolnej kolejności, odporność na błędy użytkownika.
Po zakończeniu kompleksowych testów przejdź do oceniający testowanie, którego celem jest poszukiwanie niezgodności z zakresem zadań. Testy ewaluacyjne obejmują testowanie: użyteczności, limitu wolumenu, limitu obciążenia, użyteczności, bezpieczeństwa, wydajności, wymagań dotyczących pamięci, konfiguracji sprzętu, kompatybilności, łatwości instalacji, użyteczności, niezawodności, odzyskiwania, dokumentacji, procedury.
Debugowanie to proces lokalizacja (ustalenie operatora programu, którego wykonanie spowodowało naruszenie procesu obliczeniowego) oraz skorygowanie błędów wykrytych podczas testowania oprogramowania. Aby naprawić błąd, musisz określić jego przyczynę. Debugowanie wymaga od programisty głębokiej wiedzy na temat specyfiki zarządzania używanym sprzętem, systemem operacyjnym, środowiskiem i językiem programowania, wdrażanymi procesami, naturą i specyfiką błędów, technikami debugowania i odpowiednim oprogramowaniem; niewygodny psychicznie (musisz szukać własnych błędów w ograniczonym czasie); pozostawia możliwość wzajemnego wpływu błędów w różnych częściach programu. Nie ma dobrze zdefiniowanych technik debugowania. Rozróżniać:
błędy składniowe- towarzyszy komentarz wskazujący ich lokalizację, ustalony przez kompilator (tłumacz) podczas wykonywania analizy składniowej i częściowo semantycznej;
błędy układu- znaleziony przez linker (linker) podczas łączenia modułów programu;
błędy czasu wykonania -wykryty przez sprzęt, system operacyjny lub użytkownika podczas wykonywania programu, manifest różne sposoby iz kolei są podzielone na grupy:
błędy definicji danych źródłowych (błędy transmisji, błędy konwersji, błędy przepisywania i błędy danych);
logiczne błędy projektowe (nieodpowiednia metoda, nieprawidłowy algorytm, niepoprawna struktura danych, inne) i kodowanie (błędy za pomocą zmiennych, obliczenia, interfejs międzymodułowy, implementacja algorytmów, inne);
błędy w kumulacji błędów w wynikach obliczeń (ignorowanie ograniczeń siatki bitowej i sposobów redukcji błędu).
Debugowanie programu w każdym przypadku zakłada przemyślenie i logiczne zrozumienie wszystkich dostępnych informacji o błędzie. Większość błędów można wykryć za pomocą znaków pośrednich poprzez dokładną analizę tekstów programu i wyników testów bez uzyskiwania dodatkowych informacji przy użyciu następujących metod:
testowanie ręczne (w przypadku znalezienia błędu należy ręcznie uruchomić testowany program za pomocą zestawu testów, podczas pracy z którym wykryto błąd);
indukcja(na podstawie dokładnej analizy symptomów błędów, które mogą objawiać się błędnymi wynikami obliczeń lub komunikatem o błędzie);
odliczenie (najpierw tworzą zbiór powodów, które mogą spowodować ten przejaw błędu, a następnie analizując przyczyny wykluczają te, które są sprzeczne z dostępnymi danymi);
cofanie się (na potrzeby wnioskowania o błędnym wyniku budowana jest hipoteza o wartościach głównych zmiennych, które mogłyby doprowadzić do otrzymania tego wyniku, a następnie na podstawie tej hipotezy przyjmuje się założenia dotyczące wartości zmiennych w poprzednim punkcie).
Aby uzyskać więcej informacji o błędzie, przeprowadza się dodatkowe testy i stosuje specjalne metody i środki: wyjście debugowania; zintegrowane narzędzia do debugowania; niezależne debuggery.
Ogólna metodologia debugowania oprogramowania napisanego do wykonania w systemach operacyjnych MS DOS i Win32:
Scena 1- badanie przejawów błędu;
Etap 2 -określenie lokalizacji błędów;
Etap 3- określenie przyczyny błędu;
Etap 4 -naprawa błędów;
Etap 5 -ponowne testowanie.
Proces debugowania można znacznie uprościć, jeśli zastosujesz się do podstawowych zaleceń ustrukturyzowanego podejścia do programowania:
zbudować program „z góry na dół”, od interfejsu do podprogramów przetwarzania, testując go podczas dodawania podprogramów;
wyświetlić użytkownikowi wprowadzone przez niego dane do kontroli i sprawdzić je pod kątem dopuszczalności natychmiast po wprowadzeniu;
zapewniają wyjście danych podstawowych we wszystkich punktach węzłowych algorytmu (rozgałęzienia, wywołania podprogramów).
Dodatkowe informacje na ten temat można uzyskać pod adresem.
Cel:
Przetestuj i debuguj wcześniej opracowany konkretny program w języku algorytmicznym wysokiego poziomu.
Zlecenie pracy i raportowanie.
W trakcie pracy laboratoryjnej konieczne jest skomponowanie zestawu testów dla wcześniej opracowanego programu i jego debugowanie.
Skompilowany zestaw testów należy przedstawić w raporcie.
Informacje teoretyczne.
Testowanie to proces wykonywania programu w celu określenia miejsca jego nieprawidłowego działania. Obejmuje przemyślane projektowanie trudnych zestawów danych wejściowych, które stwarzają największy potencjał awarii oprogramowania. Testowanie jest główną metodą wykrywania błędów w programie. Wyniki testu to wstępne dane do debugowania.
Debugowanie programu to etap jego rozwoju, na którym niwelowane są mankamenty nowopowstałego programu.
Jeśli program zachowuje się poprawnie przez solidny zestaw testów, nie ma powodu, aby twierdzić, że nie ma błędów. Po prostu nie wiadomo, kiedy nie działa i możemy mówić tylko o pewnym poziomie jego poprawności.
Testy, które nie pomagają wykryć błędów, a jedynie potwierdzają poprawność działania programu, są nieskuteczne, ponieważ prowadzić do marnotrawstwa zasobów i czasu.
Test to przykład obliczony ręcznie lub w inny sposób, którego pośrednie i końcowe wyniki są wykorzystywane do kontrolowania poprawności (przeżywalności) oprogramowania. Test składa się z danych początkowych i tych wartości, które powinny zostać wydrukowane przez wydruki debugowania podczas pracy nad tym testem. Wartości te muszą być zapisane dokładnie w takiej postaci, w jakiej powinien je podać komputer. Pożądane jest uzyskanie tych wartości w jakikolwiek sposób, ale nie taki, który jest zaimplementowany w programie, ponieważ w tym drugim przypadku błędy w algorytmizacji mogą nie zostać zauważone.
Zestaw testów powinien wyglądać następująco:
Aby sprawdzić wszystkie opcje efektu zewnętrznego programu i opcje jego wewnętrznej pracy algorytmu;
Aby wszystkie gałęzie algorytmu przeszły przynajmniej raz.
Aby kontrolować przypadki ograniczające i zdegenerowane.
Dane testowe powinny być tak dobrane, aby programista był w stanie obliczyć poprawny wynik jeszcze przed rozpoczęciem testów.
Proces testowania programu można podzielić na trzy etapy:
1. Sprawdzenie w normalnych warunkach.
2. Sprawdzenie w ekstremalnych warunkach.
3. Sprawdź w wyjątkowych sytuacjach.
Każdy z tych trzech etapów walidacji musi zapewniać uzyskanie prawidłowych wyników przy prawidłowych danych wejściowych oraz zgłaszanie komunikatów o błędach w przypadku nieprawidłowych danych wejściowych.
Sprawdzanie w normalnych warunkach
Przypadki, w których program musi działać ze wszystkimi możliwymi danymi wejściowymi, są niezwykle rzadkie. Zwykle istnieją określone ograniczenia dotyczące obszaru zmiany danych, w którym program musi zachować swoją wydajność. Program musi dawać poprawne wyniki dla reprezentatywnych zestawów danych wejściowych.
Sprawdzenie w ekstremalnych warunkach
Dane testowe tego etapu obejmują wartości graniczne zakresu zmiennych wejściowych, które program powinien postrzegać jako prawidłowe. Typowe przykłady to bardzo duże liczby, bardzo małe liczby lub brak informacji.
Sprawdzenie w wyjątkowych sytuacjach.
Wykorzystywane są dane źródłowe, których wartości leżą poza dopuszczalnym zakresem ich zmiany. Najgorsza sytuacja ma miejsce, gdy program uzna nieprawidłowe dane za poprawne i daje niepoprawny, ale wiarygodny wynik. Program musi odrzucić wszystkie dane, których nie może poprawnie obsłużyć.
Przykładowe testy.
Niech będzie wymagane obliczenie długości przekątnej równoległościanu za pomocą wzoru Konieczne jest wygenerowanie danych testowych dla warunków normalnych, ekstremalnych i wyjątkowych.
|
Strony Równoległościan |
Uwaga |
|||
Dobry test normalny d 1,7320508 |
||||
Pojęcia „debugowania”, „debugowania programu”. Proces debugowania. Rodzaje (techniki) debugowania, metody debugowania.
Po zakończeniu projektowania formularza i napisaniu kodu programu należy skompilować program. Podczas kompilacji należy poprawiać nie tylko błędy, ale również uwagi. Większość błędów ma charakter syntaktyczny. Często komunikaty o takim błędzie pojawiają się już na etapie pisania kodu programu. Jeśli błąd nie zostanie poprawiony przez użytkownika, tekst operatora zostanie podświetlony na czerwono. Jeśli błędy kompilacji zostaną naprawione, to po uruchomieniu aplikacji nie jest konieczne, aby nie pojawiły się żadne nowe błędy. Mogą to być błędy logiczne. Przy niektórych danych mogą pojawić się błędy: dzielenie przez 0, przepełnienie, wyodrębnienie pierwiastka kwadratowego z liczby ujemnej, brak inicjalizacji na początku obliczeń, otwarcie nieistniejącego pliku itp.
Gdy wyjątek występuje w czasie wykonywania, kompilator informuje o tym użytkownika w oknie dialogowym.
Gdy aplikacja zostanie przerwana, linia zostanie podświetlona na żółto, jeśli okno dialogowe zostanie zamknięte przez kliknięcie przycisku Debuguj. Jeśli komunikat o błędzie został zamknięty przyciskiem End, to zostanie zaznaczony tytuł procedury, w której znaleziono błąd.
Debugowanie programu
Jak już powiedzieliśmy, debugowanie jest dwojakiego rodzaju:
· Debugowanie składniowe... Kompilator wykrywa błędy składniowe, więc łatwo je naprawić.
· Debugowanie semantyczne (semantyczne)... Nadchodzi czas, gdy nie ma już błędów składniowych, ale program daje niepoprawne wyniki. Tutaj sam kompilator nie będzie w stanie niczego ujawnić, chociaż w środowisku programistycznym zwykle istnieją pomoce do debugowania, o których będziemy mówić później.
Debugowanie to proces lokalizacji i poprawiania błędów w programie.
Zasady debugowania
Zasady lokalizacji błędów:
· Większość błędów jest wykrywanych bez uruchamiania programu - wystarczy dokładnie przeanalizować tekst.
· Jeśli debugowanie jest zakleszczone i nie można wykryć błędu, lepiej odłożyć program. Kiedy oko jest „zamazane”, wydajność pracy uparcie dąży do zera.
· Niezwykle wygodnymi środkami pomocniczymi są mechanizmy debugowania środowiska programistycznego: śledzenie, pośrednia kontrola wartości. Możesz nawet użyć zrzutu pamięci, ale takie drastyczne działania rzadko są potrzebne.
· Eksperymenty typu „co się stanie, jeśli zmienisz plus na minus” - należy za wszelką cenę unikać. Zwykle nie daje to rezultatów, a jedynie bardziej dezorientuje proces debugowania, a nawet dodaje nowe błędy.
Zasady korekcji błędów są jeszcze bardziej podobne do praw Murphy'ego:
· W przypadku znalezienia jednego błędu mogą występować inne.
· Prawdopodobieństwo, że błąd zostanie znaleziony poprawnie, nigdy nie wynosi stu procent.
· Naszym zadaniem jest znalezienie samego błędu, a nie jego symptomu.
Chciałbym wyjaśnić to stwierdzenie. Jeśli program uparcie podaje wynik 0,1 zamiast zera odniesienia, proste zaokrąglanie nie rozwiąże problemu. Jeśli wynik jest ujemny zamiast odniesienia dodatniego, nie ma sensu przyjmować go modulo - zamiast rozwiązać problem, dostaniemy bzdury z dopasowaniem.
· Poprawiając jeden błąd, bardzo łatwo jest dodać kilka więcej do programu. Hooked bugs to prawdziwa plaga debugowania.
· Poprawianie błędów często zmusza nas do powrotu do etapu programowania. Jest to nieprzyjemne, ale czasami nieuniknione.
Metody debugowania.
1 skuteczna metoda
o Korzystanie ze zrzutu pamięci (wydruk).
Jest to interesujące z poznawczego punktu widzenia: możesz dokładnie zrozumieć procesy maszynowe. Czasami takie podejście jest nawet konieczne - na przykład, jeśli chodzi o przydzielanie i zwalnianie pamięci dla zmiennych dynamicznych przy użyciu nieudokumentowanych funkcji językowych. Jednak w większości przypadków otrzymujemy ogromną ilość niskopoziomowych informacji, z którymi wróg nie będzie chciał się uporać, a wydajność wyszukiwania jest znikoma.
o Używanie drukowania debugowania w tekście programu - dowolnie iw dużych ilościach.
Interesujące jest również uzyskanie informacji o wykonaniu każdej instrukcji. Ale tutaj znowu mamy do czynienia ze zbyt dużą ilością informacji. W dodatku zaśmiecamy program dodatkowymi operatorami, otrzymujemy nieczytelny tekst, a nawet ryzykujemy wprowadzenie kilkunastu nowych błędów.
o Korzystanie z narzędzi do automatycznego debugowania - śledzenie ze śledzeniem wartości pośrednich zmiennych.
Jest to prawdopodobnie najczęstsza metoda debugowania. Należy nie tylko zapominać, że jest to tylko jeden ze sposobów, a stosowanie go zawsze i wszędzie jest nieopłacalne.
Trudności pojawiają się, gdy musisz śledzić zbyt duże struktury danych lub ich ogromną liczbę. Jeszcze bardziej problematyczne jest prześledzenie projektu, w którym wykonanie każdego podprogramu prowadzi do wywołania kilkudziesięciu innych. Ale w przypadku małych programów śledzenie jest wystarczające.
Z punktu widzenia „prawidłowego” programowania, metody wymuszania są złe, ponieważ nie zachęcają do analizy problemu.
Podsumowując właściwości metod siłowych, otrzymujemy praktyczne rady:
o śledzenie i śledzenie wartości zmiennych dla małych projektów, oddzielnych procedur;
o używaj drukowania debugowania w małych ilościach i w interesach;
o zostawić zrzut pamięci w ostateczności.
2. Metoda integracji zawodowej - analiza programu od szczegółu do ogółu.
Patrzymy na symptomy błędu i określamy dane, które mają z nim przynajmniej jakiś związek. Następnie za pomocą testów eliminujemy mało prawdopodobne hipotezy, aż zostanie jedna, którą staramy się udoskonalić i udowodnić.
3. Metoda dedukcji - od ogółu do szczegółu.
Postawiliśmy hipotezę, która może wyjaśnić błąd, choć nie do końca. Następnie za pomocą testów ta hipoteza jest testowana i sprawdzana.
4. Ruch wsteczny zgodnie z algorytmem.
Debugowanie rozpoczyna się w miejscu pierwszego napotkania nieprawidłowego wyniku. Następnie praca programu jest śledzona (mentalnie lub za pomocą testów) w odwrotnej kolejności, aż do znalezienia miejsca ewentualnego błędu.
5. Metoda badawcza.
· Metoda indukcyjna.
Indukcja to analiza od szczegółu do całości. Patrząc na objawy błędu zidentyfikowane w jednym lub kilku testach i zależności między nimi, można znaleźć przyczynę błędu.
· Metoda odliczenia.
Ta metoda pozwala na podstawie niektórych ogólne teorie lub warunki wstępne, przy użyciu operatorów wyjątku lub doprecyzowania, aby dojść do określonego wniosku (aby znaleźć miejsce błędu). Podsumowując, musimy spojrzeć na wszystkie informacje, którymi dysponujemy: wszystkie wyniki wszystkich testów wszystkich błędów. Przedstawione hipotezy są pojedynczo wyłączone z rozważań.
· Śledzenie logiki w odwrotnej kolejności.
Metoda lokalizacji małych błędów. Debugowanie rozpoczyna się w punkcie programu, w którym napotkano jakiś wynik. W tym miejscu na podstawie uzyskanego wyniku należy ustalić, jakie powinny być wartości zmiennych. Wykonując mentalnie z danego punktu programu w odwrotnej kolejności i ponownie rozumując coś takiego: „Jeśli stan programu byłby taki w tym miejscu, to następny stan powinien być w innym miejscu”, można szybko i dokładnie zlokalizować błąd, tj. znaleźć miejsce w programie pomiędzy punktem, w którym stan programu był zgodny z oczekiwanym, a punktem, w którym stan programu różnił się od oczekiwanego.
Zautomatyzowane narzędzia do debugowania programów.
Standardowe możliwości debuggera. Kontrola poprawności napisanego programu (etapy).
Narzędzia do debugowania
Oprócz technik dobrze jest rozumieć narzędzia, które pomagają nam identyfikować błędy. To:
1) Wydruk awaryjny - wyświetla komunikaty o nieprawidłowym wykonaniu poszczególnych bloków i całego programu.
2) Drukowanie w węzłach programu - wyprowadzanie wartości pośrednich parametrów w wybrane przez programistę miejsca. Zwykle są to krytyczne sekcje algorytmu (np. Wartość, od której zależy dalszy przebieg wykonania) lub składowe złożonych formuł (osobno oblicz i wyświetl licznik i mianownik dużego ułamka).
3) Bezpośrednie śledzenie:
Arytmetyka (po czym są równe, kiedy i jak zmieniają się wybrane zmienne),
Logiczne (kiedy i jak jest wykonywana wybrana sekwencja instrukcji),
Kontrola indeksów wykraczających poza dopuszczalne limity,
Śledzenie dostępu do zmiennych,
Śledzenie wywołań podprogramów,
· Sprawdzanie wartości wskaźników elementów tablicy itp.
Dzisiejsze środowiska programistyczne często wymagają od nas reakcji na pojawiający się problem w trybie interaktywnym. W takim przypadku możesz:
· Zobacz aktualne wartości zmiennych, stan pamięci, sekcję algorytmu, w której wystąpiła awaria;
· Przerwij wykonywanie programu;
· Wprowadź zmiany w programie i uruchom go ponownie (w środowiskach kompilatorów będzie to wymagało ponownej kompilacji kodu; w środowiskach interpretowanych można kontynuować wykonywanie bezpośrednio ze zmienionej instrukcji).
Zalecane jest przeprowadzenie niezależnych testów modułu w czterech kolejnych krokach.
Krok 1. W oparciu o specyfikację debugowanego modułu przygotuj testy dla każdej możliwości i każdej sytuacji, dla każdej granicy obowiązującego zakresu wszystkich danych wejściowych, dla każdego zakresu zmian danych, dla każdego nieprawidłowego zakresu wszystkich danych wejściowych i każdego nieprawidłowego warunku.
Krok 2. Sprawdź tekst modułu, aby upewnić się, że każdy kierunek dowolnej gałęzi przejdzie przynajmniej jeden test. Dodaj brakujące testy.
Krok 3. Sprawdź tekst modułu, aby upewnić się, że dla każdej pętli istnieją testy, które zapewniają co najmniej trzy z następujących sytuacji: treść pętli nigdy nie jest wykonywana, treść pętli jest wykonywana raz, a treść pętli jest wykonywana tyle razy, ile to możliwe. Dodaj brakujące testy.
Krok 4. Sprawdź tekst modułu, aby upewnić się, że istnieją testy, które sprawdzają czułość na określone specjalne wartości wejściowe. Dodaj brakujące testy.
Wskazówki dotyczące debugera
1) Sprawdź dokładnie: błąd najprawdopodobniej znajduje się w niewłaściwym miejscu, w którym się wydaje.
2) Często okazuje się, że łatwiej jest podświetlić te części programu, w których nie ma błędów, a potem zajrzeć do reszty.
3) Uważnie przestrzegaj deklaracji stałych, typów i zmiennych, danych wejściowych.
4) W programowaniu sekwencyjnym należy zachować szczególną ostrożność podczas pisania sterowników i kodów pośredniczących - one same mogą być źródłem błędów.
5) Przeanalizuj kod zaczynając od największej ilości proste opcje... Najczęstsze błędy to:
Wartości argumentów wejściowych są akceptowane w złej kolejności,
Zmienna nie została zainicjowana,
Przy ponownym przekazaniu modułu zmienna nie jest ponownie inicjowana,
Zamiast rzekomego całkowitego kopiowania struktury danych kopiowany jest tylko najwyższy poziom (na przykład zamiast tworzyć nową zmienną dynamiczną i przypisywać jej żądaną wartość, adres jest głupio kopiowany z istniejącej zmiennej),
· Nawiasy w złożonym wyrażeniu są umieszczone nieprawidłowo.
6) Przy długotrwałym debugowaniu oczy „rozmazują się”. Dobrą praktyką jest szukanie pomocy u innej osoby, aby nie powtarzać błędnego rozumowania. Jednak często wyzwaniem pozostaje przekonanie tej drugiej osoby do pomocy.
7) Błąd najprawdopodobniej będzie twój i będzie w tekście programu. Znacznie rzadziej okazuje się:
W kompilatorze
System operacyjny,
Część sprzętowa,
· Okablowanie elektryczne w budynku itp.
Ale jeśli jesteś absolutnie pewien, że w programie nie ma błędów, spójrz na standardowe moduły, do których uzyskuje dostęp, dowiedz się, czy zmieniła się wersja środowiska programistycznego, w końcu po prostu uruchom ponownie komputer - pewne problemy (szczególnie w środowiskach DOS uruchamianych z pod Windows) są spowodowane nieprawidłową pracą z pamięcią.
8) Upewnij się, że kod źródłowy programu jest zgodny ze skompilowanym kodem obiektowym (tekst można zmienić, a moduł wykonywalny, który testujesz, jest kompilowany ze starej wersji).
9) Obsesyjne poszukiwanie jednego błędu prawie zawsze przynosi efekt przeciwny do zamierzonego. Jeśli to nie zadziała - odłóż zadanie, zacznij pisać kolejny moduł lub w najgorszym przypadku zrób dokumentację.
10) Spróbuj znaleźć przyczynę błędu. To pomoże ci:
Napraw program,
Wykryj inne błędy tego samego typu,
· Nie rób ich w przyszłości.
11) Jeśli znasz już objawy błędu, czasami warto nie usuwać go od razu, ale poszukać innych błędów na tle znanego zachowania programu.
12) Najtrudniejsze do wykrycia błędy to błędy najechania kursorem, czyli te, które zostały wprowadzone do kodu podczas naprawiania innych.
nadpisaniem jest weryfikacja wyników testów przez sam testowany program
Piękno bycia programistą ma wiele wspólnego z debugowaniem. Dlaczego programiści naruszają znane im wymagania - nie pytają o komentarze, nie opisują szczegółowo istoty rozwiązywanego problemu, nie stosują się do innych przydatnych rad. Najczęściej powodem jest niecierpliwość, wolą raczej zobaczyć, jak działa program, zobaczyć efekty jego pracy. Debugowanie to jakiś proces detektywistyczny. Podejrzewamy, że nowo utworzony program nie działa poprawnie. Domniemanie niewinności nie działa tutaj. Jeśli uda nam się przedstawić test, na którym program daje błędny wynik, to zostanie udowodnione, że nasze podejrzenia są słuszne. W tajemnicy zawsze mamy nadzieję, że program zadziała poprawnie za pierwszym razem. Ale cel testowania jest inny - próba obalenia tego założenia. I dopiero wtedy, po poprawieniu wszystkich zidentyfikowanych błędów, aby uzyskać poprawnie działający program. Niestety, debugowanie nie gwarantuje poprawności programu, nawet jeśli wszystkie testy przejdą pomyślnie. Debugowanie może udowodnić, że program jest nieprawidłowy, ale nie może udowodnić, że jest poprawny.
Sztuka testera polega na stworzeniu możliwie kompletnego systemu testowego, który sprawdza wszystkie możliwe gałęzie obliczeń. Wyjaśnijmy to na najprostszym przykładzie. Niech program znajdzie sumę pierwszych N elementów tablicy X zawierającej M elementów. Oprócz „normalnego” testu, który sprawdza sytuację, w której 1
Wcześniej wspomnieliśmy o prawie „czechaco” - początkujący może zawiesić dowolny system. Jest na to wytłumaczenie, nieświadomie ustawi on jedną z nieprawdopodobnych kombinacji danych wejściowych (pracując w środowisku wizualnym, naciska przycisk najbardziej nieodpowiedni dla danej sytuacji). Dlatego tester przeprowadzający debugowanie powinien być w stanie zająć pozycję początkującego, system testowy musi zapewnić, że program działa poprawnie nie tylko w „normalnych sytuacjach”, ale także jest „niezawodny” i nie doprowadzi do zapętlenia lub ekstremalnej przerwy prawdopodobne sytuacje.
Trudność debugowania polega na tym, że po znalezieniu i naprawieniu błędu otrzymujesz nowy program, dla którego proces debugowania należy rozpocząć od nowa, ponownie pomijając wszystkie testy. Wiadomo, że w programach są urzekające miejsca - korekta jednego błędu prowadzi do pojawienia się nowego. W takich przypadkach najlepszym wyjściem jest poszukiwanie innego, zasadniczo innego rozwiązania problemu.
Narzędzia do debugowania
Niektóre błędy programu są wychwytywane automatycznie na etapie kompilacji. Obejmuje to wszystkie błędy składniowe, błędy niezgodności typów i kilka innych. jednak poprawna składniowo program wymaga debugowania, ponieważ mimo uzyskania wyników obliczeń nie spełniają one wymaganych specyfikacji. Najczęściej program, który nie został jeszcze debugowany, działa poprawnie na niektórych danych początkowych i daje błędne wyniki na innych. Sztuka debugowania polega na znajdowaniu wszystkich sytuacji, w których działanie programu prowadzi do błędnych obliczeń. VBA posiada bardzo wyrafinowane narzędzia do debugowania programów, tj. wykrywanie błędów w programach (testowanie) i ich naprawianie. Istnieją dwie grupy narzędzi VBA, które pomagają programiście identyfikować i naprawiać błędy:
- Pierwsza grupa pozwala kontrolować przebieg procesu obliczeniowego tj. kolejność operatorów w procedurach, kolejność wywoływania samych procedur. W razie potrzeby w trakcie procesu debugowania można zmienić tę kolejność, np. Można pominąć wykonanie niektórych operatorów lub powrócić do ich wykonania
- Druga grupa narzędzi pozwala kontrolować zmianę stanu procesu obliczeniowego (wartości zmiennych i właściwości obiektów) podczas wykonywania. I tutaj możesz interweniować i zmieniać stan, ustawiając po drodze nowe wartości dla pewnych zmiennych.
Przed przystąpieniem do szczegółowego badania tych narzędzi należy przypomnieć, że podczas debugowania program może znajdować się w jednym z trzech stanów: projekt, obliczenia i przerwanie. Po zakończeniu projektowania można uruchomić program do wykonania. Po przerwaniu wykonywania programu w danym punkcie, po wejściu w stan przerwania można w tym miejscu sprawdzić wartości zmiennych i właściwości obiektów oraz w razie potrzeby zmienić te wartości „ręcznie”. W takim przypadku możesz zmienić kolejność wykonywanych operatorów, określić następny wykonywalny operator, możesz edytować tekst programu przed kontynuowaniem obliczeń. Przejście od stanu obliczeniowego do stanu przerwania może nastąpić z różnych powodów, na przykład po osiągnięciu punktu przerwania, gdy jeden z wielu warunków przerwania jest spełniony, z powodu wykonywania programu krok po kroku. Później omówimy wszystkie te możliwości, ale teraz rozważymy jeden specjalny przypadek. Czasami program „zapętla się” i musi zostać zmuszony do przejścia w stan przerwania. Jak zatrzymać uruchomiony program? Wystarczy nacisnąć parę klawiszy Ctrl + Break znaną z pracy w DOS. Pojawi się następujące okno dialogowe z komunikatem zatrzymania.
Debugowanie (debug, debugowanie) - etap tworzenia programu komputerowego, podczas którego błędy są wykrywane, lokalizowane i eliminowane. Aby zrozumieć, gdzie wystąpił błąd, musisz: znaleźć aktualne wartości zmiennych; dowiedzieć się, na której ścieżce był uruchomiony program.
Proces debugowania zaczyna się od próby odtworzenia problemu, który może być trudny podczas programowania współbieżnych procesów lub niektórych nietypowych błędów znanych jako heisenbugs.
Technologie debugowania.
1) Użyj debuggery - programy zawierające interfejs użytkownika do wykonywania programu krok po kroku: operator po operatorze, funkcja po funkcji, z zatrzymaniem w niektórych wierszach kodu źródłowego lub po osiągnięciu określonego warunku.
2) Wyświetlanie aktualnego stanu programu za pomocą punkt krytyczny programy operatory wyjściowe - do ekranu, drukarki, głośnika lub pliku. Zapisywanie informacji debugowania do pliku nazywane jest rejestrowaniem.
Narzędzia do debugowania.
1. Debugger - narzędzie programowe, które pozwala programiście obserwować wykonanie badanego programu, zatrzymywać go i restartować, uruchamiać w zwolnionym tempie, zmieniać wartości w pamięci, a nawet w niektórych przypadkach cofać w czasie.
2. Profilerzy- pozwalają określić, jak długo dany fragment kodu jest wykonywany, a analiza pokrycia ujawni sekcje kodu, które nie są wykonywalne.
3. Rejestratory API- pozwól programiście śledzić interakcję między programem a interfejsem API systemu Windows poprzez zapisywanie komunikatów systemu Windows w dzienniku.
4. Deasemblerypozwól programiście przeglądać kod asemblera pliku wykonywalnego
5. Snifferspomóc programiście w śledzeniu ruchu sieciowego generowanego przez program
6. Snifery interfejsu sprzętowegopozwoli Ci zobaczyć dane wymieniane między systemem a urządzeniem.
7. Dzienniki systemowe.
Za pomocą języki programowania wysokiego poziomutakie jak Java zwykle ułatwiają debugowanie, ponieważ zawierają narzędzia takie jak obsługa wyjątkówktóre znacznie ułatwiają poszukiwanie źródła problemu. W niektórych językach niskiego poziomu, takich jak Monter, błędy mogą prowadzić do subtelnych problemów, takich jak uszkodzenie pamięci lub wycieki pamięci, i może być trudno określić, co spowodowało błąd. W takich przypadkach mogą być wymagane zaawansowane sztuczki i narzędzia do debugowania.
Debugowanie \u003d testowanie + znajdowanie błędów + edycja
Typy debugowaniaOprogramowanie, w tym testowanie (w naszym kraju).
1.1. Autonomiczny debugowanie. Sekwencyjne oddzielne testowanie różnych części programów zawartych w oprogramowaniu z wyszukiwaniem i korektą błędów naprawianych podczas testowania. W rzeczywistości obejmuje debugowanie każdego modułu programu i debugowanie parowania modułów.
1.2. Złożony debugowanie . Testowanie oprogramowania jako całości, z wyszukiwaniem i korygowaniem błędów zarejestrowanych podczas testowania we wszystkich dokumentach (w tym w tekstach programów) związanych z oprogramowaniem jako całością. Takie dokumenty obejmują definicję wymagań oprogramowania, specyfikację jakości oprogramowania, specyfikację funkcjonalną oprogramowania, opis P.O. oraz teksty programów komputerowych.
2.1. Syntaktyczny debugowanie. Kompilator wykrywa błędy składniowe, więc łatwo je naprawić.
2.2. Semantyczny (semantyczny) debugowanie. Nadchodzi czas, gdy nie ma już błędów składniowych, ale program daje niepoprawne wyniki. Tutaj sam kompilator nie będzie w stanie niczego ujawnić, chociaż w środowisku programistycznym zwykle istnieją pomoce do debugowania, o których będziemy mówić później.
Powiązanie procesów testowania i debugowania poprzez algorytm debugowania.
Po napisaniu działającego kodu wykonywane są testy programu na różnych zestawach danych testowych.
W takim przypadku tester lub programista musi wcześniej uzyskać wynik kontroli, z którym przejdzie weryfikacja działania testowanego kodu.
W przypadku stwierdzenia rozbieżności między wynikami kontrolnymi a rzeczywistymi, rozpoczyna się poszukiwanie problematycznej części kodu i identyfikacja błędów w powyższy sposób.
Narzędzia do automatycznego testowania kodu źródłowego programów.
Główną techniką tutaj jest tworzenie testów kodu źródłowego, który zostanie zastosowany do testowanego fragmentu kodu, a system testujący będzie raportował ich wyniki.
Przykładami takich systemów są wbudowany moduł doctest w Pythonie oraz wielojęzyczna biblioteka testowa xUnit, rozpowszechniana na warunkach GNU / GPL i LGPL. Podstawą wszystkich tych narzędzi i technik jest rozbicie jednego dużego zadania na kilka jasnych i mniejszych zadań.
23. Podstawowe zasady programowania obiektowego: hermetyzacja, dziedziczenie, polimorfizm. Różnica między podejściem obiektowym a podejściem modułowym przy tworzeniu programów
Programowanie obiektowe (OOP) to paradygmat programowania, w którym podstawowymi pojęciami są pojęcia obiekty i zajęcia (lub, w mniej znanej wersji języków prototypowania, prototypy).
Prototyp jest obiektem próbnym, na którego obrazie i podobieństwie tworzone są inne obiekty.
Klasa
Pola, opisane w klasie, służą do przechowywania składowych stanu obiektu, tj. pola określają stan obiektów.
Metody, opisane na zajęciach, określają zachowanie obiektów. Każda metoda określa reakcję obiektu na jakąś zewnętrzną lub wewnętrzną wiadomość.
Obiekt - zmienna typu klasa
Zasady programowania obiektowego.
1. Abstrakcja.Abstrakcja to sposób na podkreślenie zbioru istotnych cech obiektu, wykluczenie z rozważań tych nieistotnych. W związku z tym abstrakcja jest zbiorem wszystkich takich cech.
2. Kapsułkowanie.
Hermetyzacja to zasada OOP, zgodnie z którą pola i metody są łączone w klasę.
Hermetyzacja pozwala na ograniczenie dostępu programistów do różnych pól i właściwości klasy (podobnie jak w modułach Delphigdy tylko część interfejsu jest widoczna z innych modułów). W ten sam sposób, wewnątrz klas, niektóre pola i metody mogą być swobodnie udostępniane do użytku (widoczne) w dowolnym miejscu w programie, a inne pola i metody mogą być udostępniane tylko wewnątrz bieżącego modułu i metod własnych klasy. Pozwala to ukryć różne cechy i możliwości klasy w opisie, dzięki czemu programiści, którzy ponownie używają klasy, skupiają się na jej najważniejszych właściwościach.
3. Dziedzictwo.Dziedziczenie to właściwość systemu, która pozwala na opisanie nowej klasy na podstawie już istniejącej z częściowo lub całkowicie pożyczoną funkcjonalnością.
Dziedziczenie to możliwość konstruowania nowych, bardziej złożonych klas z już istniejących poprzez dodawanie pól i definiowanie nowych metod ( zasada hierarchii).
Wywoływana jest klasa, z której tworzone jest dziedziczenie podstawowy, rodzic lub nadklasa. Nowa klasa - potomek, dziedzicznik lub klasa pochodna. Mechanizm dziedziczenia zapewnia klasie potomnej możliwość korzystania z pól i metod klas nadrzędnych. Łańcuchy dziedziczenia mogą być nieograniczony długość. W takim przypadku dozwolone są różne metody dla każdego ze spadkobierców nadpisanie.
4. Wielopostaciowość.Polimorfizm to właściwość systemu do używania obiektów z tym samym interfejsem bez informacji o rodzaju i wewnętrznej strukturze obiektu.
Polimorfizm („różnorodność”) w programowaniu - możliwość zmiany kodu programu zgodnie z wartością niektórych parametrów.
4.1. Czysty polimorfizm - możliwość różnej interpretacji kodu funkcji w zależności od rodzaju argumentów.
4.2. Funkcje przeciążeniowe (nazwy polimorficzne) - możliwość zdefiniowania kilku funkcji pod jedną nazwą; wybór żądanej funkcji może być określony przez typy argumentów, zakres (wewnątrz modułu, pliku, klasy itp.); jeśli wybór jest określony przez typ argumentów, wywoływane jest przeciążenie parametryczne.
4.3. Metody zastępujące - w OOP - możliwość różnych definicji metod w klasie podrzędnej i klasie nadrzędnej; konkretna metoda jest określana przez klasę obiektu, dla którego jest wywoływana. Podczas nadpisywania metod rozróżnia się prosty i złożony polimorfizm.
4.3.1. Prosty polimorfizm są używane, jeśli podczas wywoływania metody przesłoniętej, typ obiektu, dla którego ta metoda jest wywoływana, jest dokładnie znany, a zatem jest dokładnie wiadomo, która metoda powinna zostać połączona: metoda nadrzędna czy metoda potomna. W takim przypadku wymagana metoda jest określana na etapie kompilacja programy.
4.3.2. Złożony polimorfizm są używane, jeśli przy wywołaniu metody przesłoniętej konieczne jest wyjaśnienie, która metoda powinna zostać połączona: metoda nadrzędna czy metoda potomna, ponieważ obiekt, dla którego jest wywoływana metoda przesłonięta, może być albo obiektem klasy nadrzędnej, albo obiektem klasy potomnej. W takim przypadku wymagana metoda jest określana na etapie spełnienie programy, gdy typ obiektu jest dokładnie znany.
4.4. Funkcje uogólnione (szablony) - możliwość opisu sparametryzowanych klas i szablonów funkcji, parametrami takich opisów są typy argumentów metod lub funkcji.
Różnica między podejściem obiektowym a modułowym.
1) Zorientowany obiektowo podejście do projektowania oprogramowania. produkty oparte na:
- dobór klas obiektów;
- ustalenie charakterystycznych właściwości obiektów i metod ich obróbki;
- tworzenie hierarchii klas, dziedziczenie właściwości obiektów i metod ich przetwarzania.
2) Programowanie modułowe to organizacja programu jako zbioru małych niezależnych bloków, modułów, których struktura i zachowanie podlega pewnym regułom.
Należy zauważyć, że pojęcie „modułu” nie pokrywa się w tym przypadku z pojęciem „modułu” (w znaczeniu „biblioteki”) języka Pascal... Powinien to być prosta, zamknięta (niezależna) jednostka oprogramowania (procedura lub funkcja), widoczna, realizująca tylko jedną funkcję. Aby napisać jeden moduł, wystarczy minimalna znajomość tekstu innych osób, zarówno dzwoniących, jak i dzwoniących.
W programowaniu modułowym produktów programowych najpierw określa się skład i podporządkowanie funkcji, a następnie zestaw modułów oprogramowania, które realizują te funkcje.
24. Klasy i przedmioty: ich definicja, relacje między nimi. Rola składników klasy - pola, właściwości, metody. Opublikowane specyfikatory dostępu, publiczne, prywatne, chronione. Konstruktory i destruktory, ich rola. Wydarzenia i ich wykorzystanie w zarządzaniu programami
Klasa to strukturalny typ danych zawierający opis pól danych, a także procedury i funkcje, które działają z tymi polami danych (metodami).
Obiekt - zmienna typu klasa - jednostka w przestrzeni adresowej systemu komputerowego, która pojawia się podczas tworzenia instancji klasy (na przykład po uruchomieniu wyników kompilacji (i linkowania) kodu źródłowego do wykonania).
Relacja klasy do obiektu:
Pojęcie klasy jest bardziej ogólne niż pojęcie przedmiotu. Obiekt jest instancją klasy... Klasę można postrzegać jako zbiór obiektów (tak jak zestaw jest zbiorem elementów). Klasa może być niepodzielna lub podzielona (tak jak zbiór jest podzielony na podzbiory). Na przykład klasa PERSON zawiera podklasę STUDENT, która z kolei zawiera obiekt John_Smith.
Klasy mają(na przykład w Delphi):
− Pole klasa ( atrybut) w OOP - zmienna skojarzona z klasą lub obiektem. Pola, opisane w klasie, służą do przechowywania składowych stanu obiektu, tj. pola określają stan obiektów. Dostęp do pól uzyskuje się po ich nazwie.
− Metodyopisane w klasie (podprogramy przetwarzające pola i właściwości klasy) określają zachowanie obiektów. Każda metoda określa reakcję obiektu na jakąś zewnętrzną lub wewnętrzną wiadomość.
− własność - sposób na dostęp do wewnętrznego stanu obiektu, imitujący zmienną pewnego typu. Dostęp do właściwości obiektu jest realizowany poprzez wywołanie funkcji. Przy próbie ustawienia wartości tej właściwości wywoływana jest jedna metoda, a przy próbie uzyskania wartości tej właściwości inna metoda.
Nazywa się pola, właściwości i metody klasy członkowie klasy.
Zmienna opisana jako klasa jest w rzeczywistości wskaźnik do instancji klasy. W programach obiektowych używających klas każdy obiekt jest „instancją” określonej klasy i żadne inne obiekty nie są dostarczane.
Opublikowane specyfikatory dostępu, publiczne, prywatne, chronione.
Hermetyzacja to właściwość systemowa, która umożliwia łączenie danych i metod, które z nią współpracują, w klasie i ukrywanie szczegółów implementacji przed użytkownikiem.
Domyślnie (w Delphi) widoczność członków klasy nadrzędnej jest dokładnie dziedziczona, jednak jest dozwolona podnieść widoczność - zwiększanie dostępności pól, właściwości i metod. Ograniczona widoczność jest niedozwolona.
Poziomy hermetyzacji(dostępność dla wszystkich członków klasy):
1) Publiczny... Członkowie klasy w tej sekcji są dostępni z dowolnego miejsca w programie.
2) Prywatny... Członkowie klasy są dostępni tylko w module, w którym jest opisana klasa. Domyślnie wszystkie pola klasy są uważane za znajdujące się w sekcji prywatny.
3) Chroniony... Składowe klasy są dostępne w module, w którym klasa jest opisana, a także wewnątrz metod klas, które dziedziczą po tej klasie i są opisane w innych modułach.
4) Opublikowany... Członkowie klasy w tej sekcji są dostępni z dowolnego miejsca w programie. Ta sekcja zawiera właściwości klasy: pola dostępne do edycji i zmiany wartości w czasie projektowania i od Inspektorzy obiektów.
5) Zautomatyzowane... Członkowie klasy w tej sekcji są dostępni z dowolnego miejsca w programie. Opisy mogą być umieszczane w tej sekcji tylko wtedy, gdy klasa dziedziczy po klasie standardowej TAutoObject(w Delphi), przeznaczony do tworzenia tzw. serwerów automatyki z wykorzystaniem technologii COM (Kompetentny model obiektowy).
Konstruktory i destruktory.
Kiedy obiekt jest tworzony, specjalna metoda o nazwie konstruktor... Wykonuje różne akcje, aby zainicjować pola obiektu.
Kiedy obiekt jest zniszczony (na przykład została opisana wewnątrz procedury jako zmienna lokalna i jest usuwana z pamięci po jej zakończeniu), wywoływana jest inna metoda - burzycielktóry w razie potrzeby wykonuje różne dodatkowe czynności w celu zwolnienia pamięci.
Wydarzenia i ich wykorzystanie w zarządzaniu programami.
Zdarzenie OOP to komunikat, który pojawia się w różnych punktach kodu wykonywalnego, gdy spełnione są określone warunki.
Zdarzenia są zaprojektowane tak, aby móc przewidywać reakcję oprogramowania.
Aby rozwiązać ustawione zadanie, programy obsługi zdarzeń: gdy tylko program wejdzie w określony stan, następuje zdarzenie, wysyłany jest komunikat, a program obsługi przechwytuje ten komunikat.
25. Główne różnice między Object Pascal (Delphi) a Turbo Pascal. Tablice dynamiczne w Delphi: opis, cechy, zastosowanie
Turbo pascal - zintegrowane środowisko programistyczne dla języka programowania Pascal i języka programowania w tym środowisku, dialektu Pascal firmy Borland.
Delphi - środowisko programistyczne wykorzystujące język programowania Object Pascal.
Object Pascal jest wynikiem rozwoju języka Turbo pascal, który z kolei rozwinął się z języka Pascal. Pascal był językiem całkowicie proceduralnym.
Turbo pascalod wersji 5.5 dodanej Pascal zorientowany obiektowo właściwości, aw Object Pascal - dynamiczna identyfikacja typu danych z możliwością dostępu do metadanych klas (czyli opisu klas i ich składowych) w skompilowanym kodzie, zwanym także introspekcją - technologia ta otrzymała oznaczenie RTTI.
Ponieważ wszystkie klasy dziedziczą funkcje podstawowej klasy TObject, każdy wskaźnik do obiektu można przekonwertować na ten obiekt, a następnie użyć metody ClassType i funkcji TypeInfo, które zapewnią introspekcję.
Obiekt Pascal ( Delphi) jest wynikiem rozszerzenia funkcjonalnego Turbo Pascal.
Model obiektowy Delphi Pascal jest bardziej kompletny niż model używany przez Borland Pascal 7.0:
- ograniczenie dostępu do pól i metod poprzez zdefiniowanie własnego interfejsu do każdego pola klasy (pięć typów sekcji przy deklarowaniu klasy, przy użyciu właściwości);
- bardziej zaawansowane mechanizmy implementacji metod polimorficznych (metody abstrakcyjne, dynamiczne) ",
- narzędzia do pracy z metaklasami (zmienne metaklas, metody klas, mechanizm RTTI).
Tablice dynamiczne w Delphi.
Szyk to uporządkowany zbiór danych. Dynamiczny nazywana jest tablicą, której rozmiar może się zmieniać podczas wykonywania programu.
Ogłoszenie szyk: var My_Array: tablica typu BaseType;
W przypadku tej deklaracji nie jest przydzielana żadna pamięć, a początkowy rozmiar tablicy to zero.
Ustawienie rozmiaru szyk: SetLength (My_Array, 100);
Uzyskanie liczby elementów szyk: n: \u003d Długość (My_Array);
Odnosząc się do pierwszej pozycji szyk: My_Array: \u003d 10; x: \u003d My_Array;
Deklaracja 2D szyk: var A: tablica tablicy typu BaseType;
Jeśli przypiszesz tablicę dynamiczną do zmiennej, jej zawartość nie zostanie skopiowana, a przypisany zostanie tylko wskaźnik do tablicy. Ale jeśli zastosujesz się do nowej tablicy SetLength, wtedy nastąpi kopiowanie.
26. Struktura modułów w Delphi. Interfejs, części wykonywalne, części inicjujące i kończące. Procedury i funkcje: funkcje w Delphi
Projekt Delphi to zbiór jednostek programowych - modułów.
Delphi umożliwia oddzielenie funkcji i procedur moduł (Jednostka), a następnie skorzystaj z procedur i funkcji modułu w swoich programach, podając nazwę modułu na liście modułów wymaganych przez program (instrukcja używa). Moduł to plik z rozszerzeniem * .pas.
Moduł zaczyna się od nagłówka - instrukcji jednostka, który zawiera nazwę modułu.
Moduł składa się z sekwencji sekcji... Każda sekcja zaczyna się od słowa kluczowego i trwa do początku następnej sekcji. Do sekcji realizacja (implementacja) musisz umieścić procedury i funkcje zadeklarowane w sekcji berło.
Struktura modułu Delphi.
Jednostka<имя>;
Berło <интерфейсная часть>
Realizacja <исполняемая часть>
inicjalizacja <инициирующая часть>
finalizacja <завершающая часть>
Często brakuje części początkowej i końcowej... W inicjowanie części to instrukcje, które są wykonywane przed przekazaniem sterowania do programu głównego i zwykle służą do przygotowania jego pracy. W finał części, określa się instrukcje, które są wykonywane po zakończeniu działania programu głównego (w którym zasoby przydzielone programowi są zwalniane, pliki są zamykane itp.).
jednostka Nazwa modułu;
berło // sekcja interfejsu
(Opisy procedur modułu i funkcji, które mogą być używane przez inne moduły.)
konst // sekcja deklaracji stałych
(Deklaracje globalnych stałych modułu, które mogą być używane przez procedury i funkcje modułu).
rodzaj // deklaracje typów rozproszonych
(Deklaracje globalnych typów modułów, które mogą być używane przez procedury i funkcje modułu)
var // sekcja deklaracji zmiennych
(Deklaracje zmiennych globalnych modułu, które mogą być używane przez procedury i funkcje modułu)
realizacja // sekcja implementacji
(Opisy (tekst) procedur i funkcji modułu!}
Korzystanie z modułu.Aby program mógł korzystać z funkcji i procedur modułu, konieczne jest dodanie tego modułu do projektu oraz określenie nazwy modułu na liście używanych modułów. Po dodaniu nazwy modułu do listy modułów używanych przez aplikację, sam moduł należy dodać do projektu.
Procedury i funkcje w Delphi.
Procedura - podprogram, który wykonuje jakąś akcję i który można wywołać z innego miejsca w programie. Po wykonaniu procedury program kontynuuje pracę od miejsca, z którego został wywołany.
Procedura jest rodzajem podprogramu. Zwykle podprogram jest implementowany jako procedura w dwóch przypadkach:
- gdy podprogram nie zwraca żadnych danych do programu głównego;
- gdy podprogram zwraca więcej niż jedną wartość do programu wywołującego.
Parametry Czy wejście.
Deklaracja procedury
procedura ProcedureName (var parametr1: typ1;… var parametr K: typ K);
