Diseo de un Sistema Meteorolgico 2010

DISEO DE UNA SISTEMA

METEOROLGICO

Realizado por: Francisco Aisa Garca, Csar Delgado, Juan Manuel de Frutos Bernab y lvaro
Sevillano lvarez

Grupo 1

1
Diseo de un Sistema Meteorolgico 2010

Contenido
1. Introduccin .......................................................................................................................... 3
2. Requisitos del Sistema.......................................................................................................... 4
3. Anlisis del Problema ........................................................................................................... 6
a. Recoleccin de Datos Meteorolgicos .............................................................................. 6
b. Prediccin del tiempo ....................................................................................................... 7
4. Diseo Actual ........................................................................................................................ 8
a. Diagrama de clases de la estacin central .................................................................... 8
b. Diagrama de clases de la subestacin ......................................................................... 10
c. Principales Operaciones del Sistema .......................................................................... 11
5. Ventajas del Diseo Actual................................................................................................. 17
a. Ventajas del diseo orientado a objetos......................................................................... 17
i. Diagrama de clases de la estacin central .................................................................. 17
ii. Diagrama de clases subestacin ................................................................................. 20
b. Ventajas en la funcionalidad del sistema ........................................................................ 23
i. Generar Informe Diario ............................................................................................... 23
ii. Generar Informe Diario General ................................................................................. 26
6. Resultados........................................................................................................................... 29
a. Impacto del cambio ......................................................................................................... 29
b. Obtencin de un Patrn en el Diseo ............................................................................. 31
7. Conclusiones ....................................................................................................................... 33

2
Diseo de un Sistema Meteorolgico 2010

1. Introduccin

En el presente documento se va a recoger la informacin que permita describir el diseo

de nuestro sistema, el cul, a peticin de nuestro cliente, ser un sistema meteorolgico.
Este sistema ser capaz de recoger las mediciones realizadas por una serie de sensores y
elaborar a partir de ellos distintos informes y predicciones de carcter meteorolgico.

La estructura del documento es la siguiente. Primero se van a exponer los requisitos de

acuerdo a los cuales debemos realizar el sistema. A continuacin se muestra la
problemtica del problema. El siguiente apartado se corresponde con la situacin actual
del sistema, en el cul se detallan los diagramas de clases y las principales operaciones del
sistema. Puesto que el sistema ha pasado por una serie de etapas y de modificaciones en
el diseo, tambin se ha querido reflejar esta situacin mediante una seccin del
documento en la que se mostrarn los diseos actuales y los diseos de la anterior
entrega, as como se comentarn las diferencias y las ventajas asociadas a las mismas. As
mismo, y dado que nuestros clientes nos propusieron un cambio en el sistema, tambin
se va a crear una seccin en este documento para reflejar el impacto que dicho cambio
tuvo en el sistema. Durante el desarrollo de nuestro sistema nos dimos cuenta que
podamos crear cierta monotona en el diseo del mismo, por lo que la diseamos
utilizando un patrn de diseo, el cual vamos a explicar en este documento. Y por ltimo
se van a reflejar una serie de conclusiones a las que hemos llegados tras la realizacin del
sistema.

3
Diseo de un Sistema Meteorolgico 2010

2. Requisitos del Sistema

El problema que el cliente nos plante en la primera iteracin, era la construccin de un

sistema de recoleccin de datos meteorolgicos; Dicho sistema debera recoger
informacin a travs de una serie de subestaciones espaciadas geogrficamente y realizar
unos informes diarios y semanales, que ms adelante detallaremos a travs de los
requisitos.

En la segunda iteracin, el cliente nos pidi que nuestro sistema no solamente recogiera
datos de la meteorologa, sino que tambin fuese capaz de predecir el tiempo.

Queda claro que se trata de un sistema distribuido y que por lo tanto habr que dejar bien
definidas las partes correspondientes a las subestaciones y la estacin central.

Cada provincia estar dotada de una estacin meteorolgica (central y subestaciones)

