Atributos Arquitetura 2 PP

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
Arquitetura de Software, © Jair C Leite
1
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 re-
introduçã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 re-
introduçã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 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 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 – 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) 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
• 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.
10
• 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” – 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
11
• 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 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
12
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 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
13
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.
14
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

1 1 1 1
Cliente Proxy Scheduler Lista Ativação
método1() dispatch() insert()

<<chamada>>
... insert() remove()
métodoN()
<<instancia>>
<<instancia>>
Future
Servant
MethodRequest
método1()
can_run() ...
<<executa>>
call() métodoN()
<<escreve em>>
15
Padrão Active Object: comportamento
:Cliente :Proxy :Scheduler :Lista Ativ :Servant

method()
:Future
future :Method
Request
method insert() insert()
dispatch() can_run()
future
remove()
call()
method()
write()
read()
Estudo de caso: e-commerce
16
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
17
Arquitetura de referência para sistema e-
commerce
Regras de negócio
Interação do usuário Serviços de dados
e aplicações
• 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 1
De Carga
1 1..*
1
Servidor
Roteador/ WEB
Interação do usuário Firewall
1 Serviços de dados
1
1 1..*
Servidor
1..* 1 Servidor Servidor 1 1..*
Browser De BD
Proxy De Aplicação
18
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.
Balanceador 1
De Carga
1 1..*
1
Servidor
Roteador/ WEB
1
1 1..*
Servidor
Browser De BD
Servidores Proxy para Desempenho
• Servidores Proxy mantêm no seu cache arquivos

disponíveis em servidores remotos, diminuindo o tempo
de acesso e aumentando o desempenho.
Balanceador 1
De Carga
1 1..*
1
Servidor
Roteador/ WEB
1
1 1..*
Servidor
Browser De BD
19
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.
Balanceador 1
De Carga
1 1..*
1
Servidor
Roteador/ WEB
1
1 1..*
Servidor
Browser 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.
Balanceador 1
De Carga
1 1..*
1
Servidor
Roteador/ WEB
1
1 1..*
Servidor
Browser De BD
20
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.
Balanceador 1
De Carga
1 1..*
1
Servidor
Roteador/ WEB
1
1 1..*
Servidor
Browser De BD
Servidores 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.
Balanceador 1
De Carga
1 1..*
1
Servidor
Roteador/ WEB
1
1 1..*
Servidor
Browser De BD
21
Servidor 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.
Balanceador 1
De Carga
1 1..*
1
Servidor
Roteador/ WEB
1
1 1..*
Servidor
Browser De BD
Resumo de como a arquitetura dos sistema e-commerce

realizam seus objetivos de qualidade
Objetivo de qualidade Quem realiza

Bom desempenho Balanceador de carga, servidores
proxy
Alta disponibilidade Banco de dados, Balanceadores de
Carga
Escalabilidade Balanceador de Carga
Segurança Firewall
Modificabilidade 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

Atributos Arquitetura 2 PP

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Atributos Arquitetura 2 PP

Transféré par

Droits d'auteur :

Formats disponibles

Arquitetura de Software e Atributos

Requisitos e atributos de qualidade

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Importância da arquitetura para qualidade

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Disponibilidade (tolerância a falhas)

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Táticas para “recuperação de falhas”

Arquitetura de Software, © Jair C Leite

Táticas para “prevenção de falhas”

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Táticas para “evitar propagação” (efeito

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Táticas para “evitar propagação” – 1

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Táticas para “evitar propagação” – 3

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Táticas para “prorrogar tempo de ligação”-2

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Padrão Active Object: contexto e problema

Arquitetura de Software, © Jair C Leite

Arquitetura de Software, © Jair C Leite

Padrão Active Object: estrutura

método1() dispatch() insert()

Arquitetura de Software, © Jair C Leite

:Cliente :Proxy :Scheduler :Lista Ativ :Servant

Arquitetura de Software, © Jair C Leite

Estudo de caso: e-commerce

• Tipo de comércio que está sendo cada

Arquitetura de Software, © Jair C Leite

Requisitos exigidos pelos e-commerce

Arquitetura de Software, © Jair C Leite

• Arquitetura de camadas, no caso 3 camadas, cada uma

Arquitetura do sistema e-commerce

Regras de negócio e Aplicações

Arquitetura de Software, © Jair C Leite

Regras de negócio e Aplicações

Arquitetura de Software, © Jair C Leite

Servidores Proxy para Desempenho

• Servidores Proxy mantêm no seu cache arquivos

Regras de negócio e Aplicações

Arquitetura de Software, © Jair C Leite

Regras de negócio e Aplicações

Arquitetura de Software, © Jair C Leite

Balanceador de Carga para Desempenho, Escalabilidade

Regras de negócio e Aplicações

Arquitetura de Software, © Jair C Leite

Regras de negócio e Aplicações

Arquitetura de Software, © Jair C Leite

Servidores de Aplicação para Modificabilidade,