Arquitetura de Software I
Hyggo Oliveira de Almeida
Laboratório de Sistemas Embarcados e Computação Pervasiva
Centro de Engenharia Elétrica e Informática
Universidade Federal de Campina Grande
2
Módulo I
Relembrando...






O que é arquitetura de software?
Motivação e benefícios
Conceitos
Visões arquiteturais
Descrevendo arquiteturas com UML
Estilos arquiteturais
Pós-Engenharia de Software - FAT
2
Módulo II
Estilos e padrões arquiteturais
Atributos de qualidade
Seleção de estilos
Seleção de visões
Rastreabilidade bidirecional
2
Estilos e padrões arquiteturais

Estilos arquiteturais


Definem meios de selecionar e apresentar blocos de
construção de arquitetura (Shaw)
Padrões arquiteturais

Projetos de alto nível, testados e validados, de blocos de
construção de arquitetura (Buschman).
Pós-Engenharia de Software - FAT
4
Estilos e padrões arquiteturais
Classificação
Invocação/Retorno (Call/Return)
Programa principal/Subrotina (Main Program/Subroutine)
Invocação remota de procedimento (Remote Procedure Call - RPC)
Camadas (Layered)
Componentes independentes (Independent Components)
Comunicação de processos (Communicating Processes)
Baseado em eventos
Máquina virtual (Virtual Machine)
Interpretador (Interpreter)
Baseado em regras (Rule-based)
Centrado em dados (Data-Centered)
Repositório (Repository)
Quadro negro (Blackboard)
Fluxo de dados (Data-Flow)
Seqüencial (Batch Sequential)
Tubos e filtros (Pipe and Filter)
Pós-Engenharia de Software - FAT
5
Estilos e padrões arquiteturais
Invocação/Retorno (Call/Return)

Programa principal/Subrotina (Main Program/Subroutine)
Programa principal
Subrotina 1
Subrotina 2
Pós-Engenharia de Software - FAT
Subrotina 3
6
Estilos e padrões arquiteturais
Invocação/Retorno (Call/Return)

Programa principal/Subrotina (Main Program/Subroutine)

Objetivos
Programa principal
Subrotina 1
Subrotina 2
Subrotina 3
Reúso
Pós-Engenharia de Software - FAT
7
Estilos e padrões arquiteturais
Invocação/Retorno (Call/Return)

Programa principal/Subrotina (Main Program/Subroutine)

Objetivos
Programa principal
Subrotina 1
Subrotina 2
Subrotina 3
Desenvolvimento
independente
Pós-Engenharia de Software - FAT
8
Estilos e padrões arquiteturais
Invocação/Retorno (Call/Return)

Invocação remota de procedimento (RPC)
Programa principal
Subrotina 1
Subrotina 2
Subrotina 3
192.168.10.8
192.168.10.11
Pós-Engenharia de Software - FAT
9
Estilos e padrões arquiteturais
Invocação/Retorno (Call/Return)

Invocação remota de procedimento (RPC)
Programa principal
Subrotina 1
Subrotina 2
Subrotina 3
Ganho de
desempenho
(2 processadores)
192.168.10.8
192.168.10.11
Pós-Engenharia de Software - FAT
10
Estilos e padrões arquiteturais
Invocação/Retorno (Call/Return)

Camadas (Layered)
Aplicação
Apresentação
Apresentação
Sessão
Negócio
ISO-OSI
Transporte
Clássica
3 camadas
Armazenamento
Rede
Dados
Física
Pós-Engenharia de Software - FAT
11
Estilos e padrões arquiteturais
Invocação/Retorno (Call/Return)

Camadas (Layered)

Camadas se comunicam apenas com outras adjacentes
Apresentação
Negócio
Armazenamento
Pós-Engenharia de Software - FAT
12
Estilos e padrões arquiteturais
Invocação/Retorno (Call/Return)

Camadas (Layered)

Alterações locais não são propagadas
Apresentação
Negócio
Armazenamento
Pós-Engenharia de Software - FAT
13
Estilos e padrões arquiteturais
Componentes independentes

Comunicação de processos (Communicating Processes)

Baseado na comunicação via troca de mensagens entre
processos



Em geral, via rede
Cliente - Servidor
Ponto a ponto (Peer to Peer – P2P)
Pós-Engenharia de Software - FAT
14
Estilos e padrões arquiteturais
Componentes independentes

Comunicação de processos (Communicating Processes)

