Programação Modular

Índice de Aulas

1. Aug 2 - Introdução - Fatores de qualidade de software
2. Aug 4 - Introdução à linguagem Java
3. Aug 9 - Estudo de caso - Fatorando números inteiros
4. Aug 11 - Introdução a tipos abstratos de dados
5. Aug 16 - TADs em Java
6. Aug 18 - Introdução à programação orientada por objetos
7. Aug 23 - UML - Diagramas de classes e de estados.
8. Aug 25 - Polimorfismo paramétrico em Java
9. Aug 30 - Introdução à estruturas de dados
10. Sep 1 - Princípios de projeto de classes (OCP e LSP)
11. Sep 08 - Princípios de projeto de classes (ISP e IDP)
12. Sep 13 - Princípios da coesão de pacotes
Sep 15 - Primeiro debate: o que é um bom programador
Sep 20 - Aula de revisão
Sep 22 - Primeira avaliação
13. Oct 4 - Padrões de projeto: Composite, Builder, Flyweight
14. Oct 6 - Padrões de projeto: Visitors, Factory, Singleton
15. Oct 13 - Implementação de linguages orientadas por objetos
16. Oct 18 - Tratamento de exceções em Java
17. Oct 20 - Programação multi-thread em Java
18. Oct 25 - Invocação remota de métodos em Java
19. Oct 27 - Reúso via Funções de Alta Ordem
20. Nov 3 - Inversão de controle
21. Nov 8 - Desenvolvimento Ágil
22. Nov 10 - Metodologias de teste de software
23. Nov 17 - Gerenciamento de memória e coleta de lixo
24. Nov 22 - POO em linguagens dinâmicas
Nov 24 - Anti-padrões de projeto
Nov 29 - Aula de revisão
Dec 1 - Segunda avaliação

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: procure lembrar a cor dos olhos de alguém que você ama. Se não conseguir, repare melhor da próxima vez.

Conceitos que devem ser entendidos.

• A noção de qualidade de Software é subjetiva.
• Existem fatores de qualidade externos, isto é, que interagem diretamente com o usuário, e fatores de qualidade internos, com os quais os programadores devem interagir.
• Bertrand Meyer enumera alguns fatores de qualidade em seu livro.
  Fatores externos:
  1. Corretude
  2. Robustez
  3. Extensibilidade
  4. Reusabilidade
  5. Compatibilidade
  6. Eficiência
  7. Portabilidade
  8. Facilidade de uso
  9. Funcionalidade
  10. Pontualidade
  11. Segurança
  Fatores internos:
  1. Legibilidade
  • Documentação
  • Padronização
  • Conscisão
  • Fatoração
  2. Modularidade
• Existe um padrão internacional para avaliação de qualidade de software, o padrão ISO 9126. Este padrão agrupa os fatores de qualidade nas seguintes categorias:
  • Funcionalidade
  • Confiabilidade
  • Usabilidade
  • Eficiência
  • Manutenabilidade
  • Portabilidade
• Problemas de software podem ser classificados como defeitos ou não-conformidades.

Questões para discutir

• Como mensurar a qualidade de um programa?
• Caso fosse necessário priorizar entre os diferentes fatores de qualidade, quais seriam suas prioridades?

Leitura

• Capítulo 1 do livro de Bertrand Meyer.
• Software Quality.
• ISO 9126

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: escreva uma carta para quem quer que tenha pintado o miolo das margaridas de amarelo.

Conceitos que devem ser entendidos.

• Linguagens Imperativas
  • Referências
  • Comandos e iterações
  • Efeitos colaterais (Side Effects)
• Orientação por objetos
  • Objetos sabem como executar ações em si mesmos
• Expressões, comandos, classes e pacotes.
• Máquinas virtuais

Questões para discutir

• Por que Java obteve tanto sucesso ao longo de sua história?
• Quais as vantagens e desvantagens de máquinas virtais?

Leitura

• A linguagem Java
• Um tutorial sobre Java.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: chame seus colegas para dar uma volta pelo campus. Leve uma câmera.

Conceitos que devem ser entendidos.

• Novamente: a medida da qualidade de um programa, em geral, baseia-se em critérios subjetivos.
• Uma função deveria representar um conceito, exemplo: ler dados, imprimir dados, formatar a entrada ou implementar um algoritmo bem definido.
• É possível programar para os testes, isto é, o programa é desenvolvido apenas o suficiente para passar os testes.
• Comentários devem ser explicativos, porém concisos.
• Os nomes de variáveis e classes são uma forma de documentação.
• Existem ferramentas que auxiliam o programador a padronizar o código. Um exemplo é checkstyle.

