Reuso de Software Aula 04

Agenda da Aula

Arquitetura de Software e Arquitetura de Software

Padrões Arquiteturais Padrões arquiteturais
Arquitetura em Camadas
Dutos e Filtros
Eduardo Figueiredo Repositório Compartilhado
http://www.dcc.ufmg.br/~figueiredo Cliente-Servidor
[email protected] Modelo-Visão-Controle
14 Março 2012 Microkernel

Abordagens de Reuso Padrões de Projeto

Um padrão é uma descrição do

problema e a essência da sua solução
Documenta boas soluções para
problemas recorrentes
Permite o reuso de conhecimento
anterior documentados em boas práticas
Deve ser suficientemente abstrato
para ser reusado em aplicações
diferentes

Elementos de um Padrão

Nome
Um identificador significativo para o padrão Arquitetura de Software
Descrição do problema
Descrição da solução
Um template de solução que pode ser
instanciado em maneiras diferentes
Consequências
Os resultados e compromissos de
aplicação do padrão
Modelagem de Software Projeto Arquitetural de Software
GUI

Dividido em duas etapas

DISTRIBUTION
Projeto de Arquitetura define a estrutura
modular do software, as interfaces e as
estruturas de dados utilizadas
CONCURRENCY BUSINESS

Projeto Detalhado descreve

detalhadamente cada módulo definido no
projeto preliminar PERSISTENCE DATA

Outro Exemplo de Arquitetura Projeto Detalhado de Software

Projeto Arquitetural Definindo a Solução

Primeiro passo do projeto de sistema
O projeto é uma atividade criativa
Cada arquiteto tem sua própria maneira É frequentemente conduzido em
de projetar o software paralelo com atividades de
especificação de requisitos
Projeto arquitetural faz a ligação entre O projeto arquitetural envolve
Requisitos (domínio do problema) e Identificação dos componentes principais
do sistema
Projeto detalhado (domínio da solução)
Definição das interfaces de comunicação
entre os componentes
Vantagens da Arquitetura Uma arquitetura pode afetar...

Comunicação entre stakeholders O desempenho do sistema

A arquitetura pode ser usada como foco Exemplo: se incluir gargalos de
da discussão sobre o sistema comunicação
Análise de sistema A facilidade de distribuição
Adequação aos requisitos não funcionais Sistemas complexos executam em
Reuso em larga escala várias máquinas
Um componente da arquitetura pode ser A facilidade de manutenção
reusado em outros sistemas Componentes devem ser substituíveis

Requisitos Não Funcionais Decisões de projeto arquitetural

A arquitetura deve considerar requisitos Questões precisam ser respondidas

não funcionais Como o sistema será distribuído em
diferentes máquinas?
Desempenho: evitar comunicação
excessiva entre componentes distribuídos Como as funcionalidades serão
decompostas em componentes?
Segurança: ocultar características críticas
de segurança em camadas mais internas Como avaliar se a arquitetura atende
aos requisitos não funcionais?
Disponibilidade: incluir componentes
redundantes e tolerância à falhas, etc. Existe uma arquitetura genérica que
possa ser usada?

Diagrama de Componentes Exemplo de Arquitetura

Identifica os principais subsistemas Subsistema de

Subsistema de Subsistema de
que serão desenvolvidos Vendas
Controle de
Fornecedores
Estoque

Notação simplificada
Caixas representam os subsistemas
(componentes) Subsistema de
Subsistema de
Gerência de
Linhas representam alguma Entrega
Pessoal
comunicação entre os subsistemas
Quando usar o diagrama?

Pontos positivos
Facilita comunicação com stakeholders Padrões Arquiteturais
Úteis para planejamento de projeto
Facilita o desenvolvimento em paralelo
Pontos negativos
Não mostra a natureza dos
relacionamentos entre componentes
Não indica as propriedades internas dos
subsistemas

Reuso de arquitetura Padrões Arquiteturais

Padrões arquiteturais expressam

Embora cada sistema seja único formas de organizar a estrutura
É comum que sistemas do mesmo fundamental do sistema
domínio tenham arquiteturas similares Permitem a construção de uma
arquitetura aderente a certas
Um projeto pode ser baseado em um propriedades
padrão arquitetural conhecido O conhecimento de padrões
arquiteturais pode ajudar na definição
da arquitetura do sistema

Elementos de um Padrão Da arquitetura a implementação

A escolha do padrão arquitetural pode Padrões arquiteturais representam os

ser o primeiro passo para a solução padrões mais abstratos
Padrões de projeto (Modelagem)
Padrões arquiteturais definem Idiomas (Programação)
Um conjunto de sub-sistemas
As responsabilidades de cada Os padrões arquiteturais definem a
sub-sistema estrutura fundamental
Regras de relacionamentos entre Atividades subsequentes devem seguir
os sub-sistemas esta estrutura
Padrões são abstratos Escolha do Padrão

Os padrões não definem completamente A escolha do padrão arquitetural deve

