Você está na página 1de 102

Helemano Ernesto Chilengue

Concepção e Implementação de um Sistema de Gestão Estoque – Caso de Estudo: PALE


CONSTRUÇÕES – JHF CONSTRUFACIL LDA

Licenciatura em Ensino de Informática

Universidade Pedagógica
Maputo
2016
Helemano Ernesto Chilengue

Concepção e Implementação de um Sistema de Gestão Estoque – Caso de Estudo: PALE


CONSTRUÇÕES – JHF CONSTRUFACIL LDA

Monografia Científica apresentada ao Departamento de


Informática, Escola Superior Técnica, Delegação de
Maputo para obtenção do grau académico de Licenciatura
em Ensino de Informática.
Supervisor:
MSc. Célio Barbosa Sengo

Universidade Pedagógica
Maputo
2016
Índice
Lista de Tabelas ................................................................................................................................ i
Lista de Figuras ............................................................................................................................... ii
Lista de Abreviaturas e Siglas ......................................................................................................... v
Declaração de Honra ...................................................................................................................... vi
Dedicatória..................................................................................................................................... vii
Agradecimentos ............................................................................................................................ viii
Resumo ........................................................................................................................................... ix
Abstract ............................................................................................................................................ x
CAPÍTULO I: INTRODUÇÃO ................................................................................................... 1
1.1. Formulação do Problema .................................................................................................. 2
1.2. Objectivos ......................................................................................................................... 4
1.2.1. Objectivos Gerais ...................................................................................................... 4
1.2.2. Objectivos Específicos .............................................................................................. 5
1.3. Questões de Pesquisa ........................................................................................................ 5
1.4. Hipóteses ........................................................................................................................... 5
1.5. Importância do Tema ........................................................................................................ 6
1.6. Justificativa ....................................................................................................................... 6
1.7. Metodologia ...................................................................................................................... 7
1.8. Técnicas e Instrumentos de Recolha de Dados ................................................................. 8
1.9. Material necessário para a concepção e modelagem do sistema ...................................... 9
1.9.1. Software ..................................................................................................................... 9
1.9.2. Hardware ................................................................................................................... 9
1.10. Estrutura do Trabalho .................................................................................................. 10
CAPÍTULO II: REVISÃO BIBLIOGRÁFICA........................................................................ 11
2,1. Engenharia de Software .................................................................................................. 11
2.1.1. Ciclo de Vida de Desenvolvimento ......................................................................... 11
2.2. Sistema ............................................................................................................................ 13
2.2.1. Tipos de Sistemas .................................................................................................... 13
2.2.1.1. Sistema Fechado .................................................................................................... 13
2.2.1.2. Sistema Aberto ...................................................................................................... 13
2.2.1.3. Sistemas de Informação ......................................................................................... 14
2.2.3 Requisitos ................................................................................................................ 14
2.2.3.1. Requisitos Funcionais ............................................................................................ 15
2.2.3.2. Requisitos Não Funcionais .................................................................................... 15
2.3. Sistema de Gestão de Banco de Dados – SGBD ............................................................ 15
2.3.1. Características de um SGBD ........................................................................................ 15
2.3.2. Banco de Dados ............................................................................................................ 16
2.3.2.1. Projecto de Banco de Dados .................................................................................. 16
2.3.3. MySQL ....................................................................................................................... 17
2.4. A Linguagem SQL .......................................................................................................... 17
2.5. Metodologia de Desenvolvimento de Software .............................................................. 18
2.5.1. Metodologia Orientada a Objectos (OO) ..................................................................... 18
2.5.1.1. Classes ................................................................................................................... 19
2.5.1.2. Objectos ................................................................................................................. 19
2.5.1.3. Polimorfismo ......................................................................................................... 19
2.5.1.4. Herança .................................................................................................................. 19
2.5.1.5. A Linguagem Java ................................................................................................. 20
2.6. A Linguagem UML......................................................................................................... 21
2.6.1. Principais Diagramas UML .......................................................................................... 21
2.6.1.1. Diagrama de Caso de Uso ..................................................................................... 21
2.6.1.2. Diagrama de Sequência ......................................................................................... 22
2.6.1.3. Diagrama de Classes .............................................................................................. 22
2.6.1.4. Diagrama de Estado ............................................................................................... 23
2.6.1.5. Diagrama de Actividade ........................................................................................ 24
2.6.1.6. Diagrama de Componente ..................................................................................... 24
2.7. Padrões de Projectos ....................................................................................................... 25
2.7.1. Padrão MVC ................................................................................................................. 25
2.8. Processo Unificado da Rational - RUP ........................................................................... 26
2.8.1. Características do RUP................................................................................................. 26
2.8.2. Conceitos gerais ........................................................................................................... 27
2.8.3. Arquitectura do RUP .................................................................................................... 27
2.8.3.1. Dimensão Dinâmica: Fases ................................................................................... 28
2.8.3.1.1. Concepção ....................................................................................................... 29
2.8.3.1.2. Elaboração....................................................................................................... 29
2.8.3.1.3. Construção ...................................................................................................... 29
2.8.3.1.4. Transição ......................................................................................................... 30
2.8.3.2. Dimensão Estática: Workflows ............................................................................. 30
2.8.3.2.1. Modelagem de Negocio .................................................................................. 30
2.8.3.2.2. Requisitos........................................................................................................ 30
2.8.3.2.3. Análise e Desenho........................................................................................... 30
2.8.3.2.4. Implementação ................................................................................................ 31
2.8.3.2.5. Testes .............................................................................................................. 31
2.8.3.2.6. Implantação ..................................................................................................... 31
2.8.4. As Melhores práticas do RUP ...................................................................................... 31
2.8.4.1. Metodologia conduzida por casos de utilização .................................................... 31
2.8.4.2. Metodologia centrada numa arquitectura .............................................................. 31
2.8.4.3. Metodologia iterativa e incremental ...................................................................... 32
2.8.4.4. Metodologia que controla as mudanças................................................................. 32
2.8.4.5. Metodologia que verifica a qualidade ................................................................... 32
2.8.4.6. Metodologia que modela visualmente ................................................................... 33
2.8.5. Vantagens e Desvantagens do RUP ............................................................................. 33
2.8.5.1. Vantagens .............................................................................................................. 33
2.8.5.2. Desvantagens ......................................................................................................... 33
CAPÍTULO III: ANÁLISE E DISCUSSÃO DOS RESULTADOS ....................................... 35
3.1. Descrição do Local de Estudo......................................................................................... 35
3.2. Análise do Sistema Actual de Gestão de Estoque e suas Limitações ............................. 35
3.3. Concepção e Implementação do Sistema de Gestão de Estoque .................................... 36
3.4. Eficiência do Sistema de Informação de Gestão de Estoque. ......................................... 38
3.5. Proposta de um sistema de gestão de base de dados e medidas de segurança e
integridade da informação para processo de gerenciamento de estoque. .................................. 42
3.5.1. Proposta da Base de Dados ...................................................................................... 42
3.5.2. Medidas de Segurança e Integridade da Informação ................................................... 43
3.5.2.1. Confidencialidade .................................................................................................. 43
3.5.2.2. Integridade ............................................................................................................. 44
3.5.2.3. Disponibilidade...................................................................................................... 44
CAPÍTULO IV: CONCLUSÃO, LIMITAÇÕES E RECOMENDAÇÕES........................... 46
4.1. Conclusão ............................................................................................................................... 46
4.2. Limitações ........................................................................................................................... 47
4.3. Recomendações................................................................................................................... 47
BIBLIOGRAFIA ......................................................................................................................... 48
ANEXOS....................................................................................................................................... 52
i

Lista de Tabelas

Tabela 1: Plano de Actividades do Sistema de Informação de Gestão de Estoque (baseado na


metodologia RUP) ......................................................................................................................... 59

Tabela 2: Requisitos de Negocio ................................................................................................... 61

Tabela 3: Requisitos Funcionais do Sistema ................................................................................. 62

Tabela 4: Requisitos Não Funcionais do Sistema ......................................................................... 62

Tabela 5: Descrição da estrutura da aplicação ............................................................................... 86


ii

Lista de Figuras

Figura 1: Modelo Cascata .............................................................................................................. 12

Figura 2: Ciclo de vida de desenvolvimento de um software........................................................ 13

Figura 3: Exemplo do Modelo Conceitual .................................................................................... 17

Figura 4: Exemplo do Modelo Lógico .......................................................................................... 17

Figura 5: Exemplo de Classe ......................................................................................................... 19

Figura 6: Exemplo de Objecto ....................................................................................................... 19

Figura 7: Exemplo de Herança e Polimorfismo ............................................................................ 20

Figura 8: Exemplo de Diagrama de Caso de Uso .......................................................................... 22

Figura 9: Exemplo de Diagrama de sequência .............................................................................. 22

Figura 10: Exemplo de Diagrama de Classe ................................................................................. 23

Figura 11: Exemplo de Diagrama de Estado ................................................................................. 23

Figura 12: Exemplo de Diagrama de Actividade .......................................................................... 24

Figura 13: Exemplo de Diagrama de Componente ....................................................................... 25

Figura 14: Dimensões do RUP ...................................................................................................... 28

Figura 15: As quatro fases do RUP ............................................................................................... 28

Figura 16: Tela Principal ............................................................................................................... 37

Figura 17: Formulário de Cadastro de materiais ........................................................................... 39


iii

Figura 18: Restrição no cadastro de vendas .................................................................................. 40

Figura 19: Recibo de venda ........................................................................................................... 41

Figura 20: Relatório de todas vendas efectuadas........................................................................... 42

Figura 21: Banco de dados do SIGE ............................................................................................. 43

Figura 22: Tela de Login ............................................................................................................... 44

Figura 23: Ficha de pedido de cotação de material ....................................................................... 53

Figura 24: Ficheiro Excel de Registo de Materiais ....................................................................... 54

Figura 25: Ficheiro Excel de Registo de Materiais ....................................................................... 55

Figura 26: Questionário dirigido à JHFCONSTRUFACIL LDA ................................................. 56

Figura 27: Funcionalidades básicas param o SIGE proposto ........................................................ 57

Figura 28: Diagrama de Caso de Uso Preliminar .......................................................................... 64

Figura 29: Caso de Uso do Sistema de Informação de Gestão de Estoque ................................... 65

Figura 30: Diagrama de Actividade Autenticar ............................................................................. 66

Figura 31: Diagrama de Actividade Cadastrar Venda ................................................................... 67

Figura 32: Diagrama de Sequencia - Autenticação ....................................................................... 68

Figura 33: Diagrama de Sequencia Cadastrar Venda .................................................................... 69

Figura 34: Diagramas de estado .................................................................................................... 70

Figura 35: Diagrama de componente............................................................................................. 71

Figura 36: Diagrama de Classes .................................................................................................... 72

Figura 37: Diagrama Entidade Relacionamento (DER) ................................................................ 73


iv

Figura 38: Tela de Cadastro de Materiais ...................................................................................... 77

Figura 39: Tela de Cadastro de Vendas ......................................................................................... 78

Figura 40: Tela de Cadastro de Clientes ........................................................................................ 79

Figura 41: Tela de Cadastro de Fornecedores ............................................................................... 80

Figura 42: Tela de Cadastro de Categorias .................................................................................... 81

Figura 43: Tela de Cadastro de Unidades ...................................................................................... 82

Figura 44: Tela de Cadastro de Usuários....................................................................................... 83

Figura 45: Tela de Consulta de Vendas ......................................................................................... 84

Figura 46: Estrutura da Aplicação ................................................................................................. 85


v

Lista de Abreviaturas e Siglas

DER - Diagrama Entidade Relacionamento

ESTEC - Escola Superior Técnica

HDD - Hard Disc Drive

LDA - Limitada

OO - Orientado a Objectos

RAM - Random Access Memory

RF - Requisito Funcional

