Prá começar, aí está o Diagrama de Classes:

Ele é simples como a estrutura do padrão: as classes que são observadoras implementam a interface IObserver, o sujeito observado implementa a ISubect que, por sua vez, tem um conjunto de IObservers.

Aqui você baixa o código do projeto CS3 em Actionscript 3.0  [download id="3"]

Até a próxima!

Primeiramente, nossa implementação do Observer terá 2 interfaces:

-        IObserver, implementada por todos os observadores que devem responder às mudanças no Sujeito

-        ISubject. Implementada pelo Sujeito Observado.

Trabalhar com essas interfaces simplifica muito a manutenção do código graças ao princípio da substituição de Liskov como veremos no final do artigo. Por enquanto, continuaremos com a implementação.

Nossa interface IObserver terá somente o método Atualizar(direcao:String):void. Esse é o único método que todos os outros observadores do meu sistema deverão ter. "E o que ele faz, Tiago?" Esse é o método que atualiza a direção do Observador baseado na direção que o Sujeito Observado tomar em um dado instante.

package Observer

{
	public interface IObserver
	{
		function Atualizar(direcao:String):void;
	}
}

Nossos Sujeitos, porém, terão outras funcionalidades: ISubject deverá ter um método para registrar novos observadores e um outro para notificá-los sobre as mudanças de direção.

package Observer

{
	import Observer.IObserver;

	public interface ISubject
	{
		function RegistrarObservador(observador:IObserver):void;
		function NotificarObservador():void;
	}
}

Esse é nosso jato, um sujeito observado pelos mísseis teleguiados. Notem que, por ser um sujeito, ele obrigatoriamente deve implementar a interface ISubject que criamos e, consequentemente, também seus métodos.

package Observer
{

	public class TJato implements ISubject
	{
		private var _observadores:Array;
		private var _direcao:String;

		public function TJato(direcao:String)
		{
		this._observadores = new Array();
		this._direcao = direcao;
		}

/***************************************************************

Adiciona um observador à coleção de observadores do sujeito  ...

... observado, para que ele possa notificá-los quando seu    ...

... estado mudar.

Por ser passado um objeto IObservador, TODA E QUALQUER...

... CLASSE pode se tornar um observador, desde que ...

... implemente a interface IObserver.

****************************************************************/

		public function RegistrarObservador(observador:IObserver):void
		{
			// Adiciono um observador à lista...
			this._observadores.push(observador);

			// ... e aviso a todo mundo quem foi registrado
			trace ("observador registrado: "+ observador);
		}

/***************************************************************

Varre a coleção de observadores, enviando à eles o novo estado.

... Utiliza a metodologia de empurrar dados observados.

****************************************************************/

		public function NotificarObservador():void
		{
			for(var i:int=0; i<this._observadores.length; i++)
			this._observadores[i].Atualizar(this._direcao);
		}

/***************************************************************

Retorna a direção para onde o Jato está voando

****************************************************************/

		public function RetornarDirecao():String
		{
			return this._direcao;
		}

/***************************************************************

Modifica a direção do Jato para uma nova direção

****************************************************************/

		public function ModificarDirecao(direcao:String):void
		{
			this._direcao=direcao;
			this.NotificarObservador();
		}
	}
}

O míssil terá somente esses 2 métodos. Note que eles são passivos, fazendo com que o funcionamento da classe dependenda exclusivamente do que é passado para ela.

package Observer
{

	public class TMissil implements IObserver
	{
		private var _direcao:String;

		public function TMissil(direcao:String)
		{
			this._direcao = direcao;
		}

/***************************************************************
Atualiza a direção para onde o Míssil está indo
****************************************************************/

		public function Atualizar(direcao:String):void
		{
			this._direcao = direcao;
		}

/***************************************************************
Retorna a direção para onde o Míssil está voando
****************************************************************/

		public function RetornarDirecao():String
		{
			return this._direcao;
		}
	}
}

Por fim, nossa classe principal, a TMain. Nela vamos realizar uma sequência de testes da funcionalidade do Observer.

