Modelagem de Banco de Dados

FACULDADE DE ENGENHARIA DE GUARATINGUETÁ

ESPECIALIZAÇÃO EM INFORMÁTICA EMPRESARIAL

Desenvolvimento de um sistema de compras para uma fábrica de

alimentos

Andréa Silva de Oliveira

Guaratinguetá - SP

Junho, 2008

Desenvolvimento de um sistema de compras para uma fábrica de

alimentos


Monografia apresentada à Faculdade de Engenharia de

Guaratinguetá, da Universidade Estadual Paulista, como

parte dos requisitos para a obtenção do certificado de

Especialista em Informática Empresarial.

Orientador : Prof. Dr. Edson Luiz França Senne

Guaratinguetá - SP

Junho, 2008

Ficha catalográfica preparada na Seção de Aquisição e Tratamento da Informação do Serviço Téc-

nico de Biblioteca e Documentação - FEG/UNESP

Oliveira, Andréa Silva de

O48d Desenvolvimento de um sistema de compras para uma fábrica de

alimentos / Andréa Silva de Oliveira, Guaratinguetá, 2008.

50 f.:il.

Bibliografia: f.49-50

Monografia de Especialização em Informática Empresarial - Univer-

sidade Estadual Paulista, Faculdade de Engenharia de Guaratinguetá, 2008.

Orientador: Prof. Dr. Edson Luiz França Senne.

1. UML (Linguagem de modelagem padrão) I. Título

CDU 519.682

Desenvolvimento de um sistema de compras para uma fábrica de alimentos

DADOS CURRICULARES


NASCIMENTO: (28/08/1983) - Local (Campinas, São Paulo)

FILIAÇÃO: Paulo Afonso Pinto de Oliveira

Rosa Maria Silva de Oliveira

(2004) Tecnólogo em Automação de Escritórios e Secretariado

Faculdade de Tecnologia de Guaratinguetá - FATEC

UNESP/FEG-CEIE, 2008 i


Dedico esse trabalho ao meu pai,

por todos os exemplos de vida

e ensinamentos que me deixou.

UNESP/FEG-CEIE, 2008 ii


AGRADECIMENTOS

Agradeço a Deus que me deu capacidade e força para vencer os obstáculos e dificul-

dades que encontrei.

Ao meu orientador Prof. Dr. Edson Luiz França Senne pela habilidade e dedicação

com que me orientou nesse trabalho.

À minha mãe, por ter me dado força nos momentos mais difíceis.

E ao meu namorado, que sempre me apoiou e incentivou.

UNESP/FEG-CEIE, 2008 iii


UNESP/FEG-CEIE, 2008 iv

Sumário

1 Introdução 1

1.1 Objetivo do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Descrição do funcionamento do módulo de compras . . . . . . . . . . . . 2

1.3 Desenvolvimento do trabalho . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Resultados esperados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.5 Organização da monografia . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Modelagem orientada a objetos 7

2.1 Etapas do desenvolvimento do sistema . . . . . . . . . . . . . . . . . . . 8

2.2 Conceitos básicos de modelagem orientada a objetos . . . . . . . . . . . 10

2.3 Tecnologias utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.2 Diagramas da UML . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.3 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.4 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Modelagem do sistema de compras 17

3.1 Diagramas de caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Fluxos de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1 Fluxo de eventos para o caso de uso "Inserir fornecedor" . . . . . 19


3.2.2 Fluxo de eventos para o caso de uso "Alterar fornecedor" . . . . 20

3.2.3 Fluxo de eventos para o caso de uso "Excluir fornecedor" . . . . 21

3.2.4 Fluxo de eventos para o caso de uso "Inserir material" . . . . . . 22

3.2.5 Fluxo de eventos para o caso de uso "Alterar material" . . . . . . 23

3.2.6 Fluxo de eventos para o caso de uso "Excluir material" . . . . . . 24

3.2.7 Fluxo de eventos para o caso de uso "Inserir requisições" . . . . 24

3.2.8 Fluxo de eventos para o caso de uso "Realizar cotações" . . . . . 25

3.2.9 Fluxo de eventos para o caso de uso "Efetuar compras" . . . . . 26

3.2.10 Fluxo de eventos para o caso de uso "Receber mercadorias" . . . 27

3.2.11 Fluxo de eventos para o caso de uso "Movimentar estoque" . . . 27

3.3 Estrutura da base de dados . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Funcionamento do sistema 31

4.1 Tela inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Botões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3 Cadastro de Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.4 Cadastro de Materiais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.5 Cadastro de Fornecedores . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.6 Requisição de Material . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.7 Cotação de Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.8 Compras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.9 Movimento de Estoque . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5 Conclusão 47

Referências Bibliográficas 49

UNESP/FEG-CEIE, 2008 vi

Lista de Figuras

3.1 Caso de uso principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Caso de uso: Cadastro de fornecedores . . . . . . . . . . . . . . . . . . . 19

3.3 Caso de uso: Cadastro de materiais . . . . . . . . . . . . . . . . . . . . . 22

3.4 Modelagem de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Tela inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Menu Cadastros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3 Menu Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 Botões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5 Cadastro de Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.6 Pesquisar por login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.7 Relatório de Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.8 Cadastro de Materiais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.9 Pesquisar por descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.10 Relatório de Materiais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.11 Cadastro de Fornecedores . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.12 Pesquisar por razão social . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.13 Relatório de Fornecedores . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.14 Requisição de Material . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.15 Relatório de Requisições . . . . . . . . . . . . . . . . . . . . . . . . . . 40


4.16 Cotações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.17 Relatório de Cotações . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.18 Compra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.19 Relatório de Compras . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.20 Movimento de Estoque . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.21 Relatório de Movimento de Estoque . . . . . . . . . . . . . . . . . . . . 46

UNESP/FEG-CEIE, 2008 viii


Oliveira, A.S. - Desenvolvimento de um sistema de compras para uma fábrica de alimen-

tos. Guaratinguetá, 2008. 50 p. Monografia (Especialização em Informática Empresarial)

- Faculdade de Engenharia de Guaratinguetá, Universidade Estadual Paulista.

Resumo

A Tecnologia da Informação vem, cada vez mais, sendo usada pelas empresas para

criar, tratar, armazenar e transferir informações entre seus setores e mesmo das empresas

para seus clientes. Os sistemas informatizados permitem às empresas um maior controle

do negócio e exercem grande influência no processo de tomada de decisões.

Este trabalho consiste no desenvolvimento de um sistema para uma fábrica de ali-

mentos. O objetivo do sistema é fornecer aos usuários informações sobre o estoque das

matérias-primas e materiais de consumo para que seja possível organizar e planejar as

requisições dos materiais a serem usados na produção de alimentos. O sistema objetiva

também gerenciar o processo de compras junto a fornecedores, incluindo as informações

de formas de pagamento e prazos de entrega. O sistema, portanto, pretende automatizar os

processos envolvidos no processo de compras da empresa, auxiliando os funcionários no

seu dia-a-dia e proporcionando aos diretores informações rápidas e seguras sobre a situ-

ação da empresa.

O trabalho apresenta as etapas necessárias para o desenvolvimento de um sistema de

informações e ressalta os benefícios da modelagem orientada a objetos para este processo

de desenvolvimento.

Palavras-chave: UML, Análise orientada a objetos, Modelagem, Linguagem Java.

UNESP/FEG-CEIE, 2008 ix


Oliveira, A.S. - Development of a purchase system for a food industry. Guaratinguetá,

2008. 50 p. - Monografia (Especialização em Informática Empresarial) - Faculdade de

