Mudanças entre as edições de "Arquitetura Classpad"

De MSTECH wiki
Ir para: navegação, pesquisa
(Decisões de Arquitetura)
(Aplicativo)
 
(13 revisões intermediárias por 2 usuários não estão sendo mostradas)
Linha 32: Linha 32:
 
'''Ambiente:''' GITLab - Git
 
'''Ambiente:''' GITLab - Git
  
'''Nome:''' MSCRO
+
'''Nome:''' Classpad
  
'''Caminho:''' https://gitlab.mstech.com.br/mscro/app-mscro.git
+
'''Caminho:''' https://gitlab.mstech.com.br/groups/classpad
  
'''Estrutura dos branches:''' Código mantido no tronco, porém mantemos 2 branches para os clientes SP e RJ.
+
'''Estrutura dos branches:''' dev, release e master
  
 
=Visão de Componentes=
 
=Visão de Componentes=
  
Apresente um diagrama básico dos módulos do sistema, bem como suas fronteiras. Descreva sucintamente cada módulo que compõe o produto, seu objetivo e como foi construído (linguagens usadas, bancos de dados, etc.).
+
 
 +
 
 +
==== Servidor Datacenter ====
 +
Servidor localizado no Datacenter e que interage com todos os servidores das escolas a ele ligados e diretamente com os aplicativos nos dispositivos android.
 +
==== Servidor Escola====
 +
Servidor localizado em cada escola e que interage diretamente com os aplicativos nos dispositivos android.
 +
==== Aplicativo====
 +
Existe em duas variantes: Professor e aluno, apresentando fundamentalmente diferenças no interface com o usuário.
 +
Sendo que o professor poderá criar sessões de aprendizagem e atividades nessa mesmas sessões, o aluno poderá apenas ingressar numa sessão e interagir com as atividades nela criada por um professor.
 +
 
 +
[[Arquivo:Classpad-servidor.png]]
 +
[[Arquivo:Classpad-escola.png]]
 +
[[Arquivo:Classpad-Datacenter.png]]
  
 
=Decisões de Arquitetura=
 
=Decisões de Arquitetura=
Linha 52: Linha 64:
 
Tráfego via WSS entre servidores e dispositivos
 
Tráfego via WSS entre servidores e dispositivos
 
Tráfego via HTTPS entre servidores e entre servidores e dispositivos
 
Tráfego via HTTPS entre servidores e entre servidores e dispositivos
 
  
 
==== Log ====
 
==== Log ====
Linha 58: Linha 69:
 
Para os logs utilizamos arquivos de texto gerenciado pelo LOG4J2
 
Para os logs utilizamos arquivos de texto gerenciado pelo LOG4J2
 
Para crash report usaremos Crashlytics (Fabric.io)  
 
Para crash report usaremos Crashlytics (Fabric.io)  
 
  
 
==== Padrão de arquitetura utilizado ====
 
==== Padrão de arquitetura utilizado ====
Linha 69: Linha 79:
 
Utilização de Hibernate 4 para comunicação com banco de dados PostgreSQL e SQLite.
 
Utilização de Hibernate 4 para comunicação com banco de dados PostgreSQL e SQLite.
 
Utilização de JMDNS para Discovery na rede.
 
Utilização de JMDNS para Discovery na rede.
 
  
 
==== Tecnologia de Front-end ====
 
==== Tecnologia de Front-end ====
Linha 75: Linha 84:
 
Utilização de front end simplificado nos ambientes de Administração
 
Utilização de front end simplificado nos ambientes de Administração
 
Aplicação de Material Design no Android e Angular-JS na Web
 
Aplicação de Material Design no Android e Angular-JS na Web
 
  
 
==== Tecnologia de Back-end ====
 
==== Tecnologia de Back-end ====
 
Arquitetura padrão para servidores Java e clientes Android
 
Arquitetura padrão para servidores Java e clientes Android
 
Utilização de Java 7 e Android 4.4 ou superior
 
Utilização de Java 7 e Android 4.4 ou superior
 
  
 
==== Deploy ====
 
==== Deploy ====
Linha 88: Linha 95:
  
 
=Fundamentações das decisões tomadas=
 
=Fundamentações das decisões tomadas=
Nesta seção, coloque todas as considerações das tomadas de decisão realizadas para o produto. Porque foi usada tal arquitetura? Porque essa separação de componentes? Porque houve refatoração? Descreva o máximo possível nesta seção para que o histórico das decisões seja armazenado para consultas futuras.
+
A utilização de servidores em escola é uma necessidade dada a natureza das infra estruturas de rede existentes nas escolas.
 +
 
 +
 
 +
Utilizar a rede escolar para uma utilização da rede apoiada inteiramente em tecnologia peer to peer, é algo que obriga a estudo caso a caso, e inviabiliza um aplicativo que se pretende ser instalável em diversos cenários e localizações.
 +
 
 +
 
 +
