UNIVERSIDADE FEDERAL DE SANTA CATARINA

Relatório 1: Metodologia para Ensino de Programação Orientada a Objetos com

Jogos 2D

Kaléu Caminha

Florianópolis, 2º semestre de 2012

UNIVERSIDADE FEDERAL DE SANTA CATARINA

DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA

CURSO DE SISTEMAS DE INFORMAÇÃO

Relatório 1: Metodologia para Ensino de Programação Orientada a Objetos com

Jogos 2D

Kaléu Caminha

Trabalho de Conclusão de Curso

apresentado como requisito parcial para a

obtenção de grau de Bacharel em

Sistemas de Informação.

Florianópolis, 2º semestre de 2012

Kaléu Caminha

Relatório 1: Metodologia para Ensino de Programação Orientada a Objetos com

Jogos 2D

Trabalho de Conclusão de Curso apresentado

como requisito parcial para a obtenção de grau

de Bacharel em Sistemas de Informação.

Orientador

Professor Doutor Ricardo Pereira e Silva

Banca Examinadora

Leandro José Komosinski

Patrícia Vilain

Para os avaliadores deste relatório 1

Percebi ao finalizar este primeiro relatório o grande número de páginas. Acredito que isto se deve ao alto número de ilustrações e listas

utilizados e também a um detalhamento (talvez desnecessário de laguns capítulos).

Sem dúvida visualizo que isso precisará ser corrigido para a versão final de modo que o trabalho não fique por demais extenso, solicito

ajuda para como tratar esta questão. Muito Obrigado

Sumário

Lista de Reduções.............................................................................................................................10

Resumo...............................................................................................................................................11

1 Introdução......................................................................................................................................12

1.1 Justificativa..............................................................................................................................13

1.2 Objetivo Geral..........................................................................................................................15

1.3 Objetivos Específicos..............................................................................................................15

1.4 Metodologia de Pesquisa.........................................................................................................15

2 Fundamentação Teórica................................................................................................................17

2.1 Programação Orientada a Objetos...........................................................................................17

2.1.1 Conceitos POO ...............................................................................................................18

2.1.2 Estruturas Básicas de Programação em Java...................................................................182.2 Jogos 2D..................................................................................................................................19

2.2.1 Desenho de imagens........................................................................................................202.2.2 Animações........................................................................................................................20

2.2.3 Tiles e Composição de Cenários......................................................................................202.2.4 Pontos / Plano Cartesiano................................................................................................21

2.2.5 Sprites...............................................................................................................................212.2.6 Dispositivos de Entrada ..................................................................................................21

2.2.7 Execução de sons.............................................................................................................212.2.8 Taxa de Quadros e atualização do jogo............................................................................22

2.2.9 Acumuladores de Tempo..................................................................................................222.2.10 Gravidade.......................................................................................................................22

2.2.11 Detecção e Tratamento de Colisões...............................................................................222.2.12 O Game Loop.................................................................................................................23

2.2.13 Movimentação e Gravidade nos cenários......................................................................232.3 Frameworks Orientado a Objetos............................................................................................23

2.3.1 Frameworks OO...............................................................................................................232.3.2 Metodologias de Desenvolvimento de Frameworks OO.................................................24

2.3.3 Uso de Frameworworks OO............................................................................................242.4 Padrões Pedagógicos................................................................................................................25

2.4.1 O Mais Importante Primeiro (Early Bird)........................................................................252.4.2 Espiral (Spiral).................................................................................................................26

2.4.3 Metáfora Consistente (Consistent Mataphor)..................................................................262.4.4 Caixa de Brinquedos (Toy Box).......................................................................................26

2.4.5 Caixa de Ferramentas (Tool Box)....................................................................................27

2.4.6 Disposição do território (Lay of the Land)......................................................................27

2.4.7 Corrigir para cima (Fixer Upper).....................................................................................282.4.8 Maior que a Vida (Larger than Life)................................................................................28

2.4.9 Sprint de Projeto dos Estudantes (Student Design Sprint)...............................................282.4.10 Engano (Mistake)...........................................................................................................28

2.4.11 Canal de Teste (Test Tube).............................................................................................292.4.12 Preencha as Lacunas (Fill in the Blanks).......................................................................29

2.4.13 Estrela de Ouro (Gold Star)...........................................................................................292.4.14 Avalie isto novamente Sam (Grade it again Sam)..........................................................29

3 Experiência prévia com ensino de POO e Jogos.........................................................................31

3.1 Conteúdos trabalhados.............................................................................................................31

3.2 Metodologia.............................................................................................................................33

3.2.1 Exemplo 1 – Movimentando uma bola............................................................................34

3.2.2 Exemplo 2 – Construindo o primeiro jogo.......................................................................353.2.3 Exemplo 3 – Ítens e fases.................................................................................................35

3.2.4 Exemplo 4 – Guerra Especial...........................................................................................363.2.5 – Personagens e Cenários.................................................................................................37

3.2.6 – Jogo de Luta..................................................................................................................383.2.7 – Revisão..........................................................................................................................38

3.3 Avaliação e Resultados............................................................................................................39

3.3.1 Avaliação Teórica.............................................................................................................39

3.3.2 Avaliação da Motivação...................................................................................................403.3.3 Avaliação Prática..............................................................................................................40

3.3.3.1 Grupo 1 – PowerMusic.............................................................................................403.3.3.2 Grupo 2 – Champions Fighter..................................................................................413.3.3.3 Grupo 3 – Ghomaine................................................................................................413.3.3.4 Grupo 4 – Ice Crown Citadel...................................................................................413.3.3.5 Grupo 5 – Moluscation.............................................................................................413.3.3.6 Grupo 6 – Terrorist Strategy.....................................................................................413.3.3.7 Grupo 7 – God of Worms.........................................................................................413.3.3.8 Grupo 8 – Sami Game..............................................................................................41

3.3.4 Resultado avaliação prática..............................................................................................413.3.4 Conclusão ao final do módulo.........................................................................................42

4 Ensino de Programação Orientada a Objetos............................................................................43

4.1 Metodologias para Ensino OO.................................................................................................43

4.1.1 Isaias Camilo Boratti........................................................................................................444.1.1.1 Análise Geral do Método..........................................................................................464.1.1.2 Pontos Fortes ...........................................................................................................474.1.1.3 Pontos Fracos...........................................................................................................504.1.1.4 Conclusão.................................................................................................................53

4.1.2 David J. Barnes e Michael Kölling..................................................................................53

4.1.2.1 Diretrizes .................................................................................................................56

4.1.2.2 Análise geral do método...........................................................................................584.1.2.3 Pontos fracos............................................................................................................594.1.2.4 Conclusão.................................................................................................................60

4.1.3 Bruno Feijó et al...............................................................................................................60

4.1.3.1 Análise geral do método...........................................................................................624.1.4 Stelios Xinogalos.............................................................................................................62

4.1.4.1 O Uso de ambientes de programação.......................................................................634.1.4.2 Diretrizes para o Ensino das lições propostas..........................................................644.1.4.3 Análise Geral do método..........................................................................................70

4.1.5 Michael Caspersen...........................................................................................................71

4.1.5.1 As etapas da metodologias.......................................................................................724.1.5.2 O Framework conceitual..........................................................................................734.1.5.3 O início.....................................................................................................................734.1.5.4 Padrões de Código....................................................................................................734.1.5.5 Outros elementos da metodologia............................................................................744.1.5.6 Análise Geral da Metodologia..................................................................................74

4.3 Diretrizes para o Ensino de OO .............................................................................................74

4.3.1 Princípios baseados na prática com o BlueJ....................................................................74

4.3.2 Representações visuais para todas as estruturas e conceitos trabalhados........................754.3.3 Operações de abstração e framework conceitual.............................................................75

4.3.4 Ambiente educacional + Ambiente profissional..............................................................754.3.5 Processo sistemático de desenvolvimento.......................................................................75

4.3.6 A partir do zero.................................................................................................................764.3.7 Todos os recursos usados devem ser explicados..............................................................76

4.3.8 Estilo de Código-fonte.....................................................................................................764.3.9 Lista abrangente de exercícios e desafios........................................................................76

4.3.10 Todos os exemplos devem envolver jogos.....................................................................76

5 Framework Java para Jogos 2D..................................................................................................77

5.1 Aquisição do Conhecimento de Domínio................................................................................77

5.2 Modelagem do Framework:.....................................................................................................77

5.2.1 Generalização...................................................................................................................775.2.2 Flexibilização...................................................................................................................78

5.2.3 Modelagem das Classes...................................................................................................795.3Validação...................................................................................................................................79

5.4 Documentação.........................................................................................................................79

6 Metodologia de Ensino..................................................................................................................80

6.1 Módulo 1: Objetos Primeiro....................................................................................................80

6.2 Módulo 2: Mini-Game.............................................................................................................81

6.3 Módulo 3: Jogo 2D..................................................................................................................81

6.4 Avaliação da Metodologia........................................................................................................81

7 Conclusão.......................................................................................................................................82

7.1 Trabalhos Futuros....................................................................................................................82

8 Bibliografia.....................................................................................................................................83

8.1 Livros.......................................................................................................................................83

8.2 Artigos e Documentos acadêmicos..........................................................................................83

8.3 Bibliografia para código-fonte e materiais didáticos desenvolvidos pelo autor......................84

8.4 Bibliografia Consultada...........................................................................................................85

Índice de ilustraçõesIlustração 1: Cenário baseado em Tiles..............................................................................................20Ilustração 2: Exemplo de uma Sprite..................................................................................................21Ilustração 3: Movimentando uma bola na tela....................................................................................34Ilustração 4: Exemplo mais complexo utilizando a bola criada anteriormente..................................34Ilustração 5: Tela final do jogo desenvolvido com o auxílio do roteiro.............................................35Ilustração 6: Terceira fase do exemplo com diversos itens na tela.....................................................36Ilustração 7: Versão final do jogo Guerra Espacial............................................................................37Ilustração 8: Personagem saltando sobre um inimigo representado por uma bola vermelha.............38Ilustração 9: Exemplo jogo de luta.....................................................................................................38Ilustração 10: A Construção do modelo. Fonte: Boratti.....................................................................48Ilustração 11: Representação Visual de Objetos. Fonte: Boratti. Adaptado por Kaléu Caminha.......49Ilustração 12: Implementação de Objetos. Fonte: Boratti. Adaptado por Kaléu Caminha................50Ilustração 13: Representação Visual de um Array. Fonte: Boratti. adaptado por Kaléu Caminha.....50Ilustração 14: Instanciação de objeto e chamada de método em código............................................59Ilustração 15: Objetos na bancada de objetos (em vermelho) e chamada de método de um objeto. .59Ilustração 16: Instanciação de um objeto no objectKarel com a ajuda da interface gráfica...............65Ilustração 17: Criação de uma tarefa a partir dos métodos de um robô.............................................66Ilustração 18: Execução de um programa. à direita a visualização do robô, à esquerda a lista de tarefas e abaixo a descrição do que ocorre no interior do método em execução................................66Ilustração 19: Criação sistemática de um programa orientado a objetos...........................................72

Índice de tabelasTabela 1: Conceitos POO...................................................................................................................18Tabela 2: Documentação de frameworks............................................................................................25Tabela 3: Tabela demonstrando os conteúdos trabalhados na experiência prévia com ensino de orientação a objetos baseado em jogos...............................................................................................32Tabela 4: Índice de acerto em cada um dos critérios de avaliação do jogo 2D..................................42Tabela 5: Conteúdos e Exemplos da metodologia de Boratti.............................................................46Tabela 6: Conteúdos e exemplos da metodologia de Barnes..............................................................56Tabela 7: Conteúdos e exmplos da metodologia de Feijó..................................................................62Tabela 8: Conteúdos e ambiente de programação na metodologia de Xinogalos..............................64

Lista de Reduções

POO Programação Orientada a Objetos

OO Orientação a Objetos

2D Duas dimensões

ResumoO presente trabalho busca o desenvolvimento de uma metodologia de ensino de

Programação Orientada a Objetos tendo como campo de prática os jogos em duas

dimensões. São descritas as ferramentas, o roteiro de aulas com sua respectiva carga

horária, avaliações e exercícios a serem utilizados na metodologia apresentada, bem

como um framework Java que abstrai os principais recursos específicos da plataforma e

algoritmos avançados, importantes para o desenvolvimento de jogos.

1 IntroduçãoPor volta de abril de 2011 o autor deste trabalho viveu a experiência de ensinar

Programação Orientação a Objetos para alunos entre 15 e 17 anos no curso técnico de

programação no SENAI de São José, em Santa Catarina.

Dentre muitas dificuldades, as que mais se destacaram eram a evidente

desmotivação dos alunos com o tema de programação, a dificuldade com a sintaxe e

recursos específicos do Java e a ausência de método para transformação de um

problema em um conjunto de classes que representariam sua respectiva solução.

A partir desta constatação, iniciou-se na turma do semestre seguinte uma busca por

soluções para estes problemas que culminou em duas grandes mudanças, a primeira foi a

adoção da metodologia de ensino criada por David J. Barnes e Michael Kölling utilizando

o BlueJ como ambiente de programação e no semestre seguinte, com a mesma turma,

iniciou-se um trabalho de desenvolvimento de jogos em Java a partir dos materiais

desenvolvidos por Bruno Feijó e Esteban Clua.

Ficou evidente após a aplicação destas práticas que a motivação dos estudantes

aumentou e os problemas com certas sintaxes e recursos do Java também diminuíram.

Entretanto, na análise dos trabalhos finais de desenvolvimento de jogos, ficou evidente

que para metade da turma, ainda havia um grande abismo entre o que sabiam e o

domínio prático dos principais conceitos de Programação Orientada a Objetos.

Acredita-se que a inexperiência e a falta de método do autor que acarretaram nas

dificuldades percebidas nos alunos ao final do processo de ensino aprendizagem.

E este é o ponto de partida para este trabalho, a busca por métodos, práticas,

conceitos e ferramentas que auxiliem alunos – principalmente os que possuem maiores

dificuldades com programação – a modelarem e desenvolverem softwares que

solucionem problemas com os quais eles próprios venham a se deparar no seu dia-a-dia,

deste modo, que se aprenda não apenas a desenvolver códigos orientado a objetos, mas

principalmente, conseguir “enxergar os objetos”, como bem colocado pelo professor

Ricardo Pereira e Silva na primeira reunião de orientação.

1.1 JustificativaNa Orientação a Objetos, as metodologias e ferramentas de ensino não são tão

maduras quanto nos paradigmas mais antigos como a programação estruturada e

funcional (Xinogalos), de forma que muitos professores de ciência da computação

(Xinogalos, Proulx, Caspersen, Bennedsen, Rosenberg, Kölling, Barnes, Boratti) que se

depararam diante da tarefa de ensinar orientação a objetos, iniciaram uma série de

pesquisas em busca de diretrizes, ferramentas e metodologias que norteasse essa

importante tarefa.

O autor considera, pela experiência com ensino que a grande maioria dos

exemplos didáticos em Java, mesmo em algumas metodologias recentes, trabalha com

softwares muito simples para serem interessantes ou fora da área de interesse e

conhecimento da maioria dos jovens estudantes de programação.

Um exemplo é o primeiro projeto apresentado no livro texto do ambiente BlueJ,

uma máquina de vender bilhetes de trem, algo completamente fora da realidade brasileira,

porém, mesmo que adaptássemos o projeto para, por exemplo, uma máquina de vender

café, ainda teríamos a distância do aluno entre simular uma máquina de vender café e

programar uma máquina de vender café da vida real.

Esta é a vantagem da área de jogos, é possível que o estudante crie algo com o

qual ele efetivamente poderá se divertir e além disso, a maioria dos jovens com os quais

trabalhei, aos 15 e 16 anos, já possuem um grande número de horas de experiência com

jogos, permitindo que eles tragam um conhecimento prévio para a atividade de

programação, facilitando a fixação dos conceitos com situações problema com as quais

eles já estão familiarizados.

Além desta perspectiva, o uso de jogos para o ensino de programação é um

recurso já utilizado por muitos instrutores na comunidade de educadores de ciência da

computação, não só pela sua capacidade de estimular os alunos, mas também por ser um

tipo de aplicação para o qual convergem os maiores desafios da computação (Feijó)

independente do paradigma de programação utilizado.

Porém, livros com conteúdos nesta área geralmente são complexos, utilizando

recursos das linguagens de programação que envolvem um grande número de conceitos

e regras de sintaxe, o que dificulta sua aplicação didática em sala de aula. Por exemplo,

para que seja possível desenhar uma imagem na tela (recurso essencial no

desenvolvimento de jogos) em Java é preciso conhecer conceitos complexos como

herança e sobrecarga de métodos.

A partir disto, percebe-se que o suporte ao desenvolvimento de jogos em fases

iniciais do ensino de programação exige o auxilio de ferramentas que tornem mais fácil o

desenvolvimento de recursos como uso de sons, imagens e cenários.

Duas soluções atuais foram encontradas, a primeira, um ambiente de programação

denominado Greenfoot (Kölling, 2010) desenvolvido para permitir o ensino de

programação com interação e visualização, permitindo uma inclusão rápida e fácil de

imagens, sons e posicionamento de elementos em um cenário. A segunda, é o conjunto

de bibliotecas denominado JavaLib (Proulx, 2010), cujo objetivo é permitir que o

estudante mantenha o foco no projeto do jogo, no seu comportamento e na representação

de cada cena através de formas geométricas simples. Mais recentemente a biblioteca foi

ampliada para permitir o ensino de OO através da arte de escrever e tocar músicas com

abstrações de notas e arranjos musicais.

Para este projeto, foi escolhida uma abordagem próxima a de Proulx pois como