para recoger datos de la meteorologa. Para realizar la prediccin del tiempo, las distintas
estaciones debern comunicarse entre s.

A continuacin introducimos los requisitos que el cliente exige que el sistema cumpla a
da de hoy.

A nivel provincial:

Cada provincia dispone de una estacin central que se comunica con subestaciones y un
conjunto de subestaciones meteorolgicas que recogen datos de la climatologa a travs
de sensores.

Cada cinco minutos, cada subestacin registra a travs de los sensores los siguientes
datos meteorolgicos:

Temperatura del aire

Velocidad del viento

Presin baromtrica

Cantidad de precipitaciones cadas (debe ser un dato acumulado)

Al finalizar el da, el sistema (para cada provincia) debe generar un informe con el
resumen de los datos recogidos por cada subestacin as como por el conjunto de ellas,
este informe debe contener informacin relativa a las ltimas 24 horas con las siguientes
columnas:

Temperatura mxima

Temperatura mnima

Temperatura media

Velocidad media del viento

Velocidad mxima del viento

Presin media

4
Diseo de un Sistema Meteorolgico 2010

Caudal medio

Caudal acumulado del da

Semanalmente debe mostrarse un resumen de los datos del conjunto de todas las
subestaciones con los siguientes indicadores:

Temperatura

Velocidad del viento

Presin baromtrica

Caudal acumulado diario

A nivel Nacional:

Las centrales de las distintas provincias tienen que comunicarse para realizar la prediccin
del tiempo.

Para realizar la prediccin del tiempo, se utilizan los informes diarios generados por las
estaciones centrales vecinas.

Cada prediccin debe contener los siguientes datos:

Temperatura mxima

Temperatura mnima

Temperatura media

Velocidad media del viento

Velocidad mxima del viento

Presin media

Caudal medio

Caudal acumulado

5
Diseo de un Sistema Meteorolgico 2010

3. Anlisis del Problema

Vamos a dividir el anlisis del problema en las dos etapas dadas por el cliente, que son la
recoleccin de datos meteorolgicos (a) y la prediccin del tiempo (b) a partir de dichos
datos recolectados por los sensores.

a. Recoleccin de Datos Meteorolgicos

Tenemos una serie de subestaciones repartidas en una provincia; Por ejemplo: Para
la central meteorolgica de Mlaga tenemos subestaciones en Benalmdena, Mijas,
Torremolinos y Marbella, que cada 5 minutos reciben datos de la meteorologa a
travs de sensores instalados en dichas subestaciones. A continuacin se
esquematiza el problema:

Figura 1. Esquema general de la estacin central, subestaciones y sensores.

Pasadas 24 horas, la central pide a las estaciones un Informe diario, cada una de las
subestaciones elabora su informe diario y se lo enva. Al cabo de una semana, con los
informes diarios recogidos la estacin central genera el informe semanal:

Figura 2. Esquema de generacin de los informes diario general y semanal.

6
Diseo de un Sistema Meteorolgico 2010

b. Prediccin del tiempo

Diariamente, se quiere hacer una prediccin del tiempo para cada provincia, de
manera que tenemos una estacin meteorolgica central, con una serie de
subestaciones asociadas por cada provincia. Para realizar la prediccin necesitamos
los informes diarios generales de las estaciones centrales de las provincias vecinas.

Por ejemplo, para realizar la prediccin del tiempo en la comunidad de Madrid, el

nuevo esquema de comunicacin sera el siguiente:

Figura 3. Esquema general de la ubicacin de las estaciones centrales para poder realizar una prediccin.

La siguiente estructura representa el proceso de obtencin de una prediccin:

Figura 4. Esquema general de la elaboracin de una prediccin.

7
Diseo de un Sistema Meteorolgico 2010

4. Diseo Actual

En esta seccin vamos a exponer nuestro diseo final. Se van a mostrar y explicar los
diagramas de clases correspondientes a la estacin central y a las subestaciones, as como
los diagramas de interaccin de las principales operaciones del sistema.

