Métodos Formales

Aunque el término se utiliza ampliamente, no parece existir una clara definición acerca de qué son
(Hehner, 2006). En muchas ocasiones el término se emplea simplemente para indicar la utilización
de un lenguaje de especificación formal, pero no incluye una descripción de cómo se utiliza o la
extensión de su uso. Incluso el término “lenguaje de especificación formal” no es preciso, ya que no
es claro si los lenguajes “específicamente” tienen como objetivo diseñar la implementación, en lugar
de especificar el problema. En este trabajo se utiliza el término “métodos formales” para describir
cualquier enfoque que utilice un lenguaje de especificación formal, pero que describa su función en
el proceso del desarrollo de software. Utilizar métodos formales necesariamente implica un proceso
formal de refinamiento, razonamiento y prueba. El término “lenguaje de especificación formal” se
utiliza aquí para referenciar un lenguaje en el que es posible especificar completamente la
funcionalidad de todo o parte de un programa, de tal forma que sea susceptible de razonamiento
formal, y que se fundamenta en una sólida base matemática, más en que si es lo suficientemente
abstracto.

El término “métodos formales” se refiere entonces al uso de técnicas de la lógica y de la matemática

discreta para especificar, diseñar, verificar, desarrollar y validar programas. La palabra “formal” se
deriva de la lógica formal, ciencia que estudia el razonamiento desde el análisis formal -de acuerdo
con su validez o no validez-, y omite el contenido empírico del razonamiento para considerar sólo la
forma -estructura sin materia-. Los métodos formales más rigurosos aplican estas técnicas para
comprobar los argumentos utilizados para justificar los requisitos, u otros aspectos de diseño e
implementación de un sistema complejo.

En la lógica formal como en los métodos formales el objetivo es el mismo, “reducir la dependencia
de la intuición y el juicio humanos para evaluar argumentos” (Kiniry & Zimmerman, 2008). Los
métodos menos rigurosos enfatizan en la formalización y renuncian a la computación, definición que
implica un amplio espectro de técnicas, y una gama igualmente amplia de estrategias. La interacción
de las técnicas y estrategias de muchos métodos formales, en determinados proyectos, se limita por
el papel que interpretan y por los recursos disponibles para su aplicación (García et al., 2006).

Los métodos formales en la Ingeniería de Software

En Ingeniería de Software, un método formal es un proceso que se aplica para desarrollar programas,
y que explota el poder de la notación y de las pruebas matemáticas. Además, los requisitos, la
especificación y el sistema completo deben validarse con las necesidades del mundo real (Kuhn et
al., 2002). En la Ingeniería de Software los métodos formales se utilizan para:
 - Las políticas de los requisitos. En un sistema seguro se convierten en las principales
propiedades de seguridad que éste debe conservar -el modelo de políticas de seguridad
formal-, como confidencialidad o integridad de datos.
- La especificación. Es una descripción matemática basada en el comportamiento del sistema,
que utiliza tablas de estado o lógica matemática. No describe normalmente al software de
bajo nivel, pero sí su respuesta a eventos y entradas, de tal forma que es posible establecer
sus propiedades críticas.
- Las pruebas de correspondencia entre la especificación y los requisitos. Es necesario
demostrar que el sistema, tal como se describe en la especificación, establece y conserva las
propiedades de las políticas de los requisitos. Si están en notación formal se pueden diseñar
pruebas rigurosas manuales o automáticas.
- Las pruebas de correspondencia entre el código fuente y la especificación. Aunque muchas
técnicas formales se crearon inicialmente para probar la correctitud del código, pocas veces
se logra debido al tiempo y costo implicados, pero pueden aplicarse a los componentes
críticos del sistema.
- Pruebas de correspondencia entre el código máquina y el código fuente. Este tipo de pruebas
raramente se aplica debido al costo, y a la alta confiabilidad de los compiladores modernos.

