Relatório de Análise

FACULDADE DE ENGENHARIA DA UNIVERSIUDADE DO PORTO
LICENCIATURA EM ENGENHARIA INFORMÁTICA E COMPUTAÇÃO
LABORATÓRIO DE SISTEMAS DE GESTÃO DE
BASES DE DADOS
Operador Turístico
Relatório de Análise
Luís Carlos Almeida
Ricardo Moreno
Outubro de 2001
[email protected]
[email protected]
1. Introdução
1.1. Objectivos do Sistema
Este projecto trata do desenvolvimento de um sistema de software para gestão de
reservas de um operador turístico. Os objectivos são a partir de um modelo de processo
de negócio automatizar tarefas relacionadas com a gestão de reservas de unidades
hoteleiras.
Considera-se que o negócio tem duas unidades organizacionais principais: uma
central e diversos balcões de atendimento. Na central são realizadas tarefas de gestão
global do negócio. Estas tarefas incluem a aquisição e desactivação de unidades
hoteleiras – apartamentos e hotéis – e redefinição dos preços dos factores influentes no
cálculo de preços das reservas. Os balcões de atendimento – que podem existir na
recepção de hotéis, aeroportos, áreas comerciais, etc. – dedicam-se a tarefas
relacionadas directamente com o cliente.
1.2. Objectivos comerciais
O destino comercial do sistema será o de organizações que tenham modelos de
processo semelhantes ao adoptado pelo sistema. O sistema será mais destinado, por
exemplo, a uma organização que possuí uma cadeia de hotéis e realize turismo rural do
que a uma que só possua a cadeia de hotéis.
1.3. Restrições ao projecto
Consideramos que uma forte restrição é a falta de cliente e de um estudo
aprofundado sobre esta área de negócio. Assim, o projecto nunca estará realmente apto
para os seus destinos comerciais. Isto passa-se de alguma forma devido a restrições
temporais porque, mesmo não havendo cliente – o que é suposto –, com uma margem
suficiente larga de tempo para a equipa de projecto visitar, acompanhar e verificar
actividades em diversas organizações deste sector, chegar-se-ia a um produto final mais
consistente.
1.4. Enquadramento do sistema a desenvolver no
negócio/organização
O enquadramento do sistema, seguindo a abordagem do ponto anterior, será
genérico. Pois estaria mais bem enquadrado se houvesse um estudo mais aprofundado
da estrutura organizacional deste tipo de negócio. De qualquer forma, pensamos que os
pontos essenciais estão definidos e que de alguma forma cumprem os objectivos deste
tipo de negócio. Ou seja, automatizar procedimentos para certo tipo de perguntas
frequentes na organização: “Quais os apartamentos T1 disponíveis na Serra da
2
Estrela?”, “Como redefinir a política de preços de forma a que esta se propague de uma
forma consistente?”.
1.5. Riscos
Os riscos decorrentes no sistema em desenvolvimento passam pelo esquecimento de
certos processos fundamentais para a organização. Quer na centralização nos processos
dedicados à gestão de reservas quer, como já foi dito, na falta de uma análise mais
profunda sobre este tipo de organização/negócio.
2. Descrição Funcional
2.1. Partição Funcional
2.1.1. Unidades orgânicas e sub-sistemas
Na abordagem realizada foram consideradas duas unidades orgânicas: a central e
o balcão. A central dedica-se à gestão global do sistema. O balcão à comunicação com o
cliente.
3
2.1.2. Principais funções do sistema
A figura abaixo ilustra o diagrama de processo do sistema:
4
2.2.3. Perfis de utilização
Na figura abaixo apresenta-se o diagrama de casos de uso do sistema de gestão
do operador turístico:
5
2.2. Narrativa do processo
2.2.1. Registar nova Unidade Hoteleira
Na aquisição de uma nova unidade hoteleira, cabe ao gestor o seu registo no
sistema. Se a unidade hoteleira for um apartamento é efectuado um registo dos atributos
de apartamento. Caso seja um hotel, além do seu registo como sendo uma unidade
hoteleira, será necessário proceder ao registo dos seus quartos.
2.2.2. Desactivar Unidade Hoteleira
Na desactivação de uma unidade hoteleira – devido a venda, por exemplo – cabe
ao gestor apagar o seu registo do sistema.
2.2.3. Redefinir preços
Na ocorrência de mudança de preços, cabe ao gestor alterar os preços associados
a certos factores – como por exemplo: tipo e capacidade do apartamento ou tipo e
regime de estadia do quarto.
2.2.4. Efectuar Reserva
No caso de um cliente querer efectuar uma reserva, interessará saber se é para
apartamento ou para hotel, no caso de indisponibilidades, o empregado de balcão deverá
fornecer um calendário de disponibilidades para apartamentos ou de hotéis com quartos
livres. No caso de disponibilidade, é verificada a existência do registo do cliente, sendo
criado um novo em caso negativo e finalmente efectuada a reserva.
2.2.5. Efectuar pagamento
No fim da reserva é calculado o preço final da reserva – podendo já ter sido
efectuado para conhecimento do cliente – e elaborada a conta a apresentar, ficando o
cliente com a responsabilidade de terminar o processo pelos meios habituais (em
numerário, cheque, cartão de crédito, etc.).
6
2.3. Diagrama de hierarquia de funções
A figura abaixo apresenta o diagrama de hierarquia de funções:
7
3. Descrição da Informação
3.1. Estrutura de Informação
A figura abaixo apresenta o diagrama entidade-associação do sistema:
É de referir que o atributo PRECO nas entidades APARTAMENTO, QUARTO e
é derivável, ou seja, calculado em função de outros atributos e mediante o
peso atribuído na definição de preços desses atributos pelo gestor. A definição dos
pesos dos atributos para cálculo de preços serão guardados como variáveis globais do
sistema.
RESERVA
8
3.2. Restrições de integridade
Funções de Negócio
Entidades
UNID_HOTELEIRA
QUARTO
EQUIPAMENTO
RESERVA
CLIENTE
Registar
Unid.
Hoteleira
Desactivar
Unid.
Hoteleira
Redefinir
preços
Efectuar
Reserva
C
C
CR
D
D
D
U
U
R
R
R
C
CRU
U
Efectuar
Pagamento
U
4. Esquema Relacional
4.1. Relações e Atributos
UNID_HOTELEIRAS
#ID
NUMBER
NOME
VARCHAR(50)
CATEGORIA
NUMBER
OBSERVACOES
VARCHAR(200)
REGIAO_TUR
VARCHAR(30)
#ID_TIPO
NUMBER
MORADA
VARCHAR(100)
LOCALIDADE
VARCHAR(30)
COD_POSTAL
VARCHAR(20)
TIPO
NUMBER
HOTEIS
#ID
NUMBER
APARTAMENTOS
#ID
NUMBER
TIPO
VARCHAR(10)
CAPACIDADE
NUMBER
PRECO
NUMBER
EQUIPAMENTOS
#ID
NUMBER
NOME
VARCHAR(50)
#ID_UNID_HOT
NUMBER
QUARTOS
#ID
NUMBER
NUMERO
NUMBER
TIPO
VARCHAR(20)
REGIME
VARCHAR(20)
CAPACIDADE
NUMBER
PRECO
NUMBER
#ID_HOTEL
NUMBER
RESERVAS
#ID
NUMBER
INICIO
DATE
FIM
DATE
PRECO
NUMBER
#CLIENTE
NUMBER
#ID_TIPO
NUMBER
TIPO
NUMBER
CLIENTES
#ID
NUMBER
NOME
VARCHAR(100)
MORADA
VARCHAR(100)
LOCALIDADE
VARCHAR(30)
COD_POSTAL
VARCHAR(20
9
4.2. Estudo do grau de normalização do esquema obtido
O modelo relacional obtido a partir do modelo entidade-associação parece-nos
suficiente. Os únicos pontos que nos parece ter em conta são a existência na tabela
UNID_HOTELEIRAS duma chave estrangeira #ID_TIPO correspondente tanto ao código
de identificação de um hotel como de um apartamento sendo pelo campo TIPO feita essa
distinção – atribuição de 0 para hotel e 1 para apartamento. O mesmo se verifica para a
tabela RESERVAS em que, como a reserva terá que ser ou de um quarto ou de um
apartamento, aparece igualmente uma chave estrangeira identificando o código do
quarto ou do apartamento e, um campo TIPO referindo qual dos casos se verifica – 0
para quarto e 1 para apartamento.
5. Conclusões
5.1. Avaliação da ferramenta usada
Na nossa opinião o Oracle Designer é útil e demonstra robustez na elaboração de
um projecto. Parece-nos no entanto, eventualmente por alguma falta de experiência, que
é um pouco difícil trabalhar com a ferramenta.
5.2. Avaliação do trabalho desenvolvido
Em nossa opinião o trabalho está um pouco atrasado. Achamos que o facto se deve,
de alguma forma, à dificuldade já apresentada de trabalhar com o Oracle Designer. No
entanto, pelo elaboração deste relatório, notamos que já temos esquemas bem definidos
o que facilitará e fará com que o nosso trabalho a curto prazo seja mais de
manuseamento com as ferramentas e menos a nível conceptual da aplicação.
6. Bibliografia
“Oracle Designer: First Class”, Oracle
10