Questões para discutir

• O que é revisão colaborativa de código?
• O que é um bom programador?

Leitura

• Parte um do estudo de caso.
• Segunda parte do estudo de caso.
• Exemplos de questões de entrevistas de emprego de programação
• Boas práticas de programação em Java
• Guia de estilo Javadoc oficial da Oracle-Sun.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: enterre um tesouro.

Conceitos que devem ser entendidos.

• Um tipo de dado é um conjunto de valores mais um conjunto de operações que podem ser aplicadas sobre estes valores.
• Um TAD é um tipo de dado caracterizado pelas operações que podem ser aplicadas sobre ele, em vez dos valores que o compõe.
  • O que o TAD faz é mais importante do que como o TAD faz.
• Tipos abstratos de dados podem ser formalmente definidos a partir de quatro conceitos:
  • Tipos
  • Funções
  • Axiomas
  • Pre-condições

Questões para discutir

• Por que TADs são tão importantes para o desenvolvimento de aplicações em equipe?

Leitura

• Definição de Tipos Abstratos de Dados.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: tente tomar banho de cachoeira.

Conceitos que devem ser entendidos.

• Um tipo abstrato de dados é um tipo definido pelas operações e dados ao invés de ser definido como um conjunto de valores.
• Java provê programadores com interfaces e classes.
  • Interfaces são descrições de operações que um tipo de dados provê.
  • Classes são implementações de tipos abstratos de dados. Existem dois tipos de classes:
    • Abstratas: contém métodos sem implementação, logo, não podem ser instanciadas.
    • Concretas: contém implementação para todos os métodos
  • Classes podem ser aninhadas dentro de outras classes.
• Algumas linguagens provêem herança múltipla (mas isto traz problemas).

Questões para discutir

• Herança múltipla: bom ou ruim?
• Qual a diferença entre interfaces e classes abstratas?

Leitura

• Classes e objetos em Java.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: vá empinar papagaio (estamos na época!).

Conceitos que devem ser entendidos.

• Programação Orientada por Objetos não é exatamente um paradigma de linguagens de programação; é mais uma filosofia, um estilo de programação.
  • Visão antropomórfica de objetos: um objeto sabe como executar ações em si mesmo.
• Linguagens orientadas por objetos possuem algumas funcionalidades comuns:
  • Classes.
  • Encapsulamento.
  • Dinamic Dispatch.
  • Herança.

Questões para discutir

• Por que a programação orientada por objetos é tão popular na indústria?

Leitura

• Programação Orientada por Objetos
• POO em Java.
• POO em C. (Really!)
• Nem todo mundo gosta de POO.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: edite uma página da wikipédia. Este P.O.F. vale absurdos 0.5 pontos extra! Leia as letras miúdas do contrato.

Conceitos que devem ser entendidos.

• UML é um conjunto de diagramas usados para representar software orientado por objetos. Existem vários diagramas UML. Uma lista não exaustiva inclui:
  1. Diagramas Estruturais:
     1. Diagramas de Classe
     2. Diagramas de Componentes
     3. Diagramas de Objetos
     4. Diagramas de Pacotes
     5. Diagrama de Instalação
  2. Diagramas Comportamentais:
     1. Diagramas de Atividades
     2. Diagramas de Casos de Uso
     3. Diagramas de Sequência
     4. Diagramas de Comunicação
• Diagramas de classe são uma notação usada em UML para descrever a estrutura estática de um sistema de computação.
• Diagramas de transição de estados são usados para representar algoritmos que podem ser descritos via máquinas de estados finitos.

Questões para discutir

• Em que situações usa-se diagramas de sequência em vez de diagramas de colaboração ou vice-versa?

Slides

• Slides sobre diagramas de classe.
• Slides sobre diagramas de transição de estados.

Leitura

• Linguagem de Modelagem Unificada
• UML Class Diagrams
• Class diagram.
• Abstract state machine diagram

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: assista o debate entre os candidatos à presidência.

Conceitos que devem ser entendidos.

• Uma função é polimórfica se ela tem pelo menos dois tipos diferentes.
• Polimorfismo ad-hoc (número finito de variações):
  • Overloading
  • Coerção
