Processo de Engenharia de Software II

(1)

UNIOESTE - Universidade Estadual do Oeste do Paraná CCET – Centro de ciências Exatas e Tecnológicas

Colegiado de Ciência da Computação

Curso de Bacharelado em Ciência da Computação

Processo de Engenharia de Software II

Sistema SGH

Sistema de Gerenciamento de Hotel

(2)

Diego Henrique Pagani Julio Cesar Lazzarim Mauriverti da Silva Junior

Especificação de Requisitos e Modelagem Orientada a Objetos

Professor: Victor Francisco Araya Santander

(3)

Sumário

1 . Motivação ... 4 2. Sistema Proposto ... 4 3. Requisitos Funcionais... 5 4. Modelagem Organizacional ... 5 4.1 Diagramas SD ... 5 4.2 Diagramas SR ... 8 5. Requisitos Não-Funcionais ... 16 5.1 Requisitos de Processo ... 16 5.2 Requisitos de Produto ... 16

6. Diagrama de Casos de Uso... 18

7. Diagramas de Classe ... 30

8. Metodologia ... 321

9. Cronograma ... 332

(4)

4

1. Motivação

Na necessidade de desenvolver um sistema para o complemento do co-nhecimento de duas disciplinas essenciais, Banco de Dados e Processo de En-genharia de Software, foi escolhido por desenvolver um sistema que seja res-ponsável pelo controle de um hotel. Ele abrange uma complexidade de nível que seja possível entender como é desenvolver um software desde o início.

2. Sistema Proposto

O sistema proposto será desenvolvido utilizando as tecnologias que atu-almente são destaque de mercado: Linguagem Java utilizando JDBC para cone-xão com banco de dados Postgresql. Não será utilizado nenhum framework de iteração, como Hibernate.

O sistema deverá possibilitar o controle de Quartos, Clientes, Funcioná-rios, Cargos, Departamentos.

 Quartos: O controle se dará em estabelecer um número para o quarto e dizer se este quarto está disponível ou não e mostrar os períodos de reserva, se houver!

 Clientes:

o Cadastro, edição, busca exclusão e reserva.

o O cliente pode fazer o check-in no hotel, escolhendo um quarto e du-rante a sua estadia pode escolher consumir determinados itens. Além do check-in, o check-out é necessário para finalizar a conta do cliente e realizar a liberação do quarto.

o O cliente também pode reservar um quarto por um determinado perío-do.

o

 Funcionários:

o Cadastro, edição, busca e exclusão.

(5)

ape-5 nas o controle de quem realmente trabalha no hotel e o salário do in-divíduo.

 Cargos:

o São os cargos dos funcionários do hotel, tal como atendente, cozinhei-ro, entre outros.

 Departamentos:

o Cada departamento é responsável por algum setor do hotel. Como Recepção, Cozinha, Lavanderia, entre outros.

o Cada departamento tem funcionários agregados e apenas um único gerente.

 Itens:

o Estes itens são os produtos que podem ser consumidos pelo cliente

Com base nas informações adquiridas, foi elaborado este documento que tem o objetivo documentar os requisitos (funcionais e não funcionais) do sistema e apresentar uma modelagem orientada a objetos dos mesmos, para que possam ser usados nas demais fases do projeto.

3. Modelagem Organizacional

Nesta seção apresentamos os diagramas de dependências estratégicas e o diagrama de relacionamentos estratégicos relacionado ao projeto e as descrições do mesmo.

3.1 Diagramas SD

O diagrama SD (Strategic Dependency) que envolve o sistema SGH é esquematizado na figura abaixo:

(6)

6 Esse diagrama é composto por cinco atores: Funcionário, Atendente, Ca-mareira, Garçom e Gerente. Camareira e garçom não tem acesso ao sistema, neste sistema.

O ator Funcionário é o ator principal, em que os outros herdam dele al-guns aspectos.

O ator Atendente é o principal responsável pelo uso do sistema, já que ele basicamente faz quase todas as operações do hotel. Ele responsável por

(7)

geren-7 ciar:  Clientes  Reservas  Check-in  Check-out

 Consulta dos quartos (alimentação ou produtos)

O ator Gerente, além das operações do atendente, cabe a ele cuidar:

 Itens (produtos para venda aos clientes, como refrigerante).

 Funcionários

 Departamentos

Em questão de gerenciar Clientes, envolve-se o Cadastro, alteração, visuali-zação e deleção dos dados pessoais de cada cliente que possa a vir se hospe-dar no hotel. Não há dependências que possam ocorrer, apenas que o atenden-te atenden-tenha feito o login no sisatenden-tema previamenatenden-te.

Em Reservas, cabe ao atendente ouvir o pedido do cliente e verificar a dis-ponibilidade de certo tipo de quarto em um determinado período para um cliente. Com isso essa reserva feita, não pode ser possível que outro cliente ocupe um quarto reservado no período em que exista a reserva.

O Check-in se dá que determinado quarto é marcado como ocupado pelo sistema e não pode ser feito nenhuma reserva nem outro check-in utilizando o mesmo quarto no mesmo período.