a. Diagrama de clases de la estacin central

Figura 5. Diagrama de clases de la Estacin Central.

8
Diseo de un Sistema Meteorolgico 2010

Debido al carcter distribuido de nuestro sistema hemos decidido separar el

diagrama de clases en dos partes, una correspondiente al sistema de la estacin
central y otro correspondiente al sistema de las subestaciones.

El primero de ellos podemos observarlo en la imagen anterior, y corresponde con el

sistema de la estacin central. Cabe destacar en primer lugar a la clase Estacin
Central, cuya responsabilidad en el sistema es, por un lado la solicitud de generar
algn informe o una prediccin, cuya responsabilidad caer sobre otras clases, y por
otro lado la adopcin de subestaciones como suyas.

Si se observa el diagrama con detalle se observa cierta similitud entre elementos del
sistema que generan los objetivos que nos fueron solicitados en un principio. En
concreto, esta similitud se da entre las clases GeneradorInformeSemanal,
GeneradorResumenDiario y GeneradorPrediccin. Esta similitud es motivada por la
importancia de usar el mismo patrn de diseo en todos los casos que nuestro
sistema genera algn elemento.

La generacin de un elemento por parte de una de estas clases se realiza de la misma

forma en los tres casos mencionados anteriormente. Todos los generadores
consultan alguna informacin que necesitan y se relacionan con otra clase que es
elemento a generar.

Por tanto, estamos presentando un diseo en el que la responsabilidad de creacin

de informes o predicciones la asumen las clases generadoras, para no sobrecargar de
responsabilidad a la estacin central, que ya tiene bastante con la mencionado
anteriormente.

Este patrn de dominio adoptado por nuestro equipo tambin se da en el diagrama

de la subestacin que se ver ms adelante.

Debido carcter automatizado con el que deben generarse en nuestro sistema los
informes nos hemos visto obligado a incluir temporizadores que, cada cierto tiempo
dependiendo del objeto que se trate, recuerdan a la estacin que debe generar
dicho objeto. Como se ha dicho anteriormente, la estacin pasar la responsabilidad
a la clase correspondiente.

Adems de lo ya comentado, contamos con un controlador que gestiona el sistema y

lo pone en marcha, adems de varios proxys que representan a otras estaciones
centrales u otras subestaciones para realizar la comunicacin ente stas.

Por ltimo, comentar la existencia de una clase Calculador que adquiere la

responsabilidad en el sistema de llevar a cabo los clculos para los cuales sea
invocado.

La zona que aparece enmarcada con lnea discontinua en el diagrama de la Figura 5

se corresponde con el cambio que solicit el cliente.

9
Diseo de un Sistema Meteorolgico 2010

b. Diagrama de clases de la subestacin

Figura 6. Diagrama de clases de la Estacin Central.

En este diagrama nos encontramos con el esquema que tienen las subestaciones. En
l aparecen elementos que siguen ese mismo patrn de diseo que se aplic en la
estacin central, lo que mantiene la simetra del sistema.

En el sistema destacan por su simetra elementos como el proxy, la clase subestacin,

el generadorInformeDiario, el propio informe o la clase Calculador.

10
Diseo de un Sistema Meteorolgico 2010

c. Principales Operaciones del Sistema

A continuacin se van a mostrar los diagramas de interaccin de las principales

operaciones el sistema. Ms concretamente se van a detallar, haciendo uso de este
tipo de diagramas, las operaciones Generar Informe Diario, Generar Informe
Diario General, Generar Informe Semanal y Generar Prediccin.

Tambin hay que hacer mencin al tipo de diagramas de interaccin utilizados.

Merece la pena recordar que existen dos tipos de diagramas de interaccin, los
diagramas de secuencia y los diagramas de colaboracin. En los de secuencia se
aprecia de una manera clara la secuencia de tiempo en la que se realizan las
llamadas. Por su parte, si se utilizan diagramas de colaboracin se puede representar
las llamadas entre clases de forma que se aprecien claramente.

