Hotel Unioeste

8/4/2019 Hotel Unioeste

http://slidepdf.com/reader/full/hotel-unioeste 1/38



ADRIANO DOUGLAS GIRARDELLO

ANA PAULA FREDRICH

TIAGO ALEXANDRE SCHULZ SIPPERT

SISTEMA GERENCIADOR DE HOTEL

Processo de Engenharia de Requisitos,Empresa: Hotel Real, Curso: Processo deEngenharia de Software II (PES II), Série: 4ºano.

Professor : Victor Francisco Araya Santander.

CASCAVEL

2009



Sumário

Capítulo 1 – Introdução

Capítulo 2 – Metodologia de desenvolvimento

Capítulo 3 – Cronograma de atividadesCapítulo 4 – Modelagem organizacional e Modelagem de requisitos não-funcionais

4.1 – Modelo de dependências estratégicas (SD)

4.2 – Modelo de razões estratégicas (SR)

4.3 – NFR Framework

Capítulo 5 – Requisitos do Sistema

5.1 – Requisitos funcionais

5.2 – Requisitos não-funcionais

Capítulo 6 – Caso de uso do sistema

6.1 – Descrições textuais dos casos de uso do sistema

Capítulo 7 – Diagrama de Classe do Sistema

7.1 – Descrições textuais das classes do sistema

Capítulo 8 – Conclusão

Apêndice A – Sobre o Hotel Real

Apêndice B – Entrevista

Apêndice C – Deficiências dos livros de registros

Apêndice D – Glossário



Capítulo 1

IntroduçãoA empresa escolhida para desenvolver o projeto de engenharia de software foi o Hotel

Real. O hotel está localizado na Avenida Brasil número 4506, centro, CEP 85.812-000, na

cidade de Cascavel-PR. Atua com a razão social “Girardello Vacari & Cia Ltda.”. OApêndice A traz uma descrição mais detalhada sobre o Hotel Real, assim como, discute commais detalhes o dia-a-dia do mesmo.

O Hotel Real trabalha na área de hotelaria à mais de 30 anos. A empresa não possuinenhum sistema automatizado de informação implantado, todas as atividades de operaçãocomo cadastros de hóspedes e empresas, controle de diárias, entre outras, são realizadasmanualmente com o auxilio de livros de registros, como está detalhado no Apêndice C.Sendo assim, propõe-se a implantação de um sistema gerenciador hoteleiro que aperfeiçoetodas as operações que envolvam informações/dados do hotel.

O sistema proposto será implementado na plataforma Windows com as seguintescaracterísticas: os usuários farão uso de um computador localizado na recepção para cadastros

de hóspedes e empresas, verificação de disponibilidade de quartos, gerenciamento de diáriasentre outras ações. O sistema será utilizado por diferentes funcionários, desde recepcionistasaté a gerência, mas com níveis de privilégios diferenciados através de login e senha.

Neste documento será apresentado um estudo detalhado dos Requisitos Funcionais, Não-Funcionais e modelagem organizacional (i* e NFR) do Sistema Gerenciador Hoteleiro,além dos diagramas de Casos de Uso e de Classe usando o padrão UML, que facilitam avisualização no processo de Engenharia de Requisitos.

O processo de elicitação de requisitos sobre a empresa, em forma de entrevista, estádetalhado no Apêndice B.



Capítulo 2

Metodologia de Desenvolvimento

No processo de desenvolvimento de software é extremamente importante e necessárioque se faça uso de uma metodologia, tanto para a organização da produção quanto para a

melhora em produtividade e qualidade. Dentre as principais metodologias e processos estão osmodelos: Cascata, Iterativo e Incremental, Espiral, RAD, RUP, XP e Scrum.

A metodologia escolhida para o projeto foi o Modelo em Espiral, pois é a que mais seaproxima das características do projeto a ser desenvolvido. Dentre elas, a possibilidade de queem cada iteração sejam obtidas versões do sistema cada vez mais complexas, podendo assimserem modificados alguns requisitos se o protótipo não estiver de acordo com o que o clientedeseja. Além disso, a eliminação de erros e alternativas inadequadas, através da análise deriscos e da revisão das atividades em cada ciclo, torna-se possível com essa metodologia.

Outros modelos de desenvolvimento tem suas desvantagens, que foram consideradascomo critérios de eliminação na escolha do modelo em espiral. Algumas destas desvantagenssão:

− O modelo em cascata não permite que se volte atrás em uma etapa. Em nosso casoos requisitos do usuário podem mudar, fazendo-se assim necessário que parte deuma etapa anterior possa ser reavaliada;

− Métodos Ágeis necessitam da presença constante do cliente para validação dodesenvolvimento. Em nosso caso o cliente, ou seja, o gerente do hotel, não temtempo suficiente para que possa estar envolvido com o processo dedesenvolvimento.

− Métodos Formais implicam em muita documentação e muito tempo aplicado afase de requisitos e projeto, sendo melhor aplicados em sistemas críticos. O projetoem questão é relativamente simples e não é um sistema crítico, sendo que não há

necessidade de uso de métodos formais.O Modelo em Espiral consiste de basicamente quatro fases: Análise, Projeto,Implementação e Testes, que são repetidas até que se chegue a uma fase na qual o protótipodesenvolvido está suficientemente satisfatório do ponto de vista do cliente, para que sejaconsiderado como sistema final.



Capítulo 3

Cronograma de AtividadesPara uma melhor organização e controle das atividades foi criado um cronograma

especificando as atividades e o tempo que cada uma precisará para ser executada. O projeto

tem como recursos humanos os integrantes do grupo deste trabalho e como recursos físicos asmáquinas e laboratórios da Universidade em que o mesmo está sendo desenvolvido. A seguir são descritas as atividades a serem realizadas, sendo sua duração conforme a Figura (3.1).

[AT-01] Contato inicial da equipe de desenvolvimento com o cliente. Elicitação dosrequisitos para o desenvolvimento de software através de entrevistas com o cliente.

[AT-02] Debate para escolha de uma metodologia de desenvolvimento. Elaboraçãodos diagramas de modelagem organizacional i*, NFR Framework, Casos de Uso e de classes.

[AT-03] Elaboração do documento de Especificação de Requisitos e Análise

[AT-04] Escolha de uma linguagem de programação baseada nos requisitos elicitados.Análise de tecnologias e processos para utilização no projeto.

