Disseny estructurat d'aplicacions

Disseny estructurat
d’aplicacions
Inmaculada 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.

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.

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.

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.

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.

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”.

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.

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

• 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) i
dels senyals de controls o flags (inferior)

• 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.

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.

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.

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.

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 Obtenir
X crida el mòdul Obtenir Y per llegir un valor des d’un dispositiu d’entrada i retornar-lo a Obtenir X
com 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.

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ó

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.

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.

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

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.

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-

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.

Figura 24. Exemple complet de creació de diagrama d’estructures

• 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.

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.

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.
!!

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.

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.

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ó.

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.

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é

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.

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

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.
!!

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.

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í.

• 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ísica
Elements 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àctica
Presentació 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àntica
Significat 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.

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

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

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.
!!

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.

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.

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ú de
barres 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

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 una
calculadora.

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.

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

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ó permeten
Cada vegada més s'utilitzen interfícies que
detecten el moviment davant una càmera.

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.

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-

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.

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’).

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.

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ó.

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.

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ó

Disseny estructurat d'aplicacions

Disseny estructurat d'aplicacions

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (13)

Similar a Disseny estructurat d'aplicacions

Similar a Disseny estructurat d'aplicacions (20)

Disseny estructurat d'aplicacions