i. Generar Informe Diario

Esta operacin consiste en, a partir de una serie de medidas de temperatura,

velocidad del viento, presin y precipitacin realizadas a lo largo de un da,
realizar un informe que contenga la temperatura mxima, la temperatura mnima,
la temperatura promedio, la velocidad del viento mxima y media, la presin
media, la cantidad de precipitacin media y la cantidad total de la misma. Para
elaborar un informe diario lo primero es la llegada de una llamada que pide la
generacin de un informe diario hasta la subestacin a travs del proxy que hace
de representante entre el servidor central y la subestacin. Al recibir el mensaje,
la subestacin va a crear un generador de informe diario y le va a pedir que cree
el informe. Entonces ste va a decirle al histrico de medidas de temperatura que
coja las medidas que tenga y le pida al calculador que le diga cul es la mayor de
todas ellas. El histrico de medidas de temperatura opera de igual manera para
calcular el mnimo y el promedio. Esas medidas se le pasan al generador de
informe diario, que ahora necesitar las velocidades mxima y media del viento.
Para ello le dice al histrico de medidas de velocidades que necesita el mximo y
el promedio de las medidas de velocidad de viento, entonces el histrico de
medidas de velocidad le dice al calculador que le diga dichas medidas. Una vez
que el histrico conoce dichas medidas se las pasa al generador de informe diario.
El proceso es anlogo para calcular el promedio de las medidas de presin y para
calcular el promedio y el total de precipitaciones. Cuando el generador de informe
diario tiene las medidas necesarias para poder realizar el informe diario, entonces
lo crea y se lo pasa a la subestacin. Por lo tanto es el generador de informe diario
el que tiene la responsabilidad de crear el informe diario.

Se ha decidido emplear un diagrama de colaboracin ya que hemos considerado

ms importante que se reflejara las relaciones entre clases y la distribucin de las
mismas antes que la secuencia de las llamadas, ya que la mayora de las llamadas
de este diagrama son para obtener los datos con los que realizar el informe, y
realmente el orden en que se obtienen dichos datos no es relevante, da igual
obtener primero la temperatura mxima o la presin media por ejemplo.

11
Diseo de un Sistema Meteorolgico 2010

Diagrama Generar Informe Diario

Figura 7. Diagrama de colaboracin de Generar Informe Diario, con sus correspondientes llamadas entre clases.

12
Diseo de un Sistema Meteorolgico 2010

ii. Generar Informe Diario General

La realizacin de esta operacin permite la obtencin de un informe diario

general. La estructura de que est compuesto este informe se muestran en la
siguiente figura:

Figura 8. Estructura general de un Informe Diario General

El objetivo de esta operacin es realizar un informe que contenga la temperatura

mxima, la temperatura mnima, la temperatura promedio, la velocidad del viento
mxima y media, la presin media, la cantidad de precipitacin media y la
cantidad total de la misma de entre todos los informes diarios realizados en el
presente da. Como se mostraba en la figura anterior, el informe diario general
estar formado por todos los informes diarios de las subestaciones y adems
incluir un resumen de todos ellos.

La creacin de un informe diario general se dispara con la llegada de la llamada

correspondiente a la estacin central. Entonces sta va a delegar la
responsabilidad de crear dicho informe al generador de informe diario general. Lo
primero que va a hacer el generador de informe diario es ir pidiendo a cada una
de las subestaciones su correspondiente informe diario. A continuacin y,
apoyndose en el calculador el generador de resumen diario va a obtener los
datos necesarios para elaborar un resumen de los informes diarios de todas las
subestaciones. Por ejemplo, para calcular la temperatura mxima de entra todas
las registradas en todas las subestaciones, le va a pasar al calculador la totalidad
de mediciones de temperatura y ste le devolver la mxima. De manera anloga
se calcularn el resto de datos necesarios para elaborar el resumen, es decir, la
temperatura media, la mnima, la velocidad mxima, la media, la presin
promedio, el promedio de caudal y el total de precipitaciones. Una vez que el
generador de informe diario general tiene toda la informacin, entonces crea el
resumen, y como tambin tiene los informes diarios de todas las subestaciones,
entonces ya tiene toda la informacin que necesita para crear el informe diario
general.
13
Diseo de un Sistema Meteorolgico 2010