[AT-05] Estudo e capacitação da equipe na linguagem de programação e tecnologiasescolhidas para o desenvolvimento do sistema, incluindo banco de dados.

[AT-06] Implementação de um protótipo da interface do programa.

[AT-07] Visita, validação e entrega do protótipo ao cliente.

[AT-08] Implementação das classes que identificam os objetos principais do sistema,

incluindo gerenciamento dos mesmos (Hóspede, Quarto, Empresa, Recepcionista, Gerente,Administrador, Usuário).

[AT-09] Implementação das classes de gerenciamento do sistema (Reserva, Diária).

[AT-10] Implementação das funcionalidades de Relatórios e Login no sistema.

[AT-11] Testes das implementações.

[AT-12] Implementação das modificações geradas pelas visitas ao cliente.

[AT-13] Elaboração da documentação do sistema e trabalho final.

[AT-14] Entrega e implantação do sistema final



Figura 3.1: Cronograma das Atividades.





Figura 4.1: Modelo de Dependências Estratégicas.



4.2 Modelo de Razões Estratégicas (SR)

O modelo SR Figura (4.2) é um complemento do modelo SD, já que ele demonstra deforma mais detalhada as atividades que devem ser realizadas para que um objetivo sejaalcançado.

Com a expansão do ator Sistema de Gerenciamento de Hotéis, podemos observar queos gerenciamentos, tanto de quarto, usuários, empresas e hóspedes possuem subdivisões emcomum, como: incluir, desde que os dados sejam válidos; alterar, desde que os dados sejamválidos e a entidade esteja cadastrada; consultar os dados desde que a entidade estejacadastrada e haja um identificador da entidade; remover, desde que uma entidade estejacadastrada.

Da mesma forma que os outros gerenciamentos anteriormente explicados, asoperações de gerenciamento de diárias e reservas também possuem subdivisões em comum,como: consultar os dados desde que a entidade esteja cadastrada e haja um identificador daentidade; incluir, desde que haja um quarto disponível e o hóspede esteja devidamentecadastrado no sistema; cancelar e alterar, desde que a entidade esteja cadastrada. Ogerenciamento de diária ainda tem uma subdivisão finalizar, que requer que uma diária estejaativa e ocorre com o pagamento da mesma.

Além disso, podemos observar que para ocorrer o login no sistema, são necessáriosdois recursos: o usuário e a senha do mesmo.



Figura 4.2: Modelo de Razões Estratégicas



4.3 NFR Framework

O diagrama NFR Framework representado na Figura (4.3) nos permite ter uma visãomelhor dos requisitos não funcionais e suas decomposições, operacionalizações (detalhadasna seção 5.2) e interdependências. Além disso, nos mostrar como as operacionalizaçõesinterferem uma nas outras, tanto positivamente como negativamente.

Figura 4.3: Diagrama NFR Framework



Capítulo 5

Requisitos do Sistema

Para a classificação dos requisitos funcionais e não-funcionais quanto à sua prioridade,foi feita a divisão em três categorias: essenciais, importantes e desejáveis.

Essencial é o requisito sem o qual o sistema não entra em funcionamento.Requisitos essenciais são requisitos imprescindíveis, que têm que ser implementadosimpreterivelmente.

Importante é o requisito sem o qual o sistema entra em funcionamento, mas deforma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem,o sistema poderá ser implantado e usado mesmo assim.

Desejável é o requisito que não compromete as funcionalidades básicas dosistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveissão requisitos que podem ser deixados para versões posteriores do sistema, caso não hajatempo hábil para implementá-los na versão que está sendo especificada.

5.1 Requisitos Funcionais

Os requisitos funcionais de um sistema são as capacidades que ele irá fornecer aosusuários. A seguir são apresentados os requisitos funcionais do sistema, assim como uma

breve descrição dos mesmos.[RF-01] Incluir Hóspede.

Prioridade: EssencialSolicitante: RecepcionistaDescrição: O sistema deve permitir incluir um novo hóspede, a partir dos seguintes

dados: nome, nacionalidade, CPF, estado civil, sexo, profissão, data de nascimento, data do

cadastro, procedência, destino, número do RG, telefone, placa do carro e observações.[RF-02] Alterar HóspedePrioridade: ImportanteSolicitante: RecepcionistaDescrição: O sistema deve permitir alterar os dados cadastrais de um hóspede, através

de uma consulta por nome ou CPF.[RF-03] Consultar Hóspede

Prioridade: EssencialSolicitante: RecepcionistaDescrição: O sistema deve permitir fazer a consulta de um hóspede através do nome

ou CPF do mesmo. Sendo que o resultado da consulta será exibido em tela.

[RF-04] Excluir HóspedePrioridade: Importante



Solicitante: RecepcionistaDescrição: O sistema deve permitir excluir um hóspede a partir de uma consulta por

nome ou CPF.

[RF-05] Incluir EmpresaPrioridade: EssencialSolicitante: RecepcionistaDescrição: O sistema deve permitir incluir uma nova empresa, a partir dos seguintes

dados: nome/razão social, endereço, CNPJ, telefones, falar com (responsável), o cargo domesmo (responsável), inscrição estadual, e-mail, site, e observações.[RF-06] Alterar Empresa

Prioridade: ImportanteSolicitante: RecepcionistaDescrição: O sistema deve permitir alterar os dados cadastrais de uma empresa,

através de uma consulta por nome ou CNPJ.

[RF-07] Consultar EmpresaPrioridade: EssencialSolicitante: RecepcionistaDescrição: O sistema deve permitir fazer consulta de uma empresa através de nome ou

CNPJ. Sendo que o resultado da consulta será exibido em tela.[RF-08] Excluir Empresa

Prioridade: ImportanteSolicitante: RecepcionistaDescrição: O sistema deve permitir excluir uma empresa a partir de uma consulta por

nome ou CNPJ.[RF-09] Incluir Quarto

Prioridade: EssencialSolicitante: GerenteDescrição: O sistema deve permitir incluir um novo quarto, a partir dos seguintes

dados: número/identificador, tipo do quarto, número de camas e observações.[RF-10] Alterar Quarto

Prioridade: ImportanteSolicitante: GerenteDescrição: O sistema deve permitir alterar os dados cadastrais de um quarto, através

de uma consulta por número/identificador.[RF-11] Consultar Quarto

Prioridade: EssencialSolicitante: GerenteDescrição: O sistema deve permitir fazer consulta de um quarto através do

