Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- pres:gerti:servico_de_desenvolvimento_de_sistemas_de_informacao:projetos:det_aplicativos [11/12/2017 13:38] – [8.3.6.1 Android] famoraes
+++ pres:gerti:servico_de_desenvolvimento_de_sistemas_de_informacao:projetos:det_aplicativos [26/12/2017 18:39] (atual) – removida maugusto
@@ Linha 1: / Linha 1: @@
-====== 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.1.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.1 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.