Em Check-out é feito todo o cálculo do valor total da(s) diária(s) e dos itens consumidos pelo cliente. Feito isso é mostrado o valor e é finalizada a hospeda-gem do cliente. Então o quarto usado é marcado como disponível novamente.

No item de consulta de quartos é feito mostrado o cálculo de consumo do quarto até o momento, servindo apenas de informativo.

Para o gerente, existem outros itens como o gerenciamento de Produtos, que cuida de quais itens estão disponíveis aos clientes do hotel adquirir. Também existe o controle de Funcionários e de departamentos. Todos os funcionários devem pertencer a algum departamento.

(8)

8 3.2 Diagramas SR

Mostra-se abaixo o diagrama SR (Strategic Rationale) que permite ana-lisar algumas tarefas de forma mais detalhada. Escolhemos o ator SGH para expansão.

(9)

9 Pela expansão do diagrama é possível notar que a grande parte das tarefas disponíveis é composta de várias outras. Por exemplo, a tarefa que seria efetuar check-in, depende de outras tarefas como buscar um quarto dis-ponível, buscar cliente e efetuar o check-in.

O atendente e o gerente terão acesso a alguns setores, que serão expli-cados a seguir.

(10)

10 cliente, a transferência para o software e a efetivação do cadastro. A edição de determinado cliente, depende primeiro de uma busca do cliente que terá seus dados alterados, da alteração dos valores no software e a efetivação das alte-rações. O mesmo ocorre para a exclusão de clientes: primeiro é feito uma bus-ca pelo cliente a ser deletado e depois do mesmo ser encontrado é efetuada a deleção.

Para se efetuar a atividade de Check-in, é necessário a priori de que o sistema tenha quartos cadastrados, juntamente com, pelo menos, um Cliente com seus dados armazenados. Será necessário buscar um quarto que esteja disponível, desde que este atenda as exigências do cliente. Além disso, não pode permitir que seja feito check-in em um quarto já reservado. Definida estas condições, o período de permanência, o cliente e o quarto, o check-in é efetua-do. Nisso consiste em marcar como o quarto ocupado e a contagem dos valo-res. Caso deseja fazer o check-in por uma reserva, apenas será necessário confirmar os dados de cliente, quarto e data e realizar o check-in.

Para o check-out, que seria a retirada do cliente do hotel, é feito primei-ramente a busca de qual quarto o cliente está. Após isso é analisado os itens que o cliente consumiu e calculado o valor total da diária. Com os valores, o atendente passa para o cliente o valor total e o mesmo faz o pagamento. De-pois de efetuado, o atendente irá encerrar o período e deixará o quarto marca-do como livre novamente.

Por querer fornecer mais conforto para o cliente, o sistema deverá ter como reservar um quarto por um determinado período. Para fazer isso, deverá ser feita uma busca com qual cliente será responsável pela reserva, buscar um quarto que esteja disponível naquele período desejado. Existindo estas condi-ções, é feito então a efetivação da reserva. Com isso o quarto ficará marcado como reservado naquele período e nenhuma outra reserva poderão ser feitos usando o mesmo quarto e o mesmo período.

Outra seção que deverá ter, será a consulta prévia do total gasto de um determinado quarto. Será feita a busca pelo quarto que está ocupado e será calculado o valor total baseado no custo da diária e nos itens consumidos pelo cliente.

(11)

con-11 sumo de um determinado quarto será chamada de “Consumação de Itens”. Tendo um quarto, que esteja ocupado, selecionado e com pelo menos um item cadastrado, poderá será feita a adição dos produtos consumidos para posteri-ormente ser adicionado ao custo da hospedagem.

A partir destes, somente o gerente terá acesso.

O cadastro de itens é composto por duas etapas: verificar se o produto já está cadastrado e efetuar o Cadastro. Não tendo o produto já cadastrado, será feita a efetivação do cadastro do mesmo. Para apagar um determinado item, será primeira feita uma busca por qual item que será apagado e depois é feita a efetivação da deleção.

Todo funcionário terá de ter algum tipo de cargo dentro da empresa, por isso o gerente terá a disponibilidade de fazer o controle total dos cargos. O ca-dastro de cargos é efetuado se e somente se o cargo não estiver cadastrado. A edição de um cargo será efetuada somente se o nome do cargo não for o mesmo de outro já cadastrado, tirando da lista de cadastrados o que será edi-tado.

Para ter uma melhor organização do hotel, ele é dividido entre departa-mentos. Tanto o cadastro quanto a edição do hotel, precisam apenas que o de-partamento que se deseja cadastrar ou alterar não esteja cadastrado no siste-ma (no caso da alteração, fora o departamento a ser editado será comparado). Para se realizar a exclusão, basta que seja feita a busca do departamento e efetue a exclusão.

Uma das partes principais é o controle dos funcionários do hotel. É um papel primordial para o controle da empresa. Para se realizar o cadastro de funcionários, basta ter os dados do mesmo em mãos para ser feito o cadastro. Caso ele já esteja cadastro, será impossível fazer a concretização da operação. Caso ele não exista, será necessário colocar o funcionário como integrante de um departamento e o cargo no qual ele ocupará. A edição de funcionário terá quase todos os mesmos requisitos do cadastro, menos o que ele já esteja ca-dastrado. A verificação se dará pelo CPF do sujeito, que deverá ser colocado corretamente no cadastro, pois na edição não será permitida a alteração. Para ser feita a exclusão, primeiro deverá se buscar qual funcionário será apagado e então efetivar a ação de excluir.

