8 Disenio PDF

Weitzenfeld: Captulo 8
8 Modelo de Diseo
El modelo de diseo es un refinamiento y formalizacin adicional del modelo de anlisis donde se toman en cuenta
las consecuencias del ambiente de implementacin. El resultado del modelo de diseo son especificaciones muy
detalladas de todos los objetos, incluyendo sus operaciones y atributos.
Se requiere un modelo de diseo ya que el modelo de anlisis no es lo suficientemente formal para poder llegar al
cdigo fuente. Por tal motivo se debe refinar los objetos, incluyendo las operaciones que se deben ofrecer, la
comunicacin entre los diferentes objetos, los eventos que los objetos envan entre si, etc. El sistema real debe
adaptarse al ambiente de implementacin. En el anlisis se asume un mundo ideal para el sistema, en la realidad se
debe adaptar el sistema al ambiente de implementacin, algo que puede cambiar durante el ciclo de vida del sistema.
Se busca adems aspectos como, los requisitos de rendimiento, necesidades de tiempo real, concurrencia, el lenguaje
de programacin, el sistema de manejo de base de datos, etc. Se desea tambin validar los resultados del anlisis.
Segn el sistema crece y se formaliza, se ver qu tan bien los modelos de requisitos y anlisis describen al sistema.
Durante el diseo, se puede ver si los resultados del anlisis son apropiados para su implementacin. Si se descubre
aspectos que no estn claros en alguno de los modelos anteriores, estos deben ser clarificados, quizs regresando a
etapas anteriores.
Aunque esto pudiera verse como deficiencias del resultado de las fases anteriores que deben ser clarificadas aqu,
esto sera una visin incorrecta de las diferentes etapas del desarrollo, ya que el propsito de los modelos de
requisitos y anlisis es comprender el sistema y darle una buena estructura. Tambin es importante comprender que
las consideraciones tomadas en cuenta durante el diseo deben influir en la estructura del sistema lo menos posible.
Es la propia aplicacin la que controla la estructura, no las circunstancias de su implementacin.
Se considera el modelo de diseo como una formalizacin del espacio de anlisis, extendindolo para incluir una
dimensin adicional correspondiente al ambiente de implementacin, como se puede ver en el diagrama de la Figura
8.1.
comportamiento
ambiente de
implementacin
informacin
presentacin
Figura 8.1 El diseo aade el ambiente de implementacin como un nuevo eje de desarrollo.
Esta nueva dimensin correspondiente al ambiente de implementacin debe considerarse al mismo tiempo que el
propio modelo es refinado. La meta es refinarlo hasta que sea fcil escribir cdigo fuente. Como el modelo de
anlisis define la arquitectura general del sistema, se busca obtener una arquitectura detallada como resultado del
modelo de diseo, de manera que haya una continuidad de refinamiento entre los dos modelos, como se puede ver
en el diagrama de la Figura 8.2. En particular se puede apreciar el cambio en los modelos a partir de la introduccin
del ambiente de implementacin
modelo de anlisis
modelo de diseo
refinamiento
introduccin del ambiente

de implementacin
Figura 8.2 El modelo de diseo es una continuacin del modelo de anlisis.

La transicin de anlisis a diseo debe decidirse por separado para cada aplicacin particular. Aunque es posible
continuar trabajando sobre el modelo de anlisis, incluso durante la incorporacin del ambiente de implementacin,
esto no es recomendable, ya que aumenta su complejidad. Por lo tanto, es deseable tener un modelo de anlisis ideal
del sistema durante el ciclo de vida completo del sistema, dado que muchos de los cambios del sistema provienen de
cambios en el ambiente de implementacin. Tales cambios son entonces fcilmente incorporados, ya que el mismo
modelo de anlisis sirve de base para el nuevo modelo de diseo. De esta manera se puede ver el modelo de diseo
como una especializacin del modelo de anlisis segn un ambiente de implementacin especfico.
Si un cambio en el modelo de diseo proviene de un cambio en la lgica del sistema, entonces tales cambios deben
hacerse en el modelo de anlisis. Sin embargo, si el cambio es una consecuencia de la implementacin, entonces
tales cambios no deben ser incorporados en el modelo de anlisis.
Las estructuras con las cuales se trabaja en el modelo de diseo son bsicamente las mismas que en el modelo de
anlisis. Sin embargo, el punto de vista cambia, ya que se toma un paso hacia la implementacin. El modelo de
anlisis debe se visto como un modelo conceptual y lgico del sistema, mientras que el modelo de diseo debe
acercarse al cdigo fuente. Esto significa que se cambia el punto del vista del modelo de diseo a una abstraccin
del cdigo fuente final. Por lo tanto el modelo de diseo debe ser una descripcin de cmo el cdigo fuente debe ser
estructurado, administrado y escrito.
En cierta manera este enfoque es una extensin del concpeto de la separacin de la poltica de la implementacin,
donde la poltica fue definida durante el modelo de anlisis y el diseo tiene la responsabilidad mantener esta
separacin durante el diseo de mtodos, aquellos que sirven para tomar decisiones (control) y aquellos que no
(interface y entidad).
En general, cambios en la arquitectura del sistema para mejorar el rendimiento del sistema deben ser pospuestos
hasta que el sistema est (parcialmente) construido. La experiencia muestra que en los sistemas grandes y
complejos, uno frecuentemente adivina incorrectamente cuales son los cuellos de botella crticos al rendimiento.
Para hacer una evaluacin ms adecuada es necesario evaluar parte del rendimiento del sistema construido, algo que
tambin se puede ir adelantando a nivel de prototipos.
Para llevar a cabo estos objetivos, se considera por separado los dos aspectos principales del modelo de diseo: el
diseo de sistema y el diseo de objetos:
? ? Diseo de Sistema. Se adapta el modelo al ambiente de implementacin. Este paso incluye identificar e
investigar las consecuencias del ambiente de implementacin sobre el diseo. Aqu deben ser tomadas las
decisiones de implementacin estratgicas: (i) cmo se incorporar una base de datos en el sistema, (ii) qu
bibliotecas de componentes se usarn y cmo, (iii) qu lenguajes de programacin se utilizarn, (iv) cmo se
manejarn los procesos, incluyendo comunicacin y requisitos de rendimiento, (v) cmo se disear el manejo
de excepciones y recoleccin de basura, etc. Por ejemplo, como se mencion en el Captulo 5, la mayora de los
lenguajes de programacin no tienen forma de implementar directamente una asociacin. Durante el diseo se
debe decidir cmo mecanismos abstractos como la asociacin, sern implementados. Similarmente, si el
lenguaje de programacin no ofrece ninguna tcnica para apoyar herencia, se debe especificar cmo sta ser
implementada. En resumen, se debe especificar cmo las circunstancias del ambiente de implementacin deben
ser manejadas en el sistema.
? ? Diseo de Objetos. Se refina y formaliza el modelo para generar especificaciones muy detalladas de todos los
objetos, incluyendo sus operaciones y atributos. Se describe cmo interaccionan los objetos en cada caso de uso
especfico, especificando qu debe hacer cada operacin en cada objeto. Este paso genera las interfaces de los
objetos, las cuales deben ser luego implementadas mediante mtodos.
En general, si el ambiente de implementacin tiene pocas consecuencias en el sistema, el diseo se basar casi
exclusivamente en el diseo de objetos, o sea, en un modelo de anlisis muy detallado describiendo los atributos y
operaciones del sistema. Por el contrario, si el ambiente de implementacin afecta mucho al sistema, el diseo se
basar principalmente en el diseo de sistema, o sea, en un modelo de anlisis que afecta de menor manera el
resultado final del sistema y que deber ser refinado posteriormente. En nuestro caso minimizaremos el efecto del
ambiente de implementacin sobre el sistema, razn por la cual comenzaremos con la descripcin del diseo de
objetos. Posteriormente describiremos los aspectos particulares relacionados con el diseo de sistema.
A contiuacin describimos algunas estrategias generales de diseo antes de proseguir con los aspectos especficos
del diseo, tanto de objetos como de sistema.
8.1 Estrategias de Diseo
Antes de poder resolver el diseo es necesario tomar decisiones generales sobre las estrategias de diseo a seguir.
Algunas de las decisiones a tomar se presentan a continuacin y se relacionan con aspectos que incluyen la
arquitectura, robustez, reuso y extensibilidad del sistema.
Arquitectura
El trmino arquitectura se refiere, en nuestro caso, a la organizacin de las clases dentro del sistema. Durante el
modelo de anlisis se gener una arquitectura de clases para el sistema y se defini la funcionalidad conceptual
ofrecida por las distintas clases dentro de la arquitectura. Durante el diseo esta arquitectura debe detallarse,
pudindose cambiar los aspectos considerados inicialmente, como fue la funcionalidad inicialmente asignada a cada
clase, e incluso las propias clases, como hemos mencionado al inicio del captulo.
El conocimiento y funcionalidad asignada a cada clase puede ser vista como la inteligencia de cada clase dentro
del sistema. En otras palabras, algunas clases pueden ser vistas como ms inteligentes que otras segn el
conocimiento y control que tengan sobre las dems clases. Por ejemplo, colecciones de objetos tales como listas o
arreglos, no se consideran como particularmente inteligentes ya que pueden manipular y obtener informacin sobre
las clases que almacenan, pero tienen relativamente poco impacto sobre estas u otras clases dentro del sistema. Por
otro lado, un manejador de interface de usuario requiere mayor inteligencia, ya que debe poder administrar la
interaccin con el usuario, incluyendo manejo de eventos y manipulaciones sobre las pantallas. Una clase an ms
inteligente es el controlador o manejador de la lgica completa de la aplicacin, ya que es responsables de
administrar a los propios manejadores de interface de usuario y relacionar su funcionalidad con el resto del sistema.
Como parte de la arquitectura de diseo se debe decidir cmo distribuir la inteligencia entre las clase y qu aspectos
de la inteligencia total del sistema debe ser asignada a cada una de ellas. Para esto existen tres alternativas
principales:
? ? Un enfoque es minimizar el nmero de clases inteligentes. En el caso ms extremo, slo un objeto tendra
conocimiento sobre todo el sistema. Todos los dems objetos tendrn un mnimo de inteligencia y el objeto
inteligente servir como controlador del resto. Una ventaja de este enfoque es que slo se requerira comprender
el flujo de control dentro del objeto principal para comprender toda de la aplicacin. Sin embargo, se vuelve
ms compleja la extensibilidad del sistema, ya que cualquier cambio en el flujo de control se llevara a cabo en
un mismo objeto afectando potencialmente la lgica de toda la aplicacin. En cierta manera esto puede
considerarse como la estructuracin del programa, en otras palabras, transformando la orientacin a objetos a
programacin estructurada, donde toda la aplicacin consta de un solo objeto.
? ? Otro enfoque opuesto es distribuir la inteligencia del sistema lo ms homogneamente posible, diseando todas
las clases con inteligencia similar. Este enfoque va ms con el espritu de la orientacin a objetos. Sin embargo,
una distribucin perfectamente homognea es una tarea casi imposible, ya que los objetos varan en sus
responsabilidades dependiendo de su razn de ser en la aplicacin. Por otro lado, distribuyendo la inteligencia
del sistema de manera homognea entre los objetos permite que cada objeto sepa relativamente menos cosas.
Esto produce objetos ms pequeos y ms fciles de comprender. La desventaja es que la inteligencia del
sistema va de la mano con la especializacin de las clases. Si todas las clases son inteligentes, esto significar
que ellas sern muy especializadas, dificultando la extensibilidad del sistema que requiere mayor generalizacin
en las clases.
? ? El tercer enfoque es encontrar un balance entre los dos primeros. La idea es homogenizar la inteligencia del
sistema slo entre ciertas clases, tales como las de control. El resto de las clases sern tontas o genricas,
cmo las clases entidad e interface, permitiendo un buen porcentaje de extensibilidad en el sistema. Esto sigue
la lgica introducida durante el modelo de requisitos y posteriormente anlisis, donde se distingue entre las
diversas razones de ser de las clases (comportamiento, presentacin y dominio) para lograr una mayor robustez
del sistema.
Robustez
La robustez de un sistema debe ser uno de los objetivos principales del diseo. Jams debe agregarse funcionalidad
o simplificar cdigo a expensas de la robustez. El sistema debe estar protegido contra errores y debe al menos
ofrecer diagnsticos para las fallas que an pudiesen ocurrir, en particular aquellas que son fatales. Durante el
desarrollo es a veces bueno insertar instrucciones internas en el cdigo para descubrir fallas, aunque luego sean
removidas durante la produccin. En general se debe escoger lenguajes de programacin que apoyen estos aspectos,
como son el manejo de excepciones. Las principales consideraciones relacionadas con la robustez de un sistema son
las siguientes:
? ? El sistema debe estar protegido contra parmetros incorrectos proporcionados por el usuario. Cualquier mtodo
que acepte parmetros del usuario debe validar la entrada para evitar problemas. El diseador de mtodos debe
considerar dos tipos de condiciones de error: (i) errores lgicos que son identificados durante el anlisis y (ii)
errores de implementacin, incluyendo errores del sistema operativo, tales como los errores de asignacin de
memoria, o errores de archivos de entrada y salida, etc.
? ? El sistema no debe optimizarse hasta que este funcione de manera correcta. A menudo los programadores le
dedican demasiado esfuerzo a mejorar partes del cdigo que se ejecutan poco frecuente. Optimizar requiere
primero medir el rendimiento del sistema. Se debe estudiar las alternativas, como aspectos de memoria,
velocidad, y simplicidad de implementacin. No se debe optimizar ms de lo necesario, ya que la optimizacin
compromete la extensibilidad, reuso y comprensin del sistema.
??
??
??
El sistema debe incluir estructuras de datos que no tengan lmites predefinidos. Durante el diseo es difcil
predecir la capacidad mxima esperada para la estructura de datos en la aplicacin. Por lo tanto, se debe escoger
estructuras de datos como las listas, a diferencia de los arreglos.
El sistema debe instrumentar un monitoreo de rendimiento y bsqueda de errores. El esfuerzo para llevarlo a
cabo depende del ambiente de programacin. Si el lenguaje de implementacin no proporciona ningn apoyo,
se pueden aadir mtodos de impresin para cada clase. Tambin se pueden aadir mensajes de entrada y salida
a los mtodos, imprimiendo selectivamente estos valores.
El encapuslamiento juega un papel fundamental para la robustez del sistema. Ocultar la informacin interna,
atributos e implementacin de mtodos, a una clase permite que sta pueda ser cambiada sin afectar al resto del
sistema. Unicamente la interface delos mtodos afecta a las dems clases.
Reuso
El reuso es un aspecto fundamental del diseo. Cuanto ms se pueda reutilizar el cdigo mejor ser la robustez del
sistema. Las siguientes son algunas estrategias para mejorar las posibilidades de reuso del diseo:
? ? A travs de la herencia se puede incrementar el reuso de cdigo. Se toman los aspectos comunes a clases
similares utilizando superclases comunes. Este enfoque es efectivo cuando las diferencias entre las clases son
pequeas y las similitudes son grandes. Es importante considerar la naturaleza de cada herencia para asegurar
que no se est llendo a extremos donde la aplicacin de la herencia sea inadecuada.
? ? El uso impropio de herencia puede hace que los programas sean difciles de mantener y extender. Como
alternativa, la delegacin provee un mecanismo para lograr el reuso de cdigo pero sin utilizar herencia. Esto se
basa en el uso de agregacin a travs de clases intermediarias que ocultan la funcionalidad de las clases a las
cuales se delega.
? ? El encapuslamiento es muy efectivo para lograr el reuso, pudindose aplicar tanto al nivel de los objetos como
de componentes desarrollados en otras aplicacines. Estos componentes pueden ser reutilizables como fueron
diseados a simplemente agregando nuevas interfaces.
Extensibilidad
La mayora de los sistemas son extendidos en manera no prevista por el diseo original. Por lo tanto, los
componentes reutilizables mejorarn tambin la extensibilidad. Las siguientes son algunas de las perspectivas de
extensibilidad:
? ? Nuevamente, se debe encapsular clases, ocultando su estructura interna a las otras clases. Slo los mtodos de la
clase deben accesar sus atributos.
? ? No se debe exportar estructuras de datos desde un mtodo. Las estructuras de datos internas son especficas al
algoritmo del mtodo. Si se exporta las estructuras se limita la flexibilidad para poder cambiar el algoritmo ms
tarde.
? ? Una clase debe tener un conocimiento limitado de la arquitectura de clases del sistema. Este conocimiento debe
abarcar nicamente las asociaciones entre ella y sus vecinos directos. Para interactuar con un vecino indirecto,
se debe llamar una operacin del objeto vecino para atravesar la siguiente relacin. Si la red de asociaciones
cambia, el mtodo de la clase puede ser modificado sin cambiar la llamada.
? ? Se debe evitar expresiones de casos (case statements) sobre tipos de objetos. Para ello, se debe usar mtodos
(polimorfismo) para seleccionar el comportamiento a ejecutarse basado en el tipo del objeto en lugar de
expresiones de casos. El polimorfismo evita muchas de estas comparaciones de tipos.
? ? Se debe distinguir entre operaciones privadas y pblicas. Cuando una operacin pblica es usada por otras
clases, se vuelve costoso cambiar la interface, por lo cual las operaciones pblicas deben ser definidas con
cuidado. Las operaciones privadas son internas a la clase y sirven nicamente de ayudan para implementar
operaciones pblicas. Las operaciones privadas pueden ser removidas o su interface cambiada para modificar la
implementacin de la clase, teniendo un impacto limitado en los dems mtodos de la clase.
8.2 Diseo de Sistema
Durante el diseo de sistema se toman condiseraciones en base al ambiente de implementacin teniendo como
objetivo lograr una buena rastreabilidad de la arquitectura de objetos al cdigo final. Estos objetos deben ser vistos
como abstracciones del cdigo a ser escrito donde, por ejemplo, un tpico objeto sera representado por un archivo
en el sistema, como es el caso de Java. En otros lenguajes, como C++, en lugar de un archivo se escriben dos, uno
correspondiente a la interface del objeto y el otro a su implementacin. En general, el diseo de sistema incluye
diversos aspectos como:
??
??
??
??
Seleccin del lenguajes de programacin a utilizarse, tpicamente estructurados u orientados a objetos;

