Revista de Investigación ALGHORITMIC

Transcripción

1 Revista Alghoritmic ISSN Pag 1 º Vol. 1 N 1 ISSN versión impresa Lima-Perú 2010 UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS Decana de América Facultad de Ingeniería de Sistemas e Informática INSTITUTO DE INVESTIGACION Revista de Investigación ALGHORITMIC Revista Alghoritmic ISSN Pag 1

2 Revista Alghoritmic ISSN Pag 2 Presentación El Instituto de Investigaciones de la Facultad de Ingeniería de Sistemas e Informática de la Universidad Nacional Mayor de San Marcos, Lima Perú, tiene como actividad principal la investigación científica en las áreas de Ingeniería de Sistemas, Ingeniería de software, Computación e Informática. El Instituto pretende ser un medio para difundir e integrar las disciplinas de las tecnologías de la información en el debate académico de nuestro tiempo. La Revista Alghoritmic es una publicación científica editada por el Instituto de Investigaciones de Ingeniería de sistemas e Informática, tiene una periodicidad semestral, se publica tanto en su versión impresa como digital; recibe artículos originales e inéditos en los temas de relacionados con el campo de la Ingeniería de Sistemas, Ingeniería de Software, Ciencias de la Computación e Informática. El propósito principal es contribuir al esfuerzo que despliega la Facultad de Ingeniería de Sistemas. Para ello, el Instituto aspira a recoger las múltiples perspectivas teóricas y empíricas del conocimiento científico y difundirlas en la Revista Alghoritmic. El Comité editorial de la Revista Alghoritmic, expresa su satisfacción y agradecimiento a cada uno de los responsables de los artículos, quienes muestran algunos resultados de los trabajos de investigación que vienen desarrollando en nuestra facultad. Agradecemos al Vicerrectorado de Investigación, al Consejo Superior de Investigaciones, y a la Facultad de Ingeniería de Sistemas por el apoyo económico y financiero para la publicación de la revista, así como a los docentes e investigadores, quienes conjugando docencia e investigación comprenden a cabalidad la labor de una Facultad que forme profesionales de calidad, aportando sus conocimientos y experiencia volcados en sendos textos que presentamos en las siguientes paginas. Podemos apreciar que existe un esfuerzo importante por parte de los propios docentes de la Facultad y de la Universidad por aportar en la generación de nuevas ideas y conocimientos que enriquezcan nuestro amor por la investigación, y que generen a su vez nuevos conocimientos, integrándolos a sus procesos formativos, que puedan ser transmitidos a los alumnos y ex alumnos de nuestra querida Alma Mater. Editor Responsable 2

3 Revista Alghoritmic ISSN Pag 3 Universidad Nacional Mayor De San Marcos Facultad de Ingeniería de Sistemas e Informática Instituto de Investigación de Ingeniería de Sistemas e Informática Rector Vicerrector Académico Vicerrector de Investigación Consejo Superior de Investigaciones Dr. Luis Izquierdo Vásquez Dr. Victor Peña Rodriguez Dra. Aurora Marrou Roldán Dr. Armando Yarleque Chocas Facultad de Ingeniería de Sistemas e Informática Decano Mg.Carlos Navarro Depaz Instituto de Investigación de Ingeniería de Sistemas e Informática Director Comité Editorial Mg. Augusto Cortez Vásquez Mg. Augusto Cortez Vásquez Editor responsable Dr Renato Benazic Tome La revista Alghoritmic cuenta con el auspicio de la Facultad de Ingeniería de Sistemas Informática, el Vicerrectorado de Investigación y el Consejo Superior de Investigaciones Instituto de Investigaciones Facultad de Ingeniería de Sistemas e Informática Pabellón de la Facultad de Ingeniería de Sistemas e Informática Ciudad Universitaria. Av. Venezuela cuadra 34 Lima 1 Perú Revista de Investigación Alghoritmic Vol. 1 N ISSN versión impresa Lima-Perú E mail: inst.investigaciones.fisi@gmail.com Home Page Telefono Carátula Facultad de Ingeniería de Sistemas e Informática UNMSM Lima Perú Los puntos de vista expresados por los autores son de estricta responsabilidad de ellos y no necesariamente reflejan la opinión del Editor ni del Comité Editorial; por lo tanto, no se asume responsabilidad por el contenido de cada artículo. 3

4 Revista Alghoritmic ISSN Pag 4 Revista de Investigación Alghoritmic Vol. 1 N 1 ISSN Agosto- Diciembre 2010 Lima-Perú INDICE Presentación 1. Ingeniería dirigida por Modelos 7 Espinoza Robles Armando David,Trujillo Trejo John Ledgard, 2. Modelamiento matemático de un servidor de correo electrónico 21 Félix Armando Fermín Pérez 3. Sistemas de Razonamiento basado en Reglas para determinar recomendación 28 de cirugía refractiva Augusto Cortez Vasquez, Virginia Vera Pomalaza 4. Sistema de Multiagentes para Implementación de Sistema Generación de 37 Horarios Gilberto Salinas Azaña 5. Servicios web utilizando ASP 45 Santiago Moquillaza Henríquez, Percy de la Cruz Velez de Villa, Hugo Vega Huerta 6. Base de datos distribuidos usando algoritmos genéticos para optimización de 56 proceso de transacción en la web Luzmila Pró Concepción Programas y Líneas de Investigación 76 Instructivos para la presentación de artículos 77 4

5 Revista Alghoritmic ISSN Pag 5 Revista de Investigación Alghoritmic Vol. 1 N 1 January - July 2010 ISSN Electronic version Lima-Perú INDEX Presentation ISSN versión impresa 1. Model Driven Engineering 7 Espinoza Robles Armando David,Trujillo Trejo John Ledgard, 2. Mathematical modeling of a mail server 21 Félix Armando Fermín Pérez 3. Rules-based reasoning systems for refractive surgery is recommended 28 Augusto Cortez Vasquez, Virginia Vera Pomalaza 4. Multiagent System for Generating System Implementation Schedule 37 Gilberto Salinas Azaña 5. Web services using ASP 45 Santiago Moquillaza Henríquez, Percy de la Cruz Velez de Villa, Hugo Vega Huerta, 6. Distributed database optimization using genetic algorithms for transaction 56 processing on the web Luzmila Pró Concepción Instructions for submission of articles 77 5

6 Revista Alghoritmic ISSN Pag 6 Ingeniería dirigida por Modelos Model Driven Engineering Espinoza Robles Armando David,Trujillo Trejo John Ledgard, Universidad Nacional Mayor de San Marcos Facultad de Ingenieria de Sistemas e Informatica davidespinozarobles@yahoo.com.mx, jtrujillot@unmsm.edu.pe, RESUMEN La Ingeniería dirigida por modelos(idm), un nuevo paradigma en el proceso de desarrollo de software, viene ganando terreno en el ambiente del desarrollo de software, por los que se hace necesario tener claridad sobre sus conceptos fundamentales, tal como poner como centro del proceso de desarrollo de software a los modelos, la necesidad de tener un lenguaje de dominio especifico para modelar los dominios, producir con esto modelos productivos, que puedan ser transformados en diversos artefactos, y que el mantenimiento de estos artefactos no produzcan el desfase de los modelos. Palabras claves Modelo, Meta Modelo, Dominio Especifico, Lenguaje de domino especifico, Transformación. ABSTRACT The Engineering headed by models(wdr), a new paradigm in the process of development of software, Is gaining ground in the environment of software development, which makes necessary to have clarity on their fundamental concepts, such as put as a center of the process of development of software to the models, The need to take a language of domain specific to shape the domains, produce with this production patterns, which can be processed into various artifacts, and that the maintenance of these devices do not produce the gap of the models. Key Words Model, Meta Model, Domain Specific Language of domino specific, processing. 6