(12)

12

4. Requisitos Funcionais

Lista-se abaixo, de forma numerada, os requisitos do sistema, que des-crevem os serviços que o sistema deve oferecer e ações tomadas para de-terminadas entradas. Foram obtidos com base em um software indicado, ADMH, disponível gratuitamente na internet em sites como Baixaki.

[RF - 1] Cadastro de Usuários

Os usuários são utilizados para efetuar o login no sistema. O sistema de-ve permitir que sejam cadastrados usuários vinculados com funcionários. Cada funcionário deve ter apenas um usuário. Os dados necessários são o login e a senha utilizada. Possuem apenas dois níveis de acesso, que são gerente e atendente. Prioridade: Alta. Solicitante: Gerente.

[RF - 2] Listagem de Usuários

O sistema deve exibir na tela uma lista com todos os usuários cadastra-dos. Prioridade: Alta. Solicitante: Gerente.

[RF - 3] Editar senha de usuários

O sistema deve permitir que seja alterada apenas a senha dos usuários. Prioridade: Alta. Solicitante: Gerente.

[RF - 4] Apagar usuários

O sistema deve permitir que seja possível apagar usuários cadastrados. Prioridade: Alta. Solicitante: Gerente.

[RF - 5] Cadastro de Cliente

O sistema deverá exigir que seja feito o cadastro do cliente, com da-dos como nome, CPF, RG, Telefone residencial, Telefone celular e o endereço (Rua, Cidade, Estado, Número e CEP), antes que este consiga fazer uma re-serva, é feito uma busca para ver se o cliente já não esta cadastrado. Priorida-de: Alta. Solicitante: Atendente ou gerente.

(13)

13 [RF - 6] Alteração de Cliente

O sistema deve permitir que sejam feitas alterações em quaisquer da-dos da-dos clientes, com exceção do CPF. Prioridade: Média. Solicitante: Atenden-te ou gerenAtenden-te.

[RF - 7] Busca Cliente

O sistema deve permitir que possam ser feitas buscas por nome e por CPF e retornar uma lista de clientes ordenada pelo Nome. Prioridade: Média. Solicitante: Atendente ou gerente.

[RF - 8] Cadastro de Itens

O sistema permite que seja feito cadastro de novos itens que possam ser consumidos pelos clientes. Não há necessidade de controle de estoque. Apenas o nome e o valor unitário seriam os campos. Prioridade: Média. Solici-tante: Gerente.

[RF - 9] Apaga Itens

O sistema permite que seja feito a remoção de algum item. Prioridade: Baixa. Solicitante: Gerente.

[RF - 10] Cadastro de quartos

O sistema deve permitir que sejam ditos quantos quartos existem no hotel. O numero do quarto se dá pelo seu código. Prioridade: Baixa. Solicitante: Gerente.

[RF - 11] Check-In

O sistema deve permitir que possa ser feito o check-in do cliente que consiste em:

1. Escolher um quarto livre;

2. Escolher um cliente cadastrado; 3. Definir um período de permanência;

Seguindo estes passos, o próximo seria marcar o quarto como ocupado e não permitir que o quarto não fosse usado por outro cliente. Prioridade: Alta. Solici-tante: Atendente ou gerente.

(14)

14 [RF - 12] Check-Out

O sistema deve permitir que seja feito o check-out do cliente, no mo-mento em que ele concluir a estadia. As funções de buscar o(s) quarto(s) que o cliente reservou, busca despesas extras gastas (com lavanderia e cozinha, por exemplo) e somar tudo, calculando o total da despesa. Prioridade: Alta. Solici-tante: Atendente ou gerente.

[RF - 13] Fazer Reserva

O sistema deve suportar que possam ser feitas reservas de quartos para clientes que tem funções de verificar se cliente esta cadastrado, buscar um quarto para a data que foi solicitada pelo cliente. Prioridade: Alta. Solicitan-te: Atendente ou gerente.

[RF - 14] Cancelar Reserva

O sistema deve permitir que reservas possam ser canceladas com funções de buscar reserva e efetuar o cancelamento. Prioridade: Média. Solici-tante: Atendente ou gerente.

[RF - 15] Consultar dívidas de um quarto ocupado

O sistema deve permitir que possam ser feitas buscas pelas dívidas de um quarto, incluindo o custo da diária e gastos extras como itens consumi-dos. Prioridade: Média. Solicitante: Atendente ou gerente.

[RF – 16] Consultar quartos disponíveis

O sistema deve permitir que possam ser feitas consultas dos quartos livres(desocupados e sem reserva) em um determinado período de tempo. Prio-ridade: Média. Solicitante: Atendente ou gerente.

[RF – 17] Consultar quartos ocupados

O sistema deve permitir que possam ser feitas buscas pelos quartos que estão ocupados no dia da consulta. Prioridade: Baixa. Solicitante: Atenden-te ou gerenAtenden-te.

