Enfoque Metodolgico para el Desarrollo Basado en Componentes

Andrs Vignaga, Daniel Perovich

{avignaga, perovich}@fing.edu.uy Instituto de Computacin Facultad de Ingeniera Universidad de la Repblica 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 tcnicas a aplicar para la produccin 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 ms caractersticos del desarrollo actualmente, un software de calidad debe estar preparado para absorber este tipo de cambios con el menor impacto posible. La definicin 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 tecnologas aplicables, tanto para el desarrollo como para el deploy de los sistemas, por lo que dicha arquitectura de componentes no debe apoyarse en una implementacin particular sino en una especificacin de los mismos. En este trabajo se proponen actividades que guan la especificacin de una arquitectura basada en componentes e independiente de la tecnologa 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. Introduccin
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 estn relacionados, los mismos son aplicables a sistemas de distinto porte. Generalmente OOD es asociado con Programming-in-the-Small, mientras que CBD es ms 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 metodologas para adecuarlas a la plataforma sobre la cual montarn sus desarrollos. Este cambio en las metodologas, generalmente en forma ad hoc, ha llevado a que los artefactos construidos durante el diseo sean particulares a la tecnologa a utilizar. Este hecho no es beneficioso considerando que las tecnologas de componentes son tecnologas emergentes y en continua evolucin. El presente artculo es el resultado del trabajo de investigacin de los autores en esta rea. Como anexo de este documento se encuentran tres juegos de transparencias que ahondan en distintos puntos de la metodologa. La estructura de este documento es la siguiente: la primera seccin presenta los principios que rigen el paradigma de componentes. La segunda seccin presenta las lneas generales de la metodologa, basada en la propuesta del Racional Unified Process [RUP]. La adecuacin de los workflows de las disciplinas del RUP en la metodologa propuesta es presentada en la tercera seccin. La cuarta seccin muestra la aplicacin de la metodologa 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 aplicacin de la tcnica de divide & conquer para manejar la complejidad. La diferencia principal con los mtodos estructurados es principalmente que el anlisis y diseo es realizado dentro del mismo paradigma que la implementacin. Esta implementacin queda relegada a un segundo plano, siendo importante dar una solucin lgica al problema, previo a su codificacin. Este principio fue utilizado en el paradigma de orientacin a objetos, el hecho de combinar operaciones e informacin en una misma unidad, y de contar con tcnicas de modelado dentro del mismo paradigma, hizo que la orientacin a objetos tuviera un xito importante. El principal objetivo que se persigui con la introduccin de este paradigma fue el reuso. A pesar de contar con tcnicas de buenas prcticas de diseo, como ser los patrones GRASP [Lar], no es sencillo mantener las unidades de software (i.e. clases) con el nivel de acoplamiento y cohesin 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 razn, 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 produccin. El principal objetivo de un componente no es el reuso sino que sea fcilmente reemplazable. El hecho de ser reemplazable implica que una nueva implementacin de un componente pueda ser utilizada en lugar de una implementacin 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 implementacin 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 evala el impacto del cambio y no en base a informacin local. Las decisiones internas a los componentes son un objetivo secundario, siendo lo primordial su interaccin 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 orientacin a objetos: unificacin 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 especificacin del componente y no de su implementacin. Esta importante separacin es la clave para reducir el acoplamiento y el buen manejo de las dependencias. 2

La especificacin de un componente esta formada por un conjunto de interfaces que describen el comportamiento del componente. Las interfaces describen este comportamiento en funcin de un modelo de informacin, el cual es una proyeccin del modelo de informacin 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 especificacin de componente permitiendo de esta forma contar con la propiedad de reemplazabilidad.

3. Metodologa de Desarrollo Basada en Componentes

La metodologa 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 trmino 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 funcin determinada. La arquitectura presenta adems 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 relacin de dependencia se encuentran. Como fue mencionado antes, la metodologa aqu propuesta busca utilizar el paradigma de componentes a sistemas empresariales de gran porte. Para ello consideramos arquitecturas distribudas, en mltiples capas, que incorporan fuentes de datos heterogneas, 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 lgica de UI Dilogos del Usuario Manejo de la lgica de casos de uso Control de la sesin de usuario Servicios del Sistema Servicios bsicos del sistema Usualmente corriendo en el marco de una transaccin Servicios del Negocio Tipos estables del negocio Manejo de la informacin del sistema Usualmente asociados a fuentes de datos
Figura 1 - Arquitectura

