Modelo de Arquitectura de 4+1 Vistas

30 de noviembre de 2009

Torneos Virtuales

Índice
1. Modelo de 4+1 Vistas 2

2. Vista Lógica 3

3. Vista de Componentes 3
3.1. Descripción de la Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Respresentación de la Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.1. El dominio del Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.2. Construcción del Partido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.3. Mediador del Partido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.4. Persistencia del Partido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.5. Sistema de Apuestas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Modelo de Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4. Vista de Procesos 10

5. Vista de Despliegue 11

6. Vista de Casos de Uso 12

1
1. Modelo de 4+1 Vistas
En muchos libros se ha visto que se intenta capturar todos los detalles de la arquitectura de un sistema en
un único diagrama. Esto implica que quienes necesiten interpretarlo tengan que recurrir a una enorme cuota
de esfuerzo para lograr comprender todos los planos y aspectos que los diseñadores y desarrolladores quieren
exhibir en dicho diagrama. Mucho más grande será el esfuerzo si quien lo interpreta es completamente ajeno al
proyecto y/o equipo de desarrollo.

Para remediar este problema se pensó en un modelo que pudiera disgregar las partes fundamentales de la
aplicación para lograr una mayor comprensión y asimilación de la información que se muestra, a la vez de
aplicar un mayor nivel de detalle para cada uno de los aspectos importantes que conforman la arquitectura de
un sistema: Modelo de 4+1 Vistas.

Cada una de estas partes disgregadas llamadas <<vistas>> se reere a un conjunto de intereses de diferentes
<<stakeholders>> del sistema:

La vista lógica describe el modelo de objetos del diseño cuando se usa un método de diseño orientado a
objetos. Si el diseño es muy orientado a los datos pueden utilizarse alternativas de vista lógica como ser
diagramas de Entidad-Interrelación, entre otros.

La vista de componentes describe la organización est
ática del software en su ambiente de desarrollo.

La vista de procesos describe los aspectos de concurrencia y sincronizaci
ón del diseño.

La vista de despliegue describe el mapeo del software en el hardware y reeja los aspectos de distribución.

Los diseñadores de software pueden organizar la descripción de sus decisiones de arquitectura en estas cuatro
vistas, y luego ilustrarlas con un conjunto reducido de casos de uso o escenarios, los cuales constituyen la quinta
vista.

La arquitectura del software se trata de abstracciones, de descomposici
ón y composici
ón, de estilos y est
ética.

Tambi
én tiene relación

con el diseño y la implementación
de la estructura de alto nivel del software. Los

diseñadores construyen la arquitectura usando varios elementos arquitect
ónicos elegidos apropiadamente. Estos
elementos satisfacen la mayor parte de los requisitos de funcionalidad y performance del sistema así como
tambi
én otros requisitos no funcionales tales como conabilidad, escalabilidad, portabilidad y disponibilidad del
sistema.

2
2. Vista Lógica
Ver documento adjunto sobre Vista Lógica de la aplicación.
Dicho documento describe detalladamente todos los módulos del negocio haciendo uso de diagramas de clases
y de secuencia para facilitar y profundizar la comprensión del modelo.

3. Vista de Componentes
3.1. Descripción de la Vista

La vista está basada en la notación de Booch limitándose a aquellos items relevantes para la arquitectura.
Está orientado a la distribución del sistema en pequeños paquetes (o subsistemas) identicando cada una de
las partes con la idea de asignar a grupos más reducidos de desarrollo una tarea especíca. Divide y vencerás.
Una vez identicadas las partes (partición, agrupamiento, visibilidad) y habiendo avanzado con aspectos
principales en la implementación de dichas partes se procedió luego a la asignación de las reglas que van a regir
la arquitectura de Desarrollo.

3.2. Respresentación de la Vista

Se utiliza un diagrama de paquetes para señalar las relaciones importa y exporta del sistema.
Un conector <<import>> denota una dependencia de paquetes (al menos un elemento del paquete
depende de otro elemento del otro). También se denota dependencia bidireccional.
Una relación de realización indica que existe una interfaz visible y accesible como único medio de acceso al
paquete. Mientras que una relación de Anidación signica un paquete dentro de otro.
A continuación se diferencian 5 partes principales del sistema:

el dominio del modelo

el proceso de construcción de los componentes de un Partido

el Mediador de un Partido

el modelo de persistencia de datos de un partido

y el sistema de apuestas

3.2.1. El dominio del Modelo

La estructura de paquetes del dominio del sistema se muestra a continuación.

3
 Existe una relación de realización entre Estrategias y Equipos, siendo EstrategiaEquipo la interfaz acce-
sible y visible del paquete Estrategias.
Entre el paquete jugadores y los paquetes habilidades y comandos existe una relación de Anidación. Del
mismo modo se muestra el paquete juego conteniendo algunos paquetes indicados en la gura que se relacionan
directamente con un Partido.
Con color distinto se muestra los paquetes donde las relaciones de import son con paquetes externos al
dominio (builder, mediador, observable).

3.2.2. Construcción del Partido

El diagrama de la etapa de generación de un Partido (buiderPartido) incluye el paquete juego como externo
al contexto de construcción (de color distinto) pero son aquellos objetos que son creados a partir de la interfaz
BuilderPartido (relación de realización).
Muestra el paquete excepciones como anidado a builder y este a controlador.

4
3.2.3. Mediador del Partido

Siguiendo la misma idea de mostrar los conponentes principales de cada contexto, se indica en el diagrama de
paquetes las relaciones entre el paquete mediador y los paquetes jugadores (sus comandos) y partido. Indicando
el paquete juego como externo a este apartado y denotando también cómo se relacionan con el paquete arbitraje
que le sirve de soporte al mediador.

NOTA: cabe destacar que tanto el constructor del partido como el mediador se encuentran dentro del paquete
controlador.

3.2.4. Persistencia del Partido

Resulta ser un diagrama de paquetes similar al mediador. Se relaciona a través de imports con los paquetes
externos jugadores y partidos. Tiene anidado en su interior el paquete eventos.

5
3.2.5. Sistema de Apuestas

La arquitectura de desarrollo del Sistema de apuestas sólo podría describirse completamente si se tuviesen
todos sus elementos identicados. Sin embargo, es posible listar las reglas que rigen su arquitectura.
Se reconocen cuatro paquetes principales:

el de apuestas: que incluye al apostador y a la apuesta en si, en sus dos tipos - por torneo o por fecha.
Los paquetes anidados hacen que se diferencie claramente cada tipo;

el de torneos: que del mismo modo anidan cada tipo - por puntos (que contiene la tabla de posiciones) y
por eliminatoria (que contiene el árbol de clasicación);

el de xture: que es dependiente del tipo de torneo que se está llevando a cabo;

y el de equipos: que además servirá de conexión entre este sistema y el simulador de partidos.

3.3. Modelo de Capas

El Modelo de Capas dene 4 niveles principales de subsistemas (PRESENTACIÓN, SERVICIOS, DOMINIO,

PERSISTENCIA). Cada capa tiene una responsabilidad bien denida la cual servirá de guía para mejoras a
n de minimizar el desarrollo de complejas redes de dependencias entre módulos y así permitir estrategias de
desarrollo más exibles y realizables.
Se adopta la notación de Booch para la realización de los diagramas.
Este modelo distingue las 2 principales partes del sistemas de Torneos Virtuales: el de apuestas y el simulador
de partidos. Y engloba además los diferentes componentes del sistema, los cuales se pueden distinguir a partir
de los paquetes descriptos anteriormente.

6
 El diagrama de componentes del sistema de apuestas muestra cómo es que a partir de registrar a
los equipos participantes en algún tipo de torneo, más el registro de apostadores (CAPA PRESENTACIÓN)
se procede a la construcción y control de un Torneo especicado (CAPA SERVICIO), el cual va a regir las
reglas del negocio del sistema de apuestas a través de sus componentes: Torneo, xture correspondiente, equipos
participantes, partidos a jugarse (DOMINIO).
A su vez se proveen los componentes de persistencia de las estadísticas de los partidos jugados y por jugarse,
de los datos de los equipos y de los torneos vigentes (CAPA PERSISTENCIA).
Cabe destacar que el componente Partido se vale del simulador de partidos (subsistema bien denido y
externo) para la transmisión de un partido determinado.
No se dijo nada aún de las apuestas. Dado un componente RegistroDeApuestas cuya principal función será la
de tomar las apuestas realizadas (PRESENTACIÓN) según el tipo de apuesta que se desee (DOMINIO), el obje-
tivo es llevar el control y gestión de dichas apuestas (SERVICIO) y el resguardo de sus datos (PERSISTENCIA)
para su efectiva liquidación.

En cuanto al diagrama de componentes del simulador de partidos se reconoce cada una de sus
capas: Dado un formato de conguración y un comando de ejecución como punto de inicio de un partido
(PRESENTACIÓN) se procede a la construcción y composición (SERVICIO) de cada una de las partes y del

7
todo de un partido (DOMINIO). A su vez, a medida que evoluciona el partido (como simulación) existe un
controlador-mediador de acciones el cual se vale de las estrategias que aplica cada equipo ante determinadas
situaciones (la inteligencia del sistema) que sirve de nexo entre las acciones de los jugadores y los comandos de
ejecución (nuevamente CAPA DE SERVICIOS). Finalmente, ante cada Evento del partido, se almacenan los
datos a n de poder reproducirlo cuando sea requerido (PERSISTENCIA).

8
9
4. Vista de Procesos
El sistema puede dividirse en dos grandes procesos o aplicaciones, que interactúan mediante archivos en
formato XML.

Por un lado, se cuenta con una aplicación web para la administración de apuestas. Ésta se encarga de
manipular datos de usuarios, torneos, equipos, partidos, armado de xtures y administración de las apuestas
que cada usuario realiza para los torneos correspondientes.
De acuerdo a los xtures diagramados y a los equipos existentes, el sistema debe generar la información
necesaria para invocar y alimentar el proceso responsable de simular los partidos de fútbol.

El siguiente diagrama esquematiza a ambos procesos interactuando:

El simulador de partidos es una aplicación de escritorio, recibe y parsea el archivo de conguración donde
se especica la duración del partido, los equipos participantes, los jugadores que conforman cada equipo, etc.,
originando un encuentro y desarrollando toda la lógica del juego. Al nalizar, persiste los resultados del encuen-
tro.

El sistema de apuestas se sirve del archivo de resultados para alimentar la base de datos que permite generar
las tablas de posiciones y el árbol del torneo basado en eliminatorias.

Los procesos son representados por:

El browser donde corre el sistema web de apuestas; si corre en forma local, también coexistirá con el
web server.

Main thread, único hilo donde se desarrolla la lógica de la simulación.

10
5. Vista de Despliegue

Del documento Planos Arquitectónicos: El Modelo de  4+1 Vistas de la o Arquitectura del Software de
Philippe Kruchten: La arquitectura física toma en cuenta primeramente los requisitos no funcionales del sistema
tales como la disponibilidad, conabilidad (tolerancia a fallas), performance, y escalabilidad. El software corre
sobre una red de computadores o nodos de procesamiento (o tan sólo nodos). Los variados elementos identicados
redes, procesos, tareas y objetos requieren ser mapeados sobre los variados nodos. Esperamos que diferentes
conguraciones puedan usarse: algunas para desarrollo y pruebas, otras para emplazar el sistema en varios sitios
para distintos usuarios. Por lo tanto, el mapeo del software en los nodos requiere ser altamente exible y tener
un impacto mínimo sobre el código fuente en sí.

En nuestro software tenemos nodos bien denidos que agrupan los distintos componentes. En lo que respecta
a la aplicación web de apuestas, los nodos que comprenden el despliegue y puesta en funcionamiento son:

Cliente: Es el nodo que agrupa todos los componentes que interactúan con el usuario en forma directa
mediante teclado y monitor. Estos pueden ser un navegador web y/o cualquier anexo necesario para tal
interacción.

11
 Web Server: Agrupa toda la lógica utilizada en la administración de los datos de la aplicación web y la
interfaz denida para consulta y modicación de datos.

Base de Datos: Es la base de datos propiamente dicha, donde se almacenan todas las tablas con los
datos necesarios para desarrollar la lógica de la aplicación.

Conexión entre aplicaciones: Es el nodo asociado a la capa de persistencia y conexión entre la

aplicación web y el simulador de partidos. Allí se almacenan datos en archivos con formato XML.

En lo que respecta a la aplicación de escritorio (simulador de partidos), los nodos asociados son:

Conexión entre aplicaciones: Ídem anterior. Aquí el simulador deposita los componentes (XML)
necesarios para alimentar la aplicación web.

Ejecutable: Es el archivo resultado de toda la lógica del juego compilada y linkeada con las bibliotecas
necesarias.

6. Vista de Casos de Uso

En la quinta y última vista del Modelo 4+1, se presentan los escenarios en los cuales un Caso de Uso
dispara una secuencia de acciones que devienen en la interacción entre las vistas tratadas anteriormente.

12
 El usuario, como actor primario, dispara la actividad <<Apostar>> que desencadena la secuencia de op-
eraciones necesarias para completar este C.U.
Se puede comprender fácilmente de qué manera interactúan las diferentes vistas:

1. En un único Proceso (aplicación web) usuario interactúa con el nodo Cliente mediante teclado y
monitor

2. El cliente se comunica con el nodo Web Server

3. Web server contiene una Vista Lógica englobada en diferentes Componentes que manipula los datos,
validando y consultando mediante la interfaz correspondiente, los datos del nodo Base De Datos

De esta forma notamos cómo los elementos de las cuatro vistas trabajan conjuntamente en forma natural
mediante el uso de un conjunto pequeño de escenarios relevantes instancias de casos de uso más generales.

Se presentan dos ejemplos más de casos de usos:

13
14