Printer Friendly

Creacion de una arquitectura utilizando Lenguaje de Modelado Unificado (UML) en la implementacion de un Lenguaje Especifico de Dominio Interno (LEDI): construccion de un LEDI para el modelado de problemas de optimizacion.

Creating an architecture using Unified Modeling Language (UML) in the implementation of an Internal Domain Specific Language (IDSL): construction of an IDSL for modeling optimization problems

Criacao de uma arquitetura utilizando Linguagem de Modelagem Unificada (UML) na implementacao de uma Linguagem Especifica de Dominio Interno (LEDI): construcao de uma LEDI para a modelagem de problemas de otimizacao.

I. INTRODUCCION

Dentro de los diversos roles que debe cumplir un ingeniero de sistemas, uno de los mas importantes es el ejercido como desarrollador de software. Es alli donde su capacidad de creatividad y manipulacion de los lenguajes de programacion se pone a prueba, no obstante existen ocasiones donde seria mas apropiado contar con un lenguaje que fuera enfocado al dominio del problema que se esta tratando de solucionar. Esta situacion se presenta con los Lenguajes de Proposito General donde se necesita una buena cantidad de lineas de codigo para expresar la solucion requerida, dichos lenguajes poseen elementos que no son propios del dominio (tal como parentesis, palabras reservadas, entre otros) lo cual resta expresividad y anade complejidad al momento de depurar o buscar errores en el codigo. Por el contrario, los Lenguajes Especificos de Dominio son construidos de modo que abordan el problema en terminos de su dominio, empleando sintaxis acorde con el contexto logrando una mejor abstraccion alcanzado una mejor comunicacion con los expertos del dominio y mejorando la productividad en el desarrollo [1]

II. DEFINICION DEL PROBLEMA

Desde el principio de los tiempos, el hombre ha utilizado senales, diagramas y dibujos para representar el mundo que lo rodea. La necesidad de representar sus ideas, lo ha conducido a un proceso de abstraccion que dio como origen la creacion del lenguaje hablado y escrito. En la actualidad, el hombre sigue en esta busqueda donde las ciencias de la computacion han permitido la creacion de lenguajes artificiales, en especial los de programacion, que ayudan a concretar dichas abstracciones, que se conciben en el analisis de un problema o situacion en particular.

Cada uno de estos escenarios maneja su propio contexto el cual posee una semantica propia de su universo, es decir, cada entorno maneja su propia dinamica y terminos que hacen posible la interaccion dentro de este espacio, y es alli donde estos poseen una significancia valida, de modo que si se utilizasen en un espacio diferente, carecerian del significado que los hacen validos.

Por ejemplo, imagine que ha ingresado a una organizacion dedicada a la intermediacion financiera y se le pide que modele su sistema de intermediacion, enfocandose en las actividades de comercio y liquidacion. Segun [12] un modelo es una representacion abstracta de un sistema y la porcion del mundo que interactua con el. Sin embargo, para construir este modelo es necesario utilizar herramientas (como UML) y tecnicas que permitan representar aquellos artefactos o componentes que constituyen el dominio del problema de modo que el modelo resultante pueda ser llevado al escenario llamado, dominio de soluciones.

Un dominio de soluciones, constituye el espacio donde aquellos componentes que pertenecen al dominio del problema son representados por medio de tecnicas apropiadas [4]. Es decir, supongamos que ha escogido utilizar la metodologia orientada a objetos, por lo tanto, las clases, objetos y metodos, conforman los principales artefactos del dominio de soluciones, y por medio de estos se puede realizar una mejor representacion de los componentes de alto nivel del dominio del problema.

Asi mismo, es en esta fase de construccion de artefactos en el dominio de soluciones, donde se utilizan, por lo general, los lenguajes de programacion de proposito general, cuya caracteristica principal radica en que su semantica y la gramatica de las instrucciones que ellos poseen no estan enmarcadas en la terminologia y contexto de un dominio especifico siendo este atributo un obstaculo cuando lo que se intenta es representar un dominio especifico en su mas pura expresividad.

Por tal motivo, cuando se llega a esta situacion, donde las caracteristicas del dominio del problema tiene particularidades que una herramienta generica no puede abordar de forma efectiva [20], es necesario crear un lenguaje que sirva para el proposito requerido; esto es lo que se denomina como Domain-Specific Language (DLS) o Lenguaje Especifico de Dominio (LED), donde la caracteristica principal de los mismos, es proveer un lenguaje conciso, a medida, que sea facil para ingenieros y expertos en el dominio de aprender, entender y aplicarlo para una clase especifica de problema [20].