7 Revista Alghoritmic ISSN Pag 7 1 INTRODUCCION La mayoría del Software en la actualidad aun se sigue desarrollando de manera artesanal. Aun es poco la cantidad de software que se realiza siguiendo un modelo específico. Los modelos recorren todo el ciclo de vida del software, sin embargo en la mayoría de los casos, los modelos solo sirven para un propósito específico, después de cual quedan obsoletos. Una vez elaborado el código de un Sistema Informático, este código es sometido a un proceso de mantenimiento continuo. Los modelos que sirvieron en las distintas fases del ciclo de vida del software, para la elaboración del Sistema, quedan obsoletos y ya no reflejan la realidad cambiante del Software. UML es de interés en todo el mundo y se ha tomado como un estándar de hecho para la realización de modelos por lo que se vincula a un modelo con un diagrama UML, el cual sirve para esbozar una parte del software. Una vez generado el código estos modelos pasan al olvido. La Ingeniería Dirigida por Modelos (IDM) se plantea poner en el corazón del proceso de la elaboración del software a los Modelo. Esto supone manejar los Modelos de una manera informática, es decir los modelos deben estar rigurosamente definidos, para poder realizar la transformación de estos modelos. IDM parte de considerar que el Software no es solo el código, por lo que plantea que los modelos siempre deben reflejar la situación actual del software, por lo que cualquier actualización del código debe también reflejarse en la actualización de los modelos. MDA (Model Driven Architecture) es una propuesta de la OMG, es una implementación posible de IDM, pero el MDA tiene limitaciones como estar basado en UML y MOF ((Facilidad de Meta Objeto) y los estándares de OMG. IDM pretende sobrepasar los marcos del MDA Durante años existió una relativa estabilidad de los sistemas, en la actualidad ya no es así, por razones económicas y comerciales los sistemas evolucionan rápidamente y cuando esto sucede el impacto sobre el software es cada vez mas importante. En la actualidad los sistemas son cada vez más complejos, esta complejidad de los sistemas se trata de modelizar usando un solo lenguaje estándar, el UML, por ser este un consenso de facto, pero es bastante difícil que este lenguaje puede servir para modelizar toda la complejidad del software. En muchas casos para las especificación de un sistema se recurre al lenguaje natural el cual es de por si ambiguo y tiene una falta de precisión. Para expresar un buen nivel de abstracción se debe recurrir a lenguajes más formales que nos ayuden a describir los diversos modelos en el ciclo de vida del desarrollo del software, como Lenguaje de descripción de Arquitectura (ADL), Lenguajes de Dominio específico (DSL) La IDM al poner los modelos como el centro del desarrollo de Sistemas de Información, se plantea el problema de encontrar lenguajes de modelización que tengan la suficiente semántica para expresar de manera formal niveles altos de abstracción en cada etapa del proceso del Ciclo de vida del desarrollo de un Sistema de Información. Es de suma importancia para los Analistas de Sistemas, poder elaborar modelos bien definidos, para los cual deben contar con lenguajes de modelización formales que les permita realizar un alto nivel de abstracción Para lo cual se debe utilizar Lenguajes de domino específicos para realizar Modelos de Dominio Especifico, que permita un alto nivel de abstracción y modelos productivos bien definidos. En lugar de usar un modelo general como el UML. 7

8 Revista Alghoritmic ISSN Pag 8 2 REVISION GENERAL IDM es un reciente paradigma donde el código no es considerado el centro del software. El código es un elemento, un modelo producido por la fusión del modelamiento de diferentes elementos. Minsky M. define que "Para un observador B, un objeto M* es un modelo de un objeto M en la medida en que B puede utilizar M* para responder a las preguntas que le interesen acerca de M. Esta definición muestra que un modelo es un objeto destinado a representar un particular comportamiento, dependiendo de un particular contexto. En el contexto del IDM, modelos interesantes son aquellos que pueden ser formalizados para hacerlos productivos. Algunos autores integran esta limitación en la definición de modelo: Un modelo es una descripción de (parte de) un sistema descrito en un bien definido lenguaje. En IDM, cada lenguaje es descrito por un meta modelo. Un Meta Modelo es una modelo de especificación que define el lenguaje para expresar un modelo. De esta manera un meta modelo permite a los diseñadores especificar su propio lenguaje de dominio especifico. Modelos y Meta Modelos son los principales conceptos de IDM Ingeniería Dirigida Por Modelos IDM El Enfoque de la Ingeniería Dirigida por Modelos (IDM) ha sido propuesto en el dominio de la ingeniería de software con el fin de proveer técnicas y herramientas para tratar con los modelos de una forma automática. El punto de vista de IDM esta basado en modelos, meta modelos, transformación de modelos y tejido de modelos y apuntan a producir modelos productivos por ejemplo modelos concentrados e su poder generativo. Considerando esos dos dominios y la interacción hombre maquina en IDM, la meta es entender las necesidades de diseño de la interacción hombre maquina (HCI) para estudiar como las herramientas IDM pueden soportar las necesidades de HCI. El propósito del estudio de las herramientas IDM en consideración a la gestión del modelo HCI El objetivo de la gestión de los modelos es proveer técnicas y herramientas para relacionar los modelos de una forma más automática. Ello ha estado siendo estudiado por años por varias comunidades de investigadores, en el contexto de bases de datos, gestión de documentos e ingeniería de software. En estos días un enfoque federativo emerge: Ingeniería Dirigida por Modelos IDM. En los orígenes del movimiento, el Grupo de Gestión de Objetos propuso la Arquitectura dirigida por modelos paran tecnologías orientadas a objetos. Pero esta dependía de una tecnología y la ausencia de claridad en la definición de los conceptos llevo a un punto de vista más general, IDM. En IDM, cualquier tipo de modelo puede ser tomado dentro de una versión. Así IDM esta difundiéndose rápidamente, en particular en el dominio HCI como puede ser visto por el recurrente taller Model Driven Development of Advanced User Interfaces una de las mayores conferencias acerca de IDM [3] En las cinco décadas pasadas, los investigadores de software y los desarrolladores han estado creando abstracciones que los ayudan a programar en términos de sus de diseños propuestos, envés de en términos del ambiente de computación subyacente por ejemplo, CPU, Memoria, y aparatos de red- y escudarlos de las complejidades de estos ambientes de computación. Desde los primeros días de la computación, estas abstracciones incluían lenguajes y tecnologías de plataforma. Por ejemplo, los primeros lenguajes de programación, como Assembler y Fortran, escudaban a los desarrolladores de las complejidades de la programación con código de maquina. De la misma forma, las primera plataformas de sistemas operativos, como OS/360 y Unix, escudaban a los desarrolladores de las complejidades de programar directamente en hardware. 8

9 Revista Alghoritmic ISSN Pag 9 Aunque estos primeros lenguajes y plataformas elevaron el nivel de abstracción, aun tenían un claro enfoque Orientado a la computación. En particular, ellos proveían abstracciones del espacio de solución esto es, el dominio de tecnologías de computación- envés de las abstracciones del espacio del problema que expresan diseños en términos de conceptos en dominios de la aplicación, como por ejemplo telecomunicaciones, cuidado de la salud, y biología Ingeniería de Software Apoyada por Computadoras Un esfuerzo muy importante que comenzó en los 80s fue la Ingeniería de Software apoyada por computadoras (CASE), el cual se enfocaba en desarrollar métodos de software y herramientas que permitiera a los desarrolladores expresar sus diseños en términos de representaciones graficas de programación de propósito general, como maquinas de estado, diagramas de estructura, y diagramas de flujo de datos. Una meta del CASE fue permitir un análisis mas exhaustivo de programa gráficos que acarrean menos complejidad que los lenguajes convencionales de propósito general; por ejemplo, mediante el evitamiento de corrupciones y fugas asociados con lenguajes como C. Otra meta fue sintetizar artefactos de implementación desde representaciones graficas para reducir el esfuerzo de la codificación manual, corrección de errores y transporte de programas. [2] Aunque CASE atrajo considerable atención en la literatura de investigación, no fue adoptada ampliamente en la práctica. Un problema que enfrento fue que las representaciones del lenguaje grafico de propósito general para escribir programas en herramientas CASE se mapeaban pobremente sobre las plataformas subyacentes, las cuales eran en su mayoría sistemas operativos de un solo nodo como DOS OS/2 o Windowsque no tienen el soporte para propiedades importantes de calidad de servicio (QoS), como son la distribución transparente, tolerancia de fallos y seguridad Otro problema con CASE fue su inhabilidad para escalar con el propósito de manejar sistemas complejos y ha escala productiva en un amplio rango de dominios de aplicación. En general, las herramientas CASE no soportaban la ingeniería concurrente, así que se limitaron a programas escritos por una solo persona o por un equipo que se serializaba sus accesos a archivos usados por esta herramientas. Las herramientas CASE apuntaron a ambientes de ejecución propietario, lo cual hizo difícil integrar el código que ellos generaban con otro lenguaje de software y tecnologías de plataforma. Como resultado, CASE tubo un impacto relativamente pequeño en el desarrollo del software comercial durante los 80s y 90s. Plataforma Actual y Limitaciones del Lenguaje Avances en lenguajes y plataformas en las dos décadas pasadas han aumentado el nivel de abstracciones de software, disponibles para los desarrolladores, y por lo tanto aliviando un impedimento a los primeros esfuerzos CASE. Por ejemplo, los desarrolladores hoy usan típicamente lenguajes orientados a objetos mas expresivos, como C++, Java, C#, envés de Fortran o C. de la misma forma las librerías de clases reutilizables de hoy en día y las plataformas de entorno de aplicación minimizan la necesidad de reinventar servicios de Middelware común y de dominio especifico, como las transacciones, descubrimiento, tolerancia de fallos, notificación de eventos, seguridad y manejo de recursos distribuidos. Debido a la maduración de lenguajes de tercera generación y plataformas reutilizables, los desarrolladores de software están ahora mejor equipados para escudarse de las complejidades asociadas con la creación de aplicaciones usando tecnologías pasadas. 9

10 Revista Alghoritmic ISSN Pag 10 A pesar de estos avances, algunos problemas irritantes se mantienen. En el corazón de estos problemas esta el crecimiento de complejidad de plataformas, el cual ha evolucionado mas rápido que la habilidad de los lenguajes de propósito general para enmascararla. Un problema relacionado es que la mayoría de código de aplicación y plataforma todavía es escrito y mantenido manualmente usando lenguajes de tercera generación lo cual conlleva excesivo tiempo y trabajo, particularmente para actividades claves relacionadas a la integración, como son el despliegue del sistema, configuración y aseguramiento de la calidad. Incluso usando nuevas notaciones, como los descriptores de despliegue basados en XML los cuales son populares con plataformas de componentes y plataformas de Middleware de arquitectura orientada a objetos, esta muy cargado de complejidad. Mucha de esta complejidad surge de la separación semántica entre el propósito de diseño por ejemplo, desplegar componentes 1-50 sobre los nodos A-G y los componentes sobre los nodos H-N en concordancia con los requerimientos de recursos de sistema y disponibilidad - y la expresión de este propósito en miles de líneas de XML codificado a mano cuya sintaxis visualmente densa no expresa ni la semántica de dominio ni el propósito de diseño. [2] Un enfoque promisorio para solucionar la complejidad de plataforma y la inhabilidad de los lenguajes de tercera generación de aliviar esta complejidad y expresar conceptos de dominio de manera efectiva es desarrollar las tecnologías de la ingeniería dirigida por modelos que combina lo siguiente: Lenguajes de Modelamiento de Dominio Específico (DSMLs) cuyo tipo de sistema formaliza la estructura de la aplicación, el comportamiento y los requerimientos dentro de un particular dominio, tal como servicios financieros en línea, gestión de almacenes, o incluso dominio de plataforma Middleware. Los DSMLs son descritos usando metamodelos, que definen las relaciones entre los conceptos en un dominio y especifican precisamente la clave semántica y las restricciones asociadas con esos conceptos del dominio. Los desarrolladores usan DSMLs para construir aplicaciones usando elementos tipo del sistema capturado por el metamodelo y expresar la intención de diseño declarativa y no imperativa. Motores de transformación y Generadores que analiza ciertos aspectos de los modelos y entonces sintetiza varios tipos de artefactos, tales como código fuente, inputs de simulación, descripciones de despliegue XML, o representación de modelos alternativos. La habilidad para sintetizar artefactos desde modelos ayuda a asegurar la consistencia entre la implementación de la aplicación y el análisis de la información asociada con requerimientos funcionales y QoS, capturados por los modelos En la actualidad el esfuerzo de investigación en las herramientas IDM están enfocadas en varios asuntos, uno de ellos es la necesidad de crear lenguajes que ayuden a reducir la complejidad del desarrollo y uso de las modernas plataformas. Existen muchos DSMLs que simplifican y automatizan las actividades relacionadas con el desarrollo, optimación, despliegue, y verificación de componentes distribuidos en tiempo real y sistemas empotrados. Otro asunto son los IDM Framework que usan tipos extendidos de sistemas para capturar software basado en componentes, arquitectura de línea de productos y organizar esas arquitecturas en una jerarquía para transformar modelos independientes de la plataforma (PIM) a modelos de plataforma especifica (PSM) Como las herramientas IDM atraviesan la brecha de los primeros adoptantes de desarrollo de software, una clave del reto es definir estándares útiles que habiliten herramientas y modelos para trabajar juntos portabilidad y eficacia. Para eso se evalúa los pros y contra de 10

11 Revista Alghoritmic ISSN Pag 11 UML 2.0 en términos del soporte a IDM. Un ejemplo sobre estandarización es el open Tools Integration Framework, un metamodelo basado en un enfoque para herramientas de integración IDM que define componentes de arquitectura y protocolos de interacción para la formación de cadena de herramientas de diseño integradas. Otro estándar, tal como Query/Views/Transformation y el MetaObject Facility empiezan a definirse como parte del estándar OMG para la Arquitectura Dirigida por Modelos basado en UML, puede también ser útil como la base para herramientas IDM de dominio especifico Los estándares, por si solo, sin embargo son insuficientes sin una sólida infraestructura de soporte para el desarrollo y evolución de las herramientas de IDM. Por lo cual existen varias herramientas IDM, tales como Eclipse de IBM, y el Generic Modeling Environment del Institute for Software Integrate Systems. Muchas herramientas emergentes de IDM que verán la luz en futuro son el Eclipse Graphical Modeling Framework, el DSL Toolkit en Visual Studio Team System de Microsoft, y openarqchitectureware disponible de SourceForge. Lenguajes de Dominio Específico La industria del software tiene un gran problema cuando trata de construir Sistemas de Software grandes y complejos, con menos tiempo y menos dinero. Con C++ y Java fallando para aumentar significativamente la productividad de los desarrolladores, no es una sorpresa que alrededor del 40% de los desarrolladores están ya usando o están planeando usar un enfoque de generación de código para atacar este problema [5] Hay ahora muchos casos de estudio de la aplicación satisfactoria de las herramientas y tecnologías de generación de código y es esta visión la que permite a los desarrolladores levantar el nivel de abstracción por sobre los lenguajes de programación de propósito general es la mejor apuesta para organizaciones de desarrolladores que desean direccionar los problemas de productividad mencionados arriba Los generadores de software están entre los métodos más efectivos para lograr la reutilización de software. Los generadores reducen el costo de mantenimiento, producen software más evolutivo, y proveen aumentos significativos en la productividad del software. Desde un punto de vista técnico, los generadores son compiladores para lenguajes de dominio específico (DSLs) o lenguajes de programación de propósito general con extensiones específicas de dominio [1] Implementar un lenguaje de dominio especifico como una extensión de un lenguaje de programación existente (llamado host language = lenguaje huésped ) tiene diferentes ventajas. Primero, podemos tomar ventaja de la funcionalidad existente y no tenemos que reimplementar, constructores de lenguaje comunes. Segundo, las extensiones mismas solo necesitan ser transformadas hasta el punto en que puedan ser expresadas en el host language. Tercero, la infraestructura existente (ej: ambientes de desarrollo y debugging) pueden ser reutilizados. Todos estos factores resultan en menores costos de implementación para desarrolladores de programas y menores costos de transición y educación para los usuarios. Tabal 1. Relación de algunos lenguajes de dominio especifico usados ampliamente DSL Dominio de aplicación BNF Especificación de sintaxis Excel macro languages Spreadsheets 11

12 Revista Alghoritmic ISSN Pag 12 HTML LATEX Make SQL VHDL Hypertext web pages Typesetting Construcción de Software Consultas a Base de datos Diseño de Hardware Si vamos a darle facilidades a un experto del dominio para resolver problemas usando modelos, es muy importante que los lenguajes de modelamiento representen claramente los problemas del dominio. Por lenguajes de modelamiento se entiende la definición de símbolos y relaciones que son usadas para construir modelos de algún problema del dominio. [10] Algunos podarían decir que un correcto punto de vista es definir un lenguaje de modelamiento de propósito general, y usarlo en todos los dominios enseñando a los expertos del dominio como usar el lenguaje de propósito general. La experiencia con UML nos dice que esto no es frecuentemente exitoso. Llamamos lenguajes de modelamiento a los que están cuidadosamente diseñados para facilitar el modelamiento dentro de particular problema del dominio. Un Lenguaje de Dominio Específico puede ser creado para numerosos problemas de dominio. [10] Tabla 2: algunos sistemas de desarrollo de lenguajes y kits de herramientas que han sido usadas para desarrollar DSL [7] Sistema Desarrollado en ASF + SDF CWI/ Universidad de Amsterdam AsmL Microsoft Research, Redmond Draco Universidad de California, Irvine Eli Universidad de Colorado, Universidad de Paderborn, Macquarie University Gem-Mex Universidad de L Aquila Info Wiz Bell Labs / AT&T Labs JTS Universidad de Texas at Austin Khepera Universidad de North California Kodiyak Universidad de Minnesota LaCon Universidad de Paderborn (LaCon usa Eli como backend) LISA Universidad de Maribor Metafront Universidad de Aarhus Metatool Bell Labs POPART USC/Information Sciences Institute Smgn Intel compiler Lab / 12

13 Revista Alghoritmic ISSN Pag 13 SPARK Spring Stratego TXL Universidad de Victoria Universidad de Calgary LaBRI/INRIA Universidad de Utrecht Universidad de Toronto/Queen s University al Kingston el Lenguaje de Modelamiento Unificado UML UML es un lenguaje de modelamiento de propósito general. Su desarrollo empezó en 1990 cuando surge como un enfoque de unificación de diagramas para el desarrollo de sistemas orientado a objetos propuesto por Booch, Rumbaug y Jacobson. Desde entones ha tenido una serie de revisiones, la mas reciente el desarrollo de la versión 2. Generación de Código en UML originalmente significaba un muy bajo nivel de generación convirtiendo clases sobre un diagrama en una clase en C o Java. La experiencia ha demostrado que este nivel de modelamiento no entrega ningún beneficio en el negocio cuando es aplicado al sistema completo. Sin embargo, usando mas especializados o elementos de modelamiento mas abstractos, es posible aumentar el monto de la generación. [1] Otra cuestión es el bajo nivel de UML y la liviandad (o generalidad) de su semántica: una crítica común es que UML es grande y vago para ser efectivo. Esto presume que la única posible generación de código es la generación de código de muy bajo nivel descrito fácilmente la suposición es que UML no puede expresar un mas abstracto o especializado concepto. Pero esta crítica ignora los rasgos del perfil de UML. Contiene un conjunto grande de conceptos de modelamiento que son relacionadas de forma compleja. En defensa del tamaño y la complejidad de UML 2.0, sus arquitectos señalan que el lenguaje esta orientado a soportar el modelamiento de una variedad de dominios. [7] Para hacer frente ha esta complejidad, los diseñadores organizaron el estándar en cuatro partes: Infraestructura define las clases base que proveen los fundamentos para la construcción del modelamiento UML. Superestructura define los conceptos que los desarrolladores usan para construir modelos UML. Objeto de restricción de lenguaje define el lenguaje usado para la especificación de solicitudes, invariantes, especificación de operaciones, en los modelos UML. Intercambio de diagramas define una extensión para el metamodelo UML que soporta almacenamiento e intercambio de información pertinente para las capas de os modelos UML. Jakarta Tool Suite JTS. El Jakarta Tool Suite (JTS) apunta a proveer esta infraestructura en común: es un conjunto de herramientas independientes de dominio para extender los lenguajes de programación industrial con constructores específicos de dominio. El JTS esta diseñado específicamente para crear DSLs y generadores GenVoca. El JTS consiste de dos herramientas: Jak y Bali. El lenguaje Jak es un superconjunto extensible de Java que soporta meta-programación (esto es, características que permiten a los programas de Java, escribir otros programas de Java). Bali es una herramienta para la composición de gramáticas. JTS es en si mismo un generado GenVoca. Los lenguajes y extensiones de lenguaje están encapsulados como componentes reutilizables. Un componente JTS en un archivo de gramática Bali 13

14 Revista Alghoritmic ISSN Pag 14 (que define la sintaxis de de un lenguaje o extensión) y un conjunto de archivos Jak (que definen la semántica de la extensión como transformaciones sintácticas) [2]. El Lenguaje Jak Jak es un superconjunto de Java abierto y extensible. Extiende Java con un soporte para metaprogramación. (Es decir, características que permiten a programas de java escribir otros programas de java). Jak tiene dos características claves -que son, constructores AST y Generation Scoping - que los distinguen de Java. Ambos han sido implementados como componentes JTS y son ejemplo de los tipos de extensiones de lenguaje que el JTS es capaz de expresar En la Tabla 3 se muestra algunos Lenguajes de domino especifico y el dominio de su aplicación. SOFTWARE EXISTENTES EN IDM Diversidad de Herramientas En el nivel Commercial y de investigación, muchas herramientas para IDM estas disponibles o en desarrollo. Esas herramientas son designadas como frameworks o como plug-in. Muchas clasificaciones y comparación de herramientas fueron propuestas. Sin embargo, ninguna clasificación estima el criterio funcional que describimos con relación a las necesidades, en particular en términos de modelos específicos usados en dominios HCI [3]. En la tabla 4, se muestra herramientas IDM enfocados en el dominio de la interrelación hombre computadora (HCI) 14

15 Revista Alghoritmic ISSN Pag 15 Tabla 3: Ejemplos de DSL desarrollados usando los sistemas de la Tabla 2 [7] Sistema Usado DSL Dominio de la Aplicación ASF+SDF Box Risla Prettyprinting Producto Asml Eli UPnP XLANG Maptool (Various) Financiero Protocolos de dispositivos de Red Protocolos de Negocios Mapeo de Gramáticas Generación de clases Gem-Mex Cubix Virtual data warehousing JTS Jak Transformación Sintácticas LaCon (Various) Transformación de modelos de datos LISA SODL Aplicaciones de Red Smg SPARK Sprint Stratego Hoof IMDL Guide CML2 GAL PLAN-P Autobundle CodeBoost Especificaciones de compilador IR Reingeniería de software Programación en la Web Configuración de sistema Drivers de dispositivos de Video Protocolos de aplicación especifica Construcción de Software Optimización de C++ en un dominio especifico 15

16 Revista Alghoritmic ISSN Pag 16 3 Herramientas en términos de Meta Modelos y expresión de Modelos. En lo que se refiere a modelos y meta modelos, la comunidad HCI necesita herramientas que no solo consideren los modelos UML, Sino también modelo específicos. Ya que nuestra lista de herramientas esta limitada ha este tipo de herramientas, cualquier herramienta en la lista puede ser adecuada para HCI en términos de soporte de modelos y meta modelos, sin embargo, para refinar nuestra comparación, introducimos un criterio acera de la forma de expresar modelos y meta modelos: los modelo y meta modelos pueden ser expresados ya sea textualmente o gráficamente. También notamos si algunas restricción se puede añadir par completar modelos y meta modelos. Las restricciones están escritas en OCL, el lenguaje de restricciones de UML, ver Tabla 5 Tabla 4: Herramientas IDM enfocados al dominio HCI [3] Herramienta Ver Descripción ACCELEO GLP Open Source AndroMDA Open source ADT Open source AToM3 Open source DSL Tools (Visual Studio 2005 SDK) Kermeta Eclipse and EMF template-based System for MDA generation. 3.2 An extensible generator framework. Models from UML tools will be transformed into deployable components for your favorite Platform (J2EE, Spring,.NET). 2.0 ATL Development Tools are a suite of Eclipse plugging including an ATL Engine (compiler and virtual machine) as well as an IDE. 2.2 A Tool for Multi-formalism and Meta-Modelling supporting modelling of complex systems. 4.0 DSL Tools enable the construction of custom graphical designers and the generation of source code using domain-specific diagrammatic notations in Visual Studio A metamodeling language which allows describing both the structure and the behaviour of models A tool that provides a framework For building application. ModFact GPL-Open source Merlin A software modelling tool based on model transformation and code Open source generation MDA Workbench 3.0 The MDA Workbench is a MDA tool implemented as an Eclipse plugin Open source based on modelling and code generation. MOFLON A meta modelling framework built as plug-in for the graph Open source transformation tool Fujaba. OptimalJ 3.0 Generator of J2EE applications using patterns to translate business Professional models into working applications. Edition QVT Partners 0.1 Tools based on QVT for transformation models to models and code BSD like license generator. SmartQVT A model transformation tool based on QVT-Operational language. Open source UMLX An experimental concrete syntax for a transformation language. Open source Tabla 5. Herramientas IDM en función de meta modelos y expresión de modelos [3]. 16

17 Revista Alghoritmic ISSN Pag 17 4 Herramientas en términos de Transformación de Modelos. Las necesidades de HCI en términos de operaciones sobre modelos no están limitas a transformaciones, la Tabla 6 muestra todas las manipulaciones de modelo propuestas por la herramientas y muestra que solo ADT provee alguna de la infraestructura para la creación manual de modelos Weaving (Tejido de Modelos ), lo cual es una ventaja sobre otras herramientas. En la Tabla 6 la palabra texto es usada cuando el resultado de una transformación es textual que puede ser un código escrito en un lenguaje de programación (Java, C++, C, Fortran etc) que pueden ser compilados o interpretados. El termino de XMI es usado cuando el resultado de una transformación es un modelo de la forma XMI (XML meta data interchange), el cual puede ser cargado en muchas herramientas de diseño. Aquí también ATL y UMLX tienen una ventaja ya que proveen el XMI y el formato textual Considerando las operaciones de modelo dos herramientas son buenas candidatas para el dominio HCI: ATL que es la solución para trabajos en el espíritu SE (Software Engineering) y UMLX que es mas adaptada para trabajos con tecnologías WEB. Herramientas en términos de otras Operaciones Es muy importante saber la capacidad de una herramienta para ínter operar con otras herramientas. El formato es importante para el intercambio de modelos y meta modelos y reducir la separación con el dominio de SE (Software Engineering). Una gran parte de las herramientas están centradas en la especificación MOF. Así que pueden cubrir las necesidades de modelamiento de diferentes dominios y especialmente de HCI. Muchos formatos implementados han sido propuestos para el MOF: ECore, MDR (Meta Data Repository), KM3 (Kernel Meta Meta Model), DSL (Domain specific languages) y CWM (Common Warehouse Metal model). Sin embargo, el DSL no se ajusta a la implementación de MOF. Fue por eso que se creo el KM3: que es un lenguaje especializado para especificar meta modelos y es usado como un puente entre el MOF y el DSL. El formato mas usado es ECore, el cual es una versión simplificada del MOF. En la Tabla 7 se muestra una lista de herramientas en términos de otras operaciones. 17

18 Revista Alghoritmic ISSN Pag 18 En lo que se refiere a transformación de modelos el XMI es propuesto para transformaciones pero no es tan ampliamente usado. En realidad, muchas otras herramientas prefieren transformaciones textuales, en particular para herramientas QVT. En términos de interoperabilidad, Eclipse propone métodos de facto para el, almacenamiento y la recuperación de modelos basados en XMI. Así que la gran mayoría de herramientas IDM esta basada en Eclipse y pueden interoperar con otras herramientas Eclipse Tabla 6: Herramientas IDM en términos de transformación de Modelos y Weaving [4] 18

19 Revista Alghoritmic ISSN Pag 19 Tabla 7 herramientas IDM en términos de otras operaciones.[3] Herramienta Repositorio Interoperabilidad Metamodelo Modelo transformac Restricci ón ión ACCELEO DSL,MDR, - XMI Eclipse,Netbeans ECORE AndroMDA MOF, DSL - XMI Eclipse ADT DSL,KM3,M Text (ATL) XMI Eclipse, Netbeans DR, ECORE AToM3 Proprietary - - graphical multi - formalism DSL tools DSL- XML / XMI - Eclipse, Netbeans Proprietary notation Kermeta ECORE Text (QVT) XMI Eclipse ModFact ECORE XMI XMI Eclipse Merlin ECORE Text (QVT) XMI Eclipse MDA ECORE XMI XMI Eclipse Workbench MOFLON ECORE - XMI Eclipse OptimalJ CWM, XMI XMI Eclipse ECORE QVT Partners ECORE Text (QVT) XMI Eclipse SmartQVT ECORE Text (QVT) XMI Eclipse UMLX ECORE XMI, XSLT XMI, XSLT Eclipse 5 CONCLUSIONES El paradigma de IDM esta en pleno desarrollo en la comunidad de la Ingeniería de Software, y para el IDM lo central son los modelos productivos definidos con rigurosidad por lenguajes de domino especifico para lo cual se hace necesario estudiar todas los técnicas y herramientas existentes y ponerlos en términos del proceso de la IDM, para lo cual se debe desarrollar de un método o fragmento de método para modelos de dominio específico que tenga en cuenta los aspectos de los modelos, los procesos, y las herramientas. Surgirán problemas de interoperabilidad y heterogeneidad entre los diversos modelos que expresan a un Sistema de Información los cual debe ser abordado y superado El proceso de investigación debe ser realizado enfocando modelos adecuados a temas genéricos, procesos o herramientas en particular centrarse en el estudio los Gestión de los Procesos del Negocio 19

20 Revista Alghoritmic ISSN Pag 20 El UML que es un estándar como lenguaje de modelamiento tiene mucha complejidad y es muy genérico para expresar adecuadamente la semántica de un dominio, por lo que para expresar rigurosamente los problemas de un dominio especifico se irán imponiendo los lenguaje de dominio especifico, los cuales están en pleno desarrollo. 6 LITERATURA CITADA [1] Don Batory, Bernie Lofaso, and Yannis Smaragdakis, JTS: Tools for Implementing Domain-Specific Languages, Department Of Computer Sciences the University Of Texas at Austin [2] Douglas C. Schmit, Model Driven Engineering, Published by the IEEE Computer Society February 2006, Vanderbit University [3] Jorge Luis Peres Medina, Sophie Dupuy Chessa, Agnes Front, A Survey of Model Driven Engineering Tools for User Interface Design, Laboratory of Informatics of Grenoble, France [4] José Norberto Masón, Enrique Ortega, Juan Trujillo, Ingeniería Inversa dirigida por modelos para el diseño de almacén de datos, Dpto. de lenguajes y Sistemas Informáticos Universidad Alicante [5] Mark Dalgrano, Mathew Flowler, UML vs. Domain-Specific Languages, Methods & Tools Summer 2008 [6] Marjan Mernik, Jan Heering, Anthony M. Sloane, When and How to Develop Domain Specific languages, University of Maribor, Slovenia, CWI Amsterdam, The Netherlands, Macquarie University, Australia. ACM Computing Surveys (CSUR), vol. 37, pp , 2005 [7] María Valeria Castro, Aproximación MDA para el desarrollo orientado a servicios de sistemas de información Web: del modelo de negocio al modelo de composición de servicios Web, Universidad Rey Juan Carlos, Tesis Doctoral, España [8] Robert B. France, Sudipto Ghosh, and Trung Dinh Trong Model Driven Development Using UML 2.0. Promises and Pitfalls, Published by the IEEE Computer Society February 2006, Colorado State University. [9] Shane Sendall and Wojtek Kozaczynski, Model Transformation the Heart and Soul of Model Driven Software Development, Swiss Federal Institute of Technology in Lausanne (EPFL), Software Engineering Laboratory Microsoft, Prescriptive Architecture Guidance Group Redmond, WA, USA 1) Steve Cookl, Domain-Specific Modelling and Model Driven Arquitecture, MDA, Software Architect Enterprise Framework & Tools Grup Microsoft Corporation, Jurnal January ) Tom Mens, Krzysztof Czarnecki, and Pieter Van Gorp, A Taxonomy of Model Transformations, Software Engineering Lab, Universite de Mons-Hainaut, Belgium, Dept. Electrical and Computer Engineering, University of Waterloo, University Ave, Canada, Dept. Mathematics and Computer Science, Universite Antwerpen, Belgium 20

