MOD Unidad 3: Modelado y verificación formal

Modelamiento de Software Carrera de Software
Ph.D. Franklin Parrales 1
05/06/2021
Modelado y
verificación formal
Unidad 3
Material docente compilado por el docente Ph.D. Franklin Parrales Bravo
para uso de los cursos de Modelamiento de Software

05/06/2021
Objetivo general de la Unidad 3
Evaluar los modelos de software mediante el uso
de técnicas formales que permitan validar el
correcto funcionamiento del software.

05/06/2021
Bibliografía consultada
• Pressman, Roger
S. "Ingeniería del
software." Un
enfoque (2011).
Cap. 21

05/06/2021
Contenido
• Métodos de Ingeniería del Software de Sala limpia
– Enfoque de sala limpia
– Especificación funcional, de caja negra, de caja de
estado y caja transparente
– Diseño de Sala limpia

05/06/2021
Modelado y verificación formal
• Ingeniería de software de sala limpia y
métodos formales
– Ambos exigen un enfoque de especificación
especializado y cada uno aplica un método de
verificación único.
– Ambos son bastante rigurosos y ninguno de los
dos es utilizado ampliamente por la comunidad
de ingenieros de software.
• Si debe crear un software "a prueba de
balas", estos métodos pueden ayudar
enormemente.

05/06/2021
Contenido

05/06/2021
El Proceso del enfoque de sala limpia
SE
RG
BSS FD CV CG CI
TP
SUT C
Incremento 1
RG
BSS FD CV CG CI
TP
SUT C
Incremento 2
RG
BSS FD CV CG CI
TP
SUT C
Incremento 3
SE — ingeniería de software
RG — recopilación de
requerimientos
BSS — especificación de
estructura de caja
FD — diseño formal
CV — verificación de exactitud
CG — generación de código
CI — inspección de código
SUT — prueba de uso estadístico
C — certificación
TP — planeación de prueba

05/06/2021
El enfoque de sala limpia
• Planificación de incrementos: adopta la estrategia incremental
• Recopilación de requisitos: define una descripción de los requisitos
a nivel del cliente (para cada incremento).
• Especificación de estructura de caja: describe la especificación
funcional
• Diseño formal: las especificaciones (llamadas “cajas negras”) se
refinan iterativamente (con un incremento) para volverse análogas a
los diseños arquitectónicos y procedimentales (llamados “cajas de
estado” y “cajas transparentes”, respectivamente).
• Verificación de exactitud: la verificación comienza con la estructura
de caja de nivel más alto (especificación) y avanza hacia los
detalles y el código del diseño mediante un conjunto de "preguntas
de exactitud". Si estos no demuestran que la especificación es
correcta, se utilizan métodos de verificación más formales
(matemáticos).

05/06/2021
El enfoque de sala limpia
• Generación, inspección y verificación de código: las
especificaciones de la estructura de la caja, representadas en un
lenguaje especializado, se transmiten al lenguaje de programación
apropiado.
• Planificación de pruebas estadísticas: un conjunto de casos de
prueba en los que se planifica y diseña el ejercicio de la
"distribución de probabilidad" de uso.
• Pruebas de uso estadístico: ejecute una serie de pruebas derivadas
de una muestra estadística (la distribución de probabilidad indicada
anteriormente) de todas las posibles ejecuciones de programas por
parte de todos los usuarios de una población objetivo.
• Certificación: una vez que se han completado las pruebas de
verificación, inspección y uso (y se corrigen todos los errores), se
certifica que el incremento está listo para la integración.

05/06/2021
Contenido

05/06/2021
Especificación funcional
(Box Structure Specification)
• El enfoque de modelado en la ingeniería del software de sala limpia
usa un método llamado especificación de estructura de caja.
• Una “caja” encapsula el sistema o algún aspecto del mismo en
algún nivel de detalle.
• A través de un proceso de elaboración o refinamiento por pasos, las
cajas se refinan en una jerarquía donde cada caja tiene
transparencia referencial.
– Es decir: “la información contenida en cada especificación de caja es
suficiente para definir su refinamiento, sin depender de la
implementación de alguna otra caja”.
– Esto permite al analista dividir un sistema jerárquicamente y avanzar de
la representación esencial en la parte superior al detalle específico de
la implementación en el fondo.
• Para ello, se usan tres tipos de cajas:
– Caja negra (black box)
– Caja de estado (state box)
– Caja clara (clear box)