En efecto, durante la investigacion que se planteo, la cual radica en la creacion de un LEDI Orientado al Modelado de Problemas de Optimizacion, se encontro que existen los llamados Lenguajes de Modelado Algebraico, los cuales tienen como proposito servir para el modelado de problemas orientados a la optimizacion de funciones. No obstante, estos lenguajes solo puede ser comprensibles por personas que tienen formacion como programador o aquellas que estarian dispuestas a invertir tiempo considerable en aprenderlos, ya que la forma como fueron concebidos, requiere un grado de conocimiento referente a la programacion para lograr crear un modelo pertinente al problema planteado.

Asi pues, los profesionales pertenecientes a las ramas de la Ingenieria Industrial, Administracion Financiera y Negocios Internacionales, en fin, todas aquellas relacionadas con la Investigacion de Operaciones y que necesitan la formulacion de modelos dentro de su quehacer, y en el preciso caso la optimizacion de funciones, tienen una barrera al tratar de crear los modelos pertinentes empleando estos Lenguajes de Modelado Algebraico, lo cual les deja como alternativas la utilizacion de hojas de calculo u otras herramientas no tan efectivas y faciles de usar como se necesitan.

III. JUSTIFICACION

Disenar una funcion objetivo para su optimizacion es un proceso de abstraccion donde se quiere expresar el comportamiento de cierto fenomeno por medio de variables representativas y algunas restricciones que estan atadas a esta.

Para realizar esta abstraccion es necesario contar con un lenguaje que permita la creacion de dicho modelo. Dentro de esta categoria se encuentra OPL, AIMMS, OptimJ, GAMS, Zimp, entre otros, los cuales se denominan como Lenguajes de Modelado Algebraico para Optimizacion (Algebraic Modeling Languages for Optimization) para programacion matematica.

Sin embargo, aunque ellos cuentan con una sintaxis que permite una amplia expresividad y emplean instrucciones como maximize (maximizar) y subject to (sujeto a), que son propias del dialecto utilizado en la optimizacion de funciones, el resto del codigo es dificil de construir para una persona que no tenga conocimientos en programacion.

Por el contrario, los Lenguajes Especificos de Dominio (LED) o Domain-Specific Language (DSL) son construidos de modo que el usuario del lenguaje especifique el comportamiento que desea en terminos del dominio (contexto) del problema, eliminando, en la medida de lo posible, aquellos caracteres (como puntos y comas, definicion de tipos de datos o definicion de variables) que no son parte fundamental del dominio, de modo que el lenguaje fluya por medio de expresiones naturales propias del dominio sin presentar ambiguedad en sus terminos y ofreciendo la expresividad necesaria que permita el modelado del problema por parte de un usuario que conozca del dominio del problema pero que no sea necesariamente un programador.

IV. ESTADO DEL ARTE

A continuacion se presentan algunos de los Lenguajes de Modelado Algebraico encontrados durante la investigacion:

* GAMS (General Algebraic Modeling System)--ultima version estable marzo 15 de 2016: es un sistema de alto nivel para el modelado de sistemas para programacion matematica y optimizacion. GAMS, esta adaptado para aplicaciones complejas de gran escala y permite construir modelos mantenibles que pueden ser adaptados a cualquier situacion. [23]

* Pyomo--ultima version estable enero 22 de 2015: es un paquete de software open-source basado en Python que soporta un conjunto diverso de funcionalidades para la formulacion, resolucion y analisis de modelos de optimizacion. [24]

* AIMMS (Advanced Interactive Multidimensional Modeling System)--ultima version estable julio 7 de 2014: es un software disenado para modelar problemas tanto de optimizacion como de planificacion. Consiste en un Lenguaje de Modelado Algebraico y un ambiente integrado de desarrollo. [25]

* ASCEND--ultima version estable abril 30 de 2012: ASCEND es un programa libre open-source modelos matematicos. ASCEND puede resolver sistemas de ecuaciones no lineales, problemas de optimizacion lineales y no lineales y sistemas dinamicos expresados en la forma de ecuaciones diferenciales/algebraicas. [26]

VI. C4: CONTEXTO, CONTENEDORES, COMPONENTES Y CLASES

Uno de los problemas que se presento en la creacion de la arquitectura, fue alcanzar una forma efectiva de comunicar el diseno sobre el cual se basara el LEDI. De forma, que a medida que se fuera construyendo la arquitectura se pudiera visualizar la evolucion de la misma. Por tanto, se empleo UML como un medio de comunicacion estandarizado que permite obtener este fin.

