GOG: Uma arquitetura para criação de jogos de empresa

CENTRO UNIVERSITÁRIO DA FEI

GIAN MARCO FERRARI
GUSTAVO MARTELLA ACHKAR
ORLANDO DA SILVA JUNIOR

GOG: uma arquitetura computacional para a criação e o uso de jogos de empresa

São Bernardo do Campo
2011

GIAN MARCO FERRARI
GUSTAVO MARTELLA ACHKAR
ORLANDO DA SILVA JUNIOR


Trabalho de Conclusão de Curso apresentado ao
Centro Universitário da FEI como parte dos
requisitos necessários para obtenção do título de
Bacharel em Ciência da Computação, orientado
pelo Prof. Dr. Rodrigo Filev Maia.

2011

Gian Marco Ferrari
Gustavo Martella Achkar
Orlando da Silva Junior


Trabalho de Conclusão de Curso – Centro Universitário da FEI

Comissão julgadora

_________________________________________________
Orientador e Presidente

_________________________________________________
Examinador (1)

_________________________________________________
Examinador (2)

2011

RESUMO

Jogos de Empresas constituem hoje uma importante ferramenta no auxílio ao aprendizado em
certos cursos, sendo adotados por diversas instituições. Porém, apresentam os seguintes
problemas: são caros, poucos, não satisfatoriamente específicos e de difícil utilização e
adaptação. Neste trabalho é proposta uma arquitetura capaz de permitir que não somente a
aplicação, mas também a concepção de jogos de empresas fique a cargo do professor que os
utiliza, pois, embora essa abordagem exija um maior interesse e esforço por parte do mesmo,
dessa forma é possível a personalização do jogo de empresas, adequando-o as necessidades do
professor e dos demais envolvidos. Como resultado espera-se que um professor leigo, através
da definição de um fluxo de jogo próprio e configuração dos módulos de jogo pré-
programados, encontre na arquitetura proposta a flexibilidade necessária para criar seus
próprios jogos e consequentemente supra suas necessidades.

Palavras-chave: jogo de empresas – workflow – arquitetura computacional

ABSTRACT

Business Games are today an important tool to support learning in some courses, being
adopted by several institutions. However, they present the following problems: they are
expensive, few, not satisfactorily specific and difficult to use and adapt. This work proposes
an architecture capable of allowing not only the application, but also the design of business
games, to be in charge of the teacher who uses them, because, although this approach requires
a greater interest and effort on the part of the same, this way business games customization is
made possible, adapting it to the needs of the teacher and others involved. As a result it is
expected that a lay teacher, through the definition of a game workflow of his own and the
configuration of pre-programmed modules, find in the proposed architecture the flexibility to
create his own games and therefore meet his needs.

Key words: business game – workflow – computational architecture

5

SUMÁRIO

1 INTRODUÇÃO ............................................................................................................................. 7
1.1 Contexto ............................................................................................................................. 8
1.2 Justificativa ........................................................................................................................ 8
1.3 Objetivo .............................................................................................................................. 8

2 TRABALHOS RELACIONADOS .............................................................................................. 9

3 FUNDAMENTAÇÃO TEÓRICA ............................................................................................. 11
3.1 Sobre Jogos de Empresas ............................................................................................... 11
3.1.1 O Professor e o Jogo de Empresas ................................................................................ 13
3.1.2 Aspectos de Aprendizagem ........................................................................................... 15
3.1.3 Aplicação do Jogo sob a Perspectiva do Professor ....................................................... 17
3.2 Do Processo de Negócio ao Jogo de Empresas .............................................................. 19
3.2.1 Processo de Negócio ..................................................................................................... 20
3.2.2 Classificação do BP quanto ao nível operacional.......................................................... 22
3.2.3 Gestão de Processo de Negócio..................................................................................... 24
3.2.4 Ciclo de Vida do Processo de Negócio ......................................................................... 26
3.2.5 Gestão de Workflow...................................................................................................... 29
3.2.6 Distinção entre BPM e Gestão de Workflow ................................................................ 33
3.2.7 Implicações na arquitetura proposta .............................................................................. 34
3.3 Teoria dos Jogos .............................................................................................................. 37
3.3.1 Histórico ........................................................................................................................ 38
3.3.2 Definição de jogos ......................................................................................................... 38
3.3.3 Tipos de jogos ............................................................................................................... 39

4 ARQUITETURA COMPUTACIONAL DE JOGOS DE EMPRESA ................................... 42
4.1 Definições de Arquitetura ............................................................................................... 42
4.2 Elementos Estruturais do Design de Jogos de Empresa .............................................. 43
4.3 Abordagens ao Design de Jogos de Empresa ................................................................ 45
4.4 GOG: Uma Arquitetura Computacional para Jogos de Empresa ............................. 48

5 ENGENHARIA DE SOFTWARE ............................................................................................. 51
5.1 Especificação e Requisitos do Projeto ........................................................................... 51

6

5.2 Atores................................................................................................................................ 52
5.3 Casos de Uso .................................................................................................................... 53
5.4 Arquitetura GOG ............................................................................................................ 54
5.5 Especificação dos Módulos do Workflow...................................................................... 56
5.6 Especificação da Estrutura Básica do Jogo .................................................................. 57
5.7 Especificação e Requisitos da Definição de Jogo .......................................................... 59
5.8 Linguagem de Definição de Jogo ................................................................................... 63
5.9 Implementação ................................................................................................................ 71
5.10 Testes ................................................................................................................................ 73

6 CONCLUSÕES ............................................................................................................... 76
6.1 Trabalhos Futuros ........................................................................................................... 76

REFERÊNCIAS .................................................................................................................................. 78

ANEXO A – UM JOGO DE EMPRESAS DO MUNDO REAL ..................................................... 82

7

1 INTRODUÇÃO

Com o avanço de recursos tecnológicos e as mudanças do mercado, cresceu a
necessidade de que a forma de ensino também mudasse, pois ficou evidente um
distanciamento entre a formação e a expectativa do mercado (ORTI; RODRIGUES;
ALBINO, 2008; LACRUZ, 2004). O modelo tradicional já não atende mais às necessidades
do mercado sendo a falta de prática provida na formação considerada um dos principais
problemas (LACRUZ, 2004), segundo Santos e Lovato (2007): “[...] muitos cursos de
administração enfatizam exageradamente o que deve ser em detrimento do que é, divorciando,
consequentemente, a teoria da prática, tendem a recomendar o ideal e ignorar as restrições,
pressões e limitações das situações reais (RAMOS, 1991)”. Assim, surgiram estudos que
propõe formas de melhorar o ensino, sendo os métodos vivenciais muito valorizados, para
Orti, Rodrigues e Albino (2008): “[...] jogos de empresa vêm obtendo maior destaque como
uma dessas metodologias e deve preparar os ‘jogadores’ para tornar suas empresas
competitivas em relação ao mercado, oferecendo situações similares às da realidade para o
treino da tomada de decisão e também deve ser pedagogicamente adequado, provendo o
interesse e o aprendizado”.
Entre os benefícios de um Jogo de Empresas podemos destacar: a aproximação entre
teoria e prática, a ampla aceitação e motivação dos alunos, o desenvolvimento de
competências e a melhora do aprendizado em geral, contudo, tal recurso tem se mostrado
caro, de difícil utilização pelos alunos e professores, havendo pouca variedade, inclusive de
cenários e situações onde características específicas de cada empresa e país acabam ignoradas.
Os professores têm dificuldade em adaptar jogos de empresas à grade curricular devido ao
tempo requerido e o escopo abordado (não é possível adaptá-los de modo a balancear
complexidade e tempo) (LACRUZ, 2004).
Neste trabalho é proposta uma arquitetura que permite a construção de diferentes jogos
através da concepção de um workflow e o uso de módulos configuráveis previamente
desenvolvidos, permitindo a criação de cenários e situações particulares, suficientemente
específicas e adaptadas à realidade que se quer retratar bem como a disponibilidade da grade
curricular. Cada módulo é desenvolvido através de uma linguagem de programação
específica, com interfaces segundo a definição da arquitetura proposta de modo a ser possível
a interoperabilidade entre módulos através do mecanismo de workflow.

8

1.1 Contexto

Jogos de Empresa ganharam espaço nas instituições de ensino superior graças aos
benefícios a eles associados como a aproximação entre teoria e prática, a ampla aceitação e
motivação dos alunos, o desenvolvimento de competências e a melhora do aprendizado em
geral. Contudo, atualmente, faltam Jogos de Empresa no mercado, sendo que estes têm um
alto custo de aquisição; são pouco específicos, ignorando características específicas de cada
empresa e país; e de difícil utilização pelos alunos e professores. Estes últimos, ainda, têm
dificuldade em adaptá-los à grade curricular devido ao tempo requerido e o escopo abordado.

1.2 Justificativa

Professores interessados em ter um maior controle sobre o jogo, ainda que ao custo de
um maior esforço pessoal, poderiam, se munidos de uma ferramenta que lhes permitisse tal
flexibilidade, configurar seus próprios jogos de modo que melhor se adaptem às suas
necessidades.

1.3 Objetivo

Propor uma arquitetura que confira flexibilidade a jogos de empresa, permitindo sua
maior adaptação e personalização por parte do professor através da definição de um fluxo de
jogo próprio e configuração dos módulos de jogo.

9

2 TRABALHOS RELACIONADOS

No intuito de encontrar uma solução que atenda às necessidades de todos os
envolvidos no desenvolvimento de um jogo empresarial, este projeto apresenta, a seguir, uma
relação de semelhantes trabalhos e pesquisas, tal como suas soluções obtidas.
Thavikulwat (2004) propõe uma arquitetura de simulações de jogos de negócios
computadorizados. De fato, esse trabalho não está relacionado diretamente à engenharia, mas
sua abordagem e a exposição da arquitetura apresentada permitem que este projeto analise,
avalie e desenvolva uma ferramenta que seja capaz de simular jogos de empresa. A proposta
de Thavikulwat (2004) considera a representação, a cronometragem, o hosting e a pontuação
dos simuladores de jogos de negócio. Deste modo, o tratamento que o trabalho dá à
arquitetura resulta em um modelo que é compreendido tanto por um especialista em negócios
quanto por um engenheiro de software.
O trabalho de Westphal e Lopes (2007) apresenta e analisa três abordagens ao design
de simuladores de jogos e destaca os quatro elementos principais de um simulador. O
procedimento metodológico da pesquisa de Westphal e Lopes (2007) consistiu no
levantamento das publicações já existentes sobre metodologias e abordagens ao design de
simuladores. Suas principais fontes foram os periódicos da ABSEL – Association for Business
Simulation and Experiental Learning e da Simulation & Gaming. Sendo possível abordar os
aspectos sociais, as interações existentes entre os envolvidos do jogo e as questões relativas ao
aprendizado, o estudo foi delimitado por apresentar os aspectos de desenvolvimento de
simuladores. Como resultado, os autores apresentam o conjunto de estudos, analisado e
sistematizado, dos principais aspectos para a construção de simuladores, que serve de
referência para os desenvolvedores e os estudiosos da área. O trabalho de Westphal e Lopes
(2007) colabora com a análise e a modelagem da solução deste projeto, uma vez que os
elementos estruturais de um simulador e os mais conhecidos métodos de identifica-los e trata-
los.
Pelaes (2009) desenvolve uma dissertação de mestrado focada no processo de
construção da estratégia de operações, centralizando os resultados na simulação de jogos
empresariais. Para alcançar esse objetivo, o trabalho realiza um levantamento bibliográfico
dos pontos-chave sobre o ensino da estratégia de operações e modela e avalia seu processo de
construção. Na fase de construção, Pelaes (2009) modela os processos por BPMN,
justificando essa escolha por sua interoperabilidade com outros sistemas, sobretudo baseados
em web, e desenvolve um aplicativo. Os resultados do trabalho expressam sua utilidade neste

10

projeto: três funcionários de distintas empresas avaliaram o aplicativo e o classificaram
positivamente em fatores de factibilidade, usabilidade e utilidade. Este último é composto,
sobretudo, pela avaliação da solução quanto à sua colaboração para o aprendizado de
estratégias de operações. Para este projeto, isto denota a vantagem da modelagem de
processos para a construção de jogos de aprendizado de negócios.
Por fim, Borrajo et. al (2010) apresentam o simulador SIMBA, uma ferramenta web
voltada à educação e à pesquisa em negócios. O trabalho descreve o simulador e seu modelo
lógico, arquitetura de software e principais funcionalidades. Embora focados na exposição das
características funcionais e pedagógicas do simulador, enfatizando a melhoria da função do
ensino por infraestruturas de Tecnologia da Informação (TI), Borrajo et. al (2010) apresentam
o simulador para três distintas finalidades: administração de negócios, educação de negócios e
pesquisa em inteligência artificial. Assim, esse trabalho provê um estudo inter-relacional
integrado de áreas que permitem que este projeto desenvolva uma solução para especialistas
em negócio e cientistas da computação.
Por apresentarem de modo geral as fases existentes na engenharia de jogos de
empresa, as pesquisas acima relacionadas envolvem-se diretamente com este projeto e
colaboram para a construção de uma solução computacional aceitável por professores, alunos
e engenheiros de software.

11

3 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo são apresentados os conceitos que fundamentam o presente trabalho,
permitindo a sua compreensão.

3.1 Sobre Jogos de Empresas

Trata-se de um método que pode ser denominado ainda como: jogos de negócios,
jogos gerenciais, simulação empresarial, simulação de gestão, gestão simulada e simulação
gerencial (BERNARD, 2006 apud SANTOS; LOVATO, 2007).
Para Orti, Rodrigues e Albino (2008) os jogos de empresas constituem de sistemas de
simulação empresarial informatizada, com a finalidade pedagógica do ensino e aprendizagem
sendo assim a confluência de áreas de conhecimento, tais como os conceitos e práticas de
gestão, os princípios pedagógicos de ensino e aprendizagem e a tecnologia da informação.
Lacruz (2004) em seu trabalho apresenta uma evolução da definição de jogos de
empresas citando diversos autores que, segundo ele “[...] coincidem no argumento de que
jogos de empresas são modelos dinâmicos de simulação que salientam as situações da área
empresarial, bem como o aspecto sequencial. [...] todas as definições apresentaram os jogos
de empresas como uma atividade fortemente vinculada à tomada de decisão”.
Lacruz (2004) afirma então que “[...] jogos de empresas representam uma técnica
educacional dinâmica desenvolvida para propiciar aos “jogadores” uma experiência de
aprendizado marcante e lúdica; servem, assim, como uma ponte entre a academia, a vivência
passada e o ambiente empresarial, a partir de uma representação da realidade (situações
específicas da área empresarial) por meio de abstrações matemáticas; utilizam-se de técnicas
de simulação (retratando condições de laboratório de uma determinada realidade, não sendo
somente uma simulação da empresa, mas do mercado) e possuem componentes dos jogos
(trazendo a interatividade e o exercício em equipe)”.
Apesar do recorrente entendimento de que Jogos de Empresas envolvem uma
simulação destacado tanto por Lacruz (2004) como por Orti, Rodrigues e Albino (2008)
anteriormente citados, existe um debate entre diferentes autores acerca da diferenciação do
conceito daquilo que seria uma simulação e daquilo que seria um jogo.
Para Ramos (1991) apud Santos e Lovato (2007): “A simulação é uma seletiva
representação da realidade, abrangendo apenas aqueles elementos da situação real que o autor
considera relevante para seu propósito. E, um modelo simulado reduz o tamanho da realidade

12

sendo representada, além de simplificá-la”. Seguindo a mesma linha de raciocínio, Santos e
Lovato (2007) diz que a simulação faz uso de modelos construídos que visam reproduzir
processos em ação, sendo que, a escolha dos aspectos da realidade a ser modelada depende
dos objetivos da simulação, cujo comportamento deve responder de modo semelhante àquele
do sistema real.
Jogo é um termo normalmente usado para simulação com a participação de pessoas
que tomam decisões sendo utilizado em situações nas quais há competição (GUETZKOW,
1962 apud SANTOS; LOVATO, 2007). Huizinga (1993) apud Orti, Rodrigues e Albino
(2008) vai além ao propor que no jogo cria-se uma realidade imaginária sob regras absolutas
que determinam aquilo que vale no mundo do jogo. De forma semelhante Gramigna (1993)
apud Orti, Rodrigues e Albino (2008) sugere que quando se entra num jogo aceitam-se as
regras e nos afastamos do mundo real exterior vivendo os aspectos lúdicos do jogo.
Para Gramigna (1993) apud Orti, Rodrigues e Albino (2008) se juntarmos os dois
conceitos, teremos então o jogo simulado onde os participantes enfrentam desafios de
tomadas de decisão que reproduzem situações reais.
Para Ramos (1991, p. 12, grifo do autor) apud Santos e Lovato (2007), “em essência, a
simulação [jogos de empresas] é uma estratégia de aprender a aprender, pois estimula o
aluno a desenvolver determinadas capacidades, capacidades estas que aumentarão sua
potencialidade de obter novos conhecimentos e adquirir novas habilidades”. Santos e Lovato
(2007) afirmam ainda que “esta técnica explora a faceta competitiva da personalidade do ser
humano, pela qual ele se sente estimulado a disputar com outras pessoas, e se utiliza de todas
as ferramentas possíveis para vencer o confronto”.
O Jogo de Empresas é, portanto, antes de qualquer coisa uma ferramenta de auxilio ao
aprendizado, que deve se aproximar tanto quanto possível da realidade (SANTOS; LOVATO,
2007), contudo, como percebido por Lacruz (2004): “As simulações do meio ambiente são
sempre mais simples que o mundo real, porque, além de o conhecimento sobre a realidade não
ser completo, é necessário manter o jogo relativamente fácil de ser processado e, também,
permitir que os participantes identifiquem as relações de causa e efeito que presidem o
modelo e vinculam os resultados às ações”. Portanto a aproximação da realidade de um Jogo
de Empresa esta limitada pelo seu objetivo: auxiliar no aprendizado, que necessita do
interesse ganho, por vezes, através de aspectos lúdicos de jogo como citado por Gramigna
(1993). Há um limite a partir do qual mais complexidade não traz benefícios, sendo
importante permitir aos participantes levantar perguntas e desenvolver insights (VICENTE,
2001 apud LACRUZ, 2004).

13

Segundo Tanabe (1977) apud Lacruz (2004) e Orti, Rodrigues e Albino (2008), os
jogos de empresas têm três objetivos básicos: Treinamento (desenvolver a habilidade de
tomada de decisão, através do exercício e experiências), Didático (transmitir conhecimentos e
técnicas específicos de um modo prático e experimental) e Pesquisa (encontrar soluções para
problemas empresariais valendo-se do realismo da simulação).
Sauaia (1989) apud Lacruz (2004) também ressalta três objetivos dos jogos de
empresas, porém tem seu foco nos benefícios trazidos aos jogadores, são eles: Aumento do
conhecimento (pela incorporação de novas informações trazidas ao contexto do jogo; pela
integração de conhecimentos que passam a fazer sentido; e por meio do resgate de
conhecimentos anteriormente adquiridos, cuja vivência facilita o acesso), Desenvolvimento de
habilidades (por meio da prática gerencial repetida) e Fixação de atitudes (através da
transposição da aprendizagem propiciada pelos acontecimentos fictícios, inseridos em um
cenário simulado, para o ambiente real).
Independente das diferenças nos parâmetros tomados para a classificação fica claro
que os jogos de empresas visam à melhora do aprendizado trazendo benefícios distintos aos
participantes graças ao seu caráter vivencial. Ainda acerca dos benefícios Vicente (2001) apud
Santos e Lovato (2007) diz que “[...] estas categorias de jogos [jogos de empresas em
específico] associam o prazer lúdico não só à capacidade de raciocínio analítico, mas também
à habilidade de tomada de decisão. Pessoas que têm por hábito jogar este tipo de jogo têm
menos dificuldade em fazer análises racionais e em tomar decisões. Em nossa sociedade estas
duas habilidades estão profundamente relacionadas”.
Para Harrel et al. (2002) apud Santos e Lovato (2007) “a habilidade de definir uma
idéia com um modelo, permite testar o impacto das sugestões e, então, o uso do modelo para
se vender a idéia aos tomadores de decisão pode incentivar a atitude do tipo: vamos
experimentar para ver”.
A necessidade do desenvolvimento dessas habilidades decorre da necessidade do
mercado, segundo Vicente (2001) apud Santos e Lovato (2007) “[...] as empresas precisam
muito mais de pessoas capacitadas a tomar decisões e a serem empreendedoras do que meros
operários incapazes de criar ou decidir por si mesmos”.

