Programa bat pausoz pauso zehaztutako agindu-sekuentzia xehea da, konputagailuak ataza espezifiko bat burutzeko edota problema zehatz bat ebazteko segitzen duena.

Konputagailu batek ataza-mota ugari burutu ditzake: kalkulu aritmetikoak egin, testuei formatua eman, dokumentuak dagokien inprimagailura prozesatzera bidalieta abar. Dena den, konputagailuaren hardwareak ezin ditu ataza horiek bere kabuz aurrera eraman; lan bakoitza zuzen egiteko eman beharreko pauso guztiak zehaztu behar zaizkio. Atazen arabera jaso beharreko agindu-multzo zehatz horiei esaten zaie programa.

Bi kategoria nagusi bereiz daitezke programazioan: batetik, sistemen programazioa dago, eta, bestetik, aplikazioen programazioa. Sistemen programak, gehienetan, behe-mailako programazio-lengoaietan idazten dira, eta aplikazioak, berriz, goi-mailako programazio-lengoaiak erabiliz.

Sistemen programazioak bere baitan hartzen ditu konputagailuaren oinarrizko barne-funtzioak zein bestelako funtzio espezializatuak burutzeko beharrezkoak diren programak, Konputagailuaren osagaien funtzionamendua kudeatuko eta gailuen arteko komunikazioa bideratuko dutenak. Hori dela eta, kasu askotan, behe-mailako programazio-lengoaiak erabiltzen dira, hardwarearen erabilera eraginkorragoa lortzearren. Sistemen programen adibide adierazgarrienak sistema eragileak, gailuen kontrolatzaileak eta zerbitzu-programak dira. Aplikazioen programazioan, berriz, gainerakoak sartuko lirateke.

Programazioan, garapenerako metodologia sistematikoa erabiltzea komeni izaten da. Modu horretan, pixkanaka hurbilduko gara ebatzi nahi den problemaren soluziora. Metodologiak programen garapenerako hainbat pauso logiko eta sekuentzial bereizten ditu eta pauso edo fase horiek emaitza egokia eta kalitate onekoa lortzen lagunduko dute.

Ebatzi beharreko problemaren konplexutasunaren arabera, programazio-prozesua alda daiteke, baina hurbilpen gehienek fase nagusi hauek dituzte: problemaren zehaztapena, analisia eta diseinua, programaren kodeketa, programaren egiaztapena eta arazketa, dokumentazioa eta mantentzea. Ondorengo ataletan, fase bakoitza zertan datzan aurkeztuko dugu, eta interesgarriak diren gaietan sakonduko.

Problemaren zehaztapena

Programazio-prozesua ebatzi beharreko problemaren zehaztapen argi eta idatzizkoarekin hasten da. Horrek berebiziko garrantzia du. Problema gutxiegi zehazten bada edo osotasunean ulertzen ez bada, oker ebatziko da prozesua. Garrantzitsua da hasieratik finkatzea problema ebatzita dagoen erabakitzeko irizpideak; adibidez, zer datu prozesatuko dituen, zer motatakoak diren, zer ordenatan iritsiko diren eta zer erantzun eman behar zaien. Gainera, ezagunak eta esanguratsuak diren faktore guztien berri eman beharko da fase honetan, baita programak kontuan hartu beharreko suposizioak ere. Esate baterako, nolako erabiltzaileak izango dituen, erabiltzaile-mota bakoitzari zer onartuko zaion eta zer ez, etab.

Analisia eta diseinua

Analisia problemaren sakoneko eta azaleko xehetasunak ulertzean datza, zehaztapena eta eskakizun guztiak ondo barneratuz. Fase honetan, ataza formalki definitu beharko da, eta, horretarako, programaren sarrera (datuak), irteera (informazioa edo emaitzak) eta ebazteko prozesua (datuetatik abiatuta emaitza sortzeko behar den metodoa) definitu beharko dira.

Behin problema modu argian zehaztuta eta formalizatuta dagoenean, ataza aurrera eramateko beharrezkoa den programaren logika garatzea dator. Horrek esan nahi du deskribatu behar dela programak nola lortuko dituen emaitzak sarrerako datuetatik abiatuta. Garrantzitsua da diseinua garbia, erraza eta argia izatea. Beharbada soluzio bat baino gehiago sortuko da, baina bakarra aukeratu behar da: soluzio egokia ahalik eta azkarren eta kostu txikienarekin ematen duena.

Problema konplexuak direnean, maiz azpi-problema txikiagotan bana daitezke, betiere zatiak bilduta problema osoa ebazteko helburuarekin. Azpi-problema horiek are zati txikiagotan banatuko dira, ebazten nahikoa errazak izan arte. Ondoren, zati bakoitza ebatziko duen modulua diseinatuko da. Azkenik, modulu horiek egoki lotuta, problema osoa ebaztera iritsiko da.

Diseinu-metodo honi beheranzko diseinua (Top-Down) edo diseinu modularra esaten zaio, eta problema etapa bakoitzean azpi-problema errazagotan zatitzeko prozesuari ondoz ondoko finketa deitzen zaio.

Metodo horren abantailak agerikoak dira. Hasteko, une bakoitzean problema txiki baten soluzioa bideratzen da, eta lan hori problema osoa ebaztea baino errazagoa da. Gainera, modulu bakoitza banaka diseinatu, kodetu, egiaztatu eta araztu daiteke. Horrela, gainerako moduluekin biltzean funtzionamendu egokia duela ziurta daiteke.

Modulu bakoitzaren diseinua egiteko bi pauso eman ohi dira: algoritmoaren garapena eta eskuzko probak egitea.

Algoritmoaren garapena

Algoritmo hitza Al Khwārizmī izenaren deformaziotik dator. Al Khwārizmī matematikari, astronomo, astrologo eta geografo persiarra izan zen, Khwārizm herrian jaioa eta 850. urtean hila. 825. urtean, hinduen sistema numerikoaren inguruko liburua idatzi zuen. Latinera itzultzean, Algoritmi de numero Indorum izenburua hartu zuen liburuak, eta hortik dator hitza. Aljebra hitza ere 830. urtean idatzi zuen liburu batetik dator, eta, horregatik, aljebraren aitatzat jotzen da.

Problema ebazteko burutu beharreko urrats-sekuentzia logikoari algoritmo esaten zaio. Algoritmoak problemaren soluzioaren eredua adierazten du, eta honako ezaugarri hauek behar ditu:

• Hasiera edo sarrera-puntu bakarra behar du.

• Zehatza izan behar du, anbiguotasunik gabekoa.

• Ondo definituta egon behar du.

• Orokorra izan behar du. Problemaren definizioan ager daitezkeen aldaeren aurrean portaera egokia behar du.

• Finitua izan behar du, hau da, algoritmoak uneren batean amaitu behar du.

Algoritmoa deskribatzeko, bi teknika ezagun erabili ohi dira: batetik, fluxu-diagrama baten bidez egin daiteke, eta, bestetik, pseudokodean idatz daiteke. Bi hurbilpenek betetzen duten ezaugarri garrantzitsu bat da kodetzeko erabiliko den lengoaiarekiko independentzia. Hona hemen bi hurbilpenen azalpenak.

Fluxu-diagramak

Fluxu-diagramaren kasuan, programaren logika modu grafikoan adierazten da eta unibertsalki onartutako ikur estandarrak erabiltzen dira (ISO 5807-1985: Information processing -- Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts.). Fluxu-diagrama batek erabili ohi dituen ikurren artean, hauek daude:

• Geziak: prozesuaren norabidea adierazten dute. Geziak algoritmoaren kontrola abiapuntutik helburura pasatzen dela erakusten du.

• Laukizuzenak: gertaera edo prozesuaren pauso bat adierazteko erabiltzen dira.

• Erronboak: baldintzak edo erabaki-hartzeak adierazten dituzte. Eskuarki, fluxua goiko partetik sartzen da, eta, baldintza ebaluatzearen emaitzaren arabera, albo batetik edo behetik jarraitu dezake, posizio bakoitzeko gezian emaitzaren berri emanez.

Ikur horietaz gain, gehiago ere badaude, prozesuaren hasiera/amaiera, sarrerak eta irteerak, dokumentuak, datu-fitxategiak, etab. adierazteko. Hurrengo irudiak etxera joateko prozesua deskribatzen duen diagrama erakusten du. Bi aukera dauzka, oinez joatea eta autobusez joatea, eta erabakia hartzeko euria ari duen aztertzen du.

Fluxu-diagrama baten adibidea

Pseudokodea

Pseudokodeak goi-mailako programazio-lengoaien antzeko erregela lexiko eta sintaktikoen multzoa erabiltzen du, baina ez da programazio-lengoaiena bezain zurruna, ezta hizkuntza naturala bezain malgua ere. Horrek programaren deskribapena arinago egitea ahalbidetzen du; programazio-lengoaiek eskaintzen duten semantika berbera izango du, baina orokorrean zehaztasunak kodeketa faserako uzten dira.

Pseudokodean algoritmoa deskribatzeko, hizkuntza naturala, programazio-lengoaien hitz gakoak, datu-egiturak eta kontrol-egiturak erabiltzen dira. Horien bitartez programatzailea programaren logikari dagozkion alderdietan zentratzen da.

Fluxu-diagrametan ez bezala, ez dago pseudokodea idazteko lengoaia estandarrik. Horrek esan nahi du programatzaile batetik bestera alda daitekeela. Baina baditu abantaila batzuk fluxu-diagramen aldean:

• Eragiketa errepikakor konplexuak erraz adieraz daitezke.

• Koskatze-arauak jarraitzen badira, erraz ikus daitezke programaren egituran dauden habiaraketa-mailak.

• Pseudokodetik programazio-lengoaia formalera pasatzea errazagoa da.

• Ikasleen ikasketa-prozesuan, pseudokodea hurrengo urratsetik hurbilago dago, aurretik esandakoagatik.

Irudiko diagramaren baliokidea adierazi nahi badugu, honen antzeko zerbait idatziko genuke:

baldin euria_ari_du? orduan

Oinez_joan

bestela

Autobusa_hartu

ambaldin;

Adibidean deskribatutako problema erraza da, baina problema konplexuagoak diseinatzeko oso baliagarriak dira bai fluxu-diagramak bai pseudokodea.

Eskuzko probak

Eskuzko probak edo papereko probak algoritmoaren zuzentasuna egiaztatzeko probak dira. Algoritmoa aurrean, sarrera desberdinekin duen portaera egokia den aztertzeko balio dute. Probak paperean eta arkatza erabilita egiten dira. Helburua da algoritmoaren exekuzioa pausoz pauso simulatzea ezagunak diren sarrerako datuetarako. Algoritmoaren logika zuzena bada, emaitza egokia lortuko da. Bestela, algoritmoa aldatu beharko da eta eskuzko probak errepikatu, portaera zuzena izan arte.

Proba hauek ondo diseinatuz gero, neurri handi batean emaitzaren kalitatea bermatuko da. Beste arlo batzuetan bezala, proba asko egitea baino garrantzitsuagoa da proba egokiak aukeratzea.

Algoritmo edo programa txikietan proba exhaustiboak egin daitezke, fluxuan dauden hautabide guztiak egiaztatzeko datu egokiak aukera daitezkeelako. Baina problema konplexuetan horrelako probak egitea oso garestia izan daiteke, bereziki eskuz ari garenean. Horrelakoetan erabiliko diren proba-datuak arreta handiz aukeratu behar dira, ahalik eta sarrera-mota gehienen portaera aztertu ahal izateko.

Probak egitearen helburuak hauek dira: aurretik detektatu gabeko erroreak harrapatzea eta proba-kasu onak edukitzea. Horretarako, printzipio hauek hartu behar dira kontuan:

• Proben bitartez problemaren zehaztapenetara iristea, hau da, zehaztutakoa probatzea.

• Kodeketara iritsi aurretik probak planteatzea eta diseinatzea.

• Erroreen % 80 moduluen % 20an gertatzen dira.

• Modulu bakoitzaren probekin hasi eta sistema osoa probatu arte jarraitu.

• Proba exhaustiboak ezin dira egin.

• Garapena egin duena ez den norbaitek burutzea komeni da.

Laburbilduz, hiru ezaugarri behar ditu proba on batek. Lehenengoa, erroreak aurkitzeko probabilitate handia izatea. Bigarrena, ez erredundantea izatea. Eta hirugarrena, ez errazegia ez zailegia izatea.

Probak burutzeko bi mekanismo ezagun aurkezten dira jarraian: kutxa beltza eta kristalezko kutxa edo kutxa zuria.

Programen erabiltzaile gehienei ez zaizkie axola funtzionamenduaren xehetasunak; erantzunak jaso nahi dituzte, besterik ez. Hau da, datuak jaso eta emaitzak ematen dituen kutxa beltz bat da haientzat programa. Probak prestatzean, modu berean, algoritmoaren edo programaren xehetasunetan erreparatu gabe, jokatzen duen mekanismoari kutxa beltza esaten zaio.

Kutxa beltzaren mekanismoan probarako datuak aukeratzean, hauek hartuko dira kontuan:

• Balio errazak. Emaitza egokiak jasotzen diren jakitea errazagoa da.

• Ohiko balio errealistak. Eguneroko erabileran programak jasoko dituen datu adierazgarriak aukeratuko dira.

• Mugako balioak. Azken osagaia prozesatzen ahaztea oso ohikoa da.

• Balio debekatuak. Kasu horiek identifikatu behar dira. Programak espero ez den erantzun bat baino errore-mezu egokia eman behar du.

Bigarren mekanismoak, kutxa zuriak, algoritmo edo programaren egitura logikoa aztertu eta hautabide guztiak hartuko dituzten datuak biltzeko helburua du. Arestian esan bezala, metodo hori ez da praktikoa programa handietan, baina modulu txikiak probatu eta arazteko ezin hobea da. Modulua ondo diseinatu bada, hautabide gutxi izango ditu eta erraz aukeratu ahal izango da proba-kasuen multzo txiki bat.

Algoritmo batzuk eskuz probatzea ez da erraza izaten, haien konplexutasuna dela medio. Horrelakoetan, puntu kritikoetan trazak eta erroreak detektatzeko aginduak gehitzen bazaizkio programari, akatsak detektatzeko aukera izango da.

Arazo handiena zehaztapena edo analisia egokiak ez direnean gertatuko da. Kasu horietan, problemaren azterketaren hasierara jo beharko da, eta, kasurik txarrenean, ordura arteko lana berregin. Horregatik dira hain garrantzitsuak hasierako pausoak. Eskuzko probak ere oso garrantzitsuak dira, programaren kodeketari ekin aurretik errore edo hutsune gehienak detektatzeko aukera ematen baitute.

Fase honetan bildutako proba guztiak baliagarriak izango dira programaren egiaztapenerako ere. Gainera, egiaztapenean proba masiboagoak egin ahal izango dira, denbora gutxiago beharko delako datu bakoitza egiaztatzeko. Hori dela eta, eskuzko probetako lana bildu eta dokumentatuko da, aukeratutako datuen helburua zein den azalduz eta lortu beharreko emaitzak zeintzuk diren zehaztuz.

Programaren kodeketa

Aurreko fasean definitutako algoritmoak problema ebazteko eskakizun guztiak betetzen dituela ziurtatu denean, programazio-lengoaia aukeratu eta fluxu-diagrama edo pseudokodearen logika lengoaiaren sintaxi konkretura bihurtuko da. Horretarako, lengoaiaren murriztapenak eta sintaxiaren eskakizun guztiak hartuko dira kontuan, kodeketaren emaitzak algoritmoaren portaera berbera izan dezan. Aurretik esan bezala, pseudokodearen kasuan errazagoa gertatuko zaigu kodeketa lana.

Kodeketa paperean egitea ohitura ona den arren, programatzaile askok konputagailuan idazten dute zuzenean. Programa idazteko, testu-editore arrunt bat edo programazio ingurune osoagoa erabil daiteke, eta emaitzari iturburu-programa deritzo.

Programa probatu ahal izateko, bi aukera daude: iturburu-programa konpilatu eta haren exekutagarria lortzea, edo programa interpretatzea. Labur adierazteko, konpiladoreak eta interpretatzaileak itzultzaileak dira, baina funtzionamendu desberdina dute. Konpiladoreak goi-mailako lengoaian idatzitako programak makinak ulertuko duen lengoaiara itzultzen ditu, programen exekutagarriak sortuz. Behin exekutagarria sortuta, konpiladoreak ez du erabilera gehiago. Interpretazioaren kasuan, iturburu-programa aginduz agindu aztertu, itzuli eta exekutatzen du. Kasu honetan ez da exekutagarririk sortzen; beraz, berriz probatu nahi denean, interpretatzailearen beharra dago. Nolabait esateko, konpiladoreak itzulpena behin bakarrik egin eta idazten du, eta interpretatzaileak bat-bateko itzulpenaren pareko lana burutzen du.

Prozesua edozein dela ere, lehenengo helburua programaren zuzentasuna egiaztatzea izango da. Kasu honetan, zuzentasuna esatean, esan nahi da idatzitako kodea lengoaiaren ezaugarriei atxikitzen zaiola, hau da, programak lengoaiaren arauak errespetatzen dituela. Hala ez bada, konpiladoreak edo interpretatzaileak errorea emango du eta ez da programa exekutatzerik izango errore horiek zuzendu ezean. Mota honetako errore guztiak zuzendu ondoren, programaren portaera probatu ahal izango da.

Programaren egiaztapena eta arazketa

