CLAV: classificação e avaliação da informação pública: especificação e implementação do RADA

Universidade do Minho Escola de Engenharia Departamento de Informática Frederico Daniel Pereira Pinto CLAV: Classificação e Avaliação da Informação Pública Especificação e Implementação do RADA Março 2022 Universidade do Minho Escola de Engenharia Departamento de Informática Frederico Daniel Pereira Pinto CLAV: Classificação e Avaliação da Informação Pública Especificação e Implementação do RADA Relatório de Dissertação Mestrado Integrado em Engenharia Informática Trabalho efetuado sobre orientação de Professor Doutor José Carlos Ramalho Março 2022 D I R E I TO S D E AU TO R E C O N D I Ç Õ E S D E U T I L I Z AÇ ÃO D O T R A B A L H O P O R T E R C E I R O S Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Attribution-NonCommercial CC BY-NC https://creativecommons.org/licenses/by-nc/4.0/ i AGRADECIMENTOS Em primeiro lugar quero agradecer ao meu orientador Professor José Carlos Ramalho por todo apoio, orientação e disponibilidade. Um obrigado por todos ensinamentos teóricos e sociais que me passou em todos os momentos que vivemos e pela oportunidade de dar o meu contributo à CLAV, um projeto extremamente exigente e importante no panorama arquivístico português. Sinto um orgulho enorme por ter contribuído com esta missão. De seguida quero agradecer também à minha família, especialmente ao meu pai e mãe pela forma de como me educaram e se sacrificaram para que eu tivesse uma vida melhor. Sem vocês não seria o que sou hoje e gostaria de agradecer por sempre acreditarem em mim. Quero também deixar um agradecimento a todos os amigos que fiz na vida, as nossas vivências fazem parte do que sou. As minhas últimas palavras são dirigidas à Marcela um pilar importantíssimo na minha vida, obrigado por tudo. Que travemos batalhas juntos por muito tempo. ii DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas que levaram à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. iii RESUMO A complexidade dos processos administrativos associados à administração pública portuguesa torna-os demasiados penosos e lentos para os tempos em que vivemos. Com o intuito de combater esta problemática, o governo português criou um programa denominado Simplex+ que contém inúmeras medidas que visam simplificar e modernizar os processos administrativos nas entidades públicas. Com o propósito de desmaterializar e simplificar os processos administrativos do arquivo nacional foi criada uma medida no programa Simplex+ , denominada ”Arquivo Digital”. Esta medida tem como intuito implementar instrumentos transversais de gestão da documentação que visam classificar e avaliar os documentos produzidos e recebidos nos organismos públicos, disponibilizando-os numa plataforma online . Como execução da última etapa da medida nasce a Projeto CLAV: Plataforma modular de classificação e avaliação da informação pública (CLAV) . Nos últimos anos, a CLAV tem vindo a ser desenvolvida na Universidade do Minho (UM) sobre orientação do Professor José Carlos Ramalho em conjunto com os responsáveis da entidade detentora do projeto, Direção-Geral do Livro, dos Arquivos e das Bibliotecas (DGLAB) . O principal objetivo desta dissertação surge como a introdução na plataforma CLAV de um dos instrumentos de gestão documental, o Relatório de Avaliação de Documentação Acumulada (RADA) . Este instrumento que foi criado há vários anos visava classificar e avaliar a documentação produzida após esta ter sido criada. De forma a atingir este propósito e cumprir os requisitos impostos pela DGLAB foi necessário criar na aplicação web da plataforma novas interfaces que suportem a criação de um pedido RADA e que possibilitem a análise, validação, consulta e despacho do pedido no workflow de pedidos e, posteriormente, uma interface que permita a consulta e exportação em PDF de um RADA aprovado e presente na plataforma. Aliado aos desenvolvimentos na aplicação web foi necessário também especificar o domínio de dados do RADA na ontologia da plataforma bem como, adaptar e construir novas rotas na Application Programming Interface (API) para suportarem o funcionamento deste novo universo. Todos os desenvolvimentos efetuados nesta dissertação estão disponíveis em produção no sítio web da CLAV: https://clav.dglab.gov.pt. Palavras-Chave: CLAV, DGLAB, Relatório de Avaliação de Documentação Acumulada iv ABSTRACT The complexity of the administrative processes associated with the Portuguese public administration makes them too painful and slow for the times in which we live. To combat this problem, the Portuguese government created a program called Simplex+, which contains numerous measures aimed at simplifying and modernizing administrative processes in public entities. To dematerialize and simplify the administrative processes of the national archive, a measure in the Simplex+ programme, called ”Digital Archive”. This measure aims to implement cross-cutting documentation management tools to classify and evaluate the documents produced if received in public bodies, making them available on an online platform. CLAV. In recent years, CLAV has been developed at the University of Minho, under the guidance of Professor José Carlos Ramalho, together with those responsible for the entity that owns the project, the DGLAB. The main objective of this dissertation is the introduction in the CLAV platform one of the document management tools, the RADA. This instrument that was created several years ago aims to classify and evaluate the documentation produced after it was created. To achieve this purpose and meet the requirements imposed by DGLAB it was necessary to create in the platform’s web application new interfaces that support the creation of a RADA request and enable the analysis, validation, consultation and approval on the application workflow and, subsequently, an interface that allows consultation and PDF export of an approved RADA present in the platform. Coupled with the developments in the web application, it was also necessary to specify the data domain of the RADA in the platform ontology as well as, adapt and build new routes in the API to support the functioning of this new universe. All the developments made in this dissertation are available in production on the CLAV website: https: //clav.dglab.gov.pt. Keywords: CLAV, DGLAB, Accumulated Documentation Assessment Report (RADA) v CONTEÚDO 1 introdução 1 1.1 Objetivos 2 1.2 Metodologia 2 1.3 Estrutura do Documento 2 2 o arquivo em portugal 4 2.1 Iniciativas para a modernização do Arquivo 6 2.1.1 Macro-Estrutura Funcional 6 2.1.2 Harmonização de Classes de 3º Nível 6 2.1.3 Projeto ASIA 6 2.1.4 Lista Consolidada 7 2.1.5 Plataforma CLAV 7 2.2 Resumo 8 3 clav: o ponto de partida 9 3.1 Funcionalidades Implementadas 9 3.1.1 Entidade e Tipologia de Entidade 9 3.1.2 Legislação 9 3.1.3 Lista Consolidada 10 3.1.4 Tabela de Seleção 10 3.1.5 Workflow de Pedidos 10 3.2 Arquitetura e Tecnologias 10 3.2.1 Bases de Dados 11 3.2.2 Interface para Máquinas - API de Dados 12 3.2.3 Interface para Humanos - Frontend 13 3.3 Resumo 13 4 rada especificação e requisitos 14 4.1 Especificação do RADA 14 4.1.1 Relatório Expositivo 15 4.1.2 Tabela de Seleção 17 4.1.3 Classe Área Orgânico-Funcional 17 4.1.4 Classe Série/Subsérie 18 4.1.5 Unidade de Instalação 23 4.2 Requisitos 23 4.3 Resumo 24 5 criação do pedido rada 26 5.1 Criação Assistida 26 vi conteúdo vii 5.1.1 Informação Geral 27 5.1.2 Relatório Expositivo 27 5.1.3 Tabela de Seleção 29 5.1.4 Classe Área Orgânico-Funcional 30 5.1.5 Classe Série 30 5.1.6 Classe Subsérie 35 5.1.7 Unidade de Instalação 37 5.1.8 Edição durante Criação 39 5.2 Criação através de Importação 41 5.3 Pendentes 42 5.4 Submissão do pedido de criação 43 5.5 Resumo 45 6 gestão do pedido de criação rada 46 6.1 Consulta de um pedido RADA 46 6.1.1 Relatório Expositivo 48 6.1.2 Tabela de Seleção 48 6.2 RADA no workflow de pedidos 52 6.2.1 Pedido Novo 53 6.2.2 Pedido em Apreciação Técnica 53 6.2.3 Pedidos em Validação 63 6.2.4 Pedidos em Despacho 64 6.3 Resumo 65 7 inserção do rada na plataforma 66 7.1 Ontologia 66 7.1.1 Alterações às Entidades 66 7.1.2 Alteração aos Object Properties 68 7.1.3 Alterações aos Data Properties 70 7.2 API 71 7.2.1 POST /rada 71 7.2.2 GET /rada 71 7.3 Resumo 72 8 consulta do rada 73 8.1 Consulta 73 8.2 Exportação em PDF 74 8.3 Revogação de um RADA 76 8.4 Resumo 76 9 conclusões e trabalho futuro 77 9.1 Trabalho Futuro 77 a apêndice 78 a.1 Ficheiro CSV para importação do relatório expositivo 78 1 I N T R O D U Ç ÃO Historicamente desde o ano 3000 a.C a Humidade começou a fazer registos sobre acontecimentos importantes para a sua sociedade. Esses registos denominados de arquivo, apresentam um carácter extremamente valioso para gerações futuras pois permitem obter conhecimento do que aconteceu no passado, contribuindo assim para o avanço da sociedade e da Humanidade. Foi graças aos primeiros arquivos que os historiadores conseguiram descobrir vários alfabetos, linguagens, literaturas e políticas praticadas na época. Em Portugal, o primeiro arquivo nacional, situado numas das torres do castelo de Lisboa, foi criado em 1378 por D. Fernando e tinha como intuito arquivar registos sobre o rei, os seus vassalos, a administração do reino e possessões ultramarinas, guardando também os documentos resultantes das relações com outros reinos. [2] Durante a idade média e moderna vários países foram responsáveis por criarem novos sistemas de arquivos, aliados a técnicas mais eficazes para extrair o conhecimento dos mesmos preparando eficazmente o seu futuro. Contudo nos tempos que vivemos, os processos burocráticos, administrativos e logísticos a que as instituições públicas estão sujeitas, levam à produção de grandes quantidades de informação que, conforme a sua importância devem ser arquivadas estando disponíveis para consulta a longo-termo. Essa grande quantidade de informação produzida desencadeia longos e complexos processos que arrecadam despesas elevadas para as instituições públicas. A incomportabilidade deste contexto, torna a desmaterialização desses processos fundamentais, o que se identifica como uma medida enquadrada no eixo estratégico do desenvolvimento sustentável. [1] Neste sentido o Governo Português tem desenvolvido estratégias para a transformação digital neste setor tendo por base normas e orientações provenientes da Comissão Europeia. Acima de tudo pretende-se a redução do consumo de papel, a promoção da adoção de sistemas de gestão documental eletrónica ou outros, bem como a digitalização de documentos destinados a ser arquivados. Uma das medidas previstas é o ”Arquivo Digital”apresentada no programa Simplex+ , este visa a simplificação legislativa e administrativa aliada a uma modernização dos serviços públicos no Governo Português. A gestão desta medida está a cabo do Ministério da Cultura e tem como objetivo implementar instrumentos transversais de gestão da informação, que visam classificar e avaliar os documentos produzidos e recebidos nos organismos públicos. Esses instrumentos terão que ser disponibilizados por uma plataforma modular de serviços partilhados, passível de integração com os sistemas de informação existentes por qualquer organismo. [8] Como consequência desta medida surgiu a plataforma ”CLAV”, sendo esta financiada pela DGLAB em colaboração com a UM para dar cumprimento pleno à medida acima descrita. A plataforma CLAV é uma peça fundamental nesta medida porque é o que realmente permite desmaterializar os procedimentos de classificação e avaliação, atualmente obrigatórios, para se poder eliminar documentação em papel na adminstração pública portuguesa. 1 1.1. Objetivos 2 Esta dissertação enquadra-se no projeto CLAV numas das últimas fases de desenvolvimento, tendo como objetivo implementar na plataforma um dos instrumentos de classificação e avaliação documental criado pela DGLAB há vários anos, o RADA. Este novo instrumento permite classificar e avaliar a documentação já existente. 1.1 objetivos Esta dissertação tem como principais objetivos: • Especificar formalmente um RADA na ontologia do CLAV; • Desenvolver software na API da plataforma capaz de criar e gerir toda informação sobre o RADA cumprindo os requisitos impostos pela DGLAB; • Implementar um conjunto de interfaces na aplicação web com funcionalidades que satisfaçam os requisitos impostos; 1.2 metodologia A metodologia para a elaboração da presente dissertação seguiu os seguintes passos: • Estudo profundo sobre o RADA; • Levantamento e análise de requisitos perante a DGLAB; • Estudo teórico sobre as tecnologias envolvidas para a produção de software ; • Análise de documentos técnicos e de toda a implementação realizada até ao momento; • Desenvolvimento da base de dados e do software que concretize os requisitos impostos; • Realização de testes manuais para garantir a correta funcionalidade do software desenvolvido; • Análise do desempenho e usabilidade do software produzido; • Reuniões semanais de acompanhamento com os responsáveis da plataforma. 1.3 estrutura do documento Esta dissertação está dividida em cinco capítulos. Começando pelo capítulo, ”O Arquivo em Portugal” , onde será apresentado o contexto do arquivo em Portugal e todas as iniciativas efetuadas para melhorar o processo de arquivo existente. De seguida, será apresentado o ponto de partida da plataforma CLAV aquando do início desta dissertação, expondo os conceitos já implementados e as tecnologias usadas. No capítulo 4 será apresentado o RADA abordando a descrição de todos os seus componentes e requisitos funcionais impostos pela DGLAB. A partir do capítulo 5 inicia-se a descrição das etapas de implementação, requisito a requisito, começando com a exposição da interface de criação de um pedido RADA. De seguida, no 1.3. Estrutura do Documento 3 capítulo 6 é apresentada a implementação do requisito que permite um pedido RADA ser validado e aprovado no workflow de pedidos da plataforma. Após todos estes capítulos surge no capítulo 7 a descrição da implementação do RADA na ontologia da CLAV bem como na API expondo todo o trabalho. No capítulo 8 é endereçada a implementação que permite consultar um RADA aprovado expondo todas as funcionalidades como imposto pelo último requisito. Por fim, no capítulo 9 são apresentadas as conclusões finais sobre a dissertação refletindo também sobre o trabalho futuro. 2 O ARQUIVO EM PORTUGAL O processo de arquivo da documentação gerada por instituições públicas portuguesas é composto por duas etapas, a classificação e avaliação. A classificação consiste o ato de descrever o que está retratado na documentação de modo mais abstrato, enquanto que, a avaliação é o ato onde é decidido o que vai acontecer à documentação, podendo ser conservada, eliminada ou parcialmente conservada. Em Portugal, a preocupação com a avaliação dos documentos apenas se manifestou em 1972 com o DecretoLei nº 29/72. Este decreto visava, sobretudo, resolver a acumulação de documentos físicos dando valor probatório aos microfilmes decretando também, o afastamento do arquivista e a inserção das entidades produtoras da documentação no processo de avaliação. Sendo assim, cada organismo público deveria publicar uma portaria em que fosse identificada a documentação a eliminar e a conservar definitivamente. Rapidamente este decreto expôs as suas limitações. Para além de serem diminutas as entidades que usavam as portarias, as que publicavam, praticavam um mau uso da mesma, não procedendo a uma análise ou mesmo listagem da documentação produzida ou existente, apenas se limitavam no texto da portaria a afirmar que a documentação com interesse histórico seria transferida para o arquivo histórico. Aliado a isso, o elevado custo e dificuldade de aceder aos microfilmes rapidamente impossibilitaram o uso dos mesmo. Tudo isto, deitou por terra a intenção do Decreto-Lei nº 29/72 e a documentação voltou a acumular-se. [6] Apenas em 1988 o problema da documentação acumulada voltou a ser encarado pelos legisladores com a publicação do Decreto-Lei nº 447/88. Este tinha como grande objetivo regulamentar a pré-arquivagem da documentação, obrigando à intervenção nos processos de avaliação do serviço superintendente da politica nacional, o recém-nascido Instituto Português de Arquivos. Essa intervenção tinha como objetivo por fim a eliminações descontroladas e conservações sem sentido, assegurando uma uniformidade de critérios de avaliação. Este novo decreto revogou o anterior e exigiu uma reformulação de todas as portarias que haviam sido publicadas ao seu abrigo. Com este decreto-lei surgiu em Portugal o conceito de pré-arquivagem, criando assim uma nova etapa para o ciclo de vida da documentação, o arquivo intermédio. Figura 1: Ciclo de vida da documentação. É no arquivo intermédio que são executadas as operações de avaliação, seleção, eliminação, transferência e substituição de suportes da documentação proveniente do arquivo administrativo de um serviço produtor. É 4 5 nesta etapa que o decreto-lei propõe a única intervenção do arquivista, dando-lhe um lugar central no processo de avaliação que deverá ser efetuado com estreita colaboração com os produtores da documentação e finalmente consubstanciar-se num diploma legal, uma portaria denominada Portaria de Gestão de Documentos (PGD) . Essa portaria era composta por um regulamento, uma tabela de seleção, modelos de auto de entrega, guia de remessa e auto de eliminação e após elaborada, era então aprovada pelo responsável do serviço produtor da documentação e pelo responsável do serviço superintendente da politica arquivística nacional. [6] A criação da PGD como instrumento para a classificação e avaliação da documentação foi o primeiro tipo de intervenção do arquivista no recém criado arquivo intermédio. Contudo, rapidamente se tornou notório que eram necessários dois tipos de intervenção, um para a documentação corrente e outro para a documentação acumulada. A PGD seria o instrumento correto para classificar e avaliar a informação corrente, enquanto, a documentação acumulada seria classificada e avaliada através de um relatório de avaliação de documentação acumulada (RADA). A elaboração de um RADA contêm igualmente uma tabela de seleção e folhas de recolha de dados mas a aprovação do mesmo estava ao encargo do órgão superintendente da politica arquivística nacional podendo ser aplicado posteriormente pela entidade produtora. Resumidamente tratava-se de um processo menos burocrático e menos moroso, por não incluir o circuito de aprovação que a PGD exigia. A criação destes dois instrumentos procurava também representar momentos temporais distintos para a operação de avaliação. A PGD representa uma avaliação a priori , ou seja, antes de a documentação ser efetivamente produzida já estaria avaliada. Por outro lado, o RADA tem como objetivo avaliar a posteriori , ou seja, avaliar a documentação já existente. [6] Após a criação destes instrumentos em 1988 só em 2003 é que a entidade superintendente da politica nacional teve acesso aos primeiros dados quantitativos sobre a gestão dos documentos na Administração Pública. Num universo de 645 organismos, 362 foram envolvidos num inquérito que revelou uma diminuta taxa de penetração dos arquivistas nos arquivos correntes aliada a uma falta de instrumentos para a gestão documental. Para além disso, este inquérito revelou que na maior parte das vezes a documentação em arquivo intermédio era colocada em depósitos sem as mínimas condições de conservação e acima de tudo, continuava a existir uma eliminação ilegal e grande acumulação de documentação. Em 2008 foi lançado um novo inquérito apenas aos organismos com PGD publicada, tendo este o objetivo de saber mais sobre a aplicação deste instrumento. Neste foi revelado que a PGD não era encarada como instrumento de gestão documental para documentação corrente, mas apenas e maioritariamente aplicada quando o organismo tinha necessidade de eliminar documentação existente em depósitos. Este mau-uso da PGD deve-se em grande parte à dificuldade que a maioria das entidades enfrenta em criar o seu plano de classificação e como tal, espelhando-se mais facilmente numa estrutura orgânica do que numa estrutura funcional, na qual é exigida uma teorização sobre as suas funções elevando o grau de dificuldade da criação do seu plano de classificação e consequentemente da aplicação da PGD. Em 2010 foi efectuado outro inquérito às entidades com PGD publicada. Devido ao aparecimento dos Sistema Electrónico de Gestão de Arquivos (SEGA) , que obrigaram na teoria à classificação da documentação no momento de produção, este inquérito revelou um aumento significativo da percentagem de entidades que procede à classificação da documentação e que indica estar a implementar um SEGA. Contudo continuavam a permanecer centenas de quilómetros de documentação em arquivo, estando grande parte por avaliar devido a níveis muito baixos de aplicação dos instrumentos para a gestão da documentação em vigor. [6] 2.1. Iniciativas para a modernização do Arquivo 6 2.1 iniciativas para a modernização do arquivo Após a ineficácia das ações passadas foi necessário tomar medidas e criar iniciativas concretas que realmente tivessem impacto. Sendo assim, foram iniciados trabalhos com o intuito de criar um referencial comum para todos as entidades públicas permitindo a classificação e avaliação da informação arquivística corrente mais eficazmente. 2.1.1 Macro-Estrutura Funcional Um dos primeiros passos para atingir essa meta foi a criação da Macro-Estrutura Funcional (MEF) em 2011, que teve como objetivo representar conceptualmente e de maneira abstracta as funções que os organismos da Administração Pública Central efectuam. Esta tem por base uma estrutura hierárquica de dois níveis composta por classes, sendo essas classes representações de funções no primeiro nível e sub-funções no segundo, permitindo assim decompor as funções pai dando-lhe mais especificidade. Em 2013, foi publicada uma nova versão da MEF contemplando também as funções da Adminstração Pública Local. [9] 2.1.2 Harmonização de Classes de 3º Nível Após a criação da MEF, surgiu em 2013 o projeto ”Harmonização de classes de 3º nível em planos de classificação conformes à MEF”que teve como intuito a criação de um terceiro nível na estrutura da MEF dando mais especificidade às classes generalistas até agora descobertas. Uma classe deste novo nível é obrigatoriamente uma representação de uma ”sucessão ordenada de atividades interligadas, desempenhadas para atingir um resultado definido (produto ou serviço), no âmbito de uma função”e denomina-se processo de negócio. Este projeto foi bastante importante pois existia uma necessidade de concretizar as funções/subfunções executadas pela administração pública descritas na MEF, de modo a possibilitar a construção de planos de classificação a partir de uma base comum. [9] 2.1.3 Projeto ASIA O projeto Avaliação Supra-Institucional da Informação Arquivística (ASIA) , foi um dos pilares mais importantes neste trajeto de evolução, aqui a entidade superintendente dos arquivo nacional juntamente com as entidades públicas procederam à avaliação arquivística dos processos de negócio provenientes da harmonização de classes de 3º nível, ou seja, às classificações dos processos de negócio foi adicionado os prazos de conservação e destino final para a documentação originada pelos mesmos. Como resultado, surgiu a primeira versão da Lista Consolidada (LC) . [9] 2.1. Iniciativas para a modernização do Arquivo 7 2.1.4 Lista Consolidada ALC é o primeiro grande resultado das iniciativas anteriores, um referencial comum para a classificação e avaliação da documentação criada pelas funções de toda a Administração Pública. Esta é coordenada pela DGLAB, a quem compete a responsabilidade de integração de novos processos de negócios ainda não identificados e de toda a sua gestão. Figura 2: Iniciativas para a criação da Lista Consolidada. De forma a colmatar todos os problemas descritos na secção anterior surgiu a LC que ao conter um referencial comum, possibilita a todas as entidades criarem a sua tabela de seleção de forma mais eficiente. Aliado a isso, esta estrutura macrofuncional que é a LC representa um grande avanço na interoperabilidade semântica na administração pública, mostrando um bom exemplo de como matérias complicadas podem ser melhoradas com a criação de uma língua comum. 2.1.5 Plataforma CLAV Tendo por base uma iniciativa governamental denominada Simplex+ , o governo português reuniu um conjunto de medidas para modernizar e simplificar certas áreas de trabalho na administração pública. Uma das mais relevantes neste contexto, foi a medida 51 - ”Arquivo Digital”, gerida pelo Ministério da Cultura que tem como objetivo implementar instrumentos transversais de gestão da informação, que visam classificar e avaliar os documentos produzidos e recebidos nos organismos públicos, disponibilizando-os numa plataforma modular de serviços partilhados, passível de integração com os sistemas de informação existentes por qualquer organismo. A partir desta medida nasce a plataforma Classificação e Avaliação da Informação Pública (CLAV) desenvolvida em conjunto com a Universidade do Minho. Esta plataforma tinha como objetivo principal operacionalizar a LC, disponibilizando em formato aberto a ontologia com toda a meta-informação sobre as funções/processos de negócio da LC relacionada com a legislação regulamentar e um catálogo de entidades que são responsáveis/executam esses processos de negócio. Por outro lado, a plataforma viabiliza a desmaterialização de processos referentes à atualização da LC, à elaboração de Tabelas de Seleção (TS) derivadas da LC e do controlo da eliminação da informação arquivística, através da submissão de autos de eliminação. No futuro, a plataforma será ainda 2.2. Resumo 8 capaz de ser utilizada na criação, aprovação, atualização e controlo de aplicação de Relatórios de Avaliação de Documentação Acumulada (RADA) da administração pública. [5] Contudo, o projeto CLAV apenas cumprirá integralmente os seus objetivos se a componente relativa à alteração do regime jurídico da classificação e avaliação da informação arquivística (RJCAIA) se vier a concretizar. A proposta de diploma previa, entre outros aspetos: • A revogação do Decreto-Lei n.º 447/88, que regula a pré-arquivagem, implicando a substituição da publicação das atuais portarias de gestão de documentos no “Diário da República” por mecanismos de simplificação do processo de aprovação de tabelas de seleção e sua publicitação através da plataforma CLAV; • A atribuição de valor probatório aos documentos digitalizados de acordo com requisitos pré-definidos; • O alargamento do âmbito subjetivo do novo diploma legislativo, abrangendo mais entidades do que as que vinham expressas no Decreto-Lei n.º 447/88; • A elaboração de um Regulamento Geral de Classificação e Avaliação, a aprovar pelo Diretor-Geral da DGLAB, que permitisse complementar a proposta de Decreto-Lei, especificando os procedimentos necessários para a implementação nestas áreas, bem como nas áreas do registo, transferência e substituição de suporte e preservação digital; • A responsabilização dos produtores e detentores de informação pública. A proposta de diploma que se encontra em tramitação, foi discutida no âmbito interministerial, não tendo sido concluído este processo na atual legislatura governamental. Esta situação tem como consequência a manutenção da morosidade dos processos de aprovação das portarias, como é o caso da PGD da Administração Local, concluída e remetida em 2018 para o Gabinete do Secretário de Estado das Autarquias Locais. Outra consequência é a manutenção dos procedimentos de digitalização, que todos os dias são efetuados aquando da captura de documentos em sistemas de gestão de documentos (SGD) e sistemas de informação da área de negócio (business systems - BS), sem garantia legal de valor probatório. Na ausência do RJCAIA a plataforma CLAV teve de ser adaptada de forma a responder ao Decreto-Lei 447/88. [7] 2.2 resumo Neste capítulo expôs-se a evolução do arquivo em Portugal, começando com o Decreto-Lei nº29 de 1972 até à criação da plataforma CLAV, a pegada do século XXI na gestão do arquivo português. Foram descritos todos os problemas inicialmente vividos que se refletiram em enormes quantidades de documentação acumulada e má gestão, causando eliminações descontroladas e conservações inúteis da mesma. Além disso, foram elucidadas as iniciativas criadas para resolver esses problemas, entre elas destacam-se as iniciativas mais recentes, a MEF, a harmonização de classes de 3º nível e a ASIA, que contribuíram para o desenvolvimento da LC, um referencial comum para todas as instituições públicas poderem classificar e avaliar a sua documentação à priori da geração. Por fim, abordou-se a plataforma CLAV e qual o seu impacto para resolver os problemas vividos ao desmaterializar o processo de arquivo. 3 C L AV: O P O N T O D E PA R T I DA A plataforma CLAV é um projeto com alguns anos de desenvolvimento possuindo já implementações de conceitos importantes. Sendo assim, é obrigatório nesta dissertação fornecer um capítulo para descrever o estado inicial da CLAV e as tecnologias usadas, tendo como intuito, fornecer uma visão mais abrangente sobre o projeto permitindo assim nos capítulos seguintes fazer a ponte de ligação com a implementação dos RADA de forma mais intuitiva. 3.1 funcionalidades implementadas Como conceitos fundamentais já implementados surgem a entidade, tipologia de entidade, legislação e tabela de seleção criada a partir da LC. De seguida, cada uma das funcionalidades da plataforma será descrita e elucidada. A edição, criação ou novos pedidos de cada uma destas funcionalidades seguintes está restrita a utilizadores com as devidas permissões. 3.1.1 Entidade e Tipologia de Entidade Na CLAV existe um catálogo de entidades e tipologias de entidade. Uma entidade é a representação de uma entidade pública que faz parte do governo português, por exemplo um hospital, uma câmara municipal e mais especificamente, a DGLAB, entidade para o qualquer este projeto de software está a ser desenvolvido. Por outro lado, a tipologia de entidade é um conceito que pretende agregar as entidades que partilham determinadas características. Em termos práticos, uma entidade pode também estar associada a várias tipologias. São exemplos de tipologias de entidade as Forças Armadas e as Autarquias Locais. A plataforma CLAV permite a um utilizador efetuar pedidos para criação e edição de entidades e tipologias de entidade. 3.1.2 Legislação ACLAV possuí também um catálogo de legislações sendo que cada uma representa um elemento que regula e enquadra outros instrumentos, como o RADA e os seus componentes, uma TS ou os processos de negócio representados na LC. Um utilizador autorizado pode criar um pedido de criação ou edição de certa legislação. 9 3.2. Arquitetura e Tecnologias 10 3.1.3 Lista Consolidada Como descrito no capítulo anterior, a LC é um catálogo nacional com uma estrutura hierárquica de classes que representam funções, subfunções e processos de negócio executados pelos organismos da administração pública. Para melhor gerir esta estrutura permitindo o seu crescimento e manutenção, a CLAV permite aos utilizadores criarem pedidos de criação e edição de classes pertencentes à LC. Para além disso, disponibiliza a todos os utilizadores a possibilidade de consultar as classes na estrutura com certos filtros. 3.1.4 Tabela de Seleção A tabela de seleção pode integrar PGD ou RADA [ 3 ]. No início desta dissertação existia na CLAV o conceito de tabela de seleção criada a partir da LC. A TS é um subconjunto da LC sendo aplicada por uma ou mais entidades, ou tipologia de entidade contendo os processos de negócio que a entidade ou tipologia de entidade efetua. A partir do momento que a TS é aprovada fica congelada no tempo enquanto a LC continua e evoluir. Na plataforma é possível um utilizador com as devidas permissões criar um pedido de criação para uma TS organizacional ou pluriorganizacional. Para tal, o utilizador pode utilizar uma interface de criação assistida ou importar diretamente um ficheiro para a plataforma. Após a validação e aprovação efetuada pela DGLAB, a TS entrará em vigor e estará disponível para consulta na plataforma. 3.1.5 Workflow de Pedidos A plataforma permite a utilizadores específicos que tenham a possibilidade de gerir o workflow de pedidos da plataforma. Para tal, disponibiliza um conjuntos de interfaces e mecanismos que permitem uma gestão e validação rigorosa dos pedidos de criação submetidos para poderem ser aprovados e inseridos na plataforma. 3.2 arquitetura e tecnologias Sendo a concretização desta dissertação um trabalho a efetuar depois de várias equipas já terem trabalhado durante vários anos na plataforma, as tecnologias a usar já se encontram bem definidas. Sendo assim, a plataforma CLAV possuí uma arquitetura com várias camadas. Figura 3: Arquitetura da Plataforma CLAV . 4.1. Especificação do RADA 17 4.1.2 Tabela de Seleção É também um componente principal do RADA e consiste numa estrutura hierárquica de classes cujo último nível fixa os prazos de conservação administrativa e o destino final da documentação objeto de avaliação. A estrutura hierárquica reflete a estrutura orgânica da entidade/tipologia produtora da documentação e/ou a sua própria organização. A tabela de seleção do RADA é na realidade um seleção de elementos de classes Área Orgânico-Funcional , Série e Subsérie . Relação com outra classe Elementos Informativos Atributos Área Orgânico-Funcional Série/Subsérie 1. Zona de Identificação Código X Título X 2. Zona de Descrição e Avaliação Código de classe X X Título X X Descrição X X Prazo de Conservação Administrativa X Forma de Contagem X Destino Final X Notas X Tabela 3: Descrição da Tabela de Seleção do RADA. 4.1.3 Classe Área Orgânico-Funcional Este tipo de classe é representativa da organização da documentação objeto de avaliação e podem ser de vários níveis: •Classe N1 Classe de primeiro nível. Pode corresponder a uma unidade orgância ou a uma área temático-funcional. •Classe N2 Constitui uma classe de segundo nível. Pode corresponder a uma sub-unidade orgânica ou a uma sub-área temático-funcional. •Classe N3 São classe de terceiro nível. Pode corresponder a uma sub-sub-divisão da unidade orgânica ou da área temático-funcional. 4.1. Especificação do RADA 18 Elemento Informativo Definição do elemento informativo Atributo Relação com outra classe 1. Identificação Código Identificador da classe atribuído pela entidade produtora ou elemento do quadro de classificação criado em contexto de avaliação ou descrição. X Título Designação da classe X 2. Zona Descritiva Descrição Caracterização da classe através de uma exposição dos seus traços distintivos X Tabela 4: Descrição da Classe Área Orgânico-Funcional. 4.1.4 Classe Série/Subsérie Estes tipos de classes fazem também a representação da organização da documentação objeto de avaliação, podendo ser de dois níveis diferentes representando a materialização de séries e subséries. Qualquer classe série terá que ser descendente de uma classe área orgânico-funcional, e qualquer classe subsérie terá que ser descendente de uma classe série. As decisões de avaliação concretizam-se no último nível da tabela de seleção, estando presentes nestas classes. Os elementos informativos da classe série ou subsérie agrupam-se em quatro zonas: 1. Zona de identificação Conjunto de elementos que identificam a classe; 2. Zona de descritivo Conjunto de elementos que descrevem a classe e caracterizam a sua materialização; 3. Zona de contexto de avaliação Conjunto de elementos que enquadram e informam as decisões de avaliação, nomeadamente os diplomas jurídico-administrativos relevantes e as relações com outra documentação; 4. Zona de decisões de avaliação Conjunto de elementos relativos à determinação do prazo de conservação administrativa (PCA) e destino final (DF) da documentação objeto de avaliação e respetivas justificações. 4.1. Especificação do RADA 19 Elementos Informativos das Classes Atributo Relação com outra classe Classe Série Classe Subsérie Condição 1. Identificação Código O O X Título O O X 2. Zona Descritiva Data Inicial da Documentação O F Se UI existir, senão é um atributo Data Final da Documentação O F Se UI existir, senão é um atributo Descrição O O X Tipo de Unidade Arquivística O - X Série aberta/fechada O - X Suporte O - X Medição O - X Localização O - X 3. Zona de Contexto de Avaliação Produtor(es) da documentação avaliada O - Entidades Legislação O - Legislação Código série/subsérie relacionada O O Série/Subsérie Tipo de relação série/subsérie relacionada O O Série/Subsérie 4. Zona de decisões de Avaliação Prazo de conservação administrativa (PCA) C O Obrigatório se não existir subsérie Forma de contagem do PCA C O Obrigatório se não existir subsérie Justificação do PCA C O Obrigatório se não existir subsérie Série/Subsérie Destino Final(DF) C O Obrigatório se não existir subsérie Série/Subsérie Justificação do Destino Final C O Obrigatório se não existir subsérie Série/Subsérie Notas F F X Tabela 5: Descrição da Série/Subsérie. O= Obrigatório; C= Condicional; F= Facultativo; -= Não aplicável; De seguida, serão descritos todos os campos presentes nestas classes. Identificação •Código: Identificador da classe atribuído pela entidade produtora; •Título: Designação da classe. Descrição •Data Inicial da Documentação: Indicação da data inicial da documentação; 4.1. Especificação do RADA 20 •Data Final da Documentação: Indicação da data final da documentação; • Descrição: Caracterização da classe através de uma exposição dos seus traços distintivos. Tem em conta os elementos formais e de conteúdo das unidades de arquivo no caso das séries e subséries; • Tipo de Unidade Arquivístiva: Indicação do tipo de série. Pode assumir um dos quatro valores seguintes: PROCESSO – unidade arquivística constituída pelo conjunto dos documentos referentes a qualquer ação administrativa ou judicial sujeita a tramitação própria (ex.: processos de concurso público para aquisição de bens e serviços); COLEÇÃO – unidade arquivística constituída por um conjunto de documentos de arquivo, organizada para efeitos de referência (ex.: copiadores de correspondência expedida) ou de acordo com critérios de arquivagem (ex.: coleções de documentos de despesa); DOSSIER – unidade arquivística constituída por um conjunto de documentos coligidos com o fim de informar uma decisão pontual (ex: dossiers da visita ao Japão); REGISTO – unidade arquivística elaborada para efeitos de controlo e descrição da documentação produzida e/ou recebida por uma entidade (ex: registo de correspondência) ou para efeito de prova de atos, factos ou acontecimentos (registo de nascimento). • Série aberta/fechada: Indicação sobre a continuidade da série. Poderá ser preenchido com um dos dois valores seguintes: ”Aberta”ou ”Fechada”; •Suporte: Identificação dos suportes da documentação objeto de avaliação; • Medição: Indicação quantitativa da dimensão. A unidade de medida depende do tipo de suporte, metros lineares para o papel. GigaBytes para o digital; •Localização: Identificação dos locais físicos onde se encontra a documentação objeto de avaliação. Contexto de Avaliação A zona de contexto é constituída por relações com outras classes. • Produtor(es) da documentação avaliada: Relação com entidades; nome da(s) entidade(s) que produziu ou recebeu a documentação objeto de avaliação; • Legislação: Relação com diplomas legislativos; indicação dos normativos (ex.: lei, decreto-lei, portaria, diretiva, norma, regulamento, instrução, despacho ou outro) que determinam a produção documental ou os seus Prazo de Conservação Administrativa (PCA) ou Destino Final (DF) . • Código série/subsérie relacionada: Código da(s) série(s) com as qual(ais) a série objeto de avaliação se relaciona; • Tipo de relação série/subsérie relacionada: Tipo de ligação/ relação existente entre a série objeto de avaliação e a(s) série(s) relacionada(s). Preencher com um, ou mais, dos quatro valores seguintes: 4.1. Especificação do RADA 21 RELAÇÃO COMPLEMENTAR - quando o conteúdo informativo da série em análise se relaciona como o de outra série, adicionando um ao outro informação complementar; RELAÇÃO DE SÍNTESE - quando a série em análise condensa a informação de outra (ou parte da informação) ou é condensada. Utilizar no primeiro caso a indicação ”Síntese (sintetiza)”, no segundo caso ”Síntese (sintetizada)”; RELAÇÃO DE SUCESSÃO - sequência ou sucessão: quando a série em análise sucede ou antecede outra. Utilizar no primeiro caso a indicação ”Sequência (sucessora)”, no segundo caso ”Sequência (antecessora)”; RELAÇÃO SUPLEMENTAR - quando o conteúdo informativo da série em análise deriva da observação e confronto da informação de outra(s) série(s), não adicionando conteúdo informativo a esta(s), mas necessitando dela(s) para a sua produção informacional. Decisões de avaliação • Prazo de conservação administrativa: Indicação do prazo, definido em anos, durante o qual a informação deve ser mantida sob responsabilidade do serviço produtor para responder às necessidades de negócio, requisitos organizacionais, responsabilização e obrigações legais; •Forma de contagem do PCA: Instrução relativa ao momento que origina a contagem de PCA; • Justificação do PCA: Indicação dos critérios que fundamentam o prazo de conservação administrativo. CRITÉRIO LEGAL - critério que advém da existência de diploma(s) legal(ais). Toma como base o disposto em diplomas legais. Sendo que a determinação do PCA pode derivar diretamente da lei (aplicação direta sempre que o diploma dispõe sobre o PCA) ou ser inferida a partir de uma disposição sobre o prazo de prescrição ou caducidade do procedimento, da atuação dos responsáveis ou sobre os direitos firmados (ex.: Prazo prescricional do procedimento contraordenacional previsto no, art.º 27.º, do DL 433/82, Ilícito de mera ordenação social, e diplomas que o alteram); CRITÉRIO DE UTILIDADE ADMINISTRATIVA - toma como base a utilização obrigatória da informação constante numa série para que outra possa ser processada, desencadeada ou apuradas conformidades ou desconformidades. Este critério é percecionado a partir do tipo de relação entre séries, nomeadamente o suplementar. (ex.: Prazo necessário para o processamento da série ”Recolha e tratamento de dados estatísticos de apoio à gestão”); CRITÉRIO GESTIONÁRIO - aplicável nas situações em que a responsabilização politico-gestionária e a avaliação do mérito do planeamento estratégico apenas pode ser efetuada por meio de escrutínio público (eleições) ou pela não recondução no mandato (ex.: Prazo para imputação de responsabilidade pela gestão estratégica, decorrente de escrutínio público (eleições). • Destino final: Indicação do destino final da série ou subsérie, aplicável aos processos e documentos após o cumprimento do prazo de conservação administrativa. Identificado por ”C”para a conservação permanente integral de todas as unidades arquivísticas, por ”CP”para conservação permanente parcial por amostragem ou por ”E”para a eliminação integral; 4.1. Especificação do RADA 22 •Justificação do DF: Indicação dos critérios que fundamentam o destino final. CRITÉRIO LEGAL - critério aplicado a séries cujo destino final se encontra definido, direta ou indiretamente, em diploma legal (exemplo para justificação da eliminação: Lei n.º 166/99, Lei Tutelar educativa, art. 132ª, nº 5 ”Os dossiers são obrigatoriamente destruídos decorridos cinco anos sobre a data em que os jovens a quem respeitam completarem 21 anos”; exemplo para justificação da conservação: DL 140/2009 estabelece o dever de elaboração do relatório final e o respetivo arquivo, para constituir a indispensável memória dos trabalhos de proteção e valorização do património cultural [Preâmbulo]); CRITÉRIO DE DENSIDADE INFORMACIONAL - critério aplicado a séries que mantêm entre si uma relação assimétrica de síntese de informação. Implica a identificação da série que sintetiza e da que é sintetizada, valorizando a conservação da série sintetizadora e possibilitando a eliminação da série sintetizada (ex.: a relação de síntese entre as séries ”Relatórios de atividades setoriais”e ”Relatórios de atividades anuais”permite justificar a primeira como de eliminação e a segunda de conservação); CRITÉRIO DE COMPLEMENTARIDADE INFORMACIONAL - critério aplicado a séries que mantêm entre si uma relação complementar. Implica uma análise de contexto, para percecionar de que modo é necessária a informação constante de uma série, para compreender outra série, complementando-se entre si. Valoriza de forma idêntica a conservação das partes que permitem o entendimento do todo (ex.: Os planos de atividade e os relatórios de atividade, complementam-se, permitindo conhecer a relação entre o que foi proposto e o que foi executado). • Notas: Registo de considerações suplementares que se julgue conveniente referir para melhor informar o processo de avaliação. 4.2. Requisitos 23 4.1.5 Unidade de Instalação É um conceito que contém a identificação e caracterização das unidades arquivísticas do objeto de avaliação. Pode ser uma caixa, livro, armário, entre outros. Elemento Informativo Definição do Elemento Informativo Atributo Relação com outra classe Código Identificador da unidade de instalação atribuído para efeitos do RADA X Código de Classificação Código atribuido à unidade de instalação pelo serviço produtor X Título Denominação atribuída à unidade de instalação pelo serviço produtor X Data inicial da Documentação Data inicial da documentação da unidade de instalação X Data final da Documentação Data final da documentação da unidade de instalação X Entidade Produtora Nome da entidade produtora da UI Entidade Tipologia da Entidade Produtora Nome da tipologia de entidade que produziu ou recebeu documentação Tipologia de Entidade Série/Subsérie Identificação da série ou sub-série da unidade de instalação Série/Subsérie Descrição Descrição da unidade de instalação. X Notas Registo de considerações suplementares que se julgue conveniente referir para melhor informar o processo de avaliação X Localização Identificação do espaço fisico da unidade de instalação. Deve ser considerado o depósito, a estante e a prateleira X Tabela 6: Descrição da Unidade de Instalação. 4.2 requisitos Depois da especificação do domínio de dados sobre a qual esta dissertação está debruçada, o RADA, está-se agora em condições de se expor todos os requisitos funcionais impostos pela DGLAB sendo o objetivo desta dissertação. A plataforma CLAV tem que ser capaz de: • Permitir a criação de um pedido de criação de um RADA através de uma interface de criação assistida e através da importação de ficheiros csv com os constituintes do mesmo. 4.3. Resumo 24 • Durante a etapa de criação, o utilizador tem que ser capaz de guardar o estado do trabalho desenvolvido até então. Isto pode garantir que não perde o trabalho durante o processo ou então permitir continuar mais tarde. Para além disso, o utilizador deve ser capaz de criar novas entidades e legislação não presente na plataforma CLAV durante o processo. • Possibilitar a gestão do pedido de um RADA no workflow de pedidos. Permitindo analisar, validar, consultar, devolver ou aprovar o pedido dependendo da etapa em que se encontra. • Guardar a informação relativa ao RADA na ontologia da plataforma. • Expor um RADA inserido na plataforma numa interface web e permitir o seu download em pdf . • Permitir um utilizador com as permissões corretas de revogar um RADA inserido na plataforma, retirando o de vigor. De seguida, apresenta-se o diagrama de use case onde estão presentes os requisitos descritos anteriormente associando com o tipo de utilizador que a pode concretizar. Figura 5: Diagrama use case da implementação do RADA 4.3 resumo Foi neste capítulo que se expôs a especificação pormenorizada do RADA abordando numa primeira fase os seus constituintes principais, RE eTS. Após abordar cada campo constituinte do RE, foi descrita a TS e todas as 4.3. Resumo 25 classes constituintes, classe àrea orgânica funcional, classe série e subsérie, explicitando todos os constituintes e relações entre as mesmas. Também se expôs o conceito de unidade de instalação revelando todos os campos constituintes e relações com as classes série e subsérie. Após a descrição do domínio de dados foram descritos os requisitos impostos pela DGLAB. Requisitos esses, que põem em prática o uso do RADA na plataforma, sendo então os objetivos de implementação desta dissertação. 5 CRIAÇÃO DO PEDIDO RADA Implementar todos os requisitos é o objetivo principal desta dissertação contudo foi necessário priorizar os requisitos por relevância e precedência. Pareceu lógico que a criação de um pedido para a inserção de um RADA na plataforma fosse o primeiro objetivo a atacar. Todo o fluxo do RADA na plataforma começa com a criação do pedido. Para atingir este objetivo foi necessário construir um conjunto de interfaces na aplicação web da plataforma. Relativamente à API, esta já possuía rotas capazes de suportar a criação de pedidos e trabalhos pendentes, bem como acesso a informação de entidades, tipologias de entidades e legislação. Sendo o RADA um novo elemento na plataforma, foi criado no menu das operações da plataforma a interface que permite ao utilizador efetuar a consulta de um RADA já aprovado ou a criação de um pedido para um novo elemento. 5.1 criação assistida Como primeiro grande objetivo, surge a implementação da interface de criação assistida. Nela o utilizador terá que ser capaz de criar um pedido para um novo RADA preenchendo todos os campos constituintes e especificados na seção anterior, através de um formulário online . Para além disso, essa interface teria que possibilitar a criação de novas entidades e legislação como também, a possibilidade de guardar o progresso durante o processo de preenchimento do RADA. Caso o utilizador selecione no painel de operações a opção de criação, entrará na interface de criação assistida em https://clav.dglab.gov.pt/rada/criar. 26 5.1. Criação Assistida 33 Apesar de a interface tornar o preenchimento simples, existem múltiplas e complexas regras para os relacionamentos: • Cada série pode ter múltiplas relações contudo só pode ter uma relação com cada classe; • Uma classe não pode ter uma relação consigo própria; • Caso a série tenha um relacionamento de síntese, apenas o pode ter num sentido, ou seja, se tiver o relacionamento de ”síntese de”com alguma classe, nunca poderá ter o inverso ”sintetizado por”; • Os relacionamentos só podem acontecer com outras classes séries ou subséries; Todas estas regras são verificadas automaticamente pelo sistema impedindo a criação de um relacionamento caso alguma se quebre. Após adicionar uma nova relação, esta irá surgir numa tabela na interface . Se o utilizador clicar sobre uma classe adicionada como relação surge a seguinte interface : Figura 15: Interface para visualizar classe adicionada como relação Esta interface permite ao utilizador ter uma visão da classe relacionada enquanto preenche uma nova facilitando o trabalho de preenchimento. 5.1. Criação Assistida 34 Zona de Decisões de Avaliação Figura 16: Interface de criação assistida na zona de decisões de avaliação da classe Série. Nesta zona de preenchimento, o utilizador terá que preencher um conjunto de campos relativos à determinação do prazo de conservação administrativo e do destino final, bem como as suas justificações. Relativamente à zona do PCA, o utilizador terá que preencher o campo do prazo de conservação administrativo e/ou o campo da nota do PCA, e a forma de contagem. Caso a forma de contagem seja ” Conforme disposição legal ”, irá surgir o campo da subforma de contagem que o utilizador terá obrigatoriamente que preencher. No campo da justificação do PCA o preenchimento é quase automático. Existem três critérios, como antes referido, que podem ser adicionados: •Critério Gestionário: adicionado através de um botão, pode ser alterado ou até removido; • Critério Legal: adicionado através de um botão, pode ser alterado ou removido. Neste critério surge a legislação adicionada na zona de contexto de avaliação. Cada legislação associada ao critério pode ser removida, contudo, se for removida na zona de contexto de avaliação e se o critério legal estiver ativo é automaticamente removida; • Critério de Utilidade Administrativa: surge automaticamente quando for adicionada uma relação de ”suplemento para” com uma outra série ou subsérie. Apenas pode ser removido se as relações forem removidas; Em paralelo, no preenchimento da justificação do destino final, surgem também três critérios que podem ser adicionados: •Critério de Legal: exatamente como o critério legal presente na justificação do PCA; • Critério de Complementaridade Informacional: surge automaticamente quando for adicionada uma relação de ”complemento de” com uma outra série ou subsérie. Apenas pode ser removido se as relações forem removidas; 5.1. Criação Assistida 35 • Critério de Densidade Informacional: este critério possuí duas vertentes mas surgem ambas automaticamente. Primeira vertente surge quando a série tem relações de ”síntese de” e a outra aparece quando existem relações de ”sintetizado por” . Ou seja, como estas relações não podem coexistir, este critério nunca vai ter as duas vertentes ao mesmo tempo. Apenas pode ser removido se as relações forem removidas; Para além disso, estes critérios na justificação do destino final implicam também um preenchimento automático do campo do destino final. Caso o critério de complementaridade informacional esteja presente na justificação, o destino final é obrigatoriamente a conservação da documentação. Caso não exista critério de complementaridade mas sim de densidade informacional, o destino final vai depender da vertente do critério. Se possuí relações de ”síntese de” o destino final será a conservação, caso contrário será a eliminação. Se nenhum dos critérios estiver presente o utilizador terá que preencher manualmente o campo do destino final e/ou o campo da nota sobre o destino final, sendo o preenchimento obrigatório. Após terminar o preenchimento da classe série o utilizador terá que clicar no botão adicionar para assim inserir a classe no conjunto de classes já adicionadas durante o preenchimento. Contudo as ações do sistema para a criação da classe série não acabam por aqui, sendo o sistema responsável pelas seguintes operações: • Criação das novas unidades de instalação que poderão ter sido criadas na zona descritiva; • Criação das novas classes que poderão ter sido criadas nos relacionamentos na zona de contexto de avaliação; • Adicionar a todas as classes que foram indicadas nos relacionamentos a respetiva relação inversa bem como todas as consequências que advêm dessa relação, como critérios na justificação do PCA e critérios na justificação do DF, que como dito anteriormente, implicam o novo cálculo do destino final dessa classe. É de salientar que uma classe série pode não possuir zona de decisões de avaliação caso possua uma classe subsérie como filha pois a decisão de avaliação está sempre no nível baixo da hierarquia. 5.1.6 Classe Subsérie A criação de uma classe subsérie em pouco difere de uma classe série existindo pequenas alterações que serão apresentadas de seguida. Figura 17: Interface de criação assistida da classe Subsérie. 5.1. Criação Assistida 36 Aqui tal como nas outras classes o código também terá que ser único, sendo o sistema responsável por essa validação. Zona Descritiva Figura 18: Interface de criação assistida na zona descritiva da classe subsérie. Como se pode verificar esta zona mantém apenas alguns dos campos presentes na mesma zona na classe série mantendo a mesma funcionalidade. Nos campos da data inicial e final foi implementado um mecanismo que permite herdar automaticamente as datas da série pai. Esta interface permite também ao utilizador associar a subsérie a unidades de instalação ainda não existentes, sendo criadas no final do preenchimento da classe subsérie. Zona de Contexto de Avaliação Figura 19: Interface de criação assistida na zona de contexto de avaliação da classe subsérie. Nesta zona de preenchimento, ao contrário da série que possuí outros campos, na subsérie apenas existe o campo para criar relacionamentos. As mesmas regras se mantêm, sendo o sistema responsável por fazer as validações necessárias impedindo a adição de relações inválidas e criando as classes não existentes até então. 5.1. Criação Assistida 37 Zona de Decisões de Avaliação Figura 20: Interface de criação assistida na zona de decisões de avaliação da classe subsérie. A zona de decisões de avaliação é extremamente semelhante à classe série. Exceto o preenchimento dos critérios legais presentes na justificação do PCA eDF. Como a subsérie não tem legislação associada, para adicionar o critério à respetiva justificação o utilizador necessitará primeiro de preencher o campo legislação da classe série pai. Com esse campo preenchido a legislação associada ao seu pai é importada para o critério legal da subsérie que o utilizador está a preencher, aparecendo o botão que permite realizar a operação. Caso, alguma legislação seja removida na classe pai, o sistema automaticamente irá atualizar o critério legal na respetiva classe subsérie. 5.1.7 Unidade de Instalação Figura 21: Interface de criação assistida da unidade de instalação. 5.1. Criação Assistida 38 Para criar uma nova unidade de instalação o utilizador terá que preencher obrigatoriamente todos os campos presentes. À semelhança do que acontece nas classes, os códigos são únicos sendo o sistema responsável por essa validação. Relativamente às entidades ou tipologias produtoras, tal como nas classes, apenas se pode escolher a partir das classes selecionadas no RE, ficando bloqueadas quando associadas a uma unidade de instalação. Na zona da associação com séries ou subséries, poder-se-á adicionar as classes desejadas. Caso não existam, o utilizador terá que fornecer o tipo e título da classe para ser criada posteriormente. Contudo, estas associações têm regras a serem cumpridas, o sistema é responsável pela sua validação para permitir associar a unidade de instalação à classe: • A classe associada tem que ser uma série ou subsérie; • A classe associada não pode ter a data inicial e final não preenchidas; • A data inicial e final da classes associadas tem que estar compreendidas entre as datas da unidade de instalação; • A mesma unidade de instalação não se pode associar mais que uma vez à mesma classe. Após o utilizador premir o botão adicionar insere a unidade de instalação. Contudo o sistema terá ações adicionais a fazer, criando todas as classes não existentes que foram associadas e adicionar a todas as classes a informação que permite saber que está relacionada com respetiva unidade de instalação. Após a inserção de algumas classes e unidades de instalação a interface da TS apresenta a seguinte visualização: Figura 22: Tabela de seleção com classes e unidades de instalação adicionadas em formato de àrvore. Neste modo de visualização, as classes encontram-se organizadas em árvore para ser mais intuitivo perceber a hierarquia presente na TS. Para auxiliar o utilizador as classes que estão incompletas encontrar-se-ão identificadas com um asterisco vermelho, aparecendo a mensagem de aviso apenas quando alguma classe se encontrar incompleta. 5.1. Criação Assistida 39 Para alterar o modo de visualização das classes, o utilizador terá que clicar no botão switch presente do lado direito da barra de pesquisa de classes. Figura 23: Tabela de Seleção com classes e unidades de instalação adicionadas em formato de tabela. Este modo de visualização tem a vantagem de mostrar mais explicitamente os dados das classes, permitindo ao utilizador uma melhor percepção da informação preenchida. Também neste modo de visualização, uma classe incompleta é sinalizada na coluna mais à direita com o ícone como demonstrado na figura acima. Relativamente às unidades de instalação, estas encontram-se listadas abaixo. Se a linha da tabela estiver vermelha significa que essa unidade de instalação está incompleta tendo o utilizador que a preencher totalmente. É possível editar todas as classes criadas até então premindo por cima da respetiva classe na árvore ou no ícone mais à esquerda presente em cada linha da tabela de classes. O mesmo se aplica às unidades de instalação em que se pode premir por cima da linha correspondente da tabela. 5.1.8 Edição durante Criação Edição de Classes Para editar as classes são utilizadas as mesmas interfaces presentes no modo de criação. A partir do momento que o utilizador deseja editar uma classe é efetuado um clone da classe original de modo a não destruir a informação original presente no sistema. Relativamente às classes área orgânico-funcional não existem problemas subjacentes à sua edição. Quando o utilizador desejar atualizar os dados, todos os valores originais da classe serão substituídos. Por outro lado na edição da classe série e subsérie o processo torna-se mais complexo. Após o utilizador decidir que pretende atualizar os dados para além de todos os campos originais da classe serem atualizados, o sistema efetua as seguintes operações: • Verifica as novas unidades de instalação associadas. Caso tenha novas unidades de instalação, cria-as e adiciona a informação para ligar a unidade de instalação à classe. Caso tenha removido alguma, tem que eliminar a informação que liga a unidade de instalação à classe; 5.1. Criação Assistida 40 • Fazer a gestão das relações, criando novas classes se necessário, adicionando ou removendo relações inversas, actualizar os critérios e o destino final que depende desses critérios. • Se for uma classe série, verificar se foi removida alguma legislação na zona de contexto de avaliação, para assim remover dos critérios legais presentes nas subséries que são suas filhas. É importante salientar que é possível alterar a classe pai em todas as classes exceto na subsérie. Essa ação exige um recalculo de toda a hierarquia, ficando a cargo do sistema. A alteração do código de uma classe também é proibida pelo mesmo. Edição de Unidades de Instalação Tal como nas classes, na edição de uma unidade de instalação é feito um clone aos dados originais sendo injetados na mesma interface usada na criação. Após o utilizador decidir atualizar os dados da unidade de instalação todos os campos originais são substituídos sendo o sistema responsável por atualizar as classes associadas à unidade de instalação, adicionando ou removendo a relação e/ou até criar novas classes. Criação de Elementos por Cópia A interface de criação assistida permite ainda criar uma classe série, subsérie ou unidade de instalação por cópia de um elemento do mesmo tipo já inserido durante o preenchimento. Para copiar uma classe, o utilizador terá que passar o rato por cima da classe desejada no modo de visualização de classes em árvore surgindo do lado direito um ícone . Se o utilizador premir irá iniciar o processo de cópia, surgindo a mesma interface de criação usada para o elemento em questão, sendo o utilizador capaz de completar o processo de cópia com as alterações necessárias. Para criar uma unidade de instalação por cópia, o utilizador tem premir no ícone à esquerda da unidade de instalação desejada, sendo o restante procedimento igual ao descrito acima para a classe. Eliminação É também permitido ao utilizador eliminar qualquer elemento já preenchido. Caso pretenda eliminar um elemento terá que abrir o mesmo em modo de edição e clicar no botão de eliminar. Após confirmar a ação o sistema é responsável por eliminar todas as dependências que elemento possa ter com outros elementos. 5.2. Criação através de Importação 41 5.2 criação através de importação Como segundo objetivo e requisito para criar um pedido para criação de um RADA, surge a criação através da importação de ficheiros csv que contêm a informação necessária para o preenchimento automático dos campos necessários. Como já foi revelado em imagens na secção anterior, os mecanismos para a importação do RADA estão presentes na interface de criação assistida trazendo uma excelente simbiose para o utilizador permitindo a importação e uma possível adição e/ou edição a qualquer momento ou vice-versa. O utilizador poderá importar três secções distintas nesta interface , o RE, as classes pertencentes à TS e as unidades de instalação. Contudo para completar o preenchimento total do RADA terá que preencher manualmente a secção da informação geral. Figura 24: Botão de importação do relatório expositivo. Figura 25: Botão de importação das classes e unidades de Instalação. Após clicar em algum botão para importação, a seguinte interface irá surgir: Figura 26: Popup para importação de ficheiro para o relatório expositivo. É nesta interface que o utilizador terá que carregar o ficheiro desejado sendo o sistema responsável por analisar e validar todos os dados seguindo todas as regras expostas no capítulo anterior. Se algum campo for inválido o sistema impossibilitará a importação, tornando visível numa caixa de texto todos os problemas encontrados para que o utilizador possa corrigir o respetivo ficheiro. Em relação à importação de classes e unidades de instalação o sistema permite uma união entre o que já possa ter sido preenchido e os dados que foram importados validando a existência, relações, critérios de justificação e o destino final. Caso surja alguma relação com alguma unidade de instalação ou classe não existente, o sistema irá criar essas novas classes, notificando o utilizador que a classe/unidade de instalação se encontra incompleta como demonstrado na secção anterior. 5.3. Pendentes 42 Um exemplo de ficheiro de importação para cada secção encontra-se disponível nos anexos desta dissertação. Todos os ficheiros possuem os campos necessários para o preenchimento por uma ordem definida, a alteração da ordem pode inviabilizar a importação ou então introduzir erros no preenchimento. Relativamente ao ficheiro de importação das classes pertencentes à TS, sugere-se que as classes sejam ordenadas por ordem hierárquica para automaticamente ser preenchido o campo classe pai . Os campos de múltiplas secções terão que ser preenchidos separando cada item com o caractere ’#’ (Anexo A.2). 5.3 pendentes A partir do momento que o utilizador entra na zona de preenchimento do RE é lhe permitido pelo sistema guardar o trabalho efetuado até então. Toda a informação preenchida é guardada juntamente com as novas entidades e legislações que possam ter sido criadas. Para cumprir-se esta funcionalidade usufruiu-se das rotas da API POST /pendentes capaz de criar um novo trabalho pendente e PUT /pendentes/:id responsável por atualizar um trabalho pendente já presente na plataforma CLAV. Estas rotas descritas já se encontravam implementadas aquando da implementação desta interface de criação do RADA. Para utilizar este mecanismo, está disponível o seguinte conjunto de botões na interface de criação assistida. Figura 27: Conjunto de botões para gerir o pendente no Relatório Expositivo. Figura 28: Conjunto de botões para gerir o pendente na Tabela de Seleção. Como se pode verificar através das imagens existem duas maneiras possíveis para guardar o trabalho desenvolvido. A primeira é quando o utilizador prime o botão Guardar Trabalho , neste caso o trabalho pendente é criado ou atualizado mantendo o utilizador na interface de criação do RADA. A segunda forma possível para guardar o trabalho, acontece quando o utilizador prime no botão Continuar Depois . Neste caso, o trabalho pendente é criado ou atualizado, sendo o sistema responsável por reencaminhar o utilizador para a página principal da plataforma. Após o pendente ter sido criado surge entre o conjunto de botões um novo botão que permite a destruição do pendente e consequente eliminação do trabalho efetuado até então. 6.1. Consulta de um pedido RADA 49 Figura 37: Interface do pedido. Tabela de Seleção em modo árvore. Para visualizar mais pormenorizadamente cada classe ou unidade de instalação, o utilizador terá que premir a linha da tabela do elemento que pretende visualizar. Contudo se as classes estiverem em modo de visualização de árvore, terá que premir o nome da classe. De seguida serão apresentadas as interfaces de cada elemento constituinte da TS. Classe Área Orgânico Funcional Figura 38: Interface do pedido. Classe Área Orgânico-Funcional. 6.1. Consulta de um pedido RADA 50 Classe Série Figura 39: Interface do pedido. Classe Série. Figura 40: Interface do pedido. Zona de Contexto de Avaliação da Classe Série. Figura 41: Interface do pedido. Zona de Decisões de Avaliação da Classe Série. 6.1. Consulta de um pedido RADA 51 Classe Subsérie Figura 42: Interface do pedido. Classe Subsérie. Figura 43: Interface do pedido. Zona de Contexto de Avaliação da Classe Subsérie. Figura 44: Interface do pedido. Zona de Decisões de Avaliação da Classe Subsérie. 6.2. RADA no workflow de pedidos 52 Unidade de Instalação Figura 45: Interface do pedido. Unidade de Instalação. 6.2 rada no workflow de pedidos A consulta do pedido RADA é a funcionalidade de menor relevância neste requisito sendo a mais relevante a adaptação do mecanismo que permite a análise, validação e aprovação do RADA no workflow de pedidos. Aquando da implementação desta dissertação tal mecanismo já se encontrava implementado suportando o pedido de criação para outros elementos possuindo cada um as suas próprias etapas de workflow . Sendo o RADA um novo conceito foi necessário adicionar o mesmo ao mecanismo com as suas etapas de workflow . Figura 46: Workflow do pedido de um RADA. Como demonstrado na figura acima, o pedido de criação de um RADA pode estar em cinco etapas diferentes. De seguida, irá se enumerar e especificar todas as etapas e respetivas implementações. É de salientar que este requisito é focado apenas na aplicação web estando já disponíveis as rotas da API para atualizar o pedido e criar o despacho de aprovação final. 6.2. RADA no workflow de pedidos 53 6.2.1 Pedido Novo Figura 47: Interface de pedidos novos. Nesta fase inicial do workflow o utilizador com acesso está bastante limitado às ações que pode tomar. Como primeira opção pode devolver de imediato o pedido, premindo o ícone da linha da tabela mais à direita. Um outra opção é encaminhar o pedido para a próxima fase, Apreciação Técnica , tendo neste caso que selecionar o utilizador responsável pelo pedido na nova fase. Por último, como demonstrado na secção anterior, pode apenas consultar o pedido. 6.2.2 Pedido em Apreciação Técnica Figura 48: Interface de pedidos em apreciação técnica. Quando o pedido se encontra em apreciação técnica o utilizador responsável pode efetuar três ações. Como na etapa anterior pode consultar o pedido contudo nesta é lhe permitido alterar o responsável do pedido na mesma etapa. Por último o utilizador pode analisar o pedido do RADA, tendo sido criada para esse efeito a seguinte interface . 6.2. RADA no workflow de pedidos 54 Figura 49: Interface de análise do pedido do RADA. É nesta interface que o utilizador vai fazer a primeira análise e validação dos campos preenchidos. Para tal, todos os campos possuem um mecanismo implementado que permite validar, invalidar, editar ou até escrever uma nota sobre o campo. Inicialmente todos os campos são válidos portanto têm uma cor verde contudo, caso seja invalidado ficará com a cor vermelha ou editado com a cor amarela. Este tipo de mecanismo com cores permite uma melhor percepção do estado de cada campo. Se um campo for invalidado ou editado será possível para o analista voltar a validar o campo. 6.2. RADA no workflow de pedidos 55 Relatório Expositivo Figura 50: Interface de análise do relatório expositivo do pedido do RADA. 6.2. RADA no workflow de pedidos 56 Tabela de Seleção Figura 51: Interface de análise da tabela de seleção do pedido do RADA. Na secção da TS foi implementado um mecanismo que permite ao utilizador ter uma percepção do estado de cada classe ou unidade de instalação sem ter que abrir cada uma, ou seja, se a classe/unidade de instalação possuir algum campo inválido esse elemento será marcado com um círculo de cor vermelha caso o elemento tenha apenas algum campo editado o círculo terá cor amarela. Se o elemento estiver completamente válido, será marcado com um círculo de cor verde. Classe Área Orgânico Funcional Figura 52: Interface de análise de uma classe Área Orgânico Funcional do pedido do RADA. 6.2. RADA no workflow de pedidos 57 Classe Série Figura 53: Interface de análise de uma Série do pedido do RADA. Figura 54: Interface de análise da zona de contexto de avaliação de uma Série do pedido do RADA. 6.2. RADA no workflow de pedidos 58 Figura 55: Interface de análise da zona de decisões de avaliação de uma Série do pedido do RADA. Classe Subsérie Figura 56: Interface de análise de uma Subsérie do pedido do RADA. 6.3. Resumo 65 válidas poderá devolver o pedido ao utilizador criador ou então enviar o pedido para a etapa anterior do workflow , Apreciação Técnica para voltar a ser analisado e validado. Figura 69: Interface de criação do despacho na etapa do workflow em despacho. Por fim, se o pedido for despachado irá avançar para a secção de Pedidos Aprovados da plataforma. Caso o pedido seja depositado na secção de Pedidos Aprovados ou Pedidos Devolvidos apenas será possível para um utilizador consultar o pedido através da interface apresentada na secção anterior. 6.3 resumo Durante este capítulo foi exposta a implementação por baixo de um dos requisitos mais importantes para operacionalizar o RADA na plataforma, o suporte do mesmo no mecanismo de workflow de pedidos da plataforma. Numa primeira fase foram demonstradas as interfaces construídas para permitir a consulta do pedido RADA. Sendo de seguida abordado o workflow do mesmo enumerando todas as suas etapas. Em cada etapa descreveu-se a implementação efetuada, mostrando todos os mecanismos e interfaces construídas para o efeito. É de realçar que para analisar e validar o pedido RADA foi construída uma interface completamente nova capaz de permitir a análise campo a campo mas também a disponibilização do histórico do pedido em outras etapas. 7 INSERÇÃO DO RADA NA PLATAFORMA Após a aprovação do pedido de criação de um RADA na última etapa do workflow , a plataforma tem que ser capaz de inserir na ontologia o novo elemento criado. Para tal foi necessário implementar uma nova rota na API e proceder à alteração do modelo de dados da ontologia da plataforma para acomodar o novo instrumento. Esta necessidade de implementação não representa alterações funcionais para o utilizador contudo é necessária para persistir o novo RADA na ontologia da plataforma. De seguida, serão expostas as alterações implementadas na ontologia e na API. 7.1 ontologia Tendo a plataforma CLAV vários anos, múltiplas equipas já trabalharam sobre a ontologia que foi inicialmente construída para acomodar a LC. Sendo a LC constituída por classes que partilham atributos e relações semelhantes às séries e subséries, certos conceitos importantes já se encontram especificados na ontologia, sendo eles o DF,PCA e respectivas justificações relacionadas com os critérios associados. 7.1.1 Alterações às Entidades Existem na ontologia do CLAV múltiplas entidades já especificadas que representam os elementos já presentes na plataforma. 66 7.1. Ontologia 67 Figura 70: Entidades presentes na ontologia. Para acomodar o RADA foram primeiramente adicionadas as entidades que representam o objeto RADA e os seus principais constituintes, RE eTS. Sendo assim, surgiram as seguintes entidades na ontologia: • RADA • Relatório Expositivo • TabelaSelecaoRADA De seguida, com o intuito de representar as classes pertencentes à TS foi criada uma entidade denominada, Classe_RADA , que possui as seguintes entidades descendentes: • Area_Organico • Serie • Subserie Paralelamente, foi criada a entidade UnidadeInstalacao que representa uma unidade de instalação. 7.1. Ontologia 68 7.1.2 Alteração aos Object Properties Como descrito no capítulo de especificação do RADA existem múltiplas relações entre os elementos do universo RADA que tiveram que ser criadas como object properties na ontologia. Tendo em conta as novas entidades descritas acima foram especificadas as seguintes as relações. RADA Sujeito Predicado Objeto RADA tem Tabela de Seleção RADA tem Relatório expositivo RADA aprovadoPor Legislação RADA revogadoPor Legislação RADA avaliaDocEliminadaPor Auto de Eliminação RADA avaliaDocProduzidaPor Entidade / Tipologia RADA eDaResponsabilidadeDe Entidade Tabela 7: Relações do RADA. Relatório Expositivo Sujeito Predicado Objeto Relatório Expositivo pertenceA RADA Relatório Expositivo avalia DocProduzidaPor Entidade Relatório Expositivo avalia DocProduzidaPor Tipologia de Entidade Tabela 8: Relações do Relatório Expositivo. Tabela de Seleção Sujeito Predicado Objeto Tabela de Seleção eParteDeRada RADA Tabela de Seleção temClasse Classe Série ou Subsérie Tabela de Seleção temClasse Classe Área orgânico-funcional Tabela 9: Relações da Tabela de Seleção. 7.1. Ontologia 69 Classe Área Orgânico-Funcional Sujeito Predicado Objeto Área orgânico-funcional pertenceA Tabela de Seleção Área orgânico-funcional ePaiDe Série Tabela 10: Relações da Área Orgânico-Funcional. Classe Série Sujeito Predicado Objeto Série éPaiDe Subsérie Série pertenceA Tabela de Seleção Série éFilhaDe Área orgânico-funcional Série produzidaPor Entidade Série produzidaPor Tipologia de Entidade Série reguladoPor Legislação Série éPaiDeUi Unidade de Instalação Série éReferenciada Auto de Eliminação Tabela 11: Relações da Série. Classe Subsérie Sujeito Predicado Objeto Subsérie pertenceA Tabela de Seleção Subsérie éFilhaDe Série Subsérie éPaiDeUi Unidade de Instalação Subsérie éReferenciada Auto de Eliminação Tabela 12: Relações da Subsérie. 7.1. Ontologia 70 Classe Unidade de Instalação Sujeito Predicado Objeto Unidade de instalação eFilhoDe Série / Subsérie Unidade de instalação produzidoPor Entidade / Tipologia Unidade de instalação referenciadaEm Auto de Eliminação Tabela 13: Relações da Unidade de Instalação. Toda esta lógica relacional pode ser melhor compreendida na seguinte imagem. Figura 71: Diagrama de Relações do Universo RADA . 7.1.3 Alterações aos Data Properties Devido ao trabalho desenvolvido por outros membros do projeto a grande maioria das data properties já se encontravam especificadas na ontologia, sendo assim, foi necessário associar as mesmas às novas entidades criadas. Para além disso foi necessário criar novas data properties referentes a campos não existentes e referentes aos elementos do RADA como especificado no capítulo correspondente. Após todo o trabalho de especificação desenvolvido no Protégé , a ontologia da plataforma ficou capaz de suportar o novo instrumento RADA. 7.2. API 71 7.2 api Relativamente à API foi necessário implementar uma série de rotas para acomodar a interação com o universo RADA. Todas as rotas estão protegidas, sendo apenas usadas por utilizadores com as permissões corretas. 7.2.1 POST /rada Como primeira implementação surge a rota POST /rada capaz de receber os triplos representativos do elemento RADA que se pretender adicionar à ontologia, sendo responsável por inserir e responder ao pedido se conseguiu fazer a inserção com sucesso ou não. É de salientar que a conversão do JSON representativo do RADA presente na base de dados MongoDB em forma de pedido é transformado em triplos por um mecanismo implementado na aplicação web aquando da aprovação final do RADA no workflow de pedidos. Figura 72: Rota POST /rada no Swagger . 7.2.2 GET /rada Para além da rota de criação, foram também criadas duas novas rotas na API. A primeira GET /rada capaz de listar todos os RADAs aprovados e presentes na plataforma, e por outro lado, a segunda GET /rada/:id que retorna um RADA com determinado id presente na ontologia. 7.3. Resumo 72 Figura 73: Rota GET /rada no Swagger . Figura 74: Rota GET /rada/:id no Swagger . De seguida será exposto, a utilidade destas novas rotas no lado da aplicação web para consulta de um RADA. 7.3 resumo Durante este capítulo foram expostas duas implementações necessárias para acomodar o universo RADA na plataforma. Numa primeira fase, foram descritas as alterações necessárias à ontologia especificando as entidades, object e data properties usadas para representar o RADA. De seguida, foram mostradas as alterações à API expondo as novas rotas criadas sendo elas de criação, listagem e consulta de um RADA. 8 C O N S U LTA D O R A D A Após o RADA ser aprovado no workflow de pedidos e inserido na ontologia, está-se agora em condições de implementar outro requisito imposto pela DGLAB. A plataforma terá que se capaz de listar e permitir a consulta de um RADA inserido na plataforma usando as rotas API de consulta construídas e detalhadas no capítulo anterior. Para cumprir esse requisito, numa primeira fase foi implementada uma interface capaz de listar os RADA presentes na plataforma. Figura 75: Interface de listagem dos RADAs para consulta. Como se pode visualizar através da imagem acima, o utilizador poderá efetuar duas acções, consultar o RADA na interface de consulta ou pedir a exportação do RADA como PDF . De seguida, será exposta a implementação de cada tipo de consulta detalhadamente. 8.1 consulta Quando o utilizador entra na interface para consulta de um RADA surge a seguinte visualização. Figura 76: Interface de consulta de um RADA. 73 8.2. Exportação em PDF 74 Figura 77: Interface de consulta do relatório expositivo de um RADA. Figura 78: Interface de consulta da tabela de seleção de um RADA. Todas as outras interfaces necessárias para a consulta do RADA são esteticamente e funcionalmente iguais às interfaces usadas para consulta do pedido de um RADA, como mostrado num capítulo anterior. Contudo nesta interface estão presentes hyperlinks para as entidades, tipologias e legislações relacionadas com o respetivo RADA. 8.2 exportação em pdf Outro requisito imposto pela DGLAB era a possibilidade de exportar o RADA em PDF . Para tal, foi implementado um mecanismo no frontend capaz de transformar a informação que chega da API relativa ao RADA, em PDF usando a biblioteca para Javacript , pdfMake . Este trabalho foi suportado pela Universidade do Minho (UM), projecto CLAV: Classificação e Avaliação da Documentação na Administração Pública Portuguesa (UMINHO BIC/12/2019 e UMINHO BIM/2020/16), financiado pela Direção-Geral do Livro, dos Arquivos e das Bibliotecas (DGLAB).