ESPECIFICACIÓN FUNCIONAL
Independientemente del método de análisis seleccionado, los principios de operación presentados en el Capítulo 1 1 siempre serán aplicables. Se modelan los datos, las funciones y el comportamiento. Los modelos resultantes deben de ser descompuestos (refinados) para proporcionar un grado de detalle cada vez más elevado. El objetivo global consiste en pasar de una especificación que captura la esencia de un problema, a una especificación que proporciona una cantidad de detalle sustancial para su implementación.
La ingeniería del software de sala limpia satisface los principios de análisis operacional por cuanto emplea un método denominado especijicución de estructuru de caja Una < a j a » encapsula el sistema (o algún aspecto del sistema) con un cierto grado de detalle. Mediante un proceso de refinamiento progresivo, se van refinando las ca-jas para formar una jerarquía en la cual cada caja tiene transparencia referencial.
Esto es, «el contenido de información de cada especificación de caja basta para definir su refinamiento, sin depender de la implementación de ninguna otra caja». Esto capacita al analista para desglosar jerárquicamente el sistema, pasando de la representación esencial situada en la parte superior, hasta los detalles específicos de la implementación situados en la parte inferior. Se utilizan tres tipos de ca-jas descubrir los errores) y depurado después (para eliminar los errores). Cuando se publica finalmente el software, la utilización práctica descubre aun más defectos, y comienza otro ciclo de comprobación y depuración. Este trabajo repetido asociado a las actividades mencionadas resulta costoso y lleva mucho tiempo. Y lo que es peor, puede ser degenerativo; la corrección de errores puede (inadvertidamente) dar lugar a la introducción de otros errores.
En la ingeniería del software de sala limpia, la comprobación unitaria y la depuración se ven sustituidas por una verificación de corrección y por pruebas basadas en la estadística. Estas actividades, junto con el mantenimiento de registros para una continua mejora, hacen que el enfoque de sala limpia sea único.
Caja negra. Esta caja especifica el comportamiento del sistema, o de parte de un sistema. El sistema (o parte de él) responde a estímulos específicos (sucesos) mediante la aplicación de un conjunto de reglas de transición que hacen corresponder el estímulo con la respuesta.
Caja de estado. Esta caja encapsula los datos de estados y de servicios (operaciones) de forma análoga a los objetos. En esta vista de especificación, se representan las entradas de la caja de estados (los estímulos) y sus salidas (las respuestas). La caja de estados también representa la «historia de estímulos» de la caja negra, es decir, los datos encapsulados en la caja de estado que deben ser mantenidos entre las transiciones implicadas.
Caja limpia. Las funciones de transición que están implicadas en la caja de estado se definen en la caja limpia. Dicho literalmente, la caja limpia contiene el diseño procedimental correspondiente a la caja de estados.
A medida que se va realizando cada uno de estos pasos de refinamiento, se produce también una verificación de la corrección. Se verifican las especificaciones de las cajas de estado para asegurar que todas y cada una de ellas se ajustan al comportamiento definido por la especificación de la caja negra predecesora. De manera similar, se verifican las especificaciones de las cajas transparentes con respecto a la caja de estados predecesora.
Es preciso tener en cuenta que los métodos de especificación basados en métodos formales se pueden utilizar en lugar del enfoque de especificación de estructura de cajas. El unico requisito es que se puede verificar formalmente cada uno de los niveles de especificación.
-------------------------------------------------------------------------------------------------------------------------------------
Especificación de caja negra
Una especificación de caja negra describe una abstracción, estímulos y respuestas. La funciónf'se aplica a una secuencia, S*, de entradas (estímulos) y esta función los transforma en una salida (respuesta), R. Para componentes sencillos de software,f; puede ser una función matemática, pero en genera1,f se describe empleando el lenguaje natural (o bien un lenguaje de especificación formal).
Muchos de los conceptos introducidos para sistemas orientados a objetos son aplicables también para la caja negra. Las abstracciones de datos y las operaciones que manipulan estas abstracciones, se ven encapsuladas por la caja negra. Al igual que una jerarquía de clases, la especificación de caja negra puede mostrar las jerarquías de utilización en que las cajas de nivel inferior heredan las propiedades de las cajas de nivel superior dentro de la estructura de árbol.
-------------------------------------------------------------------------------------------------------------------------------------
Especificación de caja de estado
La caja de estado es «una generalización sencilla de una máquina de estado». Recordando la descripción del modelado de comportamiento y de los diagramas de transición de estados que se ofrece en el Capítulo 12, un estado es algún modo observable de comportamiento del sistema. A medida que se produce el procesamiento, el sistema va respondiendo a sucesos (estímulos) efectuando una transición que parte del estado y llega a algún nuevo estado. A medida que se efectúa la transición, puede producirse una acción. La caja de estado utiliza una abstracción de datos para determinar la transición al estado siguiente (respuesta) que se producirá como consecuencia de la transición.
Según se muestra en la fig. la caja de estado contiene una caja negra. El estímulo, S, que se introduce en la ca-ja negra, procede de alguna fuente externa y de un conjunto de estados internos del sistema, T. Mills proporciona una descripción matemática de la función,,f, de la caja negra contenida en el seno de la caja de estado:
g:S*xT*+RxT
donde g es una subfunción que está asociada a un estado específico t. Cuando se consideran en su conjunto, las parejas de estados y subfunciones (t, g) definen la función de caja negra.6.
------------------------------------------------------------------------------------------------------------------------------------
Especificación de caja limpia.
La especificación de caja limpia está íntimamente relacionada con el diseño de procedimientos y con la programación estructurada. En esencia, la subfunción g, que se encuentra dentro de la caja de estado, se ve sustituidapor las estructuras de programación estructurada que implementa g.
Como ejemplo, considérese la caja limpia que se muestra en la Figura. La caja negra g, que se muestra en Figura 26.4 se ve sustituida por una sucesión de estructuras que contienen una estructura condicional. Éstas, a su vez, se pueden refinar para formar Lajas transparentes del interior a medida que vaya avanzando el procedimiento de refinamiento progresivo.
Es importante tener en cuenta que la especificación de procedimientos descrita en la jerarquía de caja liinpia se puede demostrar a efectos de corrección. Este tema se considerará en la sección siguiente.
-------------------------------------------------------------------------------------------------------------------------------------
REFINAMIENTO Y VERIFICACIÓN DEL DISEÑO.
El enfoque de diseño que se utiliza en la ingeniería del software de sala limpia hace mucho uso de la filosofía de la programación estructurada. Pero, en este caso, la programación estructurada se aplica de forma mucho más rigurosa.
La funciones básicas de procesamiento (que se describían durante los refinamientos anteriores de la especificación) se refinan ahora utilizando una «expansión progresiva de funciones matemáticas en estructuras de conectividad lógica [por ejemplo, si-entonces-sino] y subfunciones, donde la expansión [se] efectúa hasta que todas las funciones identificadas pudieran ser enunciadas directamente en el lenguaje de programación utilizado para la implementación».
El enfoque de la programación estructurada se puede utilizar de forma eficiente para refinar la función, pero ¿qué pasa con el diseño de datos'? En este aspecto, entra en juego un cierto número de conceptos fundamentales de diseño. Los datos del programa se encapsulan como un conjunto de abstracciones a las cuales prestan servicio las subfuncionec. Los conceptos de encapsulamiento de datos, ocultamiento de información y los tipos de datos se utilizan entonces para crear el diseño de datos.
-----------------------------------------------------------------------------------------------------------------------------------
Refinamiento y verificación del diseño.
Cada especificación de caja limpia representa el diseño de un procedimiento (subfunción) necesario para efectuar una transición de caja de estado. Mediante la caja limpia, se utilizan las estructuras de programación estructurada y de refinamiento progresivo. Una función de programa, .f; se refina para dar lugar a una sucesión de subfunciones 8 y h. Éstas a su vez se refinan para formar estructurascondicionales (si-entonces-sino y hacer-mientras). Un refinamiento posterior ilustra la elaboración lógica continuada.
Para lograr una verificacion formal de correccion, se asocia un conjunto de condiciones de corrección genéricas a las estructuras de programación estructurada. Si se expande una función f para dar una sucesión g y h, entonces la condición de corrección para todas las entradas defes:
¿Es cierto que g seguido por h da lugar af!
Si se refina una función p para llegar a una estructura condicional (si-entonces-sino), la condición de corrección para toda entrada de p es: ;Siempre que sea cierta la condición (c) es cierto que q realizap y siempre que (c) sea falsa, es cierto que Y realizap? Si se refina una función m en forma de bucle, las condiciones de corrección para todas las entradas de ni son:
¿Está garantizada la finalización?
¿Siempre que (c) sea verdadera es cierto que IZ seguido por m realiza m, siempre que (c) seafalso, sigue realizándose m si se obvia el bucle?
Cada vez que se refina una caja limpia hasta el siguiente nivel de detalle, se aplican las condiciones de corrección indicadas anteriormente.
Es importante tener en cuenta que la utilización de estructuras de programación estructurada restringe el número de comprobaciones de corrección que es preciso efectuar. Se verifica una sola condición en busca de sucesiones; se verifican dos condiciones para los sientonces- sino; y se verifican tres condiciones para los bucles.
Con objeto de ilustrar alguna verificación de corrección para un diseño de procedimientos, se utiliza un sencillo ejemplo presentado por primera vez por parte de Linger y sus colaboradores. Nuestro objetivo es diseñar y verificar un pequeño programa que calcule la parte entera, y, de una raíz cuadrada de un entero dado, x.
Para verificar la corrección de este diseño, es preciso definir las condiciones de entrada y de salida. La condición de entrada indica que x debe ser mayor o igual a O. La condición de salida requiere que x permanezca intacta y que adopte un valor dentro del intervalo mostrado en la figura. Para demostrar que el diseño es correcto, es necesario demostrar que las condiciones c o n ~ i ~ i ~bzuocl,e , wnt , son ciertas en todos los casos. En algunas ocasiones se denominan suhdemostraciones.
