Sistema de verificacin de componentes software Tesis Doctoral
- Slides: 59
Sistema de verificación de componentes software Tesis Doctoral Agustín Cernuda del Río Universidad de Oviedo, junio de 2002
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 n Componente software (según Szyperski) n n n Frecuentemente. . . n n n Unidad de composición con interfaces especificadas contractualmente y dependencias contextuales explícitas Entendido como unidad de despliegue independiente Se piensa en Active. X, 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 n Dados ciertos componentes correctos, ¿será correcto el sistema resultante? n n 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 n n 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 n Verificación de signaturas n Habitualmente, se limita al tipo y número de los parámetros void Especificación f(int x, int y) void{ f(int x, int y). . . assert(x <= y); OK. . . } f(3, 5); Especificación “Que x sea siempre mayor que y” void f(int x, int y) Uso 18 -6 -2002 Agustín Cernuda del Río ¿OK? f(3, 5); Uso
Falta de mecanismos de verificación - I n Verificación de signaturas n n Especificación textual n n Muy limitada Sujeta a ambigüedades No hay garantías de que se aplique No se puede automatizar la verificación Código de salvaguardia n n n 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 n n Muchos defectos se podrían prever Conocimiento a priori n n 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 n Se necesitaría un sistema de verificación: n 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 n 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 n Verificación 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 n n 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 n n n 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 n n Especificación formal de la interfaz SDL, Estelle, Lotos / Z, VDM, B. . . n n Especificación Refinamiento Prueba de adecuación Problemas: n Asequibilidad (o percepción sobre ella). Pressman, Parnas, Meyer, Szyperski. . . n n Componentes Conocimiento Automatización y herramientas Flexibilidad 18 -6 -2002 Agustín Cernuda del Río Wing, Bowen & Hinchey,
Análisis estático e interpretación abstracta n Evaluación de código fuente con algoritmos n n n Semántica menos precisa pero computable Valores abstractos de variables Convergencia Cousot & Cousot, PAG, Poly. Space. . . Problemas n n n Componentes Asequibilidad Flexibilidad (alg. específicos, código fuente) 18 -6 -2002 Agustín Cernuda del Río
Especificación semántica n n n Técnicas para describir formalmente el comportamiento de un lenguaje de programación Posibilidad de trasladarlas al ámbito de componentes Problemas n n n Legibilidad Modularidad (hay trabajos prometedores) Falta de madurez e implementaciones 18 -6 -2002 Agustín Cernuda del Río
Especificación de procesos n n CSP (CCS, ACP, otros), -cálculo, derivados (Piccola, Pict, etc. ) Problemas n n n L-cálculo, 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 n Varios enfoques n n n Unilateral (Meyer) Bilateral (Wirfs-Brock, Reenskaug) Contratos de reutilización (Vrije Universiteit Brussels) Lenguaje Contract Problemas n n 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 n n n Incoherencias entre estilos arquitectónicos (Carnegie Mellon) ADLs (Wright, Aesop, Darwin, Rapide, Uni. Con. . . ) Problemas n n 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 n n n OCL (Object Constraint Language) Catalysis Problemas n n Orientados al modelado, no a la verificación estática Automatización 18 -6 -2002 Agustín Cernuda del Río
Plataformas de componentes n n n OSF/DCE (IDL) COM, CORBA, Java. Beans “Estándares de cableado” (Szyperski) Ya funcionan (éxito comercial) Problemas n 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 n n Un modelo de componentes que responda a los requisitos de la tesis Primera consideración: definición abierta de “componente” n n n Uso del término distinto al habitual Problema de nomenclatura, pero. . . difícil de evitar ¿Por qué Itacio? n “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 n Entidad que consta de una frontera y un conjunto de expresiones restrictivas n n Frontera: consta de puntos de conexión n Fuentes n Sumideros Expresiones restrictivas n Requisitos (para los sumideros) n Garantías (sobre las fuentes) 18 -6 -2002 Agustín Cernuda del Río
Componente - II Sumidero 1 n Sumidero 2 Signaturas Requisitos - Sumidero 1(int) - Sumidero 2(int, char) - Sumidero 1 debe ser menor que - Sumidero 3(char) Sumidero 2 + Sumidero 3 Código Garantías Sumidero 3 Signaturas - Sumidero 1(int) - Sumidero 2(int, char) - Sumidero 3(char) Código - El valor de Fuente 1 siempre estará entre el de Sumidero 2 y Sumidero 3 Fuente 1 18 -6 -2002 Fuente 2 Agustín Cernuda del Río
Sistema - I n Grafo finito n n Nodos: componentes Arcos: pares fuente/sumidero Predicados auxiliares Corrección topológica de un sistema n n No hay puntos de conexión aislados No hay arcos repetidos 18 -6 -2002 Agustín Cernuda del Río
Sistema - II f 1 es 5 f 1 está en [10. . 20] f 1 s 1 s 2 f 1 positivo s 1 en [1. . 5] y s 2 positivo f 1 s 1 . . . OK ? s 2 s 1¿válido? válido s 1 positivo s 1 18 -6 -2002 s 2 Agustín Cernuda del Río
Expresiones restrictivas n n n Requisitos y garantías: lógica de primer orden Cláusula Horn (CLP) Programación lógica n n n 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 n n n Recopilar las expresiones restrictivas de los componentes del sistema Modificarlas de modo 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 f 1 es 5 f 1 está en [10. . 20] f 1 A B está en [10. . 20] B s 1 A es 5 s 2 C es positivo si A en [1. . 5]^ f 1 positivo s 1 en [1. . 5] y s 2 positivo f 1 . . . C s 1 s 2 s 1 válido s 1 positivo f 1 18 -6 -2002 B positivo f 2 Agustín Cernuda del Río C es válido si C positivo
Proceso de verificación n n Proceso de inferencia del motor CLP Hipótesis del Mundo Cerrado (CWA) n n 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 n Sistema de verificación n n Verificación estática Verificación automática Modelo asequible n n n Como proceso de inferencia en lógica de primer orden Gran simplicidad del modelo (mínimo de conceptos) Simplicidad de la implementación (CLP) Verificación basada en el conocimiento disponible n n 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 n Itacio-SEDA n n n Itacio-XJ n n Basado en herramienta gráfica propietaria Motor de inferencia: ECLi. PSe Datos: ficheros de texto Representación: Internet Explorer / VML Motor de inferencia: ECLi. PSe Itacio-XDB n n n Datos: base de datos ODBC Representación: Internet Explorer / VML Motor de inferencia: ECLi. PSe 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 n n Representar elementos básicos de un lenguaje (operadores, funciones, etc. ) Rudimentario sistema de generación de código Leer valor res op 1 op 2 Dividir res val Imprimir valor 18 -6 -2002 Den omi nad or pue de ser 0 #include <stdio. h> void main(void) { double val 1; scanf(“%lf”, &val 1); double val 2; scanf(“%lf”, &val 2); double res=val 1/val 2; printf(“%lf”, res); } Agustín Cernuda del Río
Ejemplos: microcomponentes - II Leer valor res op 1 op 2 Dividir valido(op 2): not igual_que(op 2, 0). . . . res val Imprimir valor n Dificultades: generación de código (no era objeto de la tesis) 18 -6 -2002 Agustín Cernuda del Río
Ejemplos: Contratos de reutilización - I n Según Carine Lucas n n n 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 n n n 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) 18 -6 -2002 Agustín Cernuda del Río
Ejemplos: Contratos de reutilización - II n Modelando contratos en Itacio n n 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 18 -6 -2002 Agustín Cernuda del Río
Ejemplos: Contratos de reutilización - III Type=smpl. Drive Sources=res BEGIN_RESTRICTIONS is. Contract($res$). participant($res$, smpl. Driver). participant($res$, smpl. Car). acq. Relationship($res$, smpl. Driver, my. Car, smpl. Car). operation($res$, smpl. Driver, go). operation($res$, smpl. Driver, stop). . operation. Invocation($res$, smpl. Driver, go, my. Car, start. Engine). operation. Invocation($res$, smpl. Driver, go, my. Car, push. Gas. Pedal). . END_RESTRICTIONS 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 n Las expresiones restrictivas realizan comprobaciones reales en el equipo cliente (enlazando CLP con DLLs) 18 -6 -2002 Agustín Cernuda del Río
Ejemplos: Wave. X - I n n 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: Wave. X - II 18 -6 -2002 Agustín Cernuda del Río
s: Wave. X - III 18 -6 -2002 Agustín Cernuda del Río
Ejemplos: Modelo de Hamlet et al n n 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 n n n Verificaciones temporales (ordenación de llamadas) Los contratos de reutilización no lo reflejan Modelo de Yellin y Strom n n n 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$, init. File, [], [created. File. Obj, opening. File, open. File, reading. File, end. Of. File, not. Reading. File]). ys_sent_message($file$, open. File. Error). ys_sent_message($file$, open. File. Ok). . ys_received_message($file$, file. Constructor). ys_received_message($file$, file. Destructor). . ys_transition($file$, init. File, +, file. Constructor, created. File. Obj). ys_transition($file$, created. File. Obj, +, file. Destructor, init. File). . 18 -6 -2002 Agustín Cernuda del Río
Ejemplo: Compatibilidad entre protocolos - III n ¿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 n Basándose en: n n Interpretación de los resultados obtenidos Análisis del estado del arte Escrutinio público Se concluye que: n 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 n Tecnología de componentes software n n n Gestión del conocimiento aplicada n n n Estudio específico de alternativas Definición abierta de componente Modelo de componente que permite incorporar conocimiento Esquema de generación de la BC para inferencias Ingeniería del software n n 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 n Mejoras n n n 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 n n n n 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 n Relación con técnicas formales n n 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 18 -6 -2002 Agustín Cernuda del Río
- Power point tesis doctoral medicina
- Componentes componentes
- Partes de la boca interna
- Componentes de los nucleótidos
- Amminoacidos
- Eui doctoral programme
- All but dissertation (abd) status
- Nsf dissertation improvement grant
- Umbc doctoral programs
- Doctoral initiative on minority attrition and completion
- College doctoral ubfc
- South west doctoral training partnership
- Nsf ddrig sociology
- Csu doctoral incentive program
- Componentes do sistema solar
- Componentes celulares del sistema nervioso
- Componentes de sistema solar
- Componentes de un sistema cromatográfico
- Componentes de la gestion ambiental
- Componentes del sistema locomotor
- Componentes de um sistema de remuneração funcional
- Cuáles son los componentes del sistema solar
- Componentes del software de una computadora
- Que es un argumento ejemplo
- Tesis solar flares
- Preguntas de investigación tesis
- Qué es la tesis
- Contoh tesis antitesis sintesis
- Hipotesis tesis antitesis sintesis
- Sa bahaging ito kadalasang nakapaloob ang mga argumento
- Como organizar una tesis
- Tesis de un texto
- Tipos de argumentos causa efecto
- Referencias electrónicas
- Tesis uth
- Estructura del texto argumentativo
- Tesis encuadrada ejemplos
- Rector tdea
- Funcion textos argumentativos
- Contoh tema, topik, dan judul tentang lingkungan
- Lumbalgia tesis
- Tesis ternarista
- Contoh topik tujuan dan tesis
- Ad hominem
- Componentes del discurso argumentativo
- Tesis bases garantias y respaldos ejemplos
- Tesis universidad nacional abierta
- Tesis transcriptivas
- Pendapat dalam eksposisi
- Smpweb upm
- Karar ağacı örnekleri
- El ensayo argumentativo es
- Hipótesis ejemplos
- Que es la tesis
- Rasgos texto argumentativo
- Tesis de grado universidad de guayaquil
- Paninsay
- Predefensa de tesis
- Ejemplos de delimitación de la investigación
- Apa itu tesis