Campderrich B (2003) - Ingenieria del software - Katherine Pantoja

Vista previa del material en texto

Ingeniería
del software
Ingeniería
del software
Benet Campderrich Falgueras
Primera edición: abril 2003
© Fundació per a la Universitat Oberta de Catalunya
© Benet Campderrich Falgueres, del texto
© Editorial UOC, de esta edición
Aragón, 182, 08011 Barcelona
Material realizado por Eureca Media, SL
Impresión:
Diseño: Manel Andreu
ISBN: 84-8429-793-4, del producto
ISBN: 84-8318-997-6, del libro
Depósito legal:
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, 
reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio,sea éste eléctrico, 
químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita 
de los titulares del copyright.
Autor
Benet Campderrich Falgueras
Doctor en Ingeniería Industrial. Especializado en ingeniería del software y bases de datos. 
Profesor titular de la Universidad Rovira i Virgili.
© Editorial UOC 7 Índice
Índice
Presentación ................................................................................................... 13
Capítulo I. Introducción a la ingeniería del software OO ................ 15
1. Qué es la ingeniería del software ............................................................. 15
1.1. El software como producto industrial.................................................. 16
1.2. La ingeniería del software .................................................................... 17
1.3. Los grandes problemas de la ingeniería del software:
la calidad y la productividad............................................................... 17
2. El ciclo de vida del software ..................................................................... 19
2.1. El ciclo de vida clásico......................................................................... 20
2.2. Los ciclos de vida iterativos e incrementales ...................................... 23
3. Desarrollo estructurado y desarrollo orientado a objetos ..................... 28
3.1. Los métodos estructurados.................................................................. 28
3.2. Los métodos orientados a objetos....................................................... 28
3.3. Los métodos formales.......................................................................... 30
4. Las herramientas CASE ............................................................................. 30
5. El OMG y el UML ....................................................................................... 32
5.1. El Object Management Group (OMG) .................................................... 32
5.2. Unified Modeling Language (UML) ........................................................ 32
Conclusiones ................................................................................................... 35
Capítulo II. UML (I): el modelo estático ................................................ 37
1. Concepto de modelo estático y diagrama de clases ............................... 37
2. Clasificadores ............................................................................................. 39
3. Paquetes...................................................................................................... 40
4. Clase y conceptos afines ........................................................................... 43
4.1. Representación ampliada de las clases ................................................ 43
© Editorial UOC 8 Ingeniería del software
4.2. La herencia en el análisis y el diseño .................................................. 48
4.3. Variantes en el concepto de clase ....................................................... 51
4.4. Interfaces ............................................................................................. 54
5. Representación de los objetos .................................................................. 56
6. Relaciones entre clases .............................................................................. 57
6.1. Asociaciones ........................................................................................ 57
6.2. Agregaciones y composiciones............................................................ 63
6.3. Relaciones de dependencia ................................................................. 66
7. Comentarios y restricciones ..................................................................... 67
7.1. Comentarios ........................................................................................ 67
7.2. Restricciones........................................................................................ 67
Conclusiones ................................................................................................... 69
Capítulo III. UML(II): el modelo dinámico 
y de implementación ............................................................................. 71
1. El diagrama de estados.............................................................................. 71
1.1. Conceptos básicos ............................................................................... 72
1.2. Notaciones básicas............................................................................... 74
1.3. Transiciones complejas ....................................................................... 78
1.4. Estados compuestos............................................................................. 79
1.5. Notación ampliada del estado............................................................. 82
2. El diagrama de casos de uso ..................................................................... 83
2.1. Actores ................................................................................................. 83
2.2. Concepto de caso de uso..................................................................... 85
2.3. Relaciones entre casos de uso.............................................................. 86
2.4. Notación.............................................................................................. 87
3. Los diagramas de interacción................................................................... 88
3.1. Interacciones y colaboraciones ........................................................... 88
3.2. El diagrama de colaboración ............................................................... 93
3.3. El diagrama de secuencias ................................................................... 95
4. El diagrama de actividades....................................................................... 99
4.1. Elementos específicos .......................................................................... 99
5. Los diagramas de implementación ........................................................ 102
5.1. El diagrama de componentes ............................................................ 102
5.2. El diagrama de despliegue ................................................................. 105
Conclusiones ................................................................................................. 107
© Editorial UOC 9 Índice
Capítulo IV. Recogida y documentación de requisitos ................... 109
1. Los requisitos ........................................................................................... 110
1.1. Clases de requisitos ........................................................................... 110
2. Fuentes de información .......................................................................... 111
3. Pasos de la recogida y documentación de requisitos ........................... 112
3.1. El contexto del software ..................................................................... 112
3.2. Los guiones ........................................................................................ 114
3.3. Identificación de los actores.............................................................. 114
3.4. Identificación de los casos de uso ..................................................... 115
3.5. Identificaciónde las relaciones entre casos de uso........................... 116
3.6. Identificación de las relaciones de especialización entre actores ..... 118
3.7. La documentación de los casos de uso ............................................. 118
4. La recogida y documentación de requisitos de la interfaz de usuario ... 120
4.1. Concepto de interfaz de usuario ....................................................... 120
4.2. Identificación de las restricciones técnicas ....................................... 121
4.3. Elaboración de los perfiles de usuario............................................... 121
4.4. Documentación de las tareas actuales y futuras ............................... 122
4.5. Comparación entre tareas y casos de uso ......................................... 123
4.6. Especificaciones de usabilidad .......................................................... 124
5. Ejemplo..................................................................................................... 124
5.1. Información inicial ........................................................................... 125
5.2. Modelo del dominio.......................................................................... 125
5.3. Modelo del negocio........................................................................... 126
5.4. El glosario del modelo del negocio ................................................... 128
5.5. Los guiones ........................................................................................ 129
5.6. Casos de uso ...................................................................................... 130
5.7. Requisitos de la interfaz de usuario................................................... 135
Conclusiones ................................................................................................. 139
Capítulo V. Análisis orientado a objetos ............................................. 141
1. El papel del análisis................................................................................. 142
1.1. La relación entre la recogida de requisitos y el análisis .................... 142
1.2. La relación entre el análisis y el diseño............................................. 142
1.3. La utilidad del análisis....................................................................... 143
2. Paquetes de análisis y paquetes de servicios ......................................... 144
2.1. Los paquetes de análisis .................................................................... 145
© Editorial UOC 10 Ingeniería del software
2.2. Los paquetes de servicios................................................................... 145
3. Revisión de los casos de uso ................................................................... 146
4. Especificación de las clases de análisis .................................................. 147
4.1. Identificación de las clases de entidades........................................... 148
4.2. Especificación de los atributos de las clases de entidades................. 150
4.3. Identificación de las relaciones entre clases...................................... 151
4.4. Identificación de las clases de frontera, las clases de control 
y de las operaciones. Diagrama estático de análisis .......................... 158
5. Especificación formal de los casos de uso ............................................. 158
6. Análisis de la interfaz de usuario ........................................................... 159
7. Ejemplo..................................................................................................... 160
7.1. Revisión de los casos de uso.............................................................. 160
7.2. Paquetes de análisis y de servicios .................................................... 160
7.3. Identificación de las clases de entidades........................................... 161
7.4. Especificación de los atributos de las clases de entidades................. 162
7.5. Relaciones .......................................................................................... 163
7.6. Identificación de las clases de frontera, las clases de control 
y de las operaciones........................................................................... 166
7.7. Especificación formal de los casos de uso ......................................... 169
7.8. Análisis de la interfaz de usuario....................................................... 171
Conclusiones ................................................................................................. 175
Capítulo VI. Diseño orientado a objetos.............................................. 177
1. El papel del diseño .................................................................................. 178
1.1. La relación entre el diseño y la realización....................................... 178
1.2. La utilidad del diseño ........................................................................ 179
2. La reutilización ........................................................................................ 179
2.1. La reutilización de clases ................................................................... 179
2.2. La reutilización de componentes ...................................................... 180
2.3. Los patrones ...................................................................................... 180
2.4. Marcos de aplicaciones...................................................................... 192
3. El diseño arquitectónico ......................................................................... 193
3.1. Establecimiento de la configuración de la red .................................. 194
3.2. Establecimiento de los subsistemas................................................... 194
4. El diseño de los casos de uso .................................................................. 195
© Editorial UOC 11 Índice
5. Revisión del diagrama estático de diseño ............................................. 196
5.1. Normalización de los nombres ......................................................... 197
5.2. Reutilización de clases ....................................................................... 198
5.3. Adaptación de la herencia en el nivel soportado por el lenguaje 
de programación ............................................................................... 198
5.4. Sustitución de las interfaces .............................................................. 201
5.5. Cambios para la mejora del rendimiento ......................................... 201
5.6. Especificación de las operaciones implícitas..................................... 202
5.7. Referencias a las clases de frontera.................................................... 202
5.8. La clase inicial ................................................................................... 203
5.9. Cohesión y acoplamiento ................................................................. 203
6. Diseño de la persistencia ........................................................................ 205
6.1. Persistencia con bases de datos orientadas a objetos ........................ 206
6.2. El modelo para bases de datos relacionales y ficheros clásicos: 
alternativas ........................................................................................ 206
6.3. Persistencia con bases de datos object-relational ................................ 215
7. Diseño de la interfaz gráfica de usuario ................................................ 216
7.1. Elementos y funcionamiento de la interfaz gráfica de usuario ........ 217
7.2. El diseño de las interfaces gráficas .................................................... 236
8. Diseño de los subsistemas ....................................................................... 243
9. Ejemplo..................................................................................................... 244
9.1. El diseño arquitectónico ...................................................................244
9.2. El diseño de los casos de uso ............................................................. 244
9.3. El diagrama estático de diseño.......................................................... 249
9.4. El diseño de la persistencia ............................................................... 251
9.5. El diseño de la interfaz de usuario .................................................... 254
9.6. El diseño de los subsistemas.............................................................. 258
Conclusiones ................................................................................................. 260
Capítulo VII. Introducción al software distribuido ........................ 261
1. Entornos distribuidos y entornos abiertos ............................................ 261
1.1. Objetivos de los entornos distribuidos ............................................. 262
1.2. Importancia de las normas en los entornos distribuidos ................. 263
1.3. Concepto de sistema abierto ............................................................. 263
2. Entornos cliente/servidores clásicos...................................................... 264
2.1. Ventajas e inconvenientes de la arquitectura cliente/servidor......... 265
2.2. Arquitecturas cliente/servidor de dos capas...................................... 266
2.3. Arquitecturas de más de dos capas.................................................... 267
© Editorial UOC 12 Ingeniería del software
3. Entornos con middleware: CORBA ........................................................ 268
3.1. Concepto de middleware.................................................................... 268
3.2. CORBA............................................................................................... 269
4. RMI............................................................................................................ 298
4.1. Mecanismos de una invocación remota ........................................... 298
5. Documentos compuestos distribuidos: DCOM..................................... 299
5.1. Concepto de documento compuesto ................................................ 299
5.2. Aspectos de la gestión de los documentos compuestos.................... 300
5.3. OLE, COM y DCOM.......................................................................... 301
6. Desarrollo del software distribuido........................................................ 308
6.1. El análisis de requisitos en el caso de software distribuido ............... 308
6.2. La distribución de los objetos ........................................................... 308
Bibliografía.................................................................................................... 312
Glosario ......................................................................................................... 314
© Editorial UOC 13 Presentación
Presentación
La ingeniería del software comprende los métodos y las técnicas que se utili-
zan en el desarrollo profesional del software. Se trata de un campo muy amplio,
del cual esta materia sólo trata una parte. 
La ingeniería del software consta principalmente de dos familias de técnicas:
• Las estructuradas, cronológicamente las más antiguas.
• Las orientadas a objetos (OO), que constituyen la parte principal de esta obra,
con las exclusiones mencionadas.
El resto de la obra es una introducción a la ingeniería del software.
La tecnología de elaboración de software orientado a objetos ha tenido la ma-
yor parte de su desarrollo desde 1985 hasta la actualidad. Como suele pasar con
toda nueva tecnología, al principio aparecen muchas técnicas alternativas y el
paso del tiempo comporta que muchas se abandonen y sólo quede una o algunas
que llegan a ser un estándar, oficial o de hecho. Parece que la tecnología orien-
tada a objetos ha alcanzado hace unos pocos años esta situación, al menos en lo
que respecta al modelo básico, del cual existe el estándar denominado UML, ya
ampliamente aceptado y utilizado. Éste es el modelo que utilizamos.
Además del modelo utilizado, otro aspecto fundamental del desarrollo de
software es el método, ya que, si utilizamos el mismo modelo, podemos imagi-
nar muchos métodos diferentes que utilizan las notaciones del modelo en otro
orden o para otros propósitos distintos. A diferencia del caso del modelo básico,
es poco probable que se imponga un método como estándar; como mucho se
puede establecer como estándar legal la presentación de una determinada docu-
mentación elaborada según un modelo fijado, pero la manera como se trabaje
para elaborarla siempre tendrá un margen de libertad amplio.
© Editorial UOC 14 Ingeniería del software
En esta obra se ha optado por seguir un método inspirado en el denominado
Rational Unified Process, porque éste es bastante elaborado y coherente y, ade-
más, ha sido desarrollado esencialmente por el mismo equipo que desarrolló el
UML, lo cual ofrece una cierta garantía de coherencia entre el método y el mo-
delo.
Se puede considerar que esta obra tiene una parte básica, un núcleo y una
conclusión:
• La parte básica comprende unos conocimientos fundamentales, que son el ca-
pítulo “Introducción a la ingeniería del software OO”, dedicado a los conceptos
generales de la ingeniería del software; el capítulo “UML (I): el modelo estático”
y el capítulo “UML (II): el modelo dinámico y de implementación”.
• El núcleo de la obra está constituido por los capítulos “Recogida y documen-
tación de requisitos”, “Análisis orientado a objetos” y “Diseño orientado a
objetos”.
• La conclusión es el capítulo “Introducción al software distribuido”, que ofrece
una visión general de la tecnología del software distribuido orientado a obje-
tos. Este tema conduce a introducir no solamente la problemática y las técni-
cas directamente relacionadas con la distribución del software, sino también
conceptos que tienen un campo de aplicación más amplio.
© Editorial UOC 15 Capítulo I. Introducción a la...
Capítulo I
Introducción a la ingeniería del software OO
En este capítulo se empieza a introducir el concepto de ingeniería de software y
a presentar su problemática. Se describe con detalle el ciclo de vida clásico o en cas-
cada, y se presentan los modelos de ciclo de vida alternativos, en especial los cono-
cidos como modelos iterativos e incrementales, entre los cuales se describe el ciclo
de vida del Rational Unified Process.
Se definen también las dos grandes líneas tecnológicas actuales en el desarro-
llo de software: el desarrollo estructurado y el desarrollo orientado a objetos, y
se introduce el concepto de herramienta CASE. El capítulo termina con la pre-
sentación del origen y estatus del modelo estándar UML, el modelo orientado a
objetos que se utiliza en esta obra, y del OMG, la organización responsable del
mismo.
1. Qué es la ingeniería del software
Un sistema de software, denominado también aplicación o simplemente
software, es un conjunto integrado de programas que en su forma definitiva se
pueden ejecutar, pero comprende también las definiciones de estructuras de da-
tos (por ejemplo, definiciones de bases de datos) que utilizan estos programas y
también la documentación referente a todo ello (tanto la documentación de
ayuda en el uso del software para sus usuarios como la documentación generada
durante su construcción, parte de la cual también servirá para su mantenimien-
to posterior).
© Editorial UOC 16 Ingeniería del software
1.1. El software como producto industrial
Un software no es una obra de arte, sino un producto de consumo utilitario
y masivo; para una empresa o trabajador autónomo, el software es un medio auxi-
liar que interviene de manera más o menos indirecta, pero a menudo imprescin-
dible, en su gestión y cada vez más en su proceso productivo; también existe,
como todos sabemos, un consumo privado de software. Por tanto, se puede con-
siderar plenamente como un producto industrial.
Por ejemplo...… los bancos, las industrias de fabricación en serie, las empresas de comercio electró-
nico, etc. actualmente no podrían funcionar sin software.
Sin embargo, es un producto industrial con algunas características especiales.
En primer lugar, es mucho más un producto singular que un producto que se fa-
brique en serie (aunque algunos software tienen muchos miles de usuarios e, inclu-
so, millones), ya que, si bien existe –y no siempre– producción en serie de copias
del software, ésta es una actividad muy poco importante dentro del conjunto de su
proceso productivo y relativamente sencilla.
¡La producción de software se parece a la construcción!
Desde cierto punto de vista, la producción de software se parece a la construcción de vi-
viendas o edificios industriales, por ejemplo, en el hecho de que cada producto es dife-
rente y su elaboración se basa en un proyecto específico (en el caso de producción en
serie, lo que se proyecta es un prototipo del producto, y no cada unidad que se produce).
© Editorial UOC 17 Capítulo I. Introducción a la...
Otras características del software son, como señala Pressman, que no se estro-
pea por el uso ni por el paso del tiempo. Si finalmente se tiene que sustituir es
porque se ha quedado tecnológicamente anticuado o inadaptado a nuevas ne-
cesidades o porque ha llegado a resultar demasiado caro mantenerlo.
1.2. La ingeniería del software
En general, a cada tipo de producto industrial corresponde un tipo de in-
geniería, entendida como el conjunto de métodos, técnicas y herramientas
que se utilizan tanto para desarrollar el producto (es decir, elaborar el proyec-
to o prototipo) como para fabricarlo (afinando más se puede decir que exis-
ten, pues, dos ingenierías para cada tipo de productos: la del producto y la del
proceso).
Una técnica es la manera preestablecida en la que se lleva a término un paso
en la elaboración del producto, un método es una manera determinada de apli-
car varias técnicas sucesivamente y una herramienta es un instrumento de cual-
quier tipo que se utiliza en la aplicación de una técnica. 
El software no es ninguna excepción a esta regla, y, por tanto, hay una inge-
niería del software que comprende las técnicas, métodos y herramientas que se
utilizan para producirlo. 
En el caso de la ingeniería del software no se suele hablar de ingeniería de pro-
ceso; quizá se podría pensar que es la que hace referencia a la programación en
sentido estricto, pero cada vez es menos nítida la distinción entre la programa-
ción y las fases anteriores en el desarrollo de software.
1.3. Los grandes problemas de la ingeniería del software:
la calidad y la productividad 
A pesar de los grandes adelantos que ha habido en las técnicas de desarrollo
de software durante los últimos treinta años, tanto la calidad del software como
la productividad de su proceso de elaboración todavía no han alcanzado niveles
© Editorial UOC 18 Ingeniería del software
plenamente comparables con los de otras tecnologías más antiguas. Todo esto,
combinado con un aumento realmente espectacular de la demanda de software,
ha provocado lo que se ha denominado la crisis del software.
En cuanto a la calidad, la causa principal de dificultades es la gran complejidad
del software comparado con otros tipos de productos, que provoca, por ejemplo,
que no sea posible, ni mucho menos, probar el funcionamento de un software en
todas las combinaciones de condiciones que se pueden dar. Y eso ocurre en una
época en la que se da cada vez más importancia a la calidad en todos los ámbitos,
al considerarla un factor de competitividad dentro de unos mercados cada vez
más saturados y, por tanto, más exigentes. No es extraño, pues, que el tema de la
calidad (y dentro de éste, cuestiones como la garantía de calidad y las certificacio-
nes oficiales de calidad) adquiera una importancia creciente dentro de la ingenie-
ría del software.
Por lo que respecta a la productividad, cabe decir para empezar que cual-
quier fabricación en serie tiene necesariamente una productividad mucho más
elevada que la fabricación de un producto singular; pero, incluso, si la compa-
ramos con otras ingenierías de producto singular, la productividad es clara-
mente inferior. La complejidad del producto también puede ser una causa de
este hecho, pero ciertamente no es la única. Un factor que tiene un peso real-
mente importante en la baja productividad es el hecho de que, a diferencia de
las otras tecnologías, en un proyecto de software el desarrollo empieza tradicio-
nalmente de cero (sólo recientemente se utilizan fragmentos de software “pre-
fabricados”).
El aprovechamiento de elementos en la fabricación en serie
Cuando se diseña un nuevo modelo de coche, se incluyen desde el principio muchí-
simos elementos que ya existían y que, por tanto, no es necesario diseñar; no sólo
elementos normalizados como tornillos y tuercas, sino también elementos más com-
plejos como baterías e, incluso, motores o cajas de cambio completos. También en
la construcción de edificios –una actividad que tiene más semejanzas con la produc-
ción de software, como se ha indicado– se utilizan muchos elementos estándares o
prefabricados: tejas, vigas, ventanas, persianas, grifos, etc. 
Por tanto, no es extraño que uno de los grandes retos, por el momento, de
la ingeniería del software sea conseguir desarrollar fragmentos de software (de-
© Editorial UOC 19 Capítulo I. Introducción a la...
nominados componentes) que sean reutilizables, por un lado, y, por el otro, de-
sarrollar software y reutilizar sus fragmentos (que seguramente estarán mejor
probados que si se hicieran de nuevo, lo cual además mejoraría la calidad del
software producido). 
Una de las vías mediante las cuales se pretende conseguir una cierta reuti-
lización en el desarrollo orientado a objetos es especialmente con compo-
nentes; otras son los patrones de diseño (reutilización, si no de fragmentos
de software, por lo menos de ideas o “recetas” para hacerlos) y los marcos o
frameworks, que son estructuras formadas por sistemas de software a los cuales se
pueden acoplar otros sistemas de software, sustituibles, para hacer funciones
concretas.
2. El ciclo de vida del software
La producción de software es algo más que la programación; hay etapas que
la preceden y otras que la siguen.
El ciclo de vida del software está constituido por el conjunto de todas estas
etapas. Los métodos y técnicas de la ingeniería del software se inscriben dentro
del marco delimitado por el ciclo de vida del software, y, más concretamente, por
las diferentes etapas que se distinguen.
La misma existencia de distintos modelos del ciclo de vida del software hace
comprender que no hay ninguno que sea ideal o que no tenga grandes limita-
ciones.
Sin embargo, es indispensable que todo proyecto se desarrolle dentro del mar-
co de un ciclo de vida claramente definido, si se quiere tener una mínima garan-
tía de cumplimiento de los plazos, y respetar los límites de los recursos asignados.
Además, la garantía de calidad y las certificaciones* de calidad también presupo-
nen que el proceso de producción de software se desarrolle según un ciclo de vida
con etapas bien definidas. 
*. Un ejemplo de certificación de calidad sería la ISO.
© Editorial UOC 20 Ingeniería del software
2.1. El ciclo de vida clásico
La figura siguiente nos muestra las etapas previstas en una cierta versión del
ciclo de vida clásico.
A veces, el ciclo de vida clásico también se denomina ciclo de vida en cascada,
lo cual quiere decir que en cada etapa se obtienen unos documentos (en inglés,
deliverables) que son las bases de partida de la etapa siguiente –que, por tanto, no
puede comenzar antes de que haya terminado la anterior– y nunca se regresa a
etapas pasadas.
2.1.1. Etapas
La primera etapa se denomina análisis previo y también análisis de sistemas
o ingeniería de sistemas. En esta etapa se definen los grandes rasgos del sistema
de softwareque tendrá que dar soporte informático a unas actividades determi-
nadas de unos ciertos usuarios dentro del marco más general de la actividad de
la empresa u organización. 
© Editorial UOC 21 Capítulo I. Introducción a la...
Además, este sistema tendrá que funcionar en un entorno de hardware y red
determinado, que será necesario indicar, y quizá también tendrá que intercam-
biar información con otro software o compartir una base de datos. Estos hechos
constituyen otros aspectos del entorno del futuro software de los cuales se tendrá
que dejar constancia. 
Hay que tener en cuenta los recursos necesarios para el desarrollo del software
y los condicionamientos temporales, especialmente los plazos impuestos desde
fuera del proyecto, que a menudo están determinados por los hechos que han
causado las necesidades de información que tiene que satisfacer dicho software, y
también restricciones eventuales y condiciones adicionales que sea necesario res-
petar; y, en función de todo esto, se evalúa la viabilidad técnica, económica y le-
gal del proyecto de desarrollo de dicho software.
El documento que resulta de esta etapa se denomina Especificación del siste-
ma, y sirve de base para tomar la decisión definitiva sobre la continuación del
proyecto.
La segunda etapa es el análisis de requisitos o simplemente análisis. Su objeti-
vo es definir con detalle las necesidades de información que tendrá que resolver
el software, sin tener en cuenta, por el momento, los medios técnicos con los que
se tendrá que llevar a término el desarrollo del software.
Como el lenguaje de programación, el gestor de bases de datos, los compo-
nentes que se pueden reutilizar, etc.
En esta etapa detallamos los requisitos de la etapa anterior; ahora sólo pen-
samos en el software que es necesario desarrollar y sus interfaces con el entorno.
La figura responsable del análisis –el analista, que puede ser un informático o
un usuario– debe tener o adquirir conocimientos generales sobre el dominio de
la aplicación y obtener información de los usuarios y de otras fuentes que le per-
mita hacerse una idea precisa de las funciones, y de los requisitos en general, del
futuro software. Con esta información se redacta el documento que llamaremos
Especificación de requisitos, que tiene una doble función: especificar qué debe
hacer el software, con la suficiente precisión para que se pueda desarrollar, y servir
de base para un contrato, explícito o no, entre el equipo de desarrollo del software
y sus futuros usuarios.
El diseño es la etapa siguiente. Si el análisis especifica el problema o “qué tiene
que hacer el software”, el diseño especifica una solución a este problema o “cómo
el software tiene que hacer su función”. 
© Editorial UOC 22 Ingeniería del software
Del software, hay que diseñar varios aspectos diferenciados: su arquitectura
general, las estructuras de datos (base de datos, etc.), la especificación de cada
programa y las interfaces con el usuario, y se tiene que llevar a cabo de manera
que, a partir de todo esto, se pueda codificar el software, de una manera parecida
a la construcción de un edificio o de una máquina a partir de unos planos.
El documento resultante es la Especificación del diseño. La etapa de diseño es
el mejor momento para elaborar la Especificación de la prueba, que describe con
qué datos se tiene que probar cada programa o grupo de programas y cuáles son
los resultados esperados en cada caso.
La programación o codificación, que es la cuarta etapa, consiste en traducir
el diseño a código procesable por el ordenador.
Es en esta etapa donde se le da forma real al software, es en realidad cuando se
elabora.
El entregable que se genera en esta etapa es el programa propiamente, con to-
das sus funcionalidades y componentes.
La prueba es la última etapa del desarrollo del software y la penúltima del mo-
delo de ciclo de vida del software que hemos considerado.
La etapa de prueba consiste en probar el software desde distintos puntos de
vista de una manera planificada y, naturalmente, localizar y corregir dentro del
software y su documentación los errores que se detecten.
La prueba se lleva a término en las dos fases siguientes: 
1) En la primera se hacen pruebas, primero para cada uno de los programas
por separado y, después, por grupos de programas directamente relacionados, y
se aplica la especificación de la prueba que hemos mencionado con anterioridad. 
2) En la segunda fase se comprueba que el conjunto de programas dé los re-
sultados que se esperan y que lo haga con el rendimiento deseado. 
El primer equipo de desarrollo hace la última fase de la prueba y, si los resulta-
dos son satisfactorios, se entrega el software al cliente, el cual puede hacer una prue-
ba parecida por su cuenta y con sus datos, con la finalidad de decidir si acepta el
software. Con la aceptación por parte del cliente se da por terminado el desarrollo.
La última etapa del ciclo de vida es el mantenimiento o, si se prefiere, explo-
tación, del software, ya que siempre que se utilice el software habrá que mantener-
lo, es decir, hacer cambios –pequeños o grandes– para corregir errores, mejorar
© Editorial UOC 23 Capítulo I. Introducción a la...
las funciones o la eficiencia, o adaptarlo a un nuevo hardware o a cambios en las
necesidades de información.
Puesto que un software puede estar en explotación diez años o más, a menu-
do el coste total del mantenimiento durante la vida del software es de dos a cinco
veces mayor que el coste de desarrollo.
2.1.2. El caso de lenguajes de cuarta generación
Los lenguajes –o más bien entornos de programación– de cuarta generación
son de muy alto nivel (en el sentido de que a menudo una sola de sus instruccio-
nes equivale a muchas instrucciones del lenguaje ensamblador) y en gran parte
son no procedimentales y están integrados en un gestor de bases de datos rela-
cionales. Incluyen herramientas de dibujo de pantallas, generación de listados y
en ocasiones salidas gráficas y hoja de cálculo. Algunos pueden generar código en
un lenguaje de tercera generación. 
Para aplicaciones sencillas, se puede pasar directamente de los requisitos a la
codificación, pero en proyectos complejos es necesario llevar a cabo una etapa de
diseño, aunque simplificada.
2.2. Los ciclos de vida iterativos e incrementales
El ciclo de vida en cascada ha sido muy criticado y se han propuesto algunos
modelos alternativos.
2.2.1. Inconvenientes del modelo de ciclo de vida en cascada
El inconveniente del modelo de ciclo de vida en cascada es que no es realista.
Como se ha visto, el modelo de ciclo de vida en cascada comporta que las
sucesivas etapas del desarrollo se hacen de manera lineal, de forma que una fase
no comienza mientras no se haya acabado la anterior, y no se vuelve nunca atrás.
También queda implícito en el modelo que, cuando se acaba una fase, se sabe
al menos aproximadamente qué porcentaje del proyecto queda por hacer, ya que
© Editorial UOC 24 Ingeniería del software
si el análisis se ha completado y su resultado es cien por cien fijo, se puede saber
con cierta precisión la duración del diseño e, incluso, de la programación.
Ahora bien, en la realidad es posible que la especificación del sistema sea fia-
ble en lo que respecta a las funciones, ya que no se espera que se describan pun-
to por punto. Sin embargo, precisamente por esto último, el coste y la duración
del proyecto se han calculado sobre una base muy poco sólida y tienen un gran
margen de error.
No obstante, el problema más grave se presenta en el análisis de requisitos,
por el hecho de que éstos casi siempre son incompletos al principio o cambian
antes de que se haya acabado de construir el software, y a menudo suceden ambas
cosas a la vez. Y si la especificación de requisitos es incompleta e insegura, es
obvio que el diseño y la programación tendrán problemas y, sobre todo, retra-
sos y aumentos de coste importantes para el trabajo no previstoque se deberá
hacer y también para el que será necesario rehacer.
Existen dos razones por las cuales es prácticamente imposible elaborar unos
requisitos completos y estables en el primer intento:
a) En primer lugar, es difícil encontrar un conjunto de futuros usuarios que
conozcan lo suficiente el entorno en el que se debe utilizar el software, que hayan
reflexionado lo suficiente sobre lo que quieren conseguir y que, además, se pon-
gan de acuerdo.
b) En segundo lugar, porque el trabajo de consolidación de las peticiones de
estos usuarios nunca será perfecto.
En cualquier caso, tenemos que contar con el hecho de que, una vez termina-
da oficialmente la etapa de análisis y comenzada la de diseño, todavía surgirán re-
quisitos nuevos y cambios en los ya existentes.
¿Qué se puede hacer, entonces? Parece que la opción más razonable sea es-
tudiar a fondo una pequeña parte de los requisitos que tenga una cierta autono-
mía, y diseñarla, programarla y probarla, y una vez que el cliente la haya dado
por buena, hacer lo mismo con otra parte, y otra. Si partimos de un software ya
construido en parte, se puede esperar que la idea que nos hacemos de los requi-
sitos restantes pueda ser cada vez más precisa y que también obtengamos una
estimación cada vez más segura del coste y de la duración del proyecto comple-
to; esto es lo que denominamos ciclo de vida iterativo e incremental (iterativo por-
© Editorial UOC 25 Capítulo I. Introducción a la...
que se repite dentro de un mismo proyecto e incremental porque procede por
partes). Y se tendrá que considerar normal que, a veces, cuando se construya
una parte, se vea que es necesario modificar una hecha con anterioridad.
La necesidad de estimar el coste y los plazos
Los inconvenientes del modelo del ciclo de vida clásico mencionados en este subapar-
tado no quieren decir que no pueda haber plazo o límite de coste para un proyecto de
desarrollo de software; simplemente, se debe reconocer que no es realista creer que se
pueda fijar de forma exacta la funcionalidad, el coste y la duración del proyecto, todo
a la vez. Si el software tiene que funcionar en una fecha determinada y no se puede au-
mentar el gasto en personal, será necesario estar dispuesto a aceptar que el software no
realice todas las funciones deseadas; si la funcionalidad y la fecha de entrega del pro-
grama son innegociables, se tendrá que aumentar el número de programadores o ana-
listas. Y esto no supone ninguna renuncia en relación con los resultados que se
alcanzaban hasta ahora, porque en la práctica muy pocos eran los proyectos en los que
no se producían desviaciones en cuanto a la funcionalidad, presupuesto o plazo, sino
en varias de estas cosas al mismo tiempo.
Por tanto, el modelo de ciclo de vida en cascada puede ser válido si se aplica de
manera que cada etapa, del análisis de requisitos a la prueba, no prevea todo el
conjunto del software, sino sólo una parte cada vez; entonces tendríamos un ciclo
de vida iterativo e incremental basado en el ciclo de vida en cascada.
2.2.2. El ciclo de vida con prototipos
Para ayudar a concretar los requisitos, se puede recurrir a construir un proto-
tipo del software.
Un prototipo es un software provisional, construido con herramientas y téc-
nicas que dan prioridad a la rapidez y a la facilidad de modificación antes que a
la eficiencia en el funcionamiento, que sólo tiene que servir para que los usua-
rios puedan ver cómo sería el contenido o la apariencia de los resultados de al-
gunas de las funciones del futuro software.
Un prototipo sirve para que los usuarios puedan confirmar que lo que se les
muestra, efectivamente, es lo que necesitan o bien lo puedan pedir por compa-
ración, y entonces se prepara una nueva versión del prototipo teniendo en cuen-
© Editorial UOC 26 Ingeniería del software
ta las indicaciones de los usuarios y se les enseña otra vez. En el momento en que
el prototipo ha permitido concretar y confirmar los requisitos, se puede comen-
zar un desarrollo según el ciclo de vida en cascada, en este caso, no obstante, par-
tiendo de una base mucho más sólida. 
Características del ciclo de vida con prototipos
El ciclo de vida con prototipos no se puede considerar plenamente un ciclo de vida
iterativo e incremental, ya que sólo el prototipo se elabora de manera iterativa, y no
necesariamente incremental. Sin embargo, es un modelo de ciclo de vida que puede
ser adecuado en algunos casos, en especial cuando basta con prototipar un número
reducido de funciones para que las otras sean bastante parecidas a éstas de forma que
las conclusiones a las que se llegue con el prototipo también les sean aplicables.
2.2.3. La programación exploratoria
La programación exploratoria consiste en elaborar una primera versión del
software, o de una parte de éste, enseñarla a los usuarios para que la critiquen y,
a continuación, hacerle los cambios que éstos sugieran, proceso que se repetirá
tantas veces como sea necesario.
La diferencia principal con respecto a los prototipos es que aquí el software
es real desde el principio. 
Características de la programación exploratoria
La programación exploratoria se puede considerar un ciclo de vida iterativo, pero no in-
cremental, ya que el software está completo desde la primera versión. Como consecuencia
de las numerosas modificaciones que sufre, la calidad del software desarrollado de esta
manera y de su documentación tiende a ser deficiente, como la de un software que haya
experimentado un mantenimiento largo e intenso.
2.2.4. El ciclo de vida del Rational Unified Process
La empresa Rational Software ha propuesto este ciclo de vida como marco
para el desarrollo de software que utiliza sus herramientas. Es claramente un ci-
clo de vida iterativo e incremental.
© Editorial UOC 27 Capítulo I. Introducción a la...
Se distinguen estas cuatro etapas (denominadas fases):
1) Inicio
Se establece la justificación económica del software y se delimita el alcance del
proyecto.
2) Elaboración
Se estudia el dominio del problema, o simplemente dominio (parte de la ac-
tividad de la empresa dentro de la cual se utilizará el software) y se tienen en
cuenta muchas de las necesidades de información y eventuales requisitos no
funcionales y restricciones, se establece la arquitectura general del software y se
realiza una planificación del proyecto.
3) Construcción
Se desarrolla todo el producto de forma iterativa e incremental, se tienen en
cuenta todas las necesidades de información que debe satisfacer y se desarrolla
la arquitectura obtenida en la fase anterior.
4) Transición
Comprende la entrega del producto al cliente y el comienzo de su utiliza-
ción; aunque es posible que sea necesario hacer retoques en el software y añadir
nuevas funciones como consecuencia de errores detectados o de requisitos que
se habían pasado por alto hasta el momento. 
En cada una de estas fases se llevan a cabo (en diferentes proporciones) los
siguientes componentes de proceso:
• recogida de requisitos (requirement capture),
• análisis y diseño,
• realización (implementation),
• prueba (test ).
Cada unidad en la que se ejecutan pocos o muchos de los componentes de
proceso es una iteración, y se aplica a un nuevo fragmento de software. Todas las
fases tienen iteraciones. 
© Editorial UOC 28 Ingeniería del software
3. Desarrollo estructurado y desarrollo orientado a objetos
Los métodos de desarrollo de software más utilizados hasta ahora pertenecen a
dos grandes grupos: los métodos estructurados y los métodos orientados a objetos.
3.1. Los métodos estructurados
Los métodos estructurados provienen de la programación estructurada y se
utilizan técnicas no muy integradas entre sí.
Los métodos estructurados tienen, asimismo, estas características:
• La especificación de los procesos y la de las estructuras de datos generalmen-
te quedan bastante diferenciadas, y hay métodos que ponen más énfasis en
aquéllos o en éstos.
• Muchas de sus técnicas obien pasan de lo general a lo particular (técnicas top-
down) o bien a la inversa (técnicas bottom-up).
Técnicas más utilizadas para los métodos estructurados
Las técnicas más usadas en los métodos estructurados son seguramente los diagramas
de entidad-relación y de flujo de datos, con sus variantes. Los primeros se refieren a
los datos y los segundos, a los procesos.
3.2. Los métodos orientados a objetos
Si bien los métodos estructurados continúan siendo muy utilizados, los de-
nominados métodos orientados a objetos ganan terreno rápidamente.
Si los métodos estructurados de desarrollo de software tienen su origen en la pro-
gramación estructurada, los métodos orientados a objetos tienen sus raíces en la
programación orientada a objetos.
Es lógico que haya sucedido así en los dos casos: una nueva técnica de pro-
gramar exige una nueva manera de diseñar los programas adaptada a las carac-
© Editorial UOC 29 Capítulo I. Introducción a la...
terísticas de la programación, y un nuevo método de diseño hace deseable un
nuevo método de análisis de requisitos que tenga la misma orientación que el
diseño, con la finalidad de evitar que el paso del análisis de requisitos al diseño
implique un cambio de modelo que inevitablemente comportaría un trabajo
adicional y un mayor riesgo de errores.
De la misma manera que la programación orientada a objetos gira en torno
al concepto de clase, también lo hacen el análisis de requisitos y el diseño. Por
esta razón, el diagrama básico de estos métodos, el diagrama de clases y objetos,
se utiliza tanto en el análisis como en el diseño; además, muchas de las clases
descritas en el análisis de requisitos se implementan en los programas pasando
por el diseño, lo cual hace que el paso del análisis de requisitos al diseño sea más
suave que en los métodos estructurados y también más sencillo y rápido.
Puesto que dentro de una clase hay a la vez atributos y operaciones, es decir,
datos y procesos, en el desarrollo orientado a objetos a medida que se definen e
implementan clases se avanza al mismo tiempo en estas dos dimensiones. El de-
sarrollo no procede ni de manera top-down ni bottom-up, sino que, más bien, se
construyen grupos de clases interrelacionadas, a menudo por niveles: clases que
gestionan la presentación de la información, o bien las entradas por pantalla, o
bien las lecturas y grabaciones de la base de datos, o bien los algoritmos princi-
pales del software; o bien proceden según un ciclo de vida incremental, tal como
hemos visto. 
Cabe añadir que el desarrollo orientado a objetos, además de introducir téc-
nicas nuevas, también aprovecha algunas técnicas y conceptos del desarrollo es-
tructurado, como el diagrama de estados y transiciones, según veremos. 
Hay dos características del desarrollo orientado a objetos que probablemente
han favorecido de manera decisiva su expansión hasta ahora y también con toda
probabilidad la continuarán favoreciendo:
• Parece que permite –por primera vez en la historia de la tecnología del soft-
ware– la reutilización de software en un grado significativo, en forma de cla-
ses implementadas, lo cual podría significar una vía para solucionar, aunque
sólo sea en parte, los problemas de productividad y calidad descritos en apar-
tados anteriores.
• Su relativa simplicidad facilita el desarrollo de herramientas informáticas de
ayuda al desarrollo; este factor podría ser potenciado por el hecho de que en
© Editorial UOC 30 Ingeniería del software
estos últimos años ha aparecido una notación orientada a objetos muy am-
pliamente aceptada, el UML.
3.3. Los métodos formales
Los denominados métodos formales parten de una especificación de las nece-
sidades de información en términos de un modelo matemático riguroso, del cual
se podría deducir el programa que les satisfaga. También permitían demostrar ma-
temáticamente que un programa es correcto en el sentido de que se ajusta a aque-
llas necesidades.
Aunque tendrían que permitir eliminar las ambigüedades y carencias de los
métodos no tan rigurosos, su utilización directa en el desarrollo de software para
usos reales es poco frecuente en la actualidad, sin duda debido a la gran com-
plejidad que tendría un modelado tan detallado y formalizado en casos reales. 
Algunos de los lenguajes de especificación formal más conocidos son Z,
VDM, CSP y LARCH.
4. Las herramientas CASE
CASE significa Computer-Aided Software Engineering. Las herramientas CASE son
software de apoyo al desarrollo, mantenimiento y documentación informatizados
de software.
De esta definición generalmente se excluyen las herramientas que tienen
una de las funciones siguientes:
1) o bien no tienen sólo esta finalidad (herramientas de tratamiento de tex-
to, de hoja de cálculo, de dibujo en general, de planificación de proyectos de
cualquier ingeniería), ya que propiamente pertenecen a otros ámbitos;
2) o bien se utilizan para codificar el software (compiladores, entornos de
cuarta generación, editores ordinarios de programas, etc.), ya que siempre están
presentes, incluso cuando el desarrollo de software se hace de la manera más ma-
nual posible.
© Editorial UOC 31 Capítulo I. Introducción a la...
Quedan, pues, principalmente las herramientas que ayudan a aplicar técnicas
concretas de desarrollo y mantenimiento de software y por eso gestionan informa-
ción sobre los elementos y conceptos que se utilizan en los métodos de desarrollo,
como las siguientes:
• Las herramientas diagramáticas, las cuales, a diferencia de las de dibujo, re-
conocen que un determinado símbolo es una clase y no simplemente un rec-
tángulo. Estas herramientas también acostumbran a aceptar documentación
textual sobre aquellos elementos.
• Las herramientas de gestión de la prueba y de gestión de la calidad en general.
• Las herramientas de gestión de cambios, etc. 
Herramientas UpperCASE y LowerCASE
A veces se distingue entre herramientas UpperCASE, que son las de análisis y diseño, y
LowerCASE, que se usan durante la programación y la prueba.
La importancia de la integración de las herramientas
Es conveniente que las herramientas que dan apoyo a diferentes técnicas utilizadas
dentro del mismo método estén integradas, en el sentido de que si hay un tipo de ele-
mento que es común a dos técnicas, sea compartido por las dos herramientas respec-
tivas, de manera que sólo sea necesario describirlo una vez y que todos los cambios
que se realicen después en esta descripción lleguen a las dos.
La expansión del uso de herramientas CASE en el método estructurado se fre-
nó a causa de la diversidad y de la falta de estandarización de las técnicas que se
utilizan; en los métodos orientados a objetos, en cambio, actualmente la situa-
ción es la contraria: por un lado, algunos diagramas sirven tanto para el análisis
como para el diseño, y por el otro, se ha producido una estandarización de las
técnicas y notaciones en el modelo conocido como UML que ha hecho que en
el poco tiempo transcurrido desde su publicación haya aparecido un número
importante de conjuntos integrados de herramientas CASE basadas en él. Este
soporte informatizado, amplio y creciente, en el desarrollo de software orientado
a objetos sin duda reforzará la mejora de la calidad y la productividad en el de-
© Editorial UOC 32 Ingeniería del software
sarrollo de software que, tal como hemos visto, la tecnología orientada a objetos
tiene que fomentar.
5. El OMG y el UML
Para el desarrollo orientado a objetos utilizaremos el modelo denominado
UML, del cual actualmente es responsable la organización llamada OMG.
5.1. El Object Management Group (OMG)
El Object Management Group (OMG), creado en 1989, es una organización no
lucrativa en la cual participan más de ochocientas grandes empresas de software,
de hardware, usuarias y consultoras, y tiene la finalidad de fomentar el uso de la
tecnología de objetos e impulsar la introducción de software orientado a objetos
que ofrezca reusabilidad,portabilidad e interoperabilidad en entornos distribui-
dos heterogéneos. 
El medio con que el OMG intenta conseguir sus objetivos es la elaboración de
estándares, para los cuales acepta propuestas. En cambio, no produce software ni
elabora especificaciones de implementación o funcionalidad.
El otro estándar del OMG
Además del UML, otro estándar que ha elaborado el OMG es CORBA, sobre objetos dis-
tribuidos, cuyas implementaciones tienen una expansión rápida.
5.2. Unified Modeling Language (UML)
El Unified Modeling Language (UML) es un modelo para la construcción de
software orientado a objetos que ha sido propuesto como estándar de ISO por el
© Editorial UOC 33 Capítulo I. Introducción a la...
OMG. Consta de un conjunto de tipos de diagramas interrelacionados, dentro
de los cuales se utilizan elementos del modelo, que sirven parar describir distin-
tos aspectos de la estructura y la dinámica del software.
UML es el resultado de una cierta unificación de los modelos utilizados en
tres métodos preexistentes de desarrollo de software orientado a objetos hechos
por sus autores en colaboración. Estos métodos son los siguientes:
• el método de Grady Booch;
• el OMT, de Jim Rumbaugh y otros;
• el OOSE, de Ivar Jacobson.
Además, se encuentran conceptos aportados por muchos otros autores, en-
tre ellos Peter Coad, Edward Yourdon, James Odell y Bertrand Meyer.
Evolución del modelo UML
Los primeros pasos hacia el modelo unificado se dieron en el año 1994, cuando Booch
y Rumbaugh, trabajando en Rational Software Corporation, comenzaron la unificación
de los modelos respectivos, y en octubre de 1995 se publicó la versión provisional 0.8
del entonces denominado Unified Method.
El mismo año, Jacobson se incorporó con su empresa al equipo mencionado y a Ra-
tional y, como resultado del trabajo de los tres autores, en 1996 salieron las versiones
0.9 y 0.91 del UML. El OMG emitió en aquella época una Request For Proposal, para
un modelo de este tipo, y entonces Rational, para responderle, constituyó un consor-
cio con otras organizaciones, con el resultado de que en enero de 1997 se presentó en
la OMG la versión 1.0 del UML.
Otras empresas que habían presentado también respuestas de manera independiente
se añadieron al consorcio y se publicó la versión 1.1, que fue aceptada por el OMG en
noviembre de 1997 (hubo otra propuesta, la del modelo OML, que tenía y todavía tie-
ne un número importante de partidarios). El OMG encargó una revisión, cuyo resul-
tado fue una versión 1.2, no publicada, y la versión 1.3, ya publicada como estándar.
La versión 1.4 se publicó oficialmente en septiembre de 2001.
Con el UML se ha llegado a un modelo orientado a objetos único como mo-
delo oficial, pero eso no quiere decir que se haya alcanzado un método único
de desarrollo orientado a objetos; la verdad es que por el momento parece que
falta bastante para llegar al mismo, si es que alguna vez se consigue. Es decir,que
© Editorial UOC 34 Ingeniería del software
lo que se ha conseguido es que haya unos diagramas que todos los desarrollado-
res de software orientado a objetos entenderán y harán de la misma manera, lo
cual supone un adelanto realmente importante con respecto a la situación an-
terior en la que cada método tenía su notación gráfica; pero, incluso así, conti-
núa siendo posible que existan métodos diferentes que utilicen el UML y que,
por ejemplo, se valgan de los mismos diagramas en orden diferente o dentro de
modelos de ciclo de vida distintos.
© Editorial UOC 35 Capítulo I. Introducción a la...
Conclusiones
Se ha concretado qué se entiende por software en esta obra, se ha indicado por
qué se puede considerar un producto industrial y, como consecuencia, por qué
tiene sentido hablar de una ingeniería del software, y también hemos entrado en
contacto con los dos grandes problemas que han afectado tradicionalmente al
desarrollo de software: las carencias referidas a la productividad y calidad.
Si entramos dentro del proceso de elaboración del software, hemos visto el
concepto de ciclo de vida y sus dos grandes modelos –el ciclo de vida en cascada
o clásico y los ciclos de vida iterativos e incrementales–, más dos modalidades in-
termedias –el desarrollo con prototipos y la programación exploratoria. Como
ciclos concretos, hemos indicado de una manera más o menos detallada el ciclo
de vida del Rational Unified Process, como representante de las tendencias ac-
tuales en lo que se refiere a ciclos iterativos e incrementales, y el ciclo de vida clá-
sico, cuyo interés radica, además de en su importancia histórica, en el hecho de
que algunos de sus conceptos continúan siendo válidos todavía.
A continuación, se han presentado las tres grandes familias de métodos de
desarrollo de software: las dos más utilizadas en entornos reales, que son los mé-
todos estructurados –más tradicionales– y los métodos orientados a objetos –en
plena expansión–, sin menospreciar los métodos formales, interesantes por su
gran rigor teórico.
Después de hablar de técnicas, es lógico referirse a las herramientas que éstas
emplean; por eso hemos visto el concepto de herramientas CASE y nos hemos
informado de su situación actual y de la evolución previsible de su papel.
Puesto que para estudiar el análisis y diseño orientados a objetos –tema esen-
cial de esta obra– utilizaremos los conceptos y la notación del UML, se ha expues-
to el origen de este modelo y el cometido de la organización que se responsabiliza
del mismo, la OMG.
© Editorial UOC 37 Capítulo II. UML (I): el modelo estático
Capítulo II
UML (I): el modelo estático
Como sabemos, para el análisis y el diseño orientados a objetos utilizaremos
los conceptos y las notaciones –esencialmente gráficas– del UML. 
El UML comprende un cierto número de diagramas interrelacionados me-
diante conceptos comunes. Sólo para describirlos, los consideraremos agrupa-
dos en tres modelos:
En este capítulo veremos el modelo estático, que consta, por una parte, de clases
y objetos, y por la otra, de relaciones de diferentes tipos entre clases y entre objetos.
En capítulos posteriores trataremos el resto de los modelos y la utilización
del UML en el análisis y en el diseño.
1. Concepto de modelo estático y diagrama de clases
El modelo estático del UML es aquél en el que se describen las clases y los
objetos. Se denomina estático porque muestra todas las relaciones posibles a lo
largo del tiempo, no las que son válidas en un cierto momento.
Estático describe la estructura de clases y objetos.
Dinámico (o modelo de comportamiento), describe las interacciones entre los objetos dentro del software.
Implementación describe la estructura del software en cuanto a los componentes de que consta y su ubicación.
© Editorial UOC 38 Ingeniería del software
Ejemplo de modelo estático
Un diagrama estático nos puede mostrar que cada profesor tiene, al menos, una asigna-
tura, y que cada asignatura tiene, al menos, un profesor, pero no nos dice qué asig-
naturas tiene un profesor concreto.
Este modelo consta de los dos diagramas siguientes:
• Diagrama de clases, que puede contener clases y objetos y relaciones entre és-
tos, y que se hace siempre.
• Diagrama de objetos, que sólo contiene objetos y relaciones entre éstos, y que
es opcional, ya que se utiliza principalmente para realizar ejemplos del diagra-
ma de clases con objetos concretos de las mismas.
Un diagrama de clases muestra la estructura estática de las clases en un do-
minio (porción del mundo real considerada por una aplicación); se muestran las
clases y las relaciones entre éstas, que pueden ser de herencia, asociación, agre-
gación o uso.
Uso del modelo estático
El modelo estático se utiliza en todas las etapas del ciclo de vida; en las diferentes etapas
se documentan diferentes tipos de objetos. En el análisis se consideran objetos del mun-
do del usuario (por ejemplo, artículos, facturas, clientes, etc.) y en el diseño, en cambio,
se consideran objetosde la tecnología informática: pantallas, gestores de disco, etc.
El modelo estático pretende ser independiente del lenguaje de programa-
ción, pero, sin embargo, si se sabe cuál será, es conveniente no utilizarlo en
el análisis de conceptos que sabemos que dicho lenguaje no soporta, si que-
remos ahorrarnos muchos cambios cuando lleguemos al diseño. También se
deberá tener en cuenta que, cuando el UML permite describir elementos in-
compatibles con un lenguaje determinado, raramente la herramienta CASE
nos lo impedirá; por lo tanto, será responsabilidad del diseñador del software
evitar caer en la utilización de conceptos no soportados por el lenguaje de
programación.
© Editorial UOC 39 Capítulo II. UML (I): el modelo estático
Relaciones en los lenguajes de programación
Los lenguajes de programación soportan las relaciones de herencia, pero no distin-
guen entre los otros tres tipos de relaciones que existen; por tanto, al pasar del diseño
a la programación, estos tipos se tendrán que transformar.
También puede suceder lo contrario; es decir, que se quieran modelar ele-
mentos que la herramienta CASE no soporta, porque UML no los prevé, o por
otros motivos; entonces se tendrán que documentar estos aspectos mediante
comentarios libres, que permiten todas las herramientas. Algunas herramientas
permiten que el usuario defina extensiones, pero si una empresa utiliza esta po-
sibilidad, los diagramas generados no serán transportables a otras empresas.
2. Clasificadores
El clasificador es la entidad básica del modelo estático. Un clasificador es
más general que una clase; es un conjunto cuyos elementos se denominan ins-
tancias.
El clasificador en sí mismo no tiene símbolo gráfico, sino que lo tienen sus
estereotipos:
• Clase: El concepto de clase es el que ya conocemos de la programación orien-
tada a objetos, y sus instancias son los objetos, que tienen identidad, en el
sentido de que incluso dos objetos que coinciden en el valor de todos sus atri-
butos son objetos diferentes si se han creado como tales.
• Tipo de dato: Por tipo de dato entendemos un tipo base ofrecido por algún
lenguaje de programación o construido por el programador; tiene operacio-
nes asociadas igual que las clases, pero sus instancias, a diferencia de los ob-
jetos, no tienen identidad.
• Interfaz: Una interfaz sólo describe las operaciones de una clase que son visi-
bles desde otras clases; se dice que dicha clase implementa la interfaz corres-
pondiente.
© Editorial UOC 40 Ingeniería del software
Estereotipo
Un estereotipo de un elemento del UML es una variante más restrictiva de dicho ele-
mento; hay estereotipos que forman parte del UML, y también se pueden encontrar
estereotipos definidos referidos al diagrama, que son un instrumento para extender
el UML, pero así se pierde portabilidad.
La utilidad del concepto de clasificador radica en el hecho de que los estereo-
tipos mencionados tienen mucho en común, por lo que es suficiente con reali-
zar la indicación una vez en el clasificador. La notación gráfica simplificada es
la misma para los tres: un rectángulo.
Todos los clasificadores deben tener un nombre. En un clasificador se puede
indicar la palabra clave del estereotipo (entre comillas latinas, «»). Cuando no
se indique ningún estereotipo, se tratará de una clase. 
3. Paquetes
Un paquete o package es sólo una “caja” que contiene elementos, como cla-
sificadores, objetos u otros paquetes, así como otras entidades que veremos más
adelante, como los casos de uso. 
Paquetes en JAVA
Por la definición que ofrecemos de paquete, podemos ver que el concepto de paquete
en el UML es diferente –y más amplio– que en Java.
© Editorial UOC 41 Capítulo II. UML (I): el modelo estático
Gráficamente, un paquete se representa así:
Todas las aplicaciones deben tener, por lo menos, un paquete que normal-
mente se denomina raíz. Cada elemento de un paquete tiene visibilidad, es decir,
puede ser reconocido o bien desde todos los otros paquetes, o bien sólo desde al-
gunos.
Ejemplo de paquetes
Éstas son dos maneras de representar el mismo paquete:
En la primera, se pueden incluir dentro del símbolo del paquete los símbolos de los
elementos que contiene; la segunda, simplificada, es más adecuada para representar
referencias al paquete (desde otros paquetes, por ejemplo).
Se pueden establecer los siguientes tipos de relaciones entre paquetes:
• De especialización. Si un paquete A hereda de otro B todos los elementos de B,
son casos más restrictivos de elementos de A.
• De inclusión. Si el paquete A incluye el B, todos los elementos de B están
también en A.
© Editorial UOC 42 Ingeniería del software
• De importación. Desde el paquete que importa se reconocen los nombres de
los elementos del otro paquete visibles desde el exterior. 
Ejemplo
Por ejemplo, públicos en el sentido de Java.
• De acceso. No sólo se reconocen los nombres de los elementos, sino que, ade-
más, se pueden utilizar. 
Ejemplo de relaciones entre paquetes
En la representación gráfica, el paquete Diagramas que vemos a continuación importa
del paquete Figuras, y el paquete Diagramas de UML hereda del paquete Diagramas;
una relación de acceso se representaría con la palabra clave access.
© Editorial UOC 43 Capítulo II. UML (I): el modelo estático
4. Clase y conceptos afines
Sobre la programación orientada a objetos sabemos que una clase describe
un conjunto de objetos en el cual todos tienen los mismos atributos y las mis-
mas operaciones. Los atributos y operaciones pueden ser de instancia, es decir,
vinculados a objetos individuales, y de clase, que no están relacionados con
ningún objeto en particular de la clase. Este mismo es el concepto de clase en
el UML.
En principio, cada clase es visible (es decir, reconocida) dentro del paquete
donde se ha declarado, y su nombre no puede estar repetido en éste, pero desde
un paquete se reconocen los nombres de clases –y elementos en general– de
otro paquete del que se importa, en el sentido indicado con anterioridad; el
nombre de la clase tiene que estar calificado por el del paquete, así Paquete :
Clase.
4.1. Representación ampliada de las clases
Puesto que una clase es un clasificador, se puede utilizar como símbolo de la
clase un simple rectángulo con el nombre. Sin embargo, dado que una clase con-
siste en un encapsulado de unos atributos y unas operaciones, también se da una
representación gráfica más detallada por medio de un rectángulo dividido en los
tres compartimentos siguientes:
• El primer compartimento contiene el nombre de la clase.
• El segundo compartimento contiene la lista de los atributos.
• El tercer compartimento corresponde a los servicios de la clase.
Se ha de tener en cuenta que como sinónimos de operación se utilizan a menudo mé-
todo y servicio; pero en UML, el término servicio no se usa, y por método se entiende
la implementación de una operación.
El usuario puede crear otros compartimentos, además de los tres obligatorios,
para dar información adicional como excepciones, requisitos, etc.
© Editorial UOC 44 Ingeniería del software
4.1.1. El compartimento del nombre
En la parte superior del compartimento de la clase se puede indicar un este-
reotipo.
Algunos estereotipos forman parte del UML –como metaclass, del que se ha-
blará más adelante–, y se pueden definir mediante un proyecto concreto, por
ejemplo.
Justo debajo se encuentra el nombre de la clase. Se recomienda que sea un
sustantivo en singular que a veces puede tener una segunda palabra que la cali-
fique.
También es recomendable que comience por mayúscula.
Debajo del nombre se pueden encontrar comentarios optativos entre llaves
({}) denominados cadenas de caracteres de propiedades (property strings) o valores
etiquetados (tagged values)*; los puntos suspensivos que se pueden hallar al final
de uno de los apartados indican que hay más elementos, pero que no se ven. La
property string “abstract” denota una clase abstracta.
Elnombre de clases
Los nombres de las clases tienen que estar bien pensados. La posibilidad de reuti-
lización depende en gran medida de ello, porque cuando queramos reutilizar una
clase de una librería que tenga centenares de nombres, la única pista que tendre-
mos es el nombre, y si no se le dio un nombre adecuado, será muy difícil de en-
contrar.
Un atributo de clase es lo mismo que un atributo static de Java y una variable de clase de
Smalltalk y C++.
Ejemplo de clase sólo con el compartimento del nombre
En la figura siguiente, el estereotipo análisis podría indicar que la clase Rectangulo se
ha identificado en la etapa de análisis.
*. Formato de los comentarios
Property strings y tagged values tienen la forma nombre = valor; en el caso de propiedades booleanas,
el nombre solo ya indica la presencia de la propiedad.
© Editorial UOC 45 Capítulo II. UML (I): el modelo estático
4.1.2. Especificación de los atributos
Cada atributo tiene un nombre o identificador y un tipo. Este último puede
ser un tipo simple del lenguaje de programación (por lo menos, durante el di-
seño y la programación, porque durante el análisis puede ser que las clases se
describan sin pensar en ningún lenguaje de programación en concreto) como
entero o carácter, o bien un tipo complejo, como una lista de enteros, o tam-
bién una clase ya definida.
Un atributo, sea de instancia o de clase, se define de la siguiente forma:
visibilidad nombre ‘:’ expresión-de-tipo ?=’ valor-inicial ‘{’ property string ‘}’
Se indica que un atributo es atributo de clase* subrayando su definición. 
La visibilidad de un atributo** indica hasta qué punto las operaciones de
otras clases pueden acceder al atributo, y se indica mediante los siguientes sím-
bolos.
• Público: “+”
• Protegido: “#”
• Privado: “-”
• Dentro del paquete: “ ”
También tienen visibilidad otros elementos del modelo estático, como las
operaciones y los extremos de asociación.
*. Atributo de clase. Un atributo de clase es lo mismo que un atributo static de Java y una variable
de clase de Smalltalk y C++.
**. La visibilidad. En el UML no hay definiciones del significado de estas opciones de visibilidad,
sino que se dejan para los lenguajes de programación; si algún lenguaje incluye más tipos de visibi-
lidad, también se podrán indicar aquí.
© Editorial UOC 46 Ingeniería del software
En el lugar de los atributos, se pueden utilizar property strings, que son, respec-
tivamente, public, protected o private. Las property strings son opcionales; además
de las mencionadas, podemos encontrar frozen, que indica que no se puede cam-
biar el valor del atributo.
En lo referente al nombre de los atributos, se deben tener en cuenta las siguien-
tes pautas:
• Se recomienda que comience por minúscula.
• Cuando se trate de un atributo derivado (es decir, que es redundante con
otros a partir de los cuales se puede obtener el valor), el nombre tiene que ir
precedido de “/”.
• Es conveniente que el nombre cumpla las reglas léxicas del lenguaje de pro-
gramación, si no queremos que se tenga que cambiar al llegar al diseño. La
expresión de tipo y el valor inicial también las deberán respetar.
Se pueden utilizar indicadores de multiplicidad como en el caso de los vectores
o matrices de acuerdo con el lenguaje. 
Uso de los indicadores de multiplicidad
Consideremos:
hijos [0..3]: persona o bien, hijos [3]: persona; en el primer caso podría haber entre 0 y
3 hijos, pero en el segundo tiene que haber exactamente tres.
Ejemplo de clase con compartimento de nombre y compartimento 
de atributos
Como se puede ver en la figura siguiente:
© Editorial UOC 47 Capítulo II. UML (I): el modelo estático
extremos serían las coordenadas de dos vértices opuestos del rectángulo, que lo determi-
nan; Punto sería una clase descrita en el mismo paquete; gruesoLínea tiene el valor 1 por
omisión, y área es un atributo derivado, ya que su valor se puede calcular a partir de las
coordenadas de los puntos de extremos.
4.1.3. Especificación de las operaciones
Una operación se define de la siguiente forma:
visibilidad nombre ‘(’ lista-de-parámetros ‘):’ tipo-de-retorno ‘{’property string‘}’
Se indica que una operación es operación de clase subrayando su definición.
La visibilidad se señala igual que en el caso de los atributos. 
Conviene que el nombre de la operación y de los parámetros y el tipo de los
parámetros y del retorno cumplan las reglas del lenguaje de programación.
En la programación conviene que los nombres de las operaciones estén bien pensa-
dos, porque son la base del polimorfismo, en el que se aplica que “a igual concepto,
igual nombre”.
Se recomienda que los nombres de las operaciones comiencen por minúscula.
La lista de parámetros se compone de parámetros separados por comas; la sin-
taxis de cada uno es la siguiente:
tipo nombre ‘:’ expresión-de-tipo ‘=’ valor-por-omisión
Donde tipo es in, out o inout (por omisión, in), y nombre es el nombre del pa-
rámetro formal; expresión-de-tipo depende del lenguaje; valor-por-omisión depen-
de del lenguaje y es opcional.
El tipo-de-retorno sólo se tiene que utilizar cuando la operación devuelva un
valor como resultado, y también se puede usar un parámetro out en su lugar.
Opcionalmente, puede aparecer property strings: query, que denota que la ope-
ración no modifica el estado del sistema, y para especificar la semántica de concu-
rrencia se pueden utilizar una de éstas: sequential, guarded o concurrent, y abstract,
que indica que la operación es abstracta.
Se pueden utilizar estereotipos poniéndolos encima de la operación afectada.
© Editorial UOC 48 Ingeniería del software
Ejemplo de clase con los tres compartimentos
Tal y como se puede apreciar en el gráfico siguiente, la operación nuevoRectangulo es del
estereotipo (no incluido dentro del UML) constructor y tiene dos parámetros in (por
omisión); la operación calculoArea no tiene parámetros pero retorna un valor, cuyo tipo
se indica. 
4.2. La herencia en el análisis y el diseño
Sabemos que la herencia presupone que existan dos clases, de las cuales una
desempeña el papel de superclase y la otra, el de subclase.
Se dice que la relación entre una subclase y su superclase es una relación
is_a_kind_of.
La subclase comprende un subconjunto de los objetos de la superclase, los
cuales, por tanto, tienen todos los atributos y operaciones de instancia de la su-
perclase (se dice que la subclase los hereda) y, además, pueden tener algunos adi-
cionales, específicos de la subclase.
Según se defina primero la superclase o sus subclases, tenemos respectiva-
mente dos tipos de herencia: herencia por especialización y herencia por gene-
ralización.
© Editorial UOC 49 Capítulo II. UML (I): el modelo estático
4.2.1. Herencia por especialización
Se llama de esta manera porque lo que se hace es crear una clase más especia-
lizada, más restrictiva, a partir de una clase definida con anterioridad. 
Ejemplo de especialización
Consideramos que en la gestión de un hotel identificamos la clase Habitación y des-
pués nos damos cuenta de que hay una categoría especial de habitaciones que tiene
atributos y/o operaciones diferentes, que son las suites; esto se representa de la si-
guiente forma:
La flecha con punta triangular vacía y cuerpo continuo expresa una relación
entre subclase y superclase, y su sentido indica cuál es cada una. También se ha-
bla de que hemos creado una jerarquía de herencia, muy sencilla en algunos ca-
sos (como por ejemplo el caso de especificación) pero que llega a ser un árbol de
diferentes niveles si hay superclases que presenten distintas subclases y subcla-
ses que sean a la vez superclases de otras. 
Incluso la jerarquía se convierte en una red si algunas clases tienen más de
una superclase (herencia múltiple).
El proceso mediante el cual reconocemos una subclase dentro de otra clase –que,
consecuentemente, pasa a ser superclase de la primera– se denomina especializa-
ción o derivación.
© Editorial UOC 50