LEEC / LEIC Engenharia de Software Ano lectivo de 2003/2004, 1 Semestre

Anlise e Desenho Orientado por Objectos de um Sistema de Gesto da Relao com Clientes em Pequenos Hotis

1. Enunciado / Requisitos iniciais

Pretende-se desenvolver um sistema de software para apoiar a gesto da relao com clientes em pequenos negcios de hotelaria, denominado CRM4SH (Costumer Relationship Management for Small Hotels), tirando partido das tecnologias da Internet. Este sistema dirigido a pequenos negcios de hotelaria (hotis, penses, residenciais, casas que oferecem turismo de habitao e turismo rural, etc.) que fornecem servios de alojamento e, possivelmente, alimentao (pequeno almoo, etc.). Pretende-se que o sistema possa ser fornecido como um package de fcil instalao e administrao pelas empresas de hotelaria que o adquiram. Para o funcionamento do sistema, ser necessrio dispor de um servidor Web com ligao Internet e um servidor de base de dados relacionais. Por razes de segurana, o sistema deve estar dividido fisicamente em dois sub-sistemas: sub-sistema para empregados (recepcionistas e gerente), acessvel apenas na rede interna (aplicao de gesto); sub-sistema para clientes efectivos e potenciais, acessvel pela Internet (site Web). Descrevem-se de seguida as funcionalidades destes sub-sistemas. 1. Aplicao de Gesto Do ponto de vista lgica, a aplicao de gesto pode considerar-se subdividida nos mdulos (grupos de funcionalidades) a seguir descritos. 1.1. Configurao A aplicao de gesto deve permitir ao gerente da empresa de hotelaria efectuar as seguintes operaes de configurao: Registar e actualizar as caractersticas gerais da empresa (nome, endereo, telefone, categoria e e-mail). Registar e actualizar os servios oferecidos (alojamento e pequeno almoo, s alojamento, etc.) e respectivo preo dirio em funo da poca do ano e do nmero de pessoas.

 Registar e actualizar os quartos existentes, com o nmero e capacidade de cada quarto. Registar os empregados com acesso ao sistema, com o nome, login, password e funo (recepcionista ou gerente). 1.2. Registo de clientes A aplicao de gesto deve permitir a qualquer recepcionista da empresa de hotelaria efectuar as seguintes transaces: Registar um novo cliente. O utilizador (recepcionista) deve indicar o nome, nacionalidade, data de nascimento, morada, telefone, nmero e data de bilhete de identidade ou passaporte e e-mail. O sistema deve atribuir automaticamente um nmero de cliente sequencial. No caso de clientes com e-mail, o sistema deve gerar automaticamente uma password que enviada por correio electrnico para o cliente. Alterar os dados de um cliente (nomeadamente morada, telefone e e-mail). Nota: Considera-se que o gerente tem sempre acesso a todas as operaes a que o recepcionista tem acesso. 1.3. Reservas A aplicao de gesto deve permitir a qualquer recepcionista da empresa de hotelaria efectuar as seguintes transaces: Registar uma reserva de um cliente. O utilizador (recepcionista) deve indicar o nmero de pessoas, data de entrada e sada prevista, servio pretendido (alojamento e pequeno almoo, s alojamento, etc.) e dados do carto de crdito (a validar automaticamente junto do sistema informtico de uma entidade bancria). O sistema deve atribuir automaticamente um nmero de reserva. O sistema no deve aceitar reservas que no podem ser satisfeitas. Alterar ou anular uma reserva. 1.4. Estadias A aplicao de gesto deve permitir a qualquer recepcionista da empresa de hotelaria efectuar as seguintes transaces: Registar a entrada (check-in) de um cliente, com ou sem reserva prvia. O utilizador (recepcionista) deve indicar o nmero de pessoas, nmero(s) do(s) quarto(s) atribudo(s), data de sada prevista, servio fornecido (alojamento e pequeno almoo, s alojamento, etc.) e dados de carto de crdito (a validar automaticamente junto do sistema informtico de uma entidade bancria). O sistema deve atribui automaticamente um nmero de estadia. O sistema no deve permitir atribuir quartos que esto ocupados, ou que impossibilitem a satisfao de reservas j assumidas. Alterar a data de sada prevista (correspondente a uma estadia j iniciada). Efectuar mudanas de quarto (correspondentes a estadias j iniciadas). Registar a sada (check-out) de um cliente, sendo a factura emitida automaticamente pelo sistema. 1.5. Mensagens e contactos (mdulo opcional, pois pode-se usar uma aplicao externa) A aplicao de gesto deve permitir a qualquer recepcionista da empresa de hotelaria efectuar as seguintes transaces: Trocar (receber, enviar e responder) mensagens de correio electrnico com clientes, com a possibilidade de relacionar as mensagens com reservas, estadias ou mensagens anteriores. Registar outro contacto ocorrido com um cliente (para alm de mensagens de correio electrnico), com indicao do modo de contacto (pessoal, por carta, por telefone, por fax, etc.), iniciativa do contacto, descrio do contacto, possvel relacionamento com uma reserva ou estadia e possvel relacionamento com um contacto anterior.