Diagrama Generar Informe Diario General

Figura 9. Diagrama de colaboracin de Generar Informe Diario General.

14
Diseo de un Sistema Meteorolgico 2010

iii. Generar Informe Semanal

La realizacin de este tipo de informe se realiza cada siete das cuando un

temporizador solicitar un informe este tipo. Esta peticin le va a llegar a la
estacin central, pero no va a ser sta la que se encargue de crear el informe
semanal, sino que delega la responsabilidad de su creacin al generador de
informe semanal, el cul, lo primero que hace es obtener todos los informes
generales correspondientes a la semana correspondiente. Llegados a este punto,
el generador de informe semanal va a apoyarse en el calculador para obtener los
valores promedio de los distintos tipos de mediciones de todos los informes
diarios generales. Una vez que ha obtenido estos valores, el generador de informe
semanal ya puede crear el informe semanal correspondiente. Por lo tanto la
inteligencia de su creacin la tiene el generador de informe semanal. La manera
de crear este tipo de informes no se ha modificado desde la anterior entrega.

Figura 10. Diagrama de colaboracin de Generar Informe Diario General.

15
Diseo de un Sistema Meteorolgico 2010

iv. Realizar Prediccin

La operacin del sistema que se encarga de realizar la prediccin se representa

abajo y corresponde a un mtodo de la clase Estacin Central. Uno de los
temporizadores que se pueden observar en el diagrama de clases, concretamente
el Solicitador Prediccin, se encarga de invocar peridicamente a este mtodo.

Cuando la Estacin Central recibe la operacin delega la responsabilidad de sta

en la clase Generador Prediccin, la cual solicita a los proxys de todas las
estaciones que le enven un informe diario.

Cuando el generador rene todos los informes invoca al mtodo

GenerarPrediccin, con los datos de todos los informes, momento en el que utiliza
el algoritmo diseado para el clculo de la prediccin y crea una instancia de la
clase Prediccin con la salida del algoritmo.

Con estas interacciones entre clases queda definida la operacin de Realizar

Prediccin, nuevo requisito solicitado por los clientes.

Figura 11. Diagrama de secuencia de Generar Prediccin.

16
Diseo de un Sistema Meteorolgico 2010

5. Ventajas del Diseo Actual

En esta seccin se van a exponer las ventajas obtenidas resultantes de modificar el diseo
anterior hasta obtener el diseo actual. Para reflejar de manera ms clara esos cambios se
van a realizar una descripcin de los cambios y las ventajas obtenidas, y a continuacin se
va a mostrar los diagramas anteriores y despus los diagramas actuales correspondientes.

a. Ventajas del diseo orientado a objetos

i. Diagrama de clases de la estacin central

En el diagrama de clases antiguo podemos observar algunas diferencias con el

diagrama de clases que hemos presentado en la ltima versin del proyecto.

En la versin actual del diagrama de la Estacin Central descargamos de

responsabilidad a la clase Estacin Central, que como se observa aqu tiene
relaciones de agregacin varias clases del diseo. En la nueva versin deshacemos
estas relaciones que consideramos sin sentido.

Adems se aprecia, como ya se ha comentado, la nueva funcionalidad aadida de

realizar predicciones meteorolgicas en funcin de los informes de otras
estaciones centrales.

17
Diseo de un Sistema Meteorolgico 2010

Figura 12. Diagrama de clases anterior de la estacin central

18
Diseo de un Sistema Meteorolgico 2010

Figura 13. Diagrama de clases actual de la estacin central

19
Diseo de un Sistema Meteorolgico 2010

ii. Diagrama de clases subestacin

