Neste EP, você deverá descobrir qual a pergunta cuja resposta é 42... OPS! Matéria errada! Não é aula do Gubi.
A idéia deste EP é aprender a trabalhar com o Squeak que será nosso ambiente de desenvolvimento ao longo do semestre. O Squeak tem
uma interface "jovial" e um conceito de program bem diferente do comum. Para isso, segue uma história à la Carlinhos:
Há muito tempo atrás, em uma galaxia muito, muito distante a Aliança rebelde se preparava para atacar a Estrela da Morte. Nossos heróis são a famosa princesa Leia, o famoso capitão Solo e o grande e desengonçado Chewbacca. Luke já estava separado da nave principal quando a princesa Leia enviou Chewie para o Millenium Falcon para ordenar o ataque imediato ao interior da estação de batalha para explodir o reator de energia. Nos juntamos ao grande Wookie assim que ele entra na nave à procura de Hans Solo.
Chegando na nave, Chewie começa a gritar pelos corredores explicando detalhadamente as ordens da princesa:
- Rowrr! rtttttttttttttttttttttt! Grwaaawaar! HHHHRRRRRROOAAAAANNNNKKKKK!
- Bora aí então bola de...hic... pêlos...
Antes que Chewie pudesse fazer qualquer coisa, Hans fecha todas as escotilhas e lança o Millenium Falcon para cima da Estrela da Morte. Chegando na cabine de pilotagem, Chewbacca encontra seu querido amigo rodeado de garrafas vazias de cerveja caseira do contrabandista Han. O capitão começa a explicar que a princesa não fala com ele e não gosta dele e que apenas o Chewie é amigo, larga os controles e se joga nos braços do Wookie. Desesperado com a situação, Chewie pergunta para o amigo se não é melhor voltar para a nave principal e abortar o ataque. Neste momento, você e Chewbacca são projetados para o ar enquanto Solo cai desmaiado de bêbado no banco do passageiro. O choque foi provocado pela destruiçao do escudo que Luke prometeu acarretando no ataque total da frota da aliança à estação espacial.
Chewie tenta desesperadamente avisar o comando central do problema em que vocês se encontram mas o rádio pifou. O destino da Aliança Rebelde está em suas mãos já que Chewie só pode controlar a estabilidade da nave e efetuar os reparos necessários para que vocês possam destruir o reator e sair vivos da batalha.
Este exercício-programa deve ajudar vocês a adquirirem alguma familiaridade com o Morphic, o arcabouço para a construção de interfaces gráficas (GUIs) do Squeak. Seria até certo ponto impreciso chamar o Morphic de um "arcabouço para interfaces gráficas" já que se trata, na verdade, de um "arcabouço para a construção de objetos interativos" (chamados de morphs). Esses "objetos interativos" constituem a base de todos os elementos da interface do Squeak - desde janelas, botões e texto até imagens e figuras animadas. O arcabouço isola o programador e o usuário de grande parte dos detalhes que fazem parte do desenvolvimento de interfaces gráficas, gerenciando automaticamente atualização de tela, despacho de eventos, leiaute e operações como arrastar-e-soltar e composição.
Parte do poder do Morphic vem de uma linguagem (gráfica) de scripts introduzida pelo arcabouço, que serve para a especificação de certas interações entre objetos (morphs). Outra parte desse poder vem do fato que o arcabouço prevê, em seu projeto, a construção de interfaces gráficas dotadas de vivacidade. Isso significa que os objetos da interface podem ser dotados de comportamentos ativos, atualizando-se automaticamente e interagindo com outros objetos a cada instante . Os "instantes" são discretos e podem ser encarados como iterações coletivas, compartilhadas por todos os morphs presentes no mundo Smalltalk. Neste exercício-programa, vamos explorar a linguagem de scripts e a possibilidade de construção de interfaces dotadas de vivacidade.
O exercício-programa consiste num jogo de computador bastante simples, em que o jogador ajuda Chewbacca a explodir o reator da estrela da morte e escapar dela. Note que os túneis da estação espacial são sinuosos e o jogador não é obrigado a sair por onde entrou. Para que seja possível controlar o Millenium Falcon, ele deve, obviamente, ser dotado de dois controles fundamentais: um para o ajuste de velocidade (acelerador/freio) e outro para o ajuste de direção (manche). Recomendo que você utilize o próprio editor gráfico do Morphic (aquele que se parece com o PaintBrush) para criar os túneis, a nave espacial e o manche. Para o controle de velocidade, você pode utilizar uma instância da classe SimpleSliderMorph. Por questões de simplicidade (e de bom senso) o jogo pode ser 2D.
Você deve ainda manter um contador na tela, que mostra a pontuação do jogador até o presente instante. A pontuação deve ser calculada da seguinte maneira:
O manche deve responder a comandos como numa nave "de verdade". Isso significa que, se o jogador estiver acelerando e virar o manche, a nave deve passar a descrever uma trajetória circular até que a posição do manche seja corrigida (não vale fazer a nave simplesmente apontar para a mesma direção do manche). O manche deve ser girado pelo botão "rotate", disponível no halo do morph que o representa.
Por fim, você deve adicionar um controle para iniciar e suspender o jogo.
A princípio você não precisa, para fazer este EP, escrever uma linha sequer de código Smalltalk. Isso não quer dizer, no entanto, que seja proibido.
Veja mais ou menos como deve ficar o seu EP aqui.
Veja a página de ponteiros para alguns tutoriais do Morphic.
Ou baixe o screencast sobre Morphic aqui.
O trabalho pode ser feito individualmente ou em grupo de duas pessoas.
Você deve entregar um arquivo contendo o projeto Squeak com a sua solução. Para criar um projeto basta clicar, com o botão da esquerda (também conhecido como botão vermelho no Squeak), em um lugar "vazio" do mundo e um menu deve aparecer. Nesse menu, clique em projects-> create new morphic project. Para exportar seu projeto, acesse, de dentro dele, o mesmo menu e clique em save project on file.... Entregue também um pequeno relatório (formato PDF ou PS, por favor) documentando a sua solução - esse relatório é especialmente importante se você decidir escrever código. O seu projeto deve funcionar no Squeak 3.9.
O trabalho deste semestre deverá ser realizado em grupos de 2 a 4 alunos e será um sistema de lembretes. O cliente será multi-usuário e deve prover funcionalidades básicas para cadastrar novas tarefas assim como relacioná-las a pessoas, datas, horários, prioridades entre outros.
Esta fase cumpre dois propósitos. O primeiro deles é aclimatá-los ao desenvolvimento no ambiente Squeak. O segundo é o desenvolvimento e a implementação do modelo que deve fundamentar o sistema de lembrete, doravante denominado 'Elefante', nas fases subseqüentes. Como nós nunca implementamos tal sistema do início ao fim, este modelo deve servir apenas como ponto inicial, e pode mudar caso apresente algum problema ou inconsistência. Essas mudanças serão devidamente discutidas e divulgadas no fórum da disciplina. Note que os programas entregues devem implementar rigorosamente as interfaces aqui descritas (o que não quer dizer, de maneira alguma, que o seu programa deve se restringir às classes especificadas abaixo). Note também que as assinaturas de métodos em Smalltalk são case-sensitive. O formato de entrega é descrito na sessão formato de entrega.
Nosso 'Elefante' organiza as tarefas dos usuários de acordo com as informações das próprias tarefas. Para deixá-los livres para implementar a arquitetura que acharem mais conveniente, todos os testes da fase 1 serão feitos por meio de uma Fachada (este é um famoso padrão de projeto que vocês irão estudar no curso). Sendo assim, a única classe obrigatória nesta fase é a classe FachadaDoElefante. Isso NÃO significa que vocês deverão fazer apenas esta classe. Significa que vocês estão livres para escolher a arquitetura que acharem mais conveniente e devem fazê-lo com muito cuidado.
EPs que forem constituídos apenas da classe FachadaDoElefante terão nota MÁXIMA 1! Vocês DEVEM fazer o máximo para diminuir o acoplamento, aumentar a coesão, distribuir responsabilidades, manter o código claro e ser consistente. Sua nota será diretamente proporcional a esses fatores.
Vocês podem baixar o conjunto de testes que define com mais detalhes qual será o uso das mensagens a seguir. Estes testes serão usados para a correção desta primeira fase. Se seu EP passar em todos esses testes e a arquitetura for razoável, a nota 5 já está garantida. Para carregar os testes, basta salvá-los em um diretório local, abrir o Squeak, clicar com o botão esquerdo, ir em "open..." e selecionar o Monticello Browser. Feito isso, clique em "Add Repository", escolha, por diretório e selecione a pasta onde salvou o mcz. Daí basta selecionar "Lembretador-Testes" e pedir para carregar. Arquivo de testes atualizado em: 15/04/2008
Para completar o resto da nota, seu EP deverá passar por mais uma bateria de testes que apenas o monitor tem, ter uma boa arquitetura de software para melhorar os fatores de acoplamento e coesão citados anteriormente. O relatório também será importante para completar o resto dessa nota.
Para os impacientes, uma prévia do que a FachadaDoElefante deve responder como mensagens é:
novoUsuario: emailDoUsuarioComoString "Devolve uma instância de usuário"
removeUsuario: emailDoUsuarioComoString "Lança exceção caso o usuário não existe"
novaTarefa: tituloDaTarefaComoString "Devolve uma instância de tarefa"
adicionaTarefa: umaTarefa para: umUsuario "Associa uma tarefa a um usuário (e vice-versa)"
naTarefa: umaTarefa mudaDescricao: umaString "Altera a tarefa com a informação passada"
naTarefa: umaTarefa mudaPrioridade: umOrdenavel "Altera a tarefa com a informação passada"
naTarefa: umaTarefa impoeDataLimite: umaData "Altera a tarefa com a informação passada"
naTarefa: umaTarefa mudaEstimativa: umaDuracao "Altera a tarefa com a informação passada"
naTarefa: umaTarefa adicionaRotulo: umSimbolo "Altera a tarefa com a informação passada"
tarefasDe: umUsuario "Devolve uma coleção de tarefas associadas ao usuário"
tarefasDe: umUsuario comPrioridade: umBloco "Devolve uma coleção de tarefas associadas ao usuário cuja prioridade é avaliada como verdadeira pelo bloco passado"
tarefasDe: umUsuario comDataLimite: umBloco "Devolve uma coleção de tarefas associadas ao usuário cuja data limite é avaliada como verdadeira pelo bloco passado"
tarefasDe: umUsuario comRotulo: umSimbolo "Devolve uma coleção de tarefas associadas ao usuário que contêm o rótulo passado"
participantesDe: umaTarefa "Devolve uma coleção de usuarios que participam da tarefa passada"
printString: umaTarefa "Devolve uma string que representa a tarefa de acordo com o formato especificado pelos testes"
pegaDataLimiteDaTarefa: umaTarefa "Devolve a data limite estabelecida para a tarefa ou nil se não houver nenhuma"
pegaDescricaoDaTarefa: umaTarefa "Devolve a descricao da tarefa ou nil se não houver nenhuma"
pegaEstimativaDaTarefa: umaTarefa "Devolve a estimativa da tarefa ou nil se não houver nenhuma"
pegaPrioridadeDaTarefa: umaTarefa "Devolve a prioridade da tarefa ou nil se não houver nenhuma"
pegaRotulosDaTarefa: umaTarefa "Devolve uma coleção de rótulos associados a essa tarefa"
Note que apesar desta fase parecer extremamente fácil de fazer sozinho, as próximas fases serão consideravelmente maiores e exigirão muito mais trabalho com necessidade de paralelizar o trabalho e integrá-lo. Por isso, realmente sugiro que façam grupos e comecem o trabalho já usando monticello e um servidor de controle de versões para integrar o trabalho. Além disso, procurem ferramentas para o squeak para ajudá-los a programar. Para aqueles acostumados com code completion e outras mordomias, olhem o Squeak-dev (o Squeak-web da mesma página pode servir para as próximas fases).
Agora que temos um modelo quase pronto, podemos para começar a criar uma interface de manipulação. Para que o nosso Elefante seja útil para vários usuários com os mais diversos sistemas, vamos criar uma interface web para ele. Para isso, vamos usar o Framework Seaside já mostrado em aula. Essa segunda fase vai ser bem grande já que temos um código existente que faz um interface bem legal para nós (ver tutorial).
De uma forma geral, a interface do elefante deve permitir que um usuário se inscreva no sistema e, feito isso, possa entrar no sistema com seu email e uma senha dada na inscrição. Uma vez logado, o usuário deve poder ver a lista de suas tarefas com as informaçõs relevantes dela (título, prioridade, estimativa e data limite). Ele deve poder então ordenar suas tarefas de várias formas assim como alterá-las. Por fim, ele deve poder ver uma tarefa com seus detalhes e, nesta página, compartilhar tarefas com outros usuários informando o e-mail destes (e ser informado em caso de sucesso ou falha no envio do convite assim como a resposta do usuário).
Da mesma forma que na fase 1, sua nota será, em partes, proporcional à quantidade de testes que vocês conseguirem passar. Novamente, para deixá-los livres para implementarem o sistema como acharem melhor, serão usados testes que não exigem nada sobre as interfaces usadas. A ferramenta para realizar esses testes é o Selenium e todos os testes serão feitos com base em propriedades do HTML gerado como id e class. Os testes exigirão alguns dados iniciais cadastrados na sua aplicação. Gostaria que esses dados fossem cadastrados ao instalar o SAR e não de forma inserida nos seu código.
Vocês podem baixar os testes (finais - salvo correções) aqui. Atualizado dia 28/05/2008 (apenas mudando para clickAndWait na linha 108 do teste TesteCompartilhamento - veja fórum para mais detalhes).
Para executá-los, o jeito mais fácil é utilizar o Selenium IDE (baixar aqui). Ele é um plugin para o Firefox
cuja interface estará disponível no menu "Ferramentas" ou "Tools". Abram a janela e carreguem os testes um a um clicando na flecha verde para executá-los. Para rodar todos os
testes de uma vez, usem a seguinte URL no Firefox (abrir do Selenium IDE não funciona para Suites):
chrome://selenium-ide/content/selenium/TestRunner.html?test=file:///path/para/seu/arquivo/TodosOsTestes.html&baseURL=http://localhost:8080/seaside/
Ou usem o Selenium-core para isso (dica: é bem parecido com isso que mostrei).
Para aqueles que não usam Firefox, usem-o! Mas caso contrário, vocês ainda podem rodar os testes graças ao Selenium Core. Deixo, no entanto, vocês se virarem com isso. A página da open-qa possui bastante informação a respeito.
Para que o renderizador do Seaside gere os atributos 'id' e/ou 'class', basta passar para o elemento que deve ter o atributo a mensagem "id: 'nome do id'" ou "class: 'nome da classe'". Como na fase 1, uma parte dos testes será liberada e ela garantirá nota 3. Mais 2 pontos virão dos outros testes para essas funcionalidades básicas. Outros 2 pontos virão da arquitetura de seus componentes e da estrutura da aplicação e do relatório descrevendo sua solução e listando os itens (a seguir) que fizeram. Para atingir nota 10, vocês deverão escolher 2 das funcionalidades na lista abaixo:
Lembrem-se de caprichar na interface com o usuário. Afinal, ninguém vai querer usar o Elefante se ele não deixar claro quais são as tarefas do usuário e quão urgente elas são. Como a fase 1 e a fase 3, esta fase deve ser entregue pelo paca com o formato de entrega já especificado. Se o formato de entrega (nome do arquivo, formato do arquivo, etc...) não for respeitado, a nota final sofrerá um desconto de 1 ponto para cada diferença.
A fase 3 será bem semelhante à fase 2 com duas principais diferenças.
A primeira é que vocês deverão trabalhar com o código de outro grupo justificando muito bem porque escolheram esse grupo. Se realmente acharem que o código de nenhum grupo agrega algo ao seu EP, justifiquem ainda mais essa escolha. Vocês podem, ou não, juntar-se a outro grupo para fazer o trabalho e usar código de terceiros mas também devem justificar essa escolha. O objetivo disso é que vocês analisem, critiquem e usem um código produzido por outras pessoas além de dar a chance das pessoas que fizeram uma fase 2 ruim, poderem ter uma excelente fase 3. Caso vocês unam grupos, espero que vocês conversem com o outro grupo para escolher a base de código para elaborar a fase 3. Essa base pode ser o código de outro grupo ou uma mistura dos v´rios códigos. Vocês sabem que eu olho o código de todos os grupos então, por favor, não tentem me enganar omitindo que pegaram um certo código. Sejam claros e honestos no relatório sobre suas escolhas. Vejam aqui a lista de grupos e trabalhos da fase 2.
A segunda diferença é que acabaram as restrições e, com elas, a moleza. Não há nenhuma parte obrigatória nesta fase. Vocês deverão escolher as funcionalidades que acharem mais interessantes da lista abaixo. Se não gostarem das minhas sugestões, vocês podem propor, com uma certa antecedência (de no mínimo 1 semana), novas funcionalidades que, se avaliadas como equivalentes, serão adicionadas a essa lista. Além das funcionalidades (e por isso disse que acabou a moleza), espero que você entreguem testes (tanto Selenium quanto SUnit quando aplicáveis) que verifiquem suas funcionalidades (e que passem).
A nota do trabalho (dada a todos cujo nome estiver no relatório) será baseada em vários fatores. O primeiro é o relatório. Como essa fase é muito mais livre, espero que o relatório seja suficientemente completo para que eu entenda as decisões tomadas, as funcionalidades implementadas, a arquitetura desenvolvida e os possíveis problemas e/ou dificuldades encontradas para fazer o trabalho. Gostaria de ver também uma auto-avaliação com respeito ao sistema desenvolvido. O que vocês acharam que precisaria incluir para que o sistema ficasse usável e o quão útil ele pode ser. Também será avaliada a decisão do grupo da base de código a ser usada assim como o resultado final da arquitetura e do nível de acoplamento e de coesão do seu sistema. Por fim, vocês devem entregar um mínimo de 6 funcionalidades sendo que NÃO contam as funcionalidades já incluídas no código de base. Funcionalidades de outros grupos podem ser usadas desde que o relatório explique como vocês as integraram no seu trabalho. Segue a lista de funcionalidades sugeridas:
Também levarei em conta a usabilidade do sistema no sentido que descontarei pontos se for muito complicado de cumprir algum dos objetivos que vocês se propuseram a permitir. Lembrando que espero receber o trabalho no formato de entrega especificado aqui que é o mesmo da fase 2. Lembrando que uma entrega só por grupão basta. Como na fase 2, se o formato de entrega (nome do arquivo, formato do arquivo, etc...) não for respeitado, a nota final sofrerá um desconto de 1 ponto para cada diferença.
Os grupos da mesma cor (que não pretos) são grupos que estão juntos para a fase 3.
| Integrantes | Código fonte |
| Adriano Massuia, Helio Campos, Fernando Waitman | Adriano_Fernando_Helio.sar.zip |
| Alexandre Barbosa de Macedo, Daniel Grecco Machado, Edson Kenji Ninomiya, Fábio Tsuguta Matsumoto | AlexandreBarbosaDeMacedo-DanielGreccoMachado-EdsonKenjiNinomiya-FabioTsugutaMatsumoto.tar.gz |
| Ana Paula Oliveira dos Santos, Ariel Martini, David da Silva Peres, Paulo Meirelles | ana-ariel-david-paulo.tgz |
| Mateus Santos, Anderson F. Machado | Anderson-Mateus.tar.gz |
| Marcio Masaki Tomiyoshi, Fernando Lemes da Silva, André Jucovsky Bianchi, Ricardo Alexandre Bastos | AndreBianchi-FernandoLemes-RicardoBastos-MarcioTomiyoshi.tar.gz |
| Breno Flesch Franco, Cecilia Fernandes, Luiz Fernando Oliveira Corte Real | BrenoFlesch-CeciliaFernandes-LuizReal.tar.gz |
| Cauê Haucke Porta Guerra, Leandro de Moraes | CaueHauckePortaGuerra-LeandroDeMoraes.tar.gz |
| Diego Mira David, Helio Tsutomu Matayoshi, Fábio Yoshio Sato | EP2-Diego-Fabio_Helio.tar.gz |
| Pablo Calcina, André Marcos | ep2-pcc-ams.sar |
| José Antonio Cardoso Marum Junior, Lucas Ikeda França, Melissa Cheau Chen Liang | JoseMarum-LucasIkeda-MelissaLiang.tar.gz |
| Pedro Paulo de Souza Bento da Silva, Rafael de Oliveira Lopes Gonçalves, Rafael Issao Miyagawa, Vivian Lababde Cury | RafaelIssao-VivianLababde-PedroPaulo-RafaelLopes.zip |
| Saulo de Oliveira, Renato Coelho, Vitor Eiji Justus Sakaguti | saulodeoliveira-renatocoelho-vitorsakaguti.tar.gz |
O formato de entrega será o Squeak ARchive. Um Squeak ARchive é um arquivo ZIP (pode ser criado com o utilitário ZIP no Linux, com o WinZIP ou uma pasta compactada no Windows) cuja extensão foi trocada para .sar. Ele apresenta uma estrutura simples, que segue algumas convenções:
./install/preambleTrecho de código executado primeiro
./install/postscriptTrecho de código executado após o preamble (hã... também não sei muito bem prá que serve isto).
Esses arquivos dizem ao SARInstaller como processar os arquivos de projeto providos junto com o SAR e podem
conter código de inicialização arbitrário. Os arquivos de projeto são aqueles que contêm o código do programa de
fato. Esses arquivos podem ser o resultado de file outs (.st), pacotes monticello (.mc/.mcz), change sets(.cs), entre outros. Eu recomento o uso do
Monticello, já que é mais fácil organizar e exportar pacotes com a ajuda dele. O código inserido
nos arquivos preamble e postscript será executado no contexto de uma instância de SARInstaller. Cabe a você dizer ao SARInstaller quais
arquivos processar e como. Por exemplo, o seguinte preamble:
self openGraphicsFile: 'umGrafico.jpg'. self fileInMonticelloZipVersionNamed: 'projeto.mcz'. self openTextFile: 'instruções-de-uso.text'. MyWeirdClass doSomeInitialization.
Abre uma imagem na tela, carrega um pacote Monticello, abre uma janela com o conteúdo de um arquivo de texto e chama o método 'doSomeInitialization' na classe 'MyWeirdClass'.
Além do arquivo SAR, eu gostaria que vocês entregassem:
Ambos os documentos devem ser entregues como arquivos PS ou PDF, para evitar problemas com formatos.
Tudo isso deve ser entregue através do paca em um arquivo NomeDoAluno1-...-NomeDoAluno4.tar.gz. Este arquivo deve conter seu relatório (em PDF ou PS), seu arquivo SAR e um arquivo puro texto chamado README com o nome dos integrantes do grupo. Apenas um membro do grupo precisa entregar o arquivo. Lembrem-se também de citar, no relatório (além do README), quais são os integrantes do grupo (isso inclui seu próprio nome) de forma a evitar maiores problemas.
O Monticello é um sistema para controle de versões no Squeak. Pode ajudar a integrar código realizado de forma distribuida além de permitir a volta a versões antigas evitando problemas com uma mudança para uma falsa solução (que parecia certa mas não era). Para mais informações, visite a página oficial do projeto.
Existe este tutorial muito bom além do tutorial feito pela Mari ano passado. Além disso, devo fazer um screencast a respeito mas isso pode ficar tarde.
