Especificaciones

formales

Métodos
Formales

1
Especificaciones formales
“Las especificaciones formales usan notación matemática para describir de
forma precisa las propiedades que debe tener un sistema de información, sin
restringirse indebidamente por la forma en que se logran estas propiedades”
(Spivey, 1989, p. 1).

Llegados a este punto, ya nos introdujimos en los métodos formales y su

polémica. Avancemos: los métodos formales se basan en el desarrollo de
una especificación formal. Una especificación formal son formalismos que
se utilizan para capturar las propiedades requeridas de un sistema o para
capturar su comportamiento. Las propiedades que pueden ser capturadas
incluyen:

 comportamiento funcional;
 estructura interna;
 estados del sistema.

Esos formalismos, como hemos visto en lecturas previas, son las

matemáticas.

Si no utilizáramos especificaciones formales desde los requisitos,

pasaríamos al código directamente o utilizaríamos especificaciones no
formales intermedias:

Requisitos  Código
Requisitos  Especificación/modelo  Código

Si utilizamos especificaciones formales, entonces, a partir de los requisitos

desarrollaríamos especificaciones formales:

Requisitos  Especificación formal/modelo formal  Código

Una especificación formal consiste de un grupo de descripciones

matemáticas del comportamiento del sistema pero que no aclaran nada
sobre cómo se implementará.

 Notación matemática.
 Estructuras de datos definidas:
o conjuntos;
o relaciones;
o funciones.

2
 Especificación del comportamiento basado en expresiones lógicas
(lógica de primer orden) y en el álgebra.

Todo esto es lo que nos va a permitir razonar acerca de las propiedades del
sistema así (matemáticamente) expresadas. Estos razonamientos tienen
como fin probar la adecuación a los requisitos; se pueden probar, entre
otros, los siguientes:

 que las acciones resultan en un conjunto discreto de estados;

 que un estado de error es inalcanzable;
 que ciertos estados deseables son alcanzables;
 que se cumplen las precondiciones;
 que se cumplen las poscondiciones;
 que se cumplen las invariantes ante cambios de estados;
 que se cumplen las invariantes de loops.

Estas especificaciones formales, una vez probadas, son luego “refinadas”

en una especificación, también formal, con un menor nivel de abstracción y
más detalle de la implementación, proceso que podemos ver en la Figura 1.
Esto puede repetirse n veces hasta determinado momento en que el
sistema es codificado en un lenguaje de alto nivel.

Figura 1: Las especificaciones van ganando detalle y pierden abstracción

Fuente: Kemmerer, 1985, https://goo.gl/e7W6r5

3
Lo hasta aquí expresado es válido para métodos formales, con sus
correspondientes formas de especificar formalmente, como Z, VDM o
Larch, que hacen foco principalmente en modelar el comportamiento de
sistemas secuenciales. Los sistemas secuenciales son aquellos en que las
salidas dependen de los valores de entrada y de los valores de las variables
internas que forman el estado. El estado interno, o estado de un sistema,
es la unión de la información que posee en dicho momento, o dicho de
otra forma, el valor que asumen sus variables. Por lo tanto, los estados
posibles pueden ser infinitos.

Las especificaciones formales modelan estos estados con conjuntos,

relaciones y funciones, y las transiciones entre los estados, es decir, el
“comportamiento”, mediante pre- y poscondiciones e invariantes.

Veamos como ejemplo una agenda de cumpleaños (simple, y por lo trivial

del caso, no ambigua, pero vale como ejemplo) con los siguientes
requisitos:

 La agenda debe almacenar como máximo 256 cumpleaños.

 Los nombres no pueden repetirse.
 El nombre de un cumpleañero está compuesto por su apellido + una
coma + su nombre de pila.
 La fecha de cum--pleaños está compuesta por el día + el mes + el año,
todos expresados en números.
 Podemos agregar un nuevo cumpleaños siempre y cuando no esté
agregado.
 Si al agregar un cumpleaños el nombre ya existe, entonces lo
mantenemos y cambiamos la fecha existente por la nueva.
 Podemos borrar un nombre que exista.
 Una fecha de cumpleaños no puede ser una fecha futura.
Almacenamos la fecha de nacimiento, no su próximo cumpleaños.

Primero, tratemos de descubrir los requisitos que hacen referencia al

estado del sistema y los que hacen referencia a su comportamiento.

Referentes al estado:

 La agenda debe almacenar como máximo 256 cumpleaños.

 Los nombres no pueden repetirse.
 El nombre de un cumpleañero está compuesto por su apellido + una
coma + su nombre de pila.
 La fecha de cumpleaños está compuesta por el día + el mes + el año,
todos expresados en números.
 Una fecha de cumpleaños no puede ser una fecha futura.
Almacenamos la fecha de nacimiento, no su próximo cumpleaños.

4
Referentes al comportamiento:

 Podemos agregar un nuevo cumpleaños siempre y cuando no esté

agregado.
 -Si al agregar un cumpleaños el nombre ya existe, entonces lo
mantenemos y cambiamos la fecha existente por la nueva.
 Podemos borrar un nombre que exista.

Ahora, usando la teoría de conjuntos, los nombres de los cumpleañeros

pueden ser un conjunto, las fechas de nacimientos de estas personas
pueden ser otro conjunto y, como se asignan unos a otros, debe existir una
relación o una función que las una (que las relacione).

Los conjuntos:

Figura 2: Los conjuntos

Nombres Fechas

. Juan M. . 12/05/1990

. Lucas E. . 21/07/1985

. Marcela J. . 04/01/2001

Fuente: elaboración propia

Y la relación entre ellos, que llamaremos agenda:

5
Figura 3: Relación entre los conjuntos

Nombres Fechas

. Juan M. . 12/05/1990

. Lucas E. . 21/07/1985

. Marcela J. . 04/01/2001

Fuente: elaboración propia

Que expresados matemáticamente:

Nombres == {Juan M., Lucas E., Marcela .J}

Fechas == {12/05/1990, 21/07/1985, 04/01/2001}

Y expresamos la relación entre ambos como:

Nombres <--> Fechas == ℙ (Nombres X Fechas)

O suponiendo que la relación se llame cumpleaños:

Agenda == {(Juan M. ↦ 12/05/1990), (Lucas E. ↦ 21/07/1985), (Marcela J. ↦

04/01/2001)}

Para especificar el comportamiento, por ejemplo, podemos agregar un

nuevo cumpleaños siempre y cuando este no exista ya.

Dado el nuevo cumpleaños para agregar expresado como (nombre1 ↦

fecha1), entonces: (nombre1 ↦ fecha1) ∉ Agenda

Y para especificar que la agenda puede contener como máximo 256

cumpleaños: #Nombres <= 256

6
Bibliografía de referencias
Kemmerer, R. A. (1985). Testing Formal Specifications to Detect Design
Errors. IEEE Transactions on Software Engineering, 11(1), 32-43.
Recuperado de
https://www.computer.org/csdl/trans/ts/1985/01/01701896.pdf

Spivey, J. M. (1989). An Introduction to Z and Formal Specifications.

Software Engineering Journal, 4(1), 40-50.