Aperfeiçoamento do Desenho. Desenho por Contrato

Transcrição

1 Aperfeiçoamento do Desenho Desenho por contrato Protótipos de desenho Desenho de Software 7 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,... Desenho de Software 72

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 Cliente Fornecedor Obrigações (tem que garantir pré-condição) 3DJDUELOKHWHEDJDJHP (tem que garantir pós-condição) /HYDURFOLHQWHDRGHVWLQR Benifícios (vai beneficiar da pós-condição) &KHJDUDRGHVWLQR (pode assumir pré-condição) %LOKHWHIRLSDJR Desenho de Software 73 Exemplo Inserção de um elemento de uma tabela Obrigações Benifícios Cliente (tem que garantir pré-condição) $WDEHODQmRHVWiFKHLD HDFKDYHGHDFHVVR QmRpDVWULQJYD]LD (vai beneficiar da pós-condição) $WDEHODpDFWXDOL]DGD FRPRQRYRHOHPHQWRHD FKDYHGDGD Fornecedor (tem que garantir pós-condição) $FWXDOL]DDWDEHODFRP RQRYRHOHPHQWR (pode assumir pré-condição) 6HDWDEHODHVWiFKHLD RXDFKDYHpDVWULQJ YD]LDQmRpQHFHVViULR ID]HUQDGD Desenho de Software 74 2

3 Desenho por Contrato Exemplo Eiffel [ Meyer992] 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 + 0 = count count = capacity Desenho de Software 75 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 =.05 * capacity) Desenho de Software 76 3

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 Desenho de Software 77 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: Validação Matemática pode ser difícil mas muito útil para alguns aspectos críticos Métricas de Desenho permitem quantificar a qualidade Comparação de Desenhos para avaliar os compromissos Desenho de Software 78 4

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 Refinamento 3 No inicio considera-se uma abstração do sistema 3 Em cada refinamento são adicionados detalhes 3 No final é gerado código C+ + ou Java Desenho de Software 79 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= indica instabilidade do módulo Desenho de Software 80 5

6 Métricas de Desenho Princípio do Aberto/Fechado Um sistema não pode ter todos os módulos estáveis Um módulo deve ser aberto à extensão e fechado à modificação 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: 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= que é abstracto Desenho de Software 8 Métricas de Desenho Relacionamento entre a medida de abstracção e a instabilidade de um modulo: A = e I = 0 A = 0 e I = A = 0 e I = 0 A = e I = abstracção (0,) sequência principal (,0) A = 0.5 e I = 0.5 instabilidade Desenho de Software 82 6

7 Métricas de Desenho É desejável que os módulos estejam próximos da sequência principal Distância (D): D = (A+ I-) / 2 abstracção (0,) sequência principal (,0) instabilidade Desenho de Software 83 Comparação de Desenhos Uma especificação possibilita muitos desenhos 2 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ção 3 Facilidade de alteração do algorítmo 3 Performance 3 Facilidade na reutilização 3 Modularidade 3... Desenho de Software 84 7

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 Desenho de Software 85 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 Desenho de Software 86 8

9 Revisão do Desenho 4 Este processo tem por objectivo garantir que se está a desenvolver o sistema/programa que o cliente pretende 4 Faz-se detecção erros 4 Revisão Preliminar Clientes e utilizadores validam o desenho conceptual 4 Revisão Principal/ Crítica Analistas, desenhadores validam o desenho técnico Discutir desenhos alternativos 4 Revisão do Programa Realizada depois do desenho do sistema estar concluído, mas antes da implementação Desenho de Software 87 Casos Notáveis 5 Padrão Data Access Object 6 java.sun.com/ blueprints/ corej2eepatterns/ Patterns/ D ataaccessobject.html 5 Padrão Intercepting Filter 6 java.sun.com/ blueprints/ corej2eepatterns/ Patterns/ In terceptingfilter.html 5 Moldura de Objectos JUnit 6 Erich Gamma and Kent Beck 6 junit.sourceforge.net/ doc/ cookstour/ cookstour.htm 5 Padrão Arquitectural Modelo-Vista-Controlador 6 In Pattern-Oriented Software Architecture: A System of Patterns. Frank Buschmann et al. Desenho de Software 88 9

