WO2013038036A1 - Método de modelado para la gestión de configuraciones en sistemas de información - Google Patents

Abstract

Método de modelado para la gestión de configuraciones en sistemas de información que comprende una etapa de meta-modelado de comportamiento (104) y de meta- modelado estructural (102) que determinan los conceptos de comportamiento y estructurales que se pueden usar y seguir para construir un modelo; y donde a través del meta - modelo de comportamiento (104) se modela el comportamiento (114) de los sistemas en base a su funcionalidad, que viene determinada por sus características, mientras que el modelo estructural (112) derivado del meta - modelo estructural (102) especifica aquella parte de la configuración del sistema o sistemas que no forman parte de su comportamiento; todo ello de tal forma que la combinación de ambos modelos (112,114) da lugar al comportamiento modelado (122) de uno o varios dispositivos; y que se caracteriza porque tanto el modelado estructural (112) como el de comportamiento (114) se realizan en base a un proceso de refinado secuencial que se compone de varias etapas de modelado partiendo de un modelo inicial (202).

Description

MÉTODO DE MODELADO PARA LA GESTIÓN DE CONFIGURACIONES EN

SISTEMAS DE INFORMACIÓN

La presente invención se encuadra en el sector técnico de los métodos y sistemas para la gestión y modelado de las configuraciones en distintos sistemas de información.

ESTADO DE LA TÉCNICA ANTERIOR

La gestión de configuraciones en sistemas de información consiste en la obtención de un inventario de los sistemas a gestionar, la obtención de su configuración, si ésta existe, su posible modificación, su desplegado, e incluso posibles migraciones entre sistemas de distintos fabricantes, pero dentro de una misma familia.

Una configuración es el conjunto de parámetros y reglas que define el comportamiento de uno o varios sistemas. Por ejemplo, una única configuración puede regir el comportamiento de un único sistema, o de varios. En muchas ocasiones, en la configuración hay que tener en cuenta el entorno donde éstas se despliegan, como sistemas físicos, sistemas operativos, servicios disponibles, conexiones de red entre sistemas y otros. De cara a definir el comportamiento global de un conjunto de sistemas, se pueden combinar varias configuraciones, relacionadas o no entre sí.

Un sistema de información puede ser tanto un software (como un ERP, por ejemplo) como un dispositivo que ejecuta un software (como un router). Por otro lado, una familia de sistemas de información es un conjunto de sistemas o productos que persiguen el mismo objetivo y con los que se pueden realizar tareas similares, es decir, que tienen una funcionalidad similar. También se suele denominar línea de productos. Ejemplos de estas familias son los firewalls, switches, routers, sistemas de gestión de bases de datos, ERP, etc. Así pues, los sistemas dentro de una misma familia suelen ofrecer exactamente la misma funcionalidad unos respecto de otros, o bien una funcionalidad con escasas diferencias.

Finalmente, en la presente memoria descriptiva se entenderá por característica, el reflejo de una o varias funcionalidades que puede ofrecer uno o varios sistemas de una misma familia de sistemas.

En general, la gestión de la configuración de los sistemas de información es muy compleja. Durante el proceso de configuración intervienen muchos aspectos, tales como las reglas de negocio, la complejidad del sistema, la red de interconexión, el soporte y la información que ofrece el fabricante, la habilidad y formación de las personas que intervienen en el proceso, el software de apoyo que se utiliza, etc. Hoy en día, la complejidad de los sistemas y redes que los interconectan es muy elevada, tanto en su estructura como su funcionalidad, y se prevé que durante los próximos años esta complejidad aumente mucho más. Entre los sistemas que forman una misma familia pueden existir grandes diferencias en cuanto a la sintaxis del lenguaje que se utiliza para configurarlos, el número de parámetros de configuración, la semántica de las operaciones y de los parámetros de configuración, las diferencias en hardware que pueden provocar diferencias en la gestión de la configuración del sistema, especialmente si son sistemas ofrecidos por distintos fabricantes, etc. Dentro de un mismo fabricante, los cambios suelen ser de menor calado para sistemas de la misma familia, aunque las diferencias suelen ser más acusadas entre sistemas de gamas diferentes, o entre sistemas más antiguos respecto de los más modernos. Hoy en día, además, suelen coexistir diferentes familias de sistemas, donde dentro de cada familia existirán sistemas de diferentes fabricantes, y donde para cada fabricante pueden existir diferentes versiones de sistemas o productos.

A consecuencia de esta situación tan compleja, los técnicos que se encargan de la gestión de sistemas suelen estar especializados en la gestión de determinadas familias de sistemas, siendo habitual que sean expertos en gestión de productos de determinados fabricantes. Por ejemplo, en una empresa suelen existir técnicos para gestionar bases de datos, para gestionar ERP, para gestionar firewalls y otros dispositivos de red similares como routers y switches. Estos técnicos suelen ser personas diferentes y su conocimiento tecnológico de la familia de sistemas no es transferible a otras familias diferentes, debido a las grandes diferencias de funcionalidad existentes entre ellas. Sin embargo, la experiencia y conocimiento en la gestión de un sistema o producto dentro de una determinada familia sí que podría ser útil para otros sistemas dentro de la misma familia.

Por ejemplo, un experto en firewalls del fabricante Cisco® podría utilizar sus conocimientos para gestionar otros firewalls de otros fabricantes diferentes, aunque para ello tendrá que conocer las características específicas de los otros fabricantes, la sintaxis del lenguaje que se utiliza para configurarlo, el número de parámetros de configuración, la semántica de las operaciones y de los parámetros de configuración, las diferencias en hardware que pueden provocar diferencias en la gestión de la configuración, etc. Esta situación es la que produce que, en la práctica, un experto en un producto de un determinado fabricante de una familia, no pueda gestionar la configuración de otros productos de la misma familia (pero de otros fabricantes) con los conocimientos que ya posee sobre uno de los fabricantes. Es decir, se impide la reutilización de conocimientos. Esta situación se agrava aún más cuando dentro de un mismo fabricante, existen también diferencias debidas a las diferentes versiones de los productos. Las diferencias más habituales en este sentido suelen darse en productos con diferentes versiones de software y/o con diferencias de hardware significativas.

A estas dificultades hay que sumarle el hecho de que estas configuraciones suelen realizarse en base a determinados requisitos funcionales, no funcionales y de información. Estos requisitos, en muchos casos no vienen especificados por escrito, pueden darse ambigüedades, redundancias y contradicciones fácilmente, y suelen tener mucha variabilidad a lo largo del tiempo. La transformación desde estos requisitos a una configuración determinada no es un proceso sencillo, ya que suelen venir descritos a través de reglas de negocio (es decir, en un lenguaje no técnico) y deben trasladarse por un técnico a un sistema o un conjunto de sistemas que implementarán dichos requisitos. Es frecuente también que unos requisitos interactúen con otros, y que la modificación de uno de ellos implique la de otros. Así, las ambigüedades que podrían tener estas reglas de negocio serían transferidas directamente a las configuraciones. Por otra parte, durante la configuración de los sistemas, podrían darse nuevas ambigüedades, redundancias y contradicciones, que se sumarían a las anteriores. Como consecuencia de este proceso desligado, largo, complejo y costoso, las configuraciones de sistemas suelen contener fallos que podrían provocar diferentes tipos de errores, como por ejemplo de funcionamiento o de seguridad.

Si bien existen métodos que permiten gestionar sistemas de información dentro de una misma familia de forma genérica, especialmente en el ámbito de la gestión de configuración para dispositivos de interconexión de redes, estos métodos suelen tener como punto de partida un modelo muy complejo que ofrece todos los conceptos necesarios para modelar configuraciones de cualquier sistema de la familia, e incluso de varias familias similares, como por ejemplo routers y firewalls conjuntamente. Esto se define como un modelo maximal.

Un modelo se define como una representación abstracta de la estructura de un sistema o conjunto de sistemas, de una funcionalidad, de un comportamiento o de cualquier combinación entre ellos. Sin embargo, al ofrecerse un modelo tan complejo, muchos de sus conceptos podrían no usarse en la mayoría de las ocasiones por el técnico modelador, por ejemplo, porque sean conceptos muy específicos para un sistema de un fabricante determinado y que tienen una frecuencia de uso muy baja. Esta situación complicaría la tarea de modelado a la vez que no permitiría la intervención en el proceso a personas con un perfil menos técnico. Además, al ofrecer todos los conceptos en una única etapa de modelado, podría ocurrir el caso de que alguno de ellos no tuviera una correspondencia para un sistema determinado dentro de la familia, por lo que la configuración modelada no podría desplegarse en él, pudiendo producir inconsistencias entre el modelo y la configuración real. La solución más habitual para este caso suele ser modelar por separado los diferentes sistemas dentro de una familia y todas sus versiones, para poder ofrecer al técnico modelador la posibilidad de elegir el sistema a modelar al inicio del proceso de modelado de entre los modelos existentes en un repositorio. Aunque esta solución alivia bastante la complejidad del proceso de configuración, suele producir como efecto lateral que las configuraciones sean poco portables entre sistemas dentro de la misma familia, a la vez que el técnico modelador aún necesite tener conocimiento del sistema concreto (fabricante, versión del producto, etc.) para el que va a modelar la configuración.

Se localizan ejemplos de métodos como los indicados en los documentos US2010/0146095, US6349306 y WO2011/047733. En estos documentos, básicamente, se propone una arquitectura top-down donde en el primer nivel de abstracción existe un modelo maximal, presentando el inconveniente de que hay conceptos en el modelado que no se comparten entre sistemas y, por tanto, no se define qué hacer con ellas a la hora de generar las configuraciones. Por esta misma razón es complicado realizar migraciones entre sistemas diferentes.

Por otro lado, en US2010/0146095 además se propone el modelado de sistemas incluyendo modelos de lenguajes. Por tanto, es necesario tener repositorios de estos modelos, aumentándose el número de modelos necesarios y las transformaciones entre ellos.

Por estas razones, se necesita un método que permita intervenir en el proceso de modelado de configuración a personas con diferentes perfiles (más o menos técnicos), que los conceptos ofrecidos estén adaptados a todos los perfiles de personas que intervengan en el modelado, que ofrezca unos conceptos que sean homogéneos para todos los sistemas dentro de una familia, que permita diagnosticar diferentes tipos de fallos en los modelos, que haga los modelos portables entre diferentes sistemas dentro de una misma familia de cara a automatizar migraciones, y que pueda desplegar los modelos automáticamente sobre sistemas reales en diferentes entornos de desplegado. De esta manera, se pueden construir aplicaciones informáticas y dispositivos que reduzcan más el coste de gestión de configuración de sistemas de información.

EXPLICACIÓN DE LA INVENCIÓN