Aplicacin

El enfoque metodolgico 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 definicin de la arquitectura de componentes cubre aspectos nicamente lgicos y es totalmente independiente de la tecnologa con la cual se implementarn los componentes y sobre la cual se har el deploy del sistema. Esta vista lgica nos permite medir el nivel de acoplamiento del sistema y razonar sobre los efectos de modificar o reemplazar un componente. La independencia de la tecnologa nos permite abstraernos de los tecnicismos de stas as como elegir la ms apta dependiendo del sistema que se est desarrollando.

Sistema

3.2. Rational Unified Process

RUP es un producto de Rational Software que presenta un modelo de proceso de ingeniera de software completo. Provee un enfoque basado en disciplinas para la asignacin de tareas y responsabilidades. Permite un vocabulario comn entre equipos de desarrollo, hacer el proceso repetible, y realizar mediciones (estimacin de costos y tiempo, nivel de avance, entre otros). Aquellos equipos que adoptan RUP no estn 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 ingeniera 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 aplicacin que involucran importantes decisiones de diseo, exhibir una arquitectura inicial y estimar potenciales riesgos. La segunda fase, Elaboration, busca asegurar la arquitectura del sistema resolviendo los principales riesgos; produce adems un prototipo evolutivo del sistema. Finalmente, Construction tiene como objetivo completar el anlisis, diseo e implementacin 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 produccin del producto en las instalaciones del cliente. El avance en el tiempo del proyecto esta dado por el avance en las fases. La divisin del mismo en disciplinas brinda una organizacin 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 especfica dentro del proyecto.

3.3. Metodologa
La metodologa 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 tecnologa por lo cual no son consideradas las disciplinas de implementacin, testeo y deployment y tampoco la fase Transition. Asimismo, este enfoque refiere a actividades exclusivamente de desarrollo de software y no a actividades de gestin 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 metodologa. 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 bibliografa para hallar una descripcin detallada de las mismas.

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 crticos 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 bibliografa. Dos de las actividades, distinguidas en el diagrama, son aquellas que fueron incorporadas dentro de esta metodologa; estn fuertemente basadas en la propuesta de Cheesman y Daniels [CD].

Figura 4 - Workflow de la fase Elaboration

El workflow para la fase Construction es anlogo al de la fase Elaboration. Adems, dado que en la fase Construction la arquitectura esta lo suficientemente estable, una nueva actividad debe llevarse adelante. La misma lleva el nombre de Especificacin de Componentes. La siguiente seccin presentar en ms detalle cada una de las actividades particulares al enfoque aqu presentado, a saber Identificacin de Componentes, Interaccin de Componentes y Especificacin de Componentes.

4. Actividades Particulares al Enfoque

4.1. Identificacin 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. Interaccin de Componentes

En esta etapa se decide cmo trabajarn 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 polticas de manejo de integridad referencial. Las tareas a realizarse en esta actividad se presentan en la siguiente figura.

Figura 6 - Tareas que componen la actividad Interaccin de Componentes

4.3. Especificacin de Componentes

Como se mencion antes, esta actividad es realizada una vez que la arquitectura e interfaces de los componentes estn estables. La especificacin 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 informacin de cada interfaz; este modelo representa una vista abstracta de la informacin manejada por el componente. Especificar formalmente las operaciones de las interfaces; esta especificacin 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 Especificacin de Componentes

5. Caso de Estudio
El caso de estudio abordado representa un sistema de informacin de porte empresarial en el dominio Hotelera, y concierne principalmente a la gestin de una cadena hotelera. Este sistema, llamado Sistema de Gestin Hotelera, esta conformado por varios subsistemas; entre ellos se encuentra el Subsistema de Reservas, objeto de estudio de esta seccin. Este caso de estudio fue atacado originalmente en [CD01], con la metodologa 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 seccin 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 aplicacin de la metodologa.

5.1. Fase Inception

