6.170 Revisão para a Prova

Transcrição

1 6.170 Revisão para a Prova Tópicos: 1. Desacoplamento 2. Abstração de dados 3. Funções de Abstração e Invariantes de Representação 4. Abstração de Iteração & Iteradores 5. Modelos de Objeto e Invariantes 6. Igualdade, Cópia e Visões Padrões de Projeto 9. Subtipagem 10. Estudos de Casos Desacoplamento Aula 2, Aula 3, Capítulo 1, Capítulo 13:1-3, Capítulo 2 Decomposição DivisãodoTrabalho Reuso Análise Modular Alteração Localizada Projeto Top Down vs. Modularização Desacoplamento Aula 2: Usos, Dependências, Especificações, MDDs Diagrama de Usos: Árvores, Camadas, Ciclos Raciocínio Reuso Ordem de Construção Dependências & Especificações; Módulos de Diagrama de Dependência para o Suposições em Menor Número e Menos Sérias o Avaliando Alterações

2 o o Comunicação Implementações Múltiplas Desacoplamento Aula 2: MDDs, Técnicas MDDs o Partes de especificação o Partes de implementação o Satisfaz, depende, relacionamentos de dependência fraca Técnicas o Façade: uma nova parte de implementação entre dois conjuntos de partes o Escondendo a representação: evite mencionar como os dados são representados o Polimorfismo: muitas formas o Callbacks: resolução de referências a procedimentos em tempo de execução Desacoplamento Aula 3: Java Namespace, Controle de Acesso Java Namespace o Packages {Interfaces, Classes} {métodos, nomes de campos} Controle de Acesso o public: acesso de qualquer lugar o protected: acessado de dentro do pacote ou por subclasses de fora do pacote o padrão: acessado de dentro do pacote o private: apenas de dentro da própria classe Desacoplamento Aula 3: Linguagens Seguras, Interfaces Linguagens Seguras o Uma parte só deve depender de outra se o fizer explicitamente referenciando a outra parte o Tipagem Forte: acesso ao tipo t no programa texto é garantido em tempo de execução o Checagem de tipos em tempo de compilação: static typing Interfaces: subtipagem mais flexível o Expressa especificação pura o Permite várias partes de especificação em uma parte de implementação Desacoplamento

3 Aula 3: Instrumentação de um Programa Abstração por Parametrização Desacoplamento com Interfaces Interfaces vs. Classes Abstratas Campos estáticos Aula 4, Aula 5, Capítulo 3-5, Capítulo 9 Especificações o Pré-condição (requires) Obrigação sobre o cliente (aquele que invoca o método) Se for omitido: true; não requer nada o Pós-condição (effects) Obrigação sobre o desenvolvedor Não pode ser omitido o Condição Estrutural (modified) Descreve todos os estados alterados Se for omitido: não modifica nada Aula 4: Especificação Especificação Operacional: uma série de passos realizados pelo método Especificação Declarativa: não fornece detalhes dos passos intermediários (preferivelmente) Exceções & Pré-condições (decisões) o Pré-condições: custo da checagem, escopo do método o Checagem através de certificações em tempo de execução o Se violada, jogar exceção (não mencionada na especificação) Aula 4: Especificações Macetes o Returns: não modifica nada, e retorna um valor o Throws: condição e exceção, ambos, fornecidos na cláusula throws; não modifica

4 nada Ordem de Especificação: uma especificação A é tão rígida quanto uma especificação B se: o A pré-condição de A nãoétãorígidaquantoadeb o A pós-condição de A não é menos rígida do que a de B, para os estados que satisfazem a pré-condição de B o (é sempre possível tornar a pré-condição menos rígida; e sempre possível tornar a pós-condição mais rígida) Aula 4: Especificações Julgando especificações o Coerente o Informativa o Rígida o suficiente o Não rígida o suficiente Firewall crucial entre implementador e cliente Aula 5: Tipos Abstratos : o tipo é caracterizado pelas operações que você pode realizar sobre ele Mutáveis: podem ser alterados; fornecem operações que quando executadas fazem com que os resultados de outras operações sobre o mesmo objeto sejam diferentes (Vectors) Imutáveis: não podem ser alterados (Strings) Aula 5: tipos abstratos Operações (T = tipo abstrato, t = algum outro tipo) Construtores: t -> T Produtores: T, t -> T Modificadores: T, t -> void Observadores: T, t -> t Exemplo: listas

5 Aula 5: tipos abstratos Projetando um tipo abstrato Poucas operações simples que podem ser combinadas de maneiras poderosas As operações devem ter propósitos bem definidos, comportamento coerente A definição das operações deve ser adequada O tipo pode ser genérico (lista, conjunto, grafo) ou específico de domínio (mapa de estrada, o banco de dados de empregados, a agenda de telefones), mas não os dois ao mesmo tempo Aula 5: Tipos Abstratos Representação: a classe que implementa o tipo abstrato fornece uma representação Independência de representação Garantindo que um tipo abstrato é independente de representação Alterações na representação não devem afetar a utilização do código Exposição de representação A representação é passada para o cliente Permite-se acesso direto do cliente à representação Necessita de uma cuidadosa disciplina de programação Aula 5: Tipos Abstratos Mecanismos de linguagem Campos private: previnem o acesso à representação Interfaces: independência de representação Interfaces: independência de representação (List -> ArrayList, LinkedList) o Campos não estáticos não são permitidos o Não podem ter construtores Aula 6: Funções de Abstração & Invariantes Rep Invariante Rep (IR) Restriçãoquecaracterizaseumainterfacedeumtipoabstratodedadosestábemformada ou não (do ponto de vista da representação) IR: Object -> Boolean Algumas propriedades do modelo de objeto não estão na IR Algumas propriedades do IR não estão no modelo de objeto (primitivas, por exemplo)

6 Aula 6: Funções de Abstração & Invariantes Rep Raciocínio indutivo Invariante Rep: torna o raciocínio modular possível Os métodos construtores criam um objeto que satisfaz a invariante Os métodos produtores preservam a invariante Os métodos modificadores mantêm a invariante Rep Os métodos observadores não realizam alterações, portanto, a invariante é mantida Aula 6: Funções de Abstração & Invariantes Rep Função de Abstração: interpreta a representação Objetos concretos: verdadeiros objetos da implementação Objetos abstratos: objetos matemáticos que correspondem à forma como a especificação do tipo abstrato define seus valores Função de abstração: função entre os domínios concreto e abstrato Pode ser parcial Diferentes representações possuem diferentes funções de abstração Aula 6: Funções de Abstração & Invariantes Rep Efeitos colaterais benevolentes: permitem que os métodos observadores alterem a representação desde que os valores abstratos sejam preservados IRs: o Raciocínio modular o Ajuda a identificar erros Função de abstração: especifica como a representação de um tipo abstrato de dados é interpretada como um valor abstrato Aula 7: Abstração de iteração e iteradores Exposição de representação: faça com que o método remove() jogue UnsupportedOperationException Refira-se ao capítulo 6 do texto

7 Modelos de Objetos & Invariantes Aula 8, Capítulo 12:1 Modelo de objeto: descrição de uma coleção de configurações Classificação de objetos Relacionamentos entre objetos Subconjuntos (implementa, estende) Relacionamentos e rótulos Multiplicidade: como muitos objetos em uma classe podem estar relacionados com um determinadoobjetoemoutraclasse Capacidade de alteração: como os estados podem ser alterados Modelos de Objetos & Invariantes Símbolos de multiplicidade: o (>= 0) o +(>=1) o?(0or1) o!(exactly1) Source -> Target o Final da flecha: quantos alvos (objetos no final da flecha) estão associados com cada fonte (objeto no início da flecha)? o Início da flecha: quantas fontes podem ser mapeadas para o alvo? Diagramas de instância Modelos de Objetos & Invariantes Modelos de Objetos de Programas Pontos de vista abstratos e concretos o Função de abstração: pode demonstrar como os valores concretos são interpretados como valores abstratos o Invariante de Representação: os modelos de objeto são um tipo de IR - uma restriçãoválidadurantetodaaexistênciadoprograma o Exposição de representação: um tipo abstrato de dados fornece acesso direto a um dos objetos abrangidos pelo contorno de abrangência da invariante de representação Igualdade, Cópia e Visões Aula 9, Ch5:5-7 O contrato da classe Object o equals() o hashcode()

8 Propriedades da igualdade (Point e ColorPoint) o Reflexiva o Simétrica o Transitiva Hashing: se dois objetos são equals() -> devem ter o mesmo hashcode() Igualdade, Cópia e Visões Cópia o Raza: os campos apontam para os mesmos objetos para os quais o objeto original apontava o Profunda Interface Cloneable Igualdade entre elementos e containers o A solução de Liskov: Equals - equivalência de comportamento Similar - equivalência de observação Igualdade, Cópia e Visões Exposição de representação: o contorno inclui a classe dos elementos (LinkedList, por exemplo) o Alteração de chaves hash Visões o Objetos distintos que oferecem diferentes tipos de acesso para a estrutura de dados subjacente o Tanto a visão quanto a estrutura subjacente podem ser modificadas Aula 10, Aula 11, Chapter 10 Executando o programa e observando seu comportamento Dijkstra: "A atividade de teste pode revelar a presença de erros mas nunca sua ausência" Não se pode depender apenas da análise dinâmica - são necessárias boas especificações de projeto Aula 10: programação defensiva Diretivas o Inserção de checagens redundantes: certificações em tempo de execução

9 o o Ao passo que você escreve o código Onde? No início de um procedimento (pré-condição) No final de um procedimento complicado (pós-condição) Quando uma operação puder gerar (ou sofrer) um efeito externo Aula 10: Programação defensiva Interceptando exceções comuns o NullPointerException o ArrayIndexOutOfBoundsException o ClassCastException Checagem da invariante rep o public void repcheck() throws (runtime expn) Framework de certificação o public static void assert(boolean b, String loc) o Assert.assert(, "MyClass.myMethod"); Aula 10: Programação defensiva Certificações em subclasses Respondendo a falhas o Concerto: complicado, mais bugs, você conhece causa -> você poderia tê-la evitado? o Execute ações especiais: depende do sistema -> difícil determinar um conjunto de ações o Abandone a execução: depende do programa; compilador vs processador de texto Aula 11: A atividade de testes Considerações a respeito dos testes o Propriedades que você quer testar (domínio do problema, conhecimento do programa) o Módulos que você quer testar (críticos, complexos e propensos a mau funcionamento) o Como gerar casos de teste o Como checar os resultados o Como saber que o trabalho está terminado

10 Aula 11: Testes de regressão Suítes de teste que podem ser reexecutadas Test-first programming: construção de testes de regressão antes que o código da aplicação esteja escrito (programação extrema) Aula 11: Normas S(t, P(t)) = false; t é um caso de teste falho C: Suite, Program, Spec -> boolean C: Suite, Spec -> boolean é baseado em uma norma specification-based; black box C: Suite, Program -> boolean é baseado em uma norma program-based; glass box Aula 11: Subdomínios Subdomínios: de visões do espaço de dados de entrada o Determinam se uma suíte de testes é boa o suficiente o Guiam a atividade de testes para regiões mais propensas a bugs Subdomínios reveladores Aula 11: Normas de subdomínio Statement Coverage: toda sentença deve ser executada pelo menos uma vez Decision Coverage: toda as extremidades do grafo do fluxo de controle devem ser executadas Condition Coverage: expressões booleanas devem ser resolvidas para true e para false, MCDC Boundary testing: testes extremos para expressões condicionais Normas specification-based: apenas em termos de subdomínios o Conjunto vazio, não vazio e contém elemento, não vazio e não contém elemento Aula 11: Viabilidade Uma norma é viável se é possível satisfazê-la Utilize normas specification-based para guiar o desenvolvimento da suíte de testes Utilize normas program-based para avaliar as suítes de teste (o quanto do código está sendo coberto pela atividade de teste)

11 Padrões de Projeto Aula 12, Aula 13, Aula 14, Chapter 15 Até aqui: o Encapsulamento (escondendo a representação dos dados) o Subclasses (herança) o Iteração o Exceções Não utilize padrões de projeto prematuramente Complexidade diminui a capacidade de compreensão Padrões de Projeto Aula 12: Padrões de criação Factories (Usinas) o Métodos Factory: métodos que fabricam um objeto de um tipo particular o Objetos Factory: objetos que encapsulam métodos do tipo factory o Protótipo: o objeto pode clonar assim mesmo (método clone()), objeto passado através de um método (ao invés de um objeto factory) Padrões de Projeto Aula 12: Padrões de criação Compartilhamento o Singleton: existe apenas um objeto da classe o Interning: reutiliza objetos ao invés de criar novos; adequado apenas para objetos imutáveis o Flyweight: (generalização do interning), pode ser utilizado se boa parte do objeto é imutável Estados intrínsecos vs estados 'extrínsecos' Utilizado apenas caso o espaço seja o gargalo do sistema Padrões de Projeto Aula 13: Padrões comportamentais Comunicação multi-modo o Observer: mantém uma lista de Observers (que implementam uma interface específica) que devem ser notificados quando ocorrerem alterações de estado; necessita dos métodos observadores add e remove

