UNIDAD IZTAPALAPA

CIENCIAS BÁSICAS E INGENIERÍA

Verificación formal de Sistemas

T E S I S

Que para obtener el grado de Licenciado

en Computación presentan:

Bravo Hernández Adolfo

Parra Ascención Jaime

Asesor: Dr. Manuel Aguilar Cornejo

México D.F. 2006

A mis padres

Luz María Hernández Pliego

Ezequiel Bravo Sánchez

Que siempre caminan a mi lado. Adolfo.

I

1

Agradecimientos

A mi asesor Dr. Manuel Aguilar Cornejo, por su apoyo.

A Laura por su amor.

A mis amigos y en especial a Gabriela, Gustavo y Jaime por su afecto.

Adolfo.

II II

2

A mis Padres:

Benita Ascención Hernández Erasto Parra Ramírez

Que con todo el apoyo que me brindaron para concluir mis estudios, con su amor y sacrificio supieron impulsarme siempre adelante, caminaron junto a mi en las buenas y en las malas y supieron aconsejarme en los momentos más difíciles, por todo esto brindo éste reconocimiento a ellos.

Jaime

III

3

Agradecimientos Con todo respeto a mi asesor Dr. Manuel Aguilar Cornejo que con sus enseñanzas y constante apoyo fue posible la realización de este trabajo. A mis hermanos Angel, Erika y Ana Karen por quienes siento un gran cariño y supieron apoyarme en todo momento. A mis abuelos, tíos y primos que con su compañía, amor y comprensión supieron estar conmigo en todos los momentos importantes de mi vida. A mis amigos en especial a Ana Bertha, Miguel Angel y Adolfo con los he compartido los momentos mas importantes de mi vida dentro de esta institución

Jaime

IV

ÍNDICE

CAPÍTULO 1. Introducción a los métodos formales 1 1.1 Resumen de los conceptos de verificación formal 2

1.2 Objetivo del proyecto de investigación 4 1.3 Estructura del documento 4 CAPÍTULO 2. Verificación de modelos 6 2.1 Fundamentos de la verificación de modelos 6 2.2 Aspectos semánticos de las transiciones de un autómata 9 2.3 Ejemplo de verificación de modelos con IFx 10 CAPÍTULO 3. IFx – Un verificador de modelos 14

3.1 Decisiones de diseño de la herramienta IFx 14 3.2 Utilerías de IFx 16 3.3 Sintaxis de IFx 17

3.3.1 Estructura de un programa en IFx 18 3.3.2 Comportamiento 20 3.3.3 Tipos de datos en IFx 21 3.3.4 Inserción de código externo 23

CAPÍTULO 4. Sistema de telefonía móvil (caso de estudio) 24 4.1 Usuario 26 4.2 Equipo terminal 27 4.3 Sistema de red 27 4.4 Sistema de atención al cliente 29 4.5 Sistema de facturación 29 CAPÍTULO 5. Desarrollo y verificación 30 5.1 Modelo del sistema de telefonía móvil 30 5.2 Proceso usuario 31 5.3 Proceso equipo terminal 33 5.4 Proceso sistema de red 34 5.5 Proceso sistema de atención al cliente 36 5.6 Proceso sistema de facturación 38 5.7 Observador del sistema 40 5.8 Resultados 41 CAPÍTULO 6. Conclusiones 44 APÉNDICE A Instalación IF en Fedora core 3 46 APÉNDICE B Instalación IFx en Fedora core 3 47 APÉNDICE C Glosario de Términos 49 APÉNDICE D Código fuente del Sistema de Telefonía Móvil 50 APÉNDICE E Código fuente de los Filósofos Comensales 59 BIBLIOGRAFÍA 65

V

1

CAPÍTULO 1.

INTRODUCCIÓN A LOS MÉTODOS FORMALES

n las diversas actividades humanas se han desarrollado disciplinas que utilizan herramientas

específicas para poder crear, desarrollar y manipular los satisfactores que cubran las necesidades

que tiene el hombre. Por ejemplo, la Ingeniería Mecánica desarrolla todos aquellos elementos

relacionados con las piezas de máquinas que tienen movimientos combinados y realizan cualquier tipo

de función; la Ingeniería Civil crea y desarrolla construcciones para la vivienda, la industria y obras

públicas. Estas dos disciplinas tienen siglos de evolución y experiencia. A diferencia de otras, como la

computación —que es el caso que hoy nos ocupa—, que han tenido un despunte sólo a partir de

mediados del siglo pasado. Aún somos inmaduros en el desarrollo de programas que utilicen la

computadora como herramienta fundamental dentro de su actividad. Estas carencias han generado

aplicaciones con anomalías y errores, por lo cual se ha buscado la forma de eliminarlas o, por lo menos,

atenuarlas, ello ha propiciado la creación de una nueva disciplina: la Ingeniería de Software. Algunos

programas de computadora que se ocupan en la vida cotidiana no admiten margen de error, como por

ejemplo el software que rige las transacciones crediticias de un sistema bancario o el sistema que

gobierna el tráfico aéreo; por lo cual, es fundamental modelar y capturar en la computadora toda la

información vital y posible de los problemas reales y su solución. En los últimos años la formalización

matemática del software cobró fuerza con el fin de mejorar la calidad de estos programas a través de la

definición y empleo de métodos formales, que si bien los orígenes de estas técnicas remontan a los años

setentas es en la última década en dónde ha tenido gran auge.

Los métodos formales emplean las matemáticas, fundamentalmente la teoría de conjuntos, el

álgebra y la lógica. El objetivo es permitir la verificación y prueba del sistema a lo largo de todo su

ciclo de vida. Al decir de Alberto Gil Solla [Gil99], “la fuerte base matemática de la mayoría de los

métodos formales da desde el primer momento la posibilidad de razonar sobre el sistema, sin tener que

esperar a la fase de codificación.” Por desgracia, los mecanismos que pretenden crear programas con

un “mínimo” de errores son muy engorrosos, el producir programas libres de errores es un problema

que se demostró no tener solución, además requieren que el equipo de desarrollo tenga una formación

profunda en matemática, lo cual no siempre sucede. Los sistemas tecnológicos modernos a menudo

E

2

alcanzan una gran complejidad, por lo que requieren utilizar técnicas y herramientas de asistencia

durante las distintas etapas de su vida útil (desarrollo, explotación y mantenimiento). Un ejemplo de

ésta es la verificación formal de sistemas.

La verificación formal de un sistema es una de las mayores ventajas que proporciona el

desarrollo con métodos formales. A través de la verificación podemos demostrar matemáticamente que

un sistema cumple las propiedades deseadas.

El proceso de verificación implica la comparación de objetos formales en pares: dos

especificaciones del sistema, una especificación y una implementación, una especificación y una

propiedad, etc. Son esos modelos, y no el sistema real, los que van a ser objeto del proceso de

verificación.

En la actualidad, son dos los mecanismos más difundidos para la verificación formal de

sistemas. El primer mecanismo es el demostrador de teoremas y el segundo es la verificación de

modelos (model checking). En el trabajo que ahora presentamos utilizaremos la verificación de

modelos, que es un procedimiento basado en la construcción de un modelo finito del sistema y en la

comprobación de que una o más propiedades dadas se satisfacen en dicho modelo.

Básicamente, la demostración se ejecuta mediante una búsqueda exhaustiva en el espacio de

estados del modelo del sistema. Los trabajos de investigación en la verificación de modelos se dirigen a

la búsqueda de algoritmos y estructuras de datos más eficientes que permitan el manejo de espacios de

estados muy grandes, propios de los sistemas reales.

1.1 RESUMEN DE LOS CONCEPTOS DE VERIFICACIÓN

FORMAL

A través de la verificación del sistema podemos demostrar matemáticamente que este cumple las

propiedades deseadas. Los beneficios potenciales que supone el poder razonar el sistema de forma

temprana y constante son:

• Una mejor comprensión del sistema. • Una mejor comunicación con el cliente al disponer de una descripción no ambigua de los

requisitos del usuario.

3

• Una descripción más precisa del sistema. • Una seguridad de carácter matemático de que el sistema implementado es correcto con respecto

a su especificación.

• Una mayor calidad del software. • Mayor productividad.

Una técnica de especificación formal (constituido de un lenguaje de especificación formal más un

método para verificar que ciertas propiedades se cumplen en el sistema) es especialmente adecuada

para describir el sistema. Dos propiedades fundamentales de un lenguaje de especificación formal son:

Expresividad: Debe ser lo suficientemente expresivo para poder modelar las características del sistema.

Abstracción: Debe poder describir qué hace un sistema sin poner restricciones a cómo lo hace (esto no siempre es posible).

Estas características del lenguaje nos permiten modelar de manera independiente la especificación

de un sistema de su posterior implementación, por ejemplo, se pueden aplicar características

específicas a las siguientes fases de desarrollo:

• En la fase de captura de requisitos se logra una especificación flexible de un sistema en función de sus propiedades importantes.

• En la fase de diseño de la arquitectura se logra describir los componentes del sistema, su

interfaz y cómo interactúan.

• En la fase de implementación se logra describir el comportamiento del sistema, de modo que pueda ser ejecutado por máquinas.

Si bien el uso de los métodos formales proporciona enormes beneficios, algunas de las posibles razones

(o pretextos) por las que no se suelen utilizar son porque:

• Es difícil demostrar a priori la rentabilidad del esfuerzo inicial • Falta formación matemática adecuada del personal de las empresas.

• Hay un desconocimiento general de este tipo de técnicas por parte de los clientes.

4

1.2 OBJETIVO

Los objetivos de esta tesis son los siguientes:

1. Aprender las técnicas de Verificación Formal de Sistemas (VFS). 2. Aprender la instalación y el uso del software apropiado para poder aplicar la VFS.

3. Estudiar y comprender los casos de estudios incluidos en el software instalado.

4. Proponer y desarrollar un caso de estudio del desarrollo de software usando la VFS.

Estos objetivos se lograron de la siguiente manera: el primer objetivo se cumplió haciendo una

incursión en los temas de Verificación Formal de Sistemas (VFS) a través de algunos artículos

referentes al tema [Gar00, Gil99], el segundo objetivo se cumplió a partir de una serie de pruebas

hechas de manera metódica y progresivas de la instalación de la herramienta IF y de la herramienta

IFx1, el tercer objetivo se cumplió analizando y estudiando algunos de los ejemplos incluidos en el

software y posteriormente construyendo un pequeño programa (el problema de los filósofos

comensales) para reafirmar el uso de la herramienta, el cuarto objetivo se cumplió realizando el

análisis, diseño y desarrollo del caso de estudio abordado en esta Tesis (Sistema de Telefonía Móvil)

1.3 ESTRUCTURA DEL DOCUMENTO

En este capítulo se introducen los conceptos básicos de la VFP y se plantean los objetivos de esta tesis.

En el capítulo dos se profundiza en el tema de la verificación de modelos, planteamos algunos de sus

fundamentos así como los aspectos básicos de los autómatas que usa la Verificación de Modelos,

concluyendo con un pequeño ejemplo donde se aplica esta técnica de verificación formal. En el

capítulo tres se introduce en el estudio del verificador de modelos IFx iniciando con las decisiones de

diseño de esta herramienta, continuando con la descripción de sus utilerías y finalizando con la

descripción de su sintaxis. En el capítulo cuatro se analiza un algoritmo de telefonía móvil,

describiendo primero en forma sintética este algoritmo, después se analiza cada uno de los procesos

que componen al sistema de telefonía móvil (que son: usuario, equipo terminal, sistema de red, sistema

1 (2005, noviembre, 03), [En Línea].Disponible: http://www-verimag.imag.fr/~async/IF/

5

de atención al cliente y sistema de facturación). En el capítulo cinco se modela nuestro caso de estudio

que es un Sistema de Telefonía Móvil en el verificador de modelos IFx y se verifican algunas

propiedades del sistema, como son: La consistencia del tipo de llamada que asigna el sistema con el

tipo de llamada que obtenga el usuario. Además se presentan los resultados obtenidos en el proceso de

desarrollo del caso de estudio. Finalmente en el capítulo seis se enlistan las conclusiones obtenidas a lo

largo del proceso.

6

CAPÍTULO 2.

VERIFICACIÓN DE MODELOS

nicialmente la verificación formal de sistemas únicamente empleaba el razonamiento deductivo con

ayuda de axiomas. Se empleaban demostradores de teoremas, que se basan en expresar tanto el

sistema, como sus propiedades de forma matemática. Una propiedad se define como un teorema, cuya

veracidad es el objetivo a demostrar. Sin embargo existe una alternativa para la Verificación Formal de

un Sistema, que es la Verificación de Modelos (Model –Checking), el cual ha tenido un gran auge

debido a:

• La posibilidad de automatizar totalmente las demostraciones del cumplimiento de las propiedades.

• La capacidad para trabajar con especificaciones parciales y proporcionar información útil del