Por tanto, los métodos formales en la Ingeniería de Software son técnicas matemáticamente rigurosas
que se utilizan para describir las propiedades del sistema, y proporcionan marcos de referencia para
especificarlo, desarrollarlo y verificarlo de forma sistemática, en lugar de hacerlo ad hoc (Jones et al.,
2006). Un método es formal si posee una base matemática estable, normalmente soportada por un
lenguaje de especificación formal, que permite definir, de manera precisa, nociones como
consistencia y completitud y, aún más relevantes, la especificación, la implementación y la
correctitud. Al utilizar notaciones y lenguajes formales es posible estructurar claramente los requisitos
del sistema, y generar las especificaciones que Matemáticamente rigurosas significa que las
especificaciones en los métodos formales son declaraciones gramaticalmente correctas en una lógica
matemática, y que la verificación formal es una deducción rigurosa en ella. Es decir, que cada paso
se deriva de una regla de inferencia que se puede comprobar mediante un proceso automático (Liu &
Venkatesh, 2005). Los métodos formales en la Ingeniería de Software difieren en la forma como se
aplican, y en los tiempos necesarios para cada fase del ciclo de vida; su estructuración y utilización
requiere mayor tiempo y trabajo para desarrollar la especificación, pero su utilización garantiza, más
“formalmente”, que la construcción de los diseños es correcta.
Ventajas de los métodos formales

La utilidad de los métodos formales en la Ingeniería de Software es un tema que se debate desde hace
varias décadas. Recientemente, con el surgimiento de la Ingeniería de Conocimiento en la Sociedad
de la Información, y la aplicación de los métodos formales en los procesos industriales, nuevamente
surge el debate. A continuación se detallan algunas de las ventajas de utilizarlos.

Especificación. Uno de los problemas más ampliamente reconocido en el desarrollo de software es

la dificultad para especificar claramente el comportamiento que se espera del software, problema que
se agudiza con el actual desarrollo basado en componentes, ya que el ingeniero tiene sólo una
descripción textual de los requisitos, procedimientos, entradas permitidas y salidas esperadas.
Asegurar que este tipo de software sea seguro es un problema, no sólo por su tamaño y complejidad,
sino porque el código fuente no suele estar disponible para los componentes que se adquieren. Una
forma de ofrecer “garantía rigurosa” del producto es definir, con precisión, el comportamiento
esperado del software (NASA, 1995). La especificación formal proporciona mayor precisión en el
desarrollo de software, y los métodos formales brindan las herramientas que pueden incrementar la
garantía buscada. Desarrollar formalmente una especificación requiere conocimiento detallado y
preciso del sistema, lo que ayuda a exponer errores y omisiones, y por lo que la mayor ventaja de los
métodos formales se da en el desarrollo de la especificación (Clarke & Wing, 1996). En la
formalización de la descripción del sistema se detectan ambigüedades y omisiones, y una
especificación formal puede mejorar la comunicación entre ingenieros y clientes.

Verificación. Para asegurar la calidad de los sistemas es necesario probarlos, y para asegurar que se
desarrollan pruebas rigurosas se requiere una precisa y completa descripción de sus funciones, incluso
cuando en la especificación se utilicen métodos formales. Una de las aplicaciones más interesantes
de éstos es el desarrollo de herramientas, que pueden generar casos de prueba completos desde la
especificación formal.

Las técnicas de verificación formal dependen de especificaciones matemáticamente precisas y, desde

un punto de vista costo-beneficio, generar pruebas desde la especificación puede ser uno de los usos
más productivos de los métodos formales. Aproximadamente la mitad del tiempo del equipo de
trabajo, en un desarrollo típico de software comercial, se invierte en esfuerzo para desarrollar pruebas,
e “incluso con este nivel de esfuerzo sólo se eliminan los errores más evidentes” (Saiedian & Hinchey,
1996). Algunas mediciones empíricas demuestran que las pruebas, generadas con herramientas
automatizadas, ofrecen una cobertura tan buena o mejor que la alcanzada por las manuales, por lo que
los ingenieros pueden elegir entre producir más pruebas en el mismo tiempo, o reducir el número de
horas necesarias para hacerlas (Gabbar, 2006).

Validación. Mientras que la verificación se puede realizar semiautomáticamente y las pruebas

