Está en la página 1de 68

Universidad Mayor de San Andrés

Facultad de Ciencias Puras y Naturales


Carrera de Informática
INSTITUTO DE INVESTIGACIONES EN INFORMÁTICA

Revista “TRIPLE i” No. 3 del Instituto de Investigaciones en


Informática, dependiente de la Carrera de Informática – Facultad
de Ciencias Puras y Naturales.

Las opiniones expresadas son de responsabilidad exclusiva de sus


autores y no reflejan, necesariamente el criterio de la “Triple i”.

El material de esta publicación pude ser reproducido citando


fuente y autor.

Autoridades:

FACULTAD DE CIENCIAS PURAS Y NATURALES


M.Sc. Franz Cuevas Quiroz
Decano
M.Sc. Luís Morales Escobar
Vicedecano

CARRERA DE INFORMÁTICA
Lic. Eufren Llanque Quispe
Jefe de Carrera

INSTITUTO DE INVESTIGACIONES EN INFORMÁTICA


M.Sc. Edgar Clavijo Cárdenas
Director

Edición, Diseño e Impresión:


Ing. Oscar L. Guzmán Jordán
María Magdalena Ponce
Nicolás Machicado Chávez

INSTITUTO DE INVESTIACIONES EN INFORMÁTICA


Av. Villazón 1995 – Monoblock Central
Edificio Carrera de Informática, 2do. Piso
Teléfono: 2440338 – 2440325 Int. 3
Sitio Web http://iii.informatica.edu.bo
Correo Electrónico: iii_umsa@yahoo.es

La Paz, Diciembre 2008


Bolivia
ÍNDICE
Pág.
1. Ingeniería de Requerimientos con Teoría Fundamentada
Guillermo Choque Aspiazu……………………………………………..………… 3

2. Middleware
Roberto Vargas Blacut …………………………………………………………………… 12

3. Resumen de una noticia de prensa: un pretexto para tener presente el


procesamiento del lenguaje natural
Lucio Torrico Díaz …………………………………………………………………………. 17

4. Recurso didáctico para programación orientada a objetos


Menfy Morales Ríos, Carlos R. Fernández L., Jaime Chura P. y
Juan P. Poma ………………………………………………………………………………. 21

5. HUMANITIES COMPUTING: Iniciativas Digitales en Humanidades


Brígida Carvajal Blanco …………………………………………………………………… 27

6. Canales de información y matrices


Edgar Clavijo Cárdenas……………………………………………………………………. 32

7. Sistemas inteligentes educativos


Patricia Trino Camacho……………………………………………………………………. 40

8. Hojas de estilo
René Casilla Gutiérrez……………………………………………………………………….. 49

9. Programación orientada a componentes


Carmen R. Huanca Quisbert y Celia E. Tarquino Peralta …………………………… 54

10.Teoría computacional en sistema multi-agente


Elizabeth García Escalante …………………………….. …………………………………. 65
Editorial

Cada etapa nos marca un nuevo comienzo y en cada comienzo renovamos las
esperanzas de mejores días.

Nos preparamos a dar nuevos pasos en la consolidación de nuestra publicación


institucional dando acceso a profesionales de fuera de nuestra institución para
enriquecer de experiencias nuestra revista.

Contamos a partir de éste número con un comité editor conformado por prestigiosos
profesionales de la Informática en nuestra región con la misión de vigilar por la calidad
de la publicación, a los cuales agradecemos su colaboración desinteresada.

La publicación de este tercer número de la revista “Triple i” es emblemático por la


coincidencia con el nombre y número.

Los artículos presentados son parte de la experiencia profesional de nuestros colegas


que se entrega generosamente para compartir y socializar su conocimiento sin otro
reconocimiento que el agradecimiento sincero de parte de nuestra institución. Entre
estos contamos aquellos que son parte de los resultados de los proyectos de
investigación del I. I. I., investigaciones realizadas conectadas con el quehacer
académico, investigaciones de interés personal con impacto social o experiencias
prácticas de alto nivel profesional.

Finalmente, debemos agradecer a nuestra sociedad la oportunidad que nos brinda


de realizar nuestras labores académicas y científicas esperando devolver con este
aporte el esfuerzo que realiza por contar con instituciones de carácter científico como
lo es el Instituto de Investigaciones en Informática. Agradecer también al personal
administrativo del Instituto de Investigaciones en Informática por el apoyo a éste
esfuerzo.

Lic. Edgar Clavijo Cárdenas M. Sc.


Diciembre, 2008
INGENIERÍA DE REQUERIMIENTOS CON TEORÍA FUNDAMENTADA
Guillermo Choque Aspiazu
Universidad Mayor de San Andrés
Carrera de Informática
gchoque@correo.umsa.bo

RESUMEN
La ingeniería de requerimientos cumple un papel primordial en el proceso de producción de
software, ya que se enfoca en la definición de lo que se desea producir. Su principal tarea consiste
en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en
forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende
minimizar los problemas relacionados al desarrollo del producto software. El presente artículo
propone utilizar la teoría fundamentada para el análisis de requerimientos de los proyectos
informáticos que se encaran utilizando la tecnología estratificada del software, para el efecto se
hace uso del paquete computacional AtlasTi como herramienta para las tareas de elaboración y
especificación al interior del clásico proceso de la ingeniería de requerimientos.

ABSTRACT
Requirement engineering plays a role in the process of software production, as it focuses on the
definition of what is desired to produce. Its main task is to correct the generation of specifications
that describe clearly, unambiguously, in a consistent manner and compact, the behavior of the
system, in this way, it is intended to minimize the problems related to development software product.
This article proposes to use of Grounded Theory in the stage of requirements analysis of the software
projects that are using stratified technology, for this purpose AtlasTi computational package is used
as a tool to execute tasks in the design and specification of the classic process engineering
requirement.

Palabras clave. Tecnología estratificada, Ingeniería de requerimientos, teoría fundamentada,


AtlasTi.
Keywords. Stratified technology, engineering requirements, grounded theory, AtlasTi.

1. INTRODUCCION

Una de las mayores deficiencias en la práctica de construcción de software es la poca atención


que se presta a la discusión del problema. En general los desarrolladores se centran en la
solución dejando el problema inexplorado y por ende no descrito totalmente. Uno de los
resultados más importantes de la aplicación del proceso de ingeniería de sistemas es la
especificación de un sistema basado en computadora que se describe de manera genérica en
los siguientes niveles: vista global de todo el sistema, vista del dominio, vista del elemento y vista
detallada [1]. Como se observa en la Figura 1, esta jerarquía está organizada de manera
deductiva, de lo general a lo particular.

Vista global

Vista del dominio

Vista del elemento

Vista detallada

Figura 1. Jerarquía de sistemas computacionales


Fuente: Tomado de [1]

En este contexto se presenta un desafío a los ingenieros del software ¿Cómo se puede asegurar
que se ha especificado un sistema que recoge las necesidades del cliente y satisface sus
expectativas?. Según [1] no hay una respuesta segura a esta difícil pregunta, pero un sólido
proceso de ingeniería de requerimientos constituye la mejor solución de la que se dispone en
este momento.

2. INGENIERIA DE REQUERIMIENTOS

La ingeniería de requerimientos facilita el mecanismo apropiado para comprender lo que


requiere el cliente, analizando necesidades, confirmando su factibilidad, negociando una
solución razonable, especificando la solución sin ambigüedad, validando la especificación y
gestionando los requerimientos para que se transformen en un sistema operacional [2].

La ingeniería de requerimientos cumple un papel primordial en el proceso de producción de


software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su
principal tarea consiste en la generación de especificaciones correctas que describan con
claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema;
de esta manera, se pretende minimizar los problemas relacionados al desarrollo del producto
software [1].

Es necesario apuntar que las técnicas más habituales en la elicitación de requerimientos son las
entrevistas, el desarrollo conjunto de aplicaciones1, la tormenta de ideas y la utilización de
escenarios [3] más conocidos como casos de uso [4]. A estas técnicas se las suele apoyar con
otras técnicas complementarias como la observación in situ, el estudio de documentación, los
cuestionarios, la inmersión en el negocio del cliente [5] o haciendo que los ingenieros de
requerimientos sean aprendices del cliente [6].

3. PROCESO DE LA INGENIERIA DE REQUERIMIENTOS

La ingeniería de requerimientos proporciona el mecanismo apropiado para entender lo que el


cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable,
especificar la solución sin ambigüedades, validar la especificación, y administrar los requisitos
conforme éstos se transforman en un sistema operacional. El proceso de la ingeniería de
requerimientos se lleva a cabo a través de siete distintas funciones: (1) Inicio, (2) obtención, (3)
elaboración, (4) negociación, (5) especificación, (6) validación y (7) gestión [1].

Resulta importante destacar que algunas de estas funciones de la ingeniería de requerimientos


ocurren en paralelo y que todas deben adaptarse a las necesidades del proyecto. Todas están
dirigidas a definir lo que el cliente quiere, y todas sirven para establecer una base sólida
respecto del diseño y la construcción de lo que obtendrá el cliente.

4. TEORIA FUNDAMENTADA

A comienzos del siglo XXI los investigadores cualitativos disponen de todo un repertorio de
paradigmas, métodos y estrategias que emplear en sus investigaciones. Las teorías van desde el
interaccionismo simbólico hasta el constructivismo, la indagación naturalista, positivismo y post-
positivismo, fenomenología, etno-metodología, crítica semiótica, estructuralismo, feminismo y
varios paradigmas étnicos. La investigación cualitativa va ganando en valor, y la política y la
ética de la investigación cualitativa fueron tópicos de gran interés. Las estrategias de
investigación iban desde la “teoría fundamentada” hasta el estudio de casos, los métodos
históricos, biográficos, la etnografía en la acción y la investigación. También se disponen de
diversas normas de recoger y analizar materiales empíricos, incluyendo la entrevista cualitativa,
la observación, la visualización, la experiencia personal y los métodos documentales. Las
computadoras van entrando progresivamente [7].

Glaser y Strauss desarrollaron la teoría fundamentada [8] como un método de investigación


proveniente del interaccionismo simbólico y como un método para derivar sistemáticamente
teorías sobre el comportamiento humano y el mundo social, con una base empírica [9]. En la
práctica, los investigadores, comúnmente, se refieren a la teoría fundamentada como un modo
de análisis. Charmaz define la teoría fundamentada como:
“....unas directrices analíticas que permiten a los investigadores focalizar su recolección
de datos y construir teorías de rango medio a través de sucesivas recolecciones de
datos y desarrollos conceptuales” [10].

1
También conocida como “Joint Application Development (JAD)”.
Como cualquier otro método cualitativo, la teoría fundamentada ofrece una manera de
representar la realidad que arroje luz o un entendimiento sobre lo estudiado. Los investigadores
la utilizan con el objetivo de crear categorías teóricas a partir de los datos y analizar las
relaciones relevantes que hay entre ellas [11]. Es decir, a través de los procedimientos analíticos,
se construye teoría que está fundamentada en los datos, de ahí su nombre. El interés que tiene
es que hace explícitos los procedimientos de análisis cualitativo y ayuda a los investigadores a
desarrollar conceptualizaciones útiles de los datos. Hasta su creación, el análisis cualitativo
dependía de métodos implícitos y por tanto de la intuición y el talento de los investigadores [11].

Un estudio de teoría fundamentada se inicia con una pregunta general, no con hipótesis. Esta
pregunta suele ser del tipo “¿qué es lo que pasa aquí?, ¿qué es lo que sucede?”. Las
características o los atributos de lo que está en estudio, lo que se llamaría variables, han de surgir
en el análisis y no asumirse o imponerse. A través del proceso de investigación se siguen
intereses, pistas o corazonadas que se identifican en los datos. La teoría fundamentada
entonces, enfatiza el descubrimiento y el desarrollo de teoría y no se basa en un razonamiento
deductivo apoyado en un marco teórico previo [11]. Esto hace que emplee unas estrategias
características aunque ya no exclusivas de ella. Primero, la recolección de datos y el análisis
transcurren de manera concurrente. Segundo, los datos determinan los procesos y productos de
la investigación y no marcos teóricos preconcebidos. Tercero, los procesos analíticos suscitan el
descubrimiento y desarrollo teórico y no la verificación de teorías ya conocidas. Cuarto, el
muestreo se realiza con base en lo que emerge de los datos, se le denomina muestreo teórico
que sirve para refinar, elaborar y completar las categorías, y por último, el uso sistemático de los
procedimientos analíticos lleva a niveles más abstractos de análisis [11].

El resultado de un estudio de teoría fundamentada es una interpretación analítica del mundo


de los participantes y de los procesos para construir esos mundos [11], los criterios para evaluarla
son cuatro: (1) ajuste, esto es que encaje en la experiencia de los participantes; (2)
funcionamiento, es decir que explique la mayor variedad posible; (3) relevancia al fenómeno en
estudio y por último, (4) la posibilidad de modificarse la propia teoría; que significa que esta
teoría se pueda acomodar a nuevos hallazgos [12] .

5. ATLAS.TI

AtlasTi es una herramienta informática cuyo objetivo es facilitar el análisis cualitativo de,
principalmente, grandes volúmenes de datos textuales. Puesto que su foco de atención es el
análisis cualitativo, no pretende automatizar el proceso de análisis, sino simplemente ayudar al
intérprete humano agilizando considerablemente muchas de las actividades implicadas en el
análisis cualitativo y la interpretación, como por ejemplo la segmentación del texto en pasajes o
citas, la codificación, o la escritura de comentarios y anotaciones; es decir, todas aquellas
actividades que, de no disponer del programa, se realizaría con la ayuda de otras herramientas
como papel, lápices de colores, tijeras, fichas, fotocopias, etc. [13] .

Los programas informáticos utilizan diferentes denominaciones para referirse a los archivos en los
que almacenan su trabajo. Por ejemplo, se habla de “documento” para hacer referencia a los
archivos almacenados en el disco duro de la computadora, o en un medio externo, que se ha
creado con un procesador de texto; se habla de “presentaciones” para referirse a los archivos
creados con programas como Power Point; o se habla de “hojas de cálculo” cuando los datos
se lo ha creado con programas como Excel.

Sin embargo, un documento es, en realidad, la combinación de diferentes elementos: una serie
de caracteres relacionados con códigos de formato: negritas, cursiva, definición de márgenes,
etc.; es decir, con propiedades de esos caracteres o datos “brutos”. Una presentación son
imágenes combinadas entre sí siguiendo una serie de criterios y a las que se aplica una serie de
características: orden, tiempo de presentación en pantalla, efectos de difuminado, etc.;
mientras que una hoja de cálculo incluirá, por ejemplo, fórmulas para el tratamiento de los datos
numéricos.

De acuerdo con [13], en el caso de AtlasTi el resultado del trabajo realizado será un archivo,
almacenado en el disco duro de la computadora o en una unidad externa de
almacenamiento, compuesto por una serie de elementos. En este caso, al archivo es
denominado Unidad Hermenéutica y sus componentes principales son los siguientes:
1. Documentos primarios. Los Documentos Primarios son la base del análisis, es decir, los “datos
brutos”. Pueden ser datos textuales, prácticamente en cualquier formato, imágenes con
extensiones: JPG, WMF, GIF, BMP, etc.; archivos de sonido con extensiones: WAV, MP3, AU,
etc., e incluso vídeo con extensiones: AVI, MPG, WMV, etc.
2. Citas. Las Citas son fragmentos de los Documentos Primarios que tienen algún significado, es
decir, son los segmentos significativos de los Documentos Primarios. Se los puede entender
como una primera selección del material de base, una primera reducción de los datos
brutos.
3. Códigos. Los Códigos suelen ser, aunque no necesariamente, la unidad básica de análisis.
Habitualmente el análisis se basará en ellos. Se puede entender los mismos como
conceptualizaciones, resúmenes o agrupaciones de las Citas, lo que implicaría un segundo
nivel de reducción de datos. Aun así, se debe tener en cuenta que no necesariamente
tienen que estar relacionados con las Citas, es decir, los Códigos pueden utilizarse también
como “conceptos” útiles para el análisis que no necesariamente tienen una relación directa
con fragmentos de texto, imagen o sonido
4. Anotaciones. Son el cuarto de los componentes principales, junto a Documentos, Citas y
Códigos. Aunque cada uno de los componentes anteriores pueden tener asociado un
Comentario, se pueden entender las Anotaciones como comentarios de un nivel
cualitativamente superior, puesto que son todas aquellas anotaciones que realiza el analista
durante el proceso de análisis y que pueden abarcar desde notas recordatorias, hipótesis
de trabajo, etc., hasta explicaciones de las relaciones encontradas, conclusiones, etc. que
pueden ser utilizadas como punto de partida para la redacción de un informe.
5. Familias. De la misma forma que los Códigos pueden ser vistos como agrupaciones de Citas,
AtlasTi permite también agrupar en Familias el resto de componentes principales. Estas
agrupaciones pueden ser un primer paso en el análisis conceptual.
6. Redes. Son uno de los componentes más interesantes y característicos de AtlasTi, y uno de
los elementos principales del trabajo conceptual. Permiten representar información
compleja de una forma intuitiva mediante representaciones gráficas de los diferentes
componentes y de las relaciones que se hayan establecido entre ellos.

En síntesis, la Unidad Hermenéutica es el “contenedor” que agrupa a todos los elementos


anteriores. Dicho de otra forma, es el archivo en el que se graba toda la información
relacionada con el análisis, desde los documentos primarios hasta las redes. Es decir, es el
equivalente a un fichero “.doc” (documento de texto), “.ppt” (presentación), o “.xls” (hoja de
cálculo) [13].

6. USO DE ATLAS.TI PARA LA INGENIERIA DE REQUERIMIENTOS

Para fines exclusivos de la propuesta, se debe reconocer que el proceso de ingeniería de


requerimientos consiste fundamentalmente en la elicitación, análisis, validación y especificación
de las necesidades de los clientes. En el contacto que se tiene entre el ingeniero del software
con los clientes, lo que normalmente se recoge son datos cualitativos antes que cuantitativos.
Los datos cualitativos por lo general provienen desde las entrevistas en profundidad, discursos,
entrevistas focales, diarios, informes y testimonios; con la adición de los sistemas computarizados
se propone la inclusión de textos de carácter general, documentos históricos, fotografías,
imágenes, videos y sonidos.

Cabe aquí entonces hacer una distinción del dato cualitativo:”Los ingenieros de requerimientos
consideran datos toda una serie de datos relativos a las interacciones de los sujetos entre sí y
con el propio ingeniero, sus actividades y los contextos en que tienen lugar, la información
proporcionada por los sujetos, bien a iniciativa propia o a requerimiento del ingeniero de
requerimientos, o por los artefactos que construyen y usan, sean estos documentos escritos u
objetos materiales [7].

6.1. Proceso analítico

El proceso analítico propuesto para el manejo de los requerimientos a través de la teoría


fundamentada tiene su base en un procedimiento descrito de manera macro en el diagrama
de bloques de la Figura 2.

Los pasos que comprende el proceso descrito, en la figura 2, son detallados a continuación.
1. Inicio. De manera general, la mayoría de los proyectos comienzan cuando se identifica una
necesidad de negocios o se descubre un nuevo mercado o servicio potencial. Se inicia con
una conversación con el cliente y se acuerda la grabación o la toma de notas de la
entrevista. Al inicio del proyecto los ingenieros del software hacen una serie de preguntas
libres de contexto. El objetivo es establecer una comprensión básica del problema, las
personas que quieren una solución, la naturaleza de la solución que se desea, y la
efectividad de la comunicación preliminar entre el cliente y el ingeniero de requerimientos.
2. Obtención. Aparenta ser muy simple preguntarle al cliente, a los usuarios y otros interesados
cuáles son los objetivos para el sistema o producto software, qué es lo que se debe lograr,
de qué forma el producto satisface las necesidades del negocio y por último cómo se
utilizará el sistema o producto día a día. Pero no es simple, es bastante difícil y se debe tener
bastante cuidado en evitar los siguientes problemas de la ingeniería de requerimientos: (a)
Problemas de ámbito, definiendo en la subjetividad del usuario el límite del sistema
clarificando principalmente los objetivos generales del sistema. Obviamente en términos
cualitativos estos límites pueden ser explicitados de manera difusa o incierta para luego
ajustarlos en el análisis del discurso. (b) Problemas de comprensión, asegurando obtener lo
que el cliente necesita, intentando obtener el conocimiento de las capacidades y
limitaciones de su ambiente de cómputo; se deben rescatar las necesidades del cliente en
una conversación amena y agradable, cuidando que no omitan información que
consideran “obvia”, intentando conseguir mayor información para reparar los requisitos
ambiguos o inestables. (c) Problemas de volatilidad, intentar estabilizar los requerimientos
para espacios de tiempo dinámicos, normalmente los problemas son bastante volátiles y
deben ser detectados en el análisis del discurso del cliente.
3. Codificación. Para [14] en la investigación cualitativa, la codificación es un modo
sistemático de desarrollar y refinar las interpretaciones de los datos. El proceso de
codificación incluye la reunión y análisis de todos los datos que se refieren a temas, ideas,
conceptos, interpretaciones y proposiciones. La codificación es considerada una actividad
fundamental en el proceso de reducción de datos, aunque no por ello la única o más
importante, sus operaciones se basan en el uso de códigos los cuales se conciben
comúnmente como una abreviación, símbolo o marca que se aplica a unas frases, párrafos
o en general a las unidades de análisis de los datos obtenidos como resultados de la
aplicación de un instrumento. Por tanto puede entenderse como una operación que se
hace inicialmente sobre los datos, en otras palabras una primera transformación de los
mismos. La técnica de codificación que suele usarse a inicialmente es la de la codificación
abierta, definida por [15] como el procedimiento analítico por medio del cual se descubren
los conceptos en términos de sus propiedades y dimensiones. Posteriormente se aplica de la
codificación axial: “acto de relacionar categorías con subcategorías, siguiendo la línea de
sus propiedades y dimensiones y de mirar como se entrecruzan y vinculan”. Este último tipo
de codificación está más asociado a los niveles de categorización y conceptualización.
También es importante destacar que la codificación no es un proceso lineal, y que se puede
alternar entre un tipo y otro de manera simultánea.
4. Nivel de categorización. La categorización es entendida como una operación que tiene la
particularidad de agrupar o clasificar conceptualmente un conjunto de elementos, datos o
códigos, que reúnen o comparten un significado, por tanto es concebida en un nivel de
abstracción superior que está más próxima a un nivel relacional conceptual, que a un nivel
de datos brutos. Según [14] el número de categorías que se adopten dependerá de la
cantidad de datos recogidos y de la complejidad del esquema analítico. Para [16] en la
teoría fundamentada “Algunas categorías pueden ser derivadas de teorías existentes, pero
este procedimiento es flexible”, es aquí entonces donde se habla de la emergencia de las
categorías a partir de los datos. Este nivel de categorización se logra en el análisis a través
del agrupamiento de códigos, resaltando las relaciones entre éstos y su incidencia en la
categoría. A través del uso del AtlasTi se forman familias de códigos que representan las
categorías.
5. Conceptualización. Como se menciono anteriormente la codificación axial es base en la
formación de conceptos, aspecto muy importante en el análisis de los datos, ya que
permite visualizar patrones o rutinas en el conjunto de datos que forman la coyuntura
principal para explicar la realidad observada, es decir, es un nivel de abstracción superior
que permite hacer las conclusiones pertinentes de los fenómenos estudiados. Para lograr tal
conceptualización se hace uso de las relaciones y vínculos entre los diferentes códigos y
categorías descubriendo así elementos centrales en los datos que permiten ser apreciados
mediante representaciones visuales que muestran el todo de una manera coherente. Al
aplicar el software AtlasTi éstas relaciones se muestran a través de los elementos
denominados redes.
6. Teorización. Para [15] las teorías son: “conjuntos de conceptos bien relacionados vinculados
por medio de oraciones de relación, las cuales juntas constituyen un marco conceptual
integrado que puede usarse para explicar o predecir fenómenos”. De igual manera las
teorías pueden clasificarse, según su nivel de generalización, en formales y sustantivas. Las
primeras responden a la búsqueda de leyes y conclusiones de carácter universal, y las
segundas buscan la generalización de un contexto específico o una realidad concreta, en
muchas de las investigaciones el nivel teórico de la investigación tiene un carácter
sustantivo, para lograr esto se hace uso de la codificación selectiva, que consiste en refinar
e integrar la teoría y descubrir la categoría central a través del uso de diagramas o
memorandos.
7. Negociación. Es relativamente común que diferentes clientes o usuarios propongan
requerimientos que entran en conflicto entre sí al argumentar que su versión es “esencial
para las necesidades especiales”. El ingeniero de requerimientos debe conciliar estos
conflictos por medio de un proceso de negociación. En este proceso se pide a los clientes,
usuarios y otros interesados que ordenen sus requerimientos y después discutan los conflictos
relacionados con la prioridad. Se identifican y analizan los riesgos asociados con cada
requisito. Se hacen “estimaciones” preliminares del esfuerzo requerido para su desarrollo y
después se utilizan para evaluar el impacto de cada requerimiento en el costo del proyecto
y sobre el tiempo de entrega. Mediante un enfoque iterativo, los requisitos se eliminan,
combinan o modifican de forma que cada parte alcance cierto grado de satisfacción.

