PIM 3

Prévia do material em texto

7
20
UNIVERSIDADE PAULISTA – UNIP EAD
PIM III – Projeto Integrado Multidisciplinar
Curso Superior em TECNOLOGIA
Solução para a interligação e a comunicação de Hosts ativos 
de redes através de Link(s) de comunicação de dados.
Polo Piraju
2021
UNIVERSIDADE PAULISTA – UNIP EAD
PIM III – Projeto Integrado Multidisciplinar
Curso Superior em TECNOLOGIA
Solução para a interligação e a comunicação de Hosts ativos 
de redes através de Link(s) de comunicação de dados.
Nome: Mateus Henrique Bernabé
R.A:0566540
Analise e Desenvolvimento de Sistemas
2º Semestre
Polo Piraju
2021
Resumo
Esta obra caracteriza-se pela confecção de um manual capaz de dissertar sobre a criação de um Solução para a interligação e a comunicação de Hosts ativos de redes através de Link(s) de comunicação de dados.
Caros amigos, a constante divulgação das informações assume importantes posições no estabelecimento do investimento em reciclagem técnica. Todas estas questões, devidamente ponderadas, levantam dúvidas sobre se a complexidade dos estudos efetuados cumpre um papel essencial na formulação das condições inegavelmente apropriadas. Assim mesmo, a revolução dos costumes pode nos levar a considerar a reestruturação do sistema de participação geral.
 Evidentemente, a determinação clara de objetivos desafia a capacidade de equalização das posturas dos órgãos dirigentes com relação às suas atribuições. Do mesmo modo, a consulta aos diversos militantes nos obriga à análise das regras de conduta normativas. A prática cotidiana prova que a crescente influência da mídia causa impacto indireto na reavaliação dos relacionamentos verticais entre as hierarquias. Por outro lado, o aumento do diálogo entre os diferentes setores produtivos talvez venha a ressaltar a relatividade do sistema de formação de quadros que corresponde às necessidades.
 As experiências acumuladas demonstram que a mobilidade dos capitais internacionais obstaculiza a apreciação da importância de alternativas às soluções ortodoxas.
 Nunca é demais lembrar o peso e o significado destes problemas, uma vez que o surgimento do comércio virtual apresenta tendências no sentido de aprovar a manutenção do remanejamento dos quadros funcionais. O incentivo ao avanço tecnológico, assim como o início da atividade geral de formação de atitudes maximiza as possibilidades por conta das formas de ação. Não obstante, o julgamento imparcial das eventualidades exige a precisão e a definição dos níveis de motivação departamental. É claro que a expansão dos mercados mundiais prepara-nos para enfrentar situações atípicas decorrentes da gestão inovadora da qual fazemos parte.
 O empenho em analisar o fenômeno da Internet agrega valor ao estabelecimento das diretrizes de desenvolvimento para o futuro. Desta maneira, a hegemonia do ambiente político facilita a criação dos métodos utilizados na avaliação de resultados. Neste sentido, o consenso sobre a necessidade de qualificação representa uma abertura para a melhoria de todos os recursos funcionais envolvidos.
Palavras-chave: Sistema. Redes. Host. Servidor. Engenharia. 
Abstract
This work is characterized by the creation of a manual capable of dissertation on the creation of a Solution for the interconnection and communication of active hosts in networks through data communication Link(s).
Dear friends, the constant dissemination of information assumes important positions in establishing investment in technical recycling. All these questions, properly considered, raise doubts about whether the complexity of the studies carried out plays an essential role in formulating the undeniably appropriate conditions. Even so, the revolution in customs may lead us to consider restructuring the general participation system.
 Evidently, the clear determination of objectives challenges the ability to equalize the positions of the governing bodies in relation to their attributions. In the same way, consulting the various activists forces us to analyze the normative rules of conduct. Everyday practice proves that the growing influence of the media has an indirect impact on the reassessment of the vertical relationships between hierarchies. On the other hand, the increase in the dialogue between the different productive sectors may come to emphasize the relativity of the system for training cadres that corresponds to the needs.
 The accumulated experiences demonstrate that the mobility of international capital hinders the appreciation of the importance of alternatives to orthodox solutions.
 It is never too much to remember the weight and meaning of these problems, since the emergence of virtual commerce presents trends in the sense of approving the maintenance of the relocation of staff. The incentive to technological advancement, as well as the beginning of the general activity of formation of attitudes, maximizes the possibilities due to the forms of action. Nevertheless, the impartial judgment of eventualities requires precision and definition of departmental motivation levels. It is clear that the expansion of world markets prepares us to face atypical situations arising from the innovative management of which we are a part.
 The effort to analyze the Internet phenomenon adds value to the establishment of development guidelines for the future. In this way, the hegemony of the political environment facilitates the creation of methods used in the evaluation of results. In this sense, the consensus on the need for qualification represents an opening for the improvement of all the functional resources involved.
