Sistema de verificación de componentes software

Presentación del tema: "Sistema de verificación de componentes software"— Transcripción de la presentación:

1 Sistema de verificación de componentes software
Tesis Doctoral Agustín Cernuda del Río Universidad de Oviedo, junio de 2002

2 Programa de la presentación
El problema Técnicas relacionadas Solución aportada Estudio práctico y resultados Conclusiones y trabajo futuro Agustín Cernuda del Río

3 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 Agustín Cernuda del Río

4 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 Agustín Cernuda del Río

5 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 Especificación “Que x sea siempre mayor que y” void f(int x, int y) void f(int x, int y) { ... assert(x <= y); } Especificación void f(int x, int y) OK ¿OK? f(3, 5); Uso f(3, 5); Uso Agustín Cernuda del Río

6 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”) Agustín Cernuda del Río

7 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 Agustín Cernuda del Río

8 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) Agustín Cernuda del Río

9 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. Agustín Cernuda del Río

10 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 Agustín Cernuda del Río

11 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 Agustín Cernuda del Río

12 Técnicas relacionadas
El problema Técnicas relacionadas Solución aportada Estudio práctico y resultados Conclusiones y trabajo futuro Agustín Cernuda del Río

13 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 Agustín Cernuda del Río

14 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) Agustín Cernuda del Río

15 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 Agustín Cernuda del Río

16 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) Agustín Cernuda del Río

17 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 Agustín Cernuda del Río

18 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) Agustín Cernuda del Río

19 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 Agustín Cernuda del Río

20 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 Agustín Cernuda del Río

21 Resumen de tendencias analizadas
Agustín Cernuda del Río

22 Agustín Cernuda del Río
Solución aportada El problema Técnicas relacionadas Solución aportada Estudio práctico y resultados Conclusiones y trabajo futuro Agustín Cernuda del Río

23 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” Agustín Cernuda del Río

24 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) Agustín Cernuda del Río

25 Agustín Cernuda del Río
Componente - II Sumidero1 Sumidero2 Sumidero3 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 Signaturas - Sumidero1(int) - Sumidero2(int, char) - Sumidero3(char) Código Fuente1 Fuente2 Agustín Cernuda del Río

26 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 Agustín Cernuda del Río

27 Agustín Cernuda del Río
Sistema - II f1 es 5 f1 está en [10..20] f1 f1 s1 s2 f1 positivo  s1 en [1..5] y s2 positivo f1 ...... OK ? s1 s2 s1 válido  s1 positivo ¿válido? s1 s2 Agustín Cernuda del Río

28 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 Agustín Cernuda del Río

29 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 Agustín Cernuda del Río

30 Generación de la base de conocimientos - II
es 5 A está en [10..20] B f1 es 5 f1 está en [10..20] f1 f1 A B s1 s2 C es positivo si A en [1..5]^ positivo B f1 positivo  s1 en [1..5] y s2 positivo f1 ...... C s1 s2 s1 válido  s1 positivo C es válido si positivo f1 f2 Agustín Cernuda del Río

31 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 Agustín Cernuda del Río

32 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 Agustín Cernuda del Río

33 Estudio práctico y resultados
El problema Técnicas relacionadas Solución aportada Estudio práctico y resultados Conclusiones y trabajo futuro Agustín Cernuda del Río

34 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 Itacio-XDB Datos: base de datos ODBC Agustín Cernuda del Río

35 Prototipo Itacio-SEDA
Agustín Cernuda del Río

36 Agustín Cernuda del Río
Prototipo Itacio-XJ Agustín Cernuda del Río

37 Agustín Cernuda del Río
Prototipo Itacio-XDB Agustín Cernuda del Río

38 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 Imprimir valor val Dividir op1 op2 Leer valor 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 Agustín Cernuda del Río

39 Ejemplos: microcomponentes - II
Dividir op1 op2 Leer valor res Imprimir valor val valido(op2):- not igual_que(op2, 0). ... Dificultades: generación de código (no era objeto de la tesis) Agustín Cernuda del Río

40 Ejemplos: Contratos de reutilización - I
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) Agustín Cernuda del Río

41 Ejemplos: Contratos de reutilización - II
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 Agustín Cernuda del Río

42 Ejemplos: Contratos de reutilización - III
Type=smplDrive Sources=res BEGIN_RESTRICTIONS isContract($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 Agustín Cernuda del Río

43 Ejemplos: Contratos de reutilización - IV
Agustín Cernuda del Río

44 Ejemplos: Diagnóstico remoto de equipos - I
Agustín Cernuda del Río

45 Ejemplos: Diagnóstico remoto de equipos - II
Las expresiones restrictivas realizan comprobaciones reales en el equipo cliente (enlazando CLP con DLLs) Agustín Cernuda del Río

46 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 Agustín Cernuda del Río

47 Agustín Cernuda del Río
Ejemplos: WaveX - II Agustín Cernuda del Río

48 Agustín Cernuda del Río
Ejemplos: WaveX - III Agustín Cernuda del Río

49 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 Agustín Cernuda del Río

50 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? Agustín Cernuda del Río

51 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). Agustín Cernuda del Río

52 Ejemplo: Compatibilidad entre protocolos - III
¿Son compatibles componentes con estos protocolos? Agustín Cernuda del Río

53 Ejemplo: Compatibilidad entre protocolos - IV
Agustín Cernuda del Río

54 Conclusiones y trabajo futuro
El problema Técnicas relacionadas Solución aportada Estudio práctico y resultados Conclusiones y trabajo futuro Agustín Cernuda del Río

55 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. Agustín Cernuda del Río

56 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 Agustín Cernuda del Río

57 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 Agustín Cernuda del Río

58 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 Agustín Cernuda del Río

59 Agustín Cernuda del Río
Fin de la presentación Agustín Cernuda del Río