RNF - Requisito Não Funcional

SE - Standard Edition

SI - Sistemas de Informação

SIGE - Sistema de Informação de Gestão de Estoque

SGBD - Sistema Gerenciador de Banco de Dados

TIC - Tecnologia de Informação e Comunicação

UP - Universidade Pedagógica
vi

Declaração de Honra
Declaro que esta Monografia Científica é resultado da minha investigação pessoal e das
orientações do meu supervisor, o seu conteúdo é original e todas as fontes consultadas estão
devidamente mencionadas no texto, nas notas e na bibliografia final.
Declaro ainda que este trabalho não foi apresentado em nenhuma outra instituição para obtenção
de qualquer grau académico.

Maputo, Março de 2016


_______________________________________
(Helemano Ernesto Chilengue)
vii

Dedicatória
Dedico este trabalho à minha mãe Arminda Francisco pela educação, conselhos e transmissão
de valores morais e cívicos imprescindíveis.
Aos meus irmãos, Francisco, Octávio, Casimiro, Zefanias, Benilde, Victoria e Joana que
serviram de suporte nos momentos difíceis e que sempre me apoiaram.
viii

Agradecimentos
A Deus, por ter-me proporcionado vida, saúde, inteligência e por todas realizações até aqui
alcançadas.
Um agradecimento especial para meus colegas com quem mantive contacto na UP, ao longo
destes quatro (4) anos de academia, explorando opiniões e críticas que me ajudaram a melhorar
a qualidade do presente trabalho científico.
Ao professor e orientador MSc Célio Barbosa Sengo por toda a sua orientação, pelo incentivo e
principalmente pela sua paciência porque sei que dei trabalho. Agradeço também aos nobres
docentes da ESTEC pela minha formação académica.
Agradeço à minha família, pela sua dedicação, carinho e apoio incondicional, sem a
colaboração da qual dificilmente teria conseguido este projecto, sem esquecer dos meus amigos,
de cujo convívio tive que prescindir para poder completar este nível.
E a todos que directa ou indirectamente contribuíram para a elaboração deste trabalho.
Muito Obrigado
ix

Resumo
A introdução de sistemas de informação optimiza o fluxo de informação relevante no âmbito de
uma organização, desencadeando um processo de conhecimento, tomada de decisão e de
intervenção na realidade.
O presente projecto foi desenvolvido para fornecer ferramentas capazes de auxiliar na diminuição
dos custos. Nele estão contidas ferramentas de cadastro de entrada e saída de materiais e
ferramentas de gerência que auxiliam na tomada de decisão e fornecem relatórios da situação
actual.
A metodologia usada neste projecto, a metodologia RUP, recomenda quatro fases para o
desenvolvimento de um sistema, nomeadamente: a Concepção, a Elaboração, a Construção e a
Transição. Concluídas estas quatro fases deverá culminar em um protótipo, que constitui uma
versão funcional do software sendo uma solução para o problema ou parte significativa do
mesmo, onde a metodologia usada no projecto preconiza uma linguagem padrão de modelação de
sistema sendo conhecida por UML.
Para a codificação do sistema foi definida a utilização do Java como linguagem de programação,
e o Banco de Dados MySQL para persistência de dados do sistema. Por fim foi feita a
codificação do sistema e em seguida realizados os testes com o objectivo de atender aos
requisitos funcionais do sistema e assegurar a sua qualidade.

Palavras-Chave: gerência, estoque, gerência de estoque, Java, RUP, UML.


x

Abstract
The introduction of information systems optimizes the flow of relevant information within an
organization, triggering a process of knowledge, decision making and intervention in reality.
This project was developed to provide tools that can assist in the reduction of costs. In it are
contained input registration tools and output materials and management tools that help in decision
making and provide the current situation reports
The methodology used in this project, the RUP methodology, recommends four phases for the
development of a system, including: the design, the development, Construction and Transition.
Completed these four stages should culminate in a prototype , which is a functional version of the
software is a solution to the problem or a significant part thereof, where the methodology used in
the project calls for a standard language system modeling is known for UML .
For the encoding of the system was defined the use of Java as a programming language, and the
MySQL database for persistence of system data. Finally the system was coded and then
performed the tests in order to meet the functional requirements of the system and ensure its
quality.

Key-words: Management, inventory, inventory management, Java, RUP, UML.


1

CAPÍTULO I: INTRODUÇÃO

Nas últimas décadas, o sector de Tecnologias de Informação e Comunicação (TIC’s) apresentou


um dinamismo notável. Esse dinamismo é resultado de mudanças estruturais, sobretudo,
tecnológicas, que alteraram não só a dinâmica económica das indústrias e nações, mas
acarretaram também transformações sociais relacionadas às formas de comunicação e de acesso à
informação (MONTEIRO, 1995).
Os Sistemas de Informação nas organizações visam dar suporte, confiabilidade e segurança de
modo a facilitar e ajudar de forma mais rápida no processamento da informação.
Neste contexto, a gestão eficaz só é possível quando suportada pelos SI que lhes assegurem
melhores conhecimentos necessário para um óptimo desenvolvimento das suas actividades bem
como, a organização, a monitorização das actividades, o controlo e a tomada de decisão. Para isso,
a abordagem metodológica no seu desenvolvimento deve ser voltada para a determinação das
necessidades, a organização, a disseminação e a representação da informação, com o objectivo de
optimizar a cadeia de valor do sistema.
O desenvolvimento de um sistema baseado em computação instrumentaliza a oportunidade de
melhorar os conhecimentos na área de informática, obtendo-se assim maior experiência e uma
melhor colocação no sector de negócios da contemporaneidade.
Considerando que a gestão de estoque é de suma importância para o bom desempenho das
actividades em qualquer que seja a empresa, este trabalho tem como objectivo apresentar a
concepção e a proposta de implementação de um sistema gerenciador de estoque na loja
JHFCONSTRUFACIL LDA pertencente à empresa PALE COSTRUÇÕES LDA, onde espera-se
uma gestão melhor de materiais e acesso rápido à informação.
2

1.1. Formulação do Problema

No entender de VERGARA (1997), problema é uma questão não resolvida, algo para o qual se
vai buscar uma resposta através de pesquisa. Pode estar referido a alguma lacuna epistemológica
ou metodológica percebida, a alguma dúvida quanto à sustentação de uma afirmação geralmente
aceita, à necessidade de pôr à prova uma suposição, a interesses práticos ou à vontade de
compreender e explicar uma situação quotidiana.
Na sociedade de informação o uso de novas tecnologias nas organizações traz uma nova
dinâmica para auxílio das mesmas. Neste sentido, a compreensão dos sistemas de informação no
que diz respeito a gestão de negócio das instituições tornou-se factor crucial para a tomada de
decisão e por consequente sucesso das organizações (KIELGAST, 1997).
As organizações hoje em dia tentam cada vez mais inovar e suprir suas necessidades no mercado
globalizado, com o avanço da informática no mundo vai ficando mais fácil essa inovação seja lá
em qual ramo a organização trabalhe, o planejamento de cada procedimento é importantíssimo
para que isso ocorra de forma eficiente e eficaz. A gestão de estoque é a parte essencial de uma
organização, pois lá são guardados todos os produtos, assim ali fica sendo outra empresa, deve-se
ter um maior cuidado com essa área, colocando uma pessoa específica para trabalhar na mesma e
informatizar os procedimentos para que ocorra a diminuição dos prejuízos e os trabalhos
realizados ali ficando mais eficientes e eficazes
A PALE CONSTRUÇÕES LDA é uma empresa Moçambicana, com capitais inteiramente
moçambicanos, registado oficialmente como empresa de Construção Civil e Obras Públicas,
produção e comercialização de materiais de construção, sedeada em Djonasse, a empresa possui
uma loja denominada JHFCONSTRUFACIL LDA que é inteiramente responsável pela
comercialização de materiais de construção. A loja utiliza um mecanismo manual para gerir o
fluxo de materiais, isto é, os gestores precisam de vasculhar os arquivos físicos consumindo
muito tempo dificultando assim o processo de controlo na manutenção, ressuprimento e saída de
materiais.
Os problemas deste processo manual de gestão são:
3

 Dificuldade de organização de dados (cadastro de clientes, fornecedores, materiais,


etc);
O processo actualmente usado na empresa permite apenas o Registro de entrada de materiais, não
se preocupando com a informação relativa ao seu fornecedor nem com o cliente que efectuou a
compra e, esse Registro é feito recorrendo-se de preferência no Microsoft Excel. Para cada tipo
de material existe um ficheiro diferente, levando deste modo muito tempo no Registro do mesmo).
(Vide anexo-1 fig-19 e fig-20).

 Falta de segurança da informação;


A informação referente ao estoque é mantida arquivos, não estando em uso nenhum mecanismo
ou medida de segurança para garantir que a informação não seja perdida, alterada ou acedida por
alguém não autorizado.
De acordo com CARNEIRO (2002), a segurança de informação tem como objectivo, propor um
conjunto de medidas e procedimentos, que têm por finalidade evitar que a informação seja
destruída, alterada ou acedida, incidental ou intencionalmente, de uma forma não autorizada.

 Falta de automação de processos;


Todo processo deste a entrada de materiais até a saída do mesmo, organização de dados e
consulta de informação é feito manualmente.
Segundo VEIGA e ZAMBALDE (2000), a automação confere mais produtividade, flexibilidade
e confiabilidade aos processos da empresa, proporcionando desta maneira claras vantagens
competitivas uma vez que consiste na informatização de todas as operações internas da empresa,
bem como a integração desses processos com o mundo externo e, até mesmo, com os
consumidores;

 Falta de um Sistema de Contingência


A informação referente à gestão de estoque fica registada em ficheiros Excel de forma estática e
redundante e, em caso de perda, incêndio ou outra calamidade que ocorra no local onde o
equipamento informático está instalado, a informação será permanentemente perdida, pois não
está em uso algum mecanismo de cópia de segurança (Backup) (Vide anexo-1 fig-19), onde
pode-se constatar que não existe nenhum plano de contingência.
De acordo com AMARO (2004), um plano de contingência também conhecido como plano de
recuperação de desastres, tem como objectivo propor um conjunto de medidas a serem tomadas
4

por uma empresa, incluindo a actuação de processos manuais, para fazer com que os seus
processos vitais voltem a funcionar plenamente, ou num estado minimamente aceitável, o mais
rápido possível, evitando assim uma paralisação prolongada que possa gerar maiores prejuízos à
empresa.

 O não uso de mecanismos que garantem a Confidencialidade e Integridade da


Informação.
O acesso à informação referente à gestão de estoque não está restringida, isto é, qualquer um que
consiga se apoderar dos ficheiros que contém a informação poderá fazer o que bem entender com
esta pois não está em uso nenhuma medida de autenticação para garantir que os dados sejam
acedidos apenas por pessoas autorizadas.
Para MAMEDE (2006), confidencialidade objectiva manter seguro o conteúdo de uma
mensagem, evitando que possa ser acedida por indivíduos não autorizados.
Já a integridade, segundo o mesmo autor, pode ser entendida como a detecção de alterações,
como adições ao conteúdo, modificação, eliminação parcial ou total por pessoas não autorizadas
a fazê-lo.
Verificados os problemas do sistema actual destacados, surge a necessidade de um estudo
aprofundado do mesmo, visto que não é eficiente, sem base de dados robusta e por vezes havendo
indisponibilidade no acesso à informação. É diante de tais constatações e de que tal informação é
também utilizada como uma arma estratégica indispensável para a obtenção de vantagens,
podendo ser o agente crítico que determina o sucesso ou decadência dos próprios serviços de
gestão que a presente pesquisa tem como objectivo principal “Conceber e propor a
implementação de um sistema de gestão de estoque” para melhorar o actual processo de
administração na empresa.

1.2. Objectivos

