ENTRADAS

25 jun 2016

EL PROBLEMA DEL ESTADO EN EL SOFTWARE

¿Por qué preocupa el estado en el software?

El software no es más que una secuencia de instrucciones a la que se le pasa una serie de datos de entrada y genera unos datos de salida. Parece sencillo desarrollar software, entonces ¿por qué se complican tanto los proyectos de software? ¿por qué se retrasan? ¿por qué fallan? ¿Hay unos “bichos” que sabotean el trabajo de los desarrolladores? Parece lógico pensar que ese no es el motivo.

En esta entrada vamos a ver qué causa realmente los fallos de software y de qué herramientas disponen los ingenieros y desarrolladores para evitarlos.

ESTADO EN EL SOFTWARE

PROBLEMA DEL ESTADO EN EL SOFTWARE: ¿bichos?

El estado en el software

Los estados determinan el proceso de cada uno de los elementos de los datos de entrada.

El culpable de una gran parte de los fallos es el gran número de estados que hay y las relaciones entre ellos. Cuando hablamos de un estado nos referimos a una combinación de valores concreta para todos los parámetros del sistema.

Por ejemplo, cuando conectamos nuestro móvil a una red Wi-Fi está en un estado de “Conectado a red Wi-Fi” y eso puede tener efecto sobre el resto de estados de los programas que tiene en ejecución. Podría afectar al actualizador de sistema, de manera que sólo se descargan aplicaciones si no está usando la conexión de la red móvil.

Cómo se expresan los estados

Los ingenieros de software representamos cada parámetro del sistema como una expresión de variables lógicas. Una variable lógica es un enunciado que puede ser verdad o no. Por ejemplo, “ayer comí espinacas” y “mi hermano Luis tiene 4 años más que yo”.

Una expresión de variables es un enunciado compuesto por los operadores Y, O y NO y una serie de variables lógicas. Por ejemplo, “ayer compré espinacas y me las comí en la cena” y “voy a ver una serie o una película”.

Por ejemplo, supongamos que tenemos un perro (Palanca) y le gusta jugar con un pato de goma. Entonces la expresión “Palanca es un perro y a Palanca le gusta jugar con un pato de goma” es cierta. En cambio, “Palanca es un gato” es falsa.

ESTADO EN EL SOFTWARE

Palanca disfrutando de un paseo

Normalmente, para no escribir mucho, se le asignan a las variables letras. Volviendo a nuestro ejemplo:

  • A equivale a “Palanca es un perro”.
  • B equivale a “A Palanca le gusta jugar con un pato de goma”.
  • C equivale a “Palanca es un gato”

La primera expresión será A Y B y la segunda simplemente C.

Evidentemente podemos tener muchos más enunciados que nos permitan definir expresiones más complejas:

  • D equivale a “Palanca duerme en el felpudo”
  • E equivale a “A Palanca le da miedo la aspiradora”
  • F equivale a “A Palanca le da miedo la batidora”

Si hacemos NO D Y (E O F), queremos decir que Palanca no duerme en el felpudo y tiene miedo de la aspiradora, la batidora (o los dos). Los paréntesis dan prioridad a una parte de la expresión lógica (como en las expresiones aritméticas).

Destacamos que el hecho de que Palanca pueda tener miedo a ambos aparatos se debe a que el O lógico es algo distinto a la disyunción que solemos usar a diario. El O lógico se conoce como disyunción inclusiva, ya que si sus operandos son ambos ciertos devuelve verdad.

Vamos a mostrar un ejemplo un poco más real: un ascensor que sube (o baja) una planta. Las flechas discontinuas indican que se realiza esa transición si la variable de la que se originan toma un valor falso y las flechas continuas indican lo contrario, esto es, que la transición se realiza si la variable origen toma valor verdadero. Los números entre paréntesis indican el identificador del estado en el sistema que generó este grafo, puedes ignorarlos.

ESTADO EN EL SOFTWARE

GRAFO DE SISTEMA. ESTADO EN EL SOFTWARE DE UN MODELO

Como puedes ver, la última transición siempre va a false (falso) o true (verdadero) en función de si ese estado es ilegal o es legal (respectivamente). Por ejemplo, el ascensor ha de estar en alguna planta, por eso, si el sistema indica que no está en el suelo y no está en la primera planta, está en un estado imposible o ilegal.

Para que nos sea más fácil, solemos escribir estas reglas de la siguiente forma:

NOT isGround AND NOT isFirstFloor ? False

Suponemos que las variables son ciertas y que cuando se evalúa como cierta la parte de la izquierda de la flecha, se devuelve la parte de la derecha. Los operadores los escribimos en inglés (AND, NOT, OR) por motivos de tradición y costumbre.

