sistema de verificaci n de componentes software n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Sistema de verificación de componentes software PowerPoint Presentation
Download Presentation
Sistema de verificación de componentes software

Loading in 2 Seconds...

play fullscreen
1 / 59

Sistema de verificación de componentes software - PowerPoint PPT Presentation


  • 134 Views
  • Uploaded on

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. El problema Técnicas relacionadas Solución aportada Estudio práctico y resultados Conclusiones y trabajo futuro. Componentes software.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Sistema de verificación de componentes software' - teenie


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
sistema de verificaci n de componentes software

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

componentes software
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

problemas del uso de componentes en la pr ctica i
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

problemas del uso de componentes en la pr ctica ii
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

falta de mecanismos de verificaci n i
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

falta de mecanismos de verificaci n ii
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

falta de mecanismos de verificaci n iii
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

tesis i
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

tesis ii
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

m todo de trabajo
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

t cnicas relacionadas
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

m todos formales
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

an lisis est tico e interpretaci n abstracta
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

especificaci n sem ntica
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

especificaci n de procesos
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

contratos
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

estilos arquitect nicos
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

metodolog as de an lisis y dise 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

Agustín Cernuda del Río

plataformas de componentes
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

resumen de tendencias analizadas
Resumen de tendencias analizadas

Agustín Cernuda del Río

soluci n aportada
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

el modelo de componentes itacio
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

componente i
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

componente ii
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

sistema i
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

sistema ii
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

expresiones restrictivas
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

generaci n de la base de conocimientos i
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

generaci n de la base de conocimientos ii
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

proceso de verificaci n
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

relaci n con los objetivos
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

estudio pr ctico y resultados
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

prototipos desarrollados
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

prototipo itacio seda
Prototipo Itacio-SEDA

Agustín Cernuda del Río

prototipo itacio xj
Prototipo Itacio-XJ

Agustín Cernuda del Río

prototipo itacio xdb
Prototipo Itacio-XDB

Agustín Cernuda del Río

ejemplos microcomponentes i
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

ejemplos microcomponentes ii
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

ejemplos contratos de reutilizaci n i
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

ejemplos contratos de reutilizaci n ii
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

ejemplos contratos de reutilizaci n iii
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

ejemplos diagn stico remoto de equipos ii
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

ejemplos wavex i
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

ejemplos wavex ii
Ejemplos: WaveX - II

Agustín Cernuda del Río

ejemplos wavex iii
Ejemplos: WaveX - III

Agustín Cernuda del Río

ejemplos modelo de hamlet et al
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

ejemplos compatibilidad entre protocolos i
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

ejemplos compatibilidad entre protocolos ii
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

ejemplo compatibilidad entre protocolos iii
Ejemplo: Compatibilidad entre protocolos - III
  • ¿Son compatibles componentes con estos protocolos?

Agustín Cernuda del Río

conclusiones y trabajo futuro
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

conclusiones
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

aportaciones
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

trabajo futuro i
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

trabajo futuro ii
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

fin de la presentaci n
Fin de la presentación

Agustín Cernuda del Río