5.1.1. Descripcin del Negocio Una cadena hotelera desea automatizar los servicios brindados por sus hoteles. Cada hotel posee un sistema de informacin que satisface parcialmente los requerimientos informticos reales de la empresa. Muchas actividades son registradas en formularios de papel y la obtencin de datos estadsticos 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 poltica de la empresa no se realiza overbooking, por lo que se quiere que dicha poltica sea ejecutada en todos los hoteles de la cadena. Se desea adems poder sugerir a los clientes otros hoteles de la cadena cuando un hotel no tiene disponibilidad de la habitacin 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 operarn 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 adems 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, adems, reutilizar un sistema de facturacin 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 regin. La gerencia general necesita informacin estadstica. sta es utilizada para la apertura o clausura de hoteles en regiones donde la empresa est instalada. La informacin se recoge peridicamente y es analizada por economistas expertos de la empresa. Por ltimo, los servicios adicionales que brinda la empresa a los clientes varan segn el hotel. Los mismos cubren una amplia gama de servicios como servicios a la habitacin, paquetes tursticos, afiliacin a sistemas de millas, etc. Estos servicios se irn incorporando y removiendo del sistema, incluso una vez que ste este en produccin. El sistema debe ser capaz de incorporar nuevos mdulos (subsistemas) que den soporte a nuevos servicios. Los servicios extras que se brinda a los clientes son dinmicos. 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 surgirn, incluso una vez puesto el sistema en produccin, 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 podran ser vendidos y quitados del sistema. En cambio, no es comn el realizar reformas edilicias, por lo que los detalles de cada hotel son considerados estticos.

5.1.2. Identificar Procesos de Negocio El caso de estudio se centra en el Subsistema de Reservas del Sistema de Gestin 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 incorporacin de nuevos hoteles al sistema, as como la eliminacin de los mismos. Se encarga adems de la administracin del personal de la cadena de hoteles. Reserva de Habitacin (P2) Este proceso administra todas las actividades de reserva por parte de los clientes. Involucra modificaciones y cancelaciones de reservas, as como la deteccin 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 Facturacin (P3) Este proceso cubre el check-out de los huspedes, as como la facturacin de los servicios contratados por ellos. La contratacin de servicios por parte de los huspedes no forma parte de este proceso. Consultas Estadsticas (P4) Este proceso ocurre cuando la gerencia general realiza un estudio de la situacin de la cadena hotelera. Mediante este proceso se extraer la informacin del sistema til para crear un datawarehouse 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 realizacin de una reserva debe ser menor a 3 minutos cuando el cliente la realiza en la recepcin del hotel o telefnicamente. Para ello, es necesario mantener toda la informacin posible de visitas anteriores de los clientes. La informacin que acumula el sistema por medio de estos procesos da soporte a (P4). (P1) es importante debido a la gestin de empleados. Las altas y bajas de hoteles y sus descripciones son casos de uso que potencialmente estarn incluidos en (P2) y (P3). Por ende, puede postergarse la realizacin de (P1). (P4) tiene fines estadsticos y de marketing. La empresa no tiene inters en mantener todo el histrico de reservas y hospedajes por tiempo indeterminado, sino que mantendr resmenes de dicha informacin. Estos resmenes sern obtenidos por medio de (P4). De postergar (P4) se corre el riesgo de no haber recabado toda la informacin necesaria en (P2) y (P3). Esto debe considerarse al momento de desarrollar los mismos. La tabla de clasificacin y ranqueo es la siguiente: Ranqueo 1 Proceso (P2) Justificacin Las restricciones de performance implican un factor de riesgo para el proyecto. Ayuda a la comprensin de los pormenores del dominio de aplicacin del sistema de informacin a desarrollar. Abarca un conjunto considerable de conceptos del dominio de aplicacin. Presenta tambin restricciones de performance. Cubre los aspectos faltantes de los pormenores del dominio. Es posterior a (P2) dado que la informacin obtenida del mismo es la base para este proceso. Cubre los casos de uso de gerenciamiento de informacin, incluyendo la administracin del personal. Se realizar previo a (P4) dado que con (P1), (P2) y (P3) se cubre una parte fundamental del sistema. Se realizar en ltima instancia debido a que es un requerimiento secundario, ya que no representa una funcionalidad fundamental del sistema. Factores tecnolgicos 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