(15)

15 [RF - 18] Buscar de itens consumidos

O sistema deve permitir que possam ser feitas buscas dos itens já consumidos por um determinado quarto. Prioridade: Média. Solicitante: Aten-dente ou gerente.

[RF - 19] Cadastrar Departamento

O sistema permite que sejam criados novos departamentos. Os dados são nome e gerente(que é um funcionário e pode não ter). Prioridade: Média. Solicitante: Gerente.

[RF - 20] Buscar Departamento

O sistema deve permitir que sejam feitas buscas entre os departamen-tos cadastrados. Prioridade: Média. Solicitante: Gerente.

[RF - 21] Excluir Departamento

O sistema permite que departamentos sejam apagados, se não houver funcionários veinculados. Prioridade: Baixa. Solicitante: Gerente.

[RF - 22] Editar Departamento

O sistema deve permitir que sejam feitas alterações nos departamen-tos cadastrados. Prioridade: Baixa. Solicitante: Gerente.

[RF - 23] Cadastrar Funcionário

O sistema deve permitir que possa ser feito a inserção de novos funci-onários, garantindo que o mesmo já não esteja cadastrado. Os campos são os mesmos do cliente, incluindo o número da carteira de trabalho, data de admis-são, data de demisadmis-são, salário e cargo. Prioridade: Média. Solicitante: Gerente.

[RF - 24] Editar Funcionário

O sistema deve permitir que possam ser feitas alterações em todos os dados do funcionário, com excessão do CPF, caso necessário. Prioridade: Bai-xa. Solicitante: Gerente.

(16)

16 [RF - 25] Busca Funcionário

O sistema deve permitir que sejam feitas buscas usando o nome e CPF dos funcionários cadastrados. Prioridade: Baixa. Solicitante: Gerente.

5. Requisitos Não-Funcionais

O sistema a ser elaborado, embora seja de cunho acadêmico e de mé-dia complexidade, apresenta uma quantidade considerável de requisitos não funcionais para se obtiver o mínimo de qualidade requerida. Segue abaixo es-tes requisitos, que são definidos de três tipos: de processo, de produto e ex-ternos. É dado destaque para os requisitos de produto, que teve seu grafo SIG elaborado e comentado.

5.1 Requisitos de Processo

[RNF / PROC - 01] O sistema deve ter toda a sua documentação elaborada de acordo com o conteúdo aprendido na disciplina de PES II e a implementação deverá ser seguida por ela, com a ajuda do professor.

[RNF / PROC - 02] A modelagem do sistema deverá ser orientada a objetos. Utilizar java como linguagem padrão.

[RNF / PROC - 03] Devem-se utilizar metodologias ágeis no desenvolvimento do projeto, como vistos na disciplina.

5.2 Requisitos de Produto

Segurança

[RNF / SEG - 03] Os funcionários do hotel deverão utilizar login e senha para usar as funcionalidades do sistema. Com o cadastro do funcionário, será permi-tido que este possa ter acesso ao sistema, utilizando um nome de usuário único e uma senha.

[RNF / SEG - 04] Deverá ser utilizada criptografia para armazenamento da senha dos funcionários. Utilizará o método SHA1 de criptografia.

(17)

17

Desempenho

[RNF / PER - 06] Para ter velocidade na consulta dos dados armazenados deverá ser utilizado o banco de dados PostgreSQL, utilizando consultas otimi-zadas, como ensinadas na disciplina de banco de dados.

[RNF / PER - 07] O software deverá contar com as últimas versões lançadas, tanto do banco de dados PostgreSQL, quanto da máquina virtual Java (JVM).

Custo

[RNF / CUS - 08] Tratando-se de trabalho de cunho acadêmico, todos os recursos envolvidos para o desenvolvimento do software devem ser gratuitos.

Portabilidade

[RNF / CUS - 09] O sistema deve poder ser transferível entre máquinas de arquitetura x86 utilizando Windows ou Linux. Possível por utilizar a linguagem Java.

Usabilidade

[RNF / USA - 10] Devem ser apresentadas mensagens de erro quando usu-ário tentar entrar com dados inconsistentes, que será feita com validações dos campos.

[RNF / USA - 11] Para uma aparência agradável do sistema, serão utiliza-dos t o n s d e c o r e s m a i s a m e n a s , e p a d r o n i z a ç ã o d e t e l a s .

[RNF / USA - 12] Evitará o uso de muitos níveis de menu. Estipulando-se no máximo três níveis.

Evolucionabilidade

[RNF / USA - 13] O sistema utilizará arquitetura de software MVC. Onde os modelos de dados, a parte visual e parte lógica de funcionamento são

(18)

separa-18 das, tornando mais fácil qualquer incremento no software.

[RNF / USA - 14] A implementação do sistema deve ser orientada a objetos. Aplicando assim conceitos de reaproveitamento de código.

Abaixo segue o diagrama NFR:

O diagrama NFR explicita quais requisitos não funcionais são necessá-rios para o funcionamento do sistema.

6. Diagrama de Casos de Uso