En el método de modelado para la gestión de configuraciones en sistemas de información, objeto de la presente invención, se parte de una arquitectura bottom - up, donde se parte de un modelo minimal, al que se van añadiendo conceptos en función de los distintos criterios, incluyendo la información de las plataformas que hay en realidad, de cara a guiar el proceso de modelado y así poder elegir conceptos específicos para ellas o no, a discreción del modelador, en función del grado de reutilización que quiera obtener de los modelos.

Así pues, a diferencia del estado de la técnica conocido, la presente invención proporciona un método para gestionar configuraciones de cualquier tipo de familia de sistema de información, donde entre los sistemas dentro una familia pueden existir diferencias en cuanto a la sintaxis del lenguaje que se utiliza para configurarlos, el número de parámetros de configuración, la semántica de las operaciones y de los parámetros de configuración, las diferencias en hardware que pueden provocar diferencias en la gestión de la configuración del sistema, la funcionalidad que ofrecen, etc.

Entre otras cosas, la presente invención facilita la intervención en el proceso de configuración a personas con diferentes perfiles, desde personas con roles de negocios, hasta personas con roles técnicos muy especializados.

La presente invención también facilita la interoperabilidad entre sistemas de la misma familia en cuanto a su a configuración se refiere, de manera que un modelo de configuración pueda transformarse en una configuración específica para un sistema de la familia, y que ésta pueda desplegarse en él de acuerdo a los lenguajes, parámetros y reglas que el fabricante del sistema establezca.

Así mismo, una configuración existente y ya desplegada en un sistema puede ser modelada con la presente invención a través de una importación y, una vez modelada, puede ser transformada en una configuración para otro sistema (posiblemente de un fabricante diferente) de la misma familia con idéntico comportamiento, ya que éste ha sido modelado, facilitando así la migración de configuraciones existentes. La presente invención también permite el diagnóstico del modelo en base a diferentes criterios (consistencia, no redundancia, etc.), de manera que se puedan detectar, identificar, caracterizar y corregir fallos antes del despliegue de las configuraciones en los sistemas.

Para ello, y en un primer aspecto de la invención, el método de modelado para la gestión de configuraciones en sistemas de información comprende una etapa de meta- modelado de comportamiento y de meta-modelado estructural que determinan los conceptos de comportamiento y estructurales que se pueden usar y seguir para construir un modelo; y donde a través del meta - modelo de comportamiento se modela el comportamiento de los sistemas en base a su funcionalidad, que viene determinada por sus características, mientras que el modelo estructural derivado del meta - modelo estructural especifica aquella parte de la configuración del sistema o sistemas que no forman parte de su comportamiento; todo ello de tal forma que la combinación de ambos modelos da lugar al comportamiento modelado de un dispositivo; y que se caracteriza porque tanto el modelado estructural como el de comportamiento se realizan en base a un proceso de refinado secuencial que se compone de varias etapas de modelado partiendo de un modelado inicial.

Se ha de tener en cuenta que cada etapa de modelado se corresponde con un nivel de abstracción diferente, representando este nivel de abstracción la ligadura respecto del sistema real. Por otro lado, el modelo inicial es conforme a su meta - modelo inicial el cual comprende los conceptos mínimos necesarios para modelar el comportamiento común de los sistemas que forman parte de una familia de sistemas, representando el nivel de abstracción más alto de todas las etapas de modelado.

Cabe indicar, además, que el refinamiento en el modelo se consigue a través de los nuevos conceptos que ofrecen los meta - modelos de las etapas sucesivas, de manera que al primer meta - modelo se le añaden los conceptos del segundo meta - modelo a través de operaciones de herencia, composición, unión, intersección o cualesquiera otra que se determine.

A lo largo de la descripción y las reivindicaciones la palabra "comprende" y sus variantes no pretenden excluir otras características técnicas, aditivos, componentes o pasos. Para los expertos en la materia, otros objetos, ventajas y características de la invención se desprenderán en parte de la descripción y en parte de la práctica de la invención. Los siguientes ejemplos y dibujos se proporcionan a modo de ilustración, y no se pretende que sean limitativos de la presente invención. Además, la presente invención cubre todas las posibles combinaciones de realizaciones particulares y preferidas aquí indicadas.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

FIG 1.- Esta figura ilustra los elementos principales que intervienen en el modelado de configuraciones de sistemas de una familia.

FIG 2.- En esta figura se presenta un esquema de las etapas de modelado que forman parte del proceso de múltiples refinamientos. Se incluyen diferentes tipos de transformaciones, así como los meta-modelos correspondientes .

FIG 3.- Esta figura representa una posible agrupación de las características de una familia de sistemas cualquiera.

FIG 4.- En esta figura se ilustra un ejemplo de aplicación de una agrupación de características de una familia de firewalls que consiste en dos sistemas. Esta agrupación sigue el mismo esquema del ejemplo genérico de la Figura 3.

FIG 5.- Esta figura ilustra un ejemplo de aplicación del esquema de modelado propuesto en la presente invención para una característica de una familia de firewalls que se compone de dos sistemas.

EXPOSICIÓN DETALLADA DE UN MODO DE REALIZACIÓN Y EJEMPLOS

En el proceso de modelado de configuraciones intervienen dos elementos principales (Fig.l): un meta-modelo de comportamiento (104) y un meta-modelo estructural (102).

