UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO. Licenciatura em Engenharia Informática e Computadores Alameda e Taguspark

Transcrição

1 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 ZOOLÓGICO 1 Domínio da aplicação O objectivo do projecto é prototipar o jogo ZOOLÓ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:

2 random(0, 1) a.especie.idademaxima a.fome + 1 morre(a) = 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.fome 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 ZOOLÓ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: custocriarhabitat(h) = h.area khabitat h.area custoremoverhabitat(h) = 2 khabitat 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 se a.fome <> 0 igual(a) dif erente(a) + espaco(a) 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

3 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 ZOOLÓ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 ZOOLÓGICO é dada pela regra: round( satisfacao(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 ksatisfacao, 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 m 2. 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 kminutos, que é instanciada no início do jogo. 3

4 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, fome. 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 ZOOLÓGICO O ZOOLÓ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 ZOOLÓ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 ZOOLÓ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

5 4 1 o Projecto No primeiro projecto pretende-se testar as funcionalidades principais do ZOOLÓ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

6 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 ZOOLÓ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

7 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 JAX- WS. 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 ZOOLÓ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 ZOOLÓGICOcomo serviços locais. Valorizar-se-ão soluções que incluam uma alternativa de build que construa um servidor centralizado do ZOOLÓGICO. 7