INSTITUTO FEDERAL DO PARANÁ
LUANA RODRIGUES DE AZEVEDO DE OLIVEIRA
LUCAS LEITE RONDINA
RIC: CONTROLE INFORMATIZADO DE REQUERIMENTOS
PARANAGUÁ
2011
2
LUANA RODRIGUES DE AZEVEDO DE OLIVEIRA
LUCAS LEITE RONDINA
RIC: CONTROLE INFORMATIZADO DE REQUERIMENTOS
Trabalho de Conclusão de Curso, recurso de
avaliação para a aprovação no Curso Técnico EMI
de Informática no Instituto Federal do Paraná –
Campus Paranaguá.
Orientador: Professor Gil Eduardo de Andrade.
PARANAGUÁ
2011
3
AGRADECIMENTOS
À Deus pela oportunidade de concretização de mais uma etapa.
Ao
orientador,
professor
Mestre
Gil
Eduardo
de
Andrade
pelo
comprometimento demonstrado durante a realização do trabalho.
Aos colegas de classe que juntamente com os nossos professores
contribuíram ao longo desta jornada na construção de nossos conhecimentos,
insignes a finalização deste trabalho.
4
“Se você está procurando uma grande oportunidade,
descubra um grande problema.” (Martinho Lutero)
“Ninguém pode ser perfeito. Mas todos podem ser
melhores” (Sponge Bob SquarePants).
5
RESUMO
A informatização de processos administrativos e gerenciais vem sendo
crucial para o desenvolvimento de empresas públicas e privadas. Este trabalho
apresenta o projeto e a implementação de um sistema informatizado para a
Capitania dos Portos do Paraná. Atualmente a Capitania utiliza planilhas e controles
manuais para gerenciar muitas de suas atividades. Após um longo processo de
imersão e reconhecimento das necessidades da empresa, projetou-se e
implementou-se um sistema de informatização. Para o desenvolvimento do projeto
foram adotadas metodologias consolidadas na literatura, tais como: análise de
requisitos, diagramas de sequencia, classe e modelagem relacional de dados. O
sistema foi desenvolvido sobre o paradigma de programação orientada a objetos,
fazendo uso da linguagem Java. A Capitania tem demostrado grande satisfação em
relação aos resultados que a solução vem oferecendo, principalmente no que se
refere a agilidade no atendimento ao público, facilidade no resgate de informações e
controle dos processos administrativos.
Palavras-chave: requerimentos, Sistema informatizado, Capitania.
6
ABSTRACT
The automation of administrative processes and management has been
crucial to the development of public and private companies. This paper presents the
design and implementation of a computerized system for the Port Authority of
Paraná. Currently Captaincy uses spreadsheets and manual controls to manage
many of their activities. After a long process of immersion and recognition of
business needs, we design and implemented a computerized system. For the
development of the project were consolidated methodologies adopted in the
literature, such as requirements analysis, sequence and class diagrams and
relational data modeling. The system was developed on the programming paradigm
called object oriented, making use of the Java plataform. The captaincy has
demonstrated great satisfaction with the results that the solution has been offering,
especially when it comes to agility in customer service, ease of retrieval of
information and control of administrative processes.
Keywords: applications, computerized system, Captaincy
7
LISTA DE FIGURAS
Figura 1. Diagrama de Caso de Uso - Simulação de saque ..................................... 23
Figura 2. Exemplo Modelo Entidade Relacionamento ............................................... 26
Figura 3. Exemplo Modelo Relacional ....................................................................... 27
Figura 4. Janela J02_MENU do Software Desktop RIC. .......................................... 34
Figura 5. Janela J01_LOGIN Software RIC............................................................... 35
Figura 6. Quadro comparativo da janela JA03_CADASTROS de Software Desktop
RIC. ........................................................................................................................... 35
Figura 7. Sequência de imagens da J07_CADASTRO_DE_FUNCIONARIO do
Software desktop RIC. .............................................................................................. 36
Figura 8. Janela J05_BUSCA Software desktop RIC. ............................................... 36
Figura 9. Janela J03_CADASTRO_REQUERIMENTO_01 Software desktop RIC. . 37
Figura 10. Janela J03_CADASTRO_REQUERIMENTO_02 Software desktop RIC. 38
Figura 11. Janela J03_CADASTRO_REQUERIMENTO_03 Software desktop RIC.38
Figura 12.Janela J03_CADASTRO_REQUERIMENTO_04 Software desktop RIC. 39
Figura 13. Janela J06_ACOMPANHAMENTO Software desktop RIC. ..................... 39
8
LISTA DE ABREVIATURAS E SIGLAS
BD
– Banco de Dados;
CPPR – Capitania dos Portos do Paraná;
DCU – Diagrama de Caso de Uso;
GAP – Grupo de Atendimento ao Público;
IFPR – Instituto Federal do Paraná;
SQL – Structured Query Language;
UML – Unified Modeling Language;
9
LISTA DE APÊNDICES
A – Diagrama de Casos de Uso;
B – Diagrama de Classes;
C – Modelo Entidade-Relacionamento;
D – Modelo Relacional;
E- Documento emitido pela CPPR para definir os objetivos da parceria com o
IFPR.
10
SUMÁRIO
1
INTRODUÇÃO ............................................................................................. 12
1.1
MOTIVAÇÃO ................................................................................................ 12
1.2
DESAFIOS ................................................................................................... 13
1.3
OBJETIVOS ................................................................................................. 13
1.4
OBJETIVOS ESPECÍFICOS ........................................................................ 13
2
FUNDAMENTAÇÃO TEÓRICA ................................................................... 14
2.1
ENGENHARIA DO SOFTWARE .................................................................. 14
2.2
ANÁLISE DE SISTEMAS ............................................................................. 15
2.2.1
Identificação de Necessidade ....................................................................... 15
2.2.2
Estudo de Viabilidade ................................................................................... 16
2.2.3
Análise Econômica ....................................................................................... 16
2.2.4
Análise Técnica ............................................................................................ 17
2.3
ADMINISTRAÇÃO DE PROJETOS.............................................................. 17
2.4
RECURSOS DE SOFTWARE ...................................................................... 17
2.5
PLANEJAMENTO DE PROJETOS............................................................... 18
2.6
ANÁLISE DE RISCOS .................................................................................. 19
2.6.1
Identificação dos Riscos ................................................................................ 19
2.6.2
Projeção dos Riscos ..................................................................................... 19
2.6.3
Avaliação dos Riscos.................................................................................... 20
2.7
ANÁLISE DE REQUISITOS ......................................................................... 20
2.8
LINGUAGEM JAVA ...................................................................................... 21
2.9
LINGUAGEM DE MODELAGEM UNIFICADA (UML) ................................... 21
2.9.1
Diagramas UML ............................................................................................ 22
2.9.1.1 Diagrama de Caso de Uso ............................................................................ 22
2.9.1.2 Diagrama de Classes .................................................................................... 23
11
2.10
MODELAGEM DE BANCO DE DADOS ....................................................... 25
2.10.1 Modelo Entidade – Relacionamento ............................................................. 25
2.10.2 Modelo Relacional ........................................................................................ 26
2.11
LINGUAGEM SQL ........................................................................................ 27
3
METODOLOGIA........................................................................................... 28
4
CONCLUSÃO E RESULTADOS.................................................................. 34
APÊNDICES...............................................................................................................41
12
1
INTRODUÇÃO
Paranaguá, cidade com o segundo maior porto do Brasil se encontra
localizada no estado do Paraná. Atualmente conta com aproximadamente 25 mil
embarcações ativas, navegando dentro do território do município e arredores,
gerando uma grande movimentação no setor marítimo desta região.
Essa movimentação esteve presente desde os primórdios da cidade,
apresentando a necessidade da criação de um órgão que controlasse e organizasse
tais atividades náuticas. A partir dessa necessidade, surge a Capitania dos Portos
do Paraná, pelo decreto Imperial n° 1.241 de outubro de 1853.
A Capitania dos Portos do Paraná (CPPR) atua contribuindo para a
orientação, coordenação e controle das atividades relativas à Marinha Mercante e
organizações correlatas, no que se refere a: segurança da navegação, defesa
nacional, defesa da vida humana no mar e prevenção da poluição hídrica.
Envolvendo um grande número de pessoas para atuar nestas atividades.
A CPPR tem como destaque o Grupo de Atendimento ao Público (GAP), que
oferta a interação Sociedade-Marinha utilizando de inúmeros serviços, tais quais:
Habilitações de Amadores, Serviço de Tráfego Aquaviário e Inspeções Navais;
Todas estas movimentações são controladas com base em requerimentos físicos,
preenchidos manualmente pelos requerentes em uma folha de papel impressa.
A fim de abandonar este processo arcaico de manipulação de requerimentos
a CPPR propôs o desenvolvimento de um projeto educacional, em conjunto com o
Instituto Federal do Paraná, visando a construção de um sistema informatizado para
automatizar parte deste processo, além de servir como um auxiliador na tomada de
decisões.
1.1
MOTIVAÇÃO
A maior motivação para o desenvolvimento deste projeto é saber que o
mesmo será implantado para melhoria da CPPR, existindo ainda, a possibilidade de
ser reconhecido não só no estado do Paraná, mas também em todo Brasil.
13
1.2
DESAFIOS
Os desafios encontrados no desenvolvimento deste projeto, além dos prazos
curtos, foram: Construção de um software que garanta a praticidade de uso além de
atender as necessidades e requisitos do usuário; capacitação e adaptação dos
futuros usuários.
1.3
OBJETIVOS
Este projeto tem como objetivo melhorar o controle da CPPR sobre seus
requerimentos, agilizar o processo de preenchimento dos mesmos, diminuir seu
tempo de trâmite e reduzir a frequência erros.
1.4
OBJETIVOS ESPECÍFICOS
“Controlar o andamento dos requerimentos a fim de oferecer celeridade aos
processos, assim como informações estatísticas para subsidiar as decisões do
comando”, Trecho retirado do Apêndice E (Documento extraoficial da CPPR).
14
2
2.1
FUNDAMENTAÇÃO TEÓRICA
ENGENHARIA DO SOFTWARE
Engenharia do software é uma área de conhecimento da computação
voltada para a especificação, desenvolvimento e manutenção de sistemas. Segundo
Pressman R., ela abrange um conjunto de três elementos fundamentais métodos,
ferramentas e procedimentos - que possibilita ao gerente o controle de
desenvolvimento do software e oferece ao profissional uma base para a construção
de software de alta qualidade produtivamente.
Os métodos de engenharia de software proporcionam os detalhes para
construir o software.
Envolvem um amplo conjunto de tarefas que incluem:
planejamento e estimativas do projeto, análise de requisitos de software e de
sistemas, projeto da estrutura de dados, arquitetura de programa e algoritmo de
processamento, codificação, teste e manutenção.
As ferramentas da engenharia de software de computador são as
tecnologias usadas para auxiliar no desenvolvimento do sistema. Proporcionam
apoio automatizado ou semi-automatizado aos métodos.
Os procedimentos da engenharia do software constituem um elo que
mantém juntos os métodos e as ferramentas. Os procedimentos que definem a
sequência em que os métodos serão aplicados, os produtos (deliverables) que se
exige que sejam entregues (documentos, relatórios, formulários etc.) e os controles
que ajudam assegurar a qualidade e a coordenar as mudanças, possibilitando aos
gerentes de software avaliar o progresso.
A engenharia do software pode utilizar um paradigma de ciclo de vida
clássico, chamado de modelo cascata. Este paradigma do ciclo de vida requer uma
abordagem sistemática, sequencial ao desenvolvimento do software, que se inicia
pelo nível do sistema, depois vem análise, projeto, codificação, teste e manutenção.
Modelado em função do ciclo da engenharia convencional, o paradigma do ciclo de
vida abrange as seguintes atividades (PRESSMAN, 1995):
Análise e engenharia de sistemas, que envolve a coleta de requisitos que
serão utilizados para a construção do software em nível do sistema, com uma
pequena quantidade de projeto e análise de alto nível.
15
Análise de requisitos de software, onde o processo de coleta dos requisitos é
intensificado e concentrado especificamente no software. O engenheiro do software
deve compreender o domínio da informação para o software bem como o
desempenho e interface exigidos.
Projeto, processo de múltiplos passos que se concentra em quatro atributos
distintos do programa: estrutura de dados, arquitetura de software, detalhes
procedimentais e caracterização de interface. É a representação do software que
pode ser avaliada quanto à qualidade antes que a codificação se inicie.
Codificação é a etapa em que se executa o que foi detalhado no projeto
numa forma legível por máquina.
Manutenção, que ocorre após a implantação do software, no qual poderá
sofrer mudanças, devido aos erros encontrados ou porque o cliente exige
acréscimos funcionais ou de desempenho.
2.2
ANÁLISE DE SISTEMAS
É uma atividade em que se concentra em todos os elementos do sistema. É
realizada com os objetivos: de identificar a necessidade do usuário; avaliar a
concepção do sistema quanto à sua possível execução; executar a análise
econômica e técnica; e estabelecer as restrições de prazo e custo quanto a
construção do software.
2.2.1 Identificação de Necessidade
O analista se reúne com o cliente e com o usuário final (caso não seja o
cliente). Nesta etapa o analista ajuda o cliente a definir as metas do sistema: as
informações a serem produzidas e as que devem ser fornecidas, as funções e
desempenho exigidos. Durante esse processo avaliam-se suas necessidades e seus
desejos quanto ao sistema a ser desenvolvido. Essas informações são especificadas
num Documento Conceitual do Sistema. Este documento ás vezes é preparado pelo
próprio cliente antes da reunião com o analista.
16
2.2.2 Estudo de Viabilidade
É de suma importância à realização de tal estudo, pois indica a viabilidade
de determinado projeto antes do inicio de sua execução, evitando gastos temporais
de esforços desnecessários.
Conforme Pressman (1995), a Viabilidade e a Análise de riscos estão
relacionadas. Pois, caso o risco do projeto for grande a viabilidade de ser produzir
um software de qualidade é reduzida. Durante essa etapa concentra-se atenção em
quatro áreas de interesses fundamentais:
Viabilidade econômica: Uma avaliação do custo de desenvolvimento do
sistema e dos benefícios.
Viabilidade técnica: Um estudo da função, do desempenho e das restrições
que possam afetar a capacidade de se conseguir um sistema aceitável. Nela
considera-se o risco do desenvolvimento, disponibilidade de recursos e tecnologia.
Viabilidade legal: Uma determinação de qualquer infração, violação ou
responsabilidade legal que possa resultar do desenvolvimento do sistema.
Alternativa:
Uma
avaliação
das
alternativas
existentes
para
o
desenvolvimento do sistema.
Caso a viabilidade econômica seja óbvia, os riscos técnicos sejam baixos,
nenhum problema jurídico seja esperado e não exista alternativa razoável não, há
razão de ser feito o estudo de viabilidade. Agora se faltar alguma dessas condições
o estudo deverá ser realizado.
2.2.3 Análise Econômica
É uma avaliação de justificativa econômica para um projeto de sistema
baseado em computador. Esta análise delineia os custos para o desenvolvimento do
projeto e compara-os com os benefícios alcançáveis e inalcançáveis de um sistema.
A análise varia de acordo com as características do sistema a ser
desenvolvido, pelo tamanho relativo do projeto e pelo retorno sobre o investimento
esperado. (PRESSMAN, 1995)
17
2.2.4 Análise Técnica
Durante a Análise técnica, de acordo com Pressman (1995) o analista avalia
os méritos técnicos da criação do sistema e, ao mesmo tempo, coleta informações
adicionais sobre desempenho, confiabilidade, manutenbilidade e capacidade da
reutilização.
A análise técnica inicia-se com uma avaliação da viabilidade técnica do
sistema proposto. A modelagem técnica ou física do sistema é importante ser criado
para servir de base como observação do mundo real ou uma aproximação baseada
nas metas do sistema. Pois o analista avalia o modelo e compara-o com o mundo
real ou com o comportamento esperado do sistema, conseguindo esclarecer a
viabilidade técnica do sistema proposto.
2.3
ADMINISTRAÇÃO DE PROJETOS
É o processo em que se realizam as estimativas. Que pode ser feita
manualmente ou utilizar técnicas para estimar o tempo e o esforço gasto para o
desenvolvimento do sistema. São as estimativas que lançam as bases para outras
atividades de planejamento de projetos (PRESSMAN, 1995).
O objetivo do planejamento de projetos de software é fornecer uma estrutura
que possibilite ao gerente fazer estimativas razoáveis de recursos, custos e prazos e
é atingindo por meio de um processo de descoberta de informações que leve a
estimativas razoáveis.
2.4
RECURSOS DE SOFTWARE
São ferramentas utilizadas para o desenvolvimento de novas ferramentas
(softwares). As principais categorias de ferramentas segundo Pressman (1995) são:
Ferramentas de Planejamento de Sistemas de Informações: ajudam os
desenvolvedores de software a criar sistemas de informações que encaminham
dados àqueles que precisam da informação. Na análise final, a transferência de
dados é melhorada e as tomadas de decisão são agilizadas.
Ferramentas de Gerenciamento de Projetos: o gerente de projetos pode
gerar úteis estimativas do esforço, custo e duração de um projeto de software;
18
planejar uma programação de atividades de projeto; e monitorar projetos em base
contínua.
Ferramentas de Apoio: são as ferramentas de produção de documentos,
software de sistemas em rede, banco de dados, usadas para controlar e gerenciar a
informação que é criada à medida que o software é desenvolvido.
Ferramentas de Análise e Projeto: possibilitam que um engenheiro de
software crie um modelo do sistema a ser construído. Estas ferramentas fornecem
ao engenheiro de software esclarecimentos e ajuda para eliminar erros antes que
estes se propaguem no programa.
Ferramentas de Programação: utilitários básicos, editores, compiladores e
depuradores.
Ferramentas de
programação
orientadas
a objeto,
sistemas
avançados de consulta de banco de dados etc.
2.5
PLANEJAMENTO DE PROJETOS
No planejamento do software é feito um cronograma determinado
casualmente. Os riscos são considerados antes que eles se transformem em
problemas completos. O engenheiro de Software deve despender de tempo neste
planejamento para evitar ao máximo o surgimento de erros durante a construção do
sistema.
Após compreender os requisitos funcionais do software, características de
desempenho, restrições relativas ao sistema e preocupações de confiabilidade o
planejador de projetos de software aplica técnicas e ferramentas para deduzir a
estimativa de custos, recursos e tempo para o desenvolvimento do sistema. A
estimativa oferece ao planejador as informações necessárias para concluir as
atividades de planejamento do projeto.
No planejamento do software é determinado um cronograma para o projeto
de desenvolvimento deste. Pode ser feito de duas maneiras. Um cronograma pode
ter uma data final para entrega de um sistema baseado em computador já
estabelecido pelo cliente onde a organização de software é distribuída nesse espaço
de tempo previsto. Outra maneira, de se determinar um cronograma para projetos
de desenvolvimento é quando uma data final seja estabelecida pela organização de
engenharia de software. No qual os limites cronológicos aproximados tenham sido já
discutidos. A última é a melhor maneira, pois o esforço é distribuído para que se
19
possa tirar melhor proveito dos recursos e a data final é definida após cuidadosa
análise.
2.6
ANÁLISE DE RISCOS
Quando o risco é considerado na engenharia de software, Segundo
Pressman (2009), preocupa-se com: O futuro - os riscos que poderiam fazer com
que o projeto saísse torto; A mudança – dos requisitos do cliente, das tecnologias de
desenvolvimento, dos computadores de destino e em todas as demais entidades
ligadas ao projeto analisando se afetará o sucesso global ou o cumprimento do
cronograma. Por fim com As escolhas – dos métodos e ferramentas que serão
usadas e das pessoas envolvidas no projeto.
A análise de riscos é composta por quatro atividades distintas:
2.6.1 Identificação dos Riscos
Ao ser identificado o risco é possível dividir em:

Os riscos de projetos: identificam problemas orçamentários, de
cronograma, de pessoal (composição de pessoal e organização), de
recursos, de clientes e de requisitos e o impacto dos mesmos sobre o
projeto de software.

Os riscos técnicos: identificam potencias problemas de projeto,
implementação, interface, verificação e manutenção

Os riscos dos negócios: são insidiosos, porque podem destruir os
resultados, até mesmo os melhores projetos de software. Dentre os
riscos de maior destaque estão: construir um excelente produto que
ninguém realmente quer (risco de mercado) e construir um produto
que não mais se encaixe na estratégia global de produtos da empresa.
2.6.2 Projeção dos Riscos
A Projeção dos riscos, também chamada de estimativa de riscos, tenta
classificar de duas maneiras – a probabilidade de o risco seja real e as
consequências dos problemas associados as risco, caso ele ocorra.
20
2.6.3
Avaliação dos Riscos
A avaliação dos riscos é examinada mais detalhadamente a precisão das
estimativas que foram feitas durante a projeção dos riscos, tentando determinar uma
ordem de prioridade para os riscos que foram descobertos e começar a pensar em
maneiras de controlar e/ou evitar riscos que tem a probabilidade de ocorrer.
2.7
ANÁLISE DE REQUISITOS
É uma tarefa da engenharia do software que efetua a ligação entre a nível
de sistema e de projeto. Ela possibilita que o engenheiro de sistemas especifique a
função e o desempenho do software, indique a interface do software com outros
elementos do sistema e estabeleça quais são as restrições de projeto que o software
deve enfrentar.
A análise de requisitos permite que o engenheiro de software aprimore a
alocação de software e construa modelos do processo, dos dados e dos domínios
comportamentais que serão tratados pelo software. A especificação de requisitos
proporciona ao desenvolvedor e ao cliente os critérios para avaliar a qualidade logo
que o software for construído.
Para realizar esta análise se estuda a Especificação do Sistema (caso exista
um) e um Plano de Projeto de Software.
De acordo com Pressman (2009), a
análise de requisitos do software pode ser dividida em cinco áreas de esforço:
Reconhecimento do problema. Nesta etapa é importante revisar o escopo do
software e estabelecer a comunicação com a atividade de análise de forma que o
reconhecimento do problema seja garantido.
Avaliação e síntese. É a área de maior esforço de análise. O analista deve
avaliar o fluxo e o conteúdo de informações, definir e elaborar todas as funções do
software, entender o seu comportamento no contexto dos eventos que afetam o
sistema e descobrir restrições de projeto.
Modelagem. A modelagem do sistema é feito para compreender melhor o
fluxo de dados e de controle, o processo funcional e a operação comportamental.
Este modelo serve como um fundamento para o projeto e como base para a criação
de sua especificação.
21
Especificação. É a especificação de informações básicas, funções,
desempenho, comportamento e interfaces entre o desenvolvedor e o cliente para o
desenvolvimento do sistema.
Revisão. É a revisão da especificação dos requisitos que quase sempre
resulta em modificações na função, desempenho, representações da informação,
restrições.
2.8
LINGUAGEM JAVA
Java é uma linguagem de programação usada para o desenvolvimento de
software. É uma linguagem orientada a objetos que utiliza uma metodologia que
está se tornando cada vez mais útil no mundo do designer de software. Além disso,
é uma linguagem multiplataforma, ou seja, seus programas podem ser criados para
ser executado independente do sistema operacional utilizado. Os programas Java
utilizam uma máquina virtual, que possui o objetivo de converter os códigos précompilados (bytecodes) em comandos que um sistema operacional possa
manipular.
A Linguagem Java pode ser executada em dispositivos como televisões,
relógios e telefones celulares. É usada para uma variedade de aplicações,
oferecendo suporte a interfaces gráficas com o usuário, interligação em rede,
conectividade de banco de dados entre outros.
2.9
LINGUAGEM DE MODELAGEM UNIFICADA (UML)
Unified Modeling Language (ou UML) é uma linguagem visual de
modelagem que visa auxiliar o desenvolvedor de um sistema a visualizar o seu
provável produto final, idealizado em forma de modelos gráficos, ou diagramas,
respeitando um protocolo específico. Ou seja, ela não dita como será projetado o
sistema, e sim auxilia no mesmo.
Vale ressaltar que o objetivo do UML não é a documentação de um projeto,
mas sim a padronização do método de construção.
22
2.9.1
Diagramas UML
O uso da UML em um projeto de desenvolvimento de software envolve a
criação de diversos documentos, podendo ser gráficos ou textuais, compondo em
conjunto uma representação visual do sistema a ser projetado. Esses documentos
são denominados artefatos de software, ou apenas artefatos. Os artefatos gráficos
do UML são compostos pelos diagramas.
Dentre os diagramas essenciais para a construção de um sistema dentro do
UML estão o Diagrama de Casos de Uso e o Diagrama de Classes.
2.9.1.1 Diagrama de Caso de Uso
“O diagrama de caso de uso (DCU) corresponde a uma visão externa do
sistema e representa graficamente os atores, casos de uso e relacionamentos entre
esses elementos.” BEZERRA (2006, página 57 ). Tendo como objetivo representar
os fatores externos que interagem com o sistema, mostrando de maneira gráfica
esta interação interna-externa.
Os atores do diagrama são representados por bonecos com sua
nomenclatura embaixo, são eles que representam os fatores externos que interagem
com o sistema, podendo ser humanos, hardwares ou até mesmo outros sistemas.
Os casos de uso são representados dentro do diagrama na forma de eclipse,
que representam as funcionalidades do sistema sendo diagramado, levando seu
nome abaixo da eclipse ou no interior da mesma.
As relações representam interações, podendo ocorrer entre atores e casos
de uso ou entre os próprios casos de uso, porém nunca entre atores. No caso de
interação entre atores e casos de uso as relações são representadas por segmentos
de retas que ligam ambas as figuras, tanto atores como casos de uso, podem
possuir diversas relações\interações. As relações entre casos de uso são separadas
em duas variantes, relacionamentos de extensão e relacionamentos de inclusão.
O relacionamento de extensão indica que um caso de uso possui uma
relação de sequência não obrigatória com outro caso de uso, essa relação é
representada por uma seta direcionada com nomenclatura “<<extend>>” localizada
abaixo da do segmento, neste caso uma função do sistema pode ou não ser
sequenciada por outra função.
23
O relacionamento incluir indica uma obrigatoriedade da relação, ou seja, um
caso de uso, obrigatoriamente, deve ter continuação por outro caso de uso indicado
pela relação. A representação desta variante de relação é uma seta direcionada com
a nomenclatura “<<includ>>” abaixo do segmento. Em ambos os casos de relação
entre casos de uso, a seta indica a ordem de segmento, indicando qual função deve
dar continuidade à sequência. (BEZERRA, E. 2006)
Temos na figura 1 um exemplo de relações obrigatórias ou opcionais através
de um simples diagrama demonstrando a sequência de um saque, em que se
solicita um saque e, obrigatoriamente, deve se expelir as cédulas de dinheiro e pode
ou não emitir o extrato do cliente.
Figura 1. Diagrama de Caso de Uso - Simulação de saque
2.9.1.2 Diagrama de Classes
Analisando o diagrama de casos de uso de forma geral podemos notar sua
contribuição para a compreensão das relações externas de um sistema. Podemos
obter igualmente uma visão ampla do sistema com o diagrama de classes, porém
das relações internas do sistema. Enquanto o diagrama de caso de uso demonstra
personagens interagindo externamente sendo retribuídos com os resultados
produzidos pelo sistema, o diagrama de classes demonstra a interação entre os
24
objetos internos do sistema, cooperando para formar os resultados que serão
externados.
Dentre todos os diagramas do UML, o diagrama de classes é o que
apresenta mais elementos para sua construção e detalhamento. A partir das Classes
e Associações temos diversas especificações que compõe o diagrama como:

Classes:
São abstrações de objetos semelhantes, ditando suas características.
Formulando uma analogia, classes seriam formas de bolo, e os bolos,
resultados do padrão estabelecido pelas fôrmas seriam os objetos. No
diagrama, as classes são representadas graficamente por retângulos com
três subdivisões, sendo cada uma, respectivamente, preenchidas por
Nomenclatura da Classe, Atributos da Classe e Operações da Classe.

Nomenclatura da Classe
É basicamente o título que a classe carrega para facilitar o
reconhecimento desta. Sempre é recomendável que seja estabelecido um
padrão para criação da nomenclatura, pois isso contribui para uma maior
organização do diagrama.

Atributo da Classe
Uma classe pode possuir vários atributos, pois são eles que
determinam as características do objeto, retomando a analogia da fôrma de
bolo, alguns dos atributos possíveis do objeto “bolo” seriam, formato, altura,
etc. Os atributos podem assumir diferentes valores. O atributo ou a lista
deles ficam no interior da segunda divisão gráfica da classe.

Operação da Classe
A operação representa o comportamento daquele objeto e fica
localizada na terceira subdivisão da classe.

Associação
A associação é o elemento do diagrama que representa a relação, ou
comunicação, entre objetos durante a execução do sistema. Ela é
representada graficamente por um segmento de reta que liga as classes que
estão se comunicando. Embora a representação gráfica se dê entre as
classes, deve-se saber que a real comunicação ocorre entre os objetos
formados a partir das classes associadas. Isso significa que uma associação
25
entre duas classes pode representar a comunicação de dois ou mais
objetos. Para representar o limite máximo e mínimo de objetos que são
ligados usa-se a multiplicidade, que é representada nas extremidades das
ligações.
Um pouco diferente do Diagrama de Caso de Uso podemos reconhecer a
Participação, ou seja, a obrigatoriedade ou não de ocorrer determinado
relacionamento, observando sua multiplicidade. Se o limite mínimo de uma das
relações for um, temos a certeza que aquela associação é obrigatória, caso contrário
torna-se opcional.
2.10 MODELAGEM DE BANCO DE DADOS
Durante o desenvolvimento de um sistema de computador que tenha
participação de um BD (Banco de Dados) dedica-se uma grande quantidade de
tempo à sua construção, porém, antes de iniciarmos esta etapa temos de reservar
tempo suficiente para seu planejamento e estruturação. Para isso usamos a
Modelagem de Dados.
A modelagem de dados, além de auxiliar no planejamento do BD, contribui
com a previsão de erros, reduzindo e facilitando futuras manutenções. Também
possui serventia como conversora de ideias conceituais para formas mais
compatíveis com os termos computacionais para que possam ser aplicados na
construção do BD.
Para alcançar estes fins a Modelagem de Dados usa modelos como o
Modelo Entidade-Relacionamento e o Modelo Relacional. (CHEN, P. 1990).
2.10.1 Modelo Entidade – Relacionamento
O modelo de entidade relacionamento é o primeiro passo para a construção
do BD. Ele visa construir um modelo lógico que auxilia o desenvolvedor do banco e
de demais diagramas mais complexos a visualizar de maneira geral o banco a ser
desenvolvido. Esse modelo visa transformar objetos da vida real em entidades
lógicas, descritas através de atributos e possuindo relacionamentos entre si. Usando
este modelo geramos o diagrama visual do BD, tendo graficamente retângulos para
26
representar entidades, traços para representar relacionamentos e pequenos círculos
conectados às entidades representando os atributos pertencentes a elas. Veja um
exemplo na figura 2.
Figura 2. Exemplo Modelo Entidade Relacionamento
2.10.2 Modelo Relacional
Pode-se dizer que o modelo relacional é uma representação mais complexa
do modelo Entidade-Relacionamento, que utiliza tabelas para representar tanto
entidades, como relacionamentos. Este modelo tem como objetivo representar de
forma mais organizada e visual o tratamento dos dados pelo BD, usando diversas
colunas, cada qual com nomenclatura única.
Na figura 3 encontra-se um exemplo deste modelo gráfico.
27
Figura 3. Exemplo Modelo Relacional
2.11 LINGUAGEM SQL
Atualmente sente-se a necessidade de estruturar tudo que está relacionado
com o projeto a ser desenvolvido, incluindo o BD. Ele pode se tornar muito mais que
uma central de acesso aos dados, pode-se estruturá-lo garantindo eficiência nesta
tarefa, a segurança no armazenamento e a interação inteligente entre os dados. É
com esses conceitos que se baseia o SQL (Linguagem de Consulta Estruturada),
uma das linguagens mais comuns nesta área. Ela está presente na criação lógica do
banco e permite, além da visualização dos dados armazenados, o total controle
sobre eles, tanto em edição, quanto em relacionamentos entre os mesmos. (CHEN,
P. 1990)
28
3
METODOLOGIA
Durante o processo de desenvolvimento do sistema foram realizadas
algumas etapas para alcançar os objetivos propostos. A primeira etapa foi de
Identificação das necessidades da CPPR. No qual foi colocada a necessidade de um
sistema que controlasse entrada e saída de requerimentos, tão quanto registrasse
esta movimentação.
Após esta explanação deu-se início a análise de requisitos. Esta análise
começou a ser feita na metade do mês abril de 2011 juntamente com a CPPR. No
qual foram definidas as funcionalidades e especificações do sistema que
propuseram. Os requisitos foram:

Acesso Restrito
Cada funcionário deve ter um código e uma senha para ter acesso ao
sistema.

Nível de acesso
Cada funcionário deve ter um nível de acesso a certas informações do
banco de dados. Para melhor segurança destes.

Buscas Múltiplas
O sistema deve ter uma janela de busca, no qual deve fornecer todas as
informações existentes referente ao que foi digitado.

Segurança
O sistema deve prover segurança de informações contidas no Banco de
Dados.

Manutenção de Funcionários
O sistema deve cadastrar, alterar e excluir informações dos funcionários no
banco de dados somente os que tiverem permissão para isso.

Manutenção de Processos
O sistema deve cadastrar, alterar e excluir as informações dos processos
no banco de dados.

Manutenção de Documentos
O sistema deve cadastrar, alterar e excluir as informações dos documentos
no Banco de Dados.
29

Manutenção de Funções
O sistema deve cadastrar, alterar e excluir as informações de funções que
os funcionários exercem na CPPR.

Manutenção de Requerentes
O sistema deve cadastrar, alterar e excluir as informações dos requerentes
(pessoas) que deram entrada no requerimento.

Manutenção de Embarcações
O sistema deve cadastrar, alterar e excluir as informações das
embarcações no Banco de Dados.

Manutenção de Amadores
O sistema deve cadastrar, alterar e excluir as informações dos amadores
no banco de dados.

