DET - Documento de Especificação Técnica
RESPONSÁVEL PELA ELABORAÇÃO
NOME DO CLIENTE
| Tipo de Solicitação | DET de Origem |
| Novo Desenvolvimento | XXX |
| 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
APLICATIVO iOS
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.
-
-
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:
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
8.3.6.2. iOS
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.