Incorporacin de una base de datos, tpicamente relacionales, relacionales extendidos u orientados a objetos;
Acceso a archivos, en sus diferentes formatos;
Inclusin de bibliotecas, como por ejemplo, interfaces grficas (GUI), bibliotecas numricas y de estructuras de
datos;
? ? Consideraciones de tiempo real, si las hay;
? ? Aspectos de procesamiento, como concurrencia, paralelismo y distribucin;
? ? Aspectos transaccionales, tpicamente en el acceso a bases de datos;
? ? Organizacin del sistema en subsistemas;
? ? Asignacin de subsistemas a componentes de hardware y software.
Estos aspectos pueden variar radicalmente entre uno y otro sistema y tambin pueden afectar de gran manera la
arquitectura resultante del sistema. En general existen diversos enfoques para la incorporacin del ambiente de
implementacin a la arquitectura del sistema:
? ? Agregando clases abstractas o interfaces que luego sern especializadas segn el ambiente de implementacin
particular. Esto es posible hacer, por ejemplo, cuando el lenguaje de programacin, como en el caso de Java, es
comn a los diversos ambientes.
? ? Instanciando objetos especializados que administren los aspectos particulares del ambiente de implementacin
particular. Esto puede significar una integracin parcial o completa de componentes adicionales a la
arquitectura del sistema. Por ejemplo, una integracin con las interfaces nativas de Java (JNI) para manejo de
aspectos de bajo nivel del ambiente.
? ? Configurando mltiples versiones del sistema correspondientes a diferentes plataformas. Este es el enfoque ms
flexible, aunque por lo general el de mayor costo de desarrollo. Por ejemplo, cambios radicales en los lenguajes
de programacin incluyendo diseos para lenguajes estructurados.
En este captulo simplificaremos de gran manera el efecto del ambiente de implementacin. Utilizaremos a Java
como lenguaje de programacin bajo un procesamiento secuencial y con interfaces grficas tambin escritas en Java.
Para el Sistema de Reservaciones de Vuelos tambin incluiremos integracin con bases de datos y archivos externos,
algo que ser manejador a travs de las clases interface.
Interfaces Grficas
Las interfaces grficas tienen como aspecto esencial que toda interaccin con el usuario es a travs de elementos
grficos, como lo son los botones, mens y textos. En lo que se refiere a la aplicacin, todo sistema que interacte
mediante interfaces grficas est dirigido por eventos. Estos eventos corresponden al movimiento del ratn, el
oprimir o soltar uno de sus botones, el oprimir una tecla, junto con los que no son directamente iniciados por el
usuario, como los eventos de desplegar una pantalla o interrumpir un programa.
El desarrollar un sistema dirigido por eventos significa que la aplicacin debe desde un inicio considerar un diseo
adecuado. Por ejemplo, en el caso de Java, se debe inicialmente escoger una de sus bibliotecas grficas, como AWT,
para luego utilizar el manejo apropiado a travs de clases como Event.
El uso de estas bibliotecas tambin afecta la lgica de diseo, ya que se debe contemplar, por ejemplo, en que
momentos es apropiado procesar nuevos eventos y cmo se inicializar el sistema. Estas consideraciones y su efecto
sobre el resto del sistema sern discutidas ms adelante durante el diseo de objetos.
Bases de Datos
El aspecto de bases de datos siempre juega un papel fundamental en los sistemas de informacin. La decisin
estratgica ms importante en nuestro contexto es si utilizar bases de datos relacionales o las orientadas a objetos.
Dado su amplia utilizacin y la situacin actual en el mercado, escogeremos para nuestro desarrollo una base de
datos relacional utilizando el lenguaje SQL estndar. Simplifcaremos al mximo el diseo de la base de datos para
minimizar su efecto sobre el sistema completo. Ms bien, demostraremos como es posible disear buenas clases que
permitan en un futuro cambiar de manejadores de bases de datos.
8.3 Diseo de Objetos
El diseo de objetos es un proceso de aadir detalles al anlisis y tomar decisiones en relacin al diseo de sistema,
o sea al ambiente de implementacin. Algunos de los aspectos a ser resuletos diseo de objetos son determinar cmo
las clases, atributos y asociaciones del modelo de anlisis deben implementarse en estructuras de datos especificas.
Tambin es necesario determinar si se requiere introducir nuevas clases en el modelo de diseo para los cuales no se
tiene ninguna representacin en el modelo de anlisis o si se requiere modificar o eliminar clases identificadas
durante el modelo de anlisis. Se debe agregar herencia para incrementar el reuso del sistema. Tambin es necesario
determinar los algoritmos para implementar las operaciones, as como todos los aspectos de optimizaciones.
Para el diseo de objeto se seguir el diseo por responsabilidades (RDD - Responsibility-Driven Design). Este
diseo est basado en un modelo cliente-servidor donde las clases son vistas como clientes cuando generan alguna
peticin hacia otra clase y como servidores cuando reciben peticiones de alguna otra clase. De tal manera, una
misma clase puede ser vista en distintos momenots como cliente o servidor.
La funcionalidad ofrecida por lass clases servidores se define en trmino de sus responsabilidades, las cuales deben
ser satisfechas por lograr sus servicios con las dems clases. Los servicios y responsabilidades correspondern
finalmente a los mtodos de la clase. A su vez, las clases servidores a su vez pueden tener colaboraciones con otras
clases para lograr la satisfaccin de responsabilidades que por si solas no pueden lograr. Como consecuencia de esto,
se integran las responsabilidades y colaboraciones entre clases para definir contratos los cuales definen la naturaleza
y alcance de las interacciones cliente-servidor. Los contratos y colaboraciones representan los requisitos de servicios
entre los objetos. En resumen, se buscar identificar los contratos entre los objetos cliente y servidor diseando su
distribucin entre los distintos objetos del sistema.
En la siguientes secciones describiremos estos conceptos y todo lo relacionado con el diseo por responsabilidades.
En las siguientes secciones especificaremos los aspectos mencionados a continuacin con mayor detalle:
? ? Especificacin del uso de las tarjetas de clases.
? ? Identificacin de las responsabilidades del sistema.
? ? Identificacin de las colaboraciones del sistema.
? ? Identificacin de las jerarquas de herencia del sistema.
? ? Indentificacin de los contratos de servicio del sistema.
? ? Identificacin de los subsistemas del sistema.
? ? Identificacin de los protocolos del sistema.
Tarjetas de Clase
Las tarjetas de clases (tambin conocidas como tarjetas CRC: Clase-Responsabilidad-Colaboracin) permiten al
diseador visualizar las diferentes clases de manera independiente y detallada. El esquema para una tarjeta de clase
se muestra en la Tabla 8.1.
Clase:
Mdulo:
Propiedades:
Estereotipo:
Superclase:
Subclase:
Tabla 8.1. Diagrama para la tarjeta de clase.

La tarjeta se divide en tres secciones:
? ? Encabezado consistiendo del nombre de la clase, el mdulo al que pertenece la clase, las propiedades de la clase
(abstracta o concreta), el estereotipo de la clase (entidad, interface o control), una lista de superclases y otra
lista de subclases.
? ? Dos columnas debajo del encabezado, correspondientes a las responsabilidades (a la izquierda) y
colaboraciones (a la derecha) de la clase. Eventualmente en la columna izquierda se incluir informacin sobre
los contratos. El nmero de filas en estas dos columnas es extensible y no est limitado al nmero que aparece
en el diagrama de la Tabla 8.1.
Originalmente, detrs de cada tarjeta se agregaba una descripcin corta del propsito de cada clase, algo que
haremos a travs del diccionario de clases. Adems, incluimos algunos datos adicionales al esquema original CRC.
Como ejemplo consideremos la clase InterfaceUsuario, una de las clases identificadas durante el modelo de anlisis
para el ejemplo del sistema de reservaciones de vuelo. La tarjeta de clase sera la que se muestra en la Tabla 8.2.
Clase: InterfaceUsuario
Mdulo: InterfaceUsuario
Propiedades:
Estereotipo: Interface
Superclase:
Subclase:
Tabla 8.2. Diagrama para la tarjeta de clase de InterfaceUsuario

De tal manera se debe especificar una tarjeta para cada clase en el sistema, donde inicialmente las tarjetas incluirn
nicamente entradas para el nombre de la clase, mdulo al que pertenecen y estereotipo correspondiente. Dado que
an no se ha identificado herencia, no habrn entradas para propiedades, superclase o subclase. Como se puede
apreiar, inicilamente las tarjetas de clase tendrn informacin muy limitada, algo que a lo largo del diseo ser
extendido hasta alcanzar los mtodos y atributos detallados. Una vez creadas estas tarjetas procedemos a identificar
las responsabilidades de cada clase como veremos a continuacin.
Responsabilidades
Uno de los esfuerzos ms grandes del desarrollo y que involucran mayor complejidad es la especificacin del
comportamiento de cada una de las clases del sistema. A diferencia de la estructura interna de una clase,
representada mediante sus atributos, los comportamientos corresponden a las operaciones y mtodos de las clases.
Dado que por lo general el nmero resultante de mtodos en un sistema es mucho mayor al de clases, el proceso de
diseo involucra mayor complejidad que el de anlisis. Si consideramos tambin la existencia de los atributos y las
propias implementaciones de los mtodos dentro de cada clase, la complejidad aumenta radicalmente. Sin embargo,
esta complejidad no radica exclusivamente en el nmero de mtodos, sino ms bien en el hecho que potencialmente
todos los mtodos de un objeto pueden ser llamados por todos los objetos del sistema. Este es la verdadera fuente de
la complejidad en la arquitectura del sistema, ya que cualquier cambio en uno de estos mtodos afectar
potencialmente a todo el resto del sistema. Por lo tanto, es necesario llevar a cabo un proceso muy cuidadoso para la
identificacin del comportamiento de las diversas clases.
En general, el comportamiento de las clases no debe descomponerse directamente en operaciones, sino seguir un
procedimiento ms natural comenzando con una descripcin verbal de las responsabilidades o roles que tiene cada
clase dentro del sistema. Obviamente, cada objeto instanciado de una misma clase tendr responsabilidades
similares a las descritas por la clase. Las responsabilidades ofrecidas por un objeto corresponden a los servicios
apoyados por ste. A partir de estas responsabilidades se podr eventualmente determinar las operaciones que cada
objeto debe tener e incluso el conocimiento que el objeto debe guardar correspondiente a sus atributos y
asociaciones.
Las responsabilidades se identifican a partir de los casos de uso generados durante el modelo de anlisis. Para ello,
se revisa el modelo de casos de uso, haciendo una lista o subrayando todos las frases para determinar cuales de stas
representan acciones que algn objeto dentro del sistema deba ejecutar. Una de las decisiones ms importantes
durante la identificacin de responsabilidades es a qu clase o clases se les debe asignar. Para ello se debe examinar
el contexto en el cual se identificaron las responsabilidades.
Se debe asignar responsabilidades a las clases que almacenen la informacin ms relacionada con la
responsabilidad. En otras palabras, si un objeto requiere cierta informacin, es lgico asignarle la responsabilidad de
mantener esa informacin. Si la informacin cambia, no ser necesario enviar mensajes de actualizacin a otros
objetos. Esto tambin significa que la responsabilidad de mantener la informacin no debe se compartida. Compartir
informacin implica una duplicacin que puede dar lugar a inconsistencias. Si ms de un objeto tiene
responsabilidad sobre la misma informacin se debera reasignar la responsabilidad a un slo objeto. Tambin puede
ocurrir que cierta responsabilidad agrupe varias responsabilidades juntas. En tal caso se puede dividir o compartir la
responsabilidad entre dos o ms objetos. Si se vuelve difcil decidir a quien se debe asignar una responsabilidad, se
puede experimentar con diversas alternativas. Tal prueba puede resultar en beneficios inesperados con la ventaja de
que durante las primeras etapas del diseo, este proceso no es muy costoso. Ser mucho ms difcil y tomar ms
tiempo hacerlo despus de haber implementado el software completo.
Las responsabilidaes de una clase pueden ser privadas, en el caso de que slo son accesibles por el propio objeto, o
pblicas, en el caso de que cualquier objeto de cualquier clase puede accesarlas. Se busca que una clase no incluya
un gran nmero de responsabilidades. Si una clase tiene demasiadas responsabilidades esto puede ser un sntoma de
que se ha incluido demasiado detalle, o que se ha centralizado toda la inteligencia del sistema en una sola clase. Si se
tiene una clase que tiene un conocimiento de todas las dems clases en la arquitectura, se debe dividir esta en varias
clases adicionales. Se debe buscar un buen balance en la distribucin de la inteligencia, ya que esto lleva a diseos
mas flexibles y finalmente a software que es ms fcil de mantener y refinar.
Existen diversas consideraciones en cuanto a la especificacin de las responsabilidades. Se debe describir las
responsabilidades en trminos generales, para poder luego encontrar ms fcilmente responsabilidades compartidas
entre clases. Por lo tanto, no es necesario considerar aspectos especficos de las responsabilidades, como nombres
particulares o incluso parmetros. Para lograr mayor reuso, las responsabilidaes de composicin deben ser
resaltadas. Una distincin clara entre un agregado y sus parte puede ayudar a determinar donde deben estar las
responsabilidades para cierto comportamiento, restringiendo el nmero de posibilidades. La relacin puede ayudar a
identificar las responsabilidades tambin para mantener informacin.
Consideremos el sistema de reservaciones de vuelos. Dado que el diseo de un sistema se incrementa radicalmente
en relacin al tamao de la arquitectura desarrollado durante el anlisis, procederemos con la descripcin de parte
del sistema, mientras que el resto del diseo se mostrar en los apndices.
Como primer paso del diseo tomaremos los documentos de casos de uso generados como resultado del modelo de
anlisis. Para ello nos concentraremos inicialmente en los casos de uso relacionados con registro: Registrar Usuario,
Validar Usuario y Registrar Tarjeta.
A continuacin mostramos el flujo principal del caso de uso Registrar Usuario como se present al final del captulo
de anlisis.
Flujo Principal Este caso de uso comienza durante la inicializacin del sistema cuando la InterfaceUsuario
enva el evento inicializar al ManejadorPrincipal. El ManejadorPrincipal enva el evento
desplegarPaginaPrincipal a la InterfaceUsuario. La InterfaceUsuario enva el evento desplegar
a la PginaPrincipal (P-1). La PginaPrincipal se despliega. El Usuario puede seleccionar entre
las siguientes opciones: "Registrarse por Primera Vez", "OK" y "Cancel".
Si la actividad seleccionada es "Registrarse por Primera Vez", se ejecuta el subflujo Crear
Registro Usuario (S-1).
Si la actividad seleccionada es "OK", el Usuario debe haber insertado su login y password en la
pgina principal del sistema. La InterfaceUsuario enva el evento validarRegUsuario a la
PginaPrincipal. La PginaPrincipal enva el evento validarRegUsuario al ManejadorPrincipal.
Se ejecuta el caso de uso Validar Usuario. Una vez validado el usuario (E-1), el
ManejadorPrincipal enva el evento ofrecerServicio al ManejadorServicio. El
ManejadorServicio enva el evento desplegarPaginaServicio a la InterfaceUsuario. La
InterfaceUsuario enva el evento desplegar a la PginaServicio (P-2). La PginaServicio se
despliega. El caso de uso continua con el usuario seleccionando la opcin "Obtener Registro"
ejecutando el subflujo Obtener Registro Usuario (S-2).
Si la actividad seleccionada es "Regresar" en la pgina de servicios, se regresar al inicio de este
caso de uso.
Si la actividad seleccionada es "Salir" se saldr del sistema.
Tomamos cada una de las frases que describen el flujo y las analizaremos para decidir que responsabilidad
representan y a que clase se le asignan:
? ? Este caso de uso comienza durante la inicializacin del sistema cuando la InterfaceUsuario enva el
evento inicializar al ManejadorPrincipal. La primera pregunta es cul es la responsabilidad. La
responsabilidad que podemos identificar aqu es la InterfaceUsuario enva el evento inicializar al
ManejadorPrincipal. La siguiente pregunta es a quin se le asigna la responsabilidad. Dado que
InterfaceUsuario es el encargado de enviar el evento, se le asigna a esta clase la responsabilidad.
? ? El ManejadorPrincipal enva el evento desplegarPaginaPrincipal a la InterfaceUsuario. En este caso, la
responsabilidad es la oracin completa y la asignamos al ManejadorPrincipal por ser el encargado de enviar el
evento.
? ? La InterfaceUsuario enva el evento desplegar a la PginaPrincipal (P-1). De manera similar a la oracin
anterior, la responsabilidad que identificamos es la oracin completa y la asignamos a InterfaceUsuario por ser
el encargado de enviar el evento.
? ? La PginaPrincipal se despliega. Esta resonsabilidad se asigna a la nica clase involucrada que es
PginaPrincipal.
? ? El Usuario puede seleccionar entre las siguientes opciones: "Registrarse por Primera Vez", "OK" y
"Cancel". En general los actores no participan propiamente en la arquitectura del sistema por lo cual no se les
asigna ninguna responsabilidad. En particular los actores primarios son ms irresponsables que los actores
secundarios!
??
Si la actividad seleccionada es "Registrarse por Primera Vez", se ejecuta el subflujo Crear Registro
Usuario (S-1). Esta oracin no involucra ninguna clase por lo cual no identificamos ninguna responsabilidad de
ella.
? ? Si la actividad seleccionada es "OK", el Usuario debe haber insertado su login y password en la pgina
principal del sistema. Nuevamente, oraciones que describen responsabilidades para actores no son incluidas.
? ? La InterfaceUsuario enva el evento validarRegUsuario a la PginaPrincipal. La responsabilidad es toda la
oracin y se asigna a la InterfaceUsuario.
? ? La PginaPrincipal enva el evento validarRegUsuario al ManejadorPrincipal. La responsabilidad es toda
la oracin y se asigna a la PginaPrincipal.
? ? Se ejecuta el caso de uso Validar Usuario. Esta oracin no describe una responsabilidad particular.
? ? Una vez validado el usuario (E-1), el ManejadorPrincipal enva el evento ofrecerServicio al
ManejadorServicio. La responsabilidad es el ManejadorPrincipal enva el evento ofrecerServicio al
ManejadorServicio la cual se asigna a ManejadorPrincipal.
? ? El ManejadorServicio enva el evento desplegarPaginaServicio a la InterfaceUsuario. La responsabilidad es
toda la oracin y se asigna a ManejadorServicio.
? ? La InterfaceUsuario enva el evento desplegar a la PginaServicio (P-2). La responsabilidad es toda la
oracin y se asigna a InterfaceUsuario.
? ? La PginaServicio se despliega. La responsabilidad es toda la oracin y se asigna a PginaServicio.
? ? El caso de uso continua con el usuario seleccionando la opcin "Obtener Registro" ejecutando el subflujo
Obtener Registro Usuario (S-2). Esta oracin no involucra ninguna responsabilidad.
? ? Si la actividad seleccionada es "Regresar" en la pgina de servicios, se regresar al inicio de este caso de
uso. Esta oracin no involucra ninguna responsabilidad.
? ? Si la actividad seleccionada es "Salir" se saldr del sistema. Esta oracin no involucra ninguna
responsabilidad.
A partir de estas frases obtenemos las responsabilidades y las insertamos en las tarjetas de calse. Las tarjetas tienen
la ventaja de forzar a uno a ser breves, de tal manera que las responsabilidades se listan lo ms compacto posible.
Vale la pena notar que si las responsabilidades han sido incluidas en una tarjeta perteneciente a una superclase, no se
necesita incluirlas de nuevo en la tarjeta correspondiente a la subclase.
Si tomamos las responsabilidades identificadas anteriormente y las asignamos a sus respectivas clases, tendremos
una versin preliminar de tarjetas de clase como se muestra a continuacin. La Tabla 8.3 muestra las
responsabilidades identificadas hasta el momento para la clase InterfaceUsuario.
Propiedades:
Superclase:
Subclase:
enva el evento inicializar al ManejadorPrincipal
enva el evento desplegar a la PginaPrincipal
enva el evento validarRegUsuario a la PginaPrincipal
enva el evento desplegar a la PginaServicio
Tabla 8.3. Tarjeta para la clase InterfaceUsuario con responsabilidades identificadas hasta el momento.
La Tabla 8.4 muestra las responsabilidades identificadas hasta el momento para la clase ManejadorPrincipal.
Clase: ManejadorPrincipal
Mdulo: Principal
Propiedades:
Estereotipo: Control
Superclase:
Subclase:
enva el evento desplegarPaginaPrincipal a la InterfaceUsuario
enva el evento ofrecerServicio al ManejadorServicio
Tabla 8.4. Tarjeta para la clase ManejadorPrincipal con responsabilidades identificadas hasta el momento.
La Tabla 8.5 muestra las responsabilidades identificadas hasta el momento para la clase PaginaPrincipal.
10
Clase: PaginaPrincipal
Mdulo: Principal
Propiedades:
Superclase:
Subclase:
se despliega
enva el evento validarRegUsuario al ManejadorPrincipal
Tabla 8.5. Tarjeta para la clase PaginaPrincipal con responsabilidades identificadas hasta el momento.
La Tabla 8.6 muestra las responsabilidades identificadas hasta el momento para la clase ManejadorServicios.
Clase: ManejadorServicios
Mdulo: Servicios
Propiedades:
Superclase:
Subclase:
enva el evento desplegarPaginaServicio a la InterfaceUsuario
Tabla 8.6. Tarjeta para la clase ManejadorServicios con responsabilidades identificadas hasta el momento.
La Tabla 8.7 muestra las responsabilidades identificadas hasta el momento para la clase PaginaServicio.
Clase: PaginaServicio
Mdulo: Servicios
Propiedades:
Superclase:
Subclase:
se despliega
Tabla 8.7. Tarjeta para la clase PaginaServicio con responsabilidades identificadas hasta el momento.
De manera similar a la identificacin de responsabilidades del flujo principal del caso de uso RegistrarUsuario y su
asignacin a las distintas clases, se contina con los dems casos de uso. Dado que esta lista es bastante extensa, nos
concentraremos en las clases relacionadas con los casos de uso RegistrarUsuario, ValidarUsuario y
RegistrarTarjeta. En las siguientes secciones mostramos algunas de estas clases con sus responsabilidades asignadas
siguiendo el mismo procedimiento. Las clases completas se pueden ver en el Apndice.
InterfaceUsuario
La clase InterfaceUsuario recibe y enva eventos a un gran nmero de clases, algo que es resaltado por la lista
extensa de responsabilidades identificadas, como se muestra en la Tabla 8.8.
Propiedades:
Superclase:
Subclase:
enva el evento inicializar al ManejadorPrincipal
enva el evento desplegar a la PginaPrincipal
enva el evento validarRegUsuario a la PginaPrincipal
enva el evento desplegar a la PginaServicio
enva el evento crearRegUsuario a la PaginaPrincipal
enva el evento desplegar a la PginaCrearRegUsuario
enva el evento crearRegUsuario a la PginaCrearRegUsuario
informa al Usuario del xito del nuevo registro
enva el evento obtenerRegUsuario a la PaginaServicio
enva el evento desplegar a la PginaObtenerRegUsuario
enva el evento actualizarRegUsuario a la PaginaObtenerRegUsuario
11
informa al Usuario del xito de la actualizacin del registro

