Disseny estructurat daplicacions
-
Upload
susannafabla -
Category
Education
-
view
297 -
download
0
Transcript of Disseny estructurat daplicacions
Disseny estructurat d’aplicacionsInmaculada Salas Díaz
Anàlisi i disseny d’aplicacions informàtiques
Anàlisi i disseny d’aplicacions informàtiques Disseny estructurat d’aplicacions
Índex
Introducció ............................................................................................... 5
Objectius ................................................................................................... 6
1. Disseny d’aplicacions ......................................................................... 9
1.1. Principis del disseny estructurat ............................................... 9
1.2. Diagrames d’estructures (diagrama d’estructures
de quadres de Constantine) ....................................................... 10
1.2.1. Mòduls ............................................................................... 11
1.2.2. Representació de paràmetres ......................................... 16
1.3. Estratègies de disseny ................................................................ 16
1.3.1. Anàlisi de transformació .................................................. 17
1.3.2. Anàlisi de transacció ........................................................ 20
1.4. Atributs de la qualitat d’un disseny ........................................... 23
1.4.1. Acoblament entre mòduls ............................................... 24
1.4.2. Cohesió (consistència) ..................................................... 25
1.5. Exemple complet de creació de diagrama d’estructures ........ 28
2. Disseny d’interfícies d’usuari ........................................................... 29
2.1. Importància de la interfície d’usuari ........................................ 29
2.2. Models de disseny d’interfície ................................................... 31
2.2.1. Model d’usuari .................................................................. 31
2.2.2. Model de programador ..................................................... 32
2.2.3. Model de dissenyador ...................................................... 32
2.3. Regles per al disseny d’interfícies d’usuari .............................. 33
2.3.1. Interacció general ............................................................. 33
2.3.2. Visualització de la informació ......................................... 37
2.3.3. Entrada de dades .............................................................. 39
2.4. Ajuda a l’usuari ............................................................................ 40
2.5. Guies de disseny o guies d’estils ................................................ 41
2.6. El procés de desenvolupament d’interfícies ............................ 42
2.7. Evolució de les interfícies .......................................................... 45
2.7.1. Interfície de línia d’ordres ............................................... 45
2.7.2. Interfície de menús .......................................................... 46
2.7.3. Interfície gràfica .............................................................. 48
2.8. El futur de les interfícies ........................................................... 51
3. Prova i documentació ......................................................................... 53
3.1. Tipus de proves ............................................................................ 57
3.1.1. Les proves de caixa blanca ............................................... 58
3.1.2. Les proves de caixa negra ................................................ 64
Anàlisi i disseny d’aplicacions informàtiques Disseny estructurat d’aplicacions
3.1.3. Revisions ............................................................................ 71
3.1.4. Proves d’integració ........................................................... 73
3.1.5. Proves d’acceptació .......................................................... 76
3.2. Documentació .............................................................................. 76
Anàlisi i disseny d’aplicacions informàtiques 5 Disseny estructurat d’aplicacions
Introducció
L’objectiu del disseny d’aplicacions és decidir com s’ha de resoldre cadas-
cun dels subprogrames identificats per a l’anàlisi i com s’han d’integrar totes
les solucions dissenyades en una solució global. Un requisit indispensable
per poder estudiar el disseny estructurat d’aplicacions és tenir destresa en
l’etapa de l’anàlisi estructurada.
Una vegada feta l’anàlisi és molt important obtenir un diagrama d’estruc-
tures en el qual es representin tots els mòduls de feina de l’equip de des-
envolupament fins a aconseguir la codificació completa de tota l’aplicació.
ANÀLISI DISSENY
Amb el diagrama d’estructura obtingut es pot repartir la feina entre els en-
carregats de desenvolupar l’aplicació, alhora que es pot controlar més fà-
cilment la qualitat del programari desenvolupat, per posteriorment
passar-lo a la fase de prova.
El crèdit Anàlisi i disseny d’aplicacions informàtiques està articulat entorn
de les fases de desenvolupament d’una aplicació informàtica. En concret, la
unitat “Disseny d’aplicacions estructurat”, que tracta de la manera en què
es dissenyen les aplicacions i les seves interfícies a partir de la seva anàli-
si, s’ha de fer de manera obligatòria després d’estudiar amb profunditat la
fase d’anàlisi. Una vegada s’ha dissenyat i construït el sistema, s’haurà de
sotmetre a la fase de prova per poder arribar a una aplicació informàtica
de qualitat.
En el nucli d’activitat “Disseny d’aplicacions” veurem com es desenvolupa
l’estructura del programa, i també la relació entre elements, que compo-
nen aquesta estructura. El disseny ens permetrà establir la transició del
diagrama de flux de dades a una descripció de l’estructura de programa.
En el nucli d’activitat “Disseny d’interfícies” veurem que les interfícies
d’una aplicació de programari la constitueixen les dades d’entrada i de sor-
tida que aquest intercanvia amb la resta del sistema. El disseny d’interfí-
cies és un aspecte crucial a l’hora d’integrar les diferents unitats que
formaran part de la solució final del problema.
En el nucli “Prova i documentació” veurem que aquesta fase serveix per
garantir el funcionament correcte de l’aplicació, i també la seva adequació
als requisits i necessitats expressats pels clients, i per documentar tot el
desenvolupament de l’aplicació perquè, malgrat ser una tasca que pot
semblar tediosa, és una de les claus del bon funcionament d’una aplicació
i imprescindible per a modificacions futures.
Es diu que l’anàlisi és l’etapa més important i que el disseny és l’etapa difícil.
Anàlisi i disseny d’aplicacions informàtiques 6 Disseny estructurat d’aplicacions
Objectius
En acabar la unitat, heu de ser capaços del següent:
1. Identificar els recursos del sistema i la informació que se n’ha d’ob-
tenir, amb les seves fonts, destinacions i els processos que cal fer-hi.
2. Analitzar les especificacions que provenen de l’anàlisi prèvia i els dia-
grames de blocs, els organigrames i la documentació provinent de
l’anàlisi funcional.
3. Descompondre una aplicació informàtica en unitats modulars segons
la metodologia establerta i a partir de les especificacions rebudes.
4. Dissenyar els esquemes de diàleg, d’entrades i de sortides per mitjà
de diagrames d’estat-succés.
5. Determinar i descriure les interfícies d’introducció de dades, els for-
mats de sortida d’informació i els esquemes de diàleg lògic utilitzats
per a cada alternativa, segons la metodologia de disseny proposada.
6. Identificar els orígens i les destinacions dels fluxos d’informació, les
condicions d’entrada, de sortida, d’error i el seu tractament, i els
processos que s’han de fer sobre les dades.
7. Definir els nivells i les polítiques de seguretat en l’ús de les aplica-
cions informàtiques.
8. Determinar i descriure les interfícies de presa de dades, els formats
de sortida d’informació i els esquemes de diàleg lògic utilitzats per
a cada alternativa, segons la metodologia de disseny proposada.
9. Identificar els orígens i les destinacions dels fluxos d’informació, les
condicions d’entrada, de sortida i el seu tractament, i els processos
que s’han de fer sobre les dades.
10. Definir la seqüència i les condicions d’execució d’un pla de proves
d’una aplicació informàtica, i també els resultats esperats de les
proves de mòduls i de les proves d’integració.
11. Verificar el pla de proves: que l’accés, la utilització i l’elaboració de
les dades, la presentació de la informació d’error i el seu tractament
s’ajusten al disseny o a les prescripcions definides per l’usuari.
Anàlisi i disseny d’aplicacions informàtiques 7 Disseny estructurat d’aplicacions
12. Elaborar la documentació d’una manera completa i detallada de les
diferents fases que intervenen en el disseny i en el pla de proves
d’una aplicació informàtica, segons el procediment establert.
Anàlisi i disseny d’aplicacions informàtiques 8 Disseny estructurat d’aplicacions
Anàlisi i disseny d’aplicacions informàtiques 9 Disseny estructurat d’aplicacions
1. Disseny d’aplicacions
El disseny estructurat, o també anomenat disseny orientat al flux de da-
des, permet establir la transició del diagrama de flux de dades (DFD) a una
descripció de l’estructura del programa, que es representa mitjançant un di-
agrama d’estructures. A continuació, veurem aquests diagrames i com obte-
nir-los a partir del DFD expandit (format només per processos primitius).
La funció del disseny és passar del què al com. El disseny ha de complir
els requisits següents:
• Que funcioni.
• Que sigui mantenible.
• Que estigui documentat.
• Que es pugui provar.
1.1. Principis del disseny estructurat
L’anàlisi estructurat que s’ha fet servir per desenvolupar els diagrames de
flux de dades (DFD) es basa en dos conceptes fonamentals: la tècnica de
resolució de problemes divideix i venceràs i top-down o disseny descen-
dent. Per tant, el disseny continua amb els mateixos principis i rep el so-
brenom de disseny estructurat.
Els principis en què es basa el disseny estructurat són:
1) Descomposició
Beneficis de la descomposició:
• Facilita la compressió i la documentació.
• Facilita les modificacions.
• Minimitza la duplicitat del codi.
L’objectiu principal del disseny estructurat és desenvolupar l’es-
tructura del programa, i també les relacions entre els elements
que componen aquesta estructura.
La descomposició, en el disseny estructurat, és la divisió d’una
operació en altres de més elementals i petites.
Podeu veure els DFD en la unitat didàctica “Anàlisi estructurada”.
!!
“Hay dos formas de realizar un diseño: una es hacerlo tan simple que obviamente no haya deficiencias; la otra es hacerlo tan complicado que no haya deficiencias obvias.”
C. A. R. Hoare
Divideix i venceràs
El disseny estructurat consta dels passos següents:
1) Descomposició del problema en subproblemes (problemes més petits).
2) Solució dels subproblemes.
3) Integració de la solució global.
Anàlisi i disseny d’aplicacions informàtiques 10 Disseny estructurat d’aplicacions
2) Jerarquia
Això es deu al fet que un problema es descompon en subproblemes i així
successivament. Per això cada element de dalt (pare) crida els seus subor-
dinats (fills) i aquest, a la vegada, els seus fills.
3) Independència
En el disseny estructurat cada element només coneix la seva funció i les
seves interfícies.
1.2. Diagrames d’estructures (diagrama d’estructures
de quadres de Constantine)
Figura 1. Propietats d’un diagrama d’estructures
Per obtenir el diagrama d’estructures (DE) el disseny estructurat s’aju-
da d’una sèrie d’eines i tècniques molt útils, tal com s’indica en la figu-
La jerarquia, en el disseny estructurat, vol dir que no tots els ele-
ments són iguals, és a dir, uns estan subordinats a uns altres.
La independència, en el disseny estructurat, vol dir que cada ele-
ment té una única comesa.
Un diagrama d’estructures, també anomenat diagrama d’estruc-tures de quadres de Constantine, és una representació gràfica de
l’estructura dels programes, incloses les relacions entre els dife-
rents elements que la componen, denominats mòduls.
DE és la forma abreujada de dir diagrama d’estructures.
Anàlisi i disseny d’aplicacions informàtiques 11 Disseny estructurat d’aplicacions
ra 1, que l’analista ha de saber fer servir amb soltesa, entre les quals
trobem:
Taula d’interfícies.
• Estratègies de disseny:
– Estratègia de transformació.
– Estratègia de transacció.
• Atributs de la qualitat del disseny:
– Acoblament.
– Cohesió.
Els elements principals d’un diagrama d’estructures són:
• Els mòduls.
• Les comunicacions entre mòduls.
1.2.1. Mòduls
Actualment el disseny estructurat gira entorn al concepte de mòdul. Tal
com es representa en la figura 2 un mòdul:
• Representa un programa, subprograma, procediment, funció o rutina,
depenent del llenguatge d’implementació que s’hagi d’utilitzar.
• Admet paràmetres de crida i retorna algun valor, si cal.
• És una unitat de programació compatible independent.
• Es representa en el diagrama mitjançant un rectangle.
• És un tros de codi que pot ser cridat (té nom).
• És un procés que converteix dades d’entrada en dades de sortida.
S’ha de dissenyar el DE de manera que:
• Els mòduls de nivell superior prenguin les decisions d’execució
(coordinin).
• Els de nivell inferior duguin a terme la major part de la feina
d’entrada, càlcul i sortida.
Un mòdul és una part independent d’un programa que es disse-
nya, codifica i prova per separat. Un mòdul és una feina, activitat
o funció ben definida, precisa, clara i única.
Segons Page-Jones (1988) un mòdul és “aquella parte de código que se puede llamar”.
Anàlisi i disseny d’aplicacions informàtiques 12 Disseny estructurat d’aplicacions
S’ha de tenir en compte que hi pot haver mòduls molt senzills (per exemple,
demanar per teclat un valor numèric) amb dues o tres línies de codi, però
també mòduls complexos que en el seu codi incloguin crides a altres mòduls
(per exemple, un mòdul per calcular el descompte en una venda pot fer una
crida al mòdul senzill per demanar un valor numèric, entre d’altres).
Figura 2. Composició d’un mòdul
Característiques desitjables dels mòduls
A l’hora de definir mòduls cal procurar que tinguin
les característiques següents:
• Mida petita. Ideal: 40-50 línies.
• Interfície clara i limitada: paràmetres ben definits i els mínims possibles.
• Independent i acoblament mínim: els canvis fets afecten el mínim pos-
sible la resta del sistema.
• Cohesió interna màxima: encarregat d’executar una funció i només una.
Figura 3. Representació gràfica dels tipus de mòduls
Tipus de mòduls (figura 3):
1) Mòdul normal: cada mòdul es representa com un rectangle amb el nom
a dins. El nom que s’assigna a cada mòdul ha de representar la funció que
duu a terme.
2) Mòdul predefinit: aquell que està disponible a la biblioteca del sistema
o de l’aplicació i pot ser utilitzat en qualsevol ocasió quan faci falta.
Anàlisi i disseny d’aplicacions informàtiques 13 Disseny estructurat d’aplicacions
3) Mòdul connector: per no perdre la referència. Un diagrama d’estructu-
ra no hauria de ser mai més gran que un full mida A4. Si no cap en un full
s’han de posar mòduls connectors a altres mòduls que s’especificaran en
altres fulls.
Connexió entre mòduls
La connexió entre mòduls es representa amb una fletxa, sobre la qual re-
torna en finalitzar l’execució del mòdul, com veiem en l’exemple següent.
Vegeu-ne l’exemple en la figura 4.
L’exemple de la figura 4 representa la crida que un mòdul fa a l’altre per-
què li faci una funció de la manera següent:
• A crida B passant-li paràmetres i cedint-li el control.
• B executa la funció.
• B retorna els paràmetres resultants i el controla A.
• A es continua executant on s’havia quedat.
El diagrama no diu res sobre el codi de A ni sobre el de B, l’únic que se sap
és que en A hi ha una sentència que crida el mòdul B. Tampoc no diu quan-
tes vegades A invoca B ni tampoc mostra detalls interns dels mòduls com
a algoritmes o dades.
Estructures de control bàsiques entre mòduls
Les estructures de control permeten modificar el flux d'execució dels mò-
duls d'un programa en el disseny estructurat. Totes les estructures de con-
trol tenen un únic punt d'entrada i un únic punt de sortida. A continuació
veurem els tipus d'estructures de control bàsiques entre mòduls:
• Alternativa o bifurcació
La selecció es representa amb un rombe com apareix en la figura 5. Signi-
fica que el mòdul que l’executa en crida un de diversos, d’acord amb l’ava-
luació d’una condició.
Figura 5. Estructures de control alternativa i de repetició
Figura 4
Anàlisi i disseny d’aplicacions informàtiques 14 Disseny estructurat d’aplicacions
• Bucle o repetició
La iteració es representa mitjançant un arc o fletxa sobre la crida dels mò-
duls que s’itera, com es pot veure en la figura 5.
Ordre d’execució dels mòduls
L’ordre en què s’executen els mòduls d’un diagrama d’estructures és d’es-
querra a dreta i de dalt a baix.
Figura 6. Exemple per veure l’ordre d’execució dels mòduls
Perquè vegeu clar en quin ordre s’executen els mòduls en un diagrama
d’estructures analitzarem l’exemple de la figura 6.
Els mòduls M1, M2, M3 i M4 criden altres mòduls. Per exemple, M1 en la
seva execució crida M2, M3 i M4. Això significa que quan M1 s’executa, en
invocar M2, li passa el control i queda, al seu torn, interromput, fins que
retorni el control i pugui continuar amb l’execució. M2 en executar-se cri-
da els mòduls M5 i M6. En cridar-los, succeeix el mateix, passa el control
al mòdul invocat i queda interromput. Com que no criden cap altre mòdul,
en finalitzar retornen el control a qui els va cridar, en aquest cas M2. M2
s’acaba d’executar i retorna el control a M1. M1 es continua executant i
crida M3.
Comunicació entre mòduls
La comunicació entre els mòduls es fa mitjançant els elements que s’in-
tercanvien com a entrada i sortida de crides entre mòduls. Hi ha diferents
tipus d’aquests elements que s’intercanvien entre mòduls:
• Dades: és la informació que l’usuari introdueix. El sistema l’emmagat-
zema i la transforma per posteriorment presentar-la a l’usuari. En la
figura 7 apareixen diversos exemples de dades. Representació gràfica de les dades (superior) idels senyals de controls o flags (inferior)
Anàlisi i disseny d’aplicacions informàtiques 15 Disseny estructurat d’aplicacions
• Flags (senyals de control): són valors interns al sistema que sincronit-
zen la comunicació entre mòduls i indiquen condicions d’estat del sis-
tema que afecten l’execució.
Figura 7. Exemple de pas de dades entre mòduls corresponent a una part d’un diagrama
Tal com apareix en la figura 6 la crida d’un mòdul es representa amb una
fletxa, sobre la qual retorna en finalitzar l’execució del mòdul.
En la taula 1 podeu veure clarament les diferències entre dades i flags.
Taula 1. Diferències entre dades i flags
Un cop vistes les diferents parts del diagrama d’estructures i com es co-
muniquen entre elles veurem en la figura 8 un exemple en què podreu ob-
servar com es representen i connecten les diferents parts d’un diagrama
d’estructures: mòduls, dades, estructura alternativa, estructura repetiti-
va. No és necessari entendre a la perfecció l’exemple, només cal que l’in-
tenteu analitzar i observareu les diferents parts que el componen.
Dades Flags
Les dades es processen. Els controls només serveixen per comunicar entre els mòduls.
Les dades són la informació compartida pels mòduls.
Els controls indiquen al mòdul que crida la terminació.
La posició de la fletxa (cap a dalt o cap a baix) indica el sentit de la comunicació.
Les dades tenen importància per al món exterior, estan relacionades amb el problema.
En sentit descendent produeixen acoblament de control no desitjable i la cohesió es veu compromesa.
Es pretén que els mòduls de dalt coordinin, els de baix facin la feina específica i assenyalin condicions anormals o de terminació.
Els flags tenen importància en la comunicació d’informació a l’interior; són els que sincronitzen l’operativa dels mòduls.
Anàlisi i disseny d’aplicacions informàtiques 16 Disseny estructurat d’aplicacions
Figura 8. Diferents parts d’un diagrama d’estructures
1.2.2. Representació de paràmetres
En la figura 9 es mostra una taula d’interfícies que permet que els parà-
metres s’especifiquin millor i així queda més clar el diagrama d’estructu-
res. Amb la taula d’interfícies es comprova que tots els paràmetres
d’entrada tinguin un propòsit determinat.
Figura 9. Taula d’interfícies
* P el paràmetre és PROCESSAT. Per exemple z = a + b; a i b són processats.M el paràmetre és MODIFICAT. Per exemple z = a + b; z és modificat.T el paràmetre és TRANSFERIT en cridar un altre mòdul, sense alterar-ne el valor. C el paràmetre és usat com una VARIABLE DE CONTROL (com a commutador, com un flag o per especificar una funció usada en cridar un altre mòdul).I el paràmetre és TRANSFERIT a un altre mòdul i és MODIFICAT en aquest segon mòdul.
1.3. Estratègies de disseny
La taula d’interfícies és la representació dels paràmetres que es
passen entre mòduls.
Les estratègies de disseny són els passos generals que cal seguir
per obtenir un bon disseny.
Anàlisi i disseny d’aplicacions informàtiques 17 Disseny estructurat d’aplicacions
Hi ha dues estratègies fonamentals per convertir un diagrama de flux de
dades (DFD) en un diagrama de quadres de Constantine:
• anàlisi de transformació,
• anàlisi de transacció.
Bàsicament, el disseny estructurat permet una traducció de les represen-
tacions de la informació (DFD) a una descripció de disseny de l’estructura
del programa, que en funció del tipus de flux de dades de què es tracti, es-
collirà una estratègia o una altra.
1.3.1. Anàlisi de transformació
En l’anàlisi de transformació, les dades entren al sistema mitjançant ca-
mins denominats fluxos d’arribada, per després ser transformats per una
sèrie d’operacions mitjançant l’execució de mòduls i finalment ser conduïts
cap a la sortida, fins a constituir el flux de sortida com es veu en la figura
10, en què es veu com el diagrama de flux de dades (DFD) es transforma
en diagrama d’estructures (DE).
Quan un DFD és d’aquest tipus es diu que té característiques de transfor-
mació.
Figura 10. Traducció de DFD a diagrama d’estructures
Estructura de transformació
Una estructura de transformació s’executa sempre igual, amb el mateix ordre i seqüència, és a dir, si el mòdul s’executa mil vegades, mil vegades es farà la mateixa seqüència de crides i execució de mòduls.
Anàlisi i disseny d’aplicacions informàtiques 18 Disseny estructurat d’aplicacions
L’anàlisi de transformació es duu a terme en els passos següents:
1) Delimitació del centre de transformació
El centre de transformació el constitueixen els processos essencials del
DFD, generalment independents dels processos d’entrada i de sortida. Els
processos que són abans del centre de transformació solen compondre
l’entrada de dades i els que són després del centre de transformació for-
men la sortida de dades (figura 11).
Figura 11. Delimitació del centre de transformació
2) Factorització de primer nivell
L’aplicació de l’anàlisi de transformació dóna com a resultat una estructu-
ra en la qual els mòduls de nivell superior prenen decisions d’execució i
els mòduls de nivell inferior executen la majoria de la feina d’entrada, de
càlcul i de sortida.
En la figura 12 trobem un mòdul Cm, que és el mòdul principal i coordina
els mòduls següents:
• Ce: mòduls controladors de la informació d’entrada.
• Ct: mòduls controladors del centre de transformació.
• Cs: mòduls controladors de la informació de sortida.
Figura 12. Factorització de primer nivell
Recordeu que tots aquests mòduls han de tenir un nom significatiu que re-
flecteixi tot el que hi ha per sota de cadascun d’ells.
Quan deixar de descompondre?
No hi ha respostes definitives, però hi ha dos bons criteris:
• Quan es deixin de trobar funcions ben definides.
• Quan el moviment de dades entre els mòduls sigui massa gran.
Anàlisi i disseny d’aplicacions informàtiques 19 Disseny estructurat d’aplicacions
3) Factorització de segon nivell
El segon nivell de factorització es fa convertint cada procés del DFD en un
mòdul corresponent del diagrama d’estructures (figura 13).
S’ha de tenir en compte que els mòduls que pengen d’un mateix pare
s’han de situar tenint en compte que l’ordre d’execució ha de ser d’esquer-
ra a dreta i de dalt a baix.
També es revisen els fluxos de dades entre processos del DFD, per decidir
les dades i senyals de control.
Figura 13. Factorització de segon nivell
4) Factorització de nivells inferiors
En funció de la profunditat i complexitat del DFD en qüestió, es poden
continuar descomponent els mòduls del diagrama de Constantine.
5) Refinament
Refinar l’estructura del sistema usant mides i guies de disseny. Es pot aug-
mentar o disminuir el nombre de mòduls per aconseguir una factorització
lògica, que tingui una bona qualitat i una estructura que s’implementi sen-
se dificultat.
Exemple de diagrama de transformació
En la figura 14 es mostra un exemple de diagrama de transformació en què:
• El mòdul Principal crida el mòdul Obtenir X per obtenir el paràmetre d’entrada X. El mòdul ObtenirX crida el mòdul Obtenir Y per llegir un valor des d’un dispositiu d’entrada i retornar-lo a Obtenir Xcom a paràmetre. Obtenir X crida el mòdul Canviar Y per calcular X a partir del paràmetre Y.
• Es crida llavors el mòdul T1 per calcular el valor de A a partir del valor de X.
• Després, es crida un altre mòdul T2 per calcular el valor de B a partir del valor de A. Per fer-ho,el mòdul T2 crida els seus subordinats, Calcular V1 i Calcular B.
• El mòdul Principal crida el mòdul Posar B i aquest crida Calcular C, i per treure aquest valor des-prés crida Posar C.
Anàlisi i disseny d’aplicacions informàtiques 20 Disseny estructurat d’aplicacions
Figura 14. Exemple de diagrama de transformació
1.3.2. Anàlisi de transacció
L’anàlisi de transacció succeeix quan, en una aplicació programari, una
dada pot determinar diversos camins alternatius pels quals poden transi-
tar el flux d’informació i en cadascun d’aquests camins la funció sobre les
dades canvia. Cadascun d’aquests possibles camins rep el nom de camíd’acció. Aquests camins parteixen d’un centre de transició exclusió. En la
figura 15 podem veure els camins C1, C2 i C3.
Figura 15. Pas de diagrama de flux de dades a diagrama d’estructures amb anàlisi de transacció
Anàlisi i disseny d’aplicacions informàtiques 21 Disseny estructurat d’aplicacions
L’anàlisi de transformació es duu a terme en els passos següents:
1) Delimitació del centre de transacció
El centre de transacció pot estar format per més d’un procés, com és el
cas del centre de transacció 1 de la figura 16. Se n’han de tenir en compte,
a més a més, tots els fluxos d’entrada i de sortida.
Els diferents camins són aquells per on pot passar el flux d’informació.
Figura 16. Delimitació del centre de transacció
2) Creació de l’estructura bàsica de transacció
Es creen dos mòduls, com es veu en la figura 17: un d’entrada al centre de
transacció (que pot ser una bifurcació) i l’altre de sortida del centre de
transacció (que sempre és una bifurcació).
Figura 17. Estructura bàsica de transacció
3) Factorització de l’estructura bàsica de transacció
Per a cada branca de l’estructura bàsica de transacció s’aplica l’estratègia de
disseny més adequada (transformació o transacció), i es crea un mòdul per
a cada procés del diagrama de flux de dades (DFD) i es connecten amb el
mòdul superior corresponent (o a l’entrada o a la sortida del centre de tran-
sacció). En la figura 18 podem veure que el mòdul que es correspon amb el
centre de transacció conté el rombe i inclou els tres camins diferents.
Anàlisi i disseny d’aplicacions informàtiques 22 Disseny estructurat d’aplicacions
Figura 18. Pas de DFD a estructura de transacció
4) Factorització de nivells inferiors
En funció de la profunditat i complexitat del DFD en qüestió, es poden
continuar descomponent els mòduls del diagrama de Constantine.
5) Refinament
Refinar l’estructura del sistema usant mides i guies de disseny. Es pot aug-
mentar o disminuir el nombre de mòduls per aconseguir una factorització lò-
gica, que tingui una bona qualitat i una estructura que s’implementi sense
dificultat.
En un diagrama d’estructures (DE) normalment són presents ambdues
estructures, de manera que s’obté una combinació d’estructures, com es
veu en la figura 19.
Figura 19. Combinació d’anàlisis de transformació i de transacció
Hi pot haver més d’una solució vàlida per a un mateix problema.
Anàlisi i disseny d’aplicacions informàtiques 23 Disseny estructurat d’aplicacions
Exemple de diagrama de transacció:
En la figura 20 es mostra un exemple de diagrama de transacció en què:
• El mòdul Principal crida el mòdul Entrada, que llegeix una transacció.
• El mòdul Principal analitza la transacció i selecciona el mòdul que es cridarà per al seu proces-sament (M1 o M2 o M3).
• Finalitzada l’execució del mòdul cridat (M1 o M2 o M3), el mòdul Principal cridarà el mòdul Sor-tida.
Figura 20. Exemple de diagrama d’estructures amb anàlisi de transacció
1.4. Atributs de la qualitat d’un disseny
Com es pot saber si el disseny és correcte?
En cada projecte s’ha de decidir quins són els requisits de qualitat que cal
complir i en quina mesura. Podem deduir si el disseny és correcte si cada
mòdul obtingut té la menor relació possible amb la resta dels mòduls del
sistema i, de la mateixa manera, hem d’aconseguir que cada mòdul faci
una única cosa o, en el seu defecte, el menor nombre possible de coses;
això es diu independència funcional (IF).
La independència funcional és un concepte derivat de modularitat, abs-
tracció i ocultament d’informació.
Es tracta de dissenyar programari de manera que cada mòdul se centri en
una funció específica dels requisits i tingui una interfície senzilla, quan es
veu des d’una altra de les parts de l’estructura del programari.
Per què és important la IF? Perquè els mòduls independents són fàcils de
desenvolupar i més fàcils de mantenir i de provar. Es redueix la propaga-
ció d’errades (només afecta els mòduls que tenen l’errada) i es fomenta la
reutilització de mòduls.
La IF és la clau d’un bon disseny i el disseny és la clau de la qualitat de pro-
gramari.
Independència funcional = alta cohesió + baix acoblament
Anàlisi i disseny d’aplicacions informàtiques 24 Disseny estructurat d’aplicacions
La IF s’aconsegueix aplicant dos criteris o propietats fonamentalment: co-
hesió i acoblament.
1.4.1. Acoblament entre mòduls
L’acoblament entre dos mòduls es produeix quan són dependents entre
ells. A mesura que és més gran la quantitat de dades o paràmetres que in-
tercanvien més gran serà l’acoblament. Mentre que com més baix sigui
l’intercanvi més eficaç serà el disseny.
Sempre es busca un acoblament baix entre els mòduls, és a dir, una relació
o interfície entre mòduls tan simple com sigui possible.
El grau d’acoblament s’amida pel nombre de paràmetres que intercanvien.
Figura 21. Tipus d’acoblament
Com podeu veure en la figura 21, hi ha diferents tipus d’acoblament:
1) Sense acoblament: no hi ha connexió directa entre els mòduls.
2) Acoblament normal: A i B estan normalment acoblats ells: A crida B; B
retorna el control a A. Poden ser:
• De dades: hi ha transferència d’informació, paràmetres o variables en-
tre mòduls.
• D’estampat: es passen paràmetres que són compostos i no els necessi-
ten complets, sinó una part dels seus camps. S’ha d’evitar, substituint
L’acoblament és el grau de dependència entre mòduls.
Se cerca l’acoblament baix i s’ha d’evitar l’acoblament alt.
Si dos mòduls presenten més d’un tipus d’acoblament, es considera que tenen el pitjor dels acoblaments que presenten.
Acoblament
• L'ideal és passar entre mòduls només els paràmetres que siguin imprescindibles.
• Com més independent sigui un mòdul, més senzill serà poder-lo substituir.
Exemple sense acoblament
Els mòduls alta proveïdor i modificar articles del magatzem.
Anàlisi i disseny d’aplicacions informàtiques 25 Disseny estructurat d’aplicacions
el paràmetre compost intercanviat per aquells camps l’ús dels quals és
imprescindible. En la figura 22 s’explica amb un exemple el tipus d’aco-
blament d’estampat en què:
– Dades_empleat = codi_empleat + nom + cognom + data_naixement.
– NO fa falta passar dades_empleat, ja que només es necessita
codi_empleat.
Figura 22. Exemple d’acoblament d’estampat
• De control: consisteix a intercanviar senyals de control (flags de con-
trol) entre mòduls. Són raonables si flueixen en sentit ascendent, és a
dir, com a valor de retorn que indica l’estat de l’operació al mòdul que
l’ha demanat.
3) Acoblament comú: es produeix quan més d’un mòdul fa referència a
una àrea comuna de dades. És desaconsellable.
Un exemple d’aquest acoblament podria ocórrer quan tenim una estruc-
tura de dades: dades de l’empleat formades per codi_empleat, nom, cog-
nom i data_naixement, definida com a global i a la qual accedeix més
d’un mòdul.
4) Acoblament per contingut: es produeix quan el mòdul superior acce-
deix a una part interna del mòdul inferior, i se salta així la interfície entre
ambdós. És completament inadmissible i s’ha d’evitar descomponent el
mòdul inferior per fer un mòdul independent d’aquesta part a la qual ne-
cessita accedir el mòdul superior.
1.4.2. Cohesió (consistència)
La cohesió és el grau de relació de les feines que un mòdul duu a terme.
La intenció bàsica del concepte de cohesió és organitzar aquests elements
de tal manera que els que tinguin una relació més gran, a l’hora d’executar
una feina, pertanyin al mateix mòdul i els elements no relacionats esti-
Anàlisi i disseny d’aplicacions informàtiques 26 Disseny estructurat d’aplicacions
guin en mòduls separats. És a dir, mesura el motiu pel qual un codi apa-
reix en el mateix mòdul.
En la figura 23 podem veure els tipus de cohesió entre mòduls. La fletxa
indica el grau de cohesió de cada tipus.
Figura 23. Tipus de cohesió
A continuació veurem cada tipus de cohesió (figura 23):
• Cohesió casual: apareix en mòduls que fan activitats en què l’intercanvi
d’informació és pràcticament nul. Aquestes activitats no tenen res a
veure les unes amb les altres. Acostuma a passar quan es fa un mòdul
amb seqüències que apareix diverses vegades i es reemplaça aquesta
seqüència per un mòdul.
• Cohesió lògica: té lloc quan tots els elements d’un mòdul tracten feines
similars.
Per exemple, un mòdul que produeix totes les sortides independent-
ment del seu tipus o un mòdul que conté tots els accessos a un arxiu.
Aquest tipus de cohesió pot generar duplicació de codi.
• Cohesió temporal: té lloc quan tots els elements d’un mòdul tracten ac-
tivitats diferents relacionades pel temps en què s’executen. Per exem-
ple, col·locar en un mòdul totes les activitats que efectua el sistema
quan es comença a executar, com, per exemple, inicialitzar les varia-
bles, obrir els arxius.
• Cohesió comunicacional: quan un mòdul duu a terme diverses activi-
tats en paral·lel, utilitzant les mateixes dades d’entrada i de sortida.
S’ha de desfer descomponent el mòdul en parts, si es tracta d’activitats
no elementals o nombroses.
Es busca cohesió alta i s’ha d’evitar cohesió baixa.
Anàlisi i disseny d’aplicacions informàtiques 27 Disseny estructurat d’aplicacions
Figura 24. Exemple complet de creació de diagrama d’estructures
Anàlisi i disseny d’aplicacions informàtiques 28 Disseny estructurat d’aplicacions
• Cohesió seqüencial: té lloc quan les sortides dels elements d’un mòdul
serveixen d’entrada a altres elements del mòdul. No comporta una in-
coherència gaire important si el nombre i la complexitat d’aquestes ac-
tivitats no és gaire gran.
• Cohesió funcional: la que presenta un mòdul els elements del qual es-
tan units per fer una única missió. És el millor tipus de cohesió que
existeix i forma, juntament amb un acoblament de dades i de control
descendent, la fórmula perfecta per a un disseny de qualitat. !
1.5. Exemple complet de creació de diagrama d’estructures
Es tracta de fer el disseny estructurat, mitjançant un diagrama de quadres
de Constatine, del manteniment del fitxer de clients d'una empresa. Es
podrà escollir mitjançant un opció entre altes, baixes i modificacions de
les dades dels client. L’usuari podrà executar qualsevol de les tres funci-
ons depenent de l’opció que esculli.
L'opció d'alta serveix per afegir un client nou a l’empresa. L'opció de baixa
serveix per esborrar un client del fitxer de clients i l’opció de manteni-
ment serveix per modificar les dades d'algun client que ja existeix.
Hi ha un codi de client que és únic que serveix per identificar cada client.
En el primer diagrama perquè quedi més clar, s’enllacen amb els mòduls
connectors ALTA, BAIXA i MODIFICACIÓ. El diagrama es veu en la figura 24.
Anàlisi i disseny d’aplicacions informàtiques 29 Disseny estructurat d’aplicacions
2. Disseny d’interfícies d’usuari
Una vegada fet el disseny de l’aplicació, s’ha de fer el disseny de les inter-
fícies d’usuari de manera que la interacció entre els usuaris i l’ordinador
es pugui ajustar a les preferències de cadascun d’ells, i es mantinguin els
requisits establerts al principi del projecte.
És molt important encertar en aquesta feina, ja que una mala interfície
pot produir el rebuig dels usuaris fins i tot d’una aplicació molt eficient.
Per la importància que té la interfície en l’èxit final de l’aplicació, mai no
està mal empleat el temps que es dedica a comentar-ne amb l’usuari el
funcionament, a admetre els seus suggeriments i a fer-hi els canvis corres-
ponents; d’aquesta manera queda constància de la participació del client
i n’augmenta el grau de satisfacció.
És tan comú conviure amb un ordinador que cada vegada es fa més impe-
ratiu la millora de la interacció persona-màquina mitjançant una interfí-
cie adequada.
Des del punt de vista d’enginyeria del programari, la interfície d’usuari té
un paper important en el desenvolupament i la posada en marxa de tot el
sistema. És la carta de presentació de tot projecte i a vegades resulta de-
terminant per a la seva acceptació o rebuig.
El disseny d’una interfície es concentra en tres àrees importants:
• Disseny d’interfícies entre els mòduls programari (interfícies internes).
• Disseny d’interfícies entre el programari i altres productors/consumi-
dors no humans d’informació (interfícies externes).
• Disseny d’interfícies entre l’home i la computadora (interfícies d’usuari).
Ens centrarem en el disseny d’interfícies entre l’home i la computadora,
o interfícies home-màquina (IHM).
2.1. Importància de la interfície d’usuari
L’home constantment interactua amb altres objectes i n’espera un com-
portament concret. Si la interfície està ben dissenyada, l’usuari trobarà les
respostes que espera a les seves accions. Si no, serà frustrant per a ell, ja
que l’usuari tendeix a sentir-se culpable per no saber utilitzar l’objecte.
El millor sistema o l’eina perfecta són inútils si no podem interactuar-hi.
Ara, penseu en totes les aplicacions i els llocs que heu fet servir recent-
ment, quantes vegades no heu trobat el que busqueu o no heu sabut com
fer el que voleu? Aquesta situació és resultat d’una interfície dolenta.
Errors en les interfícies
Entre el 1985 i el 1987, almenys cinc persones van morir en rebre una teràpia mèdica de radiació amb la màquina Therac25. Després de diversos estudis es va descobrir que la causa de l’error era un error de programari en la interfície gràfica de control de la màquina que permetia subministrar dosis de radiacions mortals. Els programadors que van dissenyar i programar la interfície gràfica probablement no van ser conscients de la repercussió d’un error en la seva feina. Afortunadament, no tots els errors de programari acaben tan tràgicament, però poden provocar grans pèrdues econòmiques.
Interfície d’usuari pobra
Una interfície d’usuari pobra produeix:
• Reducció de productivitat.
• Temps d’aprenentatge inacceptables.
• Nivells d’errades que produeixen frustració.
Hi ha qui opina que el disseny d’interfícies és un tipus d’art modern, com en el seu dia va ocórrer amb certes tècniques i obres arquitectòniques.
Anàlisi i disseny d’aplicacions informàtiques 30 Disseny estructurat d’aplicacions
Quan es dissenya un objecte cal pensar en qui l’utilitzarà i les expectatives
que tindrà sobre la forma d’ús, tant si es tracta d’objectes coneguts com si
són objectes nous.
Els elements maquinari fan referència a la part física de l’ordinador (dis-
positius utilitzats per introduir, processar i lliurar les dades). L’element
més important relatiu a aquesta part són els criteris d’ergonomia, segons
els quals les interfícies maquinari han de ser còmodes, segures i saluda-
bles. De la mateixa manera, aquestes interfícies maquinari han de ser
adaptables a persones amb algun tipus de discapacitat.
Els elements programari són els elements que l’usuari (eventualment)
veu a la pantalla, amb els quals pot interactuar (crides a comandes del sis-
tema o accessos a programes) i amb els quals pot manipular la informació.
També els manuals, les ajudes, les referències i els programes d’aprenen-
tatge (tant dels programes com del sistema o del maquinari) són part dels
elements programari.
En la figura 25 es mostra una interfície senzilla i intuïtiva de l’aplicació
Windows Media per a música i vídeo. La imatge interior correspon a la vi-
sualització que es produeix al ritme de la música.
Per tractar el disseny d’interfícies és necessari centrar-nos, en primer
lloc, en tres principis fonamentals del disseny de la comunicació:
• Models de disseny: que podem resumir en models d’usuari, de progra-
mador i de dissenyador.
• Regles del disseny: són una sèrie d’aspectes que ens serveixen per de-
terminar com es pot fer un bon disseny d’interfícies gràfiques d’usuari.
Inclou consells relacionats amb la interacció home-màquina, visualit-
zació de la informació i entrada de dades.
• Assistència i ajuda a l’usuari: sistema de documentació, ajuda en línia,
contextual...
Podem definir una interfície d’usuari com el conjunt d’elements
(maquinari i programari) que actuen com a frontera entre el do-
mini de la persona i el de la màquina amb la missió d’aconseguir
i facilitar la comunicació entre ambdós, quasi com un traductor
entre el llenguatge de l’usuari i el de l’ordinador.
Disseny d’interfícies
S’estima que del 35% al 45% de les despeses destinades a un projecte estan directament relacionades amb el disseny de la interfície. Aquesta és, per tant, una de les raons per les quals s’ha fet necessària la formalització del procés de disseny d’interfícies.
Els programes els utilitzen diversos usuaris amb diferents nivells de formació i interessos. Per tant, no hi ha una única interfície vàlida per a tots els usuaris i per a totes les tasques.
Podeu anar a la secció “Adreces d’interès” del web per tal de conèixer més sobre el disseny d’interfícies d’usuari i tenir-ne una visió global d’una manera molt concisa.
!!
Anàlisi i disseny d’aplicacions informàtiques 31 Disseny estructurat d’aplicacions
Figura 25
Tots aquests controls permeten a l’usuari interactuar amb l’ordinador per escoltar música o per veure un vídeo.
2.2. Models de disseny d’interfície
Els models de disseny d’interfícies són els punts de vista des dels quals es
poden estudiar les interfícies entre la màquina i qui utilitza el programari.
No es pot afirmar mai categòricament haver trobat el model de disseny
perfecte. Aquest varia en funció de l’heterogeneïtat de qui l’utilitzi. En
aquest sentit, es poden identificar tres punts de vista clarament definits:
d’usuari, de programador i de dissenyador.
2.2.1. Model d’usuari
L’usuari necessita veure d’una manera clara les opcions de què disposa.
Si ens situem en el punt de vista de l’usuari, aquest tendeix a crear inter-
fícies d’aprenentatge ràpid, en les quals no sigui fàcil cometre errors i que
no requereixin que faci un gran ús de la memòria (ment). Recordem sem-
pre que un gran sistema no valdrà res si l’usuari el rebutja pel fet de no
resultar-li còmode.
Anàlisi i disseny d’aplicacions informàtiques 32 Disseny estructurat d’aplicacions
Per construir unes bones interfícies d’usuari, tot disseny ha de començar
per conèixer els usuaris a qui va dirigida: edat, sexe, capacitats físiques,
formació, historial cultural i ètnic, motivació, personalitat...
Convé fer una classificació dels usuaris, com la que podeu veure en la taula 2.
Taula 2. Classificació d’usuaris
Hem de tenir en compte els aspectes de la psicologia humana. Quan es dis-
senya una interfície cal tenir presents les habilitats cognitives i de percep-
ció de les persones, i adaptar-hi la interfície.
Una de les coses més importants que pot fer una bona interfície per les
persones és reduir la dependència de la memòria pròpia i impedir que
s’hagin de fer les coses més cops dels necessaris. La màquina ha d’utilitzar
les seves capacitats per suplir les capacitats que no té la persona.
2.2.2. Model de programador
El model de programador es correspon amb la visió tècnica de la interfí-
cie, que inclou aspectes relatius al sistema operatiu, llenguatge de progra-
mació o restriccions de disseny estàndards.
És constituït pels objectes que manipula el programador, diferents dels que
tracta l’usuari (exemple: el programador anomena base de dades el que l’usu-
ari podria anomenar agenda). Aquests objectes s’han d’amagar a l’usuari.
Generalment la visió del programador i la de l’usuari entren en conflicte,
els primers prefereixen un entorn més àgil, específic o concret i els se-
gons, un de visualment atractiu i fàcil d’usar.
2.2.3. Model de dissenyador
El dissenyador és un intermediari entre l’usuari i el programador. Con-
trasta les necessitats, les idees i els desitjos de l’usuari amb els materials
de què disposa el programador per fer el programa. Amb tots aquests ele-
ments, dissenya el programa i la interfície.
Tipus d’usuari Característiques
Novells Sense coneixements sintàctics del sistema. Sense coneixements semàntics del sistema o amb pocs.
Esporàdics amb coneixements Amb coneixements semàntics raonables.
Amb dificultats per recordar els coneixements sintàctics necessaris.
Freqüents amb coneixements Bons coneixements sintàctics i semàntics del sistema.
Sovint tenen la síndrome de l’usuari potent: busquen i aprenen dreceres en l’operació del sistema.
Anàlisi i disseny d’aplicacions informàtiques 33 Disseny estructurat d’aplicacions
La presentació és el primer que crida l’atenció de l’usuari, però de seguida
passa a un segon pla a favor de com el producte compleix les expectatives
de l’usuari, excepte si resulta contraproduent (abús del color, el so, el mo-
viment, desorganització en la interfície...).
Determinar els objectes que s’han de manipular i les seves relacions és
l’aspecte més important.
Els dissenyadors d’interfícies han de tenir en compte les habilitats cogni-
tives i de percepció de les persones i adaptar-hi el programa. Així, una de
les coses més importants que una interfície pot fer és reduir la dependèn-
cia de les persones de la seva pròpia memòria, de manera que no les forci
a recordar coses innecessàriament (per exemple, informació que ha apa-
regut en una pantalla anterior) o a repetir operacions ja executades (per
exemple, introduir una mateixa dada repetides vegades).
2.3. Regles per al disseny d’interfícies d’usuari
El disseny d’interfícies d’usuari es fonamenta en l’experiència del disse-
nyador i en les anècdotes recollides en centenars de manuals i documents
per al cas.
Encara que els aspectes que determinen el disseny d’interfícies gràfiques
d’usuari són múltiples, els podem agrupar en tres grans grups:
• Interacció general: en la qual tindrem en compte aspectes relacionats
amb les comandes d’execució de feines, protecció del sistema i facili-
tats d’ajuda i assistència.
• Visualització informació: és la manera com el sistema presenta resul-
tats a l’usuari i com ha d’actuar en qualsevol situació que requereixi la
seva intervenció.
• Entrada de dades: estableix com l’usuari es comunica amb el sistema
per proporcionar dades i establir les condicions de funcionament del
sistema i la seva configuració.
2.3.1. Interacció general
Amb la paraula interacció ens referim a la manera com un usuari ha de poder
fer l’entrada-sortida d'informació amb la màquina. Els requisits que una in-
terfície d'usuari ha de complir per considerar-se acceptable són els següents:
1) Ser consistent en els formats dels menús, la forma com l’usuari in-
troduirà ordres i els aspectes de visualització.
Anàlisi i disseny d’aplicacions informàtiques 34 Disseny estructurat d’aplicacions
La consistència permet que l’usuari reconegui situacions anàlogues en
moments diferents i també permet reutilitzar el coneixement adquirit en
l’ús d’un programa en l’ús d’altres.
Podem parlar dels principis de consistència següents:
• Consistència de presentació: és a dir, associar accions a objectes, com
es pot observar en la figura 26 la consistència de les petites estructures
visibles pels sistemes gràfics basats en finestres, com la inclusió de
l’opció “x” per tancar la finestra –operació habitualment utilitzada en
aplicacions– que simplifica l’operativitat.
• Consistència de comportament: quan el mateix objecte es comporta
sempre igual, independentment del context en què es troba. Exemple:
rellotge flotant que sempre marca els segons amb un parpelleig.
• Consistència d’interacció: succeeix quan interactuant de la mateixa
manera sobre objectes diferents l’usuari espera respostes similars.
Exemple: en fer clic amb el botó dret sobre qualsevol objecte desplega
un menú contextual referit a l’objecte.
2) Reduir la càrrega de memòria de l’usuari.
La interfície ha d’evitar que l’usuari hagi d’emmagatzemar i recordar in-
formació. Per això cal seguir els principis següents:
• Minimitzar la càrrega de la memòria de curt abast (permetre desfer,
copiar i enganxar, mantenir les últimes dades introduïdes).
• Basar-se en el reconeixement abans que en el record (exemple: escollir
d’entre una llista en lloc de tornar a teclejar).
• Proporcionar indicacions visuals d’on és l’usuari, què està fent i què pot
fer a continuació, com es mostra en la figura 27.
• Proporcionar funcions desfer, tornar a fer.
• Proporcionar una altra manera d’arribar més ràpidament amb tecles
ràpides (Ctrl + C: copiar; Ctrl + V: enganxar, per exemple).
• Fer servir metàfores del món real que generen figures mentals fàcils de
recordar. Bones metàfores serien l’escriptori, la paperera de reciclatge
o, com en la figura 28, la imatge d’una agenda per indicar el sistema te-
lefònic del Lotus Organizer, al contrari de les imatges agafades pel Lotus
Organizer com a icones de la mateixa figura que no són un bon exemple.
Figura 26. Consistència de presentació
Ratolí
Estan apareixent nous substituts del ratolí per controlar el punter de la pantalla i això, sens dubte, canviarà les interfícies associades. En l’apartat web apareix un enllaç que tracta d’aquest tema.
Anàlisi i disseny d’aplicacions informàtiques 35 Disseny estructurat d’aplicacions
Figura 27. Pantalla de l’Internet Explorer
Figura 28. Imatge d’una agenda i icones del Lotus Organizer
3) Buscar l’eficiència en el diàleg, el moviment i el pensament.
El nombre de pulsacions s’hauria de minimitzar. S’ha de procurar no ha-
ver d’alternar constantment el ratolí amb el teclat: o l’un o l’altre. També
Anàlisi i disseny d’aplicacions informàtiques 36 Disseny estructurat d’aplicacions
s’ha de vigilar la distància entre elements consecutius, entre els quals s’ha
de moure sovint el ratolí.
En tot cas, que l’usuari no hagi de preguntar-se “i ara... què?”.
4) Tenir en compte les errades.
Els missatges d’error i advertiments són “males notícies” per a l’usuari,
enviades pel sistema quan alguna cosa “ha anat malament”; això fa que si-
guin percebuts de manera negativa. No cal, per tant, afegir més negativi-
tat a l’assumpte. Com ara els missatges de l’estil “error greu a AE0004F”.
En aquest missatge d’error apareix la paraula greu, que afegeix més nega-
tivitat, i també apareix un codi, que gairebé ningú coneix, cosa que afegeix
més incertesa encara.
Els missatges han d’anar acompanyats d’un senyal visible i/o audible. No
ha de contenir judicis, és a dir, no s’ha de culpar l’usuari.
A cap usuari no li agrada trobar-se un missatge d’error, per ben dissenyat
que estigui, però una bona filosofia de missatges d’error pot millorar molt
la qualitat d’un sistema interactiu.
5) Explicacions fluides i clares.
La informació que dóna el programa en les respostes a l’usuari ha de com-
plir els requisits següents:
• Oferirem respostes significatives com, per exemple, senyals visuals i
auditius, per garantir el màxim de comunicació home-màquina.
• Fer servir verbs d’acció senzills, o frases curtes, per anomenar les ordres.
• Reduir els temps de resposta. El temps de resposta és el temps que pas-
sa entre que l’usuari exerceix alguna acció de control fins que el siste-
ma respon amb alguna sortida o acció.
S’ha de procurar reduir els temps de resposta davant l’usuari, de ma-
nera que puguem evitar la sensació de desesperació de l’usuari davant
esperes llargues.
Si el procés ha de trigar relativament molt, s’ha d’avisar l’usuari que l’ac-
ció pot prendre uns minuts i posar un indicador de progrés de l’acció.
• Explicar quan s’ha acabat una tasca. Indicar d’alguna manera que una
tasca que s’executava en background, o que estava trigant molt a aca-
bar, finalment ha acabat. Indicar què cal fer en cada moment.
Missatge d’error
Els missatges d’error:
• Han de donar informació de la causa de l’error.
• Han de donar informació de quina seria la possible solució.
• Han d’indicar les conseqüències negatives de l’error.
Anàlisi i disseny d’aplicacions informàtiques 37 Disseny estructurat d’aplicacions
Mostrar informació que indiqui a l’usuari què ha de fer, com ara: “In-
troduir ordre”, “Seleccionar opció”, etc.
• Acceptar el que s’ha fet en cada moment. Mostrar informació que indi-
qui a l’usuari que l’última acció ha estat correcta (passar al camp se-
güent, mostrar un “ok” en algun lloc, etc.).
Les restriccions imposades pel sistema visual són:
• Mida de lletra 12.
• Espai entre línies proporcional.
• Fonts no complicades ni difícils de llegir.
• No utilitzar majúscules.
2.3.2. Visualització de la informació
Si la informació que presenta la interfície és ambigua o incompleta, no sa-
tisfarà les necessitats de l’usuari, per la qual cosa s’han de tenir en compte
els principis següents:
1) Ús del color
El color no solament és decoratiu, també transmet informació (exemple:
reforçar missatges d’error, com es pot apreciar en la figura 29). El color és
probablement l’element de la interfície que amb més freqüència s’utilitza
malament. S’han de fer servir combinacions adequades (per exemple, les
paletes proporcionades pels sistemes operatius). El color ha d’atraure
l’atenció, però no cansar després d’una estona de feina. És especialment
important seguir les línies de disseny existents.
Figura 29. Missatge d’error reforçat amb colors
Anàlisi i disseny d’aplicacions informàtiques 38 Disseny estructurat d’aplicacions
Abans de dissenyar el color s’ha de tenir en compte una sèrie de restriccions
imposades pel sistema visual:
• Escollir combinacions de colors compatibles. Evitar vermell-verd, blau-
groc, verd-blau, vermell-blau.
• Usar codis redundants, com formes, ja que hi ha moltes malalties que
afecten la visió.
• Evitar colors brillants en grans àrees de la pantalla.
2) Àudio
En primer lloc, cal veure quan la informació àudio és més apropiada que
la informació visual. En segon lloc, determinar el so adequat. En tercer
lloc, permetre la personalització (volum i desactivació). Com en el cas dels
colors, hi ha guies d’ús. En llocs de feina oberts pot ser poc efectiu; a més
a més, pot ser molest per a algunes persones. El so s’ha de fer servir per
informar d’alguna cosa.
3) Animació
L’animació es defineix com un canvi en el temps de l’experiència visual
d’un element gràfic. Exemples del seu ús: progrés d’accions (com apareix
en la imatge), estats de processos (icones d’impressora), accions possibles
(canvis en el cursor en desplaçar el ratolí). L’animació pot ajudar a desta-
car icones importants, mostrar l’estat d’un objecte particular o explicar-ne
el comportament o simplement fer més amigable una interfície.
A més a més, s’ha d’intentar:
• Mostrar només la informació que sigui rellevant en el context actual.
• No atabalar l’usuari amb dades: presentar-li un format de visualització
que li permeti una assimilació ràpida de la informació.
• Usar etiquetes consistents, abreviatures estàndards i sempre les ma-
teixes, i colors predictibles i fàcilment interpretables.
• Produir missatges d’avís i d’error significatius i assegurar-se que els
missatges d’error i els avisos es veuen.
• Considerar la distribució disponible en la pantalla i utilitzar-la amb efi-
càcia fent clara la presentació visual, fent agrupació d’objectes, evitant
Podeu veure un exemple de guia d’ús del color en la secció “Annexos” del web d’aquest crèdit.
!!
Anàlisi i disseny d’aplicacions informàtiques 39 Disseny estructurat d’aplicacions
la presentació excessiva d’informació com en la figura 30, en què es veu
un exemple bo i un altre de dolent de presentació d’informació. A la
dreta es veu clarament que està molt organitzat tant els colors com l’es-
pai que ocupa la informació.
Figura 30. Exemples bo (dreta) i dolent (esquerra) de la presentació d’informació
2.3.3. Entrada de dades
En les aplicacions per ordinador és quasi imprescindible que l’usuari apor-
ti informació, ja sigui exclusivament per ser emmagatzemada i recupera-
da posteriorment, o bé per fer operacions o el processament d’aquestes
dades. En qualsevol cas, el comportament de la interfície s’hauria d’ajus-
tar als punts següents:
• Minimitzar el nombre d’accions d’entrada de dades que ha de dur a ter-
me l’usuari.
• Mantenir la consistència entre la informació visualitzada i les dades
d’entrada.
• Permetre a l’usuari personalitzar l’entrada de dades segons les seves
preferències.
• Desactivar ordres que siguin inapropiades en el context actual.
• Proporcionar ajuda en totes les acciones d’entrada de dades.
Anàlisi i disseny d’aplicacions informàtiques 40 Disseny estructurat d’aplicacions
2.4. Ajuda a l’usuari
Les ajudes poden ser:
• Ajudes integrades: es dissenyen des del principi, juntament amb la res-
ta del programari.
Sovint són sensibles al context. Això redueix el temps que l’usuari in-
verteix en l’obtenció de l’ajuda i fa la interfície més amigable.
• Ajudes agregades: s’afegeixen al programari després que s’ha construït
el sistema.
Sovint és un manual d’usuari amb la particularitat que es troba en línia.
Acostuma a provocar que l’usuari hagi d’escollir entre molts temes re-
lacionats amb el que li interessa, amb tot de falsos intents, i rebent un
excedent d’informació que, al final, no li venia al cas.
No hi ha dubte que és millor una ajuda integrada. Les ajudes més usuals
són les següents:
• Manuals d’usuari. A pesar de constituir una documentació excel·lent,
poden ser rebutjats pels usuaris a causa de l’extensió, nivell de detall i
llenguatge de vegades excessivament tècnic.
• Ajudes en línia. Presents a l’ordinador, formen part de la mateixa apli-
cació (a vegades s’hi accedeix amb la tecla F1).
El seu problema és que, en contra dels manuals d’usuari, no permet
una lectura profunda i continuada, ja que llegir en pantalla provoca
molt més cansament que llegir en paper i, a més a més, està limitat.
• Ajudes contextuals. Formen part de l’ajuda en línia, però es refereixen
a l’element sobre el qual l’usuari està treballant en aquest mateix mo-
ment. Es poden consultar amb F1 o en prémer el botó dret del ratolí, o
bé arrossegant la icona d’interrogació que es troba a la filera superior
dreta de botons d’algunes finestres.
L’ajuda a l’usuari es pot presentar en forma de manuals, que l’usuari
ha de consultar quan necessita informació addicional.
Cada vegada més el programari incorpora l’ajuda en línia, que
permet a l’usuari trobar una resposta sense haver d’abandonar la
interfície.
Ajuda sensible al context
Molts programes ofereixen ajuda intel·ligent de l’objecte sobre el qual es prem amb el botó d’ajuda.
Normalment tenen un botó a dalt a la dreta.
Si es prem aquest botó i després es prem alguna altra part de la finestra s’aconsegueix una explicació de la zona on érem.
També podem trobar ajuda sensible al context amb altres botons similars:
En alguns programes també es pot trobar ajuda sensible al context prement el botó dret del ratolí.
Anàlisi i disseny d’aplicacions informàtiques 41 Disseny estructurat d’aplicacions
• Programes d’aprenentatge. Són guies d’usuari conceptualment disse-
nyades per ser llegides d’una manera ordenada, com un passeig per
l’aplicació. Es dirigeixen a usuaris novells i moltes vegades s’inclouen
en la mateixa ajuda en línia del programa.
2.5. Guies de disseny o guies d’estils
Per construir interfícies adequades a vegades ens hem de remetre a estàn-
dards ja definits, que tothom pot arribar a conèixer, i respectar-los per fa-
cilitar l’adaptació de l’usuari a la interfície.
Les guies de disseny comprenen tres àrees del disseny de la interfície:
1) Àrea físicaElements maquinari que la interfície podrà utilitzar / haurà d’utilitzar. Per
exemple: el ratolí, amb una acció concreta establerta per a cada botó.
2) Àrea sintàcticaPresentació de la informació i seqüència i ordre d’accions que l’usuari ha
de dur a terme per assolir un objectiu. Per exemple: per imprimir, prepa-
rar pàgina, seleccionar paràmetres d’impressió, imprimir.
3) Àrea semànticaSignificat dels objectes i de les accions. Per exemple: tot botó significa
“obrir el programa de correu per escriure un correu”.
Cada entorn de desenvolupament, Apple (Macintosh), IBM (OS/2, DOS),
Microsoft (Windows) i UNIX (OSF/Motif), té les seves pròpies guies de dis-
seny. Els desenvolupadors les han de seguir per obtenir consistència amb
la resta de productes de la casa. Per exemple, el logotip de Windows està
fitxat, no es pot canviar i és únic per a totes les versions de Windows.
Una guia d’estil és un conjunt de recomanacions, generalment
proposades per un fabricant o organització (local, estatal o inter-
nacional), que descriuen unes regles que cal seguir a l’hora de
dissenyar l’aspecte i el comportament de les interfícies.
Cada empresa acostuma a tenir guies d’estil pròpies que s’apliquen
a tots els productes amb la finalitat de dotar-los de consistència vi-
sual i operativa i de mantenir una imatge corporativa.
Anàlisi i disseny d’aplicacions informàtiques 42 Disseny estructurat d’aplicacions
La figura 31 mostra la denominada piràmide de guies, en què s’observa
com unes guies es construeixen sobre les altres.
Figura 31. Piràmide de guies d’estil
Tanmateix, les guies d’estil són recomanacions, i de vegades la usabilitat
del programa pren prou importància per saltar-se-les.
2.6. El procés de desenvolupament d’interfícies
Actualment, el procés de desenvolupament d’una interfície es pot consi-
derar com un cicle que consta de quatre etapes, en diversos nivells, com
es veu en la figura 32.
• Disseny.
• Implementació.
• Mesurament.
• Avaluació.
El disseny d’interfície és una disciplina que estudia i tracta de po-
sar en pràctica processos orientats a construir la interfície més
usable possible, ateses certes condicions d’entorn.
Definim usabilitat d’un sistema o eina com la mesura de la seva
utilitat, facilitat d’ús, facilitat d’aprenentatge i apreciació per
una feina concreta, un usuari i un context determinat.
Un sistema és usable si és fàcil d’aprendre i fàcil d’utilitzar.
Usabilitat
Anàlisi i disseny d’aplicacions informàtiques 43 Disseny estructurat d’aplicacions
Figura 32. Procés de desenvolupament d’interfícies
El resultat (o output) de cada etapa és l’alimentació (o input) de la que
segueix, fins i tot el de l’última. S’agafen els resultats de l’etapa d’avalua-
ció per tornar a dissenyar la interfície, implementar-la novament, avaluar-
la i així successivament.
A causa d’aquesta repetició o autoalimentació aquest procés s’anomena
disseny iteratiu.
Mentre tinguem temps, tractarem de fer tants cicles de millora com ens
sigui possible, fins a la data límit. La versió següent, agafarà el producte
existent com el començament i una altra vegada començarà el cicle.
A més de la recursivitat, una altra característica de la visió actual del disseny
d’interfícies és que involucra no solament els especialistes en el disseny, sinó
tot l’equip de desenvolupament.
Qui constitueix l’equip de desenvolupament?
Tots aquells que participen d’alguna manera en el desenvolupament o co-
mercialització del sistema: gent de màrqueting, comunicació, documenta-
ció, sistemes i informàtica, disseny, etc.
Cadascú té coneixement sobre una àrea específica, i la seva participació al
llarg del desenvolupament fa augmentar les probabilitats d’èxit.
Tots els equips poden tenir discussions sobre la usabilitat d’un lloc (ús de
l’aplicació que s’està fent). Res millor per acabar aquestes discussions que
Anàlisi i disseny d’aplicacions informàtiques 44 Disseny estructurat d’aplicacions
un test d’usabilitat, que no és ni més ni menys que veure com un usuari
tracta d’usar aquest programari, per tornar al laboratori sense discussions
i acceptar que és necessari canviar la versió actual.
En la taula 3 podeu veure una descripció més detallada de què es fa en ca-
dascuna de les etapes.
Taula 3. Etapes del cicle
A continuació, detallarem com es poden fer els tests d’usabilitat per ava-
luar els prototips d’interfícies per part de l’usuari:
El dissenyador pot prendre dades qualitatives i quantitatives per avaluar
els prototipus:
• Per recollir dades qualitatives, es poden passar qüestionaris a una pobla-
ció d’usuaris en què les preguntes es responen amb SÍ/NO, valoracions
graduals, percentatges subjectius...
• Per recollir dades quantitatives, cal recórrer a l’observació de l’usuari
durant un cert temps. Cal recollir dades com:
– Nombre de tasques completades en un cert temps.
– Freqüència de l’ús de les ordres.
– Temps invertit a mirar el monitor.
– Temps d’utilització de l’ajuda.
Com s’articula el disseny d’interfícies dins d’un projecte?
Una de les claus més importants per articular un bon procés de disseny d’in-
terfície i així augmentar la usabilitat del producte resultant és començar
amb el cicle de disseny iteratiu tan aviat com sigui possible. Com més aviat
es comenci, menys probabilitat hi ha que s’arribi a la versió pública amb
Etapa Feines
Disseny
Anàlisi dels requeriments del producte.
Anàlisi de les tasques.
Coneixement de l’usuari.
Generació de possibles metàfores i anàlisi de tipus de diàleg.
Revisió de possibilitats per a la implementació.
ImplementacióGeneració de prototips.
Desenvolupament de l’aplicació, lloc o sistema.
Mesurament i avaluació dels prototips(test d’usabilitat)
Cal avaluar si cobreix les necessitats de l’usuari.
Planificació (desenvolupament del pla, definició de les mides, selecció de participants, formació d’observadors, preparació dels materials).
Test (prova pilot, tests amb usuaris).
Avaluació del procés
Conclusió (anàlisi de les dades, elaboració de l’informe, resultats i recomanacions).
Comparació d’estàndards (interns i/o externs), versions anteriors del mateix producte i productes competidors.
Verificació de les diferències.
Generació de noves metes.
SDIU
Per fer els prototips, hi ha paquets de software CASE anomenats sistemes de desenvolupament d’interfícies d’usuari (SDIU) o kits d’eines d’interfície d’usuari.
Eines conegudes:
• Demo, de Symantex.
• Excelerator (eina CASE, que inclou facilitats de disseny de pantalles).
• Powerbuilder, de PowerSoft.
• D’altres.
Podreu fer una pràctica d’un test d’usabilitat d’un lloc web que trobareu en la secció “Adreces d’interès” del web d’aquest crèdit.
!!
Anàlisi i disseny d’aplicacions informàtiques 45 Disseny estructurat d’aplicacions
errades importants i més temps per millorar aquelles característiques que
poden ser millorables. A més a més, és molt més ràpid i barat modificar pro-
totips que fer un canvi en un producte avançat o ja desenvolupat.
Un altre factor que col·labora amb el bon desenvolupament del producte
és una àmplia participació de totes les persones involucrades. Les feines
de tots estan íntimament lligades i és necessari que cadascun sàpiga no so-
lament la feina que li toca, sinó que entengui com s’articulen aquestes fei-
nes amb la resta i les persones de l’equip.
La interfície ha de permetre canvis a mesura que els resultats dels tests
–que es fan als usuaris per veure si funciona bé– dictin les modificacions.
2.7. Evolució de les interfícies
L’evolució de les interfícies d’usuari va en paral·lel amb la dels sistemes
operatius (SO); de fet, la interfície constitueix actualment un dels princi-
pals elements d’un sistema operatiu. Són les mateixes empreses de des-
envolupament del programari les que han d’adaptar les seves interfícies
perquè segueixin les directrius de disseny segons les guies d’estil dels di-
ferents sistemes operatius.
2.7.1. Interfície de línia d’ordres
La interfície de línia d’ordres (CUI, command-line user interface) és la
primera interfície coneguda des del punt de vista informàtic. Habitual del
SO DOS i les primeres versions de UNIX. Requereix la introducció d’ins-
truccions per part de l’usuari en un llenguatge formal amb vocabulari i sin-
taxi pròpia, per mitjà del qual s’expressen les accions que es volen
executar, com es pot veure en la figura 33, en què hi ha ordres d’MS-DOS.
Figura 33. Ordres d’MS-DOS amb interfície de línia d’ordres
CUI
Un intèrpret d’ordres, intèrpret de línia d’ordres, intèrpret d’ordres, terminal, consola, shell o el seu acrònim en anglès CLI (command line interface) és un programa informàtic que actua com a interfície d’usuari per comunicar a l’usuari amb el sistema operatiu mitjançant una finestra que espera ordres escrites per part de l’usuari en el teclat (per exemple, PRINT CARTA.TXT), les interpreta i les lliura al sistema operatiu per executar-les. La resposta del sistema operatiu es mostra a l’usuari a la mateixa finestra.
Anàlisi i disseny d’aplicacions informàtiques 46 Disseny estructurat d’aplicacions
El model de la interfície és un model propi del programador, no és un mo-
del de l’usuari.
Inconvenients:
• L’usuari ha d’utilitzar molt la seva memòria.
• No sempre els noms de les ordres són adequats a les funcions que fan
i poden ser mal entesos.
• Manca de flexibilitat en els noms de les ordres (DEL, no DELETE); sin-
taxi estricta.
Avantatges:
• Potent.
• Controlat per l’usuari (avantatge només si es tracta d’un usuari experi-
mentat).
Atès que les CUI són adequades per a usuaris experts, cal considerar la
possibilitat d’incloure CUI en les interfícies, com a alternativa d’altres
possibilitats més adreçades a usuaris inexperts.
2.7.2. Interfície de menús
Un menú és una llista d’opcions que es mostren a la pantalla o en una fi-
nestra de la pantalla per tal que els usuaris escullin l’opció que vulguin.
Els menús permeten:
• Navegar per la interfície.
• Seleccionar accions que cal fer sobre els objectes.
Les interfícies de menús apareixen quan l’ordinador passa de ser una eina ex-
clusiva del programador o de l’expert informàtic a ser una eina d’usuari final.
Tenim diversos tipus de menús:
1) Menús de pantalla completa
És el característic en antics entorns mainframe (grans sistemes) i en MS-
DOS, fins i tot en el gran UNIX. Actualment és imprescindible en molts
jocs, ja que la seva utilització dels recursos fa inviable l’ús d’un altre tipus
d’interfície.
En la figura 34 es veu una mostra d’aquest tipus de menús en el qual es
configura la BIOS.
Anàlisi i disseny d’aplicacions informàtiques 47 Disseny estructurat d’aplicacions
Figura 34. Configuració BIOS que utilitza menú de pantalla completa
2) Menús de barra
Situats a la part superior (normalment) de la pantalla, com es pot veure
en la figura 35.
Si cada opció dóna pas a un menú desplegable, aquest s’anomena menú debarres desplegables que poden contenir noves opcions, que poden donar
pas a accions o a altres menús desplegables.
Els menús de barra, i desplegables, poden canviar dinàmicament i conte-
nir opcions habilitades i accions deshabilitades en funció del context o de
les preferències dels usuaris.
3) Paletes o barres d’eines
Són menús gràfics, en què hi ha icones en lloc de paraules. Això facilita la
inclusió al menú de moltes opcions, que ocuparien més espai si fossin ex-
pressades mitjançant text.
Aquestes paletes poden ser flotants (ser col·locades al lloc de la pantalla
que vulgui l’usuari i estar a la vista o no en funció de les seves preferèn-
cies), com es pot veure en la figura 36.
Figura 36. Barra d’eines
Figura 35. Menú de barra
Anàlisi i disseny d’aplicacions informàtiques 48 Disseny estructurat d’aplicacions
4) Menús contextuals
Depenen exclusivament de les característiques concretes de l’objecte que
es tracta en cada moment. Tècnicament, es tracta d’un menú en cascada,
però les seves opcions variaran depenent de l’entorn, de l’objecte sobre el
qual actua i del moment. Se’n pot veure un exemple en la figura 37.
Recomanacions que cal tenir en compte a l’hora de dissenyar menús:
• No ocupar gaire espai en pantalla.
• Recordar la informació acumulada en menús precedents.
• No mostrar gaires elements de menú (utilitzar agrupacions homogèni-
es).
• Tenir cura de la terminologia per a cada opció de menú.
• Permetre que l’usuari personalitzi les opcions de menú.
2.7.3. Interfície gràfica
La primera implantació de la interfície gràfica (GUI, graphic user inter-
face) va venir de la mà de Xerox (1981) i, posteriorment, va ser popularit-
zada per Apple. Es basa en el concepte de WYSIWYG (what you see is
what you get, ‘el que veus és el que tens’), de manera que la funcionalitat
d’una aplicació quedi totalment definida només mirant-la per sobre.
Tot i la senzillesa de comprensió d’aquest tipus d’interfícies, no són gaire
apreciades pels professionals, que les consideren excessivament lentes.
Hi ha casos en què es disposa d’una interfície paral·lela per línia d’ordres
per a usuaris més experts.
En podem destacar com a principals avantatges els següents:
• Acostumen a ser fàcils d’entendre. Normalment l’objecte gràfic ha de
ser familiar a l’usuari i estarà relacionat amb el món real, utilitzant me-
tàfores.
• També és habitual que siguin multitasca, mitjançant la percepció de la
informació en diferents finestres i representada per diferents objectes.
I com a desavantatges, en podem destacar:
• Consumeixen molta més memòria i CPU que les CUI i s’han d’utilitzar
monitors gràfics d’alta resolució.
• Impliquen l’ús d’una bona targeta de vídeo.
Figura 37. Menús contextuals
Interfície gràfica que representa unacalculadora.
Anàlisi i disseny d’aplicacions informàtiques 49 Disseny estructurat d’aplicacions
Una característica important és que la GUI permet manipular els objectes
i informació de la pantalla, no solament presentar-la. !
Per fer servir una GUI, els usuaris han de conèixer una sèrie de conceptes:
organització del sistema (fitxers, directoris...), diferents tipus d’icones i
efecte de les accions sobre ells (com es veu en la figura 38), elements bà-
sics d’una finestra, ús dels controls de la GUI, ús del ratolí, etc.
Figura 38. Icones utilitzades habitualment en interfícies gràfiques
També han aparegut interfícies orientades a l’objecte (object oriented
user interfaces, OOUI). Es poden considerar dins les GUI i el principal ob-
jectiu és que l’usuari es concentri en les feines en lloc de concentrar-se en
la manera en què ha d’utilitzar l’ordinador, les aplicacions...
L’estil d’interacció de les OOUI és el d’objecte-acció (igual que en les GUI).
Per exemple, la finestra és un objecte finestra, no una finestra d’aplicació;
desapareixen, doncs, els menús de barra i guanyen terreny els contextu-
als, és a dir, finestres diferents tindran opcions diferents.
La construcció d’interfícies es faria mitjançant la utilització de controls
objectes com, per exemple:
• Contenidors (Form, Frame, Panel, etc.).
• Botons (Button).
• Caixes de text (TextField).
• Caixes de verificació (CheckBox).
• Botons de ràdio (RadioButton).
• Etiquetes (Label).
• Imatges (Image).
• Llistes desplegables (ComboBox).
• Etc.
Interfícies a Windows
La interfície de Windows se centra en la presentació d’informació a l’usuari
mitjançant finestres, en les quals s’executen aplicacions o simplement es
mostra informació de manera interactiva.
Anàlisi i disseny d’aplicacions informàtiques 50 Disseny estructurat d’aplicacions
L’organització de la informació es fa mitjançant l’emmagatzematge de da-
des en arxius de diferents tipus (imatges, documents, sons, etc.) que agru-
pa en carpetes segons el criteri de l’usuari.
Interfícies en Unix/Linux
Encara que són similars a les de Windows com es veu en la figura 39, en
referència a la interactivitat, la veritat és que n’hi ha prou amb un primer
cop d’ull per saber que no som a Windows. Presenten un aspecte molt par-
ticular, potser perquè estan desenvolupades per dissenyadors no professio-
nals, la qual cosa fa que la interfície sembli molt propera als usuaris.
Figura 39. Interfície gràfica de Linux
Interfícies web
Totes les interfícies per al web estan destinades a ser executades en els
navegadors o browsers com Internet Explorer de Microsoft, Opera, Mozi-
lla, Firefox, Nautilus, i un llarg etcètera, fins i tot n’hi ha de desenvolupats
per alguns programadors per al seu ús personal.
Les interfícies per al web acostumen a tenir una gran quantitat de compo-
nents gràfics, però han de tenir un pes reduït, és a dir, imatges i recursos
de mida més petita per facilitar-ne la transmissió i evitar grans retards en
la càrrega de la pàgina. Hi ha una oferta de multitud de plantilles de dis-
seny de pàgines que podem descarregar i utilitzar lliurement.
Sobre els diferents navegadors, les interfícies web no presenten grans di-
ferències, si bé cada navegador té les seves peculiaritats que decideixen
les preferències dels usuaris.
Imatge del logotip de Windows
Imatge del logotip de Linux
Anàlisi i disseny d’aplicacions informàtiques 51 Disseny estructurat d’aplicacions
Podem observar també en la figura 40 l’ús conjunt de botons i enllaços per
accedir a determinades pàgines. A vegades, es poden utilitzar diversos ob-
jectes o enllaços per arribar a una mateixa pàgina. El que sí sembla gaire-
bé estàndard en els llocs web és l’aparició de menús d’opcions, tant si se
situen en un marge com si ho fan a la part superior, el funcionament dels
quals és sempre el mateix, i això fa que el visitant es mogui amb certa sol-
tesa.
Figura 40. Interfície web típica
Algunes pàgines es basen en la senzillesa i en la facilitat d’ús; d’altres, en
canvi, són molt més sofisticades i pretenen cridar l’atenció de l’usuari.
Per crear pàgines web es fan servir diferents tècniques, entre les quals po-
dem destacar l’ús de fulls d’estil CSS (cascade style sheets) mitjançant els
quals és possible canviar l’aspecte d’una pàgina fàcilment; a més a més, es
poden fer diferents configuracions de presentació segons les preferències
dels usuaris.
2.8. El futur de les interfícies
El futur de les interfícies encara ha d’arribar, tot i que ja van apareixent
alguns dispositius nous, com els que permeten controlar el punter del ra-
tolí amb el moviment dels ulls, la qual cosa permet prescindir de les mans
per fer anar un ordinador.
També estan cada vegada més implantats els dispositius sintetitzadors de
veu (mitjançant els quals la màquina ens pot parlar) i els de reconeixe-
ment de patrons de veu (mitjançant els quals la màquina és capaç d’“en-
tendre” el que diem). Fins i tot alguns jocs d’última generació permetenCada vegada més s'utilitzen interfícies quedetecten el moviment davant una càmera.
Anàlisi i disseny d’aplicacions informàtiques 52 Disseny estructurat d’aplicacions
la participació del jugador mitjançant moviment davant una càmera, de
manera que s’activen determinades zones de la pantalla del lloc amb el
moviment.
Segons els experts, les tendències auguren línies d’evolució ben definides:
• Entorns que simulen la realitat (realitat virtual).
• Màquines més semblants a l’ésser humà. Que segueixen els mateixos
patrons deductius i que es comuniquen d’una manera humana.
Els entorns del futur constaran d’escenes, sons i camps tàctils sintetitzats,
reaccionaran a més a ordres i peticions explícites, a estats d’ànim i tem-
perament. Representacions d’informació que reaccionen a les caracterís-
tiques sensorials, preferències, habilitats i necessitats de cada individu.
Finalment, els experts en aquest terreny, reconeixen quatre línies de re-
cerca:
• Reconeixement de caràcters.
• Síntesi de veu.
• Reconeixement de veu.
• Processament d’imatges.
• Etc.
Cinema
Res millor que el cinema per descobrir interfícies noves i increïbles. En el cinema realment estem veient interfícies increïbles que és possible que en algun moment puguin veure la llum com a elements útils de la comunicació entre la persona i la màquina.
Hi ha moltes pel·lícules, sobretot de ciència-ficció (i especialment les de naus espacials), en les quals es presenten màquines complexes que es controlen d’una manera molt fàcil amb interfícies extraordinàries.
Podeu veure molts articles sobre el reconeixement de veu a la Viquipèdia.
Anàlisi i disseny d’aplicacions informàtiques 53 Disseny estructurat d’aplicacions
3. Prova i documentació
En el desenvolupament del programari les possibilitats d’error són innu-
merables. Els errors es poden produir per una mala especificació dels re-
quisits funcionals, una selecció incorrecta dels mètodes de resolució,
errors en enllaçar mòduls, errors en la documentació.
Per tot això el desenvolupament del programari ha d’anar acompanyat
d’alguna activitat que garanteixi la qualitat de les aplicacions. La prova és
un element crític per garantir la qualitat del programari.
Errors de disseny
Quan parlem de proves de programari solem pensar a trobar errors en els programes, però moltes
vegades són errors de disseny. Si un programa emmagatzema la data en una variable de 32 bits
no es pot dir que funcioni malament o que tingui errors, però succeirà que no podrà funcionar més
enllà del 2038 i serà un problema de disseny i no un error de programari. Per tant, veiem que si
volem evitar errades hem de revisar el programari en tot el seu procés i no solament en la progra-
mació. Això vol dir que les proves de programari s’han de fer al llarg de tot el cicle de vida del pro-gramari.
Segons certs estudis, un error que no es detecta a l’inici del cicle de vida, necessitarà cinquanta
vegades més d’esforç per solucionar-lo si és detectat després de tenir el programa implementat.
La prova i validació dels resultats no és només un procés que es duu a ter-
me una vegada desenvolupat el programari, sinó que s’ha d’efectuar en ca-
dascuna de les etapes prèvies a la codificació: en la fase d’especificació de
requisits, anàlisi i disseny.
En la fase de prova es verifica i es valida que el sistema faci el que ha de
fer i que a més a més ho fa bé, és a dir, eficaçment i eficientment. Les pro-
ves recorren el camí invers a l’anàlisi i al disseny top-down: van del més
petit (proves unitàries) al més gran (proves d’integració), del més concret
(prova de subsistema) al més general (prova de sistema).
Quan un sistema ja s’ha provat, es passa a la fase d’instal·lació, en la qual
s’implanta en el seu entorn real, a les màquines del client. I s’han d’em-
plenar les bases de dades del sistema amb dades reals.
Després hi ha la fase de manteniment, en què hi ha d’haver documentació
de les proves que inclogui els casos de prova i els resultats. Si es fan mo-
dificacions en el programa s’ha de tornar a provar.
Abans de començar a detallar com funciona el procés de prova d’una apli-
cació, cal tenir clars una sèrie de conceptes. Alguns autors diferencien en-
Anàlisi i disseny d’aplicacions informàtiques 54 Disseny estructurat d’aplicacions
tre fallada, error i defecte, encara que les diferències són només petits
matisos:
• Defecte: imperfecció que es produeix quan en un programa hi ha un
procés, una definició de dades o un processament incorrecte. Per
exemple, si en un programa emmagatzemen dades amb decimals en
una variable sencera podrem provocar que el programa deixi de funci-
onar. El defecte és en el producte dissenyat.
• Error: és la manifestació del defecte quan s’executa el sistema, però un
error es pot produir perquè hi havia defectes en el producte o pot ocór-
rer per altres situacions, com quan un ús inadequat del programa pro-
voca que el sistema no funcioni bé. Per exemple, un error pot ocórrer
quan un operador introdueix dades incorrectes. El problema no és tant
del programador (no hi ha defectes), sinó de l’operador que no usa el
programa correctament segons les instruccions donades. L’error es
produeix quan executem el programari i en fem ús.
• Fallada: quan en un programa hi ha defectes o errors i el sistema no
funciona com caldria, diem que s’ha produït una fallada, per exemple
quan l’ordinador queda bloquejat amb una pantalla en blau. La fallada
indica que hi ha una desviació entre els requisits o necessitats de l’usuari
i el producte elaborat.
• Un bon cas de prova és aquell que té una alta probabilitat de descobrir
un error no trobat fins llavors.
• Una prova té èxit si descobreix un error no detectat fins llavors.
• Les proves no poden assegurar l’absència de defectes.
• No solament es prova el codi sinó també la documentació i ajuda.
• Per ser més efectives les proves haurien de ser conduïdes per un equip
independent.
• El principi de Pareto és aplicable a la prova del programari (“on hi ha
un defecte, n’hi ha d’altres”).
La prova és el procés d’execució d’un programa amb la intenció
de descobrir un error.
Plans de prova són cadascuna de les proves a què se sotmet cada
element de programari desenvolupat.
Curiositat
El cost aproximat dels errors del programari (bugs) per a l’economia americana és l’equivalent al 0,6% del seu PIB, uns 60.000 milions de dòlars (NIST, National Institute of Standards and Technology, 2002).
Més d’una tercera part es podrien evitar si s’efectuessin millor les proves.
Anàlisi i disseny d’aplicacions informàtiques 55 Disseny estructurat d’aplicacions
Hi ha dos conceptes que cal diferenciar i entendre amb relació a les pro-
ves: verificació i validació.
Hem vist el concepte de prova, però no solament n’hi ha prou de compro-
var que el programa obtingui resultats correctes, també cal assegurar-se
que compleix les necessitats de l’usuari. Per exemple, un Rolls-Royce és
un cotxe que sens dubte passaria les proves més exigents sobre els últims
detalls de la seva mecànica o la seva carrosseria. Però si el client vol un tot
terreny, difícilment se’l comprarà. D’una manera equivalent, en el món
informàtic, si escrivim un programa per ordenar dades per ordre ascen-
dent, però el client les necessita en ordre decreixent, no serem capaços de
detectar l’error buscant errors de programació, hem de revisar l’anàlisi
dels requisits que es va fer.
Per tant, la comprovació del programari ha d’incloure dos aspectes:
• Estem elaborant correctament el programari? Al llarg del cicle de vida
hem de comprovar que cada producte intermedi obtingut satisfaci les
condicions previstes. El procés que comprova aquest aspecte es deno-
mina verificació de programari.
• Estem elaborant el programari correcte? És a dir, el producte final
compleix els requisits inicials i les necessitats del client. El procés que
comprova aquest aspecte es denomina validació de programari.
Les proves en el cicle de vida
Les proves efectuades al llarg de tot el cicle de vida permeten validar i ve-
rificar el programari. En l’esquema de la figura 41, podem veure com en-
caixen les proves en el cicle de vida del programari.
Figura 41. Cicle de vida en V: fases de prova
El cas de la xinxa
En anglès els defectes i errors de programació es diuen computer bug. Literalment bug significa ‘xinxa’ i el motiu d’usar aquesta paraula sembla que es deu a la programadora Grace Murray Hopper, una pionera en la història de la computació desenvolupadora del llenguatge Cobol i que treballant amb la computadora Mark II a la Universitat de Harvard el 1947, els enginyers van trobar una xinxa enganxada a un dels circuits de l’ordinador que n’impedia el funcionament. Aquest insecte va passar a la història de la informàtica per ser enganxada en el llibre de registre d’activitat de l’ordinador (tal com apareix en la imatge), amb el comentari First actual case of bug being found (‘primer cas real de xinxa trobat’).
Anàlisi i disseny d’aplicacions informàtiques 56 Disseny estructurat d’aplicacions
Alhora que s’avança en el desenvolupament del programari es van plani-
ficant les proves que es faran en cada fase del projecte. Aquesta planifica-
ció es concretarà en un pla de proves que s’aplicarà a cada producte
desenvolupat. Quan es detecten errors en un producte s’ha de tornar a la
fase anterior per depurar-lo i corregir-lo; això s’indica amb les fletxes de
tornada de la part esquerra de la figura.
Hi ha eines CASE que ajuden a dur a terme aquests processos de prova;
concretament, les encarregades de depurar errors en els programes es co-
neixen com a debuggers (‘eliminació d’insectes’).
Com veiem en la figura 41 el procés de verificació cobrirà les fases de dis-
seny i implementació del producte. Les persones implicades en la seva
execució seran els desenvolupadors o programadors i l’enginyer de pro-
ves. Els desenvolupadors faran proves sobre el codi i els diferents mòduls
que l’integren, i l’enginyer sobre el disseny del sistema.
Avaluar si el producte desenvolupat acompleix els requisits establerts en
l’anàlisi es denomina validació. Les persones encarregades de fer les pro-
ves de validació són els enginyers de proves.
Finalment, el client ha de donar el vistiplau al producte, raó per la qual es
faran les proves d’acceptació en funció de les condicions que es van signar
al principi del contracte.
Recomanacions per al desenvolupament de les proves
Partint que mai no podem estar segurs si un sistema fallarà, per estar se-
gurs que el sistema no fallarà l’hauríem de provar en totes les condiciones
i situacions, amb totes les entrades possibles i fent ús de tota la funciona-
litat. És això possible?
Imaginem un programa senzill que ens diu si una persona és major o me-
nor d’edat. En el programa introduïm una edat i el sistema respon que és
major d’edat si el seu valor és més gran o igual que 18 anys. El programa
es pot veure en la figura 42.
Per provar el programa podríem introduir una edat de 10 anys i funcio-
naria bé, una altra edat de 25 anys i funcionaria bé també. Però això no
seria suficient perquè hi ha moltes més opcions, i podríem provar a in-
troduir lletres a veure si detecta l’error, o també podríem provar amb
xifres negatives o molt grans. En realitat, el nombre d’entrades possi-
bles tendeix a infinit.
Anàlisi i disseny d’aplicacions informàtiques 57 Disseny estructurat d’aplicacions
Figura 42. Programa de càlcul n > 18
Per tant, podem dir que les proves exhaustives no són possibles.
Hauríem de seguir una sèrie de recomanacions dels experts sobre com
s’han de fer les proves:
• Les proves s’han de dissenyar de manera que tinguin la màxima proba-
bilitat de trobar el nombre més gran d’errors amb la mínima quantitat
d’esforç i temps.
• Les proves s’han de centrar i insistir més en les parts o mòduls que
més s’utilitzen o siguin més crítics per al sistema.
• No s’ha de veure el procés de prova com a rutinari, sinó com un procés
fonamental; per això, s’hi han de destinar recursos, temps, personal ex-
perimentat i un procés creatiu.
• No s’ha d’associar l’error a negligència d’un programador; la finalitat
de les proves ha de ser trobar errades i no desprestigiar ningú.
• El programador no ha de provar els seu propis programes. A les grans
empreses hi ha un equip de prova diferent del de desenvolupament.
• Els casos de prova han d’incloure tant entrades correctes com incorrec-
tes per avaluar el comportament del sistema en qualsevol situació.
3.1. Tipus de proves
Hi ha diferents tipus de proves que es fan en el sistema. Segons el mo-
ment de realització, hi ha:
1) Proves unitàries (de mòduls individuals)
Components de prova
Com que el procés de prova pot ser repetitiu i laboriós, és possible automatitzar alguns processos de manera que els procediments de prova es puguin fer amb l’ajuda de programari. Aquest programari ha de ser preparat i rep el nom de components de prova. La seva utilització és molt freqüent en les proves d’integració.
Anàlisi i disseny d’aplicacions informàtiques 58 Disseny estructurat d’aplicacions
Depenent de com es duguin a terme tenim:
• Proves de caixa negra. Comproven el funcionament d’un component
programari per mitjà de la seva interfície, sense entrar-ne a veure el
funcionament intern.
• Proves de caixa blanca o transparent. Comproven la manera com un
component programari resol un problema determinat atenent als de-
talls interns d’implementació.
• Revisions.
2) Proves d’integració.
3) Proves d’acceptació.
3.1.1. Les proves de caixa blanca
Figura 43. Estructura de les proves de caixa blanca
Per exemple, imaginem un mòdul d’un programa que registra vendes d’im-
mobles. Les proves de caixa blanca ens permetran recórrer tots els possi-
Les proves unitàries es defineixen com el procediment per pro-
var el funcionament correcte d’un mòdul de codi. Això serveix
per assegurar que cadascun dels mòduls funcioni correctament
per separat.
Les proves de caixa blanca (figura 43) se centren en la implemen-
tació dels programes per escollir els casos de prova. L’ideal seria
cercar casos de prova que recorrin tots els camins possibles del
flux de control del programa. Fan un examen minuciós dels de-
talls procedimentals per comprovar els diferents camins lògics
del programari, mitjançant els casos de prova que els recorren.
Anàlisi i disseny d’aplicacions informàtiques 59 Disseny estructurat d’aplicacions
bles camins del codi i veure què succeeix en cada cas possible. Provarem què
ocorre amb les condicions i els bucles que s’executen i provarem amb dades
que garanteixin que han tingut lloc totes les combinacions possibles per a
aquestes condicions i bucles (introduint immobles ja venuts o dels quals el
client no sigui propietari, o en què tot sigui correcte, juntament amb altres
en què el preu sigui incorrecte, etc.). I per decidir quins valors prendre ne-
cessitem saber com està fet el codi perquè no quedi cap racó sense executar.
Les proves de caixa blanca es dissenyen a partir del codi del programa que
volem provar. El seu objectiu és assegurar que tots els components in-
terns han estat provats adequadament. !
Partint que les proves exhaustives són impracticables, ja que el nombre de
combinacions és excessiu, hem de dissenyar estratègies que ens ofereixin
una seguretat acceptable per descobrir errors. Els mètodes que veurem
dintre de les proves de caixa blanca són els de cobertura de flux de control
i el de complexitat ciclomàtica.
Cobertura de flux de control
El mètode de cobertura de flux de control consisteix a utilitzar l’estructura
de control del programa per obtenir els casos de prova, que són dissenyats
de manera que garanteixin que almenys es passa una vegada per cada
camí del programa.
Figura 44. Diagrama amb camí simple, bucle i condició
Anàlisi i disseny d’aplicacions informàtiques 60 Disseny estructurat d’aplicacions
Una possible tècnica per portar a terme aquest mètode es mostra en la fi-
gura 44 i consisteix a obtenir un diagrama de flux de control que represen-
ti el codi i provar tots els camins simples, totes les condicions i tots els
bucles del programa.
Pot ser impossible cobrir-ne el 100% si el programa és molt complex, però
podem tenir un mínim de garanties d’eficàcia si seguim els suggeriments
per dissenyar els casos de prova fixant-nos en aquests elements:
1) Camí simple: hem de dissenyar un cas de prova per cada camí indepen-
dent, de manera que executi almenys una vegada cada sentència. Per a
això és necessari determinar els possibles camins independents i prepa-
rar prou casos de prova per recórrer tots els camins (figura 45).
2) Condicions: hem de dissenyar prou casos de prova per a totes les con-
dicions del programa que s’avaluen a cert/fals. Si les condicions són múl-
tiples, les haurem de dividir en expressions simples (una per cada
operand lògic o comparació), de manera que s’ha de provar que es com-
pleixi o no cada part de cada condició (figura 46).
Figura 46. Estructures de condicions IF i CASE
3) Bucles: hem de dissenyar casos de prova de manera que s’intenti exe-
cutar un bucle en diferents situacions límits.
Figura 47. Estructures de bucle DO WHILE i WHILE
Cal distingir dos tipus de bucles:
• En bucles simples, cal aplicar-hi les proves:
– No s’executi (0 vegades).
– Passar una vegada.
Figura 45. Estructura de seqüència
Anàlisi i disseny d’aplicacions informàtiques 61 Disseny estructurat d’aplicacions
– Passar dues vegades.
– Passar j vegades amb j < n, en què n és el nombre màxim de passos
permesos.
– Passar n – 1, n, n + 1 vegades pel bucle.
• En bucles niats:
– Començar amb el bucle més interior. La resta es deixa en valors mí-
nims.
– S’apliquen les proves de bucles simples al bucle més interior, mentre
es mantenen els bucles exteriors en els valors mínims. Afegir altres
proves per als valors fora de rang o per a valors exclosos.
– Progressar cap a fora, portant a terme les proves per al bucle se-
güent, mantenint els bucles exteriors en els valors mínims i els inte-
riors en els valors típics.
– Repetir el procés fins que tots els bucles s’hagin provat.
Vegem un parell d’exemples de bucles:
For (comptador=0; comptador 10; comptador ++).....
S’haurien de dissenyar casos de prova per intentar executar el cicle el se-
güent nombre de vegades: 0, 1, 9, 10, 11.
While (control == false)..........
S’haurien de dissenyar casos de prova per intentar executar el cicle el se-
güent nombre de vegades: 0, 1, 5 (suposant que 5 és un nombre habitual
de vegades).
N’hi hauria prou amb una prova exhaustiva de caixa blanca?
Veurem, amb un programa com a exemple, que no n’hi ha prou:
INICIIF (X+Y+Z)/3=X THENPrint (“X,Y,Z són iguals”)ELSEPrint (“X,Y,Z no són iguals”);FI
Aquest programa no funciona sempre.
Els casos de prova que hem preparat amb aquest mètode són:
Cas 1: X = 5, Y = 5, Z = 5
Cas 2: X = 2, Y = 3, Z = 7
Anàlisi i disseny d’aplicacions informàtiques 62 Disseny estructurat d’aplicacions
Aquests casos de prova no detecten cap errada. O sigui que les proves de
caixa blanca no són suficients.
Complexitat ciclomàtica
L’estratègia de cobertura de flux de control requereix dissenyar casos de
prova suficients per recórrer tota la lògica del programa. Sabem de quants
casos estem parlant? Com es calcula?
El matemàtic McCabe va anomenar el nombre de camins independents
d’un diagrama de flux complexitat ciclomàtica (CC), i va proposar la fór-
mula següent per calcular-la:
Figura 48. Diagrama de flux de dades
Com es veu en la figura 48 els nodes serien 1, 2, 3, 4, 5, 6 i 7 i les branques
són les línies que uneixen els nodes que són 7. O sigui que la complexitat
ciclomàtica seria: CC = 7 – 7 + 2 = 2.
Els diferents camins independents són:
• 1, 2, 3, 4
• 1, 2, 3, 5, 6, 7
Per aplicar la fórmula és necessari que les condicions múltiples hagin es-
tat descompostes en expressions simples. La complexitat ciclomàtica ens
Complexitat ciclomàtica = nre. de branques – nre. de nodes + 2
Anàlisi i disseny d’aplicacions informàtiques 63 Disseny estructurat d’aplicacions
diu el nombre de camins independents que té el diagrama que representa
el programa, i s’haurà de dissenyar un cas de prova per cada camí indepen-
dent. La complexitat ciclomàtica només té en compte una única execució
dels bucles, és a dir, si volem provar-los 0, n – 1, n i n + 1 vegades cal afegir
més casos de prova. Una complexitat ciclomàtica superior a 10 pot indicar
que el programa és massa complicat i potser s’hauria de modificar i fer-lo
més simple.
Perquè s’entengui millor podem analitzar la figura 44. En el diagrama tin-
dríem una complexitat ciclomàtica de tres: CC = 13 – 12 + 2 = 3. Això sig-
nifica que hauríem de dissenyar tres casos de prova. Així, els tres
recorreguts que s’haurien de tenir en compte són:
• 1, 2, 3, 4, 5, 8, 9, 11, 12
• 1, 2, 3, 4, 5, 8, 10, 11, 12
• 1, 2, 3, 4, 5, 6, 7
Figura 49. Programa Netbeans amb l’opció de depuració
Per veure el resultat de les proves i comprovar que efectivament s’estan
recorrent aquests nodes hauríem de crear un mecanisme que ens serveixi
de guia. Una solució simple seria afegir al codi sentències de sortida per
pantalla que tinguin indicacions de valors de variables, punts del progra-
Anàlisi i disseny d’aplicacions informàtiques 64 Disseny estructurat d’aplicacions
ma (nodes) que s’estan executant o avaluacions de les condicions, etc.
Però això obliga a modificar el codi. Una solució molt millor és utilitzar ei-
nes CASE d’ajuda com el depurador o debugger. La majoria dels entorns
integrats de desenvolupament, com, per exemple, NetBeans, inclouen ei-
nes de depuració per a aquest fi. En la figura 49 podem veure un exemple
de Netbeans amb l’opció de debug.
3.1.2. Les proves de caixa negra
Figura 50. Estructura de les proves de caixa negra
Per aconseguir-ho s’han dissenyat diferents tècniques:
• Classes d’equivalència: es tracta de determinar els diferents tipus d’en-
trada i sortida, agrupar-los i escollir casos de prova per cada tipus o con-
junt de dades d’entrada i sortida.
• Anàlisi dels valors límit: estudien els valors inicials i finals, ja que es-
tadísticament s’ha demostrat que tenen més tendència a detectar er-
rors.
• Estudi d’errors típics: l’experiència ens diu que hi ha una sèrie d’errors
que s’acostumen a repetir en molts programes, es tractaria de disse-
nyar casos de prova que provoquessin les situacions típiques d’aquest
tipus d’errors.
Les proves de la caixa negra (figura 50) proven la funcionalitat
del programa per al qual es dissenyen casos de prova que compro-
vin les especificacions del programa.
Hem d’escollir amb cura els casos de prova de manera que siguin
tan pocs com sigui possible, perquè la prova es pugui executar en
un temps raonable, i al mateix temps cobreixin la varietat d’en-
trades i sortides més àmplia possible.
Anàlisi i disseny d’aplicacions informàtiques 65 Disseny estructurat d’aplicacions
• Maneig d’interfície gràfica: per provar el funcionament de les interfí-
cies gràfiques s’han de dissenyar casos de prova que permetin desco-
brir errors en el maneig de finestres, botons, icones, etc.
• Dades aleatòries: es tracta d’utilitzar una eina que automatitzi les proves
i que generi d’una manera aleatòria els propis casos de prova. Aquesta
tècnica no optimitza l’elecció dels casos de prova, però si es fa durant
prou temps amb moltes dades, podrà arribar a fer una prova bastant
completa. Aquesta tècnica es podria usar com a complementària a les
anteriors o en casos en què no sigui possible aplicar-ne cap altra.
Un avantatge de les proves de caixa negra és que són independents del
llenguatge o paradigma de programació utilitzat, de manera que són vàli-
des tant per a programació estructurada com per a programació orientada
a objectes. !
Classes d’equivalència
Hem de dissenyar els casos de prova de manera que provin la major fun-
cionalitat possible del programa, però que no incloguin massa valors. Per
on comencem? Quins valors escollim?
Hem de seguir els passos següents:
1) Identificar les condicions, restriccions o continguts de les entrades i
les sortides.
2) Identificar a partir de les condicions les classes d’equivalència de les
entrades i sortides. Per identificar-ne les classes el mètode proposa algu-
nes recomanacions:
a) Cada element de classe ha de ser tractat pel programa de la mateixa
manera, però cada classe ha de ser tractada de manera diferent respecte
a una altra classe. Això assegura que n’hi ha prou de provar algun element
d’una classe per comprovar que el programa funciona correctament per a
aquesta classe, i també garanteix que cobrim diferents tipus de dades
d’entrada amb cadascuna de les classes.
b) Les classes han de recollir tant dades vàlides com errònies, ja que el
programa ha d’estar preparat i no bloquejar-se per cap circumstància.
c) Si s’especifica un rang de valors per a les dades d’entrada (per exem-
ple: si s’admet del 10 al 50), es crearà una classe vàlida (10 x 50) i dues
Anàlisi i disseny d’aplicacions informàtiques 66 Disseny estructurat d’aplicacions
classes no vàlides, una per als valors superiors (x > 50) i l’altra per als in-
feriors (x < 10).
d) Si s’especifica un valor vàlid d’entrada i d’altres de no vàlids (per exem-
ple, l’entrada comença amb majúscula), es crea una classe vàlida (amb la
primera lletra majúscula) i una altra de no vàlida (amb la primera lletra
minúscula).
e) Si s’especifica un nombre de valors d’entrada (per exemple, s’han d’in-
troduir tres nombres seguits), es crearà una classe vàlida (amb tres va-
lors), i dues de no vàlides (una amb menys de dos valors i l’altra amb més
de tres valors).
f) Si hi ha un conjunt de dades d’entrada concretes vàlides es generarà
una classe per cada valor vàlid (per exemple, si l’entrada ha de ser ver-
mell, taronja, verd es generaren tres classes) i una altra per un valor no
vàlid (per exemple, blau).
g) Si no s’han recollit ja amb les classes anteriors, s’ha de seleccionar una
classe per cada possible classe de resultat.
3) Crear els casos de prova a partir de les classes d’equivalència detecta-
des. Per a això s’han de seguir els passos següents:
a) Escollir un valor que representi cada classe d’equivalència.
b) Dissenyar casos de prova que incloguin els valors de totes les classes
d’equivalència identificades.
L’experiència prèvia de l’equip de proves pot ajudar a escollir els casos que
més probabilitats tenen de trobar errors.
Exemple d’aplicació de classes d’equivalència
Imaginem que hem d’elaborar els casos de prova per a un programa que
efectua l’adjudicació d’habitatges subvencionats aplicant la tècnica de
classes d’equivalència.
El programa ha de guardar les puntuacions del barem d’una sèrie de sol·li-
citants d’habitatges i ens ha de dir si han resultat beneficiaris o no de l’ad-
judicació d’un habitatge subvencionat. Els habitatges seran subvencionats
si el barem és igual o superior a 5. El programa admet com a entrada el
DNI i un nombre entre 0 i 10 sense decimals.
Anàlisi i disseny d’aplicacions informàtiques 67 Disseny estructurat d’aplicacions
El primer que s’ha de fer és determinar les classes d’equivalència. Per fer-
ho hem d’analitzar les entrades del programa:
1) Sabem que el DNI es compon de manera general de vuit xifres numè-
riques i una lletra, encara que alguns DNI antics tenen set xifres. És a dir,
en total la longitud vàlida serà de vuit o nou caràcters. Això genera aques-
tes classes:
• Dues classes vàlides: l’una amb vuit caràcters i l’altra amb nou.
• Dues classes no vàlides: l’una amb set o menys caràcters i l’altra amb
deu o més.
2) Si ens fixem en la combinació de lletres i nombres les classes seran:
• Dues classes vàlides: l’una amb set xifres i una lletra i l’altra amb vuit
i la lletra; coincideixen amb les anteriors, per la qual cosa no fa falta
repetir-les.
• Dues classes no vàlides: qualsevol combinació diferent de vuit i nou xi-
fres.
3) Pel que fa a la puntuació en el barem, si ens fixem en el rang, tenim les
classes següents:
• Una de vàlida: amb un valor entre zero i deu.
• Dues amb dades no vàlides: una amb un valor negatiu i una amb un va-
lor superior a deu.
4) Si ens fixem en els decimals de la puntuació en el barem tenim:
• Una classe no vàlida: un nombre entre zero i deu amb decimals.
5) Hem d’estudiar també la sortida que pot ser persona beneficiada
amb habitatge o no beneficiada, la qual cosa genera dues possibles
classes:
• Una classe amb una puntuació amb barem inferior a cinc i una altra
amb més de cinc (en realitat una de les classes pot coincidir amb l’an-
terior; per això només cal afegir-hi una nova classe).
Resumirem en la taula 4 les classes, que etiquetarem amb un nombre per
facilitar-ne la identificació.
Anàlisi i disseny d’aplicacions informàtiques 68 Disseny estructurat d’aplicacions
Taula 4. Resum de classes
Ara cal determinar els casos de prova vàlids a partir de les classes d’equi-
valència anteriors. Els veurem en la taula 5.
Taula 5. Casos de proves vàlides
Com podem observar en la taula 5, cada cas vàlid ha de cobrir tantes clas-
ses com sigui possible. En la taula 6 apareixen els casos no vàlids que han
de cobrir una i només una classe no vàlida.
Podem observar que algunes classes es comproven diverses vegades, però
això no és un problema, ja que és necessari per complir el concepte que
provin totes les classes vàlides i no vàlides (un cas per prova).
Taula 6. Casos de proves no vàlides
Anàlisi de valors límit i errors típics
Hi ha tècniques que ens serveixen per seleccionar millor les classes
d’equivalència. Així tenim l’anàlisi dels valors límit. Per què és una tècni-
ca adequada fixar-se especialment en els valors límit?
S’ha pogut demostrar que els casos de prova que se centren en els valors
límit produeixen un millor resultat per a la detecció de defectes. !
Condició Classes vàlides Classes no vàlides
DNI• Set xifres més una lletra (1)• Vuit xifres més una lletra (2)
• Menys de set caràcters (3) • Més de vuit caràcters (4)• Vuit caràcters que no siguin set
xifres més lletra (5)• Nou caràcters que no siguin vuit
xifres més lletra (6)
Puntuació en el barem
• Un valor x amb rang 0 x < 5 (7)• Un valor x amb rang 5 x 10 (8)
• Un valor < 0 (9)• Un valor > 10 (10)• Un valor amb decimals (11)
Casos de proves vàlidesDNI i puntuació barem
Classes d’equivalència cobertes
Resultat
1234567A 4 1,7 No adjudicada
12345678A 9 2,8 Adjudicada
Casos de proves no vàlidesClasses d’equivalència
cobertesResultat
123456A 2 3,7 Dada no vàlida
1234567890A 2 4,7 Dada no vàlida
1234ABC5 2 5,7 Dada no vàlida
ABCD12345 6 6,8 Dada no vàlida
1234567A –5 1,9 Dada no vàlida
1234567A 20 1,10 Dada no vàlida
1234567A 7,5 1,11 Dada no vàlida
Anàlisi i disseny d’aplicacions informàtiques 69 Disseny estructurat d’aplicacions
D’aquesta manera, en escollir l’element representatiu de la classe d’equi-
valència, en lloc d’agafar-ne qualsevol, s’escullen els valors al límit i un in-
termedi. A més a més, també s’intenta que els valors a l’entrada provoquin
valors límit als resultats.
A l’hora d’escollir els representants de cada classe se seguiran les recoma-
nacions següents:
• En els rangs de valors agafarem els extrems del rang i el valor inter-
medi.
• Si s’especifiquen una sèrie de valors, agafem el superior, l’inferior,
l’anterior a l’inferior i el posterior al superior.
• Si el resultat es mou en un determinat rang, hem d’escollir dades a l’en-
trada per provocar les sortides mínima, màxima i un valor intermedi.
• Si el programa tria una llista o taula, hem d’agafar l’element primer,
l’últim i l’intermedi.
Si apliquem aquest esquema a l’exemple en què hem d’elaborar els casos
de prova per a un programa que adjudica habitatges subvencionats, aquest
programa ha de guardar les puntuacions del barem d’una sèrie de sol·lici-
tants d’habitatges i ens ha de dir si han resultat beneficiaris o no de l’ad-
judicació d’un habitatge subvencionat. Els habitatges seran subvencionats
si el barem és igual o superior a 5. El programa admet com a entrada el
DNI i un nombre entre 0 i 10 sense decimals. En aquest exemple els casos
de prova podrien quedar com apareixen en les taules 7 i 8.
Taula 7. Casos de proves vàlides
Taula 8. Casos de proves no vàlides
També ens podem aprofitar de l’experiència prèvia. Sabem que hi ha una
sèrie d’errors que es repeteixen molt en els programes, i podria ser una
bona estratègia utilitzar casos de prova que se centrin a buscar aquests
errors. D’aquesta manera, millorarem l’elecció dels representants de les
classes d’equivalència.
Casos de proves vàlidesDNI i puntuació barem
Classes d’equivalència cobertes
Resultat
1234567A 0 1,7 No adjudicada
12345678A 10 2,8 Adjudicada
Casos de proves no vàlidesClasses d’equivalència
cobertesResultat
123456A –1 3,9 Dada no vàlida
1234567890A 11 4,10 Dada no vàlida
1234ABC5 7,5 5,11 Dada no vàlida
ABCD12345 5 6,8 Dada no vàlida
Anàlisi i disseny d’aplicacions informàtiques 70 Disseny estructurat d’aplicacions
Hem de seguir les recomanacions següents:
• El valor zero sol provocar errors, per exemple, una divisió per zero blo-
queja el programa. Si tenim la possibilitat d’introduir zeros en l’entra-
da els hauríem d’escollir en els casos de prova.
• Quan s’ha d’introduir una llista de valors ens hem de centrar en la pos-
sibilitat de no introduir cap valor, o introduir-ne un.
• Hem de pensar que l’usuari pot introduir entrades que no són normals,
per això és recomanable posar-se en el pitjor cas.
• Els desbordaments de memòria són habituals, per això hem provat
d’introduir valors tan grans com sigui possible.
Seguint aquestes recomanacions, podríem afegir un cas de prova a l'exem-
ple que estem tractant, en el qual l'entrada de dades estigui buida: la taula
de casos vàlids tindria una fila més, com es veu en la taula 9.
Taula 9. Casos de proves no vàlides
Ús d’interfície gràfica
No sols s’ha de parlar d’entrades de textos, també cal tenir en
compte els entorns gràfics en què introduïm aquestes entrades
de textos.
Penseu que és el mateix? Vegem-ho.
En els programes actuals, moltes vegades la interconnexió amb
la màquina se sol fer amb sistemes gràfics que cada vegada són
més complexos i per això poden generar errors.
Les proves d’interfície gràfica d’usuari han d’incloure:
• Proves sobre finestres: icones de tancar, minimitzar, etc.
• Proves sobre menús i ús de ratolí.• Proves d’entrada de dades: quadre de textos, llistes desplegables, etc.
• Proves de documentació i ajuda del programa.
Casos de proves no vàlidesClasses d’equivalència
cobertesResultat
123456A –1 3,9 Dada no vàlida
1234567890A 11 4,10 Dada no vàlida
1234ABC5 7,5 5,11 Dada no vàlida
ABCD12345 5 6,8 Dada no vàlida
12345678A 1 (puntuació barem buida) Dada no vàlida
Interfície gràfica del programa de retocsd’imatges Gimp
Anàlisi i disseny d’aplicacions informàtiques 71 Disseny estructurat d’aplicacions
Els casos de prova han d’incloure la revisió del funcionament de tots els ele-
ments anteriors, almenys, una prova per cada element.
Figura 51. Pantalla per al control d’entrada de nom i usuari a la sessió del programa GoldMine
En la figura 51 apareix una finestra que controla l’accés a un sistema mit-
jançant la introducció d’un nom d’usuari i una contrasenya (password). El
sistema comprova si hi ha un compte amb aquest nom i una contrasenya
i si és així es dóna permís per entrar. Si hi ha un compte amb aquest nom
i la contrasenya és incorrecta permet tornar a introduir la contrasenya
fins a un màxim de tres vegades.
A continuació, incloem alguns dels casos de prova que es podrien utilitzar
amb aquest programa:
• Cas de prova 1– Entrada: prémer el botó de minimitzar.
– Condicions d’execució: la finestra ha d’estar oberta.
– Resultat esperat: la finestra es minimitza a la barra d’eines.
• Cas de prova 2– Entrada: usuari correcte i contrasenya correcta. Prémer botó d’acce-
dir al sistema.
– Condicions d’execució: en la taula existeix aquest usuari amb la con-
trasenya i amb un intent fallat (nombre inferior a 3).
– Resultat esperat: donar accés al sistema i reflectir que el nombre
d’intents per a l’usuari correcte és zero en la taula USUARI (compte,
contrasenya, nre. intents).
• Cas de prova 3– Entrada: usuari incorrecte i contrasenya correcta. Prémer botó d’ac-
cedir al sistema.
– Condicions d’execució: en la taula no existeix aquest usuari amb
aquesta contrasenya.
– Resultat esperat: no donar accés al sistema.
3.1.3. Revisions
A part de les estratègies de prova de codi basades en tècniques de caixa ne-
gra i caixa blanca, alguna vegada heu utilitzat alguna altra estratègia per
buscar errors en un programa? Segur que sí.
Anàlisi i disseny d’aplicacions informàtiques 72 Disseny estructurat d’aplicacions
Tots hem utilitzat altres estratègies de revisió de codi com, per exemple,
la inspecció directa del codi individualment o en grup. Probablement quan
us heu volgut assegurar que un programa funcionava bé, heu demanat a
un company, professor o amic que doni un cop d’ull al codi. Doncs quan
aquesta revisió es fa de manera sistematitzada i seguint unes normes, es-
tem parlant de les revisions, que són molt utilitzades a les empreses com
a complement de les proves.
Un avantatge de les revisions sobre les proves és que les proves detecten
el símptoma del defecte, però les revisions en detecten també la causa, ja
que revisen directament el codi. Un inconvenient és que la revisió directa
no es pot fer globalment sobre tot el codi del programa, sinó que se n’ana-
litzen mòduls.
En realitat, les revisions van més enllà de la recerca d’errors en el codi,
afegeixen tot tipus d’avaluacions per detectar defectes en els requeri-
ments, disseny, implementació o qualsevol altre producte del desenvolu-
pament del projecte programari.
És a dir, les revisions s’utilitzen tant en les proves com en el control de la
qualitat; per això, es fan servir en la comprovació de mòduls de les proves
unitàries i la resta de validacions i verificacions del sistema. !
Quan s’utilitzen en la comprovació del codi es denominen revisions tècni-
ques:
• Reunions: són les menys formals de les distintes revisions, per la qual
cosa són molt flexibles i requereixen poca preparació prèvia. En les re-
unions, diversos desenvolupadors revisen un document o producte per
millorar-ne la qualitat i detectar-hi errors abans de la prova. En el cas
de la revisió de la implementació dels mòduls d’un programa, consisti-
ria a reunir-se per llegir el codi i buscar-hi errors.
• Walkthroughs: és un procés més formal que les reunions i normal-
ment s’aplica a la revisió del codi, encara que, a vegades, es pot fer ser-
vir amb productes d’altres etapes del desenvolupament. Per això el
desenvolupador es reuneix amb revisors experts. El desenvolupador
lliura el codi als revisors i aquests indiquen qualsevol error o dubte so-
bre el codi. En la sessió de walkthrough el desenvolupador explica els
dubtes i es discuteix sobre possibles errors. S’utilitzen com a comple-
ment de les proves. Hi ha estudis que han revelat que els walkt-
hroughs detecten més errors que les proves en el mateix temps, per la
L’objectiu fonamental de les revisions és també detectar errors
tan aviat com sigui possible per tal d’eliminar-los.
Una manera de fer revisions tècniques són lesreunions.
Anàlisi i disseny d’aplicacions informàtiques 73 Disseny estructurat d’aplicacions
qual cosa són molt apropiades per al desenvolupament ràpid de progra-
mari.
• Inspeccions: són les més formals i requereixen una preparació prèvia.
S’utilitzen per a la verificació de tot el procés de desenvolupament. Les
inspeccions estan organitzades per un moderador que reparteix rols i
feines entre els participants. En el cas de la inspecció de codi, el mode-
rador i els revisors inspeccionen el programari abans de la reunió se-
guint unes llistes de control en les quals el revisor comprova i anota si
el producte compleix certes característiques.
Durant la reunió d’inspecció, el moderador organitza, l’autor explica el
codi, els revisors identifiquen els errors i un secretari recull tots els er-
rors trobats i les possibles solucions. !
Les inspeccions són molt efectives encara que requereixen la implica-
ció de bastant personal.
A més a més de les revisions, es fan auditories del programari, l’objectiu
de les quals és assegurar que els productes i processos dels desenvolupa-
dors s’ajusten als estàndards, nivells de qualitat, especificacions i procedi-
ments previstos en el projecte. Les auditories normalment les duen a
terme persones o organitzacions que no pertanyen a l’empresa de desen-
volupament per assegurar-ne l’objectivitat.
3.1.4. Proves d’integració
Són suficients les proves que es fan a cada part d’una aplicació per assegu-
rar-nos que hem provat el programari? La resposta és no; és necessari pro-
var també les diferents unitats combinades de les proves d’integració. !
Una vegada que provem els components individuals del programa i ens
hem assegurat que no contenen errors, els hem d’integrar per tal de crear
un sistema complet que ha de ser provat. Aquest és el nivell de les proves
d’integració.
Els elements no s’integren tots al mateix temps, sinó que s’utilitzen dife-
rents estratègies d’integració incremental, que, bàsicament, consisteixen
en el següent:
• Integrar uns quants components.
Un objectiu important de les proves d’integració és localitzar er-
rors en les interfícies entre les distintes unitats.
Interfícies
Les interfícies en programació són el mètode de comunicar-se les distintes unitats d’una aplicació per enviar-se dades, missatges, ordres, paràmetres, etc.
Anàlisi i disseny d’aplicacions informàtiques 74 Disseny estructurat d’aplicacions
• Provar-los i
– si no hi ha errors, afegir-hi components nous;
– si hi ha errors, se solucionen i es tornen a provar.
Amb aquest procés es facilita la localització de l’error quan es produeixi,
perquè se sap quins són els últims mòduls que s’han integrat i quan s’ha
produït l’errada.
L’organització clàssica dels mòduls és una estructura jeràrquica organitza-
da per nivells: a la part alta hi haurà el mòdul o mòduls principals (a vega-
des denominats pares), que fan crides a mòduls subordinats de nivell
inferior (fill), i així successivament cada nivell utilitzarà mòduls de nivell
inferior fins a arribar als mòduls terminals. Els mòduls superiors seran els
més propers a l’usuari, és a dir, inclouen la interfície d’usuari (entorn grà-
fic, menús, ajudes, etc.) i els mòduls inferiors són els més propers a l’es-
tructura física de l’aplicació (bases de dades, maquinari, etc.).
Vegem diferents estratègies de desenvolupament de les proves d’integració:
1) Prova d’integració ascendent:
• Comença combinant en grups les unitats o mòduls de baix nivell per
provar-los (proves dobles, triples, quàdruples, etc. segons el nombre de
mòduls combinats).
• Per fer les proves és necessari dissenyar mòduls programari com ara
components de proves, denominats programes controladors de proves
o impulsors o drivers, que permeten simular el comportament dels
mòduls superiors.
• Els programes controladors tenen la mateixa interfície del mòdul que
substitueixen, però no fan la seva funció; per tant, són fàcils de cons-
truir, ja que no simulen l’activitat dels mòduls pare, sinó que serveixen
simplement per poder executar el mòdul que es provarà.
• Amb els programes controladors duem a terme les proves de les inter-
fícies i els mòduls.
• Quan s’ha provat un grup de mòduls es continua el procés amb la resta
d’agrupacions del mateix nivell.
• Un cop provat un nivell, se substitueixen els programes controladors
pels mòduls superiors i es repeteix el procés; per aquesta raó, serà ne-
cessari anar desenvolupant nous programes controladors superiors.
• El procés s’anirà repetint successivament fins que s’integrin tots els ni-
vells.
Anàlisi i disseny d’aplicacions informàtiques 75 Disseny estructurat d’aplicacions
2) Prova d’integració descendent:
• En primer lloc, es proven els mòduls de nivell superior i després es van
integrant els components de la capa següent.
• Una vegada provats els components d’aquesta capa es proven els de ni-
vell inferior i així successivament fins a involucrar totes les capes.
• Per poder fer les proves descendents sense incloure els mòduls infe-
riors, necessitem també components; concretament, és necessari cre-
ar mòduls programari simuladors de proves anomenats ficticis o stub,
que n’emulin el comportament i tinguin la seva mateixa interfície.
• Els mòduls ficticis simulen les funcions que haurien de fer els mòduls
reals que substitueixen; per això, són més difícils de construir que els
programes controladors.
En aquest cas no es necessiten programes controladors de proves com
succeïa en els ascendents.
3) Prova d’integració combinada:
• Combinen la integració ascendent i descendent.
• Els mòduls individuals es proven amb drivers i stubs i després es van
provant les capes superiors i inferiors substituint els drivers i stubs
pels mòduls provats.
• En els nivells o capes superiors es fa servir una estratègia descendent
i en les inferiors, ascendent, fins a trobar-se en alguna capa intermèdia.
• Les proves es poden dur a terme en paral·lel per estalviar temps.
4) Prova d’integració de big bang o gran explosió:
• De primer, es proven tots els mètodes individualment i, després, tots
els components del sistema s’integren a la vegada i s’hi fan proves.
• Aquesta estratègia sembla simple d’aplicar, però té l’inconvenient im-
portant que quan es descobreix una fallada és molt difícil localitzar-la
per poder-la corregir.
En totes les estratègies hem de decidir l’ordre en què es van integrant els
mòduls. Un bon criteri és començar amb els mòduls crítics del sistema i
Programari d’ajuda
Hi ha components de prova, programes controladors de proves (drivers) i mòduls simuladors (stubs), que són necessaris per fer les proves. Però també hi ha programari que ajuda al desenvolupament i ús d’aquests components i que els automatitza.
Les proves d’unitats i les d’integració estan molt lligades i es poden fer en paral·lel, a mesura que es va desenvolupant el programari.
Anàlisi i disseny d’aplicacions informàtiques 76 Disseny estructurat d’aplicacions
els que siguin més susceptibles de contenir errors pel fet de ser més com-
plexos o estar relacionats amb més requeriments.
3.1.5. Proves d’acceptació
La prova d’acceptació la fa l’usuari en finalitzar la fase de prova.
Si el programari es desenvolupa com un producte que faran servir molts
usuaris, no és pràctic fer proves d’acceptació formals per a cadascun.
Es poden fer dos tipus de proves:
• Proves que es fan al lloc de desenvolupament però per a un client. El
desenvolupador observa i registra els problemes i errades.
• Proves que es fan per als usuaris finals (o un conjunt limitat d’aquests
usuaris) al seu entorn d’explotació. El client registra els errors i n’in-
forma el desenvolupador.
3.2. Documentació
Perquè el manteniment d’una aplicació informàtica sigui tan fàcil com es
pugui, és convenient disposar de tota la documentació, això vol dir tots els
documents que s’han anat generant en totes les etapes anteriors: algorit-
mes, codis font, manuals d’usuari, etc. Aquest tipus de documentació
s’anomena documentació externa. A més a més, hi ha un altre tipus de do-
cumentació, que és la documentació interna.
La documentació interna d’un programa són els comentaris que el progra-
mador pot escriure en el codi font d’un programa i que el compilador no
tindrà en compte, ja que no són instruccions. Els comentaris d’un progra-
ma són explicacions o aclariments que ajudaran el programador en un fu-
tur, quan vulgui revisar o modificar el codi font del programa, i encara és
més important si el que ha de fer la modificació és un programador dife-
rent del que va escriure el codi font en un primer moment.
La documentació no serveix d’ajuda per a ningú si és massa extensa o si
és massa minimalista. !
L’objectiu de la prova d’acceptació és obtenir l’aprovació del cli-
ent sobre la qualitat de funcionament del sistema desenvolupat i
provat.
Anàlisi i disseny d’aplicacions informàtiques 77 Disseny estructurat d’aplicacions
Els programadors amb experiència solen documentar de manera metòdi-
ca, fins i tot el codi provisional, les anàlisis d’un problema inicial i els es-
borranys d’un disseny i van documentant a mesura que van avançant.
Facilitarem directrius sobre com s’ha documentar un sistema de progra-
mari. La documentació hauria de tenir l’estructura següent:
1) Requisits
La secció de requisits descriu el problema que s’està solucionant junta-
ment amb la solució.
a) Visió general: una explicació de l’objectiu del sistema i de la seva fun-
cionalitat.
b) Especificació revisada: en aquesta secció hauríem d’aclarir qualsevol
suposició que s’hagi fet sobre el significat dels requisits, i també qualsevol
extensió o modificació d’aquests requisits.
c) Manual d’usuari: una descripció detallada sobre com l’usuari pot utilit-
zar el sistema, quines operacions pot portar a terme, quins són els argu-
ments de la línia d’ordres.
d) Funcionament: quins recursos necessita el sistema per a una operació
normal?, i quin espai i temps s’espera que consumeixi?
e) Anàlisi del problema: una descripció clara del problema subjacent, això
inclou el model conceptual i tota la part d’anàlisi.
2) Disseny
La secció de disseny de la documentació proporciona l’estratègia d’imple-
mentació, i consta de:
a) Visió general: dóna una visió general del disseny: organització d’alt ni-
vell, qüestions de disseny especialment interessants, ús de llibreries i al-
tres mòduls i indicadors d’aspectes no resolts.
b) Estructura en temps d’execució: una descripció de l’estructura del pro-
grama en execució, expressada com un model d’objecte de codi.
c) Estructura del mòdul: una descripció de l’estructura sintàctica del text
del programa, expressada com un diagrama de dependència entre mòduls.
3) Proves
La secció de prova de la documentació indica l’enfocament que s’ha escollit
per verificar i validar el sistema. Això podria incloure tant les proves
Anàlisi i disseny d’aplicacions informàtiques 78 Disseny estructurat d’aplicacions
d’usuari per determinar la idoneïtat del sistema com a solució al problema,
com l’execució de casos de prova per verificar la correcció algorítmica del
codi.
a) Estratègia: una explicació de l’estratègia general de les proves: caixa
blanca, caixa negra, top down (de dalt a baix) i/o bottom up (de baix a
dalt), tipus de test (casos de prova).
b) Resultats del test: resum de quines proves s’han dut a terme i quines
no, i quins mòduls s’han provat.
4) Reflexió
La secció de reflexió (vulgarment coneguda com a post mortem) del docu-
ment és on es poden fer generalitzacions a partir d’èxits o errors concrets
i detalls rellevants que semblin importants i que no s’han dit en cap mo-
ment del desenvolupament.
5) Apèndix
L’apèndix conté detalls de baix nivell sobre el sistema.
a) Formats: una descripció de tots els formats adoptats: fitxers per a l’en-
trada i sortida de dades, arguments de la línia d’ordres, diàlegs d’usuari,
formats dels missatges per a les comunicacions en xarxa, etc.
b) Especificacions del mòdul: se n’haurien d’extreure les especificacions
del codi i presentar-les per separat en aquest apartat.
6) Documentació del codi
El codi s’ha de presentar amb comentaris perquè quedi tot ben clar.