¿Cuáles son las barreras que impiden la adopción generalizada de métodos formales? [cerrado]

Cerrada . Esta pregunta está basada en la opinión . Actualmente no está aceptando respuestas.

¿Quieres mejorar esta pregunta? Actualice la pregunta para que pueda ser respondida con hechos y citas editando esta publicación .

Cerrado hace 2 años .

Se pueden usar métodos formales para especificar, probar y generar código para una aplicación. Esto es menos propenso a errores, por lo tanto, se utiliza principalmente en programas críticos / de seguridad.

¿Por qué no lo usamos con más frecuencia para la programación diaria, o en aplicaciones web, etc.?

Referencias

development-process code-quality formal-methods

— toto
fuente

Podríamos construir casas con paredes de 5 pies de grosor, como castillos medievales. La mayoría de las veces, eso sería más problema de lo que vale.

— Baldrickk

Puede intentar aplicar métodos formales a un proyecto de desarrollo web y ver cómo funciona. Lo más probable es que notes que estás haciendo un gran esfuerzo en una actividad de bajo valor. Compare eso con las pruebas rápidas de humo, que ya capturarán muchos errores. Curiosamente, los sistemas de tipo estático son un tipo simple de sistema de prueba, pero especialmente el desarrollo web evita esos lenguajes (en lugar de eso prefiere los lenguajes altamente dinámicos como Ruby, PHP o JavaScript). La correlación no implica causalidad, pero da pausa al pensamiento.

— amon

Entonces, ¿preferiría especificar en un lenguaje de especificación en lugar de programar en un lenguaje de programación? Ok, podrás probar que funciona de acuerdo con las especificaciones. Pero, ¿cómo va a demostrar que la especificación refleja el verdadero problema?

— Christophe

@toto la pregunta es: hacer las cosas bien (trabajar de acuerdo con las especificaciones) o hacer las cosas bien (tener las buenas especificaciones). Mientras que en teoría la especificación es lo que queremos, en la práctica rara vez sabemos con certeza lo que realmente se necesita: beyssonmanagement.com/2012/10/29/…

— Christophe

Para aquellos que están decepcionados de que esto esté cerrado, ahora hay una gran publicación en el blog: ¿Por qué las personas no usan métodos formales?

— icc97

Respuestas:

Un ingeniero es una persona que puede hacer con un dólar lo que cualquier idiota puede hacer con 10.

Restricciones de recursos, limitaciones de presupuesto, limitaciones de tiempo, todas son importantes.

El desarrollo de software utilizando métodos formales suele ser significativamente más costoso y lleva mucho más tiempo que sin él. Además, para muchos proyectos, la parte más difícil es comprender los requisitos del negocio. Todo lo que usa métodos formales lo compra en ese caso es una prueba de que su código corresponde al 100% a su comprensión incompleta e incorrecta de los requisitos comerciales.

Por esa razón, el uso de métodos formales, pruebas, verificación de programas y técnicas similares generalmente se limita a "cosas que importan", es decir, software de aviónica, sistemas de control para equipos médicos, plantas de energía, etc.

— Jörg W Mittag
fuente

También agregaría que poner métodos formales en el lenguaje de programación es un área de investigación activa actualmente, es decir, aún no está listo para la corriente principal

— jk.

Acepto esta respuesta, pero también quería un enfoque sobre por qué los métodos formales todavía se consideran "caros" y "lentos", especialmente cuando sabemos lo caro que es el mantenimiento y el seguimiento / depuración de código en grandes proyectos.

— toto

TDD y BDD son enfoques basados en los principios de la lógica de Hoare, una base de enfoques formales. Mejoran la eficiencia, no la restan.

— Martin Spamer

@toto Las pruebas son realmente, REALMENTE difíciles. Muchas cosas que los matemáticos dan por sentado en las pruebas no se aplican en los programas. Por ejemplo, en C ++, la adición no es asociativa: (-1 + 1) + INT_MAX = INT_MAX, -1 + (1 + INT_MAX)es un comportamiento indefinido.

— Hovercouch

@toto: La razón por la que se consideran "caros" y "que consumen mucho tiempo" es porque podemos ver los proyectos que se desarrollan utilizando métodos formales y verificar empíricamente que esos proyectos tardan mucho más en desarrollarse. Observe el tiempo de desarrollo de seL4 / L4.verified, por ejemplo, en comparación con cualquier otra implementación de L4.

— Jörg W Mittag

¿Programar o no programar?

Para resolver un problema con un producto de software, después de tener una comprensión de los requisitos, puede SEA escribir un programa utilizando lenguajes de programación O especificar el programa utilizando un lenguaje formal y herramientas de generación de código de uso. Este último solo agrega un nivel de abstracción.

¿Hacer las cosas bien o hacer las cosas bien?

El enfoque formal le brinda una prueba de que su software funciona de acuerdo con las especificaciones. Entonces su producto hace las cosas bien. ¿Pero hace lo correcto?