O desenvolvimento do presente trabalho conduz para a definição dos objectivos seguintes

1.2.1. Objectivos Gerais

 Conceber e implementar um sistema de informação de gerenciamento de estoque.


5

1.2.2. Objectivos Específicos

Constituem os objectivos específicos deste trabalho os a seguir:

 Identificar e descrever o processo de gestão manual usado na empresa;


 Conceber e apresentar uma proposta de implementação de sistema de gerenciamento de
estoque;

 Propor um sistema de gestão de base de dados e medidas de segurança e integridade da


informação para processo de gerenciamento de estoque.

1.3. Questões de Pesquisa

A presente concepção e proposta de implementação do Sistema de Gestão de Estoque (SGE)


deve-se aos problemas identificados, contudo, formulou-se algumas questões que ajudaram na
elaboração do trabalho:
 Quais as limitações do actual processo de gerenciamento de estoque na loja
JHFCONSTRUFACIL LDA?
 Qual a melhor tecnologia a utilizar para o sistema de gestão de estoque na loja
JHFCONSTRUFACIL LDA?
 Qual a medida de segurança que melhor se adequa ao sistema e garanta a integridade de
informações de estoque na loja JHFCONSTRUFACIL LDA?

1.4. Hipóteses

As Tecnologias de Informação e Comunicação (TIC’s), através dos Sistemas de Informação (SI)


promovem melhorias estratégicas das organizações para auxiliar funcionários na execução das
suas tarefas, e consequentemente melhorar o atendimento ao público.
Segundo MARCONI e LAKATOS (2003), as hipóteses constituem instrumentos poderosos para
o avanço da ciência, pois sua comprovação requer que se tornem independentes dos valores e
opiniões dos indivíduos As hipóteses são também importantes porque dirigem a investigação
indicando ao investigador o que procura investigar.
H1: O sistema vai melhorar o desempenho da JHFCONSTRUFACIL LDA no que referente à
gestão de estoque e busca de informação.
6

H2: A aplicação de uma arquitectura cliente-servidor pelos diversos departamentos da


JHFCONSTRUFACIL LDA com a finalidade de centralizar o banco de dados, eliminando a
redundância de dados que tem-se verificado e que poderá facilitar a manutenção do sistema.
H3: O uso de mecanismos de segurança como a encriptação ou criptografia de chaves para
garantir a confidencialidade, integridade e auditoria da informação assim como garantir a
contínua disponibilidade de dados com a aplicação de mecanismos de backup (cópias de
segurança)

1.5. Importância do Tema

As novas tecnologias trazem consigo múltiplas vantagens para os profissionais nos diferentes
sectores, sendo importante optarmos por mecanismos e soluções que facilitem as actividades do
homem e promovam o dinamismo, eficácia, eficiência à imagem de profissionalismo da
organização.

A concepção deste sistema direcciona-se no melhoramento do processo de gestão de estoque na


JHFCONSTRUFACIL LDA, primeiramente vai agilizar o acesso de informação referente ao
estoque, fazendo com que esta esteja disponível sempre que necessária, ou simplesmente caso o
gerente ou o vendedor necessite fazer consultas ou impressão de relatórios em tempo.

O novo sistema contribuirá também na gestão central da loja no controle do fluxo dos clientes,
elaboração de projectos e estratégias, permitindo a tomada das devidas decisões o mais rápido
possível.

1.6. Justificativa

Em um mundo cheio de mudanças, a importância dos Sistemas de Informação (SI) torna-se cada
vez mais presente frente as necessidades impostas pela concorrência. Para se tomar boas decisões,
além de conhecer bem o negócio da empresa, e preciso a existência de um rápido fluxo de
informação, para que assim a empresa torne-se competitiva. Esse fluxo de informação tem sido
ponto decisivo para a permanência de muitas empresas no mercado que, hoje, é caracterizado
pelo aumento dos processos informatizados.
7

Segundo ROSINI e PALMISANO (2008), a informação é, hoje, factor fundamental para as


organizações, os administradores, todos os indivíduos. Quando se fala em mercado aberto e
comum, competitividade, concorrência e qualidade, percebe-se que nada disso seria possível sem
um sistema de informação, pois é de fundamental importância a interacção das informações em
qualquer organização.
A JHFCONSTRUFACIL LDA sendo uma loja de comercialização de materiais de construção,
este sistema de gestão de estoque, permitirá à loja um maior controle de todos os itens que a
mesma possui, tendo assim a noção do que deve ser remanejado e/ou comprado para completá-lo
(estoque). A gestão de estoque facilitará as actividades intrínsecas da empresa, fazendo com que
a gerência aja com mais segurança, agilidade e controle.

1.7. Metodologia

Metodologia envolve princípios filosóficos que guiam uma gama de métodos que utilizam
ferramentas e práticas diferenciadas para realizar algo.
Para SILVA e MENEZES (2001) pesquisa é definida como um conjunto de acções que tem como
objectivo proporcionar respostas para determinados problemas propostos.
A pesquisa é realizada quando se tem um problema e não se tem informações para solucioná-lo.
SILVA e MENEZES (2001) afirmam ainda que existem várias formas de classificar uma
pesquisa, podendo-se classificar quanto à natureza da pesquisa, forma de abordagem do problema,
aos seus objectivos e quanto aos procedimentos técnicos.
a). Quanto à natureza da pesquisa;
Quanto à natureza da pesquisa, a pesquisa é aplicada ou tecnológica;
Para GIL (1999), a pesquisa aplicada objectiva gerar conhecimentos para aplicação prática,
dirigida à solução de problemas específicos. Este tipo de pesquisa envolve verdades e interesses
locais.
b). Quanto a forma de Abordagem;
Quanto a forma de abordagem, a pesquisa é Qualitativa.
Conforme Gil (1999), o uso da abordagem qualitativa propicia o aprofundamento da investigação
das questões relacionadas ao fenómeno em estudo e das suas relações, mediante a máxima
8

valorização do contacto directo com a situação estudada, buscando-se o que era comum, mas
permanecendo, entretanto, aberta para perceber a individualidade e os significados múltiplos.
c). Quanto aos objectivos
Quanto aos objectivos, a pesquisa é descritiva.
Na concepção de GIL (1999), a pesquisa descritiva têm como objectivo a descrição das
características de determinada população ou fenómeno, ou o estabelecimento de relações entre
variáveis. Uma de suas características mais significativas está na utilização de técnicas
padronizadas de colecta de dados.
d). Quanto aos procedimentos técnicos
Quanto aos procedimentos técnicos, a pesquisa é Bibliográfica.
Ainda em GIL (1999), a pesquisa bibliográfica é desenvolvida com base em material já elaborado,
constituído principalmente de livros e artigos científicos.
Para o concepção e implementação do sistema recorreu-se à metodologia Orientada à Objectos,
esta metodologia, visualiza o mundo como um conjunto de objectos que interagem entre si,
apresentam características distintas representadas pelos seus atributos (dados) e operações
(processos), especificamente a metodologia RUP.

1.8. Técnicas e Instrumentos de Recolha de Dados

De forma a buscar respostas certas e confiáveis sobre o presente trabalho, foram escolhidos os
seguintes instrumentos de recolha de dados:

 Observação directa e participante sobre o processo de Gestão de estoque;


“Observação é uma técnica de recolha de dados, utilizando os sentidos, de forma a obter
informação de detalhados aspectos da realidade”. (MARKONI & LAKATOS, 2002, p.97).
A observação directa obriga ao investigador a ter um contacto directo com a realidade,
auxiliando-o a identificar e a obter provas a respeito dos objectivos sobre os quais os indivíduos
não têm consciência, mas que orientam o seu comportamento.

 Questionário direccionado aos funcionários da empresa, concretamente, os pertencentes


ao sector de gestão.
9

“Questionário é um instrumento de colecta de dados constituído por uma série ordenada de


perguntas, que devem ser respondidas por escrito e sem a presença do entrevistador”.
(MARCONI & LAKATOS, 2002, p.98).

1.9. Material necessário para a concepção e modelagem do sistema


1.9.1. Software

 SO Windows 7 (32 bits);

 Apache Tomcat 7.0.34;


 StarUml (versão 5.0.2, 2005)

 Eclipse Luna 1.8.2. (32 bits);

 BrModelo (versão 2.0, 2007)


 NetBeansIDE (versão 8.0.2, 2014)

 MySQL (versão 5.1, 2008)

 Java SE Development Kit 7 (32 bits);


 iReport 4.0.0

 Mysql-connector-odbc-5.1.4-win32.msi (Para conexão com a base de dados);

 HeidiSql (Para facilitar o acesso aos dados na base de dados);

 Xamppserver (aplicativo usado como gerenciador de banco de dados);

1.9.2. Hardware

 Computador (processador Dual Core, 4GB de RAM, 50 GB de espaço livre de HDD);


 Impressora (Deskjet F1200 seriespcl) opcional.
10

1.10. Estrutura do Trabalho

O trabalho apresenta primeiro fundamentos teóricos que trazem conceitos sobre os SI, a
concepção e proposta de implementação de um Sistema de Informação de Gestão de Estoque
para a PALE CONSTRUNÇÕES – JHF CONSTRUFACIL LDA.

 No capítulo I - corresponde a introdução, onde faz-se a descrição do problema,


apresentam-se os objectivos, as hipóteses, a justificativa e a metodologia a ser usada.
 No capítulo II - corresponde a revisão bibliográfica, onde faz-se a abordagem teórica
sobre os diferentes aspectos relacionados ao tema em estudo.
 No capítulo III – corresponde ao desenvolvimento do trabalho, onde apresenta-se o caso
de estudo e discute se a proposta de implementação do trabalho.
 No capítulo IV – corresponde a conclusão e as recomendações, onde são apresentadas as
considerações finais do trabalho.
11

CAPÍTULO II: REVISÃO BIBLIOGRÁFICA

Hoje a informação é vista como a base do conhecimento, desta forma os SI facilitam e ajudam as
organizações na tomada de decisões. Com o desenvolvimento das TIC’s, as organizações
possuem várias e poderosas ferramentas que auxiliam a gestão das actividades por estas
desenvolvidas.

2,1. Engenharia de Software

Segundo SOMMERVILLE (2007), engenharia de software é uma das disciplinas da engenharia


que se ocupa da produção, manutenção e da operação do software. A engenharia de software
abrange todas as etapas de desenvolvimento de software, através de teorias, regras, ferramentas e
métodos que irão auxiliar na produção.
A engenharia de software tem como elementos principais:
I. Método - procedimento formal para a produção de um resultado. Um método define
as tarefas que serão realizadas e de que forma as mesmas deverão ser executadas.
Define que tecnologias e linguagens deverão ser adoptadas e os produtos que serão
produzidos.
II. Ferramenta - Instrumento ou sistema automatizado (software) para suportar a
realização de uma tarefa.
III. Paradigma - Maneira, estilo ou filosofia para a construção de software, envolvendo
um conjunto de princípios.

2.1.1. Ciclo de Vida de Desenvolvimento

Segundo REZENDE (2005), o ciclo de vida de alguns sistemas não é longo, portanto é necessário
entender que um software nunca estará totalmente acabado; ele poderá estar pronto para uso, mas
sempre sofrerá implementações e melhorias.
SOMMERVILLE (2007), ressalta que o ciclo de vida de software abrange algumas etapas que
são: análise, projecto, implementação, testes e manutenção. O modelo que descreve este ciclo de
vida é o modelo cascata, mais conhecido como modelo de ciclo de vida e tem cinco fases
denominadas de uma forma diferente, como ilustra a Figura 1
12

Figura 1: Modelo Cascata

Fonte: Adaptada de Sommerville (2007)


