Beheranzko diseinua ("goitik beherako diseinua" ere euskaraz, eta "top down" ingelesez) eta goranzko diseinua ("behetik gorako diseinua" ere euskaraz, eta "bottom up" ingelesez) informazioaren zientziako problementzako ebazpenak lortzeko estrategiak dira. Batez ere softwarea sortzeko erabiltzen dira; konputagailu-programak sortzea sarritan oso lan konplexua izanik, programak diseinatzeko teknika hauek erabiltzeak dezente erraztu egiten du lan hori. Teknika hauen erabilera zabaldu egin da azkenaldian, eta ondorioz, gizarte-zientzietan eta beste zientzia zehatz batzuetan ere aplikatzen hasi dira gaur egun, besteak beste hauetan: Konputagailuen programazioan, Nanoteknologia, Neurozientzia eta psikologia, Kudeaketa eta antolaketa, Osasun publikoa, Arkitektura edota Ekologian.
Goitik beherako ereduan problema batentzako ebazpidea definitzerakoan hasieran sistemaren laburpen bat formulatzen da, xehetasun guztiak zehaztu gabe. Geroago definitzen da lehen urrats horretan guztiz zehaztu gabe erabili den elementu bakoitza, behin eta berriz, gero eta zehaztasun handiagoz, zehaztapen osoa eredua balioztatzeko nahikoa zehatza den arte. Goitik beherako eredua askotan "kutxa beltzen" laguntzarekin diseinatu da; kutxa beltz horien banakako osagaiak zehatz-mehatz azaldu ez badira ere, hasieran betetzen dituzten baldintza funtzionalekin definitu dira goi mailako ebazpidean, geroago xehetasun guztiekin definitu ahal izango delakoan.
Aitzitik, goranzko diseinuan banakako piezak zehatz-mehatz diseinatu eta gero osagai handiagoak handiagoak sortzeko lotzen dira, eta horiek lotzen joango da gero, sistema osoa osatu arte. Goranzko informazioaren jarioan oinarritutako estrategiak ere beharrezkoak eta nahikoak direla dirudite; sistemaren elementuetan eragina izan dezaketen aldagai guztien ezagutzan oinarrituta daude-eta.
Informatikan
Softwarea garatzeko prozesuan funtsezko eginkizuna dute beheranzko diseinua eta goranzko diseinua.[1][2][3]
Beheranzko diseinua Harlan Mills eta Niklaus WirthIBMko ikertzaileek sustatu zuten 1970eko hamarkadan. Mills-ek programazio egituratuko kontzeptuak garatu zituen eta proiektu batean probatu zituen 1969an New York Times egunkariko hemerotekako indizea automatizatzeko. Proiektuaren administrazio- eta ingeniaritza-arrakastak beheranzko diseinuaren zabalkuntza ekarri zuen IBM-en eta informatika-industrian zehar. Niklaus Wirth-ek (bere lorpenen artean Pascal programazio lengoaiarengarapena dago) Programen garapena pausoz-pauko birfinketaren bidez artikulua idatzi zuen (Program development by Stepwise Refinement), eragin handia izan zuena.[4]
Goitik beherako estrategiak sistema osoa (problema osoa) bere osotasunean ikusi ahal izateari ematen dio garrantzia. Hasieran prozesu global konplexua zehazten da, azpiprozesu sinpleagotan banatu eta azpiprozesu bakoitza bere aldetik ebazten saiatuko da gero. Ulertzen da kodeketa ezin dela hasi xehetasun maila nahikoa lortu arte, gutxienez sistemako zatiren batean. Horrek atzeratzen du sistemako unitate funtzionalak probatzeko urratsak diseinuaren zati handi bat osatu arte.
Behetik gorako estrategiak programazio eta probaketa goiztiarrei ematen die garrantzia. Lehenengo modulua zehaztu bezain laster has daitezke programazio eta probaketarekin. Estrategia honek arriskua ere badu, gauzak programatu behar baitira sistemako gainerako osagaiekin nola lotuko diren jakin gabe, eta baliteke konexio hori hasieran uste zen bezain erraza ez izatea. Bestalde, behetik gorako estrategiaren onura handienetako bat kodearen berrerabilpena da.[5]
Software modernoaren garapenean normalean biak uztartzen dira,goitik beherakoa eta behetik gorakoa. Nahiz eta normalean sistemaren ezagutza osoa diseinu egokia lortzeko baliagarria izan, alegia, beheranzko estrategia dena, software-garapenerako proiektu gehienetan lehendik dagoen kodea erabiltzen ere saiatzen da nolabait. Lehendik dauden moduluak erabiltzeak diseinuari beheko zaporea ematen dio. Planteamendu batzuek partzialki funtzionala den sistema bat osorik diseinatu eta programatzeko estrategia bat erabiltzen dute eta sistema hori proiektuaren baldintzak betetzeko hedatzen da geroago.
Konputagailuen programazioan
Beheranzko diseinua programazio-estilo bat da, lengoaia prozedural tradizionalen zutabea, non diseinua pieza konplexuak zehaztetik hasten den eta ondoren pieza txikiago batzuetan banatzen diren. Top-down metodoak erabiliz programa bat idazteko teknika prozedura nagusi bat idaztea da, beharko diren funtzio nagusi guztiak izendatzen dituena. Gero, programazio-taldeak funtzio horietako bakoitzaren eskakizunak aztertzen ditu, eta prozesua errepikatu egiten da. Zatitutako azpierrutina horiek azkenean ekintza sinpleak egingo dituzte, nonbakoitza erraz eta zehatz kodetu ahal izango baitira. Azpierrutina guztiak kodetu direnean, programa probatzeko prest dago. Aplikazioa maila altuan definitu da, goi maila horretan azaltzen diren kontzeptuak eta ekintzak koordinatuta, eta horrela gero maila baxuko lana autonomoa izan daiteke. Argi eta garbi definitu beharko da Beheko mailako abstrakzioak goragoko mailakoetan nola integratu beharko diren.
Problema bat ebazteko, beheranzko diseinuaren metodologiaz baliatzen garenean, problema azpiproblema sinpleagotan banatu eta azpiproblema bakoitza bere aldetik ebazten saiatzen gara. Hartara, algoritmo nagusi bat lortzen dugu —problema osoaren ebazpidearen isla edo dena— eta algoritmo horretan, normalean, ondoren findu edo garatu beharreko zenbait ekintza edo azpiekintza agertzen dira (ekintza edo azpiekintza horiek ez dira primitiboak gure prozesadorearentzat, eta hortik dator fintzearen beharra). Behin azpiekintza horiek findu eta gero, algoritmo nagusian "txertatu" eta problema osoaren ebazpide den algoritmoa lortzen dugu, prozesadorearen ekintza primitiboen terminotan adierazitako algoritmoa alegia.
Programazio-lengoaia batek azpiprogramak toki batean erazagutu eta gero beste batetik deitzeko aukera eskaintzen digunean, beheranzko diseinuari hurbilagotik jarraitzeko bide ezin hobea ematen digu. Izan ere, azpiprograma-erazagupenok diseinuan findu beharrekotzat utzitako ekintza edo azpiekintza horiei baitagozkie, eta aparte erazaguturik programako beste leku batetik deitzeko aukera izateak (behin edo gehiagotan), gorago aipatutako "algoritmo nagusian txertatze" hori ez du beharrezko egiten. Horrela lor dezakegu gure azken algoritmoak hasierako diseinuaren —lehen hurbilketaren— antz osoa izatea, ekintza ez-primitiboak azpiprograma-deien bitartez adieraziz eta problemaren ebazpidea den algoritmo hori abstrakzio maila gorenean gordez. Hori ez ezik, gure algoritmoak argiago eta irakurgarriagoak izango dira.
Programazio-lengoaia agintzaile edo inperatiboek bi azpiprograma mota eskaini ohi dituzte: funtzioak eta prozedurak. Funtsean berdintsuak diren arren, deitzeko moduak eta emaitza itzultzeko erak bereizten ditu erabat: funtzioak espresioetatik deitu behar dira eta balio bakarra itzultzen dute beti; prozedurak deitzeko prozedura-dei sententziak erabiltzen dira.
Eraikuntza-blokeak goranzko diseinuaren adibide dira, piezak lehenbizi sortu eta gero batu egiten direlako, batzean piezek nola funtzionatuko duten kontuan hartu gabe.
Goranzko estrategia batean, sistemaren oinarrizko elementu indibidualak xehetasun handiz zehazten dira lehenik. Elementu horiek elkarren artean lotzen dira azpisistema handiagoak eratzeko, eta azpisistema horiek, aldi berean, maila askotan lotzen dira, maila altuagoko sistema oso bat eratu arte. Estrategia horrek "hazi" eredu baten antza du askotan, eta horren ondorioz, hasierak txikiak dira, baina, batzuetan, konplexutasunean eta osotasunean hazten dira. Objektuetara bideratutako programazioa (OOP) aplikazio eta programa informatikoak diseinatzeko "objektuak" erabiltzen dituen paradigma bat da. Ingeniaritza mekanikoan, Pro/Engineer, Solidworks eta Autodesk Inventor bezalako software programekin, erabiltzaileek osotasunaren parte ez diren piezak bezalako produktuak diseinatu ditzakete, eta ondoren pieza horiek batu, Legorekin egindako eraikuntzak bezalako mihiztadurak osatzeko. Ingeniariek piezak diseinatzea deitzen diote urrats horri.
Goranzko estrategia bat aplikatzerakoan, intuizio ona behar da moduluak eman behar duen funtzionaltasuna aurrikusteko. Dagoen sistema batetik abiatuz eraikiko bada sistema bat, ikuspegi hori egokiagoa izango da, existitzen diren modulu batzuetatik abiatzen bada.
Erreferentziak
↑Watt, David Anthony.. ([1996]). ADA lengoaia eta metodologia. Servicio Editorial de la Universidad del País Vasco = Euskal Herriko Unibertsitateko Argitalpen Zerbitzua ISBN8475858651. PMC434213410. (Noiz kontsultatua: 2019-09-06).