relata Xinogalos - que utilizou e ainda utiliza o ambiente BlueJ parcialmente em sua

metodologia - é importante preparar os estudantes para serem profissionais usando

ferramentas profissionais de desenvolvimento, manter o aluno por muito tempo em

ambientes especificamente voltados para o ensino pode torná-lo por demais acostumado

aos recursos didáticos e limitadores destes ambientes, não desenvolvendo plenamente as

habilidades de programação e abstração, necessárias a um profissional.

Outro fator favorável ao uso de bibliotecas e frameworks no ensino deriva do fato

de ser muito comum no desenvolvimento de software o aprendizado de novas bibliotecas

e frameworks. Sendo necessário ao profissional de programação o domínio das

habilidades de compreensão da documentação e utilização de tais bibliotecas e

frameworks.

Observa-se também que alguns conceitos como Interfaces e classes abstratas tem

sua aplicação observada mais frequentemente em frameworks, sendo a extensão de um

framework uma possível forma de estudo de tais conceitos.

Deste modo, considera-se essencial para este trabalho o desenvolvimento de um

framework cuja responsabilidade é abstrair as funções básicas necessárias para jogos 2D

como construção de cenários, execução de sons, animações, desenho de imagens e

demais necessidades dos jogos 2D de modo que o aluno possa se concentrar, no projeto

e construção das classes e de suas interações.

A proposta da metodologia deve conter elementos de plano de aula, carga horária,

atividades práticas e avaliações de modo que possa ser reproduzida em cursos

introdutórios de Programação Orientada a Objetos com duração de 72 horas/aula.

Também é sugerida uma atividade prática de longa duração a ser desenvolvida em

laboratório com o auxílio do professor para cursos com uma carga horária mais extensa.

Por fim, justifica-se a escolha da linguagem Java em uníssono com Feijó que

caracteriza cinco vantagens para esta linguagem: 1) Permite aplicações em um grande

número de plataformas; 2) Roda em mais de um Sistema Operacional e conta com um

bom ambiente de programação gratuito (NetBeans); 3) O Java é uma linguagem

Orientada a Objetos; 4) Java é um ponto de partida para a programação para internet; e

5) A próxima geração de linguagens orientadas a objetos será uma evolução natural do

Java.

1.2 Objetivo GeralCriar uma metodologia de ensino de Orientação a Objetos através do

desenvolvimento de jogos 2D.

1.3 Objetivos Específicos• Documentar a experiência do autor com ensino de orientação a objetos baseada

em jogos anterior a este estudo;

• Apresentar e analisar algumas das principais metodologias de ensino de

programação orientada a objetos ressaltando seus pontos fortes e fracos segundo

a experiência do autor;

• Definir diretrizes para o desenvolvimento da metodologia a partir das metodologias

estudadas e da experiência anterior do autor;

• Elencar elementos pedagógicos que auxiliem a construção da metodologia;

• Construir um framework Orientado a Objetos que atenda as principais

características de jogos 2D e esteja de acordo com as diretrizes definidas;

• Documentar uma metodologia que atenda a um curso introdutório de programação

orientada a objetos de 72 horas aula;

• Definir uma atividade de longa duração a ser desenvolvida pelos estudantes em

período de aula para disciplinas cujo ano letivo seja superior à 72 horas/aula;

1.4 Metodologia de PesquisaInicia-se com a fundamentação teórica de alguns elementos considerados

essenciais ao trabalho como programação orientada a objetos, jogos em duas dimensões,

frameworks orientados a objeto e elementos pedagógicos para a ciência da computação.

Após, considera-se essencial a documentação da metodologia utilizada para o

ensino de orientação a objetos baseados em jogos 2D na experiência que deu origem ao

tema do presente trabalho, de modo que as dificuldades e pontos fortes do ensino anterior

fortaleça a nova metodologia que será desenvolvida.

Após, será realizada uma pesquisa nas metodologias para ensino de orientação a

objetos, sendo escolhidas para detalhamento as consideradas pelo autor como mais

relevantes ao desenvolvimento deste trabalho. A partir deste detalhamento serão

definidas diretrizes para o ensino de OO que deverão ser contempladas nesta

metodologia.

Com as diretrizes definidas, bem como os elementos de jogos em duas dimensões,

será proposto um framework que atenda a estes elementos.

Em seguida, é proposta a metodologia de ensino utilizando os elementos

apresentados nos capítulos anteriores. Neste ponto, o framework poderá ser revisto

diversas vezes até atingir uma versão final que suporte as diretrizes propostas.

2 Fundamentação TeóricaEste capítulo apresenta alguns elementos básicos ao trabalho sem, entretanto,

apresentar um estrutura lógica sequencial entre estes elementos, de modo que servem

como base para os demais capítulos e discussões.

2.1 Programação Orientada a ObjetosBiologia e matemática. Esta era a formação base de Alan Kay quando ele criou a

Smalltalk, reconhecida como a primeira linguagem totalmente orientada a objetos, no

famoso laboratório da Xerox PARC em Palo Alto, no final dos anos 60.

Observamos a influência desta formação em dois dos princípios iniciais que

nortearam sua pesquisa, o primeiro era que ele inicialmente pensava em objetos ”como

células biológicas e/ou computadores individuais em uma rede, apenas habilitados a se

comunicarem através de mensagens.”. O segundo, que pode ter sido uma das origens às

modernas classes, é derivado de sua raiz matemática, que lhe fez perceber que “cada

objeto poderia ter certas álgebras relacionadas a ele, e que poderiam haver famílias

destas álgebras, o que seria muito útil.”

Além disso, foi fortemente influenciado pela Sketchpad, Simula, Lisp, o projeto da

ARPAnet e a (segundo ele), quase inacreditável arquitetura dos discos rígidos B500 da

Burroughs.

Estes princípios são compatíveis com Boratti que coloca sobre o paradigma de

Programação Orientada a Objetos:

“Esse paradigma procura abordar a resolução de um problema através de uma construção que represente, da melhor forma possível, como as coisas acontecem no mundo real.

O mundo real é constituído por entidades que interagem entre si. Uma entidade pode ser definida como alguma coisa que tenha sua própria existência, características e que apresente alguma função no mundo real...uma entidade pode ser denominada objeto e, consequentemente a identificação do paradigma de programação orientada a objetos”.

Portanto Programação Orientada a Objetos corresponde um modo de programar no

qual são construídos objetos (entidades, células), pertencentes à classes, que interagem

entre si (através de mensagens) e possuem características próprias.

2.1.1 Conceitos POO

Os conceitos relacionados à POO que serão abordados pela metodologia foram

selecionados principalmente a partir da metodologia de Barnes. Para uma melhor

organização, estes foram organizados em dois níveis de dificuldade segundo a

experiência do autor:

Nível Básico Nível Avançado

• Classe;

• Métodos de acesso e métodos modificadores;

• Variáveis e Tipos;

• Notação de ponto;

• Variável de Instância / atributo;

• Objetos / Instâncias / instanciação de objetos;

• Parâmetros;

• Construtores;

• Abstração;

• Encapsulamento / Modificadores de acesso;

• Associação / Composição;

• Listas / Iteração;

• Herança / Especialização / Generalização;

• Classes abstratas;

• Interfaces;

• Polimorfismo: Variáveis polimórficas / Polimorfismo de método;

• Sobrescrita de método;

• Modificador static: contantes de classe / métodos estáticos;

• Tratamento de Erros / Try... Catch;

• Design de responsabilidade, Princípio da Responsabilidade Única;

• Coesão, acoplamento e refatoração;

Tabela 1: Conceitos POO

2.1.2 Estruturas Básicas de Programação em Java

De modo a permitir o uso desta metodologia em cursos introdutórios de

programação se faz fundamental o ensino de conceitos de determinadas estruturas

básicas de controle e de repetição. as estruturas e conceitos básicos que serão

abordadas na metodologia serão:

• Estruturas condicionais (if, else e else if);

• Estruturas de repetição (while, for);

• Arrays / Matrizes unidimensionais e bimensionais;

• Instrução de atribuição (=, +=, -=, etc);

• Variáveis Locais;

• Comentários;

• Enum;

2.2 Jogos 2DEsta seção apresenta os principais conceitos utilizados na arquitetura de jogos em

duas dimensões a partir do material desenvolvido por Perucia e que acompanha um

framework desenvolvido na linguagem de programação C++ para o desenvolvimento

destes jogos. Um jogo desenvolvido com este framework, pode apresentar, dentre outros

recursos:

• Menu principal e de opções;

• Personagem animado controlável por teclado;

• Cenários com profundidade;

• Itens especiais de jogo;

• Interação do personagem com cenário e itens;

• Inimigos e interação do personagem com estes inimigos;

• Controle de pontos de vida do personagem;

• Execução de sons;

A arquitetura de um jogo pode envolver diversos subsistemas, um jogo 2D sempre

apresentará pelo menos alguns dos subsistemas abaixo:

• Interface gráfica (menus, botões, controle, etc);

• Tratador de eventos de teclado e/ou joystick;

• Gerenciador de dados (fases, gráficos, etc);

• Gerenciador de física (velocidade, movimento, colisão, etc);

• Engine gráfica (exibição de imagens, rotação, efeitos especiais, etc);

• Engine sonora;

• Engine lógica (o coração do jogo);

• Camadas de abstração de hardware;

• Sistema de configuração do jogo (opções, nível de dificuldade, salvamento, etc);

• Sistema de menus;

• Sistema de ajuda;

• Sistema de música;

A partir de Perucia et al, dos exemplos tratados por Feijó e da experiência pessoal do

autor foram selecionados os principais conceitos envolvendo a arquitetura de jogos e que

serão indispensavelmente cobertos pelo framework que oferecerá suporte a metodologia

2.2.1 Desenho de imagens

O desenho de imagens na tela a partir de determinados arquivos-fonte é uma

operação frequente e pode ser complementada com recursos desejáveis como

transparência, rotação, aumento ou redução do tamanho original e espelhamento que

corresponde ao desenho da mesma imagem só que em posição invertida ou espelhada.

2.2.2 Animações

Animações são sequências de imagens que se alternam em função de um

determinado tempo. Em um jogo, é importante que seja possível aumentar e diminuir a

velocidade de uma animação (em casos por exemplo, da movimentação de um

personagem mais rápido ou devagar) e que assim como nas imagens, seja possível

aplicar efeitos de transparência, rotação, aumento ou redução do tamanho e

espelhamento.

2.2.3 Tiles e Composição de Cenários

“Tiles são imagens adicionadas em um cenário e divididas em pedaços iguais de

tamanho fixo” (Perucia et al). Tiles podem ser utilizados em conjunto com arquivos de

configuração para criar cenários complexos. Segue abaixo uma demonstração de

construção de um cenário baseado em Tiles.

Ilustração 1: Cenário baseado em Tiles

Na experiência de ensino de POO baseado em jogos, os alunos requisitaram em

vários momentos recursos extras associados ao uso de cenários com Tiles, como por

exemplo: que os tiles possam ser escondidos e reexibidos (para casos por exemplo onde

existam passagens secretas), que possuam tratamento de colisão com o personagem e

demais objetos do jogo e que possam também serem movimentados

2.2.4 Pontos / Plano Cartesiano

Um jogo em duas dimensões ocorre em um plano cartesiano. É importante que

existam abstrações para pontos neste plano e operações entre estes pontos como calculo

da distância e detecção de ponto mais próximo dentre um conjunto de pontos por

exemplo.

2.2.5 Sprites

“Sprites são estruturas com imagens próprias que permitem a criação de

animações e o livre posicionamento na tela” (Perucia). Uma sprite em geral é

representada por um único arquivo dividido em quadros de tamanho fixo, contendo cada

quadro uma imagem. A mesma sprite pode ser posicionada em um determinado ponto da

tela exibindo apenas um dos seus quadros internos por vez. A mudança da exibição

destes quadros ao longo do tempo resulta em uma animação.

2.2.6 Dispositivos de Entrada

A interação com o jogo irá ocorrer sempre através de um dispositivo. Os dois mais

comuns são teclado e mouse. No caso do teclado é preciso que o desenvolver tenha

disponível a informação de se uma (ou um conjunto) determinada tecla está ou não

pressionada em um determinado momento no tempo. No caso do mouse, as principais

necessidades são a posição do ponteiro do mouse e se o botão esquerdo foi pressionado.

Também é importante que exista uma interface para um joystick, ou seja, um

controle tradicional de video-game com 4 botões de ação e quatro botões direcionais.

Ilustração 2: Exemplo de uma Sprite

2.2.7 Execução de sons

Os recursos de som disponíveis para o desenvolvedor são apenas: 1)

carregamento dos arquivos de som; 2) tocar um som (com ou sem loop) e 3) parar um

som. O arquivo de áudio pode ser no formato wave, comumente usado em jogos.

2.2.8 Taxa de Quadros e atualização do jogo

Representa o número de quadros de um jogo que uma aplicação consegue

executar em um segundo. O jogo irá sempre executar uma chamada de atualização do

estado do jogo em loop. A taxa de quadros representa o número de repetições deste

quadro em um segundo.

2.2.9 Acumuladores de Tempo

É comum em jogos eletrônicos determinadas ações somente ocorrerem após um

determinado tempo. Para realizar este cálculo de tempo uma estrutura conhecida como

acumulador de tempo pode ser fornecida. Esta estrutura inicializa com o tempo que irá

controlar e, a cada atualização do jogo, deve também ser atualizada. A estrutura fornece

uma interface para que o desenvolver identifique se o fim do tempo já chegou e a

possibilidade de reiniciar o acumulador.

2.2.10 Gravidade

A gravidade pode ser representada em um jogo por um número em pixels por

segundo que representa a aceleração da gravidade. Na vida real, a força da gravidade

pode ser contrabalanceada pelo atrito com o ar. Em um jogo, ao invés de utilizar o atrito

com o ar, cada objeto recebe um número que representa a aceleração da gravidade sobre

ele. Isso permite por exemplo, que um objeto passe a ter um salto maior, simplesmente se

a força da gravidade sobre ele for diminuída.

No mundo real, existe um ponto em que o atrito com o ar se iguala a força

gravitacional de modo que a velocidade de queda permanece constante. Isto é

reproduzido em um jogo, através de uma velocidade máxima que um objeto pode receber

quando está em queda.

2.2.11 Detecção e Tratamento de Colisões

A detecção de colisões ocorre verificando se duas formas geométricas que

representam objetos do jogo, se tocam. Estas formas geométricas são comumente

retângulos e/ou círculos, e a colisão será verificada através de operações matemáticas

simples que verificam a intersecção destas formas.

Após a detecção ter ocorrido é necessário tratar a colisão. Ou seja, se o

personagem colidir com uma parede à direita, ele não poderá mais se mover para a

direita e deverá ser reposicionado para o exato momento antes da colisão.

Uma das formas de dividir este tratamento é tratando primeiro a colisão com o eixo

vertical e somente após, com o eixo horizontal.

Também é importante que o desenvolvedor tenha condições de saber para qual

direção ocorreu a colisão.

2.2.12 O Game Loop

Todo jogo de computador ocorre dentro de um laço de repetição. Este laço realiza

três operações básicas:

• Entrada: onde são verificados os comandos emitidos pelos dispositivos de entrada,

mensagens via rede, etc;

• Processamento: onde é feito o cálculo das posições dos objetos, colisão, etc;

• Desenho: onde os objetos são apresentados na tela do dispositivo.

2.2.13 Movimentação e Gravidade nos cenários

Os cenários são um dos grandes núcleos do jogo. A grande maioria dos jogos

possuem cenários grandes que podem ser percorridos por um jogador. Além disso, o

efeito da gravidade deve parar de ocorrer quando um jogador encosta no chão,

geralmente definido em função do cenário.

2.3 Frameworks Orientado a ObjetosEste capítulo disserta sobre o desenvolvimento e uso de frameworks orientados a

objetos a partir do trabalho de Silva, esclarecendo as metodologias de desenvolvimento

existentes bem como as maneiras de documentá-la de modo a proporcionar o uso

adequado dos frameworks de acordo com as diferentes necessidades dos seus usuários.

2.3.1 Frameworks OO

Frameworks Orientados a Objetos correspondem a um conjunto de classes que se

adaptam ao desenvolvimento de aplicações de um domínio específico, oferecendo

estruturas flexíveis para os pontos em que aplicações de um mesmo domínio diferem

entre si.

Duas das principais características de um framework são alterabilidade e

extensibilidade:

• Alterabilidade: Permite que os conceitos específicos das aplicações sejam

suportados a partir de estruturas flexíveis do framework;

• Extensibilidade: Garante que o framework possa ser estendido no seu conjunto

de funcionalidades, ou seja, tenha sua manutenibilidade garantida;

Um framework sempre depende de outros artefatos de software para existir,

basicamente, as aplicações específicas de um domínio que o originaram e as aplicações

geradas a partir dele.

2.3.2 Metodologias de Desenvolvimento de Frameworks OO

Muitos elementos do processo de desenvolvimento de um framework são comuns à

diversas metodologias, podemos elencar estes elementos da seguinte forma:

• Aquisição de conhecimento de domínio: A primeira etapa é o estudo de

aplicações desenvolvidas para o mesmo domínio do framework de modo a

identificar generalidades e especificidades dentro das aplicações.

• Construção da estrutura de classes: Após a análise, é realizada a modelagem

de classes. Esta modelagem pode ser dividida em cinco etapas iterativas:

◦ Generalização: Criação de classes para as estruturas idênticas das aplicações;

◦ Flexibilização: Localização das especificidades dos frameworks;

◦ Aplicação de meta padrões: Criação de métodos template que podem ser

flexibilizados através de métodos hooks para os pontos de flexibilização

encontrados;

◦ Aplicação de Padrões de Projeto: Incluir classes de um padrão (design

pattern) já catalogado e conhecido para uma determinada estrutura do

