Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do...

1

Desenho de Software 71

Aperfeiçoamento do Desenho� Desenho por contrato� Protótipos de desenho


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, ...

2


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


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

3


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 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)

��

4


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


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

5


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


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

6


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


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

7


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


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 ...

8


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


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

9


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


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.

10


Padrão Data Access Object� &RQWH[WR

7 Acesso aos dados depende da fonte dos dados8 tipo de armazenamento8 implementação do vendedor


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

11


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


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

12


Estrutura


Participantes e Colaborações

13


Estratégia� Factory Method


Estratégia� Abstract Factory e Factory Method

14


Estratégia


Código: Fábrica Abstractapackage ServidorPersistente;

public interface ISuportePersistente {

public void iniciarTransaccao()

throws ExcepcaoPersistencia;

public void confirmarTransaccao()


public void cancelarTransaccao()


public IItemPersistente

getIItemPersistente();

public ISeccaoPersistente

getISeccaoPersistente();

public ISitioPersistente

getISitioPersistente();

}

15


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(); }

}


Código: Interface DAOpackage ServidorPersistente;

import Dominio.ISitio;

public interface ISitioPersistente {

ISitio readByNome(String nome)


void write(ISitio sitio)


void delete(ISitio sitio)


void deleteAll()


}

16


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);

}

}


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

...

}

17


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


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

18


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 ...


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

19


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


Estrutura

20


Colaboração


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

21


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


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

22


Custom Filter (3/4)9 Exemplo – Utilização do Decorator


Custom Filter (3/4)9 Exemplo – Utilização de Gestor e Cadeia de Filtros

; Problema; Filtros adicionados ou removidos programaticamente

23


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>


Standard Filter (2/2)

24


Intercepting Filter: Os filtros em geral não alteram o fluxo

de execução


Intercepting Filter: Filtro com alteração do fluxo de Execução

25


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


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

26


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


Padrão Adapter� Adaptador de Objectos (composição)

27


Padrão Adapter� Adaptador de Classes (herança)

Java não permite herança multipla


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

28


Padrão Composite


Padrão Arquitectural MVC

29


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


Exemplo

30


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


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

31


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


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

32


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


Exemplo (1/2)

33


Exemplo (2/2)


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

34


Exemplo

InterfaceDocente

ServidorAlunoInterfaceAluno

ServidorDocente

Dominio ServidorDados

Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do...

Documents

Transcript of Aperfeiçoamento do Desenho - Técnico Lisboa3-3).pdf · Métricas de Desenho Princípio do...