No obstante, UML presenta una serie de diagramas que permiten observar el sistema dinamica y estaticamente [21]. De modo que para analizar la forma o estructura que va tomando la arquitectura del LEDI a medida que va evolucionando es conveniente emplear los diagramas pertenecientes al area estructural particularmente los diagramas de clases y componentes.

Por otro lado, la sola escogencia de este enfoque no garantiza que se alcance automaticamente un diseno que comunique efectivamente la arquitectura del sistema, por lo tanto se hace necesario encontrar una metodologia que permita alcanzar este objetivo y que permita, a la vez, construir diagramas que sean sencillos y sobre todo que expresen y transmitan la realidad del sistema.

Asi pues, Simon Brown [22] presenta su metodologia llamada C4, la cual propone que un sistema de software esta hecho por un numero de contenedores, que a su vez se componen de una serie de componentes, que a su vez son implementados por una o mas clases. Esto permite visualizar la estructura de una arquitectura de software de forma simple, reflejada como una serie de bloques (Fig. 1) donde cada uno representa un nivel de abstraccion dentro de la jerarquia.

[FIGURA 1 OMITIR]

A continuacion se presenta la definicion de cada uno de los niveles [22].

* Sistema de Software (Software System): es el nivel mas alto en la abstraccion. En este nivel se observa el sistema en su forma general, de modo que se deben mostrar los actores que interactuan con el mismo, ya sean usuarios u otros sistemas, los detalles tecnicos no son importantes ya que lo que se pretende es mostrar un panorama general.

* Contenedores (Container): un diagrama de contenedor muestra las decisiones tecnologicas a un alto nivel, muestra como las responsabilidades son distribuidas a traves de ellos y como los contenedores se comunican. Para la presente investigacion se utilizo el diagrama de paquetes para representar este bloque, de modo que se pudiera identificar la estructura del sistema desde una perspectiva de capas como la que puede ofrecer este tipo de diagrama.

* Componentes (Component): por cada contenedor, un diagrama de componentes permite observar los componentes logicos claves y sus relaciones. Para la presente investigacion se empleo el diagrama de componentes para mostrar esta fase del modelo C4, a traves de este tipo de diagramas se mostro como cada uno de los paquetes que conforman el bloque de contenedores es conformado por componentes que desarrollan la implementacion de una determinada funcionalidad.

* Clases (Classes): es un nivel opcional, es utilizado para explicar como un patron o componente en particular sera implementado. Para la investigacion fue necesario llegar hasta este nivel, puesto que para lograr la implementacion del Modelo de Dominio que sustenta el LEDI se necesito emplear el diagrama de clases que soportan el mismo.

V. PATRONES DE CONSTRUCCION DE UN LENGUAJE ESPECIFICO DE DOMINIO INTERNO (LEDI) Y SELECCION DE UNO DE ELLOS PARA IMPLEMENTAR EN EL PROYECTO

La clasificacion que se hace de los Lenguajes Especificos de Dominio esta relacionada con la forma como estos son implementados, es decir, cada una de los enfoques propuestos presenta caracteristicas propias que se traducen en el diseno e implementacion del LED. Segun [1] existen dos enfoques principales de LED que son LED Interno (LEDI) y LED Externo. El primero ha sido seleccionado como objeto de la investigacion realizada.

LED Interno (LEDI)

Un LED Interno es aquel que usa la infraestructura de un lenguaje de programacion existente (tambien llamado lenguaje anfitrion) para construir la semantica de un dominio-especifico [4]. Ampliando esta definicion es util especificar que significa cuando se habla de "usar la infraestructura de un lenguaje de programacion existente".

Como ya es conocido, dentro de la composicion que posee un lenguaje de programacion no se puede olvidar mencionar su compilador, el cual posee diversas fases como son: analizador lexico, analizador sintactico, analizador semantico, etc. Es decir, se cuenta con una infraestructura ya implementada la cual sera utilizada por el LEDI.

Por tal motivo, un LEDI tambien puede ser llamado Lenguaje Especifico de Dominio Embebido, refiriendose al hecho que el LED, al utilizar la infraestructura de un lenguaje anfitrion, estara ligado a las restricciones de este, por lo tanto, cualquier expresion que se utilice debe ser un expresion legal en el lenguaje anfitrion, de ahi que sea importante escoger un lenguaje anfitrion versatil que cumpla con los criterios de expresividad requeridos; tal como lo ofrece el lenguaje de programacion Ruby a traves de su Metraprogramacion, la cual esta estrechamente ligada a la idea de la creacion de Lenguajes Especificos de Dominio [2].