Com a crescente demanda por aplicativos apoiados numa premissa BYOD (Bring your own device), surge também a necessidade de ter uma distribuição feita na loja do Google Play, e um modo de ativação e configuração simples do aplicativo.
 +
 
 +
 
 +
A necessidade de flexibilizar o aplicativo para utilizações fora das redes escolares, fez necessário a existência dos servidores em datacenter, para que permitam a que os usuários usufruam do aplicativo, mesmo estando fora da escola, ou caso a rede escolar esteja com algum problema.

Edição atual tal como às 17h29min de 27 de maio de 2016

Informações Gerais

Ambientes utilizados

Ambiente URL de Acesso Credenciais Admin
Desenvolvimento http://dev-mscro.mstech.com.br admin / 123456
Testes http://tst-mscro.mstech.com.br admin / ms@cro
Testes http://tst-mscro.mstech.com.br admin / ms@cro
Homologação Externa http://hom-mscro.mstech.com.br Informação exclusiva do Devops/GTI
Produção http://mscro.mstech.com.br Informação exclusiva do Devops/GTI

Repositório de Versionamento

Ambiente: GITLab - Git

Nome: Classpad

Caminho: https://gitlab.mstech.com.br/groups/classpad

Estrutura dos branches: dev, release e master

Visão de Componentes

Servidor Datacenter

Servidor localizado no Datacenter e que interage com todos os servidores das escolas a ele ligados e diretamente com os aplicativos nos dispositivos android.

Servidor Escola

Servidor localizado em cada escola e que interage diretamente com os aplicativos nos dispositivos android.

Aplicativo

Existe em duas variantes: Professor e aluno, apresentando fundamentalmente diferenças no interface com o usuário. Sendo que o professor poderá criar sessões de aprendizagem e atividades nessa mesmas sessões, o aluno poderá apenas ingressar numa sessão e interagir com as atividades nela criada por um professor.

Classpad-servidor.png Classpad-escola.png Classpad-Datacenter.png

Decisões de Arquitetura

Persistência

Através de banco de dados relacional Criação do banco de dados PostgreSQL nos servidores e em Realm nos dispositivos

Tecnologia de integração

Será realizada por meio de troca de mensagens entre os dispositivos e o servidor Datacenter e/ou servidor na escola Tráfego via WSS entre servidores e dispositivos Tráfego via HTTPS entre servidores e entre servidores e dispositivos

Log

Implementado log de negócio (para rastreabilidade das ações do usuário) e de log técnico para análise de funcionamento e falhas Para os logs utilizamos arquivos de texto gerenciado pelo LOG4J2 Para crash report usaremos Crashlytics (Fabric.io)

Padrão de arquitetura utilizado

Utilizamos Servidores HTTPS RESTful na arquitetura JAX-RS para gerenciamento de APIs. Utilizamos o padrão de arquitetura DDD (Domain Driven Design) na aplicação web para ambiente de administração do servidor. Utilizamos o padrão “thin client” para os dispositivos. Utilizamos o padrão PubSub na comunicação durante uma sessão de aprendizagem Utilizamos o protocolo MDNS (Bonjour) para descoberta do servidor da escola Utilização de Jetty 9 para servidor HTTPS e WSS. Utilização de Hibernate 4 para comunicação com banco de dados PostgreSQL e SQLite. Utilização de JMDNS para Discovery na rede.

Tecnologia de Front-end

Utilização do design nativo Android Utilização de front end simplificado nos ambientes de Administração Aplicação de Material Design no Android e Angular-JS na Web

Tecnologia de Back-end

Arquitetura padrão para servidores Java e clientes Android Utilização de Java 7 e Android 4.4 ou superior

Deploy

Distribuição dos clientes android via Google Play Instalação dos servidores via instalador Pacotes de instalação APK versionados e assinados conforme padronização

Fundamentações das decisões tomadas

A utilização de servidores em escola é uma necessidade dada a natureza das infra estruturas de rede existentes nas escolas.


Utilizar a rede escolar para uma utilização da rede apoiada inteiramente em tecnologia peer to peer, é algo que obriga a estudo caso a caso, e inviabiliza um aplicativo que se pretende ser instalável em diversos cenários e localizações.


Com a crescente demanda por aplicativos apoiados numa premissa BYOD (Bring your own device), surge também a necessidade de ter uma distribuição feita na loja do Google Play, e um modo de ativação e configuração simples do aplicativo.


A necessidade de flexibilizar o aplicativo para utilizações fora das redes escolares, fez necessário a existência dos servidores em datacenter, para que permitam a que os usuários usufruam do aplicativo, mesmo estando fora da escola, ou caso a rede escolar esteja com algum problema.