framework;

◦ Aplicação de Princípios de OO: Aplicação de princípios específicos de

Orientação a Objetos como uso de herança e composição.

• Implementação: Criação do framework em uma linguagem de programação;

• Avaliação: O framework deve ser avaliado a partir do desenvolvimento de

aplicações do domínio para o qual foi criado;

• Refinamento: A partir do desenvolvimento de novas aplicações, o conhecimento

sobre o domínio aumentará, possibilitando a melhoria do framework.

2.3.3 Uso de Frameworks OO

Um framework deve facilitar o desenvolvimento de aplicações de um domínio. Se

entender o framework for muito complexo, pode ser mais fácil desenvolver a aplicação

sem o framework.

Uma das formas de garantir uma documentação que atenda às necessidades dos

usuários do framework é adaptando a documentação à estas necessidades. Segue

abaixo uma proposta de documentação específica para três tipos de usuários comuns:

Tipo de Usuário Tipo de Documentação

Precisa decidir qual framework utilizar para o desenvolvimento de uma aplicação

Descrição do que pode e do que não pode ser feito com o framework.

Precisa descobrir como desenvolver uma aplicação

Receitas específicas de como utilizar um determinado recurso e/ou desenvolver uma aplicação (Cookbook).

Precisam conhecer em detalhes o projeto do framework para o desenvolvimento de aplicações complexas

Podem ser utilizados diagramas, descrições mais detalhadas da estrutura das classes, código fonte e outras ferramentas.As questões chave para este entendimento são:

• Quais classes usar: Quais classes concretas do framework podem ser utilizadas e quais devem ser criadas pelo desenvolvedor;

• Quais métodos: devem ser redefinidos pelo desenvolvedor (métodos abstratos) e quais devem ser definidos pelo framework. Entra aqui também a definição dos métodos template;

• O que os métodos fazem: qual o cmportamento dos métodos definidos pelo framework.

Tabela 2: Documentação de frameworks

2.4 Padrões PedagógicosComo apoio às metodologias de ensino de programação orientada a objetos os

autores frequentemente recorrem à padrões pedagógicos que são projetados para

capturar as melhores práticas e a excelência da arte de aprender e ensinar (THE

PEDAGOGICAL PATTERNS PROJECT) .

Para o ensino de ciências da computação, Joseph Bergin documentou catorze

padrões pedagógicos. Os padrões possuem vários níveis de aplicação, desde a

organização geral de uma disciplina até mesmo práticas em sala de aula. Os padrões são

apresentados em ordem de escala, iniciando pelos que envolvem o planejamento de

cursos semestrais até atividades diárias em salas de aula.

2.4.1 O Mais Importante Primeiro (Early Bird)

O curso é organizado de modo que o mais importante deve ser apresentado

primeiro (e frequentemente), e caso isto seja impossível, o quanto antes. Por exemplo, se

funções for mais importante que estruturas if, ensine funções primeiro, se objetos são

mais importantes que funções, ensine objetos primeiro.

Esta prática é importante porque os estudantes geralmente se lembram melhor do

que viram primeiro e é importante que eles percebam desde o início a ideia principal do

curso.

Alguns exemplos são:

• Ensinar objetos primeiro;

• Ensinar projeto primeiro;

• Ensinar concorrência primeiro em sistemas operacionais;

• Ensinar requisitos de usuário primeiro em Banco de Dados;

• Ensinar recursão antes de loops;

2.4.2 Espiral (Spiral)

Quando um conteúdo é trabalhado em sua ordem lógica, o instrutor precisa entrar

em muitos detalhes, tornando o ensino desgastante para os estudantes.

Uma solução é trabalhar os conteúdos em fragmentos que permitam que o

estudante resolva um determinado problema, posteriormente, mais fragmentos são

trabalhados de modo a resolver outros problemas, e assim, sucessivamente, trabalhando

o mesmo conteúdo mas em nível de detalhe crescente.

Deste modo, desde cedo o estudante é empoderado a construir aplicações.

2.4.3 Metáfora Consistente (Consistent Mataphor)

Ao ensinar tópicos complexos, é importante utilizar metáforas cuja base seja

conhecida pelos estudantes, de modo que ele tenham clareza sobre como o sistema deve

se comportar e possam fazer conexões dos novos conceitos com conceitos que já são

bem conhecidos por eles.

2.4.4 Caixa de Brinquedos (Toy Box)

O objetivo deste padrão é permitir que desde cedo os estudantes possam entrar em

contato com o conhecimento da área do curso através de ferramentas pedagógicas

ilustrativas, os brinquedos.

Estes brinquedos podem ser classes que abstraem parte da complexidade

envolvida no desenvolvimento de um software de maior escala, ferramentas que tornam a

programação mais acessível, ou qualquer outro tipo de artefato que permita que os

estudantes desenvolvam projetos maiores e mais interessantes.

Um dos requisitos deste padrão é que os instrutores precisam preparar o material e

ter tempo disponível para que os estudantes explorem os recursos disponibilizados.

2.4.5 Caixa de Ferramentas (Tool Box)

Desde o início do curso os estudantes desenvolvem ferramentas que lhes serão

úteis em fases avançadas do curso, funcionando também como ensino de reuso de

software.

Os exercícios do curso devem ter diversos níveis e nos níveis iniciais os estudantes

são estimulados a discutir e desenvolver seus componentes. É importante também que o

projeto de software para reuso seja discutido e apresentado o quanto antes pelo instrutor.

Estes componentes desenvolvidos pelos alunos podem ser complementados por

bibliotecas fornecidas pelo instrutor. Um bom exemplo da aplicação deste padrão é o uso

de elementos construídos em disciplinas de estruturas de dados.

2.4.6 Disposição do território (Lay of the Land)

Os estudantes devem examinar um artefato do domínio que estão estudando de

maior complexidade, de modo a ver a imagem real de um produto na sua área de

atuação.

Isto permite que eles façam conexões das diversas partes do sistema com os

concteúdos que estão aprendendo, situando cada um deles no contexto de uma aplicação

real.

Exemplos podem ser:

• Um software com várias classes interagindo em Orientação a Objetos;

• Um modelo entidade relacionamento com diversos relacionamentos em um curso

de bases de dados;

• O projeto completo de um software em um curso de projeto orientado a objetos.

É importante que o artefato seja algo semelhante ao que o instrutor deseja que o

estudante desenvolva ao final do curso. É essencial também, que o artefato tenha um

design e utilize os conceitos do curso de forma excelente.

Assim, as diversas partes do artefato a suas interações podem ser examinadas

pelos estudantes e posteriormente utilizadas como exemplo de um determinado conceito

do curso.

2.4.7 Corrigir para cima (Fixer Upper)

Neste padrão, um artefato de grande porte é oferecido aos alunos com falhas

cuidadosamente preparadas. Este padrão permite o ensino de novos conceitos e da

análise e correção de erros.

As falhas devem ser óbvias para a maioria dos leitores, contendo uma ou duas

falhas de maior complexidade.

A origem do nome do padrão vem da expressão “Fixxer Upper” que representa uma

casa vendida em condições ruins, de modo que o comprador precisará repará-la após a

compra.

2.4.8 Maior que a Vida (Larger than Life)

Em cursos de literatura, sociologia e história por exemplo, é comum que os

estudantes trabalhem com textos que eles não teriam condições de criar.

E como ler é mais fácil do que escrever, este padrão fala sobre usar artefatos de

software de maior complexidade e bem escritos como exemplos a serem copiados.

Esta é uma forma de estimular o conhecimento sobre o desenvolvimento de

softwares reais que os estudantes ainda não teriam condições de projetar e desenvolver.

Um exemplo são bibliotecas padrão das linguagens de programação atuais.

2.4.9 Sprint de Projeto dos Estudantes (Student Design Sprint)

Ensinar a projetar softwares é hoje reconhecido como necessidade por muitos

instrutores. Este padrão sugere o uso de atividades que permitam que os estudantes

projetem soluções para problemas, recebam feedback, projetem novamente, recebam

novo feedback, e assim sucessivamente.

Um exemplo de atividade é separar os alunos em grupos de dois ou três e solicitar

o projeto para um determinado problema. Ao final, são levantadas questões que não

podem ser respondidas com um design inadequado e os estudantes são organizados em

grupos de 4 ou 5 de modo que cada grupo tem pelo menos duas propostas de projeto.

Eles são desafiados a criarem uma nova proposta, ao final, mais questões podem ser

levantadas e alguns projetos discutidos. O processo pode continuar enquanto o professor

desejar.

2.4.10 Engano (Mistake)

Os estudantes são estimulados a criarem artefatos com erros propositais, de modo

a ensiná-los como reconhecer erros e suas consequências.

Todos cometemos erros, profissionais experientes geralmente conseguem

reconhecer um erro quando visualizam as consequências de um, estudantes não sabem

reconhecer estes erros.

2.4.11 Canal de Teste (Test Tube)

Também conhecido como “teste e veja”, este padrão força que os estudantes

testem suas próprias perguntas para questões do tipo “O que aconteceria se eu..”. Desde

que exista acesso a um computador, eles podem testar suas hipóteses.

É importante que o instrutor forneça listas de exercícios levando em conta as

principais dúvidas apresentadas colocando em diversos pontos questões do tipo “O que

aconteceria se você...”.

Isto pode ser usado para testar as regras de sintaxe de uma linguagem por

exemplo e/ou o uso de operadores.

Um bom exemplo é o ensino de loops, onde a simples mudança de algumas

variáveis podem gerar impressões na tela diferentes, de 1 até 10 ou mesmo um loop

infinito.

2.4.12 Preencha as Lacunas (Fill in the Blanks)

É muito difícil e o tempo gasto seria muito alto para estudantes iniciantes

desenvolverem softwares complexos, porém, o que eles podem fazer com as habilidades

iniciais geralmente é muito chato.

A solução proposta é disponibilizar um software complexo que os estudantes

possam analisar e deixar pequenas lacunas no software a serem implementadas pelos

alunos com os conhecimentos que possuem. Um exemplo simples é uma definição de

classe em Java onde o corpo de um método foi deixado em branco.

2.4.13 Estrela de Ouro (Gold Star)

Os estudantes devem ser recompensados pelo que eles fazem bem e jamais os

deprecia por ainda não terem atingido as competências almejadas.

2.4.14 Avalie isto novamente Sam (Grade it again Sam)

Permita que trabalhos e atividades sejam enviados posteriormente para

reavaliação. Isso estimula os estudantes a criarem erros e os motiva a melhorarem seus

trabalhos para melhorar suas notas.

3 Experiência prévia com ensino de POO e JogosNo primeiro semestre de 2012, no curso Técnico em Programação articulado com o

Ensino Médio do SENAI São José em Santa Catarina, na disciplina de Programação

Orientada a Objetos II, foi trabalhado um módulo de desenvolvimento de jogos com Java.

A turma trabalhada possui 33 alunos entre 16 e 18 anos.

Esta disciplina está presente no terceiro semestre do curso. Os estudantes já

chegam a esta disciplina com uma base sobre alguns conceitos básicos de OO como

construção de classes, métodos, atributos e parâmetros, bem como conceitos básicos de

estruturas de programação como if, while, switch, dentre outros. Entretanto, por ser um

curso paralelo ao ensino médio e pelo perfil do público, é comum que eles cheguem na

terceira fase após o período de férias sem se lembrar com exatidão dos conteúdos

trabalhados nos semestres anteriores, sendo necessário relembrá-los.

Este módulo teve duração de 76 horas/aula. Destas, 40 horas/aula foram utilizadas

para o ensino dos conceitos de Programação e Jogos 2D. As demais 28 horas foram

utilizadas pelos alunos em sala com orientação do professor para o desenvolvimento do

jogo.

3.1 Conteúdos trabalhadosO conteúdo foi dividido em duas categorias, Programação Orientada a Objetos

(foco da disciplina) e Jogos 2D. Além destes conteúdos, questões como uso de controle

de versão e uma IDE de programação também foram abordados, porém, por não fazerem

parte deste estudo, não serão citados.

Segue abaixo tabela com os conteúdos trabalhados e um identificador para cada

um:

Conteúdos POO Conteúdos Jogos 2D

C1) Composição;C2) Encapsulamento; C3) Herança;C4) Polimorfismo;C5) sobrecarga e sobreescrita de métodos e construtores;C6) Classes abstratas,C7) Interfaces;C8) Enum;C9) Métodos e atributos estáticosC10) Tratamento de ExceçãoC11) Padrões de desenvolvimento (frameworks);

C20) Sprites;C21) TileMaps; C22) Animação;C23) Desenho 2D;C23) Captura Eventos Teclado;C24) Captura Eventos Mouse.

Tabela 3: Tabela demonstrando os conteúdos trabalhados na experiência prévia com ensino de orientação a objetos baseado em jogos.

Para melhor entendimento, segue abaixo uma descrição breve de como cada um

dos conteúdos foi trabalhado:

• C1) Composição: Para formar objetos de um jogo, como personagens de luta, era preciso ter uma classe composta de outras que representassem imagens, 'magias' dos personagens, etc;

• C2) Encapsulamento: Alguns recursos como colisão de personagens com o cenário foi encapsulado pelo professor e fornecido através de classes, como forma de passar o conceito, depois, no desenvolvimento do jogo e dos exemplos em aula eles foram sembre lembrados de encapsular a lógica de alguns elementos do jogo dentro de sua respectiva classe;

• C3) Herança: Todos os objetos do jogo precisavam estender uma classe chamada GameObject que já possuía características básicas de um objeto, como a posição inicial, métodos de acesso e métodos modificadores a estes atributos;

• C4) Polimorfismo: É comum termos itens em jogos 2D, estes itens podem aumentar a vida do personagem, deixá-lo mais rápido ou mais lento, dentre outras características. Uma das formas de se trabalhar o polimorfismo foi com classes que representavam itens, estas classes estendiam uma classe Item, e todos os itens, representados com subclasses abstratas eram referenciados no projeto como objetos da classe Item, para permitir extensão do software. Também foi visto polimorfismo de método com métodos de colisão que podiam receber diferentes parâmetros.

• C5) Sobrescrita de métodos e construtores: A maioria dos métodos implementados pelos estudantes eram da própria classe ou abstratos. A sobrescrita foi trabalhada apenas quando os estudantes estendiam uma classe que representava um objeto com gravidade. A lógica responsável por parar o objeto em caso de queda se ele colidisse com um chão era um comportamento padrão que os estudantes precisavam sobrescrever quando haviam especificidades nos seus objetos, sempre lembrando de chamar o método sobrescrito da classe superior para não perder o efeito da gravidade;

• C6) Classes abstratas: A classe GameObject, da qual todos os objetos do jogo devem herdar, é abstrata e exige a implementação de dois métodos, um para execução da lógica do objeto e outro para desenhá-lo.

• C7) Classes Interface: Cada fase do jogo era representada por uma classe que implementava uma interface. Esta interface apresentava métodos para quando uma fase iniciava, era carregada, desenhada ou estava em execução;

• C8) Enum: Quando foram trabalhados jogos de luta, um enum foi utilizado para controlar o estado do personagem, ou seja, se ele estava pulando, apanhando ou em estado normal;

• C9) Métodos e atributos estáticos: O framework utilizado apresentava diversos métodos estáticos, principalmente para recuperar a referência aos objetos que capturam ações dos periféricos e realizam operações de desenho. Os atributos estáticos foram trabalhados para representar as teclas do teclado;

• C10) Tratamento de Exceção: Sempre que uma imagem era carregada para o jogo, corria-se o risco dela não existir. Neste caso, uma exceção era gerada internamente pelo software e o estudante deveria tratá-la. Infelizmente neste ponto, apenas era exibida uma mensagem de erro ao usuário e o tratamento de exceção não foi visto em sua plenitude, quando o programador usa exceções para manter o software funcionando mesmo em caso de falhas.

• C11) Padrões de desenvolvimento (frameworks): Foi utilizado durante toda a disciplina o framework javaPlay (Feijó et al), de modo que o conceito de framework foi trabalhado constantemente;

• C20) Sprites: Em um jogo onde o jogador precisava mover uma nave pelo cenário, foi utilizada uma sprite com a imagem da nave em todas as direções. Como suporte, foi fornecida uma classe que desenhava os quadros de uma sprite, adaptada do framework javaPlay;

• C21) TileMaps: Cada cenário era representado por um conjunto de Tiles e um arquivo de configuração que dizia como posicionar os tiles no cenário. Uma classe que desenhava o cenário a partir do arquivo de configuração foi fornecida;

• C22) Animação: Foi usado o efeito de bombas explodindo, onde a cada fatia de tempo era preciso mudar a imagem da bomba desenhada na tela;

• C23) Desenho 2D: Nos exemplos iniciais foram utilizados somente figuras geométricas simples como círculos e linhas. Todas desenhadas pela API Graphics do próprio Java;

• C24) Captura de Eventos Teclado: Através da classe Keyboard fornecida pelo framework javaPlay com métodos para saber se uma determinada tecla estava pressionada;

• C25) Captura de Eventos Mouse: Através da classe Mouse fornecida pelo framework javaPlay com métodos para saber se o botão esquerdo ou direito do mouse estava pressionado e qual a posição do cursor na tela;

3.2 MetodologiaO principal elemento da metodologia foi o uso de exemplos, no qual era aplicado

um determinado conjunto de conceitos na construção de um jogo e, a seguir, atividades

práticas de melhoria do exemplo apresentado de modo a permitir que o estudante tivesse

um contato com o conceito e a sua implementação.

Apenas em um único momento iniciaram o desenvolvimento com uma tela vazia,

neste caso, tinham em mãos um script que os guiaria pelos conceitos e recursos básicos

do javaPlay.

