Memoria Final de Proyecto Practico Software

Diseño de un Sistema Meteorológico 2010

1

DISEÑO DE UNA SISTEMA

METEOROLÓGICO

Realizado por: Francisco Aisa García, César Delgado, Juan Manuel de Frutos Bernabé y Álvaro

Sevillano Álvarez

Grupo 1


2

Contenido

1. Introducción .......................................................................................................................... 3

2. Requisitos del Sistema .......................................................................................................... 4

3. Análisis del Problema ........................................................................................................... 6

a. Recolección de Datos Meteorológicos .............................................................................. 6

b. Predicción del tiempo ....................................................................................................... 7

4. Diseño Actual ........................................................................................................................ 8

a. Diagrama de clases de la estación central .................................................................... 8

b. Diagrama de clases de la subestación ......................................................................... 10

c. Principales Operaciones del Sistema .......................................................................... 11

5. Ventajas del Diseño Actual ................................................................................................. 17

a. Ventajas del diseño orientado a objetos......................................................................... 17

i. Diagrama de clases de la estación central .................................................................. 17

ii. Diagrama de clases subestación ................................................................................. 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. Obtención de un Patrón en el Diseño ............................................................................. 31

7. Conclusiones ....................................................................................................................... 33


3

1. Introducción

En el presente documento se va a recoger la información que permita describir el diseño

de nuestro sistema, el cuál, a petición de nuestro cliente, será un sistema meteorológico.

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 carácter meteorológico.

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

acuerdo a los cuales debemos realizar el sistema. A continuación se muestra la

problemática del problema. El siguiente apartado se corresponde con la situación actual

del sistema, en el cuál 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 diseño, también se ha querido reflejar esta situación mediante una sección del

documento en la que se mostrarán los diseños actuales y los diseños de la anterior

entrega, así como se comentarán las diferencias y las ventajas asociadas a las mismas. Así

mismo, y dado que nuestros clientes nos propusieron un cambio en el sistema, también

se va a crear una sección en este documento para reflejar el impacto que dicho cambio

tuvo en el sistema. Durante el desarrollo de nuestro sistema nos dimos cuenta que

podíamos crear cierta monotonía en el diseño del mismo, por lo que la diseñamos

utilizando un patrón de diseño, 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 realización del

sistema.


4

2. Requisitos del Sistema

El problema que el cliente nos planteó en la primera iteración, era la construcción de un

sistema de recolección de datos meteorológicos; Dicho sistema debería recoger

información a través de una serie de subestaciones espaciadas geográficamente y realizar

unos informes diarios y semanales, que más adelante detallaremos a través de los

requisitos.

En la segunda iteración, el cliente nos pidió que nuestro sistema no solamente recogiera

datos de la meteorología, sino que también 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 estación central.

Cada provincia estará dotada de una estación meteorológica (central y subestaciones)

para recoger datos de la meteorología. Para realizar la predicción del tiempo, las distintas

estaciones deberán comunicarse entre sí.

A continuación introducimos los requisitos que el cliente exige que el sistema cumpla a

día de hoy.

A nivel provincial:

Cada provincia dispone de una estación central que se comunica con subestaciones y un

conjunto de subestaciones meteorológicas que recogen datos de la climatología a través

de sensores.

Cada cinco minutos, cada subestación registra a través de los sensores los siguientes

datos meteorológicos:

� Temperatura del aire

� Velocidad del viento

� Presión barométrica

� Cantidad de precipitaciones caídas (debe ser un dato acumulado)

Al finalizar el día, el sistema (para cada provincia) debe generar un informe con el

resumen de los datos recogidos por cada subestación así como por el conjunto de ellas,

este informe debe contener información relativa a las últimas 24 horas con las siguientes

columnas:

� Temperatura máxima

� Temperatura mínima

� Temperatura media

� Velocidad media del viento

� Velocidad máxima del viento

� Presión media


5

� Caudal medio

� Caudal acumulado del día

Semanalmente debe mostrarse un resumen de los datos del conjunto de todas las

subestaciones con los siguientes indicadores:

� Temperatura

� Velocidad del viento

� Presión barométrica

� Caudal acumulado diario

A nivel Nacional:

Las centrales de las distintas provincias tienen que comunicarse para realizar la predicción

del tiempo.

Para realizar la predicción del tiempo, se utilizan los informes diarios generados por las

estaciones centrales vecinas.

Cada predicción debe contener los siguientes datos:

� Temperatura máxima

� Temperatura mínima

� Temperatura media

� Velocidad media del viento

� Velocidad máxima del viento