21 Revista Alghoritmic ISSN Pag 21 Modelamiento matemático de un servidor de correo electrónico Mathematical modeling of a mail server Félix Armando Fermín Pérez Universidad Nacional Mayor de San Marcos, FISI Av. Germán Amézaga s/n Lima 1, Lima, Perú fferminp@unmsm.edu.pe RESUMEN Sistemas informáticos como los servidores de correo electrónico y otros se han constituido en componentes vitales de toda organización moderna, para administrar adecuadamente sus comunicaciones empresariales y sus operaciones. La teoría de control trata sobre el gobierno automático de los sistemas; para esto, primero se realiza el modelado matemático del sistema en estudio y luego se procede a diseñar un controlador que controle el comportamiento del mismo. La presente investigación se plantea determinar el modelo matemático de un servidor de correo electrónico utilizando la identificación de sistemas; para lo cual previamente se recoge información de su funcionamiento en el log del servidor, y luego mediante un sensor software se calcula la longitud de cola del servidor en unidades de tiempo. Los resultados de los experimentos han permitido obtener un modelo ARX lineal con una aproximación del 85% al modelo real. Este modelo matemático servirá luego en otro estudio para diseñar un controlador siguiendo la metodología de la teoría de control realimentado. Palabras claves: teoría de control, servidor de correo electrónico, sensor software. ABSTRACT Computer systems such as mail servers and others have become vital components of any modern organization in order to manage their business communications and operations. Control theory deals with automatic control systems; for this, a mathematical modeling of the system under study is performed first, and the design of a controller that controls its behavior, later. The objective of this work is to determine the mathematical model of a mail server using the system identification. For this, the input and output data are collected from the server and saved in their log, then a software sensor calculates the queue length server in units of time The results of the experiments have yielded a linear ARX model with an accuracy of 85% to the real model. This mathematical model will be used in another study to design a controller using the methodology of feedback control theory. Keywords: control theory, electronic mail server, software sensor. 21

22 Revista Alghoritmic ISSN Pag INTRODUCCION Los sistemas informáticos en general se han constituido en componentes vitales de toda organización moderna, pequeña o grande, por lo que es importante invertir no solo en la implementación sino también en la administración y el mantenimiento de servidores de aplicaciones web, servidores de base de datos y servidores de correo electrónico, en los que basan sus operaciones y comunicaciones. Los administradores de sistemas informáticos y los jefes de informática requieren de bastante dedicación y trabajo manual, además de contar con apropiadas herramientas software para el monitoreo del tráfico de red, los tiempos de respuesta y la utilización de los recursos de procesamiento y de memoria para, por ejemplo en el caso de las empresas de telecomunicaciones, asegurar el cumplimiento de los niveles de calidad de servicio como parte de los acuerdos de nivel de servicio pactados, o en el caso de las pequeñas y medianas empresas garantizar la disponibilidad y buen funcionamiento de sus sistemas informáticos. La teoría de control, conocida también por los términos de sistemas de control, ingeniería de control, teoría de servomecanismos, sistemas de control realimentados y otros, trata de controlar, regular, gobernar automáticamente las características estáticas y dinámicas de funcionamiento de sistemas de cualquier tipo [1]. En una arquitectura de control de lazo cerrado como el de la Figura Nº 1, se trata de obtener una señal de salida del sistema de control y(k) similar a la referencia r(k), mediante la acción de control u(k) que resulta del manipuleo de e(k) por el algoritmo implementado en el controlador. En general se pueden plantear objetivos de control regulatorio o de seguimiento cuando se desea por ejemplo mantener la utilización de algún recurso informático alrededor de un valor predeterminado; de reducción de las perturbaciones para evitar salir del rango de control en la presencia de eventos perturbadores como la ejecución de programas antivirus u otros que sobrecargan al sistema; o de optimización, buscando obtener el mejor valor posible en la salida del sistema para reducir el tiempo de respuesta de las consultas a una base de datos, por ejemplo. Figura Nº 1. Sistema de control en lazo cerrado. (Elaboración propia) La utilización de la teoría de control es ampliamente conocida en diferentes áreas de la ingeniería como la mecánica y otras debido a su enfoque sistemático de análisis y diseño de controladores basándose fundamentalmente en las matemáticas. Utiliza conceptos tales como el de función de transferencia que relaciona la salida y entrada de los sistemas para estudiar ciertas propiedades de los sistemas de control en lazo cerrado. Se estudia la estabilidad, por ejemplo, que siempre es lo primero que se busca cumplir y consiste en acotar la salida del sistema cuando la entrada también lo es. También la exactitud de la señal de salida del sistema, cuando se aproxima lo más posible al valor de la señal de entrada, 22

23 Revista Alghoritmic ISSN Pag 23 aunque en realidad lo que se mide generalmente para fines de control es el denominado error de estado estacionario, diferencia entre el valor de referencia, lo que se desea, y el valor real de la salida, lo que en realidad se obtiene. Otras características tales como el tiempo de establecimiento que muestra lo rápido que converge el sistema en estudio, o el tiempo de subida que muestra la velocidad de respuesta, están relacionadas al comportamiento temporal del sistema. [2] La aplicación de la teoría de control a sistemas informáticos como los servidores de correo electrónico, está orientada a brindar una alternativa de administración automática de estos servidores, reduciendo y aligerando la intervención humana especializada cuando, por ejemplo, suceden eventos de congestión que degradan la calidad del servicio o incrementan el costo de operación, manteniéndolo en un rango aceptable de funcionamiento. La metodología, mostrada en la Figura Nº 2, consta de dos fases denominadas como identificación de sistemas y diseño del controlador. Este trabajo se centra solo en el modelado matemático del servidor de correo electrónico; para ello, se hace uso de un generador de carga de trabajo que simula las solicitudes de servicio al servidor por parte de un número determinado de usuarios; y de un sensor software que mide la longitud de cola del servidor, parámetro necesario para hallar el modelo. Figura Nº 2. Metodología de aplicación de la teoría de control. (Hellerstein, 2004) El interés en aplicar la teoría de control a los sistemas informáticos no es nuevo aunque data de inicios de los años 90, así por ejemplo en 1991, Keshav [3] propuso controlar el flujo de paquetes de datos en redes de comunicación mediante un modelo en tiempo continuo y la regulación del servicio de colas. De manera similar se hicieron trabajos relacionados con el protocolo TCP mediante la utilización de modelos de flujo de fluidos [4]; y en el campo de los sistemas operativos se propuso su uso en el ajuste de parámetros que controlen las asignaciones de memoria [5] y de procesador, lo cual involucraba tener un conocimiento detallado de las entradas de control y de las salidas medidas del sistema operativo en estudio. Otra área de aplicación de la teoría de control lo constituyen los middlewares, tales como los utilizados para transmitir imágenes y video en tiempo real ajustando dinámicamente la calidad de los datos enviados por redes con ancho de banda restringido 23

24 Revista Alghoritmic ISSN Pag 24 [6]. Un middleware es un sistema software que facilita el desarrollo de robustas aplicaciones a nivel empresarial; ejemplos de middleware son los servidores de aplicaciones web, los servidores de base de datos y los servidores de correo electrónico, por citar aquellos en los que se ha aplicado la teoría de control con mayor frecuencia. [7] 2. METODOLOGIA Para hallar el modelo matemático de un servidor de correo electrónico o de cualquier otro servidor informático se puede emplear dos enfoques: el que tiene que ver con la utilización de las teorías por ejemplo, y de otro lado el enfoque empírico que emplea datos recopilados del funcionamiento del sistema mismo, en un periodo de tiempo. En trabajos previos se ha tratado de utilizar principios, axiomas, postulados, leyes o teorías básicas para realizar el modelado matemático de sistemas informáticos, pero lamentablemente existen algunos serios inconvenientes con este enfoque. Primero, es difícil construir un modelo bajo estos principios básicos ya que a menudo se asumen supuestos irreales, debido a la naturaleza compleja y estocástica de un sistema informático. Segundo, es necesario tener un conocimiento detallado del sistema en estudio, más aun, cuando cada cierto tiempo se van liberando al mercado actualizaciones del software, por lo que debería contarse con un experto de manera permanente. Y tercero, que este enfoque no aborda lo referido a la validación del modelo. [8] La identificación de sistemas es un enfoque empírico donde deben identificarse los parámetros de entrada y salida del sistema en estudio, para luego construir un modelo paramétrico como el ARX por ejemplo, basándose en técnicas estadísticas de autoregresión. Este modelo o ecuación parámetrica relaciona los parámetros de entrada y de salida del servidor de correo electrónico de acuerdo a la siguiente ecuación: (1) donde y(k) : variable de salida u (k) : variable de entrada A, B : parámetros de autoregresión k : muestra k-ésima. Debe notarse además que este enfoque empírico trata al sistema en estudio como una caja negra de manera que no afecta la complejidad del sistema o la falta de conocimiento experto. Incluso cuando se actualicen las versiones del software bastaría con estimar nuevamente los parámetros del modelo. En [2] se propone realizar la identificación del sistema de la siguiente manera: 1.- Especificar el alcance de lo que se va a modelar en base a las entradas y salidas consideradas. 2.- Diseñar experimentos y recopilar datos que sean suficientes para estimar los parámetros de la ecuación diferencia lineal del orden deseado. 3.- Estimar los parámetros del modelo utilizando las técnicas de mínimos cuadrados. 4.- Evaluar la calidad de ajuste del modelo. Si la calidad del modelo debe mejorarse, entonces debe revisarse uno o más de los pasos anteriores. 24