3.1.1 O Professor e o Jogo de Empresas

Segundo Sauaia (1995): “Pode-se observar que as escolas têm enfrentado dificuldades
em preparar administrador para a profissão, em estabelecer um nível de educação formal que

14

se possa considerar plenamente satisfatório, tanto do ponto de vista do recém-formado quanto
do ponto de vista das empresas que o acolhem”.
Para Santos e Lovato (2007), técnicas alternativas, como estudos de caso para ensino,
seminários, jogos de empresas etc, são exemplos de como complementar o ensino. Sauaia
(1995) apud Santos e Lovato (2007) afirma ainda que o jogo de empresas constitui um
método “muito bem aceito pelos educandos por combinar satisfação e aprendizagem,
representa um recurso valioso que, se bem explorado, pode contribuir grandemente para o
avanço da educação gerencial”.
Para Vicente (2001) apud Santos e Lovato (2007), “os jogos de empresas não são um
modismo, mas sim uma tendência secular que vem ganhando ímpeto em nossos dias pelo
maturamento de várias tecnologias”. No Brasil o Ministério da Educação (MEC), editou a
resolução de número CNE/CES nº. 1/2004 em 04/03/2004 que determina que o projeto
pedagógico deva fazer uma integração entre a teoria e a prática. Sendo assim o uso de jogos
de empresas atende a uma exigência do curso de administração (SANTOS; LOVATO, 2007).
Ainda assim há aqueles que resistem ao uso de Jogos de Empresas. Para Sauaia
(1995), os professores se classificam em dois grupos: “[...] em “vigorosos oponentes” ou em
“grandes partidários” das simulações, no que diz respeito à abordagem ao processo de
aprendizagem. Os oponentes não crêem que conceitos possam ser aprendidos em uma
simulação, pois, segundo eles, prevalecem os aspectos lúdicos relativos ao jogo. Já os
partidários estão convencidos de que as simulações criam um valioso ambiente no qual se
processa uma aprendizagem dinâmica e plena, com aplicação de conceitos e de técnicas”.
Gramigna (1993) apud Orti, Rodrigues e Albino (2008) identifica 10 mitos e
classifica-os como forças restritivas, que precisam ser desmistificadas:
1) "Se brinco não aprendo”;
2) "Jogos demandam muito tempo de planejamento";
3) "Tenho medo de os treinando não entrarem no jogo”;
4) "Não gosto de incentivar a competição, ela já é muito forte nas empresas";
5) "O jogo torna as pessoas agressivas";
6) "Com uma boa teoria, as pessoas aprendem mais”;
7) "No jogo, não tenho controle da aprendizagem";
8) “Fico inseguro por não possuir referencial teórico sobre jogos";
9) "Não tenho habilidade criativa, logo não posso usar jogos”;
10) "Adulto não gosta de atividades lúdicas".

15

Na visão de Sauaia (2006) apud Santos e Lovato (2007), os cursos de Ciências Sociais
(Administração de Empresas, Ciências Contábeis e Economia) incorporarão esta técnica já
conhecida e diante as suas vantagens aqueles professores que enxergam mais fatores que
dificultam o uso de jogos de empresas do que os motivam, provavelmente mudarão de idéia
no curto ou médio prazo. Santos e Lovato (2007) diz ainda que “Percebe-se uma tendência de
aumento no uso dos jogos de empresas em sala de aula, haja vista a familiaridade dos alunos e
professores com as tecnologias computacionais, cada vez mais modernas e de fácil
utilização”.

3.1.2 Aspectos de Aprendizagem

Já foi dito anteriormente que os Jogos de Empresas têm caráter vivencial, público alvo
adulto, entre outras características, para melhor compreender as implicações dessas
características Lacruz (2004) discute brevemente sobre a aprendizagem em si, segundo ele:
“[...] o tema foi discutido segundo diferentes abordagens e enfoques por diversos estudiosos, à
luz das análises de SANTOS (2003) e SAUAIA (1995) a aprendizagem será vista no contexto
da Andragogia, sob o enfoque da Abordagem Humanista, através de uma perspectiva da
Teoria da Gestalt, cujos princípios mais se aproximam dos presentes em jogos de empresas
[grifo nosso]”.
A Andragogia aborda a aprendizagem de adultos, como é o caso nos cursos de ensino
superior, na visão de KRISCHKE (2000) apud MARQUES FILHO (2001: 57) apud Lacruz
(2004): “A andragogia tem como características básicas: ser um processo de aprendizagem
de ação e participação, dando ênfase tanto no processo como no conteúdo; mais centrada na
aprendizagem do que no ensino; no treinando do que no facilitador; na atividade do que na
passividade; no clima de interesse e necessidade do treinando mais do que em provar o
conhecimento do formador; no contrato de aprendizagem; na apropriação do saber do que no
conhecer; na avaliação mais do que um instrumento de controle como um autodiagnóstico dos
hiatos das competências que se pretende alcançar [grifos do original]”.
Segundo Lacruz (2004) a Abordagem Humanista pode ser resumida partindo-se de
dois parâmetros: o aluno e o professor. O aluno é o foco do processo de ensino e
aprendizagem, visto como um ser ativo, criativo, participativo e que “aprendeu a aprender”. O
professor é o facilitador da aprendizagem, devendo fornecer condições para que os alunos
aprendam. Trata-se de uma abordagem que se contrapõe à idéia tradicional de ensino que têm
no professor o seu elemento fundamental (agente que transmite o conhecimento de forma

16

estruturada aos alunos passivos). Nos jogos de empresas o foco é transferido do professor para
os alunos.
A Teoria da Gestalt interpreta “[...] o pensamento como um processo reflexivo, dentro
do qual as pessoas desenvolvem insights novos ou os modificam através de uma nova
compreensão. O pensamento reflexivo combina tanto processos indutivos como dedutivos”
(SAUAIA, 1995). De acordo com BIGGE (1977), parafraseado por SAUAIA (1995), os
principais aspectos do pensamento reflexivo associados à teoria da gestalt são:
1. Reconhecimento e definição de um problema, ao tomarmos ciência de objetivos
conflitantes ou da presença de obstáculos ante os objetivos;
2. Formulação de hipóteses, ou seja, criação de asserções sob a forma de
generalizações, para que sejam verificadas pela experiência humana;
3. Elaboração das implicações lógicas das hipóteses, na forma de dedução das
implicações ou conseqüências de observações já feitas e de outras ainda por fazer;
4. Teste das hipóteses, envolvendo tentativas de verificar as implicações ou
conseqüências deduzidas;
5. Tirando conclusões, isto é, aceitando, modificando ou rejeitando as hipóteses,
admitindo-se a inexistência de evidências que garantam uma tomada de posição definitiva
[grifos do autor].
Lacruz (2004) conclui então que as “características encontradas na andragogia se
relacionam com a abordagem humanista, quando da adoção pelo professor de uma postura de
facilitador da aprendizagem, centrada no aluno, e com a teoria da gestalt, quando da
autogestão da aprendizagem pelo aluno, características idênticas às encontradas em jogos de
empresas”.
Sendo assim os jogos de empresas são uma abordagem de ensino que difere do modelo
tradicional na forma como se da o aprendizado. As características do modelo tradicional
sugerem uma concordância com teorias do condicionamento estímulo-resposta que
consideram a aprendizagem como um processo de mudança no comportamento, ocorrendo
através de estímulos e respostas que se relacionam e obedecem a princípios mecanicistas,
estando então em contraponto à teoria de campo-gestalt (ORTI; RODRIGUES; ALBINO,
2008). O modelo tradicional parece ainda concordar com a corrente comportamentalista
behaviorista, que vê o homem como um ser passivo cujo comportamento seria governado por
estímulos externos, em contraponto a abordagem humanista (LACRUZ, 2004).
Segundo Santos e Lovato (2007) “acredita-se que os jogos de empresas não devem
tomar o lugar de outros métodos educacionais, mas somar esforços e complementá-los para

17

suprirem as deficiências na educação tradicional”. A Tabela 1, que segue, destaca diferenças
entre o ensino tradicional e vivencial.

PARÂMETROS ENSINO
APRENDIZAGEM VIVENCIAL
EDUCACIONAIS TRADICIONAL
Orientação didática Ensino Aprendizagem
Personagem central Educador Educando
Conteúdos trabalhados Do educador Do educando
Envolvimento do educador Alto Baixo
Envolvimento do educando Baixo Alto
Atitude que orienta Quero ensinar Quero aprender
Técnica usual Expositiva Atividade em grupo
Cognitiva, afetiva, atitudinal e
Tipo de aprendizagem Cognitiva
comportamental
Áreas trabalhadas Cérebro Todo o indivíduo
Aplicação de conceitos Teórica Prática
Objetivos educacionais Gerais e coletivos Específicos e individualizados
Avaliados da aprendizagem Educador Educando
Andamento da aula Estímulo do educador Motivos do educando
Ambiente criado Competitivo Competitivo e cooperativo
Tabela 3.1 – Comparativo e parâmetros dos métodos educacionais: ensino tradicional x aprendizagem vivencial
Fonte: adaptado de Sauaia, 1995

3.1.3 Aplicação do Jogo sob a Perspectiva do Professor

Masetto (1992), citado por Orti, Rodrigues e Albino (2008), defende a existência de
nove princípios que explicitam o processo de aprendizagem do adulto, capazes de oferecer
condições facilitadoras de aprendizagem:
1. Promoção da participação num processo efetivo de interação, eliminando-se a
situação dicotômica onde o professor é o “dono” da verdade e ao aluno compete absorver o
que é transmitido, cada um sendo responsável por parte do processo, e a situação de conflito,
onde o professor é visto (se coloca) como um “obstáculo” a ser vencido, inexistindo, portanto,
o comportamento cooperativo;

18

2. Valorização da experiência e contribuição dos alunos, potencializando o
desenvolvimento da autoconfiança do aprendiz;
3. Explicitação do significado dos temas envolvidos, possibilitando que o aprendiz os
relacione com seu “universo”;
4. Definição clara e explícita de objetivos e metas a serem alcançados e organização
de um plano eficiente para consegui-lo, a partir do envolvimento e participação dos
aprendizes, de forma a relacioná-los da melhor maneira às necessidades e expectativas destes;
5. Estabelecimento de recursos eficientes, avaliáveis e adequados aos objetivos, os
quais se sujeitarão à avaliação realizada conjuntamente por alunos e professor, a fim de
verificar sua eficiência e possíveis alterações;
6. Criação de um sistema de feedback contínuo entre alunos e professor, que forneça
condições de corrigir ou redirecionar a rota no sentido dos objetivos propostos;
7. Desenvolvimento de uma reflexão crítica, apresentando interpretações alternativas
de valores, crenças, comportamento e ideologia culturalmente transmitidos, bem como do
trabalho, relações pessoais e perspectivas do mundo social e político;
8. Estabelecimento de diálogos permanentes entre professor e alunos, engajamento
mútuo e ação cooperativa (contrato psicológico), tendo em vista “equilibrar as necessidades
do aprendiz e as propostas do professor”;
9. Adaptação do comportamento do professor ao processo de aprendizagem próprio de
adultos: ao professor caberá, em resumo, preocupar-se com os interesses dos alunos,
admitindo seus autoconceitos e experiências passadas como material educacional, mostrando-
se confiante e aberto a diferentes pontos de vista e relacionando a teoria com a prática.
Estes princípios refletem o que seria uma postura de facilitador por parte do professor,
sendo esta a postura esperada na aplicação de Jogos de Empresas (ORTI; RODRIGUES;
ALBINO, 2008).
Lacruz (2004) com base em diversos autores, diz que a operacionalidade de um jogo
de empresas pode ser sintetizada em sete fases:
(1) Apresentação do cenário simulado: circunstância em que o animador esclarece os
jogadores sobre o ambiente em que o jogo está contextualizado;
(2) Esclarecimento das regras: refere-se à apresentação do que é permitido/proibido e
do ciclo do jogo; enfim, a todas as regras e a sistemática do jogo de empresas;
(3) Planejamento das equipes para as decisões a serem tomadas: nesta fase, as equipes
se reúnem por um período predeterminado para tomar as decisões concernentes ao jogo, com

19

base em suas vivências passadas, conhecimentos técnicos e relatórios gerados pelo próprio
jogo;
(4) Revelação das decisões tomadas pelas equipes ao animador: nesta ocasião, as
decisões tomadas por cada equipe de jogadores são reveladas exclusivamente ao animador;
(5) Processamento das decisões tomadas: as decisões são processadas por meio de
modelagens que reproduzam uma realidade possível do ambiente em que as empresas
dirigidas pelas equipes estão inseridas, e seu cálculo pode ser realizado pelo computador ou
pelo professor. Após o processamento das decisões, são gerados relatórios, que servem de
feedback sobre o mercado para as empresas e de parâmetro para as próximas decisões,
apontando em que condição cada empresa se encontra;
(*) Repetição das fases de (3) a (5) nas demais etapas definidas na fase (2);
(6) Definição da equipe vencedora: pelos critérios estabelecidos na fase (2) é
apresentada a equipe vencedora;
(7) Debriefing ou aftermath: momento de troca de experiências – em que jogadores e
animador reúnem-se para discutir suas impressões sobre o jogo de empresas, por que tomaram
esta ou aquela decisão – e de correção de distorções no entendimento surgidas por qualquer
razão.
Lacruz (2004) diz ainda que estas fases não são fechadas, sem pontos de interligação,
ou inflexíveis e lembra que Jogos de empresas não são fins em si mesmos.
Segundo Kallás (2004) apud Orti, Rodrigues e Albino (2008) “O administrador do
jogo procura através do diálogo e da análise, orientar as equipes no sentido de fazê-las
reconhecerem os instrumentos e técnicas da administração que as ajudariam em cada uma das
situações”.
Orti, Rodrigues e Albino (2008) reforçam a
“ênfase que inúmeros autores dão para que os jogos de empresa sejam feitos
de modo coletivo, ou seja, em equipe, pois além do enriquecimento na troca
de experiências é algo mais parecido com a realidade, onde as decisões são
normalmente interdepartamentais e interdependentes” (ORTI; RODRIGUES,
ALBINO, 2008).

3.2 Do Processo de Negócio ao Jogo de Empresas

A gestão de processos de negócio é uma disciplina que compreende uma série de
conceitos, métodos, técnicas, linguagens e notações. Sistemas de gestão de processos de

20

negócio são diferentes de jogos de empresa, porém ambos têm afinidade uma vez que
compartilham conceitos e exigem alguns conhecimentos similares para serem concebidos e
utilizados. Neste capítulo serão apresentados definições e conceitos da gestão de processos de
negócio pertinentes à compreensão e contextualização de parte daquilo que esta por trás dos
jogos de empresa, de sua concepção e da arquitetura proposta neste trabalho. Como o título do
capitulo sugere é adotada uma abordagem “da base ao topo”, começando com a introdução de
conceitos básicos necessários ao entendimento das conclusões que decorrem.
Ko (2009), referenciando diversos autores, destaca um problema que atinge
diretamente o propósito deste capítulo: a ausência de terminologias universais como um
problema comum a gestão de processos de negócio. Isso dificulta classificações, comparações
e o entendimento da relação dos conceitos apresentados com jogos de empresas, sendo,
portanto, também objetivo deste capítulo a clarificação de conceitos e adoção de uma
terminologia básica do campo de estudo para que fique mais clara à fronteira daquilo que se
aplica a este trabalho. Em geral serão adotadas, neste trabalho, as definições do livro de
Weske (2007), em cujo prólogo, o Prof dr.ir. Wil van der Aalst, reconhecido por Ko (2009)
como proeminente pesquisador da área, prove uma excelente introdução a gestão do processo
de negócio.

3.2.1 Processo de Negócio

Processo de negócio é a tradução feita neste trabalho para o termo inglês Business
Process e comumente abreviado como BP, também adotada nesse trabalho.
Em seu trabalho Ko (2009) explora diversas definições e suas facetas para o processo
de negócio e acaba por adotar a definição de Ould (1995), por ele citado, na qual os processos
de negócio são vistos como séries ou redes de atividades com valor agregado, realizadas pelas
funções ou colaboradores relevantes, para propositadamente atingir metas de negócio comuns.
Trata-se de uma definição próxima a de Weske (2007), adotada neste trabalho, para o qual um
processo de negócio consiste em um conjunto de atividades que são realizadas de forma
coordena em um ambiente técnico-organizacional atendendo a um objetivo do negócio.
Weske (2007) diz ainda que cada processo de negócio é promulgado por uma única
organização, sendo próprio a cada organização.
Segundo Ko (2009), processos de negócio são comumente encontrados dentro de
organizações empresariais e entre organizações existindo muitos tipos de processo de

21

negócio. Como exemplos de processo de negócio, ele destaca: ordens de compra, as
negociações de preço, gerenciamento de transporte, fusão e aquisição, entre outras.
Segundo Ballard et al. (2006), são elementos de um processo de negócio:
a) Entrada: representa o material e informações necessários para completar as
atividades do processo produzindo um resultado final específico;
b) Saída: representa os dados, informações e ativos físicos que o processo gera e,
portanto, valor para a organização contribuindo para a realização das medições de negócios e
objetivos. Pode representar também eventos, ações ou os resultados dessas ações;
c) Eventos: estes são notificações acerca de alguma ocorrência. Podem ocorrer antes,
durante ou depois da execução de um processo. Normalmente indicam o início, status
intermediário ou final de uma atividade do processo. Um evento pode ser uma ação resultante
da conclusão de outro processo (ou atividade do processo), da ocorrência de certa condição,
ou da chegada a um determinado ponto no tempo;
d) Subprocesso: trata-se de um processo ou etapa de processo, dentro de outro
processo. Um subprocesso é definido quando não é possível representar o escopo do trabalho
com apenas um conjunto de atividades. Um subprocesso tem os mesmos elementos de um
processo, trata-se de uma caracterização recursiva;
e) Atividade: é o mais baixo nível de trabalho em um processo;
f) Recurso: representa uma pessoa, organização, equipamento ou sistema utilizado
pelo trabalho no processo;
g) Métricas de desempenho: são atributos que servem para ajudar e orientar os
responsáveis pelo processo a fazer o controle e avaliação de eficiência e eficácia do mesmo.

Figura 3.1 – Elementos de um processo
Fonte: adaptado de Ballard et al., 2006, pag. 60

22

3.2.2 Classificação do BP quanto ao nível operacional

Quanto às possíveis classificações dos processos de negócio uma é particularmente
relevante a este trabalho: a classificação em níveis de operacionalidade (vai desde estratégias
comerciais de alto nível até o processo de negócio implementado).
Weske (2007) descreve os primeiros e mais elevados níveis, aos quais se refere como
organizacionais, da seguinte forma:
1. No mais alto nível, a estratégia da empresa é especificada, descrevendo seus
conceitos de longo prazo para desenvolver uma vantagem competitiva sustentável no
mercado.
2. No segundo nível, a estratégia de negócio é dividida em metas operacionais. Esses
objetivos podem ser organizados, de modo que cada meta pode ser dividida em um conjunto
de submetas.
3. No terceiro nível, se encontram os processos de negócio organizacionais. Processos
de negócio organizacionais são processos de alto nível que normalmente são especificados de
forma textual por suas entradas, saídas, os resultados esperados, e suas dependências em
outros processos de negócio organizacionais. Estes processos de negócio podem atuar como
processos fornecedores ou consumidores.
Segundo Weske (2007), técnicas informais e semiformais são usadas nestes níveis
elevados. A estratégia de uma empresa, seus objetivos, e seus processos de negócio
organizacionais podem ser descritos em textos enriquecidos com diagramas expressos em
uma notação adhoc (superficial) ou semiformal.
Weske (2007) explica então a relação entre processos organizacionais e operacionais
(terceiro e quarto níveis respectivamente), enquanto os processos de negócio organizacionais
caracterizam de grosso modo as funcionalidades do negócio, normalmente há vários
processos de negócio operacionais contribuindo com um processo de negócio organizacional.
Nos processos de negócio operacionais as atividades e seus relacionamentos são especificados
(através de modelos de processo de negócio), mas aspectos de implementação do processo de
negócio são desconsiderados.
Weske (2007) conclui sua caracterização dos níveis dizendo que os processos de
negócio operacionais são a base para o desenvolvimento de processos de negócio
implementados (ultimo nível). Processos de negócio implementados contêm informações
sobre a execução das atividades do processo e o ambiente técnico e organizacional em que

23

eles serão executados. Há várias maneiras de implementar processos de negócio, o ultimo
nível se refere a uma especificação que permite a promulgação do processo em uma
determinada plataforma, seja ela organizacional ou técnica.