Obtención Codificación

Inicio
Categorización

Conceptualización

Teorización Negociación

Validación Especificación

Gestión

Figura 2. Proceso de ingeniería de requerimientos con teoría fundamentada


Fuente: Con base en [1] y [15]

8. Especificación. La especificación se encuentra entendida como el refino de la teorización


realizada en el paso 6. Normalmente a la teoría obtenida se le adiciona los acuerdos
realizados en la tarea de negociación previa, esto significa afinar alguno de los
requerimientos descritos en la teoría, en términos de AtlasTi en forma de gráficos o
memorandos. La especificación es el producto de trabajo final que genera la ingeniería de
requerimientos. Sirve como base para las actividades de ingeniería del software
subsecuentes.
9. Validación. La validación de requisitos examina la especificación para asegurar que todos
los requisitos del software se han establecido de manera precisa; que se han detectado las
inconsistencias, omisiones y errores y que éstos han sido corregidos, y que los productos de
trabajo cumplen con los estándares establecidos para el proceso, proyecto y producto. El
mecanismo primario para la validación de requerimientos es la revisión técnica formal. El
equipo de revisión que valida los requerimientos incluye ingenieros del software, clientes,
usuarios y otros interesados que examinan la especificación y buscan errores en el
contenido o la interpretación, áreas que tal vez requieran una clarificación, información
faltante, inconsistencias, conflictos entre los requerimientos, o requerimientos inalcanzables.
10. Gestión. Los requerimientos para los sistemas basados en computadora cambian y que el
deseo de cambiarlos persiste durante la vida del sistema. La gestión de requerimientos es un
conjunto de actividades que ayudan al equipo del proyecto a identificar, controlar y
rastrear los requerimientos y los cambios a estos en cualquier momento mientras se
desarrolla el proyecto. Muchas de estas actividades son idénticas a las actividades de la
gestión de la configuración del software.

6.2. Aplicación del proceso

El procedimiento descrito en el proceso de ingeniería de requerimientos con teoría


fundamentada se aplica a la entrevista real sostenida con el Sr. Rubén Solíz Ortuño, Gerente
Propietario de la Empresa Importadora de Productos Suntuarios “Solíz S.R.L”. En dicha
oportunidad se realizó la presentación de la empresa de desarrollo de software “Sistemas
Integrales” y el Lic. Ramiro Loza fue el encargado de realizar la entrevista al Sr. Solíz. Para mostrar
la ejecución del proceso se selecciona un segmento de la entrevista que se muestra transcrita
en la Figura 3.

Figura 3. Inicio y obtención de requerimientos

El proceso de transferencia de los datos al AtlasTi, la codificación y categorización de los de los


datos mostrados en la figura 6 se muestra de manera grafica en la Figura 4.

Figura 4. Codificación y categorización de requerimientos


En la Figura 5 se pueden observar los resultados obtenidos luego de aplicar los pasos de
conceptualización y teorización de los requerimientos seleccionados como prueba.

[1:14][15] La empresa también cuenta [1:2][15] solicitud mediante proformas


con .. --------------------
-------------------- solicitud mediante proformas
La empresa también cuenta con agentes
que realizan ventas por comisiones

[1:3][15] las cotizaciones que se realiz..


[1:13][15] es posible que el cliente --------------------
haga.. las cotizaciones que se realizan en las
-------------------- mismas
es posible que el cliente haga una
reserva para la importación de un
producto que no se tiene en ese momento
[1:4][15] los pedidos que realizan los c..
--------------------
los pedidos que realizan los clientes
[1:12][15] Es política de la empresa fact..
--------------------
Es política de la empresa facturar por
toda entrega realizada al cliente de los [1:5][15] ventas al contado
productos con los que se cuenta --------------------
gestión de ventas ventas al contado

[1:11][15] Las ventas pueden ser [1:6][15] ventas al crédito con posibili..
realizad.. --------------------
-------------------- ventas al crédito con posibilidades de
Las ventas pueden ser realizadas con acceder a un plan de pagos
factura o sin factura dependiendo del
cliente

[1:7][15] depósitos que se realizan por ..


--------------------
[1:10][15] si paga al contado a un depósitos que se realizan por las ventas
descue.. en una cuenta bancaria de la empresa
--------------------
si paga al contado a un descuento

[1:8][15] Las reservas normalmente se


[1:9][15] cliente asiduo de la empresa e.. la..
-------------------- --------------------
cliente asiduo de la empresa es posible Las reservas normalmente se las realiza
que acceda a una línea de crédito por teléfono

Figura 5. Conceptualización y teorización de requerimientos

Finalmente en la Figura 6 se presentan los requerimientos obtenidos luego de la aplicación del


proceso de ingeniería de requerimientos con teoría fundamentada a la conversación realizada
con el gerente general de la empresa “Solíz SRL”

Fig. 6. Especificación de requerimientos luego de la negociación

7. CONCLUSIONES

La ingeniería de requerimientos cumple un papel primordial en el proceso de construcción del


producto software, debido a que se enfoca en la definición de lo que se desea construir como
producto software. Su principal tarea consiste en la generación de especificaciones correctas
que describan con claridad, sin ambigüedades, en forma consistente y compacta, el
comportamiento del sistema; de esta manera, es pretensión de la ingeniería de requerimientos,
minimizar los problemas relacionados con el desarrollo del software. El presente artículo plantea
de manera sistemática el empleo de la teoría fundamentada para el análisis de requerimientos
de los proyectos informáticos, aquello que el cliente especifica en lenguaje natural con toda la
subjetividad que le es inherente. Estos requerimientos se encaran utilizando la tecnología
estratificada del software, utilizando, para la captura de los pedidos cualitativos que realiza el
cliente, el paquete computacional AtlasTi como herramienta para las tareas de elaboración y
especificación al interior del clásico proceso de la ingeniería de requerimientos. Obviamente
este método puede ser utilizado para desarrollar el proceso de ingeniería de requerimientos
para cualquier problema que involucre la interrelación entre el desarrollador y el usuario para la
especificación de los requisitos, aquellos que correctamente especificados hacen posible la
construcción de productos software de alta calidad.

8. AGRADECIMIENTOS

Un agradecimiento especial a la empresa “Sistemas Integrales Innovadores SRL” la que presta un


apoyo decidido a la investigación en nuestro medio, otro bastante grande para la “Asociación
de Investigación en Software Inteligente” por las observaciones puntuales realizadas a la
presente investigación y finalmente una mención significativa al “Instituto de Investigaciones en
Informática” por apoyar de manera decidida la producción intelectual de la comunidad
informática de la Universidad Mayor de San Andrés.

9. REFERENCIAS BIBLIOGRAFICAS

[1] Pressman R.S. (2005) Ingeniería del Software: un enfoque práctico. 6º edición, McGraw
Hill.
[2] Thayer R.H. & M. Dorfman (1997) Software Requirements Engineering. Wiley.
[3] Weidenhaput K., K. Pohl, M. Jarke, & P. Haumer (1998) Scenarios in System Development:
Current Practice. IEEE Software, 15(2):34–45, Marzo/Abril 1998. Este artículo aparece en
ICRE’98: http://sunsite.informatik.rwthaachen.de/CREWS/reports97.htm
[4] Booch G., J. Rumbaugh & I. Jacobson (1999) El Lenguaje Unificado de Modelado.
Addison Wesley Iberoamericana.
[5] Goguen J. A. & C. Linde (1993) Techniques for Requirements Elicitation. En Proceedings
of the First International Symposium on Requirements Engineering. Disponible en
http://www.cse.ucsd.edu/goguen
[6] Beyer H. R. & K. Holtzblatt (1995) Apprenticing with the Customer. Communications of the
ACM, 38(5), Mayo 1995.
[7] Rodríguez G., J.G. Flores & E. García (1996) Metodología de la Investigación Cualitativa.
Editorial Aljibe, Málaga.
[8] Glaser B. & Strauss, A. (1967) The discovering of grounded theory. New York: Aldine.
[9] Kedall J. (1999) Axial coding and the grounded theory controversy. Western Journal of
Nursing Research, 21 (6), 743-757.
[10] Charmaz K. (2005) Grounded theory in the 21st Century. En: The Sage handbook of
qualitative reserach (Denzin N K y Lincoln Y S). SAGE, Thousand Oaks, CA, pp.507-535.
[11] Charmaz K. (1990) “Discovering” chronic illness: using grounded theory. Social Science
and Medicine, 30 (11), 1161-1172.
[12] Glaser B. (1978) Theoretical Sensitivity. The sociology Press, Mill Valey, CA.
[13] Muñoz J. J. (2005) Análisis cualitativo de datos textuales con ATLAS.ti 5. Universitat
Autonoma de Barcelona. Noviembre de 2005. Versión 3.03.
[14] Taylor S. & Bogdan R. (1986) Introducción a los métodos cualitativos de investigación.
Buenos Aires: Paidós.
[15] Strauss A. & Corbin J. (2002) Bases de la investigación cualitativa. Técnicas y
procedimientos para desarrollar la teoría fundamentada. Medellín: Universidad de
Antioquia.
[16] Tesch R. (1990) Qualitative research: analysis types and software tools, New York, The
Falmer Press.
MIDDLEWARE
RESUMEN
Al igual que individuos de diferentes nacionalidades requieren de un traductor para poder
comunicarse entre si; las aplicaciones corriendo en diferentes sistemas operativos y hardware
diverso, también requerirán de ayuda para comunicarse. Esta ayuda se denomina
middleware y es un software que se constituye como una capa de traducción intermedia
entre una aplicación corriendo en un servidor y un número de clientes que solicitan servicio.
Las funciones que provee el Middleware permiten acceder a aplicaciones e información
desde diferentes arquitecturas, protocolos y redes. En pocas palabras, el Middleware permite Roberto Vargas Blacutt
a los usuarios interactuar con aplicaciones en un ambiente computacional heterogéneo. Docente – UMSA
rvargas@correo.umsa.bo

PALABRAS CLAVE: Sistemas Distribuidos. Computación distribuida. RPC. RMI. CORBA, DCOM+OLE.
Sistemas Operativos Distribuídos.
KEYWORDS: Distributed Systems. Distributed Computing. Remote Procedure Call. RMI. CORBA.
Distributed Operating Systems.

INTRODUCCIÓN
El Middleware es una tecnología de software diseñada para la ayuda y soporte a la
heterogeneidad y complejidad de los sistemas distribuidos. Se define al Middleware como una
capa de software que se halla por encima del sistema operativo y debajo de los programas de
aplicación. Se constituye por tanto, en un estrato intermedio entre el software de base y el
software de aplicación. Proporciona una abstracción común de programación a todo lo largo y
ancho del sistema distribuido a través de bloques de construcción de más alto nivel que el de
las interfaces de programación de aplicaciones (APIs). En términos figurados, se asemeja a un
proveedor de tuberías ya que permite conectar distintas partes de un sistema distribuido por
medio de estas "tuberías" y para luego pasar un flujo de datos entre las partes conectadas.

El propósito del Middleware es enmascarar la heterogeneidad y proveer un modelo de


programación que se representa mediante procesos ejecutándose sobre un conjunto de
computadores que interactúan entre sí; para implementar mecanismos de comunicación y
recursos compartidos para aplicaciones distribuidas. También aporta con los elementos
necesarios para la construcción de componentes de software que puedan trabajar con otros
similares en un sistema distribuido. Por lo que mejora el nivel de comunicación de los programas
ya que soporta abstracciones como: procedimientos de invocación remota, comunicación
entre grupos de procesos, notificación de eventos, replicación de datos compartidos y
transmisión de datos multimedia en tiempo real.

FUNCIONES DEL MIDDLEWARE


Sus funciones pueden ser divididas en tres categorías:
a) Middleware para aplicaciones especificas. Proporciona servicios para varias clases de
aplicaciones como ser: bases de datos distribuidas, transacciones, servicios
especializados para multimedia y computación móvil.

b) Middleware de intercambio de información. Categoría que gestiona los intercambios de


información a través de las redes. Usado por las aplicaciones en tareas como:
transferencia de datos, ejecución de procedimientos, recepción de respuestas y
resolución de conflictos.

c) Middleware para administración y soporte. Incluye productos para localización de


recursos, comunicación con servidores, manejo de seguridad y control de fallos.

La implementación de un Middleware permite: automatizar las operaciones del negocio,


conectar aplicaciones dispares y diferentes como aplicaciones web y antiguas aplicaciones
heredadas de sistemas centralizados, aplicaciones existentes con nuevos sistemas y aplicaciones
preservando así la inversión. Por ejemplo, en el segmento del comercio electrónico ayuda a
conectar aplicaciones de producción, ventas y contabilidad con modernas aplicaciones
basadas en Internet.

Un Middleware (ver Figura No.1) implementado de forma apropiada puede ayudar a:

- Proteger a los desarrolladores de software de detalles vinculados a la plataforma y la


programación de sockets.
- Proveer un conjunto de abstracciones de alto nivel disponibles para responder a peticiones
de distintas aplicaciones simplificando el desarrollo de sistemas distribuidos.

- Proporcionar un amplio conjunto de servicios de control de acceso y seguridad requeridos


para operar de forma efectiva en un ambiente de redes e interconexiones. Un Middleware
podría incluir servicios que incluyen seguridad y soporte a transacciones.

Host A Host B

Aplicacion Distribuida Aplicacion Distribuida

API Middleware API Middleware

Middleware Middleware

API Sistema Operativo API Sistema Operativo

Comunicaciones Procesamiento Almacenamiento Comunicaciones Procesamiento Almacenamiento

Sistema Operativo Sistema Operativo

Red

Figura No. 1: Capas Middleware


Elaboración propia

CATEGORÍAS DEL MIDDLEWARE


Existen diferentes tipos, todos ellos varían en términos de las abstracciones de programación que
proporcionan, así como de las clases de heterogeneidad soportadas mas allá de aquellas
encontradas en las redes y el hardware. Las categorías de Middleware incluyen:

a) Middleware de Base de Datos


Las Bases de Datos Distribuidas ofrecen la abstracción de tuplas distribuidas, y proveen un
lenguaje de consulta (SQL) que permite a los programadores manipular estos conjuntos de
tuplas. Hace posible que las aplicaciones puedan comunicarse con una o más bases de datos
locales o remotos.

b) Middleware para Llamadas a Procedimientos Remotos (RPC)


Este tipo de Middleware extiende la interfaz del llamado a procedimiento local y ofrece una
abstracción de una invocación a un procedimiento cuyo código se encuentra en otra parte de
la red.

c) Middleware orientado a mensajes (MOM)


Provee la abstracción de una cola de mensajes que pueden ser accedidos mediante la red. Se
basa en una generalización de un buzón de correo donde los programas pueden depositar o
retirar mensajes de colas, cuya gestión y administración las realiza este middleware.

d) Middleware de Objetos Distribuidos


Provee la abstracción de un objeto remoto cuyos métodos pueden ser invocados de la misma
manera como si el objeto estuviese en el mismo espacio de direcciones del proceso que realiza
la petición. Los objetos distribuidos implementan todos los beneficios de las técnicas del enfoque
de orientación a objetos como ser la encapsulación, herencia y polimorfismo, las cuales están
disponibles para el desarrollo de aplicaciones distribuidas.

CORBA (Common Object Request Broker Architecture) es el estándar para la implementación


de objetos distribuidos. Desarrollado por Object Management Group (OMG), se constituye en el
Middleware disponible más difundido. Aparte de proveer una abstracción para objetos
distribuidos, proporciona a los desarrolladores un soporte para aplicaciones distribuidas de
propósito general, a través de mecanismos que ocultan la heterogeneidad de los lenguajes de
programación. Sus estándares son públicos y bien definidos. CORBA es considerado por muchos
como el Middleware más avanzado así como el más utilizado comercialmente.

DCOM es la tecnología de distribución de objetos de Microsoft que incluye OLE (Object Linking
and Embedding) y COM (Component Object Model). La abstracción de objetos de DCOM es
incrementada por otras tecnologías de Microsoft como el Transaction Server y Active Directory.
SOAP (basado en XML y HTTP) y .NET también proveen de soporte a la heterogeneidad de
lenguajes y el hardware.

El RMI (Remote Method Invocation) de Java posee similar abstracción de objetos distribuidos
que CORBA y DCOM. RMI provee soporte a la heterogeneidad en sistemas distribuidos solo en
entornos Java. Sin embargo, permite una fuerte integración con otras características de Java
que facilitan la programación y proveen una gran funcionalidad.

Si bien, todos los tipos realizan funciones de comunicación; el tipo de Middleware a seleccionar
depende exactamente de las necesidades de acceso e información que se requieran.

MIDDLEWARE Y SISTEMAS DISTRIBUIDOS


El Middleware proporciona un modelo computacional uniforme a programadores de
aplicaciones distribuidas que incluyen: invocación de objetos remotos, notificación de eventos
remotos y procesamiento distribuido de transacciones. Por ejemplo, CORBA proporciona la
invocación de objetos remotos permitiendo que un objeto en un programa invoque un método
de un objeto de otro programa que se ejecuta en otro computador.

Para los propósitos de un sistema distribuido, el middleware proporciona: Transparencia de


ubicación, Independencia de los detalles (protocolos, software y hardware) y algunas de sus
formas admite que componentes estén escritos en diferentes lenguajes.

Transparencia frente a ubicación: En RPC, el cliente que llama a un procedimiento no puede


discernir si el procedimiento se ejecuta en el mismo proceso o en otro diferente y posiblemente
en otro computador. El proceso Cliente no necesita conocer la ubicación del servidor; de forma
análoga sucede con RMI.

Protocolos de comunicación: Los protocolos que dan soporte a las abstracciones del
Middleware son independientes de los protocolos de transporte. Ejemplo: El protocolo petición -
respuesta puede estar implementado en UDP o TCP.

Hardware de las computadoras: Se emplean en el empaquetado y desempaquetado de los


mensajes. Ocultan diferencias de arquitectura en el Hardware.

Sistemas Operativos: Las abstracciones de mayor nivel que provee la capa del Middleware son
independientes de los Sistemas Operativos subyacentes.

CAPAS DE MIDDLEWARE
Pueden coexistir múltiples capas de Middleware presentes en la configuración de un sistema. Un
servicio de difusión virtual puede ser usado directamente por las aplicaciones. Es común el uso
de Middleware como módulos de construcción para construir otros Middleware de más alto
nivel, como por ejemplo, el proveer tolerancia a fallas. Entre los middleware de más alto nivel se
encuentran CORBA y MOM.

La mayoría de los Middleware pertenecen a la capa de Aplicación (Capa 7 del Modelo OSI), y
sus componentes en la capa de Presentación (Capa 6). Por lo que se podría decir que, el
Middleware es una “aplicación” para los protocolos de red presentes en el sistema operativo.

PROGRAMACION CON MIDDLEWARE


Los programadores no tienen que aprender un nuevo lenguaje y es común usar lenguajes como
C++ o Java.

Existen tres formas de desarrollar Middleware con los lenguajes existentes. La primera, es cuando
el Middleware provee una librería de funciones que deben ser llamadas para utilizar sus servicios.
Los sistemas de Bases de Datos Distribuidas hacen precisamente esto. La segunda es usar un
lenguaje de definición de Interfaz (IDL) externo. Bajo esta modalidad, un archivo IDL describe la
interfaz para el componente remoto. La tercera forma se realiza por medio de un lenguaje que
soporta la distribución de forma nativa, tal el caso de Java RMI (Remote Method Invocation).

MIDDLEWARE Y LA ADMINISTRACIÓN DE RECURSOS


Las abstracciones ofrecidas por varios sistemas de Middleware pueden ser usadas para proveer
una administración de recursos al más alto nivel en un sistema distribuido, esto se logra,
incluyendo estas abstracciones en las tres clases de recursos físicos a cargo del sistema
operativo: comunicaciones, procesamiento y almacenamiento (memoria y disco).

Estas abstracciones abarcan una perspectiva global permitiendo una vista completa para la
administración de recursos, ya que no están recluidas a un solo host. Por tanto, las
abstracciones de programación del Middleware también incorporan procesamiento y
almacenamiento. La Tabla 1 muestra el grado en que las categorías de Middleware
encapsulan e integran estos recursos.

Tabla 1: Encapsulación e Integración de Recursos

Categorias de Middleware Comunicación Procesamiento Almacenamiento


Base de Datos Distribuidas Si Limitado Si
RPC Remote Procedure Call Si Si No
Message-Oriented Middleware Si No Limitado
Objetos Distribuidos Si Si Si

El modelo de Base de Datos Distribuidas solo ofrece una limitada forma de procesamiento para
el cliente. RPC no integra al almacenamiento, mientras que MOM no incluye el procesamiento.
Los objetos distribuidos, no solamente encapsulan estos tres tipos de recursos, sino también que
los integran en un paquete, lo que permite una administración de recursos distribuidos así como
proveer diferentes clases de transparencia (acceso, movilidad y ubicación).

CONCLUSIONES
El Middleware es una capa de software que provee una abstracción de programación y oculta
las diferencias de redes, hardware, sistemas operativos y lenguajes. Se constituye en software
que reside entre las aplicaciones y las capas subyacentes al sistema operativo, pilas de
protocolos y hardware.

El diseño del Middleware busca ocultar los diferentes tipos de heterogeneidad con la que los
programadores deben tratar, tal el caso de hardware y las redes. Muchos sistemas Middleware
ocultan las marcadas diferencias entre sistemas operativos y lenguajes de programación. Las
abstracciones de programación proporcionadas por el Middleware otorgan transparencia
respecto a la distribución en una o más de las siguientes dimensiones: localización,
concurrencia, replicación, fallas y movilidad. El Middleware puede ser considerado como un
software que hace que un sistema distribuido sea programado.

