Universidade Federal de Mato Grosso - ic.ufmt.br fileuniversidade federal de mato grosso...
75
UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO RELATÓRIO DE ESTÁGIO SUPERVISIONADO DOCUMENTAÇÃO, ADEQUAÇÕES E INOVAÇÕES NO SISTEMA DE CONTROLE E BLOQUEIO (SISBLOQ) PAULO HENRIQUE GARCIA CUIABÁ – MT Ano 2014
Transcript of Universidade Federal de Mato Grosso - ic.ufmt.br fileuniversidade federal de mato grosso...
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
SISTEMAS DE INFORMAÇÃO
RELATÓRIO DE ESTÁGIO SUPERVISIONADO
DOCUMENTAÇÃO, ADEQUAÇÕES E INOVAÇÕES NO
SISTEMA DE CONTROLE E BLOQUEIO (SISBLOQ)
PAULO HENRIQUE GARCIA
CUIABÁ – MT
Ano 2014
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
SISTEMAS DE INFORMAÇÃO
RELATÓRIO DE ESTÁGIO SUPERVISIONADO
DOCUMENTAÇÃO, ADEQUAÇÕES E INOVAÇÕES NO
SISTEMA DE CONTROLE E BLOQUEIO (SISBLOQ)
PAULO HENRIQUE GARCIA
Relatório apresentado ao Instituto de
Computação da Universidade Federal de
Mato Grosso, para obtenção do título de
Bacharel em Sistemas de Informação.
CUIABÁ – MT
Ano 2014
3
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
SISTEMAS DE INFORMAÇÃO
PAULO HENRIQUE GARCIA
Relatório de Estágio Supervisionado apresentado à Coordenação do Curso de
Sistemas de Informação como uma das exigências para obtenção do título de
Bacharel em Sistemas de Informação da Universidade Federal de Mato Grosso
Aprovado por:
Prof. Msc. Nilton Hideki Takagi
Instituto de Computação
(Coordenador de Estágios)
Prof. MSc. Allan Gonçalves de Oliveira
Instituto de Computação
(ORIENTADOR)
Prof. MSc. Raphael de Souza Rosa Gomes
Instituto de Computação
(CONVIDADO)
4
DEDICATÓRIA
A Deus por permitir a concretização de mais um sonho e por saber a hora certa
para que isso ocorra.
À minha família pelo apoio, pela paciência, pela dedicação e carinho com que me
tratou nesse tempo todo de dedicação quase que exclusiva aos estudos.
À minha esposa, filha e meus pais, que abriram mão de muito tempo da minha
companhia para que eu pudesse concretizar mais este sonho.
Aos meus amigos que sempre me apoiaram e incentivaram durante essa trajetória.
5
AGRADECIMENTOS
Agradeço especialmente a minha esposa que sempre me incentivou e
encorajou a continuar os estudos que por vários anos foi um projeto que ficou
engavetado, que me deu forças e apoio para chegar ao final e também agradeço a
todos os professores, técnicos e funcionários da UFMT que sempre me trataram com
respeito e me proporcionaram um bom aprendizado.
6
SUMÁRIO
LISTA DE FIGURAS .......................................................................................................................... 7
LISTA DE SIGLAS E ABREVIATURAS ......................................................................................... 8
RESUMO .............................................................................................................................................. 9
INTRODUÇÃO .................................................................................................................................. 10
1. REVISÃO DE LITERATURA ................................................................................................ 12
1.1. LEI 12.737 DE 30 DE NOVEMBRO DE 2012. ......................................................................... 12 1.2. UML (UNIFIED MODELING LANGUAGE). ........................................................................... 13
1.2.1. Diagrama de Casos de Uso. ......................................................................................... 14 1.2.2. Diagrama de Fluxo de Dados. ..................................................................................... 15 1.2.3. Dicionário de Dados. ................................................................................................... 17 1.2.4. Diagrama de Entidades e Relacionamento. ................................................................. 17
1.3. HTML. .............................................................................................................................. 19 1.4. PHP. .................................................................................................................................. 20 1.5. CSS. .................................................................................................................................. 21 1.6. MYSQL. ............................................................................................................................ 22
2. MATERIAS, TÉCNICAS E MÉTODOS ............................................................................... 24
2.1. LEI 12.737 DE 30 DE NOVEMBRO DE 2012. ......................................................................... 24 2.2. UML (UNIFIED MODELING LANGUAGE). ........................................................................... 24
2.2.1. Diagrama de Casos de Uso. ......................................................................................... 25 2.2.2. Descrição de Casos de Uso. ......................................................................................... 25 2.2.3. Diagrama de Fluxo de Dados. ..................................................................................... 26 O DFD Sistema de bloqueio. ...................................................................................................... 26 O DFD Liberação do sistema por senha. ................................................................................... 26 Os DFDs Diversos. ..................................................................................................................... 26 2.2.4. Dicionário de Dados. ................................................................................................... 26 2.2.5. Diagrama de Entidades e Relacionamento. ................................................................. 26
3. RESULTADOS ......................................................................................................................... 28
4. DIFICULDADES ENCONTRADAS ...................................................................................... 34
5. CONCLUSÕES ......................................................................................................................... 36
6. REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................... 37
7. APÊNDICES E/OU ANEXOS ................................................................................................. 38
7.1. APÊNDICE – PROJETO SISBLOQ. ................................................................................... 38
7
LISTA DE FIGURAS
FIGURA 1 - PROCESSO DE LEVANTAMENTO E ANÁLISE DE REQUISITOS. ................................................. 14 FIGURA 2 - CASO DE USO DE EXEMPLO ................................................................................................. 15 FIGURA 3 - DFD NÍVEL 1 DE EXEMPLO ................................................................................................. 16 FIGURA 4 - DD DE EXEMPLO ................................................................................................................. 17 FIGURA 5 - DER DE EXEMPLO ............................................................................................................... 18 FIGURA 6 - EXEMPLO DE CÓDIGO HTML (IMAGENS GOOGLE.COM.BR) .............. ERRO! INDICADOR NÃO
DEFINIDO. FIGURA 7 - CÓDIGO PHP DE EXEMPLO .................................................................................................. 20 FIGURA 8 - CODIGO CSS DE EXEMPLO .................................................................................................. 21 FIGURA 9 - CODIGO SQL DE EXEMPLO .................................................................................................. 23 FIGURA 10 - ALTERAR DIAS PARA BLOQUEIO AUTOMÁTICO .................................................................. 28 FIGURA 11 - TELA EXECUTÁVEL TEMPORÁRIO COM OS DADOS DE CONFIGURAÇÃO .............................. 29 FIGURA 12 - SISTEMA DE LIBERAÇÃO COM SENHA ................................................................................ 29 FIGURA 13 - SITE - TELA HOME ............................................................................................................ 30 FIGURA 14 - SITE - TELA QUEM SOMOS E TELA MISSÃO ...................................................................... 30 FIGURA 14 - SITE - TELA QUEM SOMOS E TELA MISSÃO .................. ERRO! INDICADOR NÃO DEFINIDO. FIGURA 16 - SITE - TELA PRODUTOS E TELA FALE CONOSCO ............................................................... 30 FIGURA 15 - SITE - TELA PRODUTOS E TELA FALE CONOSCO ........... ERRO! INDICADOR NÃO DEFINIDO. FIGURA 18 - SITE - TELA CADASTRO DE REGISTROS ............................................................................. 31 FIGURA 19 - TELAS ENTRAR E LOGIN ................................................................................................... 31 FIGURA 17 - TELAS ENTRAR E LOGIN ............................................... ERRO! INDICADOR NÃO DEFINIDO. FIGURA 21 - TELA ÁREA RESTRITA ADM ............................................................................................ 32 FIGURA 22 - TELA ÁREA RESTRITA USU .............................................................................................. 32 FIGURA 23 - TELAS AGENDA ................................................................................................................ 32 FIGURA 20 - TELAS AGENDA ............................................................ ERRO! INDICADOR NÃO DEFINIDO. FIGURA 25 - TELAS CADASTRO USUÁRIOS ............................................................................................ 33 FIGURA 26 - TELA MANUTENÇÃO REGISTRO ........................................................................................ 33 FIGURA 22 - TELA MANUTENÇÃO REGISTRO .................................... ERRO! INDICADOR NÃO DEFINIDO. FIGURA 28 - TECLAS DE NAVEGAÇÃO ................................................................................................... 33 FIGURA 29 - STRUCT DATA ................................................................................................................... 34 FIGURA 30 - FUNÇÃO IDENTIFICAÇÃO DO ANO BISSEXTO ..................................................................... 34 FIGURA 31 - DIFERENÇA ENTRE DATAS ................................................................................................. 35 FIGURA 32 – IDENTIFICAÇÃO DA DATA ATUAL ...................................................................................... 35
8
LISTA DE SIGLAS E ABREVIATURAS
Tabela 1 - Lista de Siglas
ABNT Associação Brasileira de Normas Técnicas.
CPU Central Processing Unit – Unidade Central de Processamento.
UML Unified Modeling Language - Linguagem unificada de modelagem
DCU Diagrama de Casos de uso
DFD Diagrama de fluxo de dados
DD Dicionário de dados
DER Diagrama de entidade e relacionamento
MER Modelo entidade e relacionamento (Modelo Conceitual)
C Linguagem de programação
C++ Linguagem de programação
HTML Hyper Text Markup Language
PHP Um acrônimo recursivo para PHP: Hypertext Preprocessor
CSS Cascading Style Sheets
DevC++ Ambiente de desenvolvimento integrado livre que suporta as
linguagens C e C++.
NotePad++ É um editor de texto e de código fonte de código aberto sob a licença
GPL
WWW World Wide Web
9
RESUMO
Este relatório trata da implementação de melhorias e da criação da
documentação de um sistema de controle de clientes chamado SisBloq que foi
desenvolvido e é de propriedade da empresa WebCel – Garcia e Mendonça Ltda. A
WebCel trabalha com representação e suporte de sistemas ERP no estado de Mato
Grosso entre outras áreas de atuação. O SisBloq tem como função o bloqueio do
sistema ERP do cliente e o seu monitoramento, composto por três aplicativos
desenvolvidos em C++, um site web e um banco de dados. Dos aplicativos, um deles
é usado apenas no instante da instalação do sistema para inclusão de alguns dados,
sendo o mesmo excluído ao termino da instalação outro usado no caso de liberação
do sistema ERP através de senha que se altera diariamente e só é fornecida pela
WebCel. A sua execução é feita através de um atalho que fica na área de trabalho do
cliente, e o outro é executado na máquina do cliente, toda vez que a máquina é
reiniciada, com a função de bloquear, liberar e atualizar informações no servidor da
WebCel. O site, desenvolvido em HTML e PHP com CSS, tem várias páginas,
Home, missão, produtos, contato e área restrita, home, missão e produtos trazem
informações da empresa, contato é utilizada para comunicação através de e-mail com
a empresa e a área restrita é utilizada para gerenciar e monitorar o SisBloq, sendo
que para isso se faz necessário estar logado através de login e senha com controle de
sessão. Tanto o login como a senha passam por regras de validação. Por fim, o banco
de dados MySQL que fica instalado no servidor da WebCel. O foco deste relatório é
a parte do controle e bloqueio do sistema do cliente, por tanto se abordará detalhes
técnicos apenas da página da área restrita, desconsiderando a parte da agenda e
demais páginas do site. O resultado deste projeto foi satisfatório, pois o mesmo
atingiu todas as expectativas, reduzindo em cerca de 95% a inadimplência,
alcançando todos os objetivos e ainda abrindo caminho para novas ideias a serem
pesquisadas e colocadas em prática.
Palavras chaves: SisBloq, WebCel, Sistema ERP, DCU, DD, DFD e DER.
10
Introdução
No mercado de desenvolvimento de sistemas, no início o software era
desenvolvido especificamente para atender à solicitação de um ou de poucos clientes.
O sistema era vendido com os fontes por preços bem altos o que dificultava muito
sua comercialização.
Com o tempo passaram a vender o direito de uso e fazer contratos de
manutenção e suporte mensal, onde se teria produto com custo menor e um ganho
mensal.
Depois começaram a terceirizar a representação e o suporte do sistema,
diminuindo assim os custos da software house, pois poderia diminuir os setores
comercial e de suporte. Nesta época a negociação de venda era feita pelo
representante que também prestava o suporte aos clientes, mas o pagamento era feito
diretamente a software house que repassava uma pequena parte ao representante.
Hoje está se tornando uma tendência de mercado a comercialização das
licenças de uso diretamente com o representante e assim que a licença é ativada a
software house começa a cobrar uma mensalidade do representante. O representante
negocia a licença de uso diretamente com o cliente final e fecha com ele um contrato
de suporte, assim a responsabilidade de recebimento é do representante e não mais da
software house. Desta forma ela reduz novamente seu custo pois diminui
drasticamente seus setores comercial e financeiro.
Neste contexto, percebe-se que não há a devida valorização por parte do
cliente em relação aos recursos de Tecnologia da Informação (Ti), pelo contrário,
todo o dinheiro direcionado para o setor é considerado apenas como gasto e não
investimento. Com isso, aumentam cada vez mais os casos de inadimplência por
parte dos clientes em relação aos contratos firmados com o representante, cerca de 60
a 65% do total de clientes. Nesses casos, a ferramenta mais eficaz para resolver o
problema seria o bloqueio do sistema ERP. Geralmente o controle é feito
internamente ao sistema, o qual acessa uma base de dados do fornecedor e faz a
verificação do contrato, nesse caso, é necessária uma conexão com a internet, e caso
não se tenha, o controle não pode ser feito.
11
Diante disso, faz-se necessário então um sistema que seja capaz de fazer o
controle dos contratos firmados entre fornecedor e cliente, verificando os casos de
inadimplência dos contratos. Esse sistema deve ainda poder verificar se a conexão
com a internet foi interrompida e caso tenha sido, bloquear o sistema após um
determinado período sem acesso à internet para nova verificação.
Nesse contexto, a empresa WebCel – Garcia e Mendonça Ltda, que trabalha
com suporte e comercialização de Licença de uso de software ERP específico para
área de drogarias, farmácia e áreas afins além de outras especialidades viu a
necessidade de se desenvolver um sistema para esse controle.
Foi desenvolvido o sistema de controle (SisBloq) que tem como objetivo
fazer o controle dos contratos de licença de uso de software fornecidos pela WebCel.
Este trabalho apresenta o relatório de estágio supervisionado desenvolvido
pelo aluno no decorrer do desenvolvimento do sistema SisBloq.
O objeto deste trabalho é a implementação de melhorias e modificações no
sistema já existente, assim como a criação de sua documentação.
Neste relatório serão detalhadas as atividades realizadas no período do
estágio, bem como as técnicas e ferramentas utilizadas para que as mesmas fossem
possíveis.
O relatório está organizado como segue: O capítulo 1 apresenta a revisão da
literatura que contribuiu para o desenvolvimento do trabalho. No capítulo 2 são
apresentados os materiais, técnicas e métodos utilizados. O capítulo 3 apresenta os
resultados alcançados no desenvolvimento. Posteriormente são apresentadas as
dificuldades encontradas no decorrer do estágio supervisionado bem como as
soluções encontradas e as conclusões do trabalho.
12
1. REVISÃO DE LITERATURA
Como prevenção de eventuais problemas jurídicos, procurou-se conhecer a
legislação vigente que trata da área de crimes informáticos, pois se fará o bloqueio
do sistema ERP do cliente e isto pode ser interpretado como invasão. Nas pesquisas
foi encontrado a lei Carolina Dieckmann descrita no item 1.1 que proporcionou a
tomada de decisão em relação a forma que o SisBloq irá atuar.
1.1. Lei 12.737 de 30 de novembro de 2012.
A lei Carolina Dieckmann, lei 12.737 de 30 de novembro de 2012 dispõe
sobre a tipificação criminal de delitos informáticos e altera o decreto-Lei nº2.848, de
07 de dezembro de 1940 (Código Penal) acrescentando os artigos 154-A e 154-B que
tratam respectivamente da “invasão de dispositivo informático” e “ação penal”.
O artigo 154-A diz ser contra a lei a invasão de máquinas por qualquer que
seja a forma ou meio sem autorização expressa do titular, seja para fins de obter,
alterar ou destruir dados deste, conforme destacado abaixo.
“Art. 154-A. Invadir dispositivo informático alheio, conectado ou não à
rede de computadores, mediante violação indevida de mecanismo de
segurança e com o fim de obter, adulterar ou destruir dados ou informações
sem autorização expressa ou tácita do titular do dispositivo ou instalar
vulnerabilidades para obter vantagem ilícita.” (BRASIL 2012).
O artigo 154-B trata da ação penal dos crimes definidos no artigo 154-A.
13
Em relação a documentação, ou seja o projeto do SisBloq, adotou-se o padrão
UML para montagem e execução deste projeto, por tanto usou-se a metodologia e
técnicas descritas do item 1.2 em diante.
1.2. UML (Unified Modeling Language).
É uma linguagem visual utilizada para modelar softwares baseados no
paradigma de orientação a objetos.
“A UML formalizou um conjunto de conceitos composto por elementos
(classes, interfaces e componentes), relacionamentos (associação,
generalização e dependências) e tipos de diagramas, que permitiu a
unificação na representação de modelos orientados a objetos de sistemas
computacionais.” (www.devmedia.com.br/introducao-sobre-uml-mecanis
mos-gerais-revista-sql-magazine-91/22261#ixzz3RNAm4tO0).
Essa linguagem foi criada em 1996, como o resultado da integração dos
métodos orientados a objetos propostos por Booch (1994), Rumbaugh (1991) e
Jacobson (1993), padronizando as notações utilizadas. Na versão 1.1, foi aprovada
como linguagem padrão para a modelagem orientada a objetos pela OMG (Object
Management Group) em 1997.
A definição da UML encontra-se na "Especificação de Modelagem Unificada
da OMG", no site da OMG, com o objetivo de descrever qualquer tipo de sistema,
em termos de diagramas orientados a objetos. A versão 2.0 da UML foi adotada pela
OMG em 2004, possuindo 13 diferentes tipos de diagramas, mais elementos e maior
formalismo. A versão corrente é 2.4 (beta), de março de 2011. (Fonte: Revista SQL
Magazine 91).
A modelagem UML independe da linguagem de programação que o sistema
será desenvolvido.
A engenharia de software vai de encontro com a engenharia de requisitos
onde tem-se os termos de aquisição, estruturação e análise de informações. Mesmo
tomando-se muito cuidado o grande volume de informações e suas particularidades
podem ocasionar ambiguidades. Assim, torna-se uma tarefa muito difícil modelar
problemas do mundo real para serem solucionados por sistemas de computação, uma
vez que é preciso verificar quais serão os problemas tratados. Quase sempre,
14
constitui-se uma tarefa árdua essa decisão, pois geralmente são problemas de grande
complexidade.
Depois da elicitação de requisitos usa-se a modelagem através de gráficos e
diagramas como por exemplo o diagrama de casos de uso, o diagrama de fluxo de
dados e outros.
A figura abaixo apresenta todo o processo de elicitação de requisitos,
inclusive as etapas que se repetem ao longo desse levantamento.
Figura 1 - Processo de levantamento e análise de requisitos.
Fonte: SOMMERVILLE (2003).
1.2.1. Diagrama de Casos de Uso.
O diagrama de casos de uso é utilizado para descrever graficamente as
funcionalidades apontadas pelo levantamento de requisitos através da ótica do
usuário.
“Um caso de uso descreve um conjunto particular de funcionalidades do
sistema, modelando o diálogo que uma entidade externa, chamada ator,
realiza com o sistema.
Um caso de uso especifica o comportamento de um sistema ou parte dele. É
também uma descrição do conjunto de passos que o sistema executará para
desempenhar suas funções.
15
Um caso de uso identifica eventos que podem ocorrer e descreve a resposta
do sistema para estes eventos.” (Rodrigo Oliveira Spínola - DevMedia
2012).
Assim é possível descrever graficamente as funcionalidades que um sistema
desempenhará, como no exemplo (abaixo) de uma máquina de SelfService, que tem
como atores, o cliente, o repositor e o coletor que executam as tarefas de comprar,
reabastecer e coletar o dinheiro:
Figura 2 - Caso de Uso de exemplo
Fonte: http://www.dsc.ufcg.edu.br/ (2007)
1.2.2. Diagrama de Fluxo de Dados.
O diagrama de fluxo de dados (DFD) é uma representação gráfica do
"fluxo" de dados através de um sistema de informação. (Fonte: Iseg 2007).
O diagrama de fluxo de dados mostra o sistema como uma rede de
informações onde se mostra cada processo desde sua origem até o seu destino, passo
a passo.
O DFD mostra todas as relações entre os dados, os processos que
transformam os dados e o limite entre o que é do sistema e o que está fora dele.
16
O DFD pode ser nível 0, 1 ou 2, o nível 0 engloba vários processos, o nível 1
mostras os processos um a um e o nível 2 detalha os processos e os dados
transportados entre eles. Abaixo temos um exemplo de um DFD de um sistema de
reservas, no nível 1.
Figura 3 - DFD Nível 1 de exemplo
Fonte: http://www.gta.ufrj.br/ (2007)
17
1.2.3. Dicionário de Dados.
Detalham os atributos de todas as tuplas das tabelas, ou seja, como são
formados cada um dos campos das tabelas no banco de dados. (Fonte: Disciplina de
Análise e Projeto de Sistemas 2).
Este documento, permite que os analistas obtenham informações sobre todos
os objetos do modelo de forma textual, contendo explicações que podem ser muitas
vezes difíceis de incluir no diagrama. É válido lembrar que o objetivo do documento
é ser claro e consistente.
Existem vários formas e modelos de dicionário de dados, mas todos com a
mesma proposta, abaixo segue o exemplo de um:
Figura 4 - DD de exemplo
Fonte: http://labeee.ufsc.br/ (2014).
1.2.4. Diagrama de Entidades e Relacionamento.
Quando se inicia o desenvolvimento de um novo sistema, ou mesmo de uma
nova funcionalidade para um sistema existente, um dos primeiros passos a ser
executado é o estudo e levantamento dos requisitos necessários para a construção do
18
produto final. Durante essa análise, identifica-se as principais partes e objetos
envolvidos, suas possíveis ações e responsabilidades, suas características e como elas
interagem entre si. (Fonte: Disciplina de Análise e Projeto de Sistemas 2).
Não que não se possa implementar diretamente, mas o levantamento é uma
boa prática.
A partir das informações obtidas, pode-se desenvolver um modelo conceitual
que será utilizado para orientar o desenvolvimento propriamente dito, fornecendo
informações sobre os aspectos relacionados ao domínio do projeto em questão.
Enquanto o MER é um modelo conceitual, o Diagrama Entidade
Relacionamento (DER) é a sua representação gráfica. Em situações práticas, o
diagrama é tido muitas vezes como sinônimo de modelo, uma vez que sem uma
forma de visualizar as informações, o modelo pode ficar abstrato demais para
auxiliar no desenvolvimento do sistema. Dessa forma, quando se está modelando um
projeto, o mais comum é já criar sua representação gráfica, seguindo algumas regras.
O diagrama facilita ainda a comunicação entre os integrantes da equipe, pois
oferece uma linguagem comum utilizada tanto pelo analista, responsável por levantar
os requisitos, e os desenvolvedores, responsáveis por implementar aquilo que foi
modelado.
A baixo segue um modelo de um DER simples de um cadastro de produto
para familiarização:
Figura 5 - DER de exemplo
Fonte: https://programandodotnet.wordpress.com (2010).
19
1.3. HTML.
HTML foi criada por Tim Berners-Lee, é uma linguagem de fácil
entendimento baseada em TAGs.
O acrônimo HTML vem do inglês e significa Hypertext Markup Language ou
em português Linguagem de Marcação de Hipertexto. (Fonte: Disciplina de Web e Web2).
É uma linguagem de formatação que é interpretada pelo browser. Isto
significa que ela serve para criar uma formatação diferenciada do texto. Com as
TAGs podem ser criados parágrafos, títulos, cabeçalhos, formulários e tudo mais que
vemos numa página de internet.
Um documento HTML pode ser escrito utilizando um editor de texto comum,
bastando para isso conhecimento do código, para se definir as funções necessárias.
As versões de evolução da HTML incluem XHTML (uma linguagem com
sintaxe mais rigorosa, baseada em XML) e HTML5 (quinta versão da HTML que
traz novos recursos, principalmente a manipulação de conteúdo gráfico e
multimídia).
Figura 6 - Exemplo de código HTML
Fonte: http://pt.wikipedia.org/wiki/HTML (2015)
20
1.4. PHP.
Originalmente era chamado de “Personal Home Page Tools”, através de uma
votação da comunidade foi escolhido o novo nome, PHP que significa: Hypertext
Preprocessor.
Ele é uma linguagem de script de servidor, e uma ferramenta muito poderosa
para a criação de páginas Web dinâmicas e interativas. É amplamente utilizado, livre
e alternativa eficiente para concorrentes como a Microsoft ASP. É uma linguagem
dinâmica e flexível, ele suporta uma grande variedade de técnicas de programação.
Pode ser usado como extensão de seus arquivos o “.php” e “.phtml”. (Fonte: Disciplina
de Web e Web2).
Ainda possui um conjunto completo de funcionalidades de programação
orientada a objetos e é um módulo oficial do servidor Apache, que atualmente é o
líder do mercado de servidores Web livres, hoje constitui cerca de 55% da WWW.
Isso significa que o mecanismo de script do PHP pode ser construído no próprio
servidor Web, tornando a manipulação de dados mais rápida. Assim como o servidor
Apache, o PHP é compatível com várias plataformas, o que significa que ele executa
em seu formato original em várias versões do UNIX e do Windows. É sempre
descrito entre as TAGs “<?php” para indicar o início e “?>” para indicar o final,
conforme é mostrado no código do exemplo abaixo:
Figura 7 - Código PHP de exemplo
Fonte: http://webmasterpauloricardo.blogspot.com.br/ (2011)
21
1.5. CSS.
CSS (Cascading Style Sheets) é uma linguagem de folhas de estilo que define
a apresentação de documentos criados em linguagem de marcação (HTML e XML).
Criado uma página de estilos que será acessada por link’s, assim serão o
documento e a formatação dois arquivos diferentes.
Com a formatação armazenada separadamente do documento terá a vantagem
de poder reaproveitar a formatação em várias páginas diferentes o que além de
econômico facilita a manutenção.
Existem 3 versões de CSS, CSS1, CSS2 e CSS3. Onde nem todos os
navegadores estão compatibilizados em todas as suas versões. (Fonte: Disciplina de Web
e Web2).
Abaixo um exemplo de código de um arquivo de Estilo CSS.
Figura 8 - Codigo CSS de exemplo
22
1.6. MySQL.
MySQL community Edition é um banco de dados de código aberto. Está
disponível sob a licença GPL e é apoiado por uma enorme e ativa comunidade de
desenvolvedores de código aberto. É de propriedade da SUN/Oracle.
Muitas das maiores organizações do mundo e as que mais crescem, incluindo
Facebook, Google, Adobe, Alcatel Lucent e Zappos contam com MySQL para
poupar tempo e dinheiro alimentando seus sites de alto volume, sistemas críticos de
negócios e software empacotado.
“Many of the world's largest and fastest-growing organizations including
Facebook, Google, Adobe, Alcatel Lucent and Zappos rely on MySQL to
save time and money powering their high-volume Web sites, business-
critical systems and packaged software.”
O MySQL Community Edition inclui:
Arquitetura de mecanismo de armazenamento contestável;
Vários motores de armazenamento:
o InnoDB;
o MyISAM
o NDB (MySQL Cluster)
o Memória
o Fundir
o Arquivo
o CSV
MySQL Replication: Para melhorar o desempenho do aplicativo e
escalabilidade;
MySQL Partitioning: Para melhorar o desempenho e gerenciamento de
aplicações de banco de dados grandes;
Stored Procedures: Para melhorar a produtividade do desenvolvedor;
Gatilhos: Para impor regras de negócio complexas no nível de banco de
dados;
Visualizações: Para assegurar informações confidenciais não sejam
comprometidos;
23
Esquema de desempenho: Para o monitoramento do nível de usuário /
aplicação do consumo de recursos;
Esquema de informações: Para facilitar o acesso aos metadados;
MySQL Conectores: (ODBC, JDBC, .NET, etc) para a construção de
aplicações em vários idiomas;
MySQL Workbench: Para modelagem visual, desenvolvimento SQL e
administração;
Disponível em mais de 20 plataformas e sistemas operacionais, incluindo
Linux, Unix, Mac e Windows.
Abaixo segue um exemplo de um código de inserção de dados em uma tabela
de um banco MySQL.
Figura 9 - Codigo SQL de exemplo
24
2. MATERIAS, TÉCNICAS E MÉTODOS
Este capítulo aborda a metodologia utilizada no desenvolvimento do trabalho.
Buscou-se atender os aspectos legais de desenvolvimento de software. Assim,
atentou-se para o que diz a Lei 12.737. Para a documentação do sistema optou-se
pelo uso da UML como descrito abaixo.
2.1. Lei 12.737 de 30 de novembro de 2012.
Tomou-se o cuidado de observar a legislação vigente que diz ser proibido
a invasão de máquinas por qualquer que seja a forma ou meio. Assim foi
decidido pela criação de uma ferramenta que instalada na máquina do cliente se
conecta no servidor da WebCel e executa as rotinas necessárias de acordo com as
orientações do sistema. Outra medida preventiva é a cláusula colocada no
contrato que permite o bloqueio do sistema, ou seja, a interrupção dos serviços
em casos de inadimplência ou atrasos a partir do quinto dia do vencimento.
2.2. UML (Unified Modeling Language).
Como metodologia adotou-se a UML, assim foram utilizadas como técnicas o
diagrama de casos de uso (DCU), o diagrama de fluxo de dados (DFD) e por fim,
mas não menos importante, o diagrama de entidade e relacionamento (DER), apesar
de fazer parte da UML também foram utilizadas as descrições de casos de uso e o
dicionário de dados (DD).
A ferramentas utilizadas para confecção deste relatório e do projeto foram o
Microsoft Visio, Microsoft Word, imagens em padrão “.png” e “.jpg”, banco de
dados MySQL, PHP, HTML, CSS, linguagem de programação C e C++, DevC++,
Inno Setup Compiler, Notepad++, máquina virtual Virtual Box, Windows 8.1.
Uma das técnicas usadas para a elicitação de requisitos foi um questionário
que foi apresentado para o cliente e usuários do sistema, este recurso foi de grande
importância no levantamento das regras de negócio do SisBloq.
25
2.2.1. Diagrama de Casos de Uso.
O DCU (Apêndice, página 59), descreve as ações que o sistema executa, que
no caso são elas:
Cadastrar usuários;
Instalação do sistema;
Alterar nome do cliente;
Alterar número do registro;
Cadastrar clientes;
Alterar número de dias para bloqueio do sistema;
Alterar status de uso;
Fazer login;
Os atores que interagem com o sistema que são o financeiro, o gerente
de suporte e o funcionário do suporte.
O DCU (Apêndice, página 60), descreve a ação que o executável de liberação
do sistema executa, que no caso é:
Liberar o sistema com uso de senha;
O ator que interage com o executável é o cliente.
2.2.2. Descrição de Casos de Uso.
O Diagrama de Casos de Uso mostra de forma gráfica as ações que o sistema
executa, já a descrição de casos de uso descreve em detalhes estas ações.
São detalhes que fazem parte das descrições de casos de uso, quem usa,
descrição do fluxo principal, Includes, Extends, referencias, gatilho, pré-condição e
pós-condição.
Conforme pode ser visto nas Descrições de Casos de Uso do sistema
(Apêndice, páginas 61 a 70).
26
2.2.3. Diagrama de Fluxo de Dados.
Os diagramas de fluxo de dados têm a função mostrar todo o fluxo dos dados
a que ele se refere, inclusive com os processos pelos quais passarão. No
SisBloq foi usado os DFDs abaixo:
O DFD Sistema de bloqueio.
O DFD Sistema de bloqueio (Apêndice, página 71), mostra o fluxo
de dados de todo o sistema de bloqueio em nível 1, nele se tem todas ações
possíveis descritas.
O DFD Liberação do sistema por senha.
O DFD Liberação do sistema por senha (Apêndice, página 72),
mostra em fluxos de dados a ação para liberação do sistema ERP do cliente
em nível 1.
Os DFDs Diversos.
Os DFDs Diversos (Apêndice, páginas 72 e 73), mostram em fluxos
de dados as diversas ações possíveis do sistema mas em nível 2 de
detalhamento.
2.2.4. Dicionário de Dados.
Detalham os atributos de todas as tuplas das tabelas, ou seja, como são
formados cada um dos campos das tabelas no banco de dados.
Desta forma no DD (Apêndice, página 74), foram detalhadas as tabelas
Usuário e Webcel.
2.2.5. Diagrama de Entidades e Relacionamento.
O DER (Apêndice, página 75), determina os relacionamentos entre as tabelas
caso existam, no caso deste projeto eles não existem.
27
O sistema funciona em um banco de dados e dentro dele tem uma tabela de
cadastro de usuários que é usado pelo site no gerenciamento do sistema permitindo
acesso ao usuário ou não na área restrita.
A senha do banco de dados permite acesso ao banco, senha do usuário
autentica o acesso a área restrita onde é feito o gerenciamento do cliente.
Optou-se por esta arquitetura pois assim facilitaria a instalação do sistema em
outros servidores, onde se poderá comercializar o sistema de várias formas, podendo
também simplesmente fornecer a licença de uso onde o cliente no caso, outro
representante, que usará o gerenciamento no servidor da WebCel, outra forma ainda
seria fornecer a licença de uso do sistema completo inclusive com site e banco de
dados, ou seja, pode se instalar o sistema num servidor do cliente juntamente com
site e banco de dados. Por fim também existe a possibilidade da adaptação do
gerenciamento no site do cliente acessando o banco de dados da WebCel.
28
3. RESULTADOS
O principal resultado obtido neste trabalho foi a redução da inadimplência dos
clientes, sendo que este era o objetivo principal do projeto, mas juntamente com ele
se conseguiu outros resultados importantes os quais são detalhados neste capítulo.
Inicialmente o aplicativo instalado no cliente tinha as informações de banco
de dados de controle, banco de dados principal, número de dias para bloqueio no
caso de falha na conexão com o servidor e endereço de conexão ao banco de dados,
ou seja, essas informações estavam no executável, isso fazia com que no caso de
testes, de representantes diferentes, ou mesmo na troca de qualquer uma dessas
informações, tinha de se gerar um novo executável, existia a necessidade de se
compilar um novo executável para o cliente causando muito trabalho. Com as
alterações, hoje as informações acima são armazenadas em um arquivo do tipo
“.DAT” desta forma o executável agora é o mesmo para todos os clientes e
representantes, pois ele não contém mais informações específicas. O número de dias
para bloqueio agora é configurado na instalação mas também pode ser alterado a
qualquer momento pelo usuário do sistema no ambiente de gerenciamento (Figura 10).
Figura 10 - Alterar dias para bloqueio automático
Inicialmente na instalação era configurado apenas o registro do cliente, agora
na instalação é executado um aplicativo temporário, (Figura 11), que permite entrar
com o registro, o nome do banco de dados de controle, o banco de dados principal, o
endereço de conexão do servidor e o número de dias para bloqueio no caso de falha
29
de conexão com o servidor. Este aplicativo depois de executado é excluído por isso
ele é tratado aqui como temporário.
Figura 11 - Tela executável temporário com os dados de configuração
Hoje ainda durante a instalação, também é criado um atalho para um
aplicativo que possibilita a liberação do sistema através de senha (Figura 12), esta
senha se altera todos os dias e é gerada pelo representante, ela deve ser usada apenas
em caso de necessidade de liberação do cliente e o mesmo esteja sem conexão com o
servidor. Esta ferramenta de desbloqueio não existia antes.
Figura 12 - Sistema de liberação com senha
30
O aplicativo principal instalado no cliente, o aplicativo de desbloqueio e o
aplicativo temporário foram desenvolvidos em C++ com algumas rotinas em C.
O site foi desenvolvido em PHP e HTML usando CSS para padronização de
telas, o site tem as páginas home, quem somos, nossa missão, produtos, área restrita e
fale conosco. Algumas delas são mostradas nas figuras 13, 14, 15 e 16.
Figura 13 - Site - Tela Home
Figura 14 - Site - Tela Quem Somos e Tela Missão
Figura 15 - Site - Tela Produtos e Tela Fale Conosco
31
Figura 16 - Site - Tela Cadastro de Registros
Todas as páginas cumprem com seu papel de forma simples e sucinta, mas
funcional pois o foco deste projeto está na área restrita já que é ali onde se tem o
gerenciamento do SisBloq, para se acessar esta área é solicitado um login e uma
senha sendo que esta senha é criptografada usando MD5 (Figura 17) e fica armazenada
já criptografada no BD. Todo envio de senhas é feito já criptografado para melhor
segurança. Na área restrita temos três funcionalidades (agenda, cadastro de usuários e
manutenção de registros) das quais apenas uma está liberada a usuários do sistema
(manutenção de registros), as outras duas estão disponíveis apenas a administradores
do sistema.
Figura 17 - Telas Entrar e Login
32
Figura 18 - Tela Área Restrita ADM
Figura 19 - Tela Área Restrita USU
A agenda é simples tem apenas nome, telefone e data de cadastro. Ela tem
duas páginas (Figura 20), uma para inclusão de novos registros e uma para manutenção
dos mesmos, onde qualquer um dos campos pode ser editado e salvo ou excluído.
O cadastro de usuários tem nome, senha, banco e tipo de usuário. Ele tem
duas páginas, uma para inclusão de novos registros e outra para manutenção dos
mesmos, onde qualquer um dos campos pode ser editado e salvo ou excluído.
Figura 20 - Telas Agenda
33
A manutenção de registros (Figura 18 e 19), tem registro, nome, status de uso,
status de bloqueio, data do status, data de cadastro e número de dias para bloqueio.
Trabalha com duas páginas principais, uma para inclusão de novos registros e outra
para manutenção dos mesmos, porém esta última é dividia em várias, ela se divide
automaticamente a medida de que é inserido novos registros, ela mantém apenas oito
registros por tela. Nela tem os seguintes botões de navegação, início, fim, avançar,
voltar e sair. (Figura 23). Nesta área os acessos são diferenciados de acordo com o tipo
de usuário, Os usuários podem alterar o nome, status de uso e o número de dias para
bloqueio, já os administradores podem alterar o registro, o nome, o status de uso e
número de dias para bloqueio e ainda excluir o registro. Na figura 22 temos exemplo
da diferença entre a mesma tela acessada por “USU” ou “ADM”. O fato de usuários
não poderem excluir os registros foi pensado considerando que podemos passar o
direito de uso do sistema a outras empresas de representação e assim pode-se cobrar
a mensalidade de uso considerando o número de registros controlados, desta forma
eles podem apenas incluir e alterar, mas a exclusão apenas pela WebCel poderia
fazer.
Figura 23 - Teclas de navegação
Figura 22 - Tela Manutenção Registro
Figura 21 - Telas Cadastro Usuários
34
4. DIFICULDADES ENCONTRADAS
Foi necessário mudar a ordem de alguns itens do cronograma, pois
determinadas implementações dependiam de outras para poderem ser testadas.
Como o sistema já existia após o termino de todas as implementações e
correções houve a necessidade de se instalar novamente a última versão em todos os
clientes.
Todos os fontes originais foram reescritos adequando o mesmo em funções e
rotinas que irão facilitar sua montagem futuramente orientado a objeto.
O sistema foi desenvolvido em C++ porém devido a restrições da linguagem
foi obrigado a se usar algumas funções do C.
Como a linguagem não disponibiliza rotinas prontas de cálculo de datas e
horas foram montadas uma estrutura e várias funções específicas para que se permita
estes tipos de cálculos.
Figura 24 - Struct data
Figura 25 - Função Identificação do ano bissexto
35
Figura 26 - Diferença entre datas
Figura 27 – Identificação da data atual
36
5. CONCLUSÕES
O resultado deste projeto foi satisfatório, pois o mesmo atingiu as
expectativas, todos os objetivos foram alcançados e ainda abriu caminho para novas
ideias a serem pesquisadas e colocadas em prática.
Com o projeto executado e em produção nos clientes se conseguiu reduzir a
inadimplência em 95% aproximadamente, mas isto aconteceu de forma gradual, já
que os clientes tinham uma cultura de pagamento atrasado ou acumulado das
mensalidades. Para conseguir mudar este cenário sem prejuízo e perda de clientes foi
necessário seguir alguns procedimentos. Primeiramente avisar aos clientes que o
bloqueio por atraso iria começar a ser efetuado, depois começar a bloquear quando
vencia a terceira mensalidade, com o passar do tempo começou-se a bloquear quando
vencia a segunda mensalidade e posteriormente começou-se a bloquear após vinte
dias de vencido a primeira mensalidade.
Com o sistema em funcionamento se percebeu algumas melhorias a serem
feitas e funcionalidades a serem implementadas.
Também foi verificado que este mercado pode ser interessante se feito algum
acordo com software house’s o que pode permitir que o sistema seja adequado para
ser usado por escritórios de representação de outros softwares que não apenas o
SysFar. Nas pesquisas que foram feitas não foi encontrado nenhum software neste
seguimento e também foi observado que a tendência do mercado é de que os
softwares trabalhem com a modalidade de venda de registros diretamente ao
representante que o comercializará diretamente com o consumidor final,
normalmente fazendo contratos de suporte mensal e sendo assim tendo a necessidade
de uso do SisBloq ou de outro sistema com a mesma finalidade.
37
6. REFERÊNCIAS BIBLIOGRÁFICAS
WAZLAWICK, Raul Sidnei, 2011. Análise e Projeto de Sistemas de Informação
Orientados a Objetos. 2ª Edição. Rio de Janeiro: Editora Campus.
GUEDES, Gilleanes T. A., 2011. UML2 Uma Abordagem Prática. 2ª Edição. São
Paulo: Editora Novatec.
BRASIL. Lei Carolina Dieckmann (lei Nº12.737, de 30 de novembro de
2012). Disponível em http://www.planalto.gov.br/ccivil_03/_ato2011-2014/2012/lei/
l12737.htm (acessado em 18 de janeiro de 2015).
NASCIMENTO, Rafael Jullian Oliveira. Ferramenta RE-Tools para elicitação de
requisitos (de 13 de janeiro de 2015). Disponível em http://www.devmedia.
com.br/ferramenta-re-tools-para-elicitacao-de-requisitos/31990 (acessado em 17 de
janeiro de 2015). 2015.
SPINOLA, Rodrigo. LEAL, Ayala. MACÊDO, Ana Bárbara Lins de. Introdução
sobre UML: Mecanismos gerais - Revista SQL Magazine 91. Disponível em
http://www.devmedia.com.br/introducao-sobre-uml-mecanismos-gerais-revista-sql-
magazine-91/22261
SPÍNOLA, Rodrigo Oliveira. Diagrama de Casos de Uso na prática. Disponível em
http://www.devmedia.com.br/curso/diagrama-de-casos-de-uso-na-pratica/312
(acessado em 24 de janeiro de 2015).
FIGUEIREDO, MSc. Karen. UML e Diagramas de Casos de Uso. In: APSI-1
(Análise e Projeto de Sistema de Informação 1). 2013.
SILVA, Maurício Samy. Tutoriais CSS, Web Standards, Acessibilidade, HTML,
XHTML e Padrões Web. Disponível em http://www.maujor.com/index.php
(acessado em 27 de janeiro). 2003.
W3SCHOOLS.COM. CSS Tutorial. Disponível em http://www.w3schools.com/css/
css3_intro.asp (acessado em 28 de janeiro 2015).
38
7. APÊNDICES E/OU ANEXOS
7.1. APÊNDICE – Projeto SISBLOQ.
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