Para melhor especificação do sistema, é necessário que todos os requisitos e finalidades do
sistema sejam recolhidos na primeira fase, isto é, na fase da definição de requisitos. Na segunda
fase, é definida a arquitectura do sistema, tanto no aspecto software, com os requisitos funcionais,
quanto no aspecto hardware, com os requisitos não funcionais.
Na terceira fase, a fase de Implementação e Teste de unidade, o software começa a ser
implementado e testado, de maneira a verificar se atende aos requisitos para os quais ele foi
concebido. Na quarta fase, Integração e Teste de Sistema, o software é testado de uma forma
geral. E por último, na fase de Operação e Manutenção, após a entrega do software, podem ser
requeridas novas alterações, relacionadas a erros não detectados na fase de testes.
(SOMMERVILLE 2007).
As fazes de Manutenção concentram-se nas seguintes etapas:

 Correcções: Mudanças associadas à correcção de defeitos (Manutenção correctiva);


 Adaptações: Mudanças exigidas à medida que o ambiente do sistema evolui
(Manutenção Adaptava) e;
 Melhoramento Funcional: Produzidas por exigências variáveis do cliente (Manutenção
Perfeita);
 Prevenção:
 Software de computador se deteriora devido à modificações, e;
 Surge a manutenção preventiva, frequentemente chamada de reengenharia de
software;
13

 Em essência, a manutenção preventiva faz modificações nos programas de


computador, de modo que eles possam ser mais facilmente corrigidos, adaptadas e
melhoradas.
Figura 2: Ciclo de vida de desenvolvimento de um software

Fonte: Adaptada de Brookshear (2009)

2.2. Sistema

CHIAVEANATO (2004), conceitua sistema como um conjunto de elementos interdependentes


que interagem em conjunto no sentido de alcançar um objectivo comum.
Um sistema é definido como um conjunto de componentes e subsistemas que formam um todo e
quando interagem, obtêm objectivos comuns.

2.2.1. Tipos de Sistemas

CHIAVEANATO (2004), vem ainda ressaltar que há várias tipologias para classificar os sistemas.
Os sistemas quanto a natureza podem ser fechados ou abertos.

2.2.1.1. Sistema Fechado

O sistema fechado tem poucas entradas e poucas saídas com relação ao ambiente externo. Essas
entradas e saídas são bem conhecidas e guardam entre si uma relação de causa e efeito a uma
determinada entrada (causa) ocorre sempre uma determinada saída (efeito).

2.2.1.2. Sistema Aberto


14

Um sistema aberto apresenta relação de intercâmbio com o ambiente por meio de inúmeras
entradas e saídas. São adaptativos, isto é, para sobreviver devem reajustar-se constantemente às
condições do meio.

2.2.1.3. Sistemas de Informação

Assim, a partir do conceito de sistema torna-se entendível o conceito de Sistema de Informação


(SI) que BATISTA (2006) conceitua como um conjunto de componentes inter-relacionados
trabalhando juntos para colectar, recuperar, processar, armazenar e distribuir informação com a
finalidade de facilitar a planificação, o controlo, a coordenação, a análise e processo decisório em
organizações.

2.2.3 Requisitos

Requisitos têm um papel central no processo desenvolvimento de software, sendo considerados


um factor determinante para o sucesso ou fracasso de um projecto de software. O processo de
levantar, analisar, documentar, gerenciar e controlar a qualidade dos requisitos é chamado de
Engenharia de Requisitos.
Segundo SOMMERVILLE (2007), requisitos de um sistema são definidos como serviços que
devem ser fornecidos por esse sistema e as suas restrições operativas.
SOMMERVILLE (2007), ainda vem dizer que os requisitos são definidos durante as fases
iniciais do desenvolvimento do sistema como uma especificação do que deveria ser
implementado. São descrições de como o sistema deveria comportar-se.
Com base nessas e em outras definições, pode-se dizer que os requisitos de um sistema incluem
especificações dos serviços que o sistema deve prover, restrições sob as quais ele deve operar,
propriedades gerais do sistema e restrições que devem ser satisfeitas no seu processo de
desenvolvimento.
As várias definições acima apresentadas apontam para a existência de diferentes tipos de
requisitos. Uma classificação amplamente aceita quanto ao tipo de informação documentada por
um requisito faz a distinção entre requisitos funcionais e requisites não funcionais.
15

2.2.3.1. Requisitos Funcionais

Os requisitos funcionais descrevem o comportamento do sistema, aquilo que o sistema faz para o
usuário, e são descritos no RUP através de Casos de Uso.
Segundo SOMMERVILLE (2007) requisitos funcionais são serviços que o sistema deve prover,
descrevendo deste modo o ‘ o quê ‘ o sistema deve fazer.
Exemplos: O Sistema deve permitir o cadastro de Clientes, fornecedores, vendedores,
materiais e vendas;

2.2.3.2. Requisitos Não Funcionais

Ainda em SOMMERVILLE (2007,), requisitos não funcionais são restrições sobre os serviços ou
funções oferecidos pelo sistema.
Neste sentido, os requisitos não funcionais são muito importantes para a fase de projecto (design),
servindo como base para a tomada de decisões nessa fase.
Exemplos: Adaptabilidade; Confiabilidade; Eficiência; Flexibilidade; Performance; Portabilidade;
e Usabilidade.

2.3. Sistema de Gestão de Banco de Dados – SGBD

DATE (2004), conceitua SGBD como uma ferramenta que conecta o usuário ao banco de dados,
ou seja, tudo o que o usuário faz no banco de dados é intermediado por um SGBD. Tais
intervenções podem ser descritas como adição e remoção de arquivos ou tabelas e busca e
actualização de dados.
Existem vários SGBD dos quais como exemplo destes os seguintes:
 PostgresSQL;
 HSQLBD;
 MySQL;
 SQL-Server e;
 Outros.

2.3.1. Características de um SGBD


16

 Controlar redundância de dados;


 Compartilhamento de dados;
 Independência de dados;
 Segurança;
 Backup e recuperação à falhas;
 Forçar restrições de integridade;
 Aumentar a produtividade e disponibilidade;
 Flexibilidade, padronização.

2.3.2. Banco de Dados

Segundo DATE (2004), um banco de dados é uma colecção de dados, que representam
informação sobre um domínio específico. Em outras palavras, um banco de dados é um local
onde são armazenados dados necessários à manutenção das actividades de determinada
organização, sendo este repositório a fonte de dados para as aplicações actuais e as que vierem a
existir. Esses dados são mantidos por um sistema gerenciador de banco de dados (SGBD), onde
os usuários desse sistema podem realizar buscas, inserção e alteração nesses arquivos de banco de
dados.

2.3.2.1. Projecto de Banco de Dados

Na maioria dos projectos de banco de dados são utilizados dois modelos de banco de dados em
duas fases: o modelo conceitual e o modelo lógico, porém existe mais um modelo: o físico.

Segundo HEUSER (1998), na primeira fase do projecto de BD é abstraído o modelo conceitual,


na forma de um diagrama entidade-relacionamento. Este modelo captura as necessidades da
organização em termos de armazenamento de dados de forma independente de implementação,
como mostra a figura a seguir.
17

Figura 3: Exemplo do Modelo Conceitual

Fonte: Adaptada de Heuser (1998)


Na segunda fase, ainda segundo HEUSER (1998), é abstraído o modelo lógico, Modelo que
representa o banco de dados na maneira como é visto pelo usuário do SGBD. Ao contrário do
conceitual, depende do SGBD utilizado no projecto. E é gerado a partir do modelo conceitual
desenvolvido na primeira fase do projecto de banco de dados.
Figura 4: Exemplo do Modelo Lógico

Fonte: Adaptada de Heuser (1998)

2.3.3. MySQL

É um sistema de gestão de base de dados relacionais de código fonte aberto geralmente usado em
aplicações Web devido à velocidade, flexibilidade e fiabilidade, emprega a linguagem SQL para
processar os dados contidos na base de dados.

2.4. A Linguagem SQL

De acordo com DAMAS (2007), a SQL é uma linguagem que define e manipula dados, isto é,
com SQL podemos definir e construir tabela e relacionamentos e também manipular diversas
relações para obtenção de resultados desejados.

A linguagem SQL se divide em três principais grupos: DDL, DML e DCL.


18

a) DDL (Linguagem de Definição de Dados) trabalha com os objectos e tem os seguintes


comandos:
 ALTER – altera um objecto do banco de dados (uma tabela, por exemplo);
 CREATE – cria um objecto no banco de dados e;
 DROP – apaga um objecto do banco de dados.
Os comandos ALTER e CREATE, podem ser usados para index (índices) e view (visões).
b) DML (Linguagem de Manipulação de Dados), ela trabalha com as tuplas (linhas), seus
comandos são:
 SELECT – consulta os dados armazenados em uma tabela;
 INSERT – insere uma linha na tabela;
 DELETE – exclui linhas de uma tabela e;
 UPDATE – permite alterar quantas linhas de dados forem precisas em uma
tabela.
c) DCL (Linguagem de Controle de Dados) trabalha com os utilizadores, controla o acesso
aos dados, seus principais comandos são:
 GRANT – seta os privilégios, permite o acesso aos dados ao usuário e;
 REVOKE – remove os privilégios dado ao usuário.

2.5. Metodologia de Desenvolvimento de Software

Uma metodologia de desenvolvimento de software descreve como organizar actividades que


levam a produção de um sistema, inclui o uso de técnicas, notações, uma aproximação ao ciclo de
vida e um conjunto de procedimentos e regras de trabalho.

2.5.1. Metodologia Orientada a Objectos (OO)

A metodologia orientada a objectos mostra o sistema como uma colecção de classes e objectos
relacionados.
Esta metodologia é implementada pelo envio de mensagens a objectos. Ela reúne alguns
conceitos que precisam ser entendidos antes de iniciar uma programação orientada a objectos,
como classes, objectos, herança e polimorfismo.
19

2.5.1.1. Classes

Segundo RICARTE (2001), uma classe é um modelo que engloba objectos com mesmas
características. Uma classe define o comportamento de seus objectos através de métodos e as
características destes objectos através de atributos.
Figura 5: Exemplo de Classe

Fonte: Autor

2.5.1.2. Objectos

Objectos, segundo RICARTE (2001)) são ocorrências de uma classe, assim sendo, eles
representam coisas do mundo real. São justamente os objectos que caracterizam a programação
orientada a objectos. Os objectos têm seus devidos atributos e métodos que o manipulam.
Figura 6: Exemplo de Objecto

Fonte: Autor

2.5.1.3. Polimorfismo

RICARTE (2001), conceitua polimorfismo como o princípio pelo qual as classes que derivam de
uma mesma superclasse invocam métodos que têm a mesma assinatura, mas que podem ter
comportamentos diferentes, especializados para cada classe derivada, usando para tanto uma
referência a um objecto do tipo da superclasse.

2.5.1.4. Herança
20

Segundo RICARTE (2001), herança é um mecanismo que permite que as classes herdam o estado
e o comportamento de suas superclasses. Com a herança, classes filhas (subclasses) podem herdar
características da classe pai (superclasse), como por exemplo, atributos e métodos. Podendo
assim a subclasse, especificar ou estender a superclasse.

A figura 7 apresenta um exemplo de herança e polimorfismo. Foram criadas três classes de tipos
diferentes de funcionários (subclasses), todas são derivadas de outra classe (superclasse). As
classes Programador, Analista e Desenvolvedor herdam os atributos e métodos (mesma
assinatura) da classe Funcionário, as acções dos métodos são diferentes para cada uma das classes.

Figura 7: Exemplo de Herança e Polimorfismo

Fonte: Autor

2.5.1.5. A Linguagem Java

Segundo BALAGURUSAMY (2010), java é uma linguagem de programação desenvolvida em


1991 por um grupo secreto da Sun Microsystems, denominado originalmente por ‘The Green
Project’, que significa ‘O Projecto Verde’.

Ainda segundo o autor a cima citado, esta linguagem de programação, foi concebida para o
desenvolvimento de software e tem uma portabilidade entre as plataformas, através da máquina
virtual ou JAVA VIRTUAL MACHINE (JVM). Além disso, segundo SOMERA (2006), ela é
orientada a objectos, o que possibilita a reutilização de códigos desenvolvidos em outros
projectos e trabalha com a troca de mensagens entre os objectos.
21

2.6. A Linguagem UML

Segundo UML (2011), a UML é uma linguagem gráfica para modelar, visualizar, especificar,
construir e documentar os artefactos de sistemas orientados a objectos.
Segundo SILVA (2007), a UML possui treze modelos gráficos que estão divididos em duas
categorias, os diagramas de aplicações estáticas que representam a estrutura e os diagramas de
comportamentos, no entanto dentro desta última categoria, existe uma subcategoria que compõe
os diagramas de interacção.
A categoria de diagramas de Estrutura segundo SILVA (2007), inclui diagrama de classe,
diagrama de objecto, diagrama de componentes, diagrama de estrutura composta, diagrama de
pacote e diagrama de utilização.
Enfatiza ainda SILVA (2007) que os diagramas de comportamento são constituídos por diagrama
de caso de uso, diagrama de estados e diagrama de actividades, em sua subcategoria estão
inclusos os diagramas de sequência, comunicação, visão geral de interacção e por ultimo, porém
não menos importante o diagrama de temporização.

2.6.1. Principais Diagramas UML

Os diagramas UML abordados neste projecto são os de: Caso de Uso, Sequência, Actividade,
Classe, Estado e Componente.

2.6.1.1. Diagrama de Caso de Uso

O diagrama de caso de uso tem como objectivo descrever as acções do sistema do ponto de vista
do usuário. Representa as formas que um usuário tem de utilizar o sistema, e pode se utilizar
como um “contrato” entre o cliente e o desenvolvedor do software para determinar as
funcionalidades do sistema (requisitos do sistema).
22

Figura 8: Exemplo de Diagrama de Caso de Uso

Fonte: Autor

2.6.1.2. Diagrama de Sequência

O diagrama de sequência tem como objectivo descrever como distintos objectos colaboram entre
si para alcançar um objectivo ao longo do tempo.
Figura 9: Exemplo de Diagrama de sequência

Fonte: Adaptada de Silva (2007)

2.6.1.3. Diagrama de Classes


23

Os diagramas de classes tem como objectivo descreverem as classes de domínio e as suas


relações. Permite modelar a estrutura do sistema desde um ponto de vista estático, modelando as
classes desde distintos enfoques de acordo com as etapas do projecto.
Figura 10: Exemplo de Diagrama de Classe

Fonte: Adaptada de Silva (2007)

2.6.1.4. Diagrama de Estado

O diagrama de estados tem com objectivo descrever os estados pelos quais um objecto pode
passar durante o seu ciclo de vida.
Figura 11: Exemplo de Diagrama de Estado

Fonte: Adaptada de Silva (2007).


24

2.6.1.5. Diagrama de Actividade

O diagrama de actividades tem como objectivo descrever as acções que ocorrem dentro de um
processo. É utilizado principalmente para modelar o fluxo de trabalho ou workflows com o qual
se visualiza as acções de maneira ordenada.
Figura 12: Exemplo de Diagrama de Actividade

Fonte: Adaptada de Silva (2007)

2.6.1.6. Diagrama de Componente

O diagrama de componentes tem como objectivo descrever as relações existentes entre os


distintos componentes do sistema. Está directamente relacionado com o desenho do sistema,
permitindo modelar as relações e interfaces que existem entre os componentes. Está orientado à
implementação do sistema.
25

Figura 13: Exemplo de Diagrama de Componente

Fonte: Adaptada de Silva (2007).

2.7. Padrões de Projectos

Segundo METSKER (2004), um padrão é uma maneira de fazer algo, ou de buscar um objectivo.
A ideia se aplica a desenvolver um software e qualquer outro ofício.
Um padrão pode ser aplicado em diversas áreas para resolver os mais variados problemas que
podemos encontrar em nossos ofícios.
Apesar de existirem diversos padrões de projecto, padrões têm sido descritos em diferentes
formatos.

2.7.1. Padrão MVC

O padrão MVC (Model View Controller) é um padrão de arquitectura de software que separa a
informação (e as suas regras de negócio) da interface com a qual o usuário interage.
Segundo GONÇALVES (2007), o MVC é um paradigma de desenvolvimento e design que tenta
separar uma aplicação em três partes distintas.
As três partes distintas referidas pelo autor acima citado são:
26

a) Model (Modelo): Representa os dados da organização e as regras de negócios que


governam o acesso e actualizações de dados.
b) View (Visão): É a camada de apresentação com o usuário, é a interface que proporcionará
a entrada de dados e a visualização das respostas geradas.
c) Controller (Controlador): Define o comportamento da aplicação, o controlador é quem
interpreta as solicitações (cliques, selecções de menus) feitas por usuários. Com bases
nestes requerimentos, o controlador comunica-se com o model (modelo) que selecciona a
view (visão) e actualiza-a para o usuário, ou seja, o controlador controla e mapeia as
acções.

2.8. Processo Unificado da Rational - RUP

Processo Unificado da Rational ou Rational Unified Process (RUP) é uma metodologia de


análise e desenvolvimento de software criada pela Rational Software Corporation. Esta
metodologia fornece técnicas de desenvolvimento de software de modo a aumentar a sua
produtividade.

KRUCHTEN (2003), Conceitua o RUP como um processo de engenharia de software que


fornece uma abordagem disciplinada para assumir tarefas e responsabilidades dentro de uma
organização de desenvolvimento, cujo objectivo é assegurar a produção de software de alta
qualidade dentro de prazos e orçamentos previsíveis.

O RUP baseia-se no paradigma de Orientação à Objectos e projectado e documentado utilizando


a notação Unified Modeling Language (UML) para a ilustração dos processos.

2.8.1. Características do RUP

O RUP suporta diversas boas práticas do desenvolvimento de software das quais destacam-se as
seguintes:

 Guiado por casos de uso – processo de desenvolvimento segue um fluxo, em que os casos
de utilização são especificados, desenhados, implementados, e no fim são a fonte a partir
dos quais os testes são definidos e realizados;
 Baseado na arquitectura do sistema - permite implementar os casos de uso requeridos;
27

 É uma metodologia interactiva e incremental - projecto facilmente gerido e executado se


for dividido em várias partes ou miniprojectos, em que cada mini projecto é uma iteração
que resulta num incremento, que deverá ser devidamente planeado, controlado e
executado.

2.8.2. Conceitos gerais

Uma metodologia define as quatros (4) palavras-chaves: quem faz o quê, quando e como, o
RUP também especifica essas palavras:
a) Interveniente (Quem)
Que na arquitectura RUP se designa por worker (quem) conceito que define o comportamento e
as responsabilidades de um ou mais indivíduos.
Exemplo: Analista de sistemas, programador, etc.
b) Actividade (Como)
Unidade de trabalho que um interveniente pode ser chamado a realizar. A sua granularidade varia
de algumas horas até vários dias e é a unidade de planeamento mais elementar, se bem que, do
ponto de vista de acções a executar, podem ser ainda divididas em passos mais elementares.
c) Artefacto (o Quê)
Qualquer informação que é produzida, alterada ou utilizada por um ou mais intervenientes
durante uma actividade. Como exemplo de artefactos temos os modelos, documentos, planos,
código fonte e executáveis. Cada artefacto pode ser elaborado com apoio de ferramentas distintas.
d) Tarefa (Quando)
Na tecnologia RUP é designada por workflow, é uma sequência de actividades que produz um
resultado observável.

2.8.3. Arquitectura do RUP

O RUP apresenta duas dimensões, a dinâmica e a estática como mostra a figura a seguir:

 Dimensão Dinâmica – reflecte a evolução temporal de um projecto, expressa em ciclos,


fases, iterações e objectivos a atingir.
28

 Dimensão Estática – reflecte quais tarefas (workflows) e actividades realizadas, os


outputs produzidos (artefactos) e os intervenientes.
Figura 14: Dimensões do RUP

Fonte: Adaptada de Kruchten (2004)

2.8.3.1. Dimensão Dinâmica: Fases

Segundo SILVA e VIDEIRA (2011), se considera dimensão dinâmica do RUP, como uma
sequência de fases, cada qual com varias iterações.
KRUCHTEN (2003), afirma que a arquitectura do RUP apresenta quatro fases no aspecto
dinâmico, que são elas: concepção, elaboração, construção e transição, como apresenta a figura
15. Essas fases podem conter varias iterações.
Figura 15: As quatro fases do RUP

Fonte: Adaptada de Kruchten (2003)


29

2.8.3.1.1. Concepção

É a fase da criação do escopo do projecto; nela é realizada a avaliação de riscos, uma estimativa
de recursos necessários e o cronograma de marcos temporais mais importantes. Todos os atores
envolvidos na iteração do sistema também são identificados nesta fase. Nesta fase são
desenvolvidos, também, os seguintes artefactos:

 Caso de negócio inicial;


 Formulação do documento de visão geral dos requisitos do sistema;
 Relatório inicial da avaliação de riscos;
 Estimativa de recursos;
 Cronograma inicial e;
 Protótipos iniciais.

2.8.3.1.2. Elaboração

É a especificação e eliminação dos pontos de maior risco. Nesta fase são também desenvolvidos
os seguintes requerimentos:
 Modelo de casos de uso;
 Análise e projecto do sistema;
 Relatórios de riscos;
 Plano de Gerenciamento;
 Alocação da equipe;
 Planejamento das fases, mostrando suas iterações e conteúdos;
 Realiza-se a análise do domínio do problema e projecta uma arquitectura para o sistema.

2.8.3.1.3. Construção

É o início do desenvolvimento do sistema, ao final de cada ciclo pode surgir uma versão
utilizável do processo. Nesta fase são também desenvolvidos os seguintes requerimentos:

 Sistema de software funcionando e documentação associada pronta para ser liberada aos
usuários;
 Casos de testes baseados em cenários, e resultados de testes;
30

2.8.3.1.4. Transição

Consiste na implantação do software e transferência para o usuário do sistema (KRUCHTEN,


2003).

2.8.3.2. Dimensão Estática: Workflows

Segundo SILVA e VIDEIRA (2011), a dimensão estática possui quatro conceitos chaves, esses
quatro conceitos definem quem faz o que, como e quando?

 Workers (trabalhadores) – quem;


 Actividades – como;
 Artefactos – o que; e,
 Fluxos de trabalho (workflows) – quando.
O RUP possui também algumas disciplinas, que são:

2.8.3.2.1. Modelagem de Negocio

A modelagem de negócio descreve como desenvolver uma visão da nova organização, definindo
processos, papéis e responsabilidades de cada um dos envolvidos através de casos de uso em um
modelo de objecto de negócio. Visa o entendimento da estrutura dinâmica da organização; o
entendimento de problemas e; a identificação das melhorias.

2.8.3.2.2. Requisitos

A disciplina de Requisitos procura trabalhar de forma a identificar as principais necessidades dos


clientes para que possam ser bem compreendidas por todos, negociadas, aceitadas e gerenciadas
durante o desenvolvimento do sistema, visando reduzir os riscos para o desenvolvimento do
sistema através de método e processos para identificação e documentação de requisitos do
sistema.

2.8.3.2.3. Análise e Desenho

Esta disciplina visa transformar os requisitos em projecto; construir uma arquitectura para o
sistema e; adaptar o projecto ao ambiente.
31

2.8.3.2.4. Implementação

Visa estruturar o código, bem como implementar classes e objectos; testar e integrar unidades.

2.8.3.2.5. Testes

Nesta disciplina é testado o sistema para identificação de erros, estes erros são identificados e
documentados; é possível validar o sistema de acordo com o que foi especificado e validar se o
sistema foi desenvolvido de acordo com o projectado

2.8.3.2.6. Implantação

Esta disciplina visa a certificação d a entrega do sistema ao usuário final.

2.8.4. As Melhores práticas do RUP

2.8.4.1. Metodologia conduzida por casos de utilização

Tal como noutras metodologias que recorrem a UML, no RUP a inovação reside no facto dos
casos de utilização, para além de especificarem os requisitos do sistema, conduzirem também o
seu próprio desenho, implementação e teste, ou seja, todo o processo de desenvolvimento. Dito
de outra forma, significa que o processo de desenvolvimento segue um fluxo, em que os casos de
utilização são especificados, desenhados, implementados, e no fim são a fonte a partir da qual os
testes são definidos e realizados.

2.8.4.2. Metodologia centrada numa arquitectura

A função da arquitectura de software é reflectir decisões sobre a organização do sistema de


software, nomeadamente:

 Os elementos estruturais (e suas interfaces) que compõem o sistema.


 O seu comportamento especificado através de colaborações entre eles.
 A composição dos elementos estruturais e de comportamento em subsistemas
progressivamente maiores.
 O estilo arquitectural, que guia esta organização, os elementos e suas interfaces, as suas
colaborações e a sua composição.
32

A arquitectura de software decide ainda sobre restrições e compromissos relativos a diferentes


aspectos do sistema, tais como: utilização, funcionalidades, desempenha, tolerância a alterações,
reutilização, compreensão, economia e estética.

2.8.4.3. Metodologia iterativa e incremental

A justificação para esta proposta é o facto de um projecto ser mais facilmente gerido e executado
se for dividido em várias partes ou mini projectos, em que cada mini projecto é uma iteração que
resulta num incremento, que deverá ser devidamente planeado, controlado e executado (através
de análise, desenho, implementação e testes).

2.8.4.4. Metodologia que controla as mudanças

Diante de um ambiente tão complexo e dinâmico que é o processo de desenvolvimento de sof


tware, é impossível não haver mudanças no projecto, por isso que a metodologia do RUP se
preocupa em gerir cada mudança no projecto, a fim de evitar atrasos no cronograma, aumento de
custo, diminuição da qualidade, ocorrência de um risco não planejado, desmotivação por parte da
equipe do projecto, entre outros.

2.8.4.5. Metodologia que verifica a qualidade

Segundo KRUCHTEN (2004), durante o processo de desenvolvimento de software, a


preocupação sobre a qualidade é focaliza duas áreas: qualidade de produto e qualidade de
processo.

 A qualidade do produto principal que é concebido (software ou sistema) e todos os outros


elementos que ele abrange por exemplo componentes, subsistemas, arquitecturas e mais.
 A qualidade do processo que é o grau pelo qual um processo é aceitável (inclusive
medidas e critérios de qualidade), nível de implementação e adesão ao produto.
Efectuar a verificação sistemática da qualidade, não deve ser feita apenas por um ou grupo de
intervenientes, mas sim por toda organização sem que necessariamente no final do
desenvolvimento.
33

2.8.4.6. Metodologia que modela visualmente

Um modelo é uma simplificação da realidade que nos ajuda a dominar um sistema complexo que
não pode ser compreendido em sua totalidade. Consistirá em modelar o software através de
diagramas gráficos, mais facilmente compreensíveis e menos sujeitos a interpretações subjectivas.
Modelar visualmente o software quer dizer, criar um mecanismo de desenho gráfico para que
haja um entendimento entre os utilizadores e a equipe do projecto, de forma que ambos tenham a
mesma visão de como o software será criado e quais serão os requisitos que o mesmo irá conter
para atender as expectativas destes últimos.

2.8.5. Vantagens e Desvantagens do RUP

A metodologia RUP como outras metodologias de desenvolvimento de software possui vantagens


e desvantagens relacionadas com certos aspectos no processo de desenvolvimento de sistemas.

2.8.5.1. Vantagens

 Processo robusto e bem definido com a geração de artefactos importantes;


 Os maiores riscos são atacados primeiro, diminuindo as chances de fracasso do projecto;
 Processo robusto e bem definido;
 Artefactos importantes;
 Ataca os maiores riscos;
 Inconsistências entre requisitos, projecto e implementação podem ser detectados
rapidamente;
 Evidências concretas do andamento do projecto podem ser oferecidas durante todo o ciclo
de vida.

2.8.5.2. Desvantagens

 Exige experiência da equipe;


 Muito complexo em pequenos projectos;
 Requer conhecimento da equipe;
 Podem ocorrer divergências entre a documentação e o software;
34

 Aumento de gastos devido à implementação da versão a cada incremento;


 Pode gerar uma grande mudança em partes já desenvolvidas para realizar algum novo
requisito incremental.
35

CAPÍTULO III: ANÁLISE E DISCUSSÃO DOS RESULTADOS

3.1. Descrição do Local de Estudo

A PALE CONSTRUÇÕES LDA é uma empresa Moçambicana, com capitais inteiramente


moçambicanos, registado oficialmente como empresa de Construção Civil e Obras Públicas,
dprodução e comercialização de materiais de construção, sedeada em Djonasse, a empresa possui
uma loja denominada JHFCONSTRUFACIL LDA, situada na Av. Romão Fernandes Farinha-
741, na baixa da Cidade de Maputo. Esta loja, é inteiramente responsável pela comercialização de
todo tipo de materiais de construção.
A loja possui as seguintes áreas:

 Contabilidade (área responsável pelo Processamento de pagamentos e cobranças);


 Armazém (ondem é armazenado todo o material disponível na loja);
 Balcão (responsável pelo atendimento ao cliente);

3.2. Análise do Sistema Actual de Gestão de Estoque e suas Limitações

Estoque é tudo aquilo que precisa ser armazenado ou estocado em determinados locais de uma
organização, pois assim complementa a rotatividade da organização, tornando-a rápida e eficaz.
No entanto, a gestão de estoques é o procedimento adoptado para registar, fiscalizar e gerir a
entrada e saída de mercadorias e produtos seja numa indústria ou no comércio. A gestão de
estoque deve ser utilizado tanto para matéria-prima, mercadorias produzidas e/ou mercadorias
vendidas.
O actual processo de gestão de estoque na PALE CONSTRUCOES – JFH CONSTRUFACIL
LDA consiste no seguinte:

 Quando um cliente chega ao balcão com uma lista de materiais por si pretendidos, o
vendedor verifica a existência desse material. Caso exista, o vendedor faz a cotação do
material com auxílio de um caderno que contém a lista de todo o material e o seu
respectivo preço, os cálculos são feitos mediante calculadora e em seguida é apresentado
ao cliente o valor total do material requisitado. Caso o cliente esteja de acordo com os
preços, efectua o pagamento e o vendedor dirige-se aos repositórios de cada material e
sobrai os itens constantes na cotação e entrega-os ao cliente junto com o recibo
36

comprovativo da compra, actualizando posteriormente o ficheiro em Excel onde é


registado o material. Para cada material, há um ficheiro em Excel para o seu registo.
(vide anexo 1, figura 2 e figura 3).
 Quando um certo material atinge a quantidade mínima recomentada, o vendedor marca
esse material para abastecimento e em seguida informa ao gerente da loja. Este por sua
vez faz a requisição desse material a um fornecedor de sua preferência. Quando entra um
material na loja (material resultante de uma requisição), é guardado no seu respectivo
repositório e em seguida actualiza-se os ficheiros Excel (quantidade e preço de compra).
Como principais limitações do actual sistema de gestão destacam-se:
 Falta de segurança da informação;
 Consumo de quantidade de tempo;
 Acesso reduzido a informação referente ao estoque;
 Dificuldade de organização de dados (cadastro de clientes, fornecedores, produtos, etc);

3.3. Concepção e Implementação do Sistema de Gestão de Estoque

O sistema a ser concebido tem como objectivo principal a dinamização do processo de gestão de
estoque na PALE CONSTRUCOES-JHF CONSTRUFACIL LDA, visto que a gestão de estoque
está relacionada ao tratamento e armazenamento de informação. O sistema vai permitir o controlo
da situação real do estoque.
Para o processo de desenvolvimento do sistema, utilizou-se a metodologia RUP de forma
customizada. O RUP é descrito no capítulo 2 deste trabalho. Esta metodologia enfatiza quatro (4)
fases:

 Fase Concepção
Nesta fase realizou-se o levantamento de requisitos de negócio e o diagrama de caso de uso
preliminar do sistema. (Vide anexo III)

 Fase Elaboração
Nesta fase foram realizados os diagramas de classe, de sequência, de actividade, de estado e de
componente. (Vide anexo IV)

 Fase Construção
37

Nesta fase fez-se o desenvolvimento físico do sistema: a codificação e documentação. A figura


abaixo mostra a interface principal do sistema com todas a componentes.
Figura 16: Tela Principal

Fonte: Autor

 Fase – Transição - RUP


Nesta fase efectuar-se-á a disponibilização do software para o utilizador. Para que tal aconteça, é
necessário garantir a conformidade do sistema produzido relativamente aos requisitos
inicialmente definidos, que o conjunto de funcionalidades identificadas tenha sido desenvolvido e
que o seu todo constitui um sistema funcional.
Os artefactos produzidos nesta fase são:
 Manual de utilizador
É nesta fase de transição que deve ser disponibilizado o manual de utilizador. O manual do
utilizador contém toda descrição do funcionamento do sistema, os requisitos de hardware, a
instalação e principalmente procura responder à questão “como usar o software?”.
 Instalação do sistema em ambiente de produção
38

Finalmente o sistema poderá ser instalado em ambiente de produção depois da aprovação da


proposta de implementação posteriormente feita a instituição, nomeadamente o Hotel 2010 Lda.
em Maputo.
 Formação e testes do sistema
Os utilizadores do SIGE terão uma pequena formação local para que possam usar o sistema na
fase de testes em ambiente de produção. Algumas falhas detectadas durante a fase de teste
servirão para o aperfeiçoamento do sistema, na sua segunda versão.

3.4. Eficiência do Sistema de Informação de Gestão de Estoque.

Segundo STONER (1999), eficiência significa executar uma tarefa da melhor forma possível,
evitando desperdícios e maximizando a produtividade, isto é, fazer bem e correctamente,
empregar do melhor modo os recursos disponíveis.
Um SI é eficiente quando responde de forma objectiva e clara as necessidades de uma
organização.
O SIGE na JHF CONSTRUFACIL LDA é eficiente e destacam os seguintes pontos de eficiência:
 O sistema verifica e notifica em forma de cores assim que um certo material estiver em
estoque zerado ou atingir o ponto mínimo (estoque mínimo). O procedimento também se
aplica quando um material estiver em estoque baixo e alto. (Vide fig. 17)
39

Figura 17: Formulário de Cadastro de materiais

Fonte: Autor

A figura acima mostra um alerta em forma de cores assim que um material estiver em estoque
zerado (cor vermelho), estoque baixo (cor amarelo) e em estoque alto (cor verde).

 O sistema verifica e notifica em forma de alertas sempre que houver uma tentativa de
cadastro repetitivo de alguma informação (cliente, unidade, categoria, fornecedor, itens da
venda e materiais). (Vide fig. 18)
40

Figura 18: Restrição no cadastro de vendas

Fonte: Autor

A figura acima mostra uma restrição no cadastro de uma venda. Quando o vendedor adiciona um
item à venda, o sistema verifica se o item já foi adicionado ou não, caso tenha sido adio nado, ele
emite um alerta avisando a existência do item na lista.

 O sistema gerara automaticamente o recibo e em PDF assim que uma venda efectuada, o
vendedor não precisa o caderno de recibos como se fazia manualmente. (Vide fig. 19)
41

Figura 19: Recibo de venda

Fonte: Autor

