Metodologia

Ara ja sabeu fer programes editant-los en un fitxer de text. Els següents passos us proporcionaran eines que us ajudaran a determinar què cal que faci un programa, i què és necessari que hi hagi en el fitxer del programa (a més a més del codi) perquè sigui correcte.

S’entén que un programa és correcte quan funciona per tots els casos en què està definit. A més a més, per considerar que es compleix el propòsit del programa i que, per tant, és correcte, caldrà incloure en el fitxer on hi ha el codi del programa els casos en els quals es pot utilitzar i la documentació.

Esmentarem diversos passos que haureu de seguir per aconseguir que un programa pugui ser utilitzat per algú que no l’ha fet (i que potser no entén el codi), de manera que el mateix fitxer del programa contingui la documentació necessària per a utilitzar-lo correctament. Observeu aquest programa:

a = int(input())
b = int(input())

a = a + a * 21 / 100
b = b + b * 21 / 100
print(a, b)

A partir d’ara ens referirem a aquest programa com a la versió 1 de l’Alumne Brillant. Tot seguit, fixeu-vos en el següent programa.

# Autor: Alumne Brillant
# IOC
# Versió 1

# Descripció: Càlcul de l'augment de preu de dos productes, després de
# l'increment de l'IVA

# Especificacions d'entrada: 2 nombres enters majors o iguals a zero.

# Joc de proves:
#                Entrada   Sortida 

#	Execució 1      100       121, 14.52
#                  12      

#	Execució 2      305       369.05, 0
#	                  0         

IVA = 21    # IVA actual

# Lectura de dades
preu_inicial_1 = int(input())
preu_inicial_2 = int(input())

# Cálcul dels preus incrementats
preu_final_1 = preu_inicial_1 + preu_inicial_1 * IVA / 100
preu_final_2 = preu_inicial_2 + preu_inicial_2 * IVA / 100

print(preu_final_1, preu_final_2)

Tots dos fan exactament el mateix i per al processador son exactament iguals. Però és evident que si una persona ha d’utilitzar el primer programa, tindrà moltes més dificultats que per a utilitzar el segon. Per això, cal documentar adequadament els programes. Fent-los més entenedors pels programadors i d’una manera que ens ajudi a pensar què han de fer els programes i com.

L’objectiu del primer repte és aconseguir que el fitxer del programa estigui prou documentat perquè un usuari sigui capaç d’utilitzar-lo sense informació addicional. I el que és encara més important: aprendrem definir un joc de proves de manera prèvia a la codificació. Aquest joc de proves us ajudarà a pensar el programa, què ha de fer en cada cas i a verificar-lo una vegada l’hàgim codificat.

En primer lloc, els noms de variables i constants descriptius són l’element més valuós de cara a ajudar els humans a entendre el programa. Allunyeu-vos de noms críptics i abreviats, utilitzeu paraules que indiquin exactament el significat del contingut.

En segon lloc, els programes augmenten la llegibilitat amb l’ús dels comentaris. Un comentari és qualsevol cosa que no volem que l’intèrpret executi i que va dirigit als humans que llegeixin el programa.

En Python, qualsevol cosa que vagi darrere del símbol hash # i fins a final de línia, és transparent per al processador. És a dir, és un comentari que ajuda a la llegibilitat per als humans.

Un comentari és:

# tot el que s'escriu a partir del # fins al //intro// o salt de línia

El tercer recurs que pot ajudar a fer el programa més llegible és l’ús de constants. Per a una persona, és més clarificador veure una constant que es diu IVA, amb valor 21, que descobrir que el nombre 21 que s’utilitza en algunes operacions correspon al valor de l’IVA.

En definir-les al principi de tot, s’aconsegueix facilitar la modificació del programa: si l’IVA dels productes canvia, és molt més fàcil buscar la constant a la primera línia i actualitzar-la. Així fem que el programa sigui més flexible i reutilitzable.

Finalment, recordeu que és més fàcil de llegir el codi quan se segueixen també aquestes normes:

• Afegir espais en blanc al voltant dels operadors binaris. Per exemple, cal escriure a = b + c . És més fàcil d’entendre que la instrucció a=b+c (l’operador d’assignació = i l’operador suma + són dos operadors binaris).
• No deixar espais en blanc al votant dels parèntesis quan es tracta de funcions. Cal escriure print(‘hola’) en comptes de print ( ‘hola’ ) .
• No deixar un espai en blanc abans d’una coma i sí deixar-lo després, tal com s’escriu en català. La instrucció print(‘hola’, ‘adeu’) està ben escrita. En canvi, print(‘hola’,'adeu’) és menys llegible.
• Si una línia és massa llarga (sobrepassa la línia vertical de l’editor), cal obrir un parèntesi i continuar la instrucció en la línia de sota, per evitar haver de fer scroll en llegir el programa.

La capçalera d’un programa és el conjunt de comentaris afegits previs al codi. Sol tenir informació sobre l’autor, la data i documentació per a l’usuari que l’hagi d’utilitzar.

És recomanable crear una plantilla de la capçalera i que cada vegada que feu un programa nou la copieu directament. La plantilla la podeu fer com us sembli millor estèticament, però ha de contenir unes dades mínimes, precedides pels símbols de comentari (ja que no són dades per al processador).

Les dades que sol contenir la capçalera són les següents:

• Què fa el programa: si avui feu els exercicis de programació i els mireu uns dies després, heu de poder entendre i desxifrar què fan els vostres programes. us ajudarà molt escriure una breu descripció, que pot ser el mateix enunciat del programa.
• Autor: si a algú li cau a les mans un fitxer amb un programa, cal que sàpiga qui n’és l’autor. Per això el nom de l’autor normalment s’escriu a la capçalera.
• Data: si llegiu un programa vostre quan ha passat un temps, és possible que us poseu les mans al cap pels errors que vau fer. És una bona pràctica escriure la data en cada programa perquè us pugueu perdonar els errors de principiant quan sigueu programadors experts.
• Especificacions d’entrada i funcionament: Un usuari a qui li arribi un programa ha de tenir informació suficient per a utilitzar-lo: ha de saber per a què serveix i com utilitzar-lo. En concret, cal documentar les dades d’entrada. Això són les especificacions d’entrada.
• Versió: quan es fa per primera vegada un programa es crea la primera versió d’aquest. A mesura que es va millorant, es creen noves versions. És bona idea apuntar la versió perquè podeu anar modificant el programa a poc a poc, mentre aneu aprenent.

Aquí teniu un exemple de plantilla:

# Administració de Sistemes informàtics
# IOC
# 
# Autor: 
# Data: 
#
# Versió: 
#
# Descripció: 
# Especificacions d'entrada:

Les especificacions d’entrada han d’indicar a l’usuari les dades d’entrada per les quals el programa està preparat. Han d’especificar la quantitat d’entrades que ha de rebre el programa, el tipus de cada entrada i si hi ha alguna restricció.

Al següent exemple veureu la utilitat de les especificacions d’entrada.

videoioc@debian-xtec:~/Documents/programacio/python3 preus_iva.py
1.5
Traceback (most recent call last):
  File "/home/videoioc/Documents/programacio/preus_iva.py", line 23, in <module>
    preu_inicial_1 = int(input())
ValueError: invalid literal for int() with base 10: '1.5'

# Especificacions d'entrada: 2 nombres enters majors o iguals a zero.

Un programa és robust quan no té errors siguin quines siguin les seves dades d’entrada. De moment no fareu programes robustos. Però cal que especifiqueu de manera rigorosa en el fitxer del programa quines són les dades d’entrada: la quantitat, el tipus i les restriccions que hi puguin haver. L’usuari que utilitzi el vostre programa es compromet a seguir aquestes especificacions al peu de la lletra. Vosaltres, com a programadors, heu d’assegurar que el programa funciona si se segueixen aquestes especificacions.

Una execució d’un programa és el resultat que s’obté a partir d’unes dades d’entrada concretes. És a dir, consta de les dades d’entrada en un cas específic i el resultat obtingut després de processar-les.

En el programa càlcul de l’augment de preu de dos productes, després de l’increment de l’IVA, una execució seria la següent:

Si les dades d'entrada són 100 i 10, el resultat serà 121 i 12.1.

Un joc de proves consta de diverses execucions d’exemple, que serveixen per a verificar que un programa funciona. Es presenta amb una taula, on per cada execució s’inclouen les dades d’entrada i el resultat final (o dades de sortida) produït per l’entrada corresponent.

És molt important que abans de codificar un programa definiu per a quin tipus de dades voleu fer-lo (les especificacions d’entrada) i que escriviu alguns exemples d’execució. És a dir, que calculeu quines dades de sortida corresponen a unes dades concretes d’entrada. Aquests exemples els heu de calcular a mà (o amb l’intèrpret interactiu) quan comenceu a entendre el programa i pensar l’algorisme que aplicareu.

Un joc de proves ha d’abastar totes les possibilitats de camins diferents que es poden donar dins d’un programa, així com els casos especials o que poden ser problemàtics. Fer un bon joc de proves és la part més difícil i més creativa que ha d’afrontar el programador. Si el joc de proves no és suficient i us heu oblidat d’algun cas, no el tindreu en compte ni en el moment de codificar el programa ni en verificar-lo. És molt possible que el programa no funcioni (si falla un cas, el programa no és correcte) i no us n’haureu adonat.

Hi ha un punt d’art i un punt d’intuïció a l’hora de crear un joc de proves, però heu d’aprendre a ser molt rigorosos i a desenvolupar la capacitat de preveure totes les opcions i casos que es poden donar. En un joc de proves hi ha d’haver com a mínim un cas de cada una de les opcions que es poden produir al llarg del programa. També els casos límit, els que poden presentar ambigüitats i els problemàtics.

# Especificacions d'entrada: 2 nombres float majors o iguals a zero.

>>> IVA = 21
>>> preu = 100
>>> preu_final = preu * IVA / 100 + preu
>>> preu_final
121.0
>>> preu = 12
>>> preu_final = preu * IVA / 100 + preu
>>> preu_final
14.52
>>> 

>>> 100 + 100 * 21 / 100
121.0
>>> 12 + 12 * 21 / 100
14.52

En el fitxer de qualsevol programa que presenteu, és imprescindible que hi hagi les especificacions d’entrada. Un programa ben documentat hauria d’incloure també el joc de proves, però s’acceptarà que estigui documentat a part. Partint del mateix enunciat, us podríeu trobar amb unes especificacions diferents segons les decisions que preneu. A continuació ho veureu amb un exemple.

El joc de proves s’ha d’escriure abans de codificar el programa, però cal que comprovem que funciona una vegada hem acabat de codificar-lo. Si per a cada execució del joc de proves obtenim les dades de sortida previstes per les dades d’entrada, considerarem que el programa funciona. En cas que hi hagi un error no detectat en el joc de proves tampoc el detectarem en l’etapa de verificació. En cas contrari, haurem de procedir a buscar l’error i tornar al procés de codificació.

En el següent exemple veureu com es fa servir el joc de proves per verificar el programa.

videoioc@debian-xtec:~/Documents/programacio$ python3 preus_iva.py 
100
12
121.0 14.52
videoioc@debian-xtec:~/Documents/programacio$ python3 preus_iva.py 
305
0
369.05 0.0

Fixeu-vos en la importància del joc de proves: si us oblideu d’un cas quan el planifiqueu, tampoc el verificareu en acabar i és possible que el programa no funcioni.

En moltes ocasions ens trobarem que necessitem saber quin valor van prenent les variables a mesura que el programa avança, també quins són els resultats d’executar cadascuna de les instruccions. Això és el que queda registrat en el seguiment del programa. Per fer el seguiment (o “seguir” el que fa el programa) s’observa o traça quins valors van prenent les variables per a uns valors d’entrada concrets i es ressegueix línia a línia què fa el processador. Tota aquesta informació es registra en una taula.

En la primera columna hi ha d’haver el nombre de la línia per la qual passa el flux del programa. A les altres columnes hi posareu el nom de cada variable que es va utilitzant i el valor que pren en la instrucció corresponent. Només cal indicar el nou valor de la variable en el moment en què canvia, de manera que per saber quant val en cada línia només cal que buscar l’últim valor escrit en la columna. En l’última columna posarem els valors que ens mostra el programa (és a dir, la sortida). Les línies en blanc les podem obviar.

# Autor: Alumne Brillant
# IOC

# Descripció: Calcul de l'augment de preu de dos productes, desprès de
# l'increment de l'IVA

# versió 2

# Especificacions d'entrada: 2 nombres float majors o iguals a zero.

# Joc de proves:
#               Entrada         Sortida

# Execució 1        100         121, 14.52
#                   12

# Execució 2        10.5        12.705, 0
#                   0

IVA = 21    #IVA actual

# Lectura de dades
preu_inicial_1 = int(input())
preu_inicial_2 = int(input())

#Cálcul dels preus incrementats
preu_final_1 = preu_inicial_1 + preu_inicial_1 * IVA / 100
preu_final_2 = preu_inicial_2 + preu_inicial_2 * IVA / 100

print(preu_final_1, preu_final_2)

Us heu de fixar en el següent:

• S’escriu el número de la línia de codi i el valor de la variable que es modifica en aquella instrucció.
• En la línia 20 es fa una assignació a una constant entera.
• En les línies 23 i 24 es llegeixen les dades. La funció input() fa la lectura del teclat, però abans de fer l’assignació es converteixen a float. Per això els valors de les variable preu_inicial_1 i preu_inicial_2 es desen com a 100.0 i 12.0 respectivament.
• En la línia 30 s’escriu la sortida tal com ho faria la funció print()

Heu vist que parar atenció a alguns aspectes és fonamental per crear programes correctes i que facin el que volem. Tenir compte la llegibilitat, definir unes bones especificacions d’entrada, quin serà el joc de proves i com fer el seguiment són estratègies o tècniques que haureu d’assajar des dels primers programes que feu. Tot seguit repassarem els aspectes més importants.

La llegibilitat no afecta el programa en si ni al processador. Però és un element clau a l’hora de valorar-lo. S’aconsegueix amb:

• Noms descriptius de les constants i variables.
• Comentaris explicant què fan les instruccions (mai traduint-les).
• Una capçalera amb dades de l’autor i com a mínim, una descripció de per què serveix el programa i les dades d’entrada que espera rebre.
• Espais en blanc al voltant dels operadors binaris.
• Escriure els parèntesis de les funcions sense espais en blanc.
• No deixar un espai en blanc abans d’una coma, deixar-lo després.
• No fer línies massa llargues, utilitzant parèntesis per repartir-les en dues o més.

Les especificacions d’entrada són les dades que el programa espera rebre. Han d’estar sempre indicades en el fitxer del programa (a la capçalera) perquè l’usuari sàpiga com utilitzar-lo. Han d’indicar:

• La quantitat d’entrades que espera rebre el programa.
• El tipus de cadascuna de les dades.
• Si aquestes dades tenen algun tipus de restricció.

El control d’errors d’un programa és el mecanisme per evitar l’entrada de dades per a les quals el programa no està preparat i que el podrien interrompre a causa d’un error. De moment, el control d’errors el fa qui introdueix les dades (és a dir, l’usuari). Per això és imprescindible que les especificacions d’entrada siguin clares i estiguin en el fitxer del programa per poder-les consultar.

Per a fer un programa robust (a prova d’usuaris ineptes o amb molt mala idea), caldria afegir un control d’errors previ al programa per descartar les dades dolentes. De moment només escriurem les especificacions d’entrada.

Un joc de proves ha d’acomplir les següents característiques:

• Ha d’abastar tots els casos i tots els camins que es poden donar amb les dades d’entrada. Hi ha d’haver com a mínim una execució per a cadascuna de les possibilitats.
• Ha de resoldre i clarificar totes les ambigüitats que pugui tenir l’enunciat.
• Han de constar els casos límit i els casos problemàtics.
• Tot i que no hi pot faltar cap cas necessari, tampoc ha de ser massa extens.

S’expressa mitjançant una taula amb unes columnes corresponents a les dades d’entrada i unes altres amb les dades de sortida. Cada filera representa una execució diferent. El joc de proves i les especificacions d’entrada han de concordar i ser coherents.

Un programa que no acompleixi el seu joc de proves és un programa que està malament. Si en codificar un programa no aconseguiu que s’acompleixi el joc de proves (que significa en tots els casos), cal que afegiu un comentari a la capçalera i ho expliqueu.

Es fa utilitzant una taula on la primera columna és el nombre de la línia per la qual passa el flux del programa, i l’última la sortida o el que mostra per pantalla. Les columnes intermèdies ens indiquen els valors que van prenent les diferents variables. Cada filera representa una instrucció, identificada pel nombre de la línia del codi. S’ha d’escriure el nombre de línia en el mateix ordre que el flux del programa (quan el processador executa la línia).

De moment esteu programant programes seqüencials, que significa que les línies s’executen en la mateixa seqüència que estan escrites en el codi. Per aquesta raó us pot semblar que el número de la línia en un seguiment també sempre serà seqüencial. Quan utilitzeu estructures de control ja us adonareu que no és així.

Abans de començar a programar és imprescindible entendre el problema, resoldre uns quants casos concrets (els que calguin) fins a poder descriure els passos ordenats que s’han de seguir per a resoldre’l, és a dir, fins a crear l’algorisme.

Després, és el moment de traslladar l’algorisme a l’editor que és el que anomenem refinament, i que no són instruccions de codi. Més tard es comença a traduir l’algorisme a llenguatge entenedor per al processador, és a dir, a codificar el programa.

Una vegada s’ha acabat el procés de codificació, l’objectiu següent serà aconseguir que el programa s’executi (corregir els errors de sintaxi i altres no acceptats pel processador). Finalment, verificar que el programa fa el que ha de fer i que funciona en tots els casos.

Si no ho aconseguiu, s’inicia un procés que pot ser molt laboriós i pesat i que consisteix a perseguir el problema fins a identificar-lo, aïllar-lo i corregir-lo. Per tant, millor fer les coses bé des de bon començament i així evitar, o minimitzar, les complicacions posteriors.

L’objectiu del proper repte és posar en pràctica el mètode que us ajudarà en el moment de fer un programa. El programa que s’utilitzarà com a exemple per mostrar tots els passos serà la resolució de les equacions de segon grau. No és un curs de matemàtiques i no cal que sapigueu resoldre equacions de segon grau; només heu de saber que un analista us ha donat una fórmula que s’ha d’aplicar en un programa. En el món de la informàtica de vegades haureu de fer programes que facin càlculs de temes desconeguts per a vosaltres. Només necessitareu un algorisme o la fórmula que us proporcionin.

Us han encarregat un programa que llegeixi tres nombres float corresponents als coeficients d’una equació de segon grau. L’equació de segon grau és . Els coeficients seran els valors de a, b i c.

El programa ha de trobar les possibles solucions d’aquesta equació. Les solucions són els valors de x pels quals es compleix la fórmula. Pot ser que tingui dues solucions, que només en tingui una, o bé que en tingui cap. Per trobar les solucions (si existeixen), cal aplicar les següents fórmules:

Per a fer el programa, considereu que fer una arrel quadrada és equivalent a elevar el que tenim dins l’arrel a 1/2. Veureu a continuació com fer-ho pas a pas.

Com sempre han insistit els vostres professors de matemàtiques, el més important és llegir i entendre bé l’enunciat. L’enunciat d’un programa pot tenir poques o moltes línies. Convé fer una primera lectura completa per començar.

Heu de fixar-vos en l’expressió matemàtica que representa les solucions, examinar-la i traduir-la del llenguatge matemàtic al Python. L’intèrpret interactiu és l’instrument que us ha d’ajudar en aquests primers passos. La traducció de les solucions és:

sol1 = (-b + (b **2 - 4 * a * c) ** (1 / 2))/ (2 * a)
sol2 = (-b - (b **2 - 4 * a * c) ** (1 / 2))/ (2 * a)

>>> 30 / 2 * 5
75.0
>>> 30 / (2 * 5)
3.0

Si no sabeu resoldre un problema a mà, no li sabreu explicar a l’ordinador com fer-ho. “A mà” vol dir fent vosaltres les passes per solucionar-ho, això sí, amb una eina que us ajudi a fer els càlculs. I no hi ha eina millor que l’intèrpret interactiu. El primer pas, absolutament imprescindible, és resoldre un o diversos exemples vosaltres mateixos, fins que us quedi clar el procediment a seguir i n’obtingueu l’algorisme. Per molt que us costi o per molt temps que hi dediqueu mai serà temps perdut.

Per començar cal resoldre exemples concrets. Doneu els valors que vulgueu als coeficients a, b i c, i amb l’ajuda de l’intèrpret interactiu, aneu estudiant què passa. Un exemple amb qualssevol valors float podria ser aquest:

>>> a = 2
>>> b = 3
>>> c = -1
>>> sol1 = (-b + (b **2 - 4 * a * c) ** (1 / 2))/ (2 * a)
>>> sol1
0.28077640640441515
>>> sol2 = (-b - (b **2 - 4 * a * c) ** (1 / 2))/ (2 * a)
>>> sol2
-1.7807764064044151

Està bé? Sembla que la fórmula aplicada és correcta. Però no podeu saber si està bé si no teniu el resultat correcte amb el que comparar.

Caldria comprovar un cas que en sapigueu el resultat per verificar que aneu pel bon camí.

Un dels casos que podríeu deduir, és que pels valors d’entrada a = 1, b = 0, c = 0 el resultat serà 0.

Les entrades i sortides vàlides les teniu recollides a la taula.

Podem comprovar doncs si les nostres instruccions funcionen correctament revisant si en donar-li aquests valors d’entrada, el resultat és el que esperem, és a dir, 0 .

Comproveu-ho aplicant la fórmula.

>>> a = 1
>>> b = 0
>>> c = 0
>>> sol1 = (-b + (b **2 - 4 * a * c) ** (1 / 2))/ (2 * a)
>>> sol1
0.0
>>> sol2 = (-b - (b **2 - 4 * a * c) ** (1 / 2))/ (2 * a)
>>> sol2
0.0

Les dues solucions donen el mateix, el valor 0, per tant, és correcte. A més, com que les dues solucions són la mateixa, en realitat és una solució. Acabeu de trobar un cas que té una única solució.

Un altre cas que podríeu deduir, és que pels valors d’entrada a = 1, b = 0, c = -4 els resultats seran 2 i -2. Les entrades i sortides vàlides les teniu recollides a la taula.

És un dels casos en què existeixen dues solucions. Comproveu-ho amb l’intèrpret interactiu:

>>> a = 1
>>> b = 0
>>> c = -4
>>> sol1 = (-b + (b **2 - 4 * a * c) ** (1 / 2))/ (2 * a)
>>> sol2 = (-b - (b **2 - 4 * a * c) ** (1 / 2))/ (2 * a)
>>> sol1
2.0
>>> sol2
-2.0

Els resultats són els que hem calculat prèviament. Així en aquest cas també comprovem que les nostres instruccions són correctes. Un altre conjunt de valors vàlids serien els de les entrades a = 2, b = 0, c = -8 amb resultats 2 i -2. Aquestes entrades i sortides vàlides les teniu recollides a lataula.

Finalment, tindrem les entrades a = 1, b = 0, c = 4 per les quals, la equació no té solució. El joc de proves el teniu recollit a la taula.

Si ho proveu amb el codi que teniem fins ara, us haurà sortit una cosa estranya semblant a la següent:

>>> a = 1
>>> b = 0
>>> c = 4
>>> sol1 = (-b + (b **2 - 4 * a * c) ** (1 / 2))/ (2 * a)
>>> sol2 = (-b - (b **2 - 4 * a * c) ** (1 / 2))/ (2 * a)
>>> sol1
(1.2246467991473532e-16+2j)
>>> sol2
(-1.2246467991473532e-16-2j)

No és un curs de matemàtiques i no és necessari que entengueu què ha passat. L’explicació és que s’ha fet una arrel quadrada “extesa” d’un nombre negatiu i ens han aparegut els nombres complexos o imaginaris, un grup de nombres molt més grans que els reals. Les arrels quadrades no tenen solució en el camp dels nombres reals, però sí en un conjunt més extens que és el dels nombres complexos.

>>> a = 2
>>> b = 0
>>> c = -8
>>> sol1 = (-b + (b **2 - 4 * a * c) ** (1 / 2))/ (2 * a)
>>> sol2 = (-b - (b **2 - 4 * a * c) ** (1 / 2))/ (2 * a)
>>> sol1
2.0
>>> sol2
-2.0

Heu intentat resoldre l’equació amb coeficients (a = 1, b = 0, c = 4), i l’equació seria, per aquests valors .

Si aïlleu la x, obteniu , és a dir, que la solució que busqueu és un nombre que multiplicat per si mateix doni -4. Per les lleis de la multiplicació, en els nombres reals no existeix cap nombre amb aquestes característiques (recordeu que menys per menys dona un resultat positiu).

Si haguéssiu utilitzat la funció predeterminada per a fer l’arrel quadrada, el processador hauria enviat un error, ja que la funció està preparada només per buscar valors reals. En canvi, elevar a 1/2 un nombre negatiu és una operació matemàticament permesa en un conjunt més gran que el dels nombres reals, que són els nombres complexos.

Això és perquè el codi que teniem fins ara no calculava correctament aquest cas. Per fer el càlcul correctament cal utilitzar la funció sqrt() del mòdul math. Aquesta funció calcula l’arrel quadrada. Per utilitzar la funció sqrt()cal primer incloure el mòdul math al codi.

import math

Després d’incloure el mòdul math amb el import s’ha d’escriure el seu nom precedit la paraula math amb un punt al davant. Per exemple: math.sqrt(). L’ import s’ha d’escriure al principi del codi del fitxer (just després de la capçalera). D’entrada, comproveu que l’arrel de 4 amb la funció math.sqrt() és dos (ens proporciona l’arrel positiva).

>>> import math
>>> math.sqrt(4)  #per comprovar que fa l'arrel quadrada
2.0

Ara comproveu l’exemple anterior amb l’intèrpret interactiu.

>>> import math
>>> a = 1
>>> b = 0
>>> c = 4
>>> sol1 = (-b + math.sqrt((b **2 - 4 * a * c)) / (2 * a))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error

Per què s’obté aquest error? perquè la part de l’expressió que va dins de l’arrel, que es diu discriminant, és negatiu. En la fórmula de l’equació seria:

Si calculeu discriminant amb l’intèrpret interactiu obtindreu el següent valor:

>>> b ** 2 - 4 * a * c
-16

Però, en els nombres reals l’arrel de -16 no té solució, és una operació prohibida. I la funció sqrt() no la pot fer. Per això us apareix l’error.

Fins aquí, aquest estudi us ha ajudat a pensar el programa. Si reviseu, veureu que heu comprovat que segons el valor del discriminant (és a dir, el contingut de l’arrel quadrada) passen tres coses diferents. En l’exploració prèvia a la programació heu trobat que es poden donar tres casos diferents:

• Un exemple en el qual hi ha dues solucions (). Si calculeu el discriminant (el que hi ha dins de l’arrel), veureu que és un nombre positiu:

   >>> b ** 2 - 4 * a * c
  16

• Un cas amb una solució (). El discriminant val zero:

   >>> -b ** 2 - 4 * a * c
  0

• Per últim, un cas que no té solució (). El discriminat en aquests casos serà negatiu:

   >>> -b ** 2 - 4 * a * c
  -16

Si necessiteu fer més exemples, podeu fer tots els que us semblin necessaris. Les bases per a resoldre i codificar el programa ja estan assentades.

Per evitar caure en la temptació i manipular el programa per a adaptar-lo al que ens vagi bé, és necessari tenir molt clar l’objectiu abans de començar a programar. Com que heu fet alguns exemples ja coneixeu el procediment que s’ha de seguir o, en altres paraules, l’algorisme que heu d’aplicar. És el moment de pensar en les especificacions d’entrada: definir per a quin tipus de dades i per a quin rang funcionarà el programa. Al mateix temps cal pensar una bateria de proves que permetin assegurar que el programa funciona en tots els casos que accepta (el joc de proves).

Ha de quedar molt clar en aquesta etapa que de moment no es fa control d’errors. El control d’errors és un pas posterior a l’elaboració del programa en si. Té una importància secundària i el tractarem més endavant.

En canvi, ara és el moment de fer el joc de proves i és el pas més important en l’elaboració d’un programa; si no sou rigorosos i us oblideu un cas particular, quan el programa estigui fet tampoc el detectareu.

En resoldre una equació de segon grau, hi ha tres possibles casos:

• Que hi hagi dues solucions.
• Que n’hi hagi una.
• Que no n’hi hagi cap.

En el joc de proves ha d’haver-hi, com a mínim, un exemple amb una execució corresponent a cadascun d’aquests casos. També cal detectar operacions amb les quals el processador pugui tenir problemes. Algunes de les situacions que causen problemes en fórmules matemàtiques són:

• Fer una arrel d’un negatiu és un problema. Aquest cas ja l’hem estudiat i evitarem fer l’arrel quan el discriminant és negatiu.
• Calcular el valor d’una fracció quan el denominador és zero.

En la fórmula que hem d’aplicar el denominador val 2*a . Si la a val zero, dividirem per zero i el processador produirà un error:

>>> 1 / 0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero

Teniu dues opcions per evitar que es produeixi:

• Prohibir que el valor que ho causa entri al programa mitjançant les especificacions d’entrada.
• Deixar que es pugui introduir la dada però interceptar-la abans d’aplicar la fórmula.

És en el joc de proves quan s’han de prendre aquest tipus de decisions, i totes dues són vàlides. Si escolliu la primera cal que a les especificacions d’entrada es prohibeixi el valor en qüestió. Si opteu per la segona, esteu obligats a posar el valor en el joc de proves, ja que és un cas problemàtic.

En aquest cas el programador es decanta per la primera opció i no accepta que el valor de la a valgui zero, que és el culpable de l’error de dividir per zero. Amb les consideracions prèvies es determinen les especificacions d’entrada i el joc de proves:

Especificacions d’entrada: tres nombres float a, b i c, amb la a diferent de zero. El joc de proves queda recollit a la taula.

Les dues últimes execucions s’han afegit per indicar que les dades són de tipus float i incorporar un exemple que no sigui tan senzill.

És imprescindible identificar l’algorisme per a poder reproduir-lo en el codi. Codificar és traduir a la màquina el que hem fet a mà. Deixareu els passos (que no és el mateix que les instruccions) escrits en el fitxer en forma de comentari abans de començar a escriure codi. Recapitulem els passos que hem seguit:

1. Llegir els coeficients
2. Calcular el discriminant
3. Segons el valor del discriminant, fer accions diferents:
   • Si és negatiu no podem fer l’arrel quadrada i no hi ha solució.
   • Si val zero hi ha una única solució i la sabem trobar.
   • Si és positiu hi ha dues solucions, i també les sabem trobar.

Ara ja podeu escriure el refinament a l’editor de text, en el fitxer on finalment el programa acabarà codificat. Cada pas el deixareu escrit com a comentari i posteriorment, quan codifiqueu cada instrucció, ho fareu sota el comentari. D’aquesta manera, qui llegeixi el programa es podrà fer molt fàcilment una idea de què fa.

# CAPÇALERA COMPLERTA
#
# Versió: 1
#
# Descripció:  Programa per a resoldre una equació de segon grau
# ax2 + bx + c = 0
#
# Especificacions d'entrada: 3 nombres float. La a diferent de 0.


# Lectura de dades


# Càlcul del disciminant

# Si és negatiu
  # No hi ha solucions
  # Mostrar que no hi ha solució
  
# Si és zero
  # Càlcul de la solució
  # Mostrar la solució
  
# Si és positiu
  # Càlcul de les dues solucions
  # Mostrar els valors

De moment en el fitxer del programa no hi ha ni una línia de codi.

El primer refinament és explicar què volem fer a grans trets. És possible que algun dels passos necessiti tornar a descriure amb més deteniment una part el procés. Podem refinar tantes vegades com sigui necessari fins a arribar al nivell en què ens resultin evidents les instruccions que hem de donar.

En aquests primers programes el concepte de refinament i refinaments successius és difícil de mostrar, ja que els programes són senzills, però a mesura que feu més programes ho anireu aprenent. Fixeu-vos que els passos de l’1 al 5 (és a dir, tot el que heu fet fins ara) s’ha de fer abans de codificar.

Una vegada ja teniu el fitxer amb tots els passos del refinament escrits, traduireu cadascun d’ells a codi. És important anar comprovant que el codi introduït és correcte i funciona per trossos. És molt més fàcil detectar errors cada poques línies que escriure tot un programa i executar-lo de cop quan heu acabat.

Per a codificar l’exemple us falta aprendre a fer estructures alternatives (els “si és…”). Encara no teniu les eines per a codificar aquest programa.

Quan ja heu teclejat tot el codi cal fer les proves per determinar que el programa funciona: primer cal que el codi s’executi i després cal comprovar que fa el que voleu que faci.

El primer pas és relativament senzill. Només cal que us fixeu en els missatges d’error que dona el processador. Com que el llenguatge Python és interpretat, el programa s’executarà fins a la línia en què el processador no sigui capaç d’entendre el codi escrit. Els missatges són bastant clars i amb una mica d’experiència sabreu resoldre els problemes.

Una vegada el programa s’executa solen aparèixer les veritables dificultats. Molt poques vegades el programa fa el que realment volem a la primera, i hem de perseguir i identificar els errors fins a depurar-los tots i fer que funcioni en tots els casos. Si el joc de proves està ben fet, podem assegurar que si el programa mostra la sortida esperada per a cada cas del joc de proves, és que el programa funciona per tots els casos.

Evidentment, el programa funcionarà només en cas que el joc de proves sigui suficient i sobretot, que no ens hàgim oblidat cap cas. El moment més important en l’elaboració d’un programa és la creació del joc de proves.

Si executeu el programa i els resultats no són els esperats vol dir que hi ha algun error, o dit d’una altra manera, en alguna instrucció el processador no fa el que esperàvem. Heu indicat malament al processador el que volíeu que fes.

Cal que debugueu el programa. Hi ha aplicacions i eines que us poden ajudar, però en el fons debugar és fer un seguiment fins a detectar quina variable i en quin moment ha pres un valor que no és l’esperat.

Depurar o debugar el programa es pot fer mostrant, amb print() els valors de les variables a mesura que el programa es va executant, amb l’objectiu de traçar o seguir els valors que van prenent. Això permet fer un seguiment en els fragments que no es comporten com voldríem.

Ara que ja sabeu fer programes, és el moment d’enumerar les característiques que seria desitjable que tinguessin els vostres. Estan enumerades de major a menor importància des del punt de vista que es considera oportú per a la seva valoració quan es comença a programar.

En termes de nota, un programa que no funcioni estarà suspès (tindrà una nota entre 0 i menys de 5). Si funciona, les característiques que determinaran la puntuació entre 5 i 10 punts seran les següents:

• Que funcioni. Si un programa no funciona en tots els casos per què està definit (en les especificacions d’entrada), no funciona.
• Que sigui llegible. Us heu d’esforçar a incrementar al màxim la llegibilitat dels programes a les variables donant noms descriptius, posant comentaris i definint una estructura clara. No es tracta de posar comentaris després d’haver fet el programa sinó abans, amb el refinament: un comentari no ha de descriure la instrucció sinó indicar l’objectiu del codi que es desenvolupa a sota.
• Que sigui flexible i reutilitzable. Si definiu constants n’afavoriu i en simplifiqueu un nou ús. No caldrà repassar totes les línies per a modificar un valor, sinó només canviant la constant ja n’hi ha prou.
• Que sigui eficient. No heu de pensar en l’eficiència en el moment de dissenyar un programa, tot i que sí que hi farem referència en alguns casos. Una cosa és no dissenyar un programa prioritzant l’eficiència per davant de tot i una altra no tenir-la en compte. En aquest curs de programació el que es valora és la traducció de l’algorisme que feu a mà encara que no sigui el més eficient.
• Que sigui robust. Un programa és robust quan per molt inepte que sigui l’usuari (o per molt mala idea que tingui) no és capaç d’introduir-hi dades que provoquin errors. De moment aquest concepte es limitarà a la definició de les especificacions d’entrada. Més endavant i mitjançant el control d’errors, fareu programes robustos que detinguin l’execució si les dades no són les esperades.

Per a obtenir un bon programa, hem vist que és molt important seguir una metodologia que ens asseguri que hem tingut en compte tots els aspectes. Si us acostumeu a fer-ho des de bon començament, aquesta metodologia la incorporareu com a part essencial del programa. És important per això, fer-la servir des del principi.

Passos per a fer un programa

Aquestes són les etapes i l’ordre en què s’han de seguir per a aconseguir un bon programa:

1. Entendre l’enunciat.
2. Fer un o diversos exemples a mà.
3. Fer el joc de proves i les especificacions d’entrada.
4. Fer el primer refinament.
5. Fer els refinaments successius.
6. Codificar.
7. Executar i comprovar el joc de proves.
8. Fer el seguiment dels fragments que siguin necessaris per identificar i resoldre errors.

Característiques desitjables dels programes

Un programa funciona si és capaç de resoldre el problema plantejat en tots els casos pels quals està definit en les especificacions d’entrada. Però un programa que funciona té altres característiques que el milloren, i també milloren la nota quan s’avalua. Aquest és un llistat de característiques que milloren la qualitat d’un programa:

• Que sigui llegible
• Que sigui fàcilment modificable i reutilitzable
• Que sigui eficient
• Que sigui robust