Artigo - Magic: Um Framework para Jogos de Cartas

Framework para jogos de cartas
por André Luís Knabben e Thiago Robert
Professor Doutor Ricardo Pereira e Silva
Orientador
Resumo
Projetar artefatos de software visando a reusabilidade é uma tarefa complexa.
Frameworks e padrões de projeto são artefatos de software reusáveis que buscam facilitar o
desenvolvimento de aplicações. O presente documento consiste na descrição do
desenvolvimento de um framework OO generalizando o domínio dos jogos de cartas,
utilizando padrões de projeto.
Abstract
Designing reusable software artifacts is a complex task. Frameworks and design
patterns are reusable software artifacts that can be used to speed application development.
The present paper consists in the description of the development of a card games OO
framework, using design patterns.
Introdução
Há décadas, a reusabilidade vem sendo uma das principais metas dos engenheiros de
software. Entretanto, reusar software não é nada simples e a maior parte dos esforços nesse
sentido acabou gerando apenas pequenos componentes caixa-preta. Com a popularização
do paradigma OO, tornou-se possível desenvolver componentes reusáveis de maior

granularidade, entre eles os frameworks OO. Atualmente existem frameworks para uma
grande variedade de domínios, entre eles podemos citar o MVC do Smalltalk e o AWT do
Java.
Frameworks são artefatos reusáveis de alta granularidade. A utilização de um
framework tem como objetivo a redução no tempo e no custo de criação e manutenção de
novas aplicações que pertençam ao domínio tratado por esse framework. Além disso, a
utilização desses artefatos de software resulta em aplicações mais confiáveis, pois, estando
o framework depurado, o desenvolvimento deixa pouca margem à inserção de erros.
Frameworks Orientados a Objetos
Um framework é um conjunto de classes integradas que define uma estrutura reusável
para um domínio específico de aplicações. O framework provê uma arquitetura
particionada em classes abstratas e define as responsabilidades e um modelo de colaboração
para essas classes. O desenvolvedor adapta o framework para uma aplicação particular
especializando e agregando instâncias de suas classes. A figura abaixo ilustra uma
aplicação desenvolvida a partir de um framework. A estrutura em azul corresponde ao
framework e o restante é o que foi produzido pelo usuário do framework no
desenvolvimento dessa aplicação específica.
Figura 1.
Uma aplicação desenvolvida sob um framework OO.
Frameworks portam a infra-estrutura de projeto, característica que reduz a quantidade
de código a ser desenvolvida na criação de aplicações. O modelo de colaboração entre as

classes de um framework define a arquitetura da aplicação livrando o desenvolvedor dessa
responsabilidade.
A arquitetura dinâmica de um framework é caracterizada por uma inversão de
controle. A inversão de controle permite que o framework (e não a aplicação) determine
que métodos invocar em resposta a eventos.
Desenvolvimento de Frameworks
O desenvolvimento de um framework é ligeiramente diferente do desenvolvimento de
uma aplicação comum. A grande diferença é que um framework tem que cobrir os
conceitos relevantes a um domínio enquanto uma aplicação cobre apenas os conceitos
mencionados nos seus requisitos. O desenvolvimento de um framework pode ser dividido
da seguinte maneira:
Análise do Domínio
A análise de domínio é o processo de identificação e organização de conhecimentos a
respeito de uma classe de problemas – um domínio de aplicações – para suportar a
descrição e solução desses problemas. É um passo fundamental na criação de artefatos de
software reusáveis, pois elementos gerados através de uma análise de domínio capturam a
funcionalidade essencial requerida por um domínio.
Uma análise de domínio é um passo importante no desenvolvimento de frameworks,
pois faz com que o desenvolvedor do framework obtenha uma maior compreensão dos
conceitos do domínio, funcionalidades e hot spots que um framework deve possuir.
Modelagem
A modelagem de um framework consiste na especificação da estrutura de classes

