UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ DEPARTAMENTO ACADÊMICO DE INFORMÁTICA CURSO DE TÉCNOLOGIA EM INFORMÁTICA

Transcrição

1 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

2 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

3 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

4 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.

5 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.

6 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.

7 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.

8 LISTA DE FIGURAS Figura 1. Primeira versão do sistema Figura 2. GERADICDAD(Windows Explorer) Figura 3. Código fonte de cabeçalho padrão Figura 4. GERADICDAD dos programas Figura 5. GERADICDAD das stored procedures Figura 6. AUTODOC na versão com aplicação do Skin Figura 7. MIT dos programas Figura 8. MIT das stored procedures Figura 9. MIT capa do documento Figura 10. MIT Tabelas do sistema Figura 11. MIT Views do sistema Figura 12. Ambiente de desenvolvimento da aplicação Figura 13. Explicação do funcionamento do sistema Figura 14. MIT gerado de forma manual Figura 15. MIT gerado de forma automática pelo AUTODOC Figura 16. Tela de ajuda do sistema Figura 17. Sistema em funcionamento com barra de progressos Figura 18. Sistema com os Logs de erros e/ou exceções geradas Figura 19. Diagrama de Classes Figura 20. Diagrama de Casos de Uso Figura 21. Diagrama de seqüência Figura 22. MIT do sistema TOOLS antes do AUTODOC Figura 23. MIT do sistema TOOLS depois do AUTODOC... 58

9 LISTA DE TABELAS Tabela 1. Configuração das estações de trabalho Tabela 2. Recursos de softwares Tabela 3. Principais funções e procedimentos...26 Tabela 4. Descrição do caso de uso Abrir Arquivo Tabela 5. Descrição do caso de uso Fechar sistema Tabela 6. Descrição do caso de uso Gerar metadado Tabela 7. Descrição do caso de uso abrir help Tabela 8. Descrição do caso de uso construir documento: Tabela 9 Descrição do caso de uso construir documento: Tabela 10 Descrição do caso de uso construir documento: MIT... 53

10 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

11 SUMÁRIO 1 INTRODUÇÃO APRESENTAÇÃO JUSTIFICATIVA OBJETIVOS ORGANIZAÇÃO DO DOCUMENTO A EMPRESA A SOFTPARANÁ A EMPRESA ANTES DO SISTEMA A EMPRESA DEPOIS DO SISTEMA SISTEMAS DE DOCUMENTAÇÃO PORQUE DOCUMENTAR? O MERCADO X AUTODOC AUTODOC - VANTAGENS X DESVANTAGENS METODOLOGIA METODOLOGIA - REQUISITOS LEVANTAMENTO DE REQUISITOS RECURSOS - FINANCEIROS, PESSOAL E SOFTWARE METODOLOGIA CÓDIGO FONTE PESQUISAS O SISTEMA GERADICDAD O SISTEMA MIT O SISTEMA FUNCIONAMENTO RESULTADOS CONTEÚDO DOS RESULTADOS MODELAGEM TESTES - IMPLEMENTAÇÃO, INTEGRAÇÃO E IMPLANTAÇÃO DISCUSSÃO... 57

12 6 CONCLUSÕES CONTRIBUIÇÕES TRABALHOS FUTUROS... 61

13 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 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 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 15 implementado em Delphi 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 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 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 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 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, , 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 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 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 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. ESTAÇÃO SARITA WILLIAN Tabela 1. Configuração das estações de trabalho. CONFIGURAÇÃO 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 Velocidade Clock: 1795 Mhz 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 Velocidade Clock: 1795 Mhz

23 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 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 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 SubVersion SGA IDE (ambiente integrado para desenvolvimento de software) usada para desenvolver o AUTODOC. Sistema que permite o controle de versão e publicação do projeto no ambiente de produção. Sistema de gerenciamento de atividades criado pela SOFTPARANÁ com a finalidade de gerenciar recursos humanos.

25 25 Office comunicator Microsoft Office Outlook PAD Ferramenta que permite a comunicação instantânea entre os funcionários da empresa. Sistema de correio eletrônico para recebimento de s relacionados ao trabalho da empresa. 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 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 27 ProGravaLog ProOrdenaArqFlex ProOrdenaArqNet ProOrdenaArqPas FncProcuraArquivos FncProcuraDescricao ProSplit FncValidaCaminho FncVerificaCorporativo 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. Recebe como parâmetro uma string list para tratamento relacionado à ordenação dos tipos de arquivos passados como parâmetros ao ser chamada. 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. Função usada para retornar a descrição de um arquivo e se encontrar guarda em uma lista de strings para serem tratadas. 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. Função do tipo booleana que faz a conferência do caminho origem selecionado como filtro para geração da documentação. 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 28 ProCriaDoc ProPulaLinhaTabela FncGeraRTF ProBuscaSenhaBase Procedimento responsável por fazer a criação do arquivo Rich Text formatado. Procedimento responsável por pular linhas ao finalizar a tabela e permitir que documento seja formatado de acordo com os padrões. 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. 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 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 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 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 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 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 33 Figura 4. GERADICDAD dos programas. Na Figura 4 é apresentado o GERADICDAD que lista todos os códigosfontes e suas respectivas descrições do sistema D01S que é o sistema de cadastro.

34 34 Conforme a terceira fase do projeto, em seguida é apresentada à ilustração do GERADICDAD das stored procedures. Figura 5. GERADICDAD das stored procedures.

35 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 51 DESCRIÇÃO DOS CASOS DE USO Nome do caso de uso Descrição Ator envolvido Pré-condições Pós-condições Fluxo básico Ator Solicitar abertura Nome do caso de uso Descrição Ator envolvido Pré-condições Pós-condições Fluxo básico Ator Solicitar fechar Abrir arquivo Permite ao usuário abrir um arquivo Usuário Arquivo criado Arquivo aberto Sistema Sistema abre o arquivo {fim} o caso de uso termina Tabela 4. Descrição do caso de uso Abrir Arquivo Fechar sistema Permite ao usuário fechar o sistema Usuário Sistema aberto Sistema Fechado Sistema 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 Descrição Ator envolvido Pré-condições Pós-condições Fluxo básico Ator Solicitar metadado gerar metadado Permite ao usuário gerar metadado Usuário Gerado DicDad Metadado gerado Sistema Sistema atualiza o metadado {fim} o caso de uso termina Tabela 6. Descrição do caso de uso Gerar metadado