SW wykład 13 - Slajd2: Różnice pomiędzy wersjami

Z Studia Informatyczne
Przejdź do nawigacjiPrzejdź do wyszukiwania
Mengel (dyskusja | edycje)
Nie podano opisu zmian
 
Tarlecki (dyskusja | edycje)
Nie podano opisu zmian
 
Linia 2: Linia 2:


[[Grafika:sw1301.png|frame|center|]]
[[Grafika:sw1301.png|frame|center|]]
Niestety, dla wielu programistów najbardziej oczywiste podejście do
uporania się z zadaniem programistycznym opisanym przez parę warunków,
wstępnego i końcowego, względem których ma być poprawny skonstruowany
program, polega na tym, by po ewentualnej chwili refleksji i krótkim
zastanowieniu, po prostu wywołać edytor dedykowany wybranemu językowi
programowania i napisać program, z nadzieją, że zbudowany program
będzie rzeczywiście poprawny --- być może po drobnych modyfikacjach
wymuszonych przez niepoprawne wyniki testowania programu na
przypadkowo dobranych danych początkowych. Oczywiście, aby tak
zbudowany program mógł być przyjęty jako dobre rozwiązanie zadania
programistycznego, tę oczekiwaną poprawność programu należy koniecznie
uzasadnić, wykorzystując formalny system dowodzenia (całkowitej)
poprawności.
Niekiedy, szczególnie dla niewielkich zadań i przy dużym
doświadczeniu, wiedzy i praktyce programisty, takie postępowanie może
zostać uwieńczone sukcesem. Ale czy zawsze? Zapewne nie...

Aktualna wersja na dzień 19:01, 17 paź 2006

<<powrót do strony wykładu

Zadanie programistyczne Pierwsze podejście Przykład Weryfikacja Przykład Możliwe przyczyny porażki Poprawiony program Przykład dowodu Drugie podejście Wyprowadzanie programu Wyprowadzanie programu, c.d. Wyprowadzanie programu, c.d. Wyprowadzanie programu, c.d. Wyprowadzanie programu, c.d. Wyprowadzanie programu, c.d. Własność stopu Własność stopu, c.d. Poprawność przez konstrukcję

Niestety, dla wielu programistów najbardziej oczywiste podejście do uporania się z zadaniem programistycznym opisanym przez parę warunków, wstępnego i końcowego, względem których ma być poprawny skonstruowany program, polega na tym, by po ewentualnej chwili refleksji i krótkim zastanowieniu, po prostu wywołać edytor dedykowany wybranemu językowi programowania i napisać program, z nadzieją, że zbudowany program będzie rzeczywiście poprawny --- być może po drobnych modyfikacjach wymuszonych przez niepoprawne wyniki testowania programu na przypadkowo dobranych danych początkowych. Oczywiście, aby tak zbudowany program mógł być przyjęty jako dobre rozwiązanie zadania programistycznego, tę oczekiwaną poprawność programu należy koniecznie uzasadnić, wykorzystując formalny system dowodzenia (całkowitej) poprawności.

Niekiedy, szczególnie dla niewielkich zadań i przy dużym doświadczeniu, wiedzy i praktyce programisty, takie postępowanie może zostać uwieńczone sukcesem. Ale czy zawsze? Zapewne nie...