• Polimorfismo universal (número potencialmente infinito de variações):
  • Polimorfismo paramétrico
  • Polimorfismo de subtipagem
• Polimorfismo Paramétrico foi introduzido em Java 1.5, como uma forma de reuso. Em Java, este tipo de polimorfismo é chamado de generics.
• generics em Java são usados de forma similar a templates em C++, porém são implementados de forma muito diferente pelo compilador.

Questões para discutir

• Quais são as limitações de tipos genéricos em Java, quando comparamos Java com outras linguagens que também apresentam polimorfismo paramétrico?

Slides

• Exercício para ser feito em aula.

Leitura

• Generics in Java
• Tipos genéricos em Java (português).
• Um exemplo de aplicação de polimorfismo paramétrico.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: de um pulinho no circo, para assistir ao espetáculo.

Conceitos que devem ser entendidos.

• Uma estrutura de dados é uma maneira de armazenar dados de forma eficiente.
• Muitos tipos abstratos de dados encapsulam estruturas de dados.
• Existem linguagens que possuem estruturas de dados como elementos nativos (built-in). Exemplos:
  • ML: listas
  • C: arranjos uni e multi-dimensionais
  • Perl: tabelas hash
  .
• Várias linguagens provêm estruturas de dados via bibliotecas. Java possui uma biblioteca chamada Java Collections.

Questões para discutir

• Quais os compromissos entre uma linguagem que oferece estruturas de dados nativas, e uma linguagem que as oferece via bibliotecas?
• O fato de muitas estruturas de dados serem oferecidas prontas em Java compromete a necessidade de estes conceitos serem ensinados em cursos de informática?

Slides

• Slides sobre estruturas de dados.

Leitura

• Wiki sobre estruturas de dados
• O tutorial de Josh Bloch sobre Java Collections.
• Programe para interfaces e não para implementações

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: convide seus colegas para assistir filme em casa de noite. Tentem dormir todos na mesma casa.

Conceitos que devem ser entendidos.

• Existem sintomas que caracterizam um projeto ruim:
  • Rigidez
  • Fragilidade
  • Imobilidade
  • Viscosidade
• Existem alguns princípios que podem ser usados para evitar os sintomas:
  • Princípio da abertura e fechamento. Um módulo deve estar aberto para extensões, porém fechado para modificações.
  • Sintomas de um projeto ruim: uso de inspeção de tipo em tempo de execução, variáveis públicas e variáveis globais.
  • Princípio da substituição de Liskov. Subclasses deveriam poder ser sempre substituídas pela classe base.
  • A falha acontece quando uma subclasse não respeita o contrato da superclasse.

Questões para discutir

• Como organizar uma entrevista de emprego para averiguar se um candidato é um bom programador?

Slides

• Slides sobre princípios de projeto de classes.

Leitura

• Design Principles and Design Patterns - Páginas 1 até 16.
• Princípio da Abertura-Fechamento
• O Princípio da Substituição de Liskov

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: leia uma estória para uma criança.

Conceitos que devem ser entendidos.

• Princípio da inversão de dependência. Dependa de interfaces, não de implementações.
• Princípio da segregação de interfaces. Muitas interfaces específicas para cada cliente são melhores que uma grande interface de propósito geral.

Questões para discutir

• Qual a diferença entre o princípio da abertura-fechamento e o princípio da inversão de dependência? Como um princípio complementa o outro?
• Como o princípio da segregação de interfaces aparece na implementação da biblioteca java.io?

Leitura

• O Princípio da Segregação de Interfaces
• O Princípio da Inversão de Dependências
• O tutorial sobre a biblioteca de entrada/saáda de Java. Olha quanta interface!
• Usando eventos em Java para prover iteração com o usuário em janelas.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: visite um museu que você ainda não conheça.

Conceitos que devem ser entendidos.

• Pacotes agrupam classes em espaços de nomes.
• Existem alguns critérios que ajudam a determinar quais classes são mantidas em quais pacotes:
  • Equivalência entre reúso e liberação. Se um pacote contém uma classe C que foi projetada para ser reusada, então o pacote contém todas as classes C' das quais C depende.
  • Princípio do reúso comum. Classes que são reusadas em conjunto em geral devem estar no mesmo pacote. Por exemplo, listas e iteradores sobre listas.
  • Princípio do Fechamento Comum. Modificações em classes de um pacote não deveriam se alastrar por classes em outros pacotes.
  • Princípio da Dependência Acíclica. O grafo de dependências entre pacotes deve ser um DAG (grafo direto acíclico).
