CURSO DE BACHARELADO EM SISTEMAS DA INFORMAÇÃO
RODRIGO LUIZ KOVALSKI
Estudo da Aplicabilidade da OPM para Desenvolvimento de
Jogos Digitais
TRABALHO DE CONCLUSÃO DE CURSO
CURITIBA 2019
Estudo da Aplicabilidade da OPM para Desenvolvimento de
Jogos Digitais
Trabalho de Conclusão de Curso de graduação, apresentado à disciplina de Trabalho de Diplomação, do Curso Superior de Bacharelado em Sistemas da Informação do Departamento Acadêmico de Informática - DAINF - da Universidade Tecnológica Federal do Paraná - UTFPR, como requisito parcial para obtenção do título de Bacharel em Sistemas da Informação.
Orientador: Prof. Paulo Cézar Stadzisz DAINF - Departamento Acadêmico de
Informática - UTFPR
CURITIBA 2019
Câmpus Curitiba
Diretoria de Graduação e Educação Profissional Departamento Acadêmico de Informática
Coordenação do Curso de Bacharelado em Sistemas de Informação
TERMO DE APROVAÇÃO
ESTUDO DA APLICABILIDADE DA OPM PARA DESENVOLVIMENTO
DE JOGOS DIGITAIS
por
Rodrigo Luiz Kovalski
Este Trabalho de Conclusão de Curso foi apresentado no dia 29 de novembro de 2019 como requisito parcial à obtenção do grau de Bacharel em Sistemas de Informação na Universidade Tecnológica Federal do Paraná - UTFPR - Câmpus Curitiba. O(a)(s) aluno(a)(s) foi(ram) arguido(a)(s) pelos membros da Banca de Avaliação abaixo assinados. Após deliberação a Banca de Avaliação considerou o trabalho ________________________________________.
________________________________
Paulo Cézar Stadzisz
(Presidente - UTFPR/Curitiba)
________________________________
Mariângela de Oliveira Gomes Setti
(Avaliador(a) 1 - <Instituição>)
________________________________
Rita Cristina Galarraga Berardi
(Avaliador 2(a) - Instituição)
________________________________
Profa. Leyza Baldo Dorini
(Professora Responsável pelo TCC – UTFPR/Curitiba)
_____________________________
Prof. Marcelo Mikosz Gonçalves
(Coordenadordo curso de Bacharelado em Sistemas de Informação – UTFPR/Curitiba)
À minha família, por sua capacidade de acreditar em mim е investir em mim, a todos os professores do curso, em especial ao professor Paulo Cézar Stadzisz, pela paciência na orientação е todo o apoio que tornaram possível а conclusão desta monografia, aos amigos е colegas, pelo incentivo е pela parceria e a todos aqueles que de alguma forma estiveram е estão próximos de mim, fazendo esta vida valer cada vez mais а pena.
KOVALSKI, Rodrigo Luiz. Estudo da Aplicabilidade da OPM para Desenvolvimento de Jogos Digitais. x f. TCC (Curso de Bacharelado em Sistema da Informação), Universidade Tecnológica Federal do Paraná. Curitiba, 2019
Assim como qualquer software, os jogos digitais também podem ser desenvolvidos com auxílio de métodos para modelagem de sistemas. Buscar aplicar novas técnicas é essencial para o desenvolvimento de software, uma vez que o mercado de jogos digitais está em grande crescimento. Novas abordagens podem proporcionar agilidade no desenvolvimento e melhoria da qualidade do software. Há diversos estudos sobre modelagens para o desenvolvimento de jogos, mostrando um grande interesse da comunidade em aplicar estes métodos. A Metodologia Objeto-Processo (OPM), desenvolvida por Dori (1995), é uma nova abordagem para concepção de sistemas que preconiza combinar a abordagem clássica de modelagem orientada a processos com técnicas de modelagem orientada a objetos. Foram desenvolvidos dois jogos digitais. O primeiro foi modelado com UML e OPM para estudar a aplicação e fazer uma comparação entre as duas modelagens. O segundo jogo foi desenvolvido com a OPM, com objetivo de investigar a aplicação em um software mais complexo. A OPM se mostrou apropriada para a modelagem de jogos digitais. Em comparação com a UML, a OPM demonstrou ser uma alternativa favorável. Foram propostas nove orientações para auxiliar a modelagem OPM em um jogo digital.
Figura 1 - Conceitos básicos da OPM ... 17
Figura 2 - Características dos objetos e processos ... 18
Figura 3 - Relações Estruturais da OPM ... 18
Figura 4 - Relações Processuais da OPM ... 19
Figura 5 - Exemplo de interface do programa OPCAT ... 20
Figura 6 - Metamodelo OPM de nível superior de Tomada de Decisão (OPD) ... 21
Figura 7 - OPD do processo de tomada de decisão em zoom ... 22
Figura 8 – Exemplo de interface da game engine Unity3D ... 23
Figura 9 - Tela inicial do "Square Overflow" ... 25
Figura 10 - Exemplo de novo nível do jogo "Square Overflow"... 26
Figura 11 - Exemplo de execução de um nível do jogo "Square Overflow" ... 27
Figura 12 – Tela contento o botão ―Próximo nível― do jogo "Square Overflow" ... 27
Figura 13 - Tela ―Fim de Jogo‖ do jogo "Square Overflow" ... 28
Figura 14 - Diagrama de Casos de Uso ―Square Overflow‖. ... 30
Figura 15 - Diagrama de Classes ―Square Overflow‖ ... 32
Figura 16 - Diagrama de Sequência ―Iniciar uma nova partida‖ do jogo ―Square Overflow". ... 33
Figura 17 - Diagrama de Sequência ―NextLevel‖ do jogo ―Square Overflow" ... 34
Figura 18 - Diagrama de Sequência ―Selecionar quadrados‖ do jogo ―Square Overflow". ... 35
Figura 19 - Diagrama de Sequência ―countPoint‖ do jogo ―Square Overflow" ... 35
Figura 20 - Diagrama de Sequência ―countError‖ do jogo ―Square Overflow" ... 36
Figura 21 - Diagrama de Sequência ―Avançar nível‖ do jogo ―Square Overflow". ... 36
Figura 22 - Diagrama de Sequência ―Sair do jogo‖ do jogo ―Square Overflow‖ ... 37
Figura 23 - Diagrama de Sequência ―Ouvir música‖ do jogo ―Square Overflow‖ ... 38
Figura 24 – Diagrama de Comunicação ―Iniciar nova partida‖ do jogo ―Square Overflow‖ ... 39
Figura 25 - Diagrama de Comunicação ―Selecionar quadrados‖ do jogo ―Square Overflow‖ .... 40
Figura 26 - Diagrama de Comunicação ―Avançar nível‖ do jogo ―Square Overflow‖ ... 40
Figura 27 - Diagrama de Comunicação ―Sair do jogo‖ do jogo ―Square Overflow‖ ... 41
Figura 28 - Diagrama de Comunicação ―Ouvir música‖ do jogo ―Square Overflow‖ ... 41
Figura 29 - Diagrama de Estado ―PlayButton‖ do jogo ―Square Overflow‖ ... 42
Figura 30 - Diagrama de Estado ―SquareButton‖ do jogo ―Square Overflow‖ ... 43
Figura 31 - Diagrama de Estado ―NextLevelButton‖ do jogo ―Square Overflow‖ ... 43
Figura 32 - Diagrama de Estado ―GameManager‖ do jogo ―Square Overflow‖ ... 44
Figura 33 - Diagrama de Estado ―ExitGameButton‖ do jogo ―Square Overflow‖ ... 45
Figura 34 - Diagramas de Estado dos elementos da tela do jogo ―Square Overflow‖ ... 46
Figura 35 - Diagramas de Estado dos elementos da tela do jogo ―Square Overflow‖ ... 46
Figura 36 – Diagrama principal do jogo ―Square Overflow‖ ... 47
Figura 37 - Diagrama ―Iniciando nova partida in-zoomed‖ do jogo ―Square Overflow‖ ... 48
Figura 38 - Diagrama ―Gerenciando nível in-zoomed‖ do jogo ―Square Overflow‖. ... 50
Figura 39 - Diagrama ―Inicializando quadrado in-zoomed‖ do jogo ―Square Overflow‖... 51
Figura 40 - Diagrama ―Atualizando tela in-zoomed‖ do jogo ―Square Overflow‖. ... 52
Figura 45 - Diagrama ―Saindo do jogo in-zoomed‖ do jogo ―Square Overflow‖ ... 58
Figura 46 - Tela inicial do jogo "Blinky" ... 65
Figura 47 - Tela de Tutorial do jogo ―Blinky‖ ... 65
Figura 48 - Tela de exemplo do jogo ―Blinky‖ mostrando um coelho seguindo o ―Blinky‖ ... 66
Figura 49 - Tela de exemplo do jogo ―Blinky‖ mostrando o Mágico encontrando o "Blinky" ... 67
Figura 50 – Tela de exemplo do jogo ―Blinky‖ mostrando a porta de reaparecimento ... 67
Figura 51 – Diagrama principal do jogo ―Blinky" ... 70
Figura 52 - Diagrama ―Iniciando partida" do jogo ―Blinky" ... 72
Figura 53 - Diagrama ―Movimentando Blinky" do jogo ―Blinky" ... 73
Figura 54 - Diagrama ―Pulando" do jogo ―Blinky" ... 73
Figura 55 - Diagrama ―Movimentando na horizontal" do jogo ―Blinky" ... 74
Figura 56 - Diagrama ―Pegando coelho" do jogo ―Blinky" ... 75
Figura 57 - Diagrama ―Salvando coelho" do jogo ―Blinky" ... 76
Figura 58 - Diagrama ―Pegando caixa" do jogo ―Blinky" ... 77
Figura 59 - Diagrama ―Arremessando caixa" do jogo ―Blinky" ... 78
Figura 60 - Diagrama ―Matando Mágico" do jogo ―Blinky" ... 79
Figura 61 - Diagrama ―Morrendo" do jogo ―Blinky" ... 80
Figura 62 - Diagrama ―Movimentando Mágico in-zoomed" do jogo ―Blinky" ... 81
Figura 63 - Diagrama ―Matando Blinky" do jogo ―Blinky‖ ... 82
Figura 64 - Hierarquia dos diagramas do jogo "Blinky" ... 84
Figura 65 – Diagrama ―Criando cenário‖ ... 86
Figura 66 – Diagrama ―Estados do Baú‖ ... 87
Figura 67 – Diagrama ―Movimentando personagem para frente‖ ... 88
Figura 68 – Diagrama ―Comprando item‖ ... 90
Tabela 1 - Requisitos funcionais e não funcionais do jogo ―Square Overflow‖ ... 29 Tabela 2 - Quantidade de diagramas produzidos para o jogo ―Square Overflow‖ ... 60
CASE - Computer-Aided Software Engineering GWP - Game Waterfall process
GUP - Game Unified Process OPD - Object-Process Diagram OPL - Object-Process Language OPM - Object Process Methodology OPCAT - Object-Process CASE Tool UML - Unified Modeling Language
UTFPR – Universidade Tecnológica Federal do Paraná XGD - eXtreme Game Development
1. INTRODUÇÃO ... 11 1.1. Contexto do trabalho ... 11 1.2. Objetivos do Trabalho ... 12 1.2.1. Objetivo Geral ... 12 1.2.2. Objetivos Específicos ... 13 1.2.3. Estrutura do Trabalho ... 13 2. FUNDAMENTAÇÃOTEÓRICA ... 14
2.1. Metodologias utilizadas em desenvolvimento de jogos ... 14
2.2. Metodologia Objeto-Processo ... 16
3. APLICAÇÃO DA UML E DA OPM EM UM JOGO DIGITAL ... 25
3.1. Descrição do jogo ―Square Overflow‖ ... 25
3.2. Requisitos do software ―Square Overflow‖ ... 28
3.3. Modelagem UML do jogo ―Square Overflow‖ ... 29
3.4. Modelagem OPM do jogo ―Square Overflow‖ ... 47
3.5. Programação do jogo ―Square Overflow‖ ... 58
3.6. Discussão sobre o jogo ―Square Overflow‖ ... 59
3.7. Discussão sobre a aplicação a UML e a OPM em um jogo digital ... 60
4. INVESTIGAÇÃO DA APLICAÇÃO DA UML E DA OPM EM JOGOS DIGITAIS ... 62
5. SEGUNDA APLICAÇÃO DA OPM EM UM JOGO DIGITAL ... 64
5.1. Descrição do jogo ―Blinky‖ ... 64
5.2. Requisitos do jogo ―Blinky‖ ... 68
5.3. Modelagem OPM do jogo ―Blinky‖ ... 70
5.4. Programação do jogo ―Blinky‖ ... 83
5.5. Discussão sobre o jogo ―Blinky‖ ... 83
6. PROPOSTA DE ORIENTAÇÕES SOBRE A OPM EM JOGOS DIGITAIS ... 85
7. CONCLUSÃO E CONSIDERAÇÕES FINAIS ... 93
8. REFERÊNCIAS ... 95
9. APÊNDICE A – CÓDIGOS DOS SCRIPTS DO JOGO ―SQUARE OVERFLOW‖ ... 101
1. INTRODUÇÃO
1.1. Contexto do trabalho
O mercado de jogos digitais evoluiu significativamente desde as suas origens nos salões de diversões do final dos anos 70 e início dos 80, particularmente graças à Internet, às experiências online com vários jogadores e aos jogos móveis e sociais. As diversas maneiras pelas quais os videogames estão sendo utilizados vêm atraindo grande variedade de consumidores. Por exemplo, o mercado norte-americano espera alcançar um crescimento de 3,6% ao ano a partir de agosto de 2015, totalizando 20,3 bilhões até 2020, superando o esperado crescimento em outros produtos de entretenimento, como TV, cinema e música. Evidências recentes mostram que, em torno de metade dos adultos norte-americanos se envolvem com videogames de alguma forma (Kaimann, D., Stroh‐ Maraun, N., e Cox, J, 2018).
Uma grande evolução nas tecnologias e processos de desenvolvimento de jogos ocorreu desde seus primeiros dias. O crescimento das exigências dos consumidores, as complexidades técnicas e estéticas, bem como as fontes investidas no desenvolvimento de jogos digitais, sensibilizaram para a importância do uso de conceitos de Engenharia de Software e de linguagens de alto nível para o desenvolvimento de jogos (Furtado, 2012). O que começou como uma indústria artesanal tornou-se uma indústria que as grandes operações corporativas dominam atualmente (Flynt, 2005).
A produção de jogos geralmente envolve alguns dos mais complexos esforços de desenvolvimento de software. Pode não ser possível realizar tais esforços sem planejamento extensivo. Além disso, é um problema sustentar esses esforços sem atenção aos processos de desenvolvimento (Flynt, 2005).
A distinção entre jogos e outras categorias de software é que, nos jogos, os grupos de desenvolvimento consistem em pessoas com diferentes áreas de especialização. A equipe de desenvolvimento de jogos pode ser formada por:
● Roteirista: responsável por escrever o script do jogo e o papel conceitual do jogo;
● Game Designer: responsável por converter o conceito em documento de projeto, que
será o guia para o desenvolvimento do projeto;
● Programadores: podem-se envolver programadores com diversas áreas, habilidades e conhecimentos, tais como programadores de Engine e de gráficos, programadores de
inteligência artificial e programadores de frameworks.
● Músicos: são os responsáveis pela programação do som e efeitos sonoros;
● Artistas: podem-se ter artistas de personagens, modeladores 3D e os artistas de texturas;
● Testadores: são os responsáveis por encontrar bugs e fazer sugestões para mudanças na jogabilidade, gráficos e da história.
Equipes com integrantes contendo papéis diversificados, como os descritos na lista, não costumam estar necessariamente relacionados à complexidade do projeto em si, pois é comum no desenvolvimento dos jogos digitais que as equipes possuam perfis direcionados para funções específicas. (Ampatzoglou e Chatzigeorgiou, 2007).
Assim como qualquer software, os jogos digitais também podem ser desenvolvidos com auxílio de metodologias para modelagem de sistemas (Demachy 2003, Tenzer e Stevens 2007, Tenzer 2004, Barros 2007, Furtado 2012, Ampatzoglou e Chatzigeorgiou 2007, Bethke 2003, Flynt 2005, Lima 2013, Alves e Santos 2015). Buscar aplicar novas técnicas é essencial para desenvolvimento de software, uma vez que o mercado de jogos digitais está em pleno crescimento e novas abordagens podem proporcionar agilidade no desenvolvimento e melhoria da qualidade do software (Furtado, 2012).
O uso de modelagem de software, como por exemplo, a UML, é uma prática sugerida na literatura e consagrada em algumas metodologias de desenvolvimento de software que não é comumente aplicada a empresas de jogos. O não uso da UML se dá principalmente pela abordagem ágil usada em vários projetos e pela própria deficiência no modelo UML, quando utilizado para a modelagem de jogos (Barros, 2007).
Assim, o desenvolvimento de software de jogos digitais ainda carece de métodos de modelagem compatíveis com as necessidades deste tipo de software. Uma vez que a UML não demonstrou ser uma opção notória para os desenvolvedores de jogos, outras opções, como a OPM, poderiam ser exploradas para este fim.
1.2. Objetivos do Trabalho
1.2.1. Objetivo Geral
O objetivo geral deste trabalho é investigar e propor a aplicabilidade da Metodologia Objeto-Processo (OPM) como forma de substituir a linguagem UML, que seria a linguagem de referência no desenvolvimento tradicional de jogos digitais. A intenção com
este estudo é investigar como a aplicação da OPM se comporta em um projeto de jogo digital.
1.2.2. Objetivos Específicos
Os objetivos específicos deste trabalho, associados ao objetivo geral, são:
● Correlacionar as características e alternativas de modelagem da OPM no desenvolvimento de jogos digitais com outras abordagens de modelagem, notadamente a UML;
● Investigar a aplicabilidade da UML e da OPM no contexto de jogos digitais;
● Propor um conjunto de orientações para uso geral da OPM na modelagem de software de jogos digitais.
1.2.3. Estrutura do Trabalho
Primeiramente, no capítulo 2 este documento irá abordar as metodologias que são atualmente referenciadas em desenvolvimento de jogos e a descrição da Metodologia Objeto-Processo. O capítulo 3 aborda a aplicação de um jogo digital a partir da UML e a OPM. O capítulo 4 se refere a uma breve investigação da aplicação da UML e da OPM em jogos digitais. O capítulo 5 trata-se do desenvolvimento de outro jogo, mais complexo, utilizando a OPM. O capítulo 6 se refere a uma proposta de orientações de modelagem de jogos digitais utilizando a OPM. Por último, no capítulo 7, são feitas as considerações finais e conclusão do projeto.
2. FUNDAMENTAÇÃO TEÓRICA
Para fundamentar o trabalho foi realizada uma pesquisa sobre as metodologias utilizadas para desenvolvimento de jogos e sobre a Metodologia Objeto-Processo, descritos neste capítulo.
2.1. Metodologias utilizadas em desenvolvimento de jogos
Historicamente, a indústria de jogos digitais, desde seu início, enfrentou desafios e cenários únicos, assim tornando o desenvolvimento de jogos um domínio peculiar comparado ao software em geral. As primeiras produções de jogos ignoravam importantes conceitos de engenharia de software e objetivos de projeto, como reutilização e modularidade. Por vários anos a forma de desenvolver jogos foi caracterizada pela falta de um processo organizado (Furtado, 2012).
As empresas do ramo de jogos eletrônicos enfrentam dificuldades em desenvolver jogos com alta tecnologia. Os principais motivos são a evolução rápida da tecnologia e o destaque que essa indústria vem ganhando nos últimos anos (Fabichak, 2009). O crescimento das demandas dos consumidores, a complexidade técnica e estética, bem como os recursos investidos no desenvolvimento de jogos digitais, foram os principais fatores que levaram a refletir sobre como é importante o uso de conceitos de Engenharia de Software e linguagens de alto nível para o desenvolvimento de jogos (Furtado, 2012).
A tecnologia está em constante transformação e, deste modo, é preciso analisar as transformações e desenvolver projetos que atendam a todos os requisitos em um curto prazo de tempo. O risco de se construir um jogo ruim, não aceito e não comercial, causaria prejuízos. A fim de minimizar esses impactos, surgem necessidades de se utilizar metodologias para o desenvolvimento de jogos. Essas metodologias, por força das adaptações, também devem sofrer alterações para se ajustarem às demandas e às tecnologias presentes (Hamada, 2015).
Atualmente, existem diversas metodologias adaptadas para desenvolvimento de jogos, algumas delas descritas detalhadamente por Flynt (2005), em seu livro ―Software Engineering for Game Developers‖. Algumas delas metodologias são: o Modelo GWP (Game Waterfall Process), Modelo XGD (eXtreme Game Development) e Modelo GUP (Game Unified Process).
O modelo GWP é uma versão similar à versão tradicional de desenvolvimento de sistemas com o processo Cascata. O nome Cascata se dá pela característica que as fases seguem um único sentido. Este modelo, por ser pouco flexível, pode acumular vários erros durante o processo de desenvolvimento.
O Modelo XGD é um modelo adaptado do Extreme Programming (XP), que é um modelo ágil desenvolvido para programadores. O XGD realiza algumas adaptações para funcionar com os demais papéis da equipe de desenvolvimento de jogos (Demachy, 2017).
O modelo GUP é baseado na junção dos modelos Extreme Programming e Rational Unified Process (RUP). O modelo mescla iterações curtas do XP e iterações longas do RUP de forma mais adequada para cada papel na produção (Flood, 2013).
O Scrum e o Game Scrum são citados pelo autor Carvalho (2013). O Scrum é um processo ágil, iterativo e incremental que foca na aceitação das mudanças que podem ocorrer, principalmente em contextos pouco definidos. O Game Scrum é uma adaptação do ciclo de vida do desenvolvimento clássico de jogos para um contexto ágil.
Para ilustrar melhor o contexto do mercado de jogos, os dados da pesquisa brasileira ―1o Censo da indústria brasileira de jogos digitais‖ indicaram que a maioria das
empresas prefere utilizar métodos ágeis, sendo o Scrum (60%) o mais utilizado. Alguns métodos tradicionais (Cascata 4,5% e Project Management Body of Knowledge 11,3%) também foram citados. A porcentagem de respondentes que declararam não utilizar nenhuma metodologia foi de 25,6%. Outras metodologias citadas na pesquisa foram Agile, Desenvolvimento Ágil, Design Card Game (DCG), Feature Driven Development (FDD), Design Centrado no ser Humano (HCD) e Mapas Mentais. Algumas empresas também citaram que utilizam ferramentas modificadas do Scrum (BNDES, 2014).
Diversos autores de artigos e livros sobre a área de Engenharia de Software para desenvolvimento de jogos citam o uso da UML (Unified Modeling Language) como ferramenta útil para auxiliar o desenvolvimento do projeto de jogos (Demachy 2003, Tenzer e Stevens 2007, Tenzer 2004, Barros 2007, Furtado 2012, Ampatzoglou e Chatzigeorgiou 2007, Bethke 2003, Flynt 2005, Lima 2013, Alves e Santos 2015).
A UML (Unified Modelling Language - Linguagem de Modelagem Unificada) surgiu da união de linguagens anteriores para análise e projeto de sistemas orientados a objetos e, em 1997, passou a ser aceita e reconhecida como um padrão potencial de notação para modelagem de múltiplas perspectivas de sistemas de informações pela OMG ("Object Management Group") (Costa, 2001).
A UML define um conjunto básico de diagramas e notações que permitem representar as múltiplas perspectivas do sistema sobre análise e desenvolvimento. Dentre os diagramas podem ser citados: Diagramas de Casos de Uso, Diagramas de Classes, Diagramas de Interações (Sequência ou Colaboração), Diagramas de Atividades e Diagramas de Estado e Transição (Costa, 2001).
A utilização da UML para o design de jogos melhora a comunicação entre os designers de jogos e programadores e pode ser útil também para lidar com artistas e na gestão (Demachy, 2003). A UML é uma prática sugerida na literatura e consagrada em algumas metodologias de desenvolvimento de software, mas não é comumente aplicada em empresas de jogos. O não uso da UML se dá, principalmente, pela característica ágil de vários desses projetos e pela própria deficiência no modelo, quando utilizado para a modelagem de jogos (Barros, 2007). Os autores Reinhartz-Berger, Iris e Dori (2014), em um comparativo da UML com a OPM, apontam detalhadamente a deficiência da UML. No contexto de jogos, a UML demanda muito tempo e seus diagramas podem não estar consistentes.
Como foi citada, nos parágrafos anteriores, a modelagem UML é recomendada em desenvolvimento de jogos, com as devidas considerações. No próximo capítulo será descrita a Modelagem Objeto Processo e como ela pode ser utilizada em substituição da modelagem UML. Assim, justifica-se a OPM como uma opção em desenvolvimento de jogos digitais.
2.2. Metodologia Objeto-Processo
Um projeto arquitetônico de software ideal deve produzir um modelo de software que aperfeiçoa os requisitos funcionais e não funcionais, frequentemente conflitantes, de problemas do mundo real. A grande escala e a complexidade de projetos de software modernos resultam em desafios extremamente difíceis para designers de arquitetura de software (Lui e Glunch 2004). A linguagem de modelagem utilizada fornece a base para especificar o sistema desejado. Se essa linguagem não for muito técnica, ela pode facilitar a comunicação entre desenvolvedores de sistemas e clientes corporativos e fornece uma base para uma documentação de alta qualidade (Sturm, Dori e Sheohory, 2010). O modelo conceitual descreve a funcionalidade do sistema a ser desenvolvido, define os limites do sistema, sua relação com o ambiente e sua arquitetura de alto nível. Ele auxilia
a compor a base para a compreensão do nível do sistema pelas diferentes partes interessadas, tais como gerentes de engenharia de sistemas, gerentes de projeto, arquitetos e equipes multidisciplinares que realizam o projeto (Perelman, 2011).
A Metodologia Objeto-Processo é uma nova abordagem à modelagem de sistemas que preconiza combinar a abordagem clássica de modelagem orientada a processos com técnicas de modelagem orientada a objetos. A OPM se aplica à modelagem de qualquer tipo de sistema (físico ou lógico) não orientado a software unicamente. Ao longo dos anos, a OPM evoluiu para uma metodologia de ciclo de vida completo. Sua abordagem de modelagem única é a principal característica que atrai pesquisadores e desenvolvedores. O ponto forte da OPM reside no fato de que apenas um tipo de diagrama é usado para modelar a estrutura, função e comportamento do sistema. Essa abordagem de modelo único evita os problemas associados à multiplicidade do modelo, entretanto o modelo que é produzido pode ser mais complexo e difícil de entender (Ramsin e Paige, 2008).
OPM é um método de modelagem integrado que unifica a função do sistema, estrutura e comportamento dentro de um quadro de referência. Os blocos de construção do OPM são objetos, processos, estados e links estruturais e comportamentais que são ilustrados na Figura 1 (Reinhartz-Berger et al. 2002, Dori 2010, Mordecai e Dori 2014).
Fonte: Traduzido de Mordecai e Dori (2014).
Na OPM, um objeto é uma coisa que existe, ou pode existir, ―fisicamente‖ ou ―informaticamente‖. Os objetos podem conter estados, de tal forma que em cada ponto no tempo, o objeto está em um de seus estados ou em transição entre estados durante a execução de um processo. Um processo é uma ―coisa‖ (termo utilizado pela OPM) que transforma um objeto criando-o ou consumindo-o ou alterando seu estado.
Figura 2 - Características dos objetos e processos
Fonte: autoria própria.
Os objetos e processos têm características específicas quanto a sua essência, que é física (com sombreado) ou informática (sem sombreado). Os objetos e processos contêm um tipo de ―afiliação‖ que pode ser ambiental (contorno contínuo) ou sistêmica (contorno tracejado). A representação para cada caso está representada na Figura 2.
Os processos e objetos podem compreender outros processos e objetos. Os estados podem caracterizar objetos. As relações entre estes elementos são expressas por várias ligações. As ligações estruturais, mostradas na Figura 3, suportam a descrição dos aspectos do modelo estático.
Figura 3 - Relações Estruturais da OPM
Fonte: Traduzido de Mordecai e Dori (2014).
O triângulo do topo da imagem, que possui um triângulo menor dentro dele, exibe os objetos e processos que estão relacionados como características daquele objeto. Um exemplo seria um atributo ―Cor azul‖ de um objeto ―Bola‖, sendo que, removendo-o ou trocando-o, o objeto ―Bola‖ ainda continua existindo. O triângulo sem preenchimento
ilustra os processos/objetos especializados de um processo/objeto generalizado. Um exemplo seria um objeto ―Bola de futebol‖ que, além de ser também um objeto ―Bola‖, pode possuir outras características. O triângulo todo preenchido demonstra os objetos que são componentes ou partes de outro objeto. Um exemplo seria um objeto ―Motor‖ que é parte de um objeto ―Carro‖, onde sua existência é necessária para que um objeto ―Carro‖ esteja completo.
As ligações processuais, mostradas na Figura 4, suportam as relações processuais, dinâmicas e de causalidades (Mordecai e Dori 2014). O processo, quando não decorre de outro processo, ocorre apenas na presença de um objeto específico e este podendo ser em estados específicos. Processo como saída pode criar um objeto, alterar o estado de um objeto ou chamar outro processo.
Os processos transformam objetos criando-os, consumindo-os ou alterando seus estados. A representação simultânea de estrutura e comportamento no mesmo tipo de diagrama é equilibrada, criando sinergia em que cada aspecto ajuda a compreender o outro (Lui e Glunch 2004, Dori 2010).
Figura 4 - Relações Processuais da OPM
Fonte: traduzido de Mordecai e Dori (2014).
As visualizações integradas da OPM combinam as características estruturais, funcionais e comportamentais em um modelo. Nesta integração, a responsabilidade e os papéis de todas as entidades são claramente especificados e autodocumentados (Lui e
Glunch 2004). O desdobramento define relações estruturais entre o objeto ou processo principal e objetos e processos de nível inferior. Para processos, pode-se emergir ou imergir os detalhes. Essa característica é chamada in-zooming e permite definir uma ordem de execução cronológica parcial dos subprocessos incluídos (Perelman, 2011). A OPM é adequada tanto para a análise, quanto para a concepção do sistema, permitindo uma transição suave entre estas fases (Peleg e Dori, 1999).
Além da OPM, Dori também desenvolveu a Object-Process CASE (Computer-Aided Software Engineering) Tool (OPCAT), ferramenta que suporta os Object-Process Diagrams (OPD) e uma representação textual equivalente, denominada Object-Process Language (OPL). Tanto o OPD quanto a OPL fazem parte da metodologia (Lui e Glunch 2004, Dori 2010).
Fonte: Dori et al (2010).
A interface gráfica e textual combinada do OPCAT foi projetada para tirar vantagem das habilidades de linguagem natural e intuição gráfica. Um usuário do OPCAT pode esboçar sua ideia no OPD e depois verificar se as especificações textuais da OPL correspondem à sua intenção (Lui e Glunch 2004). A tradução de um OPD definido para o script OPL correspondente e vice-versa é feito automaticamente, de modo que o designer
pode trabalhar de forma intercambiável na versão gráfica ou textual da especificação (Reinhartz-Berger et al. 2002). O recurso de zoom permite aos projetistas escolher o nível de granularidade e compreender os designs OPM, de abstrações de alto nível até apresentações detalhadas de mais baixo nível (Lui e Glunch 2004).
Para a modelagem OPM dos jogos foi utilizada a ferramenta OPCAT versão 4.0 (OPCAT Systems, 2011). A escolha da OPCAT deve-se ao fato de que é uma ferramenta gratuita e foi criada justamente com o propósito de auxiliar a modelagem Objeto-Processo. A Figura 5 ilustra um exemplo de interface do programa OPCAT. O quadro nomeado ―SD‖ contém o Diagrama Objeto-Processo e abaixo dele temos outro quadro, com a Linguagem Processo, que descreve o diagrama. A Linguagem Objeto-Processo é gerada automaticamente conforme é construído o diagrama.
A metodologia Objeto-Processo, descrita por Dori (2002), foi aplicada em várias propostas, como modelagem de Enterprise Resource Planning (Soffer et al, 2005), sistema em tempo real (Peleg e Dori, 1999), transações de cartões de crédito (Dori, 2001), como ferramenta de modelagem de negócios (Dori, 2000) e especificação de algoritmos (Wenyin e Dori, 1999).
Figura 6 - Metamodelo OPM de nível superior de Tomada de Decisão (OPD)
Fonte: traduzido de Mordecai e Dori (2014).
Como forma de exemplo, o trabalho ―Conceptual Modeling of System-Based
Decision-Making‖ de Mordecai, Yaniv e Dori (2014), descreve uma aplicação da OPM. A
Figura 6 descreve um metamodelo OPM de nível superior de tomada de decisão (OPD) e a Figura 7 descreve OPD do processo de ―Tomar Decisão‖ em zoom. Comparando as
figuras 6 e 7 podemos ver como o zooming funciona na maneira de exibição do processo. Na Figura 6 o processo ―Tomada de Decisão‖ está abstraído (zoom-out) e na Figura 7 o mesmo processo está ampliado (zoom-in), mostrando de forma mais detalhada que o processo consiste de subprocessos e o relacionamento entre eles.
Na Figura 6, interpreta-se que o processo de ―Tomar Decisão‖ é um método do ―Agente Decisor‖, um ―Conjunto de Decisores‖ controla o processo de ―Tomar Decisão‖ e isso só ocorre com a presença de um ―Modelo de Decisão‖ e de um conjunto de ―Variáveis de Estados‖. O processo de ―Tomar Decisão‖ afeta o ―Conjunto de Variáveis de Decisão‖.
A Figura 7 apresenta o detalhamento do processo ―Tomar Decisão‖, que embora possua maior especificação da interação dos objetos e processos, as informações da Figura 6 permanecem representadas. Na Figura 7 têm-se vários subprocessos, que estão representados um abaixo do outro. Essa representação é uma característica da modelagem OPM na qual a representação vertical, indica que os processos situados no topo ocorrem primeiro e em seguida os situados logo abaixo. Já os processos lado a lado ocorrem simultaneamente.
Figura 7 - OPD do processo de tomada de decisão em zoom
Os modelos de interação entre os elementos que compõem os diagramas da OPM (13 no total) são em menor número do que os da UML. A UML tem 14 tipos de diagramas e cada um destes tem um conjunto ligeiramente diferente de interações. Como o OPM só tem um tipo de diagrama, a concisão dos padrões de interação ajuda a simplificar o esforço de modelagem (Lui e Glunch 2004). No artigo ―Object-Process Methodology (OPM) vs. UML: A Code Generation Perspective‖ os autores Reinhartz-Berger, Iris e Dori (2014) concluíram que os problemas de consistência na UML e sua representação distribuída do comportamento do sistema são refletidos no código, resultando em código parcial que é principalmente orientado à estrutura. Os modelos OPM, por outro lado, capturam os aspectos estáticos e dinâmicos de um sistema em uma única visão coerente, permitindo a geração de uma lógica de aplicativo potencialmente completa em vez de apenas um código esqueleto.
Figura 8 – Exemplo de interface da game engine Unity3D
Fonte: autoria própria.
De acordo com a proposta de Barros (2007), a criação do jogo é fase que envolve a produção do jogo, em que é feito o desenvolvimento do código-fonte, e da arte audiovisual do jogo. A construção do jogo foi feita a partir do Diagrama Objeto-Processo como base para desenvolvimento do sistema na camada de código de jogo. Para auxiliar na elaboração dos códigos foi utilizado o Game Engine Unity3D (Unity Technologies, 2009), versão 5.6.0f3, dando um nível maior de abstração para o desenvolvimento. A
game engine é uma camada de software que disponibiliza recursos de mais alto nível a serem empregados pelo ―código do jogo‖, facilitando seu desenvolvimento.
As Game Engines tornaram-se o estado da arte no desenvolvimento de muitos títulos de jogos comerciais. Ao fornecer mais abstração, encapsulamento do conhecimento e uma base de desenvolvimento de jogos reutilizáveis, eles permitiram que a indústria de jogos alcançasse um nível de produtividade incomparável (Furtado, 2012). A Game Engine Unity 3D é um sistema orientado por Game Objects (Objetos de jogo), que abstrai diversas funções através de associação de componentes (scripts pré-definidos).
Este capítulo apresentou o contexto do desenvolvimento de jogos digitais e descreveu as principais características da modelagem OPM. Também foram citados estudos que foram realizados sobre a análise entre as modelagens UML e OPM. Com base neste estudo, as modelagens foram aplicadas e analisadas no desenvolvimento de um jogo digital, que é descrito nos próximo capítulo.
3. APLICAÇÃO DA UML E DA OPM EM UM JOGO DIGITAL
Este capítulo descreve o processo de desenvolvimento de um jogo digital aplicando a UML e a OPM. Para isso, foi desenvolvido um jogo digital, de autoria própria, as partir dos diagramas UML e OPM. Tanto a modelagem UML como a OPM, de autoria própria, foram feitas por um estudante com experiência de nível acadêmico. Entretanto, a qualidade das modelagens segue o desenvolvimento mais próximo possível que a literatura recomenda. A elaboração do jogo foi feita em quatro etapas: a definição dos requisitos do jogo, a modelagem dos requisitos em UML, a modelagem dos requisitos em OPM e a programação do jogo.
3.1. Descrição do jogo ―Square Overflow‖
O jogo proposto para este estudo deste capítulo foi denominado ―Square Overflow‖. Trata-se de um jogo que desafia o jogador identificar um padrão de luzes por meio da sua capacidade de reconhecimento visual. Foi optado por fazer esse jogo porque seu mecanismo é simples e tem pequeno porte, facilitando a correlação entre os diagramas da UML e da OPM.
Figura 9 - Tela inicial do "Square Overflow"
A Figura 9 refere-se à tela inicial do jogo, que contém a opção de iniciar o jogo e sair do jogo. Assim que o jogador aciona o botão ―Jogar‖, uma nova partida é iniciada. O jogador pode também a qualquer momento acionar o botão ―Sair‖ para fechar o jogo.
Ao inicializar uma partida, o jogador será desafiado a indicar o padrão de luzes que é formado por um conjunto de quadrados acesos. A Figura 10 mostra um exemplo de uma tela do jogo inicializando um novo nível. Esta tela contém os textos: ―Pontos‖, exibindo a pontuação atual, e ―Erros‖, exibindo os erros cometidos, e um conjunto de quadrados com os tipos: cinza (apagado) e branco (aceso). O padrão dos quadrados acesos é exibido na tela por um período de dois segundos. Este período é reservado para que o jogador tente memorizar o padrão. Após este período de tempo todos os quadrados são apagados (em cor cinza). Na Figura 10, o padrão é formado pelos três quadrados acesos.
Figura 10 - Exemplo de novo nível do jogo "Square Overflow"
Fonte: autoria própria.
A Figura 11 exibe um exemplo de tela durante a execução do jogo, que representa a continuação da partida exibida na Figura 10. Quando o jogador seleciona um quadrado pertencente ao padrão, este quadrado permanece aceso e é computado um ponto. Na Figura 11, o quadrado no canto superior direito foi selecionado e permaneceu aceso, pois foi uma seleção correta. Quando o jogador seleciona um quadrado que não pertence ao padrão, o quadrado é removido e é adicionado um erro. Observando a Figura 11, a matriz
não exibe um quadrado no canto inferior esquerdo. Havia um quadrado anteriormente que foi selecionado e, como não pertencia ao padrão, foi removido da matriz.
Figura 11 - Exemplo de execução de um nível do jogo "Square Overflow"
Fonte: autoria própria.
Figura 12 – Tela contento o botão ―Próximo nível― do jogo "Square Overflow"
Figura 13 - Tela ―Fim de Jogo‖ do jogo "Square Overflow"
Fonte: autoria própria.
Após cada ação do jogador, ocorre a verificação de condição de vitória, que é a formação do padrão exibido, ou condição de derrota, que é errar além do limite permitido. A cada vez que a vitória é alcançada, um novo nível é criado, com um número maior de quadrados que a fase anterior e em um novo padrão. A Figura 12 mostra uma tela com o botão ―Próximo nível‖ e o texto informativo mostrando o total de pontos. Quando ocorre uma derrota, a partida acaba, exibindo a tela de fim de jogo, que está representada na Figura 12. É exibido o total de pontos e o botão ―Jogar‖, que ao acioná-lo, começa uma nova partida.
3.2. Requisitos do software ―Square Overflow‖
Os requisitos funcionais e não funcionais do software ―Square Overflow‖ são apresentados na Tabela 1. Foi dado foco apenas aos requisitos funcionais para o desenvolvimento e a compreensão do uso das modelagens UML e OPM.
Tabela 1 - Requisitos funcionais e não funcionais do jogo ―Square Overflow‖ Requisitos funcionais
RF01 O software deverá permitir a um jogador iniciar uma nova partida de jogo se uma partida não estiver em andamento.
RF02 O software deverá criar uma nova matriz de quadrados e um novo padrão de luzes quando for iniciada nova partida ou um novo nível. RF03 O software deverá permitir ao jogador selecionar um quadrado. RF03.1 O software deverá marcar ponto se o jogador selecionar um
quadrado pertencente ao padrão.
RF03.2 O software deverá emitir som se o jogador selecionar um quadrado pertencente ao padrão.
RF03.3 O software deverá marcar erro se o jogador selecionar um quadrado fora do padrão.
RF03.4 O software deverá emitir som se o jogador selecionar um quadrado fora do padrão.
RF04 O software deverá exibir os pontos na tela. RF05 O software deverá exibir os erros na tela. RF06 O software deverá tocar música de fundo
RF07 O software deve permitir ao jogador avançar o nível da partida caso tenha selecionado o padrão exibido.
RF09 O software deverá permitir ao jogador sair do jogo. Requisitos não funcionais
NRF01 O software será feito com a game engine Unity3D. Fonte: autoria própria.
3.3. Modelagem UML do jogo ―Square Overflow‖
A modelagem UML foi desenvolvida com o auxílio da ferramenta Astah Community versão 6.6.4 (Vision Change, 2012). A escolha da ferramenta deveu-se à simplicidade de uso e gratuidade da versão. Para a modelagem do ―Square Overflow‖ foram escolhidos apenas os principais diagramas que têm representatividade para esse projeto: Casos de Uso, Classes, Comunicação, Estados e Sequência. Devido ao pequeno porte do projeto, os diagramas de pacotes e componentes não foram modelados. Como foi escolhido o diagrama de Estados, o diagrama de atividade não foi modelado, em razão da redundância entre estes diagramas.
O diagrama de Casos de Uso da Figura 14 descreve quatro casos de uso, que são as utilizações que o jogador (ator) poderá fazer do sistema. O caso de uso ―Iniciar nova partida‖ está relacionado com o jogador poder iniciar uma nova rodada do jogo com a pré-condição de que não tenha uma partida em andamento. O caso de uso ―Iniciar nova
partida‖ implica que o software, por meio do subcaso de uso ―Gerenciar nível‖, crie um nível e, desta forma, uma nova partida é iniciada. Quando um novo nível é criado, os textos da tela são atualizados.
Figura 14 - Diagrama de Casos de Uso ―Square Overflow‖
Fonte: autoria própria.
O caso de uso ―Selecionar quadrados‖ permite que o jogador selecione quadrados durante o andamento de uma partida. O andamento de uma partida ocorre enquanto o padrão de luzes não está totalmente selecionado e o total de erros não excede o limite permitido. Quando o jogador faz seleção de um quadrado, o software checa a condição
de vitória ou derrota pelo subcaso de uso ―Gerenciar nível‖, atualiza as informações da tela pelo subcaso de uso ―Atualizar as informações da tela‖ e emite um áudio pelo subcaso de uso ―Emitir som‖.
O caso de uso ―Avançar nível‖ permite que o jogador continue a partida avançando para o próximo nível. O jogador deverá ter resolvido o nível anterior, tendo selecionado todo o padrão de luzes como pré-condição. O nível é incrementado pelo software por meio do subcaso de uso ―Gerenciar nível‖, que cria o próximo nível, mais complexo, a partir dos parâmetros do nível anterior.
O caso de uso ―Sair do jogo‖ permite que o jogador encerre o jogo a qualquer momento da partida e o caso de uso é o ―Ouvir música‖ que consiste de tocar música de fundo durante o jogo. Este caso de uso não depende da ação do jogador para existir.
O diagrama de Classes da Figura 15 descreve a estrutura das classes, assim como seus atributos, operações e relações. Optou-se por utilizar nomes em inglês para as classes. As classes contendo o sufixo ―Button‖ são botões e contendo o sufixo ‗‖UI‖ são elementos da User Interface (interface do usuário).
Quando o software é inicializado, é exibido o botão ―Jogar‖, que representado pela classe PlayButton. Este botão permite ao jogador inicializar uma nova partida. Ao solicitar uma nova partida, a classe de controle GameManager realiza a parametrização das variáveis e cria um novo nível. Ao ser selecionado, o PlayButton também acessa as classes pertencentes a tela fazendo as seguintes alterações: as classes que exibem texto PointsUI, ErrorUI, InfoGameUI tem seus textos inicializados e o título TitleUI é ocultado.
A criação do nível é feita pela classe GameManager, que limpa a tela destruindo todos os quadrados e instancia uma matriz de quadrados. Os quadrados contêm a classe SquareButton, que controla seu comportamento no jogo. Durante o andamento da partida, a classe SquareButton recebe as seleções do jogador e informa a classe GameManager, que atualiza os parâmetros da partida, as informações na tela (TitleUI, PointsUI, ErrorUI, InfoGameUI) e faz a verificação de vitória ou de derrota. A seleção também emite som que é controlado pela classe SquareButton.
Figura 15 - Diagrama de Classes ―Square Overflow‖
O botão ―Próximo nível‖ está associado à classe NextLevelButton que é responsável por solicitar um novo nível ao GameManager. A classe GameManager ativa o botão NextLevelButton quando um nível é concluído e o botão PlayButton quando os muitos erros levam ao encerramento da partida. Ambos os botões se desativam após a seleção do jogador.
O botão ―Sair‖ está associado à classe ExitGameButton que realiza o encerramento do jogo. Este botão fica ativo durante todo o jogo. A classe MusicManager é responsável por tocar o áudio do jogo que inicializa assim que o jogo começa.
Figura 16 - Diagrama de Sequência ―Iniciar uma nova partida‖ do jogo ―Square Overflow"
Fonte: autoria própria.
A Figura 16 mostra o diagrama de sequência do processo de inicialização de uma nova partida. A partida começa assim que o jogador seleciona o botão ―Jogar‖ que possui a classe PlayButton. O botão faz a solicitação de um novo nível para o GameManager, oculta o título (TitleUI), inicializa os textos (PointsUI, ErrorsUI) e se desativa.
A Figura 17 mostra a parte do processo que ocorre ao executar a função nextLevel que é chamada tanto no início de uma nova partida quanto na criação de um próximo nível. Como os quadrados são instanciados em forma de matriz, há dois loops que são o
eixo vertical e o eixo horizontal. Na criação dos quadrados, a parametrização determina se será parte do padrão ou não. A matriz é criada mostrando todo o padrão e, logo após dois segundos, o padrão é ocultado pela classe SquareButton.
Figura 17 - Diagrama de Sequência ―NextLevel‖ do jogo ―Square Overflow"
Fonte: autoria própria.
A Figura 18 mostra o diagrama de sequência da seleção de um quadrado. O processo começa quando o jogador faz uma seleção de um quadrado. Quando selecionado, informa a classe GameManager se pertence ao padrão ou não. Isso faz com que seja executada a função countPoint em caso de padrão ou countError em caso de erro. Na sequência, o quadrado realiza mudança de aparência e emite um som.
A Figura 19 mostra o processo de execução da função countPoint de forma completa. Com a seleção de um quadrado no padrão é realizada a atualização do texto PointsUI que exibe os pontos e então é feita a verificação se todo o padrão foi selecionado. Caso isso tenha ocorrido, a sequência continua com um loop, que destrói todos os quadrados, com atualização dos textos ErrorsUI e InfoGameUI e é habilitado o botão ―Próximo nível‖ (NextLevelButton).
Figura 18 - Diagrama de Sequência ―Selecionar quadrados‖ do jogo ―Square Overflow"
Fonte: autoria própria.
Figura 19 - Diagrama de Sequência ―countPoint‖ do jogo ―Square Overflow"
Figura 20 - Diagrama de Sequência ―countError‖ do jogo ―Square Overflow"
Fonte: autoria própria.
Figura 21 - Diagrama de Sequência ―Avançar nível‖ do jogo ―Square Overflow".
A Figura 20 exibe o processo de execução da função countError. Quando a classe GameManager recebe uma seleção fora do padrão, atualiza o texto do erro (ErrorsUI) e verifica se o limite de erros foi atingido. Caso o limite de erros seja atingido a classe GameManager destrói todos os quadrados num loop, informa o fim do jogo (InfoGameUI), exibe o título (TitleUI) e habilita o botão ―Jogar‖ (PlayButton).
A Figura 21 mostra a sequência do processo de avanço de nível. Quando o jogador seleciona o botão ―Próximo nível‖, que tem a classe NextLevelButton, a classe
GameManager irá criar um novo nível conforme o diagrama de Sequência ―NextLevel‖. O
botão ―Próximo nível‖ limpa o texto informativo InfoGameUI e se desabilita.
A Figura 22 mostra a sequência de saída do jogo. Assim que o jogador selecionar o botão ―Sair‖, sua classe ExitGameButton executa a função de encerramento.
Figura 22 - Diagrama de Sequência ―Sair do jogo‖ do jogo ―Square Overflow‖
Fonte: autoria própria.
A Figura 23 exibe o diagrama de sequência ―Ouvir música‖. O áudio da música começa a tocar assim que a classe MusicManager é criada. A classe MusicManager é instanciada pela engine Unity3D e que também, em algum momento, com o encerramento do jogo, é destruída. A criação e destruição das classes pela Unity3D ocorrem também da mesma forma com as demais classes, embora não esteja explicito-nos outros diagramas.
Figura 23 - Diagrama de Sequência ―Ouvir música‖ do jogo ―Square Overflow‖
Fonte: autoria própria.
A Figura 24 mostra o diagrama de comunicação ―Iniciar nova partida‖. Assim que o jogador seleciona o botão ―Jogar‖, a classe PlayButton solicita a criação de um novo nível, inicializa os textos (PointsUI, ErrorUI, InfoGameUI) e esconde o título (TitleUI) e se desativa. Quando os quadrados são instanciados pela classe GameManager, a classe
SquareButton bloqueia a seleção do jogador e executa a função
StartCoroutine(showingFrame()) que no decorrer de dois segundos libera a seleção e oculta o padrão.
A Figura 25 mostra o diagrama de comunicação da seleção de quadrados. Cada vez que o jogador seleciona um quadrado, a classe SquareButton informa a classe GameManager, emite um som e muda de aparência. A classe GameManager faz a verificação se é um quadrado pertencente ao padrão ou não. No caso de acerto: pontua, altera o texto de pontos na tela e se o padrão estiver completado informa o jogador e habilita o botão ―Próximo nível‖. No caso de erro: marca erro, atualiza o texto de erro na tela e caso tenha excedido o limite de erro na tela, informa o fim do jogo e habilita o botão de ―Jogar‖.
Figura 24 – Diagrama de Comunicação ―Iniciar nova partida‖ do jogo ―Square Overflow‖
Figura 25 - Diagrama de Comunicação ―Selecionar quadrados‖ do jogo ―Square Overflow‖
Fonte: autoria própria.
Figura 26 - Diagrama de Comunicação ―Avançar nível‖ do jogo ―Square Overflow‖
Fonte: autoria própria.
A Figura 26 exibe o diagrama de comunicação sobre o processo de avançar nível. Quando o jogador seleciona o botão ―Próximo nível‖ a classe NextLevelButton solicita à
GameManager a criação de um novo nível e o botão de ―Próximo nível‖ é desabilitado. Os
no diagrama de comunicação ―Iniciar nova partida‖.
A Figura 27 mostra o diagrama de comunicação do processo de saída do jogo. Quando o botão ―Sair‖ é selecionado a classe ExitGameButton chama a função quitGame que realiza o fechamento do jogo.
Figura 27 - Diagrama de Comunicação ―Sair do jogo‖ do jogo ―Square Overflow‖
Fonte: autoria própria.
A Figura 28 mostra o diagrama de comunicação ―Ouvir música‖. A função play é a única função que o MusicManager executa durante o jogo.
Figura 28 - Diagrama de Comunicação ―Ouvir música‖ do jogo ―Square Overflow‖
Fonte: autoria própria.
A Figura 29 mostra os estados alcançáveis do botão PlayButton ao longo do processo. O botão existe assim que o jogo é inicializado e fica aguardando que o jogador o selecione. Quando é selecionado, os textos são inicializados, o título é ocultado e por
fim fica aguardando até que a condição de encerramento do jogo faça com que o GameManager reabilite o botão.
Figura 29 - Diagrama de Estado ―PlayButton‖ do jogo ―Square Overflow‖
Fonte: autoria própria.
A Figura 30 exibe o diagrama de estado do botão ―quadrado‖ que possui a classe SquareButton. Assim que o botão é instanciado, sua seleção se torna desabilitada e a função interna StartCoroutine(showingFrame()) é inicializada. No decorrer de dois segundos o padrão é escondido e a seleção do botão é habilitada. Após a ocultação do padrão o botão fica estado de aguardando seleção. Quando o botão é selecionado, a classe SquareButton informa o GameManager para realizar o processamento de sua seleção, emite áudio, muda a imagem, impede que seja selecionado novamente e fica aguardando a criação de um novo nível.
Figura 30 - Diagrama de Estado ―SquareButton‖ do jogo ―Square Overflow‖
Fonte: autoria própria.
Figura 31 - Diagrama de Estado ―NextLevelButton‖ do jogo ―Square Overflow‖
Fonte: autoria própria.
NextLevelButton. Quando o jogo é inicializado o botão está inicialmente ocultado, pois não existe uma partida em andamento. O estado inicial é ―Aguardando habilitação‖ e sua habilitação irá ocorrer pela classe GameManager sempre que o jogador completar o padrão de um nível. Quando o jogador selecionar o botão, é ocultado o texto informativo InfoGameUI e o processo de novo nível será encaminhado para a classe GameManager e o botão se desabilita novamente.
A Figura 32 mostra o diagrama de estado da classe GameManager. Esta classe fica aguardando que seja solicitado um novo nível ou que o jogador selecione um quadrado. Como na inicialização do jogo não há nenhum nível em andamento, o estado inicial é aguardando a solicitação de um novo nível (nextLevel()), que pode ser feita pela seleção do botão ―Jogar‖ ou ―Próximo nível‖. Após a criação de um novo nível, a classe GameManager fica aguardando a seleção de um quadrado pelo jogador.
Figura 32 - Diagrama de Estado ―GameManager‖ do jogo ―Square Overflow‖
Fonte: autoria própria.
Com a seleção de um quadrado no padrão, ocorre o processo mostrado no diagrama de sequência ―countPoint‖. É realizada a atualização do texto PointsUI que exibe os pontos e então é feita a verificação se todo o padrão foi selecionado. Caso o
padrão ainda esteja incompleto, o GameManager continua aguardando a próxima seleção. Caso isso tenha ocorrido, todos os quadrados são destruídos, são atualizados os textos ErrorsUI e InfoGameUI e é ativado o botão ―Próximo nível‖ (NextLevelButton).
Quando a classe GameManager recebe uma seleção fora do padrão, atualiza o texto do erro (ErrorsUI) e verifica se o limite de erros foi atingido. Caso o número de erros não tenha atingido o limite, o GameManager continua aguardando a próxima seleção. Caso o limite de erros seja atingido a classe GameManager destrói todos os quadrados, informa o fim do jogo (InfoGameUI), exibe o título (TitleUI) e habilita o botão ―Jogar‖ (PlayButton).
A Figura 33 descreve os estados do botão ―Sair‖ que contém a classe ExitGameButton. O botão fica habilitado desde a inicialização do jogo e fica aguardando a seleção do jogador para executar o fim do jogo.
A Figura 34 exibe os dois únicos estados que os elementos da tela possuem, o título ―TitleUI‖, uma imagem que pode ser exibida ou ocultada e os demais textos que mudam o conteúdo escrito.
Figura 33 - Diagrama de Estado ―ExitGameButton‖ do jogo ―Square Overflow‖
Figura 34 - Diagramas de Estado dos elementos da tela do jogo ―Square Overflow‖
Fonte: autoria própria.
Figura 35 - Diagramas de Estado dos elementos da tela do jogo ―Square Overflow‖
Fonte: autoria própria.
A Figura 35 mostra os estados possíveis da classe MusicManager. A classe inicia a reprodução da música e permanece neste estado até que o jogo seja encerrado pelo jogador.
Com a realização da modelagem dos diagramas UML, foram gerados, no total, vinte e dois diagramas, sendo um de caso de uso, um de classe, sete de sequência, cinco de comunicação e nove de estados.
3.4. Modelagem OPM do jogo ―Square Overflow‖
Para a realização da modelagem OPM optou-se por iniciar o diagrama a partir das utilizações do jogo. Desta forma, o diagrama OPM da Figura 36 ilustra os cinco processos correspondentes às cinco utilizações do jogo que são: ―Tocando música‖, ―Iniciando nova partida‖, ―Selecionado quadrados‖, ―Avançando nível‖ e ―Saindo do jogo‖. Optou-se por escrever os nomes dos processos no gerúndio, uma vez que a tradução dos diagramas OPM do inglês para o português comporta mais de uma interpretação. Como existem várias relações no diagrama principal, foi utilizado o recurso de cores para facilitar sua visualização.
Figura 36 – Diagrama principal do jogo ―Square Overflow‖
Fonte: autoria própria.
O jogador (pessoa) está representado como ―objeto físico‖ (sombreado). Os objetos dos botões utilizados pelo jogador, que são ―PlayButton‖, ―SquareButton‖, ―NextLevelButton‖ e ―ExitGameButton‖, estão representadas como ―objetos informáticos‖
(sem sombreado) pois são ―botões virtuais‖ acessados pelo cursor do mouse. Como o processo ―Tocando música‖ é simples, todo o funcionamento já está sendo exibido no diagrama principal, que inicializa o componente ―AudioSource‖ pelo estado ―play‖, enquanto os demais estão generalizados. Os componentes dos objetos e os subprocessos aparecem conforme é feito o ―in-zooming‖.
Figura 37 - Diagrama ―Iniciando nova partida in-zoomed‖ do jogo ―Square Overflow‖
O diagrama da Figura 37 representa o ―in-zooming‖ aplicado ao processo ―Iniciando nova partida‖. O primeiro subprocesso é o ―Selecionando botão‖, que envolve o evento (representado pela letra ―e‖) que é disparado quando o jogador realiza sua seleção. Existe também uma condição (representado pela letra ―c‖) que determina que para isto ocorrer, um objeto precisa estar em um estado específico para um processo acontecer. No caso do processo ―Selecionando botão‖, uma das condições para a sua execução é que o objeto ―PlayButton‖ precisa estar em seu o estado inicial (borda grossa) ―Aguardando seleção‖. Este processo ocorre de maneira similar com os outros botões do sistema. Os demais subprocessos só ocorrem com a execução do anterior (acima), conforme a cronologia esperada.
Quando o botão ―PlayButton‖ muda de estado para selecionado, são executados os subprocessos ―Gerenciando nível‖ e ―Atualizando tela‖ que estão generalizados e o subprocesso ―Desativando‖. O subprocesso ―Desativando‖ faz a desativação pela alteração do parâmetro ―active‖ do ―GameObject‖, que é um objeto componente do botão.
A Figura 38 mostra a ampliação do subprocesso ―Gerenciando nível‖ que possui o subprocesso ―Criando novo nível‖ que é chamado tanto pelo ―NextLevelButton‖ quanto por ―PlayButton‖. O arco entre dois ou mais pontos de objetos apontando para o mesmo processo significa que uma relação ou outra é o suficiente para realizar a execução do processo. O objeto GameManager que representa a classe GameManager instancia os quadrados quando é solicitada a criação de um novo nível. O processo de instanciar quadrados é invocado novamente até que seus parâmetros ―Eixo X‖ e ―Eixo Y‖ alcancem um determinado valor limite. O processo ―Inicializando quadrado‖ está fora do processo ―Gerenciando nível‖ e ocorre de maneira independente, pois sua inicialização está associada somente ao estado inicial do objeto.
A Figura 39 mostra o processo de inicialização de um quadrado de forma mais detalhada. O andamento dos processos segue a ordem vertical, na qual um quadrado com o parâmetro ―Pattern‖ igual a ―true‖ faz a ocultação da imagem além dos demais processos. O objeto ―Temporizador‖ é uma forma de representação de que um período de passou e seus estados mudam com o decorrer do tempo. Os objetos ―Button‖, ―Pattern‖ e ―Image‖ são componentes pertencentes ao objeto ―SquareButton‖ que contém parâmetros equivalentes aos das classes em UML.
Figura 38 - Diagrama ―Gerenciando nível in-zoomed‖ do jogo ―Square Overflow‖.
Figura 39 - Diagrama ―Inicializando quadrado in-zoomed‖ do jogo ―Square Overflow‖.
Figura 40 - Diagrama ―Atualizando tela in-zoomed‖ do jogo ―Square Overflow‖.
Fonte: autoria própria.
A Figura 40 mostra o diagrama do subprocesso ―Atualizando tela‖ com zoom. Este processo é executado tanto pelo ―PlayButton‖ como o ―NextLevelButton‖. O processo desencadeia a ocultação do título e a atualização dos textos. Entretanto, ao iniciar uma partida, o texto informativo ―InfoGameUI‖ se encontra vazio, por isso só há necessidade do processo ―Setando o texto InfoGameUI‖ ocorrer na presença do ―NextLevelButton‖.
Figura 41 - Diagrama ―Selecionando quadrados in-zoomed‖ do jogo ―Square Overflow‖.
A Figura 41 contém o diagrama ―in-zoomed‖ do processo ―Selecionando quadrados‖. Assim como os demais botões, este processo é inicializado pelo jogador quando ele faz uma seleção. Se um quadrado possui o parâmetro ―Pattern‖ como valor ―true‖, então ele pertence ao padrão de luzes e quando ele é selecionado o subprocesso ―Contando pontos‖ é chamado. Caso um quadrado tenha o parâmetro ―Pattern‖ com o valor ―false‖, então ele não pertence ao padrão de luzes e se for selecionado o subprocesso ―Contando erros‖ será inicializado. Após a execução desses subprocessos, o som, que está pré-definido para o botão, é tocado e então sua imagem muda. A imagem muda, de acordo com a presença ou não do padrão, para que o jogador tenha o retorno visual da ação. Por fim, a opção de seleção do botão é desativada para evitar uma nova seleção.
O diagrama ―Contando pontos in-zoomed‖ da Figura 42 mostra o processo similar ao do diagrama de sequência UML ―CountPoints‖. A seleção sempre faz a atualização dos pontos ―PointsUI‖ e, caso atinja a condição de selecionar todo o padrão (numberOfPatters <= currentHits), outros subprocessos são desencadeados pelo objeto GameManager. O processo de preparar um novo nível é desencadeado, desta forma os quadrados são destruídos para a criação de novos, o texto de erro é atualizado, o texto de total de pontos ―InfoGameUI‖ é exibido e o botão ―NextLevelButton‖ é ativado para que o jogador solicite o próximo nível.
A Figura 43 mostra o diagrama ―Contando erros‖ em zoom. Quando o quadrado que está fora do padrão é selecionado, o processo contabiliza um erro e seu total atualizado é exibido na tela. Ao atingir o limite de erros permitidos (limitErrors <= currentErrors), o ―GameManager‖ realiza a limpeza da tela destruindo os quadrados, informa o final do jogo pelo texto informativo ―InfoGameUI‖, exibe o titulo e habilita o botão ―PlayButton‖ para que o jogador possa começar uma nova partida.
A Figura 44 se refere ao diagrama ―Avançando nível‖ em zoom que representa uma das cinco ações do diagrama principal. Quando o jogador executa uma seleção, os subprocessos ―Gerenciando nível‖ e ―Atualizando tela‖ são chamados e, por fim, o botão é desativado. Os diagramas da Figura 37 - ―Iniciando nova partida‖ in-zoomed e da Figura 44 – ―Avançando nível‖ in-zoomed são parecidos e utilizam os mesmos subprocessos. Os subprocessos ―Gerenciando nível‖ e ―Atualizando tela‖ estão representados na Figura 38 e 40 respectivamente. Isto é possível por que se trata do mesmo objeto ―GameManager‖ que está envolvido na execução dessas operações.
Figura 42 - Diagrama ―Contando pontos in-zoomed‖ do jogo ―Square Overflow‖
Figura 43 - Diagrama ―Contando erros in-zoomed‖ do jogo ―Square Overflow‖
Figura 44 - Diagrama ―Avançando nível in-zoomed‖ do jogo ―Square Overflow‖
Fonte: autoria própria.
A Figura 45 mostra de forma detalhada o processo envolvido com o botão ―ExitGameButton‖. Assim que o jogador realiza a seleção, a função de encerramento do jogo é acionada.
Figura 45 - Diagrama ―Saindo do jogo in-zoomed‖ do jogo ―Square Overflow‖
Fonte: autoria própria.
O desenvolvimento da modelagem OPM gerou dez diagramas no total. O diagrama OPM ―Ações do jogador‖ tem a estrutura similar ao diagrama de caso de uso, os processos seguem fluxo similar ao dos diagramas de sequência e os estados dos diagramas de estados UML estão presentes na execução dos processos e nos estados dos objetos.
3.5. Programação do jogo ―Square Overflow‖
A programação do jogo foi feita utilizando objetos do tipo GameObject, compostos por componentes pré-definidos do Unity3D, incluindo o componente Scripts realizado em linguagem C#. Para este projeto foram utilizados elementos da interface do usuário, que são botões, textos e imagens fixados na câmera. Os quadrados gerados pelo gerenciador de nível, são botões, possuindo a ação OnClick(). Esta ação, que é da própria engine Unity3D, realiza a chamada de uma ou mais funções no programa quando o botão é
