O diagrama é simples, não há muito o que explicar: ele traz em colchetes os eventos que disparam a troca de estado, indicada pela seta. O início é o círculo preto e, o fim,  o branco com o centro preto (também auto-explicativo).

Diagrama de Transição de Estados

"E qual é a vantagem dele, Tiago?" A vantagem é que, ao ver todo o funcionamento dos estados em uma única imagem, temos uma visão muito maior da sua lógica e podemos apontar erros. Identificamos, por exemplo, um "sumidouro": o estado TMarioInvencivel não muda para outro estado, sendo impossível a continuação da lógica após ele. Seguindo a lógica do jogo, deveríamos colocar um timer nele para controlasse quanto tempo podemos ficar invencíveis.Viu? Graças ao diagrama identificamos facilmente um beco sem saída na nossa lógica.

"Tá... mas e o TMarioFlorDeFogo?" Então... colocá-lo no diagrama é um exercício para vocês .

ps.: Desculpem pelo atraso na publicação do artigo, mas as coisas apertaram pro meu lado _ _'

Como pedido pelo Alexandre Ceni na 2a parte da micro-série sobre a UML, a 3a parte consiste em exemplos gráficos dos diagramas previamente citados.  Os diagramas que não fazem parte do Nuss... E agora?!? são da wikipedia. Essa página vai estar em constante modificação, pois vou substituindo os diagramas da wikipedia por aqueles que forem pintando nos artigos aqui. Não é foco do artigo  ensinar como desenvolver tais diagramas, até porque isso  é assunto para futuros artigos. Portanto, vamos a eles?

• Diagramas Estruturais (ou de estrutura)

Diagrama de Classes

Diagrama de Pacotes

Diagrama de Estrutura Composta

Diagrama de Objetos

Diagrama de Componentes

Diagrama de Instalação

• Diagramas Comportamentais (ou de comportamento)

Diagrama de Casos de Uso

Diagrama de Atividades

Diagrama de Transição de Estados

• Diagramas de Interação

Diagrama de Sequencia

Diagrama de Comunicação

Diagrama de Interação

Lembrem-se: saber entender os diagramas  é extremamente importante para o desenvolvimento de software: eles são uma forma de descrever exatamente o que você pretende e evitar problemas de comunicação entre os programadores e analistas.

Continuando a micro-série sobre a UML, é hora de falarmos sobre como utilizá-la. A UML nos disponibiliza diversas ferramentas ou artefatos para que possamos modelar as diversas partes do nosso projeto. Tais ferramentas são chamadas de “diagramas” e não passam de uma forma padronizada de desenhar determinado tipo de problema de forma a simplificar a forma de ver o que eles querem mostrar.

“Mas e a flexibilidade que você mencionou no artigo anterior?” Então... ela tem a ver com a possibilidade de não utilizarmos todos os diagramas e sim aqueles que são relevantes ao nosso problema. Isso diminui muito a quantidade de trabalho e permite que nos foquemos somente no que nos é importante (lembram-se do princípio de pareto, né?).

Esses diagramas se dividem em 3 grupos:

• Diagramas Estruturais (ou de estrutura)

Mostram que coisas existem e como elas devem estar relacionadas entre si. Em um jogo, os diagramas estruturais mostrariam, por exemplo, quantos itens cabem na mochila do seu personagem, se um item pode ter ou não alguma habilidade especial ou até mesmo como é a estrutura de salvar ou carregar o progresso do jogo. Os Diagramas Estruturais se dividem em:

Diagrama de Classes

Com o Diagrama de Classes você define as dependências das entidades que fazem parte do seu programa. Quantos personagens estão ao mesmo tempo em uma arena ou como organiza-se o seu ranking são exemplos do uso do Diagrama de Classes.

Diagrama de Estrutura Composta

Lembra quando falamos aqui em classes que contem outras classes, como um carro que tem rodas e lataria personalizáveis, ou um personagem que tem um animal de estimação? O diagrama de Estrutura Composta mostra quais relações entre essas “partes” a classe tem, como o personagem mandando seu animal atacar ou o carro ordenando as rodas que parem de girar. “Ué Tiago, é igual a um Diagrama de Classes?” Na realidade, é. Mas, dependendo do que se modela, pode ser visualmente mais simples.

Diagrama de Objetos

Esse diagrama parece-se muito com o Diagrama de Classes, mas define quais objetos foram instanciados em um dado momento do seu programa. Pegando o exemplo anterior, um diagrama de objetos poderia, por exemplo, mostrar quais personagens estão em qual arena, com quais itens e usando quais magias.

Diagrama de Componentes