a arquitetura do sistema estar associada ao tipo de sistema e
Padrões são templates que devem ser seus requisitos não funcionais
refinados Algumas perguntas podem ajudar
Exemplos de refinamentos O sistema é interativo?
Incluir outros componentes e novos Possui muitas variações?
relacionamentos Que requisitos não funcionais são
Definir padrões de projeto e idiomas em importantes? Confiabilidade?
fases subsequentes Adaptabilidade?

Composição de Padrões

Padrões diferentes levam a Exemplos de

consequências diferentes
Padrões Arquiteturais
Mesmo quando os padrões abordam
problemas semelhantes

Assim como ocorre em padrões de

projeto, sistemas complexos possuem
mais de um padrão arquitetural

Padrões Arquiteturais Livros de Padrões Arquiteturais

Da desordem a estrutura
Layered Architecture Pattern-Oriented Software
Pipes and Filters
Blackboard
Architecture: A System of
Sistemas distribuídos Patterns (Volume 1)
Client-Server
Broker
Sistemas interativos
Model-View-Controller (MVC)
Presentation-Abstraction-Control
Sistemas adaptáveis
Microkernel
Reflection
 Padrões Arquiteturais Arquitetura em Camadas
Da desordem a estrutura
Layered Architecture (Arquitetura em Camadas) Organiza o sistema em um conjunto
Blackboard (Repositório Compartilhado)
de camadas
Pipes and Filters (Dutos e Filtros)
Sistemas distribuídos Cada camada oferece um conjunto de
Client-Server (Cliente-Servidor) serviços
Broker
Discutidos no livro
Sistemas interativos
do Sommerville Uma camada somente
Model-View-Controller (MVC)
Presentation-Abstraction-Control Solicita serviços da camada inferior
Sistemas adaptáveis
Microkernel Fornece serviços para a camada superior
Reflection

Exemplo 1: Protocolos OSI Exemplo 2: Três Camadas

Modelo de camadas para sistemas de comunicação
Camada de Apresentação

Camada de Negócios

Camada de Dados

Vantagens Desvantagens

Favorece o modelo de desenvolvimento Estruturar o sistema em camadas não é

incremental
trivial
As camadas podem ser facilmente
Pode ser difícil identificar quais os serviços
substituídas por equivalentes
elementares das camadas inferiores
Requer interfaces estáveis
Mudanças em uma camada (teoricamente) Muitas camadas podem comprometer o
só impacta a camada superior desempenho do sistema
Camadas superiores podem ser A requisição tem que trafegar pelas várias
independentes de plataforma/hardware camadas até ser atendida
Dutos e Filtros Dinâmica do Padrão

Padrão de organização da dinâmica Os dados de entrada se movem

de um sistema pelos dutos, sendo transformados
Dois papéis principais pelos filtros, até serem convertidos
Dutos: componentes que conduzem ou em dados de saída
distribuem os dados As transformações podem ocorrem em
Filtros: componentes que transformam sequência ou em paralelo
os dados
Usado principalmente em aplicações
de processamento de dados

Exemplo de Dutos e Filtros Vantagens

Entradas: Faturas e Pagamentos O módulo de transformação (filtro) é

Saídas: Recibos e Lembretes bem modular
Facilmente reusável e substituível
O estilo de workflow é aderente a
muitos processos de negócios
É simples evoluir o sistema pela adição
de filtros
Se aplica tanto a sistemas sequênciais
quanto a sistemas concorrentes

Desvantagens Repositório Compartilhado

O formato dos dados trafegados devem Também conhecido como Blackboard

ser acordados entre os módulos Os subsistemas manipulam a mesma
base de dados
Pode haver um overhead causado pela Um (ou mais) subsistema gera os dados
padronização dos dados Vários subsistemas lêem os dados
Adotado principalmente quando
Incompatibilidade no formato dos dados grandes quantidades de dados são
pode dificultar o reuso de filtros compartilhadas
 Exemplo de Repositório Vantagens

Maneira eficiente de compartilhar

Subsistema de dados
Subsistema de Subsistema de
Controle de
Vendas Compras Backup é centralizado (mais fácil)
Estoque
Formas de proteção dos dados podem
ser implementadas
Banco de Os subsistemas que gravam dados
Dados de não necessitam saber quem os usa
Produtos Fácil integrar novos subsistemas

Desvantagens Resumo da Aula

Os subsistemas devem entender o Arquitetura de software

formato dos dados gravados
Primeiras decisões no domínio da
Manter e evoluir grandes volumes de solução
dados pode ser difícil / caro Favorece o reuso em larga escala
Subsistemas diferentes podem ter
Padrões arquiteturais
requisitos diferentes
Restringe as próximas fases de
Mais segurança ou maior disponibilidade
desenvolvimento
Dificuldade para distribuir os dados
A escolha depende de características
Dados redundantes ou inconsistentes do sistema

Referências da Aula Próxima Aula

Ian Sommerville. Engenharia de Software,

9a. Edição. 2011. Linha de produtos de software
Seção 6.1 Decisões de projeto de arquitetura
Seção 6.2 Visões da arquitetura
Seção 6.3 Padrões de arquitetura

F. Buschmann et al. Pattern-Oriented

Software Architecture: A System of
Patterns. John Wiley & Sons, 1996.
Cap. 2 Architectural Patterns