• Estes princípios governam as inter-relações entre pacotes:
  • Princípio da Dependência Acíclica. O grafo de dependências entre pacotes deve ser um DAG (grafo direto acíclico).
  • Princípio da Dependência Estável. Dependências devem acontecer do pacote mais instável para o mais estável.
  • Princípio da Estabilidade Abstrata. Pacotes estáveis deveriam ser abstratos.
• As relações entre pacotes tendem a mudar durante o desenvolvimento do projeto de software.
• As classes em um pacote estável dependem de poucas classes de outros pacotes.
• É possível mensurar o grau de abstração em um pacote.

Questões para discutir

• Um projeto de software começa pelo projeto de pacotes ou pelo projeto de classes?

Slides

• Slides sobre princípios de projeto de pacotes.

Leitura

• Design Principles and Design Patterns - Páginas 16,17 e 18.
• Granularidade
• Pacotes em Java

1. Escolha um dos tópicos nesta planilha. Você pode saber mais sobre este tópico no blog de Robert Read. Note que Robert Read colocou estas informações também disponíveis no livro How to be a good programmer: A comprehensive Summary.
2. Prepare uma pequena apresentação (cinco minutos) sobre o tema. Você deverá fazer a sua exposição do tema em sala de aula. As exposições durarão cinco minutos no máximo. A apresentação vale três pontos.
3. Elabore um pequeno texto sobre seu tópico, e poste em nossa lista de discussão. Esta tarefa vale mais um ponto. A data limite para a postagem será o dia 8/10.
4. A participação na discussão dos colegas, seja via comentários ou perguntas, em nosso news, lhe garante mais um ponto.

Leitura

• blog de Robert Read sobre como ser um bom programador.
• Beating the Average, um artigo por Paul Graham.
• The Hacker Attitude... divertidíssimo.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: tire a tarde para andar de bicicleta.

Conceitos que devem ser entendidos.

• Padrões de projeto são soluções comuns para problemas recorrentes em projeto de software.
• Muito do jargão da área foi lançado no livro popularmente conhecido como GoF (The Gang of Four).
• Existem padrões criacionais, estruturais e comportamentais.
• Padrões criacionais procuram controlar a forma como objetos são criados em uma aplicação. Os padrões criacionais mais comuns são:
  • Abstract Factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton
• Padrões estruturais descrevem como classes e objetos podem ser combinados para formar estruturas maiores. Os padrões estruturais mais comuns são:
  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Façade
  • Flyweight
  • Proxy
• Os padrões comportamentais dizem respeito à forma como os objetos se comunicam. Os principais padrões deste tipo são:
  • Observer pattern
  • Mediator
  • Chain of Responsability
  • Template
  • Interpreter
  • Strategy
  • Visitor
  • State
  • Command
  • Iterator

Questões para discutir

• Existem desvantagens no uso de padrões de projeto?

Slides

• Slides sobre os padrões de projeto discutidos em aula.

Leitura

• Design patterns in Java
• Padrões estruturais
• Padrões comportamentais

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: vá à Casa do Baile, na Pampulha, na tardinha de sábado, assistir filme de graça. Começa às 17:00.

Conceitos que devem ser entendidos.

• Java implementa Single Dispatch, isto é, o método chamado é baseado no tipo dinâmico do objeto chamador, e no tipo estático dos parâmetros.
• É possível simular Double Dispatch em Java. Neste caso o método chamado é também determinado pelo tipo dinâmico dos parâmetros.
• O padrão visitor utiliza a simulação de double dispatch para percorrer os elementos de estruturas de dados não lineares.

Questões para discutir

• Qual o uso do padrão Visitor no projeto de compiladores?

Slides

• Slides sobre os padrões de projeto discutidos em aula.

Leitura

• Double dispatch
• Visitors

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: dê um pulinho na FALE, e pegue um dos clássicos da literatura.

Conceitos que devem ser entendidos.

• Invocação dinâmica pode ser implementada de forma eficiente via tabelas virtuais. Toda chamada envolve no máximo duas dereferências.
• Herança múltipla complica a implementação eficiente, mas há alternativas:
  • Coloração de grafos para encontrar off-sets para campos e métodos.
  • Fatoração de campos e métodos em descritores de classes, para diminuir o consumo de memória. Chamadas passam a envolver três dereferências.