05/06/2021
BB1
BB1.1
BB1.2
BB1.n
BB1.1.1
BB1.1.2
BB1.1.3
SB1.1.1
caja de estado
caja negra
CB1.1.1.1
CB1.1.1.2
CB1.1.1.3
caja clara

05/06/2021
• La figura anterior ilustra el enfoque de refinamiento, usando la
especificación de estructura de cajas.
– Una caja negra (BB1) define las respuestas a un conjunto completo de estímulos.
BB1 puede refinarse en un conjunto de cajas negras, BB1.1 a BB1.n, cada una de las
cuales enfoca una clase de comportamiento.
– El refinamiento continúa hasta que se identifica una clase cohesiva de
comportamiento (por ejemplo, BB1.1.1). Entonces se define una caja de estado
(SB1.1.1) para la caja negra (BB1.1.1). En este caso, SB1.1.1 contiene todos los
datos y servicios requeridos para implementar el comportamiento definido por
BB1.1.1.
– Finalmente, SB1.1.1 se refina en cajas claras (CB1.1.1.n) y se especifican los detalles
del diseño de procedimientos.
• Conforme ocurre cada uno de estos pasos de refinamiento, también se
presenta la verificación de la exactitud.
• Las especificaciones de caja de estado se verifican para asegurar que
cada una se conforma de acuerdo con el comportamiento definido por
la especificación de la caja negra padre. De igual modo, las
especificaciones de caja clara se verifican contra la caja de estado
padre.

05/06/2021
Tipos de cajas
• Caja negra. La caja negra especifica el comportamiento de un
sistema o de una parte de un sistema. El sistema (o su parte)
responde a estímulos específicos (eventos) al aplicar un conjunto
de reglas de transición que mapean el estimulo en una respuesta.
• Caja de estado. La caja de estado encapsula los datos y servicios
(operaciones) de estado en una forma análoga a los objetos. En
esta visión de especificación, se representan las entradas
(estímulos) y salidas (respuestas) a la caja de estado. La caja de
estado también representa la “historia de estímulos” de la caja
negra, es decir, los datos encapsulados en la caja de estado que
deben conservarse entre las transiciones implicadas.
• Caja clara. Las funciones de transición que se implican mediante la
caja de estado se definen en la caja clara. Dicho de manera simple,
una caja clara contiene el diseño de procedimientos para la caja de
estado.

05/06/2021
Tipos de cajas
S R
f: S*→ R
caja negra
caja negra, g
Estado
T
S R
caja de estado
S R
T
Estado
g11 cg1
g12
g13
caja clara

05/06/2021
Contenido

05/06/2021
Diseño de Sala limpia
• La ingeniería del software de cuarto limpio utiliza mucho
la filosofía de programación estructurada. Pero, en este
caso, la programación estructurada se aplica de manera
mucho más rigurosa.
• Las funciones de procesamiento básico (descritas
durante los primeros refinamientos de la especificación)
se refinan usando una expansión en pasos de funciones
matemáticas en estructuras de conectivos lógicos [por
ejemplo, if-then-else] y subfunciones, donde la
expansión se realiza hasta que todas las subfunciones
identificadas puedan enunciarse directamente en el
lenguaje de programación utilizado para la
implementación.

05/06/2021
Diseño de Sala limpia
• El enfoque de programación estructurada puede usarse
de manera efectiva para refinar funciones.
• Pero ¿qué hay del diseño? Aquí entran en juego
algunos conceptos de diseño fundamentales.
– Los datos de programa se encapsulan como un conjunto de
abstracciones que son atendidas por subfunciones.
– Los conceptos de encapsulamiento de datos, ocultamiento de
información y escritura de datos se usan para crear el diseño de
datos.