12 o o Blackboard: (generalização do padrão observer); múltiplas fontes de dados e múltiplos visualizadores; assíncrono Repositório de mensagens que pode ser lido e escrito por todos os processos Interoperabilidade; formato de mensagem bem compreensível Mediator: (intermediário entre Observer e Blackboard); desacopla informação, mas não controle, síncrono Padrões de Projeto Aula 13: Composites (objetos compostos) de varredura Suporta muitas operações diferentes Realizam operações em subpartes de um composite Interpreter: agrupa operações de um objeto de um tipo particular Procedural agrupa todo o código que implementa uma determinada operação Visitor: varredura em profundidade em uma estrutura hierárquica; os nós aceitam Visitors; os Visitors visitam Nodes (nós) Padrões de Projeto Aula 14: Padrões estruturais Wrappers Padrão Funcionalidade Interface Adaptor Mesma Diferente (interoperabilidade) Decorator Diferente Mesma (estende) Proxy Mesma Mesma (controles ou limites) Padrões de Projeto Aula 14: Padrões estruturais Implementação de Wrappers o Subclasses o Delegação: armazena um objeto em um campo; implementação mais adequada de wrappers Composição o Permite que um cliente manipule uma unidade ou uma coleção de unidades da mesma forma

13 Subtipagem Aula 15, Capítulo 7 MDDs Princípio de substituição o Assinaturas o Métodos Requer menos/contravariância Garante mais/covariância o Propriedades Subclasses do Java vs. subtipos Interface o Garante o comportamento com aqueles que estão compartilhando o código o Herança múltipla Estudo de Caso: API de coleções do Java A hierarquia de tipos o Interfaces: Collection, Set, SortedSet, List o Implementações baseadas em estruturas hierarquias esqueléticas: AbstractCollection, AbstractSet, AbstractList, AbstractSequentialList o Implementações concretas: TreeSet, HashSet, ArrayList, LinkedList Estrutura paralela Interfaces vs classes abstratas Estudo de Caso: Java Collections API Aula 16, Capítulo 13, Capítulo 14 Métodos opcionais: throws UnsupportedOperationException Polimorfismo Implementações baseadas em hierarquias esqueléticas ('métodos template' e 'métodos hook') Capacidade, alocação, garbage collection Cópias, conversões, Wrappers Coleções ordenadas: Comparable vs. Comparator Visões Estudo de Caso: JUnit Aula 17

14 MDD: totalmente conectado Padrões do projeto o Método Template o Command o Composite o Observer Suítes de teste utilizando reflexão em Java Estudo de Caso: Tagger Aula 18 Aspectos de Projeto o Ações o Referências cruzadas o Mapas de propriedades o Numeração automática o Visão de planilhas de estilos o Enumerações Type-safe Requisitos de qualidade Densidadedepadrões Modelos de Objetos Conceituais Aula 19, Capítulo Átomo: o Indivisível o Imutável o Não interpretável Conjunto: coleção de átomos o Domínios: conjuntos que não possuem superconjuntos o Relação: determina uma relação entre dois átomos o Transposição: ~relação o Fechamento transitivo: +relação Fechamento reflexivo: *relação Relações ternárias Relações indexadas Modelos de Objetos Conceituais

15 Exemplos o Tipos do Java: Object, Var, Type o Meta modelo: notação gráfica de modelagem de objeto o Numeração: Tagger Estratégia de Projeto Aula 20 Processo de desenvolvimento o Análise de programas (modelos de objeto e operações) o Projeto (codificar modelo de objeto, diagrama de dependência modular, especificações dos módulos) o Implementação Testes o Testes de regressão o Certificações em tempo de execução o Invariantes de representação Estratégia de Projeto Propriedades de projeto Capacidade de extensão o Suficiência sobre modelos de objeto o Localidade e desacoplamento Confiabilidade o Modelagem cuidadosa o Revisão, análise, testes Eficiência o Modelo de objeto o Não seja tendencioso o Otimização o Escolha das representações Estratégia de Projeto Transformações de modelos de objetos Introduzindo uma generalização (subconjuntos) Inserindo uma coleção Invertendo um relacionamento Movendo um relacionamento Tabela de relacionamentos

16 Adicionando estados redundantes Decompondo relacionamentos mutáveis Interpolando uma interface Eliminando conjuntos dinâmicos