Arquitetura de Software e Atributos de Qualidade Jair C Leite Requisitos e atributos de qualidade Requisitos Características, atributos, propriedades e restrições associadas ao software. Requisitos funcionais Definem os serviços (ou funções) que o sistema deve oferecer Definem a funcionalidade Requisitos não-funcionais Definem outras propriedades e restrições do sistema. Afetam o sistema como um todo e deve São chamados também de atributos de qualidade
Outros termos utilizados Requisitos de domínio (ou de negócios) Vêm do domínio de aplicação do sistema Requisitos de usuário Versão em linguagem natural para ser lida pelos gerentes, usuários, etc. Requisitos de sistema Versão detalhada de interesse dos arquitetos, engenheiros e programadores. Atributos de qualidade Desempenho Disponibilidade Modificabilidade Segurança Testabilidade Usabilidade 2
Funcionalidade e atributos de qualidade São ortogonais Atributos de qualidade podem afetar vários serviços ou funções Atributos de qualidade devem ser independentes da funcionalidade A funcionalidade não deve ser modificada por atributos de qualidade Exceto quando analisado e decidido pelos envolvidos Funcionalidade e Arquitetura Funcionalidade É realizada por um conjunto de elementos do software, definidos no design arquitetural Decomposição funcional é uma técnica de design arquitetural mas não deve ser a única. Atributos de qualidade também afetam o design arquitetural 3
Arquitetura e Atributos de Qualidade Os atributos de qualidade envolvem aspectos arquiteturais e não arquiteturais Os atributos de qualidade devem ser considerados em todo o processo de software Design, implementação e implantação. Usabilidade - exemplos Escolhas dos objetos de interface e layout de telas são aspectos não-arquiteturais Os mecanismos de undo e feedback, dependem de decisões arquiteturais Modificabilidade - exemplos Estilo do código é um aspecto não-arquitetural que afeta modificabilidade Módulos com alta coesão e baixo acoplamento é um aspecto arquitetural Importância da arquitetura para qualidade A arquitetura do software é um fator crítico para muitas das qualidades de um sistema Elas deve ser a base para as estratégias e decisões de design da arquitetura A arquitetura, por si só, não garante que todos os atributos de qualidade seja atingidos. Ela deve ser a fundação que permitirá a qualidade em conjunto com a implementação e a implantação do sistema 4
Atingindo atributos de qualidade O design consiste de um conjunto de decisões. Os fundamentos para atingir qualidade podem ser estabelecidos por decisões de design. No método ADD, estas decisões de design são chamadas de táticas. Ex.: Redundância é uma tática para Disponibilidade Uma coleção de táticas é chamada de estratégia arquitetural. Padrões (patterns) estão relacionados com várias táticas. Disponibilidade (tolerância a falhas) Atributo relacionado com ocorrências de falhas do sistema e suas conseqüências. A indisponibilidade ocorre quando um serviço do sistema não pode ser realizado e afeta o uso do sistema. É causada por falhas É necessário que a falha seja mascarada ou um reparo seja feito. As táticas para garantir disponibilidade são baseadas em : Redundância de componentes (processos, arquivos, equipamentos, etc.) Monitoramento para prevenir falhas Mecanismos de detecção de falhas a ocorrer ou ocorridas Mecanismos de recuperação de falhas ocorridas As táticas devem considerar os seguintes fafores: Freqüência das falhas Conseqüências das falhas Tempo para recuperação 5
Táticas para detecção de falhas Detecção da falha Ping/echo Deve existir um componente que envia um outro componente (seu par) obter uma resposta de um outro componente Heartbeat Periodicamente um componente emite uma mensagem para um outro componente Exceções Criar um responsável para executar um as atividades quando ocorrer a falha Considerações Nas táticas ping/echo e no heartbeat, são necessários dois processos em execução. Na tática exceções, é possível implementa-la em um único processo ou thread. Táticas para recuperação de falhas Preparação e reparo Redundância Ativa Os componentes redundantes trabalham de forma paralela sempre respondendo aos mesmos eventos. Redundância Passiva Existem dois componentes redundantes: primário e secundário. Apenas o primário responde a eventos e sinaliza ao secundário que deve atualizar seus estados. Componente reserva O componente redundante fica em espera e quando ocorre a falha ele é iniciado. Ele re-estabelece os estado do componente que falhou com base em informações de checkpoint (ver tática para reintrodução). 6
Táticas para recuperação de falhas Re-introdução após falhas Operação sombra Antes de reiniciar um componentes que falhou, deve-se executa-lo no modo sombra por um período até que se verifique que seja completamente confiável Re-sincronização de estados Quando se usa redundância ativa ou passiva, precisa ser restaurado e re-sincronizado com o componente redundante. Checkpoint Um ponto de execução, com um estado consistente do componente, é armazenado periodicamente. Na reintrodução, o sistema é re-iniciado no último checkpoint consistente. Utilizado em conjunto com as táticas componente reserva e processo monitor. Táticas para prevenção de falhas Remoção do serviço Quando se detecta que um componente irá falha, este componente deve ser removido do sistema para prevenir a indisponibilidade total do sistema. Mecanismos de transação Um conjunto de ações críticas que podem colocar o sistema num estado de falha devem ser realizadas de forma atômica uma transação. Dessa forma, se ocorrer falha durante uma das ações, todo o conjunto é cancelado e o sistema volta para o estado anterior à transação. Processo monitor Quando uma falha num processo foi detectada, o processo monitor pode matar o processo com falha e criar uma nova instância do processo. Este processo é um componente reserva e deve ser iniciado com base em um log de checkpoint. 7
Estratégia para a disponibilidade Para garantir disponibilidade, deve-se estabelecer uma estratégia baseada em um conjunto de táticas Uma solução possível é a combinação das seguintes táticas Processo monitor Para monitorar a falha, ativar o componente reserva e reintroduzir o sistema utilizando o checkpoint. Heartbeat Para enviar mensagens periódicas aos componentes e criar o checkpoint em cada checagem. Checkpoint Para utilizar informações de log para re-introduzir o sistema. Componente reserva Para ser utilizando quando ocorrer a falhar. Modificabilidade Diminuir tempo e custo para implementar, testar e implantar mudanças As táticas para modificabilidade podem ter os seguintes objetivos: Manter modificações localizadas Evitar propagação (efeito ripple) Prorrogar tempo de ligação (binding) 8
Táticas para manter modificações localizadas Manter coerência semântica A unidades do código devem ter responsabilidades semelhantes, isto é, realizar atividades que sejam semanticamente similares Abstrair serviços comuns é um sub-tática associada. Ou seja, colocar serviços comuns a várias outras unidades numa mesma unidade Coerência e coesão são métricas associadas Antecipar as mudanças esperadas Ao definir as unidades de código, o arquiteto deve se questionar se Para cada mudança esperada, quantas unidades devem ser modificadas? Generalizar os módulos Tornar um módulo o mais genérico possível, computando um maior número de funcionalidades Módulos com esta características têm interfaces complexas. No entanto, as mudanças internas quase sempre limitam-se a mudanças na interfaces. Limitar o número de opções Quando se constrói unidades de código com poucas possibilidades de mudanças, limita-se o número de mudanças que podem ser feitas. Táticas para evitar propagação (efeito ripple) Efeito ripple é a necessidade de fazer mudanças em todas as unidades que tenham sido afetadas pela mudança em uma unidade. Dependência entre unidades Considere duas unidades A e B, com B dependendo de A. Existem diferentes tipos de dependências entre A e B As táticas devem considerar os tipo de dependência. 9
Tipos de dependência Sintática Para B compilar ou executar corretamente... Dados: Os dados produzidos por A devem ser consistentes com os tipos consumidos por B Serviço: A assinatura dos serviços (métodos ou funções) oferecidos por A e utilizados (chamados) por B Semântica Para B executar corretamente A semântica dos dados e serviços produzidos por A e consumidos por B devem ser consistentes Tipos de dependência 2 Seqüência Se B consome dados em seqüência (seguindo um protocolo), A deve produzir os dados de acordo a seqüência esperada (mesmo protocolo) Para B executar corretamente, A deve ter sido executado e terminado dentro de um limite de tempo definido Qualidade dos serviços ou dados Para B executar corretamente, a qualidades dos serviços ou dados deve ser consistente com o esperado por B. 0
Tipos de dependência 3 Identidade da interface de A Para B compilar e executar corretamente, a identidade (nome e argumentos) de A deve ser consistente com o esperado por B. Localização de A Para B executar corretamente, a localização de A em tempo de execução deve ser conhecida Existência Para B executar corretamente, os serviços ou dados de A deve existir no sistema (disponibilidade) Táticas para evitar propagação Esconder informação Na decomposição de sistemas em unidades, dados e serviços podem ficar públicas e ou privadas Informações privadas não têm relação de dependência sintática com outras unidades. Não resolve dependência semântica Manter interfaces existentes Separar interface da implementação, criando interfaces abstratas, que mascaram as mudanças. Adicionar novas interfaces Adicionar um adaptador (Adapter) Prover um stub
Táticas para evitar propagação 2 Restringir os caminhos de comunicação Deve-se restringir o número de módulos que consomem dados produzidos por um módulo...e o número de módulos que produzem os dados consumidos por ele Táticas para evitar propagação 3 Uso de intermediário Para os casos que não existem dependência semântica entre A e B, pode-se inserir um intermediário entre A e B O padrão arquitetura Repositórios (Blackboard) funciona como intermediários entre os processos produtores e consumidores de dados O padrão Observer também funciona com intermediário de dados Os padrões Facade, Mediator, Proxy, Bridge, Strategy e Factory todos oferecem intermediários que abstraem a sintaxe dos serviços oferecidos. O padrão Broker é um intermediário que pode ser usado quando existe dependência de identidade e localização O padrão Factory permite criar instâncias ncessárias de um objeto e podem resolver dependência de existência 2
Táticas para prorrogar tempo de ligação - Motivação A ligação entre as unidades pode ocorrer: Em tempo de carga (ao iniciar) Em tempo de execução Modificações em sistemas que necessitam estar disponível devem ser feitas com tempo de ligação prorrogado Táticas para prorrogar tempo de ligação -2 Arquivos de configuração Permitem definir parâmetro de execução para ser usados em tempo de carga Registro em tempo de execução Um gerenciador de registros permite suporte a plug-and-play O padrão Observer (publish/subscribe) pode ser utilizado Polimorfismo Permite ligação de chamadas de métodos em tempo de execução Troca de componentes Componentes podem ser modificados em tempo de carga Aderência a protocolos Processos que se comunicam utilizando protocolos definidos, podem ser ligados em tempo de execução 3
Padrões de Projeto e Táticas Padrões de projeto podem implementar várias táticas Por exemplo, o padrão Active Object (objeto ativo) Objetivo melhorar desempenho (atributo de qualidade) em sistemas distribuídos Tática: Introduzir concorrência Além disso, o padrão Active Object envolve outras táticas, para diferentes atributos de qualidade Desempenho Política de escalonamento Modificabilidade Escondendo informação Intermediário Tempo de ligação (binding) Padrão Active Object: contexto e problema Contexto Sistemas com clientes que acessam objetos executando em threads separadas (concorrente) Problema Quando o objeto roda de forma concorrente vários atributos de qualidade (QoS) podem ser melhorados Contudo, sincronização e compartilhamento de recursos são problemas críticos Forças Método do objeto concorrente não deve bloquear o processo indefinidamente O controle do acesso compartilhado (sincronização) dever programado facilmente O design arquitetural deve usufruir do paralelismo oferecido pela concorrência de forma transparente. 4
Padrão Active Object: solução É preciso desacoplar a chamada do método da sua execução no objeto servidor. A chamada do método pode ficar na mesma thread do cliente, mas a execução do método deve ficar numa thread separada. Para isso... Um Proxy deve representar a chamada do método. Ele roda da mesma thread do cliente. Um Servant fica responsável pela execução do método. Ele roda numa thread separada Durante a execução, o Proxy deve transformar a chamada do método em uma requisição (MethodRequest). A requisição é enviada para um Scheduler que é colocada numa lista de ativações. O Scheduler se encarrega de chamar o método no Servant. Eles rodam na mesma thread. Padrão Active Object: estrutura Cliente Proxy Scheduler Lista Ativação <<chamada>> método()... métodon() dispatch() insert() insert() remove() Future <<instancia>> <<instancia>> MethodRequest can_run() call() <<executa>> Servant método()... métodon() <<escreve em>> 5
Padrão Active Object: comportamento :Cliente :Proxy :Scheduler :Lista Ativ :Servant method() method :Future insert() future insert() :Method Request dispatch() can_run() future remove() write() call() method() read() Estudo de caso: e-commerce 6
Características Tipo de comércio que está sendo cada vez mais popular. Inovação dos negócios que resultou num grande sucesso da WEB. Inovação que trouxe mudanças na arquitetura refletida pelos novos requisitos do comércio virtual. Requisitos exigidos pelos e-commerce Bom desempenho usuários desejam sempre uma resposta a suas requisições num baixo intervalo de tempo. Alta disponibilidade é desejado que os sistemas sempre estejam ligados e funcionando, para que os usuários possam utilizar os serviços sempre que desejarem. Escalabilidade sistema deve ser capaz de expandir a quantidade de dados que ele pode controlar. Segurança sistema deve garantir que informações sensíveis (número de identificação, número cartão de crédito) estejam livres de espionagem. Modificabilidade sites e-commerce mudam frequentemente, portanto seu conteúdo deve ser simples de mudar 7
Arquitetura de referência para sistema e- commerce Interação do usuário Regras de negócio e aplicações Serviços de dados Arquitetura de camadas, no caso 3 camadas, cada uma com sua função bem definida. Função da interação do usuário é cumprida pelo WEB Browser. Funções da regra de negócio e das aplicações cumpridas pelos servidores de aplicação e de transação Funções dos serviços de dados cumpridas por servidores de banco de dados (SGBD) Arquitetura do sistema e-commerce Componentes de cada camada são responsáveis em contribuir para um/alguns dos atributos de qualidade. Regras de negócio e Aplicações Balanceador De Carga Interação do usuário Roteador/ Firewall..* WEB..* Serviços de dados Browser..* Proxy De Aplicação..* De BD 8
WEB Browser para Modificabilidade Início da interação pelo Browser. Interfaces que suportam browser são implementadas em HTML. Documentos HTML são facilmente modificados. Regras de negócio e Aplicações Balanceador De Carga Interação do usuário Roteador/ Firewall..* WEB..* Serviços de dados Browser..* Proxy De Aplicação..* De BD es Proxy para Desempenho es Proxy mantêm no seu cache arquivos disponíveis em servidores remotos, diminuindo o tempo de acesso e aumentando o desempenho. Regras de negócio e Aplicações Balanceador De Carga Interação do usuário Roteador/ Firewall..* WEB..* Serviços de dados Browser..* Proxy De Aplicação..* De BD 9
Roteadores e Firewall para Segurança Requisições de um browser (ou servidor proxy) chegam ao roteador que provê comunicação entre os computadores. Roteadores incluindo Firewall para prevenir fluxos de informações não autorizadas. Regras de negócio e Aplicações Balanceador De Carga Interação do usuário Roteador/ Firewall..* WEB..* Serviços de dados Browser..* Proxy De Aplicação..* De BD Balanceador de Carga para Desempenho, Escalabilidade e Disponibilidade Parte essencial de qualquer WEB site e-commerce. Distribui a carga entre os vários computadores rodando servidores WEB. Regras de negócio e Aplicações Balanceador De Carga Interação do usuário Roteador/ Firewall..* WEB..* Serviços de dados Browser..* Proxy De Aplicação..* De BD 20
es WEB para Desempenho A requisição HTTPS chega então ao servidor WEB. es multi-thread permitem executar várias tarefas ao mesmo tempo. Regras de negócio e Aplicações Balanceador De Carga Interação do usuário Roteador/ Firewall..* WEB..* Serviços de dados Browser..* Proxy De Aplicação..* De BD es de Aplicação para Modificabilidade, Desempenho e Escalabilidade Requisição é então direcionada do servidor WEB para o servidor de aplicação. Objetivo é disponibilizar uma plataforma, que abstrai do desenvolvedor de software complexidades do sistema computacional. Regras de negócio e Aplicações Balanceador De Carga Interação do usuário Roteador/ Firewall..* WEB..* Serviços de dados Browser..* Proxy De Aplicação..* De BD 2
de Banco de Dados para Modificabilidade, Desempenho e Escalabilidade Modernos BD usam replicação interna para consegui performance, escalabilidade e disponibilidade. Eles também usam cache para garantir bom desempenho. Regras de negócio e Aplicações Balanceador De Carga Interação do usuário Roteador/ Firewall..* WEB..* Serviços de dados Browser..* Proxy De Aplicação..* De BD Resumo de como a arquitetura dos sistema e-commerce realizam seus objetivos de qualidade Objetivo de qualidade Bom desempenho Alta disponibilidade Escalabilidade Segurança Modificabilidade Quem realiza Balanceador de carga, servidores proxy Banco de dados, Balanceadores de Carga Balanceador de Carga Firewall Browser, banco de dados 22
Referência Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, 2nd ed. Reading, MA: Addison-Wesley, 2003. 23