ES2215911T3

ES2215911T3 - Sistema informatico modular y procedimiento asociado.

Info

Publication number: ES2215911T3
Application number: ES01945434T
Authority: ES
Inventors: Emmanuel Marty
Original assignee: NEXWAVE SOLUTIONS
Current assignee: NEXWAVE SOLUTIONS
Priority date: 2000-06-16
Filing date: 2001-06-14
Publication date: 2004-10-16
Anticipated expiration: 2021-06-14
Also published as: CN1936835A; ATE263986T1; WO2001097026A1; JP2004503866A; CN1446336A; US20040031018A1; DE60102694D1; KR20030044916A; DE60102694T2; EP1290554B1; EP1429245A2; EP1429245A3; FR2810423A1; EP1450253A2; EP1290554A1; TW521210B; CN1936836A; AU2001267657A1; CN1273893C

Abstract

Procedimiento de desarrollo de proyectos informáticos (P1, P2) destinados a ser utilizados por un sistema informático, procedimiento que comprende una fase de análisis funcional (601) con el fin de censar de nuevo las funcionalidades que deben ser aseguradas, una fase de creación de componentes (C1, C2) del proyecto con la ayuda de medios informáticos para cumplir dichas funcionalidades, una fase de declaración sobre este mismo sistema de los componentes creados cuando tiene lugar la fase de creación, y una fase de carga de dichos componentes en una zona de memoria del sistema para su utilización por el sistema, caracterizado porque: cuando tiene lugar la fase de creación de componentes, cada funcionalidad es completamente cumplida por el componente que le está asociado, cuando tiene lugar la fase de declaración de los componentes, cada componente creado es declarado acerca de un componente de carga del sistema, y cuando tiene lugar la fase de carga de los componentes, están previstos unosmedios (GD) para, en asociación con cada funcionalidad requerida por un componente cargado, buscar automáticamente un componente que ofrezca dicha funcionalidad.

Description

Sistema informático modular y procedimiento asociado.

Introducción

La presente invención se refiere de manera general a los sistemas lógicos que permiten a unos usuarios interactuar con unos materiales informáticos.

Más precisamente, la invención se aplica a un sistema lógico que comprende un sistema de explotación que ofrece unas cualidades de flexibilidad y de rapidez de ejecución que no son previsibles incluso con los sistemas de explotación actuales más rendibles.

La invención se refiere a un procedimiento asociado a dicho sistema.

Y como se verá, la invención se aplica de forma ventajosa (pero no limitativa) al desarrollo de aplicaciones asociadas a unos sistemas informáticos embarcados.

Se recuerda que el sistema de explotación es un elemento esencial de cualquier sistema lógico, del que constituye la parte que interactúa directamente con el constituyente material de un sistema informático.

Se conocen ya numerosos sistemas de explotación, que permiten algunos equipos de desarrollo crear unas aplicaciones, y a unos usuarios finales utilizar estas aplicaciones.

Los sistemas de explotación existentes se reparten esquemáticamente en dos familias principales.

\ding{226} Las arquitecturas monolíticas

La primera familia está constituida por los sistemas de explotación con arquitectura monolítica. Dichos sistemas constituyen un conjunto lógico único, que comprende tres capas principales:

\bullet: una capa llamada baja que corresponde al núcleo del sistema. El núcleo puede ser definido como un conjunto de código pasivo y privilegiado, cargado de forma permanente en la memoria del sistema y susceptible de ser utilizado por todos los procesos aplicativos.

Su misión esencial es regular la utilización de los recursos compartidos del sistema (memoria, procesador, periférico). Para cumplir esta misión, el núcleo asegura ciertas funcionalidades importantes entre las cuales:

\ding{51}: la gestión de la memoria (distribución de los recursos de memoria entre las aplicaciones en función de sus peticiones ...),

\ding{51}: la gestión de los procesos (ordenación, gestión de los accesos al procesador, gestión multitareas...),

\ding{51}: la gestión de los drivers de periférico,

\ding{51}: la gestión de los ficheros (nombre, dirección, ...),

\ding{51}: la gestión de los usuarios (acceso, perfiles, ...).

\bullet: una capa llamada alta dedicada a las aplicaciones, y con la cual los usuarios pueden interactuar para entrar en el sistema de las instrucciones y de las peticiones con destino al núcleo,

\bullet: un nivel intermedio llamado de "bibliotecas", que es a veces considerado como una capa y en el cual están reunidas las funcionalidades recurrentes de manera que permitan su utilización rápida.

Una arquitectura monolítica de este tipo está representada esquemáticamente en la figura 1 anexa al presente texto, que muestra la disposición centralizada y jerarquizada de las capas K (núcleo), L (biblioteca) y A (aplicaciones).

La definición de "capas" permite jerarquizar las comunicaciones entre los elementos del sistema de explotación, siendo las capas más bajas definidas como unas capas "privilegiadas" que pueden ser llamadas por unas capas de nivel superior.

Las capas son así unas clases de elementos lógicos que comparten los mismos privilegios. Se puede definir un privilegio como la facultad de utilizar ciertos recursos del sistema informático (recurso material, o recurso lógico).

Como se ha dicho, un sistema construido según dicha arquitectura monolítica constituye un conjunto lógico único, compilable en "bloque".

Una ventaja de esta configuración es que los sistemas son generalmente estables y rápidos.

Pero dichos sistemas de explotación presentan limitaciones importantes en términos de flexibilidad y de evolución del sistema.

En efecto, una modificación en el núcleo implica sistemáticamente una recopilación completa de éste. Para cada modificación, es preciso así hacer de nuevo una carga total del sistema.

Y esta rigidez del sistema es penalizante puesto que las evoluciones del sistema se hacen pesadas y complejas, y su mantenimiento costoso. Por otra parte, el sistema puede resultar inestable debido a "adiciones" sucesivas.

Además, en el caso de los sistemas informáticos embarcados (es decir de los que una parte por lo menos está destinada a estar integrada en un material móvil tal como un vehículo, un teléfono portátil, ...), esta rigidez puede resultar extremadamente penalizante, puesto que obliga también a fijar a priori un cierto número de características del sistema informático (como el hecho de privilegiar la velocidad de ejecución, o también el tamaño de la memoria...).

Ahora bien, la diversidad de las aplicaciones embarcadas enfrenta a menudo los programadores a unas exigencias variadas de los sistemas informáticos asociados, y sería ventajoso poder libremente definir y hacer evolucionar las características principales del sistema.

Así, en razón de los inconvenientes citados más arriba y que resultan principalmente de la rigidez de los sistemas de explotación monolíticos, esta arquitectura monolítica está esencialmente destinada a unas aplicaciones que no necesitan evolución lógica o material importante, y la misma está mal adaptada a los sistemas embarcados.

\ding{226} Las arquitecturas micronúcleo

Para intentar evitar esta limitación, se ha imaginado una segunda familia de arquitectura para los sistemas de explotación. Estos son los sistemas del tipo micronúcleo, tales como las presentadas en la figura 2.

Esta figura muestra que los sistemas micronúcleo son, en este caso unos sistemas monolíticos, constituidos por unas capas concéntricas que rodean un núcleo central que constituye el "corazón" del sistema de explotación.

El elemento de núcleo MK está aquí reducido a un "micronúcleo" que solo cumple las funcionalidades esenciales necesarias para el funcionamiento del sistema, a saber:

\bullet: la gestión de la memoria,

\bullet: la gestión de los procesos, por lo menos en lo que concierne a los procesos llamados de bajo nivel - se trata de la conmutación de las tareas. Se precisa que algunos sistemas micronúcleo rigen los procesos de alto nivel con la ayuda de un servidor, mientras que otros los rigen por medio del micronúcleo mismo,

\bullet: la gestión de los puertos (buzones), y el paso de mensajes,

\bullet: el arbitraje de la asignación de los recursos materiales, entre los diferentes drivers (siendo definido un driver como un piloto, es decir un programa que controla el funcionamiento de una tarjeta o de cualquier periférico).

Las otras funcionalidades tradicionalmente realizadas por los núcleos de los sistemas monolíticos son realizadas por unos servidores S. Estos servidores forman una capa intermedia entre la capa superior de las aplicaciones A y la capa L de las bibliotecas que rodean directamente el micronúcleo MK. Son prioritarios con respecto a las aplicaciones A.

Dicha arquitectura micronúcleo permite hacer evolucionar el sistema de explotación sin necesitar la recopilación del conjunto del sistema; esta segunda familia de sistemas de explotación permite así una cierta flexibilidad con respecto a los sistemas monolíticos.

Pero las arquitecturas de esta familia quedan construidas en capas sucesivas alrededor de un núcleo central, y todos los intercambios de comunicación internos al sistema de explotación deben necesariamente pasar por el micronúcleo.

Ahora bien, el paso de las comunicaciones por las capas sucesivas del sistema, más numerosas que en el caso de los sistemas monolíticos, induce unos tratamientos suplementarios y ralentiza el funcionamiento general del sistema.

Es por consiguiente necesario optimizar estos intercambios de comunicación para cualquier desarrollo nuevo del sistema, lo que hace más complejo el trabajo de los programadores.

Resulta pues que los sistemas micronúcleo, si bien aportan una flexibilidad suplementaria con respecto a los sistemas monolíticos, están asociados a unos tratamientos más largos y sólo representa una solución imperfecta.

\ding{226} Comentario suplementario sobre las arquitecturas existentes

Por otra parte, los sistemas actuales (monolíticos y micronúcleo) están todos centrados sobre un elemento de núcleo alrededor del cual unas capas sucesivas están jerarquizadas en función de privilegios de acceso predeterminados.

En todos estos sistemas, en efecto, cada programa está sistemáticamente asociado a una capa dada según una tipología inmutable inherente al propio sistema, de manera que este programa será sistemáticamente provisto de un nivel de privilegios cuyo control escapa a los programadores, lo que constituye un primer inconveniente en común a los sistemas existentes.

Así, los programas pueden ser por ejemplo:

\bullet: un código "núcleo" o "supervisor" o "sistema" (el código privilegiado que rige la interacción con el material),

\bullet: un elemento de "biblioteca" de funcionalidades pasivas (matemáticas, descompresión vídeo, etc.),

\bullet: un código aplicativo.

Estos diferentes tipos de código corresponden a menudo a unos formatos de fichero diferentes, y son regidos de manera diferente por unos elementos diferentes del sistema de exportación.

No es entonces posible visualizar con una sola herramienta, el conjunto de los programas instalados en el sistema; así mismo no es generalmente posible reemplazar, durante el funcionamiento del sistema, las partes "núcleo", que forman un bloque opaco e indivisible.

Resulta de ello que es preciso utilizar unas herramientas diferentes para crear y limpiar de errores (bugs) estos diferentes tipos de códigos, lo que hace más complejas en todos los casos las operaciones de desarrollo; esto constituye un segundo inconveniente común a los sistemas existentes.

Y se comprende que el núcleo de los sistemas existentes constituye el centro absoluto del sistema. Este núcleo tiene un estatuto especial por su nivel de privilegios; constituye la parte menos portátil del sistema y no puede ser modificado de forma simple.

Por otra parte, otra característica común a los sistemas lógicos existentes es que su concepción se ha efectuado con:

\bullet: una fase de análisis funcional que ha permitido describir el sistema en términos de funcionalidades a cumplir, lo que constituye un nivel descriptivo muy intuitivo e inmediatamente inteligible,

\bullet: seguida de una escritura y de una compilación de programas cuando tiene lugar la cual este nivel de inteligibilidad y de legibilidad es alterado, constituyendo los programas unos conjuntos opacos cuyo funcionamiento está predeterminado.

Los programas de estos sistemas funcionan bajo demanda como unos "autómatas", y el núcleo sólo trabaja en reacción en función de las necesidades expresadas por las aplicaciones.