mecánicamente, la validación es un problema diferente. Una diferencia específica entre verificación
y validación es que la primera responde a si “se está construyendo el producto correctamente”, y la
segunda a si "se está construyendo el producto correcto" (Dasso & Funes, 2007). En otras palabras,
la verificación es el conjunto de actividades que aseguran que el software implementa correctamente
una función específica, y la validación es un conjunto de actividades diferentes que aseguran que el
software construido corresponde con los requisitos del cliente (Amman & Offutt, 2008).

Desde el conjunto de requisitos es posible verificar, formal o informalmente, si el sistema los

implementa; sin embargo, la validación es necesariamente un proceso informal. Sólo el juicio humano
puede determinar si el sistema que se especificó y desarrolló es el adecuado para el trabajo. A pesar
de la necesidad de utilizar este juicio en el proceso de validación, los métodos formales tienen su
lugar, especialmente en grandes y complejas aplicaciones, como en modelado y simulación. Una de
sus aplicaciones más prometedoras es en el modelado de requisitos, ya que, al diseñarlos
formalmente, el teorema provisto en la herramienta de prueba se puede utilizar para explorar sus
propiedades, y a menudo detectar los conflictos entre ellos. Este método no sustituye al juicio
humano, pero puede ayudar a determinar si se especificó el "sistema correcto", por lo que es más
fácil determinar si las propiedades deseadas se mantienen (Flynn & Hamlet, 2006).

Ventajas

 Se comprende mejor el sistema.

 La comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua
de los requisitos del usuario.
 El sistema se describe de manera más precisa.
 El sistema se asegura matemáticamente que es correcto según las especificaciones.
 Mayor calidad en el software respecto al cumplimiento de las especificaciones.
 Mayor productividad.
Desventajas

 El desarrollo de herramientas que apoyen la aplicación de métodos formales es complicado y los

programas resultantes son incómodos para los usuarios.
 Los investigadores por lo general no conocen la realidad industrial.
 Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra
demasiado dogmático.
 Se considera que la aplicación de métodos formales encarece los productos y ralentiza su
desarrollo.

Clasificación

La clasificación más común se realiza en base al modelo matemático subyacente en cada método, de
esta manera podrían clasificarse en:

 Especificaciones basadas en lógica de primer orden y teoría de conjuntos: permiten

especificar el sistema mediante un concepto formal de estados y operaciones sobre estados. Los
datos y relaciones/funciones se describen en detalle y sus propiedades se expresan en lógica de
primer orden. La semántica de los lenguajes está basada en la teoría de conjuntos. Los métodos
de este tipo más conocidos son: Z, VDM y B.

 Especificaciones algebraicas: proponen una descripción de estructuras de datos estableciendo

tipos y operaciones sobre esos tipos. Para cada tipo se define un conjunto de valores y operaciones
sobre dichos valores. Las operaciones de un tipo se definen a través de un conjunto de axiomas
o ecuaciones que especifican las restricciones que deben satisfacer las operaciones. Métodos más
conocidos: Larch, OBJ, TADs.

 Especificación de comportamiento:

 Métodos basados en álgebra de procesos: modelan la interacción entre procesos concurrentes.

Esto ha potenciado su difusión en la especificación de sistemas de comunicación (protocolos y
servicios de telecomunicaciones) y de sistemas distribuidos y concurrentes. Los más conocidos
son: CCS, CSP y LOTOS.

 Métodos basados en Redes de Petri: una red de petri es un formalismo basado en autómatas, es
decir, un modelo formal basado en flujos de información. Permiten expresar eventos
 concurrentes. Los formalismos basados en redes de petri establecen la noción de estado de un
sistema mediante lugares que pueden contener marcas. Un conjunto de transiciones (con pre y
post condiciones) describe la evolución del sistema entendida como la producción y consumo de
marcas en varios puntos de la red.

 Métodos basados en lógica temporal: se usan para especificar sistemas concurrentes y reactivos.
Los sistemas reactivos son aquellos que mantienen una continua interacción con su entorno
respondiendo a los estímulos externos y produciendo salidas en respuestas a los mismos, por lo
tanto el orden de los eventos en el sistema no es predecible y su ejecución no tiene por qué
terminar.

Los diez 10 mandamientos de los métodos formales

