Arquitetura de Software: Estruturas e Componentes em Sistemas de Software

ENGENHARIA DE SOFTWARE II Prof Júlio Machado ARQUITETURA DE SOFTWARE Sistemas de Software Sistemas Operacionais Aplicações Corporativas Sistemas de Controle Jogos Sistemas de Telecomunicação Aplicações de Produtividade para Desktops Arquitetura de Software Aplicações Corporativas Exemplos Sites de vendas Reservas de passagens Folha de pagamento Cadeia de suprimentos Bancos Relacionamento com cliente Organização de alunos turmas disciplinas cursos de uma universidade etc Características Dados persistentes Alterações no programa e no hardware durante o ciclo de vida do sistema Os dados precisam resistir a essas mudanças Grande volume de dados Acesso concorrente aos dados Interface com usuário tem papel importante Integração com outras aplicações corporativas Diferentes tecnologias Dados com significados diferentes em diferentes setores da mesma empresa Lógica de negócio complexa ARQUITETURA E COMPONENTES Aplicações Corporativas Diversas facetas Aplicações móveis Aplicações de cliente rico Aplicações web Aplicações de serviços etc Características básicas Limitações Requisitos Arquitetura de Software Para criar um produto confiável seguro e eficiente você precisa prestar atenção ao projeto arquitetônico que inclui sua organização geral como o software é decomposto em componentes as tecnologias que você usa para construir o software A arquitetura de um produto de software afeta seu desempenho usabilidade segurança confiabilidade e capacidade de manutenção Arquitetura de Software Existem muitas interpretações diferentes do termo arquitetura de software Alguns focam em arquitetura como um substantivo a estrutura de um sistema e outros consideram arquitetura como um verbo o processo de definição dessas estruturas Termos em comum Alguma estrutura de altonível que permeia todo o sistema Decomposição em alto nível de um sistema em suas partes Decisões difíceis de alterar Arquitetura de Software IEEE Arquitetura é a organização fundamental de um sistema de software incorporado em seus componentes seus relacionamentos entre si e com o ambiente e os princípios que orientam seu projeto e evolução Arquitetura de Software Martin Fowler Is Design Dead O quê você quer dizer com arquitetura de software Para mim o termo arquitetura traz consigo uma noção de elementos centrais de um sistema as peças que são difíceis de serem alteradas Uma base sobre a qual o resto deve ser construído Arquitetura de Software Larman Utilizando UML e Padrões Uma arquitetura é um conjunto de decisões significativas sobre a organização de um sistema de software a seleção dos elementos estruturais e suas interfaces pelos quais o sistema é composto juntamente com seu comportamento como especificado nas colaborações entre esses elementos a composição desses elementos estruturais e comportamentais em subsistemas progressivamente maiores e o estilo arquitetural que dirige essa organização Arquitetura de Software Análise arquitetural Identificar fatores que devem influenciar a arquitetura entender sua variabilidade e prioridade e resolvêlos É útil para Reduzir o risco de esquecer algo importante no projeto de sistemas Evitar aplicar esforço excessivo a tópicos de baixa prioridade Ajudar a enquadrar o produto aos objetivos do negócio Arquitetura de Software Algumas questões a serem levadas em consideração na definição de uma arquitetura Como a aplicação será instalada para entrar em produção Como os usuários irão usar a aplicação tipos de interface Quais são os requisitos de qualidade tais como segurança performance concorrência internacionalização e configuração Quais as questões relativas a aspectos de arquitetura que podem impactar a aplicação agora ou depois de ter sido instalada Arquitetura de Software O que se espera encontrar em uma descrição arquitetural de um sistema de software fonte HANMER R Pattern Oriented Software Architecture for Dummies Objetivos e filosofia do sistema O que se assume sobre o sistema e suas dependências Requisitos significativos Instruções sobre empacotamento e implantação de componentes e subsistemas Descrição dos subsistemas mais críticos Referências para os principais elementos de projeto Descrição das interfaces mais críticas com outros sistemas Apresentação dos cenários mais importantes que influenciam o funcionamento do sistema Arquitetura de Software Diferentes visões sobre uma arquitetura fonte HANMER R PatternOriented Software Architecture for Dummies Classificar as arquiteturas que são usadas nos sistemas nos permite reusar esse conhecimento Essa classificação levou a identificação de famílias de arquiteturas que caracterizam estilos arquiteturais Cada estilo arquitetural oferece suporte a um conjunto de requisitos não funcionais e atributos de projeto Arquitetura de Software Exemplos de estilos arquiteturais Pipes e filtros Camadas Invocação implícita Quadro negro Clienteservidor Orientada a serviços Serverless etc Arquitetura de Software Arquitetura de Software Existem muitas arquiteturas que combinam as arquiteturas básicas Existem arquiteturas que tem como foco um determinado tipo de aplicação as chamadas arquiteturas de domínio específico Um domínio específico bastante conhecido são os sistemas de informação Para a área de sistemas de informação existem alguns padrões arquiteturais muito utilizados Arquitetura de Software As arquiteturas atuais podem ser pensadas em 3 grandes partes Como o sistema deve ser organizado como um conjunto de componentes de arquitetura onde cada um desses componentes fornece um subconjunto da funcionalidade geral do sistema A organização deve fornecer a segurança a confiabilidade e o desempenho do sistema de que você precisa Como esses componentes arquiteturais devem ser distribuídos e se comunicar uns com os outros Quais tecnologias você deve usar na construção do sistema e quais componentes devem ser reutilizados Arquitetura de Software Arquitetura de Software Orientações para a definição de uma arquitetura de um sistema de informação 1 Identificar o tipo de aplicação que se pretende construir Aplicação para dispositivo móvel Aplicação stand alone executa em um PC Aplicação Web Serviço para ser consumido por outras aplicações Etc Arquitetura de Software Orientações para a definição de uma arquitetura de um sistema de informação 2 Identificar de que forma essa aplicação será construída Clienteservidor Baseada em componentes Multicamada MVC Orientada a objetos SOA MessageBus Onion Hexagonal Clean Etc Arquitetura de Software Orientações para a definição de uma arquitetura de um sistema de informação 3 Identificar como serão incorporados os requisitos de qualidade e os aspectos que permeiam toda aplicação Requisitos de qualidade Segurança Performance Manutenção Etc Aspectos que permeiam toda aplicação Autenticação Autorização Cache de dados Tratamento de exceções Log de eventos Etc Categorias de Padrões Padrões arquiteturais Relacionados ao projeto em larga escala e não refinado Normalmente aplicados durante as primeiras interações Ex padrão camadas Padrões de projeto Relacionados ao projeto em pequena e média escala dos objetos e frameworks Exs Observer Iterator Facade Outras categorias Padrões de processo de desenvolvimento Padrões de interface com o usuário Padrões de teste Opções de tecnologia Base de dados Você deve usar um banco de dados SQL relacional ou um banco de dados NOSQL não estruturado Plataforma Você deve entregar seu produto em um aplicativo móvel eou em uma plataforma web Servidor Você deve usar servidores internos dedicados ou projetar seu sistema para ser executado em uma nuvem pública Se for uma nuvem pública você deve usar Amazon Google Microsoft ou alguma outra opção Código aberto Existem componentes de código aberto adequados que você poderia incorporar em seus produtos Ferramentas de desenvolvimento Suas ferramentas de desenvolvimento incorporam suposições arquitetônicas sobre o software que está sendo desenvolvido que limitam suas escolhas arquitetônicas Base de dados Existem dois tipos de banco de dados que agora são comumente usados Bancos de dados relacionais onde os dados são organizados em tabelas estruturadas Bancos de dados NoSQL nos quais os dados têm uma organização mais flexível e definida pelo usuário Bancos de dados relacionais como MySQL são particularmente adequados para situações em que você precisa de gerenciamento de transações e as estruturas de dados são previsíveis e bastante simples Bancos de dados NoSQL como MongoDB são mais flexíveis e potencialmente mais eficientes do que bancos de dados relacionais para análise de dados Os bancos de dados NoSQL permitem que os dados sejam organizados hierarquicamente em vez de tabelas simples e isso permite um processamento simultâneo mais eficiente de big data Plataforma de entrega A entrega pode ser como um produto baseado na web ou móvel ou ambos Problemas móveis Conectividade intermitenteVocê deve ser capaz de fornecer um serviço limitado sem conectividade de rede Potência do processadorOs dispositivos móveis têm processadores menos potentes portanto você precisa minimizar as operações de computação intensiva Gerenciamento de energiaA vida útil da bateria móvel é limitada portanto tente minimizar a energia usada pelo seu aplicativo Teclado na telaOs teclados na tela são lentos e propensos a erros Você deve minimizar a entrada usando o teclado da tela para reduzir a frustração do usuário Para lidar com essas diferenças você geralmente precisa de versões separadas para navegador e para dispositivos móveis do frontend do seu produto Você pode precisar de uma arquitetura de decomposição completamente diferente nessas diferentes versões para garantir que o desempenho e outras características sejam mantidas Servidor Uma decisão importante que você precisa tomar é projetar seu sistema para ser executado nos servidores do cliente ou na nuvem Para produtos de consumo que não são simplesmente aplicativos móveis acho que quase sempre faz sentido desenvolver para a nuvem Para produtos de negócios é uma decisão mais difícil Algumas empresas estão preocupadas com a segurança na nuvem e preferem executar seus sistemas em servidores internos Eles podem ter um padrão previsível de uso do sistema portanto há menos necessidade de projetar seu sistema para lidar com grandes mudanças na demanda Uma escolha importante que você precisa fazer se estiver executando seu software na nuvem é qual provedor de nuvem usar Código aberto O software de código aberto é um software disponível gratuitamente que você pode alterar e modificar conforme desejar A vantagem é que você pode reutilizar em vez de implementar um novo software o que reduz os custos de desenvolvimento e o tempo de lançamento no mercado As desvantagens de usar software de código aberto é que você está limitado por esse software e não tem controle sobre sua evolução A decisão sobre o uso de software de código aberto também depende da disponibilidade maturidade e suporte contínuo de componentes de código aberto Problemas de licença de código aberto podem impor restrições sobre como você usa o software Sua escolha de software de código aberto deve depender do tipo de produto que você está desenvolvendo seu mercado alvo e a experiência de sua equipe de desenvolvimento Ferramentas de desenvolvimento As tecnologias de desenvolvimento como um kit de ferramentas de desenvolvimento móvel ou uma estrutura de aplicativo da Web influenciam a arquitetura do seu software Essas tecnologias têm suposições internas sobre arquiteturas de sistema e você precisa estar em conformidade com essas suposições para usar o sistema de desenvolvimento A tecnologia de desenvolvimento que você usa também pode ter uma influência indireta na arquitetura do sistema Os desenvolvedores geralmente preferem escolhas arquitetônicas que usam tecnologias familiares que eles entendem Por exemplo se sua equipe tem muita experiência em bancos de dados relacionais eles podem argumentar a favor disso em vez de um banco de dados NoSQL Componentes Um componente é um elemento que implementa um conjunto coerente de funcionalidades ou recursos O componente de software pode ser considerado como uma coleção de um ou mais serviços que podem ser usados por outros componentes Ao projetar a arquitetura de software você não precisa decidir como um elemento ou componente de arquitetura deve ser implementado Em vez disso você projeta a interface do componente e deixa a implementação dessa interface para um estágio posterior do processo de desenvolvimento Componentes Complexidade Arquitetural A complexidade em uma arquitetura de sistema surge devido ao número e à natureza das relações entre componentes nesse sistema Ao decompor um sistema em componentes você deve tentar evitar a complexidade desnecessária do software Localizar relacionamentos Se houver relações entre os componentes A e B estes são mais fáceis de entender se A e B são definidos no mesmo módulo Reduzir dependências compartilhadas Quando os componentes A e B dependem de algum outro componente ou dados a complexidade aumenta porque as alterações no componente compartilhado significam que você tem que entender como essas alterações afetam tanto A quanto B É sempre preferível usar dados locais sempre que possível e evitar o compartilhamento de dados se puder Exemplos de relações de componentes Diretrizes de design arquitetural ARQUITETURA E REQUISITOS Por que a arquitetura é importante A arquitetura é importante porque a arquitetura de um sistema tem uma influência fundamental nas propriedades não funcionais do sistema mostradas na tabela a seguir O projeto arquitetônico envolve a compreensão dos problemas que afetam a arquitetura do seu produto e a criação de uma descrição da arquitetura que mostra os componentes críticos e seus relacionamentos Minimizar a complexidade deve ser um objetivo importante para designers de arquitetura Quanto mais complexo um sistema mais difícil e caro é entender e mudar Os programadores são mais propensos a cometer erros e introduzir bugs e vulnerabilidades de segurança quando estão modificando ou estendendo um sistema complexo Atributos de qualidade não funcional do sistema Capacidade de resposta O sistema retorna os resultados aos usuários em um tempo razoável Confiabilidade Os recursos do sistema se comportam conforme o esperado por desenvolvedores e usuários Disponibilidade O sistema pode entregar seus serviços quando solicitado pelos usuários Segurança O sistema protege a si mesmo e os dados dos usuários contra ataques e intrusões não autorizados Usabilidade Os usuários do sistema podem acessar os recursos de que precisam e usálos rapidamente e sem erros Manutenibilidade O sistema pode ser prontamente atualizado e novos recursos adicionados sem custos indevidos Resiliência O sistema pode continuar a fornecer serviços ao usuário em caso de falha parcial ou ataque externo Arquiteturas de segurança centralizadas Os benefícios de uma arquitetura de segurança centralizada são que é mais fácil projetar e construir proteção e que as informações protegidas podem ser acessadas com mais eficiência No entanto se sua segurança for violada você perderá tudo Se você distribuir informações levará mais tempo para acessar todas as informações e custará mais para protegêlas Se a segurança for violada em um local você perderá apenas as informações armazenadas lá Manutenibilidade e desempenho A Figura a seguir mostra um sistema com dois componentes C1 e C2 que compartilham um banco de dados comum Suponha que C1 seja executado lentamente porque precisa reorganizar as informações no banco de dados antes de usálo A única maneira de tornar o C1 mais rápido pode ser alterar o banco de dados Isso significa que C2 também precisa ser alterado o que pode potencialmente afetar seu tempo de resposta Arquitetura de banco de dados compartilhado Manutenibilidade e desempenho Na figura subsequente uma arquitetura diferente é usada onde cada componente tem sua própria cópia das partes do banco de dados de que precisa Se um componente precisar alterar a organização do banco de dados isso não afetará o outro componente No entanto uma arquitetura de vários bancos de dados pode ser executada mais lentamente e pode custar mais para implementar e alterar Uma arquitetura de vários bancos de dados precisa de um mecanismo componente C3 para garantir que os dados compartilhados por C1 e C2 sejam mantidos consistentes quando forem alterados Arquitetura de banco de dados múltipla Trade off Manutenibilidade vs desempenho A manutenibilidade do sistema é um atributo que reflete o quão difícil e caro é fazer alterações em um sistema depois que ele foi liberado para os clientes Você melhora a capacidade de manutenção construindo um sistema a partir de pequenas peças independentes cada uma das quais pode ser substituída ou aprimorada se forem necessárias alterações Em termos de arquitetura isso significa que o sistema deve ser decomposto em componentes de granulação fina cada um dos quais faz uma coisa e apenas uma coisa No entanto leva tempo para que os componentes se comuniquem entre si Conseqüentemente se muitos componentes estiverem envolvidos na implementação de um recurso do produto o software será mais lento Trade off Segurança x usabilidade Você pode obter segurança projetando a proteção do sistema como uma série de camadas Figura a seguir Um invasor precisa penetrar em todas essas camadas antes que o sistema seja comprometido As camadas podem incluir camadas de autenticação do sistema uma camada de autenticação de recurso crítico separada uma camada de criptografia e assim por diante Arquitetonicamente você pode implementar cada uma dessas camadas como componentes separados para que se um desses componentes for comprometido por um invasor as outras camadas permaneçam intactas Camadas de Autenticação IP authentication Application authentication Feature authentication Encryption Protected asset such as a database of users credit cards Problemas de usabilidade Uma abordagem de segurança em camadas afeta a usabilidade do software Os usuários precisam lembrar de informações como senhas necessárias para penetrar em uma camada de segurança Sua interação com o sistema é inevitavelmente retardada por seus recursos de segurança Muitos usuários acham isso irritante e geralmente procuram soluções alternativas para que não precisem se autenticar novamente para acessar recursos ou dados do sistema Para evitar isso você precisa de uma arquitetura que não tem muitas camadas de segurança que não impõe segurança desnecessária que fornece componentes auxiliares que reduzem a carga sobre os usuários Trade off Disponibilidade vs tempo de colocação no mercado A disponibilidade é particularmente importante em produtos corporativos como produtos para o setor financeiro onde se espera uma operação 24 horas por dia 7 dias por semana A disponibilidade de um sistema é uma medida da quantidade de uptime desse sistema A disponibilidade é normalmente expressa como uma porcentagem do tempo que um sistema está disponível para fornecer serviços ao usuário Arquitetonicamente você obtém disponibilidade ao ter componentes redundantes em um sistema Para fazer uso da redundância você inclui componentes de sensores que detectam falhas e componentes de comutação que alternam a operação para um componente redundante quando uma falha é detectada A implementação de componentes extras leva tempo e aumenta o custo de desenvolvimento do sistema Ele adiciona complexidade ao sistema e portanto aumenta as chances de introdução de bugs e vulnerabilidades Problemas que influenciam as decisões de arquitetura A importância das questões de projeto arquitetônico Características não funcionais do produto Características não funcionais do produto como segurança e desempenho afetam todos os usuários Se você errar é improvável que seu produto seja um sucesso comercial Infelizmente algumas características são opostas então você só pode otimizar o mais importante Vida útil do produto Se você prevê uma longa vida útil do produto precisará criar revisões regulares do produto Portanto você precisa de uma arquitetura que seja evolutiva para que possa ser adaptada para acomodar novos recursos e tecnologias A importância das questões de projeto arquitetônico Reutilização de software Você pode economizar muito tempo e esforço se puder reutilizar componentes grandes de outros produtos ou software de código aberto No entanto isso restringe suas escolhas arquitetônicas porque você deve ajustar seu projeto ao software que está sendo reutilizado Número de usuários Se você estiver desenvolvendo software de consumo distribuído pela Internet o número de usuários pode mudar muito rapidamente Isso pode levar a uma séria degradação do desempenho a menos que você projete sua arquitetura para que seu sistema possa ser rapidamente dimensionado para cima e para baixo Compatibilidade de software Para alguns produtos é importante manter a compatibilidade com outros softwares para que os usuários possam adotar seu produto e usar os dados preparados usando um sistema diferente Isso pode limitar as escolhas de arquitetura como o software de banco de dados que você pode usar ARQUITETURA EM CAMADAS Arquitetura em Camadas Camada layer é um agrupamento de granularidade grossa de classes pacotes ou subsistemas que tem responsabilidade coesiva sobre um tópico importante do sistema Arquitetura em Camadas Camadas usuais de um sistema em 3camadas Camada de apresentação ou de interface com o usuário Interação com o usuário Responsável por apresentar informações para o usuário e interpretar comandos do usuário em ações sobre a camada de domínio Ex uma interface de cliente rico em Swing do Java Camada de domínio ou de negócios Objetos de software representando conceito do domínio que satisfazem requisitos da aplicação Envolve cálculos regras de validações regras de negócio Camada de persistência ou de dados Objetos de propósito geral e subsistemas que fornecem serviços para a aplicação Geralmente são independentes da aplicação e reusáveis entre diversos sistemas Ex uma fonte de dados a partir de um SGBD relacional Arquitetura em Camadas Princípios Organizar a estrutura lógica de larga escala de um sistema em camadas discretas de responsabilidades distintas relacionadas com uma separação clara e coesa de interesses Colaboração e acoplamento ocorrem das camadas superiores para as inferiores Acoplamento das camadas inferiores para as superiores deve ser evitado Arquitetura em Camadas Benefícios Estabelece uma separação de interesses de serviços de alto para baixo nível de serviços de aplicação gerais para específicos Reduz o acoplamento e as dependências Melhora a coesão Aumenta o potencial de reuso Aumenta a clareza Complexidade relacionada é encapsulada e decomponível Algumas camadas podem ser substituídas por nova implementação As camadas inferiores contêm funções reusáveis Algumas camadas principalmente de domínio e de dados podem ser distribuídas Desenvolvimento em equipes é facilitado Arquitetura em Camadas Outro conceito de camada vem do termo tier Representa a separação física das camadas lógicas em múltiplos nodos computacionais Ex um sistema clienteservidor pode ser visto como 2tier onde o cliente é um aplicativo desktop e o servidor é um SGBD Diretrizes Básicas Mantenha uma separação de interesses Mantenha uma separação modelovisão Utilize padrões para a conexão entre as camadas Diretrizes Básicas Objetos de camada de apresentação devem estar focados no trabalho de criação de elementos visuais captação de eventos etc Objetos da camada de lógica de negócio ou domínio devem enfocar a lógica da aplicação como por exemplo calcular um total de uma venda etc Mantenha uma separação de interesses Diretrizes Básicas Não conecte ou acople objetos que não são de interface com usuário diretamente a objetos de interface com usuário Por exemplo não faça um objeto Venda ter referência para uma janela ProcessarVenda Não coloque lógica de negócio em métodos de objetos de interface com o usuário Por exemplo não coloque o cálculo do total de uma venda dentro do método de tratamento de evento de clique do botão de uma janela Mantenha uma separação modelovisão Diretrizes Básicas Clientes colaboram com a fachada e não com os componentes internos do subsistema Fachada não deve expor muitas operações de baixo nível Desejável que a fachada exponha um pequeno número de operações de alto nível Fachada normalmente não realiza seu próprio trabalho ela é consolidadora ou mediadora dos objetos subjacentes que realizam o trabalho Utilize padrões para a conexão entre as camadas ARQUITETURA ONION Arquitetura Onion httpsjeffreypalermocom200807theonionarchitecturepart1 ARQUITETURA HEXAGONAL Arquitetura Hexagonal httpsalistaircockburnushexagonalarchitecture ARQUITETURA CLEAN Arquitetura Clean httpsblogcleancodercomunclebob20120813thecleanarchitecturehtml PADRÕES DE PROJETO Padrões de Projeto visão geral Erich Gamma Richard Helm Ralph Johnson e John Vlissides GoF publicaram um catálogo de 23 padrões de projeto design patterns de uso geral Design Patterns Elements of Reusable ObjectOriented Software Segundo GoF Um padrão de projeto provê um esquema para o refinamento de subsistemas ou componentes de um sistema de software ou os relacionamentos entre eles Ele descreve uma estrutura comumrecorrente de comunicação entre componentes que solucionam um problema de projeto geral dentro de um contexto particular Em outras palavras padroes de projeto são soluções recorrentes para problemas de projeto de software que se encontram repetidamente nos problemas reais Solucionam problemas de projeto de objetos em geral de relacionamentocomunicação entre objetos buscando soluções elegantes e reusáveis Padrões de Projeto classificação Segundo este catálogo existem dois critérios de classificação básicos de padrões pela sua finalidade ou pelo seu escopo Pelo critério de finalidade que indica o que o padrão faz existem subclassificações como de criação relativo ao processo de criação de objetos Ex factory estrutural relativo a como as classesobjetos são compostos e associados e são utilizados quando o problema corresponde a uma estrutura Ex composite comportamental relativo à forma em que classes e objetos interagem e distribuem responsabilidades e são utilizados quando há alteração de estado entre os objetos de classes diferentes Exstrategy Padrões de Projeto classificação O segundo critério o de escopo que indica sobre o que o padrão é aplicado que pode ser classe indicando relacionamentos entre classes e suas subclasses Estes relacionamentos são obtidos pelo mecanismo de herança em tempo de compilação e portanto refletem relacionamentos estáticos Ex factory objeto indicando relacionamentos entre objetos Estes relacionamentos ocorrem em tempo de execução e podem mudar refletindo relacionamentos dinâmicos Ex decorator Obviamente um padrão pode possuir características que o fariam ser tabulado em mais de uma classificação entretanto os padrões são classificados pela sua característica e aplicação principal COMPLEXIDADE Jornada Usuário