ES2207756T3 - Maquina generica de estado de software y metodo de construir objetos dinamicos para un programa de aplicacion. - Google Patents
Maquina generica de estado de software y metodo de construir objetos dinamicos para un programa de aplicacion.Info
- Publication number
- ES2207756T3 ES2207756T3 ES97950587T ES97950587T ES2207756T3 ES 2207756 T3 ES2207756 T3 ES 2207756T3 ES 97950587 T ES97950587 T ES 97950587T ES 97950587 T ES97950587 T ES 97950587T ES 2207756 T3 ES2207756 T3 ES 2207756T3
- Authority
- ES
- Spain
- Prior art keywords
- factory
- objects
- class
- dynamic
- state
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
- G06F8/24—Object-oriented
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4498—Finite state machines
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99943—Generating database or data structure, e.g. via user interface
Abstract
ESTA INVENCION SE REFIERE A UN AUTOMATA ACABADO CON SOFTWARE ESTANDAR (10) DISEÑADO PARA LA IMPLEMENTACION DE UNA APLICACION DE SOFTWARE EN UN ENTORNO ORIENTADO OBJETO. DICHO AUTOMATA ACABADO TIENE UNA SERIE DE OBJETOS ENTIDADES (20, 30) DEFINIDOS PARA ELEMENTOS DE SOFTWARE DE UNA APLICACION DE SOFTWARE, UN CONJUNTO DE OBJETOS ESTADO (26, 34, 38, 40) DEFINIDOS PARA CADA OBJETO ENTIDAD REPRESENTATIVO DE ESTADOS QUE PUEDEN SER LOS DE UN ELEMENTO DE SOFTWARE Y UN CONJUNTO DE OBJETOS EVENTOS (36, 42) DEFINIDOS PARA CADA OBJETO ESTADO REPRESENTATIVO DE ENTRADAS QUE EL ELEMENTO SOFTWARE PUEDE RECIBIR O DE SITUACIONES QUE EL ELEMENTO SOFTWARE PUEDE ENCONTRARSE MIENTRAS ESTA EN EL ESTADO REPRESENTADO POR EL OBJETO ESTADO. ESTA INVENCION SE REFIERE TAMBIEN A UN PROCEDIMIENTO Y A UN SISTEMA DE CONSTRUCCION DE OBJETOS DINAMICOS DESTINADOS A UN SOFTWARE DE APLICACION, CONSISTIENDO DICHO PROCEDIMIENTO EN LEER Y ANALIZAR UN FICHERO DE CONFIGURACION PRINCIPAL MEDIANTE UN OBJETO "CONTRAMAESTRE", EN OBTENERUN IDENTIFICADOR DE OBJETO PARA CADA OBJETO DINAMICO ESPECIFICADO EN EL FICHERO DE CONFIGURACION PRINCIPAL, QUE HAY QUE CREAR, MEDIANTE EL OBJETO "CONTRAMAESTRE", UNA INSTANCIA DE CADA OBJETO DINAMICO ESPECIFICADO EN EL FICHERO DE CONFIGURACION PRINCIPAL Y EN OBTENER UNA DIRECCION FISICA PARA CADA OBJETO CREADO, EN ALMACENAR LOS IDENTIFICADORES DE OBJETOS Y LAS DIRECCIONES FISICAS DE LAS INSTANCIAS DE OBJETOS CREADOS EN UN DICCIONARIO DE OBJETO, EN LLAMAR AL PROCEDIMIENTO DE INICIALIZACION DE CADA OBJETO ALMACENADO EN EL DICCIONARIO DE OBJETOS Y EN INICIALIZAR CADA OBJETO CREADO.
Description
Máquina genérica de estado de software y método
de construir objetos dinámicos para un programa de aplicación.
Esta invención está relacionada en general con el
campo del software de ordenadores. Más en particular, la invención
está relacionada con un método de construcción de objetos dinámicos
para un programa de aplicación.
La escritura de aplicaciones de software para los
problemas del mundo real, tal como los protocolos de comunicaciones
de conmutación telefónica, es un procedimiento extremadamente
complejo. Tales aplicaciones de software requieren un gran número
de horas para crearlas, son entregadas frecuentemente con numerosos
problemas y son difíciles de modificar y darles soporte. La
dificultad para crear y dar soporte a grandes aplicaciones es
debida principalmente a la incapacidad de los paradigmas existentes
en el desarrollo del software para proporcionar un marco que
simplifique el proceso de desarrollo del software. Se ha demostrado
que la complejidad del software aumenta como una función
exponencial del número de operaciones diferentes que se espera que
procese con los paradigmas actuales. Un programa de 1000 líneas que
podría requerir un mes de desarrollo puede ser contrastado con un
programa de 2000 líneas que requiera seis meses o más de esfuerzo
de desarrollo. En el pasado, los grandes esfuerzos de programación
casi han sobrepasado las capacidades de desarrollo en términos de
rendimiento razonable, fiabilidad, coste de desarrollo y de ciclos
de desarrollo razonables.
La tecnología orientada a objetos (OOT) mejora la
productividad siempre que pueda simplificarse un problema
descomponiéndolo en un conjunto de objetos de cajas negras. La
tecnología orientada a objetos depende de los beneficios de la
ocultación, herencia y polimorfismo de los datos para simplificar
un diseño de software. Si una aplicación no puede ser subdividida
en objetos, la tecnología orientada a objetos no ofrece unas
mejoras significativas de productividad. La tecnología orientada a
objetos tampoco aborda cómo diseñar el comportamiento subyacente de
un objeto que debe cambiar su comportamiento en función del orden
en que suceden los eventos. El comportamiento subyacente de un
objeto de este tipo de requisitos se diseña mejor utilizando una
metodología de máquina de estados finitos.
La estrategia actual del software estado/evento
es asignar a cada paso del proceso un número de estado. Se utiliza
un árbol de decisión o una tabla para encaminar un evento a una
ruta de proceso que es específica para el estado y evento actuales.
Ni una estrategia funcional ni una estrategia de diseño orientada a
objetos reducen la complejidad y la cantidad de software de proceso
estado/evento por las razones siguientes:
- \bullet
- Se requieren células de función fuertemente anidadas para reducir el tamaño del programa. Este fuerte anidamiento obscurece la comprensión del funcionamiento del sistema y distancia aún más la implantación del software de la representación gráfica, tal como un diagrama de estado.
- \bullet
- Un simple evento puede ser el resultado de muchos cambios de estado posibles. El estado específico es a menudo una función de diversos estados y parámetros de bases de datos. Si las condiciones requeridas para hacer una transición de estado específica no pueden ser especificadas gráficamente como es el caso del estado con un paradigma numérico, la comprensión de las operaciones de la máquina de estado se obscurece.
- \bullet
- Es difícil hacer la ingeniería inversa de la implantación de una máquina de estados finitos (FSM) compleja. Un ingeniero de software comprende mejor las relaciones subyacentes de eventos de estado si están expresadas en un dibujo gráfico que muestre estados como burbujas o cajas y los eventos que dan como resultado transacciones a nuevos estados como arcos entre estados. Esta representación gráfica no puede encontrarse en la implantación del software debido al hecho de que las operaciones de software requeridas para implantar los cambios de estado están distribuidas a lo largo de todo el software. Por tanto, la implantación inicial del software debe ser codificada manualmente a partir de su representación gráfica. Los programas existentes en los que la documentación inicial se ha perdido o bien está obsoleta, requieren un proceso extenso para regenerar la representación gráfica que es más intuitiva.
- \bullet
- Las modificaciones al software introducen frecuentemente errores debido a que el cambio no pudo detener un temporizador o liberar un recurso a la salida de un estado. El estado como paradigma numérico oculta los recursos que están asignados.
- \bullet
- La mayoría de las implantaciones contienen numerosas rutinas de eventos pero con comportamiento similar y no totalmente idéntico. El número de errores en un sistema aumenta normalmente con el tamaño del software. Al eliminar el código resultante debe mejorar la fiabilidad del sistema.
- \bullet
- El diseño de estados da como resultado normalmente una arquitectura plana (en contraposición a jerárquica), que da como resultado un diseño complejo. Las máquinas de estado jerárquicas son soluciones naturales para algunos problemas tales como los protocolos de comunicaciones, pero otros problemas requieren una aguda intuición en el dominio del problema para permitir la descomposición en dos o más niveles de jerarquía. La arquitectura plana es difícil de mantener por las razones siguientes:
- \bullet
- El número de interconexiones entre estados es grande.
- \bullet
- Los estados redundantes con comportamiento similar interconectan con estados diferentes. Los diseños complejos son más propensos a errores que los diseños más sencillos.
- \bullet
- La generación automática y la comprobación de la máquina de estado de la aplicación a partir de una especificación gráfica no son prácticas usualmente debido a la naturaleza aleatoria del proceso realizado y de la distribución de cambios de estado.
Todos los factores anteriores hacen difícil
mejorar la productividad del desarrollo de software complejo. El
paradigma orientado a objetos no puede ser utilizado por sí mismo
para mejorar la calidad y reducir el coste del desarrollo de las
máquinas de estado de software complejo. La tecnología orientada a
objetos no aborda los trabajos internos de un código estado/evento
de un objeto. La dificultad fundamental del paradigma de la máquina
de estado de software es que modela una máquina de estado como
colección de números de estado y rutinas de eventos.
El documento US 5.555.415 divulga un subsistema
de consignación de eventos que pre-procesa los
mensajes de eventos recibidos por un sistema principal accionado
por eventos. Se divulga una representación de una máquina de
estado.
El Depósito de Servicios de Objetos Comunes,
Especificación de Servicios del Ciclo de Vida OMG, de 2 de Julio de
1993, páginas 1 a 50, divulga una solución común para el desarrollo
de software orientado a objetos. Se divulga el desplazamiento o la
copia de un objeto desde un lugar a otro.
Consecuentemente, se ha constituido en un deseo
la provisión de una manera o marco para desarrollar aplicaciones
complejas de software que las hagan más fáciles de comprender,
depurar y comprobar al tiempo que son eficientes en su utilización
en tiempo real. Además, es deseable proporcionar un marco que
permita una conversión sustancialmente directa a código a partir de
una representación gráfica de un diagrama de máquina de estado. En
particular, un diagrama de estado modelado según el modelo de
estados de Meally o de Moore, puede ser transformado fácilmente en
código reutilizable para la aplicación de software utilizando el
marco proporcionado por la presente invención.
Además, es deseable crear dinámicamente objetos
que implanten la aplicación de software a partir de un conjunto
jerárquico de ficheros de configuración. Los ficheros de
configuración pueden ser modificados fácilmente para modificar la
aplicación de software resultante sin tener que volver a encadenar
y recompilar el código. También es deseable que no resulte una
pérdida de rendimiento en tiempo real a partir de la capacidad de
crear dinámicamente objetos en tiempo de ejecución. De esta manera,
el proceso de implantación del software se perfecciona aún más.
De acuerdo con un aspecto de la presente
invención, se proporciona un método para construir objetos
dinámicos para un software de aplicación, que comprende los pasos
de: convertir una representación de un diagrama de estados de la
aplicación de software en un fichero de configuración principal;
leer y analizar el fichero de configuración principal por medio de
un fichero maestro; obtener un identificador (ID) del objeto para
cada objeto dinámico especificado en el fichero de configuración
principal; crear, por medio de un objeto de fabricación, un ejemplo
de cada objeto dinámico especificado en el fichero de configuración
principal y obtener una dirección física para cada ejemplo creado;
almacenar los identificadores de objetos y las direcciones físicas
de los ejemplos creados en un diccionario de objetos; llamar e
inicializar de un método para cada objeto almacenado en el
diccionario de objetos; y controlar la inicialización de cada
ejemplo creado.
De acuerdo con otro aspecto de la presente
invención, se proporciona un sistema para implantar dinámicamente
una aplicación de software, que comprende: una base de datos que
incluye una representación de un diagrama de estados de la
aplicación de software, estando adaptada la base de datos para
convertir la representación del diagrama de estados en un conjunto
de ficheros de configuración organizados jerárquicamente, donde los
ficheros de configuración de mayor nivel hacen referencia a ficheros
de configuración de nivel menor, conteniendo los ficheros de
configuración una especificación de un conjunto de objetos
dinámicos organizados jerárquicamente y atributos de los mismos para
implantar la aplicación de software; un objeto maestro adaptado
para leer y analizar el conjunto de ficheros de configuración,
estando adaptado el objeto maestro para obtener un identificador de
objetos para cada objeto dinámico, un objeto de fabricación adaptado
para crear un ejemplo de una clase particular de objetos dinámicos
especificados en los ficheros de configuración y obtener una
dirección física para cada ejemplo creado; y un diccionario de
objetos adaptado para almacenar los identificadores de objetos y las
direcciones físicas de los ejemplos creados, estando adaptado el
diccionario de objetos para inicializar cada ejemplo creado.
En un modo de realización de la presente
invención, un método para construir objetos dinámicos para un
software de aplicación incluye los pasos de leer y analizar un
fichero de configuración principal por medio de un objeto maestro,
obtener un identificador de objetos para cada objeto dinámico
especificado en el fichero de configuración principal, crear, por
medio del objeto de fabricación, un ejemplo de cada objeto dinámico
especificado en el fichero de configuración principal y obtener una
dirección física para cada objeto creado, almacenar los
identificadores de objetos y las direcciones físicas de los
ejemplos de objetos creados en un diccionario de objetos, llamar e
inicializar un método para cada objeto almacenado en el diccionario
de objetos, e inicializar cada objeto creado.
En un modo de realización de la presente
invención, un sistema para implantar dinámicamente una aplicación de
software incluye un conjunto de ficheros de configuración
organizados jerárquicamente donde los ficheros de configuración de
mayor nivel hacen referencia a ficheros de configuración de nivel
menor, conteniendo los ficheros de configuración una especificación
de un conjunto de objetos dinámicos organizados jerárquicamente y
los atributos de los mismos para implantar la aplicación de
software. Un objeto maestro está adaptado para leer y analizar el
conjunto de ficheros de configuración, y obtener un identificador
de objetos para cada objeto dinámico. Un objeto de fabricación
adaptado está adaptado para crear un ejemplo de una clase particular
de objetos dinámicos especificados en los ficheros de configuración
y obtener una dirección física para cada objeto creado. Un
diccionario de objetos almacena los identificadores de objetos y
las direcciones físicas de cada ejemplo de objeto creado, y controla
la inicialización de cada objeto creado.
Una importante ventaja técnica dispone el estado
como el paradigma de objetos materializado en el marco de un modo de
realización de la presente invención. Siguiendo a este estado como
paradigma de objetos, una aplicación de software que ha sido
diseñada en términos de un diagrama de estado de Meally o de Moore
puede ser convertido fácilmente a código con clases de objetos
reutilizables. Debido a que el estado está incorporado en un
objeto, esa clase de objetos de estado es reutilizable para
proporcionar muchos ejemplos de los mismos en la implantación del
software. Además, en un diagrama de estados de Moore, por ejemplo,
los estados del diagrama de estados pueden ser establecidos
fácilmente en un mapa de correspondencia con los objetos de
estados, y los arcos del diagrama de estados pueden ser establecidos
fácilmente en un mapa de correspondencia con objetos de eventos. De
forma similar, para hacer la ingeniería inversa de una aplicación
de software construida utilizando el marco de un modo de
realización de la presente invención puede hacerse fácilmente
mediante un mapa de correspondencia entre los objetos de estados y
los estados en un diagrama de estados de Moore, y un mapa de
correspondencia entre los objetos de eventos y los arcos del
diagrama. Por tanto, el proceso de codificar una aplicación de
software compleja se simplifica y perfecciona grandemente, dando
como resultado una productividad mejorada.
Además, debido a que los objetos están
especificados en ficheros de configuración, las modificaciones y
cambios del código no conllevan típicamente el
re-encadenamiento y la
re-compilación del código y puede hacerse en línea
en tiempo de ejecución. Debido a que los ficheros de configuración
y los objetos de fabricación están organizados independientemente y
de una manera jerárquica, pueden hacerse cambios a uno de ellos sin
afectar a los demás. La eficiencia en tiempo de ejecución del
software de aplicación se consigue también mediante la creación de
objetos dinámicos a partir de clases de objetos que son implantados
en un lenguaje compilado de alto nivel, tal como el C++, en lugar
de un lenguaje intérprete.
Para una mejor comprensión de la presente
invención, puede hacerse referencia a los dibujos que se acompañan,
en los cuales:
La Figura 1 es un diagrama de bloques
simplificado de una máquina de estados de software de acuerdo con
un modo de realización de la presente invención;
La Figura 2 es un diagrama de bloques
simplificado de estados como objetos de acuerdo con un modo de
realización de la presente invención;
La Figura 3 es un diagrama de contexto de Estados
de acuerdo con un modo de realización de la presente invención;
La Figura 4 es un diagrama de contextos del
proceso de inicialización en el cual se fabrican objetos de
aplicación de acuerdo con un modo de realización de la presente
invención;
La Figura 5 es un diagrama de la arquitectura
estratificada básica de la máquina de estados de software de
acuerdo con un modo de realización de la presente invención;
La Figura 6 es un diagrama de contexto de una
Máquina de Estados de acuerdo con un modo de realización de la
presente invención;
La Figura 7 es un diagrama de flujo lógico del
proceso de mensajes en la máquina de estados de software de acuerdo
con un modo de realización de la presente invención;
La Figura 8 es un diagrama de un ejemplo de
aplicaciones múltiples de acuerdo con un modo de realización de la
presente invención;
La Figura 9 es un diagrama de herencia de clases
de Objetos de acuerdo con un modo de realización de la presente
invención;
La Figura 10 es un diagrama de herencia de clases
de FsmEntidad de acuerdo con un modo de realización de la presente
invención;
\newpage
La Figura 11 es un diagrama de herencia de clases
de ColecciónFsm de acuerdo con un modo de realización de la
presente invención;
La Figura 12 es un diagrama de contextos de
agrupaciones dinámicas de acuerdo con un modo de realización de la
presente invención;
La Figura 13 es un diagrama de herencia de clases
de Estado de acuerdo con un modo de realización de la presente
invención;
La Figura 14 es un diagrama de herencia de clases
Evento de acuerdo con un modo de realización de la presente
invención;
La Figura 15 es un diagrama de herencia de clases
de Mensaje de acuerdo con un modo de realización de la presente
invención;
La Figura 16 es un diagrama de contexto de
objetos de fundición de acuerdo con un modo de realización de la
presente invención;
La Figura 17 es un diagrama de herencia de clases
de FundiciónMensajesSalientes de acuerdo con un modo de realización
de la presente invención;
La Figura 18 es un diagrama de contextos de
clases de FundiciónMensajesPuerto de acuerdo con un modo de
realización de la presente invención;
La Figura 19 es un diagrama de contextos de
clases de órdenes de acuerdo con un modo de realización de la
presente invención;
La Figura 20 es un diagrama de herencia de clases
de órdenes de acuerdo con un modo de realización de la presente
invención;
La Figura 21 es un diagrama de contextos de
clases de Temporizador de acuerdo con un modo de realización de la
presente invención;
La Figura 22 es un diagrama de herencia de clases
de Cola de temporizador de acuerdo con un modo de realización de la
presente invención;
La Figura 23 es un diagrama de herencia de clases
de CabeceraCola de acuerdo con un modo de realización de la
presente invención;
La Figura 24 es un diagrama de herencia de clases
de Trenzado de acuerdo con un modo de realización de la presente
invención;
La Figura 25 es un diagrama de contextos de
clases de Trenzado de acuerdo con un modo de realización de la
presente invención;
La Figura 26 es un diagrama de contextos de
clases de TemporizadorTrenzado de acuerdo con un modo de realización
de la presente invención;
La Figura 27 es un diagrama de contextos de
clases de ColaTrenzado de acuerdo con un modo de realización de la
presente invención;
La Figura 28 es un diagrama de contextos de
clases de ColaClienteTrenzado de acuerdo con un modo de realización
de la presente invención;
La Figura 29 es un diagrama de contextos de
clases de ExpendedorTrenzado de acuerdo con un modo de realización
de la presente invención;
La Figura 30 es un diagrama de herencia de clases
de Trazador de acuerdo con un modo de realización de la presente
invención;
Las Figuras 31A y 31B son diagramas de flujo de
ejecución de un Trazador de acuerdo con un modo de realización de
la presente invención;
Las Figuras 32A a 32C son diagramas de flujo de
ejecución de un ReguladorTrazador de acuerdo con un modo de
realización de la presente invención;
La Figura 33 es un diagrama de herencia de clases
de TrazadoObjeto de acuerdo con un modo de realización de la
presente invención;
La Figura 34 es un diagrama de herencia de clases
de EstadoFábrica de acuerdo con un modo de realización de la
presente invención;
La Figura 35 es un diagrama de herencia de clases
de Evento de acuerdo con un modo de realización de la presente
invención;
La Figura 36 es un diagrama de herencia de clases
de FsmEntidadFábrica de acuerdo con un modo de realización de la
presente invención;
La Figura 37 es un diagrama de herencia de clases
de TrenzadoFábrica de acuerdo con un modo de realización de la
presente invención;
La Figura 38 es un diagrama de herencia de clases
de FábricaCabeceraCola de acuerdo con un modo de realización de la
presente invención;
La Figura 39 es un diagrama de herencia de
MensajeSalienteFundiciónFábrica de acuerdo con un modo de
realización de la presente invención.
Los modos de realización preferidos de la
presente invención están ilustrados en las Figuras
1-39, siendo utilizadas referencias numéricas
similares para hacer referencia a partes similares y
correspondientes de los diversos dibujos.
Las máquinas de estados de hardware
extremadamente complejas se realizan típicamente por medio de la
microprogramación. Las máquinas de estados de hardware
microprogramado simplifican la complejidad del hardware y reduce el
número de componentes. Las máquinas de estados de hardware
microprogramado se construyen típicamente utilizando memoria que
está subdividida en campos, donde cada campo de memoria controla el
funcionamiento de un subconjunto de hardware. Las máquinas de
estados de hardware microprogramado son muy normales, y fáciles de
modificar donde los cambios son requeridos solamente en el
contenido de la memoria. El estado de la máquina de estados de
hardware es la dirección de la microinstrucción en curso en la
memoria. Las máquinas de estado de hardware proporcionan típicamente
salidas que son función del estado en curso. El estado siguiente en
el cual entra la máquina de estado de hardware está totalmente
determinado por el estado en curso y los datos de entrada. Las
máquinas de estado de software pueden emular el paradigma de
hardware asociando las salidas (mensajes, estado y cambios de
hardware) con el estado en curso en lugar del transitorio asociado
con el evento. Una parte clave de la invención es que el estado de
un objeto es transformado a partir de un número en un objeto con
propiedades y comportamiento. Para que un objeto adapte fácilmente
su comportamiento, el estado de un objeto debe ser un objeto
estático relacionado con el objeto original por asociación. El
objeto cambia el estado cambiando su asociación a un objeto
diferente. El comportamiento polimórfico con los eventos es
gestionado asignando el objeto del estado para procesar el
evento.
La Figura 1 es un diagrama de bloques de un
ejemplo de máquina de estado microprogramada 10 que puede estar
basada en un estado como paradigma numérico o en un estado como
paradigma de un objeto. Si está basado en el estado como paradigma
numérico, la máquina de estados no es reutilizable porque el
comportamiento específico de la aplicación, tal como los formatos
de mensajes entrantes y los atributos, no pueden ser aislados del
comportamiento común. Los atributos 0 a (N-1) son
las acciones que puede realizar la máquina de estados 10 de
software, tal como el valor del temporizador, el estado del
hardware y el mensaje que ha de enviarse. A partir de estos
atributos, se producen salidas. En la máquina de estado 10 de
software, los interfaces abstractos para recibir un evento,
procesar un evento, entrar en un estado y salir de un estado pueden
ser definidos en un conjunto de clases de objetos que no contienen
código específico de la aplicación. Estas clases son reutilizables
como punto de partida para implantar programas de aplicación. El
programador define los atributos en un estado obtenido que son
requeridos para la aplicación e implanta los gestores de entrada y
salida. Los gestores de entrada y salida corresponden a la lógica
aleatoria en una máquina de estados de software que es accionada
por el contenido de la memoria microprogramada. Puede utilizarse una
herramienta de interfaz gráfico de usuario (GUI) para construir
programas de aplicación creando ejemplos de estados y otros objetos
en forma de diagrama, interconectándolos, y rellenando los
atributos requeridos.
En particular, el programador puede empezar
implantando la aplicación de software diseñando primero un conjunto
de diagramas de estado jerárquicos. Siguiendo al modelo de Moore,
los estados se dibujan como burbujas conectadas por arcos que
representan elementos o eventos que originan cambios de estado. El
estado, como paradigma del objeto, permite al programador
transformar fácilmente esta especificación gráfica de la aplicación
de software en código, convirtiendo los estados del diagrama en
objetos de estado y los arcos del diagrama en objetos de eventos.
La ingeniería inversa se simplifica también por el estado como
paradigma del objeto. Los objetos de estado en el software de
aplicación pueden ser transformados en burbujas en el diagrama de
estados y los objetos de eventos pueden ser transformados en arcos
que conectan las burbujas.
La Figura 2 es un diagrama de bloques
simplificado de los estados como paradigmas de objetos, de acuerdo
con un modo de realización de la presente invención. La programación
estándar orientada a objetos no tiene en cuenta que un objeto
cambie su comportamiento como resultado de la recepción de un
evento. El polimorfismo en lenguajes tales como el C++ permite que
objetos diferentes respondan unívocamente a un evento pero no hace
que los objetos individuales cambien su comportamiento con el
tiempo. Los ejemplos de máquinas de estados finitos, su conjunto de
estados, y los gestores de eventos, pueden ser considerados como un
objeto ampliado en cuanto que todos ellos son requeridos por la
entidad de nivel superior para implantar su comportamiento. En el
estado como paradigma de objetos, se utiliza un objeto 20 para
encapsular los datos y los métodos de un estado. Cuando un evento
particular 22 es encontrado por un objeto 20, el objeto 20 queda
asociado con un objeto específico N 26 de estado. El objeto 20
puede cambiar estados cambiando su asociación con diferentes objetos
26 de estado. El comportamiento polimórfico en los eventos es
gestionado asignando el objeto 26 de estado al evento 22 de
proceso.
Se ha desarrollado un conjunto de clases de
estado/evento basándose en el paradigma de estados como objetos.
Las operaciones requeridas para entrar en un estado son eliminadas
de las funciones de eventos y colocadas en funciones de entrada
asociadas con el estado. El proceso de entradas es provocado
automáticamente como resultado de la entrada en un estado. Al
asociar el proceso con un estado en lugar de un evento, permite que
todo el proceso común requerido para entrar en un estado sea
centralizado y encapsulado en el objeto del estado. Además, ciertas
funciones tales como el establecimiento de un temporizador al entrar
en un estado, se realizan mejor por el estado que por una función
de evento, ya que el temporizador debe ser establecido
independientemente de qué evento provocó la transición al estado.
En otro caso, cada una de las funciones de eventos que se origina
en una transición hacia un estado debe realizar el proceso
requerido.
Las operaciones requeridas para salir de un
estado son eliminadas también de las funciones de eventos y
colocadas en funciones de entrada asociadas con el objeto del
estado. El proceso de salida es provocado automáticamente como
resultado de abandonar un estado. Frecuentemente se requiere el
proceso de salida, tal como la detención de un temporizador que fue
establecido al entrar en el estado. Incluso la función de evento
que se origina al salir de un estado debe realizar usualmente el
mismo proceso de salida. Al automatizar la cancelación del
temporizador, se simplifican significativamente las funciones de
eventos. Al automatizar el proceso de salida, se introducen menos
errores como resultado de un fallo para realizar una función de
salida en una rutina de eventos.
En la máquina de estado de software, se permiten
atributos que imitan el funcionamiento de las máquinas de estados
microprogramadas en la ejecución del comportamiento de entrada y
salida implantado por el usuario. Las funciones de eventos, entrada
y salida pueden ser combinadas cuando se eliminan datos
dependientes del estado. La máquina de estados orientada a objetos
resume el estado de forma tal que cada aplicación añade atributos
como elementos de datos según se requiera para satisfacer los
requisitos de la aplicación.
En la máquina de estado 10 de software, se
permite que los objetos de estados sean estables o transitorios.
Los objetos de estado estables añaden el comportamiento para
procesar eventos externos y los objetos pueden permanecer en un
estado estable entre ocurrencias de eventos. En los estado
transitorios se entra solamente para realizar una operación que es
coincidente con el proceso de un evento. Los estados transitorios
pueden ser utilizados para reducir la profundidad de la llamadas a
funciones en rutinas de eventos encadenando los estados
transitorios. Por ejemplo, cada estado transitorio realiza a la
entrada las operaciones requeridas en una llamada a una función.
Desde un estado transitorio se permiten salidas múltiples. El uso de
estados transitorios simplifica el proceso que se requiere para una
transición específica de estados, pero aumenta la complejidad del
diagrama de estados.
En la máquina de estados 10 de software, no
pueden hacerse cambios explícitos de estado por la función de
eventos. A las funciones de eventos se les permite solamente
indicar cambios de estados lógicos que son traducidos en el estado
físico apropiado. Las funciones de eventos que diferirían
normalmente por los respectivos cambios de estado pueden ser
integradas en rutinas comunes.
En la máquina de estados 10 de software, la
topología de las transiciones de estados está situada dentro de los
objetos de estados en lugar de estar dentro de las funciones de la
aplicación. Por tanto, la tarea de mantener y descifrar la topología
de estados se simplifica, porque ya no se requiere al ingeniero
pasar por el código del programa para determinar qué transiciones
de estado están definidas para un estado.
En la máquina de estados 10 de software, las
responsabilidades asignadas a las funciones de eventos están
limitadas a procesar el evento recibido y determinar si se requiere
un cambio de estado lógico. Por tanto, se requieren menos funciones
de eventos y más sencillas.
En la máquina de estados 10 de software, la
estructura interna de los eventos entrantes es encapsulada. Todos
los eventos entrantes pueden entrar como objetos de mensajes de
estado o son transformadas en el extremo frontal de un objeto, de
forma tal que todos los accesos a los elementos de datos se
realizan a través de funciones asociadas.
En el paradigma de la máquina de estados de
software, se proporciona también soporte para las máquinas de
estado jerárquicas o de interacción. Los eventos son encaminados a
la máquina de estados a la que se ha delegado la responsabilidad
para procesarlos. La transmisión de mensajes internamente entre
máquinas de estado está admitida. La relación entre dos máquinas de
estados cualquiera puede ser jerárquica con procesos de eventos de
nivel más alto en la máquina de estados de nivel superior y los
eventos de nivel más bajo procesados por la máquina de estados de
nivel inferior. La comunicación entre dos niveles de máquinas de
estados se hace a través de eventos internos. Dos máquinas de
estados cualquiera pueden tener también una relación funcional,
donde cada máquina de estados tenga asignada una responsabilidad
para un conjunto independiente de eventos y las dos máquinas de
estados interactúen enviándose eventos una a otra según se requiera.
El intercambio de eventos es una transacción eficiente. Entre las
máquinas de estados se permiten llamadas directas de la función
asociada de mensajes de proceso.
Haciendo referencia a la Figura 3, se ilustra un
diagrama simplificado de contextos de una clase de estados. Un
ejemplo 30 de una clase de objetos de EjemploFsm (ejemplo de
máquina de estados finitos) tiene un puntero 32 de estados que
apunta a un ejemplo 34, estado 0, de su objeto de estados actual.
El estado 0 34 define el comportamiento del EjemploFsm 30 en
términos de los eventos 36 a los que EjemploFsm 30 puede responder
mientras está en el estado actual, de las acciones realizadas en el
estado actual, y de un estado siguiente 38 en el que puede entrar
EjemploFsm 30. Por tanto, los objetos 34, 38 y 40 de estados
representan los estados en los que puede entrar el objeto de
EjemploFsm y define también una colección de eventos 42 a los que
puede anticiparse EjemploFsm 30 cuando está en los estados 34, 38 y
40.
Haciendo referencia a la Figura 4, se ilustra un
diagrama de bloques de un proceso de inicialización de una máquina
de estados de software. Todos los objetos de la aplicación que
siguen al paradigma de la máquina de estados de software son creados
a través de una referencia a un fichero de configuración. En la
inicialización, a un objeto Maestro 50 se le proporciona un nombre
específico 51 de fichero de configuración, tal como un fichero de
configuración principal (ConfigPrincipal). El fichero de
configuración especifica y define un conjunto de objetos de nivel
superior que necesitan ser creados por un objeto 52 de Fábrica a
petición del Maestro 50. El Maestro 50 recupera el fichero
ConfigPrincipal 53 de un sistema de ficheros o base de datos 54 y
pasa el contenido del fichero de configuración a la Fábrica 52.
Cada objeto especificado en el fichero de configuración puede tener
un fichero o ficheros de configuración asociado que especifican
además cómo deben ser construidos los objetos.
El Maestro 50 asume todas las responsabilidades
de construcción de objetos. Es responsable de construir el sistema
preparándolo para el arranque. El Maestro almacena el
IdentificadorObjetos y una dirección del objeto para cada objeto
creado en el DiccionarioObjetos. El objeto de fabricación puede
hacer referencia a una jerarquía de objetos para la creación del
objeto requerido. El Maestro construye el sistema en dos pasos:
- 1.
- Todos los objetos son creados y almacenados en el DiccionarioObjetos. En esta etapa, los objetos son enlazados por el IdentificadorObjetos.
- 2.
- Se llama al método de inicialización del DiccionarioObjetos. El diccionario ejecuta iterativamente su método de inicialización a través de todos los objetos. Todos los objetos deben traducir referencias al IdentificadorObjetos en direcciones físicas de objetos.
La fábrica 52 contiene un conjunto de objetos de
fábrica. Cada objeto de fábrica posee el conocimiento para construir
un ejemplo de una clase de objetos en particular. Haciendo
referencia también a la figura 5, el Maestro 50, la Fábrica 52 y
otros objetos son parte de un creador dinámico 70 de objetos. En el
constructor de objetos de Fábrica se crea un ejemplo de un objeto de
fábrica para cada tipo de objeto que pueda ser construido
dinámicamente. Los objetos dinámicos que pueden ser creados por el
creador dinámico 70 de objetos incluyen objetos 72 de colección,
objetos 74 de trenzado, objetos 76 de colas, objetos 82 de mensajes,
objetos 78 de temporizadores, objetos 80 de estado y objetos 82 de
mensajes, por ejemplo. Los programas 90 de aplicación son
construidos encima de los objetos dinámicos 72-82
construidos por el creador dinámico 70 de objetos y utilizan estos
objetos dinámicos para realizar las funciones necesarias. Por tanto,
la fábrica 52 puede ser exclusiva de cada aplicación para crear
conjuntos diferentes de objetos dinámicos adaptados a cada
aplicación. Los objetos dinámicos del programa de aplicación se
crean generalmente en dos pasos.
Haciendo nuevamente referencia a la Figura 4, la
Fábrica 52 crea todos los objetos recuperando los identificadores de
objetos (IdentificadorObjetos), las clases de objetos y los
atributos de objetos opcionales de las clases de objetos enumeradas
en el fichero 53 de configuración. La fábrica 52 proporciona
entonces las direcciones de los objetos creados al Maestro 50 y las
direcciones e identificadores de objetos de los objetos creados a un
DiccionarioObjetos 56, que mantienen una tabla o base de datos para
almacenarlos. Un objeto 58 de diccionario dentro del
DiccionarioObjetos 56 es instruido entonces para inicializar todos
los objetos almacenados en el DiccionarioObjetos 56 a través de su
función de inicialización de asociados. El diccionario 58 llama
iterativamente a todos funciones asociadas a través de todos sus
objetos almacenados. Después se hace un encadenamiento cruzado entre
los objetos creados. El DiccionarioObjetos 56 es un objeto estático
que es visible a todos los objetos creados dinámicamente. Su
diccionario 56 establece un mapa de correspondencia entre los
identificadores de objetos y las direcciones del objeto
correspondiente. El Maestro 50 está activo solamente durante la fase
de inicialización y es responsable de gestionar la creación de los
objetos de nivel superior en el fichero de configuración pasado.
Construido de esta manera, un programa de
aplicación puede ser modificado rápidamente cambiando los ficheros
de configuración sin recompilar y re-encadenar el
código. Los ficheros de configuración pueden estar escritos en TCL,
sin embargo, puede utilizarse un lenguaje de argumentos o incluso el
ASCII para especificar la lista de nombres de ficheros de
configuración que almacena las especificaciones del objeto.
La Figura 6 es un diagrama de contextos de clases
de cierto marco de clases de la arquitectura de la máquina de
estados de software. La Figura 6 ilustra la relación de contexto de
las clases de máquinas de estado de software que se ejecutan en el
contexto de una o más clases abstractas 100 de Trenzado. El Trenzado
100 es una clase abstracta que es el objeto central en la máquina de
estados de software. Una clase abstracta es una clase que tiene una
o más funciones virtuales puras, que están definidas pero no
implantadas en la clase abstracta. Por tanto, no pueden crearse
ejemplos directamente a partir de una clase abstracta. Una clase
abstracta se utiliza para obtener clases adicionales que contienen
realizaciones de las funciones virtuales puras. El Trenzado 100
recibe MensajesOS (mensajes del sistema operativo) 102 desde un
ejemplo 104 de GestorColas, los convierte en ejemplos 106 de objetos
de Mensaje y los envía a un ejemplo 108 de MapaFsm. El Mensaje 106
es una clase abstracta que define el interfaz para obtener la
identidad de un mensaje. El ejemplo 108 de MapaFsm pregunta al
ejemplo 106 de Mensaje su identificador simbólico de mensaje y lo
traduce o lo pone en un mapa de correspondencia con la dirección de
un EjemploFsm 110 con responsabilidad asignada para procesar el
mensaje. Los mensajes entrantes de la máquina de estados pueden ser
procesados por un solo objeto EjemploFsm 110 o un objeto
ColecciónFsm, que se ilustra en la Figura 5 como un objeto 112 de
una AgrupaciónFsm que recibe un mensaje 114 de una agrupación.
El objeto AgrupaciónFsm 112 pregunta al mensaje
114 de una agrupación de máquinas de estado por el identificador de
EjemploFsm, que es traducido a uno o más EjemplosFsm específicos (o
colección) 120 que tiene asignada la responsabilidad de procesar el
mensaje. El EjemploFsm 120 gestiona el proceso del mensaje. Cada
EjemploFsm 120 contiene su identificador de estado actual y la
dirección del estado 122 que especifica el proceso del mensaje. El
EjemploFsm 120 llama a la función asociada del evento del proceso
del estado. Si el objeto 122 del estado devuelve un nuevo
identificador de estado, el EjemploFsm 120:
- 1.
- Llama a la función asociada a la salida del estado actual;
- 2.
- Llama a la función de entrada en el estado siguiente; y
- 3.
- Repite el paso 2 si la función de entrada del paso 2 devuelve un identificador de estado.
Ejemplos de un objeto 126 de Estado de Evento
contienen un DiccionarioEstados 128 de los eventos que están
definidos para este estado. Al mensaje recibido de la máquina de
estados se le pregunta por su identificador de mensaje simbólico que
es traducido en la dirección de uno o más Eventos objetivo 130. El
objeto 126 de Estados de Eventos pasa el mensaje de la máquina de
estados y el objeto EjemploFsm al Evento 130. El ejemplo 130 de
eventos devuelve un puntero a un ejemplo de EstadoLógico cuando se
requiere un cambio de estado. Cada ejemplo de estado 126 de Eventos
es obtenido a partir de una clase 128 de DiccionarioEstados y por
tanto tiene también un diccionario lógico de estados. El
DiccionarioEstados 128 de clase gestiona colecciones de estados y
contiene funciones asociadas para añadir un estado a su colección y
convertir un IdentificadorEstado en una dirección de su estado
asociado. Cada ejemplo de DiccionarioEstados contiene dos
diccionarios: _DiccionarioInic contiene parejas de
IdentificadorEstado a IdentificadorObjeto; _DiccionarioEstados
contiene direcciones de estados que son traducidas por el
DiccionarioObjetos a partir del _DiccionarioInic.
El Estado 126 de Evento traduce entonces el
EstadoLógico devuelto por el Evento 130 en un identificador de
estado (IdentificadorEstado) y traducido además en la dirección del
objeto 122 del Estado asociado, que es devuelto al que llama a su
función de proceso asociada de evento.
Los parámetros generales del fichero de
configuración para cada clase son los siguientes:
- establecer AtributosObjeto (0, ClaseObjeto) NombreClase
- establecer AtributosObjeto (0, IdentificadorObjeto) IdentificadorObjeto
- establecer FicherosConfig (0, Nombrefichero) Nombrefichero1.config
- establecer FicherosConfig (1, Nombrefichero) Nombrefichero2.config
- establecer AtributosObjeto (0, Estadoseguimiento) DESACTIVADO
Los ejemplos de parámetros requeridos pueden
tener el formato:
- _IdentificadorEstado Nombre Inicial del Estado
- establecer AtributosNombreClase (0.EstadoNombreClase) IdentificadorEstado
- _IdentificadorDiccionarioEstados dirección del diccionario para traducir ejemplos de IdentificadorEstado
- establecer AtributosNombreClase (0.DiccionarioEstadoFsm) IdentificadorObjeto
El NombreClase referido anteriormente es
el nombre de la clase que ha de sustituirse en ese lugar.
La Figura 7 es un diagrama que ilustra también el
flujo lógico de un MensajeOS 102 a partir de un ejemplo 104 de un
GestorColas hasta que es procesado por un objeto 130 de Eventos. Un
CPTrenzado 140 de clase obtenida crea ejemplos de mensajes de
proceso de llamadas y los devuelve moldeados como ejemplos de
mensaje. El EjemploFsm 120 traduce los valores del identificador de
estado (IdentificadorEstado) que recibe devueltos desde un ejemplo
de Estado de Eventos (que es una clase obtenida del diccionario 128
de estados) a la dirección del estado asociado 122. La arquitectura
de la máquina de estados permite sustituir los modelos alternativos
de máquinas de estado para ejemplos específicos de EjemploFsm, donde
la colección de estados puede diferir incluso en un solo ejemplo de
estado.
Haciendo referencia a la Figura 8, se ilustra un
ejemplo de aplicación múltiple. En un programa de aplicación de
proceso de llamadas de telecomunicaciones, puede existir una
aplicación de máquinas de estado de software para un traductor
genérico 140 para traducir el proceso de llamadas de traducción que
residen conjuntamente con varios modelos 142 de llamadas. Un objeto
144 de Trenzado de aplicación múltiple crea unos mensajes 146 a
partir de MensajesOS 148 recibidos desde el GestorColas 104. El
Trenzado 144 de aplicación múltiple remite los mensajes a un objeto
150 controlador de la aplicación, el cual encamina los Mensajes 146
a la aplicación apropiada. El Trenzado 144 de aplicación múltiple
hereda sus datos y funciones de la clase 100 de objetos de Trenzado
y el Controlador 150 de la Aplicación los hereda de una clase de
objetos de ColecciónFsm (Objeto 120 de EjemploFsm múltiple).
Consecuentemente, para conseguir la funcionalidad
de la máquina de estados de software, se ha diseñado un ejemplo de
conjunto de jerarquías de clases. Algunas de estas jerarquías de
clases han sido descritas brevemente con anterioridad y se resumen a
continuación:
- \bullet
- Todos los mensajes recibidos son obtenidos a partir de una clase de Mensajes que oculta todos los detalles de la aplicación de la máquina de estados de software.
- \bullet
- Se crea una clase de Trenzado que define una función virtual pura para traducir ejemplos de MensajesOS en ejemplos de Mensajes compatibles.
- \bullet
- Una clase de MapaFsm admite ejemplos individuales de máquinas de estados finitos así como colecciones de ejemplos de máquina de estados finitos.
- \bullet
- Una clase EntidadFsm es el interfaz abstracto entre la máquina de estados de software y los bloques de llamadas.
- \bullet
- Una clase de Estados define el comportamiento abstracto para entrar, salir de un estado y procesar un evento.
- \bullet
- Las nuevas clases de estado, el estado del diccionario y el estado configurable admiten cambios lógicos de estado. El usuario es responsable de definir el conjunto de variables lógicas de estado y el mapa de correspondencia dentro de cada estado del estado lógico y el identificador del estado físico.
- \bullet
- La jerarquía de clases de eventos admite el proceso de un evento específico para un estado.
Estas clases de objeto están descritas con más
detalle a continuación.
Haciendo referencia a la Figura 9, se ilustra un
diagrama de herencia de clases de Objetos. En la máquina de estados
de software, todos los objetos que pueden crearse a partir de un
fichero de configuración por el creador dinámico 70 de objetos
(Figura 5), son descendientes desde una clase base, la clase 170 de
Objetos. Como los objetos son creados e inicializados durante la
fase de inicialización del proceso, (ilustrado en la Figura 4), la
clase 170 de Objetos proporciona el interfaz para acceder e
inicializar los objetos almacenados en el DiccionarioObjetos 56
(Figura 4). Desde la clase 170 de Objetos se obtiene la clase 172 de
objetos de Estado, el objeto 174 de EntidadFsm, la clase 176 de
objetos de Eventos y la clase 178 de objetos de Mensaje. Los objetos
del tipo Objeto deben dominar a la implantación de la base de los
siguientes ejemplos de métodos:
- 1.
- inicializar - resolver todas las referencias de IdentificadorObjetos en direcciones de objetos físicos utilizando el DiccionarioObjetos;
- 2.
- comenzar la ejecución - realizar cualquier proceso tras la inicialización, tal como la creación de un trenzado;
- 3.
- poner cadenas en secuencia - el objeto debe volcar todos sus atributos de datos en un formato ASCII humanamente legible; y
- 4.
- Obtener clases - devuelve un ejemplos de cadena que identifica unívocamente la clase del objeto.
La clase 170 del objeto es una clase abstracta
que define el interfaz para la inicialización de objetos. Como se ha
descrito anteriormente, la inicialización es un proceso de dos pasos
de construcción y resolución de direcciones de objetos. Tras el
proceso de inicialización, comienza la ejecución. Es una tarea del
DiccionarioObjetos ejecutar cada una de las funciones de
inicialización asociadas al objeto. La función de inicialización
asociada es una función virtual que se utiliza para provocar que el
objeto obtenido se inicialice por sí mismo. El objeto traduce todas
las referencias de IdentificadorObjetos en direcciones de objetos
físicos para permitirles acceder directamente a los objetos de
destino. Por tanto, cada objeto que pueda residir en el
DiccionarioObjetos debe ser obtenido a partir de una clase de
objetos del Diccionario. Debido a que la clase 170 de Objetos es una
clase abstracta, no pueden crearse ejemplos de la misma.
Haciendo referencia a la Figura 10, se ilustra un
diagrama de una jerarquía de clases de una clase 174 de objetos de
EntidadFsm de acuerdo con las enseñanzas de un modo de realización
de la presente invención. La clase 174 de EntidadFsm generaliza el
comportamiento de la recepción y proceso de mensajes definiendo una
función asociada a procesarEventos que es una función virtual pura
que define el interfaz para recibir mensajes a procesar. Una
EntidadFsm puede ser un simple objeto tal como un EjemploFsm o puede
ser una colección de entidades tales como ColecciónFsm, descritas a
continuación. Ejemplos de EntidadFsm están enlazados a una entidad
madre a través de su atributo Entidadmadre.
El EjemploFsm 196 hereda el comportamiento del
interfaz de mensajes de la EntidadFsm 174 y es la clase base para
objetos orientados a estados que pueden definir una aplicación, tal
como objetos de bloques de llamadas en una aplicación de proceso de
llamadas de telecomunicaciones. El objeto fundamental en una
aplicación de telefonía es el bloque de llamadas. Contiene el estado
actual de la llamada para un circuito de enlace troncal específico y
proporciona el almacenamiento de dígitos entrantes acumulados. La
clase 196 de objetos de EjemploFsm no contiene ningún comportamiento
o atributos específicos de la aplicación, sino que en lugar de eso
define el comportamiento común de un objeto que tiene un estado. Los
objetos específicos de la aplicación, tales como los bloques de
llamadas, pueden ser obtenidos a partir de la clase 196 de
EjemploFsm. El EjemploFsm 196 tiene un atributo, _estado, que define
el estado actual del ejemplo de objeto, y otro atributo,
_MáquinaEstados, que contiene la dirección de la MáquinaEstados que
se utiliza para traducir los IdentificadoresEstado en ejemplos de
objetos de Estado. Cuando se llama a su función asociada
procesarEvento, se hace pasar al Mensaje recibido al estado a través
de su función asociada procesarEvento. Esta función asociada
devuelve un puntero al IdentificadorEstado si se requiere un cambio
de estado. El EjemploFsm emite entonces una petición al ejemplo de
MáquinaEstados para traducir el IdentificadorEstado a la dirección
del objeto de estado, llama primero a la función asociada de salida
del estado actual y después a la función de entrada del estado
siguiente. El Ejemplo FSM incluye además una función asociada de
establecerIdentificadorEstado que es una función pública utilizada
para establecer el IdentificadorEstadoInicial, que debe ser llamado
por el objeto de FábricaEjemplosFsm antes de llamar a la función de
inicialización. Otra función pública,
establecerIdentificadorDiccionarioEstados, establece el
IdentificadorObjeto del diccionario de estados, que debe ser llamado
antes de llamar a la inicialización.
La clase 198 de EjemploAgrupaciónFsm hereda del
EjemploFsm 196, y define el comportamiento de proceso de estados
para una agrupación de EjemplosFsm. El EjemploAgrupaciónFsm 198
puede tener las mismas funciones y atributos asociados que el
EjemploFsm 196.
La clase 200 de EjemploTemporizadoFsm hereda de
EjemploAgrupaciónFsm 196 y proporciona soporte para un temporizador
que se inicia o se detiene automáticamente al entrar en un estado.
El EjemploTemporizadoFsm 200 define dos funciones virtuales puras,
iniciarTemporizador y detenerTemporizador, para iniciar y detener
temporizadores a la entrada y salida de un estado, respectivamente.
El EjemploTemporizadoFsm 200 incluye además una función pública,
procesarExpiraciónTiempo, que proporciona el punto de entrada para
eventos de expiración de tiempo desde el temporizador. La función
asociada procesarExpiraciónTiempo tiene el flujo lógico
siguiente:
- 1.
- emitir un mensaje de Seguimiento si está activado
- 2.
- si se devuelve un estado (indicativo de un cambio de estado a punto de ocurrir), traducir el IdentificadorEstado del estado siguiente a una dirección del objeto
- 3.
- Si está activado el seguimiento, emitir un mensaje de seguimiento
- 4.
- salir del estado actual
- 5.
- si está activado el seguimiento, emitir un mensaje de seguimiento
- 6.
- entrar en el estado siguiente.
Enclavamiento 202 es una clase que encapsula el
mecanismo de enclavamiento del sistema operativo para aislar el
sistema operativo del software de aplicación. Muchas clases utilizan
Enclavamiento 202 como una clase madre mezclada.
El EjemploTemporizadoMúltipleFsm 204 es una clase
que permite que progresen simultáneamente temporizadores múltiples
para un EjemploFsm. El EjemploTemporizadoMúltipleFsm 204 hereda de
EjemploTemporizadoFsm 200 y añade funciones asociadas para añadir un
temporizador al conjunto permitido de temporizadores y para iniciar
o detener un temporizador específico. Es responsabilidad del
programa de aplicación iniciar y detener los temporizadores
mantenidos en un mapa, _MapaTemporizador, que tiene las direcciones
de los temporizadores en el conjunto de temporizadores permitidos. A
diferencia del temporizador definido por la clase madre
EjemploTemporizadoFsm, ninguno de estos temporizadores se inicia o
detiene automáticamente por las clases de estados base al entrar o
salir de un estado. El ejemplo TemporizadoMúltipleFsm 204 incluye
una función asociada de iniciarTemporizadorMúltiple, que tiene el
flujo lógico siguiente:
- 1.
- obtener dirección del temporizador a partir del _MapaTemporizador
- 2.
- si no está presente el temporizador en _MapaTemporizador, imprimir el mensaje de seguimiento de errores y volver
- 3.
- activar el temporizador
- 4.
- volver.
De forma similar, una función asociada
detenerTemporizadorMúltiple, accede a _MapaTemporizador para obtener
la dirección de un temporizador especifico y lo desactiva cuando es
llamada. Una función asociada, añadirTemporizadorMúltiple, puede ser
llamada para añadir un temporizador al conjunto de temporizadores y
actualizar el _MapaTemporizador con su dirección.
La clase AsignadorEntidadFsm 192 es otra clase
que hereda de la EntidadFsm 174. El AsignadorEntidadFsm 192 es una
clase abstracta que define el comportamiento para un conjunto de una
o más EntidadFsm. Una función virtual pura de preProceso permite
realizar a una clase obtenida cualquier proceso en una EntidadFsm
asignada antes de darle el mensaje para procesar. Los atributos de
clase incluyen un IdentificadorColaDesocupada, el cual apunta al
conjunto de EntidadFsm no asignado que está disponible para la
asignación.
De forma similar, la clase
AsignadorDinámicoAgrupaciónFsm 194 hereda de AsignadorEntidadFsm 192
y define además el comportamiento para asignar un EjemploFsm de una
AgrupaciónFsm. Se utiliza también una cola desocupada para organizar
el conjunto de EjemplosFsm no asignados y disponibles.
El comportamiento de colecciones de EntidadFsm
está definido por una clase 190 de ColecciónFsm, que resume el
comportamiento de un conjunto arbitrario de EntidadFsm. La
ColecciónFsm 190 define el interfaz para añadir o eliminar la
EntidadFsm en un conjunto. Las clases de colección pueden tener un
atributo dinámico/estático, donde él mismo y su hijo pueden ser
estáticos, él mismo puede ser estático y su hijo puede ser dinámico,
o él mismo y su hijo pueden ser dinámicos. Las clases de colección
pueden ser también sin enclavamiento o con enclavamiento durante el
proceso del evento. Además, un atributo de índices de las clases de
colección puede indicar si se utiliza el IdentificadorMensaje como
índice o si el mensaje puede contener un índice. Las clases de
colección pueden ser también del tipo que utiliza un mapa para
identificar sus hijos o que utiliza una agrupación para sus hijos.
Consecuentemente, la convención nominativa de una clase de colección
puede ser:
Fsm<DINÁMICA><ENCLAVAMIENTO><ÍNDICE><TIPO>
La ColecciónFsm incluye una función asociada,
obtenerEntidadFsm, que devuelve la dirección de la entidad en la
colección que es responsable de procesar un mensaje. Una función
asociada, procesarEvento, posee el flujo lógico siguiente:
- 1.
- obtenerEntidadFsm
- 2.
- si EntidadFsm no está definida, mensaje de estar desocupada y volver
- 3.
- llamar a la función asociada procesarEvento de la EntidadFsm
- 4.
- volver.
La Figura 11 es un diagrama de jerarquía de
clases para la ColecciónFsm 190. Siguiendo la convención de nombre
anterior, la clase AgrupaciónFsm 210 es una clase que proporciona el
comportamiento de una agrupación lineal de ejemplos de EntidadFsm.
El número de entidades en la colección o conjunto puede ser
establecido durante la fase de construcción de la inicialización.
Los ejemplos de EntidadFsm en la colección están indexados por un
entero. Las funciones asociadas de AgrupaciónFsm 210 incluyen
funciones que permiten la manipulación de la agrupación. Por
ejemplo, una función asociada pública, crearAgrupación, puede ser
llamada para crear una agrupación vacía; se puede utilizar una
función asociada pública, insertarEntidad, para insertar una
EntidadFsm en la agrupación; una función asociada pública, obtener
EntidadEnÍndice, obtiene la dirección de una EntidadFsm; y la
función obtenerTamaño, es una función privada que devuelve el tamaño
de la agrupación. La función asociada de inicialización de la
AgrupaciónFsm puede tener el flujo lógico siguiente:
- 1.
- crear una nueva agrupación para mantener direcciones de objetos
- 2.
- realizar, para cada objeto de la agrupación, el método de llamada de inicialización de la entidad
- 3.
- si fallase la inicialización de cualquier objeto de la agrupación, informar de un mensaje de error
- 4.
- en otro caso, informar de mensaje de éxito.
Los parámetros requeridos para el fichero de
configuración pueden especificar el número de entidades de la
agrupación.
La clase AgrupaciónEnclavamiento 212 es una clase
que hereda de AgrupaciónFsm 210 y añade un enclavamiento de
ejecución mutua a la definición de la AgrupaciónFsm madre. El
comportamiento de enclavamiento es heredado de la clase 202 de
Enclavamiento.
La clase 214 de AgrupaciónDinámicaFsm hereda de
la AgrupaciónFsm 210 y cambia su comportamiento para admitir la
asignación dinámica de la EntidadFsm a la agrupación. La
AgrupaciónDinámicaFsm 214 desborda al método de inicialización de
AgrupaciónFsm donde añade el índice de cada elemento de la
agrupación a la cola desocupada. Ejemplos de AgrupaciónDinámicaFsm
214 actúan solamente como repositorio para los elementos de la
agrupación. La asignación de entidades de agrupaciones desocupadas
es realizada por ejemplos del AsignadorDiámicoAgrupacionesFsm 194
(Figura 10).
La clase 220 MapaFsm hereda de la ColecciónFsm
190 y define el comportamiento de una colección de EntidadFsm que
están indexadas por el IdentificadorMensaje. El IdentificadorMensaje
obtenido desde el mensaje se utiliza para indexar un mapa o
diccionario para llegar a la EntidadFsm específica para procesar el
mensaje. Por tanto, las funciones asociadas de MapaFsm 220 incluyen
la de crearDiccionario, que crea un diccionario para el mapa de
correspondencia entre IdentificadorMensaje y EntidadFsm, y la de
insertarEntidad, que inserta una EntidadFsm en el diccionario
creado. Una función asociada de obtenerIdentificadorEjemploFsm puede
tener el flujo lógico siguiente:
- 1.
- obtener el identificadorMensaje del Mensaje recibido
- 2.
- obtener la dirección de la EntidadFsm objetivo a partir del diccionario utilizando el IdentificadorMensaje
- 3.
- si no se encuentra la EntidadFsm objetivo, imprimir un mensaje de seguimiento y volver
- 4.
- en otro caso, informar de la dirección de EntidadFsm.
La clase 222 de MapaEnclavamiento hereda de
MapaFsm 220 y Enclavamiento 202 para añadir un mecanismo de
enclavamiento al MapaFsm 220.
La Figura 12 es un diagrama de contexto que
ilustra el proceso de Mensajes por agrupaciones dinámicas. Cuando se
llama a una función asociada de procesarEventos de ejemplos de
MapaFsm para recibir y procesar un primer mensaje que requiere la
asignación de una EntidadFsm, es encaminada a un ejemplo del
AsignadorDinámicoAgrupacionesFsm 194. El ejemplo del
AsignadorDinámicoAgrupacionesFsm 194 obtiene una entrada desocupada
en la agrupación y entrega el mensaje a la nueva entidad asignada
para su proceso. La CabeceraCola 222 contiene el índice del
siguiente elemento disponible en la agrupación o cola desocupada.
Los Mensajes posteriores que son recibidos por el MapaFsm 220 son
encaminados a la AgrupaciónDinámicaFsm 214.
Haciendo referencia a la Figura 13, se ilustra un
diagrama de herencia de clases de Estado. Las clases de Estado
definen el comportamiento de un EjemploFsm en un punto particular
del proceso. La técnica de definir estados como objetos elimina esta
lógica del EjemploFsm y elimina instrucciones caso/si en el código.
El estado como objeto es también capaz de encapsular el
comportamiento que reside normalmente en las funciones de evento que
provocan cambios de estado. La clase abstracta 230 de Estado Base
define el comportamiento común de todos los estados, que son
procesarEvento, entrar y salir. Como se ha descrito anteriormente,
el EjemploFsm inicia un cambio de estado cuando la dirección de un
ejemplo de IdentificadorEstado es devuelta desde una llamada
asociada a procesarEvento. Llama a la función asociada de salida del
estado actual, traduce el IdentificadorEstado en una dirección
física de objeto y llama a la función de entrada en el estado
siguiente. La clase 230 de Estado proporciona una implantación nula
de las funciones de entrada y salida, de manera que no se requieren
las clases obtenidas para utilizar los comportamientos de entrada y
salida. Las funciones asociadas de la clase 230 de Estado incluyen
además la función obtenerIdentificadorEstado, que devuelve el
IdentificadorEstado; establecerIdentificadorEstado, que cambia el
IdentificadorEstado; procesarTiempoExpiración, que proporciona un
punto de entrada para eventos de tiempo de expiración en el
estado.
La clase ComportamientoEstadoLógico 234 es una
clase que admite cambios de estado lógico para hacer de interfaz con
objetos de Eventos. Contiene un diccionario de EstadosLógicos
definidos que traduce en IdentificadoresEstado. La clase 232 de
DiccionarioEstado hereda del estado 230 y del
ComportamientoEstadoLógico 234 y proporciona el interfaz entre
EjemploFsm y objetos de Evento. Como se ha descrito anteriormente,
EjemploFsm requiere el IdentificadorEstado para cambios de estado y
Evento devuelve el EstadoLógico para cambios de estado. El
DiccionarioEstado 232 incluye una función virtual pura,
procesarEventoDiccionario, que procesa el evento y devuelve un valor
no nulo de EstadoLógico si se requiere un cambio de estado. Una
función asociada de procesarEvento tiene el flujo lógico
siguiente:
- 1.
- recoger todas las excepciones
- 2.
- llamar a la función asociada de procesarEventoDiccionario
- 3.
- traducir e informar de cualquier estado lógico devuelto por procesarEventoDiccionario
- 4.
- si se recoge una excepción, llamar a obtenerEstadoErrores
- 5.
- si se devuelve un objeto, volver a arrojar una excepción
- 6.
- en otro caso, informar sobre la dirección de EstadoErrores.
La clase 236 de ComportamientoMoore implanta el
modelo de estados de Moore donde el proceso de eventos se realiza en
el estado en contraposición al modelo de Meally en el cual el
proceso se realiza en el arco de eventos. La clase
ComportamientoMoore 236 incluye una función asociada entrarObjeto
que puede ser llamada por una clase obtenida para realizar el
proceso de entrada del estado; la función asociada salirObjeto, que
puede ser llamada por una clase obtenida para realizar el proceso de
salida del estado; la función asociada añadirObjetoEntrada, que
establece el valor de IdentificadorObjeto en los datos asociados de
entrarIdentificador; la función asociada añadirObjetoSalida, que
establece el valor de los datos asociados de IdentificadorObjeto en
salirIdentificador; y la función asociada
iniciarComportamientoMoore, que puede ser llamada por una clase
obtenida que resuelve los IdentificadoresObjeto de entrada y salida
en direcciones físicas de objetos.
La clase 234 de Moore, que hereda de la clase
ComportamientoMoore 236, implanta el modelo de estados de Moore y
define los atributos de datos _entrarEvento y _salirEvento, que son
traducidos en direcciones físicas de objetos cuando se llama a la
función asociada iniciarComportamientoMoore.
La clase 240 de ComportamientoDiccionarioEventos
proporciona un diccionario de objetos de Evento permitidos que están
indexados por IdentificadoresMensajes. La clase
EstadoDiccionarioEventos 240 incluye una función asociada de
añadirEvento, que añade un estado al diccionario; una función
asociada obtenerEvento, que proporciona un interfaz de diagnóstico
para verificar la configuración del diccionario; una función
asociada procesarMensaje, que obtiene el IdentificadorMensaje a
partir del Mensaje recibido y lo utiliza como un índice asociativo
en el diccionario de eventos para obtener la dirección del objeto de
Evento responsable de procesar el mensaje; y la función asociada
iniciarDiccionarioEventos, que resuelve el IdentificadorObjeto de
eventos en el diccionario en direcciones físicas. La función
asociada procesarMensaje tiene el siguiente flujo lógico como
ejemplo:
- 1.
- obtener IdentificadorMensaje a partir del Mensaje recibido
- 2.
- si el IdentificadorMensaje no está en el diccionario de eventos, enviar un mensaje de procesarEvento a un GestorPorDefecto, y informar del estado lógico devuelto por el GestorPorDefecto
- 3.
- en otro caso, llamar a la función asociada de procesar Eventos e informar del estado lógico devuelto.
La función asociada iniciarDiccionarioEventos
puede tener el flujo lógico siguiente:
- 1.
- Traducir el IdentificadorGestorPorDefecto en IdentificadorObjeto
- 2.
- si hay un error al traducir la dirección, procesar el error y volver
- 3.
- realizar, para cada IdentificadorObjeto del diccionario de eventos, la traducción del IdentificadorObjeto en una dirección de objeto; si hay error en la traducción, procesar el error y volver; en otro caso, informar de un mensaje de éxito.
La clase 238 de EstadoEvento hereda de
EstadoMoore 234 y de ComportamientoDiccionarioEventos 240 y actúa
como un expendedor para encaminar un mensaje al objeto de Evento
apropiado. Utilizando la clase ComportamientoDiccionarioEventos 240
como una clase madre mezclada, contiene un diccionario que establece
un mapa de correspondencia entre el IdentificadorMensaje de un
mensaje y un objeto de Evento. Si no se encuentra el
IdentificadorMensaje en el diccionario, el mensaje es encaminado a
un GestorPorDefecto.
El EstadoTemporizado 242 es una clase obtenida a
partir del EstadoEvento 238 y proporciona servicio de temporizador a
un EjemploFsm. Al entrar en un estado se inicia un temporizador y al
salir se detiene. La función de iniciar y detener el temporizador es
transparente para los métodos de usuario de entrarAplicación y
salirAplicación. El EstadoTemporizado 242 incluye una función
asociada de inicializar que puede tener el flujo lógico
siguiente:
- 1.
- llamar a la función asociada de inicializar clase madre
- 2.
- si hay un error al inicializar la clase madre, abortar y devolver a la clase madre su estado de inicialización
- 3.
- traducir _IdentificadorInterfazTemporizador a una dirección de objeto físico
- 4.
- si hay un error en la traducción, informar del error al que llama, en caso contrario informar de un mensaje de éxito
- 5.
- traducir el TiempoExpiraciónIdentificadorEvento en una dirección de objeto físico
- 6.
- si hay un error en la traducción, informar de un error al que llama, en caso contrario almacenar la dirección del objeto y informar de un mensaje de éxito.
La Figura 14 es un diagrama de herencia de clases
de Eventos. Las clases de Eventos dividen el proceso de eventos en
objetos configurados independientes del objeto de Estado. Los
objetos de Eventos pueden ser compartidos por ejemplos de Estado.
Por tanto, los ejemplos de Eventos no especifican objetos explícitos
de Estado para transiciones de estado. En su lugar, devuelven un
valor de EstadoLógico que es traducido por Estado en el
correspondiente Estado de destino. El Evento 260 de clase base es
una clase abstracta que define el interfaz para procesar un evento.
El Evento 260 define una función virtual pura, procesarEvento, que
devuelve un valor no nulo de EstadoLógico para indicar un cambio de
estado. A la función asociada procesarEvento se le suministra la
dirección de EjemploFsm, el Mensaje recibido y la dirección del
estado actual.
La clase EventoDeterminista 262 es una clase
obtenida a partir de Evento 260 y emula la gestión de eventos
deterministas devolviendo un valor constante de EstadoLógico cada
vez que se le da control. Un evento determinista fuerza también la
misma transición de estado para un estado. Puede llamarse a una
función asociada, establecerEstadoLógico para asignar un valor al
EstadoLógico.
La FunciónDeterminista 264 es una clase obtenida
a partir del Evento 260 y emula también la gestión de eventos
deterministas devolviendo un valor constante de EstadoLógico cada
vez que se le da control. La FunciónDeterminista 264 es similar a
EventoDeterminista 262, pero define el interfaz para una función que
no devuelve una indicación de cambio de estado lógico.
Pueden definirse clases adicionales 266 con
aplicaciones especializadas para heredar a partir de la clase 260 de
Evento.
La Figura 15 es un diagrama de herencia de las
clases de Mensaje. Las clases de Mensaje definen los atributos y el
comportamiento requerido para encaminar un Mensaje recibido al
gestor para un EjemploFsm, un Estado, o un Evento para procesar el
mensaje. Las clases de mensaje no definen ningún comportamiento
específico de la aplicación y admiten mensajes dinámicos y
estáticos. Un mensaje dinámico es el que es creado en base a las
necesidades y liberado cuando ha sido procesado; un mensaje estático
es el que existe permanentemente y contiene información no
alterable. Las clases de Mensaje admiten también agrupaciones de
EntidadFsm y diccionarios o mapas de EntidadFsm.
El Mensaje 270 es una clase abstracta de base
para todos los mensajes intercambiados dentro de la máquina de
estados de software. El Mensaje 270 define un identificador
simbólico exclusivo, el IdentificadorMensaje, para cada tipo de
mensaje y un interfaz para mensajes de desocupación. El Mensaje 270
puede incluir una función asociada, obtenerIdentificadorMensaje, que
es una función virtual pura que devuelve el IdentificadorMensaje
asociado con un ejemplo de objeto; Desocúpate, que es una función
virtual para solicitar que se elimine un mensaje no estático.
El MensajeEstático 272 es un mensaje interno
utilizado para enviar mensajes entre ejemplos de máquinas de estados
(EjemplosFsm). Los ejemplos de MensajesEstáticos pueden ser
utilizados cuando se desea un mecanismo de señalización eficiente y
sencillo entre EjemplosFsm.
El ComportamientoMapa 276 es una clase abstracta
que proporciona un interfaz para obtener una referencia simbólica a
una EntidadFsm que no forma parte de una agrupación. Puede llamarse
a una función virtual pura de ComportamientoMapa,
obtenerIdentificadorEntidadFsm, por las clases obtenidas para
informar de la dirección de un ejemplo de Cadena que identifique
simbólicamente el objetivo del mensaje.
El ComportamientoAgrupación 278 es una clase
abstracta que proporciona un interfaz para obtener el índice hacia
una EntidadFsm que está contenida dentro de una agrupación de
EntidadFsm. Puede llamarse a una función virtual pura de
ComporatamientoAgrupación 278, obtenerAgrupaciónFsm, para obtener el
índice de agrupación de una EntidadFsm.
El ComportamientoAplicación 280 es una clase
abstracta que proporciona un interfaz para obtener el nombre
simbólico de la aplicación que es el objetivo del mensaje. Puede
utilizarse una función virtual pura,
obtenerIdentificadorAplicaciónFsm, para obtener la dirección de un
ejemplo de Cadena que identifique simbólicamente el objetivo del
mensaje.
El MensajeMultiDimensional 274 es una clase que
se obtiene a partir de MensajeEstático 272 y se mezcla en los
interfaces definidos por ComportamientoMapa 276,
ComportamientoAgrupación 278 y ComportamientoAplicación 280. Es
requerido por ejemplos de AgrupaciónFsm y MapaFsm para determinar la
EntidadFsm dentro de su colección que es el objetivo del
mensaje.
En el futuro pueden definirse otras clases 282 de
mensajes específicos de la aplicación, que heredan de
MensajeMultiDimensional 274.
La Figura 16 es un diagrama de contexto de las
clases de fundición. Las clases de fundición se utilizan para
construir y transmitir mensajes que son intercambiados con otros
procesos u objetos dentro de este proceso. Los objetos de fundición
son fabricados a partir de objetos de fábrica de fundición y por
tanto requieren un fichero de configuración para ser creados. Una
aplicación 300 de usuario puede requerir a la Fundición 302 que
fabrique un objeto particular de EntidadFsm. La fundición responde
solicitando un ejemplo de FundiciónMensajesSalientes 306 para crear
el mensaje. Ejemplos de objetos de FundiciónMensajesSalientes 306
son fabricados por los objetos 304 de la
FábricaFundiciónMensajesSalientes como respuesta a solicitudes de la
Fundición 302. La clase 302 de Fundición es un centro de fabricación
de mensajes salientes. Es una clase contenedora de objetos del tipo
FundiciónMensajesSalientes 306. Se utiliza una función asociada,
fabricar, para dirigirse a un objeto de fundición que es responsable
de la fabricación de un mensaje y de entregar el mensaje. La función
asociada fabricar consulta el objeto de la
FundiciónMensajesSalientes que es responsable de fabricar un ejemplo
de IdentificadorMensaje recibido desde la aplicación 300 de usuario.
A continuación se ofrece un ejemplo de flujo lógico para
fabricar:
- 1.
- si un objeto de fundición no está en el diccionario de IdentificadoresMensajes, presentar un mensaje de error e informar del error
- 2.
- en otro caso, llamar a la función asociada crear del objeto situado en el diccionario e informar del estado de crear.
Se llama a otra función asociada,
añadirFundición, para añadir un objeto de FundiciónMensajeSaliente
al diccionario si no está presente ya un elemento para el
IdentificadorMensaje. A continuación se ofrece un ejemplo de flujo
lógico para añadirFundición:
- 1.
- si el diccionario ya contiene un elemento para el IdentificadorMensaje admitido, informar de un error
- 2.
- en otro caso, añadir el objeto admitido al diccionario y informar de un mensaje de éxito.
La Figura 17 es un diagrama de herencia de
FundiciónMensajeSaliente 306. La FundiciónMensajeSaliente 306 es una
clase base para objetos almacenados en Fundición 302. Los objetos
del tipo FundiciónMensajeSaliente 306 son utilizados para crear
ejemplos de objetos de mensaje que son transmitidos desde el ejemplo
en curso de EntidadFsm. Una función asociada, crear, proporciona el
interfaz público para fabricar un ejemplo de mensaje saliente. Crear
puede tener, por ejemplo, el siguiente flujo lógico:
- 1.
- crear objeto de mensaje vacío
- 2.
- si no se puede crear el mensaje, informar de un fallo
- 3.
- construir mensaje obtenido
- 4.
- si no se construye el mensaje, informar de un fallo
- 5.
- en caso contrario, enviar mensaje e informar del éxito.
La FundiciónMensajeSaliente 306 incluye también
una función virtual pura, enviar, para enviar el mensaje creado a su
punto de destino.
La FundiciónMensajePuerto 308 es una clase
obtenida desde la FundiciónMensajeSaliente 306 y admite la creación
de mensajes que son transmitidos desde un ejemplo 310 de MapaPuerto.
Cuando se llama al método de creación de la FundiciónMensajePuerto
308, fabrica un ejemplo de MensajeOS, el cual es transmitido a
través del ejemplo 310 de MapaPuerto. Esto puede observarse en el
diagrama de contexto de la Figura 18. La FundiciónMensajePuerto 308
puede incluir una función asociada de inicialización, que puede
tener el siguiente flujo lógico:
- 1.
- llamar al método madre de inicialización
- 2.
- si falla la llamada de la inicialización madre, informar de un fallo
- 3.
- si no se especifica el IdentificadorObjeto de Puerto, hay error y se devuelve un fallo
- 4.
- obtener dirección del objeto Puerto a partir del DiccionarioObjetos
- 5.
- si no se puede encontrar el objeto en DiccionarioObjetos, informar de un error
- 6.
- en caso contrario, informar de un éxito.
La Figura 19 es un diagrama de contexto de clases
de órdenes y la Figura 20 es un diagrama de herencia de las mismas.
Las clases de órdenes proporcionan un marco para un interfaz de
usuario en el proceso. Los objetos de órdenes encapsulan el
comportamiento requerido para una orden individual. Todos los
objetos de órdenes descienden de la clase abstracta Orden 324. Los
objetos de órdenes son objetos simples que son creados y colocados
en un DiccionarioÓrdenes 322 antes de la llamada al principal.
TrenzadoÓrdenes 320 recibe un objeto Cadena que contiene el
contenido de una orden. TrenzadoÓrdenes 320 llama una función
asociada, ejecutar, del DiccionarioÓrdenes 322, que el interfaz
público que analiza la orden, pasa testigos a la cadena de órdenes
(PasadorTestigosRWC), y consulta en el diccionario si la orden está
contenida en él. Si está en el diccionario, ejecuta la función
asociada de ejecutar objeto de orden. Una función asociada de Orden
324, ejecutar, define el interfaz para ejecutar la orden encapsulada
en el ejemplo de objeto.
Una clase 326 de OrdenControlSeguimiento es una
clase obtenida de Orden 324. Una función asociada, ejecutar, de
OrdenControlSeguimiento 326 puede tener el siguiente ejemplo de
flujo lógico:
- 1.
- obtener una opción de nuevo estado de seguimiento a partir de orden
- 2.
- si el estado de seguimiento no está especificado, informar de un error y volver
- 3.
- convertir el estado del seguimiento en mayúsculas
- 4.
- si el nuevo estado de seguimiento es HABILITAR, entonces habilitar el seguimiento para el objeto de seguimiento global
- 5.
- en caso contrario, si el nuevo estado es INHABILITAR, entonces inhabilitar el seguimiento para el objeto de seguimiento global
- 6.
- en otro caso, informar de un error.
Otra función asociada de OrdenControlSeguimiento
326 es secuenciaCadena, que define el interfaz para volcar el
contenido de la orden en un objeto en cadena. Como puede ser
definida como una función virtual, se espera que las clases
obtenidas desborden a la implantación madre, pero llaman a la
implantación madre como parte de su implantación.
Una clase obtenida de Orden 324 es la clase 328
OrdenObjetoSeguimiento. OrdenObjetoSeguimiento 326 encapsula la
orden de usuario de ObjetoSeguimiento para controlar el seguimiento
de objetos dentro del DiccionarioObjetos. Si el IdentificadorObjeto
obtenido desde la orden es TODO, entonces el estado de seguimiento
de todos los objetos del DiccionarioObjetos está afectado como
HABILITAR o INHABILITAR, según se especifique en la orden.
La OrdenVolcarObjeto 330 es una clase obtenida de
Orden 324 y es responsable de la ejecución de una orden de usuario,
VolcarObjeto.
La Figura 21 es un diagrama de contexto para
clases de Temporizador y la Figura 22 es un diagrama de herencia
para las clases de cola del temporizador. La clase 350 de
Temporizador es una clase que puede ser utilizada para controlar la
creación y expiración de los temporizadores. Mantiene un conjunto de
contadores que se añaden o eliminan individualmente por medio de
trenzados externos. El Temporizador 350 admite actividades de
temporización que no están restringidas a expiraciones de tiempo de
estado o de evento. El temporizador 350 está diseñado para hacer
mínimo el tiempo requerido para insertar y eliminar elementos y
también para gestionar el decremento de los temporizadores, y para
detectar y procesar las expiraciones de tiempo. Se gana eficiencia
utilizando múltiples colas de temporización para reducir la longitud
media de cada cola. Una función asociada a la inicialización del
Temporizador 350 crea una agrupación 352 de 2^{n} ejemplos
353-356 de CabeceraTemporizador. Las
CabecerasTemporizador 353-356 están enlazadas juntas
por medio del atributo _siguienteCabeceraTemporizador para formar
una lista circular. La agrupación 352 de CabecerasTemporizador
353-356 se utilizan para implantar un algoritmo de
aleatoriedad que utiliza el bit "n" menos significativo del
recuento de tiempo deseado como un índice en la agrupación 352. El
ElementoTemporizador 361-363 forma una agrupación o
cola 360 de temporizadores mantenidos por el Temporizador 350. La
clase ElementoTemporizador proporciona el interfaz para aislar las
acciones a realizar cuando expira el recuento del elemento
temporizador.
El Temporizador 350 incluye una función asociada
de marcado denominada ejemplo de TrenzadoTemporizador para cada
progresión del marcado del temporizador. La función asociada de
Marcado enclava el temporizador 350 y examina la
CabeceraTemporizador a la que se dirige actualmente el Temporizador
350, y si la CabeceraTemporizador actual tiene uno o más
ElementoTemporizador 360 en su cola, la función marcar disminuye el
contador de todos los ElementosTemporizador en la cola que tenga un
recuento mayor que cero. Los ElementosTemporizador con un recuento
de cero antes de ser disminuidos son eliminados para el proceso la
expiración de tiempo. La función asociada procesarExpiraciónTiempo
del ProgramadorTemporizador 378 es llamada después de haber
eliminado el ElementoTemporizador cuyo tiempo ha expirado de la cola
de CabeceraTemporizador. Entonces, la función asociada de marcar
avanza a la siguiente CabeceraTemporizador en la lista circular.
Tras 2^{n} llamadas a la función marcar, vuelve a hacerse un ciclo
de todas las colas ElementoTemporizador a las que apuntan todas las
CabecerasTemporizador, se disminuyen y se procesan los tiempos de
expiración.
El Temporizador 350 tiene una función asociada a
inicializar que puede tener el siguiente flujo lógico:
1. llamar al estado madre de inicialización
2. si falla la inicialización madre, volver al
estado madre de inicialización
3. crear una agrupación de
CabeceraTemporizador
4. si falla la creación de la agrupación de
CabeceraTemporizador, informar de un fallo
5. enlazar juntas las CabecerasTemporizador en
una lista circular
6. inicializar el atributo CabeceraColaActual
para iniciar una cadena circular
7. informar de un éxito.
Una función asociada de añadirTemporizador del
Temporizador 350 tiene por ejemplo el siguiente flujo lógico:
1. calcular valores del contador LSB (bit menos
significativo) y de MSB (bit más significativo)
2. Enclavar el Temporizador
3. obtener el número actual de
CabeceraTemporizador
4. añadir contador de LSB al número actual de
CabeceraTemporizador (número MOD de CabecerasTemporizador) para
producir una CabeceraTemporizador donde se añadirá el
ElementoTemporizador
5. almacenar el valor MSB en el
ElementoTemporizador
6. añadir ElementoTemporizador al final de la
cola CabeceraTemporizador
7. Desenclavar el Temporizador.
Haciendo referencia nuevamente a la Figura 22, la
clase 370 de ElementoCola es la definición de clase base para todos
los objetos que pueden ser almacenados en una cola doblemente
enlazada. La clase 370 de ElementoCola incluye muchos métodos de
manipulación o de acceso a colas, tales como obtenerSiguiente,
obtenerPrevio, añadirSiguiente, añadirPrevio, eliminarElemento,
Desocúpate, etc. La ColaContador 372 es una clase obtenida a partir
de ElementoCola 370 y es la clase base para elementos de cola
manipulados por el Temporizador 350. Las clases ilustradas en la
Figura 22 son creadas dinámicamente por clases tales como
Temporizador 350 y, típicamente, no son fabricadas directamente a
partir de un fichero de configuración. Los ejemplos de ColaContador
372 contienen un atributo de contador que determina el tiempo
restante antes de que el elemento expire o termine su tiempo.
ColaContador define un atributo _recuento como valor entero y
funciones asociadas para manipular o acceder el valor de _recuento.
Estas funciones asociadas incluyen establecerRecuento,
obtenerRecuento, dismRecuento, restarRecuento e incrementarRecuento.
La función asociada restarRecuento es capaz de reducir el recuento
por un valor admitido, mientras que la función dismRecuento
disminuye el recuento en uno.
Como se ha descrito anteriormente,
ElementoTemporizador 374 es una clase abstracta para Temporizadores
mantenida por Temporizador 350. ElementoTemporizador 374 obtiene
parte de su comportamiento a partir de ColaContador 372.
CabeceraTemporizador 376 es una clase obtenida a partir de
ColaContador 372 y de Enclavamiento 202.
El ProgramadorTemporizador 378 hereda de
ElementoTemporizador 374 y es responsable de añadir un ejemplo de
EventoFsmProgramado al final de la cola de ElementoTemporizador
cuando se llama a la función asociada procesarTiempoExpiración. Se
supone que los ejemplos de ProgramadorTemporizador están asignados
permanentemente a un FSM específico y por tanto no son creados ni
destruidos dinámicamente.
La Figura 23 es un diagrama de herencia de
objetos de la cola. Como se ha descrito anteriormente, la clase
ElementoCola 370 define los atributos y comportamiento requeridos
para mantener listas enlazadas de objetos. Las clases de cola de
Temporizador ilustradas en la Figura 22 obtuvieron sus
comportamientos de cola a partir de ElementoCola 370.
ElementoColaEnclavada 372 es una clase que añade un enclavamiento de
exclusión mutua con ElementoCola, su definición de clase madre.
ActividadProgramada 373 es la clase base para
todas las clases que implanta el proceso programado. La programación
es requerida para gestionar ejemplos múltiples de FSMS. Por otro
lado, se requiere un trenzado de ejecución para cada FSM. El proceso
de la programación es deseable también para dividir el contexto de
la ejecución. Secuencias específicas de eventos pueden rebasar la
pila si el contexto de la ejecución no es dividido en actividades
independientes. La programación del proceso de una
ActividadProgramada es una clase base abstracta y define la función
asociada ejecutar-Actividad, que es el interfaz
común para realizar el proceso requerido.
La clase MensajeProgramado 375 es una clase
obtenida a partir de ActividadProgramada 373 y puede ser utilizada
para gestionar un mensaje que ha sido programado para
ejecutarse.
La clase EventoFsmProgramado 377 es una clase
obtenida a partir de ActividadProgramada 373. Se crea un ejemplo de
EventoFsmProgramado cuando se va a procesar un mensaje para un
EjemploFsm específico. Se crea un ejemplo 377 de EventoFsmProgramado
cuando un EjemploFsm tiene un mensaje o un evento para otro
EjemploFsm y se requiere una división del contexto. Los ejemplos de
EventoFsmProgramado se utilizan típicamente para la comunicación
interna en las máquinas de estados jerárquicas. Las divisiones de
contextos son requeridas para la comunicación entre EjemplosFsm que
pueden enviar mensajes en ambas direcciones. Solamente el EjemploFsm
tiene permitido llamar directamente a la función asociada
procesarMensaje del EjemploFsm relacionado. El segundo EjemploFsm
debe programar también sus mensajes. Por otro lado, pueden
introducirse bucles de ejecución que pueden desbordar la pila. El
EventoFsmProgramado 377 tiene un atributo _fsm que mantiene la
dirección del EjemploFsm asignado para procesar el mensaje;
_mensaje, que mantiene la dirección del ejemplo de Mensaje a
procesar. Su función asociada ejecutarActividad llama a la función
asociada procesarEvento del objeto de _fsm para procesar el
mensaje.
CabeceraCola 380 obtiene su comportamiento a
partir de ElementoCola 370 y de Objeto 170 y pueden utilizarse
ejemplos de la misma para almacenar y recuperar elementos en un
orden FIFO (primero en entrar, primero en salir) o en un orden LIFO
(último en entrar, primero en salir). Su atributo _siguiente
contiene la dirección del primer elemento de la cola, mientras que
_previo contiene la dirección del último elemento de la cola. Una
cola está vacía si el contenido de _siguiente y _previo es igual a
la dirección de la cabecera de la cola. ColaCabacera 380 proporciona
además otra manipulación de colas y funciones de acceso asociadas.
ColaEnclavada 382 es una derivación de CabeceraCola 380 y de
Enclavada 202 y añade un enclavamiento mutuamente exclusivo a la
definición de clase de CabeceraCola.
ColaEspera 384 es una clase abstracta que define
el interfaz para esperar una cola vacía. EsperarCola 384 puede ser
utilizada en entornos multiproceso donde se requieren llamadas del
sistema operativo para desplazamientos de contextos o aplicaciones
de primer plano/segundo plano donde el programa puede hacer un bucle
si la cola está vacía. EsperarCola 384 define una función virtual
pura de espera que puede ser llamada para eliminarÚltimo y
eliminarPrimero si la cola está vacía. Esperar suspende el proceso o
tarea en un entorno multiproceso o simplemente vuelve en
aplicaciones de proceso en primer plano o en segundo plano. Otra
función virtual pura, señalizar, es llamada por añadirPrimero y
añadirÚltimo cuando se añade un elemento a una cola desocupada.
Señalizar deja lista la primera tarea suspendida que está esperando
a un elemento de la cola.
SemáforoCola 386 hereda de EsperarCola 364 y
contiene un objeto de Semáforo utilizado para suspender un trenzado
mientras está esperando que se añada un elemento a la cola.
SemáforoCola implanta funciones virtuales puras y la de señalizar
definida por EsperarCola 384.
La Figura 24 es un diagrama de herencia para las
clases de Trenzado. La plataforma de aplicación puede no imponer
ninguna arquitectura preconcebida sobre la aplicación del usuario.
Por tanto, no se crea ningún trenzado a menos que estén
especificados en los ficheros de configuración del usuario. Cada
trenzado es un objeto manufacturado. La clase 392 de Trenzado es la
clase base abstracta para todos los objetos de tipo trenzado. La
clase 392 de trenzado mezcla el comportamiento de Objeto 170 y de
ComportamientoTrenzado 390. ComportamientoTrenzado 390 contiene
todos los interfaces requeridos para iniciar y detener un trenzado.
Como ComportamientoTrenzado es una mezcla, su comportamiento puede
ser reutilizado en aplicaciones que no desean el comportamiento
generalizado proporcionado por la plataforma de aplicación. El
Trenzado 392 incluye la función asociada iniciarEjecución para crear
un trenzado de control para un ejemplo de un objeto descendiente de
Trenzado. Cuando se crea un trenzado de control, añade su objeto de
Trenzado asociado a un DiccionarioTrenzado global. Todos los
trenzados son accesibles a partir del DiccionarioTrenzado por su
IdentificadorTrenzado. El control después de la terminación del
trenzado está admitido en la clase MonitorTrenzado 398. Si se crea
un ejemplo de MonitorTrenzado 398, el trenzado se suspende en una
llamada trenz_unión. Si un trenzado sale a través de una llamada
trenz_salir, es activado con el IdentificadorTrenzado del trenzado
que termina. Si se almacena un objeto de trenzado en el
DiccionarioTrenzado con el IdentificadorTrenzado, se llama a su
función asociada trenzarSalida. A continuación se describen clases
de objetos de Trenzado con más detalle.
TrenzadoPrincipal 394 hereda de Trenzado 392 y de
Enclavamiento 202, y proporciona un interfaz general para obtener
MensajesOs desde un GestorColas 410, y convertirlos en Mensajes y
darles una EntidadMáquinaestados para procesarlos, como se ilustra
en la Figura 25. El TrenzadoPrincipal 394 define una función virtual
pura de la cual deben implantarse las clases derivadas para
convertir los ejemplos de MensajesOs en un tipo de Mensaje.
TrenzadoPrincipal 394 incluye una función asociada trenzarInicio,
que puede tener el flujo lógico siguiente:
- 1.
- hacer siempre
- 2.
- obtener un MensajeOS a partir del GestorColas
- 3.
- si hay un error al obtener el MensajeOS, enviar un mensaje de seguimiento al objeto de cpSeguimientoY-Evento
- 4.
- convertir el MensajeOS en un Mensaje (fabricar Mensaje)
- 5.
- enviar procesarMensaje a un GestorMáquinaEstados
- 6.
- terminar hacer.
La función asociada obtenerMensaje se utiliza en
el paso 2 anterior para recibir un MensajeOS desde la cola por
defecto de MapaPuerto. La función asociada fabricarMensaje es una
función virtual pura que implanta un interfaz para informar de un
tipo de Mensaje cuando pasa un ejemplo de MensajeOS.
El TrenzadoTemporizador 400 es otra clase que se
obtiene a partir de Trenzado 392. TrenzadoTemporizador 400 es uno de
los dos trenzados de control que se requieren para la ejecución del
objeto Temporizador dentro de un entorno de programación UNIX. Se
utilizan dos trenzados para asegurar que se ejecuta la función
asociada marcar del Temporizador a una velocidad media constante.
TrenzadoTemporizador es responsable de señalizar
TrenzadoTemporizadorEsclavo 414 a intervalos de marcado constantes,
como se ve en la Figura 26. TrenzadoTemporizador 400 contiene un
simple bucle de ejecución que se retrasa en un sistema de
interrogación en el intervalo requerido entre marcas del
Temporizador. Tras despertar de su estado suspendido, el
TrenzadoTemporizador llama a su función asociada de marcación de
TrenzadoTemporizadorEsclavo antes de suspenderse nuevamente. El
TrenzadoTemporizadorEsclavo 414 es el contexto bajo el cual se
realizan las actualizaciones del temporizador Temporizador. El
TrenzadoTemporizadorEsclavo contiene un objeto semáforo que es
incrementado por TrenzadoTemporizador 400 cuando llama a la función
asociada de marcación de TrenzadoTemporizadorEsclavo. El
TrenzadoTemporizadorEsclavo 414 se suspende en el semáforo entre
llamadas a la función asociada de marcación del Temporizador 350. El
intervalo entre la suspensión de TrenzadoTemporizadorEsclavo no
puede ser controlada debido a la naturaleza aleatoria del trabajo
que debe realizar interno al Temporizador 350. Sin embargo, el
estado del semáforo asegura que no se pierden marcaciones del
temporizador.
TranzadoCola 396 es una clase obtenida a partir
de Trenzado 392 y es responsable de recibir MensajesOS desde un
trenzado o proceso 422 basado en colas y los transmite al gestor
420 de mensajes de una aplicación no residente a través de un
conector. Esto puede verse en la Figura 27.
TrenzadoClienteCola 402 es una clase obtenida a
partir de Trenzado 392 y es responsable de recibir los MensajesOS
del gestor 420 de mensajes de una aplicación no residente y
transmitirlos a una tarea o proceso de la aplicación a través de un
conector, como se ilustra en la Figura 28.
TrenzadoExpendedor 404 es otra clase obtenida de
Trenzado 394. TrenzadoExpendedor 404 admite la ejecución de trabajo
programado interno al proceso. Dos ejemplos de EntidadFsm pueden
programar el proceso de mensajes entre sí creando un ejemplo de
ActividadProgramada 374 y añadiéndolo a la CabeceraCola supervisada
por los ejemplos de TrenzadoExpendedor. Esto se ilustra en la Figura
29. Uno o más ejemplos de TrenzadoExpendedor 404 pueden obtener
ejemplos de ActividadProgramada 374 a partir de CabeceraCola 380.
Una función asociada de ejecutarActividad de cada ejemplo de
ActividadProgramada es llamada antes de solicitar que el objeto se
desocupe. El TrenzadoExpendedor 404 es necesario para dividir el
contexto de la ejecución para el proceso de tiempos de expiración y
situaciones que impliquen el proceso de mensajes internos enviados
entre objetos en la aplicación. Sin el uso de TrenzadoExpendedor,
pueden tener lugar condiciones de parada.
La Figura 30 es un diagrama de herencia de clases
de objeto de seguimiento. Se proporcionan dos clases de seguimiento
independientes de la plataforma. El Seguidor 430 proporciona la
habilitación o inhabilitación del seguimiento en todo el sistema.
Cuando un objeto Seguidor está en el estado inhabilitado, no se
ejecutan instrucciones de seguimiento. El estado de seguimiento
puede ser cambiado a través de llamadas a las funciones asociadas
habilitarSeguimiento y de inhabilitarSeguimiento. SeguidorRegulado
432 se obtiene a partir de Seguidor 430 y admite regulación dinámica
o detención de mensajes de seguimiento en situaciones de sobrecarga.
Define funciones asociadas para habilitar, inhabilitar, iniciar y
detener la regulación. Las Figuras 31A y 31B ilustran el flujo de
ejecución durante los estados de seguimiento habilitado e
inhabilitado. Las Figuras 32A a 32C ilustran el flujo de ejecución
durante los estados de regulación inhabilitada, regulación inactiva
y regulación activada.
La Figura 33 es un diagrama de herencia de clases
de objeto de seguimiento. El conjunto de objetos de seguimiento
encapsula los datos que han de imprimirse en una operación de
seguimiento. El ObjetoSeguimiento 460 es la clase base y define el
interfaz para encadenar los datos de seguimiento en una cadena de
seguimiento del sistema operativo. El ObjetoSeguimientoEstado 464 es
una clase obtenida a partir de ObjetoSeguimiento 460 y encapsula los
mensajes de seguimiento que han de imprimirse para indicar cambios
de estado.
La Figura 34 es un diagrama de herencia de clase
de fábrica de estados. Los objetos de fábrica son responsables de la
creación de un ejemplo de una clase específica. Cada ejemplo de una
clase que pueda ser creado a partir de un fichero de configuración
es creado por un objeto de fábrica. Los objetos de fábrica son
referenciados en todo el objeto global de Fábrica. Un ejemplo
estático de cada tipo de objeto de fábrica es creado y añadido a
Fábrica antes de introducir el principal. Todos los objetos de
fábrica son obtenidos de la clase abstracta FábricaObjetos 490.
FábricaObjetos 490 define el interfaz para crear un objeto de una
clase específica. Su función asociada, crear, es llamada por Fábrica
para fabricar un ejemplo. La función asociada crear está después del
nombre del fichero de configuración que define los valores de todos
los atributos requeridos por el objeto. La función asociada crear
llama a la función virtual pura crearObjeto para crear un ejemplo
vacío del objeto, y después llama a la función virtual pura
construirObjetoDerivado para configurar los atributos del objeto
como se especifica en el fichero de configuración.
FábricaEstados 492 es una clase obtenida a partir
de FábricaObjetos 490. FábricaEstados 492 es una clase abstracta de
fábrica para crear ejemplos de Estados. FábricaEstados configura el
ejemplo de estado con el IdentificadorEstado obtenido del fichero de
configuración. Una función asociada construirObjetoDerivado puede
tener el siguiente flujo lógico:
- 1.
- llamar a la clase madre construirObjetoDerivado
- 2.
- si la clase madre construir falla, devolver una dirección de objeto nulo
- 3.
- obtener IdentificadorEstado a partir del fichero de configuración
- 4.
- si no se puede obtener el IdentificadorEstado, encadenar un mensaje de error, eliminar el objeto y devolver una dirección de objeto nulo
- 5.
- almacenar IdentificadorEstado en el ejemplo del nuevo estado
- 6.
- devolver dirección del ejemplo del nuevo estado.
FábricaEstadosDiccionario 494 es una clase
abstracta de fábrica para crear ejemplos de EstadosDiccionario y
hereda de FábricaEstados 492 y FábricaComportamientoEstadoLógico
496. El EstadoDiccionario contiene EstadosLógicos para los mapas de
correspondencia de IdentificadorEstados. Una función asociada,
construirObjetoDerivado, de la FábricaEstadosDiccionario puede tener
el flujo lógico siguiente:
- 1.
- llamar a la clase madre construirObjetoDerivado
- 2.
- si la clase madre construir falla, devolver una dirección de objeto nulo
- 3.
- obtener el número de elementos en el diccionario a partir del fichero de configuración
- 4.
- si hay un error al obtener el número de elementos, eliminar el objeto y volver
- 5.
- efectuar para el número de elementos del fichero de configuración:
- 6.
- obtener EstadoLógico a partir del fichero de configuración
- 7.
- si hay un error al obtener el EstadoLógico, encadenar un mensaje de error, eliminar el objeto y volver
- 8.
- obtener IdentificadorEstado a partir del fichero de configuración
- 9.
- si hay un error al obtener el IdentificadorEstado, encadenar un mensaje de error, eliminar el objeto y volver
- 10.
- añadir la pareja de EstadoLógico e IdentificadorEstado al DiccionarioObjetos
- 11.
- si hay un error al añadir, eliminar el objeto y devolver un nulo
- 12.
- terminar efectuar
- 13.
- devolver ejemplo de objeto.
FábricaEstadosMoore 498 es una clase obtenida a
partir de FábricaEstadosDiccionario 494 y crea ejemplos de
EstadoMoore a partir de un fichero de configuración. Su función
asociada construirObjetoDerivado llama al método madre
construirObjetoDerivado para crear el objeto y obtiene un
IdentificadorObjeto a partir del fichero de configuración para
almacenarlo en el objeto creado.
FábricaEstadosEvento 500 hereda de
FábricaEstadosMoore 498 y crea ejemplos de EstadoEvento a partir de
un fichero de configuración. Su función asociada
construirObjetoDerivado puede tener el flujo lógico siguiente:
- 1.
- llamar clase madre construirObjetoDerivado
- 2.
- si clase madre construir falla, devolver una dirección de objeto nulo
- 3.
- efectuar para cada objeto de evento del fichero de configuración:
- 4.
- obtener IdentificadorMensaje a partir del fichero de configuración
- 5.
- si hay un error al obtener el IdentificadorMensaje, encadenar un mensaje de error, eliminar el objeto y volver
- 6.
- obtener IdentificadorObjeto a partir del fichero de configuración
- 7.
- si hay un error al obtener el IdentificadorObjeto, encadenar un mensaje de error, eliminar el objeto y volver
- 8.
- añadir la pareja de EstadoLógico e IdentificadorEstado al DiccionarioObjetos de evento
- 9.
- si hay un error al añadir, encadenar mensaje de error, eliminar el objeto y devolver dirección de objeto nulo
- 10.
- terminar efectuar
- 11.
- devolver dirección de objeto.
FábricaEstadosTemporizados 502 es una clase
obtenida a partir de FábricaEstadosEvento 500.
FábricaEstadosTemporizados crea ejemplos de EstadoTemporizado a
partir de un fichero de configuración.
La Figura 35 es un diagrama de herencia de
objetos de FábricaEventos. FábricaEventos 510 es una clase abstracta
para crear ejemplos de Evento. FábricaEventos 510 define el interfaz
para crear un ejemplo de una clase en las clases de Evento.
FábricaEventosDeterministas 512 es una clase de fábrica para crear
ejemplos de EventosDeterministas. FábricaFuncionesDeterministas 514
es una clase de fábrica para crear ejemplos de
FuncionesDeterministas. Tanto FábricaEventosDeterministas 512 como
FábricaFuncionesDeterministas 512 tienen las funciones asociadas
construirObjetosDerivados para crear el objeto, obtiene el
EstadoLógico a partir de un fichero de configuración y almacena el
EstadoLógico en el objeto creado. En el futuro pueden definirse
otras clases 516.
La Figura 36 es un diagrama de herencia de clases
de fábrica de EntidadFsm. La FábricaEntidadesFsm 530 es una clase
abstracta de fábrica para crear ejemplos de EntidadFsm. La
FábricaEntidadesFsm 530 define el interfaz para crear un ejemplo de
una clase en la familia de EntidadFsm. La FábricaColecciónFsm 532
hereda de la FábricaEntidadesFsm 530 y es responsable de crear
ejemplos de objetos de ColecciónFsm. La FábricaAgrupacionesFsm 534
hereda de FábricaColecciónFsm 532 y es responsable de crear ejemplos
de objetos de AgrupacionesFsm. Su función asociada
construirObjetoDerivado puede tener el flujo lógico siguiente:
- 1.
- llamar a la clase madre construirObjetoDerivado
- 2.
- si la clase madre construir falla, devolver la dirección de un objeto nulo
- 3.
- obtener el número de elementos de la agrupación
- 4.
- si hay un error, encadenar mensaje de error, eliminar el objeto y devolver una dirección de objeto nulo
- 5.
- crear agrupación vacía
- 6.
- si hay un error al crear la agrupación, encadenar mensaje de error, eliminar objeto y devolver una dirección de objeto nulo
- 7.
- efectuar para cada elemento de la agrupación:
- 8.
- obtener el nombre del fichero de configuración para el elemento del fichero de configuración
- 9.
- si hay un error al obtener el nombre del fichero de configuración, encadenar un mensaje de error, eliminar objeto y devolver una dirección de objeto nulo
- 10.
- solicitar que Fábrica construya un ejemplo de objeto especificado en el fichero de configuración
- 11.
- si hay un error en la construcción, devolver una dirección de objeto nulo
- 12.
- almacenar la dirección del objeto del elemento de la agrupación
- 13.
- terminar efectuar
- 14.
- devolver dirección de objeto de la agrupación.
FábricaAgrupaciónGrandeFsm 538 es también una
clase obtenida a partir de FábricaColecciónFsm 532.
FábricaAgrupaciónGrandeFsm proporciona la definición del interfaz
para todos los objetos de AgrupaciónGrandeFsm que se obtienen
directa o indirectamente de la FábricaAgrupaciónGrandeFsm.
FábricaAgrupaciónGrandeFsm define los interfaces requeridos para
construir los atributos definidos por AgrupaciónGrandeFsm a partir
de un fichero de configuración. Su función asociada
construirObjetoDerivado puede tener el siguiente flujo lógico:
- 1.
- llamar a la clase madre construirObjetoDerivado
- 2.
- construir atributos definidos primero en la clase base
- 3.
- si se devuelve la dirección del objeto nulo, devolver dirección de objeto nulo
- 4.
- si hay un error en la construcción de la clase base, volver
- 5.
- obtener el número de entidades en la agrupación
- 6.
- obtener el nombre del fichero de configuración utilizado para crear un EjemploFsm
- 7.
- si hay un error al obtener el nombre del fichero de configuración, encadenar un mensaje de error, eliminar el objeto creado parcialmente y volver
- 8.
- crear agrupación vacía
- 9.
- si hay un error al crear la agrupación dentro del objeto, encadenar mensaje de error, eliminar el objeto construido parcialmente y volver
- 10.
- efectuar para cada entidad de la agrupación:
- 11.
- fabricar un ejemplo de entidad
- 12.
- si falla la fabricación, eliminar el objeto de agrupación creado parcialmente y volver
- 13.
- añadir objeto a la agrupación
- 14.
- si hay un error al añadir la entidad a la agrupación, eliminar la agrupación creada parcialmente y volver
- 15.
- terminar efectuar
- 16.
- devolver dirección de agrupación.
FábricaMapasFsm 542 hereda de la
FábricaColecciónFsm 532 y es una clase que crea ejemplos de MapaFsm
y devuelve la dirección del objeto. FábricaAgrupaciónEnclavamiento
536 hereda de FábricaAgrupaciónFsm 534 y crea ejemplos de
AgrupaciónEnclavamiento. FábricaAgrupaciónDinámicaFsm 540 hereda de
FábricaAgrupaciónGrandeFsm 538 y crea ejemplos de
AgrupaciónDinámicaFsm. FábricaMapasEnclavamiento 542 hereda de
FábricaMapasFsm 542 y crea ejemplos de MapaEnclavamiento.
FábricaAsignadorEntidadFsm 550 hereda de
FábricaEntidadFsm 530 y crea ejemplos de AsignadorEntidadFsm a
partir de un fichero de configuración. Su función asociada
construirObjetoDerivado puede tener el siguiente flujo lógico:
- 1.
- llamar a la clase madre construirObjetoDerivado
- 2.
- construir atributos definidos primero en la clase base
- 3.
- si se devuelve la dirección de un objeto nulo, devolver dirección de objeto nulo
- 4.
- si hay un error en la construcción de la clase base, volver
- 5.
- obtener la cola desocupada IdentificadorObjeto a partir del fichero de configuración
- 6.
- si hay un error al obtener el IdentificadorObjeto, encadenar un mensaje de error, eliminar objeto y volver
- 7.
- almacenar IdentificadorObjeto en el objeto
FábricaAsignadorAgrupaciónDinámicaFsm 552 hereda
de FábricaAsignadorEntidadFsm 550 y crea ejemplos de
AsignadorAgrupaciónDinámicaFsm a partir de un fichero de
configuración. FábricaEjemplosFsm 554 hereda de FábricaEntidadesFsm
530 y crea ejemplos de EjemplosFsm obteniendo los
IdentificadoresEstado a partir del fichero de configuración.
FábricaEjemplosTemporizadosFsm 556 hereda de FábricaEjemplosFsm 554
y crea ejemplos de EjemploTemporizadoFsm.
La Figura 37 es un diagrama de herencia de clase
de fábrica de Trenzado. FábricaTrenzado 570 hereda de FábricaObjetos
490 y de FábricaComportamientoTrenzado 572 y crea ejemplos de
Trenzado a partir del fichero de configuración.
FábricaComportamientoTrenzado 572 incluye una función asociada
construirObjetoDerivado que puede tener el flujo lógico
siguiente:
- 1.
- obtener nombre del trenzado
- 2.
- si no puede acceder al elemento, imprimir un mensaje de error, eliminar objeto, volver
- 3.
- almacenar nombre del trenzado en el objeto
- 4.
- obtener atributo TAMAÑO_PILA a partir del fichero de configuración
- 5.
- si se especifica el TAMAÑO_PILA, convertir TAMAÑO_PILA en un valor entero
- 6.
- si hay un error en la conversión, imprimir mensaje de error
- 7.
- obtener atributo PRIORIDAD_TRENZADO a partir del fichero de configuración
- 8.
- si se especifica la PRIORIDAD_TRENZADO, convertir PRIORIDAD_TRENZADO en un entero
- 9.
- si hay un error en la conversión, imprimir mensaje de error
- 10.
- obtener atributo ESTADO_LIGADO a partir del fichero de configuración
- 11.
- si se especifica la PRIORIDAD_TRENZADO, si el valor es VERDADERO o FALSO, almacenar el nuevo valor en el objeto, en otro caso, imprimir mensaje de error y volver
- 12.
- obtener atributo ESTADO_TIEMPO_REAL a partir del fichero de configuración
- 13.
- si se especifica ESTADO_TIEMPO_REAL, convertir a un entero
- 14.
- si hay un error en la conversión, imprimir mensaje de error
- 15.
- obtener atributo ESTADO_TIEMPO_COMPARTIDO a partir del fichero de configuración
- 16.
- si se especifica ESTADO_TIEMPO_COMPARTIDO, convertir en un entero
- 17.
- si hay un error en la conversión, imprimir mensaje de error.
FábricaTrenzadoPrincipal 574 hereda de
FábricaTrenzado 570 y crea ejemplos de TrenzadoPrincipal a partir de
un fichero de configuración. Su función asociada
construirObjetoDerivado puede tener el flujo lógico siguiente:
- 1.
- llamar a la clase madre construirObjetoDerivado
- 2.
- construir atributos definidos en la clase base
- 3.
- si se devuelve la dirección del objeto nulo, devolver dirección de objeto nulo
- 4.
- obtener Identificador de GestorColas a partir del fichero de configuración
- 6.
- si hay un error al obtener el Identificador de GestorColas, eliminar objeto y volver
- 7.
- almacenar IdentificadorObjeto en el objeto
- 8.
- obtener Identificador EntidadFsm a partir del fichero de configuración
- 9.
- si hay un error al obtener el Identificador de EntidadFsm, eliminar objeto y volver
- 10.
- almacenar IdentificadorObjeto en el objeto.
FábricaTrenzadoCola 576 hereda de FábricaTrenzado
570 y crea ejemplos de TrenzadoCola a partir de un fichero de
configuración. Su función asociada construirObjetoDerivado puede
tener el flujo lógico siguiente:
- 1.
- llamar a la clase madre construirObjetoDerivado
- 2.
- construir atributos definidos en la clase base
- 3.
- si se devuelve una dirección de objeto nulo, devolver una dirección de objeto nulo
- 4.
- obtener el Identificador del GestorMensajes a partir del fichero de configuración
- 6.
- si hay un error al obtener el Identificador del GestorMensajes, eliminar objeto y volver
- 7.
- almacenar IdentificadorObjeto en el objeto.
FábricaMonitorTrenzado 578 hereda también de
FábricaTrenzado 570 y crea ejemplos de MonitorTrenzado a partir de
un fichero de configuración. FábricaTrenzadoTemporizador 580 hereda
de FábricaTrenzado 570 y crea ejemplos de TrenzadoTemporizador a
partir de un fichero de configuración. Su función asociada
construirObjetoDerivado puede tener el siguiente flujo lógico:
- 1.
- llamar clase madre construirObjetoDerivado
- 2.
- construir atributos definidos en la clase base
- 3.
- si se devuelve dirección de objeto nulo, devolver dirección objeto nulo
- 4.
- obtener el Identificador del Temporizador a partir del fichero de configuración
- 6.
- si hay un error al obtener el Identificador del Temporizador, eliminar objeto y volver
- 7.
- almacenar IdentificadorObjeto en el objeto
- 8.
- obtener intervalo de activación del temporizador a partir del fichero de configuración
- 9.
- si hay un error, eliminar el objeto y volver.
FábricaTrenzadoClienteCola 582 hereda de
FábricaTrenzado 570 y crea ejemplos de TrenzadoClienteCola a partir
de un fichero de configuración. Su función construirObjetoDerivado
utiliza también la función madre asociada construirObjetoDerivado
para crear el objeto, obtiene el Identificador del GestorMensajes a
partir del fichero de configuración y almacena el
IdentificadorObjeto en el objeto. FábricaTrenzadoExpendedor 584
hereda de FábricaTrenzado 570 y crea ejemplos de TrenzadoExpendedor
a partir de un fichero de configuración. Su función
construirObjetoDerivado obtiene el Identificador de cola de
actividad a partir del fichero de configuración y almacena el
IdentificadorObjeto en el objeto.
La Figura 38 es un diagrama de herencia de
objetos de fábrica de CabeceraCola. FábricaCabeceraCola 600 hereda
de FábricaObjetos 490 y crea ejemplos de CabeceraCola a partir de un
fichero de configuración. FábricaColaEnclavada 602 hereda de
FábricaCabeceraCola 600 y crea ejemplos de ColaEnclavada a partir de
un fichero de configuración. FábricaColasEspera 604 hereda de
FábricaColaEnclavada 602 y crea ejemplos de ColaEspera a partir de
un fichero de configuración. FábricaColaSemáforo 606 hereda de
FábricaColasEspera 604 y crea ejemplos de ColaSemáforo a partir de
un fichero de configuración. Todos los objetos de fábrica de
CabeceraCola tienen funciones asociadas construirObjetoDerivado que
llaman a los métodos madre construirObjetoDerivado, construye
atributos definidos en la clase base y devuelve una dirección de
objeto nulo si se devuelve la dirección de un objeto nulo en el paso
de construcción.
La Figura 39 es un diagrama de herencia de clases
de fábrica de FundiciónMensajesSalientes.
FábricaFundiciónMensajesSalientes 610 es una clase base que crea
ejemplos de FundiciónMensajesSalientes a partir de un fichero de
configuración. Su función asociada construirObjetoDerivado puede
tener el siguiente flujo lógico:
- 1.
- llamar clase madre construirObjetoDerivado
- 2.
- construir atributos definidos en la clase base
- 3.
- si se devuelve una dirección de objeto nulo, devolver dirección de objeto nulo
- 4.
- obtener IdentificadorMensaje a partir del fichero de configuración
- 6.
- si hay un error al obtener el IdentificadorMensaje, presentar un mensaje de error, eliminar objeto y volver
- 7.
- almacenar IdentificadorObjeto en el objeto
- 8.
- devolver dirección de objeto como ha sido construida hasta ahora.
FábricaFundiciónMensajesPuerto 612 hereda de
FábricaFundiciónMensajesSalientes 610 y crea ejemplos de
FundiciónMensajesPuerto a partir de un fichero de configuración. Su
función asociada construirObjetoDerivado puede tener el flujo lógico
siguiente:
- 1.
- llamar a la clase madre construirObjetoDerivado
- 2.
- construir atributos definidos en la clase base
- 3.
- si se devuelve la dirección de un objeto nulo, devolver dirección de objeto nulo
- 4.
- obtener el Identificador del directorio de puertos a partir del fichero de configuración
- 6.
- si hay un error al obtener el Identificador del directorio de puertos, eliminar objetos y volver
- 7.
- almacenar IdentificadorObjeto en el objeto
- 8.
- obtener nombre de la cola a partir del fichero de configuración
- 9.
- si hay un error al obtener el nombre de la cola, eliminar objeto y volver
- 10.
- almacenar nombre de la cola en el objeto.
Aunque la presente invención y sus ventajas han
sido descritas en detalle, debe entenderse que pueden hacerse en
ella diversas mutaciones, cambios, sustituciones y alteraciones sin
apartarse del alcance de la invención como se define en las
reivindicaciones anexas.
Claims (28)
1. Un método para construir objetos dinámicos
para un software de aplicación, que comprende los pasos de:
convertir una representación de un diagrama de
estado de la aplicación de software en un fichero principal (53) de
configuración;
leer y analizar dicho fichero de configuración
principal por medio de un objeto maestro (50);
obtener un identificador de objeto para cada
objeto dinámico especificado en el fichero de configuración
principal;
crear, por medio de un objeto (52) de fábrica, un
ejemplo de cada objeto dinámico especificado en el fichero principal
de configuración y obtener una dirección física para cada ejemplo
creado;
almacenar los identificadores de objeto y las
direcciones físicas de los ejemplos creados en un diccionario (56)
de objetos;
llamar a un método de inicialización de cada
objeto almacenado en el diccionario de objetos; y
controlar la inicialización de cada ejemplo
creado.
2. El método, como se ha establecido en la
reivindicación 1, que comprende además los pasos de:
leer y analizar una jerarquía de ficheros de
configuración adicionales especificados en el fichero de
configuración principal;
leer y analizar una jerarquía de objetos
dinámicos adicionales especificados en el fichero de configuración
principal y ficheros de configuración adicionales;
obtener un identificador de objeto para cada
objeto dinámico adicional especificado en los ficheros de
configuración adicionales;
crear, por medio de un objeto de fábrica, un
ejemplo de cada objeto dinámico especificado en los ficheros de
configuración adicionales y obtener una dirección física para cada
ejemplo creado;
almacenar los identificadores de objeto y las
direcciones físicas de los ejemplos creados en el diccionario de
objetos;
llamar al método de inicialización de cada objeto
almacenado en el diccionario de objetos; y
inicializar cada ejemplo creado.
3. El método, como se establece en la
reivindicación 1, en el que el paso de creación del objeto dinámico
comprende además los pasos de:
acceder al fichero de configuración
principal;
obtener una clase (170) para cada objeto
dinámico; y
localizar un objeto particular de la fábrica en
un diccionario de fábrica responsable de crear un ejemplo de la
clase de objetos.
4. El método, como se establece en la
reivindicación 2, en el que el paso de creación de objetos dinámicos
comprende además los pasos de:
acceder a uno de los ficheros adicionales de
configuración;
obtener una clase (170) de cada objeto dinámico;
y
localizar un objeto particular de la fábrica en
un diccionario de fábrica responsable de crear un ejemplo de la
clase de objetos.
5. El método, como se establece en la
reivindicación 3, que comprende además los pasos de:
crear el objeto particular de la fábrica
responsable de la creación del ejemplo de la clase de objetos; y
añadir el objeto de la fábrica al diccionario de
fábrica.
6. El método según la reivindicación 2, en el que
el paso de creación del ejemplo de objeto dinámico incluye:
crear un ejemplo vacío de cada objeto dinámico;
y
configurar los atributos del ejemplo vacío creado
como se especifica en el fichero principal o ficheros adicionales de
configuración.
7. El método, como se establece en la
reivindicación 6, en el que el paso de creación de ejemplos de
objeto dinámico incluye:
acceder a uno de los ficheros adicionales de
configuración;
obtener una clase de cada objeto dinámico;
localizar un objeto particular (172) de la
fábrica en un diccionario de fábrica responsable de crear un ejemplo
de la clase de objetos;
crear un objeto (80) de estado.
8. El método, como se establece en la
reivindicación 7, en el que el paso de localizar el objeto de la
fábrica incluye la localización de un objeto de fábrica de
estados.
9. El método, como se establece en la
reivindicación 6, en el que el paso de creación de ejemplos de
objetos dinámicos incluye:
acceder a uno de los ficheros adicionales de
configuración;
obtener una clase de cada objeto dinámico;
localizar un objeto particular (176) de la
fábrica en un diccionario de fábrica responsable de crear un ejemplo
de la clase de objetos;
crear un objeto (130) de evento.
10. El método como se establece en la
reivindicación 9, en el que el paso de localización de objetos de
fábrica incluye la localización de un objeto de la fábrica de
eventos.
11. El método, como se establece en la
reivindicación 6; en el que el paso de creación de ejemplos de
objeto dinámico incluye:
acceder a uno de los ficheros adicionales de
configuración;
obtener una clase de cada objeto dinámico;
localizar un objeto particular (174) de la
fábrica en un diccionario de fábrica responsable de crear un ejemplo
de la clase de objetos;
crear un objeto de entidad.
12. El método, como se establece en la
reivindicación 11, en el que el paso de localización de objetos de
fábrica incluye la localización de un objeto de la fábrica de
entidades.
13. El método, como se establece en la
reivindicación 6, en el que el paso de creación de ejemplo de objeto
dinámico incluye:
acceder a uno de los ficheros adicionales de
configuración;
obtener una clase de cada objeto dinámico;
localizar un objeto particular (178) de la
fábrica en un diccionario de fábrica responsable de crear un ejemplo
de la clase de objetos;
crear un objeto (82) de mensajes.
14. El método, como se establece en la
reivindicación 13, en el que el paso de localización de objetos de
fábrica incluye la localización de un objeto de la fábrica de
mensajes.
\newpage
15. El método, como se establece en la
reivindicación 6; en el que el paso de creación de ejemplos de
objeto dinámico incluye:
acceder a uno de los ficheros adicionales de
configuración;
obtener una clase de cada objeto dinámico;
localizar un objeto particular de la fábrica en
un diccionario de fábrica responsable de crear un ejemplo de la
clase de objetos;
crear un objeto (76) de colas.
16. El método, como se establece en la
reivindicación 15, en el que el paso de localización de objetos de
fábrica incluye la localización de un objeto de la fábrica de
colas.
17. El método, como se establece en la
reivindicación 6; en el que el paso de creación de ejemplos de
objeto dinámico incluye:
acceder a uno de los ficheros adicionales de
configuración;
obtener una clase de cada objeto dinámico;
localizar un objeto particular de la fábrica en
un diccionario de fábrica responsable de crear un ejemplo de la
clase de objetos;
crear un objeto (78) de temporizador.
18. El método, como se establece en la
reivindicación 17, en el que el paso de localización de objetos de
fábrica incluye la localización de un objeto de la fábrica de
temporizadores.
19. El método, como se establece en la
reivindicación 5, en el que el paso de creación de objetos de
fábrica comprende los pasos de:
crear una jerarquía de objetos de fábrica
responsable de crear una jerarquía de objetos de clases; y
añadir la jerarquía de objetos de fábrica al
diccionario de fábrica.
20. El método, como se establece en la
reivindicación 1, en el que el paso de creación de ejemplos de
objetos dinámicos comprende el paso de crear ejemplos de objetos
dinámicos a partir de clases de objetos especificados en un lenguaje
compilado de alto nivel.
21. Un sistema para implantar dinámicamente una
aplicación de software, que comprende:
una base de datos que incluye una representación
de un diagrama de estados de la aplicación de software, estando
adaptada la base de datos para convertir la representación del
diagrama de estado en un conjunto de ficheros (53) de configuración
organizados jerárquicamente, donde los ficheros de configuración de
nivel más alto hacen referencia a ficheros de configuración de nivel
más bajo, conteniendo los ficheros de configuración una
especificación de un conjunto de objetos y atributos dinámicos de
los mismos organizados jerárquicamente para implantar la aplicación
de software;
un objeto maestro (50) adaptado para leer y
analizar el conjunto de ficheros de configuración, estando adaptado
el objeto maestro para obtener un identificador de un objeto para
cada objeto dinámico;
un objeto (52) de fábrica adaptado para crear un
ejemplo de una clase particular de objetos dinámicos especificados
en los ficheros de configuración y obtener una dirección física para
cada ejemplo creado; y
un diccionario (56) de objetos adaptado para
almacenar los identificadores de los objetos y las direcciones
físicas de los ejemplos creados, estando adaptado el diccionario de
objetos para inicializar cada ejemplo creado.
22. El sistema, como se establece en la
reivindicación 21, que comprende además un diccionario de fábrica
adaptado para almacenar referencias a objetos (170) de fábrica
adaptados para crear ejemplos de diferentes clases de objetos
dinámicos.
23. El sistema según la reivindicación 22, que
comprende además:
un objeto (172) de fábrica de estados adaptada
para crear ejemplos de objetos (80) de estados.
\newpage
24. El sistema, como se establece en la
reivindicación 23, que comprende además un objeto (176) de fábrica
de eventos adaptado para crear ejemplos de objetos de eventos.
25. El sistema, como se establece en la
reivindicación 23, que comprende además un objeto (174) de fábrica
de entidades adaptado para crear ejemplos de objetos de
entidades.
26. El sistema, como se establece en la
reivindicación 23, que comprende además un objeto (178) de fábrica
de mensajes adaptado para crear ejemplos de objetos (82) de
mensajes.
27. El sistema, como se establece en la
reivindicación 23, que comprende además un objeto de fábrica de
colas adaptado para crear ejemplos de objetos (76) de colas.
28. El sistema, como se establece en la
reivindicación 23, que comprende además un objeto de fábrica de
temporizadores adaptado para crear ejemplos de objetos (78) de
temporizadores.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US3082496P | 1996-11-14 | 1996-11-14 | |
| US30824P | 1996-11-14 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2207756T3 true ES2207756T3 (es) | 2004-06-01 |
Family
ID=21856231
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES97950587T Expired - Lifetime ES2207756T3 (es) | 1996-11-14 | 1997-11-12 | Maquina generica de estado de software y metodo de construir objetos dinamicos para un programa de aplicacion. |
Country Status (9)
| Country | Link |
|---|---|
| US (2) | US6138171A (es) |
| EP (1) | EP0938701B1 (es) |
| KR (1) | KR20000068979A (es) |
| AU (1) | AU5355098A (es) |
| DE (1) | DE69726004T2 (es) |
| ES (1) | ES2207756T3 (es) |
| TW (1) | TW401558B (es) |
| WO (1) | WO1998021651A1 (es) |
| ZA (1) | ZA9710268B (es) |
Families Citing this family (142)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| SE506535C2 (sv) * | 1995-06-16 | 1998-01-12 | Ericsson Telefon Ab L M | Metod och anordning för att härleda instansinformation i ett informationshanterande system |
| US6230159B1 (en) * | 1997-04-30 | 2001-05-08 | Microsoft Corporation | Method for creating object inheritance |
| CA2210755C (en) * | 1997-07-17 | 2003-12-23 | Ibm Canada Limited - Ibm Canada Limitee | Creating proxies for distribution of beans and event objects |
| US6148302A (en) * | 1998-02-26 | 2000-11-14 | Sun Microsystems, Inc. | Method, apparatus, system and computer program product for initializing a data structure at its first active use |
| FR2775804B1 (fr) * | 1998-03-05 | 2000-04-14 | Alsthom Cge Alcatel | Procedes de stockage et de depaquetage des attributs d'un objet |
| GB2335518A (en) * | 1998-03-18 | 1999-09-22 | Ibm | Triggering event causes creation of Coordinator transaction state object |
| US6493599B2 (en) * | 1998-03-19 | 2002-12-10 | Dell Usa, L.P. | Automated system and method for generating data to drive a manufacturing process |
| US6678713B1 (en) * | 1998-04-29 | 2004-01-13 | Xerox Corporation | Machine control using a schedulerlock construct |
| US6308197B1 (en) * | 1998-04-29 | 2001-10-23 | Xerox Corporation | Machine control using register construct |
| US6345387B1 (en) * | 1998-04-30 | 2002-02-05 | Cosa Technologies, Inc. | Coherent object system architecture |
| US6708181B1 (en) * | 1998-09-01 | 2004-03-16 | International Business Machines Corporation | System and method for initializing variables in an object-oriented program |
| US7015964B1 (en) * | 1998-11-02 | 2006-03-21 | Canon Kabushiki Kaisha | Solid-state image pickup device and method of resetting the same |
| FR2786008B1 (fr) * | 1998-11-13 | 2001-04-27 | Gemplus Card Int | Procede et dispositif de controle du cycle de vie d'un objet portatif, notamment d'une carte a puce |
| WO2000031629A1 (en) * | 1998-11-25 | 2000-06-02 | Microsoft Corporation | Object model for object-oriented computing environments |
| US6304879B1 (en) | 1998-11-25 | 2001-10-16 | Microsoft Corporation | Dynamic data cache for object-oriented computing environments |
| US6795968B1 (en) | 1998-11-25 | 2004-09-21 | Microsoft Corporation | Dynamic object behavior for object-oriented-computing environments |
| US6738778B1 (en) * | 1998-12-11 | 2004-05-18 | International Business Machines Corporation | Method and apparatus for monitoring the execution of a program |
| US6473769B1 (en) | 1999-03-31 | 2002-10-29 | Microsoft Corporation | Property linking in object-oriented computing environments |
| US7213061B1 (en) | 1999-04-29 | 2007-05-01 | Amx Llc | Internet control system and method |
| US7210117B2 (en) * | 1999-08-19 | 2007-04-24 | National Instruments Corporation | System and method for programmatically generating a graphical program in response to program information |
| US6578068B1 (en) | 1999-08-31 | 2003-06-10 | Accenture Llp | Load balancer in environment services patterns |
| US6640244B1 (en) | 1999-08-31 | 2003-10-28 | Accenture Llp | Request batcher in a transaction services patterns environment |
| US6715145B1 (en) | 1999-08-31 | 2004-03-30 | Accenture Llp | Processing pipeline in a base services pattern environment |
| US6842906B1 (en) | 1999-08-31 | 2005-01-11 | Accenture Llp | System and method for a refreshable proxy pool in a communication services patterns environment |
| US6615253B1 (en) | 1999-08-31 | 2003-09-02 | Accenture Llp | Efficient server side data retrieval for execution of client side applications |
| US6601234B1 (en) | 1999-08-31 | 2003-07-29 | Accenture Llp | Attribute dictionary in a business logic services environment |
| US6636242B2 (en) | 1999-08-31 | 2003-10-21 | Accenture Llp | View configurer in a presentation services patterns environment |
| US6954220B1 (en) | 1999-08-31 | 2005-10-11 | Accenture Llp | User context component in environment services patterns |
| US6742015B1 (en) | 1999-08-31 | 2004-05-25 | Accenture Llp | Base services patterns in a netcentric environment |
| US6640249B1 (en) | 1999-08-31 | 2003-10-28 | Accenture Llp | Presentation services patterns in a netcentric environment |
| US6640238B1 (en) | 1999-08-31 | 2003-10-28 | Accenture Llp | Activity component in a presentation services patterns environment |
| US6571282B1 (en) | 1999-08-31 | 2003-05-27 | Accenture Llp | Block-based communication in a communication services patterns environment |
| US6549949B1 (en) | 1999-08-31 | 2003-04-15 | Accenture Llp | Fixed format stream in a communication services patterns environment |
| US7289964B1 (en) | 1999-08-31 | 2007-10-30 | Accenture Llp | System and method for transaction services patterns in a netcentric environment |
| US6601192B1 (en) | 1999-08-31 | 2003-07-29 | Accenture Llp | Assertion component in environment services patterns |
| US6499136B1 (en) * | 1999-11-10 | 2002-12-24 | Lucent Technologies Inc. | Single-shot entry code for software state transition |
| US7082609B2 (en) * | 2000-03-31 | 2006-07-25 | Schlumbergersema Telekom Gmbh & Co. Kg | Meta application system and method |
| US6985946B1 (en) | 2000-05-12 | 2006-01-10 | Microsoft Corporation | Authentication and authorization pipeline architecture for use in a web server |
| US7013340B1 (en) | 2000-05-18 | 2006-03-14 | Microsoft Corporation | Postback input handling by server-side control objects |
| US6961750B1 (en) | 2000-05-18 | 2005-11-01 | Microsoft Corp. | Server-side control objects for processing client-side user interface elements |
| US6792607B1 (en) | 2000-05-18 | 2004-09-14 | Microsoft Corporation | Databinding using server-side control objects |
| US6990653B1 (en) * | 2000-05-18 | 2006-01-24 | Microsoft Corporation | Server-side code generation from a dynamic web page content file |
| US6799319B2 (en) * | 2000-07-17 | 2004-09-28 | Sun Microsystems, Inc. | Method and apparatus for application packages and delegate packages to adopt and export standard execution state machine interfaces |
| US6880147B1 (en) * | 2000-09-07 | 2005-04-12 | Rockwell Collins | System and method for developing software utilizing determinative representations |
| US20100223295A1 (en) * | 2000-12-06 | 2010-09-02 | Io Informatics, Inc. | Applied Semantic Knowledgebases and Applications Thereof |
| US20020156756A1 (en) * | 2000-12-06 | 2002-10-24 | Biosentients, Inc. | Intelligent molecular object data structure and method for application in heterogeneous data environments with high data density and dynamic application needs |
| US7200838B2 (en) * | 2000-12-20 | 2007-04-03 | National Instruments Corporation | System and method for automatically generating a graphical program in response to a state diagram |
| US6925632B2 (en) * | 2001-03-08 | 2005-08-02 | Martin Shiu | System for configuration programming |
| US6951022B1 (en) * | 2001-03-14 | 2005-09-27 | Microsoft Corporation | Delegate-based event handling |
| US7100148B2 (en) * | 2001-03-16 | 2006-08-29 | Sap Ag | Development computer, development program for combining components to applications, using component descriptors related to the components, method, and computer program |
| US7380250B2 (en) | 2001-03-16 | 2008-05-27 | Microsoft Corporation | Method and system for interacting with devices having different capabilities |
| US7296194B1 (en) * | 2002-03-28 | 2007-11-13 | Shoregroup Inc. | Method and apparatus for maintaining the status of objects in computer networks using virtual state machines |
| US7197561B1 (en) * | 2001-03-28 | 2007-03-27 | Shoregroup, Inc. | Method and apparatus for maintaining the status of objects in computer networks using virtual state machines |
| US7028228B1 (en) | 2001-03-28 | 2006-04-11 | The Shoregroup, Inc. | Method and apparatus for identifying problems in computer networks |
| US20020144015A1 (en) * | 2001-03-30 | 2002-10-03 | Lortz Victor B. | Method and apparatus to implement a state machine |
| US7100167B2 (en) | 2001-05-01 | 2006-08-29 | Microsoft Corporation | Method and apparatus for creating templates |
| US7275250B1 (en) * | 2001-05-01 | 2007-09-25 | Microsoft Corporation | Method and apparatus for correlating events |
| US7024285B2 (en) * | 2001-05-09 | 2006-04-04 | Spraying Systems Co. | Object-oriented operating system for a spray controller |
| US6986146B2 (en) * | 2001-05-30 | 2006-01-10 | Siemens Communications, Inc. | Method and apparatus for providing a state machine operating on a real-time operating system |
| US7493397B1 (en) | 2001-06-06 | 2009-02-17 | Microsoft Corporation | Providing remote processing services over a distributed communications network |
| US6915454B1 (en) | 2001-06-12 | 2005-07-05 | Microsoft Corporation | Web controls validation |
| US6898604B1 (en) | 2001-06-29 | 2005-05-24 | Microsoft Corporation | XML serialization and deserialization |
| US7120897B2 (en) | 2001-07-10 | 2006-10-10 | Microsoft Corporation | User control objects for providing server-side code generation from a user-defined dynamic web page content file |
| US20030037023A1 (en) * | 2001-08-07 | 2003-02-20 | Intelliclaim | Emulation process for making changes and revisions to computer data files |
| US7216294B2 (en) * | 2001-09-04 | 2007-05-08 | Microsoft Corporation | Method and system for predicting optimal HTML structure without look-ahead |
| US20040189713A1 (en) * | 2001-10-31 | 2004-09-30 | Metacyber.Net | Computer-based user interface for a memory-resident rapid comprehension document for original source information |
| US7428725B2 (en) * | 2001-11-20 | 2008-09-23 | Microsoft Corporation | Inserting devices specific content |
| AU2002366158A1 (en) * | 2001-11-21 | 2003-06-10 | Enterasys Networks, Inc. | Translating configuration files among network devices |
| US7308676B2 (en) * | 2001-12-28 | 2007-12-11 | Sap Ag | Generic layer for virtual object resolution |
| US6993706B2 (en) * | 2002-01-15 | 2006-01-31 | International Business Machines Corporation | Method, apparatus, and program for a state machine framework |
| US7644392B2 (en) * | 2002-04-12 | 2010-01-05 | Telelogic Technologies North America, Inc. | System and method for active configuration management |
| US7039893B2 (en) * | 2002-06-11 | 2006-05-02 | Carrier Corporation | System and method for implementing configurable finite state machine |
| US7010778B2 (en) * | 2002-06-24 | 2006-03-07 | International Business Machines Corporation | Method, apparatus, and program for a state machine framework |
| US7234132B2 (en) * | 2002-08-29 | 2007-06-19 | International Business Machines Corporation | Application integration model for dynamic software component assembly within an application at runtime |
| US7574653B2 (en) | 2002-10-11 | 2009-08-11 | Microsoft Corporation | Adaptive image formatting control |
| US7146231B2 (en) * | 2002-10-22 | 2006-12-05 | Fisher-Rosemount Systems, Inc.. | Smart process modules and objects in process plants |
| US9983559B2 (en) | 2002-10-22 | 2018-05-29 | Fisher-Rosemount Systems, Inc. | Updating and utilizing dynamic process simulation in an operating process environment |
| GB2417574A (en) * | 2002-10-22 | 2006-03-01 | Fisher-Rosemount Systems Inc | Smart process modules and objects in a process plant |
| DE10348563B4 (de) * | 2002-10-22 | 2014-01-09 | Fisher-Rosemount Systems, Inc. | Integration von Grafikdisplayelementen, Prozeßmodulen und Steuermodulen in Prozeßanlagen |
| US7007004B2 (en) * | 2002-11-20 | 2006-02-28 | Nokia Corporation | Concurrent operation of a state machine family |
| US20040254884A1 (en) * | 2002-12-20 | 2004-12-16 | Sap Aktiengesellschaft | Content catalog and application designer framework |
| US6957415B1 (en) | 2003-06-04 | 2005-10-18 | Sandia Corporation | Method for self-organizing software |
| US20040267771A1 (en) * | 2003-06-30 | 2004-12-30 | International Business Machines Corporation | Method, system and computer program product for providing business logic transaction processing |
| US7610587B2 (en) * | 2003-11-05 | 2009-10-27 | Hewlett-Packard Development Company, L.P. | System and method for creating a best-match object at run time |
| US7047343B2 (en) * | 2003-11-26 | 2006-05-16 | Dell Products L.P. | System and method for communication of keyboard and touchpad inputs as HID packets embedded on a SMBus |
| US7421546B2 (en) * | 2004-02-12 | 2008-09-02 | Relaystar Sa/Nv | Intelligent state engine system |
| US7729789B2 (en) | 2004-05-04 | 2010-06-01 | Fisher-Rosemount Systems, Inc. | Process plant monitoring based on multivariate statistical analysis and on-line process simulation |
| JP2007536634A (ja) | 2004-05-04 | 2007-12-13 | フィッシャー−ローズマウント・システムズ・インコーポレーテッド | プロセス制御システムのためのサービス指向型アーキテクチャ |
| US7890604B2 (en) | 2004-05-07 | 2011-02-15 | Microsoft Corproation | Client-side callbacks to server events |
| US9026578B2 (en) | 2004-05-14 | 2015-05-05 | Microsoft Corporation | Systems and methods for persisting data between web pages |
| US7464386B2 (en) | 2004-05-17 | 2008-12-09 | Microsoft Corporation | Data controls architecture |
| US7676791B2 (en) * | 2004-07-09 | 2010-03-09 | Microsoft Corporation | Implementation of concurrent programs in object-oriented languages |
| GB0422294D0 (en) * | 2004-10-07 | 2004-11-10 | Ibm | Accessing a data structure |
| US8892582B2 (en) * | 2005-03-03 | 2014-11-18 | Hewlett-Packard Development Company, L.P. | Method and system for identifying objects of service |
| US7979468B2 (en) * | 2005-06-14 | 2011-07-12 | Enterprise Elements, Inc. | Database data dictionary |
| US7743066B2 (en) | 2005-07-29 | 2010-06-22 | Microsoft Corporation | Anonymous types for statically typed queries |
| US7818719B2 (en) * | 2005-07-29 | 2010-10-19 | Microsoft Corporation | Extending expression-based syntax for creating object instances |
| US9063739B2 (en) | 2005-09-07 | 2015-06-23 | Open Invention Network, Llc | Method and computer program for device configuration |
| US20070101316A1 (en) * | 2005-09-12 | 2007-05-03 | Don Berndt | Software Architecture and Program for the Concurrent Execution of Finite State Machine-Encoded Processes, on Single or Multiple-Processor-Based Embedded Systems |
| US7444191B2 (en) | 2005-10-04 | 2008-10-28 | Fisher-Rosemount Systems, Inc. | Process model identification in a process control system |
| US7738975B2 (en) | 2005-10-04 | 2010-06-15 | Fisher-Rosemount Systems, Inc. | Analytical server integrated in a process control network |
| US8036760B2 (en) | 2005-10-04 | 2011-10-11 | Fisher-Rosemount Systems, Inc. | Method and apparatus for intelligent control and monitoring in a process control system |
| CN101322083A (zh) | 2005-12-05 | 2008-12-10 | 费舍-柔斯芒特系统股份有限公司 | 利用并行过程仿真的多目标预测过程优化 |
| US20070204277A1 (en) * | 2006-02-27 | 2007-08-30 | Burgess Andrew L Jr | Computer program and method for managing implementation of a process |
| US20070204169A1 (en) * | 2006-02-28 | 2007-08-30 | International Business Machines Corporation | Enabling automatic business processes using state transfer diagram and abstraction |
| US20070250295A1 (en) * | 2006-03-30 | 2007-10-25 | Subx, Inc. | Multidimensional modeling system and related method |
| US7890929B1 (en) * | 2006-07-25 | 2011-02-15 | Kenneth Raymond Johanson | Methods and system for a tool and instrument oriented software design |
| US7877727B2 (en) * | 2006-08-18 | 2011-01-25 | Bitrouter | Hierarchical state programming with a markup language |
| US8387002B2 (en) * | 2007-04-20 | 2013-02-26 | National Instruments Corporation | Statechart development environment with embedded graphical data flow code editor |
| US8640100B2 (en) * | 2007-04-20 | 2014-01-28 | National Instruments Corporation | Debugging a statechart using a graphical program |
| US7992130B2 (en) * | 2007-05-07 | 2011-08-02 | Microsoft Corporation | Class-based object-oriented features in class-less script language |
| DE602007010259D1 (de) * | 2007-06-06 | 2010-12-16 | Siemens Ag | Verfahren zur Bereitstellung von Referenzdaten für eine Diagnose eines von einer Ereignisspur abhängigen Systems |
| US20090100406A1 (en) * | 2007-10-16 | 2009-04-16 | Microsoft Corporation | Software factory specification and execution model |
| US20090157817A1 (en) * | 2007-12-12 | 2009-06-18 | International Business Machines Corporation | Using an unsynchronized event pool to improve performance of an event driven im gateway |
| US8140978B2 (en) * | 2008-01-16 | 2012-03-20 | International Business Machines Corporation | System and method for providing information in a virtual world |
| US8458667B2 (en) * | 2008-01-30 | 2013-06-04 | National Instruments Corporation | Debugging a statechart for a real time target |
| US9449298B2 (en) * | 2008-05-13 | 2016-09-20 | Emc Corporation | Managing complex dependencies in a file-based team environment |
| US8689195B2 (en) * | 2008-06-03 | 2014-04-01 | International Business Machines Corporation | Identifying structured data types as requiring designated initializers |
| US8245144B2 (en) * | 2008-06-27 | 2012-08-14 | Microsoft Corporation | Object model for a user interface |
| US20100083219A1 (en) * | 2008-10-01 | 2010-04-01 | Microsoft Corporation | Runtime Object Composition |
| US8631208B2 (en) * | 2009-01-27 | 2014-01-14 | Intel Corporation | Providing address range coherency capability to a device |
| US8881039B2 (en) | 2009-03-13 | 2014-11-04 | Fisher-Rosemount Systems, Inc. | Scaling composite shapes for a graphical human-machine interface |
| US8364862B2 (en) * | 2009-06-11 | 2013-01-29 | Intel Corporation | Delegating a poll operation to another device |
| US8429605B2 (en) * | 2009-12-30 | 2013-04-23 | The United States Of America As Represented By The Secretary Of The Navy | Finite state machine architecture for software development |
| US8825183B2 (en) | 2010-03-22 | 2014-09-02 | Fisher-Rosemount Systems, Inc. | Methods for a data driven interface based on relationships between process control tags |
| US8601013B2 (en) | 2010-06-10 | 2013-12-03 | Micron Technology, Inc. | Analyzing data using a hierarchical structure |
| KR101551045B1 (ko) * | 2011-01-25 | 2015-09-07 | 마이크론 테크놀로지, 인크. | 요소 이용을 위한 상태 그룹화 |
| JP5848778B2 (ja) | 2011-01-25 | 2016-01-27 | マイクロン テクノロジー， インク． | Ｆｓｍを実装するための専用要素の利用 |
| US8726256B2 (en) | 2011-01-25 | 2014-05-13 | Micron Technology, Inc. | Unrolling quantifications to control in-degree and/or out-degree of automaton |
| KR101640295B1 (ko) | 2011-01-25 | 2016-07-15 | 마이크론 테크놀로지, 인크. | 정규 표현을 컴파일하기 위한 방법 및 장치 |
| US8417689B1 (en) * | 2011-11-21 | 2013-04-09 | Emc Corporation | Programming model for transparent parallelization of combinatorial optimization |
| US8959494B2 (en) * | 2012-03-20 | 2015-02-17 | Massively Parallel Technologies Inc. | Parallelism from functional decomposition |
| US8996920B2 (en) * | 2012-10-19 | 2015-03-31 | Spirent Communications, Inc. | Finite state machine method for test case generation and execution of communication protocols |
| WO2014152800A1 (en) | 2013-03-14 | 2014-09-25 | Massively Parallel Technologies, Inc. | Project planning and debugging from functional decomposition |
| CN104714794A (zh) * | 2013-12-12 | 2015-06-17 | 南宁市磁汇科技有限公司 | Web页面对象动态组合的方法和装置 |
| US10365901B2 (en) * | 2015-08-14 | 2019-07-30 | Entit Software Llc | Dynamic lexer object construction |
| US11087358B2 (en) | 2016-06-24 | 2021-08-10 | The Nielsen Company (Us), Llc | Methods and apparatus for wireless communication with an audience measurement device |
| US10878140B2 (en) | 2016-07-27 | 2020-12-29 | Emerson Process Management Power & Water Solutions, Inc. | Plant builder system with integrated simulation and control system configuration |
| US11070451B2 (en) | 2017-12-11 | 2021-07-20 | Spirent Communications, Inc. | Method and system for inducing pseudo HTTPS communications between one or more emulated servers and emulated clients to test a device therebetween |
| US11374973B2 (en) | 2018-12-20 | 2022-06-28 | Spirent Communications, Inc. | Streamlining cryptographic processes in a test environment |
| US10430179B1 (en) * | 2019-03-07 | 2019-10-01 | Capital One Services, Llc | Methods and systems for managing application configurations |
| US11418969B2 (en) | 2021-01-15 | 2022-08-16 | Fisher-Rosemount Systems, Inc. | Suggestive device connectivity planning |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5065393A (en) * | 1990-04-10 | 1991-11-12 | Dsc Communications Corporation | Network controller billing system and method of operation |
| US5065392A (en) * | 1990-04-10 | 1991-11-12 | Dsc Communications Corporation | Network controller scheduling system and method of operation |
| US5138614A (en) * | 1990-04-12 | 1992-08-11 | At&T Bell Laboratories | Transformation method for network conference connections |
| US5265206A (en) * | 1990-10-23 | 1993-11-23 | International Business Machines Corporation | System and method for implementing a messenger and object manager in an object oriented programming environment |
| EP0495279B1 (en) * | 1991-01-18 | 1997-07-16 | International Business Machines Corporation | Object oriented programming platform |
| ATE143549T1 (de) * | 1991-05-08 | 1996-10-15 | Siemens Ag | Steuerungsanordnung für ein breitbandvermittlungssystem |
| US5295139A (en) * | 1991-11-15 | 1994-03-15 | Dsc Communications Corporation | Management system for partitioned multi-bandwidth communications network |
| US5426634A (en) * | 1992-01-31 | 1995-06-20 | Summa Four, Inc. | Flexible call-processing apparatus for ISDN telephone channels |
| JPH06149554A (ja) * | 1992-11-09 | 1994-05-27 | Matsushita Electric Ind Co Ltd | プログラム動作仕様自動合成装置及びその方法 |
| JPH0828913B2 (ja) * | 1993-01-13 | 1996-03-21 | 日本電気株式会社 | 時間多重スイッチ |
| US5437025A (en) * | 1993-01-26 | 1995-07-25 | International Business Machines Corporation | System and method for run time configuration of objects in an object oriented computing environment |
| JP2500743B2 (ja) * | 1993-04-23 | 1996-05-29 | 日本電気株式会社 | ディジタルクロスコネクト装置 |
| US5384771A (en) * | 1993-08-27 | 1995-01-24 | At&T Corp. | Multimedia call configuration system |
| US5555415A (en) * | 1994-01-10 | 1996-09-10 | Metasphere, Inc. | Object oriented event message dispatching subsystem and method utilizing a disposition matrix |
| US5692195A (en) * | 1994-08-31 | 1997-11-25 | International Business Machines Corporation | Parent class shadowing |
| US5732263A (en) * | 1995-10-03 | 1998-03-24 | International Business Machines Corporation | Systems, methods and computer program products for generating and validating user defined object classes in an object oriented programming environment after build time |
| US5764958A (en) * | 1995-11-30 | 1998-06-09 | International Business Machines Corporation | Method and apparatus for creating dynamic roles with a system object model |
-
1997
- 1997-11-12 ES ES97950587T patent/ES2207756T3/es not_active Expired - Lifetime
- 1997-11-12 US US08/968,997 patent/US6138171A/en not_active Expired - Fee Related
- 1997-11-12 US US08/969,187 patent/US5995753A/en not_active Expired - Lifetime
- 1997-11-12 AU AU53550/98A patent/AU5355098A/en not_active Abandoned
- 1997-11-12 KR KR1019997004286A patent/KR20000068979A/ko not_active Application Discontinuation
- 1997-11-12 EP EP97950587A patent/EP0938701B1/en not_active Expired - Lifetime
- 1997-11-12 DE DE69726004T patent/DE69726004T2/de not_active Expired - Fee Related
- 1997-11-12 WO PCT/US1997/020377 patent/WO1998021651A1/en active IP Right Grant
- 1997-11-13 TW TW086116934A patent/TW401558B/zh not_active IP Right Cessation
- 1997-11-13 ZA ZA9710268A patent/ZA9710268B/xx unknown
Also Published As
| Publication number | Publication date |
|---|---|
| EP0938701A1 (en) | 1999-09-01 |
| EP0938701B1 (en) | 2003-11-05 |
| DE69726004T2 (de) | 2004-08-12 |
| ZA9710268B (en) | 1998-06-10 |
| KR20000068979A (ko) | 2000-11-25 |
| WO1998021651A1 (en) | 1998-05-22 |
| TW401558B (en) | 2000-08-11 |
| US6138171A (en) | 2000-10-24 |
| US5995753A (en) | 1999-11-30 |
| AU5355098A (en) | 1998-06-03 |
| DE69726004D1 (de) | 2003-12-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2207756T3 (es) | Maquina generica de estado de software y metodo de construir objetos dinamicos para un programa de aplicacion. | |
| US6028998A (en) | Application framework for constructing building automation systems | |
| Burrafato et al. | Designing a multi-agent solution for a bookstore with the PASSI methodology. | |
| JP2986051B2 (ja) | オブジェクト指向コンピュータ・システム及びオブジェクト実行方法 | |
| EP1474753B1 (en) | Component model for real time system control | |
| US5553282A (en) | Software project history database and method of operation | |
| EP0755006A2 (en) | Object-oriented communication system with support for multiple remote machine types | |
| KR20020091071A (ko) | 소프트웨어 컴포넌트를 생성하기 위한 ｎ-계층 소프트웨어아키텍처 디자인 방법 및 시스템 | |
| US6405363B1 (en) | Class casting support for run-time extensible items in an object oriented framework | |
| Schleicher et al. | Beyond stereotyping: Metamodeling approaches for the UML | |
| Cardozo et al. | Using the active object model to implement multi-agent systems | |
| EP1426857A1 (en) | Component-based development of software | |
| JP3672334B2 (ja) | オブジェクト集合方法およびシステム | |
| Hailpern et al. | A model for object-based inheritance | |
| Latif et al. | Feature-based design and the object-oriented approach | |
| Philippi | System modelling using object-oriented Pr/T-nets | |
| WO1999027447A1 (en) | Knowledge module | |
| US6377954B1 (en) | Object-oriented processing system and object-oriented case apparatus | |
| Ling et al. | Using two object‐oriented modelling techniques: specifying thejust‐in‐time kanban system | |
| Klimathianakis et al. | DELOS-A repository based environment for developing network centric applications | |
| Yau et al. | A structured bipartite inheritance network representation for object-oriented software design | |
| Thomas | Support system for OCCAM objects on transputers | |
| Ziegler et al. | BRFplus: Business Rule Management for ABAP Applications | |
| Theologitis | Private and shared data in object-oriented programming | |
| da Silva | Acting on Inheritance Hierarchies |