Requerimientos Funcionales:

RF.1: Permitir la creación y edición de escenarios.

RF.2: Permitir la selección de una imagen de fondo para el escenario.

RF.3: Permitir mediante Drag and Drop posicionar en el escenario todos sus elementos fijos (pelota, puntos fijos, areas de salidas y obstáculos).

RF.4: Permitir asignar una cantidad, precio y características particulares para cada elemento de la lista de elementos disponibles que tendrá el escenario.

RF.5: Permitir asignar un tiempo máximo de resolución para el escenario.

RF.6: Permitir asignar al escenario las constantes para la resolución del puntaje.

RF.7: Validar que el escenario tenga posicionada una pelota y al menos un area de salida.

RF.8: Permitir persistir el escenario.

Atributos del Sistema:

AS.1: El escenario debe persistirse en xml y estará compuesto por el archivo xml más un archivo de imagen para el fondo del escenario.

Análisis de Casos de Uso:

CU.1 - Crear un escenario: El usuario accederá desdela pantalla principal la opción de Nuevo Escenario. La pantalla quedará dividida en cuatro zonas: Una barra de herramientas con un botón por cada elemento, una zona de edición para el escenario donde el usuario podrá posicionar los elementos fijos utilizando Drag and Drop, una zona donde el usuario pueda asignar las propiedades del escenario y una zona con botones para manipular el Drag and Drop. Para agregar un elemento fijo (punto fijo, pelota, obstaculo o área de salida) el usuario deberá presionar el botón correspondiente y luego hacer clic en la zona del escenario donde el usuario quiera posicionar el elemento. Para ingresar las propiedades de un elemento que no sea fijo el usuario presionará el boton correspondiente de la barra de herramientas y se desplegará un panel para que se ingresen las propiedades del elemento. Una vez que el usuario termine de crear el escenario presionará un botón Guardar que lo persistirá para luego poder subirlo al servidor. Requerimientos abarcados: RF.1, RF.2, RF.3, RF.4, RF.5, RF.6, RF.7, RF.8.

CU.2 - Editar un Escenario: Desde la barra de menú el usuario accederá a la opción Abrir Escenario. En este momento se desplegará un file chooser para que el usuario seleccione que escenario desea abrir. Una vez abierto se procede a editarlo de la misma manera descripta en CU.1. Requerimientos abarcados: RF.1, RF.2, RF.3, RF.4, RF.5, RF.6, RF.7, RF.8, RF.9.

Interfáz Gráfica:

Editor de Escenarios

Diseño del modelo:

A continuación se muestra el diagrama de clases del modelo:

Modelo

Stage: Representa al escenario completo y contendrá las propiedades del escenario, como ser la gravedad, etc. También contendrá las propiedades de todos los elementos y un ElementContainer con todos los elementos fijos del escenario. Esta clase es una fachada entre las clases del modelo del cliente y las clases del editor para favorecer la reutilización.

ElementContainer: Es la clase que contiene a todos los elementos que aparecen en el escenario. Es contenida por Stage y contiene una pelota y una coleccion por cada tipo de elemento. Posee los metodos para recorrer las colecciones y agregar elementos.

Representacion en xml de un Escenario:

Los tags coinciden con los nombres de las clases que representan a las entidades, los atributos de cada tag coinciden con los nombres de los atributos de las clases.

Arquitectura:

A continuación se muestra el diagrama de arquitectura del editor:

Hay dos módulos principales: presentation y serialization. Cada módulo estará representado físicamente por un directorio de igual nombre que contendrá los archivos fuentes de todas las clases pertenecientes al mismo. Además cada una de estas clases pertenecerá a un namespace también de igual nombre que el módulo. La comunicación entre módulos es atravez de una única clase que actua como fachada del modulo disminuyendo al mínimo el acoplamiento y dependencias entre módulos. Los módulos persistence, model y service estarán dentro de un directorio serialization aparte para que puedan ser llamados tanto por la aplicacióon cliente como por el editor.

presentation: En este módulo están todas las clases referidas a la interfaz de usuario del editor. Sus clases son:

editor::presentation::StageEditorGui: Representa a la vista del patrón MVC. Es una interfaz que agrupa a todos los métodos que pueden ser llamados por el controller. No contiene ninguna referencia a ninguna libreria gráfica en particular.

editor::presentation::StageEditorGuiGlade: Es la implementación de la interfaz EditorDeEscenariosGui utilizando Glade.

editor::presentation::StageEditorHandler: Es el Controller del patrón MVC. Es la unica clase de presentation que tiene acceso al módulo serialization utilizando al BusinessDelegate, que es la representación del model del patrón MVC.

serialization: En este modulo estarán todas las clases que representan a la lógica de la aplicación. Contiene a su vez a tres módulos: model, service y persistence.

game::serialization::BusinessDelegate: Contiene todos los métodos necesarios para acceder al modelo desde el módulo presentation. Es un Facade entre serialization y presentation.

game::serialization::model: Este módulo contiene a todas las entidades que representan a los conceptos de la aplicación.

game::serialization::service: Este módulo contiene a todos los servicios de la aplicación. Un servicio se define como toda acción o evento que pueda recibir una entidad del modelo pero que no pueda incluirse dentro de la clase de la entidad por cuestiones de bajo acoplamiento y alta cohesión. Por ejemplo, un método que retorne una posición de la pelota iría en la clase de la pelota ya que no involucra conceptos externos, en cambio el método que persiste a la pelota en un xml no puede ir en la clase pelota ya que en este caso se requiere insertar código externo al modelo, como ser el manejo de un archivo xml. Si este código se insertara en la misma clase pelota esta clase cumpliria dos funciones, representar a una pelota y persistir a una pelota, con lo cual hay baja cohesión. Además se requeriría acoplar codigo dependiente de la librería xml a usar, con lo cual hay alto acoplamiento. Para solucionar esto el método para persistir una pelota debe estar en una clase aparte a la que llamaremos service.

game::serialization::service::StageService: Es una interfaz que posee todos los servicios que afectan a la entidad Stage y a las entidades que componen a Stage. Es el único servicio necesario ya que Stage es la única aggregate root.

game::serialization::service::StageServiceImpl: Es la implementación de StageService. Esta clase utilizará a las clases provistas por el módulo de persistencia a medida que las necesite.

domain::service::ServiceLocator: Esta clase juega el papel de Facade del módulo service y al mismo tiempo es un Factory de servicios. El business delegate nunca instanciará un service directamente, sino que lo obtendrá a partir del ServiceLocator.

game::serialization::persistence: Este módulo contendrá a todas las clases involucradas en la persistencia del modelo.

game::serialization::persistence::StageXmlRepository: Es una interfaz que representa a un repositorio de escenarios, o sea que provee los metodos necesarios para persistir y recuperar un escenario en un archivo xml.

game::serialization::persistence::StageXmlRepositoryTinyXml: Es la implementación del EscenarioXmlRepository utilizando a la libreria TinyXml.

game::serialization::persistence::RepositoryFactory: Esta clase juega el papel de Facade del módulo y a su vez de factory proveyendo repositorios a los services a travez de interfaces, independizando así a los services de la librería framework utilizada.

Taller I