Keywords: System. Networks. Host. Server. Engineering.
SUMÁRIO
1.	Introdução	7
2.	Requisitos do Sistema	8
3.	Diagrama de Classes	10
4.	Requisitos Funcionais	12
4.1.	[RF01] Criar Usuário/Cliente	12
4.1.1.	[RF011] Cadastrar Funcionário	13
4.1.1.1.	[RF012]Incremento/Decremento Estoque.	13
4.2.	[RF02] Criar Estoque	13
4.3.	[RF03] Cancelar Venda	13
4.4.	[RF04] Pagamentos	14
4.5.	[RF05] Relatórios Produtos/Cliente – Sistema Financeiro	14
4.6.	[RF06] Reservar Produtos	14
4.7.	[RF07] Comprar Produto	14
4.7.1.1.	[RF10] Impressão de Recibos/ Contratos	14
4.8.	[RF08] Serviço de entrega	15
4.9.	[RF09] Seleção de Console	15
5.	Requisitos Não Funcionais	15
5.1.	Requisitos de Processo	15
6.	Requisitos de Externos	16
6.1.	[RNF04] - Tempo de Desenvolvimento	16
6.2.	[RNF05] - Custo de Desenvolvimento	16
7.	Requisitoos de Produto	16
7.1.	[RNF06] – Permissão	16
7.2.	[RNF07] - Backup	16
7.3.	[RNF08] - Mensagens de Retorno	17
7.4.	[RNF09] - Menus bem Estruturados	17
8.	Regras de Negócios Existentes	17
9.	Diagramas de Caso de Uso	18
9.1.	CSU01: Cadastrar Funcionário/Supervisor	18
9.2.	CSU02: Logar no Sistema	19
9.3.	CSU03: Criar Cliente no Sistema	19
9.4.	CSU04: Cadastrar Produto	20
9.5.	CSU05: Pesquisar Produto	21
9.6.	CSU06: Reservar Produto no Sistema	22
9.7.	CSU07: Cancelar Reserva de Produto no Sistema	22
9.8.	CSU08: Comprar Produto no Sistema	23
9.9.	CSU09: Entrega de Produtos no Sistema	24
9.9.1.1.	CSU010: Realizar pagamentos no Sistema	24
9.9.1.2.	CSU011: Verificar Status no Sistema	25
9.9.1.3.	CSU12: Imprimir Recibo de Pagamento no Sistema	26
10.	Conclusão	27
11.	Referências	27
1. Introdução
A 2SHOW.IE é uma agência de marketing digital que surgiu a partir da ideia de agregar, transformar, unir e criar conteúdo, por meio de mídias e plataformas digitais contemporâneas. O foco é propor soluções com base em ideias criativas que atendam às necessidades dos clientes, impulsione os negócios, permita a identificação e a aproximação dos clientes ao seu público. Os serviços prestados pela 2SHOW.IE estão alinhados às boas práticas de mercado quanto ao marketing digital, oferecendo um pacote completo de soluções digitais adequados a diversos segmentos, e tipos de negócios e porte da empresa. A proposta é fomentar o reconhecimento da marca, adequar e direcionar o tráfego para sites, portais e vitrines virtuais, qualificar, gerenciar e aumentar o quadro de leads qualificados.A 2SHOW.IE tem a capacidade para ajudar empresas a enfrentar os desafios que exigem soluções dinâmicas frente às adversidades do mercado. Para tanto, conta com especialistas em diversas áreas digitais, contemplando facilities em diversos serviços e oferecendo os resultados surpreendentes. Neste último trimestre, a partir de excelentes resultados, e do aumento da carteira de clientes e serviços, a 2SHOW.IE expandiu o seu escritório, por meio de um parceiro do segmento de publicidade, ampliando os seus serviços de mídia, gamificação, inbound marketing, redes sociais, performance digital, criação e desenvolvimento de web design, marketing de conteúdo, Search Engine Optimization (SEO), Pagamento Por Clique (PPC), entre outros.
O parque tecnológico da 2SHOW.IE contempla:
 
Escritório central: 
1 (um) servidor responsável por manter os serviços: DNS, arquivos dos usuários, serviço de diretórios (Microsoft Active Directory: AD), servidor de impressão, Microsoft Project Server e o antivírus: Kaspersky (end point); 
1 (um) servidor responsável por manter softwares e aplicativos de monitoramento de performance, rotinas e pesquisas através da internet; 
1 (um) servidor de páginas de internet rodando sob o Microsoft Internet Information Server (Microsoft IIS);
 35 (trinta e cinco) estações de trabalho (hosts) distribuídas entre desktops e notebooks; � 5 (cinco) impressoras multifuncionais em rede; 