1.6. Consulta de ocupao A aplicao de gesto deve permitir a qualquer recepcionista da empresa de hotelaria efectuar as seguintes consultas: Consultar o mapa de ocupao do hotel numa determinada data ou intervalo de datas (incluindo reservas pendentes), com possibilidade de aceder a detalhes de estadias, reservas e clientes. 1.7. Consulta de informao de clientes A aplicao de gesto deve permitir a qualquer recepcionista da empresa de hotelaria efectuar as seguintes consultas: Consultar a ficha e historial de um cliente (reservas, estadias, mensagens, outros contactos). Deve ser possvel ver toda a informao de historial agregada e ordenada cronologicamente. 1.8. Estatsticas Adicionalmente, o gerente deve poder obter as seguintes estatsticas : Taxa de ocupao ao longo de tempo, em nmero de quartos vendidos em relao ao nmero total de quartos e em nmero de pessoas alojadas em relao capacidade mxima. Evoluo da facturao ao longo do tempo. Distribuio das vendas por nacionalidade. Clientes com maior facturao. 2. Site Web Do ponto de vista lgico, o site Web, pode considerar-se subdividido nas duas reas a seguir descritas. 2.1. rea para clientes potenciais (pblico) Atravs do site Web, qualquer pessoa pode: Consultar as caractersticas gerais, servios oferecidos, preos e disponibilidades. Registar-se como cliente (com password gerada pelo sistema e enviada por correio electrnico para o cliente). 2.2. rea para clientes registados Uma vez identificados (atravs do nmero de cliente e password), os clientes registados devem ter acesso adicionalmente s seguintes operaes: Alterar dados pessoais. Efectuar uma reserva, com indicao de dados de carto de crdito (a validar automaticamente junto do sistema informtico de uma entidade bancria). Consultar as reservas pendentes. Alterar ou anular uma reserva. Trocar (receber, enviar e responder) mensagens de correio electrnico com a recepo do hotel (funcionalidade opcional). Consultar o historial de estadias, reservas e mensagens (estas ltimas, s se a funcionalidade anterior estiver disponvel).

A fazer
1. Anlise orientada por objectos

1.1. Construir um modelo de casos de utilizao (diagrama de casos de utilizao em UML e definies associadas) relativo ao prprio sistema de negcio (pequena empresa de hotelaria). 1.2. Descrever o "workflow" do processo de negcio "Alojamento" (reserva, "check-in", "checkout" e variantes) atravs de um diagrama de actividades em UML. Nota: em termos de documentao, este diagrama deve ficar inserido na seco que descreve o caso de utilizao. 1.3. Construir um modelo de casos de utilizao (diagramas de casos de utilizao em UML e definies associadas) relativo ao sistema de software. 1.4. Modelar a sequncia tpica de funcionamento do caso de utilizao "Registar entrada de cliente sem reserva prvia" atravs de um diagrama de sequncia em UML. Nota: em termos de documentao, este diagrama deve ficar inserido na seco que descreve o caso de utilizao. 1.5. Modelar o fluxo de funcionamento do caso de utilizao "Registar entrada de cliente sem reserva prvia" atravs de um diagrama de actividades em UML. Nota: em termos de documentao, este diagrama deve ficar inserido na seco que descreve o caso de utilizao. 1.6. Construir um modelo de objectos (diagrama de classes em UML e definies associadas) relativo aos conceitos deste domnio de aplicao, tambm denominado modelo de domnio. No indicar operaes. 1.7. Identificar e descrever tanto informalmente como formalmente (em OCL - Object Constraint Language) todas as restries associados ao modelo de objectos anterior. 1.8. Modelar os ciclos de vida de reservas e estadias atravs de diagramas de estados em UML. 2. Desenho orientado por objectos 2.1. Modelar a arquitectura do sistema (estrutura de alto nvel) atravs de diagramas de pacotes, componentes e distribuio em UML. 2.2. Construir um modelo de objectos (diagrama de classes em UML e definies associadas) relativo camada de base de dados do sistema de software, tendo em vista uma futura implementao numa base de dados relacional. No indicar operaes. Indicar restries, nomeadamente chaves primrias. Obter o esquema relacional correspondente em notao abreviada. 2.3. Construir um modelo de objectos (diagrama de classes em UML e definies associadas) relativo a parte da camada intermdia (lgica de negcio) do sistema de software, tendo em vista uma futura implementao numa linguagem orientada por objectos como Java ou C#. Considerar apenas o caso de utilizao "Registar reserva de cliente". fundamental indicar operaes. As classes desta camada normalmente no tm estado. Indicar dependncias em relao camada de base de dados. 2.4. Construir um modelo de objectos (diagrama de classes e definies associadas) relativo a parte da camada de interface com o utilizador do site Web, modelando tanto as pginas que so geradas dinamicamente (possivelmente em HTML + JavaScript) como as pginas JSP ou ASPX e cdigo associado que geram as primeiras. Indicar dependncias em relao camada de lgica de negcio. Considerar apenas o caso de utilizao "Registar reserva de cliente".

