CENTRO PAULA SOUZAFACULDADE DE TECNOLOGIA DE TATUCURSO SUPERIOR EM TECNOLOGIA EM GESTO DE TECNOLOGIA DA INFORMAO

ALEXANDRO DA ROSA PONTESALISON FERNANDO WINCLERBRUNO RODRIGO PADILHAFELIPE PEDRO DA SILVA MARQUESJONATHAN GROPO LOPES

LEVANTAMENTO DE REQUISITOS DE UM SISTEMA PARA GERENCIAMENTO E CONTROLE DE ESTOQUE

Tatu SP2014ALEXANDRO DA ROSA PONTESALISON FERNANDO WINCLERBRUNO RODRIGO PADILHAFELIPE PEDRO DA SILVA MARQUESJONATHAN GROPO LOPES

Levantamento de Requisitos para a Implantao de um Sistema para Gerenciamento e Controle de Estoque sob a orientao do Prof. Samuel Vieira, para a obteno de nota na matria Banco de Dados, no Curso de Gesto em Tecnologia da Informao.

Tatu SP2014SUMRIO

1INTRODUO41.1SUPOSTO PROBLEMA42Documento de requisitos51.2VISO GERAL DO SISTEMA51.2.1REQUISITOS FUNCIONAIS51.2.2Lanamentos diversos61.2.3Impresso de diversos tipos de relatrios e consultas61.3.1Confiabilidade61.3.2Eficincia63VISO DE CASO DE USO NVEL ANLISE73.3Modelo de caso de uso84DESCRIO DE CASOS DE USO95Modelo de SEQUNCIA116VISO LGICA NVEL ANLISE136.1MODELOS DE CLASSESDO SISTEMA ESTOQUE147DIAGRAMA DE CLASSES DO PROJETO158MODELO DE ENTIDADE RELACIONAMENTO169Diagrama Entidade Relacionamento1710TELAS DO SISTEMA1811PL/SQL Funes2112referncias bibliogrficas25

INTRODUO

Busca por conhecimento da equipe, no desenvolvimento do aprendizado do uso da engenharia de software para o desenvolvimento de sistemas em geral, atender o cliente que necessita de um sistema organizacional para controle do caixa, e cadastro dos dados dos produtos, e consulta do estoque produzindo um sistema de qualidade que gerencie as tarefas de uma papelaria, e possa trazer uma maior interao com o cliente.O objetivo diminuir o tempo gasto nos arquivamentos dos dados dos produtos, manuteno e controle do estoque, efetuar pedidos de clientes com agilidade. Com este sistema poder resultar na economia de tempo e esforo, gerando tambm mais segurana e restrio aos dados e agilidade no atendimento ao cliente. Definimos produto de venda, todo e qualquer produto do estoque da empresa, como canetas, lpis, cadernos, etc.

SUPOSTO PROBLEMA

A empresa ainda no possui qualquer tipo de sistema para o controle. Por esse motivo h uma grade perda de tempo esse controle, alm de que esse controle como esta sendo feito em arquivos de papel mesmo, ocorre frequentemente perda de informao ou at erro humano na hora de passar a informao para o papel, gerando assim transtornos. O controle de compras com o fornecedor feito apenas guardando as notas de compra em um arquivo fsico, o que gera o mesmo problema anterior de extravios.O Sistema proposto iria resolver essas situaes para o proprietrio, agilizando e organizando o dia a dia da empresa, alm de evitar erros graves (perda de registros).

Documento de requisitos

Este documento traz as especificaes do software a ser desenvolvido, suas funes e quais as necessidades que ele deve suprir. Apresentaremos isso por meio dos requisitos funcionais, no funcionais e da interface.

VISO GERAL DO SISTEMA

por meio deste documento que vamos especificar as metodologias necessrias Requisitos funcionaisPor meio dos requisitos funcionais explicaremos detalhadamente as ferramentas que devem estar presentes no software e o que se pode obter dele.

REQUISITOS FUNCIONAIS

Os requisitos funcionais so declaraes dos servios que o sistema deve fornecer ou so descries de como algumas computaes devem ser realizadas. Os requisitos de domnio so requisitos funcionais derivados das caractersticas do domnio da aplicao. (SOMMERVILLE).

Lanamentos diversos