Resulta así que el núcleo, si bien adapta los recursos y puede utilizar unas funciones de optimización para mejorar el funcionamiento general del sistema, trabaja siempre en reacción corriente abajo con respecto a las necesidades expresadas por las aplicaciones. Esto constituye otra limitación esencial de los sistemas existentes.

Como se verá, en el caso de la invención por el contrario, el funcionamiento de todos los componentes del sistema está integrado y los enlaces funcionales establecidos cuando tiene lugar la fase de análisis funcional son preservados en la arquitectura del sistema.

Así, con respecto a un sistema conocido tal como el representado por el lenguaje Java (marca registrada) del que se encontrará una descripción en el documento "Introduction to programming using Java". "Versión 3,0 verano 2000" de D.J. ECK - Department of mathematics and computer science. Hobart and William Smith College, Geneva, New-York, US 24/05/2000,accesible el 7 marzo 2001 en la dirección Internet http://math.hws.edu/eck/cs24/downloads/
Javanotes3.pdf> , y sería ventajoso ofrecer un grado de flexibilidad suplementario en el establecimiento de las relaciones entre las entidades.

Por "entidad", se entiende en el caso de los lenguajes conocidos (Java por ejemplo) los objetos y clases que pueden ser utilizados.

En el caso del lenguaje Java, en efecto, si una entidad dada puede efectivamente llamar otras entidades que son necesarias para su funcionamiento, el programador debe necesariamente especificar de forma explícita cuales son las entidades que deben ser cargadas en la memoria viva del sistema para permitir el buen funcionamiento de dicha entidad llamadora dada.

Resulta así que este tipo de lenguaje conocido, si bien ofrece efectivamente una cierta flexibilidad ligada a una arquitectura objeto, impone así mismo elegir desde la concepción unas entidades específicas, lo que limita en gran manera la flexibilidad del sistema.

Además, dicho sistema conocido no devuelve mensaje de errores cuando tienen lugar operaciones de carga, de manera que es posible que una entidad defectuosa o incapaz de cumplir su función sea cargada en el sistema. Y la deficiencia de dicha entidad sólo será constatada cuando tiene lugar el funcionamiento general del sistema, o cuando tienen lugar operaciones de prueba que serán entonces necesario prever específicamente.

El documento "CORBA: a Platform for distributed Object Computing" de YANG Z et al., describe una plataforma para efectuar unas comunicaciones transparentes entre unos objetos de aplicación.

\ding{226} Objetos de la invención

El objeto principal de la invención es proponer un sistema de explotación que ofrezca unas cualidades de flexibilidad y de rapidez de ejecución que no son previsibles incluso con los sistemas de explotación actuales más rendibles.

Otro objeto de la invención es proponer un sistema lógico que permita además liberarse de los inconvenientes mencionados anteriormente a propósito del conjunto de los sistemas existentes.

Y otro objeto aún de la invención es proporcionar una solución lógica adaptada a las obligaciones inherentes a la concepción de los sistemas embarcados.

A fin de alcanzar estos objetos, la invención propone un procedimiento de desarrollo de proyectos informáticos destinados a ser utilizados por un sistema informático, procedimiento que comprende una fase de análisis funcional en vista a censar de nuevo las funcionalidades que deben estar aseguradas, una fase de creación de componentes del proyecto con la ayuda de medios informáticos para cumplir dichas funcionalidades, una fase de declaración sobre este mismo sistema de los componentes creados cuando tiene lugar la fase de creación, y una fase de carga de dichos componentes en una zona de memoria del sistema para su utilización por el sistema, caracterizado porque:

\bullet: cuando tiene lugar la fase de creación de componentes, cada funcionalidad es completamente cumplida por el componente que le esta asociado,

\bullet: cuando tiene lugar la fase de declaración de los componentes, cada componente creado es declarado acerca de un componente de carga del sistema, y

\bullet: cuando tiene lugar la fase de carga de los componentes, están previstos unos medios para, en asociación con cada funcionalidad requerida por un componente cargado, buscar automáticamente un componente que ofrezca dicha funcionalidad.

Unos aspectos preferidos, pero no limitativos del procedimiento según la función son los siguientes:

\bullet: dicha búsqueda automática se efectúa teniendo en cuenta una condición,

\bullet: dicha condición está expresada en función de criterios expresados en función de las propiedades asociadas individualmente a cada componente,

\bullet: cuando tiene lugar la creación de un componente se procede a las etapas siguientes:

\ding{51}: creación de un fichero fuente de intercara del componente, en vista a constituir una parte "intercara" del componente,

\ding{51}: creación de por lo menos un fichero fuente de código que permita realizar la funcionalidad del componente, con el fin de constituir una parte "implementación" del componente.

\bullet: cada fichero fuente de código creado en vista a constituir una parte "implementación" del componente puede ser elaborada en un lenguaje de programación cualquiera,

\bullet: cada componente puede cumplir la funcionalidad que le está asociada utilizando unos medios lógicos, y/o materiales,

\bullet: el fichero de intercara de cada componente comprende una descripción de la funcionalidad cumplida por dicho componente, independiente de la manera en la que esta funcionalidad es cumplida por el componente,

\bullet: el fichero de intercara comprende también una descripción de las funcionalidades que el componente tiene necesidad de importar de otros componentes a fin de cumplir su propia funcionalidad,

\newpage

\bullet: cada componente puede ser reemplazado dinámicamente por otro componente que exporta la misma funcionalidad,

\bullet: dicho reemplazado utiliza las etapas siguientes:

\ding{51}: salvaguarda del estado corriente del componente a reemplazar,

\ding{51}: carga e inicialización del nuevo componente,

\ding{51}: transmisión del estado corriente del componente a reemplazar al nuevo componente,

\ding{51}: establecimiento de un canal de comunicación entre el componente que llama la funcionalidad y el nuevo componente,

\ding{51}: descarga del componente a reemplazar.

\bullet: Si la carga o la inicialización del nuevo componente no se ha efectuado correctamente, están previstos unos medios para devolver un mensaje de error,

\bullet: cuando tiene lugar la creación de un componente se procede también a las etapas siguientes:

\ding{226}: creación de un Makefile en el cual están especificados:

\ding{51}: el (los) lenguaje(s) utilizado(s) para el (los) fichero(s) fuente creado(s) cuando tiene lugar la etapa de creación de fichero(s) fuente de código,

\ding{51}: el (los) fichero(s) fuente de código correspondiente a la parte "implementación" del componente,

\ding{226}: creación de un prototipo del componente,

\ding{226}: edición de enlaces entre la parte "intercara" y la parte "implementación" del componente, para generar un prototipo de componente ejecutable,

\ding{226}: utilización del makefile para compilar el componente individualmente, y constituir un fichero objeto respectivo para el fichero fuente de intercara de la parte "intercara" del componente así como para el o cada fichero fuente de código de la parte "implementación" del componente,

\ding{226}: encapsulado de los ficheros objeto creados cuando tiene lugar la etapa anterior en un módulo ejecutable único,

\bullet: cuando tiene lugar la creación del prototipo de un componente se crea un prototipo que comprende:

\ding{226}: una intercara objeto que resulta de la compilación del fichero fuente de intercara del componente,

\ding{226}: un fichero objeto prototipo para cada fichero fuente de código de la parte "implementación" del componente,

\bullet: cuando tiene lugar la compilación del fichero fuente de intercara del componente, se procede a:

\ding{226}: el análisis y la verificación de la coherencia del fichero fuente de la intercara,

\ding{226}: la traducción del fichero fuente de la intercara en datos binarios,

\ding{226}: la generación automática de por lo menos un fichero para llamar las funcionalidades que deben ser importadas por el componente,

\bullet: después de la etapa de edición de enlaces entre la parte "intercara" y la parte "implementación" del componente para generar un prototipo de componente ejecutable, se procede a una etapa de prueba de integridad automática cuando tiene lugar la cual se verifica que el proyecto es coherente y cerrado,

\bullet: cuando tiene lugar la prueba de integridad automática, para cada funcionalidad necesaria para el proyecto se busca automáticamente, entre una lista de componentes accesibles, un componente que cumple dicha funcionalidad,

\bullet: en el caso en que se identifican varios componentes que cumplen la funcionalidad requerida, se puede elegir entre estos componentes un componente particular,

\bullet: en el caso en que la prueba de integridad revele que el proyecto no está correctamente cerrado, se edita un mensaje de error que indica las incoherencias para poder modificar algunos componentes y/o añadir otros,

\bullet: para cada componente cargado en el sistema, la descripción de las funcionalidades que el componente tiene necesidad de importar de otros componentes a fin de cumplir su propia funcionalidad es accesible de forma permanente a dichos medios de búsqueda automática del componente,

\bullet: cuando tiene lugar la encapsulación de los ficheros objeto creados cuando tiene lugar la etapa precedente en un módulo ejecutable único, se verifica que todas las funcionalidades proporcionadas por las diferentes partes de intercara del proyecto han sido efectivamente descritas totalmente en un fichero fuente asociado, y compiladas,

\bullet: el procedimiento comprende la memorización en una zona de memoria viva del sistema de una cartografía de los componentes cargados en el sistema,

\bullet: dicha cartografía está destinada a ser consultada cuando tiene lugar la llamada de una funcionalidad por un componente llamador, para determinar si un componente de dicha cartografía es apto para proporcionar la funcionalidad llamada,

\bullet: son dichos medios de búsqueda automática de componente que son aptos para consultar dicha cartografía,

\bullet: dicha cartografía es puesta al día en tiempo real cuando tiene lugar el funcionamiento del sistema, en función de los componentes cargados en el sistema,

\bullet: cada componente puede estar asociado a un nivel de privilegios que condiciona las posibilidades de acceso del componente a otros componentes, en función de los niveles de privilegios respectivos de dichos otros componentes,

\bullet: están previstos unos medios para descargar automáticamente cada componente cuya funcionalidad que ofrece no es necesaria para el funcionamiento de los proyectos informáticos,

\bullet: dichos medios comprenden un contador de utilización para cada componente,

\bullet: dicho contador cuenta el número de componentes que importa una funcionalidad del componente al cual el contador está asociado, y dicho componente es descargado desde que su contador de utilización a decrecido hasta cero,

\bullet: están previstos unos medios para liberar automáticamente los recursos utilizados por dicho componente descargado.

\ding{226} Introducción de las figuras

Otros aspectos, objetos y ventajas del sistema según la invención aparecerán mejor con la lectura de la descripción siguiente de una forma de realización de la invención, dada con referencia a los planos anexos en los cuales, además de las figuras 1 y 2 que han sido ya comentadas:

\bullet: las figuras 3a a 3c son tres representaciones esquemáticas de un sistema de explotación según la invención,

\bullet: la figura 4 es una representación esquemática de un componente del sistema según la invención,

\bullet: la figura 5 es una representación esquemática de las etapas de elaboración de dicho componente,

\bullet: la figura 6 es un logigrama que ilustra la creación y la utilización de un componente de un sistema de explotación según la invención,

\bullet: la figura 7 representa en modo de repartición y de carga de los componentes lógicos del sistema según la invención,

\bullet: la figura 8 ilustra la reducción de consumo de memoria cuando tienen lugar la carga y la descarga dinámicas de componentes de un sistema según la invención,

\bullet: la figura 9 es un logigrama que ilustra el reemplazado dinámico de un componente en un sistema según la invención,

\bullet: las figuras 10a, 10b y 10c son tres cartografías de los componentes cargados en un sistema según la invención. La figura 10a correspondiente a una configuración mínima en la cual solamente son cargados los componentes estrictamente necesarios para el funcionamiento inicial de un sistema según la invención. La figura 10b corresponde a una configuración de base que permite además de una gestión multi-threads. La figura 10c corresponde a una versión enriquecida de un sistema según la invención.

\ding{226} Introducción general al sistema

Se ha dicho que los sistemas existentes, ya sean monolíticos o micronúcleo, diferencian sistemáticamente los programas en función de la capa del sistema a la cual están asociados.

El sistema según la invención no diferencia los programas de esta manera. Al contrario, en el caso de la invención, el sistema de explotación está completamente constituido por componentes no jerarquizados. Así, según una característica original, el sistema según la invención no presenta una estructura en capas.

Y aunque el programador de un sistema lógico conserve en el caso de la invención la posibilidad de asociar a cada componente del sistema un nivel de privilegios particular para comunicar con los otros componentes (pudiendo estos niveles de privilegios corresponder a los clásicamente utilizados en los sistemas del estado de la técnica -"núcleo", "biblioteca", "aplicativo", o bien ser creado bajo demanda), el programador es libre de efectuar o no dicha asociación para cada componente, y elegir un nivel de privilegios cualquiera deseado para el componente.

Se precisa que se define el término "programador" como que puede referirse a una persona sola o un equipo de desarrolladores. Un gran interés del sistema según la invención es, como se comprenderá, permitir a unos equipos de desarrolladores trabajar de manera lo más eficaz posible, pudiendo cada desarrollador tomar a su cargo una funcionalidad de una aplicación, desarrollando un componente. Y la gestión fina de los privilegios ofrecida por el sistema según la invención abre numerosas posibilidades, como por ejemplo:

\bullet: la creación, el desarrollo y la prueba completa de un componente en modo "no privilegiado" (aplicativo), y su explotación sobre la diana en modo "privilegiado" (sistema) una vez terminado el desarrollo y totalmente validado. Esta aproximación permite la misma flexibilidad de puesta a punto que un sistema con micronúcleo, permitiendo concebir un piloto ("driver") en forma de aplicación, para a continuación explotarlo a un nivel de características igual a un núcleo monolítico, en modo "sistema",

