Professional Documents
Culture Documents
del software
Ingeniera
del software
Benet Campderrich Falgueras
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
3.
4.
5.
15
16
17
17
19
20
23
28
28
28
30
30
32
32
32
Conclusiones ................................................................................................... 35
37
39
40
43
43
Editorial UOC
48
51
54
56
57
57
63
66
67
67
67
Conclusiones ................................................................................................... 69
Editorial UOC
ndice
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
142
142
142
143
144
145
Editorial UOC
10
145
146
147
148
150
151
158
158
159
160
160
160
161
162
163
166
169
171
178
178
179
179
179
180
180
192
193
194
194
195
Editorial UOC
11
ndice
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
261
262
263
263
264
265
266
267
Editorial UOC
12
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
Editorial UOC
15
Captulo I
Editorial UOC
16
Editorial UOC
17
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.
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.
Editorial UOC
18
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
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.
Editorial UOC
20
La figura siguiente nos muestra las etapas previstas en una cierta versin del
ciclo de vida clsico.
2.1.1. Etapas
Editorial UOC
21
Editorial UOC
22
Editorial UOC
23
Editorial UOC
24
Editorial UOC
25
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.
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
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.
Editorial UOC
27
Editorial UOC
28
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
Editorial UOC
30
estos ltimos aos ha aparecido una notacin orientada a objetos muy ampliamente aceptada, el UML.
Editorial UOC
31
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
sarrollo de software que, tal como hemos visto, la tecnologa orientada a objetos
tiene que fomentar.
5. El OMG y el UML
Editorial UOC
33
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
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
Conclusiones
Editorial UOC
37
Captulo II
Dinmico
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.
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
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
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
Editorial UOC
40
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
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).
Editorial UOC
42
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
Editorial UOC
44
Editorial UOC
45
Editorial UOC
46
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
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.
Editorial UOC
48
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
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
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
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.
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.
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
4.3.3. Metaclases
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
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:
Editorial UOC
54
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
Editorial UOC
55
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
Editorial UOC
57
6.1. Asociaciones
Dentro de este subapartado veremos los conceptos y terminologa utilizados
para designar las asociaciones y los diferentes tipos existentes.
Editorial UOC
58
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.
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
2) Asociacin reflexiva
Consideremos la figura siguiente:
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
Editorial UOC
61
Editorial UOC
62
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
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.1. Agregaciones
Editorial UOC
64
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
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.
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
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
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
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
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
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
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.
Editorial UOC
73
Editorial UOC
74
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.
Editorial UOC
75
Editorial UOC
76
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
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
*. 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
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.
Editorial UOC
80
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
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 Sub1. 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
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.
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
2.1. Actores
Editorial UOC
84
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
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.
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
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.
Editorial UOC
87
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
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.
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.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
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
Editorial UOC
91
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
Editorial UOC
92
bolo del patrn por medio de lneas discontinuas en las clases u objetos que sustituyen las del patrn en esta aplicacin.
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
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
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
Editorial UOC
96
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
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.
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
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
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.
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
Editorial UOC
101
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
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.
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.
Editorial UOC
103
Editorial UOC
104
Editorial UOC
105
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.
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.
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
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:
Editorial UOC
107
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
Editorial UOC
110
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.
Editorial UOC
111
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
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
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.
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
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.
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.
Editorial UOC
115
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.
Editorial UOC
116
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.
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
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.
Editorial UOC
118
La descripcin textual
Editorial UOC
119
Editorial UOC
120
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
Editorial UOC
122
Editorial UOC
123
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
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
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
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.
Editorial UOC
127
Mediante los diagramas de colaboracin, identificamos los objetos que utilizan los casos de uso anteriores:
Editorial UOC
128
Editorial UOC
129
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.
Editorial UOC
130
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
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
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
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
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
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.
Editorial UOC
136
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
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.
Editorial UOC
138
Editorial UOC
139
Conclusiones
Editorial UOC
141
Captulo V
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:
Editorial UOC
142
Editorial UOC
143
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
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.
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
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.
Editorial UOC
146
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.
Editorial UOC
147
Editorial UOC
148
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.
Probablemente, es el paso ms difcil y tambin el que tiene ms repercusiones sobre los pasos y etapas posteriores.
Editorial UOC
149
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.
Editorial UOC
150
Editorial UOC
151
Editorial UOC
152
Editorial UOC
153
Generalizacin
Editorial UOC
154
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.
Editorial UOC
155
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.
Editorial UOC
156
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).
4.3.5. Agregaciones
Editorial UOC
157
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
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.
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
Editorial UOC
160
7. Ejemplo
Ya hemos visto un ejemplo de recogida y documentacin de requisitos. Ahora continuaremos el proceso realizando el anlisis para el mismo caso.
Editorial UOC
161
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:
Editorial UOC
162
Editorial UOC
163
7.5. Relaciones
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.
Editorial UOC
164
Editorial UOC
165
7.5.2. Asociaciones
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
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.
Editorial UOC
167
Editorial UOC
168
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
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
Editorial UOC
171
2) Clase PantallaAadirPropietario
Editorial UOC
3) Clase PantallaIntroducirInforme.
4) Clase PantallaIntroducirContrato
172
Editorial UOC
173
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
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
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
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
Editorial UOC
179
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.
Editorial UOC
180
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.
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
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
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.
Editorial UOC
183
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.
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
Editorial UOC
185
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.
Editorial UOC
186
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
Tipo
Sistema
Propsito
Creacin
GHJV
Adapter
Estructura
GHJV
Blackboard
Arquitectnico
BMRSS
Bridge
Estructura
GHJV
Builder
Creacin
GHJV
Chain of
responsibility
Comportamiento
GHJV
ClientDispatcherServer
Estructura
BMRSS
Command
Comportamiento
GHJV
Command
Processor
Comportamiento
BMRSS
Composite
Estructura
GHJV
Controller
Comportamiento
Larman
Creator
Estructura
Larman
Factory
Editorial UOC
Nombre
188
Tipo
Sistema
Propsito
Decorator
Estructura
GHJV
Dont call
to Strangers
Comportamiento
Larman
Expert
Comportamiento
Larman
Facade
Estructura
GHJV
Factory
Method
Creacin
GHJV
Flyweight
Estructura
GHJV
ForwarderReceiver
Estructura
BMRSS
High
Cohesion
Comportamiento
Larman
Indirection
Comportamiento
Larman
Interpreter
Comportamiento
GHJV
Iterator
Comportamiento
GHJV
Layers
Arquitectnico
BMRSS
Low Coupling
Comportamiento
Larman
Master-Slave
Estructura
BMRSS
Mediator
Comportamiento
GHJV
Editorial UOC
Nombre
189
Tipo
Sistema
Propsito
Memento
Comportamiento
GHJV
Microkernel
Arquitectnico
BMRSS
Model-ViewController
Arquitectnico
BMRSS
Observer
Comportamiento
GHJV
Pipes
and Filters
Arquitectnico
BMRSS
Polymorphism
Comportamiento
Larman
PresentationAbstractionControl
Arquitectnico
BMRSS
Prototype
Creacin
GHJV
Proxy (1)
Estructura
GHJV
Proxy (2)
Estructura
BMRSS
PublisherSubscriber
Comportamiento
BMRSS
PureFabrication
Estructura
Larman
Reflection
Arquitectnico
BMRSS
Singleton
Creacin
GHJV
Editorial UOC
190
Nombre
Tipo
Sistema
Propsito
State
Comportamiento
GHJV
Strategy
Comportamiento
GHJV
Template
Method
Comportamiento
GHJV
View Handler
Comportamiento
BMRSS
Visitor
Comportamiento
GHJV
Whole-part
Estructura
BMRSS
Editorial UOC
191
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.
Editorial UOC
192
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.
Editorial UOC
193
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.
3. El diseo arquitectnico
El diseo arquitectnico tiene como objetivo definir las grandes lneas del modelo del diseo.
Editorial UOC
194
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
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.
Editorial UOC
196
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.
Editorial UOC
197
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.
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
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.
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
Una manera de suprimir la herencia mltiple consiste en duplicar en la subclase los atributos que heredara de una de las superclases:
Editorial UOC
200
Las relaciones de herencia se pueden sustituir por agregaciones. Esto se puede hacer de dos maneras:
Editorial UOC
201
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.
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
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.
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
5.9.1. Cohesin
Editorial UOC
204
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
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
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.
Editorial UOC
207
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.
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
Editorial UOC
209
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
Evidentemente, esta solucin es muy sencilla, pero tiene los siguientes inconvenientes:
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
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
Tabla Cliente:
NIF: String, clave principal
Tipo: Integer
Nombre: String
...
Descuento: Integer
....
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
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
Editorial UOC
214
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
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
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
Editorial UOC
218
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
Editorial UOC
219
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
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
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
Editorial UOC
223
Elementos estticos
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.
Editorial UOC
224
e) Value sets. Son como botones de radio, pero con iconos en lugar de etiquetas. Por ejemplo, las paletas de colores.
Editorial UOC
225
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
g) Spin boxes. Permiten dar un valor, o aumentarlo o disminuirlo por saltos haciendo clic en unos botones con puntas de flecha.
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
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
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
Editorial UOC
230
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
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
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
7.1.2. La interaccin
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
La activacin
Transferencia de datos
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
Editorial UOC
235
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 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.
Editorial UOC
236
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.
Editorial UOC
237
Editorial UOC
238
o) Facilidad de utilizacin.
p) Facilidad de aprendizaje.
A menudo, es difcil hacer compatibles todas estas caractersticas.
Editorial UOC
239
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
una ventana a otra. Habr que buscar unos iconos adecuados; para asegurarse
de que lo son, se comprobar si los usuarios los reconocen fcilmente.
Aqu veremos algunas recomendaciones relativas a ventanas, mens, controles y cajas de dilogo y tambin algunas orientaciones sobre la ayuda en lnea.
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
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
Editorial UOC
242
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
Editorial UOC
243
Editorial UOC
244
9. Ejemplo
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
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.
Editorial UOC
246
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
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
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
Editorial UOC
250
Editorial UOC
251
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.
Editorial UOC
252
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
Editorial UOC
253
Editorial UOC
254
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.
Editorial UOC
255
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.
Editorial UOC
256
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.
Editorial UOC
257
Editorial UOC
258
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.
Como hemos visto, los subsistemas coinciden con los paquetes establecidos
en la etapa de anlisis. Estos paquetes son los que vemos a continuacin:
Editorial UOC
259
Editorial UOC
260
Conclusiones
Editorial UOC
261
Captulo VII
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.
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
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
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).
Editorial UOC
264
Editorial UOC
265
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.
Editorial UOC
266
Editorial UOC
267
Editorial UOC
268
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
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.
Editorial UOC
270
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
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
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.
Editorial UOC
273
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
Editorial UOC
275
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
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.
Editorial UOC
277
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.
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
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.
Editorial UOC
279
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.
Caractersticas comunes
Editorial UOC
280
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
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
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
Editorial UOC
283
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
Editorial UOC
284
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
Editorial UOC
286
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
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
Editorial UOC
289
Editorial UOC
290
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
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
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
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.
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
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
Editorial UOC
294
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.
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
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
Editorial UOC
296
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.
Editorial UOC
297
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
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
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
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.
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
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
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.
Editorial UOC
302
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
Editorial UOC
304
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
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
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
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.
Editorial UOC
307
Editorial UOC
308
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.
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.
Editorial UOC
309
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.
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.
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.
Editorial UOC
310
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.
Editorial UOC
311
Editorial UOC
312
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
Editorial UOC
314
Glosario
Editorial UOC
315
Glosario
Editorial UOC
316
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
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