Engenharia de Guaratinguetá, Universidade Estadual Paulista.

Abstract

The Information Technology has, more and more, been used by the companies in

order to create, to treat, to store and to transfer information inside the companies and even

from the companies for their customers. The computerized systems allow the companies

to have a larger control of the business and they have great influence in the decision mak-

ing process.

This work describes the development of a information system for a food industry.

The objective of the system is to supply information on the stock of the raw materials

and consumption materials to their users, so that can be possible to organize and to plan

the requests of the materials which are used in the production of foods. The system also

aims at to manage the purchase process with the suppliers, including the information about

payment ways and delivery periods. The system intends that the purchase process of the

company be automated, aiding the employees in their work and providing fast and safe

information about the situation of the company to the managers.

The work presents the necessary stages for the development of a information system

and emphasizes the benefits of the objects oriented modelling in this development process.

Keywords: UML, Object oriented analysis, Modelling, Java language.

UNESP/FEG-CEIE, 2008 x

Capítulo 1

Introdução

A Tecnologia da Informação possibilita a utilização da informática em qualquer empresa.

Os softwares desenvolvidos para o controle interno das organizações estão sendo cada vez

mais usados como um meio de criar, armazenar e transferir a informação entre setores das

empresas e mesmo das empresas para seus clientes.

Os sistemas informatizados permitem um maior controle para as empresas e exercem

grande influência no processo de tomada de decisões. Estes sistemas transformam a infor-

mação de modo que esta possa ajudar empregados e gerentes a tomar decisões, analisar e

resolver diversos tipos de problemas [LAUDON e LAUDON 1999]. Se a informação não

é precisa ou completa, decisões ruins podem ser tomadas, custando muito dinheiro à orga-

nização. Além disso, se a informação não é fornecida no tempo certo, ela pode ter pouco

valor para a empresa. O valor da informação está diretamente ligado ao modo como ela

ajuda os tomadores de decisões a atingirem os objetivos da organização [STAIR 1998].

Além da eliminação de tarefas repetitivas, o uso de um sistema informatizado por uma

empresa possibilita uma maior segurança com relação às informações e conseqüentemente

uma diminuição de erros em processos que passarão a ser realizados de forma automati-

zada.

Resultados precisos, maior controle das operações realizadas nas empresas e a grande

possibilidade de decisões estratégicas são as maiores motivações para automatizar proces-

sos em uma empresa. E é a razão para o desenvolvimento desse trabalho.


1.1 Objetivo do trabalho

Esse trabalho consiste no desenvolvimento de um sistema para uma fábrica de alimentos.

A empresa ainda não possui um controle informatizado das compras de matérias-primas e

materiais de consumo. O principal objetivo desse trabalho é desenvolver um sistema que

possa controlar as operações envolvidas nesse processo de compras.

O sistema fornecerá aos usuários informações sobre o estoque das matérias-primas e

materiais de consumo. Com base nessas informações, os funcionários poderão organizar

e planejar melhor as requisições dos materiais, sem deixá-los atingir o estoque mínimo.

Outro controle importante que o sistema fornecerá é o das cotações junto aos fornece-

dores. Muitas vezes, a diretoria não toma conhecimento de algumas delas e do processo

de escolha de fornecedores. Todas as cotações realizadas deverão ser armazenadas no

sistema, incluindo as informações de formas de pagamento e prazos de entrega.

Com a chegada das mercadorias, o usuário dará baixa na compra, confirmando as

quantidades recebidas e dando entrada em estoque de todas elas. O sistema irá fornecer

também ao usuário uma tela para realização de saídas de materiais do estoque. O usuário

deverá registrar no sistema as saídas de cada matéria-prima e material de consumo que for

utilizado. Deve-se ressaltar que, futuramente, o sistema poderá incluir um módulo de pro-

dução. Nesse módulo, a cada produção realizada, o sistema atualizaria automaticamente o

estoque de todas as matérias-primas utilizadas na produção.

1.2 Descrição do funcionamento do módulo de compras

Há várias atividades envolvidas no funcionamento do módulo de compras. As principais

são:

• Cadastro de matérias-primas;

• Cadastro de materiais de consumo;

• Cadastro de fornecedores;

UNESP/FEG-CEIE, 2008 2


• Requisições de compra;

• Cotações;

• Compras;

• Recebimento de mercadorias e entrada em estoque;

• Movimentação de estoque.

Quando o funcionário insere uma nova requisição, o sistema verifica se a matéria-

prima e/ou material de consumo que o funcionário deseja requisitar já está cadastrado.

Caso não esteja, o sistema informa ao usuário para que ele efetue o cadastro inicialmente.

Em seguida, o funcionário faz a requisição da matéria-prima ou de algum material de

consumo que esteja precisando.

Um funcionário do setor de compras seleciona as requisições e dá início às cotações

de preços com os fornecedores. Caso haja algum fornecedor novo, o funcionário deve

providenciar o cadastro do mesmo no sistema.

Com as cotações finalizadas, é realizada a análise de preços, condições de pagamento

e prazos de entrega de cada uma delas. Com base nessas informações, será decidido qual

a melhor cotação para a empresa e de qual fornecedor será efetuada a compra.

Com a chegada da mercadoria na empresa, é dado baixa na compra e na requisição.

Também é atualizado o estoque dos materiais e matérias-primas compradas.

Conforme esses itens forem sendo utilizados, o usuário deverá acessar a tela de movi-

mentação de estoque para informar as quantidades utilizadas. O sistema atualizará o es-

toque desses materiais.

1.3 Desenvolvimento do trabalho

Para desenvolver o sistema, foi realizada uma pesquisa na empresa para saber como são

mantidos os cadastros de fornecedores, matérias-primas e materiais de consumo. Tam-

bém foi pesquisado como são feitas as requisições, cotações e compras e se é mantido



um histórico dessas compras. Também foi pesquisado como a empresa espera que o sis-

tema automatizado controle esses processos. A partir da pesquisa foram constatadas as

seguintes deficiências no processo de compras:

• Não existe cadastro das matérias-primas e materiais de consumo;

• Não existe cadastro dos fornecedores;

• Não existe controle dos materiais e matérias-primas que estão em falta e das requi-

sições;

• Não existe controle das cotações;

• Não existe controle das compras;

• Não existe controle do recebimento de mercadorias e entrada em estoque;

• Não existe controle das movimentações de estoque.

Com as informações colhidas na empresa, foi realizada a análise do sistema desen-

volvido e a definição e criação das tabelas do banco de dados. O sistema foi desenvolvido

na linguagem Java, utilizando o PostgreSQL como sistema gerenciador de bancos de da-

dos (SGDB).

1.4 Resultados esperados

Como resultado desse trabalho, espera-se que o sistema desenvolvido solucione as defi-

ciências constatadas, fornecendo informações precisas e seguras da situação do estoque da

empresa.

Espera-se que o sistema proporcione um controle correto do estoque, trazendo benefí-

cios diretamente ligados ao tempo e dinheiro da empresa. Informações precisas da situação

atual do estoque permitem que as compras sejam realizadas no tempo certo, evitando gas-

tos antecipados quando estas ocorrem antes do tempo necessário e impedindo possíveis

atrasos de produção quando os níveis de estoque estiverem abaixo do mínimo.



Outro resultado importante que o sistema trará para a diretoria da empresa é o controle

das escolhas de fornecedores, evitando que funcionários beneficiem, por diversas razões,

fornecedores que não oferecem os melhores preços e formas de pagamento.

O objetivo fundamental do sistema é contribuir ao máximo com a melhoria do fluxo de

trabalho da empresa, possibilitando que os processos sejam realizados de maneira correta

e padronizada. Além de proporcionar informações concretas para a tomada de decisões

estratégicas por parte do alto escalão da empresa.

1.5 Organização da monografia

Além de uma breve descrição dos objetivos do trabalho nesse capítulo, esse trabalho está

desenvolvido da seguinte forma:

O Capítulo 2 apresenta alguns conceitos de modelagem orientada a objetos, as etapas

de desenvolvimento do sistema e a tecnologias utilizadas nesse trabalho, como UML, Java

e PostgreSQL.

O Capítulo 3 apresenta a modelagem do sistema desenvolvido, utilizando os conceitos

de modelagem orientada a objetos e de UML apresentados no Capítulo 2.

O Capítulo 4 apresenta o funcionamento do sistema, através da apresentação de suas

telas.

O Capítulo 5 apresenta as considerações finais desse trabalho, mostrando a importância

de considerar todas as etapas no desenvolvimento de um sistema. Além de deixar, como

sugestão, o desenvolvimento de outros módulos que complementam o módulo de compras

desenvolvido.


Capítulo 2

Modelagem orientada a objetos

O processo de informatização dentro de uma empresa traz inúmeras implicações, que vão

desde mudanças nas rotinas de trabalho até reestruturações organizacionais.

Construir esses sistemas de informação é um processo de resolução de problemas e

as ferramentas e tecnologias utilizadas são decisivas para o seu desenvolvimento. Os sis-

temas de informação são dinâmicos, estão em constante mudança e costumam aumentar

em tamanho, complexidade e abrangência. Essas mudanças se devem a diversos fatores,

como a necessidade de melhorias por parte dos clientes e de novas estratégias devido a

mudanças no mercado.

A tecnologia mais utilizada hoje pelas empresas de desenvolvimento de sistemas é a

orientação a objetos. Quando os sistemas são desenvolvidos corretamente, eles se tornam

flexíveis a mudanças e podem ser mantidos com facilidade, rapidez e de maneira correta.

Modelar um sistema é uma forma bastante eficiente de documentá-lo. O primeiro

passo no desenvolvimento de um sistema é descobrir o que o sistema deve fazer, deter-

minando quais são as necessidades a serem atendidas. A esse conjunto de necessidades,

dá-se o nome de requisitos.


2.1 Etapas do desenvolvimento do sistema

Uma das primeiras fases no desenvolvimento de um software é o levantamento de requi-

sitos. Esta etapa serve para descobrir e conhecer as necessidades do usuário e o que ele

deseja que o sistema realize. Esta é uma etapa de planejamento e é muito importante,

pois as decisões tomadas nesta fase determinam a qualidade e o preço do sistema final.

Sem um bom planejamento e levantamento das informações, um sistema corre o risco de

ser mal desenvolvido, não atendendo às necessidades reais da empresa. Nesta etapa, são

realizadas entrevistas com usuários, especialistas e analistas de negócios para determinar

quais são os requisitos funcionais e conhecer os processos que devem ser automatizados

[LEME FILHO 2003].

As entrevistas devem ser realizadas até que as necessidades do usuário sejam bem

compreendidas. Depois de cada entrevista, é de suma importância manter documentadas

as pautas das entrevistas e os e-mails trocados.

Logo após o levantamento dos requisitos, passa-se à fase em que as necessidades apre-

sentadas pelo cliente são analisadas. Esta etapa é conhecida como análise de requisitos. É

nela que os requisitos enunciados pelos usuários serão examinados, verificando se os mes-

mos foram bem especificados e compreendidos. A partir da etapa de análise de requisitos,

são determinadas as reais necessidades do sistema de informação.

Um dos principais problemas enfrentados na fase de levantamento de requisitos é o

de comunicação, caracterizando-se pela dificuldade em conseguir compreender um con-

junto de conceitos vagos e abstratos que representam as necessidades dos clientes para

transformá-los em conceitos concretos e inteligíveis.

A grande questão é saber se as necessidades dos usuários foram realmente bem com-

preendidas, se algum tópico deixou de ser abordado, se algum item foi especificado in-

corretamente ou se algum conceito precisa ser mais bem explicado. Estas questões devem

ser resolvidas o quanto antes, para que o projeto do software não tenha que sofrer modifi-

cações no decorrer do seu desenvolvimento, o que poderia causar grandes atrasos e até a

necessidade de remodelar totalmente o projeto [GUEDES 2004].

Outro grande problema encontrado durante as entrevistas é o fato de que os usuários



não têm realmente certeza do que querem. Às vezes, é necessário sugerir muitas caracterís-

ticas e funções do sistema que o cliente não sabia como formular ou não havia imaginado.

Na realidade, na maioria das vezes, é preciso reestruturar o modo como as informações

são utilizadas pela empresa e apresentar maneiras de combiná-las e apresentá-las de modo

que possam ser mais bem aproveitadas pelos usuários.

Em muitos casos é realmente isso o que os clientes esperam, porém em outros, os

clientes oferecem fortes resistências a qualquer tipo de mudança na forma como a empresa

manipula suas informações e é preciso um grande esforço para provar ao cliente que as

modificações sugeridas permitirão um melhor desempenho do software, além de ser útil

para a própria empresa. Na realidade, neste último caso é preciso trabalhar bastante o

aspecto social da implantação de um sistema informatizado na empresa, porque muitas

vezes a resistência não é tanto por parte da gerência, mas pelos usuários finais que serão

obrigados a mudar a forma como estavam acostumados a trabalhar e aprender a utilizar

uma nova tecnologia.

Todo processo de mudança desencadeia ansiedades, expectativas, temores e mudanças

de comportamento. Nos momentos em que ocorre a introdução de automação, ela quase

sempre é vista imediatamente como uma ameaça ao emprego. É necessário lidar ade-

quadamente com isso.

É corrente a ilusão de que a automação diminui a dependência dos funcionários. O

contrário é mais verdadeiro, pois os sistemas necessitam de pessoas que os operam e que

precisarão se capacitar para fazê-lo. Se a introdução da automação for conduzida de modo

adequado, os funcionários terão a oportunidade de se capacitar e evoluir.

Depois de realizada a análise e definidos os processos que serão automatizados, terá

início a modelagem de dados. Caso seja necessário, as possíveis telas do sistema poderão

ser planejadas, simulando a entrada de algumas informações e possibilitando uma melhor

visualização dos dados. Depois do modelo pronto, o sistema começará a ser desenvolvido

[MATSUKI 2008].

Em seguida, poderão ser realizados os testes e o treinamento do sistema com os usuários.

Esta etapa servirá para verificar se o sistema foi desenvolvido de acordo com as necessi-



dades definidas na etapa de planejamento.

Depois de validados todos os módulos do sistema e de treinados os usuários, o sistema

poderá ser implantado. Quanto mais cuidadosos e detalhados tiverem sido os trabalhos das

etapas anteriores, mais tranqüila e suave será a etapa de implantação. É importante realizar

um acompanhamento da implantação para solucionar dúvidas que venham a ocorrer e

corrigir eventuais problemas que vierem a surgir [REGENSTEINER 1999].

2.2 Conceitos básicos de modelagem orientada a objetos

Objeto: elemento que representa algum conceito do mundo real. É uma instância de uma

classe e é capaz de armazenar estados através de seus atributos e reagir a mensagens

enviadas a ele, assim como se relacionar e enviar mensagens a outros objetos. Cada

objeto tem uma identidade única, mesmo se seu estado (valor de seus atributos) for

idêntico ao de outro objeto [FURLAN 1998].

Abstração: denota as características essenciais de um objeto que o distinguem de todos

os outros objetos e portanto, oferece limites conceituais bem definidos, relativos a

perspectiva do observador [FURLAN 1998].

Encapsulamento: ocultamento de informações. Este mecanismo é utilizado para impedir

o acesso direto ao estado de um objeto, disponibilizando externamente apenas os

métodos que alteram estes estados [WIKIPEDIA 2008].

Modularidade: divisão do sistema em módulos menores que se interligam, ficando mais

fácil compreendê-los e gerenciá-los individualmente [WIKIPEDIA 2008].

Classe: conjunto de objetos que possuem as mesmas propriedades (atributos) e o mesmo

comportamento (métodos). A classe é o conceito e o objeto é o que dá vida ao

conceito [WIKIPEDIA 2008].

Super-classe:elemento mais geral utilizado para evitar as redundâncias de descrição

[WIKIPEDIA 2008].



Sub-classe:elemento mais específico utilizado para descrever as particularidades das

classes [WIKIPEDIA 2008].

Herança: capacidade de um novo objeto tomar todos atributos e operações de um objeto

existente. A nova classe herda todas as propriedades e comportamentos da super-

classe. A nova classe é chamada de sub-classe. A linguagem Java permite organizar

tipos semelhantes de classes em categorias chamadas hierarquias de classes, onde

classes de baixo nível (sub-classes) podem usar serviços das classes mais altas na

sua hierarquia (super-classes). Todos os atributos e operações comuns ao objeto e

à classe base são herdados por seus descendentes. A herança, ou compartilhamento

de atributos e operações dentro de uma hierarquia de classes, é um dos pontos fortes

da programação orientada a objetos [FURLAN 1998].

Generalização: processo de criação de super-classes. É uma relação na qual os objetos de

um elemento especializado (um filho) pode ser substituído por objetos do elemento

geral (o pai) [FURLAN 1998].

Especialização:processo de criação de sub-classes. É especificar um caso geral de maneira

mais detalhada, até chegar ao conceito mais restrito [FURLAN 1998].

Polimorfismo: termo usado para designar o fato de uma mesma operação poder assumir

vários comportamentos, e também a capacidade de uma variável referir-se a objetos

diferentes [FURLAN 1998].

Mensagem: comunicação entre o usuário e um objeto ou entre objetos. Uma mensagem é

composta do nome do objeto que a receberá, de um seletor que representa o nome da

operação que será executada e de parâmetros definidos pela assinatura da operação

de destino [FURLAN 1998].



2.3 Tecnologias utilizadas

2.3.1 UML

A UML ( Unified Modeling Languageou Linguagem de Modelagem Unificada) surgiu

da união de três métodos de modelagem: o método de Booch, o método OMT de Ja-

cobson e o método OOSE de Rumbaugh. Estas eram, até meados da década de 90, os

três métodos de modelagem orientada a objetos mais populares entre os profissionais da

área de desenvolvimento de software. A união dessas metodologias contou com o am-

plo apoio da Rational Software, que incentivou e financiou a união das três metodologias

[MEDEIROS 2004].

A UML é uma linguagem visual utilizada para modelar sistemas computacionais por

meio do paradigma de Orientação a Objetos.

O objetivo da UML é ajudar a definir as características do software, tais como seus

requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus processos e suas

necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser im-

plantado. Todas essas características são definidas por meio da UML antes do software

começar a ser realmente desenvolvido [GUEDES 2004].

A UML é composta por diferentes tipos de diagrama, cada um representando o sistema

sob uma determinada ótica. A utilização de diversos diagramas permite que falhas sejam

descobertas, diminuindo a possibilidade da ocorrência de erros futuros.

2.3.2 Diagramas da UML

Diagrama de Casos de Uso:é o diagrama mais geral e informal da UML, sendo utilizado

normalmente nas fases de levantamento e análise de requisitos do sistema. Procura

identificar os atores que utilizarão o software e os serviços que o sistema disponibi-

lizará aos atores, conhecidos como casos de uso.

Diagrama de Classes:é o diagrama mais utilizado e o mais importante da UML. Define

a estrutura das classes utilizadas pelo sistema, determinando os atributos e métodos



de cada classe, além de estabelecer como as classes se relacionam e trocam infor-

mações entre si.

Diagrama de Objetos: fornece uma visão dos valores armazenados pelos objetos de um

Diagrama de Classes em um determinado momento da execução de um processo do

software.

Diagrama de Seqüência:preocupa-se com a ordem temporal em que as mensagens são

trocadas entre os objetos envolvidos em um determinado processo.

Diagrama de Comunicação:era conhecido como Diagrama de Colaboração até a versão

1.5 da UML, tendo seu nome modificado para Diagrama de Comunicação a partir da

versão 2.0. Esse diagrama está amplamente associado ao Diagrama de Seqüência;

na verdade, um complementa o outro. As informações mostradas no Diagrama de

Comunicação são, com freqüência, praticamente as mesmas apresentadas no Dia-

grama de Seqüência, porém com um enfoque diferente, visto que este diagrama não

se preocupa com a temporalidade do processo, concentrando-se em como os objetos

estão vinculados e quais mensagens trocam entre si durante o processo. Portanto, o

diagrama de seqüência enfatiza a seqüência no tempo e o diagrama de comunicação

enfatiza os relacionamentos entre os objetos.

Diagrama de Estados:procura representar as alterações no estado sofridas por um objeto

dentro de um determinado processo.

Diagrama de Atividades: preocupa-se em descrever os passos a serem percorridos para

a conclusão de uma atividade específica.

Diagrama de Componentes:representa os componentes do sistema quando este for ser

implementado em termos de módulos de código-fonte, bibliotecas, formulários, ar-

quivos de ajuda, módulos executáveis etc. e determina como esses componentes

estarão estruturados e interagirão para que o sistema funcione de maneira adequada.

Diagrama de Implantação: determina as necessidades de hardware do sistema, servi-

dores, estações, topologias e protocolos de comunicação.



Diagrama de Pacotes:representa os sub-sistemas englobados por um sistema de forma

a determinar as partes que o compõem.

2.3.3 Java

Java é uma linguagem de programação orientada a objetos que foi desenvolvida pela Sun

Microsystems. É antes de tudo uma linguagem simples, fortemente tipada, independente

de arquitetura, robusta, segura, extensível, bem estruturada, distribuída,multithreadede

com coletor de lixo.

Java é uma linguagem de alto nível muito parecida com C++, porém, mais simples.

Java não possui sobrecarga de operadores,structs, unions, aritmética de ponteiros, herança

múltipla, arquivos .h, diretivas de pré-processamento e a memória alocada dinamicamente

é gerenciada pela própria linguagem, que usa algoritmos de coletor de lixo para liberar

regiões de memória que não estão mais em uso.

Java é uma linguagem independente de plataforma. Isto quer dizer que um programa

em Java pode funcionar em qualquer sistema operacional. Isto é possível porque existe

uma Máquina Virtual para cada sistema operacional e que se encarrega de executar o

programa de Java.

Atualmente Java é utilizado em um amplo leque de possibilidades e praticamente qual-

quer aplicação pode ser feita em Java e muitas vezes com grandes vantagens. Com Java

pode-se programar páginas web dinâmicas, com acesso à base de dados, utilizando XML,

independentemente da conexão de rede e do sistema utilizado. Em geral, qualquer apli-

cação acessável através da web pode ser construída utilizando Java.

2.3.4 PostgreSQL

O PostgreSQL é um SGBD (Sistema Gerenciador de Banco de Dados) objeto-relacional

de código aberto, com mais de 15 anos de desenvolvimento. É extremamente robusto e

confiável, além de ser flexível e rico em recursos. Ele é considerado objeto-relacional por

implementar, além das características de um SGBD relacional, algumas características de



orientação a objetos, como herança e tipos personalizados. A equipe de desenvolvimento

do PostgreSQL sempre teve uma grande preocupação em manter a compatibilidade com

os padrões SQL92/SQL99 [POSTGRESQL 2008].

O PostgreSQL oferece muitas funcionalidades, como: comandos complexos, chaves

estrangeiras, gatilhos, visões e integridade transacional.

Além disso, o PostgreSQL pode ser ampliado pelo usuário de muitas maneiras como,

por exemplo, adicionando novos tipos de dados, funções, operadores, funções de agre-

gação e através da utilização de linguagens procedurais.


Capítulo 3

Modelagem do sistema de compras

Nesse capítulo é apresentada a modelagem do sistema desenvolvido, utilizando os con-

ceitos de modelagem orientada a objetos e de UML já apresentados no capítulo anterior.

O capítulo apresenta também a modelagem da base de dados do sistema desenvolvido.

3.1 Diagramas de caso de uso

Como apresentado anteriormente, os diagramas de caso de uso têm o objetivo de identificar

os atores que utilizarão o sistema e os serviços que serão disponibilizados a eles.

A Figura 3.1 apresenta o diagrama de caso de uso principal elaborado na modelagem

do sistema de compras. Este diagrama apresenta todas as funcionalidades do sistema.


Figura 3.1: Caso de uso principal

3.2 Fluxos de eventos

Em seguida, serão apresentados os fluxos de eventos para cada caso de uso.

Os casos de uso "Cadastro de fornecedores" e "Cadastro de materiais" são compostos

de outros casos de uso. Por esse motivo, necessitam ser melhor detalhados. As Figuras

3.2 e 3.3 apresentam, respectivamente, esses casos de uso.



Figura 3.2: Caso de uso: Cadastro de fornecedores

As seções a seguir, se referem aos casos de uso que compõem o caso de uso "Cadastro

de fornecedores".

3.2.1 Fluxo de eventos para o caso de uso "Inserir fornecedor"

Descrição: Este caso de uso aborda o procedimento adotado para o cadastro de fornece-

dores no sistema. O caso de uso se inicia quando o usuário deseja cadastrar um novo

fornecedor no sistema e finaliza quando o cadastro é realizado ou quando o usuário can-

cela o procedimento.

Pré-condições:O caso de uso "Login" deve ser executado antes que este caso de uso

se inicie.

Atores envolvidos:Usuário.



Fluxo principal: Este caso de uso se inicia após o usuário ter realizado login no

sistema. Na seqüência o usuário deve selecionar a atividade desejada: Inserir fornecedor

(IF) ou Sair (QUIT).

Se a atividade selecionada for Inserir fornecedor (IF), o sub-fluxo S-1: "Inserir fornece-

dor" será executado.

Se a atividade selecionada for Sair (QUIT) o caso de uso termina.

Sub-fluxos: S-1 "Inserir fornecedor": O sistema apresenta uma janela para entrada

dos seguintes dados: código (E1), razão social, fantasia, CNPJ, endereço, bairro, cidade,

estado, cep, telefone, fax, site e e-mail. O sistema salva os dados e o caso de uso é

reiniciado.

Fluxos alternativos: E-1: Houve uma tentativa de cadastro de um fornecedor já

cadastrado. O usuário pode fornecer um novo código ou terminar o caso de uso.

3.2.2 Fluxo de eventos para o caso de uso "Alterar fornecedor"

Descrição: Este caso de uso aborda o procedimento adotado para a alteração de algum

fornecedor cadastrado no sistema. O caso de uso se inicia quando o usuário deseja alterar

dados de um fornecedor no sistema e finaliza quando a alteração é realizada ou quando o

usuário cancela o procedimento.


se inicie.



sistema. Na seqüência o usuário deve selecionar a atividade desejada: Alterar fornecedor

(AF) ou Sair (QUIT).

Se a atividade selecionada for Alterar fornecedor (AF), o sub-fluxo S-1: "Alterar

fornecedor" será executado.


Sub-fluxos: S-1 "Alterar fornecedor": O sistema apresenta uma janela solicitando o



código (E1) do fornecedor a ser alterado. O sistema exibe uma janela para alteração dos

dados: razão social, fantasia, CNPJ, endereço, bairro, cidade, estado, cep, telefone, fax,

site e e-mail. O sistema salva os dados e o caso de uso é reiniciado.

Fluxos alternativos: E-1: Houve uma tentativa de alteração de um fornecedor não


3.2.3 Fluxo de eventos para o caso de uso "Excluir fornecedor"

Descrição:Este caso de uso aborda o procedimento adotado para a exclusão de fornece-

dores no sistema. O caso de uso se inicia quando o usuário deseja excluir um fornecedor

no sistema e finaliza quando a exclusão é concluída ou quando o usuário cancela o pro-

cedimento.


se inicie.



sistema. Na seqüência o usuário deve selecionar a atividade desejada: Excluir fornecedor

(EF) ou Sair (QUIT).

Se a atividade selecionada for Excluir fornecedor (EF), o sub-fluxo S-1: "Excluir

fornecedor" será executado.


Sub-fluxos: S-1 "Excluir fornecedor": O sistema apresenta uma janela para entrada

do código do fornecedor (E1) que deseja excluir. O sistema exibe o código e a razão social

para confirmação da exclusão. O sistema exclui o fornecedor e o caso de uso reinicia.

Fluxos alternativos: E-1: Houve uma tentativa de exclusão de um fornecedor não




Figura 3.3: Caso de uso: Cadastro de materiais

As seções a seguir, se referem aos casos de uso que compõem o caso de uso "Cadastro

de materiais".

3.2.4 Fluxo de eventos para o caso de uso "Inserir material"

Descrição:Este caso de uso aborda o procedimento adotado para o cadastro de materiais

no sistema. O caso de uso se inicia quando o usuário deseja cadastrar um novo mate-

rial no sistema e finaliza quando o cadastro é realizado ou quando o usuário cancela o

procedimento.


se inicie.





sistema. Na seqüência o usuário deve selecionar a atividade desejada: Inserir material

(IM) ou Sair (QUIT).

Se a atividade selecionada for Inserir material (IM), o sub-fluxo S-1: "Inserir mate-

rial" será executado.


Sub-fluxos: S-1 "Inserir material": O sistema apresenta uma janela para entrada dos

seguintes dados: código (E1), descrição do material, tipo e estoque mínimo. O sistema

salva os dados e o caso de uso é reiniciado.

Fluxos alternativos: E-1: Houve uma tentativa de cadastro de um material já cadastrado.

O usuário pode fornecer um novo código ou terminar o caso de uso.

3.2.5 Fluxo de eventos para o caso de uso "Alterar material"

Descrição:Este caso de uso aborda o procedimento adotado para a alteração de materiais

no sistema. O caso de uso se inicia quando o usuário deseja alterar dados de um mate-

rial no sistema e finaliza quando a alteração é realizada ou quando o usuário cancela o

procedimento.


se inicie.



sistema. Na seqüência o usuário deve selecionar a atividade desejada: Alterar material

(AM) ou Sair (QUIT).

Se a atividade selecionada for Alterar material (AM), o sub-fluxo S-1: "Alterar mate-



Sub-fluxos: S-1 "Alterar material": O sistema apresenta uma janela solicitando o

código (E1) do material a ser alterado. O sistema exibe uma janela para alteração dos



dados: descrição do material, tipo e estoque mínimo. O sistema salva os dados e o caso de

uso é reiniciado.

Fluxos alternativos: E-1: Houve uma tentativa de alteração de um material não


3.2.6 Fluxo de eventos para o caso de uso "Excluir material"

Descrição:Este caso de uso aborda o procedimento adotado para a exclusão de materiais

no sistema. O caso de uso se inicia quando o usuário deseja excluir um material no sistema

e finaliza quando a exclusão é concluída ou quando o usuário cancela o procedimento.


se inicie.



sistema. Na seqüência o usuário deve selecionar a atividade desejada: Excluir material

(EM) ou Sair (QUIT).

Se a atividade selecionada for Excluir material (EM), o sub-fluxo S-1: "Excluir mate-



Sub-fluxos: S-1 "Excluir material": O sistema apresenta uma janela para entrada do

código do material (E1) que deseja excluir. O sistema exibe o código e a descrição para

confirmação da exclusão. O sistema exclui o material e o caso de uso reinicia.

Fluxos alternativos: E-1: Houve uma tentativa de exclusão de um material não


3.2.7 Fluxo de eventos para o caso de uso "Inserir requisições"

Descrição:Este caso de uso aborda o procedimento adotado para a requisição de materi-

ais no sistema. O caso de uso se inicia quando o usuário deseja requisitar um material no

sistema e finaliza quando a requisição é realizada ou quando o usuário cancela o procedi-



mento.


se inicie.



sistema. Na seqüência o usuário deve selecionar a atividade desejada: Requisitar material

(RM) ou Sair (QUIT).

Se a atividade selecionada for Requisitar material (RM), o sub-fluxo S-1: "Requisitar

material" será executado.


Sub-fluxos: S-1 "Requisitar material": O sistema apresenta uma janela para entrada

dos seguintes dados: código (E1) do material e quantidade requisitada. O sistema salva os

dados e o caso de uso é reiniciado.

Fluxos alternativos: E-1: Houve uma tentativa de requisição de um material não

cadastrado. O usuário pode fornecer um novo código, ir para o caso de uso "Cadastrar

material" ou terminar o caso de uso.

3.2.8 Fluxo de eventos para o caso de uso "Realizar cotações"

Descrição:Este caso de uso aborda o procedimento adotado para a realização de cotações

de materiais no sistema. O caso de uso se inicia quando o usuário deseja realizar co-

tação para as requisições cadastradas no sistema e finaliza quando a cotação é realizada ou

quando o usuário cancela o procedimento.


se inicie.



sistema. Na seqüência o usuário deve selecionar a atividade desejada: Realizar cotação

(RC) ou Sair (QUIT).



Se a atividade selecionada for Realizar cotação (RC), o sub-fluxo S-1: "Realizar co-

tação" será executado.


Sub-fluxos:S-1 "Realizar cotação": O sistema apresenta uma janela para a escolha da

requisição. Em seguida, oferece uma janela para entrada dos seguintes dados: código do

fornecedor (E1), preço, forma de pagamento e prazo de entrega. O sistema salva os dados

e o caso de uso é reiniciado.

Fluxos alternativos: E-1: Houve uma tentativa de cotação de um fornecedor não


fornecedor" ou terminar o caso de uso.

3.2.9 Fluxo de eventos para o caso de uso "Efetuar compras"

Descrição:Este caso de uso aborda o procedimento adotado para a realização de compras

de materiais no sistema. O caso de uso se inicia quando o usuário deseja realizar compra

para as cotações realizadas no sistema e finaliza quando a compra é realizada ou quando o



se inicie.



sistema. Na seqüência o usuário deve selecionar a atividade desejada: Efetuar compra

(EC) ou Sair (QUIT).

Se a atividade selecionada for Efetuar compra (EC), o sub-fluxo S-1: "Efetuar com-

pra" será executado.


Sub-fluxos: S-1 "Efetuar compra": O sistema apresenta uma janela para a escolha da

cotação e confirmação da compra. O sistema salva os dados e o caso de uso é reiniciado.



3.2.10 Fluxo de eventos para o caso de uso "Receber mercadorias"

Descrição:Este caso de uso aborda o procedimento adotado para a realização de recebi-

mento de materiais no sistema. O caso de uso se inicia quando o usuário deseja receber

uma compra realizada no sistema e finaliza quando a compra é recebida ou quando o



se inicie.


Fluxo principal: Este caso de uso se inicia após o usuário ter realizado login no sis-

tema. Na seqüência o usuário deve selecionar a atividade desejada: Receber mercadorias

(RM) ou Sair (QUIT).

Se a atividade selecionada for Receber mercadorias (RM), o sub-fluxo S-1: "Receber

mercadorias" será executado.


Sub-fluxos: S-1 "Receber mercadorias": O sistema apresenta uma janela para a es-

colha da compra e confirmação das quantidades recebidas de cada material. O sistema


3.2.11 Fluxo de eventos para o caso de uso "Movimentar estoque"

Descrição:Este caso de uso aborda o procedimento adotado para a realização de entradas

e saídas no estoque de materiais no sistema. O caso de uso se inicia quando o usuário

deseja efetuar uma movimentação de estoque no sistema e finaliza quando a movimentação

é realizada ou quando o usuário cancela o procedimento.


se inicie.



sistema. Na seqüência o usuário deve selecionar a atividade desejada: Movimentar estoque



(ME) ou Sair (QUIT).

Se a atividade selecionada for Movimentar estoque (ME), o sub-fluxo S-1: "Movimen-

tar estoque" será executado.


Sub-fluxos: S-1 "Movimentar estoque": O sistema apresenta uma janela para entrada

dos seguintes dados: código (E1) do material, tipo de movimento e quantidade. O sistema


Fluxos alternativos: E-1: Houve uma tentativa de movimentação de um material não


material" ou terminar o caso de uso.

3.3 Estrutura da base de dados

A modelagem de uma base de dados exige um grande entendimento do problema a ser

solucionado. A utilização de modelos é importante para que se tenha uma visão mais clara

e também para que se possa representar formalmente a realidade analisada.

A modelagem da base de dados foi feita utilizando o software Toad Data Modeler,

anteriormente conhecido como Case Studio, que tem o intuito de auxiliar a modelagem de

dados [DEVMEDIA 2008]. As tabelas foram criadas no PostgreSQL para serem utilizadas

pelo sistema.

As tabelas que compõem o sistema são:

• Usuario : armazena a identificação ("login") e a senha de cada usuário do sistema;

• Fornecedor : armazena dados cadastrais dos fornecedores da empresa;

• Material : armazena os materiais de consumo e as matérias-primas que a empresa

utiliza. O atributo tipo define se é material ou matéria-prima;

• MaterialFornecedor : armazena os materiais fornecidos para cada um dos

fornecedores;



• MovimentoEstoque : armazena as entradas e saídas de estoque de cada material;

• Requisicao : armazena as requisições dos funcionários da empresa;

• Cotacao : armazena as cotações realizadas no sistema;

• ItemCotacao : armazena os itens cotados junto aos fornecedores;

• CotacaoRequisicao : relaciona o material requisitado com o material cotado.

A Figura 3.4 mostra a modelagem de dados realizada para o sistema desenvolvido.

Figura 3.4: Modelagem de dados


Capítulo 4

Funcionamento do sistema

Nesse capítulo apresenta-se o funcionamento do sistema desenvolvido, através da apre-

sentação de suas telas.

4.1 Tela inicial

A Figura 4.1 apresenta a página inicial do sistema. O usuário deverá digitar seu "login" e

senha, e clicar no botãoAcessar . Se o login digitado já estiver cadastrado e a senha

estiver correta, o usuário terá acesso ao menu principal do sistema.

Figura 4.1: Tela inicial


A Figura 4.2 apresenta os sub-items do menu Cadastros. Esses sub-items serão apre-

sentados nas seções de 4.2 a 4.4.

Figura 4.2: Menu Cadastros

A Figura 4.3 apresenta os sub-items do menu Processos. Esses sub-items serão apre-

sentados nas seções de 4.5 a 4.8.

Figura 4.3: Menu Processos

4.2 Botões

A figura 4.4 apresenta os botões existentes nas telas do sistema.



Figura 4.4: Botões

4.3 Cadastro de Usuários

A Figura 4.5 apresenta a tela de cadastro de usuário. Essa tela é acessada através do menu

Cadastros -> Usuário .

Figura 4.5: Cadastro de Usuários

A tela de Cadastro de Usuários mostra todos os usuários cadastrados. Para inserir um

novo registro, o usuário deve clicar no botãoNovo e preencher os campos requisitados.

Em seguida, clicar no botãoSalvar . Caso já exista um usuário cadastrado com o mesmo

login, o sistema apresentará uma mensagem informando e requisitando que seja digitado



outro login. o sistema apresentará mensagem também caso algum campo obrigatório não

tenha sido digitado.

O sistema também oferece a opção de pesquisar algum usuário cadastrado. Para isso,

deve-se clicar no botãoPesquisar , que está ao lado do campo login. O sistema vai abrir

uma tela para o usuário digitar o login que se deseja pesquisar. A Figura 4.6 mostra essa

tela de pesquisa. Depois de digitar o login, o usuário deve clicar no botãoOK. Se este login

não estiver cadastrado, o sistema apresentará uma mensagem de erro. Caso contrário, o

sistema apresentará as informações referentes ao registro localizado.

Figura 4.6: Pesquisar por login

O botãoImprimir oferece um relatório de todos os usuários cadastrados. A Figura

4.7 mostra um exemplo desse relatório.

Figura 4.7: Relatório de Usuários



4.4 Cadastro de Materiais

A Figura 4.8 apresenta a tela de cadastro de matéria-prima e material de consumo. Essa

tela é acessada através do menuCadastros -> Material .

Figura 4.8: Cadastro de Materiais

A tela de Cadastro de Materiais mostra todos os materiais cadastrados. Para inserir um

novo registro, o usuário deve clicar no botãoNovo e preencher os campos requisitados.

Em seguida, clicar no botãoSalvar . Caso algum campo obrigatório não tenha sido

digitado, o sistema exibirá uma mensagem solicitando o preenchimento desse campo.

O sistema também oferece a opção de pesquisar alguma matéria-prima ou material

de consumo pelo código ou pela descrição. Para pesquisar por código, deve-se clicar no

botãoPesquisar , que está ao lado do campo código. Para pesquisar por descrição,

deve-se clicar no botãoPesquisar , que está ao lado do campo descrição. O sistema

vai abrir uma tela para o usuário pesquisar o que se deseja. A Figura 4.9 apresenta a tela



de pesquisa por descrição. Depois de digitar a descrição, o usuário deve clicar no botão

OK. Se não houver cadastrado nenhum material com essa descrição, o sistema apresentará

uma mensagem de erro. Caso contrário, o sistema apresentará as informações referentes

ao registro localizado.

Figura 4.9: Pesquisar por descrição

O usuário pode alterar qualquer registro cadastrado e em seguida, clicar no botão

Salvar .

Para excluir algum material cadastrado, deve-se clicar no botãoExcluir .

O botãoCancelar cancela qualquer operação que esteja sendo executada pelo usuário.

O botãoImprimir oferece um relatório de todas as matérias-primas e materiais de

consumo cadastrados. A Figura 4.10 mostra um exemplo desse relatório.

Figura 4.10: Relatório de Materiais



4.5 Cadastro de Fornecedores

A Figura 4.11 apresenta a tela de cadastro de fornecedor. Essa tela é acessada através do

menuCadastros -> Fornecedor .

Figura 4.11: Cadastro de Fornecedores

A tela de Cadastro de Fornecedores mostra todos os fornecedores cadastrados. Para

inserir um novo registro, o usuário deve clicar no botãoNovo e preencher os campos

requisitados. Em seguida, clicar no botãoSalvar . Caso algum campo obrigatório não

tenha sido digitado, o sistema exibirá uma mensagem solicitando o preenchimento desse

campo.

O sistema também oferece a opção de pesquisar algum fornecedor pelo código ou



pela razão social. Para pesquisar por código, deve-se clicar no botãoPesquisar , que

está ao lado do campo código. Para pesquisar por razão social, deve-se clicar no botão

Pesquisar , que está ao lado do campo razão social. O sistema vai abrir uma tela para

o usuário pesquisar o que se deseja. A Figura 4.12 apresenta a tela de pesquisa por razão

social.

Figura 4.12: Pesquisar por razão social


Salvar .

Para excluir algum fornecedor cadastrado, deve-se clicar no botãoExcluir .


O botãoImprimir oferece um relatório de todos os fornecedores cadastrados. A

Figura 4.13 mostra um exemplo desse relatório.

Figura 4.13: Relatório de Fornecedores



4.6 Requisição de Material

A Figura 4.14 apresenta a tela de requisição de matéria-prima e material de consumo. Essa

tela é acessada através do menuProcessos -> Requisição .

Figura 4.14: Requisição de Material

A tela de Requisição de Material mostra todos as requisições cadastradas no sistema.

As requisições possuem três "status" diferentes. Quando o usuário faz uma nova requi-

sição, ela fica com o status "A". Quando é realizada alguma cotação para ela, a requisição

fica com o status "C". E quando essa cotação gera uma compra, a requisição fica com

status "E". O usuário só pode alterar e excluir requisições com status "A".

Para inserir um novo registro, o usuário deve clicar no botãoNovo e preencher os cam-

pos requisitados. Em seguida, clicar no botãoSalvar . Caso algum campo obrigatório

não tenha sido digitado, o sistema exibirá uma mensagem solicitando o preenchimento

desse campo.



O sistema também oferece a opção de pesquisar alguma requisição pelo código. Para

isso, deve-se clicar no botãoPesquisar , que está ao lado do campo código. O sistema

vai abrir uma tela para o usuário pesquisar o que se deseja. Depois de digitar o código

da requisição, o usuário deve clicar no botãoOK. Se não tiver nenhuma requisição com

esse código, o sistema apresentará uma mensagem de erro. Caso contrário, o sistema

apresentará as informações referentes ao registro localizado.


Salvar .

Para excluir alguma requisição, deve-se clicar no botãoExcluir .


O botãoImprimir oferece um relatório de todas as requisições. A Figura 4.15

mostra um exemplo desse relatório.

Figura 4.15: Relatório de Requisições



4.7 Cotação de Material

A Figura 4.16 apresenta a tela utilizada para realizar a cotação de matéria-prima e material

de consumo. Essa tela é acessada através do menuProcessos -> Cotação .

Figura 4.16: Cotações

A tela de Cotação de Material mostra todas as cotações realizadas no sistema. As

cotações possuem três status diferentes. Quando o usuário faz uma nova cotação, ela fica

com o status "A". Quando ela gera uma compra, a cotação fica com o status "C". E

quando essa compra é recebida e é dado entrada em estoque dos materiais, a cotação fica

com status "E". O usuário só pode alterar e excluir cotações com status "A".

Para inserir um novo registro, o usuário deve clicar no botãoNovo e preencher os cam-