La decisión de hacer uso de los métodos formales en el mundo real no debe de adoptarse a la ligera.
Bowen y Hinchley han acuñado los diez mandamientos de los métodos formales, como guía para
aquellos que estén a punto de embarcarse en este importante enfoque de la ingeniería del software.

1. Seleccionarás la notación adecuada: Con objeto de seleccionar eficientemente dentro de la amplia

gama de lenguajes de especificación formal existente, el ingeniero del software deberá considerar el
vocabulario del lenguaje, el tipo de aplicación que haya que especificar y el grado de utilización del
lenguaje.

2. Formalizarás, pero no de más: En general, resulta necesario aplicar los métodos formales a todos
los aspectos de los sistemas de cierta envergadura. Aquellos componentes que sean críticos para la
seguridad serán nuestras primeras opciones, e irán seguidos por aquellos componentes cuyo fallo no
se pueda admitir (por razones de negocios).

3. Estimarás los costes: Los métodos formales tienen unos costes de arranque considerables. El
entrenamiento del personal, la adquisición de herramientas de apoyo y la utilización de asesores bajo
contrato dan lugar a unos costes elevados en la primera ocasión. Estos costes deben tenerse en cuenta
cuando se esté considerando el beneficio obtenido frente a esa inversión asociada a los métodos
formales.

4. Poseerás un experto en métodos formales a tu disposición: El entrenamiento de expertos y la

asesoría continua son esenciales para el éxito cuando se utilizan los métodos formales por primera
vez.
5. No abandonarás tus métodos formales de desarrollo: Es posible, y en muchos casos resulta
deseable, integrar los métodos formales con los métodos convencionales y/o con métodos orientados
a objetos. Cada uno de estos métodos posee sus ventajas y sus inconvenientes. Una combinación de
ambos, aplicada de forma adecuada, puede producir excelentes resultados.

6. Documentarás suficientemente: Los métodos formales proporcionan un método conciso, sin

ambigüedades y consistente para documentar los requisitos del sistema. Sin embargo, se recomienda
que se adjunte un comentario en lenguaje natural a la especificación formal, para que sirva como
mecanismo para reforzar la comprensión del sistema por parte de los lectores.

7. No comprometerás los estándares de calidad: Los métodos formales no tienen nada de mágico, y
por esta razón, las demás actividades de SQA deben de seguir aplicándose cuando se desarrollen
sistemas.

8. No serás dogmático: El ingeniero de software debe reconocer que los métodos formales no son
una garantía de corrección. Es posible (o como algunos probablemente dirían) que el sistema final,
aun cuando se haya desarrollado empleando métodos formales, siga conteniendo pequeñas omisiones,
errores de menor importancia y otros atributos que no satisfagan nuestras expectativas.

9. Comprobarás, comprobarás y volverás a comprobar: Los métodos formales no absuelven al

ingeniero del software de la necesidad de llevar a cabo unas comprobaciones exhaustivas y bien
planeadas.

10. Reutilizarás cuanto puedas: A la larga, la única forma racional de reducir los costes del software
y de incrementar la calidad del software pasa por la reutilización. Los métodos formales no modifican
esta realidad. De hecho, quizás suceda que los métodos formales sean un enfoque adecuado cuando
es preciso crear componentes para bibliotecas reutilizables.

Los siete 07 mitos sobre los métodos formales

Los siete mitos más generalizados sobre los métodos formales son variaciones de los siguientes:

1. Los métodos formales garantizan que el software esta perfecto: El mito más importante es que
los métodos formales serian todopoderosos, si nosotros humildes mortales pudiésemos aplicarlos.
Este mito es pernicioso porque nos lleva a expectativas irreales y a la idea de que los métodos formales
son de alguna forma todo o nada.
2. Los métodos formales se centran en demostrar corrección: En los Estados Unidos, gran parte del
trabajo desarrollado en métodos formales se ha concentrado en la verificación de programas. Esto ha
hecho que los métodos formales parezcan muy difíciles y no muy relevantes para la vida real.

3. Los métodos formales son útiles solo para sistemas críticos: Esta creencia se basa en la percepción
de la dificultad que implica la aplicación de métodos formales. La verdad es que los sistemas críticos
requieren un uso más acucioso de métodos formales, pero cualquier sistema puede beneficiarse con
el uso de algunas técnicas de especificación formal.