Un meta-modelo determina los conceptos que se pueden usar y las reglas que se deben seguir para construir un modelo. Por tanto, un modelo siempre será conforme a su meta-modelo. A través del meta-modelo de comportamiento (104) se puede modelar el comportamiento (114) de los sistemas en base a su funcionalidad, que viene determinada por sus características. Por ejemplo, si los sistemas son fírewalls, se modelarán las reglas de control de acceso, de traslación de direcciones, registro de reglas, etc., entre los diferentes sistemas que forman la red.

Con el meta-modelo estructural (102) se pueden construir modelos (112) que especifiquen aquella parte de la configuración del sistema o sistemas que no formen parte de su comportamiento, como el fabricante, sistema operativo, el entorno de desplegado, las relaciones entre ellos (físicas y lógicas), etc. Volviendo al ejemplo de los fírewalls, se modelará la topología de la red (las conexiones entre segmentos de red, clasificación del nivel de seguridad de zonas, etc.) y la configuración del sistema operativo de cada sistema (interfaces de red, pilas de protocolos de comunicaciones, etc.). La combinación de estos dos modelos produce las configuraciones específicas para los sistemas del modelo estructural, de manera que se pueda cumplir con el comportamiento modelado (122).

Tanto el modelado estructural como de comportamiento se realizan en base a un proceso de refinamiento secuencial que se compone de varias etapas de modelado (FIG.2) partiendo de un modelo inicial (202).

Cada etapa de modelado puede ser un nivel de abstracción diferente o no, siendo habitual lo primero. El nivel de abstracción representa la ligadura respecto al sistema real: mientras más abstracto es un modelo, más independiente es de los sistemas reales. Como todos los modelos, este primer modelo también es conforme a su meta- modelo (262). Este meta-modelo suele ofrecer los conceptos mínimos necesarios para modelar el comportamiento común de los sistemas que forman parte de una familia de sistemas, incluso a nivel de reglas de negocio. Representa el mayor nivel de abstracción de todas las etapas de modelado. Así, este primer modelo podría ser construido por personas con perfil poco técnico o de negocio.

En función de las necesidades de modelado (funcionalidad que se desea modelar) y del conocimiento del entorno tecnológico del técnico modelador, este primer modelo se irá refinando. El refinamiento se consigue a través de los nuevos conceptos que ofrecen los meta-modelos de las etapas sucesivas, de manera que al primer meta- modelo (262) se le añaden los conceptos del segundo (264) a través de operaciones como pueden ser la herencia, composición, la unión, la intersección, o cualquier otra.

A continuación, el primer modelo (202) se transforma a un segundo modelo (204) mediante reglas de transformación modelo a modelo (222). Este segundo modelo ya se puede refinar a través de los nuevos conceptos disponibles en su nuevo meta- modelo (264). La manera de pasar de un modelo (modelo origen) hasta otro (modelo destino) es a través de transformaciones. Ambos modelos deben ser conformes a un meta-modelo, que puede ser el mismo o no, dependiendo de si el nivel de abstracción de los modelos origen y destino es el mismo, o no.

Las transformaciones se describen a través de lenguajes de transformación que también deben ser conformes a su propio meta-modelo (no se han incluido en la figura 2 para mejorar su legibilidad). Normalmente, las transformaciones se definen sobre meta-modelos. Por ello, una transformación necesita como entrada (al menos) un modelo, el meta-modelo al que es conforme, el meta-modelo del modelo de destino, y la definición de la transformación, devolviendo como salida un modelo o un conjunto de ellos.

Una transformación se considera modelo a modelo (M2M) si toma como entrada uno o un conjunto de modelos y produce como salida uno o un conjunto de modelos. Sin embargo, si el resultado es un conjunto de artefactos textuales o una implementación, se denomina transformación modelo a texto (M2T). De esta forma es como, por ejemplo, se realizan las transformaciones en la metodología Model-Driven Architecture (MDA) del Object Management Group (OMG), que puede utilizarse para una implementación de la presente invención, existiendo otras metodologías igualmente válidas.

De manera secuencial, el refinamiento se repite mientras queden niveles de modelado de refinamiento. El número de niveles de modelado de refinamiento depende del modelado que se haga de las características de cada familia de sistemas, no existiendo un número fijo de niveles. Así, a través de una de las últimas transformaciones M2M (224) se obtiene el último modelo de refinamiento (206), conforme a su meta-modelo (266), y que define un comportamiento global e independiente del modelo estructural.

Este meta-modelo (266) ofrecerá una gran cantidad de conceptos para modelar en comparación con el primer meta-modelo (262). En este punto, se incluye el modelo estructural (252) que también será conforme a su meta-modelo (254). En el modelo estructural (252) se especifica aquella parte de la configuración del sistema o sistemas que no forma parte de su comportamiento, como por ejemplo el número de sistemas disponibles para el desplegado de la configuración, los fabricantes de los sistemas, tipos y versiones de sistemas operativos, las relaciones entre los sistemas (físicas y lógicas), disponibilidad de cada sistema, limitaciones software y hardware de cada sistema, etc. También en él se pueden especificar aquellos parámetros que puedan guiar las transformaciones (226 a 230) hacia los modelos de configuración individuales (208 a 212), como por ejemplo preferencias para elegir ciertos sistemas de entre todos los disponibles, reglas para la asignación de configuraciones, etc. El modelo estructural se puede construir a través de un proceso similar al descrito para el modelo de comportamiento, o por otro proceso de modelado, y debe especificar al menos un sistema donde desplegar el modelo de comportamiento.

