Home | Cronograma | Sprints | Requisitos | Gerência de Projeto | Horários Disponiveis |
---|---|---|---|---|---|
Mockups | Banco de Dados | Material de estudo | Arquitetura | Git Workflow | Configuração |
Padronização do Código | Testes |
Página da Arquitetura do Sistema
CAMADAS DO SISTEMA:
• Components: Onde estão os componentes visuais que podem ser utilizados em toda a aplicação. Não devem possuir lógica e nem depender de outros serviços, tornando-o assim, genérico a partir de alguma característica determinada.
Ex: CardEmojiComponent, ItemListComponent
• Containers: Os containers ficam responsáveis de unificar os componentes que serão utilizados em uma tela, atribuindo a eles a camada de lógica de acordo com a funcionalidade que o mesmo deve implementar, como por exemplo o que o botão deverá realizar quando pressionado.
Ex: CardEmojiContainer, ListContainer
• Screens: Possui como responsabilidade montar o Container para a apresentação. Não deve possuir lógica, pois seu container ja deve possuir implementada.
Ex: EmojiScreen, ListScreen
• Routes: A camada de Routes, utilizando o padrão de arquitetura Coordinator, irá realizar a navegação entre as telas da aplicação, tendo conhecimento do fluxo e como devem se comportar. Possui a StackNavigator(navegação em telas empilhadas que seguem um determinado fluxo) e a TabBarNavigator (navegação por blocos com funcionalidades que diferem umas das outras, possui uma barra com suas opções na parte inferior da aplicação)
• Database: Classe de acesso ao serviço utilizado, com as configurações necessárias e os métodos que irão facilitar a manipulação do mesmo.
• Utils: Classes que podem ser reaproveitadas na aplicação, com funcionalidades de formatação de texto, modelos de entrada, acesso a constantes, etc..
• Resources: Pasta com as imagens que são utilizadas na aplicação uma ou mais vezes.
DIAGRAMA DO SISTEMA:
O diagrama do sistema de como as camadas se comunicam. Cada container irá dispor vários componentes (genericamente implementados). A Screen irá montar os containers, onde estas serão navegadas pelas Routes.
Clique aqui para visualizar em PDF.
ARQUITETURA DO FIREBASE:
O Google Firebase é conhecido como um Backend as a Service, que já fornece um serviço que garante que a estrutura necessária do Backend já esteja pronta para ser usada por desenvolvedores. O projeto HiperBem faz uso desta ferramenta para integração e fluxo de dados.
DIAGRAMA DE DEPLOYMENT:
O diagrama a seguir representa a versão final do produto que será implantada.
OBS: Esta versão atual é parcial e será atualizada assim que as tecnologias forem completamente definidas (executáveis, etc...)
Clique aqui para visualizar em PDF.