ARENA Case Study ISABEL RAMOS FUENTES OSCAR JAVIER MUÑOZ

Porque el uso de un caso de estudio? Desarrollar actividades del proyecto de ingeniería del software. Uso integral. Mas realista y permite mejor toma de decisiones.

ARENA!!! Multi-Usuario, Sistema basado en web Organización, la realización de torneos. Añadir nuevos juegos. Anunciar torneos.

Pasos para el estudio del caso ARENA 1.Identificar el problema inicial. 1.Primera reunion. 2.Planteamiento inicial del problema 3.No hay presupuesto…sin fecha.

1. Declaracion del problema ARENA 1.Problema: El Internet y la WWW ha permitido la creación de comunidades virtuales. Esta comunidad puede ser pequeña o grande. Muchos juegos multijugador ahora incluyen el apoyo a las comunidades virtuales que son jugadores para el juego dado. Con jugadores que pueden recibir noticias acerca de las actualizaciones del juego y nuevos mapas del juego. Las compañías de juegos se aprovechan de esta infraestructura para generar ingresos y hacer publicidad de sus productos. Cada compañía de juegos desarrolla la comunidad como para cada juego individual. cada empresa utiliza una infraestructura diferente, conceptos diferentes y ofrecen distintos niveles de apoyo..

2. Ojetivos: Proporcionar una infraestructura para el funcionamiento de una arena, incluidos los juegos de nueva matriculación y los jugadores, los torneos a organizar y llevar registro de las puntuaciones de los jugadores. Proporcionar un marco de trabajo para los dueños de la liga para personalizar la secuencia de el número de partidos. Proporcionar un marco de trabajo para los desarrolladores de juegos, para el desarrollo de nuevos juegos o para la adaptación de juego existentes en el campo de trabajo. Proporcionar un infraestructura para los anunciantes.

3. Requerimientos funcionales: ARENA soporta 5 tipos de usuarios: Operador: debe ser capaz de definir los nuevos juegos, nuevos torneos y la gestión de usuarios. Los dueños de la liga: deben ser capaces de definir una nueva liga, organizar y anunciar nuevos torneos. Los jugadores: deben ser capaces de registrarse en la arena, jugar partidos, y solicitar la liga. Los espectadores: deben ser capaces de controlar cualquier partido, visitar la puntuación y la estática de partidos pasados. Anunciante: debe ser capaz de cargar nuevo anuncio.

4. Requerimientos no funcionales: Bajo costo de operacion: el operador debe ser capaz de instalar cualquier componente de campo sin necesidad de software adicional. Extensibilidad: el operador debe ser capaz de añadir nuevos juegos sin ninguna otra modificación del actual sistema. Escalabilidad: el sistema debe ser compatible con los torneos paralelos. Bajar los juegos en banda ancha: debe ser capaz de jugar partidos a través de un módem de 56k analógico y más rápido.

5. Objetivo del medio ambiente: Todos los usuarios deben poder acceder a la arena con un navegador Web, Java Script y los applets de Java. Las funciones de administración utilizadas por el operador no deben estar disponible a través de la web. El sistema debería funcionar en cualquier sistema operativo Unix

2. Identificando actores y escenarios. Desarrollar los casos de uso, los actores y escenarios. 5 actores (operador, propietario de la liga, jugadores, espectadores, y el anunciante). Medidas: 1.Ejemplo escenario (torneo Tic Tac Toe) 2.Enfoque en el segmento estrecho del sistema (por qué?) 3.Ejemplos y preguntas. Ahora podemos tener un coste inicial. 4. Escenarios mas cortos para cada actor (no detallado)

3. Identificando casos de uso. 1.Escenarios para los casos de uso Funciones relacionadas uso de un solo caso Funciones no relacionadas uso de varios casos de uso 2.condiciones de entrada, condiciones de salida y el flujo de eventos 3.acciones actor... mientras que

4. Mejorar la utilizacion de los casos identificando relaciones. Identificar los límites del sistema. Interacción detallada con el sistema. Detallar los casos de uso. Los desarrolladores deben ser capaces de definir la información intercambiada entre los actores. Aquí hay un ejemplo de caso de uso de un torneo organizado. Descubrimiento de flujo de los acontecimientos y el sistema de excepciones que debe manejar con la identificación del caso de uso detallado paso a paso.

5. Identificiacion de Requerimientos no funcionales Usabilidad (espectador) Fiabilidad (accidentes deben ser tratados) (reiniciar) Rendimiento (los jugadores deben ser capaces de jugar) Compatibilidad (operador debe ser capaz de añadir nuevos juegos) Ejecución (todos los usuarios deben acceder a la arena) Operación (anunciante no debe gastar el dinero) Legal (ofertas y respuestas a las necesidades de autenticación

conclusion Se desarrollo un software de alta calidad que cubre todas las expectativas del cliente Por lo que estos pasos se deben seguir para un mejor software

orgnizeTicTacToeTouranment New actor