1 (um) access point (AP). 
Sucursal: 
1 (um) servidor responsável por manter os serviços: arquivos dos usuários e servidor de impressão;
20 (vinte) estações de trabalho (hosts) distribuídas entre desktops e notebooks; 
3 (três) impressoras multifuncionais em rede; 
1 (um) access point (AP). No entanto, devido a expansão física e de serviços, faz-se necessário a interconexão de rede, de forma que os dispositivos ativos (hosts) localizados, fisicamente, no escritório central possam se comunicar com os seus pares na sucursal, a fim de compartilhar as informações e os serviços entre os colaboradores/usuários. 
2. Link de Comunicação
Como foi requisitado apresentamos uma solução para a interligação e a comunicação de dispositivos/hosts ativos de redes através de link(s) de comunicação de dados. Para que a central e a sucursal possam se comunicar:
Figura 1 - Diagrama de Comunicação
Fonte: Autor
Figura 2 - Diagrama de Comunicação Escritório Central
Fonte: Autor
Figura 3 - Diagrama de Comunicação Sucursal
Fonte: Autor
Figura 4 - Diagrama de Comunicação Cisco Packet Tracer
Fonte: Autor
3. Lista de Configuração de IP
Figura 1 – Escritório central
Fonte: Autor
Server 1
Server 2
Server 3
Impressora 1
Impressora 2
Impressora 3
Impressora 4
Impressora 5
Access Point
Estações de Trabalho
As estações subsequentes devem seguir padrão de configuração idêntica ao exemplo acima, alterando apenas o ultimo digito do IP para identificação da estação local, com numero idêntico.
Exemplo:
Estação número 2:
Estação número 3:
Assim por diante até atingir o número de estações desejadas, porém será limitada pelo número máximo de portas no “Switch”.
Figura 2 – Escritório central
Fonte: Autor
4. Requisitos Funcionais
Nesta seção são definidas as funções que o sistema deve realizar. Os requisitos funcionais estão agrupados de acordo com suas características. Por convenção, os requisitos são indicados e referenciados por um indicador no formato [RFxx], para os requisitos funcionais, e no formato [RNFxx], para os não funcionais, onde xx se refere ao número do requisito. Os requisitos também possuirão os nomes dos casos de uso relacionados. 
4.1. [RF01] Criar Usuário/Cliente 
Identificação: [RF01] Efetuar logon.
Descrição: Permite que um usuário tenha acesso a informações pertencentes ao software. Para isso, o usuário deve informar login e senha. Não deve haver outra maneira de entrar no sistema diferente desta. Deve haver código, RG, CPF, nome, data do cadastro, endereço, telefone, e email do cliente.
4.1.1. [RF011] Cadastrar Funcionário
Identificação: [RF011] Cadastrar Funcionário.
Descrição: Permite cadastrar um funcionário tenha acesso a informações pertencentes ao software. Para isso, o usuário deve informar login e senha. Não deve haver outra maneira de entrar no sistema diferente desta. Este poderá controlar os incrementos ou decrementos no estoque.
4.1.1.1. [RF012]Incremento/Decremento Estoque.
Identificação: [RF11] Alterar Estoque.
 		Descrição: O sistema deve permitir que seja alterado/incrementado/decrementado valores de produtos vendidos/comprados pela loja automaticamente ou manualmente pelos funcionários cadastrados. Recibos, contratos, cancelamentos de contratos, contratos pendentes e Notas Fiscais. Compra de Produtos e consequentemente alterações no estoque.
4.2. [RF02] Criar Estoque 
 
Identificação: [RF02] Manter Dados. 
Descrição: O administrador cadastra os dados da Loja “Geek”, inserindo cadastro do funcionário, cadastro do cliente e dos produtos. Os dados são armazenados no banco de dados do sistema. Os dados são removidos logicamente do sistema. Os dados dele devem permanecer no banco de dados do sistema até a exclusão dos clientes à qual ele pertence. Permite-se alterar um ou mais dados dos cadastros da loja que estiver armazenado no banco de dados do sistema. Lista os dados dos funcionários, clientes e produtos. Todos os produtos devem possuir: código de barras, nome do produto, categoria(categorizar os items por jogos, acessório e produtos “geek”), fabricante, quantidade e valor do produto. 
4.3. [RF03] Cancelar Venda 
Identificação: [RF03] Cancelar Venda.
Descrição: O sistema deve permitir cancelar as vendas ainda não concluídas no sistema, incrementar ou decrementar no estoque, permitir funcionario cadastrar ou remover produtos.
4.4. [RF04] Pagamentos 
 