O sistema dever permitir a insero, alterao e excluso de funcionrios, contendo os seguintes atributos: codUser, nomeUser, login, senha, nivUser. O sistema dever verificar a disponibilidade do login e senha. Cada funcionrio dever obrigatoriamente, preencher os atributos login e senha. A senha dever ser nica e exclusiva, a qual permitir o acesso do funcionrio ao sistema.

O sistema dever permitir a insero, alterao de itens, contendo os seguintes atributos: id_prod, nomeItem, unmedItem, status, est_min, est_max, valor e descricao . O sistema dever verificar se no tem nenhum item com o mesmo nome j cadastrado.

O sistema dever permitir a insero, alterao de pedidos, contendo os seguintes atributos: numPed, dataPed, valortotalPed.

O sistema dever permitir lanamentos de entradas e sadas de produtos, utilizando os seguintes atributos: codItem, unmedItem, qtdItem, descItem.

Impresso de diversos tipos de relatrios e consultas

O sistema dever permitir a consulta e impresso de relatrios de estoque utilizando os filtro por nomeItem. O sistema dever emitir um alerta que indique quando a quantidade do item estiver baixa. O sistema dever permitir a consulta de funcionrios cadastrados, a partir do atributo: nomeUser. O sistema dever permitir a consulta de pedidos realizados a partir do seguinte atributo: numPed.

1.3 Requisitos no-funcionaiSOs requisitos no funcionais restringem o sistema que est sendo desenvolvido e o processo de desenvolvimento que deve ser usado. Eles podem ser requisitos de produto, requisitos organizacionais ou requisitos externos. Esto frequentemente relacionados s propriedades emergentes do sistema e, portanto, aplicam-se ao sistema como um todo. (SOMMERVILLE).

Confiabilidade

O sistema dever contar com uma opo que permita realizar o backup e tambm que faa a restaurao do sistema. O sistema dever controlar os acessos dos funcionrios, alm de possibilitar o rastreamento das aes realizadas por cada funcionrio.

Eficincia

O sistema dever ser totalmente intuitivo; O sistema dever responder de forma imediata em todo o processo de chamada; Os relatrios devero ser exibidos em no mximo 5 segundos, aps sua solicitao.

1.3.3 Desempenho Para um melhor desempenho do sistema recomendada uma mquina razovel. Com os seguintes requisitos mnimos: Processador 1200MHz, 512Mb de Memria, espao mnimo no HD de 1GB.

VISO DE CASO DE USO NVEL ANLISE

Atores representam uma entidade que interage com o sistema durante sua execuo. Essa interao se d atravs de comunicaes (troca de mensagens). Atores podem ser pessoas (usurio, secretaria, aluno...) ou softwares interativos (sistema de bd, aplicativos...), etc. Algumas de suas caractersticas so descritas abaixo:

Ator no parte do sistema. Representa os papis que o usurio do sistema pode desempenhar. Ator pode interagir ativamente com o sistema. Ator pode ser um receptor passivo de informao. Ator pode representar um ser humano ou outro sistema.

Figura 1 Representao ator

Os atores representam, na verdade, papis desempenhados por pessoas, dispositivos ou outros quando interagem com o sistema. Um ator cujo identificador seja ALUNO no representa um aluno, mais sim um aluno qualquer, uma pessoa que esteja interagindo com o sistema na qualidade de aluno.A identificao dos atores que integram o Sistema de Gerenciamento de Controle de uma Papelaria descrita como:

FuncionrioO Ator Usurio poder fazer a incluso e alterao de novos itens, fornecedores e fazer os lanamentos de entrada e sada de itens.

2.2 LISTA DE CASOS DE USOCaso de uso uma sequncia de aes que o sistema executa e produz um resultado de valor para o ator. Ele modela o dilogo entre os atores e o sistema; um fluxo de eventos completos. Algumas de suas caractersticas so descritas abaixo:

Um "Caso de Uso" modela o dilogo entre atores e o sistema. Um "Caso de Uso" iniciado por um ator para invocar certa funcionalidade do sistema. Um "Caso de Uso" fluxo de eventos completo e consistente. O conjunto de todos os "Casos de Uso" representa todas as situaes possveis de utilizao do sistema.

Ator Funcionrio

NmeroCasos de UsoDescrio

1addFunInclui os dados do funcionrio no B.D

2altFunAltera os dados do funcionrio no B.D

3consFunConsulta os dados do funcionrio no BD.

4delFunDeleta os dados do funcionrio no BD.

