Disseny estructurat daplicacions

78
Disseny estructurat d’aplicacions Inmaculada Salas Díaz Anàlisi i disseny d’aplicacions informàtiques

Transcript of Disseny estructurat daplicacions

Page 1: Disseny estructurat daplicacions

Disseny estructurat d’aplicacionsInmaculada Salas Díaz

Anàlisi i disseny d’aplicacions informàtiques

Page 2: Disseny estructurat daplicacions
Page 3: Disseny estructurat daplicacions

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

Page 4: Disseny estructurat daplicacions

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

Page 5: Disseny estructurat daplicacions

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.

Page 6: Disseny estructurat daplicacions

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.

Page 7: Disseny estructurat daplicacions

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.

Page 8: Disseny estructurat daplicacions

Anàlisi i disseny d’aplicacions informàtiques 8 Disseny estructurat d’aplicacions

Page 9: Disseny estructurat daplicacions

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.

Page 10: Disseny estructurat daplicacions

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.

Page 11: Disseny estructurat daplicacions

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

Page 12: Disseny estructurat daplicacions

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.

Page 13: Disseny estructurat daplicacions

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

Page 14: Disseny estructurat daplicacions

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)

Page 15: Disseny estructurat daplicacions

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.

Page 16: Disseny estructurat daplicacions

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.

Page 17: Disseny estructurat daplicacions

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.

Page 18: Disseny estructurat daplicacions

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.

Page 19: Disseny estructurat daplicacions

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.

Page 20: Disseny estructurat daplicacions

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ó

Page 21: Disseny estructurat daplicacions

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.

Page 22: Disseny estructurat daplicacions

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.

Page 23: Disseny estructurat daplicacions

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

Page 24: Disseny estructurat daplicacions

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.

Page 25: Disseny estructurat daplicacions

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-

Page 26: Disseny estructurat daplicacions

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.

Page 27: Disseny estructurat daplicacions

Anàlisi i disseny d’aplicacions informàtiques 27 Disseny estructurat d’aplicacions

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

Page 28: Disseny estructurat daplicacions

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.

Page 29: Disseny estructurat daplicacions

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.

Page 30: Disseny estructurat daplicacions

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.

!!

Page 31: Disseny estructurat daplicacions

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.

Page 32: Disseny estructurat daplicacions

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.

Page 33: Disseny estructurat daplicacions

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

Page 34: Disseny estructurat daplicacions

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.

Page 35: Disseny estructurat daplicacions

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é

Page 36: Disseny estructurat daplicacions

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.

Page 37: Disseny estructurat daplicacions

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

Page 38: Disseny estructurat daplicacions

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.

!!

Page 39: Disseny estructurat daplicacions

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.

Page 40: Disseny estructurat daplicacions

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

Page 41: Disseny estructurat daplicacions

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.

Page 42: Disseny estructurat daplicacions

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

Page 43: Disseny estructurat daplicacions

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

Page 44: Disseny estructurat daplicacions

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.

!!

Page 45: Disseny estructurat daplicacions

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.

Page 46: Disseny estructurat daplicacions

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.

Page 47: Disseny estructurat daplicacions

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

Page 48: Disseny estructurat daplicacions

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.

Page 49: Disseny estructurat daplicacions

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.

Page 50: Disseny estructurat daplicacions

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

Page 51: Disseny estructurat daplicacions

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.

Page 52: Disseny estructurat daplicacions

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.

Page 53: Disseny estructurat daplicacions

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-

Page 54: Disseny estructurat daplicacions

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.

Page 55: Disseny estructurat daplicacions

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

Page 56: Disseny estructurat daplicacions

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.

Page 57: Disseny estructurat daplicacions

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

Page 58: Disseny estructurat daplicacions

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.

Page 59: Disseny estructurat daplicacions

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ó

Page 60: Disseny estructurat daplicacions

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

Page 61: Disseny estructurat daplicacions

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

Page 62: Disseny estructurat daplicacions

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

Page 63: Disseny estructurat daplicacions

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-

Page 64: Disseny estructurat daplicacions

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.

Page 65: Disseny estructurat daplicacions

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

Page 66: Disseny estructurat daplicacions

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.

Page 67: Disseny estructurat daplicacions

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

Page 68: Disseny estructurat daplicacions

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

Page 69: Disseny estructurat daplicacions

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

Page 70: Disseny estructurat daplicacions

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

Page 71: Disseny estructurat daplicacions

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

Page 72: Disseny estructurat daplicacions

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.

Page 73: Disseny estructurat daplicacions

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.

Page 74: Disseny estructurat daplicacions

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.

Page 75: Disseny estructurat daplicacions

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.

Page 76: Disseny estructurat daplicacions

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.

Page 77: Disseny estructurat daplicacions

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

Page 78: Disseny estructurat daplicacions

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.