Al incluirse el modelo estructural (252) durante estas últimas transformaciones M2M (226 a 230), se pueden generar diferentes modelos de configuración individuales y específicos para los sistemas especificados en el modelo estructural (208 a 212). En la figura 2 se han incluido sólo tres, pero deberán existir tantas transformaciones como sistemas existan en la familia y, en un ejemplo de aplicación, se usarán tantas transformaciones como sistemas diferentes se usen del modelo estructural.

En su conjunto, los modelos de configuraciones individuales definen el mismo comportamiento que el último modelo de refinamiento (206). Estos modelos de comportamiento individuales también son conformes a sus respectivos meta-modelos (268 a 272), y por tanto, podrían retinarse también en este nivel de modelado. Nótese que en este nivel de modelado, los meta-modelos pueden incluir conceptos que estén relacionados con características totalmente específicas de un sistema concreto de la familia. Finalmente, estos modelos individuales (208 a 212), se transforman en configuraciones específicas (242 a 246) para un sistema concreto a través de sus respectivas reglas de transformación M2T (232 a 236). Estas configuraciones implementan los modelos de configuración individuales, y suelen incluir no sólo aspectos relacionados con el comportamiento del sistema, sino también aquellos aspectos necesarios para el desplegado de la configuración (tales como configuración de interfaces de red, de servicios auxiliares, etc.). Por ejemplo, un modelo de configuración podría consistir en las de control de acceso de un firewall, pero también en la configuración del sistema operativo y del dispositivo donde el firewall correrá, de manera que pueda hacerse el despliegue no sólo del servicio (firewall), sino de todo el sistema, a partir del modelo y de manera automática. Estas transformaciones también pueden incluir optimizaciones que permitan obtener la configuración de la forma más óptima para un sistema determinado. Una optimización podría ser por ejemplo, utilizar pocas instrucciones en vez de muchas para definir un comportamiento determinado para reducir el consumo de CPU y de memoria del sistema. Las optimizaciones que puedan realizarse dependerán de las características de cada sistema de la familia y también de cada familia en sí misma. Así, el técnico modelador podría elegir diferentes preferencias a la hora de realizar optimizaciones, como eficiencia energética, menor consumo de memoria, menor consumo de CPU... e incluso varias de ellas a la vez. Estas preferencias se pueden establecer, por ejemplo, a través de parámetros de entrada a las transformaciones M2T o a través de un nuevo modelo que tomen estas transformaciones. De nuevo, este modelo puede hacerse por una persona con un perfil diferente del resto de los técnicos modeladores. En cualquier caso, las configuraciones resultantes de las transformaciones M2T (232 a 236) pueden ser interpretadas directamente por los sistemas reales, de acuerdo a los lenguajes, parámetros y reglas que el fabricante de cada sistema haya establecido.

Según este proceso, existirá un meta-modelo inicial, cero o más meta-modelos de refinamiento, al menos una transformación M2M entre cada dos meta-modelos de refinamiento consecutivos (transformaciones 1 :1), uno o más meta-modelos de configuración de sistemas específicos, una transformación desde el último meta- modelo de refinamiento a cada meta-modelo de configuración de sistema (transformación 1 :m), y una transformación M2T desde cada uno de los meta-modelos de configuración a un sistema real (transformaciones 1 :1). Nótese que a través de este proceso de modelado se independiza el modelo de comportamiento del estructural. La consecuencia más directa de este hecho es que un mismo modelo de comportamiento puede desplegarse en modelos estructurales diferentes sin que por ello deban cambiar los modelos de comportamiento realizados, siempre que las características modeladas se ofrezcan en los sistemas de los modelos estructurales donde se vaya a realizar el desplegado.

El proceso de modelado descrito, aunque facilita mucho la configuración de sistemas, no puede garantizar la ausencia de fallos en las configuraciones de diferente índole, ya que estos fallos se pueden cometer en cualquiera de las etapas de modelado. Sin embargo, se pueden usar técnicas de validación y diagnosis de cara a identificar y corregir estos fallos antes del desplegado de configuraciones y de la forma más temprana posible. La validación consiste en averiguar si el modelo está bien construido o no (por ejemplo, su corrección) y suele utilizarse para su estructura y semántica; mientras que la diagnosis consiste en dar una explicación de por qué un modelo no está bien construido. La diagnosis suele ser una etapa mucho más compleja que la validación, y suele incluir a la validación. Al igual que la validación, la diagnosis se puede utilizar para buscar explicaciones a diferentes problemas, como por ejemplo inconsistencias y redundancias en los modelos. Las etapas de validación y diagnosis se pueden ejecutar en cada etapa de modelado, y a medida que se crean los modelos (online) o una vez se han creado (offline). El diagnóstico temprano de fallos mejora la calidad de las configuraciones resultantes, reduce el tiempo dedicado al testado y por tanto el coste del ciclo de desarrollo. Estas etapas no se han incluido en la figura 2 de cara a mejorar su legibilidad.