� Presión media

� Caudal medio

� Caudal acumulado


6

3. Análisis del Problema

Vamos a dividir el análisis del problema en las dos etapas dadas por el cliente, que son la

recolección de datos meteorológicos (a) y la predicción del tiempo (b) a partir de dichos

datos recolectados por los sensores.

a. Recolección de Datos Meteorológicos

Tenemos una serie de subestaciones repartidas en una provincia; Por ejemplo: Para

la central meteorológica de Málaga tenemos subestaciones en Benalmádena, Mijas,

Torremolinos y Marbella, que cada 5 minutos reciben datos de la meteorología a

través de sensores instalados en dichas subestaciones. A continuación se

esquematiza el problema:

Figura 1. Esquema general de la estación 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 envía. Al cabo de una semana, con los

informes diarios recogidos la estación central genera el informe semanal:

Figura 2. Esquema de generación de los informes diario general y semanal.


7

b. Predicción del tiempo

Diariamente, se quiere hacer una predicción del tiempo para cada provincia, de

manera que tenemos una estación meteorológica central, con una serie de

subestaciones asociadas por cada provincia. Para realizar la predicción necesitamos

los informes diarios generales de las estaciones centrales de las provincias vecinas.

Por ejemplo, para realizar la predicción del tiempo en la comunidad de Madrid, el

nuevo esquema de comunicación sería el siguiente:

Figura 3. Esquema general de la ubicación de las estaciones centrales para poder realizar una predicción.

La siguiente estructura representa el proceso de obtención de una predicción:

Figura 4. Esquema general de la elaboración de una predicción.


8

4. Diseño Actual

En esta sección vamos a exponer nuestro diseño final. Se van a mostrar y explicar los

diagramas de clases correspondientes a la estación central y a las subestaciones, así como

los diagramas de interacción de las principales operaciones del sistema.

a. Diagrama de clases de la estación central

Figura 5. Diagrama de clases de la Estación Central.


9

Debido al carácter distribuido de nuestro sistema hemos decidido separar el

diagrama de clases en dos partes, una correspondiente al sistema de la estación

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 estación central. Cabe destacar en primer lugar a la clase “Estación

Central”, cuya responsabilidad en el sistema es, por un lado la solicitud de generar

algún informe o una predicción, cuya responsabilidad caerá sobre otras clases, y por

otro lado la adopción 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 GeneradorPredicción. Esta similitud es motivada por la

importancia de usar el mismo patrón de diseño en todos los casos que nuestro

sistema genera algún elemento.

La generación 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 información que necesitan y se relacionan con otra clase que es

elemento a generar.

Por tanto, estamos presentando un diseño en el que la responsabilidad de creación

de informes o predicciones la asumen las clases generadoras, para no sobrecargar de

responsabilidad a la estación central, que ya tiene bastante con la mencionado

anteriormente.

Este patrón de dominio adoptado por nuestro equipo también se da en el diagrama

de la subestación que se verá más adelante.

Debido carácter 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 estación que debe generar

dicho objeto. Como se ha dicho anteriormente, la estación pasará la responsabilidad

a la clase correspondiente.

Además de lo ya comentado, contamos con un controlador que gestiona el sistema y

lo pone en marcha, además de varios proxys que representan a otras estaciones

centrales u otras subestaciones para realizar la comunicación ente éstas.

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

responsabilidad en el sistema de llevar a cabo los cálculos para los cuales sea

invocado.

La zona que aparece enmarcada con línea discontinua en el diagrama de la Figura 5

se corresponde con el cambio que solicitó el cliente.


10

b. Diagrama de clases de la subestación

Figura 6. Diagrama de clases de la Estación Central.

En este diagrama nos encontramos con el esquema que tienen las subestaciones. En

él aparecen elementos que siguen ese mismo patrón de diseño que se aplicó en la

estación central, lo que mantiene la simetría del sistema.

En el sistema destacan por su simetría elementos como el proxy, la clase subestación,

el generadorInformeDiario, el propio informe o la clase Calculador.


11

c. Principales Operaciones del Sistema

A continuación se van a mostrar los diagramas de interacción de las principales

operaciones el sistema. Más 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 Predicción”.

También hay que hacer mención al tipo de diagramas de interacción utilizados.

Merece la pena recordar que existen dos tipos de diagramas de interacción, los

diagramas de secuencia y los diagramas de colaboración. 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 colaboración se puede representar

las llamadas entre clases de forma que se aprecien claramente.

i. Generar Informe Diario

Esta operación consiste en, a partir de una serie de medidas de temperatura,

