====== DET - Documento de Especificação Técnica ====== ===== 1. Informações Gerais sobre o Levantamento ===== ==== RESPONSÁVEL PELA ELABORAÇÃO ==== |**Unidade**| |Cast - Brasília| ==== NOME DO CLIENTE ==== |**Unidade**|**Nome**|**Fone**|**e-mail**| ||||| ==== INFORMAÇÕES DA SOLICITAÇÃO ==== |**Tipo de Solicitação**|**DET de Origem**| |Novo Desenvolvimento|XXX| ==== INFORMAÇÕES DE AMBIENTE ==== |Sistema operacional das estações dos clientes |Android| |Sistema operacional das estações dos clientes |IOS| |Versão dos Aplicativos|1.0.1| ===== 2. Objetivo ===== 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. ===== 3. Contexto Normativo ===== 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. ===== 4. Finalidade ===== 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. ===== 5. Escopo ===== 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. ===== 6. Definições, Acrônimos e Abreviações ===== **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. ===== 7. Referências ===== **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 ===== 8. Proposta de Solução | Arquitetura ===== **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.** ==== 8.1. Arquitetura ==== 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. ==== 8.2. METAS E RESTRIÇÕES DE ARQUITETURA ==== * 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. ==== 8.3. Visão de Implementaçã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. === 8.3.1. Android === 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. === 8.3.2. iOS === 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. === 8.3.3. Processo Software === 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 === 8.3.5. Implantação === 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. === 8.3.6. Dependências === São as principais decisões tomadas em termos de ferramental a ser empregado no desenvolvimento. == 8.3.6.1 Android == * 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 == 8.3.6.2. iOS == * 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. === 8.3.7. Qualidade === 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.