ES2394826B2 - Método y sistema de coordinación de sistemas software basado en arquitecturas multiparadigma - Google Patents

Abstract

Método y sistema de coordinación de sistemas software basados en arquitecturas multiparadigma.#Emplea eventos con semántica alterable dinámicamente, en el que se emplea una entidad coordinadora (2) que coordina el funcionamiento entre una entidad destino (3) y una o más entidades origen (1), comunicando la entidad destino (3) la necesidad de recibir notificaciones de una o más entidades origen (1); y notificando la entidad coordinadora (2) a cada una de las entidades origen (1) que cuando en ella se produzca un evento se lo comuniquen, componiendo la entidad coordinadora (2) un nuevo evento combinación de los recibidos que propaga a la entidad destino (3). Cada entidad (1) y (3) solo requieren conocer la existencia de la entidad coordinadora (2) favoreciendo la coordinación y la incorporación de nuevas entidades.

Description

imagen1

BASADOS EN ARQUITECTURAS MULTIPARADIGMA

OBJETO DE LA INVENCIÓN

5

La presente invención, según se expresa en el enunciado de esta memoria descriptiva, se refiere a un método de coordinación para entidades en sistemas software basados en arquitecturas multiparadigma.

10 A lo largo de la invención se define entidad como cualquier dispositivo hardware, o software con capacidades de cómputo. Concretamente podrá ser una entidad: una aplicación software, un emisor/receptor de eventos

15 software/hardware o un sensor/actuador hardware.

El método hace uso de eventos con semántica alterable

dinámicamente, y tiene por objeto simplificar la

coordinación entre entidades de sistemas software,

20 facilitando la adición de nuevas entidades a coordinar en el sistema sin necesidad de que éstas sean diseñadas para que puedan intercambiar información en un instante de tiempo o deban sincronizarse, es decir, interrumpir su flujo de ejecución hasta que otra entidad haya alcanzado un

25 punto concreto en su propio flujo.

A lo largo de esta invención se definirá un evento como una notificación de información producida por una entidad como consecuencia de uno o varios cambios en su

30 estado, el evento tendrá asociada una semántica determinada en base a la información que notifica(ej. temperatura, ruido, humedad, etc.).

Definiremos un evento con semántica alterable 35 dinámicamente como un evento que tendrá una semántica cambiante durante el transcurso del funcionamiento de una

imagen2

entidad, como resultado de la modificación de la información asociada al propio evento.

Es otro objeto de la invención el asegurar un orden de

5 ejecución correcto, cuando dos o más entidades se ejecutan de manera concurrente y, por tanto, proporcionar un estado final del sistema que cumpla con los objetivos con los que las entidades fueron diseñadas originalmente. También es objeto de la invención el mejorar la eficiencia de la

10 coordinación entre entidades gracias a la eliminación de la necesidad de los sondeos de estado desde una entidad a otras mediante el uso de eventos con una semántica formal y alterable dinámicamente. Ello permite informar de los cambios de estados únicamente a aquellas entidades que

15 expresen previamente la necesidad de recibir la información de estado automáticamente cada vez que sea modificada.

La invención es aplicable a entidades en sistemas que presentan una arquitectura orientada a servicios, agente, 20 multiagente, dirigida por eventos, procesos de sistemas

operativos, o cualquier combinación de las anteriores.

ANTECEDENTES DE LA INVENCIÓN

25 El desarrollo de sistemas software distribuidos complejos plantea una gran dificultad en cuanto a la correcta coordinación entre las diferentes entidades que los conforman y que cooperan entre sí para alcanzar determinados objetivos, ya que los métodos de coordinación

30 propuestos hasta el momento son rígidos en cuanto a la necesidad de concretar qué entidades van a ser coordinadas. Por tanto, cuando se desea incorporar una nueva entidad al sistema, es necesario volver a desarrollar o modificar gran parte del resto de las entidades para que se cumplan los

35 requisitos de coordinación que se deseen en cada instante o caso particular. El documento titulado “Procedimiento para la coordinación de componentes de una red” (ES 2 193 604))

imagen3

trata el problema de la coordinación en entornos hardware. El documento “Sistema de coordinación de documentos y tareas para un ordenador” (ES 2 242 585) trata el problema de la coordinación en entornos software.

5 Además, los métodos de coordinación existentes implican el bloqueo en el flujo de ejecución de al menos una de las entidades del sistema, ya que la coordinación, hasta la fecha, se resuelve mediante una operación de sincronización.

10 Además la introducción de distintos tipos de entidades (servicios, agentes, emisores de eventos o receptores de eventos, procesos de sistemas operativos, etc.), en un sistema software distribuido agrega una mayor complejidad, ya que dificulta la aplicación de métodos de coordinación

15 bajo un único método común que proporcione la uniformidad y la adecuada integración que se necesita en nuestros sistemas para posibilitar que las diversas entidades cooperen entre sí. La falta de propuestas en este sentido lleva a utilizar y a aplicar soluciones ad-hoc para la

20 coordinación entre entidades, con el inconveniente que ello conlleva.

DESCRIPCIÓN DE LA INVENCIÓN

Para conseguir los objetivos y resolver los

25 inconvenientes anteriormente indicados, la invención proporciona un nuevo método para sistemas software basados en arquitecturas multiparadigma, basado en eventos con semántica alterable dinámicamente, definiendo “evento con semántica alterable dinámicamente” como un evento que

30 tendrá una semántica cambiante durante el transcurso del funcionamiento de una entidad, como resultado de la modificación de la información asociada al propio evento. El funcionamiento de una entidad coordinadora incluirá, entre otras cuestiones: 1) la adición de nuevas entidades a

35 coordinar en el sistema sin necesidad de que éstas sean diseñadas para que puedan intercambiar información, 2) el asegurar un orden de ejecución correcto, cuando dos o más

imagen4

entidades se ejecutan de manera concurrente instante de tiempo o deban sincronizarse, 3) la eliminación de los sondeos de estado. El método comprende las siguientes fases:

5 a) generar en una entidad destino, en un punto concreto de ejecución en el que se requiere realizar una coordinación con al menos una entidad origen asociada a un tipo concreto de evento, un evento de requerimiento indicativo de la necesidad de recibir notificaciones cada

10 vez que al menos una entidad origen genera el tipo de evento concreto al que está asociada. b) Recibir el evento de requerimiento en una entidad coordinadora, asociada a todo tipo de eventos, para recibir cualquiera de los eventos que se pueden producir en el

15 sistema. c) Procesar e inferir, en la entidad coordinadora, eventos relacionados con la información requerida en el evento de requerimiento recibido, a partir de reglas previamente establecidas que asocian semánticamente los

20 tipos de eventos entre sí. Entendiéndose por procesar a extraer información contenida en cada evento recibido, y entendiéndose por inferir a producir nuevos eventos resultantes de la combinación de los eventos que recibió desde las entidades origen.

25 d) A continuación, la entidad coordinadora notifica a cada una de las entidades origen del sistema los tipos de evento concretos que deben notificar a dicha entidad coordinadora.

e) Seguidamente, la entidad coordinadora recibe las 30 notificaciones de los eventos concretos producidos en las diferentes entidades origen.

f) Finalmente, la entidad coordinadora transmite, a la entidad destino, los eventos inferidos y las notificaciones recibidas de las entidades origen.

35 El método de la invención, además, comprende opcionalmente una fase en la que, si se modifica la

imagen5

estructura de un evento por parte de cualesquiera de las entidades en las fases d-f, se pasa a la fase c).

Además, opcionalmente, el método de la invención comprende una fase en la que cuando se define un nuevo 5 evento por parte de cualesquiera de las entidades en las

fases d-f, se pasa a la fase c).

También opcionalmente, el método comprende una fase en la que, si la entidad destino cambia de necesidades en las fases d-f, se pasa nuevamente a la fase c).

10 Cuando el evento de requerimiento indica la necesidad de recibir notificaciones coordinadas de más de una entidad origen, la notificación transmitida desde la entidad coordinadora a la entidad destino se constituye por un nuevo evento de notificación resultante de realizar una 15 composición de la información contenida en la notificación de cada entidad origen, de forma que la entidad coordinadora compone la información que contiene cada uno de los eventos para producir nuevos eventos de otros tipos distintos a las notificaciones generadas por las entidades 20 origen, resultantes de la combinación de los eventos que recibió. En el caso de que en esta tarea de composición se obtenga un evento de un tipo determinado al que alguna de las entidades del sistema (entidad destino) expresó su interés previo en recibirlo automáticamente, se realiza una 25 transmisión de estos eventos hacia estas últimas entidades. En base a la descripción realizada, se deduce fácilmente que una entidad destino puede quedar a la espera de un tipo de evento que sólo puede originarse debido a la composición de la información provista por una o más 30 entidades con las que se desea coordinarse. Gracias a ello se evita que el flujo de ejecución de una entidad avance hasta que otras entidades del sistema hayan llegado a un punto concreto en el flujo de ejecución de cada uno de ellos. En consecuencia, es posible la coordinación entre 35 entidades de un sistema, asegurándose un orden de ejecución correcto, cuando dos o más entidades se ejecutan de manera concurrente y, por tanto, proporcionando un estado final

imagen6

del sistema que cumpla con los objetivos con los que las entidades fueron diseñadas originalmente. Además, gracias a que la entidad coordinadora es la encargada de realizar la composición de información de eventos y de recibir y 5 transmitir los nuevos eventos generados, cada entidad origen y destino solo requieren conocer la existencia de esta única entidad coordinadora. Por tanto, las entidades origen y destino permanecen desacopladas entre sí, lo cual favorece la obtención de propiedades de calidad de un 10 sistema software, tales como mantenibilidad y reusabilidad. Por último, el uso de un modelo de eventos en el método de coordinación permite que las entidades origen y destino a coordinar puedan mantener la ejecución de parte de su flujo de ejecución en todo momento, incluso si se

15 encuentran a la espera de un evento determinado para realizar una operación concreta, ya que las entidades son notificadas cuando se recibe asíncronamente un evento.

En consecuencia, el método de la invención permite que la coordinación se lleve a cabo de manera asíncrona, aunque 20 obviamente también puede efectuarse de forma síncrona, y se evita que las entidades deban de tener un conocimiento explícito de la existencia de otras entidades, permitiéndose la posibilidad de agregar nuevas entidades a un sistema sin necesidad de rediseñar ni reiniciar el resto

25 de entidades a ejecutar o ya en ejecución en el sistema. Por último, cabe señalar que el método de coordinación de la invención es único para el sistema software y común para los distintos tipos de entidades, proporcionando la uniformidad e integración requerida en estos sistemas para

30 posibilitar que las diversas entidades cooperen entre sí. Ello evita la necesidad de utilización de métodos ad-hoc que convencionalmente se usan en la coordinación de entidades. Por otro lado, cabe señalar que la configuración

35 descrita permite que la invención sea aplicable en sistemas software basados en arquitecturas para sistemas software distribuidos en los que las entidades pueden ser

imagen7

conceptualmente distintas, permitiendo que la invención se aplique a entidades con una arquitectura orientada a servicios, agente, multiagente, dirigida por eventos, procesos de sistemas operativos, o una combinación

5 cualquiera de las anteriores.

En una realización añadida de la invención se prevé que el método comprende mecanismos para almacenar la información intercambiada entre las entidades en una base de conocimiento en las propias entidades, siempre que estas

10 entidades posean un sistema software que permita almacenar y recuperar información, propiedades acerca de esta información y las relaciones entre las diferentes clases de información, lo que contribuye a mejorar el proceso de análisis, verificación y mantenimiento de un sistema

15 software. Para ello se hace uso de una base de conocimiento donde se almacena meta-información acerca de la información intercambiada entre las entidades.

Adicionalmente, si el método de la invención es incorporado como parte de un sistema software que se 20 encargue de resolver las tareas de comunicación entre entidades, se pueden combinar métodos de comunicación y coordinación síncronos y asíncronos que contribuyan a cumplir con los requisitos de coordinación en cada instante y para cada sistema software concreto y que aporten una

25 mayor facilidad de desarrollo de sistemas software distribuidos. Finalmente, al realizarse la coordinación mediante una notificación de información de manera asíncrona, es posible continuar con parte del flujo de ejecución de las

30 entidades, no introduciendo, por tanto, tantos tiempos de parada en el flujo de ejecución como otros métodos ya existentes de coordinación, que implican la sincronización entre los flujos de ejecución. Además la invención se refiere a un sistema de

35 coordinación de sistemas software basado en arquitecturas multiparadigma de acuerdo con el método anteriormente descrito.

imagen8

Son independientes del objeto de la invención la implementación concreta de las entidades origen y destino a coordinar, de la entidad coordinadora y del sistema software distribuido concreto sobre el que se aplica el

método

descrito, así como los detalles accesorios que

puedan

presentarse, siempre y cuando no afecta a sus

características esenciales.

A continuación, para facilitar una mejor comprensión de esta memoria descriptiva y formando parte integrante de la misma, se acompañan una serie de figuras en las que con carácter ilustrativo y no limitativo se ha representado el objeto de la invención.

BREVE DESCRIPCIÓN DE LAS FIGURAS Figura 1.-Muestra una representación esquemática de

un sistema software basado en arquitecturas multiparadigma al que se aplica el método de coordinación de la invención.

Figura 2.-Muestra el sistema software de la figura anterior en el que las entidades origen están determinadas por un sensor de humedad y un sensor de ruido, en tanto que la entidad destino está determinada por un sensor de temperatura.

Figura 3.-Muestra una especificación temporal de la posible realización del método de la invención aplicado a un sistema software con arquitectura multiparadigma mostrado en la figura 2.

DESCRIPCIÓN DE LA FORMA DE REALIZACIÓN PREFERIDA

A continuación se realiza una descripción de la invención basada en las figuras anteriormente comentadas.

En el ejemplo de realización de la figura 1 se han representado "n" entidades origen 1, cada una de ellas asociada a un tipo concreto de evento T1-Tn respectivamente, de forma que mediante una entidad coordinadora 2 que está

imagen9

asociada a todo tipo de eventos, es decir está configurada de forma que pueda recibir cualquier tipo de evento, se coordina el funcionamiento de las entidades origen 1 con una entidad destino 3, de acuerdo con el método de la invención.

Previamente es necesario definir los eventos T1-Tn con una semántica formal, con un conjunto de información asociada a cada tipo de evento y dotados de una estructura que relacione unos tipos con otros.

Para conseguir la coordinación comentada, el método de la invención comprende una fase a) en la que la entidad destino 3 genera, en un punto concreto de ejecución en el que se requiere realizar una coordinación con al menos una de las entidades origen 1, un evento de requerimiento indicativo de la necesidad de recibir notificaciones cada vez que una o más de las entidades origen 1 generan el tipo de evento concreto al que está asociada.

A continuación sigue una fase b) en la que la entidad coordinadora 2 recibe el evento de requerimiento, siguiendo una fase c) en la que procesa e infiere eventos relacionados con la información requerida en dicho evento de requerimiento recibido, mediante un conjunto de reglas preestablecidas que asocian semánticamente los tipos de eventos entre sí. A continuación sigue una fase d) en la que la que la entidad coordinadora 2 notifica a cada una de las entidades origen 1 los tipos de eventos que deben notificar a la entidad coordinadora; siguiendo una fase e) en la que la entidad coordinadora 2 recibe las notificaciones de los eventos T1-Tn concretos producidos en las diferentes entidades origen 1, de forma que el procedimiento finaliza según una fase f) en la que la entidad coordinadora 2 realiza diversas composiciones de la información contenida en los eventos T1-Tn recibidos e inferidos, componiendo nuevos eventos Ti-Tj de forma que

imagen10

dicha entidad coordinadora 2 transmite los eventos inferidos y las notificaciones recibidas de las entidades origen 1 según los nuevos eventos Ti-Tj hacia la entidad destino 3. De esta forma, la entidad coordinadora 2 cuando se encuentre una composición con la que se obtenga un evento Ti-Tj, se notificará el nuevo evento a la entidad destino 3. Cuando ésta reciba la notificación de este evento, podrá continuar con la parte de su flujo de ejecución que requería del método de coordinación descrito, para posibilitar que las diversas entidades cooperen entre sí.

En la figura 2 se muestra una particularización de un ejemplo de realización de la figura anterior en el que las entidades origen 1 están constituidas por un sensor de humedad 1a y un sensor de ruido 1b, en tanto que la entidad de destino está constituida por un sensor de temperatura 3. En este ejemplo se requiere una coordinación en la que el sensor de temperatura 3 sólo podrá notificar una medición si previamente se han notificado mediciones por parte del sensor de humedad 1a y del sensor de ruido 1b.

Según la fase a) del método de coordinación señalada, dado que hay más de una unidad origen 1, se deberá expresar desde el sensor de temperatura 3, mediante un evento de requerimiento, que se desea la recepción automática de aquellos eventos cuya información asociada sea el resultado de la composición de la información extraída de los eventos notificados por los sensores de humedad 1a y de ruido 1b. Tras recibirse el evento de requerimiento en la entidad coordinadora 2, y tal y como se describe en la fase c), la entidad coordinadora 2 procesa e infiere que los eventos requeridos para la combinación son aquellos que son notificados por el sensor de humedad 1a y el sensor de ruido 1b. Asimismo, como se explicita en la fase d) se

imagen11

notificará a los sensores de humedad 1a y de ruido 1b para que se aplique el método de coordinación mediante el inicio de la notificación de eventos generados por dichos sensores.

5 Tras la notificación de eventos realizada por los sensores de humedad 1a y ruido 1b, la entidad coordinadora 2 compone la información asociada a cada evento, resultando en la construcción de un nuevo evento asociado semánticamente tanto con "humedad" como con "ruido", el

10 cual será notificado en consecuencia, tal y como fue descrito en la fase d) del método. Al haber expresado previamente desde el sensor de temperatura 3 la necesidad de recibir automáticamente el nuevo evento generado, este sensor recibirá automáticamente el nuevo evento resultante

15 de la composición. Como consecuencia de la recepción de la notificación de uno de esos eventos, se realiza una notificación de un evento por parte del sensor de temperatura 3 incluyendo información acerca del valor cuantificado de ésta. De esta forma, cada vez que se reciba

20 un nuevo evento asociado semánticamente tanto con "humedad" como con "ruido", el sensor de temperatura 3 realiza la notificación pertinente y, en consecuencia, se cumple con la coordinación requerida para el sistema, ésto es: el sensor de temperatura 3 solo podrá notificar una medición

25 si previamente se han notificado mediciones por parte del sensor de humedad 1a y del sensor de ruido 1b. Por último, cabe señalar que se deberá volver a la fase c) cuando en alguna de las fases d) a f) se dan las siguientes circunstancias: cambia la estructura interna de

30 alguno de los eventos, se definen nuevos eventos como consecuencia, por ejemplo, de la incorporación de nuevas entidades al sistema, y/o cambian las necesidades de la entidad destino 3, por ejemplo, si la regla de coordinación

imagen12

impuesta sólo tiene vigencia durante un tiempo limitado o tras un número predeterminado de eventos recibidos.

Las entidades origen 1 y destino 3 pueden ser diseñadas tal y como se requiera: agentes, servicios, multiagentes, por eventos, procesos de sistemas operativos, etc. La entidad coordinadora 2 también puede ser considerada un servicio, un agente o un emisor/consumidor de eventos. La entidad coordinadora 2 debe poseer, al menos, una interface pública que permita la comunicación con el resto de entidades 1 y 3 para permitir la asociación entre una entidad 1 y 3 y un tipo de evento, la notificación de un evento a una entidad destino 3 interesada y, por último, el envío de un evento desde una entidad origen 1 cualquiera hacia la entidad coordinadora

2.

La entidad coordinadora 2 debe poder acceder a una base de conocimiento 4 donde pueda comprobar el tipo de cada uno de los eventos recibidos, para que la composición de información resulte eficiente en el tiempo, es necesario también consultar esta base de conocimiento 4 y sólo realizar las composiciones que estén recogidas en ella.

La base de conocimiento 4 puede ser cualquier tipo de sistema software que permita almacenar y recuperar información, propiedades acerca de esta información (metainformación) y las relaciones entre diferentes clases de información. Por ejemplo, una base de conocimiento podrá ser una base de datos relacional, una ontología y sus instancias, etc.

El método de coordinación puede ser integrado en un sistema software encargado de resolver los distintos mecanismos de comunicación entre entidades de un sistema software distribuido.

Además la invención también se refiere a un sistema que comprende los medios necesarios para llevar a cabo el

imagen13

método descrito, presentando las ventajas que fueron indicadas en el apartado descripción de la invención.

En la figura 3 se muestra una posible realización del

5 método de la invención aplicado a un sistema software con arquitectura multiparadigma. Dicha figura es una especificación temporal del ejemplo dado en la figura 2. Las líneas discontinuas son las líneas de tiempo (éste transcurre de arriba hacia abajo de la figura) de cada tipo

10 de entidad (coordinadora, origen y destino). Los rectángulos blancos indican los momentos en que dichas entidades software deben ejecutar parte del método de la invención. Las flechas indican las comunicaciones entre unas entidades y otras. Sobre las flechas se ha incorporado

15 texto para mejorar la comprensión de la forma de realización propuesta del método de la invención. Se puede observar como en la realización propuesta, la activación de las entidades origen 1 (E1a y E1b en la figura 3) y destino 3 (E3 en la figura 3) se realiza de manera esporádica, lo

20 que ayuda a mejorar la eficiencia (energética, uso de recursos, etc.) de dichas entidades. Asimismo, se observa como las entidades origen 1 y destino 3 no se comunican directamente, por lo que dichas entidades permanecen desacopladas entre sí durante todo el proceso de

