DET - Documento de Especificação Técnica

Trata o presente documento, de análise de sistema elaborada pela Cast-Brasília, tendo por escopo a o desenvolvimento dos aplicativos para apoio ao processo de registro de manifestações e solicitações de informação.

O aplicativo deve integrar com os módulos já criados do Solicitação de Informação ao Cidadão(e-SCI) e Portal da Ouvidoria, portanto seguirá as normas dos mesmos.

Este documento apresenta uma visão geral abrangente da arquitetura do sistema e utiliza uma série de visões arquiteturais diferentes para ilustrar os diversos aspectos do sistema. Sua intenção é capturar e transmitir as decisões significativas do ponto de vista da arquitetura que foram tomadas em relação ao sistema.

Este documento de arquitetura afeta os produtos Aplicativo Android, Aplicativo iOS e a especificação da camada de Serviço Restfull influênciado assim a implementação da mesma: implementação essa que porém não é escopo deste documento.

Aplicativo Móvel → Software projetado e desenvolvido para ser executado em um sistema operacional móvel.

Android → Sistema Operacional Móvel. iOS → Sistema Operacional Móvel.

Serviço → Uma função que poder ser acessada por outros softwares através de rede (Internet) para a execução de uma funcionalidade específica.

API Rest → Representational State Transfer (REST) é um estilo arquitetural e o modelo de comunicação utilizado para desenvolvimento de serviços tendo como principais características o baixo consumo de rede de dados e o desecomplamento dos protocolos de comunicação.

OpenAPI Specification → Ferramental teórico para modelagem de APIs REST.

Swagger → Ferramental que implementa as definições da OpenAPI Specification.

End Point → O endereço URL através do qual o serviço pode ser acesso pelo aplicativo cliente.

Ontologia → Um conjunto de conceitos (funcionalidades), nomenclaturas, definições de tipos, propriedades e inter-relacionamentos.

Domínio → Uma esfera de conhecimento (ontologia), influência ou atividade. A área que o programa deve atender é o domínio do software.

Subdomínio → Um domínio é composto de multíplos subdomínios. Cada subdomínio corresponde a uma parte diferente do negócio.

HTTP Session → Modelo que estabelece um mecanismo através do qual os multiplas chamadas HTTP podem ser vinculadas estabelcendo, por exemplo, condições de controle de segurança ao garantir que a sessão existente é a mesma sessão criada no momento da autenticação de um usuário.

Autenticação → é o processo que garante que alguém realmente é quem diz ser.

Autorização → é o processo referente às regras que permitem a um usuário executar ou não uma funcionalidade.

Problem Details for HTTP APIs → Especificação que estabelece um modelo unificado e normatizado (RFC 7807) de comunicar aos Aplicativos todos os erros ocorridos no serviço.

Kotlin → Liguangem de programação funcional para desenvolvimento Android.

Swift → Linguagem de programação funcional para desenvolvimento iOS.

API Rest TCE → Modelo em formato Swagger da API Rest.

Protótipos → Protótipos visuais com as definições de UX e de design dos aplicativos

A arquitetura da aplicação está representada nos diagrama abaixo. Sendo subdividida em subsistemas para que a aplicação tenha um baixo acoplamento e seu desenvolvimento em paralelo.

Os serviços que atendem os aplicativos Android e iOS estão organizados na forma de uma API REST cuja modelagem baseia-se nos padrões estabelecidos pela OpenAPI Especification na versão do Swagger com a organização inicial de Domínio e Subdomínios sendo guiadas pelas definições da área de negócio da Ouvidoria e pelas definições de segurança construída no modelo clássido HTTP Session.

APLICATIVO ANDROID

• Software implementado em plata forma Nativa para o sistema operacional Android para Smartphones.

APLICATIVO iOS

• Software implementado em plataforma Nativa para o sistema operacional iOS para Smartphones.

As configurações de De X Para poderão ser consultadas a partir da descrição, da Origem de Dados (aplicação, categoria/dimensão da informação, tipo de formulário e versão de formulário), do Destino dos Dados, pela situação da configuração de De X Para (Em Elaboração, Publicado, Cancelado), e pelo período quem a configuração foi criada.

A situação da configuração de De X Para quando estiver Em Elaboração significa que a configuração ainda está sendo criada, dessa forma ela ainda poderá ser excluída (botão “X” da grid), editada (botão “E” da grid) e publicada (botão “P” da grid). Quando o usuário solicitar a exclusão da configuração de De X Para, todas as configurações filhas serão também excluídas, e ao final do processo o sistema irá informar ao usuário que a configuração de De X Para foi excluída com sucesso. Caso o usuário solicite a edição da configuração de De X Para, será apresentado para ele as informações da configuração até o momento salvas, através da rotina de manutenção de configuração de De X Para. Já quando o usuário solicitar a operação de publicação da configuração de De X Para não poderá mais editar a configuração, e esta estará elegível para ser executada pelo processo de sincronização, seção 8.5 deste documento.

Quando a configuração de De X Para estiver em situação Publicado, o usuário apenas poderá visualizar a configuração ou cancelar, botão “V” e botão “C”, respectivamente. O cancelamento/inativação da configuração de De X Para será uma exclusão lógica, que irá impossibilitar o uso dessa configuração de modo não ser possível sincronizar as informações a partir dessa configuração de De X Para.