enva el evento eliminarRegUsuario a la PaginaObtenerRegUsuario
informa al Usuario del xito de la eliminacin del registro
enva el evento crearRegTarjeta a la PginaObtenerRegUsuario
enva el evento desplegar a la PginaCrearRegTarjeta
enva el evento crearRegTarjeta a la PginaCrearRegUsuario
enva el evento desplegar a la PginaObtenerRegTarjeta
enva el evento crearRegTarjeta a la PginaCrearRegTarjeta
enva el evento crearRegTarjeta a la PginaObtenerRegTarjeta
enva el evento actualizarRegTarjeta a la PginaObtenerRegTarjeta
enva el evento eliminarRegTarjeta a la PginaObtenerRegTarjeta
Tabla 8.8. Tarjeta para la clase InterfaceUusario con responsabilidades identificadas de los casos de uso
RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
Principal
Esta seccin incluye las clases principales de la arquitectura que son el ManejadorPrincipal y la PaginaPrincipal.
La clase ManejadorPrincipal recibe y enva eventos entre manejadores y la InterfaceUsuario, como se muestra en la
Tabla 8.9.
Mdulo: Principal
Propiedades:
Superclase:
Subclase:
enva el evento desplegarPaginaPrincipal a la InterfaceUsuario
enva el evento ofrecerServicio al ManejadorServicio
enva el evento crearRegUsuario al ManejadorRegistroUsuario
enva el evento validarRegUsuario al ManejadorRegistroUsuario
Tabla 8.9. Tarjeta para la clase ManejadorPrincipal con responsabilidades identificadas de los casos de uso
La clase PaginaPrincipal es la encarga de presentar las opciones de inicio del sistema, como se muestra en la Tabla
8.10.
Mdulo: Principal
Propiedades:
Superclase:
Subclase:
se despliega
enva el evento validarRegUsuario al ManejadorPrincipal
enva el evento crearRegUsuario al ManejadorPrincipal
Tabla 8.10. Tarjeta para la clase PaginaPrincipal con responsabilidades de interface identificadas de los casos
de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
Registro
Este mdulo se compone de los mdulos de Usuario, Tarjeta e InterfaceBD.
Usuario
Esta seccin involucra las clases de registro de usuario que son ManejadoRegistroUsuario,
PaginaCrearRegUsuario, PaginaObtenerRegUsuario y RegistroUsuario.
La clase ManejadoRegistroUsuario administra todo lo relacionado con registro de usuario, lo cual incluye recibir y
enviar eventos entre el ManejadorPrincipal, la InterfaceUsuario, y la InterfaceBaseDatosRegistro, como se muestra
en la Tabla 8.11.
Clase: ManejadorRegistroUsuario
12
Mdulo: Registro.Usuario
Propiedades:
Superclase:
Subclase:
enva el evento desplegarPaginaCrearRegUsuario a la InterfaceUsuario
enva el evento escribir RegistroUsuario a la InterfaceBaseDatosRegistro
le enva el evento OK a la InterfaceUsuario
enva el evento leer RegistroUsuario a la InterfaceBaseDatosRegistro
enva el evento desplegarPaginaObtenerRegUsuario a la InterfaceUsuario
enva el evento eliminar RegistroUsuario a la InterfaceBaseDatosRegistro
enva el evento validar RegistroUsuario a la InterfaceBaseDatosRegistro
enva el evento OK al ManejadorPrincipal
Tabla 8.11. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades identificadas de los casos de
uso RegistrarUsuario y ValidarUsuario.
La clase PaginaCrearRegUsuario administra la pantalla relacionada con la creacin de registro de usuario, como se
muestra en la Tabla 8.12.
Clase: PaginaCrearRegUsuario
Propiedades:
Superclase:
Subclase:
despliega un nuevo RegistroUsuario a ser llenado
enva el evento crearRegUsuario al ManejadorRegistroUsuario
enva el evento crearRegTarjeta al ManejadorRegistroTarjeta
Tabla 8.12. Tarjeta para la clase PaginaCrearRegUsuario con responsabilidades de interface identificadas del
caso de uso RegistrarUsuario.
La clase PaginaObtenerRegUsuario administra la pantalla relacionada con la modificacin y eliminacin de registro
de usuario, como se muestra en la Tabla 8.13.
Clase: PaginaObtenerRegUsuario
Propiedades:
Superclase:
Subclase:
despliega el RegistroUsuario
enva el evento actualizarRegUsuario al ManejadorRegistroUsuario
enva el evento eliminarRegUsuario al ManejadorRegistroUsuario
enva el evento obtenerRegUsuario al ManejadorRegistroUsuario
Tabla 8.13. Tarjeta para la clase PaginaObtenerRegUsuario con responsabilidades de interface identificadas del
La clase RegistroUsuario guarda la informacin de registro de usuario, como se muestra en la Tabla 8.14.
Clase: RegistroUsuario
Propiedades:
Estereotipo: Entidad
Superclase:
Subclase:
Actualizar informacin
Consultar informacin
13
Tabla 8.14. Tarjeta para la clase RegistroUsuario con responsabilidades de actualizar y consultar informacin
de registro para el caso de uso RegistrarUsuario.
Tarjeta
Esta seccin involucra las clases de registro tarjeta que son ManejadoRegistroTarjeta, PaginaCrearRegTarjeta,
PaginaObtenerRegTarjeta y RegistroTarjeta.
La clase ManejadoRegistroTarjeta administra todo lo relacionado con registro de tarjeta, lo cual incluye recibir y
enviar eventos entre el ManejadorRegistroUsuario, la InterfaceUsuario, y la InterfaceBaseDatosRegistro, como se
Clase: ManejadorRegistroTarjeta
Mdulo: Registro.Tarjeta
Propiedades:
Superclase:
Subclase:
enva el evento desplegarPaginaCrearRegTarjeta a la InterfaceUsuario
enva el evento escribir RegistroTarjeta a la InterfaceBaseDatosRegistro
enva el evento leer RegistroTarjeta a la InterfaceBaseDatosRegistro
enva el evento desplegarPaginaObtenerRegTarjeta a la InterfaceUsuario
enva el evento actualizar RegistroTarjeta a la InterfaceBaseDatosRegistro
enva el evento eliminar RegistroTarjeta a la InterfaceBaseDatosRegistro
Tabla 8.15. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades identificadas del caso de uso
RegistrarTarjeta.
La clase PaginaCrearRegTarjeta administra la pantalla relacionada con la creacin de registro de tarjeta, como se
Clase: PaginaCrearRegTarjeta
Propiedades:
Superclase:
Subclase:
despliega un nuevo RegistroTarjeta a ser llenado
Tabla 8.16. Tarjeta para la clase PaginaCrearRegTarjeta con responsabilidades de interface identificadas del
caso de uso RegistrarTarjeta.
La clase PaginaObtenerRegTarjeta administra la pantalla relacionada con la modificacin y eliminacin de registro
de tarjeta, como se muestra en la Tabla 8.17.
Clase: PaginaObtenerRegTarjeta
Propiedades:
Superclase:
Subclase:
despliega el RegistroTarjeta
enva el evento actualizarRegTarjeta al ManejadorRegistroTarjeta
enva el evento eliminarRegTarjeta al ManejadorRegistroTarjeta
Tabla 8.17. Tarjeta para la clase PaginaObtenerRegTarjeta con responsabilidades de interface identificadas del
caso de uso RegistrarTarjeta.
La clase RegistroTarjeta guarda la informacin de registro de tarjeta, como se muestra en la Tabla 8.18.
Clase: RegistroTarjeta
Propiedades:
14
Superclase:
Subclase:
Tabla 8.18. Tarjeta para la clase RegistroTarjeta con responsabilidades de actualizar y consultar informacin de
registro para el caso de uso RegistrarTarjeta.
Interface Base de Datos
La clase InterfaceBaseDatosRegistro es la encargada de interactuar con el actor BaseDatosRegistro para escribir y
leer la informacin all guardada, tanto de registro de usuario como de registro de tarjeta, como se muestra en la
Tabla 8.19.
Clase: InterfaceBaseDatosRegistro
Mdulo: Registro.InterfaceBD
Propiedades:
Superclase:
Subclase:
enva el evento leer RegistroUsuario a la BaseDatosRegistro
enva el evento escribir RegistroUsuario a la BaseDatosRegistro
devuelve el evento OK al ManejadorRegistroUsuario
devuelve el RegistroUsuario y el evento OK al ManejadorRegistroUsuario
enva el evento actualizar RegistroUsuario a la BaseDatosRegistro
enva el evento eliminar RegistroUsuario a la BaseDatosRegistro
enva el evento validar RegistroUsuario a la BaseDatosRegistro
enva el evento leer RegistroTarjeta a la BaseDatosRegistro
enva el evento escribir RegistroTarjeta a la BaseDatosRegistro
enva el evento actualizar RegistroTarjeta a la BaseDatosRegistro
enva el evento eliminar RegistroTarjeta a la BaseDatosRegistro
Tabla 8.19. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades de escribir y leer
informacin de registro de usuario y registro de tarjeta para los casos de uso RegistrarUsuario, ValidarUsuario
y RegistrarTarjeta.
Servicios
La clase ManejadorServicio es la encargada de todo lo relacionado con consultas, reservaciones y pagos. Adems de
esto, es responsable de permitir al usuario accesar la informacin de registro, como se muestra en la Tabla 8.20.
Clase: ManejadorServicio
Mdulo: Servicios
Propiedades:
Superclase:
Subclase:
enva el evento desplegarPaginaServicio a la InterfaceUsuario
enva el evento obtenerRegUsuario al ManejadorRegistroUsuario
Tabla 8.20. Tarjeta para la clase ManejadorServicio con responsabilidades a partir de los casos de uso
RegistrarUsuario y RegistrarTarjeta.
La clase PaginaServicio es la encarga de presentar las opciones de servicio del sistema, como se muestra en la Tabla
8.21.
Mdulo: Servicios
Propiedades:
Superclase:
Subclase:
se despliega
15
enva el evento obtenerRegUsuario al ManejadorServicio

Tabla 8.21. Tarjeta para la clase PaginaServicio con responsabilidades a partir de los casos de uso
RegistrarUsuario y RegistrarTarjeta.
Colaboraciones
Es indispensable que los objetos dentro de un programa colaboren entre si o de lo contrario el programa consistir de
mltiples mini-programas independientes. Las colaboraciones entre objetos se dan en base a las relaciones entre
responsabilidades de distintas clases. Dado la infinidad de posibles relaciones entre clase, las colaboraciones son la
fuente principal de complejidad en el diseo de objetos.
Las colaboraciones representan solicitudes de un objeto cliente a un objeto servidor. Los objetos pueden jugar el
papel de clientes o servidores dependiendo de su actividad en ese momento. Un objeto juega el papel de servidor
cuando satisface una solicitud hecha por un objeto cliente. Las colaboraciones se basan en llamadas a
responsabilidades o sevicios ofrecidos por otras clases. Desde el punto de vista del cliente, cada una de sus
colaboraciones se asocia con una responsabilidad implementada por el servidor. Aunque cada colaboracin trabaja
para satisfacer una sla responsabilidad, satisfacer una responsabilidad no requiere necesariamente de una sla
colaboracin. Puede tomar varias colaboraciones poder satisfacer una misma responsabilidad.
El proceso de identificacin de colaboraciones se basa en el patrn de interacciones de las clases dentro de la
aplicacin, algo que fue hecho durante el modelo de anlisis durante la generacin de la arquitectura de clases. Para
identificar colaboraciones se analiza las responsabilidades de cada clase, decidiendo si cada una de estas clases es
capaz de satisfacer sus responsabilidades por si misma o si requiere de otra clase para lograrlo. Se analiza qu tanto
sabe cada clase y qu otras clases necesitan su conocimiento o funcionalidad. Cada clase que necesita de otra clase
debe colaborar para recibirlo. El patrn de colaboraciones revela el flujo de control e informacin del sistema
durante su ejecucin. Analizando los patrones de comunicacin entre objetos puede revelar cuando una
responsabilidad se ha asignado de forma incorrecta. Incluso puede revelar responsabilidades ausentes. Se analizan
las colaboraciones estudiando qu objetos dentro del sistema tienen el conocimiento que se busca. Se busca aquellas
clases que colaboran y las que no colaboran con las dems, qu grupos de clases parecen trabajar juntas y donde
existen cuellos de botella. A travs de las colaboraciones se analizan las dependencias entre clases.
Si una clase no tiene colaboraciones con otras clases, en otras palabras, nadie colabora con ella y ella no colabora
con nadie, esta clase debe descartarse. Sin embargo, antes de hacerlo es bueno revisar el diseo completo
verificando todas las clases y colaboraciones. Es importante recordar que las colaboraciones son en una sla
direccin, y que ciertos tipos de clases son tpicamente clientes o servidores, ubicndose las clase en uno u otro
extremo de la colaboracin. En la mayora de los casos, las clases que representan interfaces externas no son clientes
de otros objetos en el sistema, si no que existen para ser servidores, donde otras clases colaboran con ellas.
Existen ciertas relaciones que denotan colaboraciones especiales.
Una relacin es-parte-depuede implicar una responsabilidad para el mantenimiento de informacin. Se puede ver
esta relacin de dos formas distintas: (i) relaciones entre clases compuestas (composite) y los objetos que las
componen y (ii) relaciones entre clases contenedoras (container) y los objetos que las componen. Una clase
compuesta es responsable de contener otros objetos que la componen, teniendo una mayor responsabilidad ya que
debe conocer a sus partes y a menudo satisfacer sus responsabilidades delegando a uno o ms de sus componentes.
Por ejemplo, para poner en marcha un automvil es necesario oprimir el acelerador, el cual acelera el motor para
hacer girar ms rpido las reudas. El automvil debe colaborar con varias de sus partes, en particular el motor, los
ejes y las ruedas para satisfacer esta responsabilidad. Por el contrario, relaciones entre clases contenedoras y los
elementos que contiene por lo general no requieren de una colaboracin. Por ejemplo, una lista contiene a sus
elementos sin haber necesidad de comunicarse con ellos, ya que la lista no tiene la responsabilidad de mantener
informacin sobre sus elementos, excepto tener una referencia a ellos. Sin embargo, algunas clases contenedoras,
pueden tener que colaborar con sus elementos. Por ejemplo, una lista ordenada requiere obtener informacin de sus
opartes para lograr las comparaciones necesarias.
Una relacin tiene-conocimiento-depuede indicar responsabilidades sobre el conocimiento de informacin,
implicando una colaboracin entre la clase que tiene el conocimiento y la clases que se conocen. Este tipo de
asociacin no denota una relacin de composicin, nicamente de conocimiento. Una relacin depende-depuede
implicar una relacin tiene-conocimiento-deo la existencia de una tercera parte en una composicin.
Para grabar las colaboraciones se toma la tarjeta de clase que juega el papel de cliente, escribiendo el nombre de la
clase que juega el papel de servidor. Se escribe ese nombre directamente a la derecha de la responsabilidad a la cual
la colaboracin ayuda a satisfacer. Si una responsabilidad requiere varias colaboraciones, se escribe el nombre de
cada clase requerida para satisfacer la responsabilidad. Por otro lado, si varias responsabilidades requieren una
16
misma clase para colaborar, se graban varias colaboraciones, una para cada responsabilidad. Se debe asegurar que la
responsabilidad correspondiente exista para cada colaboracin que se grabe.
Los servicios provistos por una clase incluyen aquellos listados en la tarjeta y las responsabilidades que hereda de
sus superclases. Sin embargo, si se da una colaboracin con una subclase donde el servicio est definido por la
superclase, la responsabilidad correspondiente debe ser grabada nicamente en la tarjeta de la superclase. Esto se
hace a menos que la subclase sobrescriba el servicio de la superclase, en cuyo casa tambin se graba en la tarjeta de
la subclase. Si satisfacer una responsabilidad requiere una colaboracin con otras instancias de la misma clase (o
instancias de sus superclases), sta debe ser grabada tambin.
En esta seccin se describen las colaboraciones para el Sistema de Reservaciones en base a los casos de uso
RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. Ntese que se omiten actores primarios, como Usuario, en
las colaboraciones, aunque se incluyen los actores secundarios como BaseDatosRegistro.
InterfaceUsuario
A partir de la Tabla 8.8 se generan las colaboraciones para la clase InterfaceUsuario, como se muestra en la Tabla
8.22.
Propiedades:
Superclase:
Subclase:
enva el evento inicializar
ManejadorPrincipal
enva el evento desplegar
PginaPrincipal
enva el evento validarRegUsuario
PginaPrincipal
PginaServicio
enva el evento crearRegUsuario
PaginaPrincipal
PginaCrearRegUsuario
informa del xito del nuevo registro
enva el evento obtenerRegUsuario
PaginaServicio
PginaObtenerRegUsuario
enva el evento actualizarRegUsuario
PaginaObtenerRegUsuario
informa del xito de la actualizacin del registro
enva el evento eliminarRegUsuario
informa del xito de la eliminacin del registro
enva el evento crearRegTarjeta
PginaObtenerRegUsuario
PginaCrearRegTarjeta
PginaObtenerRegTarjeta
PginaCrearRegTarjeta
enva el evento actualizarRegTarjeta
enva el evento eliminarRegTarjeta
Tabla 8.22. Tarjeta para la clase InterfaceUusario con responsabilidades y colaboraciones identificadas de los
casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
Principal
A partir de la Tabla 8.9 se generan las colaboraciones para la clase ManejadorPrincipal, como se muestra en la
Tabla 8.23.
Mdulo: Principal
Propiedades:
Superclase:
17
Subclase:
enva el evento desplegarPaginaPrincipal
InterfaceUsuario
enva el evento ofrecerServicio
ManejadorServicio
ManejadorRegistroUsuario
Tabla 8.23. Tarjeta para la clase ManejadorPrincipal con responsabilidades y colaboraciones identificadas de
los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
A partir de la Tabla 8.10 se generan las colaboraciones para la clase PaginaPrincipal, como se muestra en la Tabla
8.24.
Mdulo: Principal
Propiedades:
Superclase:
Subclase:
se despliega
ManejadorPrincipal
ManejadorPrincipal
Tabla 8.24. Tarjeta para la clase PaginaPrincipal con responsabilidades y colaboraciones identificadas de los
Registro
Usuario
A partir de la Tabla 8.11 se generan las colaboraciones para la clase ManejadoRegistroUsuario, como se muestra en
la Tabla 8.25.
Propiedades:
Superclase:
Subclase:
enva el evento desplegarPaginaCrearRegUsuario
InterfaceUsuario
enva el evento escribir
RegistroUsuario, InterfaceBaseDatosRegistro
enva el evento OK
InterfaceUsuario
enva el evento leer
enva el evento desplegarPaginaObtenerRegUsuario
InterfaceUsuario
enva el evento eliminar
enva el evento validar
enva el evento OK
ManejadorPrincipal
Tabla 8.25. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades y colaboraciones
identificadas de los casos de uso RegistrarUsuario y ValidarUsuario.
A partir de la Tabla 8.11 se generan las colaboraciones para la clase PaginaCrearRegUsuario, como se muestra en
la Tabla 8.26.
Propiedades:
Superclase:
Subclase:
despliega
RegistroUsuario
18