Figura 3.2 – Níveis dos processos de negocio.
Fonte: adaptado de Weske, 2007, pag. 18

A Figura 3 adiante, no subcapitulo intitulado “Gestão de Processo de Negócio”, é
apresentado um exemplo onde os BPs são definidos em nível operacional. Weske (2007)
apresenta exemplos para os níveis organizacionais dentro de um mesmo contexto, através
deles podemos entender melhor as 3 primeiras fases:

24

1. Estratégia de negócio: Um exemplo seria buscar a liderança de custo para os
produtos em um determinado domínio. Segundo Stahl e Grigsby (1997) isso significa buscar
o menor custo de operação num domínio da indústria, o que não significa necessariamente
oferecer produtos ou serviços a um menor preço.
2. Meta: Reduzir os gastos com materiais fornecidos é um exemplo de meta que leva a
liderança de custo.
3. Processo de negócio organizacional: um processo de negócio para gerenciar entrada
de matérias-primas fornecidas por um conjunto de fornecedores seria um exemplo de
iniciativa para reduzir os gastos com materiais fornecidos.

3.2.3 Gestão de Processo de Negócio

Gestão de Processo de Negócio é a tradução feita nesse trabalho para o termo em
inglês Business Process Management, comumente abreviado como BPM, abreviação esta
adotada nesse trabalho.
Segundo Ko (2009) a tecnologia da informação foi aproveitada para gerenciar
processos de negócio, formulários anteriormente preenchidos manualmente foram
crescentemente substituídos por suas contrapartes eletrônicas, o que resultou na origem da
Gestão de Processos de Negócio.
Segundo Weske (2007) a gestão de processos de negócio inclui conceitos, métodos e
técnicas para apoiar a concepção, administração, configuração, promulgação e análise de
processos de negócio. Para Weske (2007) a base da gestão de processos de negócio é a
representação explícita dos processos de negócio com suas atividades e as restrições de
execução entre elas.
Algumas definições adaptadas de Weske (2007) necessárias a compreensão prática da
gestão do processo de negócio:
a) Sistema de gestão de processos de negócio (do inglês Business Process
Management System, abreviado BPMS): é um sistema de software genérico impulsionado
pela representação explícita dos processos com objetivo de coordenar a promulgação dos
processos de negócio.
b) Modelo de processo de negócio: consiste em um conjunto de modelos de atividade
e as restrições de execução entre eles. Cada modelo de processo de negócios funciona como
um blueprint (um detalhado plano de ação) para um conjunto de instâncias de processos de
negócio.

25

c) Instância do processo de negócio: representa um caso concreto no negócio
operacional de uma empresa, composto de instâncias de atividade. Cada modelo de atividade
funciona como um blueprint para um conjunto de instâncias de atividade.
d) Orquestração de processo: refere-se ao controle centralizado dos processos de
negócio de uma empresa por um sistema de gestão de processos de negócio de modo análogo
a um maestro que centralmente controla os músicos de uma orquestra. Isso é possível uma vez
que os processos de negócio são realizados em uma única organização, sendo próprios desta
conforme definido anteriormente.
e) Coreografia de processos: compreende a especificação das interações de um
conjunto de processos de negócio. O termo coreografia indica a ausência de um agente central
que controla as atividades nos processos de negócio envolvidos. A interação só é alcançada
através do envio e recebimento de mensagens. A fim de realizar interações de forma correta,
os processos de negócio que interagem precisam concordar sobre uma coreografia comum
antes de começar a interagir.
Na figura 3.3 estão representados dois processos de negócio (Comprador e
Revendedor), o fluxo de ação por eles compreendido e a troca de mensagens feita entre os
dois de modo a formar uma coreografia. Neste exemplo foi usada a notação BPMN que será
discutida mais a frente.

Figura 3.3 – Processos de negócio interagindo e formando uma coreografia de processos

26

3.2.4 Ciclo de Vida do Processo de Negócio

O ciclo de vida do BP, segundo Weske (2007), consiste, resumidamente, em:
1. Design e Análise: nesta etapa, processos de negócio são identificados, analisados,
validados e representados por modelos de processo de negócio.
2. Configuração: nesta etapa o processo de negócio deve ser implementado. Em geral
o sistema de gestão de processos de negócio precisa ser configurado de acordo com o
ambiente organizacional da empresa e os processos de negócio, cuja promulgação ele deve
controlar. Esta configuração inclui as interações dos funcionários com o sistema, bem como a
integração dos sistemas de software existente com o sistema de gestão de processo de
negócio.
3. Promulgação: nesta etapa instâncias de processos de negócio são promulgadas.
Esta etapa engloba a execução em tempo real do processo de negócio. O BPMS controla
ativamente a execução de instâncias de processos de negócio, tal como definido no modelo de
processo de negócio. A promulgação do processo precisa atender a uma correta orquestração
dos processos, garantindo que as atividades do processo são realizadas de acordo com as
restrições de execução especificadas no modelo de processo.
4. Diagnóstico: a fase de avaliação utiliza as informações disponíveis para avaliar e
melhorar os modelos de processos de negócio e suas implementações. Logs de execução são
avaliados por meio do monitoramento de atividades de negócio e técnicas de mineração de
processo. Estas técnicas visam identificar a qualidade dos modelos de processo de negócio e a
adequação do ambiente de execução.
5. Administração e Envolvidos: O domínio de processos de negócio é caracterizado
por ter vários tipos de profissionais envolvidos, com diferentes saberes, conhecimentos e
experiência. Estes diferentes tipos de profissionais devem cooperar estreitamente na
elaboração de processos de negócio e no desenvolvimento de soluções adequadas para
promulgá-los.

27

Figura 3.4 – Ciclo de vida do processo de negócio

Ko (2009) propõe em seu trabalho um processo de seis passos intitulado como
processo de modelagem de processos de negocio, que segundo ele próprio tem estreita relação
com o ciclo de vida do processo de negocio. Os seis passos por ele propostos:
Passo 1 — Necessidades do Negócio: Envolve a identificação de uma necessidade e
definição de uma meta de negócio em alto nível (equivalente ao segundo nível operacional da
Figura 2).
Passo 2 — Definições de Meta de Negócio: Envolve o levantamento de requisitos e
concepção de uma visão de alto nível das etapas do processo em questão (equivalente ao
terceiro nível operacional da Figura 2).
Passo 3 — Detalhes dos Diagramas de Processo de Negócio: Envolve a modelagem de
processos de negócio em um padrão gráfica facilmente interpretável e formal (e.g., BPMN).
Passo 4 — Traduzir Diagramas para Código Executável: Usa-se uma ferramenta que
suporta padrões de intercâmbio (e.g., XPDL) para traduzir automaticamente o modelo gráfico
de processo de negócio no código executável (e.g., BPEL).

28

Passo 5 — Código de Execução: o código será verificado e os ajustes necessários
serão feitos. Após testes e aprovação, o processo de negocio será publicado no BPMS.
Passo 6 — Processos de Negócio Executáveis: O BPMS contém um componente
chamado de motor, trata-se de um software que gerencia o encaminhamento e execução
adequados de todas as instâncias de BP para as fases e pessoas corretas. O BP esta enfim em
vigor.
É importante notar que Ko (2009) enxerga o ciclo de vida do BP de forma menos
abrangente do que Weske (2007), sendo os passos 1 e 2 do processo em questão
compreendidos na etapa de Design e Análise do ciclo de Weske (2007). O nome processo de
modelagem de processos de negocio é infeliz, não apenas pela desagradável repetição da
palavra processo, mas também por haver muito mais do que modelagem envolvido neste
processo, parece que Ko (2009) pensa num caso particular do ciclo de vida no qual haveria
apenas a implementação desprovida de um esforço de melhoramento continuo dos processos,
quebrando a idéia de ciclo. A despeito daquilo que Ko (2009) pudesse ter em mente ao definir
o tal processo de modelagem de processos de negocio, este não apenas ajuda a entender
melhor o ciclo de vida do BP, mas serve também para junto a este pensar no processo de
desenvolvimento de um jogo de empresas dada a arquitetura proposta, o que será feito
adiante.
Ko (2009) observa que há lacunas entre a teoria, os padrões e os sistemas BPM. A
figura abaixo indica que a definição de padrões e normas se baseia na teoria da gestão de
processos de negócio sendo por sua vez adotadas em sistemas e software. Ko (2009) diz ainda
que a heterogeneidade de técnicas de modelagem de processos de negócio constitui um
problema notório para a área da gestão de processos de negócio sendo estas técnicas distintas
quanto às áreas de aplicabilidade (sugere BPM, SOA e B2B), uso e reconhecimento (de jure e
de facto), por exemplo.

29

Figura 3.5 – A relação entre teoria, padrões e sistemas BPM.
Fonte: adaptado de Ko, 2009, p. 16

3.2.5 Gestão de Workflow

Workflow é um termo inglês que pode ser traduzido como fluxo de trabalho. Segundo
Weske (2007), uma conquista importante da gestão de workflow é a representação explícita
de estruturas de processo em modelos de processo bem como a promulgação controlada de
processos de negócio de acordo com estes modelos. Diz ainda que esta abordagem, dirigida a
modelos, possibilita um alto grau de flexibilidade, porque os modelos de processo podem ser
adaptados para cumprir novas exigências e ser imediatamente usados para promulgar
processos de negócio.
O Workflow Management Coalition define workflow e sistemas de gestão de
workflow da seguinte forma:
1. Workflow é a automação de um processo de negócio, no todo ou em parte, durante
o qual documentos, informações ou tarefas são passadas de um participante ao outro para
tomada de ação, de acordo com um conjunto de regras processuais.
2. Um sistema de gerenciamento de workflow é um sistema de software que define,
cria e gerencia a execução de workflows através do uso de software, rodando em um ou mais
motores de workflow, que são capazes de interpretar a definição do processo, interagir com os

30