25 Revista Alghoritmic ISSN Pag 25 La arquitectura del experimento a implementar, mostrada en la Figura Nº 3, consta de una computadora personal PC1 en la que se ha instalado y configurado el software del servidor de correo electrónico a utilizar. Además en ella se encuentra instalado el sensor software que se encargará de recoger la información del log del servidor, para luego realizar los cálculos de la longitud de cola del mismo basándose en el conteo de las llamadas a procedimientos remotos servidos. Por lo general los administradores de servidores de correo electrónico prestan mucha atención al número de llamadas a procedimientos remotos normalmente procesados en el servidor ya que este valor se halla muy relacionado al número de usuarios activos cuyas solicitudes están siendo procesadas por el servidor. Si por ejemplo, el número de llamadas a procedimientos remotos llega ser muy grande entonces habrá una excesiva utilización del procesador, de la memoria y otros recursos provocando que la performance se deteriore rápidamente. En la práctica, los administradores de servidores de correo electrónico monitorean el uso de recursos del servidor y ajustan el valor del parámetro de entrada, número máximo de usuarios, para lograr el valor deseado de llamadas a procedimientos remotos normalmente procesados. [8] Figura Nº 3. Arquitectura para identificar el servidor de correo electrónico. (Elaboración propia) Y en otra computadora personal PC2 se instala el generador de carga de trabajo, que simula la actividad de los usuarios concurrentes solicitando servicio mediante las llamadas a procedimientos remotos (RPC por sus siglas en inglés: Remote Procedure Call). El generador de carga de trabajo debe configurarse para que emita solicitudes al servidor con mensajes de diferentes tamaños ya que los usuarios no actúan de la misma manera. La actividad generada en el servidor se almacena en el log del servidor. Con los datos de los parámetros de la entrada y la salida del servidor, se hace uso de una técnica de autoregresión con entrada exógena para obtener el modelo ARX del servidor. 3. RESULTADOS El primer paso para hallar el modelo matemático de manera consiste en recoger información de las señales de entrada y salida para luego determinar el modelo ARX del servidor elegido. El servidor de correo electrónico utilizado fue el Kerio Mail Server para redes corporativas. Los datos recopilados de la entrada NumMaxUsuarios y de la salida Longitud de Cola se muestran en la Figura Nº 4. 25

26 Revista Alghoritmic ISSN Pag 26 Figura Nº 4. Número Máximo de Usuarios y Longitud de Cola. (Elaboración propia) Los datos recogidos de la salida, Longitud de Cola, previamente fueron ingresados a un sensor software en donde se cuenta el número de llamadas a procedimientos remotos que han sucedido en el periodo anterior y que se encuentran registrados en el log del servidor. Luego de utilizar la técnica de autoregresión con entrada exógena ARX, se obtiene la ecuación paramétrica siguiente: (2) La validación del modelo obtenido, con un nivel de confianza de aproximadamente el 85%, se realizó tomando una parte de los datos recopilados experimentalmente y comprobando que los valores de la función de autocorrelación de los residuos y la función de correlación cruzada entre las entradas y los residuos se hallan dentro de los rangos mostrados en la Figura Nº 5. Figura Nº 5. Autocorrelación y correlación cruzada de residuos. (Elaboración propia) 4. CONCLUSIONES Y TRABAJOS FUTUROS Se concluye que si es posible hallar modelos matemáticos de estos sistemas con bastante aproximación al modelo real, como en este caso en el que el modelo se aproxima en un 85% al real. 26