Cliente – Servidor

Já vimos anteriormente
Servidor
Aplicação: Internet
Clientes
Pós-Engenharia de Software - FAT
15
Estilos e padrões arquiteturais
Componentes independentes

Comunicação de processos (Communicating Processes)

Cliente – Servidor

Problema: servidor é ponto de falha!
Servidor
Clientes
Pós-Engenharia de Software - FAT
16
Estilos e padrões arquiteturais
Componentes independentes

Comunicação de processos (Communicating Processes)

Ponto a Ponto (P2P)



Não há distinção entre nós
Cada nó mantém seus próprios dados e endereços conhecidos
Cada nó é “cliente e servidor ao mesmo tempo”
Pós-Engenharia de Software - FAT
17
Estilos e padrões arquiteturais
Componentes independentes

Comunicação de processos (Communicating Processes)

Ponto a Ponto (P2P)




Exemplos de redes P2P: gnutella, freenet
Exemplos de aplicação: Kazaa, eMule
Vantagem: não há ponto de falha
Desvantagem: tempo de consulta
Pós-Engenharia de Software - FAT
18
Estilos e padrões arquiteturais
Componentes independentes

Baseado em eventos




Produtores e consumidores de eventos
Consumidores se registram nos Produtores
Produtores notificam consumidores registrados
Motivação:
imprimir
a.imprimir()
A
B
Pós-Engenharia de Software - FAT
19
Estilos e padrões arquiteturais
Componentes independentes

Baseado em eventos



Produtores e consumidores são independentes
Execução via procedimentos disparados via mudança de estados
Escalabilidade no número de interessados
imprimir()
A
Consumidor
interessado(“relatorioOK”)
relatorioOK
B
Produtor
Relatóri
o OK
Pós-Engenharia de Software - FAT
20
Estilos e padrões arquiteturais
Componentes independentes

Baseado em eventos

Aplicação comum

Interface gráfica
onKeyDown
onMouseOver
onKeyUp
onMouseReleased
onMouseClick
menuDown
onMousePressed
onSelected
Pós-Engenharia de Software - FAT
21
Estilos e padrões arquiteturais
Centrado em dados (Data-centered)

Repositório (Repository)

Integridade, escalabilidade (novos clientes, novos dados)
Cliente 2
Clientes operam
sobre os dados
Cliente 3
Cliente 1
Cliente n
Estado atual
consistente
Dados
compartilhados
Pós-Engenharia de Software - FAT
22
Estilos e padrões arquiteturais
Centrado em dados (Data-centered)

Repositório (Repository)

Exemplo: banco de dados tradicional
Cliente 2
Cliente 3
Cliente 1
Gatilhos
(triggers)
Cliente n
Transações
Dados
compartilhados
Pós-Engenharia de Software - FAT
23
Estilos e padrões arquiteturais
Centrado em dados (Data-centered)

Quadro negro (Blackboard)
Controlador
x
-
Gerência dos dados
Fontes de
conhecimento
+
Pós-Engenharia de Software - FAT
24
Estilos e padrões arquiteturais
Centrado em dados (Data-centered)

Quadro negro (Blackboard)
Sei subtrair!
Sei multiplicar!
2 x (3+2)2 + 3 - 6 = ?
-
x
Controlador
Sei
exponencial!
Sei somar!
+
Pós-Engenharia de Software - FAT
25
Estilos e padrões arquiteturais
Centrado em dados (Data-centered)

Quadro negro (Blackboard)
2 2x x(3+2)
(5)2 2++33- -66==??
-
x
Controlador
+
Pós-Engenharia de Software - FAT
26
Estilos e padrões arquiteturais
Centrado em dados (Data-centered)

Quadro negro (Blackboard)
2 x 25
(5)2++33- -66==??
-
x
Controlador
+
Pós-Engenharia de Software - FAT
27
Estilos e padrões arquiteturais
Centrado em dados (Data-centered)

Quadro negro (Blackboard)
+ 3+- 36 -=6?= ?
250
x 25
-
x
Controlador
+
Pós-Engenharia de Software - FAT
28
Estilos e padrões arquiteturais
Centrado em dados (Data-centered)

Quadro negro (Blackboard)
53 47
-6=?
-
x
Controlador
+
Pós-Engenharia de Software - FAT
29
Estilos e padrões arquiteturais
Centrado em dados (Data-centered)