• Algumas linguagens, como JavaScript, não possuem classes. Objetos são organizados via tabelas hash. Chamadas são menos eficientes, mas a flexibilidade é maior: pode-se adicionar ou remover métodos e campos de objetos.

Questões para discutir

• Até que ponto é importante conhecer a implementação de uma linguagem?

Slides

• Slides sobre as ténicas de programação vistas em aula.

Leitura

• Tabelas Virtuais.
• Herança múltipla.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: aprenda algo sobre a história de nosso país.

Conceitos que devem ser entendidos.

• Exceções são eventos anormais que podem ocorrer durante a execução de um programa.
• Mecanismos de tratamento de exceções em Java:
  • Blocos try e catch.
  • Declarações throws e classes throwable.
  • finalize.
• Exceções podem ser verificáveis (checked) ou não-verificáveis (unchecked).

Questões para discutir

• Qual é o papel de exceções em guarantir a forte tipagem de linguagens tais como Java e ML?
• Quais as vantagens e desvantagens entre exceções checked e unchecked?

Leitura

• 10 boas dicas para o tratamento de exceções.
• Tratamento de exceções em linguagens de programação.
• Exceções em Java.
• Exceções checked e unchecked.
• Asserções são uma forma de programação por contrato.
O FAQ do projeto de asserçõs é muito interessante, do ponto de vista de projeto de LPs.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: doe sangue.

Conceitos que devem ser entendidos.

• Processos: um programa ou aplicação que possui área em memória e usa recursos para realização de computações.
• Threads: linhas de execução dentro de um processo, que compartilham código e unidades de processamento. Um processo possui pelo menos uma thread.
• Cada aplicação Java possui no mínimo uma thread, mas pode possuir várias.
• Programação concorrente em Java dá-se via instâncias de Thread ou via instâncias de Executor.
• A classe Thread possui muitos métodos úteis, como interrupt, wait e join.
• A programação concorrente possui alguns problemas:
  • Condições de corrida
  • Deadlocks
  • Livelock
  • Starvation
• Condições de corrida podem ser controladas via métodos sincronizados (sincronized).
• Objetos imutáveis ajudam a evitar condições de corrida.

Questões para discutir

• Existe uma boa notação para representar programas paralelos?
• Como paralelismo é implementado em linguagens diferentes de Java?

Leitura

• Tutorial sobre Threads em Java
• Double checked lock

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: compre algo bem gostoso no supermercado, e divida com algum amigo.

Conceitos que devem ser entendidos.

• Java RMI é uma forma de programação distribuída.
• A invocação remota de métodos permite que um objeto o1 invoque métodos sobre outro objeto o2, que existe em uma máquina virtual diferente, como se o1 e o2 estivessem na mesma máquina virtual.
• Um objeto é considerado distribuído quando ele implementa a interface Remote. Métodos remotos podem disparar exceções do tipo RemoteException.
• Java RMI segue um modelo cliente/servidor: objetos clientes invocam métodos sobre objetos servidores, os quais podem ser remotos.
• O arcabouço Java RMI usa um servidor de nomes para que objetos distribuídos possam ser encontrados: java.rmi.registery. Este servidor funciona como um catálogo telefônico.
• Objetos que são passados como parâmetro ou valor de retorno remotamente devem ser serializáveis, isto é, eles precisam implementar a interface java.io.Serializable.
• Execution engines são aplicações que servem poder de processamento para clientes. Em geral estas aplicações são implementadas via o padrão de projeto command.

Questões para discutir

• Que alternativas existem para a programação distribuída?

Leitura

• Tutorial sobre Java RMI.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: chame seus amigos para jogar algum jogo de tabuleiro.

Conceitos que devem ser entendidos.

• Funções de alta ordem são aquelas que recebem outras funções como parâmetro ou as retornam como valores de retorno.
• Algumas linguagens de programação provêem esta abstração; outras, como Java, não o fazem.
• O padrão de projetos Template pode ser usado para simular funções de alta ordem.
• Outro recurso útil é o uso de classes anônimas.
• Mapas e reduções permitem a implementação de algoritmos paralelos eficientes.

Questões para discutir

• Em que outras situações templates seriam úteis? Pensemos em outros algoritmos que podem ser parametrizados.

Slides

• Slides sobre as ténicas de programação vistas em aula.

Leitura

