Modelagem de Banco de Dados

FACULDADE DE E NGENHARIA DE G UARATINGUETÁ
E SPECIALIZAÇÃO EM I NFORMÁTICA E MPRESARIAL
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 Language ou 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, multithreaded e
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ão Acessar. 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ão Novo e preencher os campos requisitados.
Em seguida, clicar no botão Salvar. 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ão Pesquisar, 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ão OK. 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ão Imprimir 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 menu Cadastros -> 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ão Novo e preencher os campos requisitados.
Em seguida, clicar no botão Salvar. 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ão Pesquisar, que está ao lado do campo código. Para pesquisar por descrição,
deve-se clicar no botão Pesquisar, 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ão Excluir.
O botão Cancelar cancela qualquer operação que esteja sendo executada pelo usuário.
O botão Imprimir 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
menu Cadastros -> 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ão Novo e preencher os campos
requisitados. Em seguida, clicar no botão Salvar. 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ão Pesquisar, 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ão Excluir.
O botão Imprimir 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 menu Processos -> 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ão Novo e preencher os cam-
pos requisitados. Em seguida, clicar no botão Salvar. 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ão Pesquisar, 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ão OK. 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ão Excluir.
O botão Imprimir 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 menu Processos -> 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ão Novo e preencher os cam-
pos requisitados. Em seguida, clicar no botão Salvar. 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 grade Requisições em Aberto e enviar para
a grade Itens da Cotação. A grade Requisiçõ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 grade Itens
da Cotação e enviar para a grade Requisições em Aberto.

Salvar.
Para excluir alguma cotação, deve-se clicar no botão Excluir.
O botão Imprimir 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ão Efetuar 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 menu Proces-
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 grade Itens 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ão Receber 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ão Imprimir 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
menu Processos -> 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ão Novo e preencher os cam-
pos requisitados. Em seguida, clicar no botão Salvar. 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ão Imprimir 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

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Modelagem de Banco de Dados

Загружено:

Авторское право:

Доступные форматы

FACULDADE DE E NGENHARIA DE G UARATINGUETÁ

E SPECIALIZAÇÃO EM I NFORMÁTICA E MPRESARIAL

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

Andréa Silva de Oliveira

Andréa Silva de Oliveira

Monografia apresentada à Faculdade de Engenharia de

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

Oliveira, Andréa Silva de

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

Andréa Silva de Oliveira

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

FILIAÇÃO: Paulo Afonso Pinto de Oliveira

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

Dedico esse trabalho ao meu pai,

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

UNESP/FEG-CEIE, 2008 iii

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.2 Diagramas da UML . . . . . . . . . . . . . . . . . . . . . . . . . 12

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.1 Tela inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

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.9 Movimento de Estoque . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

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