Processo de Engenharia de Software II

Transcrição

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 Cascavel - PR Abril

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 Cascavel - PR - Abril

3 Sumário 1. Motivação Sistema Proposto Requisitos Funcionais Modelagem Organizacional Diagramas SD Diagramas SR Requisitos Não-Funcionais Requisitos de Processo Requisitos de Produto Diagrama de Casos de Uso Diagramas de Classe Metodologia Cronograma Conclusão

4 1. Motivação Na necessidade de desenvolver um sistema para o complemento do conhecimento de duas disciplinas essenciais, Banco de Dados e Processo de Engenharia de Software, foi escolhido por desenvolver um sistema que seja responsá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 atualmente são destaque de mercado: Linguagem Java utilizando JDBC para conexã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 durante 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íodo. o Funcionários: o Cadastro, edição, busca e exclusão. o O controle de funcionários não envolve o pagamento de salários, ape- 4

5 nas o controle de quem realmente trabalha no hotel e o salário do indivíduo. Cargos: o Cadastro, edição, busca e exclusão. o São os cargos dos funcionários do hotel, tal como atendente, cozinheiro, entre outros. Departamentos: o Cadastro, edição, busca e exclusão. 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 Cadastro, edição, busca e exclusão. 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: 5

6 Esse diagrama é composto por cinco atores: Funcionário, Atendente, Camareira, 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 alguns 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 geren- 6

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, visualização e deleção dos dados pessoais de cada cliente que possa a vir se hospedar no hotel. Não há dependências que possam ocorrer, apenas que o atendente tenha feito o login no sistema previamente. Em Reservas, cabe ao atendente ouvir o pedido do cliente e verificar a disponibilidade 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 hospedagem 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. 7

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

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 disponível, buscar cliente e efetuar o check-in. O atendente e o gerente terão acesso a alguns setores, que serão explicados a seguir. O cadastro de cliente é composto do recebimento dos dados pessoais do 9

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 alterações. O mesmo ocorre para a exclusão de clientes: primeiro é feito uma busca 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 é efetuado. Nisso consiste em marcar como o quarto ocupado e a contagem dos valores. 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 primeiramente 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. Depois de efetuado, o atendente irá encerrar o período e deixará o quarto marcado 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. A parte do sistema que será responsável por adicionar produtos no con- 10

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 posteriormente 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 cadastro 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á editado. Para ter uma melhor organização do hotel, ele é dividido entre departamentos. Tanto o cadastro quanto a edição do hotel, precisam apenas que o departamento que se deseja cadastrar ou alterar não esteja cadastrado no sistema (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 cadastrado. 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. 11

12 4. Requisitos Funcionais Lista-se abaixo, de forma numerada, os requisitos do sistema, que descrevem os serviços que o sistema deve oferecer e ações tomadas para determinadas 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 deve 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 cadastrados. 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 dados 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 reserva, é feito uma busca para ver se o cliente já não esta cadastrado. Prioridade: Alta. Solicitante: Atendente ou gerente. 12

13 [RF - 6] Alteração de Cliente O sistema deve permitir que sejam feitas alterações em quaisquer dados dos clientes, com exceção do CPF. Prioridade: Média. Solicitante: Atendente ou gerente. [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. Solicitante: 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. Solicitante: Atendente ou gerente. 13

14 [RF - 12] Check-Out O sistema deve permitir que seja feito o check-out do cliente, no momento 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. Solicitante: 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. Solicitante: 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. Solicitante: 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 consumidos. 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. Prioridade: 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: Atendente ou gerente. 14

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: Atendente 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 departamentos 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 departamentos cadastrados. Prioridade: Baixa. Solicitante: Gerente. [RF - 23] Cadastrar Funcionário O sistema deve permitir que possa ser feito a inserção de novos funcioná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 admissão, data de demissã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: Baixa. Solicitante: Gerente. 15

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 estes requisitos, que são definidos de três tipos: de processo, de produto e externos. É 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á permitido 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. 16

17 Desempenho [RNF / PER - 06] Para ter velocidade na consulta dos dados armazenados deverá ser utilizado o banco de dados PostgreSQL, utilizando consultas otimizadas, 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 utilizados tons de cores mais am enas, e padronização de tela 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 separa- 17

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. 18

19 19

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 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 funcioná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 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. 20

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 1. Lista os usuários<<include>> 2. O gerente solicita ao sistema a exclusão de um dos usuários cadastrados 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 Objetivo no Contexto: Editar o cadastro de um cliente 21

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 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 cadastrados 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 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 22

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 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 1. O atendente insere o nome do item a ser pesquisado no sistema 23

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 Ator Primário: Atendente 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. Ator Primário: Atendente 1. O atendente solicita ao sistema a listagem de quartos que estão livres. 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 especificadas do quarto. Condição Final de Falha: Não possível localizar quarto Ator Primário: Atendente 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. 24

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. Ator Primário: Atendente 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 5. O sistema retorna uma mensagem confirmando a ação [Caso de Uso 17]: Cancelar Reserva Objetivo no Contexto: Cancelar uma reserva, feita por um cliente em um determinado 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 Ator Primário: Atendente 1. O atendente insere o nome do cliente para filtrar as reservas 2. O atendente marca a reserva a ser cancelada 3. O sistema retorna uma mensagem confirmando a ação [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 entrada a contabilizar a diária. Pré-Condições: Atendente logado no sistema, Cliente cadastrado, Um quarto livre 25

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 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 pagamento sem iteração com o sistema 4. O atendente efetiva o check-out(faz a liberação do quarto) e é impresso 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 26

27 Condição Final de Sucesso: cadastro de departamento realizado com sucesso 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 sucesso Condição Final de Falha: Cadastro de departamento inexistente Ator Primário: Gerente 1. Buscar um departamento <<include>> 2. O gerente solicita a exclusão dos dados ali cadastrados 27

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 1. Buscar Departamento <<include>> 2. O gerente efetua as alterações necessárias no nome e/ou no gerente do departamento buscado 3. O sistema retorna uma mensagem confirmando a ação [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úmero 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 Ator Primário: Gerente 28

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 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 Ator Primário: Gerente 1. Busca Funcionário <<include>> 2. O gerente efetua a alteração dos campos desejados do funcionário, com exceção do CPF. 3. O sistema retorna uma mensagem confirmando a ação 29

30 7. Diagramas de Classe O diagrama de classe é utilizado para mostrar a existência das classes 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 responsabilidades 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. 30

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 gerdepartamentos que contem uma lista dos Departamentos 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 disponí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 contem 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á ocupado, reservado, entre outros. A classe principal de gerencia dos quartos, e que 31

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. Nela 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 inclusão e as outras operações. Também todo check-in é efetuado criando uma nova instancia de uma reserva, 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 funcionalidades aumentando seu valor para o cliente; Divisão do tempo de desenvolvimento em Sprint. O Scrum permite um fator de auto-organização na criação da equipe, 32

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 reconhecimento 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 funcionalidades, 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 obtenção de respostas rápidas das necessidades emergentes. 9. Cronograma Abaixo apresentamos o cronograma das atividades previstas para o desenvolvimento do sistema utilizando a metodologia descrita anteriormente. A cada 15 dias será feita uma reunião para inicio de Sprint, onde serão apresentadas 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á considerado o fim de uma Sprint anterior. 10. Conclusão 33

34 A elaboração do dado trabalho, demonstrou que o levantamento de requisitos 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 software são ferramentas extremamente uteis, não apenas para agregar conhecimento para a equipe de desenvolvimento, 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. 34

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 33% Diego Henrique Pagani 33% Julio Cesar Lazzarim 33% Mauriverti da Silva Junior 35