ManejadorRegistroTarjeta
Tabla 8.26. Tarjeta para la clase PaginaCrearRegUsuario con responsabilidades y colaboraciones identificadas
del caso de uso RegistrarUsuario.
A partir de la Tabla 8.12 se generan las colaboraciones para la clase PaginaObtenerRegUsuario, como se muestra en
la Tabla 8.27.
Propiedades:
Superclase:
Subclase:
despliega
RegistroUsuario
enva el evento actualizarRegUsuario
enva el evento eliminarRegUsuario
Tabla 8.27. Tarjeta para la clase PaginaCrearRegUsuario con responsabilidades y colaboraciones identificadas
del caso de uso RegistrarUsuario.
A partir de la Tabla 8.13 se generan las colaboraciones para la clase RegistroUsuario, como se muestra en la Tabla
8.28. Dado que RegistroUsuario es una clase entidad, las responsabilidad no son por lo general delegadas, por lo
cual no se agregan colaboraciones.
Propiedades:
Superclase:
Subclase:
Tabla 8.28. Tarjeta para la clase RegistroUsuario con responsabilidades y colaboraciones de actualizar y
consultar informacin de registro para el caso de uso RegistrarUsuario.
Tarjeta
Esta seccin involucra las clases de registro de tarjeta que son ManejadoRegistroTarjeta, PaginaCrearRegTarjeta,
A partir de la Tabla 8.14 se generan las colaboraciones para la clase ManejadoRegistroTarjeta, como se muestra en
la Tabla 8.29.
Propiedades:
Superclase:
Subclase:
enva el evento desplegarPaginaCrearRegTarjeta
InterfaceUsuario
RegistroTarjeta, InterfaceBaseDatosRegistro
enva el evento leer
enva el evento desplegarPaginaObtenerRegTarjeta
InterfaceUsuario
enva el evento actualizar
Tabla 8.29. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades y colaboraciones identificadas
del caso de uso RegistrarTarjeta.
19
A partir de la Tabla 8.15 se generan las colaboraciones para la clase PaginaCrearRegTarjeta, como se muestra en la
Tabla 8.30.
Propiedades:
Superclase:
Subclase:
despliega
RegistroTarjeta
Tabla 8.30. Tarjeta para la clase PaginaCrearRegTarjeta con responsabilidades y colaboraciones identificadas
A partir de la Tabla 8.|6 se generan las colaboraciones para la clase PaginaObtenerRegTarjeta, como se muestra en
la Tabla 8.31.
Propiedades:
Superclase:
Subclase:
despliega
RegistroTarjeta
enva el evento actualizarRegTarjeta
enva el evento eliminarRegTarjeta
Tabla 8.31. Tarjeta para la clase PaginaCrearRegTarjeta con responsabilidades y colaboraciones identificadas
A partir de la Tabla 8.17 se generan las colaboraciones para la clase RegistroTarjeta, como se muestra en la Tabla
8.32. Dado que RegistroTarjeta es una clase entidad, como en el caso de RegistroUsuario, no se agregan
colaboraciones.
Propiedades:
Superclase:
Subclase:
Tabla 8.32. Tarjeta para la clase RegistroTarjeta con responsabilidades y colaboraciones de actualizar y
consultar informacin de registro para el caso de uso RegistrarTarjeta.
Interface Base Datos
A partir de la Tabla 8.18 se generan las colaboraciones para la clase InterfaceBaseDatosRegistro, como se muestra
en la Tabla 8.33.
Mdulo: Registro.InterfaceBD
Propiedades:
Superclase:
Subclase:
enva el evento leer
RegistroUsuario, BaseDatosRegistro
devuelve el evento OK
devuelve el evento OK
RegistroUsuario, ManejadorRegistroUsuario
20

enva el evento validar
enva el evento leer
RegistroTarjeta, BaseDatosRegistro
Tabla 8.33. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades y colaboraciones de escribir
y leer informacin de registro de usuario y registro de tarjeta para los casos de uso RegistrarUsuario,
ValidarUsuario y RegistrarTarjeta.
Servicios
A partir de la Tabla 8.19 se generan las colaboraciones para la clase ManejadorServicio, como se muestra en la
Tabla 8.34.
Mdulo: Servicio
Propiedades:
Superclase:
Subclase:
enva el evento desplegarPaginaServicio
InterfaceUsuario
Tabla 8.34. Tarjeta para la clase ManejadorServicio con responsabilidades y colaboraciones a partir de los casos
de uso RegistrarUsuario y RegistrarTarjeta.
A partir de la Tabla 8.20 se generan las colaboraciones para la clase PaginaServicio, como se muestra en la Tabla
8.35.
Mdulo: Servicio
Propiedades:
Superclase:
Subclase:
se despliega
ManejadorServicio
Tabla 8.35. Tarjeta para la clase PaginaServicio con responsabilidades y colaboraciones a partir de los casos de
uso RegistrarUsuario y RegistrarTarjeta.
Jerarquas
El diseo de las jerarquas de herencia es uno de los aspectos de programacin ms importantes de la orientacin a
objetos. A travs de la herencia se puede reducir radicalmente la complejidad del diseo de la arquitectura del
sistema. Aunque llevaremos a cabo una sla etapa de diseo de jerarquas, la herencia debe aplicarse continuamente
a lo largo del diseo de objetos.
La herencia se identifica a partir de las responsabilidades y colaboraciones identificadas anteriormente. Si varias
clases definen una responsabilidad similar, se puede introducir una superclase de la cual estas clases hereden la
responsabilidad comn. Las nuevas superclases tpicamente son clases abstractas. Una forma de factorizar
responsabilidades en la jerarqua es disear un buen nmero de clases abstractas. Cuando se determina cuantas
clases estn presentes en el diseo, se puede especular sobre las clases abstractas que pudieran encapsular
comportamiento para ser reutilizadas por subclases existentes y futuras. Se debe tambin buscar atributos comunes y
responsabilidades duplicadas y analizar si existen abstracciones adicionales que sean tiles.
De tal manera se sentarn las bases para una extensin posterior del sistema donde se agregue una nueva subclase
que apoye las mismas responsabilidades definidas por la superclase pero sobrescrita de manera correspondiente.
Cuanto mayor sea el nmero de casos concretos que puedan extenderse a partir de una funcionalidad abstracta,
mayor ser la probabilidad de que la abstraccin sobreviva las pruebas del tiempo y mejoras del software. Se
necesita solo una responsabilidad para definir una superclase abstracta, pero se necesita por lo menos dos subclases
antes de esperar disear una abstraccin general til. Si no se tiene o no se prev por lo menos dos casos, no se debe
21
perder tiempo en construir la abstraccin. Probablemente no se pueda disear funcionalidad apropiada general sin
varios ejemplos concretos que sirvan de gua.
Si se considera que las clases abstractas definen responsabilidades de manera independiente de su implementacin,
stas no deben heredar de clases concretas, las cuales dependen normalmente de la implementacin. Si el diseo
actual considera tal herencia, se puede resolver el problema haciendo otra clase abstracta de la cual ambas clases, la
concreta y la abstracta, puedan heredar su comportamiento comn. Sin embargo, las clases concretas tambin
pueden refinarse para que otras clases concretas puedan heredar de ellas.
No se debe exagerar con la herencia, una subclase debe heredar de una superclase slo si la subclase aprovecha
todas las responsabilidades definidas en la superclase y no de manera parcial.
Existe un nmero de relaciones especiales que es importante resaltar en las jerarquas de herencia cuando stas son
apropiadas. Cuando una clase parece ser un tipo de otra clase, generalmente esto corresponde a una relacin
subclase-superclase. Tal relacin a menudo se ve por el hecho de que ambas clases comparten un mismo atributo.
Cada atributo implica una responsabilidad particular o un conjunto de responsabilidades. La generacin de jerarqus
de clases de acuerdo a atributos especficos implica que algn comportamiento o informacin es comn a todas estas
clases. Todas las clases que son un tipo dealguna otra clase, comparten responsabilidades permitiendo asignar
responsabilidades a superclases. La asignacin de una responsabilidad a una superclase puede ser bastante ventajosa,
ya que de esta manera la responsabilidad se asigna una sla vez, para ser luego heredada por todas las subclases. Las
responsabilidades asignadas a la superclase pueden ser compartidas entre las subclases, e incluso pueden servir
como base para el polimorfismo cuando una subclase sobrescribe las responsabilidades de su supercalse.
Tambin se puede examinar las relaciones entre clases por analoga. Si una clase tiene una relacin con otra clase,
entonces estas clases comparten las mismas responsabilidades, o responsabilidades anlogas. Quizs ambas clases
son tipos de una superclase todava no identificada. Cuando varias clases parecen ser anlogas, generalmente
comparten una superclase comn. Tal relacin a menudo se ve por el hecho que las clases tienen algunas
responsabilidades comunes. Tal relacin ayuda a identificar una superclase que falta, y asignar las responsabilidades
comunes a la superclase.
En este etapa se debe revisar las tarjetas de clases y clasificar cada clase segn si es concreta o abstracta. Se debe
adems agregar tarjetas para las superclases (abstractas o concretas) segn sea necesario y reasignar
responsabilidades para corresponder al nuevo diseo. Mediante la reasignacin de responsabilidades se busca
producir jerarquas de clases que puedan reutilizarse y extenderse mas fcilmente.
A continuacin se describen las jerarquas de herencia para el Sistema de Reservaciones en base a los casos de uso
RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. En la Figura 8.3 se muestra la jerarqua de herencia para las
clases del mdulo de registro a partir de una superclase general llamada Pagina y dos superclases particulares
llamadas PagRegUsuario y PagRegTarjeta, respectivamente.
PaginaPrincipal
(from principal)
Pagina
(from usuario)
(from interfaceUsuario)
PaginaRegUsuario
PaginaServicio
(from usuario)
(from servicios)
PaginaCrearRegUsuario
(from usuario)
PaginaRegTarjeta
(from tarjeta)
PaginaCrearRegTarjeta
(from tarjeta)
PaginaObtenerRegTarjeta
(from tarjeta)
Figura 8.3 El diagrama muestra la jerarqua de clases para el mdulo de registro a partir de la clase
Pagina.
En la Figura 8.4 se muestra la jearqua de herencia para el mdulo de registro a partir de una superclase general
llamada Manejador.
22
Manejador
(from principal)
ManejadorPrincipal
(from principal)
(from tarjeta)
ManejadorServicio
(from servicios)
(from usuario)
Figura 8.4 El diagrama muestra la jerarqua de clases para el mdulo de registro a partir de la clase Manejador.
En la Figura 8.5 se muestra la jearqua de herencia para el mdulo de registro a partir de una superclase general
llamada Datos.
Datos
(from dominio)
RegistroUsuario
(from usuario)
RegistroTarjeta
(from tarjeta)
Figura 8.5 El diagrama muestra la jerarqua de clases para el mdulo de registro a partir de la clase Datos.
Ntese en las siguientes secciones cmo la herencia reduce el nmero de responsabilidades y colaboraciones en el
sistema. Una vez modificado el diseo se debe modificar las tarjetas para corresponder a las jerarquas. Esto se hace
agregando la informacin de subclases y superclases, adems de la especificacin de si la clase es concreta o
abstracta.
InterfaceUsuario
A partir de la Tabla 8.22 se generan las colaboraciones para la clase InterfaceUsuario, como se muestra en la Tabla
8.36. Se reducen de manera radical las responsabilidades y colaboraciones de la clase InterfaceUsuario a partir de
los aspectos comunes de stas. En el caso particular de las pantallas, utilizando una nueva clase Pagina de la cual
hereden el resto de las clases correspondientes a pantallas, se reduce de gran manera las responsabilidades de
InterfaceUsuario. Aqu aprovechamos que enviar eventos, como validarRegUsuario, pueden corresponder a
parmetros de una colaboracin por lo cual pueden ser eliminados como responsabilidades distintas y en su lugar
utilizar una responsabilidad ms genrica llamada enviarEvento.
Propiedades: Concreta
Superclase:
Subclase:
inicializar
ManejadorPrincipal
enviarEvento
Pagina
desplegarPagina
Pagina
informar
Tabla 8.36. Tarjeta para la clase InterfaceUusario con responsabilidades, colaboraciones y jerarquas
identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
Para poder reducir el nmero de responsabilidades y colaboraciones en InterfaceUsuario es necesario crear la
superclase Pagina antes mencionada, la cual se muestra en la Tabla 8.37.
Clase: Pagina
Propiedades: Abstracta
Superclase:
23
Subclase: PaginaPrincipal, PaginaServicio, PaginaRegUsuario, PaginaRegTarjeta

desplegarPagina
manejarEvento
Tabla 8.37. Tarjeta para la superclase clase Pagina con responsabilidades, colaboraciones y jerarquas
Principal
De manera similar a la incorporacin de la clase Pagina, se agrega una nueva superclase Manejador que generaliza
a los diferentes manejadores, como se muestra en la Tabla 8.38.
Clase: Manejador
Mdulo: Principal
Superclase:
Subclase: ManejadorPrincipal, ManejadorServicios, ManejadorRegistroUsuario, ManejadorRegistroTarjeta
desplegarPagina
InterfaceUsuario, Pagina
Tabla 8.38. Tarjeta para la clase Manejador con responsabilidades, colaboraciones y jerarquas identificadas de
los diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
A partir de la Tabla 8.23 se generan las jerarquas para la clase ManejadorPrincipal, como se muestra en la Tabla
8.39.
Mdulo: Principal
Superclase: Manejador
Subclase:
desplegarPaginaPrincipal
InterfaceUsuario, PaginaPrincipal
ofrecerServicio
ManejadorServicio
crearRegUsuario
validarRegUsuario
Tabla 8.39. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones y jerarquas
A partir de la Tabla 8.24 se generan las jerarquas para la clase PaginaPrincipal, como se muestra en la Tabla 8.40.
Mdulo: Principal
Superclase: Pagina
Subclase:
validarRegUsuario
ManejadorPrincipal
crearRegUsuario
ManejadorPrincipal
Tabla 8.40. Tarjeta para la clase PaginaPrincipal con responsabilidades, colaboraciones y jerarquas
Dominio
De manera similar a la incorporacin de la clase Pagina y la clase Manejador, se puede agregar una nueva
superclase Datos que generaliza a las diferentes clases entidad, en este caso RegistroUsuario y RegistroTarjeta,
como se muestra en la Tabla 8.41. La idea de tener una superclase de cada estereotipo es muy til ya que se
generalizan los aspectos comunes de cada grupo de stas.
Clase: Datos
Mdulo: Dominio
Superclase:
Subclase: RegistroUsuario, RegistroTarjeta