25 coordinación, lo cual favorece la obtención de propiedades de calidad de un sistema software, tales como mantenibilidad y reusabilidad.

Claims (8)

1. imagen1

   REIVINDICACIONES

   1.-MÉTODO DE COORDINACIÓN DE SISTEMAS SOFTWARE BASADO EN ARQUITECTURAS MULTIPARADIGMA que emplea eventos con 5 semántica alterable dinámicamente en la coordinación entre

   entidades de un sistema software; caracterizado por que comprende las siguientes fases:

   a) Generar en una entidad destino (3), en un punto concreto de ejecución en el que se requiere realizar una 10 coordinación con al menos una entidad origen (1) asociada a un tipo concreto de evento, un evento de requerimiento indicativo de la necesidad de recibir notificaciones cada vez que al menos la entidad origen (1) genera el tipo de

   evento concreto al que está asociada la entidad destino. 15 b) Recibir el evento de requerimiento en una entidad coordinadora (2), asociada a todo tipo de eventos.

   c) Procesar e inferir, en la entidad coordinadora (2), eventos relacionados con la información requerida en el evento de requerimiento recibido, a partir de reglas 20 previamente establecidas que asocian semánticamente los

   tipos de eventos entre sí.

   d) Notificar, por parte de la entidad coordinadora (2), a cada una de las entidades origen (1) del sistema los tipos de eventos concretos que deben de notificar a dicha

   25 entidad coordinadora (2). e) Recibir en la entidad coordinadora (2) las notificaciones de los eventos concretos producidos en las diferentes entidades origen (1). f) Propagar desde la entidad coordinadora (2) a la 30 entidad destino (3), los eventos inferidos y las notificaciones recibidas de las entidades origen (1).

   Y en el que cuando el elemento de requerimiento indica la necesidad de recibir notificaciones coordinadas de más de una entidad origen (1), la notificación propagada desde 35 la entidad coordinadora (2) a la entidad destino (3) se

   imagen2

   genera un nuevo evento de notificación resultante de realizar una composición de la información contenida en la notificación de cada entidad origen.
2. 2.- MÉTODO DE COORDINACIÓN DE SISTEMAS SOFTWARE BASADO EN ARQUITECTURAS MULTIPARADIGMA, según reivindicación 1, caracterizado por que comprende una fase en la que cuando se modifica la estructura de un nuevo evento en las fases d-f, se pasa a la fase c).
3. 3.-MÉTODO DE COORDINACIÓN DE SISTEMAS SOFTWARE BASADO EN ARQUITECTURAS MULTIPARADIGMA, según reivindicación 1, caracterizado por que comprende una fase en la que cuando se define un nuevo evento en las fases d-f, se pasa a la fase c).
4. 4.- MÉTODO DE COORDINACIÓN DE SISTEMAS SOFTWARE BASADO EN ARQUITECTURAS MULTIPARADIGMA, según reivindicación 1, caracterizado por que comprende una fase en la que cuando la entidad destino (3) cambia de necesidades en las fases d-f, se pasa a la fase c).
5. 5.- MÉTODO DE COORDINACIÓN DE SISTEMAS SOFTWARE BASADO EN ARQUITECTURAS MULTIPARADIGMA, según reivindicación 1, caracterizado por que la generación de un evento de requerimiento de la entidad destino se realiza de una forma seleccionada entre síncrona y asíncrona.
6. 6.- MÉTODO DE COORDINACIÓN DE SISTEMAS SOFTWARE BASADO EN ARQUITECTURAS MULTIPARADIGMA, según reivindicación 1, caracterizado por que comprende almacenar la información

   intercambiada entre las diferentes entidades (1, 2 y 3).
7. 7.- MÉTODO DE COORDINACIÓN DE SISTEMAS SOFTWARE BASADO EN ARQUITECTURAS MULTIPARADIGMA, según reivindicación 1, caracterizado por que las diferentes entidades (1, 2 y 3) presentan una arquitectura seleccionada entre una arquitectura orientada a servicios, agentes, multiagentes, dirigida por eventos, procesos de sistemas operativos o una combinación de cualquiera de las anteriores.

   imagen3
8. 8.-SISTEMA DE COORDINACIÓN DE SISTEMAS SOFTWARE

   BASADOS EN ARQUITECTURAS MULTIPARADIGMA, caracterizado por

   que está configurado de manera tal que implementa el método

   de las reivindicaciones 1 a 7.