Quadro negro (Blackboard)
Ap 1
Ap 2
Ap 3
Quadro Negro
Controlador
Ap 4
Ap n
Ap 5
Pós-Engenharia de Software - FAT
30
Estilos e padrões arquiteturais
Centrado em dados (Data-centered)

Quadro negro (Blackboard)




Sistemas complexos
 Resolução Distribuída de Problemas - RDP
Aplicações independentes
 Escalabilidade
Ponto de falha!!!
 Quadro negro
Arquitetura usada no paradigma de agentes
Pós-Engenharia de Software - FAT
31
Estilos e padrões arquiteturais
Máquina virtual (Virtual Machine)

Interpretador (Interpreter)

Simular funcionalidade não nativa para obter portabilidade
entrada
dados
saída
Programa sendo
interpretado
Dados
(Estado do programa)
Atualiza
Mecanismo de
interpretação
Dados de
estado
Instrução selecionada
Dados selecionados
Pós-Engenharia de Software - FAT
Instruções do
programa
Estado interno
(Instruções + dados)
32
Estilos e padrões arquiteturais
Máquina virtual (Virtual Machine)

Interpretador (Interpreter)

Exemplo: Java
public class Oi{
...
}
Máquina
Virtual
Compilador Java
“javac.exe”
Máquina
Virtual
Arquivo “Oi.java”
bytecode
Êþº¾ 1
<init>
()V
Code
LineNumberTable
main
([Ljava/lang/String;)...
INTERPRETA
Arquivo “Oi.class”
Máquina
Virtual
Máquina
Virtual
Máquina
Virtual
Pós-Engenharia de Software - FAT
33
Estilos e padrões arquiteturais
Máquina virtual (Virtual Machine)

Interpretador (Interpreter)

Problema


Algumas pesquisas apontam que algumas das linguagens
interpretadas já conseguem ser mais rápidas que C


Desempenho
Java, por exemplo
Máquina virtual nativa – Intel®
Pós-Engenharia de Software - FAT
34
Estilos e padrões arquiteturais
Máquina virtual (Virtual Machine)

Baseado em regras (Rule-based)



Conjunto de regras sobre um estado
Definição do estado atual com base em dados de entrada
Regras alteram o estado
Memória de
trabalho
entrada
saída
Base de
Regras
Máquina de
inferência
Pós-Engenharia de Software - FAT
35
Estilos e padrões arquiteturais
Máquina virtual (Virtual Machine)

Baseado em regras (Rule-based)

Exemplos: Prolog, Sistemas Especialistas
Memória de trabalho
SE “HORA=21:00”
ENTÃO “AÇÃO=LANCHE”
HORA=18:00
HORA = ?
AÇÃO = ?
SE “HORA=22:00”
ENTÃO “AÇÃO=LIBERAR”
SE “HORA<19:00”
ENTÃO “AÇÃO=ESPERAR”
SE “HORA=19:00”
ENTÃO “AÇÃO=COMEÇAR”
Base de Regras
Máquina de
inferência
Pós-Engenharia de Software - FAT
36
Estilos e padrões arquiteturais
Máquina virtual (Virtual Machine)

Baseado em regras (Rule-based)

Exemplos: Prolog, Sistemas Especialistas
Memória de trabalho
SE “HORA=21:00”
ENTÃO “AÇÃO=LANCHE”
HORA = 18:00
AÇÃO = ?
SE “HORA=22:00”
ENTÃO “AÇÃO=LIBERAR”
SE “HORA<19:00”
ENTÃO “AÇÃO=ESPERAR”
SE “HORA=19:00”
ENTÃO “AÇÃO=COMEÇAR”
Base de Regras
Máquina de
inferência
Pós-Engenharia de Software - FAT
37
Estilos e padrões arquiteturais
Máquina virtual (Virtual Machine)

Baseado em regras (Rule-based)

Exemplos: Prolog, Sistemas Especialistas
Memória de trabalho
SE “HORA=21:00”
ENTÃO “AÇÃO=LANCHE”
HORA = 18:00
AÇÃO = ESPERAR
SE “HORA=22:00”
ENTÃO “AÇÃO=LIBERAR”
SE “HORA<19:00”
ENTÃO “AÇÃO=ESPERAR”
SE “HORA=19:00”
ENTÃO “AÇÃO=COMEÇAR”
Base de Regras
Máquina de
inferência
Pós-Engenharia de Software - FAT
38
Estilos e padrões arquiteturais
Máquina virtual (Virtual Machine)

Baseado em regras (Rule-based)

Exemplos: Prolog, Sistemas Especialistas
Memória de trabalho
SE “HORA=21:00”
ENTÃO “AÇÃO=LANCHE”
HORA = 18:00
AÇÃO = ESPERAR
AÇÃO=ESPERAR
SE “HORA=22:00”
ENTÃO “AÇÃO=LIBERAR”
SE “HORA<19:00”
ENTÃO “AÇÃO=ESPERAR”
SE “HORA=19:00”
ENTÃO “AÇÃO=COMEÇAR”
Base de Regras
Máquina de
inferência
Pós-Engenharia de Software - FAT
39
Estilos e padrões arquiteturais
Fluxo de dados (Data Flow)

Seqüencial (Batch Sequential)

Programas independentes executados em seqüência
 Um após o outro
 Dado transmitido por completo entre um programa e outro
Arquivos fonte
Bytecode
class{
}
Arquivo Jar
000
1001
1001
A$n3*
3N4*#
Javac
Jar
Java
Compilando
Empacotando
executando
Pós-Engenharia de Software - FAT
40
Estilos e padrões arquiteturais
Fluxo de dados (Data Flow)

Tubos e filtros (Pipe and Filter)


Já vimos na última aula
Exemplo: compilador
tokens
Código fonte
Analisador
Léxico
Intel backend
Árvore sintática
Analisador
Sintático
Árvore sintática c/ semântica
Analisador
Semântico
Executável otimizado
Gerador de
código
intermediário
Executável
Otimizador
MIPS backend
SPARC backend
Pós-Engenharia de Software - FAT
41
Estilos e padrões arquiteturais
Fluxo de dados (Data Flow)

Tubos e filtros (Pipe and Filter)

Não precisa ser seqüencial
Pós-Engenharia de Software - FAT
42
Estilos e padrões arquiteturais
Exercício


Quais estilos arquiteturais poderiam ser aplicados na
arquitetura definida anteriormente (Módulo I)? Como?
Se algum estilo não puder ser aplicado, justifique o
porquê.
Invocação/Retorno (Call/Return)
Programa principal/Subrotina (Main Program/Subroutine)
Invocação remota de procedimento (Remote Procedure Call - RPC)
Camadas (Layered)
Componentes independentes (Independent Components)
Comunicação de processos (Communicating Processes)
Baseado em eventos
Centrado em dados (Data-Centered)
Repositório (Repository)
Quadro negro (Blackboard)
Máquina virtual (Virtual Machine)
Interpretador (Interpreter)
Baseado em regras (Rule-based)
Fluxo de dados (Data-Flow)
Seqüencial (Batch Sequential)
Pós-Engenharia de Software
- FAT e filtros (Pipe and Filter)
Tubos
43
Atributos de qualidade

Arquitetura e funcionalidade





Se a funcionalidade fosse o único atributo buscado no
desenvolvimento de um software...
... sua arquitetura seria sempre monolítica: uma só função,
um só componente, uma só classe...
Outros atributos: mutabilidade (modifiability), usabilidade,
desempenho...
... influenciam na determinação da arquitetura do software
É com base em atributos de qualidade interessantes para o
sistema que se determina a sua arquitetura
Pós-Engenharia de Software - FAT
44
Atributos de qualidade

Classes de atributos



Qualidades de sistema: disponibilidade, mutabilidade,
desempenho, usabilidade...
Qualidades de negócio: tempo de produção (time to
market), custo e benefício...
Qualidades de arquitetura: buildability, integridade
conceitual...
Pós-Engenharia de Software - FAT
45
Atributos de qualidade
Qualidades de sistema






Disponibilidade
Mutabilidade
Desempenho
Segurança
Testabilidade
Usabilidade
Pós-Engenharia de Software - FAT
46
Atributos de qualidade
Qualidades de sistema

Disponibilidade




Relacionada a falhas no sistema e suas conseqüências
Um sistema está em falha quando não funciona mais de acordo
com a sua especificação
Uma falha é observável do ponto de vista externo
Medida de disponibilidade:
disp =
tempo médio para falhar
tempo médio para falhar + tempo médio para reparar
Pós-Engenharia de Software - FAT
47
Atributos de qualidade
Qualidades de sistema

Mutabilidade


Relacionado ao custo de mudanças
O que pode mudar?


Implementação de funcionalidades
Plataforma na qual o sistema é executado (hardware, SO,...)



O ambiente no qual opera (protocolos, rede, outros sistemas)
Capacidade (nº de usuários, nº de operações simultâneas)


Portabilidade
Escalabilidade
Quem pode mudar?

Desenvolvedor, usuário final, administrador...
Pós-Engenharia de Software - FAT
48
Atributos de qualidade
Qualidades de sistema

Mutabilidade

Quando pode mudar?




Implementação (código fonte)
Construção – build (escolha de bibliotecas)
Configuração
Execução (parametrização)
Pós-Engenharia de Software - FAT
49
Atributos de qualidade
Qualidades de sistema

Desempenho



Relacionado a tempo!
Eventos ocorrem e o sistema tem que responder aos mesmos
A medida de desempenho é:


Evento???


Quanto tempo leva o sistema para responder a um evento?
Interrupções, mensagens, requisições do usuário, inicialização...
Exemplo:

Respostas a requisições do usuário não podem durar mais que
10 milisegundos!
Pós-Engenharia de Software - FAT
50
Atributos de qualidade
Qualidades de sistema

Segurança



Habilidade do sistema de impedir acesso não autorizado...
... ainda garantindo acesso autorizado!
Segurança pode ser visto como uma composição de:






Não repudiação: uma transação não pode ser negada por
nenhuma das partes envolvidas
Confidencialidade: proteção a acesso não autorizado
Integridade: de dados e serviços
Garantia: partes de uma transação são quem dizem que são
Disponibilidade: sistema disponível para uso sem falhas
Auditoria: caso ocorra falha, o sistema consegue recuperar-se
sem perdas aos usuários
Pós-Engenharia de Software - FAT
51
Atributos de qualidade
Qualidades de sistema

Testabilidade



Facilidade com que podem ser demonstradas as faltas de um
software através de testes
No mínimo, 40% do custo de desenvolvimento de software com
“boa engenharia” é atribuído a testes...
... se o arquiteto consegue reduzir este custo, o lucro é bem
maior!
Pós-Engenharia de Software - FAT
52
Atributos de qualidade
Qualidades de sistema

Usabilidade



Quão fácil é para o usuário realizar uma tarefa desejada usando
o sistema?
Que tipo de suporte o sistema provê para o usuário?
Áreas:





Aprendizado das características do sistema: o que o sistema pode fazer
para ajudar no aprendizado do usuário?
Uso eficiente do sistema: o que o sistema pode fazer para que o usuário o
utilize mais eficientemente?
Minimização do impacto de erros: o que o sistema pode fazer para
minimizar o impacto de um erro cometido pelo usuário?
Adaptação do sistema às necessidades do usuário: como o usuário (ou o
próprio sistema) pode adaptar o sistema para tornar as tarefas mais fáceis
Aumento de confiança e satisfação: o que o sistema faz para dar ao usuário
a confiança de que ele está executando a tarefa corretamente?
Pós-Engenharia de Software - FAT
53
Atributos de qualidade
Qualidades de negócio






Tempo de produção (time-to-market)
Custo e benefício
Tempo de vida projetado
Mercado alvo
Agenda de divulgação
Integração com sistemas legados
Pós-Engenharia de Software - FAT
54
Atributos de qualidade
Qualidades de negócio

Tempo de produção (time-to-market)



Se há pressão competitiva ou janela de oportunidade restrita...
... tempo de produção é essencial!
Em geral, reduzido com o uso componentes pré-construídos

Componentes COTS – Commercial Off-The-Shelf
Pós-Engenharia de Software - FAT
55
Atributos de qualidade
Qualidades de negócio

Custo e benefício



Orçamento não pode ser excedido
Diferentes arquiteturas levarão a diferentes custos de
desenvolvimento
Arquiteturas mais flexíveis são mais caras!!!
Pós-Engenharia de Software - FAT
56
Atributos de qualidade
Qualidades de negócio

Tempo de vida projetado





Se o sistema é projetado para ter um longo ciclo de vida...
... mutabilidade, escalabilidade e portabilidade se tornam
extremamente importantes
Porém... isto influencia no custo!
Por outro lado, tais características diminuem custos de
manutenção
Sistemas projetados para um curto ciclo de vida podem ser mais
brandos em relação a estas características!

Será??? Como prever o ciclo de vida?
Pós-Engenharia de Software - FAT
57
Atributos de qualidade
Qualidades de negócio

Mercado alvo

Considerando softwares de propósito geral, a quantidade de
plataformas de execução determina o mercado em potencial

Exemplo: seu sistema de controle de estoque pode executar:





Em Windows, Linux e Mac?!
Em rede ou standalone?!
Em PC ou dispositivo móvel?
Portabilidade é chave! Usabilidade e desempenho também!
Solução utilizada

Linhas de produto

Núcleo em comum + características específicas
Pós-Engenharia de Software - FAT
58
Atributos de qualidade
Qualidades de negócio

Agenda de divulgação


Liberação do produto como um todo???
Liberação de funcionalidade base e depois liberação de
funcionalidades adicionais?



Escalabilidade
Flexibilidade
Facilidade de expansão e contração


Diferentes usuários terão diferentes necessidades
Exemplo: Eclipse
Pós-Engenharia de Software - FAT
59
Atributos de qualidade
Qualidades de negócio

Integração com sistemas legados


Integração com sistemas e tecnologias existentes
Impacto direto na arquitetura



Deve funcionar de acordo com a especificação de terceiros
Deve se adequar à arquitetura de terceiros
Pode haver incompatibilidades!
Pós-Engenharia de Software - FAT
60
Atributos de qualidade
Qualidades de arquitetura

Buildability


Integridade conceitual


Facilidade do sistema ser construído, maximizando o paralelismo
de desenvolvimento e manutenção
Visão que unifica o projeto arquitetura em todos os níveis
Corretude e completude



Análise e verificação formal dos requisitos
Garante que a arquitetura contempla os requisitos
Complementar aos testes
Pós-Engenharia de Software - FAT
61
Atributos de qualidade
Exercício



Quais atributos de qualidade são contemplados na arquitetura
definida anteriormente (Módulo I)
Como os atributos não contemplados poderiam vir a ser?
Se algum atributo não pode ser contemplado, justifique o
porquê.
Qualidades de sistema: disponibilidade, mutabilidade, desempenho,
segurança,
testabilidade e usabilidade
Qualidades de negócio: tempo de produção, custo e benefício, tempo de
vida projetado, mercado alvo, agenda de divulgação, integração com sistemas
legados
Qualidades de arquitetura: buildability, integridade conceitual, corretude e
completude
Pós-Engenharia de Software - FAT
62
Seleção de estilos

Como selecionar um estilo arquitetural?
1. Identificar os principais elementos da arquitetura
2. Identificar o estilo arquitetural dominante
3. Considerar responsabilidades adicionais associadas com a
escolha do estilo
4. Modificar o estilo para atingir objetivos adicionais
Fonte:
Pós-Engenharia de Software - FAT
63
Seleção de estilos
1. Identificar os principais elementos da arquitetura



Cada elemento arquitetural tem um estilo arquitetural dominante
que reflete as qualidades importantes que devem ser alcançadas
no contexto daquele elemento
A escolha do estilo arquitetural dominante é baseada nos
principais elementos arquiteturais
Os atributos de qualidade sobre cada elemento arquitetural
podem acarretar a utilização ou não de um estilo
Fonte:
Pós-Engenharia de Software - FAT
64
Seleção de estilos
2. Identificar o estilo arquitetural dominante



O estilo dominante pode ser modificado para alcançar objetivos
particulares
Se nenhum estilo conhecido parece ser apropriado, o arquiteto
deve projetar e documentar um novo estilo
As decisões sobre escolhas baseadas em atributos de qualidade
dentro de um estilo devem ser documentadas
Fonte:
Pós-Engenharia de Software - FAT
65
Seleção de estilos
3. Considerar responsabilidades adicionais associadas com
a escolha do estilo



A escolha de um estilo arquitetural introduzirá responsabilidades
adicionais
Por exemplo:
 Se o estilo é “Quadro negro”, então deve-se gerenciar os
mecanismos para o controle do quadro negro
 Se o estilo é “cliente-servidor”, deve-se gerenciar os protocolos
de interação
Responsabilidades adicionais devem ser atribuídas a elementos
arquiteturais existentes ou a novos elementos criados para este
fim
Fonte:
Pós-Engenharia de Software - FAT
66
Seleção de estilos
4. Modificar o estilo para atingir objetivos adicionais


Pode-se alterar o estilo arquitetural caso este necessite ser adaptado
devido a atributos de qualidade ou até mesmo funcionalidade
Exemplo: cliente-servidor

Adaptação: broker
Requisita
serviço
Servidores
Broker
A
Bridge
Proxy
Broker
B
Cliente
Proxy
Servidores
Fonte:
Pós-Engenharia de Software - FAT
67
Seleção de estilos
Exemplo
1. Identificar os principais elementos da arquitetura

Sistema: acadêmico
Módulo de acesso do
usuário
Módulo de
armazenamento de
dados
Pós-Engenharia de Software - FAT
68
Seleção de estilos
Exemplo
2. Identificar o estilo arquitetural dominante
Não deve requerer
instalação!
Deve ter alta
disponibilidade
Módulo de acesso do
usuário
Deve executar
na Internet
Deve ser fino!
Deve ser possível
acessar de qualquer
lugar
Acesso à máquina
do BD só via rede
Não há confiança na
disponibilidade da
máquina do BD
Módulo de
armazenamento de
dados
Pós-Engenharia de Software - FAT
Utiliza banco de outra
aplicação (legada)
69
Seleção de estilos
Exemplo
3. Considerar responsabilidades adicionais associadas com
a escolha do estilo



Estilo dominante escolhido: Cliente-servidor
Estilo secundário: Repositório
Responsabilidades: considerar protocolo de comunicação
Cliente
Rede/HTTP
Servidor
Pós-Engenharia de Software - FAT
70
Seleção de estilos
Exemplo
4. Modificar o estilo para atingir objetivos adicionais

Cliente servidor de 2 camadas e repositório com backup
Módulo cliente
(Acesso do usuário)
Cliente/
Servidor
consulta/
atualização
Cliente/
Servidor
leitura
Repositório
Módulo Backup
(Dados)
sincronização
Módulo Servidor
(Web)
leitura/escrita
Cliente/
Servidor
Pós-Engenharia de Software - FAT
Módulo Servidor
(Dados)
leitura/escrita
Aplicação legada
71
Seleção de estilos
Exemplo
4. Modificar o estilo para atingir objetivos adicionais

Objetivos atingidos!
Módulo cliente
(Acesso do usuário)
consulta/
atualização
- Alta disponibilidade
- Fino
- Executar na Internet
- Acesso de qualquer lugar
- Não requer instalação
leitura
Módulo Backup
(Dados)
sincronização
Módulo Servidor
(Web)
leitura/escrita
- Acesso à maquina do BD
só via rede
- Banco de outra aplicação
- Não há Pós-Engenharia
confiança nade Software - FAT
disponibilidade
Módulo Servidor
(Dados)
leitura/escrita
Aplicação legada
72
Seleção de estilos
Exercício

Qual ou quais estilos arquiteturais você utilizaria para os
sistemas listados... (lista apresentada em sala)
Invocação/Retorno (Call/Return)
Programa principal/Subrotina (Main Program/Subroutine)
Invocação remota de procedimento (Remote Procedure Call - RPC)
Camadas (Layered)
Componentes independentes (Independent Components)
Comunicação de processos (Communicating Processes)
Baseado em eventos
Centrado em dados (Data-Centered)
Repositório (Repository)
Quadro negro (Blackboard)
Máquina virtual (Virtual Machine)
Interpretador (Interpreter)
Baseado em regras (Rule-based)
Fluxo de dados (Data-Flow)
Seqüencial (Batch Sequential)
Pós-Engenharia de Software
- FAT e filtros (Pipe and Filter)
Tubos
73
Seleção de visões

Quais são as visões arquiteturais relevantes para o
sistema sendo desenvolvido?
Cliente
???
Arquiteto
???
Pós-Engenharia de Software - FAT
74
Visões arquiteturais
Relembrando...

Modelo “4+1” (Rational Software)
Visão
Lógica
Visão de
Desenvolvimento
Cenários
Visão de
Processo
Visão
Física
Pós-Engenharia de Software - FAT
75
Visões arquiteturais
Relembrando...

Visão Lógica


“Retrato estático” dos relacionamentos existentes entre as
entidades do sistema
Pode possuir duas ou mais representações, dentre elas,
uma conceitual e outra de esquema de banco de dados
Visão
Lógica
Pós-Engenharia de Software - FAT
76
Visões arquiteturais
Relembrando...

Visão de Processo



Descreve aspectos de sincronização e concorrência
Descrição de processos concorrentes
Diferentes linhas de execução (threads), entidades ativas
Visão de
Processo
Pós-Engenharia de Software - FAT
77
Visões arquiteturais
Relembrando...

Visão de Desenvolvimento

Descreve a organização do software em seu ambiente de
desenvolvimento
 Componentes
 Linguagens
Visão de
Desenvolvimento
Pós-Engenharia de Software - FAT
78
Visões arquiteturais
Relembrando...

Visão Física




Descreve o mapeamento do software para o hardware
Distribuição de componentes
Verificação de alta disponibilidade, confiabilidade,
desempenho...
Também chamada “deployment”
Visão
Física
Pós-Engenharia de Software - FAT
79
Visões arquiteturais
Relembrando...

Cenários (+1)



Cenários de funcionamento do sistema diretamente
ligados à arquitetura
Principais casos de uso
Lembram de RUP?
 Centrado em arquitetura!
Cenários
Pós-Engenharia de Software - FAT
80
Seleção de visões

Três passos:
1. Produza uma tabela de visões
2. Combine visões
3. Priorize visões
Pós-Engenharia de Software - FAT
81
Seleção de visões
Produza uma tabela de visões
1.

De acordo com as características do sistema
Stakeholder
Gerente
Desenvolvedor
Testador
Cliente
Usuário final
Analista
Arquiteto
Lógica
d
v
v
v
v
d
d
Processo
Desenvolvimento
Física
v
v
v
v
d
d
d
v
d
d
d
Legenda:
d = informação bem detalhada
a = alguns detalhes
v =Pós-Engenharia
visão geral de Software - FAT
82
Seleção de visões
2. Combine visões




Considerando que para cada visão apresentada
anteriormente, tem-se um ou mais modelos...
... ficaria impraticável criar um modelo na perspectiva de
cada uma das visões definidas anteriormente
Procure visões na tabela que requeiram apenas uma
“visão geral” e com poucos stakeholders envolvidos
 Lógica: 4 v
 Física: 3 stakeholders
Os modelos gerados para esta visão podem ser
simplificados
Pós-Engenharia de Software - FAT
83
Seleção de visões
2. Combine visões

A visão de processo poderia ser combinada à de
desenvolvimento (Estereótipos)
Stakeholder
Gerente
Desenvolvedor
Testador
Cliente
Usuário final
Analista
Arquiteto
Lógica
d
v
v
v
v
d
d
Processo
Desenvolvimento
Física
v
v
v
v
d
d
d
v
d
d
d
Legenda:
d = informação bem detalhada
a = alguns detalhes
v =Pós-Engenharia
visão geral de Software - FAT
84
Seleção de visões
3. Priorize visões



Uma vez definidas as visões, deve-se estabelecer uma
ordem de prioridade
Sempre começar uma nova visão após terminar outra
Exemplo de ordem:
 Visão lógica
 Visão física
 Visão de desenvolvimento
Pós-Engenharia de Software - FAT
85
Rastreabilidade bidirecional

Rastreamento: requisitos código e vice-versa
durante o ciclo de desenvolvimento do software
Requisitos
Código
Public
class{
Public
class{
Public
class{
Public
......
Publicclass{
class{
......
}}
...
}}
}
Revisões mais
rápidas
Maior facilidade
de entendimento
Rastreamento “para frente”
(Forward Traceability)
Pós-Engenharia de Software - FAT
Evita código
desnecessário
Testes mais fiéis
à funcionalidade
86
Rastreabilidade bidirecional

Rastreamento: requisitos código e vice-versa
durante o ciclo de desenvolvimento do software
Requisitos
Código
Public
class{
Public
class{
Public
class{
Public
......
Publicclass{
class{
......
}}
...
}}
}
Manutenção
Rastreamento “para trás”
(Backward Traceability)
Depuração
Evolução
Pós-Engenharia de Software - FAT
87
Rastreabilidade bidirecional

Apontada como grande “arma” para o
desenvolvimento...
 CMMi (Capability Maturity Model Integration)
Software Engineering Institute – SEI
Manter rastreabilidade bidirecional do desenvolvimento é
essencial para um processo de software de sucesso


Pós-Engenharia de Software - FAT
88
Exercício final

Refaçam a arquitetura do sistema definido
anteriormente (Módulo I)




Levando em conta a seleção de estilos
Levando em conta a seleção de visões
Levando em conta atributos de qualidade
Justificando escolhas:



Por que usou estes estilos?
Por que usou estas visões?
Como a arquitetura “alcança” os atributos de qualidade definidos?
Pós-Engenharia de Software - FAT
89