Sebastián Rubén Gómez Palomo

Eduardo Moraleda Gil

APROXIMACIÓN,
A LA INGENIERIA
DEL SOFTWARE

@ ;ditorial Universitaria· .
_ ~ Ramón Areces
11
Índice general

! . Introducción 17
1.1. Introducción. 17
1.2. Objetivos .. 18
1.3. ¿Qué es el software? 18
1 .3.1. Calidad del software 19
1.3.2. Tipos de software .. 21
1.4. ¡,Cómo se fabrica el software? 23
1.5. :Mitos del software 25
1.6. Conclusiones . . . . 27
1.7. Ejercicios propuestos 27

" El Ciclo "de V ida del Software 29

2.1. Introducción . . . . . . . . . . 29
2.2. Objetivos . . . . . . . . . . . 29
2 .3. El ciclo de vida de un producto 29
2 .4. El ciclo de vida del software . . . 31
2.5. Fases del ciclo de vida del software 32
2.5.1. Análisis . . . 32
2.5.2. Diseño . . . . 32
2.5.3. Codificación . 33
2.5.4. Integración 33
2.5.5. Explotación . 33
2.5.6. :Ylantenimiento 33
2.6. Documentos que se generan en el ciclo de vida 33
2.6.1. Documento de requisitos del software 34
2.6.2. Documento de diseño del software 34
2.6.3. Código fuente . . . . . . 34
2.6.4. El sistema software . . . . . 34
2.6.5. Documentos de cambios . . 34
2. 7. Tipos de ciclo de vida del software 35
2.7.1. Ciclo de vida en cascada. 35
2. 7.2. Ciclo de vida en V 36
2.8. Prototipos . . . . . . . . . . . 38
2.8.1. Prototipos rápidos .. 39
2.8.2. Prototipos evolutivos . 40
· 2.9. El modelo en espiTaJ . . 41
2.10. Programación extrema . . . . 43

9
10 ÍNDICE GENERAL

2.11. ~lamenimiento del software . . . . . 45

2.11.1. Evolución <le las aplicaciones 46
2.J 1.2. Gestión de cambios . . . . 47
2.11.3. Rcing<'niería . . . . . . . . . 47
2.12. Garantía <le calidad de software .. 48
2.12.1. Plan dr garantía de calidad 48
2.12.2. Re,·isiones . . . . . . . . . 49
2.12.3. Pruebas . . . . . . . . . . 50
2.12.4. Gestión de configuración . 50
2.12.5. Kormas y estándares . 52
2.13. Conclusiones . . . . 54
2.14. Ejercicios propuestos . . . . 54

3. Especificación de Requisitos 55
3.1. Introducción . . . . . . 55
3.2. Objetivos . . . . . . . . . . 55
3.3. Modelado de sistemas . . . 56
3.3.l. Concepto de modelo 57
3.3.2. Técnicas de modelado 57
3.4. Análisis de requisitos de software 62
3.4.1. Objetivos del análisis . . . 63
3.4.2. Tareas del análisis . . . . 66
3.5. ~otaciones para la especificación 69
3.5.1. Lenguaje natural . . . . . 70
3.5.2. Diagramas de flujo de datos . 71
3.5.3. Diagramas de transición de estados . 77
3.5.4. Descripciones funcionales. P seudocódigo 79
3.5.5. Descripción de datos . . . . . . . . 82
3.5.6. Diagrama.5 de modelo de datos .. 8-1
3.6. Documento de especificación de requisitos 87
3.7. Ejemplos de especificaciones . . . . . . . 95
3. 7.1. \'ideojuego de las minas . . . . . 95
3. 7.2. Sistema de gestión de biblioteca 100
3.b. Condm,iones . . . . 111
3.9. Ej<'rcicios propuestos . . . . . . . .. . 112

4. F\1ndamentos del Diseño d e Software 113

-1.1. fn t roducción . . . . 113
4.2. Objetivos . . . . . 113
43. . ¿Q ue, es eld.1scno.
-?
114
4..1. Conceptos de base 117
•1. 1.1. Abstracción 118
4.4.2. Modularidad 121
1.5. Rc•finamicnto . . . . 122
4.5. l. Estructuras de datos 123
4.5.2. Ocultación 124
4.5.3. Gencricidad 125
4.5.-l. Herencia .. 127
LVDICE GE,i\íERAL 11

4.5.5. Polimorfismo . . . 129

4.5.6. Concurrencia . . . 131
4.6. Notaciones pa.ra el diseño 132
4.6.1. Kotaciones estructurales 133
4.6.2. Kotaciones estáticas 140
4. 7. Documentos de diseño . 150
4.7.l. Documento ADD 150
4.7.2. Documento DDD 154
4.8. Conclusiones . . . . 155
4.9. Ejercicios propuestos .. 156

5. T écnicas Generales de Diseño de Software 157

5.1. Introducción . . . . . . . . 157
5.2. Objetivos . . . . . . . . . . . . 157
5.3. Descomposición Modular . . . . 158
5.3.1. Independencia funcional 159
5.3.2. Adaptabilidad . . . . . . 167
5.4. Técnicas de diseño funcional descendente 169
5 .4.1. Desarrollo por refinamiento progresivo 169
5.4.2. Diseño estructurado . . . . . . . . . , 174
5.4.3. Ejemplo: Sistema de gestión de biblioteca 177
5.5. Técnicas de diseño basado en abstracciones . . . 178
5.5.1. Descomposición modular basada en abstracciones . 179
5.5.2. :.viétodo de Abbott . . . . . . . . . 180
5.5.3. Ejemplo: Videojuego de las minas 183
5.6. Técnicas de diseño orientadas a objetos 185
5.6.1. Diseño orientado a objetos . . . . 186
5.6.2. Ejemplo: Estación meteorológica 188
5.7. Técnicas de diseño de datos . . . . . . 196
5.8. Diseño de bases de datos relacionales . 196
5.8.1. Formas normales . . . . . . . . 197
5.8.2. Diseño de las entidades . . . . 199
5.8.3. Tratamiento de las relaciones de asociación 199
5.8.4. Tratamiento de las relaciones de composición 201
5.8.5. ·T ratamiento de la herencia . . . . . . . . . . 201
5.8.6. Diseño de Índices . . . . . . . . . . . . . . . . 201
5.8.7. Ejemplo: Diseño de datos para la gestión de biblioteca 201
5.9. Diseño de bases de datos de objetos 204
5.10. Diseño de software con patrones 205
5.11. Ejemplos de diseños . . . . . . . . . 210
5.11.1. Ejemplo: Videojuego de las minas 210
5.11.2. Ejemplo: Sistema de gestión de biblioteca 222
5.12. Conclusiones . . . . 231
5.13. Ejercicios propuestos . . . . . . . . . . . 232

6. UML, Lenguaje Unificado de Modelado 233

6.1. Introducción . 233
6.2. Objetivos . . . . . . . . . . . . . . . . . 233
12 !NDICE GENERAL Í:VI

6.3. ¿Qui>"" l"~IL'! . . 234

6.4. Oríge1ws de l"~lL . 235
6.5. Objetivos <lP C~IL 236
6.6. Estructura de {;1\IL 237
6.7. Diagrama.'> UML .. 244
6.7.1. Diagramas dP casos de 11s0 244
6.7.2. Diagrama <l<' das<'S . . . . . 247
6.7.3. Diagramas de SC'ruencia. .. 250
6.7.4. Diagramas de colaboración 251
6.7.5. Diagrama de estado . . . . 253
6. 7.6. Diagrama de actividad . . . 255
6. 7. 7. Diagramas <le componentes 256
6. 7.8. Diagrama de despliegue . 257
6.8. Conclusiones . . . . . 258
6.9. Ejercidos propuestos . . . . 258

7. La Codificación del Software 261

7.1. Introducción . . . . . . . . . 261
7.2. Objetivos . . . . . . . . . . 261
7.3. Los lenguajes de programación 262
7.3.1. Prim<'ra generación de lenguajes . 262
7.3.2. Segunda gl"neración . 263
7.3.3. Tercera generación . . . . . . 265
7.3.4. Cuarta generación . . . . . . 268
7.4. Criterios dC' selección del lenguaje . . 270
7.5. Aspe<·tos m<>todológicos . . . . . . . 272
7.5.1. Normas y estilo de codificación . 272
7.5.2. Manejo de errores . . . . . . . . 274
7.5.3. Aspectos de eficiencia . . . . . . 277
7.5.4. Transportabilidad de software . . 278
7.6. Conclusiones . . . . . 280
7.7. Ejercicios propuestos . 281

8. Pruebas de Software 283

.l. Introducción .. . 283
8.2. Objetivos . . . . . 284
~.3. Tipos de pruebas . 284
.4. PruE>bas de unidades . 285
.4.l. Pruebas de C'aja negra . 286
.4.2. Pruebas de caja transparente . 291
.4.3. E.c;timación de errores no detectados . 296
- Pruebas de unidades en programación orientada a objetos . 297
Esuategia-. de Integración . . . . 298
l. Integración Big Bang .. . 298
~ ó n descendente . 298
lmegración ascendente . . 300
Estrategias de int<•gración en programación orientada a objetos . 301
P..c.....lh-.-.c de ,-alídación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
ÍSDICE GENERAL 13

8.8. Pruebas del sistema . 302

8.9. Conclusiones . . . . . 303
8.10. Ejercicios propuestos . 304
Capítulo 1

Introducción

1.1. Introducción
El sofl ware es una parle principal del enlorno humano. La cantidad de aparatos
•orlo tipo que rodean a las personas, que se usan a diario y sin los cwe cada vez
•.'Jda sería más difícil de imaginar, que están controlados por un programa, por uu
··ware que rige su comportamiento es enorme.

Teléfonos, electrodomésticos, coches o cualquier vehículo que circule por una ca-
':TP1'era, aviones, barcos, trenes, el aire acondicionado de la casa u oficina, los siste-
::r..i.s de control de edificios, aeropuertos o estaciones, las televisiones, los sistemas de
_ tión de las empresas, los robots de las fábricas de ensarnblaje, la lista es intermi-
1le. Todos estos sistemas disponen de uno o más computadores, que c.onstit11ycn
·hardware" tlel siste1na, y de los programas que gobiernan su funcionamiento, que
n mponen el "software" de los mismos.

El software está presente no sólo en los sisternas infonnáticos que realizan tareas
dt> tratamiento de información 1 sino en un sinfín de sistemas de la 1nás diversa, corn-
kjidad. Son nliles, millones de líneas de código que diariamente se programan para
e nseguir que todos estos sistemas funcionen como se desea. Esta tarea de construir
t _ software la realizan los programadores, los cuales tienen que a su vez dar rnante-
rumiento durante, en la mayoría de los casos, largo tiempo.

La ingerucría es, según la Real Academia de la Lengua, el conjunto de conoci1nien-

s y técnicas que permiten aplicar el saber científico a la 11tilización de la materia y
t." las fuentes de energía. Se pueden encontrar un sinfín <le definiciones de ingeniería,
t-n las que el deno1ninador cornún es la aplicación prácl.ir.a <le! conocirniento para la
• a bora.ción de cualquif>r 1.ipo de producto o servicio.

17
18 n•,TRODUCCI Ó.V

En f'Ste libro se introduce el conjunto de técnicas y procedimientos que se han ido

desarrollando a lo largo dP las últimas décadas, para poder elaborar de una forma
ordenada y eficiente tantas y tantas líneas de código que comp onen el software. Todas
estas técnicru:; y proc.:edimientos c.:omponen la ingeniería de software. una todavía joven
rama de la ciencia.

1.2. Objetivos
En este capítulo se da una visión inicial de lo que es el software y cómo se produce.
lgualment0 se profundiza en e] concepto de ingeniería del software. Se pretende que
el lector adquiera una idea clara de los siguientes conceptos:

• Definición de software y requisitos de calidad exigibles.

■ (\0 todo el software es igual. según su aplicación y modo de desarrollarlo puede

ser muy diverso. Se da una visión de los distintos t ipos de software.

■ Definición del concepto de Ingeniería del software y comprensión de su origen.

■ Existen algunas ideas preestablecidas acerca del software que se analizan.

1.3. ¿Qué es el software?

En lm sistema informático el hardware se identifica con facilidad. son los aparatos
físicos. El software, sin embargo, es algo más difícil de caracterizar. y a veces se defi-
ne por exclusión: el software es todo lo que no es hardware. El software incluye, por
supuesto. los programas que gobiernan el funcionamiento del sistema. pero también
incluye otros elementos tales como documentos, bases de datos, o algo tan inmaterial
como son los procedimientos de operación o de mantenimiento periódico.

El software pue<le ser <'tl sí mismo un producto que se venda, por ejemplo un
procesador de textos o un programa de tratamiento de imágenes, o tan sólo una par-
te, e11 la mayoría dc> los casos esencial, de un producto más complejo, por ejemplo el
programa que gobierna la inyf'Ccióu de gasoil en un motor diésel, o puede ser el medio
para dar un sen'icio, por ejemplo el programa que permite realizar una transferencia
banc.:aria. Lo que es indudable es que la elaboración <l<'l software ocupa a millon&:>
de personas en todo el muuc.io y se puede considerar una actividad económica en s1
misma.
 - ES EL SOFTWARE? 19

Calidad del software

~alidad de un producto puede valorarse desde puntos de vista di\·ersos. El soft-
.iJ..a
~o es una excepción, y existen por tanto diferentes enfoques para la valoración
, calidad.

ideal sería poder medir la calidad del software como se miden ciertos aspectos
c:.lidad de otros productos de ingeniería: pureza de un producto, resistencia de
material, sus dimensiones, etcétera. Desgraciadamente esto no resulta fácil, y las
-..:.as de aplicación de métricas precisas a los productos software están todavía en
ción.

Existe un esquema general de mediciones de la calidad de software propuesto por

Call y otros [:tvlcCall78], basado en valoraciones a tres niveles diferentes, deno-
ados factores, criterios y métricas. Los factores de calidad constituyen el nivel
rior , y son la valoración propiamente dicha, significativa, de la calidad. Esta
ración no se hace directamente, sino en función de ciertos criterios o aspectos
ruvel intermedio que influyen en los factores de calidad. Las métricas están en el
inferior, son mediciones puntuales de determinados atributos o características
_ producto, y son la base para evaluar los criterios intermedios. Entre los factores
-alidad propuestos encontramos los siguientes:

■ CORRECCIÓN. Es el grado en que un producto software cumple con sus espe-

cificaciones. P odría estimarse como el porcentaje de requisitos que se cumplen
adecuadamente.
■ FIABILIDAD. Es el grado de ausencia de fallos durante la operación del produc-
to soft,,v7are. Puede estin1arse como el número de fallos producidos o el tiempo
durante el que permanece inutilizable durante un intervalo de operación dado.
■ EFICIENCIA. Es la relación entre la cantidad de resultados suministrados y
los recursos requeridos durante la operación. Se mediría corno la inversa de lm,
recursos consumidos para realizar una operación dada.
• SEGURIDAD. Es la dificultad para el acceso a los datos o a los datos o a las
operaciones por parte de personal no autorizado.
■ FACILIDAD DE USO. Es la inversa del esfuerzo requerido para aprender a
usar un producto software y utilizarlo adecuadarnente.
• l\IAKTENIBILIDAD. Es la facilidad para corregir el producto en caso necesario.
Se aplica propian1cntc el m anteni mien Lo correctivo.
■ FLEXIBILIDAD. Es la facilidad para modificar f'l producto software. Se aplica
propiarnente al mantenimiento adaptatiYo ~- al perfecti,·o.
20 INTRODUCCIÓN

• FACILIDAD DE PRCEBA. Es la inverna <lel esfuerzo r<>querido para ensayar

un producto software y comprobar su correcc-ión o fiabilidad.

• TRANSPORTABILIDAD. Es la facilidad para adaptar el producto software a

una plataforma (hardware - sistema operativo) diferente de aquella para la que
se desarrolló inkialn1ente.

• REUSABILIDAD. Es la facilidad para emplear partes del producto en otros

desarrollos postcriore-,. Se facilita mediante una adecuada. organización de los
1nódulos y funciones durante el diseño.

■ I. "TEROPERATI\1DAD. Es la facilidad o capacidad del producto soft ware

para trabajar en combinacióu con otros productos.

Estos factores de calidad se centran en características del producto software. En

muchos casos se contemplan también otros aspectos relath·os al proceso de desarrollo.
ya qtH' la organización de éste influye muy directamente en la calidad del producto
obtenido.

Comprobar la calidad de un software es una tarea compleja. Las pruebas o ensayos

c-onsisten en hacer un producto software o una parte de él en condiciones determi-
nadas, y comprobar sí los resultados son correctos. El objetiYO de las pruebas es
descubrir los errores que pueda contener el software ensayado.

La-.; prueba.s no p<'nniten garantizar la calidad de un producto. Puede decirse que

uua prueba ti(•nc éxito si se descubre algún error, con lo que se sabe que el producto
no cumple co11 algún criterio de calidad. Por el contrario, si la p rueba no desC'ubre
uingún error. no se garantiza con ello la calidad del producto, ya que pueden existir
otros errores que habrían dE' descubrirse mediante pruebas diferentes. Esto es así
porque nunca pucdf' eusayan;c un producto de forma exhaustiva, sino que las prue-
bas sólo hacen que el producto realice una parte ínfima de la enorn1e variedad de
operaciones conc,Tetas que podría realizar.

En la figura 1.1 podemos observar de fom1a simplificada la evolución de la tasa de

fallos de un software en el tiempo. Inicialmente esta ta.qa es muy alta. Según se van
corrigiendo lo:-. <>rrore-. se reduC'e rápi<la1n<>ntc. Sin embargo, a lo largo de la vida de un
softwar<> es frpcuente realizar mejoras funcionales, dando lugar a distintas versiones.
Cada ,·cz que introdudmos cambios en }as nuevas Ycrsioncs. <>l número de errores del
software se dispara, haciendo de nuevo ncc<>sario la corrección de los mü,mos.
 :E ES EL SOFT1VARE? 21

Tasa de fallos tras

cambio funcional

en
o
\
.....
(O

<l)
"O
(O
en Cambio
Cambio
~ Cu,vasin
\ \ cambios

Tiempo

Figura 1.1: Evolución de fallos en un Sistema Software

1.3.2. Tipos de software

Gasificar el software no es una tarea fácil debido a la gran variedad de aplicaciones
métodos de desarrollo que existe. Una de las clasificaciones más completas se
entra en (PressmanlO], donde se agrupa el software en siete grandes categorías:

■ SOFTvVARE DE SISTEl\iIAS

Lo forman todos aquellos programas necesarios para dar soporte a otros progra-
mas, como los sistemas operativos, los compiladores o los programas de gestión
de redes. Su principal característica es su alto grado de interacción con el hard-
ware, ya que en rnuchos casos deben gestionar de forma eficiente el acceso al
hardware por parte de otros programas o usuarios.

■ SOFT\VARE DE APLICACIÓX

Son aplicaciones desarrolladas para n•Bolver problemas específicos de los nego-

cios. En esta categoría incluiríamos el software de gf'stión de los bancos o de
las grandes empresas en general, como los ERP (Entcrprise Resource Planning).
22 V:TRODUCCIÓN

• SOFT\\".\RE DE I);GE:'\""ERÍA Y C IEXCIAS

El objeti\·o e~ la programación <le elaborados algoritrnos matemáticos para mo-

delar ~- simular complc>jo-. sist< mas J procesos. tales como reacciones nucleares,
modelos metereológicos. la re<I cléct nea de un pai8 o el diseño de un avión.

• SOFTvYARE I~CRUSTADO

Reside en el int<'rior <le un producto o sistema, y su objetivo es controlarlo, de-

finir su comportamiento. Suele ser muy específico y de pE>queñas dimensiones,
con la necesidad de operar en tiempo real. Desde el regulador de temperatura
de una vivienda hasta el sistema d e frenos de w1 vehículo, están gobernados
por este tipo df' software.

■ SOFT\\'.-\RE DE LIXEA DE PRODl7CTO

Su objetivo es dar una determinada funcionalidad al consumidor. En esta ca-

tegoría encontrarnos procesadores de texto, hojas de cálculo o las aplicaciones
d e contabilidad para pequeñas empresas.

■ APLIC..\CIO~ES \YEB ('·,YEI3APPS'')

En los últimos años se ha extendido su utilización con la generalización de los

aparatos móYil(>s con acceso a redes. Inicialmente simplemente se comr~ían
de archh·o~ de hipertexto para la presentación de información, sin embargo ho)
día tienen capacidad <l<' cómputo y está integradas con aplicaciones y bases de
dato corporativa.-,. A través ele ellas se puede operar una cuenta bancaria, rea-
lizar todo tipo de compras. utili;mr juegos muy elaborados ó conocer el tiempo
en cualquier parte del mundo. La comodidad: rapidez y vistosidad son deter-
:minanres a la hora de que tengan éxito.

• OIT\\"ARE DE IXTELIGEXCIA ARTIFICIAL.

plicarionc::,; de robótica, visión art ifidal. redes n euronales o sobre la

fg(b. Ctili1:an al~oritn1os no numéricos para la resolución de lo:-.
:-!::'..1:t:c:2!5. como por Pj<·mplo árbole.s lógicos de bfo,queda.
 Ó.\IO SE FABRICA EL SOFTlVA.RE? 23

.4. ¿ Cómo se fabrica el software?

Antes de la revolución industrial, los productos realizaban de forma artesanal. El
-PSano aprendía una serie de técnicas y procedimientos que le permitían elaborar-
, manualmente. Dichas técnicas y procedimientos rara vez se documentaban, y se
~mitían de maestro a aprendiz a lo largo de los años.

En el siglo XIX la industrialización y la producción en serie cambio radicalmen-

esta forma de hacer. Se fabricaban cientos y miles de productos todos iguales y
comercializaban masivamente. Para producir de forma eficiente se desarrollaron
serie de técnicas, procedimiento, est ándares y normas, los cuales permitían tener
:iedectamente controlado todo el ciclo de vida del producto, desde que éste es una
..
ple idea, hasta que se entrega al cliente final .

La elaboración de cualquier producto industrial conlleva un largo proceso, desde

concepción del producto pensando en la necesidad que se desea que cubra y su
rcado potencial, hasta que sale terminado de la fábrica. Todo este proceso está
ncebido para lograr los objetivos de calidad y coste que se consideren necesarios
ryara poder venderlo.

De igual forma, en las décadas iniciales de existencia de la informática, la labor de

d!Sarrollo de software se planteaba como una actividad art esanal, basada en la labor
<> personas habilidosas y más o menos creativas, que actuaban en forma individual

relativamente poco disciplinada.

Al aumentar la capacidad de los computadores gracias a los avances del hardwa-

r-P. aumentó también la complejidad de las aplicaciones a programar, y se apreció la
necesidad de una mejor organización de la producción de software, basada en el tra-
l iajo en equipo, con la consiguiente división y organización del trabajo , y el empleo
<1e herramientas apropiadas que automaticen las labores triviales y repetitivas.

La identificación formal del problema origina una frenética actividad para la crea-
-ión de metodologías concretas de desarrollo y, en general, en la concepción de la
ingeniería del software como disciplina. A finales de los años 60, se acuña el ter-
mino Ingeniería del Software en un congreso e.le la OTAN de manera formal. Con
esta denominación se designa el empleo en el desarrollo del software, de técnicas y
procedimientos típicos de la ingeniería en general.

El software tiene una particularidad especial frente a cualquier producto físico que
podamos imaginar: una vez diseñado, este se puede replicar con tremenda facilidad.
:,in necesidad de un proceso de fabricación propian1ente dicho. A pesar de ello, la
ingeniería del software se ha desarrollado a partir de la ingeniería industrial.
24 IIVT ROD UCCIÓ.V

La nurma d e calid ad I1 ~O169490.:J es un conjunto de normas de calidad y gestión

de la calidad. adop tadas por la industria del automó,-il como herramienta básica
para <le:,arrollar lo:- proce--05 nec-e.:sarios en la producción de un vehículo de forma
competiti,-a y ,atisfactoria para el cliente.

En <'l capll 1110 2 de e=,te libro :,e analizan los procesos más importantes para la
producción del :,oftware y difereute5 modelos para organizarlo:-;. de forma similar a
los procesos mostrado!- en la figura 1.2 para la industria del automóYil.

' ISO 16949 ENFOQUE DE PROCESOS

~MEDIDAS COMUNES
-,foa~1te•fttlOCeSOSdela~ntl~CN - · - . GNCi61\delos
A:UiiJoSM. la F ~ d a l ~ l d o y ta MIJ,¡jradal~

~
--""
-....,00

0€~/to

00.CUCllff
,......v-,1.
Q . . . . . . . . .~
DI~
V~

Figura 1.2: Enfoque de calidad en la industria del automóvil

La ingeniería del software amplía la visión del desarrollo del software como una
actividad esencialmente de programación. contemplando además otras acth;dades de
auáli:-;is y diseño previos y de integración y verificación posteriores. La d istribu ción
de todas estas actividades a lo largo del tiempo constituye los se ha dado en llamar
ciclo de ,;da del desarrollo de software.

Concretando, se tomará la definición de ingeniería del software de [S\VEBOK04].

Ingeniería de software es la aplicación de un enfoque sistemático. disciplinado y cuan-
tificable al desarrollo. operación y mantenimiento de software. y el e.tudio de estos
enfoques. es decir, la aplicación de la ingeniería al software.

A lo largo de los años 70 aparecen la..., herramientas CASE (Computer Aidcd

Software Engineering) de diseño a.-,istido p11r ordenador. que se aplican ampliamen-
te durante lo~ O. Las herramientas CASE tradicionalf's apoyaban a las acth-.idadc:-.
anteriores a la programación o coclific:acivn. para la que -;e ~~1ías empleando herra-
 uS DEL SOFTW.4.RE 25

.-as tradicionales, como los compiladores. que funcionaban de forma totalmente

a de la herramienta CASE.

En los 90 se amplía el campo de aplicación de las herramientas de ingeniería de

e, reconociendo la necesidad de automatizar aún más la labor de desarrollo
·ante la formalización del proceso completo de producción d~ software y el empleo
~Prramientas que soporten todo el ciclo de vida de desarrollo. Estas herramientas
_esignan con las siglas IPSE (Integrated Project Support Environment) o, más
ntemente, ICASE (Integrated CASE).

Con la llegada del siglo XXI, el desarrollo e implantación de Internet , muchos

los planteamientos de las herramientas CASE han evolucionado. Por un lado la
ibilidad de distribuir el desarrollo de los proyectos en diferentes localizaciones y
!' otro la obligada necesidad de la utilización de esta plataforma como marco para
funcionamiento de la mayoría de las aplicaciones. Otro de los grandes retos que
aparecido y triunfado recientemente son los "smartphones" o teléfonos inteligen-
- . P or el momento sólo se utilizan como plataformas de funcionamiento. pero no
y duda de que en breve formarán parte de las infraestructuras empleadas para el
---arrollo del software .

...\ lo largo de estos períodos de tiempo fue surgiendo una importante comunidad
::rentífica en torno a la ingeniería de software. Dos organizaciones han liderado di-
.. comunidad, AC:'.VI e IEEE Computer Society, que han promovido activamente la
·esta en práctica de esta disciplina. IEEE ha desarrollado la guía S\YEBOK con
objeto de crear una acreditación para la profesión de ingeniero del software en
Estados {.;nidos. Dicha guía da forma a los conocimientos necesarios para dominar
~-a disciplina y los diferenciales frente a otras relacionadas con el software, como
, ciencias de la computación o la gestión de proyectos de software.

Todavía a día de hoy, la ingeniería de software se encuentra en una situación p er-

manente de fuerte evolución, con avances continuos en las técnicas que resultan sin
embargo insuficientes en cada momento. De hecho se discute si el término ingeniería
del software es realmente válido, ya que una disciplina de ingeniería se caracteriza,
n general: por haber alcanzado una cierta madurez en las técnicas a aplicar, basadas
Pn un fundamento científico subyacente y no sólo en un pragmatismo artesanal.

1.5. Mitos d el software

El continuo proceso de evolución en las disciplinas <le desarrollo de software, junto
~on algunas de sus características particulares. tales como una relativa inmateriaJi-
26
INTRODUCCIÓN

dad.hacen difícil obtener una Yisión serena y justa de la ingeniería de software, provo-
cando que por parte de lo~ usuarios e incluso de algunos profesionales se mantengan
opiniones infundadas sobre la iinportancia o influencia de determinados factores en
el éxito o calidad de un producto software.

Alguna de estas opiniones. relatiYamente generalizadas, constituyen verdaderos

mitos, difíciles de erradicar. Podemos mencionar, por ejemplo, las siguientes:

• El hardware es mucho más importante que el software. l\t!anifiestamente falso,

ya que al usar un computador nuestra interacción es fundamentalmente con el
software, y sólo de una manera muy limitada el usuario accede directamente a
elementos hard,vare del equipo. Este menosprecio por el software se evidencia
en quienes consideran que la realización de copias ''pirata" o ilegales de los pro-
gramas no es una acción censurable...--

■ El software es fácil de desarrollar. Esto es falso para cualquier aplicación soft-

ware de cierta importancia. El desarrollo de grandes sistemas es muy complejo
y costoso 1 incluso aunque esos sistemas no empleen ningún material o hardware
específico. De hecho el desarrollo de software exige una mayor proporción de
manos de obra, frente al empleo de maquinaria, y por. ello el progresivo au-
mento del costo de la mano de obra en los países desarrollados ha llevado a un
crecimiento importante en el coste de los productos software.

■ El software consiste exclusivarnente en programas ejecutables: El software no se

de esta manera. Al concebir un sistema informático de manera global hay que
pensar en todos los elementos que intervienen: hardware , software y personas.
Los procedimientos que han de seguir esas personas para usar correctamente el
sistema son también elementos software. Igualmente es software toda la docu-
mentación del desarrollo 1 necesaria para poder mantener el producto después
de haber sido puesto en explotación.

■ El desarrollo de software es sólo una labor de programación: Falso, pues no se

puede limitar el trabajo de desarrollo sólo a la fase de codificación. Las tareas
de análisis y di~eño no son meras actividades cornplementarias que puedan ser
vistas como un costo añadido, necesario para organizar el trabajo en equipo.
Las tareas de análisis y diseño son el fundamento para todo el resto del desarro-
llo, igual que el proyecto de un arquitecto o de un ingeniero es necesario para
acometer la construcción de un edificio u otra obra pública, que no consiste
simplemente en colocar materiales uno sobre otro.
 SCLUSIONES 27

■ E s natural que el software contenga errores. :'\o exactamente. Aunque es cierto

que el desarrollo de software, como toda actividad humana, es susceptible de
errores, no es admisible que los productos software siempre contengan errores.
Si un producto hardware contiene d efectos. se rechaza. Con el software debería
ocurrir lo mismo. Por desgracia el software erróneo no puede simplemente sus-
tituirse por otro sin defecto, ya que todas las copias del producto sofhvare son
exactamente iguales. Los errores del software son errores durante su desarrollo
inicial, y deben reducirse a un nivel tan bajo como en el diseño de los productos
hardware durante la fase de desarrollo de ingeniería.

1.6. Conclusiones
El software lo componen el conjunto de programas que gobiernan el comporta-
- to de cualquier sistema basado en computador. En muchos casos el software
e entidad en sí misma, y puede ser considerado un producto propiamente dicho.

La aplicación del conocimiento y del método científico a la elaboración del soft-

'lrare. dan lugar a la disciplina que se conoce como ingeniería del software.

El ciclo de vida del software, igual que el de cualquier otro producto que se pueda
aaborar, es la evolución del mismo desde el momento que se concibe hasta que se
~jade utilizar.

1. 7. Ejercicios propuestos
l. Piénsese en diez sistemas con los que se interactúe usted la vida diaria que estén
controlados por algÚn-tipo de programa. Hágase un listado e intente describir
la funcionalidad de cada uno de ellos.
2. Supóngase el diagrama de las tasas de fallos de un coche en el tiempo. ¿Qué
diferencias puede tener respecto a un producto de software?
3. Compárase el ciclo de vida de una lavadora con el de un programa de edición
de texto. Elabórese un listado con las particularidades de cada uno de ellos.

-1. Repásese las siete categorías de sofrware y dar diez ejemplos de cada una de
ellas.
0. l:na práctica muy extendida para reut ilizar software es "cortar y pegar" frag-
mentos de código. E sto puede llevar a que un trozo de código se encuentre
 INTRODUCCIÓN

rq>etH..lu lllUd1a:c. n~ces en un progTmna. ¿Cómo afecta est,o al manteninücuto

del programa'? ¿Cómo se podrían solve11tarne los efectos negativos del código
<luplicado"?

6. Lo~ pri11cip, 10s términos acuñados en est.e capítulo son software e ingeniería de
;e;oftware. Explíquense ra.zonada1ncnte las diferencias entre ambos térnlinos.

T. Argurn¡'.>ntesf' la corrección o falsedad de las siguientes afir n1aciones:

• ''Los rf'qucrimientos de software ca.inbian continuamente, pero el cambio se

ru,iruila nm facilidad debido a que el software es flexible".
• "Una Vf'Z qu<." se escriba el progra1na y se hace que funcione, el trabajo ha
terminado"
• "La ingeniería de software hará que Sf' genere documf'ntación voluminosa f'
innecesaria, e invariablemente rclrasará el trabajo".
Capítulo 2

El Ciclo de Vida del Software

2. 1 . Introducción
Uno de los conceptos que se estudian en este curso es el ciclo de vida del software.
En este capítulo se va a definir qué es el ciclo de vida de un producto, cómo es
.-: ciclo de vida del software, qué fases tiene y qué posibles E>Squemas organizativos
ueden tener esas fases, dando lugar a ciclos de vida diferentes. Se presentará además
qué tipo de ciclo de vida es el más adecuado según qué proyecto o producto se esté
u esarrollando. La descripción pormenorizada de las diferentes fases del ciclo de vida
t:el sofb,vare serán descritas en posteriores capítulos de este libro.

2.2. Objetivos
El alurnno, después de leer este capítulo, debe conocer qué es el ciclo de vida
J e un producto comercial y en particular del software. Así mismo debe conocer las
:iiferentes fases que integran este ciclo de vida, la documentación resultante de cada
fase y los diferentes enfoques en la organización del ciclo de desarrollo del sofhvare.
Para completar el capítulo se presenta la fase de mantenimiento del software.

2.3. El ciclo de vida d e un producto

El ciclo de vida es algo propio de un ser vivo: nacE>, crece o cambia: se reproduce o
diversifica y muere o desaparece. El estudio de cualquier concepto productivo, desde
una óptica del ciclo de vida: lleva implícito una evolución temporal que debe ser te-
nida en cuenta en todos los momentos del ciclo. Cuando un ser vivo nace: igulamente
lleva implícitas cualquiera de las fases posteriores por las que va a pasar su Yida.

29
30 CICLO DE VIDA

Contempla!' la producción de un bien desde este planteamiento obliga, desde el

momento de su concep ción , a tener en cuenta que a lo largo de su vida útil va a pasar
por la secu encia de fases de su ciclo.

Cuando la pro ducción de un bien se hacía de modo artesanal, se contemplaba

como un h ech o aislad o que se realizaba por encargo y se entregaba cuando estaba
finaliz a d a s u elaboración. Dependía de la habilidad del artesano, de su honestidad
y d e su capacidad de convicción, que el cliente quedara satisfecho con el producto
encargado.

Desde el punto de vista de la producción industrial de cualquier bien, hay que

distinguir entre las fases de ingeniería, producción y comercialización. En cada una
de estas fases se encuentran distintos ciclos de vida de los productos que se "ingenian"
o desarrollan, se producen y finalmente se comercializan.

El ciclo de vida en la. ingeniería pasa por etapas como prediseño o diseño preli-
minar , diseño básico , diseño ejecutivo y diseño final. También se añaden a este ciclo
de vida las acciones de diseño necesarias durante el período de explotación o funcio-
namiento del producto , acciones de mantenimiento y de mejora del product?.

Si se plantea cómo sería. el ciclo de vida en la producción industrial de un bien ,

también tendría s u s fases. Desde la implantación de su producción, introducción de
cambios, adaptaciones o nuevos elementos en la. planta de producción, al mante-
nimiento d e la producción del bien , aseguramiento de la calidad de la producción,
op timización de los r ecursos, eficiencia de los procesos que intervengan en la. pro-
d ucción y la elim inación de la producción del bien con el reciclaje de los recursos
existentes p ara produ cir el bien, reciclado de la mano de obra y eliminación final de
la p r oducción. Tod as estas actividades serían realizas por la dirección de la planta
d e p r oducción o serían encargadas a una empresa de ingeniería que lo organizase.

Si se analiza el ciclo d e vida de un producto en el mercado, se enc<?ntraría la evo-

lución que experimentan las ventas de ese producto mientras se encuentra disponible
en el m ercado. Las fases por las que pasa este ciclo suelen ser: introducción en el
mercado, crecimiento, madurez y declive. Dependiendo del tipo de producto del que
se trate, estas fases pueden tener duraciones , actividades y costes distintos. Estas
son actividades propias del marketing y se realizan por la sección de marketing de la
empresa o son subcontratadas a empresas especializadas en estos campos.

T~:miendo en cuenta las característ icas particulares del producto "software" ya

explicadas en el capítulo 1, a continuación s e verá cómo es el ciclo de vida del software.
 -::TCLO DE VIDA DEL SOFTW:A.RE 31

El ciclo de vida del software

S-Pgún lo que se ha explicado en el epígrafe anterior. deberían contemplarse cual-
•:::::aa de los posibles ciclos de vida mencionados. El software es un producto co-
...--.:--ial. que debe ser generado de acuerdo con las pautas utilizadas en el sector de
producción industrial y que debe ser comercializado con prácticas adecuadas del

Así. cuando el software se está diseñando, se debe tratar como un producto de

zPniería Cuando se está produciendo, como cualquier producto producido por la
_:.!Stria. Finalmente, cuando se está comercializando, deben seguirse las pautas
:tuales del mercado. Evidentemente deben considerarse las particularidades del
dueto en cualquiera de las citadas fases, pero no se debe olvidar lo genérico del

El ciclo de vida del software que se va a presentar en sus diferentes modalidades.

-ará centrado en la parte de ingeniería, no en vano, ya que éste es un curso para
_ 5enieros. Se dejará para otras asignaturas u otras profesiones los otros ciclos de
rida. Se estudiará el ciclo de vida de la ingeniería de software. El ciclo de vida del
f-t-ware abarca el proceso de desarrollo y el mantenimiento necesario durante su
explotación.

Las fases en el proceso de desarrollo del software suelen ser la13 siguientes:

• Análisis
■ Diseño
• Codificación
• Integración
• .Nlantenimiento

Cada una de estas fases lleva consigo una serie de tareas que deben realizarse,
~ambién conocidas como actividades. Estas tareas generan, como resultado, docu-
mentos donde se presenta el trabajo realizado. Estas diferentes fases deben poder
rompletarse por grupos de trabajo independientes, quienes trabajarán de manera
secuencial o simultánearnente. El producto del trabajo de un grupo será utilizado
por el grupo de trabajo siguiente.

Imaginemos un arquitecto que, después de escuchar los deseos o requisitos de un

cliente y analizar sus preferencias, le plantea un posible diseño de la casa que le
32 CICLO DE VIDA

ha encargado. El trabajo del arquitecto consiste en recoger toda la información del

diente y procesarla para comprobar que las peticiones del cliente son posibles de
realizar dentro del presupuesto establecido. Después elabora unos planos y una me-
moria de ejecución del proyecto. Los planos y el proyecto son el resultado de esta fase.

Estos documentos serán utilizados posteriormente por el cliente que los apruebe,
por la ad1flinistración que los supervise y la empresa constructora que materialice el
proyecto. Algo extremadamente importante es que estos mismos documentos servirán
para que todas las partes implicadas puedan validar sus compromisos; el arquitecto
con el propietario, el constructor con el arquitecto y con el propietario, el propietario
con la administración. El modo de hacerlo será validar que la realidad construida
coincide con lo descrito en los planos.

Esto que se acaba de describir GS un conjunto de actividades de ingeniería o

arquitectura encaminadas a la elaboración de un proyecto. Cuando lo que se quiere
construir es software en lugar de una casa: una máquina o una explotación agrícola,
las fases de desarrollo de la elaboración del proyecto son bastantes parecidas.

2. 5. F ases d el ciclo d e vida del software

Como se ha comentado en el epígrafe anterior las fases habituales en el proceso
de software son: análisis, diseño, codificación, integración y mantenimiento.

2.5.1. Análisis
En esta fase se procede a analizar las necesidades que tienen los usuarios del
futuro sistema software y que deben ser satisfechas mediante el funcionamiento del
mismo. El diente que realiza el encargo expone sus necesidades, requisitos que debe
cumplir el software :v la empresa que va a realizarlo los recoge y analiza. De acuerdo
con esto. la e1npresa, elabora una especificación precisa del sistema a desarrollar.

2.5.2. Diseño
Consiste en elaborar un esquema o diseño donde se contemplen los elementos
necesarios para que el sistema funcione según con lo especificado en el análisis. En
esta fase no sólo se debe diseñar el sistema para su funcionarniento, también debe
establecerse la organización del sistema para su construcción. -Cn adecuado diseño
permite la optimización de los recursos en la producción del mismo. El resultado de
la fase de diseño suele ser un documento de carácter gráfico, donde se presentan todo~
los elementos componentes del sistema y la organización pormenorizada de cada un(.
de ellos. En la fase de diseño se elaboran los planos de lo que se va a construir.
 rl\IENTOS QUE SE GE.YERAX ES EL CICLO DE \ "ID_.\ 33

C odificación
En t•sta fase se produce materialmente lo que ,-a a hacer funcionar el sistema
;-are. Se construirá: por separado. cada uno de los elementos que se han definido
ta fa~c de disefio utilizando para ello las herramientas pertinentes: lenguajes de
--~3.lliación, sistemas de bases de datos. sistf'mas de información, etc. Así mismo
con:-truirán los elementos necesarios para la comprobar que lo construido funciona
tamente.

- .-1. Inte gración

Después de construidos todos los elementos se procede a unirlos todos con el
~h·•J de construir el sistema completo. En esta fa.e;(' deben realizarse pruebas
ustivas para garantizar que el conjunto funciona durante la explotación.

_.5.5. E xplotación
E.:.-ta fase no forma parte del ciclo de desarrollo de un producto software aunque si
uyc en el resto de las fases que se están describiendo. Esta fase comprended perío-
de funcionamiento de la aplicación. Es el objctiYo final del producto desarrollado
~ n su devenir marcará fases posteriores de desarrollo como la de mantenímiento.

2.5.6. M ante nimiento

Durante la fase de explotación del software ei:; necesario realizar cambios. bien pa-
corrc-gir errores no detectados en las fases de desarrollo o para introducir mejora.e;.
Cual<111iPr sistema que se ponga en funcionarüicnto durante un período de tie1nµu
recibe uua casuística ampliada sobre la supuest,a en su desarrollo. Ante estas nuevas
, tuaciones de funcionamiento el sistema debe e\'olucionar para responder a las nue-
vas dc1na.ndas. Esta evolución se desarrolla en la fase de mantenimiento.

El resultado de cada una de estas fases se plasma en un documento. Estos docu-

('nto::; permiten independiiar las fases y posibilitan que grupos de personas distintas
u-abajPn en cada fase especializándose según la fase eu la que se trabaje en analista,
diseñador, programador. etc.

2.6. Docume ntos que se gen eran en el c iclo de vida

Los trabajos realizados en cada una de las fru;es del ciclo de vida se describen
formaltnente en cada uno de los siguientes doc11111entos.
34 CICL O DE VIDA

2.6.1. Docume n to de requisitos del software

(En inglés SRD: Software Requirements Dorument) como producto de la fase de
análisis. Consiste en una especificación precisa y completa de lo que debe hacer el
sistema, prescindiendo de los detalles internos de cómo lo debe hacer. En un proyecto
de arquitectura sería una lista detallada. acompañada con diagramas, de todas los
elementos que quiere el propietario para su casa.

2.6.2. Documento de diseño del software

(En inglés SDD : Software Design Document) como producto de la fase de diseño.
Consiste en una descripción de la estructura global del sistema y la especificación de
qué debe hacer cada una de sus partes así como la combinación de unas con otras. En
un proyecto de arquitectura equivaldría a los planos que d iseña el arquitecto indican-
do todas y cada una de las partes del edificio, los detalles constructivos particulares
incluyendo directivas de cómo se deben unir todos los element os.

2.6.3. Código fuente

Como producto de la fase de codificación . Con t iene los programas fuente, en el
lenguaje de programación elegido, debidamente comen tados para conseguir que se
entiendan con claridad. En cualquier otro proyecto está sería la fase de construcción
o de fabricación de cada uno de los elementos necesarios para construir lo que se
quiere.

2 .6 .4. E l sist e m a software

Es lo que se denomina el ejecut able como producto de la fase de integración.
Obviamnte no se trata de un tocumento escrito, sin embargo deben documentarse
las pruebas realizadas para su puesta en marcha y debe describirse el procedimiento
de integración.

2.6.5. Documentos de cambios

Tras cada modificación realizada en la fase de mantenimiento del software debe
quedar constancia escrita de las acciones realizadas. Est os documentos suelen tener la
siguiente estructura para cada modificación realizada: Información sobre el problema
detectado, descripción de la solución adoptad a y las modificaciones realizadas sobre
el sistema para aplicar dicha solución.
 VID. OS DE CICLO DE VID.4. DEL SOFTlV.4.RE 35

Tipos de ciclo de vida del software

se de En esta sección se verá cómo se pueden organizar las diferentes fases que integran
ciclo de vida del software según diferentes enfoques.

__7.1. Ciclo de vida en cascada

El ciclo de vida en cascada es la secuenciación de las distintas fases de la pro-
jXión del software que se han descrito. Como elementos de unión entre cada fase
ecen los d iferentes documentos que se generan en cada fase. En la figura 2.1 se
roe ver la organización de un ciclo de vida en en cascada.
ño.
de Cada fase se separa claramente de la siguiente lo que permite la independización
En realización. Los elementos de unión entre las fases son los documentos generados
tn-
las mismas. El modelo en cascada obliga a terminar cada fase antes de comenzar
·es la siguiente. Cada fase fundamenta su trabajo en los resultados de la anterior.
_ra detectar errores lo antes posible y evitar que se propaguen a las fases posteriores
..-stablecen procesos de revisión al completar cada fase, antes de pasar a la siguiente.

E sta revisión se realiza sobre la documentación generada en cada fase de manera

rmal siguiendo una lista de comprobaciones establecida de antemano. Si se detectan
errores en una fase será necesario corregirlos en esa fase y todos los puntos del ciclo
e 0 ,ida anteriores.
l

Análisis Documento de Requisitos

Documento de Oiseilo

1
, _ _ Código Fuente
''
:'
' 1----. Sistema en explotación
1
1
1 1 1 ••
1 1 1 1 Mantennrnento
1 1 1 1
11__ _______ :t1 ______ I ' __ ______ I 1 ___ _____ _

Figura 2.1: Ciclo de vida en cascada

El modelo de ciclo de vida en cascada se puede ampliar y pormenorizar hasta el

nivel que se desee dependiendo de la complejidad del sistema que se esté desarro-
..:ando. En la figura 2.2 se puede ver un ciclo de vida ampliado donde se contemplan
:ases adicionales como la Ingeniería de sistemas o la arquitectura del sistema.
 36 CICLO DE VIDA

Ingeniería de
Especificación del sistema
sistemas

1
1 Análisis Especificación del sofuvare
L_

1
1
Diseño Documento de Arquitectura del Sistema
L_
Arquitectónico

1
1 Diseño Especificaciones de módulos y funciones
l_
Detallado

1
1 Codificación Código fuente
L_

1
1 Pruebas de Módulos utilizables
l_
unidades

1
1 Pruebas de Sistema aceptado
l_
sistema

Exp!otaaón y
mantenimíento

Figura 2.2: Ciclo de vida en cascada ampliado

2.7.2. Ciclo de vida en V

Este rnodelo se hasa en una secuencia de fases análoga a la del modelo en cascada,
pero se da especial importancia a la visión jerarquizada que se va teniendo de las
distintas partes del sistema a medida que se avanza en el desarrollo. En la figura 2.3
se recoge esta idea en un diagraina bidimensional: en que el eje horizontal representa
avance en el desarrollo y el eje vertical corresponde al nivel de detalle con que se
trabaja en cada fase.

En este diagrama ven10s cómo en las fases iniciales, en la rama izquierda desct>n-
dente, el sistema software se va descomponiendo en elementos cada vez más sencillos.
hasta llegar a las sentencias del lenguaje de programación. A partir de ahí el sistema
se va construyendo poco a poco a base de integrar los elementos que lo componen, si-
gitiendo la rama ascendente, hasta disponer del sistema completo listo para ser usado.
 JS DE CICLO DE l'IDA DEL SOFTl,v:4.RE 37

A.: igual que en el modelo en cascada, existendi,-ersas variantes del modelo en V,

:;e caracterizan por reconocer o no determinados niveles de d~talle intermedios.

Mundo Real

Análisis Explotación

i
NIVEL
Sistema
Validación
-···-·-·- -·--·-·---·- ..:►-.... ·- -·-·-···· -·-·- -·-····
Módulo

Sentencia

Figura 2.3: Ciclo de vida en V

El diagrarna de la figura 2.3 corresponde a un modelo en V simplificado. En las

tividades situadas en un nivel determinado se trabaja sobre una unidad del nivel de
calle superior, que se organiza en varias unidades del detalle inferior. Por ejemplo,
urante la codificación se trabaja con un módulo que se organiza y construye con
-Pfltencias del lenguaje. Durante las fases d~ diseño y de integración se trabaja con
~ sisten1a. software, que se organiza (durante el diseño) o se construye ( durante la
mregración) con varios módulos.

En el diagrama en V se puede poner de manifiesto de manera elegante que el

:re:,7lltado de una fase no sólo sirve como entrada para la fase siguiente, sino que
también debe utilizarse en fases posteriores para comprobar que el desarrollo es co-
rrecto. En particular la comprobación de que una parte del sistema cumple con sus
specificaciones se denomina verificación, y en el diagrama simplificado de la figura
2.3 aparece a un nivel de módulo. La comprobación de que un elemento satisface las
nt'Cesidades del usuario identificadas durante el análisis se denomina validación, y
en el diagrama aparece a nivel del sisten1a completo.

Al igual que en el modelo en cascada, se p11cdc establecer modelos de ciclo en V

más elaborados, con un mayor número de fases. En la figura 2.4 se representa una
c.U'iante ampliada de este modelo.
38 CICLO DE VIDA

Mundo Real

Validación del sistema

software
Venficadóndel sistema

Sistema

Oisel',od, la
~ Venficadóndes..bs!stemas

subsistema ---·-·-·-·-·::--:::::::::_ ::::::::::::::::::::::::_--:::::_--:::1 -·

VerifMódulos
Módulo

Sentencia

Figura 2.4: Ciclo de vida en V, ampliado

2.8. Prototipos
Qué es un prototipo Los modelos clásicos tienen el inconveniente de estar muy
orientados hacia una forma de desarrollo lineal, en que cada fase del desarrollo tiene
una duración limitada en el tiempo, de forma que una vez terminada una fase pue-
den dedicarse a otra cosa los recursos humanos o materiales que se han empleado en
ella. Esto quiere decir que no se contemplan de manera organizada las vueltas atrás
necesarias ocasionalmente al detectar algo inadecuado en una fase anterior durante
una fase posterior del desarrollo.

Estas vueltas atrás resultan así bastante costosas, por lo que los modelos clásicos
insisten mucho en las actividades de revisión del resultado de cada fase, para evitar
los retrocesos, en lo posible. Desgraciadamente hay situaciones en que no es posible
garantizar adecuadamente al concluir una fase que su resultado es correcto. Esto
ocurre, por ejemplo, en sistemas innovadores, en que no se dispone de una experien-
cia previa para contrastar si las decisiones adoptadas durante el análisis y diseño
son apropiadas. El empleo de prototipos puede solucionar, al menos en parte, este
problema.

-Cn prototipo es un sistema auxiliar que permite probar experimentalmente cier-

tas soluciones parciales a las necesidades del usuario o a los requisitos del sistema. Si
 39

-.oripo se desarrolla con un costo sensiblemente inferior al del sistema final, los
r ::..-.:s- cometidos en el mismo no resultarán d emasiado costosos, ya que su incidencia
limitada por el costo total del desarrollo de dicho prototipo, y normalmente será
_: ...r. ya que siempre habrá algo del prototipo que sea aprovechable para el resto
_PSa.rrollo.

Para reducir el costo del desarrollo del prototipo, con respecto al del sistema final,
puede:

■ Limitar las funciones, y desarrollar sólo unas pocas.

• Limitar su capacidad, permitiendo que sólo se procesen unos pocos datos.

• Limitar su eficiencia, permitiendo que opere en forma lenta.

• Evitar limitaciones de diseño usando un soporte hardware m ás p otente.

ra Reducir la parte a desarrollar, usando un apoyo software m ás potente.

~ormalmente se distinguen dos clases de prototipos, según se pretenda aprovechar

código del mismo, o sólo la experiencia obtenida con él, tal como se indica a
rinuación.

2 . . l. Prototipos rápidos
Estos prototipos son aquellos cuya finalidad es sólo adquirir experiencia, sin pre-
-ender aprovecharlos como producto. Se denominan también prototipos de usar y
irar (en inglés throw-away) , y maquetas (en inglés mockup) cuando su funcionali-
dad o capacidad es muy limitada.

Estos prototipos se aprovechan dentro de las fases de análisis y / o diseño de un

sistema, para experimentar algunas alternativas y garantizar en lo posible que las
decisiones tomadas son correctas. Una vez completadas estas fases el sistema final
~ codifica totalmente part iendo de cero, es decir , sin aprovechar el código del pro-
-.otipo. La figura 2.5 representa una variante del ciclo de vida en cascada usando un
prototipo de usar y tirar durante la fase de análisis.

Lo importante en estos prototipos es desarrollarlos en poco tiempo, y de ahí el

:iombre de prototipos rápidos, para evitar alargar excesivamente la duración de las
fases de análisis y diseño. Hay que tener en cuenta que el desarrollo completo y
experimentación con el prototipo o prototipos es sólo una parte de alguna fa.se del
ciclo de vida del sistema final.
40 CICLO DE VIDA

-----------------------------------------
Análisis
Inicial

Definición del
Prototi¡:m

1 Construcción
1 del Prototi~o
1
1
1
1_ _ _ _ _
Análisis del
Análisis 1
sistema ,1
·------------------------ --------------~ 1

L..--- Diseñt:>

Codificación

ExJ)"lotación y
mantenimiento

Figura 2.5: Análisis con prototipo rápido

2.8.2. Prototipos evolutivos

Otra rr1anera de utilizar un prototipo es tratando de aprovechar al max1mo su

código. En este caso el prototipo se desarrollará sobre el mismo soporte hard,va-
re/ software que el sistema final, pero sólo realizará algunas de las funciones, o en
general, será sólo una realización parcial del sistema desea.do.

El prototipo inicial se construirá tras unas fases parciales de análisis y diseño.

La experimentación con el prototipo permitirá avanzar en esas fases parciales: y a
continuación ampliar el prototipo inicial para ir convirtiendolo en el sistema final
mediante adiciones sucesivas.
_4 MODELO EN ESPIRAL 41

Cocf,f,c.ac10n

U.Ode l
prototipo
,.,.,.,óocul.2-'-

Figura 2.6: :.Vlodelo del ciclo de vida eYolutivo

De esta manera se van construyendo sucesivas versiones del prototipo. ('arla vez
, complet as, hasta obtener el sist ema deseado. Al mismo tiempo los documento::.
especificación , diseño, etc. van siendo también desarrollados progresn:amente.

E:,,ta forma de desarrollo puede formalizarse en un modf'lo de ciclo de ";da eYolu-

:n-o. tal como el que se representa en la figura 2.6. Este modelo puede considerarse
como un proceso iterativo en bucle sobre el modelo en cascada, de manera que en
ca.da iteración se hace sólo una parte del desarrollo. avanzando un poco en cada fase.
Cada iteración utiliza todo lo que se ha generado en la iteración anterior, y produce
un nuevo prototipo, que es una nueva versión parcial del sistema, hasta llegar final-
~ente al sistema completo, con lo que se sale del bucle de iteracionf's y termina el
proteso.

2.9 . El modelo en espiral

El modelo espiral desarrollado por B. Boehm[Boehm88] puede considerarse como

w1 refinamiento del modelo evolutivo general. Con10 elemento rustintivo respecto a
otros modelos de ciclo de vida, introduce la actividad de análisis de riesgo como
elemento fundamental para guiar la evolución del proceso de desarrollo.

El ciclo de iteración del m odelo evolutivo se conYierte en una espiral al añadir co-
mo dimensión ramal una indicación del esfu <:'rzo rotal realizado hasta cada momento ,
que será un valor siempre creciente, tal como s(' indi< a en la figura 2. 7
42 CICLO DE VIDA

PLANIFICACIÓN ANÁLISIS DEL RIESGO

Costo acumulado

,..
, ...,•
-\
'\

", Ava.nce «n fll

~ d-rroJlo

EVALUACIÓN
1 /NGENJERÍA
1

--', '''
1

''~U~s sucniw'O.s

Figura 2. 7: l\tlodelo en espiral

Las distintas actividades se representan sobre unos ejes cartesianos, conteniendo

cada cuadrante una clase particular de actividades: PLANIFICACIÓ::'-J, ANÁLISIS
DE RIESGO. IXGE~IERÍA y EVALUACIÓN , que se suceden a lo largo de cada
ciclo de la espiral. La dimensión angular representa el avance relativo en el desarro-
llo de las actividades de cada cuadrante. En cada ciclo de la espiral se realiza una
parte del desarrollo total, siguiendo la secuencia de las cuatro clases de actividades
indicadas.

Las actividades de planificación sirven para establecer el contexto del desarrollo,

y decidir qué parte del mismo se abordará en ese ciclo de la espiral.

Las actividades de análisis de riesgo consisten en evaluar diferentes alternativas

para la realización de la parte del desarrollo elegida, seleccionando la más ventajosa
y tomando precauciones para evitar los inconvenientes previstos.Las actividades d e
ingeniería corresponden a las indicadas en los 1nodelos clásicos: análisis, diseño, codi-
ficación, etc. Su resultado será ir obteniendo en cada ciclo una versión más completa
del sistema.
 43

Las actividades de evaluación analizan los resultados de la fase de ingeniería, ha-

:n:ualmente con la colaboración del "cliente'' para quien se realiza el desarrollo. El
ss=tltado de esta evaluación se utiliza como información de entrada para la planifi-
"ón del ciclo siguiente.

&>gún qué parte del desarrollo se decida hacer en cada ciclo, tendremos distintas
:riantes del modelo espiral, que podrá así adaptarse a cada proyecto concreto. Por
plo, sí en cada vuelta se realizase exactamente una de las fases del modelo en
~da, el modelo espiral coincidiría con dicho modelo en cascada en los aspectos de
_ niería. Si en cada vuelta se realiza lo suficiente de cada fase como para obtener
rersión parcial ampliada del sistema, el modelo espiral coincidirá con el evolutivo.
odas formas el modelo espiral siempre se distingue por las actividades de análisis
riesgo, que no aparecen en los otros modelos.

2.10. Programación e xtrema

l:no de los riesgos mayores, a los que se enfrentan las empresas de software, es
-ener a los clientes satisfechos con los productos desarrollados, en cuanto a calidad,
ñempo de entrega y precio. l\lluchas empresas desarrolladoras utilizan metodologías
?()':O o nada rigurosas para ahorrarse los costes de las fases previas a la producción
el software y entregar el producto en menos tiempo. Total , los clientes no quieren un
m ntón de planos y el coste de su producción, sino un software que funcione cuanto
antes.

Los clientes dan por hecho, que todo lo que ellos pidan, la empresa de software
~abe hacer bien y con g~.r~ntí:=iR, aunque sea la primera vez que se haga. Si no
~ así, buscan otra empresa más rápida, mejor y más barata, "que seguro que la
encuentran". Estos planteamientos seguro que no los tienen si se trata de adquirir
maquina.ria, vehículos o construir edificios. El software es así.

El panorama puede resultar desolador, las alternativas son: mantener una meto-
dología estricta, en pos de obtener un producto con garantías, awnentando costes y
tiempo de entrega, con riesgo de perder el cliente o dejar la metodología a un lado
y atender al cliente cuanto antes y a buen precio con unos riesgos evidentes. Existe
otra alternativa: las metodologías de desarrollo ágil, entre las que se encuentra la XP.

La programación extrema es una nueva metodología introducida por Kent Bcck

'Becküü] con un único objetivo: ser capaz de responder de una forma rápida y de
calidad a las exigencias de los clientes, por lo tanto la satisfacción del cliente. Si bien
es cierto que éste debería ser el objetivo últüno de cualquier rnetodología, la progra-
 44 CICLO DE VIDA.

mación extrema se centra en ello. dando por sentado que los requisitos del cliente
carnbian a lo largo del proceso y que hay que ser capaz de adaptarse a ellos de una
forma muy ágil.

Según el propio Beck, la programación extrema es "un proceso ligero , de bajo ries-
go, flexible, predecible, científico y <liYertido de desarrollar software". El equipo de
desarrollo, para lograr este proceso, tiene que basarse en cuatro valores principales,
los cuales están muy interrelacionados unos con otros:

SENCILLEZ. Sin ella no es posible crear un código ágil que se adapte de forma
rápida a las necesidades cambiantes del cliente. Se debe programar sólo aquello que
nos han pedido, sin pensar en lo que nos podrían pedir mañana. Si nos lo piden 1na-
ñana lo programamos mañana. Además, para conseguir que el software se n1antenga
sencillo , utilizaremos la recodificación de forma continua, es decir reescribir código
antiguo de otra forma que aporte más sencillez.

COl'vlU~ICACIÓK. En programación extrema se potencia el trabajo en equipo,

tanto dentro del grupo de desarrollo como con el cliente. Algunas prácticas en este
sentido son el código autodocunientado, programación por parejas, propiedad colec-
tiva del programa, cliente in-situ o el empleo obligado de la utilización de estándares
de codificación.

RETROALI~IENTACIÓ~. La retroalimentación funciona con el cliente y con el

propio siste1na. El cliente está integrado dentro del equipo de desarrollo y los ciclos
del proceso de softv:arc son muy cortos, por lo que en muy poco tiempo se evalúa el
diseño y se cainbia si no curnple los requisitos del cliente. Por otro lado, las pruebas
unitarias siste1náticas en el momento y la integración continua permiten tener cono-
cimiento en ticrnpo real sobre la respuesta del sistema.

VALENTÍA. La valentía es la que permite a los programadores afrontar la recodi-

ficación continua del programa, aceptar las modificaciones de los requisitos, escuchar
las peticiones del cliente a lo largo de su trabajo, realizar pruebas unitarias tras la
programación de cada unidad o desechar un código obsoleto. La programación cx-
tre1na fomenta que los miembros del equipo trabajen con confianza, sin esconderse,
aportando valor y, por lo tanto , eliminando algunos de los problemas de los grandes
grupos de trabajo bajo una metodología más "tradicional". En esta línea Kent Beck
introdujo , posteriormente a su primera propuesta, el respeto hacia el trabajo de los
otros miembros del equipo corno otro valor clave dentro de la programación extrema.
 -x TEHIMJENTO DEL SOFTlVARE 45

• Diseí'\o s mple • Soluciones en punto

• Historias del usuario • Tarjetas CRC • Prototipos
• Valores
• C..-iterios de pruebas d~
aceptación
• Plan de Iteración

Rediseí'lo
< ...
Programación
por parejas
¡... J ,!IJ)
r---------------," •
;ruabas
' ... ~ ~

Prueba unitaria
"·
fe • Incremento del software • Integración continua
[ • Veloá!fad ~-lcut~_d•f,l'~ecto
Pruebas de
aceptación

Figura 2.8: Programación extrema por vrww.codejobs.biz

Desde un punto de vista fonnal, la programación extrema propone ciclos del pro-
;e,v de software muy cortos y rápidos, realizando pruebas de unidad inmediatas y
!:::t:a integración continua. De esta forma se van creando tantas pequeñas versiones
prototipos como sea posible, las cuales son testeadas antes de continuar. Cada
n2 que se considera preciso para eliminar código obsoleto o demasiado complejo, se
cecodifica, realizando las pertinentes pruebas a continuación para eliminar posibles
Err)res o efectos secundarios del nuevo código. Igualmente se replanifica y rediseña
cor; cada nueva versión, en un proceso iterativo hasta cumplir todos los requisitos
de~ cliente. La figura 2.8 muestra un esquema básico del proceso.

~o se entra más a fondo en esta metodología porque será abordada en asignaturas

~teriort=>..s.

2.11. Mantenimiento del software

Las actividades fundamentales del desarrollo de soft.,vare, correspondientes a las
fases de análisis, diseño, codificación y pruebas se describen con detalle en los si-
guientes capítulos. La fase de mantenimiento es algo particular, y se describe en
e:.te primer capítulo. Esta etapa final denominada mantenirniento, o explotación y
mantenimiento, no suele representar una adiYida<l específica, sino que consiste nor-
46 CICLO DE '\i7D

malmente en repetir o rehacer part<' de las actividades de las fases anteriores pat
introducir cambios en una aplicación de software ya entregada al cliente y puesta e
explotación.

A continuación se analiza con más detalle en qué consiste el proceso de mantc

niiniento de una aplicación software, y porqu é es necesario realizarlo, en lugar d
seguir explotando la aplicación original tal como se desarrolló la primera vez.

2.11.1. Evolución de las aplicaciones

Una de las características del software, que lo diferencian de los p roductos hard
ware, es la ausencia de deterioro o envejecimiento durante su utilización. U n sistem,
software funcionará con la misma corrección al cabo de los años que el primer dia d•
su empleo. ¿Porqué es necesario modificarlo?

H ay varios motivos para ello, que dan lugar a distintos tipos de mantenimientc
con diferentes objetivos, entre ellos:
• l\{antenim icnto correctivo.
• 1,lantenimiento adaptativo.
■ ~Iantenimiento perfectivo.
El mantenimiento correctivo tiene como finalidad corregir errores en el producto
software que no han sido detectados y eliminados durante el desarrollo inicial del
DlÍ::,mo. Este tipo de mantenimiento no debería existir si el desarrollo inicial se hu-
biera n :alizado con las debidas garantías de calidad. Sin embargo es prácticamente
imposible evitarlo. ya que el desarrollo de sofh,·arc. como cualquier otra actividad
humana. está sujeto a errores.

El mantenimiento adaptativo se produce en aplicaciones cuya explotación du-

ra bastante::; ario::;. de 1nanera que los elementos básicos hardware y software (máqui-
na , sbtema operativo) que constituyen la plataforma o entorno en que se ejecutan
evoluciona a lo largo de ese tiempo, rnodificándose parcialmen te la interfaz ofrecida
a las aplicaciones que corren sobre ellos. Esto exige modificar una aplicación para
adaptarla a las nuevas características del entorno si se quiere seguir utilizándola.

Finalmente el mantenimiento perfectivo aparece sobre todo en aplicacionf's

sujetas a la competencia de mercado. Este tipo de mantenimiento es necesario para
ir obteniendo versiones mejoradas del producto que permitan mantener el éxito del
mismo. Tan1bién se realiza sobre aplicaciones en que las necesidades del usuario
evolucionan. y por tanto h ay que modificar los requisitos iniciales del producto para
seguir satisfaciéndolas.
 ITESIA-fIENTO DEL SOFTWARE 47

.2. Gestión de cambios

Con independencia del objetivo concreto del mantenimiento, las actividades a
zar durante el mismo son básicamente la realización de cambios sucesivos sobre
deterrninada aplicación o producto software ya desarrollado. La aplicación de
reas de ingeniería a la actividad de mantenimiento exige organizar y gestionar
,.~-r:-,,,,·i adamente el desarrollo de estos cambios.

Podríamos distinguir dos enfoques diferentes en la gestión de cambios. dependien-

el mayor o menor grado de modificación del producto .

.":)] el cambio a realizar afecta a la mayoría de los componentes del producto, dicho
io se puede plantear como un nuevo desarrollo, y aplicar un nuevo ciclo de vida
_..___.~ el principio, aunque aprovechando lo ya desarrollado igual que se aprovecha
prototipo.

Si el cambio afecta a una parte localizada del producto, entonces se puede orga-
___,...,,.... como simple modificación de algunos elementos. Es importante darse cuenta
que un cambio en el código del producto software debe dar lugar además a una
sión de los elementos de documentación afectados. es decir, carnbiar el código de
2t:nos módulos puede requerir además modificar los documentos de diseño o inclu-
en el caso de mantenimiento perfectivo, modificar el documento de especificación
requisitos.

Desde el punto de vista de gestión la realización de cambios se puede controlar

,. ante dos clases de documentos, que a veces se refunden en uno solo:

■ Informe de problema: describe una dificultad en la utilización del producto que

requiere alguna modificación para subsanarla.

■ Informe de cambio: describe la solución dada a un problema y el cambio reali-

zado en el producto software.

El informe de problema puede ser originado por los usuarios. Este informe se
,a a un grupo de ingeniería para la comprobación y caracterización del problema,
luego a un grupo de gestión para decidir la solución a adoptar. Este grupo de
tión inicia el informe de cambio, que se pasa de nuevo al grupo de ingeniería para
- desarrollo y ejecución.

'2.11.3. Reingeniería
Con mucha frecuencia, por desgracia, es necesario mantener productos software
que no fueron desarrollados siguiendo las técnicas de ingeniería de software, sino de
 48 CICLO DE VIDA

forma artesanal. En estos casos el desarrollo no suele estar documentado , y se dis-

pone solamente del código fuente, quizá comentado.

Para ayudar al mantenimiento de este tipo de aplicaciones se han desarrollado

algunas técnicas particulares que t ratan de subsanar estas deficiencias de documen-
tación. Estas técnicas se han denominado inicialmente ingeniería inversa, y más mo-
dernamente reingeniería.

La ingeniería inversa consiste en tomar el código fuente y a partir de él tratar de

con struir, si es posible de manera automática, alguna documentación, en particular
documentación de diseño) con la estructura modular de la aplicación y las depen-
dencias ~ntre módulos y funciones. Esto facilita la caracterización del ámbito de un
posible cambio, es decir, determinar qué módulos y funciones habría que 1nodificar.

Una documentación mecánica de la estructura del sistema software es insuficiente

para mantener aplicaciones complejas. La actividad de reingeniería se plantea como
algo más general, que trata de generar un sistema bien organizado y documentado a
partir del sistema inicial deficiente. Este trabajo puede incluir el reconstruir manual-
mente la documentación inexistente, y modificar el código fuente para reestructurarlo
de manera más apropiada.

2.12. Garantía de calidad de software

La calidad de un producto software, como cualquier otro producto de ingeniería,
úene determinada fundamentalmente por el proceso seguido en su desarrollo. En el
modelo de ciclo de vida encontrainos actividades típicamente productivas, tales como
las de análisis, diseño y codificación, y otras cuyo objetivo es controlar la calidad del
producto. tales como las revisiones y pruebas.

En el capítulo 1 ya se revisaron los factores de calidad con los que se valora el

producto. A continuación se analiza cómo debe organizarse el proceso de desarrollo
para garantizar un nivel de calidad adecuado.

2.12.1. Plan de garantía de calidad

Una adecuada calidad del producto es inalcanzable sin una buena organización
del desarrollo. Las técnicas de ingeniería de software tratan de formalizar el proceso
de desarrollo evitando los inconvenientes de una producción artesanal.

Esta organización del proceso de desarrollo de software debe materializarse en un

doGumento formal, denominado Plan de Garantía de Calidad de Software (en inglés
 ,'TÍA. DE CALIDAD DE SOFT\V.4.RE 49

. Software Quality Assurance Plan). El plan debe contemplar aspectos tales

• Organización de los equipos de p<>rsonas y la dirección y seguimiento del desa-

rrollo.
• ~lodelo de ciclo de vida a seguir, con detalle de sus fases y actividades.
• Documentación requerida. especificando el contenido de cada documento y un
guión del mismo.
• ReYisiones y auditorías que se llevarán a cabo durante el desarrollo, para ga-
rantizar que las actiYidades y documentos son correctos y aceptables.
• Organización de las pruebas que se realizarán sobre el producto soft"vare a
distintos niveles. A veces esta parte se redacta como un plan separado.
• Organización de la etapa de mantenimiento, especificando cómo ha de gestio-
narse la realización de cambios sobre el producto ya en explotación.

_ 12.2. Revisiones
·na revisión consiste en inspeccionar el resultado de una actividad para determi-
5.i es aceptable o, por el contrario. contiene defectos que han de ser subsanados.
- re,-isiones se aplican, fundamentalmente, a la documentación generada en cada
apa o fase del desanollo.

De acuerdo con el espíritu de las reglas de ingeniería de software. las revisiones

n ser formalizadas. E sto quiere decir que deben estar contempladas en el modelo
ciclo de vida y que debe existir una normat iva para su realización.

Parece interesante enunciar algunas recomendaciones concretas sobre cómo for-

izar las revisiones. entre ellas las siguientes:

• Las re,·isiones deben ser realizadas por un grupo de personas. y no por un solo
individuo. E sto facilita descubrir posibles fallos, al existir diversos puntos de
vista.
• El grupo que realiza la revisión debe ser reducido, para evitar excesivas discu-
siones y facilitar la comunicación entre sus miembros. Se recomienda de tres a
cinco personas.

• La revisión no debe ser realizada por los autores del producto, sino por otras
personas diferentes para garantizar la imparcialidad <le <-riterio.
50 CICLO DE VIDA

• Se debe revisar el producto, pero no el productor ni el proceso de producción.

El producto permanece. mientras que el cómo se obtuvo influye poco en el uso
futuro de ese producto.
■ Si la revisión ha de decidir la aceptación o no de un producto, se debe establecer
de antemano una lista formal de comprobaciones a realizar, y atenerse a ella.
■ Debe levantarse acta de la reunión de revisión, conteniendo los puntos importan-
tes de discusión y 4l.s decisiones ton1adas. Este documento puede considerarse
como el producto de la revisión.

2.12.3. Pruebas
Las pruebas o ensayos consisten en hacer funcionar un producto software o una
parte de él en condiciones determinadas, y comprobar si los resultados son los correc-
tos. El objetivo de las pruebas es descubrir los errores que pueda contener el software
ensayado.

Las pruebas no permiten garantizar la calidad de un producto. Puede decirse que

una prueba tiene éxito si se descubre algún error . con lo que se sabe que el producto
no cumple con algún criterio de calidad; por el contrario, si la prueba no descubre
ningún error, no se garantiza con ello la calidad del producto. ya que pueden existir
otros errores que habrían de descubrirse mediante pruebas diferentes. Esto es así
porque nunca puede ensayarse un producto en forma exhaustiva, sino que las prue-
bas sólo hacen que el producto realice una parte ínfima de la enorme variedad de
operaciones concretas que podría realizar.

A pesar de esta limitación, las pruebas son una técnica fundamental de garantía
de calidad. En el capítulo 8 se describen técnicas concretas para organizar y realizar
pruebas de software.

2.12.4. Gestión de configuración

Para precisar el concepto de configuración se consultará, como otras veces, E>l
diccionario: Configuración. (Del latín configuratio) Disposición de las partes quf
componen una cosa y le dan su peculiar figura.

La configuración de software hace referencia a la manera en que diversos elemen-

tos se combinan para coru;tituir un producto software bien organizado, tanto desd(
el punto de Yista de su explotación por el usuario como de su desarrollo o ma.ntcni-
rniento.
 51

describe aquí brevemente los elementos básicos de la gestión de configuración.

- ideas se encuentran más desarrolladas en otros textos generales de ingeniería

ra cubrir la doble visión del software, desde el punto de vista del usuario y del
-=_.......llador, habremos de considerar como elementos componentes de la configu-
--.. . ,J_ ~odos los que intervienen en el desarrollo, y no sólo los que forman parte del
___,..___,-ro entregado al cliente. Estos elementos serán, por ejemplo:
• Dvcumentos del desarrollo: Especificaciones, diseño, etc.
• Código fuente de los módulos
• Programas, datos y resultados de las pruebas
• ~fanuales de usuario
• Documentos de mantenimiento: informes de problemas y cambios
■ Prototipos intermedios
■ ~ armas particulares del proyecto
■ •.. etc ....
El problema de la gestión de configuración es que estos elen1entos evolucionan a
.:;argo del desarrollo y la explotación del producto software, dando lugar a diferen-
o· nfiguraciones particulares, compuestas de diferentes elementos. Los elementos
;iduales evolucionan a base de construir sucesivas versiones de los mismos.

Para mantener bajo control la configuración o configuraciones de software hay

apoyarse en técnicas particulares de:
■ Control de versiones
• Control de cambios
El control de versiones consiste en almacenar de forma organizada las sucesi-
- \·ersiones de cada elemento de la configuración, de manera que al trabajar sobre
configuración concreta del producto softw~re se pueda acceder cómodamente a
- ··ersiones apropiadas de sus elementos. El control de cambios consiste en ga-
~ a r que las diferentes configuraciones del software se componen de elementos (y
~iones de estos elementos) compatibles entre sí, y que constituyen un conjunto
_erente.

El control de cambios se realiza normalmente usando el concepto de línea base.

-na línea base es una configuración particular del sif:tPma. Cada línea base se cons-
:znye a partir de otra mediante la inclusión de ciertos cambios, que pueden ser la
52 CICLO DE VIDA.

adición o supresión de elementos. o la sustitución de algunos por versiones nuevas de

los mismos. La aceptación de los carnbios y la consiguiente creación de la nueva línea
base ha de controlarse mediante pruebas o revisiones apropiadas, para garantizar la
corr ección de la nueva configuración.

Las líneas base constituyen configuraciones es.tables: que no pueden ser modifica-
das (se dice que están '·congeladas"). La forma de modificar una línea base es crear
otra nueva introduciendo los cambios apropiados. La antigua línea base seguirá exis-
t iend o, aunque en algún momento se podrá hacer desaparecer si se está seguro de no
necesitarla más.

2.12.5. Normas y estándares

_ Las recomendaciones de la ingeniería de software se han t raducido en ocasiones
en normas precisas sobre determinados aspectos del desarrollo de software, desde
el enfoque global del proceso de desarrollo hasta normas detalladas de codificación.
procedimientos concretos para la realización de ensayos o modelos más o menos pre-
cisos de la documentación a redactar.

Algunas de estas normas han sido recogidas por organizaciones internacionales y

establecidas como estándares a seguir en el desarrollo de determinadas aplkaciones.
Entre estas normativas encontramos las siguientes:
IEEE: es la asociación p rofesional Institute of Elcctrical and Electronics Engi-
neer establecida en USA. Ha establecido una colección de normas , muchas de ellas
admitidas también corno normas AKSI (American National Standards Institute) y
recogidas globalmente en [IEEE93j.

DoD: son las siglas del Departamento de Defensa (Departm ent of Defense) nor-
teamericano. La norma fundamental es la DoD-STD-2167A lDoD88], que se com-
plementa con otras normas adicionales conteniendo, por ejemplo, modelos de lo::-
docurnentos a redactar. En la actualidad está en revisión y será sustituida por la
:\1IL-STD-SDD , que engloba en una sola tanto la norma principal como las comple-
mentarias de documentación.

ESA: es la Agencia Europea del Espacio (European Space Agency) . Posee una
norma general para. el d esarrollo de software [ESA91]. Esta norma se apoya en algu-
nos aspectos en las normas del IEEE citadas anteriormente.

ISO: son las siglas del organismo internacional de normalización (Internationa

Standards Organization). Está integrado por los organismos nacionales de nonnali-
zación de un gran número de países (el de España es AEKOR). Publica un sinfí:::
de normas para toda la actividad t écnico-industrial. Ent re sus normas de Ingeniería
 ,TL!. DE CALIDAD DE SOFTvVARE 53

de mayor nivel se encuentran la IS0-9001. que establece los criterios que

~"=-!:1,-r,, ,
cumplir las empresas que desarrollen software para obtener certificaciones de
c:miactos niveles de garantía de calidad de su producción.

~ll: son las siglas de Integración de ~'Iodelos de l\'Iadurez de Capacidades

1"ty Maturity Model Integration). Es un modelo desarrollado por el Instituto
Ereniería df'l Software Software Engineering Jnstitute de EEl,lf para la n1ejora
procesos de las empresas de software que califica las compañías según su nivel
urez. Por proceso se entiende un conjunto de fases sucesivas que llevan a. la
ón de un resultado, y por nivel de madurez, el grado de calidad que alcanzan
,__.....,...=-os. La versión actual es la 1.3.

~U establece una serie de buenas prácticas que las empresas deben cumplir
consideradas de un grado de madurez determinado a la hora de gE>nerar
SB"

--.&os. C~L\iII no establece como llevar a cabo estas prácticas, sirnplen1ente te

qué se compromisos se deben cumplir.

- niveles de madurez son 5:

• Xh·el O: Inexistente

• _-¡ye} 1: Inicial

• ~i\·el 2: Repetible

• ~ivf'l 3: Definido

• ~ivel 4: Gestionado

• ~i\·el 5: Optimizado

E:- muchos países SE' han desarrollado también normas oficiales similares a éstas,
- •J!-o interno. Entre las normas españolas encontra1nos:

~IBTRICA-2: Desarrolla.da por el Consejo Superior de Informática del Nliniste-

para las Administraciones Públicas (~1AP). Es una norma para el de,Sarrollo de
-""'anas de ínforrnación de las administraciones públicas, basada en la metodología
análisis y diseño estructurado de Yourdon/De:VIa.rco.

I\IETRICA-3: La evolución natural del estandard anterior. En esta versión se

:31;c,n en cuenta la división en procesos. Descripción de las tareas de manera siste-
.ca. Incorporación de nuevos estándares (corno UI\11). Soporte para desarrollos
entados a objetos. Interfaces (tareas comunes a todos los procesos). Consideración
mantenimiento dentro de la norma.
54 CICLO DE VIDA

2.13. C onc lusiones

En este capítulo se ha presentado co1no se organiza por fases el desarrollo de un
sistema software. El conjunto de estas fases se llama ciclo de vida. Esto no es algo
particular del software sino que es habitual en cualquier proceso productivo y comer-
cial. En el caso de la producción del software t iene sus particularidades. Se presentan
diferentes alternativas de organización del ciclo de vida del software, incluso meto-
dologías "extremas". Para concluir el capítulo se aborda la fase de mantenimiento y
una breve presentación de la medida de la calidad del software.

2. 14 . Ejercicios propuest os
l. Plantéese el ciclo de vida de un nuevo producto) como una bebida, desde la
óptica de su diseño, su fabricación y su comercialización.
2. Preguntado un alumno de primer curso de informática por lo primero que ten-
dría que hacerse para construir una casa, respondió: "hacer un agujero)). Despué5
de leer este capítulo demuéstrese que eso no es lo más adecuado. ivlárquese las
fases que seguiría.
3. Póngase un ejemplo de proyecto para cada uno de los tipos de ciclo de vida.
4. Búsquese un ejemplo de prototipo de usar y tirar y de prototipo reutilizable en
la industria, en la construcción y en la producción de software.
5. Elabórese una lista con 5 posibles riesgos a valorar en un proyecto software.
6. P lantéese unas pautas que seguiría una empresa para ofertar el mantenimient ...
de una aplicación software que va a producir, pero que también quiere mantener
7. Búsquese información sobre los niveles de madurez del modelo CMMI.
8. lndáguese sobre la norma Nlétrica 3.
 pecificación de Requisitos

Introducción
..--~te capítulo está dedicado a describir la labor de análisis y definición de los
·sitos que ha de cumplir un proyecto de software. Esta labor debe dar lugar a
,i::::,pecificación de software) en la que se concretan las necesidades que se desean
· y se fij an las restricciones con las que debe trabajar el software a desarrollar.
&)-,álisis se realiza dentro de la primera fase (fase de definición) del ciclo de vida y
una importancia decisiva para conseguir que el sistema que se construya final-
re sea realmente el que se deseaba.

Primeramente) en este capítulo) se hace un breve repaso al modelado de siste-

~ centrado específicamente en los sistemas desarrollados mediante software. A
-inuación, se estudia de manera detallada el proceso de análisis de requisitos,
zbleciendo los objetivos y las tareas de dicho análisis. Seguidamente se describen
intas notaciones que habitualmente se emplean para elaborar la especificación de
e «are. Finalmente, se sugiere un posible formato para el documento que recoge la

~cación y que constituye el resultado fundamental del análisis .

. 2. Objetivos
El alumno después de leer este capítulo debe conocer el concepto de especificación
·m sistema software, obtención, análisis y validación de los requisitos. Concreta-
_ ente el lector deberá:
■ Comprender la relevancia que para la realización de un sistema software tiene
la obtención de los requisitos que tiene que cumplir para satisfacer su funcio-
namiento de manera correcta y las expectativas del cliente que lo encarga.

55
56 ESPECIFICACIÓN DE REQL7SITOS

• Conocer :,· distinguir los diferentrs tipos de requisitos que se presentan en la

elaboración de un sistema software.

• Conocer las técnicas más relc,·antes para la captura de los requisitos de un

sistrma y ser capaz de elaborar un documento de especificación de requisitos.
SRD.

• Reconocer diferentes notaciones para elaborar los diagramas que se emplean e1

la elaboración del SRD.

3.3. Modelado de sistemas

Para la 1nayoría de los trabajos de ingeniería es ba.<:>tante habitual utilizar proto-
tipos o maquetas. Por ejemplo en arquitectura es muy común realizar un modelo 1
maqueta a escala del nuevo edificio. Esto mismo sucede cuando se trata de analizar el
comportamiento de un nuevo dispositivo mecánico, eléctrico, hidráulico, etc. Todo~
estos modelos facilitan al ingeniero la labor de comprensión de los problemas que se
plantean en el nuevo sistema a desarrollar.

El modelado de los sistemas realizados mediante software también Uene come,

objetivo entender mejor el funcionamiento requerido y facilitar la comprensión d
los problemas planteados. Sin embargo, para este tipo de sistemas no se busca, en
principio, un modelo físico de su comportamiento. En este caso, el sistema softwan
deberá efectuar de una forma más o menos compleja un determinado tratamient
de la información. Se trata de establecer modelos conceptuales que reflejen, por u1.
lado, la organización de la información y, por otro. las diversas transformaciones qu
-.e dchen lleYar a caho con dicha información.

Hay que tener presente que cuando hablamos de modelo, en este capítulo, no,
e::;tamos rf'firiendo a. un modelo completo y preciso del comportamiento u organiza-
ción del ::;i::;tema software. No hay que confundir este modelo con el correspondient
a una maqueta o prototipo parcial empleado como ayuda para realizar la activida.
<le análisu;. tal como se indicaba en el capítulo anterior.

Existen diversas metodologías para realizar el análisis de los requisitos que del
cumplir un proyecto soft-\.vare. Un aspecto común a todas ellas es que tratan dl
facilitar la obtención de uno o varios modelos que detallen el comportamiento desead
del sistema. El empleo de una u otra metodología dependerá del tipo de aplicació1
(gestión, control. cálculo, etc.) y de las preferencias del analista que elabore el model.
El estudio de metodologías concretas queda fuera del alcance de este libro y seráu
objeto de estudio eu cur::;os posteriores.
 57

Concepto de modelo
carácter gen eral. un modelo conceptual es rodo aquello que nos permite
-.-:-r-re? nna abstracción lógico-matemática del mundo real y que facilita la com-

~ c...,.....u del problema a resolver.

manera específica, el modelo de un sistema software debe establecer las pro-

., _____....: · restricciones del sistema. Con el modelo, siempre se tratará de ofrecer
6n de alto nivel, sin descender a explicar detalles concretos del mismo. Por
o. el modelo debe explicar QUÉ debe hacer el sistema y no CÓl\IO lo debe
Después en la etapa de diseño posterior es cuando se debe concretar cómo se
hacer las cosas.

- • lo::- objetivos que se deben cubrir con los modelos he pueden concretar en los

Facilitar la comprensión del problema a resolver .

.Establecer un marco para la discusión. que simplifique y ::-istematice la labor.

tanto de análisis inicial, como de las futuras revisiones del uiisrno.

Fijar las bases para realizar el diseño.

Facilitar la verificación del cumplimiento de los objetivos dPl sistema.

Técnicas de modelado
La obtención de un modelo que cubra todos los objetivos anteriores no PS una
fácil. Las dificultades son de todo tipo. En primer Jugar, los sistemas a mo-
pu('(fen ser mu~ complejos. Por otro lado. es relativamentE' normal que no se
nga de ninguna referencia o experiencia anterior, dado que el sistema que SE>
a de modelar e implementar no ha sido planteado anteriormente. A continuación
mdic-an algunas técnicas que pueden re~ultar útiles para realizar el ruodelado de
,istema software.

>e -;con1posición. Modelo jerarquizado

e Cuando un problema es complejo, la primera t<"<'nica que se debe emplear es des-
o .poner lo en otros más sencillos de acuerdo con el viejo axioma ·'divide y Yenccrás''.
n •sta mancra1 se establece un modelo jerarquizado en el que el problema global
.
-<la subdividido en un cierto núrnero de subproblemas Por ejemplo, si se trata de
n modelar un sist<>ma para la gestión integral de una cmpn•sa, este sistema se puede
de~cornponer en los subsistemas siguientes:
 ESPECIFICACIÓN DE REQUISITOS

• nómin;¡s

• :::;,¡:;.,~E:ma de facturación

•
E:::,.:e tipo de dc:-;composición se denomina horizontal y trata de descomponer fun-
cicualn::."'nte el problema. A continuación, en el análisis de cada uno de estos subsis-
tema.::, :':e pueden emplear las mismas técnicas que con el sistema global. Por tanto
e:, µasible voh·er a descomponer cada uno de estos subsistemas a su vez en otros más
simples. P or ejemplo. el sistema de nóminas se puede dividir en los siguientes:
■ Realización de nóminas
■ Pagos a la Seguridad Social
• Pagos del IRPF

•
Evidentemente, para completar el modelo se tendrán que establecer las interfases en-
tre las partes o subsistemas en que queda dividido, posibilitando el funcionamientc.
del sistema global.

Cuando se descompone un modelo: tratando de detallar su estructura, este tipo

de descomposición se d enomina vertical. Por ejemplo: la realización de nóminas se
descompone según la secuencia:
■ Entrada de datos del trabajador
■ Cálculo de los ingresos brutos
• Cálculo de las retenciones
• Cálculo del pago a la Seguridad Social
• Impresión de la nómina
Esta técnica supone aplicar el método de refinamientos sucesivos al modelado del
sistema.

Aproximaciones sucesivas

A pesar de que el sistema a desarrollar nunca será igual a alguno ya en funciona-

miento, siempre se podrá tomar como modelo de partida el modelo de otro sisten.
similar. Por ejemplo. es corriente que el sisterna software que se quiere modcl~
sustituya a un proceso de t rabajo ya existente, que se realiza de forma totalmente
 59

-==:::al o con
un grado de automatización menor del que se pretende lograr con el
5istcma. En este caso, se puede crear un rnodclo df' partida basado en la forma
ajo anterior. Sin embargo, este modelo sólo será preliminar y tendrá que ser
----rlo mediante aproximaciones sucesivas hasta alcanzar un modelo final.

o es fácil suponer, la depuración es una labor ardua y difícil que requiere una
experiencia del analista y en cualquier caso un estudio exhaustivo del problema
trata de resolver con el sistema software. Para lograr un buen resultado me-
e aproximaciones sucesivas, además del analista, es fundamental contar con la
ración de alguien que conozca muy bien el sistema anterior y que sea capaz de
___.,,_.,.,..,.rar mejoras dentro del nuevo sistema y discutir las ventajas e inconvenientes
a uno de los modelos intermedios elaborados.

_.\ reces puede suceder que el modelo resulte muy complejo o incluso imposible de
-...Leu. utilizando una única notación para su elaboración. En un apartado posterior

:l'eSCriben distintas notaciones utilizadas habitualmente. En estos casos es impor-

cratar de utilizar notaciones alternativas o complementarias que simplifiquen
,-a .delo.

-na posible notación para describir el modelo de un sisterna es mediante el len-

je natural. Evidentemente, todo se puede describir mediante una explicación más
os prolija empleando el lenguaje natural. Sin embargo, este método puede dar
......,.""",.. a un modelo difícil de apreciar en su conjunto por lo farragoso de las expli-
b:i·~nes. Además es normal que se produzcan imprecisiones, repeticiones e incluso
ic::r:m:T,e cciones en el modelo así realizado. Como suele ser habitual, un esquema, una
:iz:!ra. o cualquier método gráfico suele ser más fácil de entender. Hay que recordar
una imagen puede valer más que 1nil palabras.

Teniendo en cuenta los objetivos, ya citados anteriormente, que debe cubrir un

..:-<>Jo. lo ideal es emplear para su elaboración la notación con la que mejor se cubran
_os objetivos. Incluso es aconsejable emplear varias notaciones juntas cuando sea
esario. Así, existen diversas herramientas de modelado para la ayuda al análisis
diseño de los sistemas, también llamadas herramientas CASE (Computer Aided
~·are Engineering), que combinan texto. tablas, diagramas, gráficos, etc. Estas
::;,rramientas están disponibles en el mercado y están basadas en distintas metodo-
.....a.s de análisis y diseño de sistemas software. DepE>ndiendo del aspecto concreto
sistema que se quiere modelar es más adecuado ernplcar una. u otra notación.
60 ESPECIFICACIÓ1V DE REQUISITOS

Considerar distintos puntos de vista

Para poder concretar la creación de un modelo es necesario adoptar un determi-

nado punto de vista. Después, el n1odelo que resulte estará necesariamente influido
por el punto de vista adoptado. Por ejemplo, cu ando un pintor realiza un paisaje.
elige el punto de vista q ue refleje de forn1a más exacta lo que quiere transmitir con el
cuadro: calma, soledad, tristeza, alegría, sosiego, etc. El pintor , con el punto de vista
elegido, trata de destacar los r asgos del mundo real que coinciden con el objetivo que
se plantea en el cuadro y, a la vez, t rata de ocultar aquellos detalles que no ayudan
a perfilar el modelo del mundo real que desea obtener en el cuadro .

EYi<lentemente. no se pued e comparar la labor de un pintor con la de un ingenie-

ro que trata de obtener el modelo software de una futura aplicación. Sin embargo.
t.ambién f'Sle último df'be elegir el punto de vista que permita obtener el n1odclc
111ás adecuado para representar el con1portamiento deseado del sisterna. Con eRte
fin, en ocasiones será más adecuado adoptar el punto de vista del futuro usuario dé
sistema, en otras será más importante considerar el punto de vista del mantenedor
del sistema, en algunos modelos será suficiente con perfilarlo desde el punto de vi::,t&
funcional) etc. Por tanto, en el desarrollo de un modelo se debe elegir conveniente-
1nente el punto d e vista más adecuado. P ara esta elección será convenien te esboza:
distintas alternativas y elegir aquella q ue resulte la más idónea.

En ocasiones el modelo no quedará completan1ente definido con un solo punto <lt:

vista. En este caso lo adecuado sería realizar el n1odelo desde distintos puntos <l
vista, que 1nuestren todos los aspectos que se quieren destacar del sistema.

R ealizar un anális is d el donünio

Por dominio entenderen10s el campo de aplicación en el que se encuadra el sistem

a de5arrollar. Por ejemplo, supongamos que se trata de desarrollar un sistem a par
el .;:egnimienro <lf' la f'volución de los pacientes de un hospital. Este sistema qued~
encuadrado dentro de las aplicaciones para la gestión de hospitales. En este carnpc
como en cualquif'r or,ro, existe desde siempre una cierta rnanera de realizar las cosa.
y una terminología _va acuñada que debe ser respetada y tenida en cuenta. Esto e
lo que dcnonunarc1nos realizar un análisis del dominio de la aplicación.

Si bien las peculiaridades de cada aplicación hacen que necesariamente deba. :,:e.
estudiada como un caso único , es irnportante analizar el dominio de la aplicacit.
para situarla dentro de un entorno mucho más global. Para realizar este análisis ,___
aconsejable estudiar los siguientes aspectos:
■ Normativa que afecte al sisterna
■ Otros sistemas sen1ejantes
 lDO DE SISTEMAS 61

L-rudios recientes en el campo de la aplicación

• Bibliografía clásica y actualizada: libros y artículos sobre el tema

e estudio facilitará la creación de un modelo más universal. Como ventajas de

:-oque se puede citar las siguientes:

Facilitar la cornunicación entre analista y usuario del sistema.

La creación de un nuevo modelo requiere una colaboración muy estrecha en-
re el experto que conoce los detalles de la aplicación que se está creando, que
denominaremos usuario, y el ingeniero de software que realiza el análisis, que
denominaren1os analista. Esta colaboración sólo es posible si la. comunicación
entre ellos resulta fluida y emplean el mismo lenguaje. Por ejemplo. en el siste-
ma de seguimiento de la evolución de los pacientes, para guardar la información
dt? cada paciente desde siempre se emplea el término de "historia clínica.. y re-
- tltaría confuso cambiar esta denominación por la de "ficha del paciente"' que
podría sugerir el analista.

_ Creación de elementos reahnente significativos del sistema.

Cuando se ignora el dominio de una aplicación, la solución que se adopta
r_ueda particularizada en exceso. Por ejemplo, si se trata de realizar una aplica-
~ión de contabilidad para una empresa determinada, es bastante normal que se
adapte fielmente a las exigencias del contable de dicha empresa, lo que puede
dar lugar a soluciones no válidas para otras empresas. Sin embargo, si se tie-
ne en cuenta el Plan Contable Nacional, la aplicación será válida en cualquier
empresa. En este sentido se adoptarán los términos normalizados de balance,
cuenta, apunte, transferencia, etc. según un criterio único y universal.

3. Reutilización posterior del software desarrollado.

Olro de los beneficios importantes del análisis del dominio es la posible re-
utilización posterior de aquellos elen1entos que han s ido creados dentro de un
contexto más globalizado. Este criterio es el que ha sido utilizado desde siempre
para dotar a todos los cornputadores de un paquete de subrutinas matemáticas.
Dentro de un dominio de cálculo 1natemático, sicn1prc es necesario disponer de
operaciones trigonornétricas, logaritmos. matrices, er.c. con distintas precisiones
y, tanto en coma fija, como en coma flotante.

Otro ejemplo en este sentido sería el siguiente. Supongarnos que se trata

de realizar un sistema para la gestión de una base de datos en tiempo real,
62 ESPECIFICACIÓN DE REQUISITOS

la cual necesita un tiempo de acceso que no se puede lograr con ninguna d e

las disponibles en el n1crcado. Para que el esfuerzo que hay que realizar no
sirva sólo para la aplicación concreta , lo que se debe hacer es especificar un
conjunto de subrutinas de consulta y modificación que se adapten al estándar
SQL (Standard Query Language). Con estas subrutinas cualquier programa que
utilice una base de datos mediante SQL podrá utilizar nuestra base de datos
con un mejor tiempo de respuesta.

3.4. Análisis de requisitos de software

Como ya se ha comentado anteriormente, la etapa de análisis se encuadra dentro
de la primera fase (fase de definición) del ciclo de vida y tiene una importancia de-
cisiva en el desarrollo de todas las etapas posteriores (diseño, codificación, pruebas
y mantenimiento). Como también ha sido apuntado en el apartado anterior, el inge-
niero de software encargado de esta labor lo llamaremos analista.

Con el análisis de requisitos se trata de caracterizar el problema a resolver. Este

se puede concretar en la obtención del modelo global que define por completo el
comportamiento requerido del sistema. Esta tarea es bastante compleja. El primer
problema que se le presenta al analista es conseguir un interlocutor válido para po-
derla llevar a cabo. Este interlocutor, que denominaremos de forma genérica cliente
puede estar constituido por una o varias personas expertas, en todo o sólo en una par-
te del trabajo que se pretende automatizar con el sistema a especificar. Por ejemple
cuando se desea de automatizar la gestión de una empresa y existe un responsablt'
de la contabilidad. pedidos, facturación, etc. y otro del pago de las nóminas, será ne-
cesaria la colaboración de ambos. En otros casos, no existirá nadie capaz de asumi:
el papel de cliente, bien debido a que nadie conoce exactamente lo que se requier
del sistema, o bien sirnplemente por lo novedoso de la aplicación. En estos casos
el analista debe buscar su cliente mediante una documentación exhaustiva sobre e
tema.

Como ya se ha podido deducir fácilmente, a lo largo de este capítulo no se asociar

al cliente con la persona o entidad que financia el proyecto. Aquí, el cliente será
encargado de elaborar, junto con el analista, las especificaciones del proyecto de sor
ware. Posteriormente se encargarán de verificar el cumplimiento de las mismas con:
si de un contrato se tratara. Por tanto, en algunas ocasiones el cliente será el usuar.
final de la aplicación, en otras coincidirá con el cliente que propiamente financia
proyecto e incluso, en otras puede ser simplemente parte de una especificación
otro proyecto de mayor envergadura en el que está encuadrado el nuestro.
 -..'JS DE REQUISITOS DE SOFTvV.4.RE 63

Objetivos del análisis

o jetivo global del análisis es obtener las especificaciones que debe cumplir el
~ =:a a desarrollar. El medio que se emplea para lograr dicho objetivo es obtener
elo válido, necesario y suficiente para recoger todas las necesidades y exigen-
e el cliente precisa del sistema y, además, también todas aquellas restricciones
analista considere debe verificar el sistema. Las especificaciones se obtendrán
_,.....,.ose en el modelo obtenido.

ridentemente, en el proceso de análisis quedarán descartadas aquellas exigencias

ente que resulten imposibles de lograr o que, simplemente, resulten inalcanza-
con los recursos puestos a disposición del proyecto.

1gual manera, como resultado del diálogo entre el analista y el cliente, queda-
n~·enientemente matizadas cada una de las exigencias y necesidades d el sistema
~aptarlas a los medios disponibles para el proyecto. Para lograr una esp eci-
s:::;:1·tón correcta, el modelo global del sistema deberá tener las siguientes propiedades:

Completo y sin omisiones:

Aunque pueda parecer simple , esta propiedad no es sencilla de cumplir dado
que a priori no es fácil conocer todos los detalles del sistema que se pretende es-
pecificar. Por otro lado, cualquier omisión puede tener una gran incidencia en el
diseño posterior e incluso desvirtuar el modelo del sistema. Por ejemplo, supon-
gamos que se omite, por considerarlo sobreentendido, los sistemas operativos
DOS y UNIX) o la configuración mínima que se precisará para la ejecución
d el sistema a desarrollar. Las consecuencias de esta omisión pueden dar lugar
a que se anule o reduzca la utilidad del sistema desarrollado finalmente.

Conciso y sin trivialidades:

En general, uno de los graves errores que se suelen cometer al elaborar una docu-
mentación es suponer que será más exhaustiva cuanto más voluminosa resulte.
Sin embargo, si el tamaño crece desmesuradamente suele ser una prueba inequí-
voca de que no está siendo revisada convenientemente y que muy probablemente
t iene trivialidades, repeticiones innecesarias o incluso alguna inexactitud. Por
ejemplo, esto puede ocurrir al elaborar un nuevo modelo partiendo de otro an-
terior semejante. En principio, se suele mantener todo aquello que no entra en
contradicción con el nuevo modelo. Esto da lugar a que se mantengan párrafos
del anterior que no aportan nada al nuevo modelo y que pueden dar lugar a
in exactitudes.
64 ESPECIFICACIÓN DE REQUISITOS

P or otro lado, cuando un modelo rei:mlta muy farragoso, es n1uy probable que no
se estudie en detalle y q ue r esulte difícil distinguir los asp ectos fundamen tales.

3. Si11 am bigüedades:
Exbte cierta tendencia a pensar que el anális is de requisitos es un mero trámite.
qu<' deh<' ~er pasado rápidamente para entrar de lleno en el diseño e implemen-
ración dt=>I siste1na.

Esta filosofía, que afortuuada1nente es cada día m enos habitual. da lugar a que
en < 1 análisis S<' dejf'n ciertos aspectos completamente ambiguos. Las consecuen-
cia~ d0 esta actitud son todai:; negativas:

• Difkultades en el diseño
• R etr asos y errores en la implementación
■ Imposibilidad de verificar si el siste1na cumple las especificaciones

Si se considera que el modelo resultado del análisis es un contrato con el clieu-

te, es eviden te que nada debe quedar ambiguo o de lo contrario se producirán
inevitablemente fricciones y probl('mas de consecuencias difícilt=>. s de prever.

-1 Sin detalles de diseño o implementación:

Como ya se ha indi<:ado anterionn eute. el objetivo del análisis es definir el Ql E
debe hacer el sistema y no el CÓl\10 lo debe de hacer. Por tanto, es claro q1.
no se dt•bc entrar en ningún detalle del diseño o implementación del s istc1.
en la etapa tle ai,alisü,. Ha;y que tener en cuent a que el analista puede te1
una formación previa TTUl)' próxirna al diseño y codificación. Esto hac<' qu<"
una ma11era in\·oluntana tenga cierta tentación a buscar la solución en lu~
<le Pxcl11sivament0 plantear el p roblema. Esta tentación debe ser superada si
quiere realizar un buen análisis.

5. Fácilment.e entendible por el cliente:

La única forrna de conocer si el clien te está de acu erdo con el modelo fru
del análisis es que lo entienda y sea capaz de discutir todos sus aspectos.
in1portante. por tanto, que el lenguaje que se utilice sea asequible y que facili
la colaboración entre analista v diente. En este sentido es muy interesanrP
enrpleo de notaciones gráfica!-- tales c01no las que se estudiarán en el próxi
apartado.
 DE REQlTISJTOS DE SOFTWARE 65

~ando requisitos funcionales y no funcionales:

_-05 requisitos funcionales son los destinados a establecer el modelo de fun-
namicnto del sistema y serán el fruto fundamental de las discusiones entre
analista y cliente. Las personas no muy expertas en sistemas software, tales
crJmo el usuario, tienen tendencia a creer que los requisitos funcionales son los
rmicos a tener en cuenta y que sólo en base a ellos se realizarán las pruebas
de verificación del sisterna después de su implementación. Sin embargo, exis-
en además las restricciones o requisitos no funcionales que están destinados a
encuadrar el sistema dentro de un entorno de trabajo y que delimitan:
■ Capacidad mínima y máxima
■ Interfases con otros sistemas
■ Recursos que se necesitan
■ Aspectos de seguridad
■ Aspectos de fiabilidad
■ Aspectos de mantenirniento
■ Aspectos de calidad
•
Estos requisitos no funcionales tienen un origen más técnico y no tienen tanto
..merés para el cliente como lo tienen los funcionales. Por tanto, parece evidente
que deban permanecer claramente separados en el modelo del sistema.

- Di.-idiendo y jerarquizando el modelo:

La forma más sencilla de simplificar un modelo necesariamente complejo del
::,istema es dividiéndolo y jerarquizándolo. Est a división dará lugar a otros sub-
modelos , como ya se indicó anteriormente. En la definición del modelo global
del sistema, se deberá ir de lo general a lo particular. Esto facilitará su com-
prensión y permitirá abordar el análisis de cada parte por separado de una
forma racional y sistemática. Ejemplos de este enfoque ya se han mostrado en
el apartado anterior de este mismo capítulo.

Fijando los criterios de validación del sistema:

Es muy importante que en el modelo del sistema queden expresamente indica-
dos cuáles serán los criterios de validación del sistema. No hay que olvidar el
aspecto contractual que debe tener el modelo aprobado en la especificación del
sistema. En este sentido un buen m étodo para fijar los criterios de validación
es realizar con carácter preliminar el :-.Ianual de l:suario del sfatema. Siempre
será un buen punto de partida.
66 ESPECIFICACIÓN DE REQUISITOS

3.4.2. Tareas del análisis

Para la realización correcta de un análisis de requisitos conYiene efectuar una
serie de pasos o ta.reas. Dependiendo de las características y complejidad del s istema
que se trata de analizar, alguna de las tareas puede resultar trivial o inexistente. Las
tareas a desarrollar son las siguientes:
• Estudio del sistema en su contexto
• Identificación de necesidades
• Análisis de las alternativas. Estudio de viabilidad
• Establecimiento del modelo del sistema
■ Elaboración del documento de especificación de requisitos. SRD
■ Revisión continuada del análisis
A continuación se detallan las tareas en el orden en que habitualmente serán desa-
rrolladas:

l. ESTUDIO DEL SISTEMA E~ SU CONTEXTO.

Los sistemas realizados mediante software o sistemas software normalmente son
subsistemas de otros sistemas más complejos en los que se agrupan subsistemaE
hardware, subsistemas mecánicos, subsistemas sensoriales, subsistemas organi-
zativos etc. Por tanto, la primera tarea del análisis del sistema software será
conocer el medio en el que se va a desenvolver.

Por ejemplo, en un sistema para la supervisión y control del nivel de gases con-
taminantes en un garaje, se dispondrán sensores de CO, CO2 y de otros gase:,
situados en diferentes puntos del garaje. Asimismo, para evacuar los gases ~
dispondrá de varios extractores situados normalmente próximos a alguno de lili
sensores. Por otro lado, el sistema debe disponer de una consola situada en 1
cabina de control en la que se muestra periódicamente la situación y en la qu
se indican mediante alarmas acústicas situaciones que requieran la intervencié-
del operador ( avería en un sensor, avería en un ventilador, nivel de contaminan-
tes alto e incontrolable, etc.). Si se quiere especificar un sistema que pueda s<r
utilizado en cualquier tipo de garaje y con cualquier tipo de sensor, es impor-
tante establecer un contexto global de funcionamiento del sistema. Aparece de:
inmediato la necesidad de especificar una función de configuración del sistcr.
para el garaje concreto en el que se instala. Esto es, indicar el número y tip
de sensores, su situación, condiciones de alarma, etc. Todos estos detalles so.
se pueden conocer si se analiza el sistema software en su contexto.
 - ~ DE REQUISITOS DE SOFTlVA.RE 67

ro aspecto muy importante en este sentido es el análisis del dominio de la

!icación. Este análisis, como ya se indicó en el apartado del modelado de
--emas, incide directamente no sólo en la terminología a emplear en la especi-
ión del sistema, sino también en la creación de sistemas con una visión más
_ :::malizadora y que facilita la reutilización posterior de alguna de sus partes.

IDE:\"TIFICACIÓN DE :'-JECESIDADES
b.lcialmcnte, la actitud del cliente es solicitar del sistema todas aquellas fun-
- nes de las que en algún momento sintió la necesidad, sin pararse a pensar el
~do de utilidad que tendrán en el futuro. La labor del analista es concretar
la,.. necesidades que se pueden cubrir con los medios dis_ponibles (potencia de
cálculo, capacidad de mernoria, capacidad de disco, etc.) y dentro del presu-
uesto y plazos de entrega asignados a la realización del sistema.

Para realizar esta tarea de análisis es fundamental que el analista mantenga un

diálogo constante y fluido con el cliente, esto es, con todos aquellos que puedan
aportar algo al sistema en cualquiera de sus facetas. De todos ellos. el analista
deberá recoger y estudiar sus sugerencias para elaborar una propuesta que satis-
faga a todos. Como resultado de esta labor deben quedar descartadas aquellas
funciones muy costosas de desarrollar y que no aportan gran cosa al sistema.
A.demás, para aquellas necesidades que tengan un cierto interés y que requieran
más recursos de los disponibles, el analista tendrá que aportar alguna solución
aunque sea incompleta, que encaje dentro de los presupuestos del sistema. Por
ejemplo, suele ser frecuente la necesidad de acotar la cantidad de información
que se necesita guardar para realizar posteriormente estadísticas. Una actitud
permisiva en este sentido puede dar lugar a megabytes de información que no
sirven para nada.

Desde luego , las necesidades que finalmente se identifiquen deberán estar con-
sensuadas por todos aquellos que, junto al analista, hayan participado en el
análisis. Es labor del analista convencer a todos de que la solución adoptada es
la mejor con los medios disponibles y nunca tratar de imponer su criterio.

~- ANA.LISIS DE ALTERNATIVAS. ESTUDIO DE VIABILIDAD

En esta tarea aparece de forma evidente el enfoque de ingeniero de software
del que debe estar impregnada la actividad del analista. En principio existen
infinitas soluciones a un mismo problema. La labor del analista se debe centrar
en buscar aquella alternativa que cubra las necesidades reales detectadas en la
tarea anterior y que tenga en cuenta su viabilidad tanto técnica como econó-
mica. Cuando no es posible con un enfoque determinado encontrar un modelo
68 ESPECIFICACIÓN DE REQUISITOS

que cubra todas las necesidad e!-> de una forrna satisfactoria. se deben buscar so-
luciones altcrnatiYas. Con cada una dt las alternatiYas planteadas es necesario
realizar su correspondiente c•studio de -viabilidad. Estos estudios <'Onstituirá.n
una base fundamental para la toma <le decisión sobre la alternativa final1nentc
elegida. La. realización de esta tarea no siempre resulta necesaria. Solamente
en aquellos sistemas cuya complf'jidad, alto presupuesto o dificultad intrínseca
así lo aconsejen, se deberá realizar un análisis co1npJeto de diversas alternativas.

4. ESTABLECir-.IIENTO DEL :\10DELO DEL SISTElv1A

Según se van obteniendo conclusiones <le las tareas anteriores. estas se d eben ir
plasmando en el modelo del sistema. Así, el modelo se irá perfilando a medida
que se avanza en el estudio de las necesidades y las soluciones adoptadas. Pro-
bablemcnt<>, el resultado final será un modelo del sistema global jerarquizado
en el que aparecerán subsistemas que a su vez tendrán que ser desarrollado::-
hasta concretar suficientemente todos los detalles d el sistema que se quierc11
especificar.

Para la elaboración del modelo se deberán utilizar todos los medios disponible:,;.
desde procesadores <le texto hasta las rnás sofisticadas herramientas CASE, pa-
sando por las más diversas herra1nientas gráficas. Todo ello debe cont.ribuir a.
simplificar la elaboración del modelo y a facilitar la comunicación entre anali::,-
ta, cliente y diseñador. E n el próximo apartado se detallan la mayoría d e la,
notaciones que se utilizan habitualmente para desarrollar el modelo del sistema

5. EL DOCCl\lE~TO DE ESPECIFICACIÓ~ DE REQCISITOS

El resultado final del análisis será el documenlo de especificación de requisito::-.
Este docun1cnto debe recoger absolutamente todas las conclusiones del análi-
sis. EYidcntementc, una parte fundan1ental de este d ocumento será el modelo
del sisten1a -:,.· prf'cisan1ente es en este documento donde se debe ir p erfiland
su elaboración a lo largo de lodo el análisis. Existen distintas propuestas el
organizaciém de este documento que serán estudiadas en un próxirno apartad
de- este ntismo capítulo.

Es rnuy in1portante tener en cuenta que este documento será el que utilizar
el diseñador como punto de partida de su trabajo. Asimismo, este d ocumer
también es el encargado de fijar las condiciones de validación del sistema 1u.a
vez concluido su desarrollo e implen1cntación. Todo ello indica la transcendc, -
cía que tiene su elaboración y el cuidado que se debe poner para que sea ú · ·
tanto al cliente con10 al diseñador.
 lCIOSES PARA LA ESPECIFICACIÓN 69

REYISIÓ~ CO~TINUADA DEL ANALISIS

.-:,graciada1nente la labor de análisis no acaba al dar por finalizada la redac-
:..n del documento de especificación de requisitos. A lo largo del desarrollo del
-· -rema y según aparecen problemas en las etapas de diseño e implementación
tendrán que modificar alguno de los requisitos del sistema. Tampoco resulta
muy raro que se modifiquen los requisitos debido a cambios de criterio del clien-
e debidos a los más diversos motivos. Todo ello implica que se debe proceder
una revisión continuada del análisis y de su documento de especificación de
~uisitos según se producen los cambios.

S. se prescinde de esta última tarea, cosa desgraciadamente bastante habitual, se

rre el peligro de realizar un sistema del que no se tenga ninguna especificación
concreta y en consecuencia tampoco ningún medio de validar si es o no correcto
eL sistema finalmente desarrollado.

Notaciones para la especificación

I.a especificación será fundamentalmente una descripción del modelo del siste-
qLe se pretende desarrollar. P ara un misn10 modelo conceptual. dependiendo de
ración o notaciones (texto, gráficos, tablas, etc.) que se empleen para su des-
_ ,___ ón, se obtendrán distintas especificaciones. A priori, todas las especificaciones
~an ser equivalentes independientemente de la notación empleada. Sin embar-
el empleo de la notación más adecuada en cada caso redundará en una mejor
_,,..._.ificación del sistema. En general, siernpre será preferible utilizar una tabla o
notación gráfica que el texto que las pueda describir.

:_35 diversas n1etodologías de análisis, desarrolladas a lo largo de años, han ido es-
?ciendo distintas notaciones para describir el modelo global del sistema o ciertos
:j>eCtos del mismo. Debido al desarrollo paralelo de las distintas metodologías es fre-
te que una misma notación tenga significados distintos en cada metodología (por
plo: un círculo puede significar en unos casos una transformación de datos y en
~ representar un estado del sistema), o que para un mismo concepto se empleen
,::utas notaciones (por ejemplo, un estado del sistema puede indicarse mediante
círculo o mediante un rectángulo). Para evitar rnalas interpretaciones en la espe-
ación, es fundamental conocer el significado concreto de la notación que se utiliza.

En cualquier caso, la notación o notaciones ernpleadas deberán ser fáciles de enten-

por el cliente, el usuario , y en general por todos aquellos que puedan participar
el análisis y desarrollo del sistema. No obstante, el empleo de una notación u
ra dependerá de la complejidad y tipo de sistema a desarrollar (gestión, control,
romunicaciones, etc.), de la metodologia empleada. de las herra1nientas disponibles
70 ESPECIFICACIÓ1'V DE REQUISITOS

(procesador de textos, software para gráficos. entornos CASE, etc.) e incluso de las
preferencias del analista o del cliente.

A continuación se hace un repaso a las notaciones que se utilizan más frecuente-

mente para especificar los sistemas software.

3.5.1. Lenguaje natural

La notación más inmediata que se puede emplear para realizar una especificación
es el lenguaje natural que habitualmente empleamos para comunicarnos. Ylediante
explicaciones más o menos precisas y más o menos exhaustivas es posible describir
prácticamente cualquier cosa. ·

Para sistemas de una complejidad pequeña, es suficiente el lenguaje natural co-

rno notación para realizar su especificación y es la manera en que casi siempre se
suele realizar. Cuando la complejidad del sistema es mediana o grande, resulta prác-
ticamente ünposible utilizar sólo el lenguaje natural. Los principales inconvenientes,
como ya ha sido mencionado, son las imprecisiones, repeticiones e incorrecciones que
se pueden producir. Además, existen otras notaciones que son mucho más adecuadas
para sintetizar aspectos concretos del s istema y que son capaces de ofrecer una visión
más globalizadora, lo que simplifica mucho la especificación del sistema.

El lenguaje natural será la notación que se empleará siempre que sea necesario
aclarar cualquier aspecto concreto del sistema, que no sean capaces de reflejar el resto
de notaciones. En cualquier caso, siempre que se utilice el lenguaje natural es muy
importante organizar y estructurar los requisitos recogidos en la especificación. La
mejor manera de lograrlo, es concebir cada uno de los requisitos como una cláusula
de un contrato entre el analista y el cliente. Así, se pueden agrupar los requisitos
según su carácter:

1. Funcionales
2. Calidad
3. Seguridad
4. Fiabilidad

y dentro de cada gTupo, establecer y numerar correlativamente las cláusulas de dis-

tintos niveles y subniveles que estructuren los requisitos:
1 . Funcionales

■ R.1.1: l\'lodos de funcionamiento

■ R.1.2: Formatos de entrada
 CIOSES PARA L.4. ESPECIFICACIÓN 71

• R.1.3: Formatos de salida

• R.1.4 .....

=a limitar las imprec1s10nes y arnbigüedades propias del lenguaje natural, es

-~.....,,·ente establecer ciertas reglas de uso del lenguaje, que impidan, en la medida
po~ible. un uso retórico o impreciso. Evidentemente, una especificación nunca
~ una novela y es preferible que se utilicen frases siempre con la misrna cons-
---'"""""n que tengan siempre la misma interpretación .

...... lenguaje natural estructurado es una notación más formal que el lenguaje na-
Fundamentalmente se trata de establecer ciertas reglas para la construcción de
~e. en las que se especifica una acción de tipo secuencia, condición o iteración.
trata de obligar a que todas las especificaciones escritas en español utilicen las
ac;::ns.5;; frases: lo que sería imposible. Se trata de lograr que dentro de una misma
----.;;..=_..._~"-· ·ación todas las frases se construyan de igual manera. Por ejemplo. en lugar
·bir en distintos apartados de la especificación:

cuando ae teclee la clave 3 veces mal, debe invalidar•• la tarjeta ...

O.ando el saldo ••a menor de cero peaetaa ae aplicará un interéa ...

Para loa cliente• mayores de 66 aflos se eatablecerá un descuento de

es mejor que todas las frases se construyan de igual manera:

SI•• teclea la cla•e 3 ••e•• 11a]. ENTONCES inYalidar tarjeta .. .

SI el saldo ea menor de cero pesetas ENTONCES el interés será .. .

SI el cliente•• mayor de 66 ali.os ENTONCES el deacuento será .. .

Construcciones similares se pueden utilizar para la iteración y la secuencia. No se

a de utilizar siempre una misma palabra clave (SI , REPETIR , etc.), sino emplear
misma construcción en todas las frases, al menos, de una misma especificación.

3.5.2. Diagramas de flujo de datos

Esta notación está asociada a la metodología de análisis estructurado, que fue
:esarrollada a lo largo de la década de los 70 [De)¡Iarco79]. El enfoque del análisis cs-
!?'llcturado es considerar que un sistema softwarE> es un sistema procesador de datos.
Rf'<'ibe datos como entrada, los procesa, es decir los ordena. los cuenta: los utiliza
-oara calcular expresiones.

Siendo así un sistema software se podría modelar refic•jando el flujo de datos que
tra al sistema, las transformaciones que se realizan con los dat.os de entrada y el
72 ESPECIFICACIÓN DE REQUISITOS

fl ujo de datos que se produc(' a la salida como resultado de la transformación. E sta

filosofía se puede aplicar con total ~f'11Pralidad para 1nodelar los sistemas de infor-
1nación, en los que efrcti,·;:u1H.'nte ;:-.iemµrc- :::-1.' producen sucesivas trans-forn1aciones <le
los datos de entrada (salario, ingresos. precios. etc.) para obtener los datos de salida
(nómina , liquidacion es, factur&;. ete.).

Con los diagra.mab de flujo d<:· datos (DFD) se pueden modelar de forma muy
sen cilla las transformaciones y los flujos de <latos u tilizando una n otación gráfica.
Como se muestra en la figura :3.1 una flecha indica un flujo de dalos e n el sentido
en el que apunta su cabeza. C011 cada flecha de un DFD se tienen que detallar s u s
Datos mediante un nombre o una descripción. U n proceso o transformación de datos
~f' indica con un círculo o burbuja.

Dentro del círculo se nombra o describe el proceso que realua. Una línea doble
indica un almacén de d atos. Estos datos almacenados pueden ser guardados p or
uno o varios procesos y asimismo pueden ser consultados o consumidos por uno o
1nás procesos. Entre las dos líneas se detalla e l nombre o desc ripción de los dato:;
que g uarda e l almacén. Finalmente, un rectángulo r epresenta una entidad externa
al sistem a software (el usuario, otro p rograina. un dispositivo hardware. etc.), qnt>
produce o consumf' sus datos.

Flujo de Datos en el sentido de la flecha

Proceso o transformación de datos

Proceso

'--...---
Entidad Entidad externa que produce o consume datos
Externa

Almacén de datos Almacén de datos con cualquier organización

Figura 3.1: ~otación DFD básica

Corno ejernplo de diagrama de DFD. supongamos el .siguient e f'mn1c ia.do e.le pro-
blc1na: Se trata de especificar un sistt>ma para C'l <'ontrol de acceso a un rc>ciut
mediante una tarjeta y una daYe de acce8o. L a tarjeta rnaguética lleYa graba<la l
datos personalt>s del propietario y la da,·e e.le accf>So. El sistema dispondrá de W::
 L-\.CIONES PARA LA ESPECIFICACIÓN 73

.lado numérico para introducir la clave y un display o pant alla para escribir los
~ajes. El sistema registrará todos los intent os d e accesos aunque sean fallidos por
.-eclear correctamente la clave o por tratar de u t ilizar un tipo de tarjeta incorrecta.

Lector de
tarjetas 1 P,mna 1

Teclado Puerta

Figura 3.2: DFD de contexto para el sistema de control de accesos

En la figura 3.2 se muestra el DFD del sistema global o DFD de contexto. En est e
~ plo, las entidades externas son el lector de las tarjetas magnét icas, el teclado para
.,_'Toducir la clave, la pantalla o display y el dispositivo para la apertura de la puerta.

El lector de tarjetas suministra a nuestro sistema los datos grabados en las mismas
_;o mbre y apellidos, clave de acceso, etc.) y mediante el teclado se lee la clave para
correspondiente comprobación. La pantalla recibe de nuestro sistema los mensajes
.:u-a poder establecer el diálogo con la persona que trata de acceder al recinto y el
spositivo de apertura de la puerta, las órdenes para abrirla.

El DFD de contexto nunca es suficiente para describir el modelo del sistema que
trata de especificar. Para refinar el modelo, los DFD se usan de forma jerarquizada
p r niveles. El DFD de contexto se denomina nivel O. A continuación, cada proceso
b urbuja se puede "explotar" y mostrar cómo se organiza interiormente, mediante
;ros DFD. En el caso de un diagrama de context o , sólo se puede explotar un único
proceso que es el proceso global del sistema y su explosión dará lugar al único DFD
e nivel l.

En el ejemplo del sistema para el cont rol de acceso, la figura 3.3 muestra el
DFD de nivel l. Como se puede observar, los fl ujos de entrada y salida al DFD de
74
------------- --- -------ESPECIPICA CIÓN DE REQUISITOS
nivd 1 corresponden cxactarnente con los que tie1w el proceso Control de Acceso d<'I
diagranrn. de contexto. esto es: Datos Tarjeta, Clave . l\Iensajes y Órdenes.

Datos
Tar,eta

Mensajes de Comprobación
Tar1eta Me nsajes

Tar,eta
Correcta

Clave Órde nes

Acceso Autor izado

Figura 3.3: D FD d<• nivel l para <'I sistema d e control de acceso

La elaborac.ión del 1111eYo DFD es el resultado de la labor de análisis del sistem

que se está espec:-ihcan<lo. Teniendo en c uenta las necesidades del cliente expresada.,
en el enunciado. se ,·e> que hace falta utilizar un alrnacén para guardar los dat os d
la tarjeta que intenta accC'der. :, si finalmentf' se consigue o no. En la figura 3.3. este
almacen ::;e ha denomiuado Información de Accesos.

También. de acuerdo con <'l diente, el proceso Comprobar Tarjeta ser á el en car-
gado de ,·t>rificar si la t.arjeta introducida por el lector es correcta. Esta verificaci< ll
se reduce a comprobar si los datos que tiene grabados la tarjeta lo están en d or<le.
y fonuato adecuado y cou lm, controles de seguridad establecidos. En cualqni<'r ca:--
se grabarán todos los datos clt> la tarjeta l0ída para el control de acceso. E l proce,
Co1nprohar Clave es <·1 encargado de \"<'rificar si la clave tecleada es la misma que
estñ gral>nda cu la tarjc•l a. Si la da,·<• es cm-rectas<' autoriza el acceso. En cualqui( r
casu se graba 1-'I n·sult ado dd i11tento de ¡w<·<>so. LI procc·so Vis ualizar M e nsaje,
es <·1 <:>ne argado de' sacar por pantalla los lll<'llsaj<'H q u e le enYían los dos anl erior
 T-lCIOJVES PARA LA ESPECIFICACIÓIV 75

establecer el diálogo con la persona que trata de acceder al recinto. Finalrnente,

lDI"'")Ceso Control de Puerta es el encargado de ejecutar y temporizar la orden de
---~ura de la puerta.

E! refinamiento del DFD de nivel 1 puede continuar con cada uno de los procesos
.,,. en él aparecen. Una forma de facilitar la identificación de los ara guardar los
- - de la tarjeta que intenta acceder, y si finalmente se consigue o no. En la figura
. este almacén se ha denominado Información de Accesos.

También, de acuerdo con el cliente, el proceso Comprobar Tarjeta será el encar-

de verificar si la tarjeta introducida por el lector es correcta. Esta verificación
r,t"Cluce a comprobar si los datos que tiene grabados la tarjeta lo están en el orden
5mnato adecuado y con los controles de seguridad establecidos. En cualquier caso
grabarán todos los datos de la tarjeta leída para el control de acceso.

El proceso Comprobar Clave es el encargado de verificar si la clave tecleada es

misma que está grabada en la tarjeta. Si la clave es correcta se autoriza el acceso.
- malquier caso se graba el resultado del intento de acceso. El proceso Visualizar
lensajes es el encargado de sacar por pantalla los mensajes que le envían los dos
--t:'riores para establecer el diálogo con la persona que trata de acceder al recinto.
;;:ia)mente, el proceso Control de Puerta es el encargado de ejecutar y temporizar
<..rden de apertura de la puerta. .

El refinamiento del DFD de nivel 1 puede continuar con cada uno de los procesos
_e en él aparecen. Una forma de facilitar la identificación de los sucesivos DFD es
TT erar de forma correlativa los distintos procesos antes de su refinamiento. El DFD
-J.ltante de la explosión de un proceso x tendrá el número x del proceso explotado.
- procesos hijos que aparecen en él se numerarán de 1 en adelante, en la forma x.1,
~.... El único proceso del diagrama de contexto no lleva numeración, y el único
.......grama resultante de nivel 1 se designa como DFD O. De esta manera los sucesivos
~ amas se numerarán de la fonna:

·3vel O Diagrama de contexto

_-:vel 1 DFD O
DFD 1 hasta DFD n
de los procesos 1 hasta n de niYel 1
-h-el 3 DFD 1.1 hasta DFD l.i
de los procesos 1.1 hasta 1.i del niYel 2
DFD 2.1 hasta DFD 2.j
de los procesos 2.1 hasta 2.j del ni,·el 2

DFD n.1 hasta DFD n.k

76 ESPECIFICACIÓN DE REQUISITOS

de los procesos n. l hasta n.k del nh·el 2

:'-Jivel 4 DFD 1.1.1 hasta DFD 1.1.x

DFD 1.1.1 ha,ta DFD 1.1.x

... etc ..

En todos ellos los flujos de datos de entrada y salida antes de la ·'explosión··

del proceso debe coincidir C'On los flujos de entrada y salida del DFD resultado de
la explosión o refinamiento. La ventaja de esta notación es su simplicidad lo que
permite que sea fáciln1ente entendida por todos: cliente, usuario, analista, etc. En
los ejemplos qu<' se desarrollan al final de este capítulo se puede comprobar todo esto

Aunque se podría continuar refinando ele manera indefinida, a partir de un deter-

minado nivel y dependiendo de la complejidad del sistema que se especific a, no tiene
sentido subdividir más los procesos. En este punto es conveniente describir cada uuo
de ellos utilizando otra notación distinta, por ejemplo, el lengu aje natural estructu-
rado que ya ha sido presentado o pseudocódigo que se presentará más adelante en
este rnis1no apartado.

Por otro lado, también es necesario describir las estructuras de cada uno de los
flujos de datos y las estructuras de los datos guardados en cada uno de los almace-
nes de datos. Ebta descripción tarnbién se puede r ealizar mediante lenguaje natural
estructurado o bien utilizando alguna de las notaciones para la descripción de dato~
que se estudiarán en un próximo apartado. En líneas generales, se tratará de descri-
bir mediante una tabla. todos los elementos básicos de información quf' constituyen
los diversos datos que se 1nanejan en los distintos DFD del n1odelo del sistema. Por
eje1nplo, en la figura 3.3, los datos Clave, Tarjeta Correcta o Inforrnación de Accesos.

Para finalizar esta introducción a los diagramas de flujo de datos, c-onviene pre-
cisar algunos aspectos. Principalmente, los DFD sirven para establecer un mo<lek
conceptual del siste1na que facilüa la estructuración de su c::;pecificación. El modelo
así desarrollado es fundamentalrucnt P estático dado que refleja los procesos necesario;:,
para su desarrollo y la interrelación que existe entre ellos. 1'1ediarite un DFD nunca
se pnc>de establ(•cer la dinámica o secuencia en la que se ejecutarán los procesos. P e_ r
ejen1plo. en la figura 3.3 no se c.-,tablec~ ningún orden concreto entre los flujos de
salida del proce-..o Co1nprobar Tarjeta y por tanto, se podrá producir prin1ero Gra-
bar Tarjeta. de::.pués 1\len.saje d<> Con1probación de Tarjeta y finalmente Tarjeta
Correcta o en cualquier otro orden.
 iCIONES PARA LA ESPECIFICACIÓN 77

k única premisa de carácter dinámico que se puede establecer en un DFD es que

s se utiliza un modelo abstracto de computo del tipo flujo de datos (Cerrada00].
:; procesos funcionan de forma semejante a una ··Red de operadores1' y en cada
ción se utiliza y consu1ne un elemento de cada uno de lo::; flujos de datos de
a.da y se generan los elementos de datos previstos para cada uno de los flujos
sa:ida. En el caso de los almacenes de datos. los elementos se utilizan pero no se
~_...~en y pueden ser utilizados posteriormente .

- .3. Diagramas de transición de estados

sistemas software, com o muchos otros que se modelan, no suelen ser estáti-
l.-0-;
Aunque tengan partes integrantes que lo sean, una componente fundamental de
rmsmos será los cambios que se produce durante su funcionamiento. Suelen ser,
anto, sistemas dinámicos. Cuando un sistema permanece inalterado durante un
_odo de tiempo se dice que se encuentra en un estado. Permanece estático. Todos
elementos que pueden cambiar en el sistema, elementos variables, no cambiarán.
manera de caracterizar un sistema dinámico es mediante la descripción de los
i:>ntes estados por los que puede pasar y la transición entre los mismos.

E! número de estados posibles que se pueden dar en un sistema software crece

una forma exponencial con su complejidad. Incluso para sistemas bastante sim-
el número de estados es muy grande. Hay que tener en cuenta que cada vez
se rnodifica una variable, se evalúa una condición o el término de una expresión
?roduce un cambio de estado en el sistema. Todos estos estados y las sucesivas
.,;,.-siciones entre ellos configuran la dinán1ica del siste1na que se produce mientras
~tá ejecutando.

Para realizar la especificación de un sistema, de todos sus estados posibles, sólo

Eportante resaltar aquellos que tienen cierta transcendencia desde un punto de
...:-ta funcional. El diagrama de transición de estados e,5 la notación específica para
ie:::cribir el comportamiento dinámico del sistema a partir de los estados elegidos co-
más importantes. Por tanto , es una notación que se complementa perfectamente
:::. los diagramas de flujo de datos y que ofrece otro punto de vista del sistema que
la mayoría de los casos resulta irnprescindible.

La notación básica para elaborar los diagramas de estados que se emplea habi-
almente se muestra en la figura 3.4 como se puede observar en la figura, se sugieren
:, form as distintas para representar un estado: rnediante un rectángulo o mediante
i:..= círculo. En ambas notaciones se indica rnediante el nombre que encierran en su
c:uerior el estado concreto que representan. La razón por la que existen estas dos
osi bilidades es su procedencia. Los diagramas de estado mediante círculos son los
~ás utilizados para representar autómatas de ef:tados finitos (autómatas mecánicos,
78 ESPECIFICACIÓN DE REQUISITOS
•
circuitos ellictricos o electrónicos y automatismos en general). Sin embargo, para
evitar la confusión con la notación ernpleada en la elaboración de los DFD, para lz
especificación de un sistema software se suelC' emplear el rectángulo.

Estado inicial/final del sistema

Arranque/parada del sistema

EJ 0 Estado intermedio del sistema

Evento que provoca el cambio de estado

Figura 3.4: Notación básica de diagramas de estado

Los eventos que provocan el cambio de estado se indican mediante una flecha d.
rigida desde el estado viejo al nuevo estado. Por razones estéticas se emplean flech=
en forma de arco cuando se utilizan círculos y formadas por tramos r ectos cuando
utiliza un rectt.1.Ugulo.

Cuando -.e con.c,idcre interesante destacar los estados inicial y final del sistema.
pu e hacer mcdiantf' dos círculos concéntricos.

En la figura 3.5 sC' muesl ra el diagran1a de estados del sisle1na de acceso. En e-

~o el :,i,tcma es umy seudllo y los estados posibles son solamente tres: Esper ..
Tarjeta. E:-perar Clave y Permitir Acceso. Respecto a los eventos qu<' provocan :
cambio:c. dP estado, se dcb0rán utilizar otrab notaciones para detallar <le manf'ra 11-:!:
prccba el significado c·oncrcto <le cada uno df' f'Jloi:,. A pesar <le todo. este diagr~
mo<lcl;:i de n1ar1f'ra sencilla y precisa la dinámica del sistema y se complementa per-
fectamente con los D FD del apartado anterior para lograr una. especificación lo I11.&::
completa y 0xacta posible.
 ..\CIONES PARA LA ESPECIFICACIÓN 79

Arranque del
Sistema Fin del acceso

Tarjeta
- - - - N o válida

Clave
Esperar Incorrecta Permitir
Tarjeta
Acceso

Parada del Clave

Sistema ,......_.__ _..., Correcta
Esperar
Clave

Figura 3.5: Diagrama de estado del sistema de acceso

En los ejemplos del final del capítulo se mueslra otro diagram de estado emplean-
una notación alternativa.

Cuando la complej idad del sistema así lo requiera, serán necesarios varios día-
amas de estados. Además del diagrama de estados global del sisterna, pueden ser
esarios otros diagramas adicionales para especificar la dinámica de determinados
esos significatiYos del sistema. En estos casos, es importante elegir cuidadosa-
nte los estados y las transiciones que faciliten la comprensión del sistE>ma sin
fundizar en detalles de diseño que dcbC'rán ser concretados posteriormente.

3.5.4. Descripciones funcionales. P seudocódigo

Los requisitos funcionales son una parte muy importante de la especificación de
-:.o ::;istf'ma. P or tanto. es esencial que las dcscripcion<'s func1onalcs se realict>n em-
eando una notación precisa y quf' no S(' pre:,,t a an1higiit>dad0s. Como mínimo se

•
80 ESPECIFICACIÓN DE REQUISITOS
•
deberá utilizar un lengua j e natural estructurado y siempre que sea posible es acon-
sejable utilizar una notación algo más precisa que denominaremos pseudocódigo.

Entenderemos por pseud ocódigo una notación basada en un lenguaje de pro-

gramación estructurado (P ascal, ::\lodula-2, Ada, etc) del que se excluyen todos los
aspectos de declaración de constantes, tipos, variables y s ubprogramas. El pseudo-
código maneja datos en general, no tiene una sintaxis estricta, como sucede con
los lenguajes de programación y se pueden incluir descripciones en lenguaje natural
siempre que se considere necesario, como parte del pseudocódigo.

Hay que tener cuidado al en1plear pseudocódigo para realizar una especificación
software. Si se detalla o "refina" demasiado una descripción funcional mediante pseu-
docódigo, se puede estar realizando el diseño del sistema e incluso su codificación. De
hecho, existen notaciones similares al pseudocódigo que están pensadas para realizar
el diseño. En este caso, se habla de lenguaje de descripción de programas (PDL -
Program Description Language). Estos lenguajes para el diseño, se estudiarán en el
capítulo dedicado a las técnicas generales de diseño.

Es importante destacar que aunque se utilicen notaciones parecidas (pseudocódi-

go o PDL), los objetivos que se persiguen son muy diferentes. Cuando se especifica.
se trata de indicar cual es la naturaleza del problema a resolver, sin detallar cómo se
debe resolver. En este sentido, en una especificación no se debería establecer ningu-
na forma concreta de organización de la información, ni tampoco ninguna propuesta
concreta de los procedimientos de resolución de los problemas.

La notación de las estructuras básicas que se pueden emplear en el pseudocódigc

tendrán los siguientes formatos:

A.- Selección:

SI < P seudocódigo de la Condición> EXTONCES

<Pseudocódigo>

<Pseudocódigo>
FIK-SI

donde <Pseudocódigo de la Condición> es la condición que se debe verificar par-

efectuar el < P seudocódigo> indicado después de ENTQ:-,.¡CES o en caso contran
efectuar el < Pseudocódigo> indicado después de SI-NO. Por ejemplo, para el siste-
ma de control de acceso tendríamos:
 OTA. CIONES PARA LA ESPECIFICACIÓN 81

SI Datos Tarjeta son Correctos ENTONCES

Guardar Datos Tarjeta;
Comprobar Clave
SI-~O
Devolver Tarjeta
F~-SI

Evidentemente, cuando se necesiten se pueden anidar varias selecciones unas den-

- de otras .

B.- Selección por casos:

CASO <Especificación del elemento selector>

SI-ES <Descripción del caso l> HACER <Pseudocódigo> ;
SI-ES < Descripción del caso 2> HACER <Pseudocódigo> ;

SI-ES <Descripción del caso N> HACER <Pseudocódigo>;

OTROS <Pseudocódigo>
FIN-CASO

donde <Especificación del elemento selector> determina el elemento con el que se

:t:"Ctúa la selección. Este elemento sólo podrá tomar un número acotado de valores
_ ~intos y según tome uno u otro se efectuará el <Pseudocódigo> correspondiente.
_ <Pseudocódigo> indicado después de OTROS se realizará cuando el valor del
:..-emento no coincida con ninguno de los previstos. Por ejemplo) para seleccionar en
= cajero automático el, tipo de operaciones que se pueden realizar dependiendo del
· ;,o de tarjeta! introducida, se tendría:

CASO Tipo de Tarjeta

SI-ES Visa HACER Operaciones a crédito;
SI-ES CuatroB HACER Operaciones en cuenta;
SI-ES Express HACER Operaciones con confirrnación;
OTROS Devolver Tarjeta
FIN-CASO
82 ESPECIF ICACIÓN DE REQUIS ITO.

C .- Iteración c on pre-condición:

l.VIIE::--JTRA.S <Pseudocódigo de la condición> H ACER

<Pseudocódigo>
F I::--J-l\.1IENTRAS
que efectú a el < P seudocódigo> mient ras que se verifique la condición ind icad
por<Pseudocódigo de la condición >.

D.- Iterac ión con pos t-condición:

REPETIR
<Pseudocódigo>
HASTA <Pseudocódigo de la condición >
que efectúa el <Pseudocódigo> h asta qu e se verifique la cond ición in dicada por
<Pseudocódigo de la condición> . P or ejemplo, en el sistema de con trol d e accesc
para cornprobar la clave se pueden p~rmitir hasta tres inten tos:

REPETIR
Leer Clave
HASTA Clave correcta o Tres intentos incorrectos

E.- Número de iteraciones conocido:

PARA-C ADA < E specificación del elem ento ín d ice> H ACER

< P seudocódigo>
FIK-PARA
donde <Especificación del elemento índice> indica el número de veces que se efectú
el <Pseudocódigo>. Por ejemplo, si se quieren listar todos los accesos realizados e
el sistema de control de acceso, se podría in d icar:
PARA.-CADA Acceso registrado HACER
Escribir datos del acceso;
Escribir resultado del acceso
FI::\'-PARA

3.5.5. Descripción d e d a tos

La descripción de los datos constituye otro aspecto fundamental de una espec::
cación software. Se trata de detallar la estructura interna de los datos que n1an~.
el sisterna. Lo mismo que sucede con la descripción funcional, cuando se realiza u=
descripción de datos no se debe descender a detalles de diseño o codificación. Sólc
deben describir aquellos datos que resulten relcvant,es para entender que debe h ao
el sistema.
 _.\CIONES PARA LA ESPECIFICA.CIÓ!"\' 83

En principio, también los datos se pueden describir utilizando el lenguaje natu-

-..n e1nbargo es mejor emplear notaciones rnás específicas. {;na posible solución
.•;zar la notación usada para definir tipos de datos en alguno de los lenguajes
--rurados habituales (Pascal, ::vlodula-2 o Ada). Sin einbargo. esta solución tiene
mconveniente fundarnental la gran dependencia de una sintaxis concreta y la
sidad de detallar aspectos propios de la fase de diseño o codificación tales como
:amaño o el tipo concreto de cada elemento.

Lo. notación adoptada en la metodología de análisis estructurado es lo que se co-

como diccionario de datos [Yourdon90]. Esta notación es bastante más informal
-ualquier definición de tipos de un lenguaje de programación pero con ella se
_ una descripción de los datos suficientemente precisa para la especificación de
~ ::1·15-i tos.

~aoque existen diversos formatos posibles de diccionario de datos según los dis-
- s autores o herramientas CASE que lo incorporen) en esencia todos los formatos
:J.Sejan que al menos se pueda describir la siguiente inforn1ación para cada dato:

A.- Nombre o nombres:

Será la denominación con la que se utilizará este dato en el resto de la especifica-
Puede ocurrir que para mayor claridad de la especificación se utilicen distintos
-bres para datos que tienen una misma descripción.

B.- Utilidad:
.. e indicarán todos los procesos, descripciones funcionales, almacenes de datos.
en los que se utilice el dato.

C.- Estructura:
Se indicarán los elementos de los que está constituido el dato, utilizando la si-
~ente notación:

- B Secuencia o concatenación de los elementos A y B

.'-\ B ] Selección entre los distintos elementos A o bien B
A }N Repetición N veces del elernento A (se omite ::--J' si es indeterminado)
-~ ) Opcionalmente se podrá incluir el elemento A
~escripción / Descripción en lenguaje natural como c01nentarios
Separador entre el nornbrc de un elem.ento y su descripción

Para ilustrar una descripción de datos , a continuación se detallan algunos de los

¡:os del sistema de control de acceso:
 84 ESPECIFICACIÓN DE REQUISITOS

Nombres: Datos Tarjeta

Grabar Tarjeta

Utilidad: Proceso: Comprobar Tarjeta con10 entrada

Proceso: Comprobar Tarjeta corno salida
Alrnacén de datos: Información de Accesos como entrada
Entidad externa: Lector de Tarjetas como salida
Estructura: ~ombre +
Prirner Apellido +
Segundo A pcllído -
~ivcl de Acceso 1
Clave ...1..
( Código empresa )

Kombre = / Ristra con 10 caracteres máximo/

Primer Apellido - / Ristra con 20 caracteres máxirnoí
Segundo Apellido -= / Ristra con 20 caracteres máximo/
Xivel de Acceso - [0 1 112]
Código empresa - l 101 11021 ... 1199 J
~ombre: Clave
utilidad: Proceso: Comprobar Clave como entrada

Estructura: { Dígito }4
Dígito= / Carácter numérico del O al 9 /

3.5.6. Diagramas de modelo de datos

Si un sistema maneja una cierta cantidad de datos relacionados entre sí, com
sucede habitualmente en los sistemas de información, es necesario establecer un_
organización que facilite las operaciones que se quieren realizar con ellos. Por ejem-
plo, si tenernos datos de países, regiones, ciudades, etc. y entre ellos ·existen cierta.
relaciones tales como: una ciudad es capital de un determinado pais o un país tiec-
embajada en una determinada ciudad o una ciudad esta en una determinada regió::
etc., inmediatamente surge la necesidad de establecer una organización entre los da-
tos que simplifique y agilize su utilización. Precisamente dicha organización es la q~
configura la estructura de la base de datos que utilizará el sistema.

Es fundarnental que en la especificación se establezca el modelo de datos que ~

considera más adecuado para conseguir todos los requisitos del sistema. Este mode.
se conoce como modelo entidad-r<>larión (modPlo E-R) y pernüte definir t odos k•
datos que manejará el sistcrna junto con laR relaciones qrn, se desea que exist~
 CIOJ\'ES PARA LA ESPECIFICA.CIÓ.IV 85

ellos. Aunque el modelo estará sujeto a revisionPs durante las fases de diseño y
7'\ción, como sucede con el resto de la especificación, sin embargo, es un punto
ida i1nprescindible para comenzar cualquier diseño.

Relación entre entidades/datos

Entidad/Datos relacionados
Entidad

Min: Max Cardinalidad entre Mínimo y Máximo

Sentido de la relación

Figura 3.6: ~otación básica de diagramas de datos

~ten diversas propuestas de notación para realizar los diagramas E-R, aunque
todas ellas las diferencias son mínimas. En la figura 3.6 se recogen los elementos
notación más habituales. Las entidades o datos que se manejan en el diagrama
cierran dentro de un rectángulo, por ejemplo: ciudad, país, región, etc. Las re-
es se indican mediante un rombo que encierra el t ipo de relación , por ejernplo:
pital de, tiene embajada en, está en, etc.

Las entidades y la relación que se establece entre ellas se indican uniéndolas todas
ante líneas. Opcionalmente, se puede indicar el sentido de la relación con una
a. Es conveniente utilizar la flecha sobre todo cuando únicamente con el nombre
....;. relación encerrado en el rombo no queda claro cual es su sentido.

Otro elemento fundamental es la cardinalidad de la relación, esto es, entre que

?'es mínimo y máximo se mueve la relación Pntre entidades. Por ejemplo, un país
e no tener embajada en ninguna ciudad o tenerlas en muchas. En los diagramas
-R. la cardinalidad se indica según se muestra en la figura 3. 7 , donde cero es un
o, uno es una raya perpendicular a la línea de relación y 1nuchos o ~ son t res
en bifurcación. La cardinalidad se dibuja siempre unida a la segunda entidad
la relación con un símbolo para el valor mínimo y otro para el máximo.
86 ESPECIFICACIÓN DE REQUISITO~

Cardinalidad

-----Of- 0:1 -----OE O:N

1:1 1:N

Figura 3.7: :\'otación para la cardinalidad de las relaciones

Para explicar mejor todo esto, veamos la figura 3.8 Inicialmente la relación "C
pital" es ambigua dado que no queda claro si se trata de "es Capital de" o de "tiet
como capital". La flecha nos aclara, en este caso, que la relación principal del diagr
ma es "es Capital". Teniendo en cuenta la cardinalidad unida a la segunda entida-...
tenemos la relación: Una ciudad puede ser la capital de ningún país o s~rlo com
máximo de uno.

Ciudad País

Figura 3.8: Diagrama E-R sencillo

También en el rnisrno diagran1a se indica la relación inversa: Cn país tiene cc.::.

capital una y sólo una ciudad. Esta es la razón de utilizar nombres ambiguos para
relaciones, que se puedan emplear en an1bos sentidos y así se prescindirá de la flec...
En la figura 3.9 se tiene el diagrama E-R del sistema completo, cuya interpretac-
rcsulla trivial.
 DIENTO DE ESPECIFICACIÓN DE REQUISITOS 87

Figura 3.9: Diagrama E-R completo

Documento de especificación de requisitos

El documento de especificación de requisitos, denominado SOFTWARE REQUI-
rJIENTS DOCUMENT (SRD) o SOFTWARE REQUIREMENTS SPECIFICA-
J_V (SRS) en la literatura anglosajona, es el encargado de recoger todo el fruto
trabajo realizado durante la etapa de análisis del sistema de una forma integral

Pueden existir otros documentos previos al SRD, tales como los estudios d e viabi-
~ o los estudios d e las diversas alternativas posibles, centrados fundamentalmente
:os aspectos de la gestión del proyecto. También es posible , cuando el proyecto es
r amplio y se prolonga mucho en el tiempo, que se elabore un documento con la
~"oria del proyecto y todas las vicisitudes habidas, de las que se podrán sacar en-
:anzas en futuros proyectos. Todos estos documentos tienen una utilidad concret a
..o no son imprescindibles. sin embargo, el SRD es un documento fundamental y
d punto de partida d el desarrollo de cualquier sistema software.

Con carácter general, el SRD debe cubrir todos los objetivos indicados en la sec-
a 3.4. Además, dado que será un documento que deberá. ser revisado con cierta
_uencia a lo largo del desarrollo de la aplicación. es muy conveniente que se re-
te de una forma fácil de modificar. Por otro lado. también debe facilitar la labor
,·erificación del cumplimiento de la.e, especificaciones. Todo esto hace que la mejor
.nera de redactar este documento sea C'n forma de un contrato con sus distintas
Jstilas organizadas y agrupadas según E>l c:aráct<'r <le los requisitos.

Son muy numerosas las propuesta-.; de organi7ación del documento SRD. Se pue-
<lecir que prácticamente cada autor proponc> uno distinto. Sin cmhargo. en líneas
neralcs todas las propuest.as son similarc-.. Div(•rsos organismos internacionales ta-
88 ESPECIFICA.CIÓN DE REQUISITOS

les como IEEE [IEEE84], el Departamentc, de Defensa norteamericano [DoD88] o la

Agencia Espacial Europea [ESA91] han e;rablecido su propia organización de docu-
mentos y los imponen a las empresas que contratan para evitar el caos que supondría
la coordinación de miles de proyectos cada uno con una. organización distinta de la.
documentación.

A continuación se sugiere un modelo de documento SRD basado en la propuest

de la Agencia Espacial Europea [ESA91]. Este documento tiene un carácter genera.
y en algunos casos no será necesario cumplimentar todos sus apartados. El índic
del documentó propuesto se recoge en el cuadro 3.1. El contenido de cada apartad
debería ser el siguiente:

l. INTRODUCCIÓN

Esta sección debe dar una visión general de todo el documento SRD.
1.1 Objetivo

Debe exponer brevemente el objetivo del proyecto, a quién va dirigido, l

participantes y el calendario previsto.
1.2 Ámbito

En esta subsección se identificará y dará nombre al producto o los produ

tos resultantes del proyecto. Asimismo, se explicará qué hace cada uno y
se considera necesario que no será capaz de hacer. También se detallara.:.
de manera precisa las posibles aplicaciones y beneficios del proyecto.

1.3 Definiciones, siglas y abreviaturas

Aquí se incluirá un glosario que contendrá una lista de definiciones de tk-

minos; siglas y abreviaturas particulares utilizados en el documento, y q
convenga reseñar para facilitar su lectura o evitar ambigüedades. Toda
ta información organizada y clasificada convenientemente, se podrá recog
también en uno o varios apéndices al final del documento.

1.4 Referencias

Si el documento contiene referencias concretas a otros, se dará una lista e

la descripción bibliográfica de los documentos referenciados y la manera
obtener acceso a dichos documentos.
 U3 fEST O DE ESPECIFICACIÓS DE REQCISITOS 89

1.5 Panorámica del documento

Esta subsección describirá la org anización y el conteni<lo del resto del do-
cumento.

_ DESCRIPCIÓ . GE ERAL

En est a sección se dará una Yisión general del sistema. ampliando el contenido
de la sección de introducción. Constará de los siguientes apartados:

2.1 Relación con otros proyectos

Se describirán la.e; analogías y diferencia::; de este proyecto con otro::; simila-

res o complementarios, o con ot ros sistemas ya existentes o en desarrollo.
Si no hay proyectos o sistemas relac.ionados, se indicará ·':"\o aplicable··.

2.2 Relación con proyectos anteriores y posteriores

Se indicará si est e provecto es continuación de otro o si se continuará el

desarrollo en proyectos posteriore-.. Si no hay proyectos de esta dase. se
ind icará ·'No e.'C:isten''.

2.3 Objetivo y funciones

Se debe describir el sistema en su conjunto con los objetivos y las funciones

prin cipal<'S.

2.-1 Consideraciones de entorno

En est e apartado se describirán las características esp<'<ialcs que debe te-

~s- ner el entorno en que se utilice el si,tema a df'sarrollar Si no se necesitan
er
características especiales, se indicara ··No existen··.

2.5 Relaciones con otros sistemas

Se describirán las <'Onexio11e~ dd :-i,remn con otros. si debe f1mcionar inte-

n
grado con ellos o utilizando entradas o salidru; indirectas de información.
e
Si el sistema no ne<'esita intercambiar información con !llllgún otro, se in-
dicará " •o existen".
90 ESPECIFICACIÓN DE REQUISITO

2.6 Restricciones generales

Se describirán las restricciones generales a tener en cuenta a la hora d

diseñar y desarrollar el :;istema. tales como el empleo de determinadas me-i
todologías de desarrollo. lenguajes de programación, normas particulares
restricciones de hardware. de sistema operativo , etc.

2. 7 Descripción del modelo

Este será probablem ente el apartado más extenso de esta sección. Del>'
describir el modelo conceptual que se propone para desarrollar el sistem
en su conjunto y para cada una de sus partes más relevantes. E ste model
se puede realizar utilizando todas las notaciones y herramientas dispoIL
bles.

3. REQUISITOS ESPECÍFICOS

Esta sección es la fundamental del documento. Debe contener una lista det
Hada y completa de los requisitos que debe cumplir el sistema a desarrollar .

Los requisitos deben exponerse en la forma más precisa posible, pero sin que
descripción de un requisito individual resulte demasiado extensa. Si fuera neo
sario: puede darse una descripción resumida y hacer referencia a un Apéndi
con la d escripción detallada.

Es importante no incluir en los requisitos aspectos de diseño o desarrollo. L

requisitos son lo mínimo que se impone al sistema, y no hay que describir s
luciones particulares que no sea obligatorio utilizar (excepto como aclaración
sugerencia) .

E s ventajoso enunciar los requisitos en forma de una lista numerada, para :

cilitar su seguimiento y la validación del sisterna. Cada requisito debe ir aco::
pañado de una indicación del grado de cumplimiento necesario, es decir , si
obligatorio, recomendable o simplen1ente opcional .

Los requisitos se agruparán en los apartados que se indican a continuación

no hay requisitos en algw10 de ellos, se indicará "No existen".
º1IENTO DE ESPECIFICA. CIÓX DE REQUISITOS

3.1 Requisitos funcionales

Son los que describen las fu nciones o el Q'CÉ debe hacer el sistema y están
muy ligados al modelo conceptual propuesto. A.qui se concretarán las ope-
raciones de tratamiento de información que realiza el sistema, tales como
almacenamiento de información. generación de informes, cálculos, estadís-
ticas, operaciones. etc.

3.2 Requisitos de capacidad

Son los referentes a los volúmenes de información a procesar, tiempo de

respuesta, tamaños de ficheros o discos. etc. Estos requisitos deben expre-
sarse mediante valores numéricos e incluso, cuando sea necesario, se darán
valores para el peor, el mejor y el caso más h abitual.

3.3 Requisitos de interfase

Son los referentes a cualquier conexión a otros sistemas {hardware o soft-

ware) con los que se debe interactuar o comunicar. Se incluyen. por tanto.
bases de datos, protocolos. formatos de ficheros, sistemas operativos, datos.
etc. a intercambiar con otros sistemas o aplicaciones.

3.4 Requisitos de operación

Son los referentes al uso del sistema en general e incluyen los requisitos
de la interfase de usuario (menús de pantalla, manejo de ratón , teclado ,
etc.), el arranque y parada. copias de seguridad, requisitos de instalación
y configuración.

3.5 Requisitos de recursos

Son los referentes a elementos hardware. software, instalaciones. etc., nece-

sarios para el funcionamiento del sistema. Es muy importante estimar los
recursos con cierto coeficiente de seguridad en previsión de necesidades de
última hora no previstas inicialmente.

3.6 Requisitos de verificación

Son los que debe cumplir el :;istema para que sea posible verificar y certi-
ficar que funciona correctamente (autotest. emulación, simulación. etc.).
92 ESPECIFICACIÓN DE REQUISITOS

3.7 Requisitos de pruebas de aceptación

Son ]os que deben cumplir las pruebas de aceptación a que se someterá e
sistema.

3.8 Requisitos de documentación

Son los referentes a la documentación que debe formar parte del product
a entregar.

3.9 Requisitos de seguridad

Son los referentes a la protección del sistema contra cualquier manipula-

ción o utilización indebida (confidencialidad, integridad, virus, etc.).

3.10 Requisitos de transportabilidad

Son los referentes a la posible utilización del sistema en diversos entorne-

º sistemas operativos de una forma sencilla y barata.
3.11 Requisitos de calidad

Son los referentes a aspectos de calidad, que no se incluyan en otros apai.

tados.

3.12 Requisitos de fiabilidad

Son los referentes al límite aceptable de fallos o caídas durante la operaci

del siste1na.

3.13 Requisitos de mantenibilidad

Son los que debe cumplir el sistema para que se pueda realizar adecuadt:
mente su rnanti:>rlimiento durante la fase de explotación.
 L\IENTO DE ESPECIFICACIÓN DE REQUISITOS 93

3.14 Requisitos de salvaguarda

Son los que debe cumplir el sistema para evitar que los errores en el fun-
cionamiento o la operación del sistema tengan consecuencias graves en los
equipos o las personas.

- APÉNDICES

e incluirán como apéndices todos aquellos elementos que completen el conte-

nido del documento, y que no estén recogidos en otros documentos accesibles a
los que pueda hacerse referencia.

)a!-

d..
94 ESPECIFICACIÓN DE REQUISITOS

l. L,TRODCCCIÓ~
1.1 ObjetiYo
1.2 --\mbito
1.3 Definiciones. sigla.-, y abreviaturas
l A Referencias
1.5 Panorámica del documento
2. DESCRIPCIÓ~ GE~ERAL
2.1 Relación con otros proyectos
2.2 Relación con proyectos anteriores y posteriores
2.3 ObjetiYo y funciones
2.4 Consideraciones de entorno
2.5 Relaciones con otros sistemas
2.6 Restricciones generales
2. 7 Descripción del modelo

3. REQUISITOS ESPECÍFICOS
3.1 Requisitos funcionales
3.2 Requisitos de capacidad
3.3 Requisitos de interfase
3.4 Requisitos de operación
3.5 Requisitos de recursos
3.6 Requisitos de ,·erificación
3. 7 Requisitos de pruebas de aceptación
3.8 Requisitos de documentación
3.9 Requisitos de seguridad
3.10 Requisitos de transportabilidad
3.11 Requisitos de calidad
3.12 Requisitos de fiabilidad
3.13 Requisito.s de mantenibilidad
3.1-1 Requisitos de sah-aguarda
4. APÉ~DICES

Cuadro 3.1: Índice de Documento SRD

 ,fPLOS DE ESPECIFICACIONES 95

Ejemplos de especificaciones
En este apartado se recogen las especificaciones completas de dos sistemas, que
trán desarrollando a lo largo del libro.

Videojuego de las minas

El documento SRD para el videojuego de las minas es el siguiente:

DOCUMENTO DE REQUISITOS DEL SOFTWARE (SRD)

Proyecto: JUEGO DE LAS MINAS (Versión simple)
Autores: J.A. Cerrada y R.Gómez Fecha: Enero 1999
Documento: MI~AS-SRD-99
CONTE~IDO
l. ~TRODliCCIÓK
1.1. Objetivo
1.2. Ámbito
1.3. D efiniciones, siglas y abreviaturas
1.4. Referencias
1.5. Panorámica del documento
2. DESCRIPCIÓN GENERAL
2.1. Relación con otros proyectos
2.2. Relación con proyectos anteriores y posteriores
2.3. Objetivo y funciones
2.4. Consideraciones de entorno
2.5. Relaciones con otros sistemas
2.6. Restricciones generales
2.7. Descripción del modelo
3. REQüISITOS ESPECÍFICOS
3.1. Requisitos funcionales
3 .2. Requisitos de capacidad
3.3. Requisitos de interfase
3.4. Requisitos de operación
3.5. Requisitos de recursos
3.6. Requisitos de verificación
3.7. Requisitos de pruebas de aceptación
3.8. Requisitos de documentación
3.9. Requisitos de seguridad
3 .10. Requisitos de t ransportabilidad
3.11. Requisitos de calidad
3.12. Requisitos de fiabilidad
3.13. Requisitos de mantenibilidad
3.14. Requisitos de salvaguarda
 96 ESPECIFICACIÓN DE REQUISITOS E.JEl
------------------------
1. fNTRODUCC1ÓN

1.1 Objetivo
Se trata de realizar un videojuego denominado Juego de las Minas cuyas reglas y características
generales se detallan en los siguientes apartados de este documento.
I.a utilización de est<' videojuego deberá SN fácil de aprendor sin necesidad d<' la lectura previa
de ningún manual. E11 todo ca.t:>o, el juego dispondrá de las correspondientes ayudas para facili-
tar su aprendizaje.
1.2 Ámbito
En este proyecto se r<'ali;:1tr:\ 1111a Vl'rsión simple ci<'I videojuego que solamente utilizará pantalla
alfanum6rica y teclado.
1.3 Definiciones, siglas y abreviaturas
'.!:i!&.l&.!ll.: Elemento gráfico que se muestra Ni la pantalla del computador con forma de cuadrícula
y en el que se desarrolla el juego.
Casilla: Cada uno de los elementos de los que está formada la cuadrícula del tablero.
Mina: Elemento oculto en una casilla del tablero y que si se destapa provoca la finalización del
juego de manera infructuosa para l'i jugador.
1.4 Referencias
No aplicable.
1.5 Panorámica del documento
l::n el resto de este documento ¡¡e recogen el modelo conceptual, las reglas del juego y los requi-
sitos que debe cumplir el sistema a desarrollar.

2. DESCRIPCIÓN GENERAL
2.1 Relación con otros proyectos
Ninguna.
2.2 Relación con proyectos anteriores y poAteriores
~;n esto desarrollo se abordará una versión simple que uti li;mrá u11a interfase de usuario par
pant.alla alfa11umérica y teclado. Rn una fase posterior, se desarrollarfl una versión mfls elaber
rada que utilizará. pantalla gráfica y ratón. El desarrollo de esta versión simple y la posterior
debertl diferir solamente en los módulos rspecfficos dedicados a la interfase hombre-máquina.
2.3 Objetivo y funciones
El objetivo es realizar una versión simplificada del juego de las minas. En este juego se t ratad_
descubrir dentro del tablero la situación de las minas sin que ninguna de ellas explote y en e,
menor tiempo posible.
Las funciones básicas seráu:
• Selección del nivel de dificu ltad del juego (bajo, medio, alto)
• Desarrollo de la partida según las reglas de juego
• Blaboración y mantenimiemo de la tabla de mejorei; resultados
• Ayudas al jugador
2.4 Consideraciones de entorno
No existen.
2.5 Relaciones con otros sistemas
No existen.
2.6 H<'striccion<'s g<'nNalC's
Para la realización de este proyecto se deberán utilizar las siguientes herramientas y entorno,
Lenguaje de programación: C 1-
Metodología: Desarrollo modular basado en abstracciones
SistC'rna op1•ra1.ivo: DOS versión 3.0 o post.erior
Mflximo personal: l p<'rsona
2.7 Descripción del mod elo
En el juc&o se empica u11 tablero cuadrado d<i N casillas de lado semejante al que se muestra r-
ia ílgura M.1. En c~u· tablero 1•,;tán ocultas un 11úrrwro determinado d<' rnir111.~ que pueden cst
sit uadas 1•11 cualqu i<>r nuiilla. lniciahn<>nlí' SI' muestra el t.ablcro con todas las casillas tapadd
En el ejemplo de la 11gura :\1.1, las casillas tapadas están en blanco. El jugador l.icne qu<'
destapando las casillas para descubrir la situación de las minas. Cuando se destapa una casil"
que t.icne una rni11a, esta mina explota y s1• acaba el juego infructuosamente. El objetivo e!
juego es r11ro11t rar la siluació11 d.- ludas las miuas sin que <'xplote ninguna de ellas.
Para facilitar la búi,queda de lOdas la,, minas, el jugador podrá marcar una casilla cuando ten¡,.
• Ja certeza de que Pn Pila existe una mina. En la figura M.1 la marca ~e indica con el sírnho
:.-'IPLOS DE ESPECIFIC.4CIOl\'ES 97

"!!". Esta marca impide que pueda ser destapada la casilla por error. El jugador lambién podrA
quitar la marca de una casilla. En todo momem.o se mostrará en pantalla el número de minas
ocultas y todavía no marcadas.

El jugador podrá seleccionar el grado de dificultad del juego entre tre~ niveles: bajo, medio y
alto. En cada nivel se empleará un tamaño dist.inl.o d~ tablero y el número de minas a descubrir
Lambién será distinto. La situación de las minas en el tablero se real7ará de forma aleatoria..

1 .
2 2 1 2 2 '1
s I! 1 - 1 1 1 2

u 2 1 - 1 1 1 !I
1
.. - 3
.-
1 X 1

3 1 1 1 - . . 1 .

. !J 1
2
1 - 1- 1 i 1
11
1 • 1
1 1 1

1 1
l 1
1
r
1 '
Figura 1\11: Tablero del juego de las minas

Cada vez que el jugador destapa una casilla, se deberá indicar si tenía una mina, en cuyo caso
finaliza el juego. o el número de minas que rodean La. =;lla que ha sido destapada. En la figura
lvfl las casillas con el símbolo".:· indican que el número de minas que las rodean son cero. El
número de minas que pueden rodear una casilla. pueden ir desde O basta 8.

El juego dispondrá de un cronómetro que actualiza en pantalla cada segundo el tiempo transcu-
rrido desde el comienzo de Ja última partida. Si el jugador consigue descubrir todas las minas,
el programa registrará el tiempo invertido junt.o con eJ texto que desee poner el jugador y ac-
tualizará la lista de los mejores tiempos registrados en el nivel correspondiente: bajo, medio o
alto.

2.7.1 Descripción de datos

L-0s principales datos que :,,e utilizan son los siguientes:
~ombre: Tablero
Estructura: tamaño del rahlero - nº de minas ! información de casilla
información de ca.silla - si no mina
si no d<'Stapada -
si no marcada
Kombre: :\lejore,; resu 1t ados
Estructura: informacióu resultado
información resultado - Tl'xto d!'I ganador +
nh el de dificultad
til'mµu invertido

2. 7 .2 Diagrama de tran::;ici,m dE c-,tddO:,

El diagrama de estados del :,i::,1¡,ma se muestra en la figura :\1.2
98 ESPECIFICACIÓN DE REQUISITOS

Nueva jugada

Figura J\,12: Diagrama de estados

3. REQUISITOS ESPECÍFICOS
3.1 Requisitos funcionales
R.1.1.1 El juego se iniciará al destapar la. primera. casilla.
R.1.1.2 Al iniciarse el juego se pondrá. el cronómetro en marcha y se situarán de forma aleatoria
las minas en el tablero.
R.1.1.2 El cronómetro se actualizará cada segundo.
R.1.1.4 En cada paso del juego, el jugador puede destapar una casilla, marcar en una casilla la
presencia de una mina o quitar la marca puesta en cualquier paso anterior.
R.1.1.5 Al destapar una casilla que tiene una mina se acaba el juego de forma infructuosa para e
jugador y se muestra la situación de todas las minas.
R.1.1.6 Al destapar una casilla que no tiene mina se informa al jugador del número de minas qu
rodean la casilla destapada.
R.1.1.7 Cuando se destapa. una casilla que no tiene ninguna mina a su alrededor, automáticamem..-
también se destapan todas las casillas que la rodean. Este requisito se cumplirá. de form.
recursiva con las nuevas casillas destapadas.
R.1.1.8 Cuando se marca la presencia de una mina en una casilla se impide que dicha casilla pued:.
ser destapada mientras no se quite la marca.
R.1.1.9 A una casilla marcada se le puede quitar la marca
R.1.1.10 E l jugador consigue su objetivo cuando todas las casillas que no tienen mina han sid
destapadas. En este momento se para el cronómetro indicando el tiempo invenido.
R.1.2 En todo momento el jugador estará informado de los segundos transcurridos y de las mina:..
que todavía quedan por marcar del total de minas ocultas inicialmente.
R.1.3 El jugador en cualquier momento podrá cambiar el nivel de dificultad del juego entre 1
tres siguientes: bajo, medio y alto. Por defecto estará seleccionado el nivel medio. Este..
niveles representarán distintos tamaños del tablero y un número diferente de minas ocultas-
R.1.4 El jugador puede registrar el texto que quiera, junto al tiempo invertido, en la tabla de le
mejores resultados y dentro del nivel de dificultad en el que se realizó el juego.
R.1.5 E l jugador en cualquier momento podrá. finalizar el juego.
R.1.6 La tabla con los mejores resultados no se borrará nunca al apagar el computador.
R.1.7 Para reinicializar la tabla de resultados existirá una opción especial no accesible a. cua.lquir
jugador.
R.1.8 La situación inicial de las minas en el tablero será aleatoria y deberá dar lugar a un repar
aproximadamente uniforme en todo el tablero.
R.1.9 (Requisito deseable) Se dispondrá de una ayuda con las reglas del juego que podrá Sf'
consultada solamente antes de comenzar o al finalizar un juego.
R.1.10 El juego dispondrá de una ayuda simplificada que podrá ser consultada en cualquier m
mento y que explicará las teclas que se pueden utilizar durante el juego y la función
cada una
3.2 Requisitos de capacidad
R.2.1 Precisión del cronómetro s; 0.1 segundo
?.JE.\fPLOS DE ESPECIFIC.4.CIO~ES 99

R.2.2 Respuesta al pulsar una tecla ~ 0.1 segundo

R.2.3 Tiempo para situar inicialmente las minas ~ 1 segundo
3.3 Requisitos de interfase
R.3.1 Para la presentación del tablero Pn pantalla será necesario al menos disponer de una pan-
talla de tipo alfa.numérico.
3.4 Requisitos de operación Además de los indicados en el apartado de descripción del modelo
respecto a la estructura del tablero. casillas. etc.. se deberán cumplir los siguientes:
R.4.1 En todo momento y dentro del tablero deberá señalarse claramente la casilla en la. que está
situado el jugador.
R.4.2 Para moverse de una ca.silla a. otra. de las que la. rodean sólo será necesario pulsar una. tecla
una sola vez.
R.4.3 Para destapar. marcar o desmarcar una casilla sólo será necesario pulsar una tecla una
sola vez.
R.4.4 El cambio de nivel de dificultad se realizará de forma rotativa (bajo ➔ medio ➔ alto ➔
bajo) con sólo pulsar una tecla una sola "-ez· El cambio de nivel reiniciará. el nuevo tablero
de juego.
R.4.5 Para finalizar el juego o mostrac las ayudas del juego sólo será necesario pulsar una tecla
una vez.
3.5 Requisitos de recursos
R.5.1 Este sistema no requiere recursos especiales para su utilización y podrá. ser ejecutado en
cualquier instalación básica basada en un PC compatible con la configuración mínima
siguiente:
• CPU: 486 o posterior
• Memoria: 640 Kbytes o más
• Pantalla: cualquiera con modo texto de 80 x 25 caracteres
• Disquete: 31 2 pulgadas o 51/ 4 pulgadas
• No necesita disco duro
3.6 Requisitos de verificación
R.6.1 (Requisito deseable) Se dispondrá. de un modo auxiliar para depuración en el que el tablero
sera ''transparente'' y en el que el jugador conoce la situación de todas las minas a prior i.
3.7 Requisitos de pruebas de aceptación
~inguno.
3.8 Requisitos de documentation
R.8.1 El videojuego estará autodocumentado con las funciones de ayuda previstas
3.9 Requisitos de seguridad
R.9.1 (Requisito desea.ble) Se dispondrá. de algún mecanismo de protección contra. la copia in-
discriminada del programa.
3.10 Requisitos de transportabilidad
:'llinguno.
3.11 Requisitos de calidad
~o aplicable.
3.12 Requisitos de fiabilidad
No aplicable.
3.13 Requisitos de mantenibilidad
No aplicable.
3.14 Requisitos de salvaguarda
Ko aplicable.
100 ESPECIFICACIÓN DE REQUISITOS

3.7.2. Sistema de gestión de biblioteca

Se trata de informatizar la gcslión cif'l présran10 de libros en una biblioteca re-
lativamente pequeña, atendida por una sola persona. En esta biblioteca se pueden
consultar libros en la sala de lectura, sin ningún control especial, y también se pueden
sacar libros en préstamo, en forma controlada.

Para sacar libros en préstamo el usuario debe estar dado de alta en un registro de
lectores, en el que habrá una ficha por cada usuario, conteniendo sus datos personales.

Los libros estarán catalogados. Habrá un registro de libros con una ficha por ca-
da uno, conteniendo los datos fundamentales: título, autor , materias de que trata, etc.

Cuando un libro se saque en préstamo, se anotará en la ficha del libro a quién

está prestado. Un mismo lector puede tener a la vez varios libros en préstamo, hasta
un límite fijo. También hay un límite fijo para el número de días que se puede tener
prest ado un libro. Pasado ese plazo sin que se haya devuelto el libro, el bibliotecaric
avisará por teléfono al lector moroso para que realice la devolución.

El sistcn1a informático se usará también como ayuda para localizar los libros so-
licitados por los usuarios, permitiendo realizar búsquedas en el catálogo de libro:::.
bien por autor, título o materia.

A continuación se presenta un ejemplo de lo que podría ser el SRD de este sistema

recogiendo el análisis realizado con la metodología de ANALISIS ESTRUCTURA-
DO.
EIE~IPLOS DE ESPECIFIC.4.CIO,VES 101

DOCUMENTO DE REQUISITOS DEL SOFTWARE (SRD)

Proyecto: SISTEMA DE GESTIÓ~ DE BIBLIOTECA
Autores: :'11. COLLADO y J.F. ESTIVARIZ
Fecha: :\!layo 1999
Documento: BIBLIO-SRD-99
CO~TEJ\IDO
l. INTRODUCCIÓN
1.1. Objetivo
1.2. Arnbito
1.3. Definiciones, siglas y abreviaturas
1.4. Referencias
1.5. Panorámica del documento
2. DESCRIPCIÓJ\ GE:--rERAL
2.1. Relación con otros proyectos
2.2. Relación con proyectos anteriores y posteriores
2.3. Objetivo y funciones
2.4. Consideraciones de entorno
2.5. Relaciones con otros sistemas
2.6. Restricciones generales
2.7. Descripción del modelo
3. REQUISITOS ESPECÍFICOS
3.1. Requisitos funcionales
3.2. Requisitos de capacidad
3.3. Requisitos de interfase
3.4. Requisitos de operación
3.5. Requisitos de recursos
3.6. Requisitos de verificación
3.7. Requisitos de pruebas de aceptación
3.8. Requisitos de documentación
3.9. Requisitos de seguridad
3.10. Requisitos de transportabilida.d
3.11. Requisitos de calidad
3.12. Requisitos de fiabilidad
3.13. Requisitos de mantenibilidad
3.14. Requisitos de salvaguarda

1. IKTRODUCCIÓ:"i

1.1 Objeiivo
El objetivo del sistema. es facilit.ar la gestión de una biblioteca mediana o pequeña, en lo referente
a la atención directa a los usuarios. Esto incluye, funda.mentalmente, el préstamo de libros. así
corno la consulta bibliográfica.
102 ESPECIFICACIÓN DE REQUISITOS

1.2 Ambito
El s istema a desarrollar se denominará BIBLI0- 1. y consistirá en un único programa que reali-
zará todas las funciones necesarias. En panicular. deberá facilitar las siguientes:
• Gestión del préstamo y devolución de libros
• Consulta bibliográfica por título. autor o materia
El sistema no ha de soportar. sin embargo. la gestión económica de la biblioteca, ni el control
de adquisición de libros, ni otra8 funciones no relacionadas directamente con la atención a los
usuarios.
El sistema facilitará la atención al público por parte de un único bibliotecario, que podrá aten-
der a todas las funciones.

1.3 Definiciones, siglas y abreviaturas

~inguna.
1.4 Referencias

Ninguna.

1.5 Panorámica del documento

2. DESCRIPCIÓN GENERAL

2.1 Relación con otros proyectos

Ninguna.
2.2 Relación con proyectos anteriores y posteriores
Ninguna.

2.3 Objetivo y funciones

La biblioteca dispone de una colección de libros a disposición del público. Cualquier persoc..
puede consultar los libros en la sala de lectura, sin necesidad de realizar ningún registro de~
actividad.
Los libros pueden ser también sacados en préstamo por un p lazo limitado, fijado por la org::
nización de la biblioteca, y siempre el mismo. En este caso es necesario mantener anotados k;
libros prestados y qué lector los tiene en su poder. Para que un lector pueda sacar un libro e
préstamo debe disponer previamente de una ficha de lector con sus datos, y en particular con i=.
dicación de su teléfono, para facilitar la reclamación del libro en caso de demora en su devoluciá:.
Un lector puede tener a la vez varios libros en préstamo, hasta un máximo fijado por la o~
nización de la biblioteca, igual para todos los usuarios.
Los usuarios deben disponer de algunas facilid ades para localizar el libro que desean, tanto si
para consultarlos en la sala como si es para sacarlos en préstamo. Se considera razonable poc.
localizar un libro por su autor, su títu lo (o parte de él) o por la materia de que trata. Para
búsqueda por materias, existirá una lista de materias establecida p or el bibliotecario Cada li
podrá tratar de una o varias materias.
El objetivo del sistema es facilitar las funciones más directamente relacionadas con la aten -
directa a los usuarios de la bibliotec..a. Las funciones p ri ncipales serán:

• Anotar los préstamos y devoluciones

• Indicar los préstamos que hayan sobrepasado el plazo establecido
• Búsquedas por autor, título o materia
Como complemento serán necesarias otras funciones, en concreto:
• Ma.n~ener un registro <le los libros
• Mantener un registro de los usuarios (lectores)
2.4 Consideraciones de entorno
Ninguna.
2.5 Relaciones con olros sistemas
Ninguna..
EJE~fPLOS DE ESPECIFICACIO.l\ES 103

2.6 Restricciones generales

• El sistema se desarrollará y documentará empleando la metodología de análisis y diseño

estructurado.
• La implementación se hará sobre una base de datos relacional.
• El programa deberá poder ejecutarse en máquinas de poca capacidad y con sistemas ope-
rativos sencillos, sin sopone de multitarea, tal como itS-DOS en PCs.

2.7 Descripción del modelo

El sistema de gestión de biblioteca será operado por una sola persona. que dispondrá de un
terminal con pantalla y teclado. También existirá una impresora por la que podrán obtenerse
listados y fichas de los libros y de los lectores. Esta organización se refleja en el Diagrama de
Contexto que se muestra en la figura B.1

La operación del sistema se hará mediante un sistema de menús para seleccionar la operación
deseada, y con formularios en pantalla para la entrada y presentación de datos. Las funciones
a realizar se pueden organizar en varios grupos principales, tal como se indica en el diagrama
de flujo de datos de la figura 8.2. Estos grupos de funciones se describen a continuación. La
descripción precisa de cada función se incluye en la Sección 3: Requisitos Específicos.

2. 7 .1 Gestión de libros
Estas funciones permiten mantener actualizado el registro (fichero) de libros existentes en la
biblioteca.. El desglose de las mismas se refleja en el diagrama de flujo de datos de la figura B.3

Orden listados

Respuesta
Opel'ador Impresora

Datos Fichas

Figura Bl: DC. Diagrama de contexto

Orden

libros

LIBROS

LECTORES

Gestión
Orden
de

Orden
Ficha ele 'ector

F igura B2: DFD.O GE>:,-1:ión de la biblioteca

104 ESPECIFICACIÓN DE REQUISITOS

Orden Listado de libros

Orden

Ficha de libro

Figura B3: DFD.l Gestión de libros

Las funciones de gestión de libros son las siguientes:
Función l .1 Alta de libro: registra un nuevo libro
Función 1.2 Baja de libro: marca un libro como dado de baja
Función 1.3 Anular baja de libro: suprime la. marca de ba.ja
Función 1.4 Actualizar libro: modifica los da.tos del libro
Función 1.5 Listar libros: lista todos los libros registrados
Función 1.6 Compactar registro de Libros: elimina los libros dados de baja.
Función 1.7 Actualizar lista de materias: actualiza la lista de materias consideradas
2.7.2 Gestión de lectores
Estas funciones permiten mantener actualizado el registro (fichero) de usuarios (lectores) . El
desglose de las mismas se refleja en el diagrama de flujo de datos de la figura B.4

Orden L,stado de lectores

Anular
baja de
lector
Orden

-
Orden

F cha de l ector

Figura B4: DFD.2 Gestión de lectores

~LOS DE ESPECIFICA.CIONES 105

Las funciones de gestión de lectores son las siguientes:

Función 2.1 Alta de lector: registra un nuevo usuario (lector)

!<unción 2.2 Baja de lector: marca un lector como dado de baja
Función 2.3 Anular baja de lector: suprime la marca de baja
Función 2.4 Actualizar lector: modifica los datos del lector
Función 2.5 Listar lectores: lista todos los lectores registrados
Función 2.6 Compactar registro de lectores: elimina los lectores dados de baja
Función 2.7 Buscar lector: localiza un lector por nombre o apellido
2. 7 .3 Gestión de préstamos
Estas funciones permiten tener anotados los libros en préstamo, y conocer en un momento dado
los que han sido retenidos más tiempo del permitido. El desglose de las mismas se refleja en el
diagrama de flujo de datos de la figura B.5
Las funciones de gestión de préstamos son las siguientes:

Función 3.1 Anotar préstamo: anota los datos del préstamo

Función 3.2 AnotaJ' devolución: elimina. los datos del préstamo
Función 3.3 Lista de morosos: lista todos los préstamos no devueltos en el plazo fijado
Función 3.4 Préstamos de lector: lista los libros que tiene en préstamo un lector dado

Morosos

Prestamos de tec:tor

F igura B5: DFD .3 Gestión de préstamos

Figura B6: DFD.-1 Búsquedas

2.7.4 Búsquedas
Estas funciones permiten localizar libros por autor. título o materia. El desglose de las mismas
se refleja en el diagrama de flujo de datos de la figura B.6.
106 ESPECIFICACIÓN DE REQUISITOS

Las funciones de búsqueda. son las siguientes:

Función 4.1 Buscar p or aut or: localiza los libros de un autor dado
!:<unción 4.2 Buscar p or titulo: localiza los libros cuyo título contiene un texto dado
Función 4.3 Buscar por materia: locali2a los libros q ue t ratan de una materia dada
2. 7 .5 Modelo de datos
El diagrama Entidad-Relación correspondiente a los d at os principales del sistema se recoge en
la figura B. 7 El significado de cada elemento es el siguiente:

LECTOR

LIBRO

MATERIA

Figura B7: Nlodelo de datos del sistema

Entidad Libro: Contiene los datos de identificación del libro
Entidad Lector: Contiene los dat os personales del lector
Entidad Materia: Contiene el término clave que identifica la materia
Relación Prestado-a: Enlaza un libro con el lector que lo ha sacado en préstamo. Contiene
la fecha del préstamo
Relación Trata-de: Enlaza un libro con cada materia de la que trata
Las estructuras de datos principales se recogen en el diccionario de datos del cuadro B.8

DATO DESCRIPCIÓN
LECTORES FICHA DE LECTOR
LIBROS FICHA DE LIBRO
~1ATERIAS ~1ATERIA
FICHA-DE-LECTOR CÓDIGO-DE-LECTOR - DATOS-DE-LECTOR
FICHA-DE-LIBRO CÓDIGO-DE-LIBRO - DATOS-DE-LIBRO
+ DATOS-DE-PRÉSTAMO
MATERIA / l\ombre de la materia/
CÓDIGO-DE-LECTOR / l\ úmero del lector/
CÓDIGO-DE-LIBRO / :'.'>iúmcro del libro/
DATOS-DE-PRÉSTAMO FECHA + CÓDIGO-DE-LECTOR
DATOS-DE-LECTOR / Nombre, apellidos, D:t\"1, domicilio, teléfono, .. ¡
DATOS-DE-LIBRO / Autor. título, materias, .../
ORDEN / Datos de cada orden/
RESPUESTA / Respuesta. en pantalla/
LISTADO-DE-LIBROS LIBROS
LISTADO-DE-LECTORES LECTORES
MOROSOS FECHA - / Datos del libro/ + / Datos del lector/
PRÉSTAMOS-DE-LECTOR FECHA - / Datos del libro /

Cuadro B8: Diccionario de datos del sistema

3. REQUSJTOS ESPEC ÍFfCOS
3.1 Requisitos funcionales
Todos los requisitos ;;e considera11 obligatorios, sal vo que se indique Jo con t rario.
\IPLOS DE ESPECIFICACIOl'iES 107

3.1.1 Alrnacenamiento de datos

R.1.1 El sistema mantendrá almacenados en forma permanente al menos los datos indicados en
LIBROS, LECTORES y MATERIAS. en el Diccionario de Datos descrito en la Sección
2.7.5.
3.1.2 Funciones principales
R.1.2 El sistema realizará al menos las funciones que se describen a continuación, bajo petición
del operador.
3.l .2.1 Gestión de libros
Función 1.1 Alta de libro: registra un nuevo libro
Entrada: DATOS-DE-LIBRO
Salida: FICHA-DE-LIBRO
lisa:
Actualiza:L IBROS
Efecto: Compone una nueva ficha de libro asignando código automáticamente y leyendo
los datos del Libro por pantalla (las materias se seleccionarán de entre la lista de materias
registradas). Registra la ficha en el fichero de libros, y además la imprime.
Excepciones:

Función 1.2 Baja de libro: marca un libro como dado de baja

Entra.da. CÓDIGO-DE-LIBRO
Salida:
Usa:
Actualiza: LIBROS
Efecto: Lee el código del libro por pantalla, y marca la ficha de ese libro en el fichero de
libros como dada de baja.
Excepciones: Si no existe el libro con ese código, o ya estaba dado de baja, da un aYiso.

Función 1.3 Anular baja de libro: suprime la marca de baja

Entrada: CÓDIGO-DE-LIBRO
Salida:
{;sa:
Actualiza:
LIBROS Efecto: Lee el código del libro por pantalla, y anula la marca de dado de baja en
la ficha de ese libro en el fichero de libros.
Excepciones: Si no existe el libro con ese código, o no estaba dado de baja, da un aviso.
Función 1.4 Actualizar libro: modifica los datos del libro
Entrada: CÓDIGO-DE-LIBRO, DATOS-DE-LIBRO
Salida: FICHA-DE-LIBRO
Usa:
Actualiza: LIBROS
Efecto: Lee el código del libro por pantalla, localiza la ficha de ese libro, y actualiza los
datos de ese libro, también por pantalla (las materias se seleccionarán de entre la lista de
materias registradas) Registra la ficha actualizada en el fichero de libros, y la imprime.
Excepciones: Si no existe el libro con el código indicado, da un aviso.
Función 1.5 Listar libros: lista todos los libros registrados
Entrada:
Salida: LISTADO-DE-LIBROS
Usa: LIBROS
Actualiza.:
Efecto: Imprime un listado con todos los datos de todos los libros, incluso los que estén
dados de baja.
Excepciones:
Función 1.6 Compactar r<'gistro de libros: elimina los libros dados de baja
Entra.da:
Salida:
Usa:
Actualiza: LIBROS
Efecto: Suprime del fichero de li bros las fichas de libros que estén da.dos de baja, liberando
el espacio que ocupaban.
Excepciones:
108 ESPECIFICACIÓN DE REQUISITOS

F\rnción 1.7 Actualizar lista de materia.-;: actualiza la lista de materias consideradas

Entrada:
Salida:
Csa:
Actualiza: :\:IATERJAS
Efecto: Se edita por pantalla la lista de materias a considerar, pudiendo añadir, suprimir
materias, o modificar sus n()mbres.
Excepciones: Si se intenta suprimir una materia habiendo libros registrados que tratan de
ella, se pedirá confirmación especial. Si se fuerza la eliminación, se suprimirá también la
referencia a esa materia de los libros quP t,raten de ella.

3.1.2.2 Gestión de lectores

Función 2.1 Alta de lector: registra un nuevo usuario (lector)
Entrada: DATOS-DE-LECTOR
Salida: FICHA-DE-LECTOR
Usa:
Actualiza: LECTORES
Efecto: Compone una nueva ficha de lector asignando código automáticamente y leyendo
los datos del lector por pantalla. Registra la ficha en el fichero de lectores, y además la
imprime.
Excepciones:
Función 2.2 Baja de lector: marca un lector como dado de baja
Entrada: CÓDIGO-DE-LECTOR
Salida:
Usa:
Actualiza: LECTORES
Efecto: Lee el código del lector por pantalla, y marca la ficha de ese lector en el fichero de
lectores como dada de baja.
Excepciones: Si no existe el lector con el código indicado, o ya estaba dado de baja, da un
aviso.
Función 2.3 Anular baja de lector: suprime la marca de baja
Entrada: CÓDIGO-DE-LECTOR
Salida:
Csa:
Actualiza: LECTORES
Efecto: Lee el código del lector por pantalla, y suprime la marca de dado de baja. de la
ficha de ese lector en el fichero de lectores.
Excepciones: Si no existe el lector con el código indicado, o no estaba dado de ba.ja, da ur
a.viso.
Función 2.4 Actualizar lector: modifica los datos del lector
Entrada: CÓDIGO-DE-LECTOR, DATOS-DE-LECTOR
Salida.: FICHA-DE-LECTOR
t:sa:
Actualiza: LECTORES
Efecto: Lee el código del lector por pantalla, localiza la ficha de ese lector y actualiza lo,
datos de ese lector, también por pantalla. Registra la ficha actualizada en el fichero de
lectores, y la imprime.
Excepciones: Si no existe el lector con el código indicado, da un aviso.
Punción 2.5 Listar lectores: lista todos los lectores registrados
Entrada-Salida: LISTADO-DE-LECTORES
Csa: LECTORES
Aciualiza:
Efecto: Imprime un listado con todos los datos de todos los lectores, incluso los que PStei..
dados de baja.
Exct>pcione!;:
Función 2.6 Compactar registro de lectorPs: elimina los lectores dados de baja
Entrada:
Salida:
Usa:
Actmiliza: LJ::CTORE:5
 ::\IPLOS DE ESPECIFICA.CIONES 109

Efecto: Suprime del fichero de lectores las fichas de lectores que estén dados de baja,
liberando el espacio que ocupaban.
Excepciones:
Función 2. 7 Buscar lector: localiza un lector por nombre o apellido
r Entrada: NOMBRE-O-APELLIDO
Salida: FICHA-DE-LECTOR
L"sa: LECTORES
Actualiza:
Efecto: Presenta en pantalla un listado con los datos de cada lector que contenga el nombre
o apellido indicado.
Excepciones:
3.1.2.3 Gestión de préstamos
Función 3.1 Anotar préstamo: anota. los da.tos del préstamo
Entrada.: CÓDIGO-DE-LIBRO, CÓDIGO-DE-LECTOR
Salida.:
Usa: LECTORES
Actualiza: LIBROS
Efecto: Lee por pantalla los códigos del libro y del lector. Anota en la ficha del libro los
datos del préstamo: código del lector y la fecha del día, tomada del reloj del sistema..
Actualiza. la ficha. en el fichero de libros.
Excepciones: Si no existe el libro o el lector, o el libro ya estaba prestado. o el lector tiene
ya el máximo de libros en préstamo, da un aviso.
Función 3.2 Anotar devolución: elimina los da.tos del préstamo
Entrada: CÓDIGO-DE-LIBRO
Salida:
Usa: LECTORES
Actualiza.: LIBROS
Efecto: Lee por pantalla el código del libro, y elimina. los datos de préstamo de su ficha.
Actualiza esa ficha en el fichero de libros.
Excepciones: Si el libro no existe. o no está presta.do, da un aviso.
Función 3.3 Lista de morosos: lista todos los préstamos no devueltos en el plazo fijado
Entrada:
Salida: MOROSOS
Usa: LIBROS, LECTORES
Actualiza:
Efecto: Imprime un listado con los datos de libros y lectores de todos los préstamos para
los que el plazo desde que se realizaron hasta hoy sea superior el plazo límite establecido.
Excepciones:
Función 3.4 Préstamos de lector: lista los libros que tiene en préstamo un lector dado
Entrada: CÓDIGO-DE-LECTOR
Salida: PRÉSTAMOS-DE-LECTOR
Usa: LIBROS, LECTORES
Actualiza:
Efecto: Presenta en pantalla un listado con los datos abreviados de cada libro que tenga
en préstamo ese lector, y la fecha de cada préstamo.
Excepciones: Si el lector no existe, da u11 aviso.
3.1.2.4 Búsquedas
Función 4.1 Buscar por autor: localiza los libros de un autor dado
Entrada: NOMBRE-O-APELLIDO
Salida: FICHA-DE-LIBRO
l;sa: LIBROS
Actualiza:
Efecto: Presenta en pantalla un listado con los datos de cada libro cuyo autor contenga el
nombre o apellido indicado.
Excepciones:
Función 4.2 Buscar por título: localiza los libros cuyo título contiene un texto dado
Entrada- TEXTO
Salida: FICHA-DE-LIBRO
110 ESPECIFICACIÓN DE REQUISITOS

l:sa: LIBROS
Act ualiza.:Efecto Presenta en pantalla un listad o con los da.t os de cada libro cuyo título
contenga el t exto indicado.
Exce pcio nes :
Función 4.3 Buscar po r materia: localiza. los libros que tra.tan de una materia. dada
Entra.da: MAT ERI A
Salida: FICHA- DE-LIBRO
Usa: LIBROS
Actualiza:
Efecto: Presenta en pant alla la list a de materias y permite seleccionar la materia. objeto
de la búsqueda. Presenta. en pantalla un lista.do con los datos de cada libro que trate de la
materia indicada.
Excepciones:

3.2 Requisitos de capacidad

R.2.1 El software debe soportar al menos 9 .000 libros, 9.000 lectores y 250 materias.
R.2.2 No obstante Jo anterior, la capacidad de almacenamiento puede estar limitada por la ca-
pacidad del hardwc1.re de ca.da instalación.
R.2.3 La ejecución de cualquiera de las funciones principales (excepto listados) deberá durar 5
segundos, como máximo, en un PC con procesador 80486. Esto incluye las búsquedas con
registros de 9000 libros o lectores. El tiempo puede ser proporcionalmente mayor con re-
gistros de mayor capacidad.
R.2.4 En el caso de los listados, el límite anterior se incrementará. en el tiempo físico de impresión .
dependiente de la impresora.
3.3 Requisitos de interfase
No aplicable.
3.4 Requisitos de operación

R.4.1 La selección de una función se hará mediante un sistema de menús

R.4.1.1 (Deseable) La selección de una función principal no debería exigir má.s de dos niveles d e
menú
R.4.2 Los códigos de libro y lector deberán ser fáciles de teclear, exigiendo pocas pulsaciones.
R.4.3 (Deseable) Sobre un libro o lector seleccionado mediante una función se podrá invoca.r otra
sin necesidad de volver a seleccionar manualmente dicho libro o lector.
R.4.4 (Deseable) La función de actualizar la lista de materias debería ser accesible desde las de
alta de libro y actualizar libro.
R.4.5 El sistema podrá configurarse para que el programa entre en funcionamiento automática-
mente al arrancar el equipo.
R.4.6 Existirá la posibilidad de sacar y restablecer copias de seguridad (backups). Para ell,
bastará que se puedan salvar y rest aurar los ficheros con los registros permanentes de.
sistema.
R.4.7 En las funciones que actualizan los registros permanentes, se pedirá confirmación antes d
hacerlo, presentando los dat os que se van a actualizar.
R.4.8 Al arrancar la aplicación (o durante la operación) , se podrán modificar los límites de pré'--
tamo, tanto el plazo como el número de libros para un mismo lector.

3.5 Requisitos de recursos

R.5.1 El programa deberá pode r ejec u t arse en equipos tipo PC (o similares) de gama baja. co
la configuración m ínima equivalente a la siguiente:
• CPl:: 486 o posterior
• Memoria: 640 K b
• Pantalla: alfanumé rica 80 x 25 caracteres
• Disquete : 31/ 2"720K b o 51; 4" 1,2:Mb, para backup
• Disco fijo : con capacidad para los programas y los registros permanentes
3.6 R equis itos de verificación

R.6.1 (Deseable) De ber á d isponerse de un sistema d e acceso a. los registros d e libros, lec tore--
materias, ind ep endiente de la aplicación, y q ue permita examinar su contenido, preferib
m ente o bteniendo un listado del mismo, para comprobar que la información almacen~
es la correcta.
 XCLUSIONES 111

3. 7 Requisitos de pruebas de aceptación

R. 7.1 Se deben probar al menos una vez todas y cada una de las funciones, tanto con entradas
normales como con datos que provoquen errores, en su caso.
3.8 Requisitos de documentación
R.8.1 Exist.irá un manual de operación. sencillo. q111> descriha el uso del sist.ema.
R.8.2 (Deseable) Un resumen del manual de operación estará disponible como ayuda en linea,
durante la operación del sistema.

3.9 Requisitos de seguridad

R.9.1 (Deseable) La compactación de los registros sólo debería realizarse si previamente se ha

sacado una copia de "backup"de los mismos.
R.9.2 Aunque se llene el disco fijo y no se puedan registrar nuevos libros, lectores, materias o
préstamos, no deberá perderse información anterior de los registros permanentes.
3.1 O Requisito,; de transponabilidad
R.10.1 (Deseable) El programa se codificará en un lenguaje de programación de alto nivel, para
el que exista una. definición normalizada.
3.11 Requisitos de calidad Ninguno en especial.
3.12 Requisitos de fiabilidad :'.'ilinguno en especial.
3.13 Requisitos de mantenibilidad Ninguno en e:;pecial.
3.14 Requisitos de salvaguarda :Ninguno en especial.

3.8. Conclusiones
A lo largo este capítulo se ha descrito la labor de análisis y definición de los re-
uisitos que ha de cumplir un proyecto de software. Esta labor no es exclusiva de la
roducción del software. Cualquier actividad productiva que tenga como objetivo la
c-eación de un sistema complejo debe pasar por esta fase.

El cliente. el mercado y la propia empresa requieren un sistema nuevo que debe

i-,Cr descrito de manera precisa y específica. Eso es la especificación del sistema. La
relación detallada de todas las características del nuevo sistema debe hacerse de ma-
nera rigurosa. no sólo teniendo en cuenta lo que ha encargado el cliente. sino también
todo lo necesario para que lo encargado funcione correcta y legalmente. Esta labor
debe dar lugar a la especificación de software. en la que se concretan las necesidades
que se desean cubrir y se fijan las restricciones con las que debe trabajar e] software
.. desarrollar. El análisis de lo especificado también se realiza dentro de esta prime-
ra fase {fase de definición) del ciclo de vida y tiene una importancia decisiva para
l·onseguir que el sistema que se construya finalmente sea realmente el que se deseaba.

Una partf' fundamental de este capítulo c>s la dedicada a las diferentes notaciones
empleadas para redactar de manera precisa las particularidades del sistema a de...,a-
rrollar.

Para concluir se ha elaborado, a modo ele cjf'mplo, un documento de requisitos

de un sistema software.
112 ESPECIFICACIÓN DE REQUISITOS

3.9. Ejercicios propuestos

l. Elabórese una lista de 5 requisitos funcionales y 5 no funcionales de tres posibles
sistemas de software.
2. Realícese una descripción cu lenguaje natural, diagrama de flujo de datos y
diagrama de estados de los siguientes sistemas:
■ U na puerta manual
■ Una puerta automática con detector de presencia
• -C-n ascensor con dos pisos
3. Elabórese un plan para la captura, validación y verificación de los requisitos de
un proyecto.
4. Búsquese una herramienta de gestión de requisitos. Analícese sus funcionalida-
des, ventajas, inconvenientes, incluso su precio si fuera posible.
5. Elabórese el SRD de la práctica de fundamentos de programación que realizó el
curso pasado. Detállense los diagrarnas necesarios para su completa especifica-
ción. ¿Con qué argumentos se podría convencer al cliente de que se ha cumplido
con lo que se encargó?
r

apítulo 4

undamentos del Diseño de

~oftware

.l . Introducción

Con este capítulo se inicia el estudio de las etapas de desarrollo. Después de haber
~ecificado QUÉ se quiere resolver durante la especificación, las etapas de desarrollo
dedican a determinar CÓNIO se debe resolver el proyecto. La primera de estas
·apas es la de diseño, se continúa con la de codificación y se finaliza con las etapas
pruebas del software realizado. Toda esta segunda unidad didáctica está dedicada
la etapa de diseño. Concretamente, en este capítulo se abordan los fundamentos
e la etapa de diseño.

-!.2. Objetivos

Primeramente se concreta qué se entiende por diseño y se analizan las activida-

es que se deben realizar para llevarlo a cabo. A continuación se introducen algunos
xmceptos fundamentales que deben tenerse en cuenta para realizar cualquier diseño.
:ieguidamente se describen distintas notaciones que se pueden emplear para la des-
-ripción de un diseño softw,e. Algunas de estas notaciones son versiones ampliadas
ie las ya estudiadas para la especificación y otras son totalmente exclusivas para el
liseño. Finalmente, se proponen unos formatos concretos para la elaboración de los
iocumentos del diseño arquitectónico y del diseño detallado en los que se recogen
·odos los resultados del diseño.

113
114 F(;·:,,.-v_.t;\ lESTOS DEL DISESro DE SOFTWARE

4.3. ¿Qué es el d iseño?

Si consultamos el diccionario., encontramos la sio-
o~iente definición:
11
1
D iseño. (del italiano disegno) ... 2. Descripción o bosquejo de alguna cosa, hecho
1

por palabras.
Lo que trasladado al contexto del diseño de sistemas software sería la descripción
o bosquejo del sistema a desarrollar. En nuestro caso, la descripción se puede y se
debe hacer mediante otras notaciones más formales y no sólo empleando palabras
Se trata, por tanto, de definir y formalizar la estructura del sistema con el suficiente
detalle como para permitir su realización física. Cualquier producto que se crea en la
ingeniería se describe de manera precisa para su producción mediante la redacción de
los planos de su diseño. Estos planos del diseño permiten la comunicación del mismc
a todas las partes implicadas en la producción del bien.

La elaboración del diseño permite, además, una clasificación del producto d

acuerdo a las características que se plasmen en el documento resultante. Una ten-
dencia bastante utilizada, y que se estudiará en profundidad en futuras asignatur~
es la elaboración del diseño de una aplicación de acuerdo con unas pautas previa-
mente establecidas. Es lo que se conoce como diseño con patrones de software.

El punto de partida principal para abordar el diseño es el documento de espec-

ficación de requisitos (SRD). La realización del diseño de un sistema es un proce-
creativo que no es nada trivial y que casi siempre se lleva a cabo de una forma it -
rativa mediante prueba y error. En este proceso es muy importante la experienc.
previa y siempre que sea posible se tratará de reutilizar el mayor número de módul
o elementos ya desarrollados. Cuando esto último no sea posible, por tratarse d
diseño de un sistema completamente original y sin ningún antecedente previo.
seguro que para comenzar el diseño, al menos se podrá aprovechar el enfoque dadc
algún otro proyecto anterior, lo que se conoce como aprovechar el know-how (sab
hacer). Después, en sucesivas iteraciones, se perfilará el enfoque más adecuado pa.:
el nuevo diseño. Esta forma de trabajo es la misma que se utiliza para diseñar nue,
coches, aviones, edificios, puentes o cualquier otra obra de ingeniería. Está claro <r
los expertos en la construcción de aviones son más adecuados para diseñar uno nue
que los encargados de diseñar puentes.

En el próximo capítulo se estudiarán ciertas técnicas de carácter general

abordar el diseño de cualquier sistema. Desgraciadamente, estas técnicas son err;.
ricas y no están suficientemente formalizadas como para que se puedan realizar
una manera automática. Para cierto tipo de aplicaciones sencillas o muy específi
(nóminas, cáJculos científicos. control de stocks. etc.) existen herramientas tales ce
lenguajes de cuarta generación. hojas de cálculo, paquetes de cálculo científico. e·
 115

~
simplifican mucho la labor de diseño y codificación, pero esto no es la situación
· ral. En los restantes casos, la aplicación de las técnicas no es tan sistemática y
0

:nuy importante la habilidad del diseñador.

El método más eficaz para adquirir experiencia en el diseño es participar en al-

de ellos y aprender de los otros diseñadores sus técnicas de trabajo. También es
nsejable estudiar diseños ya realizados y analizar pormenorizadamente las razones
r las que se adopta una u otra solución. Estas razones normalmente no se suelen
_licar en los libros, ya que dependen de cada caso concreto y de las preferencias
::ada diseñador, lo que hace muy difícil establecer alguna regla general. Por tanto,
:nuy complicado aprender a diseñar exclusivamente leyendo libros.

En los desarrollos de sistemas software de los años 60, el objetivo del diseño era
.;..seguir la mayor eficiencia posible, dado que la memoria de los computadores era
-asa y su potencia de cálculo no muy grande. Actualmente y debido al tremen-
aumento de los costos de desarrollo, el objetivo fundamental es conseguir que el
.::ware sea fácil de mantener y si es posible que se pueda reutilizai· en futuras apli-
:iones. Para conseguir ambos objetivos, la etapa de diseño es la más importante
evia- la fase de desarrollo de software.

Durante la etapa de diseño se tiene que pasar de una forma gradual del QUÉ
peci- be hacer el sistema, según se detalla en el documento de requisitos, al CÓMO
debe hacer, estableciendo la organización y estructura física del software. En es-
transformación gradual no siempre está claramente determinado dónde acaba el
.:iálisis y dónde empieza el diseño propiamente dicho. En algunos casos se llega a
nsiderar que los requisitos forman parte del diseño externo o funcional del sistema.
: ,, cualquier manera, durante el diseño se tiene que pasar de las ideas informales re-
gidas en el SRD a definiciones detalladas y precisas paia la realización del software
2diante refinamientos sucesivos.

A lo largo del proceso de diseño se realiza ui:1 conjunto de actividades. Estas acti-
.-tlades tienen como objetivo sistematizar cada uno de los aspectos o elementos de la
-uuctura del sistema. Aunque no existe consenso ni en el número ni en la denomi-
:..ación de las actividades, con ellas se persigue un refinamiento progresivo del diseño .
...,epcndiendo de la complejidad del sistema a diseñar algunas de las activídades que-
..arán e;°globadas dentro de otras o simplemente desaparecerán. A continuación se
:=iumeran y describen actividades habituales en el diseño de un sistema:

1. DISEÑ<) ARQUITECTÓNICO: Ésta es la primera actividad a realizar

icas - en ella se deben abordar los aspectos estructurales y de organización del sistema
)ffiO su posible división en subsistemas o módulos. Además, se tienen que establecer
~te.. .i.s relaciones entre los subsistemac, creados y definir las interfases entre ellos. Esta
116 Fl/SD.-LHE.VTOS DEL DISENO DE SOFTlV.ARE

actividad proporcionará una Yisión global del sistema y por tanto resulta esencial
para poder avanzar en las acti,·idades siguientes . Por ejemplo, para el sistema de
control de acceso del tema ant erior. no t ien e ningún sentido abordar el diseño de la
visualización de mensajes sin tener absolutament e establecidos todos los módulos del
sistema, los tipos de mensajes posibles que cada uno necesitará, la interfase con la
que se interrelacionarán los distintos módulos. etc.

2. DISEÑO DETALLADO: Con esta actividad se aborda la organización de:

los módulos. Se trata de determinar cuál es la estructura más adecuada para cada
uno de los módulos en los que quedó subdividido el sistema global. Simplificando
podemos decir que si se utilizara el lenguaje l\11odula-2 como notación de diseño est..
act ividad sería la encargada de la elaboración de los módulos de definición para cad
uno de los módulos del programa global. Así , estos módulos de definición serían e
resultado fundamental de esta actividad.

También como resultado del diseño detallado, aparecen nuevos módulos que .
deben incorporar al diseño global, componentes que es razonable agrupar en un ún.
co módulo, o módulos que desaparecen por estar vacíos de contenido. Esto refleja 1
interrelación entre el diseño arquitectónico y el detallado a pesar de que pudiera.
parecer actividades puramente secuenciales. Cuando se trata de diseñar sistemas r:
muy complejos, el diseño detallado no existe como tal actividad y es simplemente lL
refinamiento del diseño arquitectónico.

3. DISEÑO PROCEDIMENTAL: Esta actividad es la encargada de abordz..

la organización de las operaciones o servicios que ofrecerá cada uno de los módulc -
Siguiendo con la simplificación anterior del empleo de i\!Iodula-2, en esta activid
se diseñan los algoritmos que se emplean en el desarrollo de los módulos de imp·
mentación para los procedimientos más importantes de cada uno de los módulos ¿
sist ema. Korrnalmente, en esta actividad se detallan en pseudocódigo o PDL so-
mente los aspectos más relevantes de cada algoritmo (ver la sección 3.5.4 del capíh..
3). Posteriormente en la etapa de codificación se dará forma definitiva a los algor
rnos.

4. DISEÑO DE DATOS: En esta actividad se aborda la organización de

base de datos del sistema y se puede realizar en paralelo con el diseño detallad_
procedimental. El punto de partida para esta actividad es el diccionario de da
y los diagramas E-R de la especificación del sistema. Con esta actividad se t
de concret ar el formato exacto para cada dato y la organización que debe exb
entre ellos. El diseño de datos es de una gran importancia para conseguir el objet
de que el sist ema sea reut ilizable y fáci lmente mantenible. Sin embargo; una paz
muy importante de est a actividad se suele realizar en el momento que se elabora
especificación de requisitos del sistema.
 -cEPTOS DE BASE 117

5. DISEÑO D E LA IN T E RFA Z DE USUARIO: En cualquier aplicación

·are, cada día resulta más importante el esfuerzo de diseño destinado a conseguir
.liálogo más ergonómico entre el usuario y el computador. Por ejemplo, la facili-
de aprendizaje y manejo de una aplicación aumenta considerablemente cuando
_ interfaz de usuario se emplean ventanas desplegables y ratón en lugar de menús
"'Ciado precisamente esta actividad es la encargada de la organización de la
erfaz de usuario. La importancia de esta actividad ha propiciado el desarrollo
ecoicas y herramientas específicas que facilitan mucho el diseño. Sin embargo,
ii conseguir una buena interfaz de usuario hay que tener en cuenta incluso factores

ológicos.

El resultado ele todas estas actividades de diseño debe dar lugar a una especifi-
:!>n lo más formal posible de la estructura global del sistema y de cada uno de
P}ementos del mismo. Esto constituye el "producto del diseño" y se recogerá en
Documento de Diseño de Software (en inglés SDD: Software Design Document. o
bién Software Design Description). Si la complejidad del sistema así lo aconseja:
podrán utilizar varios documentos para describir de forma jerarquizada la estruc-
- global del sistema, la estructura de los elementos en un primer nivel de detalle
en los sucesivos niveles de detalle, hasta alcanzar el nivel de codificación con los
ados de los programas.

Las normas ESA establecen un Documento de Diseño Arquitectónico (ADD: Ar-

+ectural Design Document) y un Documento de Diseño Detallado (DDD: Detailed
-ign Document) al que se pueden añadir como apéndices los listados de los pro-
..mas una vez completado el desarrollo. El formato de estos documentos será el
~to del último apartado de este mismo capítulo.

Conceptos de base
La experiencia acumulada a lo largo de los años por los diseñadores de sistemas
fr"'·are ha permitido identificar una serie de conceptos o características de los sis-
!'!llas y sus estructuras que tienen especial influencia en la calidad de un diseño de

~ruchos de estos conceptos aparecen en un campo bastante amplio de la actividad

desarrollo de soft,vare, y su utilidad no se limita exclusivamente a la tarea de
.;;eño. Algunos de ellos se pueden aplicar de manera natural en el análisis e incluso
otro tipo de actividades dentro y fuera del ámbito del desarrollo de sistemas
[tware. Todas las técnicas que sr estudiarán en el próximo capítulo están basadas
uno o varios de los conceptos que aquí se recogen.
118 Fl.:XD.-L\IESTOS DEL DISEÑO DE SOFTH¼RE co1,

La aplicación particular de determinadas técnicas da lugar a metodologías especi- E

ficas, que podrán cambiar o mejorar en el futuro. Sin embargo, los conceptos de ba~
permanecen y se seguirán utilizando probablemente sin grandes variaciones. Lamen-
tablemente, los conceptos por sí mismos no constituyen una técnica o metodologí.
de diseño. La importancia relativa de cada concepto en las diferentes técnicas d
diseño varía según la opinión o preferencias personales de los distintos expertos .. El
continuación se recoge una lista bastante amplia de los conceptos más interesantes
tener en cuenta en cualquier diseño.

os
4.4.1. Abstracción
Este concepto siempre resulta muy "abstracto" para los estudiantes. Con objer
de definirlo de manera precisa se irá al diccionario de la Real Academia de la Len
l. adj. Que significa alguna cualidad con exclusión del sujeto.
2. adj. Dicho del arte o de un artista: Que no pretende representar seres o co
concretos y atiende solo a elementos de forma, color, estructura, proporción, etc.
Si se consulta por la etimología (ETIJVICHIL) de la palabra quizás se encuem:.;
más luz.

La palabra abstracto viene del latín abstractus, compuesto del prefijo abs (se¡;
ración, privación) y tractus. Éste es el participio del verbo trahere, que da palab:r
como trecho y tractor. Etimológicamente sería algo como "sin trecho", pero se apL
para referirse a cualidades o elementos que no son específicos. Por ejemplo: belle
libertad, justicia, etc. El antónimo de abstracto es concreto. en

Abstracto quiere decir etimológicamente "arrastrado o sacado a partir de su~

mi tes externos". Abs-í ab- significa alejamiento a partir del límite exterior de a:
Es por eso que una abstracción o algo abstracto es cualquier cosa que partiendo
la apariencia externa de una realidad, se aleja de ella.

Para ilustrar el concepto se presenta un ejemplo "concreto". Supóngase un e

o naipe de una baraja española, "El dos de oros". La carta en sí no es más que
pedazo de cartón con un dibujo y unos números en una de las dos caras del car
la otra no tiene dibujo. Esta descripción es el objeto concreto. Sin embargo
conoce el concepto de baraja de cartas y las funciones que tiene, se puede saber
el cartón representa algo más que lo descrito. La carta forma parte de una colee-
de elementos que están clasificados y también ordenados, tienen un valor impli
dentro de una escala establecida. También forma parte de un conjunto limitad
\fialores. Es una carta de la baraja española. Este es el concepto abstracto que se -
de sus límites físicos.
 119

mismo caso se da con una tarjeta de crédito. Su presencia física es un rectán-

Je plástico con una banda magnética y unos datos grabados en su superficie.
embargo, el conceptp que abarca es un medio de pago universalmente aceptado,
nnos límites máximos, una fecha de caducidad, etc.

El concepto de abstracción se utiliza en un gran número de actividades humanas.

ejemplo, en el lenguaje con el que nos comunicamos se utilizan esencialmente
conjunto amplio de abstracciones a las que se referiren a través de las palabras.
nueva palabra sirve para referirse a un nuevo concepto abstracto aceptado por
- sin necesidad de aclarar cada vez su significado.

Cna abstracción, en el diseño de un sistema software, será cualquier elemento

forme parte del sistema que se quiere modelar, con la suficiente entidad o im-
ancia para distinguirlo del resto y que esté dotado de funciones relevantes para
sstema. Cuando se identifiquen esos elementos "importantes" deberá hacerse te-
do en cuenta no sólo su forma "concreta" sino también todo lo que lo rodea y
permite distinguirlo corno un elemento importante.

Cuando se diseña un nuevo sistema software es importante identificar los elemen-

~ realmente significativos de los que consta y además, abstraer la utilidad específica
~ada uno, incluso más allá del sistema software para el que se está diseñando. Es-
?Sfuerzo dará como resultado que el elemento diseñado podrá ser sustituido en el
::uro por otro con mejores prestaciones y también podrá ser reutilizado en otros
:>yectos similares. Estos son dos de los principales objetivos del diseño: conseguir
mentos fácilmente mantenibles y reutilizables.

En el ejemplo del control de acceso planteado en el capítulo anterior, la tarjeta

acceso sería una abstracción. Tiene una clave, se debe leer en sistema, se pue-
cambiar su clave, etc. Cuantas más características contemplemos mayor grado de
-tracción conseguiremos. Otra abstracción podría ser la pantalla, y otra el teclado.

Durante el proceso de diseño se debe aplicar el concepto de abstracción en todos

- niveles de diseño. Tomando corno ejemplo el sistema para el control de acceso
nunciado en el capítulo anterior, en un primer nivel aparecen abstracciones tales
:orno: Tarjeta, :Nicnsajes, Órdenes, etc.

Inicialmente, todos ellos son ele1nentos abstractos y su diseño se puede realizar sin
Pner en cuenta al sistema de control de acceso concreto en el que se utilizarán. Esto
:'.'.acilitará los cambios futuros y la posibilidad de reutilizarlos en diversos sistemas.
En un segundo nivel aparecen nuevas abstracciones como: Clave, Control de Puerta,
~omprobar Clave, etc. a los que se aplicarán los mismos criterios.
120 FUNDA_\IESTOS DEL DISEÑO DE SOFTlV.4.RE

Este proceso de abstracción se puede y se debe continuar con cada elemento soft-
ware que tengamos que diseñar. El mismo procedimiento es el que se utiliza para
diseñar un coche, un avión, una casa. etc. Inicialmente tenemos como elementos abs-
tractos el motor, el chasis, las ruedas, etc. y para diseñar estos elementos a su vez
necesitamos filtros, bujías, correas, etc. que si se diseñan convenientemente se podrác
utilizar en cualquier modelo de coche. ·

U na buena fuente de abstracciones aplicables al diseño proviene del análisis deJ

dominio del sistema. Como ya se comentó en el capítulo anterior.

En el diseño de los elementos software se pueden utilizar fundamentalmente tre-

formas de abstracción:
■ Abstracciones funcionales
■ Tipos abstractos
■ 1'1áquinas abstractas
Como se explica en el libro de Fundamentos de Progran1ación (Cerrada00], un.
abstracción funcional sirve para crear expresiones parametrizadas o acciones par
metrizadas mediante el empleo de funciones o procedimientos. Para diseñar un.
abstracción funcional es necesario fijar los parámetros o argumentos que se le deb
pasar, el resultado que devolverá. en el caso de una expresión parametrizada, lo q
se pretende que resuelva y como lo debe resolver (el algoritmo que se debe emplear
Por ejemplo, se puede diseñar una abstracción funcional para Comprobar Clave cu:
parámetro es la clave a comprobar y que devuelva como resultado si/no la clave
correcta.

En cuanto a los tipos abstractos, estos sirven para crear los nuevos tipos de da.-
que se necesitan para abordar el diseño del sistema. Por ejemplo, un tipo Tarjeta
ra guardar toda la información relacionada con la tarjeta utilizada: clase de tarje'
identificador, clave de acceso, datos personales, etc. Además , junto al nuevo tipo
dato se deben diseñar todos los métodos u operaciones que se pueden realizar con
Por ejemplo, Leer Tarjeta, Grabar Tarjeta, Comprobar Tarjeta, etc.

Una rnáquina abstracta permite establecer un nivel de abstracción superior a .

dos anteriores y en él se define de una manera formal el comportamiento de
máquina. 'Cn ejernplo de este tipo de abstracción sería un intérprete de órdenes S
(Standard Query Language) para la gestión de una base de datos. El lenguaje S
establece formalmente el comportamiento perfectamente definido para la máq
abstracta encargada de manejar la base de datos: construcción, búsqueda e inserc
de elementos en la base de datos. Otro ejemplo clásico de máquina abstracta p.;.
definición de un protocolo de comunicaciones en el que se establecen los posible:,
tados (espera, envío, recepción. inacti,·o ..... ), las transiciones entre ellos, los tip~
 121

jes, etc. que configuran la máquina abstracta romo un autómata. También, el

a de control de acceso utilizado como ejemplo i:;r puede ver corno u na máquina
..eta si se consigue formalizar todo su comportamiento. En todos estos casos el
- consiste en definir formalmente la máquina abstracta que se necesita.

Modularidad
s
Casi siempre los proyectos requieren el trabajo simultáneo y C'oordinado de varias
nas. Una forma clásica de conseguir la coordinación es mediante el empleo de
..useño modular. Uno de los primeros pasos que intuitivamente parece claro que
"'be dar al abordar un diseño es <lividfr el sistema en sus correspond ientes mó-
. . o partes claramente diferenciadas. E sta división permite encargar a personas
enles el desarrollo de ,cada módulo y que todas ellas puedan trabajar simul-
•amente. Sin embargo, para conseguir la adecuada coordinación, la. división en
¿ulos no resulta trivial y además es necesario que las interfases entre todos ellos
len completamente definidas y correctamente diseñadas. En el próximo capítu-
estudiará la técnica df' descomposición modular que permite logrn,r l:'ste objc•tivo.

Además de posibilitar la división del trabajo, las ventajas de utilizar un diseño

.Jular son de todo tipo:

• CLAIUDAD: Siempre es más fácil de entender y manejar cada una <le las partes
o módulos de un sistema que tratar d e entenderlo como un todo compacto.
• REDCCCIÓ::'-J DE COSTOS: Resulta más barato desarrollar, df'purar, docu-
mentar, probar y mantener un sistema modular que otro que no lo es. Hay que
1.tc.
tener en cuenta que sj el número de módulos crece innecesariamente esta afir-
péi
mación puede no ser correcta. Cuando hay demasiados módulos se aumentan
eta
también las relaciones entre ellos y las interfases necesarias.
d
él • REUTILIZACIÓK: Si los módulos se diseñan teniendo en C'uenta otras posibles
aplicaciones resultará inmediata su reutilización.
El concepto de modularidad se debe aplicar en f'l diseño de cualquier sistC'ma, incluso
lo., n aquellos para los que existan limitaciones de tiempo o memoria quf' impidan que
1na 11 su codifiración se puedan emplear móduloH compilados por separado. Por ejemplo,
QL ,1 ciertas operaciones son críticas y se deben realizar en un tiempo muy corto, no
QL ,,, pueden empleas subrutinas con las que se gastaría un tiempo precioso en cada
ma !amada. En este caso se pueden emplear macros para sustituir a las suhrntinaH siu
ór. 1u<' esto afecte para nada al diseño.
la
es- La modularidad es un concepto <le diseño que no drbe estar ligado a la etapa de
de ·odificación y mucho menos al empleo de un d<'lcrminado lenguajf' de programación.
122 FUSD...L\IESTOS DEL DISEÑO DE SOFT\.VA.RE REFl

Sin embargo, históricamente se ha asociado el concepto de módulo a determinadas ::unci

estructuras de los lenguajes de prograrnación. En lenguajes como FORTRAN, Pas-
cal, etc. un módulo sólo se puede asociar a una subrutina, procedimiento o función.
Estas estructuras resultan insuficientes cuando se quiere conseguir que cada miem- E
bro del equipo de trabajo pueda desarrollar su actividad por separado y de forma
coordinada y tampoco permiten agrupar en una misma entidad sólo datos o datos
y las operaciones que los manejan. Otros lenguajes posteriores sí que están dotados
de estructuras específicas para estos fines. Los package de ADA o los l\.1ODvLE de
i\Iodula-2 son los ejemplos más claros. La ventaja que supone la utilización de esto~
últimos lenguajes es que resulta inmediato trasladar el diseño a estructuras del len-
guaje. E

Cualquier actividad productiva que se desarrolle de manera discontinua en el

tiempo por un grupo de personas debe ser descompuesta y desarrollada de manera
modular.
l
Para los estudiantes de primer curso de Ingeniería informática resulta una tarea
adicional y no siempre cómoda la descomposición modular de cualquier aplicacióL
desarrollada. Es en esta asignatura donde los alumnos deben adquirir el hábito y la
metodología para realizar la descomposición modular del trabajo a realizar para asr
poder beneficiarse de las ventajas expuestas de la misma.

4.5. Refinamiento
El concepto de refinamiento resulta imprescindible para poder realizar cualquier
tipo de diseño. En un diseño, sea del tipo que sea, siempre se parte inicialmente d
una idea no muy concreta que se va refinando en sucesivas aproximaciones hasta per-
filar el más mínimo detalle. Fue ~ iklaus Wirth [\i\Tirth71) el primero que recomend
la aplicación de refinamientos sucesivos para el diseño de programas.

Las especificaciones recogidas en el documento SRD siempre terminan siendo ex-

presadas en un lenguaje de programación de alto nivel. Sin embargo, el alto nivel d
los lenguajes de programación es sólo relativo, y esos lenguajes están más próximos
al lenguaje del computador que al nuestro propio. La forma natural de acercar ambc-
lenguajes (el natural y el de programación) es utilizando el refinamiento: el objetiY
global de un nuevo sistema software expresado en su especificación se debe refinar er.
sucesivos pasos hasta que todo quede expresado en el lenguaje de programación de
computador. Además, todos los lenguajes tienen la posibilidad de declarar subprer-
gramas (funciones y procedimientos) capaces de expresar los pasos del refinamiem
como acciones o expresiones parametrizadas. Por tanto, el proceso de refinamiento ::
puede dar por concluido cuando todas las acciones y expresiones quedan refinadas er.
 LVAA1IENTO 123

ión de otras acciones o expresiones o bien en función de las instrucciones básicas

enguaje empleado.

El uso direct o e rrestringido de refinamientos sucesivos conduciría a programas

olíticos. El refinamiento directo debe dejar de aplicarse s i el tamaño del progra-
resu1tante para una sola acción global excede de un lírrúte razonable, establecido
~amente en unas dos páginas de texto. Si se excede este límite, convendrá apli-
.. las ideas de abstracción y modularidad para fragmentar una operación global en
rias separadas.

En el próximo capítulo se estudiará la técnica de diseño descendente en la que se

plean los refinamientos sucesivos como mecanismo básico de diseño.

Estructuras de datos
La organización de la información es una parte esencial del diseño de un sistema
'.""Ware. Las decisiones respecto a que datos se manejan y la estructura de cada
o de ellos afectan de una forma decisiva al resto del diseño: abstracciones, módu-
. algoritmos, etc. Por ejemplo, una decisión errónea respecto a si un determinado
-sultado intermedio se guarda o se calcula nuevamente cada vez que se necesite 1
~ede hacer tan lento el sistema que resulte inservible. Esto mismo puede suceder
la estructura de datos elegida complica de manera excesiva la búsqueda de un
.:>terminado dato.

De la importancia de las estructuras de datos en el diseño son buena prueba las

_.etodologías de diseño orientadas a los datos, tales como las propuestas ,Jackson
~ackson75], [Jackson83l y vVarnier [\Narnier81]. En estas metodologías es precisa-
:nente la estructura de datos el punto de partida del que se arranca para realizar el
liseño. El estudio de la gran diversidad de estructuras de datos posibles queda fuera
el alcance e interés de este libro. Además, existen muchos y buenos libros dedicados
..l estudio de las estructuras de datos más adecuadas para resolver los problemas
\:- ...lásicos que se presentan en la mayoría de los casos [Aho83),(\Virth80), [Collado87).
te Para el diseño basta tener en cuenta, en general, las estructuras fundamentales, tales
)S ·orno:
>S
■ Registros
-o
n ■ Conjuntos
~1 ■ Formaciones
1-
■ Listas
o
e ■ Pilas
1 ■ Colas
 124 FUSD..L\IESTOS DEL DI SENO DE SOFT\-VARE REl

• Arboles
• Grafos
■ Tablas
• Ficheros
Es labor del diseñador- la búsqueda, a partir de estas estructuras básicas, de la combi-
nación más adecuada para lograr aquella estructura o estructuras que den respuesta
a las necesidades del sistema planteadas en su especificación. Como siempre, resulta
trascendental la experiencia acumulada de diseños anteriores.

4 .5.2. Ocultación
Para poder utilizar correctamente un programa no es necesario conocer cuál e;
su estructura interna. Por ejemplo, el usuario de un procesador de textos puede ser
cualquier persona que no posea absolutamente ningún conocimiento de informática
y mucho menos de la estructura interna del programa.
De forma semejante se puede pensar respecto a cada uno de los módulos en los qu
se divide el programa en su diseño. Al programador "usuario" de un módulo desa-
rrollado por otro programador del equipo puede quedarle completamente oculta l..
organización de los datos internos que maneja y el detalle de los algoritmos que eIL-
plea.

El concepto de ocultación aplicado al desarrollo de software fue propuesto pe;

Parnas (Parnas72j. Cuando se diseña la estructura de cada uno de los módulos d
un sistema, se debe hacer de tal manera que dentro de él queden ocultos todos k-
detalles que resultan irrelevantes para su u tilización. Tbmando como ejemplo el ::;i::._
tema de control de acceso, en el módulo para el control de puerta deben permanen,
ocultos todos los detalles específicos del manejo de la puerta concreta utilizada (elér-
trica, hidráulica, neumática, etc.) y por tanto del modo de actuar para conseguir:-~
apertura o cierre (tipo de señal y temporizaciones necesarias). Al ,:usuario" de es·
módulo sólo le interesa conocer cómo se le pasa la orden de que la puerta se abra
se cierre.

Con cará.cter general, se trata de ocultar al "usuario" todo lo que pueda ser susce.
tible de cambio en el futuro y además es irrelevante para el uso (hardware, sisten:.
operativo, con1pilador, idioma, etc.). Sin embargo, se muestra en la interfaz sé.
aquello que resultará invariable con cualquier carr1bio. Las ventajas de aplicar e:-
concepto son las siguientes:

• DEPURACIÓ:\f: Resulta más sencillo detectar qué módulo concreto no funci

na correctamente. También es más fácil establecer estrategias y programas
 125

prueba que verifiquen y depuren cada módulo por separado en base a lo que
hacen sin tener en cuenta cómo lo hacen.
■ :\iIA:'-JTEKil\IIEN'TO: Cualquier modificación u operación de mantenimiento
que se necesite en un módulo concreto no afectará al resto de los módulos del
sistema. Si se cambian el hardware, el sistema operativo, etc. sólo se tiene que
modificar el módulo encargado de ocultar estos detalles. El resto de módulos
que usen el módulo modificado permanecerán sin cambios.
-mque el concepto de ocultación se puede y se debe aplicar con cualquier meto-
!ogía o lenguaje de programación, estructuras como los packages de ADA o los
.ODULE de ~;fodula-2 y, por supuesto, los lenguajes de programación orientados
Jbjetos, tienen la ventaja de facilitar de manera considerable la labor de diseño
Jan<lo se aplica el concepto de ocultación.

J.5 .3. Genericidad

Un posible enfoque de diseño es agrupar aquellos elementos del sistema que utili-
..u:1 estructuras semejantes o que necesitan de un tratamiento similar. Si se prescinde
_P los aspectos específicos de cada elemento concreto es bastante razonable diseñar
n- _..:,. elemento genérico con las características comunes a todos los elementos agrupa-
os. Posteriormente, cada uno de los elementos agrupados se pueden diseñar como un
..so particular del elemento genérico. Esta es la idea básica que aporta el concepto
_? genericidad.

Para ilustrar este concepto con un ejemplo, supongamos que se trata de diseñar ,
.n sistema operativo multitarea que necesita atender las órdenes que le llegan de los
..:istintos terminales. Una de las órdenes habituales será imprimir por una cualquiera
Je las impresoras disponibles. Por otro lado. es normal que desde varios terminales
,;multáneamente se necesite acceder a ficheros o bases de datos compartidas. Cada
J11a de estas actividades necesita de un módulo gestor para decidir en qué orden se
.1tienden las peticiones.

La forma más sencilla de gestión es poner en cola las órdenes, peticiones de impre-
)-
,ión o peticiones de acceso a ficheros o bases de datos compartidas. Inmediatamente
,urge la necesidad de una estructura genérica en forma de cola para la que se necesi-
~an también unas operaciones genéricas tales como poner en cola, sacar el primero.
:e iniciar la cola, ver cuántos hay en cola, etc.

En cada caso el tipo de información que se guarda en la cola es diferente: tipo de

)- orden a ejecutar, texto a imprimir) dato a consultar, et.e. A partir de la cola genérica
.e y con un diseño posterior más detallado se tendrá que decidir la estructura concreta
126 FC.:SD.-4.\fESTOS DEL DISEÑO DE SOFTtV.4RE REFI

de las distintas colas necesarias y si para alguna de ellas es conveniente utilizar prio-
ridades; lo que daría lugar a operaciones específicas.

Indudablemente el concepto de genericidad es de gran utilidad en el diseño y da

sir
lugar a soluciones simples y fáciles de mantener. Sin embargo, la implementación de
los elementos genéricos obtenidos como resultado del diseño puede resultar bastante
Er
compleja e incluso desvirtuar el propio concepto de genericidad. Por ejemplo, un
lenguaje de programación, tal como Pascal o :Ylodula-2 , impone unas restricciones
muy fuertes en el manejo de datos de distinto tipo y las posibles operaciones entre
ellos.

Con estos lenguajes es necesario definir un tipo distinto de cola para cada tipo de
elemento a almacenar i y aunque las operaciones sean esencialmente idénticas para
los distintos datos almacenados, también es necesario implementar como operaciones
distintas las destinadas a manejar cada tipo de cola. Esto es, sí tenemos los tipos:
' I
Cola de enteros
Cola de reales
Cola de caracteres
es necesario implementar las operaciones:
Poner entero (en la cola de enteros)
Poner real (en la cola de reales)
Poner caracter (en la cola de caracteres)
Sacar entero
Sacar real
esta solución, que es la única posible en estos lenguajes, desvirtúa de forma evident
la genericidad propuesta en el diseño.

El lenguaje de programación ADA tiene la posibilidad de declarar elementos gené-

ricos (generic) tales como tipos; constantes, subprogramas y objetos, que se pued~
utilizar para parametrizar un procedure o un package. En este caso, tendríamos lo:
siguientes elementos genéricos:
generic
type COLA is private;
procedure PonerenCola( X: in COLA);

Ahora, es posible obtener los procedimientos para cada tipo de dato almacena<!
en la cola de la siguiente forma:

procedure PonerEntero is new PonerenCola( INTEGER );

procedure PonerReal is new PonerenCola( REAL);
MFINA.i\IIENTO 127

procedure PonerCaracter is new PonerenCola( CHARACTER ) ;

procedure PonerOtroTipo is new PonerenCola( OtroTipo ) ;

sin necesidad de desarrollar implementaciones distinta.e; para cada uno de ellos.

En el l\!lodelo Orientado a Objetos se maneja el concepto de clase. Las clases se

.,nstruyen en base a tipos de datos (enteros, reales, cadenas de caracteres, sectores,
ilas. etc.) Si se sustituyen algunos de los tipos de datos mencionados por parámetros
rmales que los representan , y que pueden materializarse en cualquiera de estos ti-
-Js de datos, podemos considerar que estos parámetros formales son tipos genéricos,
":- decir, tipos de datos no concretos.

Las clases de objetos genéricos se pueden denominar clases genéricas, ya que re-
~resentan a todas las clases que se pueden construir cuando se sustituye los tipos
:enéricos por tipos de datos existentes. Cuando hablamos de genericidad en el len-
;uaje C-+, estamos hablando de clases y funciones genéricas, es decir, de clases y
c.J.nciones que están definidas en base a tipos de datos genéricos, parámetros forma-
~ que son tipos de datos que se traducen en tiempo de compilación. En el caso del
.-nguaje C++ se habla de templates o plantillas.

El uso de templates permite definir funciones y clases genéricas mediante la utili-

::ación de datos genéricos, que se escriben como parámetros formales. El compilador
-ustituye el parámetro formal por el tipo real y genera el código necesario cuando
.Jgún fragmento de código hace uso de una instanciación de un template.

4.5.4. Herencia
Otro enfoque posible del diseño cuando hay elementos con característ icas comunes
.es establecer una clasificación o jerarquía entre es¿s elementos del sistema partiendo
de un elemento "padre" que posee una estructura y operaciones básicas.

Los elementos "hijos" heredan del "padre" su estructura y operaciones para am-
pliarlos, mejorarlos o simplemente adaptarlos a sus necesidades. A su vez los elemen-
tos "hijos" pueden tener otros "hijos" que hereden de ellos de una forma semejante. De
manera consecutiva se puede continuar con los siguientes descendientes hasta donde
sea necesario. Esta es la idea fundamental en la que se basa el concepto de herencia.

El mecanismo de herencia permite reutilizar una gran cantidad de software ya

desarrollado. Habitualmente, en un nuevo proyecto siempre se parte de otros pro-
yectos ya realizados de los que se t oman todos aquellos elementos que nos pueden
resultar útiles bien directamente, o con pequeñas modificaciones, o de forma combi-
128 Fl;1YDA-'IESTOS DEL DISENO DE SOFTWARE

nada entre varios, etc. Facilitar esta labor es uno de los objetivos fundamentales del
concepto de herencia.

Si tratamos de realizar un software para dibujo asistido por computador, las fi-
guras que se manejan se podrían clasificar del siguiente modo:

FIGURAS:

ABIERTAS:
TRAZO RECTO:
LÍ~EA RECTA
TRAZO GCRVO: ,
SEGtvIENTO DE CIRCUNFERENCIA
CERRADAS:
ELIPSES:
CÍRCULOS
POLÍGONOS:
TRIÁNGULOS:
EQUILÁTEROS
RECTANGULOS:
CUADRADOS

Aquí, el elemento <'padre" será FIGURAS. Las operaciones básicas con cualquier tip
de figura podrían ser:
■ Desplazar
■ Rotar
■ Pintar
Aunque estas operaciones las heredan todos los tipos de figura, normalmente de-
berán ser adaptadas en cada caso. Así, Rotar los CÍRCULOS significa dejarlos t -
cual están.

Por otro lado. al concretar los elen1entos "hijos" aparecen nuevas operaciones q·
no tenían sentido en el elemento "padre". Así, la operación de calcular el Períme---;-
solo tiene sentido para figuras CERRADAS. De fonna semejante sólo los POLÍGl
XOS tendrán una operación csp<'dfica para determinar la posición de sus Vértir..-
sólo en los RECTA~Gl-LOS se puede hablar de las longitudes de sus lados L
Uno y LacloDos y de su Diagonal. etc.

El concepto de herencia está mur ligado a las metodologías de análisis y dis -

de software orientadas a objetos. Aunque en este apartado sólo se ha mencionadC'
 129

rcncia simple entre un "hijo" y un único "padre'·, es posible realizar diseños en los
~e se tengan en cuenta herencias múltiples de varios ··padres". En esencia se trata
lle aprovechar elementos ya desarrollados para producir otro nuevo que combine si-
::Lultáneamente las estructuras y propiedades de más de un elemento anterior.

La aplicación del concepto de herencia en la fase de diseño es posible sin mayor

problema. Sin embargo, para trasladar de una manera directa y sencilla los resulta-
os del diseño a la codificación es aconsejable utilizar un lenguaje de progrrunación
rientado a objetos. Algunos de estos lenguajes son los siguientes:
■ Smalltalk
■ Object Pascal
■ Objetive-e
■ Eiffel
• e~+
■ .JAVA
Todos ellos disponen del mecanismo de herencia. En [Budd94j y [::"JAUGHTON97]
.;e detallan las particularidades del mecanismo de herencia propuesto por cada uno
de los lenguajes citados.

4.5.5. Polimorfismo
La definición de polimorfismo que encontramos en el diccionario es la siguiente:

Polimorfismo. Propiedad de los cuerpos que pueden cru:nbiar

de forma sin variar su naturaleza.

En nuestro caso, el concepto de polimorfismo engloba distintas posibilidades utili-

zadas habitualmente p~ra conseguir que un mismo elemento software adquiera varias
le-
formas simultáneamente:
tal
1. El concepto de genericidad es una manera de lograr que un elemento genérico
pueda adquirir distintas formas cuando se particulariza su utilización.
ue 2. El concepto de polimorfismo está muy unido al concepto de herencia. Las estruc-
ro turas y operaciones heredadas se pueden adaptar a las necesidades concretas
8- del elemento "hijo": no es lo mismo Rotar ELIPSES que CíRGGLOS. Por tanto,
~s. la operación de rotar tiene distintas formas según el tipo de figura a la que se
:lo destina y es en el momento de la ejecución del programa cuando se utiliza una
u otra forma de rotación. Este tipo de polimorfismo se conoce como de A n u-
lación, dado que la rotación específica para los círculos anula la más general
io para las elipses.
la
130 FUSDA _U ESTOS DEL DISEÑO DE SOFTlVARE REFil

En algunos casos, no hay anulación real dado que no tiene sentido diseñar e 4.5.6
implementar una operación general que abarque todas las posibles situaciones
que se puedan plantear con todos los posibles descendientes. Para estos casos Le
aprov
se plantea un polimorfismo Diferido en el cual se plantea la necesidad de la
operación para el element o "padre", pero su concreción se deja diferida para el tie1
curre:
que cada uno de los elementos "hijos'' concrete su forma específica. Este es el
caso de la operación Rotar FIG"CRAS que resultaría muy compleja y además de a¡:
los e1
probablemente inútil.
casos
.-vent
3. Por último, existe otra posibilidad de polimorfismo que se conoce como So-
brecarga. En este caso quienes adquieren múltiples forrti.as son los operadores. e
l'Il Cl
funciones o procedimientos.
l.
El ejemplo clásico de polimorfismo por sobrecarga lo constituyen los operadores
matemáticos: + , * y / . Estos operadores son similares para operaciones entre
enteros, reales, conjuntos o matrices. Sin embargo, en cada caso el tipo de ope-
ración que se invoca es distinto: la suma entre enteros es mucho más sencilla
y rápida que la suma entre reales y por otro lado con el mismo operador + se
indica la operación suma entre valores numéricos o la operación de unión entre 2.
dos conjuntos o la suma de matrices.

En el diseño de esta Sobrecarga de operadores, a pesar de que nos resulta tan

familiar, se ha utilizado el concepto de polimorfismo. Este mismo concepto se
debe aplicar cuando se diseñan las operaciones a realizar entre elementos del
sistema que se trata de desarrollar. Por ejemplo, se puede utilizar el operador
+ para unir ristras de caracteres o realizar resúmenes de ventas.
3.
El polimorfismo por Sobrecarga también se puede utilizar con funciones o pro-
cedimientos. Así, podemos tener la función Pintar para FIGURAS y diseñar
también una función Pintar para representar en una gráfica los valores de un..
tabla o rellenar con distintos trazos una región de un dibujo, etc.

Todas estas posibilidades de polimorfismo redundan en una mayor facilidad par'

realizar software reutilizable y mantenible. Los elementos que se propongan deberá::.
resultar familiares al mayor número posible de usuarios potenciales.

Al igual que la herencia. el concepto de polimorfismo está ligado a las metodologí::.

orientadas a objetos y para simplificar la implementación es conveniente utilizar algt:.
lenguaje orientado a objetos de los indicados en el apartado anterior.
 131

Concurrencia
Los computadores disponen de una gran capacidad de proct"~c;o que no se debe dcs-
rovechar. lVIientras el operador decide la siguiente tecla que debe pulsar o durante
tiempo en que se está imprimiendo, el computador puede realizar de manera con-
-;:rrentc otras tareas. Sobre todo en los sistemas de tiempo real existe la necesidad
p aprovechar toda la capacidad de proceso del computador para atender a todos
5 eventos que se producen y en el mismo instante en que se producen. En estos
"1..'-0 S normalmente se establecen tiempos máximos de respuesta ante determinados
--entos (alru·mas, fallos, errores, etc.).

~s.
Cuando se trata de diseñar un sistema con restricciones de tiempo se debe tener
'Il cuenta lo siguiente:
l. TAREAS CONCURRE~TES: Determinar qué tareas se deben ejecutar en pa-
ralelo para cumplir con las restricciones impuestas. Se deberá prestar especial
atención a aquellas tareas con tiempos de respuesta más críticos y aquellas otras
que se ejecutarán con mayor frecuencia. Al diseño y codificación de ambos gru-
la pos de tareas se debe prestar especial cuidado, pues de ello depende que se
;e cumplan finalmente las restricciones.
·e 2. SI~CROKIZACIÓK DE TAREAS: Determinar los puntos de sincronización
entre las distintas tareas. ~ormalmente las tareas nunca funcionan cada una
por separado sin tener en cuenta a las demás. Cuando una tarea Ti se encarga
de obtener un resultado que debe utilizar otra T2, ambas se deben sincronizar.
n
La tarea T2 esperará hasta que Ti tenga disponible un nuevo resultado y en el
e
caso de que T2 no haya utilizado el anterior resultado es Ti la que debe esperar.
:1
Para la sincronización entre tareas se pueden utilizar semáforos o mecanismos
r
de tipo rendezvous disponibles en los sistemas operativos o en lenguajes de
programación concurrentes (Ada, Pascal Concurrente, etc.).
3. CO:MCKICACIÓN ENTRE TAREAS: Determinar si la cooperación se basa
en el empleo de datos compartidos o mediante el paso de mensajes entre las
r
tareas. En cualquier caso, el diseñador debe concretar la estructura de los datos
L
compartidos o de los mensajes que se intercambian. También se debe concretar
qué tareas serán las productoras de los datos y qué otras serán las consumidoras.

En el caso de utilizar datos compartidos se tendrá que evitar que los datos
puedan ser modjficados en el momento de la consulta, lo que daría lugar a errores
muy difíciles de detectar. En este caso, es necesario utilizar mecanismos como
semáforos, monitores: regiones críticas, etc. para garantizar la exclusión mutua
entre las distintas tareas que modifican y consultan los datos compartidos.
Estos mecanismos están disponibles en los sistemas operativos o en lenguajes
de programación concurrente.
132 F"CND.4..,IESTOS DEL DISEÑO DE SOFTlV.4.RE se

4. INTERBLOQCEOS (deadlock): Estudiar los posibles interbloqueos entre ta-

reas. -C-n interbloqueo se produce cuando una o varias tareas permanecen es- ue
perando por tiempo indefinido una situación que no se puede producir nunca. en
Por ejemplo , el caso más sencillo de interbloqueo entre dos tareas se produce
cuando ambas simultáneamente se quedan esperando algún resultado que se
deben proporcionar mutuamente la una a la otra y ninguna puede avanzar.
El concepto de concurrencia introduce una complejidad adicional al sistema y por
tanto sólo se debe utilizar cuando no exista una solución de tipo secuencial sencilla
que cumpla con los requisitos especificados en el documento SRD. En general, se '
requieren conocimientos específicos para el diseño de sistemas concurrentes o de
tiempo real [BenAri90J y en gran número de casos la solución finalmente adoptada pu
resulta ser completamente a la medida. de
ca

4.6. N otaciones para el diseño

Para concretar y precisar las descripciones resultantes de todo el proceso de di-
seño se pueden utilizar múltiples notaciones. Como sucedía con la especificación.
cada notación de diseño ha sido propuesta dentro de una metodología concreta, y un
mismo símbolo (rectángulo, círculo, etc.) puede tener significados distintos según los
casos. Además, debido a la evolución de las metodologías y según las propuestas de
distintos expertos o fabricantes de herramientas de diseño, se utilizan distintos sím-
bolos para representar una misma idea. De las decenas de notaciones que existen, en
este apartado se ha tratado de recoger aquellas que disfrutan de mayor aceptación.
empleando para ello los símbolos utilizados más comunmente. A pesar de todo, si se
utiliza una nueva herramienta o metodología de diseño, es muy aconsejable cercio-
rarse antes del significado de cada símbolo. Con este repaso panorámico se trata de
facilitar el aprendizaje de cualquier notación nueva situándola dentro del contexto
adecuado.

El objetivo fundamental de cualquier notación es resultar precisa, clara y sencilla

de interpretar en el aspecto concreto que describe. Se trata sobre todo de evitar am-
bigüedades e interpretaciones erróneas del diseño. En este sentido lo más adecuad"
sería emplear notaciones formales de tipo cuasi matemático. Sin embargo, sólo un-
parte muy pequeña del resultado de un diseño se suele describir utilizando única-
mente notaciones formales.

Resulta muy difícil establecer dónde queda la frontera entre la especificación

el diseño de las características externas o estructurales de un sistema. Así, result
normal que para ciertos aspectos de diseño se empleen notaciones semejantes e e
cluso las mismas del análisis. Para estas notaciones nos remitiremos a lo dicho en
apartado del capítulo anterior c.le<licado a las notaciones para la especificación.
 \'OT.4.CIO.'i'ES P...\RA. EL DISESO 133

Según el a8pecto del sistema que se trata de describir es acom,ejablc emplear una.
,_ :nra clase <le notación. De acuerdo con este criterio, dasifkaremos las notaciones
a los siguientes grupos:
• Notacion0s estructnr alcs
■ ~otacioncs estáticas o de organización
>r ■ l'iotaciones dinámicas o de comportamiento
!él
■ Notaciones híbridas
;e
le El lenguaje natural como notación queda fuera de esta clasificación puesto que se
.a . ucde utilizar para cubrir cualquier aspecto del sistema. Siempre que se utilice, sc>
.eherán tener en cnenta las recomendaciones dadas en el capítulo anterior v en todo
abO, se procurará utilizar solamente como complemento a otras notaciones.

A
1-

1.
TI
)s

le
1-
'Il
:l.
;e
)-

Je
D
o

a
1- Figura 4.1: Diagrama de bloque:,
o,
a
-
4.6.1. N ota ciones estructurales
E::,tas notaciones sirven para cubrir un primer nivel del diseño arquitectónico y
con ellas se trata de desglosar y estructurar el sistema en sus partes f undamentale::..
y En principio 1 cualquier notación informal utilizada en otras ac-tividade::. de ingeniería
a \ que permita describir la estructura global de uu sistema, puede ser válida. Una
-
notación habitual para desglosar un sistema en su~ partes es el empleo de diagrama..._
de bloque..
134 FUSD.-L\!ESTOS DEL DISEÑO DE SOFTW,tR.E NOj

En la figura 4.1 se muestra el diagrama <le bloques de un sistema que está dividjdo I
en cuatro bloques y en el que además se indican las conexiones que existen entre ellos. trod
En algunos casos estas conexiones también pueden reflejar una cierta clasificadón ady,
o jerarquía de los bloques. Cuando la notación es informal , es necesario concretar que
explícitamente si con el diagrama se indica algo más que la simple conexión existente que
entre los bloques.
(

arq1
sub:
Capa 1
par:
1 Pr,
Capa 2 má.'

Capa 3
P1

Capa 4
E P2 s
T
Capa 5

Capa 6

Capa 7

(a) (b)

Figura 4.2: Diagramas de cajas adosadas

Otra notación informal para estructurar un sistema se muestra en la figura 4.2.

En este caso se emplean <'cajas adosadas" para delimitar los bloques. La conexión
entre los bloques se pone de manifiesto cuando entre dos cajas existe una frontera
común.

En el diagrama (a) de la figura 4.2 se muestra un sistema organizado por capas.

Esta estructura se emplea, por ejemplo, en el estándar OSI de comunicaciones. En
él se establecen 7 capas o niveles: Físico, Enlace. Red, Transporte, Sesión, Presenta-
ción y Aplicación.A grandes rasgos, cada capa es un subsistema hardware o software
encargado de incorporar a los mensajes que se envían cierta información redundante
adicional.
 SOTACIOIVES PARA EL DISE1VO 135

) La misma capa al recibir un mensaje se encarga de eliminar las redundancias in-

troducidas en <>l envío y comprobar si la información recibida es correcta. Entre capas
l -ld~·accntes está definida una interfaz completamente estándar. Todo esto posibilita
r ¡ne las modificaciones en la implementación de una capa nunca afecten al resto y
ue el software de comunicaciones de distintos fabricantes sea compatible.

Otro ejemplo es la propuesta de Hatley [Hatley87], que sugiere como plantilla de

.rqui tectura para estructurar los sistemas la que se muestra en la figura 4.2 (b). Los
-.ubsistemas generales propuestos en la plantilla son: E (Entrada), S (Salida), T (Test
?ara la autocomprobación y el mantenimiento), (Interfase de usuario) y P 1 , P2 .....
Procesado y control del sistema). A continuación se presentan algunas notaciones
más formales para describir la estructura <le un sistema.

E F

Figura 4.3: Diagrama de estructura

Diagramas de estructura

Estos diagramas fueron propuestos por Yourdon (Yourdon79) y 11yers(tlyers78]

para describir la estructura de los sistemas software como una jerarquía de subpro-
gramas o módulos en general. En la figura 4.3 se muestra un diagrama dr estructura.
El significado de los símbolos utilizados es el siguiente:
• RECTÁNG-CLO: representa un módulo o subprograma cuyo nombre se indica
en su interior.
136 FUSD.4..\IESTOS DEL DISEÑO DE SOFT\.VARE NO

■ LÍKEA: une a dos rectángulos e indica que el módulo superior llama o utiliza
al módulo inferior. A veces la línea acaba en una _flecha junto al módulo inferior
al que apunta.
■ RO:\ifBO: se sitúa sobre una Línea e indica que esa llamada o utilización es
opcional. Se puede prescindir de este símbolo si en la posterior descripción
del módulo superior, mediante pseudocódigo u otra notación) se indica que el
módulo inferior se utiliza sólo opcionalmente.
■ ARCO: se sitúa sobre una Línea e indica que esa llamada o utilización se efectúa
de manera repetitiva. Se puede prescindir de este símbolo si en la posterior
descripción del módulo superior, mediante pseudocódigo u otra notación, se
indica que el módulo inferior se utiliza de forma repetitiva.
• CÍRCULO CON FLECHA: se sitúa en paralelo a una línea y representa el
envío de los datos, cuyo nombre acompaña al símbolo, desde un módulo a otro.
El sentido del envío lo marca la flecha que acompaña al círculo. Para indicar
que los datos son una información de control se utiliza un círculo relleno. Una
información de control sirve para indicar SI/ KO, o bien un estado: Correcto /
Repetir / Error / Espera / Desconectado /
En el capítulo siguiente se verán técnicas de diseño que permiten obtener el dia-
grama de estructura a partir de la especificación. Cuando el diseño realizado es
razonablemente correcto, el resultado es un diagrama en forma de árbol mostrando
la jerarquización de los módulos. Como sucede en la figura 4.3 es normal que varios
módulos superiores utilicen un mismo módulo inferior, lo que significa que ese mó-
dulo se reutiliza en varios puntos del sistema.

El diagrama de estructura no establece ninguna secuencia concreta de utilización

de los módulos y tan sólo refleja una organización estática de los mismos. Por ejem-
plo, en la figura 4.3 el módulo A utiliza a los módulos B, C y D en cualquier orden
sin tener en cuenta su situación a la izquierda, a la derecha o en el centro.

Observando el diagrama de la figura 4.3 se puede decir lo siguiente:

■ El módulo E proporciona el dato "C al módulo B. Este dato es una entrada al
sistema ( teclado, ratón, generación por cálculo, etc.).
• El módulo B transforma el dato U y obtiene el dato X que proporciona al
módulo A. El módulo A utiliza al módulo B de forma repetitiva.
■ El módulo A proporciona al módulo C el dato Y y este último le devuelve al
módulo A la información de control Z.
• El módulo C proporciona al módulo F el dato V. También, el módulo D pro-
porciona al módulo F Pl mismo dato V.
 -JT.4CIONES PA.RA EL DISEÑO 137

utiliza • El módulo F no devuelve nada a ninguno de sus módulos superiores. Eso ocurre,
inferior por ejemplo 1 si se encarga de realizar la salida de los datos que se le envían
(impresora, pantalla, etc.).
ción es • El módulo D se utiliza opcionalmente por A y recibe de este último el dato X
ripción que a su vez A recibió de B.
que el
• El diagrama es estrictamente jerarquizado y no existen Líneas entre módulos
de un mismo nivel.
efectúa
>sterior
ión, se
A o.o

enta el
a otro. 1
indicar
o. "Cna B 1.0
e 2.0
D
3.0

recto/
l 1 1
1 1 1 1
el dia-
ado es E F G H 1 J K 3.3
1.2 2-1 2.2 3.1 3.2
1.1
tra.ndo
varios
se mó- Figura 4.4: Diagrama. HIPO de contenidos

.zación Diagramas HIPO

· eJem-
orden Los diagramas HIPO (Hierarchy-lnput-Process-Output) son una notación pro-
puesta por IBM para facilitar y simplificar el diseño y desarrollo de sistemas software,
destinados fundamentalmente a gestión (facturación,contabilidad, nóminas, inventa-
rio, etc.). La mayoría de estos sistemas se pueden diseñar como una estructura jerar-
quizada (Hierarchy) de subprogramas o módulos. Además, el formato de todos los
·ada al módulos se puede adaptar a un mismo patrón caracterizado por los datos de entrada
(Input), el tipo de proceso (Process) que se realiza con los datos y los resultados de
ona al salida que proporciona (Output).

La figura 4.4 muestra un diagrama HIPO de contenidos que se utiliza para estable-
elve al
cer la jerarquía entre los módulos del sistema. Como se puede observar, es asimilable
a un diagrama de estructura simplificado en el que no se indican los datos que se in-
) pro- tercambian los módulos. Cada módulo tiene un nombre (A, B, C, ... ) y una referencia
al correspondiente diagrama HIPO de detalle (O.O, 1.0, .... ).
 FüSD.-1:-.fESTOS DEL DISEÑO DE SOFTlVARE NO
138

Dia
p o
Datos_A Pseudocódigo del (Ja
Proceso de
Datos- N
tre;
Con referencias a
otros diagramas
de detalle: L(k,m)
Datos- M

Datos- B

Diagrama: a.b
PARA: M(K,I)
rrtulo del diagrama: A Q(m,n)

Figura 4.5: Diagrama HIPO de detalle

En la figura 4.5 tenernos el diagrama HIPO de detalle del módulo cuyo nombre
es A y referencia (a.b). Los diagramas de detalle constan de tres zonas: Entrada (I).
Proceso (P), Salida (O). En las zonas de entrada y salida se indican respectivamente
los datos que entran (Datos_A y Datos_B) y salen (Datos_N y Datos_M) del
módulo. En la zona central se detalla el pseudocódigo del proceso con referencia a
otros diagramas de detalle de nivel inferior en la jerarquía. La lista de los diagramas
referenciados se listan a continuación de la partícula PARA: Por la parte superior y
a continuación de la partícula DE: se indica el diagrama de detalle de nivel superior:
N(iJ).

A B e
l o
* o
X y z u V

Secuencia Iteración Secuencia

Figura !.6: Diagrama de .Tackson

 YOTACIOi'lES PARA EL DISEl\'O 139

Diagramas de Jackson

Esta notación forma parte de la metodología desarrollada por Jackson (Jackson75].

packson83] para diseñar sistemas software a partir de las estructuras de su~ <latos
<le entrada y salida. El proceso de diseño es bastante sistemático y se lleva a cabo en
trt>S pasos:

l. Especificación de las estructuras de los datos de entrada y salida.

2. Obtención de una estructura del programa capaz de transformar las estructuras

de datos de entrada en las de salida. Este paso implica una conversión de las
estructuras de datos en las correspondientes estructuras de programa que las
manejan. teniendo en cuenta las 2 equivalencias clásicas entre ambas:

TUPLA - SECUENCIA: Colección de elementos de tipos diferentes, combina-

dos en un orden fijo.
{.;)llÓN - SELECCIÓ ·: Selección de un elemento entre varios posibles. de tipos
diferentes. ·
FOR..\IACIÓK - ITERACIÓK: Colección de elementos del mismo tipo.

3. Expansión de la estructura del programa para lograr el diseño detallado del

sistema. Para realizar este paso normalmente se utiliza pseudocódigo.

La metodología Jackson está englobada dentro de las de Diseño Dirigido por los
Datos. que ha sido utilizado fundamentalmente para diseñar sistemas relath·amente
pequeños de procesamiento de datos.

La notación propuesta por J ackson se muestra en la figura 4.6 y ::;irve indistin-

tamente para especificar tanto la estructura de los datos como la estructura del
programa. En estos diagramas la estructura del elemento superior se detalla según
queda indicado por los elementos inmediatamente inferiorc::;. En e;te caso e::; funda-
mental la situación de cada elemento en el diagrama. En la figura •1.6. el ele1nPnto
A es igual a la secuencia x-y leída de izquierda a derecha y nunca a la invt'rsa. El
elemento B es igual a la repetición de cero o más Yeces del elemento z ( indicado
por el símbolo ··*'º). El elemento C es igual a una st>lccción entre los elementos u y \
(indicado por el símbolo "0'').
140 FUNDA.\IESTOS DEL DISEl\10 DE SOFTvVARE NC

Di
A 1
B·
I

IF Condicion THEN sis

de
FOR i:=1 TO N DO
B D se
G re:
~ END DE
o
ELSE pé
E F
H;I
END D
D;
G H
gE
d1
Figura 4.7: Diagrama de J ackson
la
d,
el
En la figura 4. 7 se muestra un diagrama de J ackson y la estructura de programa
equivalente. Si los elementos del diagrama representan datos, la estructura equiva-
lente, expresada en notación de diccionario de datos, es la siguiente:

A- B-C+ D ii
C= [ E I F] e
E= G d
F =H + I u
e

4.6.2. Notaciones estáticas

Estas notaciones sirven para describir características estáticas del sistema, tales ]
como la organización de la información, sin tener en cuenta su evolución durante el
funcionamiento del sistema. La organización de la información es uno de los aspectos
{
en los que se hace un especial hincapié al especificar el sistema. Sin embargo, en
el documento SRD de especificación sólo se realiza una propuesta de organización a
grandes rasgos y de acuerdo exclusivamente con las necesidades externas del sistema.

En la fase de diseño se completa la organización de la información teniendo en

cuenta todos los aspectos internos: datos auxiliares, mayor eficiencia en el manejo de
los datos, datos redundantes, etc. Por tanto, como resultado del diseño se tendrá una
organización de la información con un nivel de detalle mucho mayor. En cualquier
caso, las notaciones que se pueden emplear para describir el resultado de este trabajo
son las mismas que se emplean para realizar la especificación.
 .RE XOT, lCIOSES PARA. EL DISEÑO 141

Diccionario de datos

C'on esta notación se detalla la estructura interna <le los <latos que maneja el
. -.tema. Las características de esta notación ya han sido descritas en el apartado
_ descripción de datos del capítulo de especificación de software. Para el diseño
partirá del diccionario de datos incluido en el documento SRD y mediante los
n finamientos necesarios se ampliará y completará hasta alcanzar el nivel de detalle
DP(.'Csario para iniciar la codificación. En el próximo capítulo se estudiarán las técnicas
~ra realizar esta labor.

Diagramas Entidad-Relación

Esta notación permite definir el modelo de datos. las relaciones entre los datos y en
..,""11eral la organización de la información. Esta notación está descrita en el apartado
ie diagramas de modelo de datos del capítulo de especificación de software. Para
~a fase de diseño se tomará como punto de partida el diagrama propuesto en el
documento SRD, que se completará y ampliará con las nuevas entidades y relaciones
entre las mismas, que aparezcan en la fase de diseño del sistema.
na
,a-
~ otaciones dinámicas

Estas notaciones permiten describir el comportamiento del sistema durante su

funcionamiento. La especificación de un sistema es precisamente una descripción del
·omportamiento requerido desde un punto de vista externo. Al diseñar la dinámica
del sistema se detallará su comportamiento externo y se añadirá la descripción de
un comportamiento interno capaz de garantizar que se cumplen todos los requisitos
especificados en el documento SRD. Así, las notaciones que se empican para el diseño
son las mismas utilizadas en la esprcificación.

es Diagramas de flujo de datos

el
)S Las características de esta notación están detalladas en el capítulo de especifi-
cación de software. Desde el punto de vista del diseño, los diagramas de flujo de
a datos serán mucho más exhaustivos que los de la especificación. Esto es debido a la
l,. necesidad de describir cómo se hacen internamente las rosas y no sólo qué cosas debe
hacer el sistema.
n
e Digramas d e transición de estados
a
Esta notación está descrita eu el capítulo de esprdficación de software. En el
o diseño del sistema pue<lC'n aparecer nueYos diagramas de estado que reflejen las tran-
siciones entre estados internos. Sin embargo, E>S prefcrihle no modificar o ampliar los
142 FLº.\'D.--L\IESTOS DEL DISEÑO DE SOFTW4.RE NO'I

diagramas recogidos en el documento SRD encargados de reflejar el funcionamiento p

externo del sistema. de e
dent
aob
Lenguaje de Descripción de Programas (PDL)
disei
La notación PDL ha sido presentada en el apartado dedicado al pseudocódigo y de
del capítulo de especificación de software. Como allí se comentaba, esta notación se
utiliza tanto para realizar la especificación funcional del sistema como para elaborar
el diseño del mismo. La diferencia entre ambas situaciones la marca el nivel de detalle
al que se desciende en la descripción funcional.
Dia,
Tanto al especificar como al diseñar se utilizan las mismas estructuras básicas de
la notación PDL. Sin embargo, cuando se quiere descender al nivel de detalle que se (
requiere en la fase de diseño, la notación PDL se amplía con ciertas estructuras de
dan
algún lenguaje de alto nivel. Uno de los apropiados es Ada.
,-ib
Je l
La notación denominada Ada-PDL permite declara1· estructuras de datos e incluso
q, e
existen compiladores para verificar el pseudocódigo. Evidentemente, a nivel de diseño.
lat,
los detalles de implementación se dejarán indicados mediante comentarios en lenguaje
natural. Ada-PDL ha sido incluido corno estándar en las normas IEEE. Aunque no es
totalmente formal conduce a descripciones precisas, poco ambiguas, y relativamente
fáciles de comprender si se conoce suficientemente el lenguaje Ada. tos,

Notaciones híbridas

Estas notaciones tratan de cubrir simultáneamente aspectos estructurales, está-

ticos y dinámicos. En realidad algunas de las notaciones descritas anteriormente.
aunque han sido clasificadas dentro de un grupo concreto, poseen también ciertas
características del resto de los grupos.

Según hemos visto, la metodología de Jackson utiliza una notación estructura!

que describe, según los casos, la organización de la información (estática) o el corn-
porta1nicnto (dinámico) del sistema y está basada precisamente en aprovechar la
analogía que existe entre la organización de los datos y los procedimientos o progra-
mas necesarios para su manejo.

Por tanto, se podría considerar como una notación híbrida. Tam_bién la metodolo-
gía de diseño orientada a los datos de \Varnier-Orr posee una notación que se pucd..-
considerar híbrida por las mismas razones: se parte de la organización de los dato-
para diseñar los procedimientos. Para un estudio en detalle de esta metodología ::,
pueden consultar (\Varnier81] ~- [Orr8ll.
 "iDTA.CIOJVES PARA EL DISEÑO 143

Prescindiendo de las notaciones de Jackson y \\"arnier. el objetivo fundamental

este apartado es presentar las notaciones más modernas que se han propuesto
'ltro de las metodologías de diseño basado en abstracciones y de diseño orientado
hjetos. Todas estas notaciones son híbridas y permiten un enfoque globalizado del
, cño en el que se aglutinan los aspectos estáticos (datos). dinámicos (operaciones)
le estructura del sistema.

!>iagramas de abstracciones
de
SC'
de
Como ya hemos visto en este mismo capítulo, el concepto de abstracción es fun-
~ amental para la estructuración de sistemas complejos. La notación que aquí se des-
cnbe fue propuesta originalmente por Liskov [Liskov80) para describir la estructura
de un sistema software compuesto por elementos abstractos. En la propuesta original
so
.o.
contemplaban dos t ipos de abstracciones: las funciones y los tipos abstractos de
ó ltos. A ellos se han añadido con símbolo propio [Cerrada00] los datos encapsulados.
,Je
es
te Dada la afinidad existente entre los tipos abstractos de datos y las clases de obje-
' '>S. al tiempo que se presenta la notación para describir abstracciones, se aprovecha
para establecer una cierta analogía entre la programación basada en abstracciones y
!a programación orientada a objetos.

á-
e. Según se muestra en la figura 4.8 (a), en una abstracción se distinguen tres partes
o elementos claramente diferenciados:

NO~IBRE: Es el identificador de la abstracción

1-
a CONTENIDO: Es el elemento estático de la abstracción y en É'l se define la
.- organización de los datos que constituyen la abstracción. Si se utilizase el len-
guaje l\Iodula-2, este elemento lo formarían las definiciones de constantes, tipos
de datos y variables declarados en el módulo de definición.
-
e OPERACIOKES: Es 01 elemento dinámico de la abstracción y en él se agrupan
s todas las operaciones definidas para manejar el COKTENIDO de la abstrac-
e ción. Si se utilizase el lenguaje l\Iodula-2, este elemento estaría.formado por
las definiciones de funciones y 1 o procedimientos declaradas en el módulo de
definición.
144 Fr.í.VD--l.\IESTOS DEL DISEÑO DE SOFT\;,VARE ~0'1

Nombre Nombre

Contenido Atributos
. .. .... ....... e
....... ·ión
.......
de 1

Operaciones Métodos
Ol
....... ....... ecl

(a) (b)

Figura 4.8: Estructura de una abstracción (a) y de un Objeto (b)

Inicialmente la única forma de abstracción disponible en los lenguajes, y por tanto

con la que únicamente se podía abordar un diseño, era la definición de subprogramas:
funciones (expresiones parametrizadas) o procedimientos (acciones parametrizadas).
Un subprograma constituye una operación abstracta que denominaremos abstracción
funcional. Esta forma de abstracción no tiene la parte de CONTEKIDO y sólo está
constituida por una única OPERACIÓN.

Al analizar y diseñar un sistema se identifican datos de diferentes t ipos con los

que hay que operar. En un diseño bien organizado se puede agrupar en una misma
entidad la estructura del tipo de datos con las correspondientes operaciones necesa-
rias para su manejo. Esta forma de abstracción se denomina tipo abstracto de datos
y tiene una parte de COKTENIDO y también sus correspondientes OPERACIONES.

Los tipos abstractos de datos permiten crear nuevos tipos de datos, además de
los predefinidos en el lenguaje de implementación. Todos los datos concretos que se
manejen en un programa deben aparecer como constantes o variables de algún tipo ,
sea predefinido o definido como tipo abstracto. Para operar con un dato en particular
se invocará alguna de las operaciones definidas sobre su tipo, indicando a qué dato
en particular queremos aplicarla. Por ejemplo, si tenemos el tipo abstracto Tarjeta
y se declara:

VAR tarjeta4B, tarjetaVISA : Tarjeta;

podremos indicar con cuál de ellas queremos realizar una operación haciéndola apa-
recer como argumento de la misma. por ejemplo:
VARE T.4.CIONES PA.RA EL DISENO 145

LeerTarjeta( tarjeta4B );

ComprobarTarjeta( tarjeta VISA ) ;

Cuando sólo se necesita una variable de un determinado t ipo abstracto, su declara-
n se puede encapsular <lentro de la misma abstracción. Así, todas las operaciones
la abstracción se referirán siempre a esa variable sin necesidad de indicarlo de
1era explícita. Esta forma de abstracción se denomina Dato encapsulado, tiene
O~TENIDO y OPERACIO~ES, al igual que un tipo abstracto, pero no permite
larar otras variables de su mismo tipo.

0 Abstracción funcional

anto
mas: ~ Tipo Abstra cto de datos

m
ias).
:ción Dato Encapsulado
está

Llos F igura 4.9: Abstracciones: notación básica

sma
esa- En el ejemplo anterior, si sólo se maneja una Tarjeta, se podría declarar:
atos
l\tIODL'LE Tarjeta;
rEs.
EXPORT LeerTarjeta, ComprobarTarjeta;
3 de
YAR «datos de la tarjeta»
e se
1po,
END Tarjeta;
1lar
!ato e invocar las operaciones simplemente como: LeerTarjeta;
ieta
LeerTarjeta;

ComprobarTarjeta;

pa- En la figura 4.9 se muestra la notación gráfica para indicar la forma de abstracción
que se está empleando. En la figura 4.10 tenemos el diagrama de estructura de un
146 FUNDA~IEXTOS DEL DISEÑO DE SOFT\.V..4.RE so
sistema. En este caso los módulos son abstracciones en sus distintas formas posibles
y la relación entre abstracciones es jerárquica e implica que la abstracción superior
utiliza a la inferior. Así, la abstracción funcional A utiliza el dato encapsulado D y
el tipo abstracto B. Al dato encapsulado D también lo utilizan B y la abstracción
funcional C. A su vez, la abstracción funcional C también es utilizada por B.

Figura 4.10: Diagrama de estructura basada en abstracciones

Diagramas de objetos

La metodología de diseño basado en abstracciones y la metodología orientada

los objetos se han desarrollado de forma paralela pero en ámbitos muy distintos. La.
abstracciones se pueden considerar una propuesta de los expertos en programaciórr
mientras que los objetos son una propuesta de los expertos en inteligencia artificia.2
Aunque las similitudes entre ambos conceptos son muy grandes, su desarrollo en dL-
tintos ámbitos ha propiciado la utilización de una terminología distinta para indica.;
lo mismo. Esto da lugar a cierta confusión. Como se indica en la figura 4.8 (b). -
estructura de un objeto es exactamente igual que la estructura de una abstracciót.
En cuanto a la terminología empleada se puede establecer la equivalencia que se n-
coge en el cuadro 4.1

Las diferencias fundan1entales enlre ambos conceptos son las siguientes:

l. ~o existe nada equivalente a los datos encapsulados ni a las abstracciones fu:::
cionales cuando se utilizan objetos en forma estricta (algunos lenguajes, corr.
SmallTalk, suplen esta carencia permitiendo asociar atributos y métodos a L
clases).
2. Sólo entre objetos se contempla una relación de herencia.
Teniendo en cuenta la escasa diferencia entre ambos planteamientos. en el r
de este capítulo utilizaremos la terminología de objetos, debido a la mayor aceptad
 :JTA.CIONES PARA. EL DISEÑO 147

ABSTRACCIOKES OBJETOS

Tipo Abstracto de Datos - - Clase de Objeto

Abstracción Funcional - NO HAY EQl;IVALENCIA
Dato encapsulado - NO HAY EQl,;IVALENCIA
Dato Abstracto - - Objeto (Ejemplar de la Clase)
(Variable o Constante)

Contenido Atributos
Operaciones - - :\ilétodos

Llamada a una operación - - :\ilensaje al Objeto

Cuadro 4.1: Equivalencias de terminologías

Si consideramos un objeto formado exclusivamente por sus atributos, tendremos

.Jla estructura de datos. Esta estructura, como cualquier otra, puede formar parte
Je un diagrama de modelo de datos E-R (Entidad-Relación) como una entidad más.
:nversamente, es admisible considerar que todas las entidades en un modelo de datos
-=on objetos (o más exactamente, clases de objetos). Como entidades, entre objetos
~ puede destacar cualquier tipo de relación que el diseñador considere necesaria.
-\demás, debido a las propiedades particulares de los objetos, se pueden establecer
~ntre ellos dos tipos de relaciones especiales:

A.- CLASIFICACIÓ:i\", ESPECIALIZACIÓK O HEREKCIA: (Ko contemplada en-

tre abstracciones) Esta relación entre objetos permite diseñar un sistema aplican-
fun-
do el concepto de herencia. Como ya se indicó al hablar de herencia, los objetos
«hijos" pueden adaptar las operaciones heredadas a sus necesidades concretas.
Así, la herencia también se puede denominar especialización o clasificación. Para
ratificar esta afirmación es completamente válido el ejemplo de las FIGURAS
que hemos clasificado en ABIERTAS, CERRADAS, Las operaciones para rotar,
desplazar, etc. s.e heredan y especializan según la estructura concreta de la figura
ción. "hija".
148 FUNDA.UESTOS DEL DISEÑO DE SOFTWARE S01

Padre
- ···
··-····
- ··
- ···
·-··"·
_ ,,

/"'-..
1 1
Hijo_Uno Hijo_Dos Hijo_Tres
- - -·-· -
······- ·-····· --··
--· - ·· - ·

_,, -
--·
-··-·- ,.-..., - -···
-·-- -- ··- ·

Figura 4.11: Clasificación, especialización o herencia entre objetos

En la figura 4.11 se muestra un ejemplo de herencia entre objetos. La notaci

empicada es la sugerida por la metodología 01'1T (Object Modelling Techniqt.
descrita en [Rumbaugh91]. Con el triángulo se indica que los objetos inferio.
{Hijo_ Uno, Hijo_ Dos e Hijo_Tres) heredan los atributos y las operaciones
objeto superior (Padre). De esta misma metodología también forma parte
notación empleada en la figura 4.8 para describir una abstracción u objeto. H
que tener en cuenta que existe un gran número de notaciones para represen
objetos y sus relaciones particulares, por lo que para trabajar con unos diagra::::
concretos es conveniente consultar el correspondiente manual de la herramie--
de soporte o un texto específico sobre la metodología empleada. (

I
Con la relación de herencia no es necesario indicar la cardinalidad entre las di.;:
de objetos, que está implícita en el diagrama. ya que en él aparece expresam'-
cada relación de herencia entre clases. I
 JTACI01'"ES E4RA EL DISE5to 149

Estructura

-
--
-
-
·--
-

◊
6 ...... l
Elemento_1 Elemento- 2 Elemento_3

-- - -
·--- - -- -·-···
-·- - -·

- - -·
- ·- --··
·- - -

Figura 4.12: Composición de objetos

B.- COivIPOSICIÓ~ (También válida entre abstracciones)

.
La relación de composición permite describir un objeto mediante los elemen-
tos que lo forman. En la figura 4.12 se muestra la relación de composición
con la notación O~IT. El rombo indica. que el objeto Estructura está com-
puesto de Elemento_ l, Elemento_ 2 y Elemento_ 3.

En la relación de composición sólo hay que indicar la cardinalidad en un sentido.

Cada objeto hijo sólo puede formar parte de un objeto padre. Sólo falta indicar
qué número mínimo y máximo de objetos de cada clase hija se pueden utilizar
para componer un objeto de la clase padre. Como se muestra en la figura 4.12.
.ases la cardinalidad se indica junto a cada uno ele los objetos componentes. Así.
para formar Estructura son necesario:. cero o \·arios Elemento_ 1, uno y sólo un
Elemento_ 2 y al menos un Elemento 3.
150 FUNDA.1UESTOS DEL DISEÑO DE SOFT\V.4.RE DOCl

4. 7. Documentos de diseño

El resultado principal de la labor realizada en la etapa de diseño se recoge en un

documento que se utilizará como elemento de partida para las sucesivas etapas deI
proyecto, y que denominaremos documento de diseño de software o Software Desigi:.
Document (SDD). Cuando la complejidad del sistema haga que el documento SDI:
resulte muy voluminoso y dificil de manejar es habitual utilizar dos o más documen-
tos para describir de forma jerarquizada la estructura global del sistema.

Existen numerosas propuestas para la organización de los documentos y de hech

probablemente cada empresa utilice uno distinto. Organismos internacionales com
IEEE [IEEE87), el Departamento de Defensa norteamericano [D0D88] o la Ager.:
cía Espacial Europea [ESA91] han propuesto sus propias normas de documentaciór.
bien como simples recomendaciones o como normas de obligado cumplimiento cuai::
do se realiza un trabajo para dichos organismos. Las normas de la ESA establecen
empleo de un Documento de Diseño Arquitectónico o "Architectural Design Doc-
ment" (ADD) para describir el sistema en su conjunto y otro Documento de Disec
Detallado o "Detailed Design Document" (DDD) para describir por separado ca..
uno de los componentes del sistema. Los índices de estos documentos están recogid
en los cuadros 4.2 y 4.3 respectivamente. Los contenidos de cada apartado son :
siguientes:

4.7.1. Documento ADD

l. INTRODUCCIÓN

Esta sección debe dar una visión general de todo el documento ADD. Los ..
tenidos de sus apartados (Objetivo, Ámbito, Definiciones: siglas y abreviattc
y Referencias) st>rán similares a los descritos en el capítulo anterior para el
cumento SRD pero referidos al sistema tal como se ha diseñado. Siempre q~
considere interesante se puede y se debe hacer referencia a los correspondí
apartados del documento SRD.

2. PAKORAl\IICA DEL SISTE~JA

Esta secrión debe dar una visión general de los requisitos funcionales r
otro tipo) del sistema que ha de ser diseñado. haciendo referencia al docu
SRD.
 :)fENTOS DE DISENO 151

l. INTRODUCCIÓ~
1.1 Objetivo
1.2 Ámbito
1.3 Definiciones, siglas y abreviaturas
1.4 Referencias
1.5 Panorámica del documento
2. PA::--IORÁ\flCA DEL SISTEMA
3. CONTEXTO DEL SISTE1'v1A

3.n Definición de interfaz externa

4. DISEÑO DEL SISTE:VfA
4.1 ~1etodología de diseño de alto nivel
4.2 Descomposición del sistema
5. DISEÑO DE LOS COJ\:1PO::--IENTES

5.n Identificación de componente

5.n.l Tipo
5.n.2 Objetivo
5.n.3 función
5.n.4 Subordinados
5.n.5 Dependencias
5.n.6 Interfases
5.n.7 Recursos
5.n.8 Referencias
5.n.9 Proceso
5.n.10 Datos
6. VIABILIDAD DE RECURSOS ESTIMADOS
7. :MATRIZ DE REQUISITOS CO:.VfPONENTES

Cuadro 4.2: Índice de Documento ADD

3. CO~TEXTO DEL SISTEl\-1A

En esta sección se indicará si este sistema posee conexiones con otros y si

debe funcionar integrada con ellos. En cada uno de sus apartados se definirá la
corTcspondiente interfase que se debe utilizar con cada uno de los otros sistemas.
Si el sistema no necesita intercambiar inform ación con ningún otro, se indicará
•~o existe interfaz" o "~o aplicable".

-1. DISEKO DEL SISTE?vIA

Esta sección describe el nivel superior del dü,eiío. en que se considera el sistema
en su conjunto y se hace una primera estrucrnra.ción en cornponentes.
152 FL'SDAJJENTOS DEL DISEÑO DE SOFT1V:ARE DOC(

4.1 :\1etodología de diseño de alto nivel

Se describe brevemente o se hace referencia a la metodología a seguir en el

proceso de diseño de la arquitectura del sistema.
4.2 Descomposición del sistema

Se describe el primer nivel de descomposición del sistema en sus componen-

tes principales. Se enumeran los componentes y las relaciones estructurales
entre ellos.
5. DISEKO DE LOS CO~PONE~TES
Las siguientes subsecciones se repiten para cada uno de los componentes men-
cionados en el apartado 4.2
5.n Identificador del componente

Nombre del componente. Dos componentes no podrán tener nunca el mism

nombre. Al elegir el nombre se tratará de que refleje su naturaleza. Esto sim-
plifica la búsqueda e identificación de los componentes.

5.n.l Tipo

Se describe la clase de componente. En algunos casos es suficiente con indicar e:

tipo de componente: subprograma, módulo, procedimiento, proceso, datos, et
También es posible definir aquí nuevos tipos basados en otros más elemental~
En cualquier caso, dentro del mismo documento se debe establecer una lisr
coherente de los tipos usados.

5.n.2 Objetivo

Se debe describir la necesidad de que exista el componente. Para ello se puec.

hacer referencia a un requisito concreto que se trata de cubrir. Si el requisi
no forma parte del documento SRD se tendrá que detallar en este rnomento.

5.n.3 Función

Se describe qué hace el componente. Esto se puede detallar mediante la trru:..

formación entrada/ salida que realiza o si el componente es un dato se describe-
qué información guarda.
 CUA1ENTOS DE DISEÑO 153

5.n.4 Subordinados

Se enumeran todos los componentes usados por éste.

5.n.5 Dependencias

Se enumeran los componentes que usan a éste . .Junto a cada dependencia se

podrá indicar su naturaleza: invocación de operación, datos compartidos, ini-
cialización, creación, etc.

5.n.6 Interfases

Se describe cómo otros componentes interactúan con éste. Se tienen que esta-
blecer las distintas formas de interacción y las reglas para cada una de ellas:
paso de parámetros, zona común de memoria, mensajes, etc. También se indi-
carán las restricciones tales como rangos, errores, etc.

5.n.7 Recursos

Se describen los elementos usados por este componente que son externos a este
diseño: impresoras, particiones de disco, organización de la memoria, librerías
matemáticas, servicios del sistema operativo. tamaño de "buffers". posibilida-
des de interbloqueos, etc.

5.n.8 Referencias

Se presentan todas las referencias utilizadas.

5.n.9 Proceso

Se describen los algoritmos o reglas que utiliza el componente para realizar su

función como un refinamiento de la subsección 5.n.3.
o.
5.n.10 Datos

Se describen los datos internos del componente induyendo el método de re-

presentación, valores iniciales, formato. valores válidos, etc. Esta descripción se
puede realizar mediante un diccionario <le <latos. Además. se indicará el signi-
ficado de cada elemento.
154 FC.:SD.--L\IESTOS DEL DISEÑO DE SOFTWA ONCLi

6. VIABILIDAD Y RECURSOS ESTII\L\DOS

Se analiza la viabilidad de la realización del sistema y se concretan los recurso.

que se necesitan para llevarlo a cabo.

7. l\IATRIZ REQUISITOS/ CO:.JPONENTES

Finalmente, en esta sección se muestra una matriz poniendo en las filas todo
los requisitos y en las columnas todos los componentes. Para cada requisito ~
marcará el componente o componentes encargados de que se cumpla.

4.7.2. Documento DDD

Este documento irá creciendo con el desarrollo del proyecto. En proyectos grar.
des puede ser conveniente organizarlo en varios volúmenes. Como se puede ver en
cuadro 4.3, el formato de este documento es bastante similar al ADD. La diferena.
entre ambos es el nivel de detalle al que se desciende. En este documento exist
un mayor nfunero de componentes y para cada uno de ellos se baja incluso hasta
nivel de codificación. Los listados fuente se recogen dentro del documento como
apéndice.
 _-cLUSIONES 155

P arte l. DESCRIPCIÓ~ GENERAL

l. I:\'TROD-CCCIÓN
1.1 Objetivo
1.2 Ámbito
1.3 Definiciones, siglas y abreviaturas
1.4 Referencias
1.5 Panorámica del documento
2. NORMAS, CONVENIOS Y PROCEDL\UENTOS
2.1 Normas de diseño de bajo nivel
2.2 Normas y convenios de documentación
2.3 Convenios de nombres (ficheros, programas, módulos, etc.)
2.4 Normas de programación
2.5 Herramientas de desarrollo de software
Parte 2. ESPECIFICACIO:'-1ES DE DISEÑO DETALLADO
n. Identificador del componente
n.l Identificador
n.2 Tipo
n.3 Objetivo
n.4 Función
n.5 Subordinados
n.6 Dependencias
n. 7 Interfases
n.8 Recursos
n.9 Referencias
n.10 Proceso
n.11 Datos
APÉ:\!DICE A. LISTADOS FUE~TE
APÉ:\!DICE B. MATRIZ REQUISITOS/ CO:VIPO:\'ENTES

Cuadro 4.3: Índice del Documento DDD

Dentro de la Parte 1 es interesante destacar la sección 2 dedicada a recoger todas

" normas, convenios y procedimientos de trabajo que se deben aplicar durante el
rrollo del sistema. La importancia de esta sección es muy grande y de ella depende
e el trabajo realizado por un equipo amplio de personas tenga una estructura
:-i.erente y homogénea. La realización de esta sección debe ser la primera actividad
l diseño detallado antes de iniciar el diseño propiamente dicho. Si se utilizan las
~mas normas en diversos proyectos; se puede sw,tituir esta sección por referencias
:os documentos que contienen la información correspondiente.

Conclusiones
En este capítulo se ha presentado en qué consiste el diseño de un sistema software
los conceptos necesarios para realizar un diseño, corno son:
156 FL-NDA_\IEXTOS DEL DISENO DE SOFTWARE

• Abstracción
■ \ Iodularidad
1

• Refinamiento
• Estructuras de datos
• Ocultación
• Genericida.d
• Herencia
■ Polimorfismo
• Concurrencia
También se presentan notaciones para realizar el diseño de los sistemas software
Tanto desde un punto de vista estático, qué elementos tiene el sistema, corno des<i
un punto de vista dinámico, qué evolución t ienen esos elementos cuando el sistem:
funciona.

En un principio sirven también para mostrar a los lectores qué tipo de cosas
quieren representar en el diseño y qué diferentes alternativas de representación ha-
Se presentan diferentes notaciones.

En el capítulo 6 de este libro se presentará la notación universalmente aceptac.

para el diseño de un sistema software: el lenguaje U\1L.

4 .9. Ejercicios propuestos

l. Póngase 5 ejemplos de abstracciones, de modularidad, de herencia, de ocultad
y de polimorfismo empleadas en la vida diaria.
2. \lodélese mediante abstracciones un autobus urbano.
3. ~fodélese mediante diagramas de J ackson la función factorial.
4. :Y!odélese mediante objetos el autobus del ejercicio 2. Empléese el concepto
herencia.
5. Explíquese brevemente como aplicar la técnica de refinamientos sucesivos er:
descripción de una receta de cocina.
Esta colección de ejercicios propuestos tiene como objeto que el lector se olvide
la programación para obtener los resultados pedidos y se concentre en el <lesa
del diseño de los sistemas.
 apítulo 5

écnicas Generales de Diseño de

oftware

Introducción
El diseño de software es una actividad que requiere tener cierta experiencia pre-
:a. que es difícil de adquirir sólo a través del estudio de las técnicas de diseño. Sin
..:ibargo, un conocimiento detallado de dichas técnicas es esencial para poder abor-
~ la tarea de diseño con perspectivas de éxito.

5.2 . Objetivos
En este capítulo se hace un repaso a las técnicas más importantes de diseño que
... emplean habitualmente. Todas ellas tratan de facilitar la realización del diseño.
Jasadas en una o varias de estas técnicas se han desarrollado metodologías comple-
.as de diseño y en algunos casos tambi6n las correspondientes herramientas CASE
ara diseño asistido por computador. El estudio de cualquiera de estas metodologías
• ieda fuera del alcance de este libro. Además, ceñirse a una metodología concreta
...:nita bastante la capacidad del diseñador a la hora de intentar enfoques alternativos
e diseño. Por otro lado, existen libros enteros dedicados exclusivamente a la presen-
.ación y estudio de cada una de las metodologías y sus correspondientes herramientas.

Con carácter general, todas las técnicas tratan de conseguir como objetivos in-
_¡iediatos del diseño los siguientes:
. La descomposición modular del sistema. Se trata de aplicar el concepto de modu-
laridad y obtener una división del sistema en partes o módulos.

157
158 TÉCNICAS GENER4.LES DE DISEÑO DE SOFTlVA.RE DEt

b La decisión sobre los aspectos de implementación o representación de datos que son

importantes a nivel global. Se trata de que el diseñador decida sobre los algoritmos
y/ o las estructuras de datos fundamentales que se deben utilizar para la realización
del sistema.
Este capítulo comienza estableciendo ciertos requisitos y características que debe
poseer la descomposición modular de un sistema. A continuación se estudian las
técnicas de diseño propiamente dichas, agrupadas en:
■ Diseño funcional descendente
■ Diseño orientado a objetos
■ Diseño de datos
Dentro del segundo grupo se dedica un apartado específico al diseño basado en abs-
tracciones como paso previo al diseño orientado a objetos. Los objetos incorporan
respecto a las abstracciones el mecanismo de herencia y la posibilidad de establecer
relaciones de especialización entre objetos. Finalmente se incluyen los documentos
de diseño de dos ejemplos totalmente desarrollados.

5.3 . D escomposición Modular

Todas las técnicas de diseño están de acuerdo en la necesidad de realizar una
descomposición modular del sistema como actividad fundamental del diseño y para ]
lograrlo es necesario concretar los siguientes aspectos:
■ Identificar los módulos
■ Describir cada módulo
■ Describir las relaciones entre módulos
La diferencia fundamental entre las distintas técnicas de diseño es precisamenc
lo qué se entiende por módulo en cada una de ellas y, como consecuencia, los crite-
rios que se deben emplear para su identificación, la manera en que se describen le-
módulos y las posibles relaciones que se pueden establecer entre ellos.

Con un carácter lo más general posible, se puede decir que un 1nódulo es u:

fragmento de un sistema software que se puede elaborar con relativa independenci
de los demás. La idea básica es precisamente que la elaboración de los diferent ·
módulos se pueda encargar a personas distintas y que todas ellas trabajen en paralel
Con la definición anterior son innmnerables los tipos posibles de módulos Algun ·
de ellos pueden ser los siguientes:
CÓDIGO FUENTE: contiene texto fuente escrito en el lenguaje de prograrn..
ción elegido. Es el tipo de módulo considerado como tal con 1nayor frecue:icia
en el que se hace mayor hincapié en las diferentes técnicas de diseño. Su forma
y organización dependen mucho de la técnica y lenguaje empleados.
 ESC0l\1POSICIÓN J\t! OD ULAR 159

TABLA DE DATOS: Se utiliza para tabular ciertos datos de inicialización,

experimentales o simplemente de difícil obtención. Por ejemplo, una aplicación
de control de procesos en que haya un depósito de forma irregular puede tener
tabulados los volúmenes de líquido en el depósito en función del nivel. Esta
tabla puede ser un módulo específico para cada forma de depósito y cuando se
cambia el depósito sólo es necesario cambiar este módulo.
COXFIGURACIÓ:_\¡: Un sistema se puede concebir para trabajar en entornos
diversos según las necesidades de cada cliente. En estos casos> interesa agrupar
en un mismo módulo toda aquella información que p~rmite configurar el entorno
concreto de trabajo. Esto es lo que sucede con los sistemas operativos que
configuran el número y tipo de periféricos que el cliente adquiere. Otro ejemplo
son los módulos encargados de guardar todos los mensajes de una aplicación
en los distintos idiomas. Un cambio de idioma sólo requiere el cambio de este
módulo.
OTROS: En general, un módulo puede servir para agrupar ciertos elementos del
sistema relacionados entre sí y que se puedan tratar de forma separada del resto.
Por ejemplo, para utilizar el "make" de UNIX es necesario indicar en un módulo
o fichero el número y orden en que se deben combinar los otros módulos para
generar el programa del sistema. También se elaboran por separado los ficheros
de ayuda en línea, los manuales de usuario, etc.
El formato concreto de cada tipo de módulo depende de la técnica, metodología o
.-erramienta utilizados. Por ejemplo, dependiendo del lenguaje de programación, un
::iódulo de CÓDIGO FUEKTE puede ser una única subrutina en un fichero fuente
:-ORTRA:'-J o un tipo abstracto de datos dentro de un MODlJLE de Modula-2.

Un mismo sistema se puede descomponer en módulos de muchas formas diferentes

probablemente cada diseñador argumentará razones evidentes para considerar que
-:i propuesta es la mejor. Casi siempre el objetivo fundamental de cualquier diseño
::; conseguir un sistema mantenible y sólo en casos excepcionales se sacrificará este
bjetivo para lograr una mayor velocidad de proceso o un menor tamaño de código.
z:,·identemente, resulta muy difícil establecer un patrón de medida capaz de indicar
..e una manera precisa y cuantitativa lo buena o mala que es una determinada des-
::omposición para facilitar su mantenimiento. Sin embargo, la experiencia acumulada
~rmite establecer que una descomposición modular debe poseer ciertas cualidades
!llÍnimas como las siguientes para que se pueda considerar válida, a saber:

Independencia funcional
ma-
En la matriz REQUISITOS/ COJvIPOXENTES del final de los documentos ADD
- DDD es necesario indicar qué componente (módulo) se encargará de realizar cada
.mo delos requisitos (funciones) indicados en el documento SRD. Como primer paso
160 TÉCXICAS GEXERALES DE DISEÑO DE SOFTR'"4.RE DES

de la descomposición se puede establecer que cada función se podrá realizar en uc

módulo distinto.

Si el análisis está bien hecho y las funciones son independientes, estos módul~
tendrán independencia funcional entre ellos. Posteriormente y en sucesivos pasos d
refinamiento del diseño se agruparán funciones afines en un rn.ismo módulo o 'Se sub-
dividirán ciertos módulos en otros varios más sencillos. Para llevar a cabo esta tare¡
es necesario tener muy en cuenta los conceptos de abstracción, ocultación, generici-
dad, etc. explicados en el capítulo anterior.

]
Para que un módulo posea independencia funcional debe realizar una función con
creta o un conjunto de funciones afines, sin apenas ninguna relación con el resto d
los módulos del sistema. Aunque resulta absurdo, el mayor grado de independencí
se consigue cuando no existe ninguna relación entre los distintos módulos.

Evidentemente al descomponer un sistema en sus partes o módulos es necesari

que existan ciertas relaciones entre ellos. En todo caso se trata de reducir las rela-
ciones entre módulos al mínimo. Una mayor independencia redunda en una may
facilidad de mantenimiento o sustitución de un módulo por otro y aumenta la p os.-
bilidad de reutilización del módulo.

Para medir de una forma relativa la independencia funcional que hay entre varir
módulos se utilizan fundamentalmente dos criterios: acoplamiento y cohesión. EfiL
criterios fueron sugeridos por Stevf'ns, Constantine y Mycrs en [Stevens74] dentro e
la metodología de diseño estructurado, pero son igualmente validos para realizar ~
descomposición funcional de un sistema utilizando cualquier otro tipo de técnica
metodología.

Acoplamiento

El grado de acoplamiento entre módulos es una medida de la interrelación q

existe entre ellos: tipo de conexión y cornpl~jidad de la interfase. Como escala pa:
medir de una fonna cualitativa el grado de acoplanliento entre módulos se utiliza
siguiente escala:
lVA :-SCOl\IPOSI CIÓN M'.ODUL4R 161

en i Acoplamiento por Contenido

FUERTE 1 Acoplanúento Común
1 Acoplamiento Externo
MODERADO 1 Acoplamiento de Control
1 Acoplamiento por Etiqueta
DÉBIL 1 Atoplamiento dP Datos
1 Sin Acoplamiento Directo

Para manejar esta escala hay que saber el significado de cada tipo de acoplamiento
·uándo se produce. Con ella se trata de conocer lo que se debe hacer para conseguir
Sto acoplamiento débil y lo que se debe evitar para que no exista un acoplamiento
denc ~ rte entre módulos. No se trata de situar con precisión el resultado de la descompo-
- 1ón final de un sistema dentro de esta escala, dado que esto no resulta de especial
terés y además resulta difícil delimitar las fronteras entre los tipos consecutivos.
P r el contrario, el objetivo es que durante el diseño se tenga en cuenta la escala
'OOra buscar descomposiciones con acoplamiento débil o. a lo sumo, moderado. En la
:¡gura 5.1 se muestran gráficamente situaciones que dan lugar a la existencia de un
·oplamiento fuerte entre módulos.

a7 1 A l_, B
~
A 1
Zona
común
zar
e 1 C I D

(a) (b)

Figura 5.1: Acoplamiento fuerte: (a) por c-ontenido; (b) común o externo

El acoplamiento por Contenido se produce cuando desde un módulo se pueden

cambiar los datos locales e incluso el código dP otro módulo. Como se muestra Pn
q~ la figura 5.1 (a). en realidad no existe una ~eparación real entre módulos y hay
par solapes entre ellos. Este Upo de acoplamiento sólo se puede lograr utilizando un
~a: lenguaje emsamblador o de muy bajo rlÍYel y puedt> ) debe ser evitado siempre.
Resulta prácticamente imposible no sólo mantenc'r sino también entender y depurar
162 TÉCNICAS GENERALES DE DISEÑO DE SOFTWARE DES(

un sistema con acoplamiento por contenido. Para el acoplamiento Común se emplea

una zona común de datos a la que tienen acceso varios o todos los módulos del sistema
(Ver figura 5.1 (b) ). En la práctica, esto significa que cada módulo puede estructurar
y manejar la zona común con total libertad sin tener en cuenta para nada al resto
de módulos. El empleo de este acoplamiento exige que todos los módulos estén de
acuerdo en la estructura de la zona común y cualquier cambio adoptado por uno
de ellos afecta al resto que deberían ser modificados según la nueva estructura. Este
tipo de acoplamiento se produce cuando se utiliza el COM:\10N de FORTRAK y
responde a una forma de trabajo en la que la memoria disponible era escasa. La
depuración y el mantenimiento de un sistema con esta descomposición resulta muy
dificil y siempre que se pueda se debe evitar.

~
,._L 7 ~ ,.-L, B
~---' L__ J

Figura 5.2: Acoplamiento moderado

E
En el acoplamiento Externo la zona común de la figura 5.1 (b) está constituid... A
por algún dispositivo externo (disco, sensor, canal de comunicaciones, etc.) al qu
están ligados todos los módulos. En este caso la estructura de la zona común L
impone el formato de los datos que maneja el dispositivo y cualquier modificaciót:
exige el cambio de todos los módulos. Aunque el acoplamiento externo es inevitable
siempre se deben buscar descomposiciones en que los dispositivos externos afecte'"
al mínimo número posible de módulos. La figura 5.2 muestra la situación típica d
un acoplamiento moderado o acoplamiento de Control.

En este caso, una señal (s) o dato de control que se pasa desde un módulo (A
otro (B) es lo que determina la línea de ejecución que se debe seguir dentro de e~r }
último (B). Con este tipo de acoplamiento dentro de un mismo módulo se puede:-
tratar distintos casos o situaciones. Por ejemplo, es razonable que un módulo puec
generar o no una señal acústica al alcanzar un nivel de alarma y en general qllf'
 :.'ESCOMPOSICIÓN 1'10DULAR 163

acoplamiento sirva para solicitar o anular sen·icios adicionales a un determinado

_ódulo. Sin embargo, cuando se trata de utilizar este tipo de acoplamiento para
,rovechar ciertas partes del módulo con fines completamente dispares se suelen
7ear módulos difíciles de entender, depurar, modificar y mantener. Como veremos
::i el próximo apartado, esto da lugar a un módulo con muy poca cohesión en que
"".lS elementos tienen muy poca relación entre ellos.

B e

o E

Figura 5.3: Acoplamiento débil

En la figura 5.3 tenemos una descomposición modular con acoplamiento débil.

Aquí, el acoplamiento se produce sólo a través del intercambio de aquellos datos
~ue un módulo necesita de otro. Si el intercambio se realiza estrictamente con los
m icos datos que se necesitan tenemos un acoplamiento de Datos. Este es el mejor
~ipo posible de acoplamiento.

Cuando en el intercambio se suministra una referencia que facilita el acceso no

:-0!0 a los datos estrictamente necesarios sino también a la estructura completa de
a que forman parte (p.ej., vector, pila, árbol. grafo, etc.) tenemos un acoplamiento
por Etiqueta.
,) a
~stc Ambos tipos de acoplamiento débil son los más deseables en una descomposición
den modular. Con ellos, cualquier modificación en un módulo afecta muy poco o nada
eda al resto. Sin embargo, cuando se utiliza un acoplamiento fuerte es necesario ser muy
que meticuloso y consultar siempre a todo el equipo de diseño e implementación antes
164 TÉCNICA.S GE.VERALES DE DISEJ\TO DE SOFTlVARE DES<

de introducir ningún cambio en las zonas comunes. El equipo en su conjunto debe

analizar todas las consecuencias del cambio propuesto. Además. cada cambio deberá
quedar regjstrado junto con las razones que lo hacían necesario.

Evidentemente el acoplamiento más débil es el que no existe. Este caso es el que

se produce entre los módulos E y B de la figura 5.3 entre los que no existe ningún
tipo de acoplamiento directo. li

C ohesión

El criterio de cohesión es complementario al de acoplamiento. Además de buscar

un acoplamiento débil entre módulos es necesario lograr que el conterudo de cada
módulo tenga coherencia. Cuando se descompone un sistema se debe buscar un obje-
tivo específico para cada módulo. A continuación, se tratará de agrupar en el mismc
módulo todos aquellos elementos afines o que estén relacionados con el objetivo fijadc
para dicho módulo. Por otro lado, se debe tener en cuenta que el número de módu-
los no debe crecer desmesuradamente para no aumentar la complejidad del sistema.
Esto último hace que ciertos elementos "sueltos" se incorporen a un determinadc.
modulo aunque no tengan mucha afinidad con él y que corno resultado se disminuya
la cohesión del módulo. Como escala para meilir de forma cualitativa la cohesión de
un módulo se utiliza la siguiente:

t Cohesión abstraccional
ALTA 1 Cohesión funcional
1 Cohesión secuencial
:\IIEDIA 1 Cohesión ele comunicación
1 Cohesión temporal
BAJA 1 Cohesión lógica
1 Cohesión coincidcntal

La cohesión coincid ental es la peor posible y se produce cuando cualquier rf'la-

ción entre los elementos del módulo es una "pura coincidencia", esto es, no guarda:.
absolutamente ninguna relación entre ellos. El módulo se convierte en un "cajón d
sastre" del que es muy difícil establecer cual es su objetivo concreto. La existencia d
este tipo de módulos inilica que no ha sido realizada ninguna labor de diseño y q11
simplemente se ha efectuado un troceado del sistema agrupando líneas de código e!
cien en cien.

La cohesión lógica se produce cuando se agrupan en un mismo módulo elemcntc..

que realizan funciones similares desde un punto de vista de usuario. Este es el cas
 --COldPOSICIÓN lHODULAR 165

módulo o biblioteca de funciones matemáticas en el que coseno, raíz cuadrada,

--..;I1

_ itrno, etc. se agrupan debido a su carácter de herramientas matemáticas que el

io prefiere mantener unidas. Esta misma cohesión es la que existe en los mó-
os de entrada/ salida o cuando se diseña un módulo para el manejo de todos los
ajes de error que se producen en el sistema.

Cna cohesión temporal es el resultado de agrupar en un mismo módulo aquellos

::mentos que se ejecutarán en un mismo momento. Esta es la situación que se pro-
~ce en la fase de inicialización o finalización del sistema en que necesariamente se
ben .ªrrancar. 0 "parar"dispositivos completamente heterogéneos: teclado, pantalla,

La cohesión BAJA debe evitarse prácticamente siempre. De hecho, tan sólo se

...dría justificar una cohesión lógica o temporal y solamente en los casos dados como
Pmplo u otros semejantes.

Por cohesión de comunicación se entiende aquella que se produce cuando todos los
meneos del módulo operan con el mismo conjunto de datos de entrada o producen
mismo conjunto de datos de salida. Esto se da, por ejemplo cuando un módulo
,-a!iza operaciones diversas, pero siempre con la misma tabla de datos, y también
.1ando un módulo de exportación de información empaqueta distintas da.ges de da-
s pero generando siempre el mismo fichero de salida.

La cohesión secuencial es la que se produce cuando todos los elementos del

ódulo trabajan de forma secuencial. Esto es, la salida de un elemento del módulo
- la entrada del siguiente de una manera sucesiva. Por ejemplo, un módulo para
-tlcular el valor medio y también a continuación la desviación típica de un conjunto
~e valores tiene una cohesión secuencial.

Con una cohesión f\.1EDIA se puede reducir el número de módulos. Sin embargo,
-sto no se debe realizar a costa de aumentar el grado de acoplamiento entre módulos.
Por ejemplo, no se deben unir dos módulos con acoplamiento DÉBIL para obtener
la- ..!DO único con acoplamiento :tvIODERADO, en el que se requiere pasar una serial

an ;>ara indicar con cual de los dos antiguos submódulos se quiere trabajar.
de
de En un módulo con cohesión funcional cada elemento está encargado de la rea-
ue jza.ción de una función concreta y específica. Con las técnicas de diseño funcional
::le descendente este nivel de cohesión es el máximo que se puede lograr dentro de un
módulo. Por tanto, con estas técnicas el objetivo será que todos los módulos tengan
una cohesión funcional.
os
so
166 TÉCXICAS GESERALES DE DISE}\'O DE SOFTl-VARE DEt

Con la técnica de diseño basado en abstracciones, un módulo con cohesión funcio- Cor.

nal sería una abstracción funcional. La cohesión abstraccional se logra cuando se I

diseña un módulo como tipo abstracto de datos con la técnica basada en abstraccio- am
nes o como una clase de objetos con la técnica orientada a objetos. En ambos casos. :on1
se asocian un cierto contenido (atributos) u organización de datos con las con-espon- trc
dientes operaciones (métodos) encargados de su manejo. Independientemente de la
técnica empleada, una cohesión ALTA debe ser el objetivo que se debe perseguir en
cualquier descomposición modular. Con ello. se facilitará en gran medida el mante-
nimiento y la posible reutilización de los módulos así diseñados.

Para conocer, y si es necesario, mejorar la cohesión de un módulo se sugiere rea-

lizar una descripción de su comportamiento [Stevens7-1]. ,t\. partir de la descripción.
se puede establecer el grado de cohesión de acuerdo con los siguientes criterios:

A Si la descripción es una frase compuesta que contiene comas o más de un verbo

es muy probable que se esté incluyendo más de una función y la cohesión será 1
1.1EDIA de tipo secuencial o de comunicación.

B Si la descripción contiene palabras relacionadas con el tiempo, tales como: "pri-

mero·'. "después''. '·entonces". ··cuando", "a continuación'·, "al comenzar'', etc. la
cohesión será de tipo temporal o secuencial.
r
'-
C Si la frase de la descripción no se refiere a algo específico a continuación del verbo.
es muy probable que tengamos una cohesión lógica. Por ejemplo, ªescribir todü::'
los mensajes de en-or·· o ··calcular todas las funciones trigonométricas".

D Cuando se utilizan palabras tales como: '·inicializar'·. ·-preparar'', '·configurar'', etc.

la cohesión será probablemente de tipo temporal.

Estos criterios serán siempre orientati\·os debido tanto a las deficiencias intrínsecas
propias de cualquier descripción que se realiza en lenguaje natural como también .1
la. dificultad de delimitar las fronteras entre los distintos niveles de cohesión. Así, con
una descripción detallada: "medir temperatura. humedad y presión" se puede pensa:-
en una cohesión secuencial y con una más concisa: 11 medir sensores.en una cohesiot.
funcional. Está claro que la palabra ·'sensores·' resulta más imprecisa que las tres -
las que sustituye. Por otro lado. el diseñador es el encargado de matizar la necesida.
de un tratamiento específico para cada tipo de sensor o si todos los sensores se deber:.
tratar como un único tipo abstracto de datos. Esto último daría lugar a una cohesi'"'
abstraccional. En resumen. la descomposición modular con una mayor independencu.
funcional se logra con un acoplamiento DÉBIL entre sus módulos y una cohesi
ALTA dentro de cada uno de ellos.
 ~ ESCOlv.CPOSICIÓN :VIODULA.R 167
ARE

:lCIO-
Comprensibilidad
lo se La dinámica del proceso de diseño e implementación de un sistema hace que los
ccio- :ambios sean más frecuentes de lo que sería deseable. Posteriormente, los cambios
!l.sos. ontinúan durante la fase de mantenimiento hasta que se sustituye el sistema por
pon- tro nuevo. A menudo los cambios deben ser realizados por personas que no parti-
le la -iparon ni en el diseño ni en a implementación. Para facilitar e incluso posibilitar
1r en t:Stos cambios es necesario que cada módulo sea comprensible de forma &islada. Ko
rnte- ~iene ,sentido que a veces el esfuerzo de comprensión de un módulo sea mayor que el
tlecesario para su realización.

rea- El primer factor que facilita la comprensión de un módulo es su independencia

~ión. funcional. Ya hemos visto que con una cohesión ALTA y un acoplamiento DÉBIL
d módulo tiene menor dependencia del resto del sistema y por tanto será más fácil
Pntender su funcionamiento de manera aislada. Sin embargo, esto no es suficiente y
es necesario además cuidar especialmente los siguientes factores:
erbo
será l. IDENTIFICACIÓN: Una elección adecuada del nombre del módulo y de los
nombres de cada uno de sus elementos facilita mucho su comprensión. Los nom-
bres deben reflejar de manera sencilla el objetivo de la entidad que representan.
'pri- l,;n buen ejemplo de la dificultad de compresión que representa la utilización de
~- la una identificación inadecuada son los libros o manuales técnicos ,:traduztados"
con un total desconocimiento del léxico utilizado habitualmente.
2. DOCU~!ENTACIÓN: La labor de documentación de cada módulo y del sistema
rbo.
)dos en general debe servir para facilitar la compresión, aclarando todos aquellos
aspectos de diseño o implementación que por su naturaleza no puedan quedar
reflejados de otra manera. Hay que tener en cuenta que si la documentación
etc.. es muy prolija y reiterativa se corre el riesgo de que no se lea. En cada diseño
se deben establecer normas y convenios de documentación que eviten estos
problemas. Estas normas formarán parte del Documento de Diseño Detallado
ecas (DDD)
én a 3. SINIPLICIDAD: Las soluciones sencillas son siempre las mejores. Un algoritmo
con complicado es muy difícil de entender, depurar y modificar en el caso de que
usar sea necesario. Un esfuerzo fundamental del diseñador debe estar dedicado a
sión simplificar al máximo las soluciones propuestas. Sólo en casos muy excepcionales
es a (tiempo o memoria escasos) , se puede sacrificar la simplicidad de un algoritmo
.dad por otro más sofisticado y dificil de comprender .
:ben
sión 5.3.2. Adaptabilidad
uc1a
sión Al diseñar un sistema se pretende resolver un problema concreto y se trata de
obtener prácticamente un "traje a la medida". Por tant o, la descomposición modular
168 TÉCNIC.4S GE.VERA.LES DE DISEÑO DE SOFT\VARE TÉ

estará muy mediatizada por el objetivo concreto del diseño. Esto dificulta bastante
la adaptabilidad del diseño a otras necesidades y la posible reutilización de algunos
de sus módulos. Sin embargo, es inevitable que un sistema en mayor o menor medida
se adapte a los nuevos requisitos que va imponiendo el «cliente".

Independencia funcional y comprensibilidad son dos cualidades esenciales que de-

be tener cualquier diseño para posibilitar su adaptabilidad. No se puede abordar la
tarea de adaptación de un diseño con un acoplamiento Fl;~RTE entre sus módu-
los, con módulos de BAJA cohesión, mal documentados y difíciles de comprender.
Con estas premisas, resulta más aconsejable y ventajoso realizar un diseño com-
pletamente nuevo que elimine todas las deficiencias del que se pretende adaptar.
Desgraciadamente las adaptaciones suelen ser múltiples y variadas a lo largo de la
vida del sistema. Así, es necesario cuidar otros factores adicionales para facilitar la
adaptabilidad y de ellos destacaremos los siguientes:

l. PREVISIÓ:-J: Resulta rrmy complicado prever que evolución futura tendrá un

determinado sistema. Sólo la experiencia previa nos puede indicar que partes de
sistemas semejantes han sido más susceptibles a cambios o adaptaciones. Por
ejemplo: listados, presentaciones en pantalla, etc. En el diseño, estas partes se
deberán agrupar en módulos con un acoplamiento lo más débil posible con el
resto de los módulos del sistema. Así, las adaptaciones se podrán realizar COL
correcciones que sólo afectarán a los módulos previstos. Si la adaptación exige
una modificación de la descomposición modular resultará tremendamente más
complicada y costosa de realizar.
2. ACCESIBILIDAD: Antes de abordar la nueva adaptación de un sistema es nece-
sario conocerlo con la suficiente profundidad. Previamente a cualquier adapta-
ción es imprescindible estudiar la estructura global del sistema y todos aquello:-
detalles a los que afecte de manera fundamental la adaptación. Este trabajo sólc
es posible si resulta sencilla la accesibilidad a todos los documentos de especifi-
cación: diseño e implementación. Esto requiere una organización minuciosa qut
en la mayoría de los casos sólo es posible si se emplea una herramienta CASE
En este sentido hay que señalar las posibilidades que ofrecen los entornos de di-
seño y lenguajes de programación basados en el empleo de objetos. Todos esto-
entornos mantienen una biblioteca de objetos de fácil accesibilidad y graci~
al mecanismo de herencia resulta relativamente sencilla su adaptabilidad. Est-
disponibilidad permite realizar prototipos de nuevos sistemas como adaptaciór.
de otros ya existentes en un plazo 1nuy breve de tiempo.
3. CONSISTENCIA: Cuando se realizan adaptaciones sucesh·as es vital mantent:
la consistencia entre todos los documentos de especificación, diseño e implemen-
tación para cada nueva adaptación. La tentación de modificar exclusivamem
los programas fuentes sin actualizar ningún otro documento da lugar a un cao-
 ~ÉCNICAS DE DISEÑO FUNCIONAL DESCE1VDE:VTE 169

en el que es imposible saber a que adaptación pertenece cada nueva versión de

módulo y en consecuencia nunca se podrán abordar posteriores adaptaciones.
Existen herramientas para el "control de versiones y configuración" que per-
miten mantener automáticamente la consistencia de cada adaptación. En los
entornos o lenguajes orientados a objetos no existen este tipo de herramien-
tas y es obligatorio imponer una disciplina ferrea dentro de la biblioteca de
objetos para mantener la consistencia de las distintas adaptaciones. Periódica-
mente se debe revisar la biblioteca, eliminar objetos duplicados, reestructurar
la organización de objetos, etc.

5.4. Técnicas de diseño funcional descendente

En este grupo de técnicas se incluyen todas aquellas en que la descomposición del
•·~tema se hace desde un punto de vista funcional, es decir, se atiende fundamental-
:::iente a la función o funciones que ha de realizar el sistema: que se van expresando
oco a poco mediante funciones más sencíllas, las cuales se encomiendan a módulos
eparados. De esta manera los módulos corresponden precisamente a funciones con-
::-etas que se han de realizar en el sistema. Desde el punto de vista de la codificación,
ada módulo corresponde esencialmente a un subprograma. Por esta razón estas téc-
icas de diseño conducen a estructuras modulares que pueden implementarse bien
asi con cualquier lenguaje de programación, incluso aquellos como FORTRAN o
.'.:'OBOL que carecen de facilidades para la implementación de tipos abstractos de
~atas.

ece-
5.4. 1. Desarrollo por refinamiento progresivo
Esta técnica corresponde a la aplicación en la fase de diseño de la metodología
·e programación conocida como programación estructurada, [Dijkstra68], [Dahl72l
- que condujo a la construcción de programas mediante refinamientos sucesivos
-\"irth71].

La programación estructurada recomienda emplear en la construcción de progra-

=:las sólo estructuras de control claras y sencillas. con un único punto inicial y un
mico punto final de ejecución. En particular son la secuencia, la selección entre al-
. 'rnativas: y la iteración.

La construcción de programas basada eu el concepto de refinamiento, ya expues-

'> en el capítulo anterior, consiste en plante-ar inicialmente el programa como una
ten- peración global. única, e irla descomponiendo poco a poco en función de otras ope-
mtc --i.ciones más sencillas. Cada paso de descomposición consistirá en refinar o detallar
:ao:- operación considerada en ese momento según una estructura de las mencionadas
 TÉ(
170 TÉCNICA.$ GENERA.LES DE DISEÑO DE SOFTWARE

par;
anteriormente, cuyos elementos serán a su vez operaciones. Por ejemplo, considere-
mos un programa para obtener las raíces de una ecuación de segundo grado. Los
primeros refinamientos podrían ser:

Obtener raíces - >

Leer coeficientes
Resolver ecuación - >
Calcular discriminante
Calcular raíces - >
SI el discriminante es negativo ENTONCES
Calcular raíces complejas
SI-NO
Calcular raíces reales
FIN-SI
Imprimir raíces

Obtener
raíces

•'

Leer Resolver Imprimir

coeficientes ecuación rafees

Figura 5.4: Diseño por refinamiento

La aplicación de esta técnica a la fase de diseño consiste en realizar sólo lo-:

primeros niveles de refinamiento, asignando a módulos separados las operacion~
parciales que se van identificando. En el ejemplo anterior, la descomposición modula:
del programa resultante del primer refinamiento podría ser la que se indica en la figura.
5.4. A nivel de codificación, estos módulos separados se invocarían, tal como se h
dicho: como subprogramas. El paso de la estructura de refinamientos a estructur~
modular es inmediata: ya que los refinamientos se basan precisamente en la aplicaciór.:
de estructuras de control en el programa.

Programación estructurada de Jackson

La técnica de Programación EstrucLurada de Jackson (en inglés JSP: Jackso

Structured Programming) aparece descrita en IJ ackson 75]. Esta técnica sigue estri -
tamente las ideas de la programación estructurada en cuanto a las estructuras r -
comendadas (secuencia, selección, iteración ) y el ml>todo de refinamientos sucesi,· ,
 TÉCNICAS DE DISERO FUNCIONAL DESCEIYDESTE 171
lVARE

:1ara construir la estructura del programa en forma dE>scendente. Se utilizan los dia-
sidere-
.o. Los gramas específicos descritos en el capítulo anterior para representar tanto la estruc-
~ura del programa como la de los datos con los que opera. Ko hay que confundir esta
=::ictodología de diseño de programas con la denominada JSD: Jackson Systcm Deve-
opment , del mismo autor, descrita en [Jackson83l, y que presenta algunas analogías
,:on las técnicas de desarrollo orientadas a objetos.

La aportación principal de la programación estructurada de Jackson frente a

.a metodología general de programación estructurada está en las recomendaciones
para ir construyendo la estructura del programa, que debe 1 hacerse similar, en
.'.:> posible, a las estructuras de los datos de entrada y salida. Esta idea es muy
_propiada para las aplicaciones denominadas antiguamente de "proceso de datos",
4ue solían realizarse en modo "batch" y que en la actualidad han sido englobadas
-:!entro de los denominados "sistemas de información", que operan con frecuencia en
forma interactiva. La técnica original de JSP se basa en los siguientes pasos:

l. Analizar el entorno del problema y describir las estructuras de datos a procesar.

2. Construir la estructura del programa basada en las estructuras de datos.

3. Definir las tareas a realizar en términos de las operaciones elementales disponi-

bles, y situarlas en los módulos apropiados de la estructura del programa.

Como técnica de diseño los pasos significativos son los dos primeros, mientras que
el tercero corresponde más bien a la fase de codificación. Ilustraremos esta técnica
:nediante un ejemplo, consistente en un programa para "justificar" un texto, es decir,
reagrupar las palabras en líneas e intercalar los espacios apropiados para que las
Jneas del texto se ajusten a los márgenes establecidos. En este ejemplo se pretende,
lo los
además, respetar la forma de separar los párrafos en el texto original. Si consideramos
;iones
Pl texto inicial:
dular
figura Texto de entrada
se ha
Este párrafo y los dos siguientes son un
ctura ejemplo del texto que se
pretende ajustar. Este es el primer
ación párrafo.
Y este es el segundo párrafo, que está
separado del anterior
sólo por el sangrado.
Este tercer ~árrafo no tiene sangrado, y la
separación viene dada
por una línea en blanco.
c:kson
stric-
ts re-
se trataría de obtener como resultado algo similar a:
isivos
172 TÉCNIC...\S GE1\"ERALES DE DISEÑO DE SOFTWARE TE

Texto de salida
El
Este párrafo y los dos siguientes son un ejemplo
del texto que se pretende ajustar. Este es el
primer párrafo.
Y este es el segundo párrafo, que está
separado del anterior sólo por el sangrado.

Este tercer párrafo no tiene sangrado, y la

separación viene dada por una línea en blanco.

[
En el PASO 1 del diseño identificamos las estructuras de los datos de entrada v
salida. En el texto de entrada los espacios en blanco y los saltos de línea sólo soL
significativos en la separación entre párrafos. Podríamos describir la estructura com
una iteración de elementos, bien palabras o separadores.

texto de entrada = [ separador de párrafo 1 palabra ]

El diagrama equivalente aparece a la izquierda de la figura 5.5.

texto de salida, la escritura ha de hacerse al completar las líneas y justificadas, er.
caso de que no sean la últüna del párrafo. Además se usan líneas en blanco coru
separación. La estructura de salida podría ser una iteración de líneas, cada una dt
tipo apropiado.

Texto de Telttode
entrada salida

Token• línea•

o . o o
Separ. de Palabra
o linea Línea O Linea en
párrafo ajustada finol blanco

ENTRADA SALIDA

Figura 5.5: Ejemplo de estructuras de ent.rada y salida I

!lRE TÉCNICAS DE DISElVO FUNCIONAL DESCESDE_VTE 173

texto de salida = [ línea ajustada

1 línea final 1 línea en blanco ]
El diagrama de estructura aparece a la derecha de:> la figura .

Te:xto de Te®de (A} (A)

entrada (A) salida

Linea • (BJ Párn,fo* (B)

Sepa.r de
o
Palabras
J)Mrafo

Ia'" (C) (DJ (C) (D) {E) (C) (DJ (E)

son • L~a en • l.ínea •
Palabra
btsnco o¡ustod.

ENTRADA PROCESO SALIDA

Figura 5.6: Ejemplo de diseño usando .JSP

, en
,rno El problema ahora es encontrar) en el PASO 2, una estructura del programa que
del se ajuste al mismo tiempo a las dos estructuras de datos: la de entrada y la de salida.

En este caso lo que se puede hacer es buscar una un idad superior de información
que englobe a las unidades de datos de la entrada y de la salida, y usarla como uni-
dad de t ratamiento en el programa. Esta unidad superior sería el párrafo, que podría
adaptarse a ambas en la forma:

texto = { párrafo }
párrafo de entrada = separador de párrafo + { palabra }
párrafo de salida = { línea en blanco }
+ { línea ajustada } + línea final
Con esta perspectiva podemos redefinir las estructuras de los datos de entrada y
de salida, tal corno se indica en la figura 5.6. Ahora ya se puede derivar con relativa
facilidad la estructura del programa, mediante un sencillo análisis de las operaciones
a realizar con cada elemento de datos.

La e:>-Structura resultante podría ser la represe:>ntada en el centro ele la figura 5.6,

donde se han señalado con las letras (A), (B ), (C), (D) y (E) los elementos corres-
pondientes de las distintas estructuras. La op<'rarión de inicio de párrafo procesa el
separador de párrafo en la entrada y genera las líneas en blanco a la salida. La ope-
ración de formar líneas lee las palabras del texto de entrada y las agrupa en líneas.
174 TÉCNICAS GKI\-ERALES DE DISEÑO DE SOFTtV.4RE IÉC

justificando e imprimiendo las línea<; que ¡,e llenen. La operación de terminar párrafo
imprime la línea final, sin ajustar.

5.4.2. Diseño estructurado

Esta técnica de diseño [Yourdon79J.lPage-Jones80] es el complemento del llama-

do análisis estructurado. Ambas técnicas coinciden en el empleo de los diagramas de
flujo de datos (DFD), descrita en el capítulo anterior, como medio fundamental de
representación del modelo funcional del sistema. Para el diseño se emplea la notación
de diagramas de estructura, también descrita en el capítulo anterior.

La tarea de diseño consiste en pasar de los DFD a los diagramas de estructura. La

dificultad a superar al hacer el diseño reside en que no basta con asignar módulos a
procesos o grupos de procesos relacionados entre sí, sino que hay que establecer una
jerarquía o estructura de control entre los diferentes módulos, que no está implícita
en el modelo funcional descrito mediante los diagramas de flujo de datos.

Por ejemplo, considerando un caso muy sencillo con sólo dos operaciones o proce-
sos (Figura5.6 (A), cada uno de los cuales materializamos como un módulo separado.
tenemos tres posibilidades de organización modular según cómo establezcamos la je-
rarquía de control entre ellos.

X z

(A)

UNO DOS
Módulo de
... leer x._ ...escribir z Coordinación

DOS UNO
UNO DOS
•. escribir z ...leer x...
-leer x ... ... escribir z

(B) (C) (O)

Figura 5.7: Ejemplo de Estructuras alternativas m

 TÉC1':"ICAS DE DISEÑO FUNCIONAL DESCENDEXTE 175

na- Ruj.o de Tr-.nsformlC:iOf'I

Rujo de Entrada Flujo da Sa1id.a:

:ión

,ce- Figura 5.8: Diseño basado en el flujo de transformación

do.
Je-

En la figura 5.7-B el módulo de la primera operación lee los datos e invoca a la

segunda con los valores intermedios. En el caso de la figura 5. 7-C es el módulo de la
segunda operación quien tiene el control sobre la primera. En el último caso, de la
figura 5.7-D) se ha introducido un módulo adicional, llamado módulo de coordina-
ción, para llevar el control de los otros dos.

Para establecer una jerarquía de control razonable entre las diferentes operacio-
nes descritas en los diagramas de flujo de datos, la técnica de diseño estructurado
recomienda hacer ciertos análisis del flujo de datos global.

En concreto se recomienda realizar los análisis denominados de flujo de transfor-

mación y de flujo de transacción. Estos análisis pueden realizarse con mayor facilidad
si se modifica parcialmente la estructura jerárquica de los diagramas de flujo de datos,
construyendo un único diagrama con todos los procesos contenidos en los primeros
niveles de descomposición, y prescindiendo de los almacenes de información.
 176 TÉCNICAS GENERALES DE DISENO DE SOFTlVARE

1 --------------------------,

'' ''
' '

/ :
'
'
1-------ol

1 ------------------- ------- 1
,__.._
: ---+

TrWlUIC.ÓOMS

,___ _ _...., 91 >-------+

,
:
' '
1 -------------- -- 1

Í
,
~f'!VOCH
lt'WISICC:lotl
: -------------------------------------~
''
¡
'
:'
:
--------------------------------------~'

Figura 5.9: Diseño basado en el flujo de transacción

•
.
El análisis de flujo de transformación consiste en identificar un flujo global de
información desde los elementos de entrada al sistema hasta los de salida, tal como
se indica en la parte superior de la figura 5.8. Los procesos se deslindan en tres regio-
nes, denominadas de flujo de entrada, de transformación, y de salida. Para obtener
la estructura modular del programa se asignan módulos para las operaciones del
diagTama (o grupos de ellas) y se añaden módulos de coordinación que realizan el
control de acuerdo con la distribución del flujo de transformación, tal como se indica
en la parte inferior de la misma figura. Si se considera conveniente, a cada una de
las partes se le pueden aplicar a su vez las técnicas de análisis de flujo, para refinar
aún más la estructura del sistema.

El análisis del flujo de transacción es aplicable cuando el flujo de datos se pued<"

descomponer en varias líneas separadas, cada una de las cuales corresponde a una
función global o transacción distinta, de manera que sólo una de estas líneas, en ge-
neral, se activa para cada entrada de datos de tipo diferente. En la parte superior de
la figura 5.9 se representa un diagrama de flujo con estas características. El análisis
consiste en identificar el llamado cf'ntro de transacción, a partir del cual se ramifi-
can las líneas de flujo, y las regiones correspondientes a cada una de esas líneas o
transacciones. La estructura modular del sistema puede derivarse de la distribución
del flujo identificada en este análisis, tal corno se indica en la parte inferior de la
misma figura. Si se considera apropiado, a cada una de las transacciones se le puede
'E ~CNICAS DE DISEÑO FUNCIONAL DESCE.l\'DESTE 177

-.>licar por separado el análisis de flujo de transformación y/ o de transacción, para

finar aún más la estructura del sistema.

fltN di' IK't«

Figura 5.10: Gestión de biblioteca. Diseño inicial

le
10
)-

91
~l
:a
le Ejemplo: Sist e ma de gestión de biblioteca
tr

Se describe aquí como ejemplo un posible diseño del caso práctico especificado
.e en el capítulo 3 con el nombre de "Sistema de Gestión de Biblioteca", empleando la
a técnica de diseño estructurado, por ser la más ajustada a la forma de especificación
mediante diagramas de flujo de datos usada en el SRD de este ejemplo. El primer
e paso será analizar los tipos de flujo de datos que circulan por el sistema. Podemos
.s rcformular el diagrama de primer nivel DFD.O prescindiendo, para simplificar, de
L- los almacenes de información, en la forma que se indica en la figura 5.10. En este
O diagrama se aprecia claramente una estructura de transacciones, en la que el centro
n de transacción no se corresponde con un proceso concreto, sino simplemente con la
a ramificación del flujo de órdenes de entrada. De aquí podemos derivar un primer
e nivel de estructura del sistema tal como el que aparece en dicha figura.
178 TÉCNICAS GEJ\'ERALES DE DISENO DE SOFTVV.ARE TÉ

Gestión de
-
o ...~

--
biblioteca

Gestión de Gestión de Gestión de

Búsquedas
ca,
libros lectores préstamos ,. t
os
Buscar
....
Alta - Alta L-
Préstamo ~

material
1ec
:Ull
..... listar ~
Listar
.... Buscar por
....
Baja _ - Baja L-
Devolución
autor

'- Compactar '- Compactar Listar Buscar por

Anular ..... Anular ~ - morosos
'-
título
baja baja

Actualizar 1-
Buscar
1-

materias lector Préstamos

L-
Actualizar ~
Actualizar ~

de lector

Figura 5.11: Diseño final del sistema de gestión de biblioteca

El proceso puede repetirse con cada uno de los subsistemas (gestión de libros) de
lectores) etc ... ), para refinar aún más la estructura del sistema. El análisis de cada
subsistema nos vuelve a mostrar un esquema de flujo de transacción, ya que cada
uno de ellos es una agrupación de funciones más sencillas, que se han asociado el!
un mismo proceso o diagrama por la afinidad de los datos sobre los que operan. E,
inmediato. por tanto, llegar a la estructura final de la figura 5.11, en que aparece ur:
segundo nivel de descomposición del sistema.

5.5. Técnicas de diseño basado en abstracciones

Estas técnicas de diseño surgen cuando se identifican con precisión los conceptc•
de abstracción de datos y de ocultación descrit os en el capítulo anterior. La idc-
general es que los módulos se correspondan, o ~ien con fu nciones, o bien con tipc
abstractos de datos. Las estructuras modulares resultantes pueden implementaf'-o
bien con lenguajes de programación que tengan facilidades para implementar a~
tracciones de datos, tales como :VIodula-2 o Ada, y en menor medida con lenguaj
como Pascal o C. Por supuesto, pueden también implementarse con lenguajes e
programación orientados a objetos. que poseen aún más facilidades. En todo caso r"
sultan menos apropiados los lenguajes como FORTRAK o COBOL que sólo cuenta=:
con módulos de tipo subprograma.
 CNICAS DE DISENO BASADO EN ABSTR.ACCIOSES 179

Descomposición modular basada en abstracciones

Esta técnica aparece descrita en lParnas72] y [LiskoY80]. Considerada como técni-

de programación, consiste en ampliar el lenguaje existente con nuevas operaciones
-ipos de datos, definidos por el usuario , de forma que se simplifique la escritura de
, niveles superiores del programa. Considerada como técnica de diseño, consiste en
t'<licar módulos separados a la realización de cada tipo abstracto de datos y cada
::...::ición importante.

Para la representación de la estructura modular basada en abstracciones, usare-

os la notación introducida en el capítulo anterior, basada en la propuesta inicial
_ [Liskov80]. Esta técnica de diseño puede aplicarse tanto en forma descendente
mo ascendente. En forma descendente puede considerarse como una ampliación
e la técnica de refinamiento progresivo, en que al realizar un refinamiento se plan-
.,.ª corno alternativa, además de su descomposición, el que la operación a refinar se
fi na separadamente como abstracción funcional, o bien como operación sobre un
po abstracto de datos. En forma ascendente se trata de ir ampliando las primiti-
a.5 existentes en el lenguaje de programación y las librerías asociadas con nuevas
peraciones y tipos de mayor nivel, más adecuados para el campo de la aplicación
ne se está diseñando. En muchos casos puede aplicarse simultáneamente de ambas

Volviendo al ejemplo de la ecuación de 2° grado, usado en la sección 5.4.1, pode-

::nos identificar los tipos abstractos correspondientes a un número complejo, y a una
,>Cuación de 2° grado. Sabiendo que la fórmula que da las raíces es:

Ax
2 C
+ B x + = O =;, X =
-B ± J (B2
A
- 4AC)
2
podemos definir sobre dichos tipos abstractos las siguientes operaciones necesarias
para la aplicación:

Ecuación de 2° grado: Número complejo:

Leer ecuación Escribir
Escribir ecuación Sumar, Restar, etc
Obtener raíces Raíz cuadrada

Para obtener las raíces se usarán _las operaciones definidas sobre números comple-
jos. La estructura modular del progran1a podría la representada en la figura 5.12
180 TÉCNICAS GE!\-ERA.LES DE DISEÑO DE SOFT\iv'ARE TJ

D]
Programa
dt
principal rn

o
ne

Ecuación
E
22 grado d,

Número
complejo

Figura 5.12: Ejemplo de diseño basado en abstracciones

5.5.2. Método de Abbott

8n la descripción de la descomposición modular basada en abstracciones del apa:--
tado anterior no se ofrece ninguna guía, salvo el sentido común, para ir reconociend
aquellos elementos del modelo del sistema que son buenos candidatos para ser con-
siderados como abstracciones; sean funciones o tipos abStractos de datos.

En [Abbott83] se sugiere una fonna metódica de conseguirlo a partir de las <l~

cripciones o especificaciones del sistema hechas en lenguaje natlual. De hecho e~
técnica puede aplicarse también, y con mayor precisión, a las descripciones más for-
males, que emplean notaciones precisas y no sólo lenguaje natural.

La idea es identificar en el texto de la descripción aquellas palabras o términos q

puedan corresponder a elementos significativos del diseño: r.ipos de datos, atribut
y operaciones, fundamentahnenc;e. Los tipos de datos aparecerán como sustanti,
genéricos, los atributos como sustantivos, en general, y las operaciones como verb.
o bien como nombres de acciones. _.\lguno::; a<ljclivos pueden también sugerir valo
de los atributos.
 ~CNICAS DE DISEÑO BASADO EN ABSTR.4CCJO:'.'ES 181

Se puede comenzar subrayan<lo en el texto todos los términos de alguno de los

pos indicados, que sean significativos para la aplicación. y establecer dos listas: una
e nombres y otra de verbos u operaciones. El siguiente paso es reorganizar dichas lis-
s extrayendo los posibles tipos de datos, y asocián<lolcs sus atributos y operaciones.

Al reorganizar las listas hay que depurarlas eliminando los términos irrelevantes
;-;inónimos, y completarla con los elementos implícitos en la descripción, pero que
o se mencionaban expresamente.

Podemos ilustrar esta técnica aplicándola al ejemplo del programa de ajuste de un

exto, ya utilizado en este capítulo. Comenzaremos con una especificación informal
el mismo, en la que subrayamos los elementos significativos:

AJUSTE DEL :\-1ARGE.t\ DERECHO DE l,;,i TEXTO - Especificación informal

Se trata de desarrollar un programa que permita obtener te:x.1:os impresos con PI
margen derecho bien ajustado, al mismo tiempo que se recomponen las lineas pa-
ra que contengan tantas palabras como quepan en ellas.
El programa op_erará a partir de un texto de entrada sin ajustar y sin limitaciones de
ma.rgen, el cual deberá ser impreso a la salida en forma ajustada.
El ajuste se hará de manera que se respete la sepa.ración en párrafos del
texto de entrada Dicha separación vendrá marcada por líneas en blanco y/ o sangrado.
Esto quiere decir que la primera línea de un párrafo debe seguir a una línea en blanco o
bien empezar por algún espacio en blanco. Las líneas segunda y siguientes del párrafo
empezarán en la primera columna, y no irán precedidas de ninguna línea en blanco.
La forma de separar párrafos en el texto inicial debe respetarse en la salida. Esto
quiere decir que las líneas en blanco entre párrafos deben reproducirse en la salida.
así como el sangrado sí lo hay.
Todas las líneas de salida, excepto las que sean final de párrafo, deberán ser ajustadas
al margen derecho intercalando espacios en blanco entre las palabras. La posición del
margen derecho será un parámetro global del programa.

En este marcado ya se ha omitido destacar ciertos elementos de información, ta-

les como "... primera lfnea de un párrafo ... segunda y sigiúentes ... primera columna ...",que se
refieren a las líneas del texto de entrada, cuya organización, como ya se dijo en un apartado
anterior, no es significativa para el result.ado a generar. salvo en lo referente a la separación
entre pánafos.

A partir de este marcado elaboramos w1a doble lista. con los elementos correspondientes
>re- a datos y a operaciones. En estas listas se han man-arlo con el signo ·'=" los términos con-
siderados sinónimos. También se han distinguido. comentándolos, los términos homónimos
pero con diferente significado.
182 TÉCNICAS GENERALES DE DISEÑO DE SOFTWARE TÉ

DATOS OPERACIO~ES
textos impresos ajustado
- salida = ajustar
margen derecho - ajuste
= margen - intercalando (espacios)
palabra.e; recomponen
texto de entrada = texto inicial quepan
separación en párrafos ser impreso
- forma de separar párrafos
líneas en blanco
sangra.do
- espacio en blanco
(comienzo de línea)
párrafo
líneas de salida
final de párrafo
espacios en blanco
(entre palabras de salida)

Ajustar

o g
dat
ha~
Párrafo ~o
ab:
:,,i

Palabra

Figura 5.13: Programa de ajuste: diseño mediante abstracciones

A partir de estas listas inicialeR hay que elaborar la descripción de abstraccione-c

indicando para cada tipo abstracto de datos cuáles son sus atributos y sus operaC'I ~
nes. En esa lista se pueden ar1adir los elementos necesarios no incluidos en las list-
iniciales. En este caso SE' podría tener: e;
IÉC.VIC.4..S DE DISEÑO BASADO EN A.BSTR.ACCIOSES 183

DATO: Palabra DATO: Sq>ara<lor ele párrafo

.\tributos: .'\.tributos:
caracteres líneas Pn blanco
Operaciones: :,angra.do
. . .
1mprmur Operacion0s:

DA.TO: P árrafo (de salida) DATO: Línea (de salida)

.\.tributos: Atributos:
sepa rador de párrafo sangrado
líneas de salida palabras
Üpflra.cioncs: Operaciones:
iniciar párrafo iniciar línea
poner palabra (- recomponer) ¿cabe palabra'!
terminar párrafo poner palabra
imprimir sin a.justar
imprimir ajustada

Para obtener el diseño podemos asignar un módulo a ca<la. abstracción de datos

grupo de abst.raccionf's relacionadas entrf' sí. El módulo puf'<lf' corrE>sponder a un
1ato encapsulado si sólo se man~ja un dato <le ese tipo en todo el progTarna. Además
ay que tratar de E>xpresar cada operación en función de las otras, para ver las rela-
10nes <le uso entre módulos y detectar posibles omisiones. También hay que añadir
hstracciones funcionales para el módulo principal y otras operaciones omitidas, en
:-u caso.

En este ejemplo se detecta la omisión de una función para leer las palabras del
'f'xto de entrada y reconocer la separación entre párrafos. El diseño resultante podría
--er el indicado en la figura 5.13. El tipo ··separador de párrafo" no se ha materializado
·n un módulo separado, ya que no hay operaciones df'finidas sobre él y su contenido de
:nformación se reduce a un par de números enteros {líneas de separación y sangrado).

~ i,:: 3
::> .a. . Ejemplo: Vide ojuego de las minas
Este ejemplo ha sido descrito en el capítulo 3, donde se encuf'ntra incluso el do-
~umento de espE>cifica.ción de requisitos, cornpk•to. Para. realizar el diseño basado en
abstracciones debemos empezar por recopilar toda la información disponible. Pnf'<le
considerarse que la información es bastant<' precisa, <' incluye ya la identificación de
\·arias funciones y tipos de datos importantf's. l · u primer repaso del docnmf'nto de
Pspecificación de requisitos. al que podemos aplicar la técnica <le Abbot para identi-
'icar elementos significativos, nos conducirfa a una primera lista df' tipos df' datos y
operaciones asociadas, por ejemplo:
184 TÉCNICAS GESERALES DE DISEÑO DE SOFT\VARE TE

DATO: Tablero DATO: Tabla de resultados

Atributo:;: Atributos:(por nivel y entrada)
tamaüo texto
datos de casillas tiempo
nº de minas Operaciones:
nº de casillas destapadas anotar resultado
Operaciones: presentar pantalla
inic·iar tablero OPERACIÓl\: Ayuda
mover cursor
destapar
poner/ quitar marca
ap
DATO: Casilla de
Atributos: lac
hay mina
nº <le minas vecinas
está destapada
esta marcada

OPERACIÓN: 1finas (juego)

En esta lista se han incluido algunos tipos abstractos de datos. así como un par
de abstracciones funcionales, correspondientes al programa principal ( el juego de las
minas) y a la invocación de la ayuda en pantalla. El siguiente nivel de refinamiento
exige idear de manera. más precisa la forma de realizar ciertas operaciones. Por ejem- El
plo, se tiene el problema de cómo actualizar el cronómetro en pant,alla rnientras sP ple
está desarrollando el juego. y en particular mientras se está esperando que el juga- Ca]

dor pulse alguna teda. Otros problemas son cómo conservar los mejores resultado}-.
de una sesión para otra. y cómo actualizar un elemento en pantalla sin alterar la
presentación de otros. -
.:> .

Los últimos problemas son relativamente fáciles de resoh·er. Se puede almacenar

la tabla de resultados en un fichero en disco, entre sesión y sesión. La pantalla puedt oc
actualizarse por zonas. disponiendo de una función para situar el cursor de texto ob
antes <le escribir. Estas solucio11cs nos llevan a diseüar nuevas abstracciones de niYel po
más bajo q11e las anteriores. y que permitan realizar las operaciones indicadas p ero
evitando tener que invocar dir<'dameute funciones del sistema opt~rati\T1. El problP-
ma de actuar por tiempo ) no '>Ólo por la acción del jugador es algo más complejo. [G
Se podría pensar en usar 0I nwcani:-m10 <le interrupciones, pero resulta más sencillc, COl

realizar en el programa principal nn Psquema de rnonitor cíclico, disponiendo de uua de:

ID(
operación de lectura del t.0,·lado qu0 110 1mpliq11e espera: si no se pulsa teda se de-
vuelve !.<'da nula al leer. El esquema sl'ría: da
 XCNICAS DE DISENO ORIENTA.DAS A OBJETOS 185

REPETIR
Leer tecla
SI tecla no nula ENTONCES
responder a la tecla
F I~-SI
Leer tiempo
SI ha pasado el plazo E~TONCES
actuar por tiempo
FIN-SI
HASTA fin del juego
Esto nos lleva a diseñar un módulo de cronómetro del juego, de alto nivel, que se
.poya en otro de bajo nivel para leer el reloj del computador, así como otro módulo
.,e bajo nivel para leer del teclado sin espera. El cronómetro sería un dato encapsu-
1!.ado, definido de la siguiente manera:

DATO: Cronómetro
Atributos:
tiempo transcurrido 1 en segundos
Operaciones:
iniciar
pa: actualizar, si ha pasado un segundo
las parar
nto
im- El resultado final del diseño se recoge en el documento que aparece como ejem-
: se plo de documento completo de diseño arquitectónico, más adelante en este mismo
ga- "apítulo.
:io:-
· la
5. 6. Técnicas de diseño orientadas a objetos

1ar El diseño orientado a objetos es esencialmente igual al diseño basado en abstrac-

ide ciones, que de hecho se describe en muchos casos como ubasado en objetos'1• Los
cto objetos sólo añaden algunas características adicionales, tales como la herencia y el
vel polimorfismo.

le- Se han descrito una gran variedad de metodologías particulares en este campo
Jo. ICoad90l, [Booch94], [Rumbaugh91], etc. Toda.s Pilas tienen muchos elementos en
llo común, y se distinguen sobre todo en la aparienda de los diagramas empleados para
na describir el diseño. Esta situación es análoga a la que ocurrió en su momento con las
le- metodologías de análisis y diseño estructurado. basadas en los diagrainas de flujo de
e.latos.
186 TÉCNICAS GENERALES DE DISEÑO DE SOFTlVARE TÉ

La idea global de las técnicas de diseño orientadas a objetos es que en la des-

composición modular del sistema cada módulo contenga la descripción de una clase
de objetos o de varias clases relacionadas entre sí. Además del diagrama modular
que describe la estructura del sistema, estas metodologías se apoyan en diagramas
ampliados del modelo de datos, en que se ponen de manifiesto distintas relaciones
entre los datos, independientes de las relaciones de uso, que son las que aparecen en
el diagrama de estructura.

5.6.1. Diseño orientado a objetos

Puesto que la mayoría de las metodologías orientadas a objetos son bastante si-
milares, nos limitaremos aquí a describir una técnica general para derivar el diseño
a partir de las especificaciones del sistema. Realmente el diseño orientado a objetos
se solapa en parte con el análisis del sistema si en él se emplean ya objetos para
describir el modelo del sistema a desarrollar.

La técnica general de diseño se basa en los siguientes pasos:

l. Estudiar y comprender el problema a resolver. Rcformular las especificaciones.

si se considera conveniente, para hacerlas suficientemente precisas.

2. Desarrollar en líneas generales una posible solución. Describirla suficientemente

al menos de una manera informal.

3. Formalizar dicha estrategia en términos de clases y objetos y sus relaciones

Esto puede hacerse mediante las siguientes etapas:

3.1 Identificar los objetos (o clases), sus atributos y componentes.

3.2 Identificar las operaciones sobre los objetos y asociarlas a la clase u objet
adecuado.
3.3 Aplicar herencia donde sea conveniente.
3.4 Describir cada operación en función de las otras, y subsanar posibles omi-
s10nes.
3.5 Establecer la estructura modular del sistema, asignando clases y objetos
módulos.

Si tras estos pasos el diseño del sistema no está suficientemente refinado, se vucl
ven a repetir, aplicándolos a las clases y objetos poco detallados, hasta conseguir e::
diseño aceptable, listo para ser codificado. A continuación se detalla algo más cae
uno de los elementos de esta técnica general.
 -:ÉCNICAS DE DISEÑO ORIENTADAS A OBJETOS 187

l. ESTU DIAR Y COM PREND ER EL PROBLEMA.

Debe haberse realizado ya en la fase de análisis de requisitos. Sin embargo
puede ser necesario repetirlo en parte, bien porque la especificación no sea
suficientemente precisa, o simplemente porque el diseño va a ser realizado por
personas diferentes de las que confeccionaron la especificación.

2. DESARROLLAR U NA POSIBLE SOLUCIÓN.

Es posible que esto se haya hecho también durante la fase de análisis, aunque es
más probable que se tenga que hacer o completar en la fase de diseño. Conven-
drá considerar varias alternativas y elegir la que se considere más apropiada.
La solución elegida debe expresarse con suficiente detalle como para que en su
descripción aparezcan mencionados casi los elementos que formarán parte del
diseño. De todas maneras puede ser suficiente una descripción informal.

3. 3.1 IDENTIFICAR LAS CLASES Y OBJETOS . P uede hacerse siguien-

do la técnica de Abbott mencionada anteriormente. En este primer paso
se atiende sobre todo a identificar las clases de objetos y sus atributos. Si
un objeto contiene otros objetos, no se suelen t ratar como atributos, sino
que se establece una relación de composición entre el objeto compuesto y
r1es.
los objetos componentes. Tras este primer paso puede ya confeccionarse un
diagrama inicial del modelo de objetos, con las relaciones de composición,
nte. así como otras relaciones generales que se vayan identificando.
3.2 IDEN TIFICAR LAS OPERACIO N ES SOBRE LOS OBJETOS.
También puede hacerse siguiendo la técnica de Abbott. Además de iden-
tificar las operaciones hay que decidir a qué objeto o clase se asocia. Esto
puede ser un problema de diseño no trivial. Por ejemplo, la operación de
escribir en pantalla la representación como caracteres de una fecha puede
asociarse al objeto fecha, o bien al objeto pantalla. Cada decisión tiene sus
jete ventajas e inconvenientes. En algunos casos puede fraccionarse la opera-
ción en varias más sencillas. Por ejemplo, se puede definir una operación de
conversión de fecha a texto, sobre el objeto fecha, y otra operación de es-
mí- critura del texto sobre el objeto pantalla. Las operaciones pueden reflejarse
sobre el diagrama de modelo de objetos.

)S a 3.3 APLICAR HEREN CIA. Una vez identificados los objetos y sus opera-
ciones asociadas, hay que detectar analogías entre ellos, si las hay, y esta-
blecer las relaciones de herencia apropiadas, reformulando las descripciones
1el- de los objetos si es necesario. Estas relaciones de herencia se incluirán en
un el diagrama de modelo de objetos que se va desarrollando.
:l.da 3.4 DESCRIBIR LAS OPER ACIONES. Esta es una manera de verificar
que el diseño es consistente. Cada operación se describe de manera informal
o en pseudocódigo, haciendo referencia únicamente a operaciones o clases
188 TÉCNICAS GENERALES DE DISEÑO DE SOFT\-\:4.RE TÉG.

de datos definidos en este mismo diseño, o bien predefinidos en el lenguaje

de programación a usar y otros elementos de softv,,are ya disponible. En
caso necesario habrá que añadir nuevas operaciones a las ya identificadas.
o incluso nuevas clases de objetos, y se actualizará el modelo de objetos.

3.5 ESTABLECER LA ESTRUCTURA MODU LA R . Para ello hay que

asignar clases, objetos y operaciones a módulos separados. En principio se
intentará que cada módulo corresponda a una clase de objetos (o a un
objeto en particular). Si el módulo es demasiado complicado, ciertas ope-
raciones pueden establecerse como módulos separados. También es posible
agrupar en un solo módulo varios objetos o clases muy relacionados entre
sí, para mejorar las características de acoplamiento y cohesión. Como re-
sultado de esta etapa se obtendrá el diagrama de estructura del sistema.

L
lé
Como ya se ha indicado, hay que analizar si el diseño modular resultante e:-
apropiado para pasar a la fase de codificación. Si algún módulo es todavía demasiadc
complejo, o no está definido con suficiente precisión: se repetirán los pasos anteriore:- e
t,
de diseño para ese módulo, con objeto de refinarlo.

5.6.2. Ejemplo: Estación m ete orológica

Para la realización de este ejercicio de diseño se parte de una especificación I

descripción informal del sistema a desarrollar: l
EJE:V1PLO: ESTA.CIÓ~ METEOROLÓGICA Un sistema de recogida I
de datos meteorológicos está formado por una. serie de estaciones me-
teorológicas automáticas que recogen datos ambientales, realizan algún
tratamiento loca.! de dichos datos, y envían periódicamente la informa-
ción recogida y elaborada a un computador de zona para su tratamiento.
Se trata. de diseñar el software que ha de controlar el funcionamiento de
una de estas estaciones automáticas. Los datos medidos son:
• Temperatura
■ Velocidad y dirección del viento
■ Presión atmosférica
■ Precipitación (llu\"ia)

Para ello se dispone de dispositivos de medida que aceptan las siguientes órden
básicas:
ÉCNICAS DE DISEÑO ORIENTADAS .4 OBJETOS 189

Termómetro:
lectura de la temperatura en ese instante

Anemómetro:
lectura de la velocidad de viento en ese instante

Veleta:
lectura de la dirección de viento en ese instante

Barómetro:
lectura de la presión atmosférica en eHe instante

Pluviómetro:
iniciar medición ( vaciar el depósito)
lectura de la lluYia calda desde el inicio anterior

Los datos de los medidores deberán leerse cada minuto, excepto

la precipitación que se leerá cada hora.

Con las lecturas de los instrumentos deberán realizarse los siguien-

tes cálculos para cada periodo de una hora:

• Con los datos de temperatura, presión. y velocidad de viento,

se obtendrán los valores má.ximo, mínimo y medio.
• Para la dirección de viento. se obtendrá la media y se marca-
rán para enviar todas las lecturas que se desvíen en más de
15°.

La estación meteorológica dispone de otros dos dispositiYOS para

la medida del tiempo y comunicación con el computador de zona.
Las operaciones básicas son:

• Reloj
lectura de la hora en ese instante
poner el reloj en hora

• 11odem
recibir un mensaje
transmitir un mensaje
 TÉt
190 TÉCNICA.S GESERALES DE DISERO DE SOFTl,V,ARE

La comunicación con el computador de zona se rea.liza por línea compar-

tida. El computador de zona explorará cíclicamente (mediante polling)
las estaciones meteorológicas para ver si tienen algo que comunicar.
Las estaciones responderán con uno o varios mensajes, el último de los
cuales indicará. fin de transmisión.
Las estaciones comunicarán datos cuando hayan completado el trata-
miento de los valores de una hora. El mensa.je de exploración desde
el computador central incluirá la hora del reloj maestro. La estación
pondrá su reloj en hora si la desviación del reloj local excede de 20
segundos.
El arranque de la estación meteorológica se hará automáticamente
al conectarse a la corriente, o mediante un pulsador manual. En el
arranque, se esperará a una exploración del computador de zona, se
pondrá el reloj en hora, se notificará que se produce dicho arranque, y
se inicializará la recogida de datos. También habrá un pulsador manual
de parada que detendrá la operación de la estación.

El diseño orientado a objetos puede realizarse siguiendo los pasos indicados ante-
riormente:
l. Estudiar y comprender el problema. Requiere leer con atención las especifica-
ciones y consultar todos los puntos dudosos que se encuentren. En particular
habrá que conocer el formato de los mensajes a enviar y recibir.
2. Desarrollar una posible solución. En este caso se puede optar por mantener en
memoria los datos necesarios para ir componiendo la información que habrá
que enviar cada hora. Esta información será:
■ Para la temperatura, presión, velocidad y dirección de viento, la suma de
las medidas y el número de ellas, para obtener la media al final.
• Para la temperatura, presión y velocidad de viento, el máximo y el mínim
hasta cada momento, que serán finalmente los de toda la hora.
■ Para la dirección de viento, cada una de las muestras, para poder seleccio-
nar al final de la hora las que se desvíen más del límite.
Los valores finales se calcularán al cabo de la hora, y se pondrán a cero ,~
registros. Los valores finales se mantendrán almacenados en espera de transm.-
tirlos a la estación central, al mismo tiempo que se va realizando la recogid
de datos de la hora siguiente. Al completar una nueva hora, los nuevos date.-
totales se almacenan reemplazando a los de la hora anterior, aunque éstos n
hayan podido ser trasmitidos a la estación central.
3.a Identificar las clases y objetos. Según la técnica de Abbott, marcando los té:-
minos clave como se ha hecho en la descripción informal inicial, se pued(
confeccionar las siguientes listas de elementos significativos:
 ..:.CNICAS DE DISEI~O ORIENTADAS A OBJETOS 191

DATOS OPERACIOJ.\"ES

datos meteorológicos lectura

= datos ambientales = leer
= temperatura iniciar medición
= velocidad del viento obtener máximo
- dirección del viento obtener mínimo
- presión atmosférica obtener media
= precipitación poner el reloj en hora
= lecturas que se desvíen recibir
dispositivo de medida =explorar
mensaje transmitir
fin de transmision =responder
hora = comunicar
estación = notificar
pulsador manual arranque
detener
A partir de la lista de nombres de datos hay que identificar los candidatos a
clases y objetos. Este paso no es trivial, y requiere cierta experiencia o habilidad
para realizarlo. En este ejemplo se puede llegar a la siguiente lista de clases y
atributos:

Dispositivo de medida
lectura
máximo
mínimo
media
lecturas que se desvían
Jv!ensaje
hora
datos meteorológicos
fin de transmisión
Reloj
hora
Estación

S no

: tér-
eden
192 TÉCNICAS GE,\TERALES DE DISENO DE SOFTH~4RE TÉ<

3.b Identificar las operaciones sobre los objetos. A partir de la lista de operaciones
se van asignando los diferentes elementos a las clases reconocidas. En este caso.
podemos llegar a la siguiente distribución: Dispositivo de medida leer iniciar
medición obtener máximo obtener mínimo obtener media Nlensaje enviar recibir
Dispositivo de medida
leer
iniciar medición
obtener máximo
obtener mínimo
obtener media
:Mensaje
enviar
recibir
3.,
Reloj
leer
poner en hora
Estación
arrancar
detener
3.c Aplicar herencia. En este caso se puede observar que no todas la operacionec
sobre dispositivos de medida son aplicables a cada uno de los dispositivos. Per
demos identificar medidores especializados, con operaciones particulares. A~
llegamos al siguiente esquema superclase/subclases:

:t\Iedidor
:t\Iedidor con máximo, mínimo y media
:t\Iedidor con media y lecturas que se desvían
:t\Iedidor con puesta a cero inicial

La primera subclase corresponde a las mediciones de temperatura, presión

velocidad de viento, mientras que la segunda corresponde a la dirección d
viento, y la tercera a la precipitación. Ahora hay que redefinir los atributos
operaciones sobre estas clases. Las nuevas operaciones podrían ser:

1Iedidor leer
(lectura simple)

~Icdidor con máximo. mínimo y media

leer (a(;umulando y actualizando máximo y mínimo)
obtener media poner a cero (el acumulador)
:ÉCNICAS DE DISEi\•O ORIENTA.DAS A OBJETOS 193

::Vledidor con media y lecturas que se desvían

leer (acumulando y registrando lecturas)
obtener media
obtener medidas desviadas
poner a cero (el acumulador)
::Vledidor con puesta a cero inicial

iniciar medición

Todos los medidores especializados heredan la operación de lectura simple, y la

mayoría de ellos la redefinen.

3.d Describir las operaciones. Ahora hay que comprobar que cada operación es
realizable, bien directamente o en función de las otras. Por ejemplo, la clase
"fvledidor" y la subclase "J\iledidor con máximo, mínimo y media" se podrían
definir, en pseudocódigo, en la forma siguiente:
CLASE 1-'Iedidor
ATRIBUTOS
lectura: Tipo:Nledida
OPERA.CION Leer
tomar una nueva 'lectura'
FII\-CLASE

CLASE :MedidorConl\:1áximo ES-UN :Medidor

ATRIBUTOS
máximo, mínino: TipoNiedida
acumulado: Tipo1'1edida
num~1uestras: E:NTERO
OPERACIO:N PonerACero
poner a cero 'acumulado' y 'num:Niuest ras'
OPER.ACION Obtener::Vledia( media )
devuelve 'media' = 'acumulado' / 'nurnN1ucstras'
OPERACIOX Leer
SUPER.Leer
acumular la nueva 'lectura' en 'acumulado'
incrementar 'numJ\!Iucstras'
si la nueva 'lect ura' es mayor que el 'máximo'
anotarla como nueYo 'máximo'
si la nueva 'lectura' es menor que el mínimo',
anotarla como nuevo ·mínimo'
FIN-CLASE
194 TÉCNICAS GENERALES DE DISEÑO DE SOFTWARE TÉC~

Las operaciones que dan problemas son las de "Arrancar" y "Detener:' la esta- 3.e l
ción. Con un poco de reflexión se puede comprender que en realidad la estación
sólo tiene una operación que realizar, que es el trabajo normal, y que podemos
redefinir como "Operar". El flujo de control de esta operación puede adoptar la
forma clásica de monitor cíclico, lo que conduce al siguiente pseudocódigo:

CLASE Estación
OPERACIOK Operar
iniciar la estación
REPETIR
SI hay mensaje ENTQ_ CES
recibir mensaje
poner en hora le reloj
componer mensaje con datos de la hora anterior
enviar el mensaje
FI~-SI

SI ha pasado un minuto EKTONCES

leer medidas de temperatura, viento y presión
FIN-SI

SI ha pasado un minuto EKTONCES

leer pluviómetro
iniciar lectura de pluviómetro
calcular los datos de la hora

FIN-SI
HASTA tecla de parada pulsada
FIK-CLASE

Esta descripción nos lleva a descubrir que necesitamos dos operaciones adi-
cionales sobre la clase "Nlensaje", correspondientes a detectar si ha llega.do u.e
nuevo mensaje, y a componer el mensaje para enviarlo. Con el resultado d-
todos estos pasos del diseño se puede ya confeccionar un diagrama de objf'tc¿
del software de la estación meteorológica, tal como el que se representa en lo
figura Un objeto "Estación'· se compone de un gestor de ":tvlensajes" (modem
un "Relof, y una colección de medidores de las clases indicadas. Los medidore:
son especializaciones de la clase genérica '·:Yiedidor".
 ItC_VICAS DE DISENO ORIENTA.DAS A OBJETOS 195

...e Establecer la estructura modular. Ahora se agrupan los elementos del diseño
en módulos, y se construye el diagrama de estructura de la aplicación, con las
relaciones de uso entre módulos. La forma más sencilla de hacerlo es asignar un
módulo a cada clase de objetos. Con ello se llega a la arquitectura representada
en la figura 5.14 Las relaciones de herencia de la figura 5.14 se traducen ahora
a relaciones de uso. Una subclase utiliza el código de su superclase.

Medidor Estaci6n

lectura

Leer Operar

◊
Á

1 1
1 1 1

Medidor con Medidor con Medidor con Mensaje Reloj

máximo desviación pues. cero IModeml
hora hon
máximo desviaciones
mínimo datos

Lee< Leer Hoy?

Media Media Iniciar Componer leer
Obten. Des Enviar Pooer hora
P.a cero P. a cero Recibir

Figura 5.14: :Vfodelo de objetos de la estación meteorológica

Estación

1 ----==
Medidor Medidor con Medidor con Mensaje
Reloj
con máximo desviación puesta a cero (modem)

to::.
Lla
/
n) Medidor
re.<:

F igura 5.15: ArquitecLura del software de la estación meteorológica

196 TÉC1\'ICA5 GENERALES DE DISE1\TO DE SOFTWARE DISE.

5. 7. T écnicas de diseñ o d e datos de m:

acept
La mayoría de las aplicaciones informática~ requieren almacenar información en ione
forma permanente. La manera típica de hacerlo es apoyando esa aplicación en una " la.E
base de datos subyacente. El diseño de la estr uctura de las bases de datos es ho} ~tre
día una disciplina independiente IDate90l,(De1vliguel93J, al igual que otras que sirven
de apoyo a la ingeniería del software. En esta sección y las siguientes se presentan
algunas ideas fundamentales sobre cómo organizar la base de datos en que se al- l. Vl:
macena la información permanente de una aplicación informática. !\luchas de esta.<; vitai
ideas pueden aplicarse también a la organización de las estructuras de datos en me- e ín,
moria, durante la operación de la aplicación. La organización de la base de datos
puede realizarse d<'sde varios puntos de Yista. l,;na forma clásica de enfocarla es en
· .. 8.]
tres niveles: externo, conceptual e interno. En cada nivel se establecen esquemas dt>
organización de los datos desde un punto de vista concreto. El paso de un nivel a L::
otro es el siguiente: es
no
nh·el externo: Esquemas de usuario
\., A . ALIS IS
te. l
nh·el conceptual: Esquemas lógicos
\., DIBE~O
nivel interno: Esquemas físicos
El nivel externo corre;ponde a la visión dé usuario. La organización de los dato:-
se realiza siguiendo esquemas significativos en el campo de la aplicación, por ejemplo
en forma de ficha de cliente o de empleado.
r l
El nivel conceptual establece una organización lógica de los datos. con indepen- ur
dencia del sentido físico que tengan en el campo de aplicación. Esa organización sr ep
resume en un diagrama de modelo de datos, bien del tipo Entidad-Relación (descri- ado
to en el capítulo 3) o como diagrama de ~lodelo de Objetos (descrito en el capítulo 3
Gn
El niYel físico organiza los datos según los esquemas admisibles en el sistema <l
11,
gestión de bases de datos v I o lenguaje de programación elegido para el desarrollo. S.
13
se uliliza una base de datos relacional los esquemas físicos serán esquemas de tabla:-
11
El paso del nivel externo al ni\·el conceptual se puede realizar durante la etap;
12
de análisis de requisitos. El paso del nh·el conceptual al nivel interno se realizarn 13
habitualmente durante la fase de diseño.

S
5.8. Diseño de bases de dat os r elacionales ad
;aria
Partiendo del modelo Entidad-Relación o bien del 11odelo de Objetos, es posib -.il
dar reglas prácticas, relativamente sencillas, para obtener los esquemas de las tabl~ ode
 I::,EIVO DE B.\SES DE DATOS REL.-1CIOX.4.LES 197

una base de datos relacional que reflejen la ,isión lógica de los datos, y que sean
ptablemente eficientes. En [Rumbaugh9ll se $iStf'111atizan bien esas recomenda-
ión e nes, que nos guían sobre la forma de traducir a esquemas de tablas los a.tributos
m Ul. las entidades. y las relaciones entre ellas. incluyendo las de composición y herencia
es he ...~re objetos.
sin·e
3enta, En Pl modelo relacional, los aspectos de eficiencia se contemplan desde dos puntos
se a.- , ista. Por una parte se establecen las llamadas formas normales, que tienden a
1tar redundancias en los datos almacena.dos. Por otra parte se estudia el empleo
índices para mejorar la velocidad de acceso a los datos.

es en
é\.::, d 5.8.1. Fo rmas normales
Las formas normales de Codd definen criterios para establecer esquemas de tablas
tC' s0an claros y no redundantes. Estos criterios se numeran correlativamente, de
=ieuor a mayor nivel de restricción. dando lugar a las formas normales 1ª, 2ª. 3ª.
c. Una tabla que cumpla con una cierta forma nonnal cumple también con las
1.nt<•riores.

Para ilustrar las definiciones de estas formas normales, consideraremos como ejem-
:lato lo una tabla en que se recoge información sobre la organización de las clases pre-
nplo senciales en un determinado centro educativo. En cada curso hay varios grupos de
lasC' y en cada grupo se imparten varias asignaturas. Cada asignatura es impartida
ror uno o varios profesores. cada uno de los cuales se encarga de esa asignatura
~pen en uno o varios grupos. Cada asignatura tiene, además, un profesor coordinador,
m -; <'tlW puede ser, o no, uno de los profesores que la imparten. Cada profesor tiene asig-
!Ser· nado un despacho. En la figura 5.16 se recoge toda esta información en una sola tabla.
lo 3
Grupo Asignatura Profesor DE>spacho Coordinador
ad€ .
11,12 Cálculo F .Díaz D-23 R.Pérct
}. S.
13 Cálculo A.García D-27 R.Pérf'z
)las
11 Álgebra C.l\forales D-34 F.Arranz
;apd
12 Álgebra ~LCampo'> D-21 F.Arranz
13 1 AlgE>bra 1 F.Arranz 1 D-32 F.Arranz

Figura 5.16: Tabla sin ninguna normalización

Se dice que una tabla se encuentra en 1ª forma normal si la información asociada

a cada una de las columnas es un valor único, y no una colección de valores en número
,·ariable. La tabla de la figura 5. 16 no está en la forma normal, porque hay alguna
.ble casilla en que se ha anotado más de un valor (,-arios grupos con el mismo profesor).
,la'i Podemos forzar que la tahla está en la forma uormal desdoblando la fila de esa casilla
198 TÉCNICA.S GEl\.ERALES DE DISEÑO DE SOFTWARE

en tantas filas como valores hay en la misma casilla. tal como se indica en la figura
5.17.
7
Grupo Asignatura Profesor Despacho Coordinador
11 Cálculo F.Díaz D-23 R.Pérez
12 Cálculo F.Díaz D-23 R.Pérez
13 Cálculo A.García D-27 R.Pérez
11 Álgebra e.Morales D-34 F.Arranz
12 Álgebra M.Campos D-21 F.Arranz
13 Álgebra F.Arranz D-32 F.Arranz

Figura 5.17: Tabla en 1ª forma normal pero no en 2ª

Se dice que una tabla está en 2ª forma normal si está en 1ª forma normal y
además hay una clave primaria (una columna o combinación de varias) que distingue
cada fila, y cada casilla que no sea de la clave primaria depende de toda la clave
primaria. En la tabla de la figura 5.17 la clave primaria es la combinación de las
dos primeras columnas. La tabla no está en 2ª forma normal porque el dato del
coordinador de la asignatura no depende de toda la clave primaria, sino sólo de
parte de ella (depende de la asignatura, pero no del grupo). Se puede conseguir la
segunda forma normal suprimiendo este dato de la tabla principal, y usando una
tabla auxiliar para relacionar la asignatura con el coordinador, tal como se hace en
las tablas de la figura 5.18

Grupo Asignatura Profesor Despacho Asignatura! Coordinador

11. Cálculo F.Díaz D-23 Cálculo R.Pérez
12, Cálculo F.Díaz D-23 Álgebra F.Arranz
13 Cálculo A.García D-27
11 Álgebra. c.~1oralcs D-34
12 Algebra M.Ca.mpos D-21
13 Algebra F.Arranz D-32

Figura 5.18: Tabla en 2ª forma normal pero no en 3ª

Se dice que una tabla está en 3ª forma normal si satisface el criterio de la 2ª

forma normal y además el ,·alor de cada columna que no es clave primaria depende
directamente de la clave primaria: es decir, no hay dependencias entre columnas que
no son clave primaria. La tabla de la figura 5.18 no está en 3ª forma normal porque
el despacho del profesor depende del profesor. Puede conseguirse la tercera forma
normal eliminando de la tabla cada columna dependiente de otra no clave primaria..
y usando una tabla auxiliar para registrar dicha dependencia. Esto se ha hecho en
las tablas de la figura 5.19
 ::JSEÑO DE EA.SES DE DATOS RELACIONALES 199

, Grupo Asignat. Prof. Asignat. Coord. Prof. Desp.

1gura
11. Cálculo F.Díaz Cálculo R.Pérez F.Díaz D-23
12. Cálculo F.Díaz Algebra F.Arranz A.García D-27
13 Cálculo A.García e .Morales D-34
11 Algebra C.Morales M.Campos D-21
12 Álgebra M.Campos F.Ananz D-32
13 Álgebra F.Arranz

Figura 5.19: Tabla en 3ª forma normal

Existen criterios aún más restrictivos que definen las formas normales 4ª y si-
;uientes, que se aplican poco en la práctica.

1aJ y
ngue 5.8.2. Diseño de las entidades
:lave
e las En el modelo relacional cada entidad del modelo E-R se t raduce en una tabla por
•ada clase de entidad, con una fila por cada elemento de esa clase y una columna
> del
o de por cada atributo de esa entidad.
1ir la
una Si una entidad está relacionada con otras, y se quiere tener una referencia rápida
:e en zntre las entidades relacionadas, se puede incluir además una columna conteniendo
un cód igo o número de referencia que identifique cada elemento de datos, es decir,
cada fila de la tabla. En el modelo de objetos, esto corresponde a almacenar explíci-
~amente en la tabla el identificador del objeto.

El número o código de referencia, si se usa, sirve perfectamente como clave pri-

maria.

5.8.3. Tratamiento de las relaciones de asociación

En el modelo de objetos se distinguen dos tipos especiales de relación, que son
las de composición (o agregación) y las de herencia (o especialización). Las demás
a 2ª relaciones se denominan genéricamente relaciones de asociación. En el modelo E-R
mde todas las relaciones se consideran relaciones de asociación. En las explicaciones si-
que guientes se atiende sólo a relaciones binarias, entre parejas de entidades.
~que
rma La manera de almacenar en tablas la información de las relaciones de asociación
iria, depende de la cardinalidad de la relación. La técnica general es traducir la relación a
) en una tabla conteniendo referencias a las tablas de las entidades relacionadas, así corno
los atributos de la relación, si los hay. Esto es ,-álido para relaciones con cualquier
200 TÉCNICAS GE.VERALES DE DISEÑO DE SOFTWARE DIS.

cardinalidad, incluyendo N-1\. La referencia a las entidades relacionadas se hará me- 5.8
diante la clave primaria de cada una. La figura 5.20 (a) recoge esta idea.

rela
Si la cardinalidad es 1-~, es decir, la cardinalidad de un lado de la relación está ubj
limitada a 1, es posible incluir los datos de la relación en la misma tabla de una de ind
las entidades relacionadas, tal como se indica en la figura 5.20 (b). Si la relación es
1-1. es decir, la cardinalidad está limitada a 1 en cada lado, se pueden fundir las
tablas de las dos entidades en una sola, tal como se hace en la figura 5.20 (c). 5.8

El reducir el número de tablas simplifica en cierto modo los esquemas físicos de la ~p

base de datos. Por ejemplo: algunas de las columnas con códigos de referencia pue- .as
den ya no ser necesarias, tal como se indica con líneas de puntos en la figura. Esta
simplificación se hace a costa de reducir, en algunos casos, el grado de normalización.

~-A~f----<0>-----i~_B~
a) relación N--N

Tabla A Tabla R Tabla B

Ref.A Atrib.A Ref.A Ref.B Atrib.R Ref.8 Atrib.B

t 1 1 t
b) relación 1· N

Tabla A+R Tabla B

Reí.A Atrib.A Ref.B Atrib.R Ref.8 Atrib.8

e) relación l • l
t
Tabla A+ 8 +R

Reí.A Atrib.A Ref.8 Atrib.8 Atrib.R

··········t-----t-
5

---------~--~
Figura 5.20: Tablas para relaciones de asociación
 EÑO DE BASES DE DATOS RELACIONALES 201

Tratamiento de las relaciones d e composición

_i_as relaciones de composición o agregación se tratan de la misma manera que las
iones de asociación. En las relaciones de composición la cardinalidad del lado del
'€to compuesto es casi siempre 1: por lo que serán df' aplicación las simplificaciones
.Jcadas en la sección anterior.

Tratamiento de la herencia
Cuando una clase de objetos (entidad genérica) tiene varias subclases (entidades
-7ecíficas) se pueden adoptar tres formas de almacenar en tablas la información de
, entidades, tal como se recoge en la figura 5.21. En el caso (a) se usa una tabla para
superclase, con los atributos comunes, heredados por las subclases, más una tabla
r cada subclase, con sus atributos específicos. En el caso (b) se han repetido los
ributos comunes en las tablas de cada subclase, por lo que desaparece la tabla de
superclase. En el caso (c) se prescinde de las tablas separadas para cada subclase,
se amplía la tabla de la superclase con todos los atributos de cada una de las
-ibclases, en forma de campos o columnas con valores opcionales, según cuál sea la
-;ibdase del objeto almacenado en cada fila de la tabla.

Diseño de Índices
Los índices permiten acceder rápidamente a un dato concreto, reduciendo así el
iempo de acceso. Pero esto es a costa de aumentar el espacio necesario de almace-
::amiento y, lo que es más importante, aumentar el tiempo necesario para almacenar
--ada nuevo dato y más aún para modificar el valor de un atributo indexado (la mo-
jjficación equivale a suprimir el elemento del índice y luego reinsertarlo con el nuevo
•-alor).

En general, si hay que acceder a datos a través de sus relaciones con otros. será
conveniente mantener índices sobre las claves primarias y columnas de referencia de
las entidades relacionadas. Aparte de esto, no es fácil dar criterios generales sencillos
para decidir cuándo conviene o no establecer índices adicionales sobre campos no
rlave.

5.8. 7. Ejemplo: Diseño de dat os para la gestión de biblioteca

La visión externa de los datos está constituida por los elementos '·Ficha de libro"
.\' "Ficha de lector", con los siguientes contenidos:
202 TÉCNICAS GENERA.LES DE DISENO DE SOFTWARE I

Ficha de lector: Ficha de libro:

Nombre Autor(es) l\Iateria( s) G
¿
Apellidos Título Lector (si está prestado)
Teléfono Editorial; etc. Fecha del préstarno (si está prestado) I
Domicilio

X
a) tablas de superclase y de subclase

Ref.X Atrib.X
1
l
l
1 1
l
y z I
i
1 1 :

Ref.X Atrib.Y Ref.X Atrib.Z

Relación de herencia

b) sólo tablas de subclases

Ref.Y Atrib.X Atrib.Y Ref.Z Atrib.X Atrib.Z

e) sólo tabla de superclase

r---------
' Ref.X Atrib.X Atrib.Y Atrib.Z
r--------·
'
XXlCl yyyy

:<Xlft zzzz
'''
'
'----------
Figura 5.21: Tablas para relaciones de herencia
 -:SEÑO DE BASES DE D.4TOS REL4CIONALES 203

En el documento de especificación de requisitos correspondiente a este ejemplo,

e aparece en el capítulo 3, se ha planteado como modelo conceptual correspon-
Pnte a estos datos los del diagrama E-R que allí aparece. con las entidades LIBRO.
::CTOR y :tvIATERIA, y las relaciones PRESTADO-A y TRATA-DE.

La razón para desglosar la lista de materias de las fichas de libro es para permitir
::,¡e dicha lista de materias ("thesaurus", en la terminología de los bibliotecarios) sea
ermanente, y todas las materias estén reseñadas aunque no haya ningún libro que
~ te de alguna de ellas en un momento dado.

La traducción directa de estas entidades y relaciones a tablas relacionales tiene el

..aconveniente de la falta de normalización en lo referente a los autores de los libros. En
ta visión inicial se habla del "autor" de un libro, cuando en realidad pueden ser varios.
En este caso no se cumpliría la 1ª forma normal, ya que en el mismo campo tenemos
.ma colección de datos en número variable. Para conseguir la 1ª forma normal se
puede promocionar el autor como entidad independiente, y establecer la relación
..\UTOR-DE entre autores y libros. Esto nos lleva a rehacer el modelo conceptual
según el diagrama E-R de la figura

LECTOR

LIBRO

MATERIA

AUTOR

Figura 5.22: Modelo de datos revisado

Ahora se puede hacer de forma adecuarla el diseño de los esquemas físicos de la

base de datos relacional. Las entidades LIBRO , LECTOR, A'CTOR y ~IATERIA se
t raducen a una tabla cada una, incluyendo una columna de Kº de referencia para
acceso mediante las relaciones.
204 TÉCNICAS GE.YERALES DE DISEÑO DE SOFTlVARE DI1

LIBRO LECT OR ACTOR :r-.1ATERIA

~ºRef KºRef ~ºRef NºRef da·
T ítulo Nombre Nombre l\"ombre fil

Editorial... Apellidos COI

Domicilio da
Teléfono

de
Las relaciones TRATA-DE y ACT OR-DE son de cardinalidad N-X, y se traducen en
en una tabla adicional para cada una. :;e
El
de
TRATA-DE AUTOR-DE rel
NºRef.Libro l\"ºRef.Libro
~ºReí.Materia :.'\ºReí.Autor
-
. ).

La relación PRESTADO-A es de cardinalidad 1-:--J. Se puede aplicar la simplifica-

ción indicada en la sección 4.6.3, incluyendo esta información en la tabla de libros.
qt
in
LIBRO es
U1
~ºRef
Título
w
Editorial d,
Nª Ref.Lector m
FechaPréstamo

Con esto se tiene de nuevo un esquema similar al de la visión externa de la ficha de

libro, en la que aparecen anotados el lector y la fecha del préstamo, en su caso. Est o:c a
campos de la tabla serán opcionales, y estarán vacíos si el libro no está prestado. ll
le
p
5.9. Diseño de bases d e datos de objetos
A diferencia de las bases de datos que siguen el modelo relacional, en las basf>-'
de datos orientadas a objetos no hay todavía un conjunto estable de estructuras d
información fundamentales, que se consideren primitivas de este modelo de bases <l
datos. En las bases de datos relacionales sólo se trabaja con la estructura tabla. ~
las bases de datos de objetos hay una mayor variedad de estructuras disponible::-
pero distintas en cada caso.
 :...JSEÑO DE SOFTlVARE CON PATRO!fES 205

En general pueden adoptarse dos enfoques en el d iseño físico con estas bases de
_,,_tos. El primer enfoque resulta apropiado cuando la base de datos de objetos per-
::::ute usar una gran variedad de estructuras. En estt> caso el diseño se puede hacer
rno para las estructuras de datos en memoria. El sistema de gestión de base de
natos aporta como complemento la persistencia de los datos.

El segundo enfoque se aplicaría cuando no existe esa gran variedad de estructuras

...P datos. y la base de datos de objetos resulta análoga a una base de datos relacional,

m que se establece implícitamente una tabla por cada clase de objetos. En este caso
..,p seguirían las recomendaciones ya dadas para el diseño sobre el modelo relacional.

El sistema de gestión de base de datos aporta la existencia implícita de identificadores

..e objetos, que hacen innecesarias las columnas explícitas de códigos o números de
-efcrencia.

5 .1 O. Diseño de software con patrones

1ca- El diseño con patrones fue introducido en el mundo científico dentro de la ar-
)S.
..¡uitectura por Christopher Alexander [Ale77] y adoptado con posterioridad en la
ingeniería de software, [Gam95l, siendo por tanto, la primera referencia obligada en
~ te campo. El concepto de patrón se puede definir como una solución probada a
un problema recurrente, de tal forma que, cada vez que aparezca dicho problema,
se aplica el patrón para resolverlo. Cada problema y su solución está descrito por
un patrón de diseño catalogado y perfectamente descrito. Trasladado a la ingeniería
Jel software: la cuestión es idéntica. Se tiene un problema por resolver, fundamental-
mente en la fase de diseño, y se busca una solución que otros ingenieros de software
.-a resolvieron y han contrastado la bondad de la solución que aportaron.

de Las dos principales características que debe cumplir un patrón son la efectividad
to~ a la hora de resolver el problema descrito y la capacidad para ser reutilizado en
multitud de ocasiones. La correcta documentación del patrón es imprescindible para
lograr la reutilizabilidad. En [Gam95] se describen los patrones a través de una
plantilla común compuesta, entre otros, de los siguientes campos:

■ Nombre del patrón

se:,
de ■ Propósito
de
■ lvfotivación
En
cs. ■ Aplicabilidad

■ Desa1Tollo del patrón

206 TÉCNIC.4.5 GESERALES DE DISEÑO DE SOFTW4RE DISE:

■ C sos conocidos

• Ejemplos

Cada vez son más las aplicaciones de los patrones dentro de la in,geniería de soft-
ware, algunas de ellas son: f

■ Interfaces de usuario u hombre-computador

■ Patrones de diseño en programación orientada a objetos

■ Patrones para la integración de sistemas heterogéneos que deben comunicarse

y sincronizarse

■ Patrones de flujo de datos dentro de la gestión de procesos empresariales

El empleo de patrones permite crear aplicaciones de gran tamaño en un periodo

de tiempo muy corto, lo que puede llevar a que aparezcan problemas para la elección.
organización y clasificación de los mismos. En [:tv1ic04] se propone la creación de una
tabla organizadora de patrones, la cual permite analizar los posibles patrones a utili-
zar para cada parte del programa que se está diseñando y elegir el más adecuado. La
variedad de repositorios de patrones y la multiplicidad de lenguajes de programación
hacen compleja esta tarea.

Dentro de los patrones de diseño en programación orientada a objetos, [Gam95]

clasifica los patrones en tres grandes grupos:

■ Patrones creacionales, son los que resuelven problemas en la creación de ins-

tancias.

■ Patrones estructurales, son los que resuelven problemas de composición de clases

u objetos para dar lugar a otras más complejas.

■ Patrones de comportamiento, son lo que resuelven problemas en la interacción

comunicación y responsabilidad entre clases u objetos.

En ,vw,v.wikipedia.org se describen varios ejemplos de los distintos tipos de pa-

trones. A continuación se reproduce el ejemplo <le un patrón de comportamiento, le.
clase Iterador (Iterator). Ver figura 5.23.
 -E~íO DE SOFTWARE CON PATRONES 207

.
ListaAbstracta
,
Cliente , lterador
" +primero()
+creartterador()
+siguiente()
+contar()
+hayMas())
+añadir(Elemento)
+elementoActual()
+borrar( Elemento)
+,..()

6 <<crear>> 6
1
r----------------,y
1

Lista ' lte radorlista

ListaSalto " lteradorlistaSalto

. A
: <<aear>> 1
--------------------------------------------------------------'

Figura 5.23: Esquema de uso de patron Iterador

■ Propósito . El patrón Iterador es un mecanismo de acceso a los elementos que

constituyen una estructura de datos para la utilización de estos sin exponer su
estructura interna. Ver figura 5.23

■ Motivación. El patrón surge del deseo de acceder a los elementos de un conte-

nedor de objetos (por ejemplo, una lista) sin exponer su representación interna.
Además, es posible que se necesite más de una forma de recorrer la estructu-
ra siendo para ello necesario crear modificaciones en la clase. La solución que
propone el patrón es añadir métodos que permitan recorrer la estructura sin
referenciar explícitamente su representación. La responsabilidad del recorrido
195 se traslada a un objeto iterador.

El problema de introducir este objeto iterador reside en que los clientes nece-
sitan conocer la estructura para crear el iterador apropiado. Esto se soluciona
ms- generalizando los distintos itera.dores en una abstracción y dotando a las es-
tructuras de datos de un método de fabricación que cree un iterador concreto.

■ Aplicabilidad. El patrón iterator permite el acceso al contenido de una es-

tructura sin exponer su representación interna. Además diferentes iteradores
pueden presentar diferentes tipos de recorrido sobre la estructura (recorrido de
.ón. prin9pio a fin, recorrido con saltos ... ). Por otro lado los iteradores no tienen
por qué limitarse a recorrer la estructura, sino que podrían incorporar otro tipo
de lógica (por ejemplo, filtrado de elementos). Es más, dados diferentes tipos de
pa- estructuras, el patrón iterador permite recorrerlas todas utilizando una interfaz
' la común uniforme.
208 TÉCNICAS GEYERALES DE DISEÑO DE SOFTWARE DL

• Estructura. El diagrama se puede ver en al figura 5.24

• Participantes. Las entidades participantes en el diseño propuesto por el patrón
iterador son:

• Iterador (Iterator). define la interfaz para recorrer el agrega'do de ele-

mentos y acceder a ellos) de manera que el cliente no tenga que conocer
los detalles y sea capaz de manejarlos de todos modos.
• Iterador Concreto. (Concretelterator) implementa la interfaz propuesta
por el Iterador. Es el que se encarga de mantener la posición actual en el
recorrido de la estructura.
• Agregado (Aggregate). define la interfaz para el método de fabricación
de iteradores.
• Agregado Concreto. ( ConcreteAggregate) implementa la estructura de
datos y el método de fabricación de iteradores que crea un iterador espe-
cífico para su estructura.

Agregado ,--
1 Qiente
1 .- lterador
1 1 +primero()
+crearlterador{)
+siguiente()
+hayMas:())
6 +elementoActual()

l~
AgregadoConcreto
«reartterador() ,,
,
lteradorConcreto
,
,, .
: <<crear>> ~
'' ------------------------------------------------------·'
''
return new tteradorConcreto(this);
r,
el

Figura 5.24: Estructura genérica de patron Iterador

■ Colaboraciones. Un iterador concreto es el encargado de guardar la posicióu

actual dentro de la estructura de datos, interactuando con esta para calcular e
siguiente elemento del recorrido.
■ Consecuencias. El patrón Iterador permite por tanto diferentes tipos de reco-
rrido de un agregado y \'arios recorridos simultáneos, simplificando la interfaz
del agregado.
■ Implementación. Para la creación del patrón iterador debe implementarse l-
control de la iteración (pudiendo Sff un iterador externo que ofrece los método,
 -:sEÑO DE SOFTWARE CON P.4.TRONES 209

para que el cliente recorra la estructura paso a paso, o un iterador interno que
ofrece un método de actuación sobre la estructura que, de manera transparente
al cliente, la recorre aplicándose a todos sus elementos) .Y definirse el recorrido. A
mayores se podrían implementar operaciones adicionales en el iterador o definir
la estructura de éste de una manera más robusta ante cambios en la estructura.
Hay que tener especial cuidado en la implementación de iteradores con accesos
privilegiadosi iteradores para estructuras compuestas o iteradores nulos.

A continuación se muestra el código que los define

.,...1ic claas Vector2 {

public int[] _datos;
public Vector2(int valores){
_datos= nev int[valores];
for (int i = O; i < _datos.length; i++){
_datos[i] a O;
}
}
public int getValor(int pos){
return _datos[poa];
}
public void setValor(int pos, int valor){
_datos[pos] = valor;
}
public int dimenaion(){
return _datos.length;
}
public IteradorVector iterador(){
return new IteradorVector (thia);
}
l

Definición del iterador concreto.

:,ublíc class IteradorVector{
'!l"i vate int [) _vector;
~ private int _posicion ;
public Iteradoriector(Vector2 vector) {
_vector• vector._dato&;
_po&icion • O;
}
public boolean hasNext (){
if (_posicion < _vector.length)
return true;
else
return false;
}
public Object next(){
ínt valor= _vector(_posicion];
_posicion++;
return valo..r;
ón }
}
el

Ejemplo de uso
:o-
public {tatic void main(String argv[)) {
az Vector2 vector a nev Vector2(5);
//Creación del iterador
IteradorVector iterador • vector.iterador( );
/ /Recorrido con el iterador
el vhile (iterador.haaNext())
System.out.println(iterador.next());
los }
210 TÉCNICA.S GENERALES DE DISEÑO DE SOFTR:4.RE EJE

En java ya existe una interfaz it(!rator que hace a las veces de abstracción. Todos
los iteradores utilizados en sus librerías cumplen esta interfaz , lo que permite tratarlos
a todos ellos de manera uniforme. Hacer que nuestro IteradorVector implementase
Iterator permitiría que fuese utilizado por otras librerías y programas dffmanera
transparente.

5.11. Ejemplos de diseños

En este apartado se recogen los documentos completos de diseño de los dos siste-
mas que se han ido desarollando a lo largo del libro.

5.11.1. Ejemplo: Videojuego de las minas

El documento ADD para el videojuego de las minas es el siguiente:

DOCUMENTO DE DISEÑO DEL SOFTWARE (AAD)

Proyecto: JUEGO DE LAS MDJAS (Versión simple)

Autores: J.A. Cerrada y R.Gómez Fecha: Enero 1999
Documento: MDJAS-ADD-99
COKTENIDO
l. INTRODUCCIÓ~
1.1. Objetivo
1.2. Ámbito
1.3. Definiciones, siglas y abreviaturas
2. PANORÁMICA DEL SISTE:'.\!IA
3. CONTEXTO DEL SISTE:.VIA
4. DISEÑO DEL SISTEMA
4.1. Metodología de diseño de alto nivel
4.2. Descomposición del sistema
5. DESCRIPCIÓN DE COMPONE:\"TES
6. VIABILIDAD Y REGCRSOS ESTIMADOS
7. ::VIATRIZ REQUISISTOSíCOMPO~ENTES

l. 11\TRODvCCTÓ~

l.1. Objetivo
Se trata de realizar un vidcojuego denominado "Juego de las Minas" cuyas reglas y característ"
generales se detallan en el documento de requisitos del software: '.\HN'AS-SRD-99. En lí
generale~. en este juego se trata de descubrir dentro del tablero la situación de las minas oc
y situadas aleatoriamen te' sin que ninguna de ellas explote y en el menor tiempo posiblf'.
E.JE,vIPLOS DE DISEJVOS 211

1.2. Ambito
En este desarrollo se abordará una versión simple que utilizará una interfase hombre-máquina
para pantalla alfanumérica y teclado. En una fase posLerior, se desarrollará una. versión más
elaborada que utilizará pantalla gráfica y ratón. El desarrollo de esta versión simple y la posterior
deberá diferir solamente en los módulos específicos dedicados a la interfase hombre-máquina.
1.3. Definiciones siglas y abreviaturas
Tablero: Elemento gráfico que se muestra en la pantalla del computador con forma de cuadrícula
y en el que se desarrolla el juego.
Casilla: Cada uno de los elementos de los que está formada la cuadrícula del tablero.
Mina: Elemento ocul,o en una casilla del tablero y que si se destapa provoca la finalización del
juego.
1.4. Referencias
MIXAS-S RD-99, OOCUME:STO DE REQUISITOS DEL SOFTWARE d•l VIDEO JUEGO OE LAS MINAS.

2. PANORÁMICA DEL SISTE:'vlA

Se recoge aquí un resumen de la descripción del sistema ya incluida en el documento de especificación
de requisitos YlINAS-SRD-99.
2.1. Objetivo y funciones
El objetivo es realizar una versión simplificada del juego de las minas, En este juego se trata de
descubrir dentro del tablero la situación de las minas sin que ninguna de ellas explote y en el
menor tiempo posible. Las funciones básicas serán:
• Selección del nivel de dificultad del juego (bajo, medio, alto)
• Desarrollo de la partida según las reglas del juego
• Elaboración y mantenimiento de la tabla de mejores resultados
• Ayudas al jugador
2 .2. Descripción funcional
En el juego se emplea un tablero cuadrado de N casillas de lado, semejante al que se muestra
en la figura :.VLl.

2 2 1 2 2

5 11 1
- 1 2
.
11 2 1 .. 1 11
1
4 1 - X 1 3

3 1 1 .. .. 1

4 11 2 .. .. 1

11 4 1 1 1

'
1

1 '
1
'

Figura Ml: Tablero del juego de las minas

J
En este tablero están ocultas un número det<'rmimulo de minas que pueden estar situadas en
cualquier ca8illa. Inicialmente se muestra el tablero con todas las casillas tapadas. Bn el ejemplo
de la figura M.l, las casillas tapa.<las están en blanco. El jugador tiene que ir destapando las
casillas para descubrir la situación de las mina:;. Cuando se destapa una casilla que tiene una
mina, esta mina explota y se acaba el juego infructuosamente. El objetivo del juego es encon1,rar
la situación de todas las minas sin que explote ning;una de ellas.
212 TÉCNICAS GEYERALES DE DISEÑO DE SOFT\.VARE E.

Para facilitar la búsqueda de todas las mina:,. el jugador podrá. marcar una casilla cuando tenga
la certeza de que en ella existe una mina. En la figura M. l la marca se indica con el símbok
"!!". Esta marca impide que pueda ser destapada la casilla por error. El jugador también podrá
quitar la marca de una casilla. En todo momento se mostrará en pantalla el número de minas
ocultas y todavía no marcadas.
El jugador podrá seleccionar el grado de dificultad del juego entre tres nive les: b.fjo, medio ,
alto. En cada nivel se empleará un tamaño distinto de tablero y el número de minas a descu-
brir también será dis~into. La si Luación de las minas en el tablero se realizará. de forma aleatoria.
Cada vez que el jugador destapa. una casilla., se deberá. indicar si tenía. una mina, en cuyo case
finaliza el juego, o el número de minas que rodean la. casilla que ha sido destapada. En la figura
M.l las casillas con el símbolo".." indican que el número de minas que las rodean son cero. P
número de minas que pueden rodear una casilla. pueden ir desde O hasta 8.
El juego dispondrá. de un cronómetro que actualizará en pantalla. cada segundo el tiempo trans-
currido desde el comienzo de la última partida en juego. Si el jugador consigue descubrir toda:,
las minas, el programa registrará el tiempo invertido junto con el texto que desee poner el j u-
gador y actualizará la lista de los mejores tiempos registrados en el nivel correspondiente.

3. CONTEXTO DEL SISTE11A

~o hay conexión con otros sistemas.

4. DISEÑO DEL SISTEMA

1.l. Metodología de diseño de alto nivel

1

Se utiliza la metodología de diseño modular basado en abstracciones.

4.2. Descomposición del sistema
La figura. M.2 contiene el diagrama de estructura del sistema. En él aparecen los component~
principales y las relaciones de uso entre ellos, así como una serie de módulos de bajo nivel. qu,
constituyen una librería de soporte. Las componentes principales son las siguientes:
Abstracciones funcionales:
• Minas
• Ayuda
Tipos AbsLractos de Datos:
• Casilla
Datos Encapsulados
• Tablero
• Crono
• Resultados

Minas

T~blero

Casilla

Figura :.VI2: Diagrama de estructura

El diagrama de estructura del sisLema utiliza un módulo para cada una de estas abstracciones, ;,, ...
se muestra en la figura .M.2. El módulo principal encargado del control del juego es Minas. que ul
y coordina al resLo de módulos. El dato encapsulado Tablero utiliza el tipo abstracto de dato Ca.s
Además, en la figura se muestra.u varios módulos encargados de adaptar los módulos de librería
los distintos compilador¡,s a las necesidades de este sistema. Estos módulos son:
STElHPLOS DE DISEÑOS 213

Tipos Abstractos de Datos:

• Ficheros
• Datos Encapsulados:
• Pantalla.
• Teclado
• Reloj
• Azar

5. DESCRIPCIÓI\ DE COMPONEKTES
A continuación se describen cada uno de los módulo::. indicados en el diagrama de estructura del
sistema.

5.1. Módulo: Ml ~AS

5.1. l. Tipo: Programa Principal

l!jugada

cambio de dificultad o
fin de juego sin mejor resultado Nueva Jugada
dificultad

mejor resultado

Figura M3: Diagrama de estados del sistema

5.1.2. Objetivo
Efectuar el control principal del juego.
5.1.3. Función
Iniciar el juego y controlar la ejecución de las diferentes funciones:
• Selección del nivel de dificultad del juego (ba.jo, medio, alto)
• DesarroUo de la partida según las reglas del juego
• Elaboración y mantenimiento de la tabla de mejores resultados
• Ayudas al jugador
El flujo de control de este módulo equivale al del sistema completo, y se muestra en la
figura :\I.3.
5.1.4. Subordinados: Tablero, Crono, Ayuda, Resultados. Pantalla, Teclado
J 5.1.5. Dependencias: :--Tinguna
5.1.6. intezfases: Ninguna
5.1.7. Recursos: l\"inguno
5.1.8. Referencias: l\"inguna
214 TÉG'VIG4S GESERALES DE DISEÑO DE SOFTWARE

5.1.9. Proceso: De acuerdo con el diagrama de la figura M.3 será:

Inicializar juego por defecto
REPETIR
Leer opción sin espera
SI inicio Juego EKTO:--ICES (
CASO opción
SI-ES Ayuda HACER Mostrar ayuda
SI-ES Cambio dificultad HACER Cambiar dificultad
SI-ES Borra resultados HACER Borrar Mejores
SI-ES Muestra resultados HACER Mostrar ).,fejores
Si-ES lª jugada HACER
Pasar al estado: En Juego
Realizar jugada
Fl~-CASO
SI-NO
Actualizar cronómetro
CASO opción
SI-ES Ayuda HACER Mostrar ayuda
SI-ES Cambio dificultad HACER
Cambiar dificultad
Pasar al estado: Inicio Juego
SI-ES Jugada HACER Realizar jugada
SI Fin de Juego & Mejor resultado E~TOKCES Grabar mejor FIN-SI
SI Fin de Juego EKTOKCES Pasar al estado: Inicio Juego Fl~-Sl
F~-CASO
FIK-SI
HASTA Fin de juego
5.1.10. Datos
• Última opción
• Nivel de dificultad
• Estado del juego
5.2. Módulo: TABLERO
5.2.1. Tipo: Dato encapsulado
5.2.2. Objetivo
Este módulo realiza todas las operaciones básicas para manejar el tablero del juego.
5.2.3. Función La función de este módulo es encapsular todas las operaciones posibles qu<> 9f
pueden realizar en el tablero en las distintas fases del juego. Las operaciones previstas~
las siguientes:
• Iniciar el tablero
• Poner las minas aleawriamente
• Mover el cursor a otra casilla
• Marcar o desmar car la casilla apuntada por el cursor
• Destapar casillas a partir de la apuntada por el cursor
• Pintar el tablero
5.2.4. Subordinados: Casilla, Azar, Pantalla
5.2.5. Dependencias: Minas
5.2.6. Interfases: Para cada operación:
Operación: iniciar tablero
Entrada: Nivel de dificultad
Salida:
Operación: Poner minas
Entrada:
Salida:
Operación: Mover cursor
Entrada: Incremento de posición X, Incremento de posición Y
Salida:
Operación: Marcar o desmarcar casilla
Entrada:
Salida:
Operación: Destapar casillas
Entrada:
Salida:J!KO fin del juego, SI/ NO objetivo alcanzado
Operación: Pintar tablero
Entrada:
Salida:Presentación en pantalla del tablero
5.2.7. Recursos: ~inguno
5.2.8. Referencias: ~inguna
 DEAIPLOS DE DISEÑOS 215

5.2.9. Proceso: Para cada operación:

Operación: iniciar tablero Proceso:
Inicializar tamaño tablero y total casillas según nivel
Inicializar número de minas y marcas según nivel
Iniciar cursor Iniciar casillas
Operación: Poner minas
Proceso:
REPETIR.
Elegir casilla aleatoriamente
Poner mina en la casilla
Incrementar el nº de minas que rodean a las casillas vecinas
HASTA Tota.J de minas
Operación:Mover cursor
Proceso:
Comprobar limites del tablero
Situar el cursor en la. nueva posición
Pintar casilla con nueva posición del cursor
Operación: Marcar o desmarcar casilla
Proceso:
Cambiar marca de casilla
Pintar casilla con/sin marca
Actualizar nº de casillas marcadas
Operación:Destapar casillas
Proceso: Destapar y pintar casilla
SI no hay mina & vecinas = O EKTONCES
Destapar y pintar recursivamente las casillas próximas con vecinas = O
FI)!-SI
Actualizar nº de casillas tapadas
Devolver resultado
Operación: Pintar tablero
Proceso:
Pintar dibujo base del tablero
REPE-'TIR
Pintar casilla
HASTA Total casillas
Je 5.2.10. Datos Los atributos del tablero son los siguientes:
• ::-lúmero de minas
• Lado del tablero
• Número de casillas marcadas
• Número de casillas tapadas
• Posición del cursor
• Datos de las CASILLAS
5.3. Módulo: CASILLA
5.3.1. Tipo: Tipo abstracto de datos
5.3.2. Objetivo Este módu lo define el tipo abstracto de datos para una casilla del tablero.
5.3.3. Función
Este módulo encapsula todas las operaciones posibles que se pueden realizar con cualquier
casilla del tablero y define la estructura de datos asociada a una casilla. Las operaciones
previstas serán las siguientes:
• Iniciar
• Cambiar marca
• Poner mina
• IncremenLar vecinas
• Destapar
• Pintar
5.3.4. Subordinados: Pantalla
5.3.5. Dependencias: Tablero
5.3.6. interfases: Para cada operación:
Operación: Iniciar
J Entrada:
Sa.Jida:
Operación: Cambiar marca
Entrada:
Salida: Variación de marca: Puesta. Quitada, Imposible por destapada
Operación: Poner mina
Entrada:
Salida:
216 TÉCNICAS GESERALES DE DISE.ÑO DE SOFTHZ4RE EJl

Operación: Incrementar vecinas

Entrada:
Salida:
Operación: Destapar
Entrada:
Salida: SiíK0 destapada, SI/KO mina, ~úmero de vecinas
Operación: Pintar
Entrada:
Salida: Presentación en pantaUa de la casiUa
5.3.7. Recursos: Ninguno
5.3.8. Referencias: Kinguna
5.3.9. Proceso: Para cada operación:
Operación: Iniciar
Proceso:
Poner casiUa sin mina
Poner casiUa sin marca
Poner casilla no destapada
Poner número de vecinas a cero
Operación: Cambiar marca
Proceso:
SI no destapada E:N"TONCES cambiar marca FIN-SI
Devolver variación de marca
Operación: Poner mina
Proceso:
Poner ca.silla con mina
Operación: Incrementar vecinas
Proceso:
Incrementar en uno el número de vecinas
Operación: Destapar
Proceso:
SI no marcada & no destapada EKTO~CES destapar FIN-SI
Devolver resultados
Operación: Pintar
Proceso:
Pintar casilla
5.3.10. Datos
Los atributos de una casilla son los siguientes:
• SI/:'.'fO con mina
■ SI/:'.'fO destapada
■ SI/NO marcada
• Número de vecinas
5.4. Módulo: CRONO
5.4.1. Tipo: Dato encapsulado
5.4.2. Objetivo Este módulo es el encargado de proporcionar todas las operaciones necesana..
para manejar el cronómetro del juego.
5.4.3. Función Este módulo encapsula todas las operaciones que se pueden realizar con el eran ~
metro en las distintas fases del juego. Las operaciones previstas son las siguientes:
• Iniciar
• Parar
• Actualizar
5.4.4. Subordinados: Pantalla, Reloj
5.4.5. Dependencias: Minas
5.4.6. interfases: Para cada operación:
Operación: Iniciar
Entrada:
Salida: Operación: Parar
Entrada:
Salida: Valor final del cronómetro
Operación: Actualizar
Entrada:
Salida:
5.4. 7. Recursos: Kinguno
5.4.8. Referencias: l\'inguna
5.4.9. Proceso: Para cada operación:
Operación: Iniciar
Proceso:
Poner segundos a cero
;:JE1'vIPLOS DE DISEÑOS 217

Operación: Parar
Proceso:
Devolver segundos
Poner segundos a ce ro
Operación: Actualizar
Proceso:
Leer reloj del computador
Si Tiempo transcurrido - l segundo ENTONCES
Incrementar segundos
Actualizar segundos en pantalla
F IN-SI
5.4.1 O. Datos
Los atributos del cronómetro son los siguientes:
Segundos
5.5. Módulo: AYUDA
5.5.1. Tipo: Abstracción funcional (procedimiento)
5.5.2. Objetivo Este módulo es el encargado de proporcionar la información de ayuda a.l jugador.
5.5.3. Función La función de este módulo es presentar en pantalla la información de ayuda al
jugador.
5.5.4. Subordinados: Pantalla
5.5.5. Dependencias: Minas
5.5.6. Intetfases
Operación: Presentar ayuda
Entrada:
Salida:
Presenta en pantalla texto de ayuda
5.5.7. Recursos: Ninguno
5.5.8. Referencias: Ninguna
5.5.9. Proceso
Operación: Presentar ayuda
Proceso:
Presentar en pantalla el texto de ayuda
5.5.10. Datos
Texto a presentar, codificado en la. propia función.
5.6. Módulo: RESULTADOS
5.6.1. Tipo: Dato encapsulado
5.6.2. Objetivo
Este módulo es el encargado de gestionar la tabla de los mejores resultados obtenidos por
los distintos jugadores.
5.6.3. Función
Las operaciones sobre la tabla de resultados son las siguientes:
• Borrar resultados de un nivel de dificultad
• Comprobar si hay mejor resultado en un nivel de dificultad
• Grabar resultado en un nivel de dificultad
• Presentar mejores resultados de un nivel de dificultad
5.6.4. Subordinados: Pantalla, Fichero
5.6.5. Dependencias: Minas
5.6.6. intetfases: Por cada. operación:
Operación: Borrar
Entrada: Nivel de dificultad
Salida:
Operación: Comprobar
Entrada: Nivel de dificultad, Segundos
Salida: SJ/)10 mejor resultado, posición ocupada
Operación: Grabar
Entrada: Texto a. grabar, posicion ocupada.
Salida:
Operación: Pre.5enta.r
Entrada: Nivel de dificultad
Salida.: Presentación en pantalla de mejores resultados del nivel
5.6.7. Recursos:
Un fichero en disco para almacenar 1;1 tabla de resuJLados.
218 TÉCNICAS GE:YERALES DE DISEJVO DE SOFT,VARE

5.6.8. Referencias: Ninguna

5.6.9. Proceso: Por cada operación:
Operación: Borrar
Proceso:
Inicializar tabla de resultados J
Grabar en el fichero en disco
Operación: Comprobar
Proceso:
Buscar el orden que ocupa el resultado
Devolver SiíNO es mejor y la posición que debe ocupar el resultado
Operación: Grabar
Proceso:
Desplazar los resultados peores
Copiar el texto a grabar en la posición
Grabar en el fichero en disco
Operación: Presentar
Proceso:
Presentar en pantalla la tabla de mejores resultados del nivel de dificultad
5.6. 1O. Datos Tabla con los registros ordenados por nivel de dificultad y segundos invertidos er
orden creciente. Cada registro deberá tener:
■ ~ivel de dificultad
■ Resultado en segundos invertidos
• Texto grabado por el jugador (~ombre, etc.)
5.7. Módulo: PAf\TALLA
5. 7.1. Tipo: Dato encapsulado
5.7.2. Objetivo
Este módulo es el encargado de proporcionar todas las operaciones necesarias para
manejo de la pantalla e independizar al resto del sistema de un compilador o sistem:.
operativo concretos.
5.7.3. Función
Este módulo encapsula todas las operaciones que se pueden necesitar de la pantalla. W
operaciones previstas son las siguientes:
• Limpiar
• Situar cursar
• Cambio video inverso/normal
• Salto de línea
■ Escribir ristra de texto
■ Escribir número entero
• Escribir carácter
5.7.4. Subordinados: !\lódulos predefinidos del compilador
5.7.5. Dependencias: Minas, Tablero, Casilla, Crono, Ayuda, Resultados
5.7.6. Interfases: Por cada operación:
Operación: Limpiar
Entrada:
Salida: Limpiar la pantalla por completo
Operación: Situar cursor
Entrada: Posición del cursor
Salida: Presentar el cursor en la posición indicada de la pant.alla
Operación: Cambiar video
Entrada: Kormalílnverso
Salida: Cambiar el vídeo de la posición en la que está el cursor
Operación: Salto de linea
Entrada.:
Salida: Salta el cursor a la primera posición de la siguiente linea
Operación: Escribir ristra
Entrada.: Ristra de texto a escribir
Salida: Presenta en pantalla el texto a partir de la posición del cursor
Operación: Escribir entero
Entrada: Entero a escribir, número de espacios de formato
Salida: Presenta. en pantalla el entero en los espacios indicados a partir
cursor
Operación: Escribir carácter
Entrada: Carácter a escribir
Salida: Presenta en pantalla el carácter en la. posición del cursar
5.8. Módulo: TECLADO
S.8.1. Tipo: Dato encapsulado
 LJEJ1PLOS DE DISEÑOS 219

5.8.2. Objetivo Este módulo es el encargado de proporcionar tocias las operaciones necesarias
para el manejo del tecla.do e independizar al resto del sistema de un compilador o sistema
operativo concretos.
5.8.3. Función
Este módulo encapsula todas las operaciones que se pueden necesitar del tecla.do. Las
operaciones previstas son las siguientes:
• Leer tecla con espera
■ Leer tecla sin espera
■ Leer ristra con espera
5.8.4. Subordinados: Ylódulos predefinidos del compilador
5.8.5. Dependencias: Minas
5.8.6. Interfases: Por cada operación: Operación: Leer tecla con espera Entrada: Salida: Carácter
ASCII de la tecla pulsada Operación: Leer tecla sin espera Entrada: Carácter ASCII testigo
Salida: Carácter ASCII testigo o de la tecla pulsada Operación: Leer ristra con espera
Entrada: Salida: Ristra leida
5.9. Módulo: RELOJ
5.9.1. Tipo: Dato encapsulado
5.9.2. Objetivo Este módulo es el encargado de proporcionar todas las operaciones necesarias
para el manejo del reloj e independizar al resto del sistema de un compilador o sistema
operativo concretos.
5.9.3. Función Este módulo encapsula la operación de lectura de reloj siguiente:
■ Leer segundos
5.9.4. Subordinados: Módulos predefinidos del compilador
5.9.5. Dependencias: Crono
5.9.6. Interfases: Por cada operación: Operación: Leer segundos Entrada: Salida: Segundos leídos
en el reloj del computador
5.10. :Módulo: AZAR
5.10.1. Tipo: Dato encapsulado
5.10.2. Objetivo Este módulo es el encargado de proporcionar todas las operaciones necesarias
para generar números aleatorios e independizar al resto del sistema de un compilador o
sistema operativo concretos.
5.10.3. Función Este módulo encapsula las operaciones para generar números aleatorios siguientes:
■ Iniciar semilla
■ Obtener un nuevo número
5.10.4. Subordinados: Módulos predefinidos del compilador
5.10.5. Dependencias: Tablero
5.10.6. interfases: Por cada operación:
Operación: Iniciar semilla
Entrada:
Salida:
Operación: Obtener un nuevo número
Entrada: Rango de validez del número
Salida: ~uevo número
5.10.7. Datos
El atributo es el siguiente:
■ ~úmero anterior
5.11. Módulo: FICHERO
5,U.l. Tipo: Tipo abstracto de datos
5.11.2. Objetivo Este módulo es el encargado de proporcionar todas las operaciones necesarias
para el manejo de ficheros e independizar al resto del sistema de un compilador o sistema
operativo concretos.
tir del ,.A,.11.3. Función
Este módulo encapsula todas las operaciones que ~ pueden necesitar para el manejo de
ficheros. Las operaciones previstas :;on lai, sigui<'ntes:
• Abrir
• Cerrar
■ Leer tabla de resultados
■ Escribir tabla de resultados
220 TÉCNIC.45 GESERA.LES DE DISENO DE S OFTWARE EJE1

5.11.4. Subordinados: Módulos predefinidos del compilador

5.11..5. Dependencias: Resultados
5.11.6. Interfases: Por cada operacióu:
Operación: Abrir
Entrada: Nombre del fichero
Salida: Identificador interno del fichero
Operación: Cerrar
Entrada: Identificador interno del fichero
Salida:
Operación: Leer tabla de resultados
Entrada: Identificador interno del fichero
Salida: Tabla de resultados
Operación: Escribir tabla de resultados
Entrada: Identificador interno del fichero, tabla de resultados
Salida:

6. VIABILIDAD Y RECURSOS ESTIMADOS

El programa puede ejecutarse en una máquina tipo PC de gama baja. La configuración mínima esti-
mada es:

■ Procesador: 80486
■ ~1emoria RA:\.f: 512 Kb
• Pantalla: :\lodo texto de 25 x 80 caracteres, rooI1ocromo o color

• Disquete o disco duro: 360 Kb

7. MATRIZ REQUISITOS / COMPO:'-lENTES

Se recoge en la figura M.4. En ella se pueden observar requisitos no ligados a ningún componente.
Son de dos clases.

Los marcados con asterisco (*) son requisitos que no se cumplen. Los demás son requisitos no fun-
cionales que se satisfacen con otros elementos del sistema distintos de los módulos establecidos en e
diseño.
'JE>.IPLOS DE DISEl'~·OS 221

MÓDULOS
1/l
o
o
oa:
1/l
e( w
_,
oz e(
o ~
::,
5
_,
z eo oa: ::, 1/l ¡;:¡
REQU ISITOS ~ ...
e(
u ~
w
o::
e(
u
R.1.1 X X X X X X
R.1.1.1 X
R.1.1.2 X X X
R.1.1.3 X
R.1.1.4 X X
R.1.1.5 X
R.1.1.6 X
R.1.1.7 X
R.1.1.8 X
R.1.1.9 X
R.1.1.10 X X
R.1.2 X X
R.1.3 X
R.1.4 X X
R.1.5 X
R.1.6 X
R.1.7 X
R.1.8 X
* R.1.9
R.1.10 X X
R.2.1 X
R.2.2 X
R.2.3 X
R.3.1
R.4.1 X
R.4.2 X
R.4.3 X
R.4.4 X
R.4.5 X
R.5.1
* R.6.1
R.8.1 X
* R.9.1

NOTA: Los requisitos marcados con(*) no se cumplen

Figura ~14: Matriz REQ"CISITOS-CO:\IPONE~TES

222 TÉCNICAS GESERALES DE DISEÑO DE SOFTH1ARE E
-------------------
5.11.2. Ej emplo: Sistema d e gestió n d e biblioteca
Eu esta sección se presenta el docurnrnto <le diseño de arquitectura (ADD) del
sistema de gestión <le biblioteca usado antt>riormente como ejemplo, v cuyo dueumen-
to de especificación de requisitos (SRD) se presentó en el capítulo 3. El documento
ADD para el sistema de gestión de biblioteca es el siguiente:

DOC UMENTO DE DISEÑO DEL SOFTWARE (AAD}

Proyecto: SISTE).'fA DE GESTIÓX DE BIBLIOTECA

Autorci,: ).l. Collado y J .F . Estívariz Fecha: ~oviembrc 1999
Documento: BIBLI O-ADD-99
COXT ENIDO
l. L,TRODVCCIÓN
1.1. Objetivo
1.2. Ámbito
1.3. Definiciones, siglas y abreviaturas
2. PA~ORÁÑ1ICA DEL SISTEJ\.1A
3. CO~TEXT O DEL SISTEl\lA
4. DISE,- O DEL SISTEMA
1.1. Metodología de diseño de alto nivel
1.2. Descomposición del sistema
5. DESCRIPCIÓ:N DE C0).i1PO~E 'TES
6. VIABILIDAD Y RECGRSOS ESTThfADOS
7. ).1ATRIZ REQUISISTOS/ C0:\1P01'ENTES

l. l.'lTRODUCCIÓK
l. l. Objetivo
El objetivo del sistema es facilitar la gestión de una bibliotE'ra mediana o pequeña, en lo r<'ft•re
te a la atención directa a los usuarios. Esto incluye, fundamentalmente. el préstamo de libr
a._-,¡ como la consulta bibliográfica

1.2. Ambito El sistema a. desarrollar consistirá en un único programa que realizará t.odas las funno1
nece:sarias. En particular, deberá facilitar las siguientes:
• Gestión del préstamo y de,olución d«> libro:,
■ Consulta bibliográfka por tit.ulo, autor o materia
Fl sistema no ha de soportar, sin t>mba.rgo. la gE'stión económica de la biblioteca, ni el com
cfp adquisición de libro:,, ui otra-; funciones no relacionadas directamente con la atención a
usuarios
Fl s1Stema facilitará la at<'nción al públiro por pant> de un único bibliotecario, que podrá at
clcr a todas las funciones.

1.3. Definiciones, siglas y abreviaturas

K ne,una
 IJEV/PLOS DE DISEiíros 223

1.4. Referencias
BIBLlO-SRD-99: DOCt;'-tENTO DE REQUISITOS DEL SOFTWARE d•I SISTEMA DE CESTIÓ~ DB BIBLIO-
TECA.

2. PANORÁMICA DEL SISTEl\lA

Se recoge aquí un resumen de la descripción del sistema ya incluida en el documento de especificación
de requisitos BIBLIO-SRD-99

2.1. Objetivo y funciones

La biblioteca dispone de una colección de libros a disposición del público. Cualquier persona
puede consultar los libros en la sala de lectura, sin necesidad de realizar ningún registro de esta
actividad.
Los libros pueden ser también sacados en préstamo por un plazo limitado, fijado por la orga-
nización de la biblioteca, y siempre el mismo. En este caso es necesario mantener anotados los
libros prestados y qué lector los tiene en su poder. Para que un lector pueda sacar un libro en
préstamo debe disponer previamente de una ficha de lector con sus datos, y en particular con in-
dicación de su teléfono, para facilitar la reclamación del libro en caso de demora en su devolución.
l;n lector puede tener a la vez varios libros en préstamo, hasta un máximo fijado por la orga-
nización de la biblioteca, igual para todos los usuarios.
Los usuarios deben disponer de algunas facilidades para localizar el libro que desean, tanto si es
para consultarlos en la sala como si es para sacarlos en préstamo. Se considera razonable poder
localizar un libro por su autor, su título (o parte de él) o por la materia de que trata. Para
la búsqueda por materias, existirá una lista de materias establecida por el bibliotecario. Cada
libro podrá tratar de una o varias materias.
El objetivo del sistema es facilitar las funciones más directamente relacionadas con la atención
directa a los usuarios de la biblioteca. Las funciones principales serán:
• Anotar los préstamos y devoluciones
• Indicar los préstamos que hayan sobrepasado el plazo establecido
• Búsquedas por autor, título o materia
Corno complemento serán necesarias otras funciones, en concreto:
• Mantener un registro de los libros
• Mantener un registro de los usuarios (lectores)
2.2. Descripción funcional El sistema de gestión de biblioteca será operado por una sola persona,
que dispondrá de un terminal con pantalla y teclado. También existirá una impresora por la
que podrán obtenerse listados y fichas de los libros y de los lectores.
La operación del sistema se hará mediante un sistema de menús para. seleccionar la operación
deseada, y con formularios en pantalla para la entrada y presentación de datos. Las funciones
a realizar se pueden organizar en varios grupos principales, que se describen a continuación.
2.2.1. Gestión de libros
Estas funciones permiten mantener actualizado el registro (fichero) de libros existentes en
la biblioteca. Las funciones de gestión de libros son las siguientes:
Función 1.1 Alta de libro: registra un nuevo libro
Función 1.2 Baja de libro: marca un libro como dado de baja
Función 1.3 Anular baja de libro: suprime la marca de baja
Función 1.4 Actualizar libro: modifica los datos del libro
Función 1.5 Listar libros: lista todos los libros registrados
Función 1.6 Compactar registro de libros: elimina los libros dados de baja
Función 1.7 Actualizar lista de materias: actualiza la lista de materias conside-
radas
2.2.2. Gestión de lectores
Estas funciones permiten mantener actualizado el registro (fichero) de usuarios (lectores).
ontn,
, a 106 Las funciones de gestión de lectores son las siguientes:
Función 2.1 Alta de lector: registra un nuevo usuario (lector)
Función 2.2 Baja de lector: marca un lector corno dado de baja
. a.ter- Función 2.3 Anular baja de lector: suprime la marca de baja
Función 2.4 Actualizar lector: modifica los datos del lector
Función 2.5 Listar lectores: lista todos los lectores registrados
Función 2.6 Compactar registro de lectores: elimina los lectores dados de baja
Función 2. 7 Buscar lector: localiza un lector por nombre o apellido
224 TÉC.\IC.\S Gf..\ERA.LES DE DISEÑO DE S0FT1líiRE EJE

2.2 3. Gestión de préstamo:,

Esta:, funciones permiten tener anotado,, lo:, libros ea préstamo, y conocer en un momt>lllO
dado los que han hido retenidos más tit-mpo del permitido. Las funciones de gestión de-
préstamos son las siguient€'S:
Función 3.1 Anotar préstamo: anota los datos del préstamo
Función 3.2 Anotar devolución: elimina los datos del préstamo 3

Función 3.3 Lista de moro80s: lista todos los préstamos no devueltos en el pla.z
fijado
Función 3.4 Préstamo:. de lector: lista los libros que tiene en préstamo un lecto= 4
dado
2.2.4. Búsquedas
Estas funciones permiten localizar libros por autor, título o materia. Las funciones de bú:-
queda son las siguientes:
Función 4.1 Buscar par autor: localiza los libros de un autor dado
Función 1.2 Buscar por título: localiza los libros cuyo título contiene un lt>xt
dado
Función 1.3 Buscar por materia: localiza los libro:; que tratan de una ma1eni.
dada

2.3. Modelo de datos El modelo conc<'ptual se describe en el diagrama Entidad-Relación. revi:,ad

que aparece en la figura B.l.

LECTOR

LIBRO

MATERIA

AUTOR

Figura B l: ~Iodelo de datos ENTIDAD-RELACIÓN

Este mode lo amplía el de::.c:rito en el documento de requisitos BIBLlO"SRD-99. Las entid

de datos principales y las relaciones entre ellas son las siguientes:
Entidad Libro: Contiene los data:, de identificación del libro
I::ntidad Autor: Contiene el nombre y apellidos del autor
Entidad Lector: Contiene los da.tos personales del lector
Entidad !\1a.teria: Contiene el término clave que identifica. la materia.
Relación Autor-de: Enlaza un libro con su(s) autor(es)
Relación Prestado-a. Enlaza un libro con el lector que lo ha sacado en pré;.t
Contiene la fecha del pré:>ta.mo
Relación Trata-de: Enlaza un libro con la(i,,) ma.teria(s) de la(s) que trata
Los esquemas fisicos correspondientt>s a este modelo conr<'ptua.l se d1•scriben l:'n el apartad,
MádtJlo: BASISDATOS. La Ficha de Libro e,; una vibión externa de los datos de un libro
M'r presentada en panLa.lla, o impre:sa como ficha o como líneas de detalle en un listado, •
incluye:

• Número de referencia
• Título
• Autor(c:.¡
• Colección
• Editorial
• ~lateria(s)
E:JElvIPLOS DE DISEÑOS 225

La Ficha de Lector es una. visión externa que incluye los datos de un lector alma.cena.dos en
la tabla LECTORES, para ;;er presenta.da en pantalla o impresa corno ficha o como líneas de
detalle en un lista.do.

3. CONTEXTO DEL SISTE~fA

Ko existe conexión con otros sistemas.

4. DISEÑO DEL S TSTEMA

4.1. Metodología de diseño de alto nivel Se utiliza la metodología de DISE:ri;O ESTRUCTURADO,

basa.da en la descomposición funcional del sistema.
4.2. Descomposición del sistema La estructura. modular del sistema aparece representada. en la. figura
B.2. Los módulos identificados son los siguientes:

E]
Figura B2: Arquitectura del sistema

• BIBLIO: Es el programa principal. Realiza el diálogo con el operador, en lo referente a la

selección de función.

• GESTIO~LIBROS, GESTIO~LECTORES. CESTIONPRESTAMOS, BUSQUEDAS: Mó-

dulos que realizan las funciones principales del sistema..
• BASEDATOS: Módulo que contiene la base de da.tos del sistema..

El módulo BaseDatos está realizado ñsi camente por el SGBD comercia.! que se utiliza.

5. DESCRIPCIÓN DE COMPONENTES

5.1. Módulo: BASEDATOS

5.1.1. Tipo: Base de datos relacional

5.1.2. Objetivo: Este módulo contiene la base de datos relacional que a.lma.cena la. información
persistente del sistema.
5.1.3. Función Alma.cenar los da.tos que se indican.
5.1.4. Subordina.dos: Ninguno

5.1.5. Dependencias: GESTIONLTBROS, GEST!Ol'\LECTORES, GESTIONPRESTA1IOS, BU$-

QUEDAS

5.1.6. Interfases El modelo físico de datos es ~I ;;iguiente:

• Tabla: LIBROS
226 TÉCNICAS GEJVERA.LES DE DISEÑO DE SOFTlVARE E

Campo Tipo Long. Indice Descripción

NumRef Kum 4 Sí ~úmero de referencia del libro

Titulo Texto 60 Ko Tll,ulo del libro
Coleccion Texto 20 No Colección a la que pertenece, opcional
Editorial Texto 30 No Nombre de la editorial
Lector ~um 4 Sí Número de referencia del lector que
lo ha sacado en préstamo
FechaPres Fecha Sí Fecha en que se prestó

■ Tabla: LECTORES
Campo Tipo Long. Indice Descripción

NumRef Kum 4 sr :'llúmero de referencia del lector

Apellidos Texto 40 No Apellidos del lector
Nombre Texto 20 No Nombre del lector
Domicilio Texto 40 No Domicilio del lector
Telefono ~um 7 No l\úmero de teléfono del lector

• Tabla: MATERIAS
Campo Tipo Long. Indice Descripción
NumRef Kum 3 Sí ::'llúmero de referencia de la materia
nombre Texto 20 l\o Nombre de la materia
(término o palabra clave que la identi-
fica)

• Tabla: AUTORES
Campo Tipo Long. Indice Descripción

NumRef Kum 4 Sí :'llúmero de referencia del autor

nombre Texto :30 No Nombre y apellidos del autor

• Tabla: AUTOR DE
Campo Tipo Long. Indice Descripción
Libro Num 4 Sí Número de referencia del libro
Autor Kum 4 No ::'llúmero de referencia. del autor
• Tabla: TRATA-DE
Campo Tipo Long. Indice Descripción
Libro ::'llum 4 Sí l\úmero de referencia del libro
Materia Num 3 :-lo :Número de referencia de la. materia
5.1.7. Recursos: :Ninguno
5.1.8. Referencias: Ninguna
5.1.9. Proceso: ~inguno
5.1.10. Datos (ver Interfases)
5.2. :vlódulo: BIBLIO

5.2.1. Tipo: Abstracción funcional (programa principal)

5.2.2. Objetivo: Este es el programa principal de la aplicación
5.2.3. Función
Este módulo se encarga de realizar el diálogo con el usuario en lo referente a la sclea:
de la función deseada en cada. momento. También debe realizar las operaciones oportu
al comienzo y al final de una sesión de traba.jo.
5.2.4. Subordinados: GESTlO.\fLIBROS GESTIOKLECTORES, GESTIONPRESTA~IOS. B
QCEDAS
5.2.5. Dependencias: l\inguna
5.2.6. Interfases: l\o aplicable
5.2.7. Recursos: Ninguno
5.2.8. Referencias: .'.'linguna
EJEMPLOS DE DISENos 227

5.2.9. Proceso
Iniciar la sesión
REPETIR - Presentar menú principal
Elegir opción
CASO opción DE
Gestión de libros:
Presentar menú de gestión de libros
Elegir opción
CASO opción DE
Alta de libro: Realizar alta
Baja de libro: Realizar baja
FIN-CASO
Gestión de lectores:
· óéstión de préstamos: Búsquedas:
FIN-·c.ÁSO
HASTA fin de sesión
Terminar la sesión
5.2.10. Datos (ver BASEDAT0S)
5.3. Módulo: GESTIONLIBROS
5.3.1. Tipo: Abstracción funcional (colección de funciones)
5.3.2. Objetivo: Realizar las funciones de mantenimiento del registro de libros disponibles en la
biblioteca..
5.3.3. Función: Las funciones realizadas por este módulo son las siguientes:
Función ALTALIBRO: registra un nuevo libro
Entrada:
Salida:
Usa: 11ATERIAS
Actualiza: LIBROS, AUTORES, AUTOR-DE, TRATA-DE
Efecto:Compone una nueva fi eha d e libro asignan . d o có d.1go automáticamente
. y
leyendo los datos del libro por pantalla (las materias se seleccionarán de
entre la lista de materias registradas). Registra la ficha en el fichero de
libros, y además la imprime.
Excepciones:
Proceso: . . d fi . al .b
- As1gnar numero e re erenc1a nuevo 1I ro
- Editar la ficha del libro mediante un formulario en pantalla
- El autor o autores se seleccionan de la lista de autores, añadiendo
nuevos nombres o editando los existentes, si es necesario
- La materia o materias se seleccionan de la lista de materias, pero no se
pueden añadir o modificar las materias existentes
- Pedir confirmación
- SI se confirma ENTONCES
- Regisf,rar la ficha del libro en las tablas de LIBROS,
AUTOR-DE y TRATA-DE
- Imprimir la ficha del libro SI-~O
- Anular la asignación de nuevo número de referencia y las
modificaciones en las tablas
FIN-Sl
Función BAJALIBRO: marca un libro como dado de baja
Entrada:
Salida:
Usa: AUTORES, ~ifATERIAS, Al:TOR-DE, TRATA-DE
Actualiza: LIBROS
Efecto:Lee el código del libro por pantalla, y marca la. ficha de ese libro
en el fichero de libros como dada de baja.
Excepciones: Si no existe el libro con el código indicado, o ya estaba dado de
baja, da un aviso.
Proceso:
- Lee el número del libro por pantalla
- Busca el libro en la tabla LIBROS
- SI el libro no existe ENTO:'lCES
- Da mensaje de que no exist.l'
SI-KO
- Presenta la ficha del libro C'n pantalla.
- Pide confirmación de la baja - SI se confirma
E:'lTONCES
- Marca el libro corno borrado en la. tabla LIBROS
FTJ\-SI
FIK-ST
228 TÉCNICA. S GE.\'ER.,\LES DE DISEÑO DE SOFTWARE

Función AKULARBAJALIBRO: suprime la marca de baja

Entrada:
Salida:
{;sa: AUTORES, MATERIAS, AllTOR-DE, TRATA-DE
Actualiza: Ll B R OS Efecto: L-<>c e1 co'd.1go del hbro
. por pantalla, y anua
1 la marca<1e
dado de baja en la ficha de ese libro en el fichero de libros.
Excepciones: Si no existe el libro con el código indicado, o no estaba dado de
baja,da un aviso.
Proceso:
- Lec el número del libro por pantalla
- Busca el libro en la. tabla LIBROS
- SI el libro no existe o no está marcado como borrado ENTO~CES
- Da el mensaje de aviso apropiado
SI-NO
- Presenta la ficha del libro en pantalla
- Pide confirmación de la. anulación de la. baja
- SI se confirma ENTONCES
- Anula la marca. de borrado del libro en la tabla
LIBROS
FTK-SI
FIN-Sl
Función EDITARLIBRO: modifica los da.tos del libro
Entrada:
Salida:
Usa: ~iATER.TAS
Actualiza.: LIBROS, AUTORES, AUTOR-DE, TRATA-DE
Efecto:
Lee el código del libro por pantalla, localiza la ficha de ese libro, y
actualiza los datos de ese libro, también por pantalla. Registra la ficha
actualizada en el fichero de libros, y la imprime.
Excepciones: Si no existe el libro con el código indicado, da un aviso.
Proceso: -Lee el número d e re ferenc1a. d el libro por pantall a
-Busca el libro en la tabla LIBROS
-SI el libro no existe o está marcado como borrado E~TONCES
- Da el mensaje de aviso apropiado
SI-1'0
- Editar la ficha del libro mediante un formulario en pantalla.
El autor o autores se seleccionan de la lista de autores,
añadiendo nuevos nombres o editando los existentes, si es
necesario
- La materia o materias se seleccionan de la lista. de
materias, pero no se pueden añadir o modificar las
materias existentes
- Pedir confirmación
- sr se confirma ENTO~CES
- Registrar la ficha modificada del libro en las tablas
de LIBROS, AUTOR-DE y TRATA-DE
- Imprimir la ficha modificada del libro
SI-NO
- Anular las modificaciones en las ta.bias
FIN-SI
FIK-SI
Función LISTARLIBROS: lista todos los libros registrados
Entrada:
Salida:
Usa: LIBROS, AUTORES, MATERIAS, AUTOR-DE, TRATA-DE
Actualiza:
Efecto: Imprime un lista.do con todos los datos de todos los libros, incluso los q
estén dados de baja, indicando si están prestados.
Excepciones:
Proceso:
- PARA-CADA libro registrado HACER
- Imprimir una o varías Líneas del listado, con los datos
de la ficha del libro y la indicación de si está prestado o
dado de baja (el listado se hará pag!nando en la forma
habitual)
FIN-PARA
 TMPLOS DE DISE1VOS 229

Función CO:\fPACTARLIBROS: elimina los libros dados de baja

Entrada:
Salida:
Usa:
Actualiza: LIBROS, AUTORES, ArTOR-DE, TRATA-DE

Efecto:Suprime del fichero de libros las fichas de libros que estén

dados de baja. liberando el espacio que ocupaban.
Excepciones:
Proceso:
- PARA-CADA libro registrado HACER
- SI está marcado como borrado ENTONCES
Borrar las líneas que correspondan de las tablas de
AüTOR-DE y TRATA-DE
F IN-SI
FJ:-f-PARA
- Compactar las tablas de LIBROS, A{;TOR-DE y TRATA-DE
- PARA-CADA autor HACER
- SI no queda ningún libro de ese autor E~TONCES
- Borrar ese autor
FIK-SI
FIN-PARA
- Compactar la tabla de AUTORES
Función EDITAR:"1ATERIAS: actualiza la lista de materias
Entrada:
Salida: Usa: TRATA-DE
Actualiza: MATERIAS

Efecto:S e ed'ita por pant a.U a l a 1·1sta d e matena.s

. a cons,.d erar, pudien do an"ad•1r,
suprimir materias, o modificar sus nombres.
Excepciones:S. . . . . h b. d lib • ad d
1 se intenta supnmrr una materia a 1en o ros reg,str os que tratan e
ella, se pedirá confirmación especial. Si se fuerza la eliminación, se suprimirá
también la referencia a esa materia de los libros que traten de ella.
Proceso:
- Editar la lista de materias en pantalla, permitiendo
- Añadir materias
- Modificar el nombre de una materia
- Suprimir materia:
- Si hay libros que tratan de esa materia, pedir confirmación
- SI se confirma la supresión ENTONCES
- Borrar las entradas en TRATA-DE
correspondientes a esa materia
F IN'-SJ
5.3.4. Subordinados: BASEDATOS
5.3.5. Dependencias: BIBLIO
5.3.6. Interfases (ver .Función)
5.3.7. Recursos: Ninguno
5.3.8. Referencias: Ninguna
5.3.9. Proceso (ver Función)
5.3.10. Datos (ver módulo BASEDATos)
5.4. Módulo: GESTIONLECTORES
5.5. Módulo: GESTlONPRESTAMOS
5.6. Módulo: Bt;SQUEDAS

6. VIABILIDAD Y RECURSOS ESTIMADOS

Esta aplicación puede ejecutarse ea una máquina tipo PC de gama baja. Los recursos mínimos esl.i-
mados son los siguientes:

• Procesador: 80486
 TÉCiYIC...\S GESERA.LES DE DISEÑO DE SOFT"~E C0,'\1
230

• Sistema Operativo: DOS

• :'\fomoria RA.\ef: 2 ).1b

• Pantalla: ::O.Iodo texto de 25 x 80 caracter!'S. monocromo o color

• Disco duro:

4 Mb para. el SGBD
l Mb para los programas de la aplicación
4 :\lb para los datos de la. aplicación (10.000 libros y 10.000 lectores)

7. MATRIZ REQUISITOS / COMPOKE!\~ES Se recoge en la figura B.3. En ella pueden observarse

requisitos no ligados a ninguna componente. Son de dos clases. Los marcados con asterisco (*) soi:
requisitos que no se cumplen. Los demás son requisitos no funcionales que se satisfacen con otrOE'
elementos del sistema distintos de los módulos establecidos en el diseño.
 -:JSCLUSIONES 231

MÓDULOS

"'
...o
"'...CII
...ou ... ....."'"'
o
E

..
"'
o .&J
:::;
e:
CII
....J
e:
CII
Q.
e:
.."'
~
CII
e _g o o o :,

REQUISITOS .."'
CII

CD
:¡;
iii
.:;
"'
CII
l.:>
t;
CII
l.:>
t:
CII
1:)
a
"'
:,
Cl0
R.1.1 X
R.1.2 X
F.1.1 X
F.1.2 X
F.1.3 X
F.1.4 X
F.1.5 X
F.1.6 X
F.1.7 X
F.2.1 X

R.2.1 X
R.2.2
R.2.3
R.2.4
R.4.1 X
R.4.1.1 X
R.4.2 X
* R.4.3
* R.4.4
R.4.5
R.4.6
R.4.7 X X X X
R.4.8 X
R.5.1
R.6.1 X
R.7.1
R.8.1
* R.8.2
• R.9.1
R.9.2 X
R.10.1

NOTA: Los requisitos marcados con (*) no se cumplen

Figura B3: Matriz REQ"CISITOS-CO.lVIPONE~TES

5.12. Conclusiones
En este capítulo se hace un repaso a las técnicas más importantes de diseño que
se emplean habitualmente:
• Técnicas por refinamiento progresivo
232 TÉCNlC.-lS GESERA.LES DE DISENO DE SOFTU'.ARL

• Técnicas de diseño basado en ahstraccíones

■ Técnicas de diseño orientado a objetos
• Técnicas de diseño de datos
Todas ellas tratan de facilitar la realización del diseño. Basadas en una o varias ct
estas técnkas se han desarrollado metodologías completas de diseño. En cursos pv::-
teriores se imparten asignaturas donde se desarrollan en profundidad estas técnica:-
e
Y otras que se basan en ellas.

5 .13. Ejercicios propuestos l

1. Búsquese dos ejemplos en los que ponga de manifiesto la propiedades de Ac~
plamiento y Cohesión dentro de un diseño de un sistema.
2. Realícese el diseño del "autobus'' del capítulo pasado utilizando las técnicas¿
diseño basado en abstracciones.
3. Diséñese las tablas de la base de datos que modeliza una escuela con profesorc--
6.
asignaturas, alumnos y departamentos. Extiéndase a la universidad con otra.
facultades.
4. Hágase un diseño del sistema de gestión de biblioteca orientada objetos.
5. Plantéese como conseguiría en su diseño un acoplamiento débil en los módulo~

Ql

6
 ,

Capítulo 6

UML, Lenguaje Unificado de

~odelado

6 .1. Introducción

En los capítulos anteriores se han presentado las metodologías y herramientas pa-

ra la realización de las fases del ciclo de vida del software, tanto para la especificación
Je requisitos, como análisis y modelado de los sistemas software.

En este capítulo se presenta Ul\1L, un lenguaje universal de modelado de sistemas

que se emplea para especificar y modelizar los sistemas software.

6.2. Objetivos

El objetivo de este capítulo es que el lector se familiarice con el lenguaje UML y

su utilización para la especificación y el modelado. En primer lugar se hace un breve
recorrido por la historia de su génesis. Esto permite contemplar cómo es un proceso
de normalización de herramientas conceptuales. en el que están implicadas tanto la
industria del sector como la comunidad científica, y cómo se lleva a cabo con total
normalidad y se llega a un estandard de aplicación mundial. En segundo lugar se
presenta los elementos de lenguaje Ul\.1L, rE>lacioncs. clases y diagramas. Algunos de
estos elementos se salen fuera del alcance de la asignatura pero se presentan para
completar la visión de todo el lenguaje L'1-1L.

233
234 UAIL, LENGC-AJE UNIFICADO DE .MODELADO 01

6.3. ¿Qué es UML? 6.

El lenguaje unificado de modelado (U:ML, por sus siglas en inglés, lJnified 11[ode-
ling Language) es el lenguaje de modelado de sistemas de software más conocido y
ex
utilizado en la actualidad. Es un lenguaje gráfico para visualizar, especificar, cons-
truir y documentar un sistema. ül\!IL ofrece un estándar para describir un ''plano" de
ba
del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de ne-
gocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de
Ja
m,
programación, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que C:NIL es un "lenguaje de modelado" para especificar

o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar R1
los artefactos en el sistema y para documentar y construir. En otras palabras, es el fir
lenguaje en el que está descrito el modelo. en

Se puede aplicar en el desarrollo de software gran variedad de formas para dar

soporte a una metodología de desarrollo, pero no especifica en sí mismo qué meto-
cr
dología o proceso usar.
m
ot
u:ML no puede compararse con la programación estructurada, pues UML significa
m
Lenguaje Unificado de :VIodelado, no es programación, sólo se diagrama la realidad
ce
de una utilización en un requerimiento. Mientras que, programación estructurada.
es una forma de programar como lo es la orientación a objetos. La programación
orientada a objetos viene siendo un complemento perfecto de Ul'v1L, pero no por eso
se toma l:YIL sólo para lenguajes orientados a objetos. V€
I-
Cl\!IL es un lenguaje de modelado visual que se usa para especificar, visualizar. R
const ruir y documentar artefactos de un sistema de software. Se usa para entender.
diseñar, configurar, mantener y controlar la información sobre los sistemas a cons-
truir. tá
su
U:\IIL presenta información sobre la estructura estática y el comportamiento cli- m
námico de un sistema. Un sistema se modela como una colección de objetos cliscreto-o m
que interactúan para realizar un trabajo que finalmente beneficia a un usuario ex- re
terno. d(

El lenguaje de modelado pretende unificar la experiencia pasada sobre técnic&

de modelado e incorporar las mejores prácticas actuales en un acercamiento estándar
H
Existen herramientas que pueden ofrecer generadores de código a partir de 1 -
L,
diagramas U:\•11 para una gran variedad de lenguaje de programación, así com ra
construir modelos por ingeniería inversa a part ir de programas existentes. la
DO ORlGENES DE U1'1L 235

6.4. Orígenes de UML

de-
o ,. La notación "Cl\1L deriva y unifica las tres metodologías de análisis y diseño más
1ns- extendidas: metodología de Grady Booch [Booch94] para la descripción de conjuntos
no de objetos y sus relaciones, técnica de modelado orientada a objetos de James Rum-
ne- baugh (Olv1T: Object - ~odelling Technique)[Rumbaugh91] y aproximación de lvar
. de Jacobson (OOSE: Object- Oriented Software Engineering)[Jacobson92] mediante la
metodología de casos de uso (use case).

car El desarrollo de UML comenzó a finales de 1994 cuando Grady Boocb y Jim
llar Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A
se finales de 1995, Ivar Jacobson y su compañía Objectory se incorporaron a Rational
en su unificación, aportando el método OOSE.

dar
De las tres metodologías de partida, las de Booch y Rumbaugh pueden ser des-
:to--
critas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el
modelado de los objetos que componen el sistema, su relación y colaboración. Por
otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su
ica
método se deriva de los escenarios de uso. CML se ha ido fomentando y aceptando
lad
como estándar desde el Object l\lianagement Group (0~1G).
da.
ión
eso Diversas organizaciones y empresas colaboraron en la elaboración de la primera
versión del lenguaje. Entre ellas Digital Equipment Corporation, Hewlett-Packard,
1-Logix, lntellicorp, IBl\1, ICON Computing, l\lICI Systemhouse, l\!Iicrosoft, Oracle,
;ar. Rational, Texas Instruments y Unisys.
ler.
ns-
En 1997 UML 1.1 fue aprobada por la OJVIG convirtiéndose en la notación es-
tándar de facto para el análisis y el diseño orientado a objetos. Como prueba de
su validez como lenguaje de modelado; U:ML es el primer método en publicar un
di- meta-modelo en su propia notación, incluyendo la notación para la mayoría de la
tos
información de requisitos, análisis y diseño. Se trata pues de un meta-modelo auto-
ex-
referencial (cualquier lenguaje de modelado de propósito general debería ser capaz
de modelarse a sí mismo).

ar Desde el año 2005, Ul\11L es un estándar aprobado por la ISO corno ISO /IEC
19501:2005 Information technology, Open Distributed Processing Cnified l\!Iodeling
los Language (U1v1L). Con el paso de los años el lenguaje ha ido evolucionando, incorpo-
mo rando nuevas funcionalidades para conseguir una mayor unificación integrando todas
las posibles tecnologías de desarrollo de software. La versión más actual es la 2.5.
236 UA1L, LESGC.:.4.JE UNIFICADO DE MODELADO

6.5. Objetivos de UML

Durante el desarrollo del L"lVIL sus autores tuvieron en cuenta los siguientes ob-
jetivos:
■ Conseguir la capacidad· de modelar sistemas; desde el concepto hasta los arte-
factos ejecutables, utilizando técnicas orientadas a objetos.

■ Cubrir las cuestiones relacionadas con el tamaño inherentes a los sistemas com-
plejos y críticos.
■ Crear un lenguaje de modelado utilizable tanto por las personas como por 1~
máquinas.
:vlediante el fomento del uso de UlVIL, 01\/IG pretende alcanzar los siguiente::
objetivos:

■ Proporcionar a los usuarios un lenguaje de modelado visual expresivo y utili-

zable para el desarrollo e intercambio de modelos significativos.
■ Proporcionar mecanismos de extensión y especialización.
■ Ser independiente del proceso de desarrollo y de los lenguajes de programacióL
■ Proporcionar una base formal para entender el lenguaje de modelado.
■ Fomentar el crecimiento del mercado de las herramientas 00.
■ Soportar conceptos de desarrollo de alto nivel como pueden ser colaboracion~
frameworks, patterns, y componentes.
■ Integrar las mejores prácticas utilizadas hasta el momento.

El U:v1L debe entenderse como un estándar para modelado y no como un estánda:

de proceso software. Aunque L"l\IL debe ser aplicado en el contexto de un proces
la experiencia ha mostrado que organizaciones diferentes y dominios del problem...
diferentes requieren diferentes procesos.

U~IL es un lenguaje que se puede utilizar no sólo para modelar aplicacion

software, también se puede utilizar en otros campos como:
■ Sistemas de información de la empresa
■ Bancos y servicios financieros
■ Telecomnicaciones
■ Transporte
.DO ESTRUCTURA DE UML 237

• Defensa/industria aerospacial
• Comercio
• Electrónica médica
• Ambito científico
■ Servicios distribuidos en la vVeb

)m-
6.6. Estructura de U ML
Los conceptos y modelos de Gl\iIL pueden agruparse en las siguientes áreas con-
ceptuales:
1. Estructura estática:

tili- Cualquier modelo preciso debe primero definir su universo, esto es, los concep-
tos clave de la aplicación, sus propiedades internas, y las relaciones entre cada
una de ellas. Este conjunto de construcciones es la estructura estática.

ón. Los conceptos de la aplicación son modelados como clases, cada una de las cua-
les describe un conjunto de objetos que almacenan información y se comunican
para implementar un comportamiento.

La información que almacena es modelada como atributos; La estructura está-

tes.
tica se expresa con diagramas de clases y puede usarse para generar la mayoría
de las declaraciones de estructuras de datos en un programa.

iar 2. Comportamiento dinámico:

so.
ma Hay dos formas de modelar el comportamiento, una es la historia de la vida de
un objeto y la forma como interactúa con el resto del mundo y la otra es por
los patrones de comunicación de un conjunto de objetos conectados, es decir la
11es forma en que interactúan entre sí.

La visión de un objeto aislado es una máquina de estados que muestra la forma

en que el objeto responde a los eventos en función de su estado actual. La visión
de la interacción de los objetos se representa con los enlaces entre objetos junto
con el flujo de mensajes y los enlaces entre ellos. Este punto de vista unifica la
estructura de los datos, el control de flujo y el flujo de datos.
238 UllfL. LE~G L.1\JE UNIFICADO DE MODELADO

3. Construcciones de implementación:

Los modelos m ,11 tienen significado para el análisis lógico y para la implemen-
tación física. Un componente es una parte física reemplazable de un sistema y
es capaz de responder a las peticiones descritas por un conjunto de interfaces.
Un nodo es un recurso computacional que define una localización durante la
ejecución de un sistema. Puede cont ener componentes y objetos.

4. Mecanismos de extensión:

UML tiene una limitada capacidad de extensión pero que es suficiente para
la mayoría de las extensiones que requiere el día a día sin la necesidad de un
cambio en el lenguaje básico.

Un estereotipo es una nueva clase de elemento de modelado con la misma es-

tructura que un elemento existente pero con restricciones adicionales.

5. Organización del modelo:

La información del modelo debe ser dividida en piezas coherentes, para que lo:,
equipos puedan trabajar en las diferentes partes de forma concurrente. El cono-
cimiento humano requiere que se organice el contenido del modelo en paquetes
de tamaño modesto. Los paquetes son unidades organizativas, jerárquicas y de
propósito general de los modelos de -CJVIL. Pueden usarse para almacenamiento.
control de acceso, gestión de la configuración y construcción de bibliotecas que
contengan fragmentos de código reutilizable.

6. Elementos de anotación:

Los elementos de anotación son las partes explicativas de los modelos Ul'vIL. Sor.
comentarios que se pueden aplicar para describir, clasificar y hacer observacio-
nes sobre cualquier elemento de un modelo. El tipo principal de anotación es la
not a que simplemente es un símbolo pai·a mostrar restricciones y comentarios
junto a u n elemento o un conjunto de element os.
ESTRUCTURA DE Ul\rIL 239

7. Relaciones:

Existen séis tipos de relaciones entre los elementos de un modelo Ul\/IL. Depen-
dencia, asociación, generalización, realización, agregación y composición estas
se describen a continuación.

■ Dependencia

Es una relación semántica entre dos elementos en la cual un cambio a un

elemento (el elemento independiente) puede afectar a la semántica del otro
elemento (elemento dependiente). Se representa como una línea disconti-
nua, posiblemente dirigida, que a veces incluye una etiqueta.

En el diagrama de la figura 6.1 se puede ver una relación de dependencia

entre dos clases. La clase A usa la clase B. La clase impresora usa la clase
documento.

aaseA Clase B

•l

Impresora 000.lmento
·)
-texto:stmg

tmprimir +getTexto():string
(documento:Oocumento)

Figura 6.1: Relación de dependencia

■ Asociación

Es una relación estructural que describe un conjunto de enlaces, los cuales

son conexiones entre objetos. La agregación es un tipo especial de asocia-
ción y representa una relación estructural entre un todo y sus partes. La
asociación se representa con una línea continua, posiblemente dirigida, que
a veces incluye una etiqueta. A menudo se incluyen otros adornos para
indicar la multiplicidad y roles de los objetos involucrados.
240 UAfL, LENGUAJE UNIFICADO DE MODELADO

La multiplicidad de una asociación detnmina cuantos objetos de cada tipo

intervienen en la relación, o sea. el número de instancias de una clase
que se relacionan con una instancia de la otra. Cada asociación tiene dos
multiplicidades, una para cada extremo de la relación. Para especificar la
multiplicidad de una asociación hay que especificar la multiplicidad mínima
y la multiplicida-d máxima) (mínima .. máxima). En la figura 6.2 se pueden
ver los diferentes índices de multiplicidad y su significado.

Multiplicidad Significado
1 uno y sólo uno
0 .. 1 cero o uno
N .. M desde ~ hasta M
* cero o varios
o.. * cero o varios
l..* uno o varios
(almenos uno

Figura 6.2: Multiplicidades de asociación

En la figura 6.3 se puede ver una relación de asociación. La clase A está

asociada a la clase B. La clase A necesita la clase B. La clase Taxi necesita
la clase Chofer y la clase Matrícula. Necesita 1 o varios chóferes y un sola
matrícula.

,____Clase_A_----11----------->ijl---Clase-B----I

Taxi O.Oler
1 1 ..•
-choffer:Chofer 1
-nombre:Stnng
•matricula:Matricula
1
+prlntChofe,(~Stnng ' +getNombre(~
+printMatriwla{}:string

1 Matric:ula

-numero: Slnlg

+getNumero(}:String

Figura 6.3: Relación de asociación

 ESTRUCTURA DE UML 241

tipo ■ Generalización
lase
dos Es una relación de especialización / generalización en la cual los objetos
.r la del elemento especializado (el hijo) pueden sustituir a los objetos del ele-
ima mento general (el padre). De esta forma, el hijo comparte la estructura y el
den comportamiento del padre. Gráficamente, la generalización se representa
con una línea con punta de flecha vacía.

En la figura 6 .4 se puede ver una relación de generalización. La clase A es

una generalización de la Bode la clase C. También se puede comtemplar
a la inversa y decir que la clase B y la clase C son especializaciones de la
clase A. La clase l\1oto y la clase Coche son especializaciones de la la clase
general Vehículo a Motor.

)Stá
sita
mla
due8

Moto

Figura 6.4: Relación de generalización

242 U1UL, LESGL-A.JE UNIFICADO DE 1\fODELADO EST1

• Realización

Es una relación semántica entre clasificadores, donde un clasificador espe-

cifica un contrato que otro clasificador garantiza que cumplirá. Se pueden
encontrar relaciones de realización en dos sitios: entre interfaces y las clases
y componentes que las realizan, y entre los casos de uso y las colaboracio-
nes que los realizan. La realización se representa como una mezcla entre
la generalización y la dependencia, esto es, una línea discontinua con una
punta de flecha vacía .

En la figura 6.5 se puede ver una relación de realización. La clase B es una

realización de la A. La clase Viaje realiza la interface Registrable.

<<interface»
Clase B
ClaseA

r<l

<<intefface>>
Viaje
Registrable

+Crearnuevo Vlaje():void
k}

Figura 6.5: Relación de realización

• Agregación

Es muy similar a la relación de Asociación solo varía en la multiplicidad

ya que en lugar de ser una relación "uno a uno" es de "uno a muchos".Se
representa con una flecha que parte de una clase a otra en cuya base hay
un rombo de color blanco. En la figura 6.5 se puede ver una relación de
agrupación. La Clase A agrupa varios elementos del tipo Clase B. La clase
Agenda agrupa a varios Contactos.
 ESTRUCTURA DE Ui\fL 243

aa.es

r
Clase.A

spe-
1

der.
as~

r
Agenda Contacto

cio-
rltre
1
una

Figura 6.6: Relación de agregación

■ Composición

Similar a la relación de Agregación solo que la Composición es una relación

mas fuerte. Aporta documentación conceptual ya que es una "relación de
vida'\ es decir, el tiempo de vida de un objeto está condicionado por el
tiempo de vida del objeto que lo incluye.En la figura 6.7 se puede ver una
relación de composición o agrupación.

La Clase A agrupa varios elementos del tipo Clase B . El tiempo de vida

de los objetos de tipo Clase B está condicionado por el t iempo de vida del
objeto de tipo Clase A.

Tenemos una clase Silla. un objeto Silla está a su vez compuesto por cuatro
objetos del tipo Pata. El tiempo de vida de los objetos Pata depende del
tiempo de vida de Silla, ya que si no existe una Silla no pueden existir sus
Patas.

ClaseA ciases
-
-

Silli Pata

lad
.Se
tay
de
I· 1

IBe
Figura 6. 7: Relación de composición
 244 UlvlL, LEi\-GUAJE UNIFICA.DO DE 1WODEL.4DO

8. Diagramas

Los diagramas se utilizan para representar diferentes perspectivas de un sist ema

de forma que un diagrama es una proyección del mismo. ül\lIL proporciona un
amplio conjunto de diagramas que normalmente se usan en pequeños subcon-
juntos para poder representar las cinco vistas principales de la arquitectura de
un sistema. En la siguiente sección se muestran los diferentes tipos de diagra-
mas con los que se cuenta en Ul\11

6.7. Diagramas UML

En esta sección se presentan los diagramas utilizados en üML.

6. 7.1. Diagramas de casos de uso

Los diagramas de casos de uso ilustran la funcionalidad proporcionada por una
unidad del sistema. Los diagramas de casos de uso describen las relaciones y las de-
pendencias entre un grupo de casos de uso y los actores participantes en el proceso.

Es importante resaltar que los diagramas de casos de uso no están pensados para
representar el diseño y no puede describir los elementos internos de un sistema. Lo::,
diagramas de casos de uso sirven para facilitar la comunicación con los futuros usua-
rios del sistema, y con el cliente, y resultan especialmente útiles para determinar las
características necesarias que tendrá el sistema. En otras palabras, los diagramas de
casos de uso describen qué es lo que debe hacer el sistema, pero no cómo.

Actor

"Cn actor es una entidad externa (de fuera del sistema) que interacciona con el
sistema participando (y normalmente iniciando) en un caso de uso. Los actores pue-
den ser gente real (por ejemplo, usuarios del sistema), otros sistemas o eventos.

Los actores no representan a personas físicas o a sistemas, sino su rol. Esto significa
que cuando una persona interactúa con el sistema de diferentes maneras (asumiendo
diferentes papeles) , estará representado por varios actores. Por ejemplo, una perso-
na que proporciona servicios de atención telefónica a clientes y realiza pedidos para
los clientes est.aría representada por un actor "equipo de soporte" y por otro actor
'·representante de ventas".
 DIAGRAA1AS UNIL 245

C aso de uso

Un caso de uso describe, desde el punto de vista de los actores, un grupo de ac-
tividades de un sistema que produce un resultado concreto y tangible.

Los casos de uso son descriptores de las interacciones típicas entre los usuarios
de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y
¡ra-
especifican qué requisitos de funcionamiento debe tener éste ( únicamente el qué,
nunca el cómo).

Cuando se trabaja con casos de uso, es importante tener presentes algunas senci-
llas reglas:
• Cada caso de uso está relacionado como mínimo con un actor.
■ Cada caso de uso es un iniciador (es decir, un actor).
■ Cada caso de uso lleva a un resultado relevante (un resultado con "valor intrín-
seco")

ma
de-
ISO.

ara
C,os
ua- Actor
las
de
Figura 6.8: Actor y caso de uso

En la figura 6.9 se puede ver un diagrama de casos de uso de un cajero automático

con dos actores: un cliente y un empleado de banco. Los casos de uso pueden tener
Lel
relaciones con otros casos de uso. Los tres tipos de relaciones más comunes entre
ue-
casos de uso son:
■ «include» que especifica una situación en la que un caso de uso tiene lugar
ica dentro de otro caso de uso.
tdo
• «extends» que especifica que en ciertas situaciones. o en algún punto (llamado
so-
punto de extensión) un caso <le uso será extendido por otro.
ira
tor ■ Generalización que especifica que un caso de uso hereda las características del
"super" caso de uso, y puede voh-er a especificar algunas o todas ellas de una
forma muy similar a las herencias entre clases.
246 Ui\IL, LE1\'GUAJE UNIFICADO DE ,'vIODELADO DI

Cajero automático

co
dE

6.
Cliente con tarjeta Empleado del banco

y
gi
CC
c1
ir

Figura 6.9: Diagrama de casos de uso

o
e
En la figura 6.10 se muestra el diagrama de casos de uso del cajero automáticc t,;
presentado en 6.9 extendiendo los casos de uso con las diferentes relaciones. €

-----~
Caje<o Automático
t

<<extend> ,,•
......·
~ o
<<ft"Jude>
A
Efflpleadode.Jbanco

OientecontWJe"la

Figura 6.10: Diagrama de casos de uso

DIAGRAl\lIAS Ul\lIL 247

Descripción de casos de uso

Las descripciones de casos de uso son reseñas textuales del caso de uso. Kormal-
mente tienen el formato de una nota o un documento relacionado de alguna manera
con el caso de uso, y explica los procesos o actividades que tienen lugar en el caso
de uso.

6.7.2. Diagrama de clases

Los diagramas de clases muestran las diferentes clases que componen un sistema
y cómo se relacionan unas con otras. Se dice que los diagramas de clases son dia-
gramas estáticos porque muestran las clases, junto con sus métodos y atributos, así
como las relaciones estáticas entre ellas: qué clases conocen a qué otras clases o qué
clases son parte de otras clases, pero no muestran los métodos mediante los que se
invocan entre ellas.

Clase

Una clase define los atributos y los métodos de una serie de objetos. Todos los
objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y
el mismo conjunto de atributos (cada objeto tiene el suyo propio). En ocasiones se
utiliza el término tipo en lugar de clase, pero recuerde que no son lo mismo, y que
el término tipo tiene un significado más general.

En las clases están representadas por rectángulos, con el nombre de la clase, y

también pueden mostrar atributos y operaciones de la clase en otros dos «comparti-
mentos» dentro del rectángulo.

La clase esta formada por atributos y operaciones o métodos

■ Atributos

En líl\lIL, los atributos se muestran al menos con su nombre, y también pue-

den mostrar su tipo, valor inicial y otras propiedades. Los atributos aparecen
calificados en el diagrama dependiendo de su acceso como:

•+ Indica atributos públicos

• # Indica atributos protegidos
• - Indica atributos privados
248 U1\fL, LENGüAJE UNIFICADO DE J.fODELADO

■ Operaciones
Las operaciones (métodos) también se muestran al menos con su nombre, y
pueden mostrar sus parámetros y valores de retorno. Las operaciones, al igual
que los atributos, aparecen calificados en el diagrama dependiendo de su acceso
como::

• ~ Indica operaciones públicas

• # Indica operaciones protegidas
• - ln<lica operaciones privadas
■ Plantillas

Las clases pueden tener plantillas o templates, un valor usado para una clase
no especificada o un tipo. El tipo de plantilla se especifica cuando se inicia una
clase (es decir cuando se crea un objeto).

Asociaciones de clases

Las clases se puede relacionar, (estar asociadas), con otras de las siguientes posi-
bles formas:

■ Generalización
• Asociación
■ Realización
■ Agregación
■ Composición

Los diagramas de clases pueden contener más componentes aparte de clases. Estos
pueden ser:
■ Interfaces

Las interfaces son clases abstractas, esto es, instancias que no pueden ser creadas
directamente a partir de ellas. Pueden contener operaciones, pero no atributos.
Las clases pueden heredarse de las interfaces pudiendo así realizarse instancias
a partir de estos diagramas.
DIAGRA.i\íAS U!v1L

■ Tipo de datos

Los tipos de datos son primitivas incluidas en algunos lenguajes de programa...

ción. Algunos ejemplos son: bool y float. ~o pueden t ener relación con cl~es,
pero las clases sí pueden relacionarse con ellos.

■ Enumeraciones

Las enumeraciones son simples listas de valores. Un ejemplo típico de esto sería
una enun1eración de los días de la semana. Al igual que los tipos de datos, no
pueden relacionarse con las clases, pero las clases sí pueden hacerlo con ellos.

■ Paquetes

Los paquetes, en lenguajes de programación, representan un espacio de nombres

en un diagrama se emplean para representar partes del sistema que contienen
más de una clase, incluso cientos de ellas.

En la figura 6.11 se presenta un diagrama de clases.

listacliemes

E'! Em resa
Attnbutu
- nombre : String
- d,recc,on : String
es na
§ Helado
Art.ribc,,te-.s
- sabor : Suing
- precio : String
1 • - codigo : Stnng

§:!Persona 0-s
A ttribul' ~s
- nombre : Smng § Compra
- ~ula : String Antiburn uene
- cantidad : String
1
- totalcompra : String
Optn1io.ns

Figura 6.11 : Diagrama de clases

250 UAIL, LE.YGüA.JE U1VIFICA. DO DE ñ.,fODELADO

6.7.3. Diagramas de secuencia

Los diagramas de secuencia muestran el flujo de mensajes (es decir la forma en
que se invocan) entre objetos para un determinando caso de uso. Los diagramas
de secuencia ponen especial énfasis en el orden y el momento en que se envían los
mensajes a los objetos. El propio diagrarna explica la secuencia de llamadas que se
producen entre los objetos que intervienen. Pueden tener mayor o menor detalle y
representar diferentes llamadas a diferentes objetos.

Los diagramas de secuencia tienen dos dimensiones: la vertical muestra la secuen-

cia de llamadas ordenadas en el tiempo en el que ocurren. La dimensión horizontal
muestra las diferentes instancias de objetos a las que son enviadas las llamadas.

En la figura 6.12 puede verse una secuencia de invocaciones para el dibujo de el

botón de una ventana de una aplicación.

En los diagramas de secuencia, los objetos están representados por rectángulos

con el nombre del objeto dentro y por líneas intermitentes verticales, con el nombre
del objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose
hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma
de flechas con los nombres de la operación y los parámetros. Es conveniente dibujar
una flecha de retorno de la llamada.

1 a • Aplicacion 1
~v-•_ve_n_ta_n_ª~I ~l_b_:_B-□t_□_n~
... Draw()
''
' DraW() ''
'
-' Paint()
,~
,;' 1

.,
-'
'''
''
- ''
,

Figura 6.12: Diagrama de secuencia simple de dibujo de aplicación

Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje
DO DI.4..GRA.l\L4..S U~1L 251

donde se pasa el control a objeto llamado hasta que el método finalize, o asíncro-
nos donde se dev71elve el control directa.mente al objeto que realiza la llamada. Los
. ec
mensajes síncronos tienen una caja vertical en un lateral del objeto invocante que
nas
1~
muestra el flujo del control del programa.
~se
ey

en-
ttal
'"•adOI"

1 · Mu.-.e pieza □ □□
1
1
1.1 mu- pieza
1
1
1
- 1
1
1
1
1
t
l ,.I'r.í1 ¿Esvalido?
1
1
i el 1 1.2· Refr•sc.ar pantalla 1
1
IJ .....
1
1
1 2· Que mueva el ordenado~ 1

los i
1
)re 1 1.2 1 Mahzar tablero

)Se L,J 1 2 2 lolueva

na 1.2.2 1 Refrescar pantalla

Jar
1( ....1
1 1
1 1 1
1 1 t
1 1 1
1 1 1
.... 1 1 1

Figura 6.13: Diagrama de secuencia. de jugada de ajedrez

6. 7 .4. Diagramas de colaboración

Los diagramas de colaboración muestran las interacciones que ocurren entre los
objetos que participan en una situación determinada. Esta es más o menos la misma
información que la mostrada por los diagramas de secuencia, pero destacando la
forma en que las operaciones se producen en el tiempo, mientras que los diagramas
de colaboración fijan el interés en las relaciones entre los objetos y su topología.
En los diagramas de colaboración los mensajes enviados de un objeto a otro
se representan mediante flechas, mostrando el nombre del mensaje, los parámetros
y la secuencia del mensaje. Los diagramas de colaboración están indicados para
mostrar una situación o flujo programa específicos :, son unos de los mejores tipos
de diagramas para demostrar o explicar rápidamente un proceso dentro de la lógica
re del programa.
252 UAJL, LESGC4..JE UNIFICADO DE MODELADO

En las figuras 6.14 y 6.15 pueden verse los diagrams de secuencia y el respectivo
de colaboración del caso de uso de alta de un préstamo en una biblioteca.

'
1 , : &11:uentra
'
1
•: !ncuentn: en l

Figura 6.14: Diagrama de secuencia de gestión de préstamo de biblioteca

~
1: Encuentra Titulo()
3: Encuentra Artócuio()
5: !dentidad Presta!(}

:Bíblictecario
~
6: Enroentra(S~

cion prestataoo, Articulo)

:Información del :Préstamo

prestatario

Figura 6.15: Diagrama de colaboración de gestión de préstamo de biblioteca

DIAGR...AJHAS UlvIL 253

6.7.5. Diagrama de estado

Los diagramas de estado muestran los diferentes estados de un objeto durante su

,·ida, y los estímulos que provocan los cambios de estado en un objeto.

Los diagramas de estado ven a los objetos como máquinas de estado o autómatas
finitos que pueden estar en un conjunto de estados finitos y que pueden cambiar su
estado a través de un estímulo perteneciente a un conjunto finito. Todos los objetos
tienen un estado pero no todos los objetos son susceptibles de generar un diagrama
de estados. Sólo aquellos que que presenten "estados interesantes", es decir tres o más
estados, deberán ser modelados en su diagrama de estados.

La notación de un diagrama de estados tiene cinco elementos básicos:

■ P unt o de inicio: dibujado con un círculo relleno

■ Transición entre estados: dibujado con una línea terminada con punta de flecha
abierta

■ Estado: dibujado con un rectángulo con los vértices redondeados

■ Punt o de decisión: dibujado con un círculo no relleno

■ Puntos de terminación: dibujados con un círculo con otro relleno en su interior

P ara dibujar un diagrama de estados se debe cornenzar por el punto de inicio

y una línea de transición que lleve hasta el primer estado del objeto. Después se
dibujan cada uno de los estados distribuidos por el diagrama y se conectan con las
línea de transición de estados.

Hay dos tipos especiales de estados: inicio y fin. Son especiales en el sentido de
que no hay ningún evento que pueda devolver a un objeto a su estado de inicio: y de
la misma forma no hay ningún evento que pueda sacar a un objeto de su estado de
fin.
En las figura 6.16 puede verse el diagrama de transición de estados de un teléfono.
254 Ul\JL, LESGUAJE UNIFICADO DE MODELADO

Estado
lnieiaJ ( Hab,ando )1------)@
colgar f
co'9llr y
descolgar/

Tono
Uamando

colgar y
descot9ar /
marcar/

Espet"ondo
ocupado/

~ Estado
Í..__F_in_a_1_ .....

Figura 6.16: Diagrama de transición de estados de un teléfono

En las figura 6.17 puede verse el diagrama de transición de estados del acceso con
tarjeta con dos puntos de bifurcación.

Arranque del
sistema
Esperar
tarjeta

Esperar
dave
[no)
¿clave
Correcta?
Permitir
acceso

Figura 6.17: Diagrama de transición de est ados de sistema de accesos

 :>!AGRAMAS Uj\fL 255

6.7.6. Diagrama de actividad

Los diagramas de actividad describen la secuencia de las actividades en un siste-

:na. Los diagramas de actividad son una forma especial de los diagramas de estado,
~ue únicamente contienen actividades. Los diagramas de actividad son similares a
.os diagramas de flujo procesales, con la diferencia de que todas las actividades están
·laramente unidas a objetos. Los diagramas de actividad siempre están asociados a
Jna clase, a una operación o a un caso de uso.

Los diagramas de actividad soportan actividades tanto secuenciales como parale-

.as. La ejecución paralela se representa por medio de iconos de fork/ espera, y en el
caso de las actividades paralelas, no importa en qué orden sean invocadas (pueden
-:er ejecutadas simultáneamente o una detrás de otra).

Actividad

Una actividad es un único paso de un proceso. Una actividad es un estado del sis-
tema que t iene actividad interna y, al menos , una transición saliente. Las actividades
también pueden tener más de una transición saliente, si tienen diferentes condiciones.
~on
Las actividades pueden formar jerarquías, lo que significa que una actividad pue-
de estar formada de varias actividades "de detalle", en cuyo caso las transiciones
entrantes y salientes deberían coincidir con las del diagrama de detalle.

Los diagramas de actividad son indicados para modelar procesos de alto nivel.
Son indicados para modelizar el proceso de negocio de una compañía. Su complejidad
técnica es menor y son más fáciles de entender por quien no tiene muchos conoci-
mientos técnicos de computación.

Los elementos para definir un diagrama de actividades son similares a los usados
en los diagramas de secuencia. Círculo relleno de inicio: rectángulos con los bordes
redondeados para determinar las actividades, flechas conectoras para unir las ac-
tividades, puntos de decisión con círculo huecos. Cómo elemento distinto aparecen
las líneas divisorias o calles para establecer las responsabilidades entre los distintos
objetos del sistema.

En la figura 6.18 se muestra un diagrama de actividades para la gestión de pedidos

en una empresa
256 Ul\-1L , LE_VGC.:.-1.JE UNIFICADO DE MODELADO

Cliente Vendedor Almacén

Realizar
Pedido

Tomar
Ped ido
Preparar
Pago
Pedido

Distribuir
Pedido
Recoger
Ped ido

Figura 6.18: Diagrama de secuencia de actividad

6. 7. 7. Diagramas de componentes

Los diagramas de componentes muestran los componentes del software (ya sea
las tecnologías que lo forman como Kparts, componentes CORBA, Java Beans
simplemente secciones del sistema claramente distintas) y los artilugios de que est ...
compuesto como los archivos de código fuente, las librerías o las tablas de una base
de datos.
Los componentes pueden tener interfaces (es decir clases abstractas con operacio-
nes) que permiten asociaciones entre componentes.
Los Diagramas de Componentes ilustran las piezas del software, controladore:,
embebidos, etc. que conformarán un sistema. Un diagrama de Componentes tiene ur:
nivel más alto de abstracción que un diagrama de clase. Usualménte un componem
se implementa por una o más clases (u objetos) en tiempo de ejecución. Estos so&
bloques de construcción, como eventualmente un componente puede comprender nna
gran porción de un sistema.
 DIAGRAMAS Ui\iL 257

Product

Ordec Cus.tomer

Payment

,_
,_

Account:Oetsíl-s

Aeco:unf

Figura 6.19: Diagrama de componentes

~a
o
;á Este diagrama queda fuera del alcance del programa de la a.signatura.
,e

}-

6. 7 .8. Diagrama de despliegue

n El diagrama de despliegue muestra cómo el sistema se asentará físicamente en el

e entorno hardware que lo acompaña. Su propósito es mostrar dónde los componentes
n del sistema se ejecutarán y cómo se comunicarán entre ellos. Este será un diagram
a muy utilizado por el las personas que procluzcau el sistema. La notación que utiliza
es la misma que el diagrama. de componentes. S<" puede ver en la figura 6.20
258 UAIL, LE,\GC.lJE L-:VIFIC..WO DE AIODELADO

W ~ J ..,..._ _

·•.
··k,~.
r ª''""*

- · · -· · .. . . . ,. i-~ -·~:-~
~--,... ·- . . . ;;;__ ¡
=-Cllll.
db1.,,,,.....- , 082 6111_,._ : --1

Figura 6.20: Diagrama. de despliegue

Este diagrama también se sale fuera del aJcance de esta asignatura.

6.8. Conclusiones
En este capítulo se ha presentado el lenguaje UML, sus orígenes, sus objetivo,
y sus principales elementos para la especificación y diseño de sistemas softwar<'. E
reco1Tido realizado facili ta al lector unos conocimientos mínimos que le permitru
aplicar E'Sta notación para las tareas de especificación y diseño que se han abordad
en los capítulos anteriores.

6.9. Ejercicios propuestos

ReaJícense todos los diagramas U~IL necesarios para la completa especificación \
diseño de los siguientes sistemas software:

l. El programa "hola mw1do"

2. La práctica del calendario de la asignatura Fundamentos de Programación

3. "Cn sistema de gestión de clientes, y proveedores de una empresa

4. Videojuego de las minas del capítulo anterior

 EJERCICIOS PROPUESTOS 259

0. La estación meteorológica del capítulo anterior

6. Sistema de acceso con tarjeta, teclado y pantalla

'05
El
an
do
 Capítulo 7

La Codificación del Software

7. 1. Introducción
La fase codificación constituye el núcleo central de cualquiera de los modelos de
desarrollo de software: ciclo de vida, uso de prototipos, modelo en espiral. Gna vez
especificado y diseñado, de forma parcial o total, un determinado programa llega el
momento de construir el código, es decir de prograJnar. Hasta el década de los 70,
en el desarrollo de software prácticamente todo el trabajo se centraba en la fase de
codificación. Actualmente, también sucede lo mismo al desarrollar pequeños sistemas
que son realizados enteramente por una única persona en un plazo de tiempo muy
breve. Simplificando, se puede decir que las etapas previas de análisis y diseño tienen
como misión fundamental la de organizar y traducir los requisi tos del cliente en
•unidades o módulos de programa que puedan ser codificados de forma independient e
y sencilla. La importancia de la fase de codificación dentro del desarrollo de software
es evidente si se tiene en cuenta que en ella se elabora el producto fundamental de
todo el desarrollo: los programas fuente.

7.2. Objetivos
Codificar es el proceso de expresar un programa de computadora en un lenguaje
de programación. Sin embargo construir un programa no es sólo codificar, también
implica las tareas de verificación, depuración y pruebas de ese programa. En este ca-
pítulo nos centraremos en estudiar únicamente la tarea de codificación. Los objetivos
específicos son los siguientes:

• Analizar los lenguajes de programación más utilizados y agruparlos por sus

características comunes.

261
262 L.4 CODIFICACIÓN DEL SOFTWARE

• Estudiar los recursos de programación que nos ofrecen los leguajcs y las técnicru,
de implementación a las que dan lugar.
• Repasar algunos de los criterios habitualmente utilizados para elegir un deter-
minado lenguaje de programación.

7 .3. Los lenguajes de programación

Existen diferentes formas de comunicación entre los humanos y las computadora.,
que de una forma u otra nos permiten modificar el comportamiento de una compu-
tadora y, por lo tanto, de programarla. Según la guía Swebok se pueden diferenciar:
• Lenguajes de configuración, en los que el ingeniero de software elige un con-
junto de parámetros entre una serie de opciones predefinidas. Los ficheros de
configuración de Cnix o \\.indows son un ejemplo.
• Lenguajes de caja de herramientas o "toolkits'' que se utilizan para construir I
aplicaciones a partir de la combinación de un conjunto de piezas preprogra- t
madas, llamados "toolkit.''. También se les llama lenguajes de programación de (

aplicación. (

é
• Lenguajes "script" o también llamados macros o ficheros por lotes (·'batch").
j
• Lenguajes de programación propiamente dichos, que nos permiten construir un- I
aplicación completa y son muy flexibles. Nos centraremos en este apartado ec
ellos. (

Aunque la historia de los computadores es r elativamente reciente, son cientos y cieL- I

:,
tos los lenguajes de progra1nación que han sido diseñados con los más diversos oh-
(
jetivos. La utilidad de la mayoría de ellos ha sido meramente experimental o d
investigación. Sólo un número relativamente pequeño de ellos se utiliza o has :;id
utilizado en el desarrollo de software a escala industrial. El estudio detallado de ta:.
sólo los dos o tres más representativos queda fueras de los objetivos de este libr
Incluso resulta difícil realizar una clasificación coherente en la que cada lenguajf' _
é
pueda catalogar indiscutiblemente dentro df' un grupo concreto y determinado. fl
(
estudio de la. eYolución histórica de los lenguajes de programación en una buena ma-
I
nera de adquirir una visión panorámica de los mismos. En todo caso, dentro de e::,
evolución se suelen distinguir cuatro generaciones de lenguajes que se solapan en ,..
tiempo. Los leguajes de las nue\"as generaciones coexisten con los de las generacione::: t
anteriores hasta que se imponen por completo los de mejores prestaciones. J

7 .3. l. Primera generación de lenguajes (

Los primeros computadores eran máquinas de \-álvulas tremendamente costo~aE (

y los programas que podían ejecutar eran muy pequeños. La programación se l a- (

 LOS LENGUAJES DE PROGRAMACIÓN 263

cía introduciendo directamente en su memoria el escaso número de instrucciones del

programa en forma de códigos binarios. Para realizar esta labor era esencial conocer
la estructura interna del computador; tarea esta que estaba reservada a un número
,er-
reducido de personas.

Durante la década de los 50 el número de computadores disponible aumentó y

la tarea de su programación empezó a tener entidad propia. Para simplificar esta
labor tan tediosa y disminuir las posibilidades de error se crearon los lenguajes en-
r~ sambladores. Un lenguaje ensamblador consiste fundamentalmente en asociar a cada
!)U- instrucción del computador un nemotécnico que recuerde cuál es su función. Estos
1ar nemotécnicos constituyen un lenguaje algo más próximo al ser humano que el puro
código máquina a base de unos y ceros. Los ensambladores se consideran la primera
Dn-
generación de lenguajes; con un nivel de abstracción muy bajo.
d
Actualmente, con cada nuevo computador que se diseña; el fabricante debe pro-
·urr porcionar de forma inmediata su correspondiente ensamblador. Por tanto existen
;ra- tantos ensambladores como computadores distintos. La programación en ensambla-
d ... dor resulta compleja, da lugar a errores difíciles de detectar; exige que el programa-
dor conozca bastante bien la arquitectura del computador y sobre todo se necesita
adaptar la solución a las particularidades de cada computador concreto. Sólo esté
justificada la utilización del ensamblador en aquellos casos en los que no se puede
ma programar con ningún lenguaje de alto nivel. Esta situación es cada día más rara y
ei: se da fundamentalmente cuando se requiere una optimización del código para apli-
caciones con especificaciones muy críticas de tiempo real. En cualquier caso, solo se
en- programaran en ensamblador pequeños fragmentos de programa que se podrán in-
ob- sertar, en forma de macros o subrutinas, dentro del programa escrito en un lenguaje
d~ · de alto nivel.
idc
tan 7.3.2. Segunda generación
>ro.
i se
El aumento de la capacidad de memoria y disco de los computadores hizo posible
E~ abordar programas más grandes y complejos, Cuando estos programas se realizaban
na- enteramente en ensamblador resultaban muy difíciles de depurar, entender y mante-
:sta ner, lo que aumentaba los costes y el tiempo de desarrollo. A finales de la década de
1 el
los 50 se comenzaron a desarrollar los primeros lenguajes de alto nivel. Su caracterís-
nes tica más notable era que no dependían de la estructura de un computador concreto
y por primera vez se programaba en 'alto nivel' de manera simbólica.

Esta segunda generación de lenguajes suponf' un paso trascendental en la creación

de herramientas para el desarrollo de software. Con ellos, se incorporan los primeros
>Sas elementos realmente abstractos. Por ejemplo, aparecen tipos de datos {numéricos o de
ha- caracteres) no soportados directamente por las instrucciones de la máquina. También
264 L4 CODIFTCACIÓN DEL SOFTlVARE I

se puede ignorar en parte la organización interna <le la memoria del computador µar a
pasar a. trabajar con variables simbólicas rlf' distintos tamaños y estructurac., ( vecto-
res o matricf's) según las necesidades de cada programa. Además se dispone de la.'-
primcras estructuras de control para la definición <le bucles genéricos o la selección
entrf' \·arios caminos alternativos de ejecución, etC'. Todo esto l1izo que estos leuguajc>:-
alcanzaran inmediatamente una amplia difusión y que se utilizaran de forma masi,·a.
TodaYía hoy se utilizan estos nlisrnos lenguajes o alguno de sus descendientes direc-
tos de la tercera generación. Algunos de los lenguajes más representativos de f'sta
generación son FORTRAK, COBOL, ALGOL y BASIC.
• FORTRAN (FOfunula TRANslator): 7
Es un lenguaje que fue pensado para programar fundamentalmente aplicacioue--
científicas o técnicas en las que tiene una gran importancia el cálculo nun1éri-
n
co. Con el paso de los afios se han sucedido diversas versiones: FORTRAN-!\.
FORTRAX-66, FORTRAK-77, FORTRAN-90 quf' han ido corrigiendo df'fi-.
n
ciencias anteriores y se han adaptado a las nuevas propuestas rnetodológica.--
d
incorporadas por otros lenguajes. Desde el punto de vista metodológico, un,.
p
deficiencia importante que todavía conserva FORTRAN es el manejo casi di-
H
recto de la memoria mediante la sentencia CO~IlVIOI\".
A pesar de su origf'n científico, FORTRAK se ha utilizado y se continúa uti- p
lizando en el desarrollo de una amplia rama de aplicaciones de todo tipo que lE
incluyen la realización de sistemas df' gestión de bases de datos, sistema::, en
tiempo real, etc. v,
• COBOL (Cümmon Business-Orientf'd Lenguage): d

Es el lengua.je con el que están escritos casi todos los sistemas para el procf'Sa-
miento de información ( contabilidad, nominas; facturación, control de almact i .
etc). Hay que tener en cuenta que este tipo <le sistemas supone más del 70
de todo el software que se desarrolla. Aunque actualmente se continúa utiliza.1-
do COBOL pa1·a estos desarrollos, los lenguajes df' la cuarta gf'nf'ración f'sta::.,
consiguiendo despla:,,arlo pa.ulatinament,e.
■ ALGOL:
Se considera el precursor de muchos de los lenguajes de la tercera generació1.
espf'cialmente de Pascal y todos sus descendientes, tales como ;\fodula.-2 y AcL
Se puede decir que es el primer lenguaje que da una gran importancia a la t1:-
ficación de datos. También en este caso existen divf'rsa.c., versiones: ALGOL6 l
ALGOL-68, aunque su difusión a nivf'I industrial o comercial no ha sido ax:_
importante como t->n el e-aso de FORTRAX.
• BASIC:
Fue pt->nsado para la enseñanza de la programación y f'S <lf' destacar su sencill
y facilidad de aprendizaje, Gracias a los escasos recursos que necesitaba
 :.OS LENGUA.JES DE PROGRA.AIACIÓN 265

intérprete de BASIC, con la llegada de los primeros c-omputadores de sobremesa

se produjo una rá.pida difusión de este lenguaje y con él se desarrollaron las
aplicac-iones más diversas. Son innumerables las versiones que existen de este
lenguaje y en algunas de ellas se incorporan herramientas de tocio tipo. Por
ejemplo, existen versiones para trabajar con distintos tipos de bases de elatos,
con entornos de ventanas {windows) o incluso para aplicaciones de tiempo real.
Estas versiones han siclo desarrolladas fundamentalmente para trabajar con los
actuales computadores personales.

7.3 .3. Tercera generación

A esta generación pertenecen gran parte de los lenguajes que se utilizan actual-
mente para el desanollo de software. A finales de los 60 y principios de los 70 se
1·onsolidan las bases teóricas y prácticas de la programación estructurada. Con esta
nueva metodología, la programación pierde definitivamente su considcración de ''arte"
destinado a demostrar las habilidades del programador para c-onvertirse en una tarea
proclucti,·a que se debe realizar de forma metódica y sin concesioncs a la genialidad.
di- Hay que tener en cuenta que ya entonccs el número de personas que participaban
Pn el desarrollo <le un nuevo compilador, sistema operativo u otro tipo de aplicación
1ti- podía ser de varias decenas. Aparece así, la neccsidacl de una nueva generac-ión de
1u l<'nguajes fuertemente tipados, que faciliten la estructuración de código y datos, con
en redundancias entre la dcclaJ·ación y el uso ele cada tipo de dato. Con ello se facilita la
,·crificación en compilación de las posibles inconsistencias de un programa. Algunos
de los lenguajes más-importantes de esta generación son las siguientes:

:sa- ■ PASCAL
én.
Aparece en 1971 y se puede considerar el primer lenguaje de esta gencración.
)
Aunque fue diseñado fundamentalmente para la enseñanza de la programación
an- estn1cturada, su sencillez y buenas prestaciones hizo que pronto se utilizara
tár
también para el desarrollo de todo tipo de aplicaciones científic-o-técnicas o de
sistemas. Pascal permite la estructuración del código mediante procedirnicntos
o funciones que se pueden definir de manera recursiva La tipificación de datos es
ny
bastante rígida y no se contempla en forma apropiada la compilación separada.
da ■ MODULA-2
,pi-
50. Es el descendiente más directo de Pascal :-· con su diseño se trataban de pa-
tau liar las carenc-ias más importantes de su pn'<lecesor. Ambos lenguajes han sido
diseñados por Kiklaus ,virth. Las deficiencias fundamentales de Pascal se de-
ben a que no fue pensado coma un lcnguaje para el desarrollo de software a
gran escala, En ~odula-2 se incorpora la estructura de módulo y queda sepa-
llez rada la especificación del módulo de su r<'aJi.,,ación concreta. Esto facilita una
un compilación segura y permite la ocultación de los detalles ele implementación.
266 L...\ CODIFICACIÓN DEL SOFT\VARE

Con l\,1odula-2 se facilita enormemente la aplicación inmediata de los concep-

tos fundamentales de diseño: modularidad. abstracción y ocultación. Además.
:Vlodula-2 incorpora ciertos mecanismos básicos de concurrencia. Al cont rariL
de lo que sucedió con Pascal, la utilización de Ivlodula-2 para el desarrollo de
aplicaciones es todavía más bien escasa .

•e
Aparece en 1975 y su desarrollo es prácticamente paralelo a Pascal. Original-
mente fue diseñado para la codificación del sistema operativo U~IX. Poste-
riormente ha sido utilizado ampliamente para desarrollar software de sistem~
y aplicaciones científico-técnicas de todo t ipo. A pesar de su consideración de
lenguaje de alto nivel, posee ciertas características que le hacen muy flexible ~
capaz de optimizar el código tanto como si se utilizara un lenguaje ensamblador
Por otro lado, esto mismo hace que deba ser utilizado con bastante cuidadc.
Por ejemplo, la importancia de los punteros dentro del lenguaje y su íntima
relación con vectores, matrices y en general con el manejo casi directo de 1~
memoria, puede tener resultados desastrosos si no se toman las debidas pre-
cauciones. También posee un conjunto de operadores muy amplio que permiv·
hacer cualquier cosa con cualquier tipo de dato sin apenas ninguna restricción.
Esto puede dificultar bastante la depuración de un programa cuando se utiliza!:
indiscriminadamente.

■ ADA
Es el lenguaje patrocinado por el Departamento de Defensa de los EEUu, priL.-
cipal consumidor de software del mundo, para imponerlo como estándar ~
todos sus desarrollos de sistemas con computador englobado ("embedded com--
pnter systems") y de tiempo real. Es un descendiente de Pascal mucho ma.:-
potente y complejo. Aunque desde principios de los 80 se viene hablando ck
las ventajas de Ada coma lenguaje universal, todavía no está suficientemcnr,...
extendido. Esto se ha debido fundamentalmente a la dificultad de aprendiza_;
de un lenguaje tan complejo y a que la puesta a punto de los compiladores h..
requerido más tiempo del previsto. Los packages de Ada facilitan la codificaciór
de un diseño modular y la aplicación de los conceptos de abstracción y oculta-
ción. Ada permite la definición de elementos genéricos y dispone de mecanism~
para la programación concurrente de tareas y la sincronización y cooperació::.
entre ellas.
Dentro de esta misma generación y de forma paralela, se han ido desarrollanC:.-
lenguajes asociados a otros paradigmas de programación o modelos abstracto--
de computo (orientación a objetos, funcional o lógico) como enfoques alternan-
vos a la programación imperativa representada por Pascal , C, Nlodula-2 y Ad&.
Los lenguajes que soportan estos paradigmas tienen una aplicación bastanr_
 LOS LENGUAJES DE PROGRANIACIÓN 267
'E

[r
orientada hacia el campo para el cual han sido diseñados. Algunos de los más
s. representativos son los siguientes:
10
■ SMALLTALK
le
Este lenguaje es el precursor de los lenguajes orientados a objetos. Aunque las
primeras versiones son de principios de los 70, los entornos de trabajo disponi-
bles eran deficientes y su difusión fue muy limitada. Durante la década de las
80 las estaciones de trabajo con pantallas gráficas y procesadores más poten-
J- tes permitieron disponer de entornos más amigables y las nuevas ,.-ersiones d el
e- lenguaje alcanzan mayor difusión .

le • e++
y Es un lenguaje que incorpora al lenguaje C los mecanismos básicos de la pro-
,r. gramación orientada a objetos: ocultación, clases, herencia y polimorfismo. Con
o. este lenguaje se trata de aprovechar la amplia difusión que tiene C y facilitar su
la utilización cuando se emplean técnicas de análisis y diseño orientadas a objetos.
la
e- ■ JAVA
te El lenguaje de programación Java fue originalmente desarrollado en 1995 por
n. Sun Microsystems (la cual fue adquirida posteriormente por la compañía Ora-
lil cle). Su sintaxis deriva mucho de C y C- f-, pero tiene menos facilidades de
bajo nivel que cualquiera de ellos. Las aplicaciones de Java son generalmente
compiladas a un pseudocódigo que puede ejecutarse en cualquier máquina vir-
tual Java (JV~1) sin importar la arquitectura de la computadora subyacente.
[1-
Es un lenguaje de programación de propósito general, concurrente, orientado
m a objetos y basado en clases que fue diseñado específicamente para tener tan
[1-
pocas dependencias de implementación como fuera posible. Su intención es per-
á.s mitir que los desarrolladores de aplicaciones escriban el programa una vez y lo
ie ejecuten en cualquier dispositivo (conocido en inglés como \VORA., o "write
te once: run anywhere"), lo que quiere decir que el código que es ejecutado en
Je
una plataforma no tiene que ser recompilado para correr en otra. Java es, a
la partir de 2012, uno de los lenguajes de programación más populares en uso,
)Il
particuJarmente para aplicaciones de cliente-servidor de web.
a- ■ EIFFEL
:)S
Este lenguaje de finales de las 80 supone probablemente el intento más serio de
in
diseño de un lenguaje completamente nuevo orientado a objetos, tomando como
estructura básica de partida un lenguaje imperativo estructurado. Eiffel permite
lo la definición de clases genéricas, herencia múltiple y polimorfismo. Aul).que su
:)S difusión todavía no es muy grande es previsible que la adquiera en un futuro
próximo.
a.
te
268 L.-1 CODIFICA.CIÓ2V DEL SOFTl-l~4.RE

• LISP
Es el precursor de 105 lenguajes funcionales. Las primeras versiones aparecie-
ron junto a los lenguajes de 2ª generación. Aunque actualmente compiten con
él un gran número de lenguajes funcionales, continúa siendo uno de los má.,
utilizados en aplicaciones de inteligencia artificial y sistemas expertos. En LISP
todos los datos se organizan en forma de listas y para su manejo se emplean
exclusivamente funciones, que normalmente son recursivas LISP está pensado
especialmente para la manipulación de símbolos, demostración de teoremas y
resolución de problemas teóricos.

■ PROLOG
Este lenguaje es el representante más importante de los lenguajes lógicos y se
utiliza fundamentalmente para la construcción de sistemas expertos. En el desa-
rrollo de la propuesta de 11 quinta generación'1, el lenguaje PROLOG se tomó
como un punto de arranque. Los elementos fundamentales que utifüm son: he-
chos y reglas; ambos constituyen la base de la representación del conocimiento.
A partir de ellos se pueden inferir nuevos hechos o reglas que se incorporan a la
base del conocimiento. Cuando el número de hechos y reglas crece) el proceso
de inferencia puede resultar tremendamente costoso y lento.
Existen en el mercado una gran variedad de lenguajes de marcas. Estos lengua-
jes no son propiamente lenguajes de programación, aunque suele confundirse
con ellos. Estos lenguajes permit~n codificar un documento con una serie de eti-
quetas o marcas que aportan información adicional o estructural al documento.
El ejemplo más conocido es el HTlv1L, que permite crear páginas web a tra-
vés de documentos con marcas que son interpretadas por el navegador. ExistPn
1nuchos otros tipos, especialmente para la edición de textos como el TEX, perc
también para aplicaciones gráficas, matemáticas, de música, etc.

7 .3.4. Cuarta generación

Los lenguajes de la cuarta generación (L4G) tratan de ofrecer al programador un
mayor nivel de abstracción, prescindiendo por completo del computador. Normal-
mente estos lenguajes no son de propósito general y en realidad se pueden considerar
herramientas específicas para la resolución de determinados problemas en los c&;o:=c
más diversos. Se trata de lograr que cualquiera, sin grandes conocimientos sobre pro-
gramación de computadores, pueda utilizar estos lenguajes para realizar aplicacione-c
sencillas. Por otro lado, no es aconsejable utilizar estas herramientas para desarrollar
aplicaciones complejas debido a lo ineficiente que resulta el código que generan. EL
todo caso, se pueden utilizar para la realización de prototipos que postcriormcntP
serán mejorados con lenguajes de la tercera generación.
 LOS LE1VGUAJES DE PROGRANIACIÓN 269

Desde hace más de veinte años han venido surgiendo lenguajes o herramientas.
1e- La amplia difusión de los computadores personales de altas prestaciones (potencia
011
de cálculo, pantalla gráfica, etc), así corno el uso generalizado de Internet y la consi-
l~
guiente necesidad de aplicaciones 11 web'1 , han sido determinantes para su desarrollo
3P más amplio. Sería tremendamente prolijo hacer una relación de herramientas (la
at
mayoría de ellas tienen marcas comerciales) e incluso resulta difícil establecer una
do clasificación. t:na posible agrupación según su aplicación concreta sería la siguiente:

■ BASES DE DATOS
Estos lenguajes permiten acceder y manipular la información de la base de
datos mediante un conjunto de órdenes de petición (Qt:ERY) relativamente
sencillas. Con estas órdenes se pueden establecer condiciones para el simple
se
acceso a determinados datos, se pueden agrupar datos que verifican una deter-
;a-
minada relación entre ellos, se pueden efectuar cálculos entre los datos u otras
nó
operaciones mucho más sofisticadas. La ventaja fundamental de estos lenguajes
1e-
es que dotan de una gran versatilidad a la base de datos y permiten que pueda
:o.
ser el propio usuario quien diseñe sus propios listados, informes, resúmenes,
la
cálculos, etc., cuando las necesite.
so
■ GENERADORES DE PROGRAMAS
a- Con ellos se pueden construir elementos abstractos fundamentales en un cierto
se campo de aplicación sin descender a los detalles concretos que se necesitan en
ti- los lenguajes de la tercera generación. La generación de los correspondientes
º· programas, en algún lenguaje de la tercera generación, se realiza de acuerdo a
a- un conjunto de reglas que se establecen a priori y que dependen del lenguaje
destino. Evidentemente, el programa generado se puede modificar o adaptar
ro cuando la generación automática no resulta completamente satisfactoria. Con
la utilización de estos lenguajes siempre se produce un ahorro considerable de
tiempo de desarrollo. La mayoría de los generadores de programas sirven para
realizar aplicaciones de gestión y el lenguaje destino es COBOL. Sin embargo,
también se han desarrollado herramientas CASE para diseño orientado a objeto
Lll que se pueden utilizar para aplicaciones de sistemas y que generan programas
1- en C, C-+ ó Ada.
'l.r
)S
■ CÁLCULO
)- Existe una amplia gama de herramientas de cálculo destinadas a simplificar
~s las más diversas tareas científicas o técnicas. Inicialmente estas herramientas
tr fueron simplemente aplicaciones más o menos sofisticadas que ofrecían distin-
:n tos métodos o algoritmos para resolver un problema concreto en el campo de
;e la estadística. la investigación operativa. el control, etc. Sin embargo, algunas
de estas herramientas han evolucionado de tal manera que se han converti-
do en verdaderos L4G. Con ellos se puede programar prácticamente cualquier
270 L.4. CODIFICACIÓN DEL SOFT\iVARE

problema dentro de un determina.do campo. Como ejemplos concretos se pue-

den citar los siguientes: hojas de cálculo, herramienlas de cálculo matemático.
herramientas de simulación y diseño para control; etc.

■ OT ROS
En este grupo se pueden englobar todo tipo de herranüentas que permitan
una programación de cierta complejidad y para ello utilicen un lenguaje. Como
ejemplos concretos se pueden citar las herramientas para la especificación y veri-
ficación formal de programas, lenguajes de simulación; lenguajes de prototipos,
etc.

7.4. Criterios de selección del lenguaje

Después del repaso a las diferentes prestaciones que ofrecen los lenguajes no pa-
rece sencilla la selección de uno determinado para el desarrollo de un proyecto. El
lenguaje de programación es probablemente uno de los elementos más importantes
de cualquier desarrollo, puesto que es la herramienta de trabajo que utilizarán mayor
número de personas y que además tiene una influencia decisiva en la depuración y
mantenimiento de la aplicación. A priori, en la decisión deberían prevalecer los cri-
terios técnicos, pero existen otros factores de tipo operativo que deben ser tenidos
muy en cuenta. Algunos de los criterios de selección que deberían ser analizados son
los siguientes:

■ Il\IPOSICIÓ)I DEL CLIENTE

En algunos casos es directamente el cliente el que fija el lenguaje que se debe
utilizar. Las razones para esta imposición pueden ser de diversa índole. Por
ejemplo, el lenguaje Ada fue diseñado para imponerlo como estándar en todos
los desarrollos de sistemas con computador empotrado o englobado (embed-
ded computer systems) para el Departamento de Defensa norteamericano. Se
trataba con ello de disminuir los costes de desarrollo y mantenimiento que se
producen cuando se utilizan cientos de lenguajes diferentes. En otras ocasiones
el cliente no es tan drástico y simplemente establece una relación reducida de
lenguajes que se pueden usar en sus desarrollos.

■ TIPO DE APLICACIÓN
Aunque con las prestaciones de cualquier lenguaje de última generación se pue-
den realizar aplicaciones para los más diversos campos, no parece muy realista
pensar en un lenguaje universal que sirva para todo. Por el contrario cada día
aparecen nuevos lenguaje-S orientados a un campo de aplicación concreta. Sólo
en aplicaciones de tiempo real muy crítico (robótica, aeroespaciales, etc.) opa-
ra hardware muy especial, sin compiladores de lenguajes de alto nivel, estaría
 CRITERIOS DE SELECCIÓN DEL LENGUA.JE 271

justificado el empleo de lenguajes ensambladores. En todo caso, la parte realiza-

da en ensamblador debería quedar reducida exclusivamente a lo imprescindible.

Para aplicaciones de gestión lo habitual es utilizar COBOL, aunque cada día

se utilizan más los lenguajes de cuarta generación. En las aplicaciones del área
técnica-científica, tradicionalmente ha sido FORTRAN el lenguaje más emplea-
do, aunque tanto P ascal como C también se utilizan con bastante frecuencia.
Para aplicaciones de sistemas y tiempo real se utilizan bastante C, lVIodula-2 y
Ada. Los lenguajes LISP y PROLOG todavía están entre los más usados para
las aplicaciones de inteligencia artificial. Finalmente, para aplicaciones con un
diseño orientado a objetos se pueden utilizar C+ + , Java, Eiffel o cualquier otro
diseñado para este fin.

■ DISPOKIBILIDAD Y ENTORNO
Desde luego no existen compiladores de todos los lenguajes para todos los
computadores. Por tanto, como paso previo, es necesario comprobar que com-
piladores existen para el computador elegido. Normalmente, el número de ellos
será bastante reducido. Puede resultar interesante realizar un estudio compa-
rativo de los compiladores disponibles en cuento a la memoria y tiempo de
ejecución del código que generan para un programa sencillo de prueba. En este
sentido se debe tener en cuenta si el código generado se ejecuta directamente o
se interpreta posteriormente.

-Cn factor muy importante a tener en cuente en la selección, es el entorno que

acompaña a cada compilador. El desarrollo será más sencillo cuanto más poten-
tes sean las herramientas disponibles: editor , montador de enlaces, depurador,
control de versiones, manejo de librerías de programas realizados en ensam-
blador o en otros lenguajes, etc. Por otro lado, también se deben considerar
las facilidades de manejo de estas herramientas y lo amigable que resulta su
utilización.

■ EXPERIE~CIA PREVIA
Aunque se supone que el equipo de programadores posee una buena metodología
de trabajo y se adaptaría rápidamente a un nuevo lenguaje y entorno, siempre
que sea posible es más rentable aprovechar la experiencia previa. Cuando las
condiciones de trabajo no se modifican el rendimiento aumenta y se disminuyen
L las posibilidades de error. En la mayoría de las empresas de software están
L establecidos tanto el lenguaje de programación que utilizan preferentemente,
como su entorno de desarrollo y, en todo caso , a lo largo del tiempo se van
actualizando con nuevas versiones. Hay que tener en cuenta que la formación
L de todo el personal es una inversión muy importante.
272 L.-l CODIFIC.4CIÓN DEL SOFTWARE

• REUSABILIDAD
Este aspecto es importante tanto por la posibilidad de utilizar software ya rea-
lizado como por el hecho de dejar disponibles para otros proyectos partes del
software desarrollado.
Así, por un lado, es muy interesante conocer exhaustivamente las librerías dis-
ponibles, y por otro, resulta muy conveniente disponer de herramientas dentro
del entorno del lenguaje para la organización de dichas librerías en las que se
facilite la búsqueda y el almacenamiento de los módulos reutilizables. Este tipo
de herramientas todavía no están muy e:x.1:endidas, pero es previsible que se
utilicen mucho en un futuro muy próximo.

■ TRAKSPORTABILIDAD
Los desarrollos se realizan para un computador concreto, pero a lo largo del
tiempo este se queda obsoleto. Por esta y otras razones, es bastante habitual
que se traten de trasladar las aplicaciones de unos computadores a otros. Para
facilitar esta labor es muy interesante que el lenguaje utilizado sea transporta-
ble.

La transportabilidad está ligada a que exista un estándar del lenguaje que

se pueda adoptar en todos los compiladores. Pese a todo siempre existirán
pequeños detalles que no resultarán completamente compatibles y que deberán
ser modificados para adaptarlos al nuevo computador.

■ USO DE VARIOS LENGUAJES

Aunque no es aconsejable mezclar varios lenguajes en un mismo proyecto, hay
ocasiones en las que las distintas partes del mismo resultan mucho más sencillas
de codificar si se utilizan diferentes lenguajes. En todo caso, para tomar esta
decisión se debe hacer un estudio de la compatibilidad entre los compiladores
y en definitiva de los pros y los contras de utilizar uno a varios lenguajes.

7.5. Aspectos metodológicos

En esta sección se repasan ciertos aspectos metodológicos que pueden mejorar la
codificación bajo determinados puntos de vista: claridad, manejo de errores, eficiencia
y transportabilidad. Un estudio más profundo de todos los aspectos de una buena
metodología de programación queda fuera del alcance de este libro.

7.5.1. N ormas y estilo de codificación

Cuando se inicia la fase de codificación de un proyecto es fundamental fijar las
normas que deberán respetar todos los progran1adores para que el resultado del tra-
ASPECTOS A1ETODOLÓGICOS 273

bajo de todo el equipo sea completamente homogéneo. Es habitual que las empresas
dedicadas al desarrollo de software tengan ya establecidas un conjunto de normas
que con carácter general aplican a todos sus proyectos.

Casi todos los lenguajes permiten un formato libre en la escritura de sus senten-
cias e ignoran los espacios en blanco redundantes y los comentarios. Así, al mismo
texto de un programa se le pueden dar distintos formatos que pueden resultar muy
significativos desde el punto de vista del lector humano, al tiempo que son irrelevan-
tes desde el punto de vista del compilador.

Para la puesta a punto y sobre todo para el mantenimiento de un programa es

esencial que éste resulte fácil de entender por todos, sus actuales y futuros lectores.
incluyendo a su propio autor. Por tanto, se deben fijar normas concretando un estilo
de codificación.

No se trata de proponer el mejor estilo posible puesto que este sería muy difícil
de establecer y provocaría muchas discusiones estériles. Lo más importante es fijar
un estilo concreto y que todo el equipo lo adopte y lo respete. Para fijar un estilo de
codificación se deberán concretar al menos los siguientes puntos:
■ Formato y contenido de las cabeceras de cada módulo
• Identificación del módulo
• Descripción del módulo
• Autor y fecha
• Revisiones y fechas
•.. .
■ Formato y contenido para cada tipo de comentario
• Sección
• Orden
• Al margen
• ....
■ Utilización de encolumnado
• Tabulador = N' espacio
• Máximo indentado
• Formato selección
• Formato iteración
•
274 LA. CODIFICACIÓN DEL SOFTlVARE

■ Elección de nombres
• Convenio para el uso de mayúsculas y minúsculas
• Kombres de ficheros
• Identificadores de elementos del programa
•
En el libro de Fundamentos de Programación [Cerrada00) se concretan estos pun-
tos para configurar el estilo de todos los programas escritos a lo largo del texto.
Además del estilo, en las normas se deben incluir todas aquellas restricciones o reco-
mendaciones que puedan contribuir a mejorar la claridad del código y a simplificar
su mantenimiento posterior. Por ejemplo, se pueden fijar las siguientes restricciones
de carácter general:
■ El tamaño máximo de las subrutinas no debe superar P páginas.
■ Las subrutinas tendrán un máximo de N argumentos.
■ Se deben incluir en un fichero todas las ristras de caracteres que utilice el
programa. Esto facilitará la personalización y los cambios.
■ Evitar el anidamiento excesivo de sentencias IF.

Con los mismos fines , también se puede limitar el empleo de algunas sentencias
del lenguaje. Por ejemplo, si se utiliza el lenguaje C para la codificación se pueden
dar normas como las siguientes:

■ Evitar el empleo de goto.

■ Ko usar los operadores de autoasignación (+=, -= , *- \=, = ,<<=, >>=.
& = ), ya que pueden resultar confusos.

7.5.2. Manejo de errores

Durante la ejecución de un programa se pueden producir fallos que tienen como
origen las más diversas causas:
■ Introducción de datos incorrectos o inesperados.
■ Anomalías en el hardware (p.ej.: ruido en las comunicaciones).

• Defectos en el software (p.~j.: erratas no depuradas del programa).

Algunas de estas causas no pueden ser eliminadas completamente, por lo que si se
quiere evitar su efecto indeseable habrá que introducir elementos correctores en el
código del programa.
 ASPECTOS !vIETODOLÓGICOS 275

En lo que sigue consideraremos los errores en el funcionamiento de un programa

desde el punto de vista del software, fundamentalmente, pero antes de analizar la
manera de organiza el código para atenuar o evitar errores, comenzaremos por definir
de manera precisa los conceptos básicos a tener en cuenta:
■ Defecto:
Errata o "gazapo" de software. Puede permanecer oculto durante un tiempo
indeterminado, si los elementos defectuosos no intervienen en la ejecución del
programa. Esto depende de los datos particulares con los que se opere en cada
momento. En sistemas en tiempo real, también depende del momento preciso
en que se reciban estímulos externos.
■ Fallo:
Es el hecho de que un elemento del programa no funcione correctamente, pro-
duciendo un resultado (parcial) erróneo. Si un elemento software defectuoso
interviene en una ejecución particular del programa, dará lugar normalmente a
un fallo.
el • Error:
Se define como un estado inadmisible de un programa al que se llega como
consecuencia de un fallo. Típicamente consiste en la salida o almacenamiento
de resultados incorrectos.
as
~n
Esta terminología no se emplea siempre con la precisión requerida. Por ejemplo, en
la bibliografía sobre pruebas o ensayos de programas se suele usar el término "error·'
como sinónimo de "defecto". Al codificar un programa se pueden adoptar distintas
actitudes respecto al tratamiento de los errores (o más precisamente, de los fallos).
Analizaremos brevemente cada una de ellas.
=
• KO CONSIDERAR LOS ERRORES
Con esta actitud, la más cómoda desde el punto de vista de la codificación,
se declina toda responsabilidad si se produce algún error. Para ello. se exigirá
como requisito que todos los datos que se introduzcan sean correctos y que
10
el programa no tenga ningún defecto. Cuando no se cumpla alguno de estos
requisitos, no será posible garantizar el resultado correcto del programa. Evi-
dentemente, esta postura no es realista y sólo puede ser válida para sistemas
con muy baja probabilidad de fallo o muy poca trascendencia de los mismos.
• PREVENCIÓ~ DE ERRORES
Consiste en detectar los fallos antes de que provoquen un error. La técnica
se general de prevención se conoce como programación a la defensiva (en inglés
el "defensive programming" ) y consiste en que cada programa o subprograma esté
codificado de manera que desconfíe sistemáticamente de los datos o argumentos
que se le introducen, y devuelva siempre
276 LA CODIFICACIÓN DEL SOFTl~JlRE

l. El resultado correcto, si los datos son válidos, o bien

2. Una indicación precisa. del fallo, si los datos no son válidos.
En el caso (b) además, el código del programa debe evitar operar con los datos
incorrectos de forma que el estado después de la operación sea erróneo. Si han
sido considerados todos los posibles fallos, no se puede producir ningún error.

Conviene recordar que un error es un estado incorrecto (o resultado incorrecto)

del programa. La prevención de errores evita estos resultados incorrectos, a
base de no producir resultados en caso de fallo. De todas maneras una ventaja
principal de la programación a la defensiva es evitar la propagación de errores.
facilitando así el diagnóstico de los defectos.
• RECUPERACIÓN DE ERRORES
Cuando no se pueden detectar todos los posibles fallos, es inevitable que en el
programa se produzcan errores. En este caso se puede hacer un tratamiento dPl
error con el objetivo de restaurar el programa en un estado correcto y evitar
que el error se propague. Este tratamiento exige dos actividades diferentes y
complementarias:
l. DETECCIÓ:'.'1 del error.
2. RECl:PERACIÓ:'.'1 del error.
Para la detección de un error hay que concretar qué situaciones se considerarán
erróneas y realizar las comprobaciones adecuadas en ciertos puntos estratégicos
del programa. Por su parte en la recuperación se tienen que adoptar decisiones
sobre cómo corregir el estado del prograJna para llevarlo a una situaeión con-
sistente. Estas decisiones pueden afectar a otras partes del programa diferentes
y alejadas de aquella en la que se produce la detección del error.

Para la recuperación de errores, existen dos esquemas generales:

• Recuperación hacia adelante
• Recuperación hacia atrás
La recuperación hacia adelante trata de identificar la naturaleza o el tipc.,
de error (p.ej.: fuera de rango, sobrepresión, etc.), para posteriormente tomar
las acciones adecuadas que corrijan el estado del programa y le permitan con-
tinuar correctamente su ejecución. Este esquema se puede programar medianl r
el mecanismo de manejo de excepciones.

La recuperación hacia atrás lrata de corregir el estado del programa res-

Laurándolo a un estado correcto anterior a la aparición del Prror, todo ello con
E ASPECTOS lVIETODOLÓGICOS 277

independencia de la naturaleza del error. Con este esquema se necesita guardar

periódicamente el último estado correcto del programa. En la nueva operación
se parte de ese último estado correcto para obtener otro nuevo estado. Si ese
)S nuevo estado es también correcto, la operación se da por terminada satisfacto-
,n riamente. En caso de error, se restaura el estado anterior y se trata de realizar
la misma operación por un camino o algoritmo diferente.

)) Este esquema se utiliza habitualmente en los sistemas basados en transacciones.

a "Cna transacción es una operación que puede terminar con éxito, modificando el
a estado del sistema ("commit", o con fallo, en cuyo caso la transacción se abor-
s. ta ("abort') y se restaura el estado inmediatamente anterior de manera que la
operación no produce ningún efecto.

Los esquemas de transacciones se usan para mantener la consistencia en las

bases de datos (p .ej.: en las transacciones bancarias). En estos casos. lo fun-
damental es asegurar que el estado del programa sea siempre correcto aun-
Lr
que se queden pendientes de realizar ciertas operaciones. En general, todos los
y
programas que realizan una previsión o recuperación de errores se denominan
genéricamente tolerantes a fallos.

7.5.3. Aspectos de eficiencia

[l Actuallnente, la eficiencia en la codificación no es tan importante como lo fue
,s en los primeros computadores. La potencia de cálculo y la cantidad de memoria
s disponible en los computadores actuales permite asegurar que prácticamente nunca
será necesario sacrificar la claridad en la codificación por una mayor eficiencia. La
s eficiencia se puede analizar desde varios puntos de vista:
• Eficiencia en memoria.
• Eficiencia en tiempo.
El bajo costo de la memoria hace que cuando se precisa cierto ahorro resulte sufi-
ciente con el que se puede obtener de forma automática empleando un compilador
que disponga de posibilidades de compresión de memoria. Por otro lado, cuando el
)
volumen de información a manejar sea excesivamente grande para la memoria dispo-
r nible, será durante la fase de diseño detallado cuando se deban estudiar las distintas
alternativas y optar por el algoritmo que optimice más la utilización de la memoria.

La eficiencia en tiempo adquiere su mayor importancia en la codificación de sis-

temas para tiempo real con plazos muy críticos. En ocasiones una mayor eficiencia
en tiempo se logra disminuyendo la eficiencia en memoria. Por ejemplo, cuando un
l cálculo es muy complQjo y no hay suficiente tiempo para llevarlo a cabo se puede
278 LA. CODIFICACIÓN DEL SOFTlt:4.RE

adoptar como solución tabular dicho cálculo y simplemente consultarlo cada vez que
se necesite.

La primera vía para conseguir un ahorro de tiempo importante es realizar en

la fase de diseño detallado un estudio exhaustivo de las posibles alternativas del
problema y adoptar el algoritmo más rápido. Aunque existen compiladores capaces
de optimizar el código que generan para aumentar su eficiencia en tiempo, las mejoras
que se pueden obtener son difíciles de prever. Existen formas bastante simples de
obtener un ahorro de tiempo significativo utilizando técnicas de codificación tales
como las siguientes:

■ Tabular los cálculos complejos según se mencionó anteriormente.

■ Expansión en línea: Si se emplean macros en lugar de subrutinas se ahorra el
tiempo necesario para la transferencia de control y el paso de argumentos.
■ Desplegado de bucles: En la evaluación de la condición de un bucle se emplea un
tiempo que se puede ahorrar repitiendo el código de forma sucesiva. Por ejemplo,
si se repite 10 veces seguidas el código interno del bucle, las evaluaciones se
reducen a la décima parte.
■ Simplificar las expresiones aritméticas y lógicas.
■ Sacar fuera de los bucles todo lo que no sea necesario repetir.
■ Utilizar estructuras de datos de acceso rápido (p.ej.: vectores en lugar de listas
con encadenamiento).
• Evitar las operaciones en coma flotante y realizarlas preferiblemente en coma
fija.
■ Evitar las conversiones innecesarias de tipos de datos.

7.5.4. Transportabilidad de software

Realizar una aplicación transportable implica un esfuerzo adicional, que en mu-
chos casos se rentabiliza rápidamente. La transportabilidad permite usar el mismo
software en distintos computadores actuales y futuros. Por tanto. la transportabi-
lidad no sólo es rentable a corto plazo para aprovechar el mismo software en dis-
tintos computadores, sino también a medio y largo plazo para facilitar el manteni-
miento/ adaptación de la aplicación a las nuevas arquitecturas y prestaciones de los
computadores.
RE ASPECTOS 1'1ETODOLÓGICOS 279

iue Como factores esenciales de la transportabilidad se pueden destacar los siguientes:

■ Utilización de estándares.
en ■ Aislar las peculiaridades.
lel 'Cn producto software desarrollado exclusivamente sobre elementos estándar (len-
~es guaje, base de datos, librerías gráficas, etc.) es teóricamente transportable sin ningún
·as cambio, al menos entre plataformas que cuenten con el soporte apropiado de dichos
de estándares. La falta de estándares es uno de los problemas que dificulta la transpor-
les tabilidad. En este caso se deben utilizar lenguajes, compiladores, bases de datos y
herramientas en general que tengan una amplia difusión y que se puedan considerar
estándares "de facto". De todos ellos, se procurarán evitar aquellos elementos no con-
solidados por completo y que puedan estar sujetos a futuros cambios o revisiones.
el
La mejor manera de aislar las peculiaridades es destinar un módulo específico para
cada una de ellas. El transporte se resolverá recodificando y adaptando solamente
m
estos módulos específicos al nuevo computador. Las peculiaridades fundamentales de
.o.
los computadores suelen estar vinculadas a los elementos siguientes:
se
• ARQUITECTURA DEL co:rvIPUTADOR
La arquitectura del computador determina la longitud de palabra (8, 16, 32
ó 64 bits) y de esto se deriva la representación interna de los valores enteros
y reales. Cuando no se desbordan los rangos o precisiones del computador no
resulta muy compleja la transportabilidad debido a que será el compilador el
is
encargado de tener en cuenta todos los detalles. Aunque afortunadamente este
problema es cada día menos frecuente la cosa se complica cuando se llega a
La desbordar capacidad de la longitud de palabra del computador. Para resolver
esto es necesario definir un nuevo tipo abstracto de dato con el rango o precisión
ampliados y crear para él todas las operaciones necesarias mediante funciones.

En Ada el nombre de estas funciones pueden ser directamente operadores (-+- ,

-,*, /, ... ). Inevitablemente, la implementación de estos nuevos tipos abstractos
L-
será bastante ineficiente respecto a los tipos propios del computador realizados
por hardware.
O
l-
La tabla de códigos de caracteres utiliz;ados es otra causa de problemas. Ac-
I- tualmente, prácticamente todos los computadores utilizan la tabla ASCII. Sin
S embargo para facilitar la transportabilidad lo mejor es no aprovechar nunca en
la codificación el orden de los caracteres en una tabla concreta.
■ SISTE:\1A OPERATIVO
Los lenguajes incorporan de un modo u otro el acceso a servicios del sistema
operativo para realizar tareas como las siguientes:
280 L-l CODIFICACIÓN DEL SOFT\VARE

• Entrada/salida (teclado, pantalla, ratón. etc.).

• lVIanejo de ficheros (abrir. leer. escribir. t'tc-.).
• l\!Ianejo de librerías (numéricas, utilidades, etc.).

En muchas aplicaciones es inevitable hacer uso de algunas o todas estas facili-

dades que son específicas de cada sistema operativo. Los lenguajes de alto nivel
disponen de procedimientos o funciones predefinidos para la realización de las
operaciones más elementales dentro de estas tareas y siempre que sea posible
deben ser las únicas que se utilicen.

En algunos compiladores concretos el nivel de sofisticación de estas operaciones

puede ser mayor y esto simplificará bastante la codificación. Sin embargo, su
transportabilidad será bastante incierta dado que son operaciones que no se
encontrarán en todos los compiladores con carácter general.

Lo habitual es que se necesiten operaciones más complejas y particularizadas

que las predefinidas en los lenguajes. En este caso, se deben concretar y espe-
cificar claramente cada una de ellas. Estas nuevas operaciones se agruparán en
módulos de entrada/salida, para manejo de ficheros, librerías matemáticas, etc,
propios de cada aplicación. Para cada módulo y operación se definirá una inter-
faz única y precisa en toda la aplicación. El resto de la aplicación utilizará estos
módulos de forma independiente del sistema operativo. En la implementación
de estos módulos se podrán utilizar las operaciones disponibles en el lenguaje
y el sistema operativo. Para transportar la aplicación a otro sistema operativo
sólo será necesario realizar una nueva implementación de estos módulos a partir
del nuevo sistema operativo y sus operaciones más o menos sofisticadas.

7.6. Conclusiones
La programación o construcción del softwarf> es la etapa en la que, después df'
análisis, especificación y diseño, elaboramos el producto. La elección del lenguaje de
programación más adecuado no es sencilla, depende de múltiples factores como el
tipo de aplicación, el bagaje de la empresa u organización que lo construye, la plata-
forma hardware elegida, etc. En este capítulo se han dado algunos consejos para la
correcta elección del lenguaje, y se ha dado un breve repaso a los distintos lenguajes
de programación. Existen cientos de lenguajes disponiblE>s en el mercado. La calidad
final del producto una vez terminado depende mucho de haber seguido una correcta
metodología durante la programación. En las organizaciones más desarrolladas exis-
ten estrictas normas sobre el uso de lenguajes y compiladores. Aquí se han revisado
algunos de los aspectos metodológicos más importantes que sirven de base para su
elaboración.
 E.TERCICIOS PROPUESTOS 281

7. 7. Ejercicios propuestos
1. Elahórese un conjunto de reglas para la cn•ación de los nombre de los identifica-
dores de un programa. Elíjase el lenguaje de programación que mejor conozca.
¿Cree que obligar a cumplir dichas reglas es una pérdida de tiempo? Razone su
respuesta.
2. Escríbase una rutina en C que calcule términos de la sucesión de números ente-
ros conocida como la serie de Fibonaci sin utilizar la sentencia GOTO. \'uelYa
a escribirla utilizando la sentencia GOTO. ¿Qué ventajas o inconvenientes ve
entre ambos métodos?

1
3. Piénsese en los dos lenguajes de programación que mejor conozca. Elabórese
una lista de Yentajas e inconvenientes que \·e en cada uno de ellos para la
programación de una aplicación que gestione una gasolinera.
-1. Búsquese información sobre la popularidad de los diferentes lenguajes <le pro-
3 gramación e intente elaborar una lista de los 20 más utilizados.
5. Consúltese la guía S\\.EBOK y descubra., según ella, cuáles son los principios
fundamentales de la construcción del software.

1
?

-
a
s
i
a
Capítulo 8

Pruebas de Software

8.1. Introducción
A lo largo del proceso de elaboración del soft"vare se introducen de manera inad-
vertida múltiples errores de todo tipo e incorrecciones respecto a las especificaciones
del proyecto. Todo ello debe ser detectado y corregido andes de entregar al cliente el
programa acabado.

Como sucede con cualquier otro producto (mecánico, electrónico, etc), para ga-
rantizar su calidad es necesario someter al programa a diversas pruebas dcstmadas a
detectar errores o verificar su funrionamiento correcto. Según la utilización final df'l
programa, las pruebas pueden ser más o menos exhaw,tivas.

Para un software crítico (aeronáutica, nuclear. automoción, etc), donde la grave-

dad de las consecuencias de un fallo es alUsima, el costo de las pruebas puede ser la
partida más importante del costo de todo el desarrollo.

P ara evitar el caos de una p rueba única. se deben hacer pruebas a cada unidad o
módulo según se avanza en la codificación dcl proyecto. Esto facilitará enormemente
las posteriore~ pruebas de integración entrf' módulos y las prueba..., del sistema total
que deben realizarse en cualquier caso.

Las pruebas permiten valorar la calidad de un programa. es decir. descubrir sus

errores, sin embargo no deben w•rsP como una red df' seguridad. La calidad se in-
corpora a lo largo de todo el proc-eso de ingeniería del sofl ware y las pruebas deben
confirmarnos que se ha logrado un buen programa. a través de la adecuada aplic-ación
de métodos y herramientas.

283
284 PRUEBAS DESOFT ~V.4RE

Con frecuencia, la fase de pruebas requiere más esfuerzo que cualquier otra de la
ingeniería del software. Una correcta planificación puede ahorrarnos mucho tiempo
dentro del proyecto y evitar que un menor porcentaje de errores pase desapercibido.

8.2. Objetivos
Se analiza a lo largo de este capítulo los distintos tipos de pruebas que se deben
o pueden realizar a un software para garantizar de forma razonable su correcto fun-
cionamiento. Se reüsan además las técnicas más utiliza.das en función del tipo de
lenguaje de progTamación.

8.3. Tipos de pruebas

Las pruebas de software tienen un doble objetivo: la verificación y la validación.
La verificación persigue comprobar que se ha construido el producto correctamente.
La validación comprueba que el producto se ha construido de acuerdo a los requeri-
mientos del cliente.

Los procesos de verificación y validación llevan a realizar pruebas a diferentes ni-

veles, con10 se muestra en la figura 8.1, en los que se revisa la calidad de cada etapa
del proceso de elaboración del software:

• Pruebas de unidades
• Pruebas de integración
• Pruebas de validación
• Prueba.e, de sistema

ESl'EOFICAOÓN

PRUEIIASOE INl'EGRAO ÓN DlscliiO

PRUEIIA O[ UNIDADES CootFICAOÓN

F igura 8.1: Tipos de pruebas

PRUEBAS DE UNIDADES 285

La.s pruebas de unidad se centran en comprobar la correcta codificación de las

partes más pequeñas con entidad propia en las que poden10s descomponer un pro-
grama: unidades o módulos de software. Est~ pruebas comprueban la lógica del
procesamiento interno del módulo y su estructura de datos.

Podríamos pensar que si todos los módulos funcionan correctamente, lo cual ya

hem.os comprobado una vez reaJizadas las pruebas de todas las unidades, el software
que resulta de juntar todos esos módulos deberá igualmente funcionar correctamen-
te. ~ada más lejos de la realidad, la variedad de problemas que pueden surgir como
resultado de juntar los módulos es enorme. Las pruebas de integración revisan que la
estructura de programa que resulta de la unión de los diferentes módulos es consiste
con el diseño y está libre de errores.

"'Cna vez ensan1blados todos los módulos correctamente y eliminados los errores
de interacción entre ellos, comienza la fase de verificación de que software realiza
aquello para lo que ha sido especificado. Estamos en las pruebas de validación. A.ho-
ra lo relevante es la interacción del usuario con el programa, el cual debe obtener los
resultados deseados ante las diferentes peticiones que pueda requerir.

El software una vez terminado y funcionando correctamente, es decir según se ha

especificado y diseñado, debe montarse sobre una plataforma hardware y comunicarse
tanto con los usuarios como con otros sistemas o equipos. incluso formando parte
de un sistema más grande. Las pruebas de sistema revisan por completo el sistema
basado en computadora, yendo Wl paso rnás allá del proceso de software.

8.4. Pruebas de unidades

Aunque puede resultar paradójico, el principal objetivo de las pruebas debe ser
conseguir que el programa funcione incorrectamente y que se descubran sus defectos.
Esto exige elaborar minuciosamente un juego de casos de prueba destinados a sometE>r
al progran1a al máximo número posible de situaciones diferentes. Para elaborar los
casos de prueba se debe tener en cuenta lo siguiE>nte:
■ una buena prueba es la que encuentra errores y no los encubre.
• Para detectar un error es necesario conocer cuál es el resultado correcto.
■ Es bueno que no participen en la prueba el codificador y el diseñador.
■ Siempre hay errores, y si no aparecen se deben diseñar pruebas mejores.

• Al con-egir un error se pueden introducir otros nuE>vos.

• Es imposible demostrar la ausencia de defectos mediante pruebas.
 286 PRUEBAS DE SOFT\VARE

Probar completamente cada módulo es inabordable y además no resulta rentable

ni práctico. Como se muestra en la figura 8.2, con las pruebas sólo se explora una
parte de todas las posibilidades del programa. Se trata de alcanzar un compromiso
para que, con el menor esfuerzo posible, se puedan detectar el máximo nún1ero de
defectos y, sobre todo, aquellos que puedan tener las más gTaves consecuencias.

ESPACJO ESPACIO

DE DE

PRUEBA EJECUCIÓN

Figura 8.2: Dominio de pruebas

Para garantizar unos resultados fiables, además del juego de casos de prueba, es
esencial que todo el proceso de prueba se realice de la manera más automática posi-
ble. Esto exige crear un entorno de prueba que asegure unas condiciones predefinidas
y estables para las sucesivas pasadas, que necesariamente se deben efectuar después
de corregir los errores detectados en cada pasada anterior.

Las pruebas de unidades se realizan en un entorno de ejecución controlado, que

puede ser diferente del entorno de ejecución del programa final en explotación. El
entorno deberá proporcionar, al menos, un informe con los resultados de las pruebas
y un registro de todos los errores detectados con su discrepancia respecto al valor
esperado. A veces, para establecer el entorno de pruebas, serán suficientes las utilida-
des del sistema operativo, preparando en un fichero los casos de prueba y recogiendo
en otro fichero los resultados obtenidos, que se compararán posteriormente con los
esperados. Si se necesita un entorno más sofisticado que registre tiempos u otros
parámetros de prueba, será necesario desarrollar el correspondiente programa. La8
técnicas de prueba de unidades responden a dos estrategias fundamentales:
• Pruebas de caja negra.
• Pruebas de caja transparente.

8.4.1. Pruebas de caja negra

Según muestra la figura 8.3, la estrategia de caja negra (black box) ignora por
completo la estructura interna del programa y se basa exclusivamente en la compro-
 RE PRTJEBAS DE USIDADES 287

::>le bación de la especificación entrada-salida del software. Se trata de verificar que todos
Ilé' los requisitos impuestos al programa. como a cualquier otro producto 1 se cumplen.
ISO Esta es la única estrategia que puede adoptar el cliente o cualquier persona ajena al
de desarrollo del programa.

CASOS
DE e=) RESULTADOS
PRUEBA

Figura 8.3: Pruebas de caja negra

La elaboración de unos buenos casos de prueba que permitan conocer el correc-

~s to funcionamiento de la caja negra no resulta trivial, y para ello se deben emplear
1-
todos los métodos que estén a nuestro alcance. Esta tarea requiere cierta dosis de
tS ingenio y hay personas mejor capacitadas que otras para llevarlo a cabo. Como si
~s se tratara de un juego, el objetivo es descubrir los errores o incorrecciones del mó-
dulo ·'sospechoso·', y para ello hay que diseñar un ·'interrogatorio'' amplio y coherente.

e Existen ciertos métodos, basados fundamentalmente en la experiencia, que ayudan

J bastante en la elaboración de casos de prueba. Todos ellos se pueden, y se deben,
s utilizar de forma conjunta y complementaria. Algunos de los usados más ampliamente
•r son los siguientes:
-
■ Partición en clases de equivalencia
o
s ■ Análisis del valor límite
s
■ Comparación de versiones
s
■ Empleo de la intuición

PA RT ICIÓN EN CLASES DE EQUIVALE CIA

Según se muestra en la figura 8.-1. se trata de dh·idir el espacio de ejecución
del programa en varios subcspacios. Cada subcspacio o clase de equivalencia
agrupa a todos aquellos datos de entrada al módulo que resultan equivalentes
desde el punto de vista de la prueba de> caja 11rgra. La equivalencia podría
corresponder intuitivamente a que el algoritmo de cálculo. tal como se describe
externamente, siga los mismo~ pasos en ,u ejecución. Por E'jemplo. si estamos
288 PRUEBAS DE SOFTl-l-':4.RE

probando una función que realiza la raíz cuadrada, será suficiente con probar
cualquier número positivo, el cero y cualquier número negativo, o tal vez sea más
adecuado probar con un cuadrado perfecto positivo, un valor positivo sin raíz
exacta, el cero, un cuadrado perfecto negativo y un valor negativo arbitrario.
De una forma tenemos tres clases de equivalencia y de otra cinco.

ESPACIO

DE

Figura 8.4: Clases de equivalencia.

Los pasos que se deben seguir con este método son los siguientes:

l. Determinar las clases de equivalencia apropiadas.

2. Establece pruebas para cada clase de equivalencia.

Se deben proponer casos o datos de pruebas válidos e inválidos para cada una
de las clases definidas en el paso anterior. Con este método, si las clases se eligen
adecuadamente, se reduce bastante el número de casos que se necesitan para
descubrir e] defecto. Según cómo se caractericen las clases de equivalencia, se
pueden emplear las siguientes directrices:
A Rango de valores.
Ejemplo: O < - edad < 120años
Casos válidos: 1 dentro del rango 33 años
Casos inválidos: 1 mayor y 1 menor -5 y 132 años

B Valor específico.
Ejen1plo: Clave - OGCLTA
Casos válidos: 1 igual OGCLTA
Casos inYálidos: 1 distinto Otra578

C Conjunto de valores.
Ejemplo: Operaciones = compra, venta, cambio
 PRUEB,4S DE UNIDADES 289
RE

>ar
Casos válidos: 1 por elemento compra, venta, cambio
tás
Casos inválidos: 1 fuera del conjunto regalo
9.ÍZ
10.

Hay que tener en cuenta que un caso de prueba válido para una clase puede
ser también un caso de prueba inválido para otra y, asimismo, puede ocurrir
que un caso de prueba bien elegido sea válido para varias clases. Así, para la
elaboración del juego de casos de pruebas, se pueden refinar los pasos indicados
anteriormente:

l. Definir clases de equivalencia.

2. Definir una prueba que cubra tantos casos válidos como sea posible de
cualquier clase.

3. rvtarcar las clases cubiertas y repetir el paso anterior hasta cubrir todos los
casos válidos de todas las clases.

4. Definir una prueba específica para cada caso inválido.

ta ANÁLISIS DE VALORES LÍMITE

m Muchos programas se construyen codificando primero un tratamiento general, y
:a retocando luego el código para cubrir casos especiales. P or esta y otras razones
es bastante normal que los errores tengan cierta tendencia a aparecer precisa-
mente al operar en las fronteras o valores límite de los datos normales.

El método de análisis de los valores límite (en inglés boundary analysis), como
se muestra en la figura 8.5, hace un especial hincapié en las zonas del espacio
de ejecución que están próximas al borde. Este método es complementario del
anterior y, también en éste, se deben proponer casos válidos y casos inválidos.
Por ejemplo, para el rango de edades indicado en el apartado anterior, los casos
válidos de prueba serían:

Límite inferior: -1 O 1
Límite superior: 119 120 121
290 PRUEBAS DE SOFTWARE

ESPAOO
DE

ESPACIO

DE

EJECUCIÓN

\ ESPAOO
DE
PRUEBA

Figura 8.5: Pruebas de valores límite

Los errores en los límites pueden tener consecuencias más graves de lo normal,
debido a que se puede provocar la necesidad de unos recursos extra que no
estaban previstos. Por ejemplo, si un sistema de control de una central nuclear
debe poder atender 20 alarmas simultáneamente, en las pruebas se podrán
provocar 21, 22 e incluso 30 alarmas, comprobando que se detecta esta situación
y se avisa al operador sin abortar el programa y producir la parada del sistema
por violación de memoria. En este caso, las directrices a seguir en la elaboración
de casos de prueba serían las siguientes:
l. Entradas: probar con los mismos valores límite y justo fuera de límites.
Por ejemplo, si la precisión en los cálculos = 5 cifras, probar 5 y 6.
2. Salidas: probar con los mismos valores límite y justo fuera de límites. Por
ejemplo: para listados con Nº líneas/página= 70, probar 70 y 71.
3. l\.1emoria: probar con tamaños nulos, límite y superior al límite de todas
las estructuras de información. Por ejemplo, para pilas, colas tablas, etc.,
probar los casos vacío, lleno, y sobrelleno (un elemento más de lleno).
4. Recursos: probar con ningún recurso, límite de recursos y superior al límite.
Por ejemplo, si máximo ~o de terminales= 30, probar O, 30 y 31.
5. Otros: pensar en otras situaciones límite y establecer la pruebas.
Ente método también se puede utilizar con la estrategia de caja transparente
en la medida que se conozcan las estructuras internas del programa.
COMPAR ACIÓN D E V ER SIONES
Cuando una unidad o módulo es especialmente crítico se puede hacer un desa-
rrollo multi-versión (en inglés ~-version), encargando ia codificación de dife-
rentes versiones a distintos programadores. Todos ellos utilizarán las mismas
especificaciones de partida y deberían obtener módulos completamente inter-
cambiables. Sin embargo, esto no suele ocurrir debido a variaciones en los algo-
ritmos empleados, diferencias de matiz en la interpretación de la especificación,
 PRUEBAS DE UNIDADES 291

diferentes precisiones, etc. Por otro lado, se elaborará un juego de casos de prue-
ba mediante los métodos habituales. Hay que tener en cuenta que no siempre
se conocen de forma completamente exacta los resultados esperados y que, en
algunos casos, como sucede en los sistemas de tiempo real, resulta casi imposi-
ble conocer a priori cuáles serán esos resultados.

A continuación se someterán todas las versiones al mismo juego de casos de

prueba de una forma completamente automática. Los resultados de las distin-
tas versiones se comparan entre ellos y con los esperados. Cualquier discrepancia
entre las distintas versiones se debe analizar hasta discernir si una versión es
errónea y sus causas. Cuando todas las versiones produzcan los mismos re-
sultados y éstos coincidan con los deseados, se puede suponer que todas son
equivalentes y correctas, y se puede utilizar cualquiera de ellas.

La redundancia que se introduce con la codificación de v·arias versiones aument a

las garantías de que el módulo funcione correctamente y que cumpla las espe-
l
cificaciones. Sin embargo, no es un criterio infalible puesto que un error en la
t
especificación se trasladará a todas las versiones.
l
EMPLEO DE INTUICIÓN
Como ya ha sido comentado, la elaboración de pruebas requiere ingenio. En
este sentido, es muy importante dedicar cierto tiempo a preparar pruebas que
planteen situaciones especiales y que puedan provocar algún error. Para ello, las
r personas ajenas al desarrollo del módulo suelen aportar un punto de vista mucho
más distante y fresco que las que participan en él. En esta forma de trabajo
3
es fundamental la intuición, aunque ésta suele ir muy ligada a la experiencia
previa en otras situaciones similares.

8.4.2. Pruebas de caja transparente

Según se muestra en la figura 8.6, en la estrategia de prueba de caja transparente
(existen diversas denominaciones en inglés como white box, clear box, glass box) se
conoce y se tiene en cuenta la estructura interna del módulo. En la elaboración de
los casos de pruebas se trata de conseguir que el programa transite por todos los
posibles caminos de ejecución y ponga en juego todos los elementos del código. Por
tanto los casos de prueba deben conseguir que:

■ Todas las decisiones se ejecuten en uno y otro sentido.

3

■ Todos los bucles se ejecuten en los supuestos más diversos posibles.

■ Todas las estructuras de datos se modifiquen y consulten alguna vez.

292 PRUEBASDESOFT~¼RE

CASOS DE
i "Correcto THEN RESULTADOS
PRUEBA CLS[ Operar
(NO Corregh_datos

n
J ~
RESULTADOS
INTERNOS

Figura 8.6: Pruebas de caja transparente 1

En principio puede parecer que las únicas pruebas que realmente son necesarias
son las que sirven para demostrar el funcionamiento según las especificaciones y esto
se puede lograr con una estrategia de caja negra. Sin embargo, un programa es una
entidad de una complejidad muy superior a la del más sofisticado artilugio mecánico,
hidráulico o electrónico, para los que si suele ser suficiente con someterlos a pruebas 1
de caja negra. Como ejemplo se puede decir que un sencillo bucle, que se pueda 1

J
ejecutar entre O y 10 veces y que tenga en su interior sólo 5 caminós diferentes, se
puede ejecutar de casi 10 millones de formas diferentes. ,,

Es cierto que en la mayoría de los programas sólo se llegan a ejecutar un número 1

bastante reducido de todos los caminos posibles, pero también es cierto que no re-
sulta fácil prever a priori qué caminos se ejecutarán y cuáles no. Cuando se elaboran
las pruebas de caja negra pueden quedar perfectamente inexplorados caminos que
en un funcionamiento habitual no serán muy frecuentados, pero que sí son decisivos
en situaciones concretas y que, si no han sido probados convenientemente, pueden
producir un error en el peor momento.

Las pruebas de caja negra y de caja transparente deben ser complementarias y 1;

nunca excluyentes. De hecho es conveniente aplicar el método de análisis de valores

límite para elaborar pruebas de caja transparente teniendo en cuenta la estructura
del programa. Está claro que las pruebas de caja transparente deben ser propuestas
por alguien que haya participado o conozca la codificación en detalle.

Los métodos más ampliamente utilizados en la elaboración de pruebas de caja

transparente son los siguientes:

• Cubrimiento lógico

• Pruebas de bucles

• Empleo de la intuición

- -
 PRUEBAS DE UNIDADES 293

CUBRIMIENTO LÓGICO No parece muy razonable proponer casos de

prueba para conseguir que un programa se ejecute de todos los billones o tri-
llones de formas posibles, pero al menos debemos conseguir cierto cubrimiento
lógico de todas las secciones de código, y no dejar ninguna sin ejecutar alguna
vez.

Dado un fragmento de código como el que muestra el diagrama de flujo de la

figura 8. 7, denominaremos camino básico a cualquier recorrido que, siguiendo
las flechas de las líneas de flujo, nos permita ir desde el punto inicias (O) al pun-
to final (9) del diagrama. Se utiliza aquí un diagrama de flujo por su carácter
gráfico, pero los razonamientos se pueden trasladar de forma inmediata a un
as fragmento de código escrito en cualquier lenguaje de programación. Cada rom-
to bo del diagrama debe representar un predicado lógico simple, esto es, no puede
la ser una expresión lógica con algún operador OR, AND, etc. Hay que tener en
o, cuenta que cualquier expresión lógica siempre se puede representar utilizando
:\.5 un rombo por cada predicado lógico simple.
la
se

:o
s-
,Il

1e
)S
n

s
y 7 8

lS
a
,S

a Figura 8.7: Diagrama de flujo con 3 predicados lógicos simples

Primeramente, se trata de determinar un conjunto de caminos básicos que reco-

rran todas las líneas de flujo del diagrama alguna vez. Como máximo, el número
de caminos básicos necesarios vendrá determinado por el número de predicados
lógicos simples o rombos que tenga. el diagrama de flujo de acuerdo con la si-
guiente fórmula
294 PRUEBAS DE SOFTWARE

~º máximo de caminos = Nº predicados + 1

En el caso de la figura 8. 7 tenemos Nº máximo de caminos = 3 + 1 = 4 y para

este ejemplo serían suficientes los siguientes cuatro caminos básicos
Camino 1: O - 1 - 9
Camino 2: O - 1 - 2 - 3 - 4 - 5 - 1 - 9
Camino 3: O - 1 - 2 - 3 - 6 - 8 - 1 - 9
Camino 4: O - 1 - 2 - 3 - 6 - 7 - 1 - 9
Existen otros caininos tales como:
Camino 5: O - 1 - 2 - 3 - 4 - 5 - 1 - 2 - 3 - 6 - 7 - 1 - 9
pero ninguno de ellos utiliza alguna línea de flujo nueva no utilizada previa-
mente por los cuatro primeros. Lo que sí es posible es sustituir un camino por
otro siempre que con el conjunto se recorran todas las líneas.

10
7 8

Figura 8.8: Diagrama de flujo con 4 predicados lógicos simples

El método del cubrimiento lógico -consiste en elaborar casos de prueba para

que el programa recorra un determinado conjunto de caminos siguiendo cierta.<;
pautas. Para ello se pueden establecer distintos niveles de cubrimiento:

• ~IVEL I. Se trata de elaborar casos dt> prueba para que se ejecuten al

PRUEBAS DE UNIDA.DES 295

menos una vez todos los caminos básicos, cada uno de ellos por separado .
• NIVEL II. Se trata de elaborar casos de prueba para que se ejecuten todas
las combinaciones de caminos básicos por parejas. En el ejemplo de la figura
8.8 serían necesarios 7 caminos para probar las combinaciones por parejas.
Estos caminos podrían ser:
Camino 1: O - 1 - 11
Camino 2: O - 1 - 2 - 3 - 5 - 6 - 7 - 1 - 11
Camino 3: O - 1 - 2 - 3 - 5 - 6 - 8 - 1 - 11
Camino 4: O - 1 - 2 - 3 - 5 - 9 - 10 - 1 - 11
Camino 5: O - 1 - 2 - 4 - 5 - 6 - 7 - 1 - 11
Camino 6: O - 1 - 2 - 4 - 5 - 6 - 8 - 1 - 11
Camino 7: O - 1 - 2 - 4 - 5 - 9 - 10 - 1 - 11

• NI VEL III. Se trata de elaborar casos de prueba para que se ejecuten un

número significativo de las combinaciones posibles de caminos. Como se ha
comentado, cubrir todas las combinaciones posibles resulta inabordable.
Como mínimo la pruebas de cada módulo deben garantizas el nivel l. Según los
distintos autores, con el cubrilniento lógico se pueden quedar sin detectar el 50
■ P RUEBAS DE BUCLES Los bucles constituyen un elemento esencial en
cualquier programa y se debe prestar especial atención a la elaboración de
pruebas para ellos. Con este fin distinguiremos las siguientes situaciones:
• Bucle con número no acotado de repeticiones. Se elaborarán pruebas para:
o Ejecutar el bucle O veces
o Ejecutar el bucle 1 vez
o Ejecutar el bucle 2 veces
o Ejecutar el bucle un número moderado de veces
o Ejecutar el bucle un número elevado de veces
• Bucle con número :Yl de repeticiones. Se laborarán pruebas para:
o Ejecutar el bucle O veces
o Ejecutar el bucle 1 vez
o Ejecutar el bucle 2 veces
o Ejecutar el bucle un número intermedio de veces
o Ejecutar el bucle :.V1 - 1 veces
o Ejecutar el bucle l\1 veces
o Ejecutar el bucle 1-I 1- 1 veces
• Bucles anidados. El número de pruebas crece de forma geométrica con
el nivel de anidamiento. Para reducir este número se utiliza la siguientt>
técnica:
296 PRUEBAS DE SOFTWARE

1. Ejecutar todos los bucles externos en su número mínimo de veces para

probar el bucle más interno con el algoritmo de bucle que corresponda.
2. Para el siguiente nivel de anidamiento, ejecutar los bucles externos en
su número mínimo de veces y los bucles internos un número típico
de veces, para probar el bucle del nivel con el algoritmo de bucle que
corresponda.
3. Repetir el paso 2 hasta completar todos los niveles.
• Bucles concatenados. Si son independientes se probarán cada uno por se-
parado con alguno de los criterios anteriores. Si están relacionados, por
ejemplo el índice final de uno es el inicial del siguiente, es empleará un
enfoque similar para los bucles anidados.
EMPLEO DE LA INTUICIÓN También con la estrategia de caja transpa-
rente merece la pena dedicar un cierto tiempo a elaborar pruebas que sólo por
intuición podemos estimar que plantearán situaciones especiales. Es obvio que
parar ello es necesario conocer muy en detalle la estructura del módulo y tener
alguna experiencia previa.

8.4.3. E stimación de errores no de tectados

Aunque sea constatable que no aparecen nuevos errores y ha sido considerable
el esfuerzo empleado con las pruebas más diversas y sofisticadas, resulta imposible
demostrar que un módulo no tiene defectos. Este hecho resulta poco tranquilizador,
por lo que conviene obtener alguna estimación estadística de las erratas que puede
permanecer todavía sin ser detectadas.

Desde luego, el juego de pruebas sólo ejercita el módulo en una parte de sus
posibilidades y siempre pueden quedar situaciones sin explorar. P ara tener una esti-
mación del número de defectos que quedan sin detectar se puede utilizar la siguiente
estrategia:
l. Anotar el número de errores que se producen inicialmente con el juego de casos
de prueba El (por ejemplo El = 56).
2. Corregir el módulo hasta que no tenga ningún error con el mismo juego de casos
de prueba.
3. Introducir aleatoriamente en el módulo un número razonable de errores EA (por
ejemplo EA = 10) en los puntos más diversos. Esta labor deberá ser realizada
por alguien que no conozca el juego de casos de prueba.
4. S01neter el módulo con los nuevos errores al juego de casos de prueba y hacer
de nuevo el recuento del número de errores que se detectan ED (por ejemplo
ED = 95).
PRUEBAS DE UNIDADES EN PROGRAA1ACIÓN ORIENTADA A OBJETOS 297

EE = (EA - ED) * (El , ED) = (100 - 95) * (56 / 95) - 3 errores

5. Para el juego de casos de prueba considerado 1 suponiendo que se mantiene la

misma proporción estadística, el porcentaje de errores sin detectar será el mismo
para los errores iniciales que para los errores deliberados .

Por tanto el número estimado de errores sin detectar será: Dependiendo de lo

crítico que resulte el software y del resultado obtenido con esta estrategia. se debe
estudiar la conveniencia de elaborar nuevos casos de prueba.

8.5. Pruebas de unidades en program ación orientada a

objetos
En programación orientada a objetos la unidad se convierte en las dases u objetos.
que encapsulan tanto datos como operaciones. Dentro de una clase son las opera-
ciones o métodos de esta clase los elementos más pequeños que podemos probar. El
problema surge cuando un método es heredado por alguna subclase. E l hecho de
haber probado dicho método dentro de la superclasc no nos garantiza que funcione
correctamente para la subclase, ya que el contexto varía sutilmente. A diferencia del
software convencional en el que se prueba el algoritmo interno de un determinado
procedimiento o función con su interfaz correspondiente, en programación orientada
a objetos debemos probar la clase como unidad, en la que las operaciones van modi-
ficando los datos encapsulados en ella y por lo tanto el comportamiento de la clase.

Las secuencias de prueba de una clase se diseñan para probar las operaciones más
relevantes de ella, y es examinando los valores de los atributos de la clase donde
comprobaremos si existen errores. Existen varios métodos para probar una clase:

• Pruebas basadas en fallo. el objetivo es descubrir fall ,::. que durante el diseño se
hayan detectado o valorado como probables. Los casos de prueba se crean con
el fin de detectar dichos posibles fallos. Obviamente la efectividad dependerá
del esfuerzo e interés dedicado durante el diseño en analizar las posibles causas
de fallo.

• P ruebas aleatorias. se eligen de forma aleatoria una :=.erie de métodos dentro de

la clase para probarlos y se diseñan las secuencia, de prueba correspondientes.

• P ruebas de partición, de forma similar a la"- cla:;es de equivalencia utilizadas en

las pruebas dr software convencional, sr- pueden crear una serie de categorías en
las entradas ~· salidas para probar una cla-;e de forma selectiva. Las particiones
las podemos hacer con distintos criteri , :
 298 PRUEBAS DE SOFTWARE

• En base la capacidad de las operaciones de cambiar el estado de la clase,

es decir a modificar un determinado atributo.
• En base a los atributos que utiliza cada operación. Una categoria la com-
pondrían todas las operaciones que utilizan un determinado atributo.

8.6. Estrategias de Integración

Las unidades o módulo de un producto software se han de integrar para conformar
el sistema completo. Desgraciadamente, en esta fase de integración también aparecen
nuevos errores debidos a las más diversas causas:
• Desacuerdosde interfaz
• Interacción indebida entre módulos
• Imprecisiones acumuladas
entre otras. Durante la fase de integración se debe proceder en forma sistemática,
siguiendo una estrategia bien definida, para facilitar la depuración de los errores que
vayan surgiendo. Entre las f>Strategias básicas de integración tenemos:
■ Integración Big Bang
• Integración descendente (top-down)
• Integración ascendente (bottom-up)
Estas estrategias pueden emplearse independientemente o en forma combinada.

8.6.1. Integración Big Bang

Esta estrategia consiste en realizar la integración de todas las unidades en un
único paso. Como es fácil suponer, la cantidad de errores que aparecen de golpe puede
hacer casi imposible la identificación de los defectos que los causan, provocando un
auténtico caos. Sólo para sistemas muy pequeños se puede justificar la utilización de
esta estrategia. La ventaja fundamental es que se evita la realización del software de
"andamiaje)> que se requiere con las otras dos estrategias progresivas.

8.6.2. Integración descendente

Como se muestra en la figura 8.9, en esta estrategia de integración se parte inicial-
mente del módulo principal (iv1ódulo P) que se prueba con módulos de "andarniaje''
o sustitutos (en inglés stubs) de los otros módulos usados directa1nente (Sust. A) .
Los módulos sustitutos se van reemplazando, uno por uno, por los verdaderos y se
realizan las pruebas de integración correspondientes. La forma en que se produce
E ESTRATEGIAS DE INTEGRACIÓN 299

la sustitución e integración de los módulos verdaderos puede ser estrictamente por

niveles, por ramas o una mezcla, según vayan estando disponibles.
l-

Paso 1

,f Paso 2
n

Paso 3

Paso4
.e

Figura 8.9: Integración descendente.

La codificación de los sustitutos es un trabajo adicional que conviene simplificar

al máximo y para el que se pueden adoptar distintas soluciones:
■ No hacer nada y que sirva para comprobar la interfaz
n
e ■ Imprimir un mensaje de seguimiento con información de la llamada
n
■ Suministrar un resultado fijo
e
e ■ Suministrar un resultado aleatorio
■ Suministrar un resultado tabulado u obtenido con un algoritmo simplificado
La ventaja fundamental de la integración descendente es que se ven desde el
principio las posibilidades de la aplicación. Esto permite mostrar muy pronto al
l- cliente un prototipo sencillo y discutir sobre él posibles n1ejoras o modificaciones.
" Los inconvenientes más importantes son:
).

e l. La integración estrictamente descendente limita en cierta forma el trabajo en

e paralelo.
300 PRUEBAS DE SOFT1VARE

2. Al concluir la integración de los nuevos módulos desde otros módulos ya integra-

dos y definitivos, se tienen bastantes limitaciones para hacer pruebas especiales
o dirigidas a un objetivo específico. Para lograr esto es necesario desarrollar
nuevos módulos o hacer una inlcgración híbrida ascendente-descendente.

8.6.3. Integración ascendente

En la estrategia de integración ascendente se empieza por codificar por separado y
en paralelo todos los módulos de nivel más bajo. Para probarlos se escriben módulos
gestores o conductores (en inglés drivers) que los hacen funcionar independientemente
o en combinaciones sencillas. Por ejemplo, según se muestra en la figura 8.10, el
Gestor A es el encargado de realizar las pruebas de integración entre los módulos Al
y A2 antes de que se tenga disponible el módulo A definitivo. Los gestores se van
sustituyendo uno a uno por los módulos de mayor nivel según se van codificando, al
tiempo que se van desarrollando nuevos gestores si hace falta. En este caso, el orden
df' sustitución puede ser cualquiera, salvo para los últimos pasos, en que se necesita
que todos los módulos inferiores estén disponibles.

Paso 1
Módulo O

Paso2
Módulo C

Módulo a

Paso3
Módulo C

Módulo a

Figura 8.10: Integración ascendente

Aunque en algunos casos se puede prescindir de los gestores, su interés radica

fundamentalmente en su capac-idad para probar de forma explícita situaciones es-
peciales o infrecuentes. Las ventajas de la integración ascendente coinciden con los
inconvenientes de la integración descendente:
■ Facilita el trabajo en paralelo
■ Facilita el ensayo de situacione:; especiales
E PRUEBAS DE V.4.LIDACIÓN 301

Por el contrario, el inconveniente más importante es que resulta difícil ensayar el

is funcionamiento global del producto software hasta el final de su integración.

La mejor solución es utilizar una integración ascendente con los módulos de nivel
más bajo y una integración descendente con los de nivel más alto. Esto se denomina
integración sandwich.

y 8.6.4. Estrategias de integración en programación orie ntada a ob-

jetos
e
~l En el software orientado a objetos no existe una estructura de control jerárquica.
1 como en el software convencional estructurado. Por lo tanto las estrategias de inte-
n gración ascendente y descendente no tienen sentido. Las operaciones dentro de una
Ll clase no pueden ir integrándose incrernentalmente debido a las interacciones entre
n los componente de la clase.
a
Existen dos estrategias para la integración de software orientado a objetos:
• P rueba basada en hebra, se integran todas las clases necesarias para responder
a una determinada entrada o evento del sistema. Cada hebra se integra y prueba
de forma independiente.
• Prueba basada en uso, se comienza construyendo y probando las clases llamadas
independientes, es decir las que menos relación tienen con las posibles clases
servidor. A continuación se prueban las clases dependientes, que usan clases
independientes. De esta forma se siguen construyendo el sistema, añadiendo y
probando más clases dependientes.
Los módulos gestores y sustitutos también se utilizan pero de forma diferente a la
integración convencional. Por ejemplo se puede usar un módulo gestor para sustituir
el interfaz de usuario y probar el resto del sistema antes de la implementación del
interfaz. Los módulos sustitutos pueden utilizarse en situaciones donde se requiere
la colaboración de dos clase y una de ellas no está todavía implementada.

8. 7. Pruebas de validación
t Una vez culmina la integración y sus pruebas asociadas, y con el software com-
pletamente ensamblado, el siguiente paso consiste en asegurar que el producto ob-
tenido cumple la especificación bajo la que se construyó. La validación del software
se consigue a través de una serie de pruebas que comprueban la conformidad con los
requerimientos, no sólo en cuanto a funcionalidad, sino también en cuanto a rendi-
miento, ergonomía y documentación.
302 PRUEBAS DE SOFTl V.4.RE

:\1ás allá incluso de la propia especificación, para comprobar que un producto

software es realmente útil para sus usuarios, es conveniente que estos últimos inter-
vengan también en las pruebas finales del sistema. De esta manera se pueden poner
de manifiesto nuevas deficiencias no caracterizadas hasta entonces. Para un desarro-
llador de software es imposible prever cómo usará el cliente realmente el programa.
Algunos problemas típicos son:
• Mensajes ininteligibles para el usuario
• Presentación inadecuada de resultados
■ Deficiencias en el manual de usuario
• Procedimientos de operación inusuales
Para la realización de estas pruebas se pueden necesitar semanas o meses, porque
el usuario necesita ir aprendiendo el manejo del nuevo sistema. Es probable que los
problemas más graves aparezcan ya al comienzo y por ello es aconsejable que alguien
del equipo de desarrollo acompañe al usuario durante la primera toma de contacto.
Se denominan pruebas alfa a las primeras pruebas que se realizan en un entorno con-
trolado, donde el usuario tiene el apoyo de alguna persona del equipo de desarrollo
y a su vez esta misma persona puede seguir muy de cerca la evolución de las pruebas.

Posteriormente, en las pruebas beta, uno o varios usuarios trabajan con el siste-
ma en su entorno normal, sin apoyo de nadie, y anotando cualquier problema que se
presenta. En algunos sistemas pueden quedar registradas automáticamente las últi-
mas operaciones que han dado lugar al problema. Sin embargo es muy importante
que sea el usuario el encargado de transmitir al equipo de desarrollo cuál ha sido el
procedimiento de operación que le llevó al error. Esta información resulta vital para
abordar la corrección.

8.8. Pruebas del sistema

El software es un elemento de un sistema basado en computadora más grande.
Las pruebas de sistema tienen como objetivo probar el sistema completo basado en
computadora. A continuación se describen diferentes tipos de pruebas de sistema,
todas ellas encaminadas a asegurarse que el software se ha integrado de forma co-
rrecta con su entorno.

P rue bas de re cuperación

Sirven para comprobar la capacidad del sistema para recuperarse antes fallos.
Con estas pruebas, además de provocar el fallo, se debe comprobar si el sis-
tema lo detecta, si lo corrige cuando así está especificado y si el tiempo de
recuperación es menor del también especificado.
RE CONCLUSIONES 303

:to Pruebas de seguridad

er- Sirven para comprobar los mecanismos de protección contra un acceso o ma-
1er nipulación no autorizada. Las pruebas deberán intentar violar los mecanismos
~o- previstos corno si de un intruso se tratara.
1a.
Pruebas de resistencia
Sirven para comprobar el comportamiento del sistema ante situaciones excep-
cionales. Las pruebas deberán forzar el sist ema por encima de su capacidad y
prestaciones normales para verificar cuál es su comportamiento y cómo se va
degradando en estos casos.
Pruebas de sensibilidad
Sirven para comprobar el tratamiento que da el sistema a ciertas singularidades
ue relacionadas casi siempre con los algoritmos matemáticos utilizados. Las prue-
os bas deben buscar combinaciones de datos que puedan provocar alguna operación
~n incorrecta o poco precisa en un entorno del problema especialmente sensible.
o.
Pruebas de rendimiento
n-
Sirven para comprobar las prestaciones del sistema que son críticas en tiem-
lo
po, normalmente en sistemas de tiempo real o en sistemas embebidos. Para
.S.
medir los tiempos se suelen necesitar equipos de instrumentación externos (os-
ciloscopios, emuladores, analizadores lógicos .... ). Por ejemplo se pueden forzar
e-
al sistema provocando múltiples interrupciones simultáneamente para medir el
1-
tiempo máximo que emplea en tratarlas.
ce Pruebas de despliegue o de configuración
el Sirven para comprobar el funcionamiento de software que debe ejecutarse en
·a varias plataformas y sistemas operativos distintos. Además permiten comprobar
la correcta instalación del programa y la documentación para ello.

8.9. Conclusiones
Probar es parte inevitable del desarrollo de cualquier sistema de software, de he-
n cho, las pruebas de software representan la parte más importe dentro del esfuerzo
~, técnico en el proceso de software. Incluso en los sistemas más pequeños es necesario
-
marcar la estrategia para planificar y ejecutar las pruebas sistemáticas que garanti-
cen la calidad del producto final.

De forma global, la estrategia de pruebas comienza por las partes más pequeña
_ con entidad propia o unidades, las cuales se integran hasta componer el programa
completo. Una vez integrado, se comprueba que> ~E' cumplen los requisitos que se
e especificaron. Finalmente se realizan pruebas para mejorar otros aspectos tales como
el rendimiento, la integrabilidad o la documentación.
304 PRUEBAS DE SOFTlVARE

8.10. Ejercicios propuestos

l. Analícese las soluciones comerciales para la planificación y gestión de pruebas
que ofrecen las empresas u organizaciones de las páginas web que se listan a
cont inuación:
l. l. www.testmanagement.com
1.2. www.compuware.com
1.3. www.soft.com
1.4. www.opensourcetesting.org
2. Consúltese la guía SWEBOK y revise la propuesta de clasificación de pruebas
que esta hace.
3. A partir de un algún programa convencional que se haya implementado, realí-
cese pruebas de caja negra y caja transparente.
4. A partir de un algún programa orientado a objetos que se haya implementado,
realícese las siguientes pruebas:
■ Pruebas de partición de sus clases
■ Pruebas de integración basadas en hebra y basadas en uso
5. ¿Quién realiza las pruebas de validación? Razónes la respuesta.
RE

>as
l a

Bibliografía

>as lAbbott83] R.J. Abbott: Pro gram Design by Infmmal English Descriptions..
Comm.ACl\.I, V.26 , N.11, )Jov.1983:

tli- [Ale77] A LEXANDER, C: A Pattern Language. Oxford l"m~t'· Press, 1977.

(Aho83] A.V. Ano ) J. HOPEROFT, J. CLLMA'.'\:'\. :Jata .. rores and Algorithms.

lo, Addison-vVesley, 1983.

(Beck00] BECK, K ENT, Extreme Programming EzJ;!;=L6>11: Embrace Change.

Addison-\Vesley Professional, 2000.

[Boehm88] BOEH:\1 1 B.vV. , A Spiral Model of Soft..::arc Deetlopment and Enhance-

ment, IEEE Computer, :Mayo 1988.

(Booch94] G. BoocH, Object-Oriente d Analysis andlle~~ ' A.pplications {2nd

.Ed}. Benjamín/ Cummings, 1994.

[Booch99] G. BoocH, J. RU :\fBAUGH, I. JACOBSC, -. El

delado, Addison vVesley, 1999.

[B00TH67] T AYLOR L. BOOTH , Sequential .Afachina Aat,.mata Theory ;\ w

York: vViley, 1967.

[BenA.ri90] IvI. l3 EN-ARI, Principies of Concttrrent

Prentice-Hall, 1990.

[Budd94) T. B UDD: Introducción a la Programación

\Vesley Iberoamericana, 1994.

[Cerrada00] J.A. CERRADA, :\1. COLLADO Y OTRi.), tos de Programa

con Módula-2. Editorial "Cni,·ersitaria Ramón .\reces.. M2m1d. 2000.
[Coad90) P. COAD, E. YOURDOX, Object-Oriented. __ , .....,..,.,. Prentice-HalL 1

[Collado87] 11. COLLADO. R. l'vfüRALES , J .J. ~lo CU:..'•~ rocturas de Datos: Ra:.-
lización en Pascal, EdicioneR Diaz de Santos. : -

305
306 BIBLIOGRAFÍA

[Date90] C.J. DATE, An lntroduction to Database Systems, Addison-vVesley, 1990.

Addison-\Vesley Iberoamericana, 1993.

[De:Y1arco79] T.DE~11ARCO, Structured analysis and System specification, Prentice

Hall, 1979.
[Dahl72j 0. DAHI.,, E. DIJKSTRA, C. HOARE, Structure Programming, Acadcmic
Press, 1972.
(Dijkstra68] E. vV. DIJKSTRA , A Constructive Approach to the Problem of Program
Correctness. BIT Nº 8, pp. 174-186, 1968.
[D0D88] DOD-STD-2167 A, Military Standard: Defense System Software Develop-
ment, USA Dep. of Defense, Feb 1988.
[De:Miguel93] A. DE l'v1TGUEL, l\.1.G. PlATlNl , Concepción y diseño de bases de
datos: del modelo E-R al modelo relacional. Ra-l\.Ia, 1993.
rESA91] ESA BOARD FOR SOFTWARE STAXDARDISATION AXD CONTROL (BSSC),
ESA Software Engineering Standars. Jssue 2, USA Dep. of Defense, FEb 1991.
[ETé\1CHIL] http://etimologias.dechile.net
[Gam95] GAM1,1A , E ET AL, Design Patterns: Elements of Reusable Object-Oriented
Software, Addison-\Vesley, 1995.
[Hatley87j D. J. HATLEY, l. A. PIRBHAl, Strategies for Real-Time Systems Speci-
fication. Dorset House, 1987.
[IEEE87] IEEE STD 1016-1987, IEEE Recommended Practice for Software Design
Descriptions.IEEE Computer Society Press, 1987.
(IEEE84] IEEE STD 830-1984,IEEE Guide to Software Requirements Specifications,
1984.
[IEEE93] IEEE SOFTWARE ENGINEERING STA:\"DARDS COLLECTION,IEEE Com-
puter Society Press, 1993.
[IS01694908] INTERXATIONAL STAXDARD ÜRGAXIZATIOX , Quality management
systems Partic'ular requirements for the application of ISO 9001:2008 for au-
tomotive production and relevant se1'Vice part organizations, 2008.
[Jacobson92] IVAR JACOBSO:'- , l'vlAGl\ US CHRISTERSON , PATRlK JONSSON, Güx-
NAR ÜVERGAARD , Object-Oriented Software Engineering: A Use Case Driven
Approach,(AC~1 Press) Addison-Wesley, 1992,
BIBLIOGR.4.FÍA 307

(Jackson75] l\!1.A. J ACKSON Principies of Pro gram Design, Academic Press,1975.

[Jackson83] ~vi.A. J ACKSON System De11elopment Prentice-Hall, 1983.

[Liskov80] B. LISKOV Modular Program Construction Using Abstractions, Lectures
Kotes in Computer Science Kº 86.
[:McCall78] J.A. :tvlcCALL, J.O. CAVANO, A Framework for Measurement of Soft-
ware Quality:AC:vl Software Quality Assurance vVorkShop , ~ov 1978.
íN1ic04] NlICROSOFT, Prescriptive Architecture: Integration and Pattems, :VISDN,
2004.
[:.VIyers78] G. l\!1YERS Composite Stru.ctttred Design. Van Nostrand, 1978.
[NAUGHT0:\'97] JPATRICK KAUGHTON; HERBERT SHILOT, J ava, Manual de
Refemcia,:YlcGraw-Hill / Interarnerica, S.A., 1997.
[Orr81l K. ÜRR, Structured R equierements Definition, Ken Orr & Associates, 1981.
[Parnas72] D. L. P ARNAS, On Gritería to be used in Decomposing Systems into
Modules,Comm. AC:tv'l , V.14, N.l, Abril.1972, pp.221-227.
[Page-.Jones80] :tvl. P AGE-JONES, The Practical Guide to Structured System Design,
Yourdon-Press, 1980.
[Pratt84] T. PH.ATT, Programming Languages. 2° Edici6n, Prentice-Hall, 1984.

ÍPressmanl0] R.S. PRESS:\,1A~, Ing eniería del Software: Un Enfoque Práctico,

l\!lcGraw-Hill)0l0.
[Rumbaugh91] RCMBAUGH, l\!I BLAHA, \V. PREMERLANI , F.EDDY, vV. LOREX-
SEX, Object-Oriented Modeling and Design, Prentice-Hall, 1991.
[Stevens74] \iV. STEVENS, G. IVIYERS, L. CONSTAXTINE, Structured Design, IBYI
Systems Journal, V. 13 nº 2, 1974, pp. 115-139.
[S\VEBOK04] A . ABRAN, J. \V. NlOORE; EDITORS, P. Bül:RQUE, R. DUPl:IS,
Guide to the Software Engineering Body of Knowledge, Version IEEE Computer
Societv.2004.
V'

lvVarnicr81] J.D. \Varnier: Logical Construction of Systerns. Van Nostrand Reinhold,

1981.
[\i\'irth71] \VIRTH N., Program Development by Stepwise Refinement) Comm.AC:\11,
V.14, K.4, 1971, pp.221-227.
ívVirth80] \VIRIII N., Algoritmos + Estructuras de Datos = Programas, Editorial
Castillo, 1980.
.308 BIBLIOGR.4.FÍA

[Yourdon79j E. N. YüURDü:'\, L. CO:\iSTA:'\TlNt Structured Design. Prcntice-Hall,

1979.
[Yourdon90l YOt;RDO>l, E.~., 1vfodern Structured Analysis, Prentice-Hall,1990 .

....
ISBN-13: 978-84-9961-003-1