velocidad del viento, presión y precipitación realizadas a lo largo de un día,

realizar un informe que contenga la temperatura máxima, la temperatura mínima,

la temperatura promedio, la velocidad del viento máxima y media, la presión

media, la cantidad de precipitación media y la cantidad total de la misma. Para

elaborar un informe diario lo primero es la llegada de una llamada que pide la

generación de un informe diario hasta la subestación a través del proxy que hace

de representante entre el servidor central y la subestación. Al recibir el mensaje,

la subestación va a crear un generador de informe diario y le va a pedir que cree

el informe. Entonces éste va a decirle al histórico de medidas de temperatura que

coja las medidas que tenga y le pida al calculador que le diga cuál es la mayor de

todas ellas. El histórico de medidas de temperatura opera de igual manera para

calcular el mínimo y el promedio. Esas medidas se le pasan al generador de

informe diario, que ahora necesitará las velocidades máxima y media del viento.

Para ello le dice al histórico de medidas de velocidades que necesita el máximo y

el promedio de las medidas de velocidad de viento, entonces el histórico de

medidas de velocidad le dice al calculador que le diga dichas medidas. Una vez

que el histórico conoce dichas medidas se las pasa al generador de informe diario.

El proceso es análogo para calcular el promedio de las medidas de presión 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 subestación. 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 colaboración ya que hemos considerado

más importante que se reflejara las relaciones entre clases y la distribución de las

mismas antes que la secuencia de las llamadas, ya que la mayoría 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 máxima o la presión media por ejemplo.


12

Diagrama “Generar Informe Diario”

Figura 7. Diagrama de colaboración de “Generar Informe Diario”, con sus correspondientes llamadas entre clases.


13

ii. Generar Informe Diario General

La realización de esta operación permite la obtención 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 operación es realizar un informe que contenga la temperatura

máxima, la temperatura mínima, la temperatura promedio, la velocidad del viento

máxima y media, la presión media, la cantidad de precipitación media y la

cantidad total de la misma de entre todos los informes diarios realizados en el

presente día. Como se mostraba en la figura anterior, el informe diario general

estará formado por todos los informes diarios de las subestaciones y además

incluirá un resumen de todos ellos.

La creación de un informe diario general se dispara con la llegada de la llamada

correspondiente a la estación 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 continuación y,

apoyándose 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 máxima 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 máxima. De manera análoga

se calcularán el resto de datos necesarios para elaborar el resumen, es decir, la

temperatura media, la mínima, la velocidad máxima, la media, la presión

promedio, el promedio de caudal y el total de precipitaciones. Una vez que el

generador de informe diario general tiene toda la información, entonces crea el

resumen, y como también tiene los informes diarios de todas las subestaciones,

entonces ya tiene toda la información que necesita para crear el informe diario

general.


14

Diagrama “Generar Informe Diario General”

Figura 9. Diagrama de colaboración de “Generar Informe Diario General”.


15

iii. Generar Informe Semanal

La realización de este tipo de informe se realiza cada siete días cuando un

temporizador solicitará un informe este tipo. Esta petición le va a llegar a la

estación central, pero no va a ser ésta la que se encargue de crear el informe

semanal, sino que delega la responsabilidad de su creación al generador de

informe semanal, el cuál, 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 creación 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 colaboración de “Generar Informe Diario General”.


16

iv. Realizar Predicción

La operación del sistema que se encarga de realizar la predicción se representa

abajo y corresponde a un método de la clase Estación Central. Uno de los

temporizadores que se pueden observar en el diagrama de clases, concretamente

el “Solicitador Predicción”, se encarga de invocar periódicamente a este método.

Cuando la Estación Central recibe la operación delega la responsabilidad de ésta

en la clase Generador Predicción, la cual solicita a los proxys de todas las

estaciones que le envíen un informe diario.

Cuando el generador reúne todos los informes invoca al método

GenerarPredicción, con los datos de todos los informes, momento en el que utiliza

el algoritmo diseñado para el cálculo de la predicción y crea una instancia de la

clase Predicción con la salida del algoritmo.

Con estas interacciones entre clases queda definida la operación de Realizar

Predicción, nuevo requisito solicitado por los clientes.

Figura 11. Diagrama de secuencia de “Generar Predicción”.


17

5. Ventajas del Diseño Actual

En esta sección se van a exponer las ventajas obtenidas resultantes de modificar el diseño

anterior hasta obtener el diseño actual. Para reflejar de manera más clara esos cambios se

van a realizar una descripción de los cambios y las ventajas obtenidas, y a continuación se