Antes de implementar un LEDI es necesario evaluar el tipo de sintaxis que se desea obtener, es decir, cual sera la estructura o apariencia que esta tendra para ser presentada al usuario. Para lograr esto, Martin Fowler en [1] plantea tres patrones principales de implementacion llamados Encadenamiento de Metodos (Method Chaining), Funcion anidada (Nested Function) y Secuencia de funciones (Function Sequence).

Sin embargo, haciendo un analisis de la forma y el tipo de sintaxis a la que se pretendia llegar en la investigacion (como se muestra en la Fig. 2), se analizo una cuarta tecnica tambien presentada en [1] llamada Cierres Anidados (Nested Closures), encontrando que esta tecnica se adapta perfectamente al uso de Ruby como lenguaje anfitrion y se fundamenta esencialmente en el uso de Bloques.
Fig. 2. Sintaxis resultante en la implementacion del LEDI.
(Fuente: A. Rodas, J.I Rios y G.R Solarte)

max{'2x1 + 0.34x2').subjectTo {
     restrictionA '0.03x1 > 0.98'
     restrictionB '10.6x1 <= 0.002'
     restrictionC '2x1 >= 1.57'}


Asi mismo, el patron Cierre Anidado se muestra como una mejora de las Funciones Anidadas, Secuencia de Funciones y Encadenamiento de Metodos [1], ya que permite combinar estas tecnicas creando un lenguaje versatil. Por consiguiente, se realizo la eleccion de esta tecnica para ser la utilizada en la creacion del LEDI objeto de la investigacion.

VI. DEFINICION DE LA ARQUITECTURA UTILIZANDO LENGUAJE DE MODELADO UNIFICADO (UML), EN LA IMPLEMENTACION DE UN LENGUAJE ESPECIFICO DE DOMINIO INTERNO

Uno de los objetivos en la aplicacion de la metodologia C4 fue mejorar la abstraccion en la representacion del sistema mediante la creacion de varios diagramas. Por tanto, siguiendo dicha metodologia se inicio la construccion de la arquitectura con un Diagrama de Contexto del Sistema (que puede ser equivalente a un Diagrama de Casos de Uso) permitira identificar aquellos componentes que interactuan con el sistema observando a este como un solo bloque.

* Actor Usuario: este actor juega el papel de Usuario del LEDI e interactua con los casos de uso Modelado de Problema de Optimizacion y obtener los valores de las variables de decision. Donde el primero, se enfoca en la construccion de los componentes de la arquitectura que le permitiran al actor utilizar la infraestructura que soporta el modelo de dominio del LEDI; y el segundo caso que ha sido disenado para ejecutar todos aquellas operaciones que implican la resolucion del modelado de la funcion a optimizar, entre estas la conexion entre el algoritmo de resolucion de problemas de optimizacion creado en C y el propio LED implementado en Ruby.

* Actor Sistema de Interpretacion Grafica de Resultados: aunque este actor no tiene presencia obvia en la presente investigacion, se ha tomado la decision en incluirlo en el modelo puesto que, tomando en consideracion trabajos futuros, es importante contar con un sistema que permita visualizar los resultados obtenidos de forma grafica. Esta consideracion se vera reflejada en la arquitectura, como se observara mas adelante.

[FIGURA 3 OMITIR]

Continuando con la aplicacion de la metodologia C4, la siguiente perspectiva a crear es una visualizacion del sistema por medio de lo que han sido llamados Contenedores (Containers), los cuales se representaran por medio de un Diagrama de Paquetes. Esta vista, permite descomponer el Diagrama de Contexto del Sistema en un conjunto de bloques que tendran una comunicacion entre ellos y responsabilidad individuales asignadas (Fig. 4).

* Capa DSL Model: esta capa contiene las estructuras que componen el Modelo de Dominio. Estas estructuras son representadas mediante clases, donde por medio de sus atributos y metodos, el usuario posee los elementos sintacticos provistos por el LEDI necesarios para la representacion del modelo a optimizar. Del mismo modo, esta capa posee un componente dedicado a albergar los casos de prueba que ayudan a comprobar el Modelo de Dominio y los nuevos elementos que se anadan a este.