En el diagrama de clases de la subestacin de la versin anterior del sistema (la

que se entreg en la primera entrega) se observa un cambio en la realizacin del
informe diario.

En este caso se puede ver como la responsabilidad de realizar el informe diario la

tena la clase Subestacin, lo cual decidimos que, seguramente, no sea la opcin
ms adecuada. Por tanto decidimos insertar un Generador, para seguir con el
patrn que usamos en la estacin central.

Entonces, es esta clase generadora la que se encarga de consultar los histricos y

generar el informe, siempre y cuando se lo solicite la Subestacin. Observamos
aqu el cambio, ahora la Subestacin solo se ocupa de pedirle al Generador un
informe que le ha sido solicitado a travs del Proxy.

20
Diseo de un Sistema Meteorolgico 2010

Figura 14. Diagrama de clases anterior de la subestacin.

21
Diseo de un Sistema Meteorolgico 2010

Figura 15. Diagrama de clases actual de la subestacin.

22
Diseo de un Sistema Meteorolgico 2010

b. Ventajas en la funcionalidad del sistema

i. Generar Informe Diario

La principal diferencia existente en la manera de crear un informe diario entre el

diseo de la primera entrega y el diseo de esta ltima entrega reside en que en
el primera entrega toda la lgica de creacin del informe la tena la subestacin,
ya que era quin se encargaba de ir pidiendo al resto de clases que hicieran
determinadas acciones. Mientras que en el segundo diseo la clase que posee la
inteligencia necesaria para crear el informe diario es el generador de informe
diario, centrando en l la inteligencia para la creacin del informe diario.

Por lo tanto, a pesar de que las modificaciones realizadas respecto al diseo

anterior supone aadir una nueva clase, adems de otras cosas como por ejemplo
nuevos mtodos, se obtienen una serie de ventajas asociadas.

Una de esas ventajas es, como se acaba de decir, la independencia de la lgica de

creacin de un informe diario con respecto a la subestacin, por lo que sta no va
a ser quin tenga la responsabilidad de la creacin de dicho informe.

Otra ventaja que se obtiene con este nuevo diseo es la monotona en la

estructura del mismo. En este caso la generacin de un informe diario es
responsabilidad del generador de informe diario, el cual se apoya en otras clases
para obtener la informacin necesaria para su creacin y llegados a este punto lo
crea. ste va a ser el mismo esqueleto de acciones y clases que va a estar presente
en la creacin de los distintos informes del sistema. Consiguindose as
monotona en el diseo.

23
Diseo de un Sistema Meteorolgico 2010

Diagrama Generar Informe Diario del diseo anterior:

Figura 16. Diagrama de colaboracin de Generar Informe Diario correspondiente al anterior diseo.

24
Diseo de un Sistema Meteorolgico 2010

Diagrama Generar Informe Diario del diseo actual:

Figura 17. Diagrama de colaboracin de Generar Informe Diario correspondiente al actual diseo.

25
Diseo de un Sistema Meteorolgico 2010

ii. Generar Informe Diario General

La principal diferencia radica en que en el diseo correspondiente a la anterior

entrega, la estacin central era quin se encargaba de obtener todos los informes
diarios de todas las subestaciones y de crear el informe diario general,
apoyndose en el generador de resumen diario nicamente para que ste
elaborara el resumen de los informes diarios. Sin embargo, en el diseo
correspondiente a la entrega final, la clase que tiene la inteligencia necesaria para
la creacin del informe diario general es el generador de informe diario general, el
cual se va a encargar de conseguir los informes diarios de las distintas
subestaciones, de elaborar el resumen y de crear el resumen diario general. De
este modo se consigue liberar a la estacin central de una carga importante de
trabajo, delegando el trabajo a un generador de informe diario general, el cual
tendr en s la lgica de creacin de los informes diarios generales.

