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.

A visão de organização do layout de telas:

• ConstraintLayout → calcula dinamicamente a partir de limitadores horizontais e verticais o tamanho e posição de todas a views da hierarquia de uma tela.

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

• Controller: 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.
• Model: 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).
• Service: 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 iOS é baseada nas seguintes classes:

• AppDelegate → 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 e de inicialização do fluxo de interfaces responsável por encapsular as decisões de qual interface exibir durante o inicialização do aplicativo.
• MainController → classe responsável por ser a tela principal da aplicação e controlar a exibição do menu lateral.
• TCEAPI → classe responsável por encapsular os aspectos de uma chamada HTTP.
• Controllers(Model) → responsáveis pelas ViewControllers de todas as telas do aplicativo.
• Localizable(strings) → respsonsável pela tradução para outros idiomas.
• InfoPlist(strings) → responsável pela tradução do arquivo de configurações do aplicativo.
• Storyboards(strings) → responsável pela tradução dos textos dos componentes da UI.

A visão de organização do layout de telas:

• Auto Layout → calcula dinamicamente o tamanho e posição de todas a views da hierarquia de uma tela.

O sistema é gerenciado por meio de processos (threads), esses processos (threads) podem ser divididos com base na sua capacidade de influência para o sistema como um todo, podendo ser classificados em dois tipos :

• Processos leves: São processos de baixa importância dentro do sistema, tais como threads de baixa prioridade criadas para processamento paralelo.
• Processos pesados: São processos de alto impacto dentro do sistema como um todo tais como threads para chamadas HTTP

Os aplicativos são construídos em plataformas nativas com liguagem Kotlin para o Android e Swift para o iOS.

• A linguagem Kotlin utiliza de máquinas virtuais JVM para executar o aplicativo nas mais diversas plataformas (smartphones, tablets, entre outros). As máquinas virtuais interpretam o código e executam as instruções nele contidas diretamente nos sistemas.
• A linguagem Swift é executada o aplicativo de forma nativa (sem máquina virtual) nas mais diversas plataformas (smartphones, tablets, entre outros).
• Ambas linguagens são licenciadas através de Apache 2.

Os aplicativos devem ser implantados para distribuição para os usuários nas respectivas lojas de cada plataforma (Google Play e AppStore) sendo necessária a existencia de uma conta específica para cada loja em nome do TCE-GO.

São as principais decisões tomadas em termos de ferramental a ser empregado no desenvolvimento.

• Android Studio 2.3.3 ou Superior
• Android 8 (Compilação com SDK 26) (Mínima 4.4) - 91% do Mercado
• Kotlin 1.1.50
• Material Design
• Retrofit 2.3.0
• GSON 2.3.0
• Android PDFViewer 2.7.0

• XCode 9.0
• iOS - Compilação 10.13 (Miníma 10.3)
• Swift 4/Objetive C
• Alamo Fire 4
• Item de lista não ordenadaQuikLook

Observação: Todas dependência são licenciadas através de Apache 2.

Sabendo que qualidade e seus atributos são a base para as estratégias e decisões de design da arquitetura. Os padrões adotados oferecem uma solução mais satisfatória para atender a qualidade esperada do sistema.

• Kotlin como linguagem de programação para Android ao invés de Java elimina diversos erros comuns como NullPointerException ocorridos quando o desenvolvimento Android é feito com Java. Elimina também a necessidade de agregar frameworks diversos como os de injeção de dependência visto que o compilador Kotlin resolve também esse tipo de problema de forma nativa. Além disso torna o código produzido mais enxuto por ser uma linguagem menos verborrágica que a linaguagem Java.
• Swift como linguagem agrega conceitos que as linguagens de programação modernas podem oferecer: é type safe, usa o conceito de Optionals para tratar valores nulos, não exige ponto-e-vírgula ao final de cada linha, possui um melhor gerenciamento de memória, trabalha com closures, generics, tuplas, subscripts.
• Ambas são linguagens funcionais que é um paradigma de programação que trata a computação como um conjunto de funções matemáticas evitando estados e dados mutáveis, combinando flexibilidade, poder e a clareza da abstração construído na elaboração de um código de mais manutenível e evolutivo.