Tabla 8.41. Tarjeta para la clase Datos con responsabilidades, colaboraciones y jerarquas identificadas de las
diversas clases entidad para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
Registro
Usuario
A partir de la Tabla 8.25 se generan las jerarquas para la clase ManejadoRegistroUsuario, como se muestra en la
Tabla 8.42.
Subclase:
desplegarPaginaCrearRegUsuario
InterfaceUsuario, PaginaCrearRegUsuario
escribir
leer
desplegarPaginaObtenerRegUsuario
InterfaceUsuario, PaginaObtenerRegUsuario
eliminar
validar
Tabla 8.42. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones y jerarquas
identificadas de los casos de uso RegistrarUsuario y ValidarUsuario.
Se agrega la superclase PaginaRegUsuario antes mencionada, la cual se muestra en la Tabla 8.43.
Clase: PaginaRegUsuario
Superclase: Pagina
Subclase: PaginaCrearRegUsuario, PaginaObtenerRegUsuario
desplegarPagina
manejarEvento
Tabla 8.43. Tarjeta para la clase PaginaRegUsuario con la jerarqua identificadas de las pginas de registro de
usuario para el caso de uso RegistrarUsuario.
A partir de la Tabla 8.26 se generan las jerarquas para la clase PaginaCrearRegUsuario, como se muestra en la
Tabla 8.44.
Superclase: Pagina
Subclase:
desplegar
RegistroUsuario
crearRegUsuario
ManejadorRegistroUsuario, RegistroUsuario
crearRegTarjeta
ManejadorRegistroTarjeta, RegistroTarjeta
Tabla 8.44. Tarjeta para la clase PaginaCrearRegUsuario con responsabilidades, colaboraciones y jerarquas
identificadas del caso de uso RegistrarUsuario.
A partir de la Tabla 8.27 se generan las jerarquas para la clase PaginaObtenerRegUsuario, como se muestra en la
Tabla 8.45.
24
25
Superclase: Pagina
Subclase:
desplegar
RegistroUsuario
actualizarRegUsuario
eliminarRegUsuario
crearRegTarjeta
obtenerRegUsuario
Tabla 8.45. Tarjeta para la clase PaginaCrearRegUsuario con responsabilidades, colaboraciones y jerarquas
identificadas del caso de uso RegistrarUsuario.
A partir de la Tabla 8.28 se generan las jerarquas para la clase RegistroUsuario, como se muestra en la Tabla 8.46.
Ntese que RegistroUsuario es una subclase de la recin introducida clase Datos.
Superclase: Datos
Subclase:
Tabla 8.46. Tarjeta para la clase RegistroUsuario con responsabilidades, colaboraciones y jerarquas de
actualizar y consultar informacin de registro para el caso de uso RegistrarUsuario.
Tarjeta
A partir de la Tabla 8.29 se generan las jerarquas para la clase ManejadoRegistroTarjeta, como se muestra en la
Tabla 8.47.
Subclase:
desplegarPaginaCrearRegTarjeta
InterfaceUsuario, PaginaCrearRegTarjeta
escribir
leer
desplegarPaginaObtenerRegTarjeta
InterfaceUsuario, PaginaObtenerRegTarjeta
actualizar
eliminar
Tabla 8.47. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones y jerarquas
identificadas del caso de uso RegistrarTarjeta.
Se agrega la superclase PaginaRegTarjeta antes mencionada, la cual se muestra en la Tabla 8.48.
Clase: PaginaRegTarjeta
Mdulo: Registro. Tarjeta
Superclase: Pagina
Subclase: PaginaCrearRegTarjeta, PaginaObtenerRegTarjeta
desplegarPagina
26
manejarEvento
Tabla 8.48. Tarjeta para la clase PaginaRegTarjeta con la jerarqua identificadas de las pginas de registro de
tarjeta para el caso de uso RegistrarTarjeta.
A partir de la Tabla 8.30 se generan las jerarquas para la clase PaginaCrearRegTarjeta, como se muestra en la
Tabla 8.49.
Superclase: Pagina
Subclase:
desplegar
RegistroTarjeta
crearRegTarjeta
Tabla 8.49. Tarjeta para la clase PaginaCrearRegTarjeta con responsabilidades, colaboraciones y jerarquas
A partir de la Tabla 8.31 se generan las jerarquas para la clase PaginaObtenerRegTarjeta, como se muestra en la
Tabla 8.50.
Superclase: Pagina
Subclase:
desplegar
RegistroTarjeta
actualizarRegTarjeta
eliminarRegTarjeta
Tabla 8.50. Tarjeta para la clase PaginaCrearRegTarjeta con responsabilidades, colaboraciones y jerarquas
A partir de la Tabla 8.32 se generan las jerarquas para la clase RegistroTarjeta, como se muestra en la Tabla 8.51.
Ntese que RegistroTarjeta es una subclase de la recin introducida clase Datos.
Superclase: Datos
Subclase:
Tabla 8.51. Tarjeta para la clase RegistroTarjeta con responsabilidades, colaboraciones y jerarquas de
actualizar y consultar informacin de registro para el caso de uso RegistrarTarjeta.
A partir de la Tabla 8.33 se generan las jerarquas para la clase InterfaceBaseDatosRegistro, como se muestra en la
Tabla 8.52.
Mdulo: Registro.InterfaceDB
Superclase:
Subclase:
leer
escribir
actualizar
27
eliminar
validar
leer
escribir
actualizar
eliminar
Tabla 8.52. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades, colaboraciones y jerarquas
de escribir y leer informacin de registro de usuario y registro de tarjeta para los casos de uso RegistrarUsuario,
Servicios
A partir de la Tabla 8.34 se generan las jerarquas para la clase ManejadorServicio, como se muestra en la Tabla
8.53.
Mdulo: Servicios
Subclase:
desplegarPaginaServicio
InterfaceUsuario, PaginaServicio
obtenerRegUsuario
Tabla 8.53. Tarjeta para la clase ManejadorServicio con responsabilidades, colaboraciones y jerarquas a partir
de los casos de uso RegistrarUsuario y RegistrarTarjeta.
A partir de la Tabla 8.35 se generan las jerarquas para la clase PaginaServicio, como se muestra en la Tabla 8.54.
Mdulo: Servicios
Superclase: Pagina
Subclase:
obtenerRegUsuario
ManejadorServicio
Tabla 8.54. Tarjeta para la clase PaginaServicio con responsabilidades, colaboraciones y jerarquas a partir de
los casos de uso RegistrarUsuario y RegistrarTarjeta.
Contratos
Un contrato es una mecanismo de diseo para agrupar las responsabilidades de una clase que tienen relaciones entre
si, sirviendo como indicadores de los diversos servicios provistos por cada clase. El contrato es un elemento de
abstraccin adicional en el manejo de la complejidad del diseo, ayudando en la asignacin y reasignacin de
responsabilidades, donde grupos de responsabilidades funcionalmente relacionadas deben ser comunes a un mismo
contrato. A diferencia de los contratos, las responsabilidades representan una visin ms detallada de los servicios
provistos por la clase.
El contrato no es simplemente otro nombre para responsabilidad, ya que la responsabilidad corresponde a una accin
especfica, mientras que un contrato define un conjunto de responsabilidades cercanas una de la otra.
Cada responsabilidad pueder ser parte de un slo contrato, aunque no tiene que ser necesariamente parte de algn
contrato. Esto ocurre cuando las responsabilidades representan comportamiento que una clase debe tener, pero que
son privadas a los propios objetos. En general, una clase puede apoyar uno o ms contratos, aunque a menudo una
clase con varias responsabilidades apoya un slo contrato.
Un contrato entre dos clases representa una lista de servicios que una instancia de una clase puede solicitar de una
instancia de otra clase. Todos los servicios especificados en un contrato particular son la responsabilidad del
servidor para ese contrato. Las responsabilidades correspondientes al contrato deben ser ofrecidas pblicamente. Por
lo tanto, para un mejor manejo de la complejidad del sistema, se debe posponer la definicin de los aspecto privados
de una clase y concentrrse inicialmente en las responsabilidades pblicas.
En general, un contrato entre un cliente y un servidor no especifica cmo se hacen las cosas, solo qu se hace. Los
contratos especifican quien colabora con quien, y qu se espera de la colaboracin. El contrato cliente-servidor
28
divide los objetos en dos categora aquellos que proveen servicios (servidores), y aquellos que piden servicios
(clientes). De tal manera, un contrato es una lista de pedidos que le hace un cliente a un servidor. Ambos deben
satisfacer el contrato, el cliente haciendo slo los pedidos que el contrato especifica, y el servidor respondiendo
apropiadamente a estos pedidos.
Como se mencion anteriormente, cliente y servidor son roles que juegan los objetos en cierto momento y no
caractersticas inherentes de los propios objetos. Un objeto puede tomar el rol de cliente o servidor en relacin a
otros objetos. Por ejemplo, los componentes casi siempre juegan el rol de servidores, ya que satisfacen una
responsabilidad especfica. Raramente los componentes necesitaran pedir servicios del propio sistema para poder
satisfacer esas responsabilidades. Por el contrario, los marcos (frameworks) generalmente toman ambos roles, ya
que se integran a las aplicaciones para solicitar y proveer funcionalidad.
Se puede determinar qu responsabilidades pertenecen a cuales contratos siguiendo ciertos criterios. Una forma de
encontrar responsabilidades relacionadas es buscar responsabilidades que sern usadas por el mismo cliente. Aunque
es posible que algunas clases den servicio a diferentes clientes mediante diversas responsabilidades, es ms
significativo cuando dos o ms responsabilidades de una clase dan servicio a los mismos clientes. En tal caso sera
innecesario definir distintos contratos. En su lugar, se puede abstraer de las responsabilidades especficas un slo
contrato, satisfaciendo la responsabilidad general.
Si una clase define un contrato que tiene relativamente poco en comn con el resto de los contratos definidos por esa
clase, este contrato debe ser movido a una clase diferente, usualmente una superclase o subclase. De tal manera, se
puede refinar las jerarquas de clases maximizando la cohesin de contratos para cada clase. Maximizando la
cohesin tender a minimizar el nmero de contratos apoyados por cada clase. Esto es algo deseable, ya que cuanto
menos contratos existan, se lograr un sistema ms fcil de comprender. En general, la mejor manera de reducir el
nmero de contratos es buscar responsabilidades similares que puedan generalizarse. Esto tambin resultar en
jerarquas de clases ms extensibles.
Un buen diseo hace un balance entre clases pequeas con pocos contratos, fciles de comprender y reutilizar, con
un nmero reducido de clases ms complejas cuyas relaciones entre ellas se puede comprender mas fcilmente.
Una tcnica para definir contratos es comenzar definiendo primero los contratos de las clases ms arriba en las
jerarquas. Posteriormente, se definen nuevos contratos para las subclases que agregan nueva funcionalidad. Se debe
examinar las responsabilidades para cada subclase y determinar si estas representan nueva funcionalidad o si son
simplemente maneras especficas de expresar responsabilidades heredadas, en cuyo caso seran parte del contrato
heredado.
En cada tarjeta de clase se divide la seccin de responsabilidades en dos. En la parte superior se especifica una
seccin para los contratos, mientras que en la parte inferior se especifica una seccin para las responsabilidades
privadas. Cada contrato debe incluir un nombre y un nmero de contrato. Se debe listar cada contrato para el cual
esta clase es un servidor. Tambin se debe listar contratos heredados, e indicar la clase de la cual se heredan, aunque
no hay necesidad de repetir los detalles del contrato. Para cada contrato, se debe listar las responsabilidades de la
clase en la cual se basan, asignando cada responsabilidad al contrato correspondiente.
Si la responsabilidad requiere colaborar con una clase que define varios contratos, se debe indicar el nmero del
contrato correspondiente entre parntesis en la columna de la colaboracin, para as simplificar el seguimiento de
qu responsabilidad se relaciona con qu contrato.
En esta seccin se describen los contratos para el Sistema de Reservaciones, en base a los casos de uso
InterfaceUsuario
A partir de la Tabla 8.36 se generan los contratos para la clase InterfaceUsuario, como se muestra en la Tabla 8.55.
Superclase:
Subclase:
Contratos
1. Desplegar Pagina
desplegarPagina
Pgina (1)
Responsablidades Privadas
inicializar
ManejadorPrincipal (2)
29
manejarEvento
Manejador (1)
informar
Tabla 8.55. Tarjeta para la clase InterfaceUusario con responsabilidades, colaboraciones, jerarquas y contratos
A partir de la Tabla 8.37 se generan los contratos para la clase Pagina, como se muestra en la Tabla 8.56.
Clase: Pagina
Superclase:
Contratos
1. Desplegar Pgina
desplegarPagina
Tabla 8.56. Tarjeta para la superclase clase Pagina con responsabilidades, colaboraciones, jerarquas y
contratos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
Principal
A partir de la Tabla 8.38 se generan los contratos para la clase Manejador, como se muestra en la Tabla 8.57.
Clase: Manejador
Mdulo: Principal
Superclase:
Contratos
1. Manejar Evento
manejarEvento
desplegarPagina
InterfaceUsuario (1), Pagina (1)
Tabla 8.57. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquas y contratos
identificadas de los diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario y
RegistrarTarjeta.
A partir de la Tabla 8.39 se generan los contratos para la clase ManejadorPrincipal, como se muestra en la Tabla
8.58.
Mdulo: Principal
Subclase:
Contratos
1. Manejar Evento
manejarEvento
2. Inicializar
inicializar
PaginaPrincipal (1)
ofrecerServicio
ManejadorServicio (2)
crearRegUsuario
ManejadorRegistroUsuario (2)
validarRegUsuario
InterfaceUsuario (1), PaginaPrincipal (1)
Tabla 8.58. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones, jerarquas y
A partir de la Tabla 8.40 se generan los contratos para la clase PaginaPrincipal, como se muestra en la Tabla 8.59.
Mdulo: Principal
Superclase: Pagina
Subclase:
Contratos
1. Desplegar Pgina
desplegarPagina
Tabla 8.59. Tarjeta para la clase PaginaPrincipal con responsabilidades, colaboraciones, jerarquas y contratos
Dominio
A partir de la Tabla 8.41 se generan los contratos para la clase Datos, como se muestra en la Tabla 8.60.
Clase: Datos
Mdulo: Dominio
Superclase:
Contratos
1. Actualizar y Consultar Informacin
Tabla 8.60. Tarjeta para la clase Datos con responsabilidades, colaboraciones y jerarquas identificadas de las
diversas clases entidad para los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
Registro
Usuario
A partir de la Tabla 8.42 se generan los contratos para la clase ManejadoRegistroUsuario, como se muestra en la
Tabla 8.61.
Subclase:
Contratos
1. Manejar Evento
manejarEvento
2. Crear Registro Usuario
crear
3. Validar Registro Usuario
validar
RegistroUsuario (1), InterfaceBaseDatosRegistro (2)
4. Obtener Registro Usuario
obtener
Responsabilidades Privadas
escribir
leer
eliminar
30
31
crearRegTarjeta
ManejadorRegistroTarjeta (2), RegistroTarjeta (1)
InterfaceUsuario (1), PaginaCrearRegUsuario (1)
InterfaceUsuario (1), PaginaObtenerRegUsuario (1)
Tabla 8.61. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquas y
contratos identificadas de los casos de uso RegistrarUsuario y ValidarUsuario.
A partir de la Tabla 8.43 se generan los contratos para la clase PaginaRegUsuario, como se muestra en la Tabla
8.62.
Clase: PaginaRegUsuario
Superclase: Pagina
Subclase: PaginaCrearRegUsuario, PaginaObtenerRegUsuario
Contratos
1. Desplegar Pagina
desplegar
RegistroUsuario (1)
Tabla 8.62. Tarjeta para la clase PaginaRegUsuario con responsabilidades, colaboraciones, jerarquas y
contratos identificadas del caso de uso RegistrarUsuario.
A partir de la Tabla 8.44 se generan los contratos para la clase PaginaCrearRegUsuario, como se muestra en la
Tabla 8.63.
Superclase: Pagina
Subclase:
Contratos
1. Desplegar Pagina
desplegar
RegistroUsuario (1)
Tabla 8.63. Tarjeta para la clase PaginaCrearRegUsuario con responsabilidades, colaboraciones, jerarquas y
A partir de la Tabla 8.45 se generan los contratos para la clase PaginaObtenerRegUsuario, como se muestra en la
Tabla 8.64.
Superclase: Pagina
Subclase:
Contratos
1. Desplegar Pagina
desplegar
RegistroUsuario (1)
Tabla 8.64. Tarjeta para la clase PaginaCrearRegUsuario con responsabilidades, colaboraciones, jerarquas y
A partir de la Tabla 8.46 se generan los contratos para la clase RegistroUsuario, como se muestra en la Tabla 8.65.
Superclase: Datos
Subclase:
Contratos
32

Tabla 8.65. Tarjeta para la clase RegistroUsuario con responsabilidades, colaboraciones, jerarquas y contratos
de actualizar y consultar informacin de registro para el caso de uso RegistrarUsuario.
Tarjeta
A partir de la Tabla 8.47 se generan los contratos para la clase ManejadoRegistroTarjeta, como se muestra en la
Tabla 8.66.
Subclase:
Contratos
1. Manejar Evento
manejarEvento
2. Crear Registro Tarjeta
crear
3. Obtener Registro Tarjeta
obtener
escribir
RegistroTarjeta (1), InterfaceBaseDatosRegistro (3)
leer
actualizar
eliminar
InterfaceUsuario (1), PaginaCrearRegTarjeta (1)
InterfaceUsuario (1), PaginaObtenerRegTarjeta (1)
Tabla 8.66. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones, jerarquas y
contratos identificadas del caso de uso RegistrarTarjeta.
A partir de la Tabla 8.48 se generan los contratos para la clase PaginaRegTarjeta, como se muestra en la Tabla 8.67.
Clase: PaginaRegTarjeta
Mdulo: Registro. Tarjeta
Superclase: Pagina
Subclase: PaginaCrearRegTarjeta, PaginaObtenerRegTarjeta
Contratos
1. Desplegar Pagina
desplegarPagina
RegistroTarjeta (1)
Tabla 8.67. Tarjeta para la clase PaginaRegTarjeta con responsabilidades, colaboraciones, jerarquas y
A partir de la Tabla 8.49 se generan los contratos para la clase PaginaCrearRegTarjeta, como se muestra en la Tabla
8.68.
Superclase: Pagina
Subclase:
Contratos
1. Desplegar Pagina
desplegar
RegistroTarjeta (1)
Tabla 8.68. Tarjeta para la clase PaginaCrearRegTarjeta con responsabilidades, colaboraciones, jerarquas y
A partir de la Tabla 8.50 se generan los contratos para la clase PaginaObtenerRegTarjeta, como se muestra en la
Tabla 8.69.
Superclase: Pagina
Subclase:
Contratos
1. Desplegar Pagina
desplegar
RegistroTarjeta (1)
Tabla 8.69. Tarjeta para la clase PaginaCrearRegTarjeta con responsabilidades, colaboraciones, jerarquas y
A partir de la Tabla 8.51 se generan los contratos para la clase RegistroTarjeta, como se muestra en la Tabla 8.70.
Superclase: Datos
Subclase:
Contratos
Tabla 8.70. Tarjeta para la clase RegistroTarjeta con responsabilidades, colaboraciones, jerarquas y contratos
de actualizar y consultar informacin de registro para el caso de uso RegistrarTarjeta.
A partir de la Tabla 8.52 se generan los contratos para la clase InterfaceBaseDatosRegistro, como se muestra en la
Tabla 8.71.
Superclase:
Subclase:
Contratos
1. Registrar Usuario
leer
RegistroUsuario (1), BaseDatosRegistro
escribir
actualizar
eliminar
validar
3. Regitrar Tarjeta Usuario
leer
RegistroTarjeta (1), BaseDatosRegistro
escribir
actualizar
33
34
eliminar
Tabla 8.71. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades, colaboraciones, jerarquas
y contratos de escribir y leer informacin de registro de usuario y registro de tarjeta para los casos de uso
Servicios
A partir de la Tabla 8.53 se generan los contratos para la clase ManejadorServicio, como se muestra en la Tabla
8.72.
Mdulo: Servicios
Subclase:
Contratos
1. Manejar Evento
manejarEvento
2. Inicializar
ofrecerServicio
obtenerRegUsuario
InterfaceUsuario (1), PaginaServicio (1)
Tabla 8.72. Tarjeta para la clase ManejadorServicio con responsabilidades, colaboraciones, jerarquas y
contratos a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta.
A partir de la Tabla 8.54 se generan los contratos para la clase PaginaServicio, como se muestra en la Tabla 8.73.
Mdulo: Servicios
Superclase: Pagina
Subclase:
Contratos
1. Desplegar Pgina
desplegarPagina
Tabla 8.73. Tarjeta para la clase PaginaServicio con responsabilidades, colaboraciones, jerarquas y contratos a
partir de los casos de uso RegistrarUsuario y RegistrarTarjeta.
Subsistemas
Como se puede apreciar en lo que hemos hecho hasta ahora en el diseo, la complejidad del sistema aumenta a
medidad que se incorporan nuevos detalles. Para lograr un mejor manejo de esta complejidad introducimos el
concepto de subsistemas, el cual permite dividir el sistema completo en diversas partes siguiendo la frase de divide
y conquista.
Los subsistemas organizan grupos de objetos dentro de la arquitectura de diseo en mini-sistemas, apoyando una
visin jerrquica del sistema mediante mltiples niveles de abstracin, donde el sistema completo se compone de
mltiples subsistemas y donde cada subsistema puede ser subdivido en subsistemas adicionales o ser definido en
trminos de los objetos finales.
La organizacin en subsistemas se hace a partir de las colaboraciones identificadas entre los objetos para apoyar el
conjuntos de contratos del sistema completo. Externamente, los subsistemas son mecanismos de encapsulamiento,
vistos como cajas negras, donde sus objetos cooperan para proveer una unidad de funcionalidad claramente
delimitada por el subsistema. Internamente, los subsistemas revelan tener estructuras complejas, con clases
colaborando entre si para satisfacer sus distintas responsabilidades contribuyendo al objetivo general del subsistema,
o sea, satisfacer sus responsabilidades.
El objetivo es lograr un fuerte acoplamiento funcional dentro del subsistema y un dbil acoplamiento entre
subsistemas, en otras palabras, debe haber el mnimo posible de comunicacin entre los diferentes subsistemas.
35
Un subsistema bien diseado tiene pocas clases o subsistemas que directamente apoyan contratos, y un nmero
mayor de colaboraciones entre clases internas y subsistemas.
Es importante distinguir entre el concepto de mdulo y subsistema. Un mdulo agrupa clases, correspondiente a
bibliotecas, o sea, organizaciones definidas para almacenar y facilitar el acceso a las clases. Esto es similar al
concepto de directorios en una computadora. Son estructuras completamente estticas, sin ningn efecto durante la
ejecucin del sistema. Por otro lado, el subsistema agrupa objetos, siendo una abstraccin dinmica ya que los
objetos que se ejecutan dentro de un subsistema son instancias de clases que deben existir forzosamente en un
mdulo.
El criterio ms importante para la divisin en subsistemas es predecir como afectarn los cambios en el sistema. Los
subsistemas debern mantener una buena correspondencia con los casos de uso, de manera que cualquier cambios
causado por modificaciones en la funcionalidad del sistema pueda ser rastreado a los subsistemas afectados. Esto se
hace siguiendo los casos de uso en orden de importancia.
Cabe resaltar, que los subsistemas no existen durante la ejecucin de la aplicacin, son puramente conceptuales,
obviamente afectando el diseo del sistema. Sin embargo, es comn definir mdulos con clases que sern utilizadas
por ciertos subsistemas particulares, como son las clases de control y por lo general las de interface. Sin embargo,
las clases entidad tienden a ser utilziadas por mltiples subsistemas.
Si consideramos que la mayor complejidad en el diseo radica en las relaciones entre objetos (a travs de sus
colaboraciones), la meta es reducir o al menos manejar de mejor manera estas relaciones. Un enfoque es definir los
subsistemas de manera que, aunque el nmero total de relaciones sea el mismo, las relaciones estarn organizadas
pro grupos (clusters). Si se observan que cierto grupo de objetos estn muy relacionados entre si pero no tanto con
otro grupo de objetos, esto sirve de base para la organizacin de los subsistemas y la reduccin de la complejidad.
Por otro lado, gracias a los subsistemas, se puede trabajar en diferentes partes del sistema en paralelo mediante su
asignacin a mltiples diseadores.
Como parte de la identificacin de subsistemas, se define un protocolo de comunicacin para cada subsistema, el
cual restringe las posibles interacciones entre subsistemas. Esto se logra exportando o haciendo pblicos slo ciertos
objetos del subsistema. La interface de estos objetos, sus servicios, definen la interface del subsistema completo.
Como unidades de encapsulamiento, si se incluyen, los subsistemas deben incluir completos o no ser incluidos, de
manera que un sistema pueda ser ofrecido con o sin ciertos subsistemas. Dada la dependencia entre subsistemas, si
se incluye un subsistema, se debe tambin entregar el subsistema del cual depende.
Los subsistemas, al igual que clases, apoyan contratos. Para determinar los contratos apoyados por un subsistema, se
tiene que encontrar todas las clases que proveen servicios a clientes fuera del subsistema. Al menos inicialmente,
estos servicios correspondern a los contratos apoyados por el subsistema. Al igual que se hizo para las clases, se
debe describir los contratos ofrecidos por cada subsistema. Dado que los subsistemas son solamente entidades
conceptuales, estos no pueden directamente satisfacer ninguno de sus contratos. En su lugar, los subsistemas delegan
cada contrato a una clase interna que lo satisface.
La divisin de subsistemas es normalmente hecha al final del anlisis, cuando est clara la arquitectura. En
proyectos grandes a menudo se debe hacer esto temprano, incluso antes de que se haya desarrollado el modelo de
anlisis. En general existen mltiples criterios para la divisin de subsistemas, por ejemplo, diferentes grupos de
desarrollo tienen diferente competencia o recursos y puede ser deseable distribuir el trabajo de manera
correspondiente o los grupos tambin pueden estar geogrficamente separados. Cabe resaltar que un componente
externo al sistema puede ser considerado como un subsistema.
Las guas bsicas para simplificar los patrones de colaboracin son los siguientes:
? ? Minimizar el nmero de colaboraciones que una clase tiene con otras clases o subsistemas. Las clases deben
colaborar con el menor nmero posible de clases y subsistemas. Menor nmero de colaboraciones significa que
la clase tiene menor probabilidad de ser afectadas por cambios en el resto del sistema. Se puede reasignar
responsabilidades o expandir el conocimiento de otra clase para crear un menor nmero de colaboraciones. Una
forma para lograr esto es centralizar las comunicaciones fluyendo a un subsistema. Se puede crear una nueva
clase en el subsistema para ser el intermediario principal, o utilizando una ya existente.
? ? Minimizar el nmero de clases y subsistemas a los cuales un subsistema delega. En un sistema bien diseado, el
nmero de clases o subsistemas que tienen contratos delegados a ellos debe mantenerse en el mnimo. Esto va
de la mano con la idea de centralizar las comunicaciones, ya que si una clase o subsistema sirve como el
intermediario de comunicacin para un subsistema, los contratos son delegados solamente al intermediario.
? ? Minimizar el nmero de contratos diferentes apoyados por una clase o subsistema. Demasiados contratos para
un subsistema puede ser un signo que demasiada inteligencia de la aplicacin se concentra en el subsistema.
36
Tarjetas de Subsistemas
Los subsistemas se describen en tarjetas de subsistemas, un subsistema por tarjeta. Cada tarjeta incluye un nombre
en la primera lnea y dos columnas, como se puede ver en la Tabla 8.74.
Subsistema: Nombre del Subsistema
Tabla 8.74. Tarjeta para subsistemas.