Téngase en cuenta que el proceso propuesto en la figura 2 puede ser modificado, por ejemplo, añadiendo o modificando niveles de modelado, introduciendo nuevos modelos como entrada a las transformaciones, cambiando el orden de las etapas, y reduciendo o aumentando el número de etapas de validación y/o diagnosis o cambiando su lugar. Por ejemplo, es posible que durante el proceso de modelado no se necesiten conceptos de algunos de los niveles de refinamiento. De hecho, también sería posible que, de todos los conceptos que ofrece un meta-modelo, no se usen todos para especificar comportamiento. En estos casos, aunque las transformaciones se ejecuten, el técnico modelador puede decidir no especificar nada nuevo en los modelos. De esta forma, es posible evitar todos o algunos de los niveles de modelado. También sería posible volver a niveles de modelado anteriores si fuera necesario. Por otra parte, es posible que sea necesaria la incorporación del modelo estructural en las transformaciones M2M de entre cualesquiera dos modelos, para por ejemplo, limitar los conceptos que se pueden usar de entre los que ofrecen los meta-modelos, en función de las características que ofrecen los sistemas disponibles, su forma de conexión, y en general en función de cualquier concepto que forme parte del modelo estructural.

Los conceptos ofrecidos por cada meta-modelo en cada uno de los niveles de abstracción o modelado suelen depender de las características de los sistemas de una determinada familia, ya que las características son reflejos de las funcionalidades de sistemas reales. A mayor número de características en un sistema, más comportamiento se podrá modelar y por tanto más ricos serán los meta-modelos. Un conjunto de sistemas forma parte de la misma familia porque los sistemas suelen ofrecer exactamente las mismas características de unos respecto de otros, o bien características similares con pequeñas diferencias. Las diferencias mayores suelen venir en cuanto a la forma de configurarlos: lenguajes que se utilizan, interfaces, sintaxis y semántica de sus operaciones, etcétera, aun cuando todos los sistemas de la familia ofrezcan funcionalidades idénticas. Así, si la funcionalidad de un sistema se divide en características (figura 3), lo habitual es que éste tenga un conjunto mayoritario de características (302) que se comparte con otros sistemas de la misma familia, un segundo conjunto de características que se diferencian minoritariamente de las de otros sistemas (304), e incluyan un tercer conjunto de características que es exclusivo para un determinado sistema de la familia (306), aunque pueden existir muchas más variantes.

Todas estas características resumen la funcionalidad total que el sistema puede ofrecer. Así, dada una familia de sistemas, se puede modelar mediante características la funcionalidad que ofrecen todos sus sistemas. En la figura 4 se muestra un ejemplo donde se han agrupado las características para una familia de firewalls, y donde existen sólo dos sistemas en ella: IPTables y Cisco PIX en cualesquiera versiones. En este ejemplo, existe un conjunto donde se recogen las características comunes a los dos sistemas (402), otro donde hay características con pequeñas diferencias (404), y dos conjuntos más (406,408) donde se recogen las características que son específicas para IPTables y Cisco PIX respectivamente.

En la figura 4 existen algunas características que están en diferentes grupos al mismo tiempo. Esto es frecuente en aquellas características que tienen una parte que cumple el criterio que se ha establecido para la agrupación, y otra parte que no lo cumple. En este caso, la característica "filtrado de paquetes" tiene una parte común a los dos sistemas (402), pero otra parte que es específica para cada uno de los sistemas (406,408).

Si este ejemplo se extrapola a una gran familia con muchos sistemas de muy diversos fabricantes, y muchas versiones entre sistemas, la abstracción necesaria para poder llegar a una agrupación por características de este tipo requiere un gran esfuerzo. Nótese que, en el ejemplo, la agrupación se ha regido por un criterio de exclusividad, pero existen otros criterios que se pueden utilizar para agrupar las características de los sistemas, tales como por ejemplo la frecuencia de uso de las características, la similitud entre ellas, complejidad relativa, etc. e incluso varios criterios a la vez. Una vez se tiene la agrupación de características de la familia, hay que decidir qué conceptos o primitivas se ofrecerán en cada nivel de modelado o abstracción de los disponibles en la presente invención (figura 2) de cara a modelar estas características. Cada nivel de modelado puede ofrecer los conceptos necesarios para modelar una característica completa, fragmentos de características (de una o de varias), un conjunto de características, o cualquier otra variante. Las características modeladas dentro de un mismo nivel de abstracción pueden estar relacionadas entre sí o no estarlo, al igual que las que se modelan en varios niveles de abstracción pueden estar relacionadas o no. De esta forma, para modelar un comportamiento determinado, puede ser necesaria la utilización de conceptos en diferentes niveles de abstracción. Los conceptos utilizados modelarán diferentes características o fragmentos de ellas. El objetivo de los modelos de refinamiento de la presente invención (204 a 206) es precisamente permitir fácilmente estas operaciones. Así, mediante múltiples refinamientos se pueden combinar diferentes modelos parciales de una característica hasta obtener el modelo del comportamiento deseado.