O diagrama de Caso de Uso tem como objetivo descrever um cenário que mostra as funcionalidades do sistema no ponto de vista do usuário, nele chamados de ator. A seguir apresentaremos o diagrama de Casos de Uso no ponto de vista dos atores (Atendente e Gerente) e descreveremos todos os casos de uso de forma textual detalhada.

(19)

(20)

20 [Caso de Uso 01]: Listar usuários

Objetivo no Contexto: Listar os usuários cadastrados no sistema Pré-Condições: Usuário logado no sistema com permissão de gerente Condição Final de Sucesso: Lista todos os usuários.

Condição Final de Falha: Não foi possível realizar este objetivo. Ator Primário: Gerente

CENÁRIO PRINCIPAL (Primary Scenario):

1. O gerente solicita a listagem dos usuários

2. O sistema retorna a lista de usuários cadastrados

[Caso de Uso 02]: Cadastro de Usuários

Objetivo no Contexto: Cadastrar um usuário no sistema Pré-Condições: Gerente logado no sistema

Condição Final de Sucesso: Usuário cadastrado com sucesso Condição Final de Falha: Não foi possível cadastrar o usuário Ator Primário: Gerente

1. O gerente insere os dados de usuário e uma senha e busca um funcio-nário já cadastrado (Não obrigatório).

2. O sistema retorna uma mensagem informando o acontecido.

[Caso de Uso 03]: Edição de senha de Usuários

Objetivo no Contexto: Alterar a senha de um usuário no sistema Pré-Condições: Gerente logado no sistema

Condição Final de Sucesso: Senha alterada com sucesso

Condição Final de Falha: Não houve a possibilidade de alterar a senha Ator Primário: Gerente

CENÁRIO PRINCIPAL (Primary Scenario): 1. Lista os usuários <<include>>

2. O gerente escolhe o usuário a ter a senha trocada 3. O gerente informa duas vezes a nova senha do usuário 4. O sistema informa que a senha foi alterada, ou não.

(21)

21 [Caso de Uso 04]: Excluir Usuários

Objetivo no Contexto: Excluir o cadastro de um usuário do sistema Pré-Condições: Gerente logado no sistema

Condição Final de Sucesso: Usuário excluído com sucesso Condição Final de Falha: Não foi possível excluir o usuário Ator Primário: Gerente

CENÁRIO PRINCIPAL (Primary Scenario): 1. Lista os usuários<<include>>

2. O gerente solicita ao sistema a exclusão de um dos usuários cadastra-dos por vez.

[Caso de Uso 05]: Busca Cliente

Objetivo no Contexto: Busca um cliente já cadastrado no sistema Pré-Condições: Um usuário logado no sistema

Condição Final de Sucesso: Cliente localizado com sucesso Condição Final de Falha: Não existe o cliente buscado Ator Primário: Atendente

1. O atendente insere o nome ou o CPF do cliente no sistema.

2. O sistema retorna a existência ou não do cliente, junto com a possibilidade de editar os dados.

[Caso de Uso 06]: Cadastro Cliente

Objetivo no Contexto: Cadastrar um cliente Pré-Condições: Atendente logado no sistema

Condição Final de Sucesso: Cliente cadastrado com sucesso Condição Final de Falha: Não possível realizar o cadastro Ator Primário: Atendente

1. O atendente insere os dados cadastrais do cliente no sistema 2. O sistema retorna uma mensagem confirmando a ação

[Caso de Uso 07]: Edita Cliente

(22)

22 Pré-Condições: Atendente logado no sistema

Condição Final de Sucesso: Dados do cliente alterados com sucesso Condição Final de Falha: Não foi possível fazer as alterações

Ator Primário: Atendente

CENÁRIO PRINCIPAL (Primary Scenario): 1. Buscar Cliente<<include>>

2. O atendente solicita as alterações no cadastro do cliente 3. O sistema possibilita que o ator primário faça as alterações 4. O sistema retorna uma mensagem confirmando a ação

[Caso de Uso 08]: Cadastrar Itens

Objetivo no Contexto: Realiza o cadastro de um item no sistema Pré-Condições: Gerente logado no sistema

Condição Final de Sucesso: Item cadastrado com sucesso Condição Final de Falha: Não possível cadastrar o item Ator Primário: Gerente

1. O gerente insere os dados do item(Nome e preço unitário) a serem ca-dastrados

2. O sistema retorna uma mensagem confirmando a ação.

[Caso de Uso 09]: Apagar Itens

Objetivo no Contexto: apaga um item no sistema Pré-Condições: gerente logado no sistema

Condição Final de Sucesso: item removido com sucesso Condição Final de Falha: não possível remover o item Ator Primário: Gerente

CENÁRIO PRINCIPAL (Primary Scenario): 1. Buscar Item<<include>>

2. O gerente requisita ao sistema a deleção dos dados ali cadastrados 3. O sistema retorna uma mensagem confirmando a alteração

(23)

23 [Caso de Uso 10]: Inserir quartos

Objetivo no Contexto: Insere quartos no sistema Pré-Condições: Gerente logado no sistema

Condição Final de Sucesso: Quartos inseridos com sucesso Condição Final de Falha: Não foi possível inserir o quarto Ator Primário: Gerente

