Sistema de verificación de componentes software Tesis Doctoral Agustín Cernuda del Río...
-
Upload
antonello-del-rosario -
Category
Documents
-
view
1 -
download
0
Transcript of Sistema de verificación de componentes software Tesis Doctoral Agustín Cernuda del Río...
Sistema de verificación de Sistema de verificación de componentes softwarecomponentes software
Tesis DoctoralAgustín Cernuda del Río
Universidad de Oviedo, junio de 2002
18-6-2002 Agustín Cernuda del Río
Programa de la presentación
1. El problema
2. Técnicas relacionadas
3. Solución aportada
4. Estudio práctico y resultados
5. Conclusiones y trabajo futuro
18-6-2002 Agustín Cernuda del Río
Componentes software
Componente software (según Szyperski) Unidad de composición con interfaces
especificadas contractualmente y dependencias contextuales explícitas
Entendido como unidad de despliegue independiente
Frecuentemente... Se piensa en ActiveX, CORBA o similares Se equipara “componente” a “objeto
empaquetado” Beneficios esperados: ahorro de tiempo,
mayor fiabilidad
18-6-2002 Agustín Cernuda del Río
Problemas del uso de componentes en la práctica - I Dados ciertos componentes correctos,
¿será correcto el sistema resultante? Errores derivados de la propia combinación “Comportamiento emergente” Violación de los requisitos de funcionamiento
de algún componente Recursos para verificar la conexión entre
componentes Frecuentemente, sólo verificación de
signaturas En algunos casos, mecanismos de tiempo de
ejecución
18-6-2002 Agustín Cernuda del Río
Problemas del uso de componentes en la práctica - II Verificación de signaturas
Habitualmente, se limita al tipo y número de los parámetros
OK
Especificaciónvoid f(int x, int
y)
f(3, 5);Uso
Especificación“Que x sea siempre
mayor que y”void f(int x, int y)
f(3, 5);Uso
¿OK?
void f(int x, int y){...assert(x <= y);...}
18-6-2002 Agustín Cernuda del Río
Falta de mecanismos de verificación - I Verificación de signaturas
Muy limitada Especificación textual
Sujeta a ambigüedades No hay garantías de que se aplique No se puede automatizar la verificación
Código de salvaguardia Sólo funciona en tiempo de ejecución Puede haber problemas que no se detecten Semántica limitada (ej.: “No utilizar en
sistemas de tiempo real”)
18-6-2002 Agustín Cernuda del Río
Falta de mecanismos de verificación - II
Muchos defectos se podrían prever Conocimiento a priori
Se pueden conocer propiedades indecidibles Habitualmente se pierde
Necesidad de un mecanismo que permita aprovechar el conocimiento a priori
Verificación basada en ese conocimiento
18-6-2002 Agustín Cernuda del Río
Falta de mecanismos de verificación - III Se necesitaría un sistema de verificación:
Que pudiera utilizarse en tiempo de construcción del software (no de ejecución)
Automático (la especificación acompañaría al componente y se tendría en cuenta de forma inmediata)
Susceptible de ser utilizado con facilidad en entornos de producción
Flexible (un método general aplicable a diversos aspectos y ámbitos del desarrollo, con una semántica abierta)
18-6-2002 Agustín Cernuda del Río
Tesis - I
Es posible verificar, de manera estática, automática y asequible que, hasta donde nos es posible asegurar con el conocimiento disponible, al combinar ciertos componentes software no se han violado las condiciones de funcionamiento correcto de ninguno de ellos.
18-6-2002 Agustín Cernuda del Río
Tesis - II
Verificación Estática – sin poner el sistema en
funcionamiento (detección temprana de los defectos, aprovechamiento del conocimiento disponible)
Automática – menor coste, mayor frecuencia, menor ambigüedad
Asequible Técnicas conocidas y viables Comprendido y aplicado con facilidad por el personal
típico General, flexible (retorno de inversión) Esto exige un modelo sencillo
18-6-2002 Agustín Cernuda del Río
Método de trabajo
Proponer un modelo de verificación que cumpla los objetivos marcados
Probar la viabilidad técnica de las herramientas desarrollando prototipos con medios limitados
Probar la aplicabilidad de ese modelo a problemas prácticos diferentes
18-6-2002 Agustín Cernuda del Río
Técnicas relacionadas
1. El problema
2. Técnicas relacionadas
3. Solución aportada
4. Estudio práctico y resultados
5. Conclusiones y trabajo futuro
18-6-2002 Agustín Cernuda del Río
Métodos formales
Especificación formal de la interfaz SDL, Estelle, Lotos / Z, VDM, B...
Especificación Refinamiento Prueba de adecuación
Problemas: Asequibilidad (o percepción sobre ella). Wing, Bowen &
Hinchey, Pressman, Parnas, Meyer, Szyperski... Componentes Conocimiento Automatización y herramientas Flexibilidad
18-6-2002 Agustín Cernuda del Río
Análisis estático e interpretación abstracta Evaluación de código fuente con
algoritmos Semántica menos precisa pero computable Valores abstractos de variables Convergencia Cousot & Cousot, PAG, PolySpace...
Problemas Componentes Asequibilidad Flexibilidad (alg. específicos, código fuente)
18-6-2002 Agustín Cernuda del Río
Especificación semántica
Técnicas para describir formalmente el comportamiento de un lenguaje de programación
Posibilidad de trasladarlas al ámbito de componentes
Problemas Legibilidad Modularidad (hay trabajos prometedores) Falta de madurez e implementaciones
18-6-2002 Agustín Cernuda del Río
Especificación de procesos
CSP (CCS, ACP, otros), -cálculo, L-cálculo, derivados (Piccola, Pict, etc.)
Problemas Orientadas a procesos (CSP y similares) Notaciones formales (asequibilidad) Flexibilidad Bajo nivel Orientados a concurrencia (Pict) Orientados a composición y no tanto a
verificación (Piccola)
18-6-2002 Agustín Cernuda del Río
Contratos
Varios enfoques Unilateral (Meyer) Bilateral (Wirfs-Brock, Reenskaug) Contratos de reutilización (Vrije Universiteit
Brussels) Lenguaje Contract
Problemas Meyer: estado concreto, verificaciones ejecutables Wirfs-Brock, Reenskaug: centrados en
análisis/diseño Contratos de reutilización: poca flexibilidad Lenguaje Contract: no orientado a verificación
18-6-2002 Agustín Cernuda del Río
Estilos arquitectónicos
Incoherencias entre estilos arquitectónicos (Carnegie Mellon)
ADLs (Wright, Aesop, Darwin, Rapide, UniCon...)
Problemas Flexibilidad Automatización Análisis estático (limitado) Asequibilidad (WRIGHT: notaciones basadas en
CSP)
18-6-2002 Agustín Cernuda del Río
Metodologías de análisis y diseño
OCL (Object Constraint Language) Catalysis Problemas
Orientados al modelado, no a la verificación estática
Automatización
18-6-2002 Agustín Cernuda del Río
Plataformas de componentes
OSF/DCE (IDL) COM, CORBA, JavaBeans “Estándares de cableado” (Szyperski) Ya funcionan (éxito comercial) Problemas
Orientados a la composición, no a la verificación
18-6-2002 Agustín Cernuda del Río
Resumen de tendencias analizadas
18-6-2002 Agustín Cernuda del Río
Solución aportada
1. El problema
2. Técnicas relacionadas
3. Solución aportada
4. Estudio práctico y resultados
5. Conclusiones y trabajo futuro
18-6-2002 Agustín Cernuda del Río
El modelo de componentes Itacio Un modelo de componentes que responda
a los requisitos de la tesis Primera consideración: definición abierta
de “componente” Uso del término distinto al habitual Problema de nomenclatura, pero... difícil de
evitar ¿Por qué Itacio?
“Enterré en precioso mármol para la mansión eterna el tierno cuerpo de Itacio”
18-6-2002 Agustín Cernuda del Río
Componente - I
Entidad que consta de una frontera y un conjunto de expresiones restrictivas Frontera: consta de puntos de conexión
Fuentes Sumideros
Expresiones restrictivas Requisitos (para los sumideros) Garantías (sobre las fuentes)
18-6-2002 Agustín Cernuda del Río
Componente - II
Sumidero1 Sumidero2 Sumidero3
Fuente1 Fuente2
Signaturas- Sumidero1(int)- Sumidero2(int, char)- Sumidero3(char)Código
Requisitos- Sumidero1 debe ser menor que Sumidero2 + Sumidero3
Garantías- El valor de Fuente1 siempre estará entre el de Sumidero2 y Sumidero3
Signaturas- Sumidero1(int)- Sumidero2(int, char)- Sumidero3(char)Código
18-6-2002 Agustín Cernuda del Río
Sistema - I
Grafo finito Nodos: componentes Arcos: pares fuente/sumidero
Predicados auxiliares Corrección topológica de un sistema
No hay puntos de conexión aislados No hay arcos repetidos
18-6-2002 Agustín Cernuda del Río
Sistema - II
s1 válido s1 positivo
s1 s2
f1 positivo s1 en [1..5] y s2 positivo
s1 s2
s1 s2
f1
f1 es 5
f1
f1 está en [10..20]
f1
......
?OK¿válido?
18-6-2002 Agustín Cernuda del Río
Expresiones restrictivas
Requisitos y garantías: lógica de primer orden
Cláusula Horn (CLP) Programación lógica
Gran flexibilidad para representar conocimiento
Ampliamente conocida (asequible) Automatizable (procesos de inferencia
definidos) Herramientas disponibles y estables CLP: Gran potencia y eficiencia
18-6-2002 Agustín Cernuda del Río
Generación de la base de conocimientos - I
Recopilar las expresiones restrictivas de los componentes del sistema
Modificarlas de modo que quede implícita la información sobre topología
De este modo, el proceso de inferencia se remonta a los componentes implicados
18-6-2002 Agustín Cernuda del Río
Generación de la base de conocimientos - II
s1 válido s1 positivo
s1 s2
f1 positivo s1 en [1..5] y s2 positivo
f1 f2
s1 s2
f1
f1 es 5
f1
f1 está en [10..20]
f1
......
A B
C
es 5A
está en [10..20]B
C es positivo si
A en [1..5]^
positivoB
C es válido si
C positivo
18-6-2002 Agustín Cernuda del Río
Proceso de verificación
Proceso de inferencia del motor CLP Hipótesis del Mundo Cerrado (CWA)
Enfoque exigente: si no se satisface explícitamente un requisito, se da por supuesto que se viola
El proceso de inferencia puede señalar qué requisito no se cumple y por qué
Con un buen diseño de los predicados, el sistema puede ofrecer explicaciones
El sistema y su diagnóstico pueden representarse gráficamente
18-6-2002 Agustín Cernuda del Río
Relación con los objetivos
Sistema de verificación Como proceso de inferencia en lógica de primer
orden Verificación estática Verificación automática Modelo asequible
Gran simplicidad del modelo (mínimo de conceptos) Simplicidad de la implementación (CLP)
Verificación basada en el conocimiento disponible Aprovechamiento del conocimiento Gran flexibilidad y potencial de aplicación
18-6-2002 Agustín Cernuda del Río
Estudio práctico y resultados
1. El problema
2. Técnicas relacionadas
3. Solución aportada
4. Estudio práctico y resultados
5. Conclusiones y trabajo futuro
18-6-2002 Agustín Cernuda del Río
Prototipos desarrollados
Itacio-SEDA Basado en herramienta gráfica propietaria Motor de inferencia: ECLiPSe
Itacio-XJ Datos: ficheros de texto Representación: Internet Explorer / VML Motor de inferencia: ECLiPSe
Itacio-XDB Datos: base de datos ODBC Representación: Internet Explorer / VML Motor de inferencia: ECLiPSe
18-6-2002 Agustín Cernuda del Río
Prototipo Itacio-SEDA
18-6-2002 Agustín Cernuda del Río
Prototipo Itacio-XJ
18-6-2002 Agustín Cernuda del Río
Prototipo Itacio-XDB
18-6-2002 Agustín Cernuda del Río
Ejemplos: microcomponentes - I Representar elementos básicos de un lenguaje
(operadores, funciones, etc.) Rudimentario sistema de generación de código
Dividir
op1 op2
Leer valor
res
Leer valor
res
res
Imprimir valor
val
Dividir
op1 op2
Leer valor
res
Leer valor
res
res
Imprimir valor
val
#include <stdio.h>void main(void){double val1;scanf(“%lf”, &val1);double val2;scanf(“%lf”, &val2);double res=val1/val2;printf(“%lf”, res);}
Denominador puede ser 0
Denominador puede ser 0
18-6-2002 Agustín Cernuda del Río
Ejemplos: microcomponentes - II
Dificultades: generación de código (no era objeto de la tesis)
Dividir
op1 op2
Leer valor
res
Leer valor
res
res
Imprimir valor
val
valido(op2):- not igual_que(op2, 0).......
18-6-2002 Agustín Cernuda del Río
Según Carine Lucas Contrato de reutilización: conjunto de participantes con
nombre, cláusula de relación e interfaz. Cláusula de relación: indicación de que un participante
“conoce a” otro. Interfaz: conjunto de descripciones de operaciones (nombre y
operaciones invocadas por esta). Verificaciones de consistencia (no invocar
operaciones inexistentes, no eliminar operaciones en uso...)
Modificaciones a contratos Modeladas como operadores (8 combinaciones) Lucas propone reglas para operadores aplicables Si se modela un sistema como contratos, con este modelo
se puede verificar la evolución (usando las reglas establecidas)
Ejemplos: Contratos de reutilización - I
18-6-2002 Agustín Cernuda del Río
Modelando contratos en Itacio El contrato es un componente Cada modificación es otro componente La conexión entre contratos y sucesivas
modificaciones modela la evolución del sistema
Los requisitos y garantías permiten validar las operaciones realizadas
Ejemplos: Contratos de reutilización - II
18-6-2002 Agustín Cernuda del Río
Type=smplDriveSources=resBEGIN_RESTRICTIONSisContract($res$).participant($res$, smplDriver).participant($res$, smplCar).acqRelationship($res$, smplDriver, myCar, smplCar).operation($res$, smplDriver, go).operation($res$, smplDriver, stop)....operationInvocation($res$, smplDriver, go, myCar, startEngine).operationInvocation($res$, smplDriver, go, myCar,
pushGasPedal)....END_RESTRICTIONS
Ejemplos: Contratos de reutilización - III
18-6-2002 Agustín Cernuda del Río
Ejemplos: Contratos de reutilización - IV
18-6-2002 Agustín Cernuda del Río
Ejemplos: Diagnóstico remoto de equipos - I
18-6-2002 Agustín Cernuda del Río
Ejemplos: Diagnóstico remoto de equipos - II
Las expresiones restrictivas realizan comprobaciones reales en el equipo cliente (enlazando CLP con DLLs)
18-6-2002 Agustín Cernuda del Río
Ejemplos: WaveX - I
Sistema de procesamiento de sonido en tiempo real Basado en componentes (efectos, transformaciones) Combinaciones no válidas (imposible verificación
meramente local) Necesidad de sistema de ayuda al usuario
18-6-2002 Agustín Cernuda del Río
Ejemplos: WaveX - II
18-6-2002 Agustín Cernuda del Río
Ejemplos: WaveX - III
18-6-2002 Agustín Cernuda del Río
Ejemplos: Modelo de Hamlet et al Un modelo de fiabilidad para componentes
software Cada componente tiene asociada una hoja
de transformación que indica cómo transforma los dominios de entrada en los de salida
Cada componente tiene también una tasa de fallos asociada a cada combinación de subdominios
Expresando esta información como expresiones restrictivas, se puede reflejar este modelo en Itacio
18-6-2002 Agustín Cernuda del Río
Ejemplos: Compatibilidad entre protocolos - I Verificaciones temporales (ordenación de
llamadas) Los contratos de reutilización no lo reflejan Modelo de Yellin y Strom
Especificar protocolos indicando las transiciones posibles (es decir, el orden de invocación admitido en cada componente para sus operaciones)
Algoritmo para verificar la compatibilidad de los protocolos de dos componentes
¿Susceptible de ser modelado en Itacio?
18-6-2002 Agustín Cernuda del Río
Ejemplos: Compatibilidad entre protocolos - II
ys_collaboration($file$).ys_states($file$, initFile, [], [createdFileObj,
openingFile, openFile,readingFile, endOfFile, notReadingFile]).
ys_sent_message($file$, openFileError).ys_sent_message($file$, openFileOk)....ys_received_message($file$,
fileConstructor).ys_received_message($file$, fileDestructor)....ys_transition($file$, initFile, +,
fileConstructor, createdFileObj).ys_transition($file$, createdFileObj, +,
fileDestructor, initFile)....
18-6-2002 Agustín Cernuda del Río
Ejemplo: Compatibilidad entre protocolos - III ¿Son compatibles componentes con estos
protocolos?
18-6-2002 Agustín Cernuda del Río
Ejemplo: Compatibilidad entre protocolos - IV
18-6-2002 Agustín Cernuda del Río
Conclusiones y trabajo futuro
1. El problema
2. Técnicas relacionadas
3. Solución aportada
4. Estudio práctico y resultados
5. Conclusiones y trabajo futuro
18-6-2002 Agustín Cernuda del Río
Conclusiones
Basándose en: Interpretación de los resultados obtenidos Análisis del estado del arte Escrutinio público
Se concluye que: Es posible verificar, de manera estática, automática y
asequible que, hasta donde nos es posible asegurar con el conocimiento disponible, al combinar ciertos componentes software no se han violado las condiciones de funcionamiento correcto de ninguno de ellos.
18-6-2002 Agustín Cernuda del Río
Aportaciones
Tecnología de componentes software Estudio específico de alternativas Definición abierta de componente
Gestión del conocimiento aplicada Modelo de componente que permite incorporar
conocimiento Esquema de generación de la BC para inferencias
Ingeniería del software Método de modelado de componentes para verificación y
con las restricciones descritas (gran flexibilidad y generalidad)
Ejemplos de aplicación de modelo de componentes a campos diversos
Sistema de verificación plenamente viable en la práctica Diversos prototipos
18-6-2002 Agustín Cernuda del Río
Trabajo futuro - I
Mejoras Gestión del conocimiento Corrección de las especificaciones Razonamiento aproximado / probabilístico Relajación del criterio de corrección topológica
Relación con la Ingeniería del Software Herramientas de producción (no prototipos) Integración con procesos de desarrollo Nuevos campos de aplicación del modelo Ingeniería inversa para búsqueda de defectos Búsqueda de componentes Anticipación y ayuda al diseño Relación entre expresiones restrictivas y código fuente
18-6-2002 Agustín Cernuda del Río
Trabajo futuro - II
Relación con técnicas formales Especificación de la semántica del modelo mediante
semántica monádica reutilizable Modelado de los componentes mediante semántica
modular Creación de lenguaje independiente y extensible de
propósito específico Adaptación de una técnica de especificación semántica
al trabajo con componentes
18-6-2002 Agustín Cernuda del Río
Fin de la presentación