Los requisitos en los que está trabajando pueden ser incompletos o ambiguos. Incluso podrían tener errores. En el peor de los casos, las necesidades reales ni siquiera se expresan. Pero una imagen vale más que mil palabras, solo imágenes de Google para "Lo que quiere el cliente", por ejemplo de este artículo :

El costo de la formalidad.

En un mundo perfecto, tendría requisitos completamente detallados y perfectos desde el principio. Entonces podría especificar completamente su software. Si opta por formal, su código se generará automáticamente para que sea más productivo. Las ganancias de productividad compensarían el costo de las herramientas formales. Y ahora todos usarían métodos formales. Entonces, ¿por qué no lo es?

¡En la práctica, esto rara vez es la realidad! Es por eso que tantos proyectos en cascada fallaron, y por qué los métodos de desarrollo iterativos (ágil, RAD, etc.) tomaron la delantera: pueden manejar requisitos, diseños e implementaciones incompletos e imperfectos y refinarlos hasta que estén bien.

Y aquí viene el punto. Con métodos formales, cada iteración requiere tener una especificación formal completamente consistente. Esto requiere un pensamiento cuidadoso y trabajo adicional, porque la lógica formal no es indulgente y no le gustan los pensamientos incompletos. Los simples experimentos desechables se vuelven caros bajo esta restricción. Y también cada iteración que llevaría a retroceder (por ejemplo, una idea que no funcionó, o un requisito que no se entendió).

En la práctica

Cuando no está obligado a usar métodos formales por razones legales o contractuales, también puede lograr una calidad muy alta sin sistemas formales, por ejemplo, mediante el uso de programación basada en contratos y otras buenas prácticas (por ejemplo, revisión de código, TDD , etc.). No podrá probar que su software funciona, pero sus usuarios disfrutarán de un software de trabajo antes.

Actualización: esfuerzo medido

En la edición de octubre de 2018 de Communications of the ACM hay un artículo interesante sobre el software verificado formalmente en el mundo real con algunas estimaciones del esfuerzo.

Curiosamente (basado en el desarrollo del sistema operativo para equipos militares), parece que producir software probado formalmente requiere 3,3 veces más esfuerzo que con las técnicas de ingeniería tradicionales. Entonces es realmente costoso.

Por otro lado, requiere 2.3 veces menos esfuerzo obtener software de alta seguridad de esta manera que con el software de ingeniería tradicional si agrega el esfuerzo para certificar dicho software a un alto nivel de seguridad (EAL 7). Entonces, si tiene requisitos de alta confiabilidad o seguridad, definitivamente hay un caso de negocios para ir formal.

El diseño de seL4 y el desarrollo del código tomaron dos años-persona. La suma de todas las pruebas seroespecíficas a lo largo de los años llega a un total de 18 años-persona para 8,700 líneas de código C. En comparación, L4Ka :: Pistachio, otro microkernel de la familia L4, comparable en tamaño a seL4, tardó seis años-persona en desarrollarse y no proporciona un nivel significativo de seguridad. Esto significa que solo hay un factor 3.3 entre el software verificado y el software de ingeniería tradicional. Según el método de estimación de Colbert y Boehm, 8 una certificación tradicional de Criterios Comunes EAL7 para 8,700 líneas de código C tomaría más de 45.9 años-persona. Eso significa que la verificación formal de implementación a nivel binario ya es más que un factor de 2.3 menos costoso que el nivel de certificación más alto de Criterios comunes, pero proporciona una garantía significativamente más sólida.

— Christophe
fuente

La programación basada en contratos utiliza al menos pruebas informales.

— Frank Hileman

@FrankHileman sí! Y el simple hecho de aclarar condiciones previas, condiciones posteriores e invariantes ayuda en gran medida a revisar el código de manera eficiente, reducir errores y sistematizar las pruebas.

— Christophe

Esta debería ser la mejor respuesta con diferencia.

— Hashim

Cada programa en cualquier idioma puede considerarse como una especificación formal (equivalente a alguna máquina de torneado). Cualquier "especificación formal" de nivel superior que se utilizará para demostrar la corrección formal también es, simplemente, otro programa. Pero es (típicamente) un programa malo, incompleto, vago, insuficientemente pensado. Y no es coincidencia, generalmente escrito por personas que no saben programar (generalmente son expertos en dominios).

Y así, demostrando que un programa es compatible (produce las mismas respuestas o como lo caracterice) con sus requisitos formales de nivel superior, invariablemente se reduce a cómo se resuelven las ambigüedades en la especificación formal de nivel superior. No hay una buena forma general de hacerlo.

Esa asignación de requisitos de alto nivel a detalles de nivel inferior es la esencia de lo que se trata la programación real. No debería sorprender que el trabajo central que realiza un programador que lee e interpreta las especificaciones no se puede reemplazar con un saludo manual y diciendo "ahora solo vea si este programa de ejemplo cumple con esta especificación formal de alto nivel".

Incluso en los primeros días de la programación lógica, donde este concepto primero parecía tan prometedor (porque tanto la especificación de alto nivel como los programas subyacentes reales podían escribirse en el mismo lenguaje), este problema central resultó intratable.

— Lewis Pringle
fuente