instituto tecnolÓgico de aeronÁutica - davi.ws · tal fator exige que este segmento de uma...
TRANSCRIPT
INSTITUTO TECNOLÓGICO DE AERONÁUTICA
Tese apresentada à Divisão de Pós-Graduação do Instituto Tecnológico de Aeronáutica
como parte dos requisitos para obtenção do título de Mestre em Ciência no Curso de Engenharia Eletrônica e de Computação
Área de Informática
Autor: Jacintho Mendes Lopes Júnior
Uma Abordagem de Desenvolvimento de Sistemas de Jogos de Guerra para a Força Aérea Brasileira
Orientador: Prof. Dr. Adilson Marques da Cunha
Prof. (Chefe da Divisão de Pós Graduação)
Campo Montenegro São José dos Campos, SP - Brasil
2004
Versão 1.2
Uma Abordagem de Desenvolvimento de Sistemas de Jogos de Guerra para a Força Aérea Brasileira
Autor: Jacintho Mendes Lopes Júnior
Composição da Banca Examinadora: Presidente – ITA Prof. Dr. Adilson Marques da Cunha Orientador
ITA
Dedicatória
Às minhas musas Aniele, Nádia, Isabelle e Juliane
A todas as gerações que se revezam em busca de dotar a FAB de pessoal adequado às atividades de Comando e Controle nos níveis Estratégico e Operacional.
Agradecimentos
A Deus, sem cujo apoio, nada seria possível. À minha família, cujo carinho me deu forças para chegar ao fim dessa jornada. Ao Prof. Dr. Adilson Marques da Cunha, pela orientação segura e valiosa. Aos Profs. Carlos Henrique, Celso Hirata e Cairo, pelos valiosos esclarecimentos fornecidos. Ao Cap. -Av. Vinícius pelas valiosas críticas.
“Se vis pacem, parabellum”. (“Se desejas a paz, prepara-te para a guerra”.)
(Ditado romano)
“A guerra é o exame dos povos”.
(Gaston Boutouhl)
Uma Abordagem de Desenvolvimento de Sistemas de Jogos de Guerra para a Força Aérea Brasileira
Resumo
A História tem mostrado, ao longo dos séculos, como a guerra tem sido o
exame dos povos, tornando-se um ponto crítico de decisão para os envolvidos.
Nosso povo, embora de índole pacifista, também precisa estar pronto para
tal exame quando for necessário, uma vez que, quando isto acontecer, a falta de preparo
pode ser a diferença entre contar a história ou talvez até desaparecer dela.
Tal preocupação com o futuro da Nação Brasileira é especificamente vivida
pela Força Aérea Brasileira (FAB), que se vem buscando treinar seu pessoal da forma
mais racional e eficaz.
Na FAB, diversas dessas ferramentas, dentre as quais a simulação empre-
gando recursos computacionais, têm sido, em sua maioria, empregadas no nível Tático,
ou seja, mais especificamente às atividades de emprego, como simuladores de vôo ou de
sistemas de autodefesa antiaérea.
Nos níveis Estratégico e Operacional, entretanto, verifica-se a carência de
sistemas apropriados para o treinamento dos Comandantes e Oficiais de Estado-Maior, a
fim de que os mesmos decidam, com o maior acerto possível o destino da Nação.
Este trabalho de pesquisa foi elaborado endereçando o problema de dotar a
Força Aérea Brasileira de uma sistemática apropriada para o desenvolvimento de siste-
mas de jogos de guerra voltados ao treinamento das atividades de Comando e Controle
nos níveis Estratégico e Operacional, visando a melhorar a eficácia operacional de seu
pessoal e reduzir o desperdício dos recursos envolvidos.
A pesquisa feita indica a solução no sentido de desenvolver uma abordagem
específica para o desenvolvimento de Jogos de Guerra voltados aos níveis Operacional e
Estratégico, a fim de melhorar a eficácia operacional de seu pessoal e reduzir o desper-
dício dos recursos envolvidos.
An Approach for the Development of Wargaming Systems for Brazilian Air Force
Abstract
History has shown, throughout many centuries, how war has been an ex-
amination for peoples, becoming a critical decision point for them.
Although Brazilian people loves the peace, they must be prepared to cope
with such situation whenever it’s necessary, because if it happens when they are not
ready, this could be the difference between telling the History or maybe disappearing.
Such care about Brazilian Nation’s future is lived in Brazilian Air Force,
which has strained at training its personnel in order to get rationality and efficacy.
Simulation has been one of the tools employed for this purpose, mostly us-
ing computer systems. Most of them has been very useful for the tactical level, i. e. they
have been used almost always as flight simulators or as Antiair Self Defense Systems.
Although Simulation is also necessary to operational and strategical levels,
they miss appropriated systems for training Commanders and Staff Officers to make the
best decisions for the destiny of this Nation.
This research was written to tackle the problem of giving Brazilian Air
Force an appropriate systematic for the development of wargaming systems, specifically
for Command and Control activities on Strategical and Operational levels, in order to
improve the efficacy of its personnel and to reduce the waste of all employed resources.
The resource indicates the solution of developping an specific approach for
wargames to Operational and Strategic levels, in order to improve the efficacy of its
personnel and to reduce the waste of all employed resources.
9
Uma Abordagem de Desenvolvimento de Sistemas de Jogos de Guerra para a Força Aérea Brasileira
1. Introdução
“ A arte da guerra é de importância vital para o Estado. É uma questão de vida ou morte, um ca-
minho tanto para a segurança como para a ruína...” (Sun Tzu – 500 a C)
1.1. Motivação
Há milênios que a arte da guerra preocupa os povos por ser, como menciona o cé-
lebre Sun Tzu, uma questão de sobrevivência para os mesmos. Assim é que impérios e hege-
monias se sucederam sobre o mundo até os dias de hoje.
Embora se diga que este é um fenômeno muito importante para ser deixado ape-
nas na mão dos militares, são estes os grandes responsáveis por escrever a ferro e fogo as suas
histórias. Tal fator exige que este segmento de uma sociedade viva permanentemente ocupado
e preocupado com estes momentos, muitas vezes decisivos para a história de diversas nações.
Apesar de ser algo de elevada importância, a preparação para a mesma não pode
exceder em prioridade as metas sociais de uma nação, fazendo com que as riquezas emprega-
das no preparo das forças de um país sempre devam ser otimizados.
Tal fator se mostra mais vivo nos países em desenvolvimento, nos quais os escas-
sos recursos existentes para a área de defesa devem ser muito bem empregados, a fim de ob-
ter-se um preparo adequado.
O surgimento dos jogos de guerra, desde o Chaturanga1 da antiga Índia, que, mais
tarde, foi associado aos atuais recursos computacionais, auxiliou, por meio da simulação das
diversas situações de um conflito, a preparar os estrategistas com um máximo de custo-
benefício.
Clausewitz, em seu livro Da Guerra2, mostrou, há mais de um século, que uma
das grandes limitações dos jogos de guerra para treinamento naquela época era a dificuldade
em expressar mais fidedignamente a realidade. Tal fator, atualmente, pode ser reduzido, gra-
1 Nome em sânscrito que significa Jogo do Rei, constituindo ancestral do atual jogo de xadrez.
2 CLAUSEWITZ, Carl von. De la Guerra. Tradución de R. W. Setaro. 2ª edición. Barcelona: Labor, 1976.
10
ças à evolução da Matemática e da própria Ciência da Computação, que permitem a criação
de abordagens mais flexíveis a novos contextos.
1.2. Contextualização
Este trabalho se volta ao desenvolvimento de uma abordagem que permita atender
às necessidades treinamento na Força Aérea Brasileira (FAB), nos níveis Operacional e Estra-
tégico, das atividades de Comando e Controle (C2).
Conforme os dicionários, a expressão abordagem significa ato ou efeito de tratar
de determinado assunto, sugerindo, por conseguinte, um conjunto integrado de soluções ne-
cessário para a resolução do referido problema.
Uma das situações onde a FAB torna mais clara a carência em relação a jogos de
guerra é no Curso de Comando e Estado-Maior (CCEM), ministrado na Escola de Comando e
Estado-Maior da Aeronáutica (ECEMAR), no qual seus alunos praticam, os ensinamentos de
doutrina e de estratégia militar hauridos, tornando essa Escola um dos centros disseminadores
do treinamento na área de C2.
Tal situação levou à criação do software de dupla ação existente, denominado Sis-
tema Azuver, que utiliza, atualmente, um Módulo de Entrada de Planejamentos (MEP), de-
senvolvido pelo Centro de Computação de Aeronáutica de São José dos Campos (CCA-SJ)
em Object Pascal (Delphi), inicialmente em 1998. Este programa também possui um módulo
de simulação, chamado Módulo de Processamento de Interações (MPI), implementado pela
ECEMAR em Clipper Summer 87, no início da década de 90.
Tal sistema possui o elevado mérito de ser o primeiro software brasileiro a ser efe-
tivamente empregado na simulação de guerra, em cenário aeroespacial, no nível operacional,
entretanto, apresenta alguns inconvenientes resultantes da obsolescência da tecnologia empre-
gada, a qual ainda limitou a abordagem usada no desenvolvimento do MEP.
Dentre os aspectos que mostram a obsolescência do sistema existente, podem ser
citados fatores referentes à linguagem empregada, que possui uma fraca tipagem, ou ligados à
baixa segurança oferecida pelos arquivos do Dbase III Plus (*.dbf) utilizados como repositó-
rios de informações.
11
Existe um outro elemento, também resultante das limitações da tecnologia da épo-
ca, que mais prejudica o treinamento com o sistema existente que é o conjunto de simplifica-
ções adotado. Este fator, visível nos últimos anos, em virtude de uma progressiva evolução
doutrinário-tecnológica, tornou-se mais restritivo para o sistema existente.
Um exemplo é a simples inserção de um novo armamento, resultando numa gran-
de alteração desse software no nível de tabelas *.dbf, devido à desnormalização das mesmas, e
na necessidade de se modificar o código dos eventos que as manipulam.
Outro exemplo é a abordagem utilizada para a simulação dos combates que é cal-
cada em tabelas que contêm probabilidades fixas. Tendo em vista que um combate é um con-
fronto relativo, a simples inserção de uma aeronave ou armamento antiaéreo exigirá a defini-
ção das probabilidades de vitória, de derrota ou de empate contra todos os adversários possí-
veis, tornando a inserção desses recursos progressivamente mais trabalhosa, mais lenta e mais
sujeita a erros. Ambos os exemplos apontados mostram como a flexibilidade desse software
fica bastante comprometida para novos contextos.
Um terceiro ponto é que a abordagem atualmente adotada não permite expandir
facilmente a simulação em relação aos aspectos logísticos, de comunicações ou associados à
repercussão dos danos colaterais ou adicionais causados, em virtude do paradigma de desen-
volvimento empregado. Danos colaterais são resultados indesejáveis obtidos com os ataques,
como, por exemplo, a destruição de um hospital com vítimas fatais durante um ataque a um
aeródromo, enquanto que danos adicionais são resultados desejados (mas não planejados) de
um ataque, como, por exemplo, a destruição de um estoque de armamento aéreo durante um
ataque à pista de um aeródromo.
Sendo assim, a melhor forma de se corrigir tal situação é, antes de mais nada,
compreender-se o problema enfrentado, a fim de viabilizar o estudo do mesmo e de suas pos-
síveis soluções.
12
1.3. O Problema
Percebe-se que o inconveniente vivido no contexto apresentado é que o Sistema
de Jogos de Guerra existente na ECEMAR não atende às atuais necessidades daquela Escola
e, por extrapolação, nem tampouco as da FAB.
A Força Aérea Brasileira necessita de sistemas de jogos de guerra flexíveis, que
permitam treinar as pessoas envolvidas nas atividades de Comando e Controle dos níveis O-
peracional e Estratégico para o desafio dos tempos de conflito. Devido à baixa probabilidade
de conflito entre o Brasil e as nações vizinhas e à progressiva escassez de recursos para a fre-
qüente realização de manobras reais, tal situação exige que este treinamento aproveite ao má-
ximo as vantagens da simulação.
Tendo em vista um velho adágio militar que afirma que se luta como se treina, o
recurso atualmente existente tem um baixo rendimento para a preparação e adestramento dos
futuros Comandantes e Oficiais de Estado-Maior, uma vez que o modelo adotado está aquém
realidade, não atendendo à necessidade de exercitar o pessoal nos diversos aspectos doutrina-
riamente estipulados para os níveis já citados, podendo gerar desmotivação dos envolvidos.
Esta situação ocorreu, conforme já apresentado, devido à obsolescência do siste-
ma elaborado dentro de um contexto e de tecnologias que, com o passar dos anos, tornaram-se
fatores limitantes à sua evolução principalmente para atender a novos requisitos.
Associado a isto, a abordagem adotada também apresenta o inconveniente de ofe-
recer um modelo que não atende aos propósitos da gerência do campo de batalha nos níveis
Operacional e Estratégico, restringindo a simulação apenas aos aspectos operacionais e dei-
xando de apresentar impactos logísticos, psicossociais e de comunicações que podem estar
associados a cada missão, os quais podem levar a questões de extrema importância para o
treinamento dos futuros Comandantes e Oficiais de Estado-Maior.
Assim, devido ao elevado grau de interligação no nível de processo, ou seja, uma
ordem do nível Estratégico (saída) é uma entrada para o nível Operacional, que gera por sua
vez um conjunto de ordens (saídas) para o nível Tático, as quais geram ações que produzem
resultados, os quais são agrupados no nível Operacional e cujas respostas são consolidadas no
nível Estratégico, fechando o ciclo de Comando e Controle, conforme pode ser visto a seguir,
na Figura 1.1.
13
e e
l
Ordem(s)
Resultado(s)
Fig. 1.1 – Interconexão da
Outro fator de interesse é que a
não prevê apenas missões aéreas e de contro
atividades logísticas, de inteligência e de se
tornando-se necessário que o sistema possa c
Percebe-se assim, que a obsolesc
gerou o modelo no qual se baseia o software
técnicas e pelas ferramentas (tanto computac
gia da época em que foi desenvolvida, do qu
ware e de software então disponíveis.
Assim, o problema endereçado
Força Aérea Brasileira de uma sistemática ap
jogos de guerra voltados ao treinamento da
Estratégico e Operacional, visando a melhor
o desperdício dos recursos envolvidos.
Comando
Comandoe
s informações nos diversos
atual Doutrina Básica
le do espaço aéreo, ma
gurança e defesa (além
omportar tais fatores.
ência do sistema é ma
, provavelmente restrit
ionais quanto matemá
e simplesmente em re
neste trabalho de pes
ropriada para o desen
s atividades de Coma
ar a eficácia operacion
Comando
e
Unidad Unidad Unidadníveis
da Força A
s também o
da autode
is fruto da
a pelas meto
ticas), enfim
lação aos re
quisa consi
volvimento
ndo e Con
al de seu p
Unidad
Nível Estratégico
Nível Operaciona
Nível Tático
érea Brasileira
utras ligadas às
fesa antiaérea),
abordagem que
dologias, pelas
, pela tecnolo-
cursos de hard-
ste em: dotar a
de softwares de
trole nos níveis
essoal e reduzir
14
1.4. Análise de Soluções
Antes de analisar-se cada opção apresentada, faz-se necessário especificar as fai-
xas de tempo que serão utilizadas como parâmetro de raciocínio. A expressão curto prazo
refere-se a um tempo igual ou inferior a dois anos, médio prazo, acima de dois anos até cinco
anos e longo prazo, superior a cinco anos
A primeira alternativa de solução considerada foi a manutenção da atual aborda-
gem, a qual atualmente leva em conta apenas os aspectos operacionais do conflito e apresenta
os inconvenientes de operação citados em 1.2. Tal enfoque vicia os tomadores de decisão no
sentido de enfatizarem excessivamente o aspecto operacional, sem levar em conta que a logís-
tica, as comunicações, a segurança e defesa (além da autodefesa antiaérea) e a inteligência são
ferramentas essenciais para o processo, principalmente a nível de realimentação do processo.
Um exemplo que se pode observar a respeito na história é como a superioridade
britânica em termos de Comando e Controle pôde expressar-se mais tarde em termos de supe-
rioridade aérea, devido ao desgaste sofrido pela Luftwaffe no combate com a Real Força Aé-
rea (RAF – Royal Air Force), durante a Batalha da Inglaterra, em 1941-42. Outro exemplo
interessante a respeito é que um dos fatores que ajudou na derrota do Afrika Korps, comanda-
do pelo Mal. Rommel, na II Guerra Mundial, foi exatamente a falta de suprimentos (deficiên-
cia logística).
Calcado nos aspectos supracitados, esta alternativa passa a ser vista como inade-
quada, por não atender às necessidades expressas.
Apesar de poder ser descartada a partir deste ponto, vale a pena analisar os diver-
sos aspectos referentes a essa opção, uma vez que facilitarão a análise do sistema existente, a
ser feita no Capítulo 3.
Realmente, ela exigirá pouco em termos de recursos de hardware e de software,
uma vez que o parque existente atende às necessidades atuais. Em relação ao treinamento do
pessoal para a operação desse sistema, o mesmo será facilitado, apesar da sua dificuldade de
manutenção, em virtude de já haver elevado grau de conhecimento sobre o mesmo e sobre
suas limitações, tornando tal alternativa praticável.
Esta solução tem como principal benefício o baixo custo e a falta de necessidade
de implantação, entretanto, o seu inconveniente mais sério é fazer com que o treinamento fi-
que progressivamente mais distante da realidade e do ideal, uma vez que o fato de os militares
15
que treinarem com a ferramenta existente, com crescente nível de obsolescência, percebem e
sentirão, com uma nitidez progressivamente maior, a inadequação do modelo que a sustenta,
tornando-a inaceitável a médio prazo.
Uma segunda alternativa considerada foi a utilização de um sistema empregado
por outras Forças Aéreas, como a do Chile. Tal idéia é bastante atraente, principalmente no
que se refere ao baixo risco para o desenvolvimento do sistema, em virtude de se tratar de um
software já desenvolvido, associado ao emprego da mesma metodologia a ser adotada pela
FAB. Há, entretanto, inconvenientes bastante relevantes, voltados ao problema doutrinário-
cultural de se instalar um sistema utilizado por outro país, uma vez que a existência de pontos
divergentes entre as doutrinas de emprego pode fazer com que a FAB tenha que se adaptar ao
sistema ou o rejeite, tornando necessários investimentos na personalização do sistema, os
quais podem manter o país dependente de tecnologia externa, expondo a esse país suas regras
e doutrinas de emprego. Existe também o inconveniente do treinamento, uma vez que há
grande rotatividade na equipe que opera esse sistema, tornando sua operação bastante dispen-
diosa, por depender de um grupo estrangeiro. Apesar desse inconveniente, esta solução tem
elevado grau de afinidade com o problema, podendo ser considerada adequada.
Devido aos inconvenientes previamente abordados no que tange à dependência
externa, aos custos de personalização, de treinamento e/ou à aquisição de recursos específicos,
uma vez que tais sistemas podem exigir algum tipo de hardware ou software específico, tor-
nando tal opção excessivamente dispendiosa, em termos de manutenção, a médio prazo. Tal
fator faz com que esta opção seja vista como parcialmente praticável em virtude dos riscos de
custos excessivos face aos escassos recursos disponíveis.
Tendo em vista os riscos associados à rejeição, à apresentação das regras e doutri-
nas sigilosas específicas da FAB para personalização do sistema, da dependência externa e de
custos excessivos de manutenção a médio prazo, tal solução torna-se inaceitável, uma vez que
os riscos são muito altos em comparação com os benefícios auferidos.
16
A terceira opção é o desenvolvimento de uma abordagem específica para o desen-
volvimento de Jogos de Guerra para os níveis Estratégico e Operacional no Comando da Ae-
ronáutica.
Esta opção permite aproveitar o potencial humano existente na FAB e, mais ainda,
preserva o sigilo das regras e doutrinas peculiares, reduz o nível de dependência externa e
aumenta a flexibilidade de manutenção do(s) sistema(s) desenvolvido(s), uma vez que quais-
quer modificações e/ou atualizações seriam executadas sem maiores custos e/ou riscos, por
depender de equipes nacionais. Tais fatores tornam esta alternativa adequada, uma vez que
esta possui a mesma natureza do problema.
Além de possuir custos atraentes por poder utilizar pessoal interno, a possibilidade
de contratação de pessoal externo na fase de implementação a torna ágil e pouco suscetível de
afetar o sigilo das regras, uma vez que as partes mais sensíveis e as regras dos softwares pro-
duzidos seriam trabalhadas por equipes da FAB. Por ser desenvolvida especificamente e tra-
balhada internamente nas fases de análise, podem ser definidos requisitos particulares da For-
ça, viabilizando um elevado grau de aderência ao modus operandi brasileiro, reduzindo os
riscos de rejeição. Existe também a necessidade de pessoal, recursos financeiros e ferramental
de hardware e software capazes de viabilizar tal empreitada, sendo que atualmente existem
tais recursos, com exceção do financeiro, neste Comando. A restrição financeira pode ser mi-
nimizada com o desenvolvimento evolutivo, viabilizando o trabalho com baixo nível de inves-
timento ao longo do tempo. Devido a tais fatores, esta opção aparece com parcialmente prati-
cável.
Tendo em vista o elevado grau de benefício obtido com a flexibilidade de desen-
volvimento e manutenção associada ao sigilo das regras utilizadas, o baixo risco ligado ao
desenvolvimento e a existência e disponibilidade de quase todos os recursos necessários, esta
alternativa pode ser encarada como aceitável, passando também a ser a recomendada neste
trabalho de pesquisa.
Assim, a alternativa de solução recomendada neste trabalho pode ser enunciada
como: desenvolver uma abordagem específica para o desenvolvimento de Jogos de Guerra
voltados aos níveis Operacional e Estratégico, a fim de melhorar a eficácia operacional de seu
pessoal e reduzir o desperdício dos recursos envolvidos.
17
1.5. Especificação de Requisitos do Trabalho de Pesquisa
Este trabalho de pesquisa, em nível de Dissertação de Mestrado, deverá ser capaz
de propor:
Um conjunto de passos necessários ao desenvolvimento de sistemas de Jogos de
Guerra para utilização nos níveis Estratégico e Operacional da FAB;
Um modelo para tratamento de eventos relativos à detecção de incursores;
Um modelo para tratamento dos eventos de combate aéreo, de combate com arti-
lharia antiaérea e para o cômputo dos danos, inclusive adicionais e colaterais; e
Um modelo para o tratamento do impacto dos ataques a sistemas de comunica-
ções.
1.6. Escopo
Este trabalho de pesquisa irá restringir-se a investigar apenas o enfoque do desen-
volvimento de uma abordagem que viabilize a implementação de um sistema de Jogos de
Guerra mais apropriado às atuais necessidades da FAB nos níveis Operacional e Estratégico.
Por se tratar de um trabalho acadêmico não voltado ao levantamento do compor-
tamento dos eventos, as regras utilizadas para a elaboração dos modelos de interação do
protótipo elaborado não terão completeza e não abordarão o aspecto moral ligado às forças
em operação.
Para a verificação e a validação da proposta de solução apresentada, será desen-
volvido um estudo de caso, contendo apenas algumas missões de ataque, escolta, reabasteci-
mento em vôo e interceptação, num ambiente que também contará com meios de detecção
(radares fixos e móveis) e de defesa antiaérea (canhões e/ou mísseis), não devendo ser testado
de maneira exaustiva. A verificação dos fatores logísticos, ligados às comunicações e aos da-
nos colaterais estará associada ao impacto do resultado das missões.
Pretende-se mostrar com esta abordagem que não somente a ECEMAR poderá ser
contemplada, em curto espaço de tempo, com ferramentas de simulação à altura de suas ne-
cessidades, para o treinamento das atividades voltadas a Comando e Controle, como também
18
todas as Organizações do Comando da Aeronáutica que comandam e controlam a atividade-
fim da FAB nos níveis estratégico e operacional.
Eventualmente, possíveis reutilizações desse protótipo poderão ser estendidas para
o Ministério da Defesa, por atenderem às outras Forças Armadas, principalmente no tocante à
Aviação do Exército e à Aviação Naval.
Tal situação será possível devido ao fato de estarem sujeitas a regras de negócio
bastante semelhantes, apesar de serem empregadas, atualmente, com propósitos mais voltados
aos seus interesses, embora se sinta progressivamente a necessidade de uma gerência unifica-
da dos recursos aeroespaciais3, visando à otimização dos esforços para a consecução do obje-
tivo comum de ganhar a guerra.
1.7. Estruturação
Buscando uma melhor compreensão deste trabalho, torna-se também necessário
apresentar como o mesmo está estruturado.
O Capítulo 2, Fundamentos, discute os fatores que serão a sustentação teórica des-
te trabalho, sugerindo como poderão ser aplicados à solução vislumbrada. Parte-se de uma
visão organizacional da ação militar na guerra, chegando-se a recursos para aplicação na solu-
ção proposta.
No Capítulo 3, Sistemas Existentes, serão discutidas várias particularidades refe-
rentes a jogos de guerra existentes em algumas Forças Aéreas no mundo e no Brasil, come-
çando-se pelo software atualmente operado pela FAB, o sistema Azuver.
A proposta deste trabalho é explicitada no Capítulo 4, Desenvolvendo a Aborda-
gem, onde os fundamentos teóricos explicitados no Capítulo 2 são aplicados de forma a cons-
tituir a base para o desenvolvimento de um protótipo de sistema de jogos de guerra.
Um ponto bastante importante para a verificação do valor de qualquer trabalho é a
demonstração de sua conformidade com os requisitos, assim, no Capítulo 5, Utilização da
3 BRASIL. Ministério da Defesa. Doutrina Básica de Comando Combinado. Brasília, 2001. (MD33-M-03). p. 15-16.
19
Abordagem, serão desenvolvidos o levantemento de requisitos, a análise e o projeto de um
protótipo de sistema de jogos de guerra calcado na abordagem apresentada.
Posteriormente, no Capítulo 6, Implementando e Testando o Protótipo, os será
implementado e testado o protótipo, sendo também confrontados os requisitos apresentados
no item 1.6. com a proposta de abordagem desenvolvida no Capítulo 4.
Toda proposta tem um impacto no contexto onde se insere, sendo o impacto desta
proposta tratado em termos de contribuições e perspectivas futuras no Capítulo 7, Visão Pros-
pectiva.
Com base nessa visão prospectiva, surgirão novos horizontes para o desenvolvi-
mento de sistemas de Jogos de Guerra para a FAB, que serão discutidos no Capítulo 8, Con-
clusões e Recomendações. Nesse capítulo também será reenfatizada a importância deste tipo
de sistemas para a gerência eficiente e eficaz da Força Aérea Brasileira, onde ela será mais
decisiva para escrever a história do Brasil – num conflito.
Higham e Parillo4 ratificam que o que proporciona os grandes meios para a vitória
em combate é uma gerência eficiente e eficaz dos recursos disponíveis em relação aos fins
desejados. Tal tipo de competência demanda conhecimento, treinamento e experiência daque-
les que executam essas tarefas gerenciais. Semelhantemente, o entendimento da abordagem
proposta demanda a compreensão dos diversos conceitos que a sustentam.
4 HIGHAM, Robin, Dr., PARILLO, Mark P., Dr. The Management Margin Essential for Victory. Aerospace Power Journal, spring 2002.
20
2. Fundamentos “O valor principal dos jogos de guerra está em preparar a arte operacional para desenvol-
ver o descortino em questões e concepções de operações atuais e futuras. Ele não reside em tentar pre-ver ou revelar resultados, como se fosse para uma justificação orçamentária e de estrutura de força.”
(Cel Bobby J. Wilkes - USAF)
2.1. Os níveis da Guerra segundo a Doutrina Básica da FAB
Buscando facilitar o entendimento dos jogos de guerra e o por quê de, no caso
particular dos níveis estratégico e operacional, resumirem-se em simulação das atividades de
Comando e Controle, torna-se necessário um maior detalhamento, sob diversos prismas, a
respeito do contexto organizacional no qual estão inseridos.
Calcados na Doutrina Básica da FAB (DMA 1-1)5, existem três níveis organiza-
cionais para a gerência do conflito:
2.1.1. Nível Tático
É o nível responsável pelas ações de combate propriamente ditas. Nesse nível, a
grande preocupação em termos de planejamento é a execução das ordens recebidas, ou seja,
como cumprir as missões recebidas face à situação atual.
Os esforços de controle são voltados a informar os órgãos superiores em relação
aos resultados obtidos e à situação atual.
2.1.2. Nível Operacional
É o nível responsável pela orientação do conjunto das ações táticas, planejando o
emprego desse todo, de maneira a atingir os objetivos definidos pelo Nível Estratégico.
Em termos de controle, nesses Comandos são consolidadas as informações oriun-
das das Unidades subordinadas (do nível tático) em relação aos objetivos recebidos, ou seja,
quanto os resultados obtidos no campo de batalha, confrontados com os esperados para este
nível, contribuíram para o sucesso da missão recebida.
5 BRASIL. Estado-Maior da Aeronáutica. Doutrina Básica da Força Aérea Brasileira. Brasília, 1997. (DMA 1-1).
21
As ordens dirigidas às organizações subordinadas são sempre em termos de o que
fazer, deixando aos Comandantes subordinados a liberdade de decisão a respeito de como
cumpri-las.
2.1.3. Nível Estratégico
É o nível responsável pela tradução dos objetivos políticos da guerra em objetivos
militares, essencial para a orientação geral da nação num conflito.
As necessidades desse nível em relação ao controle são voltadas à análise do im-
pacto das ações realizadas para a consecução dos objetivos politicamente estabelecidos.
Em termos de planejamento, este nível organiza os subordinados em termos de hi-
erarquia, de recursos de toda ordem e de missão.
Semelhantemente aos Comandos subordinados, não há, nas ordens emitidas, preo-
cupação a respeito do como fazer, mas sim a respeito de o que fazer, dando a liberdade de
decisão aos subordinados em relação à concepção das ações para cumpri-las.
Observa-se, dessa forma, que o principal fator comum entre os níveis Estratégico
e Operacional é que ambos têm grande ênfase em comandar as ações dos níveis subordinados,
expedindo ordens, e controlar os resultados obtidos por meio da consolidação dos dados rece-
bidos. Em outras palavras, a grande preocupação desses níveis é Comando e Controle.
Antes de se conhecer a organização, entretanto, torna-se necessário conhecer-se o
que esse sistema gerencia, ou seja, as Missões e as Tarefas da Força Aérea, segundo a DMA
1-1.
2.2. Missões e Tarefas da Força Aérea
Para uma melhor compreensão do contexto onde se insere a atividade de Coman-
do e Controle, torna-se importante conhecer-se as missões que essa atividade gerencia.
Calcados no estabelecido pela Doutrina Básica da FAB, observa-se que as tarefas
representam os propósitos mais amplos para aplicação da Força Aérea, enquanto que as mis-
sões constituem ações mais específicas, ficando contidas no escopo de uma tarefa.
22
Com base nisto, as Missões podem ser agrupadas segundo as tarefas que as con-
têm:
Tarefa Missão Tipo de Missão
Ataque Interceptação Escolta Superioridade Aérea
Patrulha Aérea de Combate Ataque Patrulha Marítima Anti-Submarino Reconhecimento Armado
Interdição
Cobertura Transporte Aeroterrestre Transporte Aéreo Logístico Reabastecimento em Vôo Reconhecimento Aéreo Guerra Eletrônica Controle e Alarme em Vôo Ligação Aérea Observação Aérea Controle e Aéreo Avançado Lançamento Aéreo Busca e Salvamento Evacuação Aeromédica Socorro em Vôo Ensaio em Vôo Inspeção em Vôo Instrução e Adestramento Aéreo Lançamento Aéreo
Apoio ao Combate
Busca e Salvamento
Aérea
Operação de Instalações Aeronáuticas Defesa de Instalações Logística Vigilância do Espaço Aéreo
Apoio à Força
Inteligência
De superfície
Tabela 2.1 – Tarefas e Missões da Força Aérea
As tarefas que englobam missões aéreas representam a aplicação da Força Aérea
para a obtenção do controle do espaço aéreo, contra forças de superfície (terrestres ou maríti-
mas) e para a ampliação do próprio poder de combate. A tarefa de Apoio à Força representa
um conjunto de ações para a sustentação do poder aéreo.
Com base nessa organização, há necessidade de que o sistema militar gerencie su-
as missões, permitindo que as ordens planejadas fluam dos níveis mais altos para os mais bai-
xos e que os resultados venham dos inferiores para realimentar as decisões dos níveis superio-
res. Tal abordagem é conhecida como Ciclo de Comando e Controle.
23
2.3. O Ciclo de Comando e Controle e a Doutrina Aeroespacial Brasileira
O processamento das informações recebidas pelos níveis subordinados e outros
órgãos e/ou aliados e das ordens recebidas dos níveis superiores deve ser organizado, de for-
ma a permitir que o Comando alcance seus objetivos.
De uma forma simplista, as ações de Comando se resumem a planejar e expedir
ordens, enquanto que as de Controle permitem verificar o cumprimento e o resultado delas,
permitindo o feedback em relação ao que foi previsto6.
O Cel John Boyd, quando pilotou caças durante a Guerra da Coréia, observou co-
mo tirar vantagem dos comandos hidráulicos do F-86 Sabre para obter vitórias contra os Mig-
15 soviéticos, os quais eram aeronaves tecnologicamente superiores. Tais observações foram
inicialmente transformadas em táticas e técnicas de combate aéreo e, anos mais tarde, por
volta de 1976, foram generalizadas para o emprego das forças militares como um todo, tor-
nando-se o Ciclo de Comando e Controle7, ou ciclo OODA (Observação, Orientação, Decisão
e Ação), que também passou a ser conhecido como Ciclo de Boyd (fig. 2.1).
Este ciclo envolve a observação por parte de sensores e/ou pessoas, a interpreta-
ção dessas informações, a fim de fornecer a orientação das decisões a serem tomadas, a deci-
são propriamente dita e a ação a ser desencadeada.
Graças a essa abordagem, foi possível visualizar na observação e principalmente
na orientação pontos extremamente frágeis no ciclo, fazendo com que a inserção de sinais
falsos e/ou o conflito entre dados verdadeiros induza o inimigo a tomar decisões equivocadas
que lhe custem a derrota final.
Outro ponto a ser ainda analisado é que o excesso de informações faz com que o
sistema inimigo se sobrecarregue em interpretá-las, levando à decisão um atraso que pode ser
fatal.
6 BRASIL. Comando da Aeronáutica. Comando-Geral do Ar. Comando e Controle na Guerra. Brasília, 1999. (MCA 500-3).
7 FADOK, David S. Tem.-Cel. John Boyd e John Warden A Busca da Paralisia Estratégica pelo Poder Aéreo. Aerospace Power Journal em Português. p. 23-48. 1° Trimestre de 2001.
24
Orientação
Observação
Ação
Decisão
Saída para o ambiente (ação)
Entrada do ambiente (reação)
Fig. 2.1 – O Ciclo de Comando e Controle (OODA)
Embora não aborde diretamente o Ciclo de Boyd, a Doutrina Básica da FAB já
possui, desde 1997, elevada ênfase quanto ao processo de Comando e Controle, demandando
que a estrutura de C2 da FAB seja “...ágil, de alta confiabilidade, [capaz de] operar em tempo
real e ser suportada por eficazes sistemas de comunicações e de informações”.
A incorporação do Ciclo de Boyd na Doutrina Aeroespacial Brasileira aparece ex-
plicitamente no MCA 500-3 – Comando e Controle na Guerra8, de onde vem a definição de
Comando e Controle adotada pela FAB: “É o exercício da autoridade do Comandante, na direção
de uma força, com a finalidade de cumprir uma missão. As funções de comando e controle são execu-
tadas através da gerência de pessoal, de equipamentos, comunicações, instalações e procedimentos
empregados pelo Comandante para planejar, dirigir, coordenar e controlar forças e operações no
cumprimento de uma missão”.
Baseado na definição do MCA 500-3, percebe-se a preocupação com o direcio-
namento dos recursos alocados ao Comando para que este cumpra sua missão. Tal quantidade
de recursos aumenta não apenas em termos de quantidade quanto em termos de diversidade
geográfica à medida que o nível se torna mais alto. Assim, a quantidade de pessoas e de meios
a serem administrados no nível tático, por exemplo, em uma Unidade Aérea, é muito menor
que no nível estratégico, como num CJTF (Combined Joint Task Force – Força Tarefa Con-
8 BRASIL. Comando-Geral do Ar. Comando e Controle na Guerra. Brasília, 1999. (MCA 500-3).
25
junta Combinada, que inclui as três forças armadas de pelo menos dois países operando em
coalizão).
Essa complexidade pode ser vista sob o prisma de três dimensões:
2.3.1. Dimensão Psicológica
Aborda o ser humano envolvido no processo de tomada de decisão, a organização
a nível formal e informal e a liderança a ela associada e o processo de tomada de decisão em
si.
2.3.2. Dimensão Metodológica
Aborda o ciclo de C2 em si, as gerências das pessoas envolvidas, dos processos e
dos meios necessários a cada etapa do Ciclo de Boyd.
Associado ao Ciclo de Boyd, há também o processo de assessoria do Comando,
utilizado no relacionamento Comandante-Estado-Maior (EM), constituído das seguintes fases:
- Elaboração da Decisão, com suas etapas de Formulação do Problema, Estudo do
Problema e Tomada de Decisão, onde o Comandante transmite ao Estado-Maior o problema a
ser resolvido (missão), o EM analisa os fatores envolvidos e retorna com um relatório das
análises efetuadas em relação à árvore de decisão, levando o Comandante a, com base nos
fatores apresentados, tomar uma decisão.
- Formalização da Decisão, na qual as ordens resultantes da decisão são confec-
cionadas e enviadas às Unidades subordinadas.
- Acompanhamento da Execução, com suas etapas Supervisão, Reajuste e Ações
Corretivas, voltada às correções necessárias para que o planejamento inicial possa ser reajus-
tado aos fatores observados durante o seu cumprimento.
Tal processo pode ser visto, nesse ambiente e nessa dimensão, como dois ciclos de
C2 associados, conforme apresentado a seguir, na Fig. 2.2:
26
Formalização da Decisão
Elaboração da Decisão
Tomada de Decisão
Estudo do Problema
Formulação do Problema
Observar DecidirOrientar Agir
Acompanhamento da Execução
Ações Corre-tivas
Reajuste Supervisão
Saída para o ambiente
Entrada do ambiente
Fig. 2.2. Ciclo de Comando e Controle versus Processo de Assessoria
2.3.3. Dimensão Tecnológica
Aborda as ferramentas (basicamente sensores, informática e telecomunicações) a
serem empregadas nos sistemas de Comando e Controle.
Tendo em vista que a atuação dos níveis Estratégico e Operacional é essencial-
mente voltada às atividades de C2, os jogos de guerra voltados ao treinamento de pessoal para
esses níveis acabam tornando-se verdadeiros simuladores de Comando e Controle, passando a
serem ferramentas essenciais para o treinamento do pessoal envolvido, uma vez que tal tipo
de treinamento envolve custos e riscos inaceitáveis para determinadas situações que podem
ocorrer em conflito. Como admite a própria DMA 1-1, em relação a essa necessidade: “os
modernos meios de simulação deverão ser exaustivamente empregados, tanto no desenvolvi-
mento técnico e tático como no estudo e na pesquisa de soluções estratégicas”.
O atendimento de tal necessidade de treinamento demanda que sejam aprofunda-
dos conhecimentos a respeito do ciclo de C2 no ambiente dos níveis Estratégico e Operacional
num contexto caótico – o da guerra.
27
2.4. O Ciclo de Comando e Controle e o Caos
Os Majores David Nichols (USAF) e Todor Tagarev (Força Aérea Búlgara) de-
monstraram, em um artigo na revista Airpower Journal9, que a guerra se comporta como um
sistema caótico, apresentando os mesmos aspectos peculiares destes como dependência sensí-
vel, onde pequenas diferenças aumentam rapidamente com o decorrer das iterações, e a fracta-
lidade, onde um padrão se repete em razões progressivamente menores.
Ainda baseado no trabalho destes dois Oficiais e corroborando as idéias do Cel
John Boyd, a importância do fator tempo no ciclo OODA tornar-se-ia fundamental pelo fato
de que, com o decorrer de segundos, minutos, horas e/ou dias e das conseqüentes iterações do
combate, pequenos desvios dos resultados desejados não corrigidos oportunamente poderiam
chegar à irreversibilidade, configurando a derrota.
Em relação à fractalidade, Nichols e Tagarev sugerem que existe uma escalabili-
dade entre as ações dos diversos níveis, ou seja, os níveis tático, operacional e estratégico são
regidos pelas mesmas leis, guardadas as devidas proporções. Dessa maneira, soluções vitorio-
sas a um nível funcionarão, devidamente adaptadas, nos demais, tomando justamente como
exemplo a teoria desenvolvida pelo Cel. Boyd. Assim, o referido Coronel da USAF aplicou a
fractalidade da guerra às suas idéias, trazendo sua contribuição do nível tático (combate aé-
reo) aos níveis operacional e estratégico (Comando e Controle).
Baseados nas idéias acima expostas, chega-se a uma abordagem fractal para o Ci-
clo de Comando e Controle, na qual, além da relação de proporção, também se apresenta a
conexão desses ciclos, uma vez que os resultados dos níveis subordinados influenciam a ob-
servação, a orientação, as decisões e as ações dos níveis superiores, conforme ilustra a figura
2.3.
9 NICHOLS, David, Maj. (USAF), TAGAREV, Todor, Maj. (Bulgarian Air Force). What Does Chaos Theory Means to Warfare? Air Power Journal, …
28
A O
DA O
O
DA O
O
DA O
OD
A OO
D A O
O
D A O
O D
OO
DA O
O
DA O
O
D
A
A
O
DA O
ODA O
O
O
D A O
O
O
Figura 2.3. Uma visão fractal do Ciclo de Boyd
Calcados nessa visão fractal, conclui-se que os níveis operacional e estratégico
têm preocupações muito semelhantes, em termos de gerar e de controlar ordens para a conse-
cução de um objetivo, guardadas as proporções temporais e de meios e objetivos envolvidos.
Assim, o treinamento que se fornecer a um nível será facilmente aproveitado para o outro,
devido ao elevado grau de transferência positiva causado pela similaridade das situações. Se-
melhantemente, as ferramentas que forem desenvolvidas para um nível poderão ser facilmente
adaptadas para o outro.
Baseados nessa visão, fica um questionamento sobre que aspectos são importantes
para que tais ferramentas alcancem seus objetivos, tornando-se necessário, antes de mais na-
da, uma visão mais detalhada a respeito da finalidade dos jogos de guerra.
29
2.5. Jogos de Guerra – Usina de Questionamentos
O Cel. Bobby J. Wilkes, em seu artigo publicado na Aerospace Power Journal10,
discute uma armadilha muito comum na história dos jogos de guerra – utilizá-los como ferra-
menta para a previsão de resultados.
À primeira vista isto parece contraditório, levando-se em consideração os vários
progressos observados em relação à matemática e à computação, que oferecem recursos cada
vez melhores e mais precisos para a simulação dos conflitos e a conseqüente previsão dos
seus resultados.
Faz-se mister lembrar, entretanto, das observações de Jacob Bronowski11 a respei-
to da própria limitação perceptiva humana em absorver todo o conteúdo de informações do
ambiente, levando ao uso de modelos para analisar os aspectos considerados relevantes do
Universo. O uso desse recurso torna o resultado obtido uma fraca aproximação da realidade12.
Tal limitação, associada à visão caótica da guerra, apresentada pelos Majores Ni-
chols e Tagarev, na Airpower Journal, mostra que a perda de um pequeno detalhe pode levar a
uma visão equivocada dos resultados, tornando a previsão exata dos mesmos inviável com os
atuais recursos. Tal situação já havia sido percebida há aproximadamente um século antes por
Karl Von Clausewitz13, em sua clássica obra Da Guerra, à qual ele se referia como a névoa da
guerra, considerando-a um ambiente de elevado grau de incerteza.
Associado a esse fator, existe também, na guerra, a presença do oponente racional
– o inimigo – cujas ações e intenções não são sempre facilmente perceptíveis ou compreensí-
veis, chegando, em determinados casos a ser exatamente uma tática de despistamento, como
ocorreu com os aliados, na Segunda Guerra Mundial, em 1944, quando veiculavam mensa-
gens sobre o futuro desembarque em Calais, a fim de que o alto comando alemão desviasse
sua atenção do real ponto de desembarque (a Normandia), tornando essencial a atividade de
inteligência, conforme já pregava Sun Tzu há mais de 2500 anos atrás em sua obra A Arte da
Guerra14.
10 WILKES, Bobby J., Cel. (USAF). Silver Flag – Uma Concepção para o Aspecto Operacional da Guerra. Ae-rospace Power Journal, 2 Trimestre de 2002. 11 BRONOWSKI, Jacob. As Origens do Conhecimento e da Imaginação. Brasília: Universidade de Brasília, 1997. 12 LEE, David B. – Lt Col (USAF). Wargaming – Thinking for the Future. 13 Clausewitz, Karl von. De la Guerra. Barcelona: Labor, 1976.
14 TZU, Sun. A Arte da Guerra. Rio de Janeiro: Record, 1984.
30
Se não se podem prever exatamente os resultados, então para que servem os jogos
de guerra?
Antes de mais nada, embora os resultados não sejam exatamente o que acontece
na realidade, os jogos de guerra e seus modelos de simulação não deixam de ser verossímeis,
ou seja, continuam sendo cenários realísticos, possíveis.
Tal situação faz desses sistemas um recurso de elevado valor para a análise do
ambiente de combate, das possíveis respostas inimigas e dos cenários assim obtidos, seme-
lhantemente às observações de Maquiavel em sua obra O Príncipe15, quando citava o caso de
um príncipe que, ao sair para caçar com vários nobres, questionava-os a respeito de como
sobreviver a emboscadas e diversas situações de combate inspiradas pelo ambiente em que se
encontrassem.
Tal análise múltipla de cenários lembra também a metodologia ensinada por
Grumbach16, na qual ele apresentava a importância da análise dos diversos cenários possíveis
como base para um planejamento ou para o preparo das pessoas envolvidas com o processo
decisório.
Vistas por esse prisma, essas ferramentas ganham características prospectivas, on-
de é possível estudar-se diversos cenários e indicadores, levantar as questões a eles relaciona-
das e chegar-se a conclusões de grande valor para o preparo dos Comandantes e Oficiais de
Estado-Maior17, como participantes do processo de tomada de decisão no ciclo de Comando e
Controle18.
O próprio Cel. Bobby J. Wilkes, em seu trabalho, recomenda tal postura quando
descreve o as atividades que ocorreram no Naval War College, durante a Segunda Guerra
Mundial, quando, graças à análise de diversos cenários em jogos de guerra, o Almte. Chester
Nimitz e seu Estado-Maior puderam preparar-se para tomar decisões face às diversas contin-
gências possíveis no conflito contra o Japão. Segundo as próprias palavras desse oficial da
USAF, “as questões emanadas dos jogos de guerra beneficiam os combatentes por meio de
ensino, treinamento e análise”.
15 MAQUIAVEL: Os Pensadores. São Paulo: Nova Cultural, 1999. 16 GRUMBACH, Raul J. Prospectiva A Ciência do Futuro. Rio de Janeiro: Catau, 1999. 17 LEE, David B., Lt. Col. (USAF). Wargaming – Thinking for the Future. Airpower Journal,
18 LIEPMAN Junior, James M. Lt. Col. (USAF). Cnth Inth XYZ, TACS, and Air Battle Management The Search for Operational Doctrine. Airpower Journal, Spring 1999.
31
Em outras palavras, mais do que uma ferramenta puramente educacional para cur-
sos como o CCEM, os jogos de guerra se mostram valiosíssimos também para o treinamento
de Estados-Maiores dos níveis operacional e estratégico da FAB, graças à possibilidade de
serem utilizados como um recurso que Peter Senge, em sua obra A Quinta Disciplina19, cha-
mava de micromundos, que são simulacros, em pequena escala, que permitem aos seus usuá-
rios analisarem os diversos cenários resultantes de suas decisões e as questões a eles associa-
das.
Perla20, em sua obra A Arte dos Jogos de Guerra, observa que os resultados de
uma das Forças Aéreas mais bem-sucedidas em conflito do mundo - a israelense - também se
devem a uma elevada ênfase no realismo para seus jogos de guerra, a fim de que as questões e
análises resultantes permitam tratar com maior atenção a conjuntura vivida.
Para viabilizar o entendimento a respeito de como produzir o nível de realismo
adequado, torna-se vital analisar-se os aspectos ligados à criação de Jogos de Tomada de De-
cisão, contexto no qual estão inseridos os jogos de guerra.
2.6. Técnicas para a Criação de Jogos de Tomada de Decisão
Vicente, em sua obra Jogos de Empresas21, recomenda os seguintes passos para a
elaboração de Jogos de Tomada de Decisão –JTD - que incluem tanto jogos de empresas
quanto jogos de guerra e outros jogos estratégicos:
- Qual o objetivo do Jogo? Nesse aspecto, o referido autor divide os JTD em Edu-
tainment (jogos para educação/treinamento) e jogos para análise e quanto ao foco (estratégia,
marketing, decisão, recursos humanos, política, finanças, etc.).
- Quais as formas de jogo? Nesse sentido, o autor questiona o(s) recurso(s) que se-
rá(ao) utilizado(s) para o jogo, que podem variar desde lápis e papel até uma rede de compu-
tadores, sugerindo uma associação entre o foco e as formas de jogo.
19 SENGE, Peter. A Quinta Disciplina. São Paulo: Best Seller, 1995. 20 PERLA, Peter P. The Art of Wargaming A Guide for Professional and Hobbyists. Annapolis: Naval Institute Press, 1990.
21 VICENTE, Paulo. Jogos de Empresas. São Paulo: Makron Books, 2001.
32
- Qual o público-alvo? Onde o autor tece comentários a respeito da adaptação do
jogo ao público-alvo.
Na modelagem, Vicente elabora algumas perguntas bastante importantes:
“Qual o tipo de decisão a ser tomada? Que decisão é correta e que decisão é errada? Como as firmas devem gastar dinheiro? Em que as firmas gastam dinheiro? O modelo reflete a realidade? Onde entra a sorte neste negócio?”22
Quanto a esse último questionamento, a respeito dos gastos de recursos, pode-se
refazer tais questões, para jogos de guerra, da seguinte forma:
Como as forças devem empregar seus recursos?
Em que as forças empregam seus recursos?
Analisando-se essas diretrizes chega-se à conclusão de que esses jogos de guerra
serão utilizados como “edutainment” e que seu foco será estratégia e decisão.
Os recursos utilizados serão salas para planejamento e crítica (“debriefing”) e rede
local de computadores, a fim de agilizar o trâmite de informações.
Os Oficiais de Estado-Maior, em grande parte, evitam prender-se a longos cálcu-
los matemáticos, tornando importante que tais processos de cálculo ocorram de maneira
transparente para o usuário e, tendo em vista a complexidade das tarefas e o tempo reduzido,
torna-se necessário que o sistema facilite os cálculos referentes às diversas providências a
serem tomadas, a fim de que o Estado-Maior se concentre especificamente com a decisão a
ser tomada.
Deverão ser tomadas decisões a respeito do que, com que meios e quando atacar,
do que, com que meios e quando defender, como, quando e quanto ressuprir, que informações
existem e quais são necessárias e quais as medidas para conservar o apoio da opinião pública
interna e externa.
As decisões doutrinariamente corretas apontam, atualmente, na direção do ataque
aos chamados Centros de Gravidade, que são objetivos de vital importância para o inimigo,
podendo incluir lideranças, instalações de Comando e Controle, de logística e/ou as próprias
forças inimigas, em consonância com os trabalhos de John Warden23. Quanto às ações defen-
22 VICENTE, Paulo. Op. Cit.
23 WARDEN, John A.O Inimigo como um Sistema. Aerospace Power Journal em Português,
33
sivas, deve ser tomada atitude semelhante. Em relação ao esforço logístico, o mesmo deve ser
dimensionado para apoiar a decisão tomada com certa margem de tolerância e, em relação ao
apoio da opinião pública, devem ser levadas a cabo ações que resultem em postura favorável
às decisões planejadas.
As perguntas referentes aos recursos abordam o aspecto de como será feito o pla-
nejamento logístico para apoiar as decisões tomadas em relação às ações ofensivas e defensi-
vas previstas.
Essas diretrizes de Vicente oferecem uma visão geral sobre o jogo em si, porém as
últimas, referentes ao modelo e à sorte, são mais pertinentes à simulação, sendo necessário
respondê-las posteriormente, no Capítulo 4, uma vez que constituirão parte importante do
resultado dos combates simulados.
Há também necessidade de abordar-se aspectos mais específicos em relação aos
jogos de guerra, que são elementos essenciais dos mesmos, de acordo com Perla:
- Os objetivos do jogo definem claramente para todos os envolvidos o que ele é,
que informações oferece e a que grupo se destina.
- O cenário é o ambiente físico onde se desenrolarão as operações, colocando os
jogadores num determinado ambiente e condicionando as decisões deles a esse meio.
- O banco de dados contém todas as informações referentes aos recursos disponí-
veis para cada jogador.
- Os modelos transformam as decisões dos jogadores e os dados existentes em e-
ventos. Tais modelos devem oferecer, com alto grau de realismo, as abstrações mais impor-
tantes para alimentar as decisões subseqüentes.
- As regras definem como e quando os modelos serão aplicados e qual a seqüên-
cia em que os eventos serão gerados e tratados.
- Os jogadores são as pessoas envolvidas na utilização do jogo de guerra, que se-
rão ou são oficiais integrantes de Estados-Maiores.
- Por fim, há também necessidade da análise dos resultados obtidos no jogo, a fim
de fixar o aprendizado, no caso de jogos didáticos voltados a profissionais, discutir as diversas
soluções adotadas, no caso de jogos de treinamento de EM ou, ainda, discutir-se os processos
de tomada de decisão e cada decisão, no caso de jogos de pesquisa.
34
As duas visões, de Vicente e de Perla, parecem conflitantes, mas são complemen-
tares, uma vez que as questões referentes aos JTD quando não se enquadram nos aspectos
citados para os Jogos de Guerra, ajudam a complementar a especificação, como, por exemplo,
que decisão é correta e que decisão é errada, permite especificar as ações que serão válidas
por parte dos jogadores, deixando o jogo menos sujeito a falhas por ações não previstas, com-
plementando os modelos.
Outras diretrizes importantes para o desenvolvimento de jogos de guerra são, se-
gundo Dunningham (citado por Perla), a simplicidade e a similaridade a outros jogos.
A simplicidade facilita os trabalhos de projeto, de implementação, de manutenção,
de documentação, de instalação e de operação, fazendo com que o sistema seja bem aceito
pelos usuários.
Quanto à similaridade, vale a pena lembrar que os diversos usuários de jogos de
guerra conhecem ou operam produtos semelhantes ao que será desenvolvido. Assim, uma
brusca ruptura com os paradigmas existentes, salvo se solicitada pelos stakeholders (interes-
sados), pode gerar elevado grau de resistência à mudança e conseqüente aumento nas estatís-
ticas de sistemas rejeitados pelo cliente.
Pensando-se a respeito do modelo a ser criado, percebe-se que o mesmo contém
extensa cadeia de causas e de efeitos, semelhantemente ao que Senge24 pregava em termos de
raciocínio sistêmico.
2.7. Encadeando Ações e Eventos
Senge, em sua obra A Quinta Disciplina, discute os princípios do raciocínio sis-
têmico, levando à criação de círculos de causalidade. Tais círculos também são discutidos por
Pidd25 , em termos de como simular sistemas desse tipo.
Esta abordagem permite gerar um metamodelo, fazendo com que todo o sistema
de jogos de guerra a ser implementado torne-se uma cadeia de decisões que geram resultados
e que realimentam novas decisões (nos vários lados do jogo).
24 SENGE, Peter. Op. Cit.
25 PIDD, Michael. Computer Simulation in Management Science. 3rd edition. New York: John Wiley and Sons, 1994.
35
Existem três estratégias possíveis para se vencer o inimigo em combate, segundo
Warden26: a do custo imposto, na qual a liderança inimiga vê como inviáveis os esforços para
manter a guerra, como no caso do Japão, ao final de 1945; a da paralisia, onde a liderança
inimiga não consegue executar seu esforço de manutenção da guerra, como aconteceu no Ira-
que, em 1991; e a da aniquilação, na qual se destrói o inimigo como um todo, sendo uma op-
ção não recomendada pelo Ministério da Defesa27.
Observa-se também que a paralisia, além de prevista na DMA 1-1, é a opção re-
comendada por estrategistas como Sun Tzu, John Boyd, John Warden e Liddel Hart, por fazer
com que o inimigo não tenha capacidade de reagir (material e/ou psicológica), e que também
pode ser vista como um círculo de causalidade. Tal visão chegou a ser corroborada por War-
den, que via o inimigo como um sistema.
Combinando-se a conexão dos sistemas dinâmicos com a visão dos combatentes
como sistemas antagônicos, obtém-se, no caso de ataques (fig. 2-4):
- -
Ataques sem
êxito Poder amigo
Ataques com
êxito Poder Inimigo
+
-
Figura 2.4 – Ataques com e sem êxito e seus impactos.
Observa-se que o aumento de ataques bem sucedidos a alvos vitais, conhecidos
como centros de gravidade, reduz o poder inimigo e, conseqüentemente, diminui a necessida-
de de novos ataques, em função do impacto desses para a paralisia do inimigo ou para a sua
rendição. O fracasso dos ataques, apesar de paradoxal, traduz a persistência nos objetivos,
pregada pela Doutrina Básica da FAB, principalmente quando se trata de alvos importantes,
como sistemas de C2 ou a capacidade de Defesa Aérea do inimigo.
À luz desses fatores, torna-se possível compreender-se melhor os anéis de War-
den, expostos na figura 2.5:
26 WARDEN, John. Op. Cit. 27 BRASIL. Ministério da Defesa. Manual de Doutrina Militar de Defesa. Brasília, 2001. (MD33-M-04).
Elementos orgânicos essenciais
Forças desdobradas População
Infra-estrutura
Liderança36
Fig. 2.5 – Os anéis de Warden28
Ao explicar sua teoria, Warden afirma que é possível derrotar-se o inimigo bus-
cando-se concentrar os esforços no ataque aos anéis internos e, mais especificamente, na lide-
rança. Ressalta-se também que o referido autor também via como alvo atrativo o “cinturão de
informação” (C2) que envolve os cinco anéis (conectando-os à liderança) e cuja destruição
faria com que os diversos anéis se movessem de maneira frenética, descoordenada, fora de
controle.
Associando-se os diagramas de causa e efeito aos anéis de Warden, aplicados com
sucesso aos sistemas de Comando e Controle, obtém-se a figura 2.6, que ilustra a paralisia
obtida pela neutralização do C2 inimigo.
+ -
Nós conectados da rede de C2 Inimiga
Ataques com êxito
Capacidade de Reação Inimiga
-
Fig. 2.6 – Paralisia obtida por meio de ataques ao sistema de C2 inimigo
Essa visão sistêmica pode ser também aplicada em outras situações, que detalham
o funcionamento dos diversos eventos, norteando, por conseguinte, o modelo do sistema de
Jogos de Guerra. Tais detalhes serão abordados nos capítulos 4 e 5.
Um modelo orientado a causa, para altos níveis de abstração, num ambiente tão
incerto como a guerra, não deve ser determinístico29, devido à atual complexidade das intera-
ções envolvidas. Uma forma de se resolver esta dificuldade seria a utilização de uma aborda-
28 WARDEN, John. Op. Cit. 29 PERLA, Peter P. Op. Cit.
37
gem estocástica e, tendo em vista a falta de uma base estatística confiável para a sua elabora-
ção completa, torna-se necessário o uso de outras alternativas.
2.8. Lógica Fuzzy – Uma Alternativa
Discute-se muito em relação à falta de dados estatísticos que permitam a geração
de um modelo realístico de combate.
Tomando-se por base a discussão do item anterior, na qual mostrou-se os jogos de
guerra não como uma ferramenta para a previsão exata do futuro, conclui-se pela possibilida-
de do uso de recursos que produzam resultados verossímeis30, os quais seriam úteis para su-
prir a falta dos dados estatísticos. Em outras palavras, buscar-se-ia obter resultados aproxima-
dos dos reais, os quais resultariam em simulações aceitáveis e em questionamentos realistas.
Um possível modelo nesse sentido seria a aplicação das próprias regras de veros-
similhança para o tratamento dos eventos de combate como base para a elaboração do modelo
de interação, empregando-se a Lógica Difusa, Nebulosa ou Fuzzy.
Buscando-se um melhor entendimento do que será posteriormente discutido, tor-
na-se necessário detalhar a aplicação da lógica Fuzzy.
O conceito da Lógica Fuzzy surgiu em 1965, com os trabalhos do Prof. Lotfi Za-
deh que a propôs como alternativa para as limitações da lógica booleana em situações ambí-
guas31.
Seu conceito mostrou-se de extrema utilidade para o tratamento de informações
em linguagem natural ou de informações vagas. Faz-se mister ressaltar que tais situações são
extremamente comuns no ambiente de conflito, constituindo parte da névoa clausewitziana da
guerra.
Outro fator muito útil é que o tratamento quantitativo para informações recebidas
em linguagem natural permite também uma aceleração no tratamento de informações, que,
associado à simplificação na solução de problemas, viabiliza o tratamento dos eventos de
combate de forma mais simplificada sem prejudicar o realismo dos mesmos.
30 Verossímil, segundo o Dicionário Michaelis da Língua Portuguesa: “que não repugna à verdade, possível” e, segundo o Dicionário Aurélio: “semelhante à verdade (...), provável”.
31 CRUZ, Adriano. Lógica Nebulosa. Rio de Janeiro: UFRJ, 2002. (Apresentação)
38
Seu princípio básico é calcado na atribuição e interpretação (fuzzyficação ou nebu-
lização) de valores de entrada para as regras, sendo então avaliado o grau de pertinência do
conjunto de entrada às regras, em função do valor obtido na fuzzyficação. Com base no valor
obtido há uma implicação dentro de cada regra, na qual é atribuído um “valor-conseqüência”
à pertinência ao conjunto nebuloso, sendo seus resultados agregados para formar o conjunto
de saída, o qual é tratado (defuzzyficado ou desnebulizado) para fornecer resultados de acordo
com a faixa de saída.
ImplicaçãoImplicaçãImplicaçãoo
Nebulização
(Uma/regra)
Agregação
Desnebulização
Entrada 1
Saída Entrada 2
Entrada 3
Figura 2.7 – Funcionamento de um sistema utilizando Lógica Nebulosa
Como exemplo, digamos que, num determinado cenário de riscos para gerência de
projetos, no qual são avaliados apenas a estabilidade e o nível de conhecimento dos requisitos
e o grau de domínio da tecnologia a ser usada, se os requisitos são conhecidos e estáveis, o
risco é baixo ou se a tecnologia a ser empregada é pouco conhecida, o risco é alto.
Tais afirmações podem ser transformadas num conjunto de regras de pertinência,
encadeando-se todas elas:
- Se os requisitos são pouco conhecidos e pouco estáveis ou a tecnologia é pouco
conhecida, o risco é ALTO.
- Se os requisitos são medianamente conhecidos e medianamente estáveis ou a
tecnologia é medianamente conhecida, o risco é MÉDIO.
- Se os requisitos são bem conhecidos e bem estáveis ou a tecnologia é bem co-
nhecida, o risco é BAIXO.
Além das regras, torna-se necessária a obtenção dos valores de entrada, referentes
ao conhecimento e à estabilidade dos requisitos e ao conhecimento da tecnologia necessária
como valores de 0 a 10, significando, por exemplo, em relação à estabilidade dos requisitos,
0, nenhuma estabilidade e 10 completa estabilidade.
39
Os valores de entrada serão utilizados em cada regra, resultando um grau de perti-
nência ao conjunto referente à mesma, resultante da nebulização.
Supondo-se como valores de entrada 7 para o conhecimento dos requisitos, 6 para
a estabilidade e 8 para o domínio da tecnologia a ser aplicada (Fig. 2.8), obtém-se o seguinte
resultado para a regra 1, associando-se inicialmente os requisitos e depois o domínio da tecno-
logia:
0,40,3 0,2
867 Domínio da Tecnologia Estabilidade dos Requisitos) ou (Conhecimento dos Requisitos e
0,3
0,3
Fig. 2.8 - Nebulização
Utilizando-se a função min( ), mínimo, para o encadeamento e (AND), obtém-se
0,3 para os requisitos e, empregando-se max( ), máximo, para o encadeamento ou (OR), ob-
tém-se, como resultado da nebulização, 0,3.
Baseado no valor obtido, pode ser, então, realizada a implicação (Fig. 2.9):
Se nebulização(entrada) = 0,3; então
0,3
Pertinência(entrada) = 0,3 0
Fig. 2.9 – Implicação
A implicação deve ser interpretada a área atribuída ao grau de pertinência do valor
de entrada obtido em relação ao conjunto nebuloso associado à regra (alto risco, no caso).
40
As demais regras, 2 e 3, utilizam o mesmo raciocínio, diferindo apenas na função
de pertinência empregada para a implicação (Fig. 2-10), resultando: Para a Regra 2:
7
0,6
6
0,8
0,4
8 Estabilidade dos Requisitos
Conhecimento dos Requisitos Domínio da Tecnologia
Assim, a entrada passa a valer Max([Min(0,6; 0,8)]; 0,4) ∴entrada = 0,6.
0,60,6
00
Para a Regra 3:
7
0,7
6
0,80,6
8Estabilidade dos Requisitos Conhecimento dos Requisitos Domínio da Tecnologia
Assim, a entrada passa a valer Max([Min(0,7; 0,6)]; 0,8) ∴entrada = 0,8.
0
0,8
0,8
0
Fig. 2.10 – Aplicação das regras 2 e 3.
A saída será um número no valor de 0 a 10, indicando o grau de risco do projeto
(Fig. 2.11), significando com 0 que o projeto não tem risco e com 10 que o projeto é inviável
pelo excessivo risco.
41
3,125
Fig 2.11 – Agregação e Desnebulização
Com base no obtido acima, obtém-se um nível de risco igual a 3,125, significando
um baixo, porém considerável nível de risco para o projeto de exemplo.
Tal associação de visões qualitativas a fatores quantitativos torna viável a substi-
tuição dos dados estatísticos inexistentes pelas próprias regras dos diversos eventos, conforme
será discutido no capítulo 4.
Todos esses recursos, ao serem transformados em software devem poder ser rea-
proveitados ao máximo, acelerando a produção dos sistemas que deles necessitem. Objetivan-
do tal reutilização com flexibilidade, buscou-se a orientação a objetos.
2.9. Orientação a Objetos – Um Caminho Progressivamente Melhor
A orientação a objetos é um recurso extremamente útil devido às suas característi-
cas citadas por Page-Jones32:
2.9.1. Classes
A grande característica da orientação a objetos é a existência das classes, as quais,
segundo Page-Jones são o “estêncil a partir do qual são criados (gerados) os objetos” Tal
recurso permite a criação de objetos que possuirão a mesma estrutura e comportamento pre-
vistos para a classe.
Devido ao fato de serem um fragmento de software com baixo acoplamento com o
sistema para o qual foram inicialmente desenvolvidas, poderão ser utilizadas em outras apli-
cações que tenham necessidades semelhantes.
32 PAGE-JONES, Meilir. Fundamentos do Desenho Orientado a Objeto com UML. São Paulo: Makron Books, 2001.
42
2.9.2. Identidade de Objeto
Trata-se da propriedade que todo objeto possui, independentemente da classe a
qual pertença, permitindo que ele seja tratado especificamente.
Este identificador é único para todos os objetos, mesmo que se trate de dois obje-
tos de uma mesma classe e com os mesmos valores de atributos. Tal situação pode levar a
tratamento específico quando houver necessidade de se persistir objetos assim num banco de
dados.
2.9.3. Encapsulamento
Como o próprio termo sugere, os objetos são tratados pela aplicação como “cai-
xas-pretas” pelo fato de a mesma não acessar diretamente as informações ou certas operações
neles existentes, a não ser pelos recursos disponibilizados na interface.
Tal situação facilita a detecção dos erros, uma vez que se sabe que as falhas refe-
rentes a um objeto não serão fruto dos outros, pelo fato de os objetos terem suas informações
e implementações isoladas entre si.
Esse fator também viabiliza o reaproveitamento e a manutenção do código desen-
volvido, pois, uma vez que os objetos são fechados para a aplicação, torna-se necessário que
ela apenas saiba o que solicitar e o que esperar deles para poder utilizar todos os recursos dis-
ponibilizados.
2.9.4. Ocultação de Informações e de Implementações
Como conseqüência de um bom encapsulamento, as informações e implementa-
ções de uma classe tornam-se fechadas às demais, protegendo as variáveis e os algoritmos
utilizados de modificações indesejáveis, oriundas da aplicação. Essas informações protegidas
da aplicação tornam-se acessíveis ao sistema apenas por meio dos métodos da classe, os quais
permitem que esta controle as informações recebidas, dando maior estabilidade ao sistema.
43
2.9.5. Herança
A herança aumenta o potencial de reaproveitamento do código produzido para as
classes, viabilizando pequenas adaptações à superclasse, possibilitando também o acréscimo
de funcionalidades, especializando a classe resultante quanto a algum aspecto de interesse do
sistema.
Ressalta-se também que a herança permite distribuir certo tipo de comportamento
entre as classes de um sistema, facilitando sobremaneira o trabalho de implementação.
2.9.6. Retenção de Estado
Desde a sua criação até a sua destruição, um objeto armazena o conjunto de valo-
res dos seus atributos, ou seja, seu estado, a fim de reagir convenientemente no contexto da
aplicação.
2.9.7. Polimorfismo
Conforme a própria etimologia (do grego poli, muito, e morphos, forma), duas
classes podem herdar um mesmo método de uma classe-pai e implementá-lo diferentemente.
Assim, criada a classe porcentagem, com um método chamado calcular, que cal-
cula a porcentagem recebida do valor que a classe armazena, foram também obtidas por he-
rança as classes juro, cujo método calcular reaproveita o valor obtido pela classe pai e o soma
ao valor armazenado na própria classe, e desconto, cujo método calcular reutiliza o cálculo
genérico da classe porcentagem e abate o valor obtido do valor armazenado.
O polimorfismo aumenta o potencial da herança, tornando-a mais flexível e per-
mitindo que os métodos existentes na classe base possam ser aproveitados da maneira mais
conveniente nas “classes-filhas”, as quais se comportarão de várias formas com o mesmo mé-
todo. Pode-se ainda fazer uma mesma referência a métodos de objetos de classes diferentes
em diferentes momentos, utilizando-se a superclasse, a fim de obter-se resultados específicos.
44
2.9.8. Mensagens
São o meio de comunicação entre os objetos, solicitando que o objeto receptor a-
cione um método específico.
Tal método pode realizar alguma tarefa determinada de interesse do sistema (men-
sagens imperativas) ou apenas fornecer (mensagens interrogativas) ou receber nova informa-
ção (mensagens informativas).
2.9.9. Generalização
Com uma visão um pouco diferente da mais comum quando se trata de orientação
a objetos, Page-Jones se refere a esta característica no sentido de ser a construção de uma
classe X de forma que se utiliza de uma ou mais outras classes, que lhe são atribuídas na hora
em que X é instanciada. Tal conceito permite a criação de classes contêiner, que permite man-
ter objetos em um determinado tipo de estrutura mais sofisticada, por exemplo, grafos.
Para se desenvolver um sistema orientado a objetos é também necessário optar-se
por um caminho, uma metodologia, a qual está associada a um processo de desenvolvimento
de software já bem apoiado em ferramentas CASE (Computer Aided Software Engineering –
Engenharia de Software auxiliada por computador), a fim de constituir a base da abordagem –
o Processo Unificado Rational (RUP – Rational Unified Process).
2.10. O Processo Unificado Rational (RUP)
O Processo Unificado Rational, como mostra o próprio nome, é um conjunto de
atividades distribuídas no tempo, visando a transformar as necessidades do cliente em um
software de qualidade.
Tal processo de desenvolvimento de sistemas é evolutivo, ou seja, divide o mes-
mo em partes de forma a construí-lo em mini-projetos, que constituirão as iterações, visando a
reduzir os riscos e a complexidade, cujos resultados serão integrados, constituindo incremen-
tos, de forma a, ao final da última iteração, obter-se todo o software.
45
O ciclo de desenvolvimento no RUP é dividido em fases e em disciplinas, sendo
que cada fase é dividida em uma ou mais iterações e cada iteração contém diversas discipli-
nas, conforme exposto na figura 2.13:
Fig. 2.13 – Fases e Disciplinas do RUP33
A estratégia do RUP para entregar sistemas de qualidade é baseada nos seguintes
aspectos:
2.10.1. Orientado por Casos de Uso
Os casos de uso são o detalhamento das funcionalidades do sistema, que fornecem
ao usuário um resultado de valor. Em outras palavras, descobrem-se casos de uso perguntando
o que se espera que o sistema faça para cada usuário.
Com base nessa visão, os casos de uso passam a fornecer todos os requisitos fun-
cionais do sistema.
Os casos de uso não são ferramentas apenas para requisitos. Muito mais do que is-
to, com base neles, concebe-se a arquitetura do sistema, é feita a análise, o projeto, a imple-
mentação, a distribuição, planejam-se e executam-se os testes. Vale a pena lembrar que mui-
tas das informações neles obtidas podem também realimentar a lista de riscos do projeto, fa-
zendo desse modelo a base de todo o desenvolvimento do sistema. É também interessante
citar que, algumas vezes, a arquitetura também pode influenciar os casos de uso, algumas ve-
33 RATIONAL Software. Rational Unified Process. [s. l.], [2001?].
46
zes, por exemplo, devido à inviabilidade de um requisito em face dos recursos tecnológicos
disponíveis.
Assim, numa sucessão de diferentes prismas pelo qual o sistema é entendido e
construído, o modelo de casos de uso é especificado pelo de análise, realizado pelo de projeto,
implementado pelo de implementação, distribuído pelo de distribuição e verificado pelo de
testes, tornando possível a rastreabilidade entre os diversos artefatos produzidos e os casos de
uso.
2.10.2. Centrado na Arquitetura
A arquitetura apresenta a forma do sistema, visando a atender aos requisitos esta-
belecidos, exemplificada no naquilo que diferencia uma ponte de um monte de ferro e concre-
to que é a forma associada a um propósito.
Muitas vezes, essa forma é complexa, exigindo, como nas plantas de edifícios, di-
versas visões específicas do mesmo objeto, buscando-se viabilizar o entendimento de cada um
deles em particular.
Tais visões, no RUP, são baseadas nos Casos de Uso, abordando também outros
aspectos, como os lógicos, os de componentes e os de distribuição.
Este é um ponto fundamental para o desenvolvimento bem-sucedido de um siste-
ma, uma vez que a escolha imprópria da sua forma pode afetar sua flexibilidade, sua evolução
ou até o seu funcionamento em relação aos requisitos.
Assim, um software concebido para uso na Internet pode utilizar uma arquitetura
distribuída, enquanto que tal pode não ser apropriado para outro que vai ser utilizado em uma
rede local.
Buscando utilizar-se o RUP da maneira mais ágil para o desenvolvimento do pro-
tótipo para validar a abordagem, optou-se pela utilização do método proposto por Philippe
Kruchten em seu artigo Software Development for a Team of One34, onde as idéias por ele
expressas não alteram o processo, mas apenas o tornam mais leves, associadas à proposta de
Lesliee Probasco em seu artigo Ten Essencials of RUP – The Essence of na Efective Deve-
lopment Process, onde eles sugerem como essenciais os seguintes aspectos:
34 KRUCHTEN, Philippe. Software Development Process for a Team of One. The Rational Edge, 2002, www.therationaledge.com, capturado em 25 set 2002.
47
Documento de Visão (apresenta o glossário, o problema, os interessados, suas ne-
cessidades, as características necessárias ao software e os casos de uso, os requisitos não fun-
cionais e as limitações de projeto);
Plano de Desenvolvimento do Sistema, que especifica como será realizado o de-
senvolvimento dos artefatos do sistema;
Lista de Riscos, que aborda os riscos do projeto e o tratamento para os mesmos;
Tarefas a serem desenvolvidas;
Caso de Negócio;
Arquitetura;
Avaliação;
Pedidos de Mudança efetuados pelo usuário, a fim de controlar a configuração em
operação; e
Apoio ao Usuário.
Por se tratar, no entanto, de um trabalho acadêmico, onde apenas uma iteração do
RUP será executada, serão omitidos o Caso de Negócio, mais direcionado à viabilidade eco-
nômica do projeto; a avaliação, os pedidos de mudança e o apoio ao usuário, por se saber que
o protótipo não será entregue aos seus potenciais usuários.
Segundo os autores aqui mencionados, o primeiro passo a ser buscado é a confec-
ção do documento de visão, do qual já se definiu o problema, sendo a base para a definição
dos casos de uso.
Tendo em vista a capital relevância dos casos de uso para a aplicação da aborda-
gem, torna-se necessário detalhar-se alguns aspectos referentes à obtenção dos mesmos.
2.11. A Gênese dos Casos de Uso
O levantamento dos casos de uso, segundo Leffingwell35, baseia-se na obtenção
de outros dois aspectos principais:
2.11.1. Necessidade dos Interessados
35 LEFFINGWELL, Dean, WIDRIG, Don. Managing Software Requirements: A Unified Approach. Reading, Massachussetts: Addison Wesley, 2000.
48
Utiliza-se aqui o termo interessados como uma tradução para stakeholders, que
são um grupo que abrange mais que os usuários de um software, mas todos os afetados por
ele, que têm o poder de expressar como desejariam que ele influenciasse suas atividades.
Aqui são expressos todos os desejos dos interessados em relação ao novo sistema,
os quais levarão ao questionamento a respeito do que será necessário criar-se para atender tais
desejos dos usuários, caso sejam realmente viáveis.
Respondendo tal pergunta, chega-se ao próximo passo no processo de levanta-
mento de requisitos – a obtenção das funcionalidades.
2.11.2. Funcionalidades Necessárias
É o conjunto de características que o sistema tem de possuir para atender às ne-
cessidades levantadas. Tal informação pode ser obtida respondendo-se à pergunta:
Que funcionalidades o sistema X precisa ter para atender à necessidade Y?
Ressalta-se que uma funcionalidade pode atender a mais de uma necessidade e
que uma necessidade também pode ser atendida por mais de uma funcionalidade.
Perguntando o que fazer para que uma funcionalidade efetivamente atenda às ne-
cessidades dos interessados, retornando a eles algo de valor, obtém-se uma grande variedade
de cenários, que expressam o comportamento desejado do sistema, constituindo os casos de
uso.
Assim, os casos de uso surgem como comportamentos do sistema para atender às
funcionalidades, podendo haver mais de um para atendê-las, caso sejam mais complexas, co-
mo também pode haver mais de uma funcionalidade simples atendida por apenas um caso de
uso.
Ressalta-se que com todos os casos de uso, obtém-se todos os requisitos funcio-
nais e parte dos não-funcionais (relacionados diretamente aos casos de uso) do software.
Antes de se propor a abordagem e se tratar das funcionalidades necessárias, vale a
pena levantar-se este aspecto em relação aos sistemas já existentes no Brasil e no mundo.
Com base principalmente nas informações conceituais apresentadas nos itens de
2.1. a 2.3., pode-se analisar diversos aspectos referentes às funcionalidades dos sistemas atu-
almente existentes, não apenas no Brasil, mas também em alguns outros países.
49
3. Sistemas Atualmente Existentes
“Assim, um príncipe deve preocupar-se com a arte da guerra e praticá-la na paz mais a-inda do que na guerra, e é possível conseguir-se isto de dois modos: pela ação ou somente pelo pensa-mento”.
(Maquiavel) 3.1. Considerações Iniciais
Conforme a recomendação de Maquiavel, torna-se essencial que, semelhantemen-
te aos príncipes daquela época, os Comandantes e Oficiais de Estado-Maior estejam prepara-
dos para a guerra e, devido aos custos de treinamentos reais, principalmente nos níveis mais
elevados, faz-se mister o uso de simulações, que permitirão o preparo pelo pensamento, anali-
sando e discutindo os resultados de suas ações, e pela ação, concebendo e executando as suas
estratégias.
Buscando-se analisar as ferramentas existentes, faz-se importante definir os parâ-
metros que nortearão tal análise:
3.1.1 Flexibilidade
Capacidade do sistema em adaptar-se a novos contextos, que variam desde novas
aeronaves ou armamentos até novas estruturas, formas de controle de tempo ou cenários.
3.1.2 Realismo
Grau em que o sistema cumpre as regras de verossimilhança dos eventos (por e-
xemplo, uma aeronave desarmada não deve ser capaz de derrubar uma aeronave armada).
3.1.3 Aderência Doutrinária
Grau em que o software se coaduna com a Doutrina Básica da FAB, a fim de evi-
tar-se que a FAB se adapte ao sistema.
3.1.4 Ferramenta para Crítica
Recurso que o sistema permite que os jogadores analisem seus acertos e/ou erros
na aplicação de suas estratégias.
50
Buscando dar a este trabalho uma base para comparação em relação à situação a-
tual da FAB, torna-se importante iniciar esta análise pelo sistema que era operado na ECE-
MAR até o ano 2003, o Sistema Azuver, na versão 2.6.
3.2. Sistema Azuver
Este sistema foi desenvolvido inicialmente no final da década de 80 pela equipe
da ECEMAR, tendo como principal vantagem o fato de ser o primeiro software utilização na
categoria de sistema de jogos de guerra para emprego aeroespacial, no nível Operacional, para
uso didático na FAB.
Sua primeira versão como sistema incluía todas as entradas e simulação em Clip-
per Summer 87, permitindo a simulação de um conflito entre dois países (partidos), constitu-
indo, assim, um jogo de guerra de dupla ação.
Sua constituição é de um Módulo de Entrada de Dados36, mais tarde chamado
Módulo de Entrada de Planejamentos (MEP)37, que recebia os planejamentos dos partidos, e
de um Módulo de Interação de Planejamentos (MIP), que realiza toda a simulação do conflito.
Posteriormente, em 1997, o CCA-SJ ficou responsável por aperfeiçoar o MEP,
desenvolvendo a nova ferramenta em Delphi, sem, no entanto, alterar a estrutura do Banco de
Dados existente, o qual apresentava inconvenientes resultantes da falta de normalização, cuja
solução demandaria modificações profundas na simulação. Foi também adicionado o Módulo
de Visualização de Resultados (MVR), que permite visualizar as ações de um ou mais Co-
mandos de um ou de ambos os partidos, tornando-se uma eficiente ferramenta de crítica, gra-
ças aos recursos visuais fornecidos. Esta versão passou a ser denominada 2.3 e sua composi-
ção e funcionamento são expostas na figura 3.1.
Seu funcionamento, a partir da versão 2.3 passou a ser o planejamento realizado
pelos alunos no MEP e transmitido ao Grupo de Controle (GRUCON) via disquete. Após re-
ceber os disquetes ou atingir o horário-limite, o GRUCON iniciava a simulação no MPI, len-
do os disquetes, concatenando os planejamentos, gerando e ordenando os eventos e os execu-
tando. Uma vez obtidos os resultados, estes eram transmitidos aos grupos via relatórios e em
36 BRASIL. Escola de Comando e Estado-Maior da Aeronáutica. Azuver – Jogo de Guerra de Dupla Ação. Rio de Janeiro, [1997?]. (Manual do Sistema).
37 BRASIL. Centro de Computação da Aeronáutica de São José dos Campos. Manual do Usuário do Módulo de Entrada de Planejamentos (MEP). São José dos Campos, 1998.
51
disquetes, os quais realimentavam o planejamento no MEP. O MVR era utilizado pelo GRU-
CON para a elaboração da crítica do exercício, sendo visto pelos alunos apenas no final do
último exercício.
O Azuver 2.X (conjunto de todas as versões até hoje desenvolvidas) trabalha com
períodos de tempo de 12 horas, denominados janela, não possuindo capacidade de variar o
tipo de gerência de tempo.
MEP MVR
P nejamento
Resultados
-Partidos
Fig. 3.1 – Visão
A principal vantagem d
simular rapidamente um conflito en
te à preconizada pelas normas bras
Sua principal desvanta
malização das tabelas do Banco de
Um fator que, na époc
separação das regras que deveriam
mantidos em arquivos e/ou em ban
dade em termos de adaptação à inse
Um exemplo desta situ
possível. Além da necessária inclus
Unidades que o empregarão e das
mudanças na estrutura de diversas
la
Resultados MPI
RelatóriossRelatórioRelatórios
Resulta
esquemática d
a atual versã
tre dois país
ileiras até 200
gem é a man
Dados e da f
a, não era su
ser escritas
cos de dados
rção de novo
ação é a inse
ão do mesm
suas probabil
tabelas (de ae
GRUCON
dos
a arquitetura do Azuver 2.X
o da ferramenta existente é a possibilidade de
es com a estrutura militar de guerra semelhan-
3.
utenção, principalmente afetada pela desnor-
alta de flexibilidade do sistema.
ficientemente conhecido era a necessidade da
no código e dos parâmetros que deveriam ser
, a fim de dar ao sistema a necessária flexibili-
s equipamentos e/ou cenários.
rção de um novo armamento no único cenário
o no banco de dados, da sua distribuição pelas
idades de acerto, essa modificação resulta em
ronaves, para a inserção das novas configura-
52
ções, de meios aéreos, que contém os estoques de armamentos e alvo-aeronave, que tem as
probabilidades de acerto), forçando a criação de um novo atributo, referente ao novo arma-
mento, em vez de um novo registro. Essa alteração tem impacto direto no código, tornando
necessário um rastreio em toda o MPI e no MPE, onde deverão ser ajustados os comandos
para aceitar o novo campo.
Outro exemplo é a inserção de novo equipamento de Artilharia Antiaérea. Além
de colocá-lo no banco de dados, em termos de distribuição, faz-s mister ajustar-se o código
com as informações referentes à probabilidade de acerto desse sistema de armas, uma vez que
não há tabelas no Banco de Dados que levem em conta tais fatores.
Além da manutenção, este sistema se restringe a apenas um tema com pequenas
variantes de cenários, restrito, entre outros fatores, pela maneira como foi modelado, que le-
vava em conta apenas aspectos específicos do Cone Sul até a versão 2.3. Para o desenvolvi-
mento da versão 2.6, que comportava um cenário maior, houve necessidade de modificações
em algoritmos de cálculos de distância e de geo-referenciamento para o MEP e para o MVR.
Outro fator que também contribui para a obsolescência desse software é a falta de
realismo do seu modelo de simulação.
Por utilizar o gerenciamento de tempo do próximo evento, o sistema calcula toda
a detecção antes de começar a realizar os demais eventos sem, entretanto criticar o impacto
desses nas detecções posteriores. Por exemplo, se na detecção, um radar detecta uma aeronave
às 10:00, se ele tiver sido destruído às 09:30, este evento de detecção deveria ser cancelado,
porém seu impacto continua existindo na simulação.
Nele, são levadas em conta quase exclusivamente as missões aéreas, sendo tam-
bém consideradas as atividades de recuperação de pistas, a interação com a artilharia anti-
aérea e o consumo de material bélico.
Apesar da elevada ênfase às missões aéreas, o enfoque ainda tem restrições quanto
à simulação de surtidas, as quais, num período de 12 horas, denominado janela, são restritas a
apenas uma, quando poderia haver mais, dependendo apenas da duração das mesmas e do
tempo para reabastecimento e remuniciamento (intervôo).
Devido a problemas de normalização no banco de dados, ocorrem inconsistências
no reconhecimento eletrônico, o qual detecta radares que teoricamente estariam fora de alcan-
ce e não detecta os mais próximos, e no reconhecimento foto, quando as informações obtidas
53
não vêm atualizadas, fazendo com que um reconhecimento que chega num objetivo recém-
atacado ainda vê o alvo intacto.
Os aspectos de Segurança e Defesa levados em conta referem-se quase que espe-
cificamente à ação da autodefesa antiaérea, faltando interações da guarda e segurança de ins-
talações com guerrilheiros, terroristas e/ou Forças Especiais inimigos.
O controle do armamento aéreo não leva em conta o ressuprimento das Unidades
e nem inviabiliza a realização de missões pela falta dos recursos, permitindo estoques negati-
vos.
Para completar a abordagem logística seria necessário discutir-se o consumo e
ressuprimento de víveres, de material de saúde, a situação dos efetivos e os transportes.
O MVR como ferramenta de crítica apresenta diversas possibilidades para a apre-
sentação dos danos causados e para a apresentação das missões planejadas. A partir da versão
2.6, passou a apresentar a distribuição dos diversos tipos de missão planejados.
O sistema também oferece poucos recursos ao trabalho cooperativo, uma vez que
o banco de dados do Dbase é local em cada máquina que opera com o software, resultando na
dificuldade de coordenar planejamentos realizados em paralelo pelos diversos grupos e na
impossibilidade de se dividir a atividade de planejamento dentro de um mesmo grupo. Outro
fator ainda relacionado com este aspecto é o pobre suporte a rede utilizado no Clipper Sum-
mer 87, que levou a se manter o uso de disquetes para o envio das informações até a versão
2.6.
Tais fatores levaram a ECEMAR a solicitar ao CCA-SJ a substituição desse soft-
ware por um novo sistema, levando à abertura do Projeto Marte.
Em associação com as atividades de Jogos de Guerra levadas a cabo na ECE-
MAR, ocorrem outras paralelamente, na Escola de Comando e Estado-Maior do Exército (E-
CEME), empregando um software específico para as necessidades da Força Terrestre, que
opera integrado ao Azuver, e na Escola de Guerra Naval (EGN), também com um sistema
específico para a atividade naval, o qual não possui integração com o da FAB.
Tendo em vista o interesse por sistemas que utilizem o meio aeroespacial para os
níveis Estratégico e Operacional, os jogos da Marinha e do Exército não serão discutidos nes-
54
te trabalho, passando-se à análise de sistemas congêneres em outros países, dentre os quais,
destaca-se, na América do Sul, o Chile, com o SIMAE38 (Simulador de Mando Aéreo).
3.2. Simulador de Mando Aéreo (SIMAE)
Este sistema foi desenvolvido pela Silicon Chilena e implantado na Academia de
Guerra Aérea.
Trata-se de um software que opera em ambiente gráfico UNIX (IRIX, da Silicon
Graphics), tendo sido desenvolvido orientado a objetos em C++, com 250.000 linhas de códi-
go, trabalhando com cartas ou imagens de satélites (raster) nas escalas entre 1:2.500.000 e
1:250.000, podendo aceitar qualquer cenário e apresentando o potencial de apresentação tri-
dimensional da Open GL.
O SIMAE possui ferramentas distintas para a criação dos cenários, para o plane-
jamento das missões, para a simulação e para o controle das atividades discentes, conforme a
arquitetura exposta na figura 3.2.
PARTIDOAZUL DIREÇÃO SALA MARTE SALA DOS
PROFESORES
GERÊNCIA DO SISTEMA
5
PARTIDOVERMELHO
5SCANNERUPS
Fig. 3.2 – Visão esquemática da arquitetura do SIMAE
38 SILICON GRAPHICS (Chile). Simulador de Mando Aéreo. [S. l.], [2001?] (folheto).
55
Trata-se de um software de dupla ação, com o qual cada partido faz seu planeja-
mento e o insere na simulação, a qual gera os resultados e realimenta novos planejamentos.
Todo esse ciclo é monitorado pelos árbitros e avaliadores, os quais podem, com o auxílio do
sistema, verificar a atuação individual e em equipe dos partidos e criticá-la posteriormente.
Este sistema aborda também as forças terrestres e navais, oferecendo um treina-
mento conjunto para estes três segmentos.
As documentações observadas não permitem concluir sobre a aderência à Doutri-
na Básica da FAB ou sobre os possíveis pontos de divergência ou de diferenças de aborda-
gem, tornando inviável uma avaliação a esse respeito. O material fornecido, no entanto, leva a
crer que não há provisões para o planejamento de todas as missões de apoio à força, embora
os fatores principais tenham sido abordados.
O material obtido sobre esse sistema também não permite inferir sobre como é
modelado o tratamento dos diversos eventos de combate.
As informações existentes permitem inferir que o software chileno possui alto
grau de flexibilidade na elaboração dos cenários, em termos de ambiente geográfico, de recur-
sos para as forças simuladas, entretanto, não é possível raciocinar-se com o grau com que no-
vas aeronaves e/ou armamentos inseridos podem ser tratados apropriadamente.
A grande virtude desse sistema é a integração dos esforços das três Forças Arma-
das numa única atividade, sedimentando uma doutrina de ação conjunta desde o tempo de
treinamento, associada à atuação em tempo real, que proporciona um maior realismo.
Informes verbais obtidos durante o Exercício CRUZEX (Exercício ocorrido em
2002, incluindo a FAB, a Armée de l’Air, a Fuerza Aérea Argentina e a Fuerza Aérea de Chi-
le) indicam que esse software opera de acordo com os processos adotados pela OTAN (Orga-
nização do Tratado do Atlântico Norte), os quais também estão em fase de adoção pela FAB,
a fim de poder participar de operações em coalizões, entretanto não se sabe as adaptações
feitas para a utilização dessa metodologia no contexto chileno.
Além do Chile, o grande líder da OTAN, os Estados Unidos, também possui sis-
temas de elevado interesse para análise, alguns dos quais desenvolvidos para entretenimento,
mas que também são utilizados para treinamento pelas forças armadas americanas, dentre os
quais se destaca o JFE (Joint Forces Employment – Emprego Conjunto de Forças), utilizado
56
pelo Defense Technical Information Center (DTIC39) para o treinamento da doutrina de em-
prego conjunto, sendo este o órgão central do Departamento de Defesa (DoD) americano para
a divulgação de informações doutrinárias, técnicas e científicas.
3.3. Joint Forces Employment (JFE)
Este sistema foi desenvolvido pela OC Incorporated para treinamento da doutrina
de emprego conjunto, a qual constitui o cerne da utilizada pela OTAN. Seu referencial é a
atuação do jogador como Comandante de Força-Tarefa Conjunta (Joint Task Force, JTF),
que, no caso americano, engloba meios da Força Aérea, da Marinha, do Exército e dos Fuzi-
leiros Navais.
O JFE é limitado a 10 cenários, dos quais apenas quatro podem ser modificados
pelo usuário do sistema.
O sistema apresenta um enfoque voltado a todas as Forças Armadas não apenas
em termos operacionais, mas também com um importante enfoque logístico, abordando tam-
bém problemas relativos a suprimentos e ao apoio de engenharia, viabilizando também um
enfoque integrado da aplicação do poder militar.
Trata-se de um jogo de dupla ação para apenas um usuário, onde o oponente é um
sistema com inteligência artificial.
Apesar de ter características eminentemente de jogos utilizados para entreteni-
mento, o JFE traz embutidos os conceitos doutrinários necessários ao comando de uma Força-
Tarefa Conjunta, tornando-se uma valiosa ferramenta para treinamento, uma vez que permite
o estudo e a aplicação prática da metodologia pregada pelo Departamento de Defesa america-
no de maneira bastante didática, chegando a possuir um modo de operação assistida pelo pró-
prio software, no qual o usuário recebe orientações do sistema, simplificando o entendimento
do emprego prático dos conceitos usados.
O JFE aborda todo o fluxo previsto pela doutrina americana de operação conjunta,
desde o fornecimento da missão e das regras de engajamento, passando pelas informações
obtidas pela inteligência até a ação propriamente ditas, enfocando ainda, antes do início de
39 O. C. INCORPORATED. Joint Force Employment User Manual. Washington, 2000. Baixado do site http://www.dtic.mil/doctrine/jfe/jfeman.pdf.
57
cada cenário, quais os conceitos-chave mais importantes que serão empregados, deixando ao
estrategista, atuando como Comandante de uma JTF, decidir como utilizar tais abstrações.
Existe, por trás disso, uma documentação muito bem elaborada em relação à ope-
ração do jogo e à doutrina subjacente ao mesmo, existindo também um modo tutorial, a fim
de preparar o usuário para utilizá-lo apropriadamente, o qual difere da operação assistida, uma
vez que, durante a utilização do tutorial, o usuário tem pouca participação no jogo, enquanto
que no modo de operação assistida, o sistema orienta o usuário que participa efetiva e direcio-
nadamente das ações.
Fig 3.3 – Tela de informações preliminares para a simulação.
Diferentemente do Azuver e do SIMAE, o JFC não oferece um conjunto de fer-
ramentas de software específicas para a criação de cenários, para a simulação e para os plane-
jamentos, provavelmente por ser concebido para operar localmente com um único usuário.
Dessa maneira, em uma única tela da simulação, aparecem graficamente as informações ne-
cessárias ao planejamento e ao acompanhamento das missões, conforme apresentado na fig.
3.4.
Tal conceito torna-se a causa da a sua principal limitação para emprego profissio-
nal – a falta de estímulo à ação do Estado-Maior do nível operacional como uma equipe, ou
58
seja, a impossibilidade de atuação de uma equipe para a sua operação. Este fato se deve à falta
de recursos que permitam uma atuação cooperativa dentro do Comando Operacional simula-
do.
Fig. 3.4 – Planejamento e acompanhamento da interação convivem na mesma tela
Embora se trate de um jogo predominantemente para entretenimento, este sistema
ilustra como a abordagem de hobby pode ser trazida para se elaborar jogos de guerra profis-
sionais atraentes e com fortes recursos didáticos para a sedimentação da doutrina preconizada
e dos aspectos de maior interesse para o treinamento, baseado, conforme mostrava Perla40 em
sua obra The Art of Wargaming, em uma documentação muito bem elaborada.
Aproveitando-se as lições apresentadas por cada um desses sistemas, em associa-
ção com os fundamentos expostos no Capítulo 2, tornam-se claras as idéias que sustentam a
abordagem proposta neste trabalho, fazendo-se necessário discutir a abordagem em si.
40 PERLA, Peter P. Op. Cit.
59
4. Desenvolvendo a abordagem
“Um dos primeiros praticantes de jogos de guerra do mundo, o Barão von Reisswitz, a-prendeu, no começo do século XIX, que o rei não apreciava esperar um ano para que um jogo de guerra estivesse pronto”.
(Cel Bobby J. Wilkes - USAF)
4.1. Uma Abordagem Aglutinadora
Seguir um processo de desenvolvimento aumenta a probabilidade de se obter sis-
temas apropriados, entretanto, a utilização de uma abordagem mais específica a determinados
casos, como os jogos de guerra, aumenta o poder do processo adotado, focalizando questões
críticas a tais softwares, evitando-se que o rei (ou alguma autoridade) espere para que o jogo
esteja pronto ou que os resultados estejam disponíveis.
Além dos diversos passos previstos no RUP, voltados ao desenvolvimento de um
software, torna-se vital inserir os elementos de um jogo de guerra citados por Perla41 (objeti-
vo, cenário, banco de dados, regras, modelos, jogadores e análise dos resultados), comple-
mentados com as questões de Vicente, já discutidas em 2.6, a cada Disciplina, a fim de se
desenvolver os artefatos apropriados à luz dos aspectos críticos para o desenvolvimento do
software, conforme exposto na fig. 4.1.
Elementos de um Jogo de Guerra
(Perla)
Disciplinas o RUPd
Fases do RUP
Fig. 4.1 – Visão esquemática da abordagem
60
É importante ressaltar que, em relação à figura 4.1, que as proporções entre as fa-
ses e disciplinas do RUP continuam exatamente como no diagrama apresentado na fig. 2.13,
entretanto, tais variações não ocorrem da mesma forma, no que se refere aos planos que inclu-
em os elementos específicos dos Jogos de Guerra.
4.1.1 Negócio
Durante a modelagem de negócio, onde, segundo Gordijin, Akkermans e van Vli-
et42, são levantados os fluxos de valor e quais são os valores que circulam dentro do negócio,
já começam a ser abordados como os diversos aspectos necessários ao projeto de um jogo de
guerra são afetados pelo negócio (atuação de um Comando de nível Operacional ou Estratégi-
co).
Essencialmente, na modelagem de negócio de um jogo de guerra serão levantados
os objetivos, a organização da atividade num Comando Operacional ou Estratégico, o vocabu-
lário utilizado e os comportamentos esperados dos partidos e do Grupo de Controle (GRU-
CON), em termos de troca de informações, as quais constituirão os valores que circularão
nesse tipo de sistema.
Vale a pena ressaltar que o enfoque duplo de analisar-se tanto a atividade real a
nível de negócio quanto o jogo em si fornece dois aspectos vitais para o levantamento posteri-
or de requisitos – o que ocorre na atividade real (em relação à atuação do Comando) e o que
se pretende enfocar (em relação ao treinamento pretendido com o jogo, raciocinando-se com
um jogo manual em relação às ações dos jogadores e das análises necessárias).
Torna-se essencial lembrar da importância das fases do jogo: preparação (quando
o GRUCON gera o ambiente (cenário, parametriza a simulação e atualiza o banco de dados)
onde se desenrolarão as ações), planejamento (quando os partidos levantam a situação criada
e planejam suas estratégias), interação (quando os planejamentos são confrontados, com base
nas regras e nos modelos, e o resultado é obtido) e análise (que envolve os partidos, para novo
planejamento, e o GRUCON, para verificação do desempenho dos partidos).
Assim, os fatores modelo, responsável pelo tratamento dos diversos eventos do
jogo, e regras, voltadas à orientação de quando ocorrerão os diversos eventos e a interligação
entre os mesmos, serão também vitais para o sistema, demandando um valioso esforço inicial.
41 PERLA, Peter P. Op. Cit.
42 GORDIJIN, Jaap, AKKERMANS, Hans, VAN VLIET, Hans. Business Modelling is not Process Modelling. Amsterdan: Vrije Universitat, [2001?].
61
Nessa oportunidade, buscando facilitar o entendimento do fluxo de valores e a in-
ter-relação entre estes dentro dos casos de uso de negócio, torna-se oportuna a modelagem
com uso de diagramas de causa e efeito, a fim de explicar o impacto das decisões dos jogado-
res e/ou do GRUCON sobre o jogo.
4.1.2 Requisitos
Tendo em vista de atender às necessidades dos interessados, que, no caso de jogos
de guerra profissionais incluem também, além dos jogadores, o GRUCON e outros envolvi-
dos na atividade, torna-se essencial um levantamento dos anseios de cada grupo e, eventual-
mente, a realização de um desconflito de posições incompatíveis e/ou priorização de interes-
ses.
Esse levantamento deverá perguntar, além do esperado no RUP, os aspectos parti-
culares:
4.1.2.1 Objetivos
- Quais os objetivos dos envolvidos em relação ao sistema?
- Há conflito entre os interesses?
- Quais as prioridades entre os objetivos?
4.1.2.2 Cenário
- Quais as necessidades dos interessados em relação ao cenário? Esta pergunta
pode envolver mais que apenas o ambiente geográfico onde são realizados os exercícios, a-
bordando também os sistemas de armas existentes, sensores e características geopolíticas e
psicossociais.
- Quais as missões serão simuladas?
- Haverá apenas um ou vários tipos de organizações nos países beligerantes?
- Que fatores do cenário devem ser definidos e quando?
62
4.1.2.3 Banco de Dados
- Que dados são necessários para o cenário, para a análise e para as interações e
o que se deve fazer para que os mesmos se transformam nas informações necessárias?
- Que dados são necessários para a descrição qualitativa dos eventos do jogo?
4.1.2.4 Modelos
- Quais as necessidades dos eventos em termos de entrada e saída de dados? O
que cada evento deve fazer?
- Há restrições de desempenho ou de recursos de hardware?
- Qual a cinemática dos objetos móveis? Qual a representação desejada?
- Haverá interação com os jogadores durante a simulação ou será somente um
confronto de planejamentos?
- Qual o comportamento de sensores, armas, comunicações, logística, segurança
e defesa e inteligência em cada um dos eventos?
- Quais os aspectos de cada evento que necessitam de parâmetros aleatórios?
4.1.2.5 Regras
- Quais as regras de negócio que precisam ser informatizadas? Verificar também
quais podem ser implementadas.
- Quais as seqüências de eventos de cada missão? Como eles se inter-relacionam
numa mesma missão?
- Quais as decisões dos jogadores que não devem ser permitidas? Qual deve ser
o tratamento de tais erros?
- Qual deve ser a atuação do GRUCON nos resultados?
- Quais os graus de acesso às informações dos demais interessados além dos jo-
gadores e do GRUCON?
- Que verificações o sistema deve fazer ao final de cada fase (geração de ambi-
ente, planejamento, interação e análise), a fim de minimizar a ocorrência de erros sem afetar a
realidade?
63
4.1.2.6 Jogadores
- Quais as informações a serem produzidas pelos diversos jogadores?
- Quais informações que cada jogador necessita para seus processos? Quais as
restrições a ser-lhes impostas? Que variações a situação pode impor a essas restrições?
- Qual o nível de conhecimento dos jogadores no início da operação do softwa-
re?
- Qual o nível de detalhamento desejado para a documentação e para a documen-
tação online do sistema?
4.1.2.7 Análise
- Que fatores norteiam a crítica?
- Quais os indicadores associados a esses fatores?
- Quais os dados necessários à análise e o que deve ser feito para transformá-los
em informação?
Ressaltando-se que apenas os usuários do sistema serão os atores humanos e que
os diversos casos de uso que nortearão o desenvolvimento do software resultarão da interação
dessas pessoas com o sistema, tornando também essencial a especificação da arquitetura a-
propriada ao atendimento das necessidades levantadas.
4.1.2 Análise e Projeto
Duas das atividades do RUP são vitais nessa fase - a definição da arquitetura can-
didata e a análise do comportamento.
No primeiro caso, a definição preliminar de alto nível do sistema é bastante sensí-
vel aos elementos do jogo. Inicialmente, porque o objetivo responde a diversas perguntas vi-
tais para a arquitetura:
- Como é o ambiente em que se pretende operar o software (stand-alone, rede
local ou internet/intranet)?
- Os interesses da atividade estão voltados ao treinamento de planejamento, de
supervisão da execução (operações correntes) ou de ambos?
64
- Há interesse que o Estado-Maior e o Comandante atuem efetivamente como
uma equipe?
- Há interesse na criação de cenários ou no uso de cenários fixos?
- Há interesse na comunicação do GRUCON com os jogadores?
- Há interesse no controle dos resultados?
- Em que consiste a análise de resultados e onde estão seus interessados?
- Há necessidade de integração com outros jogos? Qual o interesse dessa inte-
gração?
Tais perguntas, respondidas dentro do objetivo e aspectos a ele afetos oferecem
uma visão geral de aspectos vitais para a arquitetura do software, como, por exemplo, o ambi-
ente indicará a distribuição do sistema, o interesse no trabalho em equipe, cenários e troca de
mensagens resulta na construção de diversos subsistemas para a geração de cenários, para a
instalação das ferramentas de planejamento, de mensagens, e de coordenação de planejamen-
tos.
Ao se dizer que os interesses do treinamento visam ao planejamento ou à supervi-
são da execução, especifica-se o grau de interatividade necessário à simulação, uma vez que
simulações voltadas apenas ao confronto de planejamentos podem processá-los em lote, en-
quanto que simulações com os dois enfoques ou voltadas à supervisão da execução exigem
que as missões sejam simuladas dentro de elementos constantes de tempo. Assim, os interes-
ses de treinamento definem como será a gerência do tempo na simulação.
O controle de resultados define a necessidade de um subsistema específico, ligado
à simulação, a fim de permitir uma re-simulação a partir de modificações em um determinado
evento. Tal re-simulação teria início no ponto onde houve mudança.
A análise de resultados define se haverá uma ferramenta específica e suas caracte-
rísticas (distribuição, capacidade de exportar dados, interação com outros sistemas)
A necessidade de integração pode determinar a criação de subsistema específico
para atuar como interface para os outros sistemas. Os requisitos não-funcionais ligados à in-
terligação fornecem pistas a respeito de como serão as características da conexão entre eles.
O cenário, por definir o ambiente espacial do jogo, arquiteturalmente possui im-
pacto na existência ou não de ferramentas específicas para a montagem do mesmo, conforme
65
já discutido, entretanto, em relação comportamento, há outros aspectos que merecem uma
análise mais cuidadosa:
- Que sistema(s) de coordenada(s) geográfica(s) será(ão) utilizado(s)?
- Que tipo de cartas, escalas e projeções serão necessários?
- Há necessidade de visualização dinâmica da simulação?
- Quais os subsistemas que necessitam da apresentação do cenário? Quais os re-
quisitos especificados para cada um desses subsistemas?
O Banco de Dados pouco afeta a arquitetura, exceto quanto a onde se encontram
aqueles que necessitam de seu conteúdo, conforme discutido anteriormente. Em relação ao
comportamento, ele é afetado estruturalmente pelas necessidades de persistência dos demais
fatores, principalmente do cenário e das conseqüências do modelo.
O modelo, calcado nos requisitos já definidos nessa fase, tem um alto grau de im-
pacto no tipo de simulação a ser escolhido, na seleção dos recursos necessários para atender
às possíveis necessidades de distribuição. Outro fator importante em relação ao modelo é o
tratamento da interface com outros sistemas com os quais trocará informações, principalmente
no que se tratar de importar e exportar dados (diferentes tecnologias de armazenamento, re-
cursos para comunicações, sistemas de medidas e/ou sistemas de coordenadas utilizados) e em
termos de gerência de tempo, demandando um tratamento específico para tal.
Em termos de comportamento, existe também outra grande contribuição do mode-
lo – definindo o que será levado em conta nas interações dos diversos elementos de manobra
(aeronaves, veículos blindados ou não e/ou embarcações) existentes no cenário, movidos por
suas missões, e seus impactos na evolução do jogo. Nesse momento, serão levados em conta
os diagramas de causa e efeito elaborados na análise de negócio, a fim de nortear a análise do
comportamento.
À medida que tal análise avança, são também estabelecidos os aspectos persisten-
tes do software, viabilizando o projeto do Banco de Dados de maneira a apoiar eficientemente
o funcionamento do sistema.
Baseado no comportamento necessário, obtido durante a modelagem do negócio e
o levantamento de requisitos, torna-se possível extrair as regras de verossimilhança, as quais
viabilizarão a definição do comportamento de maneira realista, mesmo na falta de um conjun-
66
to de dados estatísticos suficientemente confiável, com base na lógica nebulosa, que será dis-
cutido em 4.2.
Outro fator do modelo que também merece uma abordagem específica, em relação
ao comportamento, é a definição de onde serão empregados os fatores aleatórios em cada e-
vento, a fim de emular as incertezas do conflito, devendo também se rever as informações das
disciplinas anteriores, de onde é possível mapear-se tais necessidades para cada situação.
As regras oferecem uma visão essencialmente comportamental, tendo pouca in-
fluência no conjunto das ferramentas em si, porém definirão todas as limitações dos planeja-
mentos, da elaboração dos cenários, da interação em si e dos fatores relacionados com a análi-
se do jogo.
Torna-se, portanto, vital mapear-se a aplicação das regras (que a esta altura já es-
tarão definidas dentro dos diversos casos de uso) para o comportamento do sistema na elabo-
ração dos cenários iniciais, para a elaboração dos planejamentos, para as simulações das di-
versas missões, da interação entre estas e das conseqüências das mesmas para os resultados.
As regras também regerão a análise, permitindo verificar a aplicação da doutrina por cada
partido.
Os jogadores influenciarão a arquitetura na medida que seu afastamento ou não
entre si, dos sistemas com os quais o software será integrado em termos de planejamento, do
Banco de Dados, de um servidor de aplicação (se necessário) e/ou de um possível servidor de
simulação tornarem necessária a utilização de recursos específicos para atender a essas neces-
sidades, quer em relação ao uso de redes locais ou de outras estruturas distribuídas.
Outro fator de interesse ainda em relação aos jogadores será em relação à impor-
tância dada ao trabalho integrado em equipe. Tal necessidade levará à criação de subsistemas
que permitam a visualização e a coordenação de todo o trabalho do Estado-Maior na fase de
planejamento.
Este aspecto também tem profundo impacto no comportamento, uma vez que tal
cooperação pode facilitar a coordenação de diversas missões, resultando em alto grau de si-
nergia. Como exemplo, o planejador das missões de ataque que necessite de reabastecimento
em vôo pode acessar os planejamentos feitos por outro elemento do Estado-Maior que conte-
nham essas missões e preparar os ataques com base nos planejamentos existentes ou solicitar
ao planejador de REVO que crie missões numa área de interesse específico.
67
Surge também outro fator importante com relação aos jogadores, que é relativo à
documentação online e/ou impressa a ser empregada, que recursos oferecerá e em que mo-
mentos serão disponibilizados. Desta forma serão planejadas as ferramentas para operação
assistida pelo sistema, tutoriais, manuais e/ou help online, se julgados necessários, conforme
já especificado nos requisitos.
A influência da análise na arquitetura também se refere à separação ou não dos in-
teressados nas informações produzidas da área onde ocorrerá a simulação, gerando ou não a
necessidade de distribuição.
Em relação ao comportamento, com base nos casos de uso gerados, o comporta-
mento planejado também será traduzido nos diagramas de interação que viabilizarão a elabo-
rar os relatórios e/ou gráficos desejados.
Durante o projeto, tornam-se visíveis os algoritmos mais apropriados principal-
mente para a simulação, a fim de não comprometer o desempenho da mesma frente aos requi-
sitos não-funcionais estabelecidos, fornecendo-se os insumos necessários à atividade de im-
plementação.
4.1.3 Implementação
Embora com pouca influência, por já haver definido vários aspectos previamente,
o(s) objetivo(s) é(são) ainda um ponto de referência para o esclarecimento de dúvidas quanto
a que aspecto priorizar ou penalizar na hora da tomada das decisões de compromisso.
Semelhantemente ao objetivo, o cenário e o banco de dados já possuem diversos
fatores definidos, servindo de base para as decisões de implementação ou para os refinamen-
tos necessários.
As regras e os modelos ainda dão margem a diversas decisões importantes em
termos de seleção de algoritmos para as diversas ferramentas (se forem necessárias), exigindo
uma análise cuidadosa em relação aos requisitos não-funcionais estabelecidos no que toca a
segurança e desempenho.
Embora a codificação das ferramentas para os jogadores ofereça pouca margem
para decisões importantes a nível de implementação, faz-se mister lembrar que a conseqüên-
cia da utilização de operação assistida é a necessidade do emprego de técnicas de Inteligência
Artificial, a fim de acompanhar-se as ações dos jogadores e criticá-las frente a um padrão
68
doutrinariamente correto, demandando o emprego de implementadores familiarizados com tal
conhecimento.
A influência da análise sobre a implementação também é bastante reduzida, vindo
indiretamente das disciplinas anteriores, vindo também a servir de base para as poucas deci-
sões necessárias.
4.1.4 Testes
São indiretamente influenciados pela análise dos diversos fatores estabelecidos
nos requisitos. As respostas ali definidas e as decisões tomadas deverão ser mapeadas para os
casos de testes e, por meio destes, verificadas no sistema.
Ressalta-se que essas respostas deverão abranger tanto os requisitos funcionais, li-
gados aos casos de uso, quanto os não-funcionais especificados.
Torna-se também fundamental uma crítica em relação à documentação colocada à
disposição, a fim de que todos os procedimentos necessários estejam claros para os usuários
de cada ferramenta produzida.
Nesse sentido, recomenda-se a participação de representantes dos diversos usuá-
rios para a verificação da documentação e das ferramentas de análise, a fim de também detec-
tar possíveis distorções relativas ao enfoque e/ou ao vocabulário utilizado.
Além das disciplinas, tendo em vista o sentido tridimensional da abordagem, tor-
na-se importante discuti-lo também em relação às fases do processo de desenvolvimento.
4.1.5 Elementos x Fases
Na Concepção, quando é definido um conceito de alto nível do sistema, permitin-
do o mapeamento dos principais riscos, todos os fatores do jogo são importantes, demandando
elevado esforço em relação a todos os elementos.
Na Elaboração, quando são atacados os principais riscos voltados ao núcleo ar-
quitetural, apenas o enfoque no objetivo é reduzido, embora ainda seja elevado, por já haver
sido bastante discutido na fase anterior, enquanto os demais são detalhados em relação à ar-
quitetura candidata e seus riscos inerentes.
Na Construção, a ênfase no objetivo, no cenário, no banco de dados e na análise é
reduzida, concentrando-se especificamente, em relação ao cenário, ao banco de dados e à aná-
lise, na implementação do que foi anteriormente planejado. A ênfase predominante nos mode-
69
los e nas regras se justifica pelo detalhamento dos diversos eventos que serão especificamente
projetados e implementados, juntamente com a integração destes ao sistema via regras. A im-
portância das regras também se justifica por determinar as limitações dos diversos fatores
envolvidos em cada subsistema. O forte enfoque nos jogadores se deve à elaboração da do-
cumentação e ao esforço empregado na realização de testes.
Na Transição, tendo em vista a necessidade de se treinar os usuários (grupo que
inclui os jogadores e o GRUCON), há uma grande ênfase em relação ao cenário, às regras,
aos jogadores e à análise, sendo também realizados os testes de aceitação do sistema, nos
quais os usuários constatam, em seu ambiente de operação, os resultados já observados nos
testes anteriores.
Tendo em vista a importância da aceitação do sistema por parte dos usuários, exis-
te a necessidade de se discutir especificamente um fator que causa grande quantidade de pro-
blemas para a credibilidade do sistema – o modelo utilizado – demandando o uso de recursos
que lhe confiram o grau apropriado de realismo sem aumentar muito a complexidade do
mesmo.
4.2. Aplicando a Lógica Nebulosa aos Eventos
Buscando dar ao modelo a simplicidade necessária para um alto desempenho sem
comprometer o realismo, buscou-se a utilização das regras de verossimilhança do próprio mo-
delo como base para a simplificação do modelo baseada na lógica nebulosa ou fuzzy.
Conforme já abordado em 2.8, a lógica nebulosa simplifica o sistema, dando ao
mesmo um tratamento quantitativo a informações qualitativas, auxiliando principalmente na
montagem de um modelo de combates apesar da falta de informações estatísticas, utilizando
apenas as regras de verossimilhança já conhecidas do levantamento de negócio.
Com base nesses fatores, cada evento empregará a lógica nebulosa de um modo
específico, coerentemente com os requisitos estabelecidos nos casos de uso.
Tendo em vista a constante utilização de tal recurso pelos vários eventos, torna-se
recomendável, com base nas recomendações de Page-Jones43 quanto à reusabilidade das clas-
ses, o encapsulamento do tratamento dessas informações em uma classe específica, que efetue
43 PAGE-JONES, Meilir. Op. Cit.
70
os cálculos necessários e retorne ao sistema as respostas apropriadas, simplificando a imple-
mentação do software como um todo e aumentando o potencial de reutilização do código pro-
duzido.
Cada evento deverá também constituir uma classe que trate as regras de verossi-
milhança que o regem, utilizando-se da colaboração da classe que implementa a lógica nebu-
losa para a aplicação das regras, calculando os fatores probabilísticos envolvidos, e de uma
classe que empregue pseudo-aleatórios para, com base nas probabilidades obtidas, gerar a
resposta (detectou ou não detectou, abateu ou não abateu, etc.).
Objetivando facilitar a obtenção das regras de verossimilhança, pode-se gerar um
diagrama de causa e efeito ligado ao evento, o qual torna mais claro o levantamento dos fato-
res envolvidos de acordo com a granularidade desejada do modelo em desenvolvimento.
Como exemplo, um evento referente à detecção de aeronaves por um radar de de-
fesa aérea, sem levar em conta todos possíveis fatores envolvidos, terá como entrada as aero-
naves incursoras e o radar que fará a detecção e, como saída terá a resposta sim ou não, tendo
suas regras extraídas do diagrama de causa e efeito apresentado na fig. 4.2.
+-
nível de
naves; qu
teção ele
similhan
Capacidade de CMEdos incursores
+
Nível de Vôo Probabilidade de Detecção
+
ent
an
trô
ça
Quantidade de Aeronaves
Fig. 4.2 – Diagrama de Causa e Efeito associado à detecçã
Para se obter essa saída, torna-se necessário saber, em
rada, sua capacidade de contramedidas eletrônicas (CM
to ao radar defensor, faz-se mister conhecer a capacida
nica nele disponíveis. Baseado nesses fatores, pode-se
para tal evento:
Capacidade de MPE do radar
o de aeronaves
relação aos incursores, seu
E) e a quantidade de aero-
de de suas medidas de pro-
aplicar as regras de veros-
71
- Se o nível é alto, a probabilidade de detecção é alta, se o nível é médio, a pro-
babilidade detecção é média, se o nível é baixo, a probabilidade de detecção é
baixa.
- Se a capacidade dos sistemas de CME é alta, a probabilidade de detecção é
baixa; se a capacidade de contramedidas eletrônicas é média, a probabilidade
de detecção é média; se a capacidade dos sistemas de CME é baixa, a probabi-
lidade de detecção é baixa.
- Se a quantidade de aeronaves é alta, a probabilidade de detecção é alta; se há
média quantidade de aeronaves, a probabilidade de detecção é média; se exis-
tem poucos incursores, a probabilidade de detecção é baixa.
- Se o radar possui um excelente equipamento de medidas de proteção eletrôni-
ca, a probabilidade de detecção é alta; se possuir de média capacidade, a pro-
babilidade de detecção será média; se possuir recursos de fraca capacidade, a
probabilidade de detecção será baixa.
Com base na abstração das regras expostas acima, pode-se aplicar a lógica nebu-
losa, conforme o exposto em 2.8., para a concepção da classe que realizará tais cálculos, a
qual deve ser genérica e flexível o bastante para aceitar dados e fornecer resultados adaptáveis
a qualquer contexto, oferecendo como resultado um parâmetro que pode ser devidamente tra-
tado por qualquer evento que utilize a lógica nebulosa.
Para que tal seja possível, faz-se mister que o evento também trate as regras de
uma forma agrupada, ou seja:
- Se o nível é alto, se a quantidade de aeronaves é alta, se a capacidade de CME
dos incursores é baixa ou se a capacidade de MPE do radar é alta, então a pro-
babilidade de detecção é ALTA.
- Se o nível é médio, se a quantidade de aeronaves é média, se a capacidade de
CME dos incursores é média ou se a capacidade de MPE do radar é média, en-
tão a probabilidade de detecção é MÉDIA.
- Se o nível é baixo, se a quantidade de aeronaves é baixa, se a capacidade de
CME dos incursores é alta ou se a capacidade de MPE do radar é baixa, então
a probabilidade de detecção é BAIXA.
72
Surge, provavelmente, no pensamento de qualquer um que leia essas regras a dú-
vida a respeito da definição de alto, médio e baixo. Tal definição embora pareça um ponto
frágil desta abordagem é, na realidade seu ponto mais forte, pois proporciona elevado grau de
flexibilidade por permitir que os parâmetros que definem tais adjetivos sejam tratados no ní-
vel de código dos objetos ou, ainda, no nível de banco de dados associado ao código dos obje-
tos. No primeiro caso, as definições serão mais rígidas por estarem presas ao código, enquanto
que, no segundo, por estarem inseridas num contexto de banco de dados, referentes a um de-
terminado cenário, permitirão que os objetos carreguem os parâmetros a ele apropriados, ob-
tendo-se, assim, maior flexibilidade.
Uma vez que o evento obtenha o resultado, obtém-se apenas a probabilidade de
detecção, faltando saber se ela ocorreu ou não. Para obter-se essa resposta, torna-se necessário
aplicar os métodos de Monte Carlo ou a esperança matemática. A esperança matemática mos-
tra-se mais apropriada para ferramentas de planejamento, uma vez que expressa a média das
ocorrências esperadas em relação à probabilidade obtida, enquanto que a utilização dos méto-
dos de Monte Carlo permite o emprego de variáveis aleatórias de acordo com a faixa de pro-
babilidade definida.
Além dos combates e confrontos de forças, há necessidade de estabelecer-se um
método para tratar os eventos voltados à logística.
4.3. Eventos Logísticos – Uma questão de Tempo e de Conseqüências
A Logística envolve diversos aspectos, ligados a Pessoal (Recursos Humanos e
Saúde), Material (Suprimento e Manutenção) e a Serviços (Transporte e Engenharia), sendo
necessária uma abordagem específica para cada um, obtida junto a especialistas das áreas.
4.3.1 Recursos Humanos
O tratamento dos fatores ligados a efetivos pode resumir-se às conseqüências dos
ataques (mortos e feridos), dos combates (as aeronaves abatidas poderão ter, como conse-
qüências, mortos, ilesos e/ou feridos resultantes do abandono das mesmas) e dos recompleta-
mentos, que podem baixar o nível de treinamento das Unidades, uma vez que serão recebidos
combatentes com pouca experiência, resultando em menor nível de aproveitamento nas mis-
sões de combate, conforme exposto na fig. 4.3.
73
Ataques inimigos com êxito
Tempo de Atendimento
+
+
Pedidos de Re-completamento -
-
Nível de treinamen-to
+Recompletamentos
-
Efetivo
+Combates
-
+
Baixas (mortos e/ou feridos)
Fig. 4.3 - Diagrama de Causa e Efeito referente aos efetivos
4.3.2 Saúde
A recuperação do pessoal operacional é conseqüência do nível do ferimento (feri-
dos graves sairão do Teatro de Operações), permitindo que, nesse sentido, um Hospital de
Campanha (H Campo) possa ser tratado como uma fila.
Existe ainda o aspecto de consumo, ligado ao consumo de material hospitalar, o
qual é influenciado pela quantidade e pelo nível dos ferimentos do pessoal ali em tratamento.
O aumento do consumo reduz o nível de estoque do H Camp, podendo tanto aumentar o tem-
po de recuperação dos feridos quanto a probabilidade de mortes pela falta tempestiva do ma-
terial necessário, conforme ilustrado na fig. 4.4.
74
- Baixas (feridos leves ou médios)
Efer
Estoque de Material hospitalar
-
+
N° de Remoções
+
-
+
-
Consumo derial hospi
+
Baixas (feridos graves ou mortos)
-
Fig. 4.4 – Diagrama de C
Os pacientes graves estão exc
H Camp (exigiriam missões de Evacuaçã
os mortos também sairão do escopo do m
ro, demandando missões de transporte aér
Para este modelo, há necessid
fatores estocásticos, os quais estão ligado
po de recuperação dos feridos leves e/ou m
- Em relação à probabilida
- Se o estoque de material h
alta;
- Se o estoque de material
média, então, a probabilid
Número de Pacientes Hospitalizados
tivo Ope-acional
+
mate-talar
ausa e Efeito
luídos, por
o Aeroméd
odelo, send
eo logístico
ade de se e
s às mortes
édios.
de de morte
ospitalar é
hospitalar
ade de mor
+
+
Tempo de Recuperação
Probabilidade de mortes
Gravidade dosferimentos
associado a um H Camp
saírem da capacidade de atendimento dos
ica, EVAM, para tal). Semelhantemente,
o enviados à Zona do Interior para enter-
.
specificar melhor as regras associadas aos
durante o atendimento hospitalar e tem-
s:
baixo, então, a probabilidade de mortes é
é médio ou a gravidade dos ferimentos é
tes é média; ou
75
- Se o estoque de material hospitalar é alto ou a gravidade dos ferimentos é bai-
xa, então, a probabilidade de mortes é baixa.
- Em relação ao tempo de recuperação de feridos:
- Se o estoque de material hospitalar é baixo ou a gravidade do ferimento é alta,
então, o tempo de recuperação será alto;
- Se o estoque de material hospitalar é médio ou a gravidade do ferimento é
média, então, o tempo de recuperação será médio; ou
- Se o estoque de material hospitalar é alto ou a gravidade do ferimento é baixa,
então, o tempo de recuperação será baixo.
4.3.3 Suprimento
A atividade de suprimento terá um tratamento dependente do tipo de material em-
pregado.
Assim, a atividade de suprimento de material de aviação pode ser tratada pelo
consumo proporcional às horas voadas pelas missões e às panes, enquanto a atividade de su-
primento de material bélico de aviação deve ser tratada por surtida e, de acordo com o resul-
tado de cada uma, poderá haver um consumo diferente, causado por combates ou pelo alija-
mento de parte do armamento utilizado.
O suprimento de material de saúde foi discutido em 4.3.2.
Quanto ao material bélico da defesa terrestre, o consumo do mesmo será devido
aos combates para autodefesa antiaérea ou para defesa contra guerrilheiros, sabotadores e/ou
forças especiais.
Quanto aos víveres e outros materiais, o consumo pode ser tratado por dia, em
função do pessoal e/ou equipamentos em operação no local que deles necessitam, conforme
ilustrado na fig. 4.5. Nesse caso, com o objetivo de se dar maior realismo à situação, pode-se
tratar o consumo diário de maneira estocástica, dando-lhe uma probabilidade máxima de co-
incidir com o consumo médio diário e o restante da probabilidade ser distribuído, de acordo
com a conveniência didática ou do treinamento para o cenário, dentro de uma pequena mar-
gem de variação.
76
Consumo diário Nível do Estoque
-
Ações de Ressupri-mento
+
Efetivo ou quan-tidade de equi-
pamentos
+N° de surtidas
+
N° de Pedidos
+Tempo de Pedido
e Remessa
+
+
Fig. 4.5 – Consumo de víveres ou materiais de apoio
Outro fator de elevada importância em relação ao exposto na fig. 4.5 é a influên-
cia do Tempo de Pedido e Remessa, o qual limita a eficiência dos pedidos, uma vez que have-
rá um tempo entre o pedido e a chegada do material para emprego.
4.3.4 Manutenção
A atividade de manutenção terá um tratamento específico em relação ao tipo de
equipamento analisado.
A fig. 4.6 modela as atividades de manutenção de aeronaves como exemplo para
as demais atividades de manutenção.
77
+
N° de surtidas +
Tempo de Reparo N° de Inspeções
-N° de Aeronaves
Disponíveis
N° de Panes ou Avarias
+
-
Atividades de Manutenção
Solicitação de aeronaves
+
-
-
+N° de Aeronaves abatidas
Consumo de Material de Aviação+
-
*
* Tempo de processamento e atendimento das solicitações
Fig. 4.6 Modelagem das Atividades de Manutenção
Ressalta-se que os dois ciclos que permitem a recomposição da quantidade de ae-
ronaves disponíveis têm uma demanda por tempo, tanto para a manutenção quanto para a re-
posição das mesmas, exigindo que as solicitações de aeronaves tenham um grau de antecipa-
ção compatível com os valores do tempo de processamento e de atendimento.
O tempo de reparo também pode ser tratado com base em regras fuzzy, levando-se
em conta a profundidade das avarias ou a complexidade da inspeção. Assim, avarias e inspe-
ções profundas necessitarão de maior tempo de reparo e de mais materiais de aviação, conec-
tando esse diagrama com o de suprimento.
78
4.3.5 Engenharia
A atividade de Engenharia terá um tratamento voltado ao controle de danos, à
construção e à manutenção de instalações.
A fig. 4.7 modela as seqüências de causa e efeito ligadas às atividades de enge-
nharia, voltadas ao controle de danos.
Tempo de Obra
-
+
Atividades de Recuperação
+Consumo de material
+
Disponibilidade de material
Diferença Dano x Recuperação
Extensão do Dano
- +
Fig. 4.7 - Seqüência de Causa e Efeito ligada às atividades de controle de danos
Ressalta-se a sensibilidade desse modelo ao tempo de obra e à disponibilidade do
material, permitindo a conexão deste diagrama com o de suprimento.
Implicitamente, o modelo também é sensível à quantidade e à capacidade dos re-
cursos humanos e materiais utilizados para as atividades de recuperação da instalação danifi-
cada, os quais são expressos por meio do tempo de obra. O tempo de obra também pode ter
um tratamento probabilístico em torno da média esperada com pequenas diferenças especifi-
cadas em função das necessidades do treinamento.
79
4.3.6 Transporte
A atividade de Transporte será sensível ao meio utilizado, à produtividade do
mesmo para chegar ao destino, à disponibilidade dele e ao tempo de transporte.
+Material/Pessoal
para envio
Necessidade de Meios
+
+
-
Tempo de Transpor
F
Impli
transporte em rel
tempo de transpo
O tem
que é possível c
teria a maior prob
da rede de transp
ções da mesma.
Além
necessitam ser m
dagem.
4.4. Segurança
Os co
racionais e/ou lo
sabotadores e/ou
Diferença entregue x a entregar
Difcaçã
- N° de pernas +
-
te
ig. 4.8 – Diagrama de Causa e Efeito das atividades
citamente também é apresentada, na fig. 4.8, a s
ação à velocidade do meio e à distância, as quais
rte.
po de transporte pode também ser tratado de m
riar-se pequenas variações em torno do tempo
abilidade de ocorrer. Outro fator que pode ser ta
ortes utilizada, definindo o tempo de transporte
da Logística, as atividades de Segurança e Def
odeladas, a fim de poderem ser incluídas num s
e Defesa
mbates com forças terrestres de infantaria para
gísticas serão travados contra Forças Especiais
contra insurgentes do próprio país simulado.
Disponibilidade de Meios
erença Alo-o x Disponi-bilidade
de tran
ensib
são e
aneir
médio
mbém
como
esa d
istem
a defe
inim
Produtividade do Meio utilizado
sporte
ilidade da atividade de
xpressas em termos de
a estocástica, uma vez
de transporte, o qual
simulado é a situação
dependente das condi-
as instalações também
a que utilize esta abor-
sa de instalações ope-
igas infiltradas, contra
80
Tendo em vista este trabalho não abordar os aspectos morais ligados às forças
combatentes, serão modelados apenas os fatores ligados à quantidade, ao equipamento, ao
treinamento, à mobilidade, ao apoio aéreo e ao fator surpresa, apresentados na fig. 4.9.
Qualidade do Equipamento +
Qualidade do treinamento
Grau de mobili-dade
Quantidade de Pessoal/Material
Fator Surpresa
Potencial Absoluto
+
+
-
-
-
-
+
++
Nível de Danos -
Fig. 4.9 - Diagrama de Causa e Efeito das Atividades de Segurança e Defesa p
Ressalta-se que o potencial absoluto dependerá exclusivamen
enquanto que as probabilidades de empate e de vitória também levarão
absoluto do adversário. Cada potencial absoluto deve ser trabalhado na
fim de facilitar os cálculos da distribuição proporcional de probabilidade
Uma vez definidas as probabilidades, emprega-se um valor p
0 e 100 num continuum de 100%, dividido em partes correspondentes às
se definir os resultados do combate, conforme o apresentado na fig. 4.10.
Probabilidade de Vitória
ara confronto terrestre
te da tropa analisada,
em conta o potencial
faixa de 0 a 100%, a
.
seudo-aleatório entre
probabilidades, para
81 Potencial Absoluto dos
defensores (PAD) 0 a 100%
Potencial Absoluto dos atacantes (PAA)
0 a 100%
-
Probabilidade de Vitó-
o re78.
par
mo
três
Probabilidade de Vitóriados atacantes P(A)
P(A) + P(E) + P(D) = 100Empregando-se pseudo-al
sultado. Supondo-se X = 48, Y = 78
Fig. 4.10
Finalmente, para se ob
a cada peça de manobra envol
da simulação com mais um m
casos a se considerar, aplican
- Caso a vitória seja
obtida, devendo-s
te. Para os defens
em combate pela d
- Caso ocorra empa
dos, calcado no va
- Caso a vitória sej
entre 100% e o v
cantes, as perdas s
Probabilidade de Empate P(E)
Potencial de Empate (PE) = 100 - |PAD – PAA|
ria dos defensores P(D)
0 % eatór, com– C
ter
vida
étod
do-s
do
e mu
ores
ifer
te,
lor
a do
alor
erão
X
ios, verifica-se a qu um valor obtido de
álculo do Resultad
o resultado final
de cada lado, en
o da ordem Ο(n
e um tratamento
s atacantes: as p
ltiplica-la pelos
, as perdas serão
ença entre 100%
considera-se o m
obtido; e
s defensores: as
obtido, multipli
o valor obtido m
Y
al faixa pertence o resultado 55, resulta em empate, por
o dos confrontos
, poderia ser aplicado o
tretanto tal opção pen
). Outra alternativa seri
semelhante à esperanç
erdas dos atacantes ser
recursos da força que e
o produto da força qu
e o valor obtido;
esmo nível de perdas p
perdas dos defensores
cado pela força defens
ultiplicado pela força
100%
Y = X + P(E)
Xobtido, a qual será estar este entre 48 e
mesmo processo
alizaria o algorit-
a a aplicação dos
a matemática:
ão a porcentagem
ntrou em comba-
e eles colocaram
ara ambos os la-
serão a diferença
ora. Para os ata-
atacante.
82
Além dos combates e confrontos de forças, há necessidade de estabelecer-se um
método para tratar a conexão das redes de comunicações, a fim de tratar o resultado dos ata-
ques a esses recursos.
4.5. Generalizando a aplicação da Lógica Nebulosa aos Eventos
Tendo em vista a modelagem das regras apresentadas em 4.4 comparadas com as
produzidas em 4.2, questiona-se por que não se comparar os diversos fatores envolvidos em
cada força combatente?
Há, inicialmente, uma consideração em relação ao resultado a ser feita quanto às
possíveis saídas do evento: na detecção, haverá ou não a localização dos incursores, podendo
ser utilizada tanto a comparação de potenciais quanto à composição dos fatores numa mesma
regra.
Entretanto, a preferência é utilizar a composição do resultado quando este se re-
sumir a sim ou não (duas opções), uma vez que as probabilidades serão x ou 100% - x. Quan-
do se tratar de resultados com mais de duas possibilidades (vitória de A, vitória de B ou
empate), a composição dos fatores não permitirá determinar a probabilidade de empate,
tornando necessária a abordagem de comparação de potenciais.
Assim, a composição dos fatores será utilizada sempre que os possíveis resultados
forem soma zero, ou seja, ou um resultado acontece ou não acontece. Quando se tratar de re-
sultados que possam considerar mais saídas, como o empate, deverá ser utilizada a compara-
ção de potenciais.
Além dos combates, outro fator a ser tratado pelos modelos é o impacto dos danos
causados na conexão dos sistemas de comunicações, que também requer um tratamento espe-
cífico.
4.6. Aplicando Grafos às Redes de Comunicações
Tendo em vista os sistemas de comunicações serem a base dos sistemas de Co-
mando e Controle e a integridade dos mesmos afetar o grau em que os resultados serão apre-
sentados ou não a cada partido, torna-se necessário definir-se a situação do mesmo.
83
Tal definição seria calcada na conexão do grafo em relação ao Centro de C2. Des-
sa forma, se houvesse uma Unidade desconectada da rede, a mesma não forneceria informa-
ções a ela afetas, tornando necessárias ações do Comando para obtê-las, quer seja no sentido
de restabelecer comunicações, quer no sentido de enviar-se missões de ligação.
Considerando-se cada estação de comunicações como um nó de um grafo, pode-se
empregar os algoritmos de verificação de conexão de grafos para saber-se quais as Unidades
que não fornecerão informações para o relatório da simulação.
Tendo em vista, no entanto, a utilização de recursos diferentes, tal emulação de-
manda que se construa um grafo para cada rede e que essa verificação seja efetuada para cada
uma, a fim de que apenas as Unidades que não tiverem nenhuma conexão com o Centro de
Comando e Controle do Comando de Emprego sejam consideradas fora do ar e suas informa-
ções não sejam disponibilizadas aos jogadores.
Com base nas idéias apresentadas, tem-se os recursos necessários para a elabora-
ção do protótipo, seguindo-se os passos da abordagem para o desenvolvimento do mesmo.
Essas idéias devem ser um guia seguro para que o software desenvolvido com ba-
se nelas leve o “rei” (autoridade patrocinadora do exercício) a não esperar mais para que o
jogo fique pronto, mas sim, para que ele e toda a equipe envolvida focalizem mais a estratégia
a ser aplicada.
84
5. Utilização da Abordagem
“Precisamos decidir o que é relevante e o que não é relevante”. (Jacob Bronowski)
5.1. Fatores Iniciais
Seguir um processo de desenvolvimento eleva a probabilidade de se obter siste-
mas apropriados, entretanto, a utilização de uma abordagem mais específica a determinados
casos, como os jogos de guerra, aumenta o poder do processo adotado, focalizando questões
críticas a tais softwares, ajudando a decidir o que é relevante para os modelos e regras a serem
desenvolvidos e a se escolher a opção mais apropriada nos momentos de projeto e de imple-
mentação.
Tendo em vista ainda tratar-se de um protótipo acadêmico para verificação da a-
bordagem, será adotada uma simplificação do RUP baseada na combinação dos trabalhos de
Kruchten44 e de Probasco45, as quais, por manterem a coerência com o RUP, não afetam a
essência da abordagem, acelerando, apenas a sua aplicação.
Com base nessa combinação, foram selecionados os seguintes aspectos para nor-
tearem a implementação do protótipo:
- Lista de Riscos: embora não seja desenvolvido formalmente o documento, serão
apenas apresentados os aspectos vistos como riscos e seus tratamentos;
- Documento de Visão: embora não seja desenvolvido formalmente o documento,
os aspectos por ele abordados encontrar-se-ão no decorrer deste capítulo;
- Tarefas: não serão apresentadas formalmente, constituindo os diversos tópicos a
serem abordados;
- Caso de Negócio: também não será desenvolvido por ser um trabalho acadêmi-
co, sem preocupação com a viabilidade econômica do projeto;
- Arquitetura: será discutida a arquitetura proposta para o protótipo;
- Avaliação: tendo em vista tratar-se de um protótipo acadêmico, não será feita
uma avaliação de andamento das fases; 44 KRUCHTEN, Philippe. Software Development Process for a Team of One. The Raional Edge, 2002, http://www.therationaledge.com/, capturado em 25 set. 2002.
85
- Pedidos de Mudança: por se tratar de um projeto acadêmico sem um cliente real
efetivo, não haverá controle de configuração e de mudança; e
Apoio ao Usuário: Tendo em vista o caráter acadêmico do protótipo, não haverá
um apoio efetivo ao usuário.
Um dos primeiros riscos a serem confrontados por este projeto é o desempenho
que deverá permitir interatividade. Para mitigar tal dificuldade, escolheu-se fatias de tempo
relativamente grandes, de um minuto, para a atualização da simulação, a fim de que a grande
quantidade de eventos não afete a resposta da mesma. Como contingenciamento, pode-se au-
mentar a fatia de tempo ou evitar-se o tratamento específico dentro dos eventos, como citado
em 4.4.
Outro risco é a complexidade envolvida, a qual exige como mitigação a adoção de
simplificações que permitem uma implementação mínima para provar o conceito. Como con-
tingenciamento, podem ser adotadas mais simplificações, as quais serão citadas no decorrer
dos próximos capítulos.
Segundo os autores aqui mencionados, o próximo passo a ser buscado é a confec-
ção do documento de visão, do qual já se definiu o problema, faltando conhecer-se os interes-
sados e suas necessidades.
Assim, a pergunta que paira no ar passa a ser: quais os interessados e quais são as
necessidades da FAB em relação a um sistema de jogos de guerra?
5.2. Interessados e Necessidades da Força Aérea
Antes de qualquer coisa, as figuras centrais dos níveis operacionais são o Coman-
dante do Grande Comando e seu Estado-Maior.
Um Estado-Maior é composto pelo Chefe do Estado-Maior, pelos Chefes das Se-
ções de Operações, de Inteligência, de Logística, de Pessoal, de Planejamento, de Comando e
Controle, de Comunicação Social46 e seus auxiliares, nas áreas de Suprimento e Manutenção
de Aeronaves, de Intendência, de Saúde de Transporte, de Engenharia e de Segurança e De-
fesa.
45 PROBASCO, Leslee. Ten Essentials of RUP – The Essence of an Effective Development Process. Rational White Papers, 2000.
46 BRASIL. Ministério da Defesa. Doutrina Básica de Comando Combinado. Brasília, 2001. (MD33-M-03).
86
Todo esse grupo está envolvido com as atividades de planejamento e de controle
dentro dos níveis operacional e estratégico47.
Assim, o objetivo deste protótipo seria proporcionar à equipe que compõe um Es-
tado-Maior uma ferramenta para a simulação das missões por eles planejadas.
Buscando obter uma visão da necessidade dos diversos grupos, aproveitou-se a
experiência dos alunos do CCEM da ECEMAR, dentre os quais sempre aparecem oficiais
com experiência nas áreas de atuação de um Estado-Maior, para a entrega de questionários no
período 2001-2003. As respostas obtidas foram compiladas e geraram as necessidades apre-
sentadas.
Analisando-se os interesses dos componentes de um mesmo Estado-Maior, os in-
teresses são bastante semelhantes em relação ao protótipo, ou seja, obter-se os diversos cená-
rios resultantes de possíveis decisões e suas conseqüências para o cumprimento da missão do
Comando a que pertencem.
Baseado na lição de um dos primeiros jogos de guerra do mundo, o Kiegsspiel,
jogado pelo Barão von Reisswitz na Prússia, percebe-se que um jogo de guerra deve propor-
cionar aos seus praticantes meios para tornar suas decisões mais ágeis, tendo em vista que os
conflitos atuais são cada vez mais rápidos e letais. Torna-se, assim, necessário expor-se as
necessidades da FAB nesse aspecto:
Tendo em vista as rápidas mudanças nos sistemas de armas, torna-se essencial que
o ele seja flexível o suficiente para aceitar diversos cenários necessários ao treinamento do
pessoal que irá exercer atividades nos níveis operacional e estratégico.
Segundo as mais diversas solicitações, o sistema deve simular as atividades do ní-
vel tático (operacionais e logísticas) com realismo em relação ao estabelecido na Doutrina
Básica e confiabilidade. Essa ânsia por realismo aparece, inclusive no interesse por se apre-
sentar o desenrolar do conflito em tempo real, semelhantemente às telas de radar dos centros
de Comando e Controle. Esse último aspecto, embora não seja atendido neste protótipo, defi-
ne o tipo de simulação adotado, tendo impacto na arquitetura.
Deve prover meios de simular a situação dos recursos de comunicações durante o
desenrolar do jogo.
47 BRASIL. Ministério da Defesa. Manual do Processo de Planejamento de Comando para Operações Combina-das. Brasília, 2001. (MD-33-M-05).
87
O sistema deve, quando pertinente, gerar danos colaterais e adicionais.
O próximo passo para o levantamento dos requisitos será o levantamento das fun-
cionalidades do sistema que atendam às necessidades apresentadas.
5.3. Funcionalidades Essenciais
As seguintes funcionalidades tornam-se vitais para cada necessidade:
5.3.1. Diversos Cenários
O sistema deverá possuir a capacidade de aceitar a definição do conflito hipotético
em qualquer ponto da América do Sul (pelo menos) e, além disso, permitir que a inserção de
novos elementos de manobra (Unidades Aéreas, Unidades de Logística, Unidades de Segu-
rança e Defesa, Unidades de Controle do Espaço Aéreo, aeronaves, sistemas de artilharia an-
tiaérea, radares, aeródromos, hospitais, escolas, centros de Comando e Controle, depósitos,
munições, mísseis, portos, instalações navais, tropas terrestres, embarcações, submarinos,
hidrelétricas, usinas termelétricas, estações elevadoras/rebaixadoras, eclusas, usinas termonu-
cleares e fábricas).
Para permitir a apresentação desses dados geográficos do conflito no âmbito da
América do Sul é necessário associar-se o protótipo em estudo a uma ferramenta com caracte-
rísticas de GIS (Geographic Information System – Sistema de Informações Geográficas), que
está fora do escopo deste trabalho, entretanto, apesar de não ser tratado no escopo do trabalho,
haverá necessidade de se reutilizar essas funcionalidades de bibliotecas já existentes, que in-
cluam o tratamento das informações de posição e permitam o armazenamento das coordena-
das dos elementos nos objetos e no Banco de Dados.
Tratar as informações de posição é essencial para a simulação da localização dos
elementos de manobra, principalmente os móveis, uma vez que a simulação de todos os even-
tos a eles relacionados depende da posição dos mesmos, tornando vital o tratamento das equa-
ções de movimento em relação às coordenadas geográficas.
Tendo em vista que esses elementos de manobra são persistentes em muitos casos,
isto é, suas informações deverão subsistir após o encerramento da simulação, torna-se impor-
tante que haja meios de armazenar essa posição geográfica quando for apropriado.
88
5.3.2. Simular as Atividades do Nível Tático com Realismo
O protótipo de sistema deverá possuir a capacidade de ler ou de importar os plane-
jamentos realizados pelo Comando e simular essas missões, obtendo resultados compatíveis
com a realidade delas.
As missões do nível tático a serem discutidas dentro do escopo, conforme estabe-
lece a DMA-1-1, são:
5.3.2.1. Ataque;
É a missão que objetiva destruir ou danificar os objetivos no país inimigo. Esses
objetivos podem ou não ser alvos de interesse direto do poder aeroespacial.
A destruição dos alvos depende do confronto entre a capacidade do armamento u-
tilizado e a resistência intrínseca do alvo àquele efeito. Por exemplo, ao atacar-se uma pista,
que é pouco sensível ao efeito incendiário, com bombas incendiárias, os danos serão mínimos.
Entretanto, se o alvo for uma refinaria, que é sensível ao efeito incendiário, ela poderá ser
destruída.
Outro fator importante para se raciocinar com a destruição de um alvo é a quanti-
dade de armamento que atingiu o alvo. Se apenas uma bomba incendiária cair em um pequeno
depósito de combustível, ela será suficiente. Entretanto, no caso de uma grande refinaria, o
incêndio causado por uma única bomba, dependendo dos recursos de combate a incêndio dis-
poníveis, pode ser controlado e debelado em curto espaço de tempo.
É necessário pensar-se também em relação às vítimas do ataque. O alvo deverá ter
o número de pessoas envolvidas na sua operação e quanto maior for o dano sofrido, maior a
probabilidade de se ter um elevado número de mortos e de feridos, cujo total deve ser igual ou
inferior ao de envolvidos com o objetivo.
Há que se raciocinar ainda com os danos colaterais, que são danos indesejáveis
causados a instalações que não se pretendia atingir, como, por exemplo, hospitais ou escolas.
Este tem sido um fator de elevada importância no conflito moderno, devido ao fato de, muitas
vezes, haver coalizões para o esforço de guerra e tais resultados afetarem o apoio ao país que
os obteve.
89
Pode, ainda, ao contrário do dano colateral, haver o caso de se atingir outro alvo
não planejado ou o impacto do ataque afetar outros alvos de interesse, cujo resultado não ha-
via sido previsto. Assim, de repente, uma bomba incendiária lançada num hangar para a des-
truição de aeronaves pode atingir um depósito de combustível do aeródromo. Tal resultado é
conhecido como dano adicional e o mesmo ajuda a influenciar negativamente o país que o
sofreu. Todo o modelo discutido é diagramado em termos de Causa e Efeito no Anexo X.
5.3.2.2. Interceptação
São missões em que aeronaves são lançadas para interceptar e, se possível, destru-
ir os vetores inimigos, que tanto podem ser aeronaves quanto veículos aéreos não-tripulados
(VANT).
O resultado desse tipo de missão depende inicialmente de quem domina o espec-
tro eletromagnético, uma vez que a interceptação sem recursos de coordenação tem baixas
possibilidades de êxito para os defensores.
Outro fator é que, uma vez ocorrendo a interceptação com sucesso em um
ambiente de conflito, ocorrerá o combate aéreo, que poderá ou não utilizar armamentos além
do alcance visual (BVR – Beyond Visual Range), mísseis de curto alcance e/ou canhões.
A probabilidade de vitória, nesse caso, dependerá também de diversos fatores, os
quais foram priorizados em enquete com diversos pilotos de caça que eram alunos ou instruto-
res do CCEM no período de 2002 a 2003 e esses resultados foram tabulados para servir de
base para o modelo do combate aéreo.
Outro fator a ser analisado é que nem sempre o combate aéreo é um jogo de soma
zero, ou seja, haverá um vencedor ou um perdedor. Um empate pode ocorrer pelo consumo
sem êxito dos armamentos de ambas aeronaves ou pelo desengajamento e fuga por parte de
uma delas.
Caso haja uma aeronave abatida, tornar-se á necessário também verificar se sua
tripulação está ou não morta, resultando em atualizações no efetivo.
Além de o resultado poder ser vitória, derrota ou empate, ainda torna-se necessá-
rio tratar-se o combate aéreo muitos contra muitos, o qual é limitado pela relação entre a
quantidade de armamento disponível para cada formação e a quantidade de inimigos a ser
atacada. Assim, uma formação com quatro aeronaves, armadas com 4 mísseis cada, que tenta
90
interceptar 18 aeronaves, somente poderá, no máximo, derrubar 16. As duas restantes poderão
prosseguir na missão.
5.3.2.3. Escolta
A escolta é uma missão com a finalidade de proteger as aeronaves que cumprem
diversas outras missões, reagindo semelhantemente às missões de interceptação, com a parti-
cularidade de nem sempre disporem do apoio de um sistema de defesa aérea, tendo que contar
especificamente com os recursos disponíveis.
Em termos de simulação, as aeronaves escoltantes deverão sempre partir para o
combate com os defensores inimigos antes que estes ataquem as aeronaves escoltadas.
5.3.2.4. Reabastecimento em Vôo (REVO)
A ocorrência deste tipo de missão depende especificamente do êxito do “rendez-
vous” (encontro) da aeronave reabastecedora com as aeronaves a serem reabastecidas em ter-
mos de espaço einsteiniano (3 dimensões mais o tempo), havendo uma distância máxima a-
ceitável, que será função da condição de silêncio eletrônico estabelecida e da meteorologia.
Assim, com o uso do radar ou equipamento radiogoniométrico, será possível a realização
bem-sucedida com uma margem de erro maior, enquanto que o mesmo não acontecerá sem
eles numa condição de mau tempo (vide modelo no Anexo X).
Outro fator importante é o tempo de duração do reabastecimento, que é função da
quantidade a ser passada para cada aeronave e da quantidade de aeronaves a serem reabaste-
cidas.
Vale a pena ressaltar que, se for extrapolado o limite da capacidade disponível pa-
ra transferência, não haverá mais reabastecimento e as aeronaves não reabastecidas ou aborta-
rão a missão ou efetuarão pouso forçado.
Tendo em vista o pequeno tamanho das órbitas dessas aeronaves em relação ao
cenário do confronto, as mesmas serão consideradas pairando sobre o ponto de órbita.
91
5.3.2.5. Controle e Alarme em Vôo (AEW – Airborne Early Warning)
Este tipo de missão visa a complementar a efetividade dos radares de solo, detec-
tando incursões inimigas a baixa altura ou em áreas não cobertas, aumentando a efetividade
do sistema de defesa aérea.
A eficácia destas missões depende da efetividade das Medidas de Proteção Eletrô-
nica (MPE) contra a capacidade dos recursos de Contramedidas Eletrônicas (CME) das aero-
naves incursoras.
Caso a aeronave AEW tenha vantagem, a detecção ocorrerá a partir da distância
de alcance máximo.
Tendo em vista o pequeno tamanho das órbitas dessas aeronaves em relação ao
cenário do confronto, as mesmas serão consideradas pairando sobre o ponto de órbita.
A detecção de aeronave incursora resultará no acionamento do sistema de Defesa
Aérea, a fim de que a mesma seja interceptada e destruída.
5.3.2.6. Suprimento
Nessas missões, busca-se dotar as Unidades Aéreas e de Aeronáutica com o devi-
do material para o cumprimento da missão.
Existem diversas classes de materiais que são utilizados por essas Unidades. Para
o presente trabalho de pesquisa, será necessária uma modelagem flexível para suprimento de
Material de Aeronáutico (material que apóia a operação e a manutenção das aeronaves) e de
Material Bélico de Aviação, de forma a poder reaproveitá-la nas demais classes.
Essencialmente, o fluxo de suprimentos gira em torno do consumo, realizado por
uma missão, um ataque inimigo ao depósito ou uma atividade de manutenção. Esse consumo
reduz o estoque disponível, o qual, se chegar a zero, inviabilizará a execução de missões por
falta do item necessário.
O modelo necessário para a atividade de suprimento foi detalhado em 4.3.3.
92
5.3.2.7. Pessoal
As atividades de gerência de pessoal são voltadas à disponibilização dos efetivos
necessários ao cumprimento da missão.
As baixas de pessoal podem ser computadas com base nos resultados dos comba-
tes aéreos, ar-terra, ar-mar, marítimos ou terrestres.
Semelhantemente aos suprimentos, a falta de pessoal é suficiente para inviabilizar
a realização de missões, fazendo com que o recompletamento de efetivo deva ser tempestivo,
para evitar que tal situação ocorra.
O modelo para tratamento dos eventos ligados a pessoal foi discutido em 4.3.1.
5.3.2.8. Engenharia
Realiza as obras de construção e/ou reparo de instalações como pistas, hangares,
depósitos e vias de acesso.
O modelo necessário foi tratado em 4.3.5.
5.3.2.9. Controle do Espaço Aéreo
Essa missão envolve a operação dos sistemas de controle de tráfego aéreo e de
controle de Defesa Aérea.
Uma vez detectada a incursão inimiga, serão acionadas as aeronaves de alerta de
Defesa Aérea (DA).
O modelo foi tratado com mais detalhes em 4.2.
As regras de interceptação serão:
a. Acionar os alertas em vôo mais próximos que tenham autonomia suficiente para
tal;
b. Acionar o alerta a postos mais próximo (se não houver alerta em vôo); e
c. Acionar o alerta a tempo mais próximo (se não houver nenhum dos anteriores).
93
Caso a quantidade de aeronaves de alerta acionadas não seja suficiente para se
contrapor à ameaça, o processo de acionamento deve ser repetido até completar o necessário
ou esgotar-se a Defesa Aérea.
5.3.2.10. Segurança e Defesa
As missões de Segurança e Defesa incluem as ações de Autodefesa Antiaérea e as
de Defesa de Instalações.
No primeiro caso, as Unidades de Infantaria farão a proteção dos aeródromos, ra-
dares, depósitos e Centros de Comando e Controle contra ataques aéreos, utilizando mísseis
antiaéreos de curto alcance.
O número de incursores a serem engajados será função da quantidade de Unidades
de Tiro posicionadas e do número de aeronaves engajadas por Unidade de Tiro, que depende
do tipo de míssil utilizado.
O êxito no confronto é fruto do tipo de aquisição do alvo (óptica ou radar), da ma-
nobrabilidade do míssil contra a do atacante, da sensibilidade do míssil a CME e da capacida-
de de CME do incursor, da velocidade e altura da aeronave e do treinamento do pessoal.
Quanto à Defesa de Instalações, o modelo foi discutido em 4.4.
Serão computados também os números de feridos e de mortos dos grupos na inte-
ração, atualizando-se assim ambos os efetivos.
A derrota dos defensores resultará em danos ou na ocupação do alvo, dependendo
dos danos sofridos pelo grupo invasor durante o confronto e da missão desse grupo (destruir,
danificar ou ocupar).
5.3.2.11. Operação de Instalações Aeronáuticas
Embora nesse grupo haja diversas ações, tendo em vista o escopo proposto, será
abordada apenas a ação de comunicação, que informará se o elo daquela localidade está ou
não ativo e quem ele alcança na rede.
Em função dos danos sofridos nos ataques, o equipamento poderá ser danificado,
restringindo, sua capacidade, ou destruído.
94
Como conseqüência da destruição dos equipamentos de comunicação, as informa-
ções referentes à localidade afetada não serão disponibilizadas ao Comando, tornando neces-
sárias outras medidas para a obtenção dos dados necessários.
5.3.3. Simular a Situação dos Meios de Comunicação
Conforme discutido logo acima, em 5.3.2.11., tal simulação ocorrerá com as ações
de comunicações e a operação destas dependerá dos danos sofridos dos ataques inimigos.
Vale a pena ressaltar que outro fator importante é a quantidade de enlaces dispo-
níveis, pois, se, por exemplo, a conexão de fibra óptica foi destruída, mas o enlace HF não foi
afetado, a Unidade em questão ainda terá comunicação.
É também importante frisar que os equipamentos e/ou conexões podem ser repa-
rados e/ou substituídos em determinada faixa de tempo, podendo também ser simulada a in-
terdição da estação por tempo determinado (vide Anexo X).
Assim, a existência de equipamentos sobressalentes e a disponibilidade de pessoal
capacitado a efetuar substituições e/ou reparos também influencia na recuperação do enlace
de comunicações.
5.3.4. Danos Adicionais e Colaterais
A possibilidade de danos colaterais e/ou adicionais depende da definição da mes-
ma durante a descrição de cada objetivo.
Cada um terá a definição a respeito da proximidade ou não de escolas, hospitais,
templos religiosos e embaixadas de países neutros para a definição de danos colaterais e han-
gares de manutenção, alojamentos, estações de comunicações, depósitos de combustível, ar-
mamento ou outras classes de suprimento para o cômputo de danos adicionais.
Caso haja um ou mais alvos colaterais e/ou adicionais próximos, será informado
qual(is) alvo(s) colateral(is) ou adicional(is) foi(ram) atingido(s) e com que grau de danos, em
função do tamanho do alvo e da sensibilidade ao armamento empregado.
Assim, quanto maior o alvo, mais armamento será necessário para destruí-lo,
quanto mais sensível ao efeito dos artefatos bélicos, menos bombas, mísseis e/ou foguetes
95
serão precisos e quanto mais próximo o artefato cair do alvo colateral ou adicional, maior será
o dano (vide modelo no Anexo X).
Segundo a técnica de elaboração de requisitos, após a definição das necessidades,
chega-se aos casos de uso, os quais são conectados às mesmas, dependendo da ferramenta
utilizada.
Entretanto, tendo em vista a importância da confecção dos casos de uso para a a-
plicação da abordagem, esse processo será dividido em três etapas: a primeira, com a defini-
ção do(s) caso(s) de uso associado(s) a cada funcionalidade, a segunda, com o detalhamento
da aplicação da abordagem proposta para o caso de uso, e, por fim, o diagrama de casos de
uso.
5.4. Casos de Uso associados às Funcionalidades
Tendo em vista que os casos de uso dependem da definição dos atores, que são as
pessoas, outros sistemas ou equipamentos que interagem com o software, ou seja, um subcon-
junto dos interessados, responsável por operar a simulação, conclui-se que o ator será um
componente do Estado-Maior, que poderá, genericamente ser chamado de operador.
Devido à grande complexidade das operações executadas automaticamente pelo
sistema, as quais são tempo-dependentes, optou-se por considerar o objeto relógio (objeto que
controla o tempo de simulação) como um ator, a fim de minimizar um problema apresentado
por Leffingwell em relação às limitações dos casos de uso para a modelagem de simulações.
Assim, o operador iniciará a simulação, e o relógio acionará as diversas operações
que ela deve executar automaticamente no decorrer do tempo simulado.
Diversas funcionalidades do protótipo foram influenciadas pelas missões de Ata-
que, uma vez que, conforme foi explanado em 5.3., várias informações serão obtidas das con-
seqüências dessas missões, variações no efetivo, situação das comunicações, danos colaterais
e/ou adicionais.
Embora a associação das informações referentes a necessidades, funcionalidades e
casos de uso possa ser feita em ferramentas específicas de software como o Rational Requisite
Pro, o Borland Caliber ou o Sysnet, da Elbit, tendo em vista a necessidade de se explicitar as
conexões entre tais aspectos, optou-se por apresentar essas ligações na tabela 5.1, a fim de
96
facilitar a visualização a respeito de como os fatores discutidos em 5.2. e 5.3. levaram aos
casos de uso a serem descritos.
Buscando simplificar o tratamento das missões do nível tático, as mesmas foram
divididas por eventos. Assim, todas as missões aéreas terão os eventos comuns como decola-
gem e pouso, os quais resultarão nos casos de uso Realizar Decolagem e Realizar Pouso. Os
demais eventos serão eventos específicos para cada missão.
Necessidade Funcionalidade Caso de Uso Cenários diversos Tratamento de posições Atualizar Ambiente
Simular Ataque Realizar Ataque Simular Interceptação Simular Escolta Realizar Combate Aéreo
Simular REVO Realizar REVO Simular AEW Atualizar Ambiente
Consumir combustível Simular Abastecimento Consumir lubrificantes
Simular Rearmamento Consumir Material Bélico de Avia-ção
Simular decolagem Realizar Decolagem Simular Pouso Realizar Pouso
Realizar Decolagem Verificar Efetivo Realizar Combate Terrestre Realizar Ataque Realizar Combate Aéreo Realizar Combate Terrestre Atualizar Efetivos
Atualizar Efetivo
Simular Autodefesa Antiaérea Realizar Combate com Artilharia Antiaérea
Simular Guarda de Instalações Realizar Combate Terrestre
Simular as atividades do nível tático
Simular reparo a instalações Reparar Instalação Simular a situação dos recursos de Comunicações
Apresentar a situação das conexões do sistema de comunicação
Gerar danos colaterais Simular danos colaterais Gerar danos adicionais Simular danos adicionais
Realizar Ataque
Gerenciar Eventos Verificar os Evento Correntes Controle da Simulação Atualização de Posições Atualizar Ambiente
Tabela 5.1 – Necessidades, Funcionalidades e Casos de Uso inter-relacionados.
Com base na tabela acima, conclui-se que as funcionalidades ligadas ao posicio-
namento dos objetos móveis e a conseqüente detecção ou não, serão tratadas no caso de uso
Atualizar Ambiente.
Observa-se também que as ações do nível tático serão tratadas como eventos, ha-
vendo ainda a demanda por uma funcionalidade que permita a gerência desses eventos, a qual
pode ser atendida por mais um caso de uso – Verificar os Eventos Correntes – em comple-
mento ao caso de uso Atualizar Ambiente.
97
Para a ordenação e descrição dos diversos eventos, que constituem os casos de uso
que simulam as missões, surge a contribuição deste trabalho.
5.5. Aplicando a Lógica Fuzzy às Missões de Ataque
Conforme discutido em 2.4., a lógica difusa surge como alternativa para a ausên-
cia de um modelo probabilístico preciso para a simulação do evento Ataque por permitir o
tratamento quantitativo de informações vagas, aproximadas ou em linguagem natural, forne-
cendo resultados verossímeis para tais situações.
Ao analisar os fatores voltados às missões de ataque, omite-se aqui os fatores refe-
rentes às comunicações (caso o alvo principal ou adicional seja uma estação de comunica-
ções), por ser tratado em tópico específico posteriormente.
O ataque a um alvo inclui questões a serem respondidas para a obtenção do resul-
tado:
4.5.1. O Alvo Foi Localizado?
Embora tal pergunta pareça sem propósito, vários armamentos dependem da de-
tecção do alvo, como mísseis antinavio guiados por radar ou mísseis anti-irradiação, os quais
apresentam variados graus de sensibilidade a sistemas de guerra eletrônica voltados ao despis-
tamento deles.
Outro fator que influencia na detecção do alvo é a aquisição visual, a qual também
depende da meteorologia da região onde ele se localiza.
Assim, podem ser dados dois tratamentos para a localização de alvos:
4.5.1.1. Localização com Sensores Eletrônicos
Para o tratamento de tais eventos, torna-se necessário definir-se a prevalência en-
tre o sistema de detecção do atacante ou o sistema de guerra eletrônica do defensor, podendo-
se incluir até fatores referentes ao treinamento dos operadores dos sistemas (dependendo do
interesse nos detalhes a serem abordados pelo software).
Tal situação pode ser expressa pelo diagramas de causa e efeito da fig. 5.1:
98
Capacidade de detecção do sensor do atacante
+ -
Fig. 5.1 – Influência dos fatore
Transformando-se em r
Se a capacidade do sis
guerra eletrônica do alvo é baixa, a
Se a capacidade do sis
guerra eletrônica do defensor é méd
Se a capacidade do sis
guerra eletrônica do defensor é alta
Com base nessas regra
corrência ou não da localização do
4.5.1.2. Localização Vi
A localização visual de
encontra o objetivo, a qual afeta a
nível de camuflagem utilizado para
Capacidade do sistema de CME do alvo
s
e
te
p
te
i
te
,
s,
o
su
n
Probabilidade de detecção
de CME e do sensor para a detecção eletrônica do alvo
gras, obtém-se:
ma de detecção é alta e a capacidade do equipamento de
robabilidade de detecção é alta.
ma de detecção do atacante é média e a dos recursos de
a, a probabilidade de detecção do alvo é média.
ma de detecção do atacante é baixa e a dos recursos de
a probabilidade de detecção do alvo é baixa.
conclui-se que ambos os sistemas contribuem para a o-
bjetivo do ataque.
al
um objetivo depende da meteorologia da região onde se
visibilidade, do nível de treinamento dos atacantes e do
ão ser detectado.
99
+
Meteorologia
Fig. 5.2 –
Transformando-se em
- Se a meteorologia d
namento dos atacantes, alto; entã
- Se a meteorologia d
treinamento dos atacantes, médio
- Se a meteorologia d
namento dos atacantes, baixo; en
Com base nessas reg
dições visuais. Vale ressaltar que
a localização visual do mesmo é
4.5.2. O Armamento
Apesar da evolução
(HUD), a probabilidade de acerto
do (guiado ou não), pelas condi
eletrônica do alvo (para despista
incluindo fogo de barragem ou m
Nível de camuflagemdo alvo
+
-
Pr
r
a
o,
a
; e
a
tão
ras
a
pr
At
do
t
çõ
m
ís
Probabilidade de detecção
obabilidade de detecção
egras, obtém-se:
região é boa; o nível d
a probabilidade de det
região é razoável; o nív
ntão, a probabilidade d
região é ruim; o nível
, a probabilidade de d
, é possível simular-se
não detecção resultará
é-requisito para se lanç
ingiu o Alvo?
s sistemas de pontari
ambém pode ser afetad
es meteorológicas (ra
ento de mísseis) e/ou
seis antimísseis (princi
Nível de treinamento dos atacantes
visual do alvo
e camuflagem, baixo; o grau de trei-
ecção visual é alta.
el de camuflagem, médio; o grau de
e detecção visual é média.
de camuflagem, alto; o grau de trei-
etecção visual é baixa.
a detecção ou não do alvo em con-
na abortiva da missão, uma vez que
ar os armamentos.
a com os atuais Head-Up Displays
a pelo tipo de armamento emprega-
jadas de vento), sistemas de guerra
pela capacidade de defesa do alvo,
palmente no caso de navios).
100
Fig. 5.3 – Definição d
Tal quadro perm
- Se a precisão
alta, a meteorologia é boa,
é fraca, a probabilidade de
- Se a precisão
média, a meteorologia é raz
do alvo é média, a probabil
- Se a precisão
baixa, a meteorologia é ru
alvo é forte, a probabilidad
Uma vez defini
impactos obtidos, sendo ne
empregado.
4.5.3. O Alvo é
Um fator que d
ção entre o seu grau de re
armamento utilizado, assoc
pagar efeitos e ao seu tama
+
-
Meteorologia
Precisão dos sistemas da aeronave
a pro
ite
do
a ca
ace
do
oáv
ida
do
im,
e de
do
ces
Se
efin
sistê
iad
nho
+
+
Probabilidade de acerto
babilidade de acerto
compor as seguin
sistema de tiro da
pacidade do sistem
rto é alta;
sistema de tiro da
el, a capacidade d
de de acerto é méd
sistema de tiro da
a capacidade do s
acerto é baixa;
que o alvo foi ating
sário para tanto, sa
nsível ao Armamen
e o grau de dano
ncia ao efeito do
o à quantidade de
, conforme expost
Defesas Inimigas
Precisão do armamento empregado
do alvo com base nos fatores de combate
tes regras para a probabilidade de acerto:
aeronave é alta, a precisão do armamento é
a de CME do alvo é baixa e a defesa do alvo
aeronave é média, a precisão do armamento é
o sistema de CME do alvo é média e a defesa
ia;
aeronave é baixa, a precisão do armamento é
istema de CME do alvo é alta e a defesa do
ido, torna-se vital analisar-se o resultado dos
ber-se a sensibilidade do alvo ao armamento
to Empregado?
sofrido pelo alvo será tratado pela compara-
armamento empregado e o grau do efeito do
impactos recebidos, à sua capacidade de pro-
o na figura 5.4.
-
Capacidade de CME do alvo
101
-
-
+
Fig. 5.4
Como exemplo
armamento com elevado n
por conseguinte, sofrerá el
res.
O mesmo racio
entendida como a capacid
uma belonave que não afun
nificativo.
É importante r
dando a simular a “névoa
um alto grau de dano pode
vinas, quando uma belona
armamento lançado.
O diagrama de
nham um único fato, o imp
mento e a resistência do al
fator envolvido. Semelhant
Tais fatores são
Para que essa
considerados:
Nível do efeito produzido pelo armamento
Sensibilidade
do alvo ao efeito
-
Probabilidade
-+
– D
, u
íve
eva
cín
ade
da
ess
da
nã
ve
ca
ac
vo,
em
as
com
Impacto do armamento
de Destruição do alvo
+
Confiabilidade do armamento
efinição da probabilidade de destruição
m alvo com alta sensibilidade a sopro,
l de sopro, terá um elevado grau de
do grau de dano, se forem levados em
io se aplica à capacidade de absorçã
de um alvo isolar o impacto recebid
com o impacto de um único míssil, e
altar-se que o resultado obtido é a p
guerra”, uma vez que uma elevada
o concretizar-se, como pôde ser cons
inglesa, embora atingida, não sofreu
usa e efeito da figura 5.4 permite q
to do armamento, pela comparação en
com o uso do conectivo e, que perm
ente, pode ser obtida a capacidade de
sociados entre parênteses na regra
paração seja possível, existem vário
Capacidade de propagação de efeito do alvo
do
a
im
o
o
m
ro
p
ta
d
ue
tr
iti
ab
s
Capacidade de Absorção do
alvo
+Tamanho do alvo
alvo
o receber um impacto de
pacto do armamento e,
conta apenas esses fato-
do alvo, a qual pode ser
em sua estrutura, como
bora sofra um dano sig-
babilidade de dano, aju-
robabilidade de obter-se
tado na Guerra das Mal-
anos devido à falha do
as regras fuzzy compo-
e a capacidade do arma-
rá a utilização do menor
sorção do alvo.
tipos de efeito a serem
102
4.5.2.1. Sopro
É a rápida variação de pressão causada por uma explosão. Geralmente produz
bons resultados em muitos alvos, com exceção de edificações reforçadas com concreto, blin-
dados e pistas, que necessitam de um outro efeito.
Também não é o mais apropriado para o ataque a refinarias ou depósitos de com-
bustíveis, uma vez que o dano será limitado a pequenas áreas, comparado com o efeito incen-
diário.
4.5.2.2. Penetração
É o efeito que combina a explosão após a penetração em um alvo de elevado grau
de resistência. Este é o mais apropriado para ataque a alvos reforçados com abrigos de siste-
mas de Comando e Controle, shelters para a proteção de aeronaves e pistas de pouso.
4.5.2.3. Incendiário
É o incêndio causado pelo armamento. Geralmente é o mais apropriado para o a-
taque a depósitos de combustíveis e/ou munições.
Pode também ser empregado contra tropas a pé (infantaria), dependendo da vege-
tação e da umidade da época, sendo este emprego pouco recomendado, devido à grande pro-
babilidade da ocorrência de efeitos colaterais.
4.5.2.4. Fragmentação
É o espalhamento de fragmentos metálicos a alta velocidade, provocado por uma
explosão ou pelo movimento de rotação da arma. Este é o efeito mais apropriado para o ata-
que a aeronaves no solo ou a tropas de infantaria.
103
6. Implementando e Testando o Protótipo
104
7. Visão Prospectiva
105
8. Conclusões e Recomendações
106
9. Referências Bibliográficas
1. BRASIL. Ministério da Aeronáutica. Estado-Maior da Aeronáutica. Doutrina Básica da FAB. Brasília, 1997. (DMA 1-1).
2. BRASIL. Ministério da Defesa. Doutrina Básica de Comando Combinado. Brasília, 2001. p. 15-16. (MD33-M-03).
3. _____. Ministério da Defesa. Manual de Doutrina Militar de Defesa. Brasília, 2001. (MD33-M-04).
4. _____. Ministério da Defesa. Manual do Processo de Planejamento de Comando para Operações Combinadas. Brasília, 2001. (MD33-M-05).
5. _____. Comando da Aeronáutica. Comando-Geral do Ar. Comando e Controle na Guerra. Brasília, 1999. (MCA 500-3).
6. _____. Escola de Comando e Estado-Maior da Aeronáutica. Exame de Situação. Rio de Janeiro, 2001. (Apostila).
7. _____. Escola de Comando e Estado-Maior da Aeronáutica. Estado-Maior - Funda-mentos. Rio de Janeiro, 2000. (Apostila).
8. _____. Escola de Comando e Estado-Maior da Aeronáutica. Azuver – Jogo de Guerra de Dupla Ação. Rio de Janeiro, [1997?]. (Manual do Sistema).
9. _____. Centro de Computação da Aeronáutica de São José dos Campos. Manual do Usuário do Módulo de Entrada de Planejamentos (MEP). São José dos Campos, [1997?].
10. BRONOWSKI. Jacob. As Origens do Conhecimento e da Imaginação. Brasília: Uni-versidade de Brasília, 1997.
11. CLAUSEWITZ. Carl von. De la Guerra. Tradución de R. W. Setaro. 2ª edición. Bar-celona: Labor, 1976.
12. CRUZ, Adriano. Lógica Nebulosa. Rio de Janeiro: UFRJ, 2002. (Apresentação).
13. DOUHET, Giulio. O Domínio do Ar. Rio de Janeiro: Instituto Histórico-Cultural da Aeronáutica, 1988.
14. FADOK, David S. Ten.-Cel. John Boyd e John Warden A Busca da Paralisia Estraté-gica pelo Poder Aéreo. Aereospace Power Journal em Português. p. 23-48. 1º Trimestre de 2001.
15. FERREIRA. Aurélio Buarque de Holanda. Novo Dicionário da Língua Portuguesa. Rio de Janeiro: Nova Fronteira, 1987.
107
16. FOX, Daniel B. A Conceptual Design for a Model to Meet the War-Gaming Needs of the Major Commands of the USAF. Maxwell: AU Press, 1985.
17. FUJIMOTO, Richard M. Time Management in The High Level Architecture. AI & Simulation. p.388-400. December, 1998.
18. GORDIJIN, Jaap, AKKERMANS, Hans, VAN VLIET, Hans. Business Modelling is not Process Modelling. Amsterdan: Vrije Universitat, [2001?].
19. GRUMBACH, Raul J. Prospectiva A Chave para o Planejamento Estratégico. p.76-86. Rio de Janeiro: Catau, 1997.
20. HIGHAM, Robin, Dr. PARILLO, Mark P. Dr. The Management Margin Essencial for Victory. Aerospace Power Journal, spring 2002.
21. HUGUES. Thomas J., Dr. O Culto da Rapidez. Airpower Journal, 4º Trimestre de 2002.
22. JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James. The Unified Software De-velopment Process. Reading, Massachusetts: Addison Wesley, 1999.
23. KIRKWOOD, Craig W. System Dynamics Methods: A Quick Introduction. Tempe: Arizona State University, 1998.
24. KRUCHTEN, Philippe. Software Development Process for a Team of One. The Ra-tional Edge, 2002, http://www.therationaledge.com/, capturado em 25 set 2002.
25. LEE, David B., Lt. Col.. (USAF). Wargaming – Thinkig for the Future. Airpower Journal, .
26. LEFFINGWELL, Dean, WIDRIG, Don. Managing Software Requirements: A Unified Approach. Reading, Massachussetts: Addison Wesley, 2000.
27. LIEPMAN JUNIOR, James M., Lt. Col. CnthInthXYZ, TACS, and Air Battle Manage-ment The Search for Operational Doctrine. Airpower Journal. Spring 1999.
28. Lógica Fuzzy. www.geocities.com/logicas2000/log01.htm, capturado em 13 ago. 2002.
29. MAQUIAVEL: Os Pensadores. São Paulo: Nova Cultural, 1999. p. 91-97.
30. NICHOLS, David, Maj. (USAF), TAGAREV, Todor, Maj. (Bulgarian Air Force).What Does Chaos Theory Means to Warfare? Airpower Journal, .
31. O. C. INCORPORATED. Joint Force Employment User Manual. Washington, 2000. Baixado do site http://www.dtic.mil/doctrine/jfe/jfeman.pdf em 15 dez 2003.
32. PAGE-JONES, Meilir. Fundamentos do Desenho Orientado a Objeto com UML. São Paulo: Makron Books, 2001.
108
33. PERLA, Peter P. The Art of Wargaming A Guide for Professional and Hobbyists. An-napolis: Naval Institute Press, 1990.
34. PIDD, Michael. Computer Simulation in Management Science. 3rd edition. p. 243-290. New York: John Wiley and Sons, 1994.
35. PROBASCO, Leslee. Ten Essencials of RUP – The Essence of an Efective Develop-ment Process. Rational White Papers, 2000.
36. SENGE, Peter M. A Quinta Disciplina. São Paulo: Best Seller, 1995.
37. SILICON GRAPHICS (Chile). Sistema de Mando Aéreo. [S.l.], [2001?] (folheto).
38. TZU, Sun. A Arte da Guerra. Rio de Janeiro: Record, 1983.
39. VICENTE, Paulo. Jogos de Empresas. p. 25-35 São Paulo: Makron Books, 2001.
40. WARDEN, John A. O Inimigo como um Sistema. Airpower Journal em Português, de 1999.
41. WILKES, Bobby J. (USAF). Silver Flag – Uma Concepção para o Aspecto Operacio-nal da Guerra. Aerospace Power Journal em Português, 2º Trimestre de 2002.
1