desse framework. Essa estrutura de classes deve possuir algumas características
importantes:
• Generalidade – reflete a capacidade do framework de alterar suas
funcionalidades, tendo em vista as necessidades de uma aplicação específica.
• Extensibilidade – refere-se à manutenibilidade do framework. O
desenvolvimento de frameworks é um processo iterativo, isto é, à medida que
o framework é utilizado novos recursos podem ser agregados a sua estrutura.
Assim, durante o projeto de um framework, deve-se tentar prever futuras
utilizações para este framework e futuras extensões no domínio tratado.
Implementação
A implementação de frameworks segue as linhas gerais da implementação de uma
aplicação comum. Todas as técnicas e padrões para o desenvolvimento de código podem
ser usados na implementação de um framework.
É importante ressaltar que o sucesso da implementação de um framework depende da
qualidade do projeto desse framework. Todas as características definidas durante a fase de
projeto devem ser mantidas na fase de implementação para que o framework não perca sua
capacidade de generalizar um domínio de aplicações.
Testes
Um framework é validado através da criação de aplicações teste, usadas para
determinar se o framework provê as funcionalidades desejadas e para avaliar sua
usabilidade.
Se, no processo de criação de aplicações, forem encontradas características do
domínio tratado que não estão presentes no framework deve-se reavaliar o projeto e
atualizar a implementação do framework para que essas características sejam adicionadas.

Essa retro-alimentação faz parte do ciclo de vida dos frameworks.
Documentação
O desenvolvimento e a utilização de frameworks são tarefas complexas e, por isso,
uma boa documentação é essencial. A documentação deve prover informações sobre o
domínio tratado pelo framework, sua estrutura e funcionamento.
Frameworks podem ser descritos a partir de notações de metodologia OOAD como,
por exemplo, a UML. Essa descrição pode ser uma ótima fonte de informação sobre o
framework e, portanto, uma documentação valiosa.
Uma outra forma de documentação é a que ensina a usar o framework para gerar
aplicações. Esse tipo de documentação dá pouca ênfase a aspectos de projeto concentrandose
na descrição do processo de criação de aplicações sob o framework. Um exemplo desse
tipo de documentação é o cookbook.
Cookbooks são conjuntos de receitas textuais para a utilização de um framework. Sua
principal vantagem é a capacidade de responder a questões chave minimizando o tempo
gasto para produzir aplicações. O principal problema dessa abordagem é que ela cobre uma
faixa limitada de tipos de aplicação. O auxilio proveniente do uso de um cookbook pode ser
ínfimo no caso das necessidades do usuário não se ajustarem ao conjunto de problemas
tratados pelo cookbook. [SIL 00]
Outro modo de documentar um framework, talvez o mais elementar, é a
disponibilização de código fonte aos usuários. O código fonte de um framework ou de
aplicações desenvolvidas sob esse framework é uma rica fonte de documentação.
Entretanto, é muito difícil entender o funcionamento de um framework apenas pelo seu
código fonte e, por isso, é recomendável que o código não seja a única fonte de referência
disponibilizada pelo autor do framework.

Padrões de Projeto
Um padrão de projeto nomeia e explica sistematicamente uma solução geral para um
problema recorrente em sistemas OO.
O padrão de projeto descreve o problema, a solução, quando aplicar a solução e as
conseqüências de sua aplicação. A solução é uma estrutura de classes e objetos que resolve
o problema.
Padrões de projeto capturam a essência de uma idéia que projetistas experientes
usaram diversas vezes para resolver um problema comum, abstraindo-se da situação
específica. Por isso, os padrões de projeto são independentes da aplicação e tem que ser
mapeados para uma situação específica antes de serem implementados.
Framework para Jogos de Cartas
O domínio dos jogos de cartas pode parecer simples à primeira vista, entretanto, é um
domínio vasto e sua análise e generalização exige muita atenção com os detalhes sutis que
poderiam passar despercebidos. A generalização desse domínio em um framework tem o
objetivo didático de fixar os aspectos referentes ao desenvolvimento e utilização de
frameworks.
Análise do Domínio
Analisando várias aplicações no domínio de jogos de cartas pode-se chegar a três
entidades básicas:
• Carta – comum a todos as aplicações desse domínio, essa é a entidade básica
de qualquer jogo de cartas.
• Baralho – todas as cartas de um jogo fazem parte de um baralho.

