Escolar Documentos
Profissional Documentos
Cultura Documentos
Verificación de
Componentes Software
{Moisés Aguirre Carmona}
[Descripción del problema]
[Puntos importantes]
tiempo
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…
e construe 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