Aplicación de Patrones de Software en el Dominio

Aplicación de Patrones de Software en el Dominio de
los Simuladores de Procesos Dinámicos
Edith Cuéllar-Vázquez 1, Gustavo Rodríguez-Gómez 1 y Jaime Muñoz-Arteaga 2.
1
Ciencias Computacionales del Instituto Nacional de Astrofísica Óptica y Electrónica
Luís Enrique Erro #1. Tonantzintla. Puebla, México, CP 72840
[email protected], [email protected]
2
Dpto. de Sistemas de Información de la Universidad Autónoma de Aguascalientes
Av. Universidad # 940, Fracc. Bosques del prado Aguascalientes, México, C.P. 20100
[email protected]
Resumen. La construcción de Simuladores de Procesos Continuos es una tarea
difícil, ya que implica el manejo de diversos aspectos complejos tales como el
progreso del tiempo, los modelos matemáticos, y los métodos numéricos.
Presentamos la identificación de algunos patrones de análisis en el dominio de
Simulación y su influencia en las diferentes etapas del desarrollo, tales patrones
son una solución para el manejo de la complejidad. Hacemos uso de las técnicas
Orientadas a Objetos y herramientas de alto nivel como UML y los patrones de
diseño de software. El objetivo final es proveer una infraestructura que permita
desarrollar Sistemas de Procesos Continuos con los atributos de flexibilidad,
extensibilidad, mantenibilidad y reusabilidad.
Palabras Clave: Patrones de Análisis en Simulación, Diseño de Simuladores
de Procesos Dinámicos, Simulación e Ingeniería de Software.
1. Introducción
Actualmente, el desarrollo de Simuladores de Procesos Continuos, DSS por sus siglas
en ingles, se caracteriza por tener un bajo nivel de flexibilidad, reusabilidad y
mantenibilidad. La construcción de DSSs requiere el manejo de la complejidad en
diferentes aspectos como son el progreso del tiempo, los modelos matemáticos y los
métodos numéricos. Para dar solución a los problemas mencionados podemos hacer
uso de paquetes de simulación de alto nivel como SIMULINK, sin embargo cuando el
tamaño del problema crece puede no ser adecuado o necesitamos representar
fielmente la complejidad del sistema real, es necesario programar el DSS en un
lenguaje de propósito general como C, C++ ó FORTRAN.
La mayoría de las veces las características inherentes de un simulador son
reprogramadas cada vez que se construye un nuevo simulador para otro dominio. Por
esta razón es una buena idea reusar tales funcionalidades similares, pero haciéndolo a
través de métodos probados.
Los Simuladores de Procesos Continuos están compuestos intrínsicamente por
módulos interconectados, que pueden ser fácilmente representados usando las
técnicas orientadas a objetos y las herramientas que lo soportan. Los Patrones de
Software son una herramienta que permite el reuso, mantenibilidad, la reducción de
costos, de una manera flexible durante todas las etapas del desarrollo.
Nuestra propuesta para desarrollar la Infraestructura es llevar a cabo todo el
proceso del ciclo de software, específicamente la identificación de patrones de
análisis se llevo a cabo con la recopilación de la información necesaria que se
requiere para construir un DSS, a partir del análisis de diferentes DSSs. Con esta
información, identificamos los requerimientos del sistema, los cuales son el punto de
inicio del desarrollo. El siguiente paso es obtener las funciones semejantes y
determinar la mejor forma de agruparlas, y finalmente la obtención de los diagramas
conceptuales que derivan en los patrones de análisis.
El siguiente paso en el ciclo de vida es el diseño del sistema, que debe ser
construido tomando como base la etapa de análisis.
Presentamos la identificación de algunos patrones de análisis en el dominio de los
DSSs, y su efecto en las etapas subsecuentes del desarrollo. Además, presentamos los
diagramas de diseño derivados y basados en los patrones de diseño [3]. El resultado es
un diseño con bajo acoplamiento y alta coherencia, extendible y mantenible.
Finalmente presentamos un caso de estudio, aplicando el diseño propuesto.
El esquema del artículo es el siguiente. En la Sección dos, explicamos la
problemática de diseño en el desarrollo de DSSs. En la Sección tres listamos algunas
definiciones necesarias en el contexto de patrones de software. En la Sección cuatro,
describimos el uso de los patrones de software en los sistemas simuladores, y
proponemos un conjunto de Patrones de Análisis. En la Sección cinco mostramos el
uso de los patrones de análisis en la construcción del diseño. En la Sección seis
incluimos un caso de estudio que muestra el uso de la infraestructura propuesta, para
implementar un DSS. Finalmente, en la Sección siete concluimos con una breve
discusión de nuestra investigación y el trabajo futuro.
2. Problemática de Diseño en Simuladores de Procesos Dinámicos
Un simulador es un sistema de software que imita tanto el comportamiento de un
sistema del mundo real, como los procesos de entrada que manejan o controlan el
sistema simulado. Las simulaciones pueden usarse para obtener conocimiento acerca
de sistemas existentes, para predecir su comportamiento y para propósitos de
enseñanza.
Además su uso se ha extendido en la industria debido a que la simulación permite
analizar el sistema real en situaciones difíciles, peligrosas o cuando resulta muy
costoso recrear un estado del proceso.
Una de las características claves de la simulación es la habilidad de modelar el
comportamiento del sistema considerando el progreso del tiempo. Las características
inherentes a las aplicaciones que simulan algún sistema deben ser consideradas desde
la etapa de análisis para reflejar los requerimientos asociados durante la etapa de
diseño del sistema.
Construir un modelo de simulación puede tomar mucho tiempo y en múltiples
ocasiones se realizan modelos muy parecidos a los ya creados. Para llevar a cabo esta
construcción existen sistemas llamados ambientes de simulación los cuales son
herramientas interactivas de aprendizaje e investigación que brindan al usuario un
acceso flexible a lo recursos computacionales. Estas herramientas permiten el
desarrollo de modelos matemáticos que se comportan como el sistema físico. Los
modelos son verificados y validados por medio de pruebas, las cuales permiten
optimizar los resultados desde la perspectiva de aproximación, estabilidad y eficiencia
computacional.
Los ambientes de simulación usualmente cuentan con los elementos necesarios
para la construcción de simulaciones, pero tal construcción se encuentra limitada por
el número y tipo de elementos que el ambiente proporcione.
Si se requiere representar fielmente la complejidad de un sistema en una
simulación ó si el tamaño del sistema no es soportado por los elementos de un
ambiente de simulación, necesitamos codificar el sistema en un lenguaje de propósito
general para lo cual debemos dar una solución a los problemas de flexibilidad,
mantenibilidad, reducción de costos y principalmente la falta de reuso. El ultimo
problema puede ser fácilmente atacado debido a los modelos similares que los
desarrolles encuentran en la construcción de DSSs.
Algunos autores han propuesto algunas soluciones basadas en componentes para
algún dominio en particular, como por ejemplo turbinas de gas [1]. Otro precedente es
el trabajo hecho por Ulf Ekström [2], quien propone un diseño basado en patrones de
diseño, donde usa los propuestos por Gamma [3] y también propone algunos nuevos,
pero este trabajo se refiere únicamente al ambiente de desarrollo Erlang/OTP.
3. El Paradigma de Patrones
Los patrones en el contexto del desarrollo del software son un medio de registrar la
experiencia durante las diferentes etapas de este. La experiencia registrada puede ser
aplicada en la construcción de sistemas nuevos de la misma clase, lo que trae como
consecuencia un conjunto de beneficios como son el reuso exitoso de los modelos
conceptuales, diseños y arquitecturas. Los patrones de software son un medio para
compartir el conocimiento y nos proporcionan un lenguaje común entre diseñadores.
[4].
3.1 Patrones de Análisis
La frontera entre análisis y diseño no es muy clara, Fowler [5] define tal frontera
estableciendo la tarea principal del análisis como el tratar de entender el problema, lo
que nos lleva a decir que en el diseño se busca resolverlo. El análisis del sistema por
lo tanto busca observar debajo de la superficie y revelar los principios básicos. Para
cumplir este objetivo es necesario crear los modelos conceptuales que muestren los
detalles identificados.
Debido a que nuestro trabajo busca utilizar las herramientas del paradigma
orientado a objetos, el análisis debe ser realizado bajo las mismas reglas. Uno de los
principios del modelado orientado a objetos es que estos modelos conceptuales se
representan a través de interfaces (tipos) y no a través de implementaciones (clases).
[5]
Podemos identificar necesidades del usuario comunes y si encontramos una buena
solución para tal necesidad en un contexto práctico, entonces es posible usar la misma
idea en otros contextos. Esto nos lleva a identificar nuevos patrones de análisis.
Fowler define los patrones de análisis como, “una idea que ha sido útil en un
contexto practico y lo será probablemente en otros.”
3.2 Patrones de Diseño
“Un patrón de diseño es una abstracción de una forma concreta que ocurre repetidas
veces en un contexto arbitrario” [6].
Los patrones de diseño nos permiten resolver varios problemas que enfrentan
comúnmente los diseñadores de software orientado a objetos, a través de diferentes
principios que debe cumplir un buen diseño orientado a objetos, como son
“Programar a la interfaz”, “Favorecer a la composición sobre la herencia” y
“Diseñar para el cambio” [3].
Es importante mencionar que un patrón de diseño es una notación gráfica que
denota relaciones entre clases y objetos, pero además cuenta con documentación
acerca del problema que resuelven, su intención, su solución, bajo que contexto,
ejemplos concretos, sugerencias para su implementación. Además registra las
alternativas, decisiones e intercambios necesarios para su aplicación [3].
Con respecto a la aplicación de los patrones de diseño debemos tomar en cuenta
que estos se agrupan en catálogos dependiendo de su tipo de aplicación, por ejemplo
existen patrones de diseño específicos para crear interfaces de usuario, para
aplicaciones basadas en Web, etc. La aplicación de los patrones de diseño puede
complicarse por la inexperiencia del diseñador en su aplicación y por la gran cantidad
de patrones existentes, por lo que se recomienda hacer uso de los pasos propuestos
por Gamma et al. [3] para seleccionar y usar los patrones de diseño adecuados.
3.3 Efecto Delta
La delgada línea entre el análisis y el diseño de un sistema no es fácil de distinguir
e incluso muchas veces el resultado del análisis es ignorado al construir el diseño, lo
cual es un desperdicio de recursos y tiempo al tener que rehacer todo de nuevo.
Por lo anterior es importante asegurarnos de que cada etapa del ciclo de vida del
software sea la base de la siguiente, teniendo en mente el objetivo de cada una de ellas
y considerando que las decisiones tomadas no pertenezcan a otra etapa. Las
decisiones tomadas durante la etapa de análisis tendrán un efecto en el diseño, al
darnos la guía y base para su construcción y acotando los patrones de diseño a
utilizar, tal implicación es llamada efecto delta [4].
En este trabajo la aplicación de los patrones de análisis es realizada manualmente,
pero podría automatizarse en trabajos posteriores.
4. Sistemas de Simulación y el paradigma de Patrones
Los sistemas construidos sobre la base del paradigma orientado a objetos facilitan la
flexibilidad y el reuso. Técnicas como el uso de patrones de diseño además de
reforzar estos dos puntos, aplican de manera directa los diferentes principios antes
mencionados, que debe cumplir un buen diseño orientado a objetos. Esto reduce el
tiempo de diseño y construcción del sistema y facilita la mantenibilidad, favoreciendo
a la extensión sobre el cambio.
Finalmente, con respecto a la problemática del alcance de los ambientes de
simulación, los patrones nos dan una herramienta que permite la inclusión de nuevos
elementos y nuevas funcionalidades desde la etapa de diseño, permitiendo realizar
simulaciones en diferentes dominios de aplicación, de manera rápida y sencilla.
4.1 Requerimientos de un Sistema Simulador de Procesos Continuos
El primer paso en el desarrollo de un sistema de software en la recopilación de
información, y la segunda etapa es el análisis la información recopilada. Se analizaron
cuatro sistemas para obtener los requerimientos comunes y el resultado de este
análisis son los modelos conceptuales y la clara definición y especificación de los
requerimientos del sistema.
A continuación listamos los requerimientos identificados, los cuales son
independientes de un dominio de aplicación específico.
1.
2.
3.
4.
5.
6.
7.
8.
Definición del sistema.
Definición de las condiciones iniciales.
Definición de parámetros por parte del usuario.
Definición de parámetros internos al sistema.
Definición y selección del modelo.
Definición y selección del método numérico.
Ejecución de la simulación.
Visualización de resultados.
5. Diseño e Implementación de un Simulador haciendo uso de los
Patrones de Análisis
Tomando en cuenta el análisis realizado en la sección previa identificamos varios
patrones de análisis. Algunos de ellos se refieren al proceso de construcción del
sistema, otros a la arquitectura y algunos procesos internos. A continuación
mostramos algunos patrones identificados y su aplicación y efecto en las etapas de
diseño e implementación.
5.1 Patrón “Modularización General del Sistema de Simulación”
El primer problema al que nos enfrentamos en la construcción de un sistema
simulador es el tener una visión general de sus componentes y su interacción con
elementos externos de entrada o salida. Después de analizar diferentes sistemas de
simulación identificamos algunos módulos comunes. Con base en estos módulos
definimos el patrón de análisis “Modularización General del Sistema de Simulación”,
el cual representa la arquitectura básica para un sistema simulador de procesos
continuos. Este patrón se muestra en la figura 1. Para la representación de los patrones
de análisis propuestos usamos una notación similar a la propuesta por Sanz [7].
Figura 1. Patrón “Modularización General del Sistema de Simulación”
5.1.1 Desarrollo del Diseño e Implementación
A partir del patrón de análisis “Modularización General del Sistema de Simulación”
de la figura 1, proponemos el diagrama de diseño, derivado y acotado por el efecto
delta. Para su construcción también hacemos uso de los patrones de diseño existentes,
propuestos por Gamma et al. [3].
El diagrama muestra los módulos que satisfacen los requerimientos generales del
sistema, pero en términos de clases y sus relaciones.
a. Patrón de Diseño Fachada
Los módulos que podemos asociar son, el sistema central, el modelo y su
correspondiente método resolvedor y las clases necesarias para la interacción con el
exterior. Con respecto a este último punto aplicamos el patrón de diseño Fachada,
para definir la interfaz de entrada de los datos referentes a las condiciones iniciales, el
modelo, los parámetros externos proporcionados por el usuario y la selección del
método revolvedor. La característica principal del uso de este patrón es que permite la
entrada de datos y oculta el funcionamiento interno del simulador hacia la clase
cliente, que puede ser la interfaz gráfica, la línea de comando o el usuario
directamente.
Dicho funcionamiento que no necesita ser conocido por el cliente, de tal manera
que si se requiere un cambio en el funcionamiento interno, la interfaz no se ve
afectada.
Figura 2. Diagrama de Diseño derivado del Patrón de Análisis “Modularización
General del Sistema de Simulación”
El lenguaje de propósito general seleccionado para la implementación del presente
caso de estudio es C++. Primero declaramos la clase de tipo Fachada en un archivo de
cabecera:
class FachadaSim {
public:
FachadaSim();
void FachadaGate(CString _m_csArchivo, int _RBactive);
};
El método FachadaGate, tiene como parámetros una variable entera que define el
método resolvedor y el nombre del archivo que contiene los datos de entrada.
El siguiente fragmento de código muestra como la ventana cliente al recibir el
evento del botón ejecutar solo necesita instanciar la clase fachada y llamar al método
FachadaGate, lo que disparará inmediatamente la lectura de los datos de entrada, la
creación del sistema de simulación en base a la modularización definida, la ejecución
de la simulación y finalmente el despliegue de resultados.
void CventanasDlg::OnBnClickedButton1(){
FachadaSim *FS = new FachadaSim();
FS->Fachada_Gate ( m_csArchivo, Rbactive );
}
Todas las funcionalidades mencionadas son transparentes a la interfaz gráfica, razón
por las que no las detallamos en esta sección.
b. Patrón de Diseño Comando
Para la creación de cada clase en el diagrama anterior hacemos uso del patrón de
diseño Comando, el cual encapsula una solicitud como un objeto, por lo tanto permite
parametrizar los clientes con diferentes solicitudes a objetos sin preocuparse de la
operación a realizar. El diagrama de diseño obtenido es el presentado en la figura 3.
Figura 3. Creación de las clases usando el Patrón Comando
Este diagrama de diseño toma como base los requerimientos del usuario definidos en
la sección 4.
Es en el contenido de la función FachadaGate, presentada en la subsección anterior,
donde se instancian las clases que definen el sistema de simulación modularizado.
void Facade_Simula::Facade_Gate(CString _m_csArchivo,
int _RBactive){
//Creación de la clase que almacenará el Sistema
SistConc *SDS = new SistConc(_RBactive);
//Comando que crea el Sistema
CreaCommand *CreaSim = new
CreaCommand(_m_csArchivo,SpringDashpotSystem);
//Ejecución de la Creación
CreaSim->Execute();
//Comando que ejecutará la simulación
ExecuteCommand *ExeSim = new
ExecuteCommand(SpringDashpotSystem);
//Ejecución de la Simulación
ExeSim->Execute();
}
5.2 Patrones de Análisis Identificados
Se han identificado siete patrones de análisis, Validación–Verificación, Verificación
de los resultados, Manejo de los datos, Funciones Básicas, Sistema de Simulación,
Fotografiado y Modelo-Resolvedor [8]. Además obtuvimos diez diagramas de diseño
a partir de los patrones de análisis identificados y usando los patrones de diseño
existentes. Todos estos diagramas tanto conceptuales como de diseño fueron usados
para la construcción del Caso de Estudio pero no se incluye su descripción de tallada
debido al espacio.
6. Caso de Estudio - Sistema de Control
Proponemos el siguiente caso de uso para dar un ejemplo de aplicación El caso
propuesto es un problema de optimización, que consiste en un sistema de control de
posición, formado por un motor de corriente continua controlado por campo [9]. El
motor esta representado por el siguiente sistema de ecuaciones diferenciales, y debe
ser simulado para obtener el comportamiento global del control:
•
x1 = x 2
•
x2 =
1
x 2 + 5 x3
3
•
x 3 = − x3 + 0.1e 2f
El programa principal hace uso de un algoritmo de optimización, que a su vez llama a
la función de índice de costo.
∫ [(r (t ) − x (t ))
tf
J=
2
1
]
+ Re 2f (t ) dt + w1 (x1 (t f ) − rss ) + w2 (x2 (t f )) + w3 x32 (t f )
2
2
t0
•
donde : x1 = θ , x2 = θ , x3 = i f
e f = K1 (r − x1 ) − K 2 x2 − K 3 x3
Donde r representa los grados de referencia, θ es el ángulo de posición del eje de
salida, R es una constante positiva, ef es el voltaje del campo, rss es una constante de
estado estable, θ e i son variables de estado y wn son vectores de peso.
La función J requiere la simulación del modelo para obtener uT = [K1, K2, K3] de
tal manera que u sea un mínimo, ya que representa las constantes que definen el error
deseado ef. El diagrama de simulación que representa el problema se muestra en la
figura 4.
Figura 4. Diagrama de simulación del Controlador
6.1 Implementación
La implementación de la parte de control se realizo haciendo uso de la rutina
propuesta en [6] respetando su interfaz y adaptándola para poder usarla por medio del
patrón Adaptador, propuesto por Gamma [3]. El control se comunica con la parte de
simulación por medio del patrón Fachada propuesto en la sección 5, proporcionando
los parámetros de entrada y las condiciones iniciales. Internamente la simulación se
desarrollo haciendo uso de los patrones de análisis propuestos.
6.2 Resultados
La salida obtenida al ejecutar el caso de estudio, para obtener un ángulo en radianes
r = r ss = θ = 10, es:
K1 = 35.08,
K2 = 27.51,
K3 =43.07
Para corroborar el resultado obtenido simulamos el modelo sustituyendo estos valores
como entradas y el resultado se muestra en la gráfica de la figura 5, donde mostramos
la relación tiempo/posición del eje y la curva que describe se estabiliza en 1.7
segundos aproximadamente. Usamos el método numérico RungeKutta4 con paso de
integración de 0.01 seg., Tiempo de inicio = 0 y Tiempo final = 3.3.
Figura 5. Gráfica obtenida al simular el modelo
7 Conclusiones
El éxito de un simulador depende de la precisión con la que se reproduce el
funcionamiento del sistema simulado, es por esto que en su construcción deben
emplearse técnicas que nos permitan obtener un sistema confiable, robusto, que
permita ser mantenido de una manera sencilla y rápida, También necesitamos que sea
flexible permitiendo la extensión de su funcionalidad.
Los patrones de diseño son una herramienta que nos dan todos estos beneficios si
son aplicados adecuadamente, y si se realiza un análisis detallado y no se aplican de
manera arbitraria.
Los requerimientos nos dan una guía para identificar los modelos conceptuales y
por lo tanto los patrones de análisis, estos a su vez nos dan una guía para construir los
diagramas de diseño del sistema, debido al efecto delta.
La infraestructura formada por el conjunto de modelos y diagramas es la base para
la construcción de sistemas simuladores de procesos continuos en diferentes dominios
de aplicación. Las características inherentes de las metodologías orientadas a objetos
permiten el reuso extensivo, es decir en todas las etapas del desarrollo. Así un nuevo
simulador no tiene que ser desarrollado desde cero.
Hacemos notar que es posible el uso de la infraestructura por otros sistemas como
en el caso de estudio propuesto, ya que el encapsulamiento de la misma permite su
inclusión sin afectar al sistema general.
Finalmente como trabajo futuro, aplicaremos la infraestructura para construir
nuevos sistemas simuladores en diferentes dominios para estudiar el beneficio
obtenido. Además puede ser base para automatizar la generación de sistemas de este
tipo a partir de los requerimientos del sistema.
8 Agradecimientos
Agradecemos al Consejo Nacional de Ciencia y Tecnología de México (CONACYT),
ya que parte de este trabajo es apoyado por el proyecto CONACYT-2002-C01-40022.
Los autores también agradecen el apoyo dado por el Instituto Nacional de Astrofísica
Óptica y Electrónica (INAOE) y la Universidad Autónoma de Aguascalientes (UAA)
en el desarrollo de este proyecto.
9. Referencias
1. Reed J. A., Afjeh, A.: Computational Simulation of Gas Turbines: PART I- Foundations of
Component-Based Models. In: ASME Transactions (1999)
2. Ekström, U.: Design Patterns for Simulations in Erlang/OTP. Uppsala Master's Thesis in
Computing Science 178 (2001)
3. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns, Elements of Reusable
Object-Oriented Software. Addison-Wesley Publishing Co. (1995)
4. Molina, P. J., Melia, S. Pastor, O.: User Interface Conceptual Patterns. Proceedings del 4to
Workshop Internacional de Diseño, Especificación & Verificación de Sistemas de
Información DSVIS’2002, Rostock, Alemania. (2002) 201-214
5. Fowler, M.: Analysis Patterns: Reusable Object Models. Object Technology Series.
Addison-Wesley Publishing Company (1997)
6. Gilbert, J.C., Nocedal, J.: Global Convergence Properties of Conjugate Gradient Methods,
SIAM Journal on Optimization, Vol. 2. (1992) 21-42
7. Sanz, R., Zalewski J. Pattern-Based Control Systems Engineering. IEEE Control Systems,
Vol. 23, No. 3 (2003) 43-60
8 Cuellar-Vazquez, E. Rodríguez-Gomez, G., Muñoz-Arteaga, J.: Software Patterns
Identification to Implement Dynamic Simulation Systems. Proceedings of 2004 Summer
Computer Simulation Conference (SCSC'04). San Jose, California, USA. (2004)
9. Hasdorff, L.: Gradient Optimization and Nonlinear Control. A Wiley-Interscience
publication (1976)