1

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

2

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.

3

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

Servicios del Sistema Servicios básicos del sistema Usualmente corriendo en el marco de una transacción A

plica

ción

Servicios del Negocio Tipos estables del negocio Manejo de la información del sistema Usualmente asociados a fuentes de datos

Sistema

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

4

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.

5

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.

6

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.

7

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

8

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.

9

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

10

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.

Ver disponibilidad Hacer reserva

Confirmar reserva

Modificar reserva

Tomar reserva

Cancelar reserva

Procesar NSP

Notificar Facuracion

[habitacion disp]

[else]

llega cliente/

cancelar/

cliente NSP/modificar/

Esperar eventosolicitud/

Sugerir Alternativas

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.

11

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.

CreadorDeReserva

System

Huesped

Ver disponibilidad Hacer reserva

Confirmar reserva

Modificar reserva

Tomar reserva

Cancelar reserva

Procesar NSP

Notificar Facuracion

[habitacion disp]

[else]

llega cliente/

cancelar/

cliente NSP/modificar/

<no receive action>solicitud/

Sugerir Alternativas

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

SugerirAlternativas HacerReserva ConfirmarReserva

CreadorDeReserva

12

(CU2.2) CancelarReserva CancelarReserva CreadorDeReserva (CU2.3) ModificarReserva ModificarReserva

ConfirmarReserva CreadorDeReserva

(CU2.4) TomarReserva TomarReserva NotificarFacturacion

Huesped SistemaDeFacturacion

(CU2.5) ProcesarNSP ProcesarNSP NotificarFacturacion

AdministradorDeReservas SistemaDeFacturacion

5.2.2. Realizar el Modelo Conceptual del Negocio CadenaHoteles

Cliente

Direccion

Pago

Hotel

Reserva

Cuenta

Recepcionista

Habitacion

TipoHabitacion

1 1..*

*

hotelContactado

*

1*

1 *

1

direccionContacto0..1

1

0..1

1

0..1

*

1

*

ubicacion

0..1

1

1..*

1 1..*

*

1

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

13

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.

14

ABMHotel

ABMRecepcionista

ABMHabitacion

ABMTipoDeHabitacion

AdministradorHotel

System

Figura 11 - Diagrama de Casos de Uso - ABMs

AdministradorDeReservas

CreadorDeReserva

Huesped

SistemaDeFacturacion

System

CancelarReserva

HacerReserva

IdentificarReserva

«include»

«include»

ModificarReserva

TomarReserva

«include»

ConfirmarReserva«include»

«include»

ModificarCliente

ProcesarNSP

RemoverClientesInactivos

RemoverReservasCaducas

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

TomarReserva Este caso de uso requiere de interacción con el sistema de facturación 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 HacerReserva

Tiene gran impacto en la arquitectura ya que involucra casi todos los conceptos del dominio del problema.

3 CU2.5 ProcesarNSP

Presenta interacción con el sistema de facturación existente, lo cual generará nuevos requerimientos sobre este.

4 CU2.3 ModificarReserva

Representa un caso de uso importante para el proceso de negocio en cuestión.

5 CU2.2 CancelarReserva

Representa un caso de uso importante para el proceso de negocio en 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.

15

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.

16

TomarReserva

«dialog type»DlgTomarReserva

«becomes»

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.

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

3. La reserva no fue identificada

a. Fallo

Cursos alternativos

En 4 el Huesped puede solicitar cambiar los detalles de la estadía.

comenzarEstadia()

«interface type»ITomarReserva

«derived»

getReserva()

«interface type»IIdentificarReserva

«instance»

IdentificarReserva

«include»

«instance»

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.

c. El Actor elige la reserva correspondiente.

d. Fin.

2. El identificador indicado refiere a una reserva en otro hotel.

a2. Fallo.

2b. No hay reservas activas para el cliente en este hotel.

a. Fallo.

«becomes»

«derived»

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).

17

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.

nombre : String

«core»Hotel

nombre : Stringdireccion : Direccionemail : String

«core»Cliente

rid : Stringfechas : RangoFechas

«type»Reserva

precio(in f : Fecha) : ImporteprecioEstadia(in rf : RangoFechas) : Importedisponible(in rf : RangoFechas) : Boolean

nombre : String

«type»TipoHabitacion

numero : String

«type»Habitacion

1 *

1

*

1 1..*

1

*

1

*

*

ubicacion

0..1

*

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 andself.habitacion.tipoHabitacion = self.tipoHabitacion)

context TipoHabitacion def:-- R1let disponible(rf : RangoFechas) : Boolean =

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

self.reserva→select(r | r.fechas.includes(f))→size()inrf.asSet()→forall(f | self.cantResFecha(f) < self.cantHab)

