ESA - Teste 2 PDF

9 – Desenho de Software Analise vs. Desenho Na Análise e Especificação de Requisitos, captura-se e entende-se o que o software deve fazer, identificando os requisitos funcionais e não funcionais. A analise tem o seu foco nos problemas e necessidades do cliente ou utilizador final. Já no Desenho,...

9 – Desenho de Software Analise vs. Desenho Na Análise e Especificação de Requisitos, captura-se e entende-se o que o software deve fazer, identificando os requisitos funcionais e não funcionais. A analise tem o seu foco nos problemas e necessidades do cliente ou utilizador final. Já no Desenho, determina-se como o software irá funcionar, traduzindo os requisitos em uma solução técnica detalhada. O desenho tem o seu foco na arquitetura, nos componentes e na interação entre os módulos. Atividades realizadas (Analise vs. Desenho) Na análise e especificação de requisitos faz-se a eliciação através de reuniões com os stakeholders ou outras ferramentas. Após a eliciação faz-se a modelação de requisitos criando diagramas e documentando os requisitos em linguagem clara e compreensível. A próxima fase é a Validação e Priorização, em que se garante que os requisitos atendem às necessidades do cliente e são viáveis. Por fim, faz-se a gestão de requisitos para rastrear mudanças nos requisitos ao longo do projeto. No desenho, faz-se o Design Arquitetural, definindo a estrutura geral do sistema (em camadas / microserviços…) e escolhem-se padrões arquiteturais, como o MVC ou o REST. Após o design arquitetural faz-se o Design de Componentes que visa detalhar os módulos ou componentes do sistema e as suas responsabilidades. A seguir, faz-se o Design de Dados, onde se modelam as bases de dados e estruturam as classes e atributos (em sistemas orientados a objetos). O Design de Interfaces é a próxima atividade a ser realizada, onde se define interfaces entre módulos e também a interface com o utilizador. Por fim, na Especificação Técnica, criam-se diagramas detalhados (UML) que mostram interações entre os elementos. Entregáveis (Analise de Requisitos vs. Desenho) Na AER os entregáveis são: Documento de Requisitos de Software (Lista detalhada dos requisitos funcionais e não funcionais), Modelos de Requisitos (Diagramas de casos de uso, Diagramas de Contexto, User Stories), Matriz de rastreabilidade (Relaciona requisitos a funcionalidades e módulos). No desenho estes passam a ser Diagramas UML (Diagramas de classes, sequência, componentes e estados), Especificações Técnicas Detalhadas (Arquitetura do sistema e descrição de algoritmos), Protótipos ou mockups (Esboço das interfaces do utilizador - opcional), Modelos de Dados (Diagramas de entidade-relacionamento e especificações do banco de dados) 1 Ferramentas Utilizadas Na AER utilizam-se técnicas como brainstorming, entrevistas e workshops e ferramentas como o JIRA, o Confluence, o Word ou o LucidChart. Quando ao desenho de Software, as técnicas utilizadas são, design centrado no utilizador e desenho baseado em padrões. Já as ferramentas usadas na AER são ferramentas como o Visual Paradigm, o Entreprise Architect, o Draw.io, o Figma ou ferramentas UML. Envolvimento de Stakeholders A AER envolve fortemente stakeholders externos (clientes, utilizadores finais) e analistas de negócios. O foco é traduzir as necessidades em requisitos claros. O Desenho de Software envolve stakeholders internos (arquitetos, desenvolvedores) para definir a implementação técnica. O cliente, normalmente, não está diretamente envolvido. Nível de Abstração Na AER existe uma alta abstração, não havendo preocupação com a implementação técnica, mas sim com as necessidades do negócio e do utilizador. No Desenho de Software a abstração é tem um nível que varia de média a baixa. O foco é criar soluções técnicas detalhadas para implementar os requisitos. Riscos e Problemas Na AER há o risco dos requisitos ficarem incompletos ou mal definidos e o risco de mudanças frequentes nas necessidades do cliente. Os problemas existentes na ERA são a falta de comunicação entre analistas e stakeholders e a ambiguidade na descrição dos requisitos. No Desenho de Software existe o risco do design se tornar excessivamente complexo ou incompatível com os requisitos e o risco das decisões arquiteturais que não escalam ou são difíceis de manter. Os problemas são a falta de alinhamento entre desenvolvedores e arquitetos e a ausência da documentação detalhada. 2 Dependência e Continuidade O desenho só pode começar apos a conclusão de uma análise clara e completa dos requisitos. Os requisitos servem como base para tomar as decisões no desenho de software. Durante o desenho, problemas com os requisitos podem ser descobertos, o que pode levar a ajustes na fase de analise. Introdução ao Design de Software O desenho de software abrange princípios e práticas que resultam em sistemas de alta qualidade, é essencial para traduzir os requisitos em soluções práticas, permite a criação de sistemas escaláveis, flexíveis e robustos e evolui constantemente com novas metodologias, como desenho ágil e modelagem orientada a objetos. O Desenho de Software facilita a comunicação entre analistas, arquitetos e programadores Componentes do Design de Software 1 – Design de Dados/Classes – Define estruturas de dados e classes especificas O desenho de dados/classes é uma etapa essencial que define as estruturas de dados e as classes que serão utilizadas para representar a logica de negócios e o armazenamento no software. Os objetivos desta etapa são: Criar um modelo logico que represente entidades e as suas relações Definir atributos e métodos associados às classes Garantir que a estrutura de dados suporte os requisitos do sistema Estrutura de dados – Inclui tabelas, coleções, ou objetos de dados que armazenarão informações essenciais para o sistema. Classes e objetos – Classes são descritas no desenho orientado a objetos, incluído os seus atributos, métodos e relações. Ferramentas e técnicas – Diagramas UML e Analise de Cardinalidade 3 2 – Design Arquitetural – Estabelece a organização geral do sistema O desenho arquitetural estabelece a estrutura global do sistema, definindo componentes de alto nível e como eles se comunicam. Os objetivos principais desta etapa são: Dividir o sistema em módulos ou camadas para facilitar o desenvolvimento, manutenção e escalabilidade. Escolher o estilo arquitetural apropriado. Componentes principais – Identifica subsistemas ou camadas, como interface do utilizador, logica de negócios e banco de dados. Interconexões – Define como os módulos se comunicam Tecnologias e padrões – Arquitetura RESTful para sistemas distribuídos e padroes como Event- Driven Architecture ou Microservices. O papel do Desenho Arquitetural no processo de desenvolvimento de software é o seguinte: Definir a Estrutura do Sistema o Identifica os principais componentes e como eles interagem o Estabelece a separação de responsabilidades entre os componentes Satisfazer Requisitos Não Funcionais o Atende às necessidades como desempenho, segurança, escalabilidade, disponibilidade e manutenibilidade o Serve para alinhar o sistema às restrições técnicas e organizações Orientar o Desenvolvimento o Fornece diretrizes para que os desenvolvedores implementem os componentes conforme o desenho o Facilita a comunicação entre equipes técnicas e não técnicas, promovendo um entendimento comum. Suporte à Tomada de Decisões o Permite a escolha de tecnologias, padrões e frameworks que melhor atendem aos objetivos do projeto. o Facilita a analise de risco e mitigação de problemas antes da implementação. As componentes do Desenho Arquitetural são as seguintes: Diagramas Arquiteturais Diagrama de Componentes o Representam os principais blocos do sistema e suas interações Diagramas de Implantação o Detalham como os componentes serão distribuídos em servidores ou dispositivos Diagramas de Sequência ou Fluxo o Mostram como os dados fluem entre os componentes 4 Estilo ou Padrão Arquitetural O estilo escolhido depende das características do projeto. Interfaces e Integrações Especificação de API’s e protocolos de comunicação Detalhes sobre a interoperabilidade com outros sistemas Decisões Arquiteturais Documentação das escolhas feitas, como tecnologias, frameworks e padrões Justificações e possíveis impactos futuros Ferramentas para o Desenho Arquitetural Modelaçao Visual – UML, C4 Model, Archimate Plataformas Colaborativas – Lucidchart, Draw.io, Visio Documentaçao – Markdown, Wikis corporativos, ADR (Architecture Decision Records). 3 – Design de Interfaces – Garante comunicação eficiente entre utilizadores e componentes O desenho de interfaces é uma etapa fundamental no processo de desenvolvimento de software. Trata da conceção e estruturação da interação entre os utilizadores e o sistema, visando garantir que o software seja intuitivo, funcional e eficiente, tendo em conta tanto os objetivos dos utilizadores como os requisitos técnicos do projeto. O desenho de interfaces é a atividade de criar o layout e os elementos visuais que compõem a interação de um utilizador com um sistema. Inclui botões, menus, formulários, janelas e outros componentes visuais, indo além do aspeto estético, pois o foco principal é proporcionar: Uma UX positiva Uma boa usabilidade (UI) Os principais objetivos do Desenho de Interfaces são: 1. Permitir que os utilizadores realizem tarefas de forma eficiente e com o mínimo esforço 2. Garantir que o sistema seja acessível a pessoas com diferentes níveis de capacidade e dispositivos 3. Manter padrões visuais e funcionais para reduzir a curva de aprendizagem dos utilizadores. 4. Criar interfaces visualmente apelativas, mas sem comprometer a usabilidade 5 Etapas do Desenho de Interfaces 1. Pesquisa e Planeamento a. Compreensão do utilizador: i. Estudar o público-alvo (personas/comportamentos/necessidades) b. Definição de objetivos i. Identificar o que o software precisa alcançar para os utilizadores e a empresa c. Mapeamento de tarefas i. Compreender os fluxos de trabalho e tarefas que os utilizadores irão realizar 2. Criação de protótipos a. Wireframes – Esboços simples para definir a estrutura e o layout inicial b. Mockups – Versões mais detalhadas, com elementos visuais realistas c. Protótipos Interativos – Modelos funcionais que simulam a navegação e as interações 3. Testes de Usabilidade a. Validar o protótipo com utilizadores reais para identificar problemas de desenho b. Obter feedback sobre a clareza, funcionalidade e eficiência da interface. 4. Interação a. Ajustar e melhorar a interface com base nos resultados dos testes. b. Repetir o processo até que a interface esteja otimizada. Ferramentas utilizadas no Desenho de Interfaces Ferramentas de desenho: Figma, Adobe XD, Sketch Prototipagem rápida: InVision, Marvel App Testes de usabilidade: Maze, UsabilityHub Integração de Desenho de Interfaces A interface deve ser desenhada tendo em conta as limitações e possibilidades tecnológicas como frameworks front-end (React, Angular) e linguagens de programação. A colaboração entre arquitetos e programadores é essencial para que o desejo seja implementado como planeado. 6 Benefícios de Desenho de Interfaces 1. Maior Satisfação do Utilizador – Interfaces bem desenhadas reduzem a frustração e melhoram a experiência 2. Redução de Erros – Um desenho claro e intuitivo minimiza mal-entendidos e ações incorretas. 3. Melhor Retenção – Os utilizadores tendem a continuar a usar sistemas que oferecem uma experiência agradável 4 – Design de Componentes – Detalha a logica interna de cada modulo de software O desenho de componentes é uma etapa no desenvolvimento de software que detalha a logica interna de cada modulo ou componente do sistema. Esta atividade foca-se em definir como cada componente será implementado internamente, desde a organização do seu código até às interações internas que suportam as funcionalidades desejadas. Esta etapa é essencial no desenho de software, pois garante que cada parte do sistema seja eficiente, reutilizável e funcionalmente correta. O que é um Componente? Um componente é uma unidade logica do software que encapsula uma funcionalidade especifica e pode interagir com outros componentes. Pode ser representado por um modulo, classe, função ou mesmo um conjunto de objetos que desempenham uma tarefa concreta dentro do sistema. Objetivos do Design de Componentes 1. Definir a logica interna – De forma clara e modular separando responsabilidades 2. Garantir a coesão interna – Todos os elementos dentro de um componente devem estar relacionados à funcionalidade que ele oferece 3. Promover a reutilização de código – Projetando componentes genéricos que podem ser usados noutras partes do sistema 4. Facilitar a manutenção e evolução do Software – Dividindo a logica em unidades bem definidas 5. Reduzir o acoplamento – Minimizando as dependências entre componentes 7 Elementos do Design de Componentes Estrutura Interna o Identificar e projetar as funções / métodos principais o Definir as classes ou estruturas de dados usadas dentro do componente o Garantir que o componente tenha uma interface externa clara, escondendo os detalhes de implementação Fluxo de Dados o Detalhar como os dados fluem através do componente: entradas, saídas e transformações internas. o Utilizar diagramas de fluxo de dados ou pseudocódigo para ilustrar o funcionamento. Gestão de Estados o Definir como o componente gerirá o seu estado interno Tratamento de Erros o Incluir lógica para prever e gerir falhas internas, como validação de dados ou gestão de exceções Interações internas o Especificar como as partes internas do componente comunicam entre si Passos para o Desenho de Componentes 1. Definir o objetivo do componente a. O que este componente deve fazer? b. Quais são as entradas e saídas esperadas? 2. Projetar a interface externa a. Quais métodos ou funções o componente ira expor para outros módulos? (API REST, funções publicas, eventos) 3. Detalhar a logica interna a. Criar diagramas ou pseudocódigo para descrever o funcionamento interno b. Identificar subcomponentes, classes ou estruturas de suporte 4. Identificar dependências a. Listar outros componentes, serviços ou bibliotecas necessárias 5. Testar a logica interna a. Garantir que cada unidade de funcionalidade funciona como esperado através de testes unitários Ferramentas usadas no Desenho de Componentes UML – Para desenhar diagramas de classes, de sequência ou de atividades Data Flux Diagrams – Para representar como os dados são processados internamente Ferramentas de Desenho – Lucidchart, Draw.io ou Microsoft Visio para criar diagramas Pseudocódigo – Para descrever o fluxo logico de algoritmos 8 Diretrizes de Qualidade no Desenho Um desenho de qualidade deve: Ser modular facilitando manutenção e escalabilidade Usar padrões arquiteturais reconhecidos Garantir interfaces simples e intuitivas Representar requisitos claramente e ser rastreável Conceitos Fundamentais de Desenho Abstração – Foca nos aspetos essenciais, ignorando detalhes desnecessários Modularidade – Divisão do sistema em partes menores e independentes Ocultação de informação – Limita o acesso a detalhes internos para reduzir dependências Independência Funcional – Altamente coeso e com baixo acoplamento entre módulos Princípios de Modulação de Desenho 1. O desenho deve ser rastreável aos requisitos 2. Considerar sempre a arquitetura do sistema a construir 3. Desenho de dados é tao importante como o desenho de funções de processamento 4. Interfaces devem ser desenhadas cuidadosamente 5. O design da UI deve ser adaptado às necessidades do end-user e dar ênfase à facilidade de uso 6. Desenho ao nível dos componentes deve ser funcionalmente independente 7. Os componentes devem estar fracamente acoplados entre si e ao ambiente. 8. As representações de design (modelos) devem ser facilmente compreensíveis. 9. Desenvolva iterativamente para ajustar e refinar 10. Adapte o desenho a diferentes abordagens, como ágil ou cascata. 9  10 – Arquiteturas de Software Arquiteturas de software são um conjunto de decisões organizacionais que definem o design e a operação de um sistema de software. Estas desempenham um papel fundamental no processo de engenharia de software, funcionando como um plano que guia o desenvolvimento, a evolução e a manutenção de um sistema. Definição de Arquitetura de Software Estrutura de um sistema, composta pelos elementos do software, as suas interações e as propriedades que eles exibem. É uma representação de alto nível que considera não apenas aspetos técnicos, mas também requisitos funcionais e não funcionais, como desempenho, escalabilidade, segurança e manutenibilidade. Componentes Principais da Arquitetura de Software Componentes (ou módulos) o São as partes independentes do sistema que realizam funções especificas. Podem ser bibliotecas, serviços ou outros elementos de software Conexões (ou conectores) o Representam as interações entre os componentes, como chamadas de funções, API’s, mensagens ou eventos Restrições e Regras o Conjunto de diretrizes que definem como os componentes e conectores devem interagir, assegurando que o sistema atenda aos requisitos desejados Visões Arquiteturais: A arquitetura pode ser representada sob diferentes perspetivas como o Visão logica ▪ Foca no comportamento e funcionalidades do sistema o Visão Física ▪ Descreve a infraestrutura de hardware onde o software será executado o Visão de desenvolvimento ▪ Mostra como o software será organizado para facilitar a construção e a manutenção o Visão de processos ▪ Aborda aspetos relacionados à execução do sistema, como concorrência e comunicação. 10 Importância da Arquitetura de Software A arquitetura de software é uma base para tomada de decisões, ajudando a tomar decisões sobre tecnologias, frameworks, linguagens de programação e padrões de design. Estas oferecem também grande facilidade de evolução e manutenção, o que facilita a adição de novas funcionalidades, a correção de erros e a adaptação a mudanças. Para alem disso serve como um modelo comum para desenvolvedores, gerentes, clientes e outros stakeholders, facilitando o entendimento e a colaboração. Por fim são uma garantia de qualidade, ajudando a atende requisitos de qualidade como desempenho, escalabilidade, confiabilidade e segurança. Processo de Criação da Arquitetura de Software 1. Entendimento dos Requisitos a. Requisitos funcionais e não funcionais são obtidos e analisados para guiar as decisões arquiteturais 2. Escolha de Estilos Arquiteturais a. Estilos são avaliados e selecionados 3. Modelação a. A arquitetura é representada por diagramas e documentos que explicam a sua estrutura e comportamento 4. Avaliação a. Técnicas como ATAM (Architecture Tradeoff Analysis Method) são usadas para avaliar a eficácia da arquitetura proposta 5. Documentação e Comunicação a. A arquitetura é documentada e apresentada para garantir que todos os envolvidos entendam o plano e possam contribuir Relação com a Engenharia de Software A arquitetura é a base que conecta todas as etapas do ciclo de vida do desenvolvimento, influenciando: Analise de Requisitos o Vincula necessidades ao design técnico Design e Implementação o Guia a estruturação do código e a escolha de padrões Testes o Define pontos de controle e critérios de qualidade Manutenção o Oferece uma base consistente para atualizar o sistema 11 Estilos Arquiteturais São padrões de design amplamente reconhecidos que guiam a organização e a interação dos componentes de um sistema. Cada estilo é projetado para atender a diferentes necessidades e restrições de sistemas e é escolhido com base nos requisitos funcionais e não funcionais. 1 – Arquitetura em Camadas Organiza o sistema em camadas empilhadas, onde cada camada fornece serviços à camada acima e consome serviços da camada abaixo. Geralmente inclui camadas como apresentação, logica de negócios e acesso a dados. São vantagens e desvantagens os seguintes aspetos: Separação de responsabilidades: Facilita a manutenção e a compreensão Facilidade de teste: As camadas podem ser testadas individualmente Reutilização: Componentes de camadas podem ser reutilizados em outros sistemas Desempenho: A comunicação entre camadas pode adicionar sobrecarga Dependência Rígida: Alterações numa camada podem exigir mudanças em outras 2 – Arquitetura Cliente-Servidor Divide o Sistema em dois componentes principais: O servidor, que processa dados e fornece serviços e o cliente, que consome os serviços do servidor. São vantagens e desvantagens os seguintes aspetos: Distribuição: Permite a interação entre dispositivos distintos Escalabilidade: É possível adicionar mais clientes sem alterar o servidor Dependência da rede: O sistema depende de uma ligação estável Manutenção: O serviço pode se tornar um ponto único de falha 3 – Arquitetura Monolítica O sistema é desenvolvido como um único bloco de código, onde todos os componentes serão integrados. Esta arquitetura tem as seguintes vantagens e desvantagens: Simplicidade: Fácil de desenvolver e implantar em sistemas pequenos Desempenho: Não há sobrecarga de comunicação entre serviços Manutenção: Torna-se difícil escalar e atualizar à medida que cresce Confiabilidade: Um erro pode afetar o sistema todo 12 4 – Arquitetura de Microserviços Divide o sistema em pequenos serviços independentes, cada um com a sua própria logica e base de dados comunicando.se via API’s. Esta arquitetura tem as seguintes vantagens e desvantagens: Escalabilidade: Serviços podem ser escalados de forma independente Manutenção: Alterações em um serviço não afetam outros Complexidade: Gerir muitos serviços pode ser desafiador Comunicação: A comunicação entre serviços pode adicionar latência 5 – Arquitetura Baseada em Eventos Componentes do sistema comunicam-se através de eventos assíncronos. Um evento é gerado por um produtor e consumido por um ou mais consumidores. Seguem as vantagens e desvantagens: Desempenho: Pode lidar com altos volumes dados em tempo real Flexibilidade: Permite desacoplamento entre componentes Depuração: Difícil rastrear o fluxo de dados Complexidade: Requer um mecanismo eficiente de fila ou barramento 6 – Arquitetura Orientada a Serviços O sistema é composto por serviços reutilizáveis e independentes que se comunicam via protocolos padronizados, como SOAP ou REST. Seguem as vantagens e desvantagens: Reutilização: Serviços podem ser usados em diferentes aplicações Interoperabilidade: Integração com diferentes plataformas Sobrecarga: A comunicação pode ser lenta devido ao uso de protocolos complexos Manutenção: A gestão de contratos de serviços pode ser difícil 7 – Arquitetura de Repositório Compartilhado Todos os componentes compartilham um repositório de dados centralizado, como uma base de dados. Esta arquitetura tem as seguintes vantagens e desvantagens: Consistência: Todos os componentes acedem a dados atualizados Facilidade de integração: Os dados são centralizados Confiabilidade: O repositório é um ponto único de falha Desempenho: O acesso simultâneo pode causar gargalos 13 8 – Arquitetura de Pipeline e Filtros O sistema é composto por filtros que processam dados e passam os resultados para o próximo filtro num pipeline. Esta arquitetura tem as seguintes vantagens e desvantagens: Modularidade: Filtros são componentes independentes Reutilização: Filtros podem ser reaproveitados em diferentes pipelines Desempenho: Processamento sequencial pode ser lento Flexibilidade: Difícil alterar a ordem dos filtros sem fazer refactoring 9 – Arquitetura Orientada a Componentes O sistema é composto por componentes modulares que podem ser desenvolvidos e implementados independentemente. Tem as seguintes vantagens e desvantagens: Reutilização: Componentes podem ser compartilhados entre sistemas Manutenção: Alterações em um componente não afetam os restantes Complexidade: Integração e comunicação entre componentes podem ser difíceis Sobrecarga: A gestão de dependências pode ser trabalhosa. 10 – Arquitetura de Computação em Nuvem Os serviços e recursos do sistema são fornecidos por meio de plataformas de computação em nuvem. Tem as seguintes vantagens e desvantagens: Escalabilidade: Recursos podem ser ajustados conforme a procura Custo-benefício: Reduz custos iniciais de infraestrutura Dependência de provedores: Risco de lock-in com fornecedores Segurança: Dados sensíveis podem estar expostos Computação em Nuvem (Cloud Computing) Localização: Centros de dados centralizados Função: Oferece recursos de computação escaláveis e sob demanda, como armazenamento, processamento e serviços analíticos. Vantagens e Limitações: Alta escalabilidade e elasticidade Custos reduzidos devido ao modelo de pagamento conforme o uso Ampla disponibilidade de recursos computacionais avançados Alta latência em sistemas que dependem de tempo real Consome maior largura de banda devido à transferência de grandes volumes de dados. 14 Computação em Névoa (Fog Computing) Localização: Dispositivos mais próximos do utilizador final ou do dispositivo IoT Função: Fornece capacidade de processamento, armazenamento e rede para reduzir a latência e o tráfego em direção à nuvem. Vantagens e Limitações: Baixa latência e rápida resposta Reduz o tráfego de dados para a nuvem Melhor suporte para aplicações em tempo real Menor capacidade de processamento e armazenamento em comparação com a nuvem Maior complexidade para gerir dispositivos distribuídos Cloud and Fog-based Architecture É um modelo que combina computação em nuvem e computação em nevoa para distribuir recursos e capacidades de processamento. Este modelo é amplamente utilizado em sistemas que precisam de escalabilidade, baixa latência e suporte a dispositivos distribuídos, como em aplicações da Internet das Coisas (IoT), smart cities e sistemas industriais Este modelo utiliza os melhores recursos de cada paradigma, permitindo que tarefas sejam distribuídas entre a nuvem e a névoa, dependendo das necessidades da aplicação. Componentes Principais Dispositivos Perifericos (Edge Devices) o Sensores, atuadores e dispositivos IoT que coletam dados Camada de Névoa (Fog Layer) o Gateways e dispositivos intermediários que processam os dados localmente Camada de Nuvem o Grandes data centers que realizam armazenamento massivo, analise avançada e machine learning 15 Fluxo de Dados Recolha de Dados: Os dispositivos periféricos capturam dados brutos Processamento Local (Fog) o Parte dos dados é processada localmente para aplicações em tempo real o Decisões rápidas são tomadas sem necessidade de enviar dados para a nuvem Envio à nuvem o Dados processados ou menos urgentes são enviados para a nuvem para analises mais profundas ou armazenamento Distribuição de Resultados o Resultados processados pela nuvem são enviados de volta para a camada de nevoa ou dispositivos periféricos. Vantagens e Desafios Baixa Latência: A camada de nevoa reduz atrasos ao processar informações localmente Eficiência no Uso de Rede: Minimiza o envio desnecessário de dados para a nuvem Escalabilidade: A nuvem oferece capacidade praticamente ilimitada para lidar com picos de procura Resiliência: Em caso de falha na conexão com a nuvem, a camada de nevoa pode continuar a operar de forma independente Segurança e Privacidade: Maior número de dispositivos e camadas exige políticas rigorosas de segurança Gestão de Recursos: Coordenar tarefas entre nevoa e nuvem pode ser complexo Interoperabilidade: Dispositivos e plataformas diferentes precisam de funcionar de forma integrada 16