Salvar Requerimentos
O sistema deve salvar no banco de dados todos os requerimentos feitos.

Registrar trâmite
O sistema deve registrar o destino, a situação e o caminho que o
requerimento percorreu.

Imprimir requerimentos
O sistema deve imprimir o requerimento com todas as informações
preenchidas nele após sua realização.

Gerar estatísticas
O sistema deve gerar estatísticas quanto à quantidade de serviços e
requerimentos feitos por dia, mês ou ano.
Normalmente em um projeto o próximo passo seria o desenvolvimento do
estudo de viabilidade. Porém, analisando os requisitos para construção deste,
descartamos sua necessidade. O motivo é que as condições nas quais o projeto
surgiu ofereceram todos os elementos para tornar possível a construção e
implantação do sistema na CPPR. Tendo em vista que os recursos e ferramentas
utilizadas não geram custos que ofereçam riscos econômicos, os futuros operadores
já estão habituados com o manuseio de sistemas computacional semelhantes e as
funcionalidades não interferem no código de segurança do cliente nem infringe as
leis vigentes.
30
Na análise Econômica foi possível perceber que não haverá problemas de
gastos grandes com recursos que pudessem ser utilizados na construção do
sistema. Pois os recursos de softwares utilizados não produziram custos. Foi
utilizado como ferramenta de apoio o Firebird que é um gerenciador de Banco de
Dados, porque não é pago e de fácil uso para um sistema como este. Também foi
usado ferramentas de Análise e projetos para realizar a parte de modelagem do
sistema. Dentre elas foi o Astah que possibilitou fazer os diagramas de Caso de Uso
e os de Classes. As ferramentas usadas para modelar o Banco de Dados do
software foram DBDesigner e BrModelo. Com estas duas ferramentas foi possível
realizar o Modelo Entidade-Relacionamento e o Modelo-Relacional. Por último, foi
usado a ferramenta de programação NetBeans como compilador.
Após o cumprimento destas etapas iniciou-se a fase administrativa do
projeto. Nesta fase foram realizadas estimativas de tempo, custos e recurso. A
estimativa de tempo foi determinada junto a CPPR, no qual seria gasto 4 horas por
dia durante nove meses. Quanto aos custos foi decidido entre os desenvolvedores e
o cliente. Já os recursos utilizados foram citados acima.
Depois se iniciou um planejamento do projeto no qual foi determinado um
cronograma para entrega deste software com a quantidade de dias e horas
necessárias para o desenvolvimento do sistema. Nesta etapa também foi pensado
nos riscos que podem ocorrer. Por isso realizou-se a Análise de riscos.
Durante a execução da Análise de riscos não foram levantados riscos
significativos ao projeto. Dentre os poucos riscos estava presente a não adaptação
dos usuários ao novo sistema, porém após uma breve observação do local onde o
sistema seria implantado verificou-se que os usuários já estão habituados com a
operação de recursos semelhantes. Para confirmar os resultados de nossas
observações foi realizada uma reunião informal com os futuros operadores do
programa, desta reunião teve a aprovação destes indivíduos.
A etapa seguinte foi de análise técnica no qual se realizou a modelagem de
como funcionaria o sistema. Esta modelagem feita chama-se Diagrama de Caso de
uso (Apêndice A) que foi feita descrevendo todas as funções e pessoas relacionadas
com o sistema. Neste diagrama os atores são os funcionários que estão divididos
em: verificador, diretor geral, INSP (Inspeção Naval), técnico e atendente.
Os
atendentes que salvam os requerimentos. Os verificadores conferem os documentos
e o requerimento.
Os funcionários da INSP fazem a mesma coisa que os
31
verificadores só que eles são responsáveis especificamente pelos serviços
referentes às embarcações. Os técnicos são os responsáveis pela manutenção de
processos e documentos. Os Verificadores e os da INSP são responsáveis pela
manutenção de requerentes, embarcações e amadores. Além de poderem salvar a
situação do requerimento.
O Diretor Geral, o principal ator, é o único que tem
acesso a tudo e por todo controle administrativo.
Como mais uma ferramenta de auxílio na construção do sistema foi
construído o Diagrama de Classes (Apêndice B). Este Diagrama possui a interface
de J01_Login que se relaciona com a interface J02_Menu. No software esta
comunicação só será permitida caso o login e a senha estejam corretos. A partir da
J02_Menu temos acesso as outras interfaces: J10_Tramite, J06_Acompanhamento,
J04_Auditoria,
J11_Exibe-Requerimento, J05_Busca, J07_Cadastro-Funcionario,
J03_Cadastro-Requerimento, J09_Cadastro-Processo, todas limitadas pelo o nível
de acesso do funcionário. Cada uma destas interfaces é responsável por mostrar
algo ao usuário que podem ser vistas abaixo:

J03_Cadastro-Requerimento
É responsável no sistema por mostrar todos os dados necessários para
ser efetuado o cadastro de requerimento.

J04_Auditoria
É responsável por mostrar toda ação feita pelo funcionário e o horário
de entrada e saída deste no sistema.

J05_Busca
É responsável no sistema por mostrar todas as informações
encontradas no banco de dados referente ao que foi digitado.

J06_Acompanhamento
É responsável no sistema mostrar os requerimentos que chegaram
para determinado funcionário.

J07_Cadastro-Funcionario
No sistema é responsável por mostrar todos os dados necessários para
realizar o cadastro de funcionário.

J08_Alerta-Geral
No sistema é responsável por mostrar ao usuário as ações realizadas
no momento.
32

J09_Cadastro-Processo
No sistema são mostrados todos os dados referentes ao processo para
ser realizado o cadastro de processos.

J10_Tramite
É responsável por mostrar no sistema toda a movimentação do
requerimento pela capitania.

J11_Exibe-Requerimento
No sistema ela mostra todas as informações do requerimento salvo no
Banco de Dados.
Além destas interfaces foram criados controles que fazem a comunicação
entre elas e as classes. Estes controles são responsáveis pelas funções de
cadastro, alteração, exclusão dentre outras funções de manutenção de algum dado
no Banco. As classes criadas para que possa ocorrer isso foram: C01_Requerente,
C02_Requerimento, C03_Funcionario, C04_Cargo, C05_Processo, C06_Servico,
C07_Amador, C09_Embarcacao, C10_Tramite, C11_Auditoria, C17_categoria. Cada
uma dessas classes possui seus referentes atributos podendo ser vista no Apêndice
C.
Após o diagrama pronto foi possível iniciar a modelagem do Banco de Dados
do sistema para melhor entender onde serão armazenados estes. Por isso foi feito o
Modelo Entidade-Relacionamento e Modelo Relacional.
O Modelo Entidade-Relacionamento (Apêndice C) possui uma entidade
principal
T02_Requerimento
que
está
relacionada
com
as
entidades:
T01_Requerente, T10_Tramite, T05_Processo, T15_Embarcacao_Temporaria e
T16_Amador_Temporario. Porque para ser feito um requerimento precisa de um
requerente, de um ou mais processos e das informações da embarcação ou amador
no qual vai ser necessário utilizá-lo em algum processo. Um requerimento possui
também um trâmite, no qual salva a movimentação deste pela CPPR. A
T01_Requerente
está
relacionada
com
as
entidades
T07_Amador
e
T09_Embarcacao. Porque um requerente pode ser um amador ou ter uma
embarcação. Além disso, a entidade T07_Amador está relacionada com a
T17_Categoria. Porque cada amador tem sua categoria.
A T05_Processo está
relacionada com as entidades T08_Documento e T06_Servico. Porque um processo
possui documentos e também um tipo de serviço. A T10_Tramite está relacionada
com T05_Processo, T02_Requerimento, T03_Funcionario. Porque um trâmite possui
33
um ou mais processos e um ou mais requerimentos. A função desta entidade no
banco de dados é registrar todos os comentários, situação, data de entrada e saída
referente aos processos de determinado requerimento e de salvar o código do
funcionário que registrou tudo isso. A entidade T03_Funcionario está relacionada
com a T04_Cargo, pois todo funcionário possui um cargo e com a T11_Auditoria no
qual salva todas as ações feitas pelo funcionário no sistema.
No Modelo Relacional (Apêndice D) todas as entidades do modelo EntidadeRelacionamento tornaram-se tabelas. Porém, as entidades que possuem relações
com outras de cardinalidade N p/ N foi criado uma nova tabela. Por isso nesse
modelo foram criados duas tabelas a mais T12_Documento_Processo e a
T13_Processo_Requerimento. A tabela T12_Documento _Processo possui as
chaves
primárias
das
tabelas
T13_Processo_Requerimento
T08_Documento
possui
as
chaves
e
T05_Processo.
primárias
das
Já
a
tabelas
T02_Requerimento e T05_Processo.
Após realizar todas as etapas citadas acima finalmente foi possível, iniciar o
desenvolvimento do software propriamente dito. Para realizar a codificação do
sistema a equipe foi dividida em duas partes. Uma focada na criação do banco de
dados e a outra na interface gráfica do sistema. É importante ressaltar que em
momento algum os elementos do sistema (banco de dados e interface gráfica) foram
tratados isoladamente, houve uma interação por parte dos desenvolvedores todos
os momentos dentre os dois contextos do sistema (parte lógica e gráfica), para que
no término do desenvolvimento não houvesse conflitos na conexão de ambas.
Para a criação das interfaces gráficas de interação com o usuário foi
utilizada a linguagem Java. Esta linguagem foi optada por oferecer recursos mais
favoráveis às necessidades do cliente e por apresentar um grande número de
desenvolvedores que a utilizam, tornando assim mais acessível ao cliente a
manutenção do sistema. Quanto ao desenvolvimento do Banco de Dados utilizou-se
a Linguagem SQL que é eficiente para se ter acesso aos dados, proporcionando
segurança no armazenamento e interação com os dados diretamente.
34
4
CONCLUSÃO E RESULTADOS
Através de pesquisas referentes a técnicas de implementação, modelagem de
sistemas e aplicação destas, bem como a utilização de nossos conhecimentos
construídos ao longo de nossa formação, pudemos concluir o projeto com êxito,
atendendo, fundamentalmente, as necessidades da Capitania dos Portos do Paraná,
que atuou como cliente dês de a idealização do sistema até sua ultima faze, a
utilização.
Através de ferramentas únicas para construção de interfaces gráficas ou
manipulação de códigos fontes tais quais NetBeans e FireBird, pudemos finalizar a
implementação do Software Desktop RIC, software este que possibilitou o
cumprimento das metas propostas, satisfazendo o requerente.
Quanto ao Software RIC, para alcançar a satisfação de seu futuro usuário,
contou com uma interface agradável, completa e de fácil uso, buscando sempre,
durante a implementação, considerar a opinião de seus idealizadores e,
futuramente, utentes do software. Um exemplo desta interface pode ser encontrado
na figura 4 contendo o menu principal, que possui um Layout gerado com base em
cálculos que se adaptam ao usuário, assegurando suporte à diversas resoluções
dentro de uma imensa variação - entre 800px de largura por 600px de altura, até
1920px de largura por 1200px de altura (testados).
Figura 4. Janela J02_MENU do Software Desktop RIC.
35
Para garantir a segurança do software e de sua base de dados foram
desenvolvidos níveis de acesso relacionados a conta de cada utente. Na Figura 5
vemos a primeira janela exibida ao usuário que tenta utilizar o sistema, esta janela
exige login e senha individual, traçando a partir destas informações demais dados
pertencentes ao funcionário da CPPR que tenha se logado no sistema.
Figura 5. Janela J01_LOGIN Software RIC.
A seguir, na Figura 6, temos um exemplo da limitação realizada de acordo
com o nível do Funcionário logado. No primeiro quadro da figura vemos um
funcionário de nível 1, que corresponde a um Atendente, já no segundo quadro,
observamos um funcionário nível 3, correspondente ao Diretor Geral. Nesta figura
podemos notar claramente que o gráfico do programa se modifica de acordo com o
usuário o operando, indicando assim suas limitações ou possibilidades.
Figura 6. Quadro comparativo da janela JA03_CADASTROS de Software Desktop RIC.
A grande preocupação das “primeiras impressões”, muito relacionadas ao
gráfico do Software, afetou inclusive a forma de navegação no sistema.
Desenvolvido para facilitar o máximo possível o acesso do usuário às informações e
36
funções, o RIC Desktop conta com uma maneira diferenciada de construção de
frame, que permite o início de frames dentro de frames, proporcionando acesso
direto às funções ou dados de maneira que o funcionário operando o sistema não
necessite mudar constantemente de janelas. Observe a característica descrita na
figura 7.
Figura 7. Sequência de imagens da J07_CADASTRO_DE_FUNCIONARIO do Software desktop
RIC.
Cumprindo também a exigência do cliente, foi implementado um sistema de
busca completo, retornando um conjunto amplo de resultados. Sua janela, bem
como grande parte do Software, depende da conexão com o banco de dados para
realizar um funcionamento adequado. Percebe-se, pela figura 8, que apenas com
fragmentos de palavras obtém-se resultados coerentes.
Figura 8. Janela J05_BUSCA Software desktop RIC.
37
O sistema de buscas falha apenas no sentido temporal, tendo em vista que
uma mesma busca é realizada em diversas tabelas do banco de dados e em
diferentes campos em um mesmo momento, podendo exigir um tempo demasiado
para o processamento das buscas, o que pode piorar com o povoamento do banco
de dados. Porém não causa empecilho grande o suficiente para inviabilizar o uso
deste sistema.
Além das demais exigências cobertas pelo software, atendemos também as
fundamentais, sendo elas o cadastro e o acompanhamento dos requerimentos. Nas
figuras de 9 a 12 se encontram as janelas responsáveis pelo cadastro dos
requerimentos e, logo em seguida, na figura 13 encontramos a janela de
acompanhamento, que possui a função de selecionar, dentre tantos requerimentos
cadastrados, aqueles que são dedicados à vistoria de cada funcionário.
Figura 9. Janela J03_CADASTRO_REQUERIMENTO_01 Software desktop RIC.
38
Figura 10. Janela J03_CADASTRO_REQUERIMENTO_02 Software desktop RIC.
Figura 11. Janela J03_CADASTRO_REQUERIMENTO_03 Software desktop RIC.
39
Figura 13.Janela J03_CADASTRO_REQUERIMENTO_04 Software desktop RIC.
Figura 12. Janela J06_ACOMPANHAMENTO Software desktop RIC.
Espera-se que este sistema possa atender as necessidades colocadas pela
CPPR e que os resultados obtidos com a implantação deste sejam avaliados de
acordo com que foi proposto na etapa de especificação das funcionalidades do
sistema. Caso alguma funcionalidade divirja (não vá de acordo) do que tenha sido
tratado nesta etapa haverá uma revisão desta.
40
REFERÊCIAS
PRESSMAN, R. Engenharia de Software. 3. ed. Editora: Makron Books. 1995
SILBERSCHATZ, A.; KORTH, H. & SUDARSHAN, S. Sistema de Banco de Dados.
Tradução Daniel Vieira. 5. ed. Rio de Janeiro: Elsevier, 2006.
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 2. ed.
Editora: Campus. 2006.
CHEN, P. Modelagem de Dados Abordagem Entidade-Relacionamento para
Projeto Lógico. 1. ed. Editora: Makron Books. 1990.
LEMAY, L.; CADENHEAD, R., Aprenda em 21 dias Java. 2. ed. Campus: 2001.
PEREIRA, W. Fundamento de Banco de Dados. 1. ed. Editora Érica. 2004
CANDIDO, C. H. BrModelo 2.0. Disponível em: <http://www.sis4.com/brModelo/>
CHANGE VISION, Astah Community. Disponível em: <http://astah.changevision.com/en/product/astah-community.html>
fabFORCE, DBDesigner 4. Disponível em: <http://fabforce.net/dbdesigner4/>
ORACLE CORPORATION. NetBeans. Disponível em:
<http://netbeans.org/index_pt_BR.html>
41
APÊNDICES
A- Diagrama de Caso de Uso
42
B- Diagrama de Classes
43
C- Modelo Entidade-Relacionamento
44
D- Modelo Relacional
45
E- Documento emitido pela CPPR para definir os objetivos da parceria com o
IFPR.
MARINHA DO BRASIL
CAPITANIA DOS PORTOS DO PARANÁ
DEPARTAMENTO DE STA
CONTROLE INFORMATIZADO DOS REQUERIMENTOS
1. Objetivo
Controlar o andamento dos requerimentos a fim de oferecer celeridade aos processos,
assim como informações estatísticas para subsidiar as decisões do comando.
2. Situação
Atualmente os requerimentos são controlados “manualmente” seja através de livros de
controle ou através de várias planilhas criadas por cada integrante do processo.
O “arquivo do STA”, local onde são arquivados os requerimentos deferidos e
indeferido, possui vários métodos de arquivamento (por ano, alfabético, numérico), além de
arquivar os documentos das embarcações e dos amadores.
3. Problemas constatados.
a) Duplicidade de requerimentos, ou seja, dois ou mais requerimentos com a mesma
numeração;
b) Demora na localização dos requerimentos;
c) Difícil extração de dados estatísticos;
d) Cada divisão e até setores com os seus próprios livros de numerações de
requerimentos;
e) Falta de subsídios ou corretos enquadramentos para os indeferimentos;
f) A mesmo procedimento sendo realizado em etapas distintas ±;
g) Etapas por vezes esquecidas de serem realizadas;
h) Dinamismo das NORMAM, impõe de atualizações rápidas os processos;
i) Falta de Ordens Internas regulando os assuntos;
j) Dificuldade na localização dos requerimentos arquivados (finalidade transferência
de jurisdição).
4. Sugestões para o sistema
a) possibilidade da retirada e inserção dos serviços oferecidos pela Capitania;
b) que atenda tanto ao CP-20 quanto ao CP-10;
c) numerador único para os requerimentos de toda a Capitania;
d) leitor de código de barras para agilizar o recebimento dos requerimentos;
e) exposição ao atendente dos documentos necessários para aquele serviço oferecido;
f) login e senha de acesso (com perfis);
g) registro dos procedimentos realizados em BD para auditorias (com box);
i) extração de dados e relatórios;
j) integração com página da Internet para exibição da situação do requerimento aos
requerentes (CPF do requerente);
k) informação de tempo do requerimento na Capitania;
l) localização do requerimento;
m) controle da saída do requerimento;
46
n) regular através de Ordem Interna (não só o sistema, mas os processos humanos);
o) designar o “gerente do sistema” para recolher as reclamações;
p) Possibilidade de atualizações do sistema;
q) realização de adestramento dos usurários;
r) desenhar o fluxo do requerimento com possibilidade de alterações;
s) preenchimento e impressão do requerimento no balcão de atendimento para
assinatura do requerente;
t) relatório (mensal) de documentos que sofreram by-pass;
u) Controle do “arquivo do STA” embarcações ordenadas por número de inscrição,
assim como os amadores (regular em OI);
v) código de barra, figura e data de validade no protocolo para não ter que ser
carimbado, chancelado e assinado pelo atendente. Ao final do dia um código de barra único
com todos os requerimentos ali contidos (separados por setor);
x) vaga para a realização da prova com agenda, possibilidade de aumentar e reduzir o
nº de vagas, tipo marcação cadeiras de avião;
w) Possibilidade de selecionar os indeferimentos em uma caixa de seleção para ser
inserido na 2ª via do requerimento, podendo ampliar e alterar;
y) Possibilidade de inserir requerimentos processados manualmente em caso de pane
do sistema (regular em OI);
z) Campo box para o atendente contendo “Não consta débito decorrente de infração da
Lei nº 9.537 (LESTA) que impeça o andamento de qualquer documento ou ato administrativo
na Capitania”;
aa) Vistoria da embarcações mesmos moldes da prova do amador.
ab) Disponibilizar para lançamento do CP-22 os dados estatísticos mensais de
arrecadação de TUF, Despachos, Inspeções, embarcações arrestadas com data/hora da última
atualização.



Fatores Positivos
Exatidão das informações extraídas dos
relatórios.
Minimização de erros durante o
recebimento dos requerimentos.
Facilidade de localização do
requerimento em processo.



Fatores Negativos
Restrição do pessoal a mudanças.
Necessidade de pessoal especializado
para manutenção do sistema.
O sistema em baixa poderá afetar no
atendimento.