En la columna izquiera se muestran los contratos que se ofrecen externos al subsistema, mientras que en la columna
derecha, al lado de cada contrato se escribe la clase interna que ofrece el servicio, en otras palabras, a quien se le
delega el contrato. Por ejemplo, en la Tabla 8.75 se muestra el diseo inicial para el subsistema InterfaceUsuario.
Subsistema: Subsistema InterfaceUsuario
1. ManejarEvento
InterfaceUsuario (1)
Tabla 8.75. Tarjeta para el subsistema InterfaceUsuario.

Al incluir los subsistemas es necesario modificar las tarjetas de clase para hacer referencias a estos subsistemas y no
a las clases que stas encapsulan. Si una clase externa a un subsistema colabora con una clase dentro de un
subsistema, se debe cambiar esto a una colaboracin con el subsistema.
Diagramas de Colaboracin
Para analizar mejor el efecto de los subsistemas se utilizan los diagramas de colaboracin donde se despliega las
colaboraciones entre clases y subsistemas de forma grfica.
Como se ha visto, los responsabilidades de una clase se ofrecen como contratos de una clase servidor. Los contratos
se muestran como crculos externos a la clase a la cual pertenecen relacionada con la clase mediante una liga de
realizacin de interface, como se muestra en la Figura 8.6.
Nombre de la Clase
1.Nombre del Contrato
Figura 8.6 Diagrama de clase con contrato.

Se dibuja un crculo por contrato y se numeran los crculos con el nmero asignado al contrato correspondiente.
Las colaboraciones entre clases se representan por una flecha correspondiente a una asociacin de utilizacin del
cliente al contrato apoyado por el servidor, como se muestra en la Figura 8.7 (la flecha de la derecha proveniente de
Clase 2).
Clase 1
Clase 2
1. Contrato
Figura 8.7 Diagrama de colaboracin donde Clase 2 es cliente del Contrato 1 de Clase 1.
Si dos clases colaboran con un mismo contrato de otra clase, se dibuja las flechas al mismo crculo. Por el contrario,
se dibujan las flechas a crculos distintos correspondientes a diferentes contratos.
Los diagramas de colaboracin para aplicaciones moderadamente grandes pueden volverse grandes y complejas. Por
lo tanto, se puede ocultar informacin para simplificarlos ligeramente. Los subsistemas se muestran en el diagrama
de colaboracin dibujando rectngulos envolviendo las clases y contratos que las forman, como se ve en la Figura
8.8.
Nombre de la Clase
(Clase)
Subsistema

(Subsistema)
37
Figura 8.8 Diagrama de subsistema encapsulando clases y contratos.

El problema de la complejidad es evidente cuando uno se fija en el diagrama de colaboracin. El diagrama se vuelve
un espagueti. No se puede entender fcilmente y la aplicacin se vuelve imposible de mantener o modificar. Por lo
tanto la meta es simplificar los patrones de colaboracin.
Ntese que simplificando los patrones de colaboracin se traduce en la simplificacin del diagrama de colaboracin.
Subsistema de Reservaciones de Vuelo
A continuacin se describen los subsistemas para el Sistema de Reservaciones, en base a los casos de uso
RegistrarUsuario, ValidarUsuario y RegistrarTarjeta. En la Figura 8.9 se muestra los tres subsistemas ms
importantes y de ms alto nivel en el sistema de reservaciones: SubsistemaRegistro, SubsistemaServicios y
SubsistemaInterfaceUsuario.
<<subsis tema>>
subsistemaregistro
<<subsistema>>
subsistemaservicios
<<subsistema>>
subsistemainterfaceusuario
Figura 8.9 Subsistemas del sistema de reservaciones de vuelos.

Estos subsistemas sern descritos con mayor detalle a continuacin.
InterfaceUsuario
El SubsistemaInterfaceUsuario se muestra en la Tabla 8.76. Este subsistema se compone principalmente de la clase
InterfaceUsuario que a su vez sirve de servidor para el subsistema.
Subsistema: InterfaceUsuario
Clases: InterfaceUsuario
Contratos
Servidor
InterfaceUsuario (1)
1. Desplegar Pagina
Tabla 8.76. Tarjeta de subsistema para SubsistemaInterfaceUsuario mostrando sus contratos y servidores a
partir de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
El SubsistemaInterfaceUsuario se muestra grficamente en la Figura 8.10. Ntese como los contratos se muestran
como bolitas, el ms cercano a la clase InterfaceUsuario corresponde al contrato de esa misma clase, mientras que
el que aparece en el borde del subsistema es el correspondiente al propio subsistema.
<<Interface>>
InterfaceUsuario
(f ro m int erfaceU sua rio)
1.Interface
Usuario.DesplegarPagina
1.Subsistema.Interface
Subsistema InterfaceUsuario
Figura 8.10 Subsistema de interface de usuario.

Registro
El SubsistemaRegistro se muestra en la Tabla 8.77. Este subsistema se compone de las diversas clases de los
mdulos de Registro (Usuario, Tarjeta e InterfaceBD).
Subsistema: Registro
Clases: ManejadorRegistroUsuario, PaginaCrearRegUsuario, PaginaObtenerRegUsuario, RegistroUsuario,
ManejadorRegistroTarjeta, PaginaCrearRegTarjeta, PaginaObtenerRegTarjeta, RegistroTarjeta,
InterfaceBaseDatosRegistro
Contratos
Servidor
ManejadorRegistroUsuario (1), ManejadorRegistroTarjeta (1)
1. Manejar Evento
38
ManejadorRegistroTarjeta (3)
Tabla 8.77. Tarjeta de subsistema para SubsistemaRegistro mostrando sus contratos y servidores a partir de los
El SubsistemaRegistro se muestra grficamente en la Figura 8.11. Ntese nuevamente como los contratos se
muestran como bolitas, mostrando las ligas correspondientes entre el subsistema y los dos servidores.
Subsistema Registro
2.ManejadorRegistro
Usuario.CrearRegistroUsuario
2.SubsistemaRegistro.Crear
RegistroUsuario
3.ManejadorRegistro
Usuario.ValidarRegistroUsuario
3.SubsistemaRegistro.Validar
RegistroUsuario
4.ManejadorRegistro
Usuario.ObtenerRegistroUsuario
4.S ubsistemaRegistro. Obtener

RegistroUsuario
<<Control>>
(from usuario)
<<uses>>
<<uses>>
1.ManejadorRegistro
Usuario.ManejarEvento
2.ManejadorRegist ro
Tarjeta.CrearRegsitroTarjeta
1.Subsistema
Registro.ManejarEvento
3.ManejadorRegistroTarjet
aObtenerRegistroTarjeta
<<control>>
(from tarjeta)
1.Manejador
Registro
5.S ubsistemaRegistro. Obtener

RegistroTarjeta
Figura 8.11 Subsistema de registro.

Servicios
El SubsistemaServicios se muestra en la Tabla 8.78. Este subsistema se compone principalmente de la clase
ManejadorServicios. Ntese que el resto de los contratos y servidores del subsistema de servicios para el resto de su
funcionalidad se muestran en el apndice.
Subsistema: Servicios
Clases: ManejadorServicios, PaginaServicio
Contratos
Servidor
ManejadorServicios (1)
1. Manejar Evento
ManejadorServicios (2)
2. Inicializar
Tabla 8.78. Tarjeta de subsistema para SubsistemaServicios mostrando sus contratos y servidores a partir del
El SubsistemaServicio se muestra grficamente en la Figura 8.12. Ntese nuevamente como los contratos se
muestran como bolitas, mostrando las ligas correspondientes entre el subsistema y el servidor.
39
1.Subsistema
Servicios.ManejarEvento
<<Control>>
ManejadorServicio
(from servicios)
2.Subsistema
Servicios.Inicializar
Subsistema Servicios
Figura 8.12 Subsistema de servicios.

Principal
El sistema principal se muestra grficamente en la Figura 8.13. Este sistema integra los subsistemas anteriores
adems de la clase ManejadorPrincipal, mostrando las diferentes ligas entre los distintos elementos. Ntese
nuevamente como los contratos se muestran como bolitas, mostrando las ligas correspondientes entre subsistemas
y servidores.
Subsistema InterfaceUsuario
<<Interface>>
InterfaceUsuario
<<Control>>
<<uses>>
(from usuario)
1.Subsistema.Interface
(from subsistemainterfaceusuario)
<<uses>>
<<uses>>
<<us es>>
1.Subsis tema
Registro.ManejarEvento
(from subsistemaregistro)
<<uses>>
<<uses>>
2.Manejador
1.Manejador
Principal.Inicializar Principal.ManejarEvento <<uses>>
<<uses>>
<<control>>
(from tarjeta)
2.SubsistemaRegistro.Crear
RegistroUsuario
1.S ubsistema
Servicios.ManejarEvento
<<uses>>
(from subsistemaservicios)
<<uses>>
3.SubsistemaRegist ro.Validar
RegistroUsuario
<<uses>>
<<Control>>
ManejadorPrincipal
(from principal)
2.S ubsistema
Servicios.Inicializar
(from subsistemaservi ci os)
ManejadorPrincipal
<<Control>>
ManejadorServicio
<<uses>>
(from servicios)
4.SubsistemaRegistro.Obtener
RegistroUsuario
<<uses>>
Subsistema Servicios
5.SubsistemaRegistro.Obtener
Regist roTarjeta
Subsistema Registro
Figura 8.13 Subsistemas del sistema de reservaciones de vuelo.

Mdulos de Reservaciones de Vuelo
En esta seccin se muestra como los subsistemas afectan a los diversos mdulos descritos anteriormente. A
continuacin se describen las clases principales de los distintos mdulos segn la organizacin de subsistemas para
el Sistema de Reservaciones y en base a los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
InterfaceUsuario
La clase InterfaceUsuario se muestra en la Tabla 8.79. En este caso es idntica a la mostrada en la Tabla 8.54.
Superclase:
40
Subclase:
Contratos
1. Desplegar Pagina
desplegarPagina
Pgina (1)
inicializar
envarEvento
Manejador (1)
informar
Tabla 8.79. Tarjeta para la clase InterfaceUusario con responsabilidades, colaboraciones, jerarquas, contratos y
subsistemas identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
La descripcin de la clase Pagina se mantiene igual.
Principal
A partir de la Tabla 8.55 se actualizan los contratos segn subsistemas para la clase Manejador, como se muestra en
la Tabla 8.80.
Clase: Manejador
Mdulo: Principal
Superclase:
Contratos
1. Manejar Evento
manejarEvento
desplegarPagina
SubsistemasInterfaceUsuario (1), Pagina (1)
Tabla 8.80. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquas, contratos y
subsistemas identificadas de los diversos manejadores para los casos de uso RegistrarUsuario, ValidarUsuario
y RegistrarTarjeta.
A partir de la Tabla 8.57 se actualizan los contratos segn subsistemas para la clase ManejadorPrincipal, como se
Mdulo: Principal
Subclase:
Contratos
1. Manejar Evento
manejarEvento
2. Inicializar
inicializar
PaginaPrincipal (1)
ofrecerServicio
SubsistemaServicio (2)
crearRegUsuario
SubsistemaRegistro (2)
validarRegUsuario
SubsistemaInterfaceUsuario (1), PaginaPrincipal (1)
Tabla 8.81. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones, jerarquas,
contratos y subsistemas identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
La descripcin de la clase PaginaPrincipal se mantiene igual.
Dominio
La descripcin de la clase Datos se mantiene igual.
41
Registro
En el mdulo de Registro, compuesto de los mdulos Usuario, Tarjeta e InterfaceBD, slo se modifican las clases
de control pero no las de interface o entidad, como se ver a continuacin.
Usuario
A partir de la Tabla 8.60 se actualizan los contratos segn subsistemas para la clase ManejadoRegistroUsuario,
como se muestra en la Tabla 8.82.
Subclase:
Contratos
1. Manejar Evento
manejarEvento
crear
validar
obtener
escribir
leer
eliminar
crearRegTarjeta
SubsistemaInterfaceUsuario (1), PaginaCrearRegUsuario (1)
SubsistemaInterfaceUsuario (1), PaginaObtenerRegUsuario (1)
Tabla 8.82. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquas,
contratos y subsistemas identificadas de los casos de uso RegistrarUsuario y ValidarUsuario.
La descripcin de las clases PaginaRegUsuario, PaginaCrearRegUsuario, PaginaObtenerRegUsuario y
RegistroUsuario se mantienen igual.
Tarjeta
A partir de la Tabla 8.65 se generan los contratos para la clase ManejadoRegistroTarjeta, como se muestra en la
Tabla 8.83.
Subclase:
Contratos
1. Manejar Evento
manejarEvento
crear
obtener
escribir
42
leer
actualizar
eliminar
SubsistemaInterfaceUsuario (1), PaginaCrearRegTarjeta (1)
SubsistemaInterfaceUsuario (1), PaginaObtenerRegTarjeta (1)
Tabla 8.83. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones, jerarquas,
contratos y subsistemas identificadas del caso de uso RegistrarTarjeta.
La descripcin de las clases PaginaRegTarjeta, PaginaCrearRegTarjeta, PaginaObtenerRegTarjeta y
RegistroTarjeta se mantienen igual.
Interface Base Datos Registro
La descripcin de la clase InterfaceBaseDatosRegistro se mantiene igual.
Servicios
A partir de la Tabla 8.71 se actualizan los contratos segn subsistemas para la clase ManejadorServicios, como se
Mdulo: Servicios
Subclase:
Contratos
1. Manejar Evento
manejarEvento
2. Inicializar
ofrecerServicio
obtenerRegUsuario
SubsistemaInterfaceUsuario (1), PaginaServicio (1)
Tabla 8.84. Tarjeta para la clase ManejadorServicios con responsabilidades, colaboraciones, jerarquas,
contratos y subsistemas a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta.
La descripcin de la clase PaginaServicio se mantiene igual.
Protocolos
Una vez completadas las etapas anteriores, se debe detallar la especificacin de cada clase para poder derivar la
implementacin final. Esto se hace extendiendo las responsabilidades y los contratos de las clases en protocolos,
donde un protocolo corresponde a el conjunto de firmas para las distintas responsabilidades de una clase. El objetivo
de los protocolos es refinar las responsabilidades en mtodos precisos dando especial nfasis en los contratos
ofrecidos por las clases correspondientes a sus responsabilidades pblicas.
En general, responsabilidades privadas representan notas de implementacin a un programador y no deben sobreespecificarse. Sin embargo, en algunos casos se debe generar protocolos para responsabilidades privadas. Por
ejemplo, si una superclase abstracta ser implementada por un programador y sus subclases implementadas por otro,
las responsabilidades privadas usadas por sus subclases deben especificarse completamente. Es tambin importante
seleccionar cuidadosamente los nombres de los mtodos.
Durante esta etapa es comn descubrir sitios en el diseo donde el modelo fue impreciso, incorrecto, o pobremente
comprendido. Especificando protocolos ayuda a corregir tales situaciones. Por lo tanto, puede que sea necesario
tener que repetir etapas anteriores del proceso de diseo antes de poder completar las definiciones de clases y
contratos.
En general, se incrementa la reutilizacin si se tiene slo uno pocos parmetros, simplificando su comprensin e
incrementando la probabilidad de descubrir nuevas bases para la herencia. Se debe escoger los nombres con
cuidado, siguiendo un patrn uniforme en el momento de asignar estos nombres.
43
Sistema de Reservaciones con Protocolos