* Capa SolverServices: esta capa permite la comunicacion entre las capas DSL Model y C Solver, las cuales estan construidas en los lenguajes de programacion Ruby y C, respectivamente. Para solventar este problema entre plataformas, se ha hecho uso de la libreria FFI (Foreign Function Interface), la cual permite hacer llamados desde Ruby a funciones implementadas en C. Por lo tanto, la capa DSL Model puede llamar las rutinas algoritmicas alojadas en la capa C Solver.

Capa C Solver: esta capa contiene los algoritmos que permiten resolver problemas de optimizacion, los cuales estan construidos en el lenguaje de programacion C, como va se ha mencionado.

[FIGURA 4 OMITIR]

Una vez obtenida la representacion de la arquitectura del sistema por medio de un Diagrama de Contenedores (Fig. 4), el siguiente paso es descomponer cada Contenedor en bloques que han sido llamados Componentes (Components). Tal como se menciona en [22] un Contenedor representa el lugar en el cual los Componentes son ejecutados. En la Fig. 5 se muestra el sistema por medio de un Diagrama de Componentes, y como cada capa representada (por su correspondiente Contenedor) esta conformada por uno o varios Componentes.

A continuacion se realiza una descripcion de los principales componentes.

* Componente DSL Model: contiene las estructuras que conforman el Modelo de Dominio, es decir, el LEDI propiamente dicho. Por lo tanto, es este Componente el que interactua directamente con el actor Usuario

* Componente Test DSL Model: dedicado a los casos de prueba y tiene como finalidad comprobar el Modelo Semantico residente en el Modelo de Dominio, de modo que cualquier modificacion o evolucion de dicho modelo sea comprobable y validada a traves de dichas pruebas o tests.

* Componente Builder: es el encargado de hacer el llamado a los metodos que yacen en el componente SolverServices (el cual esta alojado en el Contenedor del mismo nombre).

[FIGURA 5 OMITIR]

* Componente DSLException: tiene como funcion realizar las validaciones sobre los parametros que reciben los metodos que conformar el LEDI y en caso de un error originar el mensaje apropiado. Contiene la clase RestrictionException la cual hereda de Exception, esta clase es propia de Ruby y responsable de manejar todas aquellas excepciones que se produzcan. Como ejemplo, algunas de ellas son: NoMemoryError, RuntimeError, SecurityError, ZeroDivisionError, y NoMethodError [31]. Asi mismo, uno de los propositos que se buscaba con esta herencia fue la creacion de una clase disenada exclusivamente para las necesidades del LEDI.

* Componente Expression Parser: tiene como funcion analizar cada una de las expresiones matematicas (manifestadas en la funcion de optimizacion y sus restricciones) para posteriormente determinar en que categoria (Programacion Lineal o Programacion No Lineal) se encuentra el problema que se esta modelando, de esta manera el LEDI podra utilizar el algoritmo de resolucion apropiado.

* Componente DslConnection: tiene el proposito de ser el elemento que sera invocado en el archivo (con extension .rb) donde el usuario modelara su problema de optimizacion; este componente jugara el papel de ser la conexion entre dicho archivo y la arquitectura del LEDI.

Una vez descrita la arquitectura por medio de un Diagrama de Contenedores y de Componentes, se presenta a continuacion el nivel de descripcion mas detallado de la misma por medio de un Diagrama de Clases (Fig. 6). De igual forma, ya que el enfoque de implementacion escogido para la construccion del LEDI radica en la combinacion de los patrones Encadenamiento de Metodos y Cierre Anidado (Nested Closures), las caracteristicas funcionales del lenguaje yacen en la creacion de un Modelo de Dominio que por medio de la definicion de clases y el empleo de sus metodos como elementos que proveen la sintaxis del LEDI, por tanto es conveniente analizar la arquitectura desde la perspectiva de un Diagrama de Clases.

Como se puede observar en la Fig. 6, OptimizationFunction y Restriction son clases que estan asociadas por una relacion de Composicion; son estas clases las que conforman el Modelo de Dominio de la arquitectura. Se puede notar que la clase OptimizationFunction posee dos atributos que son: equation (permite almacenar la ecuacion que conforma la funcion objetivo) y subject_to_restriccition (permite almacenar en forma de objeto la serie de restricciones a las que esta sujeta la funcion a optimizar), este ultimo atributo esta relacionado con la clase Restriction, la cual posee el atributo llamado restriction_equation correspondiente a una estructura de tipo Hash destinada a almacenar las restricciones relacionadas con la funcion de optimizacion, donde la llave del arreglo Hash es el nombre de la restriccion y el valor de dicha llave es la inecuacion que expresa la restriccion.