Al igual que se coment anteriormente, una ventaja que se obtiene con este
nuevo diseo es la monotona en su estructura. En este caso, el generar un
informe diario general es responsabilidad del generador de informe diario
general, el cual se apoya en otras clases para obtener la informacin necesaria
para su creacin y luego se va a encargar de crearlo. ste va a ser el mismo
esqueleto de acciones y clases que va a estar presente en la creacin de otros
informes del sistema, consiguindose de esta manera monotona en el diseo.

26
Diseo de un Sistema Meteorolgico 2010

Diagrama Generar Informe Diario General del diseo anterior:

Figura 18. Diagrama de colaboracin de Generar Informe Diario General correspondiente al anterior diseo.

27
Diseo de un Sistema Meteorolgico 2010

Diagrama Generar Informe Diario General del diseo actual:

Figura 19. Diagrama de colaboracin de Generar Informe Diario General correspondiente al diseo actual.

28
Diseo de un Sistema Meteorolgico 2010

6. Resultados
En este punto se describen los resultados obtenidos tanto durante la realizacin de este
proyecto como tras la aplicacin del cambio propuesto por los clientes sobre nuevas
funcionalidades de nuestro sistema. Es decir, mientras se realizaba el proyecto nos hemos
dado cuenta de una pauta en las operaciones que se realizaban y hemos llegado a
identificar un patrn de diseo en varias funcionalidades. Este patrn se explicar en esta
seccin. Tambin se va a describir el impacto que ha tenido en nuestro sistema el cambio
en el sistema que nos han propuesto nuestros clientes, es decir, las modificaciones que
han sido necesarias introducir al sistema para que proporcione la nueva funcionalidad y
las consecuencias de las mismas.

a. Impacto del cambio

Para evaluar la forma en la que el sistema sufre el impacto del cambio que nuestros
clientes nos solicitaron, vamos a comparar las diferencias entre aplicar dicho cambio
a la versin que se presenta del sistema (que ya viene integrado) y alguna versin
antigua que no cuente con el cambio, concretamente la que fue presentada en la
primera entrega.

Para empezar, explicar que el cambio que nuestros clientes solicitaron fue que el
sistema, adems que realizar informes meteorolgicos como hasta entonces haca,
deba estar dotado para realizar predicciones meteorolgicas para un da, en funcin
de los informes de das anteriores de otras estaciones colindantes a una concreta.

En el sistema actual, las consecuencias que tiene aplicar un cambio como el explicado
dejan claro que el sistema no sufre en exceso, puesto que aplicar un cambio como
este supone:

- Aadir tres clases (Generador Prediccin, Prediccin, Proxy Estacin

Central)
- La clase Generador Prediccin se relaciona con la clase Estacin Central.
Mientras, Prediccin y Proxy Estacin Central no tienen relacin directa
con el sistema ya diseado, se relacionan con la tambin aadida Generador
Prediccin.

Mientras, aplicar el cambio en el sistema que se entreg para la primera entrega

supone lo siguiente:

- Parte de la lgica de la generacin de la prediccin corresponde a la estacin

central, mientras que en el nuevo diseo corresponde al generador de
predicciones.
- Si seguimos el mismo patrn con el que diseamos esta etapa anterior,
aadiramos las predicciones como relaciones de agregacin, por lo que la
estacin central supondra un cuello de botella de todo el sistema si diese
algn problema en sta.
- Con todo esto, se nota una gran sobrecarga de responsabilidad en la estacin
central, lo cual no es apropiado.

29
Diseo de un Sistema Meteorolgico 2010

- Por ltimo, los nuevos proxys que se aaden afectan a la estacin central,
mientras que en la versin actual los proxys se aaden al Generador de
Prediccin, lo cual descarga de responsabilidad a la Estacin Central.

30
Diseo de un Sistema Meteorolgico 2010

b. Obtencin de un Patrn en el Diseo

Durante el proceso de desarrollo del proyecto software hemos tratado de ser lo ms

homogneos posibles. Este esfuerzo de homogeneizar el sistema ha desembocado en un
desarrollo uniforme y un diseo monoltico, que a la larga nos ha beneficiado, ya que en el
diseo actual pueden apreciarse una gran cantidad de simetras entre el diagrama de clases de
la subestacin y la estacin central.