va a mostrar los diagramas anteriores y después los diagramas actuales correspondientes.

a. Ventajas del diseño orientado a objetos

i. Diagrama de clases de la estación central

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

diagrama de clases que hemos presentado en la última versión del proyecto.

En la versión actual del diagrama de la Estación Central descargamos de

responsabilidad a la clase Estación Central, que como se observa aquí tiene

relaciones de agregación varias clases del diseño. En la nueva versión deshacemos

estas relaciones que consideramos sin sentido.

Además se aprecia, como ya se ha comentado, la nueva funcionalidad añadida de

realizar predicciones meteorológicas en función de los informes de otras

estaciones centrales.


18

Figura 12. Diagrama de clases anterior de la estación central


19

Figura 13. Diagrama de clases actual de la estación central


20

ii. Diagrama de clases subestación

En el diagrama de clases de la subestación de la versión anterior del sistema (la

que se entregó en la primera entrega) se observa un cambio en la realización del

informe diario.

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

tenía la clase Subestación, lo cual decidimos que, seguramente, no sea la opción

más adecuada. Por tanto decidimos insertar un Generador, para seguir con el

patrón que usamos en la estación central.

Entonces, es esta clase generadora la que se encarga de consultar los históricos y

generar el informe, siempre y cuando se lo solicite la Subestación. Observamos

aquí el cambio, ahora la Subestación solo se ocupa de pedirle al Generador un

informe que le ha sido solicitado a través del Proxy.


21

Figura 14. Diagrama de clases anterior de la subestación.


22

Figura 15. Diagrama de clases actual de la subestación.


23

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

diseño de la primera entrega y el diseño de esta última entrega reside en que en

el primera entrega toda la lógica de creación del informe la tenía la subestación,

ya que era quién se encargaba de ir pidiendo al resto de clases que hicieran

determinadas acciones. Mientras que en el segundo diseño 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 creación del informe diario.

Por lo tanto, a pesar de que las modificaciones realizadas respecto al diseño

anterior supone añadir una nueva clase, además de otras cosas como por ejemplo

nuevos métodos, se obtienen una serie de ventajas asociadas.

Una de esas ventajas es, como se acaba de decir, la independencia de la lógica de

creación de un informe diario con respecto a la subestación, por lo que ésta no va

a ser quién tenga la responsabilidad de la creación de dicho informe.

Otra ventaja que se obtiene con este nuevo diseño es la monotonía en la

estructura del mismo. En este caso la generación de un informe diario es

responsabilidad del generador de informe diario, el cual se apoya en otras clases

para obtener la información necesaria para su creación 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 creación de los distintos informes del sistema. Consiguiéndose así

monotonía en el diseño.


24

Diagrama “Generar Informe Diario” del diseño anterior:

Figura 16. Diagrama de colaboración de “Generar Informe Diario” correspondiente al anterior diseño.


25

Diagrama “Generar Informe Diario” del diseño actual:

Figura 17. Diagrama de colaboración de “Generar Informe Diario” correspondiente al actual diseño.


26

ii. Generar Informe Diario General

La principal diferencia radica en que en el diseño correspondiente a la anterior

entrega, la estación central era quién se encargaba de obtener todos los informes

diarios de todas las subestaciones y de crear el informe diario general,

apoyándose en el generador de resumen diario únicamente para que éste

elaborara el resumen de los informes diarios. Sin embargo, en el diseño

correspondiente a la entrega final, la clase que tiene la inteligencia necesaria para

la creación 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 estación central de una carga importante de

trabajo, delegando el trabajo a un generador de informe diario general, el cual

tendrá en sí la lógica de creación de los informes diarios generales.

Al igual que se comentó anteriormente, una ventaja que se obtiene con este

nuevo diseño es la monotonía 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 información necesaria

para su creación 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 creación de otros

informes del sistema, consiguiéndose de esta manera monotonía en el diseño.


27

Diagrama “Generar Informe Diario General” del diseño anterior:

Figura 18. Diagrama de colaboración de “Generar Informe Diario General” correspondiente al anterior diseño.


28

Diagrama “Generar Informe Diario General” del diseño actual:

Figura 19. Diagrama de colaboración de “Generar Informe Diario General” correspondiente al diseño actual.


29

6. Resultados

En este punto se describen los resultados obtenidos tanto durante la realización de este

proyecto como tras la aplicación 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 patrón de diseño en varias funcionalidades. Este patrón se explicará en esta

sección. También 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 versión que se presenta del sistema (que ya viene integrado) y alguna versión

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, además que realizar informes meteorológicos como hasta entonces hacía,

