arquitetura de software e atributos de qualidade -...
TRANSCRIPT
1
Arquitetura de Software e Atributosde Qualidade
Jair C Leite
Arquitetura de Software, © 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 deveoferecer
– 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
2
Arquitetura de Software, © Jair C Leite
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.
Arquitetura de Software, © Jair C Leite
Atributos de qualidade
• Desempenho• Disponibilidade• Modificabilidade• Segurança• Testabilidade• Usabilidade
3
Arquitetura de Software, © Jair C Leite
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
Arquitetura de Software, © Jair C Leite
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 odesign arquitetural
4
Arquitetura de Software, © Jair C Leite
Arquitetura e Atributos de Qualidade
• Os atributos de qualidade envolvem aspectosarquiteturais e não arquiteturais
• Os atributos de qualidade devem ser considerados emtodo 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 afetamodificabilidade
– Módulos com alta coesão e baixo acoplamento é um aspectoarquitetural
Arquitetura de Software, © Jair C Leite
Importância da arquitetura para qualidade
• A arquitetura do software é um fator crítico paramuitas das qualidades de um sistema
• Elas deve ser a base para as estratégias edecisões de design da arquitetura
• A arquitetura, por si só, não garante que todosos atributos de qualidade seja atingidos.
• Ela deve ser a fundação que permitirá aqualidade em conjunto com a implementação ea implantação do sistema
5
Arquitetura de Software, © Jair C Leite
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 deestratégia arquitetural.
• Padrões (patterns) estão relacionados comvárias táticas.
Arquitetura de Software, © Jair C Leite
Disponibilidade (tolerância a falhas)
• Atributo relacionado com ocorrências de falhas do sistema e suasconseqüências.
• A indisponibilidade ocorre quando um serviço do sistema não podeser 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
6
Arquitetura de Software, © Jair C Leite
Táticas para “detecção de falhas”
• Detecção da falha– Ping/echo
• Deve existir um componente que envia um outro componente (seupar) 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 quandoocorrer 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.
Arquitetura de Software, © Jair C Leite
Táticas para “recuperação de falhas”
• Preparação e reparo– Redundância Ativa
• Os componentes redundantes trabalham de forma paralelasempre 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 afalha ele é iniciado.
• Ele re-estabelece os estado do componente que falhou combase em informações de ‘checkpoint’ (ver tática para re-introdução).
7
Arquitetura de Software, © Jair C Leite
Táticas para “recuperação de falhas”
• Re-introdução após falhas– Operação sombra
• Antes de reiniciar um componentes que falhou, deve-seexecuta-lo no modo ‘sombra’ por um período até que severifique 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 docomponente, é armazenado periodicamente. Na re-introdução, o sistema é re-iniciado no último checkpointconsistente.
• Utilizado em conjunto com as táticas ‘componente reserva’ e‘processo monitor’.
Arquitetura de Software, © Jair C Leite
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 aindisponibilidade 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 oconjunto é 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 novainstância do processo.
– Este processo é um ‘componente reserva’ e deve ser iniciadocom base em um ‘log’ de ‘checkpoint’.
8
Arquitetura de Software, © Jair C Leite
Estratégia para a disponibilidade
• Para garantir disponibilidade, deve-seestabelecer uma estratégia baseada em umconjunto de táticas
• Uma solução possível é a combinação dasseguintes táticas– Processo monitor
• Para monitorar a falha, ativar o componente reserva e re-introduzir 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.
Arquitetura de Software, © Jair C Leite
Modificabilidade
• Diminuir tempo e custo para implementar,testar e implantar mudanças
• As táticas para modificabilidade podem teros seguintes objetivos:– Manter modificações localizadas– Evitar propagação (efeito ripple)– Prorrogar tempo de ligação (binding)
9
Arquitetura de Software, © Jair C Leite
Táticas para “manter modificaçõeslocalizadas” • 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, colocarserviç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 sermodificadas?”
• 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çasna 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.
Arquitetura de Software, © Jair C Leite
Táticas para “evitar propagação” (efeitoripple)• Efeito ripple
– é a necessidade de fazer mudanças em todasas unidades que tenham sido afetadas pelamudanç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.
10
Arquitetura de Software, © Jair C Leite
Tipos de dependência – 1
• 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) porB
• Semântica– Para B executar corretamente– A semântica dos dados e serviços produzidos por A e
consumidos por B devem ser consistentes
Arquitetura de Software, © Jair C Leite
Tipos de dependência – 2
• Seqüência– Se B consome dados em seqüência (seguindo um
protocolo), A deve produzir os dados de acordo aseqüência esperada (mesmo protocolo)
– Para B executar corretamente, A deve ter sidoexecutado e terminado dentro de um limite de tempodefinido
• Qualidade dos serviços ou dados– Para B executar corretamente, a qualidades dos
serviços ou dados deve ser consistente com oesperado por B.
11
Arquitetura de Software, © Jair C Leite
Tipos de dependência – 3
• Identidade da interface de A– Para B compilar e executar corretamente, a
identidade (nome e argumentos) de A deve serconsistente 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 dadosde A deve existir no sistema (disponibilidade)
Arquitetura de Software, © Jair C Leite
Táticas para “evitar propagação” – 1
• 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
12
Arquitetura de Software, © Jair C Leite
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
Arquitetura de Software, © Jair C Leite
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 consumidoresde dados
– O padrão Observer também funciona com intermediário dedados
– Os padrões Facade, Mediator, Proxy, Bridge, Strategy e Factorytodos oferecem intermediários que abstraem a sintaxe dosserviços oferecidos.
– O padrão Broker é um intermediário que pode ser usado quandoexiste dependência de identidade e localização
– O padrão Factory permite criar instâncias ncessárias de umobjeto e podem resolver dependência de existência
13
Arquitetura de Software, © Jair C Leite
Táticas para “prorrogar tempo de ligação”-1
• 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 necessitamestar disponível devem ser feitas com tempode ligação prorrogado
Arquitetura de Software, © Jair C Leite
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
14
Arquitetura de Software, © Jair C Leite
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)
Arquitetura de Software, © Jair C Leite
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 dequalidade (QoS) podem ser melhorados
– Contudo, sincronização e compartilhamento de recursos sãoproblemas 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.
15
Arquitetura de Software, © Jair C Leite
Padrão Active Object: solução
• É preciso desacoplar a chamada do método da suaexecução no objeto servidor.
• A chamada do método pode ficar na mesma thread docliente, mas a execução do método deve ficar numathread 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.
Arquitetura de Software, © Jair C Leite
Padrão Active Object: estrutura
Cliente Proxy
método1()...métodoN()
Servant
método1()...métodoN()
Future
Scheduler
dispatch()insert()
Lista Ativação
insert()remove()
MethodRequest
can_run()call()
<<executa>>
<<escreve em>>
<<instancia>>
<<chamada>>
<<instancia>>
1 1 1 1
16
Arquitetura de Software, © Jair C Leite
Padrão Active Object: comportamento
:Cliente :Proxy :Scheduler :Lista Ativ :Servant
:Future :MethodRequest
method()
insert() insert()
dispatch() can_run()
remove()
method()call()
read()
write()
future
future
method
Estudo de caso: e-commerce
17
Arquitetura de Software, © Jair C Leite
Características
• Tipo de comércio que está sendo cadavez mais popular.
• Inovação dos negócios que resultou numgrande sucesso da WEB.
• Inovação que trouxe mudanças naarquitetura refletida pelos novosrequisitos do comércio virtual.
Arquitetura de Software, © Jair C Leite
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 quedesejarem.
• 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 deidentificaçã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
18
Arquitetura de Software, © Jair C Leite
Arquitetura de referência para sistema e-commerce
• Arquitetura de camadas, no caso 3 camadas, cada umacom sua função bem definida.
• Função da interação do usuário é cumprida pelo WEBBrowser.
• Funções da regra de negócio e das aplicaçõescumpridas pelos servidores de aplicação e de transação
• Funções dos serviços de dados cumpridas porservidores de banco de dados (SGBD)
Interação do usuário Regras de negócio e aplicações Serviços de dados
Arquitetura de Software, © Jair C Leite
Arquitetura do sistema e-commerce
• Componentes de cada camada são responsáveis emcontribuir para um/alguns dos atributos de qualidade.
Interação do usuário
Browser 1..*
Regras de negócio e Aplicações
BalanceadorDe Carga
ServidorWEB
ServidorDe Aplicação
ServidorProxy
Roteador/Firewall
1..*
1
1..*
1
11
11
1 1
Serviços de dados
ServidorDe BD
1..*
19
Arquitetura de Software, © Jair C Leite
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.
Interação do usuário
Browser 1..*
Regras de negócio e Aplicações
BalanceadorDe Carga
ServidorWEB
ServidorDe Aplicação
ServidorProxy
Roteador/Firewall
1..*
1
1..*
1
11
11
1 1
Serviços de dados
ServidorDe BD
1..*
Arquitetura de Software, © Jair C Leite
Servidores Proxy para Desempenho
• Servidores Proxy mantêm no seu cache arquivosdisponíveis em servidores remotos, diminuindo o tempode acesso e aumentando o desempenho.
Interação do usuário
Browser 1..*
Regras de negócio e Aplicações
BalanceadorDe Carga
ServidorWEB
ServidorDe Aplicação
ServidorProxy
Roteador/Firewall
1..*
1
1..*
1
11
11
1 1
Serviços de dados
ServidorDe BD
1..*
20
Arquitetura de Software, © Jair C Leite
Roteadores e Firewall para Segurança
• Requisições de um browser (ou servidor proxy) chegam ao roteadorque provê comunicação entre os computadores.
• Roteadores incluindo Firewall para prevenir fluxos de informaçõesnão autorizadas.
Interação do usuário
Browser 1..*
Regras de negócio e Aplicações
BalanceadorDe Carga
ServidorWEB
ServidorDe Aplicação
ServidorProxy
Roteador/Firewall
1..*
1
1..*
1
11
11
1 1
Serviços de dados
ServidorDe BD
1..*
Arquitetura de Software, © Jair C Leite
Balanceador de Carga para Desempenho, Escalabilidadee Disponibilidade
• Parte essencial de qualquer WEB site e-commerce.• Distribui a carga entre os vários computadores rodando
servidores WEB.
Interação do usuário
Browser 1..*
Regras de negócio e Aplicações
BalanceadorDe Carga
ServidorWEB
ServidorDe Aplicação
ServidorProxy
Roteador/Firewall
1..*
1
1..*
1
11
11
1 1
Serviços de dados
ServidorDe BD
1..*
21
Arquitetura de Software, © Jair C Leite
Servidores WEB para Desempenho
• A requisição HTTPS chega então ao servidor WEB.• Servidores multi-thread permitem executar várias tarefas
ao mesmo tempo.
Interação do usuário
Browser 1..*
Regras de negócio e Aplicações
BalanceadorDe Carga
ServidorWEB
ServidorDe Aplicação
ServidorProxy
Roteador/Firewall
1..*
1
1..*
1
11
11
1 1
Serviços de dados
ServidorDe BD
1..*
Arquitetura de Software, © Jair C Leite
Servidores de Aplicação para Modificabilidade,Desempenho e Escalabilidade
• Requisição é então direcionada do servidor WEB para o servidor deaplicação.
• Objetivo é disponibilizar uma plataforma, que abstrai dodesenvolvedor de software complexidades do sistemacomputacional.
Interação do usuário
Browser 1..*
Regras de negócio e Aplicações
BalanceadorDe Carga
ServidorWEB
ServidorDe Aplicação
ServidorProxy
Roteador/Firewall
1..*
1
1..*
1
11
11
1 1
Serviços de dados
ServidorDe BD
1..*
22
Arquitetura de Software, © Jair C Leite
Servidor de Banco de Dados para Modificabilidade,Desempenho e Escalabilidade
• Modernos BD usam replicação interna para conseguiperformance, escalabilidade e disponibilidade. Elestambém usam cache para garantir bom desempenho.
Interação do usuário
Browser 1..*
Regras de negócio e Aplicações
BalanceadorDe Carga
ServidorWEB
ServidorDe Aplicação
ServidorProxy
Roteador/Firewall
1..*
1
1..*
1
11
11
1 1
Serviços de dados
ServidorDe BD
1..*
Arquitetura de Software, © Jair C Leite
Resumo de como a arquitetura dos sistema e-commercerealizam seus objetivos de qualidade
Quem realizaObjetivo de qualidade
Browser, banco de dadosModificabilidade
FirewallSegurança
Balanceador de CargaEscalabilidade
Banco de dados, Balanceadores deCarga
Alta disponibilidade
Balanceador de carga, servidoresproxy
Bom desempenho