1. O gerente preenche quantos quartos serão adicionados ao sistema e qual o preço da diária cobrado.

2. O sistema retorna uma mensagem de confirmação.

[Caso de Uso 11]: Inserir consumo de itens

Objetivo no Contexto: Insere na conta do quarto os itens consumidos Pré-Condições: Atendente logado no sistema

Condição Final de Sucesso: Itens inseridos na conta

Condição Final de Falha: Não foi possível adicionar quartos Ator Primário: Atendente

CENÁRIO PRINCIPAL (Primary Scenario): 1. Busca Quarto <<include>>

2. Lista os itens cadastrados

3. O atendente insere a quantidade de um item na coluna de quantidades da lista dos itens

4. O sistema confirma as alterações no quarto

5. O sistema retorna uma mensagem confirmando a ação

[Caso de Uso 12]: Buscar Itens

Objetivo no Contexto: Buscar itens no sistema Pré-Condições: Atendente logado no sistema

Condição Final de Sucesso: Retornar uma lista dos possíveis itens utilizando filtro por nome.

Condição Final de Falha: Não foi encontrado nenhum item com o nome. Ator Primário: Atendente

(24)

24 2. O sistema retorna a lista

[Caso de Uso 13]: Consultar Quartos Ocupados

Objetivo no Contexto: Verifica quais os quartos ocupados no hotel Pré-Condições: Atendente logado no sistema

Condição Final de Sucesso: Gera uma lista de quartos que estão ocupados Condição Final de Falha: Todos os quartos estão livres

1. O atendente solicita ao sistema a listagem de quartos, com o nome dos clientes, que estão ocupados.

[Caso de Uso 14]: Consulta Quartos Livres

Objetivo no Contexto: Verificar quais os quartos livres no hotel Pré-Condições: Atendente logado no sistema

Condição Final de Sucesso: Gera uma lista de quartos que estão livres Condição Final de Falha: Todos os quartos estão ocupados.

1. O atendente solicita ao sistema a listagem de quartos que estão li-vres.

2.

[Caso de Uso 15]: Consultar dívidas de um Quarto

Objetivo no Contexto: Gerar relatório de dividas de um quarto Pré-Condições: Atendente logado no sistema

Condição Final de Sucesso: Exibe um relatório com as despesas especifica-das do quarto.

Condição Final de Falha: Não possível localizar quarto Ator Primário: Atendente

CENÁRIO PRINCIPAL (Primary Scenario): 1. O atendente insere o numero do quarto

2. O sistema calcula o valor das diárias do quarto

3. O sistema calcula o valor dos itens consumidos pelo quarto 4. O sistema gera um relatório com todos os gastos do quarto.

(25)

25 [Caso de Uso 16]: Fazer Reserva

Objetivo no Contexto: Realizar uma reserva de um quarto Pré-Condições: Atendente logado no sistema

Condição Final de Sucesso: O quarto é reservado num período

Condição Final de Falha: não existem quartos livres naquele período, reserva não possível de ser efetuada.

CENÁRIO PRINCIPAL (Primary Scenario): 1. O atendente busca o cliente <<include>>

2. O sistema gera uma lista de quartos livres no hotel <<include>> 3. O atendente seleciona um quarto que atenda ao pedido do cliente 4. O atendente insere a reserva

[Caso de Uso 17]: Cancelar Reserva

Objetivo no Contexto: Cancelar uma reserva, feita por um cliente em um de-terminado período.

Pré-Condições: Atendente logado no sistema

Condição Final de Sucesso: Reserva cancelada com sucesso Condição Final de Falha: Não existe a reserva

1. O atendente insere o nome do cliente para filtrar as reservas 2. O atendente marca a reserva a ser cancelada

[Caso de Uso 18]: Check-In

Objetivo no Contexto: Realizar o check-in de um cliente no hotel. Check-in é a operação que marca o quarto como ocupado e começa a partir do dia da entra-da a contabilizar a diária.

Pré-Condições: Atendente logado no sistema, Cliente cadastrado, Um quarto livre

(26)

26 Condição Final de Sucesso: check-in realizado com sucesso

Condição Final de Falha: não possível realizar check-in Ator Primário: Atendente

1. O cliente informa ao atendente verbalmente se possui reserva.

2. O atendente verifica se a reserva está cadastrada pelo nome do cliente e pelo período <<include>>

3. Se a reserva existir, é feito o check-in a partir dos dados da reserva. 4. Se não existir, busca-se o cliente <<include>>

5. Preenche-se o período de permanência

6. Busca um quarto livre filtrando pelo período <<include>> 7. Efetua o checkin

8. O sistema retorna uma mensagem de confirmação

[Caso de Uso 19]: Check-Out

Objetivo no Contexto: Realizar o check-out de um cliente. O check-out é fazer o cálculo das despesas e fazer a liberação do quarto.

Pré-Condições: Atendente logado no sistema

Condição Final de Sucesso: Check-out realizado com sucesso Condição Final de Falha: não possível realizar o check-out Ator Primário: Atendente

CENÁRIO PRINCIPAL (Primary Scenario): 1. O atendente insere o número do quarto

2. O Sistema faz o cálculo das despesas (diárias e itens consumidos) e exibe em tela.