participantes do workflow e, quando necessário, invocar o uso de ferramentas de TI e
aplicações.
Quanto a sua aplicação Weske (2007) diz que a tecnologia de workflow é capaz de
suportar processos de negócio dentro de um dado sistema de aplicativo ou entre um conjunto
de sistemas aplicativos, de forma a integrar eficazmente estes sistemas. Mas a tecnologia de
workflow também pode ser utilizada para promulgar processos de negócio em que humanos
estão ativamente envolvidos, melhorando assim a colaboração entre os trabalhadores.
Segundo Weske (2007) tradicionalmente a lógica do processo é definida no código da
aplicação, o que dificulta alterações na nesta, porém a tecnologia de gestão de workflow pode
ser usada para facilitar a modificação da lógica do processo realizado por aplicativos. As
funções de um sistema de aplicação são as etapas do workflow, e um componente de
workflow utiliza um modelo de workflow para promulgar as funções. Pela modificação da
lógica de processo especificada em modelos de workflow, o comportamento do sistema de
aplicação pode ser modificado sem codificação.
Segundo Weske (2007), a maioria dos sistemas de aplicação empresariais, tais como
sistemas de planejamento de recursos empresariais (ERP – Enterprise Resource Planning),
hospedam um componente de workflow que facilita a personalização flexível de processos de
negócio dentro destes sistemas. Observe que, em vez do termo sistema de gerenciamento de
workflow, o termo componente de workflow é usado, porque um componente de workflow
não é um sistema de software stand-alone, mas sim, incorporado na aplicação.
Na definição de Weske (2007) um workflow de única aplicação consiste em atividades
e sua ordenação causal e temporal que são realizadas por um sistema de aplicação comum.
Workflows de múltiplas aplicações contêm atividades que são realizadas por múltiplos
sistemas de aplicação, proporcionando uma integração destes sistemas.

31

Figura 3.6 – Arquitetura de sistemas de workflow de única aplicação.

Weske (2007) explica que na arquitetura de um sistema de workflow de um único
aplicativo, mostrada na Figura 6, há um componente de workflow dedicado que é alimentado
com modelos de workflow que captam a lógica do processo, bem como informação sobre a
execução técnica. O componente de workflow usa funções realizadas pelo aplicativo e fornece
processos para o nível superior, a interface gráfica do usuário. Já no caso de um workflow de
múltiplas aplicações, um sistema de gestão de workflow dedicado garante que os sistemas de
aplicação sejam invocados conforme especificado no modelo de processo. Além disso, a
transferência de dados entre os sistemas de aplicação também é cuidado pelo sistema de
gestão de workflow.

32

Figura 3.7 – Arquitetura de sistemas de workflow de múltiplas aplicações.

Weske (2007) distingue workflows em duas outras categorias: os de sistema e os de
interação humana.
Segundo Weske (2007) em workflows de sistema, as atividades de workflow são
executadas automaticamente por sistemas de software, não havendo, portanto, interação entre
trabalhadores e a aplicação. Em sua definição um workflow de sistema consiste em atividades
que são executadas por sistemas de software, sem qualquer envolvimento do usuário.
Segundo Weske (2007), workflows de interação humana tipicamente compreendem
partes de um processo de negócio maior, que tem partes automatizadas e não automatizadas.
O objetivo dos workflows de interação humana é apoiar eficazmente as partes automatizadas
dos processos de negócio controlando ativamente as atividades realizadas de acordo com
modelos de processo. Ele define os workflows interação humana como workflows nos quais
os humanos estão ativamente envolvidos e interagem com os sistemas de informação.
Ainda acerca dos workflows de interação humana, Weske (2007) diz que estes
requerem conceitos de interface gráfica particulares. O principal conceito é a lista de itens de
trabalho. Trabalhadores interagem com o sistema usando listas de itens de trabalho, sempre
que um trabalhador puder realizar uma atividade do processo, ele ou ela é informado por um
item na sua lista de itens de trabalho. Quando o item é selecionado, o respectivo aplicativo é
iniciado, e os dados de entrada são fornecidos. Quando a atividade for concluída, o

33

trabalhador informa a aplicação de workflow. O sistema de gestão de workflow em seguida,
computa o estado atual e determina as próximas atividades.

3.2.6 Distinção entre BPM e Gestão de Workflow

Em seu trabalho, Ko (2009) aponta que há dois pontos de vista pelo qual é possível
fazer a distinção entre BPM e a Gestão de Workflow. Um ponto de vista é do Gartner
Research, segundo o qual Business Process Management (BPM) é uma disciplina de gestão
orientada a processos e não é uma tecnologia, e workflow é uma tecnologia de gerenciamento
de fluxo encontrada em sistemas de gestão de processos de negócio (BPMS) e outras
categorias de produtos. A tabela abaixo mostra outro ponto de vista, por van der Aalst et al.
(2003), segundo o qual as funcionalidades da gestão de workflow são um subconjunto
daquelas do BPM sendo a fase de diagnóstico do ciclo de vida do BPM a principal diferença.

Figura 3.8 – Utilização do ciclo de vida do BPM para comparar a gestão de workflow com a gestão de
processos de negócios por Van der Aalst et al. (2003).
Fonte: adaptado de Ko, 2009, pag. 15

GESTÃO DE
ESTÁGIO DO CICLO GESTÃO DE
PROCESSO DE
DE VIDA BPM WORKFLOW
NEGÓCIO

Design Sim Sim

Configuração Sim Sim

Promulgação Sim Sim

Diagnostico Fraco Sim

Tabela 3.2: Gestão de Workflow e BPM comparados.
Fonte: adaptado de Ko, 2009, pag. 15

34

Os pontos de vista não se anulam e nenhum deles destoa daquilo que é apresentado
por Weske (2007) em seu livro. A única ressalva é de que um workflow não necessariamente
é uma tecnologia como apresentado pela Gartner. Vale lembrar também que os ciclos de vida
levam em conta a implementação da teoria, sendo ambos, workflow e BPM, implementáveis.
Na figura abaixo Weske (2007) representa através de UML as relações entre conceitos
de modelagem de processo de negócio citados nesse trabalho. É interessante destacar que para
Weske (2007) o workflow não é uma subclasse do BP uma vez que concretiza uma parte do
BP, sendo assim, o workflow não possui uma relação “é-um” com o BP, mas sim uma
associação.

Figura 3.9 – Processo de Negócio: modelo conceitual.
Fonte: adaptado de Weske, 2007.

3.2.7 Implicações na arquitetura proposta

No trabalho de Roudaky e Doroodchi (2009), cujo objetivo é tornar o processo por trás
dos jogos de computador visível e simples de compreender, é proposto o uso do workflow
para mapear a interação entre o usuário e o jogo, no caso uma interação analógica com o
controle (usuário pressiona botões para manifestar suas escolhas) resulta numa resposta
pseudo-analógica equivalente no mundo virtual do jogo. É possível abstrair esse uso do
workflow para a interação em jogos de empresas, que se da pelo passar das rodadas de jogo

35

em resposta ao envio das escolhas feitas pelos alunos.
Segundo Roudaky e Doroodchi (2009) jogos de computador também podem ser
considerados como processos e, conseqüentemente, podem ser modelados usando workflow.
Shubik (2002) diz que um jogo é definido por suas regras formais e informais. As regras
formais são explicitadas, enquanto as informais estão contidas no contexto dos arredores e
situações nas quais o jogo é jogado. Para Shubik (2002), juntas, as regras provêm os
portadores do processo. Jogos de empresas, assim como qualquer jogo, também seguem
regras e podem ser considerados como processos, portanto, também podem ser modelados
através de um workflow.
A sequência de passos de desenvolvimento para jogos de computador proposto por
Roudaky e Doroodchi (2009):
1. Definir os objetivos do jogo, principais objetos e cenários;
2. Realizar a análise de workflow sobre os cenários, e criar o diagrama de workflow
do jogo;
3. Criar os objetos na cena;
4. Desenvolver o código usando o diagrama de workflow;
5. Testar o software.
Neste trabalho, assim como no trabalho de Roudaky e Doroodchi (2009), não é o
objetivo discutir aspectos dos jogos de computador como objetos e cenários, bastando à
compreensão dos passos de desenvolvimento de um modo geral. Abaixo estão os passos para
se fazer a análise de workflow segundo o próprio Roudaky e Doroodchi (2009), esclarecendo
o passo 2 do desenvolvimento que pode ser aplicado pelo professor ao conceber o jogo de
empresas (que seguirá um workflow por ele definido):
a) Primeiro pensamos no jogo como um grande processo com uma atividade, sendo
depois dividido em mais atividades.
b) Para expandir uma atividade, partimos dos pontos de entrada. Um ponto de entrada é o
evento que ativa ou desencadeia um processo. Na maioria dos casos, os pontos de
entrada são os resultados de interações do usuário com o jogo.
c) Depois de identificados os pontos de entrada, todas as atividades que vão ser
executadas devem ser listadas e esboçadas em um diagrama de workflow.
d) Para cada cenário, o modelo de workflow é formado.
e) Mais tarde, esses workflows individuais são combinados com base em suas interações
e mecanismos de sincronização. Em outras palavras, o workflow do jogo global será
formado por esses workflows individuais.

36

Como dito anteriormente, um BPM pretende apoiar a concepção, administração,
configuração, promulgação e análise dos processos de negócio, sendo este abrangente
objetivo alcançado através das etapas compreendidas no ciclo de vida do processo de negócio.
A arquitetura proposta neste trabalho para a criação de jogos de empresa personalizados
sugere um processo de desenvolvimento próximo a esse, uma vez que tem um objetivo
similar, conforme definição no capítulo 1.3.
Considerando o ciclo de vida do processo de negocio de Weske (2007), o processo de
modelagem de processos de negocio de Ko (2009) e os passos de desenvolvimento de jogos
de Roudaky e Doroodchi (2009), é proposto aqui o seguinte processo para o desenvolvimento
de jogos de empresas:
1. Design: nesta etapa o professor deve definir como será o jogo de empresas, qual
será o fluxo do jogo e como serão as fases do mesmo. Essa etapa pode ser feita em papel, ela
envolve a criação do jogo em si. O professor tem diversos aspectos a levar em conta nesta
etapa, mas vale lembrar que decisões de nível organizacional (estratégia, metas e processos
organizacionais), devem ser pensadas e cobradas dos jogadores nas rodadas de jogo. Portanto
a relação entre BPM e nossa arquitetura se da também quanto ao conteúdo do jogo. Contudo,
os níveis abaixo dos organizacionais fogem ao propósito didático dos cursos de administração
e nossa arquitetura não permite o trabalho sobre tais processos. Sendo assim, a avaliação das
empresas dos alunos no jogo não contempla a gestão dos processos de negócio, apesar deste
ser um fator competitivo importante.
2. Configuração: nossa arquitetura propõe a existência de uma interface que permita a
modelagem de um diagrama que define o workflow de jogo, bem como a configuração dos
módulos pré-programados. Nesta etapa, o professor deve, então, transcrever aquilo que tem
em mente para o software de apoio ao desenvolvimento de jogos personalizados. É possível
que a arquitetura não atenda as necessidades do professor em situações onde este quer algo
mais sofisticado ou personalizado, nesse caso ele pode contratar profissionais de computação
para mexer no código.
3. Promulgação: Com o código automaticamente gerado, e possivelmente
personalizado, em mãos, o professor precisa aplicá-lo aos seus alunos. Nossa arquitetura
propõe que haja uma interface de administração através da qual o professor pode controlar a
aplicação do jogo, tanto quanto a sua disponibilidade como quanto a outros aspectos de jogo
(ex: alterações no cenário do mercado do jogo em uma dada fase). Os alunos têm acesso ao
jogo via web.

