Artigos
Curso ECO 3: Dreidel em Diagramas...
... ou o primeiro esboço do “rapa”
ADAIL MUNIZ RETAMAL E MARCELO PEREIRA ROCHA
Terça-feira, oito e meia da noite
O celular de Dalai toca, acordando-o. Havia cochilado um pouco enquanto assistia ao jornal na TV. Olhou para o nome no painel do aparelho: Tzur. “A essa hora? Que será que ele quer?”, pensou enquanto atendia à chamada.
– Fala mano! Beleza? – Essa é uma das vantagens de ter reconhecimento do número chamado, pois já podemos atender de forma personalizada.
– Tranqüilo! Seguinte, Dalai, preciso fazer um trabalho para minha pós em jogos. Só que os caras querem que eu faça em C++... Eu já falei que poderia ser em Delphi, mas eles me olharam de forma esquisita.
– Hehehe... Isso acontece com freqüência. Ainda mais no mundo dos jogos, que é tipicamente “controlado” pelo C++. Você pode fazer em Delphi 2006 com ECO. Tenho certeza de que eles nunca viram nada parecido! Vão ficar babando!
– É verdade! Boa idéia! Mas o ECO não é só para sistemas comerciais? O que ele tem que ver com jogos?
– Mano, o ECO é um framework completo para qualquer aplicação orientada por objetos. O domínio de negócio não faz diferença. O que manda é a modelagem das classes. O resto fica por conta do ECO: geração de código fonte, administração dos objetos em memória, criação do banco de dados e gerenciamento da gravação e leitura dos dados, comunicação com a interface gráfica etc.
– É verdade! Puxa, acho que vou fazer mesmo com o ECO. Vou falar com meu professor e, se ele topar o desafio, eu lhe aviso e aí vou lhe incomodar para me ajudar, pode ser?
– Claro, mano! E você já decidiu qual jogo?
– Sim. Como este é um trabalho interdisciplinar envolvendo gamecultura e técnicas de desenvolvimento, resolvi fazer sobre o Dreidel.
– Dreidel! Legal! Eu conheci ainda pequeno pelo nome de “rapa”! Meu pai trouxe a caixinha com o pião e as fichas, após uma de suas viagens. Mas o negócio é só gerar um programa de qualquer jeito? Você não quer aproveitar e fazer a coisa do jeito certo, seguindo uma metodologia de desenvolvimento e gerenciamento de projeto? Fica muito mais profissional, além de dar um “banho” de Engenharia de Software nos seus colegas da pós, que tal?
– Ah! Essa eu não vou perder! Negócio fechado! Amanhã eu ligo com a notícia. Valeu!
– Até mais! – “Esse Tzur é gente boa...”, pensou Dalai, desligando o celular.
Quarta-feira, meio-dia e meia.
O celular toca bem na hora em que Dalai está pesando seu prato no restaurante self-service. Ao olhar no painel o nome de Tzur, ele já antecipa o resultado.
– Então vamos começar? – Atendeu enquanto levava a bandeja para a mesa.
– Ué, como sabia? Eu mandei um e-mail para o professor, explicando o que pretendo fazer, e ele achou interessante. Tive que dar mais detalhes sobre o ECO, claro. Ele entendeu e ficou curioso para ver o resultado.
– Legal! E sobre a metodologia? Qual você quer usar?
– Que pergunta, hein? Com você só poderia ser a FDD, né? – Tzur sabia o quanto Dalai gostava da Feature Driven Development, uma metodologia ágil que ele conhecera alguns anos antes e que se mostrou muito apropriada para o desenvolvimento orientado por objetos. – Só que minha dúvida é: posso usá-la mesmo com uma equipe composta por uma pessoa?
– Foi exatamente como fiz meu primeiro projeto usando a FDD. – Respondeu Dalai, lembrando-se com nostalgia. – Tive a ótima oportunidade de testar os conceitos e aprender fazendo. Depois pude auxiliar meus colegas em outros projetos, o que me propiciou outras oportunidades para melhorar meu entendimento.
– Se você garante... Eu me lembro dos cinco processos da FDD: DMA (Desenhar um Modelo Abrangente), CLF (Construir a Lista de Features), PPF (Planejar Por Feature), DPF (Detalhar Por Feature) e CPF (Construir Por Feature) (ver Figura 1).
Figura 1: Os 5 processos da FDD
– Exatamente! – exclamou Dalai. – Vejo que você estava acordado naquele mini-curso que ministrei. Então a primeira tarefa é modelar o domínio de negócio. Pense sobre os objetos que existem no ambiente do jogo: o Dreidel, os jogadores, o placar, etc. Construa o modelo de classes, sem muito detalhe. Ah, você tem que decidir também sobre a regra para terminar o jogo, ou as regras, se quiser deixar mais flexível.
– OK! Vou fazer a modelagem e enviá-la para suas considerações. Veja seu e-mail ainda hoje. Abração!
– Bom trabalho! – Dalai desligou já abocanhando um pedaço do pastel de queijo.
Quarta-feira, duas da tarde.
Tzur prepara-se para desenhar o primeiro esboço do modelo de classes do Dreidel e se depara com uma situação aparentemente conflitante: “Puxa, o professor solicitou para este trabalho que aplicássemos algumas premissas de XP (Extreme Programming), principalmente o TDD (Test Driven Development)!”. Rapidamente ele entrou em contato com Dalai.
- Fala Tzur !
- Opa! Cara, pintou uma dúvida aqui... Nós combinamos de usar os processos da FDD, mas pelos requisitos do trabalho eu também preciso utilizar XP. Estas coisas são meio antagônicas, não?
- Bom, eu não diria antagônicas. Na verdade são complementares.
- Complementares?
- Sim. Você não estava pensando neste momento em construir o modelo de classes?
- Exato.
- E não é uma ótima maneira de se construir um modelo pensando antes de tudo em como as possíveis partes da aplicação serão utilizadas?
- Agora entendo o que quer dizer... Podemos efetivamente usar o XP para descrever uma metáfora sobre o Dreidel, identificando vários elementos do jogo e, com isso, escrever alguns dos testes funcionais e unitários. A partir daí, teremos informações suficientes para entender como os elementos se relacionam e esboçar um primeiro diagrama. Não é um pecado misturar essas coisas?
- Pecado é deixar de entregar o projeto em tempo e com qualidade. Vou ficar esperando o diagrama. Até mais.
- Ok, até mais!
Após desligar o telefone, Tzur começou a ponderar sobre a metáfora a ser escrita. Pegou uma caneta e uma folha de papel e, pensando nas etapas do jogo, escreveu:
“Este software é basicamente um motor que altera os movimentos de um pião. A cada parada, ele lê este pião e atualiza um grande placar eletrônico.”.
A partir desta idéia simples Tzur passou a imaginar como estes elementos poderiam interagir e serem testados. Para isso, criou um Test Project (File New Other Test Projects Test Project) baseado em NUnit, inseriu uma nova unit (File New Other Delphi for .NET Projects New Files) e começou a esboçar o teste descrito na Listagem 1.
Listagem 1. Bateria de testes para o jogo Dreidel
unit TestDreidel;
interface
uses
NUnit.Framework;
type
[TestFixture]
TTestDreidel = class
strict private
FMotor: Motor;
FEcoSpace: TDreidelEcoSpace;
public
[SetUp]
procedure SetUp;
[TearDown]
procedure TearDown;
published
[ExpectedException(typeof(ENumeroDeJogadoresInvalido))]
[Test]
procedure TestInicioJogo;
[Test]
procedure TestCreatePiao;
[Test]
procedure TestCreatePlacar;
end;
implementation
procedure TTestDreidel.SetUp;
begin
FEcoSpace := TDreidelEcoSpace.Create;
FEcoSpace.Active := True;
FMotor := Motor.Create(FEcoSpace);
end;
procedure TTestDreidel.TearDown;
begin
FMotor := nil;
FEcoSpace := nil;
end;
procedure TTestDreidel.TestInicioJogo;
var
_jogador: Jogador;
begin
_jogador := Jogador.Create(FEcoSpace);
FMotor.Jogadores.Add(_jogador);
FMotor.IniciarJogo;
end;
procedure TTestDreidel.TestCreatePiao;
begin
Assert.IsTrue(Assigned(FMotor.Piao), 'Pião não foi criado pelo motor.');
end;
procedure TTestDreidel.TestCreatePlacar;
begin
Assert.IsTrue(Assigned(FMotor.Placar), 'Placar não foi criado pelo motor.');
end;
end.
Ao compilar o projeto do teste, o primeiro erro indicado pelo Delphi foi “[Error] TestDreidel.pas(13): E2003 Undeclared identifier: 'Motor'”. “Ótimo! Agora posso finalmente começar a esboçar um diagrama para ser utilizado por esse teste. E o melhor: durante toda a construção do jogo, eu terei uma forma de me certificar que nenhuma alteração causará qualquer efeito colateral.” – pensou Tzur. Em seguida, criou um novo ECO Package (File New Other Delphi for .NET Projects ECO Package in Package). Na janela New Application, atribuiu “DreidelModel” como nome do projeto e manteve a sugestão de diretório fornecida pelo Delphi. Ao clicar em OK, a estrutura básica de um novo pacote ECO foi criado, contendo apenas as units Package_1Unit e Package_1.ecopkg. “Vou melhorar esses nomes” – pensou Tzur, enquanto já clicava sobre Package_1Unit.pas com o botão direito do mouse e escolhia ‘Rename’ no menu. Colocou ‘UDreidelClasses.pas’ como novo nome. Tzur possui um padrão para nomenclatura de units, que consiste simplesmente em colocar a letra U (maiúscula) antes do nome real da unit. Para que o ECO gere os arquivos no mesmo padrão, ele foi ao menu Tools Options ECO General Options, e no grupo ‘ECO Delphi Code Generation’ ele marcou a caixa ‘One file per class’ (para que o ECO gere uma unit para cada classe do modelo), e na caixa de texto ‘Unit Name Pattern’ ele escreveu U{0} (é um zero entre as chaves, que significa o parâmetro 0 da formatação de strings). Para salvar as configurações, clicou em OK. Em seguida, clicou na aba Model View (ao lado do Project Manager), abriu o nó ‘DreidelModel’ e selecionou o Package_1 com o botão direito do mouse, escolheu ‘Rename’ e colocou ‘DreidelClasses’ como nome do pacote de modelagem. “Genial! O ECO 3 já torna a utilização de packages mais natural para o arquiteto” – ele pensou. Para criar o modelo de classes, clicou duas vezes sobre o pacote ‘DreidelClasses’ para abrir o diagrama, adicionou quatro classes (Tool Palette UML ECO Class Diagram ECO Class) e atribuiu os nomes Piao, Motor, Placar e Jogador respectivamente. Finalmente, estabeleceu as associações entre as classes e adicionou os métodos e atributos concebidos durante a fase de escrita dos testes iniciais (Figura 2). Note que o Delphi gerou também 4 units no projeto, uma para cada classe do modelo. Como em .Net o uso de reflexão (reflection) para determinar o conteúdo dos pacotes (ou assemblies) é obrigatório, precisamos compilar o projeto para gerar a DLL referente ao pacote ECO. Assim, Tzur compilou o projeto e certificou-se que não havia nenhum erro.
Figura 2: Diagrama de classes criado no ECO 3.
Isto feito, Tzur voltou ao projeto do teste e incluiu o assembly do pacote ECO gerado, ‘DreidelModel.dll’, na pasta ‘References’ do projeto. Também alterou a cláusula uses da unit TestDreidel, acrescentando as seguintes units: UPiao, UMotor, UJogador e UPlacar (estas units também foram adicionadas ao projeto de teste). Além disso, foi necessário fazer referência ao Borland.Eco.Handles.dll, que está localizado no diretório (C:\Arquivos de programas\Arquivos comuns\Borland Shared\BDS\Shared Assemblies\3.0). Depois destas alterações, o projeto de teste foi novamente compilado e executado. Como previsto, todos os testes falharam (Figura 3).
Figura 3: Primeira execução do projeto de testes
Quarta-feira, sete e quinze da noite.
O e-mail de Tzur chega com o modelo anexado. Dalai abre o Delphi 2006 e carrega o projeto para dar uma olhadinha. Tzur havia criado um pacote do ECO para deixar o modelo separado da aplicação. Essa é uma ótima estratégia, pois permite a reutilização do modelo em diferentes projetos, como WinForms e Web, por exemplo. Ele observa o modelo (Figura 2) e fica pensando um pouco. “Que legal! Ele fez certinho: usou uma classe para controlar o jogo (Motor), uma coleção de jogadores, um pião e um placar. Acho que para começar está bom.” – pensou Dalai. No e-mail, ele também explicou quais seriam as regras utilizadas, como o jogo terminaria, entre outros detalhes. A aplicação seria um projeto WinForms, mas posteriormente (algum dia) poderia virar uma aplicação Web.
Jogando Dreidel
Dreidel (em ídiche; “sevivon” em hebraico) é um jogo antigo, geralmente ligado ao feriado judaico de Hanukah, que comemora a reconsagração do templo em Jerusalém, após a revolta dos Macabeus contra a ocupação grega, no segundo século A.E.C. (Antes da Era Comum). É jogado com um pião de quatro faces, cada uma contendo uma letra do alfabeto hebraico. Cada participante inicia com um certo número de fichas (pode ser qualquer coisa para contar). No início, cada jogador deve colocar uma ficha no pote (ou monte no centro). A cada vez que o pião é rodado, a face que cair para cima indica o que o jogador deve fazer:
- Nun (Nichts) (Nada) Você não ganha nem perde fichas.
- Guímel (Ganz) (Tudo) Você ganha todas as fichas do pote. Todos os jogadores (incluindo você) colocam uma ficha no pote para repô-lo.
- Hê (Halb) (Metade) Você ganha metade das fichas do pote (mais uma, se o número for ímpar). Se isso deixar o pote vazio, todos os jogadores (incluindo você) colocam uma ficha no pote para repô-lo.
- Shin (Shtel) (Pôr) Você deve colocar uma ficha no pote.
Há várias formas de determinar o fim do jogo:
• Quando um jogador ganhar todas as fichas (o que demora bastante);
• Quando um dos jogadores ficar sem fichas;
• Quando um jogador conseguir um número pré-definido de fichas;
• Atribuindo-se pontos para cada letra: 0 para Nun, 10 para Guímel, 5 para Hê e -2 para Shin (isso, você perde 2 pontos). No início define-se o número de pontos para determinar o vencedor.
Cenas do próximo capítulo...
Com a ajuda de Dalai, Tzur iniciou o seu trabalho de pós-graduação: o desenvolvimento de um jogo conhecido como “rapa”, o Dreidel. Os amigos estão trabalhando no Delphi 2006 com ECO, utilizando as metodologias complementares FDD (Feature Driven Development) e XP. Pois é, o trabalho já começou, mas ainda tem muito a ser feito. No próximo capítulo, Tzur e Dalai descobrem o poder do diagrama de estados no ECO 3! Não perca !
Links
http://www.chabad.org.br/datas/chanuca/cha009.html
Site com uma breve explicação sobre o jogo de Dreidel (sevivon).
http://br.groups.yahoo.com/group/gufdd
Site do grupo de discussão sobre a FDD, contendo muito material sobre a metodologia.
http://www.xprogramming.com/
Site contendo bastante material sobre XP.
... ou o primeiro esboço do “rapa”
ADAIL MUNIZ RETAMAL E MARCELO PEREIRA ROCHA
Terça-feira, oito e meia da noite
O celular de Dalai toca, acordando-o. Havia cochilado um pouco enquanto assistia ao jornal na TV. Olhou para o nome no painel do aparelho: Tzur. “A essa hora? Que será que ele quer?”, pensou enquanto atendia à chamada.
– Fala mano! Beleza? – Essa é uma das vantagens de ter reconhecimento do número chamado, pois já podemos atender de forma personalizada.
– Tranqüilo! Seguinte, Dalai, preciso fazer um trabalho para minha pós em jogos. Só que os caras querem que eu faça em C++... Eu já falei que poderia ser em Delphi, mas eles me olharam de forma esquisita.
– Hehehe... Isso acontece com freqüência. Ainda mais no mundo dos jogos, que é tipicamente “controlado” pelo C++. Você pode fazer em Delphi 2006 com ECO. Tenho certeza de que eles nunca viram nada parecido! Vão ficar babando!
– É verdade! Boa idéia! Mas o ECO não é só para sistemas comerciais? O que ele tem que ver com jogos?
– Mano, o ECO é um framework completo para qualquer aplicação orientada por objetos. O domínio de negócio não faz diferença. O que manda é a modelagem das classes. O resto fica por conta do ECO: geração de código fonte, administração dos objetos em memória, criação do banco de dados e gerenciamento da gravação e leitura dos dados, comunicação com a interface gráfica etc.
– É verdade! Puxa, acho que vou fazer mesmo com o ECO. Vou falar com meu professor e, se ele topar o desafio, eu lhe aviso e aí vou lhe incomodar para me ajudar, pode ser?
– Claro, mano! E você já decidiu qual jogo?
– Sim. Como este é um trabalho interdisciplinar envolvendo gamecultura e técnicas de desenvolvimento, resolvi fazer sobre o Dreidel.
– Dreidel! Legal! Eu conheci ainda pequeno pelo nome de “rapa”! Meu pai trouxe a caixinha com o pião e as fichas, após uma de suas viagens. Mas o negócio é só gerar um programa de qualquer jeito? Você não quer aproveitar e fazer a coisa do jeito certo, seguindo uma metodologia de desenvolvimento e gerenciamento de projeto? Fica muito mais profissional, além de dar um “banho” de Engenharia de Software nos seus colegas da pós, que tal?
– Ah! Essa eu não vou perder! Negócio fechado! Amanhã eu ligo com a notícia. Valeu!
– Até mais! – “Esse Tzur é gente boa...”, pensou Dalai, desligando o celular.
Quarta-feira, meio-dia e meia.
O celular toca bem na hora em que Dalai está pesando seu prato no restaurante self-service. Ao olhar no painel o nome de Tzur, ele já antecipa o resultado.
– Então vamos começar? – Atendeu enquanto levava a bandeja para a mesa.
– Ué, como sabia? Eu mandei um e-mail para o professor, explicando o que pretendo fazer, e ele achou interessante. Tive que dar mais detalhes sobre o ECO, claro. Ele entendeu e ficou curioso para ver o resultado.
– Legal! E sobre a metodologia? Qual você quer usar?
– Que pergunta, hein? Com você só poderia ser a FDD, né? – Tzur sabia o quanto Dalai gostava da Feature Driven Development, uma metodologia ágil que ele conhecera alguns anos antes e que se mostrou muito apropriada para o desenvolvimento orientado por objetos. – Só que minha dúvida é: posso usá-la mesmo com uma equipe composta por uma pessoa?
– Foi exatamente como fiz meu primeiro projeto usando a FDD. – Respondeu Dalai, lembrando-se com nostalgia. – Tive a ótima oportunidade de testar os conceitos e aprender fazendo. Depois pude auxiliar meus colegas em outros projetos, o que me propiciou outras oportunidades para melhorar meu entendimento.
– Se você garante... Eu me lembro dos cinco processos da FDD: DMA (Desenhar um Modelo Abrangente), CLF (Construir a Lista de Features), PPF (Planejar Por Feature), DPF (Detalhar Por Feature) e CPF (Construir Por Feature) (ver Figura 1).
Figura 1: Os 5 processos da FDD
– Exatamente! – exclamou Dalai. – Vejo que você estava acordado naquele mini-curso que ministrei. Então a primeira tarefa é modelar o domínio de negócio. Pense sobre os objetos que existem no ambiente do jogo: o Dreidel, os jogadores, o placar, etc. Construa o modelo de classes, sem muito detalhe. Ah, você tem que decidir também sobre a regra para terminar o jogo, ou as regras, se quiser deixar mais flexível.
– OK! Vou fazer a modelagem e enviá-la para suas considerações. Veja seu e-mail ainda hoje. Abração!
– Bom trabalho! – Dalai desligou já abocanhando um pedaço do pastel de queijo.
Quarta-feira, duas da tarde.
Tzur prepara-se para desenhar o primeiro esboço do modelo de classes do Dreidel e se depara com uma situação aparentemente conflitante: “Puxa, o professor solicitou para este trabalho que aplicássemos algumas premissas de XP (Extreme Programming), principalmente o TDD (Test Driven Development)!”. Rapidamente ele entrou em contato com Dalai.
- Fala Tzur !
- Opa! Cara, pintou uma dúvida aqui... Nós combinamos de usar os processos da FDD, mas pelos requisitos do trabalho eu também preciso utilizar XP. Estas coisas são meio antagônicas, não?
- Bom, eu não diria antagônicas. Na verdade são complementares.
- Complementares?
- Sim. Você não estava pensando neste momento em construir o modelo de classes?
- Exato.
- E não é uma ótima maneira de se construir um modelo pensando antes de tudo em como as possíveis partes da aplicação serão utilizadas?
- Agora entendo o que quer dizer... Podemos efetivamente usar o XP para descrever uma metáfora sobre o Dreidel, identificando vários elementos do jogo e, com isso, escrever alguns dos testes funcionais e unitários. A partir daí, teremos informações suficientes para entender como os elementos se relacionam e esboçar um primeiro diagrama. Não é um pecado misturar essas coisas?
- Pecado é deixar de entregar o projeto em tempo e com qualidade. Vou ficar esperando o diagrama. Até mais.
- Ok, até mais!
Após desligar o telefone, Tzur começou a ponderar sobre a metáfora a ser escrita. Pegou uma caneta e uma folha de papel e, pensando nas etapas do jogo, escreveu:
“Este software é basicamente um motor que altera os movimentos de um pião. A cada parada, ele lê este pião e atualiza um grande placar eletrônico.”.
A partir desta idéia simples Tzur passou a imaginar como estes elementos poderiam interagir e serem testados. Para isso, criou um Test Project (File New Other Test Projects Test Project) baseado em NUnit, inseriu uma nova unit (File New Other Delphi for .NET Projects New Files) e começou a esboçar o teste descrito na Listagem 1.
Listagem 1. Bateria de testes para o jogo Dreidel
unit TestDreidel;
interface
uses
NUnit.Framework;
type
[TestFixture]
TTestDreidel = class
strict private
FMotor: Motor;
FEcoSpace: TDreidelEcoSpace;
public
[SetUp]
procedure SetUp;
[TearDown]
procedure TearDown;
published
[ExpectedException(typeof(ENumeroDeJogadoresInvalido))]
[Test]
procedure TestInicioJogo;
[Test]
procedure TestCreatePiao;
[Test]
procedure TestCreatePlacar;
end;
implementation
procedure TTestDreidel.SetUp;
begin
FEcoSpace := TDreidelEcoSpace.Create;
FEcoSpace.Active := True;
FMotor := Motor.Create(FEcoSpace);
end;
procedure TTestDreidel.TearDown;
begin
FMotor := nil;
FEcoSpace := nil;
end;
procedure TTestDreidel.TestInicioJogo;
var
_jogador: Jogador;
begin
_jogador := Jogador.Create(FEcoSpace);
FMotor.Jogadores.Add(_jogador);
FMotor.IniciarJogo;
end;
procedure TTestDreidel.TestCreatePiao;
begin
Assert.IsTrue(Assigned(FMotor.Piao), 'Pião não foi criado pelo motor.');
end;
procedure TTestDreidel.TestCreatePlacar;
begin
Assert.IsTrue(Assigned(FMotor.Placar), 'Placar não foi criado pelo motor.');
end;
end.
Ao compilar o projeto do teste, o primeiro erro indicado pelo Delphi foi “[Error] TestDreidel.pas(13): E2003 Undeclared identifier: 'Motor'”. “Ótimo! Agora posso finalmente começar a esboçar um diagrama para ser utilizado por esse teste. E o melhor: durante toda a construção do jogo, eu terei uma forma de me certificar que nenhuma alteração causará qualquer efeito colateral.” – pensou Tzur. Em seguida, criou um novo ECO Package (File New Other Delphi for .NET Projects ECO Package in Package). Na janela New Application, atribuiu “DreidelModel” como nome do projeto e manteve a sugestão de diretório fornecida pelo Delphi. Ao clicar em OK, a estrutura básica de um novo pacote ECO foi criado, contendo apenas as units Package_1Unit e Package_1.ecopkg. “Vou melhorar esses nomes” – pensou Tzur, enquanto já clicava sobre Package_1Unit.pas com o botão direito do mouse e escolhia ‘Rename’ no menu. Colocou ‘UDreidelClasses.pas’ como novo nome. Tzur possui um padrão para nomenclatura de units, que consiste simplesmente em colocar a letra U (maiúscula) antes do nome real da unit. Para que o ECO gere os arquivos no mesmo padrão, ele foi ao menu Tools Options ECO General Options, e no grupo ‘ECO Delphi Code Generation’ ele marcou a caixa ‘One file per class’ (para que o ECO gere uma unit para cada classe do modelo), e na caixa de texto ‘Unit Name Pattern’ ele escreveu U{0} (é um zero entre as chaves, que significa o parâmetro 0 da formatação de strings). Para salvar as configurações, clicou em OK. Em seguida, clicou na aba Model View (ao lado do Project Manager), abriu o nó ‘DreidelModel’ e selecionou o Package_1 com o botão direito do mouse, escolheu ‘Rename’ e colocou ‘DreidelClasses’ como nome do pacote de modelagem. “Genial! O ECO 3 já torna a utilização de packages mais natural para o arquiteto” – ele pensou. Para criar o modelo de classes, clicou duas vezes sobre o pacote ‘DreidelClasses’ para abrir o diagrama, adicionou quatro classes (Tool Palette UML ECO Class Diagram ECO Class) e atribuiu os nomes Piao, Motor, Placar e Jogador respectivamente. Finalmente, estabeleceu as associações entre as classes e adicionou os métodos e atributos concebidos durante a fase de escrita dos testes iniciais (Figura 2). Note que o Delphi gerou também 4 units no projeto, uma para cada classe do modelo. Como em .Net o uso de reflexão (reflection) para determinar o conteúdo dos pacotes (ou assemblies) é obrigatório, precisamos compilar o projeto para gerar a DLL referente ao pacote ECO. Assim, Tzur compilou o projeto e certificou-se que não havia nenhum erro.
Figura 2: Diagrama de classes criado no ECO 3.
Figura 3: Primeira execução do projeto de testes
O e-mail de Tzur chega com o modelo anexado. Dalai abre o Delphi 2006 e carrega o projeto para dar uma olhadinha. Tzur havia criado um pacote do ECO para deixar o modelo separado da aplicação. Essa é uma ótima estratégia, pois permite a reutilização do modelo em diferentes projetos, como WinForms e Web, por exemplo. Ele observa o modelo (Figura 2) e fica pensando um pouco. “Que legal! Ele fez certinho: usou uma classe para controlar o jogo (Motor), uma coleção de jogadores, um pião e um placar. Acho que para começar está bom.” – pensou Dalai. No e-mail, ele também explicou quais seriam as regras utilizadas, como o jogo terminaria, entre outros detalhes. A aplicação seria um projeto WinForms, mas posteriormente (algum dia) poderia virar uma aplicação Web.
Jogando Dreidel
Dreidel (em ídiche; “sevivon” em hebraico) é um jogo antigo, geralmente ligado ao feriado judaico de Hanukah, que comemora a reconsagração do templo em Jerusalém, após a revolta dos Macabeus contra a ocupação grega, no segundo século A.E.C. (Antes da Era Comum). É jogado com um pião de quatro faces, cada uma contendo uma letra do alfabeto hebraico. Cada participante inicia com um certo número de fichas (pode ser qualquer coisa para contar). No início, cada jogador deve colocar uma ficha no pote (ou monte no centro). A cada vez que o pião é rodado, a face que cair para cima indica o que o jogador deve fazer:
- Nun (Nichts) (Nada) Você não ganha nem perde fichas.
- Guímel (Ganz) (Tudo) Você ganha todas as fichas do pote. Todos os jogadores (incluindo você) colocam uma ficha no pote para repô-lo.
- Hê (Halb) (Metade) Você ganha metade das fichas do pote (mais uma, se o número for ímpar). Se isso deixar o pote vazio, todos os jogadores (incluindo você) colocam uma ficha no pote para repô-lo.
- Shin (Shtel) (Pôr) Você deve colocar uma ficha no pote.
Há várias formas de determinar o fim do jogo:
• Quando um jogador ganhar todas as fichas (o que demora bastante);
• Quando um dos jogadores ficar sem fichas;
• Quando um jogador conseguir um número pré-definido de fichas;
• Atribuindo-se pontos para cada letra: 0 para Nun, 10 para Guímel, 5 para Hê e -2 para Shin (isso, você perde 2 pontos). No início define-se o número de pontos para determinar o vencedor.
Cenas do próximo capítulo...
Com a ajuda de Dalai, Tzur iniciou o seu trabalho de pós-graduação: o desenvolvimento de um jogo conhecido como “rapa”, o Dreidel. Os amigos estão trabalhando no Delphi 2006 com ECO, utilizando as metodologias complementares FDD (Feature Driven Development) e XP. Pois é, o trabalho já começou, mas ainda tem muito a ser feito. No próximo capítulo, Tzur e Dalai descobrem o poder do diagrama de estados no ECO 3! Não perca !
Links
http://www.chabad.org.br/datas/chanuca/cha009.html
Site com uma breve explicação sobre o jogo de Dreidel (sevivon).
http://br.groups.yahoo.com/group/gufdd
Site do grupo de discussão sobre a FDD, contendo muito material sobre a metodologia.
http://www.xprogramming.com/
Site contendo bastante material sobre XP.