(P3)

(P1)

(P4)

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 metodologa 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 habitacin 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 telfono a travs de una central de reservas, por telfono directamente al hotel, o va Internet. El servicio brindado va Internet ser por medio de pginas Web accedidas directamente por los clientes, o a travs de Web Services utilizando documentos XML especficos. Esto permitir que los sistemas de las agencias de viajes realicen reservas automticamente. 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 recepcin 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 va Internet es de 5 segundos. El tiempo necesario para realizar una reserva por telfono o en persona es de 3 minutos. Para acelerar el proceso se almacenarn los detalles de los clientes que hayan interactuado con el hotel anteriormente. Descripcin del proceso. Primeramente se confirma la disponibilidad de la habitacin requerida en el hotel. En el caso de que no haya disponibilidad, se sugiere habitaciones similares que estn 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 confirmacin 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 modificacin 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 facturacin y finaliza el proceso. Por ltimo, puede ocurrir que el husped no haya concurrido al hotel dejando as una reserva vencida (cuyo husped no se present). En estos casos, peridicamente se revisa que reservas no fueron tomadas por los clientes respectivos. Para aquellas reservas vencidas se notifica al sistema de facturacin y finaliza el proceso.
Tomar reserva

llega cliente/

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

modificar/ [else] Modificar reserva

cliente NSP/

Procesar NSP

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 confirmacin por e-mail de las reservas a los clientes, y que notifique al sistema de facturacin. 10

El proceso de aquellas reservas en las que el cliente asociado no se haya presentado no ser realizado en forma automtica por el sistema, sino que se realizar a solicitud del actor involucrado en dicha actividad. El sistema, adems, 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
<no receive action> solicitud/

llega cliente/

Cancelar reserva cancelar/ [habitacion disp]

Ver disponibilidad

Hacer reserva

modificar/ [else] Modificar reserva

cliente NSP/

Procesar NSP

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 Husped y el RealizadorDeReserva. Puede abstraerse los roles que sern jugados por los actores al momento de interactuar con el sistema. De esta forma podemos considerar los siguientes actores: Huesped CreadorDeReserva AdministradorDeReserva SistemaDeFacturacin Puede asociarse conceptos del dominio de la aplicacin a los actores aqu definidos. El mapeo primario es: Husped Huesped Cliente Husped, CreadorDeReserva Recepcionista CreadorDeReserva Gerente CreadorDeReserva, AdministradorDeReservas El actor SistemaDeFacturacin representa al sistema de facturacin existente en la empresa. La elaboracin y construccin 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 deteccin 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 automticamente por el sistema. Si existe el requerimiento de que el sistema realice en forma automtica 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 (CU2.1) HacerReserva Actividades abarcadas VerDisponibilidad SugerirAlternativas HacerReserva ConfirmarReserva 11 Actores involucrados CreadorDeReserva

(CU2.2) CancelarReserva (CU2.3) ModificarReserva (CU2.4) TomarReserva (CU2.5) ProcesarNSP

CancelarReserva ModificarReserva ConfirmarReserva TomarReserva NotificarFacturacion ProcesarNSP NotificarFacturacion

CreadorDeReserva CreadorDeReserva Huesped SistemaDeFacturacion AdministradorDeReservas SistemaDeFacturacion

5.2.2. Realizar el Modelo Conceptual del Negocio

CadenaHoteles 1 hotelContactado Hotel * 1 * Cliente 1 1 0..1 direccionContacto * 1 * * ubicacion Reserva * 0..1 * Habitacion 1..* 1 1..* 1 1..* Recepcionista

Direccion 0..1 1 Cuenta 0..1 Pago 1 1 TipoHabitacion

Figura 10 - Modelo Conceltual del Negocio