Identificação: [RF04] Pagamentos.
Descrição: O sistema deve permitir realizar pagamentos à vista (em dinheiro, cheque ou cartão de crédito) e faturado para 30 dias.
4.5. [RF05] Relatórios Produtos/Cliente – Sistema Financeiro 
Identificação: [RF05] Relatórios Produtos/Cliente. 
Descrição: O sistema deve permitir que seja impresso relatórios apresentando listagem de clientes e de produtos, podendo ter uma visão dos clientes inadimplentes, em dias e quantidades já cadastrado no sistema. Dos produtos cadastrado no sistema e dos devolvidos.
4.6. [RF06] Reservar Produtos
 
Identificação: [RF06] Reservar Produtos.
Descrição: O sistema permite reservar produtos para clientes previamente cadastrados, podendo ter um controle de suas aquisições futuras, podendo se organizar. 
 
4.7. [RF07] Comprar Produto 
 
Identificação: [RF07] Comprar Produto.
Descrição: O sistema deve permitir comprar produtos a pessoa física, preenchendo todos os dados: nome, endereço, CPF, forma de pagamento, data inicio, data fim. Com isso finalizando a operação, com ou não reserva de compra já realizada. 
4.7.1.1. [RF10] Impressão de Recibos/ Contratos
Identificação: [RF10] Impressão de Recibos/ Contratos.
Descrição: O sistema deve permitir que seja impresso Recibos, contratos, cancelamentos de contratos, contratos pendentes e Notas Fiscais. Compra de Produtos e consequentemente alterações no estoque.
4.8. [RF08] Serviço de entrega
Identificação: [RF08] Serviço de entrega. 
Descrição: O sistema tem um serviço de entrega para melhor comodidade do cliente, utilizando dos correios, agência nacional.
4.9. [RF09] Seleção de Console
Identificação: [RF09] Selecione o Console. 
Descrição: O sistema tem o serviço escolhido pelo cliente na hora da entrega para confirmação do console desejado, verificar todo tipo de console disponivel para o jogo comprado pela loja.
5. Requisitos Não Funcionais 
Descreveremos a seguir, os requisitos não funcionais que envolvem restrições e aspectos de qualidade do sistema de controle de estoque, os requisitos não funcionais serão classificados em: requisitos de processo, requisitos externos e requisitosde produto. 
5.1. Requisitos de Processo 
Desenvolvimento em Java 
 		Identificação - [NFR02] - Desenvolvimento em Java. 
 		Descrição - O sistema deve ser desenvolvido utilizando a linguagem Java compatível com o servidor Apache Tomcat 7.0. 
Utilizar Banco de Dados MySql 
 		Identificação - [NFR03] - Utilizar Banco de Dados MySql. 
 		Descrição - A empresa dispõe de um serviço de banco de dados em MySql, contratado e não utilizado. Portanto, a aplicação deverá fazer desse serviço ocioso para persistência dos dados.
1. 
2. 
3. 
4. 
5. 
6. Requisitos de Externos
6.1. [RNF04] - Tempo de Desenvolvimento 
 
 		Identificação - [NRF04] - Tempo de Desenvolvimento. 
 		Descrição - O tempo para desenvolvimento do sistema não deve ultrapassar o prazo previsto no documento de viabilidade, visto a urgência da solução descrita no mesmo documento. Dessa forma, o tempo de desenvolvimento total não pode ser superior a três meses. 
6.2. [RNF05] - Custo de Desenvolvimento 
 
Identificação - [NRF05] - Custo de Desenvolvimento. 
 		Descrição - O custo de desenvolvimento não deve ultrapassar o valor estimado no documento de viabilidade. Então, para o trabalho de três meses temos que não se deve ultrapassar o valor de R$ 11.999. Para equipamentos de hardware, equipe de desenvolvimento e locação de servidores.
- Servidores R$ 5.999,00 
- Hardware R$ 2.000,00
- Equipe de desenvolvimento R$ 4.000,00
7. Requisitoos de Produto
 
7.1. [RNF06] – Permissão 
 
 		Identificação: [NRF06] – Permissão. 
 		Descrição: Cada usuário só poderá realizar ações que foram permitidas a ele na hora do seu cadastro.
7.2. [RNF07] - Backup 
 
 		Identificação: [NRF07] – Backup.
 		Descrição: O sistema deverá disparar Backups agendados a fim de aumentar a segurança em caso de perda de dados pela empresa contratada para o serviço de hospedagem do banco. 
7.3. [RNF08] - Mensagens de Retorno 
 		Identificação: [NRF08] – Mensagens de Retorno.
 		Descrição: O sistema deverá exibir uma mensagem na tela para toda ação do usuário, seja ela bem sucedida ou não, bem como uma descrição do motivo quando for necessário. 
7.4. [RNF09] - Menus bem Estruturados 
 
 		Identificação: [NRF09] – Menus bem Estruturados. 
 		Descrição: Os menus devem ser bem estruturados de modo a permitir uma navegação simples e intuitiva, proporcionando uma interface simples, melhorando a usabilidade. 