27 Revista Alghoritmic ISSN Pag 27 Con la finalidad de lograr mejores aproximaciones, se sugiere emplear modelos matemáticos no lineales. Así se podrá aplicar las técnicas de la ingeniería de control para estudiar la estabilidad y el comportamiento dinámico de sistemas informáticos de manera más aproximada al modelo real y por consiguiente, diseñar un controlador más apropiado. El sensor software implementado ha permitido calcular la longitud de cola del servidor, en base a las llamadas a procedimientos remotos almacenados en el log del servidor en estudio. Trabajos futuros en la aplicación de la teoría de control involucran el estudio de otra gama importante de servidores informáticos como los servidores web y los servidores de base de datos empleando modelos no lineales. Es importante anotar que en el futuro próximo, se planteará el diseño de controladores no lineales para los servidores informáticos en general, ya que el comportamiento temporal de éstos, es esencialmente no lineal, de manera que se hace adecuada la utilización de técnicas de inteligencia artificial como la lógica difusa y las redes neuronales, principalmente. 5. BIBLIOGRAFIA [1] Ogata K, Ingeniería de control moderna, 3ra ed., México: Prentice Hall Hispanoamericana SA, 1998 [2] Hellerstein J, Diao Y, Parekh S, Tilbury D, Feedback control of computing systems, 1ra edición, USA: IEEE/Wiley-Interscience, [3] S. Keshav. Control-theoretic approach to flow control. ACM SIGCOMM Computer Communication Review [En línea], 1991, 21(4): Disponible en [4[ C. Hollot, V. Misra, D. Towsley, W. Gong. A control theoretic analysis of RED. Proceedings of IEEE INFOCOM 01 [En línea], 2001, 3: Disponible en /INFCOM [5] J. Aman, C. Eilert, D. Emmes, P. Yocom, D. Dillenberger. Adaptive algorithms for managing a distributed data processing workload. IBM Systems Journal. [En línea], 1997, 36(2): Disponible en /sj [6] X Wang, M Chen, H Huang, V Subramonian, C Lu, C Gill. Control-Based Adaptive Middleware for Real-Time Image Transmission over Bandwidth-Constrained Networks, IEEE Transactions on parallel and distributed systems, [En línea], 2008, 19(6): Disponible en [7] J Hellerstein. Challenges in Control Engineering of Computing Systems. Proceedings of the 2004 American Control Conference, [En línea], 2004, 3: Disponible en [8] S. Parekh, N. Gandhi, J. Hellerstein, D. Tilbury, T. Jayram y J. Bigus, Using control theory to achieve service level objectives in performance management. Real-Time Systems, [En línea], 2002, 23 (1-2): Disponible en 27

28 Revista Alghoritmic ISSN Pag 28 Sistemas Razonamiento basado en Reglas para determinar recomendación de cirugía refractiva Reasoning Systems based on rules for determining recommendation refractive surgery Augusto Cortez Vasquez, Virginia Vera Pomalaza Universidad Nacional Mayor de San Marcos Facultad de Ingeniería de Sistemas e Informática RESUMEN La cirugía refractiva es una conjunto de procedimientos quirúrgicos que modifican la anatomía del ojo, especialmente la cornea, eliminado definitivamente los defectos refractivos de la miopía, hipermetropía y astigmatismo para que no sea necesario el uso de gafas o lentes de contacto. No todo paciente está en condiciones de que se le haga una cirugía refractiva. Para determinar si se recomienda o no una cirugía ocular, es necesario realizar un riguroso examen previo del paciente, ver si cumple todos estos requisitos y descartar cualquier patología que impida realizar la cirugía o empeore el pronóstico. El oftalmólogo es el especialista encargado de determinar la recomendación. La construcción de sistemas inteligentes, simula de algún modo la manera en que los seres humanos resuelve problemas. Existen distintas maneras entre ellas los sistemas basados en conocimiento que es el objeto del presente articulo. Los Sistemas basados en reglas son agentes inteligentes que se encargan de resolver alguna tarea utilizando como principal recurso, precisamente el conocimiento. Se establece una separación entre la información necesaria para resolver un problema y el método para resolverlo, estos constituyen los elementos principales denominados base de conocimiento y motor de inferencia. El SRBR propuesto, plantea una solución mediante una tarea de clasificación, utiliza arboles de decisión, y propone un modelo en forma de reglas Palabras claves: Ingeniería de conocimiento, Sistemas inteligente, Sistema de razonamiento basado en reglas, cirugía refractiva, arboles de clasificación. ABSTRACT The refractive surgery is a set of surgical procedures that amending the anatomy of eye, especially the cornea, definitively eliminated the defects refractive of the nearsightedness, farsightedness and astigmatism so that is not necessary to use glasses or contact lenses. Not every patient is in a position that he is made a refractive surgery. To determine if recommends or not an eye surgery, is necessary to carry out a rigorous examination of the patient, see if it meets all of these requirements and discard any pathology that prevents perform the surgery or worse prognosis. The ophthalmologist is the specialist responsible for determining the recommendation. The construction of intelligent systems, simulates somehow the manner in which human beings solves problems. There are several ways including systems based on knowledge that is the subject of this article. The Systems based on rules are intelligent agents that are responsible for settling any task using as main resource, precisely the knowledge. Establishing a separation between the information needed to solve a problem and the method to solve it, these are the main elements socalled knowledge base and engine of inference. The SRBR proposed, raises a solution through a task of sorting, uses trees of decision, and proposes a model in the form of rules. Key Words: Engineering knowledge systems, intelligent, System of reasoning based on rules, refractive surgery, trees of classification 28

29 Revista Alghoritmic ISSN Pag 29 1 INTRODUCCION Dentro de Inteligencia artificial, existe una disciplina denominada Ingeniería de conocimiento (IC) que proporciona los métodos y técnicas para construir sistemas computacionales denominados Sistemas Basados en Conocimiento (SBC). Dentro de los SBC tenemos los sistemas de razonamiento basados en casos SRBC y los sistemas de razonamiento basado en reglas SRBR. Un sistema de razonamiento basado en reglas SRBR es un razonamiento que permite capturar la experiencia humana en la resolución de problemas, con el fin de alcanzar decisiones consistentes y repetibles. Estos sistemas son interesantes especialmente en dominios en la que escasean los expertos (medicina, ingeniería etc.). Los SRBR produce un conjunto de reglas, las cuales pueden usarse para responder cuestiones como es recomendable que se realice una cirugía ocular a un paciente, atendiendo a sus antecedentes patológicos?. En muchas situaciones, el método tradicional de convertir datos en conocimiento consiste en un análisis e interpretación realizada de forma manual. El especialista en la materia, en nuestro caso un oftalmólogo, analiza los datos y elabora un informe o hipótesis que refleja las tendencias o pautas de los mismos. Por ejemplo un grupo de médicos puede analizar la evolución de enfermedades oculares entre la población para determinar el rango de edad mas frecuente de las personas afectadas. Este conocimiento, validado convenientemente, puede ser usado por autoridades del sector salud para establecer políticas de prevención de enfermedades oculares. De una manera simplista podríamos decir que el objetivo de la minería de datos es convertir datos en conocimiento, para lograrlo se plantean dos retos: trabajar con grandes volúmenes de datos, procedentes mayoritariamente de sistemas de información, y por otro lado usar técnicas adecuadas para analizar los mismos y extraer conocimiento novedoso y útil. La cirugía refractiva es una intervención sin dolor. Esto es posible mediante la utilización del Excimer Láser en intervenciones que se realizan con anestesia local, métodos incruentos y una permanencia en el quirófano de solo cinco minutos. El paciente se retira viendo normalmente. La meta de la cirugía refractiva con Excimer láser es lograr una mejor calidad de vida abandonando la dependencia del uso de anteojos o lentes de contacto. 2 FUNDAMENTACION TEORICA Un SRBR es básicamente un SBC, desde el punto de la inteligencia artificial, es un sistema que intenta imitar el comportamiento de un ser humano experto en alguna temática, es decir imitan las actividades de un ser humano para intentar resolver los problemas de distinta índole. Existen básicamente tres tipos de sistemas SBC: Sistemas de razonamiento basados en reglas SRBR Los SRBR son sistemas expertos que utilizan para el proceso de inferencia un conjunto de reglas que constituyen la base de conocimiento del experto. Este conjunto de reglas pueden ser activadas a medida que las condiciones son evaluadas positivamente y su utilización implica la creación de nuevos hechos. Este proceso permitirá a partir de unos hechos iniciales desarrollar un proceso deductivo sobre un grupo de reglas, que concluirá el momento en que no quede ninguna regla por ejecutar. Este proceso deductivo desarrolla un encadenamiento de reglas que puede ser encadenamiento hacia adelante, hacia atrás o una combinación de ambos. 29

30 Revista Alghoritmic ISSN Pag 30 Sistemas de razonamientos bayesianos SRB Son sistemas que basan su funcionamiento como su nombre propio indica en las redes bayesianas. Así pues se trata de un modelo probabilístico que relaciona un conjunto de variables aleatorias mediante un grafo dirigido. El motor de inferencia que utiliza para procesar las evidencias se basa en la teoría de probabilidades y más concretamente con el Teorema de Bayes. Este método es especialmente una herramienta extremadamente útil en la estimación de probabilidades ante nuevas evidencias [2]. Sistemas de razonamientos basado en casos SRBC Modelo de razonamiento que permite resolver problemas, entender situaciones y aprender utilizando mecanismos de memorización, problemas superpuestos y criterios de optimización. Los SRBR presenta algunas ventajas frente a los sistemas tradicionales [3]: Adquisición de conocimiento: La adquisición del conocimiento se obtiene infiriendo desde el principio, esto es útil cuando no se tiene un cuerpo de conocimiento como en los SRBC en los que se parte de casos memorizados. Solución a casos especializados: En situaciones muy especificas en donde no se tiene experiencia o casos memorizados como los SRBC, se parte de cero a partir de reglas básicas Aplicación La cirugía refractiva es él termino que define los procedimientos quirúrgicos para corregir los defectos de refracción (Miopia, Astigmatismo e Hipermetropía). El ojo se comporta en forma similar a una cámara fotográfica, por tanto para que una imagen salga enfocada es necesario que dicha imagen se enfoque perfectamente sobre la retina. Existen dos estructuras que usted debe conocer para comprender todos los procedimientos refractivos: 30

31 Revista Alghoritmic ISSN Pag 31 La cornea que es la superficie transparente de la parte anterior del ojo y es la encargada junto al cristalino la encargada de enfocar las imágenes sobre la retina. La retina es la que convierte las imágenes que se enfocan en la retina en impulsos nerviosos que por del nervio óptico se trasmiten al cerebro donde se interpretan. Hay tres tipos de defectos de refracción: Miopía, Hipermetropía y Astigmatismo. Miopía. Es un problema visual por la cual los objetos cercanos se ven claramente, pero los lejanos se ven borrosos, debido a que la imagen visual se enfoca delante de la retina, y no directamente sobre ella. Hipermetropía. Es el efecto contrario a la miopía, suele aparecer en ojos algo más pequeños de lo normal, los síntomas suelen ser cansancio y/o dolor de cabeza cuando se trabaja de cerca, y si la hipermetropía es más alta también afectará a la visión de lejos. Astigmatismo. El astigmatismo es un problema que se presenta en la curvatura de la córnea, lo cual impide el enfoque claro de los objetos cercanos y lejanos. Cuando la córnea, en vez de ser redonda, se achata por los polos aparecen distintos radios de curvatura en cada uno de los ejes principales. Por ello, cuando la luz incide a través de la córnea, se obtienen imágenes distorsionadas. 3 MATERIALES Y MÉTODOS Se utiliza un esquema de solución basado en razonamiento basado en reglas (SRBR) su arquitectura se presenta en la figura A. Base de Hechos:- Memoria de trabajo que contiene toda la información actual del problema a resolver. Contiene todos los cambios de información que se producen en el sistema durante cada proceso de inferencias Motor de Inferencias:- Intérprete de reglas que se encarga de examinar la BH y decidir que regla utilizar y como procesarla. Interfaz del Usuario:- La persona que utiliza el sistema. Interfaz del administrador y/o experto humano:- La persona que implementa el sistema experto y lo administra, en algunos casos es el experto humano. Base de conocimiento:- Contiene las reglas (antecedente, consecuente), el antecedente contiene una lista de clausulas a verificar y el consecuente una listas de acciones a ejecutar. Ct 11, Ct 12, C t 1n At 11, At 12, A t 1n Así (Lista de clausula a verificar, Lista de Acciones a ejecutar) Condición Acción 31

32 Revista Alghoritmic ISSN Pag 32 Figura A: Arquitectura del SRBR Base de conocimientos BC Base de hechos BH Motor de inferencias MI Interfaz de usuario Interfaz del administrador y/o experto humano La tarea de aprendizaje para lo cual los arboles de decisión se adecuan mejor es la clasificación, lo que permitirá determinar de entre varias clases a que clase pertenece un objeto, la estructura de condición y ramificación de un árbol de decisión es idónea para este problema. Por ello utilizaremos la técnica de partición o divide y vencerás. 4 CASO DE ESTUDIO Consideremos el caso de un centro hospitalario en donde se realizan operaciones de cirugía ocular a las personas que lo solicitan. Un oftalmólogo desea disponer de un sistema que le sirva para determinar la conveniencia o no de recomendar la cirugía ocular a sus pacientes. Para ello dispone de una base de dato de sus antiguos pacientes clasificados en operados satisfactoriamente o no, en función del tipo de problema que padecían 32

33 Revista Alghoritmic ISSN Pag 33 El modelo resultante se utiliza para clasificar nuevos pacientes, es decir si es conveniente operarlos o no. Factores que determinan la recomendación de operación ocular: La edad del paciente Conocer el grado de miopía o hipermetropía que tiene el paciente. Ultima vez que se produjo un cambio en la graduación de la vista. Tener corneas sanas y visión estable Tener ojos sanos, sin problemas en la retina u otras enfermedades oculares. No deberá padecer ni diabetes, ni patologías oculares como consecuencia de ella (retinopatías, glaucoma, etc.). Se plantea un sistema de representación del conocimiento basado en arboles de decisión, las mismas que pueden expresarse como conjunto de reglas. si Astigmatismo? no 6 SI Miopía? NO > 6 NO NO no Edad? >18 y 45 Miopía? >1.5 y 10 Diabetes? NO si >45 NO >1 0 SI NO 33

34 Revista Alghoritmic ISSN Pag 34 El árbol se puede expresarse mediante un sistema de reglas: Concluyendo en que SI es operado o No es operado el paciente. R1: SI Astigmatismo =SI Y Miopía >6 ENTONCES NO R2: SI 18< Edad <=45 Y Miopía <= 6 Y Diabetes =NO ENTONCES SI R3: SI Edad >45 ENTONCES NO R4: SI Edad 18 ENTONCES NO R5: SI Miopía >10 ENTONCES NO R6: EN OTRO CASO Operación = SI Si consideramos que el paciente presenta: Astigmatismo = SI y Miopía > 6 Las reglas pueden expresarse como pares: Ejemplo (paciente con astigmatismo y miopía 6, se recomienda operación ocular) Otro ejemplo: (paciente sin astigmatismo con edad entre 25 y 50 y miopía entre 5 y 10, se recomienda operación ocular) Generación del árbol de decisión a partir de un conjunto de ejemplos, utilizando la técnica de partición Cuadro A: Algoritmo de Creación del Arbol E : conjunto de ejemplos R : Raíz del árbol Árbol de raíz R 34

35 Revista Alghoritmic ISSN Pag 35 Principal() Inicio GeneraParticion(R,E) // invoca a GeneraParticion para un árbol de raíz R para clasificar un conjunto de ejemplos E Fin Funcion GeneraParticion (N: Nodo, E: Conjunto de ejemplos) Inicio Si todos los ejemplos de E son de la misma clase C Asignar la clase C al nodo N Sino Particiones = generar posibles particiones MejorParticion= seleccionar mejor partición según criterio de particion Para cada condición i de la partición elegida Añadir un nodo hijo i a N y asignar los ejemplos consistentes a cada hijo(ei) GeneraParticion(i, Ei) // realizar el procedimiento para cada hijo FinPara FinSi Fin Los arboles de decisión se adecuan mejor para tareas de clasificación, esto es determinar de entre varias clases a que clase pertenece un objeto; la estructura de condición y ramificación de un árbol de decisión es idónea para este problema. El algoritmo va construyendo el árbol desde el árbol que contiene solo la raíz, añadiendo particiones y los hijos resultantes de cada partición. En cada partición, los ejemplos se van dividiendo entre los hijos. Finalmente, se llega a la situación en la que todos los ejemplos que caen en los nodos inferiores son de la misma clase y esa rama ya no sigue creciendo. Los arboles de decisión se pueden expresar como conjunto de reglas. Este conjunto de reglas se derivan de particiones. Cada partición es un conjunto de condiciones exhaustivas y excluyentes, cuantos más tipos de condiciones permitamos, más posibilidades de encontrar patrones que hay detrás de los datos. 5 CONCLUSIONES Los SRBR se utilizan en dominios en donde es permisible capturar la experiencia humana en la resolución de problemas. Los arboles de decisión se utilizan generalmente para problemas de clasificación, aunque puede utilizarse en soluciones de regresión, agrupamiento. Los sistemas de reglas son una generalización de los arboles de decisión. Cuanto mas particiones permitamos mas expresivos podrán ser los arboles de decisión generados y, probablemente, mas precisos. Sin embargo, cuantas mas 35

36 Revista Alghoritmic ISSN Pag 36 particiones elijamos, la complejidad del algoritmo será mayor. Por tanto el asunto importante en la elección de un algoritmo es encontrar un buen compromiso entre expresividad y eficiencia. Los algoritmos de aprendizaje de decisión, son de naturaleza voraz de estructura divide y vencerás, se comportan eficientemente con grandes volúmenes de datos, ya sean de gran dimensional dad (muchos atributos) o gran cardinalitas (muchos ejemplos). Este buen comportamiento se sustenta en el hecho de suponer que los datos caben en memoria, sin embargo en muchas aplicaciones de minería de datos no es cierta. Si los datos no caben en memoria el rendimiento de los algoritmos se degradara por el constante trasvase de información de disco o memoria. Para ello se utiliza los algoritmos de aprendizaje de arboles de decisión escalables. 6 REFERENCIAS [1]. Palma Méndez Jose. Inteligencia Artificial. McGRAW-HILL España 2008 [2]. Anderson James Redes neuronales Edit AlfaOmega Mexico 2007 [3]. Hernández Orallo, Jose. Introducción a la minería de datos. Edit Prentice Hall España [4] Del Brio Bonifacio, Redes neuronales y sistemas borrosos Edit Alfaomega México 2007 [5] Ian Sommerville, Ingenieria de Software Edit Pearson Addison Wesley Madrid

37 Revista Alghoritmic ISSN Pag 37 Sistema de Multiagentes para Implementación de Sistema Generación de Horarios Multiagent System for Generating System Implementation Schedule Gilberto Salinas Azaña Universidad Nacional Mayor de San Marcos Facultad de Ingeniería de Sistemas e Informática RESUMEN La distribución de carga horaria es un proceso complejo, por lo general esta distribución es realizada manualmente, a pesar de repetirse todos los semestres académicos difiere del semestre anterior ya sea por el aumento del número de alumnos, limitaciones de infraestructura o por cambios en la disponibilidad de los docentes a pesar de la buena disposición de los responsables, la distribución de la carga horaria, en muchos casos no es el mejor el cual crea conflictos en los interesados como alumnos, docentes o empleados. Existen otros métodos para resolver problemas de asignación, alguno de los cuales pueden determinarse muy rápidamente y dan buenas soluciones pero para algunos casos son inflexibles, esto es, cualquier cambio, prácticamente es como crear uno nuevo, lo cual resulta tedioso y oneroso. La presente investigación de agentes y multiagentes que son entidades de software autónomos e inteligentes, nos permite una implementación de un Sistema de Carga Horaria óptima y flexible. También nos permite aplicar lo último en tendencias de desarrollo de aplicaciones software. Los resultados de esta investigación pretenden mejorar el proceso de desarrollo de software para mejora el proceso de distribución de carga horaria evitando conflictos con las partes interesadas. Palabras Claves: Sistemas multiagentes, generacion de horarios ABSTRACT The distribution of hours is a complex process, this distribution is usually done manually, despite repeated all semesters differs from previous semester either by increasing the number of students, infrastructure constraints or changes in the availability of teachers despite the willingness of those responsible, the distribution of workload, in many cases is not the best which creates conflicts in stakeholders as students, teachers or employees. There are other methods to solve assignment problems, some of which can be determined very quickly and give good solutions, but for some cases are inflexible, that is, any change, is almost like creating a new one, which is tedious and expensive. The present investigation of agents and multiagent entities that are autonomous and intelligent software, allows us to implement a Time Charging System optimal and flexible. It also allows us to apply the latest trends in software application development. The results of this research could improve the software development process to improve the load distribution process time avoiding conflicts with stakeholders. 37

38 Revista Alghoritmic ISSN Pag 38 Keywords: multiagent systems, generation schedules 38

39 Revista Alghoritmic ISSN Pag INTRODUCCIÓN La distribución de carga horaria siempre ha sido un problema en las instituciones educativas también lo es para la institución analizada. La presente investigación tiene por objetivo el estudio de los sistemas multiagentes, ya que la programación basada en agentes constituye un nuevo paradigma en la construcción de sistemas de software y mejorar o hacer eficientes los recursos humanos y de infraestructura. Como tal, se tiene como objetivo principal la construcción de un sistema de generación de horarios para la Facultad de Ingeniería de Sistemas para lo cual se tomara en cuenta el paradigma de los sistemas multiagentes, seleccionando el uso de las plantillas para la documentación y cumplimiento de las mejores prácticas en el desarrollo del software, éstas proveen una guía de cómo se debe documentar el software en su totalidad, para esto se utiliza el lenguaje de Modelamiento UML en base a un proceso de desarrollo de software agil en una platafrma de software libre. 2. Sistemas agentes y Multiagentes (marco teórico) Los sistemas multiagentes (SMAs) es un área de la computación muy utilizada en la actualidad. Es un conjunto de conceptos y tecnologías, que hace posible dar respuestas a problemas complejos, a través de la construcción de sistemas auto-organizados y dinámicos, que pueden integrarse con aplicaciones operativas que cuentan con una utilidad real, sin la necesidad de desechar o reemplazar los sistemas heredados heterogéneos. [SHOHAM 2008], [DUNIN et al, 2005], [LIN, 2007]. Este paradigma, no se ha establecido en la mayoría de ambientes empresariales e industriales, a excepción del sector de telecomunicaciones, donde se han desarrollado una gran cantidad de aplicaciones que actualmente funcionan y resuelven una variedad de problemas utilizando teorías de agentes. [CERRADA, 2006], [BELLIFEMINE et al, 2007], [WOODRIDGE, 2002] Se percibe una creciente actividad sobre este tema en los departamentos de investigación y desarrollo de importantes empresas del ramo del software, tal es el caso de IBM (International Business Machines), Microsoft, HP, entre otras. Además, la existencia de organizaciones tales como FIPA (Foundation Intelligent Physical Agents) organización que agrupa importantes empresas del campo tecnológico que han dictado un conjunto de especificaciones para la construcción de sistemas multiagentes, evidencia que este tipo de tecnología ofrecerá mejores y nuevas soluciones a problemas que actualmente enfrentan las organizaciones que gestionan y mantienen procesos complejos. [KIRN et al, 2006], [LIN, 2007], [MAMEI et al, 2005] 3. Métodos y resultados Se basa en la generación de módulos de software que tengan capacidades de comunicación y autonomía sobre sus acciones, lo que posibilita la construcción de sistemas complejos autorregulados y más eficientes, y que son una nueva forma de realizar desarrollo de software. 39

40 Revista Alghoritmic ISSN Pag 40 Analizador. El agente Analizador es el responsable de capturar la información (datos) requerimientos del usuario y además lleva a cabo una monitorización constante para identificar información y experiencias entre el usuario y el sistema. El agente analizador tiene tres categorías de fuentes de información que definen la infraestructura de la facultad donde el agente analizador puede encontrar información acerca de las Aulas con sus atributos, sus capacidades y estado; Cursos con sus atributos y horarios; y Docentes con sus atributos, cursos que dicta y disponibilidad horaria, ver Figura 1. EAPs Carga Académica AULAS DOCENTES CURSOS N O N O N O SI SI SI Asignar Carga Horaria Acad Figura Nº 1. Proceso de Asignación de Carga Horaria Constructor. El agente Constructor es el encargado de distribuir carga horaria teniendo en cuenta las restricciones para ello, como son la existencia de aula de la capacidad solicitada, en el horario solicitado por el docente. Buscador. El agente buscador es el responsable de buscar la infraestructura adecuada basada en las restricciones de aulas, cursos y docentes. Se han diseñado modelos de multiagentes de software para cada una de las áreas o modulos que intervienen en el proceso de distribucion de horarios, que permitán que el 40

41 Revista Alghoritmic ISSN Pag 41 agente pueda desarrollar la actividad de acuerdo a la característica especial que se le haya asignado. Agencias Multiagentes Se ha descrito el modelo y los agentes para realizar el proceso de distribución horaria y se han dividido en las siguientes agencias: Agencia Asignación de Carga. Se encarga de dar soporte a los procesos de distribución de asignación de carga horaria y se compone de los agentes analizador, constructor y buscador. Agencia de Usuario. Está formado por el Agente Interfaz que es mediador entre los agentes. Entonces cuando un agente requiera enviar un mensaje al usuario, el mencionado agente debe enviar un mensaje al Agente Interfaz para que pueda mostrarlo para información al usuario. Figura 2. Sistema Multiagentes, distribución de los agentes 4. Análisis y discusión A continuación se ilustran los diagramas que representa el modelo de la figura 2 metamodelo de los agentes. Los diagramas que a continuación se detallan describen los roles y las tareas de los agentes Analizador, Constructor y Buscador de la agencia Asignación de Carga y el agente Interfaz de la agencia Usuario. Diagrama de interacción de roles (Agentes) 41

42 Revista Alghoritmic ISSN Pag 42 Agente Analizador. A continuación se describen las tareas llevadas a cabo por este agente. o El agente analizador recibe del Agente Buscador un curso, una determinada aula y un profesor para ese curso, y procede a analizar si el aula está disponible y tiene la capacidad para el curso, luego procede a analizar el horario del curso y además analiza si el docente está disponible para ese curso en el respectivo horario. Agente Constructor. A continuación se describen las tareas llevadas a cabo por este agente. o El agente constructos asigna el aula marcándolo como ocupado, asigna el curso marcándolo como asignado y asigna a un docente al curso en una aula y en un horario determinado 42

43 Revista Alghoritmic ISSN Pag 43 Agente Buscador. A continuación se describen las tareas llevadas a cabo por este agente. o El agente Buscador ubica aulas libres curso no asignados y docentes disponibles El agente interfaz es el agente encargado de monitorizar las actividades de los usuarios para obtener sus perfiles, por tanto, sus metas consisten en monitorizar las tareas de los usuarios y la de recomendar la información adecuada (si Armando solicita cambio de horario. Las respuestas pueden ser: se acepta, o No pero puede ser el día tal a tal hora en tal salón, o SIMPLEMENTE NO) Para poder llevar a cabo estas metas se deb cumplir las siguientes tareas: Modelar Perfiles. La tarea consiste en modelar el perfil de usuario, significa que el agente debe identificar las preferencias, actividades de los usuarios y la información consultada. 43

44 Revista Alghoritmic ISSN Pag 44 Base de Conocimiento. Lleva a cabo tareas como crear y gestionar localmente una base de conocimientos que almacene el perfil del usuario Asesor. La tarea consiste en asesorar o recomendar el conocimiento o fuentes de conocimiento (información relevante) para el usuario. 5. CONCLUSIONES La presente investigacion ha permitido implementar un sistema de distribucion de horarios de clases para la facultad. Ha permitido al grupo la aplicación de paradigmas de sistemas Multiagentes, lo cual motivara a los demás investigadores seguir acercándose a nuevas metodologías. La solución del problema de distribución de horarios con el paradigma de multiagentes crea ventajas competitivas puesto que permite agilizar los procesos de distribución de horarios de clases evitando conflictos en los interesados como alumnos, docentes y administrativos. La investigación de multiagentes nos ha llevado a solucionar el problema con flexibilidad la distribución de horarios de clases lo cual permite o ayuda a los responsables desempeñarse con eficiencia, esto es, evitando la sobrecarga laboral. La investigación nos ha llevado solucionar el problema de distribución de horarios con seguridad, confiabilidad y extensibilidad La investigación nos ha llevado a la implementación utilizando software libre como Java JDK 7 IDE Eclipse. 6. Referencias Bibliográficas Yoav Shoham, Kevin Leyton-Brown Multiagent Systems: Algorithmic, Game- Theoretic, and Logical Foundations Cambridge University Press, 2008 Barbara Dunin-Keplicz, Andrzej Jankowski, Andrzej Skowron, Marcin Szczuka. Monitoring, Security, and Rescue Techniques in Multiagent Systems. Springer, Mariela Cerrada, José Aguilar, Juan Cardillo y Raúl Faneite. Especificación Detallada de los Agentes del SCDIA, Rev. Téc. Ing. Univ. Zulia v.29 n.3 Maracaibo dic Fabio Luigi Bellifemine, Giovanni Caire, Dominic Greenwood. Developing Multi- Agent Systems with JADE. Wiley, Hong Lin. Architectural Design of Multi-Agent Systems: Technologies and Techniques. IGI Global, Stefan Kirn, Otthein Herzog, Peter Lockemann, Otto Spaniol. Multiagent Engineering: Theory and Applications in Enterprises. Springer Marco Mamei (Author), Franco Zambonelli Field-Based Coordination for Pervasive Multiagent Systems. Springer, 2005 Woodridge Michael. An Introduction to Multiagent System. Departament of Computer Ciencie, University of Liverpool. U.K. John Wiley & Sons,

45 Revista Alghoritmic ISSN Pag 45 SERVICIOS WEB UTILIZANDO ASP Web services using ASP Lic. Santiago Moquillaza Henríquez, Mg. Percy de la Cruz Velez de Villa, Mg. Hugo Vega Huerta, Facultad de Ingeniería de Sistemas e Informática Universidad Nacional Mayor de San Marcos smoquillaza@yahoo.com, pdelacruzv@unsmsm.edu.pe, hugovegahuerta@hotmail.com, RESUMEN Los Servicios Web son aplicaciones realizadas por una empresa proveedora del servicio al cual se suscriben mediante aplicaciones Web empresas clientes, interesadas en compartir la información. Los Servicios Web son de amplia utilidad en el mundo globalizado en el cual vivimos, se pueden realizar transacciones de compra y venta, financieras, etc. todo vía servicios web. Es una necesidad para las empresas afines utilizar los Servicios Web de manera que estén integradas, economizando tiempo y costos. Un Servicio Web simple se caracteriza por cuatro estándares: XML, SOAP, UDDI, y WSDL, los cuales al integrarse proporcionan las facilidades de petición y respuesta. En nuestro país esta tecnología emergente todavía no se está explotando en su totalidad, pero las necesidades y presiones del mercado obligarán a usar los servicios web, como herramienta competitiva. Palabras Claves: Servicios web, XML, SOAP, UDDI, WSDL ABSTRACT Web Services are applications made by a company providing the service which are underwritten by Web applications, client companies interested in sharing information. Web services are widely use in the globalized world in which we live, you can make sale and purchase transactions, financial, etc. primarily via web services. It is a necessity for companies related to use Web Services so that they are integrated, saving time and costs. A simple Web service is characterized by four standards: XML, SOAP, UDDI, and WSDL, which provide integrated facilities to request and response. In our country this emerging technology is not yet fully exploited, but the needs and market pressures will force to use Web services as a competitive tool. KeyWords: WEB SERVICES, XML, SOAP, UDDI, WSDL 45

46 Revista Alghoritmic ISSN Pag INTRODUCCION En el mundo globalizado en el cual vivimos hoy en día, las empresas aliadas necesitan estar conectadas a fin de compartir información para tomar ventaja en relación a sus competidores y los escenarios que puedan enfrentar, es indispensable en este ambiente competitivo darle satisfacción a sus clientes; además de proveerle de servicios para que estén informados y puedan realizar sus transacciones desde la comodidad de su hogar u oficina. Lo mencionado es posible mediante los Servicios Web que utilizan como tecnología de transmisión de información el protocolo de Internet HTTP y el lenguaje XML. con estándares o tecnologías como SOAP, UDDI WSDI, que ayudan a la integración y desarrollo de los negocios. Para aclarar la utilidad de los Servicios Web podemos dar ejemplos de aplicaciones al respecto: Una persona desea viajar a otro país ya sea para hacer turismo formal o por negocios, para lo cual se comunica con una agencia de viajes, esta se comunica con su par en el país destino, la cual utiliza Servicios Web de los hoteles, indicando precios, habitaciones, fechas atractivas, etc.; líneas aéreas, e información de bancos, a su vez disponen de Servicios Web meteorológicos los cuales comparten con los hoteles, buses para ir a la ciudad respectiva, museos, centros históricos, etc. En base a todo ello la agencia responde el paquete adecuado al turista, luego el turista realiza el pago a la agencia, con el conocimiento previo del país a visitar. Una empresa necesita surtir el stock de su inventario. dado que su sistema activa la alarma de stock de reposición para alguno de sus productos o insumos, para ello utiliza un Servicio Web para hacer una petición al proveedor que mejor le cotice, y que sea de su confianza por la calidad, envía su pedido a la empresa proveedora en línea pudiendo seleccionar automáticamente la oferta que más le convenga, realizando la transacción vía web. Indudablemente, la transacción de compra y venta, generará una reducción de costos, beneficiando a las empresas que interactúan. Los servicios de mensajería para enviar mensajes de texto a través de SMS, servicio de mensajes cortos, a un dispositivo móvil como teléfono celular compatible con esta función. Sin un Servicio Web adecuado, se trataría de una idea compleja que conllevaría la conexión física de un teléfono celular a un ordenador vía el puerto serial, o la integración del proveedor de SMS con lo que se perdería la sencillez que ofrece un Servicio Web [1]. En el presente artículo narraremos acerca de los Servicios Web y la plataforma sobre la cual trabaja y haremos un pequeño ejemplo con el software ASP.NET, de manera que sea más didáctico el artículo. 46

47 Revista Alghoritmic ISSN Pag FUNDAMENTACIÓN TEÓRICA 2.1. Definición: Un Servicio Web es como un Sitio Web al que solo pueden acceder ordenadores. La empresa proveedora puede optimizar su sitio incluyendo determinadas herramientas susceptibles de ser invocadas por los ordenadores. Si dos compañías quieren unir sus ordenadores deben establecer algún tipo de mecanismo de enlace con dicho objetivo. [1] La información que vamos a pasar por HTTP va a ser información en formato XML 2.2 HTTP Es el protocolo de TCP/IP a nivel de aplicación que permite el funcionamiento de la Word Wide Web, en términos más simples es una tecnología de transmisión de información [2]. 2.3 XML Es un lenguaje de marcas estándar cuyo objetivo es facilitar el intercambio de información entre aplicaciones, sin importar las diferencias entre plataformas de hardware, sistemas operativos, lenguajes de programación ni idioma. Algunos expertos denominan a este lenguaje como el nuevo ASCII, sistema universal de codificación de caracteres reconocido por la práctica totalidad de los sistemas.[3] Un ejemplo de la estructura y los datos que contiene un archivo UML es el que especificamos en el ejemplo, agenda es el nombre de la tabla y sus campos son Nombre, Teléfono y Celular como delimitadores se utiliza los símbolos <>, en medio de dichos delimitadores está el nombre del campo a continuación están los valores y luego cada campo se cierra con el delimitador </> y el nombre del campo respectivo. <?xml version="1.0" standalone="yes"?> <Cliente> <Elemento> <Nombre>SANTIAGO MOQUILLAZA HENRIQUEZ</Nombre> <Teléfono1> </Teléfono1> <Celular> </ Celular > </Elemento> <Elemento> <Nombre>PERCY DE LA CRUZ VELEZ DE VILLA</Nombre> <Teléfono1> </Teléfono1> <Celular> </ Celular > </Elemento> <Elemento> <Nombre>HUGO VEGA HUERTA</Nombre> <Teléfono1> </Teléfono1> 47

48 Revista Alghoritmic ISSN Pag 48 <Celular> </ Celular > </Elemento> <Elemento> <Nombre>EVA VASQUEZ VALLE</Nombre> <Teléfono1> </Teléfono1> <Celular> </ Celular > </Elemento> </Cliente> Aplicación ejemplo desarrollado por el grupo de trabajo. 2.4 SOAP o simple Object Access Protocol Es un protocolo basado en el uso y utilización de XML, el cual se utiliza para transportar las peticiones y respuestas enviadas a través de la web por medio del protocolo HTTP, de esta manera, no nos importará lo más mínimo el sistema que haya conectado en el otro extremo. La información será manejada automáticamente por el protocolo.[2] 2.5 WSDL o web service Description Language, Es un formato de intercambio de información, entre el servicio y el consumidor. Los datos recibidos y enviados deben ser interpretados adecuadamente de alguna manera WDSL es un documento XML, que describe los protocolos o servicios de transporte, la semántica o peticiones y las llamadas a realizar, WDSL es un descriptor de cómo debe hacerse el intercambio de la información. [2] 2.6 UDDI o universal Discovery, description and integration Descubrimiento e Integración Universal es un tipo de directorio orientado a la integración de procesos de negocio, se suele utilizar para buscar socios de negocio que realicen una tarea concreta a través de un Servicio Web. Es como unas páginas amarillas gigante donde poder acudir en busca de información, descripciones, etc. sobre Servicios Web XML [2] 2.7 ADO.NET y XML XML se ha convertido en la piedra angular de la informática distribuida de nuestros días. De ahí que gran parte de las motivaciones en cuanto a la redefinición del API de ADO, se deban a la adaptación de los objetos a un modelo de procesos que se apoya en documentos XML, no en objetos específicos de cada plataforma a partir de cursores. Esto permite que las clases de ADO.NET puedan implementar mecanismos de conversión de datos entre plataformas, lectura de datos de cualquier origen, habilitar mecanismos de persistencia en el mismo formato en el que se procesan., etc. En esta redefinición, Microsoft ha puesto como intermediario entre un cliente y sus datos, un adaptador que transforma cada comando y cada dato en modelos de documentos XML. Tanto para consultas como para actualizaciones. Esto es lo que posibilita la nueva filosofía de acceso a datos desconectados de ADO.NET: primero se cargan en el cliente los documentos necesarios almacenándolos en DataSet, (tablas temporales en memoria) a partir de consultas a tablas, vistas, procedimientos, etc.; se 48

49 Revista Alghoritmic ISSN Pag 49 nos da la posibilidad de trabajar con documentos, sin necesidad de estar continuamente consumiendo recursos de la red; y por último, se procesarán los cambios producidos enviándolos a la base de datos, el adaptador tomará los cambios del documento, y los replicará al servidor. En la figura se puede ver un esquema de la relación entre ADO.NET y XML. [4] Figura 1. Obtenido del libro de la referencia bibliográfica [4] 2.8 Consideraciones relativas a la seguridad Los desarrolladores de Servicios Web, deben dar respuesta a una serie de consideraciones relativas a la seguridad para evitarse de problemas. La naturaleza de los servicios Web pone nuestros métodos a disposición de pública. Por ello debemos tomar los medios para evitar accesos no autorizados a información sensible. Una buena técnica para proteger nuestros servicios consiste en pedir el nombre de usuario y una contraseña en cada llamada, para controlar que el usuario que está realizando la petición es el emisor del pedido [1]. 2.9 Servicios Web en nuestro país Todavía en nuestro Perú, no se utiliza masivamente, quizás porque implica mucha confianza entre empresas aliadas, no hay una integración vertical entre proveedores y clientes, amén de que los sistemas están pensados para el manejo al interior de la empresa; solo se piensa en los canales de distribución físicos, pero no alineado a las tecnologías de información, tal cual exige hoy en día el mercado global., otra de las razones es la desconfianza de que los competidores se enteren de información privada, ello se salva con un adecuado diseño de perfiles, y la otra gran razón es que los gerentes generales de las empresas desconocen la utilidad de los Servicios Web para proponerlos a su departamento o gerencia de Sistemas; en breve tiempo veremos que no solo se harán Sistemas para satisfacción de la empresa sino pensando en los clientes. 49

50 Revista Alghoritmic ISSN Pag EJEMPLO DE CREACION Y CONSUMO DE UN SERVICIO WEB EN UNA PLATAFORMA ASP Se trata de una pequeña aplicación LEERDATOS creada por un productor FIGURA 2. Elaborada por el grupo de trabajo, creación del Servicio Web 50

51 Revista Alghoritmic ISSN Pag 51 FIGURA 3. Elaborada por el grupo de trabajo, nombrando el Servicio Web Luego se nos presentará la ventana donde debemos digitar el código: Imports System.Web Imports System.Web.Services Imports System.Web.Services.Protocols Imports System.Data.SqlClient, System.Data COMENTARIO : Se importa a la clase que reconoce base de datos sqlserver, asi como las facilidades web <WebService(Namespace:=" _ <WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1)> _ <Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated()> _ Public Class LEERDATOS Inherits System.Web.Services.WebService Private CONEXION As String="SERVER=SANTIAGO- F13B31\SQLEXPRESS;DATABaSE=PROVEEDOR;INTEGRATED SECURITY=SSPI" Private CN As SqlConnection Private DA As SqlDataAdapter Private DS As New DATASET <WebMethod()> _ Public Function LISTACLIENTES() As DataSet 51

52 Revista Alghoritmic ISSN Pag 52 CN = New SqlConnection(CONEXION) CN.Open() DA = New SqlDataAdapter("SELECT * FROM CLIENTES", CN) DA.Fill(DS) Return DS End Function End Class COMENTARIO: El código anterior nos conecta a la base de datos y y se gurda los datos en un espacio de memora da definido por la clases Sqldataadapter, con este web service accedemos a la tabla clientes. CLIENTE Es la entidad que va a consumir o utilizar el Servicio Web, debemos agregar la referencia Web donde se encuentra el servicio(aplicación definida por el productor) Para ello el servicio web destino debe estar habilitado, y poner la URl., correspondiente a fin de que realice la búsqueda para luego si está activa añadirla a nuestra aplicación cliente. FIGURA 4. Elaborada por el grupo de trabajo, agregando la referencia web 52

53 Revista Alghoritmic ISSN Pag 53 FIGURA 5. Elaborada por el grupo de trabajo, ubicando la URL para agregar la referencia web Indicada la URL debe pulsarse Go y luego una vez que se halla el Servicio Web, pulsar en Add Web Reference, de manera que la aplicación cliente ubique el Servicio Web, a continuación y estando diseñada la aplicación cliente digitar el código de la aplicación cliente para acceder a los métodos del Servicio Web. CODIGO DEL CONSUMIDOR WEB Imports localhost.leerdatos Partial Class _Default Inherits System.Web.UI.Page Private ACCESO As New localhost.leerdatos Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load If Not Page.IsPostBack Then Me.GridView1.DataSource = ACCESO.LISTACLIENTES Me.GridView1.DataBind() COMENTARIO : Se muestra en el objeto Gridview1 los datos de los clientes mediante el objeto ACCESO. End If End Sub End Class 53

54 Revista Alghoritmic ISSN Pag 54 //COMENTARIO : //El objeto ACCESO instancia el método LISTACLIENTES del Servicio Web que se //halla en la clase proveedora LEERDATOS // Y se lee los datos proporcionados por el Servicio Web, se debe hacer la atingencia //que debe estar activo el Servicio Web de la máquina productora para que el //consumidor pueda acceder y realizar las operaciones correspondientes. 4 CONCLUSIONES - Posiciona a las empresas con ventaja, porque pueden enfrentar escenarios con mayor adaptabilidad, al conocer la información del mercado. - Se incrementa el número de clientes atraídos por los servicios oportunos que brinda la empresa - Mayor facilidad de planificar a corto y mediano plazo. - Se estrecha mejores relaciones entre empresas clientes y proveedores. - Se reducen costos y sobre todo tiempo, por ende hay mayores utilidades debido a que las transacciones son mediante las aplicaciones Web y no físicas. - La seguridad se logra con una buena planificación en el diseño de los Componentes. - Los Servicios Web permiten que las organizaciones integren sus diferentes aplicaciones de una manera eficiente, sin preocuparse por cómo fueron construidas, dónde residen, son independientes del sistema operativo donde se ejecutan o cómo acceder a ellas por las facilidades de los estándares explicados en el artículo. - En nuestro país falta desarrollo de Servicios Web, dada la baja comunicación entre clientes y proveedores., amen del desconocimiento de las gerencias generales acerca de sus ventajas. 5 REFERENCIAS BIBLIOGRÁFICAS [1] Bill Forgey, Denise Gosnell, Matthew Reynolds, Iniciación a Visual Basic. N et Base de Datos, Danisoft (Madrid-España) ISBN: , [2] Jorge Serrano Pérez, Manual Avanzado Visual Basic.Net impreso en España Ediciones Anaya, ISBN: [3] Francisco Charte Ojeda, Programación de Base de Datos con Visual Basic.Net - Mdrid-España ISBN:

55 Revista Alghoritmic ISSN Pag 55 [4] Luís Miguel Blanco Programación en Visual Basic.Net - Grupo EIDOS, Madrid (España), ISBN ,

56 Revista Alghoritmic ISSN Pag 56 BASE DE DATOS DISTRIBUIDOS USANDO ALGORITMOS GENÉTICOS PARA OPTIMIZACIÓN DE PROCESO DE TRANSACCIÓN EN LA WEB Distributed database optimization using genetic algorithms for transaction processing on the web Luzmila Pró Concepción Universidad Nacional Mayor de San Marcos Facultad de Ingeniería de Sistemas e Informática lproc2003@hotmail.com RESUMEN El presente articulo Base de Datos Distribuidos Usando Algoritmos Genéticos Para Optimización de Proceso de Transacción en la Web, trata sobre algunas deficiencias presentadas en los procesos de transacción por el procesador del servidor; que actualmente trabajan con algoritmos tradicionales; como la lectura / escritura de datos en el disco magnético en el servidor Web, produciéndose por ejemplo, demora en la cola de espera, demora en tiempo de proceso de transacción, demora en tiempo de respuesta, que ocasionan los cuello de botella y falta memoria, etcétera. El problema central que se propone está orientado al crecimiento y, evolución del servidor web de una manera económica y escalable que lleva a un rendimiento óptimo. Por consiguiente, existe la necesidad de estudiar los procesos de transacciones del sistema, de tal manera que se aplique otra alternativa como algoritmos genéticos para optimizar el proceso de transacción en el servidor, a fin de así mejorar los procesos del servidor web y, mejorar la atención a los clientes / usuarios. Se implementara un simulador de transacciones orientando a la toma de decisiones del administrador de transacciones aplicando los algoritmos genéticos, tal que permita determinar que transacción se debe tomar para asignarlo en la cola de procesos. Se asumen ciertas restricciones que el simulador tomará como dados. Palabras claves: Algoritmos genéticos, base de datos distribuidos, genoma, interconexión de sistemas abiertos, protocolo de control de transmisión, protocolo de internet, servidor Web, transacción. ABSTRACT The development of the investigation "Distributed Database Using Genetic Algorithms For Optimization of Process Transaction in the Web" that have been allowed to reach the following there is deficiency in the time of transaction processes for processor of the server; that they are working with traditional algorithms; as the reading / writing of data in the magnetic disk in server web. For example, it delays in the wait line, it delays in time of transaction process, it delays in time of answer that you/they cause as neck of the bottle, it lacks memory, etc. The central problem that intends is guided to the growth and, evolution of the server web in an economic and scalable way 56

57 Revista Alghoritmic ISSN Pag 57 that takes to a good yield. Consequently, the necessity exists of studying the processes transactions of the system, in such a way that another alternative is applied as genetic algorithms to optimize the process of transactionin servant, basing stops to improve processes of the server web and, to improve the attention to the clients / users. The objective is to implement a pretender of transactions guiding the taking of the administrator's of transactions decisions with the application of genetic algorithms. It was used the genetic algorithms to determine that transaction should take to assign it in the line of processes. Certain restrictions are assumed that the pretender took as given. Key words: Genetics algorithms, base of distribuid data, genoma, interconection of open systems, protocol of control of transmission, protocol of Internet, Web Server, transaction. 1. INTRODUCCIÓN El presente estudio trata de Base de Datos Distribuidos Usando Algoritmos Genéticos Para Optimización de Proceso Transacción en la Web, identificado en el área de ingeniería de software en la web, para el desarrollo del estudio se ha requerido la técnica de caché, proceso de transacción, un conjunto de procedimientos para el proceso de transacción en el servidor web y la tecnología de base de datos distribuidos. El estudio presentará una propuesta que mejorara los procesos de tareas en el servidor, ante algunas deficiencias como en el tiempo de procesos de transacciones en el sistema; que están trabajando con algoritmos tradicionales, como la lectura / escritura de datos en el disco magnético en el servidor web, por ejemplo, demora en tiempo de espera para el proceso de transacción, demora en tiempo de respuesta, que ocasionan los denominados cuellos de botella, y falta memoria, para lo cual se propondrá una metodología nueva para el sistema de aplicación usando algoritmos genéticos, para optimizar eventos concurrentes de proceso de transacción en el servidor Web, que permitirá ahorro de: tiempo de espera de las colas, tiempo de proceso de tareas, menor tiempo de lectura / escritura datos en disco magnético del servidor web de la empresa o institución. En el estudio se utilizarán Protocolo de Internet / Protocolo de Control Transmisión (TCP/IP) para la transmisión de datos (paquetes) en redes de computadoras. El articulo se desarrollara a través de los siguientes: Marco Conceptual comprende Algoritmos Genéticos, Sistemas Distribuidos, Base de Datos Distribuidos, Gestión de Transacciones y la Metodología de implementación del simulador prototipo utilizando algoritmos genéticos para optimizar procesos de transacción en la web, finalmente los Resultados y Conclusiones. 2. MARCO CONCEPTUAL 2. 1 ALGORITMOS GENÉTICOS Definición Los Algoritmos Genéticos (AGs), fueron creados por John Holland (1975). Es una técnica de búsqueda aleatoria dirigida, que puede encontrar la solución óptima global en los espacios de búsqueda multidimensionales complejos. Los Algoritmos genéticos, es un modelo de la evolución natural que los operadores emplean, inspirado por el proceso de evolución natural. Los operadores genéticos, manipulan a los individuos en una población a lo largo de varias generaciones para mejorar su aptitud gradualmente. Los individuos son como la población semejante a los cromosomas, normalmente representado como una cadena de números binarios Evolución biológica 57

58 Revista Alghoritmic ISSN Pag 58 Todo organismo vivo consiste de células. En cada célula hay el mismo conjunto de cromosomas. Los cromosomas son cadenas de ADN y sirven como modelo del organismo completo. Un cromosoma consiste de genes, bloques de ADN. Cada gen, codifica una proteína particular. Cada gen codifica una característica, Por ejemplo, el color de los ojos de una persona, los posibles valores de una característica (azul, cafés) se llama alelos. Cada gen tiene una propia posición en el cromosoma, esta posición se denomina locus. El conjunto completo del material genético se llama genoma. Un conjunto particular de genes en el genoma es llamado genotipo. El genotipo va acorde con el desarrollo posterior, es como la base del nacimiento del fenotipo del organismo, el cual es la característica (física o mental), como el color de los ojos de la persona, la inteligencia de la persona, etcétera (Darwin 1930). Se muestra en la figura célula : Figura Célula Representación Normalmente, se representa la optimización de los parámetros que van a ser perfeccionados en un formulario de una cadena de operadores genéticos que son adecuados para este tipo de representación. Hay dos métodos de representación para los problemas de optimización numérica (Davis 1991). El método más usado, es la de representación de cadena binaria. El segundo método de representación, es utilizando un vector de enteros o números reales, con cada entero o número real representado sólo el parámetro Creación de la población inicial Los algoritmos genéticos, requieren un grupo de soluciones iniciales o población inicial. Hay dos maneras, de formar esta población inicial. El primero consiste en utilizar las soluciones aleatorias producidas al crear un generador del número aleatorio. El segundo método, emplea el conocimiento a priori sobre el problema de optimización dado Operadores genéticos Hay tres operadores genéticos comunes: de selección, de cruzamiento y de mutación. a) La selección: El objetivo del procedimiento de selección, es producir más reproducciones de individuos cuyos valores de aptitud sean más altos que aquellos cuyos valores de aptitud son bajos. En los algoritmos genéticos, hay dos procedimientos de selección: la selección proporcional y la de selección jerárquica, basada en (Whitley 1989). La selección proporcional, se le llama "rueda de la ruleta", mediante este procedimiento se valora la aptitud de individuos 58

59 Revista Alghoritmic ISSN Pag 59 los que son representados por las anchuras de las hendiduras de la rueda. Para seleccionar a un individuo para la próxima generación, los individuos de las hendiduras con anchuras grandes representan los valores de aptitud altos, estos tendrán una oportunidad más alta de ser seleccionados, después, de un funcionamiento de la rueda se obtiene un conjunto aleatorio. Una manera, de prevenir la convergencia rápida es limitar el rango de ensayos asignados a un solo individuo, para que ningún individuo genere demasiados descendientes. La clasificación jerárquica, basado en el procedimiento de la producción de idea planteada. Cada individuo genera un número esperado de descendientes que se basa en la línea de su valor de aptitud. b) El cruzamiento: Se considera que esta operación es lo que hace a los algoritmos genéticos diferente de otros algoritmos, como la programación dinámica. La operación de cruzamiento, se utiliza para crear dos nuevos individuos de dos individuos existentes, que son escogidos de la población actual para la operación de selección. Hay varias maneras de hacer esta operación. El cruzamiento basado en un punto. Es la operación de cruzamiento más simple. Se seleccionan dos individuos al azar como los padres de una familia de individuos formados por el procedimiento de selección, el procedimiento se corta al azar en un punto escogido. Las colas son las partes después del punto cortante, y dos nuevos individuos se producen. Se observa que esta operación no cambia los valores de los bits. Se muestran la tabla 2.1,2 especificados Un cruzamiento basado en un punto. Tabla 2,1.2 Cruzamiento de Cromosomas Del cruzamiento basado en un punto, el padre 1, tiene once bits de ceros y unos. Sea la longitud de 11 bits, como la fórmula L-1 = L puntos de cruce, y aplicando en la Tabla 2.1.2, se tiene 11-1 = 10 puntos; entonces, se debe generar un número aleatorio de 1 al 10. Se ha tomado el número 5, es decir, del padre 1 se toma los 5 bits primeros que son: y del padre 2, se toma los 6 bits últimos que son: y se une ambos bits; entonces se tiene la cadena nueva 1 que son los siguientes bits: resultado del cruzamiento basado en un punto. Del mismo modo, del padre 2 se toma los 5 primeros bits que son: y del padre 1 se toma los 6 últimos bits que son: y se une ambos bits; entonces, se tiene la cadena nueva 2 que son el siguiente conjunto de bits: resultado del cruzamiento basado en un punto. De está manera, en general se realizan el cruzamiento de puntos de la población de los algoritmos genéticos. c) La mutación: En este procedimiento, se verifican a todos los individuos de la población, bit por bit, y los valores de bits se invierten al azar según una proporción especificada. A diferencia de la operación de cruzamiento, la mutación es una operación monádica, es decir, una cadena de un niño, se produce de una sola cadena de un padre. El operador de la mutación obliga al algoritmo a investigar nuevas áreas de solución. En el futuro, ayuda a los algoritmos genéticos a evitar la convergencia prematura y encuentra la solución óptima global. Un ejemplo se muestra en la tabla siguiente: 59