Antes do início deste módulo com jogos houve uma revisão breve dos conceitos de

classe, métodos, atributos, e outros conceitos básicos de OO.

Todos os exemplos foram desenvolvidos tendo como base o framework javaPlay

(Feijó). E, após um período de aulas teóricas, os alunos puderam desenvolver seu próprio

jogo, com tema livre. Seguem abaixo o relato dos exemplos utilizados:

3.2.1 Exemplo 1 – Movimentando uma bola

No primeiro momento, foi apresentado um exemplo de uma bola se movimentando

horizontalmente na tela a partir do movimento do teclado (Caminha, Exemplo 1). Esta

lição demonstrou o uso básico do framework, como acessar o teclado e como criar um

objeto de jogo, no caso, a bola.

Após a apresentação, os estudantes receberam a tarefa de permitir o movimento

vertical da bola no eixo vertical sem perder o movimento horizontal existente. Ao final, um

exemplo de um jogo mais complexo (Caminha, Exemplo 2) utilizando o objeto da bola foi

mostrado para exemplificar o potencial do que eles estavam aprendendo. Também foi

disponibilizado um tempo para que eles fizessem alterações neste exemplo mais

complexo, agora porém, de forma livre.

Ilustração 3: Movimentando uma bola na tela

Ilustração 4: Exemplo mais complexo utilizando a bola criada anteriormente

3.2.2 Exemplo 2 – Construindo o primeiro jogo

No segundo momento, era importante que os estudantes iniciassem o

desenvolvimento de um jogo simples, porém, passando por todas as etapas do processo

de desenvolvimento, já que na etapa anterior, haviam apenas realizado uma modificação.

Para auxiliá-los foi fornecido um roteiro de 10 passos (Caminha, javaPlay em 10

passos)que guiava a construção de um jogo (Caminha, Exemplo 3) no qual o personagem

controla um jogador em formato de bola (verde) que deve fugir de alguns inimigos (bolas

amarelas e vermelhas) até um elemento de chegada, uma estrela.

3.2.3 Exemplo 3 – Ítens e fases

Passamos agora a melhorar o jogo desenvolvido com o auxílio do roteiro. A

primeira atividade foi o uso do framework para poder realizar a passagem de fases.

Então, foi construído um jogo com três fases.

1. A primeira fase corresponde ao jogo já criado na etapa anterior;

2. Na segunda fase o personagem também pode capturar itens. Um dos itens é

representado por um quadrado verde e aumenta a velocidade do jogador. O

segundo é um quadrado vermelho e inverte a movimentação. Para a construção

dos itens foi criada uma classe abstrata que obriga o programador a implementar

um método de ação quando o personagem tem colisão com alguns dos itens.

Antes de avançar para a terceira fase, os estudantes são orientados a criar um

novo tipo de item;

3. Na terceira fase, uma única lista é utilizada para armazenar os diversos itens do

jogo. Quando existe colisão com algum deles o método definido na classe abstrata

Ilustração 5: Tela final do jogo desenvolvido com o auxílio do roteiro

é executado.

3.2.4 Exemplo 4 – Guerra Especial

A partir deste ponto, iniciou-se o trabalhando com o uso de imagens e a criação de

novos objetos a partir de objetos já existentes. Decidi utilizar uma metáfora similar aos

projetos anteriores e escolhi um jogo no qual o jogador controla uma nave que se move

pelo cenário e precisa destruir as naves inimigas (Caminha, Guerra Espacial).

Como este projeto era complexo, ele foi divido em 4 etapas:

• Etapa 1: apenas foi desenhada uma nave que se movimentava livremente pelo

cenário, de modo a trabalhar o uso das classes para desenho de imagens;

• Etapa 2: a nave foi capaz de atirar. Os tiros eram criados pela nave, de modo a

trabalhar que um objeto era capaz de criar outros objetos ao longo da execução do

software. Estes tiros são armazenados em uma lista, trabalhando a capacidade

dinâmica de armazenamento das listas;

• Etapa 3: uma nave inimiga é criada e o objetivo é, com os tiros, eliminar a nave

inimiga. Este módulo trabalha principalmente a interação entre três objetos

diferentes em tempo de execução. Também é adicionada uma classe que gerencia

a explosão que ocorre quando o tiro acerta a nave.

• Etapa 4: um segundo jogador é adicionado e explosões especiais são adicionadas

quando uma nave inimiga atinge um dos jogadores. Várias naves inimigas são

criadas e os tiros de ambos os jogadores podem acertar as naves. Isto cria um

ambiente complexo que só pode ser gerenciado através do uso de listas. Cada

Ilustração 6: Terceira fase do exemplo com diversos itens na tela

jogador é construído com uma classe de modo a estimular os estudantes na

identificação de código duplicado e possibilidade de herança.

3.2.5 – Personagens e Cenários

Nesta etapa, era importante demonstrar os mesmos conceitos abordados em outro

contexto. Foi escolhido o contexto de jogos com cenários e gravidade. Nestes jogos um

personagem se movimenta por um cenário que possui uma estrutura considerada como

chão e pode saltar sobre obstáculos, plataformas e outros. Como este projeto envolvia

grande complexidade, foi dividido em 2 etapas:

• Etapa 1: Apenas um personagem (chamado Ryu) se movimentando por um

cenário construído a partir de um arquivo de configuração. Toda a colisão com o

cenário é feita por uma classe que encapsula a lógica. Os alunos não são

instruídos sobre a lógica utilizada pela classe devido a sua complexidade. Os

estudantes são instruídos sobre como controlar os pulos do personagem

(Caminha, Exemplo Ryu);

• Etapa 2: Após, são adicionados inimigos na fase representados por bolas

vermelhas que rolam em direção ao jogador, semelhante as naves inimigas no jogo

Guerra Espacial (Caminha, Exemplo Ryu 2).

Ilustração 7: Versão final do jogo Guerra Espacial

3.2.6 – Jogo de Luta

Como exemplo final foi trabalhado um jogo de luta utilizando o mesmo personagem

anterior contra outro personagem (chamado Vegeta). Neste jogo os personagens

possuem golpes e um deles pode atingir o outro. Este material serviu principalmente

como estímulo ao desenvolvimento dos jogos dos alunos no projeto final e demonstrou

comportamentos mais complexos de interação entre os objetos (Caminha, Ryu vs

Vegeta).

3.2.7 – Revisão

Ao final foi preparado um material de revisão de todos os conceitos relembrando os

tópicos abordados e todos os conceitos apresentados (Caminha, Revisão jogos 2D).

Ilustração 8: Personagem saltando sobre um inimigo representado por uma bola vermelha

Ilustração 9: Exemplo jogo de luta

3.3 Avaliação e ResultadosA avaliação da disciplina foi feita através de conhecimentos e habilidades. Por

conhecimento entende-se as capacidades teóricas, avaliadas com três provas de curta

duração e uma de revisão sobre todo o conteúdo. Por habilidades entende-se a

capacidade prática de desenvolver um jogo utilizando os conceitos aprendidos.

Para avaliar o nível de motivação com a disciplina, principalmente ao trabalharmos

o tema de jogos, foram incluídas questões sem peso avaliativo e de resposta voluntária

nas provas teóricas.

3.3.1 Avaliação Teórica

As três primeiras provas avaliaram diferentes aspectos ao longo das 40 horas/aula

trabalhadas e ao final do conteúdo, houve uma prova com todo o conteúdo abordado

durante o ensino. As três primeiras provas foram divididas em duas partes, a primeira

parte era sempre aplicada no início das atividades e a segunda ao final. Segue a

descrição de cada uma e a média de pontuação obtida.

• Primeira prova: foi aplicada logo após a construção do primeiro jogo e abordou

conceitos complexos como classes abstratas, interface e herança. A média geral da

prova em uma escala de 0 a 100 foi de 66 pontos e meio (Caminha, Prova 2a e

Prova 2b).

• Segunda prova: Após este resultado baixo os mesmos conceitos foram

retrabalhados nos exemplos posteriores e a segunda prova foi aplicada após o

exemplo com uso de itens e diversas fases, de modo que polimorfismo foi incluído

com os demais conteúdos na prova. A média geral da turma foi de 90 pontos em

uma escala de 0 a 105 (Caminha, Prova 3a e Prova 3b).

• Terceira Prova: A terceira prova teve como foco o reuso de código com

composição e herança, acrescido de alguns poucos tópicos sobre jogos 2D. A

média geral foi de 73 em uma escala de 0 a 100 (Caminha, Prova 4a e 4b).

• Prova de Revisão: A prova revisão foi aplicada a todos os alunos após a revisão

com o objetivo de verificar de forma ampla o entendimento teórico da disciplina

após todo o conteúdo trabalhado. Esta prova teve pelo menos um tópico sobre

cada conteúdo trabalhado e a média geral da turma foi de 72 pontos em uma

escala de 0 a 100 (Caminha, Prova de Revisão).

Após a análise da prova percebi que as questões envolvendo os conceitos de

herança, composição, polimorfismo, classes abstratas e classes interface foram

devidamente absorvidos.

Porém, tive índice de erro de quase 50% em uma questão que envolvia a

identificação e classificação de algumas estruturas básicas como atributos, métodos e

construtores (questão 3 da prova de revisão). Porém, no momento de correção da prova

praticamente todos percebiam e compreendiam o erro após este ter sido identificado.

A hipótese levantada é que esta dificuldade ocorreu poque foi trabalhado muito com

estruturas básicas já prontas que eles apenas copiavam, colavam e modificavam para a

sua necessidade, até mesmo quando era criada uma aplicação do zero, eles tinham um

roteiro com códigos fonte de apoio.

Como trabalhamos neste modelo por dois meses e a disciplina anterior de

Orientação a Objetos havia sido ministrada no ano anterior, acredito que eles acabaram

esquecendo o nome de algumas estruturas simples.

3.3.2 Avaliação da Motivação

Na primeira prova, logo após a construção do primeiro jogo os estudantes foram

perguntados se estava sendo interessante aprender Orientação a Objetos com Jogos.

82% disseram que sim, 9% não responderam e 9% disseram que não fazia diferença.

Havia uma opção para o caso de não estar gostando, nenhum estudante marcou esta

opção.

Ficou claro também na relação de convivência que o interesse havia aumentado

muito em relação à disciplina de Programação Orientada a Objetos I onde havíamos

trabalhado com softwares Desktop e com exemplos proposto por Barnes.

Ao final, pelo menos 5 alunos demonstraram grande interesse em seguir a carreira

de programador de jogos.

3.3.3 Avaliação Prática

Ao final das 40 horas aula teóricas, os estudantes tiveram 28 horas aula para

desenvolver o próprio jogo. Os 33 alunos se organizaram em 8 grupos e desenvolveram

os seguintes trabalhos:

3.3.3.1 Grupo 1 – PowerMusic

Jogo similar ao popular GuitarHero onde o jogador simula que está tocando uma

guitarra no acompanhamento da música e deve pressionar os botões correspondendo a

nota da guitarra no momento exato indicado por uma animação na tela.

3.3.3.2 Grupo 2 – Champions Fighter

Jogo de luta como o apresentado no exemplo para a turma com personagens

clássicos de diferentes desenhos animados e jogos de vídeo-game. Cada personagem

pode dar socos, chutes e alguns contém um especial.

3.3.3.3 Grupo 3 – Ghomaine

Jogo de luta como o apresentado no exemplo para a turma com personagens

clássicos de diferentes desenhos animados e jogos de vídeo-game com o diferencial de

cada personagem contém de 2 à 3 ataques especiais específicos.

3.3.3.4 Grupo 4 – Ice Crown Citadel

Jogo com muitas fases onde três jogadores unem habilidades distintas para

derrotar diversos inimigos. Cada inimigo representa uma fase no jogo.

3.3.3.5 Grupo 5 – Moluscation

Um personagem criado pelos estudantes deve percorrer um cenário pulando por

obstáculos e bombas. A cada fase é possível ganhar alguns poderes especiais.

3.3.3.6 Grupo 6 – Terrorist Strategy

Jogo no estilo do clássico Bomberman onde dois personagens disputam entre si

lançando bombas em um cenário com obstáculos.

3.3.3.7 Grupo 7 – God of Worms

Disputa entre duas minhocas realizado em turnos. Cada minhoca, no seu turno,

pode lançar um tiro sobre a outra escolhendo um ângulo e uma força.

3.3.3.8 Grupo 8 – Sami Game

Jogo similar a um futebol de botão no qual cada personagem é um círculo que

precisa acertar uma bola e jogá-la para dentro do gol adversário.

3.3.4 Resultado avaliação prática

A avaliação técnica do jogo contou com diversos critérios para verificar se os

conceitos de Orientação a Objetos foram aprendidos corretamente, segue abaixo os

critérios, o respectivo índice de acerto médio dos grupos e o número de grupos que

atenderam perfeitamente ao critério:

Critério Porcentagem de Acerto

Número de Grupos com acerto máximo

Uso de Composição 90% 6

Uso de Herança 81% 4

Uso de Polimorfismo 38% 3

Classes Enum 38% 3

Classes Abstratas 38% 3

Uso de Listas (ArrayList) 88% 5

Tabela 4: Índice de acerto em cada um dos critérios de avaliação do jogo 2D

A avaliação mostrou de forma clara que os estudantes não conseguiram identificar

em seus projetos oportunidades para uso de recursos mais avançados de programação

como polimorfismo e classes abstratas.

Foi identificado na maioria dos projetos oportunidades do uso destes recursos, de

modo que as restrições não foram decorrentes dos jogos projetados.

Outros conceitos mais básicos como herança e composição foram absorvidos com

tranquilidade e implementados com qualidade pela maioria dos grupos. No caso de

herança, apesar de todos terem utilizado pelo menos alguma classe com herança,

existiam muitos lugares no código onde a herança seria adequada e o grupo não

percebeu. Por isso que apenas metade dos grupos atingiram aproveitamento perfeito

neste quesito, tendo, todos os outros, aproveitamento parcial.

3.3.4 Conclusão ao final do módulo

Ficou evidente o grande aumento da motivação dos alunos, principalmente pela

qualidade de muitos dos jogos apresentados ao final da disciplina.

Porém, a ênfase em um grande conjunto de códigos previamente elaborados que

eles apenas modificavam acabou por gerar dificuldade em reconhecer quando e como

aplicar um determinado conceito aprendido para um problema novo. Por exemplo, eles

tinham facilidade em entender quando usar herança para os casos semelhantes aos

apresentados em sala, mas não em casos diferentes.

Acredito que a metodologia aqui adotada carece de maturidade na elaboração de

atividades e exemplos que permita aos estudantes adquirirem maturidade no processo de

desenvolvimento e identificarem adequadamente onde cada conceito pode ser aplicado.

4 Ensino de Programação Orientada a ObjetosO ensino de programação em Java implica em grandes desafios para o ensino de

programação orientada a objetos. segundo Barnes, um programa mínimo em java possui

numerosos obstáculos de sintaxe tas como: escrever uma classe; escrever um método

main; a criação de um objeto utilizando a palavra-chave new; uma atribuição a uma

variável, a declaração de uma variável, incluindo o tipo; uma chamada de método;

utilizando a notação de ponto; possivelmente, uma lista de parâmetros.

Podemos somar a isso o excesso de conhecimento necessário para realizar

operações básicas de input e output, o grande número de termos como instância,

herança, método com os quais os estudantes não estão familiarizados e a dificuldade

adicional para os estudantes cuja língua nativa não é o inglês (Clark).

Por fim, alguns autores (Barnes, Feijó) identificaram a necessidade de ensinar

através de projetos, para que os conceitos possam ser vistos em aplicações reais.

Esta seção visa apresentar algumas metodologias para o ensino de Orientação a

Objetos com Java e extrair ao final, um conjunto de diretrizes guia para o presente

trabalho.

4.1 Metodologias para Ensino OOPara a elaboração deste trabalho foram escolhidas cinco metodologias de ensino

de Orientação a Objetos. Os critérios para a escolha foram a sua relevância entre os

instrutores de programação e a experiência prática do autor deste trabalho com cada

metodologia.

A primeira metodologia é a desenvolvida pelo professor do Departamento de

Informática e Estatística da Universidade Federal de Santa Catarina, Isais Camilo Boratti.

Metodologia responsável pelo primeiro contato do autor com Orientação a Objetos.

A segunda é a de maior abrangência internacional, principalmente por ter sido a

primeira metodologia a vir acompanhada de um livro texto e de uma ferramenta que

oferecesse suporte total a ela. É a metodologia construída por David J. Barnes e Michael

Kolling utilizando o BlueJ como ambiente de programação. Esta metodologia foi utilizada

parcialmente pelo autor para um curso de Programação Orientada a Objetos I de 90 horas

aula.

A terceira escolhida foi a metodologia de introdução à ciência da computação com

jogos que deu origem ao curso apresentado no capítulo três, baseada no trabalho de

Bruno Feijó do VisionLab da PUC do Rio de Janeiro.

A quarta, é a metodologia desenvolvida por Stelios Xinogalos ao longo de quatro

anos de ensino de programação orientada a objetos. Xinogalos também trabalhou com a

metodologia de Barnes e Kolling, porém com o tempo, passou a adotá-la apenas

parcialmente no projeto do seu curso, utilizando um conjunto mais abrangente de

ferramentas.

Por fim, para atender uma necessidade observada pelo autor deste trabalho, foi

adotada a metodologia de Caspersen, que trabalha com uma abordagem baseada na

modelagem do problema a ser resolvido antes de trabalhar como produzir o código para

um determinado problema.

Para cada metodologia é apresentada a sequencia de seções da metodologia com

os respectivos conteúdos e exemplos trabalhados. Após, é feita uma descrição geral do

método, uma análise dos pontos fortes e fracos de cada metodologia e uma revisão final.

