PROPOSTA DE IMPLEMENTAÇÃO DE UM SISTEMA DE CONTROLE DE
ESTOQUE NO ARMAZÉM DA FACULDADE DE CIÊNCIAS DE SAÚDE
(UCM)
Inácio Augusto Belo
UNIVERSIDADE ZAMBEZE
FACULDADE DE CIÊNCIAS E TECNOLOGIA
ENGENHARIA INFORMÁTICA
PROPOSTA DE IMPLEMENTAÇÃO DE UM SISTEMA DE CONTROLE DE
ESTOQUE NO ARMAZÉM DA FACULDADE DE CIÊNCIAS DE SAÚDE
(UCM)
INÁCIO AUGUSTO BELO
BEIRA
2016
UNIVERSIDADE ZAMBEZE
FACULDADE DE CIÊNCIAS E TECNOLOGIA
ENGENHARIA INFORMÁTICA
PROPOSTA DE IMPLEMENTAÇÃO DE UM SISTEMA DE CONTROLE DE
ESTOQUE NO ARMAZÉM DA FACULDADE DE CIÊNCIAS DE SAÚDE
(UCM)
INÁCIO AUGUSTO BELO
Monografia submetida à Faculdade de
Ciências e Tecnologias, Universidade
Zambeze – Beira, como requisito parcial à
obtenção do grau de Licenciatura em
Engenharia Informática.
Orientador:
Msc. Eng. Amílcar Borráz Gonzaléz
BEIRA
2016
DECLARAÇÃO
Eu, Inácio Augusto Belo declaro por minha honra que esta monografia é resultado do
meu próprio trabalho, fruto do meu esforço, da minha investigação que foi embasada na
revisão bibliográfica e está a ser submetida para a obtenção do grau de Licenciatura na
Universidade Zambeze, Beira. Ela não foi submetida antes para obtenção de nenhum grau
ou para avaliação em nenhuma outra universidade.
________________________________
Inácio Augusto Belo
_________ de ________________________2016
DEDICATÓRIA
Dedico este trabalho ao meu pai Augusto Belo (em memória) e a minha mãe
Zenha Costa pelo amor e valores que me transmitiram, por sempre terem apostado em
mim e transmitido um precioso legado de boa educação, aos meus irmãos que sempre me
deram força nos momentos que mais precisei e pela amizade incondicional.
AGRADECIMENTOS
Em primeiro lugar, agradeço à Deus que me deu a força e que foi sempre fiel em
tudo para que não pudesse desistir em cada momento difícil que eu passei durante a minha
formação. Em segundo, à minha família que me apoiou em todos momentos de tribulação
que passei durante a formação e desenvolvimento deste projecto. Pelo apoio que me foi
dado, em todos os anos da minha vida e durante a cada um dos momentos desta formação
superior, com muita força e dedicação, da qual foi de extrema importância para que
conseguisse chegar até este momento.
Meu agradecimento especial vai aos meus pais, que não apenas deram-me a vida,
mas também a educação necessária para a compreensão do significado de
responsabilidade e de virtude para a vida humana.
Ao meu orientador Amílcar Borráz González, pela atenção oferecida durante o
curso em cada uma das cadeiras do curso leccionadas por ele como professor e em
especial no desenvolvimento deste trabalho, sempre contribuindo com seus
conhecimentos e conselhos nos momentos de dificuldades durante o percurso.
EPÍGRAFE
“Todo mundo deveria saber como programar um computador porque isso ensina você
como pensar”.
Steve Jobs
SUMÁRIO
RESUMO .......................................................................................................................... I
ABSTRACT ....................................................................................................................... II
LISTA DE FIGURAS .................................................................................................... III
LISTA DE TABELAS ..................................................................................................... V
LISTA DE SIGLA E ABREVIATURAS ...................................................................... VI
INTRODUÇÃO ................................................................................................................ 1
METODOLOGIA ............................................................................................................. 5
CAPÍTULO I - FUNDAMENTAÇÃO TEÓRICA .......................................................... 9
1.1 FUNDAMENTAÇÃO DO PROCESSO DE INFORMATIZAÇÃO DE
ARMAZÉNS ................................................................................................................. 9
1.2 SISTEMAS DE INFORMAÇÃO ..................................................................... 11
1.3 A RELAÇÃO DE DADOS E INFORMAÇÃO COM O SI ............................. 15
1.4 NÍVEIS E TIPOS DE SISTEMAS DE INFORMAÇÃO ................................. 16
1.5 SISTEMAS DE CONTROLE DE ESTOQUES ............................................... 18
1.5.1 CONTROLE DE ESTOQUE ................................................................... 18
1.5.2 ESTOQUE ................................................................................................ 19
1.5.3 FUNÇÕES DE ESTOQUE ...................................................................... 20
1.5.4 CLASSIFICAÇÃO DE ESTOQUES ....................................................... 20
1.5.5 MÉTODOS DE AVALIAÇÃO DE ESTOQUE ...................................... 21
1.6 CARACTERIZAÇÃO DO ESTADO ACTUAL DO PROCESSO DE
INFORMAÇÃO DO ARMAZÉM .............................................................................. 22
1.6.1 PROPOSTA DO TRABALHO ................................................................ 24
1.6.2 POR QUE USAR O SISTEMA PROPOSTO? ........................................ 24
1.7 PRINCIPAIS TECNOLOGIAS E FERRAMENTAS UTILIZADAS ............. 25
1.8 METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE ............... 37
1.8.1 METODOLOGIAS DE DESENVOLVIMENTO TRADICIONAIS ...... 38
1.8.2 METODOLOGIAS DE DESENVOLVIMENTO ÁGEIS ....................... 42
1.8.3 COMPARAÇÃO ENTRE METODOLOGIAS ....................................... 44
1.9 CONCLUSÕES DO CAPÍTULO ..................................................................... 45
CAPÍTULO II – DESENVOLVIMENTO DE SISTEMA ............................................. 47
2.1 REQUISITOS FUNCIONAIS DO SISTEMA ................................................. 47
2.2 REQUISITOS NÃO FUNCIONAIS DO SISTEMA ....................................... 49
2.3 ACTORES DO SISTEMA ............................................................................... 50
2.4 DIAGRAMAS DE CASO DE USO DO SISTEMA ........................................ 50
2.5 DIAGRAMA DE ACTIVIDADES .................................................................. 64
2.6 DIAGRAMA DE SEQUÊNCIA ...................................................................... 66
2.7 DIAGRAMA DE CLASSES DO SISTEMA ................................................... 67
2.8 DIAGRAMA ENTIDADE RELACIONAL DO SISTEMA ............................ 69
2.9 DIAGRAMA DE IMPLANTAÇÃO DO SISTEMA ....................................... 70
2.10 APLICAÇÃO DO SISTEMA ....................................................................... 72
2.10.1 UTILIZAÇÃO DO SISTEMA ................................................................. 72
2.10.2 ACESSO AO SISTEMA .......................................................................... 72
2.10.3 TELA INICIAL DO SISTEMA ............................................................... 73
2.11 CONCLUSÕES DO CAPÍTULO ................................................................. 77
CONCLUSÕES E RECOMENDAÇÕES ...................................................................... 78
REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................... 80
ANEXOS ........................................................................................................................ 84
ANEXO I ..................................................................................................................... 84
ANEXO II ................................................................................................................... 86
ANEXO III .................................................................................................................. 87
ANEXO IV .................................................................................................................. 88
I
RESUMO
Nos últimos dias, as empresas ou organizações têm demandado pela tecnologia de
informação para continuarem mais competitivas e organizadas. Utilizando os sistemas de
informação, as empresas obrigatoriamente estão a deixar de usar padrão departamental e
a engrenar para um padrão integrado de gestão e produção. Em consonância com isso,
nos últimos dias, os sistemas de informação estão a passar por um crescimento
assinalável, com vista a atender as necessidades que o mercado dia após dia relata. A
inexistência de um sistema informatizado para este controle tem ocasionado muitas
inconsistências e redundância de informação, além de atrasos para se obter informações
importantes para a tomada de decisões. Nesta vertente, a utilização de um sistema de
controle é imperiosa para permitir a integridade da informação do armazém, permitindo
assim a organização de informação de uma maneira racional, ágil e principalmente para
recuperar esta informação e distribuí-la a quem precisa, tornando assim a rotina do
trabalho mais ágil e eficiente. A presente monografia tem como objectivo o
desenvolvimento de um sistema para controle de estoque de modo a informatizar as
principais actividades do armazém, provendo as informações armazenadas, condições
para um controle de estoque mais aperfeiçoado, preciso e verídico. O sistema abarca as
funcionalidades como Autenticação de Utilizador, Cadastro de Material, Gestão de
estoque, Gestão de requisição, Gestão de Entradas e Emissão de Relatórios. O sistema foi
implementado na linguagem Java por meio de um IDE NetBeans 8.1, com programação
orientada a objectos.
Palavras Chaves: Sistema de Informação, Estoque, Controle de Estoque,
Metodologias de Desenvolvimento de Software e Extreme Programming.
II
ABSTRACT
In recent days, the companies or organizations have sued by information
technology to continue more competitive and organized. Using the information systems,
companies are compulsorily to cease using standard departmental and engage for a
standard integrated management and production. In line with this, in recent days, the
information systems are going through a strong growth, with a view to meet the needs
that the market day after day reports. The lack of a computerized system for this control
has caused many inconsistencies and redundancy of information, besides delays to get
important information for decision making. In this aspect, the use of a system of control
is imperative to allow the integrity of the Information Warehouse, thus allowing the
organization of information in a rational manner, agile and mainly to retrieve this
information and distribute it to those who need it, thus making the routine of work more
efficient and responsive. This monograph has as its objective the development of a system
for the control of inventory to computerize the main activities of the warehouse, providing
the information stored, the conditions for a more streamlined inventory control, accurate
and truthful. The system covers the features such as User Authentication, Register of
material, inventory management, Requisition Management, Management of entries and
reporting. The system was implemented in the Java language through a NetBeans IDE
8.1, with objects oriented programming.
Key words: Information System, inventory, inventory control, methodologies of Software
Development and Extreme Programming.
III
LISTA DE FIGURAS
FIGURA 1: FUNÇÕES DE UM SISTEMA DE INFORMAÇÃO. .................................................. 12
FIGURA 2: CLASSIFICAÇÃO DOS SISTEMAS DA INFORMAÇÃO .......................................... 16
FIGURA 3: MODELO CLIENTE/SERVIDOR.. ....................................................................... 30
FIGURA 4: DIAGRAMA DE CASOS DE USO ........................................................................ 34
FIGURA 5: EXEMPLO DE DIAGRAMA DE ACTIVIDADES .................................................... 35
FIGURA 6: EXEMPLO DE DIAGRAMA DE SEQUÊNCIA. ....................................................... 35
FIGURA 7: EXEMPLO DE DIAGRAMA DE CLASSES.. .......................................................... 36
FIGURA 8: EXEMPLO DE DIAGRAMA DE IMPLANTAÇÃO ................................................... 37
FIGURA 9: FASES DO PROCESSO UNIFICADO (RUP) ......................................................... 41
FIGURA 10: DIAGRAMA DE CASOS DE USO DO SISTEMA. ................................................. 51
FIGURA 11: DIAGRAMA DE CASOS DE USO GERIR ENTRADAS E REQUISIÇÕES. ................. 52
FIGURA 12: DIAGRAMA DE CASOS DE USO DE GERIR ESTOQUE E EMITIR RELATÓRIOS. .... 53
FIGURA 13: DIAGRAMA DE ACTIVIDADES DO CASO DE USO GERIR REQUISIÇÃO. ............. 65
FIGURA 14: DIAGRAMA DE SEQUÊNCIA DA GESTÃO DE REQUISIÇÃO. .............................. 66
FIGURA 15: DIAGRAMA DE CLASSES DO SISTEMA. .......................................................... 68
FIGURA 16: MODELO ENTIDADE RELACIONAMENTO DO SISTEMA. .................................. 70
FIGURA 17: DIAGRAMA DE IMPLANTAÇÃO DO SISTEMA. ................................................. 71
FIGURA 18: TELA DE ACESSO AO SISTEMA. ..................................................................... 72
FIGURA 19: TELA DE AUTENTICAÇÃO COM DADOS DO UTILIZADOR INCORRECTOS. ........ 73
FIGURA 20: TELA INICIAL DO SISTEMA SICE.. ................................................................ 74
FIGURA 21: TELA DE CADASTRO DE REQUISIÇÃO. ........................................................... 75
IV
FIGURA 22: TELA DE CADASTRO DE ENTRADA DE MATERIAL. ......................................... 75
FIGURA 23: RELATÓRIO DE REQUISIÇÃO DE MATERIAL. .................................................. 76
FIGURA 24: RELATÓRIO DA ENTRADA DE MATERIAL. ..................................................... 76
V
LISTA DE TABELAS
TABELA 1: CASO DE USO AUTENTICAR UTILIZADOR........................................................ 55
TABELA 2: CASO DE USO ALTERAR SENHA.. .................................................................... 55
TABELA 3: CASO DE USO GERIR ENTRADAS..................................................................... 57
TABELA 4: CASO DE USO GERIR REQUISIÇÕES.. ............................................................... 58
TABELA 5: CASO DE USO CRIAR MATERIAL.. ................................................................... 59
TABELA 6: CASO DE USO ALTERAR MATERIAL.. .............................................................. 60
TABELA 7: CASO DE USO PESQUISAR MATERIAL.. ........................................................... 61
TABELA 8: CASO DE USO EXCLUIR MATERIAL. ................................................................ 61
TABELA 9: CASO DE USO CRIAR NOVO UTILIZADOR.. ..................................................... 62
TABELA 10: CASO DE USO ALTERAR UTILIZADOR.. ......................................................... 62
TABELA 11: CASO DE USO EXCLUIR UTILIZADOR.. .......................................................... 63
TABELA 12: CASO DE USO SAIR DO SISTEMA.. ................................................................. 64
VI
LISTA DE SIGLA E ABREVIATURAS
EA Enterprise Architect
ERP Enterprise Resources Planning
FIFO First In, First Out
FCS Faculdade de Ciências de Saúde
IDE Integrated Development Environment
JEE Java Enterprise Edition
JSE Java Standard Edition
LIFO Last In, Last Out
PHP Hypertext Preprocessor
PEPS Primeiro a Entrar, Primeiro a Sair
RUP Rational Unified Process
RN Regra de Negócio
RF Requisito Funcional
RNF Requisito Não Funcional
TI Tecnologia de Informação
SI Sistema de Informação
VII
SICE Sistema de Informação para Controle de Estoque
SQL Strutured Query Language (Linguagem de Consulta Estruturada)
SPT Sistemas de Processamento de Transações
SIG Sistemas de Informações Gerenciais
SAD Sistemas de Apoio a Decisão
SGC Sistemas de gestão de conhecimentos
SGBD Sistema Gerenciador de Banco de Dados
SAE Sistemas de apoio ao executivo
UEPS Último a Entrar, Primeiro a Sair
UML Unfied Modified Language (Linguagem de Modelagem Unificada)
XP Extreme Programing
1
INTRODUÇÃO
Nos dias que correm, a informação é considerada o bem mais precioso de uma
organização. Informação esta que estando permanentemente actualizada, correcta e
relevante contribui para uma maior competitividade, o que, num mundo empresarial com
níveis de concorrência nunca antes atingidos, pode significar a diferença entre o lucro e
o prejuízo. Para além das características da actualidade, da correcção e da relevância, a
informação deve estar sempre disponível e interpretável, para que esta possa fazer parte
do processo de tomada de decisão de um modo eficaz. Com isso, qualquer organização
que queira destacar-se da concorrência e assim segurar o seu sucesso, terá que investir
nos seus métodos de controle da sua informação. A melhor forma de o fazer, é sem dúvida
reforçar a qualidade e eficiência no controle da informação, de forma a reforçar a
flexibilidade das actividades da empresa.
Uma das maneiras de aumentar a flexibilidade das actividades se demonstra a
partir do ambiente da empresa, a organização que ela mantém, bem como pela
preocupação que a empresa tem em investir nos métodos de controle desde de seus
processos até a informação. Cada vez mais cresce o número de empresas que buscam
novas tecnologias e aplicativos para melhor organizar e inovar seu negócio, tornando
desta forma uma melhor maneira de bem controlar a sua informação. A inovação no
negócio pode ser uma grande oportunidade para crescer, e principalmente para manter os
dados dos serviços prestados e informação bem organizados e acessíveis. Actualmente
vive-se um momento em que a gestão da informação é extremamente importante para
todo e qualquer tipo de negócio, desde grandes empresas ou instituições até mesmo as de
2
pequeno porte. Porém, pequenas empresas têm grande dificuldade em gerir seu negócio
por falta de um sistema que faça isso e mantenha as informações actualizadas.
De acordo com (Sêmola, 2003) a informação representa a inteligência competitiva
dos negócios e é reconhecida como activo crítico para continuidade operacional e saúde
empresarial. A informação e o conhecimento serão os diferenciais das empresas e dos
profissionais que pretendem destacar-se no mercado e manter a sua competitividade
(Rezende e Abreu, 2000). Neste contexto, as empresas já perceberam que o domínio da
tecnologia como aliado para fazer face a gestão da informação é vital. No entanto, dispor
da informação correcta, na hora adequada, significa tomar uma decisão de forma ágil e
eficiente. Por conta da evolução dos sistemas, a informação ganhou a mobilidade,
inteligência e real capacidade de gestão.
Com o aumento da procura pela eficiência, consequentemente as organizações são
obrigadas a sofisticar as suas ferramentas de trabalho com vista a fazer face a vantagem
competitiva que é exigida pelo mercado empresarial. Verifica-se que hoje a maioria das
empresas continua a utilizar métodos obsoletos, onde o uso de papel como suporte de
registo de informação é a principal característica, razão pela qual contribui para existência
de algumas limitações de gestão de informação e fornecimento de mais serviços.
Diante das incessantes mudanças é necessário que as empresas tenham
flexibilidade, dinamismo, agilidade, adaptabilidade, persistência contínua para obterem
melhores resultados das suas actividades, pois continuarão no mercado somente aquelas
que estiverem munidas de recursos para a gestão eficiente de seus negócios.
A complexidade do mercado a cada dia está mais acirrada, de forma que as
empresas busquem continuamente inovações tecnológicas e de gestão com o intuito de
3
diminuírem custos e aprimorarem a qualidade de seus produtos, focalizando suas atenções
na obtenção de vantagem competitiva.
Levando em consideração a esses aspectos, o sistema de controle de estoque é de
extrema importância para o bom desempenho das actividades das empresas,
principalmente para o armazém da FCS, neste âmbito torna-se necessário que estas
invistam em sistemas de informação para reduzir problemas correlacionados ao uso do
papel como suporte de registro da informação.
Delimitação do problema
Como forma de delimitação do contexto de estudo, esta monografia está baseada
na Faculdade de Ciências de Saúde da Universidade Católica de Moçambique Beira,
concretamente no armazém da Faculdade no qual ainda emprega técnicas obsoletas, pelo
que, diante do cenário actual, a partir de um estudo profundo deste tema e com a aplicação
de entrevista feita ao gestor do armazém (VER ANEXO I), foram identificadas as
seguintes manifestações fácticas:
Limitações na emissão de relatórios;
Uso de métodos obsoletos no registro de informação do material.
De acordo com as manifestações fácticas encontradas, se identifica o seguinte
Problema de investigação:
Limitação no armazenamento e registro de informação do material,
impossibilitando a sua segurança e confiabilidade.
As manifestações e o problema anteriormente identificados são consequências de
muitas causas, das quais podem ser citadas algumas como:
4
Ineficiência do método em uso para fazer o registro de informação do material
comprometendo a segurança e confiabilidade da informação;
Limitação da metodologia em uso para manusear grandes volumes de informação,
o que limita o processo de registro e armazenamento de informação dificultando
assim o processo de busca de informação;
Limitações no registro e acesso as informações.
Portanto, para dar solução a este problema, torna-se necessário fazer um estudo
profundo sobre o processo de informatização do armazém da Faculdade de Ciências de
Saúde, que é declarado como objecto de estudo. Trata-se de um objecto de estudo amplo,
sendo assim, esta monografia centra-se num sistema de controle de estoque no armazém
da Faculdade de Ciências de Saúde.
O campo de acção da presente monografia declara-se como o processo de
implementação de um sistema de controle de estoque.
O objectivo geral da investigação é desenvolver um sistema de controle de
estoque no armazém da Faculdade de Ciências de Saúde.
Em consonância com o objectivo do estudo no processo da realização da
investigação se realizarão os seguintes objectivos específicos:
Fundamentar epistemologicamente sobre o processo de informatização de
armazéns, as tecnologias a serem utilizadas e a linguagem de modelação
unificada;
Caracterizar o estado actual do processo de informação do armazém da Faculdade
de Ciências de Saúde da Universidade Católica de Moçambique – Beira;
Desenvolver um sistema de controle de estoque e a sua aplicação.
5
Em consonância com o problema, objectivo e campo de acção se estabelece a
seguinte Hipótese de investigação:
Desenvolvendo-se um sistema de controle de estoque no armazém da Faculdade
de Ciências de Saúde, vai proporcionar maior dinamismo no armazenamento e registro
de informação e ainda aumentará a segurança e confiabilidade da informação.
A justificativa deste estudo encontra-se nas dificuldades vivenciadas pelo gestor
do armazém com o método actual no gerenciamento das actividades correlacionadas ao
armazenamento da informação do material, devido à este método não atender grande parte
das principais necessidades que o armazém possuí. Portanto, com a implementação de
um sistema de controle de estoque servirá para um maior controle de todos os itens que
armazém possui, tendo assim a noção do que deve ser remanejado e/ou comprado para
completar o estoque.
METODOLOGIA
Definições propostas por Lakatos e Marconi (2004) conceituam a metodologia
como sendo uma maneira de como se procede ao longo de um caminho, a forma como
são seleccionadas as técnicas de avaliação para se atingir um resultado. As técnicas
utilizadas par o levantamento de informações e elaboração da actividade, a presente
pesquisa é de natureza exploratória.
Em referência aos estudos exploratórios os mesmos não elaboram hipóteses que
são testadas no trabalho com a finalidade de definir objectivos ou buscar informações
sobre determinado assunto, portanto a finalidade da pesquisa exploratória é realizar
descrições precisas da situação que está ocorrendo e, além disso, visa descobrir as
relações existentes entre os factos que estão ocorrendo (CERVO, BERVIAN, 2002). A
6
seguir descrevem-se os métodos e as técnicas de levantamentos de requisitos utilizadas
para a implementação deste projecto:
Entrevistas
A entrevista é uma das técnicas tradicionais mais simples de utilizar e que produz
bons resultados na fase inicial de obtenção de dados. Convém que o entrevistador dê
margem ao entrevistado para expor as suas ideias. É necessário ter um plano de entrevista
para que não haja dispersão do assunto principal e a entrevista fique longa, deixando o
entrevistado cansado e não produzindo bons resultados. Foi entrevistado ao gestor do
armazém, com o objectivo de colher informações a respeito do nível actual da
metodologia de registro de informação relacionada a entrada e requisição do material.
Etnografia
É uma técnica de observação que pode ser usada para compreender os requisitos
sociais e organizacionais. Um analista de sistema se insere no ambiente de trabalho onde
o sistema será usado. Esta técnica é embasada na observação do trabalho diário e anotam-
se as tarefas reais nas quais os participantes estão envolvidos. A vantagem desta técnica
está na ajuda que presta aos analistas para descobrir os requisitos implícitos de sistema
que reflectem os processos reais, e não os formais, com os quais as pessoas estão
envolvidas. Esta técnica tem algumas desvantagens como, o desperdício de tempo e o
analista pode ser induzido a erro sem suas observações. Mas de uma maneira geral a
técnica de observação é muito útil e muitas vezes usada para complementar as descobertas
obtidas por outras técnicas.
Revisão bibliográfica
Baseada na leitura de todo material no qual abordava assuntos relacionados com
o tema da monografia.
7
Estrutura da monografia
A presente monografia está estruturada em introdução, três capítulos, referências
bibliográficas e anexos:
Na introdução apresenta-se de uma forma geral sobre o contexto da monografia,
o problema, objecto de estudo, campo de acção e objectivos a serem alcançados.
Capítulo 1. Fundamentação Teórica: neste capítulo dedica-se ao
desenvolvimento da fundamentação teórica em que primeiramente apresenta-se o
processo de informatização de armazéns, a definição de sistemas de informação, suas
principais características, uma breve descrição sobre a teoria geral de sistemas, os
principais tipos de sistemas de informação existentes, definição de controle de estoque,
estoque, suas funções, classificações e métodos de avaliação de estoque. Em seguida é
apresentada a caracterização actual do processo de informação do armazém da Faculdade
e por fim apresenta-se a definição de tecnologias que foram utilizadas no trabalho bem
como a linguagem de modelação unificada utilizada no desenho do sistema. Também este
capítulo aborda acerca das metodologias de desenvolvimento de software, no qual faz-se
um estudo comparativo de metodologias actuais de desenvolvimento de software, através
deste estudo propõe-se a metodologia a aplicar na implementação deste projecto.
Capitulo 2. Desenvolvimento de sistema: neste capítulo dedica-se a estruturação
do sistema desenvolvido, desde a definição dos requisitos do sistema até a elaboração de
diagramas UML que colaboraram para a especificação, documentação e refinamento de
requisitos elicitados visando assim à implementação do sistema de forma que ele
realmente possa atender as necessidades que o armazém possui. Também neste capítulo
é apresentado o sistema desenvolvido para o armazém da faculdade, mostrando assim os
principais formulários do sistema desenvolvido.
8
Capítulo 3. Conclusões e recomendações: neste capítulo são apresentadas as
conclusões finais, as recomendações a seguir e subsequentemente são apresentadas as
referências bibliográficas, são demonstrados em apêndices e anexos documentos
utilizados para a elaboração deste projecto.
9
CAPÍTULO I - FUNDAMENTAÇÃO TEÓRICA
Para melhor entendimento das características do sector que esta monografia está
inserida, foram realizadas pesquisas, dentre outros, sobre sistemas de informação e seus
variados tipos existentes, sistemas integrados de gestão, incluindo também a
caracterização actual do processo de informação do armazém.
Na primeira secção desse capítulo é apresentada a fundamentação epistemológica
sobre o processo de informatização de armazéns. A segunda secção desse capítulo
introduz sistemas de informação, a relação de dados e informações, bem como as
tecnologias que serão utilizadas. Também se aborda de conceitos de UML que serão
utilizados no desenvolvimento do sistema proposto.
1.1 FUNDAMENTAÇÃO DO PROCESSO DE INFORMATIZAÇÃO DE
ARMAZÉNS
Segundo o dicionário Aurélio (2004) informatizar quer dizer adaptar métodos
tradicionais de trabalho ou actividade ao uso de sistemas computadorizados.
Hoje em dia, o computador é uma ferramenta de trabalho quase que indispensável,
pois ele está presente em vários ramos da actividade humana.
Num mundo globalizado e cada vez mais competitivo, é essencial que as pessoas
pertencentes à população economicamente activa, dominem as funções básicas de
informática, tendo em vista que a expansão de sectores da economia como o terciário, fez
10
aumentar o uso de computadores, por isso não podemos mais ignorar a presença dessa
ferramenta tão útil em nosso dia-a-dia.
Portanto, com a necessidade de criar ferramentas que facilitassem o seu trabalho
diário, o homem passou a aprimorar cada vez mais os computadores, pois a sua utilização
não apenas poupa tempo e dinheiro, mas também permite a possibilidade de um controle
cada vez melhor de estoques, informações, serviços etc.
Por muito tempo o homem produziu, criou ou simplesmente modificou seu habitat
de forma directa sem um controle áspero do trabalho, delegando "missões" a pessoas e
esperando a resposta, que por vezes se fazia demorada. Entretanto com o advento do
computador, o trabalho se tornou mais ágil e com resposta imediata.
Nisto as pessoas têm a necessidade de conhecer esta nova ferramenta de trabalho
que não só está inserida na forma de computadores de mesa (desktop), mas também como
consoles de comando de máquinas especializadas de diversas ocupações, tais como: robôs
médicos, máquinas exploradoras, controles de caminhões. (SAMPAIO, 1999).
Muitas empresas ainda acreditam que informatizar é um simples facto de fazer a
expansão de computadores e impressoras pelas unidades departamentais da empresa,
ligando-os em rede e instalando sistemas ou aplicativos, possa informatizar as mesmas.
Para que a informatização seja levada a cabo é imperioso que a empresa esteja organizada
em todos seus sectores. O maior erro que a maioria das empresas comete no processo da
informatização da sua informação ou dos seus processos é de não descobrir ou conhecer
as reais necessidades que possuem.
O primeiro passo no caminho para a informatização é conhecer e definir as reais
necessidades da empresa. É fundamental para o sucesso da informatização que a empresa
já tenha estabelecido o costume de promover controles, sejam eles administrativos ou
11
financeiros, fazendo com que os funcionários, comprometidos com a empresa, realizem
os diversos processos de captura das informações e a análise de resultado, dentro dos
critérios previamente estabelecidos. Desta forma, para que haja a informatização é
imperioso que as empresas estejam organizadas para facilitar o processo de
informatização, visto que esta organização engloba o conhecimento e definição das reais
necessidades da empresa.
Por isso, um sistema informatizado proporcionará ao armazém maior dinamismo,
agilidade e precisão no controle de estoque, total de entrada e saída de material. Torna-se
então necessário o desenvolvimento de um sistema que armazene de forma confiável, as
informações do material, entrada e requisição do material provendo, sempre que
necessário, relatórios de entrada, requisição e estoque.
1.2 Sistemas de informação
De acordo com (LAUDON & LAUDON, 2007, p.9), um sistema de informação
pode ser definido tecnicamente como um conjunto de componentes inter-relacionados
que colectam (ou recuperam), processam, armazenam e distribuem informação destinadas
a apoiar a tomada de decisões, a coordenação e o controle de uma organização. Os
sistemas de informação além de dar apoio à tomada de decisões, coordenação e ao
controle, esses sistemas também auxiliam os gerentes e trabalhadores a analisar os
problemas, visualizar assuntos complexos e criar novos produtos. Os sistemas de
informação contêm informações sobre pessoas, locais e itens significativos para a
organização ou o ambiente que o cerca.
Três actividades em um sistema de informação produz as informações de que as
empresas necessitam para tomar decisões, controlar operações, analisar problemas e criar
novos produtos ou serviços. Essas actividades são a entrada, o processamento e a saída.
12
A entrada captura ou colecta dados brutos de dentro da organização ou de seu ambiente
externo. O processamento converte esses dados brutos em uma forma mais significativa.
A saída transfere as informações processadas às pessoas que utilizarão ou às actividades
nas quais elas serão empregadas. Os sistemas de informação também requerem um
feedback (realimentação), que é a saída que retorna a determinados membros da
organização para ajudá-los a avaliar ou corrigir o estágio de entrada.
Figura 1: Funções de um sistema de informação. Fonte: (Laudon & Laudon, 2007)
Um sistema de informação possui como principais objectivos armazenar, tratar e
fornecer informações visando ser um subsídio de apoio ao processo de tomada de decisões
nas organizações. Com a expansão de sua utilização ocorrida nos últimos tempos eles se
tornaram condição vital para que ela possa obter melhor controle de parte ou todos os
processos empregues na organização colaborando para a ocorrência de melhorias em sua
gestão. (RIBEIRO, 2012).
13
A informação ocupa um papel estratégico vital nas organizações permitindo que
elas possam obter vantagem competitiva em relação á seus concorrentes. Entretanto para
isso é fundamental que haja qualidade nas informações que elas adquiriram, devido a ela
possuir grande importância nos resultados que serão obtidos no processo de tomada de
decisões na organização. (FERAUCHE, 2006).
A informação pode ser caracterizada como o principal activo de uma empresa. Ela
por ser um recurso intangível faz com que se torne difícil mensurar o valor que esta pode
agregar as organizações. Desta forma, é de grande importância que as empresas valorizem
cada vez mais as informações, por representarem um papel de suma importância na gestão
organizacional. (RIBEIRO, 2012).
Com base nas leituras realizadas pode se considerar que a informação hoje é um
bem precioso nas organizações, visto que ela se tornou num quarto poder no mundo.
Desta feita, quem tem informação nos dias de hoje tem o poder nas mãos isto pela sua
extrema importância que vem ganhando nas organizações e no mundo. Por isso a
informação deve estar sempre actualizada e disponível com vista a facilitar os gestores
sêniores da organização ou empresa na tomada de decisões e ainda com informação
actualizada e disponível a empresa estará em altura para competir com as outras em pé de
igualdade. Pode-se ressaltar ainda que hoje a informação tornou-se numa cereja para
organizações ou empresas ajudando-as assim a manterem a sua vantagem competitiva no
mercado.
Conforme (FERAUCHE, 2006) um sistema de informação engloba vários
elementos dentre eles destacam-se:
Hardware: conjuntos de equipamentos que permitem com que os dados sejam
recolhidos, tratados e armazenados.
14
Software: conjunto de programas que permitem com que seja realizado o
tratamento de dados, transformando-os em informações.
Organização: é responsável por determinar à forma como são organizados os
processos e as pessoas para o tratamento armazenamento da informação.
Pessoas: responsáveis por realizar o tratamento e a utilização das informações,
sem que para isso seja necessário o uso de qualquer equipamento.
Output: é produto final, em suma a informação organizada de forma lógica e útil
para empresa.
A maioria das pessoas ou empresas acha que o sistema de informação é composto
de hardware e software, mas na verdade o sistema de informação é mais do que hardware
e software, ele é composto de um subsistema social e automatizado. O subsistema social
corresponde as pessoas, processos informações e documentos. O subsistema
automatizado este diz respeito aos meios automatizados (máquinas, computadores, redes
de comunicação) que interligam os elementos do subsistema social.
Por isso, o SI é algo mais que um software ou hardware, pois além de incluir o
hardware e software, também inclui processos e seus agentes que são executados fora das
máquinas. Convém frisar que o conceito de sistemas de informação costuma ser
equiparado com os de sistemas informáticos, pois os dois sistemas são bem diferentes e
com objectivos totalmente diferentes. Em todo o caso, os sistemas de informação tratam
do desenvolvimento e da administração da infraestrutura tecnológica de uma organização.
Um Sistema de Informação não precisa ter essencialmente computadores envolvidos,
basta ter várias partes trabalhando entre si para gerar informações. Com isso, um sistema
de informação pode ser entendido como a comunicação de vários elementos entre si
permitindo assim a entrada, processamento e saída de informação.
15
Ele pode ser tanto manual quanto baseado em TI, ou uma combinação dos dois.
Acontece que um sistema de informação complexo, dificilmente sobrevive actualmente
sem que esteja informatizado, o que por si só, não elimina o factor humano no processo.
Pois é através da interação dos componentes da tecnologia de informação com o
componente humano que faz com que o sistema de informação tenha funcionalidade e
utilidade para organização.
1.3 A relação de dados e informação com o SI
De acordo com (LAUDON & LAUDON, 2007, p.9) informação são dados
apresentados em uma forma significativa e útil para os seres humanos. Dados define como
sequências de factos brutos que representam eventos que ocorrem nas organizações ou no
ambiente físico, antes de terem sido organizados e arranjados de uma forma que as
pessoas possam entendê-los e usá-los.
Para (FERAUCHE, 2006) no momento em que se identificam as metas da
organização, elas devem ser claras e concisas para que os sistemas de informação possam
alcançar a sua principal finalidade que é fornecer dados organizados, processados e
tratados visando auxiliarem as organizações nos processos de tomadas de decisões com
o mínimo de riscos possíveis nos níveis gerenciais, táticos e operacionais. Desta forma,
posteriormente objectivos específicos podem ser traçados para uma grande variedade de
setores, definindo claramente que eles não podem estar acima das metas da organização;
mas também agregando para que elas possam ser alcançadas com êxito. Dentre alguns
dos principais benefícios que podem ser desencadeados se este processo de implantação
e gerenciamento do sistema de informação for bem-sucedido é de grande relevância
ressaltar:
Redução de custos;
16
Expansão da qualidade de serviços e produtos;
Aumento da oferta e consequente satisfação do cliente;
Abertura de novos nichos de mercado.
1.4 Níveis e tipos de sistemas de informação
Para (SANTOS, 2009), os sistemas de informação nas organizações podem ser
aplicados nos níveis operacional, conhecimento, gerencial e estratégico. Os sistemas de
nível operacional visam apoiar as empresas no acompanhamento de suas actividades
rotineiras devem oferecer informações de fácil acesso com um alto grau de precisão. Os
sistemas de nível do conhecimento devem auxiliar as organizações na integração de novas
tecnologias para ajudar na forma que ela se organiza. Os sistemas de nível gerencial visam
atender as actividades que envolvem monitoração, controle e tomada de decisões. Os
sistemas de nível estratégico visam auxiliar a empresa na elaboração de seu planeamento
á longo prazo.
A Figura 2 representa os níveis mencionados, os grupos que eles atendem dentro
das organizações e as diferentes áreas funcionais atendidas.
Figura 2: Classificação dos sistemas da informação. Fonte: (SANTOS, 2009)
17
Segundo (LAUDON & LAUDON, 2007), existe uma grande variedade de tipos
de sistema de informações que possuem objectivos distintos dentro do contexto
organizacional em que ele está implantado. Vale ressaltar, que não há nada que
impossibilite que um determinado SI utilizado por uma empresa seja classificado em mais
do que um tipo.
A seguir apresenta-se uma descrição das características de alguns dos principais
tipos de sistemas de informação existentes:
Sistemas de Gestão Empresarial Integrada (ERPs): são responsáveis por
realizar a integração de inúmeros sistemas rotineiros ou transacionais de uma
empresa. Eles são utilizados com muita frequência no âmbito corporativo para
que diversos sectores possam trabalhar de maneira integrada e assim auxiliando
na agilização da execução dos processos organizacionais.
Sistemas de Processamento de Transações (SPTs): são sistemas
computadorizados que realizam e registram as transações rotineiras necessárias
ao funcionamento da empresa. Estes sistemas têm como principal objectivo
responder as perguntas de rotina e monitorar o fluxo de transações dentro da
organização.
Sistemas de Informações Gerenciais (SIGs): são sistemas que atendem aos
gerentes de nível médio da organização. Possuem como principal objectivo de
proporcionar relatórios sobre o desempenho corrente da organização.
Sistemas de Apoio a Decisão (SADs): são os que ajudam os gerentes de nível
médio a tomar decisões não usuais. São responsáveis por receber um conjunto de
alternativas que possam auxiliar na realização do processo de tomada de decisões
visando solucionar determinado problema e efetuar uma análise das
18
consequências que cada alternativa pode resultar. Diferentemente do SIG o SAD
é um sistema interativo, em que o usuário fornece a entrada das diferentes
alternativas e este irá auxiliar a subsidiar a decisão á ser tomada por ele sem
escolher a melhor alternativa dentre a lista de entrada fornecida.
Sistemas de gestão de conhecimentos (SGCs): são os sistemas que permitem às
organizações administrar melhor seus processos, a fim de capturar e aplicar
conhecimentos e expertise. Esses sistemas colectam todo o conhecimento e a
experiência relevantes na empresa e os tornam disponíveis onde e quando forem
necessários para melhorar os processos de negócios e as decisões administrativas.
Sistemas de apoio ao executivo (SAEs): são os que ajudam a gerência sênior a
tomar decisões. Eles proporcionam capacidade generalizada de computação e
comunicações que pode ser aplicada a um conjunto de problemas em constante
alteração.
1.5 SISTEMAS DE CONTROLE DE ESTOQUES
Os sistemas de controle de estoques processam dados que reflectem em mudanças
nos artigos em estoque. Há que frisar que os sistemas de controle de estoques minimizam
os gastos, investimentos excessivos e desnecessários evitando deste modo prejuízos no
processo produtivo e crescimento dos custos das empresas. Para isso as empresas são
desafiadas a se aliarem com os modelos de sistemas de controle de estoques com vista a
controlar o seu estoque.
1.5.1 Controle de estoque
O controle de estoques é o procedimento adoptado para registrar, fiscalizar e gerir
a entrada e saída de mercadorias e produtos, seja numa indústria ou no comércio. O
19
controle de estoque deve ser utilizado tanto para matéria prima, mercadorias produzidas
e/ou mercadorias vendidas.
O Controle de estoques exerce influência muito grande na rentabilidade da
empresa. Os estoques absorvem capital que poderia estar sendo investido de outras
maneiras, desviam fundos de outros usos potenciais e tem o mesmo custo de capital que
qualquer outro projecto de investimento da empresa. Sendo um importante papel na fase
administrativa, pois através desse estoque e que é possível saber o quanto se pode comprar
o que comprar para não chegar ao desperdício de matérias ou até mesmo da falta de
material em estoque.
O objectivo do controle de estoque é também financeiro, pois a manutenção de
estoques é cara e o gerenciamento do estoque deve permitir que o capital investido seja
minimizado. Ao mesmo tempo, não é possível para uma empresa trabalhar sem estoque.
1.5.2 Estoque
De acordo com VIANA (2000) o estoque pode ser definido como materiais,
mercadorias ou produtos acumulados para utilização posterior, de modo a permitir o
atendimento regular das necessidades dos usuários para a continuidade das actividades da
empresa, sendo o estoque gerado, consequentemente, pela impossibilidade de prever-se a
demanda com a exactidão.
Segundo (CHIAVENATO, 2005, p.67) define estoque como sendo a composição
de materiais em processamento, materiais semi-acabados, materiais acabados que não é
utilizada em um dado momento na empresa, mas que precisa existir em funções de futuras
necessidades da empresa.
20
1.5.3 Funções de estoque
Segundo (CHIAVENATO, 2005, p.68) as principais funções do estoque são:
Garantir o abastecimento de materiais à empresa, neutralizando os efeitos de:
demora ou atraso no fornecimento de materiais, sazonalidade no suprimento,
riscos de dificuldade de fornecimento.
Proporcionar economias de escala: através da compra ou produção de lotes
econômicos, pela flexibilidade do processo produtivo, pela rapidez e eficiência no
atendimento às necessidades.
1.5.4 Classificação de estoques
De acordo com (CHIAVENATO, 2005, p.69) os estoques podem ser classificados
em função dos mesmos critérios de classificação dos materiais:
1. Estoques de matérias-primas (MPs).
2. Estoques de materiais em processamento (ou em vias).
3. Estoques de materiais semi-acabados.
4. Estoques de materiais acabados (ou componentes).
5. Estoques de produtos acabados (PAs).
Estoques de Matérias-Primas (MPs): Os estoques de MPs dizem respeito aos
insumos e materiais básicos que ingressam no processo produtivo da empresa. São os
itens iniciais para os produtos/serviços da empresa. Isto significa que a produção é
totalmente dependente das entradas de MPs para ter a sua sequência e continuidade
garantidas.
Estoques de Materiais em Processamento ou em Vias: Os estoques de materiais
em processamento ou em vias diz respeito aos materiais que estão sendo processados ao
21
longo das diversas secções que compõem o processo produtivo da empresa. São, pois, os
materiais em processo de produção ou em vias de serem processados em cada uma das
seções produtivas da empresa.
Estoques de Materiais Semi-acabados: Estoques de Materiais Semi-acabados
diz respeito aos materiais parcialmente acabados, cujo o processamento encontra-se no
estágio intermediário de acabamento e que se encontra também ao logo das diversas
secções que compõe o processo produtivo.
Estoques de Materiais Acabados ou Componentes: Estoques de Materiais
Acabados ou Componentes diz respeito às peças isoladas ou componentes ou ainda
materiais já acabados e prontos para serem integrados ao produto. São, na realidade,
partes prontas ou montadas que, quando juntadas constitui um produto acabado.
Estoques de Produtos Acabados (PAs): Estoques de Produtos Acabados referem
ao tipo de produtos já acabados e prontos para o seu uso, cujo o processamento foi
completado inteiramente. Diz respeito ao estágio final do processamento produtivo e que
já passaram por todas as fases.
1.5.5 Métodos de avaliação de estoque
A avaliação do estoque pode ser feita por meio de quatro métodos distintos a saber
(CHIAVENATO, 2005, p.89):
Avaliação pelo Custo Médio: este método baseia-se no preço de todas as
retiradas ao preço médio de suprimento total do item em estoque. A saída de
estoque é calculada pelo custo médio.
Avaliação pelo Método PEPS (FIFO): a sigla PEPS é a abreviação da frase:
primeiro a entrar, primeiro a sair. Em inglês, FIFO: first in, first out. Neste método
22
a avaliação do estoque é feita pela ordem cronológica das entradas. Isto significa,
sai o lote mais antigo que entrou para estoque.
Avaliação pelo Método UEPS (LIFO): a sigla UEPS é a abreviação da frase:
último a entrar, primeiro a sair. Em inglês LIFO: last in, first out. A saída do
estoque é feita pelo preço do último lote a entrar.
Avaliação pelo Custo de reposição: é o custo de reposição do estoque que ajusta
a avaliação financeira dos estoques. Assim, o valor dos estoques é sempre
actualizado em função dos preços do mercado.
1.6 CARACTERIZAÇÃO DO ESTADO ACTUAL DO PROCESSO DE
INFORMAÇÃO DO ARMAZÉM
No armazém há uma grande diversidade de materiais, onde cada funcionário
efectua a sua requisição, havendo assim o mesmo tipo de requisição oriundo do mesmo
funcionário, mas com datas diferentes.
Quando o funcionário faz a requisição é preenchido um formulário em um papel,
com a discriminação ou anotação do número da requisição, requisitante, quantidade,
observação e a data da mesma. Com isso, é impresso um formulário, que é assinado pelo
funcionário requisitante e pelo gestor do armazém. Este formulário fica no armazém para
controle desta requisição.
Ao final do mês, é feita uma planilha para se saber a quantidade de requisição feita
por cada departamento, para se obter o valor gasto em cada departamento. Quando há
necessidade de saber a quantidade exacta de determinado material, é realizada a contagem
manual do mesmo e quando chega um funcionário ou requisitante perguntando se há
determinado material no armazém, o gestor precisa procurar para descobrir.
23
Neste contexto, o controle de estoque no armazém da Faculdade de Ciências de
Saúde, baseia-se no método de registro de informação no papel para gestão das suas
actividades, método este que não satisfaz na íntegra grande parte das necessidades que o
armazém precisa atender e certas actividades que o utilizador precisa executar (como por
exemplo quais os materiais requisitados no armazém, qual o departamento que mais
requisita material, qual a quantidade de material requisitada durante um mês, relatórios,
etc.). Vale ressaltar que ocorrem frequentes casos de desaparecimento de papéis de
registro de informação, comprometendo segurança, credibilidade e confiabilidade da
informação e também dificultando o processo da elaboração de relatórios seja semanal,
mensal ou anual.
A sistemática utilizada pelo armazém é de difícil manutenção e possui falhas que
acabam gerando gastos desnecessários e prejudicando o fluxo de trabalho. Também não
é possível extrair informações que possam auxiliar na tomada de decisão (o que comprar,
quando comprar e quanto comprar), por parte do gestor do armazém, muitas vezes,
gerando o desperdício de tempo, acúmulos de grandes volumes de papéis, morosidade na
elaboração de relatórios. Com isso torna o processo do controle de estoque do armazém
cada vez mais embaraçoso.
O método de controle de estoque utilizado no armazém é PEPS que significa,
primeiro a entrar, primeiro a sair ou FIFO em inglês, first in, first out. Sai primeiro do
estoque ou armazém o material mais antigo, ou seja, primeiro que entrou no estoque.
Desse modo, fica em estoque, o material mais recente. Também se baseia na data de
validade do material.
Diante desses factos, pode-se dizer que, no armazém se aplica a metodologia FIFO
ou UEPS, isto porque a metodologia traz consigo uma vantagem de manter o valor dos
24
estoques sempre actualizado em relação ao valor da última entrada. Isto significa que o
valor dos estoques se aproxima dos preços actuais do mercado. Por outro lado, é pelo
facto do custo de produção ser calculado em função dos valores dos primeiros lotes de
entrada.
1.6.1 Proposta do trabalho
Com base nas dificuldades apresentadas anteriormente, este trabalho objectiva a
informatização das principais actividades do armazém, que actualmente são realizadas de
forma manual com base nos dados disponibilizados, reduzir as despesas relacionadas com
estoque e melhorar o controle de estoque.
Tendo em conta que o método actual empregue no armazém não satisfaz o
armazenamento confiável, como o controle de registro de dados do material, controle de
entrada do material e a saída do mesmo, como também permitir o uso simultâneo da
informação, a utilização de um sistema proporcionará condições de disponibilizar apenas
as funcionalidades de acordo com a categoria ou privilégio de cada utilizador. Presume-
se que, com o modelo proposto, se poderão suprir muitas das insuficiências já relatadas.
A proposta fundamenta-se em satisfazer todos os requisitos existentes e ter
capacidade de suprir as desvantagens do método actual, bem como prover novas
facilidades aos processos ligados ao armazém da faculdade.
1.6.2 Por que usar o sistema proposto?
Existem vários sistemas de controle de estoque de armazém já prontos no mercado
de softwares, mas eles geralmente são desenvolvidos e projectados para atender as
necessidades de uma maneira geral ou são projectados com objectivo de atender as
especificações de uma determinada empresa de um dado país ou continente.
25
Cada sistema de controle de estoque é desenhado para um determinado fim de
acordo com as necessidades da empresa que o deseja. Por isso o sistema proposto foi
desenvolvido fundamentando-se na realidade do armazém, suas regras de funcionamento
e características das actividades exercidas no armazém, de modo que os utilizadores do
sistema usem um software que corresponda com à sua realidade. Deste modo garantindo
a satisfação dos utilizadores do mesmo.
1.7 PRINCIPAIS TECNOLOGIAS E FERRAMENTAS UTILIZADAS
1.7.1 Java
Java é uma linguagem de programação utilizada no desenvolvimento do projecto
de software criada pela Sun Microsystems. É considerada uma linguagem robusta que
roda em vários tipos de plataforma, não limitando o programador à somente algumas
plataformas. A linguagem é composta por símbolos e palavras reservadas que são
utilizadas para escrever expressões, instruções métodos, classes, etc. Existem ainda vários
tipos de IDEs (Integrated Development Environment – Ambiente de Desenvolvimento
Integrado) que utilizam a linguagem Java como padrão (SANTOS, 2004). Uma das
principais características da tecnologia Java é a Programação Orientada a Objetos (POO),
é através desta técnica de desenvolvimento que os programadores conseguem criar
sistemas mais estáveis e de fácil manutenção. Cada classe instanciada determina o
comportamento de seus objectos, assim como o relacionamento com outros objectos do
sistema.
26
1.7.1.1 Características da linguagem Java
A linguagem Java possui as seguintes características:
Simples e familiar;
Orientada a objectos;
Compilada e interpretada;
Distribuído;
Multiprocessamento;
Portabilidade;
Segura.
1.7.2 Java Platform, Enterprise Edition (Java EE)
Java Platform, Enterprise Edition (Java EE) é uma plataforma padrão de
desenvolvimento de aplicações para empresas, codificada na linguagem de programação
Java. Com base no sólido fundamento da Plataforma Java, Standard Edition (Java SE),
Java EE acrescenta bibliotecas e serviços do sistema que oferecem suporte à
escalabilidade, acessibilidade, segurança, integridade e outros requisitos de aplicações de
classe empresarial. (ORT, 2009). Desde seu lançamento em 1999, Java EE amadureceu
de modo a tornar-se uma plataforma funcionalmente rica e de alto desempenho. Os
recentes lançamentos da plataforma sublinharam igualmente a simplicidade e facilidade
de uso. Na verdade, com a plataforma Java EE, o desenvolvimento de aplicações
corporativas Java nunca foi mais fácil ou mais rápido.
1.7.3 NetBeans IDE
É um ambiente absolutamente livre para desenvolvimento de software com código
fonte aberto, o que suporta as seguintes linguagens de programação: C, C + +, Java, PHP,
27
Groovy, JavaScript, etc. O ambiente fornece aos desenvolvedores ferramentas necessárias
para criar aplicação profissional, empresarial, desktop, aplicações móveis e de internet.
NetBeans actualmente existem dois produtos: o IDE NetBeans (NetBeans IDE) e a
Plataforma NetBeans (NetBeans Platform). NetBeans suporta as seguintes funções:
perfis, destaque de sintaxe de cor, autopreenchimento, modelos de código definidos, etc.
O NetBeans IDE é um ambiente de desenvolvimento - uma ferramenta para
programadores, que permite escrever, compilar, depurar e instalar programas. A IDE é
completamente escrito em Java, mas pode suportar qualquer linguagem de programação.
Existe também um grande número de módulos para estender as funcionalidades do IDE
NetBeans. O NetBeans IDE é um produto livre, sem restrições à sua forma de utilização.
1.7.3.1 Principais características
Open-source;
Suporte para seguintes linguagens de programação: C, C#, C++, PHP, Groovy,
JavaScript, etc;
Capacidade de criar vários tipos de aplicações.
1.7.4 Navicat Premium
Navicat é uma rápida, confiável e acessível ferramenta de administração de
bancos de dados propositadamente construída para simplificar o gerenciamento de banco
de dados e reduzir os custos de administração. Projectado para atender as necessidades
dos administradores de banco de dados, desenvolvedores e pequenas e médias empresas,
Navicat é construído com uma interface de usuário intuitiva que permite criar, organizar,
acessar e compartilhar informações de forma segura e fácil.
Navicat é bem conhecido, confiável e utilizado todos os dias ao redor do mundo
por empresas globais, agências governamentais e instituições educacionais. Desde do
28
início de 2000, Navicat foi baixado mias de 2.000 mil vezes em todo o mundo e tem uma
clientela de mais de 50.000 usuários. Actualmente mais de 100 das empresas Global
Fortune 500 utilizam Navicat. Navicat agora está disponível em ste línguas e é
reconhecido como mais popular do front end da interface do usuário para MySQL.
Está disponível para MySQL, SQLite, PostgreSQL, e Oracle para administração
e desenvolvimento de banco de dados local ou remoto (http://www.software.com.br).
1.7.5 Sistema gerenciador de banco de dados MYSQL
Um sistema gerenciador de banco de dados (SGBD – Database Management
System) é uma colecção de programas que permite aos usuários criar e manter um banco
de dados (ELMASRI, NAVATHE, 2011). O SGBD é um sistema de software de uso
geral que facilita o processo de definição, construção, manipulação e compartilhamento
de banco de dados entre diversos usuários e aplicações.
Definir um banco de dados envolve especificar os tipos, estruturas e restrições
dos dados a serem armazenados. A construção do banco de dados é o processo de
armazenar os dados em algum meio controlado pelo SGBD. A manipulação de um banco
de dados inclui funções como consulta ao banco de dados para recuperar dados
específicos, actualização do banco de dados para reflectir mudanças no minimundo e
geração de relatórios com base nos dados. O compartilhamento de um banco de dados
permite que diversos usuários e programas acessem-no simultaneamente.
MYSQL é um sistema de gerenciamento de banco de dados relacional (relational
database management system - RDBMS) poderoso e muito rápido. Um banco de dados
permite armazenar, pesquisar, classificar e recuperar dados de forma eficiente
(WELLING, THOMSON, 2005). O servidor MYSQL controla o acesso aos dados para
assegurar que vários usuários possam trabalhar com os dados ao mesmo tempo, fornece
29
acesso rápido aos dados e assegurar que somente usuários autorizados obtenham acesso.
Ele utiliza SQL (Struture Query Language), como a linguagem de consulta padrão de
banco de dados.
Algumas vantagens que tornam o MYSQL poderoso são apresentadas a seguir
(WELLING, THOMSON, 2005):
Alto desempenho;
Baixo custo;
Fácil configuração e aprendizado;
Portabilidade;
Disponibilidade de código-fonte.
1.7.6 Modelo cliente/servidor
Esse tipo de modelo divide o processamento de informação entre clientes e
servidores. Ambos fazem parte da rede, mas cada máquina desempenha a função
específica que estiver mais apta para executar. O cliente é o ponto de entrada do usuário
para a função requisitada e normalmente é um computador de mesa, estação de trabalho
ou computador pessoal. O usuário em geral interage de maneira directa somente com a
porção cliente da aplicação, com frequência para entrar com os dados ou requisitá-los
para análise posterior. O servidor provê serviços ao cliente. Os servidores armazenam e
processam dados compartilhados e também executam funções de apoio invisíveis aos
usuários, como o gerenciamento das actividades na rede.
Algumas pessoas acham que o cliente é o processo que faz o processamento de
dados, mas na verdade o cliente é o processo que faz a interação com o servidor através
de uma interface gráfica, permitindo assim a consulta de dados. O servidor é o processo
que fornece serviços aos seus clientes e os disponibilizam a quem necessita deles.
30
Figura 3: Modelo cliente/servidor. Fonte: (LAUDON & LAUDON, 2007).
1.7.7 JasperReports e iReports
A biblioteca JasperReports é uma poderosa e flexível ferramenta de geração de
relatórios que fornece rico conteúdo para a tela, impressos ou arquivo em PDF, HTML,
RTF, XLS, ODT, CSV ou XML. A biblioteca é escrita inteiramente em Java e pode ser
usado em uma variedade de aplicativos habilitados para Java, incluindo J2EE ou
aplicações web, para gerar conteúdo dinâmico.
Seu principal objectivo é ajudar a criar páginas orientadas, prontas para imprimir
documentos de uma forma simples e flexível. JasperReports utiliza modelos de relatório
estruturados em várias secções, tais como título, resumo, detalhes de página e cabeçalhos
e rodapés do grupo. Cada secção tem um layout de forma livre em que o desenvolvedor
pode colocar vários tipos de elementos, incluindo imagens estáticas e dinâmicas, campos
de texto, linhas e retângulos. O mecanismo de relatório usa esse modelo para organizar
os dados em um arquivo XML (JRXML - JasperReports eXtensible Markup Language)
ou para criá-lo de forma programática utilizando a API da biblioteca. Estes dados podem
vir de várias fontes de dados, incluindo dados relacionais, coleções ou matrizes de objetos
Java ou dados XML. Os usuários podem conectar a biblioteca de comunicação por meio
31
de fontes de dados através da implementação de uma interface simples (DANCIU e
CHIRITA, 2007).
Segundo Toffoli (2007), iReport é um framework de código aberto que pode criar
relatórios complexos, para serem utilizados em qualquer tipo de aplicação Java através
da biblioteca JasperReports. É escrito em Java puro e é distribuído com código-fonte de
acordo com a GNU (General Public License). O software JasperStudio é a edição
profissional do iReport que é comercialmente suportado por JasperSoft Corporation e
lançado como parte da JasperSoft Business Intelligence Suite, um conjunto abrangente
de ferramentas para relatórios integrados, análises e integração de dados. Através de uma
interface gráfica rica e intuitiva, o iReport permite criar rapidamente qualquer tipo de
relatório com facilidade.
O iReport permite, aos desenvolvedores que estão aprendendo essa tecnologia,
acesso a todas as funções do JasperReports, bem como ajuda os usuários qualificados a
economizar uma grande quantidade de tempo durante o desenvolvimento de relatórios
muito elaborados.
1.7.8 Linguagem UML
UML (Unified Modeling Language – Linguagem de modelagem Unificada) é uma
linguagem de modelagem que serve para a realização de uma padronização no
desenvolvimento de software. Sendo assim, ela provê a elaboração e visualização de
elementos existentes no desenvolvimento de softwares como por exemplo, os diagramas.
De acordo com BEZERRA (2006), a UML é uma linguagem visual para modelar
sistemas orientados a objectos. Isto significa que a UML é uma linguagem constituída de
elementos gráficos (visuais) utilizados na modelagem que permitem representar conceitos
do paradigma de orientação a objectos. Através dos elementos gráficos definidos nesta
32
linguagem pode-se construir diagramas que representam diversas perspectivas de um
sistema.
A UML é independente tanto de linguagens de programação quanto ao processo
de desenvolvimento. Isto significa que UML pode ser utilizada para modelagem de
sistemas, não importa qual a linguagem de programação será utilizada na implementação
de sistema, ou qual forma (processo) de desenvolvimento adoptada.
Algumas pessoas definem a UML como uma linguagem de programação visual,
especificação de ferramentas ou como um processo de desenvolvimento de software. Mas
na realidade ela é uma linguagem de modelagem visual para capturar conhecimentos ou
ideias e expressar o tal conhecimento. Isto quer dizer que a UML tem como principal
propósito a modelagem de sistemas ou modelagem do que pensamos (ideias).
A UML se destina principalmente à modelagem de sistemas de informação
complexos. Hoje ela é empregue nas mais diversas áreas, como por exemplo: serviços de
bancos e finanças, telecomunicações, transportes, vendas, sistemas distribuídos,
fundamentos na Web, etc., no entanto, ela não se restringe somente ao desenvolvimento
de sistemas complexos, ela pode ser utilizada no desenvolvimento de qualquer tipo de
sistema.
A UML por possuir estas características visuais, por meio de diagramas ela
possibilita a representação de sistemas de software de diferentes pontos de vista.
Facilitando assim a comunicação entre todas pessoas envolvidas no desenvolvimento de
sistema como gerente, analista de sistema, coordenadores, programadores, etc.
apresentando um vocabulário de entendimento facilitado. Por este motivo esta linguagem
pode ser considerada como uma das linguagens mais expressivas de sistemas orientados
a objectos.
33
Os requisitos de software são as capacidades e condições às quais o sistema em
termos mais amplos, o sistema ou projecto deve atender. Eles representam um conjunto
de funcionalidades que o sistema deve fornecer e variam de acordo com o tipo de sistema
desenvolvido, dos usuários finais e das técnicas que serão aplicadas, auxiliando no
entendimento das principais características do domínio da aplicação (LARMAN, 2005).
Os requisitos de sistemas categorizados como funcionais não funcionais
(SOMMERVILLE, 2007, p.80):
Os requisitos funcionais são as declarações de serviços que o sistema deve
fornecer ou atender, como o sistema deve reagir as entradas específicas e como o sistema
deve se comportar em determinadas situações
Assim são considerados como responsáveis por descrever as funcionalidades ou
o que um sistema faz ou é esperado que faça. O ideal é que os requisitos funcionais tenham
uma descrição completa e consistente. Desta forma é possível evidenciar e definir (de
maneira não contraditória) todas as funções demandadas pelo usuário.
Os requisitos não funcionais são as restrições sobre os serviços ou as funções
oferecidas pelo sistema. Estes requisitos estão relacionados com às propriedades
emergentes do sistema, como confiabilidade, tempo de resposta e espaço de
armazenamento.
Existe outra categoria de requisito que não é muito referenciada no
desenvolvimento de sistemas que são requisitos de usuário descrevem os requisitos
funcionais e não funcionais, de modo que eles sejam compreensíveis pelos usuários de
sistema que não possuem conhecimento técnico detalhado. Eles apenas especificam o
comportamento externo do sistema e evitar sempre que possível, características de
projecto de sistema. Esses garantem a existência uma boa ligação entre o sistema
34
desenvolvido, utilizadores do sistema e também as tarefas que desempenham apoiados
pelo sistema.
1.7.8.1 Diagrama de casos de uso (use case)
Um caso de uso constitui a técnica em UML para representar o levantamento de
requisitos de um sistema. O diagrama de casos de uso serve para identificar as fronteiras
do sistema e descrever os serviços (use cases) que devem ser disponibilizados a cada um
dos diversos utilizadores (actores).
Figura 4: Diagrama de casos de uso. Fonte: (SOMMERVILLE, 2003)
1.7.8.2 Diagramas de actividades
O diagrama de actividades constitui um elemento de modelação simples, mas
eficaz para descrever fluxos de trabalho numa organização ou para detalhar as operações
de uma classe, incluindo comportamentos que possuam um processamento paralelo.
35
Figura 5: Exemplo de diagrama de actividades. Fonte:( Ranthum, 2005)
1.7.8.3 Diagrama de sequência
É diagrama de usado em UML que representa a sequência de processos mais
especificamente de mensagens passadas entre objectos de uma classe. Ele é utilizado para
representar a interação entre objectos de uma classe.
Figura 6: Exemplo de diagrama de sequência. Fonte: (Sommerville, 2003)
36
1.7.8.4 Diagrama de classes
O diagrama de classe representa uma descrição formal da estrutura de objectos
num sistema para cada objecto descreve a sua identidade, os seus relacionamentos com
os outros objectos, os seus atributos e as suas operações. Assim, as classes descrevem
objectos com atributos e operações comuns e servem dois propósitos: permitem
compreender o mundo real que relevante para sistema de informação que se pretende
desenvolver e fornece uma base prática para a implementação em computador
(Rumbaugh et all, 1991).
Um diagrama de classe é composto de seguintes elementos: classes de objectos,
relação de associação e generalização e multiplicidade.
Figura 7: Exemplo de diagrama de Classes. Fonte: (SOMMERVILLE, 2003).
1.7.8.5 Diagrama de implantação
O diagrama de implantação serve para descrever a arquitectura do sistema em
termos de hardware e a sua relação com os diferentes componentes (software). Onde estes
componentes precisam ser executados em algum recurso computacional que contenha
memória e um processador. Portanto, este diagrama também pode se chamar de diagrama
37
de instalação ele define em que recursos os diferentes estarão localizados. A figura 8
mostra um exemplo de diagrama de implantação.
Figura 8: Exemplo de diagrama de implantação. Fonte: (PRESSMAN, 2006).
1.8 METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE
Um processo de software é um conjunto de actividades complexo que leva à
produção de um produto de software. Todos processos de software são complexos e como
todos os processos intelectuais e criativos dependem julgamento humano. Por isso um
processo deve ser adaptado e configurado conforme as necessidades das empresas,
projectos e das pessoas envolvidas. As metodologias estão divididas em dois grupos que
são:
Metodologias de Desenvolvimento Tradicionais;
Metodologias de Desenvolvimento Ágeis.
38
1.8.1 Metodologias de Desenvolvimento Tradicionais
As metodologias consideradas tradicionais, também são conhecidas como
“pesadas” isso por possuir uma característica principal que é de serem divididas em etapas
ou fases. Essas fases são bem definidas e englobam actividades como análise,
modelagem, desenvolvimento e testes. O objectivo principal das metodologias
tradicionais é a previsibilidade de requisitos do sistema, que tem uma grande vantagem
de fazer com que os projectos sejam bem planejados, facilitando a gestão do mesmo,
seguindo a mesma linhagem, com muita rigorosidade.
Um exemplo de metodologia tradicional: RUP.
1.8.1.1 Processo unificado
O Processo Unificado (RUP - Rational Unified Process) é uma metodologia de
análise e desenvolvimento de sistemas orientados a objecto baseada na notação UML. O
RUP é um processo bem definido e estruturado, pois define claramente quem é
responsável pelo que, como as coisas devem ser feitas e quando. Ele utiliza a UML para
especificar, modelar e documentar artefatos, e pelo facto de ser flexível e configurável,
pode ser utilizado em projectos de pequeno, médio e grande porte.
1.8.1.1.1 Características
O Processo Unificado reconhece a importância da comunicação com o cliente e
dos métodos directos para descrever a visão do cliente de um sistema (caso de uso). Ele
enfatiza o importante papel da arquitectura de software e ajuda o arquitecto a se
concentrar nas metas correctas, tais como compreensibilidade, abertura a modificações
futuras e reuso. O fluxo de processo é iterativo e incremental, dando a sensação
evolucionária que é essencial no desenvolvimento moderno do software. (PRESSMAN,
2006).
39
Dessa forma, as principais características do processo unificado são:
Ser baseado em casos de uso;
Ser centrado na arquitetura;
Utilizar o desenvolvimento iterativo e incremental.
1.8.1.1.2 Baseado em casos de uso
Um caso de uso é a descrição de uma sequência de ações realizadas por um actor
(pessoa, máquina ou sistema), que ocorrem enquanto o actor interage com o sistema.
Casos de uso ajudam a identificar o escopo do projecto e fornecem base para o
planejamento do projecto de software.
O processo unificado utiliza os casos de uso para dirigir todo o processo de
desenvolvimento, desde a concepção inicial do sistema até a aceitação dos componentes
(testes), com o objectivo de atender, especificamente, às necessidades dos usuários que
interagem com o sistema.
O RUP é orientado a casos de uso pelo facto deles não estarem ligados apenas à
especificação de requisitos, mas também ao projecto, implementação e testes do sistema,
pois:
Por meio deles é que são registrados os requisitos funcionais;
Eles auxiliam no planejamento das iterações;
Eles podem conduzir o projecto;
Os testes do sistema são baseados neles.
1.8.1.1.3 Centrado na arquitetura
A arquitetura baseia-se na visão de todos os modelos, ou seja, na visão do sistema
como um todo, destacando suas principais características sem entrar em detalhes. Muitos
40
factores influenciam na arquitetura do projecto, como por exemplo, a plataforma na qual
o software será implantado, os requisitos funcionais e não funcionais, entre outros.
Os casos de uso relacionam-se com a funcionalidade do sistema, enquanto a
arquitetura está ligada à forma deste. Para que se alcance um produto final com qualidade,
é necessário que a funcionalidade e a forma estejam balanceadas. Dessa forma, é
necessário que a arquitetura e os casos de uso estejam relacionados a tal ponto que os
primeiros sejam desenvolvidos de acordo com a arquitetura e esta por sua vez, forneça
um ambiente para que todos os requisitos dos casos de uso sejam realizados.
1.8.1.1.4 Iterativo e incremental
Para enfrentar a alta complexidade dos sistemas actuais se precisa dividir o
processo de desenvolvimento em vários miniprojectos. A cada um destes miniprojectos
se chama iteração e podem ou não representar um incremento no grau de terminação do
produto completo. Cada iteração deverá ser devidamente planeada, controlada e
executada (através de análise, desenho, implementação e testes). A planificação de
iterações faz com que, se reduzam os riscos e custos, se cumpra os prazos previstos, haja
motivação na equipe de desenvolvimento pois estes podem ver avanços claros a curto
prazo e o desenvolvimento pode adaptar-se a mudanças dos requisitos.
1.8.1.1.5 Fases do Processo Unificado
O Processo Unificado comporta as actividades de comunicação, planejamento,
modelagem, construção e implantação, porém as organiza de maneira diferente,
apresentando quatro fases distintas: concepção, elaboração, construção e transição.
41
Figura 9: Fases do processo unificado (RUP). Fonte: Adaptada de PRESSMAN (2006)
A fase de concepção ou iniciação abrange as actividades de comunicação com o
cliente e de planejamento. É nessa etapa que o analista faz o primeiro contacto com o
cliente em busca das primeiras informações sobre o sistema a ser desenvolvido, com o
objectivo de identificar os requisitos, definir o escopo do sistema e dar início ao
planejamento. O planejamento é composto pela avaliação da viabilidade de implantação
do sistema, dos recursos e dos principais riscos que devem ser gerenciados ao longo do
projecto, pela elaboração de um rascunho da arquitetura do sistema e pela definição do
cronograma e do custo do projeto.
A fase de elaboração inclui planejamento e actividades de modelagem do
processo. É nela que ocorre a expansão e o refinamento dos casos de uso elaborados pela
fase de concepção. Nessa fase também existe a preocupação de avaliar os riscos técnicos
e arquitecturais, incluindo cinco visões diferentes do software: o modelo de casos de uso,
o modelo de análise, o modelo de projecto, o modelo de implementação e o modelo de
implantação. Ao fim dessa fase, espera-se que a maior parte dos requisitos esteja
42
detalhada, o núcleo do sistema implementado com qualidade e os principais riscos
tratados. Dessa forma, será possível elaborar estimativas mais realistas.
A fase de construção tem como objectivo desenvolver os componentes de
software que tornam os casos de uso operacionais para os usuários finais. Para isso, os
modelos de análise e projecto que foram iniciados durante a fase de elaboração são
completados e os componentes são implementados conforme os requisitos levantados
para o incremento de software referente.
Além disso, conforme os componentes são implementados, são realizados testes
unitários e actividades de integração. Por fim, antes de passar para a fase seguinte, são
realizados testes de aceitação conforme as especificações dos casos de uso.
A fase de transição abrange os últimos estágios do processo e a primeira parte de
implantação. Nela, o software é implantado no cliente para testes e com o intuito de se ter
um feedback dos usuários em relação aos defeitos e modificações que se achem
necessárias. Além disso, são elaboradas informações de apoio, como manuais, guias de
solução de problemas e procedimentos de instalação. Ao final da fase de transição, o
incremento de software torna-se uma versão utilizável e de qualidade.
1.8.2 Metodologias de Desenvolvimento Ágeis
Os métodos ágeis são caracterizados pelo carácter de adaptação e é orientado a
pessoas. As metodologias ágeis comungam, na sua essência, o processo de
desenvolvimento centrado nas pessoas. As metodologias ágeis têm uma característica
comum de seu processo de desenvolvimento basear-se nas pessoas, orientado para
obtenção de artefactos a partir de iterações, o que, consequentemente, obriga o carácter
adaptativo durante o ciclo de desenvolvimento.
Exemplo de algumas metodologias ágeis:
43
Extreme Programming (XP);
Scrum;
Feature Driven Development (FDD);
Dynamic Systems Development Method (DSDM).
1.8.2.1 Extreme Programming (XP)
Extreme Programming (XP) é uma metodologia para o desenvolvimento de
software, que usa uma abordagem orientada a objectos com o paradigma de
desenvolvimento predilecto. O XP é uma disciplina de desenvolvimento de software
baseada em valores de simplicidade, comunicação, feedback e coragem. O XP inclui um
conjunto de regras e práticas que ocorrem no contexto de quatro actividades:
planeamento, projecto, codificação e teste. O Xp compreende seguintes fases:
Planeamento: é uma actividade que compreende a criação de um conjunto de
histórias que também são chamadas histórias de usuários que descrevem as características
e funcionalidades requeridas para o software a ser construído.
Projecto: o projecto Xp segue rigorosamente o princípio KIS (Keep It Simple -
mantenha a simplicidade). É sempre preferível um projecto simples em relação a uma
representação complexa. Se um difícil problema de projecto for encontrado como parte
do projecto de uma história. O XP recomenda a criação imediata de um protótipo
operacional dessa parte do projecto. Denominada solução de ponta, o protótipo do
projecto é implementado e avaliado.
Codificação: depois que as histórias forem desenvolvidas e o trabalho preliminar
de projecto for feito, a equipe não avança logo para a codificação, mas sim desenvolve
uma série de testes unitários que exercitarão cada uma das histórias que devem ser
incluídas na versão mais recente. O XP recomenda que duas pessoas trabalhem juntas em
44
sua estação de computador com vista a criar código concernente a uma história. Portanto
isto, fornece um mecanismo de solução de problemas em tempo real, isto porque duas
cabeças são frequentemente melhores do que uma e de garantia de qualidade em tempo
real.
Teste: os testes unitários são criados e devem ser implementados usando uma
metodologia que os permita ser automatizados. Os testes de aceitação XP, também são
chamados de testes do cliente, são especificados pelo cliente e focalizam as características
e funcionalidades do sistema global que são visíveis e passíveis de revisão pelo cliente.
Testes de aceitação são derivados das histórias do usuário que foram implementadas
como parte de uma versão de software.
1.8.3 Comparação entre Metodologias
O principal foco das metodologias tradicionais ou pesadas são os grandes
projectos, onde envolvem documentação, especificações e processo burocrático do
projecto, enquanto que as ágeis são centradas na adaptabilidade ou mudança, isto é, não
faz o uso excessivo de documentos e a burocracia que é usada nas metodologias
tradicionais é considerada desperdício de tempo.
45
1.9 Conclusões do capítulo
Neste capítulo, foi descrito sobre o método actual de gestão de informação do
armazém da faculdade de Ciências de Saúde, as dificuldades vivenciadas e uma proposta
de um sistema informático para a gestão da informação do armazém. Neste contexto
pode-se concluir que o sistema actualmente usado no armazém da FCS não garante a
eficiência e eficácia particularmente na execução dos processos controle, manutenção e
recuperação de informação, e que com a implementação de um sistema de informação,
implementado com algumas tecnologias apresentadas poderá trazer benefícios quer na
resolução do problema existente, assim como, trará benefícios adicionais no que concerne
a optimização do fluxo de informação permitindo mais agilidade e organização, mais
integridade e veracidade de informação, mais estabilidade e mais segurança de acesso à
informação.
A plataforma usada para o desenvolvimento deste sistema foi Java pela
portabilidade ou independência de plataforma e pela reutilização de código fonte. Isto
significa que o desenvolvedor não terá que se preocupar com as especificações do sistema
operacional.
A linguagem de programação usada foi Java devido a sua simplicidade, de alto
desempenho, pela sua independência de plataforma, por ser uma linguagem orientada a
objectos e principalmente pela independência de arquitectura e a reutilização de código
fonte.
As técnicas de levantamento de requisitos usadas foram a entrevista e a etnografia.
Usou-se a entrevista para certificar até que ponto o gestor está satisfeito com o método
actual e se pretende mudar esta metodologia ao passo da etnografia serviu para observar
o trabalho do cliente ou gestor e anotar as tarefas reais que o sistema proposto deve
46
atender e poder identificar as reais dificuldades que o sistema deve suprir. Dizer que não
existe uma técnica padrão para o levantamento de requisitos. Para efectuar um
levantamento mais preciso é importante ter o conhecimento de diversas técnicas para
fazer uma selecção que técnicas de levantamento aplicar a cada situação. O SGBD usado
foi o MYSQL por ser rápido, de código aberto, de baixo custo, disponibilidade de código
fonte, por ser multi-plataforma, e por ser um dos SGBD popular actualmente.
Também neste capítulo, abordou-se sobre metodologias de desenvolvimento de
software, na qual procurou-se descrever o foco de cada uma das metodologias.
No desenvolvimento de sistemas os métodos ágeis são viáveis para o
desenvolvimento de sistemas de pequenas e médias empresas enquanto que as
tradicionais são empregues nos grandes projectos, onde precisam especializações e
especificações maior do projecto.
Neste contexto, foi apresentada a comparação das metodologias, tendo critério de
avaliação, a garantia de qualidade do produto final e satisfação do usuário final. Portanto,
foi na base desta comparação que foi adoptada a metodologia RUP para o
desenvolvimento deste projecto, pelo facto, de RUP ser uma metodologia orientada a
objectos, baseado em casos de uso, centrado na arquitectura e por ser iterativo e
incremental, atendendo satisfatoriamente às expectativas do cliente.
47
CAPÍTULO II – DESENVOLVIMENTO DE SISTEMA
Neste capítulo apresenta-se a análise e desenho do sistema segundo a metodologia
utilizada, diagramas que compõem o sistema proposto. Também neste capítulo,
apresenta-se a utilização do sistema proposto, demonstrando assim alguns exemplos de
funcionalidades do sistema.
2.1 Requisitos Funcionais do sistema
[RF01] Autenticar utilizador: o sistema permitirá que o utilizador faça a
autenticação através de seu utilizador e a sua senha. Para acessar o sistema, o utilizador
deverá informar o nome de utilizador e senha correctos. Uma mensagem deverá ser
exibida caso o utilizador e senha estejam incorrectos ou caso o utilizador não exista.
[RF02] Alterar a senha: o sistema permitirá a alteração da senha de um utilizador.
O utilizador e a senha deverão ser validados para permitir o acesso ao sistema.
[RF03] Gerir entradas: o sistema permitirá que o utilizador faça controle do
material por meio de uma interface ou formulário de entrada e registre dados de material
que está entrando no armazém. Para efectuar ao controle de entrada o caso de uso possui
quatro operações de criar nova entrada, alterar entrada, pesquisar a entrada e excluir a
entrada.
[RF04] Gerir requisições: o sistema permitirá que utilizador faça o controle das
requisições ou a saída do material por meio de um formulário onde irá registrar todos os
dados de material requisitado no armazém. Para efectuar a requisição este caso de uso
dispõe de quatro operações criar nova requisição, alterar a requisição, pesquisar a
requisição e excluir a requisição.
48
[RF05] Gerir estoque: o sistema permitirá que utilizador faça o controle do
armazém por meio de um formulário onde irá registrar o material, a quantidade e a data
de validade do material. Neste caso de uso engloba quatro operações criar novo estoque,
alterar estoque, pesquisar estoque e excluir estoque.
[RF06] Criar novo material: o sistema permitirá que o utilizador adicione um
novo material em sua base de dados. Uma mensagem de erro será exibida caso o material
já exista.
[RF07] Alterar material: o sistema permitirá que o utilizador faça a alteração de
material em sua base de dados, possivelmente para actualização de informação de
manutenção.
[RF08] Pesquisar material: o sistema permitirá que o utilizador faça a consulta das
informações de material de forma detalhada, de modo que consiga visualizar todas as
informações registradas de um determinado material.
[RF09] Excluir material: o sistema permitirá que utilizador exclua um material em
sua base de dados. Uma mensagem deverá ser exibida o material excluído com sucesso
ou será exibida uma mensagem de erro caso este não tenha sido excluído com êxito.
[RF10] Emitir relatórios: o sistema permitirá que o utilizador possa gerar os
relatórios voltados para análises estatísticas, por exemplo, entrada, requisição e estoque
do material.
[RF11] Criar novo utilizador: o sistema permitirá que o administrador crie ou
adicione um novo utilizador em sua base de dados, informando seu perfil (permissões) e
um nome de utilizador e senha. Uma mensagem de erro deverá ser exibida caso o
utilizador já esteja adicionado.
49
[RF12] Alterar utilizador: o sistema permitirá que o administrador altere dados do
utilizador em sua base de dados, possivelmente para actualização ou manutenção da
informação de utilizador. Uma mensagem de erro deverá ser exibida caso o utilizador já
não tenha sido alterado com sucesso.
[RF13] Excluir utilizador: o sistema permitirá que o administrador exclua
utilizador em sua base de dados. Uma mensagem de erro deverá ser exibida caso o
utilizador não tenha sido excluído.
[RF14] Sair do sistema: o sistema disponibilizará a opção para fechar a sessão do
utilizador conectado.
2.2 Requisitos não Funcionais do sistema
[RNF01] Interface ou aparência do sistema: o sistema apresentará uma interface
objectiva, amigável, intuitiva e de fácil acessibilidade, isto é, suas informações e
funcionalidades deverão estar bem visíveis e disponíveis.
[RNF02] Portabilidade: o sistema deve ser independente de plataformas, isto é, o
sistema deve ser executado em múltiplas plataformas.
[RNF03] Eficiência: dar as respostas rápidas sobre as operações do utilizador.
[RNF04] Segurança: o sistema permitirá o controlo de acesso com vista a garantir
a segurança de informação. Para isso, o sistema deverá solicitar que o utilizador acesse o
sistema através de utilizador e sua senha.
[RNF05] Suporte: o sistema possuirá um manual de utilização.
[RNF06] Manutenção: o sistema deve ser desenvolvido nos moldes que permita
uma fácil manutenção com menos gastos em recursos.
50
2.3 Actores do sistema
Utilizador: Actor responsável pelas operações quotidianas do sistema, possuindo
autorizações que vão desde de criação de um novo material até a emissão de
relatórios.
Administrador: Actor que pode realizar um papel semelhante ao de utilizador,
além de ser o responsável pela administração do sistema, o que lhe confere
permissões extras para gerenciar todas as funcionalidades do sistema.
2.4 Diagramas de Caso de Uso do sistema
O diagrama de caso de uso é responsável por modelar ou relacionar as
funcionalidades existentes de um sistema. Os elementos principais de um diagrama de
caso de uso são elipses contendo o nome de caso de uso e elementos externos ou bonecos
chamados de actores, estes interagem com o sistema. Observe que no diagrama tem dois
actores do tipo utilizador e administrador, onde o utilizador é o actor que trabalha com as
operações rotineiras do sistema. O administrador é o actor que atribui as permissões aos
utilizadores comum do sistema e também pode adicionar, alterar e apagar um utilizador.
Ainda este administrador pode herdar as características do utilizador comum que lida com
as operações rotineiras.
Observe também que para comunicação de um caso de uso com actor ou caso de
uso igual se efectua por meio de relacionamentos extend e include, onde o include indica
que o caso de uso onde parte o relacionamento sempre inclui ou executa o comportamento
do outro caso de uso, que é representado pela seta. O extend é um relacionamento de
dependência que poderá ter o comportamento da classe herdada pela classe como se pode
ver na figura a seguir.
51
Figura 10: Diagrama de casos de uso do sistema. Fonte: Própria
uc UC
SISTEMA DE CONTROLE DE ESTOQUE
Autenticar
utilizador
Excluir material
Gerir entradas
Criar novo
material
Gerir
requisições
Gerir estoque
Alterar material
Pesquisar
material
Utilizador
Administrador
Criar novo
utilizador
Alterar
utilizador
Excluir
utilizador
Emitir
relatórios
Alterar senha
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«extend»
52
Figura 11: Diagrama de casos de uso gerir entradas e requisições. Fonte: Própria
uc UC-Gerir entradas e requisicoes
Gerir entradas
Criar nova
Alterar entrada
Pesquisar entrada
Excluir entrada
Utilizador
Administrador
Gerir requisições
Criar nova
requisição
Alterar requisição
Pesquisar
requisiçãoExcluir
requisição
«extend»
«extend»
«extend»
«extend»
«extend»
«extend»
«extend»
«extend»
53
Figura 12: Diagrama de casos de uso de gerir estoque e emitir relatórios. Fonte: Própria
Actor: é o nome do actor que inicia o caso de uso.
Pré-condições: uma pré-condição de um caso de uso define que hipóteses são
assumidas como verdadeiras para que o caso de uso tenha início. Ex. O usuário deve
inserir senha para ter acesso ao sistema.
Fluxo Principal: corresponde à descrição da sequência de passos do fluxo
principal. O fluxo principal descreve o que normalmente acontece quando o caso de uso
é realizado. O fluxo principal descreve o evento sequencial de caso de uso.
uc uc-Gerir estoque e Emitirrelatorios
Utilizador
Gerir estoque
Criar novo
estoque
Alterar estoque
Pesquisar estoque
Excluir estoque
Emitir relatórios
Emitir relatório de
entrada
Emitir relatório de
requisição
Emitir relatório de
estoque
Administrador
«extend»
«extend»
«extend»
«extend»
«extend»
«extend»
«extend»
54
Fluxos Alternativos: este tipo de fluxo é utilizado para descrever o que acontece
quando o actor faz uma escolha alternativa, diferente da descrita no fluxo principal, com
vista a alcançar o seu objectivo.
Fluxos de excepção: corresponde à descrição das situações de excepção, que
descrevem o que acontece quando algo inesperado ocorre na interação entre actor e caso
de uso.
Pós-condições: corresponde a um estado que o sistema alcança após o caso de
uso ter sido realizado.
Cada caso de uso foi proposto de forma minuciosa, descrevendo as actividades
com todos os fluxos principais e alternativos, conforme apresentam as tabelas abaixo:
Caso de Uso: Autenticar utilizador
Actores: Utilizador e Administrador
Pré-Condição O actor precisa estar autenticado no sistema.
Pós-Condição Continuar em sessão enquanto actor não escolher a
opção de terminar a sessão.
Fluxo Principal
1. Actor executa o sistema;
2. O sistema disponibiliza a interface de autenticação de utilizador;
3. O actor informa o utilizador e senha;
4. O sistema permite ao actor seu devido acesso e apresenta itens de menus
disponíveis;
5. O actor escolhe o menu desejado conforme o objectivo.
Fluxo Secundário
1. Utilizador e/ou senha inválidos;
55
2. O sistema exibe uma mensagem de erro;
3. O sistema retorna ao passo 3 do fluxo principal.
Tabela 1: Caso de uso autenticar utilizador. Fonte: Própria
Caso de Uso: Alterar senha
Actores: Utilizador e Administrador
Pré-Condição: O actor precisa estar autenticado no
sistema.
Pós-Condição: Continuar em sessão enquanto actor não
escolher a opção terminar sessão.
Fluxo Principal
1. Actor selecciona a opção alterar senha;
2. O sistema exibe a tela de alteração de senha;
3. O actor informa os dados da nova senha;
4. O actor confirma a inclusão e os dados são registrados.
Fluxo Secundário
1. Senha não é alterada;
2. O sistema exibe uma mensagem de erro;
3. O sistema volta ao passo 3 do fluxo principal.
Tabela 2: Caso de uso alterar senha. Fonte: Própria.
Caso de Uso: Gerir entradas
Actores: Utilizador e Administrador
Pré-Condição: O actor precisa estar autenticado no
sistema e ter seleccionado a opção entrada.
56
Pós-Condição: O sistema efectua a gestão de entrada de
material.
Fluxo Principal
1. O actor selecciona o menu entrada;
2. O sistema disponibiliza o formulário de entrada com as opções possíveis:
(Novo, Pesquisar, Alterar, Excluir e Sair);
3. O actor selecciona a opção desejada;
4. O actor encerra o caso de uso.
Fluxo Alternativo [ 3]: Novo
a. O sistema apresenta o formulário solicitando os dados cadastrais da entrada;
b. O actor preenche formulário com os dados solicitados;
c. O sistema guarda o cadastro da entrada;
d. O sistema exibe uma mensagem de guardado com sucesso.
Fluxo Alternativo [3]: Alterar
a. O sistema exibe as informações;
b. O actor efectua as devidas alterações e faz a confirmação;
c. O sistema guarda os dados alterados;
d. O sistema exibe uma mensagem de sucesso.
Fluxo Alternativo [3]: Pesquisar
a. O actor solicita a pesquisa da entrada;
b. O sistema exibe a entrada solicitada pelo actor e retorna ao passo 3.
Fluxo Alternativo [3]: Excluir
a. A entrada seleccionada é eliminada;
b. O sistema exibe uma mensagem de sucesso e retorna ao passo 4.
Fluxo Alternativo [ 3]: Sair
57
a. O sistema volta ao menu principal
Fluxo Secundário
1. A entrada não é guardada;
2. A entrada não é alterada;
3. A entrada não é excluída;
4. O sistema exibe a mensagem de erro.
Fluxo de Excepção [01]: Dado já existe
Caso o actor ao efectuar a alteração ou o cadastro introduza um dado que já existe, o
sistema exibe uma mensagem que o dado já existe.
Tabela 3: Caso de uso gerir entradas. Fonte: Própria.
Caso de Uso: Gerir requisições
Actores: Utilizador e Administrador
Pré-Condição: O actor precisa estar autenticado no
sistema e ter seleccionado a opção
requisição.
Pós-Condição: O sistema efectua a gestão de requisição
de material.
Fluxo Principal
1. O actor selecciona o menu requisição;
2. O sistema disponibiliza o formulário com as opções possíveis: (Novo,
Pesquisar, Alterar, Excluir e Sair);
3. O actor selecciona a opção desejada;
4. O actor encerra o caso de uso.
Fluxo Alternativo [ 3]: Novo
58
a. O sistema apresenta o formulário solicitando os dados cadastrais da requisição;
b. O actor preenche o formulário com os dados solicitados;
c. O sistema guarda o cadastro da requisição;
d. O sistema exibe uma mensagem de sucesso.
Fluxo Alternativo [3]: Alterar
a. O sistema exibe as informações;
b. O actor efectua as devidas alterações e faz a confirmação;
c. O sistema guarda os dados alterados;
d. O sistema exibe uma mensagem de sucesso.
Fluxo Alternativo [3]: Pesquisar
a. O actor solicita a pesquisa da requição;
b. O sistema exibe a requisição solicitada pelo actor.
Fluxo Alternativo [3]: Excluir
a. A requisição seleccionada é eliminada;
b. O sistema exibe uma mensagem de sucesso e retorna ao passo 4.
Fluxo Alternativo [3]: Sair
a. O sistema volta ao menu principal.
Fluxo Secundário
1. A requisição não é guardada;
2. A requisição não é alterada;
3. A requisição não é excluída;
4. O sistema exibe a mensagem de erro;
Tabela 4: Caso de uso gerir requisições. Fonte: Própria.
Caso de Uso: Criar novo material
59
Actores: Utilizador e Administrador
Pré-Condição: O actor precisa estar autenticado no sistema.
Pós-Condição: O novo material é adicionado ao sistema.
Fluxo Principal
1. O actor selecciona o menu cadastro;
2. O sistema disponibiliza as opções;
3. O actor selecciona na opção desejada;
4. O sistema exibe o formulário para efectuar o cadastro;
5. O actor preenche o formulário informando os dados solicitados;
6. O actor confirma a inclusão de material e os dados são guardados.
Fluxo Secundário
1. A operação não é confirmada;
2. O sistema exibe a uma mensagem de erro.
Tabela 5: Caso de uso criar material. Fonte: Própria.
60
Caso de Uso: Alterar material
Actores Utilizador e Administrador
Pré-Condição O actor precisa estar autenticado no sistema.
Pós-Condição O material precisa estar cadastrado no sistema
Fluxo Principal
1. O actor selecciona o material;
2. O sistema apresenta o material que precisa ser alterado;
3. O actor confere os dados do material a ser alterado;
4. O actor confirma a alteração e o material é alterado.
Fluxo Secundário
1. A operação não é confirmada;
2. O sistema exibe uma mensagem de erro.
Tabela 6: Caso de uso alterar material. Fonte: Própria.
Caso de Uso: Pesquisar material
Actores: Utilizador e Administrador
Pré-Condição O actor precisa estar autenticado no sistema.
Pós-Condição O material precisa estar cadastrado e a pesquisa feita no
sistema.
Fluxo Principal
1. O actor introduz o material que pretende pesquisar;
2. O actor selecciona na opção pesquisar;
3. O sistema exibe as informações do material desejado.
Fluxo Secundário
61
1. A operação não é concretizada;
2. O sistema exibe uma mensagem de erro.
Tabela 7: Caso de uso pesquisar material. Fonte: Própria.
Caso de Uso: Excluir material
Actores: Utilizador e Administrador
Pré-Condição: O actor precisa estar autenticado no sistema.
Pós-Condição: O material precisa estar cadastrado e a exclusão feita no
sistema.
Fluxo Principal
1. O actor selecciona o material que pretende excluir;
2. O actor clica em excluir;
3. O sistema exibe uma mensagem a perguntar se deseja excluir o material
seleccionado;
4. O actor confirma a exclusão e os dados são removidos.
Fluxo Secundário
1. A operação não é concretizada;
2. O sistema exibe uma mensagem de erro na tela.
Tabela 8: Caso de uso excluir material. Fonte: Própria.
Caso de Uso: Criar novo utilizador
Actores: Administrador
Pré-Condição: O actor precisa possuir privilégios de
administrador e estar autenticado no
sistema.
Pós-Condição: O utilizador é adicionado ao sistema.
62
Fluxo Principal
1. O actor clica em novo;
2. O sistema disponibiliza o formulário de utilizador;
3. Informa os dados do novo utilizador;
4. O actor clica em guardar e os dados são guardados;
5. O sistema exibe uma mensagem de dados inseridos com sucesso.
Fluxo Secundário
1. A operação não é realizada;
2. O sistema exibe mensagem de erro;
3. O sistema retorna ao passo 3 do fluxo principal.
Tabela 9: Caso de uso criar novo utilizador. Fonte: Própria.
Caso de Uso: Alterar utilizador
Actores: Administrador
Pré-Condição: O actor precisa possuir privilégios de
administrador e estar autenticado no
sistema.
Pós-Condição: O utilizador é alterado.
Fluxo Principal
1. O actor selecciona no utilizador;
2. O sistema disponibiliza os dados de utilizador;
3. O actor realiza a alteração dos dados de utilizador;
4. O actor clica em alterar e os dados são guardados;
5. O sistema exibe uma mensagem dados alterados com sucesso.
Fluxo Secundário
1. A operação não é realizada;
2. O sistema exibe mensagem de erro.
Tabela 10: Caso de uso alterar utilizador. Fonte: Própria.
63
Caso de Uso: Excluir utilizador
Actores: Administrador
Pré-Condição: O actor precisa possuir privilégios de
administrador e estar autenticado no
sistema.
Pós-Condição: O utilizador seleccionado é excluído do
sistema.
Fluxo Principal
1. O actor selecciona no utilizador;
2. O sistema disponibiliza os dados de utilizador;
3. O actor confere os dados de utilizador a ser excluído;
4. O actor clica em excluir e os dados são removidos;
5. O sistema exibe uma mensagem dados excluídos com sucesso.
Fluxo Secundário
1. A operação não é realizada;
2. O sistema exibe mensagem de erro.
Tabela 11: Caso de uso excluir utilizador. Fonte:Própria.
Caso de Uso: Sair do sistem
Actores: Administrador
Pré-Condição: O actor precisa possuir privilégios de
administrador e estar autenticado no
sistema.
Pós-Condição: Nenhuma.
Fluxo Principal
1. O actor selecciona menu sair;
2. A sessão é terminada.
64
Fluxo Secundário
1. A operação não é realizada;
2. O sistema exibe mensagem de erro na tela.
Tabela 12: Caso de uso sair do sistema. Fonte: Própria.
2.5 Diagrama de actividades
É um diagrama que mostra o fluxo de controle e daodos de uma actividade para a
outra, este diagrama abrange a visão dinâmica do sistema. Observe que o diagrama de
actividades apresenta uma forma simples de documentar as acções executadas em cada
caso de uso. Para o diagrama a seguir, para se efectuar ou registrar uma requisição, o
utilizador primeiro terá que executar o sistema, passar pela interface de autenticação. Para
isso se usa o diagrama de actividades para auxiliar a documentação de controle e fluxo de
actividades.
65
Figura 13: Diagrama de actividades do caso de uso gerir requisição. Fonte: Própria
act Requisicao
Base de dadosSistemaUtilizador
Início
Executar o sistema
Verificar a v alidade da
senha
Autenticar
Clicar no menu cadastro
Mostrar menus
disponiv eis
Escolher menu
requisição
Mostrar formulário
requisição
Preencher formulário
Clicar em guardar
Guardar dados da
requisição
Clicar em sair
Fim
Todos campos estão
preenchidos
Dados inseridos com
sucesso
[Dados incorrectos]
[Não][Sim]
[Dados correctos]
66
2.6 Diagrama de sequência
Como foi descrito no capítulo anterior, o diagrama de sequência é utilizado para
dois objectos trocar mensagens entre eles, ou seja, o diagrama de sequência permite aos
objectos de uma classe se comuniquem entre eles. Observe que no diagrama a seguir
temos as classes onde contém os objectos, no qual para efectuar o cadastro de requisição,
primeiro o utilizador clica na opção requisição, em seguida o utilizador faz a busca do
material, funcionário e departamento.
Figura 14: Diagrama de sequência da gestão de requisição. Fonte: Própria
sd Diagrama de sequencia de requisicao
Utilizador Cadastrar
Requisição
Material Funcionário Departamento
9: Buscar código do funcionário()
15: Retornar departamento()
4: Buscar código do material()
1: Clicar em requisição()
18: Guardar dados()
13: Clicar em seleccionar departamento()
16: Seleccionar departamento()
6: Mostrar material()
20: Clicar em sair()
12: Seleccionar funcionário()
19: Dados inseridos com sucesso()
11: Mostrar funcionário()
17: Inserir quantidade, observação e data()
3: Clicar em seleccionar material()
2: Mostrar tela de requisição()
8: Clicar em seleccionar funcionário()
5: Retornar material()
10: Retornar funcionário()
7: Seleccionar material()
14: Buscar código do departamento()
67
2.7 Diagrama de classes do sistema
Este é um dos diagramas mais utilizados e um dos mais importantes da UML,
servindo de apoio para a maioria dos outros diagramas. Como o próprio nome diz, o
diagrama de classes define a estrutura das classes utilizadas pelo sistema, determinando
os atributos e métodos possuídos por cada classe, além de estabelecer como as classes se
relacionam e trocam informações entre si. Na figura 15 é demonstrado um diagrama
contendo algumas das principais classes de objectos presentes no sistema proposto,
contendo as respectivas associações de dependência entre as mesmas. Estas classes
reflectem a base de dados implementada para o sistema proposto.
68
Figura 15: Diagrama de classes do sistema. Fonte: Própria
class Diagrama de classe
material
- descricao: string
- idmaterial: int
- material: string
- tipo: string
+ getDescricao(): string
+ getId_material(): int
+ getMaterial(): string
+ getTipo(): string
+ setDescricao(descricao): void
+ setId_material(id_material): void
+ setMaterial(material): void
+ setTipo(tipo): void
requisicao
- dataRequisicao: date
- id_dept: int
- id_material: int
- id_requisicao: int
- idfuncionario: int
- observacao: string
- quantidade: double
+ getDataRequisicao(): date
+ getId_funcionario(): int
+ getId_material(): int
+ getId_requisicao(): int
+ getIddept(): int
+ getObservacao(): string
+ getQuantidade(): double
+ setDatarequisicao(): void
+ setId_dept(id_dept): void
+ setId_funcionario(id_funcionario): void
+ setId_material(id_material): void
+ setId_requisicao(id_requisicao): void
+ setObservacao(observacaao): void
+ setQuantidade(quantidade): void
Funcionario
- apelido: string
- funcionario: string
- idFuncionario: int
+ getApelido(): string
+ getFuncionario(): string
+ getId_funcionario(): int
+ setApelido(apelido): void
+ setFuncionario(funcionario): void
+ setId_funcionario(id_funcionario): void
Departamento
- departamento: string
- id_dept: int
+ getDepartamento(): string
+ getId_dept(): int
+ setDepartamento(depto): void
+ setId_dept(id_dept): void
materialDanificado
- dataValidade: date
- id_danificado: int
- id_material: int
- quantidade: double
- tipo: string
+ getDataValidade(): date
+ getId_danificado(): int
+ getId_material(): int
+ getQuantidade(): double
+ getTipo(): string
+ setDataValidade(dataValidade): void
+ setId_danificado(id_danificado): void
+ setId_material(id_material): void
+ setQuantidade(quantidade): void
+ setTipo(tipo): void
Entradas
- dataentrada: date
- id_entrada: int
- id_fornecedor: int
- id_material: int
- preco_unitario: double
- quantidade: double
- total_pago: double
+ getDataEntrada(): date
+ getId_entrada(): int
+ getId_fornecedor(): int
+ getId_material(): int
+ getPreco_unitario(): double
+ getQuantidade(): double
+ getToal_pago(): double
+ setDataEntrada(): void
+ setId-fornecedor(): void
+ setId-material(): void
+ setId_entrada(): void
+ setPreco_unitario(): void
+ setQuantidade(): void
+ setTotal_pago(): void
Utilizador
- id_util izador: int
- login: string
- perfi l: string
- senha: string
+ alterar(): void
+ criar(): void
+ excluir(): void
Estoque
- dataValidade: date
- id_estoque: int
- id_material: int
- quantidade: double
+ getDataValidade(): date
+ getId_estoque(): int
+ getId_material(): int
+ getQuantidade(): double
+ setDataValidade(dataValidade): date
+ setId_estoque(id_estoque): int
+ setId_material(id_material): int
+ setQuantidade(quantidade): double
1
0..*
0..*
1
1
0..*
1
0..*
1 0..*
1
0..*
69
2.8 Diagrama Entidade Relacional do sistema
A modelagem entidade relacionamento foi desenvolvida por Peter Chen e
publicada em um artigo de 1976. Entretanto, variantes da ideia existiram anteriormente
e, posteriormente, foram imaginadas como entidades de dados de supertipo e subtipo e
relacionamentos de uniformização.
O processo é modelado como componentes (entidades) que são ligadas umas às
outras por relacionamentos que expressam as dependências e exigências entre elas.
Entidades podem ter várias propriedades (atributos) que as caracterizam. Diagramas
criados para representar graficamente essas entidades, atributos e relacionamentos são
chamados de diagramas entidade relacionamento.
Observe que no modelo da figura 16 contém nove tabelas nas quais todas elas têm
o relacionamento de um para muitos. Nota-se que cada tabela possui uma identificação
única conhecida como chave primária permitindo que o identificador seja recuperado,
alterado e ordenado. A chave primária é o identificador exclusivo ou único para todas
as informações em qualquer linha de tabela, e essa chave primária de maneira nenhuma
poderá ser nula e duplicada. E o campo da chave primária é inserido automaticamente na
base de dados.
Para este sistema é proposto o seguinte modelo conceitual de dados:
70
Figura 16: Modelo entidade relacionamento do sistema. Fonte: Própria
2.9 Diagrama de implantação do sistema
O diagrama de implantação determina as necessidades de hardware do sistema, as
características físicas como servidores, estações, topologias e protocolos de comunicação,
ou seja, todo o aparato físico sobre o qual o sistema deverá ser executado. A figura 17
demonstra o diagrama de implantação do sistema:
71
Figura 17: Diagrama de implantação do sistema. Fonte: Própria
Na Figura 11 são mostrados três nós:
Computador Cliente – é neste computador onde se encontra a interface da
aplicação através da qual, o utilizador pode usufruir das funcionalidades do
sistema.
Servidor de Base de Dados – é onde se encontra a base de dados na qual é
armazenada, recuperada toda a informação persistente, os procedimentos
armazenados que funcionam como serviços de recuperação de informação
requisitada pelo utilizador.
Impressora – é o dispositivo onde se pode imprimir a informação recuperada de
base de dados.
deployment Diagrama de implantação
COMPUTADOR CLIENTE SERVIDOR DE BASE DE DADOS
«device»
IMPRESSORA
<<JDBC-TCP/IP>>
<USB-TCP/IP>>
72
2.10 APLICAÇÃO DO SISTEMA
2.10.1 Utilização do sistema
As interfaces de um sistema são responsáveis pela interação entre homem e a
máquina. Elas devem prover ao utilizador a capacidade de realizar tarefas de forma
rápida, fácil e satisfatória. Uma visão geral do sistema será mostrada a seguir, através de
figuras contendo algumas telas deste.
2.10.2 Acesso ao sistema
O sistema possui dois perfis nomeadamente: utilizador e administrador. No
entanto, para acessar o sistema tais perfis terão acesso à mesma tela de autenticação. Na
figura, pode ser visualizada a tela de autenticação que é composta pela identificação do
utilizador e pela senha, a qual será disponibilizada inicialmente pelo administrador do
sistema no momento do cadastro de um novo utilizador.
Figura 18: Tela de acesso ao sistema. Fonte: Própria
1
2
4
3
73
Legenda:
1. Campo para inserção do nome de utilizador.
2. Campo para inserção de senha do utilizador.
3. Botão para efectuar a autenticação do utilizador.
4. Botão para efectuar o cancelamento de autenticação.
Figura 19: Tela de autenticação com dados do utilizador incorrectos. Fonte: Própria
2.10.3 Tela inicial do sistema
Ao efectuar acesso ao SICE – FCS é apresentada a tela inicial do sistema ilustrada
na figura 20, onde o utilizador fará escolha das opções desejadas. No menu cadastro é
onde o utilizador efectuará o cadastro de material, de entrada, requisição, departamento,
funcionário, fornecedor e estoque. No menu a seguir que é de consultas é onde o utilizador
fará as suas consultas tangente a requisição, entrada e estoque. No menu relatório é onde
que o utilizador terá possibilidade de emitir os relatórios como de entrada, requisição e
estoque. A seguir o menu configurações está incumbido a proporcionar ao administrador
74
efectuar o cadastro de utilizadores e controle de acessos dos mesmos. Já no menu ajuda
é onde o utilizador terá oportunidade de fazer a recuperação de base de dados, acessar o
manual de orientação do sistema e poderá ver as informações do sistema. No último menu
o utilizador tem a posse de terminar a sessão, isto é fechar a sua conexão ao sistema.
Figura 20: Tela inicial do sistema SICE. Fonte: Própria.
A figura 21, ilustra a tela de cadastro de requisição, onde a esquerda dela contém
o painel para efectuar o cadastro de requisição e a direita contém o painel de pesquisa,
onde o utilizador poderá efectuar a pesquisa e exclusão da requisição bastando assim
seleccionar a linha da tabela e os botões excluir e alterar serão habilitados de imediatos
para proceder com alteração ou exclusão da requisição. E o botão visualizar que está no
painel direito permite ao utilizador visualizar ou imprimir o relatório da requisição.
75
Figura 21: Tela de cadastro de requisição. Fonte: Própria
A figura 22, ilustra a tela de cadastro de entrada, onde esta tela possui as mesmas
características ou funcionalidades que a tela anteriormente descrita.
Figura 22: Tela de cadastro de entrada de material. Fonte: Própria
76
Figura 23: Relatório de requisição de material. Fonte: Própria
Figura 24: Relatório da entrada de material. Fonte: Própria
77
2.11 Conclusões do capítulo
Neste capítulo foi apresentado a análise e desenho do sistema proposto, mostrando
diferentes diagramas que ilustram o fluxo de actividades e funcionalidades do sistema.
Foram apresentados os principais formulários e algumas funcionalidades do sistema
mostrando assim a sua aplicação. Também foram apresentados alguns relatórios gerados
pelo sistema proposto.
78
CONCLUSÕES E RECOMENDAÇÕES
Os sistemas são desenvolvidos com intuito de gerar soluções e agregar facilidades
para todas empresas, desde da empresa de pequeno porte até de grande porte, com ou sem
fins lucrativos, proporcionando um bom ambiente e comodidade para o trabalho dos seus
colaboradores ou usuários nas mais diversas áreas como: educação, comércio, economia
entre outras.
O sistema de controle de estoque foi desenvolvido para atender uma parte da
Faculdade de Ciências de Saúde que é o armazém, que foi usado como subsídio de
pesquisa nesta monografia, sistema este que irá auxiliar o gestor do armazém no
conhecimento e controle de estoque e de entradas e requisições de material.
O desenvolvimento deste sistema permitiu a participação na construção de um
software em todas as suas fases, desde o levantamento de requisitos até a fase de testes,
garantindo assim a aplicação prática do que foi aprendido, de forma teórica no percurso
acadêmico.
Um facto importante a relatar foi a possibilidade de trabalhar em interação com o
cliente, aprendendo assim a habilidade de trabalhar em equipe, habilidade esta que muito
é exigida no mercado actual de trabalho para qualquer área, mas principalmente na área
de informática, onde é necessário aprender a relacionar-se com os clientes e usuários, com
vista a extrair deles requisitos necessários para se conseguir desenvolver um software de
qualidade que mercado de software exige.
O armazém, antes do sistema desenvolvido, utilizava planilhas de Excel e fichas
de papel para realizar, de uma forma precária, a entrada, requisição, controle de estoque
e cadastro de material, o que gerava um grande acúmulo de papéis a serem arquivados,
além do desaparecimento dos mesmos e falta de credibilidade de relatório apresentado.
79
Com este sistema, todos os controles realizados em planilhas e fichas de papel
passarão a serem realizados no computador proporcionando tanto a organização quanto à
agilidade e precisão de dados para realizar os cadastros e emissão relatórios. Em suma, o
sistema proporciona facilidades tanto para o armazém quanto para os funcionários fazem
requisições.
Também com o desenvolvimento deste sistema permitiu demonstrar metodologias
e tecnologias para desenvolver um sistema com vista a aperfeiçoar o controle de estoque
do armazém. Pode-se dizer que o desenvolvimento de um sistema, requer tempo,
paciência e muita dedicação. Neste projecto, foram realizadas pesquisas bibliográficas
com intuito de alcançar o maior conhecimento possível tangente as tecnologias e
metodologias necessárias para o desenvolvimento do sistema.
Recomenda-se que se termine com a documentação do sistema com vista a
facilitar o uso do sistema desenvolvido e garanta uma base para manutenções e em caso
de se pretender incrementar novas funcionalidades ao sistema, uma vez que o modelo ou
as regras de negócios são dinâmicos com o passar do tempo.
Para usufruir deste sistema o utilizador terá que possuir um computador com uma
resolução mínima de (1200X600).
O trabalho está aberto a novas mudanças, restruturação e ideias dependendo da
tendência tecnológica e das necessidades futuras do armazém.
80
REFERÊNCIAS BIBLIOGRÁFICAS
BEZERRA, E. Princípios de análise e projecto de sistemas com UML. 3. ed. Rio de
Janeiro: Campus Elsevier, 2006.
CERVO, A. L.; BERVIAN, P. A. Metodologia científica. 5. ed. São Paulo: Pearson
Prentice Hall, 2002.
CHIAVENATO, I. Introdução à teoria geral da administração: uma visão abrangente
da moderna administração das organizações. 7. ed. Rio de Janeiro: Elsevier, 2003.
Disponivel em:
<http://www.ebah.com.br/search?q=teoria+geral+de+sistemas+administra%C3%A7%C
3%A3o>. Acesso em: 20 Março 2016.
CHIAVENATO, I. Administração de materiais: uma abordagem introdutória. 3. ed.
Rio de Janeiro: Elsevier, 2005.
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 6. ed. São Paulo:
Pearson Addison Wesley, 2011.
LAKATOS, E. M.; MARCONI, M. D. A. Metodologia científica. 4. ed. São Paulo:
Atlas, 2004.
LAKATOS, E. M.; MARCONI, M. D. A. Metodologia do trabalho científico:
Procedimentos básicos, pesquisa bibliográfica, projecto, relatório, publicações e trabalhos
científicos. 6. ed. São Paulo: Atlas, 2006.
81
LARMAN, C. Utilizando UML e Padrões. 3. ed. São Paulo: Pearson Education, 2005.
LAUDON, K. C.; LAUDON, J. P. Sistemas de informação gerenciais. 7. ed. São Paulo:
Pearson Prentice Hall, 2007.
MARIA, T. Teoria geral de sistemas de informação. [S.l.]: [s.n.], 2006. Disponivel em:
<http://docplayer.com.br/75505-Thais-maria-yomoto-ferauche-professora-thais-gmail-
com-2006.html>. Acesso em: 21 Março 2016.
NUNES, M.; O'NEILL, H. Fundamental de UML. 3. ed. Lisboa: Editora de Informática,
2004.
PRESSMAN, R. S. Engenharia de software. 6. ed. Rio de Janeiro: McGraw-Hill, 2006.
RANTHUM, R. Modelagem e implementação de um sistema de informação para
otimização de exames diagnósticos por imagens. Ponta Grossa: Univeridade
Tecnológica Federal do Paraná : [s.n.], 2005.
REZENDE, A. D.; ABREU, A. F. Tecnologia da Informação Aplicada a Sistemas de
Informação Empresariais. São Paulo: Atlas, 2000.
SAMPAIO, A. B. C. Introdução à Ciência de Computação. Belém: [s.n.]. 1999.
SANTOS, R. R. D. Programando em Java 2 - Teoria & Aplicações. Rio de Janeiro:
Axcel Books , 2004.
SÊMOLA, M. Gestão de segurança da informação - Uma visão executiva. Rio de
Janeiro: Campus, 2003.
82
SILVA, A. M. R. D.; VIDEIRA, C. A. E. UML, Metodologias e Ferramentas CASE.
1. ed. Porto-Lisboa: Centro Atlântico, 2001.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Editora Pearson
Education, 2007.
VIANA, J. J. Administração de Materiais: um enfoque prático. São Paulo: Atlas, 2000.
WELLING, L.; THOMSON, L. Php e MySQL desenvolvimento Web. 6. ed. Rio de
Janeiro: Elsevier, 2005.
FERAUCHE,Thaís Maria. Teoria geral de sistemas e informação. 2006. Disponível
em:< http://docplayer.com.br/5975505-Thais-maria-yomoto-ferauche-professora-thais-
gmail-com-2006.html>; Acesso em 21 de março de 2016
DANCIU, Teodor; CHIRITA, Lucian. The Definitive Guide to JasperReports. New
York: Apress, 2007.
SANTOS, Robson. Tipos de sistema da informação. 2009. Disponível em:
<http://pt.slideshare.net/robssantoss/tipos-de-sistema-de-informao-2081471>; Acesso
em 21 de Março de 2016
RIBEIRO, Arléa Ayran de Souza. Aplicação de sistemas da informações geográficas
em empresas de saneamento. 2012. Disponível em:
<http://www.saneamentobasico.com.br/portal/wpcontent/uploads/2013/02/SISTEMAS-
DE-INFORMA%C3%87%C3%95ESGEOGR%C3%81FICAS-EM-EMPRESAS-DE-
SANEAMENTO.pdf >;Acesso em 22 de Março de 2016
83
SEJA bem vindo ao NetBeans. Disponível em: <http://netbeans.org/index_pt_BR.html>,
acesso em: 28 de Março de 2016. [S.L.: s.n.], 2016.
ORT, Edward. Introducing the Java EE 6 Platform. Disponível em:
<http://java.sun.com/features/>, acesso em: 8 de Abril de 2016. [S.L.: s.n.], 2016.
84
ANEXOS
ANEXO I: FORMULÁRIO UTILIZADO PARA ENTREVISTAR O GESTOR DO
ARMAZÉM DA FCS
Objectivo: Auxiliar a recolha de dados e levantamento de requisitos para o processo de
desenvolvimento de SICE para o armazém da FCS.
UNIVERSIDADE CATÓLICA DE MOÇAMBIQUE
FACULDADE DE CIÊNCIAS DE SAÚDE
1. Como é que funciona o processo de controle de estoque de material neste
armazém?
________________________________________________________________
________________________________________.
2. Qual é a informação que é registrada no momento da requisição e entrada de
material?
________________________________________________________________
________________________________________.
3. Dá-se o caso de um departamento fazer a requisição de material num dia e levantar
noutro?
________________________________________________________________
________________________________________.
85
4. Qual é a maior dificuldade que vivencia no controle de estoque do armazém?
________________________________________________________________
________________________________________.
5. Quando é que se elaboram o relatório mensal do armazém?
________________________________________________________________
__________________________________________.
6. Que tipo de informações precisa fornecer ao departamento de contabilidade?
________________________________________________________________
__________________________________________.
7. Que tipo de informações o contabilista pode ter acesso?
________________________________________________________________
_________________________________________.
8. Dá-se o caso de um determinado material deteriorar-se, qual é o tratamento deste?
________________________________________________________________
_________________________________________.
9. Qual é a condição necessária para que o funcionário de um determinado
departamento levante o material que requisitou?
________________________________________________________________
__________________________________________.
10. Qual é o método utilizado para controle de estoque no armazém?
________________________________________________________________
__________________________________________.
11. Qual a frequência de falta de material ou estoque no armazém?
________________________________________________________________
___________________________________________.
86
ANEXO II – CONTINUAÇÃO DO FORMULÁRIO
12. Há algum sistema (software) para controle de entrada e saída de material?
________________________________________________________________
______________________________________.
13. Qual a forma de localização de materiais utilizada no armazém?
________________________________________________________________
________________________________________.
14. Quando se sabe que foi antingido o estoque mínimo? Como é calculado?
________________________________________________________________
________________________________________.
Muito Obrigado!
87
ANEXO III: FORMULÁRIO DE CADASTRO DE ENTARADA DE MATERIAL NO
ARMAZÉM
88
ANEXO IV: FORMULÁRIO DE REQUISIÇÃO DE MATERIAL NO ARMAZÉM
Top Related