A continaucin se muestra como los subsistemas afectan a los diversos mdulos descritos anteriormente. A
continuacin se describen las clases principales de los distintos mdulos segn la organizacin de subsistemas para
el Sistema de Reservaciones y en base a los casos de uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
InterfaceUsuario
La clase InterfaceUsuario se muestra en la Tabla 8.85.
Superclase:
Subclase:
Contratos
1. Desplegar Pagina
desplegarPagina(Pagina) devuelve void
Pgina (1)
InterfaceUsuario()
actionPerformed(Evento) devuelve void
Manejador (1)
Tabla 8.85. Tarjeta para la clase InterfaceUusario con responsabilidades, colaboraciones, jerarquas, contratos,
subsistemas y protocolos identificados de los casos de uso RegistrarUsuario, ValidarUsuario y
RegistrarTarjeta.
A partir de la Tabla 8.80 se generan los contratos para la clase Pagina, como se muestra en la Tabla 8.86.
Clase: Pagina
Superclase:
Contratos
1. Desplegar Pgina
desplegarPagina(InterfaceUsuario) devuelve void
Tabla 8.86. Tarjeta para la superclase clase Pagina con responsabilidades, colaboraciones, jerarquas y
Principal
A partir de la Tabla 8.81 se actualizan los contratos segn protocolos para la clase Manejador, como se muestra en
la Tabla 8.87.
Clase: Manejador
Mdulo: Principal
Superclase:
Contratos
1. Manejar Evento
manejarEvento(Evento) devuelve void
desplegarPagina(Pagina) devuelve void
SubsistemasInterfaceUsuario (1), Pagina (1)
Tabla 8.87. Tarjeta para la clase Manejador con responsabilidades, colaboraciones, jerarquas, contratos,
subsistemas y protocolos identificadas de los diversos manejadores para los casos de uso RegistrarUsuario,
A partir de la Tabla 8.82 se actualizan los contratos segn protocolos para la clase ManejadorPrincipal, como se
Mdulo: Principal
Subclase:
Contratos
1. Manejar Evento
2. Inicializar
ejecutarTransaccionInicializar() devuelve void
ejecutarTransaccionServicio(ManejadorRegistro) devuelve void
ejecutarTransaccionCrearRegistroUsuario() devuelve void
ejecutarTransaccionValidarRegistro(String,String) devuelve void
desplegarPagina(PaginaPrincipal) devuelve void
44
PaginaPrincipal (1)
SubsistemaServicio (2)
SubsistemaInterfaceUsuario (1),
PaginaPrincipal (1)
Tabla 8.88. Tarjeta para la clase ManejadorPrincipal con responsabilidades, colaboraciones, jerarquas,
contratos, subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y
RegistrarTarjeta.
A partir de la Tabla 8.83 se generan los protocolos para la clase PaginaPrincipal, como se muestra en la Tabla 8.89.
Mdulo: Principal
Superclase: Pagina
Subclase:
Contratos
1. Desplegar Pgina
desplegarPagina se hereda
Tabla 8.89. Tarjeta para la clase PaginaPrincipal con responsabilidades, colaboraciones, jerarquas contratos,
subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario, ValidarUsuario y
RegistrarTarjeta.
Dominio
A partir de la Tabla 8.84 se generan los protocolos para la clase Datos, como se muestra en la Tabla 8.90.
Clase: Datos
Mdulo: Dominio
Superclase:
Contratos
setElementAt
elementAt
Tabla 8.90. Tarjeta para la clase Datos con responsabilidades, colaboraciones, jerarquas, contratos, subsistemas
y protocolos identificadas de las diversas clases entidad para los casos de uso RegistrarUsuario,
Registro
En el mdulo de Registro, compuesto de los mdulos Usuario, Tarjeta e InterfaceBD, slo se modifican las clases
de control pero no las de interface o entidad, como se ver a continuacin.
45
Usuario
A partir de la Tabla 8.60 se actualizan los contratos segn protocolos para la clase ManejadoRegistroUsuario, como
se muestra en la Tabla 8.91.
Subclase:
Contratos
1. Manejar Evento
ejecutarTransaccionCrear(Pagina) devuelve void
ejecutarTransaccionValidarRegistro(String,String)
devuelve Boolean
ejecutarTransaccionObtener(Pagina) devuelve void
ejecutarTransaccionEscribir() devuelve void
ejecutarTransaccionLeer() devuelve void
ejecutarTransaccionEliminar() devuelve void
crearRegistroTarjeta() devuelve RegistroTarjeta
desplegarPagina(PaginaCrearRegUsuario) devuelve
SubsistemaInterfaceUsuario (1), PaginaCrearRegUsuario
void
(1)
desplegarPagina(PaginaObtenerRegUsuario) devuelve SubsistemaInterfaceUsuario (1),
void
PaginaObtenerRegUsuario (1)
Tabla 8.91. Tarjeta para la clase ManejadoRegistroUsuario con responsabilidades, colaboraciones, jerarquas,
contratos, subsistemas y protocolos identificadas de los casos de uso RegistrarUsuario y ValidarUsuario.
La descripcin de las clases PaginaRegUsuario, PaginaCrearRegUsuario y PaginaObtenerRegUsuario y se
actualizan de manera similar a la PaginaPrincipal.
A partir de la Tabla 8.46 se generan los protocolos para la clase RegistroUsuario, como se muestra en la Tabla 8.92.
Superclase: Datos
Subclase:
Contratos
setElementAt se hereda
elementAt se hereda
Tabla 8.92. Tarjeta para la clase RegistroUsuario con responsabilidades, colaboraciones, jerarquas, contratos,
subsistemas y protocolos de actualizar y consultar informacin de registro para el caso de uso RegistrarUsuario.
Tarjeta
A partir de la Tabla 8.65 se generan los protocolos para la clase ManejadoRegistroTarjeta, como se muestra en la
Tabla 8.93.
Subclase:
Contratos
1. Manejar Evento
ejecutarTransaccionCrear(Pagina) devuelve void
ejecutarTransaccionObtener(Pagina) devuelve void
ejecutarTransaccionEscribir() devuelve void
ejecutarTransaccionLeer() devuelve void
ejecutarTransaccionActualizar() devuelve void
ejecutarTransaccionEliminar() devuelve void
desplegarPagina(PaginaCrearRegTarjeta) devuelve void
46