4.1.1 Isaias Camilo Boratti

Esta metodologia foi vivenciada pelo autor como aluno no primeiro semestre de

2007, no curso de Sistemas de Informação da Universidade Federal de Santa Catarina,

na disciplina de Programação Orientada a Objetos I.

A disciplina foi ministrada pelo próprio professor Isaias Camilo Boratti que, no

mesmo ano, em agosto, publicou o livro que documenta a metodologia intitulado

“Programação Orientada a Objetos em Java”.

O livro está organizado em oito capítulos conforme tabela abaixo:

Capítulo Exemplos de Projetos Desenvolvidos Principais Conceitos abordados

Capítulo 1 Nenhum projeto desenvolvido • Relação POO com o mundo real;• Processo de Abstração;• Operações de Abstração.

Capítulo 2 Nenhum projeto desenvolvido • Objetos e Classes;• Representação visual de objetos

e classes;• Linguagem Java;

Capítulo 3 • Imprimir na tela uma linha de texto;• Calcular a soma de dois números;• Escrever um programa que determine a área

de um círculo;

• Método main;• Identificadores;• Tipagem de valores;• Variáveis;• Criação de objetos;• String / sequência de caracteres;• Declaração de atributos;• Declaração de métodos;• Construtores;• Parâmetros e Argumentos;• Compilação Java;• Processo de modelagem de um

software a partir de um problema;

Capítulo 4 • Escrever uma aplicação que determine a distância entre dois pontos;

• Implementação de métodos;• Métodos de acesso e métodos

modificadores;• Implementação de construtores;• Escopo;• Comentários;• Parâmetros;• Implementação de objetos /

referência para um espaço de memória;• Tipagem de valores;• Atribuição;• Conversão explícita de tipo;• Expressões aritméticas;• Expressões Lógicas;

Capítulo 5 • Escrever um programa que determine a idade média de um grupo de pessoas;• Escrever um programa que determine a

média de idade das pessoas do sexo masculino e também a média de idade das pessoas do sexo feminino de um grupo de pessoas;• Classe Aluno;• Classe Triângulo;

• Processos de repetição / loops;• Processos de tomada de decisão.

Ex: if, switch;• Encapsulamento;• Modificadores de acesso;• Palavra chave this;

• Verificar se um número é primo;

Capítulo 6 • Desenvolver uma aplicação que faça uma análise do desempenho de alunos em determinada disciplina. A aplicação deve determinar, para cada um dos alunos, a sua média final, juntamente com uma informação dizendo se o aluno foi aprovado ou não. Considerar que o aluno tenha realizado três avaliações, todas com o mesmo peso;• Em um determinado jogo de dados

participam dois jogadores. Cada jogador deve lançar o dado e computar para si os pontos obtidos. Será considerado vencedor o jogador que atingir um total de 100 pontos ou mais. Sempre que no lançamento do dado, o jogador obter o valor 1 ou 6, este terá direito a um novo lançamento;• Modelagem das classes Funcionario, Chefe

e Apoio, sendo as duas últimas subclasses de Funcionario;• Modelagem da classe abstrata Contribuinte e

das subclasses Fisico e Juridico.

• Herança;• A palavra-chave super;• Reutilização de código;• Sobreposição de métodos;• Polimorfismo;• Polimorfismo de método;• Sobrecarga de métodos;• Classes abstratas;

Capítulo 7 • “Desenvolver uma aplicação que avalie o desempenho de um grupo de estudantes em determinada disciplina...que prevê a realização de vários testes e uma prova final...a média dos testes terá peso de 60% e a prova final peso de 40%.... ”

• Arranjos / Arrays;• Arrays Multidimensionais;• Operações com arrays.

Capítulo 8 • Atributos de classe;• Métodos de classe;• Métodos da classe Math;• Manipulação de Strings;• Classe Character;

Tabela 5: Conteúdos e Exemplos da metodologia de Boratti

4.1.1.1 Análise Geral do Método

A metodologia inicia demonstrando que o mundo real “é constituído por entidades

que interagem entre si”, e que tais entidades possuem características e funções, podendo

também serem chamadas de objetos.

Dessa forma, a construção de um software orientado a objetos passa pelo processo

de identificação dos objetos envolvidos e de como estes objetos irão se relacionar entre si

para a resolução de um determinado problema.

A partir disto, Boratti conduz o estudante pelo conceito de abstração, que

corresponde:

“ao processo utilizado na análise de determinada situação, através da qual observa-se uma realidade, tendo-se por objetivo a determinação dos aspectos e fenômenos considerados essenciais, excluindo-se todos os aspectos considerados irrelevantes.”

E a partir de problemas simples como “determinar o raio de um círculo” demonstra

como o problema pode ser modelado em termos de objetos com características e funções

interagindo entre si, modela as classes que representam estes objetos e apresenta sua

respectiva implementação em Java.

Os conceitos chave são demonstrados na medida em que são úteis para resolver

problemas mais complexos e sub seções complementares se encarregam de

determinados aspectos da linguagem Java como operadores matemáticos e detalhes de

sintaxe, sem necessariamente, serem parte da solução dos problemas apresentados.

Ao final de cada seção, é apresentado um resumo dos conceitos e conhecimentos

trabalhados, uma lista de exercícios, geralmente extensa e abrangente, nos casos que

apresentem conteúdo prático, diversos exercícios resolvidos também são fornecidos.

Por fim, ressalta-se que todos os códigos construídos por Boratti são em língua

portuguesa e sempre que apresentam recursos novos, são comentados com descrições

detalhadas do seu comportamento.

4.1.1.2 Pontos Fortes

4.2.1.2.1 Operações de Abstração

No capítulo introdutório da metodologia, Boratti traz o conceito de operações de

abstração que “mostram como o ser humano mentaliza, organiza e modela o mundo ao

seu redor”. Estas operações são úteis na medida em que definem uma taxionomia para

as interações entre as entidades no mundo real e podem ser representadas diretamente

através de código orientado a objetos. Logo, o processo de analisar uma interação entre

entidades no mundo real e o código que deve ser construído para resolver problemas

envolvendo esta interação pode ser mais adequadamente identificado.

As Operações de abstração são demonstradas utilizando representações parecidas

com o utilizado pelo diagrama de classes da UML para as classes identificadas.

Segue abaixo as quatro operações de abstração:

• Classificação / Instanciação: Classificação corresponde a determinar um

conjunto de características de um determinado grupo de objetos de modo a

classificá-los em uma categoria ou classe. Instanciação é o processo inverso, no

qual exemplos (instâncias) de determinadas categorias são ressaltados. Por

exemplo a Classe Carro e Instância carro vermelho do josé;

• Generalização e Especialização: Generalização ocorre quando determinamos

características comuns a conjunto de classes e assim, criamos uma classe mais

genérica. Especialização é o inverso, quando a partir de uma classe genérica,

determinamos classes especialistas. Por exemplo, a classe genérica Médico

poderia ser especializada em Obstetra, Pediatra e Ornitolaringologista;

• Agregação / Decomposição: A Agregação é caracterizada pela relação de “é

composto por” entre duas classes. A decomposição é quando dizemos que um

objeto “é parte de” outro objeto. Por exemplo, a classe Carro é composta por

objetos da classe Motor. Já um objeto da classe Motor é parte de um objeto da

classe Carro;

• Associação: Ocorre quando dois objetos possuem algum tipo de ligação entre si

mas podem existir independentemente do outro, Por exemplo, na relação que

ocorre entre objetos das classes Professor e Aluno.

4.2.1.2.2 Processo de Modelagem

Boratti coloca que o modelo de resolução de um problema, ou seja, o software, é o

resultado de um processo de abstração que em orientação a objetos corresponde à

identificação dos objetos com suas características e funções e a respectiva modelagem

das suas classes.

4.2.1.2.3 Representação Visual de Objetos

Após a identificação dos objetos é necessário representá-los visualmente pelo

projetista de software. A visualização proposta por Boratti utiliza um círculo para

representar um objeto com um texto dentro representando o identificador deste objeto.

Ilustração 10: A Construção do modelo. Fonte: Boratti

Quando um objeto é composto por outros objetos estes são representados como círculos

dentro do círculo maior. No caso de atributos simples de um objeto como números e

textos, estes objetos são representados com um retângulo.

4.2.1.2.4 Implementação de Objetos

Recordo, como estuante do professor Isaías Boratti, que fortaleceu muito o meu

aprendizado no momento que compreendi que cada objeto ocupava um espaço na

memória e que uma variável, na verdade, era um apontador para este espaço na

memória.

Este aspecto da implementação de objetos é tratada na seção 4.8 onde Boratti

coloca que “a identificação de um objeto constitui-se em uma posição na memória

(portanto, uma variável) que armazena o endereço do espaço de memória ocupado por

aquele objeto”.

Para exemplificar este conceito o seguinte código é apresentado:

Ponto umPonto, outroPonto; // Um ponto contém um atributo inteiro x e um y

umPonto = new Ponto();

outroPonto = new Ponto();

outroPonto.redefina_se(2.0, 3.0); // este método altera os valores de x e y

E a partir do código acima, é utilizada uma adaptação da visualização de objetos

demonstrando que as variáveis são apenas apontadores para os objetos:

Ilustração 11: Representação Visual de Objetos. Fonte: Boratti. Adaptado por Kaléu Caminha

4.2.1.2.5 Representação Visual de um Array

Arranjos, como são chamados os tradicionais Arrays por Boratti são “elementos que

armazenam vários valores”. Para facilitar o ensino foi criado um modelo visual para o uso

de arrays. Para exemplificar o modelo usaremos o seguinte código:

int[] numeros = new int[8];

int cont = 2;

numeros[1] = 34;

numeros[cont] = 15;

numeros[cont+1] = numeros[cont] – 10;

O código acima apresentaria a seguinte representação visual:

4.1.1.3 Pontos Fracos

4.2.1.3.1 Início pelo método main com Hello World

Após os dois primeiros capítulos de introdução, com uma explicação detalhada e

abrangente sobre orientação a objetos e o processo de modelagem, o primeiro programa

mostrado tem como problema “Imprimir uma linha na tela” e o seguinte código-fonte:

Ilustração 12: Implementação de Objetos. Fonte: Boratti. Adaptado por Kaléu Caminha

Ilustração 13: Representação Visual de um Array. Fonte: Boratti. adaptado por Kaléu

Caminha

public class Programa1

{

//Declaração do método main

public static void main(String[] parametro)

{

System.out.println(“Primeiro Programa!”);

}

}

O programa que resolve este problema não envolve a criação de nenhum objeto, e

o único método chamado é um método acessado através de um atributo estático da

classe System, usando notação de ponto.

E isto é feito dentro do método main, um método estático que exige como

parâmetro um array de strings, conteúdos que somente serão trabalhado nos capítulos

sete e oito.

É evidente que esta abordagem se torna necessária na medida em que Boratti, por

não adotar nenhuma ferramenta que suporte a execução de código sem a criação do

método main, não tem saída a não ser iniciar por ele.

Esta abordagem porém, não é interessante pois a primeira porção de código que o

estudante enxerga é algo absolutamente incompreensível para ele, devido a grande

quantidade de conceitos envolvidos (Kolling e Rosemberg).

4.2.1.3.2 Primeiro o código, depois o conceito

Em diversos exemplos, certas regras de sintaxe são apresentadas, cujos conceitos

envolvidos somente são trabalhados em seções ou capítulos posteriores.

Um exemplo é a primeira classe com a qual os alunos tem contato. A classe

Círculo, apresentada como o terceiro trecho de código com o qual os estudantes tem

contato.

public class Circulo

{

//Declaração do atributo

protected double raio;

//Declaração dos métodos

public Circulo()

{

raio = 0.0;

}

public double forneceArea()

{

double area;

area = 3.1415*raio*raio;

return area;

}

public void recebaValorRaio(double vRaio)

{

raio = vRaio;

}

}

Esta classe apresenta mais de 10 conceitos: comentários, declaração de atributos,

tipagem de variáveis, declaração de método com retorno, declaração de método sem

retorno, declaração de um construtor, assinatura de classe, parâmetros, atribuições,

operações matemáticas e uso de modificadores de acesso.

A maioria destes conceitos só serão trabalhados posteriormente, por exemplo,

atribuições serão detalhadas no capítulo 4 enquanto modificadores de acesso somente

serão vistos no capítulo 5.

Percebe-se que esta abordagem tem como intenção demonstrar a modelagem

completa de uma classe adequadamente escrita para resolver um problema. Isto fica

claro pelo uso de modificadores de acesso desde o início, com a intenção de evitar que

estudantes declarem atributos como públicos.

Isto causa, porém, uma sobrecarga de conceitos apresentados sem a devida

possibilidade do estudante experimentar cada um deles e suas consequências para o

programa, sem saber qual a função de cada palavra-chave.

4.2.1.3.3 Métodos estáticos desde o início

Para complementar o exemplo do capítulo 3 no qual é preciso determinar a área de

um círculo a partir do seu raio, é apresentada uma classe chamada Interface (que não

tem nenhuma relação com o conceito de interfaces em Java) responsável por solicitar ao

usuário um número que irá representar o raio do círculo.

O principal método desta classe chamado “pegaValorRaio” contém 4 linhas,

conforme apresentado abaixo:

…

String valorLido;

valorLido = JoptionPane.showImputDialog(“Digite o raio: ”);

double valor = Double.parseDouble(valorLido);

return valor;

…

O problema deste método é que as principais instruções são métodos estáticos de

classes específicos da biblioteca do Java. Isso nada ensina sobre orientação a objetos,

sendo necessários apenas para que o programa seja minimamente interessante.

Construções como esta são utilizadas em outros pontos como no capítulo 4 com o

uso do método sqrt da classe Math, responsável por recuperar a raiz quadrada de um

número.

A grande crítica a esta abordagem é que métodos e atributos estáticos são

ensinados apenas no capítulo 8, de modo que o estudante precisa simplesmente ignorar

o fato da sintaxe ser diferente de outros objetos com os quais ele trabalha.

O autor já presenciou, como professor, estudantes que foram ensinados sob

metodologias parecidas chamando métodos diretamente das classes, sem diferenciar se

um método era ou não estático.

4.1.1.4 Conclusão

A metodologia se mostra muito interessante ao tornar claro para o estudante o

processo de construção de um software, a sua respectiva modelagem de objetos e

classes e as diversas representações visuais do programa.

Também se mostra interessante a forma de abordar os conceitos sempre que

possível a partir de problemas do mundo real. Observa-se porém que a complexidade dos

problemas tratados é muito pequena como por exemplo, calcular a média de um grupo de

alunos ou determinar a área de um círculo.

Um dos motivos para o uso de exemplos triviais é a dificuldade em utilizar recursos

avançados de programação em função da complexidade destes recursos conforme

apresentado pela linguagem Java. De forma mais clara isto é visto na modelagem da

classe Interface que para recuperar um valor digitado pelo usuário precisa de métodos

estáticos logo no início da metodologia.

Este ponto ressalta que alguns dos pontos fracos observados na metodologia

poderiam ser melhor trabalhados com o apoio de um ferramental adequado como um

editor que não exigisse a criação de um método main para executar código ou uma

ferramenta que permitisse executar métodos diretamente dos objetos.

4.1.2 David J. Barnes e Michael Kölling

“Partindo de Objetos em Java”. Esta é a primeira frase do livro-texto para a

metodologia. A metodologia utiliza o ambiente de programação BlueJ e possui como

algumas de suas linhas guia:

• Uma abordagem iterativa: A partir do uso do padrão “Early Bird”, documentado na

seção 2.4 os principais conceitos são apresentados primeiro de uma forma

simplificada para que um determinado problema seja resolvido. Posteriormente no

curso, os mesmos conceitos são retomados segundo outro ponto de vista e o

conhecimento é aprofundado;

• Sem completa cobertura da linguagem: em função do foco do livro ser em POO,

detalhes específicos da linguagem java não são abordados a menos que sejam

necessários para a resolução de um determinado problema;

• Abordagem baseada em projeto: ao invés de introduzir uma nova construção e

então fornecer exercícios para aplicar a construção aprendida, primeiro é fornecido

um objetivo e um problema. A análise do problema determina o que será

necessário e então, os recursos da linguagem e os conceitos são apresentados;

• Sequencia dos conceitos em vez de construções de linguagem: é preferível,

sempre que existe conflito entre trabalhar construções de linguagem ou os

conceitos, trabalhar os conceitos e o mínimo possível das construções de

linguagem que auxiliem a implementar o conceito.

A metodologia está organizada em duas partes: 1) Fundamentos da Orientação a

Objetos e 2) Estruturas de aplicação. Na primeira parte são abordados os conceitos

básicos como classes, objetos, métodos, etc. Na segunda, conceitos importantes para o

desenvolvimento de aplicações e reuso como herança, polimorfismo e interfaces são

abordados.

O livro-texto da metodologia possui 13 capítulos, sendo os 7 primeiros reservados

para a primeira parte e os seis últimos para a segunda. O último capítulo é reservado para

um estudo de caso de uma aplicação de maior porte.

Segue abaixo descrição dos exemplos e conteúdos trabalhados em cada capítulo:

Capítulo Exemplos de Projetos Desenvolvidos Principais Conceitos abordados

Capítulo 1 Objetos e Classes

• Desenhos simples de algumas formas geométricas;• Exemplo utilizando um objetos do projeto

anterior para desenhar uma figura;• Exemplo simples com classes de alunos que

participam de aulas de laboratório.

• Objetos;• Classes;• Métodos;• Parâmetros.

Capítulo 2Entendendo as definições de classe

• Simulação uma máquina de vender bilhetes de trem;• Armazenamento de informações sobre um

livro.

• Campos;• Construtores;• Parâmetros;• Métodos de acesso e