05/06/2021
Refinamiento del diseño
• Cada especificación de caja clara representa el diseño
de un procedimiento (subfunción) requerido para
lograr una transición de caja de estado.
• Dentro de la caja clara se usan constructos de
programación estructurada y refinamiento por pasos
para representar detalles procedurales.
• Por ejemplo, una función de programa f se refina en
una secuencia de subfunciones g y h. Estas a su vez
se refinan en constructos condicionales (por ejemplo,
if-then-else y do-while).
• Un mayor refinamiento continúa hasta que existe
suficiente detalle procedural para crear el componente
en cuestión.

05/06/2021
• En cada nivel de refinamiento, el equipo de sala
limpia realiza una verificación formal de
exactitud.
• Para lograr esto, a los constructos de
programación estructurada se une un conjunto
de condiciones de exactitud genéricas…

05/06/2021
• Si una función de programa f se refina en una
secuencia de subfunciones g y h, la condición de
exactitud para toda entrada a f es:
– ¿g seguida de h hace f?
• Cuando una función f se refina en una condicional de
la forma (if <c> then g, else h), la condición de
exactitud para toda entrada a f es:
– Siempre que la condición <c> es verdadera, ¿g hace f?; y
siempre que <c> es falsa, ¿h hace f?
• Cuando la función f se refina como un ciclo, las
condiciones de exactitud para toda entrada a f son:
– ¿Está garantizada la finalización?
– Siempre que <c> es verdadera, ¿g seguida por f hace f?; y
siempre que <c> es falsa, ¿saltar el ciclo todavía hace f?

05/06/2021
Verificación del diseño
Para probar que un diseño es correcto, primero
deben identificarse todas las condiciones y luego
probar que cada una toma el valor booleano
adecuado. A éstas se les llama subpruebas.

05/06/2021
• Debe observar que el uso de los constructos de
programación estructurada restringen el numero
de pruebas de exactitud que deben realizarse.
• Una sola condición se verifica para secuencias;
dos condiciones se prueban para if-then-else y
tres condiciones se verifican para ciclo.
• Para ilustrar la verificación de exactitud para un
diseño procedural, la intención es diseñar y
verificar un pequeño programa que encuentre la
parte entera y de una raíz cuadrada de un entero
dado x.

05/06/2021
y :=y +1
(y +1)2 ≤x
sqrt
exit: x no cambia y y2 ≤x ≤(y +1)2
yes: (y +1)2 ≤x
loop: [y2 ≤x] cont: [y2 ≤x]
init: [ x ≥0, y y =0]
entry: [x ≥0]
y := 0
• El diseño procedural se representa usando el diagrama de
flujo de la figura mostrada en esta diapositiva.
• Para verificar la exactitud de este diseño, las condiciones de
entrada y salida se agregan como se muestra en la figura.
• La condición de entrada observa que x debe ser mayor que o
igual a 0.
• La condición de salida requiere que x permanezca invariable
y que y satisfaga la expresión anotada en la figura.
• Para probar que el diseño es
correcto, es necesario probar que
las condiciones init, loop, cont, yes y
exit, que se muestran en la figura,
son verdaderas en todos los casos.
En ocasiones a esto se le conoce
como subpruebas.

05/06/2021
1. La condición init demanda que [x ≥ 0 y y = 0].
– Con base en los requerimientos del problema, la
condición de entrada se supone correcta.
– Por tanto, se satisface la primera parte de la
condición init, x 0.
– En el diagrama de flujo, el enunciado
inmediatamente anterior a la condición init establece
y = 0.
– Por tanto, la segunda parte de la condición init
también se satisface.
– En consecuencia, init es verdadera.

05/06/2021
2. La condición loop puede encontrarse en una de
dos formas:
1. directamente de init (en este caso, la condición loop se
satisface directamente) o
2. por medio del flujo de control que pasa a través de la
condición cont.
– Dado que la condición cont es idéntica a la
condición loop, esta es verdadera sin importar la
trayectoria de flujo que conduce a ella.

05/06/2021
3. La condición cont se encuentra solamente
después de que el valor de y aumenta en 1.
– Además, la ruta de flujo de control que conduce a
cont puede invocarse solo si la condición yes también
es verdadera.
– Por tanto, si (y + 1)2 ≤ x se sigue que y2 ≤ x. Se
satisface la condición cont.