3. O atendente informa ao cliente o preço e acertam a forma de paga-mento sem iteração com o sistema

4. O atendente efetiva o check-out(faz a liberação do quarto) e é impres-so o comprovante com os dados nome do cliente, quarto, período, itens consumidos e os valores..

[Caso de Uso 20]: Cadastrar um Departamento

Objetivo no Contexto: Cadastra um departamento no sistema Pré-Condições: Gerente logado no sistema

(27)

27 Condição Final de Sucesso: cadastro de departamento realizado com suces-so

Condição Final de Falha: não possível efetivar o cadastro Ator Primário: Gerente

1. O gerente insere os dados relativos ao cadastro do departamento (nome e, se tiver gerente) no sistema.

2. O sistema retorna uma mensagem confirmando a ação.

[Caso de Uso 21]: Buscar um Departamento

Objetivo no Contexto: Buscar cadastro de departamento no sistema Pré-Condições: Gerente logado no sistema

Condição Final de Sucesso: Retorna uma lista dos possíveis departamentos buscados.

Condição Final de Falha: Não foi encontrado departamentos. Ator Primário: Gerente

1. O gerente informa o nome do departamento ou do gerente para o sistema

2. O sistema retorna uma lista dos possíveis departamentos com as características inseridas.

[Caso de Uso 22]: Excluir um Departamento

Objetivo no Contexto: Excluir o cadastro de um departamento do sistema Pré-Condições: Gerente logado no sistema

Condição Final de Sucesso: Cadastro de departamento excluído com suces-so

Condição Final de Falha: Cadastro de departamento inexistente Ator Primário: Gerente

CENÁRIO PRINCIPAL (Primary Scenario): 1. Buscar um departamento <<include>>

(28)

28 [Caso de Uso 23]: Editar um Departamento

Objetivo no Contexto: Editar o cadastro de um departamento Pré-Condições: Gerente logado no sistema

Condição Final de Sucesso: Cadastro de departamento editado com sucesso Condição Final de Falha: Cadastro de departamento inexistente

Ator Primário: Gerente

CENÁRIO PRINCIPAL (Primary Scenario): 1. Buscar Departamento <<include>>

2. O gerente efetua as alterações necessárias no nome e/ou no gerente do departamento buscado

[Caso de Uso 24]: Cadastrar um Funcionário

Objetivo no Contexto: Realizar o cadastro de um funcionário no sistema Pré-Condições: gerente logado no sistema

Condição Final de Sucesso: cadastro realizado com sucesso

Condição Final de Falha: não possível realizar o cadastro do funcionário Ator Primário: Gerente

1. O gerente insere além dos mesmos dados pessoais do cliente, o núme-ro da carteira de trabalho, o salário, data de admissão e o cargo do funcionário no sistema,

3. Busca um departamento <<include>>

4. O Gerente confirma para o sistema a inserção de dados 5. O sistema retorna uma mensagem confirmando a ação

[Caso de Uso 25]: Buscar Funcionário

Objetivo no Contexto: Busca o cadastro de um funcionário do hotel Pré-Condições: Gerente logado no sistema

Condição Final de Sucesso: Encontrar o cadastro do funcionário buscado Condição Final de Falha: Não existe o funcionário buscado

(29)

29 1. O gerente informa o nome ou CPF ou número da carteira de trabalho

do funcionário para o sistema.

2. O sistema exibe em tela os possíveis funcionários buscados.

[Caso de Uso 26]: Excluir um Funcionário

Objetivo no Contexto: Excluir o cadastro de um funcionário no sistema Pré-Condições: Gerente logado no sistema

Condição Final de Sucesso: Funcionário excluído com sucesso Condição Final de Falha: Funcionário não pode ser excluído. Ator Primário: Gerente

CENÁRIO PRINCIPAL (Primary Scenario): 1. Busca Funcionário <<include>>

2. O gerente solicita ao sistema a exclusão do cadastro selecionado 3. O sistema retorna uma mensagem confirmando a ação;

[Caso de Uso 27]: Editar Funcionário

Objetivo no Contexto: Editar o cadastro de um funcionário Pré-Condições: gerente logado no sistema

Condição Final de Sucesso: Dados de funcionário editado com sucesso Condição Final de Falha: Funcionário inexistente

CENÁRIO PRINCIPAL (Primary Scenario): 1. Busca Funcionário <<include>>

2. O gerente efetua a alteração dos campos desejados do funcionário, com exceção do CPF.

(30)

30

7. Diagramas de Classe

O diagrama de classe é utilizado para mostrar a existência das clas-ses e as relações entre elas sob um ponto de vista lógico. Durante a etapa de análise, esses diagramas são utilizados para indicar os papéis e as res-ponsabilidades das entidades que fornecem o comportamento do sistema, e durante a etapa de desenvolvimento o diagrama de classe assume a função de capturar as estruturas das classes que compõe a arquitetura do sistema.

Logo abaixo é apresentado o diagrama de classes do sistema, e uma breve descrição de cada classe segue abaixo.

(31)

31 Departamento

