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.

• Dado que na Primeira Onda os processos de Autenticação e Autorização estão baseados no modelo HTTP Session, os aplicativos Android e iOS devem manter a sessão de forma a permitir que os End Points de negócio possam ser chamados de forma segura.
• Todos os erros retornados como resultado de uma chama a um End Point devem estar no famato da entidade “ProblemApiResponse” conforme a modelagem da API Rest do TCE (vide item 1.4 deste documento) e cuja definição está em conformidade com a RFC 7807 - Problem Details for HTTP APIs.
• As definições e espcificações deste documento são aplicáveis apenas a Smartphones.
• Os aspectos concretos de implementação da API REST não são contemplados neste documento.
• Os aplicativos Android e iOS estão preparados para a internacionalização.

Descreve as classes mais importantes, sua organização em pacotes e subsistemas de serviço, e a organização desses subsistemas em camadas detalhados de acordo com cada plataforma.

A visão geral do aplicaitvo Android é composta por 4 pacotes principais abaixo descritos:

• activity: não está preocupado em como a informação foi obtida ou onde ela foi obtida, apenas exibe ao usuário; captura as informações providas pelo usuário sem também se interessar com o destino delas.
• business: abriga todas as regras e pontos de acesso a outros componentes dos quais as regras dependam.
• models: abriga todas as entidades de que o projeto depende em conformidade com a modelagem da API Rest do TCE (vide item 1.4 deste documento).
• rest: seu papel é o de estabelecer todas a implementações que de fato fazem a comunicação com os serviços dos quais o aplicativo depende.

A visão estrutural central do aplicaitvo Android é baseada nas seguintes classes:

• TceGoApplication: classe de aplicação responsável por encapsular para o aplicativo os comportamentos necessários e esperados durante a inicialização de uma aplicação.
• InitActivity: classe de inicialização do fluxo de interfaces responsável por encapsular as decisões de qual interface exibir durante o inicialização do aplicativo.
• BaseActivity: classe abstrata que serve de base às demais activities do projeto na qual são encapsulados comportamentos comuns a todas as activities.
• SimpleActivity: classe abstrata da hierarquia da classe BaseActivity responsável por especializar tratamento de mensagens de chamadas assíncronas entre componentes do projeto e cujo resultado deverá ser a exibição de alguma mensagem para o usuário.
• MainActivity: classe principal de interface responsável pela principal do aplicativo.
• TceRestService: classe abstrata responsável por encapsular os aspectos de uma chamada HTTP.
• Base RestService: classe abstrara da hierarquia da classe TceRestService responsável por encapsular o acesso as configurações de URL base dos serviços que atendem o aplicativo.
• TceRestReponseCallback: interface responsável por fornecer os contratos de callback de erros locais do cliente e erros do servidor.
• TceJsonRestReponseCallback: intertface da hierarquia de TceRestReponseCallback responsável por fornecer o contrato de mensagem de retorno de sucesso no formato em uma entidade parametrizável com Generics.
• TceInputStreamRestReponseCallback: intertface da hierarquia de TceRestReponseCallback responsável por fornecer o contrato de mensagem de retorno de sucesso no formato de uma Stream de dados.
• BaseBusiness: classe concreta responsável por encapsular comportamento negociais e de mensageria entre componentes assíncronos do Android.

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.