Na manutenção da configuração de De X Para o usuário deverá informar uma breve descrição que identifique o De X Para, selecionar a Origem de Dado (aplicação, categoria/dimensão da informação, tipo de formulário e versão de formulário), selecionar ou adicionar uma nova configuração de Destino. No momento da configuração de De X Para a inclusão de uma nova configuração de Destino será somente para o tipo Banco de Dados.

Em seguida, ainda na configuração de De X Para, o usuário deverá informar a configuração de Item de De X Para, informando para cada item qual a propriedade de Origem para qual propriedade de Destino será sincronizado. Quando a configuração de Destino for adicionada no momento da configuração de De X Para, será apresentada a opção de adicionar um destino, que apresentará a mesma rotina de Manutenção de Coluna Tabela da seção 8.1.1. Na rotina de Manutenção de Item De X Para, será apresentado o campo de seleção da propriedade de Origem, um capo que será usado para apelidar a propriedade de Origem para melhor identificar o seu conteúdo, há campo de seleção/inclusão do Item de Destino, um campo para apelidar a propriedade de Destino para melhor identificar a propriedade, será apresentado campo que identifica se a propriedade é uma Opção - quando marcado será apresentada a opção de configuração dos itens da opção, da Origem para o Destino.

Na manutenção de Opção de Item De X Para, será apresentado ao usuário os campos de Descrição de Origem (breve descrição do valor da origem), o campo Valor de Origem, o campo Descrição do Destino (breve descrição do valor de Destino), e o valor de destino. Desses campos apenas os campos Valor Origem e Valor Destino são obrigatórios.

Na manutenção de De X Para o usuário poderá determinar a condição de exclusão da informação sincronizada no destino, utilizando a configuração Condição de Exclusão e/ou a opção para marcar se quando a origem deixar de existir deverá apagar no destino.

Na manutenção de condição para exclusão o usuário deverá selecionar a propriedade de Origem que determinará a condição de exclusão. O usuário poderá dar um apelido para a propriedade para melhor identificar a condição. E por fim, deverá informar o valor que a propriedade terá quando o registro de destino deverá ser excluído.

Para a sincronização das informações da origem para o destino serão controladas tupla a tupla, sendo cada tupla correspondente a um conjunto de itens de De X Para que representa uma informação da Origem de Dados para um Destino. Para cada tupla será mantido um item do controle de sincronização que irá identificar o conteúdo da ultima sincronização, para que quando for executado o sincronismo agendado ou manual, seja possível comparar com o conteúdo atual da origem, em que caso esteja diferente será sincronizado para o destino a atualização da informação conforme a informação origem.

No controle de sincronização será identificado o tipo de sincronização, se manual ou agendada e quem executou a sincronização, bem como a data e hora de início e data e hora de término, e qual máquina executou o sincronismo e qual a configuração de De X Para foi sincronizada.

No item do sincronismo terá o identificador da origem (chave da origem de identificação), o identificador do destino (chave da origem de identificação), o tipo da operação de sincronização (Inclusão, Atualização ou Exclusão), hash do conteúdo da origem, hash do conteúdo de destino e a situação da sincronização (Iniciado, Concluído, Erro de Sincronização ou Erro de Validação).

Para cada item do controle de sincronização será registrado log de sincronismo, contendo a situação da sincronização, e a descrição do passo a passo do que foi sincronizado, incluindo mensagem de erro quando tiver.

Será possível consultar as sincronizações realizadas para conferir o que foi sincronizado e qual a situação da sincronização, para caso tenha alguma anomalia possa ser identificada no log do sincronismo.

O agendamento da sincronização poderá ser feito para ser executado de forma Anual, Mensal, Semanal e Diário, que será identificado como tipo de execução. No agendamento Semanal deverá ser selecionado quais dias da semana deseja agendar a execução. Em todos os tipos de execução o usuário deverá informar a data de início do agendamento e caso queira determinar a uma data final, poderá informar a data e horário de quando será executada a última sincronização. Na última sincronização o sistema irá marcar o agendamento como inativo.

Na configuração de agendamento de sincronização o sistema irá validar apenas se existe configuração de agendamento iguais ativos para a mesma configuração de De X Para, não validando dessa forma se terá concorrência de sincronismo agendado com base na configuração. Assim, na execução da sincronização o sistema irá marcar o controle de sincronização quando em execução, de modo que outro agendamento possa identificar e reagendar a execução para adiar em 10 minutos. Nesse sentido, a responsabilidade do controle de sincronizações agendadas será do usuário que configurou, o qual deverá analisar a melhor configuração de agendamento para o que necessita.

Através da consulta dos agendamentos de sincronização por De X Para, o usuário poderá excluir uma sincronização através do botão “X”, editar uma configuração de agendamento de sincronização através do botão “E”, inativar uma configuração a partir do botão “I” ou ativar uma configuração que esteja inativa a través do botão “A”.

O usuário a qualquer momento poderá inicializar um sincronismo de forma manual, sendo que esse sincronismo irá verificar da mesma forma que no sincronismo agendado, se já tem uma sincronização agendada, caso positivo será reagendado a cada 10 minutos. Na funcionalidade de Sincronização de De X Para, o usuário poderá inicializar uma sincronização manual, e visualizar as sincronizações em ordem decrescente de sincronização. Como o controle de sincronização será único por De X Para, nessa visualização terá apenas a última sincronização do De X Para. A partir dessa visualização o usuário poderá visualizar o resultado da sincronização a partir do botão “V” que irá carregar a funcionalidade de consulta do Controle de Sincronização, carregando as informações de sincronização da configuração de De X Para selecionada.