La decisión de qué conceptos se ofrecen en cada nivel de abstracción puede venir determinada en base a varios criterios (uno o la combinación de varios), como ocurría con la agrupación por características. Ejemplos de estos criterios pueden ser si una determinada característica completa se comparte por todos los sistemas dentro de la familia o no (exclusividad), la complejidad de una característica (puede ser necesario el uso de varios conceptos para modelarla), la frecuencia de uso de una característica, la variabilidad de las características, las relaciones que puedan existir entre varias características, etc. De hecho, también es posible utilizar la agrupación de características ya realizada para construir los meta-modelos de esta forma. En la figura 5 se muestra un ejemplo para una familia de firewalls. En esta ocasión se ha representado una sola característica ("filtrado de paquetes") para dos firewalls diferentes (502,504). Esta característica se ha dividido, a su vez, en varias subcaracterísticas utilizando una representación en árbol, aunque cualquier otra sería posible. De cara a facilitar la comprensión del ejemplo, se han obviado el resto de características que pueden existir en esta familia. Por la misma razón, no se han considerado en el ejemplo relaciones entre características que pudieran existir. Las subcaracterísticas están representadas de forma genérica con un símbolo (una letra más un número), siendo la característica principal "filtrado de paquetes" la raíz del árbol. Si una misma subcaracterística existe en los dos firewalls, se utiliza el mismo símbolo para identificarla. De cara a mejorar la comprensión del ejemplo, se ha utilizado un criterio basado en el nivel de abstracción para decidir qué conceptos se asociarán a cada característica. De esta forma, en los niveles de modelado superiores se ofrecerán aquellos conceptos que modelen las características más abstractas (más desligadas del sistema, las que están más cerca de la raíz). Junto a cada uno de los meta-modelos de cada nivel de abstracción (512 a 522) se han incluido los símbolos correspondientes a las características que se pueden modelar para este ejemplo. De esta forma, a medida que se avanza en el proceso de modelado, los conceptos disponibles en los meta-modelos cada vez son más específicos de cada firewall cuya configuración se está modelando, hasta llegar a conceptos que sólo están disponibles en alguno de los dos firewalls (520,522).

Como no todos los sistemas de la familia ofrecen las mismas características, y dado que los conceptos que se ofrecen en los niveles de modelado estarán ligados, en algún momento, a una característica exclusiva de un sistema concreto o de un reducido conjunto de sistemas, se hace necesario especificar qué sistemas son los que están disponibles en el entorno de desplegado durante el modelado. Esta necesidad se suple con el modelo estructural que contiene, entre otras cosas, esta información. El modelo estructural puede asistir al técnico modelador en cuanto a qué conceptos puede utilizar en función del grado de reutilización de los modelos de comportamiento que quiera tener. Si el técnico necesita que el modelado sea desplegable independientemente de qué sistemas existan en el modelo estructural y por ende en la realidad, sólo podrá usar conceptos que se compartan entre todos los sistemas de la misma familia. Sin embargo, si sabe qué sistemas tendrá disponibles, podrá modelar comportamiento que se corresponda con características que son exclusivas de estos sistemas. Parece por tanto bastante natural que los meta-modelos estén, a su vez, realizados de forma modular, donde cada módulo puede contener el meta-modelo de una característica o un conjunto de ellas. Por tanto, los conceptos disponibles en un nivel de modelado podrían venir determinados no sólo por un meta-modelo, sino por un conjunto de meta-modelos. De nuevo, el criterio para realizar esta modularización puede ser muy variado, y se pueden tomar como ejemplos los descritos para la agrupación por características o para asignación de conceptos a los meta-modelos citados anteriormente. De esta forma el técnico modelador no sólo puede elegir qué niveles de abstracción usará durante el modelado, sino qué conceptos le son necesarios en un nivel de abstracción. Así, los meta-modelos (y por tanto los conceptos disponibles) de cada nivel de abstracción se pueden crear de forma diferente y dinámica durante el modelado, ajustándose la complejidad del proceso de modelado a las necesidades del técnico modelador. Sin embargo, hay que tener presente que algunos conceptos de niveles de modelado inferiores pueden depender de otros de niveles superiores, de manera que exista una relación de dependencia entre ellos. Qué hacer con estas relaciones de dependencia es un problema de diseño del proceso que se resuelve de manera diferente para cada familia de sistemas. Por ejemplo, se pueden dejar como opcionales sólo aquellos conceptos que no tengan dependencias con otros, o bien impedir el uso de conceptos en niveles inferiores que dependan de otros de niveles superiores si éstos no se han usado.

Así, dado que a través de uno o varios módulos de un meta-modelo se pueden modelar comportamientos, las transformaciones también pueden hacerse de manera modular, asignando una transformación M2M a cada módulo o a cada característica modelada, ya que cada módulo tendrá asociado su propio meta-modelo. Las transformaciones M2T también pueden realizarse de forma modular. En vez de realizar una transformación M2T de forma monolítica al final del proceso propuesto en la invención, a cada característica se le puede asignar una transformación M2T por cada sistema de la familia, de manera que la transformación M2T monolítica sería equivalente a la composición de las transformaciones M2T parciales. Así se obtiene un mayor grado de reutilización en las transformaciones. Sin embargo, debe tenerse en cuenta el caso de que la combinación de modelos pueda dar lugar a un comportamiento que sea diferente que el de la suma de los dos comportamientos individuales, y que por tanto tendrán una transformación M2T diferente en conjunto que por separado. Por todo ello, puede ser necesario guardar la relación existente entre un concepto de un meta-modelo, la característica o características a la que está asociado, la plataforma que posee esa característica, y en su caso la transformación M2T para ella por cada sistema de la familia. Esta relación se puede guardar en cualquier formato, como por ejemplo un fichero o una base de datos.

Claims

REIVINDICACIONES

