Escolar Documentos
Profissional Documentos
Cultura Documentos
de Qualidade
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
Arquitetura de Software, © Jair C Leite
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.
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.
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’.
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.
Arquitetura de Software, © Jair C Leite
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.
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
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.
10
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)
11
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
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
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)
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.
<<escreve em>>
15
Padrão Active Object: comportamento
dispatch() can_run()
future
remove()
call()
method()
write()
read()
16
Características
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
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
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
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
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
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
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
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
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
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
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
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
Segurança Firewall
22
Referência
• Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, 2nd
ed. Reading, MA: Addison-Wesley, 2003.
23