| Documentação |
|||
| Instalação |
Funcionamento |
Experiências |
| A documentação de nosso projeto foi
inteiramente feita através do programa JAVADOC, que acompanha o java, gerando uma documentação interna muito limpa e inte- ligível. Para acessá-la basta clicar aqui |
No deccorer do código, existem também
alguns comentários que nós achamos pertinentes colocar, bem como alguns comentários sobre características a serem implementadas e código de depuração que poderia ser útil no futuro. |
|
| Instalação |
|||
| Documentação |
Funcionamento |
Experiências |
| Requisitos: Para instalar o TCB-MUD alguns requisitos são necessários: -> Java SDK 1.4 ou superior -> JacORB previamente instalado e configurado Como JAVA é uma linguagem multi-plataforma, o software roda tanto em Windows quanto em Linux, sendo que nesta última plataforma o Software não foi testado. Instalação e Execução: -> Copie os arquivos para um diretorio, digamos EP3 -> Modifique os arquivos .BAT para conterem os diretórios (e classpath) corretos -> Rode makeidl para que os esqueletos sejam devidamente gerados -> Rode make para que tanto o servidor quanto o cliente sejam compilados -> Rode rodaserv para que o servidor seja inicializado -> Rode rodacli1 para que o usuário MASTER seja inicializado. Note que para usuarios diferentes, é necessário alterar o rodacli. O primeiro argumento da linha de comando passada ao programa contem o arquivo com a referencia para o controle (vide especificação), enquanto o segundo fornece o nome do usuario e o terceiro a senha do mesmo para autenticação. Inicialmente, o sistema só é capaz de reconhecer o usuário wizard (que é o usuário master) com a senha 123 Uso: Até agora o programa reconhece os seguintes comandos:
|
|||||||||||||||||||||||||||||||||||||||||||||
| Funcionamento |
|||
| Documentação |
Instalação |
Experiências |
| De acordo com nossa proposta, nosso software deveria
implementar um sistema de salas, avatares e coisas. Infelizmente devido ao pouco tempo que tivemos para dedicar ao projeto devido a outras atividades acadêmicas, bem como dificuldades encontradas durante a fase de implementação (que serão expostas mais abaixo), implementamos o software parcialmente, com as salar e os avatares plenamente funcionais. Assim, o funcionamento é o padrão de qualquer MUD: O usuário master se loga e a partir dai, pode criar usuarios, (nomes/senha) que poderão se logar ao sistema após terem sido criados. Uma vez logados, os avatares que estiverem na mesma sala irão ouvir tudo o que for dito naquela sala, sendo que sempre é possível migrar de uma sala a outra através das saídas. As saídas entre duas salas já existentes podem ser criadas pelos usuarios, e sempre que uma nova sala for criada, uma saída é automaticamente adicionada. As salas possuem um esquema de proteção, que nos diz se elas são públicas ou privadas, ou seja, se qualquer um pode entrar ou se somente o criador das mesmas é que tem acesso à sala. Outro fator interessante, é que os avatares podem mudar as descrições das salas, bem como suas próprias descrições. O sistema foi feito de maneira dinâmica e planejada, permitindo que futuramente, Bots construtores do mundo sejam implementados. |
| Experiências |
|||
| Documentação |
Instalação |
Funcionamento |
| Aprendemos muito fazendo esse trabalho. Algumas lições
foram muito positivas e outras serviram mesmo para chamar nossa atenção
para os cuidados que devemos ter com o desenvolvimento de projetos maiores. A primeira coisa que pudemos aprender, é como a Engenharia de Software pode auxiliar no projeto de sistemas grandes. Com um código superior a 1500 linhas, sendo desenvolvido a duas mãos, a documentação foi um fator fundamental para que conseguissemos desenvolver nosso software. Antes de começar o design do sistema em si, fizemos os use-cases, que mudaram muito pouco no decorrer da implementação, o mesmo ocorrendo com a IDL que foi gerada a partir deles. Outro ponto importante e muito positivo foi constatar a versatilidade com que o JAVA e o JacORB conseguem se comunicar. Em muitos momentos, passamos para funções ORB, POA, etc. Algumas vezes inicializamos novos objetos servantes através de objetos servantes, coisas que nós não fazíamos a menor idéia de que fossem possíveis. Entretanto, cada vez que necessitávamos fazer algo mais complicado deste tipo, tempo era consumido, e embora um mês tenha sido um prazo razoável para o desenvolvimento de um sistema desses, aprendemos a superestimar o tempo de desenvolvimento, devido a prováveis imprevistos, tanto de ordem técnica (como os citados acima) quanto de ordem pessoal (como a falta de tempo comum para reuniões, e acima de tudo, nossos outros compromissos com a graduação). Assim, algumas vezes tivemos de virar a noite para discutir e implementar certos aspectos mais problemáticos. Tivemos também um pequeno problema com concorrência no decorrer do código, que tentamos resolver através de monitores (depois que a espera ativa se mostrou desastrosa). E isto devido ao fato de que precisavamos instanciar um novo servante e manter esse objeto "vivo" mesmo fora do escopo da função que o havia criado. Enfim, quando estavamos pra entregar o projeto, fazendo alguns dos testes, acabou acontecendo algo muito legal: A gente parou de fazer os testes e começamos a brincar com o sistema. Isso nos motivou a levar o projeto adiante. Nós terminaremos de implementar a parte de objetos (assim que a graduação e os empregos) nos permitirem, e provavelmente submeteremos um artigo contando sobre essa experiência para o 1 Workshop de Jogos da SBC, que será realizado dia 10 de outubro no Ceara. |