You are on page 1of 321

Ingeniera del software

Ingeniera del 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 edicin Aragn, 182, 08011 Barcelona Material realizado por Eureca Media, SL Impresin: Diseo: Manel Andreu ISBN: 84-8429-793-4, del producto ISBN: 84-8318-997-6, del libro Depsito 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 Falgueras Doctor en Ingeniera Industrial. Especializado en ingeniera del software y bases de datos. Profesor titular de la Universidad Rovira i Virgili.

Editorial UOC

ndice

ndice

Presentacin ................................................................................................... 13

Captulo I. Introduccin a la ingeniera del software OO ................ 15 1. Qu 1.1. 1.2. 1.3. 2. es la ingeniera del software ............................................................. El software como producto industrial.................................................. La ingeniera del software .................................................................... Los grandes problemas de la ingeniera del software: la calidad y la productividad ............................................................... El ciclo de vida del software ..................................................................... 2.1. El ciclo de vida clsico......................................................................... 2.2. Los ciclos de vida iterativos e incrementales ...................................... Desarrollo estructurado y desarrollo orientado a objetos ..................... 3.1. Los mtodos estructurados .................................................................. 3.2. Los mtodos orientados a objetos ....................................................... 3.3. Los mtodos formales.......................................................................... Las herramientas CASE ............................................................................. El OMG y el UML ....................................................................................... 5.1. El Object Management Group (OMG) .................................................... 5.2. Unified Modeling Language (UML) ........................................................ 15 16 17 17 19 20 23 28 28 28 30 30 32 32 32

3.

4. 5.

Conclusiones ................................................................................................... 35

Captulo II. UML (I): el modelo esttico ................................................ 37 1. 2. 3. 4. Concepto de modelo esttico y diagrama de clases ............................... Clasificadores ............................................................................................. Paquetes ...................................................................................................... Clase y conceptos afines ........................................................................... 4.1. Representacin ampliada de las clases ................................................ 37 39 40 43 43

Editorial UOC

Ingeniera del software

4.2. La herencia en el anlisis y el diseo .................................................. 4.3. Variantes en el concepto de clase ....................................................... 4.4. Interfaces ............................................................................................. 5. Representacin de los objetos .................................................................. 6. Relaciones entre clases .............................................................................. 6.1. Asociaciones ........................................................................................ 6.2. Agregaciones y composiciones ............................................................ 6.3. Relaciones de dependencia ................................................................. 7. Comentarios y restricciones ..................................................................... 7.1. Comentarios ........................................................................................ 7.2. Restricciones ........................................................................................

48 51 54 56 57 57 63 66 67 67 67

Conclusiones ................................................................................................... 69

Captulo III. UML(II): el modelo dinmico y de implementacin ............................................................................. 71 1. El diagrama de estados .............................................................................. 71 1.1. Conceptos bsicos ............................................................................... 72 1.2. Notaciones bsicas............................................................................... 74 1.3. Transiciones complejas ....................................................................... 78 1.4. Estados compuestos............................................................................. 79 1.5. Notacin 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. Notacin .............................................................................................. 87 3. Los diagramas de interaccin ................................................................... 88 3.1. Interacciones y colaboraciones ........................................................... 88 3.2. El diagrama de colaboracin ............................................................... 93 3.3. El diagrama de secuencias ................................................................... 95 4. El diagrama de actividades ....................................................................... 99 4.1. Elementos especficos .......................................................................... 99 5. Los diagramas de implementacin ........................................................ 102 5.1. El diagrama de componentes ............................................................ 102 5.2. El diagrama de despliegue ................................................................. 105 Conclusiones ................................................................................................. 107

Editorial UOC

ndice

Captulo IV. Recogida y documentacin de requisitos ................... 109 1. Los requisitos ........................................................................................... 1.1. Clases de requisitos ........................................................................... 2. Fuentes de informacin .......................................................................... 3. Pasos de la recogida y documentacin de requisitos ........................... 3.1. El contexto del software ..................................................................... 3.2. Los guiones ........................................................................................ 3.3. Identificacin de los actores.............................................................. 3.4. Identificacin de los casos de uso ..................................................... 3.5. Identificacin de las relaciones entre casos de uso ........................... 3.6. Identificacin de las relaciones de especializacin entre actores ..... 3.7. La documentacin de los casos de uso ............................................. 4. La recogida y documentacin de requisitos de la interfaz de usuario ... 4.1. Concepto de interfaz de usuario ....................................................... 4.2. Identificacin de las restricciones tcnicas ....................................... 4.3. Elaboracin de los perfiles de usuario............................................... 4.4. Documentacin de las tareas actuales y futuras ............................... 4.5. Comparacin entre tareas y casos de uso ......................................... 4.6. Especificaciones de usabilidad .......................................................... 5. Ejemplo ..................................................................................................... 5.1. Informacin inicial ........................................................................... 5.2. Modelo del dominio.......................................................................... 5.3. Modelo del negocio ........................................................................... 5.4. El glosario del modelo del negocio ................................................... 5.5. Los guiones ........................................................................................ 5.6. Casos de uso ...................................................................................... 5.7. Requisitos de la interfaz de usuario................................................... 110 110 111 112 112 114 114 115 116 118 118 120 120 121 121 122 123 124 124 125 125 126 128 129 130 135

Conclusiones ................................................................................................. 139

Captulo V. Anlisis orientado a objetos ............................................. 141 1. El papel del anlisis ................................................................................. 1.1. La relacin entre la recogida de requisitos y el anlisis .................... 1.2. La relacin entre el anlisis y el diseo............................................. 1.3. La utilidad del anlisis....................................................................... 2. Paquetes de anlisis y paquetes de servicios ......................................... 2.1. Los paquetes de anlisis .................................................................... 142 142 142 143 144 145

Editorial UOC

10

Ingeniera del software

2.2. Los paquetes de servicios................................................................... 3. Revisin de los casos de uso ................................................................... 4. Especificacin de las clases de anlisis .................................................. 4.1. Identificacin de las clases de entidades........................................... 4.2. Especificacin de los atributos de las clases de entidades................. 4.3. Identificacin de las relaciones entre clases...................................... 4.4. Identificacin de las clases de frontera, las clases de control y de las operaciones. Diagrama esttico de anlisis .......................... 5. Especificacin formal de los casos de uso ............................................. 6. Anlisis de la interfaz de usuario ........................................................... 7. Ejemplo ..................................................................................................... 7.1. Revisin de los casos de uso .............................................................. 7.2. Paquetes de anlisis y de servicios .................................................... 7.3. Identificacin de las clases de entidades........................................... 7.4. Especificacin de los atributos de las clases de entidades................. 7.5. Relaciones .......................................................................................... 7.6. Identificacin de las clases de frontera, las clases de control y de las operaciones........................................................................... 7.7. Especificacin formal de los casos de uso ......................................... 7.8. Anlisis de la interfaz de usuario.......................................................

145 146 147 148 150 151 158 158 159 160 160 160 161 162 163 166 169 171

Conclusiones ................................................................................................. 175

Captulo VI. Diseo orientado a objetos.............................................. 177 1. El papel del diseo .................................................................................. 1.1. La relacin entre el diseo y la realizacin ....................................... 1.2. La utilidad del diseo ........................................................................ 2. La reutilizacin ........................................................................................ 2.1. La reutilizacin de clases ................................................................... 2.2. La reutilizacin de componentes ...................................................... 2.3. Los patrones ...................................................................................... 2.4. Marcos de aplicaciones...................................................................... 3. El diseo arquitectnico ......................................................................... 3.1. Establecimiento de la configuracin de la red .................................. 3.2. Establecimiento de los subsistemas................................................... 4. El diseo de los casos de uso .................................................................. 178 178 179 179 179 180 180 192 193 194 194 195

Editorial UOC

11

ndice

5. Revisin del diagrama esttico de diseo ............................................. 5.1. Normalizacin de los nombres ......................................................... 5.2. Reutilizacin de clases ....................................................................... 5.3. Adaptacin de la herencia en el nivel soportado por el lenguaje de programacin ............................................................................... 5.4. Sustitucin de las interfaces .............................................................. 5.5. Cambios para la mejora del rendimiento ......................................... 5.6. Especificacin de las operaciones implcitas..................................... 5.7. Referencias a las clases de frontera.................................................... 5.8. La clase inicial ................................................................................... 5.9. Cohesin y acoplamiento ................................................................. 6. Diseo de la persistencia ........................................................................ 6.1. Persistencia con bases de datos orientadas a objetos ........................ 6.2. El modelo para bases de datos relacionales y ficheros clsicos: alternativas ........................................................................................ 6.3. Persistencia con bases de datos object-relational ................................ 7. Diseo de la interfaz grfica de usuario ................................................ 7.1. Elementos y funcionamiento de la interfaz grfica de usuario ........ 7.2. El diseo de las interfaces grficas .................................................... 8. Diseo de los subsistemas ....................................................................... 9. Ejemplo ..................................................................................................... 9.1. El diseo arquitectnico ................................................................... 9.2. El diseo de los casos de uso ............................................................. 9.3. El diagrama esttico de diseo .......................................................... 9.4. El diseo de la persistencia ............................................................... 9.5. El diseo de la interfaz de usuario .................................................... 9.6. El diseo de los subsistemas..............................................................

196 197 198 198 201 201 202 202 203 203 205 206 206 215 216 217 236 243 244 244 244 249 251 254 258

Conclusiones ................................................................................................. 260

Captulo VII. Introduccin al software distribuido ........................ 261 1. Entornos distribuidos y entornos abiertos ............................................ 1.1. Objetivos de los entornos distribuidos ............................................. 1.2. Importancia de las normas en los entornos distribuidos ................. 1.3. Concepto de sistema abierto ............................................................. 2. Entornos cliente/servidores clsicos ...................................................... 2.1. Ventajas e inconvenientes de la arquitectura cliente/servidor ......... 2.2. Arquitecturas cliente/servidor de dos capas...................................... 2.3. Arquitecturas de ms de dos capas.................................................... 261 262 263 263 264 265 266 267

Editorial UOC

12

Ingeniera del software

3. Entornos con middleware: CORBA ........................................................ 3.1. Concepto de middleware .................................................................... 3.2. CORBA ............................................................................................... 4. RMI ............................................................................................................ 4.1. Mecanismos de una invocacin remota ........................................... 5. Documentos compuestos distribuidos: DCOM ..................................... 5.1. Concepto de documento compuesto ................................................ 5.2. Aspectos de la gestin de los documentos compuestos.................... 5.3. OLE, COM y DCOM .......................................................................... 6. Desarrollo del software distribuido........................................................ 6.1. El anlisis de requisitos en el caso de software distribuido ............... 6.2. La distribucin de los objetos ...........................................................

268 268 269 298 298 299 299 300 301 308 308 308

Bibliografa .................................................................................................... 312 Glosario ......................................................................................................... 314

Editorial UOC

13

Presentacin

Presentacin

La ingeniera del software comprende los mtodos y las tcnicas que se utilizan 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 mayor 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 orientada 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 imaginar 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 documentacin 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, adems, 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 modelo. 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 captulo 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 documentacin 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 objetos. Este tema conduce a introducir no solamente la problemtica y las tcnicas 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 cascada, y se presentan los modelos de ciclo de vida alternativos, en especial los conocidos 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 desarrollo de software: el desarrollo estructurado y el desarrollo orientado a objetos, y se introduce el concepto de herramienta CASE. El captulo termina con la presentacin 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 datos (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 mantenimiento 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 auxiliar que interviene de manera ms o menos indirecta, pero a menudo imprescindible, 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 considerar plenamente como un producto industrial.
Por ejemplo... los bancos, las industrias de fabricacin en serie, las empresas de comercio electrnico, 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 fabrique en serie (aunque algunos software tienen muchos miles de usuarios e, incluso, 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 viviendas o edificios industriales, por ejemplo, en el hecho de que cada producto es diferente y su elaboracin se basa en un proyecto especfico (en el caso de produccin en serie, 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 estropea 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 necesidades 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 ingeniera, entendida como el conjunto de mtodos, tcnicas y herramientas que se utilizan tanto para desarrollar el producto (es decir, elaborar el proyecto o prototipo) como para fabricarlo (afinando ms se puede decir que existen, 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 aplicar varias tcnicas sucesivamente y una herramienta es un instrumento de cualquier tipo que se utiliza en la aplicacin de una tcnica. El software no es ninguna excepcin a esta regla, y, por tanto, hay una ingeniera 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 proceso; 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 programacin 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 certificaciones oficiales de calidad) adquiera una importancia creciente dentro de la ingeniera del software. Por lo que respecta a la productividad, cabe decir para empezar que cualquier fabricacin en serie tiene necesariamente una productividad mucho ms elevada que la fabricacin de un producto singular; pero, incluso, si la comparamos con otras ingenieras de producto singular, la productividad es claramente 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 realmente importante en la baja productividad es el hecho de que, a diferencia de las otras tecnologas, en un proyecto de software el desarrollo empieza tradicionalmente de cero (slo recientemente se utilizan fragmentos de software prefabricados).
El aprovechamiento de elementos en la fabricacin en serie Cuando se disea un nuevo modelo de coche, se incluyen desde el principio muchsimos elementos que ya existan y que, por tanto, no es necesario disear; no slo elementos normalizados como tornillos y tuercas, sino tambin elementos ms complejos como bateras e, incluso, motores o cajas de cambio completos. Tambin en la construccin de edificios una actividad que tiene ms semejanzas con la produccin de software, como se ha indicado se utilizan muchos elementos estndares o prefabricados: 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, desarrollar 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 reutilizacin en el desarrollo orientado a objetos es especialmente con componentes; 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 limitaciones. Sin embargo, es indispensable que todo proyecto se desarrolle dentro del marco de un ciclo de vida claramente definido, si se quiere tener una mnima garanta de cumplimiento de los plazos, y respetar los lmites de los recursos asignados. Adems, la garanta de calidad y las certificaciones* de calidad tambin presuponen 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 determinadas 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 intercambiar 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 respetar; y, en funcin de todo esto, se evala la viabilidad tcnica, econmica y legal del proyecto de desarrollo de dicho software. El documento que resulta de esta etapa se denomina Especificacin del sistema, 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 objetivo 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 componentes que se pueden reutilizar, etc. En esta etapa detallamos los requisitos de la etapa anterior; ahora slo pensamos 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 permita 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 todas sus funcionalidades y componentes. La prueba es la ltima etapa del desarrollo del software y la penltima del modelo 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 resultados 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 resultados son satisfactorios, se entrega el software al cliente, el cual puede hacer una prueba 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, explotacin, del software, ya que siempre que se utilice el software habr que mantenerlo, 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 menudo 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 instrucciones equivale a muchas instrucciones del lenguaje ensamblador) y en gran parte son no procedimentales y estn integrados en un gestor de bases de datos relacionales. 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 s abe 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 fiable en lo que respecta a las funciones, ya que no se espera que se describan punto 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, retrasos 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 pongan 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 terminada oficialmente la etapa de anlisis y comenzada la de diseo, todava surgirn requisitos nuevos y cambios en los ya existentes. Qu se puede hacer, entonces? Parece que la opcin ms razonable sea estudiar a fondo una pequea parte de los requisitos que tenga una cierta autonoma, 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 requisitos 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 completo; 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 subapartado no quieren decir que no pueda haber plazo o lmite 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 duracin del proyecto, todo a la vez. Si el software tiene que funcionar en una fecha determinada y no se puede aumentar 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 programa son innegociables, se tendr que aumentar el nmero de programadores o analistas. Y esto no supone ninguna renuncia en relacin con los resultados que se alcanzaban hasta ahora, porque en la prctica muy pocos eran los proyectos en los que no se producan 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 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 prototipo del software. Un prototipo es un software provisional, construido con herramientas y tcnicas 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 usuarios puedan ver cmo sera el contenido o la apariencia de los resultados de algunas 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 comparacin, 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 comenzar un desarrollo segn el ciclo de vida en cascada, en este caso, no obstante, partiendo 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 vida iterativo e incremental, ya que slo 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 nmero 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 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 incremental, ya que el software est completo desde la primera versin. Como consecuencia de las numerosas modificaciones que sufre, la calidad del software desarrollado de esta manera y de su documentacin 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 ciclo 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 actividad 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 utilizacin; 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 generalmente 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 topdown) 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 denominados mtodos orientados a objetos ganan terreno rpidamente. Si los mtodos estructurados de desarrollo de software tienen su origen en la programacin 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 programar 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 desarrollo 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 principales 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 tcnicas nuevas, tambin aprovecha algunas tcnicas y conceptos del desarrollo estructurado, como el diagrama de estados y transiciones, segn veremos. Hay dos caractersticas del desarrollo orientado a objetos que probablemente han favorecido de m anera 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 software la reutilizacin de software en un grado significativo, en forma de clases implementadas, lo cual podra significar una va para solucionar, aunque slo sea en parte, los problemas de productividad y calidad descritos en apartados 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 ampliamente aceptada, el UML.

3.3. Los mtodos formales Los denominados mtodos formales parten de una especificacin de las necesidades de informacin en trminos de un modelo matemtico riguroso, del cual se podra deducir el programa que les satisfaga. Tambin permitan demostrar matemticamente que un programa es correcto en el sentido de que se ajusta a aquellas 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 complejidad 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 texto, 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 manual 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 informacin 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, reconocen que un determinado smbolo es una clase y no simplemente un rectngulo. 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, y LowerCASE, 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 utilizadas dentro del mismo mtodo estn integradas, en el sentido de que si hay un tipo de elemento que es comn a dos tcnicas, sea compartido por las dos herramientas respectivas, de manera que slo sea necesario describirlo una vez y que todos los cambios que se realicen despus en esta descripcin lleguen a las dos.

La expansin del uso de herramientas CASE en el mtodo estructurado se fren 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 situacin 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 distribuidos 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 distribuidos, 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 distintos 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, entre 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 Booch y Rumbaugh, trabajando en Rational Software Corporation, comenzaron la unificacin de los modelos respectivos, y en octubre de 1995 se public la versin provisional 0.8 del entonces denominado Unified Method. El mismo ao, Jacobson se incorpor con su empresa al equipo mencionado y a Rational 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 Proposa l, para un modelo de este tipo, y entonces Rational, para responderle, constituy un consorcio con otras organizaciones, con el resultado de que en enero de 1997 se present en la OMG la versin 1.0 del UML. Otras empresas que haban presentado tambin respuestas de manera independiente se aadieron al consorcio y se public la versin 1.1, que fue aceptada por el OMG en noviembre de 1997 (hubo otra propuesta, la del modelo OML, que tena y todava tiene un nmero importante de partidarios). El OMG encarg una revisin, cuyo resultado 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 modelo 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 desarrolladores de software orientado a objetos entendern y harn de la misma manera, lo cual supone un adelanto realmente importante con respecto a la situacin anterior en la que cada mtodo tena su notacin grfica; pero, incluso as, contina 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 intermedias 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 actuales en lo que se refiere a ciclos iterativos e incrementales, y el ciclo de vida clsico, 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 mtodos 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 esencial de esta obra utilizaremos los conceptos y la notacin del UML, se ha expuesto 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 mediante conceptos comunes. Slo para describirlos, los consideraremos agrupados en tres modelos:
Esttico Dinmico describe la estructura de clases y objetos. (o modelo de comportamiento), describe las interacciones entre los objetos dentro del software . describe la estructura del software en cuanto a los componentes de que consta y su ubicacin.

Implementacin

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.

Editorial UOC

38

Ingeniera del software

Ejemplo de modelo esttico Un diagrama esttico nos puede mostrar que cada profesor tiene, al menos, una asignatura, y que cada asignatura tiene, al menos, un profesor, pero no nos dice qu asignaturas tiene un profesor concreto.

Este modelo consta de los dos diagramas siguientes: Diagrama de clases, que puede contener clases y objetos y relaciones entre stos, 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 diagrama de clases con objetos concretos de las mismas. Un diagrama de clases muestra la estructura esttica de las clases en un dominio (porcin del mundo real considerada por una aplicacin); se muestran las clases y las relaciones entre stas, que pueden ser de herencia, asociacin, agregacin o uso.
Uso del modelo esttico El modelo esttico se utiliza en todas las etapas del ciclo de vida; en las diferentes etapas se documentan diferentes tipos de objetos. En el anlisis se consideran objetos del mundo 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 programacin, 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 queremos ahorrarnos muchos cambios cuando lleguemos al diseo. Tambin se deber tener en cuenta que, cuando el UML permite describir elementos incompatibles 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 distinguen entre los otros tres tipos de relaciones que existen; por tanto, al pasar del diseo a la programacin, estos tipos se tendrn que transformar.

Tambin puede suceder lo contrario; es decir, que se quieran modelar elementos 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 posibilidad, 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 instancias. 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 orientada 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 atributos 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 operaciones asociadas igual que las clases, pero sus instancias, a diferencia de los objetos, no tienen identidad. Interfaz: Una interfaz slo describe las operaciones de una clase que son visibles desde otras clases; se dice que dicha clase implementa la interfaz correspondiente.

Editorial UOC

40

Ingeniera del software

Estereotipo Un estereotipo de un elemento del UML es una variante ms restrictiva de dicho elemento; hay estereotipos que forman parte del UML, y tambin 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 estereotipos mencionados tienen mucho en comn, por lo que es suficiente con realizar 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 clasificadores, 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 paquete en 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 normalmente 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 algunos.

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 los elementos que contiene; la segunda, simplificada, es ms adecuada para representar referencias 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, adems, se pueden utilizar.
Ejemplo de relaciones entre paquetes En la representacin grfica, el paquete Diagramas que vemos a continuacin importa del 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 mismas 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 consiste 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 mtodo y servicio; pero en UML, el trmino servicio no se usa, y por mtodo se entiende la 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 estereotipo. Algunos estereotipos forman parte del UML como metaclass, del que se hablar 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 califique. 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 reutilizacin depende en gran medida de ello, porque cuando queramos reutilizar una clase de una librera que tenga centenares de nombres, la nica pista que tendremos es el nombre, y si no se le dio un nombre adecuado, ser muy difcil de encontrar. 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 slo con el compartimento del nombre En la figura siguiente, el estereotipo anlisis podra indicar que la clase Rectangulo se ha identificado en la etapa de anlisis.
*. 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

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 diseo 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 tambin 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 smbolos. 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 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 programacin; si algn lenguaje incluye ms tipos de visibilidad, tambin se podrn indicar aqu.

Editorial UOC

46

Ingeniera del software

En el lugar de los atributos, se pueden utilizar property strings, que son, respectivamente, public, protected o private. Las property strings son opcionales; adems de las mencionadas, podemos encontrar frozen, que indica que no se puede cambiar el valor del atributo. En lo referente al nombre de los atributos, se deben tener en cuenta las siguientes 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 programacin, 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 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

Captulo II. UML (I): el modelo esttico

extremos seran las coordenadas de dos vrtices opuestos del rectngulo, que lo determinan; Punto sera una clase descrita en el mismo paquete; gruesoLnea tiene el valor 1 por omisin, 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. 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 pensados, 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 sintaxis 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 parmetro formal; expresin-de-tipo depende del lenguaje; valor-por-omisin depende 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 operacin no modifica el estado del sistema, y para especificar la semntica de concurrencia 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 del estereotipo (no incluido dentro del UML) constructor y tiene dos parmetros in (por omisin); la operacin calculoArea no tiene parmetros pero retorna un valor, cuyo tipo se 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 superclase (se dice que la subclase los hereda) y, adems, pueden tener algunos adicionales, especficos de la subclase. Segn se defina primero la superclase o sus subclases, tenemos respectivamente dos tipos de herencia: herencia por especializacin y herencia por generalizacin.

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 especializada, 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 despus nos damos cuenta de que hay una categora especial de habitaciones que tiene atributos y/o operaciones diferentes, que son las suites ; esto se representa de la siguiente 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 habla de que hemos creado una jerarqua de herencia, muy sencilla en algunos casos (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 subclases 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 especializacin 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, encontramos, por un lado, los impuestos sobre las motos y por otro, los impuestos sobre los ciclomotores. Aunque inicialmente se haba considerado que Motos y Ciclomotores 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 encontrado 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 Habitacin, 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 independiente desde cada subclase a la superclase. La propiedad disjoint denota que todo objeto 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 estn 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 declaran 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 cambios 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 lenguajes 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 de un atributo o de un parmetro o del resultado de una operacin, el nmero de elementos 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 propiamente 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 generado una clase y hemos dado un valor a cada parmetro. La relacin entre la clase y 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, podemos definir una clase con el estereotipo utility, e incluir las rutinas como operaciones y los datos como atributos.
*. Las clases genricas en otros lenguajes. C++ y Eiffel soportan plenamente las clases genricas pero con algunas diferencias, mientras que en Java se tienen que simular con la clase Object.

Editorial UOC

54

Ingeniera del software

Puesto que esta clase no tendr objetos, aunque los atributos y operaciones se definan formalmente como atributos y operaciones de instancia, ser como si fuesen de clase y, por lo tanto, no se pueden definir ni operaciones ni atributos formalmente de clase.
Ejemplo de clase de utilidad La clase de utilidad Arranque rene diferentes elementos independientes relativos a la puesta en funcionamiento de un programa: dos parmetros y dos rutinas de inicializacin.

4.4. Interfaces

Una interfaz describe un conjunto de operaciones visibles de una clase, sin indicar su implementacin. Se dice que dicha clase en cuestin implementa la interfaz. Una interfaz no es una clase, pero equivale a una clase abstracta sin atributos y con todas sus operaciones diferidas. Las interfaces pueden establecer relaciones de herencia entre s, pero no pueden participar en asociaciones ni tener estados. Cada interfaz acostumbra a especificar slo una parte del comportamiento de una clase. Una clase puede implementar diferentes interfaces, si al menos una de stas no posee todas las operaciones visibles de la clase. En cambio, una interfaz slo es implementada por una clase. La notacin de la interfaz es como la de la clase pero con el estereotipo interfaz y sin el compartimento de atributos, porque no los tiene.

Editorial UOC

55

Captulo II. UML (I): el modelo esttico

Ejemplo de una interfaz con clase que la utiliza y otra que la implementa El siguiente ejemplo se ha inspirado en la librera de Eiffel:

La interfaz Comparable pretende declarar todas las operaciones que debern tener las clases que quieran permitir que dos de sus objetos se puedan comparar segn algn criterio de igualdad que slo se define dentro de la implementacin de la operacin esIgual dentro de la clase Cadena , que es la que implementa Comparable. La clase ClaseCliente utiliza la interfaz Comparable, en el sentido de que la implementacin de alguna operacin de ClaseCliente llama alguna operacin de Comparable. Prestad atencin a cmo es cada flecha! Una notacin equivalente ms abreviada del mismo ejemplo es sta:

Editorial UOC

56

Ingeniera del software

5. Representacin de los objetos

Un objeto se representa grficamente de una manera muy parecida a las clases; se indican los valores en los atributos de instancia y, opcionalmente, un nombre en el objeto, que va seguido de : y del nombre de la clase, todo subrayado. Se puede omitir el tipo de los atributos, as como el compartimento de las operaciones, porque los dos elementos ya se conocen gracias a la especificacin de la clase.

Tambin se puede representar la relacin, denominada instanciacin, entre un objeto y la clase a la cual pertenece.

Editorial UOC

57

Captulo II. UML (I): el modelo esttico

6. Relaciones entre clases

Sintcticamente, los lenguajes de programacin permiten slo dos tipos de relaciones entre clases: de herencia, que ya hemos visto, y cliente-servidor. Por relacin cliente-servidor se entiende que un objeto (el cliente) pida a otro (el servidor), mediante un mensaje, que ejecute una operacin de las definidas en la clase del servidor. En lo que respecta al anlisis y el diseo, se consideran otros tipos de relaciones, porque las relaciones cliente-servidor son demasiado simples para describir el mundo real.
Desacuerdo entre autores y el estndar de tipo relacin Lamentablemente, no existe acuerdo entre los autores ms importantes sobre cules son estos tipos (y menos todava sobre su semntica y notacin). Sin embargo, si el UML, convertido en estndar, se acaba imponiendo, es probable que su versin sea aceptada por todos o casi todos. No obstante, si el UML permite modelar grficamente diferentes tipos de relaciones entre clases (agregacin, asociacin y uso), el significado de cada uno no queda concretado en los documentos oficiales del OMG y, por lo tanto, la decisin sobre cundo se debe aplicar un tipo de relacin u otro ser a menudo una interpretacin personal.

6.1. Asociaciones Dentro de este subapartado veremos los conceptos y terminologa utilizados para designar las asociaciones y los diferentes tipos existentes.

6.1.1. Concepto y terminologa Hay una asociacin entre clases cuando una clase necesita otra u otras para la implementacin de sus operaciones, lo cual se cumple por medio del paso de mensajes entre stas. Una asociacin se define partiendo de la clase, y se concreta en la existencia de enlaces (en ingls, links) entre objetos concretos de las clases relacionadas por la asociacin.

Editorial UOC

58

Ingeniera del software

Dentro de una asociacin, se considera que cada clase desempea un papel (en ingls, role) determinado; cada papel tiene asociada una cardinalidad. Entre las mismas clases puede haber asociaciones diferentes con significado distinto. Una asociacin puede tener nombre, que sirve para identificar su significado, y tambin se puede dar un nombre a cada uno de los papeles de las clases.

6.1.2. Asociaciones binarias y n-arias

Asociaciones binarias son las que tienen lugar entre dos clases. Las dos clases pueden ser la misma (asociacin reflexiva), y en este caso es posible permitir que un objeto est enlazado consigo mismo o que no lo est. En una asociacin binaria, la cardinalidad de un papel A es el nmero de objetos del otro papel B al que puede estar enlazado cada objeto de A; se indica el valor mximo y mnimo de este nmero.
Ejemplos de asociaciones binaria y reflexiva 1) Asociacin binaria Como se puede apreciar en la siguiente asociacin binaria:

La asociacin significa que una persona trabaja en una empresa (no al revs, observad el sentido indicado por la punta de flecha coloreada); la empresa es la que ofrece el empleo y la persona desempea el papel de empleado. Cada persona concreta puede tener una empresa que ofrece el empleo o ninguna, mientras que una empresa puede tener un empleado como mnimo y cualquier nmero como mximo, segn indican las cardinalidades. La punta de flecha abierta encima de la lnea de la asociacin indica que se puede acceder (navegar) de una empresa hacia sus empleados.

Editorial UOC

59

Captulo II. UML (I): el modelo esttico

2) Asociacin reflexiva Consideremos la figura siguiente:

El significado de esta asociacin es que un trabajador depende de un jefe; tanto el jefe como el subordinado son trabajadores. Cada trabajador puede tener como mximo un jefe, mientras que un jefe puede tener cualquier nmero de subordinados (el asterisco solo indica que el nmero puede ser cualquiera, incluso el cero). Un trabajador no puede ser jefe de s mismo, pero eso no lo indica la notacin grfica.

Una relacin ternaria es aquella que tiene tres papeles, y en general una relacin n-aria es la que tiene n papeles. Las relaciones no binarias, ya que no se pueden representar mediante una lnea, se representan por medio de un rombo.
Ejemplo de asociacin ternaria Observemos la siguiente asociacin:

Un chfer determinado puede conducir un autocar determinado en cualquier nmero de excursiones (0..* es equivalente a *), pero en una excursin concreta, un chfer slo puede conducir un autocar, y en una excursin en particular, un autocar slo puede tener un chfer.

Editorial UOC

60

Ingeniera del software

El establecimiento de enlaces segn una asociacin El establecimiento de enlaces entre objetos segn una asociacin puede ser una operacin de alguna de las clases asociadas, igual que la navegacin de un objeto a otro enlazado a ste.

El significado de la cardinalidad en una asociacin ternaria es el siguiente: la cardinalidad del papel A expresa los lmites al nmero de objetos de A que pueden estar enlazados en cada combinacin concreta de un objeto del papel B y otro del papel C.

6.1.3. Clases asociativas

En principio, una asociacin no es una clase: no tiene por qu tener atributos ni operaciones, y puede carecer incluso de nombre. No obstante, si una asociacin debe tener atributos y operaciones propias o bien uno de los dos, entonces es preciso que se defina como clase. En este caso se habla de clase asociativa. Una clase asociativa se representa como una clase colgada del smbolo de la asociacin (la lnea, en el caso de una asociacin binaria, o el rombo en los otros casos) por medio de una lnea discontinua.
Ejemplo de clase asociativa binaria El caso que presentamos aqu es el mismo que el del ejemplo de asociacin binaria, excepto por el hecho de que aqu la asociacin tiene un atributo. Puesto que la asociacin ahora es una clase, se le ha aadido una operacin para crear instancias, y tambin se le ha cambiado el nombre por uno ms apropiado para una clase.

Editorial UOC

61

Captulo II. UML (I): el modelo esttico

6.1.4. Asociaciones calificadas

Veremos mejor este concepto si lo introducimos mediante un ejemplo. Consideremos una clase Departamento y otra Empleados, que tienen un atributo categora, y queremos establecer una asociacin separada entre el departamento y sus empleados para la categora A, la categora B, etc. Una forma de hacerlo es con una relacin ternaria, as:

Esta solucin es un poco forzada, porque obliga a convertir un atributo en una clase independiente, circunstancia que se puede evitar mediante una asociacin calificada en la cual el atributo calificador sea la categora del empleado. Esto se representa de la siguiente forma:

Este diagrama se puede interpretar de esta manera: cada empleado tiene un departamento, y dentro de un departamento tiene que haber al menos un empleado de cada categora (mientras que si tuviramos una asociacin binaria or-

Editorial UOC

62

Ingeniera del software

dinaria, prescindiendo de la categora, cualquier departamento tendra al menos un empleado, de una categora u otra).

6.1.5. Asociaciones alternativas

Puede ocurrir que en una clase que participe en dos asociaciones, cada objeto concreto participe en una o en la otra, pero no en las dos. Entonces se habla de asociaciones alternativas.
Ejemplo de asociaciones binarias alternativas Una forma de representar las asociaciones binarias alternativas se puede apreciar en la figura:

Un servicio determinado puede ser prestado por un proveedor autnomo o bien por una empresa, pero nunca por uno y otra a la vez. Esto tambin se podra describir as:

Editorial UOC

63

Captulo II. UML (I): el modelo esttico

6.1.6. Asociaciones derivadas Una asociacin derivada es una asociacin redundante que se puede obtener como combinacin de otras relaciones del modelo.
Ejemplo de asociacin derivada En la figura representamos la siguiente asociacin derivada:

donde alumnos del curso es una asociacin derivada, porque los alumnos de un curso se pueden determinar recorriendo las asignaturas del curso y encontrando a los alumnos de cada una. Sin embargo, tambin podra ocurrir que esta relacin se definiese de una manera no redundante, por ejemplo, que comprendiese a los alumnos que estuviesen matriculados slo en asignaturas de dicho curso. Entonces no se pondra /, que es el indicador de elemento derivado, como hemos visto al hablar de los atributos derivados en el subapartado 5.1.2.

6.2. Agregaciones y composiciones

En este subapartado consideramos las agregaciones y las composiciones.

6.2.1. Agregaciones

Una agregacin es un caso particular de asociacin binaria en la cual uno de los papeles tiene el significado de parte y el otro el de todo, en algn sentido.

Editorial UOC

64

Ingeniera del software

Denominaremos componentes a la clase correspondiente al primer papel y a sus objetos, y clase y objetos agregados, a los del segundo papel. Se dice que una agregacin es una relacin is-part-of. Las agregaciones pueden tener diferentes significados: Acoplamiento-piezas. Una mquina y sus piezas, un circuito elctrico y sus componentes, un sistema de software y sus programas; cada parte tiene un papel concreto y no se puede cambiar por ninguna otra. Continente-contenido. Un avin y los pasajeros que transporta, que no constituyen el avin, ya que un avin sin pasajeros es por s solo un avin. Colectivo-miembros. Un grupo excursionista y sus excursionistas, o bien una promocin de alumnos y dichos alumnos; se supone que los miembros no tienen papeles diferenciados y, por tanto, son intercambiables. Un objeto compuesto puede tener objetos componentes que pertenecen a diferentes clases o, dicho de otra forma, una clase puede tener relaciones de agregacin con otras diferentes. Una clase puede desempear el papel de clase compuesta en una agregacin y el de clase componente en otra, y tambin es capaz de realizar los dos papeles en la misma agregacin (aunque un objeto no puede ser componente de s mismo). Entre dos clases puede haber ms de una agregacin.
Ejemplo de agregaciones A continuacin se representa la composicin clsica de un equipo de ftbol:

Cada jugador juega en un equipo (el del club al que pertenece) o en ninguno, y un jugador slo puede estar en una de las cuatro posiciones, como indica {or}. Se supone

Editorial UOC

65

Captulo II. UML (I): el modelo esttico

que las de defensa, por ejemplo, son intercambiables entre s, o de otro modo habra once agregaciones diferentes. El rombo vaco en la parte de la clase compuesta u objeto compuesto denota que se trata de una agregacin.

6.2.2. Composiciones y objetos compuestos

La composicin (o agregacin de composicin) es un caso particular de la agregacin. En una composicin, los objetos componentes no tienen vida propia sino que, cuando se destruye el objeto compuesto del que forman parte, tambin se destruyen. Adems, un objeto componente slo puede formar parte de un objeto compuesto y no puede pasar de un objeto compuesto a otro. Estas restricciones no existen en el caso de agregaciones en general. En el ejemplo de agregaciones que hemos visto antes, los jugadores pueden pasar de un equipo a otro y existen por s mismos incluso cuando no estn en ningn equipo. Por tanto, las agregaciones en cuestin no son composiciones. En una composicin denominaremos a la clase agregada clase compuesta, y al objeto agregado, objeto compuesto.
Ejemplos de composicin y de objeto compuesto 1) Ejemplo de composicin Consideremos la composicin siguiente:

Un centro universitario (facultad, etc.) pertenece a una sola universidad (de hecho, por la parte de la clase compuesta, la cardinalidad en una composicin es siempre 1).

Editorial UOC

66

Ingeniera del software

Una universidad debe tener, al menos, un centro universitario. Suponemos que si desaparece una universidad desaparecen tambin sus centros universitarios, y que stos no se trasladan de una universidad a otra. 2) Ejemplo de objeto compuesto Puesto que en una composicin cada objeto componente slo puede pertenecer a un nico objeto compuesto, podemos representar los objetos componentes dentro del objeto compuesto en un compartimento especial.

6.3. Relaciones de dependencia

Una relacin de dependencia expresa que un elemento del modelo denominado cliente depende para su implementacin o funcionamiento de otro elemento denominado suministrador (en ingls, supplier). El smbolo de una relacin de dependencia es una flecha de lnea discontinua y punta abierta. Existen diferentes estereotipos estndar, alguno de los cuales ya hemos visto, y se pueden definir otros ms: derive: significa que un elemento se obtiene de otro por medio de un clculo o algoritmo; friend: da acceso al cliente a los elementos de visibilidad private contenidos en el suministrador; refine: quiere decir que el cliente procede histricamente del suministrador, del cual es una versin nueva o enriquecida (por ejemplo, una clase descrita en el anlisis en el que se realizan cambios en el diseo);

Editorial UOC

67

Captulo II. UML (I): el modelo esttico

trace: relaciona elementos que corresponden desde un punto de vista semntico al mismo concepto, como por ejemplo un elemento y su implementacin; call, create y send; extend e include: que existen slo entre casos de uso.

7. Comentarios y restricciones

7.1. Comentarios

Un comentario se pone dentro de un rectngulo con un vrtice doblado, enlazado con un lnea discontinua al elemento al cual se refiere.

7.2. Restricciones

Las restricciones (en ingls, constraints), expresan condiciones que debe cumplir el elemento del modelo al cual se asocian. Se representan del mismo modo que los comentarios, salvo que van entre llaves {}, lo cual indica que pueden ser interpretadas por las herramientas CASE. Las especificaciones del UML incluyen un lenguaje para la descripcin de las restricciones, denominado OCL. No obstante, se puede utilizar el UML sin usar este lenguaje. OCL es la sigla de Object Constraint Language .

Editorial UOC

68

Ingeniera del software

7.2.1. Las restricciones de las operaciones: la programacin por contrato

En el UML hay tres tipos de restricciones relativas a las operaciones: precondiciones, postcondiciones e invariantes. Las precondiciones son restricciones que se deben cumplir antes de ejecutar una operacin. Su cumplimiento nos garantiza que la operacin se ejecuta partiendo de un estado correcto del sistema. Las postcondiciones se comprueban al acabar la ejecucin de una operacin, y garantizan que cuando est terminada la operacin, el sistema vuelva a situarse en un estado correcto. Las invariantes son condiciones que se deben cumplir en todo momento. Se tienen que comprobar al inicio de cualquier operacin excepto los constructores y al acabar. Las restricciones pueden servir para disear con vistas a hacer programacin por contrato, que se basa en unas condiciones sobre operaciones y objetos denominadas aserciones, las cuales se pueden expresar en forma de restricciones del UML.

Editorial UOC

69

Captulo II. UML (I): el modelo esttico

Conclusiones

En este captulo hemos estudiado el modelo esttico del UML. Se han descrito los diferentes elementos del modelo, y de cada uno se ha descrito la notacin. Estos conceptos son los siguientes: Las clases, con sus variantes (clases abstractas, metaclases y otras) y conceptos relacionados con la clase (clasificador, interfaz, plantilla) y la herencia. Las relaciones entre clases (asociaciones, agregaciones, relaciones de dependencia). Los comentarios y las restricciones.

Editorial UOC

71

Captulo III. UML (II): el modelo...

Captulo III

UML (II): el modelo dinmico y de implementacin

Hemos visto que el modelo esttico del UML consiste esencialmente en un nico diagrama, el de clases, que se tiene que elaborar en todo proyecto de software. El modelo dinmico y de implementacin, en cambio, comprende diferentes diagramas, en parte relacionados entre s y tambin con el diagrama esttico. Algunos de estos diagramas slo se utilizan en determinados casos. Los aspectos dinmicos o de comportamiento del sistema se pueden modelar con los siguientes diagramas: el diagrama de casos de uso, el diagrama de estados y transiciones, el diagrama de actividad y los diagramas de interaccin, que son el de secuencias y el de colaboracin. La implementacin se puede modelar con el diagrama de componentes y el de despliegue.

1. El diagrama de estados

A veces hay objetos cuyo comportamiento puede variar a lo largo del tiempo; cuando esto sucede, se dice que el objeto tiene estados. Existen algunos tipos de aplicaciones, como las de tiempo real, para las cuales el modelado de estados es especialmente importante.
Informacin redundante, pero aclaratoria... La informacin que contiene el diagrama de estados es esencialmente redundante, ya que los cambios de estado son resultado de la dinmica del sistema y, por tanto, de la ejecucin de las operaciones de la misma clase o de otras. No obstante, aun as, re-

Editorial UOC

72

Ingeniera del software

presenta otro punto de vista sobre la dinmica de una parte del sistema que puede contribuir decisivamente a comprenderla mejor.

En el diagrama de estados o diagrama dinmico tenemos que distinguir los siguientes elementos: Las diferentes situaciones en que se puede encontrar un objeto (los estados). Qu cambios de estado son posibles (transiciones). Cul es el hecho que los produce (acontecimientos). En las especificaciones del UML se habla de mquinas de estados para distinguiras de los diagramas de estado clsicos o de Harel, con los cuales existen diferencias. Sin embargo, nosotros utilizaremos el trmino diagrama de estados porque siempre representamos las mquinas de estado en forma de diagrama. No puede haber ninguna confusin, ya que en esta asignatura no se tratarn los diagramas de Harel.
Ejemplos de estados Hay objetos a los cuales no se puede pedir alguna de sus operaciones en cualquier momento, u objetos para los que alguno de sus atributos slo puede tener un valor no nulo en circunstancias determinadas.

El diagrama de estados se utiliza normalmente para describir objetos del dominio del usuario y se documenta por lo general en la etapa de anlisis.

1.1. Conceptos bsicos

A continuacin explicaremos una serie de conceptos bsicos: 1) Un estado es una situacin determinada dentro de la vida de un objeto o la duracin de una interaccin durante la cual cumple alguna condicin, lleva a cabo alguna accin o espera que se produzca un acontecimiento. Un estado no corresponde a un instante en el tiempo, sino que el objeto o interaccin permanece en ste un tiempo finito.

Editorial UOC

73

Captulo III. UML (II): el modelo...

2) Una transicin simple consiste en que el objeto o interaccin pasa de un estado (estado de origen) a otro (estado de destino), que podra volver a ser el mismo. En el caso ms general, este paso comienza cuando se produce un acontecimiento determinado y al mismo tiempo se cumple una condicin especificada (condicin de guarda). Entonces se pueden ejecutar unas acciones y se pueden enviar mensajes a objetos individuales o a conjuntos de objetos. Un estado puede tener transiciones de llegada, una de las cuales ser el estado de destino, y transiciones de salida, una de las cuales ser el estado de origen. 3) Las transiciones internas* son seudotransacciones en las cuales no hay cambio de estado. Sirven para especificar acciones que se deben ejecutar en respuesta a un acontecimiento que no provoca ningn cambio de estado en el objeto o interaccin en cuestin. 4) Una accin es la especificacin de un proceso atmico, es decir, que o no se ejecuta o se ejecuta hasta el final. Como consecuencia de una transicin, se puede ejecutar una accin o ms. Es posible describir una accin mediante un procedimiento o una mquina de estados. 5) Los objetos, por medio de mensajes, pueden recibir peticiones de operaciones o seales. Las seales, a diferencia de las operaciones, no realizan ningn proceso, y el nico efecto directo que pueden tener es producir acontecimientos (que s pueden provocar transiciones y la consiguiente ejecucin de acciones). 6) Los acontecimientos (en ingls, events) son hechos que, cuando se producen, pueden provocar transiciones de un estado a otro en objetos e interacciones y/o la ejecucin de determinadas acciones. Un acontecimiento no est vinculado a ningn objeto o clase en particular, sino que es un hecho que puede afectar en general a los elementos del paquete en cuyo interior est definido. Cada acontecimiento posee un nombre que lo identifica dentro del paquete, y puede tener parmetros. Normalmente, un acontecimiento se tiene que tratar en el momento en que se produce. En caso contrario, se provoca la transicin porque el objeto o interaccin no est en el estado correspondiente: se pierde el acontecimiento a no ser que se declare como acontecimiento diferido.
*. Conviene no confundir una transicin interna con una a-totransicin, que es una transicin ordinaria en la cual el estado de origen y el estado de destino son el mismo.

Editorial UOC

74

Ingeniera del software

Tipos de acontecimientos Ahora veremos diferentes tipos de acontecimiento: De llamada. Se producen cuando se llama una operacin del objeto al que corresponde el diagrama. De seal. Representan la recepcin de una seal por el objeto a la que corresponde el diagrama. De cambio. Representan una notificacin de que una condicin ha llegado a ser cierta. Esta condicin no se tiene que confundir con condicin de guarda, ya que una guarda se evala una vez se ha presentado el acontecimiento correspondiente a una transicin para determinar si se provoca la transicin o no, mientras que esta condicin produce el acontecimiento cuando ha llegado a ser cierta. De tiempo. Representan la notificacin de que o ha pasado un periodo de tiempo desde que se ha producido un acontecimiento determinado (por ejemplo, que se ha entrado en el estado de origen de la transicin), o de que es una hora determinada. Acontecimientos internos Son seudoacontecimientos, ya que estn vinculados a un estado en lugar de a una transicin, y sirven para poner en marcha acciones que no van asociadas a ningn cambio de estado concreto. Existen tres tipos de acontecimientos internos: 1) De entrada. Se producen cuando el objeto entra en el estado correspondiente. No tienen ni guarda ni parmetros, porque se nombrarn implcitamente cuando haya una transicin de entrada en el estado (incluida una autotransicin), pero no cuando haya una transicin interna, ya que entonces no se producir un cambio de estado. Se especifican explcitamente y tienen como nombre la palabra clave entry. 2) De salida. Son anlogos a los de entrada, salvo que se producen a la salida del estado. Se especifican explcitamente y tienen como nombre la palabra clave exit. 3) De accin. Especifican acciones que se ejecutan cuando se llega al estado en cuestin y acaban por s mismas o cuando se sale del estado. Se especifican explcitamente y tienen como nombre la palabra clave do.

1.2. Notaciones bsicas

La representacin ms sencilla de un estado es un rectngulo con los vrtices redondeados, tal y como podemos observar en la siguiente figura:

Editorial UOC

75

Captulo III. UML (II): el modelo...

En la prctica, es imprescindible que cada estado tenga un nombre y que este nombre no se repita en ningn otro estado del mismo diagrama. Este hecho no impide que el objeto o interaccin pueda llegar al mismo estado varias veces a lo largo de su vida. Las transiciones se representan mediante flechas de punta coloreada que van del estado de salida al de llegada. Con la flecha se encuentra una expresin (denominada cadena de la transicin) que presenta la siguiente sintaxis formal: signatura [ guarda ] / accin ^ envo Puede haber varias acciones o envos o no haber ninguno, y pueden estar mezclados. El orden en que aparecen es en el que se deben ejecutar. A continuacin veremos una explicacin de cada uno de los elementos de la cadena de transicin: Signatura. Tiene un formato que depende del tipo de acontecimiento. En el caso de un acontecimiento de llamada o de seal, se define as: nombre_acontecimiento ( nombre_parmetro : expresin_tipo , ... ) Si el acontecimiento es de tiempo, la signatura adopta una de estas formas: after( expresin_de_tiempo ) donde expresin_de_tiempo consiste en una duracin a partir de un origen, o: when( hora o fecha ) Finalmente, si el acontecimiento es de cambio, tendremos lo siguiente: when( expresin_booleana )
Nota terminolgica Respecto al uso de trminos parmetro y argumento en relacin con una llamada, hay que tener presente que parmetro corresponde al punto de vista de lo que se llama, y argumento, al punto de vista de lo que hace la llamada.

Editorial UOC

76

Ingeniera del software

Guarda. Es una expresin que puede tomar el valor verdadero o falso, escrita en seudocdigo o en el lenguaje de programacin que se utiliza. Accin. Es la especificacin de una accin, en seudocdigo o en el lenguaje de programacin que se usa. En el caso de un acontecimiento diferido, debe aparecer la palabra clave defer como primera accin. Envo. Este elemento presenta la forma siguiente: destino . mensaje ( argumento , ... ) en el que destino tiene que identificar un objeto o grupo de objetos y mensaje puede ser una operacin del objeto de destino o una seal. Las seales se pueden definir como clases con el estereotipo signal. No tienen operaciones, y en el compartimento de los atributos tienen los parmetros de la seal. Pueden constituir jerarquas de herencia, pero no les es posible establecer relaciones de ningn tipo con clases. Las seales a las cuales deben ser sensibles los objetos de una clase se pueden especificar en un compartimento adicional del smbolo de la clase.
Ejemplos de diagramas de estado En los ejemplos siguientes veremos diagramas de estados con transiciones, estados, acontecimientos, autotransicin, etc. 1) Ejemplo de estados, transiciones y acontecimientos Este diagrama corresponde a una clase de facturas, cuyo nombre no aparece:

Editorial UOC

77

Captulo III. UML (II): el modelo...

Todo comienza cuando llega una factura, hecho que describimos como el acontecimiento llegada, que tiene como parmetro la fecha. Este acontecimiento pide la operacin constructor de dicha clase en relacin con un objeto de la clase que es la factura llegada (identificada por factura) y provoca la transicin hacia el estado Recibida ; fecha, y proveedor son parmetros de constructor. Despus, la factura es verificada (esto no aparece explcitamente), lo cual puede dar como resultado dos acontecimientos alternativos: aceptacin que pide la operacin aceptar y provoca la transicin hacia el estado Aceptada, y error que pide, a su vez, la operacin retorno y provoca la transicin al estado Devuelta. Si la factura est en el estado Aceptada y se produce el acontecimiento pago, la factura pasa al estado Final y se pide la ejecucin de la operacin pagar en relacin con dicha factura. Si la factura est en el estado Devuelta, la transicin hacia el estado Final es provocada por un acontecimiento de tiempo que consiste en que hayan pasado tres das (puesto que no se especifica desde cundo, se entiende que es desde la entrada en el estado de origen), y entonces se pide la operacin borrar. 2) Ejemplo de autotransicin, accin y guarda El diagrama siguiente representa parte del diagrama de estados de los objetos de una clase de libros de una biblioteca pblica:

Cuando un lector tiene un libro en prstamo, puede pedir renovaciones, que se le concedern si otro lector no lo ha reservado. Los efectos del acontecimiento peticion_renovacion son la autotransicin, la llamada a la operacin renovacion y la ejecucin de la accin estadisticas. 3) Ejemplo de acontecimiento de seal Un lector tiene un libro en prstamo. Cuando lo devuelve, si otro lector lo ha reservado, se enva un mensaje al objeto reserva con la seal devuelta, que debe estar definida dentro del compartimento de seales de la clase a la cual pertenece reserva .

Editorial UOC

78

Ingeniera del software

1.3. Transiciones complejas

Un objeto o interaccin puede estar en ms de un estado al mismo tiempo, y puede haber transiciones que salgan de ms de uno o que vayan a parar a ms de uno, o ambas cosas a la vez. Son las denominadas transiciones complejas. Una transicin compleja con varios estados de origen slo tiene lugar si el objeto o interaccin est en todos estos al mismo tiempo y, adems, se produce el acontecimiento correspondiente a la transicin (y se cumple la guarda, si la hay) y, por tanto, realiza una funcin de sincronizacin. Por analoga, cuando se produce una transicin compleja con varios estados de destino, el objeto o interaccin pasa a todos estos estados a la vez. Una transicin compleja se representa utilizando un seudoestado* intermedio, al que van a parar varias transiciones (seudoestado de sincronizacin, join pseudo-state) o del que salen varias (seudoestado de bifurcacin, fork pseudostate), o ambas circunstancias al mismo tiempo. Este tipo de seudoestado se representa por medio de una barra vertical corta y gruesa que es origen y destino de transiciones en las cuales se descompone la transicin compuesta.
Ejemplo de transiciones complejas Considerad las siguientes transiciones complejas:

*. Seudoestado. Un seudoestado es un smbolo que figura en una posicin del diagrama donde normalmente habra un estado, y no representa ningn concepto, sino que tiene una funcin puramente grfica.

Editorial UOC

79

Captulo III. UML (II): el modelo...

Cuando llega una factura de una compra de material, pasa a estar pendiente de la verificacin mediante la comparacin con el pedido (V1) y con lo que se ha recibido (V2), por medio de una transicin compleja de bifurcacin. Si de cada verificacin resulta una conformidad (acontecimientos OK1 y OK2), se pasa al estado Revisado1 y Revisado2, respectivamente. Cuando llega el da 30, se paga la factura slo si estaba al mismo tiempo en estos dos estados, por medio de una transicin compleja de sincronizacin.

1.4. Estados compuestos

Hemos visto que mientras un objeto o interaccin permanece en un estado, se encuentra en una situacin determinada. Sin embargo, a veces esta situacin es genrica, y mientras permanece en ella y slo en este caso, puede estar en diferentes momentos en lo que podramos considerar variantes o matices de la situacin genrica. Una situacin genrica como sta se representa mediante un estado compuesto, en el que hay varios subestados posibles, cada uno de los cuales puede ser un estado compuesto a su vez o no. Los estados no compuestos todos los que hemos considerado hasta el momento se denominan estados simples. A un estado compuesto le corresponde un diagrama de subestados. Los subestados de un estado pueden ser concurrentes (es decir, que se pueden presentar de forma simultnea), o secuenciales (incompatibles entre s). En el caso ms general, el diagrama de subestados consta de varias secuencias de subestados en paralelo. Cada secuencia comienza en un seudoestado inicial y acaba en un seudoestado final. Un estado compuesto est representado por el mismo smbolo que un estado simple, pero en su interior habr al menos dos compartimentos separados por una lnea: arriba el del nombre y abajo el que contiene su diagrama de subestados. Cada secuencia de subestados ocupar una franja horizontal separada de las franjas adyacentes por una lnea discontinua. Un subestado inicial se representa con un crculo lleno, y uno final con un crculo lleno envuelto en una circunferencia. Las transiciones entre subestados de la misma secuencia se representan igual que entre estados. Las transiciones entre estados que pertenecen a secuencias diferentes usan seudoestados de sincronizacin de la manera que veremos en el ejemplo correspondiente.

Editorial UOC

80

Ingeniera del software

Existen varios tipos de transiciones que tienen por estado de origen o de destino un objeto compuesto: Transiciones que entran directamente en un subestado o salen del mismo. Transiciones que entran o salen del estado compuesto, considerado como una unidad. Si entra, es como si la transicin tuviera como estados de destino los estados iniciales de todas las secuencias, mientras que si sale, es como si la transicin tuviera como estados de origen los estados finales de todas las secuencias. Transiciones que tienen como destino un indicador de historia de los estados, el cual es un seudoestado que indica que en una transicin de regreso al estado compuesto se vuelve, dentro de ste, al mismo subestado (dentro de la secuencia contenida en la misma franja que dicho indicador de historia) del que sali la ltima vez que parti del estado compuesto. Si el subestado puede ser un estado compuesto, hay una opcin que indica que se vuelva tambin a un subestado de ste, seleccionado de la misma forma, y esto para tantos niveles de subestados como haya. Del indicador de historia puede salir una transicin hacia un subestado que ser el de destino, en el caso de que la transicin tenga lugar sin que anteriormente hubiera estado ninguna vez en el estado compuesto. Vase el segundo ejemplo a continuacin. Transiciones stubbed. Estas transiciones tienen como estado de destino (origen) algn subestado de un estado compuesto del que no se especifica el diagrama de subestados. Dicho subestado no puede ser inicial (final), ya que, en el caso contrario, podramos tener como estado de destino (origen) el estado compuesto, segn se ha explicado anteriormente.
Ejemplos de transiciones que tienen por estado de origen o destino un estado compuesto Ahora veremos tres ejemplos de estas transiciones: 1) Ejemplo de estado compuesto Este ejemplo describe el mismo caso que el ejemplo de transiciones complejas, pero esta vez, por medio de un estado compuesto (de nombre EnVerificacion). Este estado no tiene compartimento de transiciones internas.

Editorial UOC

81

Captulo III. UML (II): el modelo...

2) Ejemplo de transiciones con subestados, indicador de historia y seudoestado de sincronizacin Observemos la figura siguiente:

Desde el estado Est1 se va al estado compuesto Est2 en general (es decir, a todos sus estados iniciales a la vez) si se produce el acontecimiento ev1 y se cumple la guarda g1. En cambio, si con el mismo acontecimiento se cumple la guarda g2, entonces se pasa al subestado de Est2, donde se estaba antes de salir de Est2 (observad que se puede haber salido tanto desde Sub1 como desde Sub3) si es que se haba estado alguna vez en el mismo, y si no se pasa a Sub 1. Si Sub1 o Sub3 tuvieran subestados, se ira al subestado de stos en el que se estaba cuando se sali de Est2 por ltima vez (esto lo indica el hecho de que la H del indicador de historia vaya acompaada de un asterisco). Se puede pasar de Sub1 a Sub4 que pertenece a otra secuencia por medio de un seudoestado de sincronizacin y una transicin compleja de sincronizacin. El asterisco dentro del smbolo del estado de sincronizacin denota que no hay lmite mximo en el nmero de veces que se puede disparar la transicin hacia Sub4 como

Editorial UOC

82

Ingeniera del software

consecuencia de que se produce repetidamente ev6 mientras se est ininterrumpidamente en Sub1 (si hubiera un valor mximo, se pondra en lugar del asterisco). Del estado Est4 se pasa directamente al subestado Sub2. 3) Ejemplo de transiciones stubbed Este ejemplo describe el mismo caso que el ejemplo anterior, pero ahora las transiciones que entran y salen de subestados no especifican de cules. Sin embargo, las transiciones que entran y salen del estado compuesto en su conjunto se indican de la misma forma que antes.

1.5. Notacin ampliada del estado

Igual que la clase, el estado tiene dos representaciones grficas: una que slo tiene el nombre, que es la que hemos utilizado hasta el momento, y otra con varios compartimentos. Los compartimentos son los siguientes: Compartimento del nombre, que contiene slo el nombre del estado. Compartimento de las transiciones internas y los acontecimientos internos. Contiene una lista de las cadenas de los acontecimientos y seudoacontecimientos correspondientes. En el caso de los seudoacontecimientos entry y exit, no puede haber ni condiciones de guarda ni parmetros. Compartimento del diagrama de subestados, que ya hemos visto, en el caso de estados compuestos.

Editorial UOC

83

Captulo III. UML (II): el modelo...

2. El diagrama de casos de uso


Los diagramas de casos de uso (en ingls, use case) sirven para mostrar las funciones de un sistema de software desde el punto de vista de sus interacciones con el exterior y sin entrar ni en la descripcin detallada ni en la implementacin de estas funciones. Los casos de uso se utilizarn tanto en la recogida y documentacin de requisitos como en el anlisis.

2.1. Actores

La finalidad de un software es proporcionar informacin a personas, mquinas y dispositivos o software del exterior, cuyo conjunto denominaremos entidades exteriores. Tambin hay entidades exteriores las mismas u otras que piden funciones al software o le suministran informacin para que la trate. Un actor es un conjunto de papeles de una entidad exterior en relacin con el sistema de software considerado. Por tanto, un actor no es la entidad exterior en s, sino slo los aspectos que tienen que ver con su interrelacin con el sistema de software; podramos decir que un actor es la visin que el software tiene de una entidad exterior. Desde este punto de vista, un actor es un conjunto de papeles, ya que se considera que el actor desempea un papel diferente en cada interaccin (cada caso de uso, en el UML) que tiene con el software. Adems, si una entidad exterior forma dos conjuntos de papeles con poca relacin entre s, le correspondern dos actores diferentes (se podra decir que, en este caso, el software no puede saber si los dos actores son o no la misma entidad exterior). A menudo hay discusiones sobre si una entidad exterior en particular es o no un actor en relacin con un software. Nosotros consideraremos que para ser actor, una entidad exterior tiene que cumplir estas dos condiciones: 1) Ser autnoma con respecto al software, es decir, que la actividad en que utiliza la informacin suministrada por el software no est subordinada a la de ste.

Editorial UOC

84

Ingeniera del software

2) Mantener relacin directa con el software o con entidades exteriores que desempean tareas subordinadas a la actividad del software.
Ejemplos de actores Algunos ejemplos nos ayudarn a aclarar el concepto de actor aplicando las reglas que acabamos de indicar. Un motor elctrico que es puesto en marcha o parado por un software de tiempo real es un actor, ya que su actividad es autnoma (su rotacin sirve para accionar algn dispositivo mecnico), mientras que una impresora no tiene actividad autnoma porque se limita a imprimir la informacin que le enva un sistema de software (o varios) y, por tanto, su actividad est subordinada a la generacin de listados por parte del software. Si la persona A recoge un listado de la impresora y lo entrega a una persona B que hace un resumen manual de la informacin y lo da a otra persona C, slo B ser actor, ya que A no tiene una actividad autnoma y C no recibe la informacin directamente del software y, por tanto, el software no conoce su existencia. Naturalmente, si A tuviera alguna actividad autnoma sin ninguna relacin con el software por ejemplo, barrer la oficina no por este motivo sera actor del software.

Un actor es un clasificador (pero a pesar de esto, no es ningn estereotipo estndar del clasificador). Si hay varias entidades exteriores que desempean el mismo conjunto de papeles en relacin con el software , un nico actor las representa todas, de igual manera que una clase representa todos sus objetos posibles (o, dicho de otra forma, estas entidades exteriores seran instancias del actor).
El ejemplo de los bibliotecarios (I) Si en una biblioteca pblica todos los bibliotecarios pueden utilizar las mismas funciones del software de apoyo a la gestin de la biblioteca, definiremos un nico actor para todos. Sin embargo, si hay un bibliotecario que puede realizar algunas funciones que los dems no pueden (como variar la duracin de los prstamos), estas funciones se asignaran a otro actor. Hay dos maneras de hacerlo; podis leer, unas lneas ms abajo, la segunda parte de este ejemplo.

Entre actores, es posible establecer relaciones de especializacin/generalizacin con herencia, igual que entre clases. Un actor A que es una especializacin de otro B realiza como mnimo todos los papeles de B.

Editorial UOC

85

Captulo III. UML (II): el modelo...

Caso especial... Si un proceso se tiene que poner en funcionamiento, automticamente o no, en una fecha y/o hora determinada, se considera que hay un actor ficticio, por ejemplo Reloj, que desempea este papel. El ejemplo de los bibliotecarios (II) En el ejemplo de los bibliotecarios, el hecho de que haya algunos de ellos (digamos, los jefes de biblioteca) que pueden efectuar todas las funciones (casos de uso, recordmoslo) que desempean los dems, ms otras propias, hace que sea posible definir un actor Bibliotecario y otro JefeDeBiblioteca, y este ltimo heredar de aqul. Sin embargo, esto mismo se podra expresar de otra forma: haciendo que el actor JefeDeBiblioteca slo comprendiera los papeles que tienen los jefes de biblioteca y no tienen los dems bibliotecarios. En este caso, evidentemente, no habra herencia, y a los jefes de biblioteca corresponderan dos actores, Bibliotecario y JefeDeBiblioteca.

2.2. Concepto de caso de uso

Un caso de uso documenta una interaccin entre el software y un actor o ms. Dicha interaccin tiene que ser, en principio, una funcin autnoma dentro del software.
Caso especial Si un proceso se tiene que poner en funcionamiento, automticamente o no, en una fecha y/o hora determinada, se considera que hay un actor ficticio, por ejemplo Reloj, que desempea este papel .

Entre los actores que participan en un caso de uso, conviene distinguir el actor primario del caso de uso, que es el que lo pone en funcionamiento pidiendo la funcin correspondiente del software. Los casos de uso son un caso particular de los clasificadores; una instancia de un caso de uso es una ejecucin de ste con intervencin de casos particulares de los actores involucrados. Los casos de uso pueden tener atributos y operaciones que pueden servir para describir el proceso (que tambin es posible describir de otras maneras, como texto ordinario y diagramas de estados y de actividad).

Editorial UOC

86

Ingeniera del software

Se pueden hacer descripciones ms formales y detalladas de los casos de uso durante el anlisis, as como de su implementacin suprimir por medio de diagramas de colaboracin o de secuencias.

Entre los casos de uso y los actores que intervienen se establecen asociaciones (lo cual no tiene nada de especial, ya que unos y otros son clasificadores). El significado de estas asociaciones es el papel del actor en relacin con el caso de uso, pero no representan ni la direccin ni el contenido de un eventual flujo de datos entre el software y el actor.

2.3. Relaciones entre casos de uso

Entre los casos de uso se pueden establecer tres tipos de relacin: 1) Relaciones de extensin. Se dice que el caso de uso A extiende el B si dentro de B se ejecuta A cuando se cumple una condicin determinada. A tiene que ser un caso de uso que tambin se pueda ejecutar de forma separada de B, y debe tener el mismo actor primario que ste. 2) Relaciones de inclusin. Un caso de uso A est incluido dentro de los casos de uso B, C, etc., si es una parte de proceso comn a todos stos. A no es un caso de uso autnomo, en el sentido de que no tendr actor primario, sino que siempre ser puesto en funcionamiento por uno u otro de los casos de uso que lo incluyen. No obstante, su implementacin no puede depender de stos (Por ejemplo, no puede utilizar sus variables). Por tanto, la inclusin de casos de uso es esencialmente una forma de reutilizacin. 3) Relaciones de generalizacin/explotacin. Un caso de uso A es una especializacin de otro caso de uso B si A realiza todo el proceso de B, ms algn proceso especfico. Adems, hay una forma de relacin no tipificada (parecida a las agregaciones entre clases) entre casos de uso que consiste en definir, por ejemplo, un caso de uso que corresponde a todo el sistema, otros que corresponden a todos sus subsistemas, etc.

Editorial UOC

87

Captulo III. UML (II): el modelo...

2.4. Notacin Tanto para los casos de uso como para los actores, no se utiliza el smbolo de los clasificadores, sino smbolos especiales como los siguientes: Los casos de uso se representan mediante elipses de trazo continuo. A veces se agrupan todas las elipses dentro de un rectngulo que representa todo el software. Los actores se representan mediante una figura humana esquemtica. Las relaciones de especializacin entre actores y entre casos de uso se representan mediante el mismo tipo de flecha que en el caso de clases. Las relaciones de extensin y de inclusin entre casos de uso son estereotipos de la dependencia entre clasificadores, y se representan mediante las palabras clave extend e include, respectivamente.
Ejemplo de casos de uso y actores con diferentes relaciones Consideremos el ejemplo siguiente:

Los usuarios correspondientes al actor Contable slo pueden intervenir en los casos de uso Asiento y CreacionCuenta, mientras que el actor JefeContable puede hacer tambin el caso de uso Correccion. Por tanto, JefeContable es una especializacin de Contable. El caso de uso CreacionCuenta extiende el caso de uso Asiento porque cuando se intenta hacer un asiento con una cuenta inexistente es necesario crear esta cuenta. El caso de uso Da-

Editorial UOC

88

Ingeniera del software

tosCuenta representa el acceso a los datos de una cuenta desde dentro de los casos de uso Asiento y Correccion. A diferencia de CreacionCuenta, no se trata de un caso de uso que pueda ser llevado a cabo de manera directa e independiente por parte un actor y, por tanto, la relacin con los casos que utilizan es de inclusin y no de extensin.

3. Los diagramas de interaccin

La ejecucin de un software orientado a objetos consiste en un encadenamiento de operaciones y de cambios de estado de objetos, el cual, a su vez, consiste en que durante la ejecucin de una operacin o durante una transicin se llaman operaciones sobre otros objetos (o sobre el mismo) y se envan seales que provocan otras transiciones. As, se puede describir el funcionamiento de los casos de uso y de operaciones complejas. En el UML esta accin se lleva a cabo mediante los denominados diagramas de interaccin.

3.1. Interacciones y colaboraciones

Para empezar, tenemos que definir los conceptos de interaccin y colaboracin.

3.1.1. Interacciones Una interaccin es la especificacin del comportamiento de un caso de uso u operacin en trminos de secuencias de intercambio de mensajes entre objetos (o, ms exactamente, entre instancias de clasificadores). Estos mensajes contienen estmulos, que pueden ser peticiones de ejecucin de operaciones o seales. Un hilo de ejecucin es una secuencia de mensajes tal que el primero contiene un estmulo que provoca el envo del segundo, etc. Si el mensaje A ha sido la causa de que se emitiera el mensaje B, se dice que A es el predecesor de B y B, el sucesor de A. Que un mensaje tenga varios sucesores o predecesores quiere decir que hay una bifurcacin o confluencia de hilos, respectivamente.

Editorial UOC

89

Captulo III. UML (II): el modelo...

3.1.2. Colaboraciones

De la misma forma que para que puedan circular mensajes entre ordenadores es necesario que los ordenadores estn unidos por enlaces de comunicaciones, tambin debe haber una cierta infraestructura para la circulacin de mensajes entre objetos (a diferencia del caso de las redes, aqu no se trata de una necesidad fsica, sino de una necesidad de coherencia entre los diferentes diagramas del UML que describen un software). Esta infraestructura est formada por las clases o clasificadores y las asociaciones entre las mismas, definidas en el modelo esttico, as como las asociaciones entre actores y objetos que se obtienen cuando se describen casos de uso mediante interacciones. De acuerdo con esto, para cada interaccin se tiene que indicar qu parte del modelo esttico utiliza.
Si un objeto de la clase A tiene que pedir una operacin de un objeto de la clase B, es necesario que estn estas dos clases y que B tenga definida la operacin que se pide. Sin embargo, debe haber tambin una asociacin entre estas dos clases y que est especificada la posibilidad de navegar a travs de ella por lo menos desde la clase A hacia la B.

Por tanto, en una colaboracin sobre la cual debe tener lugar una interaccin determinada, es necesario que figuren todos los clasificadores y asociaciones entre stos que se utilizarn en la interaccin. Sin embargo, de la misma manera que en un caso de uso de las entidades exteriores no nos interesan todos los aspectos, sino slo el papel que ejecutan en relacin con aquel caso de uso, tambin en una colaboracin, ms que clases u objetos, lo que se tendr en cuenta sern sus papeles* respectivos en relacin con dicha interaccin, y lo mismo es vlido para las asociaciones. Resumiendo, una colaboracin es un conjunto de papeles de clasificadores o instancias y de papeles de asociaciones entre aquellos que intervienen en una interaccin. Una colaboracin se puede definir en lo que respecta a clasificadores o por lo que respecta a instancias.
*. Conviene no confundir estos papeles con los que desempean los clasificadores con respecto a una asociacin que los relaciona.

Editorial UOC

90

Ingeniera del software

La sintaxis de los nombres de los papeles de clasificadores es la que presentamos a continuacin: / nombre_papel : nombre_clasificador [ nombre_estado ] o esta otra: nombre_instancia / nombre_papel : nombre_clasificador [ nombre_estado ] y en el caso de una asociacin, tenemos la expresin siguiente: / nombre_papel : nombre_asociacin El nombre_estado corresponde a uno de los estados que pueden tener los objetos de dicho clasificador, y es opcional, juntamente con los corchetes que lo rodean. La primera forma es aplicable tanto a clasificadores como a sus instancias. La representacin grfica de los papeles es igual que la de los clasificadores y asociaciones correspondientes, aunque slo es necesario especificar los elementos que estn modificados siempre en sentido restrictivo en la colaboracin. En una colaboracin pueden figurar varios papeles del mismo clasificador, con nombres de papel diferentes. Los multiobjetos representan un conjunto de objetos de un papel con cardinalidad mayor que 1 dentro de una asociacin. Se representan con dos rectngulos superpuestos, de los cuales el de delante est ligeramente desplazado hacia un ngulo para dar la sensacin de que hay muchos objetos. Los multiobjetos necesitan dos mensajes para realizar una operacin en cada uno de sus objetos: uno sirve para seleccionar el conjunto de enlaces de la asociacin que corresponden a los objetos, y el otro mensaje se enva de forma separada a cada objeto individual por medio del enlace respectivo. Estos dos mensajes pueden estar combinados dentro de uno que incluya tanto la interaccin como la aplicacin de la operacin a cada objeto individual.

Editorial UOC

91

Captulo III. UML (II): el modelo...

Ejemplo de colaboracin Observemos la figura siguiente:

El diagrama esttico de partida sera ste (tal vez con otras clases y asociaciones, que no vienen al caso):

Vemos que en el ejemplo de colaboracin no se utilizan todos los aspectos que tienen las dos clases y la asociacin en el diagrama esttico: slo se usa la navegacin en un sentido y el papel prstamos y reservas de la clase Libro se sustituye por el papel ms restrictivo prstamos, circunstancia que se refleja en la cardinalidad mxima. Se ha definido una colaboracin entre objetos (ms exactamente, entre un objeto y un multiobjeto), y al papel que desempea el objeto unLector se le ha dado el nombre prestatario, mientras que ni el multiobjeto de la clase Libro ni su papel tienen nombre.

3.1.3. Patrones

Una colaboracin parametrizada constituye la parte estructural de un patrn orientado a objetos. Los patrones son recetas formales para resolver problemas de diseo que se presentan a menudo, y la descripcin de la solucin que proponen tiene una parte estructural y otra dinmica. Los patrones se representan como elipses con el contorno discontinuo. Una aplicacin de un patrn en un caso particular se representa conectando el sm-

Editorial UOC

92

Ingeniera del software

bolo del patrn por medio de lneas discontinuas en las clases u objetos que sustituyen las del patrn en esta aplicacin.

Ejemplo de aplicacin de un patrn Este ejemplo corresponde a una aplicacin del patrn Composite , muy conocido, que trata de la implementacin de un objeto compuesto, cuyos componentes pueden ser compuestos o no.

En este caso, los objetos compuestos son grupos de datos, y cada uno de sus componentes puede ser un campo (es decir, un dato atmico) u otro grupo de datos. Las clases Campo , Dato y GrupoDeDatos son los argumentos que en este caso concreto sustituyen respectivamente las clases Leaf, Component y Composite, que son los parmetros de la colaboracin que describen los aspectos estructurales del patrn.

El UML ofrece dos diagramas para representar una interaccin y la colaboracin en que se basa: el diagrama de colaboracin, que pone nfasis en la descripcin de la colaboracin, y el de secuencias, que lo pone en la sucesin temporal de los mensajes de la interaccin. Hay una tercera manera de describir las interacciones, el diagrama de actividades, que tiene otra orientacin.

Editorial UOC

93

Captulo III. UML (II): el modelo...

3.2. El diagrama de colaboracin El diagrama de colaboracin es la representacin de una interaccin mediante un diagrama esttico de la colaboracin correspondiente sobre la cual se representan los mensajes de la interaccin. Para cada mensaje hay una especificacin con la siguiente sintaxis: predecesores guarda expresin_de_secuencia valores_de_retorno signatura A continuacin, daremos una explicacin de cada elemento del mensaje: predecesores es la lista de los mensajes predecesores de dicho mensaje que tiene esta forma: ( nmero_de_secuencia , nmero_de_secuencia ) ... /
El nmero de secuencia del mensaje que pone en funcionamiento toda la interaccin es 1, y los de los mensajes que enva en diferentes momentos el proceso que ha puesto en marcha directamente son 1.1, 1.2, etc., mientras que si el mensaje 1.2 activa un proceso que enva a la vez dos mensajes (y se crean, entonces, dos hilos de ejecucin) tendrn los nmeros que se distinguirn por un nombre, como 1.2a y 1.2b. Los mensajes con nombres como 1, 1.3, 1.3.1, 1.3.1.2, etc. se dice que forman una secuencia. Los predecesores que pertenecen a la misma secuencia que el mensaje en cuestin no es preciso mencionarlos.

guarda es la condicin que se tiene que cumplir para que se enve dicho mensaje (adems del hecho de que se hayan recibido los mensajes predecesores). expresin_de_secuencia tiene esta sintaxis: nmero_de_secuencia [ recurrencia ] , nmero_de_secuencia [recurrencia ] ... : La recurrencia tiene este formato: * [ clusula_de iteracin ] Si la iteracin es en paralelo, en lugar del asterisco slo aparece *||, o: [ clusula_de_condicin ]

Editorial UOC

94

Ingeniera del software

Ejemplo de clusula de iteracin La clusula_de iteracin podra ser, pongamos por caso, [x = 1, , 10]

La clusula_de_condicin acostumbra a servir para definir ramas de ejecucin. Puede haber varios nmeros de secuencia con sus clusulas de condicin respectivas. valores_de_retorno especifica una lista de nombres de valores retornados si los hay como resultado del proceso puesto en marcha por el mensaje. Presenta el formato siguiente: valor_de_retorno , valor_de_retorno ... :=. signatura est compuesta por el nombre del estmulo y por una lista de argumentos entre parntesis. Adems de los mensajes, se puede indicar la creacin y destruccin de objetos y enlaces durante la interaccin con las palabras clave new , destroyed, y transient, que equivale a las otras dos y, por tanto, denota que el objeto o enlace ha sido creado y destruido durante la interaccin.
Tipos de mensajes A continuacin, veremos los diferentes tipos de mensajes: a) Mensajes asncronos. La comunicacin asncrona se produce cuando la clase emisora enva un mensaje al suministrador y se contina ejecutando sin esperar a que llegue el resultado. La clase receptora, por su parte, no ejecuta la operacin inmediatamente, sino que deja la peticin en una cola. Se representa mediante una flecha con la punta abierta y cortada horizontalmente.

b) Mensajes sncronos. Slo se dan cuando el cliente enva un mensaje al suministrador y ste acepta el mensaje. La clase emisora ejecuta el cdigo hasta que enva

Editorial UOC

95

Captulo III. UML (II): el modelo...

el mensaje y, despus, se espera a recibir el resultado de la operacin asociada al mensaje. Se representan mediante una flecha con la punta coloreada que indica el sentido.

Ejemplo de diagrama de colaboracin Si usamos la colaboracin del Ejemplo de colaboracin, se ha descrito una interaccin en la cual un bibliotecario pide informacin sobre un objeto de la clase Lector identificado por su nmero de carnet y sus prstamos, mediante un mensaje al objeto unLector que slo tiene el nmero de secuencia y la firma de la operacin pedida. Durante su ejecucin, unLector enva un mensaje al multiobjeto de la clase Libro. Este ltimo mensaje es sincrnico, y del primero no se indica que sea sincrnico o asncrono porque corresponde a una interaccin entre un usuario y el sistema.

3.3. El diagrama de secuencias

A diferencia del diagrama de colaboracin, en el diagrama de secuencias no se representan de forma explcita los papeles de asociaciones (quedan implcitos en los mensajes) y se representa explcitamente el orden en el tiempo, e incluso la duracin, de los mensajes y de las operaciones que ponen en marcha.

Editorial UOC

96

Ingeniera del software

El diagrama de secuencias est estructurado segn dos dimensiones. El tiempo se representa verticalmente y corre hacia abajo, y no est representado necesariamente a escala. En direccin horizontal, hay franjas verticales sucesivas que corresponden a los diferentes papeles de clasificadores que participan en la interaccin; cada papel de clasificador est representado por el smbolo habitual, que encabeza su lnea de vida. El orden de los clasificadores de izquierda a derecha no es significativo, aunque la tendencia debe ser que los mensajes circulen de izquierda a derecha y los resultados y respuestas, de derecha a izquierda. La lnea de vida simboliza la existencia del papel en un cierto periodo de tiempo. Se representa mediante una lnea discontinua vertical que va desde la creacin del objeto hasta su destruccin. Si la destruccin no est prevista en el diagrama, entonces la lnea de vida ir hasta la parte inferior del mismo, es decir, hasta ms all del ltimo mensaje que se muestra. Si se quiere indicar la destruccin del objeto, entonces el final de la lnea de vida ir marcado con una X. Puede ser que durante una parte de la lnea de vida haya dos activaciones del objeto a la vez, que no sern concurrentes sino alternativas segn una condicin que determina que se emita el mensaje que pone en marcha una u otra. Una activacin es una parte de la lnea de vida durante la cual dicho papel ejecuta una accin, u otros papeles ejecutan otras acciones como consecuencia de una accin ejecutada por el papel. Las activaciones sirven para modelar relaciones de control entre clases y se representan mediante rectngulos alargados verticalmente insertados en las lneas de vida. El inicio y el final del rectngulo coinciden con la llegada del mensaje que pone en marcha la accin y el envo del mensaje de respuesta, respectivamente. Pueden tener etiquetas, que especifican la accin que corresponde al mensaje. Para especificar llamadas recurrentes del mismo papel, se representar una nueva activacin desplazada un poco ms a la derecha. Los mensajes se indican con flechas iguales a las del diagrama de colaboracin, que comienzan en una activacin (al principio de sta o por el medio) y acaban en otra. Su orden de arriba abajo expresa el orden en que se producen en el tiempo. Adems, una flecha inclinada (hacia abajo, necesariamente) indica un mensaje de duracin no ignorado, o de otro modo la flecha sera horizontal.

Editorial UOC

97

Captulo III. UML (II): el modelo...

La especificacin de los mensajes es muy parecida a la que hemos visto en el diagrama de colaboracin. Las principales diferencias son las siguientes:

No se indican los nmeros de secuencia, ya que quedan implcitos en el orden temporal de los mensajes y de las activaciones que provocan. Si hay dos expresiones de secuencia para el mismo mensaje, habr dos flechas, cada una con la clusula de condicin correspondiente, que saldrn del mismo punto de la activacin.

A diferencia del diagrama de colaboracin, se pueden indicar los mensajes de retorno al final de una activacin, en forma de flechas de lnea discontinua y punta abierta.

Ejemplo de diagrama de secuencias Diagrama de secuencias equivalente a diagrama de colaboracin. Este ejemplo corresponde al ejemplo de diagrama de colaboracin del final del subapartado 4.2:

Observad que no se indican los papeles de los objetos ni los nmeros de secuencia de los mensajes, pero de todas formas queda claro qu mensaje es consecuencia de qu

Editorial UOC

98

Ingeniera del software

otro. Observad la diferencia entre lnea de vida y activacin: puesto que los objetos y el actor existan antes de la interaccin y continuarn existiendo despus, sus lneas de vida (las lneas verticales discontinuas) comienzan antes y acaban despus de las activaciones respectivas. Que las flechas de los mensajes sean horizontales quiere decir que se pueden considerar instantneos, pero en cambio, los procesos tienen una duracin no ignorada, ya que tienen una cierta medida en direccin vertical y los mensajes en cascada se encuentran en flechas cada vez ms abajo. Ejemplo de diagrama de secuencias con creacin y destruccin de objetos y activaciones alternativas. Consideremos el siguiente diagrama de secuencias:

Se trata de aadir o suprimir un campo (dato atmico) contenido dentro de un grupo de datos, segn que la funcin pedida sea a o s, respectivamente. Puesto que un grupo de datos puede estar contenido dentro de otro (una vez o ms) se da una activacin recursiva de objetos de la clase GrupoDeDatos (naturalmente sern objetos diferentes en cada activacin, pero en el diagrama se representa un objeto en general). Los dos mensajes alternativos se produciran en el mismo momento; el hecho de que uno de stos se represente mediante una. flecha con una parte inclinada es slo por razones de dibujo. Podis prestar atencin a cmo se representan la creacin y la destruccin del objeto campo. La flecha del mensaje de creacin (aadir) se supone que coincide con el principio de la activacin, el cual lo hace, a su vez, con el principio de la lnea de vida. Hay una bifurcacin de la lnea de vida del ob-

Editorial UOC

99

Captulo III. UML (II): el modelo...

jeto de la clase campo desde el comienzo, pero las dos partes no se vuelven a juntar porque cuando se destruye un objeto (observad la X al final de una de sus activaciones), su lnea de vida ya no contina.

4. El diagrama de actividades

El diagrama de actividades se puede considerar una variante tanto del diagrama de estados como de los diagramas de interaccin, ya que sirve para describir los estados de una actividad, que es un conjunto de acciones en secuencia y/o concurrentes en el cual intervienen clasificadores.

4.1. Elementos especficos

El diagrama de actividades tiene muchos elementos comunes con los diagramas de colaboracin y de estados (objetos, estados, transiciones simples y complejas y seudoestados, acontecimientos, seales, flujos de control). Sus elementos especficos son stos:

1) Estados de accin, que son un caso particular de los estados, en los cuales no hay un objeto que permanezca en espera de que se produzca un acontecimiento que lo haga salir del mismo, sino que se est desarrollando una accin, que es la accin de entrada del estado. Cuando sta acabe, se producir la transicin, lo cual significa que un estado de accin no puede tener acciones vinculadas a otros acontecimientos que no sean el de entrada ni, por tanto, transiciones internas. Los estados de accin se representan como un rectngulo en el cual los lados derecho e izquierdo son semicircunferencias, con el nombre de la accin y el de un acontecimiento seguido de /defer si durante la accin se puede producir un acontecimiento que no es posible tratar hasta que termine.

Editorial UOC

100

Ingeniera del software

2) Flujos de objetos, que consisten en que un objeto es creado o cambia de estado en una accin y es utilizado por otra u otras. Los flujos de objetos se representan mediante flechas de punta abierta y lnea discontinua. Cuando un flujo de control y un flujo de objeto coinciden, se representa slo el flujo de objeto. 3) Estados de flujo de objeto, que significan que un objeto, probablemente en un estado convencional determinado, ha pasado a estar disponible al acabar una accin (es decir, al salir de un estado de accin). El objeto, con indicacin de su estado, se representa con un flujo de objeto que entra y otro que sale, y el smbolo del objeto en un estado es el mismo utilizado en las colaboraciones. Un objeto puede figurar varias veces en un diagrama, cada vez en un estado diferente. 4) Estados de subactividad, que son un caso particular de los estados compuestos, y corresponden a la ejecucin de todo un subdiagrama de actividades. Los estados de subactividad se representan como un estado de accin en cuyo interior hay dos pequeos estados de accin con una transicin de uno a otro. 5) Swimlanes son franjas verticales del diagrama que, a diferencia de las del diagrama de secuencias, no corresponden a papeles de clasificadores sino a unidades organizativas responsables de diferentes acciones. Cada estado de accin pertenece a un swimlane, y puede haber transiciones y flujos de objetos de un swimlane a otro. Los swimlanes llevan un nombre en su parte superior y estn separados por lneas verticales continuas. 6) Iconos de control, que representan el envo de una seal al acabar un estado de accin y su recepcin en otro como entrada. En las transiciones puede haber bifurcaciones y reunificaciones posteriores del flujo de control basadas en condiciones de guarda incompatibles a menudo complementarias. Por tanto, no expresan ninguna sincronizacin, ya que los dos flujos de control son alternativos. En la bifurcacin y en la reunificacin se ponen rombos en lugar de smbolos de seudoestado (barras gruesas).

Ejemplo de diagrama de actividad

En el ejemplo siguiente se describe la gestin de la compra de ordenadores en una empresa.

Editorial UOC

101

Captulo III. UML (II): el modelo...

Si partimos del estado inicial, el departamento que hace la peticin realiza la accin Preparacin propuesta, de la cual resulta un objeto de la clase Compra en el estado propuesta que entra en la accin Revisin presupuesto, que est a cargo de Control de gestin. Como resultado de esta accin, si no hay presupuesto para la compra (guarda no presupuesto) el departamento que pide pone en marcha la accin Cancelacin, con la que se llega al estado final. Si la guarda que se cumple es hay presupuesto, el objeto Compra pasa al estado presupuestada y entra dentro del estado de subactividad Gestin de compra (el cual se supone que est detallado en un diagrama de actividades aparte). Observad que a la vez se enva una seal que hace que el objeto de clase ConexionRed pase al estado acti-

Editorial UOC

102

Ingeniera del software

vada y que la llegada a este estado produzca una seal que, juntamente con el cumplimiento sucesivo de la actividad Gestin de compra y las acciones Envo y Transporte, permite que se ponga en marcha la accin Recepcin, que lleva al estado final.

5. Los diagramas de implementacin

Los diagramas de implementacin, a diferencia de los estticos y de los dinmicos, no describen la funcionalidad del software, sino su estructura general con vistas a su construccin, ejecucin e instalacin. Son dos: El diagrama de componentes, que muestra cules son las diferentes partes del software. El diagrama de despliegue, que describe la distribucin fsica de las diferentes partes del software en tiempo de ejecucin. Se utilizan en el diseo y la implementacin.

5.1. El diagrama de componentes

El diagrama de componentes describe la descomposicin fsica del sistema de software (y, eventualmente, de su entorno organizativo) en componentes, a efectos de construccin y funcionamiento. La descomposicin del diagrama de componentes se realiza en trminos de componentes y de relaciones entre los mismos.

5.1.1. Los componentes

Los componentes identifican objetos fsicos que hay en tiempo de ejecucin, de compilacin o de desarrollo, y tienen identidad propia y una interfaz bien definida.

Editorial UOC

103

Captulo III. UML (II): el modelo...

Los componentes incluyen cdigo en cualquiera de sus formatos (cdigo fuente o ejecutable), DLL, imgenes, pero tambin pueden ser documentos manuales cuando se describen partes no informatizadas de un sistema de informacin.
Ejemplo de componente Un componente podra ser, por ejemplo, un conjunto de clases ya sea en forma fuente o ejecutable agrupadas dentro de un paquete de UML o de Java. La interfaz correspondiente constar no de todas las operaciones de alguna clase del paquete que pueden ser pedidas desde otras clases, sino slo de las que pueden ser pedidas desde fuera del paquete. En un software, puede ser que se encuentren en tiempo de compilacin varios paquetes de clases hechas anteriormente que estn en forma ejecutable, que sean necesarios para compilar otros paquetes, stos de clases nuevas en forma fuente. Despus de la compilacin, puede ocurrir que las clases resultantes, ahora ya todas en forma ejecutable, se agrupen en paquetes de otro modo (con vistas a la comercializacin del software, por ejemplo) y las clases de estos diferentes paquetes colaboren en tiempo de ejecucin.

De los componentes, se puede indicar su tipo o una instancia. Los primeros se denominan componentes de tipo y se dan en tiempo de desarrollo o en tiempo de compilacin, y los segundos se denominan componentes de instancia y existen en tiempo de ejecucin. Un componente se representa mediante tres rectngulos, uno que contiene el identificador del componente (el nombre del tipo y, opcionalmente, el de la instancia, como en las clases y objetos) y dos menores incrustados en el lado izquierdo del primero.

5.1.2. Relaciones entre componentes

En un diagrama de componentes se muestran las diferentes relaciones que se pueden establecer entre componentes y otros componentes, objetos o procesos (objetos activos). En el caso de componentes no informticos, el significado de la relacin es que un componente utiliza la informacin contenida en el otro. En el caso de

Editorial UOC

104

Ingeniera del software

componentes de software, se distinguen dos tipos de relaciones, las relaciones en tiempo de desarrollo y las relaciones de llamada: Las relaciones en tiempo de desarrollo son asociaciones entre componentes que modelan dependencias las cuales se tendrn en cuenta en tiempo de compilacin o en tiempo de enlace. Las relaciones de llamada son asociaciones entre componentes que sirven para modelar llamadas entre componentes, es decir, que un componente el cliente utilice servicios de otro el proveedor. En tiempo de desarrollo, las relaciones de llamada se establecen entre componentes de tipo, y se representan en los diagramas de componentes. En tiempo de ejecucin, se producen entre dos componentes de instancia y se representan en los diagramas de despliegue. Adems, un componente puede tener relaciones de agregacin y composicin con otros componentes y con objetos. En el caso de la composicin, los componentes de un componente se pueden representar dentro del mismo.
Ejemplo de diagrama de componentes Observad el siguiente diagrama de componentes:

El componente Comp2 utiliza el Comp1 y contiene el componente Comp3 y un objeto de la clase Cl1.

Editorial UOC

105

Captulo III. UML (II): el modelo...

5.2. El diagrama de despliegue

El diagrama de despliegue permite (en ingls, deployment) mostrar la arquitectura en tiempo de ejecucin del sistema respecto a hardware y software. El diagrama de despliegue se utiliza en el diseo y la implementacin. Se pueden distinguir componentes (como los del diagrama de componentes) y nodos, as como las relaciones entre todos stos. Es ms limitado que el diagrama de componentes, en el sentido de que representa la estructura del sistema slo en tiempo de ejecucin, pero no en tiempo de desarrollo o compilacin. Sin embargo, resulta ms amplio en el sentido de que puede contener ms clases de elementos.

5.2.1. Los nodos

Los nodos representan objetos fsicos existentes en tiempo de ejecucin, sirven para modelar recursos que tienen memoria y capacidad de proceso, y pueden ser tanto ordenadores como dispositivos o personas. Los componentes participan mediante stos en los procesos. Puede haber nodos de tipo y nodos de instancia. Los nodos se representan mediante paralelpedos rectangulares.

5.2.2. Relaciones dentro del diagrama de despliegue

Entre los nodos se establecen relaciones que significan que existe comunicacin entre stos. Se representan mediante lneas continuas, y se puede hacer con un estereotipo que indica el tipo de comunicacin. Un componente o un objeto se puede ejecutar si se utilizan los recursos de un nodo o puede estar contenido en ste. En el primer caso, se da una dependencia con el estereotipo supports; en el segundo, se establece una relacin de agregacin o composicin, que es posible representar de las maneras habituales. Se puede representar que un objeto o componente emigra de un nodo a otro o se transforma en otro. En el primer caso se representa el objeto o componente en

Editorial UOC

106

Ingeniera del software

los dos nodos, y en los dos casos, la relacin entre s es una dependencia con el estereotipo becomes. Podemos tener asociada una propiedad que indique el tiempo en que se producir la migracin. Adems, entre componentes se pueden establecer las mismas relaciones mediante interfaces que en el diagrama de componentes, limitadas, pero en tiempo de ejecucin.
Ejemplo de diagrama de despliegue Observemos el siguiente diagrama de despliegue:

El nodo Servidor contiene el componente Componente1 y tiene comunicacin con el nodo Cliente, que contiene el componente Componente2 y un objeto de Clase1; Componente2 depende de Clase1 de una manera no especificada.

Editorial UOC

107

Captulo III. Introduccin a la...

Conclusiones

En este captulo hemos visto el resto de los diagramas que considera el estndar UML. Dichos diagramas son los siguientes: diagrama de casos de uso, diagrama de estados, diagramas de interaccin: diagrama de secuencias y diagrama de colaboracin, diagrama de actividad, diagramas de implementacin: diagramas de componentes y diagrama de desarrollo. Hemos visto detalladamente los conceptos y el uso de todos stos. Tambin hemos tratado las conexiones que se establecen entre estos diagramas, as como entre stos y el diagrama esttico. As, por ejemplo, los clasificadores figuran en el diagrama esttico, el de interaccin y el de implementacin. Los estados, en el diagrama de estados y en el de actividad; los actores, en el diagrama de casos de uso y en los de interaccin que describen la implementacin de los casos de uso, etc.

Editorial UOC

109

Captulo IV. Recogida y documentacin...

Captulo IV

Recogida y documentacin de requisitos

En el captulo Introduccin a la ingeniera del software OO se dijo que en esta obra se seguira el ciclo de vida iterativo e incremental del denominado Rational Unified Process. Se vio tambin que el primer componente de proceso de cada iteracin es la recogida de requisitos, que es la base para los otros componentes de proceso. En este captulo se ver cmo se realiza la recogida de requisitos en forma documentada, mediante notaciones y conceptos del UML que ya hemos visto. La recogida de requisitos busca obtener informacin sobre dos aspectos esenciales del software que se desarrolla: 1) Los procesos que debe realizar sobre los datos. 2) La manera en que debe pedir a los usuarios los datos de entrada y qu funcin del software quieren utilizar en cada momento y presentarles los resultados, que es lo que conocemos como interfaz de usuario del futuro software. Aunque se trata de dos aspectos del software bastante diferentes, puesto que las fuentes de informacin son las mismas, conviene recoger estos dos tipos de requisitos al mismo tiempo. El uso que se hace de la recogida de requisitos en las diferentes fases del ciclo de vida mencionado es el siguiente: En la fase de inicio se identifican casi todos los casos de uso, para delimitar el alcance del proyecto, pero slo se describen detalladamente los ms crticos. Durante la fase de elaboracin se describen la gran mayora de los casos de uso, aunque slo se implementa una pequea parte de los mismos.

Editorial UOC

110

Ingeniera del software

El resto de los requisitos se describen e implementan en la fase de construccin; en la fase de transicin slo intervienen los eventuales requisitos nuevos o modificados.

1. Los requisitos

Los requisitos son la especificacin de lo que debe hacer el software; son descripciones del comportamiento, propiedades y restricciones del software que hay que desarrollar. A menudo se dice que los requisitos deben indicar qu tiene que realizar el software sin decir cmo debe hacerlo; pero esto es demasiado radical, por diferentes razones: Los desarrolladores de software son tcnicos y, tal vez, les resultara difcil entender unos requisitos extremadamente abstractos. Est claro que debe haber unas referencias mnimas a la tecnologa utilizada. Finalmente, el software deber ser compatible con el entorno tcnico y organizativo. Los requisitos tienen un doble papel: a) Servir de base para un acuerdo entre los usuarios (ms exactamente, la empresa cliente) y los desarrolladores sobre el software que hay que desarrollar. Esto significa que la documentacin de los requisitos debe llevarse a cabo de una manera inteligible para los usuarios, que tendrn que revisarlo. b) Los requisitos son la informacin de partida para desarrollar el software; son la entrada de la etapa siguiente, el anlisis.

1.1. Clases de requisitos Existen dos clases de requisitos, los funcionales y los no funcionales.

Editorial UOC

111

Captulo IV. Recogida y documentacin...

Los requisitos funcionales describen qu debe realizar el software para sus usuarios: aceptar, verificar y registrar datos, transformarlos, presentarlos, etc. Estos requisitos quedan recogidos en los casos de uso. Los requisitos no funcionales* no van asociados a casos de uso concretos y consisten en restricciones impuestas por el entorno y la tecnologa, especificaciones sobre tiempo de respuesta o volumen de informacin tratado por unidad de tiempo, requisitos en cuanto a interfaces, extensibilidad, facilidad de mantenimiento, etc.

2. Fuentes de informacin

Para recoger informacin de los requisitos que debe cumplir el software, deberemos recurrir a las fuentes de informacin siguientes: a) Las entrevistas y eventualmente las encuestas a los futuros usuarios es importante que vayan acompaadas de la observacin directa del trabajo de los mismos. b) La documentacin sobre el sistema actual existente. Si el sistema est informatizado, debern estudiarse los manuales de la aplicacin y tambin los procedimientos manuales que se utilizan. c) Colegas de los usuarios. Es posible que los usuarios estn acostumbrados a realizar su trabajo de la misma manera durante mucho tiempo. Por lo tanto, el hecho de conocer otros puntos de vista les ayudar a salir de esquemas prefijados; pueden hablar con los colegas de los usuarios mismos, los desarrolladores o unos y otros. d) Finalmente, es tambin muy til realizar una revisin de sistemas parecidos que existan en el mercado. Los usuarios consideran tan evidente que determinadas funciones forman parte del dominio que creen innecesario mencionarlas, y que, probablemente, estn implementadas en todo software parecido que exista. Lo mismo ocurre con las denominadas funciones del sistema, que los usuarios no utilizan
*. Los requisitos no funcionales pueden describirse en forma de casos de uso ficticios.

Editorial UOC

112

Ingeniera del software

en su trabajo normal, pero que son convenientes, y a menudo imprescindibles, para el funcionamiento regular del software: reorganizacin de las bases de datos, alta y baja de usuarios y mantenimiento de los parmetros y las tablas bsicas del software.

3. Pasos de la recogida y documentacin de requisitos


Los pasos de la recogida y documentacin de requisitos son los siguientes: 1) Conocimiento del contexto del futuro software. 2) Recogida y clasificacin de los guiones. 3) Identificacin de los actores. 4) Identificacin de los casos de uso a partir de los guiones. 5) Identificacin de relaciones entre casos de uso (extensin, inclusin, especializacin). 6) Identificacin de las relaciones de especializacin entre actores. 7) Documentacin de los casos de uso.

3.1. El contexto del software

Los desarrolladores de software que se encargarn de recoger los requisitos generalmente tendrn formacin y experiencia informticas, pero no conocern la actividad profesional de los usuarios. Si es as, ser conveniente que adquieran cierto conocimiento desde el punto de vista organizativo y, como consecuencia, de la terminologa que se utiliza; esto es lo que denominamos contexto del software. Hay dos maneras de describir el contexto de un software: el modelo del dominio, que es la manera simplificada, y el modelo del negocio, que es una modalidad ms detallada. En cualquier caso, hay que elaborar un glosario de los trminos ms utilizados. Incluso si no se realiza ninguno de los dos modelos, conviene confeccionar el glosario.

Editorial UOC

113

Captulo IV. Recogida y documentacin...

3.1.1. El modelo del dominio

El modelo del dominio recoge los tipos de objetos las clases ms importantes. Como objetos importantes, podemos establecer la clasificacin siguiente: Objetos del negocio. Facturas, expedientes, cuentas, etc. Objetos del mundo real y conceptos relacionados con stos (cliente, historial de ventas, etc.). Acontecimientos, como llegadas de trenes, expiracin del plazo para pagar una factura, etc. Para realizar el modelo del dominio, se utiliza el diagrama de clases del UML. Al modelizar el contexto, hay que tener presente que se trata de realizar un modelo del entorno del software, y no del software; esto ltimo se realiza dentro de otro componente de proceso, el anlisis y diseo.

3.1.2. El modelo del negocio

El modelo del negocio* describe a grandes rasgos los procesos y entidades principales en torno al software. Este modelo describe cada una de las grandes actividades del negocio en trminos de casos de uso y de entidades y unidades de trabajo (que son agrupaciones de entidades que tienen un significado para el usuario) que intervienen. Se utilizan el diagrama de casos de uso y el de objetos, y para explicar los casos de uso se pueden usar diagramas de interaccin y de actividades.
Diferencias del modelo del dominio y el modelo del negocio El modelo del dominio y el modelo del negocio son bastante diferentes; no se puede decir que el modelo del dominio sea la parte del modelo de negocio que considera las entidades del mismo. Las clases del modelo del dominio se han obtenido a partir de un estudio superficial del negocio, mientras que en el modelo del negocio primero se
*. Realmente, el trmino negocio no debe tomarse en sentido literal. El entorno del software puede ser no slo una organizacin no lucrativa (o una parte de sta), sino tambin un robot, por ejemplo, si el software debe gestionar el funcionamiento de ste.

Editorial UOC

114

Ingeniera del software

describen, en lneas generales, los casos de uso, despus se identifican las entidades que participan en el mismo y, finalmente, estos casos de uso se describen con ms detalle, pero siempre teniendo en cuenta los aspectos organizativos ms que los informticos.

3.2. Los guiones

En realidad, los usuarios difcilmente identificarn los casos de uso de una manera explcita y sistemtica. Generalmente nos explicarn algunas de las series de operaciones ms frecuentes que realizan en su trabajo; esto es lo que se denomina guiones. Los guiones tienen las caractersticas siguientes: Son sesiones que un actor lleva a cabo en relacin con el software. Para un sistema de software existen muchos guiones posibles; es suficiente con describir un subconjunto en el que aparezcan, al menos una vez, todas las funciones que debe tener el software. Sirven para extraer los casos de uso. Los guiones son la fuente de informacin principal, ya que expresan las necesidades de los usuarios tal como ellos las ven; conviene que cada guin describa de manera precisa y completa la interaccin correspondiente entre el usuario y el software: Tambin es preciso que se indiquen todas las excepciones, casos particulares y precondiciones.

3.3. Identificacin de los actores

Como hemos visto, un actor es un papel, o ms, de cualquier entidad externa que se prev que interactuar con el software y le dar informacin o bien la recibir. Las entidades externas en cuestin pueden ser personas, mquinas, otros sistemas de software o instantes en el tiempo en los cuales debe ponerse en marcha automticamente algn proceso.

Editorial UOC

115

Captulo IV. Recogida y documentacin...

Cada actor tiene un papel para cada caso de uso en el que interviene; un papel es primario si el actor pone en marcha el caso de uso correspondiente. Algunas consideraciones sobre los actores: 1) A una persona, por ejemplo, le pueden corresponder diferentes actores, si es que puede tener diferentes conjuntos de papeles independientes en relacin con el software; en realidad, no nos interesa si dos actores pueden ser la misma persona o no. 2) Se supone que los actores no llevan a cabo, en principio, ninguna secuencia de casos de uso determinada, sino que cada actor invoca diferentes casos de uso independientemente en momentos determinados por su actividad exterior en el software. 3) Cada actor debe corresponder al menos a un usuario concreto; as se evita definir actores demasiado abstractos. 4) Es suficiente con identificar los actores, no es necesario describirlos detalladamente. 5) No tiene sentido que dos actores intervengan exactamente en los mismos casos de uso con los mismos papeles. A veces, puede ser til esta clasificacin de los actores: El usuario final o colectivo de personas que interactuarn directamente con el sistema y utilizarn las funciones de usuario. El usuario privilegiado o gestor del sistema encargado de definir la forma de funcionamiento del sistema, del que utilizar principalmente sus funciones. El entorno informtico, concepto que agrupa todo lo que se refiere a la interfaz no humana del software.

3.4. Identificacin de los casos de uso

Los casos de uso tienen estas caractersticas: 1) Son procesos autnomos iniciados por un actor o por otro caso de uso. Dos procesos iniciados por actores diferentes no pueden ser parte del mismo

Editorial UOC

116

Ingeniera del software

caso de uso, como tampoco pueden serlo los procesos que no sean nunca puestos en marcha directamente por un actor, excepto los casos de uso que formen parte de otros mediante relaciones include. 2) Representan funciones ofrecidas por el software e identifican sus entradas y salidas. Un caso de uso debe proporcionar siempre un resultado definido al actor primario. 3) Describen el qu de estas funciones y no el cmo, excepto las especificaciones no funcionales, a las cuales a veces se puede dar la forma de casos de uso. 4) Pueden servir de base para pruebas de caja negra. 5) Los casos de uso que se describan por primera vez en una iteracin determinada deben encajar con los de las iteraciones anteriores; si es indispensable, se pueden modificar estos ltimos. Es importante describir todos los casos de uso relativos al software considerado. Sin embargo, dentro de un ciclo de vida iterativo e incremental, se ir haciendo por partes. Los casos de uso se obtienen de los guiones, y se identifican las partes autnomas y eventualmente comunes a diferentes guiones en los que participa un mismo actor; tambin puede suceder que un caso de uso agrupe diferentes guiones enteros. A cada caso de uso se le da un nombre, que por lo general consta de un verbo y un complemento directo.

3.5. Identificacin de las relaciones entre casos de uso

En el subapartado anterior habrn quedado claras las relaciones de extensin, inclusin y generalizacin entre casos de uso. Con vistas a decidir si una relacin entre casos de uso es de un tipo o de otro, se pueden tener en cuenta estas reglas: 1) Una relacin de extensin siempre se relaciona con una condicin. As, cuando hay diferentes flujos de proceso posibles o bien casos especiales o errores que deban ser tratados de manera diferente, tendremos relaciones de extensin. No obstante, a pesar de todo, el caso de uso que se ejecuta condicionalmente tiene

Editorial UOC

117

Captulo IV. Recogida y documentacin...

autonoma en el sentido de que da cierto resultado concreto al actor que lo ha iniciado, que es el mismo que el del caso que se extiende.
Ejemplo de casos de uso con el mismo actor Puede ocurrir que deba darse de alta a un cliente que no est en la situacin de uso de registro de un pedido ni en el de planificacin de una visita de un vendedor; el actor debera ser, en ambos casos, el que puede dar de alta a clientes.

2) Una relacin de inclusin es nicamente un recurso para evitar la descripcin de una misma parte de proceso dentro de diferentes casos de uso.
Ejemplo de relacin de inclusin entre casos de uso Una factura que tiene un error se debe poder rechazar y devolver tanto si la factura es por una compra como por un servicio. Es decir, el caso de uso de rechazo de una factura se incluye tanto dentro del caso de uso de tratamiento de una factura de compra como dentro del tratamiento de una factura de servicio.

Por lo tanto, no es necesario que el caso de uso incluido tenga autonoma ni que sea puesto en marcha directamente por un actor (que, en cualquier caso, sera el mismo que pone en marcha los casos de uso en los cuales se incluye). En caso contrario, probablemente lo mejor ser considerar que la relacin es de extensin, ya que nada se opone al hecho de que un caso de uso extienda varios con el mismo actor. 3) Una relacin de especializacin indica que, de los dos casos de uso relacionados, uno es una versin especializada de la otra, en el sentido, por ejemplo, de que el primero se aplica a una subclase de la clase a la cual se aplica el segundo.
Ejemplo de relacin de especializacin El caso de uso de matrcula de un estudiante de nuevo ingreso se puede considerar una especializacin del caso de uso de matrcula de un estudiante en general, si el proceso adicional que debe realizarse en el primer caso es un conjunto de operaciones independientes y dispersas. Sin embargo, si este proceso adicional tuviera entidad propia, la relacin podra ser de extensin entre el caso general y la parte que slo se realiza para los estudiantes nuevos.

Editorial UOC

118

Ingeniera del software

3.6. Identificacin de las relaciones de especializacin entre actores

El actor A es una especializacin del B si A tiene todos los papeles de B (es decir, hace los mismos papeles en relacin con los mismos casos de uso) y alguno ms. No parece que la identificacin de este tipo de relaciones tenga ningn problema.

3.7. La documentacin de los casos de uso

Se pueden distinguir dos tipos de documentacin de los casos de uso: documentacin textual, documentacin formal.

3.7.1. La documentacin textual

La documentacin textual se compone de la descripcin textual de los casos de uso y el glosario de los trminos de la descripcin textual.

La descripcin textual

Es necesario elaborar una descripcin textual de cada caso de uso. Conviene realizarla mediante una plantilla y aplicar sistemticamente unas normas de formato. A continuacin, se describe una manera de realizar la documentacin textual de un caso de uso. Establecemos las convenciones siguientes:

Nombres de actor en negrita, Otra terminologa del usuario en cursiva, Referencias a otros casos de uso subrayadas.

Editorial UOC

119

Captulo IV. Recogida y documentacin...

Daremos a la documentacin textual la estructura siguiente: Cabecera. Nmero y nombre del caso de uso, resumen de la funcionalidad, papel del caso de uso dentro de trabajo del usuario, casos de uso relacionados, actores. Cuerpo. Precondicin y postcondicin del sistema, etapas, contenido de las entradas y salidas, alternativas de proceso y excepciones. Final. Cuestiones que hay que aclarar (las respuestas se incluirn, con autor y fecha, dentro de los comentarios), hiptesis que se realizan sobre aspectos no aclarados, comentarios, cambios.
El glosario

Es muy conveniente para unificar la terminologa y su interpretacin. Se puede extraer del modelo del dominio o del negocio, pero tambin se puede obtener a partir de entrevistas con usuarios.

3.7.2. La documentacin formal Es imprescindible un diagrama de casos de uso que los muestre todos con las relaciones entre stos y entre los actores. Adems, puede ser que para casos de uso concretos convenga utilizar algn otro diagrama como complemento de la descripcin textual: diagrama de actividades, de estados o de interaccin. Quiz podra crear alguna confusin el hecho de que en el anlisis se utilizan tambin estos diagramas para describir de manera detallada y formalizada los casos de uso; pero hay diferencias importantes: a) En el mbito de requisitos, la descripcin de los casos de uso es principalmente textual, y los diagramas realizan slo una funcin complementaria y no se elaboran sistemticamente para todos los casos (no olvidemos que los usuarios deben entender los requisitos, lo cual obliga a no usar notaciones muy formales). En cambio, en el mbito de anlisis, los diagramas de interaccin o de actividades se realizan sistemticamente para todos los casos de uso como un paso de formalizacin en trminos de objetos antes de su implementacin. b) Los diagramas del anlisis utilizan las clases definidas en el diagrama esttico que se elabora, mientras que los objetos que salen en los diagramas de los

Editorial UOC

120

Ingeniera del software

requisitos habrn sido identificados en el modelo del dominio o en el modelo del negocio, o simplemente en el momento de realizar el diagrama en el que salen, y por lo tanto son provisionales.

4. La recogida y documentacin de requisitos de la interfaz de usuario

En la introduccin de este mdulo vimos que es necesario recoger tanto los requisitos de funcionalidad como los de interfaz de usuario. Con Weinschenk, Jamar y Yeo podemos hacer esta especificacin de los objetivos de la recogida de requisitos de la interfaz de usuario*. Segn los autores mencionados, la recogida y documentacin de requisitos de la interfaz de usuario consiste en documentar y verificar informacin sobre los usuarios, su trabajo actual y su visin del trabajo con el software futuro, con vistas al diseo de la interfaz de usuario del nuevo software. Concretamente, se trata de obtener la documentacin siguiente: Restricciones organizativas y tcnicas. Perfiles de los usuarios. Descripcin de las tareas actuales y futuras. Especificaciones de usabilidad. Guiones para los casos de uso.

4.1. Concepto de interfaz de usuario

La interfaz de usuario es lo que los usuarios ven del funcionamiento del software. Tambin se denomina interfaz hombre-mquina.
*. D. Weinschenk; P. Jamar; S.C. Yeo (1997). GUI Design Essentials. John Wiley & Sons.

Editorial UOC

121

Captulo IV. Recogida y documentacin...

Ejemplos de interfaces de usuario Los casos ms habituales de interfaces son entradas mediante teclado y pantalla y salidas por pantalla e impresora. Tambin se pueden considerar entradas y salidas sonoras y entradas por escner.

De la interfaz de usuario dependen en gran medida los factores siguientes: La comodidad del usuario. Afecta a la ansiedad, frustracin, confusin, fatiga. La productividad del usuario. Es mejor en la medida en que sea necesario seleccionar menos teclas y botones, y que los recorridos que deba realizar con el ratn sean ms cortos y menos frecuentes. La imagen del software. Los usuarios juzgan la calidad del software sobre todo a causa de lo que ven ms directamente, es decir, a causa de las interfaces. No se dan cuenta de la calidad de la programacin, al menos mientras no afecte de manera perceptible al funcionamiento del software; por lo tanto, la interfaz de usuario puede determinar el xito o el fracaso de un software. Adems, una interfaz de usuario inadecuada puede provocar errores del usuario, sobre todo en caso de circunstancias no habituales, en las que el usuario tiene como nica gua la interfaz misma. Tambin puede provocar la infrautilizacin del software (en trminos de usuarios potenciales y de funciones disponibles), e incluso su rechazo total.

4.2. Identificacin de las restricciones tcnicas Hay que determinar si se ha establecido el uso de alguna tecnologa, herramienta, plataforma o normativa concretas, y tambin la disponibilidad de ratn, pantallas de colores y tipos de letra.

4.3. Elaboracin de los perfiles de usuario No se puede disear correctamente una interfaz de usuario sin saber para quin se hace, ya que un diseo apropiado para un usuario (en sentido colectivo) puede no serlo para otro. Hay que evitar en especial el error de que los de-

Editorial UOC

122

Ingeniera del software

sarrolladores del software diseen la interfaz de usuario como si los usuarios fueran ellos mismos, ya que tienen una cultura profesional y unos conocimientos de informtica muy diferentes de los de la gran mayora de los usuarios. Los perfiles de usuario tienen estos aspectos: Experiencia en torno a hardware y software (ratn, teclado, ventanas, etc.). Experiencia en aplicaciones del mismo dominio. Experiencia en el trabajo. Frecuencia de uso del software y grado de rotacin del personal.

4.4. Documentacin de las tareas actuales y futuras

De cada tarea hay que recoger los aspectos siguientes: La tarea en s, su frecuencia y qu usuarios la realizan. El entorno en el que se lleva a cabo, especialmente si hay limitaciones de espacio, la iluminacin, y si hay suciedad que pueda afectar a algunos dispositivos como los ratones. Su situacin dentro del flujo de tareas, es decir, cules la preceden, la siguen o la interrumpen y las interdependencias con otras tareas que obliguen a seguir un orden determinado. Qu informacin entra y sale y cules son los resultados y hacia dnde van. Qu documentos y herramientas son necesarios. Cules son los problemas y errores ms frecuentes. Las quejas y sugerencias sobre cmo se realiza la tarea. Esta informacin no se documenta de manera formalizada. Una tarea o secuencia de tareas se puede representar mediante un diagrama de actividad simplificado en el cual slo se representen los flujos y los estados de actividad, que corresponderan a operaciones, ya sea manuales o informatizadas. El conjunto de las tareas se puede representar en forma de una tabla que tenga una fila para cada tarea y en la que las columnas correspondan a los aspectos indicados. Obviamente se documentan por separado las tareas actuales y las futuras.

Editorial UOC

123

Captulo IV. Recogida y documentacin...

4.5. Comparacin entre tareas y casos de uso

A pesar de que las fuentes de informacin para los requerimientos de funcionalidad y de interfaz de usuario son las mismas, la informacin necesaria no es la misma. As, al describir los casos de uso desde el punto de vista de la funcionalidad, se pone nfasis en lo que realiza el software, mientras que cuando se describen desde el punto de vista de la interfaz de usuario, lo que interesa ms son las acciones que realiza el usuario y en qu condiciones lo hace. Podemos resumir as las diferencias entre tareas y casos de uso: a) All donde, desde el punto de vista de un caso de uso, el software presenta determinada informacin, desde el punto de vista de las tareas el usuario la comprueba y toma una decisin. b) En un caso de uso que tiene diferentes posibilidades, no es necesario indicar la frecuencia de cada una; en una tarea, s. c) A las tareas puramente manuales no les corresponde ningn caso de uso, y en un caso de uso tampoco se indican las operaciones manuales de una tarea, como poner un disquete antes de empezar un trabajo; en la descripcin de una tarea deben tenerse en cuenta, al menos para determinar la duracin de la misma. d) Cuando se produce una anomala, el software se limita a avisar al usuario, segn el caso de uso, mientras que segn la descripcin de la tarea, el usuario debe tomar una decisin y tal vez empezar otra tarea independiente. Por lo tanto, hay que recoger informacin sobre las mismas funciones desde dos puntos de vista. Una buena manera de recoger requisitos para los dos usos sera que dos desarrolladores realizaran de forma conjunta las entrevistas a los usuarios y que cada uno se interesase por uno de los dos aspectos. Parece claro que es mucho mejor que los dos entrevistadores lleven a cabo una entrevista y no dos entrevistas independientes, por dos motivos: para no hacer perder ms tiempo al usuario y para evitar tener dos versiones no coordinadas de las necesidades de usuario.

Editorial UOC

124

Ingeniera del software

4.6. Especificaciones de usabilidad

Las especificaciones de usabilidad son los requisitos no funcionales relativos a la interfaz de usuario. Las especificaciones de usabilidad se pueden referir a facilidad de utilizacin o aprendizaje o a rapidez y precisin en la ejecucin de las tareas. Conviene expresarlas de manera cuantitativa.

Ejemplos de especificaciones de usabilidad He aqu algunos ejemplos: Que el 90% de los usuarios que han trabajado al menos un ao con el sistema antiguo sean capaces de aprender en una semana las funciones indicadas en una lista, valindose slo de la documentacin y la ayuda on-line . Que el 80% de los usuarios despus de una semana de aprendizaje puedan registrar una media de diez facturas en treinta minutos o menos. Que despus de haber practicado dando tres altas de clientes, el 75% de los usuarios pueda dar de alta a diez clientes en veinte minutos o menos y el 90%, en veinticinco minutos o menos.

5. Ejemplo

Utilizaremos un ejemplo de proyecto de software, del que veremos la documentacin que se va generando en los pasos sucesivos de las etapas de recogida de requerimientos, anlisis y diseo. Por razones didcticas se ha elegido un ejemplo mucho ms sencillo que los casos reales. El ejemplo trata de la informatizacin de la gestin de alquileres de locales comerciales que realiza una agencia inmobiliaria. La informacin no estructurada del ejemplo est en letra ms pequea, para distinguirla de las explicaciones eventuales.

Editorial UOC

125

Captulo IV. Recogida y documentacin...

5.1. Informacin inicial

ste es el resumen de la primera entrevista que tuvo el equipo de desarrollo del software con el representante de la agencia inmobiliaria:
La agencia inmobiliaria (que desde ahora se denominar simplemente la agencia) alquila locales comerciales, que pueden ser tiendas-almacn, oficinas o inmuebles. Los inmuebles son edificios que es posible alquilar enteros o por oficinas y tiendas-almacn individuales. Adems, hay unos locales, denominados polivalentes, que pueden considerarse tanto oficinas como almacn. Los propietarios de los locales pueden ser particulares o empresas. El propietario puede cancelar en cualquier momento la oferta de su local, pero mientras no lo haga no lo puede alquilar por su cuenta y est obligado a aceptar al arrendatario que proponga la agencia si cumple las condiciones estipuladas; entonces la agencia prepara el contrato de alquiler, que siempre es por un tiempo determinado. Cuando se cumple el plazo de preaviso de la renovacin o no del contrato de alquiler, si hay renovacin la agencia prepara el nuevo contrato y si no hay renovacin o el arrendatario cancela el contrato antes del plazo mencionado, la agencia propone al propietario buscarle otro arrendatario. Otro servicio que realiza la agencia es recibir peticiones de alquiler de locales con caractersticas determinadas (situacin y superficie, principalmente) y entonces se buscan locales que las tengan, entre los que alquila la agencia y, si es necesario, otras agencias. Cuando encuentra uno conveniente, se propone al propietario que se convierta en cliente y, si acepta, se prepara el contrato.

5.2. Modelo del dominio

A simple vista se identifican los objetos o clases local, propietario, arrendatario y contrato de alquiler (objetos del mundo exterior), peticin de alquiler de local (objeto del dominio) y plazo de preaviso de fin de alquiler (acontecimiento). Se han puesto algunos atributos a las clases de manera orientativa (sin tipo, o reuniendo en uno lo que pueden ser varios, como es el caso de situacin).

Editorial UOC

126

Ingeniera del software

No es necesario que los nombres de los atributos, e incluso de las clases, respeten las restricciones de algn lenguaje, porque este diagrama no se utilizar para etapas posteriores.

5.3. Modelo del negocio

Para elaborar el modelo del negocio, sera necesaria ms informacin con vistas a elaborar unos primeros casos de uso. La informacin adicional es la siguiente:
Cuando un propietario ofrece un local, es entrevistado por un agente que le pide los datos identificativos y la direccin, superficie, caractersticas y restricciones (que el arrendatario no pueda poner un bar de copas, por ejemplo) del local, e introduce estos datos en el ordenador; despus, un inspector visita el local y realiza un informe, a partir del cual fija el precio del alquiler y los usos para los que es adecuado. Cuando se produce una peticin de alquiler, un vendedor entrevista al eventual arrendatario e introduce en el ordenador los datos y las caractersticas del local que pide; cuando se realiza un contrato de alquiler, el vendedor introduce los datos del arrendatario y del contrato.

Editorial UOC

127

Captulo IV. Recogida y documentacin...

El diagrama de casos de uso del modelo del negocio es el siguiente:

Mediante los diagramas de colaboracin, identificamos los objetos que utilizan los casos de uso anteriores:

Editorial UOC

128

Ingeniera del software

El diagrama de objetos del modelo del negocio es el siguiente:

5.4. El glosario del modelo del negocio

A continuacin, se presenta el glosario del modelo de negocio.


Agencia: agencia inmobiliaria X, dedicada a la intermediacin en el alquiler de locales comerciales. Agente: empleado de la agencia que entrevista a los propietarios. Arrendatario: persona o empresa que alquila un local comercial. Arrendatario eventual: persona que pide a la agencia que le busque un local con unas determinadas caractersticas para alquilarlo con vistas a un uso concreto. Cdigo del local: dato que identifica un local, formado por el cdigo de la zona, el tipo de local y un nmero correlativo. Contrato: contrato legal de alquiler de un local, firmado por el propietario y el arrendatario.

Editorial UOC

129

Captulo IV. Recogida y documentacin...

Informe: reporte que elabora un inspector de la agencia sobre un local despus de visitarlo. Inspector: empleado de la agencia que visita los locales antes de ofrecerlos en alquiler. Local: inmueble o parte de ste que se alquila para usos comerciales, es decir, cualquier uso excepto de vivienda o industria. Puede ser inmueble, oficina, tienda-almacn o polivalente. Precio: importe mensual del alquiler de un local. Propietario: persona o empresa que tiene el ttulo de propiedad del local. Los clientes de la agencia son los propietarios de los locales que alquila. Vendedor: empleado de la agencia que entrevista a los arrendatarios y arrendatarios eventuales, busca locales adecuados para estos ltimos y prepara los contratos.

5.5. Los guiones

Se han encontrado tres guiones:


El guin del agente Llega un cliente y se le piden los datos del local que quiere alquilar: direccin, tipo, superficie, caractersticas, restricciones, el volumen si se trata de una tienda-almacn y las caractersticas polivalentes si es un polivalente, y se le asigna un cdigo que contiene la zona, el tipo y un nmero correlativo. Si el propietario no estaba introducido para un local anterior, hay que dar la razn social o los apellidos y nombre segn se trate de una empresa o de un particular, la direccin, el telfono y el NIF. Una vez aadido el local, no se puede alquilar an, sino que queda pendiente de inspeccin. El guin del inspector La inspeccin consiste en una vista previa del inspector al local. El inspector examina diferentes aspectos del local (forma, accesibilidad, instalaciones, estado de conservacin, visibilidad, etc.) con el objetivo de determinar el precio de alquiler y los usos posibles. El inspector mismo introduce esta informacin.

Editorial UOC

130

Ingeniera del software

El guin del vendedor Una vez que se le ha puesto precio, el local est pendiente de alquilar; se anuncia en la prensa y los vendedores lo ofrecen a los arrendatarios eventuales. Cuando llega un arrendatario eventual, le atiende un vendedor que lo entrevista e introduce sus datos (apellidos y nombre, NIF, telfono, direccin, tipo de local que desea, zona o zonas, superficie mnima y diferentes requisitos). A continuacin, el vendedor lleva a cabo una bsqueda entre los locales pendientes de alquilar; si encuentra locales adecuados, le comenta las caractersticas (excepto la direccin del local y los datos del propietario); si al arrendatario eventual le interesa algn local, se marca el local como comprometido y se pone en marcha la preparacin del contrato, que empieza con el aviso al propietario. Si entre los locales que la agencia ofrece no hay ninguno apropiado, la agencia busca ms locales por otros medios y, cuando encuentra uno conveniente, ofrece al propietario presentarle un alquiler a cambio de que el propietario se convierta en cliente de la agencia.

5.6. Casos de uso

A lo largo de los subapartados siguientes realizaremos la identificacin de los casos de uso correspondiente a la situacin planteada.

5.6.1. Actores

Los actores son tres: agente, inspector y vendedor, que son usuarios finales directos del sistema. En cambio, no son actores ni los propietarios ni los arrendatarios o arrendatarios eventuales, ya que no tienen interaccin con el sistema, sino que toda la relacin que tienen es mediante los agentes y los vendedores (por lo tanto, el software no los ve). El agente tiene dos papeles, ya que aade locales, por un lado, y propietarios, por otro. El vendedor tiene cuatro, ya que introduce arrendatarios, arrendatarios eventuales y contratos, y busca locales. Todos estos papeles son primarios. Los tres actores son independientes. Entre ellos no hay ninguna relacin de especializacin, ya que, como veremos a continuacin, no hay ningn caso de uso que puedan hacer dos de los actores.

Editorial UOC

131

Captulo IV. Recogida y documentacin...

5.6.2. Diagrama de casos de uso

A continuacin, vemos el diagrama de casos de uso relacionado con el ejemplo:

5.6.3. Documentacin textual

Se utilizan las convenciones y la estructura descritas antes, pero, como sucede tambin en la realidad, no todos los casos de uso tienen todos los datos posibles (por ejemplo, descomposicin en etapas). No se proporciona el glosario de los casos de uso porque, por la sencillez del caso, coincidira con el glosario del modelo del negocio. Asimismo, en los casos reales generalmente se habrn introducido trminos nuevos en las descripciones de los casos de uso.
Caso de uso nmero 1: Aadir local Resumen de la funcionalidad: aade un local a la base de datos.

Editorial UOC

132

Ingeniera del software

Papel en el trabajo del usuario: es el caso de uso principal del trabajo de los agentes . Actores: agente. Casos de uso relacionados: Aadir propietario, Introducir informe, Introducir contrato. Precondicin: el local no existe en la base de datos. Postcondicin: el local est incorporado en la base de datos. El agente introduce los datos del local: un cdigo del local que contiene la zona, el tipo (tienda-almacn, oficina, polivalente o inmueble entero), y un nmero correlativo, la direccin, la superficie, un texto de caractersticas, otro de restricciones, el NIF del propietario, el volumen si es tienda-almacn y el texto de caractersticas polivalentes si es un polivalente. Alternativas de proceso y excepciones: si el propietario no estaba introducido, hay que aadirlo segn el caso de uso Aadir propietario. Cuestiones que hay que aclarar: Hay que registrar qu agente ha aadido el local? Respuesta: s; el nombre del agente se toma de una lista. Caso de uso nmero 2: Aadir propietario Resumen de la funcionalidad: aade un propietario a la base de datos. Papel en el trabajo del usuario: es un caso de uso espordico en el trabajo de los agentes. Actores: agente. Casos de uso relacionados: Aadir local, Introducir contrato. Precondicin: el propietario no existe en la base de datos. Postcondicin: el propietario est incorporado en la base de datos. El agente introduce los datos del propietario: el NIF, la razn social si es una empresa o los apellidos y nombre si es un particular, la direccin y el telfono. Este caso de uso puede ser ejecutado independientemente o ser llamado desde el caso de uso Aadir local. Caso de uso nmero 3: Introducir informe Resumen de la funcionalidad : aade el informe del inspector a un local.

Editorial UOC

133

Captulo IV. Recogida y documentacin...

Papel en el trabajo del usuario: es el caso de uso nico en el trabajo de los inspectores. Actores: inspector. Casos de uso relacionados: Aadir local, Introducir contrato. Precondicin: el local est introducido en la base, pero an no tiene el informe y, por lo tanto, no est disponible para alquilar. Postcondicin: el local tiene incorporado el informe y est disponible para alquilar. El inspector introduce el cdigo del local y despus los textos sobre cada uno de los aspectos del local: la forma, la accesibilidad, las instalaciones, el estado de conservacin, la visibilidad y diferentes aspectos; tambin introduce los usos recomendados (los toma de una lista) y el precio. Adems, puede modificar la direccin, la superficie, el tipo y el texto de caractersticas. Cuestiones que hay que aclarar: Hay que registrar qu inspector ha realizado el informe? Respuesta: s; el nombre del inspector se toma de una lista. Caso de uso nmero 4: Introducir contrato Resumen de la funcionalidad: introduce en la base de datos la informacin necesaria para preparar un contrato. Papel en el trabajo del usuario: pertenece a la parte principal del trabajo de los vendedores. Casos de uso relacionados: Aadir arrendatario. Precondicin: el local est disponible para alquilar. Potscondicin: el local est alquilado. El vendedor introduce el cdigo del local y despus el NIF del arrendatario; despus se aaden las fechas de inicio y de final del contrato. Alternativas de proceso y excepciones: si el arrendatario no estaba introducido, se le aade segn el caso de uso Aadir arrendatario. Cuestiones que es preciso aclarar: Hay que registrar qu vendedor ha introducido el contrato ? Respuesta: s, el nombre del vendedor se toma de una lista.

Editorial UOC

134

Ingeniera del software

Hay que imprimir directamente el contrato ? Respuesta: no, pero deben imprimirse los datos del propietario, arrendatario, local y fecha de inicio y final del contrato con el objetivo de preparar el contrato fuera de la aplicacin. Caso de uso nmero 5: Aadir arrendatario Resumen de la funcionalidad: aade los datos de un arrendatario en la base de datos. Papel en el trabajo del usuario: lo utilizan ocasionalmente los vendedores como paso previo a la introduccin de un contrato . Actores: vendedor. Casos de uso relacionados: Aadir eventualmente arrendatario, Aadir contrato. Precondicin: el arrendatario no existe en la base de datos. Postcondicin: el arrendatario est incorporado en la base de datos y, por lo tanto, puede figurar en un contrato. El vendedor introduce los datos del arrendatario: el NIF, los apellidos y nombre (o la razn social, si es una empresa), el telfono y la direccin. Caso de uso nmero 6: Aadir arrendatario eventual Resumen de la funcionalidad: aade los datos de un arrendatario eventual en la base de datos. Papel en el trabajo del usuario: lo utilizan ocasionalmente los vendedores como paso previo a la bsqueda de locales que puedan convenir al arrendatario eventual . Actores: vendedor. Casos de uso relacionados: Aadir arrendatario, Aadir contrato. Precondicin: el arrendatario eventual no existe en la base de datos. Postcondicin: el arrendatario eventual est incorporado a la base de datos y, por lo tanto, puede figurar en un contrato. Es parecido al caso de uso Aadir arrendatario, excepto que, adems, el vendedor introduce los datos siguientes: el tipo de local, la zona o zonas deseadas, la superficie mnima y varios requisitos. Caso de uso de nmero 7: Buscar locales Resumen de la funcionalidad: busca los locales que cumplen determinadas condiciones.

Editorial UOC

135

Captulo IV. Recogida y documentacin...

Papel en el trabajo del usuario: lo utilizan ocasionalmente los vendedores para la bsqueda de locales que puedan convenir al arrendatario eventual . Actores: vendedor. Casos de uso relacionados: ninguno. Precondicin: ninguna. Postcondicin: ninguna, al ser una consulta. Busca todos los locales que cumplen unas condiciones especificadas antes de la ejecucin en trminos de tipo, zona y superficie y obtiene una lista de la que se pueden seleccionar locales uno por uno para ver toda la informacin o bien toda menos la direccin y el NIF del propietario. Otros requisitos La informacin sobre propietarios, arrendatarios, locales y contratos hay que poderla consultar y modificar y, la que ya no se utilice, borrarla.

5.7. Requisitos de la interfaz de usuario Aqu determinaremos los requisitos que debe cumplir la interfaz de usuario.

5.7.1. Perfiles de usuarios De entrada, se realiza una explicacin de los perfiles de los usuarios.
Todos los usuarios conocen a fondo su trabajo. Los agentes y los vendedores estn acostumbrados a utilizar ordenadores, pero los inspectores no mucho. Ningn usuario ha utilizado ninguna aplicacin parecida. La rotacin del personal es muy baja. Todas las funciones del software se realizarn muy a menudo.

5.7.2. Documentacin de las tareas futuras Aqu slo se incluye la documentacin de las tareas futuras. La de las tareas antiguas se realizara de la misma manera.

Editorial UOC

136

Ingeniera del software

Aadir un local El agente teclea la direccin y superficie del local (en m 2) y los textos de caractersticas y restricciones. Respecto al cdigo del local, la zona y el tipo se eligen de las listas respectivas. El sistema lo asigna automticamente el nmero correlativo. El agente teclea tambin el NIF del usuario y, si no existe, el agente puede optar entre cambiarlo y aadir un nuevo propietario con aquel NIF. Cuando se aade un propietario, el NIF es el que se haba dado con los datos del local. El agente teclea la direccin, el telfono y el nombre y apellidos o la razn social. Introducir un informe El inspector trae escrita en un impreso la informacin que ha recogido durante la visita. Para introducirla en el ordenador, teclea en primer lugar el cdigo del local; la comprueba y la puede modificar, excepto el cdigo del local y el texto de restricciones. Teclea los campos textuales de forma, accesibilidad, instalaciones, visibilidad y precio, y selecciona de una lista un valor para el estado de conservacin, y de otra lista, el valor o valores de los usos posibles del local. Introducir un contrato El vendedor introduce el cdigo del local y le sale toda la informacin sobre el mismo; la comprueba y si haba algn error, cancela la tarea, y si no hay ninguno, introduce el NIF del arrendatario. Si el arrendatario existe, salen todos los datos y el vendedor puede cancelar la tarea o continuar, y modificar los datos o no hacerlo; si no existe, salen los datos en blanco y puede introducirlos o cancelar la tarea; si introduce los datos y los confirma, est en el mismo punto que si hubiera encontrado un arrendatario inicialmente. Si contina, introduce la fecha de inicio y la fecha de la vigencia del contrato. Entonces puede confirmar la tarea o cancelarla; si la confirma, se imprimen los datos del contrato, que son stos: del propietario, los apellidos y nombre o la razn social, el NIF y la direccin; del local, la direccin; del arrendatario, los apellidos y nombre o la razn social, el NIF y la direccin; los datos de inicio y de fin de la vigencia. Introducir un arrendatario eventual El vendedor introduce el NIF y puede confirmar o cancelar la tarea; si el NIF ya existe en la base de datos, sale toda la informacin del arrendatario eventual, que puede ser modificada, y si no, salen los mismos datos pero vacos. Estos datos son el apellido y nombre o la razn social, la direccin, el telfono, el tipo de local y las zonas desea-

Editorial UOC

137

Captulo IV. Recogida y documentacin...

das, la superficie mnima en m 2 y el campo de diferentes requisitos. El tipo de local y las zonas se eligen de las listas respectivas, mientras que el resto de los datos se teclea. Buscar locales Se pueden buscar locales si se da alguno de los datos siguientes: el cdigo del local; la zona; el NIF del propietario; el NIF del arrendatario o arrendatario eventual; la superficie mnima (en m2).

Slo puede darse uno de estos valores, excepto la zona y la superficie mnima, que pueden darse a la vez. Cuando se da el NIF de un arrendatario, salen los locales que tiene alquilados, y si es un arrendatario eventual, salen los locales que cumplen sus requisitos en cuanto a superficie y zona. Se puede elegir entre que salgan todos los locales o slo los disponibles, y que salgan todos los datos de los locales o todos excepto el NIF de propietario y la direccin. La lista sale en pantalla y opcionalmente se puede imprimir.

En la tabla siguiente resumimos todos estos aspectos:

Editorial UOC

138

Ingeniera del software

5.7.3. Requisitos de usabilidad

Los agentes e inspectores deben ser capaces de utilizar el sistema despus de una explicacin y prctica de una hora, y los vendedores despus de una explicacin y prctica de dos horas.

Editorial UOC

139

Captulo IV. Introduccin a la...

Conclusiones

Se ha visto un procedimiento para recoger y documentar los requisitos del software que se quiere desarrollar desde sus dos vertientes: los procesos y la interfaz de usuario. Antes de proceder a la recogida de requisitos del software, los desarrolladores deben adquirir y documentar un cierto conocimiento del entorno en que se utilizar el software, aspecto que se consigue realizando el modelo del dominio o el modelo del negocio (ms extenso, como sabemos). A pesar de que hay diferentes fuentes de donde se puede extraer informacin til con el objetivo de establecer los requisitos, la fuente ms importante son los futuros usuarios, gracias a sus entrevistas. En cada entrevista conviene establecer tanto los requisitos en cuanto a proceso como los requisitos en cuanto a interfaz de usuario, que sirven para especificar los casos de uso y las tareas respectivamente. Se ha visto un ejemplo de recogida y documentacin de requisitos. De la misma manera que en un caso real, no se ha dado toda la informacin de una sola vez, sino que se supone que se ha completado durante la elaboracin de la documentacin y en forma de respuesta a dudas que se presentaban entonces. Tambin se puede ver que la documentacin de las tareas incluye aspectos que no abarcan la documentacin de los casos de uso y viceversa, ya que la finalidad con que se elaboran es diferente, pero no deberan existir contradicciones entre las dos, pues seran errores.

Editorial UOC

141

Captulo V. Anlisis orientado a objetos

Captulo V

Anlisis orientado a objetos

Este captulo trata del anlisis del software con tcnicas orientadas a objetos, aplicando las notaciones y conceptos del UML y siguiendo el ciclo de vida del Rational Unified Process. Dentro de este ciclo de vida, el anlisis y el diseo constituyen un solo componente del proceso, pero nosotros los consideraremos dos etapas diferentes, por razones que se irn explicando a lo largo del captulo. En los apartados siguientes se ver detalladamente el papel del anlisis en relacin con la etapa que lo precede, la recogida y documentacin de requisitos, y la que lo sigue, el diseo (siempre con la condicin de que consideramos que el desarrollo de software no es un proceso lineal, sino que el ciclo de vida es iterativo e incremental, y que, por lo tanto, sus etapas se repiten para diferentes partes del software hasta completarlo). Aqu decimos, no obstante, que el anlisis es la primera etapa del desarrollo del software propiamente dicho, y que consiste en traducir los requisitos a una forma ms adecuada para ser la base de partida de este desarrollo. En el anlisis distinguiremos los pasos siguientes:

La revisin de los casos de uso, La identificacin de las clases de anlisis, La identificacin de las relaciones entre clases, La especificacin formal de los casos de uso, El anlisis de la interfaz de usuario.

Editorial UOC

142

Ingeniera del software

1. El papel del anlisis

1.1. La relacin entre la recogida de requisitos y el anlisis La etapa de recogida y documentacin de requisitos establece los requisitos del futuro sistema de software con suficiente detalle para que se pueda empezar a desarrollar. Se supone que hay un acuerdo entre los usuarios (o sus supuestos representantes) y los desarrolladores del software sobre estos requisitos; esto significa que los requisitos estn expresados de una manera poco formalizada, ya que, de otra forma, seran inteligibles slo por profesionales del desarrollo del software. Sin embargo, unos requisitos en esta forma no son una buena base para construir un software de manera sistemtica. Por lo tanto, un primer cometido del anlisis es el de traducir los requisitos a un lenguaje ms formal, que en el mtodo que seguimos son los modelos y diagramas del UML; as se obtiene lo que se denomina modelo del anlisis. Cules han sido los productos de la etapa de recogida y documentacin de requisitos? Bsicamente, la descripcin de las funciones del software en forma de casos de uso, por un lado, y de tareas de los usuarios, por el otro; el modelo del dominio o el modelo del negocio y el glosario son slo documentos previos o, como mucho, complementarios, de estos dos. Ahora bien, un desarrollo orientado a objetos debe utilizar un formalismo de clases y objetos que en los casos de uso y las tareas no aparece todava. Por lo tanto, un segundo cometido de la etapa de anlisis ser la identificacin de unas clases fundamentales que sern la base de la implementacin del software. Un tercer cometido ser la expresin de los casos de uso en trminos de estas clases.

1.2. La relacin entre el anlisis y el diseo Tanto en el anlisis como en el diseo se describe el futuro software de manera orientada a objetos. La diferencia fundamental es el hecho de que en el anlisis se describe el funcionamiento del futuro software, sin entrar en la problemtica de la implementacin.

Editorial UOC

143

Captulo V. Anlisis orientado a objetos

En realidad, el anlisis se puede realizar sin tener en cuenta en qu lenguaje de software se implementar, e incluso es muy conveniente hacerlo de este modo (excepto, tal vez, los nombres de clases, atributos y operaciones). Asimismo, existe un alto grado de continuidad entre el anlisis y el diseo, ya que la mayora de las definiciones de clases del anlisis se utilizan despus en el diseo; en los mtodos de desarrollo no orientados a objetos, en cambio, se utilizan modelos diferentes al anlisis y el diseo.

1.3. La utilidad del anlisis

Jacobson, Booch y Rumbaugh mencionan cuatro razones que pueden justificar la elaboracin de una documentacin de anlisis separada de la del diseo:* 1) Es posible analizar todo el software con un coste relativamente bajo y despus implementarlo por partes de una manera coherente, ya que el anlisis habr proporcionado una perspectiva global. 2) La documentacin del anlisis ofrece una visin general del software, pero sin llegar a los detalles de la implementacin, que es muy til para adquirir rpidamente un conocimiento del mismo. 3) De sistemas de software en los cuales la seguridad es crtica, se pueden realizar varias implementaciones partiendo de un nico anlisis. Lo mismo se puede hacer si se desea encargar varias implementaciones para quedarse con la mejor. 4) Para conformar de nuevo un sistema antiguo con tecnologa actual, la descripcin de ste realizada mediante anlisis puede ser una base de partida mucho ms conveniente que la implementacin existente, en la que aparecen muchos ms detalles que no hay que tener en cuenta. El uso que se lleva a cabo del anlisis en las diferentes fases del ciclo de vida del Rational Unified Process puede ser uno de estos tres: El modelo del anlisis se va actualizando y se utiliza en todo el ciclo de vida.
*. I. Jacobson; G. Booch; J. Rumbaugh (2000). El proceso unificado de desarrollo de software . AddisonWesley.

Editorial UOC

144

Ingeniera del software

El modelo de anlisis se considera un resultado transitorio y cuando se entra de lleno en el diseo y la programacin se abandona; los problemas de anlisis que aparezcan se resuelven en el mbito de diseo y programacin. No hay modelo de anlisis, o bien se integra con la documentacin de los requisitos y entonces es necesario que sta sea mucho ms formal, lo cual dificulta que la puedan entender la mayora de los usuarios o bien se pasa directamente de los requisitos al diseo. Esto ltimo significa ponerse a resolver un problema que no ha sido especificado formalmente y, por lo tanto, de manera suficientemente clara y coherente, lo cual slo podra ser aconsejable en casos extremadamente sencillos.

2. Paquetes de anlisis y paquetes de servicios

Por poca envergadura que tenga un proyecto de software, ser necesario dividir la documentacin en paquetes de UML, cada uno de los cuales contendr clases, casos de uso u otros elementos del UML. En una divisin bien hecha, los paquetes cumplirn dos condiciones: 1) Sern coherentes, es decir, los elementos del mismo paquete estarn fuertemente relacionados. 2) Sern poco dependientes unos de otros, es decir, existirn pocas conexiones entre elementos de paquetes distintos. Se distinguen dos niveles de paquetes: paquetes de anlisis y paquetes de servicios; unos y otros se basan en la funcionalidad (es decir, en ningn caso en los requisitos no funcionales). Cada paquete de servicio est incluido dentro de un solo paquete de anlisis. Una vez descompuesto el software en paquetes, o un paquete de anlisis en paquetes de servicio, conviene identificar las dependencias entre paquetes. Si se considera que hay demasiados, se cambia la descomposicin.

Editorial UOC

145

Captulo V. Anlisis orientado a objetos

2.1. Los paquetes de anlisis

Los paquetes de anlisis constituyen una divisin del sistema de software que tiene sentido desde el punto de vista de los expertos en el dominio. Cada paquete de anlisis corresponde a uno o varios subsistemas enteros, y puede servir para repartir el trabajo del anlisis entre varias personas o equipos. La descomposicin del software en paquetes se establece cuando uno tiene una idea que considera suficientemente fiable de la cantidad de trabajo y del nmero y la complejidad de los diagramas, situacin a la cual se puede haber llegado tanto al principio de la etapa de anlisis como un tiempo despus. Se pueden asignar paquetes separados a los grandes procesos del negocio o bien a los actores primarios, y en cualquier caso, los casos de uso entre los que hay relaciones de extensin, inclusin o generalizacin deben asignarse al mismo paquete. Puede suceder que una clase (generalmente una clase de entidad) se utilice en ms de un paquete; si hay diferentes clases compartidas por los mismos paquetes, se puede hacer un paquete aparte con stas, mientras que si slo hay una clase, se la puede dejar fuera de los paquetes. Tambin se puede desarrollar la clase dentro de un paquete en el que se creen los objetos, por ejemplo mientras que los otros la utilizaran. En cualquier caso, entre los paquetes que utilizan la misma clase o clases y la clase o paquete mencionado se establecen las relaciones de dependencia correspondientes.

2.2. Los paquetes de servicios

Los paquetes de servicios* son subdivisiones de los paquetes de anlisis desde un punto de vista que podramos denominar comercial, es decir, son opciones separadas en lo que respecta a las organizaciones clientes. Ya sabemos que los casos de uso son autnomos, en el sentido de que cada uno lo entrega de manera independiente al actor primario respectivo. Asimismo, hay casos de uso relacionados en el sentido de que no es posible poner en marcha uno si antes no se ha llevado a cabo otro (por ejemplo, no se
*. Podramos decir que los paquetes de servicios son opciones de catlogo comercial.

Editorial UOC

146

Ingeniera del software

puede emitir una factura para un cliente si antes no se ha creado el pedido correspondiente); en estas circunstancias, es lgico que ambos casos formen parte del mismo paquete de servicios. En cambio, un caso de uso relativo a la obtencin de estadsticas sobre el tiempo transcurrido entre la creacin de un pedido y la emisin de la factura correspondiente podra formar parte de un paquete de servicios opcional de estadsticas, que unas empresas clientes del software compraran y otras, no (aunque el actor de los tres casos de uso fuera el mismo). Los paquetes de servicios presentan las caractersticas siguientes: Comprenden casos de uso relacionados. Generalmente, sus casos de uso tienen que ver slo con un actor o, en cualquier caso, con pocos. Son indivisibles, en el sentido de que un cliente o tiene un paquete de servicios completo, o no lo tiene. Pueden ser incompatibles o, por el contrario, uno puede necesitar de otro o de varios. En un caso de uso pueden intervenir varios paquetes de servicios. Existen muy pocas relaciones de dependencia entre elementos de paquetes de servicios diferentes y, en consecuencia, se pueden analizar, disear y ms adelante mantener de manera totalmente independiente o casi. Se pueden reutilizar, por lo menos entre diferentes configuraciones del sistema de software. La descomposicin de los paquetes de anlisis en paquetes de servicios se realiza asignando un paquete de servicios a cada conjunto de casos de uso opcional.

3. Revisin de los casos de uso

La base de partida para el anlisis es la documentacin sobre los casos de uso elaborada en la etapa anterior. Por lo tanto, conviene que sta sea precisa y detallada. Si la documentacin se haba realizado con el objetivo principal de ser

Editorial UOC

147

Captulo V. Anlisis orientado a objetos

la base de un acuerdo entre usuarios y desarrolladores, puede ocurrir que no cumpla estas condiciones y ser necesario revisarla. Podran existir carencias como que no se muestren las relaciones entre casos de uso o que haya algunas ambigedades en la terminologa utilizada en las descripciones textuales. Si no se han estudiado suficientemente las relaciones entre casos de uso, podra ser que haya dos casos que realicen funciones parecidas, quiz de manera contradictoria. Es posible que la descripcin de la funcin de un caso de uso realizada en lenguaje ordinario sea ambigua en cuanto a las combinaciones de condiciones; entonces tal vez sea conveniente escribirla de nuevo en forma de seudocdigo.

4. Especificacin de las clases de anlisis

Se consideran los tres tipos de clases de anlisis que mencionamos a continuacin: 1) Las clases de frontera (en ingls, boundary classes) representan en el nivel de anlisis la interfaz de usuario por pantalla. Debe haber al menos una para cada papel de cada actor; por lo tanto, cada una representa la interfaz de usuario entre un caso de uso y un actor. Las clases de frontera representan objetos grficos complejos como ventanas, dilogos por pantalla y mens; en esta etapa no se pretende describir los detalles del formato de estos objetos y, por lo tanto, normalmente no tendrn atributos pero pueden tener relaciones de agregacin.
Ejemplo de agregacin entre clases de frontera Una relacin de agregacin podra ser la que hay entre un formato de pantalla y un botn de la misma, cuando se pone en marcha un proceso.

2) Las clases de entidades corresponden a los objetos del dominio, es decir, los que modelan entidades o acontecimientos del mundo real de los que el software debe utilizar informacin (que son los atributos de estas clases). Muchos de

Editorial UOC

148

Ingeniera del software

estos objetos tendrn que ser persistentes, es decir, deben durar ms que el proceso que los crea, lo cual obliga a guardarlos en algn fichero o base de datos. 3) Las clases de control corresponden a objetos internos del software y no persistentes. Las operaciones de este tipo de clases contienen la parte principal de los algoritmos de aplicacin (slo quedan fuera de la verificacin de la informacin entrada por la pantalla y la lectura y grabacin de los objetos persistentes). Generalmente, no tendrn atributos. En un caso de uso puede haber cualquier nmero raramente no habr ninguna pero si hay ms de una, debe haber una que controle el conjunto del caso de uso. El hecho de distinguir estos tres tipos de clases da ms estabilidad a las clases de cada uno de ellos. As, si se modifica la manera en que se presenta la informacin al usuario sin cambiar el procesamiento de los datos, slo hay que modificar clases de frontera. Si se cambian los algoritmos de proceso de los datos sin cambiar la especificacin de los datos ni su presentacin a los usuarios, slo ser necesario modificar clases de control. Para cada uso, se realiza un diagrama de colaboracin donde figuran las clases de los tres tipos y las operaciones que se piden una a la otra. La notacin para este tipo de clases es la siguiente:

Esta notacin, igual que esta tipificacin de las clases, no forma parte del UML.

4.1. Identificacin de las clases de entidades

Probablemente, es el paso ms difcil y tambin el que tiene ms repercusiones sobre los pasos y etapas posteriores.

Editorial UOC

149

Captulo V. Anlisis orientado a objetos

La identificacin de las clases de entidades consiste en identificar unas primeras clases mediante las cuales se pueda especificar los casos de uso en forma de interacciones. Muchas de estas clases pasarn al diseo y a la implementacin, etapas en las que se definirn muchas ms clases, cuyo papel ser de implementacin, y no conceptual. Buscamos clases en el sentido habitual de conjuntos de objetos homogneos que tienen unos mismos datos (atributos) y comportamiento (operaciones). Adems y a diferencia de cuando se elabora el modelo del negocio nos interesan las clases de dentro del software y no del entorno.
Clases de entornos y de entidades Las clases del entorno pueden ser actores de los casos de uso. En cambio, las clases que sean el modelo de cosas del entorno tratadas por el software s que son clases de entidades. Regla poco recomendable para determinar las clases fundamentales Una de las reglas utilizadas para determinar cules deben ser las clases fundamentales es buscar los sustantivos que haya dentro de la documentacin textual de los requisitos y, a continuacin, revisar esta lista desde diferentes puntos de vista. sta no es una tcnica muy aconsejable porque dentro de la documentacin textual hay siempre muchos sustantivos que no corresponden a clases, a menudo hay clases importantes que no se designan explcitamente por un sustantivo e incluso puede suceder que los desarrolladores que no deben tener necesariamente una formacin lingstica slida tengan dificultades para identificar los sustantivos, sobre todo cuando son idnticos a formas verbales o adjetivos.

He aqu algunas fuentes de clases de entidades: Una buena fuente de clases, si existen, la constituyen las bibliotecas de clases ya definidas y programadas donde se puedan encontrar clases que tengan relacin con los objetivos del software. Una de las ventajas de las bibliotecas de clases es que no slo conseguiremos identificar clases, sino tambin reutilizarlas. Clases sugeridas por los expertos en el dominio. La documentacin (revisada) de los casos de uso, especialmente las descripciones textuales y el glosario: en trminos que aparecen a menudo, entidades definidas explcitamente y trminos que se dan por conocidos (todos ellos

Editorial UOC

150

Ingeniera del software

pueden ser, por ejemplo, personas y papeles de personas, objetos fsicos, acontecimientos, unidades organizativas empresas, grupos de estudiantes, equipos, departamentos, lugares), se eliminan los sinnimos y se adopta la forma singular. Se excluyen inmediatamente los trminos que son demasiado vagos o que corresponden a entidades exteriores al sistema, y tambin en general todo lo que sean acciones o procesos, ya que es ms probable que se trate de operaciones (a menos que tengan atributos). Nada impide utilizar las tres fuentes a la vez. Excepto el caso de clases ya implementadas, conviene eliminar las que tengan alguna de estas caractersticas: a) Clases sin atributos. Esto indica que el sistema no tiene informacin para tratar. b) Clases sin operaciones, es decir, que no tienen un papel ni activo ni pasivo en ninguna operacin. c) Clases que tienen slo un atributo; puede ser que realmente no sea una clase, sino un atributo de otra. d) Clases con un slo objeto. Si se da este caso, es necesario observar si hay otras con atributos y operaciones similares, e intentar unificarlas. Tambin hay que ver si no es preferible considerar los atributos y operaciones de este nico objeto como atributos y operaciones de clase.

4.2. Especificacin de los atributos de las clases de entidades

Los atributos de las clases de entidades son generalmente datos mencionados de forma explcita en los casos de uso. Esto significa que los usuarios los usan directamente. Puesto que el modelo de anlisis conviene que sea independiente del lenguaje de programacin, los tipos de los atributos sern tipos abstractos y no tipos soportados por un lenguaje de programacin concreto. Asimismo, conviene que se establezca cules son estos tipos. Por la misma razn, los nombres de los atributos no deben estar sometidos necesariamente a las restricciones de los nombres

Editorial UOC

151

Captulo V. Anlisis orientado a objetos

de ningn lenguaje de programacin concreto, pero para evitar cambiar los nombres al llegar al diseo, conviene que los nombres de atributo tengan un formato compatible con el de la mayora de los lenguajes de programacin.
Formato de los nombres de atributos compatible con la programacin Un formato compatible con la programacin podra ser, por ejemplo, atributos constituidos slo por letras, cifras y underscores, sin que stos puedan figurar ni al principio ni al final. Esto vale para todos los nombres en general: nombres de operaciones, de clases, de parmetros, etc.

4.2.1. Casos especiales en los atributos Ahora veremos una serie de casos especiales en los atributos: 1) Atributos cuyo valor es compartido por diferentes objetos. Sern atributos de clase. 2) Atributos no aplicables a todos los objetos de la clase. Se puede crear una superclase que tenga slo los atributos que sean aplicables a todos los objetos y despus una subclase o ms de atributos que sean aplicables a todos los objetos respectivos. 3) Atributos con valores repetitivos. A veces puede ser conveniente definirlos como clase aparte con una asociacin n a 1 con la primera, sobre todo si son atributos compuestos o pares de atributos con la misma cardinalidad. 4) Atributos derivados (edad, etc.). Slo se incluirn si figuran en salidas descritas en los casos de uso, mientras que los que sean simplemente un recurso para reducir la duracin de los procesos a cambio de utilizar ms espacio en memoria o en la base de datos no se introducirn hasta el diseo, que es cuando se tiene en cuenta este punto de vista.

4.3. Identificacin de las relaciones entre clases Llegados a este punto, tenemos una lista en principio completa, aunque provisional, de las clases del software.

Editorial UOC

152

Ingeniera del software

Clases de entidades y tablas relacionales Las clases de entidades con sus atributos son parecidas a las tablas de una base de datos relacional (ya se ha mencionado antes que muchas de las clases de entidad son persistentes). Pues bien, es como si la tablas estuvieran sin normalizar. De la misma manera que la normalizacin hace cambiar el contenido de las tablas en trminos de atributos y de filas, as como hace definir tablas nuevas, tambin habr atributos que pasarn de una clase a otra y se definirn clases nuevas. No obstante, asimismo, conviene tener claros los lmites de esta analoga: ni hay correspondencia clara entre los pasos de la normalizacin de tablas relacionales y los de la revisin de la lista de clases, ni sta se encuentra tan formalizada como aqulla, por ahora.

Se examinarn las relaciones de herencia, las asociaciones y las relaciones de agregacin. A pesar de que hablaremos sobre esto en este orden, es un proceso iterativo en el cual puede suceder, por ejemplo, que la identificacin de una asociacin haga cambiar una jerarqua de herencia.

4.3.1. Jerarquas de herencia Es necesario establecer las jerarquas de herencia, tarea que se realiza por medio de dos vas, la generalizacin y la especificacin.
Especificacin

En lo que respecta a la especificacin, hay que tener en cuenta lo siguiente: 1) Slo hay que aadir una subclase si sus atributos tendrn atributos, operaciones o asociaciones que no tendr el resto de los objetos de la superclase. Es preciso evitar sistemticamente subclases correspondientes a los diferentes estados que pueden tener los objetos de la superclase. Slo debe definirse una subclase para un estado si se da alguna de las circunstancias mencionadas. Como el join de dos tablas en una base de datos relacional. 2) Si se puede, hay que evitar la doble especificacin, es decir, que de una superclase se distingan dos conjuntos independientes de subclases. A veces, esto puede ser consecuencia del hecho de que la superclase sea en realidad la combinacin de dos clases.

Editorial UOC

153

Captulo V. Anlisis orientado a objetos

Ejemplo de combinacin de dos clases Consideremos el ejemplo siguiente, adaptado de uno de Richter: si las cuentas de un banco se dividen, desde un punto de vista, en cuentas corrientes y cuentas a plazo, y, desde otro, en cuentas de personas y cuentas de empresas, sera mejor distinguir dos clases diferentes cuentas y clientes unidas por una asociacin y con dos subclases en cada una, cuentas corrientes y cuentas a plazo, en cuentas, y personas y empresas, en clientes.

Generalizacin

En cuanto a la generalizacin, hay que tener en cuenta estos puntos: 1) Si diferentes clases de significado parecido tienen atributos u operaciones en comn, hay que considerar la posibilidad de definir una superclase comn a todas estas clases que agrupe todos los atributos y operaciones en cuestin. Para que los atributos comunes puedan ponerse dentro de la superclase, es necesario que estn definidos igual en todas las clases, pero las operaciones slo deben tener la misma signatura (o, por lo menos, el mismo nombre) y una funcin anloga a todas las clases, ya que las operaciones de la superclase pueden ser abstractas. La superclase ser abstracta, ya que todos sus objetos pertenecern a alguna de las clases iniciales (a menos que al definir la superclase nos demos cuenta de que hay objetos de sta que no son de ninguna de estas clases y que, por lo tanto, faltaban clases por identificar). Ahora bien, que la superclase sea abstracta no significa que deban serlo todas sus operaciones las operaciones que se realicen de la misma manera en todas las subclases sern operaciones concretas de la superclase. 2) Conviene situar todos los atributos y operaciones comunes lo ms arriba posible dentro de la jerarqua de herencia, aunque las operaciones deban ser abstractas. 3) Habiendo definido una superclase, puede ocurrir que una subclase tenga todos sus atributos y operaciones heredados, es decir, que no tenga ninguno propio; entonces se puede suprimir esta subclase, y la superclase ser evidentemente concreta. 4) No tiene sentido que una superclase abstracta tenga slo una subclase (y tampoco se prevean ms en el futuro). Ser necesario suprimir la superclase. En

Editorial UOC

154

Ingeniera del software

cambio, puede ser normal que suceda lo mismo con una superclase concreta, por ejemplo, como resultado de la situacin del punto anterior. 5) Una superclase abstracta puede heredar tanto operaciones concretas como operaciones abstractas, y sus operaciones propias pueden ser tanto abstractas como concretas. 6) Qu se puede hacer si hay tres subclases, y un atributo u operacin es comn slo a dos de stas? Una solucin es aadir un nivel intermedio en la jerarqua de herencia, de manera que las dos clases en cuestin sean subclases de una que tenga el atributo u operacin mencionado. No obstante, si tambin existiera un atributo u operacin que fuera comn a las subclases primera y tercera, sera necesaria una nueva subclase intermedia, y entonces la primera subclase lo sera de las dos subclases intermedias, ya que tiene ambas operaciones, y por lo tanto estaramos en un caso de herencia mltiple. En el caso de una operacin, existe la opcin adicional de incluirla dentro de la superclase de las tres subclases y redefinirla como una operacin nula dentro de la tercera subclase (esto slo sera viable si la superclase fuera abstracta, ya que si fuera instanciable y se crease un objeto de sta que tambin fuera de la tercera subclase, le sera aplicable la operacin tal como se habra definido en la superclase). Hablando de la agregacin veremos otra solucin a este problema.

4.3.2. Herencia mltiple

La herencia mltiple consiste en el hecho de que una clase tiene diferentes superclases y, por lo tanto, hereda atributos, operaciones, asociaciones y agregaciones de todas stas. Existe conflicto si la superclase hereda dos atributos, operaciones o asociaciones con el mismo nombre y diferentes propiedades (herencia repetida), ya que en principio no se sabe cul prevalece, y hay que establecer un criterio, poco o muy arbitrario, para decidirlo. Algunos lenguajes de programacin no soportan la herencia mltiple, y entonces en la etapa de diseo hay que adaptar el diagrama esttico, pero no por esta razn se debe renunciar a utilizar la herencia mltiple en el anlisis si procede.

Editorial UOC

155

Captulo V. Anlisis orientado a objetos

4.3.3. Interfaces

Recordad que las interfaces del UML equivalen a clases abstractas sin atributos y con todas las operaciones abstractas. En el lugar de las subclases, definidas estticamente, estn las clases que implementan la interfaz, que se pueden sustituir sin modificarla. Esto hace que las interfaces sean una alternativa a las clases abstractas que puede ser ventajosa desde el punto de vista de la flexibilidad.

4.3.4. Asociaciones Hay una asociacin entre clases cuando los objetos de una necesitan la colaboracin de objetos de otra para llevar a cabo sus operaciones. Por esta razn, es obvio que hay asociaciones entre las clases de frontera y al menos algunas clases de control, por un lado, y entre clases de entidades, por otro. Las clases de control que no estn asociadas a clases de frontera estarn asociadas a otras clases de control. En relacin con las asociaciones conviene tener en cuenta lo siguiente: 1) Tanto las asociaciones como los papeles que hacen las clases en las mismas pueden tener nombres. Muchas veces no es necesario dar a la vez nombres a la asociacin y a todos sus papeles, puesto que uno u otro sera banal, pero si la asociacin no tiene nombre, debe tenerlo al menos uno de sus papeles. 2) Entre dos clases (o ms) puede haber ms de una asociacin, con significado diferente (y entonces puede ser que estas asociaciones enlacen todas ellas los mismos objetos concretos o no). Es necesario que sean diferentes los nombres de estas asociaciones o los nombres de sus papeles.

Asociaciones diferentes: entre dos clases Consideremos el ejemplo siguiente, adaptado de Richter: en una clase de vuelos comerciales, hay la compaa, el nmero de vuelo, el aeropuerto de origen y el de destino, el da y la hora de salida, y todos los vuelos con el mismo nmero tienen la misma compaa y los mismos aeropuertos de origen y de destino. Una opcin me-

Editorial UOC

156

Ingeniera del software

jor, que evitara estas repeticiones, sera sustituir la clase por dos: una que tuviera el nmero de vuelo, la compaa y los aeropuertos de origen y de destino y otra que tuviera la fecha y hora de salida, con una asociacin de una a varias entre las dos (esto es anlogo al paso de la segunda a la tercera forma normalizada en bases de datos relacionales).

3) Si existen asociaciones entre la clase A y cada una de las subclases de la clase B, es mejor sustituirlas por una nica asociacin entre A y B; no slo el diagrama es ms sencillo, sino que, si se aade una nueva subclase, no es necesario aadir una nueva asociacin. 4) Puede haber una asociacin (binaria o no) entre una clase y ella misma.
Ejemplo de asociacin entre una clase y ella misma Todos los empleados de una empresa (menos uno) tienen un jefe que es tambin empleado. Ahora bien, un empleado no puede ser jefe de s mismo, y en general un objeto no puede estar asociado a s mismo, ya que esta situacin podra producir un bucle sin fin.

5) Conviene una clase asociativa cuando se da una de estas circunstancias: la asociacin tiene atributos o bien hay una clase cuya vida de los objetos est relacionada con la de los enlaces de la asociacin y slo tiene un objeto para cada enlace. 6) Conviene revisar cada asociacin con cardinalidad mltiple en los dos papeles para determinar si no debera ser una clase asociativa. Es decir, las asociaciones m : n.

4.3.5. Agregaciones

Las agregaciones se pueden considerar un caso particular de las asociaciones, en el cual el significado de la asociacin es que un papel es parte del otro en algn sentido, y ciertamente conviene aplicarlo, en general, siempre que nos encontremos en casos de este tipo. La agregacin, no obstante, tiene algunas propiedades que la pueden hacer til tambin para situaciones en las que puede sustituir a otras relaciones, principalmente de herencia, con vistas al hecho de que el software desarrollado sea ms flexible:

Editorial UOC

157

Captulo V. Anlisis orientado a objetos

La clase compuesta delega en las clases componentes las operaciones y atributos que hacen referencia a ellas. Esto no es imprescindible, pero es muy recomendable en general. Los componentes se pueden crear y borrar en tiempo de ejecucin, mientras que las subclases deben definirse en tiempo de compilacin. Los componentes sobre todo si la agregacin es composicin no es necesario que sean visibles desde el exterior, lo cual significa que se puede cambiar la estructura de los objetos de una clase compuesta sin afectar a otras clases. Entre dos clases puede haber varias relaciones de agregacin (que entonces debern distinguirse por el nombre), de la misma manera que puede haber distintas asociaciones. Algunas aplicaciones no obvias del concepto de agregacin son stas: 1) Para utilizar la agregacin como alternativa a las subclases, es necesario hacer lo siguiente: los atributos y operaciones que seran especficos de la subclase se ponen en una nueva clase que se define como componente de la anterior con una cardinalidad mnima de cero, de manera que los objetos de la clase inicial que deben tener los atributos y operaciones en cuestin tendrn este componente y los dems no lo tendrn. Para cambiar de subclase un objeto, sera necesario borrarlo y crearlo otra vez, ahora en la subclase nueva, con lo cual las eventuales referencias a ste dejaran de ser vlidas; con la agregacin, simplemente sera necesario borrar del objeto el componente correspondiente a la subclase antigua y aadirle el de la nueva. 2) Puesto que el valor mximo de la cardinalidad de un componente puede ser mayor que 1, el caso de los atributos con valores repetitivos descrito en otro subapartado puede ser resuelto con agregacin (en principio, composicin) en lugar de asociacin. 3) El hecho de que en una agregacin o composicin los componentes pueden ser compartidos sugiere una alternativa a la herencia mltiple, que adems soluciona la herencia repetida, ya que no habr dos atributos u operaciones con el mismo nombre, sino slo uno. 4) El caso de los atributos u operaciones compartidos por dos subclases de tres mencionado en otro subapartado se puede resolver poniendo todos los atributos y operaciones no comunes a dos subclases en una nueva clase que sera componente compartido de ambas.

Editorial UOC

158

Ingeniera del software

5) La herencia mltiple tambin se puede resolver al revs de como se ha hecho antes: haciendo que la subclase sea la clase compuesta y las superclases, sus clases componentes. Esta solucin permite aadir superclases sin que sea necesario modificar la subclase.

4.4. Identificacin de las clases de frontera, las clases de control y de las operaciones. Diagrama esttico de anlisis De la descripcin textual de los casos de uso salen las operaciones de las clases de frontera y tambin, de manera ms indirecta, las de las clases de control; las de las clases de entidades muchas veces estn implcitas, pero casi siempre son obvias.
Operaciones 1) Las operaciones de las clases de frontera son: introducir y presentar datos. 2) Las operaciones de las clases de entidades son: aadir, borrar, leer, regrabar o equivalentes.

Una manera sistemtica de buscar y documentar las clases de frontera, de control y las operaciones de los tres tipos de clases es elaborar diagramas de colaboracin simplificados de los casos de uso representando las tres clases de los tres tipos. Despus, conviene realizar un diagrama esttico en el que figuren todas las clases de los tres tipos, con los atributos y operaciones identificadas y con todas las relaciones entre ellas, que es el diagrama esttico de anlisis.

5. Especificacin formal de los casos de uso

Cuando llegamos a este punto, tenemos descrito de manera formal mediante el diagrama esttico de anlisis lo que podramos denominar la estructura esttica del software que se desarrolla. Queda representar de manera formalizada el comportamiento del sistema, y el modo ms natural de hacerlo es describiendo formalmente los casos de uso.

Editorial UOC

159

Captulo V. Anlisis orientado a objetos

En el paso de especificacin de las clases de anlisis se han elaborado unos diagramas de colaboracin simplificados de los casos de uso, cuya finalidad no era describir de manera formal y detallada el proceso de cada uno, sino identificar las clases de frontera y de control y las operaciones de stas y de las clases de entidades. La forma simplificada que se ha utilizado no tiene en cuenta la secuencia de los mensajes ni el hecho de que puedan ser repetidos un cierto nmero de veces o sujetos a condiciones. Esta especificacin puede ser suficiente para algunos casos de uso sencillos, pero otros necesitarn una especificacin complementaria; para stos, ser necesario realizar diagramas de secuencia o de colaboracin completos, o, a veces, diagramas de actividades. Tambin se pueden hacer diagramas de estados para ilustrar, ms que casos de uso en particular, el comportamiento de algunas clases de entidades o de control. En el caso de las primeras, el diagrama de estados seguramente repetir desde otro punto de vista lo que ya se haya especificado en los casos de uso afectados, mientras que en el caso de clases de control, puede formar parte de la descripcin de su comportamiento.

6. Anlisis de la interfaz de usuario

El anlisis de la interfaz de usuario parte de la informacin siguiente: la documentacin de las tareas futuras, las especificaciones de usabilidad, la lista de las clases frontera, y tiene como objetivo un esquema del contenido de cada ventana asociada a una clase de frontera, excepto las denominadas ventanas secundarias, que slo sirven para aspectos como presentar mensajes al usuario o pedirle confirmaciones o la introduccin del valor de un parmetro. Es muy importante comentar con los usuarios el contenido de las ventanas y la interaccin entre el actor y el sistema.

Editorial UOC

160

Ingeniera del software

7. Ejemplo
Ya hemos visto un ejemplo de recogida y documentacin de requisitos. Ahora continuaremos el proceso realizando el anlisis para el mismo caso.

7.1. Revisin de los casos de uso

Consultad la documentacin textual en el subapartado 6.6.3 del captulo Recogida y documentacin de requisitos de esta obra. Los casos de uso obtenidos en la etapa anterior son sencillos y parece que tal como son ya se pueden utilizar como base para los pasos posteriores. Ahora bien, en la documentacin textual, en el apartado de Otros requisitos, se indica que debe ser posible consultar, modificar y borrar toda la informacin. Para cumplir con este requisito, sera necesario aadir algunos casos de uso, triviales en general; no se ha hecho, porque no aportaran ningn concepto nuevo importante y alargaran mucho el ejemplo. En cualquier caso, conviene tener presente que en sistemas de software reales la informacin debe poderse modificar (para corregirla, por lo menos), que toda la informacin se debe poder consultar a menudo de diferentes maneras y que raramente hay informacin eterna; hay que borrar la que ya no sea necesaria (a veces, puede ocurrir que, en lugar de borrar totalmente la informacin que ya no se utiliza, se copie en un fichero histrico, normalmente en soportes no permanentemente on-line como disquetes y cintas magnticas).

7.2. Paquetes de anlisis y de servicios Evidentemente, en la realidad, en un caso tan sencillo como ste slo habra un paquete. Sin embargo, si atendemos al grado de dependencia entre los casos de uso, podramos distinguir dos paquetes de anlisis: Locales , que comprende los casos de uso relativos a los locales y propietarios (los casos de uso 1, 2 y 3), y los referentes a contratos y alquileres (el resto); dentro del primero podramos distinguir dos paquetes de servicios: BasicoLocales e Informes si consideramos

Editorial UOC

161

Captulo V. Anlisis orientado a objetos

opcional la introduccin del informe del inspector, y Alquileres, dentro del cual se podra considerar que los casos de uso 6 y 7 son opcionales y constituyen un paquete de servicio Consultas separado de Contratos, que comprende los casos de uso 4 y 5. El esquema de las relaciones entre los paquetes sera el siguiente:

Las flechas como las del diagrama indican relaciones de dependencia.

7.3. Identificacin de las clases de entidades

Empezaremos por identificar las clases de entidades a partir de los casos de uso. Para cada caso de uso se indican las clases que se encuentran; cuando una clase ya se haba identificado en un caso de uso anterior, su nombre va seguido de un asterisco, mientras que las clases que son dudosas van seguidas de un interrogante. Caso de uso nmero 1: Aadir local. Clases: Local, Propietario, Zona? Caso de uso nmero 2: Aadir propietario. Clases: Propietario*, Particular? Empresa ?

Editorial UOC

162

Ingeniera del software

Caso de uso nmero 3: Introducir informe. Clases: Local*, Instalacin? Inspector? Caso de uso nmero 4: Introducir contrato. Clases: Local*, Arrendatario, Contrato, Vendedor? Caso de uso nmero 5: Aadir alquiler. Clases: Alquiler*. Caso de uso nmero 6: Aadir arrendatario eventual. Clases: Arrendatario eventual. Caso de uso nmero 7: Buscar locales. Clases: Local*.
Comentarios

Las clases Zona e Instalacin se descartan porque no tienen ningn atributo y, por lo tanto, se pueden considerar atributos de otras clases. Inspector y Vendedor, que no se mencionan en la descripcin de los casos de uso, pero s en las cuestiones que hay que aclarar y sus propuestas, estn en el mismo caso. Particular y Empresa se descartan como clases (seran subclases de Propietario y de Arrendatario) porque no tienen ni atributos ni operaciones propias. Por lo tanto, la primera lista de clases de entidades es sta: Local, Propietario, Arrendatario y Arrendatario eventual.

7.4. Especificacin de los atributos de las clases de entidades En la lista que vemos a continuacin, presentamos los atributos de las clases de entidades correspondientes al ejemplo que consideramos. Clase Local: zona(string), tipo(string), numero(integer), direccion(text), superficie(real), caracteristicas(text), volumen(real), caracteristicas_polivalente(text), NIF_propietario (string), accesibilidad(text), instalaciones(text), agente(string), inspector(string).
Clase El atributo nombre del Propietario, Arrendatario y Arrendatario eventual contiene los apellidos y nombre o bien la razn social segn si el propietario es una persona fsica o una empresa.*
*. Conviene que los nombres de los atributos respeten el formato soportado por los compiladores; por lo tanto, es mejor no poner acentos ni caracteres especiales.

Editorial UOC

163

Captulo V. Anlisis orientado a objetos

Clase Propietario: NIF (string), nombre(text), direccion(text), telefono(string). Clase Arrendatario: NIF(string), nombre(text), direccion(text), telefono(string). Clase Arrendatario eventual: NIF(string), nombre (text), direccion(text), telefono(string), tipo_local(string), zona(string), superficie_minima(real), varios (text). Clase Contrato: NIF_arrendatario(string), NIF_propietario(string), vendedor(string).

7.5. Relaciones

7.5.1. Relaciones de herencia

Puesto que las tiendas-almacn tienen un atributo propio, el volumen, se define TiendaAlmacen como subclase de Local. Debido a que los polivalentes tienen tambin un atributo propio, las caracteristicas_polivalente, se define la subclase Polivalente de TiendaAlmacen; puesto que los polivalentes son tambin oficinas, igualmente deben ser subclase y, por lo tanto, hay que definir Oficina como subclase de Local. La subclase Inmueble se aade por claridad del diagrama, ya que todos los locales que no son tiendas-almacn ni oficinas son inmuebles; por esta razn, Local es una clase abstracta.
Por claridad, el hecho de que una clase es abstracta se indica de dos maneras: con el nombre en cursiva y con la propiedad abstract. Recordad, sin embargo, que con una sola es suficiente.

Los atributos comunes a Propietario y Arrendatario se ponen dentro de una superclase abstracta, Cliente; ArrendatarioEventual es subclase de Arrendatario a consecuencia de los atributos. Puesto que resulta que Propietario y Arrendatario no tienen ms atributos que los heredados, podramos pensar en suprimirlas, pero no se hace porque tienen comportamiento diferente: Propietario tiene apartamentos y Arrendatario los alquila.

Editorial UOC

164

Ingeniera del software

Editorial UOC

165

Captulo V. Anlisis orientado a objetos

7.5.2. Asociaciones

En este diagrama podis ver las asociaciones del ejemplo:

La asociacin entre Propietario y Local se deduce del caso de uso 1: Aadir local, y la clase asociativa Contrato se deduce del caso de uso 4: Introducir contrato. Fijaos en que la asociacin Contrato se establece con la superclase Local y no con sus subclases, ya que es comn a todas. En cambio, las relaciones se establecen con las subclases Propietario y Arrendatario por la razn contraria. Observad tambin que se han podido suprimir los atributos NIF_propietario y NIF_arrendatario de las clases Contrato y Local, porque son redundantes con las asociaciones.
Implementacin de las asociaciones Podra suceder que a la hora de programar las asociaciones se implementasen precisamente mediante atributos como los que se acaban de ver (ms una lista de los cdigos de los locales de cada propietario), y entonces sera necesario volver a aadirlos; pero tambin se podran implementar las asociaciones de otras maneras.

Editorial UOC

166

Ingeniera del software

7.5.3. Agregaciones

Segn los requisitos, un inmueble se compone de tiendas-almacn y/o oficinas; por lo tanto, entre estas tres subclases hay las agregaciones correspondientes. Estas agregaciones son composiciones, puesto que cada tienda-almacn u oficina pertenece a un solo inmueble.

7.6. Identificacin de las clases de frontera, las clases de control y de las operaciones

Para cada caso de uso, realizaremos un diagrama de colaboracin simplificado. En todos los casos de uso se ha puesto que el actor pide una opcin a la clase de frontera Menu, que corresponde al men de la aplicacin, y sta la pasa a la clase de control GestorMenu, que llama a la clase de control principal del caso de uso. Los nombres de los mensajes sern operaciones de las clases destinatarias: los que van de las clases de frontera al actor no le piden ninguna operacin, como es lgico.
Caso de uso 1: Aadir local

Este caso de uso comprende el caso de uso 2: Aadir propietario, el cual, como sabemos, lo extiende cuando no se ha encontrado al propietario.

Editorial UOC

167

Captulo V. Anlisis orientado a objetos

Caso de uso 2: Aadir propietario

Caso de uso 3: Introducir informe

Como se puede ver en el diagrama de colaboracin de este caso de uso:

Se busca el local y, si no se encuentra, se enva un mensaje de error al actor. Si se ha encontrado, una vez introducidos los datos del informe se modifica el objeto Local dando valores a los campos correspondientes y grabndolo de nuevo en la base de datos.
Caso de uso 4: Introducir contrato

Como podis observar en el diagrama, si no se encuentra al arrendatario, se crea (caso de uso 5: Aadir arrendatario), pero, si no se encuentra el local, se en-

Editorial UOC

168

Ingeniera del software

va un mensaje de error al actor. La clase ImpresionContrato imprime los datos del contrato.

Casos de uso 5 y 6: Aadir arrendatario y Aadir arrendatario eventual

Sabemos que el caso de uso 6 es una especializacin del caso de uso 5, ya que difiere de ste en que se aaden los valores de los atributos que indican qu tipo de locales quiere el arrendatario eventual, que estn en la subclase ArrendatarioEventual. Por lo tanto, los podemos convertir en un nico caso de uso que crea o bien un objeto de Arrendatario o bien un ArrendatarioEventual, respectivamente.

Editorial UOC

169

Captulo V. Anlisis orientado a objetos

Caso de uso 7: Buscar locales

Como podis ver en el diagrama de colaboracin:

El actor da los argumentos de la consulta. Le sale una lista de los cdigos de los locales que cumplen las condiciones, dentro de la cual el actor puede elegir un local de la lista, y se le presentan all los datos del mismo (todos o bien todos excepto la direccin del local y el NIF del propietario).

7.7. Especificacin formal de los casos de uso

Seguramente habris observado que en algunos de los diagramas de colaboracin simplificados que acabamos de ver hay mensajes que slo se envan cuando se cumple una condicin, y que tambin, a veces, entran y salen diferentes mensajes de una misma clase sin que quede claro en qu orden lo hacen. Por lo tanto, ser necesario realizar una especificacin ms detallada de estos casos de uso. Puesto que ya hemos realizado un diagrama de colaboracin aunque sea simplificado, ahora utilizaremos el diagrama de secuencias, porque da una visin de los casos de uso que es complementaria de la que ya tenemos; slo se har para un caso de uso, el ms complicado, el caso de uso 4: Introducir contrato. Tambin veremos el diagrama de estados de la nica clase en que no es trivial, la clase Local.

Editorial UOC

170

Ingeniera del software

a) Diagrama de secuencias del caso de uso 4: Introducir contrato:

b) Diagrama de estados de la clase Local:

Editorial UOC

171

Captulo V. Anlisis orientado a objetos

7.8. Anlisis de la interfaz de usuario Veamos el esquema de ventana correspondiente a cada clase de frontera. 1) Clase PantallaAadirLocal.

2) Clase PantallaAadirPropietario

Editorial UOC

172

Ingeniera del software

3) Clase PantallaIntroducirInforme.

4) Clase PantallaIntroducirContrato

Editorial UOC

173

Captulo V. Anlisis orientado a objetos

5) Clase PantallaAadirArrendatario

6) Clase PantallaBuscarLocales

En la cabecera salen los valores de los argumentos de la bsqueda dados por el usuario y, debajo, la lista de los cdigos de los locales que cumplen las condiciones correspondientes. Informacin completa? sirve para indicar si el usuario quiere que aparezcan tambin la direccin del local y el NIF del propietario. Seleccin sirve para pedir los datos de un local concreto.

Editorial UOC

174

Ingeniera del software

7) Clase PantallaListaLocales

8) Clase PantallaDatosLocal El esquema de la ventana es el mismo que para la clase PantallaIntroducirInforme ms una opcin para imprimir su contenido.

Editorial UOC

175

Captulo V. Anlisis orientado a objetos

Conclusiones

Hemos visto cmo se lleva a cabo la etapa de anlisis segn un mtodo basado en el Rational Unified Process . El objetivo de esta etapa es modelar los requisitos de una manera adecuada para servir de base del desarrollo propiamente dicho del software. Se empieza por revisar los casos de uso especificados en la etapa anterior con el objetivo de eliminar redundancias y aadir eventuales casos de uso no pedidos explcitamente por los usuarios, pero que, sin embargo, son necesarios para satisfacer los requisitos. Despus se identifican las clases de entidades, sus atributos y las relaciones entre ellas, y a continuacin se realiza un diagrama de colaboracin simplificado para cada caso de uso con el objetivo de identificar las clases de frontera, de control y las operaciones de stas y de las clases de entidades. De este modo se acaba de obtener la informacin necesaria para elaborar el diagrama esttico de anlisis. Despus se realizan diagramas de interaccin ms detallados para los casos de uso que sean necesarios, y eventualmente se hacen tambin diagramas de actividades, de estados y transiciones. El anlisis de la interfaz de usuario consiste en describir el contenido de las ventanas asociadas a las clases frontera, partiendo de la lista de las mismas y de la descripcin de las tareas futuras. As se ha obtenido lo que hemos denominado modelo de anlisis.

Editorial UOC

177

Captulo VI. Diseo orientado a objetos

Captulo VI

Diseo orientado a objetos

Este captulo trata del diseo del software con tcnicas orientadas a objetos, aplicando las notaciones y conceptos del UML y siguiendo el ciclo de vida del Rational Unified Process . Recordemos que, en este ciclo de vida, el anlisis y el diseo constituyen un nico componente de proceso, pero nosotros los consideraremos dos etapas diferentes porque tienen una finalidad distinta y porque los resultados de uno y otro son tambin claramente diferentes. Se ver con detalle el papel del diseo en relacin con la etapa que le precede, el anlisis, y la que le sigue, la realizacin. Avanzamos, sin embargo, que as como el anlisis formaliza los requisitos recogidos anteriormente, el diseo es el primer paso de la elaboracin de una respuesta a estos requisitos. Una de las ventajas esperadas de la tecnologa orientada a objetos, y quiz la ms importante, es la posibilidad de reutilizar software. Durante el diseo se decide qu se reutiliza y qu se hace de nuevo y, por tanto, en este mdulo tenemos que tratar las tcnicas de reutilizacin. Dentro del diseo, distinguiremos los pasos siguientes:

El diseo arquitectnico. El diseo de los casos de uso. La obtencin del diagrama esttico de diseo. La especificacin de las clases del diseo. El diseo de la persistencia. El diseo de la interfaz de usuario. El diseo de los subsistemas.

Editorial UOC

178

Ingeniera del software

1. El papel del diseo

La etapa de diseo hace de puente entre el anlisis y la realizacin. El modelo del anlisis describe las funciones que tiene que desempear el software y tambin especifica los eventuales requisitos no funcionales, es decir, plantea el problema que se debe resolver con el software. Las etapas siguientes tendrn que ver con la elaboracin de una solucin a este problema. Ahora bien, el modelo del anlisis no es una base adecuada para emprender directamente la realizacin, ya que no se expresa en trminos de la tecnologa que deber utilizar en el proyecto (principalmente el lenguaje de programacin y la herramienta de apoyo a la interfaz grfica de usuario).
Justificacin de la etapa de diseo Est claro que, al especificar los requisitos, se habrn tenido en cuenta las posibilidades generales de la tecnologa disponible, con el fin de no pedir requisitos imposibles, ni tampoco infrautilizar esta tecnologa en el caso de que permitiera atender ms necesidades del usuario o atenderlas mejor (por ejemplo, hoy da el anlisis considera implcitamente que la presentacin de la informacin a los usuarios se har mediante pantallas con apoyo de grficos e impresoras modernas). No obstante, seguramente no se habr tenido en cuenta, si no es de una manera muy general, en qu lenguaje de programacin se implementarn las clases y qu clases programadas en proyectos anteriores se reutilizarn, o qu sistema de gestin de bases de datos se usar.

Dentro del Rational Unified Process, el diseo se hace principalmente al final de la fase de elaboracin y al comienzo de la de construccin.

1.1. La relacin entre el diseo y la realizacin La realizacin da como producto el software acabado, y comprende la programacin propiamente dicha ms la generacin de ficheros binarios y ejecutables, la prueba uno a uno de los mismos y el enlace de todo. Las clases definidas en el diseo se programan una a una, y se generan los componentes y los subsistemas. Entre el modelo del diseo y el software acabado existe la misma relacin que entre el proyecto de un edificio y el edificio construido.

Editorial UOC

179

Captulo VI. Diseo orientado a objetos

1.2. La utilidad del diseo Hemos visto que en proyectos muy sencillos se puede llegar a prescindir del anlisis. En cambio, el diseo es siempre necesario. Preguntar para qu sirve el diseo es lo mismo que preguntar por qu no se puede implementar directamente el modelo de anlisis. Jacobson, Booch y Rumbaugh mencionan una relacin de 1 a 5 entre el coste del anlisis y el del diseo. Este hecho ya indica que en el modelo del diseo hay muchas ms clases y operaciones que se deben identificar y especificar antes de programarlas.

2. La reutilizacin
La reutilizacin en el diseo orientado a objetos tiene cuatro modalidades: la reutilizacin de clases, la reutilizacin de componentes, los patrones y los marcos. Meyer menciona las siguientes ventajas de la reutilizacin: Se abrevia el desarrollo del software. Disminuye el trabajo de mantenimiento del software en el futuro. Mejora la fiabilidad. A menudo el cdigo reutilizado es ms eficiente, probablemente porque se ha ido mejorando con el tiempo. Es cierto que el cdigo hecho a medida para un caso concreto podra ser ms eficiente, pero en la prctica no es posible optimizar todo el cdigo de un proyecto. Se gana en coherencia. Normalmente no se reutiliza una sola clase, sino varias, procedentes de una misma librera y que, por tanto, seguramente estarn programadas segn las mismas normas y con el mismo estilo. Preservacin de la inversin. Si se reutiliza un buen fragmento de cdigo, ser mucho ms difcil que se pierda, ya que habr muchas copias.

2.1. La reutilizacin de clases Principalmente, se reutilizan clases que tienen funciones independientes del dominio, como elementos de interfaz grfica y estructuras de datos generales.

Editorial UOC

180

Ingeniera del software

Por lo comn, la reutilizacin de clases de un dominio concreto slo es viable en el caso de sistemas de software de una misma organizacin. Las clases que se reutilizan se suelen agrupar por funcin en libreras como los paquetes de Java. La reutilizacin de clases se puede hacer de varias maneras. La ms sencilla y directa es reutilizar la clase misma, en forma fuente o compilada. No obstante, si se le tienen que aadir o modificar operaciones o atributos, hay que complementarla con subclases o mediante agregacin. Si la clase es abstracta, la nica manera de reutilizarla es, evidentemente, con subclases.

2.2. La reutilizacin de componentes

Un componente es un conjunto de clases, cuyos objetos colaboran en tiempo de ejecucin con el fin de llevar a cabo una funcin concreta. Un componente implementa una interfaz determinada, que es el conjunto de todas las operaciones de sus clases que se pueden pedir desde el exterior del componente. Por tanto, se puede sustituir un componente por otro que implemente la misma interfaz. Un componente, por el hecho de que implementa una interfaz, se comporta como una clase, y las clases que lo componen no son visibles desde el exterior. Para que un componente se pueda reutilizar correctamente, se debe conocer su interfaz y tambin el contrato. El contrato describe los efectos de las operaciones comprendidas en la interfaz y qu invariantes mantiene.

2.3. Los patrones

Los patrones (en ingls, patterns) son una manera organizada de recoger la experiencia de los diseadores de software para volverla a utilizar en casos parecidos. Cuando un experto trabaja en un problema, raramente inventa una solucin del todo nueva, partiendo de cero, sino que en general recuerda algn caso que tiene semejanzas con el suyo y adapta la solucin. Esto es lo que acostumbramos a denominar aplicar la experiencia, y se supone que es lo que hace que los expertos lo sean.

Editorial UOC

181

Captulo VI. Diseo orientado a objetos

No es necesario decir que sera mucho mejor tener esta experiencia recogida y documentada de manera ms o menos formal para hacerla accesible a otros expertos o futuros expertos, por un lado, y para hacer ms sistemtica y coherente la aplicacin de la experiencia por los mismos expertos, por el otro. Un patrn no es un programa, aunque puede incluir un programa como muestra, pero no para utilizarlo directamente. Un patrn es una idea de diseo e implementacin detallada y prctica (una receta) que constituye un esbozo de solucin de un problema que se presenta con una cierta frecuencia. Los detalles de esta solucin cambian para cada caso al que se aplica. Por tanto, el ncleo de un patrn es una pareja problema-solucin. En general, un patrn no est vinculado a un mtodo concreto de diseo. De hecho, muchos patrones se pueden utilizar tanto en diseo orientado a objetos como en diseo estructurado, si bien los patrones tienden a estar documentados en forma orientada a objetos, simplemente porque se han divulgado cuando esta tecnologa ya estaba en boga. Los patrones representan un nuevo intento de aumentar la reusabilidad del software (como la tecnologa de objetos, por ejemplo) partiendo de la idea de que en casos determinados en los que no se puede reutilizar cdigo, al menos se puede reutilizar el diseo, como mnimo las ideas bsicas. De igual manera que los entornos de desarrollo orientados a objetos acostumbran a ofrecer una amplia biblioteca de clases predefinidas, en el diseo orientado a patrones se puede disponer de recetarios de patrones preexistentes, que hay que esperar a que se vayan enriqueciendo con el paso del tiempo. Adems, tambin hay que esperar a que vayan apareciendo (ya han comenzado a hacerlo) especficos por dominios. Como programacin en tiempo real, programacin distribuida y muchos otros. El principal beneficio que se espera obtener de la utilizacin de patrones es que no hay que pensar una solucin para muchos de los problemas de diseo ms frecuentes y, por tanto, se puede concentrar el esfuerzo de diseo en los aspectos ms innovadores de cada proyecto.
Patrones y derechos de propiedad Sin duda se plantearn, si todava no se han presentado, cuestiones como patentes y propiedad intelectual sobre patrones, patrones que sean secreto de empresa, etc.

Editorial UOC

182

Ingeniera del software

2.3.1. Caractersticas de los patrones

Las caractersticas ms importantes que presentan los patrones son las que mencionamos continuacin: 1) Recogen la experiencia, es decir, son un extracto y un denominador comn de numerosos diseos anteriores: no se inventan en un momento dado. 2) Son algo ms amplio que, por ejemplo, una clase o un objeto. 3) Crean vocabulario. Dentro de un diseo se hace referencia a los patrones por su nombre. En particular, dentro de un patrn se puede hacer referencia a otros. 4) Son un instrumento de documentacin, dado que dentro de la documentacin del diseo, una referencia a un patrn ahorra describir con detalle una parte del diseo. 5) Si se utiliza el mismo patrn, facilitan la coherencia de los diseos por todas las partes donde se presenta el mismo problema. 6) No dan una solucin completa a un problema en un caso concreto: slo proporcionan una solucin genrica que hay que completar. 7) Ayudan a hacer frente a la complejidad del diseo, resolviendo de entrada algunas partes.

2.3.2. Componentes de los patrones

Un patrn tiene las cuatro partes que mencionamos a continuacin: 1) El nombre. La asignacin de nombre a un patrn no es una cuestin trivial, ya que, por el hecho de que crean vocabulario, es vital que en los nombres de los patrones no haya sinnimos o alias, ni menos an homnimos; y esto, no slo en lo que respecta al proyecto o empresa, sino tambin en cuanto a la literatura sobre patrones en general, dado que cualquier experto que mire el diseo tiene que dar la misma interpretacin. 2) El contexto. Es el entorno o la situacin dentro de la cual se presenta el problema que el patrn resuelve. A menudo se define en trminos de una lista de situaciones.

Editorial UOC

183

Captulo VI. Diseo orientado a objetos

3) El problema. Se define en trminos de lo que se conoce como fuerzas: requisitos que la solucin tiene que cumplir, restricciones y cualidades que se desea que tenga la solucin. A veces, las fuerzas estn contrapuestas. 4) La solucin. Es un compromiso entre las fuerzas. La solucin tiene los dos aspectos siguientes: Esttico o estructural, que se expresa en trminos de componentes y relaciones entre los mismos. Dinmico o de comportamiento, que describe las funciones de cada componente y cmo colaboran entre s a lo largo del tiempo.

2.3.3. Clasificaciones de los patrones

Se admiten varios tipos de clasificaciones para los patrones. En concreto, se les puede clasificar segn el nivel, el propsito o el mbito: 1) En la clasificacin por nivel, algunos autores hablan simplemente de patrones de diseo. Otros distinguen tres clases: Patrones arquitectnicos. Se utilizan durante el diseo arquitectnico y tratan sobre la estructuracin de un sistema de software en subsistemas. Patrones de diseo propiamente dichos. Patrones dirigidos a resolver problemas puntuales del diseo.
Diversidad de definiciones para patrn La inclusin de las frases hechas permite ver que no todos los autores entienden lo mismo por patrn, ya que algunas definiciones afirman que los patrones no tienen que estar vinculados a un lenguaje de programacin.

Frases hechas (idioms). Describen la manera de implementar algo (eventualmente un componente de un patrn de diseo) en un lenguaje de programacin concreto.

Editorial UOC

184

Ingeniera del software

2) La clasificacin por propsito establece la jerarqua siguiente: Patrones de creacin. Se utilizan para la instanciacin, con el fin de hacer que el software sea independiente de cmo las clases y objetos se crean, representan y agregan. Los patrones en el nivel de clase utilizan herencia para variar la clase, mientras que en el nivel de objetos se delega la instanciacin a otro objeto. Patrones de estructura. Hacen referencia a la manera como las clases y los objetos se combinan para formar estructuras mayores. En el nivel de clase se utiliza la herencia para agregar interfaz o implementacin, y en el nivel de objetos se hace agregacin en tiempo de ejecucin. Patrones de comportamiento. Describen la comunicacin entre clases y objetos. En el nivel de clases se aplica la herencia y en el nivel de objetos, la agregacin. 3) La clasificacin por mbito de los patrones identifica los siguientes: Patrones sobre clases. Hacen referencia a las relaciones de herencia, que se establecen en tiempo de compilacin. Patrones sobre objetos. Hacen referencia a las relaciones entre objetos, las cuales pueden variar dinmicamente en tiempo de ejecucin.

2.3.4. Un ejemplo de patrn: Composite

El patrn Composite* tiene como objetivo representar jerarquas de estructuras parte-todo. Este patrn se puede utilizar en los casos que se mencionan a continuacin: a) Cuando se quieren representar jerarquas de tipo de agregacin entre objetos.
*. E. Gamma; R. Helm; R. Johnson; J. Vlissides (1995). Design Patterns . Addison-Wesley.

Editorial UOC

185

Captulo VI. Diseo orientado a objetos

b) Cuando se quiere que los clientes no necesiten distinguir entre objetos compuestos y no compuestos. Los clientes tratarn todos los objetos de la misma manera.

Las clases que figuran en esta estructura tienen las funciones siguientes: a) La clase Componente implementa el comportamiento de los objetos eventualmente compuestos y declara una interfaz para acceder a sus componentes y gestionarlos. b) La clase Hoja representa los objetos que no tienen componentes. c) La clase Composite define el comportamiento de los componentes que tienen componentes, y almacena estos ltimos.

2.3.5. Sistemas de patrones

Ya se ha dicho que los patrones a menudo se refieren a otros patrones, ya sea porque se utilizan en su implementacin, ya sea porque los complementan. Por tanto, ms que de listas de patrones hablaremos de sistemas de patrones relacionados. La documentacin de un sistema de patrones ser algo ms que la suma de la documentacin de cada uno de los mismos: habr que incluir tambin un esquema de las relaciones entre stos y la descripcin de las dependencias entre ellos cuando se utilizan juntos.

Editorial UOC

186

Ingeniera del software

Algunas caractersticas deseables en un sistema de patrones son las que enumeramos a continuacin: 1) Cantidad. El sistema de patrones debe tener un nmero suficiente de patrones de varias clases o niveles; de otro modo no se puede hacer diseo basado en patrones, sino slo diseo ordinario utilizando algn patrn. 2) Descripcin. Todos los patrones del sistema deben estar descritos de una manera tan uniforme como sea posible. 3) Relaciones. Las relaciones entre patrones tienen que estar indicadas explcitamente. 4) Organizacin. El catlogo de patrones del sistema debe estar organizado de manera que sea fcil encontrar el patrn ms adecuado en cada caso. En particular, debe haber un sistema de criterios de clasificacin como los descritos con anterioridad. 5) Practicidad. El sistema de patrones tiene que ser prctico, en el sentido de que se vea fcilmente cmo se pueden utilizar e implementar los patrones. 6) Acceso. El sistema tiene que ser abierto: debe ser posible que se integren con facilidad nuevos patrones, que se tienen que poder incorporar de manera natural al esquema de clasificacin mencionado, y los patrones que ya existen se deben poder adaptar a los cambios tecnolgicos. Cuando se habla de sistemas de patrones, se piensa principalmente en sistemas pblicos, como los descritos en libros. No obstante, tambin puede haber sistemas para uso interno de una empresa o de un proyecto, que probablemente incluyan tambin patrones pblicos. Los sistemas de patrones ms conocidos son los que mencionamos a continuacin: a) El de Gamma, Helm, Johnson y Vlissides.* b) El sistema de Buschmann, Meunier, Rohnert, Sommerlad y Stal.
*. La Banda de los cuatro Los autores Gamma, Helm, Johnson y Vlissides se conocen de manera informal con el nombre de Gang of Four (La Banda de los cuatro).

Editorial UOC

187

Captulo VI. Diseo orientado a objetos

c) Los patrones documentados por Larman, que corresponden a principios generales de diseo ms que a problemas especficos. Estos sistemas se publicaron en el mismo orden en el que se han mencionado, y cada sistema hace referencias a los anteriores. Por esta razn, creemos que se pueden considerar un solo sistema. Mencionamos todos los patrones en una nica tabla que podis ver a continuacin. La descripcin detallada de cada patrn se puede encontrar en las obras citadas en la bibliografa de este mdulo.
Nombre Abstract Factory Adapter Blackboard Bridge Estructura Arquitectnico Estructura GHJV BMRSS GHJV Tipo Creacin Sistema GHJV Propsito Proporciona una interfaz para crear objetos relacionados sin que sea necesario saber su clase. Sustituye la interfaz de una clase, lo cual permite reutilizar algunas clases. Coordina la comunicacin entre los componentes de sistemas de software distribuidos. Desacopla una clase abstracta de su implementacin para que puedan variar independientemente. Permite que la construccin de un objeto complejo pueda crear diferentes representaciones. Implementa llamadas de operaciones por medio de otros objetos. Proporciona transparencia respecto a la ubicacin y los mecanismos de conexin entre cliente y servidor. Convierte una llamada de una operacin en un objeto que se puede manipular. Separa la peticin de una operacin de su ejecucin con la finalidad de permitir deshacerla, por ejemplo. Construye una jerarqua de composicin de objetos. Asigna el tratamiento de los acontecimientos a las clases que representan el sistema o la organizacin en conjunto, o un papel o un caso de uso. Asigna a la clase B la responsabilidad de crear los objetos de otra clase A si B ya agrega, contiene, registra o usa de manera principal objetos de A o tiene la informacin para inicializarlos.

Builder Chain of responsibility ClientDispatcherServer Command Command Processor Composite Controller

Creacin Comportamiento Estructura

GHJV GHJV BMRSS

Comportamiento Comportamiento

GHJV BMRSS

Estructura Comportamiento

GHJV Larman

Creator

Estructura

Larman

Editorial UOC

188

Ingeniera del software

Nombre Decorator Dont call to Strangers

Tipo Estructura Comportamiento

Sistema GHJV Larman

Propsito Aade responsabilidades a un objeto dinmicamente, sin aadirlas a la clase. Limita la variedad de objetos a los cuales pide operaciones un objeto dentro de la implementacin de sus operaciones: slo l mismo o un atributo suyo, los parmetros de la operacin o los objetos creados dentro del mtodo. Asigna cada operacin a la clase que tienen los atributos que intervienen en la misma. Proporciona una interfaz nica a un subsistema con muchos objetos. Define una interfaz para instanciar un objeto, cuya clase se decide en el mbito de subclases. Permite que muchos pequeos objetos puedan ser compartidos haciendo que su estado sea independiente del contexto en que se usan. Asla de los mecanismos de comunicacin la comunicacin entre procesos. Asigna las operaciones a las clases de manera que la cohesin del diseo sea alta (es decir, que cada clase implemente un conjunto no demasiado grande de operaciones muy relacionadas). Asigna una operacin a una clase intermediaria para desacoplar la clase cliente de la servidora. Representa las reglas de un lenguaje mediante clases. Accede a los componentes de un objeto agregado uno detrs de otro, sin ver su contenido. Estructura una aplicacin en grupos de diferentes niveles de subtareas. Asigna las operaciones a las clases de manera que el acoplamiento entre las clases sea bajo, lo cual quiere decir que cada clase haga poco uso de operaciones de otras clases dentro de las suyas. El maestro reparte trabajo a varios esclavos idnticos y obtiene el resultado final a partir de los resultados obtenidos por stos. Define un objeto que encapsula la interaccin de otros.

Expert Facade Factory Method Flyweight

Comportamiento Estructura Creacin Estructura

Larman GHJV GHJV GHJV

ForwarderReceiver High Cohesion

Estructura Comportamiento

BMRSS Larman

Indirection Interpreter Iterator Layers Low Coupling

Comportamiento Comportamiento Comportamiento Arquitectnico Comportamiento

Larman GHJV GHJV BMRSS Larman

Master-Slave

Estructura

BMRSS

Mediator

Comportamiento

GHJV

Editorial UOC

189

Captulo VI. Diseo orientado a objetos

Nombre Memento

Tipo Comportamiento

Sistema GHJV

Propsito Captura y externaliza el estado de un objeto (sin violar su encapsulacin), para que pueda ser restituido ms adelante. Dentro de un software, separa un ncleo funcional de la funcionalidad aadida. Descompone un software interactivo en tres componentes: el Modelo que contiene la funcionalidad y los datos, la Vista que presenta la informacin en la pantalla y el Controlador que trata las entradas de informacin. Define una dependencia entre objetos de manera que cuando cambia el estado de un objeto se comunica el cambio a otros. Proporciona un estructura de tubos y filtros para tratar flujos secuenciales de datos. Conviene aplicar el polimorfismo (dar el mismo nombre a operaciones anlogas de clases diferentes) para que el objeto cliente no tenga que preguntar por la clase antes de pedirle la operacin. Descompone un software interactivo en una jerarqua de agentes que colaboran. Cada agente desempea alguna funcin de presentacin por pantalla, funcionalidad bsica (abstraccin) o comunicacin entre agentes (control). Instancia objetos haciendo copias de un prototipo. Proporciona un representante para un objeto, que no hay que crear hasta que se necesite efectivamente. Tambin puede controlar el acceso. Hace que los clientes de un componente pidan las operaciones a un representante de ste y no a l directamente, por razones de eficiencia, control de acceso u otras. Un publicador notifica sus cambios a varios suscriptores. Es una variante de Observe r. A veces conviene definir una clase que no corresponde a ninguna entidad del dominio, sino que es una pura invencin para agrupar operaciones de manera ms coherente que si estuvieran asignadas a clases de entidades. Proporciona un medio para cambiar dinmicamente la estructura y el comportamiento de un software. Garantiza que de una clase slo haya un objeto.

Microkernel Model-ViewController

Arquitectnico Arquitectnico

BMRSS BMRSS

Observer

Comportamiento

GHJV

Pipes and Filters Polymorphism

Arquitectnico Comportamiento

BMRSS Larman

PresentationAbstractionControl

Arquitectnico

BMRSS

Prototype Proxy (1)

Creacin Estructura

GHJV GHJV

Proxy (2)

Estructura

BMRSS

PublisherSubscriber PureFabrication

Comportamiento Estructura

BMRSS Larman

Reflection

Arquitectnico

BMRSS

Singleton

Creacin

GHJV

Editorial UOC

190

Ingeniera del software

Nombre State

Tipo Comportamiento

Sistema GHJV

Propsito Hace que, cuando un objeto cambia de estado, cambie su comportamiento como si hubiera cambiado de clase. Encapsula varios algoritmos hacindolos intercambiables. Define el esqueleto de un algoritmo de una operacin, y algunos de sus pasos se concretarn en subclases. Permite a sus clientes abrir, manipular y cerrar las presentaciones de los datos, y gestiona sus dependencias. Sustituye la interfaz de una clase, de forma que permite reutilizar algunas clases. Hace que una operacin sobre los componentes de una estructura pueda cambiar sin que los componentes cambien de clase.

Strategy Template Method View Handler

Comportamiento Comportamiento

GHJV GHJV

Comportamiento

BMRSS

Visitor Whole-part

Comportamiento Estructura

GHJV BMRSS

GHJV = Gamma, Helms, Johnson y Vlissides BMRSS = Buschmann, Meunier, Rohnert, Sommerlad y Stal

2.3.6. Los patrones para la ayuda en la resolucin de problemas de diseo Los patrones sirven de ayuda a la hora de resolver problemas de diseo en los aspectos siguientes: a) Sugieren clases y objetos. b) Sugieren interfaces entre objetos, independientes de la implementacin de los mismos, por ejemplo, mediante clases y operaciones abstractas. c) Ofrecen posibilidades de reutilizacin de cdigo mediante superclases y objetos que se puedan utilizar como componentes de otros. d) Sugieren posibilidades de delegar operaciones de una clase a otra. e) Los sistemas de software son ms fciles de modificar por el hecho de que muchas veces los patrones se pueden implementar de varias maneras, manteniendo estables las interfaces. Ms adelante, veris el uso de varios patrones combinados para resolver un nico problema.

Editorial UOC

191

Captulo VI. Diseo orientado a objetos

2.3.7. Seleccin del patrn adecuado

Para seleccionar el patrn adecuado en cada caso, hay que suponer que se dispone de un nico sistema de patrones (si inicialmente se tenan varios, conviene consolidarlos) con un catlogo adecuado. El proceso de seleccin del patrn adecuado consiste en seguir los siguientes pasos: 1) En primer lugar, hay que especificar por escrito el problema que intentamos resolver con patrones, y si se ve que consta de partes bien diferenciadas, descomponerlo en subproblemas. De cada subproblema se tienen que describir las fuerzas que le afectan. 2) En segundo lugar, deberemos establecer una primera delimitacin del conjunto de patrones aplicables mediante el catlogo. 3) A continuacin, afinaremos ms la seleccin teniendo en cuenta los objetivos de los patrones seleccionados antes. Interesarn tanto los patrones que contemplan todo el (sub)problema como tambin los que pueden resolver alguna parte. 4) Despus, aadiremos a la seleccin todos los patrones relacionados directamente con los anteriores. 5) Entonces consideraremos los patrones que tienen como objetivo facilitar las modificaciones del software futuras, e incluiremos en la seleccin los que sean aplicables. 6) Ms tarde, consideraremos las ventajas e inconvenientes descritos en la documentacin, y evaluaremos qu importancia tienen en el caso considerado. 7) Finalmente, cuando un patrn seleccionado tenga variantes, seleccionaremos la ms adecuada.

2.3.8. Utilizacin de un patrn

A continuacin, se describe la manera de utilizar un patrn: 1) Se hace una lectura general de los puntos de la documentacin del patrn que no se hubiesen ledo todava.

Editorial UOC

192

Ingeniera del software

2) Se estudian con detalle los apartados sobre participantes, estructura y papel de los participantes. 3) Se estudia el ejemplo resuelto. 4) Se sustituye la terminologa abstracta del patrn por la del proyecto y se establece una lista de equivalencias. 5) Se definen las clases nuevas necesarias, y se modifican las ya existentes que haga falta entre las que ya se haban definido durante el proyecto.

2.4. Marcos de aplicaciones Un marco (en ingls, framework), es un conjunto de clases que constituye una aplicacin incompleta y genrica. Si el marco se complementa de manera adecuada (si se especializa), se obtienen aplicaciones especializadas de un cierto tipo. Hay dos tipos de marcos: 1) Un marco de caja blanca consta de un conjunto de clases (denominadas abstracciones) de las cuales est definida tanto la interfaz como la implementacin. Para especializarlo, hay que implementar subclases de estas clases. 2) Un marco de caja negra, en lugar de abstracciones, tiene definidas unas interfaces denominadas papeles (en ingls, roles). Para especializarlo, hay que aadirle clases que implementen sus papeles.

2.4.1. Ventajas e inconvenientes de los marcos Algunas ventajas de los marcos son las que mencionamos a continuacin: a) Reducen el trabajo de programacin y mantenimiento de aplicaciones. Los marcos reducen la codificacin y la puesta a punto, ya que proporcionan subsistemas que sabemos que funcionan. En definitiva, suministran cdigo que ya no se deber volver a escribir ni a mantener. b) Proporcionan una arquitectura para el software. c) Llevan a desarrollar pequeas aplicaciones que encajan dentro de los marcos, en lugar de aplicaciones monolticas.

Editorial UOC

193

Captulo VI. Diseo orientado a objetos

d) Son una buena base para la industria de componentes de software. Los marcos bien diseados permiten que terceras compaas puedan suministrar componentes o partes de componentes que los desarrolladores podrn aadir. Como inconvenientes de los marcos, podemos enumerar los siguientes: a) Limitan la flexibilidad. Los componentes que se construyan para un marco tienen que amoldarse a las restricciones impuestas por la arquitectura de ste. b) Dificultan el aprendizaje. Antes de utilizar un marco para construir aplicaciones, hay que estudiarlo a fondo. Para este aprendizaje, se puede calcular un tiempo inicial de tres semanas (para un marco de complejidad media) ms un tiempo adicional con un plazo medio determinado por la arquitectura de la aplicacin que hay que construir. De todos modos, este aprendizaje slo se tiene que hacer una vez y puede servir para muchas aplicaciones basadas en el marco. c) Reducen el grado de creatividad del trabajo de los desarrolladores.

2.4.2. Comparacin entre marcos y patrones Finalmente, estableceremos una comparacin entre los marcos y los patrones. Esta comparacin se centra en los siguientes aspectos: 1) Los patrones son menores. Un marco puede contener varios patrones, nunca lo contrario. 2) Los patrones son ms abstractos. Cada vez que se aplica un mismo patrn, produce programas diferentes. 3) Los patrones son menos especializados, ya que se pueden utilizar en cualquier tipo de aplicacin.

3. El diseo arquitectnico

El diseo arquitectnico tiene como objetivo definir las grandes lneas del modelo del diseo.

Editorial UOC

194

Ingeniera del software

El diseo arquitectnico comprende las actividades siguientes: establecer la configuracin de la red, decidir la utilizacin de un marco ya disponible, si procede, y establecer los subsistemas, sus interfaces y las dependencias entre stos.

3.1. Establecimiento de la configuracin de la red

El establecimiento de la configuracin de la red consiste en determinar los nodos que habr y las caractersticas que tendrn, las conexiones entre stos y cmo sern, y los protocolos de comunicaciones en cuanto al ancho de banda, fiabilidad y calidad.

3.2. Establecimiento de los subsistemas

Los subsistemas pueden ser propios del proyecto, reutilizados por otros proyectos o software del mercado, como software de sistemas y software intermediario o middleware. Se puede partir de la descomposicin del software en paquetes hechos en la etapa de anlisis. Las modificaciones que se harn en el mismo normalmente consistirn en segregar algn subsistema de un paquete de servicio con vistas a reutilizarlo en varios lugares del software, o a separar en subsistemas diferentes lo que ya est hecho de lo que se tiene que llevar a cabo en el proyecto, o a permitir que se reparta un paquete entre varios nodos. Tambin conviene tener en cuenta la posibilidad de aplicar patrones arquitectnicos. Por interfaz de un subsistema entendemos las operaciones que se pueden pedir al subsistema desde otros subsistemas. Ahora bien, aparte de estas interfaces, no necesariamente definidas de manera explcita, para conseguir un diseo ms flexible de cara a modificaciones futuras, puede ser conveniente definir interfaces explcitas implementadas por subsistemas que se pueden ir sustituyendo a lo largo del tiempo, igual que en el caso de interfaces de clases considerado de manera estndar en el UML.

Editorial UOC

195

Captulo VI. Diseo orientado a objetos

Es especialmente importante definir interfaces para los subsistemas que corresponden a software del sistema o a middleware, aunque hay que esperar a que vayan evolucionando a lo largo del tiempo de una manera independiente del software que desarrollamos. Las dependencias entre subsistemas se presentan cuando hay elementos de un subsistema que tienen relaciones con elementos de otro. Como mnimo, habr todas las dependencias que ya existen entre los paquetes de anlisis y de servicios correspondientes.

4. El diseo de los casos de uso

Dado que los requisitos se recogieron esencialmente en forma de casos de uso, una manera lgica de enfocar el diseo es describir la implementacin de cada uno, partiendo de la versin revisada y documentada con diagramas de interaccin obtenida en la etapa de anlisis. El diseo de la implementacin de los casos de uso (que a partir de ahora denominaremos simplemente diseo de los casos de uso) parte del diagrama de colaboracin resumido que se ha hecho en el anlisis, y se consideran por separado las clases de frontera, de entidades y de control. Las clases de frontera son el punto de partida del diseo de la interfaz de usuario. El diseo de las clases de entidades incluye el diseo de los instrumentos para gestionar la persistencia. No hablaremos aqu del diseo de la interfaz con el usuario y de la persistencia, sino en otros apartados. La implementacin de la funcionalidad de los casos de uso se hace dentro de las clases de control y las clases de entidades. Dado que esta funcionalidad puede ser extremadamente variada, slo se pueden dar algunas reglas generales sobre su distribucin entre clases y las operaciones de stas: a) Conviene que una de las clases de control dirija todo el proceso del caso de uso. b) Hay que aprovechar las oportunidades de reutilizar componentes y aplicar patrones. En lo que respecta a las otras formas de reutilizacin, el uso de

Editorial UOC

196

Ingeniera del software

marcos ya se habr considerado durante el diseo arquitectnico y la posibilidad de reutilizacin de clases se estudia de forma sistemtica ms adelante. Sin embargo, si se encuentran posibilidades obvias de reutilizar alguna clase, hay que hacerlo. El proceso del diseo de las clases de control es ste: se estudia la implementacin de las operaciones ya identificadas en el anlisis, una por una. A menudo ocurre que, para implementar una, son necesarias nuevas operaciones de clases ya definidas o tambin de clases nuevas. Despus, habr que estudiar la implementacin de estas operaciones nuevas, etc. Como vemos, mientras se disean los casos de uso se van incorporando clases y operaciones nuevas al diagrama esttico de anlisis, que as llega a ser el diagrama esttico de diseo. Una vez terminado el diseo de los casos de uso, ser necesario revisarlo de la manera que describiremos ms adelante, lo cual puede llevar a realizar retoques tambin en el diseo de los casos de uso.

5. Revisin del diagrama esttico de diseo

Como ya hemos visto, la obtencin del diagrama esttico de diseo no es un paso independiente, sino que se va haciendo esencialmente durante el diseo de los casos de uso. Una vez acabado ste, queda hacer una revisin del diagrama obtenido. El diagrama revisado, juntamente con la especificacin de las operaciones de sus clases, ser la base para la implementacin de las clases de control y de entidades.

Diferencias entre el diagrama esttico de diseo y el de anlisis

Generalmente, el diagrama esttico de diseo contiene muchas ms clases que el de anlisis (ya hemos mencionado antes un factor tpico de 5 a 1). No obstante, eso no

Editorial UOC

197

Captulo VI. Diseo orientado a objetos

quiere decir que el diagrama esttico de diseo tenga todas las clases que tendr el software una vez implementado. Dejando de lado las clases de la interfaz grfica, si la herramienta utilizada est orientada a objetos, durante la programacin se definirn muchas ms clases que tendrn un papel puramente instrumental y que generalmente no se reflejan en un diagrama, ya que ste sera muy complejo (sin embargo, no se descarta hacer diagramas estticos parciales si se cree conveniente).

La revisin del diagrama esttico de diseo tiene en cuenta los aspectos siguientes: la normalizacin de los nombres, la reutilizacin de clases, la adaptacin de la herencia en el mbito soportado por el lenguaje de programacin, la mejora del rendimiento, el incremento de la velocidad y la reduccin del trnsito de mensajes mediante la agrupacin de clases, la adicin de clases temporales para almacenar resultados intermedios, y la revisin desde el punto de vista de cohesin y acoplamiento. Todas estas razones pueden justificar la modificacin del modelo creado anteriormente, y lo haremos en un nuevo diagrama para respetar lo que hemos pactado con nuestro cliente.

5.1. Normalizacin de los nombres

En la recogida y documentacin de requisitos es muy posible (e incluso recomendable) que hayamos utilizado la terminologa del cliente para facilitar la comunicacin con l. Por continuidad, seguramente ser bueno utilizar la misma terminologa en el diagrama esttico del anlisis y en la especificacin formal de los casos de uso hecha dentro del anlisis y, por tanto, en el diseo de los casos de uso. No obstante, incluso si se ha ido con cuidado de no utilizar nombres no soportados por los lenguajes de programacin, puede ocurrir que haya que cambiar algunos nombres de clases, atributos y operaciones, bien porque vulneren alguna norma aplicable al proyecto o bien para respetar una terminologa ya establecida en proyectos anteriores. Esto es importante de cara a la reutilizacin de clases, ya que la librera de clases puede contener muchas y pueden ser difciles de encontrar, si no se usa una nomenclatura unificada.

Editorial UOC

198

Ingeniera del software

5.2. Reutilizacin de clases

Durante el diseo de los casos de uso, las clases se hacen a medida de acuerdo con las operaciones que deben contener, y slo se reutilizan clases cuando la posibilidad de hacerlo es obvia. Ahora se trata de revisar sistemticamente las posibilidades de reutilizar clases ya existentes de acuerdo con lo que sabemos.

5.3. Adaptacin de la herencia en el nivel soportado por el lenguaje de programacin

La herencia mltiple se da bastante a menudo en diagramas estticos de anlisis, pero hay lenguajes de programacin que no la soportan, y por esta razn, cuando se pretende realizar la implementacin con uno de estos lenguajes, en el diagrama esttico de diseo hay que sustituir los casos de herencia mltiple por otra estructura equivalente.
Justificacin del uso de la herencia mltiple Se podra pensar que, si sabemos que la aplicacin se tiene que desarrollar en un lenguaje que no soporta la herencia mltiple, lo mejor es evitarla desde el principio, de la misma manera que se recomienda que los nombres respeten las restricciones ms habituales en los lenguajes de programacin. No obstante, utilizar la herencia mltiple cuando proceda puede hacer que el diagrama esttico de anlisis sea mucho ms comprensible.

Para deshacer la herencia mltiple, habr que utilizar alguna de las tcnicas que describimos a continuacin. En todos los casos nos referiremos al mismo ejemplo:

Editorial UOC

199

Captulo VI. Diseo orientado a objetos

5.3.1. Supresin de la herencia mltiple por duplicacin

Una manera de suprimir la herencia mltiple consiste en duplicar en la subclase los atributos que heredara de una de las superclases:

5.3.2. Supresin de la herencia mltiple por delegacin

La herencia mltiple se puede suprimir por delegacin si se mantiene una sola de las superclases y se incluye dentro de la subclase una referencia a un

Editorial UOC

200

Ingeniera del software

objeto de la otra superclase, que tiene el valor de los atributos correspondientes:

5.3.3. Supresin de la herencia mltiple con interfaces

Tambin se puede suprimir la herencia mltiple si se sustituye la herencia doble por herencia simple ms una interfaz implementada por otra superclase:

5.3.4. Supresin de la herencia mltiple por agregacin

Las relaciones de herencia se pueden sustituir por agregaciones. Esto se puede hacer de dos maneras:

Editorial UOC

201

Captulo VI. Diseo orientado a objetos

5.4. Sustitucin de las interfaces

Si el lenguaje de programacin no soporta las interfaces, se pueden sustituir por clases abstractas, de las cuales, como sabemos, las interfaces son un caso particular.

5.5. Cambios para la mejora del rendimiento

En el anlisis normalmente no nos preocupamos por la cuestiones de eficiencia, pero en el diseo es imprescindible. Se pueden realizar cambios en el diagrama esttico de diseo simplemente por esta razn.

5.5.1. Agrupacin de clases para reducir el trnsito de mensajes

Hemos visto que, por flexibilidad, es mejor sustituir los atributos con valores mltiples por una clase aparte que comparta con la primera una asociacin de n

Editorial UOC

202

Ingeniera del software

a 1. Pues bien, por razones de eficiencia quiz es conveniente realizar el cambio a la inversa, ya que as no hay que enviar un mensaje de una clase a otra.

5.6. Especificacin de las operaciones implcitas

En todos los proyectos o en casi todos, hay operaciones que permanecen implcitas dentro de las especificaciones del anlisis. Dado que se debern implementar igual que las otras, tambin conviene tenerlas en cuenta en la fase de diseo. Indicamos a continuacin algunas reglas que nos pueden servir de ayuda a la hora de encontrar operaciones implcitas: 1) Para toda clase debe haber una operacin que la instancie, otra que destruya los objetos y operaciones que lean y que pongan los valores de todos los atributos (naturalmente, quiz estas acciones queden comprendidas dentro de operaciones que realizan ms acciones). La operacin que crea un objeto agregado tiene que inicializar a nulo la lista de sus componentes. 2) Para cada asociacin debe haber una operacin que cree un enlace entre objetos y otra que lo recorra. 3) Para cada estado que puedan tener los objetos de una clase tiene que haber una operacin que los haga llegar a este estado. 4) Para cada atributo derivado tiene que haber una operacin que calcule su valor.

5.7. Referencias a las clases de frontera

Sabemos que las clases de control piden operaciones a las clases de frontera. Estas clases son provisionales y se sustituyen por elementos grficos (generalmente tambin en forma de clases) durante el diseo de la interfaz de usuario. A menos que ste se hubiera llevado a cabo antes del diseo de los casos de uso, dentro de la especificacin de las operaciones de las clases de control habr que sustituir las llamadas operaciones de las clases de frontera por operaciones en elementos de la interfaz de usuario.

Editorial UOC

203

Captulo VI. Diseo orientado a objetos

5.8. La clase inicial

Generalmente, se crea un objeto cuando lo pide una operacin que se ejecuta en relacin con otro objeto ya existente, pero es obvio que tiene que haber un primer objeto que no es creado por ningn otro. Este mecanismo, que vara segn el lenguaje de programacin, se tiene que prever en el diseo.

5.9. Cohesin y acoplamiento

Llega un momento en el cual estamos razonablemente seguros de que el diagrama esttico tiene todas las clases que deber tener para la implementacin y que todas estas clases tienen definidas todas las operaciones. Entonces conviene revisar este diagrama desde el punto de vista de la cohesin y el acoplamiento para dar la mxima flexibilidad al diseo, de cara a cambios futuros.

5.9.1. Cohesin

Una clase muy coherente lo es si sus atributos y operaciones tienen mucha relacin entre s, hasta el punto de que se puede considerar que forman una unidad. En cambio, una clase poco coherente agrupa atributos u operaciones que no tienen nada o casi nada que ver los unos con los otros, a menudo como consecuencia del hecho de que la clase implementa lo que en realidad son dos entidades ms o menos autnomas. Una operacin poco coherente es la que no tiene un proceso con un objetivo nico y claro. Las clases y las operaciones poco coherentes son ms difciles de entender, y adems tienen los siguientes inconvenientes:
Uso de clases y operaciones poco coherentes A veces, no hay ms remedio que agrupar varios procesos independientes, que no son propios de ninguna clase, en una sola. Por eso, existen las clases de utilidad del UML y el patrn Pure Fabrication.

Editorial UOC

204

Ingeniera del software

Presuponen que las varias entidades que representan estn en relacin de 1 a 1, lo cual no siempre es cierto. Puede suceder que se tengan que especializar segn diferentes criterios. Se ven afectadas por ms modificaciones. En general, interesa evitar las clases y operaciones poco coherentes. La cohesin de las clases se puede conseguir si se trasladan a stas las reglas utilizadas en la normalizacin de bases de datos relacionales. Por otro lado, es conveniente descomponer en distintas operaciones, de la misma clase o de varias, las operaciones poco coherentes, de manera que cada una tenga un propsito concreto.

5.9.2. Acoplamiento

El acoplamiento de las clases y de los objetos expresa el grado en que stos dependen de otras clases y objetos para llevar a cabo su responsabilidad. Cuanto ms acoplamiento tenga una clase, ms se ver afectada por cambios en otras y, por tanto, se deber modificar ms a menudo. Existen varias formas de acoplamiento: 1) Acoplamiento por referencia. Acoplamiento en el cual un objeto contiene una referencia a otro. Se puede reducir si se suprimen asociaciones o si las referencias se hacen unidireccionales. 2) Acoplamiento por representacin. En este tipo de acoplamiento, un objeto utiliza otro. El acoplamiento por representacin puede tener varios grados: el acceso directo a atributos pblicos (el grado ms bajo), la peticin mediante operaciones de los valores de los atributos (privados) para evaluar un resultado, o la llamada a una operacin que d este resultado ya calculado (el grado ms alto). 3) Acoplamiento por subclases. Acoplamiento en el que una clase A tiene una asociacin con cada una de las subclases o les pide operaciones. Para extenderlo a una subclase nueva, habra que modificar la clase A. En cambio, el acoplamiento es menor si la asociacin o las llamadas desde operaciones se dirigen a la superclase, ya que no hay que modificar A por el hecho de que se aadan subclases. En este caso, habra problemas si la asociacin o la operacin no se tuvieran que extender a la subclase nueva.

Editorial UOC

205

Captulo VI. Diseo orientado a objetos

El acoplamiento es todava ms bajo si las llamadas a operaciones se dirigen a una interfaz, ya que entonces se podra incluso sustituir la superclase sin tener que modificar la clase A, siempre que la nueva clase implementara la misma interfaz. 4) Acoplamiento por herencia. La subclase no puede prescindir de los atributos y operaciones que hereda de la superclase. En cambio, esto s que es posible si se sustituye la herencia por la agregacin.

6. Diseo de la persistencia

Cuando un proceso acaba, libera la memoria que utilizaba y todo lo que haba, en principio, se pierde. Si un objeto debe tener una vida ms larga que el proceso que lo crea o, dicho de otra manera, el objeto se crea en un proceso y se utiliza en procesos posteriores, hay que grabarlo en un sistema de almacenamiento permanente. Entonces se dice que dicho objeto se ha hecho persistente y se habla de un objeto persistente. Denominamos clases persistentes a las clases que pueden tener objetos persistentes, y clases temporales a las no persistentes. En relacin con un objeto persistente, tiene que ser posible llevar a cabo al menos dos operaciones: grabarlo y leerlo (la operacin leer tambin se conoce como materializar). En la prctica tambin ser necesario poderlo borrar e identificar entre los otros objetos persistentes de la misma clase. De un objeto, se graban los valores de los atributos (es decir, lo que se denomina estado del objeto). Ahora bien, es posible que no todos los atributos de un objeto persistente sean persistentes. El estado persistente del objeto en cuestin lo constituyen los valores de los atributos que se hacen persistentes. Los objetos persistentes de una clase se pueden leer de dos maneras: o bien todos a la vez al comienzo del proceso, o bien cada uno cuando es necesario (modalidad de materializacin segn demanda). Podemos distinguir tres tipos de sistemas de almacenamiento segn la manera como se implementa la persistencia: bases de datos orientadas a objetos, bases de datos relacionales y ficheros clsicos, y bases de datos object-relational.

Editorial UOC

206

Ingeniera del software

6.1. Persistencia con bases de datos orientadas a objetos

La implementacin de la persistencia con bases de datos orientadas a objetos es el caso ms sencillo de todos, ya que no hay que transformar los objetos para hacerlos persistentes. No es necesario hacer un diseo de la persistencia: para especificar que los objetos de una clase pueden ser persistentes, slo hay que enriquecer la definicin de la clase, indicando cules de los atributos son persistentes y qu poltica de lectura de objetos se quiere seguir (se leen todos de una vez, o segn demanda).
Clculo automtico de los atributos no persistentes El sistema de gestin de bases de datos calcular de manera automtica los atributos al materializar los objetos.

A partir de las definiciones de las clases enriquecidas de esta manera, se genera cdigo que se pasa a un preprocesador que le aadir los mtodos necesarios para gestionar la persistencia de los objetos.

6.2. El modelo para bases de datos relacionales y ficheros clsicos: alternativas

En el modelo para bases de datos relacionales y ficheros clsicos, a un objeto le corresponde, en principio, una fila de una tabla de una base de datos relacional o un registro de un fichero, respectivamente y a los atributos de los objetos les corresponden columnas de la tabla correspondiente. Hay que realizar la transformacin mencionada antes de grabar un objeto, y es preciso llevar a cabo la transformacin inversa antes de que sea posible utilizarlo una vez ledo. Con este sistema de almacenamiento existen tres maneras de llevar a cabo la gestin de la persistencia: 1) Hacer que cada clase persistente tenga operaciones para que los objetos se graben, borren, etc., por s mismos. Esta opcin tiene la ventaja de que es ms

Editorial UOC

207

Captulo VI. Diseo orientado a objetos

eficiente que las otras, dado que requiere menos llamadas entre objetos, pero tiene el inconveniente de que la implementacin de las clases persistentes depender de un sistema de gestin de bases de datos concretos por el hecho de que son clases de entidades que corresponden a entidades del dominio del software, lo cual limita la portabilidad de la aplicacin. 2) El segundo mtodo define una clase denominada gestor de disco para cada clase persistente. El gestor de disco accede directamente al fichero o base de datos. Con este mtodo, la clase de entidades se desacopla del sistema de gestin de base de datos, y tiene la ventaja adicional de que el gestor de disco puede hacer de memoria cach de los objetos de la clase de entidades (si los objetos ledos se materializan dentro de instancias del gestor antes de crear instancias de la clase de entidades). Ahora bien, esta solucin es menos eficiente que la anterior. 3) El tercer mtodo es una mezcla de los anteriores y consiste en crear los gestores de disco y adems aadir operaciones de grabacin, lectura, etc., a las clases del dominio. La diferencia con el primer mtodo es que las operaciones de la clase no implementan la persistencia directamente, sino que llaman operaciones del gestor de disco. Con el fin de aislar las clases de entidades del sistema de gestin de bases de datos, es muy til implementar la persistencia por medio de un marco.

6.2.1. Obtencin de la definicin de la estructura de base de datos relacional o de ficheros clsicos

La base de partida para obtener la definicin de la estructura de bases de datos relacional o de ficheros clsicos es la parte del diagrama esttico de diseo que contiene las clases de entidades que son clases persistentes, y las relaciones entre stas. Los pasos para llegar a obtener la definicin de esta estructura sern los siguientes: 1) Transformar el modelo esttico en un modelo entidad-relacin (modelo ER).

Editorial UOC

208

Ingeniera del software

2) Suprimir la herencia, dado que el modelo relacional no la soporta. Si el modelo ER utilizado tampoco la soporta, este paso se habr debido hacer antes del anterior. 3) Transformar el modelo ER en un modelo relacional segn las reglas habituales del diseo de bases de datos relacionales. En el caso de ficheros clsicos, en lugar de tablas relacionales tendremos ficheros planos. 4) Crear un gestor de disco para cada clase persistente que implemente los accesos a las tablas o ficheros planos correspondientes.

6.2.2. Transformacin del modelo esttico en el modelo ER

Si nos fijamos, un modelo OO es muy parecido a un modelo ER, sobre todo en el caso de las variantes del modelo ER que soportan la herencia de tipo de entidades. En este caso, la transformacin del modelo esttico en el modelo ER consiste en convertir cada clase con un atributo con valores mltiples en dos clases unidas por una asociacin, y despus hacer corresponder un tipo de entidad a cada clase no asociativa. Ms tarde, se aade una relacin para cada asociacin o clase asociativa o agregacin, con cardinalidades que son obvias. Cuando la supresin de la herencia se lleva a cabo al pasar del modelo esttico al modelo ER, el trmino tablas hace referencia a entidades y relaciones. Al pasar del modelo ER al relacional, el concepto clases se refiere a entidades y relaciones.

6.2.3. Supresin de la herencia

Supondremos el caso presentado en la siguiente figura:

Editorial UOC

209

Captulo VI. Diseo orientado a objetos

Hay tres formas de resolver la situacin planteada: 1) Definir una tabla para cada clase, que contendra tanto los atributos propios de la clase como los heredados. 2) Crear una tabla para la superclase y una complementaria para cada subclase de sta que tenga atributos propios. Cada tabla complementaria contendra los atributos propios de la subclase respectiva ms los atributos que identifican cada fila (es decir, cada objeto) dentro de la tabla de la superclase para juntar todos los atributos (heredados y no heredados) de cada objeto de la subclase.
Nota terminolgica Cuando la supresin de la herencia se lleva a cabo al pasar del modelo esttico al modelo ER, el trmino tablas hace referencia a entidades y relaciones. Al pasar del modelo ER al relacional, el concepto clases se refiere a entidades y relaciones.

3) Crear una sola tabla para toda la jerarqua de clases, que tendra los atributos propios de cada subclase ms los de la superclase. En cada fila, todos los atributos que no fuesen aplicables a la subclase a la que pertenece el objeto deberan tener el valor nulo.
Supresin de la herencia por definicin de una tabla para cada subclase

Al definir una tabla para cada clase, las filas de Cliente_Especial tendrn tanto los atributos especficos de Cliente_Especial como los heredados. Tabla Cliente: NIF: String, clave principal Nombre: String ... Tabla Cliente_Especial: NIF: String, clave principal Nombre: String Descuento: Integer ...

Editorial UOC

210

Ingeniera del software

Evidentemente, esta solucin es muy sencilla, pero tiene los siguientes inconvenientes:

Hay tantas tablas como subclases. Hay que crear un gestor de disco para cada subclase. Un cambio en la definicin de Cliente obligara a cambiar los gestores de disco de todas las subclases. Complicar los procesos que tengan que tratar todos los clientes, ya que ser necesario realizar una fusin de todas las tablas.

Supresin de la herencia por creacin de una tabla para la superclase y una complementaria para subclase

Para suprimir la herencia, tambin se puede crear una tabla para la superclase en la que se graba a todos los clientes. Al mismo tiempo, crearemos una tabla complementaria para cada subclase con el identificador del objeto y los atributos especficos de la subclase. Un gestor de disco nico se encargar de leer y har un join por identificador entre las diferentes tablas con la finalidad de obtener toda la informacin de cada clase. Segn la informacin que lea, el gestor crear una instancia de una subclase u otra y la llenar con sus datos.

Tabla Cliente: NIF: String, clave principal Nombre: String ... Tabla Auxiliar Cliente_Especial: NIF: String, clave principal Descuento: Integer ...

Esta solucin puede ser la mejor opcin si slo una fraccin pequea de los objetos de la clase pertenecen a la subclase y, adems, los valores de los atributos

Editorial UOC

211

Captulo VI. Diseo orientado a objetos

de sta son de longitud fija, ya que entonces los valores nulos ocuparan mucho espacio, si hubiera para todos los objetos de la superclase.

Supresin de la herencia por creacin de una tabla nica para toda la jerarqua de herencia

Esta tercera solucin es ms eficiente en tiempo, pero menos en ocupacin de disco. La supresin de la herencia por creacin de una tabla nica para toda la jerarqua de herencia consiste en crear una sola tabla con todos los campos, tanto de la superclase como de todas sus subclases, y aadirle un campo que nos diga qu subclase del objeto corresponde a cada fila.

Tabla Cliente: NIF: String, clave principal Tipo: Integer Nombre: String ... Descuento: Integer ....

donde Tipo se define de la siguiente manera:

Tipo =

0 si es Cliente 1 si es Cliente_Especial, etc.

Esta solucin puede ser buena cuando el espacio ocupado por los valores nulos de los atributos no aplicables a todas las subclases sea reducido. Es decir, si hay pocas subclases, stas tienen pocos atributos propios o bien casi todos los atributos son aplicables a la mayora de los objetos.

Editorial UOC

212

Ingeniera del software

6.2.4. Los gestores de disco

Consideremos ahora el mtodo alternativo del gestor de disco para la supresin de la herencia. El gestor de disco es una clase diferente de la clase persistente, y dentro de las operaciones de sta hay llamadas a operaciones del gestor de disco. Consideraremos por separado el gestor de disco bsico y los gestores de disco para la materializacin segn demanda.
Diseo bsico de gestores de disco

Podemos considerar que todos los gestores de disco tienen al menos unas operaciones bsicas (leer, grabar, regrabar y borrar). Por tanto, podemos entender que todos son subclases de una superclase que denominaremos GestorGenerico, en la cual estas operaciones seran abstractas. Incluso podramos considerar que hay unas subclases intermedias GestorRelacional y GestorFicheros, que seran superclase de todos los gestores relacionales y de todos los gestores de ficheros clsicos, respectivamente. En el diseo bsico de gestores de disco puede aplicarse el patrn Template Method, en el cual hay una superclase abstracta que tiene una operacin concreta que llama operaciones abstractas de s misma, las cuales llegan a ser concretas en las subclases. El diagrama de clases correspondiente a este diseo es como el que veis a continuacin (el parmetro id es de tipo string por todas partes): La clase abstracta GestorGenerico tiene la operacin leerId (entre otras operaciones pblicas para borrar, etc.) que lee un objeto a partir de un identificador del orientado a objetos mismo. En primer lugar, esta operacin comprueba si el objeto ya est materializado y entonces lo coge de memoria (operacin enCache). De otro modo, lo tiene que leer de la base de datos o fichero con la operacin abstracta materializar. Esta operacin llega a ser concreta en las subclases (tambin abstractas) GestorRelacional y GestorFicheros, y llama la operacin leerFila o leerRegistro, respectivamente, y despus, filaAObjeto o registroAObjeto, tambin de forma respectiva, que hacen los movimientos de datos entre la fila o registro ledo y el objeto creado (de una clase concreta). Por tanto, estas operaciones dependen de cul sea la clase persistente y, en consecuencia, son abstractas.

Editorial UOC

213

Captulo VI. Diseo orientado a objetos

Las operaciones leerFila y leerRegistro tambin dependen de la tabla o fichero que se debe leer, que podra ser un parmetro adicional de la operacin (por ejemplo, si se utiliza una tcnica de acceso como SQL dinmico) o debera ser sustituida en el nivel de subclase por medio de polimorfismo. Esto ltimo se debera hacer necesariamente si la materializacin requiriese acceder a ms de una tabla o fichero. El proceso para aadir o modificar una fila es simtrico del de materializar: en GestorGenerico y en GestorRelacional hay una operacin grabar abstracta y GestorFicheros llama dos operaciones: objetoAFila y grabarFila, y objetoARegistro y grabarRegistro, respectivamente. Si la fila o registro existe, se sustituyen sus valores, y si no, se aade a la tabla. Tambin habra que prever una operacin para borrar filas o registros uno por uno.

Editorial UOC

214

Ingeniera del software

Para implementar la materializacin segn demanda, se puede utilizar una combinacin del patrn Template Method con la modalidad denominada Virtual del patrn Proxy ms los patrones Factory Method y Singleton.
Diseo de gestores de disco para la materializacin segn demanda

Este diseo es evidentemente ms complejo y slo est justificado o bien cuando debe ser posible sustituir la clase de entidad sin tener que modificar todas las que la utilizan, o bien cuando la materializacin es costosa y hay que esperar a hacerla cuando sea absolutamente necesario. Sin embargo, mientras no se haga, es necesario que las referencias exteriores al objeto apunten a un objeto existente. Las referencias exteriores no se hacen a objetos de la clase de entidades en cuestin, sino a objetos de una clase sustituta. La clase original y la sustituta implementan la misma interfaz (o clase abstracta, si el lenguaje de programacin no soporta explcitamente las interfaces), y la clase sustituta llama las operaciones del original. La clase sustituta puede ser subclase de una clase abstracta. Antes de pedir operaciones al gestor de disco, hay que crear una instancia. Obviamente, la instancia que se tiene que crear debe ser del gestor de disco correspondiente a la clase de entidades en cuestin y a su sustituta. El patrn Factory Method define una clase creadora abstracta (que puede ser la clase sustituta abstracta) y crea una instancia de la clase adecuada con una operacin abstracta de creacin. Esta operacin es sustituida por operaciones concretas en el nivel de subclases que crean instancias del gestor correspondiente.
Lectura recomendada Encontraris ampliaciones sobre el diseo de gestores de disco para la materializacin segn demanda que consideran otros aspectos de la persistencia (por ejemplo, transacciones) con ms patrones en la siguiente obra: C. Larman (1998). Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design . Prentice Hall.

La aplicacin del patrn Singleton garantiza que slo se cree una instancia de cada clase gestor, y lo consigue haciendo que la instancia creada sea el valor de un

Editorial UOC

215

Captulo VI. Diseo orientado a objetos

atributo de clase y la operacin de creacin sea una operacin de clase, mientras que el estado del objeto se compone de atributos de instancia y es accesible por medio de operaciones de instancia.

6.3. Persistencia con bases de datos object-relational

En principio, el mtodo diseo de la persistencia con bases de datos objectrelational es el mismo que el de las bases de datos relacionales, con la diferencia de que este nuevo modelo puede tener atributos de tipo compuesto y, por tanto, no ser necesario crear gestores de disco para todas las clases persistentes, sino slo para aqullas a las cuales se acceder directamente.
Ejemplo de diseo de persistencia con bases de datos object-relational En el ejemplo de una clase Persona con hijos, si la base de datos que utilizamos permite tener como campo un array de hijos, modelaremos esta relacin como un atributo de persona y evitaremos tener que definir un gestor de disco de hijos. Decimos si permite porque de momento no existe ningn estndar y cada fabricante de sistemas de gestin de bases de datos ofrece un modelo propio. Por tanto, se tendr que ir con cuidado al escoger una base de datos de este tipo para que satisfaga las necesidades de nuestra empresa.

Editorial UOC

216

Ingeniera del software

7. Diseo de la interfaz grfica de usuario

En las etapas de recogida y documentacin de requisitos haba un cierto paralelismo entre las actividades relativas a la funcionalidad y las relativas a la interfaz de usuario: en la recogida y documentacin de requisitos haba casos de uso, por un lado, y tareas, por el otro. En la etapa de anlisis, haba colaboracin entre clases de frontera, de control y de entidades, por una parte, y esquema del aspecto visual de las clases de frontera, por la otra. La razn de esta dualidad es clara: cuando se trata de la funcionalidad, se considera el funcionamiento del software desde el punto de vista interno, mientras que cuando se trata de la interfaz, lo que cuenta son los efectos del funcionamiento del software visibles por el usuario. En la etapa de diseo esta dualidad se mantiene por dos motivos: Por un lado, por la razn ya mencionada. Hay un diseo de la interfaz de usuario separado del diseo de los casos de uso. Por otro lado, como veremos a continuacin, porque en el diseo de la interfaz de usuario se utiliza una metodologa diferente en muchos aspectos. Tambin es posible que al comienzo de la implementacin se trabaje por separado en la funcionalidad y en la interfaz de usuario, pero en algn momento se tendrn que juntar las clases de la interfaz grfica con el resto, puesto que debern colaborar. La coherencia entre la funcionalidad y la interfaz de usuario debera estar garantizada por el hecho de que las bases de partida de los desarrollos respectivos (la documentacin de los casos de uso y la de las tareas futuras, ambas obtenidas en la etapa de recogida y documentacin de requisitos) describen lo mismo desde dos puntos de vista. Sin embargo, est claro que conviene comprobar que esta concordancia se mantenga entre la documentacin respectiva correspondiente a las etapas de anlisis y de diseo. El diseo de la interfaz de usuario considera tres aspectos de sta: a) El contenido, que ya est establecido en los esquemas de las ventanas elaborados en el anlisis.

Editorial UOC

217

Captulo VI. Diseo orientado a objetos

b) El formato, que se especifica ntegramente en esta fase. c) La interaccin, es decir, la dinmica de la interfaz de usuario, denominada tambin dilogo entre el usuario y el sistema. La interaccin est establecida dentro de la especificacin de los casos de uso en trminos formales (clases de frontera), pero independientes de la herramienta que se utilizar. Por tanto, en el diseo deber describirse la implementacin con los elementos que ofrece la herramienta de apoyo de la interfaz grfica. Antes de entrar en el diseo de la interfaz grfica de usuario propiamente dicho, veremos brevemente los aspectos estticos y dinmicos de la interfaz grfica de usuario, que son los elementos con los cuales se elabora el diseo. La interfaz grfica de usuario es slo una parte de la interfaz de usuario en general: es nicamente la interfaz implementada por medio de pantallas grficas con teclado y ratn. La interfaz grfica de usuario no incluye, por tanto, las salidas impresas, en especial las alfanumricas (los clsicos listados).
Interfaces alfanumricas Las interfaces alfanumricas por pantalla son una reliquia de la poca en que la unidad direccionable dentro de las pantallas no era el pxel, sino el carcter, y se pueden considerar un caso particular, muy simple, de las interfaces grficas.

7.1. Elementos y funcionamiento de la interfaz grfica de usuario

Comenzaremos por describir brevemente los principales tipos de elementos que componen las interfaces grficas y despus hablaremos de la interaccin entre el usuario y el sistema.

7.1.1. Elementos de la interfaz grfica de usuario Los elementos de las interfaces grficas se acostumbran a denominar objetos u objetos grficos.

Editorial UOC

218

Ingeniera del software

Ejemplos de objetos grficos Un objeto de la interfaz puede ser tanto una ventana como un botn, un texto, una palabra o un carcter dentro de un texto.

Los objetos grficos no son necesariamente instancias de clases, aunque s que lo son cuando la interfaz se implementa con una herramienta orientada a objetos. Es normal que un objeto de la interfaz est formado por otros objetos. Los objetos grficos se pueden basar en pxeles o en unos objetos que se denominan primitivas grficas. Sin embargo, para visualizar e imprimir las primitivas grficas generalmente hay que convertirlas en mapas de bits ( rasterizacin). Una interfaz grfica tiene los siguientes tipos de componentes: escritorio, cursores y punteros, ventanas, mens, controles, elementos complejos y cajas de dilogo.
El escritorio

El escritorio es el fondo de pantalla que ve el usuario cuando se pone en marcha el sistema y tambin antes de poner en marcha alguna aplicacin. Sobre l aparecen los objetos de la interfaz grfica.
Los dispositivos de entrada: ratn, teclado, pluma y pantalla tctil

Una interfaz grfica utiliza dos dispositivos de entrada tpicos: el teclado y el ratn. El puntero sigue el movimiento del ratn y cambia de forma segn los usos: flechas de una, dos o cuatro puntas, cruz, reloj, etc. Tanto el puntero como los objetos que puede seleccionar tienen una zona alrededor dentro de la cual los clics tienen efecto. El ratn puede tener de uno a tres botones y se puede utilizar de cuatro maneras bsicas:

Arrastrar el puntero sin apretar ningn botn. Pulsar el botn sobre un icono y dejarlo ir inmediatamente (hacer clic). Pulsar el botn y arrastrar el icono antes de dejarlo ir.

Editorial UOC

219

Captulo VI. Diseo orientado a objetos

Pulsar el botn y dejarlo ir dos veces seguidas o ms sobre un icono (doble clic, etc.). Del teclado nos interesan especialmente las combinaciones de teclas que equivalen a la seleccin de opciones dentro de un men. El cursor seala el punto, dentro de un campo o un texto, donde tiene efecto lo que se haga con el teclado. Se dice que el objeto donde est el cursor tiene el foco. La navegacin del cursor se puede llevar a cabo haciendo clic con el ratn en la posicin deseada, o con las teclas de principio de lnea (Home), final de lnea (End ), retroceso de pgina (Page Up), avance de pgina (Page Down ), las cuatro flechas y el tabulador (Tab). La pluma puede hacer las funciones del ratn, pero adems puede escribir. Entonces, segn la forma y direccin del trazo se ejecutan diferentes mandos: seleccionar, copiar/enganchar, anular, tabular, borrar un carcter, tecla de retorno de carro (Return), espacio, etc.
Funciones equivalentes de la pluma y el ratn Marcar en un punto con la pluma equivale a hacer clic con el ratn, marcar dos veces equivale a hacer doble clic. Por otro lado, con la pluma se puede arrastrar como con el ratn.

Las pantallas tctiles son tiles cuando el volumen de datos que se tiene que introducir es muy pequeo y la entrada consiste esencialmente en selecciones.
Las ventanas

Una ventana viene a ser una pantalla virtual asociada a una aplicacin activa, y es un marco dentro del cual aparecen los objetos propios de la aplicacin. Si en un momento dado hay varias aplicaciones activas en un ordenador con una sola pantalla fsica, y por tanto con un nico escritorio, lo tienen que compartir, y la manera de hacerlo es que cada aplicacin tenga su ventana (de hecho, una aplicacin puede tener varias ventanas, como veremos). La ventana de la aplicacin con la que trabaja el usuario en cada momento recibe la entrada del ratn y el teclado (se dice que tiene el foco) y a menudo

Editorial UOC

220

Ingeniera del software

tapa de forma total o parcial las otras. Por el contrario, las ventanas de las otras aplicaciones activas permanecen en segundo plano, pero a punto para volver a aparecer cuando el usuario vuelva a trabajar con la aplicacin respectiva. Hay dos maneras de gestionar el foco de las aplicaciones: 1) La gestin implcita del foco, en la cual la ventana que tiene el foco es siempre aqulla sobre la cual est el puntero del ratn. 2) La gestin explcita del foco, en la que la asignacin del foco a una ventana se hace explcita e independientemente de la posicin del cursor. En el caso ms general, las ventanas tienen un marco y pueden llevar un ttulo y contener elementos grficos activos (controles) para las siguientes operaciones: Variar su tamao. Maximizarla, que quiere decir hacer que ocupe toda la pantalla. Minimizarla, convirtindola en un icono. Si se hace doble clic sobre la misma recupera las dimensiones que tena antes de la minimizacin. Restaurarla, es decir, restituirle las dimensiones que tena antes de maximizarla. Dividirla en dos, verticalmente u horizontalmente, arrastrando la lnea de divisin. Desplazar el contenido arriba y abajo y a la derecha y a la izquierda (scroll) por medio de las barras que hay a la derecha y debajo respectivamente. Arrastrar toda la ventana, normalmente situando el cursor en la barra de ttulo. Esconderla (es decir, hacerla transparente, de manera que deje ver la ventana de debajo o el escritorio). Cerrarla, acabando o no la aplicacin respectiva. Podemos distinguir diferentes tipos de ventanas:

1) Ventanas de aplicacin. Son las ventanas que aparecen cuando un usuario activa una aplicacin. Tienen un ttulo con el nombre de la aplicacin, con-

Editorial UOC

221

Captulo VI. Diseo orientado a objetos

troles para redimensionarlas, el men de barra de la aplicacin, botones para maximizarlas, minimizarlas y cerrarlas, un rea de mensajes y un rea de estado, y son movibles.

Ventana de aplicacin y mens En la figura podis ver una ventana de aplicacin y una cascada de mens: el men de barra y dos niveles de mens desplegables.

2) Ventanas de documento. Son ventanas asociadas a una aplicacin y generalmente dentro de la ventana de sta (observad la figura siguiente). Se crea una cada vez que se abre un documento o se crea un documento nuevo. Puede haber varias ventanas de documento abiertas al mismo tiempo, pero slo una tiene el foco, incluso si hay varias visibles al mismo tiempo, es decir, el usuario en cada momento slo puede trabajar con un documento. Tiene que haber alguna manera de pasar de un documento a otro: generalmente se selecciona de una lista o se hace clic en una porcin visible.

Editorial UOC

222

Ingeniera del software

Las ventanas de documento tienen un ttulo con el nombre del documento, controles de ventana con las mismas opciones que la ventana de la aplicacin y tambin controles para el desplazamiento (en ingls, scroll) horizontal y vertical y para dividir la ventana.

Ventana de documento y men emergente Esta figura es un ejemplo de ventana de documento (en este caso, un diagrama) en la cual se ve tambin un men emergente.

3) Ventanas de cajas de dilogo o ventanas secundarias. Tienen una barra de ttulo con el nombre del mando que las ha abierto y contienen al menos una caja de dilogo. No tienen rea para documentos, ni barras de men y de estados, ni controles de redimensionamiento, ni rea de mensajes; se pueden mover y redimensionar estirando para que haya ms opciones visibles. Generalmente, son ventanas modales, es decir, mientras estn abiertas, el usuario no puede trabajar con ninguna otra ventana de la misma aplicacin o incluso, segn en qu sistema operativo, de todo el sistema.

Editorial UOC

223

Captulo VI. Diseo orientado a objetos

Elementos estticos

Los elementos estticos son elementos fijos y pasivos contenidos dentro de una ventana o un control complejo: ttulos y otras etiquetas, lneas, logotipos, dibujos que no sean iconos, etc.
Controles simples

Los controles son los componentes activos de la interfaz por medio de los cuales el usuario interacta con el software. Los hay simples y compuestos. Los principales tipos de controles simples son los que citamos a continuacin: a) Botones de mandato. Acostumbran a ser cuadrados o rectangulares. A menudo van agrupados por funciones relacionadas. Para identificar su funcin, llevan un icono, un texto o ambos. Cuando se seleccionan, aparentan estar hundidos o presentan algn otro cambio de aspecto.

Ejemplos de botones de mandatos En la figura podis ver un ejemplo de ventana modal con una caja de dilogo, carpeta con separadores y Check boxes .

Editorial UOC

224

Ingeniera del software

b) Iconos. Son pequeos dibujos. Cuando no van asociados a botones, es posible hacer clic, doble clic y arrastrar / dejar (en ingls, drag and drop). c) Check boxes. Son casillas cuadradas que corresponden a una variable booleana. Cuando sta toma el valor verdadero, la casilla aparece marcada. d) Botones de radio. Representan variables booleanas de las cuales slo una puede ser cierta en cada momento, o bien valores posibles e incompatibles de una variable. Por tanto, en un grupo de botones de radio, hay siempre uno seleccionado, y slo uno. En cambio, las check boxes son independientes.

Caja de dilogo y texto con scroll En la figura podis observar una caja de dilogo con carpeta con separadores, un conjunto de botones de radio (Export Control) y un texto de posibles lneas mltiples con barra de desplazamiento vertical.

e) Value sets. Son como botones de radio, pero con iconos en lugar de etiquetas. Por ejemplo, las paletas de colores.

Editorial UOC

225

Captulo VI. Diseo orientado a objetos

f) Campos de texto. Un texto es un campo alfanumrico de longitud virtualmente ilimitada. Segn la aplicacin, un texto puede ser un documento o slo el contenido de un control. En el ltimo caso, el texto puede ser de una lnea o de lneas mltiples con eventual barra de desplazamiento vertical y horizontal.

Editorial UOC

226

Ingeniera del software

g) Spin boxes. Permiten dar un valor, o aumentarlo o disminuirlo por saltos haciendo clic en unos botones con puntas de flecha.

Listas desplegables y spin boxes En la figura se pueden ver ejemplos de listas desplegables (una est desplegada) y algunas spin boxes (Sangra izquierda, derecha y otras).

Controles complejos

Los controles complejos son los que estn formados por otros controles. A continuacin mencionamos algunos tipos de controles de esta clase:

a) Listas y listas combo . Sus elementos pueden ser etiquetas o, ms raramente, iconos. En las listas combo se puede seleccionar un elemento existente o teclearlo; en cambio, en las listas ordinarias slo es posible seleccionar un elemento existente. Las listas y listas combo pueden ser permanentes (con barras de desplazamiento o no) o desplegables (en este caso tienen un control para desplegarlas, normalmente un botn con una punta de flecha hacia abajo).

Editorial UOC

227

Captulo VI. Diseo orientado a objetos

b) Tablas o matrices. As como las listas son unidimensionales, las tablas o matrices son bidimensionales y se organizan en celdas.

c) Cajas de dilogo. En este contexto, un dilogo es un intercambio de smbolos y acciones entre el sistema y el usuario. Las cajas de dilogo presentan opciones para escoger en forma de controles simples de todo tipo y tambin de listas, y tienen al menos un botn para confirmar y a menudo botones de ayuda

Editorial UOC

228

Ingeniera del software

y de cancelacin. Generalmente, van solas dentro de una ventana modal. Usos tpicos de las cajas de dilogo son la eleccin de opciones de impresin, la apertura de ficheros y la presentacin de mensajes que exigen respuesta, o al menos confirmacin, que ya se han visto.

d) Formularios. Son plantillas para la introduccin de datos. Se pueden considerar cajas de dilogo en las cuales predominan los campos de texto por encima de los controles para la seleccin de opciones.

Editorial UOC

229

Captulo VI. Diseo orientado a objetos

e) Carpetas. Carpetas de ficheros, y tambin carpetas con separadores a cada uno de los cuales corresponde una caja de dilogo.

f) Barras de herramientas. Son grupos de botones de mando, que a veces el usuario puede personalizar, de manera que es posible poner slo los botones deseados. Las barras de herramientas se pueden ocultar o hacer cambiar de forma, de ms alargada a ms cuadrada, y viceversa. A veces son flotantes y tienen ventana propia, que permanece en primer trmino aunque no tenga el foco.

Editorial UOC

230

Ingeniera del software

Los mens

Un men es una lista de etiquetas (que denominamos opciones del men) dentro de la cual el usuario puede seleccionar una cada vez haciendo clic con el ratn.
Ejemplos de opciones de men Las opciones del men pueden representar funciones de una aplicacin, ficheros de una carpeta, ordenadores de una red, valores de una variable, etc.

Las opciones del men pueden ser palabras o frases cortas o iconos y pueden tener significados muy variados. Es posible que haya opciones las cuales en un momento dado no sean seleccionables, y entonces aparecen en gris en lugar de en negro. Adems de las opciones, puede haber lneas de separacin de grupos de opciones. Cada opcin puede ir acompaada de un acelerador (combinacin de teclas equivalente a la opcin), un mnemotcnico (una letra equivalente a la opcin) y una marca que indica que se ha seleccionado la opcin.
Clasificacin de los mens

a) Mens permanentes. Son aquellos mens que estn asociados a una ventana de aplicacin y son visibles mientras la ventana permanece activa. Los ms habituales son los mens de barra.

Editorial UOC

231

Captulo VI. Diseo orientado a objetos

b) Mens temporales. Estos mens son visibles slo cuando el usuario los abre*, y desaparecen cuando el usuario selecciona un elemento, o bien cuando suelta el botn del ratn (en algunos casos), o hace clic en otro objeto.

Adems de las opciones, puede haber lneas de separacin de grupos de opciones. Cada opcin puede ir acompaada de un acelerador (combinacin de teclas equivalente a la opcin), un mnemotcnico (una letra equivalente a la opcin) y una marca que indica que se ha seleccionado la opcin. c) Mens desplegables. Los denominados mens desplegables o mens de persiana (en ingls, pull_down, drop down menus) se despliegan hacia abajo.

* . Un men se abre por ejemplo, seleccionando un elemento del men de barra o de otro men temporal, o bien haciendo clic en un icono.

Editorial UOC

232

Ingeniera del software

d) En los sistemas de mens en cascada, cuando se selecciona un elemento de un men desplegable, se despliega otro men al lado. Un elemento de un men al cual le corresponde un nuevo men acostumbra a ir acompaado de un tringulo negro con la punta hacia el lado donde est dicho men.

e) Mens emergentes. Estos mens (en ingls, pop_up menus) no forman parte de una cascada, sino que surgen (a menudo hacia arriba o hacia la direccin en que hay ms espacio disponible) cuando el usuario hace clic con el ratn dentro de un rea determinada de una ventana o del escritorio. Entre estos tipos de mens estn los asociados a un objeto grfico, que a menudo se despliegan con el botn derecho.

Editorial UOC

233

Captulo VI. Diseo orientado a objetos

7.1.2. La interaccin

En este subapartado pasamos a mencionar los diferentes tipos de interaccin que podemos encontrar y la manera en que se resuelven. El modelo objeto-accin Para describir la interaccin entre el usuario y el ordenador mediante una interfaz grfica utilizaremos el modelo objeto-accin. El modelo objeto-accin considera que una interaccin elemental tiene dos fases: Primero, el usuario selecciona un objeto. Despus, el usuario selecciona una accin que se aplicar sobre este objeto. A veces intervienen dos objetos: aqul con el cual el usuario trabaja y aqul al cual transfiere informacin.
Por ejemplo, cuando un fichero se mueve en una carpeta.

La seleccin de objetos

La seleccin de objetos consiste en la identificacin por el usuario de un objeto o ms de cara a hacer despus una accin o ms sobre stos, pero no sobre el resto de los objetos. La seleccin se realiza principalmente haciendo clic en los objetos con el ratn, pero tambin se puede llevar a cabo con el cursor si se utilizan las teclas que lo mueven. Los objetos seleccionados cambian de aspecto. La seleccin puede ser de dos tipos: 1) Seleccin simple. Se selecciona un nico elemento de una lista (un icono o un carcter de un texto). 2) Seleccin mltiple. Los otros casos de seleccin, incluida la seleccin total de un documento, lista, tabla o diagrama. En la seleccin mltiple de los objetos de una lista o de caracteres de un texto, sta puede ser contigua o no.

Editorial UOC

234

Ingeniera del software

La activacin

Ejemplos de activacin de objetos Para activar un botn, se le invoca mediante la seleccin y a la vez se pone en marcha una accin vinculada al mismo. Para activar una ventana, hay que hacer clic sobre la misma en cualquier lugar. Entonces la ventana pasa a primer trmino, aparecen los controles de redimensionamiento y su marco toma color, mientras que la ventana que antes era activa pierde los controles, su marco se vuelve gris y queda en segundo trmino. La activacin de mens emergentes se hace a menudo con el botn derecho del ratn.

Transferencia de datos

La transferencia de datos consiste en mover objetos de un objeto contenedor (objeto fuente) a otro (objeto de destino). Las modalidades generales de transferencia de datos que podemos encontrar son:

Arrastrar y dejar (en ingls, draf and drop), por manipulacin directa. Cortar / copiar y pegar (en ingls, cut/copy and paste) mediante el portapapeles, por manipulacin indirecta.
La retroalimentacin

La finalidad de la retroalimentacin (en ingls, feedback) es que el usuario vea inmediatamente el efecto de sus acciones, incluso cuando todava no se han completado.

Ejemplos de modalidades de retroalimentacin Hay muchas modalidades de retroalimentacin. A continuacin mencionamos algunas: Los cambios de la forma del cursor cuando se sita en diferentes partes de una ventana. Los cambios de color de los objetos seleccionados.

Editorial UOC

235

Captulo VI. Diseo orientado a objetos

La silueta del objeto fuente que sigue el cursor durante una operacin de arrastre, mientras que el objeto de destino cambia de color cuando se entra en l. Los indicadores de progreso de operaciones largas, en forma de barras vacas (graduadas o no) que se van llenando, o de porcentajes que se van actualizando, o de mensajes.

Estilos de interaccin

La interaccin con la interfaz de usuario se puede llevar a cabo mediante mens, formularios, pregunta-respuesta, que puede ser lineal (siempre la misma serie de preguntas) o jerrquica (cada pregunta depende de las respuestas anteriores); lenguaje de mandatos, teclas de funcin, que pueden ser dedicadas (siempre la misma funcin) o programables; manipulacin directa o lenguaje natural.
Manipulacin directa e indirecta

La manipulacin de los objetos por el usuario puede tener lugar de una manera ms concreta o ms abstracta, segn una gama de posibilidades bastante amplia. Los extremos de esta gama son los siguientes estilos genricos: a) Manipulacin directa, en la cual el usuario indica al sistema la accin que quiere llevar a cabo sobre el objeto seleccionado simulndola con el ratn, estirando el objeto, arrastrndolo, etc. b) Manipulacin indirecta, en la cual, una vez seleccionado el objeto, el usuario indica al sistema la accin que quiere llevar a cabo sobre el objeto de una manera abstracta. Las ventajas de la manipulacin directa son las siguientes:
Definicin de abstracto y concreto La definicin de qu es concreto y qu es abstracto depende del usuario, puesto que para un matemtico el hecho de operar con ecuaciones se podra entender como una manipulacin directa.

La manipulacin directa hace el aprendizaje mucho ms fcil. El usuario recuerda mejor el uso del producto. El usuario tiene la sensacin de que controla ms lo que pasa. El usuario ve de manera inmediata el resultado de sus acciones.

Editorial UOC

236

Ingeniera del software

Por otro lado, la manipulacin directa presenta los siguientes inconvenientes: A menudo ocupa mucho espacio en la pantalla. A veces, su uso es ms lento. No siempre es fcil encontrar un modelo adecuado.
Ayuda en lnea al usuario

La ayuda en lnea (en ingls, on_line) al usuario es una alternativa a los tradicionales manuales impresos, que tiene importantes ventajas en comparacin con stos: No ocupa lugar en estanteras ni en la mesa de trabajo. No tiene deterioro fsico. Es ms fcil y barato ponerla al da. Se presta al aprendizaje interactivo (tutoriales on-line). El usuario puede recurrir a la informacin que busca de una manera ms rpida y flexible. No tiene una estructura lineal, sino en red (hipertexto). Ahora bien, tambin presenta algunos inconvenientes y limitaciones, que mencionamos a continuacin: Generalmente, es un poco ms difcil leer de una pantalla que de un manual. El paso entre pginas consecutivas es ms lento (en cambio, el salto a una pgina referenciada es mucho ms rpido). No se pueden hacer anotaciones al margen (pero hay sistemas que permiten que el usuario aada anotaciones propias en los textos de ayuda). La ayuda presentada tapa temporalmente la ventana donde trabajaba el usuario, al menos en parte.

7.2. El diseo de las interfaces grficas En primer lugar, veremos algunas caractersticas que conviene que tengan las interfaces, despus estudiaremos el proceso del diseo y, finalmente, haremos algunas recomendaciones sobre el uso de los distintos elementos grficos.

Editorial UOC

237

Captulo VI. Diseo orientado a objetos

7.2.1. Caractersticas de un buen diseo

El diseo debe tender a conseguir el mejor compromiso, para un software concreto, entre las siguientes caractersticas: a) Sensacin de control. Los usuarios no quieren tener la sensacin de ser controlados por el ordenador, e incluso en el caso de tutoriales guiados conviene dejar que el usuario tome la iniciativa de vez en cuando; es preciso que la interfaz sea esencialmente pasiva y la ayuda en lnea, discreta. b) Adecuacin al usuario. Los usuarios no son iguales que el diseador (no son profesionales de las GUI) y tampoco son iguales entre ellos. c) Familiaridad para el usuario. Conviene utilizar los conceptos, terminologa y organizacin a los que el usuario est acostumbrado. d) Adecuacin a la tarea del usuario. La interfaz grfica de usuario debe integrarse en el flujo de trabajo del usuario. e) Adecuacin al flujo de operaciones. Hay casos en los cuales el usuario cambia de tarea de manera frecuente e imprevisible. En estas situaciones, el cambio de tarea informtica debe ser gil. En cambio, en ocasiones el usuario cambia de una tarea determinada a otra, que es siempre la misma; entonces conviene que el sistema pase directamente. f) Continuidad con las versiones anteriores del software . Aunque un software nuevo siempre se hace para mejorar, conviene no obstante aprovechar al mximo la experiencia del usuario con las versiones anteriores, y presentarle lo mismo de igual manera, si no hay una razn de peso para hacerlo de un modo distinto. g) Manipulacin directa. Generalmente ser mejor para el usuario. Ahora bien, la manipulacin directa no siempre es viable. h) Flexibilidad. Conviene que la interfaz sea adaptable a las preferencias del usuario, y tambin a su nivel de experiencia. i) Tiempo de respuesta adecuado. El usuario espera que el ordenador responda rpido, pero, sobre todo, que cada vez que realiza la misma operacin tarde ms o menos el mismo tiempo. Cuando se prev que una operacin puede ser larga, conviene sacar un mensaje para tranquilizar al usuario que diga que la operacin va bien, o bien mostrarle el avance del proceso por medio de una barra que va cambiando de color por partes o un porcentaje de cumplimiento de la tarea.

Editorial UOC

238

Ingeniera del software

j) Atencin a la posibilidad de errores de usuario. k) Feedback inmediato al usuario. Por un lado, el usuario debe poder darse cuenta de que su accin ha sido aceptada o rechazada o de si ya se ha completado o no. Por otro lado, cuando la accin se ha completado, el usuario tiene que ver el resultado claramente (punteros y cursores situados de modo inmediato, siluetas que siguen el arrastre de objetos), etc. l) Sensacin de seguridad del usuario. Se debe facilitar que el usuario explore el producto sin riesgo de perder informacin o de perderse, permitindole deshacer la ltima accin y pidiendo confirmacin de las acciones peligrosas. m) Robustez. El ideal de robustez es que, haga lo que haga el usuario, el software no se descontrole. n) Coherencia. Es necesario que los elementos que desempean el mismo tipo de funcin tengan el mismo aspecto: ttulos, nombres de campos. Es deseable que haya consistencia tanto dentro de una aplicacin como entre aplicaciones, ya que en ambos casos puede facilitar extraordinariamente el aprendizaje. En el caso de interfaces implementadas con una herramienta orientada a objetos, el uso sistemtico de la herencia facilita el mantenimiento de la coherencia.
Ejemplo de coherencia Conviene que los botones en pantallas diferentes que sirven para la misma funcin sean iguales en cuanto a forma, medidas, color, texto y, si procede, posicin.

o) Facilidad de utilizacin. p) Facilidad de aprendizaje. A menudo, es difcil hacer compatibles todas estas caractersticas.

7.2.2. Mtodo de diseo de las interfaces grficas

Consideraremos un mtodo con las siguientes etapas: elaboracin de una gua de estilo, diseo y evaluacin del diseo en cuanto a las caractersticas de

Editorial UOC

239

Captulo VI. Diseo orientado a objetos

buen diseo mencionadas y al cumplimiento de la normativa y recomendaciones de estilo. 1) Elaboracin de una gua de estilo La gua de estilo debe incluir una normativa sobre todos los aspectos de la interfaz que conviene que estn normalizados: Ventanas de aplicacin, de documento y de cajas de dilogo: estilo, colores y controles. Tipo de letra e iconos estndar. Controles estndar, como botones de confirmacin, cancelacin y ayuda. Feedback: formas del puntero y del cursor y uso de cada una, etc. Si la herramienta de interfaz grfica est orientada a objetos, definir las superclases bsicas, de las cuales se definirn subclases en la etapa de implementacin.

2) Diseo La etapa de diseo parte del esquema del contenido de las ventanas y de la especificacin formal de los casos de uso obtenidos en la etapa de anlisis. El esquema del contenido slo indica qu datos deben figurar en cada ventana y cules de stos tienen una lista de valores posibles limitada, y aquellos aspectos que deban ser comunes a todas las ventanas de un mismo tipo estarn fijados por la gua de estilo. A partir de esta informacin se debe determinar la mejor manera de representar cada dato con la herramienta de interfaces grficas disponible y despus establecer el formato de cada ventana, ya sea mediante la herramienta con que se implementar la interfaz de usuario definitivamente, ya sea haciendo alguna clase de prototipo que despus se tendr que implementar de manera fiel. Teniendo en cuenta el dilogo* descrito dentro de la especificacin formal de los casos de uso, se disear el instrumento para seleccionar la funcin (mens, barras de herramientas, etc.) y tambin los controles que servirn para pasar de
*. El dilogo es el intercambio de mensajes entre el software y el usuario.

Editorial UOC

240

Ingeniera del software

una ventana a otra. Habr que buscar unos iconos adecuados; para asegurarse de que lo son, se comprobar si los usuarios los reconocen fcilmente.

7.2.3. Recomendaciones sobre el diseo de objetos grficos

Aqu veremos algunas recomendaciones relativas a ventanas, mens, controles y cajas de dilogo y tambin algunas orientaciones sobre la ayuda en lnea.

Recomendaciones sobre ventanas

a) Cuando se abra una ventana, conviene situarla en primer lugar, darle el foco y mantener una lista seleccionable de ventanas abiertas. Si es necesario, conviene ponerle controles de maximizar y minimizar. b) Cuando se reabra una ventana, es recomendable que se haga en la misma posicin y con las mismas medidas. c) Es conveniente prever algn control para cerrar las ventanas de aplicacin y de documento, cerrando o no la aplicacin o documento respectivos. d) No se tiene que permitir que la ventana se pueda mover a una posicin en la que sea inaccesible, y conviene hacer saber al usuario que se est a punto de mover la ventana o de redimensionarla (puntero con una forma especial) y el movimiento en curso. e) Cuando se maximiza una ventana, hay que guardar sus dimensiones anteriores y poner el control de minimizar o restaurar. f) Cuando se minimiza una ventana por primera vez, se tiene que colocar el icono en la parte baja del escritorio. Si la ventana ya se haba minimizado, se debe poner el icono en el lugar en que estaba antes.

Recomendaciones sobre mens

a) Hay que presentar de manera diferente del resto la opcin que se selecciona y las que estn inhabilitadas. En el caso de opciones binarias, conviene

Editorial UOC

241

Captulo VI. Diseo orientado a objetos

indicar cules estn seleccionadas, o cambiar el texto segn estn seleccionadas o no. b) Las opciones que se prev que se utilizarn ms deben ir al comienzo del men. c) Conviene evitar un nmero de niveles excesivo en los mens en cascada. d) Los mens pop-up tienen que ser de un solo nivel y no repetir las opciones de los mens ordinarios.
Recomendaciones sobre controles

a) La lista combo se utilizar cuando un campo pueda tomar unos valores muy frecuentes (que sern los de la lista), pero, no obstante, pueda tomar otros, que debe ser posible teclear. b) La lista ordinaria es adecuada cuando la lista de valores posibles est cerrada y es reducida. No obstante, si hay pocos valores posibles, se debe considerar la alternativa mucho ms rpida de los botones de radio, si los valores son excluyentes entre ellos, o las check boxes en el caso contrario. c) Tanto la lista ordinaria como la lista combo se harn desplegables cuando haya problemas de espacio, y persistentes con barra de desplazamiento cuando se disponga de espacio, pero la lista tenga demasiados valores. Los valores de la lista tienen que ir ordenados por frecuencia de uso decreciente o por orden alfabtico, etc. d) Una spin box es conveniente principalmente cuando los valores sugeridos son numricos con intervalos iguales. Se puede admitir o no un valor tecleado directamente. e) Los campos de texto de una sola lnea pueden tener visible slo la parte donde est el cursor. Los campos de lneas mltiples pueden tener barra de desplazamiento vertical y horizontal, y puede ser necesario permitir los saltos de lnea con una tecla que ya no se podr dedicar a otro uso en la misma ventana.
Recomendaciones sobre cajas de dilogo

a) Una caja de dilogo modal es adecuada cuando hay que interrumpir el proceso para advertir al usuario de una circunstancia anmala o pedirle una

Editorial UOC

242

Ingeniera del software

confirmacin de una accin conflictiva que haya pedido. Tiene que aparecer en primer trmino y recibir el foco. No se tiene que recurrir casi nunca a las cajas de dilogo modales, ya que hacen perder tiempo al usuario. b) Si la caja de dilogo puede tapar informacin que el usuario puede necesitar para tomar la decisin que se le pide, es necesario que sea posible desplazarla por la pantalla. c) Las cajas de dilogo no tienen que llenar toda la pantalla. Pueden tener doble formato: primero se presenta una caja de dilogo con los controles imprescindibles, y se da opcin al usuario de desplegar el resto. d) En una caja de dilogo debe haber al menos un botn para cerrarla. A menudo hay dos, uno para confirmar y otro para cancelar, que se recomienda que estn separados de los eventuales botones de mando. Se aconseja que los botones estn alineados horizontalmente (en la parte de abajo, hacia el ngulo derecho) o bien verticalmente. Conviene que haya un botn por omisin (es decir, el botn que se selecciona con la tecla de retorno de carro) con el contorno ms grueso que los otros botones y colocado en la parte superior de una columna de botones o en el extremo de una fila. El botn de ayuda tambin debe estar en una posicin destacada. e) Si hay un nmero significativo de controles, se deben distribuir en grupos. Los controles de un grupo deben estar relacionados lgicamente, pero no hace falta que sean del mismo tipo. Los grupos tienen que estar rodeados por alguna lnea o bien deben tener un texto de cabecera del grupo y sus campos tienen que estar alineados entre s y sangrados respecto al texto de cabecera. Si hay varios grupos, los textos de cabecera respectivos tienen que estar alineados.
En un mismo grupo de controles puede haber campos de texto y grupos de botones de radio.

f) Las carpetas con separadores son convenientes cuando la cantidad de informacin que se presenta es tan grande que puede llenar varias veces la ventana de la caja de dilogo.
Principios del diseo de la ayuda en lnea

A continuacin, mencionamos algunos principios que se deben tener en cuenta a la hora de realizar el diseo de la ayuda en lnea:

Editorial UOC

243

Captulo VI. Diseo orientado a objetos

1) El acceso a la ayuda tiene que ser fcil de encontrar. 2) La redaccin de los textos se tiene que hacer ponindose en el lugar del usuario, igual que en el caso de los manuales. 3) La informacin tiene que ser tan completa como sea posible, pero debe estar estructurada de manera que resulte fcil localizar exactamente lo que el usuario quiere en cada momento. 4) Debe ser posible volver a los textos de ayuda ya vistos en la misma sesin de ayuda. 5) Debe ser posible salir fcilmente de la ayuda y volver al punto en el que el usuario haba interrumpido su trabajo. 6) El tiempo de respuesta tiene que ser breve, ya que a menudo el usuario no encuentra lo que buscaba en el primer intento. 7) Debe tener un formato y un estilo coherentes tanto con el resto de la interfaz como con el resto de la documentacin.

8. Diseo de los subsistemas

Al comenzar el diseo, dentro del diseo arquitectnico, se haba establecido una descomposicin del sistema de software en subsistemas y se haban especificado las interfaces respectivas y las dependencias entre stas. Todo esto era provisional porque no se conocan todava todas las clases del diagrama esttico del diseo. Cuando se acaba el diseo, conviene llenar de contenido los subsistemas mencionados especificando qu clases comprende cada uno, haciendo explcitas las dependencias en el nivel de clase y de operacin entre s y comprobando si entre todas las clases y subsistemas de cada subsistema se implementa la interfaz explcita o implcita de la cual es responsable el subsistema. Si hay interfaces definidas explcitamente, conviene que las dependencias queden especificadas no entre subsistemas sino entre un subsistema y una interfaz, para facilitar la sustitucin de un subsistema por otro que implemente la misma interfaz.

Editorial UOC

244

Ingeniera del software

9. Ejemplo

En este apartado continuamos el ejemplo de los captulos anteriores. Veamos ahora el diseo. En situaciones reales, las especificaciones del diseo utilizaran la terminologa propia del lenguaje de programacin, la herramienta de interfaz grfica y el sistema de gestin de bases de datos concretos que se tengan que utilizar en la implementacin, pero al tratarse de un ejemplo general se ha utilizado una terminologa neutra.

9.1. El diseo arquitectnico

Puesto que no se utilizarn subsistemas ya existentes ni tampoco se prev que ningn subsistema sea reutilizable, los subsistemas corresponden a los paquetes identificados en el anlisis.

9.2. El diseo de los casos de uso

Caso de uso 1: Aadir local

Cuando el usuario selecciona la opcin correspondiente al men, se llama la operacin crear de la clase AdicionLocal. Esta operacin instancia la clase, determina el valor del nmero correlativo del local, abre una ventana e instancia el formato de pantalla PAadirLocal .

Otro procedimiento En lugar de especificaciones textuales (sangradas para indicar qu condiciones estn subordinadas a otras) se podran realizar diagramas de secuencia, pero en los casos reales a menudo seran muy complejos.

Editorial UOC

245

Captulo VI. Diseo orientado a objetos

1) Si el usuario cancela, se llama la operacin borrar de la clase AdicionLocal y se devuelve control al men. 2) Si el usuario confirma, se llama la operacin buscar de la clase Propietario con el NIF del propietario como parmetro. Entonces esta clase llama materializar de GestorCliente con el mismo parmetro.

a) Si no se encuentra al propietario, se llama la operacin crear de la clase AdicionPropietario descrita en el caso de uso 2. b) Si est el propietario o se ha aadido, se llama la operacin crear de la clase TiendaAlmacen, Oficina, Inmueble o Polivalente y se le pasa como parmetros la zona, el tipo, el nmero, la direccin del local, la superficie, el NIF del propietario, las caractersticas, las restricciones y el agente y el volumen en el caso de tiendaalmacn y polivalente, y las caractersticas polivalentes en el caso de polivalente. Esta operacin crea un objeto de la subclase correspondiente, mueve estos valores uno a uno a sus atributos y llama grabar de GestorLocal con el objeto creado como parmetro.

Caso de uso 2: Aadir propietario

Cuando el usuario selecciona la opcin correspondiente al men, se llama la operacin crear de la clase AdicionPropietario y sta abre una ventana modal para introducir el NIF.

1) Si el usuario cancela, se llama la operacin borrar de la clase AdicionPropietario y se devuelve el control al men. 2) Si el usuario confirma, se llama la operacin buscar de la clase Propietario con el NIF del propietario como parmetro y entonces la clase llama materializar de GestorCliente con el mismo parmetro.

a) Si se encuentra el propietario, se abre una ventana modal y se muestra el mensaje El propietario con NIF X ya existe. b) Si no se encuentra el propietario, se abre una ventana y se presenta el formato de pantalla PAadirPropietario .

Editorial UOC

246

Ingeniera del software

Si el usuario cancela, se llama la operacin borrar de la clase AdicionPropietario y se devuelve el control al men. Si el usuario confirma, se llama la operacin crear de la clase Propietario y se le pasan como parmetros el NIF, los apellidos y nombre/razn social, la direccin y el telfono. La crea el objeto, le pone los valores de los atributos y llama grabar de GestorClientes con el objeto como parmetro.
Caso de uso 3: Introducir informe

Cuando el usuario selecciona la opcin correspondiente al men, se llama la operacin crear de la clase IntroduccionInforme. Esta operacin instancia la clase y abre una ventana modal que pide el cdigo del local.

1) Si el usuario cancela, se llama la operacin borrar de la clase IntroduccionInforme y se devuelve control al men. 2) Si el usuario confirma, se llama la operacin buscar de la clase Local con los componentes del cdigo del local (zona, tipo y nmero) como parmetros. sta llamar materializar de GestorLocal. a) Si no se encuentra el local, se muestra el mensaje El local XXX no existe en una ventana modal, se llama la operacin borrar de la clase IntroduccionInforme y se devuelve el control al men. b) De otra manera, se abre una ventana y se presenta el formato de pantalla PIntroducirInforme . Si el usuario introduce los datos y confirma, se llama la operacin modificar de la clase Local y se le pasan como parmetros los mismos que para la operacin crear ms un valor nulo para el NIF del arrendatario, la forma, la accesibilidad, las instalaciones, la visibilidad, la conservacin, el precio y el inspector. Esta operacin sustituye los valores de los atributos por los valores tecleados, llama grabar de GestorLocal y le pasa el objeto de Local como parmetro. Si el usuario cancela, se llama la operacin borrar de la clase AdicionPropietario y se devuelve el control al men.

Editorial UOC

247

Captulo VI. Diseo orientado a objetos

Caso de uso 4: Introducir contrato

Cuando el usuario selecciona la opcin correspondiente al men, se llama la operacin crear de la clase IntroduccionContrato. La operacin instancia la clase, abre una ventana y presenta el formato de pantalla PIntroducirContrato. 1) Si el usuario cancela, se llama la operacin borrar de la clase IntroduccionContrato y se devuelve control al men. 2) Si el usuario confirma, se llama la operacin buscar de la clase Local con la zona, el tipo y el nmero como parmetros.

a) Si no se encuentra el local, se muestra el mensaje El local XXX no existe, se llama la operacin borrar de la clase IntroduccionContrato y se devuelve el control al men. De otro modo, se llama la operacin buscar de la clase Arrendatario con el NIF como parmetro. b) Si no se encuentra el arrendatario, se llama la operacin crear de la clase AdicionArrendatario , que abre una ventana y presenta el formato de pantalla PIntroducirArrendatario .

Si el usuario cancela, se llama la operacin borrar de la clase IntroduccionContrato y se devuelve el control al men. Si el usuario confirma, se llama la operacin crear de la clase Arrendatario y se le pasan como parmetros el NIF, los apellidos y nombre/razn social, la direccin y el telfono. Entonces la clase llamar grabar de GestorCliente con los mismos parmetros.

Despus se llama la operacin crear de la clase Contrato y se le pasa como parmetros el NIF del arrendatario y el NIF del propietario, el cdigo del local, la fecha de inicio y la de finalizacin. Esta operacin crea un objeto Contratos, le pone los valores de los atributos y llama estas otras: buscar de Propietario y de Arrendatario con los NIF respectivos como parmetros, buscar de Local con la zona, el tipo y el nmero como parmetros, modificar de Local con los datos ledos ms el NIF del arrendatario y grabar de GestorContrato, e imprime los datos del contrato: NIF, apellidos y nombre/razn social y direccin tanto del propietario

Editorial UOC

248

Ingeniera del software

como del arrendatario, la direccin del local, la fecha de inicio y la de finalizacin.

Caso de uso 5: Aadir arrendatario

Cuando el usuario selecciona la opcin correspondiente al men, se llama la operacin crear de la clase AdicionArrendatario. sta abre una ventana modal para introducir el NIF. 1) Si el usuario cancela, se llama la operacin borrar de la clase AdicionArrendatario y se devuelve el control al men. 2) Si el usuario confirma, se llama la operacin buscar de la clase Arrendatario con el NIF del arrendatario como parmetro.

a) Si se encuentra el arrendatario, se abre una ventana modal y se muestra el mensaje El arrendatario con NIF ya existe. b) Si no se encuentra al arrendatario, se llama la operacin crear de la clase AdicionArrendatario , que abre una ventana y presenta el formato de pantalla PAadirArrendatario. Si el usuario cancela, se llama la operacin borrar de la clase AdicionArrendatario y se devuelve control al men. Si el usuario confirma, se llama la operacin crear de la clase Arrendatario y pasa como parmetros el NIF, los apellidos y nombre/razn social, la direccin, el telfono. Esta operacin crea un objeto Cliente, le pone los valores de los atributos y llama grabar de GestorCliente con el objeto creado como parmetro.

Caso de uso 6: Aadir eventual arrendatario

Este caso es una especializacin del caso de uso nmero 5 en el cual las clases Arrendatario y AdicionArrendatario se sustituyen por EventualArrendatario y AdicionEventualArrendatario respectivamente. La operacin crear de la clase EventualArrendatario tiene como parmetros la lista de zonas, el tipo, la superficie y los requisitos adems de los parmetros de crear de Arrendatario.

Editorial UOC

249

Captulo VI. Diseo orientado a objetos

Caso de uso 7: Buscar locales

Cuando el usuario selecciona la opcin correspondiente al men, se llama la operacin crear de la clase BuscaLocales. La operacin instancia la clase, abre una ventana y presenta el formato de pantalla PBuscarLocales.
Casos de uso adicionales De acuerdo con lo que se ha especificado en la etapa de anlisis habra que prever casos de uso adicionales para que toda la informacin se pudiera consultar, modificar y borrar.

1) Si el usuario cancela, se llama la operacin borrar de la clase BuscaLocales y se devuelve el control al men. 2) Si el usuario confirma, se llama la operacin consultar de la clase Local con el NIF del propietario y del arrendatario, la zona, el tipo, el nmero y la superficie mnima como parmetros. Esta operacin llama consultar de GestorLocal con los mismos parmetros. En el caso de que el tipo pedido sea tienda-almacn u oficina se buscan tambin los de tipo polivalente. a) Si no se encuentra ningn local, se abre una ventana modal y se muestra el mensaje No hay ningn local que cumpla las condiciones. b) Si se encuentra al menos un local, se abre una ventana y se presenta el formato de pantalla PListaLocales . Si el usuario selecciona un local de la lista y confirma, se llama la operacin buscar de la clase Local y se le pasan como parmetros la zona, el tipo y el nmero del local seleccionado; despus, se abre una ventana y se presenta el formato de pantalla PDatosLocal. Cuando el usuario cancela, se vuelve a sacar el formato de pantalla PListaLocales. Si el usuario cancela, se llama la operacin borrar de la clase BuscaLocales y se devuelve el control al men.

9.3. El diagrama esttico de diseo En las clases del diagrama esttico de diseo se han indicado slo los atributos que se han aadido a la versin de anlisis para implementar las asociaciones; las operaciones se indican todas.

Editorial UOC

250

Ingeniera del software

Editorial UOC

251

Captulo VI. Diseo orientado a objetos

En Local se han incluido el NIF del propietario y el del arrendatario para implementar las asociaciones de esta clase con Propietario y arrendatario respectivamente; slo se ha implementado uno de los sentidos de estas asociaciones, ya que no es necesaria la navegabilidad en sentido contrario. En Contrato se han aadido el NIF del arrendatario y la zona, tipo y nmero del local para implementar las asociaciones correspondientes. La herencia doble de Polivalente se ha convertido en herencia simple de TiendaAlmacen sin tener que hacer nada ms, ya que no hereda ni atributos ni operaciones de Oficina. Slo se especifica la lista de parmetros de las operaciones cuando es corta, por razones de espacio y porque ya estn descritas completamente en la especificacin de los casos de uso. Sin embargo, cuando se documentan las clases con herramientas CASE, que a menudo permiten visualizar las listas de parmetros de varias maneras, s que se especifican completamente. Slo se han incluido las operaciones que figuran en el diseo de los casos de uso. Todas las clases deben tener una operacin para borrar los objetos y es conveniente que todas las clases de entidades tengan al menos una operacin para modificar los atributos. Naturalmente, tendra que haber tambin casos de uso que las utilizasen.

9.4. El diseo de la persistencia

Para realizar el diseo de la persistencia en este ejemplo, consideraremos que se utiliza una base de datos relacional.

9.4.1. Diseo de la base de datos

Para hacer el diseo de la base de datos, primero eliminaremos la herencia, despus elaboraremos el diagrama ER equivalente al diagrama esttico de las clases persistentes y, por ltimo, obtendremos la especificacin de la base de datos relacional.

Editorial UOC

252

Ingeniera del software

Supresin de la herencia

Existen dos jerarquas de herencia encabezadas por las clases Local y Cliente , respectivamente. Entre las opciones mencionadas para la supresin de la herencia (una tabla diferente para cada subclase, una tabla para la superclase y otra para cada subclase, y una sola tabla para todo), hacemos la eleccin siguiente: 1) Para la jerarqua de Local, la tercera, ya que se supone que las tiendas-almacn sern la mayora de los locales y el atributo caracteristicas_polivalentes es de longitud variable y, por tanto, su valor nulo ocupa muy poco espacio. 2) Para la jerarqua de Cliente, la segunda, ya que slo hay que prever una tabla complementaria para una de las subclases, EventualArrendatario , y sta es minoritaria, dado que un eventual arrendatario, o bien pasa a arrendatario (y entonces se borran los atributos de la subclase) o bien se borra completamente al poco tiempo.
Diagrama entidad-relacin

El diagrama entidad relacin que corresponde a este caso es el que vemos a continuacin:

Editorial UOC

253

Captulo VI. Diseo orientado a objetos

Base de datos relacional

En los casos reales, la descripcin de la base de datos se hace en trminos de un sistema de gestin de bases de datos concreto, obviamente el que se utilizar en el proyecto. Sin embargo, aqu, para que el ejemplo sea ms general, se utiliza la terminologa general del modelo relacional. Las tablas de la base de datos sern stas: tabla_clientes, con las columnas NIF, nombre, direccion y telefono. La clave primaria es NIF. tabla_eventuales_arrendatarios, con las columnas NIF, tipo_local, zona1, ..., zona5, superficie_minima y requisitos_varios. NIF es la clave primaria y a la vez clave secundaria correspondiente a NIF de tabla_clientes. tabla_locales, con las columnas zona, tipo, numero, direccion, superficie, caracteristicas, NIF_propietario , accesibilidad, instalaciones , agente, inspector, volumen y caracteristicas_polivalente. La clave primaria se compone de los atributos zona, tipo y numero y NIF_propietario es clave secundaria correspondiente a NIF de tabla_clientes. tabla_contratos, con las columnas zona, tipo, numero , NIF_arrendatario , fecha_inicio , fecha_fin y vendedor. La clave primaria se compone de los atributos zona, tipo , numero, NIF_arrendatario y fecha_inicio. Hay dos claves secundarias NIF_arrendatario correspondientes a NIF de tabla_clientes, y otra compuesta de los atributos zona, tipo y numero que corresponde a la clave primaria de tabla_locales. En lo que respecta a los ndices, debera haber uno por cada clave primaria. En principio, no hace falta ndice para ninguna de las claves secundarias.

9.4.2. Gestores de disco Aplicaremos a este caso el esquema general que seguimos en este captulo. Los gestores son GestorLocal, GestorCliente y GestorContrato, y son subclases de GestorRelacional : a) GestorLocal se instancia al poner en marcha el sistema, por medio de la operacin crear. La operacin leerFila lee una fila de tabla_locales identificada

Editorial UOC

254

Ingeniera del software

por la clave primaria con los valores de todas las columnas. La operacin filaAObjeto crea un objeto de Local y mueve estos valores uno a uno a sus atributos. La operacin objetoAFila mueve uno a uno los atributos del objeto de Local a los valores de las columnas de una fila de tabla_locales. La operacin grabarFila graba esta fila en tabla_locales. La operacin consultar hace una consulta en tabla_locales con una condicin que depender de cules de los parmetros tengan un valor no nulo y llama filaAObjeto para cada una de las filas obtenidas. b) GestorCliente se instancia al poner en marcha el sistema por medio de la operacin crear. La operacin leerFila lee una fila de tabla_clientes y otra de tabla_eventuales_arrendatarios identificadas por la clave primaria, y la operacin filaAObjeto crea un objeto de EventualArrendatario , si alguno de los atributos especficos de esta subclase tiene un valor no nulo, o un objeto de Cliente y le mueve los valores de las filas mencionadas. La operacin objetoAFila mueve uno a uno los atributos del objeto de Cliente a los valores de las columnas de una fila de tabla_clientes y otra de tabla_eventuales_arrendatarios. La operacin grabarFila graba la primera de estas filas siempre y la segunda slo si alguno de los atributos especficos de EventualArrendatario tiene un valor no nulo. c) GestorContrato se instancia al poner en marcha el sistema por medio de la operacin crear. La operacin leerFila lee una fila de tabla_contratos identificada por la clave primaria con los valores de todas las columnas y la operacin filaAObjeto crea un objeto de Local y mueve estos valores uno a uno a sus atributos. La operacin objetoAFila mueve uno a uno los atributos del objeto de Contrato a los valores de las columnas de una fila de tabla_contratos. La operacin grabarFila graba esta fila en tabla_contratos.

9.5. El diseo de la interfaz de usuario

En este subapartado veremos cmo se representan los diferentes datos, cmo se implementan los dilogos y el diseo de algunas ventanas. No estableceremos ninguna gua de estilo concreta, ya que puede variar bastante de una organizacin a otra.

Editorial UOC

255

Captulo VI. Diseo orientado a objetos

9.5.1. Presentacin de los datos

Con vistas a conseguir una interfaz de usuario coherente, es necesario que cada dato se presente de la misma manera en todos los formularios en los que sale. Empezaremos por decidir cmo se presentar cada dato:

Los datos de tipo textual se presentarn en forma de reas de texto con barra de desplazamiento vertical, ya que permiten textos medianamente largos y son menos incmodas que las que tienen tambin barra de desplazamiento horizontal. Los campos de longitud fija se presentarn como campo de texto cuando son slo de salida. Cuando son tambin de entrada, si el nmero de valores posibles es reducido, el valor se escoger de una lista (una lista combo, si se pueden aadir valores y una lista ordinaria, en caso contrario); en lugar de una lista ordinaria de menos de seis valores fijos se utilizar un conjunto de botones de radio. Para datos booleanos, utilizaremos check boxes.

Aplicando estas normas, el tipo de local se introducir mediante botones de radio; la zona, el agente, el inspector y la conservacin se seleccionarn de listas ordinarias; el nmero de local, los NIF, los telfonos, las superficies, los datos y el precio sern campos de texto, y tambin lo sern todos los datos anteriores cuando no se puedan modificar; el resto de los datos lo constituirn textos con barra de desplazamiento vertical. No hay ningn dato booleano y, por tanto, las check boxes slo se usarn para opciones dentro de las ventanas.

9.5.2. Implementacin de los dilogos

Veremos en primer lugar la implementacin de la seleccin de la funcin y despus los instrumentos para pasar de una pantalla a otra.

Editorial UOC

256

Ingeniera del software

Los mens

Las opciones del sistema de mens son las que corresponden a los casos de uso ms las opciones de salir del sistema y de llamar la ayuda en lnea. Puesto que son pocas y caben en el men de barra, no es preciso mens desplegables. Tampoco es necesaria una barra de herramientas, ya que sera una duplicacin del men de barra con iconos en lugar de etiquetas. El men de barra sale en la parte superior de la pantalla inicial y tiene las entradas correspondientes a estas etiquetas, de izquierda a derecha: Salir, Alta local, Informe, Contrato, Eventual arrendatario, Locales, Propietario, Arrendatario y Ayuda. Salir se ha puesto como primera opcin y Ayuda como ltima porque es la misma colocacin que en el resto del software que utilizan los usuarios. Se ha utilizado la etiqueta Alta local en lugar de Local porque la ltima se parece demasiado a otra.
Paso de una pantalla a otra

La opcin de cancelar la funcin se pide por medio de un botn con la etiqueta Cancelar; la llamada en la ayuda en lnea se hace con un botn con la etiqueta Ayuda; para confirmar los datos introducidos, se hace clic en un botn con la etiqueta Confirmar y, para salir de una ventana que muestra el resultado de una consulta, hay un botn con la etiqueta Salir.

9.5.3. Formato de algunas ventanas

En una situacin real, las ventanas y su contenido estaran codificadas con la herramienta con que se implementarn finalmente, o bien con una herramienta de prototipos (en este ltimo caso, durante la implementacin se codificara una interfaz con la misma apariencia por medio de la herramienta definitiva). Aqu hay un dibujo esquemtico de las ventanas, si tenemos en cuenta que muchos detalles dependeran tanto de las prescripciones de la gua de estilo como de la herramienta. Veremos dos de las ventanas: la del alta de local (PantallaAadirLocal ) y una ventana modal para un mensaje.

Editorial UOC

257

Captulo VI. Diseo orientado a objetos

Como se ha dicho anteriormente, el tipo de local se representa mediante un grupo de botones de radio que corresponden a los cuatro valores posibles. Cuando se presenta la ventana, est seleccionado el valor Tienda-Almacn, que es el ms frecuente. Esto tiene la ventaja de que muchas veces el usuario no deber seleccionar el valor y el inconveniente de que, si tena que haber seleccionado otro y no lo hace, da un valor errneo y no ha recibido ningn aviso. Una punta de flecha sola indica una lista desplegable, y un par significa una barra de desplazamiento vertical.

Editorial UOC

258

Ingeniera del software

No todas las ventanas modales deben tener los tres botones indicados. Por ejemplo, una ventana que simplemente presente un mensaje muy fcil de interpretar slo debe tener un botn Salir.

9.6. El diseo de los subsistemas

Como hemos visto, los subsistemas coinciden con los paquetes establecidos en la etapa de anlisis. Estos paquetes son los que vemos a continuacin:

El contenido de los subsistemas es el siguiente: a) BasicoLocales comprende las clases Local con todas sus subclases y Cliente con su subclase Propietario, y los gestores de disco correspondientes. En lo que respecta a los casos de uso, incluye el 1 Aadir local y el 2 Aadir propietario.

Editorial UOC

259

Captulo VI. Diseo orientado a objetos

b) Informes comprende el caso de uso 3 Introducir informe. c) Contratos comprende las clases Arrendatario y Contrato y los casos de uso 4 (Introducir contrato), y 5 (Aadir arrendatario). d) Consultas contiene la clase EventualArrendatario y los casos de uso 6 (Aadir eventual arrendatario), y 7 (Buscar locales). De la utilizacin de las clases y sus operaciones en los casos de uso obtenemos que las interfaces (no formalizadas en trminos de UML) de estos subsistemas son las siguientes: Locales. Las operaciones buscar, modificar y consultar de la clase Local. BasicoLocales. Las operaciones buscar y modificar de la clase Local.

Editorial UOC

260

Captulo VI. Diseo orientado a objetos

Conclusiones

En la etapa de diseo se especifica cmo se tiene que implementar el software para que satisfaga las necesidades de informacin reunidas en la etapa de recogida y documentacin de requisitos y formalizadas en la etapa de anlisis. La reutilizacin es un aspecto cada vez ms importante de la construccin de software; durante el diseo se toman las decisiones sobre la reutilizacin. Los marcos, componentes y clases ya estn implementados y, por tanto, se pueden incluir directamente dentro del software a la hora de implementarlo, mientras que los patrones slo son ideas (probadas y documentadas) para resolver problemas de diseo concretos. El primer paso del diseo es el diseo arquitectnico, dentro del cual se deciden dos aspectos que condicionarn de manera decisiva el resto del diseo: la eventual utilizacin de marcos y la descomposicin del software en subsistemas. La parte principal de la etapa es el diseo de la implementacin de los casos de uso, que consiste en la especificacin de la colaboracin entre las clases de control y tambin entre stas y las clases de entidad. As, se obtiene el diagrama esttico de anlisis que, un vez revisado de cara a conseguir un acoplamiento bajo, coherencia alta y flexibilidad ante los probables cambios futuros, se complementa con la especificacin detallada de las clases que contiene, y en especial de sus operaciones. Tambin hay que disear la interfaz de usuario y los mecanismos relativos a la persistencia de las clases de entidades.

Editorial UOC

261

Captulo VII. Introduccin al software ...

Captulo VII

Introduccin al software distribuido

Todos sabemos que cada vez son ms raros los ordenadores que no forman parte de una red (ms bien, tendramos que decir de la red mundial). A pesar de que cada uno de los ordenadores de una red podra tener un software independiente que se ejecutase slo de forma local, en muchas aplicaciones es ventajoso que colaboren distintos ordenadores; las modalidades, conceptos y herramientas bsicas para esta colaboracin es lo que se ve de forma introductoria, ciertamente en este captulo.

1. Entornos distribuidos y entornos abiertos

Hablamos de entorno distribuido cuando el software de una aplicacin se ejecuta repartido entre varios ordenadores de una red; entonces, tambin decimos que el software en cuestin es distribuido. La utilizacin de entornos distribuidos es relativamente reciente, y se debe a la sustitucin de las plataformas ms antiguas de hardware y software bsico. Simplificando, se puede decir que la razn decisiva para la evolucin hacia los entornos distribuidos es que la misma capacidad de proceso resulta mucho ms barata si se consigue con PC que con mainframes o mquinas Unix.
La evolucin de las plataformas Por un lado, las tarjetas perforadas fueron arrinconadas por los terminales de pantalla, y despus las sustituyeron los microordenadores, que al principio las emulaban;

Editorial UOC

262

Ingeniera del software

por otro lado, los ordenadores medianos (miniordenadores) reemplazaron, en parte, los mainframes, y despus las redes locales y los sistemas cliente/servidor han ocupado el lugar de los sistemas con los miniordenadores y mainframes que quedaban.

1.1. Objetivos de los entornos distribuidos

Los entornos distribuidos fueron creados para alcanzar los siguientes objetivos: 1) Portabilidad de aplicaciones y de servicios del sistema, que quiere decir que las dos se pueden ejecutar indistintamente en varios ordenadores. 2) Interoperabilidad, que significa que sus diferentes ordenadores y aplicaciones sean capaces de comunicarse por medio de instrucciones y formatos de datos que todos comprendan. 3) Integracin, que significa que los intercambios de informacin se pueden hacer sin necesidad de intervenciones externas, y tambin que el funcionamiento del software y la presentacin de la informacin tengan una cierta uniformidad.
Por ejemplo, compartiendo directamente la informacin.

4) Transparencia, en el sentido de que los usuarios puedan leer datos de un ordenador sin saber dnde est (transparencia en la ubicacin de los datos), y los procesos se puedan ejecutar indistintamente en varios ordenadores sin que los usuarios sepan en cul se ejecutan (transparencia en la ejecucin). 5) Facilidad de crecimiento del sistema, que tiene dos vertientes: que se pueda aadir con facilidad hardware o software, y que los componentes de este hardware o software se puedan sustituir sin demasiada complicacin por otros ms avanzados o ms potentes. 6) Compartimiento, en el sentido de que las aplicaciones, los recursos y los servicios puedan ser compartidos sin barreras tcnicas (otra cosa son las restricciones de acceso intencionadas). 7) Finalmente, tambin es importante la seguridad, que consiste en el hecho de que los datos de un usuario estn protegidos, en lo que respecta a consulta y actualizacin, de los dems usuarios y de los agentes externos, as como de evitar que las comunicaciones se espen.

Editorial UOC

263

Captulo VII. Introduccin al software ...

1.2. Importancia de las normas en los entornos distribuidos

Para que una arquitectura distribuida se pueda considerar bien diseada, es preciso que tenga potencialmente una vida mucho ms larga que los productos con los que est implementada. Para conseguirlo, es necesario que la arquitectura se base en normas ampliamente aceptadas, hecho que constituye una cierta garanta de que durante bastantes aos se encontrarn en el mercado productos que las cumplan y que, por lo tanto, se puedan utilizar para renovar y ampliar el sistema y aumentar su capacidad. Es necesario que la estandarizacin se aplique en los siguientes campos: ordenadores, plataformas de soporte de la interfaz con el usuario, sistemas operativos, protocolos de comunicaciones y sistemas operativos de red.

1.3. Concepto de sistema abierto

Un sistema abierto es un sistema distribuido en el que se intentan conseguir, por lo menos parcialmente, los objetivos de los sistemas distribuidos, y hacer que las interfaces entre sus componentes respeten un conjunto amplio y completo de normas sobre comunicaciones, programacin, presentacin e interfaces entre aplicaciones y servicios del sistema aceptadas internacionalmente.
Las interfaces en los sistemas abiertos Por ejemplo, en un sistema abierto no hace falta que todos los sistemas operativos sean de tipo Unix, ni es necesario prescindir de los sistemas operativos propios de una marca, siempre que todos los utilizados cumplan las normas que posibiliten el grado necesario de comunicacin mediante unas interfaces adecuadas (dicho de otro modo: que un sistema sea o no abierto no es cosa de los productos en s, sino de sus interfaces).

Cuando hablamos de normas en este contexto, queremos decir lo siguiente: o bien y de forma preferente normas ampliamente utilizadas y establecidas por organizaciones independientes,

Editorial UOC

264

Ingeniera del software

o bien normas que inicialmente pertenecen a un fabricante, pero que se han convertido en estndares de facto. Por lo tanto, con el fin de conseguir un sistema abierto, sera necesario evitar los siguientes aspectos: Los productos muy utilizados pero cerrados, en el sentido de que difcilmente pueden compartir datos con otros productos; y aquellas normas que, por las razones que sean, han sido objeto de escasas implementaciones.

1.3.1. Beneficiarios de los sistemas abiertos Los sistemas abiertos benefician a los siguientes grupos: Fabricantes de hardware y sistemas operativos: en la medida en que algunos aspectos del producto estn fijados por normas y ya no hace falta estudiar sus alternativas, se puede dedicar ms esfuerzo a mejorar sus arquitecturas y su funcionalidad. Fabricantes independientes de software: se benefician de un mercado ms amplio a consecuencia de la portabilidad, hecho que evita la necesidad de versiones especficas para cada plataforma. Empresas usuarias: se benefician de poder conectar sin problemas productos de fabricantes diferentes y de encontrar ms productos en el mercado (ya que muchos productos pasan a ser utilizables en muchas plataformas) y con precios ms bajos a causa del aumento de la competencia.

2. Entornos cliente/servidores clsicos

Actualmente, el entorno distribuido que se utiliza ms es el denominado cliente/servidor.

Editorial UOC

265

Captulo VII. Introduccin al software ...

La idea bsica de la arquitectura cliente/servidor es que un programa, el servidor, gestiona un recurso compartido concreto y hace determinadas funciones slo cuando las pide otro, el cliente, que es quien interacta con el usuario.
Un ejemplo sencillo de entorno cliente/servidor sera tener un sistema de gestin de base de datos activado en un servidor, y que los programas que se ejecutaran en los ordenadores clientes pudiesen emitir instrucciones de SQL para acceder a esta base de datos.

Normalmente, estos dos programas, el servidor y el cliente, estn en ordenadores distintos. Los requerimientos de los ordenadores clientes en lo que respecta a velocidad, memoria y capacidad de disco son muy diferentes de los de los servidores; unos y otros pueden ser ordenadores de modelo y marca diferentes y, adems, con frecuencia utilizan un sistema operativo diferente.

2.1. Ventajas e inconvenientes de la arquitectura cliente/servidor

Las ventajas de la arquitectura cliente/servidor son las siguientes: a) Permite que la informacin se procese cerca de donde se ha generado. b) Dado que las funciones del software quedan repartidas entre varias mquinas, es posible utilizar PC o estaciones de trabajo para los clientes, y mquinas UNIX (por ejemplo) para los servidores, todas de un coste mucho menor que los mainframes. c) El crecimiento del hardware puede ser gradual: Se puede aumentar gradualmente el nmero de clientes sin que sea necesario cambiar cada vez el servidor. Se puede sustituir el servidor sin que los clientes se vean afectados. Se puede aumentar la capacidad de un cliente sin tener que cambiar ni el servidor ni a los otros clientes. En algunas modalidades, se pueden aadir servidores sin tener que redisear la arquitectura en su conjunto.

Editorial UOC

266

Ingeniera del software

d) Facilita el uso de interfaces grficas de usuario y aplicaciones multimedia; la razn es que estas funciones necesitan el tratamiento de un volumen importante de informacin. Este tratamiento, si tuviese que hacerse de forma centralizada, necesitara un host de gran capacidad y unos envos de informacin muy considerables mediante las lneas. Muchas de estas ventajas significan simplemente que se consiguen, en mayor o menor grado, los objetivos de los entornos distribuidos. Los inconvenientes de la arquitectura cliente/servidor son los siguientes: a) El servidor puede ser un cuello de botella. b) El software distribuido es ms complejo que el no distribuido, y tambin es ms difcil probarlo y depurar errores en l; tambin la administracin y la problemtica de seguridad son bastante ms complejas. c) Cualquier sistema distribuido tiende a fallar con ms frecuencia que un sistema centralizado, ya que tiene ms componentes que pueden fallar independientemente.

2.2. Arquitecturas cliente/servidor de dos capas

Ahora veremos diferentes entornos de arquitecturas cliente/servidor de dos capas: 1) Entornos cliente/servidor de primera generacin: es tpico de las redes de rea local (LAN); los clientes son PC o estaciones de trabajo en los que se ejecutan las aplicaciones; al principio, los servidores slo llevan a cabo funciones generales y de bajo nivel, como por ejemplo gestionar ficheros o impresoras compartidas. Ms adelante se empieza a pasar parte de las aplicaciones a un servidor adicional, si bien los clientes continan iniciando y controlando los procesos en parte. 2) Entornos de igual a igual: un ordenador acta como cliente para otras mquinas, y como servidor para estas mismas u otras, incluso para s mismo.

Editorial UOC

267

Captulo VII. Introduccin al software ...

3) Entornos cliente/servidor de segunda generacin: hay varios servidores especializados en funciones diferentes que pueden pedir los clientes; por ejemplo, gestin de bases de datos, aplicaciones, etc. Los clientes pueden ser mviles.

2.2.1. Imitaciones de la arquitectura cliente/servidor de dos capas

Este tipo de arquitecturas presenta las siguientes limitaciones: Limitaciones al crecimiento del nmero de clientes, ya que todos se conectan directamente al servidor. Dificultad de mantener el software de los clientes, ya que cualquier cambio se debe hacer en todos al mismo tiempo.

2.3. Arquitecturas de ms de dos capas

2.3.1. Arquitectura de tres capas basada en plataformas

En el caso ms general de arquitectura de tres capas basada en plataforma, la estructura es la siguiente: 1) Primera capa: el servidor. 2) Segunda capa: los agentes. 3) Tercera capa: los clientes. Los agentes pueden realizar funciones como por ejemplo stas: Traduccin de aplicaciones.
Ejemplo Una traduccin de aplicacin consiste, por ejemplo, en adaptar a un entorno cliente/ servidor una aplicacin antigua sobre el servidor.

Editorial UOC

268

Ingeniera del software

Control de la carga del servidor. Servicios de agente inteligentes, como por ejemplo descomponer una peticin de servicio por parte de un cliente en varias peticiones a uno o a varios servidores; el hecho de que hubiese varios servidores representara cierta transicin hacia el middleware (programa intermedio). Este modelo se puede expandir horizontalmente a todos los niveles con una cierta facilidad. El inconveniente principal es la fuerte dependencia de las plataformas utilizadas.

2.3.2. Arquitectura de tres capas basada en las funciones

Este tipo de arquitectura presenta las tres capas siguientes: 1) Clientes, que tienen la lgica de tratamiento de la interfaz con el usuario y parte de la lgica de aplicacin. 2) Servidores de aplicacin, en los que reside la mayor parte de la lgica de aplicacin y manipulacin de datos. 3) Servidores de datos, que presentan los gestores de bases de datos.

3. Entornos con middleware: CORBA

3.1. Concepto de middleware

Cuando la red aumenta todava ms sus dimensiones e incorpora multiplicidad de aplicaciones, plataformas y redes, es necesario un componente que gestione la comunicacin entre todos estos elementos; este componente va colocado entre los clientes y los servidores, y por este motivo se denomina software intermedio o middleware.

Editorial UOC

269

Captulo VII. Introduccin al software ...

El software intermedio debe soportar diferentes protocolos e interfaces de comunicaciones y de acceso a los datos, as como permitir conexiones dinmicas entre clientes y servidores.

3.2. CORBA

El software distribuido se puede desarrollar con tecnologa orientada a objetos y con tecnologa clsica. Sin embargo, la forma en que funciona el software orientado a objetos, por medio de mensajes entre objetos que piden la ejecucin de operaciones, se presta muy bien a la distribucin; esto se debe a que un mensaje a un objeto que est en otro ordenador puede ser igual, en cuanto a la forma, que un mensaje a un objeto que est en el mismo ordenador, si se cuenta con la infraestructura necesaria para hacer llegar cada mensaje a su destinatario, est donde est. Dicho de otro modo, cualquier software orientado a objetos funciona por llamadas a operaciones entre un objeto que acta de cliente y otro que acta de servidor; observad que decimos acta y no es porque el mismo objeto puede hacer de cliente en una llamada y de servidor en otra. La Common Object Request Broker Architecture (CORBA) es una arquitectura para sistemas de objetos distribuidos desarrollada por la OMG. Comprende las especificaciones de un software intermedio orientando a objetos diseado para ofrecer portabilidad e interoperabilidad dentro de una red de sistemas heterogneos. La OMG es la misma asociacin que desarroll UML.

3.2.1. Terminologa bsica

A continuacin veremos algunos conceptos importantes para la descripcin de CORBA: 1) Interfaz Sabemos que en el software orientado a objetos, y como consecuencia de su encapsulacin, los objetos se comunican por medio de mensajes en los que se

Editorial UOC

270

Ingeniera del software

piden operaciones y valores de atributos estos dos elementos son pblicos o, como mucho, protegidos y que, por ello, se distingue entre una clase y la interfaz o interfaces que implementa. Sin embargo, en el caso de software no distribuido, el objeto cliente y el objeto servidor estn en el mismo proceso y, por lo tanto, la interfaz y la clase que la implementa tambin; en el caso de software distribuido, el cliente y el servidor pueden estar en diferentes procesos e, incluso, en mquinas diferentes, y por lo tanto, en el proceso del cliente no encontramos la clase del servidor, sino slo su interfaz. Est claro que contina habiendo una clase que implementa la interfaz, pero esta clase no es visible desde el cliente (slo su interfaz, como ya hemos dicho). De este modo, el software intermedio y por lo tanto CORBA slo considera las interfaces, ya que el concepto de clase no se necesita para la comunicacin entre objetos clientes y objetos servidores; este concepto tampoco es necesario para la implementacin, ya que son los objetos y no las clases los que implementan las interfaces, porque cualquier operacin se pide a un objeto concreto. Adems de las interfaces de los objetos de la aplicacin, que son propias de cada aplicacin, hay interfaces estndar, cuya definicin forma parte de las especificaciones de CORBA. Estas interfaces se utilizan en las comunicaciones entre la aplicacin y los componentes de CORBA, as como entre estos componentes.
Las interfaces en CORBA y en UML El concepto de interfaz en CORBA es muy parecido al de UML (lo cual es lgico, ya que la misma organizacin los ha especificado a ambos; sin embargo, CORBA no hace referencias a UML). Como diferencias un poco significativas, encontramos que las interfaces de UML no incluyen atributos y las de CORBA s (pero esta diferencia no tiene ninguna repercusin efectiva, ya que un atributo puede ser sustituido por dos operaciones, una que le pone el valor y otra que lo lee), y que en CORBA no hay operaciones ni atributos de clase.

Entre interfaces se produce herencia: las denominadas interfaces derivadas heredan de las respectivas interfaces bsicas. Puede darse el caso de interfaces abstractas, parecidas a las clases abstractas en el sentido de que no tienen atributos

Editorial UOC

271

Captulo VII. Introduccin al software ...

porque no puede haber objetos que las satisfagan directamente, sino slo mediante interfaces derivadas de ellas.
Herencia mltiple entre las interfaces Puede darse herencia mltiple por lo menos, la hay entre las interfaces estndar mencionadas pero es estrictamente aditiva (es decir, no hay coincidencia de nombres entre las operaciones o atributos que se heredan de interfaces bsicas diferentes). En las interfaces estndar se dan algunos casos de polimorfismo; en estos casos, operaciones del mismo nombre se comportan en el caso de la interfaz derivada de forma diferente que en el caso de la interfaz bsica.

2) Objeto Dentro de este modelo, un objeto es una entidad que proporciona servicios (operaciones) a las entidades que se los pidan (los clientes). Los objetos tienen identidad, interfaz e implementacin. 3) Referencia a un objeto Una referencia a objeto es algo que identifica el mismo objeto cada vez que se utiliza; un objeto puede tener varias referencias diferentes. El formato y el valor de las referencias a objetos pueden depender del ORB.
La unidad de las referencias No es obligado que no pueda haber nunca dos objetos con la misma referencia, pero s que lo es que no pueda haberlos dentro de un mbito espacial y temporal suficientemente amplio como para que los conflictos sean prcticamente imposibles.

4) Tipo de objeto Un tipo de objeto es un tipo cuyos miembros son referencias a objetos. Un tipo de objeto corresponde a una interfaz, en el sentido de que los objetos correspondientes a las referencias de un tipo satisfacen la interfaz correspondiente. 5) Peticin (request) La peticin es el mensaje de un objeto cliente a un objeto servidor para solicitar la ejecucin de un mtodo de este ltimo objeto. Una peticin comprende la identificacin del objeto que la debe hacer, una operacin, cero o ms argu-

Editorial UOC

272

Ingeniera del software

mentos que correspondan a los parmetros de la operacin definidos en la interfaz utilizada y, eventualmente, un contexto. Los parmetros de las operaciones son esencialmente como los de las operaciones en UML; se identifican por posicin y cada uno tiene un modo (in, out o inout) y un tipo. El resultado, si lo hay, es un parmetro out especial. La invocacin de una peticin se puede dar de las dos formas siguientes: Esttica, y entonces la interfaz que se utiliza queda determinada en tiempo de compilacin. Dinmica, y entonces la interfaz no se determina hasta el tiempo de ejecucin (si bien la interfaz se debe haber compilado antes). 6) Operacin y mtodo Dentro de una peticin se invoca una operacin de una interfaz, pero lo que se ejecuta realmente es un mtodo que forma parte de la implementacin del objeto servidor al que est dirigida la operacin. 7) Object Request Broker (ORB) Teniendo en cuenta que CORBA es una arquitectura de objetos distribuida con software intermedio, es lgico que su ncleo sea un componente responsable de la distribucin de mensajes entre objetos; este componente se denomina Object Request Broker (ORB); el ORB es responsable de encontrar el objeto servidor dentro de la red, de prepararlo para recibir la demanda, de transmitirlo y de hacer llegar al cliente los datos devueltos como resultado de la peticin o su respuesta. La actividad del ORB hace que el objeto cliente slo tenga que conocer la interfaz y el valor de una referencia que lo identifique entre los dems para invocar una peticin sobre un objeto servidor, pero no el lugar ni el lenguaje en que est programado.

3.2.2. Arquitectura de CORBA

La siguiente figura representa la arquitectura de CORBA:

Editorial UOC

273

Captulo VII. Introduccin al software ...

3.2.3. Descripcin de los componentes de la arquitectura

A continuacin, haremos una descripcin de los componentes de la arquitectura que estamos considerando: Aplicaciones del cliente: por medio de CORBA, los clientes efectan peticiones con las que solicitan operaciones sobre objetos de los servidores me-

Editorial UOC

274

Ingeniera del software

diante invocacin esttica o dinmica. Con las dos formas de invocacin se pueden hacer las mismas demandas, y el servidor no puede saber si se ha utilizado una u otra. Stub: debe haber uno para cada interfaz utilizada; establece la correspondencia entre las operaciones definidas en la interfaz y las rutinas que dependen del lenguaje de programacin que llama la aplicacin del cliente cuando hace una peticin. Se genera a partir de la interfaz descrita en IDL, y se enlaza con la aplicacin. Los lenguajes de programacin orientados a objetos no necesitan stubs. ORB al cliente: como hemos visto, el ORB asla el objeto servidor y acta como intermediario para las demandas, de forma que no es necesario que el cliente y el servidor tengan informacin uno del otro. El ORB al cliente se enlaza con la aplicacin y verifica los argumentos de la demanda, los compara con los parmetros de la interfaz y enva la peticin al servidor. Dentro de una arquitectura CORBA puede haber ms de un ORB al mismo tiempo, con estilos de invocacin diferentes y referencias a los objetos con una estructura diferente tambin; entonces, cada ORB debe saber encontrar su implementacin de un objeto solicitado por un cliente sin que ste se lo tenga que indicar. Depsito de interfaces: contiene las interfaces, as como las constantes y definiciones de tipo que se utilizan. ORB al servidor: recibe las peticiones de ejecucin de mdulos, da formato a los argumentos e invoca la ejecucin del mtodo a partir del esqueleto. Se enlaza con la aplicacin del servidor. Portable Object Adapter (POA): los adaptadores de objetos llevan a cabo tareas generales relativas a la implementacin de los objetos; por ejemplo, activar los objetos y sus implementaciones a partir de referenciarlos, desactivarlos, registrar las implementaciones disponibles en los servidores diferentes, generar los identificadores de los objetos (si no se encarga de ello la aplicacin) e interpretar las referencias a estos objetos mediante estos identificadores. Para conseguir todas estas tareas, se aplican varias opciones, que son las denominadas polticas del adaptador. Los adaptadores de objetos se enlazan con la aplicacin. En un momento determinado puede haber varios POA que formen una jerarqua para un ORB, cada uno de los cuales gestiona un grupo de objetos; de stos, el POA raz se pone en funcionamiento auto-

Editorial UOC

275

Captulo VII. Introduccin al software ...

mticamente, y los dems lo hacen segn la jerarqua por medio del activador del adaptador.
Adaptador de objeto en CORBA Las primeras versiones de CORBA especificaban otro adaptador de objetos en lugar del POA: el BOA (Basic Object Adapter).

Aplicaciones al servidor : incluyen una implementacin o ms de los objetos y de sus mtodos y, obviamente, tambin el cdigo para el inicio y la finalizacin de la misma aplicacin. Mtodos: cada mtodo es el cdigo, contenido en la implementacin de un objeto, que implementa una determinada operacin de una interfaz. El conjunto de las implementaciones de las operaciones de una interfaz y, por lo tanto, el conjunto de los mtodos correspondientes se denomina sirviente (en ingls, servent). Para una misma interfaz puede haber varios sirvientes y, por lo tanto, una operacin de una interfaz puede ser implementada por varios mtodos. La implementacin de los objetos debe ser independiente del ORB. Esqueletos : son correspondencias, dependientes del lenguaje de programacin y del ORB, que se establecen entre las definiciones de operaciones de IDL y los mtodos correspondientes y las implementaciones que los contienen; incluyen la programacin necesaria para lanzar los mtodos imprescindible para una peticin. Se generan en forma fuente a partir de la definicin de la interfaz respectiva, se compilan y se enlazan con la aplicacin del servidor. Los utilizan los adaptadores de objetos. Adems de los esqueletos que establecen relaciones permanentes entre operaciones y mtodos, o esqueletos especficos del tipo, tambin puede haber esqueletos dinmicos, que acceden en tiempo de ejecucin al cdigo de la operacin y a sus parmetros. Servicios de objetos y servicios comunes: se describen aparte. Depsito de implementaciones: contiene informacin que permite al ORB localizar y activar las implementaciones de un objeto al que se ha hecho referencia, y encuentra las interfaces pedidas dentro del depsito de interfaces.

Editorial UOC

276

Ingeniera del software

3.2.4. El procesamiento de las demandas: visin resumida El procesamiento de las peticiones tiene las siguientes fases: 1) El cliente invoca la peticin. 2) Cuando llega al ORB, la demanda incluye una referencia al objeto que es su destinatario. El ORB, utilizando el depsito de implementaciones, localiza el proceso del servidor o lo pone en funcionamiento si es necesario. 3) El ORB localiza el POA correspondiente al objeto destinatario de la demanda, o bien pide su creacin al activador del adaptador; si no lo consigue, el cliente recibir la excepcin object_not_exist. 4) El POA localiza o activa el sirviente del objeto de formas distintas segn las polticas vigentes. Una vez que el sirviente est activo, el POA selecciona dentro de ste el mtodo correspondiente a la operacin invocada dentro de la peticin. 5) Se localiza el esqueleto. 6) Se hace la gestin de las respuestas y las excepciones.

3.2.5. IDL Las interfaces utilizadas dentro del entorno de CORBA se definen mediante la Interface Definition Language (IDL).
Otros lenguajes IDL En el mismo seno de la tecnologa de sistemas distribuidos se encuentran otros lenguajes que tambin se denominan IDL.

IDL no es un lenguaje de programacin, y no est pensado para que se pueda generar cdigo objeto o ejecutable a partir de s mismo; sin embargo, las implementaciones de CORBA acostumbran a poder generar cdigo fuente principalmente en C++, pero tambin en lenguajes como por ejemplo COBOL, Smalltalk y Java a partir de IDL. La compilacin de una interfaz definida con este lenguaje genera tres salidas: un stub;

Editorial UOC

277

Captulo VII. Introduccin al software ...

un esqueleto; un fichero de cabecera, que contiene definiciones de tipos de datos como estructuras y constantes, y se incluye dentro de las aplicaciones de los clientes y de los servidores. Adems, la interfaz compilada queda depositada en el denominado depsito de interfaces. La gramtica de IDL es un subconjunto de la norma que se ha propuesto sobre C++ ANSI, ampliado para soportar el mecanismo de invocacin de peticiones. IDL es un lenguaje declarativo y contiene la sintaxis de C++ para la declaracin de constantes, tipos y operaciones (si bien en algunos aspectos la sintaxis de IDL es ms restrictiva).
Las especificaciones de IDL

Una especificacin de IDL es un fichero fuente, que puede contener definiciones de mdulos, interfaces, tipos de valores, constantes y excepciones.
Los tipos de valores... ... son tipos con posibilidad de herencia, cuyos valores no tienen identidad.

Los mdulos agrupan definiciones de interfaces y sirven principalmente para definir mbitos de validez de los nombres dentro de una especificacin; en general, las referencias a nombres de elementos definidos dentro de un mdulo deben llevar como prefijo el nombre del mdulo. Hay un mdulo especial, CORBA, que rene todos aquellos nombres que forman parte de las especificaciones de CORBA.

3.2.6. Conexin de una aplicacin en el entorno CORBA

Para que una aplicacin pueda entrar en el entorno de CORBA, antes es necesario hacer lo siguiente: Inicializarla dentro del entorno de un ORB o ms primero y despus tal vez tambin dentro del respectivo entorno del adaptador de objetos.

Editorial UOC

278

Ingeniera del software

Obtener referencias al pseudoproyecto del ORB y, eventualmente, tambin a otros objetos como el POA raz, el POA Current, el depsito de interfaces y algunos servicios de objetos, para posteriormente pedirles operaciones.

3.2.7. Las invocaciones dinmicas

Las invocaciones dinmicas son invocaciones de peticiones en las que la peticin se crea en tiempo de ejecucin, a diferencia de las invocaciones estticas, en las que la peticin queda determinada en tiempo de compilacin. En la invocacin dinmica de peticiones se pueden utilizar dos modos de comunicacin: sncrono y sncrono diferido. Una invocacin dinmica gestionada por CORBA tiene tpicamente los siguientes pasos: 1) Obtencin de la informacin sobre la interfaz del objeto. 2) Creacin de la estructura de datos que se pasar al objeto. 3) Creacin de una peticin para el objeto. 4) Invocacin de la peticin.

3.2.8. La interfaz de esqueletos dinmicos (DSI)

Cuando se utilizan esqueletos dinmicos, a diferencia de los especficos de un tipo, el nombre de la operacin e incluso el tipo del objeto, no se conocen hasta la ejecucin. En cierto modo, se trata de un caso simtrico, por parte del servidor, de lo que es la invocacin dinmica por parte del cliente; del mismo modo que un servidor no sabe si el cliente ha utilizado invocacin esttica o dinmica, un cliente no sabe si el servidor utiliza un esqueleto especfico del tipo o dinmico. Junto con la invocacin dinmica, los esqueletos dinmicos son una forma de conseguir puentes genricos entre ORB. Otras utilidades de los esqueletos dinmicos son las herramientas interactivas de desarrollo del software basadas en intrpretes, las herramientas de prueba

Editorial UOC

279

Captulo VII. Introduccin al software ...

y los monitores que se interponen dinmicamente entre los objetos, y los lenguajes de tipificacin dinmica, como por ejemplo LISP. Para todas las peticiones a un mismo objeto se utiliza la misma rutina, denominada rutina de implementacin dinmica (DIR); para un mismo lenguaje de programacin, todas las llamadas a la DIR tienen los mismos argumentos.
DIR es la sigla de la expresin inglesa correspondiente a rutina de implementacin dinmica.

3.2.9. Los servicios de objetos

Caractersticas comunes

A pesar de no formar parte del entorno CORBA en sentido estricto, la forma en que se utilizan los objetos en las especificaciones de los servicios de objetos respeta muchos de sus principios: Se utilizan interfaces para tipificar los objetos. Hay una separacin clara entre la interfaz y la implementacin; los clientes slo ven las interfaces, pero no sus implementaciones. Se utiliza la herencia incluso mltiple entre interfaces para extender y especializar la funcionalidad, y permitir su evolucin. Adems, el diseo de los servicios de objetos respeta, en lneas generales, los siguientes principios: Son servicios genricos, en el sentido de que son independientes del tipo del cliente y tambin en general del tipo de datos pasados en las peticiones. Generalmente, estn implementados en forma de objetos de CORBA que se pueden activar local o remotamente. Con frecuencia, las interfaces permiten implementaciones con diferentes calidades de servicio. Muchos servicios tienen interfaces diferentes para tipos de clientes diferentes. Los servicios utilizan con frecuencia interfaces callback; es decir, hacen peticiones al cliente mediante interfaces que ste debe soportar. De este mo-

Editorial UOC

280

Ingeniera del software

do, tambin se aprovechan las ventajas de las interfaces en las llamadas al cliente. Las excepciones slo sirven para comunicar situaciones anmalas. Los cdigos de retorno normales se pasan al cliente por medio de parmetros de salida. Generalmente, hay operaciones distintas en lugar de varias modalidades de una operacin diferenciadas, por ejemplo, por un parmetro de indicadores.
El servicio de nombres

El servicio de nombres gestiona estructuras de nombres de objetos que sirven para localizarlos desde otros objetos. Un objeto puede tener varios nombres. Una asociacin entre un objeto y su nombre es un name binding. Un contexto de nombres (en ingls, naming context) es un espacio de nombres en el que los nombres de los objetos no se pueden repetir. Un contexto de nombres, que es un objeto, tiene nombre dentro de otro contexto de nombres, y de este modo se pueden constituir jerarquas eventualmente distribuidas de nombres que dan lugar a nombres compuestos, constituidos por una secuencia de los mismos, en la que todos excepto el ltimo (el nombre simple) pertenecen a contextos de nombres. Un componente consta de un atributo identificador y un atributo de clase (en ingls, kind attribute), que hace una tipificacin de los nombres; esta tipificacin no tiene valor sintctico para permitir nombres vinculados a los lenguajes de programacin o idiomas concretos.
El servicio de acontecimientos

Por lo que respecta a CORBA, un acontecimiento es un hecho que guarda relacin con un objeto y tiene inters para otros objetos, a los que se hace accesible mediante un mensaje denominado notificacin. La notificacin no la hace el objeto que no tiene por qu saber que hay objetos interesados en saber que se ha producido el acontecimiento, sino el servicio de acontecimientos. Este servicio distingue dos tipos de objetos: suministradores (en ingls, suppliers), que generan acontecimientos, y consumidores, que los procesan. Adems, puede haber un tercer tipo de objetos: los canales de acontecimientos, que

Editorial UOC

281

Captulo VII. Introduccin al software ...

son consumidores y suministradores al mismo tiempo, y permiten que varios suministradores se comuniquen con diversos suministradores sin que se conozcan entre s. Los acontecimientos con tipo (en ingls, typed events) posibilitan que las aplicaciones describan el contenido de los acontecimientos por medio de IDL, con parmetros slo de entrada y sin retorno. En este caso, puede haber dos canales de acontecimientos en serie, uno de los cuales puede filtrar los acontecimientos para el otro basndose en el tipo. Para la notificacin hay dos mecanismos: 1) Push, en el que el suministrador toma la iniciativa de transmitir informacin sobre el acontecimiento a los consumidores, ya sea directamente o mediante un canal de acontecimientos; el consumidor se puede suscribir a los acontecimientos de un tipo determinado y tambin puede decidir dejar de recibir acontecimientos. 2) Pull, en el que el consumidor que pide la informacin sobre el acontecimiento al suministrador, ya sea directamente o mediante un canal de acontecimientos; el consumidor puede preguntar peridicamente por los acontecimientos, mientras que el suministrador puede registrar el identificador del consumidor y ofrecer sus servicios; tambin puede dejar de aceptar demandas sobre acontecimientos. Cuando la notificacin tiene lugar mediante un canal de acontecimientos, tambin puede ser mixta: push entre consumidor y canal y pull entre canal y suministrador, o al revs. Los consumidores y suministradores se deben haber puesto de acuerdo en lo que respecta a la semntica de los acontecimientos, pero el canal de acontecimientos no la conoce.
El servicio de notificaciones

Es una extensin del servicio de acontecimientos con las funciones adicionales siguientes: La transmisin de acontecimientos con estructuras de datos complejas llamados acontecimientos estructurados.

Editorial UOC

282

Ingeniera del software

La posibilidad de aadir filtros a los proxies para que los clientes puedan especificar qu acontecimientos quieren recibir. La posibilidad que los suministradores de un canal sepan qu tipo de acontecimiento quieren recibir los consumidores de este canal. La posibilidad que los consumidores de un canal sepan qu tipos de acontecimiento ofrecen los suministradores de este canal para que los puedan pedir. La posibilidad que haya diferentes calidades de servicio a nivel de canal, proxy y acontecimiento. Un depsito opcional de tipos de acontecimientos que permita que los usuarios creen filtros de acontecimientos en un lenguaje que se especifica. Los acontecimientos estructurados se definen por dominios (finanzas, por ejemplo), en el sentido que cada dominio puede tener definidos sus tipos de acontecimientos y que los nombres de estos tipos se pueden repetir en dominios diferentes. Cada acontecimiento que se produce puede tener un nombre que no tiene significado para el servicio sino slo para el usuario. Los filtros son objetos que sirven para seleccionar los acontecimientos por medio de restricciones expresadas o bien en un lenguaje estndar o bien en uno propio del implementador.
El servicio de relaciones

El servicio de relaciones permite crear relaciones, permanentes y temporales, entre dos objetos o ms, sin modificarlos y sin que stos lo sepan. El concepto de relacin en este servicio es similar al de asociacin en UML. Hay tres niveles de servicio: 1) El nivel de base define relaciones y papeles. 2) El nivel de grafos considera grafos de objetos relacionados (es decir, conectados por relaciones); en este nivel se definen objetos nodos y objetos de recorrido de un grafo, que permiten recorrer un grafo sin activar sus objetos. 3) El tercer nivel considera dos tipos especficos de relaciones: por contenido y por referencia.

Editorial UOC

283

Captulo VII. Introduccin al software ...

El servicio de ciclo de vida

El servicio de ciclo de vida proporciona operaciones para crear, copiar, mover y borrar objetos de forma local o remota; adems, soporta asociaciones entre grupos de objetos (ya sean por contenido o por referencia) y condiciones de integridad referencial entre objetos. Para crear un objeto es necesario que el cliente encuentre un objeto factora es decir, un objeto que sabe cmo se crea un objeto de la clase correspondiente, que emita una peticin de creacin y que obtenga el identificador del objeto creado. El objeto factora debe asignar los recursos necesarios, obtener el identificador del objeto y registrar el nuevo objeto mediante el adaptador de objetos y el depsito de implementaciones. Tambin se puede crear un objeto copindolo.
El servicio de propiedades

El servicio de propiedades sirve para definir atributos de los objetos dinmicamente, en contraste con las interfaces de IDL, que lo hacen estticamente. Los atributos dinmicos o propiedades tienen un nombre, un tipo y un valor que se puede leer y modificar, as como un modo de propiedad, que puede tomar estos valores: normal , es decir, sin restricciones; read-only, que slo deja leer y borrar; fixed-normal , que deja modificar pero no borrar; fixed-readonly, que slo deja leer.
El servicio de tiempo

El servicio de tiempo se utiliza para obtener la hora, confirmar el orden en que se han producido diferentes acontecimientos, generar acontecimientos relativos al tiempo y calcular el tiempo transcurrido entre dos acontecimientos.
La representacin de tiempo UTC El servicio de tiempo utiliza la representacin del tiempo denominada Universal Time Coordinated (UTC), definida dentro de la especificacin X/ Open DCE Time Service, en la que la unidad son cien nanosegundos y la base son las cero horas (hora de Greenwich) del 15.10.82.

Editorial UOC

284

Ingeniera del software

El servicio de tiempo integra dos servicios: El servicio bsico de la hora (en ingls, Basic Time Service): comprende operaciones para obtener y manipular la hora. El servicio de acontecimientos de temporizacin (en ingls, Timer Event Service): proporciona operaciones para implementar gestores de acontecimientos disparados por tiempo y gestionar los acontecimientos que generan.
El servicio de externalizacin

Externalizar un objeto quiere decir convertirlo en un objeto stream, e internalizarlo quiere decir hacer lo contrario; el servicio de externalizacin sirve para las dos cosas. Un objeto stream es un rea de datos con un cursor, que est en memoria o en disco o se enva a la red. La externalizacin sirve para facilitar la exportacin/importacin de un objeto de un proceso, ordenador u ORB a otro (o al mismo proceso), en el que se har una internalizacin para crear un nuevo objeto.
El servicio de estados persistentes

Su funcin es guardar el estado de un objeto en memoria permanente y recuperarlo. Para el cliente del objeto es transparente el hecho que este est en memoria o que haya de ser recuperado del almacenamiento permanente. El sistema de almacenamiento tiene estos componentes: Los objetos de almacenamiento: es la forma en qu este servicio presenta la informacin persistente. Cada objeto de almacenamiento tiene un tipo, al cual hay asociados atributos de estado y operaciones de estado; entre estos tipos puede haber herencia. Los almacenes de datos (datastores): son las implementaciones que almacenan la informacin persistente de un objeto como una base de datos o un conjunto de ficheros. Un almacn de datos se compone de storage homes, cada uno de los cuales almacena objetos de almacenamiento de un solo tipo; cada storage home tiene un tipo, que consta del tipo de objetos de almacenamiento que puede contener y de operaciones y claves. Hay una jerarqua de tipos de storage homes

Editorial UOC

285

Captulo VII. Introduccin al software ...

paralela a la de los tipos de los objetos de almacenamiento respectivos; un (tipo de) storage home y todos los que se deriven constituye una familia de storage homes. En un almacn de datos cada storage home gestiona no solamente sus objetos de almacenamiento sino los de todos los tipos de la familia que encabeza. Cada objeto de almacenamiento tiene un identificador no repetido en su storage home (short-pid) y un identificador global (pid), no repetido en del catlogo (ver el apartado siguiente). Una clave es una lista de miembros de estado de un tipo de objetos de almacenamiento que constituye un identificador no repetido de los objetos de este tipo; un storage home puede tener cualquier nmero de claves. Los catlogos gestionan storage homes, los cuales a su vez gestionan objetos de almacenamiento. Hay dos clases de catlogos: session pools, sesiones, que son conexiones lgicas entre un proceso y un almacn de datos o ms; se puede controlar por programa la asignacin de las sesiones y su asociacin a transacciones. Las sesiones pueden ser transaccionales o no; las transaccionales estn asociadas a recursos, que son transacciones de almacn de datos. Los conectores son objetos locales que crean los catlogos. Estn registrados en un registro de conectores nico por ORB que soporta la interfaz ConectorRegistry. La especificacin del almacenamiento se puede hacer de dos maneras: mediante un lenguaje especial llamado PSDL (Persistente State Definition Language ), que es una extensin de IDL; mediante traducciones estndar a Java o C++ de las instrucciones de PSDL ( persistencia transparente).
El servicio de control de la concurrencia

La finalidad del servicio del control de la concurrencia es arbitrar los accesos concurrentes a un objeto con la intencin de garantizar su integridad. Propor-

Editorial UOC

286

Ingeniera del software

ciona interfaces para que los clientes puedan reservar y liberar recursos para coordinarse en su uso compartido. Este servicio puede funcionar en dos modos: Transaccional, es decir, en representacin de una transaccin; entonces, el servicio de transacciones se encarga de la liberacin de los recursos reservados cuando la transaccin acaba, ya sea de forma normal o anormal. No transaccional; es decir, en representacin del hilo que se ejecuta en cada momento, que no tiene por qu ser una restriccin; entonces, el mismo servicio de control de la concurrencia es el que se encarga de llevar a cabo las liberaciones cuando es necesario. Est diseado para funcionar en combinacin con el servicio de transacciones de objetos y puede soportar transacciones encajadas. No se define qu es un recurso; es responsabilidad de los clientes de este servicio tanto definir los recursos como identificar sus usos potencialmente conflictivos; en el caso ms tpico, los recursos son objetos. Es posible que haya recursos de varios niveles o granularidades; es decir, recursos que contienen otros recursos. Sin embargo, el servicio no ve estas jerarquas. Se puede optar por definir pocos recursos de alto nivel o muchos de bajo nivel; en el primer caso es preciso hacer menos reservas, pero los conflictos sern ms frecuentes.
Equivale a reservar ficheros enteros en lugar de registros individuales.

Tampoco se define qu es cada transaccin; esto lo hace el servicio de transacciones. Se considera que en los clientes transaccionales cada transaccin tiene un solo hilo, y que una transaccin no se ejecuta para ms de un hilo al mismo tiempo.
Un solo hilo por transaccin no impide el paralelismo, ya que hay soporte para transacciones encajadas (consultad el servicio de transacciones ms adelante).

Una reserva (lock) es la capacidad de un cliente concreto de acceder a un recurso determinado de un cierto modo; una reserva corresponde, por lo tanto, a un cliente y un recurso. Un cliente debe conseguir una reserva sobre un recurso

Editorial UOC

287

Captulo VII. Introduccin al software ...

antes de acceder a l; dado que existen reservas de distintos modos, el cliente debe pedir la reserva de una forma que le permita llevar a cabo las actividades previstas sobre el recurso. El arbitraje mencionado en la definicin del servicio consiste en evitar que varios clientes tengan al mismo tiempo reservas del mismo recurso si las actividades de estos clientes pudieran entrar en conflicto. El servicio conceder una reserva a un cliente slo si ningn otro tiene un reserva de un modo incompatible con el de la reserva que se pide ahora. Otro aspecto es el de la liberacin de recursos reservados (en ingls, unlocking ). Si se piden reservas en una transaccin, el servicio de transacciones libera los recursos cuando sta acaba; si se piden reservas fuera de transacciones, el cliente debe liberar explcitamente los recursos reservados. Con frecuencia, las reservas se mantienen hasta el final de la transaccin, pero en el caso de que una transaccin no modifique el recurso, lo puede liberar cuando ya sabe que no lo necesitar ms.
Locksets

Cada lockset es un conjunto de reservas sobre un mismo recurso; los clientes deben asignar un lockset a cada recurso. Tambin encontramos unos coordinadores de reservas, cada uno de los cuales puede gestionar locksets sobre recursos de un mismo tipo que deban ser liberados cuando se acaba una misma transaccin. La creacin de locksets y la liberacin de recursos cuando una transaccin se confirma o se aborta es responsabilidad del cliente.
El servicio de transacciones

Las transacciones son unidades de proceso que o bien llegan a acabar normalmente, o bien, en el caso de que se vean abortadas, las actualizaciones en bases de datos que hubiesen hecho se anulan, como si no hubiesen empezado. El servicio de transacciones tiene las siguientes funciones: Controlar el alcance y la duracin de las transacciones. Permitir que participen varios objetos en una sola transaccin. Permitir que estos objetos asocien sus cambios de estado a una transaccin. Coordinar el trmino de las transacciones.

Editorial UOC

288

Ingeniera del software

El servicio de transacciones soporta dos modelos de transaccin: Transacciones encajadas de cualquier nmero de niveles. Una subtransaccin puede confirmar o anular (a peticin de cualquiera de los objetos que participen en la misma), sin que necesariamente lo hagan las subtransacciones que la contienen, pero su confirmacin no ser definitiva mientras la transaccin no confirme. Una transaccin slo puede confirmar cuando lo hayan hecho todas sus subtransacciones; adems, cuando la transaccin es anulada, tambin lo son todas sus subtransacciones. Transacciones planas segn el modelo DPT de X/Open, que no pueden tener subtransacciones.
El servicio de seguridad

El servicio de seguridad tiene estos aspectos: Confidencialidad: que slo tengan acceso a la informacin los usuarios autorizados. Integridad: que la informacin slo pueda ser modificada por los usuarios autorizados y de la forma autorizada. Responsabilidad: que los usuarios sean responsables de sus acciones en relacin con la seguridad. Disponibilidad: que el acceso al sistema no se pueda negar injustificadamente a los usuarios. Las funciones de este servicio son las siguientes: Identificacin: pedir al principal (el principal es una persona u objeto titular de una autorizacin de acceso) que diga quin es. Autenticacin: comprobar que el principal es quien dice que es. Autorizacin de los principales. Control de acceso: determinar si se debe permitir el acceso de un principal (previamente identificado y autenticado) a un objeto a partir de los atributos de uno y otro. Auditora de seguridad: determinar a los principales responsables de las acciones en materia de seguridad e identificarlos incluso mediante una cadena de peticiones. Seguridad de la comunicacin entre objetos, que requiere la autenticacin mutua de cliente y servidor.

Editorial UOC

289

Captulo VII. Introduccin al software ...

No-repudiacin: suministrar pruebas irrefutables del origen de los datos y de su recibimiento por el destinatario. Gestin de las polticas de seguridad. El servicio tiene estos niveles de funcionalidad: 1) El nivel 1, que proporciona servicios de seguridad a aplicaciones que no tienen conocimiento de ello y a aplicaciones que tienen unas necesidades reducidas de control y auditora de la seguridad; comprende la seguridad de las invocaciones, la proteccin de los mensajes, algunas posibilidades de delegacin, control y auditora. 2) El nivel 2, que permite a las aplicaciones controlar la seguridad en las invocaciones de objetos y soporta una gestin de seguridad porttil. 3) La funcionalidad opcional, de la cual las especificaciones actuales slo incluyen la no-repudiacin.
El servicio de colecciones

Las colecciones son tipos diferentes de agrupaciones de objetos (elementos). Tpicamente, los elementos de una coleccin o bien son del mismo tipo o bien tienen una misma interfaz. Los diferentes tipos de colecciones difieren en lo que respecta a la existencia de una ordenacin de los objetos, la existencia de acceso a los objetos por clave, la existencia de un criterio de igualdad de los objetos y sobre si puede haber o no varios objetos con el mismo valor de la clave; diferentes combinaciones de estas restricciones dan lugar a tipos distintos de colecciones; a cada tipo de coleccin le corresponde una interfaz, y todas ellas constituyen una jerarqua de derivacin en la que los niveles, a excepcin del ms bajo, son interfaces abstractas. Para recorrer los objetos de las colecciones, existen unos cursores denominados iteradores; hay un tipo diferente de ellos para cada interfaz abstracta de colecciones.
El servicio de consultas

Las consultas no se limitan slo a accesos de lectura como podra parecer, sino que son instrucciones declarativas con predicados, que pueden comprender valores de atributos e invocaciones y otros servicios de objetos.

Editorial UOC

290

Ingeniera del software

El resultado de una consulta puede ser una coleccin obtenida por medio de la seleccin de aquellos objetos de una coleccin fuente (que tambin podra ser el resultado de una consulta anterior) que cumplen un predicado dado o bien puede provenir de un evaluador de consultas a partir de un predicado que se evaluara por encima de una coleccin virtual. El servicio de consultas puede coordinar varios evaluadores encajados y federados. Los objetos pueden participar en el servicio de dos formas: 1) A ttulo individual; entonces el evaluador de consultas se encarga de evaluar el predicado de la consulta y de llevar a cabo todas las operaciones de la consulta por medio de operaciones definidas en la interfaz correspondiente a los objetos. ste es el mecanismo ms general, pero tambin el menos optimizado. En este caso, los objetos afectados constituiran una coleccin virtual de las que hemos hablado. 2) Como elementos de una coleccin, que soporta una interfaz para consultas; el evaluador le pasa el predicado y esta interfaz lo evala, hace las operaciones sobre los objetos individuales, combina los resultados y transmite el resultado definitivo al objeto que lo haba invocado. Este mecanismo permite que los evaluadores apliquen sus instrumentos de optimizacin. La especificacin del servicio de consultas no define mecanismos de evaluacin, indexacin ni optimizacin, pero s prev lenguajes de consulta concretos, que son los siguientes: SQL-92 Query y sus sucesores. OQL-93 y OQL-93 Basic, del ODMG, y sus sucesores. Algunas caractersticas destacadas del servicio de consultas son las siguientes: Proporciona operaciones para seleccionar, insertar, actualizar y borrar elementos dentro de colecciones. Los elementos afectados pueden ser objetos persistentes o transitorios, locales o remotos.

Editorial UOC

291

Captulo VII. Introduccin al software ...

En los predicados se pueden utilizar atributos, herencia y navegacin mediante relaciones, todo por medio de las interfaces de los objetos elementos.
El servicio de licencias

En el mundo de los objetos distribuidos podemos encontrar objetos de pago; entonces conviene que sea posible medir el uso de los objetos con vistas a una posterior facturacin. El servicio de licencias da apoyo a esta funcin. Se consideran los siguientes tipos de licencias: con periodo de gracia, con listas de usuarios, con licencias reservadas siempre disponibles y con licencias multiuso. Desde otro punto de vista, licencias para una mquina, licencias en el mbito de instalacin y licencias flotantes para un nmero mximo de usuarios concurrentes. El servicio de licencias debe cumplir unas caractersticas necesarias para optimizar su rendimiento: Posibilidad de crecimiento. Medidas para evitar que queden licencias asignadas indefinidamente a una aplicacin. Garanta de que slo se utilicen las licencias compradas. Prevencin de clientes y servidores impostores. Un productor (en ingls, producer) es una empresa o persona que tiene la propiedad intelectual cuyo uso se quiere controlar. Un cliente del productor (en ingls, producer client) es cualquier objeto cuyo uso de una licencia debe ser controlado. Una poltica del productor (en ingls, producer policy) es un conjunto de datos que describe los trminos y las condiciones detalladas que rigen el control del uso de una licencia. Un documento de licencia proporciona un medio para especificar las limitaciones en el uso de la licencia: nmero de ejemplares de la propiedad intelectual, limitaciones temporales, etc.
El servicio del intermediario de objetos (Object Trader)

Un objeto que presta unos servicios determinados (exportador) pide ser registrado y, por ello, para cada servicio comunica la oferta de servicio, que con-

Editorial UOC

292

Ingeniera del software

tiene el nmero del tipo de servicio, una referencia a la interfaz que proporciona el servicio y los valores de las propiedades del servicio.
Entonces se dice que el objeto exporta estos servicios.

La informacin sobre cada tipo de servicio con el que trata un objeto intermediario determinado comprende un tipo de interfaz y, opcionalmente, un tipo de propiedad o ms. Un tipo de servicio puede ser subtipo de otro. Se retorna un identificador de la oferta al exportador, que le permite modificarla o retirarla posteriormente. Los clientes (importadores) pueden obtener una lista de servicios disponibles (importarlos), en general, o bien del tipo de las pginas amarillas. Por ello se debe indicar el tipo de servicio deseado, y una restriccin especificada en el lenguaje de restricciones (en ingls, standard constraid language), cuyos elementos principales son: tipos de valores de propiedades, operadores y literales. El intermediario busca el servicio que mejor se ajusta a lo que pide el cliente, pero es ste quien interacta directamente con el proveedor que elige: utiliza el tipo de servicio, la restriccin especificada y las preferencias que deben servir para establecer un orden de presentacin al importador de las ofertas seleccionadas. Unas polticas permiten identificar el conjunto de ofertas de servicios dentro del cual se debe efectuar la bsqueda. Las polticas tienen un nombre y un valor. Se pueden crear federaciones de objetos intermediarios y, por lo tanto, de los dominios de tipos de servicio o particiones, en cuyo mbito se propagan las consultas entre intemediarios.

3.2.10. Los servicios comunes (Common Facilities)

Los servicios comunes son servicios que pueden ser compartidos por las aplicaciones y que son de una naturaleza menos bsica que los servicios de objetos. Se dividen en servicios horizontales, que son utilizables en la mayora de las aplicaciones, y servicios verticales, que son especficos de un dominio o sector empresarial. Los servicios comunes horizontales son los siguientes: de internacionalizacin, tiempo y servicios relacionados

Editorial UOC

293

Captulo VII. Introduccin al software ...

de agentes mviles mientras que los servicios verticales que se han especificado hasta ahora son stos: Healthcare (Person Identification Service, Lexicon Query Service) Telecoms (Audio/Video Streams, CORBA TC Interworking and SCCP Inter-ORB Protocol, CORBA/TMN Interworking, Notification Service, Telecoms Log Service) Finance (Currency, General Ledger) Manufacturing (Distributed Simulation Systems, Product Data Management) Transportation (Air Traffic Control). Slo se tratar de los servicios horizontales.
El servicio de internacionalizacin y tiempo y servicios relacionados

El servicio de Internacionalizacin se basa en las caractersticas locales (locales) de POSIX y X/Open, que son aspectos del entorno del usuario que dependen del idioma y las convenciones culturales. Los usuarios pueden escoger unas caractersticas locales por omisin. Se consideran las caractersticas locales del POSIX, que son stas: la clasificacin de los caracteres y la conversin de las letras, la ordenacin alfabtica, el formato de los valores monetarios, el formato de los valores numricos no monetarios, formatos de mensajes y respuestas interactivas. Se consideran caracteres ampliados como los de IDL.
El servicio de agentes mviles

Pretende conseguir la interoperabilidad entre agentes mviles de diferentes fabricantes programados en el mismo lenguaje. Con vistas a este objetivo se estandarizan: La gestin de los agentes por un administrador del sistema, con funciones como la creacin de un agente de una clase determinada y suspensin, rearranque y cancelacin del hilo de ejecucin de un agente.

Editorial UOC

294

Ingeniera del software

La transferencia de agentes, que permite que dos agentes que se tendrn que comunicar durante la ejecucin (por ejemplo, para la monitorizacin de datos) se coloquen en sistemas de agentes prximos fsicamente. Los nombres de agentes y de sistemas de agentes, a ms de la estandarizacin de las operaciones y de las ubicaciones, para permitir identificar el agente del cual se pide una operacin y determinar rpidamente si un sistema de agentes determinado puede soportar un agente que llega a l. Las ubicaciones y los tipos de sistemas de agentes, para que un agente pueda acceder a informacin sobre un sistema de agentes y los sistemas de agentes se puedan identificar entre s. Un agente es un programa (no necesariamente orientado a objetos) que acta de manera autnoma en representacin de una persona u organizacin. Los agentes se programan generalmente en lenguajes interpretados, como Java y Tcl, para conseguir portabilidad, y tienen su propio hilo de ejecucin. Hay dos tipos de agentes: Agentes estacionarios, cuya ejecucin se completa en el mismo sistema donde ha empezado. Cuando se han de comunicar con agentes de otros sistemas o necesitan informacin externa a su sistema usan mecanismos como RPC, que pueden ser gestionados por sistemas de objetos distribuidos como CORBA, DCOM y RMI. Agentes mviles, que pueden viajar del sistema en que se han arrancado al sistema donde hay un agente con el cual han de interactuar y tambin pueden utilizar los servicios de objetos de este ltimo.

3.2.11. Interoperabilidad entre ORB

La interoperabilidad entre ORB pretende soportar la distribucin y la intercomunicacin de objetos entre copias e implementaciones de ORB diferentes que cumplan las especificaciones de CORBA. Se puede decir que as como un ORB hace posible que los objetos se enven y reciban peticiones y respuestas de forma transparente, la interoperabilidad en-

Editorial UOC

295

Captulo VII. Introduccin al software ...

tre ORB extiende esta transparencia al caso en que los objetos mencionados estn gestionados por ORB diferentes. La interoperabilidad se basa en los siguientes elementos: la arquitectura de la interoperabilidad, el soporte de puentes entre ORB y dos tipos de protocolos interORB: los generales (GIOP) y los de Internet (IIOP), adems de protocolos especficos para determinados entornos, como por ejemplo el DCE (ESIOP).
La arquitectura de la interoperabilidad

La arquitectura de la interoperabilidad proporciona un marco conceptual para identificar los elementos de la interoperabilidad y definir los aspectos que deben cumplir. Tambin establece mecanismos y convenciones para conseguir la interoperabilidad entre ORB producidos de forma independiente; en particular, introduce el concepto de puentes interORB. En este contexto, un dominio es un conjunto de objetos (los miembros del dominio) que tienen una caracterstica en comn. Un objeto puede pertenecer a varios dominios. Un dominio es tambin un objeto. Hay dos tipos de dominios: administrativos, como por ejemplo los dominios de nombres o los relacionados con recursos; tecnolgicos, vinculados a protocolos, por ejemplo. Entre dominios se pueden establecer dos tipos de relaciones: de contencin, cuando el mbito de uno es subconjunto del mbito de otro; de federacin, cuando los dominios se juntan por acuerdo de los respectivos gestores.
Los puentes entre dominios

El inters del concepto de dominio para la interoperabilidad est en el hecho de que sta consiste precisamente en superar las fronteras de los dominios, algo que se consigue mediante unas correspondencias o puentes entre dominios que permitan transformar las demandas expresadas en trminos de un dominio en peticiones expresadas en trminos del otro. Dado que el concepto de interoperabilidad es simtrico, es necesario que las transformaciones que los puentes soportan sean bidireccionales.

Editorial UOC

296

Ingeniera del software

Puentes seguros entre dominios No siempre es deseable la transparencia total, ya que en ocasiones se establecen dominios precisamente por razones de seguridad o de gestin de recursos compartidos o compartibles; en estos casos, el puente debe incorporar los filtros necesarios.

Los puentes permiten que los ORB colaboren sin que deban tener en cuenta los detalles de la implementacin del otro; tambin puede haber puentes que permitan la interoperabilidad con sistemas no basados en CORBA, como ocurre en el caso de COM de Microsoft. Adems, los puentes pueden servir para determinadas situaciones transitorias, generacin automtica de implementaciones para un ORB a partir de implementaciones hechas para otro, etc. Existen dos tipos de puentes: a) Inmediatos, en los que los elementos de un dominio se transforman directamente en los del otro; es una opcin adecuada cuando el cambio de dominio es puramente administrativo (es decir, cuando no hay cambio de tecnologa). b) Intermediados; en este tipo de puentes, lo que se construye son medios puentes que realizan transformaciones entre los formatos internos de los dos dominios y un tercer formato; es una opcin ms flexible pero menos eficiente que la anterior.Por lo que respecta a su relacin con los ORB, los puentes se pueden implementar de dos formas: internamente en el ORB (in-line), ya sea como servicios o como cdigo de stubs y esqueletos, y como capas por encima del ORB (request-level).
Transitoriamente, se puede empezar a utilizar un nuevo ORB que coexista con el antiguo.

Las referencias interoperables a objetos

Las referencias interoperables a objetos presentan las siguientes premisas: 1) No es necesario que los clientes sepan si las referencias de los objetos a los que dirigen peticiones son locales o remotas, ni si son del mismo ORB o de otro. 2) No es necesario que un ORB pueda tratar las referencias a objetos asignadas por otro ORB.

Editorial UOC

297

Captulo VII. Introduccin al software ...

Por lo tanto, en principio hay un dominio de referencias a objetos por cada ORB, y es necesario prever el puente correspondiente. Tambin hace falta prever la conversin de cdigos de caracteres.
El protocolo interORB general (GIOP)

El protocolo interORB general sirve para la comunicacin directa entre ORB, y est pensado para funcionar directamente sobre cualquier protocolo orientado a la conexin. Consta de los siguientes elementos: 1) La Common Data Representation (CDR), que es una sintaxis estndar que transforma tipos de datos de IDL en una representacin de bajo nivel para la transferencia entre ORN o bien entre puentes interORB. 2) Un conjunto de formatos de mensajes que pueden ser de cliente, de servidor o mixtos, para facilitar las peticiones, localizar implementaciones de objetos (incluso cuando pueden emigrar dinmicamente) y gestionar canales de comunicaciones, adems de soportar toda la funcionalidad de CORBA entre ORB. 3) Un conjunto de requisitos en lo que respecta al transporte: debe estar orientado a la conexin, debe garantizar que los bytes lleguen en el orden en que se han enviado y sin repeticiones, no debe haber lmites en el tamao del mensaje y no debe hacer falta fragmentacin o alineacin.
El protocolo interORB de Internet (IIOP)

El protocolo interORB de Internet forma parte de la especificacin del GIOP. Especifica cmo se pueden intercambiar mensajes de GIOP mediante TCP/IP, y tambin se puede utilizar como protocolo entre puentes intermediatos (medios puentes). Las definiciones del GIOP son abstractas, y el IIOP las convierte en concretas; de este modo, el IIOP describe el uso de las conexiones de TCP/ IP y cmo se identifican los objetos.
Los protocolos interORB para entornos especficos (ESIOP)

CORBA prev que haya protocolos para la interoperacin con infraestructuras concretas preexistentes de red o de computacin distribuida. Estas infraestructuras pueden soportar para los protocolos funciones especficas como la seguridad y la administracin. Estos protocolos deberan cumplir las reglas ge-

Editorial UOC

298

Ingeniera del software

nerales para la interoperabilidad. La versin 2.3 de CORBA incluye la especificacin de un ESIOP para DCE, DCE Common Inter-ORB Protocol (DCE-CIOP).

4. RMI

RMI ( Remote Method Invocation) es la herramienta de Java para el soporte de objetos distribuidos. RMI tiene una funcionalidad muy reducida en comparacin con CORBA, pero en cambio presenta la ventaja de que las invocaciones remotas tienen lugar sin salir del entorno Java. Aqu no se vern las sentencias de Java que cumplen esta funcin, sino slo sus aspectos generales. Las invocaciones remotas equivalen a las locales desde el punto de vista formal. Del mismo modo que en las locales, por lo tanto, el valor de un argumento o el resultado puede ser un objeto de cualquier clase; de esta manera, no slo se pueden transmitir datos entre los objetos cliente y el servidor, sino tambin objetos completos e implementaciones de objetos que se pueden ejecutar una vez recibidas. Para pasar los objetos se utilizan los mecanismos estndar de serializacin de Java. RMI se puede combinar con JNI para acceder a servidores programados en otros lenguajes, y con JDBC para acceder a bases de datos relacionales. Se pueden aplicar las funciones de seguridad y la comprobacin de tipos de Java.

4.1. Mecanismos de una invocacin remota

Es preciso definir las referencias para cada servidor que hay que exportar. Cuando un cliente recibe una referencia en un servidor RMI, obtiene un stub que da formato a los argumentos, utiliza la serializacin y enva la invocacin al servidor. Por la parte del servidor, RMI recibe la invocacin y la conecta a un esqueleto que restituye el formato a los argumentos e invoca la implementacin del mtodo al servidor; una vez ejecutado el mtodo, el esqueleto da formato al

Editorial UOC

299

Captulo VII. Introduccin al software ...

resultado ya sea un valor o una excepcin y enva el valor al cliente o provoca la excepcin. Tanto los stubs como los esqueletos se generan a partir de la implementacin del servidor.

5. Documentos compuestos distribuidos: DCOM

A pesar de que se acostumbra a considerar que la manipulacin de documentos pertenece ms al dominio de la ofimtica que al de la informtica profesional, los documentos compuestos nos interesan por dos razones: 1) Porque dentro de una interfaz grfica de usuario pueden figurar documentos, considerados objetos. 2) Porque los documentos compuestos pueden resultar de la combinacin de documentos distribuidos, y la tecnologa de documentos distribuidos es un caso particular de la tecnologa de objetos distribuidos.

5.1. Concepto de documento compuesto

Los documentos son objetos que se presentan directamente al usuario de forma visual y/o auditiva. Los documentos compuestos son aquellos documentos que resultan de la agregacin de otros (que tambin pueden ser compuestos), que denominaremos componentes, dentro de un determinado documento marco. Los objetos compuestos acostumbran a ser generados en tiempo de ejecucin; por otro lado, diferentes objetos componentes pueden ser gestionados y presentados por aplicaciones distintas. Por lo tanto, la caracterstica bsica que debe tener una herramienta de gestin de documentos compuestos es un protocolo que permita la comunicacin entre un conjunto lo bastante amplio de aplicaciones que gestionen tipos diferentes de documentos. La utilizacin de las aplicaciones diferentes en cuestin es mucho ms cmoda para el usuario si se hace mediante

Editorial UOC

300

Ingeniera del software

un documento compuesto que si se hace pasando de una aplicacin a otra de la forma convencional: pasando de una ventana a otra, abriendo manualmente cada fichero, etc.

5.2. Aspectos de la gestin de los documentos compuestos

A continuacin presentamos aspectos diferentes de la gestin de los documentos compuestos: a) Presentacin: el documento marco se presenta dentro de una sola ventana; cualquier documento compuesto debe tener la apariencia de un documento nico. La aplicacin que se encarga de un documento compuesto gestiona los contenedores donde se ubican los documentos componentes y, en particular, comunica a las aplicaciones que los gestionan todos los acontecimientos que tienen que ver con el contenedor respectivo.
Por ejemplo, si se redimensiona.

b) Almacenamiento estructurado: un documento simple se guarda en un fichero monoltico, mientras que un documento compuesto se guarda en uno que tiene partes que corresponden a los diferentes documentos componentes; la parte que corresponde a un documento puede contener, en efecto, el documento, o bien tener un puntero hacia el documento, que entonces reside en un fichero independiente. c) Scripts: son programas que se ejecutan cada vez que se produce un determinado acontecimiento, cuya funcin puede ser, por ejemplo, pedir una clave de acceso, dar acceso a ms o menos partes del documento segn la clave, acceder a un gestor de datos ( data warehouse), etc. Es conveniente decir que los scripts se deben poder preparar de una forma que no requiera programacin convencional, ya que generalmente los usuarios que crean los documentos no son programadores.
Por ejemplo, cuando se lee o se graba un documento.

Editorial UOC

301

Captulo VII. Introduccin al software ...

d) Transferencia de datos uniforme: los documentos compuestos deben permitir el intercambio datos principalmente documentos que incluyen documentos compuestos enteros con aplicaciones exteriores.
Por ejemplo, cut and paste, drag and drop, enlace mediante punteros, etc.

5.3. OLE, COM y DCOM

OLE es una ampliacin del portapapeles y de DDE para crear documentos compuestos orientados a objetos.
Dynamic Data Exchange (DDE) permite vincular un elemento componente a varios documentos compuestos, sin estar contenido en ninguno de stos y de forma que se puede editar, en principio, tan directamente como en un documento compuesto.

La inclusin de documentos componentes se puede llevar a cabo de dos formas: con embedding (inclusin), una copia del objeto y su formato de presentacin se almacenan dentro del documento y se transfieren con ste; con linking (enlace), el documento que se incluye dentro del compuesto contina dentro de su ubicacin original en un documento exterior o dentro del mismo documento compuesto, y el objeto que lo representa en este ltimo slo contiene el formato y un puntero.
Evolucin de la tecnologa de integracin de documentos La sigla OLE viene de Object Linking and Embedding. En 1990, Microsoft introdujo la tecnologa OLE 1 como herramienta bsica para integrar documentos creados por diferentes aplicaciones y datos multimedia en un documento marco; funcionaba sobre la base de que cuando una aplicacin necesitaba un documento creado por otra, esta ltima aplicacin se pona en marcha en una ventana aparte. En 1993 apareci OLE 2, incorporaba como ncleo una tecnologa de encapsulacin de objetos denominada COM (Component Object Model); de este modo, OLE 2 ya no era slo una herramienta para gestionar documentos compuestos, sino tambin una arquitectura para objetos bastante ms general. En 1994 se le aadi un concepto

Editorial UOC

302

Ingeniera del software

nuevo, el OCX, que fue un componente genrico que se incluye dentro del documento marco. Sin embargo, ya no hubo un OLE 3: desde entonces las versiones nuevas de OLE simplemente forman parte de las versiones nuevas de Windows. Posteriormente, ha aparecido DCOM (Distributed Component Object Model); DCOM extiende COM a entornos LAN, WAN e incluso a Internet. COM y DCOM han pasado de Microsoft al consorcio ActiveX, y DCOM est disponible para Windows NT 4.0 y Windows 2000, as como para Windows 95 y 98. Adems, Software AG ha hecho implementaciones de ello para diversas plataformas Unix: Solaris, Linux y HP/UX. Sin embargo, la estrategia de Microsoft no es que Windows funcione necesariamente con OLE, sino que la interfaz de usuario de Windows pueda estar soportada tambin por productos como Taligent y OpenStep.

5.3.1. Arquitectura

El Component Object Model (COM) es algo parecido a un ORB para un nico ordenador; DCOM soporta la distribucin. Dentro de la arquitectura podemos encontrar el grupo de los siguientes elementos: objetos, clases, interfaces y servidores. 1) Se denominan componentes los objetos de OLE, es decir, los documentos que se pueden incorporar a un documento complejo. Un objeto de COM no es un objeto clsico: es slo un grupo de funciones (denominadas tambin mtodos o funciones de miembros) relacionadas, pero que no tienen estado ni identidad, y un cliente no puede volver a conectar con el mismo objeto, sino slo con un puntero de interfaz de la misma clase. En estos subapartados, los trminos objeto, componente y documento se utilizarn indistintamente. Un documento compuesto es el resultado de la interaccin entre contenedores y servidores; se podra decir que los contenedores son lugares y los servidores son cosas que se ponen en estos lugares.
Atencin Aqu, el significado del trmino servidor no es el mismo que cuando se habla de cliente/ servidor; sin embargo, los contenedores se pueden considerar clientes de los servidores

Editorial UOC

303

Captulo VII. Introduccin al software ...

2) Las clases que implementan una interfaz o ms tienen un identificador nico que se denomina CLSID; un objeto es una implementacin en tiempo de ejecucin de una clase. Un componente consta de una clase que implementa una interfaz o ms y una factora de clase que instancia un objeto de la clase. 3) OLE y COM especifican interfaces entre objetos componentes dentro de una aplicacin o entre aplicaciones, y proporcionan una API para la localizacin dinmica de interfaces y para cargarlas y ejecutarlas. Un componente puede tener una interfaz o ms. Hay interfaces del mismo OLE e interfaces de usuario. Para definir estas interfaces, Microsoft tiene dos lenguajes: Interface Definition Language (IDL) y Object Description Language (ODL), que lo contiene. El lenguaje ODL para la definicin de interfaces es un lenguaje textual que se puede codificar manualmente o bien se puede generar mediante Visual C++ de Microsoft. Las interfaces de COM no generan cdigo en lenguajes de programacin, como las de CORBA, sino nicamente una API en binario para acceder a las interfaces mediante punteros. Se depositan en una biblioteca de tipo (type library), que tiene un papel similar al del depsito de interfaces de CORBA. Las interfaces tienen nombres que deben empezar por I, pero en tiempo de ejecucin se identifican por un identificador de interfaz (IID), que es generado por COM y no repetido, y que tambin identifica al objeto. Todas las interfaces de COM derivan de la interfaz IUnknown. Las interfaces del usuario constan de mtodos con sus parmetros, se crean en IDL y se les aplica el compilador de MDL; de esta compilacin se obtienen servidores intermediarios (proxies) del cliente, stubs del servidor y el cdigo que hace corresponder los parmetros de unos y otros. Todo esto tiene lugar en C.
Los proxies (servidores intermediarios) y los stubs se utilizan cuando el cliente y el objeto llamado estn en diferentes procesos.

Encontramos tanto la invocacin esttica de interfaces como la dinmica, que puede utilizar una biblioteca de tipo, donde hay descripciones de objetos en ODL precompiladas, con sus interfaces y parmetros. 4) Un servidor es un fichero .dll o .exe que contiene una clase o ms; cuando un cliente pide un objeto de un determinado CLSID, COM pide al servidor crear un objeto de aquella clase, y por este motivo el servidor debe proporcionar la

Editorial UOC

304

Ingeniera del software

factora de clase; cuando se crea un objeto, el servidor retorna el IID de la interfaz primaria.
La herencia

No hay referencia mltiple, pero se suple sobre la base de que los objetos pueden soportar varias interfaces. Esto permite crear objetos que presenten a los clientes los servicios de los objetos que agrupan (es decir, que los encapsulen), efecto que se puede conseguir mediante dos mtodos: Contencin y delegacin: el objeto contenedor enva a los objetos internos las invocaciones de los respectivos mtodos que recibe de los clientes. Agregacin: la interfaz de cada objeto interno forma parte de la del objeto contenedor y, por lo tanto, los clientes se pueden dirigir directamente a los objetos internos.
Acontecimientos

En COM, el soporte de los acontecimientos se hace por medio de los objetos o las fuentes conectables, que soportan interfaces de salida (adems de las de entrada); cada funcin de una de estas interfaces corresponde a un tipo de acontecimiento COM que proporciona interfaces, denominadas sumideros, para que otros objetos se puedan suscribir a los acontecimientos que las fuentes envan codificados en ODL; no hay nada parecido en los canales de acontecimientos de CORBA.

5.3.2. Los documentos compuestos y los OCX

Un documento compuesto de OLE contiene tantos datos propios como objetos gestionados por otras aplicaciones; tpicamente le corresponde un fichero compuesto, y hace de intermediario entre dos tipos de componentes: los contenedores, que proporcionan lugares donde poner las cosas, y los servidores, que son las cosas que se ponen. Un tercer tipo de componentes de OLE son los OCX, que tienen un conjunto de interfaces predefinidas. Un contenedor es una aplicacin de OLE que contiene un documento compuesto (o bien fsicamente o bien slo un puntero en este documento, en forma

Editorial UOC

305

Captulo VII. Introduccin al software ...

de moniker del servidor o los servidores del objeto). Para cada servidor, el contenedor crea un lugar donde actuar el servidor y presentar su contenido.
Clasificacin de los contenedores y servidores

Los contenedores pueden ser puros (que slo soporten embedding ), y linked (que slo soporten linking). La clasificacin de los servidores es la siguiente: a) In-process: se implementan en forma de DLL en el mismo espacio de direcciones que el contenedor, y slo pueden tratar objetos embedded; se subdividen en los siguientes: InProcHandlers, en los que varios servidores pueden compartir una misma ventana y mens relativos a un documento. InProcServers, DLL locales utilizadas por los servidores locales. Controls. b) Locales, que se implementan en forma de ficheros .exe separados, se comunican por Lightweight RPC con los contenedores y se ejecutan en la misma mquina y el mismo sistema operativo que sus clientes. Una clasificacin de los servidores por funcin es la siguiente: full servers, que soportan tanto embedding como linking y son aplicaciones autnomas, como Excel y Word; miniservers, que slo soportan embedding y slo pueden funcionar en la aplicacin del contenedor, como ocurre en el caso de Graph de Microsoft. c) Remotos, que se comunican por medio de RPC ordinarias con los contenedores.
Los OCX

Un OCX es una combinacin de un servidor in-process y un servidor de automatizacin, y soporta embedding, edicin in-place, automatizacin, notificaciones y, adems, objetos conectables, licencias y edicin de propiedades. Los contenedores para los OCX son contenedores para objetos embedded y edicin in-place que, adems, tienen unas propiedades de entorno accesibles al

Editorial UOC

306

Ingeniera del software

OCX y unas propiedades extendidas que gestionan para ste (aparte de las propiedades que gestiona el mismo OCX, que son las propiedades de control).
Propiedades como por ejemplo el color del fondo, el tamao del tipo de letra, etc.

5.3.3. La transferencia de datos

Lo que se transfiere mediante un protocolo de transferencia de OLE son objetos de datos, cuyo contenido puede estar representado en tres formatos diferentes: 1) estndar, que comprende los formatos utilizados en el portapapeles de Windows; 2) privados, que son especficos de las aplicaciones; 3) de OLE, que pueden tener dos estructuras diferentes: a) FORMATETC, que contiene una descripcin del tipo de datos, el dispositivo de almacenamiento y un puntero en los datos. b) STGMEDIUM, que describe el medio utilizado para transferir los datos (memoria, disco u objetos de documentos compuestos de OLE), y un puntero en la variable que se utiliza para hacerlo. Existen tres protocolos para la transferencia de datos: recortar/copiar y pegar por medio del portapapeles, drag and drop y mediante enlaces.
Transferencia de datos mediante enlaces El enlace entre documentos incluye un mecanismo de actualizacin automtica de todas las copias del documento por publicacin y suscripcin: se crea un objeto con una copia de los datos, que se deposita dentro de un directorio al que tienen acceso los suscriptores y que tambin contiene los enlaces a stos. Dentro de cada documento suscriptor hay un objeto que contiene la copia (que es nico incluso cuando la copia se utiliza en ms de un lugar del documento); cuando se modifica el documento, se enva una notificacin a todos los suscriptores, que entonces pueden pedir una copia actualizada.

Editorial UOC

307

Captulo VII. Introduccin al software ...

5.3.4. El almacenamiento estructurado y los monikers OLE tiene la arquitectura estructurada de almacenamiento que permite guardar en un solo fichero compuesto varios documentos independientes entre s. Los servicios de persistencia y almacenamiento estructurado de OLE utilizan tres tipos de elementos: 1) Los ficheros compuestos u objetos de almacenamiento constituyen una jerarqua de ficheros implementada en forma de elementos de directorio denominados almacenamientos, y de un tipo de ficheros denominados streams, que contienen una porcin de datos ms un puntero para acceder a stos. Entre los almacenamientos, encontramos hay uno que es la raz del fichero compuesto, que tiene una funcin para asociar el objeto de almacenamiento a un fichero de los gestionados por el sistema operativo. Un objeto de almacenamiento no contiene datos de la aplicacin, pero s nombres de almacenamientos y de streams. 2) Los objetos persistentes son objetos que se pueden leer o grabar en s mismos. Los objetos pueden soportar interfaces diferentes -una o ms al mismo tiempo- que les dan niveles distintos de persistencia. 3) Los monikers son objetos que actan como alias persistentes de otros; por ejemplo, ficheros, consultas a bases de datos, prrafos de documentos, etc. Adems, hay definidas distintas clases aplicables a diferentes tipos de objetos: de ficheros, de tems (fragmentos de documentos), anti (que anulan un moniker anterior), de punteros en memoria, y compuestos (que incluyen otros monikers, incluso compuestos). DCOM tambin utiliza monikers de URL, para los protocolos HTTP, HTTPS, FTP y GOPHER, que permiten acceder a objetos persistentes en Internet.

5.3.5. Los scripts y las libreras de tipos Los programas clientes pueden invocar mtodos que manipulan objetos con scripts. Para ello hay tres clases de componentes: 1) Servidores de automatizacin, que son los objetos a los que da acceso una aplicacin con scripts. Puede haber ms de uno por aplicacin. Tienen mtodos, que son funciones de miembros, y propiedades, cada una de las cuales es un par de funciones de miembros: una que pone un valor y otra que lo lee.

Editorial UOC

308

Ingeniera del software

2) Controladores de automatizacin, que son las herramientas y los programas de los clientes que acceden al servidor de automatizacin. Visual Basic, a partir de la versin 3.0, es un controlador de automatizacin. 3) Una librera de tipos describe los mtodos de entrada y de salida y las propiedades de un servidor. 4) Un solo programa puede controlar servidores de automatizacin de varias aplicaciones.

5.3.6. La interoperabilidad entre CORBA y COM/DCOM

La interoperabilidad entre CORBA y COM/DCOM pretende permitir el acceso de un cliente CORBA a un servidor DCOM, y al revs. Las especificaciones de CORBA describen las correspondencias entre diferentes elementos de CORBA y de COM: tipos de datos, identificadores de interfaces, excepciones, operaciones, atributos y herencia para que se puedan automatizar.

6. Desarrollo del software distribuido

6.1. El anlisis de requisitos en el caso de software distribuido El anlisis de requisitos en el caso de software distribuido es independiente del hecho de que el software que se derive de ste sea distribuido o no; la razn es que este anlisis se ocupa de lo que le debe aparecer al usuario por las pantallas y por las impresoras, independientemente de que todo el proceso se haga localmente o no.

6.2. La distribucin de los objetos En el caso de software distribuido, el diseo es igual que en el caso general, a excepcin de que tiene un paso ms al final: la distribucin de los objetos; las cla-

Editorial UOC

309

Captulo VII. Introduccin al software ...

ses y los objetos que tenga el software, independientemente de que deba estar distribuido o no, son los mismos porque estn determinados por la funcionalidad.

6.2.1. Uso del diagrama de despliegue

En el caso de que el diseo se haga orientado a objetos y con UML, est claro que el diagrama de despliegue se presta muy bien a describir la distribucin de objetos entre los nodos. De hecho, sin embargo, lo que se distribuir no sern objetos y clases individuales, sino componentes ms complejos.

6.2.2. Distribucin de los diferentes tipos de clases de anlisis

Una forma sencilla de distribuir los objetos consiste en partir de la distincin entre clases de frontera, de entidades y de control; podemos establecer estas reglas orientativas: a) Las clases de frontera se deben ubicar en las mquinas en que trabajan los usuarios directamente. b) Las clases de entidades y los respectivos gestores de disco estarn normalmente en las mquinas servidoras que tienen las bases de datos. c) Las clases de control se colocarn justo con las de frontera o bien con las de entidades, segn tengan ms interaccin con unas u otras.

6.2.3. Un paradigma alternativo

Scott Ambler, basndose en tcnicas de Rebecca Wirfs-Brock y otros autores, propone una tcnica para la distribucin de los objetos en arquitecturas cliente/servidor de n capas sin agentes mviles. Distingue cinco tipos de clases: Clases de la interfaz con el usuario. Clases del negocio/dominio.

Editorial UOC

310

Ingeniera del software

Clases de proceso, que implementan procesos que afectan a varias clases del dominio. Clases de persistencia, que pueden ser gestores de disco o frameworks. Clases del sistema, como por ejemplo las de comunicacin entre procesos. La distribucin de los objetos se hara en nueve pasos: 1) Distribucin de las dems clases antes que las del negocio/dominio. Las clases de la interfaz con el usuario se asignaran sistemticamente a los clientes, y las de persistencia, a los nodos donde debe estar la base de datos, si es nica, y en caso de que no lo sea, en un nodo aparte. Las clases del sistema que corresponden a servicios de uso general se replicaran en todos los nodos, mientras que las de servicios ms especficos se pondran en un nodo aparte.
Por ejemplo, seguridad.

2) Definir el contrato (interfaz pblica) de las clases. 3) Simplificar las jerarquas de especializacin y agregacin. Si una subclase no tiene contrato propio, ir donde vaya la superclase; un componente por composicin ir con la clase compuesta. 4) Identificar los componentes potenciales del dominio. Un componente es un conjunto de clases que colaboran para ofrecer un conjunto de contratos que sea coherente visto desde el exterior. Se supone que hay mucha ms circulacin de informacin entre las clases de un componente que entre el componente y el exterior. Una clase servidora con varios clientes probablemente tendr que ser un componente aparte, igual que aquellas clases que son slo clientes; sin embargo, si una clase servidora tiene un solo cliente, se pueden poner o bien juntas o bien en mquinas diferentes, unidas por una conexin de alta velocidad. Dos clases que colaboren con frecuencia irn dentro del mismo componente. 5) Definir los contratos en lo que respecta a componente del dominio. Si todo el contrato de una clase servidora est incluido dentro del contrato de componente al que pertenece, probablemente ser mejor segregarla como componente aparte; en cambio, si ninguna operacin del contrato de una clase forma parte del contrato del componente al que pertenece, entonces debe constituir un subsistema interno del componente.

Editorial UOC

311

Captulo VII. Introduccin al software ...

6) Simplificar los contratos de los componentes, agrupando operaciones con vistas a reducir el nmero de tipos de mensaje diferentes. 7) Asignar componentes a nodos mediante el diagrama de despliegue. Ser necesario buscar la minimizacin del trfico por la red. La distribucin se tendr que probar, y si es necesario, se deber cambiar. 8) Aadir clases complementarias, como por ejemplo clases que actan como interfaz de los componentes. 9) Distribuir las clases de la interfaz con el usuario segn los casos de uso que tendrn lugar en cada nodo.

Editorial UOC

312

Ingeniera del software

Bibliografa

Bibliografa bsica Booch, G.; Rumbaugh, J.; Jacobson, I. (1999). El lenguaje unificado de modelado. Madrid: Addison-Wesley. Booch, G.; Rumbaugh, J.; Jacobson, I. (1999). UML. El lenguaje de modelado unificado. Gua del usuario. Addison Wesley. Buschmann, F.; Meunier, R.; Rohnert, H.; Sommerlad, P.; Stal, M. (1996). A System of Patterns. Pattern-Oriented Software Architecture. Addison-Wesley. Coplien, J.O.; Schmidt, D.C.; Vlissides, J.M.; Kerth, N. (1996). Pattern Languages of Program Design 2. Addison-Wesley. Eriksson, H.E.; Penker, M. (1997). UML Toolkit. John Wiley & Sons. Fowler, M.; Scott, K. (1997). UML Distilled. Reading: Addison-Wesley Longman. Fowler, M.; Scott, K. (1999). UML gota a gota. Amsterdam: Prentice Hall. Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. (1995). Design Patterns: Elements of Reusable Object Oriented Software. Reading: Addison-Wesley. Gerarthy, R. y otros (1999). DCOM-CORBA Interoperability . Prentice Hall. Harrison, N.; Foote, B.; Rohnert, H. (1999). Pattern Languages of Program Design 4. Addison-Wesley. Jacobson, I. (1994). Object-Oriented Software Engineering: A Use Case Driven Approach . Addison- Wesley. Jacobson, I.; Booch, G.; Rumbaugh, J. (2000). El proceso unificado de desarrollo de software. Addison-Wesley. Kruchten, P. (2000). The Rational Unified Process. An Introduction (2. ed.). Addison-Wesley. Larman, C. (1998). Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design . Upper Saddle River: Prentice-Hall. Martin, R.C.; Riehle, D.; Buschmann, F.; Vlissides, J.M. (1997). Pattern Languages of Program Design 3 (Software Patterns Series). Addison-Wesley. Meyer, B. (1997). Object-Oriented Software Construction (2. ed.). Upper Saddle River: Prentice-Hall. Meyer, B. (1999). Construccin de software orientado a objetos (2. ed.). Madrid: Prentice-Hall. Orfali, R.; Harkey, D.; Edwards, J. (1999). Client/Server Survival Guide (3. ed.). Nueva York: John Wiley & Sons. Pressman, R.S. (1997). Ingeniera del software. Un enfoque prctico (4. ed.). Madrid: McGraw-Hill. Richter, Ch. (1999). Designing Flexible Object-Oriented Systems with UML. Indianpolis: MacMillan.

Editorial UOC

313

Bibliografa

Rock-Evans, R. (1998). DCOM Explained. Digital Press. Rosenberg, D.; Scott, K. (1999). Use Case Driven Object Modeling with UML: A Practical Approach. Reading: Addison-Wesley. Rumbaugh, J.; Jacobson, I.; Booch, G. (2000). UML. El lenguaje de modelado unificado. Manual de referencia . Madrid: Addison-Wesley. Slama, D.; Garbis, J.; Russell, P. (1999). Enterprise CORBA . Prentice Hall. Sommerville, I. (1995). Software Engineering (5. ed.). Harlow: Addison-Wesley. Weinschenk, S.; Jamar, P.; Yeo, S.C. (1997). GUI Design Essentials. John Wiley & Sons.

Editorial UOC

314

Ingeniera del software

Glosario

accin f Proceso que o no se ejecuta o se ejecuta hasta el final. acontecimiento m Hecho que se produce en un instante en el tiempo y que puede provocar una transicin. activacin f Parte de la lnea de vida de un papel de clasificador durante la cual se ejecutan acciones vinculadas al mismo. actor m Conjunto de papeles de una entidad exterior en relacin con el sistema del software considerado. arquitectura cliente/servidor m Sistema distribuido en el que un programa, el servidor, gestiona un recurso compartido; en relacin con este recurso, otros programas y los clientes pueden pedir funciones determinadas. asociacin binaria f Aqulla en la cual participan slo dos clases. asociacin derivada f Asociacin redundante que resulta de la combinacin de otras relaciones. asociacin reflexiva f Asociacin binaria de una clase consigo misma. atributo de clase m Atributo que tiene un nico valor para toda la clase. atributo derivado m Atributo cuyo valor se puede obtener a partir del de otros atributos. cardinalidad m En una asociacin binaria, la cardinalidad de un papel A es el nmero de objetos del otro papel B al que puede estar enlazado cada objeto de A; se indica el valor mximo y mnimo de este nmero. En una asociacin ternaria es lo siguiente: la cardinalidad del papel A expresa los lmites al nmero de objetos de A que pueden estar enlazados en cada combinacin concreta de un objeto del papel B y uno del papel C. CASE sigla de Computer-Aided Software Engineering. caso de uso m Interaccin entre el software y un actor o ms que comporta una o ms acciones. ciclo de vida clsico m Ciclo de vida en el que se supone que cada etapa se basa en los productos de la anterior y no se vuelve nunca a etapas anteriores. sin: ciclo de vida en cascada.

Editorial UOC

315

Glosario

ciclo de vida en cascada m sin: ciclo de vida clsico. ciclo de vida iterativo e incremental m Todo ciclo de vida en el que se pasa de manera repetida por las mismas fases desarrollando cada vez un fragmento ms de software. ciclo de vida m Conjunto de etapas del desarrollo de software por las cuales se pasa en el orden previamente establecido. clase abstracta f Superclase de la cual no se pueden instanciar objetos porque cada uno de sus objetos debe pertenecer a alguna de sus subclases. clase asociativa f Asociacin que, por el mero hecho de tener atributos y/o operaciones propias, llega a ser una clase. clase de control f Clase no persistente que implementa todos los algoritmos principales de un caso de uso o parte de ellos. clase de entidades f Clase del dominio del software . clase de frontera f Clase que implementa una parte de la interfaz de usuario en el mbito de anlisis. clase de utilidad f Recurso para agrupar procesos y/o datos en forma de una clase que no puede tener objetos. clase diferida f Clase abstracta que tiene alguna operacin abstracta. sin.: clase virtual. clase parametrizada f Especificacin de una clase en la cual permanecen sin concretar algunos aspectos de sus operaciones o atributos en forma de parmetros a los que se debe dar un valor. sin.: plantilla. clase persistente f Clase que puede tener objetos que se deban hacer persistentes. clase temporal f Clase que no es persistente, es decir, cuyos objetos no se pueden hacer persistentes. clase terminal f Clase cuyas subclases no se permite que se definan. clase virtual f Ved clase diferida. clase f Conjunto de objetos que tienen los mismos atributos y operaciones. clasificador: Concepto que comprende las clases, las interfaces y los tipos de datos.

Editorial UOC

316

Ingeniera del software

COM vase Component Object Model. Common Object Request Broker Architecture: Especificaciones de un middleware para objetos distribuidos elaborado por la OMG con el fin de que se convierta en un estndar. sigla: CORBA Component Object Model: Herramienta de gestin de objetos que se encarga de la gestin de documentos de OLE. sigla: COM componente m Conjunto de clases que colaboran para llevar a cabo una funcin concreta. Exteriormente se ve como una clase que implementa una interfaz determinada. componente m Objeto fsico que existe en tiempo de desarrollo, de compilacin o de ejecucin y que tiene identidad propia e interfaz. Computer-Aided Software : vase CASE. contexto (del software) m Entorno en el cual se utilizar el software que hay que desarrollar; nos interesa especialmente la organizacin y la terminologa. CORBA: vase Common Object Request Broker Architecture Custom Control: sin.: OCX desarrollo de software orientado a objetos m Desarrollo de software con mtodos centrados en el concepto de objeto derivados de la programacin orientada a objetos. desarrollo estructurado de software m Desarrollo de software con mtodos derivados de la programacin estructurada e histricamente anteriores a los orientados a objetos. diagrama esttico de anlisis m Diagrama esttico obtenido durante la etapa de anlisis que comprende las clases de entidades, de control y de frontera con sus atributos, operaciones y relaciones. dominio m Porcin del mundo real considerada por una aplicacin. especializacin f Identificacin de una o ms subclases dentro de una clase. esqueleto m Correspondencia entre las operaciones de una interfaz y los mtodos de los sirvientes que la implementan. Depende del ORB (es decir, su formato no es estndar) y del lenguaje de programacin. Se obtiene al compilar la interfaz.

Editorial UOC

317

Glosario

estado de accin m Estado que corresponde al hecho de que se encuentre en curso una accin determinada. estado de un objeto mv Conjunto de los valores de los atributos de un objeto en un momento dado. estado persistente de un objeto m Estado del objeto que est grabado en un sistema de almacenamiento permanente. Puede ser slo una parte del estado del objeto, y en un momento dado puede ser diferente del estado del objeto en memoria. estado m Situacin durante la vida de un objeto o la duracin de una interaccin en la cual cumple alguna condicin, lleva a cabo alguna actividad o espera algn acontecimiento. estereotipo m Variante de un elemento del UML. Hay estereotipos estndares, definidos dentro del UML, y se pueden definir como especficos para un proyecto. Los estereotipos se identifican por una palabra clave entre . estmulo m Peticin de una operacin o comunicacin de una seal que llega a un objeto. framework vase marco. general InterORB Protocol Protocolo general para la comunicacin directa entre ORB. sigla: GIOP generalizacin f Definicin de una superclase por abstraccin de los atributos y operaciones comunes en di-ferentes clases, que pasan a ser sus subclases. GIOP vase General InterORB Protocol herencia f Caracterstica por la cual todas las subclases tienen al menos todos los atributos y operaciones de cada una de sus superclases. herramientas CASE fs Software de apoyo al desarrollo, mantenimiento y documentacin informatizados de software. IIOP vase Internet InterORB Protocol. ingeniera del software f Conjunto de las tcnicas, mtodos y herramientas que se utilizan para producir software. instancia f Un objeto es una instancia de su clase. Este concepto se extiende a los clasificadores.

Editorial UOC

318

Ingeniera del software

interaccin f Especificacin del funcionamiento de una operacin o caso de uso en trminos de secuencias de mensajes entre instancias de clasificadores que piden operaciones o envan seales. interfaz de usuario f Lo que ven los usuarios del funcionamiento del software. Interfaz: Conjunto de operaciones de una clase visibles desde otras clases. Internet InterORB Protocol: Forma concreta que toma el GIOP en el caso de que la conexin entre ORB se haga mediante el protocolo de Internet, TCP/IP. invocacin dinmica f Invocacin de una demanda que se construye justo antes de ser invocada, en tiempo de ejecucin. lnea de vida f Intervalo de tiempo durante el cual existe un papel. marco: Conjunto de clases que constituye una aplicacin genrica e incompleta que hay que complementar con clases del usuario. Sin.: framework. mtodos formales de desarrollo de software m pl Mtodos de desarrollo que se basan en la especificacin de los requisitos en trminos de un formalismo matemtico riguroso. middleware Software que cumple el papel de intermediario entre mltiples clientes y mltiples servidores. modelo esttico m Modelo que describe las propiedades permanentes del software en trminos de clases y objetos. nodo m Representacin de un objeto fsico existente en tiempo de ejecucin con memoria y capacidad de proceso. object Linking and Embedding: Herramienta de Microsoft para integrar dentro de un documento marco documentos gestionados por diferentes aplicaciones y datos multimedia. sigla: OLE object Management Group vase OMG. object Request Broker Pseudoobjeto que constituye aquella parte de CORBA que se encarga de transmitir las peticiones de los objetos clientes a los objetos servidores. sigla: ORB

Editorial UOC

319

Glosario

objeto persistente m Objeto que no se debe destruir cuando acaba el proceso que lo ha creado porque lo tiene que utilizar algn proceso posterior. Hay que grabar su estado en un fichero permanente o base de datos. OCX: Combinacin de un servidor in-process y uno de automatizacin. Como fichero tiene la extensin .ocx. sin.: Custom Control OLE vase Object Linking and Embedding OMG Organizacin no lucrativa de empresas productoras y consumidoras de bienes y servicios informticos que tiene la finalidad de fomentar el uso de la tecnologa de objetos, y el medio con el que intenta conseguirlo es la elaboracin de estndares. operacin abstracta: Operacin de una superclase que no est implementada en sta sino slo en sus subclases. ORB vase Object Request Broker paquete m Elemento del modelo que puede contener elementos de cualquier tipo, incluso paquetes. Sirve para fraccionar el modelo segn algn criterio. patrn m Idea de diseo ampliamente probada y documentada. peticin f Mensaje dentro de CORBA de un objeto cliente a un objeto servidor, para pedir la ejecucin de una operacin contenida en una superficie soportada por este objeto servidor. plantilla f vase clase parametrizada. poa vase Portable Object Adapter Portable Object Adapter Componente de CORBA, en el lado del servidor, que se encarga de transmitir las demandas recibidas del ORB a los sirvientes que implementan los objetos servidores a los que estn dirigidas. sigla: POA prototipo: El prototipo de un sistema de software es una versin provisional del sistema, que slo tiene lo imprescindible para que el usuario pueda comprobar si se han entendido bien sus requisitos. Remote Method Invocation: Parte de JAVA que soporta la invocacin de operaciones entre objetos distribuidos. sigla: RMI

Editorial UOC

320

Ingeniera del software

Requisitos m pl Descripcin del comportamiento, propiedades y restricciones del software. RMI vase Remote Method Invocation seal f Estmulo entre dos instancias de clasificadores que puede provocar un acontecimiento. sirviente: En CORBA, implementacin de una interfaz a la que el POA correspondiente puede encargar la ejecucin de una demanda dentro del servidor. sistema abierto m Sistema distribuido basado en un conjunto de normas ampliamente aceptadas en el mbito internacional. transicin compuesta f Transicin con varios estados de origen y/o de destino. transicin interna: Recurso para especificar que cuando se produce un determinado acontecimiento que tiene lugar mientras el objeto est en un cierto estado, se deben ejecutar determinadas acciones sin que se produzca cambio de estado. transicin simple f Paso de un estado de origen a otro de destino provocado por un acontecimiento. Puede poner en funcionamiento acciones. UML: Modelo estndar para la construccin de software orientado a objetos. sigla: Unified Modeling Languag e. Unified Modeling Lenguage vase UML. visibilidad f Propiedad de diferentes elementos del modelo que representa que son reconocidos en un mbito ms o menos grande externo a aqul en el cual se han definido.