Tabela 3 Tabela Lista de Casos de Uso do Ator Funcionrio.

1.3 Modelo de caso de uso

Figura 2 Caso de Uso do Ator: Funcionrio

DESCRIO DE CASOS DE USO

[Caso de uso 01] Logar no SistemaDescrio: O usurio dever entrar com seus dados: login e senha. O Sistema dever permitir acesso ao contedo do software se somente se os dados estiverem corretos.Atores envolvidos: Gerente e Funcionrio.Pr-condio O usurio j devera possuir seu cadastro no sistema.Cenrio Principal de Sucesso:1 O caso de uso iniciado com o login e senha do usurio.2 O usurio dever entrar com seus dados.3 O sistema busca no banco de dados se os dados esto corretos4. O sistema retorna mensagem de login realizado com sucesso e ser iniciado, liberando as funcionalidades de acordo com o privilegio do usurio.Cenrio Secundrio:4.1 O sistema retorna a mensagem de erro login invlido.

[Caso de uso 02] Cadastrar FuncionrioDescrio: O usurio dever fazer entrada dos dados pessoais de cada funcionrio.Atores envolvidos: Administrador ou Usurio do sistema.Pr-condio: O usurio dever estar logado no sistema. E o nome do funcionrio ainda no estiver cadastrado no banco de dados do sistema.Ps-Condies: Retorno mensagem de produto cadastrado.Cenrio Principal de Sucesso:1. O usurio deve ir ao cadastro do funcionrio.2. O usurio dever informar os dados pessoais do funcionrio.3. O usurio submete os dados necessrios para armazenamento no banco de dados.4. O sistema validar os dados e retorna mensagem de sucesso.Cenrio Secundrio:4.1. O sistema aborta a validao dos dados e retorna mensagem de erro, e mostra quais dados so necessrios para o cadastro do funcionrio.

[Caso de uso 03] Alterar dados do FuncionrioDescrio: O usurio dever fazer entrada dos dados referente a busca do funcionrio como o nome de cada funcionrio.Atores envolvidos: Usurio do sistema.Pr-condio: O usurio dever estar logado no sistema. E o usurio deve encontrar o registro do cliente desejado.Ps-Condies: Retorno mensagem de alterao realizada com sucesso.Cenrio Principal de Sucesso:1. O usurio deve ir ao Consulta de funcionrios.2. O usurio dever informar os dados do cliente referente busca, como nome.3. O usurio ter os dados do funcionrio, podendo alter-los conforme sua necessidade, exceto cdigo identificador do mesmo.4. O usurio submete a alterao e o sistema validar os dados.5. O sistema retornar mensagem de sucesso.Cenrio Secundrio:4.1. O sistema aborta a validao dos dados e retorna mensagem de erro, e mostra quais dados so necessrios para o cadastro do funcionrio.

[Caso de uso 04] Excluir FuncionrioDescrio: O usurio dever fazer entrada dos dados referente busca do funcionrio como o nome do funcionrio.Atores envolvidos: Usurio do sistema.Pr-condio: O usurio dever estar logado no sistema. E o usurio deve encontrar o funcionrio desejado.Ps-Condies: Retorno mensagem de excluso realizada com sucesso.Cenrio Principal de Sucesso:1. O usurio deve ir ao Consulta de funcionrios.2. O usurio dever informar os dados do funcionrio referente busca, como seu nome.3. O usurio ter a visualizao dos dados do funcionrio no sistema.4. O usurio submete a ao para excluir o funcionrio e o sistema retorna mensagem de sucesso.

[Caso de uso 05] Cadastrar ProdutoDescrio: O usurio dever fazer entrada dos dados referente a cada produto.Atores envolvidos: Usurio do sistema.Pr-condio: O usurio dever estar logado no sistema. E nome ou cdigo de barras do produto ainda no cadastrado.Ps-Condies: Retorno mensagem de produto cadastrado.Cenrio Principal de Sucesso:1. O usurio deve ir ao cadastro do produto.2. O usurio dever informar os dados do produto.3. O usurio submete os dados necessrios para armazenamento no banco de dados.4. O sistema validar os dados e retorna mensagem de sucesso.Cenrio Secundrio:4.1. O sistema aborta a validao dos dados e retorna mensagem de erro, e mostra quais dados so necessrios para o cadastro do produto.

[Caso de uso 06] Alterar dados ProdutoDescrio: O usurio dever fazer entrada dos dados referente busca do produto, como cdigo identificador ou nome do produto.Atores envolvidos: Usurio do sistema.Pr-condio: O usurio dever estar logado no sistema. E o usurio deve fornecer um dos dados para encontrar o produto.Ps-Condies: Retorno mensagem de alterao realizada com sucesso.Cenrio Principal de Sucesso:1. O usurio deve ir ao cadastro do produto.2. O usurio dever informar os dados do produto referente busca.3. O usurio ter os dados do produto, podendo alter-los conforme sua necessidade, exceto cdigo identificador do produto.4. O usurio submete a alterao e o sistema validar os dados.5. O sistema retornar mensagem de sucesso.Cenrio Secundrio:4.1. O sistema aborta a validao dos dados e retorna mensagem de erro, e mostra quais dados so necessrios para o cadastro do produto.

[Caso de uso 07] Excluir ProdutoDescrio: O usurio dever fazer entrada dos dados referente a busca como seu cdigo identificador ou nome do produto.Atores envolvidos: Usurio do sistema.Pr-condio: O usurio dever estar logado no sistema. E o usurio deve fornecer um dos dadospara encontrar o produto.Ps-Condies: Retorno mensagem de excluso realizada com sucesso.Cenrio Principal de Sucesso:1. O usurio deve ir ao cadastro do produto.2. O usurio dever informar os dados do produto referente busca.3. O sistema retornar os dados do cadastro do produto. O usurio ter a visualizao dos dados do produto no sistema.4. O usurio submete a ao para excluir o produto.5. O sistema retornar mensagem de sucesso.

[Caso de uso 08]: Efetuar VendaDescrio: O usurio entrara com alguns dados do cliente em seguida os cdigos e quantidades dos produtos da venda.Atores envolvidos: Gerente e FuncionrioPr-condio O usurio j devera estar logado no sistema, e o cliente ter um cadastro existente no banco de dados do sistema.Cenrio Principal de Sucesso:1. O caso de uso iniciado com a solicitao de venda dos produtos.2. O usurio da inicio a venda, passando os cdigos identificadores dos produtos e a sua respectiva quantidade de venda.3. O sistema validar os dados e ir retornar a mensagem de sucesso.Cenrio Secundrio:3.1. O sistema internamente far um registro da venda, para a gerao de um relatrio de venda.3.2 O sistema ir fazer a atualizao do estoque, sobre os produtos vendidos.

Modelo de SEQUNCIA

Diagrama de sequncia a representao da interao dos objetos, das comunicaes necessrias para realizao dos processos de um sistema computacional. Ele um instrumento importante que oferece uma base para definio dos relacionamentos entre as classes, mtodos e atributos das classes e o comportamento dinmico dos objetos.Podem-se elaborar diagramas de sequncia por caso de uso, descrevendo as sequncias normais de comunicao e as alternativas, bem como situaes de erro.Para descrio de diagramas de sequncia utiliza-se uma notao UML que define as mensagens trocadas entre estes objetos ao longo de uma linha de tempo. Os objetos so colocados em linha na parte superior do diagrama, linhas verticais tracejadas so desenhadas da base dos objetos at a parte inferior do diagrama representando a linha de tempo. O ponto superior destas linhas indica um instante inicial e, medida que se avana para baixo evolui-se o tempo. Retngulos colocados sobre as linhas de tempo dos objetos indicam os perodos de ativao do objeto. Durante um perodo de ativao, o objeto respectivo esta em execuo realizando algum processamento. Nos perodos em que o objeto no esta ativo, ele est alocado (ele existe), mas no esta executando nenhuma instruo. Nos diagramas de sequncia existe a troca de mensagens entre objetos com interao e comunicao. Essas trocas so representadas por segmentos de retas direcionadas da linha de tempo de um objeto origem para a linha de tempo de um objeto destino. Uma seta colocada na extremidade do objeto destino.As linhas representando troca de mensagens so desenhadas na horizontal, pois se presume que a troca de uma mensagem consome um tempo desprezvel.Existe o processamento da mensagem pelo objeto destino de uma mensagem. As mensagens trocadas entre um objeto ou entre um objeto e um ator podem ter trs significados:

Chamada de Funo ou ProcedimentoA chamada de funo uma das interaes que mais se repetem. Ela acontece quando um objeto solicita a efetivao de uma funo/mtodo de outro objeto.