60 Revista Alghoritmic ISSN Pag 60 La cadena vieja La cadena nuena TABLA Mutación de cromosomas. La inversión, este operador adicional es empleado para varios problemas, incluso en el problema de la colocación celular. Se selecciona dos puntos al azar de un individuo y la parte de la cadena entre esos dos puntos se invierte, según se muestra en la tabla La cadena vieja La cadena nuena Tabla Inversión de un segmento de la cadena binaria Funcionamiento de los algoritmos genéticos Se parte de una función f(x) muy sencilla de: f ( x) Sí se desea encontrar el valor de x, que hace que la función f(x) alcance su valor máximo, sin embargo, restringiendo a la variable x, a tomar valores comprendidos entre 0 y 31. Aún más, a x sólo, le vamos a permitir tomar valores enteros, es decir: 0, 1, 2, 3,..., 30, 31. Obviamente el máximo se tiene para x = 31, donde f, vale 961. Lo primero, que se debe hacer es encontrar una manera de codificar las posibles soluciones (posible valores de x). Una manera de hacerlo es mediante la codificación binaria. Aplicando esta codificación a un posible valor de x es: (0, 1, 0, 1, 1). Luego se procede a multiplicar la última componente (un 1) por 1, la penúltima (un 1) por 2, la anterior (un 0) por 4, la segunda (un 1) por 8 y la primera (un 0) por 16 y a continuación calcular la suma: Resulta 11. Observar que (0, 0, 0, 0, 0) equivale a x = 0 y que (1, 1, 1, 1, 1) equivale a x = 31. Por ejemplo, se muestra en la figura 2.1.2, la operación de cromosoma siguiente: x 2 ción de cromosoma. Figura Operación de Cromosoma 60

