Lenguaje de Sistemas Universal

Universal Systems Language ( USL ) es un lenguaje de modelado y método formal para la especificación y diseño de software y otros sistemas complejos. Fue diseñado por Margaret Hamilton basado en sus experiencias escribiendo software de vuelo para el programa Apolo.^[1]​ El lenguaje es implementado a través del software 001 Tool Suite por Hamilton Technologies, Inc.^[2]​ USL evolucionó de 001AXES, que a su vez evolucionó de AXES, todos los cuales se basan en los axiomas de control de Hamilton. El software 001 Tool Suite utiliza el concepto preventivo de "Development Before The Fact" (DBTF Desarrollo antes del hecho) para su proceso de desarrollo del ciclo de vida. DBTF elimina los errores lo antes posible durante el proceso de desarrollo, eliminando la necesidad de buscar errores después del hecho.

Filosofía

USL fue inspirado por en el reconocimiento de patrones o categorías de errores de Hamilton, durante desarrollo de software del Apolo. Errores en las interfaces y límites de subsistemas que fueron contados entre la mayoría de errores y era a menudo el más sutil y más difícil de encontrar. Cada error de interfaz se colocó a una categoría identificando su significado para ser prevenido a manera de definición de sistema. Este proceso dirigió a un conjunto de seis axiomas, formando la base para una teoría lógica constructiva matemática de control para diseñar sistemas que eliminaría clases enteras de errores justo de la manera que un sistema es definido.^[3]​

Ciertas garantías de exactitud están introducidas en la gramática de USL. En contraste a aproximaciones reactivas para programar verificación, probando para errores tarde al ciclo de vida, el desarrollo de la filosofía de USL desarrollo-antes del-hecho es preventiva, no dejando errores al principio. Una definición USL modela tanto su aplicación (por ejemplo, aviónica o sistema bancario) y propiedades de control a su ciclo de vida propio.^[4]​ Proporcionando un marco matemático dentro de tales objetos, sus interacciones, y sus relaciones pueden ser capturadas, USL – un metalenguaje – tiene "metamecanismos" para definir sistemas. La filosofía de USL es que todos los objetos son recursivamente reutilizables y fiables; los sistemas fiables están definidos en términos de sistemas fiables; solo los sistemas fiables son utilizados como bloques de construcción; y solo los sistemas fiables son utilizados como mecanismos para integrar estos bloques de construcción para formar un sistema nuevo. Los diseñadores entonces pueden utilizar el sistema nuevo, junto con los primeros, para definir (y construir) sistemas más comprensibles y fiables. Si un sistema es fiable, todos los objetos en todos sus niveles y las capas son fiables.

USL Está considerado por algunos usuarios cuando más amigable al usuario que otros sistemas formales.^[5]​ No es sólo un formalismo para software, pero también define ontologías para elementos comunes de dominios de problema, como espacio físico y cronometraje de eventos.

Formalismo para una teoría de control

Un formalismo de filosofía de sistemas para representar la lógica del control de sistemas, USL está basado en un conjunto de axiomas de una teoría de control de sistemas general con reglas formales para su aplicación. En la base de cada sistema USL esta es un conjunto de seis axiomas y la suposición de un conjunto universal de objetos.^[6]​^[7]​ Los axiomas proporcionan la base formal para una "jerarquía" USL – referida como mapa, el cual es un árbol de control que se extiende a redes de relaciones entre objetos. Reglas explícitas para definir un mapa ha sido derivado de los axiomas, donde – entre otras cosas – estructura, comportamiento, y su integración está capturada. Cada axioma define una relación de dominación inmediata de un padre sobre sus niños. La unión de estas relaciones es control. Entre otras cosas, los axiomas establecen las relaciones de un objeto para invocación en tiempo y espacio, entrada y salida (dominio y codominio), derechos de acceso de entradas y derechos de acceso de salidas (derechos de acceso dominio y derechos de acceso de codominio), detección de error y recuperación, y ordenando durante sus estados de desarrollo y operacional. Cada sistema finalmente puede ser definido en términos de tres estructuras de control primitivo, cada cual está derivado de los seis axiomas – resultantes en una semántica universal para definir sistemas.