Aurretik aipatutako erroreak zuzendu ondoren ere, gerta liteke programak zuzenki ez funtzionatzea, hau da, programan errore logikoak egotea. Horrek esan nahi du programa ez datorrela bat hasierako zehaztapenarekin.

Proba hauek eskuzko probak bezala egingo dira, baina kasu honetan programak datuetatik emaitzak automatikoki kalkulatuko dira eta denbora aldetik eskuz egitea baino azkarragoa izango da. Horrek, eskuz probatutako datuez gain, bestelako kasu batzuk probatzea ahalbidetuko du.

Programak datu horiek zuzenki ez prozesatzeak bi arrazoi nagusi izan ditzake: batetik, programa kodetzean erabilera-kasuren bat kontuan hartu ez izana edo oker tratatu izana, eta, bestetik, analisi edo diseinu aldetik erroreak egin izana. Lehenengo kasuan, programa zuzentzea nahikoa izango da, baina bigarrenean analisi eta diseinu faseetara itzuli beharko da portaera desegoki hori aldatzeko, eta ondorengo urrats guztiak ere eguneratu beharko dira. Hala ere, eskuzko proba egokiak egin badira, bigarren kasu hori gertatzea oso zaila izango da.

Programan zuzenketak eta egokitzapenak egitea ez da lan erraza izaten, errore logikoak identifikatzea bereziki zaila izaten delako zenbait lengoaiatan. Akatsak (bug) bilatze horri arazketa (debugging) esaten zaio, eta prozesu hori errazteko araztaile (debugger) izeneko tresna lagungarriak erabil daitezke.

Programaren dokumentazioa eta mantentzea

Hau izaten da programatzaile askok denbora faltagatik, kostuengatik edota alferkeriagatik alde batera uzten duten lana. Baina programak ez dokumentatzea, oso ohitura txarra izateaz gain, akats handia da, batik bat bi arrazoi hauengatik: batetik, erabiltzaileari zaila gertatuko zaio programak nola funtzionatzen duen jakitea; bestetik, beste programatzaile batek edo programatzaile berak handik denbora batera  programaren mantentze-lanak egin behar baditu, zaila gertatuko zaio programa aldatzea, fasez fase hartutako erabakien berri ez badu edo programaren logika ulertzen ez badu.

Dokumentazioa programa ulertzen, erabiltzen edo aldatzen lagunduko duen idatzizko gida da. Bertan hainbat motatako informazioa egon daiteke: problemaren enuntziatua, diseinuaren informazioa, diagramak, marrazkiak, prozedurak, probarako datuak, etab.

Dokumentazio hori hiru ataletan banatuta egongo da:

• Barne-dokumentazioa: programan barneratuta dauden iruzkinak; argitzeko helburua dute.

• Kanpo-dokumentazioa: problemaren ebazpenean fase desberdinetan erabili eta sortutako materiala biltzen du. Kanpo-dokumentazio on batek hauek izan ohi ditu:

  • Programaren helburuen zehaztapena.

  • Programak exekutatzeko sarreran edo irteeran behar dituen datuak (datu soilak, fitxategiak, datu-baseak, etab.).

  • Erabilitako datu guztien definizio osoa.

  • Azpiko logikaren azalpena, ahal dela fluxu-diagrama edo pseudokodea barne.

  • Probetarako erabilitako datuak, dagokien erantzuna eta zer helbururekin aukeratu diren.

  • Programaren mugak eta hedapenerako gidak.

• Erabiltzailearen gidaliburua: programaren funtzionamendua pausoz pauso deskribatzen du, erabiltzaileak zuzen erabili eta espero dituen emaitzak lor ditzan.

Programaren dokumentazioak izugarri laguntzen du programa mantentzen, hau da, aldaketak edota eguneraketak egiten. Garrantzi berezia izango du mantentze-lana egiten duena programa idatzi duen pertsona ez denean.

Hainbatean behin programa doitu behar izaten da, problema bera aldatzen doalako, kodea hobetzearren edota programa azkartzearren. Problema bera denboran zehar aldatzen doanean, askotan hasierako faseetara itzuli beharko da behar berriei erantzuna emateko, eta diseinuan eta kodeketan egin beharreko aldaketak burutu. Horrekin batera, proba faseak eta programaren arazketa ere errepikatu beharko dira, eta, azkenik, dokumentazioa egunean mantendu beharko da.

Ondorioz, programazio-prozesua ziklikoa denez, aurrerago prozesuari heldu behar dionari lana errazteko ezinbestekoa izango da programen dokumentazioa.