Essa classe é responsável por conter os atribuitos dos departamentos. Ela possui três atributos, sendo um deles a chave, outro o nome e o terceiro sendo a referência para o funcionário que é Gerente desse departamento. Para o gerenciamento destes departamentos, existe a classe gerDepartamen-tos que contem uma lista dos DepartamengerDepartamen-tos cadastrados. Nesta classe possui os métodos de alteração, cadastro, remoção e busca dos departamentos. Item

Essa classe é responsável por guardar os dados necessários dos itens dispo-níveis para o consumo dos clientes. Nela contém alguns atributos: A chave, o nome do item, a quantidade em estoque e o valor de venda.

A classe responsável por fazer o controle de todos os itens é a gerItens, em que nela tem métodos específicos de controle.

Cliente

A classe cliente representa todos os dados do cliente, como nome, RG, CPF, telefone e endereços. Nesta classe ficam os métodos de gerenciamento destas informações e permitem que seja cadastrado mais de um endereço por cliente. A classe responsável por gerenciar todos os clientes é a gerCliente e nela con-tem os métodos principais.

Endereço

Esta classe é responsável por guardar os dados principais de endereço, tais como Rua, número, complemento, cidade e estado. Quem faz o controle, é a classe Funcionário e a classe Cliente.

Quarto

Nesta classe, é gerenciada os quartos do hotel. Nele teria a chave do banco de dados do quarto, o número, o valor da diária e o status dizendo se está ocupa-do, reservaocupa-do, entre outros. A classe principal de gerencia dos quartos, e que

(32)

32 faz a consulta em todos eles, é a gerQuartos. Nela contem todos os métodos das operações básicas de inclusão, exclusão, alteração e busca.

Reserva

Esta classe é responsável por guardar os dados das reservas dos clientes. Ne-la contem objetos do tipo reserva, o período em que foi reservado (a data de inicio e fim), qual o quarto escolhido e qual o cliente fez a reserva, juntamente com o funcionário que a fez. Quem faz o controle de todas as reservas é a classe gerReservas que tem todos os métodos necessários para fazer a inclu-são e as outras operações. Também todo check-in é efetuado criando uma no-va instancia de uma reserno-va, também o check-out que seria fazer o cálculo das despesas relacionada a essa reserva e liberar o quarto.

Foi abstraído do diagrama as classes da Visão, já que teriam muitos objetos e poucos métodos.

8. Metodologia

O desenvolvimento do sistema seguirá parcialmente a metodologia de desenvolvimento ágil Scrum. Decidimos por esta metodologia pelo fato do Scrum ser um processo de desenvolvimento de software voltado, para:

• Desenvolvimento de sistemas Orientados a Objetos; • Equipes pequenas;

• Iterações curtas para prover visibilidade ao desenvolvimento.

• Desenvolvimento iterativo ou incremental, onde o sistema começa a ser desenvolvido e ao longo do processo vai ganhando novas funcionalida-des aumentando seu valor para o cliente;

• Divisão do tempo de desenvolvimento em Sprint.

(33)

33 encorajando a comunicação de todos os membros da equipe, ajudando assim no desenvolvimento do projeto.

Outro grande fator responsável pela escolha do Scrum foi seu reconhe-cimento de que durante o projeto pode haver mudanças em relação o que é necessário para a implementação do sistema, e ate mesmo de suas funcionali-dades, sendo assim o Scrum permite a adoção de uma abordagem empírica, aceitando que o problema pode não ter sido totalmente entendido ou definido, sendo então focado perante a maximização da habilidade da equipe para a ob-tenção de respostas rápidas das necessidades emergentes.

9. Cronograma

Abaixo apresentamos o cronograma das atividades previstas para o de-senvolvimento do sistema utilizando a metodologia descrita anteriormente.

• A cada 15 dias será feita uma reunião para inicio de Sprint, onde serão apre-sentadas a partes do sistema a serem desenvolvidas;

• Na semana subsequente será realizado o que chamamos de Reunião de finalização de Sprint, onde serão apresentados as dificuldades encontradas e os avanços feitos.

• Uma Sprint somente será considerada finalizada, quando uma próxima Sprint se iniciar, ou seja, apenas na próxima reunião de inicio de Sprint será conside-rado o fim de uma Sprint anterior.

(34)

34 A elaboração do dado trabalho, demonstrou que o levantamento de re-quisitos e modelagem de um sistema utilizando as metodologias vistas em sala de aula, é uma tarefa essencial para o desenvolvimento da implementação do software. Além de demonstrar que estes modelos de desenvolvimento de sof-tware são ferramentas extremamente uteis, não apenas para agregar conheci-mento para a equipe de desenvolviconheci-mento, mas também para possibilitar aos integrantes do projeto ter uma visão do sistema como um todo e saber quais, e como, serão as pessoas afetas por ele.

(35)

35 Formulário do Relatório da Equipe

Descrição de papéis e contribuições de cada membro da equipe: Não houve uma divisão rígida do trabalho entre os membros da equipe. Optou-se pelo desenvolvimento gradual do projeto, em que todos participaram igualitariamente.

Nome % de esforço

Diego Henrique Pagani

33%

Julio Cesar Lazzarim

33%

Mauriverti da Silva Junior