Sistema de

Verificación de
Componentes Software
{Moisés Aguirre Carmona}
[Descripción del problema]
 [Puntos importantes]



 Software en todas partes





 Software de Calidad
Peeeero…






 ¡Concentrémonos en los defectos!
 Errores del funcionamiento del producto
final.
 [Tipos de errores]
 Los más problemáticos no identificados al
inicio.
 gravedad




 tiempo

 Recogida de requisitos, de gestión y

estimación, de análisis, de diseño, errores
por modificaciones de requerimientos
funcionales durante el desarrollo…

Peeeero…





 ¡Concentrémonos en los errores de
software!

 Defectos de fabricación.
 Comportamientos no deseados.
 Muy difíciles de detectar.

…de la Teoría del Caos

 “Con variaciones pequeñas de las variables
de entrada pueden producirse enormes
variaciones en los resultados finales…”
Y aún peor…
 Altamente improbable que un sistema de
software no esté afectado por errores…
algunos incluso desconocidos hasta que se
manifiestan.
 [Algunas técnicas]
 Paliativas, pues:
◦
◦ Pruebas exhaustivas:
 Técnicamente imposible.
En el mejor de los casos, económicamente
inviable.


 Medidas:
◦ Fase de pruebas con técnica de “cobertura”,
revisar tendencias de ritmo de aparición de
defectos.
Peeeero…

 Medidas no garantizan la inexistencia de
errores ocultos:


 “Las pruebas pueden demostrar la presencia
de defectos, nunca su ausencia”
¿Entonces?

 No se le ve solución en un futuro (al menos
no cercano) a nuestro problema.


 Restricciones económicas y prácticas.


 ¿Pero entonces?
 Debemos empezar desde ¡YA! a distribuir
mejor los recursos…


y corrección de defectos de programación

Detecciónyde
construcción.
errores de diseño, captura de requisitos, ges
La Quimera
 El Monstruo del Software correcto por
construcción.




¡Imposible!
 Peeero…
 Existen técnicas que pueden eliminar parte
de los defectos de construcción hasta
cierto grado...
Técnicas VS. Costes de
Aplicación
 Tendencia como solución:


◦ ¡Software Basado en Componentes! 

◦


 e construe a través de
composición de bloques
“estancos” bien probados 
que resuelven problemas
típicos


 Fiabilidad osto de
desarrollo



Sin embargo…
 Sigue habiendo problemas:

 Estudios serios sobre defectos inesperados
al combinar componentes.
Se dice que…
 Ingenieros de Software envidian recursos de
los ingenieros de otras disciplinas.

 Ingenieros eléctricos.
Informáticos celosos
 Los componentes físicos son continuos y
obedecen a leyes físicas ya conocidas,
cuentan con documentación, están
verificados y funcionan muy bien.

 Los componentes de sistemas de software
son discretos, más inestables y difíciles de
modelar. Su comportamiento responde a
un propósito muy variable y difícil de
caracterizar.
 Es posible utilizar la verificación de los
conglomerados de componentes para
conseguir una detección temprana de
defectos.
◦ Especificaciones de cada componente
◦ Descripción explícita de:
 requisitos que plantean para sus entradas
garantías que ofrecen sobre sus salidas
◦ Su interior se considera una “caja negra” y
sólo se necesita información referente a sus
conexiones con el mundo exterior.
 Comprobación de manera estática, (sin
necesidad de poner el sistema en
ejecución).
 El modelo de verificación debe ser capaz de
poner en relación las especificaciones de
los componentes incluso de manera
indirecta o transitiva.

C
 [Las principales técnicas]
 Métodos formales, aspectos:
◦ Un sistema formal. Notación formal, precisa, que
describe el comportamiento de un sistema y
permite demostrar ciertas propiedades.
◦ Una técnica de desarrollo. Basada en el concepto
de refinamiento: las descripciones formales se
van transformando de acuerdo a ciertas reglas,
hasta llegar a una descripción lo bastante
detallada y cercana a la implementación.
◦ Una técnica de verificación. “Obligación de
prueba” consiste en comprobar que la
especificación refinada del sistema presenta el
mismo comportamiento que la especificación
original.
  David Parnas:

ue proponen la mayoría de los investigadores en métodos formales es prolija y dif

[Análisis estático e
interpretación abstracta]
 Buena parte de las aplicaciones prácticas de
