Enfoque Metodológico para el

Desarrollo Basado en Componentes

Andrés Vignaga, Daniel Perovich

{avignaga, perovich}@fing.edu.uy

Instituto de Computación
Facultad de Ingeniería
Universidad de la República
http://www.fing.edu.uy/inco

Resumen
El desarrollo basado en componentes (CBD) es un área nueva y poco
explorada. Uno de los principales problemas que enfrenta esta área es el de
definir las tareas a desarrollar y las técnicas a aplicar para la producción de
software de buena calidad. El software en el que estamos interesados está
orientado a ambientes empresariales y es de gran porte. El constante cambio
en los requerimientos es uno de los aspectos más característicos del desarrollo
actualmente, un software de calidad debe estar preparado para absorber este
tipo de cambios con el menor impacto posible. La definición de una
arquitectura de componentes resulta fundamental en este sentido por permitir
observar y manejar globalmente los cambios. Inclusive, el cambio se
experimenta a nivel de las tecnologías aplicables, tanto para el desarrollo
como para el deploy de los sistemas, por lo que dicha arquitectura de
componentes no debe apoyarse en una implementación particular sino en una
especificación de los mismos. En este trabajo se proponen actividades que
guían la especificación de una arquitectura basada en componentes e
independiente de la tecnología para sistemas de tipo empresarial y de gran
porte, donde el énfasis principal esta hecho en facilitar el cambio.
Palabras clave: Desarrollo Basado en Componentes, Arquitectura de Software

1
1. Introducción
El desarrollo basado en componentes (CBD) es un área nueva y poco explorada. Se lo suele asociar e
incluso confundir con el desarrollo orientado a objetos (OOD); a pesar de que ambos enfoques están
relacionados, los mismos son aplicables a sistemas de distinto porte. Generalmente OOD es asociado con
Programming-in-the-Small, mientras que CBD es más aplicable a Programming-in-the-Large.
Actualmente existen plataformas que permiten el desarrollo de aplicaciones basadas en componentes (e.g.
J2EE). Muchas empresas han adaptado sus metodologías para adecuarlas a la plataforma sobre la cual
montarán sus desarrollos. Este cambio en las metodologías, generalmente en forma ad hoc, ha llevado a
que los artefactos construidos durante el diseño sean particulares a la tecnología a utilizar. Este hecho no es
beneficioso considerando que las tecnologías de componentes son tecnologías emergentes y en continua
evolución.
El presente artículo es el resultado del trabajo de investigación de los autores en esta área. Como anexo de
este documento se encuentran tres juegos de transparencias que ahondan en distintos puntos de la
metodología. La estructura de este documento es la siguiente: la primera sección presenta los principios que
rigen el paradigma de componentes. La segunda sección presenta las líneas generales de la metodología,
basada en la propuesta del Racional Unified Process [RUP]. La adecuación de los workflows de las
disciplinas del RUP en la metodología propuesta es presentada en la tercera sección. La cuarta sección
muestra la aplicación de la metodología sobre a un caso de estudio. Por último se concluye y se presentan
trabajos futuros.

2. Principios de Componentes
2.1. Objetivos
El desarrollo basado en componentes es una aplicación de la técnica de divide & conquer para manejar la
complejidad. La diferencia principal con los métodos estructurados es principalmente que el análisis y
diseño es realizado dentro del mismo paradigma que la implementación. Esta implementación queda
relegada a un segundo plano, siendo importante dar una solución lógica al problema, previo a su
codificación. Este principio fue utilizado en el paradigma de orientación a objetos, el hecho de combinar
operaciones e información en una misma unidad, y de contar con técnicas de modelado dentro del mismo
paradigma, hizo que la orientación a objetos tuviera un éxito importante. El principal objetivo que se
persiguió con la introducción de este paradigma fue el reuso. A pesar de contar con técnicas de buenas
prácticas de diseño, como ser los patrones GRASP [Lar], no es sencillo mantener las unidades de software
(i.e. clases) con el nivel de acoplamiento y cohesión deseables. La necesidad de reusar una clase implica
llevar consigo otros artefactos que en un principio pueden no ser necesarios para el nuevo escenario donde
se quiere reaprovechar la clase.
Por esta razón, el paradigma de componentes no se focaliza en el principio de reuso sino que ataca
principalmente la mantenibilidad. El reuso es un objetivo admirable pero no es sencillo de obtener. Bajo el
enfoque de componentes se busca construir para el cambio. Los sistemas actuales cambian sus
requerimientos incluso cuando el sistema ya está en producción. El principal objetivo de un componente
no es el reuso sino que sea fácilmente reemplazable. El hecho de ser reemplazable implica que una nueva
implementación de un componente pueda ser utilizada en lugar de una implementación anterior sin afectar
el funcionamiento del resto de los componentes. Nuevas implementaciones pueden por ejemplo mejorar
su performance o proveer nuevos servicios; el único requerimiento es que provea los mismos servicios
provistos por la implementación anterior.
El enfoque de componentes enfatiza en la arquitectura del sistema y en la capacidad de manejar al sistema
completo, de forma tal que es en base a esa arquitectura que se evalúa el impacto del cambio y no en base a
información local. Las decisiones internas a los componentes son un objetivo secundario, siendo lo
primordial su interacción con el resto de los componentes del sistema. El enfoque propone concentrarse
en el todo y no en las partes.

2.2. Principios
Los componentes son unidades de software que se rigen por ciertos principios. Éstos son los mismos que
los presentes en el paradigma de orientación a objetos: unificación de datos y comportamiento, identidad y
encapsulamiento. A estos principios se le agrega el del uso obligatorio de interfaces. Cada cliente de un
componente depende exclusivamente de la especificación del componente y no de su implementación.
Esta importante separación es la clave para reducir el acoplamiento y el buen manejo de las dependencias.

2
La especificación de un componente esta formada por un conjunto de interfaces que describen el
comportamiento del componente. Las interfaces describen este comportamiento en función de un modelo
de información, el cual es una proyección del modelo de información del propio componente. Las
dependencias entre componentes son dependencias de uso de interfaces, no son dependencias directas
sobre el componente. Muchas implementaciones pueden realizar una especificación de componente
permitiendo de esta forma contar con la propiedad de reemplazabilidad.

3. Metodología de Desarrollo Basada en Componentes

La metodología propuesta esta basada en casos de uso y esta centrada en la arquitectura. Estos
lineamientos generales, propuestos por el Rational Unified Proccess, encajan fuertemente con los objetivos
de nuestro paradigma.

3.1. Arquitectura
El término ‘arquitectura’ es heredado de otras disciplinas de la ciencia. Se entiende por arquitectura a un
conjunto de piezas de distintos tipos, que encajan entre sí y cumplen una función determinada. La
arquitectura presenta además el impacto del cambio de una de las piezas. Dentro del paradigma de
componentes, las piezas (o building blocks) son los componentes. La arquitectura de componentes dirá
con que tipos de componentes y en qué relación de dependencia se encuentran.
Como fue mencionado antes, la metodología aquí propuesta busca utilizar el paradigma de componentes a
sistemas empresariales de gran porte. Para ello consideramos arquitecturas distribuídas, en múltiples capas,
que incorporan fuentes de datos heterogéneas, sistemas legados y paquetes off-the-shelf.
El estilo de arquitectura en capas es aplicable a este tipo de sistemas. Cada capa sugiere un tipo diferente de
componentes, e indica el rol que juegan los componentes que residan en ella. La arquitectura propuesta se
presenta en la siguiente figura:

Interfaz de Usuario
Manejo de la lógica de UI
Diálogos del Usuario
Manejo de la lógica de casos de uso
Control de la sesión de usuario
Aplicación