5.2.3. Refinar Casos de Uso Nombre Actores Sinopsis (CU2.1) HacerReserva CreadorDeReserva Este caso de uso comienza cuando el CreadorDeReserva chequea la disponibilidad de una habitacin en un hotel dado. Si no hay disponible una habitacin 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. (CU2.2) CancelarReserva CreadorDeReserva Este caso de uso comienza cuando el CreadorDeReserva solicita la cancelacin de una reserva. El sistema procede a cancelarla. (CU2.3) ModificarReserva CreadorDeReserva Este caso de uso comienza cuando el CreadorDeReserva solicita modificar la reserva. Se procede a modificar la misma. (CU2.4) TomarReserva Huesped, SistemaDeFacturacin Este caso de uso comienza cuando el husped llega al hotel. Indica la reserva que est a su nombre. El sistema le asigna una habitacin al husped, y notifica a SistemaDeFacturacin que debe abrirse una cuenta para el cliente. (CU2.5) ProcesarNSP AdministradorDeReservas, SistemaDeFacturacion 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

Nombre Actores Sinopsis

Nombre Actores Sinopsis

Nombre Actores Sinopsis

Nombre Actores Sinopsis

vencida el sistema notifica a SistemaDeFacturacion que se cargue a la cuenta del cliente. Nombre Actores Sinopsis Nombre Actores Sinopsis Nombre Actores Sinopsis (CU2.6) ABMHotel AdministradorHotel Este caso de uso permite administrar la informacin de un hotel. (CU2.7) ABMHabitacion AdministradorHotel Este caso de uso permite administrar la informacin de las habitaciones de un hotel. (CU2.8) ABMTipoDeHabitacion AdministradorHotel Este caso de uso permite administrar la informacin de los tipos de habitaciones de un hotel. (CU2.9) ABMRecepcionista AdministradorHotel Este caso de uso permite administrar la informacin de los recepcionistas que trabajan en un hotel. (CU2.10) ModificarCliente AdministradorDeReservas Este caso de uso permite modificar la informacin de un cliente. (CU2.11) RemoverClientesInactivos AdministradorDeReservas Este caso de uso permite remover la informacin de los clientes que no hayan realizado reservas durante el ltimo ao. (CU2.12) RemoverReservasCaducas AdministradorDeReservas Este caso de uso permite eliminar aquellas reservas que ya hayan cumplido un plazo mayor a un ao en el sistema.

Nombre Actores Sinopsis

Nombre Actores Sinopsis Nombre Actores Sinopsis

Nombre Actores Sinopsis

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

Los casos de uso (CU2.1) y (CU2.3) involucran la actividad de confirmacin por e-mail al cliente. Se factoriza entonces como un nuevo caso de uso (CU2.14) ConfirmarReserva. Nombre Actores Sinopsis (CU2.14) ConfirmarReserva Solamente para inclusin 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 include ConfirmarReserva

ModificarReserva CreadorDeReserva include CancelarReserva include include TomarReserva

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 1 Caso de Uso CU2.4 TomarReserva Justificacin Este caso de uso requiere de interaccin con el sistema de facturacin existente. Se atacar en primera instancia por el riesgo que implica la interoperabilidad con el mismo. Adems, este proceso involucra la actividad de check-in, la cual tiene una restriccin importante de tiempo de respuesta. Si el husped ya tiene su reserva realizada, el check-in no puede demorar ms de 5 segundos. Tiene gran impacto en la arquitectura ya que involucra casi todos los conceptos del dominio del problema. Presenta interaccin con el sistema de facturacin existente, lo cual generar nuevos requerimientos sobre este. Representa un caso de uso importante para el proceso de negocio en cuestin. Representa un caso de uso importante para el proceso de negocio en cuestin.

2 3 4 5

CU2.1 HacerReserva CU2.5 ProcesarNSP CU2.3 ModificarReserva CU2.2 CancelarReserva

Los casos de uso CU2.6, CU2.7, CU2.8, CU2.9 y CU2.10 involucran actividades de gerenciamiento de informacin, y pueden ser postergados hasta la fase de construccin.

14

