UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR

UNIVERSIDADE TÉCNICA DE LISBOA
INSTITUTO SUPERIOR TÉCNICO
Licenciatura em Engenharia Informática e
Computadores
Alameda e Taguspark
Sistemas Distribuídos e Engenharia de Software
Projecto de 2010/2011
Z OO L ÓGICO
1
Domínio da aplicação
O objectivo do projecto é prototipar o jogo Z OO L ÓGICO. Neste jogo, que se pretende que
no futuro venha a rivalizar com o jogo FarmVille do Facebook, múltiplos jogadores têm
que gerir zoos e colaborar com outros zoos para aumentar a satisfação dos seus animais.
Cada zoo é gerido por um jogador apenas e possui os seguintes elementos: habitats,
animais e recursos. Os habitats têm uma área e os animais localizam-se nos habitats.
Cada animal pertence a uma espécie e consome uma porção de recursos em cada período.
A idade do animal corresponde ao número de períodos desde que foi criado.
A quantidade de recursos que um animal a, de uma dada espécie a.especie, consome
num período depende da espécie e da idade do animal, e é dada pela regra:
recursoConsumido(a) = a.especie.recurso × (1 +
a.idade
)
kIdade
Em que a.especie.recurso representa a quantidade de recursos de referência que um
animal da espécie a.especie consome num período, a.idade denota a idade do animal
no período e kIdade é uma constante que se pretende afinar durante a prototipagem de
forma a que o jogo seja equilibrado.
Os animais envelhecem e eventualmente morrem. A probabilidade de um animal
morrer num dado período é dada pela regra:
a.especie.idadeM axima ×
morre(a) =
random(0, 1)
a.f ome + 1
a.idade
Em que a.especie.idadeM axima representa a idade máxima que um animal da espécie pode atingir, dada em número de períodos, e a.f ome representa a quantidade dos
recursos a consumir no período anterior e que o animal a efectivamente não consumiu
dado não ter havido recursos disponíveis no Z OO L ÓGICO. Se o valor devolvido pela
regra morre for menor que 1 então o animal é retirado do jogo.
Os animais podem ser trocados do seu habitat actual para outro, dentro do mesmo
zoo, sem qualquer custo de recursos.
Os habitats podem ser criados e removidos. Naturalmente, quando um habitat é
criado, este não possui animais, e para ser removido é necessário retirar os animais e
colocá-los noutros habitats. A criação e remoção de habitats também consome recursos
em função da sua dimensão. As duas regras abaixo indicam os custos de criação e remoção de habitats:
h.area
kHabitat
h.area
custoRemoverHabitat(h) =
2 × kHabitat
custoCriarHabitat(h) =
Em que h.area indica a área do habitat e kHabitat é uma constante que se pretende
afinar durante a prototipagem.
Por outro lado, a criação de animais também consome recursos e depende da espécie
do animal. Para criar animais e habitats o jogador tem que ter recursos suficientes. A
espécie do animal a criar é escolhida aleatoriamente e se o jogador não possuir os recursos
necessários para a espécie escolhida, então o animal não é criado. Contudo, em cada 10
períodos um jogador pode criar um animal sem custos.
A satisfação de um animal num dado período é dada pela regra:
satisf acao(a) =
0
igual(a) − dif erente(a) + espaco(a)
se a.f ome <> 0
se a.f ome = 0
em que:
igual(a) = 3 × a.habitat.populacaoEspecie(a.especie)
dif erente(a) = 2 × (a.habitat.populacao − a.habitat.populacaoEspecie(a.especie))
espaco(a) = round(a.habitat.area/a.habitat.populacao)
2
onde a.habitat.populacao denota o número de animais no habitat onde o animal a
se encontra num determinado período e a.habitat.populacaoEspecie(a.especie) denota o
número de animais da espécie a.especie nesse habitat.
Por outro lado os recursos do Z OO L ÓGICO aumentam em função da satisfação dos
animais em cada período, dado que um zoo com animais satisfeitos tem mais visitantes.
O contributo da satisfação de um animal para o aumento dos recursos do Z OO L ÓGICO é
dada pela regra:
round(
satisf acao(a) × a.especie.impacto
)
kSatisf acao
Em que a.especie.impacto representa o interesse que uma determinada espécie de
animal desencadeia nos visitantes.
Pretende-se prototipar o jogo para decidir quais os melhores valores para as constantes kIdade, kHabitat e kSatisf acao, que são inteiros maiores que 0.
2
O Jogo
O jogador que possui mais recursos vence o jogo.
Considere para este jogo uma simulação com as seguintes espécies:
• Leão: criar(10), recurso(20), impacto(30), esperança(25)
• Elefante: criar(20), recurso(30), impacto(40), esperança(100)
• Águia: criar (5), recurso(10), impacto(15), esperança(15)
No início do jogo cada jogador tem 100 recursos para gerir o seu zoo, com uma área
disponível de 1000 m2 .
Os jogadores podem fazer todas as alterações ao seu zoo que desejem entre cada período. Essas alterações são:
• criar habitat
• remover habitat
• criar animal e colocá-lo em habitat
• trocar animal de habitat
Sempre que um jogador interage com o jogo é verificado se o período actual terminou.
Caso o período tenha terminado procede-se às fases abaixo pela ordem definida. Os
períodos têm uma duração de kM inutos, que é instanciada no início do jogo.
3
1. INICIALIZA: (a) Verifica os animais que morrem e retira-os do jogo; (b) incrementa
a idade de cada um dos restantes animais.
2. ALIMENTA: (a) Verifica o que cada animal necessita de consumir; (b) subtrai essa
quantidade da quantidade total de recursos do zoo; (c) regista para cada animal
que não foi convenientemente alimentado a quantidade em falta, f ome.
3. VISITA: (a) Calcula os recursos gerados pelas visitas e adiciona à quantidade total
de recursos do zoo.
Note-se que estas fases podem de ter de ser executadas diversas vezes se porventura
tiverem passado diversos períodos desde a última interacção de um jogador com o zoo.
A pontuação de um jogador, recursos do seu zoo, nunca pode ser negativa, pelo que
apenas pode criar habitats e animais se tiver recursos e durante a fase ALIMENTA apenas alimenta animais enquanto tem recursos disponíveis.
3
Arquitectura Distribuída do Z OO L ÓGICO
O Z OO L ÓGICO deverá ser suportado por uma arquitectura distribuída. Essa arquitectura será distribuída entre dois tipos de servidores: apresentação e negócio. O servidor
de apresentação é único e é responsável pela lógica de apresentação da aplicação e faz
pedidos ao servidor de negócio. No servidor de negócio é executada a lógica de negócio
do Z OO L ÓGICO, contém as entidades de domínio e delega num repositório a persistência
destas.
Existem múltiplas instâncias do servidor de negócio. Cada instância gere um subconjunto de zoos. Ou seja, cada zoo terá o seu estado replicado em um ou mais servidores
de negócio. Cabe ao servidor de apresentação o papel de, para cada comando solicitado
pelo utilizador, agulhar os pedidos de invocação de serviços para os servidores de negócio que sejam relevantes para o(s) zoo(s) afectado(s) pelo comando.
Esta arquitectura distribuída do Z OO L ÓGICO pretende alcançar duas principais vantagens. Em primeiro lugar, como se espera que o número de jogadores venha a aumentar
consideravelmente em função do sucesso do jogo, é necessário que o sistema seja escalável; ou seja, que se possa adaptar a maiores volumes de utilização pela simples inserção de mais servidores de negócio. Como cada servidor de negócio apenas gere um
sub-conjunto de zoos, só irá receber pedidos de serviços para os zoos em causa. Consequentemente, a carga é dividida entre as várias instâncias de servidores de negócio,
contribuindo para a escalabilidade do sistema. (Note-se que, embora também pudesse
ser interessante suportar a existência de múltiplas instâncias do servidor de apresentação,
tal está fora do âmbito do enunciado.)
Como segunda vantagem, a existência de várias instâncias de servidores de negócio
introduz maior tolerância a faltas. Por um lado, se uma parte dos servidores de negócio
falharem, os restantes servidores (que se mantêm correctos) podem continuar a servir
comandos sobre os zoos que mantêm. Como cada zoo pode ser replicado em mais que
um servidor de negócio, tal implica que, se o grau de replicação for suficiente, todos os
zoos possam continuar disponíveis mesmo quando alguns servidores de negócio estejam
indisponíveis.
4
4
1o Projecto
No primeiro projecto pretende-se testar as funcionalidades principais do Z OO L ÓGICO,
implementar o modelo de domínio, assegurar a sua persistência, encapsular o domínio
por uma camada de serviços e suportar invocações remotas desses serviços usando web
services.
4.1
Requisitos Funcionais
As funcionalidades a implementar nesta primeira fase devem permitir testar o jogo na
sua quase totalidade. Assim, as funcionalidades a implementar são:
• criar habitat
• remover habitat
• criar animal e colocá-lo em habitat
• trocar animal de habitat
• listar o conteúdo de um zoo
• listar todos os zoo’s existentes
4.2
Interface Utilizador
A interface utilizador do primeiro projecto deve primar pela simplicidade. Assim ela
deverá ser uma consola de texto com linha de comando que permita aos jogadores visualizar o estado do jogo e dar as suas instruções de jogo numa linha de comando. Não
se considera lógica de apresentação complexa, pelo que não existe a noção de contexto
de interacção, ou seja, é necessário que os comandos recebam como argumentos toda a
informação necessária para desambiguar a execução. Por exemplo, quando se pede para
criar um animal de habitat deve-se indicar em que contexto, zoo, a operação deve ser
executada.
Os dois comandos para visualização são:
LZoo
EZoo <nome-zoo>
em que, respectivamente, um jogador visualiza a lista de zoo’s existentes:
Zoo’s do ZooLógico
{<nome-zoo>: \tab Recursos <recursos> \newline}
e obtém o estado de um zoo:
5
ZooLógico <nome-zoo>: Recursos <recursos>
Habitats: Número <numero-de-habitats> Área Livre <área>
{<nome-habitat>: \tab Área <área> \newline
{<nome-espécie>: \tab <numero-animais-espécie> \newline}}
Animais:
{<nome-animal>: \tab Espécie <nome-espécie> \tab Idade <idade>
\tab Habitat <nome-habitat>}
Note-se que todas as entidades de um zoo, habitats e animais, possuem um identificador único, por exemplo, a identificação de um habitat é única no contexto do seu zoo.
Por outro lado, zoo’s possuem uma identificação única no contexto do jogo. Dado que
o jogo apenas se encontra na fase de prototipagem não existe nenhuma restrição sobre a
estrutura dos identificadores, podendo ser qualquer sequência de caracteres.
Os comandos de alteração que os jogadores podem dar são:
CZoo <nome-zoo>
CHabitat <nome-zoo> <nome-habitat> <num-área>
RHabitat <nome-zoo> <nome-habitat>
CAnimal <nome-zoo> <nome-animal> <nome-habitat>
MAnimal <nome-zoo> <nome-animal> <nome-habitat-destino>
Que, respectivamente, criam um zoo, criam um habitat com a dada área, removem o
habitat, criam um animal e colocam-no no habitat dado e movem um animal do primeiro
para o segundo habitat.
Uma vez dado um comando, o Z OO L ÓGICO apresenta ao jogador uma mensagem sobre a execução do comando. Nos casos em que há insucesso na execução do comando as
seguintes mensagens de erro, a lista não pretende ser exaustiva, poderão ser mostradas:
Já existe um zoo|habitat|animal com identificação <nome>
Não existe o zoo|habitat|animal <nome>
O animal|habitat <nome> não pertence ao zoo <nome>
Não existem recursos suficientes para criar habitat|animal
Não existe área disponível para criar o habitat
Não existem recursos suficientes para remover habitat <nome>
O habitat <nome> não pode ser removido pois tem animais
O animal <nome> não se encontra no habitat <nome>
4.3
Requisitos Não Funcionais
O sistema deve estar dividido entre um único servidor de apresentação e múltiplas instâncias de servidores de negócio, tal como descrito na Secção 3.
Cada instância do servidor de negócio armazenará num repositório local os dados
relativos a um sub-conjunto de zoos. Por simplicidade, deve assumir-se que o número
de instâncias, N , é pré-definido e não muda durante a execução do sistema.
6
Nesta fase do projecto, deve assumir-se que os zoos não são replicados. Ou seja, cada
zoo é mantido por apenas um servidor de negócio.
Cada zoo é atribuido a um (e um só) servidor de negócio da seguinte forma: para um
dado zoo, o servidor de negócio que manterá o seu estado é dado por hash(zoo.id) mod N =
i, em que hash é uma função de dispersão que retorna valores entre 0 e N − 1.
Cabe ao servidor de apresentação agulhar os comandos relativos a determinado jogador para o servidor de negócio correspondente.
A medição do tempo é centralizada no servidor de apresentação. Ou seja, não é permitida qualquer implementação em que os servidores de negócio consultem o seu relógio
local para determinar se aconteceu novo período do jogo. Qualquer informação sobre o
tempo actual deverá ser obtida através do servidor de apresentação.
A invocação remota de operações de cada servidor de negócio por parte do servidor de apresentação deve ser suportada por Web Services usando a plataforma JAXWS. Deixa-se ao critério dos alunos a escolha entre uma abordagem contract-first ou
implementation-first. O número de instâncias, N , de servidores de negócio é um valor
pré-definido bem conhecido pelo servidor de apresentação, assim como o endereço do
endpoint de cada servidor de negócio.
Durante o desenvolvimento pode ser conveniente poder testar apenas o código funcional do Z OO L ÓGICOpara separar a depuração da implementação dos requisitos funcionais da dos requisitos não-funcionais. Desta forma, é desejável que o servidor de
apresentação e o servidor de negócio possam ser, se o programador o desejar, unificados
num servidor apenas. Neste cenário, o servidor de apresentação invocará os serviços do
Z OO L ÓGICOcomo serviços locais. Valorizar-se-ão soluções que incluam uma alternativa
de build que construa um servidor centralizado do Z OO L ÓGICO.
7