modificadores;• Atribuição e instrução

condicional.

Capítulo 3Interação entre objetos

• Implementação de um mostrador de um relógio digital com horas e minutos;• Uma simulação simples de um correio

eletrônico.

• Abstração;• Modularização;• Criação de objeto;• Diagramas de objeto;• chamadas de método;• depuradores.

Capítulo 4Agrupando objetos

• Implementação simples de um bloco de anotações eletrônico;• Um sistema de leilão;• Um analisador de registros de acesso a uma

página web.

• Iteradores;• Coleções;• Arrays;• Loops.

Capítulo 5Comportamento mais sofisticado

• Implementação de um programa de diálogo semelhante ao Eliza utilizado para fornecer um “suporte técnico” para clientes;• Animação gráfica com bolas que quicam.

• Utilizando classes de biblioteca;• Lendo a documentação;• Escrevendo a

documentação.

Capítulo 6Objetos bem-comportados

• Estágios iniciais de um diário que armazena compromissos;• Implementação de uma calculadora de mesa;

• Testes;• Depuração;• Automação de testes.

Capítulo 7Design de Classes

• Um jogo iterativo de aventura baseado em texto;

• Design baseado na responsabilidade;• Acoplamento;• Coesão;• Refatoração.

Capítulo 8Herança

• Um banco de dados de CDs e vídeos; • Herança;• Subtipagem;• Substituição;• Variáveis polimórficas.

Capítulo 9 • Continuação do jogo iterativo do capítulo 7; • Polimorfismo de método;

Mais sobre herança

• Continuação do banco de dados de CDs e vídeos do capítulo 8;

• tipo estático e dinâmico;• Sobrescrição;• Escolha dinâmica de

método.

Capítulo 10Técnicas adicionais de abstração

Uma simulação de caçador-caça conhecida como “raposa-coelho”.

• Classes abstratas;• Interfaces.

Capítulo 11Tratamento de erros

• Implementação de um catálogo de endereços; • Programação defensiva;• Lançamento e tratamento

de exceção;• Informe de erro;• Processamento de

arquivos simples.

Capítulo 12Design de aplicações

• Sistema de reserva de lugares em um cinema; • Descobrindo classes;• Cartões CRC;• Padrões;• Design de interfaces.

Capítulo 13Estudo de caso

• Combinação de um sistema de reserva de táxis com um sistema de gerenciamento e de simulação.

• Desenvolvimento integral de aplicação.

Tabela 6: Conteúdos e exemplos da metodologia de Barnes

4.1.2.1 Diretrizes

De forma complementar, para que obtenha uma boa compreensão da metodologia,

segue-se o trabalho de KÖLLING e ROSENBERG, que, a partir da experiência com o

desenvolvimento de diversos cursos utilizando o ambiente BlueJ elencaram oito diretrizes

adequadas para o ensino de programação orientada a objetos:

4.1.2.1.1 Objetos primeiro

É consenso entre muitos professores de Programação Orientada a Objetos que é

melhor ensinar a criar e manipular objetos antes de qualquer outra coisa. Esta atividade,

porém, é difícil nos ambientes tradicionais, pois para executar o método de um objeto é

preciso:

1. Uma classe contendo um método main estático com um array de Strings como

parâmetro;

2. Uso de uma variável tipada;

3. Uma atribuição de um objeto à uma variável;

4. A instanciação de um objeto;

5. A sintaxe de chamada de um método;

6. A visualização do resultado da chamada do método.

Com BlueJ a primeira atividade é abrir um projeto existente e criar objetos a partir

das classes, em seguida, os estudantes podem chamar métodos destes objetos e

visualizar seu estado. Tudo isso sem escrever nenhuma linha de código.

4.1.2.1.2 Não inicie com uma tela em branco.

Um dos maiores erros em programação OO é iniciar com uma tela vazia.

Escrever projetos OO envolvem a definição de quais classes o programa terá e

quais métodos cada classe deverá ter, e este, é um exercício extremamente difícil para

estudantes novatos.

Ao invés disso, pode-se iniciar com pequenas modificações e adições em código

existente.

4.1.2.1.3 Leia código

Muitos estudantes são forçados a começar a programar sem terem lido

praticamente nenhum código. Isso não acontece em nenhuma outra disciplina.

Estudantes aprendem mais quando tem acesso a códigos bem escritos que eles

possam utilizar como base para os seus projetos.

4.1.2.1.4 Use projetos grandes

Programas curtos dificilmente deixam claro as vantagens em se utilizar Orientação

a Objetos.

A sugestão é que sejam utilizados programas bem escritos com um número maior

de classes e métodos que permitam aos estudantes compreenderem as vantagens do

uso de OO, assimilarem a importância de um código limpo e comentado, pratiquem a

leitura de código e estudem a interação entre as classes.

4.1.2.1.5 Não inicie com o método main

O método main exige muitos conceitos para ser compreendido. O ideal é que os

estudantes só sejam apresentados a ele após terem se envolvido com os conceitos

principais como a criação de objetos e chamada de métodos.

4.1.2.1.6 Não use “Hello world”

Para se fazer um “Hello World” em Java é preciso iniciar do método main, que por

sua vez significa: 1) construir uma classe da qual nenhum objeto é criado. 2) construir um

método (o main) que não age sobre um objeto.

Isso não é Programação OO e fere outras diretrizes já apresentadas.

4.1.2.1.7 Mostre a estrutura do programa

Classes e seus relacionamentos são muito importantes. É essencial que os

estudantes possam visualizar a estrutura dos programas nos quais trabalham.

O BlueJ exibe a estrutura do programa em um diagrama semelhante ao diagrama

de classes da UML. Quando o BlueJ não estiver sendo utilizado é importante que o

professor encontre meios de mostrar claramente esta estrutura.

4.1.2.1.8 Tenha cuidado com a interface do usuário

É importante ensinar uma forma de realizar a interface com o usuário para

fornecimento de parâmetros e para a impressão de resultados do software.

Em Java, podemos fazer isso com Applets, com a API de entrada e saída ou com

frameworks GUI como o Swing.

Porém, nenhuma destas alternativas é simples o suficiente para ser utilizada em

cursos introdutórios. São sugeridos então, dois caminhos para lidar com este problema:

1. Específico no BlueJ, são as janelas pop-up que solicitam ao usuário os valores

para os parâmetros dos métodos e as janelas que exibem os retornos dos

métodos;

2. Um projeto maior com classes que encapsulem a interface com o usuário e que os

estudantes apenas precisem aprender a utilizar seus métodos.

4.1.2.2 Análise geral do método

Não é sem mérito que esta metodologia está sendo adotada por um grande número

de instrutores de programação orientada a objetos em todo o mundo. Sem dúvida que a

metodologia trouxe grandes contribuições e dentre os pontos fortes podemos destacar: 1)

a abordagem baseada em projetos que permite ao estudante aprender a resolver

problemas; 2) a priorização do conceito antes das estruturas de construção da linguagem,

dando sentido ao que o aluno está aprendendo; 3) O rico acervo de projetos trabalhados,

trazendo diversas dimensões importantes da computação; 4) O uso do Bluej que permite

que se inicie a tarefa de ensinar diretamente através de objetos e escrita de seus

métodos.

Além destes, na prática com a metodologia foi possível perceber que os estudantes

que em geral possuem mais dificuldade com programação se sentiam mais seguros e

confiantes ao verem os objetos na tela e poder manipulá-los. É visível que muitos alunos

não se sentem a vontade quando se deparam diariamente nas aulas de programação

com telas repletas de código-fonte, sem outras representações visuais do trabalho que ele

está realizando.

4.1.2.3 Pontos fracos

Apesar do inúmero sucesso, é importante ressaltar algumas dificuldades geradas

pela metodologia. Estas dificuldades foram percebidas em prática do autor com a mesma

e através da pesquisa de Xinogalos.

4.1.2.3.1 Ênfase nas técnicas de visualização e manipulação direta do BlueJ

Em função do BlueJ disponibilizar interface gráfica para instanciação de objetos e

chamada de métodos, alguns alunos ficam por demais “acomodados” a esta maneira de

trabalhar, o que gera dificuldades com instanciação de objetos e chamadas de métodos

direto do código-fonte. Isso porque no BlueJ, a diferença entre a forma de manter objetos

em variáveis e chamar métodos destas variáveis (Ilustração 14) é muito diferente da

forma como a mesma ação é feita no BlueJ (Ilustração 15).

Ilustração 15: Objetos na bancada de objetos (em vermelho) e chamada de método de um objeto

Ilustração 14: Instanciação de objeto e chamada de método em código

Outra crítica é a que métodos que possuem retorno são chamados da mesma

forma que métodos sem retorno. Esta questão causa confusão ao tentar passar

para os estudantes que métodos com retorno devem ser sempre atribuídos a uma

variável. Métodos com retorno, no BlueJ, imprimem o valor retornado na tela.

Quando, posteriormente o autor trabalhou métodos com retorno sem o uso do

BlueJ, uma das dúvidas apresentas foi questionando se, quando se retornava um

valor, este valor não deveria ser impresso na tela?

4.1.2.3.2 Ênfase em projetos existentes

Em função da utilização de projetos com uma boa quantidade de código pronto, a

dificuldade em iniciar projetos do zero se mostrou muito maior. Além disso, métodos get e

set, bem como construtores, são geralmente fornecidos pelos projetos e os alunos

raramente os implementam.

4.1.2.3.3 Ensino posterior do método main:

O ensino apenas no final do curso do método main exige que os alunos utilizem

apenas o BlueJ para testar código, potencializando as dificuldades comentadas no item 1.

4.1.2.4 Conclusão

Percebe-se que o BlueJ apesar de suas inúmeras qualidades, não pode ser visto

como a única solução, pois, em concordância com Xinogalos, “mais de uma ferramenta é

necessário para suportar as diferentes necessidades cognitivas no ensino de

programação”, de modo que esta metodologia apesar de sua qualidade, pode ser

complementada com atividades e práticas em ambientes profissionais de

desenvolvimento.

4.1.3 Bruno Feijó et al

A metodologia apresentada por Feijó visa segundo ele próprio “apresentar os

conceitos e os bons hábitos da arte de programar”. Seu material aborda não apenas a

programação orientada a objetos mas também a programação estruturada e brevemente

a programação guiada a eventos.

Apesar do foco não ser orientação a objetos, sua metodologia e o framework que o

acompanha serviram de base e inspiração para a metodologia descrita no capítulo três e

consequentemente, base e inspiração para o presente trabalho.

O livro-texto da metodologia apresenta 9 capítulos que segundo sugestão da

metodologia poderia ser trabalhado em uma disciplina de 64 h/aula em 16 aulas de 4

h/aula cada, conforme modelo abaixo:

• Semana 1: apresentação e capítulo 1;

• Semana 2: Capítulo 2;

• Semana 3: Capítulo 3;

• Semana 4 a 6: Capítulo 4;

• Semana 7: Capítulo 5;

• Semana 8: Capítulo 6;

• Semanas 9 a 11: Capítulo 7;

• Semanas 12 a 14: Capítulo 8;

• Semanas 15 e 16: Capítulo 9;

Segue abaixo organização dos capítulos, exemplos e conteúdos apresentados.

Capítulo Exemplos de Projetos Desenvolvidos Principais Conceitos abordados

Capítulo 1 Computadores

Nenhum exemplo trabalhado;

Capítulo 2Variáveis, Tipos de Dados e Expressões

• Pequenos exemplos didáticos demonstrando os conceitos;

• Comentários;• Variáveis;• Entrada de Dados;• Saída de Dados;• Expressões;

Capítulo 3Controles de Fluxo por comandos de seleção

• Pequenos exemplos didáticos demonstrando os conceitos;

• estruturas de tomada de decisão if-else e switch.

Capítulo 4Métodos e Soluções

• Pequenos exemplos didáticos demonstrando os conceitos;

• Métodos;• Métodos Estáticos;• Sobrecarga de métodos;• Loops.

Capítulo 5Dados compostos como vetores

• Pequenos exemplos didáticos demonstrando os conceitos;

• Vetores unidimensionais;• Vetores bidimensionais;

Capítulo 6Usando mais objetos e classes simples

• Jogo similar ao tradicional Pong; • Classes;• Strings;• Leitura e gravação de

arquivos;• Classes abstratas e

interfaces.

Capítulo 7Classes, objetos, herança

• Continuação do jogo similar ao tradicional Pong;

• Classes e objetos;• Modificador static;• Encapsulamento;• Herança;• Classes abstratas.

Capítulo 8Programação Gráfica

• Jogo específico desenvolvido para o livro e continuação do jogo similar ao tradicional pong;

• Conceitos de jogos 2D;

Capítulo 9Programação guiada a eventos

• Jogo específico desenvolvido para o livro. • Captura de dados do teclado e do mouse.

Tabela 7: Conteúdos e exmplos da metodologia de Feijó

4.1.3.1 Análise geral do método

A proposta é muito abrangente, segundo Feijó, pretende-se do capítulo 1 ao 6

trabalhar com programação estruturada, no 7 e no 8 orientação a objetos e no capítulo 9,

programação guiada a eventos.

Em função até mesmo deste grande conjunto de paradigmas, o livro não oferece

um bom suporte para os conceitos de orientação a objetos, os exemplos são poucos,

muito limitados e as explicações dos conceitos não acompanham boas referências

visuais.

Em contrapartida, oferece um rico material sobre como unir conceitos de jogos em

duas dimensões com técnicas de programação, tanto estruturada quanto orientada a

objetos.

Um grande mérito está no uso do framework para trabalhar classes abstratas e

interfaces, pois, para que o aluno possa criar uma fase, deve implementar uma interface e

para criar um objeto no jogo, deve estender uma classe abstrata que já fornece os

atributos de posicionamento de um objeto na tela.

4.1.4 Stelios Xinogalos

Ao fim de 4 anos de avaliações e modificações, Xinogalos chegou a uma

metodologia que utiliza três ambientes de programação: objectKarel (Satratzemi), BlueJ e

Jcreator (um ambiente profissional de programação simplificado). O material didático

utilizado é baseado no material que acompanha o objectKarel e na metodologia de

Barnes com o BlueJ, descrita na seção 2.4.2.

O curso estruturado por Xinogalos possui 12 lições de 4 horas aula semanais, duas

teóricas e duas em laboratório. As aulas são divididas na seguinte estrutura:

Aula Temas trabalhados Ambiente

1 Objetos, classes, herança: objeto, construção e inicialização de um objeto, mensagens/métodos, atributos e comportamentos de um objeto, herança, superclasse, subclasse, hierarquia de herança, diagrama de classe UML

objectKarel

2 Herança em vários níveis, polimorfismo e sobrescrita. objectKarel

3 Definição de Classe: campos, construtores, métodos de acesso, métodos modificadores, estrutura de retorno, parâmetros, escopo de variáveis, estruturas condicionais.

BlueJ

4 Interação com objeto: abstração, modularização, objetos criando objetos, múltiplos construtores, diagrama de classe, diagrama de objetos, tipos primitivos, tipos de objetos, chamadas de métodos internos e externos.

BlueJ

5 Métodos estáticos: métodos de instância vs métodos de classe, o método main, execução sem o BlueJ, byte code, Java Virtual Machine.

BlueJ, JCreator

6, 7 Agrupando objetos em coleções: Coleções de tamanho flexível (ArrayList), coleções de tamanho fixo (arrays), classes genéricas, iteradores, loops (while, for, for-each).

BlueJ, JCreator

8 Usando bibliotecas de classe: Classes padrão do Java, leitura de documentação, interface vs implementação de uma classe, explorando e usando classes (HashMap, Random, HashSet), modificadores de acesso (public, private), informações escondidas, variáveis de classe (estáticas).

BlueJ, JCreator

9 Projeto de Classes: acoplamento, coesão, encapsulamento, duplicação de código, projeto dirigido à responsabilidade, reuso de código.

BlueJ, JCreator

10 Melhorando a estrutura com herança: hierarquia de classes, superclasse, subclasse, construtor da superclasse, “subtyping”, substituição, “autoboxing”.

BlueJ, JCreator

11 Polimorfismo, sobrescrita: tipos dinâmicos e estáticos, busca dinâmica de método, super, acesso protegido.

BlueJ, JCreator

12 Classes abstratas e Interface. BlueJ, JCreator

Tabela 8: Conteúdos e ambiente de programação na metodologia de Xinogalos

4.1.4.1 O Uso de ambientes de programação

A escolha do ambiente de programação que será utilizado é difícil e importante.

Ambientes profissionais são inadequados para trabalhar aspectos introdutórios,

ambientes de micro-mundos como o objectKarel são interessantes para trabalhar

conceitos mas não uma linguagem específica, já ambientes educacionais são

interessantes para transferir os conceitos para uma determinada linguagem, porém, sem

a transição para uma IDE profissional os estudantes ficam condicionados às

características específicas das ferramentas educacionais.

A dinâmica de 4 anos no curso apresentado mostrou que mais de uma ferramenta é

necessária para que os diversos aspectos cognitivos possam ser trabalhados. Esta

dinâmica gerou as seguintes diretrizes sobre o uso de ambientes de programação:

• Use um ambiente de micro-mundo para uma introdução curta dos principais

aspectos de programação orientada a objetos: o ambiente escolhido deve

suportar o ensino dos principais conceitos de OO sem preocupações com a

sintaxe. O conceito de objeto deixa de ser abstrato pois agora os objetos podem

ser manipulados, os estudantes também ganham confiança na sua capacidade de

programação;

• Use um ambiente educacional para apresentar os conceitos vistos no micro-

mundo para a sua implementação em Java: a transição para um ambiente

educacional é mais suave do que para um ambiente profissional pois ambientes

específicos para o ensino eliminam a complexidade permitindo que os estuantes

