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.