Hasta la fecha varias tecnologías han sido ideadas para alivianar la gran complejidad asociada
con el desarrollo de software para aplicaciones distribuidas. Su éxito ha añadido una nueva
categoría de sistemas de software a la gran familia de sistemas operativos, lenguajes de
programación, redes y bases de datos.

Desde el punto de vista funcional, el rol del Middleware es cubrir la brecha entre los programas
de aplicación y el hardware de bajo nivel y la infraestructura de software a objeto de coordinar
la forma en que las aplicaciones son conectadas y como estas operan entre ellas. Asimismo
permite y a la vez simplifica la integración de componentes desarrollados por múltiples
proveedores de tecnología.

Referencias
1. Bernstein, P. "Middleware: A Model for Distributed System Services." Communications of the
ACM. February 1996.
2. Birrel, A. Y Nelson, B. "Implementing remote procedure calls" ACM Transactions Computer
Systems, vol. 2. 1984.
3. http://www.sun.com. Sun Microsystems. Java Remote Method Invocation.
4. http://www.omg.org
RESUMEN DE UNA NOTICIA DE PRENSA: UN PRETEXTO PARA
TENER PRESENTE EL PROCESAMIENTO DEL LENGUAJE NATURAL
Lucio Torrico Diaz
Docente investigador
luciotorrico@gmail.com
iii.umsa.bo

RESUMEN
Se resume una noticia de prensa utilizando algunos rudimentos de la recuperación de información y el procesamiento del lenguaje
natural.
Subterfugios como este, son útiles para presentar nuevas ideas, hacer un repaso del estado del arte o –como en este caso- recordar
que el Procesamiento del Lenguaje Natural y la Recuperación de Información existen (como uno de los más bellos capítulos de la
Informática) evocando algunos de su muchos conceptos.

PALABRAS CLAVE: Procesamiento del lenguaje natural. Recuperación de Información. Resumen


de textos. Ley de Zipf. Luhn

KEYWORDS: Natural language procesing. Information Retrieval. Text abstract. Zipf’s law. Luhn

INTRODUCCIÓN
En el Anexo se tiene el cuerpo de una noticia de prensa (sin (sub)títulos); se quiere un resumen
de él.

Esta tarea supone que el texto tiene sentido y no es una secuencia aleatoria de símbolos y/o
palabras.

El enfoque para resumir un documento difiere dependiendo de su idioma, de si el texto está


dividido en campos tales como autor, palabras clave, etc., es decir, si está (semi)estructurado o
no; y de otras consideraciones.

De hecho la tarea empieza con la obtención del documento digitalizado y de la determinación


de su codificación (por ej. utf-8). Aquí supondremos que el texto está en español, digitalizado
bajo un estándar abierto (por ej. PDF) y (prescindiendo del títulos y subtítulos) se considera que
su estructura no pasa de párrafos, oraciones, etcétera).

ENFOQUE ESTADÍSTICO DE EXTRACCIÓN

En principio puede hacerse un tratamiento estadístico apoyado en ideas generalmente


aceptadas.

Se extraen las oraciones (o cualquier otra secuencia, por ej. párrafos) consideradas más
relevantes según algún criterio.

Ello significa tokenizar el documento: hacer una lista de palabras. Aunque parece una tarea
sencilla, no es así. No basta utilizar alguna función de split o un match a través de expresiones
regulares; debe tenerse en cuenta si los números serán considerados, si hay palabras con dígitos,
números y símbolos mezclados (por ej. utf-8), si algunos nombres deben o no partirse, qué hacer
con las abreviaturas, los signos de puntuación, entre otros.

Un documento muy extenso (en Mbytes o Gbytes) podría requerir la intervención de


herramientas de compresión y uso eficiente de memoria.

La Ley de George Zipf (1949) establece que, en un texto, la enésima palabra más común ocurre
con una frecuencia inversamente proporcional a n (respecto de la primera) [2]. Esta ley ha
generado importantes estudios y consecuencias; y ha sido verificada y establecida de manera
más general por Mandelbrot. La implementación práctica en nuestro caso es obtener el
diccionario de palabras a partir de la lista de tokens, junto a sus rangos:
Tabla No. 1: Palabras de la noticia de prensa y cantidad de apariciones (fragmento)
Elaboración propia
LA 49 Y 8
DE 29 PODEMOS 7
EL 18 UNA 7
… … … …
NO 13 PARA 4
A 11 POR 4
LOS 10 … …
SE 10 VíA 1

Por ejemplo, la 1° palabra (la más frecuente) es “LA” (la conversión a mayúsculas vía una
función upercase no afecta el resultado) y aparece 49 veces; la 208° palabra (una de las menos
frecuentes, aquí aparece en último lugar por un mero orden lexicográfico) es “YA” y ocurre 1
vez.
Las cantidades de veces que aparecen las palabras desde la que ocurre más hasta la que
ocurre menos son: 49 (una palabra), 29, 18, 16, 15, 13, 11 10 (dos palabras), 8, 7, 5, 4, 3, 2 y
1(ciento cuarenta y tres palabras).
A partir de la ley de Zipf, Luhn ha postulado que las palabras más frecuentes son las que ocurren
en casi todos los documentos, y las menos frecuentes son tales que su aparición es casi
anecdótica en un documento [2]. Es decir, que las palabras que son parte de la esencia de un
documento (y de ahí que deben estar en su resumen) son las de frecuencia media de aparición
(en relación a las más y las menos frecuentes).
En nuestro caso, consideramos las palabras que aparecen 7 veces, u 8 ... o 16 veces. Estas son
las elegidas: {QUE, EN, NO, A, LOS, SE, CONSTITUCIÓN, Y, PODEMOS}
Luego, separamos las oraciones del documento (consideramos el punto como separador entre
oraciones) y elegimos aquellas que contienen dichas palabras (una o todas), en realidad
seleccionamos las oraciones que tengan más ocurrencias de ellas). Con este criterio, el resumen
es:
Mientras Podemos ratificó que no dará luz verde a una convocatoria sin que antes se reforme el
proyecto oficialista de nueva Constitución, el MAS respondió que no se someterá a los chantajes
de la oposición.
Que tiene 12 ocurrencias del grupo de palabras elegidas.

ENFOQUE ESTADÍSTICO DE EXTRACCIÓN CON APOYO LINGÜÍSTICO


Una refinación interesante consiste en no incluir en la lista de palabras elegidas aquellas que
sean vacuas o nulas (es decir, sin mayor interés en un texto). Estas palabras se conocen más
popularmente con el nombre de “stop words” y se agrupan en una “stop list” (son del tipo que,
en, los, se, y, etc.). Es común utilizar stop words de repositorios públicos y añadirles palabras
según el trabajo que se esté realizando.
Visto así, el nuevo conjunto de palabras elegidas es: {CONSTITUCIÓN, PODEMOS}. Y la selección
de oraciones (como se hizo antes) devuelve tres. La de arriba en negrita y las dos siguientes:
“No vamos a viabilizar en el Congreso ninguna fecha para aprobar la Constitución si no
se revisan algunos elementos mínimos de esa Constitución”, advirtió Hoz de Vila, mientras
Fernández dijo que “nosotros vamos a viabilizar un referéndum donde se incorporen a mayorías
y minorías; no vamos a viabilizar un referéndum con cerco, ni con palos, ni con piedras”.
“Nosotros hemos luchado por la Constitución, los prefectos han luchado por autonomía
en su región; nosotros hemos luchado aquí en La Paz, en la plaza Murillo; hemos luchado en
Sucre, en Oruro; porque los abusos de la imposición masista en la Constitución no están sólo en
la parte de autonomía”, señaló Quiroga.
Cada una de ellas con 2 ocurrencias del nuevo conjunto de palabras elegidas.

No es el caso de este ejemplo, pero en otros contextos ocurren mejoras dramáticas si se


seleccionan oraciones con muchas ocurrencias de la nueva lista de palabras elegidas o de sus
variantes.
Estas variaciones pueden detectarse a través de stemming y lematización, es decir, de manera
que las ocurrencias cuenten si la palabra en una oración y la palabra elegida son equivalentes
en su tronco o en su lema.
Una forma muy ruda de ver esto es si sus prefijos son iguales: por ejemplo constitucional y
constitución son palabras de tronco equivalente.
Y la selección de oraciones (como se hizo antes) con esta nueva aproximación, son todas las
anteriores a las que se agregan dos candidatas más:
Podemos y el MAS anticiparon ayer una nueva batalla en el Congreso, esta vez por la
aprobación de la ley de convocatoria a los referendos constitucionales.
El jefe de Podemos, Jorge Quiroga, y los senadores Tito Hoz de Vila y Fernando Rodríguez
señalaron que no aprobarán un referéndum para dar curso a un texto constitucional observado,
al que se hubieran incorporado cambios sólo en el tema de autonomía, como piden los
prefectos.

Si nuestro criterio de extracción asciende de oraciones a párrafos, no consideramos stop words y


utilizamos stemming entonces el párrafo seleccionado es:
Mientras Podemos ratificó que no dará luz verde a una convocatoria sin que antes se reforme el
proyecto oficialista de nueva Constitución, el MAS respondió que no se someterá a los chantajes
de la oposición.
Podemos y el MAS anticiparon ayer una nueva batalla en el Congreso, esta vez por la
aprobación de la ley de convocatoria a los referendos constitucionales.
OTROS ENFOQUES
El párrafo seleccionado coincide con un criterio humano pero muy utilizado: puede considerarse
el primer párrafo de una noticia como su resumen.
Además de este criterio existen muchos otros criterios, herramientas y técnicas que pueden
competir con el criterio estadístico o complementarlo:
Resúmenes por abstracción, n-gramas, modelos vectoriales, centroides, regla del coseno,
tratamiento lingüístico previo o posterior (etiquetado, identificación de verbos, sustantivos, etc.),
detección de relaciones y significados, sinonimia, y un largo etcétera.

Discusión de resultados y conclusiones.


Se ha obtenido un resumen por extracción cuya calidad –a juicio del autor- no es mala.
Sin embargo, la discusión más importante es si en nuestro contexto tenemos presente (y en
desarrollo) el Procesamiento del Lenguaje Natural y la Recuperación de Información o es
necesario revivirlas.

Agradecimientos
Agradecemos la colaboración de Avril Torrico en la programación de los scripts en Ruby y manjo
de las hojas electrónicas que se han utilizado en el trabajo.

Referencias

5. http://www.la-razon.com/versiones/20080925_006406/nota_249_677586.htm
[accesado el 25/09/2008].
6. http://irsweb.blogspot.com/2005/04/luhn-zipf-y-los-tn.html
[accesado el 25/09/2008].
ANEXO

Podemos y el MAS anticiparon ayer una nueva batalla en el Congreso, esta vez por la
aprobación de la ley de convocatoria a los referendos constitucionales.

Mientras Podemos ratificó que no dará luz verde a una convocatoria sin que antes se reforme el
proyecto oficialista de nueva Constitución, el MAS respondió que no se someterá a los chantajes
de la oposición. Podemos replicó que ofrecerá resistencia ante la imposición.

El jefe de Podemos, Jorge Quiroga, y los senadores Tito Hoz de Vila y Fernando Rodríguez
señalaron que no aprobarán un referéndum para dar curso a un texto constitucional observado,
al que se hubieran incorporado cambios sólo en el tema de autonomía, como piden los
prefectos.

“Nosotros hemos luchado por la Constitución, los prefectos han luchado por autonomía en su
región; nosotros hemos luchado aquí en La Paz, en la plaza Murillo; hemos luchado en Sucre, en
Oruro; porque los abusos de la imposición masista en la Constitución no están sólo en la parte de
autonomía”, señaló Quiroga.

“No vamos a viabilizar en el Congreso ninguna fecha para aprobar la Constitución si no se


revisan algunos elementos mínimos de esa Constitución”, advirtió Hoz de Vila, mientras
Fernández dijo que “nosotros vamos a viabilizar un referéndum donde se incorporen a mayorías
y minorías; no vamos a viabilizar un referéndum con cerco, ni con palos, ni con piedras”.

Señaló que si la aprobación se da de esta forma, la Constitución “durará lo que dure el gobierno
de Evo Morales”. Hoz de Vila aclaró que no se trata de obstaculizar el proceso de pacificación,
sino de exigir una Constitución para todos.

“No vamos a someternos al chantaje de una minoría electoral contra el país, contra la
democracia y contra el proceso de cambio”, respondió el jefe de bancada del MAS en
Diputados, César Navarro. Cuando se le consultó cómo lo harán sin los votos de Podemos,
respondió: “eso lo vamos a discutir en el Congreso”.

Sin la votación de Podemos no es posible lograr los dos tercios necesarios para la aprobación.

El senador Ricardo Díaz (MAS) dijo que “en Podemos existe una división interna, donde cada vez
son más los disidentes y ya no deben sentirse seguros de contar con todos sus diputados y
senadores”.

No obstante, Rodríguez anticipó que resistirán una aprobación por la vía de la imposición.

Mientras tanto, el Poder Judicial se sumó al pedido de realizar ajustes al proyecto de texto
constitucional. El consejero de la Judicatura, Rodolfo Mérida, anunció que elaboran un
documento sobre los ajustes que consideran necesarios al proyecto de Constitución y que
podrían ser expuestos en el contexto del diálogo de Cochabamba. “En el Poder Judicial
sostenemos que no se debe asumir una posición a uno ni otro sector”, aclaró. [1]
RECURSO DIDÁCTICO PARA PROGRAMACIÓN ORIENTADA A
OBJETOS

RESUMEN
Recurso didáctico, también llamado tutor interactivo para programación orientada a Menfy Morales Ríos
objetos (POO), se basa en el contenido de la materia de segundo semestre Docente – Investigador
“Algoritmos y programación” de la Carrera de Informática, UMSA. menfymorales@hotmail.com

Es un recurso didáctico multimedia, maneja recursos visuales dinámicos e interactivos Participantes en el proyecto:
para que el estudiante pueda interactuar.
Carlos R. Fernández Lino
Estudiante – Investigador
Representamos el conocimiento a través de imagen, color, animación y se trata de carlos_roberto_fl@yahoo.es
reducir al mínimo el texto.
Jaime Chura Patti
Se divide en cuatro capítulos, los cuales contienen conceptos, polimorfismo, herencia y Estudiante – Investigador
agregación.
Juan Pablo Poma Chura
Los que a su vez tienen una parte de ejemplos, conectados a un link para su respectiva
Estudiante - Investigador
representación en seudolenguaje orientado a objetos (SOO) y su traducción en Java. Jupa1986@yahoo.es
El aporte principal de este tutor interactivo son los distintos ejercicios desarrollado en
SOO.

PALABRAS CLAVE: Recurso didáctico, clase, seudolenguaje, POO, constructor, herencia,


composición, agregación, polimorfismo, sobrecarga, objeto, encapsulamiento, SOO.

1. INTRODUCCIÓN
El objetivo del proyecto es desarrollar e implementar recursos didácticos informáticos en la
Carrera de Informática, en este caso particular para la materia “Algoritmos y Programación”.
Este recurso didáctico o tutor interactivo ha utilizado herramientas tales como el dreamweaver,
flash, Swish, html, homesite, javascript, actionscript, html y otros.
Este recurso se basa en el contenido regular de la materia “Agoritmos y Programación” que es
programación orientada a objetos (POO), propone un seudolenguaje orientado a objetos (SOO)
para la representación de los algoritmos orientados a objetos, utiliza el diagrama UML,
(modelamiento de lenguaje unificado), para representar las clases y las asociaciones entre
clases. A pesar de que muchos ejemplos son bastante extensos, estos están a disposición de los
estudiantes en formato PDF el que se describe a través de un SOO y el código en lenguaje de
programación JAVA.

2. RECURSO DIDÁCTICO PARA POO


El recurso didáctico o tutor interactivo INF-121, para POO, utiliza recursos multimedia para
realizar de una manera amigable, dinámica y llamativa el desarrollo del contenido.
En esta primera etapa se realiza un desarrollo completo de los conceptos que involucran la
definición de POO, como ser el objeto, la clase, el método, el mensaje, el proceso de
abstracción y encapsulamiento. Además conceptos de TDA tipos de datos abstractos para
entrar al desarrollo del seudolenguaje. Así como los conceptos de constructor y destructor.
A través de ejemplos desarrollados en SOO y el lenguaje de programación JAVA.

El equipo de trabajo ha intentado buscar un mecanismo que permita visualizar los cuatro
capítulos del tutor para ello se utiliza el siguiente formato como muestra la figura 1.
Figura No. 1: Pantalla que describe un objeto

En la parte superior de la figura 1, se puede observar los botones correspondientes a los cuatro
capítulos del tutor interactivo. La parte derecha nos permite hacer una descripción textual del
concepto correspondiente de la manera más resumida posible (el tutor interactivo ha tratado
de reducir al mínimo la descripción textual). La parte izquierda nos permite visualizar a través de
animación el concepto que se está describiendo. Los botones en la parte superior izquierda nos
permiten acceder a distintos ejemplos que también a través de animación tratan de reflejar el
concepto que se describe.

En la parte superior derecha existen dos botones, el de ayuda, que da una descripción general
del tutor y su navegabilidad, y el botón de índice, a través del cual se puede direccionar al
tema que se desee consultar.

La figura 2, nos introduce al tema de asociación, con el concepto de composición, a diferencia


de la anterior figura, esta incorpora dos botones en la parte inferior izquierda, el primero nos
indica que el ejemplo que se esta visualizando (el cuerpo humano compuesto por brazo y pie)
tiene su correspondiente algoritmo desarrollado en seudolenguaje orientado a objetos, el
segundo botón nos indica que además este ejemplo tiene su correspondiente traducción al
lenguaje JAVA (el que a través de una descarga de la carpeta correspondiente funciona al
ejecutarla, sin tener que hacer adecuaciones al código).

Figura No. 2: Pantalla que describe composición


El tutor interactivo ha sido estructurado en cuatro capítulos:
En el primer se describen los siguientes conceptos: Qué es POO, objeto, clase, método, mensaje,
encapsulamiento y abstracción.
En el segundo se describe: Polimorfismo, funciones polimórficas, operadores polimórficos, unarios
y binarios.
En el tercer capítulo se describe: Herencia Simple, herencia múltiple.
En el cuatro capítulo se describe: Asociaciones, agregados y composición.

Este tutor interactivo es un recurso didáctico multimedia, diferente a un software educativo


debido a que no cuenta con una evaluación en línea.

Los pasos que se han seguido para el desarrollo de este tutor interactivo han sido los siguientes:

1. Para el desarrollo:

 Esbozar un documento que describa textualmente los capítulos de Conceptos,


Polimorfismo, Herencia y Asociación.
 Esbozar un documento con distintos ejemplos relacionados a los anteriores capítulos
mencionados.
 Seleccionar distintos ejemplos que se adecuen a los capítulos
 Estudiar e investigar herramientas multimedia
 Identificar, seleccionar ejercicios o ejemplos a los que se pueden dar animación
 Desarrollar estilos de animación para cada tipo de ejercicio y/o ejemplo.
 Buscar la forma de crear interactividad con el estudiante.
En esta etapa, se han dispuesto responsables, como se muestra en la tabla 1:

Tabla No. 1: Tabla de responsabilidades


Fuente: elaboración propia

Actividades Responsable
Concepto Lic. Menfy Morales
Polimorfismo Lic. Menfy Morales
Herencia Univ. Jaime Chura
Asociación Univ. Carlos Fernández
Formato del tutor Univ. Juan Pablo Poma
Revisión de conceptos Todos los miembros
Revisión de Polimorfismo Todos los miembros
Revisión de Herencia Lic. Menfy Morales
Revisión de Asociación Lic. Menfy Morales
Revisión de Seudolenguaje Lic. Menfy Morales
Revisión y ejecución de programas en JAVA Lic. Menfy Morales

2. Para la prueba
 Seleccionar estudiantes con cero conocimientos acerca de POO
 Preparar el material correspondiente (quemar CD´s con el tutor interactivo)
 Distribuir aproximadamente 60 CD’s a los estudiantes del paralelo B de INF-121, gestión
(2/2008)

3. Para la evaluación
 Aplicar evaluaciones continuas
 Evaluación acerca de los distintos temas.
 Evaluación acerca de entorno del tutor interactivo

Discusión de resultados y conclusiones.


El tutor interactivo esta diseñado para ser una herramienta de apoyo en la asignatura de
“Algoritmos y programación”, el mismo que se puede conseguir a través de CD o del servidor
del Instituto de Investigación de Informática. La versión P. es una versión prueba, la que ha sido
implementada en la materia de INF-121 del paralelo D en la gestión 2/2008. Se puede
mencionar que este tutor interactivo ha tenido bastante expectativa por los alumnos de la
materia.
Se han repartido aproximadamente 60 CD´s, a los estudiantes de este curso, para que ellos
puedan someterse a dos tipos de evaluaciones.

Primero, se ha evaluado la presentación del tutor en general, para lo que se han considerado
los siguientes criterios: (1. Muy Adecuado 2. Adecuado 3. Inadecuado)
Las variables que se han medido son las siguientes: Acceso, útil, interactivo, aprendizaje, color,
entendible, ejemplos, uso.
Se han obtenido los siguientes resultados, como se muestra en la Tabla 2:

Tabla No. 2: Encuesta realizada acerca de algunos indicadores


Fuente: elaboración propia

Indicadores Muy Adecuado Inadecuado


adecuado
Acceso 43% 54% 3%
Útil 60% 40% 0%
Interactivo 33 50 17
Aprendizaje 20 80 0
Color 33 44 23
Entendible 27 66 7
Ejemplos 27 46 27
Uso 33 60 7

Una de las variables que nos interesa es “Aprendizaje”, y como se muestra, rescatamos
el 80 % de los estudiantes que lo probaron, opinan que es “Adecuado”

Segundo se ha evaluado el contenido del tutor, para ello se han realizado


evaluaciones continuas de los distintos temas del tutor a través de un cronograma
planificado. De tal manera se han obtenido los siguientes resultados:
Los alumnos se presentaron a unas evaluaciones y a otras no. Para nuestra muestra es
necesario hacer una limpieza, y considerar todas las evaluaciones, quedando
aproximadamente 15 estudiantes bajo esta condición. Además para poder realizar
una comparación, se tomo en cuenta el rendimiento de los alumnos de la gestión
(1/2008), a este grupo también se tuvo que hacer una limpieza de datos,
considerando a aquellos que hicieron todas las pruebas de esta parte. Para que el
análisis sea lo más claro posible. De estos dos grupos se puede mencionar lo siguiente,
ver tabla 3:
Tabla No. 3: Porcentaje de rendimiento con el tutor
Fuente: elaboración propia

Con tutor Sin tutor


% de aprobados 80 % 49 %
% de reprobados 20 % 57 %

Se pueden dar distintas interpretaciones a la tabla 2, sin embargo es necesario


mencionar que el tutor interactivo (recurso didáctico) es por si mismo un gran apoyo al
proceso de aprendizaje. Se logro subir el porcentaje de aprobación en un curso
regular de la materia.

Algunas recomendaciones que nacen de ambas evaluaciones, son la siguiente:


 Completar los temas de POO, como ser funciones amigas, plantillas,
asociaciones (uno a uno, uno a varios y varios a varios ) , clases virtuales,
funciones virtuales
 Adicionar mas ejemplos en cada uno de los capítulos
 Mejorar el color
 Adicionar Sonido (componente de multimedia)
 Incrementar la teoría en cada capítulo (aumentar texto)
 Permitir la impresión de la parte conceptual - teórica

Se podría pensar en una versión 2. Con todas estas recomendaciones

Agradecimientos.
A todos las personas que nos permiten re-usar código, como algunos ejemplos de
script que se puede bajar de la web. A todos los alumnos de INF-121 gestión 2/2008,
que han tenido la voluntad de usar el tutor y nos ha permitido evaluar tanto su
contenido como su forma. A todos los docentes de la materia que con su expectativa
han logrado impulsar mas este proyecto. A los universitarios investigadores, con su
apoyo desinteresado han hecho posible que este tutor llegue a la etapa de
evaluación, permitiendo de esta manera adelantar el cronograma planificado.
Gracias.

Referencias
7. Joyanes, 1998. Programación Orientada a Objetos,
8. Ceballos 2003. Programación en JAVA.
9. Flash MX, paso a paso, Joel de la Cruz Villar, Ed. MegaByte.
10. Flash MX, Curso Práctico, José Luis Oros, Ed. Alfaomega, 2003, México.
11. James Martin, Diseño Orientado a objetos.
12. Grady Booch, James Rumbaugh, Ivar Jacobson, 2000, El lenguaje unificado de modelado.
13. David Flanagan, 1999, Java ina nutsehell.
14. Laura Lemay y Charles L. Perkins, 1996, Aprendiendo Java.

HUMANITIES COMPUTING: Iniciativas Digitales en


Humanidades

RESUMEN
El presente artículo ofrece una visión actual sobre lo que se entiende por Humanities
Computing o Digital Humanities, simbiosis que surgió entre las disciplinas de
Humanidades y la informática, y que se ha ido convirtiendo en un importante foco
de atención investigadora en cuanto a formación, contenidos y métodos basados
en las nuevas tecnologías en las disciplinas Humanísticas . Brígida Carvajal Blanco
Docente - UMSA
Carrera de Informática
brigidacarvajl@yahoo.com
www.materias.webnode.com

PALABRAS CLAVE:. Humanidades Digitales. Nuevas Tecnologías. Fuentes de Información.


Metodologías
KEYWORDS: Digital Humanities. New Technologies. Resources of Information. Metodologies.

Digital Humanities, o como se traduce en otros idiomas: Humanidades e informática,


Humanidades Digitales, Humanistisk Informatik o también Humanities Computing, se refiere a
una disciplina surgida en los países angloamericanos. El 1999 en el debate organizado por la
ACM (Association for Computing Machinery) se la definió como una disciplina académica
independiente con sus organizaciones profesionales, conferencias regulares, revistas y sus
centros y departamentos concediendo gran importancia a que no es el simple hecho de usar la
computadora en Humanidades como herramienta sino también son importantes las cuestiones
teóricas, sobre el ‘cómo’ y el ‘qué’ en el uso de la computadora, manifestando una actitud
filosófica hacia este medio.

Citando a Renear, el destaca el interés en nuestro tiempo, por la cultura digital en general y
todo lo que abarca este concepto:

“… Humanities Computing tiene un interés analítico general en la cultura digital, conduciendo


análisis multi-disciplinarios con sistemas multimedia, tecnologías educativas, uso de la tecnología
en el arte así como su uso en publicaciones y en la comunicación … “[4].

En sí, el enfoque de esta disciplina se caracteriza, por su interdisciplinariedad ya que para hacer
un uso efectivo de la informática en humanidades se necesitan aplicar conocimientos
relacionados con otros campos del saber, especialmente de la ciencia de la computación,
información y comunicación. Este es el momento de integrar tanto los conocimientos de las
materias de humanidades y muchas facetas de la informática y las nuevas tecnologías,
generando así nuevas disciplinas como por ejemplo, la historiografía digital.

Las actividades de Humanities Computing pertenecen ante todo al área de Humanidades y no


así a la Informática, de ahí que no se centra en la pura aplicación del know-how tecnológico,
sino en el conocimiento de metodologías comunes en el campo de la investigación. Por lo tanto
la computadora en Humanidades adquiere un estatus bastante diferente en contraste, quizás,
con la todavía muy extendida disposición entre los tradicionales investigadores humanistas con
sentimientos de rechazo, miedo o incluso menosprecio.

La disciplina como tal contribuye a las metodologías y a la transmisión de pensamiento a través


del uso de la informática ya que son las cuestiones filosóficas y el desarrollo del pensamiento
crítico a los que está enfocado Humanities Computing y no al uso puramente de la herramienta
como tal. No obstante, se debe reconocer el rol de las nuevas tecnologías ya que han llevado a
transformar los métodos de investigación en Humanidades. Desarrollando el uso de técnicas y
equipos sofisticados de digitalización, dispositivos de almacenamiento de alta capacidad,
procesadores poderosos, técnicas de procesamiento de imágenes, dispositivos de despliegue
visual de alta calidad y muchos otros productos de avances tecnológicos que recientemente se
encuentran disponibles en el mercado.

En si, las tecnologías ayudan como herramienta de trabajo a estudiar e investigar los
tradicionales campos humanísticos de forma más eficiente, por otra parte, encontramos nuevos
métodos y objetos de estudio que se están incorporando en Humanidades donde es necesario
el desarrollo de métodos adecuados. Como el uso de la simulación, de los mismos juegos de
computadoras, o las nuevas formas de arte que van surgiendo.

Claro que, los métodos del pasado no se han quedado obsoletos, pero el empuje hacia estudios
computacionales es cada vez más evidente. Por este motivo, el contenido de la enseñanza en
Humanidades debería también adaptarse a las nuevas exigencias del desarrollo tecnológico y
del mercado laboral. Se debe preparar a los estudiantes en la integración de métodos de
informática, como por ejemplo, ingenieros lingüísticos, expertos de ediciones multimedia y en
bases de datos tanto para bibliotecas, archivos históricos, centros de documentación, museos o
empresas publicitarias, por lo tanto se necesitan cambios en la curricula. Tomando aspectos
como la búsqueda de información, tecnologías multimedia y digitalización así como
codificación de textos. Aunque la idea no es reemplazar a las actividades presenciales y formas
convencionales de investigación. Pero si, revolucionar el acceso a las fuentes de información,
llevando a nuevas formas de investigación y publicación, posibilitando nuevas comunidades
globales de investigadores.

Se ha mencionado como la disciplina va contribuyendo en dar nuevos enfoques a la


investigación en humanidades, partiendo de métodos propios a esta pero en relación con la
informática. Es así, que a continuación se hace una revisión de estos métodos, técnicas y
herramientas, usadas en Humanidades cuya perspectiva cambia desde la nueva disciplina.

Fuentes de Información

Las investigaciones en el área de humanidades están relacionadas con el estudio de fuentes


textuales, pero estas representan tan solo una pequeña parte de las fuentes de información que
pueden usar los investigadores ya que otras fuentes son las esculturas, pinturas, restos
arqueológicas y toda clase de objetos que son producidos por la sociedad a través de la
historia. Todas estas fuentes necesitan ser representadas en forma digital antes de que las
técnicas computacionales puedan ser aplicadas a estas y puedes ser transformadas en formato
digital de la siguientes formas. Como por ejemplo:

El Texto: la mayoría de las fuentes textuales ya nacen en formato digital pero las hay
también las que se encuentran en lenguajes antiguos o provienen de una variedad de
medios utilizados a través de las distintas décadas.
Datos Numéricos: es común en muchas disciplinas que se basen en fuentes de análisis
estadístico y numérico tales como censos, o datos que derivan de técnicas de análisis
textual.

Imágenes: Muchas de las disciplinas de humanidades tales como la historia del arte, son
altamente visuales.

Video: Los recursos fílmicos son importantes para las artes visuales, y son también utilizados
para el registro y propósitos educativos.

Datos Espaciales: Muchas de estas disciplinas trabajan con mapas o datos que tienen
componentes espaciales. El uso del término espacial no es utilizado en el sentido
geográfico convencional sino se refiere a la distribución espacial de los elementos
composicionales por ejemplo en una pintura, a la posición de actores en el escenario o a
otras fuentes que involucren localización de datos.

Sonido: Registros de sonido son de interés inmediato para el desarrollo de investigaciones


artísticas y para disciplinas donde el estudio del lenguaje es uno de sus componentes.

Herramientas para la investigación

Una de las principales tareas de Humanities Computing es ofrecer herramientas que permitan a
los académicos aplicar estas actividades sobre datos digitales y fuentes disponibles a través de
redes de computadores, así como asegurar la viabilidad del uso de estos recursos en el futuro.

Luego de digitalizar las fuentes de datos y organizarlas de manera que el contenido sea visible
para técnicas computacionales, se requieren herramientas que permitan realizar
investigaciones sobre estas fuentes.

John Unsworth[2], sugiere que a pesar de que tanto el conocimiento y los resultados obtenidos
de las investigaciones son diversos, es posible identificar ciertos métodos comunes, los cuales
pueden ser expresados en base a un conjunto de siete actividades combinadas

Descubrimiento
El descubrimiento se refiere a la actividad que es realizada en archivos, centros de
documentación, o bibliotecas. Pero que ahora se la puede realizar con el uso de recursos
digitales en la web, como el uso de motores de búsqueda. Por otra parte el método
tradicional de comunicación se realiza hoy en día, a través de la comunicación con otros
pero vía internet, por ejemplo a través de grupos de discusión en línea o comunidades
virtuales de investigadores que trabajan en conjunto y en forma interdisciplinaria utilizando
medios electrónicos y convencionales. El uso de estos sitios web colaborativos, wiki’s y
blog’s, ha revolucionado las formas de comunicación.

Fichaje
El fichaje ha sido siempre una de las técnicas mas importantes para las investigaciones en
humanidades, pero como puede esta habilidad aplicarse a textos electrónicos, imágenes
o otras fuentes digitales tales como registro de sonidos o video? Pues con el uso de
herramientas dirigidas a esta actividades aunque la clave no es como facilitar el registro,
sino como compartirlo entre investigadores pero controlando los posibles daños que
puedan ocurrir asi como el uso y abuso de las fuentes.

Comparación
Compara dos o mas objetos de análisis, es una actividad ante todo visual pero con el
apoyo de herramientas sofisticadas para la comparación automática se pueden obtener
mejores resultados. Esta actividad involucra análisis estadístico y numérico de datos, como
datos de censos pasados, o técnicas de comparación de imágenes, sonido y video.

Referencia:
Se refiere a la información a la cual se hace referencia en un proyecto de investigación,
relacionado con la creación de enlaces en la red.

Ejemplificación
Ejemplificación es el resultado de la selección de acuerdo a la especificación de criterios,
que puede ser un término de búsqueda o sobre una muestra poblacional.

Ilustración
La ilustración es el proceso de elucidar o poner algo en claro. Esto puede hacerse
simplificando los resultados complejos obtenidos con diagramas o representaciones
graficas.

Representación
La representación se refiere a las formas de publicación, ya sea de manera electrónica o
convencional. Los resultados de las investigaciones son ahora publicadas como fuentes
digitales ya sea en libros o artículos de revistas.

Cabe hacer notar que todas estas actividades no están limitadas solamente a las disciplinas de
humanidades, pero lo que hace la diferencia es la naturaleza de los datos, la naturaleza de las
consultas y las herramientas que serán utilizadas para las distintas interacciones. Los datos de
las investigaciones tanto en su rol de fuentes primarias y secundarias, son manejadas por
instituciones culturales de toda tipo, como librerías, archivos, galerías, museos, pero también
forman parte de nuestro entorno diario, como ser edificios públicos, monumentos, sitios
arqueológicos.

Cuáles son las disciplinas que hacen a Humanities Computing?.

En su artículo, Willard McCarty and Harold Short [3] plantean un mapa preliminar de Humanities
Computing. Las disciplinas de humanidades están al inicio del mapa organizadas en grupos
como literatura, lingüística, historia, música, religión, arqueología y antropología. Al pie del
mapa se encuentran las áreas de aprendizaje que trabajan en forma interdisciplinaria en
Humanities Computing, tales como filosofía, etnografía, historiografía, sociología del
conocimiento, estudio de los medios y otros aspectos de la ciencia de la computación como el
procesamiento digital de imágenes , investigaciones en librerías digitales. En el centro del mapa
se encuentran el común de las metodologías que comparten las técnicas computacionales,
con las disciplinas de humanidades ligadas a las ciencias sociales, como ser el diseño de bases
de datos, el análisis de textos, análisis numérico, procesamiento de imágenes, la música, la
recuperación de la información y las comunicaciones. Contribuyendo cada grupo a este
común de metodologías

Figura No. 1: Mapa de Disciplinas


Humanities Computing, W. McCarty and H. Short.
Conclusiones.

Finalmente se ha revisado que se entiende por Humanities Computing y como las fuentes de
información y las técnicas comunes a las distintas disciplinas de humanidades que conforman el
mapa, van adecuándose a la perspectiva computacional.

Es también importante la integración de los métodos computacionales en humanidades, ya


que se va abriendo un nuevo campo de investigación así como van surgiendo nuevos métodos
y preguntas para entender los alcances de los nuevos medios y su rol en el trabajo colaborativo
interdisciplinario.

Referencias
15. The Centre for Computing in the Humanities, King's College London
http://www.kcl.ac.uk/cch.
16. Unsworth. John. 2000. Scholarly Primitives: what methods do humanities researchers have in
common, and how might our tools reflect this?.
http://jefferson.village.virginia.edu/~jmu2m/Kings.5-00/primitives.html
17. Willard McCarty. Harold Short. 2002. Humanities Computing. King’s College London, London,
United Kingdom.
18. ACH Panel: Humanities Computing and the Rise of New Media Centers: Synergy or
Disjunction? http://awww.ach.org/abstracts/1999/renear-ach.html.
CANALES DE INFORMACIÓN Y MATRICES
Lic. Edgar Clavijo Cárdenas M. Sc.
Docente – Investigador - UMSA
eclavijo@acm.org
http://es.geocities.com/edgarpcc/

RESUMEN
Es un segundo artículo en el cual se enfatiza la utilización de matrices en la Teoría de la información. Se expone el uso
de las matrices en temas referidos a Canales de Información: (i) Formulación de relaciones de las probabilidades del
canal, y los alfabetos de entrada y salida, (ii) Expresión de canales en serie y convergencia del canal que relaciona
al alfabeto de entrada y salida de forma estadísticamente dependiente hacia otro que los relaciona de forma
independiente, (iii) Formulación de las reducciones suficientes y reducciones suficientes mínimas.

Abstract
It is a second article in which is emphasized the use of matrix in the Theory of the information. The use of the matrix is
exposed in topics referred to Channels of Information: (i) Formulation of the relationships of the probabilities of the
channel, the input and output alphabets, (ii) Expression of cascaded channels and convergence of a channels that
relates to the input and output alphabet in dependent form toward another that relates them in an independent form
(iii) Formulation of the sufficient reductions and minimum sufficient reductions.

PALABRAS CLAVE: Canal de Información. Canales en serie. Canales en cascada. Teoría de la


información.

KEYWORDS: Information Channels. Serial Channels. Cascade Channels. Information Theory.

Introducción.

El estudio de los canales de información es un tema muy importante dentro de la teoría de la


información. La utilidad teórica y práctica del tema ha sido ampliamente demostrada por el
segundo teorema de Shannon. Las expresiones de las diferentes relaciones entre los canales y
los alfabetos habitualmente se muestran con gran profusión de simbología matemática que
suele ocultar a los estudiantes y estudiosos del tema la posibilidad de expresiones simples que
utilicen formulaciones matriciales. El objetivo de este artículo es facilitar estas expresiones para
lograr la comprensión de estos temas introduciendo formulación matricial.

Canales de Información.

Un sistema de comunicación o de transmisión de mensajes debe considerar varios elementos:


Emisor, Canal de información, Receptor y la acción del entorno producente de ruido como se
esquematiza en la Figura No 1. El Canal de Información es el medio físico utilizado como soporte
de las señales que viajan a través de él. Un emisor de señales -similar a una fuente- utiliza este
medio con el fin de transmitir mensajes al receptor. El entorno que rodea al canal puede
perturbar y modificar las señales ocasionando distorsiones en el mensaje, a ésta acción se le
conoce con el nombre de ruido.

Con el propósito de comprender el comportamiento de un canal, se ha desarrollado un modelo


formal que pueda describir sus características de manera apropiada.

Canal de información
Emisor Receptor

Ruido

Figura No. 1: Sistema de comunicación

Un canal de información está determinado por un alfabeto de entrada A={ai: i=1, 2, ..., r}, un
alfabeto de salida B={bj: j=1, 2, ..., s} y un conjunto de probabilidades condicionales P(bj|ai) que
describe el comportamiento de la transmisión de las señales a través del canal y se entiende
como la probabilidad de que se reciba el símbolo de salida bj si se transmite el símbolo de
entrada ai. [1]
Se tienen además asociados dos conjuntos de probabilidades, llamadas probabilidades a priori,
uno para el alfabeto de entrada A y otro para el alfabeto de salida B. Se introduce como
notación -para el cumplimiento del objetivo de éste artículo- la escritura en términos de
matrices, de dimensión 1xr y 1xs, a los conjuntos de probabilidades de los alfabetos de entrada y
salida respectivamente. Para simplificar la notación de los elementos de cada matriz se escribe
la probabilidad de cada símbolo del alfabeto de entrada y del alfabeto de salida como
P(ai )  a i y P (b j )  b j . A partir de esto, se formula las siguientes identidades:

A1r  P(a1 ), P(a2 ), P(a3 ),, P(ar )  a1 , a2 , a3 ,, ar  (1)

B1s  P(b1 ), P(b2 ), P(b3 ),, P(bs )  b1 , b 2 , b3 ,, b s  (2)

 
Denotamos también como AB a la matriz de probabilidades condicionales de dimensión r x s,
donde las filas corresponden a las entradas y las columnas a las salidas. El canal propiamente
 
dicho está representado por la matriz AB . Para simplificar la notación escribimos
P (b j | a i )  c ij de acuerdo a [2] y la matriz de probabilidades del canal se expresa como:

c11 c12  c1s 


c c  c 2s 
ABrs   21 22 (3)
  
 
cr1 cr2  c rs 

En esta matriz la suma de cada fila es igual a 1 puesto que corresponde a una distribución de
probabilidades y se entiende como la certeza de recibir algún símbolo a la salida del canal
cuando se transmite algún símbolo de entrada.

En la Figura No. 2 se muestran todas las situaciones posibles en cuanto a las relaciones que se
pueden establecer entre las probabilidades de los alfabetos de entrada, salida y canal de
información. Las probabilidades hacia adelante son todas las P (b j | a i ) , las probabilidades
hacia atrás son las P(ai | b j ) .

   
Conocidos A y AB se puede determinar la probabilidad a priori de cada símbolo de salida
b j . Cada símbolo b j puede recibirse en r casos distintos. Enviado a1 se presentará b j con
probabilidad c1j , si se envía a2 se presentará b j con probabilidad c 2j , etc. En consecuencia
se escribirá como la suma de los productos de la probabilidad condicional a posteriori de que
salga el símbolo b j dado que ingreso el símbolo a i por la probabilidad a priori de la emisión del
símbolo ai para toda i de 1 a r, tal como se muestra en la figura 2 (b). Es decir, está
representado por la siguiente fórmula [1]:

P(b j | a1 ) P (a1 )  P(b j | a 2 ) P(a 2 )    P(b j | a r ) P (a r )  P (b j ) (4)

O lo que es lo mismo:

r r

 P(b j | ai ) P(ai )   c ij  a i  b j
i 1 i 1
(5)
a1 b1 a1 b1 a1 b1

a2 b2 a2 c1j b2 a2 di1 b2
c2j di2

ai bj ai cij bj ai dij bj
crj
dis
ar ar ar
bs bs bs
(a)Probabilidades (b)Probabilidad de (c)Probabilidad de
adelante y atras recibir bj enviar ai

Figura No. 2: Diagramas de correspondencia de probabilidades condicionales del canal AB 

En éste acápite se plantea expresar la relación entre las probabilidades de los símbolos de
   
entrada A , los símbolos de salida B y las probabilidades condicionales del canal AB  
utilizando la siguiente multiplicación de matrices:

A1xr ABrxs  B1xs (6)

Por otra parte, recurriendo a la ley de Bayes, tenemos la definición de probabilidad del suceso
simultáneo ( ai , b j ) como:
P(ai , b j )  P(ai | b j ) P(b j ) (7)
o bien,
P(ai , b j )  P(b j | ai ) P(ai ) (8)

De ésta relación se obtienen las probabilidades hacia atrás con la siguiente ecuación:

p (bj | ai) p (ai )


p (ai | bj )  (9)
p (bj )

Reemplazando en la ecuación (9) la parte izquierda de la ecuación (5) se tiene:

P(b j | ai ) P(ai ) (10)


P ( ai | b j )  r

 P (b
i 1
j | ai ) P(ai )

Con el mismo fin de simplificar, denotamos también P(ai | b j )  d ji para formular la matriz de
probabilidades condicionales hacia atrás que se expresa así:

d 11 d 12  d 1r 
d d 22  d 2r 
BAsr   21 (11)
  
 
 d s1 d s2  d sr 

Con lo que se puede concluir -de manera simétrica- que si se tienen conocidas las
 
probabilidades de B y las probabilidades condicionales hacia atrás BA , se obtiene las  
 
probabilidades a priori de A mediante:

B   BA   A  (12)
En la siguiente figura se muestra un ejemplo de estas relaciones con datos acerca de la entropía
de los alfabetos, de los canales, la información mutua y la entropía conjunta:

p(a1) p(a2) p(a3) b1 b2 b3 p(b1) p(b2) p(b3)


0.2000 0.3000 0.5000 a1 0.010 0.020 0.970 0.4810 0.3140 0.2050
a2 0.080 0.900 0.020
H(A) 0.9372 a3 0.910 0.080 0.010 H(B) 0.9472
a1 a2 a3
H(A/B) b1 0.0042 0.0499 0.9459 H(B/A)
0.2724 b2 0.0127 0.8599 0.1274 0.2717
b3 0.9463 0.0293 0.0244
H(A/b) I(A;B) H(B/a)
0.2048 0.6648 0.1400
0.4077 H(A,B) 0.3415
0.2240 1.2197 0.3040 ecc

Figura No. 3: Relación de las probabilidades de un canal en forma matricial

Canales en serie o en cascada.

Actualmente en muchas situaciones prácticas se observa que los canales de información están
conectados uno tras otro y además cada uno de ellos es independiente de los demás. Un
esquema de tal situación referida a dos canales se observa en la figura 4:

AC
A B C
AB BC

Figura No. 4: Canales en serie o cascada

Considerando un par de canales conectados en serie, tal como se ve en la figura 4, tenemos un


 
alfabeto de entrada A al canal AB y un alfabeto de salida B que es al mismo tiempo el
alfabeto de entrada del canal BC y de este último su salida es el alfabeto C. Dos canales en
serie o en cascada [2] dispuestos de esta manera se pueden considerar como un solo canal, el

canal AC . 
Utilizando la notación del punto anterior, se expresa un nuevo canal AC , como el resultado de  
la multiplicación de las matrices AB y   BC de la siguiente manera:
AB  r  s  BC  s  t  AC  r  t (13)

Así por ejemplo, si tenemos los siguientes canales BSC

AB   
c 12 
BC  
c 11 d 11 d 12 
(14)
c 21 c 22  d 21 d 22 

Obtendremos
AB  BC   AC  (15)
c 11 c 12  d 11 d 12   c 11 d 11  c 12 d 21 c 11 d 12  c 12 d 22 
c    [AC] (16)
 21 c 22  d 21 d 22  c 21 d 11  c 22 d 21 c 21 d 12  c 22 d 22 


Si AB y  BC son el mismo BSC con probabilidad de error igual a p obtendremos:

 2
 p2 2 qp 
AC  q  (17)
 2 qp q  p2 
2

Otro resultado interesante es relativo al canal de probabilidades a posteriori AB   y el canal


resultante BA que se obtiene a partir del primero y de A . Como se ha evidenciado BA
depende de la forma de utilización del canal, es decir de las probabilidades del alfabeto A.
   
Colocando en serie a los canales AB y BA , y luego de manera permutada, se obtienen los
siguientes otros dos canales de las ecuaciones (18) y (19) respectivamente:

AB  BA   ABA  (18)

BA  AB   BAB  (19)

Con los cuales se logran las siguientes expresiones:

A  ABA   A  (20)

B  BAB   B  (21)

Como podemos observar en éstas ecuaciones ambos canales ABA y BAB no modifican el    
valor de las probabilidades del alfabeto de entrada al canal, obteniéndose como resultado el
mismo conjunto de probabilidades en el alfabeto de salida, siendo además, ambos canales,
con ruido y sin ser necesariamente una matriz identidad.

En la Figura No. 5 siguiente se observa el comportamiento del canal ABA  obtenido del
ejemplo de la figura 3.

p(a1) p(a2) p(a3) b1 b2 b3 p(b1) p(b2) p(b3)


0.2000 0.3000 0.5000 a1 0.9182 0.0461 0.0357 0.2000 0.3000 0.5000
a2 0.0307 0.7785 0.1908
H(A) 0.9372 a3 0.0143 0.1145 0.8712 H(B) 0.9372
a1 a2 a3
H(A/B) b1 0.9182 0.0461 0.0357 H(B/A)
0.4257 b2 0.0307 0.7785 0.1908 0.3913
b3 0.0143 0.1145 0.8712
H(A/b) I(A;B) H(B/a)
0.3086 0.5116 0.3086
0.5626 H(A,B) 0.5626
0.3903 1.3629 0.3903 ecc

Figura No. 5: Relación de las probabilidades de l canal ABA  obtenido del ejemplo de la figura 3

   
Se debe notar que tanto ABA y BAB tienen menor información mutua que AB y BA    
respectivamente, por la degradación de la información producida al atravesar por dos canales
dispuestos en serie.

Extendiendo este principio se prueba que la disposición de un canal de la forma


 
ABABA  BA tiende a convertirse en un canal por el cual los alfabetos de entrada y salida
son estadísticamente independientes, llamémosle ABAK al mencionado canal. El canal
ABA K
está representado como una matriz idempotente, en el cual las probabilidades
condicionales de cada una de sus filas son iguales al del alfabeto de entrada del canal, tal
como se aprecia en la figura 6 obtenido del ejemplo citado:

[ABA] [ABA]2 [ABA]4


0.9182 0.0461 0.0357 0.845 0.082 0.073 0.721 0.135 0.144
0.0307 0.7785 0.1908 0.055 0.629 0.316 0.090 0.460 0.450
0.0143 0.1145 0.8712 0.029 0.190 0.781 0.058 0.270 0.673

[ABA]8 [ABA]16 [ABA]32


0.54005 0.19842 0.26153 0.34526 0.25765 0.39709 0.22653 0.29228 0.48118
0.13228 0.34537 0.52235 0.17177 0.30924 0.519 0.19486 0.3015 0.50365
0.10461 0.31341 0.58198 0.15883 0.3114 0.52977 0.19247 0.30219 0.50534

[ABA]64 [ABA]128
0.20089 0.29974 0.49937 0.2 0.3 0.5
0.19983 0.30005 0.50012 0.2 0.3 0.5
0.19975 0.30007 0.50018 0.2 0.3 0.5

Figura No. 6: Convergencia de ABA  hacia una matriz idempotente

El canal ABA 128 es un canal con ruido, de matriz idempotente y en el cual las relaciones entre
los alfabetos de entrada y salida son estadísticamente independientes. En la figura 7, se observa
el comportamiento de este canal en el que la información mutua I(A;B) es igual a cero.
p(a1) p(a2) p(a3) b1 b2 b3 p(b1) p(b2) p(b3)
0.2000 0.3000 0.5000 a1 0.2000 0.3000 0.5000 0.2000 0.3000 0.5000
a2 0.2000 0.3000 0.5000
H(A) 0.9372 a3 0.2000 0.3000 0.5000 H(B) 0.9372
a1 a2 a3
H(A/B) b1 0.2000 0.3000 0.5000 H(B/A)
0.9372 b2 0.2000 0.3000 0.5000 0.9372
b3 0.2000 0.3000 0.5000
H(A/b) I(A;B) H(B/a)
0.9372 0.0000 0.9372
0.9372 H(A,B) 0.9372
0.9372 1.8745 0.9372 ecc

Figura No. 7: Comportamiento del canal ABA 128

Es posible constatar con este ejemplo que para cualquier alfabeto de entrada existe al menos
un canal con ruido que obtiene a la salida un alfabeto con la misma probabilidad del alfabeto
de entrada.

Reducciones suficientes

Un canal AB 
de dimensión r  s tiene una reducción suficiente si dos de sus columnas
pueden escribirse una como múltiplo de la otra. En tal caso sumando una columna sobre la otra
y eliminando la columna que no contenga el resultado se encontrará otro canal A B  de  
dimensión r  ( s  1) con la misma información mutua que el canal AB .  
El proceso para obtener una reducción suficiente se puede realizar colocando al canal AB en  
serie con un canal determinante de dimensión s  ( s  1) que contenga una columna con 2
unos, que es la elegida como la columna resultante. Si existe más de una reducción suficiente se
podrán colocar como una hilera de canales determinantes en serie, hasta lograr la reducción
suficiente mínima. Es decir aquella que no contenga la posibilidad de hallar más reducciones
suficientes.

Tenemos como ejemplo el siguiente proceso para obtener la reducción suficiente mínima de un
canal. La primera reducción suficiente -en la ecuación (22)- obtiene A B  y la segunda  
reducción suficiente -en la ecuación (23)- se obtiene AB ' ' :  
1 0 0 0
1 / 12 1 / 12 1/ 4   1 / 3 1 / 12 1/ 4 
1 0 0 
1/ 3 1/ 4 1/ 3
1 / 16 1 / 8 1 / 4 3 / 16 3 / 8  
0
1/ 4 1/ 8 1 / 4 3 / 8  (22)
  0 0 1 0    AB 
1 / 10 1 / 10 1 / 5 3 / 10 3 / 10    2 / 5 1 / 10 1 / 5 3 / 10
  1 0 0 0  
1 / 12 1 / 24 1/ 2 1/ 4 1/ 8   1 / 3 1 / 24 1/ 2 1/ 8 
0 0 0 1

1 / 3 1 / 12 1 / 3 1 / 4  1 0 0 1 / 3 1 / 3 1 / 3
1 / 4 1 / 8 1 / 4 3 / 8  0 1 0 1 / 4 1 / 2 1 / 4 (23)
    AB' '
2 / 5 1 / 10 1 / 5 3 / 10 0 0 1 2 / 5 2 / 5 1 / 5
     
1 / 3 1 / 24 1 / 2 1 / 8  0 1 0 1 / 3 1 / 6 1 / 2

Las ecuación (24) y (25) expresan el proceso de reducción con canales determinantes en serie:

1 0 0 0
1 / 12 1 / 12 1/ 4   1 0 0  1 / 3 1 / 3 1 / 3
1 0 0 
1/ 3 1/ 4
1 / 16 1 / 8 1 / 4 3 / 16 3 / 8  
0
0 1 0 1 / 4 1 / 2 1 / 4 (24)
  0 0 1 0     AB' '
1 / 10 1 / 10 1 / 5 3 / 10 3 / 10   0 0 1  2 / 5 2 / 5 1 / 5
  1 0 0 0    
1 / 12 1 / 24 1/ 2 1/ 4 1/ 8   0 1 0  1 / 3 1 / 6 1 / 2
0 0 0 1

1 0 0
1 / 12 1 / 12 1/ 4   1 / 3 1 / 3 1 / 3
1 0 
1/ 3 1/ 4
1 / 16 1 / 8 1 / 4 3 / 16 3 / 8  
0
1/ 4 1 / 2 1 / 4 (25)
  0 0 1    AB' '
1 / 10 1 / 10 1 / 5 3 / 10 3 / 10    2/5 2 / 5 1 / 5
  1 0 0  
1 / 12 1 / 24 1/ 2 1/ 4 1/ 8   1 / 3 1 / 6 1 / 2
0 1 0

Con similar enfoque -utilizando canales sin ruido- es posible también hallar una expansión del
alfabeto A tal como sugiere la ecuación (26) donde la segunda columna se expande en dos.
Estas dos columnas vienen a ser la segunda y tercera del canal resultante AB  . En dicho
Ex

canal la tercera columna es el doble de la segunda:

1 / 3 1 / 3 1 / 3 1 / 3 1 / 9 2 / 9 1 / 3
1 / 4  1 0 0 0 
1 / 2 1 / 4  1 / 4 (26)
 0 1 / 3 2 / 3 0  
1/ 4 1/ 6 2 / 6
  AB 
Ex

2 / 5 2 / 5 1 / 5  2 / 5 2 / 15 4 / 15 1 / 5
  0 0 0 1  
1 / 3 1 / 6 1 / 2  1 / 3 1 / 18 2 / 18 1 / 2

Discusión de resultados y conclusiones.

Facilitar la comprensión del objeto de estudio analizado es un objetivo que se persigue cuando
se tiene el encargo social de enseñar. La notación matricial en el estudio de los canales de
información logra alcanzar mejores niveles de comprensión, puesto que se facilita la expresión
de los conceptos reduciendo la simbología que es habitualmente extensa en este contexto.
Los temas mostrados pueden encontrarse en la bibliografía referida y a las cuales se les añade
este aporte que conjeturamos mejore la comprensión de estos temas.

Referencias

19. Abramson N., 1977: Teoría de Información y Codificación. 216 págs. 4ta. edición, ed. Paraninfo, Madrid.
20. Togneri R, deSilva J.S.: Fundamentals of Information Theory and Coding Design. 385 pags. 1ra edición. Ed
Chapman & Hall/CRC.
21. Jones G. and Jones M. 2002: Information and coding theory. 210 págs. 2da. edición ed. Springer,
Londres
SISTEMAS INTELIGENTES EDUCATIVOS

RESUMEN

Este artículo tiene como objetivo dar una visión de actividades


realizadas con Sistemas Inteligentes Educativos (SIE) que son
desarrollados en el ámbito de la didáctica cuyas capacidades
usan técnicas de Inteligencia Artificial en la Educación.
Patricia Sonia Trino Camacho
Plantea como diseñar un SIE, utilizando técnicas para crear el Licenciada en Informática
proceso de adaptación de este sistema al usuario, con un aporte Consultora en Proyectos de
de los Sistemas Tutoriales Inteligentes (STI) y los Sistemas Hipermedia Investigación
(SH). Mostrando cuáles son las principales cuestiones que se E-mail: dpatriciatrino@gmail.com
plantean en su diseño.

PALABRAS CLAVE: Sistemas inteligentes educativos. Inteligencia artificial. Sistemas Tutoriales


Inteligentes. Sistemas hipermedia. Aprendizaje colaborativo.

KEY WORD: Intelligent systems of education. Artificial in intelligence. Tutorial Systems Integration.
Hypermedia systems. Collaborative learning.

Introducción

La situación actual en nuestro medio respecto al uso de computadores va en crecimiento,


debido a la accesibilidad en precios, el fácil acceso a tecnologías de punta en Comunicación e
Internet y el uso permanente de herramientas informáticas a todo nivel, lo que hace que los
usuarios demanden programas formativos y de autoformación de apoyo a la
enseñanza/aprendizaje.

Es así que según el artículo escrito en la revista Iberoamericana de Inteligencia Artificial [1] se
especifica claramente sobre sociedades informatizadas donde instituciones internacionales
como la UNESCO, a través de Jaques Delors que lideró la comisión internacional para la
educación en el siglo XXI bajo el título “La educación encierra un tesoro”, sustenta la
implementación de este diseño con el uso de nuevas tecnologías aplicadas en la educación.
Para lo cual tomamos en cuenta lo siguiente: ”… las sociedades actuales son de uno u otro
modo sociedades de información en las que el desarrollo de las tecnologías puede crear un
entorno cultural y educativo capaz de diversificar las fuentes del conocimiento y del saber” [2].

La aplicación de la Inteligencia Artificial (IA) en la Educación, constituye actualmente un campo


de creciente interés donde se trata, fundamentalmente, de aplicar las técnicas de la IA al
desarrollo de sistemas de enseñanza asistidos por computador, con el propósito de construir
sistemas de enseñanza inteligentes. Siendo así que esta área de investigación interdisciplinaria es
de interés de todo profesional, en especial la Pedagogía, Psicología, Ciencias Cognitivas,
Inteligencia Artificial, Multimedia e Informática en general, dónde cada uno aporta su visión al
desarrollo de estos sistemas.

Para poder entender mejor lo propuesto en este artículo respecto al diseño de un sistema
inteligente educativo, se describe los conceptos como SIEs (Sistemas Inteligentes Educativos), STIs
(Sistemas Tutores Inteligentes) y los SHs (Sistemas Hipermedia). “Entendemos como SIEs, aquellos
sistemas desarrollados en el ámbito de la didáctica cuyas capacidades hacen uso de técnicas
de la Inteligencia Artificial” [3]

Un concepto que se adecua al presente artículo de Inteligencia Artificial de los muchos que se
dan es el siguiente: “El estudio de cómo lograr que las computadoras realicen tareas que, por el
momento, los humanos hacen mejor”. [1]. Este concepto es tomado para sistemas hechos por el
ser humano, para que actúen como humanos.

Por otra parte, el concepto más adecuado al diseño de los SIEs que permite comprender el uso
de STIs es el que se publicó en el 3er congreso virtual en Internet donde describe a: “Los STIs
permiten emular el proceso de aprendizaje y de enseñanza humano, adaptando el tipo y el
contenido de la enseñanza a las necesidades específicas del alumno, decidiendo cuándo
introducir nuevos conceptos o repasar los anteriores si éstos no han sido asimilados. Estos sistemas
tienen en cuenta los conocimientos a enseñar (contenido pedagógico), la forma de enseñarlo
(estrategia pedagógica), así como la información relevante sobre el alumno que está siguiendo
el tutorial ”[2]

Por último el concepto de Sistemas hipermedia extraido de la revista Informédica [4] “... término
con que se designa al conjunto de métodos o procedimientos para escribir, diseñar, o componer
contenidos que tengan u otros medios, y que además tenga la posibilidad de interactuar con los
usuarios “

Desarrollo

Para tener una visión general de algunas actividades que realizan los Sistemas Inteligentes
Educativos (SIE) que son desarrollados en el ámbito de la didáctica cuyas capacidades hacen
uso de técnicas de la Inteligencia Artificial (IA) en la Educación, se tiene que diferenciar dos
planteamientos:

El primer planteamiento, trata de realizar una tutorización guiada mediante un proceso de


transmisión de conocimiento a través de estrategias de enseñanza establecidas por
computadora. “seguimiento continuo del profesor hacia el alumno” (Enfoque instructivo) a
través de Sistemas Tutores Inteligentes (STI).

Y el segundo planteamiento que trata, como brindar al estudiante una presentación de material
docente, que le permita adquirir conocimientos a través de sus propias estrategias de
aprendizaje, donde no se ofrece ninguna estrategia de enseñanza, a través de una
computadora, según un planteamiento “constructivista”. Esta tutorización es “construcción de
entornos de aprendizaje donde sea el estudiante el que guíe su propio proceso de aprendizaje”
(Enfoque Constructivo) a través de Sistemas de Tele formación.

Por tanto se desea mostrar los Sistemas Tutores Inteligentes (STI) y los entornos que permiten la
construcción de estos STI`s, con planteamientos didácticos y pedagógicos conducidos por la
idea de una tutorización guiada. De modo que no lejos de estos sistemas también están los
Sistemas que incluyen Tecnología Hipermedia (STH) cuya propuesta se amolda fácilmente con
los planteamientos constructivistas.

Por otro lado y desde una visión no individualizada de la enseñanza, se ven sistemas que incluyen
capacidades para un aprendizaje colaborativo. Y por último, nos centramos en ciertos modelos
de formación, necesarios en ámbitos de la formación regular, continua, ocupacional, y las
posibilidades de abordarlas desde una perspectiva tecnológica de la Inteligencia Artificial

En nuestro medio están surgiendo estos Sistemas Tutores Inteligentes en todo ámbito a
requerimiento de los usuarios pese a que esta tutorización no es tan nueva según: la revista
Informédica [4] “ Gracias a las técnicas de la IA, la enseñanza asistida por computadora recobra
un especial interés cerca de los años 80; pese a que el uso de herramientas informáticas en la
enseñanza fue desde los años 50. Es en esa época de los 80 que surgieron los Sistemas Tutores
Inteligentes, los cuales eran procesos desarrollados de enseñanza, que satisfacían en cierta
medida los requerimientos de estos usuarios o estudiantes”.

El desarrollo de sistemas en nuestro medio social, hacen que estemos en un momento clave e
inmejorable para abordar la demanda formativa y educativa, en cuanto al desarrollo de
Sistemas Inteligentes Educativos (SIEs).

Es así que se realizaron algunos sondeos de opinión de las preferencias en dos sectores de la
comunidad estudiantil universitaria que son los del área social y los del área técnica matemática,
Figura 1. y Figura 2. donde se puede verificar los dos tipos de tutorización a través de Tecnología
Hipermedia:
¿Prefieres cursos ¿Prefieres cursos
guiados por un guiados por un
profesor? profesor?

¿Prefieres buscar
¿Prefieres buscar
una
una
autoformación?
autoformación?

Figura Nº 1 Tutorización en el Area Social Figura Nº 2. Tutorización en el Area Técnica

Para poder abordar con cierto grado de adecuación el reto de diseñar y desarrollar SIEs será
necesario contar con: (1) Técnicas informáticas de (I.A)., multimedia, comunicación de
computadores, etc, (2) planteamientos que faciliten la motivación del alumno frente al
computador, (3) parámetros pedagógicos o de las ciencias de la educación que refuercen y
apoyen los procesos de instrucción/aprendizaje que se lleven acabo mediante nuevas
tecnologías. El proceso de automatizar las actividades de la compleja tarea de
enseñar/aprender obligará, en muchos casos, a fusionar planteamientos de las diversas
disciplinas.

Con los SIEs se pretende ayudar, colaborar y/o favorecer los procesos de aprendizaje como
parte integrada en los modelos de enseñanza más actualizados. Es decir, su creación se enfoca
más como una herramienta complementaria de la enseñanza/aprendizaje que permite
aumentar la calidad del aprendizaje, que como una herramienta que sustituye en sí todo un
sistema clásico de enseñanza/aprendizaje. La utilización de los SIEs implica por parte del docente
una nueva y más amplia visión de sus actividades de enseñanza.

Dentro de los objetivos del artículo es dar una visión de algunos contextos docentes en los que la
Inteligencia Artificial (IA) puede favorecer de algún modo la mejora de los procesos de
aprendizaje.

Seguidamente se muestra algunas propuestas en la panorámica actual especialmente


apoyadas en los planteamientos didácticos instructivo y constructivo, como la siguiente:

Propuestas individualizadas frente a las cooperativas.


Teleformación
“Actividad que trata de ofrecer a las personas nuevas posibilidades para llevar a cabo su
proceso de aprendizaje continuo utilizando las tecnologías de la información”.

Sistemas de teleformación
En los últimos años, los sistemas de relearning han experimentado un gran avance. Se han
planteado sistemas desde diferentes puntos de vista pedagógicos y didácticos
 Enfoque instructivo:
 Enfoque constructivo:
 Aprendizaje individualizado
 Aprendizaje cooperativo

Enfoque instructivo: “seguimiento continuo del profesor hacia el alumno”


Sistema Tutor Inteligente (STI)
 Ha proporcionado éxitos en la enseñanza (clases particulares)
 Puede provocar una actitud demasiado pasiva del estudiante y desmotivarlo.

Enfoque constructivo:
“Construcción de entornos de aprendizaje donde sea el estudiante el que guíe su propio
proceso de aprendizaje”
 Sistemas hipermedia
Aprendizaje individualizado: Proporciona al estudiante libertad para:
 Acceder a la información que desea
 Acceder a la información de múltiples modos
 El estudiante puede desorientarse de tal manera que pierda el rumbo para alcanzar
sus objetivos
 Necesidad de herramientas complementarias que permitan reorientar al estudiante
en el proceso de aprendizaje

Aprendizaje basado en la cooperación:


 Descarta el sistema uno a uno (sistema-estudiante)
 El aprendizaje de calidad requiere cooperación
 Resolución de problemas de forma conjunta
 Crítica de propuestas propias y ajenas
 Justificación y explicación de las soluciones dadas y recibidas

Se justifica el aprendizaje desde diferentes perspectivas sin ignorar un seguimiento continuo y


motivador del docente
 El proceso de seguimiento tiene una complejidad creciente que depende del número
de estudiantes del grupo
 Necesidad de herramientas de ayuda para:
 Supervisar todas las actividades realizadas por los estudiantes en un momento
determinado
 Motivar la realización de ciertas actividades con el objetivo de asegurar una solución
debatida, consensuada y más elaborada.
 La enseñanza virtual sobre la red está proliferando cada vez más, combinando
enseñanza presencial clásica (minimizada al máximo) y no presencial
Cada vez es más necesario adaptar los sistemas de tele-formación:
 Al tipo de conocimiento que se quiere aprender
 Al tipo de usuario (edad, formación previa, interés en la materia, etc.)
 Disponibilidad del tiempo del usuario (para realizar actividades síncronas o asíncronas)
 Disponibilidad en el espacio (para realizar actividades presenciales o a distancia)
 Siguiendo la máxima de los ingenieros: “a hacer se aprende haciendo”, se está
trabajando en la construcción de:
o Sistemas de simulación de actividades
o Entornos de realidad virtual, etc., que permitan formarse una idea más real del
dominio

Caliope
Se basa en el aprendizaje cooperativo asistido por computador; referencia [6]
El sistema consta de:
 Asistente personal para el alumno (LPA): guía el aprendizaje del alumno.
 Asistente personal para el profesor (TPA): realiza el seguimiento del curso en sus tres fases
(planificación, actuación, evaluación).
 Plataforma que de soporte a toda la estructura de agentes (AP).
 Agentes auxiliares.
 Herramienta para el diseño de cursos (CDT).

Asistente personal genérico


Capacidad de almacenar, aprender y manipular las preferencias del usuario.
Capacidad de aprendizaje y comunicación.
Consta de dos agentes:
a) Interfaz inteligente.
 Convierte los requerimientos del usuario en un lenguaje de comunicación entre agentes
(ACL) y viceversa.
 Gestiona los perfiles asociados a los usuarios (cuestionarios o aprendizaje.).
 Adaptar el interfaz al perfil del usuario.
 Filtrar la información según el perfil.
b) Colaboración el agente Buscador.
Como gestor de la agenda del usuario. Realizando tareas que pueden ser repetitivas para el
usuario; referencia [5].
 Maneja los avisos como: los plazos de entrega de trabajos, etc.
 Organiza las reuniones con el profesor y entre grupos de trabajo.
 Anuncia la lista de usuarios conectados.
 Colabora con James.
Asistente del alumno
A parte del núcleo básico de un asistente personal contiene un agente especializado:
 Orientador: guía en las tareas de aprendizaje de forma individualizada según las
características del propio alumno.
 Coordinador: coordina el trabajo con otros miembros del grupo (coedición
argumentativa) y/o con el profesor.
 Asesor: observa el comportamiento del estudiante para sugerir información adicional y
guiarlo con líneas de actuación que complementen el proceso de aprendizaje.
 Colabora con Orientador, Buscador, Consejero.
Asistente del profesor
Permite al profesor hacer un seguimiento del curso, mostrando la evolución de cada alumno y
de los grupos de trabajo.
Diseñador (Designer): diseña y gestiona el material del curso.
 Configurador: Permite al profesor configurar un curso, basándose en el material que ya
exista en el servidor o en Internet.
 Adaptador: el agente le permite al profesor adaptar los contenidos del curso a la
evolución del mismo, añadiendo o eliminando temas, modificando la duración o
contenido de algún tema.
Consejero (Counselor):
 Vigilante: Permite realizar un seguimiento del progreso tanto individual como colectivo
de los alumnos inscritos en el curso que imparte dicho profesor.
 Sintetizador: Una vez concluido el curso, sintetiza toda la información que ha recogido
durante el transcurso del mismo, y genera una serie de informes y estadísticas, para
evaluar el buen funcionamiento del mismo.
 Evaluador: El agente establece un diálogo entre el profesor y el alumno / grupo de
alumnos, para realizar una evaluación.

Agentes auxiliares.
 Wrapper: Gestiona el material del curso.
 Interfaz con las bases de datos propias.
 Interfaz con software desarrollado por terceros.
 Colabora con Orientador, Diseñador, Consejero.
 Buscador : Realiza búsquedas en la red.
 Atiende las peticiones de búsqueda.
 Monitorización de los proveedores de información.
 Gestión de la calidad de los proveedores de información.
 Colabora con Orientador, Buscador, James.

Figura Nª 3. Protocolo de co-edición


Fuente: Adaptación García Martínez [5]

Es necesario un protocolo para la co-edición de documentos entre varias personas.


Uno de los principales problemas es garantizar que la comunicación termine. Para ello hay las
opciones:
 Un plazo máximo para evaluar la propuesta.
 Iniciador puede cancelar la propuesta.
 Obligar a emitir un juicio sobre la propuesta aceptándola o rechazándola.
 Propuesta: Se emite una propuesta al grupo. Los participantes pueden emitir un juicio
sobre la propuesta aceptándola, rechazándola o iniciando una discusión con el resto
del grupo.
 Discusión: Permite explicar la propuesta inicial o emitir una contrapropuesta.
 Explicación: Un agente puede solicitar una explicación de la propuesta para poder
tomar una decisión.
 Aclaración: Es un intercambio de preguntas / respuestas entre agentes.
 Comentario: Es una simple opinión que no espera contestación.

1. Los componentes fundamentales de un STI

El siguiente esquema representa los cuatro módulos principales que componen un STI:
El módulo "Modelo del alumno" contiene el cuerpo de conocimientos que caracterizarán al
usuario y lo representa desde perspectivas diferentes como los aspectos psico-sociológicos
característicos que condicionan el proceso de aprendizaje.

El módulo "Pedagógico" contiene representación de conocimiento experto en los ámbitos


relativos a procesos de evaluación, enseñanza-aprendizaje; aprendizaje humano y metodología
de enseñanza. Será el razonador, dónde se almacenará la base de conocimiento y los
mecanismos de resolución de problemas. Este módulo es el responsable de dirigir la ejecución
del módulo "Modelo Didáctico" teniendo en cuenta los datos ingresados desde el módulo
"Modelo del alumno".

El módulo "Modelo Didáctico" cumple la función de tutor o profesor y contiene información para
decidir qué tareas se le presentan al estudiante de acuerdo con los objetivos de aprendizajes
que el "Módulo Pedagógico" deja establecidos y los mecanismos para corregir el modelo del
alumno. Es el encargado de generar los planes instruccionales de cada sesión. Este módulo es
responsable de la activación del módulo "Interface".

Las tareas de aprendizaje son presentadas por el STI a través de una Interface Multimedia. Esta
debe estar dotada de múltiples medios de comunicación, eficazmente integrados y
combinados, para lograr una enseñanza adaptada y eficiente. El módulo "Interface Multimedia"
contiene los mecanismos de representación (imágenes animadas, imágenes estáticas, sonido,
lenguaje oral, lenguaje escrito, reconocimiento de voz, etc.) de informaciones necesarias para
la realización de tareas que el sistema propone al sujeto. “El éxito de un programa educativo, su
calidad y efectividad, dependen en gran parte de la riqueza comunicadora que reúna”
referencia [10]. Esta cuestión empezó a interesar al campo de la Psicología Cognitiva, existiendo
recientes investigaciones que demuestran que es fundamental tener en cuenta algunos
principios de diseño multimedia para lograr y potenciar los aprendizajes; referencia {7} y [11].

2. Modelado del alumno

La característica principal de los Sistemas Tutoriales Inteligentes (STI) es su capacidad de


adaptarse a cada alumno. Entonces, el problema de obtener toda la información posible
acerca del alumno se convierte en el problema principal a la hora de diseñar un tutor
inteligente. En efecto, es necesario que en cada momento el STI disponga de una
representación del estado actual del conocimiento del alumno, con objeto de poder
seleccionar los contenidos a enseñar en el nivel adecuado de dificultad, proponer el problema
apropiado o seleccionar la estrategia tutorial más efectiva en ese momento.

El modelo del alumno es la representación de los procesos mentales que lleva a cabo para
realizar un aprendizaje en un computador. Estos procesos mentales no son modelos
cuantitativos, representables por números, sino que son modelos cualitativos. Los modelos
cualitativos describen situaciones en el mundo: objetos y procesos en términos de relaciones
temporales, espaciales y causales. “En los sistemas de enseñanza se pueden diferenciar tres tipos
de modelos: el modelo del diagnostico, el modelo del alumno, y el modelo de comunicación
que permite interactuar con el alumno” referencia [11].
Interactúa con el
perfil
Modelo del Alumno Conocimiento Pedagógico
Perfil Conocimiento Experto
Características del Alumno Proceso de enseñanza-aprendizaje
Historial Proceso de evaluación
Da objetivos
Cuerpo de conocimiento Metodologías de enseñanza
de de aprendizaje

Informa perfil del


alumno

Corrige
Interface Multimedia
Modelo Didáctico
Evalúa y Guía Inteligente
Acción Pedagógica Controla
Ejecuta Estrategias a utilizar Formas de representación
Interacción con el alumno Estímulos sensoriales

Interactúa
con tareas

Figura Nª 4. Modelo Tradicional de un STI


Fuente: Adaptado Revista Iberoamericana de Educación [1]

El modelo de diagnóstico debe inferir que está pensando el alumno y que creencias tiene.
Además, describe un estado cognitivo oculto (el conocimiento del estudiante sobre el tema a
tratar) desde el comportamiento observado.

Para realizar un diagnostico se necesitan unas entradas que son recogidas mediante la
interacción con el alumno, por preguntas directas u otros medios de información, tales como sus
fichas personales. La salida del modulo de diagnóstico es una base de datos, el modelo del
alumno, que refleja con precisión el estado de conocimiento del alumno.

El modelo del alumno se define como los componentes de un STI que representan el estado
actual de un estudiante, pero es también un modelo de simulación, que describe los procesos
por los cuales el estudiante recoge información sobre un problema y realiza aserciones, por lo
que uno puede predecir que hará el alumno próximamente.

-Modelo de superposición (overlay model).

En este enfoque se considera que el conocimiento del alumno es un subconjunto propio del
conocimiento del experto. Este enfoque supone que todas las diferencias entre el
comportamiento del alumno y el del experto se explican como una falta de conocimiento del
alumno. El modelo funciona bien cuando el principal objetivo del sistema instructor es transmitir
el conocimiento experto al alumno. El mayor problema de dichos modelos es que no consideran
que el alumno puede poseer conocimiento que el experto no posee, y por tanto son incapaces
de reaccionar ante esta situación. Esta carencia motivó la aparición de otros modelos.

-Modelo diferencial (differential model). Es una modificación del modelo de superposición.

Este modelo divide el conocimiento del alumno en dos categorías: conocimiento que el alumno
debería poseer y conocimiento que no puede esperarse que el alumno tenga. Así, a diferencia
del modelo de superposición, el modelo diferencial reconoce y trata de representar
explícitamente tanto el conocimiento del alumno como las diferencias alumno/experto. Puede
considerarse como un modelo de superposición, pero en lugar de sobre el conocimiento del
experto, sobre un subconjunto de éste.

-Modelo de perturbación (perturbation model).

Mientras que el modelo de superposición representa el conocimiento del alumno en términos


del conocimiento “correcto”, el modelo de perturbación lo combina con una representación
del conocimiento incorrecto.

De este modo, no se considera al alumno como un “subconjunto” del experto, sino que el
conocimiento del alumno puede ser potencialmente diferente en calidad y cantidad al del
experto. La técnica más frecuente para implementar un modelo de perturbación es representar
el conocimiento experto y añadirle los errores que más frecuentemente cometen los alumnos.

El modelo del alumno es entonces un modelo de superposición sobre este conjunto de


conocimiento aumentado (que incluye conocimientos correctos e incorrectos). En la literatura
aparecen dos tipos de errores: errores de concepto (misconceptions) y fallos o erratas (bugs).

- Modelo basado en restricciones. Este modelo es una modificación del modelo de


superposición propuesto por (Ohlsson, 1994) e implementado con éxito en el tutor de SQL de
(Mitrovic, 1998; Mitrovic y Ohlsson, 1999) referencia {9}. El dominio de conocimiento se representa
mediante una serie de restricciones sobre el estado de los problemas, y el modelo del alumno es
simplemente una lista de las restricciones que ha violado en el proceso de resolución del
problema. La principal ventaja de este enfoque es su robustez y flexibilidad. Es robusto ya que no
depende de la estrategia que haya seguido el alumno para resolver el problema, y por tanto
puede modelar a alumnos que tengan patrones de comportamiento inconsistentes, es decir,
que utilicen estrategias diferentes para problemas diferentes. Además, el modelo es
suficientemente flexible para reconocer soluciones innovadoras como correctas. La traza del
conocimiento consiste en determinar qué sabe el alumno, incluyendo tanto el conocimiento
correcto sobre el dominio como sus errores. La traza del modelo pretende analizar el
procedimiento de resolución de problemas que utiliza el alumno. La traza del modelo resulta útil
en sistemas que intentan dar respuesta a peticiones de ayuda del alumno y ofrecerle pistas e
información cuando no sabe seguir resolviendo el problema.

- Modelo de comunicación: De hecho, para poder ayudar al alumno el sistema necesita ser
capaz de analizar y criticar la solución en curso y tener una idea de que línea de razonamiento
está siguiendo, para poder determinar una comunicación directa y con precisión.

Conclusiones

Las aplicaciones de la IA en la Educación necesitan del trabajo multidisciplinar, tanto de


profesionales de la Educación, como de Informática, y Psicología que responden en general, a
demandas y problemáticas concretas de trabajo. De esta interconexión, la disciplina ha crecido
incesantemente durante estos últimos años, evolucionando desde la perspectiva de la
concepción de crear sistemas, donde se contemplaba solamente la interacción del alumno
con el computador y no así, el entorno social que afecta al aprendizaje del alumno mediante el
computador.

Estas iniciativas son importantes desde el punto de vista tecnológico, ya que la tecnología
evoluciona sin parar y es muy importante estudiar sus posibles aplicaciones al área educativa.

Por el contrario, otras aplicaciones ya son una realidad en los colegios desde hace años atrás, y
“Se ha demostrado la eficacia de los STIs eficacia frente a otros medios” referencia Anderson y
otros [8], y actualmente, el ámbito donde más aplicaciones podemos encontrar de técnicas
consideradas “inteligentes” y entornos de aprendizaje colaborativo es en las universidades
virtuales.

Para terminar este artículo deseo destacar que todas estas aplicaciones tecnológicas no son
más que recursos que debe ser incorporados en un entorno más amplio y complejo, como es el
sistema educativo. Para que estas aplicaciones sean una realidad en las escuelas del futuro se
debe impulsar la formación tanto de profesores como alumnos en el uso y en las posibilidades
de las herramientas tecnológicas, apoyando el desarrollo de políticas institucionales que dirijan
la implementación de estas tecnologías desde la escuela.

Bibliografía

1. Revista Iberoamericana de Inteligencia Artificial. No.12 (2001), pp. 5-12. ISSN: 1137-3601. ©
AEPIA, http://www.aepia.dsic.upv.es/.
2. Julio Cabero Almenara y Otros; Las nuevas tecnologías en la actividad universitaria,
Revista de Medios y educación, 20, 81-100, 2003.
3. Guardia Robles, B. México, D.F. 1997. Asesores Inteligentes para apoyar el Proceso de
Enseñanza de Lenguajes de Programación. Tesis de Maestría. Instituto Tecnológico y de
Estudios Superiores de Monterrey. Campus Ciudad de México.
4. INFORMEDICA 2004 information & communication technologies in healthcare
development
5. García Martínez, r. Y Britos, P.[2004]. Ingeniería de Sistemas Expertos. Editorial Nueva
Librería.
6. Inteligencia Artificial: un enfoque moderno, Stuart Russell y Peter Norvig, 1995,5
7. Soledad González, C. (2004). Sistemas inteligentes en la educación: una revisión de las
líneas de investigación y aplicaciones actuales. RELIEVE: v. 10, n. 1, p. 3-22.
http://www.uv.es/RELIEVE/v10n1/RELIEVEv10n1_1.htm
8. Anderson de Rezende Rocha, Elmo Melquíades de Souza Júnior, Júlio César Alves. 2003.
9. Guardia Robles, B. México, D.F. 1997. Asesores Inteligentes para apoyar el Proceso de
Enseñanza de Lenguajes de Programación. Tesis de Maestría. Instituto Tecnológico y de
Estudios Superiores de Monterrey. Campus Ciudad de México.

Enlaces online

10. COLLIDE. Collaborative Learning in Intelligent Distributed Environments. Universtity Duisburg-


Essen. http://www.collide.info.
11. ELM-ART. Episodic Learner Model- Adaptive Remote Tutor. http://www.psychologie.unitrier.
de:8000/elmart
HOJAS DE ESTILO

RESUMEN
Las hojas de estilo, especifican atributos para los elementos de una página Web
y además ofrecen un mayor control sobre el aspecto de nuestros documentos.
Con ellas podemos controlar muchos atributos tales como colores, márgenes,
alineación de elementos, tipos y tamaños de letras, y muchos más.

También se puede emplear hojas de estilo como patrones o páginas maestras


de forma que múltiples páginas puedan tener el mismo aspecto. René Casilla Gutiérrez
Docente Investigador
Las hojas de estilo, permiten separar el contenido de la forma de presentación Carrera de Informática - UMSA
de una página web, esto sugiere que algunos preparen el contenido y otros rencas@gmail.com
definan la presentación o forma de una página web.

PALABRAS CLAVE: Hojas de Estilo, CSS, LINK.


KEYWORDS: Style Sheet, CSS, LINK.

El concepto de hojas de estilo apareció por primera vez en 1996, cuando W3C (World Wide Web
Consortium) publicó una recomendación denominada "Hojas de Estilo en Cascada o CSS”. CSS
son las siglas de Cascade Style Sheet que traducido significa Hojas de Estilo en Cascada. Se
denominan "Hojas de Estilo en cascada" porque se pueden definir múltiples hojas y los estilos
pueden aplicarse a todas las páginas (con un sistema predefinido para resolver conflictos).

El consorcio que regula los estándares para la web recomienda separar el contenido y el diseño
de una página web. El contenido se genera con HTML ( HyperText Markup Language, Lenguaje
para el Formato de Documentos de Hipertexto) y el diseño se realiza mediante Hojas de Estilo [1].

Ventajas de las Hojas de Estilo

 Control preciso sobre la presentación, fuentes, colores, fondos y otros efectos tipográficos,
lograr una apariencia uniforme de todo el sitio al activar una sola definición de estilo en
cada página;

 Formatea un gran número de páginas con tan sólo modificar un documento es decir
permite cambiar un aspecto en todo el sitio Web con tan sólo editar unas pocas líneas,
hacer que los códigos HTML sean más fáciles de leer ya que los estilos se definen por
separado;

 Código mas claro, permite que las páginas se carguen más rápido ya que hay menos
cantidad de código HTML en cada página.

Desventajas de las Hojas de Estilo

La principal, es el soporte irregular que tienen las CSS por parte de los navegadores (browser).
Ciertas propiedades que funcionan en un browser no funcionan en otros. Esto provoca que:

 La página web sea visualizada por el lector con un formato no deseado por nosotros;

 Las propiedades de posicionamiento o visibilidad, provocan que una parte del contenido
de la página web resulte inaccesible desde ciertos navegadores si no son utilizadas
correctamente.

Definición de Estilos mediante CSS

Por ejemplo, para hacer que el color de los elementos 'H1' sea rojo, basta con decir:

H1 { color: red; }
Este ejemplo es una regla CSS sencilla. Una regla consta de dos partes principales:

 Un selector ('H1') ;
 Una declaración ('color: red'). La declaración tiene dos partes: una propiedad ('color') y un
valor ('red').

El separador de una declaración es punto y coma (;).

Aplicando Hojas de Estilo en un documento HTML

Se pueden incorporar estilos a un documento HTML de cuatro formas distintas [2]:

 Estilo de Documento: se declara en el encabezado, es decir, dentro de las etiquetas


<head> y </head>;

 Estilo en Línea, tiene el mismo significado que los atributos de las etiquetas HTML.

 Estilo Externo, se declara en un archivo separado con la extensión css;

 Estilo Importado, permite importar hojas de estilo desde otras hojas de estilo;

El más utilizado es el Estilo Externo que generalmente tiene las siguientes etapas:

El primer paso es crear un archivo de texto que contenga los estilos, cuya extensión es .css, para
el ejemplo tendrá una sola línea y se denomina miestilo.css,

h1 { color:red; font-family:impact; }

A continuación, se debe agregar a cada página web un acceso directo al archivo miestilo.css
de la siguiente forma:

<html>
<head>
<title>Estilo Externo en CSS</title>
<link rel=”stylesheet” href="miestilo.css" type="text/css">
</head>
<body>
<h1>Texto de color Rojo y Fuente de letra Impact </h1>
</body>
</html>

Es una ventaja poder almacenar definiciones de hojas de estilo fuera del documento ya que por
lo tanto es posible, al editar el archivo que contiene los estilos, cambiar la apariencia de todas
las páginas Web que utilizan ese archivo de estilos. Este método, ahorra mucho trabajo, por
ejemplo si quisieras cambiar el color de fondo de un sitio web compuesto por 1000 páginas, una
hoja de estilo puede ahorrarte el tener que cambiar de forma manual los 1000 documentos
HTML. Con CSS, el cambio se puede llevar a cabo en unos segundos modificando parte del
código de la hoja de estilo principal.

Estilos en Cascada

Con la utilización de los distintos métodos de implementación CSS se pueden definir múltiples
estilos. Por tal razón, activar varias hojas de estilo externas da como resultado lo que se
denomina estilo en cascada, una combinación de estilos para diferentes elementos HTML. Si
varios estilos afectan al mismo elemento, se mantendrá solamente el último (en el ejemplo el
estilo2.css).

<link rel=stylesheet type="text/css" href="estilo1.css">


<link rel=stylesheet type="text/css" href="estilo2.css">

Además, cuando se activan múltiples estilos dentro de una página al utilizar varios métodos de
inclusión posibles y algunos estilos entran en conflicto, se aplica el estilo más próximo al
contenido. La prioridad, en orden descendente, es el siguiente:

Estilo en Línea > Estilo de Documento > Estilo Importado > Estilo Externo.
Ejemplo Práctico

Un código de página web sin estilos es el siguiente:

La página web sin estilos, visualizada en un navegador (Figura No. 1) es:

Figura No. 1: Página Web sin estilos

Aplicando Estilos a la página web anterior se tiene el siguiente código:


El código de la hoja de estilos, miestilo1.css es:
La visualización en un navegador de la página con estilos (Ver Figura No. 2) es:

Figura No. 2: Página Web Con estilos

Se nota fácilmente con el ejemplo propuesto, que es posible la separación de contenido y


forma de presentación de las páginas web, ya que el código de la página web sin estilos no
varía en casi nada en el código de la página web con estilos.

Conclusiones

El uso adecuado de Hojas de Estilo, permite la separación de Contenido y Forma en la creación


de páginas web y lograr un mejor mantenimiento de las páginas web.

La información de una página web, debe realizarse con elementos HTML básicos que no
contengan atributos de estilo ni forma, para así concentrarse en la elaboración de contenido.

La forma o estilo de una página web debe realizarse con hojas de estilo, para lograr una mejor
presentación y uniformidad en los diferentes documentos HTML de un sitio web.

Referencias Bibliográficas

22. Perdrix, S, P., 2004: Hojas de Estilo y Usabilidad. 96 pags. Ed. Grupo Griho, España.
23. Eguíluz, P, J., 2007: Introducción a CSS. 219 pags. Ed. Creative Commons.
PROGRAMACION ORIENTADA A COMPONENTES
Celia Elena Tarquino Peralta
Docente – Carrera de Informática UMSA
celiaetp@hotmail.com

Carmen Rosa Huanca Quisbert


Docente –Carrera de Informática UMSA
c_huanca@hotmail.com
RESUMEN

El Desarrollo de Software Basado en Componentes, surge en respuesta a la necesidad de desarrollar proyectos


complejos. Si bien la Orientación a Objetos introdujo, un cambio radical en el proceso de desarrollo de software,
este paradigma abrió, nuevas posibilidades para desarrollar software basado en la reutilización de componentes.

La Orientación a Objetos creó un rumbo diferente en el proceso de reutilización a través de la producción de


componentes genéricos, fáciles de integrar, distribuidos e independientes de las plataformas de desarrollo,
denominada Desarrollo de Software basado en Componentes.

PALABRAS CLAVE: Desarrollo de Software Basado en Componentes, Programación Orientada a


Componentes, Programación Orientada a Servicios, Paradigmas de la Programación,
Programación, Paradigma.

KEYWORDS: Component Based Software Development, Bussines Component Object Oriented


Programming, Paradigm, Programming.

1. Introducción

A pesar de la aparente evolución que ha sufrido la programación a lo largo de los últimos 40


años, el desarrollo de una aplicación continúa siendo una actividad costosa en tiempo y dinero
y los errores en el producto final son frecuentes.

La reutilización de componentes de software es un problema latente, a pesar de la multitud de


librerías, toolkits y frameworks existentes. Este proceso esta inspirado en la manera en que se
producen y ensamblan componentes en la ingeniería de sistemas físicos. La aplicación de este
concepto al desarrollo de software no es nueva. Las librerías de subrutinas especializadas,
comúnmente utilizadas desde la década de los setenta, representan uno de los primeros
intentos por reutilizar software.

El desarrollo de software basado en componentes (DSBC), es una tecnología que ha empezado


a demostrar que ofrece ventajas en tiempo de desarrollo y reducción de costos en el proceso[1]
de desarrollo de software.

2. Antecedentes

¿Qué es un paradigma?

Un paradigma es un determinado marco desde el cual miramos el mundo, lo comprendemos, lo


interpretamos e intervenimos sobre él. Abarca desde el conjunto de conocimientos científicos
que imperan en una época determinada hasta las formas de pensar y de sentir de la gente en
un determinado lugar y momento histórico.

Los paradigmas son un patrón o modelo; una serie de reglas los cuales establecen límites,
explican como resolver problemas dentro de los mismos límites. Los paradigmas influyen en la
manera de ver el mundo.

A paradigm is a constellation of concepts, values, perceptions and practices shared by a


community which forms a particular vision of reality that is the basis of the way a community
organises itself [2].

¿Qué es un paradigma de programación?

Un paradigma de programación es un modelo básico de diseño y desarrollo de programas, es


una colección de modelos conceptuales que juntos modelan el proceso de diseño y
determinan, al final, la estructura de un programa.

Los paradigmas de programación nos indican las diversas formas que, a lo largo de la evolución
de los lenguajes, han sido aceptadas como estilos para programar y para resolver los problemas
por medio de una computadora.

Clasificación de los Paradigmas de Programación

Floyd describió tres categorías de paradigmas de programación:

a) Los que soportan técnicas de programación de bajo nivel (ej.: copia de ficheros frente
estructuras de datos compartidos)
b) Los que soportan métodos de diseño de algoritmos (ej.: divide y vencerás,
programación dinámica, etc.)
c) Los que soportan soluciones de programación de alto nivel, como los descritos en el
punto anterior

Floyd también señala lo diferentes que resultan los lenguajes de programación que soportan
cada una de estas categorías de paradigmas. Se agrupan en tres categorías de acuerdo con la
solución que aportan para resolver el problema

a) Solución procedimental u operacional. Describe etapa a etapa el modo de construir la


solución. Es decir señala la forma de obtener la solución.
b) Solución demostrativa. Es una variante de la procedimental. Especifica la solución
describiendo ejemplos y permitiendo que el sistema generalice la solución de estos
ejemplos para otros casos. Aunque es fundamentalmente procedimental, el hecho de
producir resultados muy diferentes a ésta, hace que sea tratada como una categoría
separada.
c) Solución declarativa. Señala las características que debe tener la solución, sin describir
cómo procesarla. Es decir señala qué se desea obtener pero no cómo obtenerlo.

Autores clasifican los paradigmas de modos similares, destacando el imperativo, el orientado a


objetos, el funcional y el lógico. Algunos mencionan paradigmas heurísticos, concurrentes,
procedimentales, declarativos y demostrativos.

3. Paradigma Orientado a Componentes

La Programación Orientada a Componentes (POC) [1] aparece como una variante natural de
la programación orientada a objetos (POO) para los sistemas abiertos, donde la POO presenta
algunas limitaciones; por ejemplo, la POO no permite expresar claramente la distinción entre los
aspectos computacionales y composicionales de la aplicación, no define una unidad concreta
de composición independiente de las aplicaciones (los objetos no lo son, claramente), y define
interfaces de demasiado bajo nivel como para que sirvan de contratos entre las distintas partes
que deseen reutilizar objetos.

La POC nace con el objetivo de construir un mercado global de componentes software, cuyos
usuarios son los propios desarrolladores de aplicaciones que necesitan reutilizar componentes ya
hechos y probados para construir sus aplicaciones de forma más rápida y robusta.

Las entidades básicas de la POC son los componentes, cajas negras que encapsulan cierta
funcionalidad y que son diseñadas para formar parte de ese mercado global de componentes,
sin saber ni quien los utilizará, ni cómo, ni cuándo. Los usuarios conocen acerca de los servicios
que ofrecen los componentes a través de sus interfaces y requisitos, pero normalmente ni
quieren ni pueden modificar su implementación.

3.1 Componente

Definición 1 Un componente es una unidad binaria de composición de aplicaciones software,


que posee un conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser
desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma
independiente, en tiempo y espacio[1].
Definición 2 Una implementación que [3]:
(a) Realiza un conjunto de funciones relacionadas
(b) Puede ser independientemente desarrollado, entregado e instalado
(c) Tiene un conjunto de interfaces para los servicios
servicios proporcionados y otro para los
servicios requeridos.
(d) Permite tener acceso a los datos y al comportamiento sólo a través de sus interfaces
(e) Opcionalmente admite una configuración controlada.

Definición 3 Un componente software es un fragmento de un sistema software que puede ser


ensamblado con otros fragmentos para formar piezas mas grandes o aplicaciones completas
completas[4].

Definición 4:: Para Booch, un componente reutilizable de software es un módulo lógicamente


cohesivo y con poco acoplamiento que denota una sola abstracción. Los componentes de
software reutilizables son elementos autocontenidos, claramente identificables que describen
y/o realizan funciones específicas, tienen interfaces claras, documentación
docu mentación apropiada y un
propósito de rehúso bien definido.

Definición 5: Un componente es una unidad de composición con interfaces contractuales


especificadas y dependencias de contexto explícitas. Un componente de software puede ser
desarrollado independientemente
ndientemente y utilizado por terceras partes para integrarlo mediante
composición a sus sistemas. Los componentes son para crear software utilizando composición,
por eso es esencial que sean independientes y que se presenten en formato binario, permitiendo
así distintos vendedores e integración robusta
robusta[5].

Un componente no es un objeto,
objeto a diferencia de los objetos, los componentes no tienen estado.
Un componente puede tomar la forma de un archivo ejecutable o una biblioteca dinámica que
usualmente cobra vidaa a través de objetos. Los os primeros componentes conocidos fueron las
bibliotecas de procedimientos. Sin embargo, los objetos, con sus características de
encapsulación y polimorfismo, facilitan la construcción e integración de componentes.

Los componentes de e software son unidades ejecutables de producción independiente,


adquisición e implementación que pueden formar parte de un sistema funcional. Para permitir la
composición, un componente de software se adhiere a un modelo de componentes particular y
apunta a una plataforma de componentes particular.

Existe un mayor mercado de componentes para el lado cliente,, en cambio para el lado del
servidor son
on desarrollados localmente.

3.2 Objetivo del Desarrollo de Software Basado en


Componentes

Construir un mercado global de componentes


cuyos usuarios son los propios desarrolladores de
aplicaciones que necesitan reutilizar componentes
ya hechos y probados para construir sus
aplicaciones de forma más
ás rápida y robusta o que
quieren añadir funcionalidad dependiente de
terceros.

3.3 Características de los componentes

Un componente debe tener las siguientes


características:
 Es una unidad software compilada
reutilizable, con una interfaz bien definida.
 Se distribuye en un único paquete
instalable que contiene en sí todo lo
necesario para su funcionamiento, con
ninguna o muy pocas dependencias con
otros componentes o librerías Figura No. 1:: Mercado compartido en ComponentSource
 Puede estar implementado en cualquier
lenguaje de programación y ser utilizado también para el desarrollo en cualquier
lenguaje de programación.
 Normalmente es un producto comercial de calidad, realizado por un fabricante
especializado. Por supuesto pueden existir componentes gratuitos.
 Un componente puede ser implementado mediante cualquier lenguaje de
programación, aunque los lenguajes orientados a objetos son especialmente
adecuados para este fin.

3.4 Diagramas UML

Los diagramas UML permiten la representación de: Componentes, Interfaces, paquete y nodos
como se observa en las figuras a), b), c) y d).

a) Componente b) Interfaces c) Paquete d) Nodo

Figura No.2: Diagramas UML


Fuente: Espeso Martinez Pedro Javier, 2002

3.5 Arquitectura Software de una aplicación basada en componentes

Una aplicación esta constituida por un número de componentes específicos, que hacen uso de
otros muchos componentes
prefabricados que se ensamblan entre sí
para proporcionar los servicios que se
necesitan en la aplicación.
En la tecnología de componentes la
interfaz constituye el elemento básico de
interconectividad. Cada componente
debe describir de forma completa las
interfaces que ofrece, como las interfaces
que requiere para su operación. Y debe
operar correctamente con
independencia de los mecanismos
internos que utilice para soportar la
funcionalidad de la interfaz. Figura No. 3: Componentes en una Aplicación
Fuente: Espeso Martinez Pedro Javier, 2002

3.6 Características de la Programación Orientada a Componentes

Lo más relevante de la tecnología de programación basada en componentes es la


modularidad, la reusabilidad y componibilidad y en todos ellos coincide con la tecnología
orientada a objetos de la que se puede considerar una evolución.

Principios básicos compartidos con Orientación a Objetos

 Integración de datos y funciones: un objeto software consiste en una serie de


valores (estado) y las funciones que procesan esos datos.
 Encapsulamiento: el cliente de un objeto software no tiene conocimiento de
cómo son almacenados los valores en el interior del objeto, ni como se
implementan las funciones.
 Identidad: cada objeto software tiene una identidad única.
 Polimorfismo: las interfaces se describen por separado de la implementación,
de modo que un código que requiera una determinada interfaz puede utilizar
cualquier componente (objeto) que implemente dicha interfaz. Esto permite
una gran flexibilidad en el diseño de aplicaciones.
 Distribución: Los componentes residen en diversas máquinas integrantes de una
red.
 Heterogeneidad: Se ejecutan en diferentes plataformas, sistemas operativos,
escritos en diferentes lenguajes, diferentes desarrolladores.
 Independencia de la extensibilidad: Modificables y ampliables añadiendo
nuevas componentes.
 Dinamismo: Sujetos a evolución por ampliación, desaparición, sustitución de
componentes o reconfigurando las relaciones entre ellos.

Figura No. 4: Evolución de la POO a la POC


Fuente: Espeso Martinez Pedro Javier, 2002

Los componentes presentan una serie de ventajas frente a las tecnologías orientadas a objetos:
 Componentes desarrollados con diferentes lenguajes de programación son compatibles
y pueden ejecutarse dentro de una misma aplicación.
 Los componentes puede tener su propio estado persistente.
 Las funciones de la interfaz no tiene que estar necesariamente implementadas
utilizando técnicas orientadas a objeto.
 Los componentes requieren mecanismos de empaquetamiento que deben ser más
robustos que los de los objetos.
 Normalmente las instancias de componentes se instalan en un contenedor, que les
proporciona contexto local. Mientras el componente aporta la simplemente la
funcionalidad, es el contenedor quien se encarga de mapear las estructuras de datos
desde el espacio lógico hasta el espacio físico de memoria en la máquina sobre la que
se está ejecutando.
 Los componentes integran servicios completos, lo que minimiza las interconexiones entre
módulos.

La tecnología de componentes es
habitual en otras ingenierías, y su
éxito se basa en:

 Una especificación
completa hacia el usuario.
Tanto de los servicios que
ofrece como de los
servicios externos que
requiere para operar
correctamente.
 Múltiples interfaces en los
que se especifican los
diferentes modos de
acoplo que admite, así como los mecanismos de acoplo y sus compatibilidades.
 Un empaquetamiento robusto, de
fácil manipulación y que Figura No. 5: Arquitectura interna de un componente
garantice un funcionamiento Fuente: Espeso Martinez Pedro Javier, 2002
fiable e independiente de otros componente que operen junto a él.
 Una catalogación estándar que simplifique su localización, permita su sustitución por
otros equivalentes y que facilite el desarrollo de múltiples fuentes que garantice el
soporte del producto.
 Debe ofrecer mecanismos de validación en el entorno de trabajo del usuario y
capacidad de configuración y sintonización de acuerdo con las necesidades de la
aplicación.

La arquitectura interna, las peculiaridades de su implementación y la tecnología que lo soporta,


sólo debe interesar al diseñador del componente y a los que sean responsables de su
mantenimiento y evolución. Ver Figura 5.

3.7 Modelos de Desarrollo

Un entorno de desarrollo orientado a componentes debe facilitar la instalación de componentes


y su configuración e integración en una aplicación.

La metodología de desarrollo basada en componentes, ha adquirido el respaldo de compañías


importantes como Microsoft y Sun que han propuesto sus propios modelos de desarrollo. Los más
populares actualmente son COM+/DCOM, CORBA y Java Beans[19].

COM y DCOM. El Component Object Model (COM), es la propuesta de Microsoft en materia de


componentes, [10].
COM es esencialmente un esquema de integración, de modo que los componentes que se
construyen para trabajar bajo este modelo, deben describir su comportamiento bajo las
consideraciones de este esquema, el cual es popularmente conocido como estándar binario.
Este estándar permite que las interfaces de los componentes se presenten a los clientes como un
conjunto de apuntadores a tablas en memoria, llamadas tablas virtuales de funciones. El
llamado de funciones entre componentes se realiza utilizando estos apuntadores, ocultándose
así detalles de implementación, lo cual permite que componentes que estén escritos en
diferentes lenguajes de programación, como: C++, Small Talk, Ada, VisualBasic, Delphi o Power
Builder, puedan comunicarse.
Distributed COM, DCOM, es una extensión de COM que se implementa como una respuesta a la
necesidad de aplicaciones distribuidas, proporcionando capacidades para el trabajo con
componentes que residen en diferentes computadoras. DCOM utiliza como mecanismo de
comunicación los llamados a procedimientos remotos (RPC), los cuales son transparentes para el
cliente.
Tanto COM como DCOM son modelos que inicialmente fueron implementados para trabajar
bajo ambientes Windows y Windows NT, sin embargo actualmente existen versiones para operar
con MacOS y UNIX.

CORBA, Common Object Request Broker Architecture, es una infraestructura abierta para el
manejo de objetos distribuidos que esta siendo estandarizada por el Object Management
Group (OMG), [11]. En CORBA, un objeto se considera como una instancia de una clase que
encapsula operaciones, atributos y excepciones.
CORBA permite que los objetos puedan comunicarse con otros sin necesidad de preocuparse
por donde están localizados o por quien han sido diseñados. Para esto, se han considerado
algunos elementos importantes como: un lenguaje de definición de interface (IDL) y una API que
provee al programador la interacción cliente-servidor entre componentes con la
implementación especifica de un Object Request Broker (ORB).
Un componente expone un conjunto de interfaces, implementadas utilizando un lenguaje de
definición llamado OMG Interface Definition Language (OMG IDL), mismas que definen las
operaciones de los objetos. Actualmente existen estándares para el mapeo de un IDL a
lenguajes de programación como C, C++, Java, Smalltalk, o Ada.

JavaBeans. Actualmente uno de los modelos de desarrollo de software basado en


componentes con mayor aceptación, es el propuesto por Sun Microsystems [12].
Java Beans es una API implementada para la construcción y uso de componentes escritos en
Java, los cuales son comúnmente llamados Beans. Esta API es proporcionada por SUN como una
herramienta visual que permite la carga, utilización, modificación, así como también
interconexión de Beans, con el propósito de construir nuevos Beans, applets o bien aplicaciones
completas.
Un Bean es un elemento de software sobre el cual solo se conoce su función, es preciso contar
con algún mecanismo que permita la comunicación con él. En este modelo, ese mecanismo de
comunicación consiste en una interfaz, a partir de la cual, se puede acceder a los elementos
principales de un Bean: sus métodos, propiedades y eventos. Los eventos son utilizados por el
Bean como un medio de comunicación con otros Beans.
La característica más importante de un Bean es que el componente este escrito en Java,
además de soportar las siguientes capacidades:
a) Introspección, mecanismo mediante el cual se pueden descubrir las propiedades,
métodos y eventos que un Bean contiene.
b) Soporte a propiedades, la posibilidad de conocer las características de los atributos y la
capacidad de poder ser modificados a tiempo de diseño.
c) Soporte a eventos, actividades como generación, escucha o respuesta a eventos con
el propósito de comunicarse con otros Beans.
d) Persistencia, capacidad para salvar y recuperar las especializaciones realizadas a un
Bean.

3.8 Metodología de desarrollo de aplicaciones basado en componentes

El con junto de actividades que


intervienen en el proceso se
muestra en la siguiente Figura:

 Requerimientos: Obtener
una idea clara y concreta
de los requerimientos que
exige la aplicación.
 Especificación:
Identificación, interacción y
especificación de
componentes.
 Aprovisionamiento: A partir
de las especificaciones se Figura No. 6: Fases de la metodología
implementa la Fuente: Espeso Martinez Pedro Javier, 2002
funcionalidad de los
componentes.
 Ensamblado: se conectan los componentes unos con otros a través de sus interfaces para
lograr la funcionalidad requerida.
 Test: se comprueba el correcto funcionamiento de las aplicaciones.
 Despliegue: se instalan las aplicaciones probadas en el entorno de trabajo donde van a
llevar a cabo su funcionamiento.

3.9 Especificación y Diseño Funcional de Componentes

En la figura se presenta las fases para la construcción de un componente

 Interface define los


diferentes aspectos del
comportamiento de un
componente relativos a un
mismo dominio que se ofrecen
como una unidad o servicio
que puede ser ofrecido de
forma intercambiable por
diferentes componentes.
 Especificación de un
componente es un descriptor
del comportamiento de un
conjunto de objetos
componentes y define una
unidad de implementación.
Figura No.7: Fases de la construcción de un componente
Fuente: Espeso Martinez Pedro Javier, 2002

 Implementación de un componente es una realización de una especificación de


componente que puede ser utilizado en el desarrollo de una aplicación.
 Componente instalado o desplegado es una copia de una implementación de un
componente que está registrado en algún entorno de ejecución. Esto capacita al
entorno de ejecución para identificarlo y usarlo cuando se genere una instancia del
componente o se invoque alguna de sus operaciones.
 Componente objeto es una instancia ejecutable de un componente instalado. Es un
concepto de ejecución. Es un objeto con una única identidad y con su propia instancia
de datos y estado.

4. Discusión de resultados

El desarrollo de la aplicación de prueba esta en JavaBeans, como la tecnología de


componentes de Java, los componentes de JavaBeans se conocen simplemente como beans
que es una clase de objetos, con ciertas características especiales:
 Es una clase pública que implementa la interfaz Serializable
 Expone una serie de propiedades que pueden ser leídas y modificadas desde el entorno
de desarrollo.
 Expone una serie de eventos que pueden ser capturados y asociados a una serie de
acciones.

Diagrama de paquete de la aplicación. Muestra los niveles de la aplicación de prueba

Interfaz de la Componente Java


Aplicación MiBoton

Figura No. 8: Diagrama de Paquetes

Diagrama de Componentes

El componente de la aplicación considera a los datos y las acciones asociadas a un objeto del
componente con el Mouse.

Titulo: texto que se despliega en el objeto Acción Ingresar al objeto


Color: Asocia un color al objeto Acción Salir del objeto
Margin x,y: Posición del objeto en la interfaz Acción Click
Vector: Acciones o eventos asociados al Acción Presionar
objeto
Mi
Interfaz Boton
Aunque los beans han sido pensados para ser utilizados
desde el entorno de desarrollo, también pueden ser
utilizados directamente.

La apariencia y comportamiento de un bean son Figura No. 9: Diagrama de los componentes de la


determinados por sus propiedades. Una propiedad aplicación
queda identificada por operaciones con la
siguiente forma: public <TipoProp> <NombreProp>() { ... } (Ver Figura ).

Este bean es utilizable como cualquier otra clase de Java. En principio no tiene ninguna
cualidad extraordinaria. Los valores de las propiedades pueden se modificados mediante las
operaciones set correspondientes
Figura No. 11: Código Java Componente y la aplicación

La forma habitual de distribución de un bean es en un fichero jar,


jar MiBoton.jar
.jar manifest.tmp
MiBoton.class y se puede instalar el bean en el netBeans (o cualquier otro entorno de desarrollo
Java):
5. Conclusiones

El Desarrollo de Software Basado en Componentes (DSBC) es importante a momento de crear


aplicaciones complejas y útiles para establecer componentes acorde a necesidades de un
entorno.
El DSBC esta evolucionando en el mundo del desarrollo de software, y los proveedores de
tecnologías que utilizan y proporcionan soporte al DSBC son pocas y no están difundidas en el
mercado.
Con base en todo lo expuesto surge la necesidad no sólo de encontrar un lenguaje común de
especificación referente al tema de DSBC entre desarrolladores y los usuario finales, sino también
la necesidad de buscar métodos que permitan el acercamiento y faciliten la utilización de los
Componentes de Software a cualquier tipo de usuario que desee integrarlos a los desarrollos de
software.

6. Agradecimientos

Al Instituto de Investigaciones en Informática y nuestra casa superior de estudios Universidad


Mayor de San Andrés (UMSA). Además a estudiantes que apoyan de manera activa a la
investigación, a Univ. William Ricardo Yujra Huanca y Univ. Roger Gonzales Aparicio.

7. Referencias

1. Szyperski Clemens, 1998: Component Software Beyond Object – Oriented Programming


2. Kuhn Thomas , 1962: Structure of Scientific Revolutions
3. IBM-WebSphere, 2001: Componente IBM
4. Brown, 1999 : Componente SEI
5. European Conference on Object Oriented Programming (ECOOP), 1996.
6. Fuentes Lidia, Troya José M., Vallecillo Antonio, 2003: Desarrollo de Software Basado en
Componentes.
7. Montevilva Jonás A., Arape Nelson, Colmenares Juan A. 2003: Desarrollo Basado en
Componentes.
8. Velasco Elizondo Perla, 2001: Prueba de Componentes de Software Basadas en el Modelo
de JavaBeans, pp. 6-15
9. Pressman Roger. 1997: Ingeniería de Software un enfoque practico, p 474-481.
10. Component Object Model, 2000: http://www.microsoft.com/com
11. CORBA, 2000: http://www.corba.org
12. Java Beans.1997: http:///java.sun.com
13. Vanhelsuwe , L.1998: Mastering Java Beans, Sybex, Inc.
14. Ferrke Peter y Loos Peter 2002: Specification of Business Components . Objects,Components,
Architectures, Services and Aplications for a Networked World
15. Richter Jeffrey, 2002: Microsoft .NET Framework Delivers the Platform for an Integrated,Service.
16. Espeso Martínez Pedro Javier, Diseño de Componentes de Software de Tiempo Real.
17. Fuentes Lidia, Troya Jose M., Vallecillo Antonio, Desarrollo de Software Basado en
Componentes
18. Casal Julio, Desarrollo de Software Basado en Componentes.
19. Garcia Perez Felipe, 2005: Desarrollo de componentes de software local y distribuido bajo la
plataforma COM – SOAP que encapsule las operaciones matriciales de MatLab.
20. Espeso Martinez Pedro Javier, 2002: Diseño de componentes software de tiempo real
TEORIA COMPUTACIONAL EN SISTEMA MULTI-AGENTE

RESUMEN
La teoría computacional en sistema multi-agente esta entendida a
expresar una formalización de fenómenos que envuelven a la
creencia, comunicación, acciones, mensajes, reglas, y a estas
propiedades se agregan conceptos abstractos de modelos, sistema,
módulos que contextualizan a los sistema multi- agente.

La notación formal expresa que los sistema multi-agente involucran Elizabeth L. Garcia Escalante
estructuras formales de agentes y modelos de ejecución. Docente – UMSA
egarcia@entelnet.bo

PALABRAS CLAVE: Sistema Multi-Agente. Agente. Modulo Agente. Modelo de Sistema Multi-
Agente. Modelo de Ejecución.

KEYWORDS: Multi-Agent System. Agent. Module Agent. Model of Multi-Agent System. Execution
Model.

1.- INTRODUCCIÓN

Un sistema multi-agente esta formado por múltiples elementos computacionales que


interactúan, conocidos como agentes. Los agentes son sistemas computacionales que
principalmente tienen dos capacidades importantes. La primera, es que tienen al menos alguna
capacidad de acción autónoma para decidir ellos mismos lo que requieren hacer para cumplir
objetivos. La segunda, es la capacidad de interactuar con otros agentes no simplemente para
intercambiar datos, sino que se tienen analogías de tipo social, actividades que los humanos
utilizan a diario, como: cooperación, coordinación, negociación, y otros más.
Gerhard Weiss (1999: 465) expresa que la noción de agentes permite un diseño de módulos que
equilibran dos aspectos, el nivel de especialidad que modela una descomposición funcional
detallada para diseñar agentes con funciones básicas especializados y el nivel de autonomía
que integra a un agente un conjunto significativo de funciones requeridas para la aplicación
entera pero limitada en el alcance. En efecto, la idea de agentes representa un alto nivel de
modularidad que es utilizado en las ciencias de la computación.
La organización del presente articulo, presenta el concepto formal de sistema multi-agente
donde se detalla las funciones de los módulos ambiente y agente. Así también se incluye el
enfoque de la teoría computacional donde se focaliza la comprensión de 3 consideraciones
como son la definición de la estructura del agente, estructura del sistema y finalmente tipos de
modelos de ejecución.
2.- SISTEMA MULTI-AGENTE

Wooldridge M. y sus colegas (2006: 2), expresan que, un sistema multi-agente está compuesto
de dos módulos2: (1) un módulo describe a los agentes por lo que se refiere a las acciones que
ellos ejecutan y (2) describe el ambiente que se puebla por estos agentes, y en particular los
efectos a realizar ciertas acciones.

 Un módulo de ambiente Env es un conjunto de Sistema de la Transición etiquetado (SLTS) es


una tupla S , Ac ,   A Ac , P ,  donde:
1. S es un conjunto de estados.
2. Ac es un conjunto finito de acciones.
3. Para cada A  Ac,  A es una relación sobre S.
4. P es un conjunto de variables proposicionales
5. π: (S x P)--> {1; 0} es una función de la interpretación que asigna cada estado y cada
variable de la proposición en un valor de verdad.

2 Razonando acerca de Acciones y Cooperación (Reasoning about Action and Cooperation). Disponible en
http://www.csc.liv.ac.uk/~mjw/.
Dado un conjunto de acciones atómicas Ac, el conjunto de expresiones de acción esta
definido por la gramática:  ::= a |    |  donde a  Ac. Para interpretar

esta acción, se define una relación entre los subconjuntos de Ac y la expresión de

acción. y es leído como ‘la acción concurrente A es de tipo  , ó ' es verdad


de A'.

Dado un conjunto de acciones Ac y un conjunto de las variables proposicionales P , el


lenguaje de la lógica del ambiente está dado como:  ::= p |    | [  ]  , donde p
 P,  es una expresión del lenguaje de acciones [Wooldridge et al, 2006: 3].

Sea Env = S , Ac ,   A Ac , P , es un SLTS, y s es un estado en S. Las sentencias del

lenguaje de la lógica de ambiente se definen inductivamente como sigue:

1. Env, s |= e p si y solo si  (s,p) = 1


2. Env, s |=  1   2 si y solo si Env, s |= e  1
e y Env, s |= e 2
3.- Env, s |= e   si y solo si Env, s |= e 
4. Env, s |= e [  ]  si y solo si para todo A  Ac y s’  S, si A |= p  y s  A s’
entonces Env, s’ |= e 

La lógica ambiente ( |= e ) tiene los siguientes axiomas [Wooldridge et al, 2006: 3]:

1. Todo axioma de la lógica proposicional


2. [  ] (    )  ([  ]   [  ]  ) para cada (distribución)
3. Todo axioma de la forma [  ]   [  ] , si |-    en lógica
proposicional
4. ( [ ]  [  ] )  [   ]  (aditividad)
5.  [ ]   si  es consistente en la lógica proposicional (serialidad)
6. [  ] 

La lógica del ambiente es valido y completo con respecto al modelo ambiental |- e  si y


solamente si Env |= e  para cada modelo de ambiente Env

Esta lógica dinámica servirá como el módulo de ambiente en un sistema multi-agente.


Ahora se procede a definir agentes que poblarán este ambiente mediante el modulo
agente [Wooldridge et al, 2006: 3].

 Dado un conjunto de agentes Ag y un conjunto de acciones Ac, un modulo de agente es


una tupla (Ag, Ac, Act), donde act es una función Ag  P(Ac) que asigna para cada
agente i un subconjunto act(i) de acciones desde Ac.

Sea la tupla (Ag, Ac, Act) del módulo de los agentes, sea G  Ag un conjunto de

agentes. La capacidad para las acciones del agente se define como: (Ag, Ac, Act) |=
G  si y solamente si este es un A  act(G) tal que para todo B  act (Ag \ G) toma
que A U B |= p 
La lógica de la coalición para las acciones está dada por los axiomas de la lógica
proposicional, y modus ponens. (Se denota la deribilidad como |- a) [Wooldridge et al, 2006:
4]
1. G  , para todo G  Ag

2. G    Ag \ G 
3. G   G  si |-    en la lógica proposicional

4. ( G1   G 2  )  G 1UG 2 (   ) para todo G1, G2  Ag tal que


G1  G2 = 0
5. G a  Vi G {i} a, para todo G  Ag y atómico a  Ac

6. ( G   G  )  G (    ) si  y  no son acciones
comunes atómicas
7. G a  G a atómico para a  Ac

8. G   V { G Λ |  es un conjunto de literales tal que Λ    }

La lógica de la coalición para las acciones es valida y completa con respecto al modelo
del agente.

Formalmente, un sistema del multi-agente es un ambiente junto con un módulo del agente que
comparte su repertorio de acción [Wooldridge et al, 2006: 6].

Un Sistema Multi-agente MaS es una tupla S , Ac , (  )A Ac , P ,  , Ag , act donde:

1. S , (  A' )A Ac , P ,  es un módulo ambiente

2. Ac , Ag , act es un módulo agente

Por lo tanto, la habilidad esta dada por: MaS, s |= m G  si y solo si es un conjunto de

acciones A  act (G, s) tal que para todo B  act( Ag \ G) y para todo estado t, si s  A B t,
entonces MaS, t |= m 

Dado un sistema multi-agente MaS y un estado s de su ambiente: MaS, s |= m G  si y

solamente si existe una expresión de acción  con MaS, s |= m G  y MaS, s |= m [  ] .


La lógica de cooperación con acciones esta dado por:

1.- los axiomas y reglas de la lógica de ambientes


2.- los axiomas y regla de la lógica de los agentes
3. ( G   [ ] )  G  para cada 
4. G   V{ G   [ ]  |  es una conjunción de  conjunto de acciones
literales donde están las acciones atómicas a o sus negaciones los literales de la acción del
 . La lógica de cooperación con acciones es valido y completo con respecto al
modelo de acción: |- m  si y solo si MaS |= m  para todo modelo MaS

3.- TEORÍA COMPUTACIONAL EN SISTEMA MULTI-AGENTE


Esta teoría contiene dos componentes: (1) es un modelo de sistema multi-agente, (2) es un
modelo de ejecución, cada una de las cuales define un camino de agentes donde actúan e
interactúan [Wooldridge M, 1992: 53].

El trabajo doctoral que presenta Wooldridge (1992: 54), expresa notaciones formales respecto a
la teoría computacional de sistema multi-agente, definiendo a la creencia como en un
lenguaje interno L, y asume un lenguaje lógico. Es decir, Belset = powerset Form(L); reglas de
deducción Drule. El símbolo  , (  0,  ’, …), denota un sistema de creencias, y el símbolo
 utilizado como el sistema de reglas de deducción.

Se modela la comunicación como el intercambio de mensajes que contiene una fórmula


definido por el lenguaje común de comunicación (lenguaje interno L). En la teoría básica, se
asume que los mensajes son enviados punto a punto. Se asigna a cada agente un identificador,
(id del agente). Es decir Agid = un conjunto arbitrario de agentes. La simbología i, j, k, l se utiliza
para identificar a los agente [Wooldridge, 1992: 57].

Un mensaje se define como una tripleta: enviador, receptor, y contenedor. El remitente y el


receptor representados por los id del agente y el contenedor es una formula del lenguaje de
comunicación L. Es decir: Mess = Agid x Agid x Form(L). El símbolo  (  ’,  1,…) denota
mensajes. Se asume la función sender, que toma el mensaje y retorna el id del
enviador; mientras la función recvr toma un mensaje y retorna el id del receptor. Es
decir,   Mess . (sender (  )  recvr(  ) ). La interpretación del mensaje es una
función que toma la creencia y el mensaje, y retorna una entrada epistémica. Es
decir: Messint = belset x Mess  Epin. Finalmente Mess nill asume un mensaje que no hace
nada [Wooldridge, 1992: 57].

El tipo de acción esta dado por: Action = Belset  Epin. El símbolo  denota acción. Para el
modelo del agente “no hacer nada”, una acción nill se asume. Una regla, es un par
condición/acción: una condición es una formula L, y la condición especial “true”. La condición
“true” siempre es satisfecha. Es decir: Cond = Form(L)  {true} [Wooldridge, 1992: 57].

Dos tipos de reglas se define: Arule = Cond x Action una regla de acción cognitiva o regla de
acción ar; Mrule = Cond x Mess regla de acción al mensaje o regla de mensaje mr. La
aplicabilidad de las reglas esta dado por la creencia ar_applic : Arule x Belset  
si la condición de creencia es verdadera (B), también definida como ar_applic(
 ,  )    (   { true }) .

El valor booleano sound : Arule  o también sound (  , )    Belset . ar_applic

(  ,  )  (   dom  ) define la regla acción valida, donde el agente posee un rango


de acciones posibles, representado por un conjunto de reglas de acciones AR y un conjunto de
reglas de mensaje MR. Una propiedad importante de una regla de agentes respecto a
acción/mensaje es la completitud, definida por el siguiente valor booleano: ar_wk_cmplt:
powerset Arule   , o también ar_wk_cmplt(AR)    Belset. ar  AR . ar_applic
(ar,  ).

La definición de una acción legal, esta dado por la siguiente función booleana:
ac_legal: Action x powerset Arule x Belset   , o también a_legal (  , AR,  ) 
  ,'  AR – (   ' )  ar_applic (  ,'  ), esta función asume el conjunto de
reglas de mensajes. Finalmente se encuentra la demanda de honestidad del conjunto de reglas
de mensajes, los cuales no permiten envíos de mensajes falsos, esta dado por la función
siguiente: honest: Agid x powerset Maule  , o también honest(i, MR)    ,  MR .
(sender (  ) = i ) [Wooldridge, 1992: 58].

3.1 Arquitectura de agentes

En este modelo también se encuentra a los agentes que tienen la estructura siguiente
0 ,  ,  , , MR , AR donde 0  Belset un conjunto inicial de creencias;  Drule es un
conjunto de reglas de deducción para el lenguaje L;  Brf la función que revisa la
creencia;  Messint la función de interpretación del mensaje; MR  Mrule es un conjunto de
reglas de mensajes tal que mr_wk_cmplt(MR); AR  Arule el conjunto de reglas de
acciones tal que ar_wk_cmplt (AR)  ar  AR . sound(ar). Una operación de un agente
muestra el algoritmo 1 [Wooldridge, 1992: 59].

1.- interpretar cualquier mensaje recibido


2.- Actualizar la creencia por el procesamiento de la entrada epistémico a partir de:
Acción previa
Interpretación del mensaje
Hasta que exista la función de revisión del mensaje
3.- Derivar en la deducción del conjunto de creencias
4.-Derivar el conjunto de posibles mensajes, escoger uno y enviarlo
5.-Derivar el conjunto de posibles acciones, seleccionar y uno y aplicar este
6.- Regresar al paso 1

Algoritmo 1. Operación de agentes


Fuente: [Wooldridge, 1992: 59].
3.2 Sistema

Un grupo de agentes se denomina un sistema. El tipo de sistemas llamado System, esta dado por
la siguiente estructura: Ag , 0 ,  ,  , , MR , AR donde Ag  Agid es un contador del

conjunto de identificación de agentes; 0 = Ag m  Belset le corresponde cada elemento


de Ag un conjunto inicial de creencias;  = Ag m  powerset Drule cada elemento de Ag
para un conjunto de reglas de deducción;  = Ag m  Brf le corresponde cada elemento
de Ag una función de revisión de creencias;  = Ag m  Messint cada elemento de Ag una
función de interpretación de mensajes; MR = Ag m  powerset Mrule corresponde cada
elemento de Ag un conjunto de reglas de mensajes, Ar = Ag m  powerset Arule le hace
corresponder cada elemento de Ag un conjunto de reglas de acción, tales que

  Ag . 0 ( i ),  ( i ),  ( i ), ( i ), MR( i ), AR( i )  Agent y i  Ag. Honest(i, MR(i)).


Esta define una función, la cual toma un identificador de agente y el sistema, donde extrae el id
del agente asociado a partir del sistema [Wooldridge, 1992: 59], es decir:

Agent : Agid x System  Agent


Agent (i, sys)  let . Ag , 0 ,  ,  , , MR , AR = sys in

0 ( i ),  ( i ),  ( i ), ( i ), MR( i ), AR( i )

3.3 Modelos de ejecución


Wooldridge (1992: 60) define dos modelos de ejecución para sistema multi-agente, el primero
asume acciones de agentes sincrónicas: enviar/recibir mensajes y actuar al mismo tiempo. El
segundo asume que al menos un agente actúa en cualquier momento. Ambos modelos de
ejecución consideran las nociones de estado del sistema, y cambia el estado inicial por la
transición. El estado esta denotado por el símbolo  . Un estado cambia, cuando uno o mas
agentes reciben mensajes y ejecutan acciones cognitivos. Una transición esta denotado por el
símbolo  . La historia de la ejecución de un sistema considera la secuencia estado - transición
- estado – transiciones…. , y así sucesivamente.

Los agentes son capaces de cambiar de estado por la ejecución de acciones de varios tipos.
Una tupla de acciones es denominada move. El movimiento de un agente no siempre
determina su próximo estado. El movimiento de cada agente en un sistema combina una
colección de movimientos, uno para cada agente, esto es llamado transición. La operación de
un sistema se describe como sigue: un sistema esta definido por un estado inicial (  0 ). Desde
este estado, cada agente pide un movimiento (legal), la cual combina con otros para formar
una transición,  1. Como resultado de esta transición, un nuevo estado se tiene  1 . Mientras
procesa los agentes seleccionan movimientos para transiciones y así sucesivamente,
denominada ejecución sincrónica, como se observa en la figura 1.

Tiempo 0 1 2 3 …………….
Agent 1 • → • → • → • → ………..
Agent 2 • → • → • → • → ………..
Agent 3 • → • → • → • → ………..
Agent 4 • → • → • → • → ………..
↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑

0  1 2  2 3  3 4  4 ………………

Figura 1. Ejecución sincrónica


Fuente: [Wooldridge, 1992: 60]3

Un modelo real es el denominado modelo de ejecución inter-etiquetado, que responde a un


modelo estándar de sistemas reactivos, donde al menos un agente esta actuando en cualquier
momento. La figura 2, ilustra una ejecución imaginaria de 4 agentes del sistema multi-agente,
donde • indica que el agente ejecuta un ciclo interno de los mensajes recibidos, actualiza su
creencia y actúa, mientras º indica que el agente aun no ha completado el ciclo. Durante las
primeras 4 ejecuciones del sistema, el agente 1 completa el ciclo de ejecución (tiempo 0,2,4,6)
el agente 2 completa (tiempo 1, 5), el agente 3 completa uno (tiempo 3) y el agente 4 aun no
ha completado [Wooldridge, 1992: 63].

Tiempo 0 1 2 3 …………….
Agent 1 • → º → • → º → ………..
Agent 2 º → • → º → º → ………..
Agent 3 º → º → º → • → ………..
Agent 4 º → º → º → º → ………..
↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑

0  1 2  2 3  3 4  4 ………………

Figura 2. Ejecución inter-etiquetado


Fuente: [Wooldridge, 1992: 63]

4.- CONCLUSIONES.

En el presente artículo se ha dado una breve descripción de la Teoría Computacional de


Sistema Multi-agente, donde se presenta elementos teóricos los cuales han sido base para el
trabajo de Tesis de la Maestría en Ciencias de la Computación del Postgrado en informática de
la UMSA. La introducción de la teoría computacional de sistema multi-agente, permite
considerar que cada agente y sistema multi-agente esta representada por una formalización
que no limita un razonamiento lógico respecto a habilidades de relacionar ejecuciones
cognitivas de creencias, acciones, mensajes y reglas que se tienen entre los agentes.

Otro aspecto relevante sobre la notación formal de la teoría computacional expresa a


Sistema Multi-Agente como sistemas complejos. El enfoque involucra la conceptualizacion
pensada para modelos de sistema multi-agente y modelos de ejecución. Esta surge como
producto de la evolución de la inteligencia artificial en el camino de dotar a los sistemas
computacionales de características complejas.

3
• indica que un agente completo un movimiento y cambio de estado, º indica un movimiento no
completado
Finalmente, la Teoría computacional de Sistema Multi-agente es una rama de las Ciencias de la
Computación con menos de veinte años de vida, y que recientemente goza de un auge
impresionante, dadas las características de autonomía e inteligencia otorgadas a estos entes
programáticos.

5.- REFERENCIAS

[Bigus, 2001] Bigus Joseph P., Bigus Jennifer. “Constructing Intelligent Agents Using Java”. Professional
Developer´s Guide Series. Second Edition.. Wiley Computer Publishing. Editorial John Wiley
& Son, Inc. 2001.
[Russell &Norvig, 1996] Russell Stuart and Norvig Peter. “Inteligencia Artificial: Un enfoque Moderno“.
Colección de Inteligencia Artificial de Prentice Hall. Hispanoamericana, S.A. Mexico. 1995.
[Weiss, 1999] Weiss Gerhard. “Multiagent Systems. A Modern Approach to Distributes Artificial Intelligence”.
The MIT Press. Cambridge, Massachusetts. London, England. 1999.
[Nilsson,2001] Nilsson J. Nils. “Inteligencia Artificial. Una nueva síntesis”. Editorial Mc Graw-Hill/Interamericana
de España, S.A.U. Madrid. 2001.
[Wooldridge, 2004] Wooldridge Michael. “An Introduction to MultiAgent Systems”. Department of Computer
Science, University of Liverpool, UK. Editorial John Wiley & Sons, Ltd. 2004.

[Iglesias, 1998] Iglesias, C.:”Definición de una metodología para el desarrollo de Sistemas Multi- Agente”. Tesis
doctoral. Departamento de ingeniería de Sistemas Telemáticos, Universidad Politécnica de
Madrid. 1998. Información disponible en
http://www.inf.udec.cl/revista/ediciones/edicion9/psalcedo.pdf [Ultima visita 10 febrero de
2007].
[Jennings et al, 1998 ]Jennings, N.R., Sycara, K. and Wooldridge, M. A Roadmap of Agent Research and
Development. In: “Autonomous Agents and Multi-Agent Systems Journal”, N.R. Jennings, K.
Sycara and M. Georgeff (Eds.), Kluwer Academic Publishers, Boston, 1998, Volume 1, Issue 1,
pages 7-38. Información disponible en www.acm.org/crossroads/xrds5-4/multiagent.html
.[ultima visita 1 de febrero de 2007].
[Ferguson & Wooldridge.1997] Ferguson Innes A. & Michael J. Wooldridge. “Paying Their Way: Comercial
digital Libraries for the 21st Century”. D-Lib Magazine. Disponible en
http://www.dlib.org/dlib/june87/zuno/06ferguson.html. 1997. [ultima visita 4 febrero 2008]

[Kinny et al, 1997] Kinny, D., Georgeff, M., and Rao, A.: “A Methodology and Modelling Technique for Systems
of BDI Agents”. Informe. 1997. información disponible en
http://eprints.agentlink.org/view/people/Kinny,_D..html [Última visita 20 enero 2008].
[Vicente et al,2000] Vicente J. Julian, Vicente J. Botti. “Estudio de Métodos de desarrollo de sistemas multi-
agentes”, Departamento de Sistemas Informáticos y computación. Universidad Politecnica
de Valencia. Información disponible en
http://tornado.dia.fi.upm.es/caepia/numeros/18/julian.pdf [Ultima visita: 10-enero-2008].
[Wooldridge et al, 1998] Wooldridge Michael, Jennings Nicholas R., Zambonelli Franco. “Developing
Multiagent Systems: The Gaia Methodology”. University of Liverpool. Información
disponible en http://www.csc.liv.ac.uk/˜mjw/pubs/imas [Ultima visita 14 de enero de
2008].
[Woordridge et al, 2000] Wooldridge Michael , MarcPhilippe Michael Fisher, Parsons Huget Simon. “ Model
Checking MultiAgent Systems with MABLE”. Department of Computer Science, University of
Liverpool . Información disponible en http://www.csc.liv.ac.uk/˜mjw/pubs/imas [ultima
visita 7 de enero de 2008].
[Woordridge et al, 2006] Wooldridge Michael, Wiebe van der Hoek, Gerbrandy Jelle y Luigi Sauro. “Reasoning
About Action and Cooperation”. Departament of computer Sciencie. University of
Liverpool, United Kingdom. Información disponible en http://www.csc.liv.ac.uk/~mjw/.
[Ultima visita 1 de mayo de 2008]

[Wooldridge, 2004] Pagina del Profesor Michael Wooldridge. Información disponible en


http://www.csc.liv.ac.uk/~mjw/. [Ultima visita 17-julio de 2008]
[Giret B. Adriana S., 2005] Giret B. Adriana S. Tesis Doctoral. “ANEMONA: Una Metodologia Multi-agente para
Sistemas Holonicos de Fabricacion”. Tesis presentada a la Universidad Politécnica de
Valencia. Junio 2005. Disponible en http://www.dsic.upv.es/-agerit/investigacion.htm.
[Ultima visita 22 abril 2006]
[Gómez, 2002] Gómez S. Jorge J. Tesis Doctoral. “Modelado de sistemas Multi-agentes”. Presentado al
Departamento de sistemas Informáticos y programación. Facultad de Informática.
Universidad Complutense de Madrid. Junio 2002. Disponible
http://www.fdi.ucm.es/profesor/jpavon/doctorado/practicas/index.html
[Wooldridge M, 1992] Wooldridge Michael. Tesis Doctoral. “The Logical Modelling Of Computacional Multi-
Agent Systems”. Tesis presentada a la Universidad de Manchester. Facultad de Tecnología
Departamento de Computación. Augusto 1992. Disponible en
http://www.csc.liv.ac.uk/˜mjw/pubs/imas. [Ultima visita 22 abril 2006]