sistema.

• La posibilidad de producir contraejemplos, que ayudan a localizar los errores.

2.1 FUNDAMENTOS DE LA VERIFICACIÓN DE MODELOS

La Verificación de Modelos es una técnica desarrollada en la década de los ochenta de forma

independiente por Clarke y Emerson y por Queille y Sifakis. Cuando surgió la Verificación de

Modelos se usó en la verificación de sistemas hardware y de protocolos de comunicación. Actualmente,

se aplica al análisis y verificación de sistemas en general (software y hardware).

Se le llama Verificación de modelos a un método automático de verificación de programas. Esto es

el programa es descrito mediante un lenguaje de especificación formal (libre de ambigüedades).

Posteriormente se traduce a un modelo matemático sobre el cual verificamos las propiedades del

sistema (a menudo escrita en lógica temporal2).

2 [2] (2006, marzo, 09), [En Línea]. Disponible: http://es.wikipedia.org/wiki/Model_checking

I

7

El modelo matemático del sistema suele estar expresado como un sistema de transición, es decir,

un grafo dirigido G (también llamado dígrafo) que es un par ordenado G = (V, E), en donde:

• V es un conjunto de vértices o nodos

• E es el conjunto de arcos formado por pares de vértices.

Un conjunto de proposiciones atómicas se asocia a cada nodo. Así pues, los nodos representan los

estados posibles de un sistema. Los arcos representan transiciones del mismo, mientras que las

propiedades a verificar deben de satisfacerse en cada estado de la ejecución.

Formalmente, el problema se representa de la siguiente manera: Dada una propiedad deseada,

expresada como una fórmula en lógica temporal n, y un modelo M con un estado inicial idle; decidir si:

M, idle ╞ n

Implica verificar que la propiedad n se satisface en el sistema M cuyo estado inicial es idle.

Para realizar la verificación de modelos se usan herramientas automáticas. Inicialmente el

programa P, el cual debe ser escrito en algún lenguaje formal es traducido a través de un Verificador de

Modelos en su modelo M (expresado en términos de un STE). La generación de dicho modelo nos

puede conducir al problema de explosión de estados. Esto es el proceso de traducción puede generar un

número infinito de estados o bien un número demasiado grande para ser almacenado en memoria

(física y secundaria) y por lo que es imposible el proceso de generación del modelo M. Para evitar el

problema de la explosión de estados se han desarrollado técnicas basadas en algoritmos simbólicos,

abstracción, reducción de orden parcial y model checking al vuelo, etc., las cuales son utilizadas en los

verificadores de modelos. Una vez obtenido el modelo M (Sistema de Transición Etiquetado) se revisa

que las propiedades se satisfagan en el modelo, en caso contrario se generará un contra ejemplo en

donde se nos indica la secuencia de instrucciones que nos llevan al error, todo esto puede ser observado

en la figura 1.

Inicialmente, las herramientas se diseñaron para trabajar con sistemas discretos, pero han sido

extendidas a sistemas de tiempo real, o sistemas híbridos. En el caso de IF, herramienta usada en esta

tesis, cuenta con opciones para sistemas de estos tres tipos.

8

Figura l: Diagrama de comportamiento del Verificador de Modelos

Un Sistema de Transiciones Etiquetadas (STE) se define como una cuádrupla

(S, s0, L, T) con el siguiente significado:

• S es el conjunto de estados en los que puede encontrarse el sistema.

• s0 es el estado inicial del sistema. Por tanto, s0 ∈ S.

• L=(a, b, c,...) es el conjunto de eventos que pueden provocar que el sistema cambie de estado (instrucciones del programa). Pueden ser eventos producidos por el propio sistema, eventos generados por el entorno, el simple paso del tiempo, etc.

• T es el conjunto de transiciones del sistema. Cada transición estará compuesta por el estado

origen, el estado destino y el evento que etiqueta o provoca esa transición. Gráficamente, suele representarse por

Un Sistema de Transiciones Etiquetadas (STE), nos permite representar de forma compacta la

evolución de un sistema a lo largo del tiempo.

Un STE es la forma clásica de expresar la semántica temporal de los lenguajes de procesos y

una representación del sistema muy apropiada para proceder al estudio de equivalencias entre sistemas

y la verificación de propiedades mediante verificación de modelos.

Diseño de un Programa P

Programa P

Escrito en algún lenguaje formal

Propiedades a Verificar (Escritas en Lógica Temporal o

en algún Lenguaje Formal)

Verificador de Modelos

Propiedades

Cumplidas

Modelo

Matemático de P (STE)

Propiedad(es) No Cumplida(s) y Contraejemplo

9

2.2 ASPECTOS SEMÁNTICOS DE LAS TRANSICIONES DE UN

AUTÓMATA

Un modelo de un sistema está constituido, como ya lo mencionamos, por un conjunto de estados, el

estado inicial, un conjunto de eventos y un conjunto de transiciones. En términos generales un modelo

puede ser visto como un Autómata en donde los nodos del autómata son estados del sistema y las

aristas representan transiciones entre estados. Las aristas de un autómata pueden tener, opcionalmente,

tres tipos de elementos, los cuales son:

• Un guardián. Condición de activación de la transición, que expresa una condición sobre los

relojes y variables enteras, que debe ser satisfecha para que dicha arista pueda ser tomada.

Formalmente los guardianes son conjunciones de condiciones sobre relojes y variables. Una

condición sobre los relojes debe ser expresado entre corchetes y puede utilizar los operadores

lógicos {<, ≤, =, >, ≥} para describir la condición deseada, por ejemplo si en una transición entre

un estado A y un estado B se encuentra [t>1], significa que el autómata cambiará del estado A al B

cuando el reloj sea mayor a uno.

• Una acción de sincronización, la cual permite que dos autómatas se sincronicen sobre un

evento, de tal modo que uno de ellos da la orden y el otro la espera.

La sincronización se implementa mediante canales de comunicación. Si por ejemplo se

declara un canal m, el autómata que va a generar el evento de sincronización deberá decir en la

arista correspondiente !m, mientras que el autómata que espera el evento deberá decir ?m en la

arista correspondiente.

• También es posible declarar a un canal como urgente (urgent), en este caso las aristas

correspondientes no podrán tener guardianes basados en relojes, debido a que un canal urgente

ejecuta la transición sin demora, en cuanto está habilitada.

Opcionalmente, un estado puede ser calificado como start (estado inicial) que representa el

estado donde se inicia la ejecución del autómata (en el estado inicial todos los relojes y variables

10

ARROZ

están en cero).

2.3 EJEMPLO DE VERIFICACIÓN DE MODELOS CON IFx

Para comprender mejor la Verificación de Modelos en la herramienta IFx fue necesaria la realización

de un ejemplo, que es plantear la solución al problema de los filósofos comensales que se plantea a

continuación:

Considere a cinco filósofos que pasan sus vidas pensado y comiendo. Los filósofos comparten

una mesa redonda común con cinco sillas, una para cada filósofo. En el centro de la mesa hay un tazón

de arroz, y la mesa esta dispuesta con cinco palillos chinos únicos para comer (figura 2). Cuando un

filósofo piensa, no interactúa con sus colegas. De vez en cuando, a un filósofo le da hambre y trata de

tomar los dos palillos más cercanos a él (los palillos que se encuentran entre él y sus vecinos de la

izquierda y a la derecha). Un filósofo sólo puede tomar un palillo a la vez. Obviamente, no puede tomar

un palillo que ya se encuentra en la mano de un vecino. Cuando un filósofo con hambre tiene los dos

palillos al mismo tiempo, come sin soltar los palillos. Cuando ha terminado de comer, deja los dos

palillos y comienza a pensar nuevamente.

El problema de los filósofos comensales es considerado un problema clásico de sincronización,

no por su importancia práctica, ni porque a los científicos de la computación les agraden los filósofos,

sino más bien porque es un ejemplo de una gran clase de problemas de control de concurrencia. Es una

representación sencilla de la necesidad de asignar varios recursos entre varios procesos que se

encuentran en un estado de bloque mutuo y en una forma donde no haya inanición [SGG04].

Figura 2: La situación de los filósofos comensales

A partir del algoritmo descrito se creó el modelo y la propiedad a verificar es que no exista un

11

abrazo mortal en el sistema. Iniciamos con la suposición de que cada uno de los filósofos tomará

primero el palillo izquierdo y después el palillo derecho, a continuación se realizó la verificación

formal usando la herramienta IFx de la cual se hablará más tarde en este documento, obteniendo los

siguientes resultados:

1.- Se verificó el abrazo mortal existente en el sistema, que ocurre cuando todos los filósofos piden el

palillo derecho, en la herramienta gráfica de IFx (if2gui) la cual se muestra en la figura 3 se observan

dos recuadros importantes, el izquierdo tiene las instancias de los procesos que en ese momento existen

y en el recuadro derecho se presentan las distintas transiciones que hay entre los estados de estos

procesos, en este caso la instancia del observador levantó la bandera de cut = true que indica que

alguna propiedad no se cumplió, y por tanto ya no realiza más transiciones entre los estados.

Figura 3: Abrazo Mortal en el Sistema

Además se puede observar en la Figura 3 que al hacer la prueba el observador del sistema arroja

un contraejemplo, se sabe que la propiedad no se cumplió (porque como se mencionó el estado cut es

verdadero) y en éste caso, es cuando el filosofo 0 (los filósofos se enumeraron del 0 al 4) pide su palillo

derecho con lo cual se generó un abrazo mortal, ya que todos tienen su palillo izquierdo y están

pidiendo el derecho como se observa en la Figura 4.

12

ARROZ

Figura 4: Abrazo Mortal al estar todos esperando el palillo derecho

Es importante mencionar que el probador gráfico que proporciona IFx sólo realiza simulaciones

de la ejecución del sistema. Para estar seguros que el abrazo mortal no se presenta nunca es necesario

hacer una búsqueda exhaustiva por todas las trazas posibles que genere el autómata, para esto IFx

proporciona mecanismos para generar y verificar el modelo del sistema.

2.- Se realizó una modificación al programa para quitar el abrazo mortal que consiste en que el filósofo

cero haga la petición primero del palillo derecho y después del izquierdo y los demás pidan primero el

izquierdo y después el derecho, en esta ocasión el probador no arrojo ningún contraejemplo por lo que

ahora se está en la posibilidad de realizar una búsqueda exhaustiva por todos los estados posibles que

genera el autómata. Como se muestra en el siguiente texto, el autómata tiene que pasar por 1, 636, 763

estados y 2, 906, 468 transiciones para recorrer todas las posibles trazas y verificar que no existe abrazo

mortal como se muestra en la figura 5.

$ ./filosmejorado.x -dfs -po -t filosmejorado.aut - q filosmejorado.states 00:06:04 1636763/s 2906468/t 12/d queue table : 65776 items 2099/entry 16/min 52/max 31.34/avg message table : 36 items 13/entry 4/min 4/max 2.77/avg instance table : 97422 items 4201/entry 8/min 72/max 23.19/avg config table : 3061578 items 134837/entry 8/min 48/max 22.71/avg chunk table : 1711454 items 67409/entry 8/min 48/max 25.39/avg label table : 4486467 items 269683/entry 4/min 40/max 16.64/avg event table : 65 items 13/entry 4/min 20/max 5.00/avg

13

Figura 5: No existencia del abrazo mortal en el sistema

Por lo que estamos en condición de afirmar que la propiedad deseada se cumple, ya que al

realizar una búsqueda exhaustiva en el archivo con extensión states con la frase “ABRAZO MORTAL”

se arroja el resultado enmarcado con rojo “No se encontró el patrón de búsqueda: ABRAZO

MORTAL”.

Para observar todo el código fuente de los Filósofos comensales con abrazo mortal y sin abrazo mortal

hacer referencia al Apéndice E.

14

CAPÍTULO 3.

IFx – UN VERIFICADOR DE MODELOS

Fx es una extensión de IF el cual nos ayuda a modelar de manera gráfica sistemas en tiempo real.

También nos auxilia para analizar sistemas que requieran de la creación y destrucción de procesos

durante su ejecución. Para usar esta herramienta fue necesario utilizar una de las distribuciones Linux

Fedora Core 3 o Red Hat 9.

3.1 PRINCIPALES DECISIONES DE DISEÑO DE LA

HERRAMIENTA IFx

Para poder construir un programa con ayuda de la herramienta IFx es necesario saber algunas de las

decisiones de diseño en las que se basaron sus creadores, entre las cuales destacan las siguientes:

• El programa está constituido por componentes, a los cuales se les llama procesos.

• Utiliza paso de mensajes punto a punto (point to point).

• El número de procesos puede variar en tiempo de ejecución.

• Cada proceso es un autómata extendido temporizado, con su propio pid (identificador de proceso) y le es asignada memoria local en la cual puede guardar el valor de variables, relojes, estado de control y una cola de mensajes pendientes.

• En un estado de control las transiciones son activadas mediante la presencia de algún mensaje

en la cola de entrada y/o alguna condición en las variables, posiblemente un temporizador.

• Puede pasar de un estado de control a otro a través de transiciones.

En resumen, los cuerpos de las transiciones son programas secuénciales que consisten de acciones

elementales como: asignación de variables, configuraciones del reloj, envío de mensajes, creación y

destrucción de procesos, etc.

I

15

Las características principales de IFx son:

• Los conceptos estructurados: Sistemas que consisten de procesos, ejecutándose en paralelo y comunicándose a través de paso de mensajes vía buffer de comunicación.

• Las primitivas de comunicación: Los procesos pueden comunicarse a través de intercambio de

señales (directamente o vía rutas de señales) o a través de variables compartidas.

• Las primitivas de tiempo-real: cada proceso puede usar varios relojes para medir el tiempo durante la ejecución y además las transiciones pueden ser guardadas con restricciones de tiempo (dependiendo de los relojes) y caracterizados con plazos explícitos como impaciente, lento y perezoso.

• Los sistemas abiertos: ofrece el concepto de canal de comunicación abierto, conectadas al

ambiente y transportando mensajes entre éste y el sistema.

• El no-determinismo: los procesos pueden ser no determinísticos es decir que más de una transición puede ser habilitada en algún estado de control y todas las situaciones tienen que ser consideradas en la ejecución.

• Los tipos de datos complejos: el lenguaje provee varios tipos de constructores tales como

enumeración, intervalo, arreglo, registro además de tipos básicos predefinidos para manipulación y descripción de datos complejos.

• La parametrización: es posible parametrizar tipos de datos usando constantes enteras (por

ejemplo el tamaño de un arreglo), configuraciones del sistema (por ejemplo número de instancias de un proceso), comportamiento de tiempo (por ejemplo restricciones de reloj).

• Las características dinámicas: El lenguaje incluye creación y destrucción de procesos e

instancias de rutas de señales (canales). Esto hace la configuración del sistema dinámica, es decir el número de componentes corriendo pueden cambiar durante la ejecución.

• El control estructurado: El lenguaje común integra estados jerárquicos para la estructura de

los autómatas.

• Las transiciones compuestas: Estados de control básicos como es if-then-else y while-do pueden ser usados para las transiciones de los autómatas estructurados.

• La integración de código externo: El lenguaje provee un camino para transformaciones

abstractas complejas de datos a través de la integración de código externo como los procedimientos. El código externo a ser dado depende de las herramientas usadas como es la implementación ejecutable para simulación y verificación del modelo, o definición de axiomas de primer orden para usar esto en un probador.

16

3.2 HERRAMIENTAS DE IFx

Se muestra a continuación un esquema de la arquitectura de IFx (Figura 6).

Figura 6: Arquitectura de IFx

Analizador Estático

IFx proporciona un analizador sintáctico de programas. Este analizador implementa técnicas clásicas de

análisis estático de programas tales como: análisis de variables activas, eliminación de código muerto y

eliminación de variable con respecto a criterios definidos por el usuario, para crear un programa

sintáctica y semánticamente equivalente a un programa dado por el usuario. El análisis de variables

activas sirve para eliminar todas aquellas variables que no se utilicen durante la ejecución del sistema.

La eliminación de código muerto se encarga de desechar todo aquel código que no se utilice también

durante la ejecución del sistema.

Especificaciones de IFx

Los programas escritos en IFx deben ser almacenados en archivos con extensión if u oif, donde el

archivo con extensión if contiene los procesos, los estados de cada proceso y las señales a través de las

cuales se comunica y el archivo con extensión oif es un observador, el cual es un autómata que se irá

generando a la par del modelo, verificando las propiedades que se especifican en éste.

Analizador Sintáctico de IF

Especificaciones de IF

Máquina de Exploración de IF

Construcción del modelo

Verificación del Modelo

AUT STATES

17

Máquina de exploración

Una de las más potentes herramientas con que cuenta IFx es la máquina de exploración que a su vez

está constituida por las siguientes herramientas:

• If2gen: Esta herramienta crea el generador del modelo (archivo con extensión .x), dicho en otras palabras genera el archivo ejecutable que es capaz de generar el modelo o bien puede seguir alguna de las trazas en forma aleatoria, todo lo anterior con ayuda de la siguiente línea de comando:

$if2gen -obs <nombre_archivo>.oif <nombre_archivo>.if

• If2gui: Esta herramienta puede crear una simulación guiada, o bien una verificación del modelo no exhaustiva llamada prueba dentro de un ambiente grafico amigable. Se ejecuta con la línea de comando ( este comando no tiene parámetros ):

$if2gui

Como se mencionó anteriormente el archivo con extensión ‘x’ creado por if2gen puede generar

el modelo del sistema con la línea de comando:

./<nombre_archivo>.x -bfs –po –t <nombre_archivo>.aut –q <nombre_archivo>.states

El modelo contiene todos los estados alcanzables usando las estrategias bfs (búsqueda primero

en amplitud) o dfs (búsqueda primero en profundidad). Durante la generación imprimirá el número de

estados alcanzados y las transiciones. En el modo dfs, la opción –po habilita la reducción en orden

parcial. Al generar el modelo (con extensión aut) también se genera un archivo con extensión states

que contiene la descripción de los estados del sistema.

3.3 SINTAXIS DE IFx

IFx trabaja con sistemas compuestos de objetos activos los cuales son ejecutados en paralelo y además

actúan asincrónicamente a través de envío y recepción de mensajes.

18

3.3.1 ESTRUCTURA DE UN PROGRAMA EN IFx

En general un sistema IF esta estructurado por procesos que se envían señales (en ocasiones usando

ruta de señales) para interactuar. A continuación se da una breve explicación de cada uno de estos

conceptos: sistema, procesos, ruta de señales, señal.

SISTEMA

Para realizar un programa con ayuda de la herramienta IFx se requiere modelar el sistema usando la

siguiente sintaxis:

system <nombre_del_sistema>; { componentes_del_sistema }* endsystem;

Los componentes_del_sistema pueden ser algunos de los siguientes:

procesos | ruta_de_señales | señales | procedi mientos | variables | tipos_definidos_por_el_usuario | constantes

A continuación se desarrolla cada uno de los componentes del sistema.

PROCESOS

Un proceso en IFx se debe declarar como sigue:

process < nombre_del_proceso > ( número_de_ins tancia ) ; [ fpar < parametros del proceso > ; ] { componentes_del_proceso }* endprocess;

Tanto en los procesos como en las rutas de señales el número_de_instancia es 1 si se desea que

una instancia del proceso sea creado desde el inicio de la ejecución y es 0 si no se requiere tal

instancia, siempre se pueden crear instancias del proceso usando la instrucción fork.

19

Los parámetros del proceso son variables que le son pasados por valor cuando se invoca dicho

proceso por alguna instancia existente.

Los componentes_del_proceso (los cuales serán descritos más adelante) pueden ser algunos de

los siguientes:

estados | procedimientos | variables | tipos_de finidos_por_el_usuario | constantes

RUTA DE SEÑALES

Las rutas de señales definen los caminos de comunicación entre procesos y su sintaxis es la siguiente:

signalroute < nombre_de_la_ruta_de_señales > ( número_de_instancia ) { opciones_de_la_ruta_de_señales } from { pid | env } to { pid | env } with < nombre_de_señales > ;

Las opciones_de_la_ruta_de_señales pueden ser alguna de las siguientes: #fifo | #multiset | #reliable | #lossy | #peer | #multiset | #unicast | #urgent | #delay[l, u] | #rate[l, u]

Estas opciones indican la política de poner en cola de espera (#fifo o #multiset), la fiabilidad (#reliable

o #lossy), política de entrega (#peer o #multiset o #unicast) y la política de retardo (#urgent o #delay[l,

u] o #rate[l, u]).

SEÑALES

Los procesos usan las señales para comunicarse entre ellos. Las especificaciones de una señal son las

siguientes:

signal < nombre_señal > ( parametros_de_la_seña l ) ;

Los parámetros de la señal son variables que le son pasados por valor cuando se usa dicha señal

por algún proceso existente.

20

3.3.2 COMPORTAMIENTO

Los procesos se describen como una serie de estados que realizan alguna tarea y que van de unos a

otros a través de transiciones. Enseguida se presenta su sintaxis.

ESTADOS

Los estados generan el comportamiento de los procesos. Su sintaxis se muestra a continuación:

state < nombre_del_estado > { opciones_del_est ado } ; { componentes_del_estado }* endstate ;

Los componentes del estado puede ser alguno de los siguientes: transición | estado

Las opciones del estado son para marcar un estado inicial (start) o su estabilidad (stable, unstable) y se

hace con alguna de las siguientes opciones:

#start | #stable | #unstable

TRANSICIÓN

La sintaxis de la transición es la siguiente:

[ deadline { eager | delayable | lazy } ; ] [ provided < condición >; ] [ when < condición_de_tiempo >; ] [ input < nombre_de_señal > ( [ expresión ] ) ; ] { < sentencia > } < terminador >

Las condiciones de tiempo se refieren a condiciones similares a lenguajes procedimentales

tradicionales pero la condición a verificar es sobre un criterio del reloj del proceso.

21

La sentencia nos ayuda a manejar condiciones o a realizar acciones, puede estar construida como sigue:

acción | if expresión then { sentencia }* [ e lse { sentencia }* ] ) endif | while expresión do { sentencia }* endwhile

El terminador puede ser alguno de los siguientes: nextstate < nombre_del_estado >; | stop;

Un ejemplo sencillo de descripción del comportamiento de una sección de un sistema es el

siguiente:

state saludo #start; when t<=2; informal “hola mundo”; nextstate saludo; when t>2 informal “adios”; nextstate saludo; endstate

El ejemplo anterior lo que realiza es verificar la variable t, cuando sea menor o igual a dos

enviará como salida “hola mundo” y realiza una transición a este mismo estado, por el contrario

enviará como salida “adios” cuando t sea mayor a dos y se realiza una transición a este mismo estado.

3.3.3 TIPOS DE DATOS EN IFx

Existen diferentes tipos de datos dentro de IFx, los más importantes se describen a continuación:

CONSTANTES

Las constantes son usadas para nombrar algún valor que no cambia durante la ejecución de los

procesos. Una constante particular es el self que denota el pid de la instancia y nil que denota el pid

nulo. Se declaran como se muestra a continuación:

const < nombre_de_constante > [ = valor ] ;

22

El valor puede ser alguno de los siguientes:

true | false | número_entero | número_decimal | self | nil | nombre_de_constante

TIPOS DE VARIABLES

Hay cinco tipos predefinidos que son: boolean, integer, float, pid y clock. Además el usuario puede

definir su propio tipo de variable. Esto se logra a través de la siguiente sintaxis:

type < nombre_del_tipo > = < tipo > ;

El tipo de variable puede ser alguno de los cinco tipos predefinidos o bien alguno de los siguientes:

enum < nombre_de_constante > { , nombre_de_const ante }* endenum | range número .. número | array [ número .. número ] of < nombre_del_tipo > | record { nombre_del_campo }* endrecord | string [número ] of < nombre_del_tipo > | abstract { nombre_de_función }* endabstract | type-id

La declaración del nombre_del_campo es como sigue:

field-id < nombre_del_tipo > ;

La declaración del nombre_de_función es como sigue:

< nombre_del_tipo > < nombre_de_función > ( [ < nombre_del_tipo > { , < nombre_del_tipo > }* ] ) ;

EXPRESIÓN

Las expresiones son construidas con base en constantes y variables usando un conjunto de

operaciones como se muestra a continuación:

23

expression ::== número | < nombre_de_variable > | < nombre_ de_parámetro > | expresión . < nombre_del_campo > | expresión [ expresión ] | < no mbre_de_función > ( [ expresión { , expresión }*] ) | un-op expresión | expresión b in-op expresión | cast-op expresión | expresión ? expresión : expresión | (e xpresión )

donde un-op es:

not | active | + | -

donde bin-op es:

or | and | = | <> | < | <= | >= | > | + | - | * | / | %

donde cast-op es:

{ < nombre_del_tipo > | < nombre_del_proceso > | < nombre_de_la_ruta_de_señales > }

3.3.4 INSERCIÓN DE CÓDIGO EXTERNO

Los procedimientos son una forma importante de utilizar código externo dentro de las especificaciones

IF. Son ejecutados sin interacción alguna con las instancias. Las especificaciones del procedimiento

incluyen su nombre, parámetros formales y valor de retorno. A continuación se describe la forma de

insertar un procedimiento escrito en lenguaje C:

procedure < nombre_del_procedimiento > ; [ fpar < declaración_de_parámetros > ;] [ returns < nombre_del_tipo > ; ] [ {# código en lenguaje C #} ] endprocedure ;

24

CAPÍTULO 4.

SISTEMA DE TELEFONÍA MÓVIL (CASO DE ESTUDIO)

grandes rasgos el algoritmo del Sistema de Telefonía Móvil cuenta con cinco procesos

importantes que tienen por propósito que los usuarios de este sistema puedan realizar llamadas a

otros usuarios tomando en cuenta el status de sus límites de crédito con la proveedora del servicio.

Los límites de crédito son aquellos máximos de consumo mensual que pueden solicitar los

clientes de un servicio de telefonía móvil. Así, cualquier cliente de uno de estos servicios puede

comunicar a su proveedor de telefonía que no desea rebasar una cantidad determinada en sus facturas.

Debido a la naturaleza de los límites de crédito, este proyecto se centra únicamente en los

servicios de telefonía móvil pospago. Al contrario de lo que sucede con los servicios de tipo prepago,

los servicios pospago no disponen de ningún sistema hecho a la medida de control de crédito. Es por

ello que suele ser necesario algún desarrollo a medida que proporcione este tipo de funcionalidad. Este

desarrollo suele implicar cambios en diferentes aplicaciones de la estructura software de la empresa

proveedora del servicio.

La funcionalidad de límites de crédito supone la actualización en el sistema de Atención al

Cliente, en el sistema de Facturación de Clientes y en el sistema de Red. La complejidad de éste

desarrollo justifica la realización de un modelo confiable, que represente de forma fehaciente todos los

aspectos a tener en cuenta.

Los límites de crédito también llamados thresholds (de aquí en adelante usaremos esta palabra

para referirnos a los límites de crédito), son una de las soluciones de control de gasto proporcionadas

por los proveedores de telefonía móvil. El principio de los límites de crédito es el permitir a los clientes

solicitar un importe monetario máximo que no desean superar.

La implementación de los límites de crédito es únicamente aplicable a los servicios de tipo

pospago, es decir, a aquellos servicios que se cargan a una cuenta facturable por ciclos mensuales. No

sería lógico aplicar este tipo de control a servicios de tipo prepago, al disponer de mecanismos de

control de consumo más sencillos ya que el servicio prepago no requiere la formalización de ningún

tipo de contrato.

De hecho la red desconoce todos los datos del abonado, excepto el identificador del teléfono y

A

25

la celda desde la que está llamando, es decir no se requiere hacer un cargo sobre una persona física o

moral que después salde la cuenta, lo cual requiere un control más riguroso.

En el caso de este sistema pospago cuando los clientes superan el importe máximo solicitado, se

redireccionan sus llamadas a un número automático también llamado hotline (de aquí en adelante

usaremos esta palabra para referirnos a este número automático), que les advierte que su límite de

crédito ha sido alcanzado. De igual manera, se permite a los clientes ponerse en contacto con el

personal de Atención al Cliente para solicitar una ampliación de límite de crédito llamado también

override (de aquí en adelante usaremos esta palabra para referirnos a esta situación).

Si el cliente solicita un override, debe permitírsele utilizar de nuevo el servicio con total

normalidad. El nuevo threshold establecido es la suma del threshold original y del importe solicitado

en el override. Si se alcanzara el nuevo límite, volvería a detenerse el servicio, repitiéndose de nuevo el

ciclo de funcionamiento mencionado.

Si el cliente no solicita un override, su servicio permanece desactivado hasta el final del ciclo de

facturación. Una vez que se factura el servicio, el cliente podrá realizar llamadas con normalidad. En el

nuevo ciclo de facturación, el cliente vuelve a disponer del límite original que había solicitado.

Paralelo a los beneficios que ésta funcionalidad aporta a los clientes del operador de telefonía,

están los beneficios que tienen para el propio proveedor del servicio.

La funcionalidad de thresholds puede utilizarse para implementar métodos de control de fraude

eficientes. Una vez que se ha detectado un posible fraude, es posible desactivar temporalmente el

servicio del cliente a través de la aplicación de límites de crédito. Esta aplicación permitiría detener un

servicio de forma temporal, obligando al cliente a ponerse en contacto con el personal de Atención al

Cliente, que inmediatamente pasaría la llamada al Departamento de Fraude.

En la implementación de cualquier sistema de thresholds deben considerarse los siguientes

elementos que pueden ser apreciados de una mejor manera en la figura 7 donde se ilustran cada uno de

los procesos y su función:

• El usuario que es el cliente final que interactúa con el proveedor a través de su equipo terminal.

• El equipo terminal o terminal de usuario que es el dispositivo empleado por los clientes

para acceder al servicio de telefonía.

• La red que es el conjunto de aplicaciones y dispositivos encargados de dar cobertura a los equipos terminales, y de garantizar la calidad de servicio y controlar de forma eficaz la utilización de los recursos disponibles.

26

• El sistema de facturación que es el sistema encargado de controlar el consumo realizado

por los clientes. De igual forma, también es el sistema que se encarga de generar las facturas correspondientes al final de cada ciclo de facturación.

• El sistema de atención al cliente que es el encargado de atender las demandas de los

usuarios del servicio de telefonía y de comunicar al resto de sistemas los cambios solicitados por los clientes.

• Inmerso en el sistema de atención al cliente está el sistema de control de fraude que se

encarga de detectar posibles estafas en el servicio y de aplicar las medidas apropiadas de contingencia.

Figura 7: Diagrama del Sistema de Telefonía Móvil.

4.1 EL USUARIO

El usuario es el cliente final que interactúa con el sistema a través de su equipo terminal. Así,

pueden destacarse dos eventos de especial interés: El inicio de una nueva llamada y el final de

una llamada existente.

Siempre que el usuario desee realizar una llamada, el sistema de límites de crédito deberá

comprobar si el límite solicitado por el usuario ha sido rebasado. En caso de que el usuario tenga un

Usuario

Equipo Terminal

Sistema de Red

Sistema de Atención al Cliente

Sistema de Facturación

27

hotline activado por superar algún límite de crédito, se le remitirá hacia un teléfono automático o IVR

que le informará de que su límite de crédito ha sido superado. Si el usuario tiene un hotline activado

por motivos de fraude, se le remitirá hacia otro IVR que le informará de que el servicio ha sido

desactivado temporalmente. En cualquier otro caso, se establecerá la llamada solicitada por el usuario.

Una vez realizada la llamada, el usuario procederá a colgar su equipo terminal debiendo

liberarse todos los recursos de red asignados.

4.2 EL EQUIPO TERMINAL

El equipo terminal debe comunicarse en todo momento con la red. De esta forma se

mantiene la cobertura del terminal con los controladores de las celdillas GSM (Global

SystemforMobile Communications es la norma de transmisiones móviles más extendida hoy en día).,

también conocidos como BTS (Base Transceiver Station, es un equipo que se encarga de garantizar la

cobertura radioeléctrica en una de las células de la red GSM).

Una vez que el usuario desea realizar una llamada, el BTS más cercano debe realizar las

comprobaciones pertinentes para posibilitar la ejecución del servicio. Para ello, el equipo terminal

deberá enviar una solicitud al BTS más cercano, que se comunicará con el resto de la red para decidir

qué tipo de conexión debe asignarse. Una vez realizada esta elección, se asignará un canal al equipo

terminal para que efectúe la llamada apropiada.

Cuando el usuario desee finalizar la llamada, el equipo terminal notificará a la red su intención

de abandonar la conexión y volverá a su estado inicial de inactividad.

4.3 EL SISTEMA DE RED

El sistema de red es el encargado de informar el tipo de conexión asignada al usuario a

partir de la respuesta obtenida del sistema de facturación. Una vez que el usuario desea

realizar una llamada, el BTS más cercano debe realizar las validaciones correspondientes

para decidir lo que debe hacer. Para ello, el BTS debe ponerse en contacto con el

subsistema de red o NSS (Base Transceiver Station, es un equipo que se encarga de garantizar la cobertura

radioeléctrica en una de las células de la red GSM) a través de su controlador de estación base o BSC (Base

28

Station Controller, es el equipo encargado de la gestión de un conjunto de BTS, cumpliendo funciones de

comunicación y explotación).

Una vez que el NSS recibe la petición, se comprueba la pertenencia del servicio a la red mediante su

número de abonado o SIM (Subscriber Identity Module es un dispositivo personal para cada abonado que

aloja el número que identifica a un usuario dentro de la red de telefonía móvil.). Para realizar esta

validación, se recurre al centro de autenticación o AUC (Authentication Center es el dispositivo que

controla los derechos de uso que cada abonado posee sobre los servicios de la red.). Validada la pertenencia

del servicio al proveedor, se recurre al registro de abonados locales o HLR (Home Location Register, es una

base de datos que contiene la información relativa a los abonados de la red.), que mantiene información

sobre el servicio de abonado.

Por otro lado, si la validación realizada por el AUC fuera infructuosa, se crearía una entrada nueva

en el registro de localización de visitantes o VLR (Visitor Location Register es la base de datos asociada al

MSC que almacena información dinámica relativa a los abonados de paso por la red.), haciendo las veces

de HLR para este servicio.

Son los HLR los encargados de mantener los datos sobre los servicios de los clientes. Para facilitar

un rápido acceso a los recursos de red, los BTS están en permanente contacto con el HLR transmitiéndole

toda la información de los servicios que hay bajo su cobertura. Esta comunicación entre los BTS y el HLRs

permite mantener la cobertura de los equipos terminales cuando éstos pasan de una celdilla a otra de la red

GSM.

De igual modo, el HLR registra los datos de las llamadas realizadas por los abonados. Para ello,

cada vez que un cliente utiliza un servicio, los BTS correspondientes transmiten al HLR los denominados

tickets de llamada. Así, cuando un equipo terminal se desplaza durante una llamada cambiando sucesivas

veces de celdilla, cada uno de los BTS afectados envía al HLR los tickets de llamada que corresponden al

tiempo en el que el equipo terminal estuvo bajo su cobertura.

La acción correspondiente a una activación de hotline para un servicio, bien sea por motivos de

fraude o por límites de crédito, consistiría en modificar un dato en el HLR que permitiese a la red decidir lo

que hacer con el servicio en cuestión. En caso de que el teléfono tenga un hotline activado por superar un

límite de crédito, el HLR más cercano le remitirá hacia un IVR (Interactive Voice Responder, se trata de un

equipo con la capacidad de interactuar con los usuarios a través de comandos de voz o del teclado del

terminal móvil) que le informará de que el límite de crédito ha sido superado.

De esta manera se establece una conexión hotline. Igualmente, si el teléfono tiene un hotline

activado por motivos de fraude, el HLR más cercano le remitirá hacia otro IVR que le informará de que el

servicio ha sido desactivado temporalmente. Se establece entonces una conexión fraude. En cualquier otro

29

caso, se establecerá la llamada solicitada por el cliente a través de una conexión llamada.

Una vez que el cliente se desconecta del servicio, la red libera la conexión asignada al equipo

terminal.

4.4 EL SISTEMA DE ATENCIÓN AL CLIENTE

El sistema de atención al cliente es la aplicación que sirve de front-end para el personal del

Call Center, permitiendo interactuar con el resto de aplicaciones corporativas.

El sistema de atención al cliente será el que da de alta los servicios de los nuevos

clientes, activa los descuentos oportunos, crea los servicios suplementarios apropiados, etc. En el caso de

los límites de crédito, será el sistema encargado de dar de alta los límites a medida que los clientes los van

solicitando, modificar las cantidades de los límites, eliminar los límites si los clientes lo desean, etc.

Igualmente, será el encargado de realizar las ampliaciones de límite de crédito a medida que los solicitan los

clientes.

El sistema de control de fraude está también integrado dentro del sistema de atención al cliente,

pudiendo realizar las desactivaciones temporales de los servicios sospechosos de fraude.

4.5 EL SISTEMA DE FACTURACIÓN

El sistema de facturación es el encargado de comprobar en todo momento el consumo de los

servicios pospago. A medida que la red va generando los tickets de llamada, un sistema de

tarificación se encarga de agrupar los datos referentes a cada una de las llamadas en unos

archivos llamados CDR (Customer Data Register es el archivo que contiene los detalles de

una llamada). En estos archivos se recogen las unidades totales consumidas por el cliente, el importe del servicio

antes de impuestos y datos relativos a la conexión, como los números de teléfono origen y destino, la fecha y

hora de la llamada, etc.

A medida que el sistema de tarificación va generando los CDR, los va enviando al sistema de

facturación para su procesamiento. El sistema de facturación recoge la información de los CDR y la procesa

realizando diversas operaciones con ella. Efectúa las validaciones de datos pertinentes, acumula los consumos en

los servicios correspondientes, genera las alarmas relativas a las llamadas inválidas, etc.

30

CAPÍTULO 5.

DESARROLLO Y VERIFICACIÓN

n este capítulo se presenta el desarrollo y verificación del Sistema de Telefonía Móvil detallando

cada uno de los procesos que lo componen como son: proceso Usuario, proceso Equipo

Terminal, proceso Sistema de Red, proceso Sistema de Atención al Cliente y el proceso Sistema de

Facturación.

5.1 INTRODUCCIÓN AL MODELO

Con base en el comportamiento que debe tener el sistema el modelo realizado contempla los siguientes

procesos:

• Usuario. El proceso Usuario realiza el inicio y el fin de la llamada a través de su equipo terminal.

• Equipo Terminal. El proceso Equipo Terminal sirve de interfaz entre el usuario y el sistema de

telefonía, pudiendo: emitir la petición de una llamada, obtener la conexión y avisar al sistema que la llamada finalizo.

• Sistema de Red. El proceso Sistema de Red, puede recibir peticiones del equipo terminal y

dependiendo la información obtenida del sistema de facturación dará un cierto tipo de conexión al usuario.

• Sistema de Atención al Cliente. El proceso de Sistema de Atención al Cliente, decide el tipo de

conexión que se asignará al usuario y se comunica con el sistema de facturación para que actué en consecuencia del tipo de conexión. Además se encarga del servicio de Override y decidir si la llamada es un posible fraude.

• Sistema de Facturación. El proceso de Sistema de Facturación controla los límites de crédito y

los ciclos de facturación, este proceso además se comunica con el proceso de Sistema de Red para enviar el tipo de conexión que tendrá el usuario a través de su equipo terminal.

En la Figura 8 se muestra un diagrama de clases en el que se aprecian los flujos de mensajes y

E

31

de control entre las instancias de los procesos necesarios para la implementación del sistema de límites

de crédito.

Figura 8: Diagrama de clases del Sistema de Telefonía Móvil.

A grandes rasgos, el modelo propuesto se basa en:

l. El usuario indica a través del equipo terminal su intención de realizar una llamada y de finalizarla. 2. La red deberá enviar la solicitud al sistema de atención al cliente. 3. El sistema de atención al cliente le da el estado que debe procesar al sistema de facturación. 4. El sistema de facturación le proporciona el tipo de conexión a la red. 5. El usuario recibe un servicio de la red a través de su equipo terminal.

A continuación se detalla cada uno de estos procesos a través de sus estados y el análisis de

partes importantes del código en IFx que se uso para construir el modelo.

5.2 PROCESO USUARIO

El usuario es el cliente final que interactúa con el sistema a través de su equipo terminal. Para modelar

su comportamiento deben considerarse únicamente dos eventos: el de inicio de llamada y el de final de

llamada.

32

Figura 9: Diagrama de estados del proceso Usuario

Estos dos eventos se expresan en el diagrama de estados de la Figura 9 que usa la señal

NumeroMarcado en la transición entre el estado idle y el estado esperando para el inicio de llamada. A

partir de aquí el usuario tiene dos posibles caminos (encontrándose en el estado esperando): el primero

que es colgar hasta que se inicie la llamada en tal caso se hará la transición entre el estado esperando y

el estado llamando o bien que cuelgue antes de que se le asignen recursos en el sistema de red en cuyo

caso realiza la transición entre el estado esperando y estado colgo. A efectos de modelado

consideramos con un guardia los dos comportamientos del usuario. En el siguiente fragmento de

código se muestra el camino a seguir por el usuario:

state esperando; when tiempo>1; reset tiempo; task colgar := true; output NumeroMarcado(true) via ({ue}0) to ({Equ ipo_Terminal}0); nextstate colgo; when tiempo<=1; reset tiempo; nextstate llamando; endstate; state llamando; informal "Se hace la llamada"; nextstate colgo; endstate;

Debe tenerse en cuenta que el usuario puede decidir colgar en este estado, no se debe perder de

vista que las decisiones que el usuario toma van dirigidas al equipo terminal pues es este su interfaz con

el resto del sistema. En el código siguiente se muestra que después de llamar el usuario cuelga, pero

33

avisa sus acciones solo al equipo terminal y nunca al sistema directamente.

state colgo; task colgar := true; skip; if (inactivar = 0) then task inactivar := 1; output NumeroMarcado(colgar) via ({ue}0) to ( {Equipo_Terminal}0); endif nextstate idle; provided (inactivar = 1); input UsuarioInactivo(); reset i; reset inactivar; nextstate inactivo; endstate;

5.3 PROCESO EQUIPO TERMINAL

En el modelo presentado, el equipo terminal sirve como interfaz entre el usuario y el sistema de red.

Una vez que el usuario desea realizar una llamada, el equipo terminal se comunica con la red

desencadenando un evento de inicio de llamada. Luego recibe el tipo de conexión asignado al usuario.

Se realiza la llamada y después entra a un estado de inactivo si es que el usuario termina la llamada.

En la Figura 10 se puede observar un diagrama de estados que modela el comportamiento del

equipo terminal en el sistema. Iniciando en el estado idle, en donde habrá una transición al estado

iniciando_llamada el cual enviará una señal Resultado(estado_facturacion) y esperará en éste estado el

tipo de conexión asignada al equipo, además se puede notar que si el usuario decide colgar en este

momento esta petición es atrapada por la señal SolicitaLlamada(inactivar) desencadenado la liberación

de recursos. Se realiza la transición del estado iniciando_llamda al estado de llamando y además se

puede recibir una nueva señal que contenga el tipo de conexión a través de la señal Resultado para

considerar que puede haber un cambio de tipo de llamada en el transcurso de la llamada.

Figura 10: Diagrama de estados del proceso Equipo Terminal

34

La parte esencial del proceso Equipo Terminal se muestra a continuación, en el estado

iniciando_llamada el proceso queda bloqueado hasta no recibir el tipo de llamada asignado, después de

recibir el tipo de conexión habrá una transición de este estado al estado llamando donde hará la llamada

propiamente, pero también hace referencia a sí mismo porque el usuario puede colgar en este momento.

state iniciando_llamada; provided (inactivar = 0 and colgar = false); input ResultadoE(estado_facturacion); if (estado_facturacion = 1) then task t1 := true; endif if (estado_facturacion = 2) then task t2 := true; endif if (estado_facturacion = 3) then task t3 := true; endif if (((t1 = true) or (t2 = true)) or (t3 = true) ) then skip; output SolicitaLlamada(1) via ({er}0) to ({Si stema_de_Red}0); output UsuarioInactivo() via ({eu}0) to ({Usu ario}0); task inactivar := 1; else skip; output UsuarioInactivo() via ({eu}0) to ({Usu ario}0); task inactivar := 1; endif nextstate llamando; nextstate iniciando_llamada;

Las variables t1, t2 y t3 se usan sólo como una forma de saber que tipo de llamada se realizo.

Cuando el Equipo Terminal requiere que se liberen los recursos que el Sistema de Red asigno ocupa la

señal SolicitaLlamada(1), el uno indica que el proceso Usuario a decidido colgar y por tanto se liberan

los recursos con la ayuda de la señal UsuarioInactivo(), esto recalca el uso del equipo terminal como

interfaz entre el usuario y el sistema.

5.4 PROCESO SISTEMA DE RED

Una vez que el equipo terminal indica la intención del usuario de realizar una llamada, el sistema de

red debe resolver qué tipo de conexión asignar a partir de la información que obtenga del sistema de

facturación que pueden ser una de las siguientes:

35

• Conexión Hotline: El usuario tiene un límite de crédito superado.

• Conexión Fraude: El servicio ha sido bloqueado por motivos de fraude.

• Conexión Llamada: El usuario puede realizar la llamada normalmente.

Tal y como se aprecia en la Figura 11, una vez que el Sistema de Red recibe una solicitud de

conexión a través de la señal NumeroMarcado pasa del estado idle a validando_servicio debe decidir

qué tipo de conexión asignar en función del estado asociado al servicio.

Para ello, recurre a los procesos de Sistema de Atención al Cliente que decide el tipo de

conexión asignar y el Sistema de Facturación que es quien cobra el servicio y responde al Sistema de

Red el estado de la conexión, el cual actúa en consecuencia pasando al estado de se_obtiene_sevicio el

cual dependiendo del estado de la conexión hará una transición a uno de los siguientes estados:

conexion_llamada, conexion_hotline o conexion_fraude.

Figura 11: Diagrama de estados del proceso Sistema de Red

Hay que tomar en cuenta que en el estado de validando_servicio se pueden liberar los recursos

antes de de que se establezca un tipo de conexión, esto tomando en cuenta que el usuario puede colgar

en cualquier momento. Por otro lado el estado de se_obtiene_servicio se establece una conexión que

puede ser atendida por un IVR en el caso real.

La siguiente parte de código muestra el estado más importante del proceso ya que es aquí donde

el Sistema de Facturación avisa el tipo de conexión a asignar al Sistema de Red, el Sistema de Red

resuelve el tipo de conexión usando la variable estado_facturacion y la comunica al proceso Usuario a

través del proceso Equipo Terminal.

state se_obtiene_servicio; provided (inactivar = 0); input Resultado(estado_facturacion); if (estado_facturacion = 1) then

36

output ResultadoE(1) via ({re}0) to ({Equipo_ Terminal}0); else if (estado_facturacion = 3) then output ResultadoE(3) via ({re}0) to ({Equipo_Termi nal}0); else output ResultadoE(2) via ({re}0) to ({Equipo_Termi nal}0); endif endif nextstate conexion_llamada; if (estado_facturacion = 2) then output ResultadoE(2) via ({re}0) to ({Equipo_ Terminal}0); else if (estado_facturacion = 1) then output ResultadoE(1) via ({re}0) to ({Equipo_Termi nal}0); else output ResultadoE(3) via ({re}0) to ({Equipo_Termi nal}0); endif endif nextstate conexion_hotline; if (estado_facturacion = 3) then output ResultadoE(1) via ({re}0) to ({Equipo_ Terminal}0); else if (estado_facturacion = 2) then output ResultadoE(2) via ({re}0) to ({Equipo_Termi nal}0); else output ResultadoE(1) via ({re}0) to ({Equipo_Termi nal}0); endif endif nextstate conexion_fraude; provided (estado_facturacion=0); nextstate inactivo; endstate;

5.5 PROCESO SISTEMA DE ATENCIÓN AL CLIENTE

El sistema de atención al cliente es el encargado de asignar el tipo de conexión, aunque no lo puede

asignar al sistema de red si no es por medio del sistema de facturación, se toma en cuenta que del

estado normal puede pasar a hotline debido a que en una llamada del usuario puede sobre pasar su

limite de crédito asignado, antes que termine la llamada. Aun más puede ser que el sistema de atención

al cliente pase de un estado a otro entre Normal, Hotline y Fraude antes de que termine la llamada del

usuario.

En la figura 12 se comienza con un estado idle y posteriormente pasa al estado activo donde se

decidirá el tipo de conexión a asignar y por medio de un número se enviará al estado correspondiente

para asignar la conexión, el uno representa a la conexión normal, el dos a la conexión hotline y el tres a

la conexión fraude, realizando la transición al estado correspondiente (normal, hotline o fraude) y

como es de esperarse todos los estados van a un estado inactivo ya que el usuario puede decidir colgar

37

en cualquier momento.

Figura 12: Diagrama de estados del proceso Sistema de Atención al Cliente

La siguiente parte de código representa el estado más importante del Sistema de Atención al

Cliente ya que es aquí donde se simula la asignación del tipo de conexión que tendrá el cliente a partir

de una petición del sistema de red, para esto lo que se hace es que se toman los tres posibles estados y

dependiendo cual se asigne se remitirá al estado correspondiente en el cual el estado de Hotline y

Fraude se atenderán con un Call Center a través de un VCR.

state activo; provided (inactivar = 0); input Estado(inactivar); nextstate idle; provided (l_estado = 1); task Ciclo := true; task Override := false; task LimiteSup := false; task Fraude := false; output EstadoFON(1, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); task l_estado := 2; nextstate normal; provided (l_estado = 2); task Ciclo := true; task Override := false; task LimiteSup := true; task Fraude := false; skip; output EstadoFON(2, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); task l_estado := 3; nextstate hotline; provided (l_estado = 3); task Ciclo := true; task Override := true; task LimiteSup := false; task Fraude := true; output EstadoFON(3, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); task l_estado := 1; nextstate fraude; provided (l_estado = 0); task Ciclo := true; task Override := false;

38

task LimiteSup := true; task Fraude := false; task l_estado := 2; output EstadoFON(2, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); nextstate inactivo; endstate;

5.6 PROCESO SISTEMA DE FACTURACIÓN

El sistema de facturación es el encargado de comprobar en todo momento el consumo de los servicios

pospago. En el modelo planteado, este sistema se encargará de modelar el comportamiento del servicio

desde el punto de vista de la facturación, además de informar al sistema de red el tipo de conexión

asignada al usuario.

Figura 13: Diagrama de estados del proceso Sistema de Facturación

En la Figura 13 se puede observar el comportamiento del Sistema de Facturación a través de un

diagrama de estados que muestra un estado idle como comienzo, pasando por el estado factura si la

señal inactivar emitida por el proceso de Sistema de Atención al Cliente es cero hay una transición

hacia el estado de factura, si es uno la hace hacia el estado de inactivo.

Una vez en el estado factura los servicios que se proveen se simulan a través de una de los

siguientes dos estados: sin_limite o limite_superado. Deberán restringirse las llamadas que sean

atendidas a través del estado limite_superado, permitiéndose la realización de llamada para el tipo de

conexión Normal a través del estado sin_limite.

39

Debe recordarse que los cambios de estado están supeditados a las condiciones de fraude

establecidas por el sistema de atención al cliente. Es decir, si el servicio esta en fraude, el sistema de

facturación no podrá aplicar ningún cambio de estado al servicio.

Si el servicio supera su límite de crédito (LimiteSup) y no es sospechoso de fraude, pasa del

estado sin_limite al estado limite_superado.

Si ya se ha efectuado la facturación de un servicio en estado limite_superado y no es

sospechoso de fraude, deberá devolvérsele al estado sin_limite.

Igualmente, si se aplica un override al servicio en estado limite_superado y no es sospechoso de

fraude, también deberá devolvérsele al estado sin_limite.

La siguiente parte de código representa el estado más importante del proceso Sistema de

Facturación ya que es aquí donde se comunica al proceso Sistema de Red el tipo de conexión que

tendrá el cliente a partir de una petición de llamada, además de estar verificando el estatus del límite de

crédito y comunicándolo al estado de sin_limite o limite_superado respectivamente.

state factura; provided (estado_facturacion = 1); output Resultado(1) via ({fr}0) to ({Sistema_de _Red}0); reset estado_facturacion; nextstate sin_limite; reset estado_facturacion; nextstate idle; provided (estado_facturacion = 2); output Resultado(2) via ({fr}0) to ({Sistema_de _Red}0); reset estado_facturacion; nextstate limite_superado; reset estado_facturacion; nextstate idle; provided (estado_facturacion = 3); output Resultado(3) via ({fr}0) to ({Sistema_de _Red}0); reset estado_facturacion; nextstate idle; reset estado_facturacion; nextstate limite_superado; provided (inactivar = 1); reset estado_facturacion; reset inactivar; nextstate inactivo; endstate;

40

5.7 OBSERVADOR DEL SISTEMA

El proceso observador es el encargado de comprobar durante la ejecución que el comportamiento del

Sistema de Telefonía Móvil sea el correcto, será en el proceso Sistema de Atención al Cliente donde

revisará que se cumplan tres propiedades; si se cumple alguna de estas se considera que el sistema tiene

un error, estas tres propiedades son:

1) El estado de Hotline no tiene la bandera de LimiteSup como verdadera. Esto representaría que el usuario sobrepasó su límite de crédito y el sistema no se dio por enterado.

2) El estado de Fraude no tiene la bandera de Fraude como falsa. Esto representaría que el usuario

esta en un posible fraude y el sistema no actúa en consecuencia. 3) Es estado de Normal (llamada normal) no tiene la bandera de Fraude en falso. Esto representaría

que el sistema toma como fraude una llamada normal.

En la Figura 14 se puede observar el comportamiento del Observador a través de un diagrama de

estados que al ser modelado lo único que hace es que al encontrar un mensaje de ERROR

inmediatamente levantará una bandera de cut = true la cual indica en IF que el proceso cumple una

propiedad no deseada.

Figura 14: Diagrama de estados del proceso Observador

Cuando el sistema de atención al cliente cumple alguna de las propiedades anteriores emite un

mensaje de Error el cual es captado por el observador y lo anuncia.

El siguiente código corresponde al proceso observador donde verifica en todo la explosión de

estados (o al hacer una prueba a través de if2gui) si existe alguna de las propiedades no deseadas,

básicamente si algún estado emite el mensaje “—ERROR—“ anuncia que existe un error en el sistema.

cut observer observador; state s #start ; deadline lazy; match informal "-- ERROR--" ;

41

cut; nextstate -; endstate; endobserver;

5.8 RESULTADOS

Se presentan los resultados verificados del sistema a través del modelo creado como se muestra en el

siguiente texto (y del observador empleado para la verificación de las propiedades enunciadas en el

apartado 5.7 de este documento).

$ ./telefonia.x -bfs -t telefonia.aut -q telefonia. states 00:08:20 2437456/s 12429057/t queue table : 46 items 13/entry 4/min 8/max 3.54/avg message table : 30 items 13/entry 4/min 8/max 2.31/avg instance table : 438 items 29/entry 4/min 32/max 15.10/avg config table : 2437456 items 134837/entry 4/min 40/max 18.08/avg chunk table : 309374 items 16843/entry 8/min 40/max 18.37/avg label table : 12429112 items 539389/entry 8/min 52/max 23.04/avg event table : 50 items 13/entry 0/min 12/max 3.85/avg

Al crear el modelo se han generado 2, 437, 456 estados y 12, 429, 057 transiciones con 2 usuarios

haciendo peticiones de llamada. A continuación se describe pequeñas partes del modelo que son muy

importantes dentro del Sistema de Telefonía Móvil y lo que es creado para su óptimo funcionamiento.

• El Usuario sólo se encarga de iniciar la llamada y terminarla y lo importante aquí es cuando se

termina la llamada ya que esto puede ocurrir en cualquier momento y se liberan todos los

servicios, además de pasar a estado inactivo.

Como se muestra en el siguiente fragmento del modelo creado, aquí se inicia la llamada y

posteriormente se termina, puede observarse que el parámetro en la señal NumeroMarcado si es falso

(f) significa que no se ha colgado por el contrario si es true (t) significa que el usuario a terminado la

llamada:

/*Inicio de llamada */

(0,"<<{Usuario}0 @tiempollamada>> <<{Usuario}0

42

!NumeroMarcado{p1=f}#{Equipo_Terminal}0{ue}0>> ",1)

/*Fin de llamada */

(4,"<<{Usuario}0 !NumeroMarcado{p1=t}#{Equipo_Termi nal}0{ue}0>> ",8)

• El Equipo Terminal actúa como interfaz entre el Usuario y el Sistema, lo importante aquí es que

convive con el sistema a través del Sistema de Red enviándole peticiones y recibiendo servicios.

En la siguiente parte del modelo se muestra el envió de peticiones, la recepción de servicios la

mostraremos cuando tratemos el siguiente punto (El Sistema de Red):

/* Envió de petición */

(3,"<<{Equipo_Terminal}0 ?NumeroMarcado{p1=f}{Equip o_Terminal}0>> <<{Equipo_Terminal}0 !SolicitaLlamada{p1=0}#{Sistem a_de_Red}0{er}0>> ",6)

• El Sistema de Red se encarga de realizar la atención de las peticiones del equipo terminal y

asignarlas al proceso de Atención al Cliente para que este decida el estado de la conexión,

recibiendo la decisión final por parte del Sistema de Facturación. Como se muestra a

continuación parte del modelo en el que el Sistema de Red recibe y envía peticiones.

/* Envió de petición al Sistema de Atención al Clie nte */

(22,"<<{Sistema_de_Red}0 !Estado{p1=0}#{Sistema_de_ Atencion_al_Cliente}0{ra}0>> ",43)

/* Envió de Servicio al Equipo Terminal*/

(43,"<<{Sistema_de_Red}0 !ResultadoE{p1=1}#{Equipo_ Terminal}0{re}0>> ",82)

• El Sistema de Atención al Cliente es el encargado de asignar el tipo de servicio e informárselo

al Sistema de Facturación para que este actúe en consecuencia. En la siguiente parte del modelo

creado se observa como el Sistema de Atención al Cliente envía el tipo de conexión al Sistema

de Facturación, en este caso particular a través del primer parámetro se envía el tipo de

conexión 2 que representa el tipo de conexión hotline:

/* Envío de Tipo de Conexión al Sistema de Facturac ión */

(161,"<<{Sistema_de_Atencion_al_Cliente}0 !EstadoFON{p1=2,p2=0}#{Sistema_de_Facturacion}0{af} 0>> ",334)

• El Sistema de Facturación es el encargado de hacer el cobro y comunicar al Sistema de Red el

43

tipo de conexión asignado. En la siguiente parte del modelo se muestra un ejemplo de esta

comunicación.

/* Envío del Tipo de Conexión al Sistema de Red */

(1414,"<<{Sistema_de_Facturacion}0 !Resultado{p1=2} #{Sistema_de_Red}0{fr}0>> ",2698)

Con el observador se verificaron las siguientes propiedades:

• El estado del tipo de conexión Hotline no tuvo la bandera de LimiteSup como verdadera.

• El estado del tipo de conexión Fraude no tuvo la bandera de Fraude como falsa.

• Es estado del tipo de conexión Normal no tuvo la bandera de Fraude en verdadero.

La siguiente figura muestra como es verdad que dichas propiedades se cumplieron.

Figura 15: Confirmación de propiedades verificadas en el modelo

Para observar todo el código fuente del Sistema de Telefonía Móvil hacer referencia al Apéndice D.

44

CAPÍTULO 6.

CONCLUSIONES

on base al sistema desarrollado se obtuvieron importantes conocimientos acerca de la

Verificación Formal de Sistemas en particular de la Verificación de Modelos (Model Checking).

Además de estudiar las características y uso de la Herramienta IF.

Antes de empezar a incursionar en la herramienta se estudio la Verificación de Modelos para

comprender mejor sus fundamentos y su funcionamiento para posteriormente ser aplicados en la

solución de problemas de Ingeniería de Software.

Ya con los conocimientos necesarios se siguió con la instalación y uso de la herramienta IF la

cual se puede instalar correctamente en la distribución Fedora Core 3 de Linux y comprendiéndola a

partir de los ejemplos adjuntos en la herramienta.

Con la herramienta IF instalada se prosiguió con la instalación y uso de la herramienta gráfica

IFx que también fue instalada con éxito en la distribución Fedora Core 3 de Linux y comprendiéndola

con los ejemplos adjuntos en ella y finalmente realizando un ejemplo para reforzar los conocimientos

adquiridos hasta ese momento.

Finalmente ya con la experiencia adquirida nos propusimos al desarrollo del caso de estudio

propuesto en esta tesis (Sistema de Telefonía Móvil) para aplicar todos esos conocimientos que se

fueron comprendiendo con el paso del tiempo.

La Verificación de Modelos nos ayuda a crear software de alta calidad que haga que los sistemas sean

menos propensos a tener errores y por tanto poder ser usado en aplicaciones que no admitan error.

Lo que nos deja la Verificación de Modelos es su útil y seguro funcionamiento para verificar sistemas

incluso antes de empezar a programar ya que esto es importante dentro de cualquier proceso de

desarrollo.

Al utilizar herramientas complementarias como las herramientas CASE es bueno trabajar con

prototipos (pequeños ejemplos) que ratifiquen su correcto funcionamiento en conjunto con la

C

45

herramienta de Verificación de Modelos para disminuir el tiempo de estudio de dichas herramientas.

Uno de los problemas encontrados con la herramienta fue la instalación en la plataforma ya que

después de ser probada en varias herramientas se encontró que la distribución Fedora Core 3 de Linux

pero que aún es complicada instalación debido a que se recurrieron a archivos que solo los creadores de

la herramienta IF tienen. En el caso de IFx se requiere para su buen funcionamiento que tengan como

compilador nativo el gcc versión 3.3 o 3.2 por que de lo contrario la herramienta no funciona, esto crea

una gran restricción en la plataforma de desarrollo.

Una de las grandes contribuciones que tuvo la herramienta IFx en nuestra implementación del caso de

estudio es que nos auxilio a verificar las propiedades deseadas lo cual hubiera sido imposible o en todo

caso nos hubiera llevado mucho trabajo sin esta.

La herramienta permite la construcción incremental del sistema ya que nos permitió ir desarrollando y

verificando cada uno de los procesos que posteriormente constituyeron el sistema en su totalidad.

Este trabajo se concluyo satisfactoriamente gracias a la forma en que modelamos nuestro caso de

estudio en donde la complejidad se iba incrementando conforme a los avances obtenidos en este

proyecto, ya que los procesos se comunican a través de ruta de señales y que lo que queríamos

modelar fuera coherente y razonable con lo propuesto en el modelo.

46

APÉNDICE A INSTALACIÓN IF EN FEDORA CORE 3

Las distribuciones en las que se probó la instalación de la herramienta IF fueron: Red Hat 9 y Fedora

Core 3 en las que funciono correctamente. En el caso de Red Hat 9 basta con descargar el archivo3,

descomprimirlo y seguir las instrucciones que están en el archivo INSTALL. Hay que mencionar que

aunque se hace referencia al gcc 3.3, Red Hat cuenta con el gcc 3.2 y aun así funciona correctamente.

En la distribución de Fedora Core 3 es casi lo mismo pero con algunos detalles que a

continuación se detallan:

1. Se descarga el archivo de “IF-2.0 on Linux-GCC 3.3” (figura 16)

2. Se descomprime el archivo en el directorio /usr/local, con la siguiente instrucción:

$ark IF-2.0.iX86.26.01.05.tgz

3. Se modifica el bash en la sesión del usuario colocando las instrucciones que se a continuación:

a) $vi .bashrc

b) Al final del archivo se agrega:

export IF=/usr/local/IF export PATH=$IF/com:$PATH export PATH=$IF/bin/’arch’:$PATH

Se sobrescriben los archivos table.h y table.i los cuales fueron proporcionados por el Dr. Marius Bozga,

CNRS Research Engineer (IR2) de VERIMAG y correo electrónico marius.bozga@imag.fr. Y se

colocaron en la dirección $IF/src/simulator/. Estos archivos hacen que funcione la herramienta

correctamente usando gcc 3.4.

3 (2005, noviembre, 03), [En Línea].Disponible: http://www-verimag.imag.fr/~async/IF/index.shtml.en

47

APÉNDICE B INSTALACIÓN IFx EN FEDORA CORE 3

La instalación de esta herramienta fue más complicada por estar diseñado para usar gcc 3.3 como

compilador nativo, a continuación se describen los pasos seguidos para la instalación:

1. Se descarga el archivo de “IFx-2.0 on Linux-GCC 3.3” 4

Figura 16: Página de verimag

2. Se descomprime el archivo en el directorio /usr/local, con la siguiente instrucción:

$ark IFx-2.0.iX86.21.10.05.tgz

3. Se descarga el archivo xerces de la dirección http://xml.apache.org/

4. Descomprimir el archivo en la dirección /usr/local

5. Agregar el paquete de Desarrollo de software de legado de la distribución Fedora Core 3 ya que aquí

se incluye el gcc 3.3 que se utiliza para la herramienta (figura 17).

Figura 17: Gestión de los paquetes de Linux Fedora Core 3 4 (2005, noviembre, 03), [En Línea].Disponible: http://www-verimag.imag.fr/~async/IF/index.shtml.en

48

6. Se descarga e instala la Máquina Virtual de Java para Linux 1.4 de la página http://www.sun.com

7. Se modifica el bash en la sesión del usuario colocando las instrucciones que se describen a

continuación:

a) $vi .basrc

b) Al final del archivo se agrega:

export IF=/usr/local/IF export PATH=$IF/com:$PATH export PATH=$IF/bin/`arch`:$PATH export XERCESLIB=/usr/local/xercesc/lib/iX86 export LD_LIBRARY_PATH=${XERCESLIB}:${LD_LIBRARY_PATH} export PATH=<directorio java>/include:$PATH export PATH=<directorio java>/lib:$PATH export PATH=<directorio java>/bin:$PATH

8. Se modifica el archivo Makefile de la dirección /usr/local/IF/com en la linea “CC = g++”

sustituyéndola por “CC = gcc33”.

9. Finalmente al escribir if2gui en la línea de comando se mostrara la herramienta IFx (figura 18).

Figura 18: Ambiente gráfico de IF

49

APÉNDICE C GLOSARIO DE TÉRMINOS

TÉRMINO DESCRIPCIÓN

AUC O Authentication Center es el dispositivo que controla los derechos de uso que cada abonado posee sobre los servicios de la red.

BSC Siglas de Base Station Controller, es el equipo encargado de la gestión de un conjunto de BTS, cumpliendo funciones de comunicación v explotación

BTS O Base Transceiver Station, es un equipo que se encarga de garantizar la cobertura radioeléctrica en una de las células de la red GSM.

Call Center Centro de atención telefónica perteneciente al sistema de Atención al Cliente.

CDR Customer Data Register es el archivo que contiene los detalles de una llamada. Información que contiene puede ser la hora de la llamada, los números origen y destino y la duración de la llamada entre otros.

GSM

Siglas de Global SystemforMobile Communications es la norma de transmisiones móviles más extendida hoy en día. Ofrece a los usuarios tres clases de servicios: Servicios Portadores (permiten transferencias de datos de hasta 14,4 kbits/s), Teleservicios (telefonía, intercambio de mensajes alfanuméricos cortos) y Servicios Suplementarios (identificación de abonado, redireccionamiento de llamadas).

HLR Siglas de Home Location Register, es una base de datos que contiene la información relativa a los abonados de la red.

Hotline Teléfono con un mensaje automático que proporciona algún tipo de información.

IVR Siglas de Interactive Voice Responder, se trata de un equipo con la capacidad de interactuar con los usuarios a través de comandos de voz o del teclado del terminal móvil.

NSS Siglas de Network Subsystem, es la agrupación del VLR, el HLR y el AUC.

Out-of-the-box Dícese de un sistema que no ha sufrido ninguna modificación desde su entrega inicial.

Override Ampliación de un límite de crédito.

Pospago Método de pago con cargo a una cuenta. En telefonía móvil suelen pasarse los cargos en ciclos de facturación mensuales.

Prepago Método de pago anticipado. Es necesario adelantar una cantidad que supondrá el límite del servicio.

SIM Siglas de Subscriber Identity Module es un dispositivo personal para cada abonado que aloja el número que identifica a un usuario dentro de la red de telefonía móvil.

Threshold Límite de crédito o umbral.

Tickets de llamada

Son los mensajes enviados por los BTS al NSS que indican los pasos de una llamada. Así hay un ticket de inicio de llamada, otros tickets de consumo y un ticket de fin de llamada.

VLR Visitor Location Register es la base de datos asociada al MSC que almacena información dinámica relativa a los abonados de paso por la red.

50

APÉNDICE D CÓDIGO FUENTE DEL SISTEMA DE TELEFONÍA MÓVIL

