O Documento de Arquitetura de Software

Documento de Arquitetura de Software

TechSystem

Histórico de Versões

Data	Versão	Descrição	Autor	Revisor	Aprovado por
10/06/2021	1.0		Eduardo	Welleton	Clodoaldo

---

Índice

Histórico de Versões        1

Índice        2

Documento de Arquitetura de Software        3

1.Objetivo do Documento        3

2.Objetivos e Restrições da Arquitetura        3

3.Elementos Arquiteturalmente Significativos        5

4.Descrição da Arquitetura        5

4.1.Camadas e Subsistemas        5

4.2.Padrões e Mecanismos Arquiteturais        9

4.3.Topologia        13

4.4.<Visão de Implementação>        15

4.5.Outras Visões        17

5.Decisões e Justificativas        17

Documento de Arquitetura de Software

 

1. Objetivo do Documento

Através “Documento de Arquitetura de Software - DAS” a TechSystem tem a finalidade  definir um modelo arquitetural para ser aplicado ao desenvolvimento do AGV Clean Mobile , com foco na  compreensão de como um sistema deve ser organizado e  estruturado, assim como analisar   componentes tecnológicos que  poderão ser usado para integrar uma solução arquitetural, oferecendo uma visão macro dos requisitos arquiteturais  e não funcionais  afim otimiza o trabalho dos designers e desenvolvedores, auxiliando nas tomadas de decisões e permitindo assim uma aplicação respeitando  padrões básicos necessários para funcionar de forma assertiva no desenvolvimento do software.

Objetivos e Restrições da Arquitetura

<Descreve os objetivos e as restrições para a definição da arquitetura, apresentando os principais aspectos da aplicação. Deve indicar também os Requisitos Significativos através de diagramas ou listagem textual. Estes requisitos desempenham um papel importante na elaboração do sistema e normalmente apresentam restrições e/ou necessidades arquiteturais.>

A arquitetura de software  tem como objetivo ser formada considerando fatores para  servir como base  de estimação de custos e gerencia do projeto, promovendo o suporte para reuso de componentes que podem ser reaproveitados em novas aplicações , assim como uma base de análise de verificação se a arquitetura de software adota suporta os atributos de qualidade além de  atuar como estrutura para atender as demandas definindo os requisitos funcionais e não funcionais seguindo critérios   com a visão logica ,visão de desenvolvimento, visão de processos, visão física e a visão de casos de uso. Existem alguns requisitos chave e restrições do sistema que têm um relacionamento significativo com a arquitetura. São eles:

• Monitoramento de falhas
• Capacidade em horas de trabalho da bateria;
• Tempo faltante para finalizar a carga da bateria;
• Diagnósticos de funcionamento do AGV (Status atual e falhas);
• Histórico de falhas;
• Seleção de trabalhos;
• Interface para controle manual (Movimentação, Habilitar-Desabilitar Luz UV);
• Notificações de paradas;
• Interface amigável e direta ao ponto;
• IHM
• Renderização de imagem da área mapeada e rota configurada em acordo com as informações recebidas do ROS.
• Integração de comunicação entre aplicação mobile e extensão Node Red;
• Acessibilidade multiplataformas;
• Desempenho com processamento otimizado para hardwares considerados intermediários à premium;

Interface para níveis de acesso (Operador – Manutenção – Acompanhamento e Demonstração);

Existem algumas restrições de requisito e de sistema que têm uma relação significativa com a arquitetura impactando no desenvolvimento do projeto , sendo elas:

• Utilização do paradigma de   Programação Orientada ao Objeto para o desenvolvimento;
• Utilização do Node-Red para  conectar o AGV Clean ao AGV Clean mobile
• AGV CLean Mobile estruturando/configurando o acesso à base de dados através de um Localhost
• Por padrão utilização  da  linguagem de programação C++;
• O sistema em questão deverá ser multiplataforma e ser capaz de funcionar em  IOS versão 11.xx e Android versão 9.xx;(verificar a forma correta de impor restrições de versões )
• O Aplicativo será funcional em dispositivos celulares ou tablets Android  e Apple  sem necessidade  ao acesso a internet.
• . AGV CLeam Mobile será implementado como um sistema cliente/servidor. A parte cliente reside em Mobile  e a parte servidor deve operar no Servidor (qual tipo servidor )

• Utilização da estrutura padrão  Layers (camadas)

• Utilização do Modelo de visão  4+1(Kruchten,1995) ;
• O AGV Clean Software tem uma versão desktop que fornece responsável pela configuração padrão . Uma interface mobile para esse sistema deve ser capaz de replicar as principais funções básicas desse software dentro das limitações de hardware.
• O AGV Clean Software tem uma versão desktop que é responsável pela configuração padrão . Uma interface mobile para esse sistema deve ser capaz de replicar as principais funções básicas desse software dentro das limitações de hardware.
• O AGV Clean Mobile  devera conter restrições de acesso a nas áreas de configuração do software sendo apenas acessado por usuários com níveis de administrador.
• O software devera estar dentro dos padrões de qualidade ISO/IEC 9126 
• Todos os requisitos e descrição de caso de uso conforme estipulados em seus respectivos documentos  , devem ser considerados durante o desenvolvimento da  arquitetura.

Documentação:[pic 1]<Insira aqui as documentações e as imagens dos diagramas de caso de uso contidos na pasta Elementos do Modelo Arquiteturalmente Significativos, dentro do Modelo de Requisitos, que se encontra dentro de Use Case View >