\bullet: la posibilidad de asignar unos privilegios diferentes en el interior de un grupo de componentes del mismo tipo (por ejemplo unos "codecs", codificadores - decodificadores de datos): explotación de un componente simple (ejemplo: "codec" GIF) en forma de componente sistema, para la rapidez; y de un componente complejo (por ejemplo "codec" HTML o Macromedia Flash (marcas registradas) en forma de componente usuario, menos rápido pero segurizado y que ofrece una total tolerancia a las averías.

Esta elección caso por caso permite al programador construir su sistema completamente en función de sus objetivos.

Las figuras 3a a 3c ilustran esquemáticamente la arquitectura de un sistema según la invención, que está únicamente realizada a base de componentes, y que no presenta elemento "central" tal como un núcleo o un micronúcleo.

Estos componentes tienen, como se verá cada uno una existencia propia en el sistema; pueden ser creados, compilados, cargados en memoria en el sistema y descargados independientemente unos de los otros, lo que permite:

\bullet: poner dinámicamente el sistema al día (nueva versión, corrección de bugs...) sin tener que arrancar de nuevo nunca ("rebooter"),

\bullet: liberarse, cuando tenga la concepción del sistema lógico, de los "partis pris" poco portátiles en la abstracción del material que se hace por el sistema lógico, ofreciendo la posibilidad de cambiar las políticas de gestión del material en función de las necesidades propias del producto final.

Cada componente del sistema según la invención está dedicado a una funcionalidad única, al contrario de los sistemas de explotación clásicos en los cuales el núcleo, así como la mayor parte de los programas, cumplen unas funcionalidades múltiples.

Y para cumplir la funcionalidad que le está asociada, cada componente puede requerir la ejecución de una o varias de otras funcionalidad(es), por uno o varios otros componente(s).

Así, para funcionar, el sistema según la invención pone en comunicación cada componente dado que está cargado en su memoria con otros componentes que cumplen una funcionalidad necesaria para el funcionamiento propio del componente dado.

Las figuras 3a a 3c comprenden así unas flechas que ilustran los canales de comunicación que son establecidos por el sistema entre algunos componentes a fin de permitirles transmitirse funcionalidades.

Estas figuras ilustran también el carácter dinámico de la arquitectura del sistema, pudiendo un componente 31 ser reemplazado por un componente 32 para cumplir la misma funcionalidad, sin necesitar el cambio de ningún otro componente, como se ha representado en la figura 3c. Estos aspectos serán detallados a continuación.

\ding{226} Los componentes - generalidades \sqbullet Definición general

Se comprende que el componente es un elemento fundamental del sistema según la invención, también es importante definirlo precisamente.

Un componente en el sentido de la invención es un elemento de código aislado, independiente y autónomo. Como se describirá más en detalle, cada componente del sistema según la invención posee las propiedades siguientes:

\bullet: cumple una funcionalidad única, a la cual está dedicado;

\bullet: cumple totalmente esta funcionalidad. Una funcionalidad dada es ejecutada en un solo componente. Esto permite no tener que modificar o reemplazar más que un solo componente si se quiere alterar una funcionalidad dada, en el desarrollo de una aplicación o de cualquier otro programa;

\bullet: como para la filosofía objeto, la manera en que una funcionalidad dada es cumplida por un componente no es conocida de los otros componentes que utilizan esta funcionalidad;

\bullet: cada componente es compilado de forma independiente, para formar un fichero ejecutable separado asimilable a una cápsula del componente (denominada "módulo" del componente). Cuando tiene lugar la compilación, no hay edición de enlaces entre los componentes. Esto permite una flexibilidad hasta aquí desconocida, en particular para los componentes que cumplen las funcionalidades esenciales del sistema y atribuidas al "núcleo" en los sistemas tradicionales,

\bullet: cada componente está asociado a un código ejecutable, encapsulado en su módulo con la ayuda de una intercara que está también individualmente asociada al componente. Cuando tiene lugar la concepción de un componente, el conceptor describe, en un fichero texto que constituye la versión fuente de la intercara del componente, la funcionalidad que el componente proporciona, con la ayuda de un lenguaje de descripción especialmente ideado a este fin por el solicitante. Esta descripción es la única información hecha disponible al sistema a propósito del componente. Dicha encapsulación garantiza la ausencia de "efectos de bordes" y de interdependencias incontrolables entre componentes del sistema.

Un componente del sistema según la invención es por tanto un objeto lógico totalmente encapsulado (en el módulo) y aislado del resto del sistema con la ayuda de una intercara, que como se verá posee unas propiedades:

\bullet: de reutilizabilidad y de modularidad (pudiendo un mismo componente ser utilizado en diferentes aplicaciones - o de manera más general en diferentes programas);

\bullet: de independencia respecto al entorno (siendo cada componente generado individualmente y pudiendo ser cargado y descargado independientemente en el sistema),

\bullet: de enlace dinámico (interviniendo los componentes bajo demanda, y no de forma sistemática),

\bullet: y de especialización en una funcionalidad dada.

Un componente C está constituido por dos partes principales, como se ha ilustrado en la figura 4:

\bullet: una parte IMP que permite la realización de la funcionalidad asociada al componente, parte que se denominará por convención "parte implementación" del componente. Esta parte corresponde al código que es ejecutado para cumplir la funcionalidad del componente, y/o a una implementación material sobre unos elementos de hardware. Por "código", se entienden uno o varios programas, que pueden ser escrito(s) en cualquier lenguaje conocido, estando el (los) dicho(s) programa(s) destinado(s) a cumplir la funcionalidad asociada al componente y ejecutando para ello una o varias funciones;

\bullet: y una parte INT "intercara" del componente, que es la parte descriptiva que permite el diálogo con los otros componentes del sistema.

\sqbullet Encapsulación de los componentes

Cada componente es encapsulado en un "módulo", fichero ejecutable que enlaza los ficheros objetos que corresponden a la intercara y al código del componente.

Como se verá, este fichero es generado de forma autónoma para cada componente, independientemente de los otros componentes que constituyen el sistema según la invención.

Para generar un componente, es necesario definir las funcionalidades externas al componente y de las que tendrá necesidad de utilizar los resultados cuando tiene lugar su ejecución; esto destaca de una marcha de análisis funcional clásico.

Por el contrario, como se comprenderá, el sistema según la invención conserva las informaciones semánticas salidas de esta fase de análisis funcional hasta en el marco de la ejecución del componente.

Esto facilita en gran manera las evoluciones del sistema y aumenta su legibilidad.

Las funcionalidades externas al componente se describen en el fichero fuente de intercara del componente, con la ayuda del lenguaje de dependencias creado por el solicitante y evocado más arriba.

Más precisamente, cada fichero fuente INT de intercara asociado a un componente C permite describir totalmente este componente. El mismo describe, los elementos de intercara que debe importar de otros componentes, y aquellos que exporta hacia otros componentes.

Este fichero será compilado (con la ayuda de un fichero de compilación MF, denominado también Makefile) y ligado al (los) fichero(s) objeto correspondiente al código de la parte implementación IMP (es decir a cada uno del o de los fichero(s) fuente(s) de la parte implementación del componente), para formar el módulo M del componente que constituye la versión ejecutable del componente, como se ha representado esquemáticamente en la figura 5 siguiente. El lenguaje de dependencia utilizado para crear los ficheros fuente de intercara será explicado más adelante en este texto.

Un módulo M puede entonces ser cargado sobre una diana 50 (estando la diana definida como el material informático sobre el cual el sistema lógico según la invención funciona), y ser inmediatamente reconocido por los otros componentes presentes en esta diana, como será detallado.

\sqbullet La parte implementación del componente

La parte implementación IMP es el núcleo operativo del componente. Es la parte que permite la realización efectiva de la funcionalidad del componente. Esta funcionalidad puede ser realizada de diferentes maneras por la parte de implementación, según las funciones utilizadas por el código.

Así, diferentes componentes pueden cada uno realizar una misma funcionalidad, pero teniendo en cuenta unos criterios diferentes, criterios que pueden ser predeterminados cuando tiene lugar la concepción de la aplicación o del programa que hace intervenir el componente, o determinados dinámicamente cuando tiene lugar la ejecución misma de la aplicación.

Estos criterios se describen en forma de propiedades (por ejemplo void, char, etc....) asociadas a la intercara del componente, que serán descritas más adelante en este texto.

Los criterios son expresados en función de una de estas propiedades, que está definida en la intercara del componente que exporta la funcionalidad, asociando la intercara del componente que importa la funcionalidad un operador de comparación con esta propiedad (<, >, = , etc. ... como se describe más adelante), así como un valor de comparación.

Es posible adaptar el sistema o la aplicación de forma estática o dinámica, en función de criterios externos al componente (materiales por ejemplo), o del estado actual del sistema y de la aplicación cuando tiene lugar la ejecución.

El fichero de intercara de cada componente proporciona así un conjunto de metainformaciones, que permitirán como se verá a un componente específico del sistema (el gestor de dependencias) administrar de forma pertinente las relaciones entre los componentes, en función de los criterios mencionados más arriba (que pueden referirse a una versión del componente, una localización de este componente, un dato del estado del sistema...).

Y se precisa que si cada funcionalidad puede ser realizada únicamente por un código (implementación "lógica" de la funcionalidad), es también posible hacer intervenir por lo menos un elemento de hardware para cumplir la funcionalidad (implementación "material" de la funcionalidad).

\sqbullet La parte intercara del componente

La parte intercara permite describir precisamente que funcionalidad es proporcionada por el componente y que funcionalidades deberán serle proporcionadas, cuando tiene lugar su ejecución.

La misma define, en el lenguaje de dependencias desarrollado por el solicitante, el formato de los datos que deben ser proporcionados de entrada al componente y el formato de los datos a la salida del componente. Este formato es únicamente dependiente de la funcionalidad realizada, y no de la forma en que la funcionalidad es realizada por la parte implementación.

Esta parte intercara permite constituir una descripción de la funcionalidad realizada por el componente, independientemente de la manera en la cual esta funcionalidad es realizada por la parte implementación. En efecto, cualquiera que sea el modo de realización de la funcionalidad por un código (o por un elemento material programado), esta funcionalidad permanece idéntica. La misma efectúa los mismos tratamientos, solicita las mismas informaciones de entrada y proporciona los mismos datos de salida.

La parte intercara permite por tanto ampliamente las evoluciones del sistema. Una implementación lógica de una funcionalidad (correspondiente a un componente cuya parte de implementación está constituida por un código) podrá así ser realizada más tarde por una implementación material.

En este caso, el componente correspondiente comprende un fichero de intercara, pero su parte implementación está constituida por un programa muy simple que describe el enlace con el elemento material.

Inversamente, una implementación material podrá ser reemplazada sin ningún impacto sobre los otros componentes por una implementación lógica de una funcionalidad.

Una intercara está definida con la palabra clave "intercara" en la descripción del módulo del componente.

La tabla siguiente describe diferentes propiedades de una funcionalidad; estas propiedades pueden referirse a unas funcionalidades solicitadas por el componente (sentido = import), o la funcionalidad que el componente proporciona (sentido = export):

1

Una intercara puede ser definida en su fichero texto con la ayuda de diferentes propiedades. Un ejemplo se da a continuación:

: inprocess supervisor module {

: interface component {

: /* Definición de la intercara exportada*/

: }

: foreign loadtime required interface codec {

: /* Definición de la intercara importada*/

: }

: };

\newpage

\RightarrowPropiedades de una intercara

Las propiedades de una intercara permiten definir los criterios mencionados más arriba en este texto. Las mismas están tipificadas, como en lenguaje C (marca registrada). La tabla siguiente describe los diferentes tipos de propiedades:

2

Las extensiones siguientes pueden ser asociadas a estas propiedades:

3

Cuando tiene lugar la descripción de las dependencias en el fichero de intercara, unos operadores permiten precisar las propiedades de las intercaras. Los mismos permiten así autorizar solo la importación de otra intercara si el valor de una propiedad de esta otra intercara corresponde a un criterio bien definido.

Los operadores siguientes pueden ser asociados a las propiedades de las intercaras:

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

(Tabla pasa a página siguiente)

4

La palabra clave "undef" puede ser utilizada como valor de comparación para las propiedades o las funciones. En el ejemplo siguiente, el componente considerado necesita una intercara denominada codec, que contiene una propiedad entera de 32 bits denominada mainType, cuyo valor debe ser 2 exactamente. Esta intercara debe hacer realizar una funcionalidad Func() que toma como parámetro una cadena de caracteres y que devuelve un entero firmado 32 bits.

: foreign loadtime required interface codec {

: /* Definición de la intercara importada*/

: int mainType == 2;

: int Func (string name) ! = undef;

: . . .

: }

La provisión y la solicitud de funcionalidad se realizan por tanto por la descripción de intercaras de programación, proporcionadas o solicitadas. Un componente puede por ejemplo proporcionar la intercara de programación "scheduler" (ordenador que permite la creación/destrucción/manipulación de procesos y de threads y su sincronización), solicitando al mismo tiempo la intercara "memory" (gestión de la memoria), la intercara "timer" (gestión de un contador de tiempo, del cual el ordenador tiene necesidad para interrumpir un proceso al cabo de un tiempo dado y pasar al siguiente), etc.

Estas intercaras de programación pueden contener a la vez:

\bullet: unas propiedades (versión, tipo de gestión de memoria, propiedades del secuenciado, etc.),

\bullet: y unos procedimientos (funciones) llamados para la ejecución del componente.

Las propiedades son utilizables a la vez cuando tiene lugar la provisión, y cuando tiene lugar la solicitud, de una intercara dada. Se puede por tanto expresar que la intercara memory asociada a un componente está en su versión 1.5.2 (propiedad expresada cuando tiene lugar la provisión de la intercara); o también que se solicita una intercara memory cuya versión es por lo menos 1.0.0 pero no la versión 1.0.4 puesto que se sabe que tiene un "bogue" insoslayable (propiedad expresada cuando tiene lugar la solicitud de la intercara).

Y el contenido de la intercara (propiedades y procedimientos) constituye una descripción escrita por el programador con la ayuda del lenguaje creado por el solicitante a este fin.

Es el lenguaje es compilado por el compilador de las dependencias, en una forma binaria que está incluida en el componente ejecutable que constituye el módulo, al mismo título que el código del componente y los datos asociados.

Esta forma binaria es fácilmente explotable en la ejecución, por el sistema, a fin de unir los componentes entre sí, según las funcionalidades solicitadas.

Este lenguaje es también utilizado para precisar que tipo de código contiene el componente ("sistema" o no, "pasivo" (biblioteca) o "activo" (aplicación), etc.), y que tipo de código puede acceder a una función dada (que permite restringir las funciones "peligrosas" del sistema a los llamadores "sistema" por ejemplo); esto permite la elección del medio de comunicación más optimizado.

\ding{226} Los componentes - creación y carga en el sistema

Con referencia ahora a la figura 6, se describirán las etapas de la creación de un componente del sistema según la invención, y de su utilización en el sistema según la invención.

Esta figura 6 es un logigrama en el cual las columnas representan diferentes elementos utilizados para la creación y la utilización de los componentes del sistema según la invención. De izquierda a derecha, se encuentra así en esta tabla:

\bullet: dos columnas "COMP" que corresponden al mismo componente, correspondiendo la columna más a la izquierda "INT" a la parte intercara mientras que la columna siguiente "IMP" corresponde a la parte implementación,

\bullet: una columna "MF" para el makefile que es el fichero de compilación del componente,

\bullet: una columna "COMPIL DEP" correspondiente a un elemento de concepción de los componentes que es el compilador de dependencias, elemento específicamente desarrollado por el solicitante para la compilación de un componente,

\bullet: una columna "COMPIL CODE" correspondiente al (los) compilador(es) de tipo conocido(s) del o de los fichero(s) que constituye(n) el código del componente,

\bullet: una columna "LINK" correspondiente al editor de enlace,

\bullet: una columna "KBIM" correspondiente a una herramienta de desarrollo particular del sistema según la invención que interviene cuando tiene lugar la concepción de un proyecto (noción que se define a continuación),

\bullet: una columna "GD" dedicada a un componente particular del sistema según la invención, llamado el gestor de dependencia (o GD), que constituye como se verá el núcleo del sistema según la invención, pero se diferencia totalmente de los núcleos y micronúcleos del estado de la técnica,

\bullet: una columna "LOAD" correspondiente a unos componentes particulares del sistema según la invención, los loaders, que permiten cargar los componentes del sistema en una zona de memoria viva de la diana,

\bullet: la columna de la derecha da una indicación de las diferentes fases descritas.

\sqbullet Creación del componente

Se define aquí la noción general de "proyecto", que designa un conjunto de componentes que tienen una finalidad común en el sistema según la invención. Un proyecto puede así corresponder a una aplicación, pero también de forma más general a cualquier tipo de programa que puede ser ejecutado por un sistema informático, y diferente de una aplicación (gestor de periféricos por ejemplo).

Previamente a la creación de un proyecto destinado a ser utilizado en el sistema según la invención, se procede en 601, de manera clásica, alguna fase de análisis funcional (AF).

Esta fase permite definir los diferentes componentes necesarios, sus funcionalidades respectivas, y las necesidades asociadas a cada una de estas funcionalidades (funcionalidades que deben ser aseguradas por otros componentes). Es posible como se verá utilizar unos componentes ya cargados en el sistema para aportar ciertas funcionalidades al proyecto.

Una vez efectuado este análisis previo, y conocidas las necesidades en términos de componentes, el programador procede para cada componente a la sucesión de las etapas 602 a 606:

\bullet: en 602, creación de un fichero fuente de intercara del componente en el cual se describen, en el lenguaje de dependencias desarrollado por el solicitante, las características del componente. Se volverá más adelante en este texto sobre las características de este lenguaje, y sus principales posibilidades,

\bullet: en 603, el programador crea a continuación el código, es decir el (los) fichero(s) fuente que permiten asegurar la funcionalidad del componente, en uno o varios lenguaje(s) que pueden ser de tipo(s) conocido(s). Cuando tiene lugar esta etapa, la o las función(es) a exportar por el componente solo están definidas en términos de prototipo, no siendo descrito el código correspondiente.

Se precisa que una funcionalidad corresponde a un tratamiento o a una operación a realizar (la descripción de una funcionalidad será expresada en francés), por ejemplo la gestión de la memoria, cuando tiene lugar el lanzamiento de los procesos en curso para administrar su acceso al procesador de la diana, la representación gráfica, etc. ..... Lo que se denomina función, es una parte de código lógico que realiza también un tratamiento. La función es la traducción lógica en un lenguaje de programación de la funcionalidad (de donde viene su nombre).

En todos los lenguajes de programación, una función es realizada de forma muy próxima a nuestro sistema. La misma comprende:

\ding{51}: un prototipo que define los parámetros de entrada y de salida (su nombre y su tipo). Este prototipo puede ser asimilado a la parte intercara de nuestros componentes (su función es idéntica);

\ding{51}: una parte de código. Esta parte efectúa un tratamiento sobre unos datos y permite así determinar el resultado a proporcionar de salida.

Se precisa también que el prototipo de una función define el nombre de la función, sus parámetros de entradas (sus nombres y sus tipos) así como el tipo de información del resultado devuelto por la función,

\bullet: en 604, el programador crea un Makefile en el cual se específica en particular:

\ding{51}: el (los) lenguaje(s) utilizado(s) para el (los) fichero(s) fuente creado(s) cuando tiene lugar la etapa precedente 603,

\ding{51}: el (los) fichero(s) fuente que corresponde a la parte implementación del componente,

\ding{51}: las opciones de compilación,

\bullet: en 605, el programador crea con el compilador unas dependencias y el (los) compilador(es) correspondiente al (los) lenguaje(s) utilizado(s) un prototipo del componente que comprende:

\ding{51}: una intercara objeto que resulta de la compilación del fichero fuente de intercara del componente creado en 602, por el compilador de las dependencias. Para esta compilación de la intercara, el compilador de dependencias analiza el texto del fichero fuente de la intercara, verifica su coherencia, y después lo traduce en datos binarios que serán comprensibles por el GD. El compilador de dependencias genera automáticamente unos ficheros para llamar las funcionalidades citadas en la intercara y que deben se proporcionadas al componente.

: Estos ficheros son unos ficheros del tipo "include", generados por el compilador de dependencias. Un fichero "include" es generado para cada lenguaje de implementación del código. La función de estos ficheros es definir en el sistema informático un espacio de nominación (es decir un contexto al cual están asociadas unas correspondencias), externo al del componente y distinto de él, que permite acceder a las funcionalidades que son solicitadas por el componente en su intercara. Cada uno de estos ficheros "include" define así unas estructuras que podrán ser llamadas por la intercara del componente, de manera que traduzcan las solicitudes realizadas en la intercara, en estructuras y nombres utilizables por el lenguaje de implementación al cual el fichero "include" está asociado.

\ding{51}: Un fichero objeto para cada fichero fuente creado en 603; cada fichero objeto corresponde en esta fase a un fichero fuente prototipo cuyas funciones no están completamente descritas,

\bullet: en 606, el programa edita a continuación los enlaces entre la intercara objeto y el (los) fichero(s) objeto de la parte implementación del componente, de manera que generen un prototipo de componente ejecutable.

KBIM procede a continuación en 607 a una prueba de integridad del conjunto de los componentes de prototipos así desarrollados para el proyecto previsto, verificando que proyecto creado es coherente y cerrado (es decir que todas las funcionalidades necesarias para el proyecto están presentes en el interior de este proyecto).

Cuando tiene lugar la prueba de integridad, KBIM dispone de la lista y de la descripción de las intercaras de todos los componentes. Así, KBIM puede buscar, entre estos componentes, el componente que cumple una funcionalidad necesaria para el proyecto. Si varios componentes cumplen la funcionalidad solicitada, KBIM propone al programador elegir entre estos componentes. El componente encontrado automáticamente por KBIM o designado por el programador es entonces añadido a los componentes que constituyen el proyecto. Este nuevo componente puede también necesitar otras funcionalidades que KBIM probará de resolver. KBIM permite así resolver automáticamente a la mayor parte de las funcionalidades necesarias para un proyecto.

Si el proyecto no está correctamente cerrado, el KBIM edita un mensaje de error que indica al programador las incoherencias y éste emprenderá de nuevo la sucesión de las etapas 602 a 606 a fin de modificar algunos componentes de la aplicación y/o de añadir alguno; si el proyecto es coherente y cerrado, el programador completa en 608 los prototipos de las funciones del código de la parte implementación del componente, escribiendo la versión completa de las funciones, en el (los) fichero(s) fuente de esta parte implementación.

En 609, el programador utiliza el Makefile para compilar cada componente separadamente, de manera que cree para el código los ficheros objetos que permitieran ejecutar la funcionalidad del componente. Cuando tiene lugar esta etapa el Makefile hace intervenir el compilador de dependencias así como el (los) compilador(es) del o de los lenguaje(s) utilizado(s) para elaborar el código. Las etapas 608 y 609 son repetidas para cada componente del proyecto en curso de desarrollo.

El programador pone en marcha a continuación en 610 el editor de enlaces para crear un módulo ejecutable para cada componente, estando dicho módulo asociado al conjunto de los ficheros objeto creados cuando tienen lugar las etapas de compilación 605 y 609 (habiendo sido la intercara objeto creada cuando tiene lugar la etapa 605, mientras que el (los) fichero(s) objeto asociado(s) al código ha o han sido creado(s) cuando tiene lugar la etapa 609).

Cuando tiene lugar esta edición de enlaces que corresponde a la encapsulación del componente en el módulo, el editor verifica que todas las funcionalidades proporcionadas por las diferentes intercaras del proyecto han sido efectivamente descritas totalmente en un fichero fuente asociado, y compiladas.

\sqbullet Declaración del componente

Una vez que un módulo ejecutable ha sido así creado para cada componente del proyecto, el programador debe declarar la existencia de estos componentes para que éstos sean tenidos en cuenta por el sistema. Esta declaración es efectuada en 611, etapa cuando tiene lugar la cual el programador declara cada componente a un "loader", siendo los loaders a su vez unos componentes específicos del sistema según la invención.

Cuando tiene lugar esta etapa 611, el loader a cerca del cual se declara un componente memoriza el componente en una lista individual del loader que reúne el conjunto de los componentes que han sido declarados a cerca de él.

Esta etapa 611 es también una etapa que se refiere globalmente al proyecto en curso de desarrollo, siendo el conjunto de los componentes desarrollados para un proyecto declarado a cerca de por lo menos un loader - correspondiendo cada loader a un medio del sistema informático (disco, red, etc. ...) sobre el cual son almacenados los componentes asociados a este loader.

\sqbullet Carga del componente en el sistema

Se han descrito anteriormente las etapas de creación y de declaración de un "proyecto" que puede comprender varios componentes. Se describirá a continuación la utilización de estos componentes, que está ilustrada en la parte inferior de la figura 6.

En 620, un componente C1 llama una funcionalidad F1 que le es necesaria.

Para esta llamada se presentan dos posibilidades:

\bullet: o bien la funcionalidad F1 está definida con la propiedad "loadtime" en la intercara del componente C1 (la propiedad "loadtime" se describe más arriba). En este caso, el GD buscará y cargará en el sistema el componente que cumple esta funcionalidad F1, previamente a la carga del componente C1.

\ding{51}: Si este componente necesita a su vez una funcionalidad "loadtime", GD cargará entonces también el componente necesario para cumplir esta funcionalidad, siempre previamente a la carga del componente C1. GD cargará así recursivamente todos los componentes necesarios para cumplir las diferentes funcionalidades "loadtime" que encontrará (se explicará más adelante como cargar un componente del sistema),

\bullet: o bien la funcionalidad F1 está definida con la propiedad "runtime" (la propiedad "runtime" se ha descrito más arriba).

: El componente C1 debe entonces realizar una llamada explícita a otra funcionalidad, "depmgr", proporcionada por el GD, para llamar la funcionalidad "runtime" F1. Para ello, la funcionalidad "depmgr" debe imperativamente ser declarada con la propiedad "loadtime" en la intercara de C1 a fin de poder utilizar esta intercara desde la carga y la inicialización de C1 (ver más arriba el tratamiento de la funcionalidad "loadtime").

: C1 podrá entonces importar la funcionalidad "runtime" F1 llamada en 620 en el momento preciso en que debe utilizarla. El componente que cumple esta funcionalidad F1 será entonces cargado por GD.

: Si este componente necesita una funcionalidad en el momento de su carga (funcionalidad declarada "loadtime" en su intercara), el componente cumple esta funcionalidad "loadtime" será también cargado.

: GD cargará así recursivamente todos los componentes necesarios para cumplir las diferentes funcionalidades "loadtime" que encontrará (se explicará más adelante como cargar un componente en el sistema).

: La funcionalidad F1 solicitada inicialmente en 620 solamente sólo estará disponible para C1 si todas las funcionalidades "loadtime" encontradas cuando tiene lugar su resolución están también resueltas. Si una sola funcionalidad solicitada en la carga por C1 (funcionalidad declarada "loadtime") no está resuelta, C1 no será cargado. C1 no podrá en efecto cumplir la misión funcional puesto que no podrá utilizar otra funcionalidad que le es necesaria.

Si la funcionalidad que C1 debe importar no es cumplida por uno de los componentes del proyecto al cual pertenece C1 y con el cual es declarado acerca de uno de los loaders del sistema, el sistema, como se mostrará, identifica en otro proyecto un componente que permita proporcionar esta funcionalidad a C1.

A estos fines GD, que está cargado de forma permanente en la memoria viva del sistema, busca en su "gráfico de los enlaces" si el fichero objeto de intercara de uno de los componentes del gráfico de los enlaces indica que este componente proporciona la funcionalidad solicitada por C1.

Para ello, el GD interpreta la versión "binaria" del fichero de intercara, que está almacenada en el componente ejecutable, y cargada/transmitida por los componentes "loaders" al GD para la ejecución.

El GD busca en principio las intercaras que poseen el mismo nombre que la solicitada (importada). Cuando la encuentra, verifica a continuación en el interior de éstas que todas las propiedades de la funcionalidad solicitada estén presentes y las obligaciones y condiciones eventuales (versión superior a 0.6.2, etc.) sean satisfechas.

El gráfico de los enlaces del GD es una lista de los componentes que están cargados en el sistema, es decir que son no solamente declarados como se ha descrito anteriormente a propósito de la etapa 611, sino que su fichero de intercara objeto ha sido importado en una zona de memoria viva de la diana, y que está en relación con otros componentes del gráfico de los enlaces para intercambiar unas funcionalidades proporcionadas y/o solicitadas.

El gráfico de los enlaces, que está memorizado en una zona de memoria viva de la diana, es así una imagen instantánea de los componentes cargados, pudiendo este gráfico de los enlaces evolucionar de forma dinámica. El gráfico de los enlaces es único y está asociado al GD, teniendo el GD acceso a las informaciones de este gráfico de los enlaces.

Si el GD determina, cuando tiene lugar la etapa 621, que la funcionalidad llamada por C1 es proporcionada por unos componentes del gráfico de los enlaces (que se denominará C2 "componente llamado", mientras que C1 es un el "componente llamador"), establece un canal de comunicación entre este componente C2 y el componente C1 importando en 627 unas características del componente C2 en el componente C1.

Más precisamente, el GD construye para C1 una estructura de datos denominada "view" (vista) que ofrece, una vista de las importaciones que deben ser realizadas. Esta "view" contiene el valor de las propiedades así como los apuntadores sobre las funciones importadas (o sobre el código que permite indirectamente alcanzarlas, como por ejemplo una llamada sistema, una migración de threads, etc.). Esta "vista" sale directamente de los elementos generados por el compilador de dependencias en los ficheros "include".

Si ahora el GD determina en 621 que la funcionalidad llamada por C1 no es proporcionada por ninguno de los componentes del gráfico de los enlaces, interrogará las listas de los loaders del sistema unas después de las otras, a fin de determinar si uno de los componentes declarados acerca de estos loaders ofrece la funcionalidad solicitada por C1. Esta interrelación de los loaders está representada por la etapa 622.

Cuando tiene lugar esta interrogación, el GD utiliza una funcionalidad "loader" que posee las funciones necesarias para listar los componentes que cada "loader" ve. La funcionalidad "loader" permite al GD comparar una funcionalidad exportada por un componente del loader, con la funcionalidad que debe ser importada. La misma permite también al GD cargar y descargar un componente individual, del medio al cual está asociado el loader hacia la memoria viva de la diana.

Se precisa que cada uno de los loaders del sistema según la invención está asociado a un medio particular que permite almacenar unos componentes; cada loader podrá así estar asociado a un disco de memoria, o a cualquier otro soporte de registro, del tipo CD ROM por ejemplo. La pluralidad de los loaders será ilustrada en particular con referencia a la figura 7.

Si un componente de este tipo es localizado en la lista de uno de los loaders del sistema (etapa 623), el primer loader cuya lista comprende dicho componente transmite en 625 al gestor de dependencia la intercara objeto del componente C2 identificado, y el GD transmite a su vez en 626 al componente C1 la "vista" de este componente C2 (etapa 627).

La "vista" de C2 ha sido memorizada por el GD en una zona de memoria del sistema que es creada dinámicamente por el GD, a la carga del componente C2, y que será destruida al mismo tiempo que este componente será descargado. Esta zona se encuentra en el mismo espacio de direcciones que el componente que puede acceder a la misma.

Si ahora la búsqueda del GD para identificar en la lista de uno de los loaders un componente que proporciona la funcionalidad solicitada resulta infructuosa cuando tiene lugar la etapa 623, el sistema se para en 624.

En cualquier caso, la carga de un componente C1 en la memoria viva del sistema provoca, como se ha explicado anteriormente, la búsqueda automática por el GD de un componente C2 que ofrezca la funcionalidad F1 que es necesaria para el funcionamiento del componente C1.

Y si el componente C1 llama no una sola, sino varias funcionalidades, el GD procederá así mismo a la búsqueda automática de componentes que ofrezcan estas funcionalidades requeridas.

Se destacará que el sistema según la invención ofrece un grado de flexibilidad suplementario con respecto a los sistemas conocidos.

En efecto, en el caso de los sistemas conocidos montados con unas entidades el programador debe especificar para cada entidad llamadora dada la lista de las otras entidades del sistema que son necesarias para el funcionamiento de dicha entidad llamadora, y que deben ser cargadas en el sistema para el buen funcionamiento de esta entidad llamadora.

Así, en el caso de estos sistemas conocidos, las necesidades de las entidades no están expresadas de manera general en término de funcionalidades, sino en términos de entidades específicas (es el caso por ejemplo del lenguaje Java).

Y en el caso de la invención, cada uno de los varios componentes diferentes es susceptible de ser asociado a un componente C1 llamador, en la medida en que dichos componentes diferentes ofrecen la misma funcionalidad.

Y una ventaja suplementaria de la invención resulta de los criterios que es posible asociar a los componentes, siendo tomados estos criterios en cuenta por el GD cuando tiene lugar su búsqueda automática de componentes que ofrezcan una funcionalidad solicitada por un primer componente.

En efecto, cuando tiene lugar esta búsqueda de componentes el GD busca no solamente un componente que ofrezca una funcionalidad solicitada, sino más precisamente un componente que ofrezca dicha funcionalidad en asociación con una condición específica expresada según los criterios que han sido mencionados más arriba en este texto.

En el caso de los lenguajes existentes (por ejemplo del tipo lenguaje Java - marca registrada), en efecto, el programador debe obligatoriamente emplear un enlace explícito entre una entidad llamadora y una entidad llamada.

Resulta así que la utilización de este tipo de sistema conocido no ofrece en modo alguno el mismo grado de flexibilidad de la invención, que se presta mucho mejor al mantenimiento y a la evolución (por ejemplo para realizar unas versiones enriquecidas, en las cuales se pueden reemplazar unos componentes que ofrecen una funcionalidad solicitada por otros componentes que cumplen la misma funcionalidad de una manera diferente, o también añadir nuevos componentes que cumplen dicha funcionalidad a fin de ofrecer nuevas posibilidades de elección al GD.

Así, la invención permite construir unos sistemas extremadamente evolutivos, en los cuales se puede a voluntad reemplazar únicamente o varios componente(s) deseado(s).

Cada componente reemplazado ofrece una funcionalidad que ya había sido ofrecida por el antiguo componente que es reemplazado.

Sin embargo, los medios específicos para cumplir esta funcionalidad, ya sean lógicos y/o materiales pueden evolucionar a voluntad.

En el marco de aplicaciones tales como el mantenimiento de una red de los sistemas instalados en diferentes lugares, o también el mantenimiento de un conjunto de dispositivos móviles (tales como los teléfonos portátiles o unos organizadores personales por ejemplo) que no se desea repatriar físicamente en un lugar central para hacerlos evolucionar, esta posibilidad es particularmente interesante.

Así, se podrán hacer evolucionar las aplicaciones instaladas en los dispositivos del tipo mencionado anteriormente por simple telecarga de uno o varios componente(s) nuevo(s) sobre estos dispositivos, a partir de un lugar central, y esto sin que sea necesario desplazar físicamente los dispositivos que pueden estar diseminados en cualquier territorio.

Además, los reemplazamientos de estos componentes no necesitan la recompilación del sistema informático que los utiliza.

En el caso en que un componente C2 que ofrece la funcionalidad solicitada por C1 ha sido identificado (con eventualmente los criterios que satisfacen una condición requerida por la intercara de (1) y las características de C2 han sido importadas en C1 en 627, el gestor de dependencia operará de modo diferente según que el componente C2 forme ya parte del gráfico de los enlaces o no (etapa 628).

Si C2 pertenece ya al gráfico de los enlaces, el GD pasa directamente a la etapa 633 de creación de un canal de comunicación entre C1 y C2. Para ello, el sistema utilizará o bien uno de los cuatro modos de comunicación descritos más adelante, o bien un modo específico creado especialmente, en función de las características específicas en la intercara de C1 y/o C2:

\newpage

\RightarrowLas llamadas directas

Es el procedimiento más rápido. La funcionalidad o procedimiento solicitado es directamente llamado, y su resultado directamente devuelto. No hay ningún código intermedio. El gestor de dependencias elige este medio cuando los dos componentes están en la misma máquina, en el mismo espacio de direcciones, y al mismo nivel de privilegios.

Se define un espacio de direcciones como una zona de memoria lógica en la cual unas direcciones de código o de datos tienen una significación para todos los componentes que acceden a esta zona. Un apuntador sobre el código o de los datos puede ser transmitido tal cual de un componente a otro y, sin que su valor sea modificado, permitirá acceder a los mismos datos.

En la invención, el término "espacio de direcciones" implica también unos privilegios comunes, un espacio de dirección que define un "espacio" o una clase de objetos que tienen el mismo nivel de privilegios: Los objetos apuntados de un mismo espacio de dirección pueden así ser accedidos de la misma manera por los diferentes componentes.

Y se puede así por ejemplo definir un espacio "usuario" de nivel de privilegios inferior, y un espacio "supervisor" de nivel superior.

La coherencia de los apuntadores entre el espacio "usuario" de cada proceso, y un espacio "supervisor" (sistema) es respetado (teniendo el procesador del sistema informático acceso a los dos espacios al mismo tiempo), pero el código "usuario" no puede referenciar unos datos situados en el espacio "supervisor".

Los privilegios son unas posibilidades de acceso entre componentes; es posible utilizar en la intercara fuente los niveles de privilegios siguientes:

5

Para asignar uno de estos niveles de privilegios a un componente, el programador fija el parámetro correspondiente en la definición del módulo del componente que está contenida en el interior de un texto del tipo:

: inprocess supervisor module {

: /* Definición del módulo*/

: };

Así, de manera general, es posible asociar a cada componente individual un nivel de privilegios dado, condicionando dicho nivel de privilegios las posibilidades de acceso de este componente a otros componentes, en función de niveles de privilegios respectivos de dichos otros componentes.

Dicho de otro modo, la asociación de un nivel de privilegio de un componente da la posibilidad a este componente de "ver" las funcionalidades ofrecidas por las intercaras de ciertos componentes, en función de los niveles de privilegios que están efectivamente asociados a estos otros componentes.

Y como se verá más adelante, esta jerarquía de acceso entre los componentes que es establecida por los niveles de privilegios que pueden ser asociados individualmente a los diferentes componentes puede ser "cortocircuitada" por unos operadores asociados individualmente a ciertos componentes específicos.

Unos ejemplos de dichas llamadas son los siguientes:

\bullet: componente supervisor hacia componente supervisor;

\bullet: componente usuario (es decir de nivel de privilegios inferior) hacia componente usuario en el mismo espacio de direcciones (tal como una aplicación que utiliza un componente que rige una biblioteca de funciones compartidas y pasivas).

Este procedimiento es el único empleado si el componente memoria no proporciona protección, lo que puede ser la elección del ingeniero que construye el sistema para su producto, lo que proporciona un sistema extremadamente rápido en ausencia de protección.

El componente memoria no " proporciona" protección cuando este componente sólo ofrece un espacio de direcciones, del tipo "sistema". Este tipo de gestión de memoria no ofrece ninguna protección (funcionando al mismo tiempo en el mismo espacio y que puede potencialmente destruir o modificar el código o los datos que pertenecen a otros componentes), pero es el único posible en ciertas dianas que no poseen "MMU" (memory management unit).

\RightarrowLas llamadas sistema

La invocación es desviada hacia una llamada sistema. Éste transfiere los parámetros de la pila usuario hacia la pila supervisor, cambia el nivel de privilegios, efectúa la llamada, vuelve al nivel de privilegios inferior, y devuelve el resultado de forma directa.

Este procedimiento es seleccionado cuando un componente usuario (no privilegiado) llama a una funcionalidad de un componente supervisor, a condición que este último permita a los componentes no privilegiados utilizarlo.

Esta autorización se realiza a nivel del lenguaje de descripción de las dependencias, por la palabra clave "promote". Y de forma más general, las palabras clave siguientes pueden ser asociadas a un componente (en la sintaxis del lenguaje desarrollado por el solicitante, las palabras clave son simplemente prefijadas a la propiedad o procedimiento del cual deben alterar el funcionamiento).

6

Así, la autorización mencionada anteriormente, utilizada por la palabra clave "promote" permite "cortocircuitar" unos niveles de privilegios que han sido establecidos por otra parte, a fin de permitir individualmente el acceso de un componente a otro, al cual su nivel de privilegios no le daría acceso.

\RightarrowLa emigración de threads

El sistema según la invención separa la gestión lógica de un thread de ejecución (identificador, prioridad, pila sistema, etc.) de su gestión física (contexto procesador, pila usuario, espacio de direcciones en el cual el thread está contenido, etc.).

Cuando un componente llama a una función situada en otro espacio de direcciones, y esto de forma asíncrona (el llamador es bloqueado hasta espera del resultado), el llamador "emigra" en el llamado y efectúa el tratamiento.

A este fin, la parte lógica del thread "apila" su parte física actual, y se fija a una nueva parte física creada en el espacio de direcciones del llamado.

El código de la funcionalidad deseada es entonces ejecutado en el contexto del llamado (es decir en el mismo espacio de direcciones y el mismo proceso que contiene), pero en el thread lógico del llamador. Una vez terminada la función, el thread llamador "desapila" su parte física original, y "emigra" de nuevo al llamador.

El código de emigración de threads se encarga también de transmitir los parámetros en los dos sentidos, copiando o reconfigurando las zonas de memorias, las cadenas, etc. proporcionadas como parámetro.

Este mecanismo evita el mucho más costoso procedimiento tradicional que consiste en componer un mensaje, enviar el mensaje a un thread en el componente llamado, suspender el thread del llamador, descomponer el mensaje en el llamado, ejecutar la función deseada, recomponer un mensaje para el resultado, despertar el llamador, suspender de nuevo el llamado.

Esto evita también numerosos problemas ligados al paso síncrono de mensajes, como la inversión de prioridades (aquí, la funcionalidad de llamada se ejecuta con la prioridad del llamador), la contabilización de las fuentes (el tiempo máquina es descontado del llamador), así como la necesidad de mantener un "pool" de threads en el componente llamado, que están dormidos, tomando unos recursos de memoria inútiles, hasta recibir unas llamadas, para a continuación ser insuficientes en número en caso de puntas de llamadas (aquí, los llamadores emigran hacia los llamados, y hay siempre el número exacto de threads necesarios).

Este procedimiento optimiza en gran manera el caso más corriente de llamadas fuera de espacio de direcciones: las llamadas síncronas sobre la misma máquina.

\RightarrowEl paso de mensajes

Contrariamente al caso de sistemas a base de micronúcleo por ejemplo en los cuales es sistemáticamente empleado, este procedimiento es utilizado únicamente para las llamadas que no entran en las categorías anteriores, tales como:

\bullet: llamada local asíncrona (el llamador no queda bloqueado en espera del resultado),

\bullet: llamada distante hacia otra máquina.

El paso de mensajes consiste en codificar los parámetros proporcionados en un mensaje, en dirigir el mensaje hacia el componente destinatario, descodificarlo, ejecutar la función, almacenar el resultado en un mensaje, devuelto hacia el llamador. Este procedimiento está, como se ha mencionado anteriormente, particularmente adaptado a las llamadas asíncronas (el mensaje de resultado es enviado ulteriormente), y a las llamadas distantes, que necesitan la construcción de paquetes de red de todas maneras.

Tomando la descripción realizada con referencia a la figura 6, la creación de un canal de comunicación está asociada a la llamada de la función de registro del componente llamador C1 en la parte implementación del componente C2 llamado.

Esta función, denominada Register() forma parte de la funcionalidad "componente" que es proporcionada por todos los componentes del sistema, además de la función que les es propia. La funcionalidad "componente" comprende cuatro funciones:

\bullet: inicialización,

\bullet: desinicialización,

\bullet: registro,

\bullet: desregistro.

Si ahora el GD determina en 628 que el componente C2 no forma parte del gráfico de los enlaces, llama en 629 al loader de este componente C2 para llevar C2 a la memoria viva de la diana, llamar en 630 las funciones de inicialización de C2 y poner al día el gráfico de los enlaces en 631.

La figura 7 ilustra así el gráfico de los enlaces G, en el cual GD puede importar un componente o un conjunto P2 de componentes del emplazamiento de memoria 72 de un primer loader, a fin de permitir a un componente C1 ya presente en el gráfico de los enlaces (que ha sido previamente importando de la zona de memoria 71 de otro loader con el proyecto P1 del cual forma parte) estar en relación con un componente llamado C2 que ha sido identificado por el GD cuando tiene lugar la etapa 623 de búsqueda en los loaders como que aportan la funcionalidad necesaria para C1.

Se recuerda en efecto que cuando tiene lugar la prueba de integridad efectuada por KBIM en 607 (ver figura 6), KBIM verifica que cada funcionalidad llamada por un componente es ofrecida no estrictamente por un componente de un mismo proyecto, sino de forma más general por un componente cargado en el sistema lógico.

Volviendo también a la figura 6, la etapa 631 desemboca en la etapa 633 ya descrita.

Y si se ha descrito la carga de un componente C2 llamado por un componente C1, se comprende que el componente C1 ha sido a su vez llamado por otro componente, y que ha sido necesario iniciar la llamada de las funcionalidades a la puesta en marcha del sistema.

A este fin, cuando tiene lugar el lanzamiento de una aplicación, el GD solicita una funcionalidad "interacción" y busca un componente que proporcione esta funcionalidad. El GD puede también importar un componente que solicite esta funcionalidad. En todos los casos, la funcionalidad "interacción" llamara otro componente, que a su vez llamara por lo menos otro componente.

\ding{226} El gestor de dependencias

Se ha dicho que el gestor de dependencias es un componente cargado de forma permanente en el sistema según la invención. El mismo permite construir los enlaces entre los diferentes componentes que constituyen una aplicación; estos enlaces son establecidos a partir de las intercaras de los componentes.

Según un aspecto ventajoso de la invención, solamente los componentes útiles para el funcionamiento de la aplicación y del sistema serán cargados, optimizando así los recursos necesarios. Esta optimización puede realizarse según uno de los modos siguientes:

\sqbullet Carga automática de los componentes cuando tiene lugar la ejecución

Cuando un componente es cargado para ser ejecutado, el gestor de dependencias analiza sus dependencias tales como las expresadas en su intercara y busca automáticamente resolver todas las dependencias que están expresadas en el mismo, es decir para proporcionar al componente todas las funcionalidades que necesita, pero también para "cerrar" el sistema de las dependencias buscando así mismo proporcionar a cualquier componente así utilizado las funcionalidades de las cuales tiene a su vez necesidad.

El GD carga entonces automáticamente en el gráfico de los enlaces los componentes que resuelven las intercaras importadas cuya propiedad es "loadtime", resuelve también sus dependencias y crea los canales de comunicación entre estos diferentes componentes, en función de sus emplazamientos respectivos.

Un canal de comunicación puede así ser creado según cualquier modo de comunicación tal como el defendido más arriba; está constituido por cualquier vía de transmisión de datos (específica de cada modo de comunicación) o incluso realizar la llamada de una funcionalidad con los parámetros asociados, y la recuperación del o de los valores de retorno que resultan del tratamiento efectuado por la funcionalidad.

Desde que los canales de comunicación son creados, los componentes puede comunicar directamente entre sí.

\sqbullet Carga y descarga dinámica de los componentes

Cuando una intercara importada tiene la propiedad "runtime", el componente que utiliza esta intercara solicitará la carga del componente que implementa esta intercara, solamente cuando este componente tendrá necesidad de la funcionalidad asociada con la intercara. Esta propiedad "runtime" es así una alternativa de la propiedad "loadtime" ya descrita.

Esta gestión permite determinar precisamente las propiedades de la implementación de la intercara que debe ser cargada, en función de parámetros dinámicos, que no son conocidos cuando tiene lugar la carga del componente que solicita la funcionalidad.

Por ejemplo, un componente "texto" puede importar una intercara codec para descomprimir los ficheros que recibe, pudiendo este componente "texto" recibir varios tipos de ficheros.

Cuando tiene lugar la recepción de un fichero, el componente "texto" puede buscar la intercara codec adaptada para la descompresión de este fichero, en función de su extensión por ejemplo. Para ello, utiliza la funcionalidad Query() del gestor de dependencias, pasándole los parámetros de búsqueda.

Puede a continuación dar la orden al gestor de dependencias, con la ayuda de la funcionalidad Open(), de cargar el componente. Puede entonces utilizar la intercara codec de este componente para descomprimir el fichero.

Cuando ha terminado la descompresión, el componente "texto" puede solicitar la descarga del componente codec utilizado.

Es así posible cargar dinámicamente un componente. Esta posibilidad permite cargar componentes sólo cuando son necesarios para efectuar un tratamiento. El componente puede a continuación ser descargado cuando su tratamiento está terminado.

Según otro ejemplo, una aplicación puede representar una imagen cuando tiene lugar su carga y no tener que tratar a continuación imágenes de este formato, o sólo excepcionalmente.

Esta aplicación puede por tanto cargar dinámicamente el componente de tratamiento del formato de la imagen, solicitarle tratar el fichero para representar la imagen y a continuación descargar este componente. El componente solo es cargado en memoria cuando es estrictamente necesario, lo que permite compartir los recursos de memoria entre los diferentes componentes, en función de tratamientos a realizar en un instante dado.

Este procedimiento permite por tanto reducir considerablemente los recursos de memoria necesarios.

El gestor de dependencias puede también regir automáticamente la carga y la descarga de componentes en función de sus estadísticas de utilización y de los recursos de memoria. Esta gestión resulta entonces completamente transparente para el programador de la aplicación.

El esquema de la figura 8 muestra el interés de la gestión dinámica de los componentes en un sistema que posee pocos recursos de memoria. En este ejemplo, la aplicación representa dos imágenes, una GIF y una JPEG. Cada imagen es tratada de forma secuencial, lo que permite por tanto cargar y descargar los componentes dinámicamente.

En este ejemplo, el hecho de cargar y descargar los componentes dinámicamente permite reducir el recurso de memoria máximo necesario.

Además en la mayor parte de los casos, esta carga y descarga no serán perceptibles en términos de prestaciones.

En efecto, los módulos de componentes tienen un tamaño reducido (del orden de unas centenas de octetos algunos quilooctetos). Su carga en memoria es por tanto una operación que se realiza muy rápidamente. Además, la mayor parte de las aplicaciones efectúan unos tratamientos secuenciales y las informaciones de entrada son a menudo proporcionadas por un usuario humano y las informaciones de salida son proporcionadas al usuario.

Por tanto, a escala humana, los microsegundos que serán necesarios para cargar y descargar un componente, no serán incluso perceptibles; en el caso del ejemplo ilustrado en la figura 8, las operaciones se realizan según la secuencia siguiente:

\bullet carga de una imagen (carga del código de JPEG),

\bullet: representación de esta imagen en la pantalla;

\bullet: carga de otra imagen (descarga del código JPEG y descarga del código GIF),

\bullet: representación de esta otra imagen.

El tiempo de carga y descarga es insignificante con respecto a los otros tratamientos.

\sqbullet Optimización de los recursos por el gestor de dependencias

El gestor de dependencias rige un contador de utilización para cada componente. Este contador cuenta el número de "importadores" del componente, es decir de componentes que importan una funcionalidad del componente al cual el contador esta asociado. Un componente es descargado en cuanto su contador de utilización ha decrecido hasta
0.

Cuando un componente no es utilizado, el gestor de dependencias libera automáticamente los recursos utilizados para este componente.

Se destacará que la invención permite así optimizar de forma particularmente eficaz los recursos utilizados por el sistema, sin pesar sobre el funcionamiento general del sistema.

En efecto, los sistemas conocidos utilizan generalmente unos medios periódicos de verificación del estado de los componentes, siendo dichos medios utilizados por una tarea específica que "toma en mano" periódicamente de forma que identifique los componentes que deben ser descargados.

Dicha tarea periódica de verificación está mal adaptada al tiempo real, puesto que no permite seguir las modificaciones de estado de los componentes con una buena reactividad.

Además, este tipo de funcionamiento impone un entorno multitarea debido a la presencia de la tarea de verificación.

Se encontrara una ilustración de este tipo de funcionamiento que utiliza una verificación periódica del lenguaje Java, utilizando la tarea de verificación un elemento del tipo "garbage del colector".

\sqbullet Precisión sobre las funcionalidades realizadas por un elemento material

Se ha dicho que la parte implementación del componente podía corresponder a un código (que comprende uno o varios programas a fin de cumplir la funcionalidad del componente), pero también a una implementación material por unos elementos de hardware que comprenden unos circuitos electrónicos.

Así, una funcionalidad puede ser realizada por un componente C1 que la implementa utilizando un circuito electrónico (circuito de descompresión vídeo por ejemplo). Pero esta funcionalidad puede también ser realizada por un componente C1 que la implementa totalmente por lógica. Si para una aplicación, el circuito electrónico está presente y funciona correctamente, el sistema utilizará el componente C1. Si, por el contrario, el circuito electrónico no está presente o si no funciona correctamente, el sistema utilizará el componente C1', de forma transparente para los otros componentes. En todos los casos la funcionalidad será realizada.

Así mismo, si una funcionalidad es actualmente realizada por código lógico, la misma podrá ser realizada más tarde por un componente que la implementa utilizando un circuito electrónico, de forma totalmente transparente para los otros componentes.

El esquema de la figura 9 ilustra el reemplazado de un componente C1 por otro componente C'1, que exporta la misma funcionalidad.

Estando C1 en curso de ejecución como se ha indicado en 900, un componente C2 que posee un canal de comunicación con C1 y está así unido en el gráfico de los enlaces solicita en 901 al GD el reemplazado de C1 por C'1.

GD solicita entonces a C1 salvaguardar su estado corriente (etapa 902), lo que C1 realiza en 903. GD carga e inicializa a continuación C'1 (904 y 905).

Si la carga o la inicialización de C'1 no son correctamente efectuadas (etapa 906), el GD devuelve un error el solicitante C2.

Si la carga y la inicialización de C'1 son correctamente desarrolladas, el GD transmite en 908 el estado corriente de C1 a C'1, a fin de que C'1 se ponga en el mismo estado.

A este fin, C'1 interpreta el estado de corriente transmitido (909) y lo acepta o lo rechaza (910).

Si lo rechaza, el GD descarga C'1 (911) y lo desinicializa (912). El GD devuelve a continuación un mensaje de error al solicitante C2 (913 y 914).

Si ahora C'1 acepta el estado corriente de C1, el GD pone al día su gráfico (916) reemplazando en el mismo C1 por C'1. Reconstruye a continuación los canales de comunicación para C'1 (917); estos canales son los que eran utilizados para C1. A continuación el GD desinicializa y descarga C1 (918 y 919).

Siendo efectuado el reemplazado correctamente, GD se informa de ello a C2 (920, 921); éste puede continuar su tratamiento.

Se describe a continuación el principio del sistema según la invención, y su aplicación (entre otras con referencia a la figura 6).

Se precisa que es también posible parametrar la intercara del componente C1 para que, cuando el GD busque un componente que exporta una funcionalidad importada por C1, prosiga su búsqueda en el conjunto de los componentes cargados en el sistema y transmita a C1 una "vista" de cada uno de los componentes del gráfico de los enlaces que exporta esta funcionalidad, en una etapa equivalente a la etapa 627 de la figura 6.

En función de los criterios de elección parametrados, C1 podrá entonces elegir el componente que le conviene entre los identificados por el GD.

Se precisa también que el sistema según la invención necesita en su versión actual cuatro componentes como mínimo para funcionar, como se ha representado en la figura 10a (en la cual las flechas indican las funcionalidades transmitidas entre componentes - este tipo de figura es así una representación del gráfico de los enlaces).

Se trata de los componentes siguientes:

\bullet: "interaction" que como se ha dicho es necesario para iniciar el funcionamiento del sistema,

\bullet: "shuttle" que es llamado por "interaction", y que llama a su vez los dos componentes siguientes:

\bullet: el GD,

\bullet: y finalmente "VMM", llamado componente memoria o de gestión de memoria, que llama también el GD por otra parte.

La figura 10b muestra en cuanto así misma una configuración también mínima del sistema, en la cual tres componentes "CPU", "TIMER" y "SCHED" han sido añadidos a fin de permitir una gestión multi-threads.

Finalmente, la figura 10c representa una configuración enriquecida de un sistema según la invención, que constituye una pequeña aplicación.

En esta figura, el componente "interaction" utiliza un componente "COM" de comunicación para intercambiar unos datos sobre una red y utiliza el componente "GUI" (intercara gráfica) para representar unas presentaciones gráficas.

El componente "RATON" permite regir el periférico RATON. Transmite unas informaciones sobre los cambios de estado de este periférico (desplazamiento, clic sobre los botones). El componente "GUI" utiliza los componentes "WINDOW" y "BUTTON" a fin de realizar las representaciones solicitadas por el componente "INTERACTION".

Los componentes "WINDOW" y "BUTTON" utilizan los componentes codec GIF y JPEG a fin de representar una imágenes en sus zonas de representación respectivas.

Los componentes GUI, COM, WINDOW, BUTTON, GIF y JPEG utilizan también unas funcionalidades de los componentes de base del sistema. Sin embargo, los enlaces que corresponden a estas funcionalidades no están representados en el esquema de la figura 10c a fin de no recargar esta figura.

Los componentes son clasificados en campos, que son unas categorías que no corresponden a un nivel de privilegios, sino a un tipo de utilización. Los diferentes campos son los siguientes, con algunos componentes asociados:

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

(Tabla pasa a página siguiente)

7

Se observará que debido a que todos los componentes del sistema según la invención están realizados según el mismo formato, el sistema rige de la misma manera todos los componentes, y las propiedades ventajosas de los componentes mencionados anteriormente se aplican y de la misma manera a los componentes, cualquiera que sea su nivel de privilegios.

Resulta finalmente que el sistema según la invención permite:

\bullet: a los programadores tener una vista sintética de todos los elementos del sistema de explotación, cualquiera que sea su nivel de privilegios;

\bullet: utilizar las mismas herramientas para crear estos diferentes elementos;

\bullet: realizar unas interconexiones entre las diferentes partes, sin restricción. La potencia del sistema no está expresada por su número de componentes, sino el número de interconexiones posibles, en los sistemas tradicionales (a la vez monolítico y micronúcleo), los medios de comunicación entre los diferentes partes están limitados y fijados. Es preciso pasar sistemáticamente por un cuello de estrangulación arbitrario (estando las llamadas sistemas en número limitado, para el núcleo, ya sea un núcleo monolítico o un micronúcleo, etc.). La gestión de dependencia será la creación dinámica de medios de comunicación permite liberarse de esta limitación,

\bullet: ofrecer unas propiedades iguales a todos los tipos de código. En el caso de la invención, no es en efecto ya necesario concebir un sistema de gestión de módulos núcleo, de bibliotecas, o incluso de "plug-ins" de aplicaciones. Todo ello está reemplazado por el sistema de gestión de los componentes;

\bullet: crear tantos componentes, para el futuro, como funcionalidades que deberán ser cumplidas. Esto permite al sistema según la invención ser totalmente evolutivo.

Además, como se ha visto en la descripción anterior, la invención muestra una gran legibilidad y una reactividad al desarrollador, devolviendo los mensajes de errores en numerosos casos.

En efecto, cuando tiene lugar la carga del componente, una función (Init) es automáticamente ejecutada para este componente. Esta función (Init) verifica que el conjunto de los componentes necesarios para el funcionamiento del componente cargado está por lo menos cargado en el sistema. En el caso en que esta verificación no es satisfactoria (por lo menos una funcionalidad solicitada no es cumplida, o también un componente que ofrece una funcionalidad requerida está asociado a un elemento material defectuoso, etc. ...), un mensaje de error es devuelto al llamador.

Además, en el caso en que un componente llamado está asociado a un elemento defectuoso (materiales y/o lógicos), es automáticamente descargado en la memoria viva del sistema.

Por otra parte, se ha visto con referencia a la figura 9 que unos mensajes de error eran también devueltos cuando tiene lugar la llamada de componentes.

Así, si un elemento material o lógico está ausente o es defectuoso para hacer funcionar un componente llamador, un mensaje de error permite estar al corriente sin necesitar una operación de pruebas completa del sistema.

Claims

1. Procedimiento de desarrollo de proyectos informáticos (P1, P2) destinados a ser utilizados por un sistema informático, procedimiento que comprende una fase de análisis funcional (601) con el fin de censar de nuevo las funcionalidades que deben ser aseguradas, una fase de creación de componentes (C1, C2) del proyecto con la ayuda de medios informáticos para cumplir dichas funcionalidades, una fase de declaración sobre este mismo sistema de los componentes creados cuando tiene lugar la fase de creación, y una fase de carga de dichos componentes en una zona de memoria del sistema para su utilización por el sistema,

caracterizado porque:

\bullet: cuando tiene lugar la fase de creación de componentes, cada funcionalidad es completamente cumplida por el componente que le está asociado,

\bullet: cuando tiene lugar la fase de carga de los componentes, están previstos unos medios (GD) para, en asociación con cada funcionalidad requerida por un componente cargado, buscar automáticamente un componente que ofrezca dicha funcionalidad.

2. Procedimiento según la reivindicación 1, caracterizado porque dicha búsqueda automática se efectúa teniendo en cuenta una condición.

3. Procedimiento según la reivindicación 2, caracterizado porque dicha condición está expresada en función de criterios expresados en función de propiedades asociadas individualmente a cada componente.

4. Procedimiento según una de las reivindicaciones anteriores, caracterizado porque cuando tiene lugar la creación de un componente se procede a las etapas siguientes:

\bullet: creación (602) de un fichero fuente de intercara del componente, con el fin de constituir una parte "intercara" (INT) del componente,

\bullet: creación (603) de por lo menos un fichero fuente de código que permita realizar la funcionalidad del componente, con el fin de constituir una parte "implementación" (IMP) del componente.

5. Procedimiento según la reivindicación 4, caracterizado porque cada fichero fuente de código creado con el fin de constituir una parte "implementación" del componente puede ser elaborado en un lenguaje de programación cualquiera.

6. Procedimiento según una de las dos reivindicaciones anteriores, caracterizado porque cada componente puede cumplir la funcionalidad que le está asociada utilizando unos medios lógicos, y/o materiales.

7. Procedimiento según una de las cuatro reivindicaciones anteriores, caracterizado porque el fichero de intercara de cada componente comprende una descripción de la funcionalidad cumplida por dicho componente, independiente de la manera en que esta funcionalidad es cumplida por el componente.

8. Procedimiento según la reivindicación 7, caracterizado porque el fichero de intercara comprende también una descripción de las funcionalidades que el componente tiene necesidad de importar de otros componentes a fin de cumplir su propia funcionalidad.

9. Procedimiento según una de las reivindicaciones anteriores, caracterizado porque cada componente (C1) puede ser reemplazado dinámicamente por otro componente (C'1) que exporta la misma funcionalidad.

10. Procedimiento según la reivindicación 9, caracterizado porque dicho reemplazado utiliza las etapas siguientes:

\bullet: salvaguarda del estado corriente del componente a reemplazar,

\bullet: carga e inicialización del nuevo componente,

\bullet: transmisión del estado de corriente del componente a reemplazar al nuevo componente,

\bullet: establecimiento de un canal de comunicación entre el componente que llama la funcionalidad y el nuevo componente,

\bullet: descarga del componente a reemplazar.

11. Procedimiento según la reivindicación 10, caracterizado porque si la carga o la inicialización del nuevo componente no es correctamente efectuada, están previstos unos medios para devolver un mensaje de error.

12. Procedimiento según una de las cuatro reivindicaciones anteriores, caracterizado porque cuando tiene lugar la creación de un componente se procede también a las etapas siguientes:

\bullet: creación (604) de un Makefile en el cual están especificados:

\ding{51}: el (los) fichero(s) fuente de código que corresponde a la parte "implementación" del componente,

\bullet: creación (605) de un prototipo del componente,

\bullet: edición de enlaces (606) entre la parte "intercara" y la parte "implementación" del componente, para generar un prototipo de componente ejecutable,

\bullet: utilización del Makefile (609) para compilar el componente individualmente, y constituir un fichero objeto respectivo para el fichero fuente de intercara de la parte "intercara" del componente así como para el o cada fichero fuente de código de la parte "implementación" del componente,

\bullet: encapsulación (610) de los ficheros objeto creados cuando tiene lugar la etapa anterior en un módulo ejecutable único.

13. Procedimiento según la reivindicación 12, caracterizado porque cuando tiene lugar la creación del prototipo de un componente se crea un prototipo que comprende:

\bullet: una intercara objeto resultante de la compilación del fichero fuente de intercara del componente,

\bullet: un fichero objeto prototipo para cada fichero fuente de código de la parte "implementación" del componente.

14. Procedimiento según la reivindicación 13, caracterizado porque cuando tiene lugar la compilación del fichero fuente de intercara del componente, se procede a:

\bullet: el análisis y la verificación de la coherencia del fichero fuente de la intercara,

\bullet: la traducción de fichero fuente de la intercara en datos binarios,

\bullet: la generación automática de por lo menos un fichero para llamar las funcionalidades que deben ser importadas por el componente.

15. Procedimiento según una de las tres reivindicaciones anteriores, caracterizado porque después de la etapa de edición de enlaces entre la parte "intercara" y la parte "implementación" del componente para generar un prototipo de componente ejecutable, se procede a una etapa (607) de prueba de integridad automática cuando tiene lugar la cual se verifica que el proyecto es coherente y cerrado.

16. Procedimiento según la reivindicación 15, caracterizado porque cuanto tiene lugar la prueba de integridad automática, para cada funcionalidad necesaria al proyecto se busca automáticamente, entre una lista de componentes accesibles, un componente que cumpla dicha funcionalidad.

17. Procedimiento según la reivindicación 16, caracterizado porque en el caso en que se identifican varios componentes que cumplen la funcionalidad solicitada, se puede elegir entre estos componentes un componente particular.

18. Procedimiento según una de las dos reivindicaciones anteriores, caracterizado porque en el caso en que la prueba de integridad revele que el proyecto no está correctamente cerrado, se edita un mensaje de error que indica las incoherencias para poder modificar ciertos componentes y/o añadir alguno.

19. Procedimiento según una de las siete reivindicaciones anteriores, caracterizado porque para cada componente cargado en el sistema, la descripción de las funcionalidades que el componente tiene necesidad de importar otros componentes a fin de cumplir su propia funcionalidad es accesible de forma permanente a dichos medios (GD) de búsqueda automática de componente.

20. Procedimiento según una de las ocho reivindicaciones anteriores, caracterizado porque cuando tiene lugar la encapsulación (610) de los ficheros objeto creados cuando tiene lugar la etapa anterior en un módulo ejecutable único, se verifica que todas las funcionalidades proporcionadas por las diferentes partes de intercara del proyecto han sido efectivamente descritas totalmente en un fichero fuente asociado, y compiladas.

21. Procedimiento según una de las nueve reivindicaciones anteriores, caracterizado porque el procedimiento comprende la memorización, en una zona de memoria viva del sistema, de una cartografía (G) de los componentes cargados en el sistema.

22. Procedimiento según la reivindicación 21, caracterizado porque dicha cartografía está destinada a ser consultada cuando tiene lugar la llamada de una funcionalidad por un componente llamador, para determinar si un componente de dicha cartografía es apto para proporcionar la funcionalidad llamada.

23. Procedimiento según la reivindicación 22, caracterizado porque son dichos medios (GD) de búsqueda automática del componente que son aptos para consultar dicha cartografía.

24. Procedimiento según una de las tres reivindicaciones anteriores, caracterizado porque dicha cartografía es puesta al día en tiempo real cuando tiene lugar el funcionamiento del sistema, en función de los componentes cargados en el sistema.

25. Procedimiento según una de las reivindicaciones anteriores, caracterizado porque cada componente puede estar asociado a un nivel de privilegios que condiciona las posibilidades de acceso del componente a otros componentes, en función de los niveles de privilegio respectivos de dichos otros componentes.

26. Procedimiento según una de las reivindicaciones anteriores, caracterizado porque están previstos unos medios para descargar automáticamente cada componente cuya funcionalidad no es ya necesaria para el funcionamiento de los proyectos informáticos.

27. Procedimiento según la reivindicación 26, caracterizado porque dichos medios comprenden un contador de utilización para cada componente.

28. Procedimiento según la reivindicación 27, caracterizado porque dicho contador cuenta el número de componentes que importa una funcionalidad del componente al cual el contador está asociado, y dicho componente es descargado en cuanto su contador de utilización a decrecido hasta cero.

29. Procedimiento según la reivindicación 28, caracterizado porque están previstos unos medios (GD) para liberar automáticamente los recursos utilizados para dicho componente descargado.