8. Regras de Negócios Existentes 
RN01 - Cadastrar e Autenticar Funcionário/Cliente 
Regra de negócio que informa ter funcionário cadastrado e autenticação de funcionário habilitada.
 
RN02 - Cadastrar Cliente 
Regra de negócio que informa que dever ter cliente cadastrado para poder comprar produto. Deve haver código, RG, CPF, nome, data do cadastro, endereço, telefone, e email do cliente.
RN03 - Comprar Produto
 		Regra de negócio que informa decrescimo de produto no estoque. 
	Todos os produtos devem possuir: código de barras, nome do produto, categoria(categorizar os items por jogos, acessório e produtos “geek”), fabricante, quantidade e valor do produto.
 
RN04 - Prazo de Entrega 
 		Regra de negócio que informa a estimativa do prazo da entrega.
RN05 - Console 
 		Regra de negócio que solicita confirmação de console.
 
RN06 - Localizar Produto
Regra de negócio trata de “Pesquisar Produto no sistema” por um funcionário/cliente da loja para ver sua disponibilidade .
 
RN07 - Imprimir Contratos e Recibos 
Regra de negócio trata de “Imprimir contratos e recibos direto no sistema” por um funcionário da loja.
RN08 - Cadastrar Produto 
Regra de negócio permite produto ser cadastrado no sistema por funcionário da loja. Permite também alterações para decremento.
RN09 - Reservar Produto/Cancelar Reserva 
Regra de negócio permite produto ser reservado no sistema por funcionário/cliente da loja. Permite também alterações para decremento/cancelamento de reserva.
RN10 - Concluir Venda 
Regra de negócio permite produto ser confirmado no sistema pelo pagamento da loja. Permite também confirmar pagamento por cartão de crédito ou à vista.
9. Diagramas de Caso de Uso 
9.1. CSU01: Cadastrar Funcionário/Supervisor 
Sumário: Caso de uso que trata de “Cadastrar funcionário no sistema”.
Atores: Funcionários, Sistema desenvolvido.
Pré-condição: Cadastrar funcionário, autenticar funcionário. 
Fluxo Principal 
1 O funcionário deve informar “Nome” 
2 O funcionário deve informar “CPF” 
3 O funcionário deve informar “RG” 
4 O funcionário deve salvar o cadastro 
5 O sistema irá apresentar Mensagem: “Funcionário cadastrado com sucesso” 
6 O caso de uso termina 
Fluxo Alternativo (3) 
1. Caso o funcionário informe “CPF” inválido o sistema deverá 
2. Retornar p/ o item (2) 
 		Regras de negócio "RN_01" 
Pós Condição Cadastro de funcionário realizado no sistema. 
9.2. CSU02: Logar no Sistema 
Sumário: Caso de uso que trata de “logar no sistema” por um funcionário da loja.
Atores: Funcionário, Cliente, Sistema desenvolvido. 
Pré-condição: Cadastrar funcionário, autenticar funcionário. 
Fluxo Principal 
1 O funcionário/cliente deve informar “Usuário” 
2 O funcionário/cliente deve informar “Senha” 
3 O funcionário/cliente deve clicar no “OK” 
4 O Sistema tem acesso liberado 
5 O caso de uso termina 
Fluxo Alternativo (3)
1. Caso o funcionário/cliente informe senha errada no sistema deverá 
2. Retornar p/ o item (2) 
Regras de negócio" RN_01 
Pós Condição 
Acesso de funcionário realizado no sistema 
9.3. CSU03: Criar Cliente no Sistema 
Sumário: Caso de uso que trata de “Criar Cliente no sistema” pela tela de login do site.
Atores: Funcionário, Cliente e Sistema desenvolvido. 
Pré-condição: Criar cliente, deve haver código, RG, CPF, nome, data do cadastro, endereço, telefone, e email do cliente.
 		Fluxo Principal 
