6|

Diseo arquitectnico
6.1| Introduccin
En esta parte del documento describiremos los pasos y la organizacin del sistema de forma ms especfica. A continuacin entraremos en ms profundidad en el diseo de la aplicacin, esto engloba los siguientes apartados: Patrones de diseo, se describirn los patrones de diseo que se han utilizado para disear la aplicacin. Diagrama de clases de diseo, en esta seccin aplicaremos los patrones de diseo para obtener el diagrama de clases de diseo final de la aplicacin. Diseo de navegabilidad, se mostrar la navegabilidad del sistema. Diseo de la BD, por ltimo, se implementar la persistencia mediante un sistema gestor de base de datos que d soporte a nuestro sistema.

6.2 | Patrones de Diseo

Los diferentes patrones de diseo de los que se han hecho uso para desarrollar la aplicacin se indican a continuacin:

6.2.1 | Patrn Modelo Vista Controlador (MVC)

El patrn de diseo Modelo-Vista-Controlador plantea un mtodo formal para separar los mdulos de entrada, de procesamiento y de salida de datos en una aplicacin y la forma de comunicacin entre dichos mdulos. Es decir, separa la lgica de negocio de la interfaz de usuario, facilitando as la evolucin por separado de ambos aspectos e incrementando la reutilizacin y la flexibilidad. Como digo, el Modelo Vista Controlador (MVC) es un estilo de arquitectura de software que separa los datos de una aplicacin, la interfaz de usuario, y la lgica de control en tres componentes distintos. El estilo de llamada y retorno MCV, se ve frecuentemente en aplicaciones web donde la vista es la pgina HTML y el cdigo que provee de datos dinmicos a la pgina. El modelo es el Sistema de Gestin de Base de Datos y la Lgica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista. El estilo fue descrito por primera vez en 1979 por Trygve Reenskaug, entonces trabajando en Samlltalk en laboratorios de investigacin de Xerox. La implementacin original est descrita en Programacin de Aplicaciones en Smalltalk- 80: Como utilizar Modelo Vista Controlador 1.

http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html

Este patrn es utilizado en mltiples frameworks: - Java Swing - Java Enterprise Edition (J2EE) - XForms (Formato XML estndar del W3C para la especificacin de un modelo de proceso de datos XML e interfaces de usuario como formularios web) - GTK+ (escritorio en C, toolkit creado por Gnome para construir aplicaciones grficas, inicialmetne para el sistema X Window) - ASP.NET MVC Framework (Microsoft) - Google Web Toolkit (GWT, para crear aplicaciones Ajax con Java) - Apache Struts (framework para aplicaciones web H2EE) - Ruby on Rails (framework para aplicaciones web con Ruby) - SEAM.

Descripcin del Patrn Modelo. Esta es la representacin especfica de la informacin con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema tambin puede operar con ms datos no relativos a la presentacin, haciendo uso integrado de otras lgicas de negocio y de datos afines con el sistema modelado. Entre otras cosas es responsable de: - Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento. - Define las reglas de negocio (la funcionalidad del sistema). - Lleva un registro de las vistas y controladores del sistema. - Si estamos ante un modelo activo, notificar a las vistas los cambios que en los datos pueda producir un agente externo.

Vista. Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario. Las vistas son responsables de: - Recibir datos del modelo y los muestra al usuario. - Tienen un registro de su controlador asociado (normalmente porque adems lo instancia) Controlador. Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.

Figura 6.1 Diagrama Modelo Vista Controlador

Muchos sistemas informticos utilizan un Sistema de Gestin de Base de Datos para gestionar los datos: en lneas generales del MVC corresponde al modelo. La unin entre capa de presentacin y capa de negocio conocido en el paradigma de la Programacin por capas representara la integracin entre Vista y su correspondiente Controlador de eventos y acceso a datos. MVC no pretende discriminar entre capa de negocio y capa de presentacin pero si pretende separar la capa visual grfica de su correspondiente programacin y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre s. Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente: 1. 2. El usuario interacta con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botn, enlace, etc.) El controlador recibe (por parte de los objetos de la interfaz-vista) la notificacin de la accin solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a travs de un gestor de eventos. El controlador accede al modelo, actualizndolo, posiblemente modificndolo de forma adecuada a la accin solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos estn a menudo estructurados usando un patrn de comando que encapsula las acciones y simplifica su extensin. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podra utilizar el patrn Observador para proveer cierta indireccin entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambio, pero an as el modelo en s mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice.

3.

4.

5.

La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

6.3 | Diagrama de clases de diseo

Vamos a ver ahora las clases de diseo que se han obtenido mediante la aplicacin del patrn MVC mencionado en el punto anterior. Para ello, organizaremos las clases segn en el apartado del patrn que se corresponda (Modelo, Vista o Controlador) Modelo. En este apartado la informacin se almacena en una base de datos o en XML. Junto a esto se tienen adems las reglas de negocio que transforman esa informacin (teniendo en cuenta las acciones de los usuarios). Es aqu donde se encuentran las Interfaces y clases que acceden directamente a la base de datos y que conforman los DAO. Vista. Como se ha dicho ya, la vista presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario. No encontraremos ninguna clase de diseo aqu ya que este apartado estar formado por las pginas .xhtml. Controlador. El controlador que como sabemos ms bien responde a eventos, normalmente son acciones que el usuario invoca que implica cambios en el modelo y tambin en la vista (interfaz). Como bien se ha indicado son acciones que el usuario invoca, por lo que es aqu donde se localizarn las clases Action del proyecto y har de puente entre el modelo y la vista.

A continuacin se muestra el esquema general del diseo que se ha propuesto, para seguidamente explicar los aspectos ms destacados de cada capa:

Figura 6.2 Esquema general diseo de la aplicacin Clases sistema. Dentro de las clases sistemas (tendremos las clases dominio y los diccionario (domain and dictionary) organizaremos las clases en diversos subsistemas para una mayor legibilidad, algunos de ellos relacionados entre s. En el siguiente diagrama se puede ver los distintos subsistemas que compondrn el conjunto de clases del sistema.

Figura 6.3 Clases sistema -

Ahora se pasar a describir cada subsistema

Subsistema gestin de usuarios y perfiles

Figura 6.4 Clases sistemas. Subsistema gestin de usuarios y perfiles -

Subsistema gestin de jugadores

Figura 6.5 Clases sistemas. Subsistema gestin de jugadores -

Subsistema gestin de equipos

Figura 6.6 Clases sistemas. Subsistema gestin equipos -

Subsistema gestin de colegiados

Figura 6.7 Clases sistemas. Subsistema gestin de colegiados -

Subsistema gestin de la competicin

Figura 6.8 Clases sistemas. Subsistema gestin de competicin -

Clases Modelo. Como en el anterior caso (para las clases del sistema) se va a separar las clases e interfaces que intervienen en el modelo en varios subsistemas (los mismos que anteriormente) donde se recoger las clases implicadas en cada subsistema. Subsistema de gestin de usuarios

Figura 6.9 Clases Modelo. Subsistema gestin de usuarios -

Subsistema de gestin de jugadores

Figura 6.10 Clases modelos. Subsistema gestin de jugadores -

Subsistema de gestin de equipos

Figura 6.11 Clases modelos. Subsistema gestin de equipos-

Subsistema de gestin de colegiados

Figura 6.12 Clases modelos. Subsistema gestin de colegiados -

Subsistema de gestin de competicin

Figura 6.13 Clases modelos. Subsistema gestin de competicin -

Clases Controlador. En este apartado vamos a recoger los distintos actions que va a tener la aplicacin para interactuar con las clases modelos y con la vista.
class Diagrama Clases Controlador Actions

MyClassNamingStraregy

Autenticador

ColegiadoAction

ColegiadoSearch

Jugador Action

Jugador Search

EquipoAction

EquipoSearch

UsuarioSearch

UserAdmi nAction

RecordarM ailAction

Competic onAction

Diccionar ioAction

Calendar ioSearch

Mantenimie ntoAction

Figura 6.14 Clases controlador A continuacin se detalla cada Action y sus relaciones con las Clases Modelos.

Colegiados

Figura 6.15 Clases controlador. Actions de colegiados -

Jugadores

Equipos

Usuarios Competicin Mantenimiento Otros