Como se menciono anteriormente, toda la sintaxis que posee el LEDI yace en su Modelo de Dominio y es representada por los metodos que yacen en este. Sin embargo, ya que toda restriccion lleva un nombre que la identifica (Fig. 2) es dificil saber cual sera el asignado por el usuario a cada restriccion, haciendo imposible de esta forma, crear un metodo que sea residente permanente en el modelo. Esta dificultad es sorteada mediante la implementacion del modulo RestrictionBuilder, el cual ha sido disenado con el proposito de ser el encargado de construir, mediante la tecnica de Generacion Dinamica de Metodos, todas aquellas restricciones que el usuario ingrese.

Una vez dada la estructura apropiada al objeto de tipo OptimizationFunction, el cual representa el modelado del problema de optimizacion con sus respectivas restricciones, el usuario debe hacer uso del metodo send_result_to_solver, el cual permite enviar dicho objeto hacia la clase SolverConnectionBuilder, la cual es la encargada de entablar la conexion con la capa C Solver, esto se hace invocando la implementacion del metodo algorithmrequest, la cual reside en la clase ServiceSolverAdapter y se define en la clase abstracta IserviceAdapter. De este modo se inicia el proceso que implica enviar el modelo de optimizacion hacia los algoritmos de resolucion mediante el metodo send_to_adapter el cual es llamado dentro del metodo send_result_to_solver.

Del mismo modo, el componente ExpressionParser es conformado por los modulos ExpressionExtensiones y ExpressionGrammar (usado por la clase SolverConnectionBuilder), el cual utiliza el archivo de configuracion equation_grammar.treetop junto con la libreria Treetop, la cual debe ser instalada en el ambiente de desarrollo. A traves de esta libreria se logra realizar el analisis sintactico de la expresion matematica, extrayendo y separando las variables y coeficientes de la misma, logrando identificar y categorizar el tipo de ecuaciones que el usuario esta utilizando en el modelado del problema de optimizacion, esto con el fin de permitir que el LEDI pueda invocar internamente el algoritmo de resolucion apropiado para generar el resultado esperado.

[FIGURA 6 OMITIR]

Por ultimo la interfaz ISolverAlgorithm permite el desacoplamiento entre las capas SolverServices y C Solver. Al mismo tiempo, tiene como tarea acceder al componente C Solver que contiene las rutinas implementadas en C, el cual depende de la libreria FFI para lograr este fin, logrando asi la interconexion entre las dos tecnologias que conforman lactura (Ruby y C)

VII. VALIDACIONES Y PRUEBAS DE LA ARQUITECTURA

Para la validacion del LEDI se planteo un problema de optimizacion como caso practico de forma que se pudiera evaluar el comportamiento que presenta la arquitectura. En las pruebas pertinentes se plantearon escenarios tales como el paso erroneo de numero de parametros y mal uso de la sintaxis del lenguaje. El formato empleado en la realizacion de las pruebas se muestra en la Tabla. I.

Como ejemplo de una de las pruebas realizadas se muestran la Tabla II y Fig. 7.

[FIGURA 7 OMITIR]

VIII. Trabajos Futuros

Dentro los proyectos relacionados se encuentran el Modelado de una Arquitectura para la Construccion de una Herramienta la Visualizacion de Resultados Obtenidos Mediante un LEDI Orientado a la Definicion de Problemas de Optimizacion. Este proyecto presentara como resultado el modelo de una arquitectura empleando UML, enfocado en la creacion de una herramienta grafica que permita visualizar los resultados obtenidos del modelado de un problema de optimizacion, empleando el LEDI mostrado en el presente articulo.

Por otro lado, tambien se pretende que el LEDI construido pueda ser convertido en una libreria que permita ser instalada en un Entorno Integrado de Desarrollo como Eclipse.

IX. CONCLUSIONES

Durante el proceso investigativo del proyecto se pudo constatar que el campo referente a la creacion de Lenguajes Especificos de Dominio Interno ha sido explorado de diferentes formas, siendo el desarrollo web un nicho importante. En esta area se encontraron LEDI como Ruby on Rails y Rspec, el cual ha tomado fuerza en el sector de testing y pruebas de integracion.

