Frameworks e Componentes

Projeto

O projeto da disciplina consiste em desenvolver 3 aplicações relacionadas usando frameworks e componentes. Num primeiro momento, 3 aplicações relacionadas, isto é, do mesmo domínio de problema, são desenvolvidas usando pelo menos 3 design patterns diferentes (na soma dos programas, não necessariamente em cada um). Nestes programas, testes de unidade devem ser realizados com o framework de testes JUNIT. Em seguida, um framework usando componentes deve ser projetado para o domínio de problema sob consideração e as aplicações reescritas usando o framework.

Você pode escolher o domínio do problema, mas lembre que as aplicações devem ser pequenas, já que 3 aplicações serão escritas, cada uma em duas versões. Sugerimos que você utilize "jogos de cartas" como domínio de problema. Especificamente, o domínio de problema "jogos de poquer" ou "jogos de paciência" poderiam ser escolhidos como domínios de problema, já que vários tipos similares de tais jogos existem. Uma sugestão segue abaixo. Observe que as aplicações não precisam ter capricho visual e não precisam sequer utilizar interface gráfica (mas seria legal, né?).

Você pode formar equipes de 2 pessoas. Os programas devem ser desenvolvidos em uma das seguintes linguagens: Java (de preferência), C++, Object Pascal. O paradigma deve obviamente ser Orientado a Objeto. Observe entretanto que o framework JUNIT utilizado no projeto não está disponível para qualquer linguagem.

Antes de iniciar o projeto, vale a pena ler o artigo: Evolving Frameworks.

A lista de milestones e detalhes do que entregar ao professor para cada milestone seguem.

  1. Entrega dos requisitos funcionais e de interface dos programas a desenvolver. Entregue uma descrição dos requisitos funcionais e uma idéia de como será a interface dos três programas. O motivo de eu pedir detalhes da interface é de ter certeza de que não haverá capricho demais (para que você não perca tempo).
  2. Entrega do primeiro programa. Entregue o código fonte documentado. Se usar Java, entregue também a saída do javadoc. Nos comentários, identifique claramente os design patterns utilizados. Adicionalemente, entregue o código fonte de todos os testes de unidade realizados. Use o framework de testes JUNIT disponível na home page. Se o framework não existir para sua linguagem, você terá que implementá-lo (como isso é trabalhoso, talvez seja melhor mudar de linguagem). Não esqueça de entregar um arquivo de lote (.bat) ou script (se for feito no unix) para executar seu programa e outro para executar os testes.
  3. Entrega do segundo programa. Idem.
  4. Entrega do terceiro programa. Idem.
  5. Entrega do design do framework. Entregue o modelo de projeto (diagramas de classe) documentado. Se usar Java, entregue também a saída do javadoc indicando que o design detalhado está feito. Lembre que o framework deve ser baseado em componentes; portanto, identifique bem quais são componentes, suas propriedades e como eles se interligam. Deixe bastante claro num documento à parte como o framework é usado para contruir uma nova aplicação (devo instanciar o quê? conectar o quê?, ...).
  6. Entrega do framework com 3 aplicações.Entregue o código fonte documentado do framework e dos testes de unidade. Se usar Java, entregue também a saída do javadoc. Entregue também um documento consistindo de 2 partes. A primeira é um manual do usuário do seu framework. A segunda é uma comparação criteriosa entre as implementações das aplicações com e sem framework. Inclua uma indicação de do percentual de código que cada aplicação deve adicionar ao framework. Não esqueça de entregar um arquivo de lote (.bat) ou script (se for feito no unix) para executar as aplicações e outro para executar os testes.

Uma sugestão para os três programas

Se você não achar um domínio de problema adequado, considere os três jogos abaixo, todos variantes de um jogo de paciência. Os três jogos podem ser vistos em ação no pacote Pretty Good Solitaire.

Jogo 1: Aces Up

Partes do Jogo

Início

Quando o jogo é iniciado, o Estoque contém todas as cartas do baralho. Logo em seguida, 4 cartas são retiradas do Estoque e dispostas no Tableau, uma em cada pilha.

Objetivo do Jogo

Mover todas as cartas do Estoque para a Fundação.