61 Revista Alghoritmic ISSN Pag 61 A cada posible valor de la variable x, en representación binaria se le llamará individuo. Una colección de individuos constituye una población y el número de individuos es el tamaño de la población. Una vez que se tiene codificada la solución, se debe escoger un tamaño de población. Para este ejemplo ilustrativo, se escogerá a 6 individuos. Se debe partir de una población inicial. Una manera de generarla es aleatoriamente: Se coge una moneda y se lanza al aire; si sale cara, la primera componente del primer individuo es un cero (0) y en caso contrario si sale una cruz es un uno (1). Repetir el lanzamiento de la moneda y se tendrá la segunda componente del primer individuo (un 0 si sale cara y un 1 si sale cruz). Así hasta 5 veces y se obtendrá el primer individuo. Repetir ahora la secuencia anterior para generar los individuos de la población restante. En total se tiene que lanzar 5 * 6 = 30 veces el siguiente paso es hacer competir a los individuos entre sí. Este proceso de selección Se muestra en la tabla (1) (2) (3) (4) (5) 1 (0,1,1,0,0) (1.0.0,1,0) (0,1,1,1,1) (1,1,0,0,0) (1,1,0,1,0) (0,0,0,0,1) Tabla de selección Cada fila en la tabla 2.1.5, está asociada a un individuo de la población inicial. El significado de cada columna de la tabla es el siguiente: (1) = Número que se le asigna al individuo. 61

62 Revista Alghoritmic ISSN Pag 62 (2) = Individuo en codificación binaria. (3) = Valor de x. (4) = Valor de f(x). Observar que el mejor individuo es el de la fila 5 con f = 676. Calculando la media de f, se obtendrá fmed = En cuanto a la columna (5), se realiza la comparación entre parejas de los individuos. Una manera de realizar el proceso de selección es mediante un torneo entre dos. A cada individuo de la población se le asigna una pareja y entre ellos se establece un torneo: el mejor genera dos copias y el peor se desecha. La columna (5), indica la pareja asignada a cada individuo (aleatoriamente). 2.3 SISTEMAS DISTRIBUIDOS Definición de sistemas distribuidos Es un conjunto de entidades que se comunican entre si a través de mensajes, los cuales son enviados sobre vías de comunicación (García 1999). Son una colección de elementos de cómputo autónomo que se encuentran físicamente separados y no comparten una memoria común, se comunican entre sí a través del intercambio de mensajes utilizando un medio de comunicación. En todo sistema distribuido se establecen una o varias comunicaciones siguiendo un protocolo prefijado mediante un esquema cliente / servidor (Buades 2002). Un sistema distribuido se compone de entidades, procesos, computadoras, redes de computadoras, dispositivos, procesadores etcétera. Se muestra en la figura la conmutación de mensajes /paquetes en una LAN siguiente: Figura Conmutación de mensajes /paquetes en una LAN Ventajas y desventajas de sistemas distribuidos 62

