arquitetura de software e atributos de qualidade -...

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


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

3


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 odesign arquitetural

4


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


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


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.


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


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.


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


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’.


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


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.


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


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.


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


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



• 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



• 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)


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



• 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



• 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


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


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


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 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


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.


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


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


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.


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 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 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


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.


Browser 1..*


BalanceadorDe Carga

ServidorWEB


ServidorProxy

Roteador/Firewall

1..*

1

1..*

1

11

11

1 1

Serviços de dados

ServidorDe BD

1..*


Servidores Proxy para Desempenho

• Servidores Proxy mantêm no seu cache arquivosdisponíveis em servidores remotos, diminuindo o tempode acesso e aumentando o desempenho.


Browser 1..*


BalanceadorDe Carga

ServidorWEB


ServidorProxy

Roteador/Firewall

1..*

1

1..*

1

11

11

1 1

Serviços de dados

ServidorDe BD

1..*

20


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.


Browser 1..*


BalanceadorDe Carga

ServidorWEB


ServidorProxy

Roteador/Firewall

1..*

1

1..*

1

11

11

1 1

Serviços de dados

ServidorDe BD

1..*


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.


Browser 1..*


BalanceadorDe Carga

ServidorWEB


ServidorProxy

Roteador/Firewall

1..*

1

1..*

1

11

11

1 1

Serviços de dados

ServidorDe BD

1..*

21


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.


Browser 1..*


BalanceadorDe Carga

ServidorWEB


ServidorProxy

Roteador/Firewall

1..*

1

1..*

1

11

11

1 1

Serviços de dados

ServidorDe BD

1..*


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.


Browser 1..*


BalanceadorDe Carga

ServidorWEB


ServidorProxy

Roteador/Firewall

1..*

1

1..*

1

11

11

1 1

Serviços de dados

ServidorDe BD

1..*

22


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.


Browser 1..*


BalanceadorDe Carga

ServidorWEB


ServidorProxy

Roteador/Firewall

1..*

1

1..*

1

11

11

1 1

Serviços de dados

ServidorDe BD

1..*


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

23


Referência

• Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, 2nded. Reading, MA: Addison-Wesley, 2003.

arquitetura de software e atributos de qualidade -...

Documents