05/06/2021
4. La condición yes se prueba en la lógica
condicional que se muestra. Por ende, la
condición yes debe ser verdadera cuando el
flujo de control se mueve a lo largo de la
trayectoria mostrada.

05/06/2021
5. La condición exit demanda primero que x
permanezca invariable.
– Un examen del diseño indica que x no aparece a la
izquierda de un operador de asignación. No hay
llamadas de función que usen x.
– En consecuencia, es invariable. Puesto que la prueba
condicional (y + 1)2 ≤ x debe fallar para alcanzar la
condición exit, se sigue que (y + 1)2 ≤ x.
– Además, la condición loop debe incluso ser
verdadera (es decir, y2 ≤ x).
– Por tanto, (y + 1)2 > x y y2 ≤ x pueden combinarse
para satisfacer la condición exit.

05/06/2021
• Adicionalmente, debe asegurarse de que el ciclo
termina.
• Un examen de la condición loop indica que, dado que y
se incrementa y x ≥ 0, el ciclo finalmente debe terminar.
• Los cinco pasos recién señalados son una prueba de la
exactitud del diseño del algoritmo del ejemplo. Entonces
se está seguro de que el diseño, de hecho, calculara la
parte entera de una raíz cuadrada.

05/06/2021
Ventajas de la verificación del diseño
• Reduce la verificación a un proceso finito.
• Permite a los equipos de salas limpias
verificar cada línea de diseño y código.
• Da como resultado un nivel de defectos
cercano a cero.
• Permite escalabilidad.
• Produce un código mejor que las pruebas
unitarias.

05/06/2021
Prueba de sala limpia
• La estrategia y tácticas de las pruebas de cuarto
limpio son fundamentalmente diferentes a las de
los enfoques de prueba convencionales.
• Los métodos convencionales derivan un conjunto
de casos de prueba para descubrir errores de
diseño y codificación.
La meta de la prueba de sala limpia es validar los
requerimientos de software al demostrar que una
muestra estadística de casos de uso se ejecuta
exitosamente

05/06/2021
Prueba de sala limpia
• Pruebas de uso estadístico
– examinan la forma en la que los usuarios del software pretenden
usarlo
• Los equipos de prueba de cuarto limpio (también llamados equipos
de certificación) deben determinar una distribución de probabilidad
de uso para el software. Para ello:
– Se analiza la especificación para identificar un conjunto de
estímulos
• los estímulos (entradas o eventos) hacen que el software cambie el
comportamiento
– En la creación de escenarios de uso y en una comprensión
general del dominio de aplicación, a cada estímulo se le asigna
una probabilidad de uso con base en entrevistas con usuarios
potenciales
– Para cada conjunto de estímulos se generan casos de prueba
de acuerdo con la distribución de probabilidad de uso

05/06/2021
Certificación
1. Deben crearse escenarios de uso.
2. Se especifica un perfil de uso.
3. Los casos de prueba se generan a partir del
perfil.
4. Las pruebas se ejecutan y los datos de fallas
se registran y analizan.
5. La confiabilidad se calcula y certifica.

05/06/2021
Modelos de certificación
• Modelo de muestreo. La prueba de software ejecuta
m casos de prueba aleatorios y se certifica si no
ocurren fallos o un numero especifico de ellos. El valor
de m se deriva matemáticamente para asegurar que
se logra la confiabilidad requerida.
• Modelo de componente. Se certifica un sistema
compuesto de n componentes. El modelo de
componentes permite al analista determinar la
probabilidad de que el componente i fallara antes de
su conclusión.
• Modelo de certificación. La confiabilidad global del
sistema se proyecta y se certifica.

05/06/2021
Modelado y
verificación formal
Unidad 3
Final de la unidad
Y del curso…. !Muchas gracias
a todos!

MOD Unidad 3: Modelado y verificación formal

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie MOD Unidad 3: Modelado y verificación formal

Ähnlich wie MOD Unidad 3: Modelado y verificación formal (20)

Mehr von Franklin Parrales Bravo

Mehr von Franklin Parrales Bravo (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

MOD Unidad 3: Modelado y verificación formal