Prof.nadzw.dr hab.inż. Władysław Brzozowski

Politechnika Częstochowska

Instytut Elektroenergetyki

Wykłady z przedmiotu:

TECHNIKA PROGRAMOWANIA

studia magisterskie, kierunek Elektrotechnika,

specjalno** Informatyka w Elektroenergetyce, sem.VI

Wyk*ad 3. Zasady techniki programowania (cd). Fazy procesu programowania

1. Fazy procesu programowania

Wyr**nia si* nast*puj*ce fazy procesu programowania:

Analiza obliczeniowego problemu technicznego. Sformu*owanie celu oblicze*. Jakiego typu rozwi*zania oczekujemy od procesu obliczeniowego.

Dob*r odpowiedniej metody matematycznej. Metoda powinna by* jak najprostsza. Nale*y wykorzysta* du** szybko** oblicze* mikrokomputera. Przyk*adowo: rozwi*zuj*c problem optymalizacji nale*y preferowa* prost* metod* przeliczania wszystkich mo*liwych wariant*w rozwi*zania, nawet je*li komputer liczy*by ten problem kilka godzin a mo*e nawet dni. Dopiero gdy problem jest tak du*y, *e komputer nie policzy go w rozs*dnym czasie, trzeba uciec si* do bardziej z*o*onych metod matematycznych np. analitycznych z zakresu tzw. bada* operacyjnych. Cz*sto warto skorzysta* z metod tzw. heurystycznych, kt*re na*laduj* mechanizmy my*lenia m*zgu ludzkiego. Metody te nie s* tak *cis*e jak analityczne, ale na og** znacznie efektywniejsze.

Dekompozycja problemu, czyli podzia* na niezale*ne systemy mikrokomputerowe; w ramach jednego systemu na pakiety mikrokomputerowe; w ramach pakietu na programy; w ramach programow na modu*y. Okre*lenie architektury oraz funkcji poszczeg*lnych sk*adowych problemu.

Opracowanie algorytmu - do programu lub w przypadku du*ego programu - do poszczeg*lnych modu**w. Algorytmem nazywamy ci*g wzor*w matematycznych rozwi*zuj*cy dany problem, obejmuj*cy i funkcje matematyczne i kompletne funkcje logiczne. Je*li problem nie jest bardzo skomplikowany, to algorytm tworzy si* automatycznie w trakcie pisania programu. Je*li jednak problem jest z*o*ony, to algorytm nale*y sporz*dzi* wcze*niej na papierze. Warto taki algorytm opracowa* w postaci tabelarycznej, w uk*adzie kolumn: - numer bloku obliczeniowego algorytmu; - nazwa bloku obliczeniowego; - co wyliczamy w danym bloku; - wzory matematyczne i logiczne; - symbole matematyczne zmiennych; - jednostki; - symbole programowe zmiennych; - typy zmiennych programowych; - formaty zmiennych programowych; - pochodzenie zmiennych programowych (gdzie czytane lub gdzie wcze*niej obliczone); - uwagi. Bardzo pomocna jest tu tak*e forma schematu blokowego oblicze*. Niekiedy schemat taki rysuje si* na roboczo dla rozpracowania jakiego* jednego podprogramu a nawet jednej instrukcji, np. szczeg*lnie z*o*onej instrukcji logicznej. Je*li pisze si* niezbyt du*y program, to wszystkie powy*sze dane: wzory, zmienne, typy, formaty, pochodzenie zmiennych itd. mo*na zamie*ci* wprost w programie w postaci komentarzy. Generalnie w programie *r*d*owym warto pisa* jak najwi*cej komentarzy, gdy* wracaj*c do programu po jakim* czasie cz*sto ju* si* nie pami*ta o co w nim chodzi*o.

Zaprojektowanie dokument*w *rod*owych oraz wydawnictw, czyli wej*cia-wyj*cia z programu.

Napisanie tekstu programu, pod wewn*trznym edytorem systemu programowania, z zapisem na dysk.

Uruchamianie programu. Faza usuwania b**d*w sk*adniowych w trakcie kompilacji. B**dy sk*adniowe wy*apuje sam kompilator.

Uruchamianie programu. Faza usuwania b**d*w formalnych, np. postaci wydawnictw, format*w liczb itp. Bl*d*w tych kompilator nie jest w stanie wykry*, ale s* one dobrze zwykle widoczne przy pr*bnych obliczeniach.

Je*li stwierdza si*, w trakcie wst*pnych prac uruchomieniowych, *e program jest powolny, nie mie*ci si* w pami*ci, zajmuje za du*o miejsca na dysku lub w pami*ci operacyjnej, to po fazie wst*pnego testowania programu nast*puje faza jego optymalizacji.