Define como as coisas físicas estão organizadas no seu projeto. Por exemplo, onde e como estão guardadas os arquivos do seu código-fonte e a dependência entre eles.

Diagrama de Pacotes

Um dos meus preferidos: ilustra as dependências das partes lógicas do seu programa entre si. Essas partes lógicas, em um jogo, poderiam ser “Fase 1”, “Tela de Login” ou “Tela Inicial”. É utilizado também para definir a arquitetura do seu projeto, como as camadas e o MVC.

Diagrama de Instalação

Sabe quando você deve instalar um DirectX qualquer para rodar um jogo? Então, esse tipo de dependência é o que os diagramas de instalação modelam. Podem ser utilizados para definir a rede onde um MMORPG roda, mostrando os servidores de jogo, de login, sites, bancos de dados e clientes de jogo.

• Diagramas Comportamentais (ou de comportamento)

Diagramas Comportamentais definem o comportamento das coisas que seu projeto tem, incluindo aí a forma com que ele reage aos estímulos externos.

Diagrama de Casos de Uso

Define a forma de interação do usuário com o seu sistema (os tais estímulos externos falados acima). Com ele você diz tudo que seu usuário pode fazer e começa a definir quais são as partes principais do seu sistema. Ele poderá salvar? Então você terá um módulo de savegame com seus próprios casos de Uso (Salvar jogo, Escolher Savegame, Cancelar, Carregar Savegame, por exemplo). Ele utilizará veículos? Então um módulo para controle de veículos será necessário.

Como dica, Casos de Uso iniciam com interação com periféricos. Botões, barras de rolagem, escolha de menus, utilização de teclado... isso tudo dá vida a um caso de uso.

Diagrama de Atividades

O Diagrama de Atividades não é muito mais que o antigo “Diagrama de Blocos”. Ele indica a lógica das coisas sem entrar em detalhes de programação. Um diagrama torna muito mais visível uma lógica como a seguinte: “Jogo exibe menu de modos de jogo. Jogador coloca o cursor sobre o modo desejado. Jogador clica no modo escolhido. O jogo carrega a tela inicial daquele modo escolhido, com a opção de confirmar escolha ou cancelar escolha. Se o jogador cancela a escolha do modo, ele volta ao menu principal; se confirma, o jogo carrega aquele modo.”

Diagrama de Transição de Estados

Como o Mario muda de estado no decorrer de um jogo? Ele pega um cogumelo e vira Super Mario, que encosta em um inimigo e vira de novo o Mario. Só que o Mario, se encostar em um inimigo, morre. Cada um desses “tipos de Mario” é um estado. O conjunto da relação entre eles é o que chamamos de Máquina de Estados. O diagrama serve para desenhar o conjunto formado por essas relações.

• Diagramas de Interação

Enquanto os Diagramas Estruturais dizem como as coisas são, os de interação dizem como elas se relacionam. Com eles você modela como um tiro afeta o seu alvo, como é construída uma pista de corrida ou como acessar o conteúdo de um baú de tesouro.

Diagrama de Sequencia

O Diagrama de Sequencia mostra a interação entre as diversas classes do sistema em um eixo temporal. Com ele você diz, no exemplo da batalha, que a classe de batalha cria uma arena, cria as árvores da arena, cria o rio da arena, cria dois personagems, cria itens e passa-os para os personagens e, finalmente, coloca-os na arena, exibindo em seguida a mensagem “BATALHEM” na tela.

Diagrama de Comunicação

Diagramas de comunicação mostram a interação das classes do sistema como os Diagramas de Sequencia. Porém, ao invés de uma estrutura cronológica, os Diagramas de Comunicação baseiam-se em uma estrutura analítica, como índices de um livro. Antes que pergunte, sim, é praticamente a mesma coisa que o Diagrama de Sequencia, mas a organização (utilizando o exemplo anterior) ficaria algo assim:

1 A classe de batalha cria uma arena
    1.1 Cria as árvores da arena
    1.2 Cria o rio da arena
2 Cria dois personagems
    2.1 Cria itens
    2.2 Passa-os para os personagens e
3 Coloca os personagens na arena
4 Exibe a mensagem “BATALHEM” na tela.

Diagrama de Interação

Modelamos com o Diagrama de Interação a interação entre os múltiplos Diagramas de Sequencia e de Comunicação que temos em nosso sistema.

Por enquanto é só. Caso alguém tenha alguma dúvida, pode comentar sobre ela. Isso pode até render uma futura parte para a série!

Saiba mais! Wikipedia e Advanced Unified Modeling Language