1 O sistema deve informar “Codigo” 
2 O cliente deve informar “CPF” 
3 O cliente deve informar “RG” 
4 O cliente deve informar “Nome” 
5 O cliente deve informar “Endereço” 
6 O cliente deve informar “Telefone” 
7 O cliente deve informar “Data” 
8 O cliente deve informar “Email” 
9 O cliente deve salvar o cadastro 
10 O sistema irá apresentar Mensagem: “Cadastro do cliente realizado com sucesso” 
11 O caso de uso termina 
Fluxo Alternativo (1) 
1. Caso o funcionário informe “CPF” no sistema deverá 
2. Retornar p/ o item (2) 
Regras de negócio "RN_02” 
Pós Condição 
Cadastro de cliente realizado no sistema. 
9.4. CSU04: Cadastrar Produto
Sumário: Caso de uso que trata de “Cadastrar Produto no sistema” por um funcionário da loja.
Atores: Supervisor, Sistema desenvolvido. 
Pré-condição: Autenticar supervisor, cadastrar veículos no sistema. 
O atendente poderá excluir produtos da venda caso o cliente não queira mais adquiri-los. Apenas o supervisor da loja poderá excluir o produto da venda, devendo informar um usuário e senha válidos; 
Comprar Produto, Todos os produtos devem possuir: código de barras, nome do produto, categoria(categorizar os items por jogos, acessório e produtos “geek”), fabricante, quantidade e valor do produto.
Fluxo Principal 
1 O sistema deve informar “Código” 
2 O supervisor deve informar “Código de Barras” 
3 O supervisor deve informar “Nome do Produto” 
4 O supervisor deve informar “Categoria; Jogo, Acessório ou Produto Geek” 
5 O supervisor deve informar “Fabricante” 
6 O supervisor deve informar “Quantidade” 
7 O supervisor deve informar “Valor do Produto” 
8 O supervisor deve informar “Observação” 
9 O supervisor deve salvar o cadastro 
10 O sistema irá apresentar Mensagem: “Produto cadastrado com sucesso” 
11 O caso de uso termina 
Fluxo Alternativo (1) 
1. Caso o supervisor informe “Código de Barras” errado no sistema deverá 
2. Retornar p/ o item (2) 
 		Regras de negócio "RN_08”, “Rn_09” 
Pós Condição 
Cadastro do veículo realizado no sistema 
 
1. 
2. 
3. 
4. 
5. 
6. 
7. 
8. 
9. 
9.1. 
9.2. 
9.3. 
9.4. 
9.5. CSU05: Pesquisar Produto
 
Sumário: Caso de uso que trata de “Pesquisar Produto” por um funcionário/cliente da loja para ver sua disponibilidade. 
Atores: Funcionário, Cliente e Sistema desenvolvido.Pré-condição: Autenticar funcionário/cliente, cadastrar cliente e cadastrar produto no sistema. 
Fluxo Principal 
1 O funcionário/cliente deve informar “Código de barras” 
2 O Sistema deve mostrar a pesquisa 
3 O caso de uso termina 
Fluxo Alternativo (1) 
1. Caso o funcionário informe “Código de barras” errado no sistema deverá 
2. Retornar p/ o item (1) 
3. Caso o funcionário informe “Código de barras” que já esteja esgotado deverá 
4. Retornar p/ o item (1)
Regras de negócio "RN_06 
Pós Condição 
Pesquisar produto realizado no sistema
9.6. CSU06: Reservar Produto no Sistema 
Sumário: Caso de uso que trata de “Reservar Produto no Sistema” por um funcionário no sistema. 
Atores: Funcionário, Cliente e Sistema desenvolvido.
Pré-condição: Autenticar funcionário/cliente, cadastrar cliente e cadastrar produto no sistema. 
 		Fluxo Principal 
1 O funcionário/cliente deve informar “Código” 
2 O funcionário/cliente deve informar “Código de barras” 
3 O funcionário/cliente deve informar “Cliente” 
4 O funcionário/cliente deve informar “Data Inicio” 
5 O funcionário/cliente deve informar “Data Fim” 
6 O funcionário deve concluir a reserva 
7 O sistema irá apresentar Mensagem: “ Reserva realizada com sucesso” 
8 O Caso de uso termina 
Fluxo Alternativo (1) 
1. Caso o funcionário informe “Código de barras” e já tenha reserva pra essa data o sistema deverá 
2. Retornar p/ o item (1) pra ser informado um novo nrºchassi 
Regras de negócio "RN_09“ 
Pós Condição 
Reserva de produto realizado no sistema 
9.7. CSU07: Cancelar Reserva de Produto no Sistema 
Sumário: Caso de uso que trata de “Cancelar Reserva de Produto” por funcionário/cliente no sistema. 
Atores: Funcionário, Cliente e Sistema desenvolvido. 
Pré-condição: Autenticar funcionário/cliente, cadastrar cliente e cadastrar produto no sistema 	
Fluxo Principal
1 O funcionário/cliente deve informar “Código” 
2 O funcionário/cliente deve informar “Código de barras” 
3 O funcionário/cliente deve informar “Cliente” 
4 O funcionário/cliente deve informar “Observação” do cancelamento 
5 O funcionário/cliente deve concluir o cancelamento da reserva 
6 O sistema irá verificar a data
7 O sistema irá apresentar Mensagem : “Verificando Cancelamento” 
8 O Caso de uso termina 
Fluxo Alternativo (1) 
1. Caso a data que o sistema informe seja antes da data atual e que não tenha reserva a ser cancelada sistema deverá 
2. O sistema irá apresentar Mensagem : “Cancelamento impossível, pedido enviado.”
3. Retornar p/ o item (1) pra ser informado um novo “Código” 
Regras de negócio "RN_09”
Pós Condição 
Reserva de veículo cancelada no sistema
9.8. CSU08: Comprar Produto no Sistema 
Sumário: Caso de uso que trata de “Comprar Produto” por cliente/funcionario no sistema.
Atores: Funcionário, Cliente, Sistema desenvolvido. 
Pré-condição: Autenticar funcionário/cliente, cadastrar cliente, cadastrar produto, ter impressora configurada ao sistema. A venda deverá possuir os dados do cliente e todos os produtos adquiridos. Deverá ser gerado um código único da venda, com a data da venda, o valor da venda, opções para pagamento (dinheiro/cartão), o status de pagamento e o status da venda; 
Fluxo Principal 
1 O sistema deve informar “Código” 
2 O cliente/funcionário deve informar “Produto” 
3 O cliente/funcionário deve informar “Quantidade” 
4 O cliente/funcionário deve informar “Data Inicio” 
5 O cliente/funcionário deve informar “Data Fim” 
6 O cliente/funcionário deve informar “Categoria” da produto 
7 O cliente/funcionário deve informar “Forma de Pagamento” 
8 O cliente/funcionário deve informar “Console” caso seja da “categoria “,”Jogo” 
9 O sistema irá apresentar Mensagem: “Compra Sendo Avaliada” 
10 O Caso de uso termina 
Fluxo Alternativo (1) 
1. Caso o funcionário informe “Código de barras” que não tenha estoque venha a ser cancelada sistema deverá 
2. Retornar p/ o item (1) pra ser informado um novo “Produto” 
Fluxo Exceção – Violação da RN04 
Regra de negócio que informa o prazo da entrega deverá ser de acordo com contrato firmado 
Fluxo Exceção – Violação da RN05 
Regra de negócio que informa restrição por categoria jogo, informe “Selecione o Console”
Regras de negócio "RN_03”, "RN_04“, "RN_05“ e "RN_07”
Pós Condição 
Confirmar Compra por email.
9.9. CSU09: Entrega de Produtos no Sistema 
 
Sumário: Caso de uso que trata de “Serviço de Entrega de Produto” pelos correios, postado pela loja.
Atores: Funcionário, Sistema desenvolvido. 
Pré-condição: Autenticar funcionário/cliente, cadastrar produto, concluir entrega de produto no sistema. 
 		Fluxo Principal 
1 O sistema deve informar “Cliente” 
2 O sistema deve conferir o “Código de barras”, “Cliente” e “Quantidade”
3 O sistema deve informar “Endereço de Entrega”
4 O sistema deve finalizar ordem de serviço impressa 
5 O sistema deve apresentar mensagem: “Ordem de serviço finalizada com sucesso”
6 O sistema deve enviar a ordem de serviço ao funcionário responsável pela postagem nos correios 
6. 
7. 
8. 
9. 
9.1. 
9.2. 
9.3. 
9.4. 
9.5. 
9.6. 
9.7. 
9.8. 
9.9. 
9.9.1. 
9.9.1.1. CSU010: Realizar pagamentos no Sistema 
 
Sumário: Caso de uso que trata de “Realizar Pagamento” por funcionário no sistema
Atores: Funcionário, Cliente, Sistema desenvolvido 
Pré-condição: A venda pode ser cancelada apenas pelo supervisor da loja, que deve informar usuário e senha válidos. No momento do cancelamento, o código da venda deve ser enviado para o sistema financeiro.
 		Fluxo Principal 
1 O sistema deve informar “Cliente” 
2 O sistema deve conferir o “Valor” 
3 O sistema deve informar “Forma de Pagamento” 
4 O sistema deve finalizar o pagamento no sistema 
5 O sistema dever apresentar mensagem: “Pagamento finalizado com sucesso” 
6 O Caso de uso termina 
Fluxo Alternativo (1) 
1. Caso o funcionário não informe o “valor” ou valor incorreto, irá apresentar mensagem informando que não foi concluído, pois não foi informado o valor do pagamento no sistema é preciso retornar para o item (2) 
Regras de negócio "RN_10“ 
Pós Condição 
Pagamento realizado com sucesso no sistema
9.9.1.2. CSU011: Verificar Status no Sistema
Sumário: Caso de uso que trata de “Realizar Pagamento” por funcionário no sistema 
 	Atores: Funcionário, Cliente, Sistema desenvolvido 
Pré-condição: Deverá ser gerado um código único da venda, com a data da venda, o valor da venda, opções para pagamento (dinheiro/cartão), o status de pagamento e o status da venda; 
 		Fluxo Principal 
