DESENVOLVIMENTO DE UM SISTEMA PARA COLÔNIA DE PESCADORES Z 20 SindPesca 27 10 2013

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

DESENVOLVIMENTO DE UM SISTEMA PARA COLÔNIA DE PESCADORES Z-20 - SindPesca
 de fabiohenriquestm | trabalhosfeitos.com
 CENTRO UNIVERSITÁRIO LUTERANO DE SANTARÉM
CURSO DE SISTEMAS DE INFORMAÇÃO
FÁBIO HENRIQUE DA MOTA DA SILVA
DESENVOLVIMENTO DE UM SISTEMA PARA COLÔNIA DE PESCADORES Z-20 SindPesca
SANTARÉM
2013
FÁBIO HENRIQUE DA MOTA DA SILVA
DESENVOLVIMENTO DE UM SISTEMA PARA COLÔNIA DE PESCADORES Z-20 SindPesca
Trabalho
de
conclusão
de
Curso
apresentado para obtenção do Grau de
Bacharel em Sistemas de Informação pelo
Centro Universitário Luterano de Santarém.
Orientador: Prof. Carlos Alberto P. Araújo
SANTARÉM
2013
FÁBIO HENRIQUE DA MOTA DA SILVA
DESENVOLVIMENTO DE UM SISTEMA PARA COLÔNIA DE PESCADORES Z-20 SindPesca
Trabalho
de
conclusão
de
Curso
apresentado para obtenção do Grau de
Bacharel em Sistemas de Informação pelo
Centro Universitário Luterano de Santarém.
Data de apresentação: 18 / 06 / 2013
_______________________________
CARLOS ALBERTO PEDROSO ARAÚJO
Prof. em Sistemas de Informação - CEULS/ULBRA
_____________
Conceito
______________________________
CLAYTON ANDRE MAIA DOS SANTOS
Prof. em Sistemas de Informação - CEULS/ULBRA
_____________
Conceito
______________________________
MARIALINA CORRÊA SOBRINHO
Prof ª. em Sistemas de Informação - CEULS/ULBRA
_____________
Conceito
AGRADECIMENTOS
Agradeço primeiramente a minha Mãe, Maria Rosinete, por ter me dado a
oportunidade de cursar uma faculdade, ela foi e continua sendo uma mulher
guerreira.
Agradeço também ao meu padastro, Francisco de Oliveira, que juntamente
com minha mãe me deram essa oportunidade.
Agradeço também ao meu pai, Raimundo Mota, por ter ajudado com essa
formação.
Agradeço a minha família, Suzana Rebelo, Ana Beatriz e Ana Karolina, por ter
toda paciência do mundo, nas horas que eu não podia dar atenção.
Agradeço ao meus professores do Curso deSistema de Informação, por ter
compartilhado “um pouco” de seus conhecimentos.
Agradeço colegas e amigos, pelo companheirismo
formação acadêmica.
durante toda minha
Ao
meu
Orientador Professor Carlos Araújo, pela sua dedicação e
compreensão, sem sua ajuda não sei o que seria desse trabalho.
O Conhecimento é o somatório das
informações que adquirimos, é a base
daquilo que chamamos de Cultura. Podemos
adquirir Conhecimento sem sequer vivermos
uma experiência fora dos livros e das aulas
teóricas. Para se ser Sábio é preciso viver,
experimentar, ousar, ponderar, amar,
respeitar, ver e ouvir a própria vida.
(frase retirado do blog rivalcir.com.br)
RESUMO
Em pleno século XXI ainda existem empresas com grandes dificuldades para
armazenar suas informações e, tais companhias, estão sempre em busca de
soluções para seus problemas. A Engenharia de Software apresenta-se como
resposta em face desses problemas enfrentados e seu mercado vem crescendo
bastante nos últimos tempos. A colônia de Pescadores Z-20 é uma empresa
sindicalista sem fins lucrativos e conta com mais de dez mil associados. Por conta
desse grande número de sócios, torna-se necessário um sistema de informação que
possa trabalhar com esse volume de dados e agilizar todo o processo de
gerenciamento das informações, que hoje é feito de forma manual. O projeto de
desenvolvimento de Software, apresentado neste trabalho, pretende solucionar o
problema da informação na Colônia Z-20. Todo o processo de cadastro, relatórios,
controle de pagamento e levantamento de informações, passará a funcionar de
forma automatizada. O processo de desenvolvimento do projeto será feito através da
metodologia P@PSI, que oferece um método ágil para pequenos sistemas. No
desenvolvimento das interfaces gráficas será usado o Delphi 7.0e, para fazer toda a
modelagem do projeto, será utilizado o JUDE Community – UML (Unified Modeling
Language). O Banco de dados utilizado será o Firebird 2.5. No primeiro momento de
execução do projeto serão priorizados todos os cadastros, para que o usuário logo
se familiarize com o sistema.
Palavras-Chaves: Engenharia de Software. P@PSI. JUDE Community.
ABSTRACT
In the XXI century there are still companies with great difficulty to store your
information and such companies are always looking for solutions to their problems.
Software Engineering is presented as a response in the face of these problems faced
and their market has grown impressively in recent times. Fishermen Colony Z-20 is a
non-profit company union and has over ten thousand members. Because of this large
number of partners, it is necessary an information system that can work with this
volume of data and streamline the whole process of information management, which
is currently done manually. The software development project, presented in this
paper aims to solve the problem of information in the Colony Z-20. The entire
process of registration, reporting, control and payment information survey, will run in
an automated fashion. The development process of the project will be done by P @
PSI methodology that offers an agile method for small systems. In the development
of graphical interfaces will use the Delphi 7.0, and to all the modeling project, will be
used JUDE Community - UML (Unified Modeling Language). The database will be
used Firebird 2.1. At first the project implementation will be prioritized all entries, so
that the user immediately become familiar with the system.
Keywords: Software Engineering. P @ PSI. JUDE Community.
LISTA DE ILUSTRAÇÕES
FIGURA 1. DIAGRAMA DE ATIVIDADES, REPRESENTANDO ASFASES DE
PLANEJAMENTO, DESENVOLVIMENTO E ENCERRAMENTO COM AS
ATIVIDADES (EM AZUL) E ARTEFATOS (EM VERDE).FONTE: GELLER, 2008 . 20
FIGURA 2. O PROCESSO SCRUM – METHODS & TOOLS, 2013. ........................ 21
FIGURA 3. EXTREME PROGRAMMING – HALLOGRAM PUBLISHING, 2013. .... 22
FIGURA 4. TELA JUDE COMMUNITY – AQUIVO PESSOAL, 2013...................... 24
FIGURA 5. SQL MANAGER 2005 FOR INTERBASE/FIREBIRD – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 25
FIGURA 6. TELA FULL CONVERT ENTERPRISE – ARQUIVO PESSOAL, 2013. 26
FIGURA 7. CASO DE USO GERAL – ARQUIVO PESSOAL, 2013. ....................... 30
FIGURA 8. DIAGRAMA DE CASO DE USO CADASTRAR USUÁRIO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 32
FIGURA 9. DIAGRAMA DE CASO DE USO CADASTRAR SÓCIO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 32
FIGURA 10. DIAGRAMA DE CASO DE USO CADASTRAR DEPENDENTE –
ARQUIVO PESSOAL, 2013...................................................................................... 33
FIGURA 11. DIAGRAMA DE CASO DE USO CADASTRAR NÚCLEO DE BASE –
ARQUIVO PESSOAL, 2013...................................................................................... 33
FIGURA 12. DIAGRAMA DE CASO DE USO CADASTRAR REGIÃO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 34
FIGURA 13. DIAGRAMA DE CASO DE USO EMITIR RELATÓRIO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 34
FIGURA 14. DIAGRAMA DE CASO DE USO REGISTRARPAGAMENTO –
ARQUIVO PESSOAL, 2013...................................................................................... 35
FIGURA 15. DIAGRAMA DE CASO DE USO IMPRIMIR DOCUMENTOS –
ARQUIVO PESSOAL, 2013......................................................................................
35
FIGURA 16. DIAGRAMA DE CLASSE DE DOMÍNIO – ARQUIVO PESSOAL, 2013.37
FIGURA 17. CASO DE USO DO PRIMEIRO SPRINT – ARQUIVO PESSOAL, 2013.38
FIGURA 18. DIAGRAMA DE SEQUÊNCIA CADASTRAR USUÁRIO – ARQUIVO
PESSOAL, 2013 ....................................................................................................... 41
FIGURA 19. DIAGRAMA DE SEQUENCIA CONSULTAR USUÁRIO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 42
FIGURA 20. DIAGRAMA DE SEQUÊNCIA ALTERAR USUÁRIO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 43
FIGURA 21. DIAGRAMA DE SEQUÊNCIA CADASTRAR SÓCIO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 44
FIGURA 22. DIAGRAMA DE SEQUÊNCIA CONSULTAR SÓCIO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 45
FIGURA 23. DIAGRAMA DE SEQUÊNCIA ALTERAR SÓCIO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 46
FIGURA 24. DIAGRAMA DE SEQUÊNCIA CADASTRAR DEPENDENTE –
ARQUIVO PESSOAL, 2013...................................................................................... 47
FIGURA 25. DIAGRAMA DE SEQUÊNCIA ALTERAR DEPENDENTE – ARQUIVO
PESSOAL, 2013....................................................................................................... 48
FIGURA 26: CASO DE USO DO SEGUNDO SPRINT – ARQUIVO PESSOAL, 2013.49
FIGURA 27. DIAGRAMA DE SEQUÊNCIA CADASTRAR NÚCLEO BASE –
ARQUIVO PESSOAL, 2013...................................................................................... 51
FIGURA 28. DIAGRAMA DE SEQUÊNCIA CONSULTAR NÚCLEO BASE–
ARQUIVO PESSOAL, 2013...................................................................................... 52
FIGURA 29. DIAGRAMA DE SEQUÊNCIA ALTERAR NÚCLEO DE BASE –
ARQUIVO PESSOAL, 2013...................................................................................... 53
FIGURA 30. DIAGRAMA DE SEQUÊNCIA CADASTRAR REGIÃO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 54
FIGURA 31: DIAGRAMA DE SEQUÊNCIA CONSULTAR REGIÃO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 55
FIGURA 32. DIAGRAMA DE SEQUÊNCIA ALTERAR REGIÃO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 56
FIGURA 33. DIAGRAMA DE SEQUÊNCIA REGISTRAR PAGAMENTO –
ARQUIVO PESSOAL, 2013...................................................................................... 57
FIGURA 34. DIAGRAMA DE SEQUÊNCIA CONSULTAR PAGAMENTO –
ARQUIVO PESSOAL, 2013...................................................................................... 57
FIGURA 35. DIAGRAMA DE SEQUÊNCIA ALTERAR PAGAMENTO – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 58
FIGURA 36. DIAGRAMA DE CASO DE USO DO TERCEIRO SPRINT – ARQUIVO
PESSOAL, 2013....................................................................................................... 59
FIGURA 37. DIAGRAMA DE SEQUÊNCIA RELATÓRIO SÓCIO SEXO POR
REGIÃO – ARQUIVO PESSOAL, 2013. .................................................................. 62
FIGURA 38. DIAGRAMA DE SEQUÊNCIA RELATÓRIO SÓCIO SEXO POR
NÚCLEO DE BASE – ARQUIVO PESSOAL, 2013.................................................. 63
FIGURA 39. DIAGRAMA DE SEQUÊNCIA RELATÓRIO SÓCIO POR REGIÃO –
ARQUIVO PESSOAL, 2013...................................................................................... 63
FIGURA 40. DIAGRAMA DE SEQUÊNCIA RELATÓRIO SÓCIO POR NÚCLEO DE
BASE – ARQUIVO PESSOAL, 2013. ....................................................................... 64
FIGURA 41. DIAGRAMA DE SEQUENCIA RELATÓRIO SÓCIO ADIMPLENTE E
INADIMPLENTE NÚCLEO BASE – ARQUIVO PESSOAL, 2013. ........................... 65
FIGURA 42. MODELO CONCEITUAL SINDPESCA - ARQUIVO PESSOAL/2013 66
FIGURA 43. MODELO LÓGICO SINDPESCA - ARQUIVO PESSOAL/2013 ......... 66
FIGURA 44. TELA SPLASH – ARQUIVO PESSOAL, 2013. ................................... 67
FIGURA 45. TELA DE LOGIN – ARQUIVO PESSOAL, 2013. ................................ 68
FIGURA 46. TELA PRINCIPAL – ARQUIVO PESSOAL, 2013. .............................. 68
FIGURA 47. TELA CADASTRO SINDICATO – ARQUIVO PESSOAL, 2013. ......... 69
FIGURA 48. TELA CADASTRO USUÁRIO – ARQUIVO PESSOAL, 2013. ............ 69
FIGURA 49. TELA CADASTRO SÓCIO – ARQUIVO PESSOAL, 2013. ................. 70
FIGURA 50. TELA CADASTRAR DEPENDENTE – ARQUIVO PESSOAL, 2013... 71
FIGURA 51. TELA CADASTRAR REGIÃO – ARQUIVO PESSOAL, 2013. ............ 72
FIGURA 52. CADASTRAR NÚCLEO BASE – ARQUIVO PESSOAL, 2013. .......... 72
FIGURA 53. TELA CONSULTAR SÓCIO – ARQUIVO PESSOAL, 2013. .............. 73
FIGURA 54. TELA RELATÓRIO SÓCIO POR REGIÃO – ARQUIVOPESSOAL,
2013. ......................................................................................................................... 74
FIGURA 55. TELA VISUALIZAÇÃO IMPRESSÃO DO RELATÓRIO SÓCIO POR
REGIÃO – ARQUIVO PESSOAL, 2013. .................................................................. 74
FIGURA 56. TELA IMPRIMIR DECLARAÇÃO – ARQUIVO PESSOAL, 2013. ....... 75
FIGURA 57. TELA VISUALIZAÇÃO DE IMPRESSÃO DE DECLARAÇÃO –
ARQUIVO PESSOAL, 2013...................................................................................... 76
LISTA DE QUADROS
QUADRO 1. DESCRIÇÃO DOS CASOS DE USO – ARQUIVO PESSOAL, 2013. . 31
QUADRO 2. PRODUTO TOTAL – ARQUIVO PESSOAL, 2013. ............................. 31
QUADRO 3. ATIVIDADES REALIZADAS NO PRIMEIRO SPRINT – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 40
QUADRO 4. ATIVIDADES REALIZADAS NO SEGUNDO SPRINT – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 51
QUADRO 5. ATIVIDADES REALIZADAS NO TERCEIRO SPRINT – ARQUIVO
PESSOAL, 2013. ...................................................................................................... 61
SUMÁRIO
1 INTRODUÇÃO ....................................................................................................... 14
2 PLANEJAMENTO .................................................................................................. 16
2.1 DESCRIÇÃO DA SOLICITAÇÃO DO CLIENTE ................................................... 16
2.2 DESCRIÇÃO DO SISTEMA ATUAL .................................................................... 17
2.3 LEVANTAMENTOS DOS PROBLEMAS ENFRENTADOS.................................. 17
2.4 LEVANTAMENTOS DEREQUISITOS ................................................................ 18
2.4.1 Requisitos funcionais inciais ........................................................................ 19
2.4.2 Requisitos de informações iniciais .............................................................. 19
2.4.3 Requisitos não funcionais inciais ................................................................. 19
2.4.3.1 Requisitos Operacionais ............................................................................ 20
2.4.3.2 Requisitos de Desempenho ....................................................................... 20
2.4.3.3 Requisitos de Segurança ............................................................................ 20
2.5 DEFINIÇÃO DO PROCESSO DE DESENVOLVIMENTO.................................... 21
2.6 FERRAMENTAS UTILIZADAS ............................................................................ 21
2.6.1 P@PSI.............................................................................................................. 21
2.6.1.2 XP - Extreme Programming ........................................................................ 23
2.6.2 JUDE Community - UML ................................................................................ 24
2.6.3 SQL Manager 2005 for InterBase/Firebird .................................................... 26
2.6.4 Full Convert Enterprise .................................................................................. 27
2.6.4.1 Funcionalidades .......................................................................................... 28
2.6.4.2 Compatível com origem de dados ............................................................. 28
2.6.4.3 Compatível com destino de dados ............................................................29
2.6.5 FIREBIRD 2.5 .................................................................................................. 29
2.6.6 DELPHI 7 ......................................................................................................... 30
3 DESENVOLVIMENTO ........................................................................................... 31
3.1 FASE DE PLANEJAMENTO DO DESENVOLVIMENTO ..................................... 31
3.1.1 Analise dos Requisitos .................................................................................. 31
3.1.2 Documentação dos casos de uso ................................................................. 34
3.2 FASE DE DESENVOLVIMENTO ......................................................................... 38
3.2.1 Definição dos Sprints..................................................................................... 39
3.2.2 Primeiro Sprint backlog ( data inicio/fim) .................................................... 40
3.2.3 Segundo Sprint backlog ( data inicio/fim) .................................................... 50
3.2.4 Terceiro Sprint backlog ( data inicio/fim) ..................................................... 61
3.2.6 Modelagem do Sistema.................................................................................. 67
3.3 ENCERRAMENTO .............................................................................................. 69
3.3.1 Tela splash ...................................................................................................... 69
3.3.2 Tela de Login .................................................................................................. 69
3.3.3 Tela inicial ....................................................................................................... 70
3.3.4 TelaCadastrar Sindicato ............................................................................... 71
3.3.7 Tela Cadastrar Dependentes ................................ Erro! Indicador não definido.
3.3.8 Tela Cadastrar Região.................................................................................... 74
3.3.9 Tela Cadastrar Núcleo de Base ..................................................................... 75
3.3.10 Tela Consultar Sócio .................................................................................... 76
3.3.11 Tela de Relatório .......................................................................................... 76
3.3.12 Tela Imprimir declaração ............................................................................. 78
4 CONCLUSÃO ........................................................................................................ 81
BIBLIOGRAFIA ........................................................................................................ 83
14
1 INTRODUÇÃO
Hoje em dia está ficando cada vez mais difícil para as empresas, de grande e
pequeno porte, lidar com grandes demandas de informações. A solução para esse tipo de
problema são sistemas de informação que sejam capazes de suportar as exigências,
cada vez maiores, de dados e processamentos. Porém, antes de implantar qualquer tipo
de sistema em uma empresa, deve-se fazer um planejamento para analisar os possíveis
problemas. Dentre esses problemas, está a necessidade de capacitar pessoas para
operar o programa, visto que, sem profissionais aptos para utilizá-lo, o mesmo seria
inviável, ficando na mesma situação que era antes. Com o uso desses sistemas nas
organizações, os usuários são obrigadas a mudar seu modo de trabalhar, passando do
modo manual para oinformatizado.
Este trabalho apresenta uma proposta de desenvolvimento de um sistema de
informação, para controlar o fluxo de informações da Colônia de Pescadores de
Santarém, denominada Z-20. Todo o processo de cadastro (Sócio, Dependente,
pagamento, Cidade, Núcleo de Base e Região), emissão de relatórios, consultas,
impressão de documentos (declaração, renda, moradia, Seap (Secretaria Estadual de
Aquicultura do Pará), transferência, requerimento, guia de recolhimento da previdência
social dos associados), são feitos de maneira rústica, de forma manual, com uso de
arquivos em papel. A partir do momento em que o sistema passar a funcionar, todo e
qualquer serviço será feito através dele, dando mais agilidade nos processos de
atendimentos, com todas as informações em um só lugar.
Para dar início ao projeto de desenvolvimento foram realizadas várias visitas na
Colônia de Pescadores de Santarém (Z-20), juntamente com quem convive com a
situação no local de trabalho. Essas pessoas sabem das dificuldades enfrentadas quando
é necessário fazer consultas ou registros dos sócios, na associação. O trabalho segue as
orientações do P@PSI, metodologia ágil para desenvolvimento de pequenos sistemas
que utiliza os recursos da UML (Linguagem de Modelagem Unificada).
O P@PSI é um processo de desenvolvimento que foi escolhido para o SindPesca
por ser um processo que se adequa as necessidades do sistema. Ele foi criado pelos
alunos e professores do curso de Sistemas de Informação, do CEULS/ULBRA.
As atividades do modelo P@PSI são divididas nos seguintes passos: Planejamento
(definição dos requisitos, Seleção dos itens do produto total), Desenvolvimento (Projeto
15
de funcionalidade do Sprint, Implementar funcionalidade do Sprint) e Encerramento
(Revisão do Sprint). Para o desenvolvimento do sistemaSindPesca foram utilizadas as
seguintes ferramentas: o Firebird 2.5 para criação do banco de dados, a IDE Delphi 7.0
para a criação e desenvolvimento das interfaces gráficas e para fazer toda a modelagem
do projeto será utilizado o JUDE Community – UML (Linguagem
de Modelagem
Unificada).
Este trabalho está dividido em quatro capítulos, sendo que no primeiro consta da
introdução. O segundo capítulo trata das considerações iniciais, onde são destacados os
requisitos do sistema, as tecnologias utilizadas e o processo de desenvolvimento
utilizado. O terceiro capítulo apresenta o desenvolvimento do software, destacando as
fases de planejamento, desenvolvimento e encerramento do sistema. E por fim, o quarto
capítulo conclui o presente trabalho.
16
2 PLANEJAMENTO
Na fase de planejamento é feita uma análise na solicitação do cliente, para que
possam ser observadas todas as suas necessidades. É nessa fase que são levantados
todos os requisitos funcionais e não funcionais do sistema. Baseado nos problemas
enfrentados que é elaborado todo o planejamento do sistema, quais as ferramentas a ser
utilizadas para que não haja nenhum problema durante a fase de desenvolvimento.
Toda fase de desenvolvimento segue
as orientações do P@PSI, que é uma
ferramenta para elaboração e desenvolvimento de pequenos projetos. A primeira fase do
processo P@PSI é a fase de planejamento que tem como objetivo a descrição da
solicitação do cliente, descrição do sistema atual, levantamento dos problemas
enfrentados, levantamento de requisitos, definição do processo e ferramentas utilizadas.
Para criação do banco de dados do sistema será utilizado o Firebird 2.5, por ser
uma ferramenta de gerenciamento de banco de dados grátis, mais muito poderosa em
questão de segurança. Para a criação e programação dasinterfaces gráficas será
utilizado a IDE Delphi 7.0, por ser uma ferramenta de desenvolvimento visualmente, e
muito poderosa. E para criação dos diagramas será utilizada o JUDE Community – UML
(Linguagem de modelagem unificada).
2.1 DESCRIÇÃO DA SOLICITAÇÃO DO CLIENTE
A Colônia de Pescadores Z-20, do município de Santarém, é uma associação civil
e sindical de pescadores(as) artesanais, sem fins lucrativos. Atualmente conta com mais
de 10.000 integrantes. Não é possível dizer um número exato, porque quase todo mês
entram e saem associados. Por causa desse grande número de sócios registrados na
associação, há uma procura muito grande em relação à documentos, todos os dias da
semana, tumultuando a sede onde ocorre o atendimento ao público, visto que todo o
processo é feito manualmente. Por exemplo, quando um sócio solicita uma declaração, o
documento é redigido em uma máquina de datilografia e se todo esse processo fosse feito
através de um sistema informatizado não haveria demora no atendimento, pois apenas
com um click, o sistema faria todo esse processo de digitalização.
17
Como em qualquer empresa de grande ou pequeno porte, que trabalha com
grande fluxo de dados, na Z-20 há dificuldades em armazenar informações para que no
futuro não perca essa base de dados. Com o passar do tempo houve grandes mudanças
no sistema de atendimento, onde cresceu o número de associados, tornando-se cada vez
mais difícil trabalhar com tantas informações.
Com esse grande número de associados, a Z-20 carece de um sistema com
capacidade de processar o seu intenso volume de informações e armazenamento de
dados. Para isso, torna-se necessário o desenvolvimento de um software que solucione a
grande problemática de acesso aos dados, existente na colônia de pescadores.
O sistema deve fazera implementação dos seguintes módulos: Cadastro de sócio,
Cadastro de Dependente, Cadastro de núcleo de base, Cadastro de região, Cadastro de
cidade, Impressão de declarações referente à renda, moradia, Seap(Secretaria Estadual
Aquicultura do Pará), transferência, requerimento, guia de recolhimento da previdência
social dos associados, Controle de pagamentos dos associados, registrar e consultar
pagamento, e imprimir relatório para cada sócio.
2.2 DESCRIÇÃO DO SISTEMA ATUAL
As grandes mudanças no cenário empresarial têm levado às organizações
prezarem, cada vez mais, pela qualidade das informações tanto gerenciais quanto
financeiras, pois à consistência das mesmas tem se transformado num fator determinante
para sobrevivência e continuidade da empresa no mercado atual.
Pelo fato da associação de pescadores ainda trabalhar com arquivos manuais, do
tipo pasta, e contar com mais de 10.000 associados, as informações contidas nesses
documentos tornam-se cada vez mais difíceis de serem consultadas. Todas às
declarações que precisam ser emitidas, o cadastramento de um novo sócio, cadastro de
um núcleo de base e região, são feitas de forma manual, seguindo um modelo. Cada ano
que se passa, o número de associados cresce, ficando mais difícil o controle dos
mesmos.
18
2.3 LEVANTAMENTO DOS PROBLEMAS ENFRENTADOS
Os problemas são inúmeros, começando desde o cadastro de um novo sócio até a
hora de emitir uma declaração. O processo de cadastro é feito através de uma ficha de
inscrição, ocasionando grande perda de tempo ao preenchê-la de forma manual.
O sindicato não tem um controle total dos seus associados, devido o modo de
trabalhar ainda é de maneira muito que ultrapassado, através de fichas e arquivos de
pastas suspensas. Esse procedimento dentro de uma empresa que trabalhacom um
grande volume de informação, fica muito mas difícil ter o controle.
Por questão desses problemas enfrentados, a Colônia de Pescadores de Santarém
vêm em busca de um sistema para controlar o fluxo de dados de seus associados. E para
dar melhor atendimento de qualidade e mais preciso.
2.4 LEVANTAMENTOS DE REQUISITOS
Uma das primeiras atividades consiste no levantamento de requisitos. Um requisito
é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar
para atingir os seus objetivos.
Nesta etapa o engenheiro de software busca compreender as necessidades do
usuário e o que ele deseja que o sistema a ser desenvolvido realize. Isto é feito
principalmente por meio de entrevista, onde o engenheiro de software tenta compreender
como funciona atualmente o processo a ser informatizado e quais serviços o cliente
precisa que o software forneça. “Devem ser realizadas tantas entrevistas quantas forem
necessárias para que as necessidades do usuário sejam bem compreendidas. Durante as
entrevistas o engenheiro deve auxiliar o cliente a definir qual o nível de desempenho
exigido do software” (GUEDES, 2004, p19). Podemos classificá-los de duas maneiras:
Requisitos funcionais e Requisitos não funcionais.
19
2.4.1 Requisitos Funcionais Iniciais
Os requisitos funcionais estão ligados diretamente aos processos que o sistema
tem que executar. Os requisitos iniciais desta proposta são:
Cadastrar Usuário
Cadastrar Sócios
Cadastrar Dependentes
Alterar Sócio
Excluir Sócio
Consultar Sócio
Registrar Pagamento
Gerar relatório sócio adimplente e inadimplente
Gerar relatório sócio por núcleo de base
Gerar relatório núcleo por região
Gerar relatório sócio por sexo
2.4.2 Requisitos de Informações Iniciais
Os requisitos iniciais que o sistema deveapresentar imediatamente para que o
processo de desenvolvimento seja executado serão:
Pesquisar cadastro de sócio
Consultar pagamento de sócio
Gerar relatórios
Gerar
documentos
(declarações,
renda,
moradia,
Seap,
transferência,
requerimento, guia de recolhimento da previdência social dos associados).
2.4.3 Requisitos não funcionais iniciais
Os requisitos não funcionais falam da forma como os requisitos funcionais devem
ser alcançados. Eles definem propriedades e restrições do sistema. Muitos
requisitos não funcionais são também requisitos de qualidade, como exigência de
desempenho e robustez. Outros são restrições ou exigências de uso de uma ou
outra tecnologia (XEXÉO, 2007, p44).
20
Os requisitos não funcionais referem-se as propriedades comportamentais que o
sistema deve possuir. Os requisitos não funcionais estão classificados em Requisitos
Operacionais, Requisitos de Desempenho e Requisitos de Segurança.
2.4.3.1 Requisitos Operacionais
Nesse tópico serão mostrados todos os requisitos operacionais para que o sistema
seja executado, tais como:
Computadores com sistema operacional Windows (2000, XP, vista ou 7)
Uma rede para acesso ao banco de dados.
Um servidor de banco de dados;
2.4.3.2 Requisitos de Desempenho
Nesse tópico serão apresentados os requisitos de desempenho para que o sistema
implantado possa funcionar sem nenhum problema. Toda e qualquer ação que o usuário
faça no sistema de busca, ou para imprimir um relatório, deve ter um tempo de resposta
mais rápido possível. As respostas apresentadas no sistema têm que estar absolutamente
exatas, onde:
Qualquer interação que o usuário faça com o sistema não pode levar muito tempo
de uma tela para outra;
O sistema tem que estar acessível 24horas;
2.4.3.3 Requisitos de SegurançaOs requisitos de segurança são necessários para limitar o acesso à funções ou
dados no sistema, onde:
O sistema deve ser acessado com senha;
21
Todas as informações dos associados, só podem ser acessadas por usuários
cadastrados no sistema;
2.5 DEFINIÇÕES DO PROCESSO DE DESENVOLVIMENTO
No desenvolvimento do projeto serão utilizadas metodologias de planejamento para
que possa ser desenvolvido o sistema sem complicações futuras. Existem diversas
metodologias para construção de software, e a utilizada no modelo P@PSI (Processo
Ágil para Pequenos Sistemas), adapta-se em projetos de pequeno ou grande porte.
2.6 FERRAMENTAS UTILIZADAS
Apresenta-se neste tópico uma breve descrição do processo e ferramentas
utilizadas para o desenvolvimento do SindPesca, como, o ambiente de desenvolvimento
Delphi 7, Banco de dados Firebird 2.5, a linguagem de modelagem UML e, para a
modelagem ER do banco de dados, a ferramenta JUDE1 Community. O processo utilizado
é apresentado a seguir com o detalhamento e as especificações necessárias.
2.6.1 P@PSI
O processo constitui-se de três etapas representadas por raias na figura 1:
Planejamento, Desenvolvimento e Encerramento que possibilitam a interatividade.
Inicia-se com a fase de Planejamento, onde a equipe de desenvolvimento trabalha
na captura de requisitos para definir o Produto Total. Os recursos utilizados para
esta atividade são reuniões, entrevistas com os clientes, questionários, entre
outras, que resultam em um diagrama de casos de uso inicial. (GELLER,2008,
p6).
A figura abaixo mostra com mais detalhes as fases do P@PSI.
1 JUD - Java and UML Developers Environment
22
Figura 1 - Diagrama de Atividades, representando as fases de Planejamento, Desenvolvimento e
Encerramento com as atividades (em azul) e artefatos (emverde).
Fonte: Geller, 2008.
A proposta de utilização do Diagrama de Casos de Uso deve-se ao fato da
facilidade desse artefato para comunicação com o cliente. Seguindo para a fase de
Desenvolvimento, prioriza-se do Produto Total uma funcionalidade ou pequenas
funcionalidades, representadas por um ou mais casos de uso. Esse pequeno pacote com
os casos de uso priorizados chama-se Sprint.
O Sprint é solucionado em um fluxo de atividades diário, implementação e teste, ou
seja, executa-se o projeto, desenhando e detalhando as classes, implementa-se o código
e testa-se a unidade funcional diariamente, podendo este fluxo ser interativo. As
atividades desenvolvidas na fase de Encerramento incluem a revisão, demonstração e
entrega do Sprint ao cliente. Neste ponto, o processo retorna executando uma nova
iteração com um novo conjunto de funcionalidades priorizadas, criando um novo Sprint,
passando por todas as fases. Quando o Produto Total estiver finalizado o processo
encerra-se.
23
2.6.1.1 SCRUM
Os princípios do Scrum são usados para guiar as atividades de desenvolvimento
dentro de um processo que incorpora as seguintes atividades de arcabouço:
requisitos, análise, projeto, evolução e entrega. Através da metodologia Scrum a
implementação do sistema se torna mais flexível (…) O Scrum enfatiza o uso de
um conjunto de padrões de processos de software que se mostraram efetivos para
projetos com prazos apertados. (PRESSMAN,2006,p69).
Na figura 2 abaixo, é mostrado o processo de desenvolvimento com mais detalhes.
Figura 2 - O Processo Scrum.
Fonte: Methods & Tools, 2013.
2.6.1.2 XP - Extreme Programming
“O XP inclui um conjunto de regras e práticas que ocorrem no contexto de quatro
atividades de arcabouço: planejamento, projeto, codificação e teste”. (PRESSMAN, 2006,
p63).24
Figura 3 - Extreme Programming.
Fonte: HALLoGRAM Publishing, 2013.
Extreme Programming (XP) é uma metodologia de desenvolvimento de software,
nascida nos Estados Unidos ao final da década de 90. Vem fazendo sucesso em
diversos países, por ajudar a criar sistemas de melhor qualidade, que são
produzidos em menos tempo e de forma mais econômica que o habitual. Tais
objetivos são alcançados através de um pequeno conjunto de valores, princípios e
práticas, que diferem substancialmente da forma tradicional de se desenvolver
software.(Improve It, 2012).
O XP concentra os esforços da equipe de desenvolvimento em atividades que
geram resultados rapidamente na forma de software intensamente testado e
alinhado às necessidades de seus usuários. Além disso, simplifica e organiza o
trabalho combinando técnicas comprovadamente eficazes e eliminando atividades
redundantes. Por fim, reduz o risco dos projetos desenvolvendo software de forma
iterativa e reavaliando permanentemente as prioridades dos usuários.
(TELES,2004).
2.6.2 JUDE Community - UML
Para fazer toda a modelagem do SindPesca será utilizada a ferramenta Jude
Community que é utilizada juntamente com a linguagem UML. Essa ferramenta permite
criar
todos os diagramas que serão utilizados no processo de desenvolvimento do
SindPesca. Esses diagramas definem todo o comportamento do sistema, servem tambem
como um guia de desenvolvimento.
25
A UML(Unified Modeling Language ou Linguagem de Modelagem Unificada), é
uma linguagem visual utilizada para modelar sistemas computacionais por meio do
paradigma de Orientação a Objetos. (...) tornou-se, nos últimos anos, a linguagem
padrão de modelagem de software adotada internacionalmente pela indústria de
Engenharia de Software. (GUEDES, 2004, p17).
A UML não é umalinguagem de programação e sim uma linguagem de
modelagem, cujo objetivo é auxiliar os engenheiros de software a definir as
características do software, tais como seus requisitos, seu comportamento, sua
estrutura lógica, a dinâmica de seus processos e até mesmo suas necessidades
físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado.
(GUEDES,2004, p17).
Isso quer dizer que a UML é uma linguagem que define elementos gráficos
(visuais) que podem ser utilizados na modelagem de sistemas. “Esses elementos
permitem representar o conceito dos elementos gráficos definidos nesta linguagem podese construir diagramas que representam diversas perspectivas de um sistema”
(BEZERRA, 2007, p15).
O Objetivo da modelagem através da UML é auxiliar os engenheiros de software a
definir características do software, tais como seus requisitos, seu comportamento,
sua estrutura lógica, a dinâmica de seus processos e até mesmo as suas
necessidades físicas em relação ao equipamento sobre o qual o sistema deverá
ser implantado. (BERTA, 2006, p9).
26
Figura 4 - Tela Jude Community.
Fonte: Aquivo Pessoal, 2013.
2.6.3 SQL Manager 2005 for InterBase/Firebird
O SQL Manager para InterBase/Firebird é uma ferramenta de alta performance
para desenvolvimento e administração de bancos de dados InterBase e Firebird.
Trabalhando com a maioria das versões do InterBase/Firebird, ele permite gerenciar todos
os recursos deste banco de dados como: triggers, views, stored procedures, funções,
backups incrementais, etc. O SQL Manager para InterBase/Firebird permite que se crie ou
edite todos os objetos do banco de dados, crie seus bancos de dados visualmente,
execute scripts SQL, importe e exporte dados do banco de dados, gerencie
usuários/privilégios e execute outras inúmeras operaçõestornando a administração do
seu banco de dados InterBase/Firebird muito mais eficiente.
27
Figura 5 - SQL Manager 2005 for InterBase/Firebird.
Fonte: Arquivo Pessoal, 2013.
2.6.4 Full Convert Enterprise
O Full Convert Enterprise oferece uma forma confortável de converter informações
de bancos de dados, para que sejam transferidas para outros bancos. Todos os bancos
de dados são apontados com estrutura
em árvore e multi-seleção, o que simplifica certas
ações, como gravar e manipular parâmetros. “O Full Convert é uma ferramenta completa
para conversão de bancos de dados” (SILICONACTION, 2010).
A seguir sera apresentadas algumas caracteristicas da ferramenata Full Converte,
para que possa ter um melhor entendimento dessa grande ferramenta.
28
Figura 6 - Tela Full Convert Enterprise.
Fonte: Arquivo Pessoal, 2013.
2.6.4.1 Funcionalidades
Criação de todos os dados / estruturas e chaves estrangeiras (Foreign Keys)
Suporte avançado a linhas de comando
Possibilidade de agendar processos de conversão
Suporte a campos tipo BLOB e Memo
Lida facilmente com massas de dados de alta densidade.
2.6.4.2 Compatível com origem de dados
Microsoft Access
dBase
FoxPro
Microsoft Excel
29
InterBase
Firebird
Lótus 1 / 2 / 3
MySQL
Oracle
PostgreSQL
Paradox
Microsoft SQL Server
XML
Arquivos de texto em formato CVS
Qualquer banco que utilize ODBC
2.6.4.3 Compatível com destino de dados
Microsoft SQL Server,
Oracle
MySQL
PostgreSQL
Microsoft Access
InterBase
Firebird
2.6.5 FIREBIRD 2.5
O Firebird surgiu em 1984, sob o nome de InterBase, fruto do trabalho de Jim
Starkey e Ann Harrison (os pais do Firebird). O nome da empresa de Jim onde o
InterBase surgiu era Groton Database Systems, daí a clássica sigla GDS. Em 1991 a
companhia foi comprada pela Ashton Tate,que por sua vez foi comprada pela Borland,
logo em seguida.
De 1991 até 1999 a Borland responsabilizou-se pelo desenvolvimento do
InterBase. Em 1999, a Borland resolveu abrir o código fonte do Interfase de forma que
30
desenvolvedores em todo o mundo pudessem trabalhar no seu desenvolvimento. Esta
ficou conhecida como Firebird. Ao mesmo tempo, criou uma versão própria do InterBase,
com
recursos
adicionais
desenvolvidos
por
ela
e
incorporando
as melhorias
acrescentadas ao Firebird. Em resumo, o Firebird é o banco de dados que se utiliza neste
sistema, é uma ferramenta que já existe há quase 22 anos, tendo evoluído muito nesse
período e que ainda continua a evoluir.
O Firebird é um poderoso sistema de gerenciamento de banco SQL, muito utilizado
em grandes projetos, adequa-se a qualquer sistema operacional. Atende igualmente bem
à aplicações de um único usuário e à aplicações corporativas.
Um simples servidor Firebird pode manipular múltiplas bases de dados
independentes, cada uma com múltiplas conexões clientes. E o melhor de tudo: é
verdadeiramente Open Source, assim, livre de qualquer exigência de licenças,
mesmo para uso comercial. (CANTU, 2008)
2.6.6 DELPHI 7
O
Delphi
é
uma
ferramenta
RAD
(Rapid
Application
Development
–
Desenvolvimento Rápido de Aplicações), criada pela Borland. É uma ferramenta de
propósito geral, permitindo o desenvolvimento de aplicações tanto científicas como
comerciais, com a mesma facilidade e alto desempenho. Integra-se facilmente com a API
(Application Program Interface) do Windows, possui um compilador extremamente rápido,
que gera executáveis nativos (em código de máquina, não interpretado), obtendo assim, a
melhor performance e total proteção do código-fonte. O Delphi é extensível,sua IDE
(Integrated Development Environment – Ambiente de Desenvolvimento Integrado) pode
ser ampliada e personalizada com adição de componentes e ferramentas criadas
utilizando-se o Object Pascal, a linguagem de programação do Delphi. “O Object Pascal é
uma poderosa linguagem Orientada a Objeto, que além de possuir as características
tradicionais das mesmas como classe objetos”. (SOARES, 2006)
31
3 DESENVOLVIMENTO
Neste capítulo serão descritas todas as etapas do desenvolvimento do sistema
SindPesca. Onde, na primeira fase do desenvolvimento, será feita toda a análise dos
requisitos, na segunda fase a execução dos Sprints e na terceira parte serão mostradas
as principais telas do sistema.
3.1 FASE DE PLANEJAMENTO DO DESENVOLVIMENTO
Nesta fase do desenvolvimento é iniciado um contato diretamente com o cliente,
para colocar e definir os principais requisitos funcionais e não funcionais do sistema. O
representante do Sindicato escolhido foi a pessoa que lida diretamente com o caso, ou
seja, sua secretária.
Todos os processos de cadastro, levantamento de informação e relatórios são
feitos pela pessoa responsável pela secretaria, bem poucas informações foram
levantadas pela sua diretoria. Considerando que seus diretores são renovados a cada três
anos, dependendo de seu mandato, pode renovar por mais três anos.
3.1.1 Análise dos Requisitos
Após serem coletados todos os requisitos e analisados cada um, foram definidos
os seguintes casos de usos, exibidos na figura abaixo para demonstrar suas finalidades.
32
Figura 7 - Caso de Uso Geral.
Fonte: Arquivo Pessoal, 2013.
Quadro 1 - Descrição dos Casos de Uso.
ENVENTO
DESCRIÇÃO
Cadastrar
O administrador pode cadastrar a secretária para utilizar o
Usuário
Cadastrar Sócio
Alterar Sócio
sistema. Oadministrador pode alterar ou excluir secretária.
A secretária pode cadastrar, alterar, excluir e consultar os
dados do sócio.
33
Cadastrar
A secretária pode cadastrar, alterar, excluir e consultar os
Dependente
dados do dependente.
Alterar
Dependente
Cadastrar Núcleo A secretária pode cadastrar, alterar, excluir dados do Núcleo de
de Base
Base.
Cadastrar Região A secretária pode cadastrar, alterar, excluir dados da região.
Emitir relatório
Registrar
A secretária pode consultar e imprimir relatório.
A secretária pode consultar, registrar e receber pagamentos.
pagamento
A secretária pode imprimir documentos solicitados pelos
Imprimir
sócios. Os documentos a ser impressos são: Declaração
documentos
moradia, declaração renda, transferência e requerimento.
Fonte: Arquivo Pessoal, 2013.
Quadro 2 - Produto Total.
PRODUTO TOTAL
Produto
Sistema para colônia de pescadores Z-20 - SindPesca
Data
Determinar uma data
Prioridade
Item
Descrição
Fase de Planejamento
Estimativa(horas)
8
Alta
1
Levantamento de requisitos
4
Alta
2
Modelagem (caso de uso)
2
Alta
3
Modelagem (classes)
2
Fase de Desenvolvimento
204
Alta
4
Cadastrar Usuário
24
Alta
5
Cadastrar Sócio
24
Alta
6
Cadastrar Dependente
24
Alta
7
Cadastrar Núcleo de Base
24
Alta
8
Cadastrar Região
24
Baixa
9
Emitir relatório
12
Alta
10
Registrar pagamento
24
34
Baixa
11
Imprimir documentos
48
Fase de Encerramento
2
Alta
12
Entrega da documentação do software
1
Alta
13
Entrega do software
1
Fonte: Arquivo Pessoal, 2013.
3.1.2 Documentação dos Casos de Uso.
A documentação dos Casos de Uso é feita para que ocliente possa ver cada
evento, ou até mesmo explicar o que acontece em determinado caso. A figura abaixo
mostra o caso de uso Cadastrar Usuário no Sistema.
Figura 8 - Diagrama de caso de uso Cadastrar Usuário.
Fonte: Arquivo Pessoal, 2013.
Neste Caso de Uso, Cadastrar Usuário no Sistema, mostra os passos que o
Usuário Administrador percorre para inserir um novo ou, até mesmo, fazer alterações de
um usuário. Os dados inseridos são: nome
de usuário e senha.
A figura abaixo mostra o Caso de Uso Cadastrar Sócio no Sistema.
35
Figura 9- Diagrama de Caso de Uso Cadastrar Sócio.
Fonte: Arquivo Pessoal, 2013.
Nesse Caso de Uso, Cadastrar Sócio no Sistema, mostra os passos que o
Administrador e a Secretária percorrem para inserir um Novo Sócio ou fazer alterações no
seu Cadastro.
A figura abaixo mostrar o Caso de Uso Cadastrar Dependente.
Figura 10 - Diagrama de Caso de Uso Cadastrar Dependente.
Fonte: Arquivo Pessoal, 2013.
Nesse Caso de Uso Cadastrar Dependente no Sistema, mostra os passos que o
Administrador e a Secretária percorrem para inserir um Novo Dependente ou fazer
alterações no Cadastro do mesmo.
A figura abaixo mostra o Caso de Uso Cadastrar Núcleo de Base.
36
Figura 11 - Diagrama de Caso de Uso Cadastrar Núcleo de Base.
Fonte: Arquivo Pessoal, 2013.
Nesse Caso de Uso Cadastrar Núcleo de Base no sistema, mostra os passos que o
Administrador e a Secretária percorrem para inserir um novo Núcleo de Base ou, até
mesmo, fazer alterações nos já existentes.
A figura abaixo mostra o Caso de Uso Cadastrar Região.
Figura 12 - Diagrama de Caso de Uso Cadastrar Região.
Fonte: Arquivo Pessoal, 2013.
37
Nesse Caso de Uso Cadastrar Região no Sistema, mostra os passos que o
Administrador e a Secretária percorrem para inserir um novoCadastro de Região ou
alterar um cadastro existente.
A figura abaixo mostra o Caso de Uso Emitir Relatórios.
Figura 13 - Diagrama de Caso de Uso Emitir Relatório.
Fonte: Arquivo Pessoal, 2013.
Nesse Caso de Uso, Emitir Relatórios no Sistema, mostra os passos que o
Administrador e a Secretária percorrem para consultar e emitir um relatório.
A figura abaixo mostra o Caso de Uso Registrar Pagamento.
Figura 14 - Diagrama de Caso de Uso Registrar Pagamento.
Fonte: Arquivo Pessoal, 2013.
38
Nesse Caso de Uso, Registrar Pagamento no Sistema, mostra os passos que o
Administrador e a Secretária percorrem para registrar ou alterar um pagamento.
A figura abaixo mostra o Caso de Uso Imprimir Documentos.
Figura 15 - Diagrama de Caso de Uso Imprimir Documentos.
Fonte: Arquivo Pessoal, 2013.
Neste Caso de Uso, Imprimir Documentos no Sistema, mostra os passos que o
Administrador e a Secretária percorrem para imprimir documentos solicitados pelos
sócios.
3.2 FASES DE DESENVOLVIMENTO
Na fase de desenvolvimento são colocados em prática todo o processo de
planejamento já visto. Se algo der errado durante o processo de desenvolvimento, devese fazer uma revisão no que foi planejado, para que se possa fazer uma análise melhor
ou até mesmo
fazer uma mudança no projeto. Por isso que um bom planejamento
durante o desenvolvimento de um projeto, não se deve deixar de analisar cada detalhe
do projeto.
Nesta fase do desenvolvimento são considerados o tempo para cada Sprint,
levando em consideração o tempo para cada nível de complexidade dos mesmos. O fator
tempo e um fato fundamental de um determinado Sprint, e aonde se determina o tempo
de cada etapa, inicio e fim.
39
3.2.1 Definição dos Sprints
Seguindo os conceitos do P@PSI, os Sprints de maior prioridade são osprivilegiados no desenvolvimento do sistema. E os Casos de Usos correspondentes são:
Cadastrar Usuário, Cadastrar Sócio, Cadastrar Dependentes, Cadastrar Núcleo de Base,
Cadastrar Região e Registrar Pagamento, esses são os requisitos de prioridade alta. E
por fim serão desenvolvidos os requisitos de menor prioridade são eles: os Casos de Uso
Emitir Relatórios, Imprimir Documentos. Os Casos de Usos descritos acima foram
divididos em três Sprints. No primeiro sprint foram priorizado
os seguintes Casos de
Usos: Cadastrar Usuário, Cadastrar Sócio e Cadastrar Dependente. No segundo sprint:
Cadastrar Núcleo de Base, Cadastrar Região e Registrar Pagamento. E no terceiro e
ultimo sprint: Emitir Relatórios e Imprimir Documentos.
3.2.1.1 Diagrama de Classe de Domínio
Os diagramas de classe de domínio são utilizados em projetos de desenvolvimento
para a visualização das classes. Essas classes demonstra como as classe do diagrama
se relacionam.
Este é o diagrama mais utilizado e o mais importante da UML, servindo de apoio
para a maioria dos outros diagramas. Como o próprio nome diz, esse diagrama
define a estrutura das classes utilizadas pelo sistema, determinando os atributos e
métodos possuídos por cada classe, além de estabelecer como as classes se
relacionam e trocam informações entre si. (GUEDES, 2007, p15).
A figura abaixo, apresenta o diagrama de classe de domínio do SindPesca, esse
diagrama está voltado para criação do Sprint backlog.
40
Figura 16 - Diagrama de Classe de Domínio.
Fonte: Arquivo Pessoal, 2013.
3.2.2 Primeiro Sprint backlog ( 09/08 à 14/09/10)
Depois de fazer todas as análises em cada Caso de Uso, foram determinados para
o primeiro sprint os seguintes Casos de Usos: Cadastrar Usuário, Cadastrar Sócio e
Cadastrar Dependente. Na figura abaixo sãomostrados com mais detalhes os Casos de
Usos do produto total com prioridade alta.
41
Figura 17 - Caso de Uso do Primeiro Sprint.
Fonte: Arquivo Pessoal, 2013.
O primeiro sprint do projeto compreende mostrar as tarefas de implementação das
telas Principal SindPesca, Cadastrar Usuário, Cadastrar Sócio, Cadastrar Dependente,
Consultar Usuário, Consultar Sócio e Consultar Dependente. No quadro abaixo são
mostradas detalhadamente as atividades que serão desenvolvidas no Primeiro Sprint.
Quadro 3 - Atividades realizadas no primeiro Sprint.
PRIMEIRO SPRINT
Produto
Desenvolvimento de um sistema para colônia de pescadores
z-20 - SindPesca
Caso de uso
Cadastrar Usuário, Sócio e Dependente
Período
Três semanas a partir do dia 09/08/2010
Semanas
Data
entrega
Horas
Data
inicio
Data
limite
Modelagem do sistema – casos de
uso e classe de domínio.
09/08/10
12/08/10
10/08/10
3
3
Modelagem do sistema – Modelo
ER.
09/08/10
12/08/10
11/08/10
2
2
Definição das telas.
12/08/10
14/08/10
14/08/10
5
5
Desenvolvimento da tela do
SindPesca.
16/08/10
17/08/10
16/08/10
5
5
Implementação das funcionalidades 17/08/10
18/08/10
18/08/10
7
7
Descrição
42
SindPesca.
Desenvolvimento da tela Cadastrar 19/08/10
usuário.
21/0810
20/08/10
4
Implementação das funcionalidades 21/08/10
cadastrar usuário.
24/08/10
24/08/10
5
Desenvolvimento da tela Cadastrar 24/08/10
sócio.
25/08/10
Implementação das funcionalidades 25/08/10
cadastrar sócio.
Desenvolvimento da tela cadastrar
dependente.
4
2
7
25/08/10
5
5
28/08/10
27/08/10
7
7
30/08/10
31/08/10
31/08/10
5
5
Implementação das funcionalidades 31/08/10
cadastrardependente.
03/09/10
02/09/10
7
7
Desenvolvimento da tela consultar
Sócio por nome
03/09/10
03/09/10
03/09/10
5
5
Implementação das funcionalidades 04/09/10
consultar sócio por nome.
04/09/10
04/09/10
7
7
Desenvolvimento da tela consultar
sócio por núcleo de base.
06/09/10
06/09/10
06/09/10
5
5
Implementação das funcionalidades 07/09/10
consultar sócio por núcleo de base.
07/09/10
07/09/10
7
7
Desenvolvimento da
tela consultar
sócio por região.
08/09/10
08/09/10
08/09/10
5
5
Implementação das funcionalidades 09/09/10
consultar sócio por região.
09/09/10
09/09/10
7
7
Desenvolvimento da tela consultar
sócio por sexo.
10/09/10
10/09/10
10/09/10
5
5
Implementação das funcionalidades 11/09/10
consultar sócio por sexo
11/09/10
11/09/10
7
7
Desenvolvimento da tela consultar
dependente.
12/09/10
12/09/10
12/09/10
5
5
Implementação das funcionalidades 13/09/10
consultar dependente.
13/09/10
13/09/10
7
7
Teste de funcionalidades entre o
banco de dados e as telas.
14/09/10
14/09/10
1
1
09/08/10
Tempo total durante as três semanas
Fonte: Arquivo Pessoal, 2013.
118
43
Na figura abaixo, o Diagrama de Sequência Cadastrar Usuário mostra os passos
que o Usuário Administrador percorre para inserir um novo usuário no sistema. Para que
o Administrador do sistema insira um novo Usuário, primeiro deve-se fazer o login no
sistema. Após se identificar como administrador vai abrir a tela principal do sistema, faz o
acesso a tela de cadastro de usuário, e insere os dados do usuário e salva as
informações, e em seguida é mostrada uma mensagem “usuário cadastrado com
sucesso”.
Figura 18- Diagrama de SequênciaCadastrar Usuário.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 19, o diagrama de sequência Consultar Usuário mostra os
passos que o usuário administrador percorre para consultar usuário no sistema. Para que
o administrador do sistema possa consultar usuário, primeiro deve-se fazer o login no
sistema. Após se identificar como administrador vai abrir a tela principal do sistema, faz o
acesso a tela de consulta de usuário, e insere o nome do usuário e consulta as
informações, e em seguida são mostrados os dados do usuário se existir.
44
Figura 19 - Diagrama de Sequencia Consultar Usuário.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 20, o diagrama de sequência Alterar Usuário mostra os
passos que o usuário administrador percorre para consultar e fazer alterações no sistema.
Para que o administrador possa alterar, primeiro deve-se fazer o login no sistema. Após
se identificar vai abrir a tela principal do sistema, faz o acesso a tela de consulta de
usuário, e insere o nome do usuário e consulta as informações, e em seguida são
mostrados os dados do usuário se existir. Faz as alterações no formulário do usuário e
salva as informações, e em seguida é mostrada uma mensagem “dados alterados com
sucesso”.
45
Figura 20 - Diagrama de Sequência Alterar Usuário.
Fonte: Arquivo Pessoal, 2013.
Na figura 21, o diagrama de sequência Cadastrar Sócio mostra os passos que o
usuário secretária percorre para inserir um novo sócio no sistema. Para que a secretária
insira um novo sócio, primeiro deve-se fazer o login no sistema. Após se identificar vai
abrir a tela principal do sistema, faz o acesso a tela de cadastro de sócio, e insere os
dados do sócio e salva as informações, e em seguida é mostrada uma mensagem “sócio
cadastrado com sucesso”.
46
Figura 21- Diagrama de Sequência Cadastrar Sócio.
Fonte: Arquivo Pessoal, 2013.
Na figura 22, o diagrama de sequência Consultar Sócio mostra os passos que o
usuário secretária percorre para consultar sócio no sistema. Para que a secretária possa
consultar sócio, primeiro deve-se fazer o login no sistema. Após se identificar vai abrir a
tela principal do sistema, faz o acesso a tela de consulta de sócio, e insere o nome ou RG
e consultar as informações, e em seguida são mostrados os dados do sócio se existir.
47
Figura 22 - Diagrama de sequência Consultar Sócio.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 23, o diagrama de sequência Alterar Sócio mostra os passos
que o usuário secretária percorre para consultar e fazer alterações no sistema. Para que a
secretária possa alterar, primeiro deve-se fazer o login no sistema. Após se identificar vai
abrir a tela principal do sistema, faz o acesso a tela de consulta de sócio, e insere o nome
ou rg do sócio e consulta as informações, e em seguida são mostrados os dados do sócio
se existir. Faz as alterações no formulário do sócio e salva as informações, e em seguida
é mostrada uma mensagem “dados alterados com sucesso”.
48
Figura 23 - Diagrama de Sequência Alterar Sócio.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 24, o diagrama de sequência Cadastrar Dependente mostra
os passos que o usuário secretária percorre para inserir um novo dependente no sistema.
Para que a secretária insira um novo dependente, primeiro deve-se fazer o login no
sistema. Após se identificar vai abrir a tela principal do sistema, faz o acesso a tela de
cadastro de dependente, e insere os dados do dependente e salva as informações, e em
seguida é mostrada uma mensagem “dependente cadastrado com sucesso”.
49
Figura 24 - Diagrama deSequência Cadastrar Dependente.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 25, o diagrama de sequência Alterar Dependente mostra os
passos que o usuário secretária percorrer para consultar e fazer alterações no sistema.
Para que a secretária possa alterar, primeiro deve-se fazer o login no sistema. Após se
identificar vai abrir a tela principal do sistema, faz o acesso a tela de consulta dependente,
e insere o nome do dependente e consulta as informações, e em seguida são mostrados
os dados do dependente se existir. Faz as alterações no formulário do dependente e
salva as informações, e em seguida é mostrada uma mensagem “dados alterados com
sucesso”.
50
Figura 25 - Diagrama de Sequência Alterar Dependente.
Fonte: Arquivo Pessoal, 2013.
3.2.3 Segundo Sprint backlog (14/09 a 18/10/10)
No segundo sprint foram determinados os seguintes casos de usos: Cadastrar
Núcleo de Base, Cadastrar Região e Registrar Pagamento. Na figura 26 abaixo, são
mostrados com mais detalhes os Casos de Usos do Produto Total com prioridade alta.
51
Figura 26 - Caso de Uso do Segundo Sprint.
Fonte: – Arquivo Pessoal, 2013.
No segundo sprint do projeto compreende mostrar as tarefas de implementação
das telas Cadastrar Núcleo de Base, Cadastrar Região, Registrar Pagamento, Consultar
Núcleo Base, Consultar Região, Consultar Pagamento. No quadro abaixo, são mostrados
com mais detalhes as atividades que serão desenvolvidas no segundo sprint.
Quadro 4 - Atividades realizadas no segundo Sprint.
SEGUNDO SPRINT
Produto
Desenvolvimento de um sistema para colônia de pescadores z20 - SindPesca
Cadastrar Núcleo de Base, Cadastrar Região e Registrar
Caso de uso
Pagamento
Período
Três semanas a partir do dia 14/09/2010
Descrição
Data inicio
Data
limite
Dataentrega
Modelagem do sistema
(caso de uso e classe de
domínio).
14/09/10
17/09/10
16/09/10 3
3
Modelagem do sistema
(modelo ER)
17/09/10
20/09/10
18/09/10 3
3
Semana
Horas
52
Definição das telas
20/09/10
22/09/10
22/09/10 5
Desenvolvimento da tela
Cadastrar Núcleo Base.
22/09/10
23/09/10
23/09/10
5
5
Implementação das
funcionalidades Cadastrar
Núcleo Base.
23/09/10
25/09/10
25/09/10
7
7
Desenvolvimento da tela
Cadastrar Região.
27/09/10
28/09/10
28/09/10
5
5
Implementação das
funcionalidades Cadastrar
Região.
28/09/10
01/10/10
30/09/10
7
7
Desenvolvimento da tela
Registrar Pagamento.
01/10/10
02/10/10
02/10/10
5
5
Implementação das
funcionalidades Registrar
Pagamento.
02/10/10
05/10/10
05/10/10
7
7
Desenvolvimento da tela
Consultar Núcleo Base.
05/10/10
06/10/10
06/10/10
5
5
Implementação das
funcionalidades Consultar
Núcleo Base.
06/10/10
08/10/10
08/10/10
7
7
Desenvolvimento da tela
Consultar Região.
08/10/10
09/10/10
09/10/10
5
5
Implementação das
funcionalidades Consultar
Região.
11/10/10
13/10/10
13/10/10
7
7
Desenvolvimento da tela
Consultar Pagamento.
13/10/10
14/10/10
14/10/10
5
5
Implementação das
funcionalidades Consultar
Pagamento.
14/10/10/
16/10/10
16/10/10
7
7
Teste de funcionalidades
entre o banco de dados e as 09/08/10
telas.
18/10/10
18/10/10
1
1
Tempo total durante as três semanas
5
84
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 27, o diagrama de sequência Cadastrar Núcleo de Base
mostra os passos que a secretária percorre para Cadastrar Núcleo de Base nosistema.
53
Para que a secretária possa Cadastrar Núcleo de base, primeiro deve-se fazer o login no
sistema. Após se identificar vai abrir a Tela Principal do sistema, faz o acesso a tela de
Cadastro de Núcleo de Base, e insere as informações e salva, logo em seguida é
mostrada uma mensagem “dados inserido com sucesso”.
Figura 27 - Diagrama de Sequência Cadastrar Núcleo Base.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 28, o diagrama de sequência Consultar Núcleo de Base
mostra os passos que a secretária percorre para consultar no sistema. Para que a
secretária possa fazer uma consulta, primeiro deve-se fazer o login no sistema. Após se
identificar vai abrir a Tela Principal do sistema, faz o acesso a tela de Consulta Núcleo de
Base, e insere o nome e consulta as informações, e em seguida são mostrados os dados
do núcleo de base se existir. E em seguida é mostrada uma mensagem “dados alterados
com sucesso”.
54
Figura 28 - Diagrama de Sequência Consultar Núcleo Base.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 29, o diagrama de sequência Alterar Núcleo de Base mostra
os passos que a secretária percorre para alterar no sistema. Para que a secretária possa
fazer uma consulta, primeiro deve-se fazer o login no sistema. Após se identificar vai abrir
a Tela Principal do sistema, faz o acesso a tela de Consulta Núcleo de Base, e insere o
nome e consulta as informações, e em seguida são exibidos os dados do núcleo de base
se existir. Após o usuário fazer a edição no cadastro do Núcleo de Base, e salvar, em
seguida é mostrada uma mensagem “dados alterados com sucesso”.
55
Figura 29 - Diagrama de Sequência Alterar Núcleo de Base.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 30, o diagrama de sequência Cadastrar Região, mostra os
passosque a secretária percorre para cadastrar região no sistema. Para que a secretária
possa cadastrar uma região, primeiro deve-se fazer o login no sistema. Após se identificar
vai abrir a Tela Principal do sistema, faz o acesso a tela de Cadastro de Região, e insere
as informações e salva, logo em seguida é mostrada uma mensagem “dados inserido com
sucesso”.
56
Figura 30 - Diagrama de Sequência Cadastrar Região.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 31, o diagrama de sequência Consultar Região mostra os
passos que a secretária percorre para consultar no sistema. Para que a secretária possa
fazer uma consulta, primeiro deve-se fazer o login no sistema. Após se identificar vai abrir
a Tela Principal do sistema, faz o acesso a tela de consulta região, e insere o nome e
consulta as informações, e em seguida são mostrados os dados da região se existir.
57
Figura 31 - Diagrama de Sequência Consultar Região.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 32, o diagrama de sequência Alterar Região mostra os
passos que a secretária percorre para alterar no sistema. Para que a secretária possa
fazer uma consulta, primeiro deve-se fazer o login no sistema. Após se identificar vai abrir
a Tela Principal do sistema, faz o acesso a tela de Consulta Região, e insere o nome e
consulta as informações, e em seguida são mostrados os dados da região se existir. Após
o usuário fazer a edição no cadastro da região, e salva, em seguida é mostrada uma
mensagem “dados alterados com sucesso”.
58
Figura 32 - Diagrama de Sequência Alterar Região.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 33, o diagrama de sequência Registrar Pagamento mostra
os passos que a secretária percorre para registrar um pagamento no sistema. Para que a
secretária possa registrarum pagamento, primeiro deve-se fazer o login no sistema. Após
se identificar vai abrir a Tela Principal do sistema, faz o acesso a tela de Registro de
Pagamento, e insere as informações e salva, logo em seguida é mostrada uma
mensagem “pagamento registrado com sucesso”.
59
Figura 33 - Diagrama de Sequência Registrar Pagamento.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 34, o diagrama de sequência Consultar Registro
Pagamento mostra os passos que a secretária percorre para consultar um registro no
sistema. Para que a secretária possa fazer uma consultar, primeiro deve-se fazer o login
no sistema. Após se identificar vai abrir a Tela Principal do sistema, faz o acesso a tela de
Consulta Registro de Pagamento, e insere o nome do sócio e consulta as informações, e
em seguida são mostrados os dados de todos os pagamento se existir.
60
Figura 34 - Diagrama de Sequência Consultar Pagamento.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 35, o diagrama de sequência Alterar Registro Pagamento,
mostra os passos que a secretária percorre para alterar um registro no sistema. Para que
a secretária possa fazer uma consulta, primeiro deve-se fazer o login no sistema. Após se
identificar vai abrir a Tela Principal do sistema, faz o acesso a tela de Consultar Registro
Pagamento, e insere o nome do sócio e consulta as informações, e em seguida são
mostrados os dados do registro do pagamento se existir. Após o usuário fazer a edição no
registro de pagamento, e salva, em seguida é mostrada uma mensagem “pagamento
alterado com sucesso”.
61
Figura 35 - Diagrama de Sequência Alterar Pagamento.
Fonte: Arquivo Pessoal, 2013.
3.2.4 Terceiro Sprint backlog (18/10 a 24/11/10)
No Terceiro Sprint foram determinados os seguintes casos de usos: Emitir
Relatórios eImprimir Documentos. Na figura 36 abaixo, são mostrados com mais detalhes
os casos de usos do produto total com prioridade baixas.
62
Figura 36 - Diagrama de Caso de Uso do Terceiro Sprint.
Fonte: Arquivo Pessoal, 2013.
No terceiro sprint do projeto compreende mostrar as tarefas de implementação das
telas Emitir Relatórios e Imprimir Documentos. No quadro abaixo, são mostradas
detalhadamente as atividades que serão desenvolvidas no terceiro sprint.
Quadro 5. Atividades realizadas no terceiro sprint.
Terceiro Sprint
Produto
Desenvolvimento de um sistema para colônia de pescadores z20 – SindPesca.
Caso de Uso
Emitir Relatórios, Imprimir Documentos
Período
Três semanas a partir do dia 18/10/2010
Descrição
Data inicio
Data
limite
Data
entrega
Semana
Horas
Modelagem do sistema
(caso de uso e classe de
domínio).
18/10/10
20/10/10
19/10/10
3
3
Modelagem do sistema
(modelo ER)
20/10/10
22/10/10
21/10/10
3
3
Definição das telas
22/10/10
23/09/10
23/09/10
5
5
Desenvolvimento da tela
emitir relatório sócio sexo
por região.
25/10/10
26/10/10
26/10/10
4
4
Implementação das
funcionalidades emitir
relatório sócio sexo por
26/10/10
28/10/10
28/10/10
6
6
63
região.
Desenvolvimento da tela
emitir relatório sócio sexo
por núcleo base.
28/10/10
29/10/10
29/10/10
4
4
Implementação das
funcionalidades emitir
relatório sócio sexo por
núcleo base.
29/10/10
30/10/10
30/09/10
6
6
Desenvolvimento da tela
emitir relatório sócio por
núcleo base.
01/11/10
02/11/10
02/11/10
4
4
Implementação das
funcionalidades relatório
sócio por núcleo base.
02/11/10
05/11/10
05/11/10
6
6
Desenvolvimento da telaimprimir declaração de
renda.
05/11/10
06/11/10
06/11/10
4
4
Implementação das
funcionalidades imprimir
declaração de renda.
06/11/10
08/11/10
08/11/10
6
6
Desenvolvimento da tela
imprimir declaração
moradia.
08/11/10
09/11/10
09/11/10
4
4
Implementação das
funcionalidades imprimir
declaração moradia.
11/11/10
13/11/10
13/11/10
6
6
Desenvolvimento da tela
imprimir transferência.
13/10/10
15/10/10
15/10/10
4
4
Implementação das
funcionalidades imprimir
transferência.
15/11/10/
17/11/10
17/11/10
6
6
Desenvolvimento da tela
imprimir requerimento.
17/11/10
18/11/10
18/11/10
4
4
Implementação das
funcionalidades imprimir
requerimento.
18/11/10
20/11/10
20/11/10
6
6
Desenvolvimento da tela
22/11/10
23/11/10
23/11/10
4
4
Desenvolvimento da tela
emitir relatório sócio por
núcleo base.
Implementação das
funcionalidades relatório
sócio por núcleo base.
64
imprimir guia da
previdência.
Implementação das
funcionalidades imprimir
guia da previdência.
23/11/10
24/11/10
24/11/10
6
6
Teste de funcionalidades
entre o banco de dados e as 09/08/10
telas.
24/11/10
24/11/10
1
1
Tempo total durante as três semanas
92
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 37, o diagrama de sequência Relatório Sócio Sexo por
Região, mostra os passos que a secretária percorre para fazer uma consulta, e mostrar os
resultados na tela. Para que a secretária possa fazer uma consulta, primeiro deve-se
fazer o login no sistema. Após se identificar vai abrir a Tela Principal do sistema, faz o
acesso a tela de Relatório Sócio Sexo por Região, e informa o sexo e a região do sócio, e
consulta asinformações, e em seguida são mostrados os dados do relatório. Após o
usuário fazer à análise do relatório ele pode fechar ou imprimir a consulta.
Figura 37 - Diagrama de Sequência Relatório Sócio Sexo por Região.
Fonte: Arquivo Pessoal, 2013.
65
Na figura 38 abaixo, o diagrama de sequência Relatório Sócio Sexo por Núcleo de
Base, mostra os passos que a secretária percorre para fazer uma consulta, e mostra os
resultados na tela. Para que a secretária possa fazer uma consulta, primeiro deve-se
fazer o login no sistema. Após se identificar vai abrir a Tela principal do sistema, faz o
acesso a tela de Relatório Sócio Sexo por Núcleo de Base, e informa o sexo e o núcleo
de base do sócio e consulta as informações, e em seguida são mostrados os dados do
relatório. Após o usuário fazer à análise do relatório ele pode fechar ou imprimir à
consulta.
Figura 38 - Diagrama de Sequência Relatório Sócio Sexo por Núcleo de Base.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 39, o diagrama de sequência Relatório Sócio por Região,
mostra os passos que a secretária percorre para fazer uma consulta, e mostra os
resultados na tela. Para que a secretária possa fazer uma consulta, primeiro deve-se
fazer o login no sistema. Após se identificar vai abrir a Tela Principal do sistema, faz o
acesso a tela de Relatório Sócio por Região, e informa a região do sócio e consulta as
informações, e em seguida são mostrados os dados do relatório. Após o usuário fazer à
análise do relatório ele pode fechar ou imprimir à consulta.
66
Figura 39 - Diagrama de Sequência Relatório Sócio por Região.
Fonte: Arquivo Pessoal, 2013.
Em seguida, na figura 40, o diagrama de sequência Relatório Sócio por núcleo de
Base, mostra os passos que a secretária percorre para fazer uma consulta, e mostrar osresultados na tela. Para que a secretária possa fazer uma consulta, primeiro deve-se
fazer o login no sistema. Após se identificar vai abrir a Tela Principal do sistema, faz o
acesso a tela de Relatório Sócio por Núcleo de Base, e informa o núcleo de base do sócio
e consulta as informações, e em seguida são mostrados os dados do relatório. Após o
usuário fazer à análise do relatório ele pode fechar ou imprimir à consulta.
Figura 40 - Diagrama de Sequência Relatório Sócio por Núcleo de Base.
Fonte: Arquivo Pessoal, 2013.
67
Em seguida, na figura 41 abaixo, o diagrama de sequência Relatório Sócio
Adimplente e Inadimplente por Núcleo de Base, mostra os passos que a secretária
percorre para fazer uma consulta, e mostra os resultados na tela. Para que a secretária
possa fazer uma consulta, primeiro deve-se fazer o login no sistema. Após se identificar
vai abrir a Tela Principal do sistema, faz o acesso a tela de Relatório Sócio Adimplente e
Inadimplente, e informa o tipo de busca, e consultar as informações, e em seguida são
exibidos os dados do relatório. Após o usuário fazer à análise do relatório ele pode fechar
ou imprimir à consulta.
Figura 41 - Diagrama de Sequencia Relatório Sócio Adimplente e Inadimplente Núcleo Base.
Fonte: Arquivo Pessoal, 2013.
3.2.6 Modelagem do Sistema
Após fazer todas as análises do levantamento de requisitos durante o processo de
desenvolvimento do SindPesca, foram criadas diversas tabelas, Cadastro Sindicato,
Cadastro Usuário, Cadastro Região, Cadastro Núcleo de Base, Cadastro Sócio, Cadastro
Pagamento e Cadastro de Dependente. Essas tabelas apresentam o fluxo de informação
e seus respectivos relacionamentos entre tabelas no banco de dados. Para melhor
entendimento, a figura 42 abaixo, mostra
modelo conceitual do SindPesca.detalhadamente cada relacionamento
do
68
Figura 42 - Modelo Conceitual SindPesca.
Fonte: Arquivo Pessoal, 2013.
A figura 43 abaixo, é gerada a partir do Modelo Conceitual do SindPesca. Essas
tabelas são geradas para ser implementadas no banco de dados, que são chamadas de
Modelo Lógico. Após fazer toda analise, pode-se observar
geradas e suas chaves primárias e estrangeiras.
Figura 43 - Modelo Lógico SindPesca.
Fonte: Arquivo Pessoal, 2013.
as ligações das tabelas
69
3.3 ENCERRAMENTO
Na fase de encerramento são mostrados os resultados obtidos durante o
desenvolvimento do SindPesca. Nesta fase são concebidas por visão dos Sprints,
demonstração dos resultados obtidos e a entrega do produto para o cliente. Com o
resultado