análisis estático están encaminadas a la
optimización de código en compiladores, y
no a la detección temprana de defectos en
programas.
 Los métodos de interpretación abstracta son
globales en el sentido de que necesitan
evaluar el código fuente completo del
programa.
[Especificación de
procesos]
 Entidades fuertemente encapsuladas que se
comunican con el exterior a través de sus
canales de comunicación, y además dichas
entidades pueden a su vez estar
constituidas por más entidades análogas,
de nivel inferior, con conexiones privadas.
[CSP y otras álgebras de
procesos]
 CSP: una notación formal para describir los
procesos y su interacción.
 Se ha planteado la idea de que cualquier
computación pueda modelarse como un
proceso (CSP sería un modelo generalista,
al menos en un plano teórico).
 El propósito principal de CSP es abordar
sobre todo problemas en los que esté
presente la concurrencia y el paralelismo.
[Constraint Satisfaction
Problem]
 Notación formal, con las dificultades de
adopción que esto suele conllevar en
muchas organizaciones de desarrollo.
 Son construcciones rigurosas y formales, lo
que da pie a su automatización, y de
hecho sí se pueden realizar ciertos tipos de
verificaciones estáticas en los sistemas,
pero no tan flexibles y adaptables como se
plantea como requisito.
[π-cálculo y πL-cálculo]
 Cálculos de procesos móviles, derivados del
álgebra de procesos CCS (Calculus of
Communicating Systems).
 Nacieron como una herramienta conceptual
para razonar sobre concurrencia y paralelismo
 Pretenden ser un fundamento teórico para
lenguajes de programación concurrente
 No son apropiados para modelar de manera
directa sistemas basados en componentes
 Insuficientemente flexibles para los problemas
de desarrollo que pretendemos resolver.
[π-cálculo y πL-cálculo]
 En muchos casos, los sistemas basados en
componentes no implican concurrencia, y la
identificación entre el concepto de proceso y
el de componente puede resultar poco natural.
 Artefactos de muy bajo nivel de cara a su uso
práctico, lo que en cualquier caso exige algún
tipo de desarrollo adicional.
 La sólida base teórica que estos modelos
ofrecen puede servir como un apoyo
prometedor de cara a desarrollar modelos de
componentes.
[Lenguajes derivados]
 Su viabilidad práctica es mucho mayor; de
hecho, estos lenguajes tienen
implementaciones, más o menos
experimentales, que demuestran que se
hallan mucho más cerca de la etapa de
producción que las teorías que les sirven de
base.
 Adoptan la forma de lenguajes de
programación; aunque sean lenguajes con
ciertas peculiaridades su comprensión y uso
no parece fuera del alcance de los
desarrolladores de software típicos.
[Lenguajes derivados]
 Piccola u otros lenguajes de composición se
han diseñado explícitamente para abordar
el desarrollo de sistemas basados en
componentes, aunque su origen teórico se
halle en el πL-cálculo.
 Se centran más bien en la composición, en
la construcción del software, y no tanto
en la verificación de los requisitos de los
diversos componentes.
[Lenguajes derivados]
 Lenguajes de composición adoptan un
enfoque funcional en el sentido de que
pretenden llevar a cabo la funcionalidad
del sistema sirviendo como pegamento
entre los diversos componentes.

[Como conclusión…]
 Parece evidente que aunque en estos
lenguajes se plantea en algún momento el
problema de la verificación no constituye
una motivación básica, y se trata de una
cuestión abierta. Las técnicas en las que
se basan, además, se hallan aún bajo
desarrollo.
[Programación por
contratos]
 Meyer


 Persigue realizar una especificación del software

◦ Qué se entiende por comportamiento correcto
 Se basa en una lógica de predicados sobre el
estado concreto del elemento a verificar.
 Expresar los contratos mediante ciertos
recursos del propio lenguaje de programación,
ciertas expresiones que se ejecutan
imbricadas con la propia implementación de la
funcionalidad.

[Meyer]
 El construir las especificaciones con
elementos del lenguaje de programación
(incluyendo funciones imperativas) va
contra la idea fundamental del análisis
estático.
 Las expresiones asertivas ejecutables que