• Conjunto de cartas – a ação mais comum de um jogador num jogo de cartas é
mover uma carta de um conjunto de cartas para outro.
A quantidade de entidades desses tipos, a interação entre essas entidades e a interação
do usuário com essas entidades varia dependendo do jogo.
Projeto
Procurou-se modelar o framework tendo em vista a generalidade, extensibilidade e
interoperabilidade. O projeto é genérico e pode ser usado como base para o
desenvolvimento de frameworks para jogos de cartas em qualquer linguagem e para
qualquer plataforma.
Hierarquia de Classes – Card
Cartas são o elemento básico de todos os jogos de cartas. Cada jogo possui diferentes
tipos de carta e por isso a classe Card é um hot spot. FourSuitCard é uma implementação
concreta de Card e refere-se à carta comum (com um número e um naipe) usada na maioria
dos jogos. SetOfCards é simplesmente um conjunto de cartas. PileOfCards representa uma
das diferentes pilhas encontradas nos jogos, como, por exemplo, a mão de um jogador ou a
pilha de compra.

Model
AttributedModel
Card *
SetOfCard
FourSuitCard
HOT SPOT
PileOfCards
setAddCondition()
setRemoveCondition()
Figura 2.
Hierarquia de modelos presente no framework de jogos de cartas.
PileOfCards
PileOfCards
chainRemoval : boolean
defaultCardOrientation : boolean
LAYOUT_TYPE_HORIZONTAL : int = 2
LAYOUT_TYPE_PILE : int = 0
LAYOUT_TYPE_VERTICAL : int = 1
addCardTestingCondition()
enableConditions()
isChainRemovalOn()
isDragEnabled()
removeAndSaveTestingCondition()
removeCardTestingCondition()
restoreSavedCard()
setAddCondition()
setDrag()
setRemoveCondition()
PileOfCards implementa um monte
qualquer dentro de um jogo de cartas. Esse
monte pode ter vários layouts diferentes, como
uma carta sobre a outra, uma ao lado da outra
ou em cascata vertical.
É essa classe que contém as regras do
jogo, dizendo qual carta pode ser movida para
qual lugar através de condições de entrada e
saída de cartas. Essas condições são
implementadas através das classes descritas a
seguir e seus métodos são invocados sempre que o usuário tenta remover uma carta de

algum PileOfCards e quando ele tenta adiciona-la em outro. Essa classe define também se a
remoção de uma carta do meio do baralho (utilizado em geral com o layout cascata) deve
efetuar a remoção de todas as cartas a partir dessa (para mover uma coluna no jogo
Paciência, por exemplo). Além disso, o método removeAndSaveTestingCondition()
permite a remoção de uma carta ou de um conjunto de cartas mantendo uma referência à
lista removida. Dessa forma as visões são atualizadas, excluindo as cartas removidas, mas
um simples método (restoreSavedCard()) faz com que as cartas sejam adicionadas
novamente no monte na posição em que estavam antes da remoção. Isso facilita, por
exemplo, a implementação de drag and drop, pois permite anular o drag caso o destino não
aceite as cartas sendo movidas.
As condições para entrada e saída de cartas implementam o padrão de projeto
Strategy, permitindo que um algoritmo seja trocado a qualquer hora, porém sem colocar a
implementação de cada tipo de algoritmo dentro da classe que usa ele.
As classes AddCardCondition e RemoveCardCondition possuem métodos que devem
retornar verdadeiro se a alteração (inclusão ou remoção de carta) for aceita e falso caso
contrário. Os parâmetros passados para essas funções contêm informações que possibilitam
a implementação de uma grande quantidade de algoritmos, sendo que a maioria deles
utilizará apenas um subconjunto dos dados fornecidos. Os parâmetros fornecidos diferem
entre AddCardCondition e RemoveCardCondition.
AddCardCondition
testAdd()
testAdd()
*
HOT SPOT
SpecificSuitAddCondition
InOrderAddCondition
CompositeAddCondition

Figura 3.
Hierarquia de condições para adição de cartas em um PileOfCards.
RemoveCardCondition
testRemove()
testRemove()
*
HOT SPOT
OnlyLastCardsRemoveCondition TrueRemoveCondition CompositeRemoveCondition
Figura 4.
Hierarquia de condições para remoção de cartas em um PileOfCards.
Criação de um Jogo
A criação do jogo consiste em especializar a classe CardGame implementando os
seguintes métodos abstratos:
• createPiles – inicializar as pilhas do jogos, que devem estar previamente
definidas.
• createPlayers – inicializar os atributos dos jogadores.
• distributeCards – criar o baralho a ser usado no jogo e o distribuidor de
cartas. Distribuir as cartas.
• createInterface – criar a interface para o jogo definido, painéis necessários,
layouts, etc.
Figura 5.
Classe Básica de um jogo de cartas.