• Higher-order functions
• The template design pattern
• Anonymous classes in Java
• JUnit in Eclipse

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: leve alguém ao teatro.

Conceitos que devem ser entendidos.

• Uma biblioteca é um conjunto de módulos que provêm funções que podem ser chamadas por um cliente.
• Um framework, ou arcabouço, é o esqueleto de uma aplicação. Clientes do arcabouço provêm módulos cujos métodos são invocados dentro do arcabouço.
• A inversão de controle baseia-se no chamado princípio de Hollywood, cujo moto é "Não nos ligue, nós ligaremos para você".
• Frameworks amarram componentes juntos. Componentes são módulos que podem ser utilizados por terceiros sem quaisquer modificações.
• O objeto que define como os vários componentes de um arcabouço estarão conectados é um injetor de dependências.
• Uma forma de implementar inversão de controle é via localizadores de serviço, como rmi.registry por exemplo.

Questões para discutir

• Quais as vantagens e desvantagens relativas entre o injeção de dependências e os localizadores de serviços?

Leitura

• Este é um capítulo de livro, em português, de vários autores, sobre IoC O livro chama-se Arquitetura e Design de Software.
• Inversão de controle, Artigo de Martin Folower traduzido para Português.
• O princípio de Hollywood.
• The Single Responsibility Principle.
• Injeção de dependência.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: procure visitar alguma associação de caridade em que você possa participar.

Conceitos que devem ser entendidos.

• Requisitos tendem a mudar durante o desenvolvimento de Software, e desenvolvedores precisam saber se adaptar a estas mudanças.
• Desenvolvimento ágil pressupõem liberações constantes de software.
• Uma das modalidades de desenvolvimento ágil conhecida como Extreme Programming se caracteriza por testes sendo programados antes do código ter sido terminado.
• Encontros face-a-face são muito importantes para o desenvolvimento ágil.

Questões para discutir

• Quando o desenvolvimento ágil passa a ser um impecilho ao desenvolvimento de software?

Slides

• Slides sobre desenvolvimento ágil.

Leitura

• Um capítulo de livro on-line sobre extreme programming.
• Um exemplo de extreme programming na prática.

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: faça algo bem nerd.

Conceitos que devem ser entendidos.

• Há três formas básicas de remover bugs:
  • Verificação formal: prova-se via um provador de teoremas, que o programa é correto.
  • Validação da tradução: prova-se que a saída gerada pelo programa, para uma entrada particular, é correta.
  • Testes: usa-se testes para mostrar que o programa atende alguns dos seus requisitos.
• Quando testes devem ser realizados?
  • Normalmente testes de unidade são realizados após a implementação da unidade de software que deve ser testada.
  • TDD - Test Driven Development é um método de desenvolvimento de software em que, a cada ciclo de desenvolvimente, testes são escritos primeiro, e o programa é codificado para passar nestes testes.
• No melhor dos mundos, testes são escritos em conjunto com o programa. Quando o programa é modificado, ele deve continuar passando todos os testes.
• Testes unitários são rápidos, não dependem do ambiente para serem executados e precisam ser executados automaticamente:
  • Não falam com o banco de dados
  • Não utilizam rede
  • Não lêem ou escrevem em arquivos
  • Podem rodar ao mesmo tempo que outros testes
  • etc
• Podemos usar jUnit para realizar testes unitários.

Questões para discutir

• Há situações em que é mais difícil escrever os testes antes do programa propriamente dito?

Slides

• Slides sobre metodologias de teste de software.

Leitura

• Test Driven Development

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: pegue uma das cartinhas do Natal Solidário e tente atender ao pedido.

Conceitos que devem ser entendidos.

• Existem linguagens, como C ou C++, em que o programador é responsável por controlar a alocação e desalocação de memória. A alocação manual deixa margem para erros:
  • Memory Leaks: memória é alocada, mas não é liberada.
  • Dangling pointers: uso de área de memória que já foi liberada.
• Usos incorretos de memória podem ser identificados usando-se depuradores como Valgrind.
• Existem também linguagens que cuidam da memória para o programador. Java é um exemplo. Tais linguagens utilizam sistemas de coleta de lixo. Há vários algoritmos de coleta de lixo:
  • Marcação e varredura: acontece em duas fases. Primeiro percorre-se o grafo de nodos alcancáveis do heap, marcando-se cada um deles. Depois libera-se os nodos que não foram marcados.
  • Contagem de referências: adiciona-se um contador a cada referência de memória. Sempre que o nodo é referenciado, seu contador é incrementado. Quando o nodo deixa de ser referenciado por algum ponteiro, seu contador é decrementado. Chegando-se o contador a zero, libera-se a região para a lista de blocos livres.
  • Coleta de cópias: divide-se a memória em duas partes. Aloca-se dados em uma delas. Quando esta está cheia, copia-se todos os dados para a outra área, e alternam-se os papéis das áreas.

Questões para discutir

• Hoje, quando os computadores têm muita memória disponível, ainda é importante liberar a memória consumida? Afinal, quando o programa terminar, a memória que ele utilizou será recuperada pelo SO...

Slides

• Alguns slides para esta aula.

Leitura

• Smart-pointers.
• Diversas técnicas de Gerenciamento de memória
• Coleta de Lixo
• Valgrind

• Notas e exemplos vistos em aula.
• Exercícios.
• P.O.F.: visite um lugar onde você possa gritar bem algo, e grite. Dica: o alto da Serra do Curral, ou um show de Heavy Metal.

Conceitos que devem ser entendidos.

• Normalmente linguagens dinâmicas apresentam as seguintes características:
  • Interpretação dinâmica: a linguagem permite a execuçcão de código carregado dinamicamente, via funções como o eval de Perl, por exemplo.
  • Tipagem dinâmica: a linguagem faz verificação de tipos em tempo de execução do programa.
  • Gerência automática de memória: normalmente a linguagem usa um sistema de coleta de lixo para controlar o uso de memória. Logo, não há necessidade de um comando para liberar a memória.
• Lua é uma linguagem dinâmica criada na PUC-Rio. Esta linguagem já ocupou a posição 17 na escala de popularidade do website tiobe.
• A principal estrutura de dados usada em Lua são tabelas.
• Objetos são criados muito naturalmente a partir de tabelas, pois a linguagem permite associar um nome à implementação de uma função.
• Lua não possui o conceito de classes. Objetos são clonados, em um processo normalmente conhecido como prototipagem.
• Herança pode ser simulada via o conceito de metatabelas.
• O estilo de programação de lua promove a visibilidade da implementação dos dados, em detrimento do controle de visibilidade.

Questões para discutir

• Quais as vantagens de se programar em uma linguagem como Lua, em que não existe controle de visibilidade?

Leitura

• Uma ótima introdução à linguagem Lua, escrita por Roberto Ierusalimschy, o pai da linguagem.
• Linguagens OO baseadas em prototipagem.

1. Escolha um dos tópicos nesta planilha. Eu fiz a lista a partir da página sobre anti-padrões na wikipédia. Você encontrará links para cada um destes tópicos lá. Note, entretanto, que alguns dos tópicos possuem descrição muito sucinta. É preciso que você faça uma pequena pesquisa sobre seu tema. Procure pensar em bons exemplos, que ilustrem a ocorrência do anti-padrão. Se possível, converse com programadores profissionais sobre o tópico que você escolheu.
2. Prepare uma pequena apresentação (cinco minutos) sobre o tema. Notem que somente 15 alunos serão sorteados para apresentarem seu tópico. O sorteio será feito em sala, em três rodadas. Isto quer dizer que, após a apresentação dos primeiros cinco alunos, mais cinco serão sorteados, e assim por diante. Você deverá fazer a sua exposição do tema em sala de aula, e responderá perguntas logo após. As exposições seguirão o seguinte formado: cinco minutos de apresentação, e dois minutos para responder perguntas. A apresentação vale dois pontos.
3. A participação na discussão dos colegas, seja via comentários ou perguntas, lhe garante mais um ponto. Tentaremos organizar o debate de forma tal que todos os alunos tenham a chance de fazer sua pergunta ou comentário.
4. Para este debate não é requerida a discussão pública em nossa lista. Por outro lado, iremos construir um documento compartilhado. Cada estudante, tendo sido sorteado para apresentar seu tópico ou não, deverá escrever uma pequena entrada neste documento. Eu deixei um modelo lá (Abstraction inversion). O importante aqui são exemplos. Procure encontrar mais exemplos, que complementem aqueles disponíveis na wiki. Converse com outros programadores, procure na internet, ou seja criativo e idealize seus próprios exemplos. Esta tarefa vale mais dois pontos.

Leitura

• Anti-patterns