aperfeiçoamento do desenho - técnico lisboa3-3).pdf · métricas de desenho princípio do...
TRANSCRIPT
![Page 1: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/1.jpg)
1
Desenho de Software 71
Aperfeiçoamento do Desenho� Desenho por contrato� Protótipos de desenho
Desenho de Software 72
Desenho por Contrato� Utiliza-se a técnica de desenho por contrato para
assegurar que o desenho satisfaz a sua especificação� Um componente, dito cliente, que necessita dos
serviços de outro componente, dito fornecedor, pelo qual celebram um contrato que especifica:� as obrigações mútuas, chamados de pré-condições� os benefícios, chamados de pós-condições� as restrições de coerência, chamadas de invariantes
� Facilitam o desenvolvimento separado, a reutilização, os testes, a verificação da coerência entre as cláusulas, a verificação da correcção da implementação, documentam o desenho, ...
![Page 2: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/2.jpg)
2
Desenho de Software 73
Noção de contrato� Contracto escrito entre duas partes quando uma
delas (FOLHQWH) executa alguma tarefa para outra parte (IRUQHFHGRU)
� O objectivo do documento de contrato é descrever os EHQHItFLRV e REULJDo}HV de cada um dos parceiros
Fornecedor
Cliente (vai beneficiar da pós-condição)
&KHJDU�DR�GHVWLQR(tem que garantir pré-condição)
3DJDU�ELOKHWH��EDJDJHP�����(pode assumir pré-condição)
%LOKHWH�IRL�SDJR�����(tem que garantir pós-condição)
/HYDU�R�FOLHQWH�DR�GHVWLQR
BenifíciosObrigações
Desenho de Software 74
Exemplo
Fornecedor
Cliente (vai beneficiar da pós-condição)
$�WDEHOD�p�DFWXDOL]DGD�FRP�R�QRYR�HOHPHQWR�H�D�FKDYH�GDGD�
(tem que garantir pré-condição)
$�WDEHOD�QmR�HVWi�FKHLD�H�D�FKDYH�GH�DFHVVR�QmR�p�D�VWULQJ�YD]LD
(pode assumir pré-condição)
6H�D�WDEHOD�HVWi�FKHLD�RX�D�FKDYH�p�D�VWULQJ�YD]LD��QmR�p�QHFHVViULR�ID]HU�QDGD
(tem que garantir pós-condição)
$FWXDOL]D�D�WDEHOD�FRP�R�QRYR�HOHPHQWR
BenifíciosObrigações
� Inserção de um elemento de uma tabela
![Page 3: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/3.jpg)
3
Desenho de Software 75
Desenho por Contrato� Exemplo Eiffel [Meyer1992]
put (x: ELEMENT; key: STRING)
-- Insert x so that it will be retrievable through key�����������
count <= capacity;
not key.empty� �
... Some insertion algorithm ...����������
has(x);
item(key) = x;
count = old count + 1�������� �����
0 <= count
count <= capacity��� �
Desenho de Software 76
Desenho por Contrato� Fabrica de produtos químicos � Classes TANK, PIPE, VALVE, CONTROL_ROOM
fill �
-- Fill tank with liquid �����������
������� �������! #"$��� &% '���� �������)(��� �*���+
� �
-- Implementation ����������
������� �������)(��� �*���+-, &% '���� �������)(��� �*���+.,��*�/�%����
0 ������� �����
isFull = (0.95 * capacity <= gauge) and(gauge <= 1.05 * capacity)
��� �
![Page 4: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/4.jpg)
4
Desenho de Software 77
Protótipos de Desenho� Permitem verificar se a solução de
desenho vai de facto resolver o problema
� O protótipo deve focar apenas no aspecto de desenho sobre o qual existem dúvidas
� Frequentemente são descartáveis
Desenho de Software 78
Validação e Verificação� 9DOLGDomR – certificar se o desenho satisfaz
todos os requisitos do utilizador� 9HULILFDomR – certificar se a solução
incorpora as qualidades de desenho requeridas
� Existem várias técnicas:1 Validação Matemática pode ser difícil mas muito
útil para alguns aspectos críticos1 Métricas de Desenho permitem quantificar a
qualidade1 Comparação de Desenhos para avaliar os
compromissos
![Page 5: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/5.jpg)
5
Desenho de Software 79
Validação Matemática� Método B
2 Metodologia e ferramenta de desenvolvimento formal
2 Um sistema é definido por uma composição de abstract machines
2 Refinamento3 No inicio considera-se uma abstração do
sistema3 Em cada refinamento são adicionados detalhes3 No final é gerado código C+ + ou Java
Desenho de Software 80
Métricas de Desenho� Não se pode gerir aquilo que não se controla
e não se pode controlar aquilo que não se consegue medir. Tom DeMarco
� As seguintes métricas propostas por Robert Martin medem a qualidade do desenho com objectos. Considera módulos reutilizáveis de componentes:� Ligação de Fora/Dentro (LFD): número de classes de fora
do módulo que dependem de classes de dentro do módulo� Ligação de Dentro/Fora (LDF): número de classes de dentro
do módulo que dependem de classes fora do módulo� Instabilidade (I): I = LDF / (LFD + LDF), I=0 indica
estabilidade e I=1 indica instabilidade do módulo
![Page 6: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/6.jpg)
6
Desenho de Software 81
Métricas de Desenho� Princípio do Aberto/Fechado
1 Um sistema não pode ter todos os módulos estáveis
1 Um módulo deve ser aberto à extensão e fechado à modificação
1 Desta forma, os módulos estáveis devem ser muito abstractos enquanto que os módulos instáveis devem ser muito concretos
� Uma medida de abstracção:1 Abstracção (A): A = número de classes abstractas
do módulo / número total de classes do módulo, A= 0 significa que é concreto e A= 1 que é abstracto
Desenho de Software 82
Métricas de Desenho� Relacionamento
entre a medida de abstracção e a instabilidade de um modulo:1 A = 1 e I = 01 A = 0 e I = 11 A = 0 e I = 01 A = 1 e I = 1
1 A = 0.5 e I = 0.5instabilidade
abst
rac ç
ã o
1
1(0,1)
(1,0)
sequência principal
![Page 7: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/7.jpg)
7
Desenho de Software 83
Métricas de Desenho� É desejável que os
módulos estejam próximos da sequência principal1 Distância (D):
D = | (A+ I-1) / 2|
instabilidadeab
stra
c çã o
1
1(0,1)
(1,0)
sequência principal
Desenho de Software 84
Comparação de Desenhos� Uma especificação possibilita muitos
desenhos2 Deve-se construir diversas soluções para o
problema usando diferentes estilos arquitecturais
2 Decidir qual o melhor desenho para os objectivos do sistema
2 Tabelas de Comparação3 Facilidade de alteração do algorítmo3 Performance3 Facilidade na reutilização3 Modularidade3 ...
![Page 8: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/8.jpg)
8
Desenho de Software 85
Comparação de Desenhos� Tabelas de comparação definem para
cada atributo de qualidade se um particular estilo arquitectural o suporta ou não
� Tabela de pesos indica qual a prioridade que cada atributo de qualidade tem para o sistema a desenvolver, permite calcular um valor para cada estilo arquitectural
Desenho de Software 86
Documentação do Desenho� Devem ser apresentadas quais as
razões do desenho que indiquem os aspectos críticos e os compromissos da solução
� Utilizar as notações necessárias para exprimir o desenho e as suas propriedades, por exemplo, UML
![Page 9: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/9.jpg)
9
Desenho de Software 87
Revisão do Desenho4 Este processo tem por objectivo garantir que
se está a desenvolver o sistema/programa que o cliente pretende
4 Faz-se detecção erros4 Revisão Preliminar
1 Clientes e utilizadores validam o desenho conceptual
4 Revisão Principal/Crítica1 Analistas, desenhadores validam o desenho
técnico1 Discutir desenhos alternativos
4 Revisão do Programa1 Realizada depois do desenho do sistema estar
concluído, mas antes da implementação
Desenho de Software 88
Casos Notáveis5 Padrão Data Access Object
6 http:/ / java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
5 Padrão Intercepting Filter 6 http:/ / java.sun.com/blueprints/corej2eepatterns/Patterns/ In
terceptingFilter.html5 Moldura de Objectos JUnit
6 Erich Gamma and Kent Beck6 http:/ / junit.sourceforge.net/doc/cookstour/cookstour.htm
5 Padrão Arquitectural Modelo-Vista-Controlador6 In Pattern-Oriented Software Architecture: A System of
Patterns. Frank Buschmann et al.
![Page 10: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/10.jpg)
10
Desenho de Software 89
Padrão Data Access Object� &RQWH[WR
7 Acesso aos dados depende da fonte dos dados8 tipo de armazenamento8 implementação do vendedor
Desenho de Software 90
Problema4 As aplicações podem usar a API JDBC mas
mesmo num SGBD relacional a sintaxe e o formato dos comando SQL pode variar devido ao produto usado
4 Existe ainda maior variação quando se usam diferentes tipos de SGBD
4 Cria-se uma dependência entre o código da aplicação e o código de acesso aos dados que dificulta a migração entre diferentes tipos de SGBD e diferentes produtos de um mesmo tipo
![Page 11: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/11.jpg)
11
Desenho de Software 91
Forças� Componentes aplicacionais necessitam
de obter/guardar informação de/para um suporte persistente
� As APIs dos suportes persistentes variam dependendo do vendedor do produto e do tipo do produto
� Componentes aplicacionais usualmente usam APIs proprietárias
� A portabilidade dos componentes aplicacionais é afectada
Desenho de Software 92
Solução� Utilizar um objecto de acesso aos
dados (DAO) para abstrair e encapsular todos os acessos à fonte de dados
� O DAO gere a ligação à fonte de dados para obter e guardar dados
� O DAO funciona como um adaptador entre o componente e a fonte de dados
![Page 12: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/12.jpg)
12
Desenho de Software 93
Estrutura
Desenho de Software 94
Participantes e Colaborações
![Page 13: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/13.jpg)
13
Desenho de Software 95
Estratégia� Factory Method
Desenho de Software 96
Estratégia� Abstract Factory e Factory Method
![Page 14: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/14.jpg)
14
Desenho de Software 97
Estratégia
Desenho de Software 98
Código: Fábrica Abstractapackage ServidorPersistente;
public interface ISuportePersistente {
public void iniciarTransaccao()
throws ExcepcaoPersistencia;
public void confirmarTransaccao()
throws ExcepcaoPersistencia;
public void cancelarTransaccao()
throws ExcepcaoPersistencia;
public IItemPersistente
getIItemPersistente();
public ISeccaoPersistente
getISeccaoPersistente();
public ISitioPersistente
getISitioPersistente();
}
![Page 15: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/15.jpg)
15
Desenho de Software 99
Código: Fábrica Concretapackage ServidorPersistente.OJB;
public class SuportePersistenteOJB
implements ISuportePersistente {
Implementation _odmg = null;
Database _db = null;
...
public IItemPersistente
getIItemPersistente()
{ return new ItemOJB(); }
public ISeccaoPersistente
getISeccaoPersistente()
{ return new SeccaoOJB(); }
public ISitioPersistente
getISitioPersistente()
{ return new SitioOJB(); }
}
Desenho de Software 100
Código: Interface DAOpackage ServidorPersistente;
import Dominio.ISitio;
public interface ISitioPersistente {
ISitio readByNome(String nome)
throws ExcepcaoPersistencia;
void write(ISitio sitio)
throws ExcepcaoPersistencia;
void delete(ISitio sitio)
throws ExcepcaoPersistencia;
void deleteAll()
throws ExcepcaoPersistencia;
}
![Page 16: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/16.jpg)
16
Desenho de Software 101
Código: Implementação OJBpackage ServidorPersistente.OJB;
public class SitioOJB
extends ObjectFenixOJB
implements ISitioPersistente {
public SitioOJB() { }
...
public void deleteAll()
throws ExcepcaoPersistencia {
String oqlQuery = "select all from " +
Sitio.class.getName();
super.deleteAll(oqlQuery);
}
}
Desenho de Software 102
Código: Objecto Valor package Dominio;
public class Sitio implements ISitio {
private String _nome;
private int _anoCurricular;
private int _semestre;
private String _departamento;
private String _curso;
private List _seccoes;
// códigos internos da base de dados
private int _codigoInterno;
...
// getter e setter methods
...
}
![Page 17: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/17.jpg)
17
Desenho de Software 103
Consequências� Permite a transparência� Facilita a migração� Reduz a complexidade do código do
componente aplicacional� Centraliza os acessos a dados numa
camada separada� Acrescenta uma camada adicional� Necessita do desenho de uma
hierarquia de classes
Desenho de Software 104
Padrão Intercepting Filter� O mecanismo de tratamento de
pedidos da camada de apresentação trata pedidos muito diferentes entre si, o que implica tratamento especializado para cada um deles
� Alguns pedidos têm tratamento imediato, enquanto outros necessitam de ser modificados ou verificados antes de serem processados
![Page 18: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/18.jpg)
18
Desenho de Software 105
Problema� É necessário haver pré- e pós-
processamento dos pedidos feitos por um cliente Web e das respectivas respostas7 O cliente foi autenticado?7 A sessão do cliente é válida?7 O tipo de browser do cliente é suportado?7 ...
Desenho de Software 106
Forças� Deve haver processamento comum a
todos os pedidos e respostas� Centralização da lógica comum� A adição e remoção dos componentes
de processamento deve ser independente
![Page 19: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/19.jpg)
19
Desenho de Software 107
Solução� Criar filtros para processar os serviços
comuns de forma que:7 Interceptem os pedidos que chegam e as
respostas que são enviadas7 Seja possível adicionar ou remover os
filtros de forma discreta sem ser necessário modificar o código já existente
Desenho de Software 108
Estrutura
![Page 20: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/20.jpg)
20
Desenho de Software 109
Colaboração
Desenho de Software 110
Participantes4 GestorFiltros
9 Gere o processamento dos filtros 9 Cria a CadeiaFiltros com os filtros apropriados, na
ordem correcta, e inicia o processamento: CadeiaFiltros
9 Conjunto ordenado de filtros independentes: Filtro1, Filtro2, Filtro3
9 Filtros individuais que são mapeados para um alvo
9 A CadeiaFiltros coordena o seu processamento: Alvo
9 Consiste no recurso pedido pelo cliente
![Page 21: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/21.jpg)
21
Desenho de Software 111
Custom Filter (1/4)� Custom Filter
7 Definido pelo programador7 Menos flexível e menos poderoso que o
Standard Filter7 Exemplos:
8 Utilização do Decorator para encapsular o processamento dos pedidos dentro dos filtros
8 Utilização de Gestor de Filtros e Cadeia de Filtros para coordenar o processamento dos filtros
Desenho de Software 112
Custom Filter (2/4)9 Exemplo – Utilização do Decorator
; Problema; Se alterarmos a forma de tratar o pedido, tem que se
alterar também o código dos filtros e do processamento principal
![Page 22: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/22.jpg)
22
Desenho de Software 113
Custom Filter (3/4)9 Exemplo – Utilização do Decorator
Desenho de Software 114
Custom Filter (3/4)9 Exemplo – Utilização de Gestor e Cadeia de Filtros
; Problema; Filtros adicionados ou removidos programaticamente
![Page 23: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/23.jpg)
23
Desenho de Software 115
Standard Filter (1/2)� Standard Filter
9 Os filtros são controlados declarativamente, utilizando um ficheiro de configuração; Este ficheiro inclui o mapeamento dos filtros para URL’s
específicos; Quando um cliente faz um pedido a que corresponde
aquele URL mapeado, os filtros são processados por ordem antes que o alvo do pedido seja invocado
<filter> <filter-name> StandardEncodeFilter </filter-name>...
</filter>...
<filter-mapping><filter-name> StandardEncodeFilter </filter-name><url-pattern> /EncodeTestServlet </url-pattern>
</filter-mapping>
Desenho de Software 116
Standard Filter (2/2)
![Page 24: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/24.jpg)
24
Desenho de Software 117
Intercepting Filter: Os filtros em geral não alteram o fluxo
de execução
Desenho de Software 118
Intercepting Filter: Filtro com alteração do fluxo de Execução
![Page 25: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/25.jpg)
25
Desenho de Software 119
Outras Estratégias� Base Filter
7 Superclasse comum a todos os filtros utilizados
7 Partilhada por todos os filtros7 Encapsula funcionalidades comuns
� Template Filter7 Base Filter que contém uma estrutura fixa
a que todos os filtros têm que obedecer7 Cada subclasse filtro implementa a sua
funcionalidade para essa estrutura
Desenho de Software 120
Consequências� Centraliza o controlo com fraca ligação
entre filtros� Promove a reutilização� Configuração independente e
declarativa� A partilha de informação é ineficiente
![Page 26: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/26.jpg)
26
Desenho de Software 121
Padrão Adapter� Permite ultrapassar incompatibilidades
entre interfaces � Converte a interface de uma classe
noutra interface (esperada pelos clientes)
� Existem dois tipos de adaptadores: de classes e de objectos
Desenho de Software 122
Padrão Adapter� Adaptador de Objectos (composição)
![Page 27: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/27.jpg)
27
Desenho de Software 123
Padrão Adapter� Adaptador de Classes (herança)
Java não permite herança multipla
Desenho de Software 124
Padrão Composite� Permite compor objectos em estruturas� Trata objectos individuais e objectos
estruturados uniformemente� Em geral são usados para representar
estruturas de dados recursivas
![Page 28: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/28.jpg)
28
Desenho de Software 125
Padrão Composite
Desenho de Software 126
Padrão Arquitectural MVC
![Page 29: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/29.jpg)
29
Desenho de Software 127
Padrão Arquitectural MVC: O padrão arquitectural Modelo-Vista-
Controlador (MVC) divide uma aplicação interactiva em três componentes: modelo, vista e controlador9 O modelo contém o núcleo da funcionalidade e
dos dados9 As vistas mostram a informação ao utilizador9 Os controladores tratam das entradas dos
utilizadoresAs vistas e os controladores formam a interface. Um mecanismo de propagação das alterações assegura a coerência entre a interface utilizador e o modelo
Desenho de Software 128
Exemplo
![Page 30: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/30.jpg)
30
Desenho de Software 129
Problema: As interfaces utilizador são muito passíveis
de sofrerem pedidos de alteração : Diferentes utilizadores têm requisitos
diferentes, e por vezes conflituosos, sobre como deve ser a interface utilizador
: Um sistema que satisfaça os requisitos acima deve permitir:< A mesma informação ser apresentada de forma diferente
em distintas janelas< A visualização e comportamento da aplicação reflecte
imediatamente as alterações aos dados< Alterações à interface são fáceis e possíveis em tempo de
execução< O suporte de diferentes look and feel não deve afectar o
núcleo da aplicação
Desenho de Software 130
Solução: Existem três tipos de componentes: modelo,
vista e controlador< O modelo encapsula o cerne dos dados e da funcionalidade,
é independente das representações de saída e do comportamento associado às entradas
< A vista mostra os dados ao utilizador, obtém os dados do modelo e permite a existência diferentes vistas do modelo
< O controlador recebe os eventos de entrada que converte para pedidos de serviços ao modelo e às vistas
: A separação entre o modelo a vista e o controlador permite múltiplas vistas do mesmo modelo
![Page 31: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/31.jpg)
31
Desenho de Software 131
Estrutura
=?>#@BA#C
coreData : undefined
attach()detach()notify()getData()service()
D�EBF A!G HIA#G
update()
J�K AML
initialize()makeController()activate()display()update()
N >BOQP GR>BC C A#G
initialize()handleEvent()update()
update()
initialize()makeController()activate()display()update()
initialize()handleEvent()update()
coreData : undefined
attach()detach()notify()getData()service()
1 *
1 0..1
Desenho de Software 132
Dinâmica: Propagação:C o n t r o lle r :M o d e l :V ie w
h a n d le E v e n t
s e r v ic e
n o t i f y
u p d a t e
g e t D a t a
u p d a t e
g e t D a t a
![Page 32: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/32.jpg)
32
Desenho de Software 133
Dinâmica: Inicialização:M o d e l
:V i e w
: C o n t r o l l e r
m a in p r o g r a m :
c r e a t e
c r e a t e
i n i t ia l iz e
a t t a c h
m a k e C o n t r o l l e rc r e a t e
in i t ia l i z e
a t t a c h
s t a r t E v e n t P r o c e s s in g
Desenho de Software 134
Exemplo (1/2)
![Page 33: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/33.jpg)
33
Desenho de Software 135
Exemplo (2/2)
Desenho de Software 136
ConsequênciasS Vantagens
< Múltiplas vistas do mesmo modelo< Sincronização das vistas< Troca dinâmica de vistas e controladores < Alteração do look and feel< Potencial para moldura de objectos
S Desvantagens< Aumento da complexidade< Possível excesso do número de propagação de alterações< Ligação forte entre as vistas e os respectivos controladores< Ligação forte das vistas e controladores com o modelo< Ineficiência dos acessos aos modelos por parte dados das
vistas< Alteração da vista e do controlador quando é necessário
portar
![Page 34: Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do Aberto/Fechado 1 Um sistema não pode ter todos os módulos estáveis 1 Um módulo deve](https://reader031.vdocuments.com.br/reader031/viewer/2022022715/5c10e5f609d3f2126b8d2367/html5/thumbnails/34.jpg)
34
Desenho de Software 137
Exemplo
InterfaceDocente
ServidorAlunoInterfaceAluno
ServidorDocente
Dominio ServidorDados