63 Revista Alghoritmic ISSN Pag 63 En la Tabla 2.3.1, se hace una breve descripción de ventajas y desventajas de sistemas distribuidos (Tanenbaum 1996, Araujo 2004). VENTAJAS DESVENTAJAS Procesadores más poderosos y a menos costo. Mayores controles de acceso, y son costosos Avances en la Tecnología de comunicaciones, compartición de recursos, el sistema se puede recuperar Servicios de replicación de datos y servicios con posibilidades de fallas de una falla. Eficiencia, flexibilidad, disponibilidad y confiabilidad de los sistemas distribuidos. Interconexión: fiabilidad posible perdida de mensajes y posibilidad saturación Crecimiento modular. Añadir en pequeños incrementos Alguna potencia de cada nodo no adecuada. Adm compleja Los microprocesadores ofrecen mejor proporción Velocidad de propagación de información lenta a veces precio/rendimiento y mayor velocidad que los mainframes Algunas aplicaciones utilizan máquinas que están Software más complejo. separadas a cierta distancia (distribución inherente). Tabla Ventajas y Desventajas de los Sistemas Distribuidos 2.4. BASES DE DATOS DISTRIBUIDOS Conceptos de base de datos distribuidos Base de Datos es una colección de datos estructurados sobre una red y que pertenecen, lógicamente, a un solo sistema distribuido (Hurtado 1997), la cual cumple las condiciones siguientes: La información de la base de datos esta almacenada físicamente en diferentes sitios de la red. Las bases de datos locales tienen sus propios usuarios locales, su propio Sistema de Gestión de Bases de Datos (DBMS) y programas para la administración de transacciones, y su propio administrador local de comunicación de datos. Este gestor global permite que los usuarios puedan acceder a los datos desde cualquier punto de la red Ejemplo de base de datos distribuidos Sea un banco con sucursales, cada sucursal o sitio con una computadora que controla las terminales de la misma y el sistema de cuentas, están conectadas por la red. Durante las 63

64 Revista Alghoritmic ISSN Pag 64 operaciones, las aplicaciones en las terminales de la sucursal necesitan acceder la base de datos de la misma. Como sólo acceden a la misma red local, estas son aplicaciones locales. Desde el punto de vista tecnológico, aparentemente lo importante es la existencia de algunas transacciones que acceden a información en más de una sucursal. Estas transacciones son globales o distribuidas. Una transacción global sería una transferencia de fondos de una sucursal a otra. Esta aplicación requiere actualizar datos en dos diferentes sucursales y asegurarse de la real actualización en ambos sitios o en ninguno. Figura BDDH: Figura 2.4 Base de Datos Distribuidos Homogéneos 64

65 Revista Alghoritmic ISSN Pag 65 Figura Base de Datos Distribuidas Homogéneas (BDDH) Base de datos homogéneas y heterogéneas En los sistemas de bases de datos distribuidos homogéneas, todos los sitios emplean idéntico software de gestión de bases de datos, son conscientes de la existencia de los demás sitios y acuerdan cooperar en el procesamiento de las solicitudes de los usuarios.. En las bases de datos distribuidos heterogéneas podría ser que los diferentes sitios utilicen esquemas y software de gestión de sistemas de bases de datos diferentes GESTIÓN DE TRANSACCIONES Concepto de transacción Las transacciones a menudo, desde el punto de vista del usuario de una base de datos, se consideran a un conjunto de varias operaciones sobre una base de datos como una única operación. Por ejemplo, una transferencia de fondos desde una cuenta corriente a una cuenta de ahorros es una operación simple desde el punto de vista del cliente; sin embargo, en el sistema de base de datos, está compuesta internamente por varias operaciones. Evidentemente es esencial que tengan lugar todas las operaciones o que, en caso de fallo, ninguna de ellas se produzca. Sería inaceptable efectuar el cargo de la transferencia en la cuenta corriente y que no se abonase en la cuenta de ahorros. Una transacción se inicia por la ejecución de un programa de usuario escrito en un lenguaje de manipulación de datos de alto nivel o en un lenguaje de programación (por ejemplo, SQL, C++ o Java). La transacción consiste en todas las operaciones que se ejecutan entre begin transaction y end transaction (Silberschatz, Korth, Sudarshan 2006). Para asegurar la integridad de los datos se necesita que el sistema de base de datos mantenga las propiedades de las transacciones como son atomicidad, consistencia, aislamiento y durabilidad (ACID: Atomocity, Consistency, Isolation and Durability) El acceso a la base de datos se lleva a cabo mediante las dos operaciones siguientes: leer(x), que transfiere el dato X, de la base de datos a una memoria intermedia local perteneciente a la transacción que ejecuta la operación leer. escribir(x), que transfiere el dato X, desde la memoria intermedia local de la transacción que ejecuta la operación escribir a la base de datos Ejecuciones concurrentes Los sistemas de procesamiento de transacciones permiten la ejecución de varias transacciones concurrentemente. Se debe asegurar la consistencia a pesar de la ejecución concurrente de las transacciones; las transacciones se ejecuten en secuencia, comenzado cada una sólo después de que la anterior se ha completado (Silberschatz, Korth, Sudarshan 2006). Sin embargo, existen 65

66 Revista Alghoritmic ISSN Pag 66 dos buenas razones para permitir la concurrencia se de. Supóngase, que los valores actuales de las cuentas A y B son $ y $ respectivamente. Supóngase, que las dos transacciones se ejecutan de una en una en el orden T1 seguida de T2. Esta secuencia de ejecución se representa mediante la Planificación 1 en la figura La secuencia de instrucciones aparece en orden con las instrucciones de T1 en la columna izquierda y las de T2 en la derecha. Los valores finales de las cuentas A y B, después de la ejecución 2.5, son de $ 855 y de $ respectivamente. De este modo, la suma total de saldo de las cuentas A y B, es decir, la suma A + B se conserva tras la ejecución de ambas transacciones. Figura Planificación 1, una planificación en la que T2 sigue a T1 3. METODOLOGÍA DE IMPLEMENTACION DEL SIMULADOR PROTOTIPO UTILIZANDO ALGORITMOS GENÉTICOS PARA OPTIMIZAR PROCESOS DE TRANSACCIÓN EN LA WEB 3.1 Análisis, diseño e implementación del sistema simulador La metodología para la implementación del simulador de transacciones orientando a la toma de decisiones del administrador de transacciones utilizando los algoritmos genéticos. Se utiliza los algoritmos genéticos para determinar que transacción se debe tomar para asignarlo en la cola de procesos. Se asumen, ciertas restricciones que el simulador tomará como dadas. Por ejemplo, cada transacción tiene un número constante de recursos que solicitan. Cada recurso tiene una cola que administra y solo se pueden hacer 2 tipos de requerimiento: leer y escribir. La estructura de un cromosoma consta de un grupo de alelos y cada uno corresponde con un recurso solicitado. El administrador de transacciones tomará el requerimiento por el recurso para ponerlo en cola, el que tenga un máximo de cromosoma igual a 1, es decir, cuando encuentre entre el grupo de transacciones la transacción que tenga sus alelos en 1. Se tomará como cromosoma una cadena binaria que será convertida a números enteros. La presente propuesta es en base al análisis de los modelos de transacciones que operan actualmente y se ha extraído tales mecanismos para llevarlo a un proceso de toma de decisiones en función de los algoritmos genéticos. 3.2 Supuestos y restricciones a) Supuestos Las transacciones son generadas por el usuario: - Recepcionado. Indica que el coordinador de transacciones ha tomado la solicitud. 66

67 Revista Alghoritmic ISSN Pag 67 - En cola. Indica que el administrador de transacciones lo esta atendiendo. - Atendido. Indica que la transacción se ha ejecutado. - No atendido. Indica que no se esta procesando - La cola de cada transacción es establecida por el usuario. - Las probabilidades de mutación y de cruzamiento son establecidos por el usuario. - El número de iteraciones y el número de alelos son establecidos por el usuario. - El administrador (despachador), asigna los procesos de manera secuencial a cada nodo, si hay cola disponible para almacenar los procesos en espera de ser atendidos y determina en función de los algoritmos genéticos, cual de los nodos va atender un proceso. - La generación de un proceso se basa en un valor aleatorio, conformado por un número entero cuyo rango máximo es la combinación máxima de la longitud del cromosoma. b) Restricciones Una transacción está conformada por un conjunto de procesos, cada proceso de una transacción solicita un recurso. Los recursos son fijos. El requerimiento por el recurso consta de 2 estados: read(r) y write(w). Un proceso ejecuta cualquiera de las 2 opciones. El sistema construye de forma aleatoria el requerimiento de (R) y (W) por cada proceso. Un read(r) se asume entrada en cola de manera directa. Un write(w) queda en espera de entrar en la cola hasta que el administrador de transacciones tome la decisión en función de los algoritmos genéticos, buscando que la transacción tenga un cromosoma con alelos 1. Cada transacción tiene un tiempo máximo de ejecución, pasado el tiempo, el coordinador de transacciones ejecuta un ROLLBACK. El tiempo máximo de uso del recurso por el proceso se genera de manera aleatoria y es como máximo el tiempo que tiene asignado la transacción. 3.3 Características y requerimientos del sistema En esta sección, se hace un breve resumen de características y requerimientos del sistema como: Existen un conjunto de transacciones que compiten. Las transacciones pueden escribir: write(w), read(r). Una transacción puede constar de un conjunto de procesos y cada una de ellas pueden hacer escritura o lectura para un conjunto de recursos. El modelo debe cumplir con las propiedades que certifican una transacción valida: atomicidad, consistencia, aislamiento y durabilidad. Existe un conjunto de procesos de distintas transacciones que esperan por un recurso. Una transacción puede solicitar varios recursos. Una transacción involucra la solicitud de varios recursos. Una transacción queda en espera cuando no ha obtenido todos los recursos. Cada recurso mantiene una cola de atención. Se definen los recursos como páginas por procesar. Solo un proceso a la vez puede usar el recurso. Mientras este asignado, nadie puede tomar hasta que sea liberado por el proceso. El sistema libera un recurso si tiene mucho tiempo en espera, en este caso, la transacción aborta. Se usa un modelo pesimista esperando obtener todos los bloqueos. El coordinador de transacciones ejecuta la administración de las transacciones y coordina que transacción debe realizarse. Ejecuta la toma de decisiones usando algoritmos genéticos para decidir que transacción es seleccionada para acceder a la cola del recurso. Asimismo, que la transacción finalmente se ejecutará y tiene la posesión de todos los recursos. La configuración de una transacción involucra el tiempo que solicita un recurso. Si una transacción tiene la siguiente configuración: solicita recursos ABCDEF, a su vez se indica el tiempo que solicita por cada recurso. Cada recurso tiene una cola, cuando un proceso toma el recurso, no involucra que se ejecutará, el proceso debe esperar por los demás recursos. El 67

68 Revista Alghoritmic ISSN Pag 68 tiempo máximo que un proceso espera es el tiempo que requiere la transacción para ejecutarse. Si excede este tiempo, el proceso se descarta y la transacción se aborta. El coordinador de transacciones ejecuta un ROLLBACK. Una transacción descartada va a un repositorio de transacciones descartadas. Una transacción exitosa implica que ha tomado todos los recursos y ha ejecutado la operación con el tiempo máximo permitido dado por el tiempo de la transacción. Si un recurso acepta un requerimiento y lo pone en la cola del recurso, el cromosoma de la transacción cambia el alelo a 1, en caso contrario se mantiene en 0. Los estados de una transacción pueden ser: Rechazada. No existe cola para procesamiento, las colas están saturadas. No ejecutado. Aun el coordinador de transacciones no ha tomado acción sobre la solicitud. a) Requerimientos del sistema: Sistema operativo: Windows XP, Windows Vista, Windows Server 2003, Windows Server b) Requerimientos para simulador prototipo: Memoria: 512 Mb (o superior) RAM, Disco: 2 Mb. c) Herramientas de desarrollo: Compilador: Codegear 2009 Builder C++ de Borland, Lenguaje: C++, Diagramador de procesos: Visio Análisis y diseño del sistema simulador En esta sección, se hace un breve resumen de análisis y diseño del sistema simulador como: 1. Variables: Tiempo de respuesta de actualización, lectura, adición, Modelo de cola. La transacción pasa a una cola, Modelo de procesamiento a disco de la transacción, Arquitectura del sistema de base de datos: paralelo, multihilo, multiproceso, distribuido. 2. Arquitectura en paralelo: Memoria compartida, Disco compartido, Sin compartimiento, Jerárquico. Combinación de memoria y disco, 3. Protocolo de concurrencia. Pesimista y optimista 4. RESULTADOS 4.1 Presentación del sistema El sistema consta de un conjunto de pasos para llegar a ejecutarlo, está organizado de manera secuencial. Primero, se debe asignar la información para la opción Cargar configuración que esta incluido en la configuración inicial del sistema. En la opción de Ejecución puede iniciar el proceso de simulación y ver el reporte de salida en la opción Reportes. Se muestra en la figura ventana principal del simulador, título denominado Simulador de Transacciones que contiene las pestañas de: Configurar, Ejecutar, Reporte, Acerca del sistema. Más abajo está la ventana de los Parámetros del sistema, y otra ventana para la Lista de transacciones y otros. 68

69 Revista Alghoritmic ISSN Pag 69 Figura Ventana principal del simulador. 4.2 Cargar configuración del sistema Este es el paso inicial, en la ventana principal las opciones están inicializadas con ceros cada una. Hacer clic en Cargar configuración y aparecerá la ventana Open. Seleccionar la opción testtransacciones.sim y se muestra en la figura ventana Open, y hacer clic sobre él, y se muestra en la figura la ventana de parámetros del sistema siguiente: 69

70 Revista Alghoritmic ISSN Pag 70 Figura Ventana Open. 70

71 Revista Alghoritmic ISSN Pag 71 Figura Ventana de parámetros del sistema. De la figura los parámetros del sistema que contiene los datos iniciales para ejecutar el simulador propuesto como: Tiempo de simulación : 30 segundos. Número de transacciones : 16. Tiempo de la transacción : 6. Número de recursos : 4. Longitud de la cola del recurso: 8. Probabilidad de cruzamiento : 0,09. Probabilidad de mutación : 0,01. 71

72 Revista Alghoritmic ISSN Pag Inicializar Hacer clic en el botón Inicializar y aparecerá la ventanita de Lista de transacciones que contiene datos de: identificación de transacción, estructura de requerimiento y tiempo; R significa lectura y W significa escritura para sistema. Se muestra en la figura lista de transacciones, siguiente: Figura Lista de transacciones. 4.4 Ejecución Pulsar la pestaña de Ejecución y aparecerá la ventana de ejecución, se muestran 3 bloques. El primer bloque es parámetros del sistema, este bloque muestra los datos iniciales para ejecutar la transacción. El segundo bloque muestra las colas de recursos, es la administración de colas de transacción del simulador. 72

73 Revista Alghoritmic ISSN Pag 73 El tercer bloque muestra las transacciones, es la administración de ejecución de transacciones del simulador y se muestra en la figura transacciones, siguiente: Figura Transacciones. Hacer clic en el botón Iniciar para ejecutar la transacción. Se muestra en la figura la terminación del proceso de transacciones. Por ejemplo, en la ventanita de parámetros del sistema, se observa la variación de los datos iniciales, las colas de recursos, los datos, en las transacciones y el estado. 73

74 Revista Alghoritmic ISSN Pag 74 Figura Terminación de procesos transacciones. Por ejemplo, en atendidos todos tienen 8, asimismo en cromosomas todos tienen 15 (1111 = 15), en estado, 8 atendidos y en rechazados 8 que no han cumplido las condiciones. El sistema muestra en línea la evolución de la simulación. Está se envía a un reporte de salida. Se puede guardar el reporte en un archivo de texto. Seleccionando el botón Guardar para salvar reporte. En reportes se ha considerado solo las transacciones procesadas como óptimos. De este modo, se ha implementado un simulador prototipo utilizando algoritmos genéticos para optimizar procesos de transacciones en la web ; para el estudio Base de Datos Distribuidos Usando Algoritmos Genéticos Para Optimización de Proceso Transacción en la Web, que permitirá mejorar la asignación de transacciones de datos en el servidor, menor costo de recursos computacionales y el resultado devolverá a los usuarios / clientes en menor tiempo de procesos de transacciones, esté se realizará a través de despachador del sistema local y/o remoto. 5. CONCLUSIONES De estudio Base de Datos Distribuidos Usando Algoritmos Genéticos Para Optimización de Proceso Transacción en la Web, se puede obtener las siguientes conclusiones: 1.- La evolución de Internet ha llegado a una alta proliferación y rendimiento en consultas de informaciones en el servidor Web por usuarios / clientes que usan base de datos distribuidos. 74