Servicios del Sistema

Servicios básicos del sistema
Usualmente corriendo en el marco de una transacción Sistema
Servicios del Negocio
Tipos estables del negocio
Manejo de la información del sistema
Usualmente asociados a fuentes de datos

Figura 1 - Arquitectura

El enfoque metodológico se centra en aquellas capas que representan las funcionalidades del sistema, a
saber, la capa de Servicios del Sistema y la capa de Servicios del Negocio.
La definición de la arquitectura de componentes cubre aspectos únicamente lógicos y es totalmente
independiente de la tecnología con la cual se implementarán los componentes y sobre la cual se hará el
deploy del sistema. Esta vista lógica nos permite medir el nivel de acoplamiento del sistema y razonar sobre
los efectos de modificar o reemplazar un componente. La independencia de la tecnología nos permite
abstraernos de los tecnicismos de éstas así como elegir la más apta dependiendo del sistema que se esté
desarrollando.

3.2. Rational Unified Process

RUP es un producto de Rational Software que presenta un modelo de proceso de ingeniería de software
completo. Provee un enfoque basado en disciplinas para la asignación de tareas y responsabilidades.
Permite un vocabulario común entre equipos de desarrollo, hacer el proceso repetible, y realizar
mediciones (estimación de costos y tiempo, nivel de avance, entre otros). Aquellos equipos que adoptan
RUP no están obligados a realizar todas las actividades propuestas sino que deben considerarlo como la

3
base para sus propios procesos. RUP debe ser ajustado a las necesidades y realidades del equipo de
desarrollo.
Como proceso de ingeniería de software es amplio y diverso; su objetivo principal es asegurar el desarrollo
de software de alta calidad que satisfaga los requerimientos del usuario final dentro de un tiempo y
presupuesto predecible. El proceso de RUP se resume en la siguiente figura:

Figura 2 - Rational Unified Process

RUP presenta un proceso iterativo organizado en cuatro fases. La cantidad de iteraciones realizadas en cada
fase depende principalmente del proyecto. La fase de Inception tiene como objetivo establecer el alcance
del proyecto, discriminar los escenarios de aplicación que involucran importantes decisiones de diseño,
exhibir una arquitectura inicial y estimar potenciales riesgos. La segunda fase, Elaboration, busca asegurar la
arquitectura del sistema resolviendo los principales riesgos; produce además un prototipo evolutivo del
sistema. Finalmente, Construction tiene como objetivo completar el análisis, diseño e implementación y
testeo de la totalidad de los requerimientos. Una arquitectura robusta permite un alto grado de paralelismo
en estas actividades. La fase de Transition refiere a la puesta en producción del producto en las
instalaciones del cliente.
El avance en el tiempo del proyecto esta dado por el avance en las fases. La división del mismo en
disciplinas brinda una organización de las actividades a realizar y permite comprender al proyecto desde el
punto de vista del desarrollo en cascada. Una disciplina es un conjunto de actividades relacionadas con un
área específica dentro del proyecto.

3.3. Metodología
La metodología propuesta abarca las tres primeras fases propuestas en el RUP, y propone actividades
correspondientes solamente a las disciplinas Business Modeling, Requirements y Analysis & Design.
Recordar que nuestro enfoque es independiente de la tecnología por lo cual no son consideradas las
disciplinas de implementación, testeo y deployment y tampoco la fase Transition. Asimismo, este enfoque
refiere a actividades exclusivamente de desarrollo de software y no a actividades de gestión y
gerenciamiento del mismo. Así, las otras disciplinas del RUP tampoco fueron consideradas.
Para una mayor aplicabilidad del enfoque hemos reformulado los workflows que ocurren en la
metodología. Los mismos no corresponden directamente a cada disciplina sino que corresponden a las
fases. Cada workflow indica claramente el lugar donde ocurren las iteraciones.
Las actividades presentes en el workflow de la fase Inception refieren principalmente a las actividades de la
disciplina Business Modeling propuesta por RUP. El lector puede referirse a la bibliografía para hallar una
descripción detallada de las mismas.

4
 Figura 3 - Workflow de la fase Inception

El workflow de la fase Elaboration ataca los procesos en el orden dado por el ranqueo de procesos
realizado en la fase anterior. No es necesario atacar todos los procesos, sino aquellos críticos desde el
punto de vista de la arquitectura. Las actividades presentes en este workflow son similares a las propuestas
en el RUP. Al igual que las actividades de la fase anterior, el lector podrá identificar claramente cuales son
las tareas a realizar en cada una de ellas; a su vez puede referirse a la bibliografía. Dos de las actividades,
distinguidas en el diagrama, son aquellas que fueron incorporadas dentro de esta metodología; están
fuertemente basadas en la propuesta de Cheesman y Daniels [CD].

Figura 4 - Workflow de la fase Elaboration

El workflow para la fase Construction es análogo al de la fase Elaboration. Además, dado que en la fase
Construction la arquitectura esta lo suficientemente estable, una nueva actividad debe llevarse adelante. La
misma lleva el nombre de Especificación de Componentes.
La siguiente sección presentará en más detalle cada una de las actividades particulares al enfoque aquí
presentado, a saber Identificación de Componentes, Interacción de Componentes y Especificación de
Componentes.

5
4. Actividades Particulares al Enfoque
4.1. Identificación de Componentes
Esta etapa identifica a partir de los artefactos generados en las actividades anteriores el conjunto de
interfaces y especificaciones de componentes que poblaran la arquitectura.
Esta actividad tiene como objetivos:
Crear un conjunto inicial de interfaces y especificaciones de componentes, tanto a nivel de componentes de
sistema como de componentes de negocio.
Producir el modelo de tipos del negocio inicial, partiendo del modelo conceptual preliminar.
Presentar las interfaces y especificaciones de componentes en una arquitectura de componentes inicial,
decidiendo de que forma se agrupan las interfaces en especificaciones de componentes.
La siguiente figura muestra las tareas que se proponen para llevar adelante esta actividad.

Figura 5 - Tareas que componen la actividad Identificar Componentes

4.2. Interacción de Componentes

En esta etapa se decide cómo trabajarán juntos los componentes detectados en la etapa anterior de forma
de satisfacer las funcionalidades deseadas.
Los objetivos particulares de esta actividad son:
Refinar las definiciones de las interfaces de sistema.
Definir las interacciones entre los componentes identificando operaciones en las interfaces de los
componentes de negocio y determinando las dependencias entre componentes.
Definir políticas de manejo de integridad referencial.
Las tareas a realizarse en esta actividad se presentan en la siguiente figura.

6
 Figura 6 - Tareas que componen la actividad Interacción de Componentes

4.3. Especificación de Componentes

Como se mencionó antes, esta actividad es realizada una vez que la arquitectura e interfaces de los
componentes estén estables. La especificación de los componentes es una actividad fundamental la cual
favorece fuertemente a la reemplazabilidad así como posibilita el reuso de componentes en futuros
proyectos.
Los objetivos de esta actividad son:
Definir el modelo de información de cada interfaz; este modelo representa una vista abstracta de la
información manejada por el componente.
Especificar formalmente las operaciones de las interfaces; esta especificación se realiza con contratos de
software.
Capturar y documentar las restricciones entre los componentes.
La siguiente figura presenta las tareas a realizar en esta actividad.

Figura 7 - Tareas que componen la actividad Especificación de Componentes

7
5. Caso de Estudio
El caso de estudio abordado representa un sistema de información de porte empresarial en el dominio
Hotelería, y concierne principalmente a la gestión de una cadena hotelera. Este sistema, llamado Sistema de
Gestión Hotelera, esta conformado por varios subsistemas; entre ellos se encuentra el Subsistema de
Reservas, objeto de estudio de esta sección. Este caso de estudio fue atacado originalmente en [CD01], con
la metodología allí propuesta. El lector podrá comparar ambos abordajes ayudando así al entendimiento de
las adaptaciones introducidas en este trabajo respecto al propuesto en [CD01].
Esta sección presenta los artefactos generados en cada una de las actividades propuestas en este trabajo.
No se incluyen, en cambio, los artefactos generados para satisfacer todos los requerimientos del Subsistema
de Reservas. Se presenta solamente los artefactos necesarios para el buen entendimiento de la aplicación de
la metodología.

5.1. Fase Inception

5.1.1. Descripción del Negocio
Una cadena hotelera desea automatizar los servicios brindados por sus hoteles. Cada hotel posee un
sistema de información que satisface parcialmente los requerimientos informáticos reales de la empresa.
Muchas actividades son registradas en formularios de papel y la obtención de datos estadísticos insume
gran cantidad de recursos.
La gerencia general desea mantener en forma central y unificada todas las reservas que se hacen en sus
hoteles. Como política de la empresa no se realiza overbooking, por lo que se quiere que dicha política sea
ejecutada en todos los hoteles de la cadena. Se desea además poder sugerir a los clientes otros hoteles de la
cadena cuando un hotel no tiene disponibilidad de la habitación solicitada. Es prioritario este
requerimiento.
Los clientes de la empresa deben poder realizar todas sus actividades por Internet. Las estaciones de
trabajo en los hoteles operarán con la misma interfaz de usuario; en cambio, en estos casos el hecho de
encontrarse en un hotel determinado debe simplificar el uso del sistema. Debe proveerse además
mecanismos para que las agencias de viajes interoperen con el sistema (por ejemplo mediante el uso de
XML y Web Services).
Hay fuertes restricciones de performance para los procesos de reserva, check-in y check-out.
Es importante, además, reutilizar un sistema de facturación existente. La empresa ha utilizado dicho
producto en otras oportunidades y desea conservarlo y aprovecharlo en este emprendimiento.
Los empleados trabajan usualmente en el mismo hotel. Sin embargo es probable que los mismos sean
rotados a otros hoteles en la región.
La gerencia general necesita información estadística. Ésta es utilizada para la apertura o clausura de hoteles
en regiones donde la empresa está instalada. La información se recoge periódicamente y es analizada por
economistas expertos de la empresa.
Por último, los servicios adicionales que brinda la empresa a los clientes varían según el hotel. Los mismos
cubren una amplia gama de servicios como servicios a la habitación, paquetes turísticos, afiliación a
sistemas de millas, etc. Estos servicios se irán incorporando y removiendo del sistema, incluso una vez que
éste este en producción. El sistema debe ser capaz de incorporar nuevos módulos (subsistemas) que den
soporte a nuevos servicios.
Los servicios extras que se brinda a los clientes son dinámicos. De todas formas, el agregar o quitar un
nuevo servicio no es un proceso en que el sistema propiamente participará. El sistema es capaz de
incorporar o remover servicios brindados por la cadena hotelera. Nuevos procesos surgirán, incluso una
vez puesto el sistema en producción, de forma de dar soporte a nuevos servicios.
El Subsistema de Reserva contempla tres de las actividades fundamentales del negocio, hacer una reserva,
realizar un check-in y realizar un check-out. La empresa penalizará a aquellos clientes que no cancelen sus
reservas, por lo que se les cobrará por dicho motivo.
La cadena hotelera es una empresa de gran dinamismo, donde nuevos hoteles son incorporados a la misma,
e incluso algunos podrían ser vendidos y quitados del sistema. En cambio, no es común el realizar reformas
edilicias, por lo que los detalles de cada hotel son considerados estáticos.

8
5.1.2. Identificar Procesos de Negocio
El caso de estudio se centra en el Subsistema de Reservas del Sistema de Gestión Hotelera. Para este
subsistema se identifican los siguientes procesos de negocio:
Gerenciamiento de la cadena hotelera (P1)
Este proceso involucra un conjunto de procesos simples encargados del gerenciamiento. Permite
la incorporación de nuevos hoteles al sistema, así como la eliminación de los mismos. Se encarga
además de la administración del personal de la cadena de hoteles.
Reserva de Habitación (P2)
Este proceso administra todas las actividades de reserva por parte de los clientes. Involucra
modificaciones y cancelaciones de reservas, así como la detección de aquellos clientes que no
tomaron su reserva. La actividad de check-in está incluida en este proceso, siendo el camino a un
estado final del mismo.
Check-out y Facturación (P3)
Este proceso cubre el check-out de los huéspedes, así como la facturación de los servicios
contratados por ellos. La contratación de servicios por parte de los huéspedes no forma parte de
este proceso.
Consultas Estadísticas (P4)
Este proceso ocurre cuando la gerencia general realiza un estudio de la situación de la cadena
hotelera. Mediante este proceso se extraerá la información del sistema útil para crear un data-
warehouse sobre el cual realizar variados tipos de estudios.

5.1.3. Clasificar y Ranquear Procesos de Negocio

(P2) y (P3) presentan exigencias de performance. En (P2), las reservas por Internet deben realizarse en
menos de 5 segundos, una vez que el cliente llene su formulario. De igual manera la interoperabilidad con
las agencias de viajes para realizar reservas tiene las mismas exigencias de tiempo de respuesta. El tiempo
de realización de una reserva debe ser menor a 3 minutos cuando el cliente la realiza en la recepción del
hotel o telefónicamente. Para ello, es necesario mantener toda la información posible de visitas anteriores
de los clientes. La información que acumula el sistema por medio de estos procesos da soporte a (P4).
(P1) es importante debido a la gestión de empleados. Las altas y bajas de hoteles y sus descripciones son
casos de uso que potencialmente estarán incluidos en (P2) y (P3). Por ende, puede postergarse la
realización de (P1).
(P4) tiene fines estadísticos y de marketing. La empresa no tiene interés en mantener todo el histórico de
reservas y hospedajes por tiempo indeterminado, sino que mantendrá resúmenes de dicha información.
Estos resúmenes serán obtenidos por medio de (P4). De postergar (P4) se corre el riesgo de no haber
recabado toda la información necesaria en (P2) y (P3). Esto debe considerarse al momento de desarrollar
los mismos.
La tabla de clasificación y ranqueo es la siguiente:
Ranqueo Proceso Justificación
1 (P2) Las restricciones de performance implican un factor de riesgo
para el proyecto.
Ayuda a la comprensión de los pormenores del dominio de
aplicación del sistema de información a desarrollar. Abarca un
conjunto considerable de conceptos del dominio de aplicación.
2 (P3) Presenta también restricciones de performance.
Cubre los aspectos faltantes de los pormenores del dominio. Es
posterior a (P2) dado que la información obtenida del mismo es
la base para este proceso.
3 (P1) Cubre los casos de uso de gerenciamiento de información,
incluyendo la administración del personal. Se realizará previo a
(P4) dado que con (P1), (P2) y (P3) se cubre una parte
fundamental del sistema.
4 (P4) Se realizará en última instancia debido a que es un
requerimiento secundario, ya que no representa una
funcionalidad fundamental del sistema.
Factores tecnológicos deben ser considerados para este proceso
(e.g. herramientas OLAP). Esto debe atacarse en forma paralela
al proceso de desarrollo, de modo de detectar tempranamente

9
 posibles problemas con la interoperabilidad con dichas
herramientas.

5.1.4. Definir la Arquitectura Preliminar

La arquitectura preliminar para el Subsistema de Reservas es la arquitectura de base de la metodología de
desarrollo presentada arriba.

5.1.5. Refinar Proceso de Negocio

El caso de estudio se enfocará en el proceso (P2), que ha calificado en primer lugar en el ranqueo de
procesos.
(P2) permite realizar reservas de habitación en cualquier hotel de la cadena de hoteles. Actualmente cada
hotel tiene su propio sistema, incompatible con el de los otros hoteles de la misma cadena.
Las reservas pueden realizarse por teléfono a través de una central de reservas, por teléfono directamente al
hotel, o vía Internet. El servicio brindado vía Internet será por medio de páginas Web accedidas
directamente por los clientes, o a través de Web Services utilizando documentos XML específicos. Esto
permitirá que los sistemas de las agencias de viajes realicen reservas automáticamente.
Una ventaja importante del nuevo sistema será la habilidad de ofrecer habitaciones alternativas en otros
hoteles de la cadena cuando el hotel deseado no tiene disponibilidad. Dentro de un hotel, facilidades para
realizar reservas debe proveerse en el escritorio de recepción y en las oficinas. Cada hotel tiene un
administrador de reservas que es responsable de controlar las reservas del hotel, pero cualquier usuario
autorizado puede realizar reservas. El tiempo necesario para que el sistema realice una reserva vía Internet
es de 5 segundos. El tiempo necesario para realizar una reserva por teléfono o en persona es de 3 minutos.
Para acelerar el proceso se almacenarán los detalles de los clientes que hayan interactuado con el hotel
anteriormente.
Descripción del proceso.
Primeramente se confirma la disponibilidad de la habitación requerida en el hotel. En el caso de que no
haya disponibilidad, se sugiere habitaciones similares que estén disponibles en otros hoteles cercanos al
hotel requerido. En el caso en que haya disponibilidad para la preferencia del cliente, se procede a hacer la
reserva. Una confirmación de la misma es enviada al cliente, preferentemente por e-mail. Si no es posible
utilizar este mecanismo se hará por correo tradicional. Una vez que la reserva fue realizada pueden ocurrir
cuatro eventos diferentes. El cliente puede solicitar alterar la reserva realizada anteriormente. Para ello se
realiza la modificación y se vuelve a confirmar la reserva. Otro evento es que se desee cancelar la reserva.
Se cancela la misma y finaliza el proceso. Por otro lado, el cliente puede arribar al hotel para hospedarse.
Para ello se toma la reserva, se notifica al sistema de facturación y finaliza el proceso. Por último, puede
ocurrir que el huésped no haya concurrido al hotel dejando así una reserva vencida (cuyo huésped no se
presentó). En estos casos, periódicamente se revisa que reservas no fueron tomadas por los clientes
respectivos. Para aquellas reservas vencidas se notifica al sistema de facturación y finaliza el proceso.
Tomar reserva

llega cliente/

Esperar evento
solicitud/ Cancelar reserva
cancelar/
[habitacion disp]
Ver disponibilidad Hacer reserva

modificar/ cliente NSP/

[else]

Procesar NSP
Modificar reserva

Sugerir Alternativas Confirmar reserva Notificar Facuracion

Figura 8 - Proceso de Negocio (P2)

5.1.6. Realizar el Envisioning del Sistema

Para (P2) se espera que el sistema realice, sin asistencia del usuario, sugerencias de posibles alternativas a las
consulta de reservas fallidas, la confirmación por e-mail de las reservas a los clientes, y que notifique al
sistema de facturación.

10
El proceso de aquellas reservas en las que el cliente asociado no se haya presentado no será realizado en
forma automática por el sistema, sino que se realizará a solicitud del actor involucrado en dicha actividad.
El sistema, además, mediante asistencia del usuario realizará tareas en las otras actividades marcadas en el
proceso.
Debido a estas decisiones, se refina el diagrama de actividad asociando responsabilidades sobre las
actividades por medio de andariveles.
Huesped
Tomar reserva

CreadorDeReserva llega cliente/

<no receive action>

solicitud/ Cancelar reserva
cancelar/
[habitacion disp]
Ver disponibilidad Hacer reserva

modificar/ cliente NSP/

[else]

Procesar NSP
Modificar reserva

System
Sugerir Alternativas Confirmar reserva Notificar Facuracion

Figura 9 - Envisioning del Sistema para el Proceso de Negocio (P2)

5.2. Fase Elaboration

5.2.1. Detectar Actores y Casos de Uso
El envisioning del sistema sugiere dos actores, a saber, el Huésped y el RealizadorDeReserva.
Puede abstraerse los roles que serán jugados por los actores al momento de interactuar con el sistema. De
esta forma podemos considerar los siguientes actores:
Huesped
CreadorDeReserva
AdministradorDeReserva
SistemaDeFacturación

Puede asociarse conceptos del dominio de la aplicación a los actores aquí definidos. El mapeo primario es:
Huésped → Huesped
Cliente → Huésped, CreadorDeReserva
Recepcionista → CreadorDeReserva
Gerente → CreadorDeReserva, AdministradorDeReservas

El actor SistemaDeFacturación representa al sistema de facturación existente en la empresa. La elaboración

y construcción de este ciclo de desarrollo identificará la interfaz que es necesaria de este sistema existente.
Deberá utilizarse un adaptador (Adapter design pattern) para mapear las operaciones de esta interfaz a los
servicios brindados pro el sistema existente.
La detección de aquellos clientes que no se presentaron a tomar su reserva será solicitada por el actor
AdministradorDeReserva. Se decidió que esta actividad no será iniciada automáticamente por el sistema. Si
existe el requerimiento de que el sistema realice en forma automática esta actividad, puede utilizarse un
scheduler de tareas batch el cual actuará como un actor en este proceso.
Las actividades presentes en el diagrama de actividad del proceso de negocio sugieren los siguientes casos
de uso:
Caso de Uso Actividades abarcadas Actores involucrados
(CU2.1) HacerReserva VerDisponibilidad CreadorDeReserva
SugerirAlternativas
HacerReserva
ConfirmarReserva

11
 (CU2.2) CancelarReserva CancelarReserva
(CU2.3) ModificarReserva ModificarReserva
ConfirmarReserva
(CU2.4) TomarReserva TomarReserva
NotificarFacturacion
(CU2.5) ProcesarNSP ProcesarNSP
NotificarFacturacion
CreadorDeReserva
CreadorDeReserva
Huesped
SistemaDeFacturacion
AdministradorDeReservas
SistemaDeFacturacion

5.2.2. Realizar el Modelo Conceptual del Negocio

CadenaHoteles Recepcionista

1 1..* 1 1..*

hotelContactado
Hotel

*
1
1
* 1..*
*
ubicacion
Cliente Reserva Habitacion

1 * * 0..1
1 1 *
*
0..1 direccionContacto

Direccion
0..1 1

1
Cuenta TipoHabitacion

1
0..1
Pago

Figura 10 - Modelo Conceltual del Negocio

5.2.3. Refinar Casos de Uso

Nombre (CU2.1) HacerReserva
Actores CreadorDeReserva
Sinopsis Este caso de uso comienza cuando el CreadorDeReserva chequea la disponibilidad de
una habitación en un hotel dado. Si no hay disponible una habitación como la
solicitada, el sistema sugiere hoteles alternativos. Si la hay, se procede a realizar la
reserva, y se confirma por e-mail al cliente.

Nombre (CU2.2) CancelarReserva

Actores CreadorDeReserva
Sinopsis Este caso de uso comienza cuando el CreadorDeReserva solicita la cancelación de una
reserva. El sistema procede a cancelarla.

Nombre (CU2.3) ModificarReserva

Actores CreadorDeReserva
Sinopsis Este caso de uso comienza cuando el CreadorDeReserva solicita modificar la reserva.
Se procede a modificar la misma.

Nombre (CU2.4) TomarReserva

Actores Huesped, SistemaDeFacturación
Sinopsis Este caso de uso comienza cuando el huésped llega al hotel. Indica la reserva que está a
su nombre. El sistema le asigna una habitación al huésped, y notifica a
SistemaDeFacturación que debe abrirse una cuenta para el cliente.

Nombre (CU2.5) ProcesarNSP

Actores AdministradorDeReservas, SistemaDeFacturacion
Sinopsis Este caso de uso comienza cuando el AdministradorDeReservas solicita que se
procesen aquellas reservas que no han sido tomadas por los clientes. Para cada reserva

12
 vencida el sistema notifica a SistemaDeFacturacion que se cargue a la cuenta del cliente.

Nombre (CU2.6) ABMHotel

Actores AdministradorHotel
Sinopsis Este caso de uso permite administrar la información de un hotel.

Nombre (CU2.7) ABMHabitacion

Actores AdministradorHotel
Sinopsis Este caso de uso permite administrar la información de las habitaciones de un hotel.

Nombre (CU2.8) ABMTipoDeHabitacion

Actores AdministradorHotel
Sinopsis Este caso de uso permite administrar la información de los tipos de habitaciones de un
hotel.

Nombre (CU2.9) ABMRecepcionista

Actores AdministradorHotel
Sinopsis Este caso de uso permite administrar la información de los recepcionistas que trabajan
en un hotel.

Nombre (CU2.10) ModificarCliente

Actores AdministradorDeReservas
Sinopsis Este caso de uso permite modificar la información de un cliente.

Nombre (CU2.11) RemoverClientesInactivos

Actores AdministradorDeReservas
Sinopsis Este caso de uso permite remover la información de los clientes que no hayan realizado
reservas durante el último año.

Nombre (CU2.12) RemoverReservasCaducas

Actores AdministradorDeReservas
Sinopsis Este caso de uso permite eliminar aquellas reservas que ya hayan cumplido un plazo
mayor a un año en el sistema.

Los casos de uso (CU2.2), (CU2.3) y (CU2.4) involucran una secuencia común de las actividades necesarias
para identificar la reserva en cuestión. Se factoriza entonces la secuencia común en un nuevo caso de uso
(CU2.13) IdentificarReserva.
Nombre (CU2.13) IdentificarReserva
Actores Solamente para inclusión
Sinopsis Identifica una reserva existente.

Los casos de uso (CU2.1) y (CU2.3) involucran la actividad de confirmación por e-mail al cliente. Se
factoriza entonces como un nuevo caso de uso (CU2.14) ConfirmarReserva.
Nombre (CU2.14) ConfirmarReserva
Actores Solamente para inclusión
Sinopsis Confirma la reserva al cliente por e-mail.

13
 System

ABMHotel

ABMTipoDeHabitacion

AdministradorHotel
ABMHabitacion

ABMRecepcionista

Figura 11 - Diagrama de Casos de Uso - ABMs

System

«include»
HacerReserva
ConfirmarReserva
«include»

ModificarReserva

CreadorDeReserva
«include» TomarReserva

CancelarReserva
«include»

«include»

IdentificarReserva Huesped

ProcesarNSP

ModificarCliente

AdministradorDeReservas RemoverReservas
Caducas
SistemaDeFacturacion

RemoverClientes
Inactivos

Figura 12 - Diagrama de Casos de Uso - Subsistema de Reservas

5.2.4. Clasificar y Ranquear Casos de Uso

Ranqueo Caso de Uso Justificación
1 CU2.4 Este caso de uso requiere de interacción con el sistema de facturación
TomarReserva existente. Se atacará en primera instancia por el riesgo que implica la
interoperabilidad con el mismo.
Además, este proceso involucra la actividad de check-in, la cual tiene
una restricción importante de tiempo de respuesta. Si el huésped ya
tiene su reserva realizada, el check-in no puede demorar más de 5
segundos.
2 CU2.1 Tiene gran impacto en la arquitectura ya que involucra casi todos los
HacerReserva conceptos del dominio del problema.
3 CU2.5 Presenta interacción con el sistema de facturación existente, lo cual
ProcesarNSP generará nuevos requerimientos sobre este.
4 CU2.3 Representa un caso de uso importante para el proceso de negocio en
ModificarReserva cuestión.
5 CU2.2 Representa un caso de uso importante para el proceso de negocio en
CancelarReserva cuestión.

Los casos de uso CU2.6, CU2.7, CU2.8, CU2.9 y CU2.10 involucran actividades de gerenciamiento de
información, y pueden ser postergados hasta la fase de construcción.

14
Los casos de uso CU2.11 y CU2.12 son de interés para el proceso de negocio. En cambio son
requerimientos secundarios, por lo que pueden ser postergados hasta la fase de construcción.
En la fase de elaboración se atacará solamente el caso de uso CU2.4 por las razones expuestas
anteriormente. Los casos de uso CU2.1, CU2.5, CU2.3 y CU2.2 serán atacados posteriormente.

5.2.5. Refinar Caso de Uso Crítico

En el caso de estudio nos concentraremos en CU2.4 ya que se posicionó primero en el ranqueo.
Nombre (CU2.4) TomarReserva
Actores Huesped, SistemaDeFacturacion
Sinopsis Este caso de uso comienza cuando el huésped llega al hotel. Indica la reserva que está a su
nombre. El sistema le asigna una habitación al huésped, y notifica a SistemaDeFacturacion
que debe abrirse una cuenta para el cliente.
Curso Típico de Eventos
1. El Huesped llega al hotel e indica que tiene una reserva.
2. Incluir CU2.13 (IdentificarReserva).
3. El Huesped confirma los detalles de la duración de su estadía y del tipo de habitación
deseado.
4. El Sistema le asigna una habitación.
5. El Sistema notifica a SistemaDeFacturacion que una estadía ha dado comienzo.
Extensiones
3a. La reserva no fue identificada:
1. Fallo
Cursos alternativos
En 4 el Huesped puede solicitar cambiar los detalles de la estadía.

Dado que CU2.4 incluye al CU2.13, también se refina este último.

Nombre (CU2.13) IdentificarReserva
Actores Solamente para inclusión
Sinopsis Identifica una reserva existente.
Curso Típico de Eventos
1. El Actor indica el identificador de la reserva.
2. El Sistema localiza la reserva.
Extensiones
2a. El Sistema no encuentra la reserva con el identificador indicado
1. El Actor provee el nombre del cliente.
2. El Sistema muestra las reservas activas para el cliente con dicha información.
3. El Actor elige la reserva correspondiente.
4. Fin.
2b. El identificador indicado refiere a una reserva en otro hotel.
1. Fallo.
2c. No hay reservas activas para el cliente en este hotel.
1. Fallo.

5.2.6. Identificar Componentes

Identificar Interfaces y Operaciones del Sistema
Las interfaces de sistema y sus operaciones (iniciales) surgen del modelo de casos de uso.
En primer lugar se define un Dialog Type y una Interfaz de Sistema para cada caso de uso, i.e.
CU2.4 y CU2.13. La siguiente figura muestra el mapeo de los casos de uso a las interfaces de
sistema.

15
 Nombre (CU2.13) IdentificarReserva
Actores Solamente para inclusión
Sinopsis Identifica una reserva existente.
Curso Típico de Eventos
1. El Actor indica el identificador de la reserva.
2. El Sistema localiza la reserva.
Extensiones
2. El Sistema no encuentra la reserva con el identificador indicado
a. El Actor provee nombre y código postal.
b. El Sistema muestra las reservas activas para el cliente con dicha información.
«derived»
c. El Actor elige la reserva correspondiente.
d. Fin.
«interface type»
2. El identificador indicado refiere a una reserva en otro hotel. IIdentificarReserva
a2. Fallo.
2b. No hay reservas activas para el cliente en este hotel. getReserva()
a. Fallo.

«becomes»

IdentificarReserva
«instance»

«include»
«dialog type»
«instance» DlgTomarReserva

TomarReserva

«becomes»

Nombre (CU2.4) TomarReserva

«derived»
Actores Huesped, SistemaDeFacturación «interface type»
Sinopsis Este caso de uso comienza cuando el huésped llega al hotel. Indica la reserva que está
a su nombre. El sistema le asigna una habitación al huésped, y notifica a
SistemaDeFacturación que debe abrirse una cuenta para el cliente.
ITomarReserva
Curso Típico de Eventos
1. El Huesped llega al hotel e indica que tiene una reserva.
comenzarEstadia()
2. Incluir CU2.13 (IdentificarReserva).
3. El Huesped confirma los detalles de la duración de su estadía y del tipo de
habitación deseado.
4. El Sistema le asigna una habitación.
5. El Sistema notifica a SistemaDeFacturacion que una estadía ha dado comienzo.
Extensiones
3. La reserva no fue identificada
a. Fallo
Cursos alternativos
En 4 el Huesped puede solicitar cambiar los detalles de la estadía.

Figura 13 - Mapeo de CU2.4 a interfaces de sistema

En el caso de uso CU2.4 el Huesped llega al hotel e indica que tiene una reserva. Se procede a
identificar la reserva del Huesped utilizando CU2.13 especificado en IIdentificarReserva. La
operación getReserva() es utilizada para dicho fin. Los detalles de la reserva son confirmados por
el Huesped. Para comenzar la estadía, el sistema asigna una habitación y notifica al Sistema de
Facturación que la estadía ha dado comienzo. Estas actividades son realizadas por la operación
comenzarEstadia().

Las interfaces que se han definido se encuentran en la capa Servicios del Sistema.
Definir el Modelo de Tipos del Negocio
Se eliminó el concepto CadenaDeHoteles ya que el Sistema solo representa a una cadena de hoteles.
La asociación Hotel-Cliente fue eliminada ya que no será mantenida por el Sistema. Las cuentas y
los pagos serán responsabilidad del Sistema de Facturación, por lo que también es eliminado. El
concepto Recepcionista no esta ligado a las funcionalidades del caso de uso en consideración, por lo
que también es eliminado.
Se refinó el modelo agregando atributos para los tipos participantes y definiendo un conjunto de
tipos de datos y restricciones en el modelo.
Se agregaron además reglas para el precio y la disponibilidad, por lo que se agregaron nuevos
atributos para reflejar las reglas.
Reglas de disponibilidad:
▪ (R1) Una tipo de habitación esta disponible si la cantidad de habitaciones reservadas en todas las
fechas del rango de fechas es menor que la cantidad de habitaciones. Se agregó un atributo
parametrizado disponible() en TipoHabitacion en donde se ubicará esta regla.
▪ (R2) Nunca se puede tener más reservas para un tipo de habitación en una fecha que
habitaciones de ese tipo (no hay overbooking).

16
Reglas de precios:
▪ (R3) El precio de un tipo de habitación para una estadía es la suma de los precios para cada día
de la estadía. Para capturar esta regla se agregó un atributo parametrizado por fecha, teniendo
así un precio variable en el modelo. Se agregó un atributo parametrizado precioEstadia() en
donde se ubicará esta regla de negocio.
Se detectó que Hotel y Cliente son core types. Un core type es un business type cuya existencia es
independiente dentro del negocio. Los otros tipos de negocio, como ser TipoHabitacion,
Habitacion y Reserva, son tipos que dependen (existencialmente) del Hotel. Los core types han sido
indicados en el Modelo de Tipos del Negocio con el estereotipo «core». Todos los otros tipos del
modelo aportan detalles a los core types.
«type»
«core» TipoHabitacion
Hotel 1
1 1..* nombre : String
nombre : String
precio(in f : Fecha) : Importe
1 precioEstadia(in rf : RangoFechas) : Importe
1 disponible(in rf : RangoFechas) : Boolean

*
*
«core»
«type»
Cliente «type»
Reserva ubicacion
nombre : String Habitacion
rid : String *
direccion : Direccion 1 * numero : String
fechas : RangoFechas
email : String
* 0..1

Figura 14 - Modelo de Tipos del Negocio para (P2)

Restricciones:
context Hotel inv:
self.habitacion.tipoHabitacion→asSet() = self.tipoHabitacion

context Reserva inv:

self.habitacion→notEmpty() implies
(self.habitacion.hotel = self.hotel and
self.habitacion.tipoHabitacion = self.tipoHabitacion)

context TipoHabitacion def:

-- R1
let disponible(rf : RangoFechas) : Boolean =
let cantHab : Integer = self.habitacion→size()
let cantResFecha(f : Fecha) : Integer =
self.reserva→select(r | r.fechas.includes(f))→size()
in
rf.asSet()→forall(f | self.cantResFecha(f) < self.cantHab)

context TipoHabitacion inv:

-- R2
let fechasConReserva : Set(Fecha) =
self.reserva→collect(fechas.asSet())→asSet()
let cantHab : Integer = self.habitacion→size()
let cantResFecha(f : Fecha) : Integer =
self.reserva→select(r | r.fechas.includes(f))→size()
in
self.fechasConReserva→forall(f |
self.cantResFecha(f) <= self.cantHab)

context TipoHabitacion def:

-- R3
let precioEstadia(rf : RangoFechas) : Importe =
rf.asSet()→collect(d | self.precio(d))→sum()

17
 «datatype» «datatype» «datatype» «datatype»
Boolean String Fecha Importe

«datatype» «datatype»
RangoFechas Direccion
inicio : Fecha Calle : String
fin : Fecha CodigoPostal : String
asSet() : Set(Fecha) Estado : String
includes(in : Fecha) : Boolean Pais : String

Figura 15 - Tipos de Datos para CU2.4

Definir Interfaces del Negocio

Se crea una interfaz de negocio por cada core type detectado. Cada interfaz de negocio administra la
información representada por el core type y los tipos que lo categorizar.
Se utiliza el sufijo Mgt (de Management, o Gerenciador) debido a que estas interfaces manejarán un
conjunto de instancias del core type. Las interfaces de negocio serán IHotelMgt e IClienteMgt.
Notar que no se esta tomando al propio core type como interfaz de negocio, sino que la interfaz
administrará el conjunto de todas sus instancias.
Se agrega dos tipos de datos adicionales que representarán los identificadores de los core types
manejados, a saber HotelId y ClienteId.
La responsabilidad sobre el tipo Reserva es asignada al Hotel dado que esta acoplado con más
información de éste que del Cliente.
Se resumen las actividades realizadas en el siguiente diagrama de responsabilidades de interfaces de
negocio.
«interface type» «type»
1 * «core»
IHotelMgt TipoHabitacion
Hotel 1
1 1..* nombre : String
nombre : String
precio(in f : Fecha) : Importe
1 precioEstadia(in rf : RangoFechas) : Importe
1 disponible(in rf : RangoFechas) : Boolean

*
*
«core»
«type»
Cliente «type»
Reserva ubicacion
nombre : String Habitacion
rid : String *
direccion : Direccion 1 * numero : String
fechas : RangoFechas
email : String
* 0..1

*
*
1

«interface type»
IClienteMgt

Figura 16 - Diagrama de Responsabilidades de Interfaces de Negocio para CU2.4

Identificar Interfaces de Sistemas Existentes

Se identifica un sistema existente necesario para llevar a cabo el caso de uso CU2.4. El mismo es el
Sistema de Facturación, considerado como un actor en los documentos de casos de uso, y que
participa en CU2.4. Este sistema existente, en uso por la empresa, será representado por la interfaz
ISistemaDeFacturacion. Las operaciones que esta interfaz debe soportar serán detectadas en
próximas etapas. Será necesario que el componente que realice esta interfaz cumpla la función de
adaptador (Adapter Design Pattern), adaptando los parámetros y tipos de retorno y el mecanismo
de invocación al sistema real. Posiblemente este componente deba hacer persistente cierta
información que lo asista en el mapeo de la información manejada en este sistema y la manejada en
el sistema real.
Crear Especificación y Arquitectura Inicial
Una arquitectura de componentes se define como un conjunto de componentes de software a nivel
de aplicación, sus relaciones estructurales y sus dependencias de comportamiento. Esta es una
definición lógica e independiente de la tecnología. Un componente es la unidad de desarrollo,

18
 deployment y reemplazo en un sistema basado en componentes. El componente será el building
block del Sistema.
Las interfaces de sistema detectadas a partir de los casos de uso de un mismo proceso se solapan
fuertemente. Por dicha razón se crea una especificación de componente SistemaDeReserva
encargada de dar soporte a dichas interfaces. Inicialmente se cuenta con las interfaces
correspondientes a los dos casos de uso que se esta tratando en esta iteración, a saber,
ITomarReserva e IIdentificarReserva.

Se tendrá además una especificación de componente para cada sistema existente detectado en
etapas anteriores. Por ello, se incluye SistemaDeFacturacion.
Para las interfaces de negocio, el punto de partida será tener una especificación de componente por
cada interfaz detectada. Por lo tanto se tendrá HotelMgr y ClienteMgr para IHotelMgt e
IClienteMgt respectivamente. Se utiliza el sufijo Mgr (de Manager, o Gerenciador) para estas
especificaciones de componente.
La dependencia entre los componentes puede resultar intuitiva. Sin embargo se esperará a la
siguiente etapa para detectarla. Debido a ello la arquitectura inicial es prácticamente desconexa.
ITomarReserva
ISistemaDeFacturacion
IIdentificarReserva

«comp spec» «comp spec»

SistemaDeFacturacion SistemaDeReservas

«comp spec» «comp spec»

IHotelMgt IClienteMgt
HotelMgr ClienteMgr

Figura 17 - Arquitectura Inicial para el proceso P2

5.2.7. Interacción de Componentes

Refinar Interfaces y Operaciones de Sistema
getReserva()

Se sabe del caso de uso CU2.13 que la operación debe obtener los detalles de la reserva
correspondiente al identificador provisto por el actor. Se define entonces un tipo de datos que
represente a la información de una reserva. Generalizaremos esta operación devolviendo además los
detalles del cliente que realizó la reserva.
IIdentificarReserva::getReserva(
in rid : String,
out dr : DetallesReserva,
out dc : DetallesCliente)
signals ReservaInexistente

El parámetro rid es el identificador de la reserva, dr son los detalles de la reserva con identificador
rid, y dc son los detalles del cliente que realizó la reserva. ReservaInexistente indica que el
identificador de la reserva provisto no existe en el Sistema.
getReservasCliente()

Notar que el caso de uso CU2.13 presenta extensiones al curso típico de eventos. Que la reserva
corresponda a otro hotel no será corroborado por esta operación, por lo que deberá ser
corroborado por algún componente en una capa superior. Se necesita, en cambio, una operación
que permita detectar todas las reservas activas que corresponden a un cliente determinado. Se
agrega entonces la operación getReservasCliente(). Esta operación recibe el identificador de un
Cliente y devuelve las reservas activas del mismo. La lógica del caso de uso, manejada en el diálogo
de usuario, al no encontrar la reserva deseada debe buscar un cliente según los criterios de búsqueda
del cliente. Una vez elegido el mismo, debe buscar las reservas de un cliente dado, según su
identificador.
IIdentificarReserva::getReservasCliente(
in cid : ClienteId)
: Set(DetallesReserva)

19
El parámetro cid es el identificador del cliente. La operación devuelve un conjunto con los detalles
de las reservas activas del cliente.
comenzarEstadia()

Una vez ubicada la reserva que será tomada por el Huesped, se indica al Sistema que una estadía
dará comienzo mediante esta operación. Según el caso de uso CU2.4 el Sistema debe asignar una
habitación a la reserva e indicar al usuario la habitación en la que se hospedará. Se notifica además al
Sistema de Facturación que debe abrir una cuenta para un nuevo cliente. Se cobrará por la estadía al
momento del check-out (proceso de negocio P3). En ese momento se conoce exactamente la
cantidad de días que se ha hospedado el Huesped.
ITomarReserva::comenzarEstadia(
in rid : String,
out n : String)

El parámetro rid es el identificado de la reserva y n representa el número de habitación que el