2 Anlise e Especificao de Requisitos

2.1 Modelo de Casos de Utilizao do Sistema de Negcio (Hotel)
O seguinte diagrama de casos de utilizao mostra, de forma muito sinttica, os servios

disponibilizados pelo hotel.

A fazer: descrever o "workflow" do processo de negcio "Alojamento" atravs de um diagrama de actividades. Ficheiro com diagramas UML em Microsoft Visio (CRM4SH.vsd)

2.2 Modelo de Casos de Utilizao do Sistema de Software (CRM4SH)

O seguinte diagrama de casos de utilizao apresenta uma viso geral do sistema de software, com dois pacotes de casos de utilizao correspondentes aos dois sub-sistemas indicados na definio de requisitos.

Os trs diagramas seguintes referem-se aplicao de gesto. Os 2 primeiros diagramas mostram casos de utilizao destinados ao recepcionista (tambm disponveis para o gerente) e o 3 diagrama mostra casos de utilizao especficos do gerente. Em cada diagrama, os casos de utilizao so agrupados em pacotes correspondentes aos mdulos referidos nos requisitos.

O diagrama seguinte mostra as funes disponveis pelo site Web.

As seces seguintes descrevem de forma mais detalhada alguns casos de utilizao identificados nas figuras anteriores.

2.2.1 Caso de utilizao "Registar entrada de cliente sem reserva"

A figura seguinte descreve a sequncia normal de funcionamento do caso de utilizao "Registar entrada de cliente sem reserva" atravs de um diagrama de sequncia.

A figura seguinte descreve as vrias sequncias possveis de funcionamento do caso de utilizao "Registar entrada de cliente sem reserva" atravs de um diagrama de actividades. Notar que, enquanto que, com diagramas de sequncia, seria necessrio (ou conveniente) desenhar um diagrama para cada sequncia possvel, basta um diagrama de actividades para mostrar todas as sequncias possveis de funcionamento.

2.2.2 Caso de utilizao "Registar entrada de cliente com reserva"

A fazer!

2.3 Modelo de Domnio

O modelo de domnio apresentado atravs de um diagrama de classes que mostra os conceitos e entidades mais importantes neste domnio de aplicao, um conjunto de restries adicionais e diagramas .de estados que mostram o ciclo de vida de algumas entidades importantes.

2.3.1 Diagrama de classes

