Artículo BIT
Las fronteras de la informática: aspectos software de la iniciativa de defensa estratégica
Las fronteros de la informática Aspectos software de la Iniciativa de Defensa Estratégica El proyecto militar norteamericano Iniciativa de Defensa Estratégica IDE o Guerra de las Galaxias ha abierto una serie de expectativas de desarrollo informático, tanto en su vertiente hardware como software. El siguiente artículo, resumen de un informe publicado por D.L. PARNAS, ofrece una panorámica de los diferentes requerimientos en materia de software que, en principio, parecen inalcanzables con estado del arte de la tecnología software. BIT6 3 Los fronteras de la Informática completado mientras era miembro del Panel on Computing in Support of Battle Management reunido bajo el patrocinio de la Oficina de la IDE. Se nos solicitó la identificación de los problemas informáticos que debían resolverse antes dé que se pudiese desplegar un sistema eficaz de misiles antibalisticos ABM. Es claro que los computadores deben tener un papel en los sistemas que la OIDE está considerando. que constituyen se enviaron a la OIDE del panel POR QUE EL SOFTWARE NO ES FIABLE El público, conocedor de sólo algunos casos de fallo software, puede interpretarlos como excepciones causadas por programadores ineptos. Los profesionales del software saben algo más ni siquiera los programadores más competentes pueden evitar tales problemas. Tipos de sistemas Los productos de ingeniería de las áreas tradicionales de la ingeniería. La matemática de las funciones continuas es bien comprendida. Cuando decimos que un sistema es descrito por puede encerrar sorpresas ocultas. Un salida. Un ingeniero que asegure, a través de un di se no cuidadoso, que los componentes del sistema están operando siempre dentro de su margen operativo normal, puede IDE El proyecto software más ambicioso en cuanto a costes jamás intentado. seño de sistemas analógicos. Los ingenie1 El diseño de muchos sistemas híbridos puede verificarse mediante una combinación de los dos métodos. Podemos para los componentes con comportamiento discreto. Dentro de esos estados se puede describir el comportamiento del sistema es pequeño. Para cada uno de estos estados se pueden aplicar las n de los utilizando muchas c mas digitales muy os pequeños subsistemas se puede ir y probar a un nivel exhaustivo. A encuentran errores de diseño en el hardware de computadores, estos son considerados excepcionales. Normalmente ocurren en aquellas partes del computador que estados discretos que no repetitiva que se tena de los computadores. de de estados en los sistemas software es órdenes de magnitud mayor que el número de estados en las partes de los computadores. Las funciones matemáticas que en su verificación. Esta diferencia contribuye de forma clara a la relativa falta de fiabilidad de los sistemas software ya la aparente falta de competencia de los ingenieros software. que no Para entender el software Existen dos técnicas para mejorar los problemas causados por esta diferencia fundamental en la tecnología 1 la tos altamente organizados de pequeños programas y 2 el uso de la lógica matemática para reemplazar a la matemática Dividir el software en módulos y construir cada módulo mediante programas estructurados ayuda bastante. se hace en forma apropiada, cada componente se ocupa de un número pequeño de casos y puede ser analizado el análisis. Incluso en los sistemas altamente estructurados, pueden ocurrir sorpresas o fallos de fiabilidad, porque la totalidad las muchas condiciones que componentes., encontrar la correcta ha demostrado ser muy difícil. Los sistemas software reales bien e son todavía poco frecuentes asumir en la ingeniería l que puede asumir en la i el papel que la matemática, esto no se ha verificado aún en la práctica. El gran número de estados y la falta de regularidad en el software dan lugar a expresiones matemáticas n pruebas para están dentro de su margen del programado de los actuales computadores Las fronteras de la Informática Hay progreso en esta área, pero es y estamos muy lejos de poderlo males, matemáticas que describen un programa son a menudo notablemente más difíciles de entender que el propio programa. La educación de los programad o res Existe además un problema de que empeora las diferencias entre el se mayoría de los diseñadores en las de la ingeniería han sí educados para entender las de que disponen. La mayoría de los programadores ni siquiera pueden empezara u herramientas más simples de los ingenie software. POR QUE EL SOTWARE DE LA IDE SERA POCO DIGNO DE CONFIANZA Para alcanzar la meta del IDE necesitaríamos un software tan desarrollado que pudiésemos tener u Características del software de dirección de combate propuesto 1. Se precisa que el sistema identifique, realice el seguimiento y dirija las armas hacia objetivos cuyas características del momento del combate. Debe distinguir estos objetivos frente a otros señuelos cuyas características también son desconocidas. 2. Los cálculos se realizan sobre una red de computadores conectados a sensores, armas y entre si, por canales cuyo, en el en que se solicite la actuación del sistema, no puede predecirse a causa de las posibles contramedidas del atacante. El subconjunto de componentes del sistema que. en forma efectiva, estará disponible en de la puesta en servicio, y a lo largo del mismo, no puede predecirse por la misma razón. bajo sal. 4.El período de servicio del sistema será tan pequeño que habrá poca posibilidad de intervención humana y ninguna posibilidad de depuración y modificación del programa durante el período de ser 5.Como muchos otros programas militares, hay limitaciones absolutas de tiempo real para los cálculos. Estos se compondrán básicamente de procesos periódicos, pero el número requerido de procesos y los requisitos computacionales de cada proceso, no pueden predecirse por anticipado, porque dependen de las características de los objetivos. Tampoco los recursos La ingeniería del software» no hará alcanzables. Ni siquiera podemos caso peor con cierta confianza.6.El sistema de armas incluirá u un sistema software grande y complejo. La variedad de armas y sensores probablemente crecerá durante el desarrollo y tras el despliegue. Las características de las armas y sensores no se conocen aún y es probable que permanezcan cambiantes durante muchos años tras el despliegue. El de dirección de combate tendrá que integrar un sistema software significativamente mayor de lo que nunca se ha mentado. Los componentes de este sistema estarán sujetos a modificaciones independientes. Implicaciones de estas características del problema claras implicaciones sobre la falibilidad de construir un software de dirección de combate que cumpla los requisitos de la IDE. 1. El software de control de disparo no las características de las armas y objetivos enemigos. Esta información se utiliza para determinar los algoritmos de reconocimiento los períodos de muestreo y las técnicas de filtrado de ruidos. Si el sistema que el enemigo pueda cambia, algún as de ellas en el día del combate, probable que situaciones donde a los fallos probables pueden predecirse sobre la base de la historia pasada, b los fallos de componentes son improbables y independientes, c el sistema tiene excedentes de capacidad, d las exigencias de tiempo real, si las hay. son débiles, esto es. prescindirse de ellas sin efectos a largo plazo. Nada de ello se cumple en el software de dirección de combate que se ha planteado. software de gran escala sin unas pruebas extensivas bajo condiciones realistas. Por ejemplo, en el software operacional para modificnal requieren unas pruebas extensivas en tierra, seguidas por pruebas en vuelo en las que puedan aproximarse cerca de las condición es del combate. Incluso con estas pruebas, pueden aparecer, y de hecho. La imposibilidad de sistema de defensa estratégica c 4. No es raro que se realicen modificaciones software sobre el terreno. Es habitual transportar a programadores hacia L —i de guerra helicópteros Las fronteras de la Informática depuraciones de programas en los camiones que computadores utilizados en Vietnam. Sólo mediante modificaciones, ese software llega a ser fiable. No se va a disponer de tales oportunidades en la guerra de 30 a 90 minutos en la a de dirección d e de 5. Los programas de este tipo deben cumplir fiablemente unas duras exigencias de tiempo real. En teoría, esto puede hacerse tanto mediante una planificación de tareas computacionales durante la ejecución o mediante una planificación prefijada. En la práctica, la eficiencia y la predecibilidad requieren algún tipo de diseñar este tipo de planificación por anticipado, no se podrá tener confianza en que el á la oxigene 6. Toda nuestra. con el tamaño del subsistemas modificables independientemente, y con el número de interfaces que deben definirse. Los problemas empeoran cuando las interfaces pueden cambiar. Las modificaciones subsiguientes aumentan complejidad del software y la dificultad de Conclusión Todas las estimaciones de costo indicar s f10 harán más difícil que los precedentes, independientemente del tamaño. Por causa d nuestra incapacidad de probarlo, podremos creer, con cierta confianza, hemos tenido éxito. Las armas nuclear seguirán siendo una potente amenaza. POR QUE F.L DESARROLLO CONVENCIONAL DEL SOFTWARE NO PRODUCE PROGRAMAS FIABLES El método convencional La manera más fácil de describir el método de programación utilizado en la mayoría de los proyectos actuales me la dio un profesor que estaba explicando cómo enseñar programación. Piensa como un a pensar y escribir lo que el computador tenía que hacer. Primero los pensamientos del computador en pasos mayores y, más tarde, retinar estos pasos grandes en secuencias de pasos menores. funciona bien en problemas demasiado pequeños para ser importantes. Pensamos que funciona porque funcionó en el primer programa que escribimos. Se puede seguir el método con programas que no tengan 66BIT Los aspectos informáticos de la dirección de combate son superables. las ni bucles. En cuanto nuestro computador debe depender de que no se conocen hasta que el se esté ejecutando, debemos del método etiquetando una o más las acciones y recordando cómo llegar a s. En cuanto introducimos bucles en el algunos de los puntos, y deberíamos todas. Según progresamos a de información sobre sucesos a y de añadir variables a nuestra comenzar a recordar lo que significa cada dato y bajo qué circunstancias Finalmente, cometemos un error. A hasta la fase de pruebas. A veces, el error no es muy importante sólo ocurre en ocasiones raras o imprevisibles. En ese caso, lo uso. A menudo, como uno precisa recordar tanto acerca del significado de cada etiqueta y de cada variable, la corrección de viejos problemas crea otros nuevos. En muchos de nuestros computadores hay varias fuentes de información y varias salidas a controlar. Esto podría llevar a concebir que el computador hace, a todos los efectos, muchas cosas a la vez. Si no puede predecirse por anticipado la secuencia de sucesos externos, la secuencia de acciones tomadas por el computador tampoco es predecible. El computador puede estar haciendo sólo una cosa cada vez, pero si se intenta pensar como un computador, aparecen muchos más puntos donde la acción estará condicionada a lo que ocurrió en el pasado. Intentar diseñar estos programas pensando las cosas en el orden a la confusión y da lugar a si que nadie pude entender completa El efecto del multiproceso Cuando hay más de un computador parece que el software esté a cada que realmente las está haciendo. No hay un programa secuencial que pueda estudiarse. Cualquier intento de pensar como un computador está obviamente condenado. Hay tantas posibilidades a considerar que únicamente unas pruebas extensivas pueden poner un principio de orden en las cosas. E incluso tras las pruebas tenernos incidentes. También los programado res profesionales utilizan este enfoque He tenido ocasión de estudiar una gran cantidad de software práctico y de discutir programas con montones de programadores profesionales. En los últimos años, muchos programadores han tratado de mejorar sus métodos de trabajo, utilizando diversos enfoques de diseño de software. Sin embargo, cuando descienden al nivel de escribir programas ejecutables, vuelven al modo de pensar convencional. Aún estoy buscando un programa representativo, en da en la secuencia de ejecución esperada. i algunos t avanzados, texto y en las conferencias científicas, pero la mayoría de los programadores sigue usando el enfoque básico de pensar las cosas en el orden en que el computador las e de r 3 ce deficiencias de los Cómo librarse de este enfoque inadecuado Debería estar claro que la escritura y comprensión de programas muy grandes en tiempo rea pensando como un computador supera nuestras capacidades intelectuales. Cómo ocurre entonces que tenemos tanto software que es bastante fiable como para utilizarlo. La respuesta es simple La programación es un asunto de prueba y error. Se escriben los programas sin ninguna esperanza de que serán correctos al principio. Se pasa tanto tiempo, al menos, probando y corrigiendo errores como se pasó escribiendo el programa inicial. Las grandes entidades tienen grupos separados encargados de las pruebas para asegurar la calidad. No puede confiarse en Las fronteras de la Informática sus propios programas, cuando se sabe que es correcto, sino cuando la frecuencia de descubrimiento de nuevos aceptable por los responsables. Los Conclusión El software militar del que dependemos los grandes sistemas software en tiempo real, que deben ser fiables desde su primera utilización. Se precisa un cambio drástico Durante 25 años hemos sabido que nuestros métodos de inadecuados para grandes proyectos. La investigación en ingeniería del software, metodología de programación, diseño de y métodos. La orientación común de los cantidad de cosas que un programador debe recordar cuando prueba y cambia un programa. son 1 la uso de semánticas formales de programas y 2 el uso de interfaces abstractas especificadas formalmente, para esconder la información sobre un módulo a los i sobre 5. Un tercera idea, peor comprendida pero no manejar las complejidades procedentes de la concurrencia y la multiprogramación. Ya en los últimos setenta, las deas básicas de la La separación entre teoría y práctica era grande y creciente. Los seguidores de los enfoques estructurados en software que decían creer en estos principios, no eran capaces de aplicarlos consistentemente. Para cubrir ese vacío, en 1977 la Marina de los EE.UU. la o. dura. El proyecto ha aclarado dos c muchas de las propuestas de los un pueden llevarse a cabo 2 1 ingeniería software es todo Estos métodos reducen, pero no el los errores. Reducen, pero no necesidad de pruebas., director de la SDI. El trabajo del SCR se ha basa 1.Deberían precisarselos requisitos requisitos de antes de c diseño del programa. 2. Debería dividirse el sistema en abstracción antes de comenzar la escritura del 3.Cada módulo debería tener una espetes de comenzar la escritura del programa. 4. Deberían utilizarse métodos formales 5.Los sistemas en tiempo real deberían período y límites especificados. Los programas deberían ser escritos Hemos demostrado que los primeros software militar Todavía no hemos probado que estos métodos den lugar a un piensan que el diseño del software se facilitará, y los errores desaparecerán, no han atacado problemas de suficiente La dificultad de la ingeniería Se pueden escribir documentos, entendemos los modelos ni ítem. os que hay detrás de los documento para documentar todas las deben tomar para escribir esos. Muy a menudo, no se sabe cómo ha que se puede operar con el sistema. Sola requisitos. Vale la pena, deben tomarse en la implementación una de ellas debe asignarse a un módulo puede hacerse a otro construido antes. Cuando es seguro pasaremos por alto difíciles de diseño. E resultado será Sabemos cómo especificar para módulos. Tenemos un c todos los diseños alternativos. Se puede La conclusión común a extraer de todas principios claros de diseño software, se precisa una amplia experiencia con sistemas dad y fiable. BIT67 Las fronteras de la Informática Los lenguajes de productividad que se n m introducción de los lenguajes compilados, con la introducción de mejores lenguajes. Una mejor notación siempre ayuda, pero proporcionen la misma magnitud de mejora que la obtenida por los primeros de estos lenguajes. Nuestra experiencia en el programa SCR no ha mostrado que la falta de un lenguaje sea un problema funda Los lenguajes de programación ahora son suficientemente flexibles, de forma que, pero no podemos esperar que esto de lugar a diferencias sustanciales. Los entornos de programación El éxito del UNIX como herramienta de desarrollo de programas ha dejado claro UNIX permitido eliminar muchas de las tareas aparecen en la producción de grandes prosa investigación en entornos de programación. También aquí espero que puedan, pero no que se produzcan grandes problemas de nuestro entorno de programación no han sido un impedimento importante para nuestro trabajo para SCR. métodos de capacidad de e trabajo no superará las dificultades a los aspectos informáticos de la de combate de la IDE. Los la tecnología del software y otras de unas pruebas de campo portante, hemos aprendido que la con éxito de estos métodos depende de sistemas similares. No hay en dirección de combate para la Conclusión n hombre modesto. La programación automática no supondrá ninguna ayuda, debido a la ausencia de información para escribir especificaciones fiables. LA INTELIGENCIA ARTIFICAL Y LA INICIATIVA DE DEFENSA ESTRATÉGICA Hoy en día son de uso El e técnicas de te enfoque se estudia os para determinar q para sólo podian aplicación de la Debe resaltarse que la primera definición define la IA como un conjunto de problemas, la segunda define la IA como un conjunto de técnicas. La primera definición tiene un significado cambiante. En la Edad Media se pensaba que la aritmética, precisaba inteligencia. Ahora reconocemos puede entrar dentro de la definición de programa y comprendemos el problema, deja de considerarse como IA en el futuro. Aunque es posible que un determinado trabajo satisfaga ambas definiciones, el mejor trabajo de IA.l que yo he visto no utiliza Los trabajadores de la IA. 1 utilizan a menudo enfoques y científicos tradicionales. Estudian el problema, sus condicionantes físicos y lógicos, y escriben un programa que no intenta imitar el modo Desgraciadamente, no puedo identificar un corpus de técnicas o Cuando se estudian estos programas de IA., se descubre que utilizan claramente enfoques científicos que también se utilizan en trabajos que no reciben la calificación de IA. La mayor parte del trabajo es específica para el problema en cuestión, y se precisa. Se habla de la IA como de una fuente mágica de nuevas ideas. Hay buenos I, mi opinión los enroques tomados en la IA.2 son peligrosos y, gran parte del, equivoco. Las reglas que se sacan del estudio de las personas, resultan ser Los programas heurísticos se desarrollan mediante un proceso de prueba y error en el que se añade una nueva regla cuando se. Este método normalmente da lugar a programas cuyo comportamiento es mal comprendido y difícil de predecir. Los ligado res en lA.2 aceptan este método evolutivo de programación como normal y gramas incluso menos de lo que lo hago en los programas s. No En o ando s he tenido que y siempre he resultado defraudado Vista de cerca, la heurística llegaba a cubrir un pequeño numero de casos obvios pero no funcionaba en general. Las fronteras de la Informática Sobre los sistemas expertos se ha oído hablar mucho del éxito de una clase particular de sistemas Toda ejemplo de tales sistemas, utilizado para resolver problemas reales por personas desarrollo. Ese ejemplo es siempre programa diseñado para configurar computadores VAX. Para muchos as, este no parece un problema difícil parece el tipo de problemas que se presta a una solución algorítmica, porque los sistemas VAX se construyen con bien diseñados, a un articulo que señalaba que el mantenimiento de este programa se había convertido en una pesadilla. Se comprendía deficientemente, estaba mal o y por ello, era difícil de cambiar. Tengo buenas razones para creer que podría reemplazarse por un programa mc e ingeniería software en lugar de técnicas .a IDE representa un problema que puede ser más difícil que los abordados por la IA. 1 y los sistemas expertos. Los trabajáis de los problemas de la IDE aparecen en humanos. De hecho hay actualmente personas que pueden observar, con i alto nivel de y confianza, misis en vuelo balístico y distinguir las cabes nucleares de los señuelos RESOLVERÁ LA PROGRAMACIÓN AUTOMÁTICA EL PROBLEMA DEL SOFTWARE DE LA IDE muchas veces que la solución al problema del software es la programación automática. Todo lo que hay que hacer es escribir las especificaciones para el software, y el computador encontrará un programa. Se puede esperar que tal tecnología produzca programas fiables para la IDE La programación automática siempre ha sido un eufemismo sustituyendo a programación en un lenguaje de programación de más alto nivel que el disponible por el programador. La investigación en sobre la implementación de La Se sabe Usualmente. sí capacidad ce entrada capacidad automática es desde años que se pueden lenguajes de programación de 1. La Única cuestión real era la los programas resultantes. si la entrada de un algoritmo, el que el uso de práctico para sistemas con limitada y con as de tiempo real. Cuando la es una descripción no. escribir la especificación un programa. No respecto a nuestra La Habilidad de la programación automática El uso de lenguajes mejorados ha dado lugar a una reducción en la cantidad de detalles que un programador debe tener en cuenta, y por ello, a una mejora en la fiabilidad. Sin embargo, los lenguajes de como entrada a estos sistemas, no modo no es Creo que las declaraciones que se han hecho sobre sistemas do programación .a programación automática de un tipo que sea sustancialmente diferente de lo que de combate de la IDE. Ademas, uno de los problemas básicos de la IDE es que no tenemos la información para escribir en que se pueda confiar. En tal situación, la programación automática no es ninguna ayuda. LA VERIFICACIÓN DF PROGRAMAS Y LA FIABILIDAI DEL SOFTWARE DE LA Tienen significados que son matemáticos. especificaciones de u programa son objetos matemáticos. No debería poder probar que un a su especificación. 1ste ha sido u tema de investigación desde hace más. Si podemos probar la corrección c BIT69 Las de la Informática La concurrencia Las técnicas de prueba más están restringidas a un intento de probar que un a proporcionaría una respuesta ce i en una situación de. para probar la corrección de presencia de fallos hardware e resulta inconcebible que una prueba de la corrección, incluso de una del software de. sistema de dirección de combate de la IDE. Qué se puede probar Puede probarse que ciertos programas pequeños en lenguajes de programación especiales se ajustan a una especificación. La palabra pequeño es relativa. Los que en verificación considerarían grande un programa tic 500 líneas. Al se consideraría pequeño. Los programas cuyas pruebas he visto eran bastante más pequeños que 500, y realizaban tareas matemáticas bien definidas. Las especificaciones En e caso de la IDE no contra las que prueba. la falta de especificaciones eliminaría todo el sentido de una prueba formal. Si para software, no tendríamos modo de probar que un programa que satisficiese la especificación real efectos. Las pruebas de programas tales como un modelo del campo gravitatorio terrestre son tan limpias o formalizables matemáticamente. A menudo están escritas en lenguajes de programación cuya semántica es difícil de formalizar. Yo no he visto pruebas para este tipo de programas. Y no sólo son las pruebas manuales las que están limitadas a programas de pequeño tamaño con especificaciones matemáticas los probadores y verificadores 70BIT Podemos tener Te en las pruebas en un programa, pero no proporcionan en matemática pura, hay muchos de pruebas que se publicaron tienden a ser fiable cuando pequeñas, David L. Pamas, es profesor de Informática de la Victoria Universiiv. en la Colombia Británica I Canadá. durante muchos años de la Oficina de Investigación y son grandes, complejas y no leídas nadie aparte del autor. Esto es lo que o cualquier intento de probar la a
30 oct 2015