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.

Vocês vão notar que eu deixei até as rotinas de debug (como o trace quando se passa o cursor sobre a bola) dentro da estrutura MVC. Além disso, vão também ver que cada camada do nosso Jogo está num pacote homônimo. Conseqüentemente, a estrutura de pastas também reflete essa lógica, organizando de forma muito melhor os arquivos.

Os comentários não estão muito explicados, mas quem tiver ainda alguma dúvida DEVE recorrer às partes 1 e 2 do artigo sobre o MVC, agora vendo como tudo acontece no código.

Bom, espero que isso ajude a vocês (especialmente ao Aryel que pediu o código). Qualquer dúvida, é só comentar!
Até a próxima!

Agora que todos já sabem como funciona o MVC, vou continuar com a 2a e última parte do artigo. Hoje vou mostrar os pontos positivos e negativos da implantação da arquitetura, além de finalmente mostrar o que isso tudo tem a ver com o Linkage.

Pontos positivos:

• Abstração e desacoplamento das camadas

Quando estamos programando a interface do problema, não nos preocupamos com a programação da lógica dele, somente com o que vai e o que vem dela. Dessa forma, podemos facilmente simular todo o funcionamento da lógica do programa com uma classe de testes que simula o funcionamento da lógica. Esse é o conceito de caixa preta, importantíssimo para o bom funcionamento de um software.

• Facilidade de manutenção

Graças a esse desacoplamento, é muito mais fácil realizar a manutenção de um programa desses. Se for um problema visual, você vai à camada responsável pelo visual do programa e pronto, corrige. Se for um problema de lógica, é na lógica que você buscará a solução. Além disso, graças ao padrão Controlador (Controller), você pode apagar toda uma janela sem perder nada de sua implementação.

Quem está acostumado a adicionar código em um botão sabe exatamente o trabalho que isso ta poupando, mas para quem não está, aí vai um exemplo. Sabe esse Mario 2 que refizeram em 3D pro Nintendo DS? Se eles não usaram o MVC para fazer o original, perderam uma gigantesca parte da lógica do programa só por trocar a interface. Em compensação, usando o MVC de forma correta eles trocariam toda a interface sem mexer em 1 linha da lógica.

• Possibilidade de Expansão

A estrutura de camadas proposta no MVC pode (e deve) ser expandida: criar mais camadas aumenta a coesão e diminui o acoplamento, organizando melhor o seu código. No jogo, por exemplo, além da Lógica e da Interface, temos a camada de Comunicação (rede) e a camada de Armazenamento (Banco de Dados), além das camadas entre elas. Um outro jogo pode, por exemplo, ter uma camada de IA, uma camada de hardware e uma camada de comunicação com outro jogo. O nosso, inicialmente, está assim:

As camadas se comunicam através de Indireções, como os já citados padrões Controlador, Proxy e DBBroker. Isso claro, pode mudar durante a análise de Casos de Uso mais avançados, mas inicialmente, essa é a idéia. Além disso, o funcionamento desses padrões vai ficar para futuros artigos.

• Facilidade de realização de testes

Com o programa modularizado, podemos criar classes de teste que rodam nosso programa à exaustão, podendo encontrar bugs estatisticamente impossíveis de encontrarmos. Mas sabe qual é o melhor? Você pode testar isso tudo sem ter NADA de interface pronta: a lógica fica tão independente que chega a funcionar sem a interface. Então não precisamos esperar que o pessoal do desenvolvimento resolva aquele problema dos relatórios para que o pessoal do teste disseque nosso Caso de Uso. Maneiro, não?

Pontos negativos:

• Programação complexa

A programação torna-se mais complexa quando aplicamos o MVC. Chamadas consecutivas e abstração do código são extremamente importantes. Além disso, uma documentação de todo o projeto é imprescindível para que as camadas sejam mapeadas e seguidas da forma correta. Além disso, teremos o...

• Uso extensivo de padrões de projeto

O MVC simples já dita o uso do padrão Controller. Expandindo camadas de Comunicação e Armazenamento, ainda usaremos Proxies como o Remote Proxy e Database Brokers. Para desacoplar essas camadas, criaremos várias classes baseadas nos padrões Indireção (usado para desacoplar 2 classes que não deveriam ter visibilidade entre si) e Invenção Pura (padrão que adiciona classes que não estão diretamente ligadas ao problema em si, mas que facilitam a solução dele). No final, a relação entre as classes é bem mais burocrática

• Dependência do MVC na portabilidade

Para poder portar um código MVC de forma correta, o programa que irá recebê-lo precisa trabalhar nos moldes do MVC. Por exemplo, se estamos portando uma janela de cadastro de cliente já pronta para um programa parecido, ele tem que estar modularizado de forma a trabalhar com a classe Controladora para que a manutenção seja mínima. Isso causa uma certa dependência à estrutura.

• Queda de performance

As mensagens trocadas navegam entre camadas de forma burocrática e indireta, o que faz com que os programadores “performance acima de tudo” reclamem bastante. Por exemplo, uma chamada a uma função que seria direta numa programação estruturada torna-se uma cadeia de várias subchamadas a métodos que somente levam a chamada para a próxima camada nessa estrutura, como vocÊs viram no diagrama de seqüência lá em cima.

A performance perdida está longe de ser relevante, principalmente com os processadores de hoje em dia, mas mesmo assim continua sendo um ponto negativo da arquitetura.

“Ta, ta, eu entendi o MVC. Mas o quê que o Linkage tem à ver com isso???” O linkage do Flash é uma facilidade ao trabalhar com a interface, pois permite que uma classe use os atributos do MovieClip como se fossem atributos de si mesma. A grosso modo, parece muito uma herança de atributos e métodos públicos. O maior problema é que, se não tomarmos cuidado, acabamos destruindo toda a modularidade do MVC.

O linkage só deve ser usado para que as classes de interface controlem os MovieClips relacionados à elas. No nosso jogo, temos as classes TCarta e TCartaAvatar, ambas controlando uma carta em jogo. A diferença é que, seguindo o MVC, modularizamos uma carta em 2 camadas:

• TCarta

Controla a lógica da carta: os atributos, as contas, o dano que ela recebe, se ela está no Deck, na Mão, em Jogo ou no Cemitério e coisas do gênero.

• TCartaAvatar

Controla todos os efeitos visuais da carta. É ela que desenha a marcação do mouse sobre a carta, quem coloca a carta em qualquer posição, que inicia/pára o arrastar, que gera os efeitos de dano e desenha na tela todos os atributos buscados de TCarta.

Dessa forma, podemos trocar completamente a interface sem mexer nas classes de lógica. Trocar para Papervision 3D, a Plasticvision 4D, a Metalvision 5D ou até mesmo OpenGL ou ClosedLG, no nosso projeto, é muuuito mais simples: basta que criemos as mesmas classes de Interface, mas agora programadas com a nova interface. MOLEZA.

Essa portabilidade ainda pode ser da interface para a lógica: nossas cartas são arrastadas independente da lógica, elas brilham independente dlógica, elas se movem independente da lógica. Basta chamar os métodos da classe de Interface na hora certa, seja em Action Script 3.0 ou qualquer outra linguagem que o Flash suporte mais pra frente.

Caso uma única classe fosse responsável por isso tudo, durante uma troca de interface ou na hora de portar um trecho do código, a manutenção seria muito mais complicada: você deveria ficar movendo/apagando métodos das classes de lógica. Isso claro, pois estou pensando numa classe bem feita, com métodos bem estruturados. Muitas vezes, o que você encontra são linhas de interface no meio da lógica. Aposto que vários de vocês já viram um “se (this.morto) rode (“AnimacaoMorto”)”. Imaginem trocar o código para o futuro suporte OpenGL nesse caso...

Se vocês já pegaram o esquema do MVC e da expansão que fizemos, criando a camada de Armazenamento, já sacou que a carta também terá uma camada de armazenamento. Ela não está implementada ainda, mas seria mais ou menos assim:

• TCartaDados

Seria a classe responsável por materializar e desmaterializar a Carta. Pra quem não sabe, materializar é buscar os dados de um objeto no BD e criá-lo em memória e desmaterializar é jogar no BD, destruindo o objeto da memória. Essa classe também seria responsável por todos os outros métodos possíveis