2.3.2 Restries
Restries relacionadas com ciclos: R1) A reserva a que se refere uma estadia tem de ser do mesmo cliente que a estadia. R2) A estadia a que se refere uma factura tem de ser do mesmo cliente que a factura. R3) A reserva a que se refere um contacto tem de ser do mesmo cliente que o contacto. R4) A estadia a que se refere um contacto tem de ser do mesmo cliente que o contacto. R5) O contacto anterior a que se refere um contacto tem de ser do mesmo cliente que o contacto actual. Restries relacionadas com datas: R6) Numa reserva, a data de sada prevista tem de ser maior do que a data de entrada prevista. R7) Numa reserva, a data da entrada prevista tem de ser maior ou igual do que a data da reserva. R8) Numa estadia, a data de sada tem de ser maior do que a data de entrada. R9) Na relao entre contactos, a data-hora do contacto anterior tem de ser menor do que a datahora do contacto actual. R10) Em "Estadia Quarto", a data da sada tem de ser maior ou igual do que a data de entrada. R11) Em "Estadia Quarto", a data de entrada (sada) tem de ser maior ou igual (menor ou igual) do que a data de entrada (sada) da estadia correspondente. Chaves compostas (chaves simples j so indicadas no diagrama): R12) Em "Preo Servio", no podem existir duas ocorrncias para a mesma combinao de servio, poca do ano e nmero de pessoas. Restries relativas ocupao do hotel: R13) O mesmo quarto no pode estar atribudo duas vezes na mesma data. Mais precisamente, para quaisquer duas instncias diferentes x e y de "Estadia Quarto", x.quarto = y.quarto (x.data_de_entrada y.data_de_sada y.data_de_entrada x.data_de_sada). R14) O nmero de pessoas colocadas num quarto tem de estar compreendido entre 1 e a capacidade do quarto. Isto , para qualquer instncia x de "Estadia Quarto", 1 x.nmero_de_pessoas x.quarto.capacidade. R15) Para qualquer data e estadia, a soma dos nmeros de pessoas indicados em "Estadia Quarto" deve ser igual ao nmero de pessoas indicado em "Estadia". Mais precisamente,

R16) Em qualquer data, os quartos que no esto atribudos a estadias devem permitir satisfazer todas as reservas activas para essa data. Considera-se que, assim que uma reserva d origem a uma estadia, a reserva passa do estado "activa" para o estado "efectivada". Considera-se tambm que, assim que se ultrapassa a data de entrada prevista de uma reserva sem que o cliente comparea, a reserva passa do estado "activa" para o estado "cliente faltou". Assim, esta restrio s se aplica para datas actuais e futuras.

2.3.3 Ciclos de vida

A figura seguinte mostra o ciclo de vida de uma reserva (classe do modelo de domnio) atravs de um diagrama de estados. Os estados indicados no diagrama correspondem aos valores possveis do atributo "estado" na classe "Reserva". Os eventos correspondem execuo de casos de utilizao, excepo de um evento temporal (passagem da data de entrada prevista).

A fazer: ciclo de vida de uma estadia.

3 Desenho de alto nvel (desenho da arquitectura) do sistema

3.1 Arquitectura lgica
A figura seguinte prope uma decomposio "horizontal" do CRM4SH em camadas. Como habitual, prope-se uma arquitectura a 3 camadas: interface com o utilizador, lgica de negcio e base de dados, em que cada camada depende apenas da camada seguinte. Prope-se que o "back end" do sistema (camadas de lgica de negcio e base de dados) se considere integrado essencialmente na aplicao de gesto. O "Site Web" acrescentar essencialmente apenas um "front end" Web (camada de interface com o utilizador) para clientes e pblico, podendo ainda conter servios de lgica de negcio especficos. Trata-se para j de uma arquitectura meramente lgica, porque no se diz se as diferentes camadas so implementadas no mesmo componente de software ou se, sendo implementadas em diferentes componentes, so executadas no mesmo processo do

sistema operativo.

A figura seguinte prope uma decomposio "vertical" do CRM4SH em mdulos funcionais (representados por packages em UML) j referidos nos requisitos. So indicadas tambm presumveis dependncias entre packages.

Em termos de cruzamento da decomposio "horizontal" com a decomposio "vertical", cada package da aplicao de gesto ter elementos das 3 camadas referidas na primeira figura. Cada package do site Web ter elementos da camada de interface e, possivelmente, alguns elementos especficos da camada de lgica de negcio.

3.2 Arquitectura fsica

4 Desenho detalhado do sistema

4.1 Desenho da camada de base de dados
O modelo conceptual da base de dados (expresso por um diagrama de classes em UML) ser quase idntico ao modelo de domnio, com pequenas modificaes para facilitar o mapeamento para SQL, incluindo mudana para nomes vlidos em SQL e introduo de cdigos internos para formao de chaves. Relativamente a cdigos internos, sugere-se apenas a introduo de um atributo "cdigo