“Tiago, você fala tanto sobre a UML, já falou de Casos de Uso, já mostrou diagramas e mais diagramas, mas até agora não disse: o que raios é a UML?”

UML é uma sigla para Unified Modelling Language. Em português, isso pode ser traduzido como Linguagem de Modelagem Unificada. Ou, simplificando, um conjunto de padrões de desenho para que você possa modelar um problema orientado a objetos, mostrá-lo a uma pessoa que entenda esses desenhos e ela entender aquilo da forma exata que você estava querendo que ela entendesse. Sabe quando um arquiteto faz uma planta de uma casa? Ou quando um roteirista escreve um roteiro? A idéia é exatamente a mesma, mas com os programas orientados a objetos.

“Orientado a Objetos... você já explicou isso aqui no nuss... Isso significa que a UML serve para o desenvolvimento de programas para computador, certo?” Tenho 2 respostas para tal pergunta:

• Sim. Como dito, a UML ajuda-nos a desenhar nossas relações orientadas a objetos. Como um programa OO é um problema orientado a objetos, ela serve para tal.
• Não. Como dito, a UML ajuda-nos a desenhar nossas relações orientadas a objetos. Como qualquer problema do nosso dia-a-dia pode ser organizado segundo a ótica da Orientação a Objetos, ela serve para muito mais que só modelar programas. Podemos, por exemplo, modelar a hierarquia de uma empresa, com seus departamentos, as funções dos funcionários e até mesmo a burocracia dos processos, chegando ao extremo de mapear até mesmo quem está trabalhando demais (ou de menos).

“Nossa, agora estou surpreso. Nunca pensei nessa possibilidade”. Sim, ela existe, porém é muito pouco usada. Eu já cheguei a explicar o problema de alguns relatórios em um departamento público com diagramas UML, mas para esses fins nunca cheguei a usar muito além disso.

“Isso significa que podemos utilizá-la para desenhar nossos problemas, independente de serem programas de computador ou não. Legal. Mas ela é usada mais no desenvolvimento de programas, como jogos de computador. Certo?” Exato. Com a UML, nós desenhamos todo o funcionamento do nosso, por exemplo, jogo. É com ela que eu anoto as características de um personagem, o que ele tem de itens, como são esses itens, como ele reage com o mundo de jogo, o que acontece quando ele ataca ou é atacado, quando pega um item ou passa de fase. A UML está para o programa como uma planta está para uma casa ou o roteiro está para um filme.

“Aaaaahhh. Acho que agora estou entendendo. Eu desenho com a UML o meu programa antes que os programadores programem as minhas idéias, como o roteirista escreve o roteiro do filme antes dele ser gravado” Novamente, Sim e Não. A UML não dita como você realiza o seu projeto, só desenha o programa. Ou seja, ela é independente da metodologia do projeto. Essa tal “metodologia do projeto” é quem dita o que e quando fazer. Tem metodologias onde fazemos a modelagem antes, outras durante ou até depois a programação. Além disso, algumas têm ciclos repetidos e incrementais durante todo o desenvolvimento, outras fazem tudo antes e, a cada problema encontrado volta-se ao início para corrigir tudo. Não existe “a melhor metodologia”: cada uma tem seus prós e contras, sendo recomendada ou não dependendo do que você pretende fazer. Como pode-se ver, a UML é só uma ferramenta para auxiliar o desenvolvimento do programa, independente de como você pretende desenvolvê-lo.

“Nossa. Legal isso. Posso fazer meu jogo com uma metodologia que eu prefira e, mesmo assim, utilizar o que você ensina aqui no Nuss...” Além de ser poderosa e flexível, eu considero esse um dos maiores pontos de sucesso da UML.

“Como assim flexível, Tiago?”. Isso já é assunto para a próxima parte desse artigo, onde falarei dos diversos diagramas da UML.

Para fechar o artigo anterior, como foi prometido, segue abaixo o diagrama do padrão de projetos Decorator. Apesar da longa explicação e do funcionamento diferente, o diagrama é bem simples:

Diagrama do padrão de projetos Decorator

A única coisa diferente nesse diagrama é o fato de TDecoratorBonus possuir, além da herança de TArma,  o atributo _arma do tipo TArma, fazendo assim que surjam as 2 setas. Além disso, basta não se esquecer que TEfeito e TEncantamento têm, por herança de TDecoratorBonus, seus próprios atributos _arma

O código do padrão (Action Script 3.0 com projeto Flash CS3) pode ser encontrado aqui: [download id="1"]

Você e 4 amigos, uma esquadrilha de netherdrakes, helicópteros, grifos e hipogrifos, girando por Oshu’gun enquanto procuram o gigante comedor de dragões Durn the Hungerer. Apesar da ameaça, vocês estão confiantes em seu grupo. O entardecer de Nagrand mostra a silhueta do gigante no horizonte e vocês sabem que a hora chegou.

A luta foi perfeita: o gigante arrasou com o grupo nos 20s mais estilosos que qualquer monstro do World of Warcraft já viu. Depois de 15min de brigas sobre quem tem a culpa, alguém descobre que o grupo não estava tão preparado assim. Todos então resolvem melhorar seus equipamentos... Mas como?

Apresento-lhes a morte do grande gigante, o padrão Decorator.

Vários jogos permitem a seus jogadores um vasto leque de personalização. Eles permitem que configuremos os personagens para que eles sejam o mais parecido possível com a gente em muito mais que só altura e cor de cabelos. Tais jogos permitem que configuremos também a forma com que esse personagem reage ao mundo de jogo, definindo coisas como a velocidade, o tipo de magia que ele usa ou o quanto sustenta de dano. Alguns jogos permitem até que você configure os itens que eles usam. Assim é o World of Warcraft, a febre do momento no mundo dos RPGS massivos (os MMORPGS).

Para vencer os desafios no WoW, os jogadores podem utilizar encantamentos, gemas, itens e diversos efeitos diferentes para aumentar suas características. Se foi isso que faltou no grupo, é isso que daremos a ele.

Comecemos pegando uma das armas dos jogadores. Essa arma exemplo será a classe TArma abaixo:

package Efeitos
{
	public class TArma
	{
		protected var _nome:String; // Damos um nome qualquer e …
		protected var _efeito:String; // … um efeito…

		public function TArma()
		{
			// ... mas setamos para os valores normais ...
			// ... afinal de contas, a arma não tem nada de especial ...
			// ... ainda
			this._nome = "Arma sem Bônus";
			this._efeito = "";
		}

		public function retornaNome():String
		{ return this._nome; }

		public function retornaEfeito():String
		{ return this._efeito; }
	}
}

Essa arma é o que os personagens têm no momento e, como já sabemos, isso não é o suficiente. Que tal incluirmos esses tais efeitos e encantamentos? Assim estaríamos adicionando a força necessária que os personagens precisam, não Tiago? É só criar uns métodos retornaEncantamento() como você fez e pronto.

Não só poderíamos adicionar tais características como várias outras características à arma. O problema é o futuro: a cada vez que um ou vários novos bônus aparecessem no nosso jogo, fossem modificados ou simplesmente excluídos do jogo (o que acontece com muita frequência), teríamos que atualizar essa classe Tarma, bem como TODO O CÓDIGO fazendo as chamadas a esses bônus, no caso deles simplesmente não existirem mais . Isso a torna alvo de alterações cíclicas, o que é longe de ser legal. A idéia aqui é encapsular essas alterações, aplicando-as como um skin ou tema à arma.

Para conseguirmos tal estrutura, usaremos o padrão Decorator: iremos “enfeitar” a arma com quantos bônus especiais precisarmos, aproveitando que ela já possui algo engatilhado para isso (afinal de contas, o método retornaEfeito() não está lá à toa) . Para isso, precisamos inicialmente criar a classe TDecoratorBonus:

package Efeitos
{
	//import Status.TStatus;

	public class TDecoratorBonus extends TArma
	{
		protected var _arma:TArma; // O Decorador possui uma instância de TArma.

		/***************************************************************
		Construtor da classe. Tem os atributos da TArma a ser decorada ...
		... por ser um tipo de arma.
		****************************************************************/
		public function TDecoratorBonus()
		{
			this._nome = "sem nome";
			this._efeito="";
		}
		/***************************************************************
		Esse método sobrescreve (overrides) o método retornaNome() da ...
		... classe TArma.
		****************************************************************/
		public override function retornaNome():String
		{ return this._nome; }
	}
}

Essa classe é o coração do nosso decorador: ela é a responsável pela estrutura de encapsulamento dos diversos efeitos. A principal estrela dessa clase é, sem dúvidas, o atributo protected var _arma:TArma. Sua função é guardar a camada de efeitos no caso dessa camada ser envolvida por outra camada. Não entendi nada, Tiago.Como assim camada envolvida por outra camada? Bom, se você pensar bem, estou falando de camadas como aquelas bonecas russas chamadas matrioshka que guardam outras bonecas idênticas dentro: essa instância seria uma "âncora" para que pudéssemos ir para a "boneca de dentro". Essa boneca de dentro, por sua vez, também tem sua boneca de dentro até o ponto em que não haja mais bonecas dentro.

Cada uma dessas bonecas é, no nosso exemplo, uma das camadas de bônus do padrão decorador, como a classe abaixo:

package Efeitos
{
	public class TEfeito extends TDecoratorBonus
	{

		/***************************************************************
		Construtor da classe recebe um objeto TArma. Ele é jogado para ...
		... a instância this._arma, encapsulando assim mais um nível para ...
		... a recursividade do padrão.
		****************************************************************/
		public function TEfeito(arma:TArma)
		{
			//Os seguintes atributos vieram por herança de TDecoratorBonus;
			this._arma = arma;
			this._efeito = "+10";
		}

		/***************************************************************
		Método que sobrescreve o retornaEfeito da classe TDecoratorBonus, ...
		... chamando ele próprio na instância this._arma da classe. Dessa ...
		... forma, o método inicia uma cadeia de chamadas que termina ...
		... na classe mais interna, a que não possui uma instância de ...
		... _arma.
		****************************************************************/
		public override function retornaEfeito():String
		{
			// Por ser um padrão de recursividade, é obrigatório que...
			// ... chamemos this._arma.retornaEfeito(). Só assim o ...
			// ... método continuará chamando os efeitos encapsulados.
			return (this._efeito + " " + this._arma.retornaEfeito());
		}
	}
}

Para fazer as camadas de bônus funcionarem, entra em ação uma coisa chamada recursividade: de forma simplificada (e, quem sabe, um dia eu escreva de forma completa), recursividade é a capacidade de um método ou função chamar a si mesma por várias vezes, retornando resultados para ela própria. Por enquanto, basta saber que o método retornaEfeito() é recursivo por chamae retornaEfeito() novamente, mas agora na camada de dentro (que, como já sabemos, é o atributo this._arma). A camada interna, por sua vez, chama retornaEfeito() de sua this._arma, que chama retornaEfeito() de sua this._arma, que chama retornaEfeito() de sua... Isso só acaba quando chegamos na arma inicial, a TArma, cujo método retornaEfeito() não chama outro retornaEfeito() e sim, exibe seu this._efeito.

Nesse momento, cada retornaEfeito() chamado retorna seu this._efeito para o método retornaEfeito() que o chamou, que concatena com seu próprio this._efeito e retorna para o método retornaEfeito() que o chamou, que concatena com seu próprio this._efeito e retorna para o método retornaEfeito() que o chamou, que concatena com seu próprio this._efeito e retorna... O fim desse ciclo se dá quando não houver mais retornos a chamadas a retornaEfeito(), o que no nosso exemplo acontece na classe TMain mais à frente.

Essa estrutura fica assim:

Camadas

Com o padrão conseguimos criar uma arma genérica que possui ao seu redor várias camadas de efeitos e que funciona do exato mesmo jeito que uma arma que não possui efeito algum. Além disso, podemos ter diferentes tipos de efeitos, cada um implementado por uma classe diferente. Vou criar agora um TEncantamento:

package Efeitos
{
	import Efeitos.TDecoratorBonus;

	public class TEncantamento extends TDecoratorBonus
	{

		public function TEncantamento(arma:TArma)
		{
			this._arma = arma;
			this._efeito = "Mongoose";
		}

		public override function retornaEfeito():String
		{
			return (this._arma.retornaEfeito() + " " + this._efeito);
		}
	}
}

Por fim, basta decorarmos a arma:

package
{
	import flash.display.MovieClip;
	import Efeitos.TDecoratorBonus;
	import Efeitos.TEncantamento;
	import Efeitos.TEfeito;
	import Efeitos.TArma;

	public class TMain extends MovieClip
	{
		public function TMain()
		{
			// Criamos uma arma qualquer ...
			var arma = new TArma();

			trace ("Antes dos efeitos"); // ... e exibimos seus bônus iniciais.
			trace ( arma.retornaEfeito() );
			trace ();
			trace("---------------------------------------");
			trace ();

			// Agora o padrão entra em ação. Criamos um efeito TEfeito que ...
			// encapsula a arma atual e é passado para ela mesma. Agora ...
			// arma tem dentro de si um TEfeito.
			// Efeito +10
			arma = new TEfeito(arma);

			// Pegamos agora a TEfeito e jogamos dentro de TEncantamento, ...
			// ... passando novamente para a arma. Agora ela tem um ...
			// TEncantamento que tem um TEfeito.
			arma = new TEncantamento(arma);

			// ... que vai dentro de mais um TEfeito ...
			arma = new TEfeito(arma);

			// ... que termina dentro de outro TEfeito
			arma = new TEfeito(arma);

			// Ao realizarmos a chamada a arma.retornaEfeito(), o próprio ...
			// ... método se encarrega de chamar retornaEfeito() das ...
			// ... instâncias encapsuladas, de forma recursiva.

			trace ( arma.retornaEfeito() );
		}
	}
}

No próximo artigo eu disponibilizo o projeto (Flash CS3) e os arquivos das classes (Action Script 3.0). Falo também do diagrama de classes dessa brincadeira toda. Até lá, caso alguém tenha qualquer dúvida, basta perguntar.

No final de uma longa batalha, O gigante finalmente tomba. Seu colossal corpo vai agora servir de alimento para as criaturas que das quais sua linhagem alimentou-se durante eras. Os heróis retornam para suas montarias e tudo volta a ser tranqüilo, graças ao padrão Decorator.

Os Padrões são receitas prontas e já muito testadas para resolver problemas recorrentes: aqueles que milhares programadores tinham. Logicamente falando, eles são para simplificar a nossa vida. Se você pode dizer "Ih. Já vi isso antes. A gente resolve isso com o State", não tenha dúvidas em aplicar o padrão. Ele vai fazer maravilhas pelo cronograma e tirar da cabeça dos programadores mais um problema.

Agora... uma coisa ninguém pode negar: padrões, sejam os de projeto quanto arquiteturais, sempre complicam programas simples. Se você tem um jogo simples de tabuleiro assim...

... sabe como ele poderá ficará depois de aplicado o MVC?

Não preciso nem perguntar se alguém notou como a complexidade aumentou, né? E olha que o MVC é só um padrão de arquitetura, hein? Imagina ainda adicionar estados para as TPeca e TTabuleiro, um Singleton para a TJogo...

Os padrões de projeto tornam as coisas mais coesas, porém aumentam o acoplamento geral de seu programa, pois as classes de um padrão são extremamente dependentes entre si. Eles aumentam muito a complexidade do código, coisa que muitas vezes não é necessário. Voltando ao exemplo acima, alguém acha necessário aplicar o MVC à um projeto que só tem 3 classes?

Usar Padrões de Projeto é uma questão de bom senso: utilize-os só quando eles simplificarem o problema, nunca para jogar mais gasolina no fogo que você tenta apagar, ok?

O ano vai começar com artigos no ritmo do artigo sobre o Singleton e o MVC: explicação do conceito + Diagramação UML + Código + comentários. Deixa só passar o ressacão do Reveillon prá gente sacudir isso aqui.

"Boas festas"; "se forem dirigir, não bebam", "Feliz Natal" e todos os outros clichês que estão nos dizendo. Aguardem o novo ano que vamos ter coisas boas por aqui! Até lá!

Mas como sempre passo um estudo de caso de exemplo, eu vou escolher o Star Fox 64? O QUÊ?!? VOCÊ NÃO CONHECE O STAR FOX 64?!?!?! Ele é um jogaço de 1997 pro Nintendo 64. Sozinho o jogo já era absurdamente maneiro, mas ficava muito melhor quando você jogava com o Rumble Pack, que tremia o joystick quando você batia ou atravessava uma explosão. Foi um dos melhores na sua época e por isso vou usá-lo, além de ter lembrado dele por qualquer aleatoriedade universal.

• Descobrindo o jogo:

Sempre antes de encontrarmos os CdUs de um programa, precisamos identificar o uso desse programa. Um documento de design do jogo não é muito válido, mas o pessoal do PMBOK pode (E DEVE!) usar a Especificação de Requisitos. Ela é um texto beeeeem parecido com o que eu escrevi aí embaixo pro Star Fox 64

Logo no início do jogo pede-se que você aperte o START para escolher o modo de jogo. Você escolhe um dos diversos modos e confirma novamente. Vamos escolher o modo Main Game, ok? Escolhido seu modo, aparece na tela um Arwing girando e a história do jogo, nada fora do comum. Confirmando de novo, você é jogado na tela do Sistema Solar Lylat, (se não me engano... faz tempo que joguei isso) onde deve-se escolher qual área será seu próximo destino. Caso você tenha mais de um possível destino, pode escolher um deles tranqüilamente. Caso queria refazer a fase anterior, você perderá uma vida.

As fases se dividem em 4 tipos: No Blue-Marine, o submarino, no tanque Landmaster e nas Arwings, as naves, tanto no típico “vai direto pra frente” quanto no “gire por esse lugar até completar a fase”, que eles chamam de all-range mode. O conjunto de ações que você pode realizar depende do tipo de fase, mas normalmente você atira, carrega o tiro teleguiado, lança a bomba, se move, acelera, breca, dá um barrel roll (giro em parafuso) e um loop.

