Sistema de verificaci

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

1. El problema
2. Técnicas relacionadas
3. Solución aportada
4. Estudio práctico y resultados
5. Conclusiones y trabajo futuro

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

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

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 lt
y) ...
Especificación void f(int x, int y)
OK
OK?

• f(3, 5)
• Uso

• f(3, 5)
• Uso

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)

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

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)

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

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

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

12
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

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

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)

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

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)

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

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)

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

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

21
Resumen de tendencias analizadas
22
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

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

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)

25
Componente - II

Sumidero1
Sumidero2
Sumidero3
Fuente1
Fuente2
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

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

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

30
Generación de la base de conocimientos - II
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
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

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

33
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

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

35
Prototipo Itacio-SEDA
36
Prototipo Itacio-XJ
37
Prototipo Itacio-XDB
38
Ejemplos microcomponentes - I

• Representar elementos básicos de un lenguaje
  (operadores, funciones, etc.)
• Rudimentario sistema de generación de código

39
Ejemplos microcomponentes - II

• Dificultades generación de código (no era objeto
  de la tesis)

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)

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

42
Ejemplos Contratos de reutilización - III

• TypesmplDrive
• Sourcesres
• 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

43
Ejemplos Contratos de reutilización - IV
44
Ejemplos Diagnóstico remoto de equipos - I
45
Ejemplos Diagnóstico remoto de equipos - II

• Las expresiones restrictivas realizan
  comprobaciones reales en el equipo cliente
  (enlazando CLP con DLLs)

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

47
Ejemplos WaveX - II
48
Ejemplos WaveX - III
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

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?

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).
• ...

52
Ejemplo Compatibilidad entre protocolos - III

• Son compatibles componentes con estos protocolos?

53
Ejemplo Compatibilidad entre protocolos - IV
54
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

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

56
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

57
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

58
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

59
Fin de la presentación