Los casos de uso CU2.11 y CU2.12 son de inters para el proceso de negocio. En cambio son requerimientos secundarios, por lo que pueden ser postergados hasta la fase de construccin. En la fase de elaboracin 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 sern atacados posteriormente. 5.2.5. Refinar Caso de Uso Crtico En el caso de estudio nos concentraremos en CU2.4 ya que se posicion primero en el ranqueo. Nombre Actores Sinopsis (CU2.4) TomarReserva Huesped, SistemaDeFacturacion Este caso de uso comienza cuando el husped llega al hotel. Indica la reserva que est a su nombre. El sistema le asigna una habitacin al husped, y notifica a SistemaDeFacturacion que debe abrirse una cuenta para el cliente. Curso Tpico 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 duracin de su estada y del tipo de habitacin deseado. 4. El Sistema le asigna una habitacin. 5. El Sistema notifica a SistemaDeFacturacion que una estada 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 estada.

Dado que CU2.4 incluye al CU2.13, tambin se refina este ltimo. Nombre (CU2.13) IdentificarReserva Actores Solamente para inclusin Sinopsis Identifica una reserva existente. Curso Tpico 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 informacin. 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 Actores Sinopsis

(CU2.13) IdentificarReserva Solamente para inclusin Identifica una reserva existente.

Curso Tpico 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 cdigo postal. b. El Sistema muestra las reservas activas para el cliente con dicha informacin. c. El Actor elige la reserva correspondiente.

derived

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.

interface type IIdentificarReserva getReserva()

becomes

IdentificarReserva

instance

include instance dialog type DlgTomarReserva

TomarReserva

becomes

Nombre Actores Sinopsis

(CU2.4) TomarReserva Huesped, SistemaDeFacturacin Este caso de uso comienza cuando el husped llega al hotel. Indica la reserva que est a su nombre. El sistema le asigna una habitacin al husped, y notifica a SistemaDeFacturacin que debe abrirse una cuenta para el cliente.

derived

Curso Tpico de Eventos 1. 2. 3. 4. 5. Extensiones 3. La reserva no fue identificada a. Fallo Cursos alternativos En 4 el Huesped puede solicitar cambiar los detalles de la estada. El Huesped llega al hotel e indica que tiene una reserva. Incluir CU2.13 (IdentificarReserva). El Huesped confirma los detalles de la duracin de su estada y del tipo de habitacin deseado. El Sistema le asigna una habitacin. El Sistema notifica a SistemaDeFacturacion que una estada ha dado comienzo.

interface type ITomarReserva comenzarEstadia()

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 operacin getReserva() es utilizada para dicho fin. Los detalles de la reserva son confirmados por el Huesped. Para comenzar la estada, el sistema asigna una habitacin y notifica al Sistema de Facturacin que la estada ha dado comienzo. Estas actividades son realizadas por la operacin 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 asociacin Hotel-Cliente fue eliminada ya que no ser mantenida por el Sistema. Las cuentas y los pagos sern responsabilidad del Sistema de Facturacin, por lo que tambin es eliminado. El concepto Recepcionista no esta ligado a las funcionalidades del caso de uso en consideracin, por lo que tambin 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 adems 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 habitacin 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 ms reservas para un tipo de habitacin en una fecha que habitaciones de ese tipo (no hay overbooking). 16

Reglas de precios: (R3) El precio de un tipo de habitacin para una estada es la suma de los precios para cada da de la estada. 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.
core Hotel nombre : String 1 type TipoHabitacion nombre : String precio(in f : Fecha) : Importe precioEstadia(in rf : RangoFechas) : Importe disponible(in rf : RangoFechas) : Boolean 1 * core Cliente nombre : String direccion : Direccion email : String type Reserva rid : String fechas : RangoFechas * * 1

1 1

1..*

* ubicacion * 0..1 type Habitacion numero : String

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

