Sistema de verificación de componentes software

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. 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” voidf(int x, int y) voidf(int x, int y) { ... assert(x <= y); ... } Especificación voidf(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. Tesis - I • Es posible verificar, de manera estática, automática y asequible que, hasta donde nos esposible asegurar con el conocimiento disponible, al combinar ciertos componentes software no sehan violado las condiciones de funcionamiento correcto de ninguno de ellos. Agustín Cernuda del Río

10. 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. 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. 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. 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. 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. 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. Componente - II 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 Sumidero1 Sumidero2 Sumidero3 Fuente1 Fuente2 Agustín Cernuda del Río

26. 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. 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 A es 5 B está en [10..20] C es positivo si A en [1..5]^ B positivo C es válido si C positivo f1 es 5 f1 está en [10..20] f1 f1 A B s1 s2 f1 positivo  s1 en [1..5] y s2 positivo f1 ...... C s1 s2 s1 válido  s1 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 • Motor de inferencia: ECLiPSe • Itacio-XDB • Datos: base de datos ODBC • Representación: Internet Explorer / VML • Motor de inferencia: ECLiPSe Agustín Cernuda del Río

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

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

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

38. Ejemplos: microcomponentes - I Denominador puede ser 0 Leer valor Leer valor Leer valor Leer valor #include <stdio.h> void main(void) { double val1; scanf(“%lf”, &val1); double val2; scanf(“%lf”, &val2); double res=val1/val2; printf(“%lf”, res); } res res res res op1 op2 op1 op2 Dividir Dividir val res res Imprimir valor val Imprimir valor • Representar elementos básicos de un lenguaje (operadores, funciones, etc.) • Rudimentario sistema de generación de código Agustín Cernuda del Río

39. Ejemplos: microcomponentes - II Leer valor Leer valor valido(op2):- not igual_que(op2, 0). ... ... res res op1 op2 Dividir val res Imprimir valor • 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. 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. Ejemplos: WaveX - II Agustín Cernuda del Río

48. 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