10 Padrão Data Access Object &RQWH[WR 7 Acesso aos dados depende da fonte dos dados 8 tipo de armazenamento 8 implementação do vendedor Desenho de Software 89 Problema 4 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 Desenho de Software 90 0

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 Desenho de Software 9 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 Desenho de Software 92

12 Estrutura Desenho de Software 93 Participantes e Colaborações Desenho de Software 94 2

13 Estratégia Factory Method Desenho de Software 95 Estratégia Abstract Factory e Factory Method Desenho de Software 96 3

14 Estratégia Desenho de Software 97 Código: Fábrica Abstracta package 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(); Desenho de Software 98 4

15 Código: Fábrica Concreta package 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 99 Código: Interface DAO package 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; } Desenho de Software 00 5

16 Código: Implementação OJB package 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 0 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... } Desenho de Software 02 6

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 Desenho de Software 03 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 Desenho de Software 04 7

18 Problema É necessário haver pré- e pósprocessamento dos pedidos feitos por um cliente Web e das respectivas respostas 7 O cliente foi autenticado? 7 A sessão do cliente é válida? 7 O tipo de browser do cliente é suportado? 7... Desenho de Software 05 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 Desenho de Software 06 8

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 enviadas 7 Seja possível adicionar ou remover os filtros de forma discreta sem ser necessário modificar o código já existente Desenho de Software 07 Estrutura Desenho de Software 08 9

20 Colaboração Desenho de Software 09 Participantes 4 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 : Filtro, 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 Desenho de Software 0 20

21 Custom Filter (/ 4) Custom Filter 7 Definido pelo programador 7 Menos flexível e menos poderoso que o Standard Filter 7 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 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 Desenho de Software 2 2

22 Custom Filter (3/ 4) 9 Exemplo Utilização do Decorator Desenho de Software 3 Custom Filter (3/ 4) 9 Exemplo Utilização de Gestor e Cadeia de Filtros ; Problema ; Filtros adicionados ou removidos programaticamente Desenho de Software 4 22

23 Standard Filter (/ 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 5 Standard Filter (2/ 2) Desenho de Software 6 23

24 Intercepting Filter : Os filtros em geral não alteram o fluxo de execução Desenho de Software 7 Intercepting Filter : Filtro com alteração do fluxo de Execução Desenho de Software 8 24

25 Outras Estratégias Base Filter 7 Superclasse comum a todos os filtros utilizados 7 Partilhada por todos os filtros 7 Encapsula funcionalidades comuns Template Filter 7 Base Filter que contém uma estrutura fixa a que todos os filtros têm que obedecer 7 Cada subclasse filtro implementa a sua funcionalidade para essa estrutura Desenho de Software 9 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 Desenho de Software 20 25

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 Desenho de Software 2 Padrão Adapter Adaptador de Objectos (composição) Desenho de Software 22 26

27 Padrão Adapter Adaptador de Classes (herança) Java não permite herança multipla Desenho de Software 23 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 Desenho de Software 24 27

28 Padrão Composite Desenho de Software 25 Padrão Arquitectural MVC Desenho de Software 26 28

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 controlador 9 O modelo contém o núcleo da funcionalidade e dos dados 9 As vistas mostram a informação ao utilizador 9 Os controladores tratam das entradas dos utilizadores As 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 27 Exemplo Desenho de Software 28 29

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 Desenho de Software 29 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 Desenho de Software 30 30

31 N Estrutura * DEBF A!G HIA#G coredata : undefined attach() detach() notify() getdata() service() J K AML update() 0.. >BOQP GR>BC C A#G initialize() makecontroller() activate() display() update() initialize() handleevent() update() Desenho de Software 3 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 if 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 Desenho de Software 32 3

32 m a in p r o g r a m : Dinâmica: Inicialização c r e a t e :M o d e l c r e a t e :V i e w i n it ia l iz e a t t a c h m a k e C o n t r o ll e r c r e a t e : C o n t r o ll e r in i t ia li 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 33 Exemplo (/ 2) Desenho de Software 34 32

33 S S Exemplo (2/ 2) Desenho de Software 35 Consequências 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 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 Desenho de Software 36 33

34 Exemplo InterfaceDocente ServidorDocente Dominio ServidorDados InterfaceAluno ServidorAluno Desenho de Software 37 34