interno" nas classes "Contacto com Cliente" e "Servio". Depois, h que mapear o modelo conceptual para um esquema relacional, seguindo regras semelhantes s regras de mapeamento do modelo Entidade-Associao para o modelo relacional. Em geral, cada classe d origem a uma tabela. Esquema relacional: Hotel(nome, endereo, telefone, categoria, e-mail) Cliente(nmero de cliente, nome, nacionalidade, data de nascimento, morada, telefone, nmero do bilhete de identidade ou passaporte, data do bilhete de identidade ou passaporte, e-mail) Quarto(nmero, capacidade) Empregado(login, password, nome, funo) Servio(cdigo interno, nome) Preo_Servio(cdigo interno do servio [ Servio], data inicial, data final, nmero de pessoas, preo) Reserva(nmero da reserva, nmero do cliente [ Cliente], data da reserva, nmero de pessoas, data de entrada prevista, data de sada prevista, nmero do carto de crdito, titular do carto de crdito, data de expirao do carto de crdito, estado, nmero da estadia [ Estadia] ) Estadia(nmero da estadia, nmero do cliente [ Cliente], nmero de pessoas, data de entrada, data de sada, nmero do carto de crdito, titular do carto de crdito, data de expirao do carto de crdito) Estadia_Quarto(nmero da estadia [ Estadia], nmero do quarto [ Quarto], data de entrada, data de sada, nmero de pessoas) Factura(nmero, data, valor, nmero do cliente [ Cliente], nmero da estadia [ Estadia]) Contacto_com_Cliente(cdigo interno, data-hora, modo de contacto, iniciativa do contacto, descrio, nmero do cliente [ Cliente], login do empregado [ Empregado], cdigo do contacto anterior [ Contacto], nmero da reserva [ Reserva], nmero da estadia [ Estadia]) Notao: As chaves primrias so indicadas a sublinhado. As chaves estrangeiras (implementao de associaes) so indicadas com uma seta para a tabela referenciada. Atributos que admitem valor nulo so indicados em itlico. Notas: Para evitar referncias circulares, optou-se por referenciar as estadias a partir das reservas, e no referenciar as reservas a partir das estadias. Desta forma, podem-se eliminar as reservas j efectivadas (que tm menos interesse para histrico do que as estadias) sem quebrar a integridade referencial. Para evitar referncias circulares, optou-se por referenciar as estadias a partir das facturas, e no referenciar as facturas a partir das estadias. Apesar de redundante, optou-se por referenciar o cliente directamente a partir da factura. desnecessrio mapear a classe "Mensagem por e-mail" para uma tabela. As associaes para "Hotel" so redundantes, pelo que no so mapeadas.

4.2. Desenho da camada de lgica de negcio

4.2.1 Lgica de negcio para implementao do caso de utilizao "registar reserva de cliente"
Mostra-se apenas a parte desta camada necessria implementao do caso de utilizao "Registar reserva de cliente". A implementao dos restantes casos de utilizao levaria ao "engordamento" das classes apresentadas e adio de novas classes. Na figura seguinte, as classes do lado direito representam dados de entidades de negcio que so passados (como argumento ou retorno de mtodos de lgica de negcio) entre a camada de lgico de negcio e a camada de interface com o utilizador. Cada instncia de uma dessas classes representa uma entidade de negcio. Para simplificar, colocaram-se todos os atributos pblicos, dispensando-se assim construtores e selectores de atributos. As classes do lado esquerdo que contm os servios (mtodos) de lgica de negcio. Cada instncia de uma dessas classes representa um gestor de um tipo de entidade de negcio. Em cada sesso, s necessrio instanciar (no mximo) um gestor de cada uma dessas classes. Esta separao a que escala melhor para uma soluo distribuda (cliente-servidor), com as camadas de interface com o utilizador (cliente) e de lgica de negcio (servidor) a correr em processos separados. As classes com os servios de lgica de negcio estaro implementadas apenas no servidor (sendo os mtodos chamados remotamente a partir da camada de interface), enquanto que as classes com os dados das entidades de negcio estaro implementadas tanto no cliente como no servidor.

4.3. Desenho da interface grfica da aplicao de gesto

A fazer!

4.4. Desenho do site Web

A fazer! Joo Pascoal Faria (jpf@fe.up.pt), Joo Correia Lopes (jlopes@fe.up.pt) ltima modificao: 26-09-2004