Meyer propone no se pueden analizar de
manera estática (a menos que se añada
una nueva capa de interpretación
abstracta sobre las mismas, tarea nada
sencilla.
[Meyer]
 Empeora esto el hecho de que la
verificación de precondiciones,
postcondiciones e invariantes puede ser
costosa en tiempo de ejecución, como ya
se ha dicho, y frecuentemente se
desactiva al generar las versiones
definitivas de los programas.
 Se sigue dependiendo de una fase de
pruebas
 “Si usted me promete llamar al método con
las precondiciones satisfechas, entonces
yo le prometo entregar un estado final en
el que las postcondiciones están
[Meyer]
 A la clase no le importan las promesas de su
cliente; lo único que ocurre es que, si en la
práctica se da el caso de incumplimiento
de las precondiciones, la clase tendrá la
libertad de incumplir sus postcondiciones.
 Perfectamente posible conectar a un objeto
servidor con un objeto cliente que no
cumpla las precondiciones de dicho
servidor.
 En tiempo de ejecución se producirá un fallo
que el sistema detectará.
[Estilos arquitectónicos e
incoherencias]
 Aproximación interesante, un problema similar.
La combinación de partes que responden a
diferentes estilos arquitectónicos (también un
conglomerado de componentes), y la
detección de incoherencias entre esas partes
responde a la misma preocupación: la
necesidad de prevenir los errores emergentes
que aparecen en un sistema y que no son
fruto de defectos intrínsecos de ninguna de
sus partes, sino de defectos consecuencia de
la propia combinación de las mismas.
[Interés del problema]

 Creciente tendencia a construir sistemas
software basados en componentes, y a la
importancia de detectar los defectos del
software; teniendo en cuenta que muchos
defectos no tienen su origen en un
componente individual, sino en la
combinación de varios componentes.

[Interés del problema]
 En general es realmente difícil asegurar que un
componente no presenta fallos internos, por dos
razones:
◦ Detección de problemas que se originan al combinar
componentes y no al construirlos.
◦ Posible aplicar las mismas ideas de manera recursiva; si
un componente deja de ser una caja negra y se
considera a su vez un subsistema formado por
componentes, también el interior de un componente
podrá verificarse
◦
 El hecho de verificar la corrección inter-
componente sin entrar a considerar la
corrección intra-componente puede parecer una
limitación, pero en realidad es una estrategia
deliberada

[Interés del problema]
 Una simple división por cero puede
considerarse como una violación de las
condiciones de funcionamiento de un
componente (÷) al colocar este en un
entorno en conexión con otros
componentes y suministrarle una
entrada errónea (el denominador cero).
Por tanto, la metáfora del sistema
formado por componentes
interconectados puede ser útil para
prevenir muy diversos tipos de errores
del software.
[Itacio]
 "Encerré en precioso mármol para la
mansión eterna el tierno cuerpo de Itacio”.


 Modelo de componentes, cuyo objetivo es

ofrecer una estrategia general de
desarrollo que, apoyándose en la
combinación de componentes, permita una
verificación estática y automática del
software que se está construyendo.
[Itacio]
 Construcción de software mediante
componentes es esencialmente una
actividad artesana, y las pruebas por sí
solas no pueden detectar muchos tipos de
errores que sin embargo podrían evitarse.
 Debería realizarse algún tipo de análisis
estático; un análisis automatizado,
exigente y conservador que señale
cualquier combinación de componentes no
válida. Si no está garantizado que una
unión es correcta, se considera que es
incorrecta y se rechaza.
[Itacio]
 Componentes suelen suministrarse con
documentación pensada para seres
humanos.
 Ambigua e incompleta, y en cualquier caso
la gente que la lee puede cometer errores.
 Si los componentes fuesen caracterizados
de manera más seria, se podrían detectar
muchos problemas casi en tiempo de
diseño, simplemente verificando las
exigencias y garantías de los componentes
involucrados.
[Itacio]
 Itacio pretende aportar especificaciones
más sólidas. Pero los métodos formales
suelen ser difíciles de entender y
utilizar.
 Objetivo: ofrecer una forma de
especificar componentes que sea útil
en el "mundo real", sin la necesidad de
conocimientos muy especializados.
 Por supuesto, la especificación de un
componente puede ofrecer garantías
que en realidad no cumple. Pero este
problema no tiene solución conocida,
de todas formas.
[La única solución
definitiva]
[Fin]