Sistema asoció a la reserva.
Descubrir Operaciones de Interfaces de Negocio
Se presenta a continuación los diagramas de colaboración para las operaciones refinadas en la
actividad anterior.
dr)
a(rid,
Reserv / IHotelMgt
etalles
1: getD
getReserva(rid, dr, dc)

: SistemaDeReservas 2: d
/ IIdentificarReserva c :=
g et
D et
alle
sCli
e n te
( dr .
clie
n te
)

/ IClienteMgt

Figura 18 - Operación SistemaDeReservas::getReserva()

drs := getReservasCliente(cid) 1: drs := getReservasCliente(cid)

: SistemaDeReservas / IHotelMgt
/ IIdentificarReserva

Figura 19 - Operación SistemaDeReservas::getReservasCliente()

dr)
(rid, / IHotelMgt
erva )
lle sRes dia(rid,n
tDeta rEsta
1: ge omenza
2: c

comenzarEstadia(rid, n) 3: dc := getDetallesCliente(dr.cliente)

: SistemaDeReservas / IClienteMgt
/ ITomarReserva
4: a
brirC
uen
ta(d
r, dc
)

/ ISistemaDeFacturacion

Figura 20 - Operación SistemaDeReservas::comenzarEstadia()

La siguiente figura muestra las interfaces y operaciones descubiertas en esta etapa. Estas últimas son
obtenidas de las interacciones realizadas.

20
 «interface type»
IIdentificarReserva

getReserva(in rid : String, out dr : DetallesReserva, out dc : DetallesCliente)

getReservasCliente(in cid : ClienteId) : Set(DetallesReserva)

«interface type»
ITomarReserva

comenzarEstadia(in rid : String, out n : String)

«interface type»
IHotelMgt

getDetallesReserva(in rid : String, out dr : DetallesReserva)

getReservasCliente(in cid : ClienteId) : Set(DetallesReserva)
comenzarEstadia(in rid : String, out n : String)

«interface type»
IClienteMgt

getDetallesCliente(in cid : ClienteId) : DetallesCliente

«interface type»
ISistemaDeFacturacion

abrirCuenta(in dr : DetallesReserva, in dc : DetallesCliente)

Figura 21 - Refinamiento de Operaciones e Interfaces

Por completitud, se presenta los tipos de datos manejados.

«datatype» «datatype»
DetallesReserva DetallesCliente
hotel : HotelId id : ClienteId
fechas : RangoFechas nombre : String
tipoHabitacion : String direccion : Direccion
cliente : ClienteId email : String

«datatype» «datatype»
HotelId ClienteId

Figura 22 - Nuevos Tipos de Datos

Definir Políticas de Manejo de Integridad Referencial

Una instancia del componente SistemaDeReservas trabajará siempre con la misma instancia que de
soporte a cada una de las interfaces que necesita. Se indica a continuación la arquitectura a nivel de
instancia de componente (Component Object Architecture) del Sistema de Reservas, la cual define
en parte las políticas de manejo de integridad referencial.
«interface type»
IHotelMgt
{frozen} 1

«comp spec» «interface type»

SistemaDeReservas IClienteMgt
{frozen} 1

«interface type»
ISistemaDeFacturacion
{frozen} 1

Figura 23 - Arquitectura a Nivel de Instancia

En lo referente al control de referencias entre componentes de negocio, se detectó una única

asociación entre elementos correspondientes a distintos componentes. La responsabilidad fue
asignada tal como lo muestra la siguiente figura.

21
 Figura 24 - Responsabilidad de asociaciones entre componentes

Hay distintas opciones para asegurar que las referencias entre componentes sean válidas; estas son:
▪ La responsabilidad se le asigna al Component Object que almacena la referencia; se le da
responsabilidad total y exclusiva
▪ La responsabilidad se le asigna al Component Object al que pertenece el objeto de la referencia;
éste debe tener un mecanismo para saber cuáles componentes tienen referencias a él y
notificarlos según corresponda
▪ La responsabilidad se le asigna a un tercer Component Object, generalmente más arriba en la
cadena de llamadas
▪ Permitir y tolerar referencias inválidas
▪ Deshabilitar la baja de información
Considerando las tres primeras opciones, se presenta a continuación cual sería la decisión a tomar
para cada una de ellas:
▪ Todas las solicitudes para eliminar un cliente son enviadas a HotelMgr, quien le enviará la
solicitud a ClienteMgr. Ningún otro Component Object podrá acceder a ClienteMgr.
▪ ClienteMgr notifica a HotelMgr sobre la eliminación de un Cliente (aplicación de Observer)
▪ SistemaDeReserva será responsable de eliminar clientes interactuando con ClienteMgr y
HotelMgr
Refinar la Arquitectura
La arquitectura de componentes refinada para el proceso P2 se presenta en la siguiente figura.
«dialog type»
IDlgTomarReserva
DlgTomarReserva

IIdentificarReserva

ISistemaDeFacturacion
ITomarReserva

«comp spec» «comp spec»

SistemaDeReservas SistemaDeFacturacion

IHotelMgt IClienteMgt

«comp spec» «comp spec»

HotelMgr ClienteMgr

Figura 25 - Arquitectura Refinada para P2

22
5.3. Fase Construction
5.3.1. Definir Modelos de Información para Interfaces

Figura 26 - Modelo de Información para IClienteMgt

Figura 27 - Modelo de Información para IHotelMgt

Las restricciones en el modelo de información de IHotelMgt son las siguientes:

context r : Reserva inv:
-- Una reserva fue tomada cuando tiene una habitación asignada
r.tomada = r.ubicacion->notEmpty()

context TipoHabitacion inv:

-- No hay overbooking

let fechasConReserva : Set(Fecha) =

self.reserva→collect(fechas→asSet())→asSet()

let cantHab : Integer = self.habitacion→size()

let cantResFecha(f : Fecha) : Integer =

self.reserva→select(r | r.fechas→includes(f))→size()
in
self.fechasConReserva→forall(f |
self.cantResFecha(f) <= self.cantHab)

23
 Figura 28 - Modelo de Información para IIdentificarReserva

Figura 29 - Modelo de Información para ITomarReserva

5.3.2. Especificar pre- y poscondiciones

Las pre- y poscondiciones pueden ser expresadas en lenguaje natural o en un lenguaje formal como OCL.
Se presenta a continuación las pre- y poscondiciones para la operación getDetallesCliente() de la
interfaz IClienteMgt.
context IClienteMgt::getDetallesCliente(in id:ClienteID) : DetallesCliente

pre: -- id es un identificador de cliente valido

cliente->exists(c | c.id = cli)

post: -- lo retornado son los detalles del cliente solicitado

let c = cliente->select(c | c.id = cli)->asSequence()->first() in
result.nombre = c.nombre and
result.codPost = c.codPost and
result.email = c.email

Se presenta además las pre- y poscondiciones para la operación comenzarEstadia() de la interfaz

IHotelMgt.
context IHotelMgt::comenzarEstadia(in rid:String, out n:String)

pre: -- debe haber una habitación disponible del tipo de habitación

-- de la reserva en la fecha de la reserva

let r := reserva->select(res | res.id = rid)->any()

let habs := reserva.hotel.habitacion->asSet() in

habs->exists(h | h.tipoHabitacion = r.tipoHabitacion and

h.reserva.fecha.asSet()->asSet()
) ->excludesAll(r.fecha.asSet())

and

24
 -- la reserva no debe estar tomada
r.tomada = false

post:
let r := reserva->select(res | res.id = rid)->any()
let habs := reserva.hotel.habitacion->asSet()
let h := habs->exists(h | h.tipoHabitacion = r.tipoHabitacion and
h.reserva.fecha.asSet()->asSet())->any()
in
r.habitacion = h and
r.tomada = true and
n = h.nombre and
h.reserva = h.reserva@pre->including(r)

5.3.3. Especificar Restricciones de Componentes e Interfaces

Se incluye aquí las restricciones entre los modelos de información ofrecidos por algunas de las interfaces
identificadas.
context SistemaDeReserva inv:
IIdentificarReserva::hotel = ITomarReserva::hotel and
IIdentificarReserva::reserva = ITomarReserva::reserva and
IIdentificarReserva::cliente = ITomarReserva::cliente and
IIdentificarReserva::tipoHabitacion = ITomarReserva::tipoHabitacion

context SistemaDeReserva inv:

IIdentificarReserva::hotel = IHotelMgt::hotel and
IIdentificarReserva::reserva = IHotelMgt::reserva and
IIdentificarReserva::tipoHabitacion = IHotelMgt::tipoHabitacion and
IIdentificarReserva::cliente = IClienteMgt::cliente

6. Conclusiones y Trabajo Futuro

La única constante en el desarrollo de aplicaciones es que las cosas cambian: los requerimientos, los
usuarios, los equipos de desarrollo, las tecnologías, etc. Procesos de ingeniería de software seguidos
adecuadamente junto con un buen equipo de desarrollo puede producir aplicaciones de alta calidad que
satisfagan los requerimientos del negocio. Sin embargo, esto no puede impedir que los requerimientos o
tecnologías cambien.
La utilización de un enfoque basado en componentes independiente de la tecnología, acompañado de una
metodología como la propuesta que presta particular atención a la especificación y a la arquitectura, puede
posicionar de mejor manera a los desarrolladores para crear aplicaciones robustas, adaptables y bajo
presupuestos factibles.
La metodología ha sido impartida en cursos de grado y de actualización profesional. En los mismos se han
realizado trabajos que profundizan en el entendimiento de la misma. Actualmente se esta trabajando en el
mapeo de arquitecturas de especificaciones de componentes a arquitecturas en tecnologías especificas así
como en el desarrollo completo de sistemas utilizando la misma.

7. Referencias Bibliográficas
[CD] UML Components
John Cheesman, John Daniels
Addison-Wesley, 2001
ISBN 0-201-70851-5
[RUP] Rational Unified Process
Racional Software Corporation, 2002
http://www.rational.com/rup
[Lar] Applying UML and Patterns
Craig Larman
Prentice-Hall, 2002
ISBN 0-13-092569-1

25