pos requisitados. Em seguida, clicar no botãoSalvar . Caso algum campo obrigatório

não tenha sido digitado, o sistema exibirá uma mensagem solicitando o preenchimento

desse campo.

Depois de preencher as informações da cotação, como fornecedor, prazo de entrega

e forma de pagamento, o usuário deve incluir os materiais requisitados na cotação. Para



isso, ele deve selecionar o material na gradeRequisições em Aberto e enviar para

a gradeItens da Cotação . A gradeRequisições em Aberto apresenta todas

as requisições que ainda não foram compradas.

Para excluir algum material da Cotação, ele deve selecionar o material na gradeItens

da Cotação e enviar para a gradeRequisições em Aberto .


Salvar .

Para excluir alguma cotação, deve-se clicar no botãoExcluir .


O botãoImprimir oferece um relatório de todas as requisições. A Figura 4.17

mostra um exemplo desse relatório.

Figura 4.17: Relatório de Cotações



Para realizar uma compra da cotação, o usuário deve clicar no botãoEfetuar Compra .

O sistema irá alterar o status da cotação para "C".

4.8 Compras

A Figura 4.18 apresenta a tela de compras. Essa tela é acessada através do menuProces-

sos -> Compra .

Figura 4.18: Compra

A tela de Compras mostra todas as compras realizadas no sistema. Uma compra só

pode ser realizada a partir de uma cotação realizada antes. Nessa tela, não é possivel

alterar nem excluir as compras.

A gradeItens da Compra , mostra todos os materiais pertencentes a essa com-

pra. As informações mostradas são: Código Material, Descrição do Material, Quantidade,



Quantidade Recebida, Preço e Preço Total. A informação Quantidade mostra as quanti-

dades que foram compradas. A informação Quantidade Recebida será destinada para o

usuário digitar as quantidades que realmente forem recebidas.

Quando as mercadorias chegarem à empresa, o usuário deverá digitar as quantidades

recebidas nessa grade, e em seguida, clicar no botãoReceber Mercadorias .

O sistema dará entrada em estoque de todos os materiais recebidos, atualizando a quan-

tidade em estoque. O sistema atualizará também o campo último preço do material. O

status da compra ficará "E".

O botãoImprimir oferece um relatório de todas as compras do sistema. A Figura


Figura 4.19: Relatório de Compras



4.9 Movimento de Estoque

A Figura 4.20 apresenta a tela de movimento de estoque. Essa tela é acessada através do

menuProcessos -> Movimento Estoque .

Figura 4.20: Movimento de Estoque

A tela de Movimento de Estoque mostra todos os movimentos realizados. Para realizar

um novo movimento de estoque, o usuário deve clicar no botãoNovo e preencher os cam-

pos requisitados. Em seguida, clicar no botãoSalvar . O sistema atualizará a quantidade

em estoque do material escolhido.

Se o usuário estiver realizando uma saída de estoque, o sistema irá verificar se o ma-

terial possui em estoque a quantidade desejada. Se não possuir, o sistema não efetuará a

saída de estoque.

O usuário não pode alterar nem excluir nenhuma movimentação de estoque.


O botãoImprimir oferece um relatório de todos os movimentos realizados. A Figura




Figura 4.21: Relatório de Movimento de Estoque


Capítulo 5

Conclusão

Esse trabalho apresentou todas as etapas do desenvolvimento de um sistema para uma

fábrica de alimentos, desde o levantamento e análise de requisitos, até o desenvolvimento

do sistema em si.

Com os conceitos de modelagem orientada a objetos e também de UML, foi realizada

a modelagem do sistema em questão. De posse dessa modelagem, foi possível desenvolver

um sistema para auxiliar os funcionários no seu dia-a-dia, a controlar as operações envolvi-

das no processo de compras e a oferecer aos diretores informações precisas da situação da

empresa.

Com o sistema desenvolvido, foi realizada uma apresentação de seu funcionamento

para todos os funcionários envolvidos. O módulo desenvolvido foi aprovado, pois atende

a todas as necessidades pedidas, como: cadastro de fornecedor, matéria-prima e mate-

rial de consumo, requisições de compra, cotações, compras e movimentações de estoque.

Em seguida, serão realizados testes do sistema junto aos usuários. Depois de concluídos

os testes, o sistema será implantado na empresa, começando pelo cadastro dos usuários,

matérias-primas, materiais de consumo e fornecedores. Depois de todos os usuários treina-

dos e de completados os cadastros, o sistema desenvolvido começará a ser utilizado.

Com a realização desse trabalho, constatou-se como é importante considerar todas

as etapas no desenvolvimento de um sistema. Levantar e analisar requisitos, conversar

com os usuários, analisar as necessidades descobertas e modelar o sistema são etapas


muito importantes e que servem como base para o desenvolvimento de um sistema. Além

disso, ter a documentação do sistema auxilia quando há a necessidade de manutenção. A

documentação auxilia também na adição de novos módulos ao sistema.

Esse trabalho deixa como proposta, o desenvolvimento de novos módulos, como o de

"contas a pagar" e o de "produção", que podem complementar o sistema desenvolvido até

o momento.

O módulo de "contas a pagar" deverá controlar os pagamentos das compras realizadas

junto aos fornecedores.

O módulo de "produção" deverá controlar a transformação das matérias-primas em

produto acabado. Cada produto deverá ter sua composição cadastrada e a cada produção

realizada, deverá ser feita a saída de estoque das matérias-primas utilizadas.

O acoplamento de novos módulos a esse de compras já desenvolvido, só trará benefí-

cios para a empresa, automatizando outros processos e auxiliando os funcionários em seus

trabalhos, além de proporcionar à empresa um maior controle de seu empreendimento.


Referências Bibliográficas

[DEVMEDIA 2008]DEVMEDIA. Devmedia. Disponível em:

<http://www.devmedia.com.br>. Acesso em 19 junho 2008.

[FURLAN 1998]FURLAN, J. D. Modelagem de objetos através da UML. 1. ed. São

Paulo: MAKRON Books, 1998. 329.

[GUEDES 2004]GUEDES, G. T. A.UML - Uma abordagem prática. 1. ed. São Paulo:

Novatec, 2004. 319.

[LAUDON e LAUDON 1999]LAUDON, K. C.; LAUDON, J. P.Sistemas de informação.

4. ed. Rio de Janeiro: LTC, 1999. 389.

[LEME FILHO 2003]LEME FILHO, T. Metodologia de desenvolvimento de sistemas. 1.

ed. Rio de Janeiro: Axcel Books, 2003. 154.

[MATSUKI 2008]MATSUKI, C. T. Modelagem de dados.SQL Magazine, v. 5, n. 51, p.

48–49, 2008.

[MEDEIROS 2004]MEDEIROS, E. S.Desenvolvendo software com UML 2.0. 1. ed. São

Paulo: MAKRON Books, 2004. 264.

[POSTGRESQL 2008]POSTGRESQL. Postgresql-br. Disponível em:

<http://www.postgresql.org.br>. Acesso em 14 janeiro 2008.

[REGENSTEINER 1999]REGENSTEINER, R. J.Elementos básicos para o planeja-

mento da automação do varejo. 1. ed. São Paulo: SENAC, 1999. 106.


[STAIR 1998]STAIR, R. M. Princípios de sistemas de informação. 2. ed. Rio de Janeiro:

LTC, 1998. 451.

[WIKIPEDIA 2008]WIKIPEDIA. Wikipedia. Disponível em: <http://pt.wikipedia.org>.

Acesso em 11 março 2008.


Modelagem de Banco de Dados

Documents

Transcript of Modelagem de Banco de Dados