numero/identificador. Sendo que o resultado da consulta será exibido em tela.[RF-12] Excluir Quarto

Prioridade: ImportanteSolicitante: GerenteDescrição: O sistema deve permitir excluir um quarto a partir de uma consulta por

número/identificador.[RF-13] Incluir Reserva

Prioridade: Desejável

Solicitante: Recepcionista



Descrição: O sistema deve permitir incluir uma nova reserva, a partir dos seguintesdados: nome, empresa, data prevista para chegada, telefone, hora prevista para chegada,número de pessoas e observações.

[RF-14] Alterar ReservaPrioridade: DesejávelSolicitante: RecepcionistaDescrição: O sistema deve permitir alterar os dados de uma reserva, através de uma

consulta por nome ou data prevista para chegada.[RF-15] Consultar Reserva

Prioridade: DesejávelSolicitante: RecepcionistaDescrição: O sistema deve permitir fazer consulta de uma reserva através do nome ou

data prevista para chegada. Sendo que o resultado da consulta será exibido em tela.[RF-16] Cancelar Reserva

Prioridade: DesejávelSolicitante: RecepcionistaDescrição: O sistema deve permitir cancelar uma reserva a partir de uma consulta por

nome ou data prevista para chegada.[RF-17] Incluir Diária

Prioridade: EssencialSolicitante: RecepcionistaDescrição: O sistema deve permitir incluir uma nova diária a partir dos seguintes

dados: identificador de uma pessoa já cadastrada, data de entrada, data prevista de saída, valor da diária e observações.[RF-18] Alterar Diária

Prioridade: EssencialSolicitante: RecepcionistaDescrição: O sistema deve permitir alterar os dados de uma diária.

[RF-19] Consultar DiáriaPrioridade: EssencialSolicitante: RecepcionistaDescrição: O sistema deve permitir fazer consulta de uma diária através da data da

mesma. Sendo que o resultado da consulta será exibido em tela.[RF-20] Cancelar Diária

Prioridade: Essencial

Solicitante: RecepcionistaDescrição: O sistema deve permitir cancelar uma diária.[RF-21] Finalizar Diária

Prioridade: EssencialSolicitante: RecepcionistaDescrição: O sistema deve permitir a finalização de uma diária, sendo esta, total dos

gastos do hóspede, tanto a soma dos valores das diárias em que ele permaneceu no hotel,como os gastos extras na lanchonete.[RF-22] Incluir Usuário

Prioridade: EssencialSolicitante: Administrador

Descrição: O sistema deve permitir incluir um novo usuário, a partir dos seguintesdados: nome, login/nome, senha e a prioridade.



[RF-23] Alterar UsuárioPrioridade: ImportanteSolicitante: Administrador

Descrição: O sistema deve permitir alterar os dados cadastrais de um usuário, atravésde uma consulta por nome.[RF-24] Consultar Usuário

Prioridade: ImportanteSolicitante: Administrador Descrição: O sistema deve permitir fazer consulta de um usuário através do nome do

usuário. Sendo que o resultado da consulta será exibido em tela.[RF-25] Excluir Usuário

Prioridade: ImportanteSolicitante: Administrador Descrição: O sistema deve permitir excluir um usuário a partir de uma consulta por

nome do usuário.[RF-26] Logar no Sistema

Prioridade: EssencialSolicitante: UsuárioDescrição: O sistema deve permitir que o usuário faça login no mesmo, através de um

login e uma senha, sendo que as funcionalidades do sistema serão acessíveis aos usuários deacordo com o seu nível de privilégios.[RF-27] Gerar Relatório

Prioridade: DesejávelSolicitante: GerenteDescrição: O sistema deve permitir gerar relatórios específicos, como de novos

cadastros de hóspedes realizados em um determinado período, relatórios de gastos de umaempresa já cadastrada em um determinado período, entre outros.

5.2 Requisitos Não-Funcionais

Requisitos não funcionais, ao contrário dos funcionais, não expressam nenhumafunção (transformação) a ser implementada em um sistema, eles expressam condições decomportamento e restrições nos serviços do sistema, tais como restrições de tempo, restriçõesno processo de desenvolvimento, padrões, etc, que devem prevalecer. Segue abaixo osrequisitos não funcionais do sistema e uma breve descrição dos mesmos.

Quanto a Segurança:[RNF-01] Confidencialidade dos dadosPrioridade: EssencialSolicitante: GerenteDescrição: O sistema deve garantir a confidencialidade dos dados.Operacionalização: A confidencialidade dos dados será implementada através de uma

política de login e senha, em que cada usuário poderá acessar dados conforme seu nível de privilégio.[RNF-02] Integridade dos dados

Prioridade: EssencialSolicitante: Gerente

Descrição: O sistema deve garantir a integridade dos dados.



Operacionalização: A integridade dos dados será mantida através de uma política dearmazenamento de dados removidos, que consistirá em ao invés de apagar os dados, apenasdesativá-los, marcando-os como inativos.

[RNF-03] Disponibilidade dos dadosPrioridade: DesejávelSolicitante: GerenteDescrição: O sistema deve garantir a disponibilidade dos dados.Operacionalização: A disponibilidade dos dados será realizada através de backups

feitos em tempos programados, além da política de armazenamento de dados removidos.Quanto a Usabilidade:

[RNF-01] Deve ser fácil de utilizar Prioridade: ImportanteSolicitante: RecepcionistaDescrição: O sistema deve ser fácil de ser usado e de localizar as operações desejadas.

Operacionalização: Para ter agilidade ao acessar as funcionalidades mais utilizadas,haverá teclas de atalho, que também facilitarão o alcance dos menus e funções do sistema aousuário. Bem como, as interfaces terão o padrão ATA, como esta descrito no apêndice D, como objetivo de uma melhor visualização e entendimento do software. E também terá ummanual de ajuda, descrevendo as funcionalidades do sistema.

Quanto a Confiabilidade:[RNF-01] Confiabilidade dos dados

Prioridade: ImportanteSolicitante: RecepcionistaDescrição: O sistema deve garantir a confiabilidade dos dados.Operacionalização: O sistema emitirá mensagens de confirmação da operação

realizada, e também fará de tempos em tempos o backup dos dados.Quanto ao Custo:

[RNF-01] Deve ter um custo baixoPrioridade: DesejávelSolicitante: GerenteDescrição: O sistema deve ter um custo baixo de desenvolvimento.Operacionalização: Para o custo de desenvolvimento ser baixo, o sistema irá utilizar

apenas ferramentas gratuitas.Quanto a Performance:

[RNF-01] Configuração do Computador

Prioridade: ImportanteSolicitante: GerenteDescrição: O sistema deve funcionar em uma configuração especifica de máquina.Operacionalização: Para ter uma boa performance o sistema deverá rodar em uma

máquina com configuração A, a mesma esta detalhada no apêndice D.Quanto a Evolução:

[RNF-01] Fácil de Atualizar Prioridade: EssencialSolicitante: GerenteDescrição: O sistema deve garantir que futuramente possam ser atualizado.Operacionalização: O sistema irá utilizar o padrão de desenvolvimento MVC (Modelo,

Visão e Controle), para obter uma maior modularidade do software, garantindo que alterações



e evoluções no sistema sejam possíveis com uma maior facilidade. E também, utiliza-ráOrientação a Objetos para uma melhor organização e entendimento do código fonte.



Capítulo 6

Caso de Uso do Sistema

O diagrama de caso de uso Figura (6.1) mostra a interação entre o sistema e os atoresenvolvidos. Serve para facilitar o entendimento mostrando sua visão externa, mostrando as

funcionalidades que o sistema provê para cada ator, sendo uma das maneiras mais tradicionaisde se documentar os requisitos. Este diagrama ajuda a formalizar as funções que o sistema

precisa fazer.

Figura 6.1: Diagrama de Caso de Uso.



6.1 Descrições Textuais dos Casos de Uso

Nesta sessão descreveremos os Casos de Uso do Sistema através de descrições textuaisdetalhadas:Caso de uso 1: GERENCIAR HÓSPEDEObjetivo: Realizar o gerenciamento de um hóspede.Nível de UsuárioPré-condições: Recepcionista logado no sistema.Pós-condições: Hóspede devidamente gerenciado.Ator: RecepcionistaCenário PrincipalPasso 1: O recepcionista obtém os dados necessários do hóspede para o gerenciamento.Passo 2: O recepcionista escolhe a operação incluir um novo hóspede.

Passo 3: O recepcionista obtém os dados do hóspede.Passo 4: O recepcionista insere os dados do hóspede no sistema.Passo 5: O sistema armazena as informações do hóspede.Passo 6: O sistema emite mensagem de operação efetuada.Cenário Secundário (Extensões)Passo 2.1: Recepcionista escolhe operação remover: caso de uso Remover.Passo 2.2: Recepcionista escolhe operação alterar: caso de uso Alterar.Passo 2.3: Recepcionista escolhe operação consultar: caso de uso Consultar.Passo 4.1: Dados do hóspede inválidos: o sistema notifica o erro ao recepcionista.Passo 5.1: Hóspede já cadastrado: o sistema cancela o cadastro e notifica o erro aorecepcionista.

Caso de uso 2: GERENCIAR EMPRESAObjetivo: Realizar o gerenciamento de uma empresa.Nível de UsuárioPré-condições: Recepcionista logado no sistema.Pós-condições: Empresa devidamente gerenciada.Ator: RecepcionistaCenário PrincipalPasso 1: O recepcionista obtém os dados necessários da empresa para o gerenciamento.Passo 2: O recepcionista escolhe a operação incluir uma nova empresa.Passo 3: O recepcionista obtém os dados da empresa.

Passo 4: O recepcionista insere os dados da empresa no sistema.Passo 5: O sistema armazena as informações da empresa.Passo 6: O sistema emite mensagem de operação efetuada.Cenário Secundário (Extensões)Passo 2.1: Recepcionista escolhe operação remover: caso de uso Remover.Passo 2.2: Recepcionista escolhe operação alterar: caso de uso Alterar.Passo 2.3: Recepcionista escolhe operação consultar: caso de uso Consultar.Passo 4.1: Dados da empresa inválidos: o sistema notifica o erro ao recepcionista.Passo 5.1: Empresa já cadastrada: o sistema cancela o cadastro e notifica o erro aorecepcionista.

Caso de uso 3: GERENCIAR QUARTOObjetivo: Realizar o gerenciamento de um quarto.



Nível de UsuárioPré-condições: Gerente logado no sistema.Pós-condições: Quarto devidamente gerenciado.

Ator: GerenteCenário PrincipalPasso 1: O gerente obtém os dados necessários do quarto para o gerenciamento.Passo 2: O gerente escolhe a operação incluir um novo quarto.Passo 3: O gerente obtém os dados do quarto.Passo 4: O gerente insere os dados do quarto no sistema.Passo 5: O sistema armazena as informações do quarto.Passo 6: O sistema emite mensagem de operação efetuada.Cenário Secundário (Extensões)Passo 2.1: Gerente escolhe operação remover: caso de uso Remover.Passo 2.2: Gerente escolhe operação alterar: caso de uso Alterar.

Passo 2.3: Gerente escolhe operação consultar: caso de uso Consultar.Passo 4.1: Dados do quarto inválidos: o sistema notifica o erro ao gerente.Passo 5.1: Quarto já cadastrado: o sistema cancela o cadastro e notifica o erro ao gerente.

Caso de uso 4: GERENCIAR USUÁRIO Objetivo: Realizar o gerenciamento de um usuário.Nível de UsuárioPré-condições: Administrador logado no sistema.Pós-condições: Usuário devidamente gerenciado.Ator: Administrador

Cenário PrincipalPasso 1: O administrador obtém os dados necessários do usuário para o gerenciamento.Passo 2: O administrador escolhe a operação incluir um novo usuário.Passo 3: O administrador obtém os dados do usuário.Passo 4: O administrador insere os dados do usuário no sistema.Passo 5: O sistema armazena as informações do usuário.Passo 6: O sistema emite mensagem de operação efetuada.Cenário Secundário (Extensões)Passo 2.1: Administrador escolhe operação remover: caso de uso Remover.Passo 2.2: Administrador escolhe operação alterar: caso de uso Alterar.Passo 2.3: Administrador escolhe operação consultar: caso de uso Consultar.

Passo 4.1: Dados do usuário inválidos: o sistema notifica o erro ao administrador.Passo 5.1: Usuário já cadastrado: o sistema cancela o cadastro e notifica o erro aoadministrador.

Caso de uso 5: GERENCIAR DIÁRIAObjetivo: Realizar o gerenciamento de uma diária.Nível de UsuárioPré-condições: Recepcionista logado no sistema, quarto disponível e hóspede cadastrado.Pós-condições: Diária devidamente gerenciada.Ator: RecepcionistaCenário Principal

Passo 1: O recepcionista obtém os dados necessários da diária para o gerenciamento.Passo 2: O recepcionista escolhe a operação incluir uma nova diária.



Passo 3: O recepcionista obtém os dados da diária.Passo 4: O recepcionista insere os dados da diária no sistema.Passo 5: O sistema armazena as informações da diária.

Passo 6: O sistema emite mensagem de operação efetuada.Cenário Secundário (Extensões)Passo 2.1: Recepcionista escolhe operação remover: caso de uso Remover.Passo 2.2: Recepcionista escolhe operação alterar: caso de uso Alterar.Passo 2.3: Recepcionista escolhe operação consultar: caso de uso Consultar.Passo 4.1: Dados da diária inválidos: o sistema notifica o erro ao recepcionista.Passo 5.1: Diária já cadastrada: o sistema cancela o cadastro e notifica o erro ao recepcionista.

Caso de uso 6: GERENCIAR RESERVAObjetivo: Realizar o gerenciamento de uma reserva.Nível de UsuárioPré-condições: Recepcionista logado no sistema, quarto disponível e hóspede cadastrado.Pós-condições: Reserva devidamente gerenciada.Ator: RecepcionistaCenário PrincipalPasso 1: O recepcionista obtém os dados necessários da reserva para o gerenciamento.Passo 2: O recepcionista escolhe a operação incluir uma nova reserva.Passo 3: O recepcionista obtém os dados da reserva.Passo 4: O recepcionista insere os dados da reserva no sistema.Passo 5: O sistema armazena as informações da reserva.Passo 6: O sistema emite mensagem de operação efetuada.

Cenário Secundário (Extensões)Passo 2.1: Recepcionista escolhe operação remover: caso de uso Remover.Passo 2.2: Recepcionista escolhe operação alterar: caso de uso Alterar.Passo 2.3: Recepcionista escolhe operação consultar: caso de uso Consultar.Passo 4.1: Dados da reserva inválidos: o sistema notifica o erro ao recepcionista.Passo 5.1: Reserva já cadastrada: o sistema cancela o cadastro e notifica o erro aorecepcionista.

Caso de uso 7: RELATÓRIOObjetivo: Realizar a impressão ou exibição de relatórios, sendo estes disponíveis somente aogerente.

Nível de UsuárioPré-condições: Gerente logado no sistema.Pós-condições: Relatório impresso ou exibido com sucesso.Ator: Gerente.Cenário PrincipalPasso 1: O gerente seleciona o relatório desejado.Passo 2: O sistema recebe esta escolha do gerente e acessa o Banco de Dados.Passo 3: O gerente escolhe o modo de exibição, se vai ser em tela (exibido) ou impresso.Passo 4: Conforme a escolha do gerente o sistema exibe ou imprime o relatório.Cenário Secundário (Extensões)Passo 2.1: Falha no acesso ao banco de dados: o sistema cancela exibição e notifica o erro ao

gerente.



Passo 4.1: Falha de hardware de impressão: o sistema cancela exibição do relatório e umamensagem de erro é enviada ao gerente.

Caso de uso 8: FINALIZAR Objetivo: Realizar a finalização de uma diária.Nível de UsuárioPré-condições: Recepcionista logado no sistema.Pós-condições: A finalização da diária realizada com sucesso.Ator: Recepcionista.Cenário PrincipalPasso 1: O recepcionista visualiza no sistema a janela de diárias .Passo 2: O recepcionista seleciona o número do quarto, cuja diária será finalizar.Passo 3: O recepcionista finaliza a diária.Passo 4: O sistema captura os dados da diária que o recepcionista deseja finalizar no Banco deDados.Passo 5: O sistema mostra em tela os dados da(s) diária(s) do hóspede naquele quarto, seusgastos extras e o total da(s) diária(s).Passo 6: Hóspede realiza o pagamento e o recepcionista confirma a finalização.Passo 7: O sistema armazena o valor recebido no Banco de Dados de acordo com quem estálogado no sistema, e se o hospede é de alguma empresa.Passo 8: O sistema emite mensagem de diária finalizada.Cenário Secundário (Extensões)Passo 4.1: Falha no acesso ao banco de dados: o sistema cancela a operação e notifica o erroao recepcionista.

Passo 6.1: Hóspede não realiza o pagamento: o sistema cancela a operação.Passo 7.1: Falha no acesso ao banco de dados: o sistema cancela a operação e notifica o erroao recepcionista.

Caso de uso 9: LOGINObjetivo: Realizar o login no sistema disponibilizando acesso adequado as funcionalidades deacordo com o nível de privilégios.Nível de UsuárioPré-condições: Usuário cadastrado no sistema com um login e uma senha.Pós-condições: Usuário ligado com sucesso e com seu devido acesso autorizado.Ator: Usuário.

Cenário PrincipalPasso 1: O usuário ingressa o login e a senha no sistema.Passo 2: O sistema recebe estes dados de login e acessa o Banco de Dados.Passo 3: O sistema permite ao usuário usar as funcionalidades de acordo com o seu nível de

privilégio.Cenário Secundário (Extensões)Passo 2.1: Senha ou login incorretos: o sistema cancela o login e notifica o erro ao usuário.Passo 2.2: Falha no acesso ao banco de dados: o sistema cancela o login e notifica o erro aousuário.

Caso de uso 10: ALTERAR Objetivo: Alterar os dados cadastrais de uma entidade.Nível de Usuário



Pré-condições: Recepcionista logado no sistema.Pós-condições: Dados da entidade alterados com sucesso.Ator: Recepcionista.

Cenário PrincipalPasso 1: Recepcionista obtém os novos dados da entidade a ser alterada.Passo 2: O sistema busca a entidade a ser alterada no Banco de Dados.Passo 3: O sistema exibe os dados cadastrais da entidade.Passo 4: O recepcionista altera os dados da entidade.Passo 5: O sistema captura os novos dados e atualiza estas informações.Passo 6: O sistema emite mensagem de dados atualizados.Cenário Secundário (Extensões)Passo 2.1: Empresa não localizada: o sistema cancela a operação e notifica ao recepcionistaque a empresa não está cadastrada.Passo 2.2: Falha no acesso ao banco de dados: o sistema cancela a exibição do cadastro da

empresa e notifica o erro ao recepcionista.Passo 5.1: Falha no acesso ao banco de dados: o sistema cancela a atualização e notifica oerro ao recepcionista.

Caso de uso 11: REMOVER Objetivo: Remove os dados de uma entidade.Nível de UsuárioPré-condições: Recepcionista logado no sistema.Pós-condições: Dados da entidade removidos com sucesso.Ator: Recepcionista

Cenário PrincipalPasso 1: O recepcionista entra com os dados necessários para remoção.Passo 2: O sistema busca a entidade a ser excluída no Banco de Dados e o mostra em tela.Passo 3: O recepcionista confirma a exclusão.Passo 4: O sistema remove o cadastro da entidade (marcando como inativa).Passo 5: O sistema emite mensagem de sucesso.Cenário Secundário (Extensões)Passo 2.1: Entidade não localizada: o sistema cancela a operação e notifica a inexistência daentidade ao recepcionista.Passo 2.2: Falha no acesso ao banco de dados: o sistema cancela a remoção e notifica o erroao recepcionista.

Passo 3.1: Não confirmação de remoção: o sistema cancela a remoção.

Caso de uso 12: CONSULTAR Objetivo: Consultar os dados cadastrais de uma entidade.Nível de UsuárioPré-condições: Recepcionista logado no sistema.Pós-condições: Consulta realizada com sucesso com sucesso.Ator: Recepcionista.Cenário PrincipalPasso 1: O recepcionista entra com os dados da entidade para uma consulta no sistema.Passo 2: O sistema busca as informações da entidade.

Passo 3: O sistema exibe os dados da entidade em tela.Cenário Secundário (Extensões)



Passo 2.1: Entidade não localizada: o sistema cancela a operação e notifica a inexistência daEntidade ao recepcionista.

Caso de uso 13: CANCELAR Objetivo: Realizar o cancelamento de uma diária ou reserva.Nível de UsuárioPré-condições: Recepcionista logado no sistema.Pós-condições: O cancelamento realizado com sucesso.Ator: Recepcionista.Cenário PrincipalPasso 1: O recepcionista visualiza no sistema as diárias ou as reservas.Passo 2: O recepcionista seleciona a reserva ou diária que deseja cancelar.Passo 3: O recepcionista cancela a diária ou a reserva.Passo 4: O sistema captura os dados da diária ou reserva que o recepcionista deseja cancelar.Passo 5: O sistema remove as informações.Passo 6: O sistema emite mensagem de sucesso.Cenário Secundário (Extensões)Passo 4.1: Diária ou reserva não localizada: o sistema cancela a operação e notifica ainexistência ao recepcionista.

Caso de uso 14: INCLUIR Objetivo: Realizar a inserção de uma entidade (hóspede, empresa, diária, reserva, quarto ouusuário).Nível de Usuário

Pré-condições: Recepcionista logado no sistema.Pós-condições: Entidade inserida com sucesso.Ator: RecepcionistaCenário PrincipalPasso 1: O recepcionista obtém os dados cadastrais da entidade.Passo 2: O recepcionista insere os dados da entidade no sistema.Passo 3: O sistema insere os dados no Banco de Dados.Passo 4: O sistema emite mensagem de inserção efetuada.Cenário Secundário (Extensões)Passo 2.1: Dados da entidade inválidos: o sistema notifica o erro ao recepcionista.Passo 3.1: Falha no acesso ao banco de dados: o sistema cancela o cadastro e notifica o erro

ao recepcionista.Passo 3.2: Entidade já cadastrada: o sistema cancela o cadastro e notifica o erro aorecepcionista.



Capítulo 7

Diagrama de Classe do Sistema

O diagrama de classes Figura (7.1) demonstra como será a representação e as relaçõesentre as classes do sistema. Mostrando os métodos e atributos de cada classe, bem como os

relacionamentos que ela possui.

7.1 Descrições Textuais das Classes do Sistema

Está sessão demonstra uma breve descrição textual das classes apresentadas nodiagrama.

HóspedeA classe hóspede talvez seja a mais importante do sistema, devido ao fato de que tudo

está relacionado direta ou indiretamente com ela, sendo o hóspede é o mais interessado no

funcionamento do sistema. Ela tem uma agregação com a classe empresa, na qual um hóspedeestá relacionado somente com uma empresa, uma associação simples com a classerecepcionista que é quem gerencia a classe, e composições com as classes diária e reserva, nasquais podem haver zero ou mais diárias ou reservas.

EmpresaEsta classe armazena e oferece informações sobre a empresa que um hóspede

pertence. Ela tem uma agregação com a classe hóspede, na qual uma empresa está relacionadacom vários hóspedes, e uma associação simples com a classe recepcionista que é quemgerencia a classe.

UsuárioÉ uma classe genérica, que tem atributos para a autenticação de um usuário, sendo a

classe da qual a classe administrador e recepcionista derivam. Tem uma associação simplescom a classe administrador, que é quem a gerencia.

AdministradorÉ a classe que gerencia os usuários do sistema, tendo uma associação simples com a

classe usuário, da qual também é derivada.

RecepcionistaÉ a classe que gerencia todas as funções para o funcionamento básico do sistema,

sendo derivada da classe usuário. Tem associações simples com as classes: hóspede, empresa,reserva e diária, as quais gerencia.



GerenteEsta classe herda todas as funções e métodos da classe recepcionista. Além das

funcionalidades herdadas, ela ainda tem uma associação simples com a classe quarto, a qualgerencia. Esta classe também gera os relatórios de empresa, hóspede e diárias.

QuartoÉ a classe que armazena e oferece informações a respeito de um quarto. Ela tem uma

associação simples com a classe gerente, a qual a gerencia. Alem disso, ela tem composiçõescom a classe reserva, sendo que um quarto está relacionado com zero ou mais reservas, e coma classe diária, sendo que também um quarto está relacionado com zero ou mais diárias.

ReservaEsta classe tem informações sobre a reserva de um quarto. Tem uma associação

simples com a classe recepcionista, a qual a gerencia, e uma composição com a classe quarto, pois para cada quarto pode haver várias reservas, e para existir uma reserva é necessário umquarto disponível. Também tem uma composição com a classe hóspede, pois para reserva énecessário um hóspede.

DiáriaA classe diária, assim como a classe hóspede, também é uma das mais importantes

para o funcionamento do sistema, pois é o objetivo principal do hóspede. Tem uma associaçãosimples com a classe recepcionista, a qual a gerencia, e uma composição com a classe quarto,

pois para cada quarto pode haver várias diárias, e para existir uma diária é necessário umquarto disponível. Também tem uma composição com a classe hóspede, pois para a diária é

necessário um hóspede.



Figura 7.1: Diagrama de Classe.



Capítulo 8

ConclusãoEste estudo e análise da engenharia de requisitos foi feito tomando como base que a

alternativa escolhida para o desenvolvimento é a mais viável. Para ter uma visão geral da

organização e um melhor entendimento de como é o funcionamento da empresa, foram feitosos diagramas de modelagem organizacional i*, incluindo os modelos de dependências erazões estratégicas.

Os requisitos, tanto funcionais quanto não-funcionais foram elicitados a partir daentrevista realizada com o cliente, sendo que para os requisitos não-funcionais foi feito o usodo diagrama NFR Framework para uma melhor compreensão de como satisfazê-los.

Para melhor entender como o usuário irá interagir com o sistema, foi feita a construçãodo diagrama de caso de uso, dando uma visão mais geral das necessidades que o usuário

possui. Foi feita uma descrição para cada caso de uso, o que ajudou a compreender melhor todos os passos e a execução de cada funcionalidade/tarefa.

Ainda foi utilizado um diagrama de classes para identificar as principais classes que o

sistema deverá implementar, e como essas classes relacionam-se umas com as outras, bemcomo os atributos e operações que são relevantes a cada uma delas.Como este trabalho é a primeira parte de um todo, foi feito um cronograma de

atividades baseado na metodologia em espiral, escolhida para o desenvolvimento do sistema,que ajudará no processo de desenvolvimento do sistema, durante as várias etapas, até que sejadesenvolvido e entregue um protótipo final.

Esta documentação servirá de apoio e base de referência para as próximas fases dodesenvolvimento do sistema, desde o projeto, implementação e testes do mesmo.



Apêndice A

Sobre o Hotel RealO Hotel Real atualmente é dirigido pelas famílias Girardello e Vacari, tornando o hotel

um ambiente familiar. Por se tratar de duas famílias, a divisão de serviços é feita da seguinte

forma: em um determinado dia uma família cuida do hotel, e no outro dia é a outra famíliaque deve cuidar, e assim sucessivamente.Os cômodos se dividem em quartos e apartamentos, destes, 24 são quartos e 11 são

apartamentos. Os quartos se caracterizam pela ausência de banheiro, os banheiros sãocoletivos nos corredores e os apartamentos possuem banheiro no interior do ambiente. Ambos

possuem televisão, ventilador, guarda roupa e o número de camas variam de 1 a 4, algumas decasal, outras de solteiro.

Possui estacionamento fechado com vaga para aproximadamente 15 veículos. Contatambém com serviço de reservas que podem ser efetuadas via telefone ou pessoalmente,deixando alguns dados, e no caso de eventos ou quando o hotel está lotado é necessáriodepositar uma porcentagem do valor total.

Para ser efetuada a entrada no hotel é realizado um cadastro, caso o hóspede já estejacadastrado é realizado apenas o registo no livro de diárias. Caso o hóspede não tenha bagagens o pagamento deve ser feito adiantado.

O café da manhã é uma cortesia do hotel. Também nas dependências do hotel possuium bar, onde os produtos consumidos podem ser adicionados ao valor da diária. Por fim, asformas de pagamento podem ser feitas em dinheiro, cartão de crédito master card e em algunscasos sendo aceito cheques também.

Atualmente todos os dados e serviços são controlados manualmente em livros deregistros e cadernos de anotações, como: livro de cadastros, livro de diárias, caderno dereservas e caderno de gastos das empresas. Isso acaba tornando o sistema muito lento eimpreciso, conforme é descrito no Apêndice C.



Apêndice B

EntrevistaApós a definição da empresa, foi dado início ao processo de coleta de dados, sendo

realizada uma entrevista.

A entrevista foi realizada dia 18 de março de 2009 (Quarta-Feira) das 9:00 às 11:00horas nas dependências do Hotel Real. A entrevista foi realizada com a sócia/gerente do hotelClementina Aparecida Copini Girardello, portadora do CPF 762.282.829-72 e RG 7.067.283-9. Por se tratar de uma sociedade familiar, todos os sócios desenvolvem diversas atividadesdentro do hotel, desde zeladores até divisão de lucros, sendo assim, a entrevistada em questãotem conhecimento de todas atividades que ocorrem no hotel. As informações colhidas foramfundamentais para entender como funciona o hotel, seus principais problemas e como umsoftware gerenciador hoteleiro poderia ajudar na solução dos mesmos.

Abaixo relacionamos as questões levantadas e as respectivas respostas obtidas daentrevistada.

1. Como é feita a locação dos quartos do hotel?R: Primeiro mostramos o quarto para a pessoa, se ela quiser ficar e é a primeira vez que vemao hotel ou seja, não tem cadastro ainda, então é feito um cadastro, e é marcado no livro dediárias a entrada da pessoa.

2. Onde é feito o cadastro do Hóspede?R: O cadastro é feito em um livro que chamamos de livro de cadastros de Hóspedes.

3. Quais os dados necessários do Hóspede para o cadastro?R: Nome, nacionalidade, estado civil, profissão, idade, data entrada, número docomodo(quarto), procedência, data de saída, destino, número do RG, e no campo observações

é marcado o telefone da pessoa já que este campo não tem no livro,mas as vezes precisamostambém marcar observações, e uma coisa que também não tem é o número da placa do carro,que deveria ter pois se a polícia precisa encontra-lo fica mais fácil de localiza-lo.

4. Como é feito o controle das diárias?R: Temos um livro onde marcamos as diárias, cada folha é um dia onde tem os números detodos os quartos e mostra naqueles que estão ocupados: o nome da pessoa; o número decamas, se for mensalista(pessoa que aluga o quarto para o mês todo) no lugar é colocado um F

para indicar que é fixo; temos a data da entrada da pessoa no hotel, se for mensalista no lugar colocamos a data que vence o mês. Ao lado do nome se a pessoa for de uma empresacolocamos o nome da empresa, se emprestarmos toalhas colocamos uns X's correspondentesao número de toalhas, tem também marcado o consumo que ele teve na lanchoneteacrescentados com +. É marcado também o valor da diária conforme o quarto escolhido e se



já esta pago ou não. Num cantinho bem em cima tem o número de pães e cucas que sãocomprados para o café da manhã.

5. Como é realizado o pagamento?R: Na hora de pagar temos que folhar o livro para ver quantas diárias a pessoa tem e vamossomando, e também somamos o consumo na lanchonete, se teve.

6. Quais as formas de pagamento?R: Dinheiro, cartão Master e as vezes aceitamos cheque também.

7. A pessoa pode pagar adiantado?R: Sim, até se a pessoa não tem bagagem ou é má encarada nós cobramos antes o valor dadiária como uma garantia, senão a pessoa que escolhe o horário de pagamento.

8. Como é feita a reserva adiantada dos quartos?R: A pessoa liga e então é marcado em um outro livro o nome da pessoa, se é de algumaempresa é marcado também o nome da empresa, a data da prevista entrada, o telefone, onúmero de pessoas, observações, e principalmente a hora de prevista chegada pois se a pessoanão chegar até a hora marcada o quarto é liberado.

9. A pessoa tem que pagar adiantado para conseguir a reserva?R: As vezes sim, depende do movimento no hotel, mas é cobrado um adiantamento, uma

porcentagem que deve ser depositada na conta do hotel, como uma garantia de que a pessoavai mesmo se hospedar, isso acontece em eventos, por exemplo na semana do Show Rural,que é quando o hotel fica cheio.

10. Quantos quartos o hotel tem? Se tem uma espectativa de aumentar o número dequartos?R: Temos 24 quartos, que são quartos mais simples onde o banheiro é coletivo, e tambémtemos 11 apartamentos que são quartos com banheiro, mais ajeitados e com internet. E temsim a possibilidade de aumentar o número de quartos futuramente.

11. Os quartos tem valores diferentes?R: Sim, os quartos tem diária de R$28,00 reais, e os apartamentos são R$40,00 reais, masconforme o número de pessoas por quarto, fazemos descontos.

12. Como é a hierarquia dentro da empresa?R: Temos as zeladoras que cuidam da limpeza dos quartos. Mas no demais não se tem umahierarquia, todo mundo faz tudo, mas possivelmente mais tarde pode haver uma recepcionista.O que se tem é uma sociedade, onde um dia uma família cuida do hotel e no outro é a outrafamília que cuida, e nos finais de semana de sexta, sábado e domingo é a mesma família quecuida sempre intercalando.

13. Como é feito o acerto entre os sócios? Os lucros são divididos entre as partes?R: Não, cada sócio ganha o lucro pelos dias que cuidou, e essa distinção de quem cuidou dohotel é feita pela letra da pessoa que marcou as diárias no caderno de diárias. E esse acerto é

semanal.



14. É feito algum tipo de relatório, controle do hotel?R: Temos um caderno para controle nosso de quanto uma empresa gastou no mês no hotel,marcamos neste caderno o nome da empresa no início da folha e depois o nome das

pessoas(funcionários) com os dias(datas) que esse funcionário ficou no hotel e o valor gasto, etambém se está pago ou não. E bem no final do caderno a soma total dos gastos de todos asdiárias da empresa.

15. Vocês tem algum cadastro dessas empresas?R: Sim, são as fichinhas verdes que ficam guardadas em uma pasta separadas por ordemalfabética.

16. Quais são os dados requisitados para o cadastro das empresas?R: A razão social, o endereço da empresa, os telefones da empresa, o CNPJ da empresa, ainscrição estadual, o e-mail,site da empresa, com quem devemos falar quando ligarmos para

a empresa o cargo desta empresa e também as vezes marcamos algumas observações sobre aempresa.

17. O que é este carimbo no livro de Cadastros dos Hóspedes?R: É o carimbo da polícia, pois todo mês é levado este livro para a polícia, para elesverificarem as pessoas que passaram no hotel no mês, e é pago uma taxa por pessoa que éverificada.

A gerente entrevistada pode ser contactada pelo telefone (45) 3223-0376 ou ainda noendereço do hotel: Av. Brasil, 4506, Centro de Cascavel-PR. A Figura (B.1) é um registrofotográfico da reunião que gerou a entrevista.

Figura B.1: Foto da Entrevista.



Apêndice C

Deficiências dos Livros de RegistrosDurante a visita ao hotel foram observados vários problemas no sistema atual, que

conta com um livro de registros, um livro de diárias e um caderno de reservas.

Um dos problemas é quanto a consulta de hóspedes e empresas cadastradas.Atualmente os dados referentes aos hóspedes são armazenados em um livro de registros(Figura (C.1)) e os dados das empresas são armazenados em um arquivo de fichas (Figura(C.2)), o que torna inviável pesquisar informações sobre um determinado hóspede ouempresa.

O controle de diárias (Figura (C.3)) é feito em um outro livro, onde todas asinformações quanto a estadia do hóspede é colocada em uma única linha, o que se tornamuitas vezes ilegível.

O controle financeiro também é feito manualmente, somando os valores do livro dediárias com calculadora, o que torna o sistema suscetível a erros.

O controle de reservas (Figura (C.4)) é feito em um caderno de anotações, o que torna

a pesquisa demorada e imprecisa.

Figura C.1: Livro de registros.



Figura C.2: Ficha de cadastro de empresas.

Figura C.3: Controle de diárias.



Figura C.4: Controle de reservas.



Apêndice D

Glossário− Computador com configuração A: CPU Intel 2,0GHz, 1GB de memória RAM,

40GB de HD, Teclado, Mouse, Monitor 15”.

− Interfaces no padrão ATA: Os botões com as mesmas funcionalidades estarãolocalizados no mesmo lugar nas diferentes janelas. A interface terá uma aparênciaagradável, com cores neutras. Para melhor entendimento e visualização dos botões,eles terão figuras associadas. Os campos obrigatórios de cadastro serãoidentificados com um asterisco (*).



Formulário do Relatório da EquipeTodos os membros da equipe desempenharam os mesmos papéis, com as mesmas

contribuições, inclusive na criação e revisão de todos os textos e diagramas deste trabalho.

Nome % Esforço da Equipe Assinatura

Adriano D. Girardello 33,33% _____________________

Ana P. Fredrich 33,33% _____________________

Tiago A. S. Sippert 33,33% _____________________

Documents

Hotel Unioeste