A la larga y tras el desarrollo de la ltima iteracin, hemos localizado un patrn que se repite
siempre en nuestro sistema, debido a la monotona y homogeneidad de que le hemos dotado.
Este hecho, nos ha conducido al diseo de un patrn a modo de esqueleto para desarrollar
sistemas similares al nuestro.

Por ejemplo, si quisiramos desarrollar un sistema para la recoleccin de los votos de los
ciudadanos, el sistema a desarrollar sera muy parecido al nuestro. Si aplicamos el patrn
identificable en nuestro sistema, el desarrollo de este nuevo sistema no solo sera mucho ms
rpido, sino que adems sera mucho ms seguro, debido a que al ya estar las estructuras
montadas y tener algunos mtodos construidos no repetiramos los mismo errores.

Sin ms demora, vamos a introducir el patrn identificado en nuestro diseo en forma de

diagrama de clases:

Figura 20. Diagrama de un patrn correspondiente a la anterior explicacin.

31
Diseo de un Sistema Meteorolgico 2010

Haciendo memoria, en nuestro diagrama de clases ya se puede apreciar este esqueleto. En el

diagrama de clases de la estacin central (Figura 13, pgina 19) existe un solicitador, que
dependiendo del tipo de informe requerido cada x segundos (minutos u horas) solicita que se
realice una accin, el elemento central (en este caso la central) una vez que recibe la orden
delega sobre el generador la responsabilidad de generar el informe y finalmente ste ltimo
consulta la informacin que necesite, en este caso en particular, solicita la informacin a las
subestaciones y con esa informacin realiza los clculos correspondientes y genera el informe
solicitado.

El caso de la subestacin (Figura 15, pgina 22) es exactamente el mismo, recibe una peticin a
travs del proxy de realizar un informe, la subestacin delega la responsabilidad al generador,
quien obtiene la informacin de los histricos y luego genera el informe a partir de los datos
derivados del calculador.

32
Diseo de un Sistema Meteorolgico 2010

7. Conclusiones

 A la hora de empezar todo proyecto es mejor hacerlo por una parte pequea del
problema, y una vez hecha esa parte ampliarla progresivamente con nuevas
funcionalidades y requisitos.
 La asignacin de responsabilidades a cada clase no es fcil ni trivial. La
independencia de unas clases con respecto a otras es un punto fundamental de
todo sistema software a la hora de posibles ampliaciones, cambios o ante la
posibilidad de producirse errores en el sistema.
 No es recomendable tener la responsabilidad de un accin distribuida entre
muchas clases, ya que ante el cambio en la manera de realizarse dicha accin, el
cambio habra que realizarlo en todas esas clases. En cambio, si se tiene centrada
la lgica de la accin en pocas clases, un cambio en esa lgica afectara a un
menor nmero de clases.
 Hay que tener en mente que el sistema y las clases que lo componen no tienen
por qu corresponderse siempre con elementos de la realidad.
 Es importante tener siempre en mente que el sistema debe ser flexible. Es decir,
el diseo actual no puede no ser el mismo que dentro de un tiempo. Esto puede
deberse a ampliaciones en el sistema, cambios en la funcionalidad del sistema, ,
y esos cambios deben de ser fciles de realizarse sobre el sistema.
 Es beneficioso obtener un diseo que posea cierta monotona. En el desarrollo del
software la monotona es un elemento fundamental, ya que posibilita la
reutilizacin de ideas, cdigo, diseos, etc, y por lo tanto el ahorro de gran
cantidad de tiempo.
 En nuestro caso, hemos encontrado un patrn de diseo a la hora de crear
nuevos informes, predicciones, etc. Esto nos ha facilitado enormemente la
realizacin de la ampliacin, as como la del propio diseo, aparte de dotar de
cierta monotona y simetra al sistema.

33
Diseo de un Sistema Meteorolgico 2010

34