Restricciones:
context Hotel inv: self.habitacion.tipoHabitacionasSet() = self.tipoHabitacion context Reserva inv: self.habitacionnotEmpty() 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.habitacionsize() let cantResFecha(f : Fecha) : Integer = self.reservaselect(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.reservacollect(fechas.asSet())asSet() let cantHab : Integer = self.habitacionsize() let cantResFecha(f : Fecha) : Integer = self.reservaselect(r | r.fechas.includes(f))size() in self.fechasConReservaforall(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 Boolean

datatype String

datatype Fecha

datatype Importe

datatype RangoFechas inicio : Fecha fin : Fecha asSet() : Set(Fecha) includes(in : Fecha) : Boolean

datatype Direccion Calle : String CodigoPostal : String Estado : String 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 informacin 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 manejarn un conjunto de instancias del core type. Las interfaces de negocio sern 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 representarn 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 ms informacin de ste que del Cliente. Se resumen las actividades realizadas en el siguiente diagrama de responsabilidades de interfaces de negocio.
interface type IHotelMgt 1 * core Hotel nombre : String 1 type TipoHabitacion nombre : String precio(in f : Fecha) : Importe precioEstadia(in rf : RangoFechas) : Importe disponible(in rf : RangoFechas) : Boolean 1 * core Cliente nombre : String direccion : Direccion email : String * 1 interface type IClienteMgt type Reserva rid : String fechas : RangoFechas * * * ubicacion * 0..1 type Habitacion numero : String 1

1 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 Facturacin, 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 sern detectadas en prximas etapas. Ser necesario que el componente que realice esta interfaz cumpla la funcin de adaptador (Adapter Design Pattern), adaptando los parmetros y tipos de retorno y el mecanismo de invocacin al sistema real. Posiblemente este componente deba hacer persistente cierta informacin que lo asista en el mapeo de la informacin manejada en este sistema y la manejada en el sistema real. Crear Especificacin y Arquitectura Inicial Una arquitectura de componentes se define como un conjunto de componentes de software a nivel de aplicacin, sus relaciones estructurales y sus dependencias de comportamiento. Esta es una definicin lgica e independiente de la tecnologa. 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 razn se crea una especificacin 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 iteracin, a saber, ITomarReserva e IIdentificarReserva. Se tendr adems una especificacin 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 especificacin 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 prcticamente desconexa.
ITomarReserva ISistemaDeFacturacion IIdentificarReserva comp spec SistemaDeReservas

comp spec SistemaDeFacturacion

comp spec HotelMgr

IHotelMgt

comp spec ClienteMgr

IClienteMgt

Figura 17 - Arquitectura Inicial para el proceso P2

5.2.7. Interaccin de Componentes Refinar Interfaces y Operaciones de Sistema

getReserva()

Se sabe del caso de uso CU2.13 que la operacin 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 informacin de una reserva. Generalizaremos esta operacin devolviendo adems los detalles del cliente que realiz la reserva.
IIdentificarReserva::getReserva( in rid : String, out dr : DetallesReserva, out dc : DetallesCliente) signals ReservaInexistente

El parmetro 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 tpico de eventos. Que la reserva corresponda a otro hotel no ser corroborado por esta operacin, por lo que deber ser corroborado por algn componente en una capa superior. Se necesita, en cambio, una operacin que permita detectar todas las reservas activas que corresponden a un cliente determinado. Se agrega entonces la operacin getReservasCliente(). Esta operacin recibe el identificador de un Cliente y devuelve las reservas activas del mismo. La lgica del caso de uso, manejada en el dilogo de usuario, al no encontrar la reserva deseada debe buscar un cliente segn los criterios de bsqueda del cliente. Una vez elegido el mismo, debe buscar las reservas de un cliente dado, segn su identificador.
IIdentificarReserva::getReservasCliente( in cid : ClienteId) : Set(DetallesReserva)

19

El parmetro cid es el identificador del cliente. La operacin 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 estada dar comienzo mediante esta operacin. Segn el caso de uso CU2.4 el Sistema debe asignar una habitacin a la reserva e indicar al usuario la habitacin en la que se hospedar. Se notifica adems al Sistema de Facturacin que debe abrir una cuenta para un nuevo cliente. Se cobrar por la estada al momento del check-out (proceso de negocio P3). En ese momento se conoce exactamente la cantidad de das que se ha hospedado el Huesped.
ITomarReserva::comenzarEstadia( in rid : String, out n : String)

El parmetro rid es el identificado de la reserva y n representa el nmero de habitacin que el Sistema asoci a la reserva. Descubrir Operaciones de Interfaces de Negocio Se presenta a continuacin los diagramas de colaboracin para las operaciones refinadas en la actividad anterior.
etalles 1: getD Reserv a(rid, dr)

/ IHotelMgt

getReserva(rid, dr, dc) / IIdentificarReserva : SistemaDeReservas

2: d c :=

g et

D et

alle

sCli e

n te

( dr . clie

n te

/ IClienteMgt

Figura 18 - Operacin SistemaDeReservas::getReserva()

drs := getReservasCliente(cid) / IIdentificarReserva : SistemaDeReservas

1: drs := getReservasCliente(cid)

/ IHotelMgt

Figura 19 - Operacin SistemaDeReservas::getReservasCliente()

, dr) a(rid ) ,n eserv llesR tadia(rid tDeta rEs 1: ge omenza 2: c

/ IHotelMgt

comenzarEstadia(rid, n) / ITomarReserva : SistemaDeReservas

3: dc := getDetallesCliente(dr.cliente)

/ IClienteMgt
4: a brirC uen

ta(d

r, dc

/ ISistemaDeFacturacion

Figura 20 - Operacin 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 DetallesReserva hotel : HotelId fechas : RangoFechas tipoHabitacion : String cliente : ClienteId datatype DetallesCliente id : ClienteId nombre : String direccion : Direccion email : String

datatype HotelId

datatype ClienteId

Figura 22 - Nuevos Tipos de Datos

Definir Polticas 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 continuacin la arquitectura a nivel de instancia de componente (Component Object Architecture) del Sistema de Reservas, la cual define en parte las polticas de manejo de integridad referencial.
interface type IHotelMgt {frozen} 1

comp spec SistemaDeReservas {frozen} 1

interface type IClienteMgt

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 asociacin 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 vlidas; 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 cules componentes tienen referencias a l y notificarlos segn corresponda La responsabilidad se le asigna a un tercer Component Object, generalmente ms arriba en la cadena de llamadas Permitir y tolerar referencias invlidas Deshabilitar la baja de informacin

Considerando las tres primeras opciones, se presenta a continuacin cual sera la decisin 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. Ningn otro Component Object podr acceder a ClienteMgr. ClienteMgr notifica a HotelMgr sobre la eliminacin de un Cliente (aplicacin 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 DlgTomarReserva IDlgTomarReserva

IIdentificarReserva ISistemaDeFacturacion ITomarReserva comp spec SistemaDeReservas comp spec SistemaDeFacturacion

IHotelMgt

IClienteMgt

comp spec HotelMgr

comp spec ClienteMgr

Figura 25 - Arquitectura Refinada para P2

22

5.3. Fase Construction

5.3.1. Definir Modelos de Informacin para Interfaces

Figura 26 - Modelo de Informacin para IClienteMgt

Figura 27 - Modelo de Informacin para IHotelMgt

Las restricciones en el modelo de informacin de IHotelMgt son las siguientes:

context r : Reserva inv: -- Una reserva fue tomada cuando tiene una habitacin asignada r.tomada = r.ubicacion->notEmpty() context TipoHabitacion inv: -- No hay overbooking let fechasConReserva : Set(Fecha) = self.reservacollect(fechasasSet())asSet() let cantHab : Integer = self.habitacionsize() let cantResFecha(f : Fecha) : Integer = self.reservaselect(r | r.fechasincludes(f))size() in self.fechasConReservaforall(f | self.cantResFecha(f) <= self.cantHab)

23

Figura 28 - Modelo de Informacin para IIdentificarReserva

Figura 29 - Modelo de Informacin 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 continuacin las pre- y poscondiciones para la operacin 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 adems las pre- y poscondiciones para la operacin comenzarEstadia() de la interfaz IHotelMgt.
context IHotelMgt::comenzarEstadia(in rid:String, out n:String) pre: -- debe haber una habitacin disponible del tipo de habitacin -- 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 informacin 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 tecnologas, etc. Procesos de ingeniera 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 tecnologas cambien. La utilizacin de un enfoque basado en componentes independiente de la tecnologa, acompaado de una metodologa como la propuesta que presta particular atencin a la especificacin y a la arquitectura, puede posicionar de mejor manera a los desarrolladores para crear aplicaciones robustas, adaptables y bajo presupuestos factibles. La metodologa ha sido impartida en cursos de grado y de actualizacin 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 tecnologas especificas as como en el desarrollo completo de sistemas utilizando la misma.

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

[RUP] [Lar]

25