Quando a fase termina, você vê uma tela onde os pilotos conversam e, logo em seguida, o dano das naves de suporte é recuperado baseado na contagem de inimigos que você destruiu na fase. Caso alguma nave tenha sido abatida na fase anterior, ela será recuperada para a próxima.

Com esse basicão aí nós podemos começar a definir alguns dos casos de uso que o Star Fox 64 tem.

• Descobrindo os CdUs:

Já que cada interação é um CdU, vem a hora de definir quais são os nossos CdUs. Lendo o texto, marcamos cada coisa que o usuário pode fazer. Nesse exemplo aí a gente pode tirar:

1. Sair da tela principal
2. Escolher modo de Jogo
3. Cortar introdução
4. Selecionar fase
5. Escolher fase
6. Voltar à fase anterior
7. Atirar
8. Carregar tiro teleguiado
9. Lançar tiro teleguiado
10. Lançar bomba
11. Mover veículo
12. Acelerar
13. Brecar
14. Realizar Barrel Roll
15. Realizar Loop

Nesse curto texto conseguimos identificar 15 interações diferentes, ou seja 15 Casos de Uso diferentes. É importantíssimo deixar claro que, mesmo coisas simples como “acelerar” ou “atirar” não devem ficar por fora da lista: CdU podem ser extremamente simples ou incrivelmente complexos, depende de sua aplicação.

Algumas pessoas trabalham com CdUs extensos, mas eu não gosto de fazer isso. Fica como dica tentar dividir aqueles extremamente complexos em diversos pequenos, como eu fiz na lista. Não há um jogar. Ao invés disso, eu desmembrei ele nas diversas ações que constituem jogar, como Acelerar, Brecar, Atirar e Realizar Loop.

Já com a lista em mãos, precisamos guardar isso tudo de uma forma clara de se entender. É claro que já há uma ferramenta na UML para tal e é dela que vou falar agora. Vamos desenhar isso tudo num Diagrama de Casos de Uso.

• Desenhando o Diagrama de CdUs (DCU):

Um DCU é extremamente simples, porém poderoso. Ele é uma forma infalível de definir o grau de interação com o usuário, o que gera uma maior complexidade na interface. Vale lembrar que a quantidade de CdUs não indica a complexidade lógica de um programa: jogos normalmente possuem uma quantidade de CdU inferior ao número de CdUs, mas de complexidade unitária muito maior.

Para desenhar um DCU, nós jogamos um bonequinho ali que chamamos de ator. É esse ator quem realiza as ações do CdU. Se iniciar sistema é feito só por administrador, temos que ter um ator administrador lá no dagrama. Ah, importante: cada CdU está relacionado com pelo menos um ator, mesmo que indiretamente.

Os CdU são as elipses, cada uma com seu respectivo nome. Todas elas estão dentro do grande retângulo que identifica o escopo do seu sistema: o conjunto de coisas que define tudo aquilo que ele faz e exclui tudo aquilo que ele não irá fazer. No final, nosso DCU fica assim:

Esse exemplo é bem simples. Podemos ter herança de Casos de Uso, bem como extensão (extends) e inclusão (includes) de casos de uso em outros Casos de Uso (onde a relação fica de CdU para CdU, ao invés de CdU para ator), mas isso já é assunto para um próximo artigo. Até lá!

O nosso Jogo tem uma característica muito especial: ele é traduzido dinamicamente, sem a necessidade de recompilação. Para isso, estamos colocando todo o texto em uma classe especial, a TIdioma. O problema é que, se nós estivéssemos utilizando um objeto simples, a cada “new” que déssemos, teríamos uma cópia inútil do objeto ocupando espaço inutilmente. Dessa forma, se tivéssemos 500k de texto, poderíamos estar ocupando vários megas da memória.

Isso, quando temos um projeto pequeno, não faz tanta diferença: acaba-se sabendo tudo que está ou não na memória, principalmente quando somente um programador fez aquilo tudo. Porém, há uma grande falha de programação: quando agregássemos um novo programador, ele teria que saber TUDO que já foi feito, da forma que foi feita, entendendo a lógica de tudo que já tá pronto para, aí sim, programar sem erros.Para resolver esse problema, o primeiro padrão de projeto que usamos para resolver um problema no Jogo foi o Singleton. Esse padrão GoF garante que a classe possui somente uma instância, criando um ponto de acesso global à ela. Isso é feito da seguinte forma: o programador NÃO cria um objeto daquela classe. Ao invés disso, a própria classe testa se ela possui uma instância dela mesma. Em caso negativo, a classe cria e retorna essa instância para o programador; em caso positivo, ela simplesmente retorna essa instância já criada.

Utilizamos esse tal de Singleton para garantir que, durante toda a execução do nosso programa, tivéssemos somente uma ÚNICA classe de tradução jogada na memória. Ela é criada no início do programa e, então, todo acesso à TIdioma é realizado via um ponteiro para ela.

O singleton pode ser aplicado à qualquer classe que você queira limitar. Abaixo vai o código genérico que deve ser aplicado:

package
{
	public class TSingleton
	{
		// Atributo de instância
		private static var _instancia:TSingleton = new TSingleton();

Esse atributo _instancia é a chave toda do Singleton e será explicado mais abaixo. O interessante é ver que, com o = new TSingleton(); a instância é inicializada na hora da criação do objeto.

		 // Atributo de teste
		private var _valor:int;

_valor é um atributo qualquer. Vamos usar aqui só para testar o funcionamento do padrão Singleton.

O construtor de uma classe Singleton deveria, por definição, ser protegido, para que, ao tentar usá-lo, o compilador desse um erro. Porém, o Action Script 3.0 NÃO PERMITE construtores privados. Como resolver isso?

		 //-----------------------------------------------------------
		public function TSingleton()
		{
			if (_instancia)
				throw new Error("Uso: TSingleton.Instancia.Metodo()");
		}

Quando _instancia é iniciada lá em cima, na criação da classe, o construtor é chamado a 1ª e única vez. Todas as outras vezes que alguém tentar construir na mão a classe, o teste é vai garantir que não seja possível criar uma segunda instância.

“Mas Tiago, se eu num posso chamar o construtor, como que eu vou criar um objeto da TSingleton???”. Isso é fácil. Você NÃO CRIA! “Mas hein?!?”

		//-----------------------------------------------------------
		// Esse método é o que iremos chamar daqui pra frente
		 // ao invés do construtor da classe
		public static function get Instancia():TSingleton
		{
			return TSingleton._instancia;
		}

Toda vez que você precisar acessar um método de uma classe com o Singleton (no nosso caso, a própria TSingleton), você vai usar pela linha TSingleton.Instancia.Metodo() (onde Metodo() é qualquer método da classe), garantindo que em TODAS AS VEZES você está acessando a mesma instância. Abaixo, mais 2 outros métodos de teste.

		//-----------------------------------------------------------
		// Método simples para retornar um atributo qualquer,
		// nesse caso, ‘valor’
		public function Valor():int
		{
			return this._valor;
		}

		//-----------------------------------------------------------
		// Como o método anterior, mas agora setando o valor do
		// atributo
		public function SetarValor( valor:int )
		{
			 this._valor = valor;
		 }
		//-----------------------------------------------------------
	}
}

Agora vai uma classe extra mostrando como usar uma classe com o padrão Singleton. A lógica de uso, nesse caso específico, está imbutida no construtor da classe, mas poderia estar em qualquer local.

Explicando passo a passo:

import TSingleton;

TODA classe que terá visibilidade de Singleton DEVE incluí-la. Dessa forma, mesmo sendo uma classe Global, áreas do programa que NÃO deveriam vê-la, NÃO verão. Isso evita muitos problemas de acoplamento, efeitos colaterais e melhora muito a reutilização.

public function TPrincipal()

{

	// Provocando o erro:

	//var teste:TSingleton = new TSingleton();

	TSingleton.Instancia.SetarValor(345);

	this.Exibe();

}

Como o construtor da TSingleton está protegido do acesso do programador, usar var teste:TSingleton = new TSingleton() vai resultar no erro:

Error: Uso: TSingleton.Instancia.Metodo()

at TSingleton$iinit()

at TPrincipal$iinit()

Lembrando que Uso: TSingleton.Instancia.Metodo() é a string que passamos para throw new Error lá no construtor de TSingleton, permitindo que vocês troquem a mensagem para algo mais descritivo, caso queiram.

Só para terminar, eu ressalto que esse é somente um dos vários algoritmos diferentes para o Singleton que vocês podem encontrar aí pela internet. Ele foi criado pelo Douglas prá nossa TIdioma há algumas poucas semanas, pois nenhum dos que encontramos era satisfatório o suficiente. Alguém aí tem mais algum exemplo do Singleton?

PS.: Aqueles que querem mesmo testar o Singleton, os arquivos estão aqui ó. Download Action Script 3.0 Singleton class (portuguese) here. Saiba mais: Wikipedia