debía estar dotado para realizar predicciones meteorológicas para un día, en función

de los informes de días 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:

- Añadir tres clases (“Generador Predicción”, “Predicción”, “Proxy Estación

Central”)

- La clase “Generador Predicción” se relaciona con la clase “Estación Central”.

Mientras, “Predicción” y “Proxy Estación Central” no tienen relación directa

con el sistema ya diseñado, se relacionan con la también añadida “Generador

Predicción”.

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

supone lo siguiente:

- Parte de la lógica de la generación de la predicción corresponde a la estación

central, mientras que en el nuevo diseño corresponde al generador de

predicciones.

- Si seguimos el mismo patrón con el que diseñamos esta etapa anterior,

añadiríamos las predicciones como relaciones de agregación, por lo que la

estación central supondría un cuello de botella de todo el sistema si diese

algún problema en ésta.

- Con todo esto, se nota una gran sobrecarga de responsabilidad en la estación

central, lo cual no es apropiado.


30

- Por último, los nuevos proxys que se añaden afectan a la estación central,

mientras que en la versión actual los proxys se añaden al Generador de

Predicción, lo cual descarga de responsabilidad a la Estación Central.


31

b. Obtención de un Patrón en el Diseño

Durante el proceso de desarrollo del proyecto software hemos tratado de ser lo más

homogéneos posibles. Este esfuerzo de homogeneizar el sistema ha desembocado en un

desarrollo uniforme y un diseño monolítico, que a la larga nos ha beneficiado, ya que en el

diseño actual pueden apreciarse una gran cantidad de simetrías entre el diagrama de clases de

la subestación y la estación central.

A la larga y tras el desarrollo de la última iteración, hemos localizado un patrón que se repite

siempre en nuestro sistema, debido a la monotonía y homogeneidad de que le hemos dotado.

Este hecho, nos ha conducido al diseño de un patrón a modo de esqueleto para desarrollar

sistemas similares al nuestro.

Por ejemplo, si quisiéramos desarrollar un sistema para la recolección de los votos de los

ciudadanos, el sistema a desarrollar sería muy parecido al nuestro. Si aplicamos el patrón

identificable en nuestro sistema, el desarrollo de este nuevo sistema no solo sería mucho más

rápido, sino que además sería mucho más seguro, debido a que al ya estar las estructuras

montadas y tener algunos métodos construidos no repetiríamos los mismo errores.

Sin más demora, vamos a introducir el patrón identificado en nuestro diseño en forma de

diagrama de clases:

Figura 20. Diagrama de un patrón correspondiente a la anterior explicación.


32

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

diagrama de clases de la estación central (Figura 13, página 19) existe un solicitador, que

dependiendo del tipo de informe requerido cada ‘x’ segundos (minutos u horas) solicita que se

realice una acción, 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 información que necesite, en este caso en particular, solicita la información a las

subestaciones y con esa información realiza los cálculos correspondientes y genera el informe

solicitado.

El caso de la subestación (Figura 15, página 22) es exactamente el mismo, recibe una petición a

través del proxy de realizar un informe, la subestación delega la responsabilidad al generador,

quien obtiene la información de los históricos y luego genera el informe a partir de los datos

derivados del calculador.


33

7. Conclusiones

� A la hora de empezar todo proyecto es mejor hacerlo por una parte pequeña del

problema, y una vez hecha esa parte ampliarla progresivamente con nuevas

funcionalidades y requisitos.

� La asignación de responsabilidades a cada clase no es fácil 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 acción distribuida entre

muchas clases, ya que ante el cambio en la manera de realizarse dicha acción, el

cambio habría que realizarlo en todas esas clases. En cambio, si se tiene centrada

la lógica de la acción en pocas clases, un cambio en esa lógica afectaría a un

menor número 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 diseño 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 fáciles de realizarse sobre el sistema.

� Es beneficioso obtener un diseño que posea cierta monotonía. En el desarrollo del

software la monotonía es un elemento fundamental, ya que posibilita la

reutilización de ideas, código, diseños, etc, y por lo tanto el ahorro de gran

cantidad de tiempo.

� En nuestro caso, hemos encontrado un patrón de diseño a la hora de crear

nuevos informes, predicciones, etc. Esto nos ha facilitado enormemente la

realización de la ampliación, así como la del propio diseño, aparte de dotar de

cierta monotonía y simetría al sistema.


34

Memoria Final de Proyecto Practico Software

Documents

Transcript of Memoria Final de Proyecto Practico Software