SubsistemaInterfaceUsuario (1),
PaginaCrearRegTarjeta (1)
desplegarPagina(PaginaObtenerRegTarjeta) devuelve void SubsistemaInterfaceUsuario (1),
PaginaObtenerRegTarjeta (1)
Tabla 8.93. Tarjeta para la clase ManejadoRegistroTarjeta con responsabilidades, colaboraciones, jerarquas,
contratos, subsistemas y protocolos identificadas del caso de uso RegistrarTarjeta.
La descripcin de las clases PaginaRegTarjeta, PaginaCrearRegTarjeta y PaginaObtenerRegTarjeta se actualizan
de manera similar a la PaginaPrincipal. Por otro lado, RegistroTarjeta se actualiza de manera similar a
RegistroUsuario.
Interface Base Datos Registro
A partir de la Tabla 8.52 se generan los protocolos para la clase InterfaceBaseDatosRegistro, como se muestra en la
Tabla 8.94.
Superclase:
Subclase:
Contratos
1. Registrar Usuario
leerRegistro(RegistroUsuario) devuelve void
escribirRegistro(RegistroUsuario) devuelve void
eliminarRegistro(RegistroUsuario) devuelve void
validarRegistro(RegistroUsuario, String, String)
devuelve boolean
3. Regitrar Tarjeta Usuario
leerRegistro(RegistroTarjeta) devuelve void
escribirRegistro(RegistroTarjeta) devuelve void
eliminarRegistro(RegistroTarjeta) devuelve void
Tabla 8.94. Tarjeta para la clase InterfaceBaseDatosRegistro con responsabilidades, colaboraciones, jerarquas,
contratos y protocolos de escribir y leer informacin de registro de usuario y registro de tarjeta para los casos de
uso RegistrarUsuario, ValidarUsuario y RegistrarTarjeta.
Servicios
A partir de la Tabla 8.71 se actualizan los contratos segn protocolos para la clase ManejadorServicios, como se
Mdulo: Servicios
47
Subclase:
Contratos
1. Manejar Evento
2. Inicializar
ejecutarTransaccionInicializar(Pagina) devuelve void
ejecutarTransaccionRegistrar() devuelve void
ejecutarTransaccionConsultar() devuelve void
SubsistemaConsultas (2)
ejecutarTransaccionReservar() devuelve void
SubsistemaReservas (2)
desplegarPagina(PaginaServicio) devuelve void
SubsistemaInterfaceUsuario (1), PaginaServicio (1)
Tabla 8.83. Tarjeta para la clase ManejadorServicios con responsabilidades, colaboraciones, jerarquas,
contratos, subsistemas y protocolos a partir de los casos de uso RegistrarUsuario y RegistrarTarjeta.
La descripcin de la clase PaginaServicio se mantiene de manera similar a las dems pginas.
Diagramas de Secuencia
Hasta el momento se ha refinado la descripcin de las clases involucradas en el diseo de objetos de manera esttica.
Sin embargo y al igual que durante el anlisis, es muy dificil apreciar la lgica del diseo sin mostrar los aspectos
dinmicos de ella. Con tal motivo se vuelve a utilizar los diagramas de secuencias, slo que esta vez a partir de los
protocolos de clases anteriormente definidos.
Los diagramas de secuencia pueden generarse a partir de las propias clases o incluso a partir de la interaccin entre
subsistemas. Esto es a menudo una tcnica muy til ya que se puede disear un subsistema mostrando slo las
interfaces de los subsistemas relacionados. A un nivel ms detallado se pueden mostrar las interacciones internas del
subsistema entre los propios objetos. Normalmente, los eventos en el diagrama corresponden a protocolos y se
especifican exactamente como se veran en el cdigo final.
El control en los diagramas de secuencia se disean de dos formas fundamentalmente diferentes, como se muestra
en la Figura 8.14.
bifuracin - centralizado
escalera - decentralizado
Figura 8.14 Diagrama de secuencias mostrando del lado izquierdo un ejemplo de control centralizado y del lado
derecho control decentralizado.
Un enfoque es el diagrama de bifurcacin, donde el control es centralizado. Se caracteriza por el hecho de que un
objeto controla el flujo y opera sobre los dems objetos. Mucho del comportamiento se pone en el objeto que
controla el cual conoce a todos los otros objetos y a menudo los llama directamente, como es generalmente el objeto
de control. Los otros objetos se usan tpicamente para informacin o como interface de usuario. Una estructura de
bifurcacin a menudo pone mucha responsabilidad en el diseador del objeto controlador, ya que el objeto de
control a menudo se vuelve mucho ms complejo que los dems objetos.
El otro enfoque es el diagrama de escalera, donde el control es decentralizado. Se caracteriza por la delegacin de
responsabilidades donde el control se distribuye entre los diferentes objetos. Cada objeto solo conoce a unos pocos
48
objetos aunque conoce qu objetos pueden ayudarlo con un comportamiento especfico, sin haber un objeto central.
Cada objeto tiene una tarea separada y slo conoce a los objetos alrededor de los cuales necesita ayuda para poder
llevar a cabo su tarea. A menudo se dice que la estructura de escalera es mas orientada a objetos y por lo tanto
mejor. Sin embargo, esto no es siempre cierto. Lo que se quiere es poder introducir cambios fcilmente y tambin
disear objetos y eventos reutilizables. Este es el caso de jerarquas de objetos de control.
Ambas estructuras tienen su beneficio. Las dos estructuras se deben combinar para ofrecer una estructura estable y
robusta.
Los diagramas de secuencia representan mucha de la lgica originalmente definida para los casos de uso y sus
asociaciones. Por ejemplo, la relacin incluye entre casos de uso a menudo corresponde a asociaciones entre objetos
correspondientes, mientras que la relacin de extensin entre los casos de uso a menudo corresponde directamente a
una relacin de herencia entre objetos.
En el diagrama de secuencias, una ubicacin de extensin indica la posicin en el caso de uso a ser extendido, a
menudo se acompaada por una condicin la cual indica bajo qu circunstancias la extensin debe ocurrir. La
extensin por lo tanto se aplica al caso de uso que extiende y no al que ser extendido para evitar cambiar el caso de
uso original cuando se aaden nuevas extensiones.
A continuacin se muestran los diagramas de secuencia para el sistema de reservaciones de vuelo para los casos de
uso Registrar Usuario y Registrar Tarjeta. Ntese como estos diagramas extienden con detalles adicionales los
diagramas de secuencias generados anteriormente durante el modelo de anlisis.
Registrar Usuario: Crear Registro Usuario
El diagrama de secuencia para el caso de uso Registrar Usuario, subflujo Registrarse por Primera Vez se muestra en
la Figura 8.15.
: Interface
Usuario
: Usuario
: ManejadorRegistro
Usuario
: Manejador
Principal
: InterfaceBaseDat os
Registro
: Base de Datos
Registros
ejecutarTransaccionInicializar()
desplegarPagina(paginaPrincipal)
RegistrarPorPrimeraVez
manejarEvento("crearRegistro")
Registrar
desplegarPagina(paginaCrearRegUs uario)
manejarEvento("registrar")
ejecutarTransaccionCrearRegistroUsuario()
escribir(registroUsuario)
esc ribir(registroUsuario)
OK
OK
OK
Salir
Figura 8.15. Diagrama de secuencias para el caso de uso Registrar Usuario, subflujo Registrarse por
Primera Vez.
Registrar Usuario: Actualizar Registro Usuario
El diagrama de secuencia para el caso de uso Registrar Usuario, subflujo Actualizar Registro Usuario se muestra en
la Figura 8.16.
49
: Interface
Usuario
: Usuario
: ManejadorRegist ro
Usuario
: Manejador
Servicio
: Manejador
Principal
: InterfaceBaseDatos
Registro
: Base de Datos
Regist ros
OK
manejarEvento("validar" )
ejecutarTransaccionValidarRegistro(log,pass)
validar(log,pass)
validar(log,pass)
OK
OK
OK
ejecutarTransaccionServicio()
desplegarPagina(paginaServicio)
ObtenerRegistro
manejarEvento("obtenerRegistro")
ejecutarTransaccionRegistrar()
leer(registroUsuario)
OK
OK
desplegarPagina(paginaObtenerRegUsuario)
Actualizar
manejarEvento("actualizar")
escribir(registroUsuario)
esc ribir(registroUsuario)
OK
OK
OK
Salir
Figura 8.16. Diagrama de secuencias para el caso de uso Registrar Usuario, subflujo Actualizar
Registro Usuario.
Registrar Usuario: Eliminar Registro Usuario
El diagrama de secuencia para el caso de uso Registrar Usuario, subflujo Eliminar Registro Usuario se muestra en
la Figura 8.17.
50
: Interface
Usuario
: Usuario
: ManejadorRegistroUsuario
: Manejador
Servicio
: Manejador
Principal
: InterfaceBase
DatosRegistro
: Base de Datos
Registros
ejecutarTrans accionInicializar()
OK
manejarEvent o("validar")
validar(log,pass)
validar(log,pass)
OK
OK
OK
ObtenerRegistro
OK
OK
des plegarPagina(paginaObtenerRegUsuario)
Eliminar
manejarEvento("eliminar")
eliminar(log)
eliminar(log)
OK
OK
OK
Salir
Figura 8.17. Diagrama de secuencias para el caso de uso Registrar Usuario, subflujo Eliminar Registro
Usuario.
Registrar Tarjeta: Crear Registro Tarjeta
El diagrama de secuencia para el caso de uso Registrar Tarjeta, subflujo Crear Registro Tarjeta se muestra en la
Figura 8.18.
51
: Interface
Usuario
: Usuario
: Manejador
: Manejador
: Manejador
RegistroUsuario
Servicio
Regis troTarjeta
: Manejador
Principal
: InterfaceBase
DatosRegistro
: Base de Datos
Registros
OK
manejarEvento("validar")
ejecutarTransaccionValidarRegistro(log, pass)
validar(log,pass)
validar(log,pass)
OK
OK
OK
ObtenerRegistro
OK
OK
RegistrarTarjeta
manejarEvento("registrarTarjeta")
ejecutarTransac cion
desplegarPagina(pagina
Registrar
manejar
escribir(registroTarjeta)
OK
OK
OK
Salir
Figura 8.18. Diagrama de secuencias para el caso de uso Registrar Tarjeta, subflujo Crear Registro
Tarjeta.
Registrar Tarjeta: Actualizar Registro Tarjeta
El diagrama de secuencia para el caso de uso Registrar Tarjeta, subflujo Actualizar Registro Tarjeta se muestra en
la Figura 8.19.
52
: Interface
Usuario
: Usuario
: Manejador
: Manejador
: Manejador
RegistroTarjeta
RegistroUsuario
Servicio
: Manejador
Principal
: InterfaceBase
Dat osRegistro
: Base de Datos
Registros
OK
validar(log,pass)
validar(log,pass)
OK
OK
OK
ObtenerRegistro
OK
OK
RegistrarTarjeta
manejarEvento("registrarTarj eta")
ejecutarTransaccion
obtener(registroTarjeta)
OK
OK
Actualizar
manejar
OK
OK
Salir
Figura 8.19. Diagrama de secuencias para el caso de uso Registrar Tarjeta, subflujo Actualizar Registro
Tarjeta.
Registrar Tarjeta: Eliminar Registro Tarjeta
El diagrama de secuencia para el caso de uso Registrar Tarjeta, subflujo Eliminar Registro Tarjeta se muestra en la
Figura 8.20.
53
: Interface
Usuario
: Usuario
: Manejador
: Manejador
: Manejador
RegistroTarjeta
RegistroUsuario
Servicio
: Manejador
Principal
: InterfaceBase
DatosRegistro
: Base de Datos
Registros
OK
validar(log,pass)
validar(log,pass)
OK
OK
OK
ObtenerRegistro
OK
OK
RegistrarTarjeta
manejarEvento("registrarTarjeta")
ejecutarTransaccion
OK
OK
Eliminar
manejar
eliminar(registroTarjeta)
eliminar(registroTarjeta)
OK
OK
OK
Salir
Figura 8.20. Diagrama de secuencias para el caso de uso Registrar Tarjeta, subflujo Eliminar Registro
Tarjeta.
Asociaciones, Operaciones, Mtodos y Atributos
En las secciones anteriores se ha diseado las clases hasta llegar a los protocolos de cada una de ellas. Estos
protocolos describen las firmas para las responsabilidades, en otras palabras, las interfaces externas de la clase. Sin
embargo, el diseo de objetos an no ha sido terminado. Falta resolver las propias responsabilidades, o sea, las
operaciones, en trmino de sus algoritmos. Esto corresponde al cuerpo o implementacin de las mtodos, junto con
los atributos de los objetos.
Las asociaciones a su vez corresponden a las colaboraciones identificadas durante el diseo de objetos. Sin embargo,
es necesario detallar aspectos relacionados con ambos, como es el caso de la multiplicidad y direccin de
navegacin entre clases.
Tambin es necesario especificar aspectos como la visibilidad de los mtodos tanto como los atributos, utlizando
modificadores como pblico o privado. Los miembros pblicos del objeto pueden accesarse desde afuera del
objeto, correspondientes a los contratos del objeto, mientras que los miembros privados del objetos no pueden
accesarse desde fuera y corresponden a las responsabilidades privadas y a los atributos. El encapuslamiento de las
clases se basa en ocultar lo mximo posible.
Asociaciones
Las asociaciones proveen las vas de comunicacin entre los objetos. Durante el diseo de objetos se debe formular
una estrategia para implementar las asociaciones.
54
Como se mencion en el captulo 4, las asociaciones son por naturaleza bidireccionales. Esto es cierto en un sentido
abstracto, pero si las asociaciones son atravesadas en una sola direccin, su implementacin se podra simplificar. Si
la asociacin se atraviesa en una sola direccin, sta se puede implementar como un atributo de referencia o
apuntador a otro objeto. Si la multiplicidad es de muchos se necesita un arreglo o lista de referencias.
Sin embargo, es posible que algunas asociaciones se deben atravesar en ambos lados. Esto se puede implementar
mediante dos atributos de referencia, uno para cada clase involucrada en la asociacin. Este enfoque permite acceso
rpido, pero si cualquier atributo es actualizado, entonces el otro debe ser actualizado para mantener la consistencia
de la conexin. Otro enfoque es implementar la propia asociacin como un objeto distinto. Esto se puede hacer
mediante un objeto de tamao variable que guarde un conjunto de pares de referencias correspondientes a cada liga
en la asociacin. El acceso es un poco ms lento que con atributos de referencia, aunque ofrece mayor flexibilidad
en la implementacin de la asociacin.
En relacin a los atributos de asociacin, estos pueden implementarse segn la multiplicidad correspondiente. En la
multiplicidad "1-1" los atributos se pueden guardar como atributos en uno de los objetos. En la multiplicidad "1muchos" los atributos se pueden guardar como atributos en el objeto del lado "muchos", ya que cada objeto aparece
una sola vez en la asociacin. En la multiplicidad "muchos-muchos" el atributo no puede asociarse con ninguno de
los dos objetos. En tal caso y en general, el mejor enfoque es implementar la asociacin como una clase distinta, en
la cual cada instancia representa una liga entre clase, guardando los atributos en la clase que representa la
asociacin.
Durante el anlisis no es deseable tener redundancia en las asociaciones, ya que stas no aaden nueva informacin.
Durante el diseo se evala la estructura del modelo de objeto para minimizar el costo de acceso y maximizar la
conveniencia de la implementacin. Las asociaciones que eran tiles durante anlisis pueden no ser lo ms eficiente
para el diseo. Para ello se debe examinar las diversas asociaciones y ver como se puede optimizar las travesas.
Operaciones
Las operaciones corresponden directamente a las responsabilidades, la diferencia radica en el trmino particular
utilizado. Responsabilidad se basa ms en el aspecto conceptual del servicio dentro de la aplicacin ofrecido por una
clase, mientras que operacin est ms relacionado con la funcionalidad orientada a objetos de la clase. Cuando se
habla de operaciones se debe pensar tanto en su interface o protocolo como en su implementacin o algoritmo. Los
algoritmos definen la lgica utilizada por cada operacin para resolver la responsabilidad a la cual corresponden.
En general, muchas operaciones son suficientemente simples que no requieren de algoritmos, como son las
operaciones que atraviesan las asociaciones entre los objetos para consultar o modificar los valores de los atributos.
Sin embargo, se necesitan algoritmos para implementar funciones de lgica ms compleja, como ordenar un
conjunto de nmeros o palabras. Adems es necesario especificar algoritmos cuando no se ha dado una
especificacin procedural para resolver la operacin, para optimizar funciones para las cuales han sido definidos
algoritmos simples pero ineficientes, y en general para minimizar el costo de la implementacin de las operaciones.
Algunas funciones tambin son especificadas como restricciones declarativas, sin definicin procedural. En tal caso,
se debe usar algn conocimiento adicional para implementar el algoritmo. Vale la pena resaltar que los aspectos
algortmicos pueden llegar a ser una de las fuentes de mayor complejidad en el sistema completo.
En nuestro sistema de reservaciones de vuelos y los sistemas de informacin en general, estos algoritmos tienden a
ser sencillos, razn por la cual no profundizaremos aqu.
Mtodos
Los mtodos corresponden a la implementacin de las operaciones, pudiendo haber ms de un mtodo
correspondiente a una misma operacin. Se considera que todos los mtodos que tengan el mismo nombre, aunque
distinta firma, corresponden a una misma operacin.
En general, es deseable generalizar tipos de argumentos, precondiciones, restricciones y suposiciones sobre el
comportamiento del mtodo al igual que el contexto en el cual el mtodo opera. Se deben tomar acciones en el caso
de valores vacos, extremos, o fuera de rango. Usualmente un mtodo puede hacerse general con un poco ms de
cdigo.
Se debe documentar la implementacin de los mtodos, describiendo su propsito, funcin, contexto, entradas y
salidas.
Atributos
Los atributos corresponden a los aspectos estructurales de la clase. Bsicamente existen atributos que guardan
valores, como nmeros y textos, y atributos correspondientes a referencias a otros objetos. En el caso de lenguajes
como Java y C++ esta distincin es clara ya que los tipos de los atributos definen a cual de los dos se refieren. En el
55
caso de lenguajes como Smalltalk, no hay distncin alguna ya que todos los atributos corresponden a referencias
entre objetos.
Vale la pena resaltar, que los atributos, en especial aquellos que guardan valores y no referencias, son lo ltimo que
se especifica en el diseo de objetos.
Los atributos que pueden ser derivados de otros atributos pueden guardarse en su forma computada para evitar
recomputacin. Estos atributos derivados deben actualizarse cuando los valores bsicos cambian. Nuevos objetos o
clases pueden ser definidos para retener la informacin que debe ser actualizada si un objeto del cual depende es
cambiado. Esto se puede hacer mediante cdigo explcito donde cada atributo derivado es definido en trmino de
uno o ms objetos fundamentales. Puede tambin hacerse una recomputacin peridica donde todos los atributos
derivados se recomputan. Si existen muchos atributos y slo algunos atributos cambian, la recomputacin peridica
puede que no sea muy prctica. Otro enfoques es registrar cada valor dependiente con el valor activo definiendo una
operacin para actualizar los valores dependientes, algo similar a un trigger.
Herencia Mltiple
Hay otro aspecto importante relacionado con la herencia afectando principalmente al dominio del problema. Ya que
muchos lenguajes de programacin orientados a objetos no apoyan la herencia mltiple, es necesario en tales casos
implementar herencia mltiple a travs de herencia sencilla y posiblemente agregacin (delegacin). Los siguientes
tres casos describen el enfoque general:
? ? Implementacin de herencia mltiple usando agregacin. Una superclase con mltiples generalizaciones
individuales se puede redefinir como un agregado en el cual cada componente del agregado reemplaza una de
las ramas de la generalizacin. Se reemplaza las posibles instancias de la herencia mltiple por un grupo de
instancias que componen el agregado. La herencia de las operaciones a travs del agregado no es automtica,
debiendo ser delegadas a los componentes apropiados. Si una subclase tiene varias superclases, todas de igual
importancia, es mejor usar delegacin y preservar la simetra.
? ? Implementacin de herencia mltiple heredando de la clase ms importante y delegando el resto. Se toma una
como subclase de la superclase ms importante, combinndose con un agregado correspondiendo a las
generalizaciones restantes. Si se tiene una superclase principal, se implementa la herencia mltiple a travs de
herencia sencilla y agregacin. Si el nmero de combinaciones es pequeo, se puede usar generalizacin
anidada (siguiente caso). Si el nmero de combinaciones, o el tamao del cdigo, es grande se debe evitar este
tipo de implementacin.
? ? Implementacin de herencia mltiple usando generalizacin anidada. Se crean varios niveles de generalizacin,
terminando la jerarqua con subclases para todas las posibles combinaciones de clases unidas. En este caso no se
utiliza agregacin. Se preserva la herencia pero se duplica las declaraciones, rompiendo con el espritu de la
orientacin a objetos. Se debe factorizar primero segn el criterio de herencia ms importante, y luego segn el
resto. Si una superclase tiene bastantes ms caractersticas que las otras superclases, o si una superclase es el
cuello de botella en el rendimiento, se debe preservar la herencia en relacin a esa clase.
Diagramas de Clase del Sistema de Reservaciones
Una vez finalizado el diseo de objetos se procede a generar los diagramas de clase para el sistema completo. A
continuacin se muestran estos diagramas para el sistema de reservaciones de vuelo.
InterfaceUsuario
El diagrama de clases para las clases del mdulo InterfaceUsuario se muestran en la Figura 8.21.
56
<<Interface>>
Pagina
<<Interface>>
InterfaceUs uario
InterfaceUsuario()
desplegarPagina(p : Pagina) : void
setPagina(p : Pagina) : void
setManejador(m : Manejador) : void
#interfaceUsuario
actionP erformed(event : ActionEvent ) : void
windowClosed(event : WindowEvent) : void
windowDeiconified(event : WindowEvent) : void
windowIc onified(event : WindowEvent) : void
windowA ctivated(event : WindowEvent) : void
windowDeactivated(event : WindowEvent) : void
windowOpened(event : WindowEvent) : void
#interfaceUsuario
windowClosing(event : WindowEvent ) : void
main(args : String[ ]) : void
-pagina
Pagina()
Pagina(p : Pagina)
Pagina(ui : InterfaceUsuario, m : Manejador)
Pagina(p : Pagina, ui : InterfaceUsuario, m : Manejador)
createPagina() : void
agregarBotonesRegresarSalir(panel : Panel) : void
getManejador() : Manejador
setPaginaRegresar(p : Pagina) : void
getPaginaRegresar() : Pagina
desplegarPagina(ui : InterfaceUsuario) : void
resetPagina() : void
resetPagina(ui : InterfaceUsuario) : void
getElemento(i : int) : String
getElemento(name0 : String) : String
leerElementos(datos : Datos) : void
escribirElementos(datos : Datos) : void
#pagina
-manejador
#rPagina
#pRegres ar
#manejador
<<Control>>
Manejador
(from pri nci pal)
$ db_flag : boolean
Manejador(ui : InterfaceUsuario)
Manejador(m : Manejador, ui : InterfaceUsuario)
setPaginaRegresar(p : Pagina) : void
setPagina(p : Pagina) : void
getPaginaRegresar() : Pagina
getPagina() : Pagina
desplegarPagina(p : Pagina) : void
manejarEventosRegresarSalir(str : String) : void
manejarEvento(str : String) : void
escribirElementos(p : Pagina, datos : Datos) : void
leerElementos(p : Pagina, datos : Datos) : void
print(lista : Vector) : void
#mParent
Figura 8.21. Diagrama de clases para las clases del mdulo InterfaceUsuario.
Principal
El diagrama de clases para las clases del mdulo Principal se muestran en la Figura 8.22.
57
<<Interfac e>>
Pagina
#pagina
#manejador <<Control>>
Manejador
#mParent
#rP agina
#pRegresar
<<Control>>
ManejadorPrincipal
<<Int erface>>
PaginaPrincipal
PaginaPrincipal(ui : InterfaceUsuario, m : Manejador)
ManejadorPrincipal(ui : InterfaceUsuario)
ejecutarTransaccionInicializar() : void
ejecutarTransaccionCrearRegistroUsuario() : void
ejecutarTransaccionValidarRegistro(log : String, pass : String) : void
ejecutarTransaccionServicio(mr : ManejadorRegistroUsuario) : void
Figura 8.22. Diagrama de clases para las clases del mdulo Principal.
Registro
El mdulo de Registro se compone de los mdulos de Usuario, Tarjeta y InterfaceBD, como se muestran en las
siguientes secciones.
Usuario
El diagrama de clases para las clases del mdulo Usuario se muestran en la Figura 8.23.
58
#manejador
#pagina
<<Interface>>
Pagina
<<Control>>
Manejador
(from principal)
#rPagina
#mParent
-paginaCrearRegUsuario
(f ro m i nterfaceUsuario )
#pRegresar
-paginaObtenerRegUsuario
<<Control>>
ManejadorRegistroUsuario(m : Manejador, ui : InterfaceUsuario)
getInterfaceRegistro() : InterfaceRegistro
ejecutarTransaccionCrear(p : Pagina) : void
ejecutarTransaccionValidarRegistro(log : String, pass : String) : boolean
ejecutarTransaccionObtener(p : Pagina) : void
ejecutarTransaccionCrear() : void
ejecutarTransaccionActualizar() : void
ejecutarTransaccionEliminar() : void
ejecutarTransaccionRegistrarTarjeta() : void
<<Interface>>
PaginaRegUsuario
PaginaRegUsuario(p : Pagina, ui : InterfaceUsuario, m : Manejador)
<<Interface>>
PaginaCrearRegUsuario
-registroUsuario
PaginaCrearRegUsuario(p : Pagina, ui : Interfac eUsuario, m : M anej ador)
<<Entity>>
RegistroUsuario
<<Entity>>
Datos
(from dominio)
RegistroUsuario()
<<Interface>>
PaginaObtenerRegUsuario(p : Pagina, ui : InterfaceUsuario, m : Manejador)
Figura 8.23. Diagrama de clases para las clases del mdulo Usuario.
Tarjeta
El diagrama de clases para las clases del mdulo Tarjeta se muestran en la Figura 8.24.
<<Interface>>
Pagina
#pagina
#manejador <<Control>>
Manejador
#rP agina
(from principal)
-paginaCrearRegTarjeta
#pRegresar
#mParent
-paginaObtenerRegTarjeta
<<Int erface>>
PaginaRegTarjeta
PaginaRegTarjeta(p : Pagina, ui : InterfaceUsuario, m : Manejador)
<<control>>
<<Int erface>>
PaginaCrearRegTarj eta
ManejadorRegistroTarjeta(m : Manejador, ui : InterfaceUsuario)

ejecutarTransaccionInicializar(p : Pagina, log : String) : void
ejecutarTransaccionCrear(p : Pagina) : void
ejecutarTransaccionObtener(p : Pagina) : void
ejecutarTransaccionCrear() : void
ejecutarTransaccionActualizar() : void
ejecutarTransaccionEliminar() : void
PaginaCrearRegTarjeta(p : Pagina, ui : InterfaceUsuario, m : Manejador)

<<Int erface>>
PaginaObtenerRegTarjeta
PaginaObt enerRegTarjet a(p : Pagina, ui : InterfaceUsuario, m : M anejador)
-registro
<<Entity>>
Datos
<<Entity>>
RegistroTarjeta
(from dominio)
RegistroTarjeta()
Figura 8.24. Diagrama de clases para las clases del mdulo Tarjeta.
InterfaceBD
El diagrama de clases para las clases del mdulo InterfaceBD se muestran en la Figura 8.25.
59
InterfaceRegistro
ArchivoRegistro
InterfaceRegistro()
leerRegistro(reg : Datos, log : String) : boolean
escribirRegistro(reg : Datos) : void
actualizarRegistro(reg : Datos) : void
eliminarRegistro(reg : Datos) : void
validarRegistro(reg : Datos, log : String, pass : String) : boolean
getClassName(reg : Datos) : String
ArchivoRegist ro()
leerRegistro()
escribirRegist ro()
actualizarRegistro()
eliminarRegistro()
validarRegistro()
inicializarRegistros()
leerRegistros()
actualizarArchivoRegistro()
escribirDatos()
leerRecordSetRegistro()
leerIndiceRegistro()
getName()
-ar
Int erfaceBaseDatosRegist ro
InterfaceBaseDatosRegistro()
escribirRegistro(reg : Datos) : void
leerRecordSetRegistro(query : String, datos : Datos) : boolean
actualizarRecordSetRegistro(query : String) : boolean
displayAllDataRegistro() : void
displayAllDataTarjeta() : void
displayRecordSet(query : String) : void
dispResultSet(rs : ResultSet) : void
checkDriverSun() : int
checkDriverMS() : int
open(url : String, log : String, pass : String) : void
checkForWarning(warn : SQLWarning) : boolean
InterfaceArchivoRegistro
InterfaceArchivoRegistro()
esc ribirRegistro(reg : Datos) : void
Figura 8.25. Diagrama de clases para las clases del mdulo InterfaceBD.
Diccionario de Clases para el Sistema de Reservaciones
Como ltima etapa del modelo de diseo de objetos, se actualiza el diccionario de datos originalmente descrito para
el anlisis para incluir todas las actualizaciones hechas.
Comenzamos con cuatro mdulos o paquetes principales: InterfaceUsuario, Dominio, Principal, Registro y
Sevicios, como se muestra en la Figura 8.26.
dominio
registro
interfaceUsuario
servicios
principal
Figura 8.26. Mdulos principales del sistema de reservaciones de vuelo.

InterfaceUsuario
El mdulo InterfaceUsuario est compuesto por una sla clase:
60
??
InterfaceUsuario Clase Interface. Toda la interaccin con el usuario se hace por medio de la interface de
usuario.
? ? Pagina - La Interface para mostrar y recibir informacin del usuario es manejada por la Interface de usuario
mediante "pginas" especializadas a partir de esta clase.
Dominio
El mdulo Dominio est compuesto por una clase:
? ? Datos - La clase genrica para todos los objetos entidad.
Principal
El mdulo Principal est compuesto por dos clases:
? ? PaginaPrincipal - Clase Interface. Pgina principal (P-1).
? ? ManejadorPrincipal - Clase Control. El manejador principal es el encargado de desplegar la pgina principal
de interaccin con el usuario, y luego delegar las diferentes funciones a los manejadores especializados
apropiados.
? ? Manejador - La clase genrica para todos los manejadores.
? ? AppletMain - El manejador para applets en el Web.
Registro
El mdulo Registro se divide en los siguientes mdulos: InterfaceBD, Usuario y Tarjeta, como se muestra en la
Figura 8.27.
tarjeta
usuario
interfaceBD
Figura 8.27. Mdulos adicionales del mdulo Registro.

InterfaceBD
El mdulo InterfaceBD est compuesto por una sla clase:
? ? InterfaceBaseDatosRegistro - Clase Interface. La informacin de cada usuario se almacena en la base de datos
de registro la cual se accesa mediante la interface de la base de datos de registro. Esto permite validar a los
distintos usuarios adems de guardar informacin sobre la tarjeta de crdito para pagos en lnea.
Usuario
El mdulo Usuario est compuesto por las clases:
? ? PaginaRegUsuario - Pgina genrica de registro de usuario.
? ? PaginaCrearRegUsuario - Clase Interface. Pgina de solicitud de registro de usuario (P-3).
? ? PaginaObtenerRegUsuario - Clase Interface. Pgina de devolucin con informacin de registro de usuario (P4).
? ? RegistroUsuario - Clase Entidad. Para poder utilizar el sistema de reservaciones, el usuario debe estar
registrado con el sistema. El registro contiene informacin acerca del usuario que incluye nombre, direccin,
colonia, ciudad, pas, cdigo postal, telfono de casa, telfono de oficina, fax, email, login y password.
? ? ManejadorRegistroUsuario - Clase Control. El manejador de registro de usuario se encarga de todo lo
relacionado con registro del usuario para poder utilizar el sistema.
Tarjeta
El mdulo Tarjeta est compuesto por las clases:
? ? PaginaRegTarjeta - Pgina genrica de registro de tarjeta.
? ? PaginaCrearRegTarjeta - Clase Interface. Pgina de solicitud de registro de tarjeta (P-5).
??
61
PaginaObtenerRegTarjeta - Clase Interface. Pgina de devolucin con informacin de registro de tarjeta (P6).
? ? RegistroTarjeta - Clase Entidad. Para poder hacer un pago con una tarjeta de crdito, se debe tener un registro
de tarjeta. El registro contiene informacin acerca de la tarjeta incluyendo nombre, nmero, expedidor y
vencimiento. La tarjeta est ligada a un registro de usuario.
? ? ManejadorRegistroTarjeta - Clase Control. El manejador de registro de tarjeta se encarga de todo lo
relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones.
Servicios
Las clase principales del mdulo son:
? ? PaginaServicio - Clase Interface. Pgina de servicios (P-2).
? ? ManejadorServicios - Clase Control. El manejador de servicios se encarga de enviar las peticiones particulares
de servicios a los manejadores espacializados para consulta, reserva y compra.
Weitzenfeld: Diseo
02/10/01
62

8 Disenio PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

8 Disenio PDF

Caricato da

Copyright:

Formati disponibili

Weitzenfeld: Captulo 8

introduccin del ambiente

Figura 8.2 El modelo de diseo es una continuacin del modelo de anlisis.

Seleccin del lenguajes de programacin a utilizarse, tpicamente estructurados u orientados a objetos;

Tabla 8.1. Diagrama para la tarjeta de clase.

Tabla 8.2. Diagrama para la tarjeta de clase de InterfaceUsuario

informa al Usuario del xito de la actualizacin del registro

enva el evento obtenerRegUsuario al ManejadorServicio

enva el evento crearRegUsuario

enva el evento eliminar

Subclase: PaginaPrincipal, PaginaServicio, PaginaRegUsuario, PaginaRegTarjeta

Subclase: RegistroUsuario, RegistroTarjeta

1. Actualizar y Consultar Informacin

Tabla 8.74. Tarjeta para subsistemas.

Tabla 8.75. Tarjeta para el subsistema InterfaceUsuario.

Figura 8.6 Diagrama de clase con contrato.

1.Nombre del Contrato

Figura 8.8 Diagrama de subsistema encapsulando clases y contratos.

Figura 8.9 Subsistemas del sistema de reservaciones de vuelos.

Figura 8.10 Subsistema de interface de usuario.

4.S ubsistemaRegistro. Obtener

5.S ubsistemaRegistro. Obtener

Figura 8.11 Subsistema de registro.

Figura 8.12 Subsistema de servicios.

Figura 8.13 Subsistemas del sistema de reservaciones de vuelo.

Sistema de Reservaciones con Protocolos

RegistroTarjeta (1), InterfaceBaseDatosRegistro (3)

ManejadorRegistroTarjeta(m : Manejador, ui : InterfaceUsuario)

PaginaCrearRegTarjeta(p : Pagina, ui : InterfaceUsuario, m : Manejador)

Figura 8.26. Mdulos principales del sistema de reservaciones de vuelo.

Figura 8.27. Mdulos adicionales del mdulo Registro.

Potrebbero piacerti anche