4. Los métodos formales requieren matemáticos entrenados: Los métodos formales se basan en
notaciones matemáticas, y muchas personas creen que esto los hace difíciles para la práctica de los
ingenieros de software. Este mito, a su vez, se basa en la percepción de que las matemáticas son
intrínsecamente difíciles.

5. Los métodos formales aumentan el costo del desarrollo: Se acostumbraba decir que a pesar que
el costo que significaba usar métodos formales era muy alto, de todas formas era conveniente porque
resultaba en menores costos de mantenimiento del software.

6. Los métodos formales son incomprensibles para los usuarios: Una especificación formal esta
llena de símbolos matemáticos que resultan incomprensibles para cualquiera que no este
familiarizado con la notación. De ahí que se suponga que son inútiles para clientes no matemáticos.

7. Los métodos formales no se usan en grandes proyectos reales: Los métodos formales se asocian
comúnmente con departamentos académicos y organizaciones de investigación. Se piensa que solo
estas organizaciones tienen la capacidad necesaria para usar métodos formales y que estos solo son
apropiados para las aplicaciones idealizadas que estos grupos desarrollan.

CONCLUSIÓN

Los métodos formales son técnicas matemáticas, a menudo soportadas por herramientas, para el
desarrollo de sistemas software y hardware. Su rigor matemático le permite a los ingenieros analizar
y verificar sus modelos en cualquier parte del ciclo de vida del desarrollo; y dado que la fase más
importante en estos procesos es la Ingeniería de Requisitos, son útiles para elicitarlos, articularlos,
representarlos y especificarlos (George & Vaughn, 2003). Sus herramientas proporcionan el soporte
automatizado necesario para la integridad, trazabilidad, verificabilidad, reutilización, y para apoyar
la evolución de los requisitos, los puntos de vista diversos y la gestión de las inconsistencias (Ghose,
2000).

Los métodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un
sistema basado en computadora aplicando una notación rigorosa y matemática; utilizando esté
método descubre y corrige ambigüedades, inconsistencias y errores.

Tenemos que tomar en cuenta que los métodos formales están presentes en bastantes campos y no
solo los referidos a la ingeniería y la informática, los métodos formales tienen un amplio recorrido y
su utilidad y eficiencia en desarrollo críticos están demostradas. Sus herramientas proporcionan el
soporte automatizado necesario para la integridad, trazabilidad, verificabilidad, reutilización y para
apoyar la evolución de los requisitos, los puntos de vista diversos y la gestión de las inconsistencias.

Los métodos formales pueden ser aplicados en las empresas para mejorar sus procedimientos y
productos.

La decisión de utilizar métodos formales debe considerar los costes de arranque, así como los cambios
puntuales asociados a una tecnología radicalmente distinta. En la mayoría de los casos, los métodos
formales ofrecen los mayores beneficios para los sistemas de seguridad y para los sistemas críticos
para los negocios.
 Modelo por Prototipos

El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo.

El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe
utilizar muchos recursos.

El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles
para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es
evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software
que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades
del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y
el cliente vea resultados a corto plazo.

Etapas

 Plan rápido.
 Modelado, diseño rápido
 Construcción del Prototipo
 Desarrollo, entrega y retroalimentación
 Comunicación
 Entrega del desarrollo final

Ventajas

 Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, procesamiento o salida.
 También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro
de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que
debería tomar la interacción humano-máquina
 Se puede reutilizar el código

La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea
más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera
de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de
construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera
cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este
ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto.
 Inconvenientes

 El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A
causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos
importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor
parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente
que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema
final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco
recomendado.
 En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones
de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación
incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador
puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de
que dichas elecciones pasen a formar parte del sistema final...

CONCLUSIÓN

A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma
efectivo para la ingeniería del software. La clave es definir las reglas del juego desde el principio; es
decir, el cliente y el desarrollador se deben poner de acuerdo en:

 Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos.

 Que el prototipo se descarte, al menos en parte.
 Que después se desarrolle el software real con un enfoque hacia la calidad.