Ingenieradel software
Ingenieradel software
Benet Campderrich Falgueras
Primera edicin: abril 2003
Fundaci per a la Universitat Oberta de Catalunya Benet Campderrich Falgueres, del texto Editorial UOC, de esta edicinAragn, 182, 08011 BarcelonaMaterial realizado por Eureca Media, SLImpresin:Diseo: Manel Andreu
ISBN: 84-8429-793-4, del productoISBN: 84-8318-997-6, del libroDepsito legal:
Ninguna parte de esta publicacin, incluido el diseo general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningn medio,sea ste elctrico, qumico, mecnico, ptico, grabacin, fotocopia, o cualquier otro, sin la previa autorizacin escrita de los titulares del copyright.
Autor
Benet Campderrich FalguerasDoctor en Ingeniera Industrial. Especializado en ingeniera del software y bases de datos. Profesor titular de la Universidad Rovira i Virgili.
Editorial UOC 7 ndice
ndice
Presentacin ................................................................................................... 13
Captulo I. Introduccin a la ingeniera del software OO ................ 15
1. Qu es la ingeniera del software ............................................................. 151.1. El software como producto industrial.................................................. 161.2. La ingeniera del software .................................................................... 171.3. Los grandes problemas de la ingeniera del software:
la calidad y la productividad............................................................... 172. El ciclo de vida del software ..................................................................... 19
2.1. El ciclo de vida clsico......................................................................... 202.2. Los ciclos de vida iterativos e incrementales ...................................... 23
3. Desarrollo estructurado y desarrollo orientado a objetos ..................... 283.1. Los mtodos estructurados.................................................................. 283.2. Los mtodos orientados a objetos....................................................... 283.3. Los mtodos formales.......................................................................... 30
4. Las herramientas CASE ............................................................................. 305. El OMG y el UML ....................................................................................... 32
5.1. El Object Management Group (OMG) .................................................... 325.2. Unified Modeling Language (UML) ........................................................ 32
Conclusiones ................................................................................................... 35
Captulo II. UML (I): el modelo esttico ................................................ 37
1. Concepto de modelo esttico y diagrama de clases ............................... 372. Clasificadores ............................................................................................. 393. Paquetes...................................................................................................... 404. Clase y conceptos afines ........................................................................... 43
4.1. Representacin ampliada de las clases ................................................ 43
Editorial UOC 8 Ingeniera del software
4.2. La herencia en el anlisis y el diseo .................................................. 484.3. Variantes en el concepto de clase ....................................................... 514.4. Interfaces ............................................................................................. 54
5. Representacin de los objetos .................................................................. 566. Relaciones entre clases .............................................................................. 57
6.1. Asociaciones ........................................................................................ 576.2. Agregaciones y composiciones............................................................ 636.3. Relaciones de dependencia ................................................................. 66
7. Comentarios y restricciones ..................................................................... 677.1. Comentarios ........................................................................................ 677.2. Restricciones........................................................................................ 67
Conclusiones ................................................................................................... 69
Captulo III. UML(II): el modelo dinmico y de implementacin ............................................................................. 71
1. El diagrama de estados.............................................................................. 711.1. Conceptos bsicos ............................................................................... 721.2. Notaciones bsicas............................................................................... 741.3. Transiciones complejas ....................................................................... 781.4. Estados compuestos............................................................................. 791.5. Notacin ampliada del estado............................................................. 82
2. El diagrama de casos de uso ..................................................................... 832.1. Actores ................................................................................................. 832.2. Concepto de caso de uso..................................................................... 852.3. Relaciones entre casos de uso.............................................................. 862.4. Notacin.............................................................................................. 87
3. Los diagramas de interaccin................................................................... 883.1. Interacciones y colaboraciones ........................................................... 883.2. El diagrama de colaboracin ............................................................... 933.3. El diagrama de secuencias ................................................................... 95
4. El diagrama de actividades....................................................................... 994.1. Elementos especficos .......................................................................... 99
5. Los diagramas de implementacin ........................................................ 1025.1. El diagrama de componentes ............................................................ 1025.2. El diagrama de despliegue ................................................................. 105
Conclusiones ................................................................................................. 107
Editorial UOC 9 ndice
Captulo IV. Recogida y documentacin de requisitos ................... 109
1. Los requisitos ........................................................................................... 1101.1. Clases de requisitos ........................................................................... 110
2. Fuentes de informacin .......................................................................... 1113. Pasos de la recogida y documentacin de requisitos ........................... 112
3.1. El contexto del software ..................................................................... 1123.2. Los guiones ........................................................................................ 1143.3. Identificacin de los actores.............................................................. 1143.4. Identificacin de los casos de uso ..................................................... 1153.5. Identificacin de las relaciones entre casos de uso........................... 1163.6. Identificacin de las relaciones de especializacin entre actores ..... 1183.7. La documentacin de los casos de uso ............................................. 118
4. La recogida y documentacin de requisitos de la interfaz de usuario ... 1204.1. Concepto de interfaz de usuario ....................................................... 1204.2. Identificacin de las restricciones tcnicas ....................................... 1214.3. Elaboracin de los perfiles de usuario............................................... 1214.4. Documentacin de las tareas actuales y futuras ............................... 1224.5. Comparacin entre tareas y casos de uso ......................................... 1234.6. Especificaciones de usabilidad .......................................................... 124
5. Ejemplo..................................................................................................... 1245.1. Informacin inicial ........................................................................... 1255.2. Modelo del dominio.......................................................................... 1255.3. Modelo del negocio........................................................................... 1265.4. El glosario del modelo del negocio ................................................... 1285.5. Los guiones ........................................................................................ 1295.6. Casos de uso ...................................................................................... 1305.7. Requisitos de la interfaz de usuario................................................... 135
Conclusiones ................................................................................................. 139
Captulo V. Anlisis orientado a objetos ............................................. 141
1. El papel del anlisis................................................................................. 1421.1. La relacin entre la recogida de requisitos y el anlisis .................... 1421.2. La relacin entre el anlisis y el diseo............................................. 1421.3. La utilidad del anlisis....................................................................... 143
2. Paquetes de anlisis y paquetes de servicios ......................................... 1442.1. Los paquetes de anlisis .................................................................... 145
Editorial UOC 10 Ingeniera del software
2.2. Los paquetes de servicios................................................................... 1453. Revisin de los casos de uso ................................................................... 1464. Especificacin de las clases de anlisis .................................................. 147
4.1. Identificacin de las clases de entidades........................................... 1484.2. Especificacin de los atributos de las clases de entidades................. 1504.3. Identificacin de las relaciones entre clases...................................... 1514.4. Identificacin de las clases de frontera, las clases de control
y de las operaciones. Diagrama esttico de anlisis .......................... 1585. Especificacin formal de los casos de uso ............................................. 1586. Anlisis de la interfaz de usuario ........................................................... 1597. Ejemplo..................................................................................................... 160
7.1. Revisin de los casos de uso.............................................................. 1607.2. Paquetes de anlisis y de servicios .................................................... 1607.3. Identificacin de las clases de entidades........................................... 1617.4. Especificacin de los atributos de las clases de entidades................. 1627.5. Relaciones .......................................................................................... 1637.6. Identificacin de las clases de frontera, las clases de control
y de las operaciones........................................................................... 1667.7. Especificacin formal de los casos de uso ......................................... 1697.8. Anlisis de la interfaz de usuario....................................................... 171
Conclusiones ................................................................................................. 175
Captulo VI. Diseo orientado a objetos.............................................. 177
1. El papel del diseo .................................................................................. 1781.1. La relacin entre el diseo y la realizacin....................................... 1781.2. La utilidad del diseo ........................................................................ 179
2. La reutilizacin ........................................................................................ 1792.1. La reutilizacin de clases ................................................................... 1792.2. La reutilizacin de componentes ...................................................... 1802.3. Los patrones ...................................................................................... 1802.4. Marcos de aplicaciones...................................................................... 192
3. El diseo arquitectnico ......................................................................... 1933.1. Establecimiento de la configuracin de la red .................................. 1943.2. Establecimiento de los subsistemas................................................... 194
4. El diseo de los casos de uso .................................................................. 195
Editorial UOC 11 ndice
5. Revisin del diagrama esttico de diseo ............................................. 1965.1. Normalizacin de los nombres ......................................................... 1975.2. Reutilizacin de clases ....................................................................... 1985.3. Adaptacin de la herencia en el nivel soportado por el lenguaje
de programacin ............................................................................... 1985.4. Sustitucin de las interfaces .............................................................. 2015.5. Cambios para la mejora del rendimiento ......................................... 2015.6. Especificacin de las operaciones implcitas..................................... 2025.7. Referencias a las clases de frontera.................................................... 2025.8. La clase inicial ................................................................................... 2035.9. Cohesin y acoplamiento ................................................................. 203
6. Diseo de la persistencia ........................................................................ 2056.1. Persistencia con bases de datos orientadas a objetos ........................ 2066.2. El modelo para bases de datos relacionales y ficheros clsicos:
alternativas ........................................................................................ 2066.3. Persistencia con bases de datos object-relational ................................ 215
7. Diseo de la interfaz grfica de usuario ................................................ 2167.1. Elementos y funcionamiento de la interfaz grfica de usuario ........ 2177.2. El diseo de las interfaces grficas .................................................... 236
8. Diseo de los subsistemas ....................................................................... 2439. Ejemplo..................................................................................................... 244
9.1. El diseo arquitectnico ................................................................... 2449.2. El diseo de los casos de uso ............................................................. 2449.3. El diagrama esttico de diseo .......................................................... 2499.4. El diseo de la persistencia ............................................................... 2519.5. El diseo de la interfaz de usuario .................................................... 2549.6. El diseo de los subsistemas.............................................................. 258
Conclusiones ................................................................................................. 260
Captulo VII. Introduccin al software distribuido ........................ 261
1. Entornos distribuidos y entornos abiertos ............................................ 2611.1. Objetivos de los entornos distribuidos ............................................. 2621.2. Importancia de las normas en los entornos distribuidos ................. 2631.3. Concepto de sistema abierto ............................................................. 263
2. Entornos cliente/servidores clsicos...................................................... 2642.1. Ventajas e inconvenientes de la arquitectura cliente/servidor......... 2652.2. Arquitecturas cliente/servidor de dos capas...................................... 2662.3. Arquitecturas de ms de dos capas.................................................... 267
Editorial UOC 12 Ingeniera del software
3. Entornos con middleware: CORBA ........................................................ 2683.1. Concepto de middleware.................................................................... 2683.2. CORBA............................................................................................... 269
4. RMI............................................................................................................ 2984.1. Mecanismos de una invocacin remota ........................................... 298
5. Documentos compuestos distribuidos: DCOM..................................... 2995.1. Concepto de documento compuesto ................................................ 2995.2. Aspectos de la gestin de los documentos compuestos.................... 3005.3. OLE, COM y DCOM.......................................................................... 301
6. Desarrollo del software distribuido........................................................ 3086.1. El anlisis de requisitos en el caso de software distribuido ............... 3086.2. La distribucin de los objetos ........................................................... 308
Bibliografa.................................................................................................... 312
Glosario ......................................................................................................... 314
Editorial UOC 13 Presentacin
Presentacin
La ingeniera del software comprende los mtodos y las tcnicas que se utili-
zan en el desarrollo profesional del software. Se trata de un campo muy amplio,
del cual esta materia slo trata una parte.
La ingeniera del software consta principalmente de dos familias de tcnicas:
Las estructuradas, cronolgicamente las ms 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 introduccin a la ingeniera del software.
La tecnologa de elaboracin 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 tecnologa, al principio aparecen muchas tcnicas alternativas y el
paso del tiempo comporta que muchas se abandonen y slo quede una o algunas
que llegan a ser un estndar, oficial o de hecho. Parece que la tecnologa orien-
tada a objetos ha alcanzado hace unos pocos aos esta situacin, al menos en lo
que respecta al modelo bsico, del cual existe el estndar denominado UML, ya
ampliamente aceptado y utilizado. ste es el modelo que utilizamos.
Adems del modelo utilizado, otro aspecto fundamental del desarrollo de
software es el mtodo, ya que, si utilizamos el mismo modelo, podemos imagi-
nar muchos mtodos diferentes que utilizan las notaciones del modelo en otro
orden o para otros propsitos distintos. A diferencia del caso del modelo bsico,
es poco probable que se imponga un mtodo como estndar; como mucho se
puede establecer como estndar legal la presentacin de una determinada docu-
mentacin elaborada segn un modelo fijado, pero la manera como se trabaje
para elaborarla siempre tendr un margen de libertad amplio.
Editorial UOC 14 Ingeniera del software
En esta obra se ha optado por seguir un mtodo inspirado en el denominado
Rational Unified Process, porque ste es bastante elaborado y coherente y, ade-
ms, ha sido desarrollado esencialmente por el mismo equipo que desarroll el
UML, lo cual ofrece una cierta garanta de coherencia entre el mtodo y el mo-
delo.
Se puede considerar que esta obra tiene una parte bsica, un ncleo y una
conclusin:
La parte bsica comprende unos conocimientos fundamentales, que son el ca-
ptulo Introduccin a la ingeniera del software OO, dedicado a los conceptos
generales de la ingeniera del software; el captulo UML (I): el modelo esttico
y el captulo UML (II): el modelo dinmico y de implementacin.
El ncleo de la obra est constituido por los captulos Recogida y documen-
tacin de requisitos, Anlisis orientado a objetos y Diseo orientado a
objetos.
La conclusin es el captulo Introduccin al software distribuido, que ofrece
una visin general de la tecnologa del software distribuido orientado a obje-
tos. Este tema conduce a introducir no solamente la problemtica y las tcni-
cas directamente relacionadas con la distribucin del software, sino tambin
conceptos que tienen un campo de aplicacin ms amplio.
Editorial UOC 15 Captulo I. Introduccin a la...
Captulo I
Introduccin a la ingeniera del software OO
En este captulo se empieza a introducir el concepto de ingeniera de software y
a presentar su problemtica. Se describe con detalle el ciclo de vida clsico 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 tambin las dos grandes lneas tecnolgicas 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 captulo termina con la pre-
sentacin del origen y estatus del modelo estndar UML, el modelo orientado a
objetos que se utiliza en esta obra, y del OMG, la organizacin responsable del
mismo.
1. Qu es la ingeniera del software
Un sistema de software, denominado tambin aplicacin o simplemente
software, es un conjunto integrado de programas que en su forma definitiva se
pueden ejecutar, pero comprende tambin las definiciones de estructuras de da-
tos (por ejemplo, definiciones de bases de datos) que utilizan estos programas y
tambin la documentacin referente a todo ello (tanto la documentacin de
ayuda en el uso del software para sus usuarios como la documentacin generada
durante su construccin, parte de la cual tambin servir para su mantenimien-
to posterior).
Editorial UOC 16 Ingeniera 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 autnomo, el software es un medio auxi-
liar que interviene de manera ms o menos indirecta, pero a menudo imprescin-
dible, en su gestin y cada vez ms en su proceso productivo; tambin 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 fabricacin en serie, las empresas de comercio electr-nico, etc. actualmente no podran funcionar sin software.
Sin embargo, es un producto industrial con algunas caractersticas especiales.
En primer lugar, es mucho ms 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 produccin en serie de copias
del software, sta es una actividad muy poco importante dentro del conjunto de su
proceso productivo y relativamente sencilla.
La produccin de software se parece a la construccin!
Desde cierto punto de vista, la produccin de software se parece a la construccin de vi-viendas o edificios industriales, por ejemplo, en el hecho de que cada producto es dife-rente y su elaboracin se basa en un proyecto especfico (en el caso de produccin enserie, lo que se proyecta es un prototipo del producto, y no cada unidad que se produce).
Editorial UOC 17 Captulo I. Introduccin a la...
Otras caractersticas del software son, como seala 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 tecnolgicamente anticuado o inadaptado a nuevas ne-
cesidades o porque ha llegado a resultar demasiado caro mantenerlo.
1.2. La ingeniera del software
En general, a cada tipo de producto industrial corresponde un tipo de in-
geniera, entendida como el conjunto de mtodos, tcnicas y herramientas
que se utilizan tanto para desarrollar el producto (es decir, elaborar el proyec-
to o prototipo) como para fabricarlo (afinando ms se puede decir que exis-
ten, pues, dos ingenieras para cada tipo de productos: la del producto y la del
proceso).
Una tcnica es la manera preestablecida en la que se lleva a trmino un paso
en la elaboracin del producto, un mtodo es una manera determinada de apli-
car varias tcnicas sucesivamente y una herramienta es un instrumento de cual-
quier tipo que se utiliza en la aplicacin de una tcnica.
El software no es ninguna excepcin a esta regla, y, por tanto, hay una inge-
niera del software que comprende las tcnicas, mtodos y herramientas que se
utilizan para producirlo.
En el caso de la ingeniera del software no se suele hablar de ingeniera de pro-
ceso; quiz se podra pensar que es la que hace referencia a la programacin en
sentido estricto, pero cada vez es menos ntida la distincin entre la programa-
cin y las fases anteriores en el desarrollo de software.
1.3. Los grandes problemas de la ingeniera del software:
la calidad y la productividad
A pesar de los grandes adelantos que ha habido en las tcnicas de desarrollo
de software durante los ltimos treinta aos, tanto la calidad del software como
la productividad de su proceso de elaboracin todava no han alcanzado niveles
Editorial UOC 18 Ingeniera del software
plenamente comparables con los de otras tecnologas ms 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 ms importancia a la calidad en todos los mbitos,
al considerarla un factor de competitividad dentro de unos mercados cada vez
ms saturados y, por tanto, ms exigentes. No es extrao, pues, que el tema de la
calidad (y dentro de ste, cuestiones como la garanta de calidad y las certificacio-
nes oficiales de calidad) adquiera una importancia creciente dentro de la ingenie-
ra del software.
Por lo que respecta a la productividad, cabe decir para empezar que cual-
quier fabricacin en serie tiene necesariamente una productividad mucho ms
elevada que la fabricacin de un producto singular; pero, incluso, si la compa-
ramos con otras ingenieras de producto singular, la productividad es clara-
mente inferior. La complejidad del producto tambin 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 tecnologas, en un proyecto de software el desarrollo empieza tradicio-
nalmente de cero (slo recientemente se utilizan fragmentos de software pre-
fabricados).
El aprovechamiento de elementos en la fabricacin en serie
Cuando se disea un nuevo modelo de coche, se incluyen desde el principio much-simos elementos que ya existan y que, por tanto, no es necesario disear; no sloelementos normalizados como tornillos y tuercas, sino tambin elementos ms com-plejos como bateras e, incluso, motores o cajas de cambio completos. Tambin enla construccin de edificios una actividad que tiene ms semejanzas con la produc-cin de software, como se ha indicado se utilizan muchos elementos estndares oprefabricados: tejas, vigas, ventanas, persianas, grifos, etc.
Por tanto, no es extrao que uno de los grandes retos, por el momento, de
la ingeniera del software sea conseguir desarrollar fragmentos de software (de-
Editorial UOC 19 Captulo I. Introduccin a la...
nominados componentes) que sean reutilizables, por un lado, y, por el otro, de-
sarrollar software y reutilizar sus fragmentos (que seguramente estarn mejor
probados que si se hicieran de nuevo, lo cual adems mejorara la calidad del
software producido).
Una de las vas mediante las cuales se pretende conseguir una cierta reuti-
lizacin en el desarrollo orientado a objetos es especialmente con compo-
nentes; otras son los patrones de diseo (reutilizacin, 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 produccin de software es algo ms que la programacin; 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 mtodos y tcnicas de la ingeniera del software se inscriben dentro
del marco delimitado por el ciclo de vida del software, y, ms 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 mnima garan-
ta de cumplimiento de los plazos, y respetar los lmites de los recursos asignados.
Adems, la garanta de calidad y las certificaciones* de calidad tambin presupo-
nen que el proceso de produccin de software se desarrolle segn un ciclo de vida
con etapas bien definidas.
*. Un ejemplo de certificacin de calidad sera la ISO.
Editorial UOC 20 Ingeniera del software
2.1. El ciclo de vida clsico
La figura siguiente nos muestra las etapas previstas en una cierta versin del
ciclo de vida clsico.
A veces, el ciclo de vida clsico tambin se denomina ciclo de vida en cascada,
lo cual quiere decir que en cada etapa se obtienen unos documentos (en ingls,
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 anlisis previo y tambin anlisis de sistemas
o ingeniera de sistemas. En esta etapa se definen los grandes rasgos del sistema
de software que tendr que dar soporte informtico a unas actividades determi-
nadas de unos ciertos usuarios dentro del marco ms general de la actividad de
la empresa u organizacin.
Editorial UOC 21 Captulo I. Introduccin a la...
Adems, este sistema tendr que funcionar en un entorno de hardware y red
determinado, que ser necesario indicar, y quiz tambin tendr que intercam-
biar informacin 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 estn determinados por los hechos que han
causado las necesidades de informacin que tiene que satisfacer dicho software, y
tambin restricciones eventuales y condiciones adicionales que sea necesario res-
petar; y, en funcin de todo esto, se evala la viabilidad tcnica, econmica y le-
gal del proyecto de desarrollo de dicho software.
El documento que resulta de esta etapa se denomina Especificacin del siste-
ma, y sirve de base para tomar la decisin definitiva sobre la continuacin del
proyecto.
La segunda etapa es el anlisis de requisitos o simplemente anlisis. Su objeti-
vo es definir con detalle las necesidades de informacin que tendr que resolver
el software, sin tener en cuenta, por el momento, los medios tcnicos con los que
se tendr que llevar a trmino el desarrollo del software.
Como el lenguaje de programacin, 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 slo pen-
samos en el software que es necesario desarrollar y sus interfaces con el entorno.
La figura responsable del anlisis el analista, que puede ser un informtico o
un usuario debe tener o adquirir conocimientos generales sobre el dominio de
la aplicacin y obtener informacin 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 informacin se redacta el documento que llamaremos
Especificacin de requisitos, que tiene una doble funcin: especificar qu debe
hacer el software, con la suficiente precisin para que se pueda desarrollar, y servir
de base para un contrato, explcito o no, entre el equipo de desarrollo del software
y sus futuros usuarios.
El diseo es la etapa siguiente. Si el anlisis especifica el problema o qu tiene
que hacer el software, el diseo especifica una solucin a este problema o cmo
el software tiene que hacer su funcin.
Editorial UOC 22 Ingeniera del software
Del software, hay que disear varios aspectos diferenciados: su arquitectura
general, las estructuras de datos (base de datos, etc.), la especificacin 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 construccin de un edificio o de una mquina a partir de unos planos.
El documento resultante es la Especificacin del diseo. La etapa de diseo es
el mejor momento para elaborar la Especificacin de la prueba, que describe con
qu datos se tiene que probar cada programa o grupo de programas y cules son
los resultados esperados en cada caso.
La programacin o codificacin, que es la cuarta etapa, consiste en traducir
el diseo a cdigo 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 penltima 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 documentacin los errores que se detecten.
La prueba se lleva a trmino en las dos fases siguientes:
1) En la primera se hacen pruebas, primero para cada uno de los programas
por separado y, despus, por grupos de programas directamente relacionados, y
se aplica la especificacin 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 aceptacin 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-
tacin, del software, ya que siempre que se utilice el software habr que mantener-
lo, es decir, hacer cambios pequeos o grandes para corregir errores, mejorar
Editorial UOC 23 Captulo I. Introduccin a la...
las funciones o la eficiencia, o adaptarlo a un nuevo hardware o a cambios en las
necesidades de informacin.
Puesto que un software puede estar en explotacin diez aos o ms, 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 generacin
Los lenguajes o ms bien entornos de programacin de cuarta generacin
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 estn integrados en un gestor de bases de datos rela-
cionales. Incluyen herramientas de dibujo de pantallas, generacin de listados y
en ocasiones salidas grficas y hoja de clculo. Algunos pueden generar cdigo en
un lenguaje de tercera generacin.
Para aplicaciones sencillas, se puede pasar directamente de los requisitos a la
codificacin, pero en proyectos complejos es necesario llevar a cabo una etapa de
diseo, 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 atrs.
Tambin queda implcito 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 Ingeniera del software
si el anlisis se ha completado y su resultado es cien por cien fijo, se puede saber
con cierta precisin la duracin del diseo e, incluso, de la programacin.
Ahora bien, en la realidad es posible que la especificacin 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 duracin
del proyecto se han calculado sobre una base muy poco slida y tienen un gran
margen de error.
No obstante, el problema ms grave se presenta en el anlisis 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 especificacin de requisitos es incompleta e insegura, es
obvio que el diseo y la programacin tendrn problemas y, sobre todo, retra-
sos y aumentos de coste importantes para el trabajo no previsto que se deber
hacer y tambin para el que ser necesario rehacer.
Existen dos razones por las cuales es prcticamente imposible elaborar unos
requisitos completos y estables en el primer intento:
a) En primer lugar, es difcil 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, adems, se pon-
gan de acuerdo.
b) En segundo lugar, porque el trabajo de consolidacin 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 anlisis y comenzada la de diseo, todava surgirn re-
quisitos nuevos y cambios en los ya existentes.
Qu se puede hacer, entonces? Parece que la opcin ms razonable sea es-
tudiar a fondo una pequea parte de los requisitos que tenga una cierta autono-
ma, y disearla, 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 ms precisa y que tambin obtengamos una
estimacin cada vez ms segura del coste y de la duracin del proyecto comple-
to; esto es lo que denominamos ciclo de vida iterativo e incremental (iterativo por-
Editorial UOC 25 Captulo I. Introduccin 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 clsico mencionados en este subapar-tado no quieren decir que no pueda haber plazo o lmite de coste para un proyecto dedesarrollo de software; simplemente, se debe reconocer que no es realista creer que sepueda fijar de forma exacta la funcionalidad, el coste y la duracin del proyecto, todoa 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 norealice todas las funciones deseadas; si la funcionalidad y la fecha de entrega del pro-grama son innegociables, se tendr que aumentar el nmero de programadores o ana-listas. Y esto no supone ninguna renuncia en relacin con los resultados que sealcanzaban hasta ahora, porque en la prctica muy pocos eran los proyectos en los queno se producan desviaciones en cuanto a la funcionalidad, presupuesto o plazo, sinoen varias de estas cosas al mismo tiempo.
Por tanto, el modelo de ciclo de vida en cascada puede ser vlido si se aplica de
manera que cada etapa, del anlisis de requisitos a la prueba, no prevea todo el
conjunto del software, sino slo una parte cada vez; entonces tendramos 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 tc-
nicas que dan prioridad a la rapidez y a la facilidad de modificacin antes que a
la eficiencia en el funcionamiento, que slo tiene que servir para que los usua-
rios puedan ver cmo sera 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-
racin, y entonces se prepara una nueva versin del prototipo teniendo en cuen-
Editorial UOC 26 Ingeniera del software
ta las indicaciones de los usuarios y se les ensea otra vez. En el momento en que
el prototipo ha permitido concretar y confirmar los requisitos, se puede comen-
zar un desarrollo segn el ciclo de vida en cascada, en este caso, no obstante, par-
tiendo de una base mucho ms slida.
Caractersticas del ciclo de vida con prototipos
El ciclo de vida con prototipos no se puede considerar plenamente un ciclo de vidaiterativo e incremental, ya que slo el prototipo se elabora de manera iterativa, y nonecesariamente incremental. Sin embargo, es un modelo de ciclo de vida que puedeser adecuado en algunos casos, en especial cuando basta con prototipar un nmeroreducido de funciones para que las otras sean bastante parecidas a stas de forma quelas conclusiones a las que se llegue con el prototipo tambin les sean aplicables.
2.2.3. La programacin exploratoria
La programacin exploratoria consiste en elaborar una primera versin del
software, o de una parte de ste, ensearla a los usuarios para que la critiquen y,
a continuacin, 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.
Caractersticas de la programacin exploratoria
La programacin exploratoria se puede considerar un ciclo de vida iterativo, pero no in-cremental, ya que el software est completo desde la primera versin. Como consecuenciade las numerosas modificaciones que sufre, la calidad del software desarrollado de estamanera y de su documentacin tiende a ser deficiente, como la de un software que hayaexperimentado 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 Captulo I. Introduccin a la...
Se distinguen estas cuatro etapas (denominadas fases):
1) Inicio
Se establece la justificacin econmica del software y se delimita el alcance del
proyecto.
2) Elaboracin
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 informacin y eventuales requisitos no
funcionales y restricciones, se establece la arquitectura general del software y se
realiza una planificacin del proyecto.
3) Construccin
Se desarrolla todo el producto de forma iterativa e incremental, se tienen en
cuenta todas las necesidades de informacin que debe satisfacer y se desarrolla
la arquitectura obtenida en la fase anterior.
4) Transicin
Comprende la entrega del producto al cliente y el comienzo de su utiliza-
cin; aunque es posible que sea necesario hacer retoques en el software y aadir
nuevas funciones como consecuencia de errores detectados o de requisitos que
se haban 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),
anlisis y diseo,
realizacin (implementation),
prueba (test ).
Cada unidad en la que se ejecutan pocos o muchos de los componentes de
proceso es una iteracin, y se aplica a un nuevo fragmento de software. Todas las
fases tienen iteraciones.
Editorial UOC 28 Ingeniera del software
3. Desarrollo estructurado y desarrollo orientado a objetos
Los mtodos de desarrollo de software ms utilizados hasta ahora pertenecen a
dos grandes grupos: los mtodos estructurados y los mtodos orientados a objetos.
3.1. Los mtodos estructurados
Los mtodos estructurados provienen de la programacin estructurada y se
utilizan tcnicas no muy integradas entre s.
Los mtodos estructurados tienen, asimismo, estas caractersticas:
La especificacin de los procesos y la de las estructuras de datos generalmen-
te quedan bastante diferenciadas, y hay mtodos que ponen ms nfasis en
aqullos o en stos.
Muchas de sus tcnicas o bien pasan de lo general a lo particular (tcnicas top-
down) o bien a la inversa (tcnicas bottom-up).
Tcnicas ms utilizadas para los mtodos estructurados
Las tcnicas ms usadas en los mtodos estructurados son seguramente los diagramas
de entidad-relacin y de flujo de datos, con sus variantes. Los primeros se refieren a
los datos y los segundos, a los procesos.
3.2. Los mtodos orientados a objetos
Si bien los mtodos estructurados continan siendo muy utilizados, los de-
nominados mtodos orientados a objetos ganan terreno rpidamente.
Si los mtodos estructurados de desarrollo de software tienen su origen en la pro-
gramacin estructurada, los mtodos orientados a objetos tienen sus races en la
programacin orientada a objetos.
Es lgico que haya sucedido as en los dos casos: una nueva tcnica de pro-
gramar exige una nueva manera de disear los programas adaptada a las carac-
Editorial UOC 29 Captulo I. Introduccin a la...
tersticas de la programacin, y un nuevo mtodo de diseo hace deseable un
nuevo mtodo de anlisis de requisitos que tenga la misma orientacin que el
diseo, con la finalidad de evitar que el paso del anlisis de requisitos al diseo
implique un cambio de modelo que inevitablemente comportara un trabajo
adicional y un mayor riesgo de errores.
De la misma manera que la programacin orientada a objetos gira en torno
al concepto de clase, tambin lo hacen el anlisis de requisitos y el diseo. Por
esta razn, el diagrama bsico de estos mtodos, el diagrama de clases y objetos,
se utiliza tanto en el anlisis como en el diseo; adems, muchas de las clases
descritas en el anlisis de requisitos se implementan en los programas pasando
por el diseo, lo cual hace que el paso del anlisis de requisitos al diseo sea ms
suave que en los mtodos estructurados y tambin ms sencillo y rpido.
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, ms bien, se
construyen grupos de clases interrelacionadas, a menudo por niveles: clases que
gestionan la presentacin de la informacin, 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 segn un ciclo de vida incremental, tal como
hemos visto.
Cabe aadir que el desarrollo orientado a objetos, adems de introducir tc-
nicas nuevas, tambin aprovecha algunas tcnicas y conceptos del desarrollo es-
tructurado, como el diagrama de estados y transiciones, segn veremos.
Hay dos caractersticas del desarrollo orientado a objetos que probablemente
han favorecido de manera decisiva su expansin hasta ahora y tambin con toda
probabilidad la continuarn favoreciendo:
Parece que permite por primera vez en la historia de la tecnologa del soft-
ware la reutilizacin de software en un grado significativo, en forma de cla-
ses implementadas, lo cual podra significar una va para solucionar, aunque
slo sea en parte, los problemas de productividad y calidad descritos en apar-
tados anteriores.
Su relativa simplicidad facilita el desarrollo de herramientas informticas de
ayuda al desarrollo; este factor podra ser potenciado por el hecho de que en
Editorial UOC 30 Ingeniera del software
estos ltimos aos ha aparecido una notacin orientada a objetos muy am-
pliamente aceptada, el UML.
3.3. Los mtodos formales
Los denominados mtodos formales parten de una especificacin de las nece-
sidades de informacin en trminos de un modelo matemtico riguroso, del cual
se podra deducir el programa que les satisfaga. Tambin permitan demostrar ma-
temticamente que un programa es correcto en el sentido de que se ajusta a aque-
llas necesidades.
Aunque tendran que permitir eliminar las ambigedades y carencias de los
mtodos no tan rigurosos, su utilizacin directa en el desarrollo de software para
usos reales es poco frecuente en la actualidad, sin duda debido a la gran com-
plejidad que tendra un modelado tan detallado y formalizado en casos reales.
Algunos de los lenguajes de especificacin formal ms 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 documentacin informatizados
de software.
De esta definicin generalmente se excluyen las herramientas que tienen
una de las funciones siguientes:
1) o bien no tienen slo esta finalidad (herramientas de tratamiento de tex-
to, de hoja de clculo, de dibujo en general, de planificacin de proyectos de
cualquier ingeniera), ya que propiamente pertenecen a otros mbitos;
2) o bien se utilizan para codificar el software (compiladores, entornos de
cuarta generacin, editores ordinarios de programas, etc.), ya que siempre estn
presentes, incluso cuando el desarrollo de software se hace de la manera ms ma-
nual posible.
Editorial UOC 31 Captulo I. Introduccin a la...
Quedan, pues, principalmente las herramientas que ayudan a aplicar tcnicas
concretas de desarrollo y mantenimiento de software y por eso gestionan informa-
cin sobre los elementos y conceptos que se utilizan en los mtodos de desarrollo,
como las siguientes:
Las herramientas diagramticas, las cuales, a diferencia de las de dibujo, re-
conocen que un determinado smbolo es una clase y no simplemente un rec-
tngulo. Estas herramientas tambin acostumbran a aceptar documentacin
textual sobre aquellos elementos.
Las herramientas de gestin de la prueba y de gestin de la calidad en general.
Las herramientas de gestin de cambios, etc.
Herramientas UpperCASE y LowerCASE
A veces se distingue entre herramientas UpperCASE, que son las de anlisis y diseo, yLowerCASE, que se usan durante la programacin y la prueba.
La importancia de la integracin de las herramientas
Es conveniente que las herramientas que dan apoyo a diferentes tcnicas utilizadasdentro del mismo mtodo estn integradas, en el sentido de que si hay un tipo de ele-mento que es comn a dos tcnicas, sea compartido por las dos herramientas respec-tivas, de manera que slo sea necesario describirlo una vez y que todos los cambiosque se realicen despus en esta descripcin lleguen a las dos.
La expansin del uso de herramientas CASE en el mtodo estructurado se fre-
n a causa de la diversidad y de la falta de estandarizacin de las tcnicas que se
utilizan; en los mtodos orientados a objetos, en cambio, actualmente la situa-
cin es la contraria: por un lado, algunos diagramas sirven tanto para el anlisis
como para el diseo, y por el otro, se ha producido una estandarizacin de las
tcnicas y notaciones en el modelo conocido como UML que ha hecho que en
el poco tiempo transcurrido desde su publicacin haya aparecido un nmero
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 Ingeniera del software
sarrollo de software que, tal como hemos visto, la tecnologa 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 organizacin llamada OMG.
5.1. El Object Management Group (OMG)
El Object Management Group (OMG), creado en 1989, es una organizacin no
lucrativa en la cual participan ms de ochocientas grandes empresas de software,
de hardware, usuarias y consultoras, y tiene la finalidad de fomentar el uso de la
tecnologa de objetos e impulsar la introduccin de software orientado a objetos
que ofrezca reusabilidad, portabilidad e interoperabilidad en entornos distribui-
dos heterogneos.
El medio con que el OMG intenta conseguir sus objetivos es la elaboracin de
estndares, para los cuales acepta propuestas. En cambio, no produce software ni
elabora especificaciones de implementacin o funcionalidad.
El otro estndar del OMG
Adems del UML, otro estndar que ha elaborado el OMG es CORBA, sobre objetos dis-
tribuidos, cuyas implementaciones tienen una expansin rpida.
5.2. Unified Modeling Language (UML)
El Unified Modeling Language (UML) es un modelo para la construccin de
software orientado a objetos que ha sido propuesto como estndar de ISO por el
Editorial UOC 33 Captulo I. Introduccin 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 dinmica del software.
UML es el resultado de una cierta unificacin de los modelos utilizados en
tres mtodos preexistentes de desarrollo de software orientado a objetos hechos
por sus autores en colaboracin. Estos mtodos son los siguientes:
el mtodo de Grady Booch;
el OMT, de Jim Rumbaugh y otros;
el OOSE, de Ivar Jacobson.
Adems, se encuentran conceptos aportados por muchos otros autores, en-
tre ellos Peter Coad, Edward Yourdon, James Odell y Bertrand Meyer.
Evolucin del modelo UML
Los primeros pasos hacia el modelo unificado se dieron en el ao 1994, cuando Boochy Rumbaugh, trabajando en Rational Software Corporation, comenzaron la unificacinde los modelos respectivos, y en octubre de 1995 se public la versin provisional 0.8del entonces denominado Unified Method.
El mismo ao, 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 versiones0.9 y 0.91 del UML. El OMG emiti en aquella poca una Request For Proposal, paraun 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 enla OMG la versin 1.0 del UML.
Otras empresas que haban presentado tambin respuestas de manera independientese aadieron al consorcio y se public la versin 1.1, que fue aceptada por el OMG ennoviembre de 1997 (hubo otra propuesta, la del modelo OML, que tena y todava tie-ne un nmero importante de partidarios). El OMG encarg una revisin, cuyo resul-tado fue una versin 1.2, no publicada, y la versin 1.3, ya publicada como estndar.La versin 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 mtodo 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 Ingeniera del software
lo que se ha conseguido es que haya unos diagramas que todos los desarrollado-
res de software orientado a objetos entendern y harn de la misma manera, lo
cual supone un adelanto realmente importante con respecto a la situacin an-
terior en la que cada mtodo tena su notacin grfica; pero, incluso as, conti-
na siendo posible que existan mtodos 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 Captulo I. Introduccin 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 ingeniera del software, y tambin 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 elaboracin del software, hemos visto el
concepto de ciclo de vida y sus dos grandes modelos el ciclo de vida en cascada
o clsico y los ciclos de vida iterativos e incrementales, ms dos modalidades in-
termedias el desarrollo con prototipos y la programacin exploratoria. Como
ciclos concretos, hemos indicado de una manera ms 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 inters radica, adems de en su importancia histrica, en el hecho de
que algunos de sus conceptos continan siendo vlidos todava.
A continuacin, se han presentado las tres grandes familias de mtodos de
desarrollo de software: las dos ms utilizadas en entornos reales, que son los m-
todos estructurados ms tradicionales y los mtodos orientados a objetos en
plena expansin, sin menospreciar los mtodos formales, interesantes por su
gran rigor terico.
Despus de hablar de tcnicas, es lgico referirse a las herramientas que stas
emplean; por eso hemos visto el concepto de herramientas CASE y nos hemos
informado de su situacin actual y de la evolucin previsible de su papel.
Puesto que para estudiar el anlisis y diseo orientados a objetos tema esen-
cial de esta obra utilizaremos los conceptos y la notacin del UML, se ha expues-
to el origen de este modelo y el cometido de la organizacin que se responsabiliza
del mismo, la OMG.
Editorial UOC 37 Captulo II. UML (I): el modelo esttico
Captulo II
UML (I): el modelo esttico
Como sabemos, para el anlisis y el diseo orientados a objetos utilizaremos
los conceptos y las notaciones esencialmente grficas del UML.
El UML comprende un cierto nmero de diagramas interrelacionados me-
diante conceptos comunes. Slo para describirlos, los consideraremos agrupa-
dos en tres modelos:
En este captulo veremos el modelo esttico, que consta, por una parte, de clases
y objetos, y por la otra, de relaciones de diferentes tipos entre clases y entre objetos.
En captulos posteriores trataremos el resto de los modelos y la utilizacin
del UML en el anlisis y en el diseo.
1. Concepto de modelo esttico y diagrama de clases
El modelo esttico del UML es aqul en el que se describen las clases y los
objetos. Se denomina esttico porque muestra todas las relaciones posibles a lo
largo del tiempo, no las que son vlidas en un cierto momento.
Esttico describe la estructura de clases y objetos.
Dinmico (o modelo de comportamiento), describe las interacciones entre los objetos dentro del software.
Implementacin describe la estructura del software en cuanto a los componentes de que consta y su ubicacin.
Editorial UOC 38 Ingeniera del software
Ejemplo de modelo esttico
Un diagrama esttico 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 slo 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 esttica de las clases en un do-
minio (porcin del mundo real considerada por una aplicacin); se muestran las
clases y las relaciones entre stas, que pueden ser de herencia, asociacin, agre-
gacin o uso.
Uso del modelo esttico
El modelo esttico se utiliza en todas las etapas del ciclo de vida; en las diferentes etapasse documentan diferentes tipos de objetos. En el anlisis se consideran objetos del mun-do del usuario (por ejemplo, artculos, facturas, clientes, etc.) y en el diseo, en cambio,se consideran objetos de la tecnologa informtica: pantallas, gestores de disco, etc.
El modelo esttico pretende ser independiente del lenguaje de programa-
cin, pero, sin embargo, si se sabe cul ser, es conveniente no utilizarlo en
el anlisis de conceptos que sabemos que dicho lenguaje no soporta, si que-
remos ahorrarnos muchos cambios cuando lleguemos al diseo. Tambin 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 diseador del software
evitar caer en la utilizacin de conceptos no soportados por el lenguaje de
programacin.
Editorial UOC 39 Captulo II. UML (I): el modelo esttico
Relaciones en los lenguajes de programacin
Los lenguajes de programacin soportan las relaciones de herencia, pero no distin-guen entre los otros tres tipos de relaciones que existen; por tanto, al pasar del diseoa la programacin, estos tipos se tendrn que transformar.
Tambin 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 tendrn 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 sern transportables a otras empresas.
2. Clasificadores
El clasificador es la entidad bsica del modelo esttico. Un clasificador es
ms general que una clase; es un conjunto cuyos elementos se denominan ins-
tancias.
El clasificador en s mismo no tiene smbolo grfico, sino que lo tienen sus
estereotipos:
Clase: El concepto de clase es el que ya conocemos de la programacin 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 algn
lenguaje de programacin 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 slo 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 Ingeniera del software
Estereotipo
Un estereotipo de un elemento del UML es una variante ms restrictiva de dicho ele-mento; hay estereotipos que forman parte del UML, y tambin se pueden encontrarestereotipos definidos referidos al diagrama, que son un instrumento para extenderel 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 comn, por lo que es suficiente con reali-
zar la indicacin una vez en el clasificador. La notacin grfica simplificada es
la misma para los tres: un rectngulo.
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 ningn estereotipo, se tratar de una clase.
3. Paquetes
Un paquete o package es slo una caja que contiene elementos, como cla-
sificadores, objetos u otros paquetes, as como otras entidades que veremos ms
adelante, como los casos de uso.
Paquetes en JAVA
Por la definicin que ofrecemos de paquete, podemos ver que el concepto de paqueteen el UML es diferente y ms amplio que en Java.
Editorial UOC 41 Captulo II. UML (I): el modelo esttico
Grficamente, un paquete se representa as:
Todas las aplicaciones deben tener, por lo menos, un paquete que normal-
mente se denomina raz. Cada elemento de un paquete tiene visibilidad, es decir,
puede ser reconocido o bien desde todos los otros paquetes, o bien slo desde al-
gunos.
Ejemplo de paquetes
stas son dos maneras de representar el mismo paquete:
En la primera, se pueden incluir dentro del smbolo del paquete los smbolos de loselementos que contiene; la segunda, simplificada, es ms adecuada para representarreferencias al paquete (desde otros paquetes, por ejemplo).
Se pueden establecer los siguientes tipos de relaciones entre paquetes:
De especializacin. Si un paquete A hereda de otro B todos los elementos de B,
son casos ms restrictivos de elementos de A.
De inclusin. Si el paquete A incluye el B, todos los elementos de B estn
tambin en A.
Editorial UOC 42 Ingeniera del software
De importacin. Desde el paquete que importa se reconocen los nombres de
los elementos del otro paquete visibles desde el exterior.
Ejemplo
Por ejemplo, pblicos en el sentido de Java.
De acceso. No slo se reconocen los nombres de los elementos, sino que, ade-
ms, se pueden utilizar.
Ejemplo de relaciones entre paquetes
En la representacin grfica, el paquete Diagramas que vemos a continuacin importadel paquete Figuras, y el paquete Diagramas de UML hereda del paquete Diagramas;una relacin de acceso se representara con la palabra clave access.
Editorial UOC 43 Captulo II. UML (I): el modelo esttico
4. Clase y conceptos afines
Sobre la programacin 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 estn relacionados con
ningn 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. Representacin ampliada de las clases
Puesto que una clase es un clasificador, se puede utilizar como smbolo de la
clase un simple rectngulo con el nombre. Sin embargo, dado que una clase con-
siste en un encapsulado de unos atributos y unas operaciones, tambin se da una
representacin grfica ms detallada por medio de un rectngulo 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 sinnimos de operacin se utilizan a menudo m-todo y servicio; pero en UML, el trmino servicio no se usa, y por mtodo se entiendela implementacin de una operacin.
El usuario puede crear otros compartimentos, adems de los tres obligatorios,
para dar informacin adicional como excepciones, requisitos, etc.
Editorial UOC 44 Ingeniera 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 ms 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.
Tambin es recomendable que comience por mayscula.
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 ms elementos, pero que no se ven. La
property string abstract denota una clase abstracta.
El nombre de clases
Los nombres de las clases tienen que estar bien pensados. La posibilidad de reuti-lizacin depende en gran medida de ello, porque cuando queramos reutilizar unaclase de una librera 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 difcil de en-contrar.
Un atributo de clase es lo mismo que un atributo static de Java y una variable de clase deSmalltalk y C++.
Ejemplo de clase slo con el compartimento del nombre
En la figura siguiente, el estereotipo anlisis podra indicar que la clase Rectangulo seha identificado en la etapa de anlisis.
*. Formato de los comentariosProperty 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 Captulo II. UML (I): el modelo esttico
4.1.2. Especificacin de los atributos
Cada atributo tiene un nombre o identificador y un tipo. Este ltimo puede
ser un tipo simple del lenguaje de programacin (por lo menos, durante el di-
seo y la programacin, porque durante el anlisis puede ser que las clases se
describan sin pensar en ningn lenguaje de programacin en concreto) como
entero o carcter, o bien un tipo complejo, como una lista de enteros, o tam-
bin una clase ya definida.
Un atributo, sea de instancia o de clase, se define de la siguiente forma:
visibilidad nombre : expresin-de-tipo ?= valor-inicial { property string }
Se indica que un atributo es atributo de clase* subrayando su definicin.
La visibilidad de un atributo** indica hasta qu punto las operaciones de
otras clases pueden acceder al atributo, y se indica mediante los siguientes sm-
bolos.
Pblico: +
Protegido: #
Privado: -
Dentro del paquete:
Tambin tienen visibilidad otros elementos del modelo esttico, como las
operaciones y los extremos de asociacin.
*. Atributo de clase. Un atributo de clase es lo mismo que un atributo static de Java y una variablede 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 programacin; si algn lenguaje incluye ms tipos de visibi-lidad, tambin se podrn indicar aqu.
Editorial UOC 46 Ingeniera 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; adems
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 minscula.
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 lxicas del lenguaje de pro-
gramacin, si no queremos que se tenga que cambiar al llegar al diseo. La
expresin de tipo y el valor inicial tambin las debern 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 podra haber entre 0 y3 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 Captulo II. UML (I): el modelo esttico
extremos seran las coordenadas de dos vrtices opuestos del rectngulo, que lo determi-nan; Punto sera una clase descrita en el mismo paquete; gruesoLnea tiene el valor 1 poromisin, y rea es un atributo derivado, ya que su valor se puede calcular a partir de lascoordenadas de los puntos de extremos.
4.1.3. Especificacin de las operaciones
Una operacin se define de la siguiente forma:
visibilidad nombre ( lista-de-parmetros ): tipo-de-retorno {property string}
Se indica que una operacin es operacin de clase subrayando su definicin.
La visibilidad se seala igual que en el caso de los atributos.
Conviene que el nombre de la operacin y de los parmetros y el tipo de los
parmetros y del retorno cumplan las reglas del lenguaje de programacin.
En la programacin conviene que los nombres de las operaciones estn 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 minscula.
La lista de parmetros se compone de parmetros separados por comas; la sin-
taxis de cada uno es la siguiente:
tipo nombre : expresin-de-tipo = valor-por-omisin
Donde tipo es in, out o inout (por omisin, in), y nombre es el nombre del pa-
rmetro formal; expresin-de-tipo depende del lenguaje; valor-por-omisin depen-
de del lenguaje y es opcional.
El tipo-de-retorno slo se tiene que utilizar cuando la operacin devuelva un
valor como resultado, y tambin se puede usar un parmetro out en su lugar.
Opcionalmente, puede aparecer property strings: query, que denota que la ope-
racin no modifica el estado del sistema, y para especificar la semntica de concu-
rrencia se pueden utilizar una de stas: sequential, guarded o concurrent, y abstract,
que indica que la operacin es abstracta.
Se pueden utilizar estereotipos ponindolos encima de la operacin afectada.
Editorial UOC 48 Ingeniera del software
Ejemplo de clase con los tres compartimentos
Tal y como se puede apreciar en el grfico siguiente, la operacin nuevoRectangulo es delestereotipo (no incluido dentro del UML) constructor y tiene dos parmetros in (poromisin); la operacin calculoArea no tiene parmetros pero retorna un valor, cuyo tipose indica.
4.2. La herencia en el anlisis y el diseo
Sabemos que la herencia presupone que existan dos clases, de las cuales una
desempea el papel de superclase y la otra, el de subclase.
Se dice que la relacin entre una subclase y su superclase es una relacin
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, adems, pueden tener algunos adi-
cionales, especficos de la subclase.
Segn se defina primero la superclase o sus subclases, tenemos respectiva-
mente dos tipos de herencia: herencia por especializacin y herencia por gene-
ralizacin.
Editorial UOC 49 Captulo II. UML (I): el modelo esttico
4.2.1. Herencia por especializacin
Se llama de esta manera porque lo que se hace es crear una clase ms especia-
lizada, ms restrictiva, a partir de una clase definida con anterioridad.
Ejemplo de especializacin
Consideramos que en la gestin de un hotel identificamos la clase Habitacin y des-pus nos damos cuenta de que hay una categora especial de habitaciones que tieneatributos y/o operaciones diferentes, que son las suites; esto se representa de la si-guiente forma:
La flecha con punta triangular vaca y cuerpo continuo expresa una relacin
entre subclase y superclase, y su sentido indica cul es cada una. Tambin se ha-
bla de que hemos creado una jerarqua de herencia, muy sencilla en algunos ca-
sos (como por ejemplo el caso de especificacin) 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 jerarqua se convierte en una red si algunas clases tienen ms de
una superclase (herencia mltiple).
El proceso mediante el cual reconocemos una subclase dentro de otra clase que,
consecuentemente, pasa a ser superclase de la primera se denomina especializa-
cin o derivacin.
Editorial UOC 50 Ingeniera del software
4.2.2. Herencia por generalizacin. Clases abstractas
Supongamos que, al informatizar los impuestos de un municipio, encontra-
mos, por un lado, los impuestos sobre las motos y por otro, los impuestos sobre
los ciclomotores. Aunque inicialmente se haba considerado que Motos y Ciclo-
motores son dos clases diferentes, despus se ha observado que tienen algunos
atributos y operaciones en comn y, en consecuencia, se define una superclase
comn Veh2Ruedas
En este caso hemos procedido al revs: a partir de las subclases, hemos en-
contrado la superclase. Este proceso se denomina generalizacin.
De la misma forma que en el ejemplo del hotel poda haber habitaciones que no
fueran suites y, por tanto, haba objetos que, de las dos clases, slo pertenecan a Ha-
bitacin, en este ltimo, cualquier vehculo de dos ruedas es o bien una moto o
bien un ciclomotor. Es decir, todos los elementos de Veh2Ruedas pertenecen a
una u otra subclase y, por lo tanto, Veh2Ruedas es una clase artificial, un simple
recurso para no describir dos veces lo que tienen en comn Motos y Ciclomotores; se
dice que Veh2Ruedas es una clase abstracta.
Una clase abstracta es una superclase de la cual no se pueden crear (instanciar)
directamente objetos, sino que se tienen que crear necesariamente en alguna de
sus subclases.
Editorial UOC 51 Captulo II. UML (I): el modelo esttico
Otro procedimiento
En el proceso de generalizacin tambin se podra haber trazado una flecha indepen-diente desde cada subclase a la superclase. La propiedad disjoint denota que todo ob-jeto de la superclase pueda pertenecer slo a una de las subclases como mximo.
Por esta razn se dice que las clases abstractas son no instanciables.
Se indica que una clase es abstracta o bien poniendo su nombre en cursiva,
o bien con la propiedad {abstract} en el compartimento del nombre.
Una clase abstracta puede tener operaciones abstractas, que son las que slo es-
tn implementadas en las subclases, en principio, de forma diferente en cada una.
Una operacin abstracta debe tener o bien su definicin en cursiva, o bien la
propiedad {abstract} al final de la misma.
4.3. Variantes en el concepto de clase
En este subapartado consideraremos diferentes tipos especiales de clases,
pero no todos se pueden representar directamente en UML.
4.3.1. Clases diferidas
Las clases diferidas son clases abstractas que tienen alguna operacin abstracta.
Tambin se denominan clases virtuales porque en algunos lenguajes como
C++ o Delphi, los servicios de las caractersticas que acabamos de indicar se de-
claran virtual; en Java se declaran abstract, y en Eiffel, deferred. En UML se definen
simplemente como clases abstractas.
4.3.2. Clases terminales
Muchas veces, y especialmente en frameworks, nos interesa bloquear los cam-
bios que se podran realizar con la herencia, porque al crear una subclase es fcil
Editorial UOC 52 Ingeniera del software
que no se conozcan todas las dependencias y restricciones que se heredan, de
modo que se pueden cometer errores.
Java permite calificar diferentes elementos como terminales:
Clases terminales, que son las que no pueden tener subclases. Mtodos terminales, que son aquellos que no pueden ser modificados en una subclase. Atributos terminales, cuya visibilidad no se puede cambiar en una subclase.
El UML no dispone de estos conceptos.
4.3.3. Metaclases
Las metaclases son clases cuyas instancias son clases.
El concepto de metaclase raramente se encuentra implementado en los len-
guajes orientados a objetos; un lenguaje que lo implementa es el CLOS (CLOS
es la sigla de Common Lisp Object System), que fue creado por investigadores de
inteligencia artificial y es un derivado del LISP.
En UML, la metaclase es un estereotipo de la clase.
4.3.4. Clases parametrizadas o plantillas
Una clase parametrizada o plantilla (en ingls, template) es un descriptor de
clase formalmente igual a una clase, excepto que algn trmino de su definicin
es un parmetro.
Qu es un parmetro de una plantilla?
Un parmetro puede ser, por ejemplo, el nombre de una operacin o atributo, el tipo deun atributo o de un parmetro o del resultado de una operacin, el nmero de elemen-tos de un atributo que sea una matriz o el nmero de bytes de un atributo de tipo string.
Cuando se dan valores a todos los parmetros de una plantilla se obtiene una
clase totalmente especificada que, por tanto, no puede ser modificada directa-
Editorial UOC 53 Captulo II. UML (I): el modelo esttico
mente, pero se pueden definir sus subclases. Aunque una plantilla no es propia-
mente una clase, se puede definir como subclase de una clase A, y entonces las
clases que se han obtenido al dar valores a sus parmetros sern subclases de A.
Ejemplo de clase parametrizada
En el diagrama que vemos a continuacin hemos definido una plantilla, hemos ge-nerado una clase y hemos dado un valor a cada parmetro. La relacin entre la clasey la plantilla se puede representar de las dos formas indicadas:
Las clases parametrizadas se denominan clases genricas* en algunos lenguajes
de programacin.
4.3.5. Clases de utilidad
A veces nos encontramos con rutinas que no corresponden a ninguna clase de
operacin, o bien con datos que no corresponden a ningn objeto determinado,
por ejemplo, parmetros del sistema que slo pueden tener un valor cada uno.
Para incluir estas rutinas y datos dentro de un diagrama esttico de UML, po-
demos definir una clase con el estereotipo utility, e incluir las rutinas como ope-
raciones y los datos como atributos.
*. Las clases genricas en otros lenguajes. C++ y Eiffel soportan plenamente las clases genricaspero con algunas diferencias, mientras que en Java