1 O usuário deve informar “Código” 
2 O sistema deve conferir o “Código” 
3 O sistema deve informar “Status de Pagamento” 
4 O sistema deve informar o pagamento no sistema 
5 O sistema dever apresentar mensagem: “Satatus do Pagamento” 
6 O Caso de uso termina 
Fluxo Alternativo (1) 
1. Caso o funcionário não informe o “Código” incorreto, irá apresentar mensagem informando que não foi concluído, pois não foi informado um código existente no sistema, é preciso retornar para o item (2) 
Regras de negócio "RN_10“ 
Pós Condição 
Pagamento realizado com sucesso no sistema
9.9.1.3. CSU12: Imprimir Recibo de Pagamento no Sistema 
Sumário: Caso de uso que trata de “Imprimir Recibo de Pagamento” no Sistema pelo sistema. 
Atores: Funcionário, Cliente, Sistema desenvolvido e impressora. 
Pré-condição: Autenticar funcionário/cliente, cadastrar cliente, cadastrar produto e ter impressora configurada ao sistema. 
Fluxo Principal 
1 O sistema deve informar “Código” 
2 O sistema deve informar “Código de Barras” 
3 O sistema deve informar “Valor”
4 O sistema deve informar “Forma de Pagamento” 
5 O sistema deve informar “Observação” 
6 O sistema deve concluir o recibo 
7 O sistema irá enviar para impressora 
8 O sistema irá apresentar mensagem: “Impressão realizada com sucesso” 
9 O Caso de uso termina
Fluxo Alternativo (1) 
1. Caso o funcionário clique no concluir recibo, e a impressora não esteja configurada com o 
sistema deverá 
2. Retornar p/ o item (7) pra ser informado um novo “Código” 
Regras de negócio "RN_07” 
Pós Condição 
Recibo impresso com sucessono sistema em PDF, enviar por email cadastrado usuário funcionário/cliente.
10. Conclusão
Através do documento de requisitos, foi possível entender, através de uma breve descrição, o problema a ser resolvido com a analise de requisitos para desenvolver o sistema de controle de estoque. Em seguida foram apresentados todos os requisitos funcionais do sistema, isto é, todos os serviços que o controle de estoque deve oferecer aos seus usuários, segundo a definição do cliente. Depois disso apresentamos os requisitos funcionais e os requisitos não funcionais, que irão definir restrições de como o sistema irá funcionar baseado em seus requisitos funcionais.
O Diagrama de Caso de Uso e seus detalhamentos deram uma visão geral do funcionamento do Software bem como os atores que estão relacionados a cada funcionalidade do Sistema e por o Digrama de Classe nos dá uma visão geral sobre o software que será desenvolvido. 
11. Referências 
 VASCONCELLOS, Marco Antonio Sandoval de. Economia: micro e macro. São Paulo: Saraiva, 2016.
 (VALENTE, T. Marco; Engenharia de Software Moderno. E-book 3.4.1 ind.).
 PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e padrões. 3. ed. Rio de Janeiro: LTC, 2012.
 BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 2 ed. Rio de Janeiro: Campus , 2006.
 Paula Filho, W, P. Engenharia de software - fundamentos, métodos e padrões. 3. ed. Rio de 
Janeiro: LTC, 2009. 
 Rezende, Denis Alcide. Engenharia de Software e Sistemas de Informação. 3, Ed. Revisada e 
Ampliada – Rio de Janeiro: Brasport, 2005. 
 Wazlawick, Sidnei Raul. Análise e Projeto de Sistemas de Informação Orientados a Ob jetos – 
2 Ed. Revisada e Atualizada – Rio de Janeiro: Elsevier, 2011. 
 Pezzé, M.; Young, M. Teste e Análise de Software: Processos, Princípios e Técnicas. Porto 
Alegre: Bookman, 2008. 
 Pressman, R. S. Engenharia de software. 6. Ed. São Paulo: McGraw-Hill, 2006. 
 Sommerville, I. Engenharia de software. 8. Ed. São Paulo: Pearson, 2007. 
Bruno Gonzales RUIZ PIM VII Polo Santo André. 
 Sites utilizados 
 
 Associação Brasileira de Locadoras de Automóveis, Disponível em: 
<http://www.abla.com.br/beneficios-aos-associados> Acesso em 17 de setembro de 2015. 
 The History of Car Rental <http://www.articlesbase.com/travel-articles/the-history-of-car-rental-
576034.html> Acesso em 12 de Setembro de 2015. 
 Tudo Sobre o Aluguel de Carros, Disponível em: <http://www.carroaluguel.com/blog/tudo-sobre-
o-aluguel-de-carros> Acesso em 7 de Setembro de 2015. 
 Locadora de Veículos Localiza, Disponível em: <https://www.localiza.com/brasil/pt-br> Acesso 
em 20 de Setembro de 2015. 
 Locadora Auto Car, Disponível em: <http://www.autocarlocadora.com.br> Acesso em 23 de 
Setembro de 2015.
 devimedia.com.br/principais-conceitos-da-programacao-orientada-a-objetos/33285