possam se dedicar a sintaxe dos conceitos fundamentais. É essencial que estes

ambientes tenham ferramentas de visualização e manipulação direta de classes e

objetos e permitam a invocação dinâmica de métodos. O tempo com o um

ambiente educacional não deve se estender muito para evitar falsas percepções,

principalmente sobre os aspectos dinâmicos da Orientação a Objetos.

• Use um ambiente profissional para prepará-los para o futuro: É inevitável que

esta transição aconteça, a maior preocupação deve ser quando realizá-la. Neste

curso foi decidido realizar esta transição na quinta lição dando ênfase para as

características destes ambientes que poderiam ajudar os estudantes como 1)

Visão das classes em árvore; 2) Navegação rápida dentro de uma classe; 3) auto-

completar de código; 4) o destaque de sintaxe. Ao realizar esta transição os

estudantes se sentem mais confiantes com o seu conhecimento.

4.1.4.2 Diretrizes para o Ensino das lições propostas

As lições são baseadas como já mencionado no livro-texto que acompanha o

BlueJ., seguindo suas principais diretrizes.

Concomitantemente, é utilizada a abordagem “modelo primeiro” de Bennedsen e

Caspersen (2004) conforme documentada na seção 4.1.5.

Abaixo, seguem as diretrizes relacionadas a cada lição trabalhada. As lições

utilizam projetos do livro-texto que acompanha o BlueJ.

4.1.4.2.1 Lição 1: Objetos, classes e herança no objectKarel

Na primeira lição, são apresentados os conceitos básicos de classe, objeto e

método. Os estudantes iniciam criando um novo objeto da classe “Robo” com a ajuda da

interface Gráfica (Ilustração 16), depois, devem utilizar os métodos do robô (como

“mover”, “virar para a esquerda”, etc) para realizar tarefas específicas como completar um

determinado percurso.

O programa vai sendo construído a partir de botões onde o estudante seleciona os

métodos que irá executar, criando uma sequencia que no objectKarel é chamada de

tarefa (Ilustração 17).

Ilustração 16: Instanciação de um objeto no objectKarel com a ajuda da interface gráfica

Após, podem executar o programa e observar qual o comportamento do robô para

cada método e o que isso significa na linguagem dos robôs (por exemplo, virar para a

esquerda significa mudar a frente do robô em 90 graus negativos.), estas informações são

fornecidas na forma de texto no rodapé do ambiente (Ilustração 18).

Em uma segunda atividade, problemas mais complexos são apresentados de modo

que é necessário utilizar herança para a criação de uma nova classe com métodos que

irão facilitar a realização da tarefa.

Xinogalos ressalta que é essencial durante o processo explicar que cada método

muda o estado interno do objeto (mesmo que os alunos não possam ver as variáveis de

instância). Também é importante utilizar exemplos que utilizem vários objetos da mesma

Ilustração 17: Criação de uma tarefa a partir dos métodos de um robô

Ilustração 18: Execução de um programa. à direita a visualização do robô, à esquerda a lista de tarefas e abaixo a descrição do que ocorre no interior do método em execução.

classe para evitar que os estudantes considerem os dois conceitos como a mesma coisa.

4.1.4.2.2 Lição 2: Herança em vários níveis, polimorfismo e sobrescrita.

A didática se mantém a mesma e agora os problemas apresentados exigem a

construção de uma hierarquia de classes. Também são utilizados exemplos que

trabalhem a necessidade da sobrescrita de métodos como por exemplo, robôs mais

velozes que no método “move”, andam mais rápido que os robôs utilizados nos exercícios

anteriores. O polimorfismo, também é trabalhado com cuidado por se uma das principais

dificuldades observadas nos estudantes.

4.1.4.2.3 Lição 3: Definição de classe

A definição de uma classe é apresentada aos alunos utilizando o exemplo de uma

máquina de vender bilhetes (TicketMachine no livro texto que acompanha o BlueJ). Os

estudantes criam instâncias desta classe, chamam seus métodos, observam a

implementação em Java da classe e por fim, tem a oportunidade de realizar pequenas

modificações nela.

No primeiro ano do curso foram identificadas as dificuldades mais comuns

referentes ao ensino do paradigma de POO, é importante que o instrutor esteja atento a

elas desde o início do ensino para reforçar o entendimento destes tópicos. Segue abaixo

as principais dificuldades encontradas:

• A compreensão e uso de múltiplos construtores;

• O uso do this é de difícil compreensão e em geral os estudantes o evitam;

• A inicialização dos campos no construtor;

• Costumam declarar o tipo de retorno de métodos “set”;

• Tentam acessar valores de campos privados diretamente, sem o uso de métodos

get;

Outras dificuldades são atribuídas mais especificamente ao uso dos recursos do

BlueJ, são elas:

• Não declaração do tipo das variáveis que armazenam os objetos. Isso pode

ser trabalhado dando ênfase na janela de instanciação de um objeto à variável

onde o objeto será armazenado e o tipo desta variável. O BlueJ já apresenta estas

informações, porém, comumente passam despercebidas.

• Chamada de métodos. Frequentemente métodos com retorno são chamados da

mesma maneira que métodos void. No BlueJ, é possível chamar ambos os tipos de

métodos da mesma forma, de modo qque o resultado de métodos com retorno

frequentemente é interpretado como “impressão do valor na tela”;

Por fim, é essencial verificar se os conceitos aprendidos no objectKarel foram

efetivamente transportados para o Java. Isso pode ser feito solicitando que os estudantes

representem em Java os modelos dos robôs criados nas últimas duas lições.

4.1.4.2.4 Lição 4: Interação entre objetos

Estudantes são apresentados aos conceitos de modularização, abstração e

interação entre objetos utilizando o exemplo de um relógio digital com duas classes, uma

representando um relógio digital e outra que representa um mostrador de dois números. O

Relógio é composto por dois mostradores, um para as horas e outro para os minutos.

As dificuldades observadas nesta etapa foram:

• Os estudantes não tem certeza onde devem inicializar os campos;

• Não sabem como manipular este novo tipo;

• Tem dificuldades com a notação de ponto.

Para estas dificuldades é recomendado o uso de diagramas de objetos e atividades

onde os estudantes identifiquem chamadas de método internas e externas;

4.1.4.2.5 Liçao 5: O método main

nesta aula é apresentado como executar código Java sem o BlueJ. Uma introdução

sobre uso de métodos estáticos versus métodos de instância é feita utilizando o BlueJ.

Após, os estudantes criam seu próprio método main no Jcreator para um projeto

que eles já tenham conhecimento como o TicketMachine.

Esta lição também é aproveitada para falar sobre compilação, “byte code” e

máquina virtual.

As principais dificuldades encontradas foram:

• Uso de parâmetros formais da chamado do construtor (Ex: new Classe(Type param); );

• O tipo das variáveis dos objetos são esquecidos;

• Esquecem argumentos em chamadas de métodos;

• Esquecem os parênteses em chamadas de métodos sem argumentos;

Para lidar com estas questões é sugerido:

• Atividades que são de alguma forma “silenciadas” pelo BlueJ como o tipo das

variáveis que armazenam os objetos são demonstrados utilizando as caixas de

diálogo do BlueJ e seu paralelo em sintaxe Java;

• Exemplos e tarefas são realizados em cima de projetos já conhecidos;

• Um programa contendo erros comuns é apresentado e os estudantes são

ensinados a reconhecer os erros e tratá-los.

4.1.4.2.6 Lição 6: Agrupando objetos em um ArrayList

Uso de coleções em programação é comum e necessário mesmo em programas de

baixa complexidade. Alguns autores já colocam o uso de ArrayList como prioridade sobre

Arrays por ser uma estrutura mais adequada para representar listas continuas.

Durante os quatro anos de curso os autores identificaram diversas dificuldades

envolvendo o uso de ArrayList`s e chegaram às seguintes conclusões:

1. O uso dos diagramas de objetos são fundamentais desde o início do projeto. Os

estudantes são estimulados a criar um diagrama de objetos para um dado

programa e simular operações de remoção e inclusão no diagrama de objetos.

2. São oferecidos exercícios para com código incompleto para que os estudantes

preencham os espaços vazios com determinados comandos.

3. Após, são construídos programas do zero.

4.1.4.2.7 Lição 7: Agrupando objetos em coleções (ArrayList vs Array)

O uso de Arrays é apresentado e o mesmo projeto no qual foi trabalhado o uso de

ArrayList é agora modificado para funcionar com Arrays.

4.1.4.2.8 Lição 8: Utilizando bibliotecas de classe

Nesta aula os estudantes são apresentados à documentação das classes Java,

com ênfase nas classes String e HashMap. A aula também apresenta a estrutura de

pacotes.

4.1.4.2.9 Lição 9: Projeto de Classes

O projeto de classes é algo difícil de ser realizado e a simples exposição dos

principais conceitos teóricos para uma solução bem projetada não causa um grande

impacto no aprendizado. É importante que os estudantes entendam através de uma

aplicação os problemas de um mau projeto de classes.

A maior dificuldade encontrada foi a limitação do tempo que impossibilita o

desenvolvimento de uma solução completa, na qual, o entendimento dos principais

conceitos de um bom projeto de classes seria trabalhado.

4.1.4.2.10 Lição 10: Melhorando a estrutura com Herança

O projeto desta lição é uma biblioteca multimídia de CD's e DVD`s. A primeira

versão do projeto não usa herança, de modo que muito código acaba sendo duplicado.

Quando os alunos são perguntados sobre como resolver o problema, eles se

recordam da apresentação feita com o objectKarel e facilmente compreendem o uso de

herança.

A maior dificuldade percebida é a chamada do construtor da superclasse através da

subclasse. Uma sugestão é utilizar o debugger para ver a execução do código passo a

passo e os campos sendo preenchidos.

4.1.4.2.11 Lição 11: Polimorfismo e Sobrescrita

Através de uma continuação do exemplo visto anteriormente, é realizado um

exemplo onde cada subclasse sobrescreve o comportamento de um método na classe

pai.

4.1.4.2.12 Lição 12: Classes abstratas e Interface

Nesta aula o uso de classes abstratas e interface são utilizados para expandir a

simulação de um ambiente com raposas e coelhos para conter diversos tipos de animais.

Percebeu-se que não é difícil para os estudantes compreenderem o conceito e o

implementarem, porém, demonstram grande dificuldade em perceber quando uma classe

deve ser declarada como concreta, abstrata ou interface.

4.1.4.3 Análise Geral do método

As duas principais conclusões de Xinogalos são 1) a necessidade de avaliação

continua dos cursos de modo a validar as pesquisas e dar continuidade aos processos de

melhoria e que 2) mais de uma ferramenta é necessário para suportar as diferentes

necessidades cognitivas no ensino de programação.

O artigo também clarifica como integrar alguns dos diferentes tipos de ambientes

de ensino de programação desenvolvidos até o momento de modo a garantir um ensino

eficaz ao mesmo tempo em que prepara os estudantes para o mercado.

É muito rica a descrição detalhada de todas as aulas realizadas e das principais

dificuldades em cada tema, de modo que o instrutor, sabendo de antemão as dificuldades

mais comuns, pode atacá-las logo no início das atividades.

A partir do material apresentado não foi possível identificar pontos fracos na

metodologia proposta por Xinogalos, na medida em que copia os pontos fortes da

metodologia de Barnes e adiciona ela o aspecto de modelagem e uso de ferramentas

profissionais de programação.

4.1.5 Michael Caspersen

Caspersen propõe um método baseado muito no fornecimento aos estudantes do

modelo conceitual, antes de iniciar a codificação, bem como em um processo sistemático

de transformação de um modelo para código-fonte.

Segundo Caspersem, modelagem conceitual é a definição de características de

orientação a objetos e provê uma perspectiva unificada e uma aproximação pedagógica

com foco sobre o aspecto de modelagem da orientação a objetos.

Esta visão contempla um dos papéis da linguagens de programação segundo

Knudsen & Madsen (1988, citado por Caspersen) que é justamente o uso da linguagem

de programação para expressar conceitos e fenômenos.

Para que seja possível a sistematização do processo de desenvolvimento, foram

identificadas técnicas para a criação sistemática de programas orientado a objetos em 4

diferentes níveis de abstração:

• Domínio do Problema → modelagem conceitual: Criar um diagrama de classes

UML do domínio do problema, focando nas classes e nas relações entre as

classes;

• Domínio do problema → modelagem dinâmica: Criar um diagrama de estados

UML que captura a dinâmica do comportamento;

• Modelagem conceitual e modelagem dinâmica → modelagem da especificação:

Propriedades específicas e distribuição das responsabilidades entre as classes;

• Modelagem da especificação → implementação:

◦ Implementação das estruturas entre as classes: cria um esqueleto para o

programa utilizando padrões de código para as diferentes relações entre as

classes;

◦ Implementação da estrutura interna das classes: Cria estruturas de classe

descrevendo os elementos internos que tem de ser estabelecidos antes e

depois de cada chamada de método;

◦ Implementação dos métodos: Uso padrões de algoritmo para os problemas

tradicionais de algoritmo por exemplo varredura e busca.

A modelagem do software pode ser vista em diferentes níveis de detalhes

caracterizados por diferentes degraus de formalidade:

• um um modelo conceitual informal descrevendo os conceitos chave do domínio do

problema e suas relações;

• um modelo de classes mais detalhado dando uma visão mais detalhada da

solução;

• e a implementação em uma linguagem orientada a objetos.

Este foco na perspectiva da modelagem conceitual, enfatiza que orientação a

objetos não é meramente um conjunto de soluções e tecnologias, mas uma forma de

entender, descrever e comunicar sobre o domínio de um problema e uma implementação

concreta deste domínio.

4.1.5.1 As etapas da metodologias

Na primeira metade do curso, de forma grosseira, o foco é paralelamente sobre o

entendimento e uso de um modelo conceitual como um “blue print” para programação

real. Na segunda metade do curso o foco primário é na qualidade interna do software.

Codificar e entender o modelo o conceitual são feitos de mãos dadas, de forma que

o modelo sempre vem primeiro, trazendo o código-fonte. A Introdução às diferentes

construções da linguagem são subordinadas às necessidades da implementação de um

dado conceito do modelo conceitual.

Ilustração 19: Criação sistemática de um programa orientado a objetos

4.1.5.2 O Framework conceitual

São trabalhados com ênfase três modelos conceituais básicos: 1) associação, 2)

composição e 3) especialização. O ponto de partida é uma classe, propriedades desta

classe e o relacionamento entre a classe e os objetos criados a partir dela. Uma das

propriedades de uma classe pode ser uma associação com outra classe;

consequentemente o próximo tópico é associação. Isto é correlacionado com o fato que

uma associação (referência) é o tipo mais comum de estrutura entre classes (objetos).

Composição é um caso especial de associação, sendo trabalhado logo em seguida

A última estrutura a ser coberta é especialização. Especialização faz a ponte com a

segunda metade do curso onde o foco é a qualidade do projeto onde especialização é

frequentemente utilizada como um modo de obter projetos mais flexíveis.

4.1.5.3 O início

Os estudantes iniciam por aprenderem os conceitos básicos de classes e objetos

bem como noções básicas de modelagem através de um diagrama de classes

semelhante ao diagrama da UML. Depois de terem usado classes e objetos, nós nos

voltamos para uma visão interna e começamos a escrever classes; nós fazemos isso

introduzindo o primeiro padrão de código: Implementação de uma classe.

4.1.5.4 Padrões de Código

Um padrão de código é uma descrição geral da implementação de um elemento do

framework conceitual.

Através de um número progressivo de exemplos nós mostramos que uma

associação é uma propriedade de uma classe, uma classe tem mais que uma associação

e é uma relação dinâmica.

O ensino inicia com associações recursivas de cardinalidade 1. Para poder

implementar estas associações, os estudantes precisam aprender sobre referências e o

valor null, bem como a chamada de métodos entre diferentes objetos.

A partir de diversos exemplos (1) e dos conceitos trabalhados é construída uma

abstração (2) que corresponde ao modelo conceitual trabalhado. Para esta abstração, é

apresentado um padrão de codificação (3) que permite transformá-la em código fonte

funcional.

Este mesmo processo é utilizado para composição e especialização, dando

confiança e instrumentos para que os estudantes passem a identificar e implementar os

mesmos conceitos em seus projetos

4.1.5.5 Outros elementos da metodologia

Nós usamos BlueJ como ferramenta de programação.

O foco é em um modo sistemático de programar. Isto implica em três coisas 2)

alguns exemplos são exibidos para os estudantes; 2) uso explícito da UML e 3) um foco

no processo de programação.

Uma vez que nós percebemos a importância do foco no processo de programação

e não apenas no produto final, nós passamos a usar muita codificação ao vivo. O

propósito disto é mostrar aos estudantes como um profissional de programação ataca os

problemas.

4.1.5.6 Análise Geral da Metodologia

As duas grades contribuições de Caspersen são o processo sistemático de

desenvolvimento de software e o framework conceitual e suas respectivas abstrações. Em

contrapartida, não é possível avaliar outros aspectos da metodologia apenas com o

material consultado.

4.3 Diretrizes para o Ensino de OOA partir dos trabalhos acima, foram identificadas e definidas 10 diretrizes base para

guiar o presente trabalho, são elas:

4.3.1 Princípios baseados na prática com o BlueJ

A metodologia deve seguir todos os princípios e diretrizes que servem como base

para a metodologia de Barnes que são:

• Abordagem iterativa;

• Abordagem baseada em projetos;

• Sequencia dos conceitos em vez de construções de linguagem;

• Sem cobertura completa da linguagem.

Além destes quatro princípios, são norteadoras também as 8 diretrizes

apresentadas por KÖLLING e ROSENBERG, documentadas na seção 4.1.2.1