37

4. Análise: O processo pode se tornar cíclico se for adicionada esta etapa ao processo,
pois essa etapa remete a etapa de design ao fornecer feedback que pode ser refletido em
alterações do jogo. Contudo essa etapa não será explorada nesse trabalho, ficando a ideia
disponível para trabalhos futuros. Vale lembrar que ao final do jogo é feita uma avaliação dos
alunos, trata-se de mais uma fase do jogo, nada tem haver com essa etapa onde são
apresentados parâmetros quanto ao desenrolar do jogo em geral.
Sendo assim a arquitetura proposta permite ao professor a concepção,
desenvolvimento e aplicação de seus próprios jogos de empresas, fornecendo a ele um recurso
que permite uma fácil tradução da ideia em código, bem como a utilização do código em
forma de jogo.
A gestão de workflow tem papel fundamental na arquitetura proposta neste trabalho,
pela mesma razão que ela tem no BPM: possibilita um alto grau de flexibilidade uma vez que
o comportamento da aplicação pode ser modificado sem codificação por parte do professor.
Na arquitetura proposta deve haver um componente de workflow de única aplicação,
gerado a partir dos dados fornecidos pelo professor na etapa de configuração, trata-se de um
objeto Java que determina qual módulo estará ativo, ele o faz chamando outros componentes
Java. O workflow proposto é de interação humana e, portanto, conceitos de interface gráfica
particulares, como a lista de itens se aplicam, contudo neste trabalho será abordada apenas a
lista de itens na forma de cobranças feitas pelo professor a cada rodada.
Na arquitetura proposta os conceitos de orquestração e coreografia não se aplicam, o
primeiro porque não há vários processos a serem coordenados, trata-se de um único grande
processo, o segundo porque não há interação desse processo com outros processos.

3.3 Teoria dos Jogos

A teoria dos jogos é uma teoria matemática que modela fenômenos que podem ser
observados quando dois ou mais agentes de decisão interagem entre si (SARTINI, 2004).
Embora sua consolidação só se tenha dado no século XX, existem registros históricos
da utilização dessa ferramenta pelo menos dois séculos antes. Nos últimos 100 anos, os
principais pesquisadores e estudiosos fundamentaram sua estrutura e confirmaram
matematicamente as proposições teóricas (SARTINI et. al, 2004).
Atualmente esta teoria é utilizada por outras áreas de estudo, como política, biologia e
economia. Esta, sobretudo, tem utilizado a teoria dos jogos em fenômenos que envolvem

38

decisões como é o caso dos leilões, das eleições e das barganhas (SARTINI et. al, 2004;
COSTA, 2004).
Este capítulo permite uma melhor compreensão da constituição dos jogos de empresas
ao fundamentar a teoria dos jogos nele empregada.

3.3.1 Histórico

A primeira demonstração formal que deu origem à teoria dos jogos apareceu em 1913
com a publicação do modelo matemático do alemão Ernst Zermelo. Nele, o matemático
alemão provava que o jogo de xadrez era estritamente determinado, ou seja, em cada jogada,
o jogador possui uma estratégia para vencer ou empatar com o adversário (SARTINI et. al,
2004).
Em 1928, o matemático John Von Neumann demonstrou que todo jogo finito de soma
zero com duas pessoas possui uma solução em estratégias mistas. Em 1937, fez a mesma
demonstração, mas utilizando-se do teorema do ponto fixo de Brouwer, e em conjunto com o
economista Oskar Morgenstein (SARTINI et. al., 2004). Em 1944, publicam em parceria The
Theory of Games and Economic Behaviour, obra acerca dos fundamentos da Teoria dos
Jogos, enfocando os jogos de estratégia, que não dependem apenas da sorte, mas
principalmente das escolhas feitas pelos jogadores (COSTA, 2004).
Logo após a Segunda Guerra Mundial, em 1950, o matemático americano John Forbes
Nash Jr. publicou quatro artigos essenciais para a teoria dos jogos. Neles, descrevia suas
teorias sobre jogos cooperativos e não-cooperativos e barganha (SARTINI et. al, 2004). Em
1994, Nash foi laureado com o prêmio Nobel de Economia por suas contribuições à teoria dos
jogos cultivada às ciências econômicas.
Já consolidada na matemática aplicada, a teoria dos jogos expandiu-se para outras
áreas, como a política e a biologia, a partir dos anos 70. As ciências que a utilizavam viam-na
como um promissor método de analisar situações estratégicas. Uma década antes, ainda,
Thomas Schelling se destaca por romper o isolamento da teoria dos jogos à matemática,
aplicando-a nas ciências sociais (CARMICHAEL, 2005).

3.3.2 Definição de jogos

Sartini et. al. (2004) definem formalmente a teoria dos jogos como “a teoria dos
modelos matemáticos que estuda a escolha de decisões ótimas sob condições de conflito”.

39

Segundo o Dicionário Aurélio (2006), o jogo é “uma atividade física ou mental
fundamentada em sistema de regras que definem a perda ou o ganho”. Com esta definição,
Costa (2004) vê em Von Neumann a utilização desse sentido sob a ótica da economia.
Segundo a autora, jogos são situações de interesse competitivo onde cada jogador visa
maximizar seus ganhos.
Basicamente, um jogo é composto por dois ou mais jogadores (COSTA, 2004), que
são os participantes do jogo (CARMICHAEL, 2005). Cada um deles possui um conjunto de
estratégias e cada estratégia escolhida pelo jogador é definida como uma situação no espaço
de todas as situações possíveis (SARTINI et. al, 2004).
Um jogo pode ser definido como um conjunto finito de jogadores ,

sendo que cada possui um conjunto finito de estratégias .
Sendo , para cada estratégia escolhida do jogador tem-se um vetor

denominado situação, que indica qual é o perfil de estratégia pura
elegido. Ainda, cada jogador possui uma função utilidade que associa o ganho, ou
payoff, a cada situação , onde é espaço de situações, formado pelo produto
cartesiano de todas elas (OLIVEIRA; ARAÚJO; CÂMARA, 2010; SARTINI et. al., 2004):

3.3.3 Tipos de jogos

As referências (CARMICHAEL, 2005; SARTINI et. al., 2004; GIBBONS, 1992;
COSTA, 2004) sobre teoria dos jogos mostram que os diversos jogos existentes podem ser
classificados de várias formas. Sobre essas classificações, este trabalho apresentará apenas
algumas, a fim de que os principais conceitos sobre a teoria possam ser compreendidos
objetivando a leitura e os resultados da presente pesquisa.
Carmichael (2005) diz que os jogos são, muitas vezes, classificados pela forma como
os jogadores se movem. Como por esta razão a autora escolheu classificar os jogos de
estratégia conforme a movimentação, é possível qualificar o jogo como sendo de
movimentação simultânea ou movimentação sequencial. Embora com nomes distintos, outros
autores como Felegyhazi e Hubaux (2006) e Gibbons (1992) também realizam a distinção
entre jogos de acordo com este critério.

40

Jogos de movimento simultâneo são aqueles em que os jogadores movem-se ao
mesmo tempo ou em que seus movimentos não são vistos pelos demais jogadores. Neste caso,
os jogadores estabelecem suas estratégias com base no que pensam que os outros jogadores
poderão fazer (CARMICHAEL, 2005). Comumente esse tipo de jogo é analisado através da
matriz de payoff’s (Figura 1). Nela, é apresentada a avaliação dos resultados obtidos (payoff)
dos jogadores para cada possível situação de ganho e de perda, respectivamente.

Figura 3.10 – Matriz de payoff’s representando o clássico dilema do prisioneiro.
Fonte: Autores “adaptado de” Sartini et. al., 2004, p. 7

Sartini et. al. (2004) exemplifica o dilema do prisioneiro, expresso na matriz de
payoff’s da Figura 3.10, da seguinte forma: “dois ladrões, Al e Bob, são capturados e
acusados de um mesmo crime. Presos em selas separadas e sem poderem se comunicar entre
si, o delegado de plantão faz seguinte proposta: cada um pode escolher entre confessar ou
negar o crime. Se nenhum deles confessar, ambos serão submetidos a uma pena de 1 ano. Se
os dois confessarem, então ambos terão pena de 5 anos. Mas se um confessar e o outro negar,
então o que confessou será libertado e o outro será condenado a 10 anos de prisão”. Esse jogo
esclarece as implicações de um jogo de movimento simultâneo, a estratégia que melhor
defende os interesses próprios de cada prisioneiro é confessar, contudo uma vez que ambos
confessem defendendo seus interesses próprios, ambos enfrentarão uma pena maior do que se
ambos tivessem negado, trata-se de uma situação paradoxal gerada pela desconfiança no
próximo, que, a princípio, pensa apenas em si próprio e não hesitaria em confessar se
soubesse que o outro vai negar ainda que seja esta postura o que impossibilita ambos os
prisioneiros de pegar uma pena menor, que é o objetivo de ambos.
Já jogos de movimento sequencial caracterizam-se por seu conjunto de movimentos
estar previamente ordenado para cada jogada. Carmichael (2005) explica que, neste caso, um
jogador realiza o primeiro movimento e outro jogador, ou jogadores, realiza o próximo
movimento, conhecendo o movimento do primeiro jogador. Diferentemente dos jogos de

41