1. - Método de modelado para la gestión de configuraciones en sistemas de información que comprende una etapa de meta-modelado de comportamiento (104) y de meta-modelado estructural (102) que determinan los conceptos de comportamiento y estructurales que se pueden usar y seguir para construir un modelo; y donde a través del meta - modelo de comportamiento (104) se modela el comportamiento (114) de los sistemas en base a su funcionalidad, que viene determinada por sus características, mientras que el modelo estructural (112) derivado del meta - modelo estructural (102) especifica aquella parte de la configuración del sistema o sistemas que no forman parte de su comportamiento; todo ello de tal forma que la combinación de ambos modelos (112,114) da lugar al comportamiento modelado (122) de uno o varios dispositivos; y que se caracteriza porque tanto el modelado estructural (112) como el de comportamiento (114) se realizan en base a un proceso de refinado secuencial que se compone de varias etapas de modelado partiendo de un modelo inicial (202).

2. - Método de modelado de acuerdo con la reivindicación 1 en donde cada etapa de modelado se corresponde con un nivel de abstracción diferente, representando este nivel de abstracción la ligadura respecto del sistema real.

3. - Método de modelado de acuerdo con la reivindicación 1 a 2 en donde el modelo inicial (202) es conforme a su meta - modelo (262) el cual comprende los conceptos mínimos necesarios para modelar el comportamiento común de los sistemas que forman parte de una familia de sistemas, representando el nivel de abstracción más alto de todas las etapas de modelado.

4. - Método de modelado de acuerdo con las reivindicaciones 1 a 3 en donde el refinamiento en el modelo se consigue a través de los nuevos conceptos que ofrecen los meta - modelos de las etapas sucesivas, de manera que a un primer meta - modelo (262) se le añaden los conceptos de otro meta - modelo (264) a través de operaciones de herencia, composición, unión, intersección o cualesquiera otra que se determine, todo ello en una o varias etapas de refinamiento.

5. - Método de modelado de acuerdo con las reivindicaciones 1 a 4 en donde el primer modelo (202) se transforma en un segundo modelo (204) mediante reglas de transformación modelo a modelo (222), refinándose a través de los nuevos conceptos disponibles en su nuevo meta - modelo (264); y en donde la manera de pasar del modelo de origen al de destino es mediante transformaciones.

6. - Método de modelado de acuerdo con las reivindicaciones 1 a 5 en donde una transformación necesita como entrada, al menos, un modelo, el meta - modelo al que es conforme, el meta - modelo del modelo de destino y la definición de la transformación, devolviendo como salida un modelo o un conjunto de ellos.

7. - Método de modelado de acuerdo con las reivindicaciones 1 a 6 en donde el número de niveles de modelado de refinamiento depende del modelado que se haga de las características de cada familia de sistemas, de tal forma que a través de una última transformación (224) se obtiene el último modelo de refinamiento (206) conforme a su meta - modelo (266).

8. - Método de modelado de acuerdo con las reivindicaciones 1 a 7 en donde en las últimas transformaciones (226 a 230) se incluye un modelo estructural (252) conforme a su meta - modelo (254), pudiéndose especificar aquellos parámetros que puedan guiar las transformaciones (226 a 230) hacia los modelos de configuración individuales (208 a 212).

9. - Método de modelado de acuerdo con las reivindicaciones 1 a 8 en donde el modelo estructural especifica al menos un sistema donde desplegar el modelo de comportamiento.

10. - Método de modelado de acuerdo con las reivindicaciones 1 a 9 en donde al incluir el modelo estructural (252) durante las últimas transformaciones (226 a 230) se pueden generar diferentes modelos de configuración individuales y específicos para los sistemas especificados en el modelo estructural (208 a 212).

11. - Método de modelado de acuerdo con las reivindicaciones 1 a 10 en donde en su conjunto los modelos de configuraciones individuales definen el mismo comportamiento que el último modelo de refinamiento (206) y son conformes a sus respectivos meta - modelos (268 a 272); y donde estos modelos individuales (208 a 212) se transforman en configuraciones específicas (242 a 246) para sistemas concretos a través de sus respectivas reglas de transformación modelo a texto (232 a 236).

12. - Método de acuerdo con las reivindicaciones 1 a 11 en donde las transformaciones modelo a texto (232 a 236) incluyen optimizaciones para un sistema determinado, mientras que las configuraciones resultantes de dichas transformaciones (242 a 246) pueden ser interpretadas directamente por los sistemas reales, de acuerdo a los lenguajes, parámetros y reglas que el fabricante de cada sistema haya establecido.

13. - Método de acuerdo con las reivindicaciones 1 a 12 en donde en el proceso de refinado existirá un meta-modelo inicial, cero o más meta-modelos de refinamiento, al menos una transformación modelo a modelo entre cada dos meta-modelos de refinamiento consecutivos (transformaciones 1:1), uno o más meta-modelos de configuración de sistemas específicos, una transformación desde el último meta- modelo de refinamiento a cada meta-modelo de configuración de sistema (transformación l:m), y una transformación modelo a texto desde cada uno de los meta-modelos de configuración a un sistema real (transformaciones 1:1).

14. - Método de acuerdo con las reivindicaciones 1 a 13 que comprende al menos una etapa de validación en alguna de las etapas de modelado. La validación se puede realizar a medida que se crean los modelos o una vez han sido creados.

15. - Método de acuerdo con las reivindicaciones 1 a 14 que comprende, al menos, una etapa de diagnosis en alguna de las etapas de modelado. La diagnosis se puede realizar a medida que se crean dichos modelos o una vez han sido creados.

16. - Sistema de modelado para la gestión de configuraciones en sistemas de información que comprende medios para ejecutar el método de las reivindicaciones 1 a 15.

17. - Un producto de software que comprende las instrucciones para ejecutar el método de las reivindicaciones 1 a 15.