alghoritmic - Facultad de Ingeniería de Sistemas e Informática

Transcripción

Revista Alghoritmic
ISSN 2220-3982 Pag 1
º
Vol. 1 N 1
ISSN
2220-3982
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 2220-3982 Pag 1
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 Pag 3
Universidad Nacional Mayor De San Marcos
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
Decano
Mg.Carlos Navarro Depaz
Instituto de Investigación de Ingeniería de Sistemas e Informática
Director
Mg. Augusto Cortez Vásquez
Comité Editorial
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
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 1 2010
ISSN 2220-3982
versión impresa
Lima-Perú
E mail: [email protected]
Home Page http://www.sistemas.unmsm.edu.pe
Telefono 6197000-3604
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
Revista Alghoritmic
ISSN 2220-3982 Pag 4
Vol. 1 N 1
Agosto- Diciembre 2010
Lima-Perú
ISSN 2220-3982
INDICE
Presentación
1. Ingeniería dirigida por Modelos
Espinoza Robles Armando David ,Trujillo Trejo John Ledgard,
7
2. Modelamiento matemático de un servidor de correo electrónico
Félix Armando Fermín Pérez
21
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
Horarios
Gilberto Salinas Azaña
37
5. Servicios web utilizando ASP
Santiago Moquillaza Henríquez, Percy de la Cruz Velez de Villa,
45
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
Revista Alghoritmic
ISSN 2220-3982 Pag 5
Vol. 1 N 1
January - July 2010
Lima-Perú
ISSN 2220-3982
ISSN
versión impresa
Electronic version
INDEX
Presentation
1.
Model Driven Engineering
7
2.
Mathematical modeling of a mail server
21
3.
Rules-based reasoning systems for refractive surgery is recommended
28
4.
Multiagent System for Generating System Implementation Schedule
37
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
processing on the web
56
Instructions for submission of articles
77
5
Revista Alghoritmic
ISSN 2220-3982 Pag 6
Ingeniería dirigida por Modelos
Model Driven Engineering
Universidad Nacional Mayor de San Marcos
Facultad de Ingenieria de Sistemas e Informatica
[email protected], [email protected],
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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
2
ISSN 2220-3982 Pag 8
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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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 51-100 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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
HTML
LATEX
Make
SQL
VHDL
ISSN 2220-3982 Pag 12
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
Revista Alghoritmic
SPARK
Spring
Stratego
TXL
ISSN 2220-3982 Pag 13
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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 Pag 15
Tabla 3: Ejemplos de DSL desarrollados usando los sistemas de la Tabla 2 [7]
Sistema
DSL
Dominio de la
Usado
Aplicación
ASF+SDF
Box
Prettyprinting
Risla
Producto
Financiero
Asml
UPnP
Protocolos de
XLANG
dispositivos de
Red
Protocolos de
Negocios
Eli
Maptool
Mapeo de
(Various)
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
Hoof
Especificaciones
IMDL
de compilador IR
Reingeniería de
software
SPARK
Guide
Programación en
CML2
la Web
Configuración de
sistema
Sprint
GAL
Drivers de
PLAN-P
dispositivos de
Video
Protocolos de
aplicación
especifica
Stratego
Autobundle Construcción de
CodeBoost Software
Optimización de
C++ en un
dominio
especifico
15
Revista Alghoritmic
3
ISSN 2220-3982 Pag 16
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
2.0.0 Eclipse and EMF template-based
System for MDA generation.
AndroMDA
Open source
3.2
ADT
Open source
AToM3
Open source
DSL Tools (Visual
Studio 2005 SDK)
Kermeta
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 2005.
0.4.1 A metamodeling language which allows describing both the structure
and the behaviour of models.
1.0.1 A tool that provides a framework For building application.
ModFact
GPL-Open source
Merlin
0.5.0 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 plugOpen source
in based on modelling and code generation.
MOFLON
1.1.0 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
0.1.4 A model transformation tool based on QVT-Operational language.
Open source
UMLX
0.2.0 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
Revista Alghoritmic
4
ISSN 2220-3982 Pag 17
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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 Pag 19
Tabla 7 herramientas IDM en términos de otras operaciones.[3]
Herramienta
Repositorio
Interoperabilidad
Metamodelo Modelo
Restricci
transformac ó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
DSLXML / 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,
Eclipse
XSLT
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
Revista Alghoritmic
ISSN 2220-3982 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. 316-344, 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 2004
2) 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
Revista Alghoritmic
ISSN 2220-3982 Pag 21
Modelamiento matemático de un servidor de correo electrónico
Mathematical modeling of a mail server
Universidad Nacional Mayor de San Marcos, FISI
Av. Germán Amézaga s/n Lima 1, Lima, Perú
[email protected]
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
Revista Alghoritmic
ISSN 2220-3982 Pag 22
1. 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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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:
donde y(k)
u (k)
A, B
k
(1)
: variable de salida
: variable de entrada
: parámetros de autoregresión
: 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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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, 2004.
[3] S. Keshav. Control-theoretic approach to flow control. ACM SIGCOMM Computer
Communication Review [En línea], 1991, 21(4): 3-15. Disponible en
http://doi.acm.org/10.1145/115994.115995
[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: 1510-1519. Disponible en
http://dx.doi.org/ 10.1109/INFCOM.2001.916647
[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): 242-283. Disponible en http://dx.doi.org/ 10.1147/sj.362.0242.
[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): 779-793.
Disponible en http://dx.doi.org/10.1109/TPDS.2008.41
[7] J Hellerstein. Challenges in Control Engineering of Computing Systems. Proceedings of
the 2004 American Control Conference, [En línea], 2004, 3: 1970-1979. Disponible en
http://dx.doi.org/10.1109/ACC.2004.182391
[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): 127-141. Disponible en
http://dx.doi.org/10.1023/A:1015350520175
27
Revista Alghoritmic
ISSN 2220-3982 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
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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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.
Ct11, Ct12,… C t1n
Así
At11, At12,… A t1n
(Lista de clausula a verificar,
Condición
Lista de Acciones a ejecutar)
Acción
31
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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.
¿Astigmatismo
?
≤
6
si
no
¿Miopía?
¿Edad?
≤1
85
>
6
SI
>45
>18 y ≤
45
¿Miopía?
NO
NO
NO
≤1.5
>1
0
>1.5 y ≤
10
NO
¿Diabetes?
NO
si
no
SI
NO
33
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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
2004.
[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 2005
36
Revista Alghoritmic
ISSN 2220-3982 Pag 37
Sistema de Multiagentes para Implementación de Sistema Generación de
Horarios
Multiagent System for Generating System Implementation Schedule
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
Revista Alghoritmic
ISSN 2220-3982 Pag 38
Keywords: multiagent systems, generation schedules
38
Revista Alghoritmic
ISSN 2220-3982 Pag 39
1. 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
Revista Alghoritmic
ISSN 2220-3982 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
N
O
DOCENTES
N
O
SI
CURSOS
N
O
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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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, GameTheoretic, 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, 2005.
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. 2006.
Fabio Luigi Bellifemine, Giovanni Caire, Dominic Greenwood. Developing MultiAgent Systems with JADE. Wiley, 2007.
Hong Lin. Architectural Design of Multi-Agent Systems: Technologies and
Techniques. IGI Global, 2007.
Stefan Kirn, Otthein Herzog, Peter Lockemann, Otto Spaniol. Multiagent Engineering:
Theory and Applications in Enterprises. Springer. 2006
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, 2002
44
Revista Alghoritmic
ISSN 2220-3982 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,
[email protected], [email protected], [email protected],
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
Revista Alghoritmic
ISSN 2220-3982 Pag 46
1.- 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
Revista Alghoritmic
ISSN 2220-3982 Pag 47
2. 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>987654321</Teléfono1>
<Celular>987654321</ Celular >
</Elemento>
<Elemento>
<Nombre>PERCY DE LA CRUZ VELEZ DE VILLA</Nombre>
</Elemento>
<Elemento>
<Nombre>HUGO VEGA HUERTA</Nombre>
47
Revista Alghoritmic
ISSN 2220-3982 Pag 48
</Elemento>
<Elemento>
<Nombre>EVA VASQUEZ VALLE</Nombre>
</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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 Pag 50
3. 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
Revista Alghoritmic
ISSN 2220-3982 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:="http://tempuri.org/")> _
<WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1)> _
<Global.Microsoft.VisualBasic.CompilerServices.DesignerGenerated()> _
Public Class LEERDATOS
Inherits System.Web.Services.WebService
Private CONEXION As String="SERVER=SANTIAGOF13B31\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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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: 1-861005-55, 2002.
[2] Jorge Serrano Pérez, Manual Avanzado Visual Basic.Net impreso en España
Ediciones Anaya, ISBN:84-415-1445-3
[3] Francisco Charte Ojeda, Programación de Base de Datos con Visual Basic.Net Mdrid-España ISBN:84-415-1375-9.2002.
54
Revista Alghoritmic
ISSN 2220-3982 Pag 55
[4] Luís Miguel Blanco Programación en Visual Basic.Net - Grupo EIDOS, Madrid
(España), ISBN 84-88457-53-7, 2002.
55
Revista Alghoritmic
ISSN 2220-3982 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
[email protected]
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
Revista Alghoritmic
ISSN 2220-3982 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
2.1.1 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.
2.1.2 Evolución biológica
57
Revista Alghoritmic
ISSN 2220-3982 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 2.1.1 célula :
Figura 2.1.1 Célula.
2.1.3 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.
2.1.4 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.
2.1.5 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
Revista Alghoritmic
ISSN 2220-3982 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: 10001 y del padre 2, se toma los 6 bits últimos que son: 100011 y
se une ambos bits; entonces se tiene la cadena nueva 1 que son los siguientes bits: 10001100011
resultado del cruzamiento basado en un punto. Del mismo modo, del padre 2 se toma los 5 primeros bits
que son: 01101 y del padre 1 se toma los 6 últimos bits que son: 001111 y se une ambos bits; entonces,
se tiene la cadena nueva 2 que son el siguiente conjunto de bits: 01101001111 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 2.1.3 siguiente:
59
Revista Alghoritmic
ISSN 2220-3982 Pag 60
La cadena vieja
11000101110
La cadena nuena 11001101110
TABLA 2.1.3 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 2.1.4.
La cadena vieja
La cadena nuena
1011001110
1000111110
Tabla 2.1.4 Inversión de un segmento de la cadena binaria.
2.1.5 Funcionamiento de los algoritmos genéticos
Se parte de una función f(x) muy sencilla de: f ( x)
x2
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:
ción de cromosoma.
Figura 2.2.4 Operación de Cromosoma
60
Revista Alghoritmic
ISSN 2220-3982 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 2.1.5
(1)
(2)
(3)
(4)
(5)
1
(0,1,1,0,0)
12
144
6
2
(1.0.0,1,0)
18
324
3
3
(0,1,1,1,1)
15
225
2
4
(1,1,0,0,0)
24
576
5
5
(1,1,0,1,0)
26
676
4
6
(0,0,0,0,1)
1
1
1
Tabla 2.1.5 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
Revista Alghoritmic
ISSN 2220-3982 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 =324.3. 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
2.3.1 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 2.3.1 la conmutación de mensajes /paquetes en una
LAN siguiente:
Figura 2.3.1 Conmutación de mensajes /paquetes en una LAN
2.3.2 Ventajas y desventajas de sistemas distribuidos
62
Revista Alghoritmic
ISSN 2220-3982 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,
Servicios de replicación de datos y servicios con
compartición de recursos, el sistema se puede recuperar
posibilidades de fallas
de una falla.
Eficiencia, flexibilidad, disponibilidad y confiabilidad de los
Interconexión: fiabilidad posible perdida de mensajes y
sistemas distribuidos.
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 2.3.1 Ventajas y Desventajas de los Sistemas Distribuidos
2.4. BASES DE DATOS DISTRIBUIDOS
2.4.1 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.
2.4.2 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
Revista Alghoritmic
ISSN 2220-3982 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 2.4.1 BDDH:
Figura 2.4 Base de Datos Distribuidos Homogéneos
64
Revista Alghoritmic
ISSN 2220-3982 Pag 65
Figura 2.4.1 Base de Datos Distribuidas Homogéneas (BDDH)
2.4.3 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.
2.5. GESTIÓN DE TRANSACCIONES
2.5.1 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.
2. 5.2 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
Revista Alghoritmic
ISSN 2220-3982 Pag 66
dos buenas razones para permitir la concurrencia se de. Supóngase, que los valores actuales de
las cuentas A y B son $ 1.000 y $ 2.000 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 2.5.1. 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 $ 2.145
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 2. 5.1 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
Revista Alghoritmic
-
ISSN 2220-3982 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
Revista Alghoritmic
ISSN 2220-3982 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 2008.
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 2007.
3.4 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
4.1.1 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
Revista Alghoritmic
ISSN 2220-3982 Pag 69
Figura 4.1.1 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 4.1..2 ventana Open, y hacer clic sobre él, y se muestra
en la figura 4.1.3 la ventana de parámetros del sistema siguiente:
69
Revista Alghoritmic
ISSN 2220-3982 Pag 70
Figura 4.1.2 Ventana Open.
70
Revista Alghoritmic
ISSN 2220-3982 Pag 71
Figura 4.1.3. Ventana de parámetros del sistema.
De la figura 4.1.3 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
Revista Alghoritmic
ISSN 2220-3982 Pag 72
4.3 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 4.1.4 lista de transacciones, siguiente:
Figura 4.1.4. 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
Revista Alghoritmic
ISSN 2220-3982 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 4.1.5 transacciones, siguiente:
Figura 4.1.5. Transacciones.
Hacer clic en el botón Iniciar para ejecutar la transacción. Se muestra en la figura 4.1.6 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
Revista Alghoritmic
ISSN 2220-3982 Pag 74
Figura 4.1.6.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
Revista Alghoritmic
ISSN 2220-3982 Pag 75
2.- Existen algunas deficiencias en el procesos de transacciones 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, etecetera.
3.-El estudio se orienta al crecimiento y, evolución del servidor web de una manera económica
y escalable que lleva a un rendimiento óptimo. Por lo que se requiere aplicar otra alternativa
como los algoritmos genéticos para optimizar el proceso de transacción
4.-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.
5.-Se ha realizado un 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.
6.-La implementación del simulador prototipo para un sistema de aplicación con algoritmos
genéticos, para optimizar el proceso de transacción, permite optimizar: tiempo de
procesamiento de datos, mediante el simulador es menor que el tiempo de procesamiento de
datos en un procesador convencional, por consiguiente mejor uso del recurso de la
computadora.
REFERENCIAS BIBLIOGRÁFICAS
1. ARAUJO CÁRDENAS, Alfonso. Sistemas Distribuidos, Conceptos y Características, 2004.
2. BUADES, G, Sistemas Distribuidos. Departamento de Investigación de Ingeniería Informática
de la UIB, 2002.
3. DARWIN, Charles ,Teoría Biológica Sobre la Evolución. Inglaterra, investigación científica,
1930.
4. DAVIS, L. Manual de Algoritmos Genéticos. Van Nostrand Reinhold, Nueva York, 1991.
5. GARCIA Carballeira F. Sistemas Distribuidos. Departamento de Investigación de Telemática,
1999.
6. HOLLAND, John H. Compendio del Algoritmo Genético. Universidad de Michigan, vol. 7, Nº
22, 1975.
7. ttp://www.inforg.uniovi.es/ia/Archivos/Apuntes%20y%20t/AlgoritmosGeneticos.pdf.
8. HURTADO JARA, O.Sistemas Distribuidos. España, Departamento de Investigación de la
Universidad Carlos III de Madrid, [email protected], 1997.
9. KWAN, T. T., MCGRATH, R. E. y REED, D. A. Modelos de Accesos de Usuarios al Servidor
de Web de NCSA. Informe Técnico de UIUCDCS-R-95-1934, dpto. de Comp. Sci., Univ. de
IL, feb.1995.
10. SILBERSCHATZ, Abraham; KORTH, Henry y SUDARSHAN, S. Fundamentos de Bases de
Datos. España, quinta edición, McGraw Hill, 2006.
11. TANENBAUM, A. S. Sistemas Operativos Distribuidos. México, Prentice Hall
Hispanoamericana, S. A., 1996.
12. TANENBAUM, A. S.
S. A., 1997.
Redes de Computadoras. México, Prentice Hall Hispanoamericana
75
Revista Alghoritmic
ISSN 2220-3982 Pag 76
PROGRAMAS Y LÍNEAS
Aprobado por Consejo de Facultad en Sesión de 03 de Diciembre de 2009
RD N. 0404-D-FISI
BASE LEGAL
Ley Universitaria
Estatuto de la UNMSM
RR 05680-R-08 Reglamento de Actividades de Investigación
-
Programa 1
ALGORITMOS Y COMBINATORIA
P1.1 Optimización Combinatoria
P1.2 Complejidad Computacional
P1.3 Algoritmos y Estructura de Datos
-
Programa 2
REDES Y SISTEMAS DISTRIBUIDOS
P2.1 Procesamiento Paralelo
P2.2 Sistemas Distribuidos
P2.3 Computación GRID
-
Programa 3
BASE DE DATOS
P3.1 Minería de Datos
P3.2 Datawarehouse e Inteligencia de Negocios
-
Programa4
COMPUTACIÓN GRAFICA Y PROCESAMIENTO DE
IMAGENES
P4.1 Geometría Computacional
P4.2 Procesamiento de Imágenes
-
Programa 5
INGENIERÍA DE SOFTWARE
P5.1 Tecnologías Open Source y Software Libre
P5.2 Proceso de Desarrollo de Software
P5.3 Ingeniería de Software dirigido por modelos
-
Programa 6
INTELIGENCIA ARTIFICIAL
P6.1 Redes Neuronales
P6.2 Sistemas Expertos
-
Programa 7
SISTEMAS, INFORMÁTICA Y SOCIEDAD
P7.1 Gestión del Conocimiento
P7.2 Redes Sociales
P7.3 Seguridad y Auditoria Informática
76
Revista Alghoritmic
ISSN 2220-3982 Pag 77
INSTRUCTIVOS PARA LA PRESENTACION DE ARTICULOS
La Revista Alghoritmic es una publicación científica editada por el Instituto de
Investigaciones de Ingeniería de sistemas e Informática, Facultad de Ingeniería de Sistemas
e Informática, Universidad Nacional Mayor de San Marcos, Lima Perú. Tiene una
periodicidad semestral, y se publica tanto en su versión impresa como digital.
La Revista Alghoritmic recibe artículos completos, 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, elaborados según las normas indicadas en las presentes
intructivos.
El articulo deberá ser presentado acompañado de una carta dirigida al Editor Responsable,
firmada por el responsable del trabajo con quien se tendrá comunicación, indicando además
el carácter indedito, original y completo del articulo presentado y su disposición para que
sea revisado y editado.
Las publicaciones pueden estar dentro de las categorías:
1. TRABAJOS ORIGINALES. Artículos inéditos que presentan resultados de trabajos de
investigación y constituye aportes al conocimiento. Todo el artículo debe tener como
máximo 12 páginas, las ilustraciones deben ser solo las necesarias para una mejor
exposición de los resultados.
1. NOTAS CIENTÍFICAS. Reportes de resultados cuya información es de interés para la
comunidad científica. La extensión del texto no será mayor de 6 páginas.
1. ARTÍCULOS DE REVISIÓN. Trabajos que constituyen una exhaustiva revisión del tema
de investigación del autor, se incluyen aquí tesis, revisiones taxonómicas y
recapitulaciones.
REDACCION DEL ARTICULO
GENERALIDADES
1. El
documento
deberá
redactarse
cumpliendo
lo
siguiente:
a) Idioma :
Español , utilizando Microsoft Word
b) Formato :
A4 , tipo de letra : Time New Roman 12
c) Márgenes:
25 mm, a espacio y medio (con excepción de los cuadros).
Izquierda 30 mm y derecha 25 mm.
d) Numeración : Inicie con el numero 1, consecutivamente en la parte central
inferior de cada página.
2
Los títulos principales (encabezados de cada sección: Resumen, Abstracto, Introducción,
Material y Métodos, Resultados, Discusión y Literatura Citada) van centrados, en
mayúsculas, y en negrita.
77
Revista Alghoritmic
ISSN 2220-3982 Pag 78
3
Los títulos de primer orden se colocan en negrita, en mayúsculas tamaño 12, al margen
izquierdo, en renglón separado, y sin puntuación final. El texto que se le sigue se ubica en
párrafo aparte. Los títulos de segundo y tercer orden se colocan en cursiva, al margen
izquierdo, en minúscula. Pueden ir en renglón separado sin puntuación final, o al inicio de
la primera línea del párrafo, seguidos de un punto.
4
Los párrafos se justifican a ambos lados y se separan entre sí con un renglón en blanco.
5
Utilice frases breves y precisas en la redacción del documento, con los verbos en forma
activa y evitando el uso de la primera persona.
6
Los cuadros y figuras se ordenan con numeración arábiga y con los títulos autoexplicativos, de manera consecutiva en cada articulo y en la parte inferior.
7
Los nombres Científicos, productos y herramientas tecnológicas se colocan en cursiva.
8
En caso que el articulo exponga sobre experimentos con humanos y animales, los
procedimientos deberán de ceñirse a la Declaración de Helsinki de 1975 y a las leyes
peruana vigentes (Ley 27265), debiendo presentarse las declaraciones pertinentes y
mencionadas en el texto.
Página Inicial
1. La primera página del documento deberá contener:
a) Título del articulo en español e inglés,
b) Titulo corto,
c) Nombre y apellidos de cada autor y, al pie, su afiliación institucional, correo
electrónico,
2 El Titulo deberá:
a) Contener a lo mas 20 palabras
b) Identificar el contenido real del estudio.
c) Ser descriptivo, breve y claro
d) No contener siglas ni abreviaciones.
e) El titulo corto es un titulo abreviado, no mayor de 80 caracteres incluyendo
espacios, que aparecerá en la parte superior de las páginas impares del trabajo
publicado.
3 El Autor
Deberá haber participado lo suficiente como para asumir la responsabilidad publica del
contenido del trabajo. Además, debe haber contribuido en forma sustancial en:
a) La concepción y el diseño del estudio, o en el análisis y la interpretación de los
datos;
b) La redacción del artículo o la revisión critica de una parte sustancial de su
contenido intelectual; y
c) La aprobación final de la versión que será publicada.
Resumen
1. El Resumen deberá contener el resumen en español seguido del abstract en inglés
conteniendo la misma información que el resumen.
2 El Resumen deberá estar contenido en una sola pagina
3 El resumen deberá contener los objetivos, procedimientos, resultados principales y las
conclusiones de la investigación en un solo párrafo, no mayor de 300 palabras y en forma
clave y concisa.
78
Revista Alghoritmic
4
ISSN 2220-3982 Pag 79
No puede contener cuadros, figuras, citas bibliograficas, ni abreviaturas o acrónimos, salvo
que sean de uso común o se definan en el mismo Resumen.
Palabras claves
Después del Resumen (y del Abstract), dejando un renglón en blanco, escriba 4 a 6 palabras
claves (key words) para efectos de indización. Estas deberán ser colocadas en minúscula, a
excepción de nombres propios, separadas por comas y sin puntuación final.
Introducción
Deberá cumplir lo siguiente
a) Describir la naturaleza del problema en estudio,
b) Presentar trabajos relacionados o realizados por otros autores en el campo bajo
estudio.
c) Indicar como se pretende solucionar el problema, de que manera se aumenta el
acervo de conocimientos existentes sobre el tema.
d) Utilizar no más de tres referencias para apoyar un concepto o idea.
Materiales y Métodos
En caso se utilice, deberá indicarse:
1. Materiales : Describir el objeto de estudio, sus características, la localización geográfica y
periodo del estudio, así como los mecanismos utilizados para el desarrollo del trabajo,
incluyendo la forma de recolección de datos, el diseño experimental (si lo tuviera) y el tipo
de análisis estadístico utilizado.
2 Métodos : Indicar los métodos, proporcionando las referencias cuando sean necesarias y lo
equipos de importancia utilizados.
3 Técnicas : Usar referencias para las técnicas utilizadas, o describa en detalle si son nuevas
o han sido modificadas.
Resultados
1
2
3
4
5
Deberá:
Presentar los resultados y una discusión de los mismos
Presentar la información en forma de texto, cuadros y figuras, y siguiendo una secuencia
lógica.
Describir los hallazgos encontrados y el resultado de los análisis, apoyado con cuadros y
figuras.
No repita en el texto los datos de los cuadros o figuras, sino resalte o resuma las
observaciones más importantes. No repita conceptos indicados en la metodología.
Puede combinarse la sección de resultados con la Discusión
Discusión
1
2
3
4
Deberá:
Explicar el significado de los resultados con el apoyo de referencias bibliográficas, así
como sus implicancias en futuras investigaciones. Compare las observaciones realizadas
con aquellas de otros estudios pertinentes. Enfatice en aspectos nuevos e importantes del
estudio y en las conclusiones que se deriven de ellos.
Discutir las implicancias teóricas o prácticas del estudio.
Evitar afirmaciones o conclusiones insuficientemente avaladas por los datos o con
resultados sin soporte estadístico.
No repetir los datos de información presentada en las secciones previas.
79
Revista Alghoritmic
ISSN 2220-3982 Pag 80
5 No hacer afirmaciones sobre costos o beneficios económicos, salvo que en el trabajo se
incluyan datos y análisis económicos.
Conclusiones
1
2
3
Presentar en forma muy breve los principales hallazgos y planteamientos que fueran
producto del estudio. Use viñetas si se tiene varias conclusiones.
Evitar conclusiones y opiniones personales que no estén respaldadas por los datos
presentados.
No sugiera continuar investigando sobre el tema. Esto no constituye una conclusión.
Agradecimientos
De haberlas:
Reconocer la ayuda de personas e instituciones que aportaron significativamente al
desarrollo de la investigación, así como la entidad que financió el estudio.
Literatura Citada
Las referencias son importantes en todo trabajo académico pues indican al lector las
distintas fuentes de sus citas o ideas trabajadas en su investigación. El mundo académico es
sumamente estricto en este sentido y una falta al indicar las fuentes equivale a plagio (o
hurto literario). En este sentido, el propósito de un sistema de referencias es describir las
fuentes de manera exacta y rigurosa, para indicar -en el mismo trabajo- dónde y cómo
fueron empleadas.
Deberá:
1
2
3
4
Ordenarse alfabéticamente por el apellido del autor. El formato requiere que los títulos de
libros, diarios, etc. sean destacados utilizando tipografía itálica (conocida también como
cursiva). Si tiene dos o mas referencias de los mismos autores se ordenan por año de
publicación; si estos están publicados en el mismo año se ordenan por orden alfabético de
los títulos de los artículos, agregando un sufijo al año de publicación (por ejemplo, 2005ª,
2005b); y si tiene dos o mas referencias del mismo año de publicación y con tres o mas
autores, donde el primer autor es el mismo, se les agrega el sufijo al año de publicación
como en el caso anterior.
Limitar el número de referencias a las más pertinentes o de mayor actualidad.
Solo la primera palabra y los nombres propios en los títulos de las publicaciones van en
mayúscula.
Evitar citar resúmenes y literatura de publicaciones que no sean científicas.
Libros
La información para citar un libro usualmente esta consignada al inicio de la obra, en el
reverso de la página del título. Asegúrese de identificar correctamente el nombre la casa
editorial y no confundirla con el de la imprenta. Esta es una información muy importante en
su lista de referencias. El Catálogo de su Biblioteca le proporcionará el nombre de la
editorial si tuviese alguna duda. No considere las fechas de reimpresión; lo que debe
considerar es la fecha en que se publicó la primera, segunda o la tercera edición de la obra,
la misma que debe corresponder con la edición que esté empleando en su trabajo. En
algunos casos, es importante señalar la fecha de la primera edición o versión original del
libro.
Moran Cortez, Enma Teolinda, Pearson H. 2001. Compactacion de memoria, 6ª ed. Madrid:
McGrawHill. 150p.
Artículos de Revistas Científicas
80
Revista Alghoritmic
ISSN 2220-3982 Pag 81
La información necesaria para citar un artículo de revista puede encontrarse, generalmente,
en el índice, portada o en el artículo mismo.
Canepa Suarez JL, Wheaton JE. 2007. Tecnicas de modelamiento de datos. J Anim Sci
85:3249-3255.
Lam HM, Zhang QF. 1994. Risk assessment of nickel carcinogenicity and occupational lung
cancer. Environ Health Perspect 102 (Suppl.l):275-282.
Fuentes electrónicas
El patrón básico para una referencia electrónica es:
Autor, inicial(es) de su nombre (año). Título. Mes, día, año, de la dirección en
Internet.
Bancos, I. (n.d.). Las redes neuronales y la solución de problemas del sector salud. Obtenida
el 29 de agosto de 2008, de http://www.coreguide.direct.nhs.uk/
Si no consigue identificar la fecha en que el documento fue publicado, utilice la abreviatura
n.d. (no date [sin fecha]).
Si no consigue identificar al autor, empiece su referencia con el título del documento.
Si el documento se ubica dentro de una página institucional, como la de alguna universidad
o departamento gubernamental, primero cite el nombre de la organización o del
departamento en cuestión, antes de dar la dirección electrónica:
Cortez Vasquez , A., & Villen, J. A. (2003). Evaluando las Fuentes Electrónicas.
Consultado el 21 de agosto de 2001, Widener University, página web conmemorativa de la
biblioteca Wolfgram: http://www.ridener.edu/ Library/webevaluation / webeval.htm
Construyendo una idea. (2005). Consultado el 5 de septiembre de 2001, Portsmouth
University, página web de Servicios Profesionales:
http://www.port.ac.uk/departments/careers/plancareer/deciding-your-future.htm
Artículos electrónicos de revistas científicas que a su vez son reproducción de la
versión impresa
Emplee el mismo formato de referencia que utiliza para un artículo de revista científica
impresa y agregue "versión electrónica" entre corchetes, después del título del artículo:
Huerta Vega, Hugo. (2001). Un modelo de sistemas expertos para dietas caseras
[versión electrónica ]. Journal of Common Market Studies, 39(3), 228- 239.
Si tiene que citar un artículo electrónico cuya versión se diferencia de la versión
impresa, o incluye datos o comentarios adicionales, debe agregar la fecha en que
usted consultó el documento en la web y su respectiva dirección (URL).
Artículos de revistas científicas que sólo se publican en la web.
Utilice la fecha completa de publicación que figura en el artículo.
Cerciórese de que no tenga paginación.
Siempre que sea posible, procure que la dirección electrónica que cite (URL) remita
directamente al artículo.
Evite citar una dirección electrónica en dos líneas y cuide que el enlace (URL) no se
corte después de un guión o antes de un punto. No inserte guiones en el enlace
cuando esto ocurra.
Korda, L. (2001, Julio). La fabricación de un traductor. Translation Journal, 5(3).
Consultada el 21 de agosto de 2001, http://accurapid.com/journal/17prof.htm
81
Revista Alghoritmic
ISSN 2220-3982 Pag 82
Artículos obtenidos de una base de datos
Utilice el formato apropiado al tipo de trabajo obtenido y agregue la fecha de recuperación del
material más el nombre de la base de datos:
Moran Cortez, T. (2000, Julio 9). Distribución de archivos en un sistema inteligente. The
Observer, p.7. consultado el 10 de septiembre de 2001, en The Porter y The Observer, en su
base de datos en CD-ROM.
a) Capítulos de libro
Lama J. 1999. Sistemas expertos. En: Hafez ESE, Hafez B, eds. Reproducción e
inseminación artificial en animales. 7ª ed. México: McGrawHill. p224-242.
b) resúmenes de congresos o reuniones
Argenti P, Ly J, Espinoza F. 2007. Evaluación del efecto de secuestrantes en el control de
micotoxinas en alimentos para cerdos en crecimiento. En: XX Reunión ALPA. Cusco:
Asociación Latinoamericana de Producción Animal.
c) Tesis
PARIONA.J 2008 Detección de errores en el analisis sintactico de un compilador. Tesis de
Lic en Computacion. Lima: Univ. Nac. Mayor de San Marcos. 48 p.
d) Informe científico o técnico
[UNMSM] Instituto de Investigacion. 2001. Factores de riesgos en la transmisión
electronica de datos. Lima Peru.541 p.
e) Material electrónico en CD ROM
Amadeo Vásquez Tavara. 2003. Redes Neuronales Artificiales [CD-ROM]. 13ª ed. Madrid:
Editorial Medica Panamericana. 363 p.
f) Articulo en revista electrónica
Aparicio-Acosta FM. 2000. Universidad , Ciencia y Tecnologia [Internet], [28 noviembre
2007]. Disponible en: http://www.uk.es/bdARTE/v6n.htm
g) Sitio de Web
Portal Agrario. 2007. Lima: Ministerio de Agricultura. [Internet], [12 agosto 2007].
Disponible en: http://www.minag.gob.pe/
Cuadros
1. Las tablas deben de haber sido citados en el texto.
2 El titulo en la parte inferior comienza con la palabra “Tabla”, seguida del número que le
corresponda. Va en minúscula con excepción de los nombres propios y acrónimos. No lleva
puntuación al final del titulo.
3 Cada columna debe ser identificada y solo la primera letra del encabezado va en mayúscula.
Las explicaciones se colocan como notas al pie.
Figuras
1. Las figuras incluyen gráficos, fotografías, imágenes, mapas y diagramas. Deben ser citadas
en el texto.
2 El titulo y la leyenda se colocan en la parte inferior de cada figura. El titulo comienza con la
palabra “Figura”, seguida del número que le corresponda. Va en minúsculas, a excepción de
los nombres propios y acrónimos.
3 Si la figura ha sido previamente publicada (a excepción de documentos de dominio
público), cite la fuente original al final de la leyenda.
Unidades de medida
1. En los valores numéricos, el punto señala la separación entre los números enteros y las
fracciones (ejemplo: 6.35). Se usa la coma para separar números con más de tres dígitos
(ejemplo: 9,232.5). Se coloca el 0 a la izquierda del punto en número y la unidad que le
corresponde.
82
Revista Alghoritmic
ISSN 2220-3982 Pag 83
2. No comience una frase con un número. Utilice otra expresión o deletree el número y la
unidad que le corresponde.
3. Al hacer referencia a porcentajes, el símbolo se coloca junto al número sin espacio en
blanco entre ellos (85%).
4. Cada vez que se mencione un número inferior a 10 y que no vaya seguido de una unidad de
medida, éste debe deletrearse (ejemplo: cuatro archivos, 14 procesos, dos gigabytes, etc.).
Si se menciona una serie de elementos semejantes que incluyen numero mayores y menores
de 10, todos se colocan en caracteres numéricos.
Abreviaturas y símbolos
1. Utilice únicamente abreviaturas estándares. Las abreviaturas de las unidades de medida se
usan cuando van inmediatamente después de un número. Evite las abreviaturas en un titulo
y en el resumen.
2 Al emplear una abreviatura en el texto por primera vez, irá entre paréntesis precedida del
termino completo, salvo si se trata de una unidad de medida común.
3 El resumen, así como cada cuadro y figura, debe entenderse en forma independiente, de
modo que las abreviaturas usadas deben ser definidas en extenso en cada caso.
4 Todas las abreviaturas de las unidades de medidas se escriben en singular, aunque se
refieran a un plural (ejemplo: kb, no kbs; gb, no gbs).
5 Términos latinos como in situ, a priori, deben escribirse en cursiva.
6 El uso de “y/o” no esta permitido. Usar la más adecuada o cambiar de expresión.
7 Usar el sistema de 24 horas al referirse al tiempo (Ejemplo: 14:10 en vez de 2:10 p.m.).
Formas de citar referencias bibliográficas en el texto
1 En las citaciones en el texto, indique el concepto y coloque el autor entre paréntesis
(Cárdenas, 2005) o indicando que determinado autor señala un concepto [Vásquez
Moran (1975) se obtiene mayores ganancias de peso…]
2 Alternativamente se puede citar una referencia de las fuentes al final del articulo
consignando el numero de la referencia entre corchetes.
Ejemplo
… las bases de datos se definen...[4]
3 Las referencias en el texto principal se trabajan dando por supuesto que las mayores
especificaciones se ofrecerán en la Bibliografía final del trabajo. De la siguiente
manera:
“Cárdenas (2005, p.45) En un estudio de las Bases de datos orientadas a objetos...”
“En un estudio de las Bases de datos orientadas a objetos (Cárdenas, 2005,p.45)...”
4
Cuando un autor, o un grupo de autores, tiene(n) más de una publicación en el mismo año
especifique la fecha con una letra minúscula. Por ejemplo:
“En dos estudios recientes (Harding, 1986a, p.80; Harding, 1986b, p.138) se sugirió que...”
“En dos trabajos recientes (1986a, p.80; 1986b, p.138) Harding sugirió que...”
5
Si se incluyen dos o mas citas dentro de una misma frase, las citas se arreglan en orden
cronológico. Si tienen el mismo año de publicación se arreglan en orden alfabético. Si el
mismo autor tiene varias publicaciones con distintas fechas se cita con el apellido del autor
seguido de los años de las publicaciones.
(García et al., 1999; Pérez y Vega, 2001; Ogata, 2006)
(Ball, 2004; Smith, 2004)
(Gil y Chávez, 2002, 2004)
6
Para citar a varios autores (hasta cinco autores) escriba todos los autores la primera
vez, después utilice et al. [y otros]. la primera vez sería (Moore, Estrich, McGillis, y
Spelman 1984, p.33) y las referencias subsecuentes a la misma publicación se harían con
(Moore et al.).
83
Revista Alghoritmic
ISSN 2220-3982 Pag 84
Para seis autores o más, utilice en cualquier caso et al. después del primer
autor. Cerciórese de utilizar “y” para los casos en los que la referencia a et al. tenga
lugar dentro de su texto normal. En cambio, cuando esta referencia se incluya
completa entre paréntesis, utilice el signo "&".
Cuando necesite referenciar una fuente cuyo autor no ha podido identificar con
precisión, cite las primeras dos o tres palabras del título, seguido por el año.
7
. ... en un reciente publicación (Enciclopedia de la Psicología , 1991, p.62)... ...
en el siguiente artículo ("Diferencias individuales," 1993, p.12)...
Este ejemplo es permitido para las direcciones electrónicas donde no ha podido identificar
ningún autor. Sin embargo, si el autor es "anónimo", cite la palabra Anónimo en su texto, por
(Anónimo, 1993, p.116).
Nota: subraye o ponga en cursiva [itálica] el título de un diario o el un libro y use comillas
dobles para identificar el correspondiente título del artículo o capítulo.
7) Cuando use citas literales en su texto principal, hágalo de la siguiente manera:
Él señaló que "la importancia relativa de los sistemas puede, sin embargo, ser
continua aproximadamente en la misma proporción" (Gardner, 1973, p.41)
Smith (1991) descubrió que "... no hay evidencia de que los chimpancés que
producen un dibujo distingan el objeto representado en él... "(p.84)
8) Si usted necesita citar una investigación que encontró en otro trabajo, puede hacerlo de las
siguientes maneras:
Navarrete (2010, p.65) cita a Roig (1999) quien descubrió que...
Roig (1999), citado por Navarrete (2010, p.65), descubrió que...
Se encontró (Roig, 1999, citado por Navarrete, 2010, p.65) que...
9) Si la referencia tienen uno o dos autores, la cita contiene el (los) apellido(s) y el año de
publicación. Si tiene tres o mas autores, se cita sólo con el apellido del primer autor seguido
de et al. Y el año de publicación. Si los autores tienen el mismo apellido se incluyen las
iniciales.
autor: Aho (1999)
autores: Pariona y Navarro (2001)
o mas autores: Tenembaum et al. (1999)
Apellido similar: Aho, T. y Aho, C. (1998)
4 La referencia es de una institución se prefiere usar el nombre abreviado en el texto. Sin
embargo, si se le cita pocas veces, puede usarse el nombre en extenso.
El numero de alumnos desertores es de 400(UNMSM, 2005).
El numero de alumnos desertores en el país es de 1250(Facultad de Educación, 2005).
PRESENTACIÓN DEL ARTICULO
1
2
3
La presentación del articulo deberá hacerla personalmente el responsable del articulo,
debiendo presentar dos copias impresas del manuscrito en papel Bond A4 (Las figuras que
deban ir a color deberán ser impresas a color) y en un CD debidamente rotulado,
conteniendo el trabajo en un archivo de Word, las ilustraciones en formato jpg. La Oficina
de la RISI: Av. Amezaga s/n CU San Marcos – Pabellón Facultad Ingeniería de Sistemas,
3er piso Ofic. 301 Lima. Tel 6197000-3604
Si hubiera mas de un autor, el responsable debe ser el primero de la lista consignada en la
presentación.
La RISI no cobra costos de impresión a los autores.
PROCESOS DE REVISIÓN
1. El Comité Editorial (CE) de la RISI verificara que el articulo presentado se circunscriba a la
temática de la revista y que el formato del documento se encuadre dentro de las
especificaciones solicitadas a los autores.
84
Revista Alghoritmic
2
3
4
5
ISSN 2220-3982 Pag 85
Los trabajos que cumplan con estos requisitos serán derivados a los revisores científicos
para su revisión.
Los revisores mantienen la confidencialidad del contenido del manuscrito, realizan una
revisión profesional al documento y preparan su informe con comentarios y sugerencias en
forma clara y precisa.
Los autores cuyos trabajos sean sujeto de correcciones deberán resolverlas y devolver una
carta aceptando las sugerencias, presentando las modificaciones o justificando las razones
para no modificar.
El CE, en base a la respuesta de los autores, aprobará o rechazará el articulo y le
comunicara la decisión final a los autores. Así mismo, enviara una carta electrónica a los
autores de trabajos indicando las razones correspondientes.
85

alghoritmic - Facultad de Ingeniería de Sistemas e Informática

Transcripción

Documentos relacionados

Leer Más - ConcretOnline

Análisis de los errores en matemática de los alumnos ingresantes a

by JOSEP LLUSCÀ Permasa

HISTORIA 2.0, Conocimiento histórico en clave digital