Envio de MensagemEste tipo de interao no direto entre dois objetos. Acontece quando a mensagem roteada ou encaminhada por algum mecanismo de entrega de mensagens, normalmente servio prestado pelo sistema operacional ou servios de notificao.

Ocorrncia de EventoOutro tipo de interao de objetos atravs de eventos, que so acontecimentos externos ao software, mas que lhe diz respeito. Como por exemplo: clique do mouse e movimentao do mouse.

2.4.1Diagrama de Sequncia de Caso de UsoLancarEntrada

O Funcionrio faz o lanamento de uma entrada de produtos no estoque atravs do sistema que salva a entrada no banco de dados.

Figura 4 - Modelo de Sequncia do Caso de Uso LanarEntrada

Curso Normal:1. Acessar tela de lanamento de entradas no sistema, essa tela j traz uma lista em uma grid das ltimas entradas lanadas.1.1 Consultar lista de entradas salva no banco de dados.1.1. Retorna o resultado da consulta que a lista das ltimas entradas lanadas.1.1.1.1 Listar as ltimas entradas lanadas no sistema para o funcionrio.2. O usurio clica no boto incluir para lanar a entrada.2.1 O sistema exibe a tela de incluso de entradas.3. O usurio preenche os campos da tela de incluso de entradas.4. O usurio clica em salvar.4.1 O sistema grava o lanamento no banco de dados.4.1.1 O banco de dados retorna uma confirmao.4.1.1.1 O sistema apresenta ao funcionrio uma confirmao da incluso.

Curso Alternativo:1.1 Sem acesso a lista e/ou lista corrompida ou inexistente.4O usurio no salva os campos preenchidos.4.1O sistema no lana os dados para serem salvados no banco de dados.

VISO LGICA NVEL ANLISE

A Viso Lgica permite a compreenso da estrutura e da organizao do sistema, sendo utilizada no fluxo de trabalho de anlise, ilustrando as principais operaes do caso de uso, subsistemas, pacotes e classes que compem o procedimento significativo em termos de design da arquitetura do sistema.

1. MODELOS DE CLASSESDO SISTEMA ESTOQUE

Uma classe uma representao de um objeto. Elas tm como formato padro a apresentao como retngulos com 3 partes: no topo temos o nome da classe, nomeio os atributos da classe e a na parte de baixo os mtodos da classe. Sendo que os atributos so as informaes armazenadas sobre o objeto, enquanto mtodos so as aes que um objeto ou classe executa.Aps a identificao das classes e elaborao da modelagem, que consiste em organizar as classes em taxonomia, ou seja, em um esquema onde so classificadas e onde so mostradas as relaes existentes entre as vrias classes por meio de atributos e servios comuns. importante entender muito bem o ambiente onde o sistema atuar, pois complicado estabelecer os relacionamentos entre as classes sem essa compreenso.Citaremos cinco tipos mais importantes de relaes: dependncia, associao, generalizao (ou herana),agregao regular e composio:

Figura 7 Notaes de relaes

Dependncia este tipo de relacionamento ocorre quando uma mudana na especificao de um elemento pode alterar a especificao do elemento dependente. Associao: So relacionamentos estruturais entre instncias e especificam que objetos de uma classe esto ligados a objetos de outras classes. A associao pode existir entre classes ou entre objetos. Como por exemplo uma associao entre a classe Professor e a classe disciplina (um professor ministra uma disciplina) significa que uma instncia de Professor (um professor especfico) vai ter uma associao com uma instncia de Disciplina. Esta relao significa que as instncias das classes so conectadas, seja fisicamente ou conceitualmente; Generalizao (herana: simples ou composta) - Relacionamento entre um elemento mais geral e um mais especfico. Onde o elemento mais especfico herda as propriedades e mtodos do elemento mais geral. A relao de generalizao tambm conhecida como herana no modelo a objetos. Como a relao de dependncia, ela existe s entre as classes. Um objeto particular no um caso geral de outro objeto, s conceitos (classes no modelo a objetos) so generalizaes de outros conceitos; Agregao Regular - tipo de associao ( parte de, todo/parte) onde o objeto parte um atributo do todo; onde os objetos partes somente so criados se o todo ao qual esto agregados for criado. Ex.: Pedidos composto por itens de pedidos. Composio - Relacionamento entre um elemento (o todo) e outros elementos (as partes) onde as partes s podem pertencer ao todo e so criadas e destrudas com ele;

DIAGRAMA DE CLASSES DO PROJETO

Figura 8 Diagrama de Classes

MODELO DE ENTIDADE RELACIONAMENTO

O Modelo de Entidade Relacionamento, como informado por Date/2000, composto por entidades que podem ser um objeto de existncia fsica, como uma pessoa, carro ou empregado, ou um objeto com existncia conceitual, uma companhia, um trabalho ou um curso. Essas entidades tm caractersticas prprias denominadas atributos, cujos valores ocupam grande parte da capacidade de armazenamento da base de dados. Por esse motivo devemos avaliar e montar corretamente o diagrama de entidade relacionamento, que otimizar nosso sistema.Existe um agrupamento de entidades que so similares, que possuem os mesmos atributos, porm cada entidade tem seus prprios valores para cada atributo. Os conjuntos de entidades similares determinam um tipo entidade.Todo tipo entidade identificado pelo seu nome e pelo grupo de atributos que determinam suas propriedades. A descrio do tipo entidade denominada esquema do tipo entidade, onde so especificados o nome do tipo entidade, o nome de cada um de seus atributos e qualquer restrio que incida sobre as entidades.Uma restrio muito significante em uma entidade de um determinado tipo entidade a chave. Este atributo chamado atributo chave o que distingue individualmente cada entidade de forma particular e nica.Em muitas ocasies, uma chave pode ser formada pela unio de dois ou mais atributos. Uma entidade pode tambm ter mais de um atributo chave.Os atributos simples de um tipo entidade so agrupados em um conjunto de valores chamado domnio, o qual nomeia um grupo de valores que podem ser designados para determinado atributo para cada entidade.As ocorrncias existentes entre entidades so denominadas relacionamentos e so representadas no modelo E-R por um losango com o nome do relacionamento escrito no seu interior.Existem entidades que no possuem relacionamentos e so chamadas de entidades isoladas.Entre as entidades existem trs modelos de relacionamento:

um-para-um um-para-muitos muitos-para-muitos

O relacionamento um-para-um existe quando uma entidade A se relaciona com uma entidade B e vice-versa sendo representada pelo sinal 1:1.

Figura 9 Relacionamento um-para-um

No relacionamento um-para-muitos, uma entidade A pode se relacionar com uma ou mais entidades B e representada pelo sinal 1:N

Figura 10 Relacionamento um-para-muitos

Ocorre o relacionamento muitos-para-muitos quando vrias entidades A se relacionam com vrias entidades B sendo este relacionamento representado pelo sinal N:N ou N:M.

Figura 11 Relacionamento muitos-para-muitos

O conceito de cardinalidade fundamental para auxiliar na definio dos relacionamentos porque define o nmero de ocorrncias presentes nele. Para se obter a determinao da cardinalidade, devemos fazer a pergunta relativa ao relacionamento em ambas as direes.Um departamento possui quantos empregados?- no mnimo 1 e no mximo N.Um empregado est alocado em quantos departamentos?- no mnimo em 1 e no mximo em 1Somando-se as cardinalidades, definimos o resultado final do relacionamento, ou seja, 1:N

Diagrama Entidade Relacionamento

Figura 12 Diagrama de Entidade e Relacionamento.

TELAS DO SISTEMA

Figura Entrada Externa do Menu Principal.

Figura Entrada Externa do Incluir Funcionrio.

Figura Entrada Externa do Incluir Item e do Incluir Pedido.

Figura Consulta Externa do Consultar Pedido.

Figura Consulta Externa do Consultar Pedidos.

Figura Consulta Externa do Consultar Estoque.

PL/SQL Funes

CREATE TABLE produto (

id_prod INT(11) NOT NULL AUTO_INCREMENT,status CHAR(1) NOT NULL DEFAULT 'A', descricao VARCHAR(50) NULL DEFAULT NULL,est_min INT(11) NULL DEFAULT NULL,est_max INT(11) NULL DEFAULT NULL,

PRIMARY KEY (id_prod));

CREATE TABLE entrada_produto ( id_ent_prod INT(11) NOT NULL AUTO_INCREMENT, id_prod INT(11) NULL DEFAULT NULL, qtde_entrada INT(11) NULL DEFAULT NULL, valor_unit DECIMAL(9,2) NULL DEFAULT '0.00', data_entrada DATE NULL DEFAULT NULL,

PRIMARY KEY (id_ent_prod));

CREATE TABLE estoque ( id_est INT(11) NOT NULL AUTO_INCREMENT, id_prod INT(11) NULL DEFAULT NULL,qtde INT(11) NULL DEFAULT NULL, valor_unitario DECIMAL(9,2) NULL DEFAULT '0.00',

PRIMARY KEY (id_est));

CREATE TABLE saida_produto ( id_sai_prod INT(11) NOT NULL AUTO_INCREMENT, id_prod INT(11) NULL DEFAULT NULL, qtde_saida INT(11) NULL DEFAULT NULL, data_saida DATE NULL DEFAULT NULL, valor_unit DECIMAL(9,2) NULL DEFAULT '0.00',

PRIMARY KEY (id_sai_prod);

PROCEDURE PARA ATUALIZAR ESTOQUE

DELIMITER $$ CREATE PROCEDURE `Atualiza_Est`( `id_prod` int, `qtde_comprada` int, valor_unit decimal(9,2)) BEGIN

declare contador int(11); SELECT count(*) into contador FROM estoque WHERE id_produto = id_prod; IF contador > 0 THEN UPDATE estoque SET qtde=qtde + qtde_comprada, valor_unitario= valor_unit WHERE id_produto = id_prod;

ELSE INSERT INTO estoque (id_produto, qtde, valor_unitario) values (id_prod, qtde_comprada, valor_unit);

END IF; END $$ DELIMITER ;

TRIGGER ENTRADA DE PRODUTO APS A INSERO

DELIMITER $$ CREATE TRIGGER `TRG_EntradaProduto_AI` AFTER INSERT ON `entrada_produto` FOR EACH ROW BEGIN CALL PROC_Atualiza_Est (new.id_produto, new.qtde, new.valor_unitario);

END $$

DELIMITER ;

TRIGGER ENTRADA DE PRODUTO APS A ATUALIZAO

DELIMITER $$ CREATE TRIGGER `TRG_EntradaProduto_AA` AFTER UPDATE ON `entrada_produto` FOR EACH ROW BEGIN CALL PROC_Atualiza_Est (new.id_produto, new.qtde - old.qtde, new.valor_unitario); END $$ DELIMITER ;

TRIGGER ENTRADA DE PRODUTO APS A EXCLUSO

DELIMITER $$ CREATE TRIGGER `TRG_EntradaProd_AE` AFTER DELETE ON `entrada_produto` FOR EACH ROW BEGIN CALL PROC_Atualiza_Est (old.id_produto, old.qtde * -1, old.valor_unitario); END $$ DELIMITER ;

TRIGGER SADA DE PRODUTO APS A INSERO DELIMITER $$ CREATE TRIGGER `TRG_SaidaProd_AI` AFTER INSERT ON `saida_produto`

FOR EACH ROW BEGIN CALL PROC_Atualiza_Est (new.id_produto, new.qtde * -1, new.valor_unitario);

END $$

DELIMITER ;

TRIGGER SADA DE PRODUTO APS A ATUALIZAODELIMITER $$ CREATE TRIGGER `TRG_SaidaProduto_AU` AFTER UPDATE ON `saida_produto` FOR EACH ROW

BEGIN

CALL PROC_Atualiza_Est (new.id_produto, old.qtde - new.qtde, new.valor_unitario); END $$

DELIMITER ;

TRIGGER SADA DE PRODUTO APS A EXCLUSO

DELIMITER $$ CREATE TRIGGER `TRG_SaidaProduto_AD` AFTER DELETE ON `saida_produto` FOR EACH ROW BEGIN CALL PROC_Atualiza_Est (old.id_produto, old.qtde, old.valor_unitario); END $$ DELIMITER ;

referncias bibliogrficas

BURNETT, Robert Carlisle. Engenharia de requisitos: conceitos e fundamentos, S.l., 1998. Disponvel em: . Acesso em: 08 fev. 2014.

LOPES, Srgio Naddeo Dias. Engenharia de requisitos: uma viso geral. So Paulo, 1999. Disponvel em: . Acesso em: 09 fev. 2014.

PRESSMAN, Roger S. Engenharia de software. So Paulo: Makron Books, 1995. Disponvel em:. Acesso em: 09 fev. 2014.