Uruchamianie programu. Faza usuwania b**d*w merytorycznych. B**dy te s* cz*sto niewidoczne, cho* gro*ne, bo powoduj* zafa*szowanie wynik*w oblicze*. Obowi*zuje generalna zasada, *e nie wolno oddawa* u*ytkownikowi programu, kt*ry nie zosta*by gruntownie przetestowany. To testowanie musi odbywa* si* na drodze r*wnoleg*ych oblicze* kontrolnych realizowanych na kalkulatorze lub, je*li to wyj*tkowo jest mo*liwe, przez por*wnanie z wynikami z innego podobnego programu, co do poprawno*ci ktorego ma si* zaufanie. Obliczenia kontrolne powinny by* wielowariantowe. Dane do tych oblicze* nale*y przygotowa* w nast*puj*cy spos*b: - ka*dy program mo*na przedstawi* w postaci drzewa rozga*eziaj*cych si* *cie*ek. Takie rozga**zienia w jez. Turbo Pascal wynikaj* np. z instrukcji wyboru "Case nazwa_zmiennej of", z instrukcji warunkowej "if warunek then else", z instrukcji skoku itp. W trakcie oblicze* kontrolnych sterowanie powinno przej** cho*by raz po ka*dej *cie*ce rozga**zie*; - nale*y tak przygotowa* dane kontrolne, by przetestowany zosta* ka*dy cho*by najmniejszy podprogram lub funkcja, a tak*e ka*da opcja wszystkich menu programu; - warto*ci wej*ciowych danych kontrolnych dobra* tak zw*aszcza, *eby wypada*y na: granicy przedzia**w deklaracji zmiennych i granicach wyra*e* logicznych w instrukcjach warunkowych, w punktach nieci*g*o*ci r**nych zmiennych i charakterystyk. Do*wiadczenie uczy, *e b**dy najcze*ciej pope*nia si* na r**nych tego typu granicach.

Przedostatnia faza jest to tzw. kosmetyka programu, czyli drobne poprawki i upi*kszenia programu.

Ostatni* faz* jest wydanie dokumentacji programu, tj. obowi*zkowo instrukcji dla u*ytkownika. Zwykle u*ytkownikowi nie udost*pnia si* program*w *r*d*owych, ale teksty tych program*w warto wydrukowa* na papierze i z*o*y* we w*asnym archiwum, niezale*nie od zabezpieczenia tekst*w tych program*w na no*nikach magnetycznych lub CD w kilku kopiach.

2. Wytyczne pisania programu

Dobry program:

ma struktur* modu*ow* i nak*adkow*. Chodzi o to by zajmowa* jak najmniej miejsca w pami*ci operacyjnej;

zawiera du*o procedur i funkcji. Powt*rzenie jakiego* fragmentu tekstu jest b**dem w sztuce programowania - nale*y fragment ten zorganizowa* w postaci podprogramu lub funkcji;

uwzgl*dnia ka*d* sytuacj* obliczeniowa (np. koincydencj* danych), jaka mo*e si* zdarzy* w przysz*o*ci i ma z g*ry okre*lone procedury dzia*ania w tych sytuacjach;

ma z*o*on* cho* maksymalnie uporz*dkowan* struktur*. Sprawdzianem, *e program jest dobrze napisany jest brak w nim (lub jest minimalna liczba) instrukcji skoku "goto etykieta". Dobry program wykorzystuje wiele wzajemnie zagnie*d*onych instrukcji "Case zmienna of";

jest w maksymalnym stopniu przyjazny u*ytkownikowi tzw. user friendly, tzn. ma zorganizowane rozwijaj*ce si* menu sterowane klawiszami kursora lub mysz*, ma wewn*trzny w*asny edytor u*atwiaj*cy wprowadzanie danych, w ka*dym momencie a przynajmniej w w*z*ach decyzyjnych oferuje u*ytkownikowi pomoc tzn. help, uwzgl*dnia wszystkie mo*liwe warianty konfiguracji komputera np. systemy polskich liter, wydaje cz*sto komunikaty informuj*ce u*ytkownika o stanie i post*pie oblicze*, oraz o r**nych sytuacjach awaryjnych, w maksymalny sposob prowadzi u*ytkownika za r*k* zw*aszcza tam gdzie ma on podja* jak** decyzj*;

nie dopuszcza do wyst*pienia b**du sygnalizowanego przez DOS, tzn. zawczasu przechwytuje kontrol* nad b**dami, wydaje komunikat i instruuje u*ytkownika jak wyj** w spos*b kontrolowany z sytuacji awaryjnej;

jest tzw. „idiotoodporny”, tzn. kontroluje ka*d* liczb* lub inn* dan* wprowadzan* przez u*ytkownika, reaguje na przyciskanie b**dnych klawiszy, nie pozwala na zniszczenie danych w spos*b przypadkowy (**da potwierdzenia wyboru niebezpiecznych opcji), obejmuje helpy dostosowane do r**nych u*ytkownik*w od pocz*tkujacych do zaawansowanych, umo*liwia zawsze kontrolowane wyj*cie z ka*dej opcji menu (przez ESC), je*li u*ytkownik wszed* w t* opcj* bezmy*lnie.

---