A figura acima ilustra a geração automática de uma venda. Assim que uma venda é finalizada, o
sistema gera um recibo para aquela venda.

 O sistema permite que os relatórios sejam gerados ao todo por código. No caso da venda,
o relatório pode também ser gerado por vendedor e intervalo de datas em que a venda foi
efectuada. (Vide fig. 20)
42

Figura 20: Relatório de todas vendas efectuadas

Fonte: Autor
A figura acima ilustra o relatório de todas as vendas efectuadas.

 O sistema permite verificar e actualizar qualquer informação relativa ao estoque. O


gerente assim como o vender não precisam fazer uma vasculha em cadernos ou arquivos
físicos como se fazia manualmente.

3.5. Proposta de um sistema de gestão de base de dados e medidas de segurança e


integridade da informação para processo de gerenciamento de estoque.
3.5.1. Proposta da Base de Dados

O banco de dados proposto para o sistema de informação de gestão de estoque foi o MySQL pois
segundo MYSQL (2010), tem um excelente desempenho, confiabilidade, facilidade de uso e é
multiplataforma.

O outro motivo por trás da proposta do MySQL como sistema gerenciador de banco de dados, foi
o facto de a PALE CONSTRUÇÕES LDA já possuir este SGBD em uso no servidor onde se
encontra hospedado o site da organização.
43

Assim sendo, a informação geral do sistema é armazenada numa base de dados cujo nome é “jhf”
(Vide fig.21) e periodicamente deverão ser feitos backups (cópias de seguranças) que geralmente
serão gravados em mídias como DVDs ou servidores de backups os quais por precaução deverão
estar situados ou guardados num local diferente da base dados principal para evitar que algum
problema como incêndio ou algo do género faça com que o banco principal e as cópias se percam.

Figura 21: Banco de dados do SIGE

Fonte: Autor

3.5.2. Medidas de Segurança e Integridade da Informação

Com a globalização torna-se impossível uma empresa funcionar sem a ajuda de um sistema
informação. Deste modo, torna-se importante que as empresas tenham suas informações bem
protegidas, pois caso contrário as mesmas podem ver suas políticas, produtos e informações
vandalizadas e comprometendo a integridade dos usuários. Neste contexto é imprescindível que
haja segurança nos sistemas.

Assim sendo, se propôs as seguintes medidas de segurança:

3.5.2.1. Confidencialidade

O acesso ao sistema é restrito a utilizadores autorizados. O sistema está dividido em dois níveis
de privilégios:
 Utilizador vendedor - tem privilégios básicos, ou seja, o acesso a informação e
manipulação da mesma é limitado.
44

 Administrador: tem acesso total a informação e o privilégio de gerir


completamente o sistema.
A figura abaixo mostra a tela de login onde serão inseridos os dados de acesso para posterior
confirmação, pois só são aceites indivíduos registados e com as respectivas credenciais.
Figura 22: Tela de Login

Fonte: Autor

3.5.2.2. Integridade

A informação não deve possuir alterações não autorizadas e que não foram aprovadas e nem
estão sob controlo do proprietário da mesma. A informação do sistema de Informação de gestão
de Estoque encontra-se armazenada no SGBD MySQL e que somente o administrador tem acesso
para execução das operações de inserção de informação, modificação, actualização e remoção das
tabelas contidas na base de dados. (Vide anexo 6).

3.5.2.3. Disponibilidade

Garantir que a informação seja acessível em qualquer instante quando necessitada. O sistema está
instalado nos computadores da JHF CONSTRUFACIL LDA (balcão e contabilidade). A
disponibilidade do mesmo seguirá as normas de segurança da organização. Assim sendo, os
45

utilizadores registados podem aceder ao sistema nos computadores onde o mesmo foi instalado.
Depois de acessar o sistema, abrir-se-á a tela de login desseguida o utilizador insere os dados
correctamente e passa para a tela principal, como mostra a figura abaixo.
46

CAPÍTULO IV: CONCLUSÃO, LIMITAÇÕES E RECOMENDAÇÕES


4.1. Conclusão

Antes, sem um sistema automatizado para o armazenamento de dados referentes à gestão de


estoque, a única solução encontrada pela gerência da PALE CONSTRUCAOES - JHF
CONSTRUFACIL LDA era recorrer a planilhas do Microsoft Office Excel e a arquivos físicos
para armazenar informação, o que não garantia segurança pela facilidade de perda de dados,
agora, com um sistema personalizado, é possível uma gestão mais segura e confiável à loja.
O Sistema de informação de gestão de estoque oferece significativos ganhos uma vez que fornece
uma ferramenta eficaz de controlo e acesso à segurança de informação sanando problemas de
falta de segurança de informação, a falta de sistema de contingência, dificuldades na organização
de dados entre outros problemas citados no primeiro capítulo deste trabalho. O uso de um SGBD,
neste caso o MySQL, resolve o problema de falta de mecanismos de armazenamento de
informação possibilitando uma rapidez e eficiência no processo de gestão de estoque.
A metodologia utilizada na efectivação deste projecto, a metodologia RUP, permitiu uma melhor
gestão no desenvolvimento do sistema, visto que as técnicas e ferramentas aceleram o processo
de análise, desenvolvimento e implementação do sistema.
47

4.2. Limitações

Levando em conta o tipo de aplicação desenvolvida, sendo uma aplicação Desktop, possui as
seguintes limitações:
 A aplicação é acessada somente em modo desktop, isto é, acessada no computador em
que foi instalada;
 No caso de uma falha no servidor ou de corrente não há como os utilizadores terem
acesso a informação.
 O facto de a aplicação ser executada em modo desktop, torna a manutenção trabalhosa
uma vez que em caso de falha ou bugs no sistema, a manutenção deverá ser feita em todos
computadores onde a aplicação foi instalada;

4.3. Recomendações

Depois da abordagem profunda das funcionalidades e características da aplicação, para o óptimo


desempenho da mesma são sugeridas as seguintes recomendações:
 Comprar um computador com capacidades no mínimo de 1GB de memória RAM, 100GB
de disco Rígido com a finalidade de ser utilizado para instalação do sistema;
 Instalação de Java Development Kit (JDK ) ou Java Runtime enviroment (JRE) versões
recentes;
 De modo a garantir confidencialidade do sistema, é necessário que o administrador
atribua senhas de segurança aos utilizadores do sistema para garantir que ele seja somente
acessado por indivíduos autorizados.
48

BIBLIOGRAFIA

AMARO, Marisa. Sua Organização está preparada para uma Contingência? Disponível em:
Acesso em 17 Maio. 2012.

BRANCO, Renata. Justin in Time Disponível em: Acesso em 24 Maio. 2012.

BLOOM, Benjamin S. Taxonomia de losobjetivos de laeducación: la clasificaci6nde


lasmetaseducacionales. Buenos Aires: EI Ateneo, 1971. Parte II.

CARNEIRO, A. (2002). Introdução à Segurança dos Sistemas de Informação


Lisboa/Porto/Coimbra: FCA – Editora de Informática, Lda.

DATE, C. J. Introdução a Sistemas de Bancos de Dados. Rio de Janeiro: Elsevier: 2003.

DAMAS, L. SQL Structured Query Language. Rio de Janeiro: LCT, 2005.

GAMMA, E. H., R. J., R. Padrões de Projeto. Porto Alegre: Bookman, 2000.

MYSQL, 2010. Site Oficial MySQL. Disponível em <http://www.mysql.com/why-


mysql/ >Acessado em 10/04/2016.

GIL, A.C. Como elaborar um projecto de pesquisa. 5 Ed. São Paulo: Atlas 2008

GIL, A. C. Métodos e técnicas de pesquisa social. 4.ed. São Paulo: Atlas, 1999.

HEUSER, C. A. Projecto de Banco de Dados. Porto Alegre: Sagra, 2000.


49

KRUCHTEN, Philippe. Introdução ao RUP – Rational Unified Process. Editora Ciência


Moderna Ltda, 2ª Ediçao, Rio de Janeiro, 2004.
KIELGAST, Soeren, HUBBARD, Bruce A. Valor agregado à informação - da teoria à prática.
Ciência da Informação on Line, Brasília, v. 26, n. 3, 1997.

MARIANI, A. C. O Mundo dos Atores: uma perspectiva de introdução à programação


orientada a objectos. Disponível em <http://www.inf.ufsc.br/poo/atores/sbie98/sbie98-
atores.html> Acessado em 01/04/2016.

MARCONI, Marina de Andrade. LAKATOS, Eva Maria. Fundamentos de metodologia


científica1 -5. Ed. -São Paulo: Atlas 2003

MAMEDE, H. (2006). Segurança Informática nas Organizações. Lisboa/Porto/Coimbra: FCA


– Editora de Informática, Lda.

MONTEIRO, Edmundo H. S., Controlo da Congestão em Sistemas Intermediários da camada


de Rede, Tese de Doutoramento. Universidade de Coimbra. Coimbra. 1995.

OMG, 1997 - 2011. Site Oficial OMG. Disponível em < http://www.omg.org/spec/ > Acessado
em 10/04/2016.

PARAISO, C.M. Desenvolvimento de um sistema de gestão académico – tese de licenciatura.


São José dos Campos, 2011.

RAMOS, S. A. Proposta de Implantação de Um Sistema de Controlo de Estoque, Tese de


Licenciatura. Universidade do Vale do Itajaí, Brasil. 2006.

REZENDE, D. A. Engenharia de software e sistemas de informação. Rio de Janeiro: Brasport,


2005.
50

ROSINI, Alessandro Marco; PALMISANO, Ângelo. Administração de Sistemas de Informação


e a Gestão do Conhecimento. São Paulo: CengageLearning, 2008.

SILVA, A. M. R. e VIDEIRA C. A. E.. UML Metodologias e ferramentas CASE. 1 ª ed. Centro


atlântico, Lisboa, 2001.

SILVA, Edna Lúcia da, MENEZES, Estera Muszkat. Metodologia de Pesquisa e Elaboração de
Dissertação.3. ed. Florianópolis, 2001

SILVA, R. P. Uml2 Em Modelagem Orientada a Objectos. Florianópolis: Visual Books, 2007.

STOLF, G. A. Sistema Web Gerenciador de Clínica Médica: CARDIOMED. Tese de


Bacharelato. Universidade Regional de Blumenau, Brasil, 2007;

TIVIR, C. R. J. Concepção e Implementação de Um Sistema de Gestão de Horário, Tese de


Licenciatura. Universidade Pedagógica, Maputo. 2014.

UNIVERSIDADE PEDAGÓGICA. Regulamento académico para os cursos de graduação e de


pós- graduação. Universidade Pedagógica, Maputo, 2012.

UML, 2011. Site Oficial UML. Disponível em <http://www.uml.org/#UML2.0 > Acessado em


01/04/2016.

VEIGA, R. D. e ZAMBALDE, A. L., Informatização das MPEs - Curso de Pós-Graduação


“Lato-Sensu” (Especialização) a Distância: Gerenciamento de Micro e Pequenas Empresas. 172
p. Lavras – UFLA/FAEPE, 2000
51

VERGARA, Sylvia Constant. Projetos e relatórios de pesquisa em administração. São Paulo:


Atlas, 1997.
52

ANEXOS
53

ANEXO I – Informações da Gestão de estoque na JHFCONSTRUFACIL LDA


Este anexo mostra dois (2) documentos que foram usados como ferramentas de recolha de dados.
O primeiro (figura-18) mostra como é feito o pedido de cotação de materiais e o último (figura-
19) é um questionário de entrevista realizada de modo a colher informação necessária para o
desenvolvimento do sistema
Figura 23: Ficha de pedido de cotação de material
54

Figura 24: Ficheiro Excel de Registo de Materiais


55

Figura 25: Ficheiro Excel de Registo de Materiais


56

Figura 26: Questionário dirigido à JHFCONSTRUFACIL LDA