context TipoHabitacion inv:-- R2let 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()inself.fechasConReserva→forall(f |

self.cantResFecha(f) <= self.cantHab)

context TipoHabitacion def:-- R3let precioEstadia(rf : RangoFechas) : Importe =

rf.asSet()→collect(d | self.precio(d))→sum()

18

«datatype»Boolean

«datatype»Importe

«datatype»Fecha

asSet() : Set(Fecha)includes(in : Fecha) : Boolean

inicio : Fechafin : Fecha

«datatype»RangoFechas

«datatype»String

Calle : StringCodigoPostal : StringEstado : StringPais : String

«datatype»Direccion

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.

nombre : String

«core»Hotel

nombre : Stringdireccion : Direccionemail : String

«core»Cliente

rid : Stringfechas : RangoFechas

«type»Reserva

precio(in f : Fecha) : ImporteprecioEstadia(in rf : RangoFechas) : Importedisponible(in rf : RangoFechas) : Boolean

nombre : String

«type»TipoHabitacion

numero : String

«type»Habitacion

1 *

1

*

1 1..*

1

*

1

*

*

ubicacion

0..1

*

1

«interface type»IHotelMgt

«interface type»IClienteMgt

*1

1

*

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,

19

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.

«comp spec»SistemaDeReservas

ITomarReserva

«comp spec»SistemaDeFacturacion

«comp spec»ClienteMgr

«comp spec»HotelMgr IClienteMgtIHotelMgt

ISistemaDeFacturacionIIdentificarReserva

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)

20

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.

getReserva(rid, dr, dc)

/ IIdentificarReserva : SistemaDeReservas

/ IHotelMgt1: getDetallesReserva(rid, dr)

/ IClienteMgt

2: dc := getDetallesCliente(dr.cliente)

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

drs := getReservasCliente(cid)

/ IIdentificarReserva : SistemaDeReservas / IHotelMgt

1: drs := getReservasCliente(cid)

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

comenzarEstadia(rid, n)

/ ITomarReserva : SistemaDeReservas

/ IHotelMgt

1: getDetallesReserva(rid, dr)

2: comenzarEstadia(rid,n)

/ IClienteMgt

3: dc := getDetallesCliente(dr.cliente)

/ ISistemaDeFacturacion

4: abrirCuenta(dr, dc)

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.

21

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

«interface type»ITomarReserva

getReserva(in rid : String, out dr : DetallesReserva, out dc : DetallesCliente)getReservasCliente(in cid : ClienteId) : Set(DetallesReserva)

«interface type»IIdentificarReserva

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

«interface type»IHotelMgt

getDetallesCliente(in cid : ClienteId) : DetallesCliente

«interface type»IClienteMgt

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

«interface type»ISistemaDeFacturacion

Figura 21 - Refinamiento de Operaciones e Interfaces

Por completitud, se presenta los tipos de datos manejados.

hotel : HotelIdfechas : RangoFechastipoHabitacion : Stringcliente : ClienteId

«datatype»DetallesReserva

id : ClienteIdnombre : Stringdireccion : Direccionemail : String

«datatype»DetallesCliente

«datatype»ClienteId

«datatype»HotelId

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.

«comp spec»SistemaDeReservas

«interface type»IHotelMgt

«interface type»IClienteMgt

«interface type»ISistemaDeFacturacion

1

1

1

{frozen}

{frozen}

{frozen} 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.

22

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.

«comp spec»SistemaDeReservas

ITomarReserva

«comp spec»SistemaDeFacturacion

«comp spec»ClienteMgr

«comp spec»HotelMgr

IClienteMgtIHotelMgt

ISistemaDeFacturacion

IIdentificarReserva

«dialog type»DlgTomarReserva IDlgTomarReserva

Figura 25 - Arquitectura Refinada para P2

23

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 asignadar.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()

inself.fechasConReserva→forall(f |

self.cantResFecha(f) <= self.cantHab)

24

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 validocliente->exists(c | c.id = cli)

post: -- lo retornado son los detalles del cliente solicitadolet c = cliente->select(c | c.id = cli)->asSequence()->first() in

result.nombre = c.nombre andresult.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 andh.reserva.fecha.asSet()->asSet()

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

and

25

-- la reserva no debe estar tomadar.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 andr.tomada = true andn = h.nombre andh.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 andIIdentificarReserva::reserva = ITomarReserva::reserva andIIdentificarReserva::cliente = ITomarReserva::cliente andIIdentificarReserva::tipoHabitacion = ITomarReserva::tipoHabitacion

context SistemaDeReserva inv:IIdentificarReserva::hotel = IHotelMgt::hotel andIIdentificarReserva::reserva = IHotelMgt::reserva andIIdentificarReserva::tipoHabitacion = IHotelMgt::tipoHabitacion andIIdentificarReserva::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