6. K¢dovanie ------------ Etapa k¢dovania alebo implement cie syst‚mu s£vis¡ s transform ciou podrobnej çpecifik cie jednotlivìch modulov syst‚mu a ich vz jomnìch v„zieb do programovej realiz cie jednotlivìch modulov. S etapou k¢dovania s£vis¡ vìber programovacieho jazyka a prostredia a çtandardy, ktor‚ je potrebn‚ pri k¢dovan¡ dodr§iavaœ. Nesystematickì pr¡stup ku k¢dovaniu sp“sobuje zhorçenie Ÿitate–nosti k¢du a s åou spojen‚ zhorçenie £dr§by syst‚mu. Vìber vhodn‚ho programovacieho jazyka (vìvojov‚ho prostredia) je prvìm probl‚mom, ktorì vo v„Ÿçine pr¡padov bìva vyrieçenì v predch dzaj£cich etap ch. Ak vçak nie je cie–ovì jazyk urŸenì, je potrebn‚ zoh–adniœ nasledovn‚ krit‚ri : - sk£senosti program torov s danìm jazykom - vhodnosœ jazyka pre dan£ aplik ciu - dostupnosœ podpornìch prostriedkov pre vìvoj syst‚mov v danom jazyku - cena vìvojov‚ho prostredia - mo§nosœ dodr§ania çtandardov pre kontrolu kvality - bud£ca strat‚gia, tzn. orient cia firmy na urŸit‚ vìvojov‚ prostredie Na z klade zoh–adnenia uvedenìch krit‚ri¡ je mo§n‚ vypracovaœ pre ka§d£ alternat¡vu struŸn£ çt£diu, obsahuj£cu odhad n kladov na realiz ciu syst‚mu v danom prostred¡. V s£Ÿasnosti sa vyu§¡vaj£ jazyky çtvrtej gener cie (4GL). Historicky je po§n‚ vìvoj programovac¡ch jazykov rozŸleniœ do gener ci¡ nasledovne: prv  gener cia - programovanie poŸ¡taŸov priamo v bin rnom k¢de. druh  gener cia - assemblery, ktor‚ symbolicky vyjadrovali bin rne inçtrukcie. Pro preklade bola jedna inçtrukcia jazyka 1. gener cie transformovan  do jednej inçtrukcie v bin rnom k¢de. tretia gener cia - jazyky vyççej £rovne (FORTRAN, COBOL, PASCAL). Pro preklade je jedna inçtrukcia transformovan  do 5-10 inçtrukci¡ v bin rnom k¢de. Vytv ranì k¢d nie je tak efekt¡ivny ako programovanie priamo v jazyku 2. gener cie, ale zvìçenie produktivity a mo§nosœ strukt£rovan‚ho programovania prekrìva tento nedostatok. çtvrt  gener cia - sa vyznaŸuje neprocedur lnosœou jazykov v tom, §e pri programovan¡ sa definuje Ÿo je potrebn‚ vykonaœ a na kompil tor sa prenech va zodpovednosœ sa spr vne prelo§enie akcie do strojov‚ho k¢du. Vo vçeobecnosti jednej inçtrukcii 4GL zodpoved  30-50 inçtrukci¡ v strojovom k¢de. Nevìhodou 4GL je neefekt¡vna realiz cia programu a nemo§nosœ ovplyvniœ zabudovanì sp“sob realiz cie jednotlivìch akci¡. 6.1. Strat‚gie implement cie softv‚rovìch syst‚mov -------------------------------------------------- Pod strat‚giou implement cie budeme rozumieœ vo–bu postupu, v ktorom bud£ jednotliv‚ programov‚ moduly realizovan‚ a odovzd van‚ k testovaniu. Je zrejm‚, §e strat‚gia implement cie ve–mi £zko s£vis¡ so strat‚giou testovania. V praxi sa v s£Ÿasnosti pou§¡vaj‚ dve strat‚gie: vytv ranie syst‚mu zdola-nahor a vytv ranie syst‚mu zhora-nadol. Vytv ranie syst‚mu zdola-nahor ------------------------------ Vytv ranie syst‚mu zdola-nahor predstavuje tradiŸn£ met¢du vìstavby softv‚rovìch syst‚mov. Najsk“r sa implementuj£ moduly na najni§çej £rovni, ktor‚ sa odovzdaj£ na testovanie. Postupne sa implementuj£ moduly vyçç¡ch £rovn¡, ktor‚ integruj£ moduly ni§ç¡ch £rovn¡. Testovanie syst‚mu preto prebieha taktie§ zdola nahor. Uvedenì pr¡stup m  nasledovn‚ nedostatky: 1. pre testovanie modulov na ni§ç¡ch £rovniach je potrebn‚ pripraviœ speci lne moduly, ktor‚ produkuj£ udaje pre testovanie ni§ç¡ch modulov. Touto aktivitou sa spotrebuje znaŸn‚ mno§stvo Ÿasu a testovacie moduly nebud£ po ukonŸen¡ testovania Ôalej pou§¡van‚. Testovacie moduly je potrebn‚ uchov vaœ z d“vodov Ôalç¡ch rozçirovan¡ syst‚mu. Pri ka§dej modifik cii je potrebn‚ op„tovne testovaœ existuj£ce moduly a preveriœ ich funkŸnosœ. 2. chyby identifikovan‚ pri testovan¡ integruj£cich modulov (na vyççej £rovni) vy§aduj£ op„tovn‚ testovanie. Znamen  to, §e danì modul m“§e byœ testovanì nieko–kokr t pod–a postupu integraŸn‚ho testovania syst‚mu. 3. d“le§it‚ chyby v logike cel‚ho syst‚mu s£ identifikovan‚ a§ v etape intergraŸn‚ho testovania, Ÿo bìva pred pl novanìm term¡nom dodania syst‚mu. Neskor  identifik cia tìchto chìb m“§e sp“sobiœ znaŸn‚ Ÿasov‚ sklzy v term¡ne dodania. 4. syst‚m nie je mo§n‚ demonçtrovaœ, pokia– nie je ukonŸen‚ testovanie modulov na najvyççej £rovni hierarchie. 5. vyu§¡vanie prostriedkov je koncetrovan‚ na etapu integraŸn‚ho testovania. V tejto etape je potrebn‚ prepracov vaœ jednotliv‚ moduly, kompilovaœ ich a sp jaœ do vykonate–nej verzie. Strojovì cas sa preto uber  dalç¡m pr cam, ako napr. dokonŸovanie dokument cie syst‚mu. Vytv ranie syst‚mu zhora-nadol ------------------------------ Pri n vrhu zhora-nadol implement cie zaŸ¡na u modulov na najvyççej £rovni. Pri testovan¡ logiky tìchto modulov sa vçak treba vyrovnaœ so skutoŸnosœou, §e ni§çie modulu eçte nie s£ implementovan‚. Preto sa tieto moduly nahradzuj£ fikt¡vnymi subsyst‚mami, ktor‚ simuluj£ pr cu subsyst‚mov. Simul cia pr ce m“§e spoŸ¡vaœ jednak vo vopred definovanej transform cii vstupov na vìstupy, alebo vyp¡san¡m spr vy, §e danì modul bol vykonanì. Testovacie d ta pre jednotliv‚ testovan‚ moduly s£ navrhovan‚ tak, aby bola preuk zan  spr vnosœ logiky testovan‚ho modulu. Testovac¡m £dajom mus¡ byœ prisp“soben  i funkcie jednotlivìch simulaŸnìch modulov. Implement cia syst‚mu prebieha tak, §e simulaŸn‚ moduly s£ postupne nahr dzan‚ plnìmi implement ciami modulov, ku ktorìm s£ prip jan‚ simulaŸn‚ moduly pre ni§çiu £roveå. Tento postup sa opakuje a§ pokia– sa nedosiahne najni§çia hierarchick  uroveå modulov v syst‚me. Implement ciu syst‚mu v praxi nie je v§dy mo§n‚ realizovaœ ako Ÿistì n vrh zhora-nadol. Pr¡Ÿiny nemo§nosti aplik cie tohoto pr¡stupu na vçetky projekty je mo§n‚ zhrn£œ nasledovne: 1. niektor‚ moduly na najni§çej £rovni je potrebn‚ implementovaœ najsk“r, preto§e ich pou§¡vate– vy§aduje sk“r ako celì syst‚m. M“§e sa jednaœ napr. o vìstupn‚ zostavy, ktor‚ s£ potrebn‚ pred uveden¡m cel‚ho syst‚mu do prev dzky. 2. testovanie modulov jednotlivo a samostatne je jednoduhçie, ako testovanie logiky cel‚ho syst‚mu. V pr¡pade realiz cie syst‚mu zhora-nadol je potrebn‚ vytv raœ mno§stvo simulaŸnìch modulov, ktor‚ sa po implelment cii jednotlivìch modulov st vaj£ zbytoŸn‚. Napriek uvedenìm nedostatkom, implement cia a n sledn‚ testovanie syst‚mu met¢dou zhora-nadol m  nieko–ko nespornìch prednost¡. Najvìznamnejçdie s£ nasledovn‚: 1. skor  identifik cia najz va§nejç¡ch chìb. Chyby v logike modulu predstavuj£ jedny z najz va§nejç¡ch chìb. Pro n vrhu zhora-nadol sa chyby v logike hierarchicky najvyççich modulov identifikuj£ skoro, Ÿ¡m ost va pomerne dostatok Ÿasu na ich odstr nenie. Tieto chyby zv„Ÿça vy§aduj£ reimplement ciu, resp. op„tovnì n vrh znaŸnej Ÿasti syst‚mu. Akl sa tento proces s£stred¡ do z vereŸnìch et p, sp“sobuje znaŸne kol¡zie v pl novan¡ cel‚ho projektu. 2. spo–ahlivosœ. Po zakomponovan¡ modulu do syst‚mu a jeho otestovan¡ je funkŸnosœ modulu mnohon sobne overovan  pri testovan¡ modulov na ni§çej £rovni. Pre moduly na vyçç¡ch £rovniach sa zvyçuje pravdepodobnosœ odhalenia skrytej chyby. Tìm sa zvyçuje spo–ahlivosœ cel‚ho syst‚mu, preto§e rozsah degrad cie funkŸnosti syst‚mu je nepriamo £mernì hierarchickej £rovni modulu s chybou. 3. ladenie. Pri implement cii zhora-nadol sa v ka§dom kroku do syst‚mu zakomponuje pr ve jeden novì modul. Tìm sa lokaliz cia chyby obmedzuje na presne definovan£ casœ syst‚mu (u n vrhu zhora-nadol sa integr ciou otestovanìch modulov m“§e odhaliœ chyba v –ubovo–nej Ÿasti integrovan‚ho syst‚mu). 4. vyu§¡vanie vìpoŸtovej techniky (ladenie, kompil cia, sp janie) je rovnomermne rozlo§en‚ do celej etapy implement cie a testovania. Pr¡stup zhora-nadol minimalizuje enormnì tlak na vyu§¡vanie techniky ku koncu projektu. 5. vyu§¡vanie program torskìch kapac¡t je efekt¡vnejçie. Je to sp“soben‚ jednak skorìm identifikovan¡m z sadnìch chìb a z nich vyplìvaj£cej reimplement cie Ÿast¡ syst‚mu, ako aj redukciou potreby vytv rania testovac¡ch £dajom pre vstupy a vìstupy jednotlivìch modulov. V tomto pr¡pade je £lohou nadradenìch modulov generovaœ vstupy a vìstupy pre testovanì modul. 6. psychologickì aspekt. Pri n vrhu zhora-nadol je od poŸiatku k dispoz¡cii kostra syst‚mu, ktor£ je mo§n‚ demonçtrovaœ managementu. Hoci to nie je plnohodnotn  koneŸn  verzia, je mo§n‚ pomerne skoro identifikovaœ odliçnosti od predst v pou§¡vatre–a, resp. od predpokladan‚ho spr vania sa syst‚mu. 6.2. ætrukt£rovan‚ programovanie -------------------------------- Zavedenie princ¡pov çtrukt£rovan‚ho programovania bolo reakciou na stav vo vìvoji programov v 60-tych rokoch. Vtedajçie jazyky boli zalo§en‚ na intenz¡vnom vyu§¡van¡ GOTO pr¡kazov a Ÿitate–nosœ, testovate–nosœ a £dr§ba vytv ranìch programovìch syst‚mov bola ve–mi problematick . Pr ve potreba zlepçenia vlastnost¡ syst‚mov z h–adiska £dr§by bola najsilnejç¡m podnetom pre zavedenie urŸitej systematiŸnosti do procesu k¢dovania. Prvìm impulzom pre zmenu v çtìle programovania bol Ÿl nok [Bohm:1966], v ktorom autori prvìkr t pouk zali na mo§nosœ reprezent cie ka§d‚ho programu pomocou troch typou riadiacich konçtrukci¡: sekvencie, podmienen‚ho vetvenia a iter cie. Cie–om Ÿl nku bolo pouk zanie na mo§nosœ programovania bez pou§itia GOTO pr¡kazu. V Ÿl nku [Dijkstra:1968] u§ je explicitne vyjadrenì zlì vplyv pou§itia GOTO pr¡kazu na vlastnosti programu, najm„ vçak na Ÿitate–nosœ a £dr§bu. Argumenty proti pou§itiu GOTO pr¡kazu mo§nos sumarizovaœ nasledovne: 1. GOTO nie je potrebn‚. Ka§dì program je mo§n‚ zap¡saœ pomocou riadiacich konçtrukci¡ sekvencie, iter cie a vetvenia. Typickìmi pr¡kladmi pou§itia pr¡kazu GOTO v programe je: - realiz cia cyklu - ukonŸenie vykon vania cyklu - reakcia na urŸit£ situ ciu (oçetrovanie chybovìch stavov) - prechod na urŸit£ Ÿasœ programu 2. pou§¡vanie GOTO pr¡kazov zhorçuje Ÿitate–nosœ a £dr§by programov. Rozskoky pomocou GOTO pr¡kazov nezodpovedaj£ vyjadreniu logiky sp“sobu rieçenia probl‚mu. Je potrebn‚ neust le sledovaœ. napr. vnorenia cyklov, aktiv ciu proced£r atÔ. 3. pou§¡vanie GOTO pr¡kazov zni§uje preh–adnosœ a vìrazov£ silu z pisu programov: label: while a> 0 then begin ... ... if a>0 then goto label; end; 4. Sp„tn‚ GOTO (tzn. skok nasp„œ v programe) m  horçie £Ÿinky ako skok dopredu. Pri skoku nasp„œ je potrebn‚ op„tovne analyzovaœ u§ analyzovanì k¢d a zisœovaœ sp“sob spracovania v stave, v ktorom bol skok vykonanì. 5. nie je mo§n‚ pou§¡vaœ form lne met¢dy na verifik ciu programov. Napriek uvedenìm nedostatkom, existuje viacero d“vodov, ktor‚ hovoria v prospech GOTO pr¡kazu. Jednìm z nich je oçetrovanie vìnimoŸnìch stavov, ktor‚ pri pou§it¡ "povolenìch" konçtrukci¡ m“§e byœ zlo§it‚ a neprirodzen‚. Inìm d“vodom je, §e spracovanie pri n silnom zav dzan¡ çtrukt£rovanìch riadiacich konçtrukci¡ m“§e byœ neefekt¡vne, napr, vytv ran¡m a neust lym testovan¡m zlo§itìch podmienok. Z tohoto d“vodu v [Knuth:1974] sa nehovor¡ o çtrukt£rovanom programovan¡ ako programovan¡ bez GOTO pr¡kazov, ale ako o programovan¡, ktor‚ minimalizuje pou§itie GOTO pr¡kazov a povo–uje pou§itie GOTO pr¡kazov iba pri skoku dopredu. Obmedzenie pou§¡vania GOTO pr¡kazov nie je jedinou charakteristikou çtrukt£rovan‚ho programovania. Òalçou charakteristikou je pou§¡vanie £dajovìch çtrukt£r. V poŸiatkoch programovania poskytovali programovacie jazyky iba obmedzen£ paletu £dajovìch çtrukt£r (Ÿ¡sla, znaky, reœazce, polia). Spracov van‚ inform cie bolo potrebn‚ reprezentovaœ tìmto çtrukt£ram, Ÿo vplìvalo s£Ÿasne i na z pis riadenia spracovania. Riadiace konçtrukcie preto nezodpovedali logike spracovania probl‚mu, ale logike manipul cie £dajov reprezentovanìch v £dajovìch çtrukt£rach. S postupom vo vìvoji v oblasti programovac¡ch jazykov sa zav dza mo§nosœ defin¡cie £dajovìch çtrukt£r, ktor‚ vyplìvaj£ zo çtrukt£ry spracov vanìch inform ci¡. Tìm je mo§n‚ logiku manipul cie s £dajmi postaviœ na £roveå logiky rieçenia probl‚mu. Vytv ran‚ programy sa preto st vaj£ Ÿitate–nejç¡mi. ætrukt£rovan‚ programovanie je preto opisne mo§no charakterizovaœ nasledovne: - pou§¡vanie definovanìch riadiacich çtrukt£r - vìrazn‚ obmedzenie pou§itia GOTO pr¡kazu a ohraniŸenie mo§nost¡ jeho pou§itia na presne definovan‚ sp“soby - vytv ranie £dajovìch çtrukt£r zodpovedaj£cich çtrukt£re spracov vanìch inform ci¡ 6.3. DoporuŸenia pre tvorbu programov ------------------------------------- Dodr§iavanie princ¡pov çtrukt£rovan‚ho programovania m“§e s¡ce zvìçiœ citate–nosœ programov, no nie je postaŸuj£cim krit‚riom, Existuj£ Ôalçie z sady, ktorìch dodr§iavanie zvyçuje Ÿitate–nosœ. Tieto z sady vçak nie s£ stanoven‚ vo forme noriem, z le§¡ na program torovi, ako ich interpretuje v praxi. Pou§¡vanie mien premennìch vyjadruj£cich podstatu uchov vanìch inform ci¡ Z prieskumov n kladov na jednotliv‚ atpy §ivotn‚ho cyklu programu vyplìva, §e viac ako polovica n kladov je venovan  na £dr§bu syst‚mu. Z tohoto £daja je zrejm‚, §e k¢d programu bude potrebn‚ viacn sobne prepracov vaœ. Prepracovanie nebude vykon vaœ v preva§nej v„Ÿçine pr¡padov tvorca modulu, ale inì program tor. Z tohoto d“vodu je potrebn‚, aby bol k¢d programu (tzn. logika modulu) zrozumite–nì pre toho, kto ho analyzuje a z dokument cie pozn  funkciu modulu. Premenn‚ predstavuj£ d“le§it£ Ÿasœ modulu, preto§e v nich sa uchov vaj£ vstupn‚ £daje i medzivìsledky spracovania. Premenn‚ je mo§n‚ pomenov vaœ r“znymi sp“sobmi (napr. A1). Z prieskumov vyplìva, §e pomenovanie premennìch na z klade vìznamu inform ci¡, ktor‚ dan  premenn  uchov va, zvyçuje Ÿitate–nosœ programu podstatnìm sp“sobom. Z tohoto d“vodu je pomenov vanie premennìch jednìm zo z kladnìch princ¡pov pri z pise k¢du programu. Okrem priraÔovania zmysluplnìch mien je potrebn‚ uchov vaœ aj konzistentnosœ mien premennìch vo vçetkìch moduloch syst‚mu. Ak v jednom module je pou§it  napr. premenn  FREQUENCY, potom v Ôalç¡ch moduloch referencuj£cich ten istì typ inform cie nie je vhodn‚ priraÔovaœ premennej men  FREQ, FRQNCY atÔ. Pou§¡vanie koment rov v zdrojovom programe Pre pochopenie logiky modulu je vhodn‚, ak je k dispoz¡cii popis s‚mantiky jednotlivìch Ÿast¡ k¢du. Pre vyjadrenie tejto s‚mantiky je mo§n‚ pou§iœ programov‚ koment re. Pre zaŸleåovanie koment rov do programu neexistuj£ ust len‚ met¢dy. Odpor£Ÿa sa zaŸleniœ na zaŸiatok ka§d‚ho modulu koment rov£ Ÿast, ktor  objasåuje funkciu modulu. Ka§d  podstatn  casœ k¢du by mala byœ zdokumentovan , tzn. mala by v dokument cii byœ zachyten  podstata logiky modulu. Pou§¡vanie parametrov V programoch sa Ÿasto vyu§¡vaj£ konçtanty, tzn. premenn‚, ktorìch hodnota sa poŸcas psracovania nemen¡. Pri pou§¡van¡ konçt nt by ich hodnota mala byœ referencovan  zodpovedaj£cim menom, nie pou§it¡m priamo hodnoty. ætrukt£rovanie zdrojov‚ho textu programu Pre zvìçenie Ÿitate–nosti k¢du sa odpor£Ÿa çtrukt£rovaœ k¢d, tzn. reprezentovaœ logiku programu pomocou form tovania zdrojov‚ho textu. V praxi to znamen , §e pri z pise k¢du by sa mali dodr§iavaœ nasledovn‚ pravidl : - na jedno riadku najviac jeden pr¡kaz - pou§¡vanie pr zdnych riadkov na rozŸlenenie k¢du na spolu s£visiace Ÿasti k¢du - oznaŸovanie pr¡kazov bloku pomocou odsadzovania textu sprava OhraniŸenia na pou§¡vanie vnorenìch IF pr¡kazov Pri z pise viacerìch vnorenìch IF pr¡kazov sa m“§e stratiœ s£vislosœ medzi THEN a ELSE Ÿasœami jednotlivìch pr¡kazov. Pou§itie odsadzovania sprava m“§e spreh–adniœ k¢d. Vo vçeobecnosti vçak mo§no konçtatovaœ, §e pr¡liçn‚ vn ranie IF pr¡kazov vìrazne zni§uje preh–adnosœ k¢du. 6.4. K¢dovacie çtandardy ------------------------ V ka§dej organiz cii produkuj£cej softv‚r sa pou§¡vaj£ ist‚ k¢dovacie çtandardy, tzn. normy, ktor‚ s£ z v„zn‚ pre program torov pri vytv ran¡ k¢du. Medzi çtandardy m“§e patriœ napr. sp“sob vytv rania koment rov, rozsah modulov, h’bka vnorenia v IF pr¡kaozch atÔ. Zav dzanie çtandardov prin ça vìhody, ale aj nevìhody pri dogmatickej aplik cii tìchto çtandardov. Jednìm z pr¡kladov mo§nìch nepriaznivìch d“sledkov pou§itia çtandardov m“§e byœ obmedzenie ve–kosti modulov. Ako bolo uk zan‚ v Kapitole 5, tak‚to krit‚rium m“§e viesœ k naruçeniu vyv §enosti modulov. ætandard by preto mal byœ definovanì vo forme doporuŸenia, priŸom ka§d‚ poruçenie doporuŸenia by malo byœ konzultovan‚ s managerom implement cie. Cie–om k¢dovac¡ch çtandardov je u–ahŸenie £dr§by syst‚mu. Ak sa vçak zist¡, §e pou§¡van‚ standardy pr¡liç sœa§uj£ pr cu program torom, çtandardy je mo§n‚ modifikovaœ i poŸas projektu.