Así, también podemos ver un estado como un conjunto de variables lógicas evaluados mediante reglas propias según el sistema. Cada estado será legal cuando la expresión de predicados lógicos se evalúe a cierto y en caso de que se evalúe a falso será ilegal. Las reglas las definimos con los operadores Y, O y NO como hemos hecho anteriormente.

Si me he explicado bien y has entendido esto, enhorabuena, estás de suerte y ya conoces los principios básicos sobre los que se rige el software.

El problema

Conforme crece el software, el número de estados suele “dispararse”. Eso implica que o se conocen claramente las transiciones legales entre cada uno de los estados, o se puede entrar en un estado inconsistente. Este estado inconsistente normalmente implica un estado de error.

Presentamos ahora un ejemplo real con 17 variables y 10 reglas. Eso nos genera un grafo de estados de 97 vértices que es imposible de verificar manualmente en un plazo de tiempo corto.

ESTADO EN EL SOFTWARE

GRAFO DE SISTEMA CON 17 VARIABLES Y 10 REGLAS

17 variables no son muchas, imagínate el número de variables que hay en un sistema software complejo, como por ejemplo, los usados en vehículos de transporte o en sistemas bancarios.

Esta complejidad es demasiado para nuestras capacidades intelectuales y los desarrolladores de software cometen fallos. Dichos fallos permiten a los programas en ejecución entrar en los estados inconsistentes o ilegales de un sistema. Por ejemplo, haciendo que un pago no se realice de forma efectiva aunque sí se haya marcado como pagado en el sistema. De hecho, este último ejemplo no es inventado, el Royal Bank of Scotland sufrió un fallo software que congeló más de 600000 pagos.

ESTADO EN EL SOFTWARE

DESARROLLADORA DE SOFTWARE A LA CAZA DE UN FALLO

Marta está trabajando duro porque se ha dado cuenta de que hay un fallo en el servidor en producción debido a que el software entra en un estado ilegal si se da cierta condición. ¿Podrá corregirlo antes de que sus efectos sean catastróficos?

Peor aún, piensa que llegar a un estado de error puede implicar no sólo cuantiosas pérdidas económicas, sino en el peor de los casos, pérdida de vidas humanas. Por esto, y en determinados casos, hay que tener un software con el mínimo número de errores posible.

La solución

Evidentemente desde los comienzos de la computación, multitud de científicos e ingenieros se han afanado en trabajar para evitar este tipo de desastres, de manera que hay varias formas de abordar el problema en función del coste que pueda tener un error de software.

Si el coste es bajo

Se revisan los estados manualmente y se hacen baterías de pruebas para detectar los errores más importantes en los flujos de trabajo críticos.

En función del interés en reducir los errores y el presupuesto del proyecto se harán más pruebas y éstas serán más profundas.

Si el coste es alto

Se evitan los errores especificando completamente los estados y transiciones entre éstos.

Los lenguajes de programación funcional se han usado en el desarrollo de sistemas bancarios con éxito. Estos lenguajes evitan los efectos colaterales entre distintas partes del código, por lo que se pueden trazar los cambios de estado de forma más sencilla y por tanto, validar que sólo se dan las transiciones válidas. La contrapartida es que resulta mucho más complejo desarrollar con estas herramientas, claro está.

Por otro lado, en el caso de posible pérdida de vidas humanas se usan los llamados métodos formales. Estos métodos buscan la descripción de forma exacta y matemática de los estados del sistema. Hay multitud de métodos, como el Model Checking o la demostración automática de teoremas.

Conclusión

El software falla porque es muy costoso hacerlo infalible. Sólo determinados sectores como el aeroespacial, la automoción y la medicina tienen interés (y los fondos) como para desarrollar un software que no tenga fallos.

En la mayoría de las aplicaciones, es mucho más rentable hacer pruebas y en caso de fallo aplicar una corrección. Hacer software sin errores haría todo el proceso de desarrollo tan lento y costoso que la mayoría de los sectores no podrían asumirlo. Por lo general, se prefiere desarrollar la funcionalidad cuanto más rápido mejor, para poder sacar al mercado un producto antes que la competencia y luego, corregir el producto.

Es por esto, que a veces los sistemas operativos y demás software que usamos a diario fallan. Ningún usuario estaría dispuesto a pagar 10, 100 o incluso 1000 veces lo que ha pagado a cambio de no tener fallos, por lo que no se puede asegurar que no los haya. Así que las compañías distribuyen actualizaciones de su software que no son más que correcciones de fallos detectados una vez que se ha puesto a disposición del público.

Autor: DIEGO ROMERO LÓPEZ

Ver más entradas del mismo autor

Si quieres participar en el blog como colaborador en alguna de las secciones, envíanos un mail a info@fdet.es 

Grupo FdeT

Compartir:
Facebooktwittergoogle_pluslinkedin

Leave a Reply

A %d blogueros les gusta esto: