WEBVTT

1
00:00:00.906 --> 00:00:03.866
Fernando Orejas Valdés: Sí, pues es la hora de de empezar.


2
00:00:05.686 --> 00:00:10.595
Fernando Orejas Valdés: Bueno, buenas tardes a todos en este primer seminario de


3
00:00:10.726 --> 00:00:13.646
Fernando Orejas Valdés: del curso, 27


4
00:00:13.756 --> 00:00:16.125
Fernando Orejas Valdés: 24 25.


5
00:00:16.626 --> 00:00:18.116
Fernando Orejas Valdés: Y


6
00:00:18.346 --> 00:00:28.176
Fernando Orejas Valdés: tenemos a Ricardo como Conferenciante Ricardo peña que ya lo tuvimos en el año 21 hablando de de


7
00:00:29.396 --> 00:00:40.305
Fernando Orejas Valdés: bueno, es igual de lo que hablaba. Pero bueno, esta vez nos va a hablar sobre el contenido de un libro


8
00:00:40.486 --> 00:00:48.285
Fernando Orejas Valdés: que ha escrito recientemente sobre los errores de software y cómo prevenirlos? ¿cómo evitarlos?


9
00:00:48.906 --> 00:00:58.075
Fernando Orejas Valdés: Bueno, Ricardo es un histórico como yo. Es decir, estamos jubilados, pues son juegos históricos.


10
00:00:58.346 --> 00:01:01.756
Fernando Orejas Valdés: Él es emérito en la complutense


11
00:01:01.926 --> 00:01:22.546
Fernando Orejas Valdés: yo en la o P, C, y el antes de estar en la complutense. Estuvo también en la u P, C, Y antes de eso, en empresas en estándar. Electric en indoico, cosa que no es muy habitual que la gente se pase de las empresas a la universidad. Lo hizo hace muchos años.


12
00:01:24.166 --> 00:01:31.905
Fernando Orejas Valdés: Y bueno, aparte de de la investigación que en su día hizo y que no sé si ahora sigue haciendo algo o no.


13
00:01:32.166 --> 00:01:34.526
Fernando Orejas Valdés: pues


14
00:01:34.976 --> 00:01:37.306
Fernando Orejas Valdés: se ha dedicado a muchas actividades


15
00:01:37.306 --> 00:01:39.005
Fernando Orejas Valdés: y es


16
00:01:39.006 --> 00:01:46.285
Fernando Orejas Valdés: más que lo que es estrictamente la investigación y la docencia. Ha escrito varios libros, algunos de docencia


17
00:01:46.926 --> 00:01:54.255
Fernando Orejas Valdés: y otros de de divulgación, este de el que va al seminario de ahora. Es 1 de ellos


18
00:01:54.876 --> 00:02:01.006
Fernando Orejas Valdés: y y creo que, además, es un buen escritor, y también ha sido el


19
00:02:01.536 --> 00:02:10.615
Fernando Orejas Valdés: el que ha puesto el que puso en su día en marcha el blog del país de las crónicas del intangible so software.


20
00:02:11.326 --> 00:02:11.876
Fernando Orejas Valdés: Y,


21
00:02:11.876 --> 00:02:13.996
Fernando Orejas Valdés: Y, bueno.


22
00:02:14.116 --> 00:02:19.145
Fernando Orejas Valdés: yo creo que lo mejor es que escuchemos el seminario


23
00:02:19.296 --> 00:02:20.876
Fernando Orejas Valdés: ahora y.


24
00:02:21.546 --> 00:02:23.316
Ricardo Peña: Y espero que os guste.


25
00:02:24.626 --> 00:02:35.936
Ricardo Peña: Bueno, Fernando, muchas muchas gracias. Espero que veáis la presentación por algún problema técnico de mi portátil. La Cámara no, no consigo que funcione, pero el sonido sí


26
00:02:36.196 --> 00:02:39.116
Ricardo Peña: y compartir pantalla también.


27
00:02:39.336 --> 00:02:44.525
Ricardo Peña: Entonces, bueno, si si hay algún problema, me lo decís por el sonido, porque yo ahora mismo


28
00:02:44.656 --> 00:02:47.805
Ricardo Peña: estoy viendo solo mis transparencias.


29
00:02:49.186 --> 00:02:49.936
Ricardo Peña: Vale.


30
00:02:50.536 --> 00:02:52.076
Ricardo Peña: Entonces, empiezo


31
00:02:52.256 --> 00:03:10.235
Ricardo Peña: muchas gracias por la presentación. Fernando: Efectivamente, soy emérito. Hago alguna actividad, pero fundamentalmente estudio lo que hago, ¿no? Bueno, salvo esta charla o alguna participar en algún tribunal de tesis o alguna cosa así. Pero mi principal actividad


32
00:03:10.336 --> 00:03:13.136
Ricardo Peña: es estudiar. Estoy estudiando


33
00:03:13.266 --> 00:03:15.556
Ricardo Peña: redes neuronales, que es una


34
00:03:15.956 --> 00:03:36.725
Ricardo Peña: una es un área muy lejana a lo que yo he hecho en mi vida profesional. Computación cuántica? Pues, bueno, cosas que me interesan pero que no, no estoy investigando en ello. Bien, pues sin más empezamos. Como ha dicho Fernando. Yo vengo a hablar de mi libro


35
00:03:37.166 --> 00:03:43.796
Ricardo Peña: y entonces, a ver un momentito que ahora tampoco funciona el avanzar páginas ¿Será posible?


36
00:03:44.296 --> 00:03:59.256
Ricardo Peña: Esto? Sí que ya esto sí que es grave. Así funciona así. Bueno, esta es la portada de mi libro se ha publicado este año. Está editado por la complutense, por lo que sé, es bastante barato, vale 10 o 12 €,


37
00:03:59.386 --> 00:04:21.766
Ricardo Peña: y está pensado, Es un libro de divulgación, pero de divulgación. Podríamos llamar avanzada porque aparecen fórmulas, aparecen textos de programa. Bueno, quiero decir que se supone que es gente con alguna. Los lectores tienen que ser personas con alguna componente técnica, ¿no? Pero bueno, también los físicos publican integrales en sus libros de divulgación y no pasa nada. ¿no?


38
00:04:21.906 --> 00:04:31.956
Ricardo Peña: Entonces, sobre todo, es interesante para los estudiantes de informática, porque hay temas que no se suelen ver en el grado. De hecho, voy a hablar


39
00:04:32.196 --> 00:04:39.456
Ricardo Peña: fundamentalmente de estos temas hoy. Entonces aquí tenéis el índice.


40
00:04:39.686 --> 00:04:45.666
Ricardo Peña: Primero voy a relatar algunos errores, solo 2 o 3. En el libro hay más


41
00:04:46.036 --> 00:04:50.216
Ricardo Peña: y, sobre todo, las causas. ¿por qué se produjeron y si se podrían


42
00:04:50.346 --> 00:04:53.735
Ricardo Peña: haber evitado con los métodos que voy a contar después.


43
00:04:53.896 --> 00:05:09.596
Ricardo Peña: Luego de más sencillo, a más complicado, pues tenemos métodos para evitar cometer errores sería el testing. El análisis estático. La verificación del modelo, lo que se llama model check in en inglés de modelos concurrentes.


44
00:05:09.726 --> 00:05:11.575
Ricardo Peña: La verificación formal.


45
00:05:12.086 --> 00:05:26.926
Ricardo Peña: Entonces, como el testing y la verificación formal suelen contar en el grado, pues le dedicaré poco tiempo a eso y dedicaré más tiempo a los apartados 3 y 4, El análisis estático y la verificación.


46
00:05:27.336 --> 00:05:43.366
Ricardo Peña: Bueno, pues empezamos errores famosos. Uno de los había aquí una en el libro Primer capítulo, se hace una distinción. Por eso el libro se llama los errores del software y no los fallos del software.


47
00:05:43.666 --> 00:05:56.146
Ricardo Peña: se hace distinción entre fallos y errores. Entonces, en el libro hay una historia paralela a la de divulgación, que es unas conversaciones que suceden en la empresa


48
00:05:56.216 --> 00:06:12.656
Ricardo Peña: Amazon Web services que me las he inventado, pero que responden a hechos reales donde los ingenieros, pues discuten cómo evitar los errores y cómo hacer las cosas mejor. ¿no? Entonces hay un personaje que es chino se llama Zhang Zhang


49
00:06:12.706 --> 00:06:40.616
Ricardo Peña: y otro que es norteamericano. Se llama Tim Ralf. Trabajan los 2 allí y el chino le pregunta al americano que por qué llaman Bax a los errores? No, Bax. ¿sería bicho, no o pulga. Entonces el americano le contesta y dice: mira, Fan. Yo creo que no es casual. Más bien pienso que se trata de una actitud psicológica. Si a los fallos les llamamos bichos, nos quitamos de encima un poco de nuestra responsabilidad. Ya se sabe que los bichos son imprevisibles


50
00:06:40.796 --> 00:06:56.136
Ricardo Peña: y si causan problemas, pues no son culpa de nadie. Y el fan le responde y dice, pues tiene sentido. Tim. Pero incluso la palabra fallo sugiere algo imprevisible, No, como dice si se va, si se va la luz, pues no es culpa de nadie. Son cosas de la vida, ¿no?


51
00:06:56.236 --> 00:07:13.345
Ricardo Peña: Y el otro concluye Así es el lenguaje que empleamos. No es inocente. Yo he escuchado a compañeros echar pestes de un programa diciendo cosas como no puede ser que falle. Esta mañana lo ejecuté. ¿por qué ahora le da por fallar? Como si los programas tuvieran vida propia y unas veces les da por fallar y otras no. No.


52
00:07:13.496 --> 00:07:28.946
Ricardo Peña: Entonces realmente lo que estamos hablando es de errores humanos, no de fallos, porque los programas no fallan programas son completamente predecibles, como sabemos. ¿no? Entonces se trata de por qué los humanos cometemos tantos errores y cómo impedir que


53
00:07:29.116 --> 00:07:30.315
Ricardo Peña: cometer más. ¿no?


54
00:07:30.536 --> 00:07:33.326
Ricardo Peña: Bien, pues empezamos el primer


55
00:07:33.636 --> 00:08:00.406
Ricardo Peña: fallo que registro es muy temprano el año 1 962, y fue el vuelo de la Mariner, que era un programa de mandar sondas a Venus, y esta era una de las sondas. La Mariner, 1 supongo que sería la primera, no a los 2 min de lanzar la sonda del cohete que lo tenéis ahí en la parte de la derecha, pues la sonda entró en un rumbo errático y tuvo que ser destruida.


56
00:08:00.546 --> 00:08:11.275
Ricardo Peña: analizada. El fallo analizado, el fallo, pues hubo varias y varias hipótesis, pero una de ellas, la más probablemente la que era más previsible, La más probable


57
00:08:11.406 --> 00:08:16.685
Ricardo Peña: es que el programa que controlaba el vuelo, pues tenía ahí una instrucción que es la que está en rojo.


58
00:08:16.936 --> 00:08:37.765
Ricardo Peña: que estaba mal escrita porque tenía que estar como en azul. Do 5 desde k igual a 1 hasta 3. Suponía que eso era un bucle de 3 iteraciones con la k variando de 1 a 3, pero el programador escribió un punto. Y entonces, en el compilador Fortran, que era una cosa muy primitiva, porque el primer compilador de forza. Estaba en el año 57


59
00:08:37.766 --> 00:08:49.026
Ricardo Peña: no tenía gramáticas formales para los lenguajes. En fin, pues habían decidido que los blancos no eran significativos y se había interpretado como la variable Du: 5 k


60
00:08:49.036 --> 00:08:50.346
Ricardo Peña: toma por valor


61
00:08:50.386 --> 00:09:05.836
Ricardo Peña: 1, 3. Entonces, en ese Ford trance que sería Fortran, 2, 1 de los primeros. Las variables no se declaraban, sino que por la letra de comienzos y comenzaba por letras entre la J. K. L. M. Y N: Se suponía que eran enteros.


62
00:09:05.926 --> 00:09:20.075
Ricardo Peña: ¿no? I J. K, Desde ahí hasta la N, si empezaban por cualquier otro letra, se suponía que eran de coma flotante, con lo cual, en lugar de un bucle, lo que había que era una asignación o una variable no declarada del valor Uno, 3. Entonces eso es lo que hacía que el cohete


63
00:09:20.076 --> 00:09:38.276
Ricardo Peña: pues perdiera por allí. No. Entonces, claro, un compilador un poquito más moderno que se fortran 2 lo hubiera detectado simplemente. Bueno, si se declaran las variables, Bueno, Para empezar, los blancos sí son significativos, por lo menos 1 de ellos


64
00:09:38.326 --> 00:09:40.046
Ricardo Peña: en los lenguajes modernos.


65
00:09:40.116 --> 00:09:54.295
Ricardo Peña: Y luego las variables se declaran con su tipo y bueno, se hubiera detectado y, en cualquier caso, como digo ahí, pues no se hicieron suficientes pruebas y aquello pues cuando se puso a ejecutar en pleno vuelo. Es cuando falló.


66
00:09:54.386 --> 00:10:00.726
Ricardo Peña: Bueno, aquí tenemos un fallo y una causa y una posible forma de que no se hubiera producido.


67
00:10:01.306 --> 00:10:03.065
Ricardo Peña: Otro muy famoso.


68
00:10:03.316 --> 00:10:18.275
Ricardo Peña: Este ya es de los años 80. Fue una máquina norteamericana, Laterack, 25, que era una máquina, un acelerador de partículas controlado por software para suministrar tratamientos de radioterapia contra el cáncer.


69
00:10:18.426 --> 00:10:30.456
Ricardo Peña: Entonces, entre los años 85 y 87 protagonizó 6 accidentes en los que los pacientes recibieron dosis dosis letales de radiación, y 3 de ellos murieron.


70
00:10:30.736 --> 00:10:46.236
Ricardo Peña: Y bueno, la máquina tenía 2 modos de funcionamiento. Uno, digamos, dosis bajas de radiaciones de baja potencia durante cortos periodos de tiempo que esas incidían directamente sobre el paciente para, digamos, matar el tumor maligno.


71
00:10:46.386 --> 00:11:08.315
Ricardo Peña: Y luego tenía otro modo que era el modo. Rayos X donde el as de electrones eran de muy alta potencia de más duración y se suponía que había un blanco contra el que incidía y al golpear los electrones se generaban rayos X en ese blanco, esos rayos X se filtraban y al final lo que llegaba al paciente eran unos rayos X más atenuados. ¿no?


72
00:11:08.476 --> 00:11:26.695
Ricardo Peña: Entonces era un sistema concurrente, porque había, pues los procesos que gobernaban la emisión de electrones y luego los procesos que atendían al usuario, el cual podía cambiar por software de un modo a otro, no. En la versión anterior de la máquina, la


73
00:11:26.866 --> 00:11:43.406
Ricardo Peña: el modo, digamos, de alta potencia no se podía activar si no había un blanco en su sitio. Había un procedimiento hardware que lo impedía. Pero en la versión moderna eso se hacía por software. Y entonces la variable que controlaba es una variable compartida.


74
00:11:43.606 --> 00:11:53.665
Ricardo Peña: Y si el Blanco estaba en su sitio. También era una variable que detectaba. Era un sensor que detectaba el blanco y era una variable. Esas variables estaban compartidas entre los procesos, entonces


75
00:11:53.666 --> 00:12:19.566
Ricardo Peña: lo de la exclusión mutua, pues en aquellas épocas no se conocía muy bien y existían aunque ya existían los semáforos y mecanismos de sincronización, pero los programas estaban hechos de una manera, un poquito rudimentaria. Entonces se producían carreras de competición entre los procesos que accedían a las variables compartidas y en algunas situaciones donde un proceso corría más que el otro se podía dar el caso de que sin haber blanco


76
00:12:19.676 --> 00:12:29.086
Ricardo Peña: se activara el modo rayos X de alta potencia. Entonces, claro, eso incidía sobre el paciente y era lo que producía los accidentes. No.


77
00:12:29.316 --> 00:12:44.835
Ricardo Peña: Bueno, ¿cómo se podía haber evitado, pues, desde luego, con mecanismos de sincronización, con regiones críticas con más testing, por supuesto. Pero si hubieran sometido al al programa a un model checker a un comprobador de modelos.


78
00:12:44.926 --> 00:13:10.615
Ricardo Peña: pues seguramente ese error hubiera aparecido Entonces, en esa época, todavía no existían los los verificadores de modelos, porque se empezaron a hacer, pues a finales de la década de los 80. Entonces, bueno, pues en este caso, si hubiéramos tenido una tecnología mejor, pues no se hubiera producido no. Y el tercer error que quería comentar. Este tiene que ver con nosotros con los europeos.


79
00:13:10.766 --> 00:13:38.956
Ricardo Peña: Fue el primer vuelo del Ariane. Cinco: El Arian 5 se inauguró en 1 996 y un lanzamiento que tenía que poner en órbita 4 satélites para medir el campo magnético de la Tierra y a los 40 s de lanzamiento, el cohete se empezó a inclinar, se inclinaba más y más se partió. Y Bueno, el mecanismo de autodestrucción se activó y el cohete estalló a 3 000 m


80
00:13:39.086 --> 00:13:56.386
Ricardo Peña: de altura. Por fortuna, no produjo daños, pero se perdieron los satélites y se perdió una buena cantidad de 1 000 000 de dólares. No, ¿Cuál fue el problema, Pues el problema fue que había que convertir un valor en coma flotante que representaba la velocidad lateral del cohete


81
00:13:56.466 --> 00:14:24.676
Ricardo Peña: había que convertirlo a flotante. Estaba en una palabra de 64 bits, y había que convertirlo a un entero de 16 bits. Entonces, pues ellos habían calculado que los valores no serían muy grandes y que podría entrar en una palabra de 60, 16 bits. De hecho, el software se había probado en la versión anterior, donde habían 4, y había funcionado todo bien. Pero resultó que el harían 5 tenía una velocidad, un rango de velocidades laterales más amplio.


82
00:14:24.806 --> 00:14:42.855
Ricardo Peña: Y entonces ya los valores que se calculaban de la velocidad lateral ya no cabían en 16 bits, con lo cual la variable se desbordó. Cambió de signo, como sabemos, pasó de positiva a negativa, y el cohete, pues en lugar de corregir el efecto lateral, se fue oxidando cada vez más.


83
00:14:43.216 --> 00:14:46.005
Ricardo Peña: Bueno, ese fue el error. La causa estaba clara.


84
00:14:46.296 --> 00:14:50.116
Ricardo Peña: ¿cómo se podía haber detectado, por supuesto, con más testing.


85
00:14:50.866 --> 00:14:58.725
Ricardo Peña: pero con métodos actuales, probablemente volveremos luego. Las técnicas de interpretación abstracta


86
00:14:59.066 --> 00:15:25.375
Ricardo Peña: son capaces de analizar de manera estática a partir del texto. Los rangos de las variables podían llegar a decidir que ciertas variables estaban entre un valor mínimo y un valor máximo. No. Entonces, si se hubiera pasado. Esto por un analizador estático, pues probablemente se hubiera visto que esa variable entera no podía contener ese valor tan grande, ¿no?


87
00:15:25.616 --> 00:15:40.185
Ricardo Peña: Y luego, si se hubiera usado lógica formal y se hubiera puesto un aserto de que, antes de claro, los programadores no prestaban mucha atención al tema del desbordamiento, pensamos que siempre van a las valores. Van a caber, van a caber las palabras, pero claro, hay que tener en mente


88
00:15:40.306 --> 00:15:49.725
Ricardo Peña: que las que las máquinas son finitas, o sea, los tamaños de las palabras enteras o comas flotante, son finitos y que en algún caso se pueden desbordar.


89
00:15:49.936 --> 00:16:09.965
Ricardo Peña: Y entonces, pues, con asertos y de verificación formal. Al fin y al cabo, la operación de casting de convertir un valor de un tipo a otro debería tener una precondición, que es que el valor esté en cierto rango para que no se desborde la valla si hubiéramos hecho eso, pues este error se podría haber detectado


90
00:16:10.366 --> 00:16:16.225
Ricardo Peña: bien, pues hay más en el libro, pero estos serían los errores


91
00:16:16.786 --> 00:16:20.166
Ricardo Peña: que me sirven de base para poder hablar de los otros métodos


92
00:16:20.316 --> 00:16:28.416
Ricardo Peña: de testing. ¿qué podemos decir de testing? Por supuesto, no os voy a aburrir de qué es el testing. Simplemente voy a decir un par de cosas no


93
00:16:28.626 --> 00:16:31.036
Ricardo Peña: que hemos


94
00:16:31.206 --> 00:16:39.345
Ricardo Peña: aprendido sobre el testing. La primera es que se hacen muchas menos pruebas de las necesarias, porque hacer pruebas son


95
00:16:39.686 --> 00:16:47.496
Ricardo Peña: es muy costoso. Y entonces, pues, claro: cuanto más pruebas se hagan, pues más probabilidades es de que el programa esté bien.


96
00:16:47.696 --> 00:16:54.235
Ricardo Peña: Pero la otra cosa que hemos aprendido es que el testing lo único que vale, como dice la extra


97
00:16:54.356 --> 00:17:18.445
Ricardo Peña: es para detectar errores. O sea, es útil para detectar errores, pero es absolutamente inútil para demostrar que no hay errores. Entonces, cuando decimos que el testing va bien, en realidad, lo que decimos en realidad es que va mal, o sea, cuando los casos de prueba se pasan sin dar errores. El testing va mal porque no detecta errores. Cuando el testing va bien, es cuando detecta errores. ¿no? Entonces bueno, pues


98
00:17:18.636 --> 00:17:37.476
Ricardo Peña: la primera, la segunda parte va a ser difícil de corregir porque, como digo ahí casi todos los programas, por muy pequeños que sean, tienen infinitas posibilidades, No, Si tenemos que hacer un programa que nos ordene una lista, pues hay infinitas listas. Entonces nunca vamos a poderlo probar en todas sus posibilidades. No


99
00:17:37.706 --> 00:17:44.445
Ricardo Peña: sí podemos mejorar el tema de la se de del de hacer más pruebas con menos coste? ¿no?


100
00:17:44.746 --> 00:17:54.426
Ricardo Peña: Y eso, pues, nos remite a las herramientas de ayuda a las pruebas, entonces las herramientas de ayuda a las pruebas suelen


101
00:17:54.556 --> 00:17:59.306
Ricardo Peña: utilizarse para seleccionar casos de prueba.


102
00:17:59.706 --> 00:18:25.485
Ricardo Peña: Pero, claro, los casos de prueba se pueden basar, como bien sabemos, en 2 cosas: o bien en la especificación, sería lo que llamamos casos caja negra, o bien en la implementación casi todas las herramientas se basan en la implementación, o sea, escogen casos de prueba que ejecutan todos los caminos a través del programa, no y claro, pero eso es incompleto, no porque primero podemos seleccionar casos de pruebas


103
00:18:25.576 --> 00:18:48.556
Ricardo Peña: que no satisfacen la especificación o que no, o sea que el programa no está previsto para ellos. Por tanto, estamos seleccionando casos de pruebas que son inútiles, no y, por otra parte, la implementación puede ser incompleta. Entonces, si le faltan caminos, nunca seleccionaríamos casos para los caminos que faltan. Por tanto, tener los 2 conjuntos basados en la especificación e implementación. Sería muy deseable, ¿no?


104
00:18:48.826 --> 00:19:01.985
Ricardo Peña: Pero, claro, el problema es que hay que tener una especificación si no tenemos especificación, pues tampoco se pueden generar casos de caja negra? ¿no? Y luego está el tema de la comprobación de los casos. Si los casos se comprueban a mano.


105
00:19:02.246 --> 00:19:31.906
Ricardo Peña: o sea, visualmente. Quiero decir, se ejecuta. Y hay un señor que dice una señora que dice: esto está bien o esto está mal, pues eso también es peligroso, porque muchas veces podemos dar por buenos casos de prueba que son erróneos y, peor. Todavía podemos dar por malos casos de prueba que se han ejecutado bien, o sea, que el resultado es bueno. Entonces sería bueno también automatizar la comprobación del resultado. Pero, claro, para eso hace falta tener una especificación, o sea, qué es lo que debe cumplir el programa? ¿no?


106
00:19:31.936 --> 00:19:32.716
Ricardo Peña: Bueno, entonces


107
00:19:33.196 --> 00:19:36.615
Ricardo Peña: entonces yo me permito una cosa que no está en el libro


108
00:19:36.796 --> 00:19:49.726
Ricardo Peña: y que es un sistema que en los últimos años de cuando estaba en activo, hicimos y que estoy bastante orgulloso de él. Esto tiene que ver con un proyecto que se llamaba Caviart.


109
00:19:49.896 --> 00:20:06.845
Ricardo Peña: que era las siglas de computer assist Validation. Bueno, mediante análisis verificación, no sé qué y la t que aparece al final de caviar es testing. O sea que la la cosa, esa era tener una plataforma que permitiera verificar programas


110
00:20:07.036 --> 00:20:14.885
Ricardo Peña: y además, hacer testing con ellos, como había que verificarlos. Los programas ya venían dotados de precondición y post condición.


111
00:20:15.016 --> 00:20:27.726
Ricardo Peña: Y entonces, pues, era una tentación: usar la especificación para hacer testing No es una cosa poco inusual usar aceptos lógicos de condiciones y poscondiciones para hacer testing.


112
00:20:27.836 --> 00:20:30.485
Ricardo Peña: Bueno, pues os voy a contar el sistema para que veáis que


113
00:20:30.826 --> 00:20:35.116
Ricardo Peña: que automatiza todo. Una vez que tenemos precondición y poscondición.


114
00:20:35.416 --> 00:21:04.636
Ricardo Peña: tenemos miles de casos que no solo se generan de forma automática a partir de la precondición, sino que se comprueban de forma automática a partir de la post condición. Entonces aquí. Tenéis el sistema completo en esta transparencia, el clear. Este es el los programas de entrada que bueno, están en un formato que Ahora veréis que es horroroso porque provienen de una transformación de programas en Java o en o en Airla. En fin, era es una representación intermedia.


115
00:21:04.766 --> 00:21:25.895
Ricardo Peña: entonces lo importante es que vienen dotados de precondición y post condición, entonces la precondición se le da a un Smt que voy a hablar dentro de poco de ellos. Un resolutor módulo feoris Tres es en este caso que es de Microsoft, entonces la precondición se convierte a un conjunto de restricciones.


116
00:21:26.036 --> 00:21:47.246
Ricardo Peña: y el resolutor da modelos que llamamos que satisfacen esas restricciones, y esos modelos se convierten en casos de prueba entendéis la idea. ¿no? Si hay alguna duda, me preguntáis, entonces esos modelos vuelven al sistema. El sistema, los convierte en casos de prueba, esos se les dan a un test Driver.


117
00:21:47.366 --> 00:22:02.066
Ricardo Peña: Bueno, los casos de prueba se escriben en Haskell porque, claro, la anotación nuestra. Esta no se ejecutaba. Había que convertirla a Haskell por aquí abajo. Eso me daba la unidad bajo prueba y unit, under test escrita en Haskell, el test Driver ejecutaba los casos de prueba.


118
00:22:02.386 --> 00:22:10.315
Ricardo Peña: veía que el resultado devolvía el programa Haskell. Ese resultado lo convertía a restricciones de Z. Tres


119
00:22:10.456 --> 00:22:15.016
Ricardo Peña: se las daba Z 3 para ver si lo que devolvía el


120
00:22:15.616 --> 00:22:20.525
Ricardo Peña: el programa bajo prueba satisfacía o no, la Post, condición


121
00:22:20.556 --> 00:22:47.156
Ricardo Peña: escrita también como restricciones Z 3. Entonces el Z 3: Si devolvía Sat Sat, es que es satisfactible. Quería decir que el caso era bueno. O sea que el resultado devuelto era bueno. Si decían Sat, el caso era malo, entonces bueno al final daba valor, por lo cual lo único que tenía que hacer una vez escrita la preposición y preposición. Lo único que tendría que hacer el programador que está sentado aquí en esta silla


122
00:22:47.396 --> 00:23:00.596
Ricardo Peña: es determinar cuántos casos quiere. Y para eso lo que hacía es dar unas limitaciones de tamaño, Es decir, si un parámetro era entero, dice, bueno, pues yo no quiero probar con todos los enteros. Quiero probar con enteros entre 1 y 10. Pongámoslo.


123
00:23:00.596 --> 00:23:18.076
Ricardo Peña: Y si el parámetro es una estructura de datos como una lista o un árbol, podías dar también una noción de tamaño. Quiero listas de tamaño entre 0 y 10, por ejemplo, o árboles de altura como máximo. Tres. Yo qué sé. Entonces eso daba lugar a un conjunto, me oís.


124
00:23:18.396 --> 00:23:19.086
Ricardo Peña: Sí,


125
00:23:19.136 --> 00:23:37.326
Ricardo Peña: eso daba lugar a un conjunto de casos que podríamos llamar exhaustivos, porque con esas limitaciones de tamaño empezaba por los casos más pequeños por vistas vacías o árboles vacíos, y terminaba todos los modelos de esos tamaños


126
00:23:37.376 --> 00:23:43.275
Ricardo Peña: hasta el máximo que se había dado. Entendéis lo que quiero decir. Entonces voy a mostrar otra pantalla


127
00:23:43.286 --> 00:24:08.646
Ricardo Peña: donde se va a ver todo esto con más claridad. Mirad, esto es la inserción en una Vl. La función esta se llama inserta Vl: Si veis. Si no veis el cursor, me lo decís recibe un entero, que es lo que vamos a insertar una vl de enteros y devuelve un resultado que es una vl de enteros. Entonces la precondición es que el árbol de entrada satisface un predicado que se llama Isa Vl, que está definido recursivamente.


128
00:24:08.646 --> 00:24:31.175
Ricardo Peña: y que los S. M Ts son capaces de convertirlo en restricciones. Entonces el I S. B, L es la precondición, o sea, que lo que le entra tiene que ser una V. L: Y luego lo que sale tiene que ser una V L. La anotación. Esta es prefija. Es un poco rara. Pero bueno, lo que dice es que lo que sale es una V L y que es la unión entre el conjunto


129
00:24:31.286 --> 00:24:35.156
Ricardo Peña: claro y que el conjunto de elementos


130
00:24:35.316 --> 00:24:40.146
Ricardo Peña: de ese resultado hay una función que te da el conjunto de elementos de un árbol


131
00:24:40.376 --> 00:25:04.895
Ricardo Peña: es la unión de s. Uno y s 2, donde s. Uno es el conjunto de elementos del árbol de entrada, y ese 2 es el conjunto unitario formado por la Equis. Lo que tú dices que la salida es la unión de la X y de la entrada, Vale, entonces eso se convierte a restricciones. S, M T, Y este es el fichero de restricciones que lo que hace es declarar una constante entera, una constante T que es una vl, o sea, los Smt, se


132
00:25:05.006 --> 00:25:12.206
Ricardo Peña: como veremos luego, permiten definir tipos algebraicos, o sea, que definir una vl, pues es un árbol binario sin más.


133
00:25:12.366 --> 00:25:14.345
Ricardo Peña: Y luego dice


134
00:25:14.936 --> 00:25:16.316
Ricardo Peña: que


135
00:25:17.676 --> 00:25:24.646
Ricardo Peña: a ver un momentito que los enteros, O sea que la X tiene que estar entre 1 y 5. Eso lo ha dado el usuario


136
00:25:24.686 --> 00:25:46.686
Ricardo Peña: que los valores que pueblan los nodos de la Vl tienen que estar también entre 1 y 5, y que la altura del árbol tiene que ser como máximo, 3, menos igual que 3, y que ha de ser una Vl. Estos son los asertos de entrada, ¿no? Entonces, con estos asertos de entrada? Bueno, si queréis, vamos a ver la post condición para que veáis que la post condición también la tenemos.


137
00:25:46.686 --> 00:26:07.045
Ricardo Peña: La post condición. Lo que dice, es, declara un entero la X, un árbol a Vl: La T. Y el resultado también es otra Vl: Y lo que dice es lo mismo que decíamos antes, no que la que la el conjunto de elementos, o sea, que el resultado es una Vl: Bueno, esto lo diferencia con lo que habéis visto antes es que esto ya no es una


138
00:26:07.186 --> 00:26:13.026
Ricardo Peña: post condición en un lenguaje lógico. Esto es un aserto, una restricción para el Smt.


139
00:26:13.276 --> 00:26:19.505
Ricardo Peña: Entonces, ahora, con la precondicción que hemos visto antes. Y con estos límites entre 1 y 5,


140
00:26:19.786 --> 00:26:23.126
Ricardo Peña: el sistema nuestro generaba todo esto.


141
00:26:23.616 --> 00:26:29.446
Ricardo Peña: Entonces vamos a ponerlo al principio, como veis, empieza generando


142
00:26:29.956 --> 00:26:31.755
Ricardo Peña: con un árbol vacío.


143
00:26:32.206 --> 00:26:38.025
Ricardo Peña: pues insertar en él un 1, un, 2, un 3, en cuanto o sea, todas las combinaciones de X posibles con árboles vacíos.


144
00:26:38.066 --> 00:26:54.055
Ricardo Peña: Luego aquí hay otros, 25, hasta el 30 que son a V Ls: de un nodo que tienen? Bueno, están un poco desordenados, pero tienen 5 treseses, 5, 1, 5, 4, 5. O sea, todos los valores que hemos dicho de que pueblan los los nodos


145
00:26:54.056 --> 00:27:09.626
Ricardo Peña: y en cada 1 de ellos insertamos, o bien un 1 hasta un 5, lo cual hay 5 por 5, 25 árboles más. Los 5 de antes son 30. Luego aquí tenéis los de 2 nodos con el nodo, primero a la izquierda, o sea, tiene una raíz y un nodo a la izquierda. Aquí Tenéis otros tantos


146
00:27:09.726 --> 00:27:20.246
Ricardo Peña: con el hijo izquierdo vacío y el nodo a la derecha aquí. Tenéis los de 3 nodos. Bueno, en fin, aquí están todos. Al final, hay 310


147
00:27:20.606 --> 00:27:26.346
Ricardo Peña: 310 casos, todos generados automáticamente, todos generados automáticamente.


148
00:27:26.626 --> 00:27:32.205
Ricardo Peña: Y bueno, si le diéramos otros límites, podría generar 10 000 casos a todos los que queramos. No nos cuesta nada.


149
00:27:32.416 --> 00:27:35.926
Ricardo Peña: Y luego estos casos se ejecutan.


150
00:27:36.206 --> 00:27:38.845
Ricardo Peña: y aquí te da los casos erróneos.


151
00:27:39.126 --> 00:27:46.465
Ricardo Peña: Y bueno, en este caso es 0, con lo cual, con muy poquito esfuerzo, Bueno, aquí tenéis el programa Haskell, que es muy parecido al


152
00:27:46.646 --> 00:27:55.845
Ricardo Peña: Este viene del transformado del que os he puesto antes, el mío. El de entrada es este, que ya veis que es una especie de lisp, una cosa extraña, una cosa funcional.


153
00:27:56.156 --> 00:28:01.276
Ricardo Peña: y esta sería la parte, la cosa ejecutable, que es una transformación.


154
00:28:01.626 --> 00:28:05.545
Ricardo Peña: Bueno, Lo que quiero decir es que si 1 tiene


155
00:28:05.716 --> 00:28:10.305
Ricardo Peña: pre condición y poscondición, puede generar con esfuerzo 0


156
00:28:10.906 --> 00:28:38.685
Ricardo Peña: miles de casos de prueba, ejecutarlos y comprobarlos de manera automática y, además, que de alguna manera son exhaustivos, no exhaustivos dentro de unos límites de tamaño, con lo cual, bueno, pues la probabilidad de que luego haya errores para casos más grandes, pues la verdad es que es pequeña, salvo que el programa esté hecho de una manera un poco rara. Bueno, me estoy yendo de tiempo, me parece. Pasamos al


157
00:28:39.276 --> 00:28:40.036
Ricardo Peña: a ver


158
00:28:40.646 --> 00:28:42.176
Ricardo Peña: un momentito.


159
00:28:43.876 --> 00:29:03.125
Ricardo Peña: Sí, Bueno, en el libro también habla del qué son casos de pruebas para programas concurrentes? No, esto ya es más difícil porque los programas concurrentes, como sabemos, tienen problemas de exclusión mutua. Los casos compartidos, desbloqueos, injusticia o inanición que hay procesos que son postergados


160
00:29:03.346 --> 00:29:17.676
Ricardo Peña: indefinidamente entonces los casos de prueba normalmente consisten en lo que llamamos un escenario donde intervienen varios procesos y varias primitivas de sincronización y aquello se ejecuta.


161
00:29:18.036 --> 00:29:32.376
Ricardo Peña: Y Bueno, si tenemos un fichero de bitácora que va registrando la traza de los eventos, pues si aquello falla podemos reconstruir. ¿qué es lo que ha pasado? ¿no? Pero bueno, sabemos que son no deterministas, con lo cual, si aparece un error.


162
00:29:32.386 --> 00:29:58.066
Ricardo Peña: volverlo a reproducir. Probablemente es difícil porque las velocidades de los procesos cambian, y seguramente la traza de los eventos será diferente. Bueno, todos los que hayan trabajado en concurrencia saben que hacer testing de congruencia todavía es más difícil y todavía es peor, y todavía es menos definitivo o menos resolutivo que hacer de programas secuenciales. No, Bueno, esto sobre el testing. Pasamos a lo que iba a lo que iba a decir.


163
00:29:58.096 --> 00:30:04.276
Ricardo Peña: Bueno, no sé cuánto tiempo tengo. Fernando. Yo había previsto una hora y cuarto. Está bien.


164
00:30:06.006 --> 00:30:07.936
Ricardo Peña: Fernando.


165
00:30:08.336 --> 00:30:11.386
Fernando Orejas Valdés: Me pongo el sonido. Ya me lo he puesto


166
00:30:13.746 --> 00:30:14.606
Fernando Orejas Valdés: perdona.


167
00:30:14.766 --> 00:30:16.486
Ricardo Peña: Una hora. Y cuarto, está bien.


168
00:30:16.706 --> 00:30:24.586
Fernando Orejas Valdés: Bueno, en principio es una hora. Tómate lo que quieras. Lo que te puede ocurrir es que se te vaya parte de la audiencia.


169
00:30:24.936 --> 00:30:43.936
Ricardo Peña: Bueno, no os voy a aburrir. Voy a intentar ajustarme a una licuarto. Es que veréis que hay mucho material, porque este libro, aunque ya he dicho que es de divulgación, pero realmente cubre muchas cosas y tiene muchos ejemplos. Y, en fin, aunque he hecho una selección, pero hay mucho que ver. Bueno, el análisis estático


170
00:30:44.076 --> 00:31:10.955
Ricardo Peña: en los que no conozcáis. Supongo que todos lo conocéis. Pero Bueno, el análisis estático consiste en procesar la parte estática de un programa, o sea, el texto, y a partir de ahí, deducir conclusiones o deducir propiedades que lo con la a diferencia del testing en el testing, solo aseguramos que funcionan bien los casos que probamos, no decimos nada sobre los que no probamos el análisis estático. Cuando se saca una propiedad, se deduce una propiedad.


171
00:31:11.206 --> 00:31:19.835
Ricardo Peña: Lo importante es que se satisface en todas las ejecuciones, con lo cual no hay que probar nada, Simplemente ya te da esa propiedad para todas las ejecuciones.


172
00:31:20.016 --> 00:31:21.906
Ricardo Peña: Bueno, entonces una de ellas


173
00:31:22.046 --> 00:31:27.686
Ricardo Peña: importante sería la terminación no saber que los bucles terminan o las llamadas recursivas terminan.


174
00:31:28.086 --> 00:31:38.205
Ricardo Peña: Bueno, pues, como ya dijo Turing en su momento en el año 36, el problema de parada de las máquinas de turing. No existe un algoritmo general que decida la terminación de los buques


175
00:31:38.906 --> 00:31:46.475
Ricardo Peña: y, por tanto, pues, esperar que un análisis estático nos detecte en el caso general, la terminación de todos los bucles, pues no es esperable.


176
00:31:46.886 --> 00:32:04.275
Ricardo Peña: Bueno, entonces la determinación manual, como bien sabemos, pues consiste en encontrar una función de acotación que haga una correspondencia entre las variables del bucle y un orden bien fundado que suele ser el subconjunto de los enteros no acotados inferiormente.


177
00:32:04.666 --> 00:32:26.815
Ricardo Peña: Y bueno, aquí tenéis un programa que calcula el logaritmo entero de un valor. Y Y lo que va haciendo es empieza con n igual a 0, Y la X empieza en 2. La X se va duplicando. Y entonces en N, tenemos siempre el logaritmo de X, menos 1. Entonces, cuando la X se hace más grande que la I, el valor anterior, o sea, lo que lleva la n es el logaritmo que buscamos.


178
00:32:26.896 --> 00:32:49.786
Ricardo Peña: Entonces, una posible función de acotación sería esta que digo aquí, y menos X que se mantiene mayor que 0 mientras itera. Y como la X se duplica. Y la I no cambia, pues decrece. No, El problema de hacerlo manualmente consiste en encontrar estas funciones de acotación, Como bien sabemos. Pero claro, eso no siempre es posible, incluso para un humano.


179
00:32:49.906 --> 00:32:51.525
Ricardo Peña: Mirad esta función


180
00:32:51.786 --> 00:33:21.446
Ricardo Peña: que lo que hace es, Le damos una n. Si la N es menor, igual que 1 termina. Pero si es mayor que 1 mira a ver si es par o impar, si es par, la divide por 2. Y si es impar la multiplica por 3 y le suma 1. Entonces, si N es potencia de 2, pues todo el tiempo, o sea, dividirse por 2. Va siendo par excepto cuando divides la última vez de 2 a 1, y entonces sale con un valor que es 1 que es menor, o sea, que no es mayor que 1 y, por tanto, termina ese potencia de 2. Seguro que acaba.


181
00:33:21.626 --> 00:33:44.166
Ricardo Peña: Pero si es impar, por ejemplo, si es 7, pues la secuencia de valores es 7, se divide por 2. Es 3, 3, por 7 21 más 1 22 es 7 22 de ahí pasa a 11 de 11 pasa a 34 de 34 pasa a 17 52, o sea, que el valor sube baja, sube baja. Parece que va creciendo y no se sabe si termina o no


182
00:33:44.386 --> 00:33:51.975
Ricardo Peña: bueno realmente para n igual a 7. Os puedo asegurar que termina. Y para muchos valores de N se ha probado y termina, pero nadie ha probado


183
00:33:52.186 --> 00:34:14.466
Ricardo Peña: que termine para todo N. Por eso es una conjetura que hizo un tal collage en los años 50 y tantos. Y es una conjetura que dice que sí, que termina para todo. N, Pero nadie lo ha demostrado hasta ahora. O sea que si en todos esos años, en más de 50 años o 70 años. Nadie lo ha demostrado, pues veréis que demostrar que los bucles acaban incluso para un humano es difícil, ¿no?


184
00:34:15.026 --> 00:34:24.256
Ricardo Peña: Pero bueno. Se ha dedicado mucho esfuerzo al tema de la terminación y se han visto. O sea, que, aunque el problema general sabemos que no hay un algoritmo.


185
00:34:24.326 --> 00:34:39.515
Ricardo Peña: pero ahí sí que hay multitud de casos particulares que se puede detectar la terminación de forma automática y, curiosamente, los casos particulares coinciden con la mayoría de los bucles que los programadores hacen los programadores no suelen hacer bucles como este tan horroroso, no.


186
00:34:39.576 --> 00:35:06.005
Ricardo Peña: Y entonces, si una herramienta cure, digamos, el 90 por 100 de los casos o el 99 por 100 de los casos, pues al programador le quedaría probar manualmente unos poquitos casos, con lo cual, a efectos prácticos, podríamos decir que el problema de la terminación está casi resuelto. Lo único es que tenemos que estar preparados para que las herramientas nos digan que no saben que no saben si termina o no, o sea, el valor and Know.


187
00:35:06.116 --> 00:35:18.755
Ricardo Peña: Y bueno, pues esos casos los resolveríamos manualmente. Bueno, pues la interpretación abstracta, o sea el análisis y determinación, podríamos verlo como una parte del análisis estático. Pero lo que voy a hablar es de la interpretación abstracta.


188
00:35:19.056 --> 00:35:32.326
Ricardo Peña: Sería algo parecido a lo que acabo de contar con la terminación. O sea, se trata de tratar de ver si se cumple una propiedad, pero estar preparado para decir, pues no sé si se cumple o no, o sea, ni se cumple ni no se cumple. No lo sé.


189
00:35:32.486 --> 00:35:37.426
Ricardo Peña: Entonces, lo que hace esto se inventó en los años 70 por los las el matrimonio Cussot


190
00:35:37.756 --> 00:35:44.326
Ricardo Peña: y representa un compromiso entre decidir la propiedad y hacerlo con precisión.


191
00:35:44.406 --> 00:36:05.766
Ricardo Peña: Entonces la menor precisión es decir, que no sabes nada. Pero a veces sabes algo, y lo puedes decir. Os pongo aquí un ejemplo, un análisis que es bueno saber con qué signo acaban las variables enteras de un programa, ¿no? Entonces lo que hace el analizador o el intérprete, porque la interpretación abstracta vendría a ser como una ejecución del programa.


192
00:36:05.766 --> 00:36:15.105
Ricardo Peña: Pero en lugar de sobre el dominio normal semántico lo hace sobre un dominio abstracto que suele ser frecuentemente es finito.


193
00:36:15.126 --> 00:36:25.006
Ricardo Peña: Por ejemplo, los enteros. Si nos interesa saber si acaban siendo positivos, negativos o 0. Pues dividimos los enteros en 3 valores abstractos, mejor dicho, en 4,


194
00:36:25.066 --> 00:36:27.716
Ricardo Peña: o mejor dicho, en 5, porque hay un quinto que no está aquí,


195
00:36:27.836 --> 00:36:33.305
Ricardo Peña: que serían los que llamamos N, que son los todos los negativos los que llamamos Z, que es el 0


196
00:36:33.416 --> 00:36:53.425
Ricardo Peña: lo que llamamos P, que son todos los positivos. Y luego este top que representa que no sé nada. ¿sabes? Cualquier entero que no sé si es positivo o negativo o 0. Hay un cuarto que es bottom, que sería que es un error, un entero, un entero, o sea, el conjunto vacío de enteros, pero no lo muestro aquí para no complicar. Entonces nos la suma abstracta.


197
00:36:53.546 --> 00:37:03.145
Ricardo Peña: tenéis aquí. Esta tabla es conmutativa, con lo cual la matiz es simétrica. Entonces me fijo nada más en las filas. Por ejemplo.


198
00:37:03.516 --> 00:37:06.966
Ricardo Peña: sabemos que la suma de 2 negativos da un negativo.


199
00:37:07.146 --> 00:37:21.036
Ricardo Peña: Entonces, N es N, la suma de negativo. Da negativo. La suma de negativo más positivo. No sabemos lo que da porque depende del valor concreto o no. Entonces ahí decimos: Toc es cualquier entero


200
00:37:21.386 --> 00:37:47.625
Ricardo Peña: Luego 0. Bueno, aquí están los simétrico ¿no? Cero, con negativo negativo 0, los positivos es positivo, con con negativo. No sabemos lo que da positivo, con 0 o positivo con positivo es positivo? ¿no? Y lo mismo para la multiplicación abstracta no que sería negativo por negativo. Es positivo, negativo por 0 es 0, negativo. Por negativo, es es perdón, negativo por negativo, es perdón, negativo por positivo, es negativo


201
00:37:47.626 --> 00:37:57.746
Ricardo Peña: y bueno, toda la tabla la tenéis aquí. Entonces, el analizador abstracto, lo que hace es ejecutar el programa sobre estos dominios


202
00:37:57.936 --> 00:38:19.325
Ricardo Peña: y tiene operaciones abstractas que corresponden a la suma, la multiplicación. Podríamos hacer lo mismo con la Resta, con la división y entonces lo ejecuta. Y al final, si una variable termina con N, pues sabemos que termina siendo negativa si termina con P. Sabemos que es positiva y termina con Z. Sabemos que es 0 y termina con Top, pues no sabemos nada. Esa es un poco la


203
00:38:19.476 --> 00:38:46.285
Ricardo Peña: la idea, ¿no? Entonces los dominios abstractos tienen que cumplir ciertas propiedades. Bueno, tiene que tener una estructura del retículo. Tiene que haber un orden parcial entre ellos, que representa la precisión. Tiene que haber un valor top, que es el Arnon, que es el que es el máximo del retículo, un valor botom que es el mínimo todo conjunto debe tener un supremo que es la menor cota superior, una serie de restricciones que son los retículos.


204
00:38:46.426 --> 00:39:14.645
Ricardo Peña: Luego se definen unas funciones que permiten convertir del dominio del dominio concreto al abstracto. La función de abstracción, la gama sería la de que la la contraria que coge un valor abstracto, lo convierte en lo concreto y tiene que cumplir ciertas propiedades. Estas 2 Alfa y Gamma, que en esencia, es que si vamos de lo concreto a lo abstracto y luego volvemos a lo perdón. Si vamos de lo abstracto a lo concreto. Y luego volvemos


205
00:39:15.426 --> 00:39:29.306
Ricardo Peña: a lo abstracto. No podemos bajar en el retículo. Tenemos que quedarnos, o bien en el punto de partida, o bien más arriba, o sea, perdemos precisión de la propiedad. Eso es eso. Se llama una conexión de la lois.


206
00:39:29.966 --> 00:39:36.755
Ricardo Peña: Bueno, y la interpretación, La función de interpretación que convierte el dominio semántico


207
00:39:36.986 --> 00:39:59.035
Ricardo Peña: concreto. El dominio semántico abstracto tiene que ser monótona, es continua, sin fin, es decir, una serie de condiciones que hacen que cuando encontramos un bucle en el programa, esos bucles iteran también en la interpretación abstracta, Pero la iteración siempre termina y además termina con unos valores estables. Y, además, los resultados que da el análisis son correctos. ¿no?


208
00:39:59.196 --> 00:40:11.165
Ricardo Peña: Entonces 1 de los retículos más sencillos es un conjunto finito de valores. Por ejemplo, aquí tenemos un conjunto de valores A, B y C. Entonces el Top sería todos ellos


209
00:40:11.356 --> 00:40:28.066
Ricardo Peña: el los que están debajo son más precisos porque A, B es un subconjunto de A, B, C o a C. Subconjunto. Los que están debajo todavía son más precisos, ¿no? Y Y bueno, pues esto sería un retículo


210
00:40:28.656 --> 00:40:52.956
Ricardo Peña: en el cual se puede hacer interpretación abstracta, entonces los dominios son muy variopintos, no el el más corriente. Es este que digo conjuntos finitos de cosas. No qué cosas puede haber en un programa, pues puede haber variables. Puede haber expresiones. Entonces, por ejemplo, el análisis que se llama de variables vivas, que es saber si una variable va a ser usada en el futuro o no, y que eso viene muy bien para minimizar el número de registros que se usan de la máquina.


211
00:40:52.956 --> 00:41:08.405
Ricardo Peña: pues lo que hace es llevar conjuntos de variables. Y entonces, al final te dice si las variables están vivas o no están vivas y entonces los conjuntos finitos de variables se pueden organizar como un retículo, como como acabamos de ver, No, pero hay dominios más interesantes. Por ejemplo, intervalos.


212
00:41:08.626 --> 00:41:20.495
Ricardo Peña: ese que os he dicho de se puede llevar un intervalo que representa el valor mínimo y el máximo que puede tomar una variable entera o una variable en coma flotante. No entonces la relación de orden es la inclusión.


213
00:41:20.826 --> 00:41:23.456
Ricardo Peña: o sea, que un intervalo está incluido en otro.


214
00:41:23.766 --> 00:41:52.456
Ricardo Peña: el top sería el intervalo máximo, que es de menos infinito a más infinito, con lo cual no sabemos nada. El supremo es el menor intervalo, o sea, la cota, La menor cota superior de 2 intervalos es el menor intervalo que engloba a ambos, con lo cual ahí perdemos precisión no porque puedes incluir valores que no estaban en ninguno de ellos. Bueno, y esto funciona, pues, para hacer análisis de tamaño, no de de qué tamaño pueden alcanzar las las variables hubiera venido bien para el arial. Cinco.


215
00:41:52.816 --> 00:42:08.485
Ricardo Peña: Luego están los octógonos, que representan relaciones binarias entre 2 variables que se pueden representar como rectas en un plano como 8 rectas en un plano. Y entonces engloban una porción del plano que es un octógono. La relación de orden es la inclusión.


216
00:42:08.596 --> 00:42:33.466
Ricardo Peña: El ínfimo es la intersección de 2 octogonos que en el caso general de un octógono y el supremo es el menor octógono que engloba los argumentos, no. O sea que con eso se pueden construir regiones del plano que representan que los puntos representan relaciones posibles entre 2 variables. No se puede ampliar a relaciones en áreas entre variables. Esto viene muy bien, por ejemplo, para ver los límites de los índices de un arrai cosas de este estilo.


217
00:42:33.646 --> 00:42:56.575
Ricardo Peña: entonces son restricciones lineales de esta forma que están puestas aquí, que representan. Si fuera un plano, si fueran 2 variables, representaría un poliedro perdón, un polígono convexo, si es en si son n variables, pues sería un poliedro converso en un espacio unidimensional. No se puede haber la relación de órdenes de inclusión. Otra vez, la la


218
00:42:56.786 --> 00:43:00.605
Ricardo Peña: el ínfimo es en la intersección. Bueno, son parecidas a los de los octogonalos


219
00:43:00.766 --> 00:43:15.646
Ricardo Peña: y otra más. Otro dominio que este se emplea. No sé si alguno conocéis un lenguaje que se llama Liquid Haskell Haskell líquido. Los tipos líquidos, eso se hacen también una interpretación abstracta en un dominio de predicados.


220
00:43:15.746 --> 00:43:39.375
Ricardo Peña: Entonces aquí la relación de orden y la implicación, o sea, un predicado más restrictivo que otro. Se supone que es más preciso. El voto no es el falso, o sea, el predicado que implica a todos el Top es el cierto, el predicado que es implicado por todos. El supremo es la unión y el ínfimo es la intersección. Estos versículos. Yo los he usado porque hicimos una hicimos algún trabajo sobre tipos líquidos.


221
00:43:39.486 --> 00:43:43.216
Ricardo Peña: Y bueno, vienen vienen bastante bien, ¿no? Bueno. Entonces


222
00:43:43.556 --> 00:44:07.056
Ricardo Peña: lo importante es que esto no es pura teoría, sino que se usa en la vida industrial. No es frecuente que se creen empresas a partir de grupos de la universidad. Por ejemplo, Abstint es un grupo, una spin off de la Universidad de Salbrücken. La persona relevante aquí es Reinhardt Reinhard Wilhelm


223
00:44:07.266 --> 00:44:10.606
Ricardo Peña: que creo que estará jubilado más o menos por esta fecha.


224
00:44:10.826 --> 00:44:24.736
Ricardo Peña: Y esta herramienta se usaba para lo que llaman análisis de tiempos. En el caso peor. Works case asecution time que lo que hacen es, se aplica a sistemas, vaya por Dios a sistemas de tiempo real.


225
00:44:25.036 --> 00:44:37.595
Ricardo Peña: Y lo que intentan es sacar una cota superior a tiempo real de la ejecución de un programa. Y bueno, se usa, pues para temas tan se ha usado para certificar el software, por ejemplo, del Airbus, 380


226
00:44:37.716 --> 00:44:45.186
Ricardo Peña: de algunos modelos de Toyota. En fin, que esto ha tenido implicación práctica bastante importante.


227
00:44:45.356 --> 00:44:50.165
Ricardo Peña: Y Apps Team también comercializa una herramienta que la hicieron los Cussot, que es Astrid.


228
00:44:50.286 --> 00:44:59.626
Ricardo Peña: que esta detecta desbordamiento de memoria usa Bueno, usa los los


229
00:44:59.816 --> 00:45:08.576
Ricardo Peña: dominios de intervalos que os he dicho para saber los límites de las variables y detecta por tanto, desbordamiento de memoria porque se emplean valores más grandes.


230
00:45:08.686 --> 00:45:17.596
Ricardo Peña: ¿tiene alguna aplicación en la concurrencia o exclusión mutua entre bloqueos y se ha usado también en Airbus y en automoción. No.


231
00:45:17.816 --> 00:45:42.915
Ricardo Peña: Julia es una empresa creada a partir de la Universidad de Verona. La persona relevante aquí es Fausto spoto para programas en Java y para el sistema Android. Estas, en un cierto momento, se fue absorbida por una empresa más grande en 2 000, Quince, y bueno, se ha usado para hacer análisis de software, de bancos, de compañías de seguros, de industria de la automoción también.


232
00:45:43.256 --> 00:45:56.985
Ricardo Peña: O sea que también es frecuente que las empresas, estas y tienen éxito sean absorbidas por empresas más grandes. Es también el caso de Facebook. Inferir infere fue una herramienta hecha por Peter o heen. Y este, cómo se llama John Reynolds.


233
00:45:57.376 --> 00:46:05.325
Ricardo Peña: basada en lo que llaman lógica de separación que no me da tiempo a contar lo que es, pero que sirve para razonar sobre el hip. El hip es una


234
00:46:05.526 --> 00:46:20.006
Ricardo Peña: zona de memoria compartida que da lugar a muchos problemas para razonar sobre ellos. Entonces, esta herramienta, pues podía detectar punteros nulos, lo que llamamos punteros descolgados, fugas de memoria, o sea, zonas del Hip que no se pueden acceder.


235
00:46:20.356 --> 00:46:24.786
Ricardo Peña: Y bueno, tuvo tanto éxito que la compró Facebook en el año.


236
00:46:25.326 --> 00:46:28.126
Ricardo Peña: A ver, lo tengo por aquí en el año.


237
00:46:28.386 --> 00:46:30.586
Ricardo Peña: Dos 1 009


238
00:46:31.276 --> 00:46:32.696
Ricardo Peña: la compró.


239
00:46:32.826 --> 00:46:44.206
Ricardo Peña: También se había empleado antes para a R. M, que es un un productor de semiconductores para Airbus, y luego Facebook las la ha usado en todo su desarrollo, o sea, que Instagram y Whatsapp.


240
00:46:44.336 --> 00:46:56.685
Ricardo Peña: Todo esto funciona y la y la se la ha alquilado, por decirlo así, a la mozilla Spotify, o sea, que muchas de las aplicaciones que usamos han pasado por aquí por Facebook


241
00:46:56.786 --> 00:47:15.876
Ricardo Peña: y han detectado muchos errores y luego una muy cercana a mí que es costa que significan las siglas. Cost Analysity análisis de The Constant Termination análisis análisis determinación y de coste que está la persona líder del proyecto Es Elvira Albert.


242
00:47:16.096 --> 00:47:26.686
Ricardo Peña: que la conoceréis muchos. Y esta infiere terminación y expresiones simbólicas de coste para programas escritos en Baikhood Baicon de tejada.


243
00:47:26.826 --> 00:47:51.546
Ricardo Peña: Y bueno, estas de uso libres. En fin, se la puede usar quien quiera y luego han aplicado una versión de ella para la plataforma de contratos inteligentes de la cadena de bloques Ethereum, y ahí no sé si sabéis, pero los contratos tienen una un recurso. Se llama gas que vendría a equivaler a digamos, tiempo, de co tiempo de cómputo.


244
00:47:51.676 --> 00:48:01.065
Ricardo Peña: y se trata, si un contrato tarda más en ejecutarse o consume más gas del que ha pagado por él, pues se aborta la transacción.


245
00:48:01.546 --> 00:48:16.056
Ricardo Peña: Entonces es muy interesante tener una herramienta que te dé una cota superior al consumo de gas, porque así solo compras el gas necesario, nunca más del necesario. Y Además, nunca te vas a quedar sin gas, ¿no? Y nunca te van a


246
00:48:16.476 --> 00:48:17.586
Ricardo Peña: abortar


247
00:48:18.006 --> 00:48:22.975
Ricardo Peña: tu contrato. ¿no? Bueno, pues esto serían herramientas. Vale.


248
00:48:23.696 --> 00:48:27.135
Fernando Orejas Valdés: Ricardo si sigues Así puede que tardes más de.


249
00:48:27.136 --> 00:48:27.956
Ricardo Peña: No, no.


250
00:48:27.956 --> 00:48:28.746
Fernando Orejas Valdés: Lo que.


251
00:48:29.156 --> 00:48:31.286
Ricardo Peña: Llevo una hora, menos 10 min.


252
00:48:31.446 --> 00:48:32.575
Fernando Orejas Valdés: Sí. Por eso.


253
00:48:32.886 --> 00:48:37.246
Ricardo Peña: No, no que va que va, ya verás que como no, la parte final es más rápida.


254
00:48:37.796 --> 00:48:41.795
Ricardo Peña: Bueno, la verificación de modelos concurrentes.


255
00:48:42.556 --> 00:48:56.945
Ricardo Peña: Bueno, con la interpretación, la interpretación abstracta tiene una ventaja muy buena, que es automática, pero el problema es que el tipo de errores que detecta son errores, más bien de decodificación que el puntero es nulo, punteros descolgados, división por 0.


256
00:48:57.096 --> 00:49:11.455
Ricardo Peña: Entonces se necesitan Si 1 quiere detectar errores de diseño, necesitamos otro tipo de herramientas, en particular los sistemas concurrentes, pues sabemos que dan lugar a escenarios muy complejos y entonces probar todas las combinaciones


257
00:49:11.906 --> 00:49:21.276
Ricardo Peña: de eventos en cuanto hay unos pocos procesos y unos pocos eventos por procesos salen muchos miles de combinaciones y no se pueden hacer de manera manual. ¿no?


258
00:49:21.386 --> 00:49:33.826
Ricardo Peña: Entonces ahí sería un buen sitio donde haría falta análisis automático, entonces una posible vía de escape. Es lo que se llama construir modelos concurrentes que son una versión simplificada, abstracta


259
00:49:33.916 --> 00:49:37.045
Ricardo Peña: del programa que vamos a construir.


260
00:49:37.076 --> 00:49:50.276
Ricardo Peña: Y solo se muestran los detalles relevantes, por ejemplo, de la sincronización, los comportamientos esenciales. Y con un poco de suerte, el modelo es finito y se puede analizar con herramientas.


261
00:49:50.276 --> 00:50:10.786
Ricardo Peña: Entonces, ¿qué tipo de propiedades nos interesan en concurrencia? Pues básicamente, 2, lo que llamamos propiedades de seguridad, por ejemplo, el tema de la exclusión mutua, o sea, que algo malo nunca va a suceder nunca. Va a haber 2 procesos a la vez en una región crítica y de vitalidad, que es que algo bueno sucederá. O sea que si yo, por ejemplo, pido permiso para usar un recurso


262
00:50:10.826 --> 00:50:13.865
Ricardo Peña: en un tiempo finito. Se me concederán


263
00:50:13.996 --> 00:50:22.135
Ricardo Peña: entonces, mientras que la lógica ordinaria podía ser útil para probar propiedades de seguridad que vienen a ser una especie de invariantes


264
00:50:22.346 --> 00:50:45.825
Ricardo Peña: para la vitalidad, no sirven porque la vitalidad habla de cosas que sucederán en el futuro y la lógica normal no conoce ni de pasado ni de futuro. Entonces aparece la necesidad. Lo que llamamos lógica temporal es que es razonar sobre el paso del tiempo, ¿no? Entonces estas lógicas existían ya desde los años 50, pero se empezaron a aplicar a los programas en los años 80.


265
00:50:45.986 --> 00:50:54.625
Ricardo Peña: Entonces los operadores básicos son estos 2, que es el All White, P, que es que algo se va a cumplir la propiedad P se va a cumplir siempre


266
00:50:54.756 --> 00:51:19.296
Ricardo Peña: y la eventual Ip, que es que algo se cumplirá con seguridad en el futuro finalmente se cumplirá. Se cumplirá. P y estas afirmaciones se refieren a secuencias infinitas de ejecución de un sistema concurrente, o sea que el Always Pes es que en una secuencia infinita se cumplen todos los Estados de la secuencia y el eventual Ip es que en algún momento de la secuencia se cumplirá. No


267
00:51:19.746 --> 00:51:40.006
Ricardo Peña: se entiende por Estado el producto cartesiano de Estado de los procesos. Es decir, tenemos un proceso, 1 que pasa por 3 Estados, ese 1, 1, ese 1, 2, s, 1, 3, pues ese se puede ejecutar por la por aquí por la rama izquierda del árbol. Cuando acaba de escoger, vuelve al S 1 1 si es un proceso cíclico y tenemos otro, que es ese 2, 1 y s 2,


268
00:51:40.116 --> 00:51:51.796
Ricardo Peña: pues se puede ejecutar, pero también se pueden hacer cualquier entrelazado. Se ejecuta un paso del 1, un paso del 2, un paso del 1. Bueno, entonces las trazas serían todos los caminos de ejecución


269
00:51:51.906 --> 00:51:54.095
Ricardo Peña: a raíz de que se pueden


270
00:51:54.486 --> 00:52:02.125
Ricardo Peña: construir a partir de este árbol. Este árbol, en este caso es un árbol binario, pero si hay más procesos, pues sería en general.


271
00:52:02.406 --> 00:52:03.626
Ricardo Peña: Bueno.


272
00:52:03.826 --> 00:52:09.605
Ricardo Peña: entonces hay una lógica de las más sencillas. Se llama lógica temporal lineal.


273
00:52:09.846 --> 00:52:17.815
Ricardo Peña: que se refieren a una sola secuencia de ejecución. Si queremos hablar de todas las secuencias, se pueden cuantificar mediante un operador all


274
00:52:17.996 --> 00:52:29.566
Ricardo Peña: o un operador. Existe fijaos aquí estas fórmulas que hay por aquí, Por ejemplo, para toda secuencia Eventual Ipeo quiere decir que p sucederá inevitablemente en alguna secuencia. En toda secuencia en el futuro.


275
00:52:29.726 --> 00:52:59.215
Ricardo Peña: O Always P, Pues que pese inmanente en todos los Estados, pues se pone a expresar cosas muy complicadas. Por ejemplo, aquí la penúltima dice que siempre se cumple para la para todas las secuencias siempre se cumple. Esta implicación es que si en algún instante de la secuencia se cumple p más adelante eventual, se cumplirá con seguridad, no. O sea, que esto permite expresar relaciones causales entre Estados del sistema? ¿no?


276
00:52:59.556 --> 00:53:13.806
Ricardo Peña: Bueno, pues con esta lógica se pueden verificar modelos. Ahora sólo falta una herramienta. ¿no? Entonces estos autores que tenéis aquí. Emerson Clarke y Shifakis son los inventores del model check In.


277
00:53:13.906 --> 00:53:35.526
Ricardo Peña: Entonces la aportación es representar el sistema como un grafo dirigido, o sea, como en lugar de como un árbol, pues como un grafo que frecuentemente es finito. Entonces los caminos infinitos corresponden a los ciclos a los ciclos del Grafo, Entonces, al disponer de un modelo finito, pues todos los problemas pasan a ser decidir, por ejemplo, si queremos probar una propiedad


278
00:53:35.916 --> 00:53:52.726
Ricardo Peña: del tipo Always P, Pues sería ver todos los Estados del Grafo y ver si todos ellos se cumple p o eventual Ip: Pues ver todos los caminos a partir de un estado dado sin repetir. Bucks, sin hacer bucles simplemente caminos simples y ver si se cumplen todos los caminos.


279
00:53:53.126 --> 00:53:59.815
Ricardo Peña: Vale entonces para hacer un verificador de modelos. Necesitamos 2 cosas: un lenguaje para expresar el modelo.


280
00:53:59.966 --> 00:54:06.506
Ricardo Peña: un lenguaje similar al lenguaje de programación y un lenguaje de lógica temporal para expresar las propiedades.


281
00:54:06.696 --> 00:54:20.006
Ricardo Peña: entonces el caso de los las herramientas en caso de encontrar un error. No solo te dicen que hay un error, sino, te dicen, el camino más corto que conduce al error, con lo cual son bastante útiles para hacer depuración.


282
00:54:20.436 --> 00:54:31.585
Ricardo Peña: Y claro, el punto débil es que en cuanto el modelo tenga muchos procesos o muchos Estados por proceso, pues se produce una explosión combinatoria y el modelo es inmanejable. ¿no? Entonces


283
00:54:31.986 --> 00:54:41.846
Ricardo Peña: vamos a hablar un poco, como ya hemos visto en la lógica temporal. ¿qué modelos hay? Uno de los más antiguos es las redes de Petri que lo voy a explicar antes a


284
00:54:41.986 --> 00:55:00.126
Ricardo Peña: a detener, a explicarlas, pero básicamente, pues hay unos Estados unas marcas, Hay una parte estática que sería la red en sí, que es un grafo y una parte dinámica que son, cómo progresan como estas marcas. Entonces la regla de disparo es que solo se dispara una transición a la vez


285
00:55:00.306 --> 00:55:10.785
Ricardo Peña: y la para dispararla tiene que estar al menos una marca en todos los lugares de entrada a la transición. Como veis aquí en X, 1 se cumple eso. Y en X 2 también.


286
00:55:10.976 --> 00:55:38.956
Ricardo Peña: Y es el disparo, consiste en de traer una marca de cada lugar de entrada y poner una marca en la de salida. Y luego son no deterministas. Aquí ves, por ejemplo, que la marca que está en ese se ha ido hacia la izquierda, por decirlo así, y la entonces se ha disparado la transición X 1 y la X 2 ha quedado inhabilitada, ¿no? Entonces, bueno, esto podría representar una exclusión mutua, una manera de representar la exclusión mutua del proceso. P: 1 del proceso. P. Dos.


287
00:55:39.206 --> 00:55:57.905
Ricardo Peña: Si los lugares, el número de marcas de cada lugar se demuestra que está acotado, o sea que no se pueden acumular un número infinito de ellas, pues esto da lugar a un grajo finito de Estados y las propiedades son decidibles, pero si se acumulan más dn marcas, o sea, si un número infinito de marcas, pues tal cosa no.


288
00:55:58.156 --> 00:56:25.735
Ricardo Peña: Y bueno, son muy intuitivas. Hay muchas herramientas sobre ellas, pero no luego convertir eso en un programa concurrente no es fácil. Ni siquiera tienen una noción de proceso. Otra alternativa serían lo que llaman las álgebra de procesos. Aquí. Os cuento la de Csp, que es concurre en Communicating sequential process debido a Tony Hall en el año. 1 980.


289
00:56:25.806 --> 00:56:43.785
Ricardo Peña: Entonces aquí es una álgebra donde los elementos son procesos. Los valores del álgebra son procesos y los operadores del álgebra, pues son la constante stop que representa el proceso parado, la El operador flecha, que da un evento a las minúsculas. Son eventos


290
00:56:43.786 --> 00:57:03.286
Ricardo Peña: y luego sigue con un proceso. Sería el operador prefijo la diversa manera de componer procesos en secuencia no determinista determinista. En paralelo con interacción, bueno, lectura de canales hay un montón de operadores y hay un montón de leyes que cumplen esos operadores. Por eso es un álgebra, ¿no?


291
00:57:03.676 --> 00:57:22.085
Ricardo Peña: Entonces, por ejemplo, si quisiéramos hacer una máquina de estas que tú le echas un euro y tienes botones para decidir qué quieres de esta le echas un euro y puede decidir de manera determinista entre darte una chocolatina o darte una galleta, y luego se vuelve al punto de partida, ¿no?


292
00:57:22.096 --> 00:57:50.505
Ricardo Peña: Y luego este proceso u representa un usuario que solo está interesado en las chocolatinas, esté hecha a un euro y espero la chocolatina. Y luego vuelvo al estado de partida. Entonces, si las componemos en paralelo, se sincronizan por los eventos comunes que serían el euro y la chocolatina, y se puede demostrar que por las leyes del álgebra que en realidad la composición paralela debe con U se comporta como U como un usuario, ¿no? Bueno, pues este es el álgebra Csp. Con esto se pueden hacer modelos.


293
00:57:50.556 --> 00:57:54.126
Ricardo Peña: y se puede hacer. Model Check in con estos modelos.


294
00:57:54.186 --> 00:58:00.725
Ricardo Peña: Otro más es el que llaman promela que esto lo diseñó los laboratorios Bell.


295
00:58:01.526 --> 00:58:14.765
Ricardo Peña: Y entonces estos bromelas se parece bastante a un lenguaje de programación. Tiene el concepto de proceso, el concepto de canales que comunican los procesos. Los canales pueden ser síncronos


296
00:58:14.836 --> 00:58:43.485
Ricardo Peña: o asíncronos. Pero si son así, nos llevan una cola de mensajes que no puede ser infinita, tiene que ser finita Luego tienen tipos de datos enteros, booleanos, vectores, arrays, registros. Bueno, entonces es un lenguaje muy expresivo y valores compartidas. También aquí tenéis el algoritmo de Peterson, que garantiza la exclusión, multa ante 2 procesos aquí están representados. Dos procesos. O sea, este 2 quiere decir que son 2 procesos de este tipo ¿no?


297
00:58:43.696 --> 00:58:47.786
Ricardo Peña: Y, bueno, no voy a contar el algoritmo de Peterson. Pero


298
00:58:48.016 --> 00:59:03.645
Ricardo Peña: en esencia, aquí tenéis asignaciones Arrays. Esto es un If ¿no? Si se cumple esta barrera, se ejecuta lo de dentro. Y si no se cumple la barrera, se queda, se queda paralizado, ¿no?


299
00:59:04.046 --> 00:59:15.175
Ricardo Peña: Bueno, y luego tiene un who, tú. Bueno, se puede hacer bucles, entonces el el problema del promela es que se pueden hacer cosas demasiado expresivas y como se pueden usar arrays y registros.


300
00:59:15.296 --> 00:59:25.325
Ricardo Peña: pues al final, el número de estado del sistema podía llegar a ser excesivamente grande. Si el programador no tiene cuidado, entonces hay un riesgo de construir modelos demasiado complejos, ¿no?


301
00:59:25.466 --> 00:59:40.136
Ricardo Peña: Pero bueno, es una herramienta como veréis luego muy usada. Y luego tiene un verificador que se llama Spin, que es simple, promela, intérprete o algo así que es el que el que procesa todos estos sistemas.


302
00:59:40.246 --> 00:59:51.016
Ricardo Peña: Y yo me voy a centrar, voy a contar un poquito más de T. L a que el libro le dedico bastante que se llama temporal Logic of Action. Este fue desarrollado por leslie lampord que todavía vive


303
00:59:51.186 --> 01:00:19.065
Ricardo Peña: y tiene. Es muy simple: el sistema, o sea, el sistema consta de Estados que son las posibles asignaciones de variables al sistema y luego acciones. Se supone que las acciones son atómicas, las que se ejecutan en exclusión mutua, y cada acción consta de una especie de barrera que es una pre condición. Si no se cumple la precondición, la acción no se puede ejecutar. Y luego, si se ejecuta, hay una relación de transición que dicen cómo se modifican las variables.


304
01:00:19.496 --> 01:00:24.915
Ricardo Peña: vale entonces el orden en que se ejecuta, o sea, si hay varias acciones que están habilitadas que tienen.


305
01:00:24.966 --> 01:00:49.686
Ricardo Peña: cumplen, la precondición se puede ejecutar de manera no determinista. Cualquiera de ellas, Bueno, los tipos enteros son más sencillos. Tiene los tipos de la del lenguaje, solo tiene enteros, buleanos, duplas y secuencias. No tiene más y no tiene bucles ni tiene condicionales, ni tiene nada de esto. Entonces aquí tenéis un ejemplo de un reloj que tiene 3 variables horas, minutos y segundos.


306
01:00:49.746 --> 01:00:52.195
Ricardo Peña: Una acción inicial que las pone a 0


307
01:00:52.266 --> 01:00:58.536
Ricardo Peña: y luego una acción T I, P. Que se supone que pasa un segundo, entonces la


308
01:00:58.776 --> 01:01:16.565
Ricardo Peña: las que están sin tilde son las variables antes de la transición, o sea, que representan la precondición que para que se ejecute esta parte de la acción del número de segundos tiene que ser menor que 59, y entonces los segundos se cambian a 1 más.


309
01:01:17.026 --> 01:01:41.515
Ricardo Peña: Si son igual a 59 los minutos tienen que ser 59 entonces los segundos se ponen a 0, y los minutos se incrementan en 1. Y si es igual a 59 los segundos y los minutos, la hora tiene que ser menor que 23 en ese caso, pues se ponen a 0 todo y la hora se incrementa en 1. Y cuando la hora es 23, todo vuelve al estado de partida, entonces se puede probar que la acción T, I, C siempre está habilitada y que los


310
01:01:42.006 --> 01:01:54.155
Ricardo Peña: las variables están en el rango que 1 espera. Las horas están entre 0 y 23 los minutos antes. Y los segundos entre 0 y 59. Bueno, pues ahí tienes un sistema muy sencillo. Os voy a contar 1 más complicado.


311
01:01:54.366 --> 01:01:57.295
Ricardo Peña: Sí, Bueno, ya voy un poquito mal de tiempo.


312
01:01:57.656 --> 01:02:16.595
Ricardo Peña: pero bueno, no contaré los detalles. Es lo que llaman el protocolo del Bit alternante, donde hay un emisor que está conectado con un usuario que quiere enviar mensajes, un receptor que está conectado con un usuario que se pone, que lo recibe. Y luego hay una red, ¿no? Entonces, en el modelo que estoy construyendo hay 7 acciones


313
01:02:16.886 --> 01:02:19.206
Ricardo Peña: y 7 variables.


314
01:02:19.426 --> 01:02:22.026
Ricardo Peña: Entonces hay 3 variables en la parte del emisor


315
01:02:22.256 --> 01:02:25.956
Ricardo Peña: que son una para contener el mensaje en curso.


316
01:02:26.106 --> 01:02:28.196
Ricardo Peña: el bit de control


317
01:02:28.776 --> 01:02:31.605
Ricardo Peña: de envío y el Bid de control de recepción.


318
01:02:31.876 --> 01:02:38.025
Ricardo Peña: entonces el y el luego la la red se representa por por unas colas de mensajes.


319
01:02:38.156 --> 01:02:42.895
Ricardo Peña: El receptor tiene estas variables aquí: un bit de control, y el mensaje que recibe


320
01:02:42.946 --> 01:03:07.025
Ricardo Peña: y tiene que enviar una confirmación que es este enviar confirmación entonces la idea del Protocolo. Y luego hay otras 2 acciones aquí, que son que de manera aleatoria se pueden perder datos de la cola de mensajes o o reconocimientos de la cola de reconocimiento, con lo cual eso simula los fallos de la red, ¿no? Entonces, el cuando el emisor quiere enviar un mensaje.


321
01:03:07.026 --> 01:03:29.925
Ricardo Peña: envía un mensaje con el bit de control, al valor; contrario, se supone que empieza en 1, entonces lo pone a 0 y envía los mensajes con 0, y y luego la acción de reenvío puede reenviar mientras el Bid de control de envío sea distinto de recepción, sigue enviando el mensaje, muchas veces porque no sabe si se va a perder si se van a perder todos o no se van


322
01:03:29.936 --> 01:03:37.166
Ricardo Peña: entonces en algún momento. Se supone que el receptor lo recibe y contesta con el bit de control que ha recibido con un 0.


323
01:03:37.186 --> 01:03:49.576
Ricardo Peña: Y entonces, mientras el que recibe, mientras el que emite no reciba un 0, sigue reenviando. Cuando le llega un 0. Ya el bit de recepción se pone a 0 y ya está dispuesto para enviar otro mensaje. Vale.


324
01:03:49.646 --> 01:03:56.955
Ricardo Peña: No sé si lo he contado bien, pero bueno que lo reconozcáis conozcáis el protocolo. Lo interesante es que esto es explicado


325
01:03:57.126 --> 01:04:19.716
Ricardo Peña: en tele A, pues es muy poca información. Aquí tenéis las 4 acciones principales, sus precondicciones, sus condiciones. No lo voy a contar porque no me da tiempo. Lo interesante es que se puede hacer que el modelo sea finito, haciendo que la cola de mensajes tenga como mucho un número finito de ellos, por ejemplo, 2, y que el número de mensajes distintos sea como mucho 2.


326
01:04:19.846 --> 01:04:46.706
Ricardo Peña: Y entonces, con esas limitaciones, el modelo de Estado es finito y se pueden probar propiedades de este estilo que siempre se cumple. Esto, que si se acaba de enviar un mensaje, y el Bit de envío es distinto de la recepción en algún momento del futuro. Ese mensaje será recibido por el receptor que esta es la propiedad interesante. O sea que los mensajes al final llegan, ¿no? Y esto lo podemos probar con el con el verificador de T Lea.


327
01:04:47.036 --> 01:04:48.716
Ricardo Peña: Bueno, pues este es el


328
01:04:49.606 --> 01:05:10.126
Ricardo Peña: Este es el modelo de T. L A. Entonces, la verificación de modelos se ha usado en la práctica, como digo ahí, sobre todo por grandes compañías tecnológicas, o sea, por I B. M. Microsoft, Intel, Amazon. Y esto a partir de cierto momento, Microsoft, a partir de 2 010 y Amazon web services a partir de 2 011.


329
01:05:10.206 --> 01:05:21.686
Ricardo Peña: Todos usan T. L, A o alguna versión de verificador de modelos. Por ejemplo, la Nasa ha usado promela y Spin


330
01:05:21.806 --> 01:05:27.365
Ricardo Peña: en fin, en el puerto de Róterdam para una barrera anti tormentas también se usó Spin. O sea que


331
01:05:27.906 --> 01:05:43.525
Ricardo Peña: quiero decir que es una tecnología que ahora mismo se puede considerar estándar de desarrollo, por lo menos para las grandes tecnológicas. Vale, pues pasamos a la última parte, ya que es la verificación formal. No voy a contar.


332
01:05:43.646 --> 01:05:52.366
Ricardo Peña: Lo que voy a contar es el estado del arte en este momento, porque la medicación formal lleva con nosotros en fin, 70 años, casi no


333
01:05:52.486 --> 01:06:04.656
Ricardo Peña: 80, no 30, 30, 50 años, 50 años con nosotros desde el 69 entonces los programas. Al principio se verificaban manualmente, o sea, que realmente.


334
01:06:05.386 --> 01:06:34.726
Ricardo Peña: pues podían cometer errores en la propia verificación, o sea, que realmente no no era tan segura. La técnica. No es interesante que que Donald, Luz, que es 1 de los en fin, interesados en la verificación. En su página Web. Publicaba esto. No dice en el código que está publicado aquí. Tenga cuidado con los errores, dice, lo he demostrado correcto y dice, pero no lo he ejecutado, o sea que no por probar lo correcto, tiene que estar bien salvo


335
01:06:35.206 --> 01:06:52.355
Ricardo Peña: que hay alguna herramienta que no sea simplemente manual. Entonces, lo que ha aportado el siglo X X I a partir de 2 005 más o menos son 2 cosas, los resolutores. S. M. T, que ahora hablaré un poquito de ellos, que lo que son demostradores automáticos de teoremas, básicamente


336
01:06:52.506 --> 01:06:55.236
Ricardo Peña: para una parte de la lógica


337
01:06:55.776 --> 01:07:07.345
Ricardo Peña: y las plataformas de verificación, que son plataformas que tienen un editor, un compilador, una imagen de programación, pero además tienen un lenguaje para escribir asertos lógicos.


338
01:07:07.496 --> 01:07:11.026
Ricardo Peña: extraen de manera automática las cosas que hay que demostrar


339
01:07:11.246 --> 01:07:17.485
Ricardo Peña: y luego las fórmulas que hay que verificar, se las da algún S, M. T, y las valida. Si puede.


340
01:07:17.876 --> 01:07:33.866
Ricardo Peña: y también demuestran terminación. Entonces, cuando digo que ha habido una realimentación. Quiere decir que los Smt dieron lugar a las plataformas y los los señores que verificaban querían cada vez un smt más potente no querían verificar programas más complejos.


341
01:07:33.866 --> 01:07:50.655
Ricardo Peña: Entonces los de los S M. T hacían ese, o sea, hacían algoritmos más complejos para demostrar más fórmulas. Entonces, las plataformas de verificación verificaban programas más complejos. Y se producía aquí un círculo virtuoso que llamo yo que al final han salido unos resolutores muy potentes. Como habéis visto en el ejemplo que os he contado antes


342
01:07:50.686 --> 01:07:53.275
Ricardo Peña: y una plataforma de verificación bastante útiles?


343
01:07:53.516 --> 01:08:02.446
Ricardo Peña: Bueno, los S M Ts: tampoco voy a contar mucho de ellos. Están basados en el problema Sad, que es decidible, pero aparte de la lógica de proposiciones


344
01:08:03.146 --> 01:08:20.726
Ricardo Peña: incorporan parte de la lógica decidible que son la aritmética lineal de números enteros y en goma flotante, lo que llaman funciones no interpretadas, que son funciones de las que sabemos el nombre y que cumplen de que si es igual A, B, F A es igual A, C, D, B, o sea, que son funciones


345
01:08:20.996 --> 01:08:48.636
Ricardo Peña: y basadas en funciones. Se construyen Arrays, que vienen a ser funciones de índices en valores, tipos algebraicos. Las constructoras de un tipo son funciones no interpretadas. Los conjuntos y los multiconjuntos son arrays un conjunto es una raíz de bureanos y un multi conjuntos, una raíz entero. Entonces, con las funciones interpretadas, hay muchas teorías interesantes para verificar que son decidibles, ¿no? Y algunas fórmulas universalmente cuantificadas.


346
01:08:48.816 --> 01:09:10.975
Ricardo Peña: Entonces se pueden usar en 2 modos. El modo satisfactibilidad que es que mira a ver si la forma es la fórmula es satisfactible o no, o sea, si existe una asignación de variables que hacen cierta la fórmula y en ese caso, proporciona esa asignación, Proporciona lo que llamamos un modelo. Ese es el modo en que yo lo he usado para el ejemplo que os he puesto del testing. Te da modelos, y con eso construyes casos de prueba.


347
01:09:11.346 --> 01:09:22.775
Ricardo Peña: Y luego la otra forma es validez, que es que demuestra que una fórmula es satisfactible para todos. Los modelos, en realidad son problemas duales y también puede responder que no sabe que la fórmula es demasiado compleja.


348
01:09:23.256 --> 01:09:39.896
Ricardo Peña: Bueno, entonces aquí tenéis en Dafney, que es una de las plataformas de más éxitos. La parte que no empieza con una línea en rojo es el código. Es una que sería un código de un algoritmo de ordenación que le damos un array, Te lo devuelve ordenado, entonces la post condición es que el arrai está ordenado


349
01:09:40.066 --> 01:10:00.686
Ricardo Peña: y que el multiconjunto de los elementos de la Rae de salida coincide con el multiconjunto de los elementos de la raíz de entrada, o sea que se puede especificar perfectamente. Y luego el invariantes tenéis aquí 3 invariantes, que básicamente es que el índice está dentro del rango que está ordenado de entre 0 e y sin incluir la I está ordenado.


350
01:10:00.956 --> 01:10:06.405
Ricardo Peña: La propiedad de la posgnición se mantiene todo el tiempo, pero lo que hacemos aquí es permutar 2 variables, 2 valores.


351
01:10:06.596 --> 01:10:23.475
Ricardo Peña: Y bueno, lo que escribiría. Entonces lo interesante es que el programador solo escribe la post condición, la precondición y los invariantes, y todo el resto lo hace la plataforma, o sea, las lo que llamamos las obligaciones de demostración, o sea, las fórmulas que hay que demostrar, las extrae de todo esto


352
01:10:23.676 --> 01:10:53.525
Ricardo Peña: y luego se las da el S M. T, que en este caso no necesita nada, sino que las puede verificar y fijaros que hay un forol aquí, o sea, un para todo el predicado sorted que está aquí es un para todo. También la post condición de la la el método que selecciona el mínimo de una Rai también tiene un forol, o sea, que son fórmulas que no son triviales, tienen para todos. Hay por lo menos 3 para todos. Hay multiconjuntos en fin que no es trivial. Bueno, pues Dafney lo hace todo de manera automática, ¿no?


353
01:10:53.716 --> 01:11:00.715
Ricardo Peña: Bueno. Entonces voy terminando la plataforma Dafne y la diseñó


354
01:11:01.226 --> 01:11:06.565
Ricardo Peña: Rusth leyendo cuando trabajaba para Microsoft. Ahora creo que está en Amazon


355
01:11:06.976 --> 01:11:27.755
Ricardo Peña: y al menos 50 universidades, entre ellas la complutense, lo usan para la enseñanza de la programación no aparte. Se han publicado muchos programas, muchos artículos con programas complejos verificados en en Daphne, con lo cual esos programas, bueno, pues tienen un alto grado de fiabilidad. ¿no? Yo mismo, hace unos años verifiqué una versión


356
01:11:27.756 --> 01:11:43.875
Ricardo Peña: de los árboles rojinegros que si alguno los ha trabajado una vez, verdad que son bastante complejos. El fichero tenía del orden de 800 líneas, pero ahí incluía todos los asertos, los lemas. En fin, fue un trabajo de varios meses.


357
01:11:43.896 --> 01:11:54.135
Ricardo Peña: Pero, bueno, ahí están los árboles rojinegros verificados por Ricardo, Peña, podéis poner la mano en el fuego por ellos porque están validados por Daphne.


358
01:11:54.296 --> 01:12:21.175
Ricardo Peña: Bueno, otra plataforma famosa es Q. Y esta descubrió en el año 2 015, un sutil error en un algoritmo de ordenación que estaba incluido en el sistema Android y que llevaba funcionando 8 años. O sea, que un sistema usado por 1 000 000 de personas, un algoritmo de ordenación tenía un error, y no fue hasta que se verificó ese algoritmo que se encontró el error. No hay otra en Francia, que es Guay. Tres de Jean Christoph y latre philatre


359
01:12:21.326 --> 01:12:34.695
Ricardo Peña: que en su página web tenéis 200 algoritmos que incluyen algoritmos de ordenación, manipulación de listas de árboles verificados, o sea que son bastante fiables, ¿no? Y luego, aparte de algoritmos sueltos.


360
01:12:34.796 --> 01:12:48.845
Ricardo Peña: hay un sistema completo que sepamos por lo menos la línea 14 del metro de París que lleva por lo menos 2 décadas funcionando, que son trenes sin conductor, que pasan cada 2 min y que transportan 40 000 viajeros por hora.


361
01:12:49.016 --> 01:12:56.196
Ricardo Peña: O sea que en fin, que no sería bueno que fallaran esos trenes, no que yo cerraran las puertas antes de tiempo, la dejaran abiertas. Yo, que sé,


362
01:12:56.296 --> 01:13:16.306
Ricardo Peña: y esta fue desarrollada por Jean Jan Raymond Adrial con una plataforma de esta se llamaba el Atelier, B, que dio lugar a 26 000 fórmulas que se demostraron de manera automática. Los test de integración no revelaron ningún error y el sistema lleva funcionando desde hace 20 años sin problemas, o sea que la verificación.


363
01:13:16.416 --> 01:13:24.386
Ricardo Peña: pues por lo menos para sistemas que son críticos en seguridad o que los va a usar mucha gente, pues son. Es bastante útil.


364
01:13:24.586 --> 01:13:29.796
Ricardo Peña: Bueno, pues estoy casi en la hora, me he pasado un minuto. Y ahora estoy en las conclusiones.


365
01:13:30.396 --> 01:13:35.695
Ricardo Peña: Entonces, la primera conclusión que también lo pregunto en el libro es.


366
01:13:36.206 --> 01:13:39.466
Ricardo Peña: ¿se puede eliminar completamente los errores del software.


367
01:13:39.736 --> 01:13:56.195
Ricardo Peña: pues, bueno, yo diría que toda labor humana está sujeta a error. O sea que por mucho que tengamos muchas herramientas y muchos analizadores. El error siempre está presente, no sea que errores de software. Yo creo que nunca se van a poder eliminar todos ellos.


368
01:13:56.336 --> 01:13:59.156
Ricardo Peña: pero lo que sí


369
01:13:59.356 --> 01:14:06.685
Ricardo Peña: podemos eliminar muchos más de los que eliminamos ahora, o sea, si si ampliáramos toda la tecnología disponible.


370
01:14:07.086 --> 01:14:10.296
Ricardo Peña: Pues seguramente


371
01:14:10.706 --> 01:14:35.045
Ricardo Peña: claro, si verificáramos los programas, hiciéramos análisis estáticos, análisis y determinación chequeo de modelos. Todo eso pues, probablemente determine mucho más no bueno, pero no os asustéis. No estoy proponiendo que todo el mundo use análisis estáticos, verificación de modelos, pero fijaros que las compañías importantes, o sea, las que dependen del del software para su


372
01:14:35.756 --> 01:14:48.746
Ricardo Peña: para sobrevivir. Por ejemplo, si I B. M. Vende 1 000 000 de circuitos o Intel o Amazon, en fin tiene 1 000 000 de clientes. No puede permitirse que su sistema falle, no, o que los circuitos tengan errores, ¿no?


373
01:14:48.966 --> 01:14:51.616
Ricardo Peña: Entonces, Por eso han sido las primeras


374
01:14:51.796 --> 01:15:08.845
Ricardo Peña: que han adoptado todas las tecnologías disponibles, incluso a veces contratando a investigadores de la universidad o incluso absorbiendo sus empresas, por ejemplo, el Peter Ohearn. Este que os he dicho antes de la lógica de separación, este trabaja para Facebook, o sea que que no solo absorbió su


375
01:15:08.976 --> 01:15:25.026
Ricardo Peña: su herramienta, absorbió al propio autor de la herramienta. Bueno, ¿por qué? Pues porque tienen que competir, no. Y entonces los productos que consumimos. Y aquí pongo todas las compañías, o muchas de las que han salido en el libro Netflix, beta Amazon, Airbus, Microsoft I b M Inter.


376
01:15:25.266 --> 01:15:49.186
Ricardo Peña: Nosotros somos consumidores de todos esos productos. Si no tuvieran la fiabilidad que tienen, no hubieran llegado a ser predominantes en el mercado no y no hubieran llegado a tener esa fiabilidad si no hubieran dis dispuesto de métodos como los que yo he contado aquí, no, o sea que los los métodos formales es una necesidad imperiosa, sobre todo para el que depende de ellos para su para su negocio, ¿no?


377
01:15:49.326 --> 01:15:55.415
Ricardo Peña: Pero claro, los demás mortales no somos. I B, M Ni somos Intel, ni somos Google.


378
01:15:55.656 --> 01:16:00.076
Ricardo Peña: ¿qué nos espera a nosotros? Pues aquí para concluir ya del todo?


379
01:16:00.296 --> 01:16:18.836
Ricardo Peña: Efectivamente, no todos los sistemas son críticos, o sea, que podemos sobrevivir si hacemos un sistema de los nuestros, que falla, pues a lo mejor la consecuencia es que hay que reiniciar el programa y perdemos un poco de trabajo, pero no perdemos mucho, O sea que, por un lado, no es tan importante que no tengan errores. No


380
01:16:19.116 --> 01:16:21.385
Ricardo Peña: son molestos, pero no son críticos.


381
01:16:21.936 --> 01:16:25.605
Ricardo Peña: Pero yo creo, y esa es mi última afirmación.


382
01:16:26.286 --> 01:16:30.865
Ricardo Peña: que la vía más eficaz para emplear toda la tecnología que he contado aquí


383
01:16:31.646 --> 01:16:35.476
Ricardo Peña: es usarla como caja negra, es decir, aprovechar.


384
01:16:35.666 --> 01:16:39.716
Ricardo Peña: o sea, tener herramientas. Una de ellas, por ejemplo, es Dakhne, pero hay otras


385
01:16:40.236 --> 01:17:09.645
Ricardo Peña: que ya te den gratis un montón de cosas, o sea, si tuviéramos una, por ejemplo, una plataforma que nada más. Meter el programa, aparte de chequear la sintaxis y los tipos, y tal hicieron un análisis de todo lo que contaba aquí de división por 0 de punteros colgados. Y ya eso ya te quitaba un montón de errores de entrada. Luego hacía un análisis de terminación y te detectaba todos los bucles que terminan y luego te dejaría unos pocos para que tú probaras que terminan, los que no puedes demostrar él no.


386
01:17:09.856 --> 01:17:14.766
Ricardo Peña: Y luego, pues, se dedican a a verificar. Porque cuando tú haces un programa en Dafney


387
01:17:14.936 --> 01:17:31.505
Ricardo Peña: si no pones pre condición y poscondición en principio, Darnik te deja escribir lo que tú quieras. Pero como hay operaciones, por ejemplo, acceder a una Rai que son operaciones parciales automáticamente verifica si el índice que le pasas está dentro del rango ¿no? Y si no puede verificar que está dentro del rango, te lo dice


388
01:17:31.536 --> 01:17:57.576
Ricardo Peña: con lo cual tú, con muy poquito esfuerzo, podrías poner allí un invariante diciendo: no mira, date cuenta de que el índice varía solo entre 0 y L Uno le pones un pequeño invariante y automáticamente eso te lo verifica Daphney. O sea que puedes usar Dafney como quieras, como un simple lenguaje de programación que te da un código máquina que puedes ejecutar. No, De hecho, Downy se compila a la plataforma punto Net, o sea, que puedes hacer programas que se ejecutan en punto Net.


389
01:17:57.656 --> 01:18:15.525
Ricardo Peña: Pero con muy poquito esfuerzo, te da terminación te da ciertos asertos, te verifica los índices de los Array, es decir, una herramienta que tenga incorporada muchas cosas de las que he contado, pues sería muy útil para hacer programas como los nuestros. Con muy poquito esfuerzo, podríamos detectar muchos errores.


390
01:18:15.856 --> 01:18:20.825
Ricardo Peña: y yo creo que Esto es mi última cosa, como he dicho, así que muchas gracias por


391
01:18:20.976 --> 01:18:26.916
Ricardo Peña: atenderme. Y ahora, pues estoy abierto a lo que queráis preguntarme. Me voy a la página.


392
01:18:27.076 --> 01:18:28.896
Ricardo Peña: dónde estáis vosotros.


393
01:18:29.146 --> 01:18:31.516
Ricardo Peña: Y aunque no me veáis. Pero si me oís no.


394
01:18:32.726 --> 01:18:42.645
Fernando Orejas Valdés: Y por favor, si queréis hacer preguntas hacedlas a través de preguntas y respuestas, si no os viene mal, si os viene mal, pues hacerlas directamente.


395
01:18:43.716 --> 01:18:46.826
Ricardo Peña: Yo, como lo veo eso. Fernando: hay un chat por ahí.


396
01:18:46.826 --> 01:18:51.455
Fernando Orejas Valdés: En la ve en la ventanita de del zoom abajo.


397
01:18:51.456 --> 01:18:51.956
Ricardo Peña: Sí.


398
01:18:51.956 --> 01:18:56.906
Fernando Orejas Valdés: Hay una cosa que pone preguntas y respuestas entre compartir y más.


399
01:18:57.566 --> 01:19:00.416
Ricardo Peña: Vale. ¿y qué le doy ahí? Y me sale un chat.


400
01:19:00.416 --> 01:19:03.066
Fernando Orejas Valdés: Y te sale ahí un una. Ca.


401
01:19:03.066 --> 01:19:04.086
Ricardo Peña: Y a.


402
01:19:04.086 --> 01:19:05.796
Fernando Orejas Valdés: Preguntas.


403
01:19:05.796 --> 01:19:07.625
Ricardo Peña: Vale, pues, de momento no hay nadie que pregunte.


404
01:19:07.626 --> 01:19:12.705
Fernando Orejas Valdés: De momento no hay nadie. Mientras llega alguna te pregunto yo, algo


405
01:19:13.066 --> 01:19:28.666
Fernando Orejas Valdés: es que todo esto está muy más que preguntarte es para que comentes No, todo esto está muy bien. Pasa basándose en la pos en que en que 1 pueda expresar con pre y poscondiciones lo que lo que quiere que haga sus programas.


406
01:19:29.526 --> 01:19:43.316
Fernando Orejas Valdés: Pero ¿qué pasa, por ejemplo, con las aplicaciones que ahora están de moda de inteligencia artificial. Aprende aplicaciones de que hacen aprendizaje computacional. Y estas cosas.


407
01:19:44.256 --> 01:19:47.246
Ricardo Peña: Bueno, como sabes, yo no soy experto en eso.


408
01:19:47.246 --> 01:19:48.376
Fernando Orejas Valdés: La ya.


409
01:19:48.376 --> 01:19:53.555
Ricardo Peña: Me parece que las redes neuronales funcionan bajo el


410
01:19:53.706 --> 01:20:08.326
Ricardo Peña: paradigma de la probabilidad, ¿no? Cuando te dan una respuesta, es la que ellos consideran más probable, no porque su aprendizaje es la que más se parece a lo que ha aprendido, ¿no? Pero yo no veo forma ahí de usar la lógica, por lo menos la lógica normal.


411
01:20:08.446 --> 01:20:11.955
Ricardo Peña: No veo manera de usarla ahí para verificar nada, no porque.


412
01:20:11.956 --> 01:20:12.426
Fernando Orejas Valdés: Todo.


413
01:20:12.426 --> 01:20:14.696
Ricardo Peña: Probabilista ahí, todos probabilistas.


414
01:20:15.436 --> 01:20:21.055
Ricardo Peña: o sea, cuando un un sistema de estos de entren que están entrenados te da una respuesta errónea.


415
01:20:21.586 --> 01:20:45.516
Ricardo Peña: pues tienes que que asumirlo, sabes, porque, bueno, porque el aprendizaje ha sido, ha sido incompleto. No ha sido capaz de dar algo más preciso, pero no no existe. Una manera de garantizar, o sea, para mí, es que los las redes neuronales, los sistemas de aprendizaje automático no son algoritmos en el sentido clásico. Tiene un algoritmo.


416
01:20:45.636 --> 01:21:02.115
Ricardo Peña: Puedes decir lo que va a hacer, y nunca te da falsos positivos ni falsos negativos, siempre te, O sea, es como los militares cuando dicen que sí es que sí, cuando dicen que no es que no. Y nunca dicen, no sé porque son militares, ¿no? Pues esto es igual cuando tú verificas un programa o te dice que es correcto o te dice que es incorrecto, ¿no?


417
01:21:02.316 --> 01:21:11.245
Ricardo Peña: Pero en las redes neuronales tienes que aceptar que te diga que sí, cuando es que no, y que te diga que no, cuando es que sí, porque son así, porque son probabilistas.


418
01:21:11.246 --> 01:21:35.865
Fernando Orejas Valdés: Sí, pero 1, por ejemplo, querría poder demostrar algo que que ya se comenta por ahí. Es algo que se sabe desde hace tiempo. Y, por ejemplo, sí un cierto software que se usa para yo, que sé cosas que pueden ser críticas, como la concesión de seguros o el dar la libertad condicional a un preso o cosas por el estilo. Tienen sesgos.


419
01:21:37.146 --> 01:21:38.535
Ricardo Peña: Sí claro, pero


420
01:21:38.686 --> 01:21:47.965
Ricardo Peña: eso se garantiza. Por otro lado, se garantiza con auditorías de los datos de entrenamiento, o sea, los Los sindicatos, por ejemplo, son muy críticos.


421
01:21:48.006 --> 01:22:14.316
Ricardo Peña: Quieren que se usen sistemas de aprendizaje automático para decidir despidos o para decidir contrataciones. Entonces ellos quieren saber, y están pidiéndolo, porque lo sé porque estuve una vez en una chapa de inteligencia artificial con los sindicatos, y ellos quieren saber con qué datos se ha entrenado el sistema para asegurarse de que no tienen sexo ni de género ni de raza, pero eso no es verificar. Yo diría que eso es otro tipo de control. No es un control.


422
01:22:14.426 --> 01:22:20.315
Ricardo Peña: Vamos a llamar sindical o político de que los datos no tienen sesgos, ¿no?


423
01:22:20.426 --> 01:22:30.275
Ricardo Peña: Y a la inversa. Yo he visto, por ejemplo, películas de de romanos en las que están hechas con inteligencia artificial que aparecen romanos.


424
01:22:30.456 --> 01:22:35.756
Ricardo Peña: que son negros o que son o que son amarillos. ¿no? ¿por qué? Porque el sistema fue entrenado


425
01:22:35.986 --> 01:22:42.265
Ricardo Peña: con datos que incluían personas negras. Y entonces, pues se decidió que los romanos podían ser negros.


426
01:22:42.446 --> 01:22:48.046
Ricardo Peña: o sea, que tiene sesgos en los 2 sentidos. Cuando no deben ser negros, los pone negros, y cuando deben ser negros, no los pone.


427
01:22:48.346 --> 01:22:51.585
Ricardo Peña: Pero eso no sé qué tiene que ver con la verificación o con la.


428
01:22:52.446 --> 01:22:57.695
Fernando Orejas Valdés: Bueno, la cuestión es que son sistemas de software


429
01:22:58.596 --> 01:23:04.565
Fernando Orejas Valdés: Mhm, en los cuales 1 querría asegurarse que se cumplen ciertas propiedades


430
01:23:05.336 --> 01:23:14.045
Fernando Orejas Valdés: que lo que ocurre es que, claro, todas estas técnicas están pensadas para otro tipo de software que eso es lo lo que ocurre. No.


431
01:23:14.616 --> 01:23:15.386
Ricardo Peña: Sí, Sí,


432
01:23:16.906 --> 01:23:17.726
Ricardo Peña: muy bien.


433
01:23:18.396 --> 01:23:20.596
Ricardo Peña: Sigue sin haber preguntas.


434
01:23:20.596 --> 01:23:21.636
Fernando Orejas Valdés: Había un.


435
01:23:21.636 --> 01:23:26.906
Ricardo Peña: Nadie. Bueno, yo no sé cuántas cuántas personas están, pues yo yo no veo a los participantes.


436
01:23:27.246 --> 01:23:30.455
Fernando Orejas Valdés: Sí. Ahora, en este momento. 22


437
01:23:30.456 --> 01:23:31.485
Fernando Orejas Valdés: Ohh: ¿Qué


438
01:23:31.486 --> 01:23:34.385
Fernando Orejas Valdés: De haber cerca de 40.


439
01:23:34.822 --> 01:23:35.765
Ricardo Peña: ¡qué bien, qué? Bien.


440
01:23:37.566 --> 01:23:42.606
Ricardo Peña: Pues no sé, es alguien o tú mismo? Javier: Si quieres preguntar algo.


441
01:23:46.396 --> 01:23:58.076
Javier Berrocal: No, no, Yo no tengo ningún ninguna pregunta. Yo me imagino que, bueno, la verdad es que ha sido una explicación bastante bastante clara y entiendo que la gran mayoría de los asistentes, pues les ha quedado bastante claro. Todo.


442
01:23:59.636 --> 01:24:00.716
Ricardo Peña: Muy bien.


443
01:24:01.506 --> 01:24:10.676
Ricardo Peña: Pues nada, yo os hago propaganda de mi libro que ya digo más que para vosotros puede ser útil para vuestros estudiantes, no


444
01:24:10.866 --> 01:24:12.056
Ricardo Peña: porque.


445
01:24:12.056 --> 01:24:14.235
Fernando Orejas Valdés: Tienes una, ya tienes preguntas.


446
01:24:14.486 --> 01:24:15.326
Ricardo Peña: Bien.


447
01:24:15.706 --> 01:24:19.616
Ricardo Peña: Muchas gracias. Ricardo. Me quedo contigo. Entonces.


448
01:24:22.956 --> 01:24:24.886
Ricardo Peña: de conocimientos, esta profundidad


449
01:24:28.966 --> 01:24:54.826
Ricardo Peña: sí. Gracias. Ernesto mucho gusto en saber de Ti. No hay métodos en los que he contado que no necesitan precondición y poscondición. Por ejemplo, la interpretación abstracta se puede usar como caja negra. O sea, tú puedes usar una herramienta como estas que he contado Astree o Julia o Facebook infern Todas estas se pueden usar sin saber nada de la de cómo están hechas Tú lo pasas por tu texto del Java


450
01:24:54.946 --> 01:25:09.536
Ricardo Peña: o lo que tengas. Y él te dice. Si detecta punteros nulos a acceso a punteros, nulos o a punteros descolgados, te lo dice gratis, O sea, tú puedes usar? Bueno. De hecho, los que la usan no saben nada de interpretación abstracta ni de nada


451
01:25:09.846 --> 01:25:27.975
Ricardo Peña: el model checkers, Los model checking sí, o sea, la comprobación de modelos. Sí, necesitas saber, claro, si quieres verificar un modelo, tienes que construir el modelo y construir la propiedad que quieres probar. O sea que ahí sí que tienes que trabajar. Y si quieres verificar también, claro, o sea que claro, todo gratis no puede ser.


452
01:25:28.156 --> 01:25:30.286
Ricardo Peña: Pero, por ejemplo, terminación


453
01:25:30.436 --> 01:25:36.125
Ricardo Peña: y análisis estático como el que he contado de interpretación abstracta. Todo eso puede hacerse como una caja negra.


454
01:25:43.916 --> 01:25:45.336
Ricardo Peña: alguna cosa más.


455
01:25:45.716 --> 01:25:52.645
Fernando Orejas Valdés: Mira otra cosa. Otro ámbito en el cual en el cual este tipo de verificación


456
01:25:53.856 --> 01:26:05.356
Fernando Orejas Valdés: puede ser útil parcialmente, pero no, no en el sentido de, digamos, verificar que el seguro haga lo que lo que se espera que haga es el caso


457
01:26:05.476 --> 01:26:13.096
Fernando Orejas Valdés: del que se habló en un seminario casi al principio de los seminarios y que fue un seminario que yo encontré muy entretenido.


458
01:26:13.216 --> 01:26:15.705
Fernando Orejas Valdés: que era sobre test metamórfico.


459
01:26:16.416 --> 01:26:16.866
Ricardo Peña: Mhm.


460
01:26:16.866 --> 01:26:33.866
Fernando Orejas Valdés: Metamórfico y que era el textil metamórfico. Nunca había oído antes. Lo que era. Eso es se da cuando 1 no sabe las respuestas que debe dar un sistema de software y ejemplos. Por ejemplo, era pues Google Maps.


461
01:26:34.646 --> 01:26:42.385
Fernando Orejas Valdés: buscas el mejor camino para ir de un sitio a otro, pero no sabes si el que te da Google Maps es el bueno, no.


462
01:26:43.446 --> 01:26:44.216
Ricardo Peña: Mhm.


463
01:26:44.626 --> 01:26:46.666
Ricardo Peña: Pues eso, claro.


464
01:26:47.016 --> 01:26:49.126
Ricardo Peña: eso es un testing.


465
01:26:49.126 --> 01:26:49.536
Fernando Orejas Valdés: Sí.


466
01:26:49.536 --> 01:26:53.576
Ricardo Peña: ¿quién evalúa la respuesta?


467
01:26:54.326 --> 01:26:59.455
Fernando Orejas Valdés: En el seminario. Aquel Se hablaba de lo que se hacía en ese ámbito.


468
01:27:01.186 --> 01:27:07.915
Fernando Orejas Valdés: intentando analizar hasta qué punto encontrar errores de otra manera


469
01:27:08.116 --> 01:27:11.886
Fernando Orejas Valdés: que si recuerdo bien, pues era, por ejemplo, viendo


470
01:27:12.076 --> 01:27:18.576
Fernando Orejas Valdés: si ante preguntas similares, se obtenía la misma respuesta o cosas así.


471
01:27:18.576 --> 01:27:19.536
Ricardo Peña: No pasa.


472
01:27:19.536 --> 01:27:20.716
Fernando Orejas Valdés: Mucho.


473
01:27:21.326 --> 01:27:27.226
Fernando Orejas Valdés: Pero Pero, bueno, de estos programas que hay hay muchos que 1 no sabe


474
01:27:27.516 --> 01:27:33.096
Fernando Orejas Valdés: los que se usan, que 1 no sabe cuál es la respuesta buena, porque si la supiera no usaría el programa, no.


475
01:27:34.296 --> 01:27:40.795
Ricardo Peña: Bueno, pues ahí sería un caso donde lo que llaman el oráculo, no, o sea, la evaluación del resultado


476
01:27:41.146 --> 01:27:51.906
Ricardo Peña: tiene que ser forzosamente por un humano. No tiene que ser un humano que valide la respuesta. Yo no veo forma de usar ahí


477
01:27:52.726 --> 01:28:08.725
Ricardo Peña: yo lo o sea, lo que el sistema que se contó mío, la ventaja que tiene es que con muy poquito esfuerzo, o sea, tú bueno para mí es poco porque estoy acostumbrado a ponerte condiciones y poscondiciones a lo mejor para quien no es tan poco. Pero si eres capaz de poner formalmente una pre condición y una post condición.


478
01:28:08.926 --> 01:28:13.036
Ricardo Peña: Claro, también había que advertir precondiciones y condiciones


479
01:28:13.226 --> 01:28:33.965
Ricardo Peña: que se puedan expresar en la lógica de los S. M. T, Claro, porque los S. M Ts. Tampoco puedes expresar todas las fórmulas que se te ocurran. No. Pero bueno, si lo puedes convertir en restricciones de un S, M. T, de un resolutor de estos. Con ese pequeño esfuerzo de escribir la precondicción y la post condición es que puedes hacer miles de casos


480
01:28:34.006 --> 01:28:51.706
Ricardo Peña: sin ningún esfuerzo. Bueno, o sea que eso yo creo que es una cosa. No sé si alguien lo ha lo ha hecho. Yo creo que no. Yo creo que nadie ha hecho un sistema así porque los los casos de caja negra que yo conozco, las herramientas que prueban caja negra, Lo que hacen es generar casos al azar no generan muchos casos.


481
01:28:51.786 --> 01:29:17.836
Ricardo Peña: pueden ser miles, también. Pero están están, bueno, no hay ningún control sobre qué casos se genera, ¿no? Y luego la comprobación de las respuestas la tienen que hacer ejecutable, o sea, tienen. Yo lo he visto eso para hacker y para Airlines, los sistemas que hizo John Hughes. No sé si lo recuerda, no esos sistemas. El programador tiene que escribir primero un generador de casos que no es trivial, aunque tiene muchas herramientas para construirlos, luego tiene que construir


482
01:29:17.896 --> 01:29:26.795
Ricardo Peña: un programita que evalúe la post condición tiene que ser un aserto ejecutable que tampoco es posible muchas veces, ¿no?


483
01:29:26.956 --> 01:29:33.356
Ricardo Peña: Entonces mis asertos no no son ejecutables. Son evaluables por un S M. T, que es un poquito más amplio que


484
01:29:33.886 --> 01:29:40.886
Ricardo Peña: entonces. Bueno, pues os animo a tener sistemas de esto. No es demasiado caro


485
01:29:41.416 --> 01:29:45.535
Ricardo Peña: dotar a una plataforma, por ejemplo, de una generación de casos.


486
01:29:45.646 --> 01:29:55.765
Ricardo Peña: Por ejemplo, Daphney se podría hacer una versión de Daphney, que generará casos como los genero, yo y comprobara las poscondiciones como las compruebo yo, o sea, que por qué no?


487
01:30:02.026 --> 01:30:03.316
Ricardo Peña: Bueno, pues no sé.


488
01:30:03.316 --> 01:30:03.956
Fernando Orejas Valdés: Bueno.


489
01:30:03.956 --> 01:30:05.006
Ricardo Peña: Alguna cosa más.


490
01:30:05.006 --> 01:30:07.556
Fernando Orejas Valdés: Parece que no hay más preguntas.


491
01:30:08.646 --> 01:30:11.226
Ricardo Peña: Tú has dicho. Fernando, que te has jubilado, no.


492
01:30:11.546 --> 01:30:13.296
Fernando Orejas Valdés: Dice, bueno, estoy de mérito. También.


493
01:30:13.296 --> 01:30:17.006
Ricardo Peña: Pero tienes alguna actividad, Todavía no.


494
01:30:17.006 --> 01:30:18.496
Fernando Orejas Valdés: Sí, Sí, Sí.


495
01:30:20.346 --> 01:30:23.386
Ricardo Peña: Aquí no hay nadie más que conteste, espérate a ver. Vamos a ver.


496
01:30:25.136 --> 01:30:31.356
Ricardo Peña: Ah, sí, sí, está aquí. Ernesto ha contestado algo a eso. Me refiero. Gracias. Tal no, Pero no hay más. No hay nada nuevo


497
01:30:33.696 --> 01:30:37.386
Ricardo Peña: bueno, pues espero que os haya sido os haya sido interesante.


498
01:30:37.386 --> 01:30:54.555
Fernando Orejas Valdés: Muy entretenido. Y bueno, yo, Las preguntas que te hacía no eran críticas, era simplemente señalar situaciones que hoy en día 1 tiene incluso que son importantes socialmente para los cuales digamos que hace falta investigación. Nueva.


499
01:30:55.356 --> 01:30:55.976
Ricardo Peña: Sí, sí.


500
01:30:56.356 --> 01:31:02.336
Ricardo Peña: Bueno, pues muy bien, a ver si inventan un ejecutor de casos de prueba para redes neuronales.


501
01:31:03.196 --> 01:31:17.955
Fernando Orejas Valdés: Bueno, la gente de de lo que llaman ya explicable es a lo que en cierta manera se dedica a intentar entender lo que poder decir, que es que por qué se obtiene un cierto resultado y


502
01:31:18.176 --> 01:31:19.786
Fernando Orejas Valdés: en tal no. Pero bueno.


503
01:31:20.176 --> 01:31:29.046
Ricardo Peña: Y cómo está eso? Porque yo, a la charla, aquella que dio Belén. No pude asistir. Si hay, si se ha avanzado mucho en eso o no.


504
01:31:29.496 --> 01:31:32.855
Fernando Orejas Valdés: No sé, no, tampoco es nuestro campo.


505
01:31:33.486 --> 01:31:41.086
Ricardo Peña: Mi última, mi última charla, que he asistido se llaman redes neuronales. Can No sé si te suena K, a N,


506
01:31:41.486 --> 01:31:49.316
Ricardo Peña: que son las los siglas de unos señores. Son fulanito y menganito. Y lo que hacen es que en lugar de aprender.


507
01:31:49.396 --> 01:31:54.165
Ricardo Peña: o sea lo que aprende en las redes neuronales normales suelen aprender funciones lineales


508
01:31:54.246 --> 01:32:01.136
Ricardo Peña: y unas funciones que llaman de activación, que son predefinidas que son arcos, tangentes, sigmoides, cosas así. ¿no?


509
01:32:01.216 --> 01:32:08.285
Ricardo Peña: Entonces el aprendizaje consiste en adaptar esas funciones a los casos de entrenamiento.


510
01:32:08.336 --> 01:32:31.406
Ricardo Peña: Entonces las redes can en lugar de todo eso, lo que aprenden son Spline, que son polinomios de grado. Tres, un parece, decían ellos que eso es más explicable, O sea, que los Spline te dan más explicación de por qué funcionan las respuestas y por qué no. Pero bueno, yo no logro entender por qué las Spline son más explicativas que otras cosas.


511
01:32:32.096 --> 01:32:34.776
Ricardo Peña: Pero bueno, ese es el estado del arte.


512
01:32:35.266 --> 01:32:35.966
Fernando Orejas Valdés: Mhm.


513
01:32:36.576 --> 01:32:37.276
Ricardo Peña: Mhm.


514
01:32:37.586 --> 01:32:39.956
Fernando Orejas Valdés: Bueno, pues muchas gracias. Ricardo.


515
01:32:39.956 --> 01:32:42.185
Ricardo Peña: Gracias a vosotros.


516
01:32:42.186 --> 01:32:44.755
Javier Berrocal: Muchas gracias y que tengas una buena tarde.


517
01:32:44.756 --> 01:32:46.326
Ricardo Peña: ¡venga! Gracias. Javier.


518
01:32:46.866 --> 01:32:47.496
Javier Berrocal: Con.