package
{
	import flash.display.MovieClip;
	import Observer.IObserver;
	import Observer.ISubject;
	import Observer.TJato;
	import Observer.TMissil;
	import Observer.THelicoptero;

	public class TMain extends MovieClip
	{
		private var _jato:TJato;
		private var _missil1:TMissil;
		private var _missil2:TMissil;

		private var _helicoptero:THelicoptero;

		public function TMain()
		{
			//Inicia a direção do Jato e dos mísseis
			this._jato = new TJato("CIMA");
			this._missil1 = new TMissil("BAIXO");
			this._missil2 = new TMissil("PARADO");

			//Exibe a direção dos objetos na tela
			trace( "Direção do jato: "
				  + this._jato.RetornarDirecao() );
			trace( "Direção do míssil 1: "
				  + this._missil1.RetornarDirecao() );
			trace( "Direção do míssil 2: "
				  + this._missil2.RetornarDirecao() );

			//Como os mísseis devem observar o ...
			//... comportamento do jato,...
			//... eles são registrados como...
			//... observadores do jato.

			trace("---------------------------------------------------------");

			trace ("Registrando observadores");
			this._jato.RegistrarObservador(this._missil1);
			this._jato.RegistrarObservador(this._missil2);

			trace("---------------------------------------------------------");

			trace("modificando a direção do jato prá BAIXO");

			//Altera a direção do jato...
			this._jato.ModificarDirecao("BAIXO");

			//... e exibe a direção dos objetos na tela
			trace( "Direção do jato: "
				  + this._jato.RetornarDirecao() );
			trace( "Direção do míssil 1: "
				  + this._missil1.RetornarDirecao() );
			trace( "Direção do míssil 2: "
				  + this._missil2.RetornarDirecao() );

			/*
			Caso um desenvolvedor queira estender a ...
			... funcionalidade do programa ...
			... adicionando um novo tipo de
			... observador, ele pode fazê-lo sem   ...
			... a necessidade de mexer no código atual.
			Para isso, basta ...
			... adicionar sua nova classe ...
			... (THelicoptero, nesse caso), fazê-la ...
			... implementar a interface IObserver ...
			... e adicioná-lo à lista de ...
			... chamadas de objetos de perseguição.
			Veja no exemplo abaixo:
			*/

			trace("---------------------------------------------------------");
			trace("Registrando observadores");

			//O Helicóptero entra na perseguição ...
			this._helicoptero = new THelicoptero("LESTE");
			// ... sendo registrado também como observador
			this._jato.RegistrarObservador(this._helicoptero);

			trace("---------------------------------------------------------");

			//Altera a direção do jato...
			trace("modificando a direção do jato prá CIMA");
			this._jato.ModificarDirecao("CIMA");

			//... e exibe a direção dos objetos na tela
			trace( "Direção do jato: "
				  + this._jato.RetornarDirecao() );
			trace( "Direção do míssil 1: "
				  + this._missil1.RetornarDirecao() );
			trace( "Direção do míssil 2: "
				  + this._missil2.RetornarDirecao() );
			trace( "Direção do helicóptero: "
				  + this._helicoptero.RetornarDirecao() );
		}
	}
}

A saída desse código é a seguinte:

Direção do jato: CIMA
Direção do míssil 1: BAIXO
Direção do míssil 2: PARADO
---------------------------------------------------------
Registrando observadores
observador registrado: [object TMissil]
observador registrado: [object TMissil]
---------------------------------------------------------
modificando a direção do jato prá BAIXO
Direção do jato: BAIXO
Direção do míssil 1: BAIXO
Direção do míssil 2: BAIXO
---------------------------------------------------------
Registrando observadores
observador registrado: [object THelicoptero]
---------------------------------------------------------
modificando a direção do jato prá CIMA
Direção do jato: CIMA
Direção do míssil 1: CIMA
Direção do míssil 2: CIMA
Direção do helicóptero: CIMA

"Mas Tiago... Que helicóptero foi aquele ali no meio do código?" Ah é... enquanto estávamos fazendo o código, um outro desenvolvedor achou que helicópteros também são maneiros em perseguições e resolveu implementar um. Notaram como foi fácil adicioná-lo? Bastou que ele implementasse a IObserver que o princípio de Liskov tomou conta do resto. Caso eu queria mais de um Sujeito observado, minha nova classe implementará ISubject. Dessa forma, adicionar observadores ou sujeitos não implica em modificação alguma no código que já estava pronto.

“Outra coisa: e se um observador não quiser mais ser avisado sobre as mudanças do sujeito?” Para isso, a IObserver deverá ter um método removerObservador (observador:IObserver) : void; que vai varrer a lista de observadores e retirá-lo de lá. Isso fica como exercício para quem quiser continuar estudando o padrão.

Na próxima - e última - parte do artigo, disponibilizarei o projeto em AS3.0 e o diagrama de Classes disso tudo ae. Então, até a próxima!

Apesar de simples, isso é tudo que você precisa saber antes de ler sobre o padrão Observer (Observador).

No exemplo anterior temos todas as entidades do padrão Observer bem definidas. Seu filho é o Observador, aquele que está ali ansioso, esperando seu aviso de quando é que a tal surpresa vai chegar. Já você é o que chamamos de Sujeito Observado, quem detém a informação da surpresa, a função de identificar quando ela já pode ser mostrada e avisar a seu observador que chegou a hora dele vê-la.

Como podemos ver, os Observadores se registram no Sujeito Observado, esperando só o momento de reagir às mudanças no Sujeito. Outro exemplo claro da lógica do padrão Observador é assinar os feeds de um site ou uma revista qualquer: todos os assinantes são avisados quando os novos artigos são publicados, bastando esperar para que isso aconteça.

O funcionamento do padrão é simples, mas os ganhos com ele são muito grandes. Com ele você consegue poupar o processador de inúmeras requisições frustradas (como todos os “Já chegou?” antes de realmente ter chegado), deixando para avisar a todos aqueles que se registraram como observadores quando o evento esperado ocorrer. Até que isso ocorra, eles ficam lá, quietinhos, sem encher o saco de ninguém...

O padrão é tão importante que, em muitos casos, seu uso é completamente transparente, sendo já embutido aos frameworks. No Actionscript 3.0, por exemplo, quando utilizamos um eventListerner, não estamos fazendo nada mais que utilizar o padrão. A seguinte linha...

_botao.addEventListener(MouseEvent.CLICK, aoClicar);

... na realidade, está registrando o objeto _botao como observador dos eventos do AS3.0. Quando o evento MouseEvent.CLICK ocorrer, _botao engatilhará o método aoClicar.

“Ta Tiago, mas o que os mísseis teleguiados tem a ver com isso?” Como não poderia ser diferente, na próxima parte do artigo vocês terão um exemplo de como implementar o Observer, brincando com esses mísseis teleguiado. Até lá!

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.