Al inicio de la investigacion se tenia pensado que el campo de los Lenguajes Especificos de Dominio era un tema especializado y de dificil acceso, ya que usualmente, durante la formacion que se recibe como ingeniero de sistemas el ambito de los lenguajes de programacion gira alrededor de los Lenguajes de Proposito General. Sin embargo, como se ha podido constatar por medio de la revision bibliografia los Lenguajes Especificos de Dominio son utilizados y desarrollados no solo con fines investigativos sino industriales, por lo tanto valdria la pena ser incluidos dentro de los planes de curso.

UML ofrece una variedad de diagramas que permiten observar el software o una aplicacion determinada desde varias Vistas. Sin embargo, al iniciar el planteamiento de la arquitectura del LEDI, se encontro que esta diversidad de diagramas en realidad planteaba cierta desventaja puesto que no se tenia claro cual de todos seleccionar. En este punto era importante encontrar alguna metodologia que brindara un punto de referencia. Es alli donde la metodologia C4 ofrece dentro de su planteamiento una forma practica y sencilla para construir un sistema, esto permitio crear la arquitectura con un enfoque funcional e incremental, como se puede evidenciar en el documento, a medida que se fue necesitando la incorporacion de nuevos componentes que desempenaran distintas funcionalidades, estos fueron acoplados sin problema en la arquitectura.

Recibido Octubre 16 de 2015--Aceptado Mayo 30 de 2016

REFERENCIAS

[1] M. Fowler, Domain--Specific Languages. Ed. Boston: Addison Wesley. 2011.

[2] D. Flanagan and Y. Matsumoto, The Ruby Programming Language. Ed. California: O'Reilly, 2008.

[3] P. Cooper.,Beginning Ruby From Novice to Professional, ed 2nd . Ed New York: Apress, 2009.

[4] D. Ghosh, DSLs in Action. Ed. Stamford: Manning, 2010.

[5] S. Gunther, Agile DSL-Engineering with Patterns in Ruby.

[6] E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software. Ed. Addison Wesley, 2003.

[7] M. Voelter, DSL Engineering. Designing, Implementing and Using Domain-Specific Languages. [Online]. Available: http://dslbook.org.

[8] M. Mernik, "When and How to Develop Domain-Specific Languages". ACM Computing Surveys. vol 37, pp 316-344, december 2005.

[9] R. Fourer, D. M. Gay, B. W. Kernighan, AMPL: A Modeling Language for Mathematical Programming, 2da ed. 2003.

[10] IBM ILOG OPL Language User's Manual [Online]. Available: http://cedric.cnam.fr/~lamberta/MPRO/ECMA/doc/oplTutorial.pdf

[11] T. Halpin. UML Data Models From An ORM Perspective: Part 1.[Online]. Available: http://www.orm.net/pdf/ICMArticle1.pdf

[12] K. Czarnecki, "Overview of Generative Software Development", in Unconventional Programming Paradigms, 2005, pp. 326-341.

[13] J. Gartner, X. GmbH, N. Musliu, W. Schafhauser and W. Slany. A Domain Specific Language for Modeling and Solving Staff Scheduling Problems. [Online]. Available: http://www.dbai.tuwien.ac.at/staff/musliu/CischedEMPLE.pdf.

[14] A. Mediratta. "A Generic Domain Specific Language For Financial Contracts," M.S thesis, Rutgers, The State University of New Jersey, 2007.

[15] H. Beck, K. Currie and A. Tate, A Domain Description Language for Job-ShopScheduling. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.269

[16] A. van Deursen, P. Klint and J. Visser. Domain-Specific Languages: An Annotated Bibliography. [Online]. Available: http://www.st.ewi.tudelft.nl/~arie/papers/dslbib.pdf

[17] R. Fourer, Algebraic Modeling Languages for Optimization. [Online]. Available: http://ampl.com/REFS/amlopt.pdf

[18] E. Gramma, R. Helm, R. Jhonson and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Ed. Boston: Addison Wesley

[19] GarfinkeL, R.S. (1985). Motivation and Modeling, in LAWLER, E.L.; LENSTRA, J.K.; RINNOOY KAN, A.H.G.; SHMOYS, D.B. (eds.) The Traveling Salesman Problem: A Guide Tour of Combinatorial Optimization. Wiley. Chichester.

[20] J. de Lara y E. Guerra. "Domian-Specific Textual Meta-Modelling Languages form Model Driven Engineering".Modelling Foundations and Aplications. pp 316-344, July 2005.

[21] J. Rumbaugh, I. Jacobson y G. Booch. El Lenguaje Unificado de Modelado: Manual de Referencia. Ed. Madrid: Addison Wesley, 2000.

[22] S. Brown. Software Architecture for Developers. Ed. Leanpub, 2015.