Gente, de todos os artigos que fiz até agora, esse foi de longe o que eu mais gostei de escrever. Espero, por meio desse, ajudar a derrubar essa história de que o Action Script é uma linguagem de 2^a linha e que jogo em Flash é um amontoado de gambiarras. Espero também incentivar os leitores a escrever sobre qualidade de software em AS. Dá mais trabalho na hora de programar, mas esse trabalho é recompensado na hora de reutilizar o código em diversos outros projetos. Pensem nisso e até a próxima!

[EDIT] Não se esqueça de conferir o resto do artigo! Parte 1 e Parte 3, valeu?

Eu acredito que muita gente vai me chamar de maluco depois desse artigo, mas espero que todos entendam. Pra começar, vamos falar do MVC (ou Model-View-Controller), uma arquitetura de software baseado na idéia de interações emtre camadas de alta coesão (fazem exatamente aquilo que se propõem a fazer e nada mais que isso) e baixo acoplamento (são o mais independentes possível entre si).

“CALMAÊ!!!! QUE NEGÓCIO É ESSE DE ARQUITETURA??? O MVC NÃO É UM PADRÃO DE PROJETO???” Pois então, como eu disse, muita gente vai me chamar de maluco... Deixa eu explicar:Eu já vi vários sites, artigos e livros chamando o MVC de várias coisas. Já vi chamando de padrão de projeto, com o que eu não concordo. Ele não é um padrão de projeto pelo fato de organizar todo um sistema, não somente um bloco ou pequeno problema. Além disso, para implementar o MVC nós precisamos utilizar padrões, como o controlador (Controller).

Pensando nisso, algumas pessoas começaram a chamá-lo de meta-padrão, coisa que ele não é. Um meta-padrão definiria o comportamento dos padrões, não de toda a arquitetura.

O MVC é isso: ele define como as classes vão se comportar, ditando quem fica onde, faz o quê e, o mais importante, o por quê disso ser assim, bem como faz uma planta de uma casa. Por isso é que, em vários locais (como aqui no Nuss), vocês vão encontrar o MVC como uma arquitetura de software.

Isso é um ponto de vista, não chega a influenciar diretamente no uso do MVC. Mas é importante explicar para que ninguém saia com “cara de LG”. Beleza? Então continuemos com o artigo.

Voltando às camadas, é como se você transformasse o software no corpo humano: separasse os ossos e delegasse a eles a sustentação do corpo, o sangue ficaria com o transporte de substâncias pelo organismo e o sistema neurológico se responsabilizasse pela propagação das sensações e ordens do cérebro. É claro que as funções não são bem essas, mas é assim que as coisas funcionam.

O MVC em nosso jogo fica assim:

Com esse diagrama eu posso falar da maior característica do MVC: Toda e qualquer camada só se comunica com as camadas imediatamente abaixo de si. Lembrando-se que, para evitar dúvidas, quanto mais próxima do usuário, mais “alta” ou “alto nível” está a camada. Nota-se que nenhuma classe da Lógica realiza chamadas à classe Controladora da mesma forma que a classe controladora não realiza chamadas à Interface. Além disso, a Interface não chama diretamente método algum da Lógica: isso é feito através da classe Controladora, como mostra o Diagrama de Seqüência a seguir:

No MVC, cada camada tem uma função específica:

• Model (Modelo / Lógica)

Essa é a camada de negócios, onde está toda a lógica do teu sistema. No Jogo, por exemplo, é onde estão as classes TCarta, TPersonagem, TLadrilho e todas as outras relacionadas ao funcionamento do núcleo do Jogo (ou engine, se preferir).

• View (Visão / Interface)

Na camada de visão você não encontra NADA além das classes de interface com o usuário. TCartaAvatar, TPersonagemAvatar e TLadrilhoAvatar são exemplos de classes que, no Jogo, ficam na Interface. Outras classes que estão aqui são a TIdioma (que controla todos os textos do programa) e a TJukeBox (recém implementada, que controla todos os sons do jogo)

• Controller (Controladora)

A controladora é uma camada intermediaria entre a Lógica e a Interface, que faz somente a propagação das mensagens da interface para a lógica, visto que a lógica não pode se comunicar com a interface.

A continuação do artigo, com os prós e contras da arquitetura, além do que o Linkage do flash tem a ver com isso vai ficar para o próximo. Então gente, até lá!

[EDIT] Seguem os links para as Partes 2 e 3 do artigo.