É incrível ver que a massa de títulos é heterogênea ao ponto de termos jogos de iniciantes lado a lado com jogos já conceituados como Resident Evil 4, fato que raramente acontece em um console da última geração.

Resident Evil 5 não é Mais do Mesmo

Já conhece Super Metroid Redesign?

Nanovor - Um jogo para o futuro

Muramasa: The Demon Blade

Espero que gostem.

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.