[23] GAMS [Online]. Available: https://www.gams.com/

[24] Pyomo [Online]. Available: http://www.pyomo.org/

[25] ASCEND [Online]. Available: http://ascend4.org/Main_Page

[26] AIMMS [Online]. Available: http://www.aimms.com/

(1) Producto derivado del proyecto de grado de la Maestria en Ingenieria de Sistemas y Computacion, dela Universidad Tecnologica de Pereira "Creacion de una arquitectura utilizando Lenguaje de Modelado Unificado (UML), en la implementacion de un Lenguaje Especifico de Dominio Embebido (LEDE): Creacion de LED Embebido en Ruby para el modelado de problemas de optimizacion".

A. Rodas. Docente Programa de Ingenieria de Sistemas y Computacion, de la Universidad Tecnologica de Pereira, Pereira (Colombia), email: alejorodasvasquez@ utp.edu.co

J. I. Rios. Director Maestria Ingenieria de Sistemas y Computacion, de la Universidad Tecnologica de Pereira, Pereira (Colombia), email: jirios@ utp.edu.co

G. R. Solarte. Docente de Ingenieria de Sistemas y Computacion, de la Universidad Tecnologica de Pereira, Pereira (Colombia), email: roberto@ utp.edu.co

Alejandro Rodas Vasquez. Profesor catedratico Programa Ingenieria de Sistemas y Computacion--Universidad Tecnologica de Pereira. Es Ingeniero de Sistemas y Telecomunicaciones--Universidad Catolica de Pereira, MSc. en Ingenieria de Sistemas y Computacion--Universidad Tecnologica de Pereira. Sus areas de actuacion son el Desarrollo Web, Desarrollo de Sistemas Expertos, Arquitectura de Software, Ingenieria de Software y Usabilidad en Lenguajes Especificos de Dominio Interno.

Jorge Ivan Rios Patino. Profesor Titular del Programa Ing. Sistemas y Computacion--Universidad Tecnologica de Pereira. Es Ingenieria Industrial --Universidad Tecnologica de Pereira, MSc Informatica e Ingeniera del Conocimiento--Universidad Politecnica de Madrid y PhD (c) Informatica-Universidad Politecnica de Madrid. Es director de la Maestria en Ingenieria de Sistemas y Computacion de la Universidad Tecnologica de Pereira desde junio de 2009. Sus areas de actuacion son la Inteligencia Artificial, Ciencias de la Computacion y de la Informacion.

Guillermo Roberto Solarte Martinez, Profesor Asociado, Transitorio del Programa Ing. Sistemas y Computacion.

Doctor en Informatica de la Universidad Pontificia de Salamanca con sede Madrid Espana Suficiencia investigativa, D .E. A Universidad Pontificia de Salamanca con sede Madrid Espana, Magister en Investigacion de Operativa y Estadistica de la Universidad Tecnologica de Pereira Risaralda e Ingeniero de Sistemas Grupo de Investigacion En Inteligencia Artificial, Semillero de Investigacion GNTO Grupo de Nuevas tecnicas de busqueda y de optimizacion.
Tabla I

FORMATO DE CASOS DE PRUEBA

Caso practico: expresion matematica de una
funcion para optimizar.

Nombre caso de prueba: describe brevemente el
caso de prueba.

Descripcion: descripcion detallada del caso de
prueba.

Criterios: items que determinan si el caso ha sido
satisfactorio o no.

Tabla II

MAL USO DE LA SINTAXIS DEL LENGUAJE

Caso practico:

Minimizar: z = 5x1 + 4x2

Sujeto a las restricciones:

6x1 + 4x2 <= 24

-2x1 + 2x2 <= 6

Nombre caso de prueba: mal uso de la sintaxis
del lenguaje.

Descripcion: el usuario olvida parametrizar las
funciones de restriccion a las que esta sujeta la
funcion a minimizar.

Criterios: la arquitectura debe mostrar un mensaje
de error revelando que faltan las funciones
de restriccion, no estan presentes.
COPYRIGHT 2016 Universidad Catolica de Pereira
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2016 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Rodas, A.; Rios, J.I.; Solarte, G.R.
Publication:Entre Ciencia e Ingenieria
Date:Dec 1, 2016
Words:5838
Previous Article:Una concepcion institucional sobre la derivada en la universidad tecnologica de Pereira, en el curso de matematicas I.
Next Article:Sistema multi-agente deliberativo para la obtencion y analisis de datos en Honeynets.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters