Aplicación de la "comprobación de modelos " en la verificación de la capa Web y en modelos de ascensores

Texto completo

(1)Aplicación de la “Comprobación de Modelos” en la verificación de la capa web y en modelos de ascensores. Edgar Mauricio Fajardo, Rodrigo Cardoso (Asesor) 28 de enero de 2009.

(2) Índice general 0.1. Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 0.2. Cómo leer este documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introducción 1.1. Motivación . . . . . . . . . . . . . . . . . . . . 1.2. Lo que se quiso hacer . . . . . . . . . . . . . . 1.2.1. Por qué son interesantes los problemas 1.2.2. Por qué Spin . . . . . . . . . . . . . . 1.3. Descripción de los Capı́tulos . . . . . . . . . .. iv v. . . . . .. 1 1 2 2 3 3. 2. Marco Teórico 2.1. Comprobación de Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Lógica Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Linear Temporal Logic . . . . . . . . . . . . . . . . . . . . . . . . . .. 4 4 4 5. 3. Como abordar verificación 3.1. Introducción . . . . . . . 3.2. Planteo del Problema . . 3.3. Modelaje . . . . . . . . . 3.4. Especificación . . . . . . 3.5. Reducción . . . . . . . . 3.6. Verificación . . . . . . .. . . . . . .. 7 7 7 7 7 8 8. . . . . . . . . . .. 9 9 9 11 12 12 12 13 13 14 14. usando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. CM . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . .. . . . . . .. 4. Problema del Ascensor 4.1. Introducción . . . . . . . . . . . . . . . . . . 4.2. Modelo de Ascensor . . . . . . . . . . . . . . 4.2.1. Tamaño teórico del Modelo . . . . . 4.3. Requerimientos del Ascensor . . . . . . . . . 4.3.1. Requerimientos de Seguridad . . . . 4.3.2. Requerimientos de Vivacidad . . . . 4.3.3. Requerimientos de Eficiencia . . . . . 4.3.4. Independencia de los Requerimientos 4.3.5. Completitud de la Especificación . . 4.4. Tipos de Ascensor . . . . . . . . . . . . . . . i. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . . . . . ..

(3) 4.4.1. AMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2. Ascensor Rango . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3. Ascensor Puertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4. Ascensor Tridirección . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.5. Ascensor CambioDirección . . . . . . . . . . . . . . . . . . . . . . . . 4.4.6. Ascensor Petición Publica . . . . . . . . . . . . . . . . . . . . . . . . 4.4.7. Ascensor Petición Privada . . . . . . . . . . . . . . . . . . . . . . . . 4.4.8. Ascensor PeticionParada y Giros . . . . . . . . . . . . . . . . . . . . 4.5. Requerimientos en LTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2. Requerimientos en LTL para un ascensor . . . . . . . . . . . . . . . . 4.5.3. Requerimientos de vivacidad en formulas de LTL para un ascensor usando peticiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Simulaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1. Simulacion caso general . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2. Morfismo de relación de subir y bajar . . . . . . . . . . . . . . . . . . 5. Problema Web 5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . 5.2. Modelo de la Aplicación . . . . . . . . . . . . . . . . . 5.2.1. Grafo de Navegación . . . . . . . . . . . . . . . 5.2.2. Los nodos de la aplicación . . . . . . . . . . . . 5.2.3. Acciones de la aplicación . . . . . . . . . . . . . 5.2.4. Variables de la aplicación . . . . . . . . . . . . . 5.3. Especificación de la aplicación . . . . . . . . . . . . . . 5.3.1. Predicados de los nodos de la aplicación . . . . 5.3.2. Precondiciones y Postcondiciones de las acciones 5.4. Reducción del Modelo . . . . . . . . . . . . . . . . . . 5.4.1. Rangos Finitos de las Variables . . . . . . . . . 5.4.2. Tamaño teórico del Modelo . . . . . . . . . . . 5.4.3. Modelo en Promela . . . . . . . . . . . . . . . . 5.5. Verificación . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1. Modelo de Usuario . . . . . . . . . . . . . . . . 5.5.2. Proceso de Verificación . . . . . . . . . . . . . . 5.5.3. Completitud de la Especificación . . . . . . . .. 14 15 16 16 16 18 18 18 18 18 18 21 22 22 23. . . . . . . . . . . . . . . . . .. 25 25 25 26 26 27 27 28 29 30 31 31 33 33 33 33 34 34. 6. Conclusiones 6.1. Conclusiones Ascensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Conclusiones Trabajo Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 35 35 37 38. ii. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . ..

(4) A. Instalación y uso de SPIN A.1. Instalación . . . . . . . . . . . . . . A.2. Información basica de Spin . . . . . A.2.1. Tipos de Objetos . . . . . . A.2.2. Especificación en SPIN . . . A.2.3. Estructuras de control SPIN A.2.4. Simulación y Verificación . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 40 40 41 41 44 44 46. B. Modelos Spin Ascensor B.1. Proceso de Usuario . . . . . B.2. Ascensor Rango . . . . . . . B.3. Ascensor Puertas . . . . . . B.4. Ascensor Tridirección . . . . B.5. Ascensor Cambio Dirección B.6. Ascensor Petición Publica . B.7. Ascensor Petición Privada .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 47 47 48 48 49 49 51 54. . . . . . . . . . . . .. 58 58 59 59 61 61 63 63 65 66 68 68 70. . . . . . . .. . . . . . . .. C. Modelos Spin Web C.1. Modelo Nodo Logon . . . . . . C.1.1. Modelo de Usuario . . . C.2. Modelo Nodo Main . . . . . . . C.2.1. Modelo Usuario . . . . . C.3. Modelo Nodo AccountList . . . C.3.1. Modelo de Usuario . . . C.4. Modelo de Nodo transferFunds C.4.1. Modelo de Usuario . . . C.5. Modelo Nodo atm . . . . . . . . C.5.1. Modelo de Usuario . . . C.6. Modelo Nodo accountHist . . . C.6.1. Modelo Usuario . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . .. iii. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . ..

(5) 0.1.. Agradecimientos. El autor desea expresar sus agradecimientos a las siguientes personas, cuyos aportes hicieron de este trabajo una realidad. Empezando por el director de investigación de este documento, Rodrigo Cardoso. Cuyos cuestionamientos y sugerencias enriquecieron y aumentaron la profundidad del documento. Igualmente agradecer a la profesora del departamento de matemáticas Maricarmen Martinez, cuyas crı́ticas, correcciones e interés general en este trabajo hicieron posible su consecución. También a Gerard Holzmann uno de los diseñadores de SPIN, por su apoyo en la solución de dudas acerca del uso y funcionamiento de SPIN. De la misma manera agradecer a Jorge Ricardo Cuellar. Sus sugerencias, crı́ticas, y su conocimiento de comprobación de modelos resultaron invaluables a la hora de abordar los problemas. Igualmente agradecer a Margarita Fajardo, Juan Camilo Salazar, Edgar Fajardo y Nicolás Garcı́a quienes se tomaron el tiempo de leer el documento y colaboraron con la corrección, ortográfica y de redacción. Finalmente agradecer a Aura Cecilia Hernández cuya dedicación y apoyo fue indispensable para la culminación de este documento.. iv.

(6) 0.2.. Cómo leer este documento. Este documento se realizó de tal forma que pueda ser leı́do con cuatro diferentes niveles de profundidad. El primer nivel comprende los capı́tulos de introducción (capı́tulo 1), de aproximación a un problema usando comprobación de modelos (capı́tulo 3) y el de conclusiones (capı́tulo 6). En este nivel el lector podrá comprender los aspectos básicos de comprobación de modelos y se podrá observa una relación entre los objetivos propuestos para este proyecto y los objetivos conseguidos. Un segundo nivel de profundidad esta compuesto de las secciones de introducción, modelado y especificación de los capı́tulos 4 y 5. En este nivel el lector se podrá dar una idea de los problemas especı́ficos abordados en este documento; en este nivel también es posible encontrar la relación entre la aproximación propuesta en el capı́tulo 3 y la aproximación realizada en los capı́tulos 4 y 5. Un tercer nivel recomendado para personas con un conocimiento más avanzado de lógica esta compuesto por el marco teórico (capı́tulo 2) y las secciones de especificación en lógica temporal de los capı́tulos 4 y 5. En este nivel se puede encontrar la relación entre las nociones de lógica, la técnica de comprobación de modelos y los problemas concretos realizados en este proyecto. Finalmente el cuarto nivel esta diseñado para personas con un alto interés por el tema y se recomienda una lectura completa del documento. Aquellas personas interesadas en comprender el funcionamiento básico de SPIN se les recomienda la lectura del anexo A. Por ultimó si hubiera personas interesadas en los detalles técnicos de la verificación y la implementación final en SPIN de los modelos de los capı́tulos 4 y 5, se les recomienda la lectura de los anexos B y C.. v.

(7) Capı́tulo 1 Introducción 1.1.. Motivación. Cada dı́a se incrementan el número de acciones que son efectuadas por computadores y dispositivos electrónicos. Algunas de las labores que hoy en dı́a están siendo o son automatizadas incluyen (pero no se limitan a): el control aéreo, el control del funcionamiento de los motores de algunos vehı́culos [Gri03], el control de sistemas de emergencia, la operación de vehı́culos en el espacio exterior [SECH98], el comercio electrónico y el control de represas contra inundaciones [Kar96]. Pero a medida que estas labores crecen en número y complejidad, las fallas en el diseño e implementación de éstas pueden llegar a ser muy costosas. Un ejemplo de este tipo de errores es la caı́da del cohete Ariane5 provocada por un error de conversión de datos [Lio96], la cual tuvo un costo de alrededor de quinientos millones de dólares. Es claro que si se desea que el número de tareas automatizadas crezca es necesario contar con una técnica que permita verificar el diseño y la implementación de estos dispositivos. Una aproximación posible a este problema es realizar una gran cantidad de pruebas dirigidas por un humano; el problema de esta aproximación es que los errores menos frecuentes y que tienden a ser más costosos pueden no revelarse. Otra aproximación consiste en realizar demostraciones matemáticas de la corrección de los programas; el problema con esta aproximación es que se necesita personal altamente calificado y las pruebas de pequeños fragmentos de código pueden llevar semanas. Una tercera aproximación relacionada con la anterior es el uso de probadores de teoremas, pero ésta tiene el inconveniente que no es totalmente automática y en general requiere de la asistencia de un humano [CGP99]. Una cuarta aproximación es la comprobación de modelos (ing. Model Checking), ésta tiene la ventaja sobre los probadores de teoremas de que no requiere asistencia humana, pero con la desventaja de que sólo funciona con dominios finitos. Aparte de las ventajas anteriormente mencionadas la comprobación de modelos también permite en caso de encontrar un error, dar una traza de eventos que llevaron al error. Esto 1.

(8) último permite a los diseñadores y programadores reparar los errores más rápidamente. Por lo explicado anteriormente se decidió escoger comprobación de modelos como la técnica formal para la verificación de dos problemas especı́ficos.. 1.2.. Lo que se quiso hacer. El objetivo de este trabajo es lograr una apropiación de los principales conceptos y procesos necesarios para usar comprobación de modelos. Para esto se escogieron dos problemas y luego se hizo la verificación de estos usando SPIN.. 1.2.1.. Por qué son interesantes los problemas. Problema del Ascensor El primer problema que se aborda es el de un grupo de ascensores en un edificio. Este problema surgió por la inconformidad de los usuarios con el funcionamiento del sistema de ascensores del edificio Mario Laserna de la Universidad de los Andes. El problema no sólo es interesante por su aplicación a la mayorı́a de ascensores en el mundo, sino porque las conclusiones pueden ser llevadas a otros sistemas de transporte con rutas cerradas como los sistemas de transporte masivo en las diferentes ciudades. Un primer objetivo es entender por qué el funcionamiento de ciertos ascensores era calificado como deficiente por los usuarios. El segundo objetivo es obtener modelos de ascensor los cuales sı́ fueran percibidos por los usuarios como “buenos”. El tercer objetivo es garantizar, usando comprobación de modelos, que los modelos entregados cumplan con todos los requisitos propuestos por los usuarios en cualquier situación. Problema Interfaz Web El segundo problema que se desarrollará en este proyecto es verificar la especificación de la capa web de la aplicación Duke’s Bank [BGJM] usando el formalismo propuesto en [CC06]. Este problema es interesante ya que la aplicación Duke’s Bank es una aplicación bancaria genérica con acceso web, lo cual permite extrapolar las conclusiones obtenidas a la mayorı́a de aplicaciones bancarias de este tipo. El primer objetivo de este segundo problema es verificar, usando comprobación de modelos, que la especificación dada en [BGJM] era correcta. El segundo objetivo era usar lo aprendido con este problema en particular para sentar las bases para el uso de comprobación de modelos junto con la herramienta presentada en [CC06], para verificar de manera automática la especificación de la capa web de cualquier aplicación.. 2.

(9) 1.2.2.. Por qué Spin. Existen varios comprobadores de modelos, unos de propósito general y otros de propósito especı́fico. Para este trabajo se decidió usar SPIN. SPIN por sus siglas en inglés significa “Simple Promela Interpreter”, esté se lleva desarrollando desde 1995. Las razones para usar SPIN sobre otros comprobadores de modelos son las siguientes: SPIN es de código abierto y gratuito, lo cual se ajusta perfectamente al perfil del proyecto. SPIN está en continuo desarrollo luego posibles problemas que no se puedan resolver con las versiones actuales pueden ser resueltos en un futuro con algoritmos más eficientes. SPIN ha sido usado de manera satisfactoria en proyectos reales como en el control de las compuertas en una represa[Kar96] y en el Mars Rover [SECH98]. PROMELA Promela es el lenguaje en el que se describen los modelos en SPIN, por sus siglas en inglés significa Process Meta-Language. Este es un lenguaje basado en procesos asincrónicos, canales de mensajes y estructuras de control basadas en guardas no deterministas[Hol03]. Promela no es en realidad un lenguaje de programación sino que es un lenguage para describir el funcionamiento de un sistema[Hol03]. La razón por la cual no puede ser considerado como un lenguaje de programación es que no tiene manejo de memoria y tampoco tiene forma de manejar el punto flotante[Hol03].. 1.3.. Descripción de los Capı́tulos. En el capı́tulo 2 se encuentra una descripción del problema teórico que implica hacer comprobación de modelos. En esté se explican los fundamentos matemáticos de comprobación de modelos. En los capı́tulos 4 y 5 se hace una instanciación de lo mostrado en el capı́tulo 3, para los dos problemas mencionados anteriormente. Finalmente en el capı́tulo 6 se realizan las conclusiones de este trabajo y se presentan sugerencias para trabajos futuros.. 3.

(10) Capı́tulo 2 Marco Teórico 2.1.. Comprobación de Modelos. La comprobación de modelos tiene su fundamento en la Lógica. En general, en Lógica un modelo es la instanciación de algo más abstracto. Por ejemplo, en lógica de primer orden un modelo es una estructura sobre un lenguaje de primer orden que incluye relaciones, funciones n-arias y constantes [Cai90]. En lógica modal un modelo es la instanciación de un marco, es decir, un modelo consta de una asignación de letras atómicas a un conjunto de estados, los cuales se pueden ver como vértices en un grafo dirigido[BRV01]. Teóricamente el problema consiste en que, dado un marco F finito, el cual se puede entender como la abstracción de un problema real (protocolo, sistema o programa) y dada una fórmula φ en lógica temporal, se desea comprobar si F |= φ. Es decir si en todos los posibles modelos (los cuales se pueden entender como posibles ejecuciones del programa) M de F vale que M |= φ. En el caso contrario, que se encuentre algún modelo M tal que M 6|= φ, entonces este modelo representa una traza en la cual no se cumplió la fórmula φ.. 2.2.. Lógica Temporal. La lógica temporal es un tipo de lógica modal[BRV01] la cual fue desarrollada por filósofos para razonar acerca del tiempo pero sin tener que hacer alusión cuantitativa al mismo. Ésta fue utilizada por primera vez para razonar sobre programas concurrentes en [Pnu77]. Esta lógica consta de dos relaciones F y P las cuales están asociadas al futuro y al pasado respectivamente. Cada una de estas relaciones tiene asociados dos operadores ♦ y . Las fórmulas de lógica temporal conforman el conjunto L más pequeño de fórmulas bien formadas tal que todas las letras proposicionales están en L, y además se tiene que si φ y ψ están en L también lo están: φ∧ψ 4.

(11) φ∨ψ φ→ψ ¬φ hF iφ [F ]φ hP iφ [P ]φ Existen variantes de la lógica temporal entre ellas CTL(Computational Tree Logic) y LTL (Linear Temporal Logic) ; esta última es la que se usa en este documento, debido a que es una de las formas de especificación de SPIN.. 2.2.1.. Linear Temporal Logic. Esta lógica es una extensión de la lógica temporal básica, la cual se usa para razonar acerca de secuencias de estados en la ejecución de un programa. En este caso sólo se tiene una relación (pasar de un estado a otro). Un modelo de esta lógica es una tupla(S, R, L), donde S es un conjunto de estados, R es la relación de estados y L es una función tal que L : S → 2AP , donde AP es el conjunto de letras átomicas. Si π es una secuencia finita de estados s0 , s1 , . . . , sn , tal que sj Rsj+1 para todo j. Se define inductivamente π, si |= φ, ası́[CGP99]: π, si |= T siempre. π, si |=⊥ nunca. Si p es una letra atómica, π, si |= p si y sólo si p ∈ L(si ) π |= ψ ∧ α si y sólo si π |= ψ y π |= α π |= ψ ∨ α si y sólo si π |= ψ o π |= α π |= ψ → α si y sólo si π |= ψ implica π |= α. π |= ¬ψ si y sólo si π 6|= ψ π, si |= Xψ si y sólo si π, si+1 |= ψ π, si |= ♦ψ si y sólo si existe j ≥ i tal que π, sj |= ψ π, si |= ψ si y sólo si para todo j ≥ i se tiene que π, sj |= ψ 5.

(12) π, si |= φUψ si y sólo si existe k ≥ i tal que π, sk |= ψ y para todo j tal que i ≤ j < k se tiene que π, sj |= φ Finalmente en [CGP99] se demuestra que es posible verificar si un modelo cumple o no con una fórmula en tiempo polinomial, en el tamaño del modelo. El problema radica en que es necesario tener el modelo completo en memoria para hacer esto, lo cual resulta difı́cil para modelos de mas de 1020 estados.. 6.

(13) Capı́tulo 3 Como abordar verificación usando CM 3.1.. Introducción. En este capı́tulo se presentan los pasos generales a seguir para usar comprobación de modelos en un problema especı́fico. Según [CGP99] la comprobación de modelos es un proceso que consta de tres pasos: modelaje, especificación y verificación. En este documento se propone que para usar comprobación de modelos es necesario algunos pasos de más. Según el autor, el algoritmo a seguir para usar comprobación de modelos consiste en planteo, modelaje, especificación, reducción y verificación.. 3.2.. Planteo del Problema. El planteo del problema consiste en poner en términos del lenguaje natural los aspectos relevantes del problema.. 3.3.. Modelaje. Esta etapa pretende formalizar lo expuesto en el paso anterior, mediante la expresión de los aspectos relevantes del problema, en términos del lenguaje del comprobador de modelos, en este caso de PROMELA. La otra razón por la cual la fase de modelaje se diferencia de la de planteo es que en este paso se requiere garantizar que el modelo resultante sea finito, ya que la comprobación de modelos es una técnica que sólo se puede usar cuando se tienen modelos finitos [CGP99].. 3.4.. Especificación. Una vez que se tiene un modelo finito, el siguiente paso es enunciar los requerimientos que se esperarı́a que éste cumpliera. Éstos pueden ser enunciados en un primer momento 7.

(14) en lenguaje natural y usando el modelo que se obtuvo del paso anterior al traducir los requerimientos a fórmulas de LTL (Linear Temporal Logic).. 3.5.. Reducción. Esta etapa consiste en determinar qué partes del modelo se pueden reducir sin perder expresividad y usar herramientas matemáticas para no tener que hacer la totalidad de la verificación usando sólo recursos computacionales. Este paso es muy importante ya que el mayor desafı́o que presenta hoy en dı́a la comprobación de modelos es la explosión de estados [CGP99], aspecto que se pretende solucionar en esta fase.. 3.6.. Verificación. La verificación consiste en el uso de un comprobador de modelos (en este caso SPIN), para hacer una verificación exhaustiva, buscando establecer si el modelo planteado cumple con la especificación. En general, esta etapa es la que requiere menos intervención humana, es decir, una vez que se tiene un modelo finito y no se tienen limitaciones de capacidad instalada (memoria y procesamiento), sólo es necesario correr el comprobador de modelos y éste eventualmente terminará. Cuando termine la verificación, si se obtiene una respuesta positiva, se puede concluir que el modelo cumple con la especificación; en caso de obtener una respuesta negativa, se obtiene una traza de eventos en la cual no se cumple el requerimiento especificado. En el segundo caso, es necesario revisar la traza de eventos y corregir el modelo original para volver a hacer la verificación hasta que se obtenga una respuesta positiva.. 8.

(15) Capı́tulo 4 Problema del Ascensor 4.1.. Introducción. Antes de la llegada de los ascensores y las escaleras eléctricas, los pisos superiores de los edificios eran los menos cotizados. Después de la llegada de los ascensores, la situación se revirtió. Hoy en dı́a estos hacen parte de la construcción básica de los edificios, dando por sentado su adecuado funcionamiento. Sin embargo, vale la pena preguntarse qué significa que un ascensor funcione “adecuadamente”; cambiarı́a esta pregunta si en vez de un ascensor se tienen varios? Esta pregunta será resuelta en la sección 4.3, pero antes será necesario entender la composición del modelo de un ascensor. Ver la sección 4.2. Una vez que se tiene el modelo de ascensor y se sabe que significa que un ascensor funcione adecuadamente, el paso natural es preguntarse si existe una manera de garantizar que un ascensor dado se comporte “adecuadamente”. La respuesta es positiva y la técnica a usar será la comprobación de modelos(ing. Model Checking). Pero antes de hacer comprobación de modelos es necesario hacer dos cosas: tener el modelo del comportamiento de un ascensor y realizar la traducción de la especificación hecha en la sección 4.3 a LTL(Linear Temporal Logic). Lo primero se hará en la sección 4.4 y lo segundo se hará en la sección 4.5. Por ultimó se presentará en la sección 4.6 el uso de herramientas matemáticas para extender los resultados obtenidos en este capı́tulo.. 4.2.. Modelo de Ascensor. El modelo de ascensor que se usa está basado en el modelo de [Knu97] compuesto de los siguientes elementos: 1. Un número de pisos fijo (N ), un piso inferior (PisoInf ) y un piso superior (PisoSup). Donde se cumplen las siguientes condiciones: N = P isoSup − P isoInf + 1 9.

(16) 0 ≤ P isoInf 0. 3. Un piso en el que se encuentra cada ascensor, el cual se notará como floor[j]. En este modelo, el ascensor siempre está en un piso (no entre dos), donde se cumplen las siguientes condiciones: P isoInf ≤ f loor[j] ≤ P isoSup 0≤j<M 4. Dos botones en cada piso para llamar al ascensor: uno para subir y otro para bajar, los botones se notan por callUp[i] y callDown[i] respectivamente indican que el botón de subir(resp. bajar) en el piso i está prendido. Donde se cumplen las siguientes condiciones: callUp[i] ∈ Z2 ∧ callDown[i] ∈ Z2 P isoInf ≤ i ≤ P isoSup 5. Un conjunto de botones dentro de cada ascensor (uno por cada piso) los cuales sirven para que un usuario dentro del ascensor le comunique al ascensor hacia cuál piso se dirige. Cada botón se nota ası́: callCar[j][i], lo cual significa que el botón en el ascensor j para ir al piso i está encendido. Donde se cumplen las siguientes condiciones: callCar[j][i] ∈ Z2 0≤j<M P isoInf ≤ i ≤ P isoSup 6. Una puerta por ascensor, la cual estará controlada solamente por el ascensor1 y puede estar abierta o cerrada. La puerta de cada ascensor se notará por door[j]. Y se cumplen las siguientes condiciones: door[j] ∈ Z2 0≤j<M 7. Una caja donde se suben los usuarios. 8. Una conjunto fijo de peticiones2 privadas por ascensor. El conjunto de peticiones privadas del ascensor j se nota por peticiones[j]. Y se cumplen las siguientes condiciones: 1. De lo contrario, un usuario podrı́a impedir que el ascensor se moviera abriendo indefinidamente la puerta Petición significa que se prende alguno de los botones fuera del ascensor o que se prende alguno de los botones dentro del mismo. Cada petición tiene asignado un piso, en el primer caso el número del piso donde se presionó el botón y en el segundo el piso asociado con el botón. Una petición para el piso i se nota por la peticion[i] y puede estar en dos estados: atendida o no. 2. 10.

(17) 0≤j<M peticiones[j] es un arreglo de peticiones de tamaño N. peticion[i] ∈ Z2 9. Dos listas de peticiones, las cuales son comunes a todos los ascensores; éstas contienen peticiones generadas por usuarios fuera del ascensor que desean subir(resp. bajar). Las listas se notan por peticionesComunesSubida y por peticionesComunesBajada . Se cumplen las siguientes condiciones: peticionesComunesSubida y peticionesComunesBajada son arreglos de tamaño N 10. La dirección en la que el ascensor se está moviendo(arriba, abajo o neutral). Ésta se nota por dir[j]. Y se cumplen las siguientes condiciones: dir[j] ∈ Z3 0≤j<M. 4.2.1.. Tamaño teórico del Modelo. Una vez que se tiene el modelo anterior es posible calcular cual es el tamaño del modelo en numero de estados, basta con hacer el producto de los tamaños de las variables que intervienen en el modelo. Esto dara un estimado teórico del modelo que se tendra. Tamaño teórico del modelo ≈ N M × 2M × 2N × 2N × (2N )M × 3M estados Esta resultado se sigue del siguiente razonamiento: N M . Debido a que cada ascensor está en un piso y hay N pisos posibles. 2M . Debido a que cada ascensor tiene la puerta abierta o cerrada. 2N . Debido a que los botones en cada piso que son usados para llamar al ascensor para subir pueden estar prendidos o apagados. 2N . Debido a que los botones en cada piso que son usados para llamar al ascensor para bajar pueden estar prendidos o apagados. (2N )M . Debido a que dentro de cada ascensor hay N botones cada uno de los cuales puede estar prendido o apagado. 3M . Debido a que cada ascensor está en una de tres direcciones. Este cálculo permite evidenciar que si se fijan M y N, entonces se tiene un modelo finito y por ende es factible usar comprobación de modelos [CGP99]. 11.

(18) 4.3.. Requerimientos del Ascensor. Una vez que se tienen los elementos que componen un modelo, el siguiente paso es decidir que requerimientos (especificación) debe cumplir un modelo de ascensor. Los requerimientos están divididos en tres grupos: seguridad (ing .safety) ,vivacidad (ing. liveness) y eficiencia.. 4.3.1.. Requerimientos de Seguridad. Los requerimientos de seguridad son predicados sobre los estados del modelo y hacen referencia a que nada “malo” pasa y por malo se entiende lo siguiente: 1. Rango El ascensor nunca sube cuando ya está en el último piso ni intenta bajar cuando ya está en el primero, es decir que el ascensor siempre está entre el primer y el último piso. 2. Puertas El ascensor no se mueve con las puertas abiertas. 3. Deadlocks El ascensor no se traba o está libre de abrazos de la muerte (ing .deadlocks); es decir que siempre tiene una acción ejecutable. 4. Tridirección El ascensor tiene una de tres direcciones: Subiendo, Bajando o Neutral. 5. CambioDirección El ascensor cambia en dirección subiendo (resp. bajando) no cambia de dirección si y solo si todavı́a le quedan peticiones privadas arriba (resp. abajo).. 4.3.2.. Requerimientos de Vivacidad. Los requerimientos de vivacidad son predicados sobre secuencias de estados del modelo y hacen referencia a que eventualmente pasa algo “bueno” y por bueno se entiende lo siguiente: 1. PeticionPublica Después de que un usuario en un piso presiona el botón de subir o bajar (la petición común de subida o bajada cambia su estado a no atendida), eventualmente algún ascensor llegará al piso donde se hizo la petición y el ascensor abre las puertas en ese piso. 2. PeticionPrivada Después de que un usuario selecciona el piso al que quiere ir (la petición privada de ese piso para ese ascensor cambia su estado a no atendida) el ascensor eventualmente llegará a ese piso y le da la posibilidad al usuario de salir(abre la puerta). 3. PeticionParada Después de que un usuario selecciona el piso al que quiere ir (la petición privada de ese piso para ese ascensor cambia su estado a no atendida) el ascensor eventualmente llegará a ese piso y no pasa por el piso sin parar en éste. 4. Giros Después de que un usuario selecciona el piso al que quiere ir (la petición privada de ese piso para ese ascensor cambia su estado a no atendida) el ascensor eventualmente llegará a ese piso y como máximo cambia dos veces de dirección. 12.

(19) 4.3.3.. Requerimientos de Eficiencia. Al igual que los requerimientos de vivacidad, los requerimientos de eficiencia hacen referencia a secuencias de estados, pero a diferencia de los primeros, éstos no sólo hacen referencia a que algo bueno eventualmente pase sino que además esto sucede utilizando la menor cantidad de recursos. En este caso sólo se tendrá un requerimiento: Después de que se realiza una petición, el ascensor toma la ruta más corta al piso de la petición. Para definir la ruta más corta se tienen en cuenta dos casos: 1. Si el ascensor está subiendo (resp. bajando) y el piso asociado a la petición se encuentra más arriba (resp. abajo) de su posición actual la ruta más corta a la petición es simplemente seguir subiendo hasta llegar al piso de la petición. 2. Si el ascensor está subiendo (resp. bajando) y el piso asociado a la petición se encuentra abajo (resp. arriba) de su posición actual, entonces la ruta más corta es subir (resp. bajar) hasta la petición con piso mayor (resp. menor) y luego bajar (resp. subir) al menos hasta el piso de la petición. El problema con este requerimiento es que el cálculo de la ruta más corta es imposible usando comprobación de modelos ya que en un mismo estado la ruta más corta puede cambiar varias veces. Es por esta razón que este requerimiento de aquı́ en adelante será opcional.. 4.3.4.. Independencia de los Requerimientos. Una observación detenida de los requerimientos permite evidenciar que salvo el requerimiento de PeticionPublica todos los otros hacen referencia a un ascensor como entidad independiente que atiende sus solicitudes. Usando este hecho y que el número de estados en el modelo crece exponencialmente con el número de ascensores (sección 4.2.1) se decidió crear un modelo con un solo ascensor y verificar que este cumpla todos los requerimientos excepto por el requerimiento de PeticionPublica. Para crear este modelo se usa una aproximación incremental3 . Una vez que se tenga un modelo que cumple con todos los requerimientos excepto con el requerimiento de PeticionPublica se pueden combinar M de estos modelos y verificar que se cumple el requerimiento de PeticionPublica. Dado que no se tendrá en cuenta el requerimiento de PeticionPublica en la construcción del modelo, se va a usar una reformulación de este requerimiento para un solo ascensor: Después de que un usuario en un piso presiona el botón de subir o bajar, eventualmente el ascensor llegará al piso donde se hizo la petición y abrirá las puertas en ese piso. 3. Se empieza por un modelo que cumpla el primer requerimiento y este se va mejorando hasta que cumpla con cada uno de los requerimientos. 13.

(20) 4.3.5.. Completitud de la Especificación. Cuando se termina la lista de requerimientos es natural preguntar si éstos son todos, es decir si cualquier ascensor que cumpla éstos se puede catalogar como un ascensor “bueno”, porque es claro que un ascensor “bueno” cumple con estos requerimientos. Se decide que ésta es la lista porque comprende todos los aspectos: desde el punto de vista del cliente (eventualmente lo atienden), eficiencia (escoge la ruta más corta y atiende las peticiones sin dar “muchas” vueltas) y disponibilidad (no se traba). Luego, tiene sentido detenerse en esta lista aunque claramente no se está diciendo que ésta sea la “lista” sino que ésta es una lista que abarca los suficientes aspectos como para sentirse seguro de que un ascensor que cumpla con estos requerimientos satisfarı́a la mayorı́a de necesidades.. 4.4.. Tipos de Ascensor. Una vez que se tienen los requerimientos se busca tener un modelo de ascensor que cumpla con todos ellos (excepto con el requerimiento de eficiencia). Un ascensor que se queda quieto abriendo y cerrando las puertas indefinidamente cumplirı́a con todos los requerimientos de seguridad pero falları́a en cumplir todos los de vivacidad. Todos los modelos de ascensor que se presentarán cumplen con el requerimiento de Deadlock, aunque esto no se mencione explı́citamente en cada modelo.. 4.4.1.. AMS. Un modelo sencillo de ascensor que cumpla “trivialmente” con todos los requerimientos excepto con los requerimientos de eficiencia y de CambioDirección, consiste en un ascensor que pasa por todos los pisos independiente de las peticiones que tenga y en cada piso abre y cierra las puertas. A este modelo lo llamaremos AMS (Ascensor más Simple) y su funcionamiento es el siguiente: 1. Inicia en el primer piso Pisoinf con las puertas abiertas. 2. Cierra las puertas, sube un piso, abre las puertas y repite el proceso cada piso hasta que llega a PisoSup. 3. Una vez que está en el piso PisoSup, abre las puertas, cierra las puertas y desciende(disminuye un piso). 4. Abre las puertas, cierra las puertas y baja un piso. Repite el proceso en cada piso hasta que llega al piso PisoInf. 5. En el piso Pisoinf abre las puertas y vuelve al estado 1.. 14.

(21) Algoritmo 1 AMS 1: piso, puerta ← P isoInf, abierta 2: while true do 3: while piso P isoInf do 9: puerta ← cerrada 10: piso ← piso − 1 11: puerta ← abierta 12: end while 13: end while Satisfacción Requerimientos AMS Ahora es necesario verificar que AMS satisface los requerimientos mencionados en la sección 4.3. 1. El requerimiento de Rango se cumple por las condiciones en los ciclos. 2. El requerimiento de Puertas se cumple porque las puertas se cierran antes de moverse. 3. El requerimiento de Deadlock se cumple ya que el ascensor sigue un recorrido lineal y por el requerimiento del rango siempre encontrará una acción ejecutable. 4. El requerimiento de Tridirección se cumple trivialmente. 5. El requerimiento de CambioDirección no se cumple debido a que el ascensor puede eventualmente subir (resp. bajar) sin tener peticiones arriba (resp. bajar). 6. Los requerimientos de vivacidad se cumplen debido a que el ascensor pasa por todos los pisos siguiendo un recorrido lineal, abriendo las puertas en todos los pisos. Luego, dado que tiene finitos pisos, eventualmente atenderá todas las peticiones y nunca hará más de dos cambios de dirección para atender una petición.. 4.4.2.. Ascensor Rango. Se buscaba que este ascensor cumpliera solo con el requerimiento de Rango, luego únicamente se tomó la variable de piso en cuenta. El funcionamiento de este ascensor es el siguiente:. 15.

(22) Algoritmo 2 Ascensor Rango 1: piso ← pisoInf 2: while true do 3: while piso P isoInf do 7: piso ← piso − 1 8: end while 9: end while. 4.4.3.. Ascensor Puertas. Este ascensor es un refinamiento del modelo Ascensor Rango y cumple los requerimientos de Rango y Puertas. El funcionamiento de este ascensor es el siguiente: Algoritmo 3 Ascensor Puertas 1: piso, door ← pisoInf, cerrada 2: while true do 3: while piso P isoInf do 7: piso ← piso − 1 8: end while 9: end while. 4.4.4.. Ascensor Tridirección. Este ascensor es un refinamiento del modelo Ascensor Puertas y cumple con los requerimientos de Rango, Puertas y TriDirección. El funcionamiento del ascensor es el siguiente:. 4.4.5.. Ascensor CambioDirección. Este ascensor es un refinamiento del modelo Ascensor Tridirección y cumple con los requerimientos de Rango, Puertas, TriDirección y CambioDirección. El funcionamiento del ascensor es el siguiente:. 16.

(23) Algoritmo 4 Ascensor Tridirección 1: piso, door, dir ← pisoInf, cerrada, neutral 2: while true do 3: while piso P isoInf do 8: dir ← bajando 9: piso ← piso − 1 10: end while 11: end while Algoritmo 5 Ascensor CambioDirección 1: piso, door, dir ← pisoInf, cerrada, neutral 2: while true do 3: while dir = subiendo do 4: if (∃i : P isoSup ≥ i > piso : ¬peticion[i]) then 5: dir ← subiendo 6: piso ← piso + 1 7: else 8: dir ← neutral 9: end if 10: end while 11: while dir = bajando do 12: if (∃i : P isoInf ≤ i < piso : ¬peticion[i]) then 13: dir ← bajando 14: piso ← piso − 1 15: else 16: dir ← neutral 17: end if 18: end while 19: while dir = neutral do 20: if (∃i : P isoSup ≥ i > piso : ¬peticion[i]) then 21: dir ← subiendo 22: else if (∃i : P isoInf ≤ i < piso : ¬peticion[i]) then 23: dir ← bajando 24: else 25: dir ← neutral 26: end if 27: end while 28: end while 17.

(24) 4.4.6.. Ascensor Petición Publica. Este ascensor es un refinamiento del modelo Ascensor CambioDirección y cumple con los requerimeintos de Rango, Puertas, TriDirección, CambioDirección y PeticionPublica(para un ascensor).. 4.4.7.. Ascensor Petición Privada. Este ascensor es un refinamiento del modelo Ascensor Petición Publica y cumple con los requerimeintos de Rango, Puertas, TriDirección, CambioDirección, PeticionPublica(para un ascensor) y PeticionPrivada.. 4.4.8.. Ascensor PeticionParada y Giros. Usando comprobación de modelos, se puede verificar que el modelo anterior también cumple con los requerimientos de PeticionParada y Giros.. 4.5.. Requerimientos en LTL. Como el objetivo final es construir y verificar un modelo de ascensor usando comprobación de modelos, el paso natural a seguir es expresar los requerimientos en términos de formulas de LTL.. 4.5.1.. Definiciones. 1. giros[j] representa el número de cambios de direccion que ha tenido el ascensor j. 2. T representa una proposición que siempre es verdadera(ej. falso=falso).. 4.5.2.. Requerimientos en LTL para un ascensor. Para empezar, se expresan los requerimientos en términos de los botones y como si sólo se tuviera un ascensor. 1. Requerimiento de Rango: (pisoInf ≤ f loor ∧ f loor ≤ pisoSup) 2. Requerimiento de Puertas: ((f loor = i ∧ door) → (f loor = i U ¬door)) 3. Requerimiento de Deadlock: Este requerimiento se verificara usando invalid end states. 18.

(25) Algoritmo 6 Ascensor Petición Publica 1: piso, door, dir ← pisoInf, cerrada, neutral 2: while true do 3: while dir = subiendo do 4: if (∃i : P isoSup ≥ i > piso : ¬peticion[i] ∨ ¬peticionP ublicaSubida[i] ¬peticionP ublicaBajada[i]) then 5: if ¬peticionP ublicaSubida[i] then 6: door ← abierta 7: peticionP ublicaSubida[i] ← ¬peticionP ublicaSubida[i] 8: door ← cerrada 9: end if 10: dir ← subiendo 11: piso ← piso + 1 12: else 13: dir ← neutral 14: end if 15: end while 16: while dir = bajando do 17: if (∃i : P isoInf ≤ i < piso : ¬peticion[i] ∨ ¬peticionP ublicaSubida[i] ¬peticionP ublicaBajada[i]) then 18: if ¬peticionP ublicaBajada[i] then 19: door ← abierta 20: peticionP ublicaBajada[i] ← ¬peticionP ublicaBajada[i] 21: door ← cerrada 22: end if 23: dir ← bajando 24: piso ← piso − 1 25: else 26: dir ← neutral 27: end if 28: end while 29: while dir = neutral do 30: if (∃i : P isoSup ≥ i > piso : ¬peticion[i] ∨ ¬peticionP ublicaSubida[i] ¬peticionP ublicaBajada[i]) then 31: dir ← subiendo 32: else if (∃i : P isoInf ≤ i < piso : ¬peticion[i] ∨ ¬peticionP ublicaSubida[i] ¬peticionP ublicaBajada[i]) then 33: dir ← bajando 34: else 35: dir ← neutral 36: end if 37: end while 38: end while 19. ∨. ∨. ∨. ∨.

(26) Algoritmo 7 Ascensor Petición Privada 1: piso, door, dir ← pisoInf, cerrada, neutral 2: while true do 3: while dir = subiendo do 4: if (∃i : P isoSup ≥ i > piso : ¬peticion[i] ∨ ¬peticionP ublicaSubida[i] ¬peticionP ublicaBajada[i]) then 5: if ¬peticionP ublicaSubida[i] ∨ ¬peticion[i] then 6: door ← abierta 7: peticionP ublicaSubida[i], peticion[i] ← true, true 8: door ← cerrada 9: end if 10: dir ← subiendo 11: piso ← piso + 1 12: else 13: dir ← neutral 14: end if 15: end while 16: while dir = bajando do 17: if (∃i : pisoInf ≤ i < piso : ¬peticion[i] ∨ ¬peticionP ublicaSubida[i] ¬peticionP ublicaBajada[i]) then 18: if ¬peticionP ublicaBajada[i] ∨ ¬peticion[i] then 19: door ← abierta 20: peticionP ublicaBajada[i], peticion[i] ← true, true 21: door ← cerrada 22: end if 23: dir ← bajando 24: piso ← piso − 1 25: else 26: dir ← neutral 27: end if 28: end while 29: while dir = neutral do 30: if (∃i > piso : ¬peticion[i] ∨ ¬peticionP ublicaSubida[i] ¬peticionP ublicaBajada[i]) then 31: dir ← subiendo 32: else if (∃i < piso : ¬peticion[i] ∨ ¬peticionP ublicaSubida[i] ¬peticionP ublicaBajada[i]) then 33: dir ← bajando 34: else 35: dir ← neutral 36: end if 37: end while 38: end while 20. ∨. ∨. ∨. ∨.

(27) 4. Requerimiento de TriEstado: (dir = gup ∨ dir = gdown ∨ dir = neutral) 5. El requerimiento PeticionPublica modificado para un ascensor: ((callUp[i] ∨ callDown[i]) → ♦(f loor = i ∧ door)) 6. El requerimiento de PeticionPrivada: (callCar[i] → ♦(f loor = i ∧ door)) 7. El requerimiento de PeticionParada: (callCar[i] → ♦(f loor = i) ∧ ((callCar[i] ∧ f loor = i) → door))) 8. El requerimiento de Giros: (callCar[i] ∧ giros = giros0 → ♦(f loor = i ∧ (giros − giros0 ≤ 2) ∧ door)). 4.5.3.. Requerimientos de vivacidad en formulas de LTL para un ascensor usando peticiones. En la anterior sección se hizo la formulación de los requerimientos de vivacidad para un ascensor usando peticiones de manera indirecta (en los requerimientos de vivacidad el antecedente de la fórmula siempre está asociado a una petición). Si se desea extender el modelo a varios ascensores, es mejor expresar estos requerimientos en términos de peticiones ya que por lo discutido en 4.3.4 una vez que se tiene el modelo con peticiones para un ascensor, es fácil verificar un modelo con varios ascensores en paralelo. Los requerimientos de vivacidad para un ascensor usando peticiones son: 1. El requerimiento de PeticionPublica modificado para un ascensor: ((peticion[i] ∈ peticionesComunesSubida ∧ ¬peticion[i]) → ♦(f loor = i ∧ door)) ((peticion[i] ∈ peticionesComunesBajada ∧ ¬peticion[i]) → ♦(f loor = i ∧ door)) 2. El requerimiento de PeticionPrivada: (peticion[i] ∈ peticiones ∧ ¬peticion[i] → ♦(f loor = i ∧ door)) 3. El requerimiento de PeticionParada: (peticion[i] ∈ peticiones ∧ ¬peticion[i] → ♦(f loor = i) ∧ ((¬peticion[i] ∧ f loor = i) → door)) 4. El requerimiento de Giros: (peticion[i] ∈ peticiones ∧ ¬peticion[i] ∧ giros = giros0 → ♦(f loor = i ∧ (giros − giros0 ≤ 2) ∧ door)) 21.

(28) 4.6. 4.6.1.. Simulaciones Simulacion caso general. Dado que la comprobación de modelos solo permite verificar un modelo de ascensor finito y fijo, que el tiempo de verificación se incrementa con el número de pisos como se evidencia en el siguiente cuadro y en la fórmula teórica del modelo dada en la sección 4.2.1, y que la especificación es necesario rehacerla cada vez que cambia el número de pisos. Se desearı́a poder tener un método en el que una vez que se han verificado los requerimientos para cierto número de casos, éste concluya, que el modelo servirı́a para un ascensor de cualquier tamaño. Para ello, se utiliza el método de inducción sobre el número de pisos. Esta comprobación es suficiente para afirmar que las propiedades verificadas se satisfacen en situaciones análogas pero más complicadas (ej. más pisos o más ascensores). Número de Pisos 1 2 3 4 5. Tiempo (seg) 9,43 19, 6 32, 5 43, 64 54, 2. Número de Estados 2, 53 ∗ 106 5, 21 ∗ 106 8, 57 ∗ 106 1, 15 ∗ 107 1, 43 ∗ 107. Cuadro 4.1: Número de Estados vs Número de Pisos en la comprobación del segundo requerimiento de seguridad. Caso Base El caso base de la inducción ya se probó para ascensores de (1,2,3,4 o 5) pisos usando comprobación de modelos. Hipótesis de Inducción Para un ascensor de k pisos con k ≤ n el ascensor cumple con todos los requerimientos expresados en la sección 4.3. Caso Inductivo La idea de la demostración es tener dos modelos de n pisos a1 y a2 de tal manera que el primero no diferencie entre el piso n y el n + 1 y el segundo no diferencie entre el piso 1 y el piso 2. Se tiene un ascensor de n + 1 pisos que llamaremos A. Si no hay peticiones desde o hacia el piso n + 1, el ascensor es similar a a1 con A.pisoSup − 1 = a1 .pisoSup. Si hay peticiones desde o hacia el piso n + 1 el ascensor A es similar a a2 teniendo en cuenta que a2 .pisoInf = A.pisoSup + 1.. 22.

(29) Luego el último caso que queda probar es que si se está en A.pisoInf y se tiene una petición para A.pisoSup ésta se cumple; por la HI se tiene que si se realiza una petición en a1 .pisoSup cuando a1 esta en a1 .pisoInf ésta se va a cumplir y además, se tiene que si el ascensor a2 está en el piso a2 .P isoSup − 1, este va a cumplir una petición en el piso a2 .pisoSup, finalmente como A.pisoSup = a2 .pisoSup y A.pisoInf = a1 .pisoInf entonces se tiene que A cumplirı́a con la petición hecha en este caso.. 4.6.2.. Morfismo de relación de subir y bajar. Una lectura cuidadosa de la sección anterior evidenciarı́a una posible falla ya que solo se está considerando la relación de subir omitiendo que el ascensor también puede bajar. En esta sección se soluciona el problema haciendo uso de una herramienta de la lógica modal llamada morfismo acotado. Usando un morfismo acotado, mostraremos que dos modelos con igual número de pisos, y uno que sube y el otro que baja cumplen las mismas propiedades en los estados “homomorfos”. Sea M el modelo con la relación de subir y sea M’ el modelo con la relación de bajar entonces definimos f ası́:  Si piso = n − 1  0 n−1 Si piso = 0 f (piso) =  n − 1 − piso Si 1 < piso < n − 1 En este caso, el conjunto de letras atómicas será Atom = {pisoInterm, pisoExtremo} y tenemos que: M, 0 |= pisoExtremo M 0 , 0 |= pisoExtremo M, n − 1 |= pisoExtremo M 0 , n − 1 |= pisoExtremo M, i |= pisoInterm M 0 , i |= pisoInterm Para 0 < i < n − 1 Con la asignación de las letras atómicas es claro que tanto i como f (i) cumplen las mismas letras proposicionales. Si se llama a la relación del primer modelo como R y a la del segundo como R0 se tiene que iRi + 1 y que jR0 j − 1. Lo primero que hay que probar es que si iRi + 1 entonces f (i)R0 f (i + 1), esto se hace por casos. 1. i=0 entonces se tiene que 0R1 y f (0) = n − 1 y f (1) = n − 2 y por la definición n − 1R0 (n − 1) − 1 2. 0 < i < n − 2 entonces se tiene que iRi+ 1 y f (i) = n−1 −i y f (i+ 1) = n−1 −(i+ 1) y por la definición n − 1 − iR0 (n − i − 1) − 1 3. i = n − 2 entonces se tiene que n − 2Rn − 1 y f (n − 2) = n − 1 − (n − 2) = 1 y f (n − 1) = 0 y por la definición 1R0 1 − 1 Finalmente hay que mostrar que si f (i)R0 j 0 entonces existe j tal que iRj y f (j) = j 0 . También se demuestra por casos: 1. i=0 entonces se tiene que f (0) = n − 1 luego j 0 = n − 2 y entonces j = 1 23.

(30) 2. 0 < i < n − 2 entonces se tiene que f (i) = n − 1 − i y j 0 = n − i − 2 y entonces j = i + 1 3. i = n − 2 entonces j = n − 1 Con lo que queda demostrado que los dos modelos son “homomorfos” y luego se justifica lo que se hizo anteriormente de sólo tener en cuenta la relación de subir.. 24.

(31) Capı́tulo 5 Problema Web 5.1.. Introducción. Hasta hace unos años las aplicaciones web no eran muy variadas ni muy complejas, pero con el advenimiento de los clientes “livianos”, las aplicaciones web se han vuelto mucho más complejas y sus usos cada vez más variados. Este aumento en la complejidad hace necesario contar con una herramienta que permita garantizar el correcto funcionamiento de este tipo de aplicaciones. El primer problema que aparece cuando se desea garantizar el correcto funcionamiento de una aplicación web es definir la noción de corrección. Este problema ya esta bastante avanzado y aquı́ se usa la aproximación dada en [CC06]. Esta aproximación se basa en: un grafo de navegavilidad (modelo) y predicados lógicos cerrados de primer orden sobre los nodos y los arcos (especificación). El segundo problema radica en verificar que el modelo cumpla con la especificación. Esto se intenta realizar en este documento usando comprobación de modelos (ing . Model Checking). En este trabajo se muestra cómo se puede usar SPIN para realizar la verificación de la capa web de la aplicación Duke’s Bank [BGJM]. Lo primero que se realiza en la sección 5.2 es enumerar los componentes del modelo de la aplicación. Después en la sección 5.3 se completa la especificación de la aplicación web, la cual está parcialmente realizada en [CC06]. A continuación, en la sección 5.4 se muestra cómo esta especificación en particular puede ser “traducida” a un modelo finito y en particular cómo éste puede ser representado en PROMELA. Además se muestra en la sección 5.5 algunas consideraciones para realizar la verificación usando SPIN.. 5.2.. Modelo de la Aplicación. El modelo de una aplicación web según [CC06] consta de tres cosas básicas: Los nodos de un grafo, donde cada nodo representa una pagina de la aplicación. Un conjunto de acciones, donde una acción representa un conjunto de arcos del grafo. 25.

(32) Variables de la aplicación.. 5.2.1.. Grafo de Navegación. El grafo para la aplicación Duke’s Bank es el siguiente:. 2. 11. login. 1. logoff login. 8. 3. dotransfer. starttransfer. 5. listAccounts. starttransfer. 4. listAccounts listAccountHistory. startAtm. 6. 7. listAccounts. listAccounts starttransfer. listAccountHistoryDetail. listAccountHistory. listAccountHistory. 10. doAtm. startAtm. 9. doAtm. 5.2.2.. Los nodos de la aplicación. Los nodos de la aplicación son una tupla (identif icador, nombre). Para la aplicación Duke’s Bank los nodos son los siguientes: (1, logon) (2, logonError) (3, main) (4, accountList) (5, transferFunds) (6, atm) 26.

(33) (7, accountHist) (8, transferAck) (9, atmAck) (10, error) (11, logoff). 5.2.3.. Acciones de la aplicación. Si se tiene que el conjunto de nodos es N entonces cada acción es un subconjunto de N × N. Para la aplicación Duke’s Bank las acciones serán los siguientes: login {(1, 2), (1, 3)} listAccounts {(3, 4), (4, 4), (5, 4), (6, 4), (7, 4)} listAccountHistory {(4, 7), (7, 7), (4, 10), (7, 10)} listAccountHistoryDetail {(7, 7)} startTransfer {(3, 5), (4, 5), (6, 5), (7, 5)} doTransfer {(5, 8), (5, 10)} startAtm {(3, 6), (4, 6), (5, 6), (6, 6), (7, 6)} doAtm {(6, 9), (6, 10)} logoff {(3, 11), (4, 11), (5, 11), (6, 11), (7, 11), (8, 11), (9, 11), (10, 11)}. 5.2.4.. Variables de la aplicación. Las variables de la aplicación y sus descripciones (tomadas textualemente de [CC06]) son las siguientes: nUsr: Variable que almacena el nombre de usuario digitado. paswd: Variable que almacena la contraseña que el usuario digitó. error: Variable que almacena el error que ha sucedido en el lugar especı́fico de la aplicación. usr: Estructura de datos que almacena la información de un usuario que ha logrado acceso al sistema1 . 1. Un usuario logra acceso al sistema cuando digita correctamente su login y su password en el nodo logon. 27.

(34) ctasUsr: Conjunto de cuentas de un usuario. cta: Cuenta que ha sido seleccionada de alguna de las pantallas. movsCta: Conjunto de movimientos de una cuenta. verMtvts: Flag de despliegue en el nodo accountHist, que puede tomar uno de tres valores: todas las operaciones, débitos y créditos. Define los movimientos que se muestran. orden: Flag de despliegue en el nodo accountHist, que puede tomar uno de cuatro valores: fecha creciente, fecha decreciente, cantidad y descripción. Define en qué orden se muestran los movimientos. oFch: Selector de rango de fecha en el nodo accountHist. Toma uno de dos valores: fecha inicio y rango. Define si se quiere realizar la consulta de movimientos por rango de fecha o simplemente escogiendo una fecha inicial, tomando como fecha final, por defecto, la actual. fchD: Fecha inicial del rango. Alcance: petición. fchH: Fecha final del rango. Alcance: petición. ctaO: Cuenta seleccionada por el usuario como cuenta origen de la transferencia de fondos. ctaD: Cuenta seleccionada por el usuario como cuenta destino de la transferencia de fondos. mntTr: Monto de la transferencia. tpoOp: Operación escogida por el usuario. Puede ser retiro o consignación. Alcance: sesión. mntOp: Monto de la operación. Alcance: sesión.. 5.3.. Especificación de la aplicación. La especificación de una aplicación web según [CC06] consta de dos cosas básicas: Dos predicados por nodo, uno de entrada y uno de salida. Una precondición y una postcondición por acción. De aqui en adelante lo que se hace es completar la especificacion del Duke’s Bank dada en [CC06].. 28.

(35) 5.3.1.. Predicados de los nodos de la aplicación. Predicados de entrada Los predicados de entrada se notan ne , donde n es el número del nodo. Los predicados de entrada de los nodos de la aplicación son los siguientes: 1e ≡ true 2e ≡ usr =⊥ ∧ error 6=⊥ 3e ≡ nUsr 6=⊥ ∧ usr 6=⊥ ∧ usr.nombre = nUsr 4e ≡ usr 6=⊥ ∧ ctasUsr 6=⊥ ∧ (∀c ∈ ctasUsr : c.clienteId = usr.clienteId) 5e ≡ 4e 6e ≡ 4e ∧ cta 6=⊥ 7e ≡ usr 6=⊥ ∧ cta 6=⊥ 8e ≡ 5s ∧ error =⊥ 9e ≡ (tpoO = retiro ∨ tpoO = deposito) ∧ tpoO = mntOp > 0 ∧ cta 6=⊥ ∧(tpoO = retiro → cta.saldo ≥ monto) 10e ≡ error =⊥ 11e ≡ usr =⊥ Predicados de salida Los predicados de salida se notaran ns donde n es el numero del nodo. Los predicados de salida de los nodos de la aplicación son los siguientes: 1s ≡ nUsr 6=⊥ ∧ paswd 6=⊥ 2s ≡ true 3s ≡ 3e 4s ≡ 4e ∧ cta 6=⊥ ∧ cta ∈ ctasUsr 5s ≡ 5e ∧ ctaO 6=⊥ ∧ctaD 6=⊥ ∧ctaO ∈ ctasUsr ∧ ctaD ∈ ctasUsr ∈ ctaO 6= ctaD ∧ mntT r > 0 6s ≡ 6e ∧ tpoO 6=⊥ 7s ≡ 7e ∧ cta 6=⊥ ∧verMvts 6=⊥ ∧orden 6=⊥ ∧oF ch 6=⊥ ∧f cD 6=⊥ ∧f chH 6=⊥ 29.

(36) 8s ≡ 8e 9s ≡ true 10s ≡ true 11s ≡ true. 5.3.2.. Precondiciones y Postcondiciones de las acciones. Precondiciones Las precondiciones de las acciones se notan Qnombre de la acción , las precondiciones de las acciones para la aplicación son las siguientes: Qlogin ≡ true QlistAccounts ≡ usr 6=⊥ QlistAccountHistory ≡ usr 6=⊥ QlistAccountHistoryDetail ≡ cta 6=⊥ QstartT ransf er ≡ usr 6=⊥ QdoT ransf er ≡ ctaO 6=⊥ ∧ctaD 6=⊥ ∧ctaO ∈ ctasUsr ∧ ctaD ∈ ctasUsr ∧ ctaO 6= ctaD ∧ mntT r > 0 QstartAtm ≡ usr 6=⊥ QdoAtm ≡ cta 6=⊥ ∧tpoO 6=⊥ Qlogof f ≡ true Poscondiciones Las poscondiciones de las acciones se notan Rnombre de la acción ; las poscondiciones de las acciones para la aplicación son las siguientes: Rlogin ≡ (nUsr 6=⊥ ∧paswd 6=⊥ ∧usr 6=⊥ ∧usr.nombre = nUsr ∧ usr.paswd = paswd) ∨ (usr =⊥ ∧error 6=⊥) RlistAccounts ≡ ∀c ∈ ctasUsr : c.clienteId = usr.clienteId RlistAccountHistory ≡ cta 6=⊥ ∨ (cta =⊥ ∧ error 6=⊥) RlistAccountHistoyDetail ≡ (verMvts 6=⊥ ∧orden 6=⊥ ∧oF ch 6=⊥ ∧f cD 6=⊥ ∧f cH = 6 ⊥ ∧f cH > f cD) ∨ (¬(verMvts 6=⊥ ∧orden 6=⊥ ∧oF ch 6=⊥ ∧f cD 6=⊥ ∧f cH = 6 ⊥ ∧f cH > f cD) ∧ error 6=⊥) 30.

(37) RstartT ransf er ≡ usr 6=⊥ ∧ (∀c ∈ ctasUsr : c.clienteId = usr.clienteId) RdoT ransf er ≡ ctaO.saldo0 = ctaO.saldo−mntT r∧ctaD.saldo0 = ctaD.saldo+mntT r > 0 ∧ error 6=⊥ RstartAtm ≡ QstartAtm RdoAtm ≡ (tpoO = retiro ∧ cta.saldo ≤ mntOp ∧ cta.saldo0 = cta.saldo − mntOp) ∨ (tpoO = deposito ∧ cta.saldo0 = cta.saldo + mntOp) ∨ (tpoO = retiro ∧ ctasaldo < mntOp ∧ error) 6=⊥ Rlogof f ≡ usr =⊥. 5.4.. Reducción del Modelo. El modelo finito que se está utilizando está basado en las variables expuestas en la sección 5.2.4. El problema radica en que para usar comprobación de modelos es necesario tener un modelo finito[CGP99] y varias de las variables pueden tomar infinitos valores (ej. nUsr ). Se soluciona esto al establecer rangos finitos para las variables y luego mostrar que en cierto nivel no se pierde expresividad al acotar las variables.. 5.4.1.. Rangos Finitos de las Variables. Se usan los mismos nombres de las variables que en la sección 5.2.4, pero en general, de aquı́ en adelante, lo que se representa es el estado de la variable y no el valor de la variable. nUsr ∈ Z3 , donde 0 representa que el usuario deja la casilla en blanco, 1 que escribe el nombre de usuario correctamente y 2 que escribe un nombre de usuario incorrecto. paswd ∈ Z3 , donde 0 representa que el usuario deja la casilla en blanco, 1 que escribe la contraseña correcta y 2 que escribe la contraseña incorrecta. error ∈ Z2 , donde 0 representa que el error es vacı́o y el 1 lo contrario. usr: Se usa una estructura de datos que contiene los siguientes campos: • nombre ∈ Z3 , donde 0 representa que el nombre está vacı́o, 1 que el nombre no está vacı́o y es el mismo del nombre del usuario que logra ingresar al sistema, y 2 que el nombre no está vacı́o, pero no es el mismo del nombre del usuario que logra ingresar al sistema. • passwd ∈ Z3 , donde 0 representa que la contraseña está vacı́a, 1 que la contraseña no esta vacı́a y es la misma contraseña del usuario que logra ingresar al sistema y 2 que la contraseña está vacı́a, pero no coincide con la contraseña del usuario que logra ingresar al sistema.. 31.

(38) • clienteId ∈ Z3 , donde 0 representa que el Id del usuario está vacı́o, 1 que el Id del usuario no está vacı́o y es el del usuario que logra ingresar al sistema, y 2 que el id del usuario no está vacı́o, pero no coincide con el del usuario que logra ingresar al sistema cta: La cuenta es una estructura compuesta por los siguientes elementos: • clienteId ∈ Z3 , donde 0 representa que el Id del usuario está vacı́o, 1 que el Id del usuario no está vacı́o y es el del usuario que logra ingresar al sistema y 2 que el id del usuario no está vacı́o, pero no coincide con el del usuario que logra ingresar al sistema. • monto ∈ Z2 , donde 0 representa que la cuenta no tiene suficientes fondos para realizar la operación y 1 representa lo contrario. ctasUsr: Se tienen dos cuentas por usuario. |ctasUsr| = 2 movsCta ∈ Z2 , donde 0 representa que no hay movimientos en la cuenta para el periodo seleccionado y 1 lo contrario. verMtvts ∈ Z4 , donde 0 representa que el Flag está vacı́o, 1 representa que el Flag está en todas las operaciones, 2 en débitos y 3 en créditos. orden ∈ Z5 , donde 0 representa que el Flag está vacı́o, 1 representa que el Flag está en fecha creciente, 2 en fecha decreciente, 3 en cantidad y 4 en descripción. oF ch ∈ Z3 , donde 0 representa que el menú de selección está en vacı́o, 1 que está en rango y 2 representa que está en fecha inicial. f chD ∈ Z3 , donde 0 representa que la fecha está vacı́a, 1 representa que la fecha no es vacı́a y es menor que la final y 2 representa que la fecha no es vacı́a, pero es mayor o igual que la final. f chH ∈ Z3 , donde 0 representa que la fecha está vacı́a, 1 representa que la fecha no es vacı́a y es mayor que inicial y 2 representa que la fecha no es vacı́a, pero es menor o igual que la final. ctaO ∈ Z3 , donde 0 representa que la cuenta está vacı́a, 1 representa la cuenta 1 y 2 representa la cuenta 2. ctaD ∈ Z3 , donde 0 representa que la cuenta está vacia, 1 representa la cuenta 1 y 2 representa la cuenta 2. mntT r ∈ Z3 , donde 0 representa que el monto de la transferencia es menor o igual a 0 y 1 lo contrario. tpoOp ∈ Z3 , donde 0 representa que no se hizo ninguna escogencia, 1 que la escogencia fue retiro y 2 que fue consignación. 32.

(39) mntOp ∈ Z2 , donde 0 representa que el monto es menor o igual a 0 y 1 lo contrario. accion ∈ Z12 Esta variable no estaba originalmente en la lista y representa la acción hecha por el usuario. 0 representa que no se ha escogido ninguna acción, de lo contrario representa la acción escogida.. 5.4.2.. Tamaño teórico del Modelo. Una vez que se tienen todas las variables con rangos finitos, se puede proceder a hacer un cálculo teórico del tamaño del modelo a verificar; se muestra en la siguiente sección que en el peor de los casos, no es necesario tener en cuenta todas las variables al mismo tiempo para hacer la verificación. La formula para el tamaño del modelo se da teniendo en cuenta lo siguiente: B es el número de variables binarias. En el modelo se tiene que B = 3. T es el número de variables ternarias. En el modelo se tiene que T = 13. C es el número de variables de rango cuatro. En el modelo se tiene que C = 1. Ci es el número de variables de rango cinco. En el modelo se tiene que Ci = 1. A es el número de acciones en el modelo. En el modelo se tiene que A = 12. N es el máximo número de cuentas de un usuario que logra ingreso al sistema. En el modelo se tiene que N = 2. Tamaño teórico del modelo ≈ 2B × 3T × 4C × 5Ci × A × 6N estados. 5.4.3.. Modelo en Promela. En la sección 5.4.1 se ve que ninguna variable toma más de 6 valores, luego una variable de tipo byte será suficiente para representar cada variable del modelo. En el caso de las estructuras como usr y cuenta, se usan las estructuras de Promela y las variables de las estructuras también son de tipo byte.. 5.5. 5.5.1.. Verificación Modelo de Usuario. El modelo de usuario consiste en que en un página (nodo) especı́fica, el usuario puede llenar o no cada uno de los campos disponibles en esa página con cada uno de los valores posibles dados en la sección 5.4.1. Después ejecuta alguna de las acciones disponibles en ese nodo.. 33.

(40) 5.5.2.. Proceso de Verificación. El proceso de verificación se divide en N subprocesos, donde N es el número de nodos. En cada subproceso se verifica que para el nodo i y para cada acción para la cual (i, j) ∈ a se cumple lo siguiente: (is → Qa ) ((Ra ∧ is ) → j e ) Es decir que en todos los estados de la pagina (nodo) que se esta verificando se cumple (respectivamente) que: Las condiciones de salida del nodo, implican que la acción es ejectuable La postcondición de la acción y las condiciones de salida del nodo implican que se puede llegar (correctamente) al nodo de llegada. Para hacer este proceso de verificación es necesario expresar is , Qa , Ra y j e como fórmulas LTL. Pero con lo hecho en la sección 5.4.1, hacer la traducción de las fórmulas de primer orden de la sección 5.3 a fórmulas en LTL es un proceso directo.. 5.5.3.. Completitud de la Especificación. Es posible que una aplicación web cumpla con la verificación y aun ası́ no sea completamente del agrado del usuario final. Esto se debe a qué existen factores no considerados en el formalismo usado como: Qué tan amigable es la aplicación con el usuario. Velocidad de respuesta del servidor web. Existencia de algún nodo en el cual no existe alguna acción ejecutable. Esto implicarı́a que lo único que puede realizar el usuario es cerrar el navegador. Esto aunque no contemplado en el formalismo, si se puede verificar usando comprobación de modelos.. 34.

(41) Capı́tulo 6 Conclusiones 6.1.. Conclusiones Ascensor. En este trabajo se ha explorado el uso de comprobación de modelos (ing. Model Checking) en un ejemplo particular de un sistema de ascensores con un número finito de pisos y un número finito de usuarios. A juicio del autor, el uso de esta herramienta está limitada por tres factores: Falta de expresividad del lenguaje: PROMELA es muy limitado en cuanto a tipos básicos y a estructuras creadas a partir de éstos. Sin embargo, el mayor problema es la falta de subrutinas a las que un proceso pueda llamar o a las que se puedan llamar durante la verificación de un programa. Aunque PROMELA permite macros estos no son sencillos de usar y, en general, tienen muchas limitaciones de uso. Falta de cuantificadores lógicos finitos en LTL. Esto conlleva a que el trabajo de especificación y verificación sea engorroso ya que si se quisiera expresar una fórmula que vale para cada piso en un modelo de N pisos habrı́a que crear N fórmulas y N letras atómicas y hacer una verificación, o crear una fórmula y cambiarla para cada verificación y hacer N verificaciones. Aunque existe una herramienta basada en el trabajo [Ete99], llamada Temporal Message Parlor , la cual permite resolver este problema. El inconveniente de esta radica en que su uso es engorroso y requiere un conocimiento amplio de autómatas y de lógica temporal. Problema de un usuario finito: Para hacer las verificaciones fue necesario incluir la restricción que se hicieran como máximo un número finito de llamadas al ascensor. Esto se debe a que si se permite hacer potencialmente “infinitas” llamadas al ascensor, el número de transiciones aumenta de tal manera que la cantidad de memoria requerida para almacenar cada estado supera los limites fı́sicos de las máquinas en las que se hizo la comprobación. 35.

(42) Número Máximo de Llamadas Tiempo (seg) 3 2, 31 6 97, 4 9 118 12 124 15 130. Número de Estados 5, 31 ∗ 105 2, 06 ∗ 107 2, 57 ∗ 107 2, 78 ∗ 107 2, 80 ∗ 107. Cuadro 6.1: Número Maximo de Llamadas vs Número de Usuarios en la comprobación de los cuatro primeros requerimientos de seguridad, para un ascensor de cinco pisos Número Maximo de Llamadas Tiempo (seg) 3 3, 31 6 112 9 121 12 127 15 129. Número de Estados 7, 70 ∗ 105 2, 35 ∗ 107 2, 77 ∗ 107 2, 81 ∗ 107 2, 89 ∗ 107. Cuadro 6.2: Número Maximo de Llamadas vs Número de Usuarios en la comprobación del segundo requerimiento de vivacidad Luego un número infinito de llamadas aunque era posible en teorı́a, en la práctica no lo es por restricciones de memoria fı́sica. Pese a que esto parece una restricción fuerte, en realidad no lo es porque obviando las cuestiones de peso máximo que puede levantar un ascensor, para un ascensor de N pisos se necesita verificar como máximo con 3N llamadas simultáneas, pues en el peor de los casos, cada usuario oprime un botón diferente y como máximo hay 3N botones. Respecto a las conclusiones “positivas” se rescatan tres factores: Creación de un modelo incremental: El uso de esta técnica permitió que durante la construcción se encontraran los errores de manera rápida pues se partı́a de un modelo que cumplı́a todos los requerimientos anteriores y se le agregaba un requerimiento adicional cada vez. De esta manera, el modelo tenı́a que cumplir más restricciones, luego para SPIN era más fácil encontrar un contraejemplo (sucesión de estados) en el que no valiera la fórmula expresada como el “y” lógico de los requerimientos. Verificación incremental: Esto está relacionado con el punto anterior ya que se encontró que el tiempo de verificación de todos los requerimientos (expresados como una sola fórmula) en un modelo requiere mucho menos tiempo que hacer la verificación de cada requerimiento por separado; esto se ve reflejado en el siguiente cuadro. En el cuadro se evidencia que la suma de los tiempos de verificación independiente de los requerimientos en promedio triplica el tiempo de verificación de todos los requerimientos (como una sola fórmula). 36.

(43) Número de Pisos 1 2 3 4 5. Tiempo 9, 7 20, 4 33 47 51, 9. Tiempo Verificación Independiente 24, 96 49, 7 82, 1 116, 4 151, 2. Cuadro 6.3: Comparacion de tiempos en la verificacion de los cuatro primeros requerimientos Tiempo de Verificación de Varias Fórmulas: Si se tiene un conjunto finito de requerimientos expresados en formulas LTL como (a) y (b) esto es equivalente a verificar (a ∧ b) y el tiempo de verificar lo anterior implica pasar por todos los estados. Luego el tiempo de verificar (a ∧ b) es similar al tiempo de verificación de (a). Este hecho teórico se evidencia en el siguiente cuadro de resultados prácticos: Número de Pisos 1 2 3 4 5. Tiempo 9, 7 20, 4 33 47 51, 9. Tiempo Verificación Req 2 9, 43 19, 6 32, 5 43, 6 54, 2. Cuadro 6.4: Comparacion de tiempos en la verificacion de los cuatro primeros requerimientos y el segundo requerimiento de seguridad. 6.2.. Conclusiones Trabajo Web. Las conclusiones acerca del uso de comprobación de modelos para la verificación de la capa web de la aplicación Duke’s Bank y en general para la verificación de cualquier especificación usando el formalismo de [CC06] son las siguientes: El uso de comprobación de modelos se ve limitado debido a que la especificación está originalmente dada en fórmulas de lógica de primer orden y la forma de especificar para hacer comprobación de modelos es LTL. Aunque en el caso especı́fico de Duke’s Bank se pudo superar este inconveniente poniendo un lı́mite al número de cuentas por usuario, esto no necesariamente se podrá hacer en todos los casos. El problema de verificación de una aplicación se puede dividir en problemas más pequeños (verificar cada página por separado). Esto permite que esta aproximación sea altamente escalable, ya que si se agrega otra pagina a la aplicación original solo es necesario verificar esta por separado. 37.