movimento simultâneo, os jogadores dos jogos de movimento sequencial fundamentam suas
decisões a partir dos movimentos do adversário.
Outra classificação bastante importante descrita por Carmichael (2005) – e também
por Nash (1951) e Nisan et. al. (2007) – é a da cooperação dos jogadores no jogo. Os autores
consideram o jogo em cooperativo ou não-cooperativo.
Carmichael (2005) descreve que jogos cooperativos são aqueles em que aos jogadores
é permitida a comunicação e a realização de quaisquer acordos sobre como jogar.
Drew (1986) descreve que “a teoria dos jogos não-cooperativos é o modo de modelar e
analisar situações em que cada decisão ótima do jogador depende de suas crenças ou
expectativas sobre o jogo de seus oponentes“. Nisan et. al. (2007) complementam essa
definição dizendo que os agentes dos jogos não-cooperativos atuam individual e
egoisticamente, fugindo da solução proposta e buscando os próprios interesses.
A arquitetura proposta neste trabalho pressupõe a concepção de jogos não-
cooperativos, embora em salas de aula talvez os alunos possam eventualmente se comunicar e
seja possível a concepção de jogos cooperativos nesse contexto, ainda assim a arquitetura
proposta não prevê qualquer meio de comunicação para facilitar a aplicação de jogos
cooperativos.
Quanto movimento a arquitetura proposta permite a concepção de jogos simultâneos,
sequenciais ou até mesmo híbridos, nos quais a informação a principio não esta disponível,
mas pode ser obtida pelos jogadores através do dispêndio de recursos disponíveis.
A teoria dos jogos se mostra relevante por possibilitar a modelagem de problemas que
serão enfrentados pelos jogadores nas tomadas de decisão impostas pelo jogo de empresas,
que simula situações reais nas quais a teoria do jogo é aplicada na busca de soluções.
Problemas conhecidos como o dilema do prisioneiro exemplificam situações que serão
enfrentadas pelos jogadores sendo o conhecimento desses problemas importante para a
concepção do jogo em si por parte do professor bem como para a formação dos alunos.

42

4 ARQUITETURA COMPUTACIONAL DE JOGOS DE EMPRESA

A proposição de uma arquitetura computacional para a construção de jogos de
empresa é o objetivo deste trabalho. Na finalidade de melhor compreensão do que seja uma
arquitetura, este capítulo distingue e define o que é uma arquitetura sob as óticas geral,
computacional e de jogos de empresa.
No âmbito geral, é apresentada uma definição utilizada também em outras áreas de
estudo. No âmbito computacional, é apresentada uma exposição do conceito de modo que a
compreensão de parte do objetivo deste trabalho seja alcançada. Na área de jogos de empresa,
a arquitetura é colocada na visão das abordagens de design dos simuladores com foco na
construção computacional. Durante o capítulo também é descrita a utilização e a aplicação do
conceito exposto no projeto.

4.1 Definições de Arquitetura

Segundo o Dicionário Aurélio (2006), a arquitetura é arte de edificar. Utilizando-se
dessa etimologia e estendendo o sentido, o Dicionário Houaiss (2009) define também
arquitetura como:

1. arte e técnica de organizar espaços e criar ambientes para abrigar os diversos tipos
de atividades humanas, visando tb. a determinada intenção plástica; 2.conjunto das
obras arquitetônicas executadas em determinado contexto histórico, social ou
geográfico. [...]. 5. conjunto de princípios e regras que são base de uma instituição; 6.
conjunto de elementos que perfazem um todo; estrutura, natureza, organização. [...]
(DICIONÁRIO HOUAISS, 2009).

As duas últimas definições da citação acima são, talvez, as mais próximas daquela a
qual este trabalho pretende alcançar, apresentando o conceito de arquitetura computacional de
jogos de empresa. Nos capítulos 5.1, 5.6 e 5.7 são descritas as especificações da arquitetura:
seus princípios e regras (limitações) de funcionamento.
Em sistemas computacionais, a arquitetura pode ser vista como uma composição de
três componentes: organização física; controle e fluxo de informações; e representação,
interpretação e transformação da informação (REDDI; FEUSTEL, 1976). Na arquitetura
proposta, os três componentes são apresentados no capítulo 5.
Outra definição na área computacional, já aplicada à área de software, é dada por
Booch, Rumbaugh e Jacobson (1999):

Uma arquitetura é o conjunto de decisões significativas sobre a organização de um
sistema de software, a seleção dos elementos estruturais e as suas interfaces pelo qual

43

o sistema é composto, juntamente com o seu comportamento como especificado nas
colaborações entre esses elementos em subsistemas progressivamente maiores e o
estilo arquitetural que guia essa organização: os elementos, as interfaces, suas
colaborações e sua composição (BOOCH, RUMBAUGH, JACOBSON, 1999 apud
LARMAN, 2001).

No capítulo 5, são descritos em detalhes os elementos da arquitetura proposta e suas
relações entre si, bem como a especificação que guia a construção e a colaboração desses
elementos.
Quando a arquitetura é colocada no âmbito do design de jogos de empresa, outra
definição costuma aparecer. Por referir-se a algo mais específico e que vai além de um
simples jogo ou da própria construção do software enquanto jogo, a arquitetura de jogos de
empresa trata dos elementos estruturais do jogo e das suas abordagens de design. Nos
próximos subcapítulos serão apresentados os principais elementos estruturais de um jogo
empresarial e uma breve descrição das abordagens de design mais conhecidas, bem como suas
aplicações neste trabalho.

4.2 Elementos Estruturais do Design de Jogos de Empresa

Entre as inúmeras abordagens de design de simuladores de jogos de empresa
existentes, é possível conhecer quais os elementos estruturais principais comuns a todas elas.
O trabalho de Westphal e Lopes (2007) identificou quais são esses elementos e como eles são
integrados na abordagem escolhida.
Westphal e Lopes (2007) identificaram quatro elementos estruturais mínimos que
compõem um simulador empresarial: cenários, decisões, modelagem de algoritmos e métodos
de avaliação do desempenho dos participantes. É importante alertar que esses elementos são
considerados pelo desenvolvimento de simuladores, foco da abordagem utilizada neste
trabalho. Sendo assim, outras considerações, como interações entre os jogadores e aspectos
sociais não são discutidas, não são discutidas.
A Figura 4.1 mostra o relacionamento desses elementos no design de simuladores.

44

Figura 4.1 – Matriz de Relacionamento de Elementos Estruturais
Fonte: Autores

Segundo Teach (1990) apud Westphal e Lopes (2007), um cenário é uma descrição da
indústria que está sendo simulada e das empresas. Um cenário contém referências para as
variáveis externas à empresa e referências para as variáveis internas que o afetam. Em suma,
um cenário descreve a economia na qual a empresa é operada e qual é o efeito dessa economia
nos concorrentes da empresa.
Goosen (1981) apud Westphal e Lopes (2007) propõe o desenvolvimento de duas
estruturas como método Westphal e Lopes (2007) de identificação do cenário: verbal e
matemática. Enquanto a primeira trata da linguagem que é utilizada no jogo, a segunda refere-
se à modelagem matemática que é utilizada na construção do jogo pela ferramenta
computacional.
Neste trabalho, o cenário foi identificado segundo o critério de Waggener (1982), cuja
proposta tem como objetivo a expansão da simulação. Nessa proposta, os jogadores aplicam
os conceitos da Administração na simulação a partir de cenários criativos idealizados pelo
professor.
Westphal e Lopes (2007) alertam que um dos maiores problemas na definição do
cenário está na quantidade de informações que são disponibilizadas ao participante. Neste
projeto, a escolha dessa proposta se deu pela flexibilidade que ela tem em permitir que o
próprio professor seja o interpretador do cenário, não cabendo à arquitetura nem a este
trabalho solucionar esse problema. O detalhamento do cenário é descrito nos capítulos 5.6 e
5.7.
O segundo elemento estrutural mais comum no design de jogos empresariais é a
decisão. Segundo Goosen, Jensen e Wells (1999) apud Westphal e Lopes (2007), o conjunto
de decisões estratégias e táticas são relacionadas entre si a partir de algoritmos que modelam

45

as funções matemáticas das áreas de estudo da Administração, como a Contabilidade, as
Finanças, o Marketing, entre outros.
Como a arquitetura proposta neste projeto visa a contemplar a flexibilidade das
operações idealizadas pelo usuário (professor) e limita-se a não interferir em seus processos
de escolha de modelagem de workflows, a variável de decisão é colocada sob a
responsabilidade do professor.
Embora diretamente ligado à computação, o terceiro elemento estrutural também é
colocado sob a responsabilidade do professor. A modelagem de funções e algoritmos faz parte
dos procedimentos de tomada de decisão que o professor escolhe quando opta por qual
estratégia de decisão no design é a mais adequada ao jogo. Segundo Teach (1990) apud
Westphal e Lopes (2007), um algoritmo é um procedimento operacional que envolve
equações que combinam fatos históricos, decisões e condições econômicas para calcular
resultados.
Por fim, tem-se a avaliação de desempenho dos jogadores, que é um parâmetro para
determinar o vencedor do jogo (WESTPHAL; LOPES, 2007). Entre as diversas
possibilidades existentes para determinar um vencedor, este projeto decidiu por escolher o
mais comum nos jogos de empresa. Uma pesquisa feita por Anderson e Lawton (1990)
apontou que 92,5% dos professores avaliam o desempenho dos jogadores sobre outros
jogadores. Este método de avaliação objetiva priorizar o desempenho competitivo e consiste
em:
a) analisar comparativamente o desempenho entre os jogadores e criar um ranking; e
b) fornecer uma análise objetiva com base nos parâmetros do ambiente simulado.
A utilização desses elementos básicos pode ser aplicada em qualquer abordagem de
design de jogos de empresa. O próximo subcapítulo apresenta de modo sucinto as principais
abordagens ao design e, em seguida, descreve como a arquitetura proposta seguiu a
abordagem escolhida.

4.3 Abordagens ao Design de Jogos de Empresa

Segundo Thavikuwat (2004), o design de simuladores de jogos de empresa tem sido
fundamentado na ciência desde 1957. Com o passar dos anos, diferentes abordagens foram
criadas. Mais recentemente, essas abordagens tem realizado seu foco no design pelo
computador.

GOG: Uma arquitetura para criação de jogos de empresa

GOG: Uma arquitetura para criação de jogos de empresa

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Andere mochten auch

Andere mochten auch (7)

Ähnlich wie GOG: Uma arquitetura para criação de jogos de empresa

Ähnlich wie GOG: Uma arquitetura para criação de jogos de empresa (20)

Mehr von Orlando Junior

Mehr von Orlando Junior (20)

GOG: Uma arquitetura para criação de jogos de empresa