Regras

Dicas

Jogo 2: Baker's Dozen

Partes do Jogo

Início

Quando o jogo é iniciado, as 13 pilhas do Tableau são preenchidas com 4 cartas cada, de maneira que os reis permaneçam no final de uma pilha. As 4 Fundações iniciam vazias.

Objetivo do Jogo

Mover todas as cartas para as Fundações em ordem crescente a partir do ás. O jogo termina quando todas as cartas foram movidas para as Fundações, completando todos os naipes (situação em que o jogador vence o jogo) ou quando não é mais possível movimentar as cartas do Tableau.

Regras

Jogo 3: Captive Queens

Partes do Jogo

Início

Quando o jogo é iniciado, o Estoque contém todas as cartas do baralho. Todas as outras pilhas iniciam vazias.

Objetivo do Jogo

Completar todas as pilhas e os lugares das rainhas com as cartas do Estoque.

Regras

Glossário de termos

Fundação

Pilha de cartas onde o objetivo é construir sobre uma cartas base, normalmente numa sequência. Na maioria dos jogos, as fundações são contruídas "para cima por naipe", embora esta regra varie. Também, uma vez que cartas são movidas para fundações, elas normalmente não podem ser movidas novamente. Ganha-se a maioria dos jogos de paciência quando todas as cartas foram movidas para as fundações.

Tableau

Pilhas de cartas onde a construção (ou empacotamento) é normalmente permitido. Cartas podem ser empacotadas nas cartas expostas de cada pilha, de acordo com regras que variam de jogo para jogo. Normalmente, o jogo inicia com um certo número de cartas em cada pilha.Quando todas as cartas de uma pilha tableau foram jogadas em outro lugar, há normalmente uma regra indicando se, e que tipo de cartas podem ser movidas para o lugar vazio.

Estoque

Uma pilha contendo o restante das cartas quando as demais foram arrumadas para o jogo. Cartas são normalmente retiradas do estoque e jogadas de alguma forma, por exemplo, para uma pilha de descarte ou para as pilhas tableau.

Pilha de descarte

Uma pilha onde cartas não jogáveis são colocadas. Normalmente, a carta no topo da pilha de descarte pode ser jogada em outras pilhas. Em alguns jogos, a pilha de descarte pode ser invertida para assumir a posição de pilha de estoque. Isso se chama "redeal".

Reserva

Um grupo de pilha(s) nas quais a construção normalmente não é permitida. Em alguns casos, todas as cartas de uma reserva estão disponíveis para o jogo, enquanto em outros casos, apenas a carta de cima está disponível.

Construir para cima em naipe

Jogue uma carta de um valor acima e do mesmo naipe da carta alvo. Por exemplo, jogue um 5 de copas.gif (897 bytes) num 4 de copas.gif (897 bytes).

Construir para baixo em naipe

Jogue uma carta de um valor abaixo e do mesmo naipe da carta alvo. Por exemplo, jogue um 8 de ouros.gif (889 bytes) num 9 de ouros.gif (889 bytes).

Construir para cima sem consideração de naipe

Jogue uma carta de um valor acima da carta alvo e de qualquer naipe. Por exemplo, jogue um 9 de copas.gif (897 bytes) num 8 de espadas.gif (901 bytes).

Construir para baixo sem consideração de naipe

Jogue uma carta de um valor abaixo da carta alvo e de qualquer naipe. Por exemplo, jogue um 9 de copas.gif (897 bytes) num 10 de espadas.gif (901 bytes).

Construir para cima alternando cores

Jogue uma carta de um valor acima da carta alvo e trocando a cor da carta. Por exemplo, jogue um 9 de copas.gif (897 bytes) num 8 de espadas.gif (901 bytes).

Construir para baixo alternando cores

Jogue uma carta de um valor acima da carta alvo e trocando a cor da carta. Por exemplo, jogue um 7 de copas.gif (897 bytes) num 8 de espadas.gif (901 bytes).

Redeal

Inverter a pilha de descarte para que ela passe a ser a nova pilha de estoque. Alguns jogos permitem um único redeal enquanto outros permitem um número ilimitado de redeals.