system telefonia_movil; const N = 2; signal NumeroMarcado(boolean); signal SolicitaLlamada(integer); signal Estado(integer); signal EstadoFON(integer, integer); signal Resultado(integer); signal ResultadoE(integer); signal Establecido(); signal UsuarioInactivo(); signalroute ue(1) from Usuario to Equipo_Terminal with NumeroMarcado; signalroute er(1) from Equipo_Terminal to Sistema_de_Red with SolicitaLlamada; signalroute ra(1) from Sistema_de_Red to Sistema_de_Atencion_al_Cli ente with Estado; signalroute af(1) from Sistema_de_Atencion_al_Cliente to Sistema_de _Facturacion with EstadoFON; signalroute fr(1) from Sistema_de_Facturacion to Sistema_de_Red with Resultado; signalroute re(1) from Sistema_de_Red to Equipo_Terminal with ResultadoE; signalroute eu(1) from Equipo_Terminal to Usuario with Establecido, UsuarioInactivo; process Usuario(1); var tiempo clock private; var colgar boolean private; var i integer private; var inactivar integer private; var x integer private; procedure tiempollamada; fpar out x integer; {# srand(1); x = (rand() % 100) + 1; #} endprocedure; state idle #start ; provided (i < N); skip; task colgar := false;

51

call tiempollamada(x); if ((inactivar = 0) and (i <> N)) then output NumeroMarcado(colgar) via ({ue}0) to ( {Equipo_Terminal}0); endif task i := (i + 1); set tiempo := 0; reset colgar; nextstate esperando; provided (inactivar = 1); input UsuarioInactivo(); reset i; reset inactivar; nextstate inactivo; endstate; state esperando; when tiempo>x; reset tiempo; task colgar := true; output NumeroMarcado(true) via ({ue}0) to ({Equ ipo_Terminal}0); nextstate colgo; when tiempo<=x; reset tiempo; nextstate llamando; endstate; state llamando; informal "Se hace la llamada"; nextstate colgo; endstate; state colgo; task colgar := true; skip; if (inactivar = 0) then task inactivar := 1; output NumeroMarcado(colgar) via ({ue}0) to ( {Equipo_Terminal}0); endif nextstate idle; provided (inactivar = 1); input UsuarioInactivo(); reset i; reset inactivar; nextstate inactivo; endstate; state inactivo; endstate; endprocess; process Equipo_Terminal(1); var estado_facturacion integer private; var colgar boolean private; var t1 boolean private; var t2 boolean private; var t3 boolean private; var inactivar integer private; state idle #start ; provided (colgar = false);

52

input NumeroMarcado(colgar); skip; if (colgar = false) then output SolicitaLlamada(inactivar) via ({er}0) to ({Sistema_de_Red}0); endif reset estado_facturacion; reset colgar; nextstate iniciando_llamada; provided (inactivar = 0); input ResultadoE(estado_facturacion); if (estado_facturacion = 1) then task t1 := true; endif if (estado_facturacion = 2) then task t2 := true; endif if (estado_facturacion = 3) then task t3 := true; endif reset estado_facturacion; nextstate iniciando_llamada; provided (inactivar = 1); reset estado_facturacion; reset inactivar; nextstate inactivo; endstate; state iniciando_llamada; provided (inactivar = 0 and colgar = false); input ResultadoE(estado_facturacion); if (estado_facturacion = 1) then task t1 := true; endif if (estado_facturacion = 2) then task t2 := true; endif if (estado_facturacion = 3) then task t3 := true; endif if (((t1 = true) or (t2 = true)) or (t3 = true) ) then skip; output SolicitaLlamada(1) via ({er}0) to ({Si stema_de_Red}0); output UsuarioInactivo() via ({eu}0) to ({Usu ario}0); task inactivar := 1; else skip; output UsuarioInactivo() via ({eu}0) to ({Usu ario}0); task inactivar := 1; task t1 := true; endif nextstate llamando; provided (colgar = false); input NumeroMarcado(colgar); nextstate iniciando_llamada; nextstate llamando; provided (colgar = true); nextstate inactivo; provided (estado_facturacion=0); input ResultadoE(estado_facturacion);

53

if (estado_facturacion = 1) then task t1 := true; endif if (estado_facturacion = 2) then task t2 := true; endif if (estado_facturacion = 3) then task t3 := true; endif nextstate llamando; provided (colgar=false); input NumeroMarcado(colgar); nextstate llamando; provided (inactivar = 1); reset inactivar; nextstate inactivo; endstate; state llamando; informal "Se realiza la llamada dependiendo el tipo que haya sido"; if (estado_facturacion = 1) then task t1 := true; endif if (estado_facturacion = 2) then task t2 := true; endif if (estado_facturacion = 3) then task t3 := true; endif nextstate idle; nextstate inactivo; endstate; state inactivo; input NumeroMarcado(colgar); nextstate inactivo; endstate; endprocess; process Sistema_de_Red(1); var inactivar integer private; var estado_facturacion integer private; state idle #start ; input SolicitaLlamada(inactivar); nextstate validando_servicio; provided (inactivar = 1); output Estado(inactivar) via ({ra}0) to ({Siste ma_de_Atencion_al_Cliente}0); reset inactivar; reset estado_facturacion; nextstate inactivo; endstate; state validando_servicio; output Estado(inactivar) via ({ra}0) to ({Siste ma_de_Atencion_al_Cliente}0); nextstate se_obtiene_servicio;

54

provided (inactivar = 1); output Estado(inactivar) via ({ra}0) to ({Siste ma_de_Atencion_al_Cliente}0); reset inactivar; reset estado_facturacion; nextstate inactivo; endstate; state se_obtiene_servicio; provided (inactivar = 0); input Resultado(estado_facturacion); if (estado_facturacion = 1) then output ResultadoE(1) via ({re}0) to ({Equipo_ Terminal}0); else if (estado_facturacion = 3) then output ResultadoE(3) via ({re}0) to ({Equipo_Termi nal}0); else output ResultadoE(2) via ({re}0) to ({Equipo_Termi nal}0); endif endif nextstate conexion_llamada; if (estado_facturacion = 2) then output ResultadoE(2) via ({re}0) to ({Equipo_ Terminal}0); else if (estado_facturacion = 1) then output ResultadoE(1) via ({re}0) to ({Equipo_Termi nal}0); else output ResultadoE(3) via ({re}0) to ({Equipo_Termi nal}0); endif endif nextstate conexion_hotline; if (estado_facturacion = 3) then output ResultadoE(1) via ({re}0) to ({Equipo_ Terminal}0); else if (estado_facturacion = 2) then output ResultadoE(2) via ({re}0) to ({Equipo_Termi nal}0); else output ResultadoE(1) via ({re}0) to ({Equipo_Termi nal}0); endif endif nextstate conexion_fraude; provided (estado_facturacion=0); nextstate inactivo; endstate; state conexion_hotline; informal "Se hace llamda hotline"; nextstate idle; nextstate inactivo; endstate; state conexion_fraude; informal "Esta llamada es posible fraude"; nextstate idle; nextstate inactivo; endstate; state conexion_llamada; informal "Se realiza una llamada normal"; nextstate idle; nextstate inactivo; endstate; state inactivo; input Resultado(estado_facturacion);

55

nextstate inactivo; endstate; endprocess; process Sistema_de_Atencion_al_Cliente(1); var l_estado integer private; var Override boolean private; var LimiteSup boolean private; var Fraude boolean private; var Ciclo boolean private; var inactivar integer private; state idle #start ; provided ((l_estado < 4) or (inactivar = 0)); input Estado(inactivar); nextstate activo; provided (inactivar = 1); output EstadoFON(1, 1) via ({af}0) to ({Sistema _de_Facturacion}0); reset l_estado; reset inactivar; nextstate inactivo; endstate; state activo; provided (inactivar = 0); input Estado(inactivar); nextstate idle; provided (l_estado = 1); task Ciclo := true; task Override := false; task LimiteSup := false; task Fraude := false; output EstadoFON(1, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); task l_estado := 2; nextstate normal; provided (l_estado = 2); task Ciclo := true; task Override := false; task LimiteSup := true; task Fraude := false; skip; output EstadoFON(2, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); task l_estado := 3; nextstate hotline; provided (l_estado = 3); task Ciclo := true; task Override := true; task LimiteSup := false; task Fraude := true; output EstadoFON(3, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); task l_estado := 1; nextstate fraude; provided (l_estado = 0); task Ciclo := true; task Override := false; task LimiteSup := true; task Fraude := false; task l_estado := 2;

56

output EstadoFON(2, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); nextstate inactivo; provided ((l_estado = 2) and (LimiteSup = false)) ; informal "-- ERROR--" ; nextstate activo; provided ((l_estado = 3) and (Fraude = false)); informal "-- ERROR--" ; nextstate activo; provided ((l_estado = 1) and (Fraude = true)); informal "-- ERROR--" ; nextstate activo; endstate; state normal; provided (inactivar = 1); output EstadoFON(1, 1) via ({af}0) to ({Sistema _de_Facturacion}0); reset l_estado; reset Override; reset LimiteSup; reset Fraude; reset Ciclo; reset inactivar; nextstate inactivo; provided (LimiteSup = true); task Fraude := true; task LimiteSup := false; task Override := true; task l_estado := 2; nextstate hotline; reset Override; reset LimiteSup; reset Fraude; reset Ciclo; nextstate activo; nextstate hotline; provided Fraude = true; nextstate fraude; endstate; state hotline; provided ((((Override = true) and (Ciclo = true)) and (inactivar = 0)) = true); output EstadoFON(1, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); task Fraude := true; nextstate normal; reset Override; reset LimiteSup; reset Fraude; reset Ciclo; nextstate activo; provided ((Fraude = true) and (inactivar = 0)); task LimiteSup := true; task Fraude := true; task Ciclo := false; output EstadoFON(3, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); nextstate fraude; provided Override = true;

57

nextstate hotline; provided Fraude = false; nextstate normal; provided (l_estado=0 or inactivar =1); nextstate inactivo; endstate; state fraude; provided ((((Fraude = false) and (LimiteSup = tru e)) and (inactivar = 0)) = true); output EstadoFON(2, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); nextstate hotline; reset Override; reset LimiteSup; reset Fraude; reset Ciclo; nextstate activo; provided (Fraude = true); output EstadoFON(3, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); task Ciclo := true; task LimiteSup := false; task Override := false; nextstate fraude; reset Override; reset LimiteSup; reset Fraude; reset Ciclo; nextstate activo; provided ((((Fraude = false) and (LimiteSup = fal se)) and (inactivar = 0)) = true); output EstadoFON(1, inactivar) via ({af}0) to ( {Sistema_de_Facturacion}0); nextstate normal; reset Override; reset LimiteSup; reset Fraude; reset Ciclo; nextstate activo; nextstate normal; provided LimiteSup = true; nextstate hotline; provided (l_estado=0 or inactivar = 1); output EstadoFON(1, 1) via ({af}0) to ({Sistema _de_Facturacion}0); reset l_estado; reset Override; reset LimiteSup; reset Fraude; reset Ciclo; reset inactivar; nextstate inactivo; endstate; state inactivo; endstate; endprocess; process Sistema_de_Facturacion(1); var estado_facturacion integer private;

58

var inactivar integer private; state idle #start ; provided (inactivar=0); input EstadoFON(estado_facturacion, inactivar); nextstate factura; provided (inactivar = 1); reset inactivar; nextstate inactivo; endstate; state factura; provided (estado_facturacion = 1); output Resultado(1) via ({fr}0) to ({Sistema_de _Red}0); reset estado_facturacion; nextstate sin_limite; reset estado_facturacion; nextstate idle; provided (estado_facturacion = 2); output Resultado(2) via ({fr}0) to ({Sistema_de _Red}0); reset estado_facturacion; nextstate limite_superado; reset estado_facturacion; nextstate idle; provided (estado_facturacion = 3); output Resultado(3) via ({fr}0) to ({Sistema_de _Red}0); reset estado_facturacion; nextstate idle; reset estado_facturacion; nextstate limite_superado; provided (inactivar = 1); reset estado_facturacion; reset inactivar; nextstate inactivo; endstate; state sin_limite; provided (inactivar = 1); reset inactivar; nextstate inactivo; nextstate idle; endstate; state limite_superado; provided (inactivar = 1); reset inactivar; nextstate inactivo; nextstate idle; endstate; state inactivo; endstate; endprocess; endsystem;

59

APÉNDICE E CÓDIGO FUENTE DE LOS FILÓSOFOS

COMENSALES

FILÓSOFOS CON ABRAZO MORTAL

system filosofos; const N = 5; type arrpid = array [N] of pid; type ten = array [N] of boolean; type estado = enum pensando, comiendo endenum; signal pide(integer, integer, integer, pid); signal da(); signal devuelve(integer, integer); signalroute fs(1) from filosofo to mesa with pide, devuelve; signalroute sf(1) from mesa to filosofo with da; process mesa(1); var palillo ten; var i integer; var x arrpid; var indi integer; var indd integer; var quien pid; var pd integer; var piderecurso integer; state idle #start ; deadline lazy; provided (i < N); x[i] := fork filosofo(self); task palillo[i]:=false; task i := (i + 1); nextstate idle; provided i=N; nextstate dar; endstate;

60

state dar; input pide(pd, indi, indd, quien); if (pd = 0) then task palillo[indi] := false; task palillo[indd] := false; task piderecurso := piderecurso - 2; endif if (palillo[indi] = false and pd = 1) then output da() via {sf}0 to quien; task palillo[indi] := true; endif if pd = 1 then task piderecurso := piderecurso + 1; endif if (piderecurso >= 2*N) then informal "-- ABRAZO MORTAL--" ; endif nextstate dar; endstate; endprocess; process filosofo(0); fpar parent pid; var ef estado; var obtieneiz boolean; var obtienede boolean; var pideiz boolean; var pidede boolean; var ti integer; var td integer; var mpid pid; state piensa #start ; task ef:=pensando; task pideiz := true; task pidede := false; task obtieneiz := false; task obtienede := false; task ti := {integer}self; task td := {integer}self; task td := (td +1) % N; nextstate pideiz; endstate; state pideiz; provided obtieneiz = false and pideiz = true; output pide(1, ti, td, self) via {fs}0 to {me sa}0; task pideiz := false; task pidede := true; nextstate pideiz; provided obtieneiz = false and pideiz = false; input da(); task obtieneiz := true; nextstate pideder;

61

endstate; state pideder; provided obtienede = false and pidede = true; output pide(1,td,ti, self) via {fs}0 to {mesa }0; task pidede := false; task pideiz := false; nextstate pideder; provided obtienede = false and pidede = false; input da(); task obtienede := true; nextstate come; endstate; state come; task ef := comiendo; output pide(0, ti, td, self) via {fs}0 to {mes a}0; nextstate piensa; endstate; endprocess; endsystem; cut observer obs; state s #start ; deadline lazy; match informal "-- ABRAZO MORTAL--" ; cut; nextstate -; endstate; endobserver;

FILÓSOFOS SIN ABRAZO MORTAL

system filosofos; const N = 5; type arrpid = array [N] of pid; type ten = array [N] of boolean; type estado = enum pensando, comiendo endenum; signal pide(integer, integer, integer, pid,integer) ; signal da(); signal devuelve(integer, integer); signalroute fs(1) from filosofo to mesa

62

with pide, devuelve; signalroute sf(1) from mesa to filosofo with da; process mesa(1); var palillo ten; var i integer; var x arrpid; var indi integer; var indd integer; var quien pid; var pd integer; var piderecurso integer; var lado integer; state idle #start #urgent ; deadline lazy; provided (i < N); x[i] := fork filosofo(self); task palillo[i]:=false; task i := (i + 1); nextstate idle; provided i=N; nextstate dar; endstate; state dar #urgent ; input pide(pd, indi, indd, quien,lado); if (pd = 0) then task palillo[indi] := false; task palillo[indd] := false; task piderecurso := piderecurso - 2; endif if (palillo[indi] = false and pd = 1) then output da() via {sf}0 to quien; task palillo[indi] := true; endif if pd = 1 then task piderecurso := piderecurso + 1; endif if (piderecurso >= 2*(N)) then informal "-- ABRAZO MORTAL--" ; endif nextstate dar; endstate; endprocess; process filosofo(0);

63

fpar parent pid; var ef estado; var obtieneiz boolean; var obtienede boolean; var pideiz boolean; var pidede boolean; var ti integer; var td integer; var mpid pid; state piensa #start #urgent ; provided {integer}self <> 0; task ef:=pensando; task pideiz := true; task pidede := false; task obtieneiz := false; task obtienede := false; task ti := {integer}self; task td := {integer}self; task td := (td +1) % N; nextstate pideiz; provided {integer}self = 0; task ef:=pensando; task pideiz := false; task pidede := true; task obtieneiz := false; task obtienede := false; task ti := {integer}self; task td := {integer}self; task td := (td +1) % N; nextstate pideder; endstate; state pideiz #urgent ; provided obtieneiz = false and pideiz = true and { integer}self <> 0; output pide(1, ti, td, self,0) via {fs}0 to { mesa}0; task pideiz := false; task pidede := true; nextstate pideiz; provided obtieneiz = false and pideiz = false and {integer}self <> 0; input da(); task obtieneiz := true; nextstate pideder; provided obtieneiz = false and pideiz = true and {i nteger}self = 0; output pide(1,ti,td, self,1) via {fs}0 to {me sa}0; task pideiz := false; task pidede := false; nextstate pideiz; provided obtieneiz = false and obtienede = true an d {integer}self = 0; input da(); task obtieneiz := true; nextstate come; endstate; state pideder;

64

provided obtienede = false and pidede = true and { integer}self <> 0; output pide(1,td,ti, self,1) via {fs}0 to {me sa}0; task pidede := false; task pideiz := false; nextstate pideder; provided obtienede = false and obtieneiz = true an d {integer}self <> 0; input da(); task obtienede := true; nextstate come; provided obtienede = false and pidede = true and { integer}self = 0; output pide(1, td, ti, self,0) via {fs}0 to { mesa}0; task pidede := false; task pideiz := true; nextstate pideder; provided obtienede = false and pidede = false and {integer}self = 0; input da(); task obtienede := true; nextstate pideiz; endstate; state come; task ef := comiendo; output pide(0, ti, td, self,0) via {fs}0 to {m esa}0; nextstate piensa; endstate; endprocess; endsystem; cut observer obs; state s #start ; deadline lazy; match informal "-- ABRAZO MORTAL--" ; cut; nextstate -; endstate; endobserver;

65

BIBLIOGRAFÍA

[Gar00] GARCÍA, Jorge, Especificación, verificación y mantenimiento de requisitos funcionales con técnicas de descripción formal, Universidad de Vigo, España, Dpto. de Tecnologías de las Comunicaciones, ETSI de Telecomunicación, España, 2000. Tesis Doctoral.

[Gil99] GIL, Alberto, Diseño y verificación de sistemas distribuidos mediante la aplicación

combinada de métodos formales, Universidad de Vigo, España, Dpto. de Tecnologías de las Comunicaciones, ETSI de Telecomunicación, España, 1999. Tesis Doctoral.

[SGG04] SILBERSCHATZ, Avi; Galvin Peter; Gagne Greg, Sistemas Operativos, México D. F.,

Limusa-Wiley, 2004.

REFERENCIAS ELECTRÓNICAS

[1] (2005, octubre, 30) [En Línea] Disponible: http://www.dsic.upv.es/users/elp/maria/MexicoWeb/TemaIntro.ps [2] (2005, noviembre, 03), [En Línea].Disponible: http://www-verimag.imag.fr/~async/IF/ [3] (2006, marzo, 09), [En Línea]. Disponible: http://es.wikipedia.org/wiki/Model_checking [4] (2006, marzo, 10), [En Línea]. Disponible: http://www.depi.itch.edu.mx/apacheco/teoria/bnf.htm [5] (2006, marzo, 15), [En Línea]. Disponible: http://www.coala.uniovi.es/~melendi/downloads/vvmis/Thresholds.pdf