Testes
Aplicações teste foram desenvolvidas para avaliar a capacidade do framework de
facilitar o desenvolvimento de aplicações no domínio proposto. Além de validar o
framework para jogos de cartas, as aplicações teste serviram também para validar o
framework para interface gráfica.
FreeCell
O FreeCell é um jogo de cartas simples e muito popular. O objetivo do jogo é ordenar
as cartas em quatro pilhas, uma para cada naipe. Existem três tipos de pilhas de carta nesse
jogo:
• Destinos – existem quatro pilhas desse tipo, uma para cada naipe. Todas as
cartas devem estar em um destino para que o jogo acabe.
o Condição de entrada – as cartas devem ser adicionadas em ordem
crescente e todas as cartas de um destino devem ser do mesmo naipe.
o Condição de saída – depois de adicionada em um destino, uma carta
não pode ser retirada.
• Espaços – essas pilhas são usadas para armazenar temporariamente uma carta
durante o jogo. O número de espaços é configurável.
o Condição de entrada – qualquer carta pode ser adicionada em um
espaço, independentemente de seu naipe ou número. Entretanto, cada
espaço comporta no máximo uma carta.
o Condição de saída – uma carta sempre pode ser retirada de um espaço.
• Pilhas de jogo – essas pilhas são usadas para movimentar as cartas durante o
jogo. O número de pilhas desse tipo é configurável.
o Condição de entrada – as cartas devem ser adicionadas em ordem
decrescente. A carta adicionada deve ser de cor diferente da última
carta na pilha.

o Condição de saída – somente a última carta da pilha pode ser retirada.
Inicialmente, as cartas do baralho são distribuídas de forma aleatória entra as pilhas
de jogo.
Espaços
Destinos
Pilhas de jogo
Figura 6.
Screenshot do jogo FreeCell.
Conclusões
A estrutura de classes de um framework, bem como o modelo de colaboração entre
essas classes, é bastante complexa. Projetar e implementar essa estrutura exige um alto
nível de conhecimento das técnicas e ferramentas para projeto e desenvolvimento OO. Por
essa razão, desenvolver um framework abrangente e extensível é um ótimo exercício dessas
técnicas.
Além disso, o desenvolvimento de aplicações sob um framework explicita a

importância do reuso. Um framework bem abrangente facilita muito o desenvolvimento de
aplicações no domínio tratado.
Entretanto, o desenvolvimento de um framework exige um esforço bem maior do que
o desprendido para criar uma aplicação isolada. Uma análise detalhada do domínio alvo e
da relação custo beneficio do desenvolvimento de um framework deve fazer parte da
análise de requisitos de um projeto qualquer que tencione criar um framework para um
domínio específico.
Os padrões de projeto, utilizados durante a modelagem e implementação dos
frameworks descritos nesse documento, são referências importantíssimas no
desenvolvimento de aplicações OO. Além de facilitar o projeto e implementação, os
padrões são uma boa fonte de documentação para a interação entre classes de um
subsistema de uma aplicação OO qualquer.
Referências Bibliográficas
[DOU 99] DOUGLASS, B. P. Doing Hard Time: Developing Real-Time Systems with
UML, Objects, Frameworks, and Patterns. [s.l.]: Addison Weasley, 1999.
[FAY 99] FAYAD, M. et al. Building Application Frameworks. New York: Wiley, 1999.
[GAM 99] GAMMA, E. Design patterns: elements of reusable object-oriented software.
Reading: Addison Wesley, 1994.
[LEW 95] LEWIS, T. et al. Object-oriented application frameworks. Greenwich:
Manning, 1995.
[MEY 97] MEYER, B. Object-oriented software construction. 2 ed. [s.l.]: Prentice Hall
PTR, 1997.
[SIL 98] SILVA, R. P.; PRICE, R. T. A busca de generalidade, flexibilidade e
extensibilidade no processo de desenvolvimento de frameworks
orientados a objetos. In: WORKSHOP IBEROAMERICANO DE
ENGENHARIA DE REQUISITOS E AMBIENTES DE SOFTWARE,

(IDEAS), 1998, Torres. Anais... Porto Alegre: Instituto de Informática /
UFRGS, 1998. v.2, p298-309.
[SIL 00] SILVA, R. P. Suporte ao desenvolvimento e uso de frameworks e
componentes. Porto Alegre: Instituto de Informática / UFRGS, 2000.