Todas las representaciones de un sistema se definen en términos de un mapa de funciones (FMap) y un mapa de tipos (TMap). Con USL, todas las funciones en un sistema y sus relaciones se definen con un conjunto de FMaps. Del mismo modo, todos los tipos en un sistema y sus relaciones se definen con un conjunto de TMaps. FMaps representa el mundo dinámico de acción (hacer) al capturar características funcionales y temporales (incluida la prioridad). TMaps representa el mundo estático (del ser) de los objetos al capturar características espaciales, por ejemplo, la contención de un objeto por otro o las relaciones entre ubicaciones de objetos en el espacio. FMaps están inherentemente integrados con TMaps. Tres estructuras primitivas universales derivadas del conjunto de axiomas y estructuras no primitivas derivadas en última instancia en términos de las estructuras primitivas especifican cada mapa. Las estructuras primitivas son universales en el sentido de que pueden usarse para derivar nuevas estructuras, funciones o tipos universales abstractos. El proceso de derivar nuevos objetos (es decir, estructuras, tipos y funciones) es equivalente al proceso de derivar nuevos tipos en una teoría de tipos constructiva. Las funciones primitivas, correspondientes a operaciones primitivas en tipos definidos en un TMap, residen en los nodos inferiores de un FMap. Los tipos primitivos, cada uno definido por su propio conjunto de axiomas, residen en los nodos inferiores de un TMap. Cada función primitiva (o tipo) puede realizarse como un nodo superior de un mapa en una capa inferior (más concreta) del sistema. Residente en cada nodo de un mapa es el mismo tipo de objeto (por ejemplo, una función en cada nodo de un FMap y un tipo en un TMap). El objeto en cada nodo juega múltiples roles; por ejemplo, el objeto puede servir como padre (en control de sus hijos) o hijo (siendo controlado por su padre). Mientras que cada función en un FMap tiene un mapeo de entrada a salida (dominio a codominio), cada tipo en un TMap tiene una relación entre su dominio y codominio. Una estructura relaciona cada padre y sus hijos de acuerdo con el conjunto de reglas derivadas de los axiomas de control. Una estructura primitiva proporciona una relación de la forma más primitiva (grano más fino) de control. Todos los mapas se definen en última instancia en términos de las estructuras primitivas y, por lo tanto, se rigen por las reglas asociadas con cada estructura: un padre controla a sus hijos para que tengan una relación dependiente (Join), independiente (Incluir) o de toma de decisiones (Or).

Cualquier sistema puede definirse completamente usando solo estructuras primitivas, pero las estructuras menos primitivas definidas y derivadas de las estructuras primitivas, y por lo tanto gobernadas por los axiomas de control, aceleran la definición y comprensión de un sistema. La estructura definida, una forma de reutilización tipo plantilla, proporciona un mecanismo para definir un mapa sin definir explícitamente algunos de sus elementos. Una estructura FMap tiene marcadores de posición para funciones variables; una estructura TMap tiene marcadores de posición para tipos variables; Una estructura universal tiene marcadores de posición para funciones o tipos. Async es un ejemplo de una estructura FMap de comunicación distribuida y en tiempo real con comportamiento asíncrono y sincrónico. Un ejemplo de una estructura TMap es TreeOf, una colección del mismo tipo de objetos ordenados utilizando un sistema de indexación de árbol. Cada estructura TMap asume su propio conjunto de posibles relaciones para sus tipos padre e hijo. Los tipos abstractos descompuestos con la misma estructura TMap heredan las mismas operaciones primitivas y, por lo tanto, el mismo comportamiento (cada uno de los cuales está disponible para FMaps que tienen acceso a miembros de cada uno de sus tipos TMap).

Implementación

El proceso de desarrollo de un sistema de software con USL junto con su automatización, 001 Tool Suite (001), es el siguiente: defina el sistema con USL, analice automáticamente la definición con el analizador 001 para asegurarse de que USL se usó correctamente, genere automáticamente mucho del diseño y todo el código de implementación con el generador de 001.^[8]​^[9]​^[10]​^[11]​ USL se puede utilizar para prestar su apoyo formal a otros idiomas.^[12]​

Objetivos

• Reducir la complejidad del proceso de creación de software.

• Asegurar el correcto funcionamiento de las propiedades inherentes del lenguaje.

• Asegfurar la perfecta integración del software en los sistemas.

• Asegurar la trazabilidad y evolución de los programas.

• Asegurar que no existan errores en la interfaz en el diseño de los sistemas.

• Maximizar la reutilización inherente del código.

• Asegurar que todos los modelos capturan semánticas de ejecución en tiempo real.

• Establecer la capacidad de entender automáticamente el comportamiento de una especificación funcional.

• Establecer la generación automática de código, reduciendo la necesidad de los diseñadores de involucrarse en detalles de implementación.

• Establecer la generación automática del 100 % de código listo para funcionar, sea cual sea el tamallo del programa.

• Eliminar la necesidad de testear constantemente el software antes de su implementación en la realidad.

Véase también

• Filosofía de Sistemas
• IDEF
• Modelo Arquitectura Conducida
• SysML
• Metodología de Proceso del objeto

Referencias

Más lectura

• Hamilton, M., Zeldin, S. (1976), "Software de Orden más Alto — Una Metodología para Definir Software," Transacciones de IEEE encima Ingeniería de Software, vol. SE-2, núm. 1, Mar. 1976.
• Hamilton, M., Hackler, W.R.. (2004), Profundamente Unidad de Navegación de Guiaje Integrada (DI-GNU) Principios de Arquitectura de Software Comunes (revisados dec-29-04), DAAAE30-02-D-1020 y DAAB07-98-D-H502/0180, Picatinny Arsenal, NJ, 2003-2004.
• Hamilton, M. Y Hackler, W.R. (2007), "Lengua de Sistemas Universales para Preventative Ingeniería de Sistemas," Proc. 5.ª Ann. Conf. Sistemas Eng. Res. (CSER), Stevens Instituto de Tecnología, Mar. 2007, papel #36.

Enlaces externos

• Hamilton Tecnologías