universidade tecnolÓgica federal do paranÁ …cristina/autodoc.pdf · sarita alves de souza...
TRANSCRIPT
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ DEPARTAMENTO ACADÊMICO DE INFORMÁTICA
CURSO DE TÉCNOLOGIA EM INFORMÁTICA
SARITA ALVES DE SOUZA WILLIAN HIDEO SAIZAKI
PROJETO AUTODOC
Trabalho de Conclusão de Curso
Curitiba 2009
SARITA ALVES DE SOUZA WILLIAN HIDEO SAIZAKI
PROJETO AUTODOC
Trabalho de Conclusão de Curso, apresentado à disciplina de Trabalho de Diplomação, do curso superior de Tecnologia em Informática do Departamento Acadêmico de Informática – DAINF – da Universidade Tecnológica Federal do Paraná – UTFPR, como requisito parcial para obtenção do título de Tecnólogo.
Orientadora: PROFESSORA ANA CRISTINA B. KOCHEM VENDRAMIN.
Co–orientador: PROFESSOR WILSON HORSTMEYER BOGADO.
Curitiba 2009
TERMO DE APROVAÇÃO
SARITA ALVES DE SOUZA WILLIAN HIDEO SAIZAKI
TÍTULO DO TRABALHO
PROJETO AUTODOC
Trabalho de Conclusão de Curso aprovado como requisito parcial à
obtenção do grau de TECNÓLOGO EM INFORMÁTICA, do Departamento
Acadêmico de Informática, pelos alunos SARITA ALVES DE SOUZA E
WILLIAN HIDEO SAIZAKI, da Universidade Tecnológica Federal do Paraná
– Campus Curitiba, pela seguinte banca examinadora:
Membro 1 –
Departamento Acadêmico de Informática (UTFPR)
Membro 2 – Departamento Acadêmico de Informática (UTFPR)
Orientadora: Profª. ANA CRISTINA BARREIRAS KOCHEM VENDRAMIN Departamento Acadêmico de Informática (UTFPR)
Co-orientador: Prof. WILSON HORSTMEYER BOGADO Departamento Acadêmico de Informática (UTFPR)
Curitiba 2009
A dedicação deste trabalho será para todos os pais, que se fazem presentes na vida de seus filhos e com o excesso de
amor, os tornam esperançosos por serem "grandes" e de quererem correr riscos, com a certeza de vencerem no final.
AGRADECIMENTOS
Aos nossos pais, por todo o feito por nós até hoje. À Professora Ana Cristina Barreiras Kochem Vendramin, pelo apoio e
paciência na orientação do trabalho. Aos amigos que, acreditaram, ouviram e opinaram.
Resumo
O objetivo deste trabalho de graduação é implementar um software
destinado a otimizar a rotina de trabalho do setor de documentação de
softwares de uma empresa que desenvolve e presta manutenção na área de
softwares financeiros. Optou-se por uma interface gráfica desenvolvida com
o auxílio das pessoas que trabalham no setor responsável pela
documentação. A metodologia para o desenvolvimento do programa foi
adotada de acordo com os padrões utilizados na empresa, que vão desde
padrões para nomenclatura de componente até formatações próprias de
código fonte. O software obtido atende todos os requisitos necessários para
facilitar a rotina de trabalho das pessoas envolvidas no processo da
documentação. Ao final são feitas sugestões para continuidade desse
trabalho, que ainda poderá ser aperfeiçoado com funcionalidades mais
sofisticadas.
Palavras chaves: Delphi, documentação de software, manuais de sistemas,
software.
Abstract
This project presents the development of software to optimize the
routine work of the sector of documentation for a software company that
develops and provides maintenance in the area of financial software. It opted
for a graphical user interface developed with the help of people working in
the sector responsible for documentation. The methodology for the
development of the program was adopted in accordance with the standards
used in the company, ranging from standards for naming components to
source code formatter. The software which meets all the requirements
necessary to facilitate the routine work of the people involved in the process
of documentation. At the end are suggestions for continuing this work, which
can still be improved with more sophisticated features.
Keywords: Delphi, software documentation, manuals, systems, software.
LISTA DE FIGURAS
Figura 1. Primeira versão do sistema. ......................................................... 30
Figura 2. GERADICDAD(Windows Explorer) ............................................... 31
Figura 3. Código fonte de cabeçalho padrão. .............................................. 32
Figura 4. GERADICDAD dos programas. .................................................... 33
Figura 5. GERADICDAD das stored procedures. ........................................ 34
Figura 6. AUTODOC na versão com aplicação do Skin. ............................. 37
Figura 7. MIT dos programas. ...................................................................... 38
Figura 8. MIT das stored procedures. ......................................................... 39
Figura 9. MIT – capa do documento ........................................................... 41
Figura 10. MIT – Tabelas do sistema ......................................................... 41
Figura 11. MIT – Views do sistema ............................................................. 42
Figura 12. Ambiente de desenvolvimento da aplicação. ............................ 43
Figura 13. Explicação do funcionamento do sistema. ................................ 44
Figura 14. MIT gerado de forma manual. ................................................... 46
Figura 15. MIT gerado de forma automática pelo AUTODOC .................... 47
Figura 16. Tela de ajuda do sistema........................................................... 47
Figura 17. Sistema em funcionamento com barra de progressos. ............. 48
Figura 18. Sistema com os Logs de erros e/ou exceções geradas ............ 48
Figura 19. Diagrama de Classes ................................................................ 49
Figura 20. Diagrama de Casos de Uso ....................................................... 50
Figura 21. Diagrama de seqüência ............................................................. 54
Figura 22. MIT do sistema TOOLS antes do AUTODOC ........................... 58
Figura 23. MIT do sistema TOOLS depois do AUTODOC ......................... 58
LISTA DE TABELAS
Tabela 1. Configuração das estações de trabalho. ..................................... 22
Tabela 2. Recursos de softwares. ............................................................... 24
Tabela 3. Principais funções e procedimentos.............................................26
Tabela 4. Descrição do caso de uso Abrir Arquivo ...................................... 51
Tabela 5. Descrição do caso de uso Fechar sistema .................................. 51
Tabela 6. Descrição do caso de uso Gerar metadado ................................ 51
Tabela 7. Descrição do caso de uso abrir help ............................................ 52
Tabela 8. Descrição do caso de uso construir documento: ......................... 52
Tabela 9 – Descrição do caso de uso construir documento: ....................... 53
Tabela 10 – Descrição do caso de uso construir documento: MIT .............. 53
LISTA DE SIGLAS
AUTODOC: Automatização da Documentação.
DFM: Delphi Form File.
GERADICDAD: Gerador dos Dicionários de Dados.
MIT: Manual de Informações Técnicas.
PAD: Padrões Avançados de Desenvolvimento.
PDF: Portable Data Format.
RTF: Rich Text Format.
STP: Stored Procedure.
SQL: Structured Query Language
UDL: Universal Data Link
SUMÁRIO
1 INTRODUÇÃO ........................................................................................ 13
1.1 APRESENTAÇÃO ............................................................................ 13
1.2 JUSTIFICATIVA ................................................................................ 14
1.3 OBJETIVOS ...................................................................................... 14
1.4 ORGANIZAÇÃO DO DOCUMENTO ................................................. 15
2 A EMPRESA ........................................................................................... 16
2.1 A SOFTPARANÁ .............................................................................. 16
2.2 A EMPRESA ANTES DO SISTEMA ................................................. 16
2.3 A EMPRESA DEPOIS DO SISTEMA ............................................... 17
3 SISTEMAS DE DOCUMENTAÇÃO ........................................................ 18
3.1 PORQUE DOCUMENTAR? .............................................................. 18
3.2 O MERCADO X AUTODOC.............................................................. 18
3.3 AUTODOC - VANTAGENS X DESVANTAGENS ............................. 19
4 METODOLOGIA ..................................................................................... 22
4.1 METODOLOGIA - REQUISITOS ...................................................... 22
4.1.1 LEVANTAMENTO DE REQUISITOS .......................................... 23
4.1.2 RECURSOS - FINANCEIROS, PESSOAL E SOFTWARE ........ 24
4.2 METODOLOGIA – CÓDIGO FONTE ............................................... 25
4.3 PESQUISAS ..................................................................................... 28
4.4 O SISTEMA – GERADICDAD .......................................................... 29
4.5 O SISTEMA – MIT ............................................................................ 35
4.6 O SISTEMA – FUNCIONAMENTO ................................................... 43
5 RESULTADOS ....................................................................................... 46
5.1 CONTEÚDO DOS RESULTADOS ................................................... 46
5.2 MODELAGEM ................................................................................... 49
5.3 TESTES - IMPLEMENTAÇÃO, INTEGRAÇÃO E IMPLANTAÇÃO . 55
5.4 DISCUSSÃO ..................................................................................... 57
6 CONCLUSÕES ....................................................................................... 60
6.1 CONTRIBUIÇÕES ............................................................................ 60
6.2 TRABALHOS FUTUROS .................................................................. 61
13
1 INTRODUÇÃO
O projeto AUTODOC (Automatização da documentação) destina-se à
automatização da documentação, tema escolhido devido ao grande trabalho
manual que ocorria no setor de documentação da empresa SOFTPARANÁ.
Ao acompanhar a rotina do setor foi possível notar a necessidade de se
desenvolver um software que visa a otimizar os processos realizados
manualmente o que demanda um tempo elevado dos funcionários. Os
métodos utilizados para criação deste software estão descritos ao longo do
trabalho, pois envolvem várias ferramentas. As pesquisas para elaboração
do trabalho foram destinadas, em sua maioria, ao tratamento da
performance do sistema, geração da interface e não envolveram a definição
das ferramentas mais apropriadas para o desenvolvimento do sistema. Por
tratar-se de uma empresa que já possui licenças de softwares, não foi
possível alterar a escolha da linguagem de programação Delphi para outra,
por exemplo, Java.
1.1 APRESENTAÇÃO
O foco deste trabalho está em automatizar processos efetuados de
forma manual para elaboração de manuais de softwares e auxílio para os
programadores da empresa SOFTPARANÁ. Para desenvolver esse sistema
foram definidas algumas fases juntamente com a coordenação do projeto na
empresa, sendo que cada fase depende da outra para dar início:
1º - Desenvolvimento do GERADICDAD (gerador dos dicionários de
dados): ferramenta que fará a geração automática de uma planilha em Excel
que conterá todos os dados sobre o sistema escolhido.
2º - Geração do GERADICDAD dos programas (Delphi; FLEX e NET);
3º - Geração do GERADICDAD das STP (Stored Procedures);
4º - Pesquisa: levantamento da melhor forma de saída dos dados (doc,
pdf, etc.) do MIT (Manual de Informações Técnicas) como um todo.
5º - Geração do MIT dos programas de cada sistema (Delphi).
6º - Geração do MIT das stored procedures de cada sistema.
14
7º - Geração do MIT das views e de todas as tabelas de cada sistema.
8º - Testes e ajustes.
1.2 JUSTIFICATIVA
Muitos dos trabalhos acadêmicos são baseados em pesquisas e
estudos de determinadas tecnologias que muitas vezes acabam não sendo
implementados na prática por vários motivos, que vão desde a falta de
informações sobre novas tecnologias até a falta de dados reais sobre
determinados assuntos. O que tornou empolgante ao optar pelo
desenvolvimento do AUTODOC foi exatamente essa diferença, ou seja, foi à
idéia de se trabalhar em um projeto real que trará grandes ganhos para a
carreira, pois os autores participarão de todos os processos relacionados à
criação de softwares e não estarão supondo quais seriam os problemas
enfrentados nesse processo e sim a vivência de cada etapa relacionada.
1.3 OBJETIVOS
O objetivo principal do projeto AUTODOC é automatizar os processos
manuais efetuados no setor de documentação e conseqüentemente no
setor de desenvolvimento. Com o AUTODOC as pessoas envolvidas no
processo de documentação não farão mais pesquisas de forma manual para
buscar dados úteis no preenchimento dos manuais dos sistemas da
empresa e os programadores terão informações úteis de forma mais rápida
e de fácil acesso.
A SOFTPARANÁ desenvolve grande parte de seus sistemas utilizando
a linguagem Delphi. Atualmente vários sistemas que a empresa possui já
em funcionamento e uso dos clientes estão em Delphi 2006. Tendo em vista
atualizações para um melhor acompanhamento de novas tecnologias a
empresa está em processo de migração de todos seus sistemas para Delphi
2007, processo que é demorado devido a vários fatores que vão desde a
quantidade de sistemas da empresa até a quantidade de clientes que
utilizam tais sistemas. Por esses motivos o AUTODOC foi prontamente
15
implementado em Delphi 2007. Esse sistema está disponível somente no
servidor de aplicação da empresa. Sendo assim, todos os programadores
que irão desenvolver sistemas em Delphi 2007 precisarão acessar o
servidor de aplicação a partir de seus micros para então implementar seus
projetos, tendo por objetivo atender às necessidades da empresa e se
adequar aos processos que visa a melhorias constantes.
1.4 ORGANIZAÇÃO DO DOCUMENTO
Este trabalho está dividido em seis capítulos, sendo que neste estão
os objetivos, a justificativa e a apresentação do trabalho. No segundo
capítulo consta a apresentação da empresa contratante do projeto
AUTODOC. O terceiro capítulo apresenta vantagens e desvantagens do
AUTODOC em relação a outros sistemas no mercado como efeito de
comparação. Em seguida, há no quarto capítulo informações sobre as
etapas e os métodos utilizados na pesquisa e levantamento de requisitos, a
concepção da interface gráfica, o desenvolvimento da programação e os
testes do sistema. O quinto capítulo expõe as análises e os resultados
obtidos após a aplicação do software desenvolvido, juntamente com as
discussões relacionadas a todo o projeto. No sexto capítulo consta a
conclusão do trabalho realizado. Por fim, são listadas as sugestões para
trabalhos futuros e as referências utilizadas na realização do trabalho.
16
2 A EMPRESA
2.1 A SOFTPARANÁ
Este capítulo apresenta a empresa SOFTPARANÁ e o papel do
sistema na melhoria dos processos.
A SOFTPARANÁ é uma empresa brasileira com mais de 28 anos de
experiência e atuação direcionada para o mercado financeiro. Hoje atende
mais de 30 instituições integrando de maneira ágil e inteligente seus dados
financeiros, possibilitando uma gestão de controle gerando maior
produtividade e otimização nas vendas. A importância da área de
documentação na empresa é um grande diferencial da SOFTPARANÁ que
mantém uma equipe de documentação atuando em conjunto com as outras
áreas técnicas da empresa, participando de todas as etapas de
desenvolvimento de sistemas, desde a concepção até as fases finais de
implementação, disponibilizando em conjunto com os aplicativos os manuais
de utilização específicos. Adicionalmente, são atualizadas todas as
documentações para uso interno das equipes de manutenção. Quando há
atualizações no sistema devido a exigências legais ou avanço tecnológico
nos softwares, toda a documentação é também atualizada e distribuída com
a nova versão do sistema, além de manter toda a documentação disponível
para acompanhamento de seus clientes em seu site de maneira restrita a
cada usuário. Por esses motivos o papel do AUTODOC na empresa é de
extrema importância.
2.2 A EMPRESA ANTES DO SISTEMA
Antes da implementação do projeto AUTODOC os processos mais
importantes na geração de manuais do sistema eram feitos de forma
manual causando um gasto de tempo elevado dos funcionários da área.
17
A cada atualização da documentação de determinado software
desenvolvido pela empresa era necessário um grande processo manual
para atualizar o Help do sistema. Por exemplo, se um programador inclui a
um novo parâmetro de entrada em uma STP era necessário atualizar o MIT
do software ao qual essa STP pertencia e isso era feito abrindo um
programa licenciado chamado Help & Manual – localizando essa STP
abrindo a tabela do MIT e fazendo a alteração manual. Com o sistema
AUTODOC isso não é mais necessário, pois a pessoa responsável por essa
atividade irá clicar em um botão que irá gerar esse MIT de forma automática
e atualizada. Ou seja, algumas funcionalidades do programa Help & Manual
não serão mais usadas e provavelmente no futuro não será mais necessário
pagar a licença desse programa. Essa operação acontece várias vezes ao
dia, mesmo porque há atualização quase diária principalmente de stored
procedures, tabelas, e views. Todo esse processo será automatizado pelo
AUTODOC e GERADICDAD.
2.3 A EMPRESA DEPOIS DO SISTEMA
Com toda a facilidade que o sistema proporciona à área da
documentação os benefícios são imensos, principalmente em relação ao
tempo gasto pelos funcionários para gerar os manuais. Outro benefício que
o projeto AUTODOC propicia, está relacionado com a confiança e
segurança dos manuais, por serem gerados de forma automática menos
erros humanos ocorrerão além de possibilitar uma conferência no trabalho
dos programadores da empresa a partir de Logs gerados pelo sistema e as
consistências exigidas para geração desses documentos de forma
automatizada.
18
3 SISTEMAS DE DOCUMENTAÇÃO
3.1 PORQUE DOCUMENTAR?
Paulino Michelazzo (2006) destaca que a documentação de software,
mesmo sendo um trabalho a mais para qualquer desenvolvedor, é
extremamente necessária e auxilia na redução de horas preciosas na
correção de problemas. Para muitos desenvolvedores, a criação de
documentação técnica é a parte mais aterrorizante para se enfrentar em
todo o processo de criação de um software, seja pela necessidade de
escrever várias e várias páginas de texto, gráficos e desenhos ou ainda pela
necessidade de largar aquilo que se aprendeu (programar) para fazer aquilo
que não se sabe bem (redigir).
Entretanto a documentação é parte integrante de qualquer sistema ou
programa criado. É tão importante inclusive por questões de segurança, pois
sem a devida documentação, bugs e pontos vulneráveis no sistema
demoram a ser encontrados e corrigidos.
Normalmente existem pessoas e/ou equipes voltadas única e
exclusivamente para a criação de documentação, como é o caso da
SOFTPARANÁ, sendo que o desenvolvedor fica restrito à codificação e
comentários de seu código. A necessidade de se documentar na empresa é
tratada com muita seriedade não só pela sua importância, mas também por
um diferencial competitivo.
3.2 O MERCADO X AUTODOC
Atualmente é possível encontrar no mercado sistemas que auxiliam na
documentação de software como é o caso do Help & Manual, sistemas que,
segundo a EC Software, é capaz de gerar menus de ajuda e, além disso, a
ferramenta permite inserir dicas para ajudar o usuário a utilizar o programa.
Contudo tem como limitação ser licenciado e a cada atualização do manual
levar um tempo, dependendo do tamanho do manual, próximo de 20
19
minutos para se recompilado, além de não ser completamente adequado às
necessidades da empresa, fato que torna o AUTODOC único e exclusivo. O
sistema foi criado especificamente para atender as necessidades da
empresa.
3.3 AUTODOC - VANTAGENS X DESVANTAGENS
A maioria das empresas busca com o uso da tecnologia da
informação, aumentar receitas, reduzir custos, melhorar o atendimento aos
seus clientes e fornecedores e principalmente obter um diferencial
competitivo que gere fidelidade e satisfação nos seus clientes preferenciais.
Há também a intenção, com o uso da tecnologia da informação, de
estruturar e automatizar seus processos internos, de forma que possa
realizar negócios sem a necessidade de uma pessoa do outro lado da
empresa, integrando com isto, seus clientes e fornecedores, em processos
automatizados.
Sistemas tradicionais de tecnologia da informação melhoram a
qualidade das informações e aumentam a produtividade, mas sozinhos, não
conseguem gerar todos os benefícios acima descritos.
Como as pessoas trabalham com documentos, relatórios e rotinas
manuais, de nada adianta ter um sistema de última geração se, ao
necessitar um documento, a pessoa é obrigada a interromper a tarefa,
dirigir-se a um arquivo em papel, procurar um documento, tirar uma cópia,
enviar por malote, e-mail, fax, etc. É bastante evidente que, de forma geral,
as empresas utilizam o documento em papel de forma intensiva gerando:
• Ocupação de espaço nobre para guarda dos documentos em papel;
• Utilização de tempo de funcionários graduados do departamento para
realizar tarefas de guarda e recuperação de documentos no arquivo;
• Conhecimento da localização dos documentos limitado às pessoas
que manuseiam o arquivo/armário;
20
Com tudo isto, é natural que as empresas estejam procurando soluções
para substituir a consulta e o manuseio do documento em papel pelo
documento digital. E, por esses motivos a SOFTPARANÁ faz questão de ter
como diferencial uma metodologia própria para facilitar a geração dos
manuais de seus sistemas.
É aí que entra o AUTODOC que permite:
• Consulta on-line documentos digitais na tela do micro;
• Eliminação do trabalho e dos controles associados à solicitação de
envio/recebimento e devolução dos documentos em papel (malote,
expedição, fax, cópias, distribuição, protocolo);
• Liberação de espaço físico nos departamentos, pois os documentos
poderão ser enviados para um arquivo uma vez que sua consulta
estará disponível on-line, a qualquer instante, através do próprio
micro do usuário;
• Aumento do controle da documentação;
• Consultas simultâneas ao mesmo documento;
• Substituição do malote tradicional pelo malote digital;
• Consulta aos documentos na intranet/Internet;
• Consulta aos documentos em CD;
• Aumento da confiabilidade nas informações que sempre estarão
atualizadas.
As consultas aos documentos em papel poderão até continuar
existindo nas empresas, em situações necessárias, em regime de exceção.
Desta forma, automatizar os documentos é um passo importante para
as empresas obterem aumentos de controle e padronização, redução de
custos, melhoria no atendimento aos clientes e fornecedores, diferencial
21
competitivo.
O AUTODOC traz esses benefícios e seu principal diferencial dos
demais softwares de documentação existente no mercado está em ser
destinado a SOFTPARANÁ, ou seja, sua exclusividade é sua limitação.
Adiante poderá ser estudado para venda, porém atualmente seu uso é
exclusividade da empresa, visto que seu desenvolvimento foi elaborado de
acordo com os padrões, normas e necessidades da empresa.
22
4 METODOLOGIA
4.1 METODOLOGIA - REQUISITOS
Os métodos utilizados para o desenvolvimento do projeto estão de
acordo com os PAD (Padrões Avançados de Desenvolvimento) que a
empresa utiliza. Os PAD seguem altos padrões de desenvolvimento de
sistemas. Os materiais usados estão desde manuais de componentes
comprados pela empresa como, por exemplo, o WpTools, que se trata de
uma biblioteca usada em Delphi que permite, entre outras funcionalidades, a
exportação de documentos para PDF e RTF, para isso utilizamos o manual
do componente(Julian Ziersch) . Outras metodologias seguem exemplos de
revistas, como o Clube do Delphi, usada na empresa como fonte de
pesquisa. Quanto à questão de equipamentos utilizados no trabalho, há dois
computadores com configurações apresentadas conforme a Tabela 1.
Tabela 1. Configuração das estações de trabalho. ESTAÇÃO CONFIGURAÇÃO
SARITA
Descrição : Equipamento Desenvolvimento (Sarita Alves de
Souza)
Sistema Operacional: Microsoft Windows XP Professional
Service pack: Service Pack 3
Memoria: 959 MB
Processador type: AMD Sempron(tm) Processor 3000+
Velocidade Clock: 1795 Mhz
WILLIAN
Descrição : Equipamento Desenvolvimento (Willian Saizaki)
Sistema Operacional: Microsoft Windows XP Professional
Service pack: Service Pack 2
Memoria: 959 MB
Processador : AMD Sempron(tm) Processor 3000+
Velocidade Clock: 1795 Mhz
23
4.1.1 LEVANTAMENTO DE REQUISITOS
Os requisitos para geração do sistema AUTODOC estão divididos em
funcionais e não-funcionais:
REQUISITOS FUNCIONAIS � O software deve possuir uma interface de fácil acesso e de uso
simples, pois sua finalidade é auxiliar os processos de documentação
de softwares da empresa de forma ágil sendo possível ser gerada por
qualquer nível de usuário;
� O sistema deve mostrar os arquivos que constam na pasta “caminho
destino” no caso do MIT será “MITSource” e “DicDadSource” para o
GERADICDAD, ou seja, onde o arquivo deverá ser salvo, pois dessa
forma é possível saber qual versão do arquivo, se está ou não
atualizada além de ter informações como data e hora da criação do
arquivo e seu tipo;
� Ao ser gerado um arquivo com o mesmo nome (processo feito de forma
automática), este deve ser sobreposto e se estiver em uso o usuário
deve ser notificado antes de gerá-lo, caso contrário é sobreposto;
� O sistema deve estar acessível a todos na empresa não necessitando
de autenticação para acesso;
� O sistema deve fazer a nomenclatura dos arquivos gerados de forma
automática e de acordo com os padrões adotados pela empresa;
� O sistema deve criar as pastas de destinos de forma automática caso
elas não existam ainda na estrutura de pasta;
� O GERADICDAD deve funcionar em modo texto;
� O sistema deve gerar Log apresentando inconsistência na geração dos
arquivos tanto do MIT quanto do GERADICDAD para finalidade de
correções por parte da equipe de desenvolvimento ou banco de dados;
� O sistema deve permitir atualizar o metadado do arquivo;
� O sistema deve manter uma lista do caminho origem com os últimos 5
caminhos digitados pelo usuário.
24
REQUISITOS NÃO-FUNCIONAIS � O sistema não fará o MIT dos sistemas em FLEX e NET;
� O sistema servirá para uso exclusivo da empresa, pois está programado
para atender as necessidades da empresa e adequado a seus padrões;
� O GERADICDAD não irá gerar arquivo em Excel sobre tabelas e views
dos sistemas;
� O sistema não fará tratamento de acesso de usuários;
� O sistema não funcionará em local que não tenha a estrutura de pastas
necessárias para consistência de dados buscados para geração dos
arquivos desejados.
4.1.2 RECURSOS - FINANCEIROS, DE PESSOAL E SOFTWARE
Os recursos financeiros utilizados para a geração do sistema
AUTODOC são investimento da SOFTPARANÁ que fez a contratação,
como estagiários, dos autores do projeto tendo a finalidade de desenvolver
o projeto AUTODOC, sendo os autores os recursos humanos utilizados
além da orientação do coordenador do projeto da empresa. O estágio está
adequado conforme contrato emitido pela UTFPR. Em nível de software,
para melhor entendimento será apresentada abaixo a Tabela 2 com o nome
e a finalidade de todos os softwares usados para geração do AUTODOC,
desde sua concepção até sua documentação através desse trabalho escrito.
Tabela 2. Recursos de softwares.
Lista de Softwares
Delphi 7 IDE (ambiente integrado para desenvolvimento de
software) usada para desenvolver o AUTODOC.
SubVersion Sistema que permite o controle de versão e
publicação do projeto no ambiente de produção.
SGA Sistema de gerenciamento de atividades criado
pela SOFTPARANÁ com a finalidade de gerenciar
recursos humanos.
25
Office comunicator Ferramenta que permite a comunicação instantânea
entre os funcionários da empresa.
Microsoft Office
Outlook
Sistema de correio eletrônico para recebimento de
e-mails relacionados ao trabalho da empresa.
PAD Sistema de manual que permite o conhecimento de
toda padronização adotada pela empresa.
4.2 METODOLOGIA – CÓDIGO FONTE
Nessa seção é explicado como está implementado o código fonte e
quais são as metodologias aplicadas, além de maiores detalhes sobre as
principais funções aplicadas para geração do AUTODOC.
Na Tabela 3 estão listadas as principais funções do sistema, com sua
nomenclatura e descrição.
26
Tabela 3. Principais funções e procedimentos
Funções/ Procedimentos Descrição da funcionalidade
FncGeraExcel Função responsável pela geração do arquivo
no formato Excel, que recebe como parâmetros
os arquivos, a descrição dos arquivos e o tipo.
Essa função é usada somente para o
GERADICDAD e seu tipo passado por
parâmetro pode ser Delphi, DSQL, FLEX e.
Net. (Studiebureau Festraets)
ProAtuProgresso Procedimento usado para fazer o tratamento da
atualização da barra de progresso usada na
interface do programa.
ProCriaArquivoLog Procedimento usado para criação do arquivo
que contém o Log com os erros ou informações
da consistência gerada pelo programa.
FncCriaDirPadraoDicDad Função booleana que verifica a existência do
diretório usado como padrão para geração do
arquivo GERADICDAD, resultando verdadeiro
ou falso. O diretório padrão é:
X:\TI\DicDadSource\ (RIBEIRO, PAULO
HENRIQUE)
FncCriaDirPadraoMIT Função booleana que verifica a existência do
diretório usado como padrão para geração do
arquivo GERADICDAD, resultando verdadeiro
ou falso. O diretório padrão é
X:\TI\MITSource\ (RIBEIRO, PAULO
HENRIQUE)
ProGeraNomeArquivo Procedimento que tem como parâmetros o tipo
opção e o formato do arquivo com a finalidade
de gerar o nome do arquivo fazendo o
tratamento para o GERADICDAD e MIT.
27
ProGravaLog Esse procedimento é iniciado chamando a
função que cria o arquivo de Log
(ProCriaArquivoLog) e tem como parâmetros
as mensagens. a data do tipo boleano e os
avisos que serão mostrados e tem a finalidade
de gravar as mensagens com esse parâmetro
no arquivo.
ProOrdenaArqFlex
ProOrdenaArqNet
ProOrdenaArqPas
Recebe como parâmetro uma string list para
tratamento relacionado à ordenação dos tipos
de arquivos passados como parâmetros ao ser
chamada.
FncProcuraArquivos Função que retorna verdadeiro ou falso caso
localize ou não os arquivos buscados de
acordo com os parâmetros passados que são
os arquivos, a descrição, a extensão, o
caminho do filtro, o tipo da descrição procurada
e se atualiza ou não a barra de progresso.
FncProcuraDescricao Função usada para retornar a descrição de um
arquivo e se encontrar guarda em uma lista de
strings para serem tratadas.
ProSplit Procedimento usado para fazer a quebra de
uma string, faz a quebra a partir do delimitador
e pode salvar em nova string list com ou sem
espaços conforme parâmetro setado.
FncValidaCaminho Função do tipo booleana que faz a conferência
do caminho origem selecionado como filtro para
geração da documentação.
FncVerificaCorporativo Função que verifica se arquivo passado como
parâmetro é ou não do corporativo da empresa
com a finalidade de tratar esse tipo de arquivo
com formatação diferenciada desde sua
ordenação até sua formatação.
28
ProCriaDoc Procedimento responsável por fazer a criação
do arquivo Rich Text formatado.
ProPulaLinhaTabela Procedimento responsável por pular linhas ao
finalizar a tabela e permitir que documento seja
formatado de acordo com os padrões.
FncGeraRTF Função responsável pela geração do arquivo
no formato RTF, que recebe como parâmetros
os arquivos, a descrição dos arquivos e o tipo.
Essa função é usada somente para o MIT e
seu tipo passado por parâmetro pode ser
Delphi, DSQL, Tabelas e Views.
ProBuscaSenhaBase Procedimento utilizado para identificar qual é a
senha da base para efetuar a conexão através
dos arquivos UDL, além de obter o código do
sistema selecionado. Ex: Cadastro – CD - 01
4.3 PESQUISAS
Como é um diferencial na empresa manter todos os manuais de todos
os sistemas atualizados e completos, foi estudada e melhor forma de
visualização desses dados para o cliente tendo em vista a otimização de
recursos. O projeto foi elaborado de forma a facilitar o dia-a-dia da área de
documentação e dos programadores da empresa, pois com o programa
AUTODOC é possível ter acesso de forma mais rápida a informações que
são essenciais no dia-a-dia tanto dos programadores quanto da
documentação.
As pesquisas realizadas para a implementação do AUTODOC estão
em nível de experiência obtida principalmente pela área de documentação,
que consistem no entendimento dos processos realizados para se criar um
manual de sistema, desde qual software é utilizado, se é necessária licença,
entre outros processos. Para auxílio na implementação houve necessidade
29
de se pesquisar sobre o funcionamento de determinadas ferramentas como,
por exemplo, o WPTools, que permite a geração de arquivos com os
formatos pretendidos além de um estudo para aplicação de Skins que têm a
finalidade de se obter uma interface mais harmônica para o sistema. Essas
pesquisas foram baseadas em experiência de trabalhos anteriores
desenvolvidos na empresa, além do próprio manual do WPTools (Julian
Ziersch) e respeito às questões de padronização adotadas pela empresa.
Para a definição da interface do sistema foi definido um levantamento de
opiniões juntamente com a área de documentação na empresa, que fará
uso do sistema. Logo, ficou decidida à interface conforme Figura 6, pois esta
interface permite um uso de forma mais rápida do sistema. A proposta inicial
era colocar os itens em forma de menu, porém a área de documentação e
desenvolvimento sentiu mais facilidade e rapidez com a interface contendo
todas opções em uma única tela. Outras pesquisas necessárias para auxílio
na elaboração do projeto foram em nível de padrões da empresa, pois há
padrão para tudo, desde nome de componentes até nomes de rotinas de
programação e com base em experiências anteriores essas questões foram
corrigidas ao longo do desenvolvimento do projeto.
Um levantamento de informações mostrou que para a saída do MIT, a
maioria dos manuais atualmente está disponível em documentos no
formado PDF (Portable Data Format). Logo, foi decidido fazer o MIT em
PDF e em RTF (Rich Text Format) que é um tipo de documento genérico
que pode ser aberto em qualquer programa que não necessite de licença,
além de poder ser editado com facilidade.
4.4 O SISTEMA – GERADICDAD
A implementação do sistema AUTODOC, de acordo com a primeira
fase do trabalho, foi iniciada com o desenvolvimento do módulo do sistema
chamado GERADICDAD. Essa opção foi escolhida devido a questões de
prioridades definidas pela coordenação do projeto na empresa. A interface
inicial do programa foi criada de forma mais fácil para se trabalhar no seu
30
desenvolvimento, especialmente para testes, ou seja, nesse início não foi
efetuada uma pesquisa junto à área interessada para concluir que essa
fosse a melhor interface. A seguir a Figura 1 ilustra a primeira versão do
sistema.
Figura 1. Primeira versão do sistema.
A finalidade do GERADICDAC é gerar um arquivo em formato Excel,
com a relação de todos os códigos-fontes (Delphi, FLEX, NET ou SQL)
contidos na pasta ''Caminho origem'' e gravar no título do arquivo a
descrição do módulo contido no código fonte. Para visualizar o título do
arquivo, é necessário clicar com o botão direito do mouse na pasta desejada
e selecionar Exibir -> Detalhes. Depois se deve clicar com o botão direito do
mouse sobre as colunas e selecionar para mostrar o título do arquivo, que
aparecerá conforme ilustra a Figura 2.
31
Figura 2. GERADICDAD (Windows Explorer)
Nessa figura temos todos os fontes visualizados pelo Windows
Explorer de um sistema em Delphi 2007, nesse caso é o chamado Sistemas
Internos que recebe o código, de acordo com os padrões da empresa, de
“D90S” na pasta Source, nela pelo que o GERADICDAD criou pode-se
ordenar por título a visualização. Conforme exemplo, é possível saber que a
tela “D90SF03J” é uma tela de “Manutenção de tipo de ocorrência de uma
OS” sem precisar abrir o Delphi ou algum visualizador para obter essa
informação extremamente importante tanto para o setor de documentação
quanto para o setor de desenvolvimento na empresa.
Essas informações coletadas e tratadas pelo GERADICDAD trazem
muitos benefícios, pois é possível fazer uma conferência para saber se os
programadores estão preenchendo de forma correta os códigos fontes dos
programas (pois caso o sistema não localize essas informações é gerado
um aviso na tela de Log sendo possível fazer a correção), conforme o
esquema de padronização adotado pela empresa. Um exemplo do
cabeçalho usado para coleta de informações está ilustrado na Figura 3.
32
Figura 3. Código fonte de cabeçalho padrão.
O resultado do GERADICDAD foi subdivido conforme etapa 2 e 3 do
projeto. Primeiramente foi necessário fazer o GERADICDAD dos programas,
que tem o resultado ilustrado pela Figura 4.
33
Figura 4. GERADICDAD dos programas.
Na Figura 4 é apresentado o GERADICDAD que lista todos os códigos-
fontes e suas respectivas descrições do sistema D01S que é o sistema de
cadastro.
34
Conforme a terceira fase do projeto, em seguida é apresentada à
ilustração do GERADICDAD das stored procedures.
Figura 5. GERADICDAD das stored procedures.
35
Na Figura 5 temos a lista de todas as Stored Procedures existentes
no sistema D01S que é o sistema de Cadastro. Através desse dicionário é
possível saber quantas Stored Procedures o sistema possui para cada
banco, separados por Oracle, que tem extensão ORA, SQL com a extensão
SER e SYBASE referente à extensão SYB, além de saber seu nome e sua
funcionalidade.
Estas foram às etapas relacionadas à criação do módulo
GERADICDAD que foi responsável por três fases do projeto como um todo.
4.5 O SISTEMA – MIT
Após essas etapas concluídas, testadas e em funcionamento foi
possível iniciar a 4º fase do sistema AUTODOC que é a definição para
geração do MIT e, conforme pesquisas, houve a decisão de se gerar o MIT
em PDF e RTF, pois de acordo com experiências relatadas pelo setor de
documentação são os tipos de documentos mais fáceis de se trabalhar.
Dessa forma foi possível iniciar o processo de desenvolvimento da
implementação do MIT.
O desenvolvimento da 5º fase do projeto foi iniciado com a
implementação do MIT dos programas, nessa etapa pode-se dizer que
houve certa facilidade na implementação devido à preocupação em deixar o
código fonte o mais genérico possível usado pelo GERADICDAD, pois
houve reaproveitamento de código no momento de criar as funções
necessárias para gerar o MIT, apenas adequando-o ao que era necessário,
que consistiu na alteração, que gerou trabalho, exatamente na formatação
do documento, pois será adequado para inclusão nos manuais dos
sistemas. Outra questão que gerou certa facilidade foi que o GERADICDAD
dos programas (Delphi) é muito parecido com o MIT, mudando apenas o
formato do arquivo.
Nessa etapa definiu-se que o sistema então ficará constituído por duas
opções de geração automática da documentação, sendo que ao escolher o
GERADICDAD o sistema traz a opção de exportação dos dados coletados
em Excel (.xls) e o MIT faz a exportação nos formatos .rtf e .pdf.
36
Para implementar o MIT, o projeto foi iniciado com a criação de um
arquivo estático para exportação em .xls, .rtf e .pdf, algo que foi introdutório
para o conhecimento das ferramentas e recursos. Foi utilizada para
exportação em rtf e pdf a biblioteca WPTools para gerar e formatar um
arquivo rtf e exportá-lo em pdf. Depois dessa etapa, da criação de arquivos
estáticos, houve necessidade de deixar de forma dinâmica essa criação
para atender as situações propostas. Para coletar os códigos e módulos dos
programas desenvolvidos pela empresa houve benefícios devido à
padronização dos cabeçalhos (conforme Figura 3) dos códigos dos sistemas
utilizados pela empresa, que são preenchidos pelos programadores e que
definem o sistema e os módulos correspondentes ao código, além da
notação do programador que desenvolveu o código, a versão e as
alterações efetuadas constam nesse cabeçalho que facilita o processo para
extrair dados necessários para o sistema, pois o programa percorre e
coleta esses dados do cabeçalho para criar uma tabela - com código e
descrição dos sistemas - que faz parte da documentação do sistema. Os
pacotes são ordenados do maior para o menor e os códigos em ordem
crescente, ou seja, para o sistema DM (Document Pro), tem-se o código do
sistema definido como D33S e os pacotes, numerada como D33SP01 e os
dois últimos dígitos incrementados; e os códigos têm o padrão D33SF01A e
D33SR01A e o último caractere é incrementado, respectivamente para
formulários e relatórios.
Para a implementação do AUTODOC uma das maiores preocupações
foi em deixar o código fonte o mais genérico possível a fim de se fazer o
aproveitamento de código, pois o sistema é composto de várias funções e
procedimentos que, caso sejam bem escritos, podem ser aproveitados para
serem chamados em situações diferentes, somente alterando parâmetros,
algo que de início dá mais trabalho, porém à medida que o sistema vai
crescendo traz muitos benefícios, e isso é algo bem cobrado na empresa
com o objetivo de obter otimização, conforme dicas adotadas segundo Silvio
Clécio. Realmente fica inviável mostrar, em nível de código fonte, o que foi
37
implementado, porém pretende-se explicar melhor através de imagens e
explicação mais técnica.
A Figura 6 ilustra a tela do AUTODOC com a aplicação de Skin, que
proporciona aparência mais harmoniosa ao sistema, além da inclusão de um
MEMO que permite visualizar os arquivos contidos no caminho destino
atualizado.
Figura 6. AUTODOC na versão com aplicação do Skin.
A Figura 7 ilustra o resultado do MIT dos programas. Essa imagem
mostra o resultado em um arquivo com formato PDF, porém o MIT pode ser
gerado em RTF. Através dessa imagem é possível notar que o MIT dos
programas (Delphi) é bem semelhante à planilha gerada pelo GERADICDAD
dos programas (Delphi). É importante salientar que o MIT não gera MIT dos
programas em FLEX e NET, funcionalidade que está disponível somente no
GERADICDAD e que não foi desenvolvida por questões de tempo e
prioridades.
38
Figura 7. MIT dos programas.
Finalizada a quinta etapa foi possível iniciar a implementação do MIT
das stored procedures que consiste na sexta etapa do projeto AUTODOC.
Essa etapa foi extremamente trabalhosa, pois exigiu conhecimentos mais
abrangentes da ferramenta WPTools, porém foi possível aproveitar um
pouco do código do GERADICDAD das stored procedures, o que ajudou um
pouco. Conforme ilustra a Figura 8, é possível verificar que o MIT das stored
procedures é totalmente diferente do GERADICDAD das stored procedures
(ver Figura 5), pois para gerar esse MIT foi necessário colher mais
informações sobre as stored procedures, além de que houve a necessidade
de juntar os MIT em um único arquivo e todo esse tratamento para que os
MIT dos programas ficassem juntos com o MIT das stored procedures foi
algo trabalhoso. Outra questão é que um documento que é incluso em um
manual precisa ser bem detalhado e formatado de acordo com os padrões
39
da empresa. Para isso houve a necessidade dos exemplos dos MIT gerados
de forma manual como base.
A Figura 8 apresenta o MIT das stored procedures, sendo que neste
documento ele consta unido em um único documento com o MIT dos
programas e também é gerado na opção de formato RTF também em um
documento único somente exportado em PDF.
Figura 8. MIT das stored procedures.
Finalizada a geração do MIT das STP foi possível iniciar a 7ª fase que
trata a parte do MIT das tabelas e views do sistema escolhido.
Nessa fase houve uma certa dificuldade para decidir qual seria a
melhor forma de obter os dados necessários para preencher o MIT tanto das
tabelas quanto das views, pois por se tratar de dados que são obtidos
diretamente do banco de dados, ambos estão bem próximos. Então em
reunião com a coordenação do projeto foi optado por fazer essa conexão
com o banco através do arquivo UDL (Universal Data Link), que armazena
40
as informações necessárias para uma conexão com um banco de dados.
Tais como: o nome do servidor, o provedor utilizado, o método de
segurança e o login a ser utilizado.
Dessa forma grande parte das dificuldades foi resolvida, pois para
obter os dados bastou fazer um select de forma genérica para que cada
banco de dados do sistema filtrado pudesse trazer todas as tabelas que o
mesmo possuía. Quanto ao tratamento dos dados para inserir no arquivo do
MIT houve uma certa facilidade, pois pelo padrão da empresa o MIT das
tabelas é formado somente pelo nome da tabela e sua descrição, processo
que não é muito trabalhoso, pois não exige muita formatação de documento.
Também nessa 7º fase foi criado o MIT das views do sistema filtrado.
Inicialmente foi algo mais simples devido à conexão com o banco já estar
definida, porém o select que traz essa informação é um pouco mais
complexo, já que para trazer esses dados é necessário existir uma conexão
dentro da outra, isso em nível de código, sendo que a primeira é para
conectar ao banco, por exemplo, conecta ao sistema de cadastro e a outra
conexão vai conectar ao sistema que apresenta views para o cadastro.
Dessa forma é possível trazer o nome e a descrição das tabelas, processo
que foi mais complexo visto que cada banco tem um login e senha diferente.
Concluídas todas as fases essenciais do projeto, foi iniciada a fase de
testes e ajustes finais do sistema, que também aconteceu de forma simples
devido ao cuidado que a equipe teve de ao ser gerada nova versão do
sistema, ela ser disponibilizada para testes que foram ajustados e corrigidos
durante todo o processo de desenvolvimento. Não houve muitas correções,
em nível de erros para o final, somente ficaram ajustes que tratam a capa do
documento, inclusão do número de páginas e textos padrões que
acompanham sua edição no início do documento MIT.
Em seguida, conforme ilustra a Figura 9, é apresentada a versão final
do documento MIT completo e dividido em várias imagens para melhor
demonstração. Foi usado, como exemplo, o sistema denominado TOOLS.
41
Figura 9. MIT – capa do documento
É importante lembrar que cada sistema tem sua capa diferente uma da
outra e esse tratamento foi feito via código–fonte, assim que ficou definida
juntamente com a coordenação do projeto a pasta padrão que conteria
esses arquivos para leitura e inclusão no documento. A Figura 9 mostra o
inicio do documento, cada MIT terá seu início com sua capa respectiva.
Figura 10. MIT – Tabelas do sistema
42
A Figura 10 apresenta a 2ª página do documento MIT que contém as
tabelas do sistema filtrado. Essa ordem é padrão para todos os documentos
sendo alteradas as informações que variam de acordo com o sistema
selecionado. Portanto, nem sempre será página 2, pois essa dependerá da
quantidade de informações que o sistema possui. Quanto maior o sistema
maior será seu MIT.
Figura 11. MIT – Views do sistema
A Figura 11 apresenta as views do sistema, composta por objeto
(nome da tabela), descrição (descrição da tabela) e banco de dados origem
(nome da base à qual essa tabela pertence). O MIT das views está na
ordem para todos os documentos, após CAPA e TABELAS,
respectivamente. Essa fase foi deixada por último por necessitar de conexão
com o banco e por questões de prioridades determinadas pela coordenação
do projeto.
43
4.6 O SISTEMA – FUNCIONAMENTO
Para mostrar o funcionamento do sistema inicialmente será
apresentada uma imagem que mostra o ambiente de desenvolvimento na
plataforma do Delphi 2007 usada no servidor de aplicação em que o
AUTODOC foi implementado. A Figura 12 mostra o ambiente com a versão
final da interface do AUTODOC, porém o Skin só é visível na aplicação
rodando. Nessa figura é possível ver a tela de Log, que é encolhida com a
aplicação rodando e só aparece caso ela gere algum erro que daí sim é
mostrado na tela de Log.
Figura 12. Ambiente de desenvolvimento da aplicação.
44
A Figura 13 ilustra o funcionamento do sistema. Mais detalhes são
explicados logo abaixo.
Figura 13. Explicação do funcionamento do sistema.
Conforme pode ser observado na Figura 13, primeiramente é
necessário escolher o que será gerado se é um GERADICDAD ou um MIT.
Na opção do GERADICDAD, por enquanto essa geração só acontece pelo
Excel e na opção do MIT o documento poderá ser gerado em RTF ou PDF.
Estas opções aparecem na combo “Formato” na tela e são preenchidas
conforme opção via código.
O segundo passo é escolher um “Caminho origem” e um “Caminho
destino” – o “Caminho origem” é onde os arquivos serão buscados para
serem tratados, ou seja, momento em que ocorre a extração dos dados
necessários. Vale lembrar que o sistema faz a consistência desse caminho,
algo que foi possível pelo padrão adotado pela SOFTPARANÁ. A opção
“Caminho destino” especifica onde será salvo esse arquivo, sendo que a
empresa tem caminhos padrões para essas opções. Por exemplo, o
45
caminho padrão para se gerar o MIT fica em uma pasta chamada
“MITSource” e os nomes dos arquivos gerados e salvos nessa pasta
também são criados de forma automática via código fonte. Outra facilidade
foi setar de forma automática a pasta onde serão salvos os arquivos,
visando a verificar se o já existe e se está atualizado. Em seguida é
necessário clicar no botão “Gerar” para geração do arquivo escolhido. Após
esse passo, é possível abrir esse arquivo pelo botão “Abrir” para visualizá-lo.
Na opção para 'Atualizar meta data' é possível editar o título dos arquivos
com a descrição do módulo contido no código fonte. Nessa tela há uma
barra de progresso que é carregada conforme geração dos arquivos
escolhidos e uma parte que traz avisos caso apresente alguma
inconsistência ou erro nessa geração. Ainda há o botão de ajuda que
explica o funcionamento do sistema como um todo. Aparentemente é bem
simples, todavia tudo que é feito em nível de código para que esses
processos aconteçam tornou-se cada vez mais complexo, conforme as
etapas foram avançadas.
Uma função interessante e importante implementada no sistema foi à
opção de se usar a aplicação em modo texto além do modo gráfico. A
intenção de disponibilizar essa opção foi facilitar principalmente para os
programadores, que normalmente estão com muitas aplicações abertas
enquanto estão desenvolvendo, de forma a ter uma opção de obter essas
informações sendo geradas a partir de uma versão mais leve somente do
GERADICDAD, visto que a opção de uso em modo texto oferece todas
opções do modo gráfico do sistema.
46
5 RESULTADOS
O presente capítulo apresenta as telas geradas pelo sistema em sua
versão final, juntamente com uma comparação sobre os processos
realizados anteriormente ao AUTODOC, constando também à modelagem
do sistema e os testes realizados.
5.1 CONTEÚDO DOS RESULTADOS
O AUTODOC tem como resultado as melhorias de todos os processos
referentes à criação da documentação de sistemas. Abaixo é mostrada uma
comparação sobre os processos e suas melhorias, além da tela da versão
final do sistema e a tela que contém a ajuda do programa. Outro detalhe
importante a ser mostrado é o MIT que era gerado de forma manual e sua
semelhança com o MIT gerado automaticamente pelo AUTODOC. Já o
GERADICDAD só foi gerado de forma automática, pois serve mais para
consulta dos programadores que para o setor de documentação, além de
não ser disponibilizado para clientes. Por esse motivo, a maior ênfase está
no MIT.
Figura 14. MIT gerado de forma manual.
47
A Figura 14 apresenta o MIT que era gerado de forma manual pela
equipe de documentação de sistemas, e, através da Figura 15, é possível
notar quanto os documentos ficaram semelhantes, pois os autores usaram
os MITs que eram gerados de forma manual como modelo para geração
automática, dada importância que essa alteração não fizesse diferença para
o cliente final, que fará a consulta através desses manuais.
Figura 15. MIT gerado de forma automática pelo AUTODOC
A Figura 16 ilustra a ajuda do sistema, que de forma simples e
objetiva auxilia o usuário como fazer uso do sistema AUTODOC.
Figura 16. Tela de ajuda do sistema.
48
A Figura 17 serve para ilustrar o momento da geração de um
documento em processo de andamento, pois é possível visualizar a barra de
progressos que é preenchida por completo ao término da geração do
documento, além de apresentar uma mensagem informando o usuário que o
processo foi concluído com erros, ou, caso contrário, informar qual exceção
ocorreu durante a sua geração.
. Figura 17. Sistema em funcionamento com barra de progressos.
A partir da Figura 18 é possível visualizar os Logs gerados ao término
da geração do documento. Esse processo ocorre durante a geração do
GERADICDAD e do MIT.
Figura 18. Sistema com os Logs de erros e/ou exceções geradas
49
5.2 MODELAGEM
A modelagem do sistema AUTODOC é baseada na Análise Orientada
a Objetos, visto que o Delphi é uma linguagem orientada a objetos. Quanto
à modelagem, não houve grandes problemas e dificuldades. Ela está
apresentada de acordo com os seguintes itens abaixo:
A figura 19 apresenta o diagrama de classes do sistema AUTODOC.
• DIAGRAMA DE CLASSES
Figura 19. Diagrama de Classes
50
A figura 20 ilustra os casos de uso do sistema AUTODOC
possibilitando melhor entendimento das funcionalidades do projeto.
• DIAGRAMA DE CASOS DE USO
Figura 20. Diagrama de Casos de Uso
51
• DESCRIÇÃO DOS CASOS DE USO
Nome do caso de uso Abrir arquivo
Descrição Permite ao usuário abrir um arquivo
Ator envolvido Usuário
Pré-condições Arquivo criado
Pós-condições Arquivo aberto
Fluxo básico
Ator Sistema
Solicitar abertura Sistema abre o arquivo
{fim} o caso de uso termina Tabela 4. Descrição do caso de uso Abrir Arquivo
Nome do caso de uso Fechar sistema
Descrição Permite ao usuário fechar o sistema
Ator envolvido Usuário
Pré-condições Sistema aberto
Pós-condições Sistema Fechado
Fluxo básico
Ator Sistema
Solicitar fechar Sistema fecha o sistema
{fim} o caso de uso termina Tabela 5. Descrição do caso de uso Fechar sistema
Nome do caso de uso gerar metadado
Descrição Permite ao usuário gerar metadado
Ator envolvido Usuário
Pré-condições Gerado DicDad
Pós-condições Metadado gerado
Fluxo básico
Ator Sistema
Solicitar metadado Sistema atualiza o metadado
{fim} o caso de uso termina Tabela 6. Descrição do caso de uso Gerar metadado
52
Nome do caso de uso Abrir help
Descrição Permite ao usuário abrir tela do help
Ator envolvido Usuário
Pré-condições Sistema aberto
Pós-condições Tela do help aberta
Fluxo básico
Ator Sistema
Solicitar help Sistema abre tela de help
{fim} o caso de uso termina Tabela 7. Descrição do caso de uso abrir help
Nome do caso de uso Construir documento
Descrição Permite ao usuário criar Dicionário de dados de programas
Ator envolvido Usuário
Pré-condições Possuir o programa na máquina
Pós-condições Arquivo Excel com dicionário de dados do programa
Fluxo básico
Ator Sistema
Solicitar criação do documento Sistema consulta os programas Sistema gera um documento
{fim} o caso de uso termina Tabela 8. Descrição do caso de uso construir documento:
DicDad de programas
53
Nome do caso de uso Construir documento
Descrição Permite ao usuário criar Dicionário de dados de stored procedures
Ator envolvido Usuário
Pré-condições Possuir as STP do programa selecionado na máquina
Pós-condições Arquivo Excel com dicionário de dados das stored procedures
Fluxo básico
Ator Sistema
Solicitar criação do documento Sistema consulta as stored procedures Sistema gera um documento
{fim} o caso de uso termina Tabela 9 – Descrição do caso de uso construir documento:
DicDad de stored procedures
Nome do caso de uso Construir documento
Descrição Permite ao usuário criar Manual de informações técnicas
Ator envolvido Usuário
Pré-condições Possuir o programa na máquina
Pós-condições Arquivo rtf ou pdf com o Manual de informações técnicas (programas, stored procedures, tabelas e views)
Fluxo básico
Ator Sistema
Solicitar criação do documento Sistema consulta o banco de dados para coletar informações de tabelas e views Sistema consulta os programas Sistema consulta as stored procedures Sistema gera um documento
{fim} o caso de uso termina Tabela 10 – Descrição do caso de uso construir documento: MIT
54
A figura 21 ilustra o diagrama de seqüência do AUTODOC.
• DIAGRAMA DE SEQUÊNCIA
Figura 21. Diagrama de seqüência
55
5.3 TESTES - IMPLEMENTAÇÃO, INTEGRAÇÃO E IMPLANTAÇÃO
Em relação a testes não houve grandes dificuldades visto que a cada
nova etapa concluída do projeto procurou-se efetuar vários testes não só
pelos autores durante o desenvolvimento, mas também pelos maiores
interessados no sistema, os funcionários do setor de documentação. Dessa
forma a implantação do sistema ocorre à medida que suas etapas são
corrigidas, testadas e aprovadas. Essa implantação resume-se a fazer o
controle de versão que permite a disponibilidade do sistema a todos os
usuários, pois o sistema é publicado no ambiente de produção da empresa
e a cada nova etapa finalizada é disponibilizada uma versão. Quanto à
integração, o sistema está integrado somente com o GERADICDAD que
forma o pacote denominado AUTODOC, ou seja, o sistema está divido em
dois módulos – GERADICDAD e MIT. Os testes realizados no sistema
consistem em:
• Testes na interface que envolve detalhes como tabulação dos
campos, validação dos caminhos que filtram os dados para
geração dos documentos, verificação quanto à barra de
progressos que acompanha a geração dos documentos, avisos
gerais sobre possíveis erros por meio de mensagens ao usuário
e verificação do Log dos erros para ter certeza que estão sendo
apresentados de forma correta e consistida. Testes de
otimização, esse em nível de código fonte que permite melhorar
a leitura do código por meio de redução de linhas utilizadas e
melhor organizadas por regiões.
• Testes de compatibilidade, a fim de verificar o funcionamento do
sistema em outros micros;
• Testes para identificar as limitações que o sistema possui.
• Testes para abrir arquivos de planilha gerados pelo
GERADICDAD em aplicações que não necessitam de licença,
56
tendo a finalidade de verificar se o arquivo não perde a
formatação pré-definida via código fonte.
Todos os testes foram efetuados durante implementação e as
correções foram passadas por meio de tarefas cadastradas no sistema SGA
aos desenvolvedores do AUTODOC. A implantação do sistema foi feita de
forma simples, a cada nova versão gerada foi disponibilizado para todos os
usuários no ambiente de produção da empresa. O sistema foi
completamente implementado na linguagem Delphi 2007 e todo orientado
pela coordenação do projeto na empresa. Maiores detalhes sobre a
implementação, em nível de código fonte estão disponíveis no capitulo 4, na
Tabela 3. Em relação ao treinamento, este não foi necessário, pois o
sistema foi desenvolvido de modo que não necessitasse de grandes
explicações, questão que trouxe uma satisfação muito grande para o
usuário, visto que basta clicar no botão ajuda, que foi formulado para
explicar simples e diretamente o funcionamento do sistema, bastando
somente essa ação para estar treinado para uso do AUTODOC.
57
5.4 DISCUSSÃO
O maior problema assim como o maior desafio do projeto consistiu em
manter os documentos atualizados. Antes do projeto AUTODOC, os dados
encontrados nos manuais, principalmente no MIT não eram confiáveis,
sendo que realmente era impossível manter tais documentos atualizados.
Era uma tarefa que dependia do grupo como um todo, programador, banco
de dados e documentação. Todo processo era iniciado pelo programador
que, por exemplo, ao atualizar uma STP caso “esquecesse” de cadastrar
uma tarefa no SGA não tinha como o DBA (Administrador do banco) saber
dessa atualização e, conseqüentemente, ao ser gerada uma nova versão
para o cliente, os manuais que acompanham o sistema também ficavam
desatualizados causando grandes transtornos que poderiam e muito
prejudicar a imagem da empresa, que garante a documentação como seu
diferencial.
Abaixo há o exemplo do MIT do sistema denominado TOOLS, no qual
é possível ver que nem as views do sistema estão cadastradas e como na
empresa a maior parte dos sistemas é de grande porte é praticamente
impossível que o sistema não tenha nenhuma view, no mínimo para o
sistema de Cadastro, que contém os dados dos clientes, ou seja, não tem
como a documentação adivinhar que estas informações estão
desatualizadas. Outra questão é o fato de todo processo acabar sendo
muito burocrático e dependente de muitas pessoas ao mesmo tempo, sem
dizer que a área de documentação não é obrigada a saber programar e
muito menos entender sobre banco de dados.
58
Figura 22. MIT do sistema TOOLS antes do AUTODOC
Na Figura 23 é possível perceber a grande diferença dos resultados
dos processos realizados anteriormente. É possível visualizar que, para o
mesmo sistema não havia nenhuma view documentada manualmente,
fazendo com que o MIT estivesse incompleto e inconsistente. Já com o
AUTODOC está todo documentado e atualizado.
Atualmente a informação é confiável e bem menos dependente de
tantas pessoas, pois só é necessário que o programador publique suas
alterações e clique no botão gerar do sistema AUTODOC para ter o MIT
atualizado e confiável.
Figura 23. MIT do sistema TOOLS depois do AUTODOC
59
Uma grande diferença pós AUTODOC foi enfatizar algo
extremamente valorizado e cobrado na empresa que é a questão da
padronização, pois com o AUTODOC e os Logs gerados é possível cobrar e
corrigir problemas quanto à padronização, visto que se o programador não
preencher um cabeçalho de um código fonte ou de uma STP de forma
correta, esta informação não poderá ser obtida pelo AUTODOC e Logs
apresentarão esses defeitos. Antes do AUTODOC não havia meios de
corrigir ou cobrar melhor essa questão, pois é inviável abrir fonte por fonte
seja de programas ou STP somente para fazer essa conferencia, ou seja,
acabavam ocorrendo inúmeros casos de códigos fora do padrão.
O GERADICDAD não foi comentado nessa discussão devido a ser
para uso do programador e sua necessidade de implementação serviu muito
como base para gerar o documento mais importante e com maior foco no
projeto que é o MIT. É importante comentar que o GERADICDAD também
gera Logs que são replicados e incrementados assim como o MIT e os Logs
gerados por esse sistema são em nível de código fonte somente de
programas e a parte de STP ele só gera Logs se a mesma não tiver a
versão preenchida e a data, diferente do MIT que tem Logs para cada caso.
Ao longo do projeto foi alterado o módulo GERADICDAD para que
somente gere arquivos de planilhas sem abrir em seguida o Excel, pois
dessa forma o usuário pode abrir o arquivo gerado com software que não
necessite de licença como é o caso do Calc do BrOffice, permitindo que
não dependa de aplicações licenciadas para funcionar.
60
6 CONCLUSÕES
Finalizado o projeto, observa-se que o produto final representa em sua
grande parte o que foi planejado e segue as especificações pré-
estabelecidas através da modelagem do sistema.
O AUTODOC vem para oferecer facilidade e praticidade na rotina da
área de documentação, pois com sua interface limpa e simplificada permite
uso para todo tipo de usuário e facilitou processos não somente para área
de documentação, mas também o desenvolvimento.
O software faz parte da rotina da empresa como um todo. Gerar
documentos não é mais um obstáculo no dia-a-dia da área de
documentação. O software oferece a garantia de documentos atualizados e
informações com alto grau de confiabilidade.
Levando-se em conta a antiga situação em que se encontrava a área
de documentação na empresa e a forma como eram gerados os manuais
essenciais para os clientes, que a empresa possui com informações
pertinentes à manutenção de seu negócio, conclui-se que o sistema
AUTODOC de forma simples atende às principais necessidades da área de
documentação e vai além com documentos que auxiliam a equipe de
desenvolvimento da empresa.
6.1 CONTRIBUIÇÕES
O trabalho contribuiu muito não somente para área que faz o uso do
sistema, mas também para a carreira dos profissionais autores do projeto,
pois vivenciar toda realidade na implementação, implantação e teste de
sistemas foi algo totalmente diferente de se fazer um sistema, por exemplo,
em sala de aula que somente o aluno irá testar, localizar defeitos ou
problemas. Para a equipe foi o conhecimento de uma nova linguagem, um
novo padrão, uma nova disciplina no momento de se programar, aprendeu-
se uma nova forma de se organizar e principalmente a possibilidade de
61
continuar esse projeto após sua apresentação para a universidade, além de
ter a oportunidade de trabalhar em outros projetos na empresa findo este.
Para a empresa a maior contribuição está no ganho de tempo utilizado
para gerar os manuais. Antes do AUTODOC, segundo a coordenadora da
área, o tempo gasto para geração da documentação de softwares era algo
em torno de seis horas por dia, tempo que hoje está reduzido em apenas
uma hora para ter documentos de todos os sistemas atualizados. Outro
grande benefício é a confiabilidade dessas informações. Foi um
conhecimento para ambas as partes que irá continuar a partir dessa etapa,
já que a equipe estará contratada pela empresa participando de novos
projetos, sendo uma grande contribuição para o início de uma carreira. A
equipe acredita num ganho muito maior quando ocorre a participação em
projetos reais.
6.2 TRABALHOS FUTUROS
Como trabalhos futuros propõe-se: aperfeiçoar a programação do
software AUTODOC, com a finalidade de aprimorar a performance do
sistema; realizar novos testes com o software AUTODOC para comprovar e
otimizar sua aplicação; incluir índices no módulo do MIT para melhor
localização das informações no documento; aplicar o Skin nas pesquisas
por diretórios; e incluir o MIT dos programas em FLEX e NET;
62
7 REFERÊNCIAS
Clécio, Silvio. Dicas para otimização de código. Setembro 2008. Disponível em:<http://www.mail-archive.com/delphi [email protected]/msg66817.html> Acesso em: 17 dez. 2008. Help e manual. Recursos. Março 2009 - Disponível em: <http://www.helpandmanual.com/go2.htm?gclid=CIiMz5SHwpwCFUdM5QodMi29nQ> Acesso em: 12 nov. 2008. Michelazzo, Paulino. A documentação de software. São Paulo, julho. 2006. Disponível em: <http://imasters.uol.com.br/artigo/4371/gerencia/ a_documentacao_de_software/> Acesso em: 13 out. 2008. Ribeiro, Paulo Henrique.Função para copia de arquivos utilizando a shell api do windows ( Códigofonte.net. - Funções). Março 2007. Disponível em: <http://www.codigofonte.net/scripts/delphi/funcoes/1407_ syscopiashellapi> Acesso em: 26 fev. 2009. Studiebureau Festraets, Delphi Tutorials. Running external applications: ShellExecute and ShellExecuteEx. 1999-2006. Disponível em: <http://www.festra.com/eng/mtut01.htm> Acesso em: 13 fev. 2009. Ziersch, Julian. WPTools Version 5 GUIDE. Munich, Germany, 2004-2008. 208p
Autorização
Autorizo a reprodução e/ou divulgação total ou parcial da presente
obra, por qualquer meio convencional ou eletrônico, desde que citada à
fonte.
Nome da autora: Sarita Alves de Souza
Assinatura da autora: ___________________________
Nome do autor: Willian Hideo Saizaki
Assinatura do autor: ____________________________
Instituição: Universidade Tecnológica Federal do Paraná
Local: Curitiba, Paraná
E-mail: [email protected]
E-mail: [email protected]