M3 - Programació estructurada / Continguts UF2: Disseny modular

Descomposició funcional

• L’objectiu serà resoldre el problema general com a una suma de subproblemes més petits.

• La solució a cada subproblema s’anomena subrutina o subprograma, i a Java, mètode.

• Permet la reutilització del codi, facilita la seva lectura i el seu manteniment.

• Escriure codi més genèric facilita la seva reutilització.

Disseny descendent

• El mètode del disseny descendent consisteix en descompondre el problema a resoldre en altres més senzills. A aquests se'ls aplica el mateix procediment fins arribar a problemes prou petits que podem resoldre directament.

• Refinament de l’algorisme (stepwise refinement) és com es coneix aquest procediment de descomposició.

• Representació en forma d'arbre:

- Cada node és un mòdul, o problema, o solució hipotètica.

- Cada subarbre depenent d'aquest node es fa servir per a la resolució d'aquest subproblema.

- El node del nivell més alt és el problema de partida.

- L’algorisme serà correcte si la solució que es dóna a cada nivell ho és.

- El programa es pot construir de sota a dalt creant primer procediments que resolguin els mòduls de detall que, un cop comprovats seran utilitzats per altres procediments més generals fins a arribar a la creació del programa.

Reutilització de subproblemes resolts

• La descomposició mitjançant disseny descendent permet reaprofitar la solució de subproblemes idèntics, o força semblants.

• Qualsevol subproblema d’un nivell donat pot ser part de qualsevol subproblema d’un nivell superior. Per remarcar

• En descompondre un problema, s'ha d'intentar fer-ho de manera que es forci l’aparició de subproblemes repetits, i així la seva resolució es pot reaprofitar en diversos llocs.

Aplicació correcta del disseny descendent

Diferents persones poden arribar a conclusions diferents sobre com dur a terme la descomposició. Entre totes les solucions diferents possibles, algunes es poden considerar millors que d’altres. De fet, res impedeix, partir d'una solució concreta i aplicar refinaments que la millorin.

Criteris per a l'avaluació de la descomposició:

• Si un problema que sembla a priori força complex es descompon en molts pocs nivells, potser val la pena fer una segona ullada. Inversament, si un problema no massa complex té massa nivells, potser s’ha anat massa lluny en la descomposició.

• Veure si el nombre de passes incloses a cadascun dels subproblemes no és excessivament gran i és fàcil de seguir i entendre. En cas contrari, potser encara faria falta aplicar nous nivells de descomposició.

• Repassar que els noms assignats als subproblemes siguin autoexplicatius i expressin clarament la tasca que estan resolent. Sense ni tan sols llegir les seves passes, caldria entendre perfectament què s’assoleix en resoldre’ls. En cas contrari, potser la descomposició no està agrupant conjunts de passes realment relacionades entre elles.

• Si absolutament cap dels subproblemes és reutilitzat enlloc, especialment en descomposicions en molts nivells, és molt possible que no s’hagi triat correctament la manera de descompondre alguns subproblemes.

• Vinculat al punt anterior, l’aparició de subproblemes molt semblants o idèntics, però tractats per separat en diferents llocs, també sol ser indici que no s’està aplicant la capacitat de reutilitzar subproblemes correctament.

Declaració de mètodes

Un cop descompost el problema general, és el moment de crear el programa que el resol mitjançant codi font. Per això, caldrà decidir, per a cadascun dels subproblemes que s’han detectat, quines instruccions cal executar per resoldre’l individualment. Els llenguatges de programació permeten una implementació directa d’aquest procés, en oferir mecanismes per agrupar o catalogar blocs d’instruccions i etiquetar-los amb un identificador, d’acord al seu subproblema associat. En general dins dels llenguatges de programació, s’anomena una funció a un conjunt d’instruccions amb un objectiu comú que es declaren de manera explícitament diferenciada dins del codi font mitjançant una etiqueta o identificador. Per tant, per cada subproblema a resoldre, dins del vostre codi font s’haurà de definir una funció diferent. En el llenguatge Java, aquests conjunts d’instruccions se’ls anomena mètodes, en lloc de funcions, però a efectes pràctics, els podeu considerar el mateix. Aquest terme no és nou, ja que ha estat usat amb anterioritat sota dos contextos diferents, si bé mai s’havia entrat en molt de detall en la seva descripció ni s’havia justificat el seu format.

• Quan es parla de mètode principal, es tracta d’un conjunt d’instruccions que,

etiquetades sota un identificador anomenat main, resolen el problema general (o sigui, tot el programa). Atès que fins al moment no s’havia aplicat disseny descendent, no hi havia subproblemes, i per tant en el vostre codi font només hi havia definit aquest únic mètode. No en calia cap altre.

• Quan es parla de la invocació d’un mètode sobre valors de certs tipus de dades

complexos, com les cadenes de text (String), es tracta d’executar un conjunt d’instruccions amb un objectiu comú: transformar la cadena de text o obtenir dades contingudes.

La declaració bàsica d’un mètode es fa usant la sintaxi que es mostra tot seguit. Com podeu veure, el seu format és molt semblant a com es declara el mètode principal (però no exactament igual): public void nomMetode() { //Aquí dins aniran les seves instruccions //... } Aquesta declaració es pot dur a terme en qualsevol lloc del fitxer de codi font, sempre que sigui entre les claus que identifiquen l’inici i fi de fitxer (public class NomClasse { ... }) i fora del bloc d’instruccions mètode principal, o qualsevol altre mètode. Normalment, se sol fer immediatament a continuació del mètode principal. Exemple 1: public class LlibreQualificacions { public void mostrarMissatge() { System.out.println( "Benvingut al llibre de qualificacions!" ); } // fi del mètode }