57

ANEXO II – Funcionalidades básicas requeridas para o Sistema de gestão de estoque (SGE)


Este documento descreve as funcionalidades básicas ou requisitos funcionais básicos requeridos
para o sistema de gestão de estoque na JHFCONSTRUFACIL LDA

Figura 27: Funcionalidades básicas param o SIGE proposto


58
59

ANEXO III: Plano de Actividades do Sistema de Informação de Gestão de Estoque


(baseado na metodologia RUP)

A tabela a baixo ilustra o plano de actividades do sistema de informação de Gestao de Estoque


baseadas na metodologia RUP

Tabela 1: Plano de Actividades do Sistema de Informação de Gestão de Estoque (baseado na


metodologia RUP)

ORDEM ACTIVIDADES DURAÇÃO

Workflow de Requisitos

 Visão de negócios
1 20 Dias
 Necessidades dos utilizadores
 Glossário de termos
 Lista de riscos

Workflow de Ambiente

 Selecção e aquisição de ferramentas de modelação


2
Workflow de Análise e Desenho 30 Dias

 Definição da arquitectura do sistema


 Elaboração do modelo de desenho do sistema
60

Workflow de Ambiente

 Selecção e aquisição de ferramentas de modelação

Workflow de Implementação
3 40 Dias
 Definição da estrutura do sistema
 Implementação dos componentes do sistema
 Testes dos componentes
 Integração de componentes e criação do executável

Workflow de Testes
4 10 Dias
 Correcção de erros do sistema

Workflow de Instalação

5  Disponibilização do software ao utilizador final 40 Dias


 Produção do manual de utilizador
 Formação de utilizadores
61

ANEXO IV: Fase de Concepção – RUP


Os Requisitos de Negócio representam o porquê da informação, ou seja porquê a organização
necessita do projecto. Quais são as espectativas com relação ao produto ou serviço e são
registados na visão e escopo do projecto.
4.1. Definição do Problema
A tabela abaixo apresenta os Requisitos de Negocio do Sistema de Informação de Gestão de
Estoque para a PALE CONSTRUCOES - JHF CONSTRUFACIL LDA.
Tabela 2: Requisitos de Negocio

A PALE CONSTRUÇÕES LDA é uma empresa de Construção Civil e


Obras Públicas, produção e comercialização de materiais de construção, a
empresa possui uma loja denominada JHFCONSTRUFACIL LDA que é
inteiramente responsável pela comercialização de materiais de construção. A
Problema:
loja utiliza um mecanismo manual para gerir o fluxo de materiais, isto é, os
gestores precisam de vasculhar os arquivos físicos consumindo muito tempo
dificultando assim o processo de controlo na manutenção, ressuprimento e
saída de materiais.

Afectado: A gerência e os vendedores da Loja

Desenvolvimento de um sistema de Informação que permita a eficácia e


Solução:
rapidez no processo de gestão de estoque

Fonte: Autor
4.2. Requisitos do Sistema
Os requisitos de sistema estabelecem funções e restrições do sistema, assim sendo os requisitos
funcionais e não funcionais do sistema de informação de gestão de estoque, são mostrados nas
tabelas abaixo:
4.2.1. Requisitos Funcionais
A tabela abaixo apresenta os requisitos funcionais do Sistema de Informação de Gestão de
Estoque para a PALE CONSTRUCOES - JHF CONSTRUFACIL LDA.
62

Tabela 3: Requisitos Funcionais do Sistema

Código Requisito

RF01 Possuir dois tipos de Usuários: Administrador e Vendedor

RF02 Liberar o Sistema após autenticação do Usuário

Permitir as seguintes operações ao vendedor sobre o gerenciamento de Estoque:


 RF0301 – Cadastro de Clientes;
 RF0302 – Cadastro de Fornecedores;
 RF0303 – Cadastro de Materiais de Construção;
RF03
 RF0304 – Cadastro de Pedidos (Venda, Requisição de compra,
cotação);
 RF0305 – Cadastro de Categorias;
 RF0306 – Cadastro de Unidades;

Para o Usuário Administrador permitir o gerenciamento de:


RF04
 RF0401 - Vendedores;

RF05 Gerar relatórios a partir dos resultados da pesquisa;

Fonte: Autor
4.2.2. Requisitos Não Funcionais
A tabela apresenta os requisitos não funcionais do Sistema de Informação de Gestão de Estoque
para a PALE CONSTRUCOES - JHF CONSTRUFACIL LDA.

Tabela 4: Requisitos Não Funcionais do Sistema

Código Requisito

RNF01 Acessível apenas em modo Desktop

RNF02 Desenvolvido em JAVA

RNF03 Utilizado o Sistema gerenciador de banco de dados MySQL

RNF04 Compatível com os Sistemas Windows XP, Seven e Ten


63

RNF05 Hardware: Computador com as seguintes especificações:


 RNF0501 – Processador Dual Core;
 RNF0502 - 4GB de RAM;
 RNF0503 - 50 GB de espaço livre de HDD;
 RNF0504 - Impressora (Deskjet F1200 seriespcl) opcional

Fonte: Autor
4.3. Caso de Uso Preliminar
O caso de uso preliminar representa uma síntese de principais funcionalidades do sistema. O
diagrama da figura abaixo faz referência aos principais serviços do sistema assim como aos
papéis desempenhados pelos actores do sistema.
64

Figura 28: Diagrama de Caso de Uso Preliminar


65

ANEXO V: Fase de Elaboração - RUP


5.1. Caso de Uso
Um caso de uso descreve uma sequência de acções que representam um cenário principal e
cenários alternativos, com o objectivo de demonstrar o comportamento de um sistema ou parte
dele, através de interacções com elementos externos, chamados de actores.
Figura 29: Caso de Uso do Sistema de Informação de Gestão de Estoque
66

5.2. Diagrama de Actividade


Um diagrama de actividades modela o fluxo de controlo de uma operação, ou seja, mostra como
as actividades de um processo dependem umas das outras.
5.2.1. Diagrama de Actividade Autenticar
A figura 30 descreve as actividades realizadas pelo vendedor e o administrador ao autenticar-se
no sistema
Figura 30: Diagrama de Actividade Autenticar

5.2.2. Diagrama de Actividade Cadastrar Venda


A figura 31 descreve as actividades realizadas pelo vendedor ao efectuar o cadastro de uma venda.
67

Figura 31: Diagrama de Actividade Cadastrar Venda


68

5.3. Diagrama de Sequencia


O diagrama de sequência é um diagrama de interacção com ênfase na ordenação temporal das
mensagens trocadas entre os objectos, a figura abaixo é relativo ao caso de uso gerir salas.
5.3.1. Diagrama de Sequencia Autenticar
A figura 32 representa o diagrama de sequência autenticar feito pelo usuário do sistema.
Figura 32: Diagrama de Sequencia - Autenticação

5.3.2. Diagrama de Sequencia Cadastrar Venda


A figura 33 representa o diagrama de sequência de cadastro de vendas feito pelo usuário
vendedor.
69

Figura 33: Diagrama de Sequencia Cadastrar Venda

5.4. Diagramas de estado


A figura 34 representa o diagrama de estado do cadastro de venda. O cadastro será iniciado a
partir da informação dos dados da venda a ser cadastra, o objecto passará para o estado de
Processando Requisição e em seguida estes dados serão enviados ao banco de dados, se os dados
estiverem correctos, o objecto passa para o estado de Finalizado, caso contrário, ele passa para
estado de Não Cadastrado, assim ele pode voltar ao estado Enviado, enviando os dados
novamente, ou passar para o estado Cancelado.
70

Figura 34: Diagramas de estado

5.5. Diagrama de componente


A figura 35 representa o diagrama de componentes deste projecto. Este diagrama é composto
pelas três (3) partes do modelo MVC – Modelo, Visão e Controladores; e o DAO (Camada de
Acesso ao Banco de Dados)
71

Figura 35: Diagrama de componente

5.6. Diagrama de Classe


Diagrama de classe representa uma descrição formal da estrutura de objectos num sistema, onde
para cada objecto descreve a sua identidade, os seus objectos, os seus atributos e as suas
operações.
72

Figura 36: Diagrama de Classes


73

Anexo VI: Fase Construção - RUP


6.1. Projecto de Banco de dados
O DER representa o conjunto de relacionamentos existentes entre as entidades do domínio em estudo. As duas tabelas que se seguem
mostram como é que as entidades do sistema se relacionam.
Figura 37: Diagrama Entidade Relacionamento (DER)
74

6.2. Estrutura das Tabelas


Estrutura das tabelas do sistema e a respectiva descrição (nome das colunas, tipos de dados e as
relações com outras tabelas).
6.2.1. Tabela Categoria

6.2.2. Cliente

6.2.3. Tabela Contacto

6.2.4. Tabela Endereço


75

6.2.5. Tabela Fornecedor

6.2.6. Tabela Itens_Venda

6.2.7. Tabela Material

6.2.8. Tabela Unidade

6.2.9. Tabela Usuario


76

6.2.10. Tabela Venda


77

6.3.Protótipo de Telas
As figuras seguintes representam os protótipos de Telas do Sistema de Informação de Gestão de
Estoque.
6.3.1. Tela de Cadastro de Materiais
A figura 33 representa a tela de gerenciamento de materiais
Figura 38: Tela de Cadastro de Materiais

A tela é composta por vários campos que solicitam os dados do material a ser cadastrado no
sistema.
6.3.2. Tela de Cadastro de Vendas
A figura 34 representa a tela de gerenciamento de vendas
78

Figura 39: Tela de Cadastro de Vendas

A tela é composta por vários campos que solicitam os dados da venda a ser efectuada.
6.3.3. Tela de Cadastro de Clientes
A figura 35 representa a tela de gerenciamento de clientes
79

Figura 40: Tela de Cadastro de Clientes

A tela é composta por vários campos que solicitam os dados do cliente a ser cadastrado no
sistema.
6.3.4. Tela de Cadastro de fornecedores
A figura 36 representa a tela de gerenciamento de fornecedores
80

Figura 41: Tela de Cadastro de Fornecedores

A tela é composta por vários campos que solicitam os dados do fornecedor a ser cadastrado no
sistema.
6.3.5. Tela de Cadastro de Categorias
A figura 37 representa a tela de gerenciamento de categorias
81

Figura 42: Tela de Cadastro de Categorias

A tela é composta por vários campos que solicitam os dados da categoria a ser cadastrada no
sistema.
6.3.6. Tela de Cadastro de Unidades
A figura 38 representa a tela de gerenciamento de unidades
82

Figura 43: Tela de Cadastro de Unidades

A tela é composta por vários campos que solicitam os dados da unidade a ser cadastrada no
sistema.
6.3.7. Tela de Cadastro de Usuários
A figura 39 representa a tela de gerenciamento de usuários
83

Figura 44: Tela de Cadastro de Usuários

A tela é composta por vários campos que solicitam os dados do usuário a ser cadastrado no
sistema
6.3.8. Tela de Consulta de Vendas
A figura 40 representa a tela de consulta de vendas
84

Figura 45: Tela de Consulta de Vendas

Esta tela é composta por dois campos de texto que recebem as datas em que uma certal4eyyehb
venda foi efectuada e duas tabelas, sendo que a primeira para listar todos os cliente que
efectuaram o pedido e a segunda tabela para listar os itens relacionados com a venda.
85

5.4. Estrutura da Aplicação


A figura 41 mostra a estrutura geral do sistema de modo a facilitar o utilizador no manuseio do mesmo
Figura 46: Estrutura da Aplicação
86

Tabela 5: Descrição da estrutura da aplicação

Campo Descrição

1 Menu geral do sistema

2 Botões de Navegação entre telas

3 Botão logout / Sair

4 Foto de perfil do utilizador

5 Área de visualização das telas

6 Username do utilizador

7 Tipo de utilizador