4.3.2 Representações visuais para todas as estruturas e conceitos trabalhados

Todos os exemplos desenvolvidos e apresentados aos estudantes devem vir

acompanhados de suas respectivas visualizações. Estas visualizações devem utilizar a

UML como base, com ênfase para o diagrama de classes e diagrama de objetos.

Estruturas de controle e repetição podem se valar de diagramas de atividades e

estruturas que não possuam uma representação adequada na UML, como é o caso dos

arrays, pode ser utilizada uma outra representação específica, como por exemplo, a

sugerida por Boratti e documentada na seção 4.2.1.2.5.

4.3.3 Operações de abstração e framework conceitual

Sempre que um novo conceito de relação entre dois ou mais objetos deve ser

acompanhado de sua respectiva operação de abstração segundo Boratti e do modelo

conceitual conforme Caspersen. Estas representações devem ser utilizadas com

frequência de modo que os estudantes aprendam a enxergá-las nos problemas com

facilidade.

4.3.4 Ambiente educacional + Ambiente profissional

Até a metade do curso, os estudantes devem ser guiados do ambiente educacional

BlueJ para um ambiente de desenvolvimento profissional de preferência do instrutor. É

necessário entretanto, que pelo menos uma aula seja dedicada exclusivamente ao uso do

novo ambiente, com exercícios e práticas que demonstrem as vantagens do novo

ambiente.

4.3.5 Processo sistemático de desenvolvimento

Desde as primeiras aulas os estudantes devem ser guiados sobre as etapas do

processo de desenvolvimento de software, através de métodos sistemáticos de

desenvolvimento e também “live coding”, que corresponde ao professor resolver

problemas e tarefas de codificação ao vivo diante dos estudantes (Caspersen).

4.3.6 A partir do zero.

Tão logo os estudantes adquiram confiança com um determinado conjunto de

recursos e conceitos, estes devem ser colocados em situações de resolução de

problemas a partir de uma tela vazia ou de um projeto em branco. Inclusive o processo de

buscar classes de bibliotecas utilizadas em outros projetos é importante para o

desenvolvimento profissional.

4.3.7 Todos os recursos usados devem ser explicados

Todos os recursos utilizados pelos alunos devem ser previamente trabalhados,

mesmo que de forma breve. Desde modo, é importante que sejam evitados o uso de

métodos e/ou atributos estáticos logo no início do projeto sem uma devida explicação.

Esse tipo de abordagem pode causar confusão sobre a possibilidade de chamar um

método diretamente da classe ou do objeto.

4.3.8 Estilo de Código-fonte

Estudantes geralmente não se preocupam com nomes de classes e variáveis, bem

como edentação. É importante que desde o início o estilo do código seja padronizado pois

conforme observações do autor, os próprios estudantes acabam por se perderem em

códigos mal formatados e variáveis e classes sem diferenciação de maiúsculas e

minúsculas.

4.3.9 Lista abrangente de exercícios e desafios

Cada aula deve vir acompanhada de uma lista abrangente de atividades em níveis

crescentes de dificuldade para estimular s estudantes e permitir a aplicação dos conceitos

vistos em contextos diferentes.

4.3.10 Todos os exemplos devem envolver jogos

Todos os exemplos desta metodologia devem envolver jogos, de preferência, com

regras amplamente conhecidas, de modo que não seja necessário investir tempo para

explicar regras de um jogo ao invés de programação orientada a objetos. Isto também

objetiva criar um acervo de atividades cujos estudantes geralmente se motivam a

desenvolver.

5 Framework Java para Jogos 2DEsta seção apresentará os conceitos básicos de construção de um framework e o

desenvolvimento do framework utilizado no tutorial.

5.1 Aquisição do Conhecimento de DomínioPara realizar o estudo do domínio, serão utilizados os oito jogos produzidos na

primeira versão da disciplina conforme apresentado anteriormente. Os temas dos jogos

foram escolhidos livremente e classes foram desenvolvidas pelo professor para auxiliar o

desenvolvimento.

A primeira versão da disciplina já utilizava um framework base, de modo que muito

se aprendeu sobre o domínio e as necessidades de jogos 2D a partir do desenvolvimento

dos exemplos e das necessidades dos estudantes.

5.2 Modelagem do Framework:Para a definição do framework foi utilizado o processo conforme demonstrado por

Silva (2000).

5.2.1 Generalização

As principais generalidades dos projetos pesquisados foram identificadas e

agrupadas em pacotes lógicos. Algumas das generalidades apresentadas eram

solicitações dos estudantes que não puderam ser atendidas na primeira versão do curso:

• Pacote Entrada:

◦ Uso de informações de teclas pressionadas do teclado;

◦ Uso de informações do mouse;

◦ Captação de informações do usuário com campos de texto como nome,

números, etc.

• Pacote Saída:

◦ Desenho de formas geométricas e imagens em janelas;

◦ Criação de animações a partir de uma sequencia de imagens;

◦ Execução e pausa de sons;

• Pacote Motor:

◦ Criação de cenários complexos;

◦ Colisão com o cenário;

◦ Colisão com outros objetos;

◦ Troca de fases;

◦ Uso dos mesmos objetos em fases distintas;

◦ Comunicação entre objetos de uma mesma fase;

◦ Mapa de navegação de fases;

◦ Menus de opções;

• Pacote Física:

◦ Aceleração, gravidade, força e vetores.

5.2.2 Flexibilização

De forma geral, existem os seguintes pontos de flexibilização nos jogos

pesquisados.

• Fases: Os jogos apresentaram fases onde jogadores realizam uma luta, saltam

sobre objetos, atiram uns nos outros baseado em turnos e outros. Na versão

anterior do framework, o conceito de fase também era utilizado para mapas de

navegação em um cenário e menus de opções.

• Objetos do Jogo: Objetos de um jogo são todos os elementos que exercem

influência direta sobre o jogo como inimigos, o próprio jogador, obstáculos na tela,

itens para recuperação de vida, força ou energia, pontos de chegada, tiros, golpes

especiais, etc.

• Cenários: Muitos cenários apresentavam necessidades especificas como exibir ou

esconder determinados blocos como por exemplo para liberar uma passagem

secreta, plataformas móveis e outros.

5.2.3 Modelagem das Classes

Apresentar aqui propostas de diagramas de classes para as questões de

generalização e flexibilização acima aplicando metapadrões, padrões de projeto e

princípios de Orientação a Objetos.

(Seção ainda incompleta, a ser desenvolvida após o relatório 1)

5.3Validação(Seção ainda incompleta, a ser desenvolvida após o relatório 1)

5.4 Documentação(Seção ainda incompleta, a ser desenvolvida após o relatório 1)

6 Metodologia de Ensino(Seção ainda incompleta, a ser desenvolvida após o relatório 1. Seguem

abaixo apenas algumas ideias ainda imaturas)

A Metodologia proposta é baseada em projetos. Os estudantes são guiados para

níveis cada vez mais complexos de conceitos OO em três módulos distintos, produzindo

ao final de cada módulo um produto adequado ao nível de complexidade trabalhado:

1. Objetos Primeiro: Na primeira etapa, realizada no ambiente BlueJ, os estudantes

devem criar um objeto da classe Jogo2D e executar os métodos deste objeto. Em

um segundo momento, os estudantes criam diversas instâncias de uma mesma

classe pertencente a um projeto previamente desenvolvido de modo a

compreender o conceito de instância, de variáveis e métodos de instância. Ao final,

os estudantes criam a sua primeira classe que irá representar um jogo simples.

2. Mini-game: Nesta etapa, os estudantes desenvolvem seu primeiro jogo ainda

utilizando o BlueJ, construindo seus próprios objetos de jogo, aprendendo a usar

os métodos que envolvem receber informações do teclado e a desenhar imagens e

animações. Esta seção deverá utilizar o livro de receitas do framework. Este

projeto deve envolver pelo menos um classe para o jogo e mais duas classes para

representar objetos do jogo;

3. Jogo2D: Desenvolvimento de um jogo 2D com mais de uma fase e uso de

recursos avançados de orientação a objetos como polimorfismo, herança e classes

interface. Esta etapa irá usar a documentação detalhada do framework e deve ser

desenvolvida em um ambiente profissional de programação. Este projeto deve

possuir não menos que três fases e 5 objetos de jogo diferentes.

Segue detalhamento de cada módulo da metodologia.

6.1 Módulo 1: Objetos PrimeiroClasse representando um jogo no BlueJ

Carga horária teórica 3 horas/aulas

Carga horária prática 6 horas/aula

Produto Uma Classe Representando um Jogo

Novos Conceitos OO Classe; método; variável de instância / atributo; objetos /

instâncias; parâmetros; construtores; abstração;

Ambiente de Programação BlueJ

6.2 Módulo 2: Mini-GameTutorial apresentando um jogo básico.

Carga horária teórica X horas/aulas

Carga horária prática 2X horas/aula

Produto Um jogo contendo pelo menos 3 classes

Novos Conceitos OO Encapsulamento; composição; coesão; design de

responsabilidade.

Ambiente de Programação BlueJ

6.3 Módulo 3: Jogo 2DTutorial apresentando um jogo mais avançado com recursos como polimorfismo...

Carga horária teórica Y horas/aulas

Carga horária prática 2Y horas/aula

Produto Um Jogo com pelo menos 3 fases e 5 classes representando objetos do jogo.

Conceitos OO Herança; composição; classes abstratas; classes interface;

polimorfismo / variáveis polimórficas; métodos sobrescritos;

modificador static; tratamento exceção;

Ambiente de Programação Ambiente profissional

6.4 Avaliação da MetodologiaO ideal é que a metodologia seja avaliada a partir de sua aplicação em um

semestre de programação orientada a objetos em cursos introdutório. Em função do

tempo disponível para o TCC não foi possível validar a metodologia até o momento,

sendo esta atividade, uma recomendação para trabalhos futuros.

7 ConclusãoConclusão...

7.1 Trabalhos FuturosEnsino de Biologia, Química, Física, etc através da programação com o auxílio de

frameworks...

8 Bibliografia

8.1 Livros

Feijó, Bruno e Clua, Esteban. Introdução à ciência da computação com jogos: aprendendo a programar com entretenimento. Rio de Janeiro. Elsevier, 2010.

BARNES, David J.; KOLLING, Michael. Programação Orientada a Objetos com Java: Uma introdução prática usando o BlueJ. São Paulo: Pearson Prentice Hall, 2004. 368 pg.

KÖLLING, Michael. Introduction to Programming with Greenfoot: Object-Oriented Programming in Java With Games and Simulations. Upper Saddle River, New Jersey: Prentice Hall, 2010. 190 p.

BORATTI, Isaias Camilo. Programação Orientada a Objetos com Java. Florianópolis: Visual Books, 2007. 308 p.

8.2 Artigos e Documentos acadêmicos

KAY, Alan. Dr. Alan Kay on the Meaning of “Object-Oriented Programming”. Email de 23 de julho de 2003. Disponível em: <http://www.purl.org/stefan_ram/pub/doc_kay_oop_en>. Acesso em: 24 jun. 2012.

PROULX, Viera K.(2010). Music in Introductory Object Oriented Programming: Music and sound library for a novice Java programmer.. Constructionism 2010. Disponível em: <http://www.ccs.neu.edu/home/vkp/Papers/Music-Constructionism2010.pdf>. Acesso em: 20 jun. 2012.

PROULX, Viera K. (2009).The Pedagogy of Program Design: Design Recipe throughout BOOTSTRAP, TeachScheme!, ReachJava.. DIDINFO 2009. Disponível em: <http://www.ccs.neu.edu/home/vkp/Papers/PPD-didinfo2009.pdf>. Acesso em: 20 jun. 2012.

PROULX, Viera K.(2003). Objects From the Beginning - With GUIs: Interactive GUI-based labs for introducing objects first.. ITiCSE 2003. Disponível em: <http://www.ccs.neu.edu/home/vkp/Papers/GUIs-iticse2002.pdf>. Acesso em: 20 jun. 2012.

CASPERSEN, M.E. e Christensen, H.B. (2008): CS1: Getting Started: Reflections on the Teaching of Programming, LNCS 4821, Springer-Verlag, 2008, pp. 130-141.

BENNEDSEN, J.B. e Caspersen, M.E. (2008): Model-Driven Programming: Reflections on the Teaching of Programming, LNCS 4821, Springer-Verlag, 2008, pp. 116-129.

KÖLLING, Michael e ROSENBERG, John. 2001. Guidelines for teaching object orientation with Java. In Proceedings of the 6th annual conference on Innovation and technology in computer science education (ITiCSE '01). ACM, New York, NY, USA, 33-36. DOI=10.1145/377435.377461 http://doi.acm.org/10.1145/377435.377461

XINOGALOS, Stelios (2009). Guidelines for Designing and Teaching an Effective Object-Oriented Design and Programming Course, Advanced Learning, Raquel Hijn-Neira (Ed.), ISBN: 978-953-307-010-0, InTech, Disponível em: http://www.intechopen.com/books/advanced-learning/guidelines-for-designing-and-teaching-an-effective-object-oriented-design-and-programming-course. Acesso em 20 de junho de 2012.

M. Satratzemi, and S. Xinogalos, and V. Dagdidelis. An environment for teaching object-oriented programming: ObjectKarel. Proceedings of The 3rd IEEE International conference on Advanced Learning Technologies (ICALT 03), 342--343.

THE PEDAGOGICAL PATTERNS PROJECT (Org.).Pedagogical Patterns. Disponível em: <http://www.pedagogicalpatterns.org/>. Acesso em: 24 jun. 2012.

Clark, David; MacNish, Cara and Royle, Gordon F.. Java as a teaching language - opportunities, pitfalls and solutions, in Proceedings of the Third Autralasian Conference on Computer Science Education, ACM, Brisbane, Australia, July 1998.

8.3 Bibliografia para código-fonte e materiais didáticos desenvolvidos pelo autor

Código-fonte

CAMINHA, Kaléu. Exemplo 1: movimentando uma bola. Disponível em: <https://github.com/kaleucaminha/javaPlay2Examples/tree/master/src/exemplo1>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Exemplo 2: um primeiro jogo com o framework javaPlay. Disponível em: <https://github.com/kaleucaminha/javaPlay2Examples/tree/master/src/exemplo2>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Exemplo 3: jogo que acompanha o roteiro de 10 passos sobre o javaPlay. Disponível em: <https://github.com/kaleucaminha/javaPlay2Examples/tree/master/src/exemplo3>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Guerra Espacial. Disponível em: <https://github.com/kaleucaminha/Guerra-Espacial>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Exemplo Ryu: Etapa 1. Disponível em: <https://github.com/kaleucaminha/Ryu-Versus-Vegeta/tree/master/src/ryuversusvegeta_2>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Exemplo Ryu 2: Etapa 2. Disponível em: <https://github.com/kaleucaminha/Ryu-Versus-Vegeta/tree/master/src/ryuversusvegeta_3>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Exemplo Ryu vs Vegeta. Disponível em: <https://github.com/kaleucaminha/Ryu-Versus-Vegeta/tree/master/src/ryuversusvegeta_final>. Acesso em: 24 jun. 2012.

Material didático

CAMINHA, Kaléu. JavaPlay em 10 passos: Tutorial para desenvolvimento de um jogo simples utilizando o framework javaPlay. Disponível em: <http://www.slideshare.net/kaleu/tutorial-1-javaplay-em-10-passos>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Revisão Jogos 2D: Orientação a Objetos com Jogos 2D. Disponível em: <http://www.slideshare.net/kaleu/conceitos-de-oo-aplicados-ao-desenvolvimento-de-jogos-2d>. Acesso em: 24 jun. 2012.

Provas

CAMINHA, Kaléu. Prova 2a. Disponível em: <http://www.slideshare.net/kaleu/prova-2a>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Prova 2b. Disponível em: <http://www.slideshare.net/kaleu/prova-2b-2012>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Prova 3b. Disponível em: <http://www.slideshare.net/kaleu/prova-3a-2012>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Prova 3b. Disponível em: <http://www.slideshare.net/kaleu/prova-3b>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Prova 4a. Disponível em: <http://www.slideshare.net/kaleu/prova-4>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Prova 4b. Disponível em: <http://www.slideshare.net/kaleu/prova-4b>. Acesso em: 24 jun. 2012.

CAMINHA, Kaléu. Prova de Revisão. Disponível em: <http://www.slideshare.net/kaleu/prova-de-reviso>. Acesso em: 24 jun. 2012.

8.4 Bibliografia ConsultadaEsta seção corresponde ao conjunto de materiais que não compõe o núcleo do

trabalho, mas que contribuíram, de forma menor, para a realização deste trabalho.

Java

ALVES, William Pereira. Java 2: Programação Multiplataforma. São Paulo: Érica, 2006. 286 p.

MECENAS, Ivan. Java 2 - Fundamentos, Swing e JDBC: Programação Multiplataforma. 2. ed. Rio de Janeiro: Érica, 2006. 306 p.

DEITEL, Harvey; DEITEL, Paul. Java Como Programar. 6. ed. São Paulo: Pearson Prentice Hall, 2005.

1100 p.

HORSTMANN, Cay S.; L., Gary Cornell. Core Java: Volume I – Fundamentos. 7. ed. Rio de Janeiro: Alta Books, 2005. 568 p.

HORSTMANN, Cay S.; L., Gary Cornell. Core Java: Volume II - Recursos Avançados. São Paulo: Pearson Prentice Hall, 2003. 823 p.

Qualidade de Software

MARTIN, Robert C.. Código Limpo: Habilidades Práticas do Agile Software. São Paulo: Alta Books, 2009. 440 p.

KOSCIANSKI, André; SOARES, Michel Dos Santos. Qualidade de Software: Aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. 2. ed. São Paulo: Novatec, 2007. 394 p.