UUNNIIVVEERRSSIIDDAADD DDEE SSEEVVIILLLLAA
ESCUELA SUPERIOR DE INGENIEROS
INGENIERÍA SUPERIOR DE TELECOMUNICACION
DDEEPPAARRTTAAMMEENNTTOO DDEE OORRGGAANNIIZZAACCIIÓÓNN IINNDDUUSSTTRRIIAALL YY GGEESSTTIIÓÓNN DDEE EEMMPPRREESSAASS
DDEESSAARRRROOLLLLOO DDEE UUNN GGEENNEERRAADDOORR DDEE MMOODDEELLOOSS LLIINNEEAALLEESS PPAARRAA LLAA
CCOOOORRDDIINNAACCIIÓÓNN SSEEMMAAFFÓÓRRIICCAA MMEEDDIIAANNTTEE MMAAXXIIMMIIZZAACCIIÓÓNN DDEE
BBAANNDDAA
FRANCISCO SOLANO VELÁZQUEZ MARTÍNEZ
Agradecimientos Agradezco la ayuda que se me ha dado por parte de mi familia, mis amigos y mi
novia durante todo el tiempo que ha durado la carrera. Gracias a todos.
2
Índice
ÍNDICE
ÍNDICE.............................................................................................................................3
LISTA DE FIGURAS......................................................................................................6
LISTA DE TABLAS........................................................................................................9
1 INTRODUCCIÓN Y OBJETIVOS DEL PROYECTO..........................................10
1.1 INTRODUCCIÓN A LOS SISTIEMAS INTELIGENTES DE TRANSPORTE
(ITS)............................................................................................................................10
1.2 INTRODUCCIÓN A LA COORDINACIÓN DE SEÑALES SEMAFÓRICAS .11
1.3 DESCRIPCIÓN DEL VIARIO..............................................................................13
1.3.1 Descripción de las cajas semafóricas..................................................................17
1.4 OBJETIVOS DEL PROYECTO .................................................................................. 21
2 MODELOS DE COORDINACIÓN SEMAFÓRICA .............................................22
2.1 INTRODUCCIÓN .................................................................................................22
2.2 DESCRIPCIÓN DEL PROBLEMA ......................................................................23
2.3 DESCRIPCIÓN DE LOS MÉTODOS ..................................................................25
2.3.1. Problema básico de maximización del ancho de banda...............................25
2.3.2. Problema extendido de maximización del ancho de banda .........................29
2.3.2.1 Cálculo de la sincronización..............................................................32
2.3.3. Método multi-banda.....................................................................................33
3 MODELADO ORIENTADO A OBJETOS .............................................................37
3.1 INTRODUCCION A UML....................................................................................37
3.1.1. Breve historia de UML ................................................................................37
3.1.2. ¿Qué es UML? ¿Por qué usar UML?...........................................................39
3.2 ESPECIFICACIÓN FUNCIONAL DEL MODELO DE COORDINACIÓN ......43
3.2.1. Diagramas de casos de uso...........................................................................43
3.2.1.1 Modelo de coordinación semafórica..................................................46
3.2.1.1.1 Diagramas de caso de uso de nivel 0 o de contexto .................46
3.2.1.1.2 Diagramas de casos de uso de nivel 1 ......................................47
3.2.1.1.3 Diagramas de casos de uso de nivel 2 ......................................47
3.2.2. Diagramas de paquetes.................................................................................50
3.2.2.1 Diagramas de paquetes del algoritmo de coordinación .....................51
3.2.3. Diagrama de clases.......................................................................................52
3
Índice
3.2.3.1 Paquete de datos “Grupo semafórico”...............................................55
3.2.3.1.1 Descripción de las clases del paquete “Grupo semafórico” .....55
3.2.3.1.1.1 Clase “Estructura” .......................................................55
3.2.3.1.1.2 Clase “Código _ estructura” ........................................58
3.2.3.1.1.3 Clase “Código_señal”..................................................59
3.2.3.1.1.4 Clase “Fase” ................................................................60
3.2.3.1.1.5 Clase “Código _ fase” .................................................61
3.2.3.1.1.6 Clase “Intermedio” ......................................................62
3.2.3.1.1.7 Clase “Código _ intermedio”.......................................63
3.2.3.1.1.8 Clase “Señal _ semafórica” .........................................63
3.2.3.1.2 Diagrama de clases del paquete “Grupo Semafórico”.............66
3.2.3.2 Paquete de datos “Algoritmo coordinación” .....................................67
3.2.3.2.1 Descripción de las clases del paquete “Algoritmo
coordinación” ....................................................................................67
3.2.3.2.1.1 Clase “Signal” .............................................................67
3.2.3.2.1.2 Clase “Datos_modelo” ................................................68
3.2.3.2.1.3 Clase “Coordina_signal” .............................................70
3.2.3.2.2 Diagrama de clases del paquete “Algoritmo coordinación”.....72
3.2.3.3 Paquete de datos “Interfaz gráfica” ...................................................72
3.2.3.3.1 Descripción de las clases del paquete “Interfaz gráfica”..........72
3.2.3.3.1.1 Clase “Señal _ elegida” ...............................................72
3.2.3.3.1.2 Clase “Coordinación_interactiva” ...............................73
3.2.3.3.2 Diagrama de clases del paquete “Grupo semafórico” ..............76
3.2.3.4 Paquete de datos “Lista”....................................................................76
3.2.3.4.1 Descripción de las clases del paquete “Lista” ..........................77
3.2.3.4.1.1 Clase “Lista_inf” .........................................................77
3.2.3.4.2 Diagrama de clases del paquete “Lista” ...................................80
3.2.3.5 Paquete de datos “VCL”....................................................................80
3.2.3.6 Paquete de datos “Viario” .................................................................81
3.2.3.6.1 Descripción de las clases del paquete “Viario” ........................81
3.2.3.6.1.1 Clase “Contexto” .........................................................81
3.2.3.6.1.2 Clase “Mapa”...............................................................82
3.2.3.6.1.3 Clase “Punto” ..............................................................84
3.2.3.6.1.4 Clase “Datos _ cruce”..................................................85
4
Índice
3.2.3.6.1.5 Diagrama de clases del paquete “Viario”....................86
4 IMPLEMENTACIÓN DEL MODELO E INTERFAZ GRÁFICA.......................86
4.1 INTRODUCCIÓN .................................................................................................86
4.2 IMPLEMENTACIÓN DEL MODELO.................................................................88
4.3 INTERFAZ GRÁFICA........................................................................................104
5 PRUEBAS DEL SISTEMA .....................................................................................109
5.1 PRUEBA DE FUNCIONAMIENTO DE LA XA ...............................................109
5.1.1. Solución aportada por la XA......................................................................114
5.1.2. Solución aportada por el Solver de EXCEL ..............................................116
5.1.2.1 Funcionamiento básico del Solver...................................................117
5.1.2.2 Solución obtenida mediante el Solver .............................................121
5.2 PRUEBA DE LA APLICACIÓN SOBRE UN ESCENARIO REAL.................123
5.2.1. Prueba realizada en la avenida Carlos V....................................................125
5.2.2. Prueba realizada en la avenida Alfonso XII...............................................128
6 CONCLUSIONES Y EXTENSIONES ...................................................................133
6.1 CONCLUSIONES ...............................................................................................133
6.2 POSIBLES EXTENSIONES ...............................................................................135
7 BILIOGRAFÍA .........................................................................................................136
5
Lista de figuras
LISTA DE FIGURAS
Figura 1.3-1. Representación del viario. .........................................................................13
Figura 1.3-2. Tramos y Nodos.........................................................................................15
Figura 1.3-3. Representación de giros. ............................................................................16
Figura 1.3-4. Posibles estados de la señal semafórica.....................................................18
Figura 1.3-5. Ejemplo de caja semafórica .......................................................................19
Figura 1.3-6. Estructura de una caja semafórica .............................................................20
Figura 2.2-1. Diagrama espacio-tiempo mostrando las bandas verdes en ambas
direcciones .......................................................................................................................24
Figura 2.3-1. Geometría de las bandas verdes. Notar que ( ) ( )i,hi,h Φ+Φ debe equivaler
a un entero. ......................................................................................................................26
Figura 2.3-2. Relaciones geométricas para la formulación multi-banda.........................33
Figura 3.2-1. Notación de actores....................................................................................45
Figura 3.2-2. Notación de casos de uso. ..........................................................................45
Figura 3.2-3. Notación de relaciones...............................................................................45
Figura 3.2-4. Casos de uso de nivel 0..............................................................................46
Figura 3.2-5. Casos de uso de nivel 1..............................................................................47
Figura 3.2-6. Diagramas de casos de uso de nivel 2. Obtención de los datos .................48
Figura 3.2-7. Diagramas de casos de uso de nivel 2. Obtención de la solución..............49
Figura 3.2-8. Diagramas de paquetes del algoritmo de coordinación .............................51
Figura 3.2-9. Ejemplo de clase ........................................................................................55
Figura 3.2-10. Estructura, fases y ciclo ...........................................................................56
Figura 3.2-11. Clase “Estructura” ...................................................................................56
Figura 3.2.-12. Clase “Codigo_estructura” .....................................................................59
Figura 3.2-13. Clase “Codigo_senal” ..............................................................................59
Figura 3.2-14. Clase “Fase”.............................................................................................60
Figura 3.2-15. Clase “Codigo_fase”................................................................................61
Figura 3.2-16. Clase “Intermedio” ..................................................................................62
Figura 3.2-17. Clase “Codigo_intermedio”.....................................................................63
Figura 3.2-18. Clase “Senal_semaforica”........................................................................64
Figura 3.2-19. Diagrama de clases “Grupo semafórico”.................................................66
Figura 3.2-20. Clase “Signal”..........................................................................................67
Figura 3.2-21. Clase “Datos_modelo”.............................................................................68
6
Lista de figuras
Figura 3.2-22. Clase “Coordina_signal”..........................................................................70
Figura 3.2-23. Diagrama de clases “Grupo semafórico”.................................................72
Figura 3.2-24. Clase “Senal_elegida” .............................................................................73
Figura 3.2-25. Clase “Coordinacion_interactiva” ...........................................................74
Figura 3.2-26. Diagrama de clases “Coordinacion_interactiva” .....................................76
Figura 3.2-27. Clase “Lista_inf” .....................................................................................77
Figura 3.2-38. Diagrama de clases del paquete Lista ......................................................80
Figura 3.2-29. Diagrama de clases del paquete VCL......................................................80
Figura 3.2-30. Clase “Contexto” .....................................................................................81
Figura 3.2-31. Clase “Mapa”...........................................................................................82
Figura 3.2-32. Clase “Punto”...........................................................................................84
Figura 3.2-33. Clase “Datos_cruce” ................................................................................85
Figura 3.2-34. Diagrama de clases del paquete Viario....................................................86
Figura 4.2-1 Estructura general del programa .................................................................89
Figura 4.2-2 Extracción de una señal determinada de una caja semafórica ....................91
Figura 4.2-3 Ejemplo del formato de un archivo de entrada a la xa ..............................93
Figura 4.2-4 Método que crea el archivo que contiene el problema lineal de
coordinación ....................................................................................................................97
Figura 4.2-5 Primera parte del archivo de salida de la xa ...............................................98
Figura 4.2-6 Método que resuelve el problema lineal de coordinación ..........................99
Figura 4.2-7 Segunda parte del archivo de salida de la xa ............................................100
Figura 4.2-8 Método que procesa el archivo de salida de la xa.....................................103
Figura 4.3-1 Muestra la selección de nuestra aplicación...............................................104
Figura 4.3-2 Pantalla de selección de los nodos cuyas señales vamos a coordinar.......105
Figura 4.3-3 Aplicación que permite importar una caja a un nodo ...............................106
Figura 4.3-4 Representación gráfica de una caja semafórica asociada a un nodo.........107
Figura 4.3-5 Interfaz para la introducción de datos y presentación de resultados.........108
Figura 4.3-6 Presentación de los resultados de desfase entre las señales......................109
Figura 5.1-1 Escenario de la prueba de validez.............................................................111
Figura 5.1-2 Representación gráfica de las señales a coordinar....................................112
Figura 5.1-3 Programa lineal de maximización del ancho de banda.............................112
Figura 5.1-4 Avenida que vamos a coordinar ...............................................................115
Figura 5.1-5 Representación gráfica de la coordinación ...............................................116
Figura 5.1-6 Representación del problema en la hoja de cálculo de EXCEL ...............119
7
Lista de figuras
Figura 5.1-7 Configuración de los parámetros del Solver.............................................119
Figura 5.1-8 Agregar restricción a los parámetros del Solver.......................................120
Figura 5.1-9 Condición de no negatividad ....................................................................120
Figura 5.1-10 Resultado de la configuración de los parámetros del Solver .................121
Figura 5.1-11 Hoja de cálculo con el problema lineal de coordinación ........................122
Figura 5.2-1 Plano de las avenidas a coordinar .............................................................123
Figura 5.2-2 Señales que rigen la avenida Carlos V......................................................124
Figura 5.2-3 Modelo lineal de coordinación de la avenida Carlos V............................126
Figura 5.2-4 Resultado gráfico de la coordinación de la avenida Carlos V en la dirección
outbound ........................................................................................................................127
Figura 5.2-5 Señales que rigen la avenida Alfonso XII ................................................128
Figura 5.2-6 Modelo lineal de coordinación de la avenida Alfonso XII.......................130
Figura 5.2-7 Resultado gráfico de la coordinación de la avenida Alfonso XII en la
dirección outbound ........................................................................................................132
8
Lista de tablas
LISTA DE TABLAS Tabla 5.1-1 Datos de distancia, velocidades y cambios en la velocidad .......................111
Tabla 5.1-2 Valor de las variables en el óptimo............................................................113
Tabla 5.1-3 Valor de los datos de interés ......................................................................114
Tabla 5.2-1 Límites de velocidad, cambios de velocidad y distancia ...........................123
Tabla 5.2-2 Solución del problema lineal de coordinación de la avenida Carlos V......124
Tabla 5.2-3 Datos de interés para la coordinación ........................................................125
Tabla 5.2-4 Límites de velocidad y distancia ................................................................127
Tabla 5.2-5 Solución del problema lineal de coordinación de la avenida Alfonso XII 129
Tabla 5.2-6 Datos de interés para la coordinación de esta avenida...............................129
9
Introducción y objetivos del proyecto
1 Introducción y objetivos del proyecto.
1.1 Introducción a los sistemas inteligentes de transporte (ITS) El transporte es un motor de desarrollo económico y de bienestar general de todo
el mundo. La vida moderna exige una movilidad cada vez mayor. A menudo ésta se
consigue mediante una creciente utilización de los coches particulares. Esto implica la
multiplicación de la demanda de tráfico sobre las ya sobrecargadas infraestructuras de
transporte. A pesar de los ingentes gastos en nuevas infraestructuras viales, la
congestión del tráfico sigue aumentando. Las mejoras conseguidas anteriormente en
materia de seguridad vial y de protección del medio ambiente empiezan a perder
importancia.
Es poco probable que estos problemas puedan resolverse simplemente
construyendo más carreteras y partiendo únicamente de los enfoques del pasado. Es
evidente que se hace necesario la puesta en práctica de los sistemas inteligentes de
transporte o ITS. Los sistemas inteligentes de transporte (ITS) abarcan un gran abanico
de nuevas herramientas para la gestión de redes de transporte que prometen nuevas vías
para conseguir una movilidad duradera en nuestra sociedad de la comunicación y de la
información.
Los ITS son sistemas de transporte que aplican las tecnologías de la
información, de la comunicación y la normativa para ayudar a explotar las redes de
transporte. Las herramientas ITS, se basan en tres características fundamentales:
información, comunicación e integración. La adquisición, el tratamiento, la integración
y la difusión de la información en “tiempo real” sobre las condiciones de circulación
actuales de una red o información en línea para la planificación de un desplazamiento,
las herramientas ITS permiten a las autoridades, a los operadores y a los usuarios tomar
decisiones con mayor grado de información y de forma integrada.
Algunos sistemas ITS no son más que mejoras de sistemas antiguos, como en el
caso del control de tráfico, pero otros son completamente nuevos, como el guiado
dinámico en ruta. La mayoría son ideas que los profesionales del transporte llevan
desarrollando desde hace mucho tiempo, pero cuya implementación estaba lejos de la
10
Introducción y objetivos del proyecto
tecnología disponible o resultaba excesivamente costosa. Lo que ITS significa como
novedad es una visión integral que alcanza lo tecnológico, financiero y organizativo,
con la correspondiente planificación y compromiso de tos los estamentos públicos y
privados implicados. ITS es una iniciativa global en respuesta a los problemas que el
transporte tiene en nuestro mundo.
1.2 Introducción a la coordinación de señales semafóricas
Como consecuencia del creciente número de vehículos, el tráfico de las ciudades
comienza a ser un grave problema. Con el fin de evitar las grandes aglomeraciones de
vehículos formadas fundamentalmente en las intersecciones reguladas por semáforos, se
trata de coordinar la sucesión de semáforos de una avenida de tal forma, que en el
intervalo en que estos están en verde pasen el mayor número de vehículos posible.
La coordinación de señales semafóricas a lo largo de una calle proporciona un
gran número de ventajas que indicamos a continuación:
• Reducción del número de paradas y reduciendo el tiempo de
viaje mediante el aumento de la velocidad en conjunto.
• Tráfico más fluido y aumento de la capacidad de la vías.
• Velocidades más uniformes animando a los conductores más
lentos a acelerar su marcha.
• Hay menos violaciones de la luz roja reduciendo el número de
colisiones.
• Mayor obediencia de las señales por parte de los peatones.
• Reducción del tráfico de las calles paralelas de menor
capacidad.
Las primeras aplicaciones empleadas para la coordinación de arterias reguladas
por semáforos es conocido como el método de progresión (FHWA, 1985). Las señales
de tráfico tienden a agrupar los vehículos en pelotones, siendo deseable que los
pelotones presente un movimiento continuo a lo largo de las diferentes señales. Bajo
tales condiciones los diagramas espacio-tiempo, donde se representa cada señal, son
11
Introducción y objetivos del proyecto
diseñados para maximizar el tiempo en verde siempre en ambas direcciones de
circulación buscando una velocidad constante en el desplazamiento. En general este tipo
de método funciona mejor para aquellas calles o avenidas principales donde las
incorporaciones de vehículos en mitad del recorrido son insignificantes.. Bajo tal
método, una banda verde continua y uniforme es provista en cada dirección de la arteria
a la velocidad deseada de viaje, con el fin de proporcionar un movimiento continuo de
los pelotones de vehículos.
En los últimos años con el gran auge de los sistemas de información y las
comunicaciones se ha sustituido el diseño manual de diagramas de espacio-tiempo por
modelos computerizados. Existe una gran cantidad de estos modelos, entre los que
podemos nombrar están: SIGART (Metropolitan Toronto, 1965), SIGPROG (Bleyl,
1967), modelos de IBM (Brooks; Yardeni, 1964), NO-STOP-1 (Leuthardt, 1975),
PASSER-II (Messer et al., 1973), y Maximización del Ancho de banda (Morgan and
Little, 1964; Little, 1966).
Uno de los más avanzados y versátiles es el modelo de Máximo de Banda
(MAXBAND), cuya última versión fue desarrollada por Little, Kelson y Gartner en
1981. Este método permite calcular mediante un modelo de programación lineal, una
solución global óptima que maximiza el ancho de banda ambas direcciones de
circulación de la arteria. Sin embargo, la principal limitación de los programas basados
en el ancho de banda es que en el criterio de optimización (Función Objetivo) no
consideran los volúmenes y los flujos de tráfico actual en cada sección.
Consecuentemente, no es posible garantizar el modelo de progresión más adecuado para
los diferentes patrones de tráfico. Es por esto, por lo que se generó una nueva
aproximación a la optimización de la progresión a lo largo de una arteria que incorpora
un criterio sistemático dependiente del tráfico. El método genera una progresión
variable del ancho de banda, de forma que en que cada sección de carretera se obtiene
un ancho de banda individual (de aquí surge el término multi-banda). Para la
optimización se usa la programación lineal. Los resultados de las simulaciones indican
que este método produce ventajas considerables con respecto a los métodos de
progresión tradicionales.
12
Introducción y objetivos del proyecto
El siguiente trabajo se basa en la aplicación del método de máximo de banda a la
coordinación semafórica de un área de Sevilla, dejando para futuras ampliaciones a este
trabajo el desarrollo del modelo multi-banda.
1.3 Descripción del viario
La descripción del viario consiste en la definición de los elementos que lo
componen, de forma que posteriormente se puedan diseñar las estructuras de datos
apropiadas para contener toda la información necesaria para el desarrollo del modelo.
La mayoría de los modelos definen el viario como un grafo, ( )AVG , (dirigido o no
dirigido) donde las calles están representadas mediante los arcos del grafo y las
intersecciones o cruces están representados mediante nodos del grafo.
Figura 1.3-1. Representación del viario.
13
Introducción y objetivos del proyecto
Esta descripción, si bien es correcta y en general suficiente, no comprende a la
totalidad de los componentes de un viario, ya que este no sólo está formado por calles y
cruces, sino que existe otra serie de elementos como los contadores de vehículos, giros
definidos, cajas semafóricas... etc.
Este apartado pretende recoger los elementos más importantes que componen el
viario y los específicos para este trabajo.
• Nodos
El viario está representado por un grafo ( )AVG , que contiene un conjunto
de vértices y arcos. Los vértices también llamados nodos, representan las
intersecciones del viario. Los atributos contenidos en nodos son:
o Código del nodo. Cada nodo está identificado en la red por un código
único que lo diferencia del resto de nodos.
o Tipo de nodo. Se han considerado dos tipos de nodos:
Normales. Son nodos que representan las intersecciones o cruces
existentes en el viario.
Centroides. Nodos especiales definidos en el viario que no se
corresponden con intersecciones de calle. Son puntos desde donde
parte y llega la demanda de viajes de una determinada zona.
o Posición. Para representar gráficamente el viario es necesario dotar a
los nodos del atributo posición, que contendrá a las coordenadas del
nodo.
• Tramos.
Los tramos representan a las calles del viario. Los atributos que
caracterizan a los tramos son:
o Código del tramo. Identificación de cada calle del viario. Los tramos
suelen ser unidireccionales, es decir, representan un solo sentido de
circulación. Para representar una calle con dos sentidos serán necesarios
dos tramos.
o Nodo origen. Todos los tramos parten de un nodo, al que denominamos
nodo origen.
14
Introducción y objetivos del proyecto
o Nodo destino. Los tramos finalizan en una intersección representada por
el nodo destino.
o Número de carriles. Espacios disponibles para el desplazamiento de
vehículos.
o Modos de transporte. Cada tramo permite la circulación de unos tipos
de vehículos (peatonal, vehículos... etc.).
o Función volumen retraso. A cada tramo se le asocia una función que
devuelva el tiempo que emplea un vehículo en recorrer el tramo en
función de la intensidad de la circulación.
o Longitud. La longitud del tramo.
Nodo
Tramo
Figura 1.3-2. Tramos y Nodos.
15
Introducción y objetivos del proyecto
• Giros
Las intersecciones son puntos de unión de los tramos y son empleadas por
los vehículos como medio de selección del tramo que conduce a su destino
final. Las intersecciones representan el punto de unión entre tramos, pero no
todos los tramos que llegan a una intersección están comunicados a través de
ella. Las posibilidades de acceso de unos tramos a otro en una intersección
están indicadas por los giros que se definen en el nodo. Un giro habilita la
posibilidad de circulación de vehículos entre dos tramos que llegan y parten de
un nodo.
En un giro se definen los siguientes atributos:
o Número de giro. Número secuencial creciente que identifica al giro.
o Código del nodo. Nodo que identifica al movimiento.
o Tramo origen. Tramo de donde proceden los vehículos.
o Tramo destino. Tramo a donde se dirigen los vehículos.
o Función volumen retraso. A veces se incluye una función volumen
retraso para obtener el tiempo empleado en realizar el giro.
Figura 1.3-3. Representación de giros.
• Detectores
Los detectores son elementos situados en los carriles de los tramos del
viario que proporcionan datos sobre la intensidad del tráfico en dichos tramos.
Los atributos que contiene son:
o Código del detector. Código que identifica unívocamente al detector.
o Código del tramo. Código del tramo en el que está el detector.
16
Introducción y objetivos del proyecto
o Tipo de detector. Los detectores pueden ser de varios tipos, desde
cámaras de televisión hasta los contadores por espiras.
o Flujo de vehículos. Número de vehículos que han pasado por el detector
en un intervalo de tiempo.
o Posición del detector. Posición del detector relativa al comienzo del
tramo.
o Estado del detector. Especifica si el detector está en funcionamiento,
averiado o pasivo.
1.3.1 Descripción de las cajas semafóricas
Asociado a un nodo del viario, se puede encontrar una caja semafórica que
contiene las señales que determinan el funcionamiento de los distintos dispositivos
reguladores de tráfico (semáforos) del nodo en cuestión.
Los semáforos son dispositivos físicos que restringen o conceden derecho de
paso a un conjunto de vehículos y funcionan de acuerdo a una señal que regula el
comportamiento (estado) del mismo.
Una señal describe el comportamiento de uno o varios semáforos a lo largo del
tiempo. El comportamiento de la señal es cíclico, es decir, se repite en cada cierto
intervalo de tiempo (ciclo). Las señales se agrupan para formar las cajas de señales o
estructuras que contienen todas las señales definidas que regulan el comportamiento de
los dispositivos en el nodo. Un nodo puede contener varias estructuras dependiendo del
efecto que se desea producir en la regulación del tráfico.
Todas las señales de una estructura se dividen en etapas o fases que muestran el
estado de la señal en un intervalo de tiempo. Asimismo, cada una de las fases suele
subdividirse en pequeños intervalos de tiempo que se denominan tiempos intermedios.
Los tiempos intermedios son tiempos fijos que garantizan la no ocurrencia simultánea
de cambios de rojo a verde para grupos diferentes. Su misión es principalmente la de
establecer breves intervalos de tiempo de seguridad, con el objetivo de evitar conflictos
entre los primeros vehículos que atraviesan la línea de detención asociada a la señal para
un grupo que acaba de recibir derecho de paso y los últimos vehículos correspondientes
17
Introducción y objetivos del proyecto
a los que se les ha suprimido este derecho. Con frecuencia, los tiempos intermedios
contienen el tiempo en ámbar asignado a los diferentes grupos. Cada etapa queda
entonces definida por un conjunto de tiempos intermedios, de longitud fija y en igual
número para todos los grupos, y un tiempo de longitud variable asignado a la fase.
El estado de la señal viene determinado por el color que puede tomar la fase o
bien el tiempo de intermedio. Los posibles estados de la señal son:
Figura 1.3-4. Posibles estados de la señal semafórica
A modo de ejemplo, a continuación se muestra una estructura formada por ocho
señales. Cada una de dichas señales se encuentra dividida en tres fases, las dos primeras
de ellas disponen de cuatro tiempos intermedios, mientras que la última fase tiene cinco
tiempos intermedios, tanto los de una fase como los de otra se encuentran ubicados al
final de las mismas.
18
Introducción y objetivos del proyecto
Figura 1.3-5. Ejemplo de Caja Semafórica
Los datos que permiten la representación de la caja como la del ejemplo de la
figura 1.3-5, se almacenan en archivos cuya estructura se explica a continuación:
19
Introducción y objetivos del proyecto
Figura 1.3-6. Estructura de una caja semafórica
En primer lugar, se indica el nombre de la calle en la que se encuentra ubicado el
nodo al que esta asociado la caja, después se indica el número del nodo que lo identifica
dentro del viario, a continuación se puede ver el número de estructuras que contiene la
caja. El siguiente dato es el ciclo de las señales de la estructura y si los tiempos que en
la caja aparecen vienen expresados en porcentaje de tiempo de ciclo,”P” o en tiempo
(segundos) “T”. Además, se dice si los intermedios de los que puede constar una fase de
la señal se encuentran al final de la fase, “P” o al principio de la misma, “T”. En la
siguiente línea se indica la estructura a la que pertenece los datos de tiempo de ciclo, de
número de fases, tiempos de fases e intermedios y colores de los mismos, y a
continuación, se expresa el número de fases de las que se compone las señales de dicha
estructura. La sucesión de datos que aparecen ahora expresan el tiempo de las fases y
de los intermedios y que según si éstos van delante o detrás, el primer o último valor
corresponde con el de la fase y el resto con los de los intermedios. Debajo de estos datos
20
Introducción y objetivos del proyecto
se indica el número de señales presentes en la caja y continuación el código de colores
de las fases y los intermedios que conforman cada señal.
Estos datos no sólo sirven para la representación gráfica de las señales como se
ha explicado más arriba, si no que también van a servir para la construcción del modelo
lineal de maximización de ancho de banda en verde.
1.4 Objetivos del proyecto
El objetivo del siguiente trabajo es el desarrollo de un entorno donde se provea a
los ingenieros de tráfico de las herramientas para la obtención de una buena
coordinación de las señales luminosas de tráfico, es decir, maximizar el número de
vehículos que atraviesan, sin realizar ninguna parada, una avenida regulada por
semáforos.
La coordinación semafórica se obtendrá mediante la aplicación y resolución de
un modelo de programación lineal que tiene en cuenta el flujo de tráfico en ambas
direcciones, así mismo mediante un factor modificador (k), es posible dar mayor
prioridad a los vehículos de una dirección de la avenida con respecto a los de la otra.
También es importante considerar las velocidades de los vehículos en cada tramo de la
avenida y la brusquedad del cambio de las mismas de un tramo a otro.
Como parte de los objetivos, se tratará de integrar las librerías comerciales de
optimización lineal XA, a las que se le llamarán para la resolución del problema lineal y
para la obtención de los resultados.
Finalmente el sistema desarrollado será integrado en una aplicación más general,
TRAMOS (Traffic and Transport Análisis, Modeling and Optimization System), que
comprende diversas herramientas para la gestión del tráfico y la planificación del
transporte en núcleos urbanos. Dicha integración se realizará mediante una interfaz
gráfica basada en las ventanas, de forma que el usuario pueda resolver el problema de la
coordinación, sin necesidad de tener conocimientos algunos acerca de la programación
lineal, es decir, esto es transparente para el usuario.
21
Modelos de coordinación semafórica
2 Modelos de coordinación semafórica.
2.1 Introducción
El método más extendido para la coordinación de una arteria, tanto en Estados
Unidos como en otros países, es el método de progresión. Las señales de tráfico
tienden a formar pelotones de vehículos de forma progresiva. El efecto de formación de
pelotones se acentúa en las avenidas donde la presencia de señales semafóricas en las
intersecciones es más frecuente. En estas circunstancias, parece deseable conseguir un
movimiento continuo y constante de los pelotones de vehículos a través de las señales
de tráfico. Para conseguirlo, se diseñan los tiempos de las señales de forma que se
maximice el ancho de la banda continua de verde en las dos direcciones de la avenida
con velocidades de viaje programadas. En general, estos sistemas de diseño de tiempos
funcionan mejor cuando los flujos de vehículos predominantes son los directos y el
número de vehículos procedentes de las calles anexas a la avenida es pequeño.
En los últimos años el gran auge y crecimiento de los sistemas informáticos ha
permitido el diseño de diagramas espacio tiempo mediante modelos computerizados. Se
desarrollaron una larga variedad de modelos tales como SIGART (Metropolitan
Toronto, 1965), SIGPROG (Bleyl, 1967), los modelos de IBM (Yardani, 1964), NO-
STOP-1 (Leuthardt, 1975), PASSER-II (Messer, 1973), y Bandwidth Maximization
(Morgan y Little, 1964; Little, 1966). Los avances en las técnicas de optimización y la
capacidad computacional han permitido que los modelos sean cada vez más
sofisticados. El modelo más avanzado y versátil de todos es el modelo de ancho de
banda (MAXBAND) descrito por Little, Kelson y Gartner en 1981. Este modelo usa
toda la fuerza de los modelos de optimización permitiendo determinar una solución
óptima global así como el ciclo, los desfases, las velocidades de progresión y los
cambios de fase de manera que se maximice el ancho de banda en verde(tiempo mínimo
que permita a un conductor que parte del comienzo de la calle atravesarla en el menor
tiempo posible) para ambas direcciones de la avenida.
En los últimos años, la Administración Federal de Carreteras de los Estados
Unidos (FWHA), ha estado promoviendo la optimización de las señales de tráfico en las
áreas urbanas, como consecuencia se desarrolló un método de optimización basado en el
22
Modelos de coordinación semafórica
retraso, TRANSYT-7F (Wallace, 1981). El objetivo es obtener unos flujos de tráfico
para la avenida más refinados que los permitidos por el TRANSYT. Otros métodos
fueron propuestos por Wallace y Courage como combinación de los métodos basados
en la minimización de los retrasos y los basados en la maximización del ancho de
banda, donde se aprovechaban las ventajas de uno y otro método. Los métodos que
nosotros desarrollaremos a continuación combinan las ventajas de unos y otros.
2.2 Descripción del problema
Una de las limitaciones básicas que existen en los programas basados en el
ancho de banda es que los criterios de diseño no dependen de los flujos de tráfico
actuales en los cruces de la avenida y por lo tanto, son muy sensibles a las variaciones
en dichos flujos. El ancho de banda obtenido se puede distribuir según se desee en
distintas proporciones en cada una de las direcciones de la avenida, esto se puede
realizar variando el valor de la razón de volumen direccional, k. La elección de este
parámetro de un modo u otro no asegura la mejor progresión de los flujos de tráfico.
Se define ahora el problema de coordinación: se considera una avenida con dos
direcciones que está regulada por n señales de tráfico. Las direcciones se identificarán
como inbound (“de entrada”) y outbound (“de salida”). Las señales se denotarán por
donde el subíndice crece en la dirección outbound. La siguiente figura
muestra un diagrama espacio-tiempo del viaje a lo largo de una avenida.
n21 S,,S,S K
23
Modelos de coordinación semafórica
( 1 )
( 2 )
Figura 2.2-1. Diagrama espacio-tiempo mostrando las bandas verdes en ambas
direcciones.
Las líneas rojas indican cuando están las señales en rojo. Las líneas en zigzag (1)
y (2) indican las trayectorias de los vehículos en su paso sin interrupciones por la
avenida en la dirección señalada. Los cambios de pendiente corresponden con cambios
en la velocidad. La posible definición de trayectorias sin interrupciones en una
dirección determinada forma la banda verde, cuyo grosor determina el ancho de banda
para esa dirección. Aunque sólo se haya dibujado una vez, la banda verde ocurre una
vez por ciclo, formando una sucesión de bandas paralelas a lo largo del diagrama.
Ciertas señales forman la última limitación del ancho de banda, a estas señales
se les denomina señales críticas. A una señal cualquiera se le denomina crítica si un
lado de uno de sus rojos toca la banda verde en una dirección y otro lado toca la banda
verde en la otra dirección. Un ejemplo de señales críticas lo encontramos en las señales
y de la figura 2.2-1.
jS
iS hS
24
Modelos de coordinación semafórica
Para desarrollar el método multi-banda, es necesario describir el problema
básico de maximización del ancho de banda y después se amplia añadiendo variables
de decisión. De todos los modelos de programación lineal entera-mixta existente en la
literatura, solo se describen tres modelos donde partiendo de un modelo inicial la
complejidad irá creciendo progresivamente. El primero, MILP-1 (Mixed Integer
Linear Programming), es el básico, simétrico y de ancho uniforme; el segundo, MILP-
2, a diferencia del primero incluye anchos de banda asimétricos en direcciones
opuestas, especificación de la velocidad entre los distintos cruces de la avenida y
determinación de la longitud del ciclo. El tercero, MILP-3, presenta el nuevo método
multi-banda, el cual nos permite incorporar previamente todas las variables de
decisión.
2.3 Descripción de los métodos
2.3.1 Problema básico de maximización del ancho de banda
El siguiente método sería el procedimiento más directo si no fuera por las
restricciones enteras, sin embargo, dichas restricciones son necesarias puesto que las
bandas verdes para ambas direcciones han de guardar una relación especial para cada
señal. Obviamente, cada banda verde transcurre a través de un tiempo en verde de una
señal determinada y, entre los tiempos en verde ocurren un número entero de ciclos, por
lo que una restricción entera es creada por cada señal. En este trabajo se desarrollan las
restricciones de forma general y luego se especializan para una avenida concreta.
25
Modelos de coordinación semafórica
Figura 2.3-1. Geometría de las bandas verdes. Notar que ( ) ( )i,hi,h Φ+Φ debe equivaler
a un entero.
Sean y dos señales tales que sigue a en la dirección outbound.
Referido a la figura 2.3-1 tenemos:
hS iS iS hS
= tiempo en rojo de la señal en la calle bajo estudio, se expresa en
tiempo de ciclo.
ir iS
( )bb = ancho de banda en la dirección outbound (inbound) en tiempo de
ciclo.
( ) ( )[ i,hti,ht ] = tiempo de viaje de a en la dirección outbound (tiempo de viaje
de a en la dirección inbound) en tiempo de ciclo.
hS iS
iS hS
( ) ( )[ i,hi,h ΦΦ ] = tiempo desde el centro de un rojo de al centro de un rojo particular
de . Los rojos se elegirán de tal forma que sean los que están
inmediatamente a la izquierda (derecha) de la misma banda verde en
la dirección outbound (inbound).
hS
iS
( ii ww ) = tiempo desde el borde derecho (izquierdo) del rojo hasta la banda
verde en la dirección outbound (inbound) en tiempo de ciclo.
( ) ( ) ( )i,hi,hi,hm Φ+Φ= (1)
26
Modelos de coordinación semafórica
Todas las cantidades que tienen dimensiones de tiempo se pueden expresar en
tiempo de ciclo con tan sólo dividir su valor por el periodo de la señal.
De la figura 2.3-1 podemos identificar las siguientes identidades:
( ) ( )i,hr21wi,htwr2
1iihh Φ=−−++ (2a)
( ) ( )i,hr21wi,htwr2
1iihh Φ=−−++ (2b)
El valor de ( i,h )Φ y ( i,hΦ ) forman una restricción importante en la que la su
suma debe ser igual a un entero, puesto que de otro modo no seria restricción.
( ) ( ) ( ) ( ) ( ) ( )ihiihh rri,hmi,hti,htwwww −−=+++−+ , (3)
( ) =i,hm entero.
Hasta ahora se ha requerido que siguiera a en la dirección outbound, pero
esta restricción puede ser eliminada si se define apropiadamente el parámetro t (h,
i). Por razones físicas mantendremos la relación:
iS hS
( ) ( ) ( );j,iti,htj,ht += (4a)
de donde, igualando h = j, obtenemos
( ) ( i,hth,it −= ) (5a)
y un argumento parecido se aplica para ( )i,ht . Por consiguiente, ( ) ( )[ ]l,ktl,kt es
la magnitud contraria del tiempo de viaje de a en la dirección outbound. lS kS
27
Modelos de coordinación semafórica
Ahora manteniendo (2) y (3) para unas señales arbitrarias y y iS hS
( ) ( ) ( j,ii,hj,h Φ+Φ=Φ ) (4b)
( ) ( ) ( j,imi,hmj,hm += ) , (4c)
( ) ( )i,hh,i Φ−=Φ , (5b)
( ) ( )i,hmh,im −= , (5c)
manteniendo las correspondientes expresiones para Φ .
De la figura 3.3-1 también podemos deducir que:
ii r1bw −≤+ , (6a)
ii r1bw −≤+ . (6b)
El modelo puede ser simplificado mediante la definición:
( 1i,ixx i += ) , (7)
para
m,,,t,tx ΦΦ= .
El problema básico puede ser presentado por un programa lineal entero-mixto.
Las restricciones (6) son necesarias para cada señal y la restricción (3) para cada par de
señales adyacentes.
28
Modelos de coordinación semafórica
LP1
Encontrar b, , iw iw , para im
max b,
sujeto a:
⎭⎬⎫
−≤+
−≤+
,r1bw
,r1bw
ii
ii ( )n,...1i = ( )( )b8
a8
( )ii ww +
( ) ( ) ( )
⎭⎬⎫
=−−=+++− +++
,egerintm,rrmttww
i
1iiiii1i1i ( )1n,...,1i −= (9)
.0w,w,b ii ≥
LP1 tiene 3n – 1 restricciones y 3n variables, sin contar con las variables de
holgura y las variables artificiales. El número de variables enteras es de n-1.
2.3.2 Problema extendido de maximización del ancho de banda
El problema básico descrito en el anterior apartado es ampliado en éste por la
adicción de un número importante de variables de decisión para la mejora del control
del tráfico. La primera extensión concierne a la carga direccional de ambas bandas. En
muchos casos se desea favorecer una dirección de tráfico sobre la otra (p.e: la dirección
inbound durante el pico que se produce por la mañana y la dirección outbound durante
el pico que se produce durante la tarde). Tomaremos k = relación de proporción entre el
ancho de banda en la dirección inbound y la dirección outbound.
A continuación, se considera el periodo y la velocidad como variable. Cada una
está restringida por límites superiores e inferiores. Además, se limitarán los cambios en
la velocidad de un segmento de la calle al siguiente. Finalmente, como se ha descrito
anteriormente, los anchos de banda en ambas direcciones no serán iguales si no que uno
será una proporción fija del otro.
29
Modelos de coordinación semafórica
La solución a este problema es proporcionada mediante la resolución del modelo
de programación lineal que es generado automáticamente por el sistema para el
conjunto de señales semafóricas en una avenida determinada.
Los parámetros y variables son:
k = constante de proporcionalidad entre b y b .
T = periodo de la señal en segundos.
, = límites inferiores y superiores del periodo, p.e: 1T 2T
21 TTT ≤≤ , en segundos.
z = frecuencia de la señal en ciclos por segundos.
d (h, i) = distancia entre y en metros. hS iS
= d (i, i + 1). id
( )ii vv = velocidad entre y en la dirección outbound ( y
en la dirección inbound) en metros por segundo.
iS 1iS + 1iS +
iS
, (ie if ie , if ) = límites superiores e inferiores de velocidad en la dirección
outbound (inbound) en metros por segundo.
1/ , 1/ (1/ih ig ih , 1/ ig ) = límites superiores e inferiores en los cambios del recíproco
de la velocidad en la dirección outbound (inbound), p.e:
( ) ( ) ( )ii1ii g1v1v1h1 ≤−≤ + , en metros por segundo a
la menos uno.
Los cambios en la velocidad son restringidos mediante la imposición de límites
superiores e inferiores en la velocidad recíproca. Aunque con esto no se consigue
exactamente restringir los cambios en la velocidad, seguramente satisface la intención
básica, que no es otra que la de obtener un método de prevención para los cambios
abruptos en la velocidad. La razón por la cual se trabaja con la velocidad recíproca es
como consecuencia que aparece de forma lineal en las restricciones y por tanto, se
puede transformar en , de este modo: it
( ) ,zvdt iii = ( ) ,zvdt iii = (10)
30
Modelos de coordinación semafórica
En el modelo extendido , it it y z son variables de decisión, la cuales, una vez
conocidas permiten determinar las velocidades.
LP2
Encontrar b, b , z, , iw iw , , it it , para im
( )bbmax + ,
sujeto a:
kbb = , (11)
12 T1zT1 ≤≤ , (12)
⎭⎬⎫
−≤+
−≤+
,r1bw,r1bw
ii
ii ( )n,...,1i = ( )( )b13
a13
( ) ( )( ) ( )
( ) ( )( ) ( ) ⎪
⎪⎪
⎭
⎪⎪⎪
⎬
⎫
≤≤
≤≤=
−−=++
+−+
+
++
,zedtzfd,zedtzfd
,egerintm,rrmtt
wwww
iiiii
iiiii
i
1iiiii
1i1iii
( )1n,,1i −= K ( )( )( )b15
a1514
( ) ( ) ( )( ) ( ) ( ) ⎭
⎬⎫
≤−≤
≤−≤
++
++
,zgdttddzhd
,zgdttddzhd
iii1i1iiii
iii1i1iiii ( )2n,,1i −= K ( )( )b16
a16
0w,w,b,b ii ≥
LP2 contiene (11n – 10) restricciones y 5n variables, sin contar las variables de
holgura ni las artificiales. El número que de estas variables serán enteras es de n-1.
31
Modelos de coordinación semafórica
2.3.2.1 Cálculo de la sincronización
Las variables lineales del programa determinan la sincronización de las señales.
Definimos
)i,h(θ = fase relativa (offset) de y , medida como el tiempo del hS iS
centro de un rojo de al centro del rojo siguiente de , hS iS
expresado en tiempo de ciclo.
Una ilustración de lo que es )i,h(θ se nos da en la figura 3.3-1. Asumiremos que
se verifica la siguiente expresión 1)i,h(0 <θ≤ . A los valores de )i,1(θ , i = 2,….,n los
llamaremos sincronización de las señales.
Para simplificar expresiones explícitas de θ , definimos, para x real y arbitrario:
[ ] xmayorenteroelxint ≤= ,
[ ] [ ]xintxxman −= . (14)
De esta forma, por ejemplo, int [5.2] = 5, man [5.2] = 0.2, int [-1.3] = -2,
man [-1.3] = 0.7.
De la figura 3.3-1 podemos ver que
[ ])i,h(man)i,h( φ=θ , (15)
y, usando (2a), (4a), y (7), obtenemos
(16) ⎥⎦
⎤⎢⎣
⎡−++−=θ ∑
−
=
1i
1ki1ki1 )rr)(2/1(twwman)i,1(
Los desfases entre una señal y el resto queda definidos por la expresión anterior.
32
Modelos de coordinación semafórica
2.3.3 Método multi-banda
El método multibanda se caracteriza por definir distintos anchos de bandas para
los diferentes tramos que componen la arteria (en ambas direcciones).
Cada ancho de banda es una proporción de la función objetivo total.(Nota: La
banda es continua; sólo la anchura puede variar). De esta manera, se tiene un método
que es sensible a la variación de las condiciones del tráfico y puede adaptar el esquema
de progresión a los diferentes flujos de tráfico posibles del modelo. El usuario puede
también elegir una progresión uniforme del ancho de banda si así lo desea, pero esto
sólo es una opción de las muchas disponibles para el usuario.
Figura 2.3-2. Relaciones geométricas para la formulación multi-banda.
La figura 2.3-2, permite definir las siguientes variables:
( )ii bb = ancho de banda de la dirección outbound (inbound) entre las señales
y ; ahora hay una banda específica para cada tramo de la avenida
en ambas direcciones.
iS
1iS +
33
Modelos de coordinación semafórica
( ii ww ) = Tiempo desde el borde derecho (izquierdo) de un rojo de la señal a
la línea central de la banda verde de la dirección outbound.
iS
Las siguientes restricciones se aplican en la dirección outbound para la señal : iS
( ) iii r1b21w −≤+ (17)
( ) 0b21w ii ≥− . (18)
El par de restricciones pueden ser combinadas de la siguiente forma:
( ) ( ) ( ) iiii b21r1wb21 −−≤≤ . (19)
Debe haber una relación parecida para , ya que la banda debe ser
restringida en ambos extremos:
1iS + ib
( ) ( ) ( ) i1i1ii b21r1wb21 −−≤≤ ++ . (20)
Las correspondientes relaciones existen en la dirección inbound (marcadas con
una raya sobre las variables):
( ) ( ) ( ) iiii b21r1wb21 −−≤≤ (21)
( ) ( ) ( ) i1i1ii b21r1wb21 −−≤≤ ++ . (22)
Estas restricciones se denominarán restricciones de interferencia direccional.
Notar que redefinimos la referencia de tiempo a los puntos de la línea central de las
bandas (o, la línea progresiva), más que a los bordes, la restricción dada por la ecuación
(3) permanece invariable y lo mismo ocurre con las restricciones del tiempo de viaje y
cambios de velocidad.
La restricción de la proporción (11) se modifica también para reflejar la
situación de la multi-banda:
( ) ( ) iiiii bkk1bk1 −≥− (23)
donde, proporción entre el ancho de banda de la dirección inbound y la outbound
en la sección i (tomada de la proporción correspondiente del volumen en cada
dirección).
=ik
34
Modelos de coordinación semafórica
El cambio más importante tiene lugar en la función objetivo. Ya que para los
tramos específicos de las bandas, podemos ponderar gradualmente el peso de cada uno
para reflejar los objetivos deseados en el tráfico de cada enlace. De esta forma, la
nueva función objetivo tiene la siguiente forma:
(∑−
=
+−
=1n
1iiiii baba
1n1BMAX ) (24)
donde ( )ii aa son los pesos de cada tramo específico en las dos direcciones. Hay
multitud de opciones disponibles para determinar los coeficientes de peso. Escogemos
investigar las siguientes opciones de carga: p
i
iia ⎟⎟
⎠
⎞⎜⎜⎝
⎛ζν
= p
i
iia ⎟⎟
⎠
⎞⎜⎜⎝
⎛ζν
=
donde,
( )ii νν = volumen direccional en la sección i, outbound (inbound); del volumen
total o del total que puede ser usado.
( )ii ζζ = flujo de saturación en la sección i, outbound (inbound)
p = poder exponencial; p puede tomar los valores p= 0,1,2,4.
Para obtener un valor de la función objetivo de acuerdo con las usadas
previamente, normalizamos el peso de los coeficiente para obtener
∑−
=−=
1n
1ii 1na ; ∑
−
=−=
1n
1ii 1na
El programa de optimización de la multi banda está resumido en MILP-3.
35
Modelos de coordinación semafórica
MILP - 3. Encontrar iiiiiiiii m,,,t,t,w,w,z,b,b δδ en
(∑−
=+
−=
1n
1iiiii baba
1n1BMAX ) (25)
Sujeto a
( ) ( ) iiiii bkk1bk1 −≥− (26)
12 C1zC1 ≤≤ (27)
( ) ( ) ( )( ) ( ) ( )( ) ( ) ( )( ) ( ) ( ) ⎪
⎪⎭
⎪⎪⎬
⎫
−−≤≤
−−≤≤
−−≤≤−−≤≤
++
++
i1i1ii
iiii
i1i1ii
iiii
b21r1wb21b21r1wb21
b21r1wb21b21r1wb21
1n,,1i −= K (28)
( ) ( ) ( ) i1i1i1i1iiiiiii1i1iii mllllttwwww −δ+δ−δ−δ++++−+ ++++++ (29)
( ) ( iii1i rr τ+τ )+−= + , 1n,,1i −= K
( ) ( )( ) ( ) ⎭
⎬⎫
≤≤
≤≤
zedtfd
zedtfd
iiiii
iiiii 1n,,1i −= K (30)
( ) ( ) ( )( ) ( ) ( ) ⎭
⎬⎫
≤−≤
≤−≤
++
++
zgdttddhd
zgdttddhd
iii1i1iiii
iii1i1iiii 2n,,1i −= K (31)
0t,t,w,w,z,b,b iiiiii ≥
im entero
ii , δδ cero/una variables
MILP-3 contiene (18n – 20) restricciones y (6n-3) variables continuas, hasta 2n
cero/una variables y n-1 variables enteras no restringidas, sin contar las variables de
holgura. De estas variables n-1 serán enteras.
Además, las restricciones del borde izquierdo en iδ y iδ deben añadirse hasta
un total de 2n. Las divisiones verdes y rojas están determinadas de la misma forma que
en MILP-2.
36
Modelado orientado a objetos
3 Modelado orientado a objetos 3.1 Introducción a UML
En este apartado se va a hacer una revisión de cómo surge, qué es y por qué se
utiliza el Lenguaje de Modelado Unificado (UML). Este lenguaje es una especificación
de notación orientada a objetos y se emplea para modelar el sistema y representar las
distintas relaciones entre los componentes del mismo.
3.1.1 Breve historia de UML
Los lenguajes de modelados orientados a objetos aparecieron a mediados de los
70 y finales de los 80, influidos por técnicas como los modelos de Entidad/Relación y el
Specifications & Description Language (SDL, circa 1976, CCITT), como diversas
metodologías que se aproximaban al análisis y diseño orientado a objetos.
El número de lenguajes de modelado sufrió un espectacular incremento entre los
años 1989 y 1994, llegando a identificarse hasta 50 lenguajes diferentes con los
problemas que esto conllevaba para los usuarios. A mediados de los 90 aparecieron
nuevas interacciones entre los diferentes métodos, destacando el Booch’93, la evolución
del OMT (Object Modeling Techniques) y Fusion. Los métodos empezaron a incluir
técnicas unos de los otros, predominando un pequeño grupo de ellos, incluyendo el
OOSE (Object Oriented Software Engineering), OMT-2 y el Booch’93. Cada uno de
ellos era un método completo con sus puntos fuertes y flaquezas.
Simplificando, OOSE era un lenguaje que se orientaba hacia los casos de uso,
dando un excelente soporte para los análisis de requerimientos en la ingeniería. OMT-2
era especialmente adecuado para el análisis de sistemas de información y bases de
datos. Finalmente Booch’93 destacaba por su utilidad en las fases de diseño y
construcción de proyectos, llegando a ser muy popular para el desarrollo de proyectos
de ingeniería.
Con este panorama, en Octubre del 94, comenzó el desarrollo del UML cuando
Grady Booch y Jim Rumbaugh, del grupo Rational Software Corporation, comenzaron
un trabajo conjunto para unificar los métodos Booch y OMT. Se daba el caso de que los
37
Modelado orientado a objetos
métodos Booch y OMT estaban conocidos en todo el mundo como los líderes entre los
métodos de modelado orientados a objetos, por lo que Booch y Rambaugh unieron sus
esfuerzos para unificar sus trabajos. Un primer boceto (versión 0.8) del Unified Method,
como fue llamado entonces, se dio a conocer en Octubre del 95. A finales de 1995, Ivar
Jacobson y su compañía de unieron a Rational y a su esfuerzo por unificar el lenguaje,
aportando lo ya desarrollado en el OOSE.
Los autores de los métodos Booch, OMT y OOSE (Grady Booch, Jim
Rumbaugh e Ivar Jacobson), estaban por lo tanto decididos a crear un lenguaje
unificado de modelado por tres razones:
• En primer lugar, los métodos se estaban desarrollando unos
independientemente de los otros. Era de sentido común continuar la
evolución conjuntamente mejor que por separado, eliminando la
posibilidad de crear diferencias innecesarias que posteriormente podrían
confundir a los usuarios.
• Por otro lado, unificar la nomenclatura y la semántica traería estabilidad
al mercado de los lenguajes orientados a objetos, permitiendo que los
proyectos se centraran en un solo lenguaje, dejando a los desarrolladores
de herramientas crear mejor aplicaciones.
• Finalmente, ellos esperaban que su colaboración pudiera conllevar
importantes mejoras en los tres métodos, de forma que se pudieran
abarcar nuevos problemas que ninguno de los tres métodos originales
resolvía adecuadamente.
Cuando de comenzó la unificación, se establecieron cuatro objetivos
primordiales en los que centrar sus esfuerzos:
• Permitir el modelado de sistemas, y no solo de software, usando
conceptos de la orientación hacia objetos.
38
Modelado orientado a objetos
• Modelar el sistema, desde el concepto hasta los artefactos ejecutables,
utilizando técnicas orientadas a objetos.
• Cubrir las cuestiones relacionadas con el tamaño inherente a los sistemas
complejos y críticos.
• Crear un lenguaje de modelado utilizable tanto por las personas como
por las maquinas.
En Junio de 1996 se publicaron las versiones 0.9 y 0.91. Durante ese año los
autores invitaron, y recibieron respuesta, de toda la comunidad internacional relacionada
con el tema. Además, varias corporaciones vieron el UML como un punto estratégico en
el desarrollo de sus actividades. Algunas de las empresas contribuyeron a la aparición
de la versión 1.0 en Enero de 1997 fueron IBM, Hewlet-Packard, Dell, Texas
Instruments... Esta versión fue ofrecida a la OMG (Object Management Group) para su
estandarización, en respuesta a su solicitud de propuestas para un lenguaje estándar de
modelado.
Entre Enero y Julio de 1997, el grupo inicial de colaboradores se amplió para
incluir prácticamente a todas las organizaciones que habían aportado algo al proyecto,
creándose un grupo de trabajo liderado por Cris Kobryn para trabajar en la semántica.
Como resultado se le entregó a la OMG la versión 1.1 para su estandarización en Julio
de 1997. Esta versión se aceptó el 14 de Noviembre de 1997 por la OMG.
El control del mantenimiento de UML fue asumido por la OMG Revision Task
Force, dirigida por Cris Kobryn. La RTF publicó una revisión editorial, UML 1.2, en
Junio de 1998. En otoño de 1998 la RTF publicó UML 1.3, que es la versión utilizada
en este proyecto.
3.1.2 ¿Qué es UML? ¿Por qué usar UML?
UML es un lenguaje estándar para escribir planos de software. Se puede utilizar
para especificar, construir y documentar los artefactos de un sistema que involucran
una gran cantidad de software.
39
Modelado orientado a objetos
UML es apropiado para modelar desde sistemas de información de empresas,
hasta aplicaciones distribuidas basadas en la web, e incluso para sistemas empotrados de
tiempo real muy exigentes. Es un lenguaje expresivo, que cubre todas las vistas
necesarias para desarrollar y luego desplegar tales sistemas.
UML es sólo un lenguaje, por lo tanto es tan sólo una parte de un método de
desarrollo de software. Es independiente del proceso, aunque para utilizarlo
óptimamente se debería usar en un proceso que fuese dirigido por los casos de uso,
centrado en la arquitectura, iterativo e incremental.
En general, UML es un lenguaje para visualizar, especificar, construir y
documentar los artefactos de un sistema con gran cantidad de software.
Como lenguaje, UML proporciona un vocabulario y unas reglas para combinar
las palabras de dicho vocabulario con el objetivo de posibilitar la comunicación. Un
lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la
representación conceptual y física del sistema. Un lenguaje de modelado como es UML
es, por tanto, un lenguaje estándar para los planos de software.
El modelado proporciona una comprensión de un sistema. Nunca es suficiente
un único modelo. Más bien, para comprender cualquier cosa, a menudo se necesitan
múltiples modelos conectados entre sí, excepto en los casos más triviales. Para sistemas
con gran cantidad de software, se requiere un lenguaje que cubra las diferentes vistas de
la arquitectura de un sistema mientras evoluciona a través del ciclo de vida del desrrollo
del software.
El vocabulario y las reglas de un lenguaje como UML indican cómo crear y leer
modelos bien formados, pero no dicen qué modelos se deben crear ni cuándo se
deberían crear. Ésta es la tarea del proceso del desarrollo del software. Un proceso bien
definido guiará a su usuario a decidir qué artefactos producir, qué actividades y personal
se emplean para crearlos y gestionarlos, y cómo usar estos artefactos para medir y
controlar el proyecto de forma global.
40
Modelado orientado a objetos
Para muchos programadores, la distancia entre pensar en una implementación y
transformarla en código es casi nula. Lo piensas, lo codificas. De hecho, algunas cosas
se modelan mejor directamente en código. En este caso, el programador todavía está
haciendo mentalmente algo de modelado, si bien lo hace de forma totalmente mental.
No obstante, esta manera de proceder plantea algunos problemas:
• Primero, la comunicación de estos modelos conceptuales se torna
complicada y está sujeta a errores, salvo que las dos partes hablen el
mismo lenguaje. Normalmente, los proyectos y las organizaciones
desarrollan su propio lenguaje, y es difícil comprender lo que está
pasando para alguien ajeno al grupo.
• Segundo, hay algunas cuestiones en un sistema de software que no se
pueden entender amenos que se construyan sobre modelos que
trasciendan el lenguaje de programación textual. Por ejemplo, el
significado de una jerarquía de clases puede inferirse, pero no capturarse
completamente inspeccionando el código de todas las clases en la
jerarquía.
• Tercero, si el desarrollador que escribió el código no dejó documentación
escrita de los modelos que hacía de forma mental, esa información se
perderá para siempre, o como mucho, será sólo parcialmente
reproducible a partir de la implementación una vez que el desarrollador
se haya marchado.
Al escribir modelos UML, se afronta el tercer problema: un modelo explícito
para facilitar la comunicación.
Algunas cosas se modelan mejor textualmente, otras se modelan mejor de forma
gráfica. En realidad, en todos los sistemas interesantes hay estructuras que trascienden
lo que puede ser representado mediante un lenguaje de comunicación. UML es uno de
esos lenguajes gráficos. Así afronta el segundo problema mencionado anteriormente.
41
Modelado orientado a objetos
UML es algo más que un simple compendio de símbolos gráficos. Más bien,
detrás de cada símbolo en la notación UML hay una semántica bien definida. De
manera que un desarrollador puede escribir un modelo en UML, y otro desarrollador, o
incluso otra herramienta, pude interpretar ese modelo sin ambigüedad. Así afronta el
primer problema mencionado con anterioridad.
En este contexto, especificar significa construir modelos precisos, no ambiguos
y completos. En particular, UML cubre la especificación de todas las decisiones de
análisis, diseño e implementación que se deben realizar al desarrollar y desplegar un
sistema con gran cantidad de software.
UML no es un lenguaje de programación visual, pero sus modelos pueden
conectarse a gran variedad de lenguajes de programación. Esto significa que es posible
establecer correspondencias desde un modelo UML a un lenguaje de programación
como C++, Java o Visual Basic, o incluso tablas en una base de datos relacional o
almacenamiento persistente en una base de datos orientada a objetos. Las cosas que se
expresan mejor gráficamente también se representan gráficamente con UML, mientras
que las cosas que se representan mejor textualmente se plasman con un lenguaje de
programación.
Esta correspondencia permite la ingeniería directa: generación de código a partir
de un modelo UML en un lenguaje de programación. Lo contrario también es posible:
se puede reconstruir un modelo en UML a partir de una implementación. Pero este
proceso no es automático, a menos que se codifique esa información en l a
implementación, la información se pierde cuando se pasa del modelo al código. La
ingeniería inversa requiere, por lo tanto, de herramientas que la soporten e intervención
humana. La combinación de estas dos vías de generación de código y de ingeniería
inversa produce una ingeniería “de ida y vuelta”, entendiendo por eso la posibilidad de
trabajar en una vista gráfica o textual, mientras que las herramientas mantienen la
consistencia de las dos vistas.
Además de esta correspondencia directa, UML es lo suficientemente expresivo y
no ambiguo como para permitir la ejecución directa de modelos, la simulación de
sistemas y la instrumentación de sistemas en ejecución.
42
Modelado orientado a objetos
UML cubre la documentación de la arquitectura de un sistema y todos sus
detalles. UML también proporciona un lenguaje para expresar requisitos y pruebas.
Finalmente, UML proporciona un lenguaje para modelar las actividades de
planificación de proyectos y gestión de versiones.
3.2 Especificación funcional del modelo de coordinación
El modelo de coordinación que en este proyecto se ha desarrollado ha sido
implementado en un lenguaje de programación orientado a objetos como es C++. Por
ello, resulta adecuado el uso de UML para explicar su diseño.
A continuación se muestran los diagramas que forman parte del lenguaje de
modelado unificado del proyecto, así como una breve introducción a los mismos, con el
fin de que su interpretación sea de utilidad a la hora de entender el modelo aquí
implementado.
3.2.1 Diagramas de casos de uso
Los casos de uso permiten describir el comportamiento de un sistema desde el
punto de vista del usuario basándose en un conjunto de acciones y reacciones. Es por lo
tanto una técnica que permite capturar los requisitos funcionales del sistema. De esta
forma queda delimitado el alcance del sistema y cuál es su relación con el entorno.
En estos diagramas, el sistema queda reducido a una “caja negra”, ya que no
interesa cómo lleva a cabo sus funciones, sino simplemente qué acciones visibles desde
el exterior son las que realiza.
Los casos de uso están basados en lenguaje natural, lo que los hace accesibles a
cualquier usuario. Además, aquellos casos de uso que resulten muy complejos pueden
descomponerse en nuevos casos de uso de un nivel inferior, hasta llegar a un nivel tal
que resulten fáciles de analizar.
Los casos de uso guían todo el proceso de desarrollo del sistema, lo que quiere
decir que en momentos determinados de dicho proceso, el sistema debe ser validado
comprobando que se ajusta al diagrama de casos de uso.
43
Modelado orientado a objetos
Los diagramas de casos de uso están formados por tres elementos
fundamentales:
• Actores. Los actores son los participantes de os casos de uso, se
corresponden con los usuarios que interactúan con el sistema. Estos
actores pueden ser humanos, dispositivos externos que interactúen con el
sistema, o incluso temporizadores que envíen eventos al mismo. Un actor
se caracteriza por la forma de interaccionar con el sistema, por lo que un
mismo usuario puede ejercer de varios actores, y un actor puede
representar a varios usuarios.
• Casos de uso. Son los escenarios de interacción de los actores.
Representan el comportamiento del sistema en relación con los usuarios.
De esta forma, un caso de uso define la secuencia de interacciones entre
uno o más usuarios y el sistema.
• Relaciones. Representan el flujo de información intercambiada entre los
actores y los casos de uso, o entre diferentes casos de uso. Normalmente,
se emplean para que un caso de uso obtenga la información necesaria
para llevar a cabo alguna acción, o para que el proceso proporcione algún
resultado. Estas relaciones pueden ser unidireccionales o bidireccionales.
Los diagramas de casos de uso se clasifican en diferentes niveles, en función del
grado de detalle con el que se represente el funcionamiento del sistema. De esta forma,
los diagramas de nivel 0 o contexto representan el sistema completo con un nivel de
detalle muy bajo, mientras que al aumentar el nivel, el grado de detalle va
incrementándose.
Notación
A continuación de muestra la notación empleada para la representación de los
distintos elementos que forman los diagramas de casos de uso.
44
Modelado orientado a objetos
Los actores son representados mediante figuras de hombre de palo, con su
correspondiente nombre debajo de la figura.
Xa
Figura 3.2-1. Notación de actores
Los casos de uso, o procesos, se representan mediante una elipse, con su nombre
correspondiente debajo de la misma.
Coordinación semafórica
Figura 3.2-2. Notación de casos de uso.
Por último, las relaciones se representan mediante flechas que unen los casos
de uso, o el caso de uso y el actor, entre los que existe un flujo de información.
Figura 3.2-3. Notación de relaciones
Debido a la similitud de los dos algoritmos implementados, los diagramas de
diseño UML de ambos métodos se irán presentando de forma paralela y conjunta. No en
vano, ambos algoritmos poseen partes en común que serán más fácilmente identificables
si se muestran a la vez.
45
Modelado orientado a objetos
3.2.1.1 Modelo de coordinación semafórica
3.2.1.1.1 Diagramas de caso de uso de nivel 0 o de contexto
En este diagrama se muestra la aplicación con el menor grado de detalle,
permitiendo una visión global de su comportamiento.
Xa
ViarioUsuario
Modelo de coordinación semafórica
Figura 3.2-4. Casos de uso de nivel 0
El usuario es la persona que se encuentra realizando la coordinación de los
semáforos de una cierta avenida. Su relación con el modelo de coordinación es
bidireccional, dado que proporciona la información necesaria para su ejecución y
recibe los resultados del proceso.
El viario es un agente externo y su relación es unidireccional con el modelo. En
concreto, se encarga de proporcionar al modelo los datos necesarios del viario relativos
a configuración del grafo que sirve de representación del mismo. Entre la información
que suministra se encuentran las cajas semafóricas de cada nodo, las señales de tráfico
que contiene cada caja, la información relativa a cada señal, etc...
Por último, se encuentra la xa, que es el programa que se encarga de resolver el
modelo de coordinación y cuya relación con este sistema es bidireccional, ya que recibe
del mismo la información necesaria para resolver el modelo y a su vez, proporciona los
resultados del proceso.
46
Modelado orientado a objetos
3.2.1.1.2 Diagramas de casos de uso de nivel 1
En este nivel se pretende profundizar en el funcionamiento interno del modelo
de coordinación semafórica.
Figura 3.2-5. Casos de uso de nivel 1
En este diagrama se divide el modelo en 2 procesos que se relacionan entre sí e
intercambian información.
El proceso de obtención de datos se encarga de obtener todos los datos
necesarios para el diseño del modelo de coordinación, para ello necesita la lista de todos
los nodos del viario, con el fin de elegir aquellos que conciernen a la avenida de
semáforos a coordinar. Además, necesitará cierta información para elaborar el modelo,
que sólo podrá obtener por medio del usuario.
Toda la información recopilada en el proceso anterior se la entregará al proceso
de obtención de la solución, el cual, proporcionará el modelo generado a partir de dicha
información y con un formato determinado a la xa. Ésta, resolverá el problema de
programación lineal y devolverá los resultados del mismo, que tras ser procesados
convenientemente, serán presentados de una forma legible al usuario.
3.2.1.1.3 Diagramas de casos de uso de nivel 2
Se ha creído conveniente entrar a explicar con mayor grado de detalle los
procesos que se han añadido al diagrama de casos de uso de nivel 1.
47
Modelado orientado a objetos
• Obtención de los datos
En este proceso se pretende obtener toda la información necesaria para generar
el modelo, que más tarde entregará al caso de uso obtención de la solución.
Figura 3.2-6. Diagramas de casos de uso de nivel 2. Obtención de los datos
El proceso de obtención de los nodos crea una lista de los nodos que contienen
las señales que serán coordinadas en el modelo. La información necesaria para la
creación de dicha lista le será proporcionada por el viario y por el usuario, este último
mediante la selección de los nodos integrantes de la lista.
La misma información se le proporciona tanto al modulo de representación de
caja como al de obtención de señales. El primero realiza una representación gráfica de
todas las señales semafóricas de la caja seleccionada; mientras que el segundo, con la
ayuda del usuario, confecciona la lista de señales que serán coordinadas.
Por último, en el proceso de obtención datos modelo se recogen todos los datos
del modelo concernientes a la distancia entre los semáforos, así como, los límites de
velocidad permitidos entre los mismos.
48
Modelado orientado a objetos
• Obtención de la solución
Este proceso se encarga de generar el modelo que se le pasará a la xa para que lo
resuelva y de presentar los datos de forma adecuada al usuario.
Figura 3.2-7. Diagramas de casos de uso de nivel 2. Obtención de la solución
El proceso generación modelo recibe los datos adquiridos en proceso obtención
de los datos y crea el modelo en un determinado formato que es capaz de leer la xa, para
finalmente pasarlo al caso de uso resolución modelo.
En el modulo resolución modelo se envía el modelo creado a la xa para que lo
resuelva y se procesa el archivo resultado determinándose si el problema de
programación lineal planteado tiene solución óptima o no.
Tanto el modulo de generación modelo como el de resolución modelo son
usados por el proceso de representación de resultados, a través de los cuales obtiene la
solución al problema de coordinación. En el caso que la solución sea óptima, este
modulo procesa el archivo devuelto por la xa obteniendo los datos relevantes y los
muestra de forma comprensible para el usuario.
49
Modelado orientado a objetos
3.2.2 Diagramas de paquetes
El objetivo de este tipo de diagramas es obtener una visión mucho más clara del
sistema de información orientado a objetos, organizándolo en diferentes subsistemas,
agrupando los elementos del análisis, diseño o construcción y detallando las relaciones
de dependencias entre ellos. El mecanismo de agrupación utilizado se denomina
paquete.
Estrictamente hablando, los paquetes y sus dependencias son elementos de los
diagramas de casos de uso, de clases y de componentes, por lo que se podría decir que
el diagrama de paquetes es una extensión de éstos.
En estos diagramas de pueden diferenciar dos tipos de elementos:
• Paquetes: Un paquete es la agrupación de elementos, bien sea casos de
uso, clases o componentes. Los paquetes pueden contener a su vez otros
paquetes anidados que en última estancia contendrán alguno de los
elementos anteriores.
• Dependencia entre paquetes. Existe una dependencia cuando un
elemento de un paquete requiere de otro que pertenece a un paquete
distinto. Es importante resaltar que las dependencias no son transitorias.
Los paquetes se van a representar mediante un símbolo en forma de carpeta, en
el cual se coloca el nombre del paquete correspondiente. Por su parte, las dependencias
entre paquetes se representan con una flecha discontinua con inicio en el paquete que
depende del otro.
A continuación se adjunta el diagrama de paquetes del algoritmo de
coordinación.
50
Modelado orientado a objetos
3.2.2.1 Diagramas de paquetes del algoritmo de coordinación
En el siguiente gráfico se pueden observar los paquetes que componen el
algoritmo de coordinación.
Viario
Algoritmo coordinación
Interfaz gráfica Lista
Grupo semafórico
VCL
Figura 3.2-8. Diagramas de paquetes del algoritmo de coordinación
En el diagrama se observan seis paquetes o elementos, que están relacionados
entre sí. Los paquetes son los siguientes:
• Viario: Este paquete contiene las clases utilizadas para describir el viario.
Por lo tanto, contendrá toda la información referente a los nodos
existentes en el escenario de simulación donde se incluye la información
sobre las señales luminosas de tráfico, es decir, todo lo que hace
referencia a los componentes estáticos del modelo.
• Grupo semafórico: Este paquete contiene las clases que se encargan de
recopilar los datos acerca de la caja semafórica asociada a un nodo
determinado.
51
Modelado orientado a objetos
• Algoritmo de coordinación: Dentro de este paquete se encuentran las
clases mas importantes, ya que además de almacenar todos los datos
necesarios para la construcción del modelo, son las encargadas de
generar el archivo con el problema programación lineal necesario para la
coordinación de las señales semafóricas.
• Lista: Este paquete contiene una clase parametrizada que será usada para
la implementación de listas de estructuras de las clases definidas en otros
paquetes. Es pues un paquete auxiliar, y su clase no tiene un significado
propio dentro del algoritmo, aunque es tremendamente útil a la hora del
procesamiento de los datos.
• VCL (Visual Component Library): Este paquete engloba a todos los
elementos visuales de la librería de Borland que se utilizan en la
aplicación.
• Interfaz gráfica: En este paquete se incluyen las clases que componen los
formularios visuales que permiten la interacción entre la aplicación y el
usuario. Estas clases hacen uso de los elementos VCL propios de
Borland.
3.2.3 Diagramas de clases
El objetivo principal de este modelo es la representación de los aspectos
estáticos del sistema, utilizando diversos mecanismos de abstracción (clasificación,
generalización, agregación).
El diagrama de clases recoge las clases existentes en los paquetes y sus
correspondientes asociaciones. En este diagrama se representa la estructura y
comportamiento de cada uno de los objetos del sistema y sus relaciones con los demás
objetos, pero no se muestra ninguna información temporal. Con el fin de facilitar la
comprensión del diagrama, se pueden incluir paquetes como elementos del mismo,
donde cada uno de ellos agrupa un conjunto de clases que tienen algún tipo de relación.
52
Modelado orientado a objetos
Este diagrama no refleja los comportamientos temporales de las clases, aunque para
representarlos puede usarse un diagrama de transición de estados.
Los elementos básicos del diagrama son:
• Clases. Una clase describe un conjunto de objetos con propiedades
(atributos) similares y un comportamiento común. Los objetos son
instancias de las clases.
No existe un procedimiento inmediato que permita localizar las clases
del diagrama de clases. Éstas suelen corresponderse con sustantivos que
hacen referencia al ámbito del sistema de información y que se
encuentran en los documentos de las especificaciones de requisitos y de
los casos de uso.
Dentro de la estructura de una clase se definen los atributos, que
representan los datos asociados a los objetos instanciados por esa clase, y
los métodos, que representan las funciones o procesos propios de los
objetos de una clase, caracterizando a dichos objetos.
Dentro de las clases es importante destacar un caso especial, las
plantillas o templates. Éstas son clases que están parametrizadas, es
decir, que necesitan de un parámetro a la hora de formarse.
• Relaciones. Los tipos más importantes de relaciones estáticas entre
clases son las siguientes:
o Asociación. Las relaciones de asociación representan un conjunto de
enlaces entre objetos o instancias de clases. Es el tipo de relación más
general, y denota básicamente una dependencia semántica. Por ejemplo
un Carril pertenece a un Tramo. Cada asociación puede representar
elementos adicionales que doten de mayor detalle al tipo de relación:
Rol, o nombre de la asociación, que describe la semántica de la
relación en el sentido indicado. Por ejemplo, la asociación entre
53
Modelado orientado a objetos
Carril y Tramo recibe el nombre de pertenece a, como rol en ese
sentido.
Multiplicidad, que describe la cardinalidad de la relación, es decir,
especifica cuántas instancias de una clase están asociadas a una
instancia de la otra clase. Los tipos de multiplicidad son: uno a uno,
uno a muchos, muchos a muchos...
o Herencia. Las jerarquías de generalización / especialización se conocen
como herencia. La herencia es el mecanismo que permite a una clase de
objetos incorporar atributos y métodos de otra clase, añadiéndolos a los
que ya posee. Con la herencia se refleja una relación es-un entre clases.
La clase de la cual se hereda se denomina superclase, y la que lo hereda
subclase.
o Agregación. La agregación es un tipo de relación jerárquica entre un
objeto que representa la totalidad de ese objeto y las partes que lo
componen. Permite el agrupamiento físico de estructuras relacionadas
lógicamente. Los objetos son-parte-de otro objeto completo.
o Composición. La composición es una forma de agregación donde la
relación de propiedad es más fuerte, e incluso coinciden el tiempo de
vida del objeto y las partes que lo componen.
o Dependencia. Una relación de dependencia se utiliza entre dos clases o
entre una clase y una interfaz, e indica que una clase requiere de otra
para proporcionar alguno de sus servicios.
A continuación se va a dar una explicación de la notación seguida para la
representación de estos diagramas.
Una clase se representa por una caja, separada en tres zonas por líneas
horizontales.
En la zona superior se muestra el nombre de la clase y propiedades generales
como el estereotipo. Si la clase es abstracta el nombre aparece en cursiva. El nombre es
único y sirve para diferenciarlo del resto de las clases.
54
Modelado orientado a objetos
La zona central contiene una lista de atributos, uno en cada línea. La notación
utilizada para representarlos incluye, dependiendo del detalle, el nombre del atributo, su
tipo y su valor por defecto, con el formato:
Visibilidad nombre: tipo = valor_inicial
Figura 3.2-9. Ejemplo de clase
3.2.3.1 Paquete de datos “Grupo semafórico”
Este paquete de datos contiene la información concerniente al funcionamiento de
los dispositivos reguladores de tráfico.
3.2.3.1.1 Descripción de las clases del paquete “Grupo semafórico”
3.2.3.1.1.1 Clase “Estructura”
Esta clase agrupa el conjunto de grupos semafóricos que pueden imponerse en
un nodo, el cual puede contener varias estructuras distintas que pueden aplicarse en
cualquier instante. Incluso dos estructuras asignadas a un mismo nodo pueden tener
ciclos diferentes, un número de fases distintas y estados desiguales.
55
Modelado orientado a objetos
Estructura Fases
Ciclo Figura 3.2-10. Estructura, fases y ciclo
Estructuracod_estructura : Codigo_estructuranumero_fases : unsigned charnumero_senales : unsigned charciclo : unsigned intposicion_intermedios : boolincluidos : booltiempo : boolactiva : bool
Cod_estructura() : Codigo_estructuraNumero_fases() : unsigned charNumero_senales() : unsigned charCiclo() : unsigned intIncluido() : boolPosicion_intermedios() : boolTiempo() : boolActiva() : boolActualiza_ciclo(c : unsigned int)Activar()Desactivar()Activar_tiempo()Desactivar_tiempo()Intermedios_delante()Intermedios_detras()Actualiza_incluido(inc : bool)Actualiza_codigo_estructura(codigo : Codigo_estructura)Actualiza_numero_fases(numero : unsigned char)Actualiza_numero_senales(numero : unsigned char)operator=(es : Estructura) : Estructuraoperator==(es : Estructura) : bool
Figura 3.2-11. Clase “Estructura”
56
Modelado orientado a objetos
• Atributos de la clase “Estructura”:
o cod_estructura : Identifica unívocamente a la estructura.
o numero_fases : Número de etapas o fases de las que consta la
estructura.
o numero_senales : Número de señales que se han definido en la
estructura.
o ciclo : Tiempo en segundos que dura el ciclo de la estructura.
o posicion_intermedios : Indica si los tiempos intermedios se producen
antes o después de cada fase.
o incluidos : Indica si los tiempos intermedios están incluidos en las
señales.
o tiempo : Indica si los tiempos se expresan en porcentajes o en segundos.
o activa : Indica si la estructura está actualmente regulando el tráfico.
• Métodos de la clase “Estructura”:
o Codigo_estructura Cod_estructura (void) : Devuelve el código de la
estructura en cuestión.
o unsingned char Numero_fases (void) : Devuelve el número de fases de
las señales presentes en la estructura.
o unsigned char Numero_senales (void) : Devuelve el número de señales
que componen la estructura.
o unsigned int Ciclo (void) : Devuelve el valor del ciclo de la estructura.
o void Incluido (void) : Devuelve el valor del atributo incluidos.
o bool Posición_intermedios (void) : Devuelve el valor del atributo
posición_intermedios.
o bool Tiempo (void) : Devuelve el valor del atributo tiempo.
o bool Activa (void) : Devuelve el valor del atributo activa.
o void Actualiza_ciclo (unsigned int c) : Actualiza el valor del ciclo de la
estructura.
o void Activar (void) : Activa la estructura.
57
Modelado orientado a objetos
o void Desactivar (void) : Desactiva la estructura.
o void Activar_tiempo (void) : Hace que los tiempos se expresen en
segundos.
o void Desactivar_tiempo (void) : Hace que los tiempos se expresen en
porcentajes.
o void Intermedios_delante (void) : Hace que los tiempos intermedios se
produzcan antes que las fases.
o void Intermedios_detras (void) : Hace que los tiempos intermedios se
produzcan después de las fases.
o void Actualiza_incluido (bool inc) : Actualiza el valor del atributo
incluido.
o void Actualiza_codigo_estructura (Codigo_estructura codigo) :
Actualiza el valor del atributo cod_estructura.
o void Actualiza_numero_fases (unsigned char numero) : Actualiza el
número de fases de la estructura.
o void Actualiza_numero_senales (unsigned char numero) : Actualiza el
número de señales de la estructura.
o Estructura operador= (Estructura es) : Copia una estructura origen en
una estructura destino.
o Bool operator== (Estructura es) : Compara dos instancias de la clase
estructura.
3.2.3.1.1.2 Clase “Codigo_estructura”
Esta clase se emplea para identificar unívocamente a una de las estructuras
analizadas anteriormente.
58
Modelado orientado a objetos
Codigo_estructuracodigo_nodo : unsigned intcod_estructura : unsigned int
Codigo_nodo() : unsigned intCod_estructura() : unsigned intActualiza_codigo_nodo(nodo : unsigned int)Actualiza_cod_estructura(cod : unsigned int)operator=(cod : Codigo_estructura) : Codigo_estructuraoperator==(cod : Codigo_estructura) : bool
Figura 3.2.-12. Clase “Codigo_estructura”
• Atributos de la clase “Codigo_estructura”:
o codigo_nodo : Nodo en el que se encuentra la estructura.
o cod_estructura : Código de la estructura en ese nodo.
• Métodos de la clase “Codigo_estructura”:
Se corresponden con los métodos habituales para el manejo de los
atributos, por los que su explicación se omitirá.
3.2.3.1.1.3 Clase “Codigo_senal”
Representa los estados que tomarán uno o varios semáforos durante todo el ciclo
de la estructura. Estos códigos tomarán un valor único que permita identificar las
distintas señales.
Codigo_senalCod_estructura : Codigo_estructuranumero_senal : unsigned char
Numero_senal() : unsigned charCod_estructura() : Codigo_estructuraActualiza_estructura(cod : Codigo_estructura)Actualiza_numero_senal(n : unsigned char)operator=(s Codigo_senal) : Codigo_senaloperator==(s Codigo_senal) : bool
Figura 3.2-13. Clase “Codigo_senal”
59
Modelado orientado a objetos
• Atributos de la clase “Codigo_senal”:
o cod_estructura : Código de la estructura a la que pertenece la señal.
o numero_senal : Número propio de la señal en el interior de la estructura
que la contiene.
• Métodos de la clase “Codigo_senal”:
Se corresponden con los métodos habituales para el manejo de los
atributos.
3.2.3.1.1.4 Clase “Fase”
Las fases o etapas muestran el estado que tienen cada una de las señales durante
un intervalo de tiempo concreto.
Fasecod_fase : Codigo_fasecolor : unsigned chartiempo : unsigned intporcentaje : floatnumero_intermedios : unsigned charpuntero_intermedios : unsigned int
Cod_fase() : Codigo_faseColor() : unsigned charTiempo() : unsigned intPorcentaje() : floatNumero_intermedios() : unsigned charPuntero_intermedios() : unsigned intActualiza_codigo_fase(c : Codigo_fase)Actualiza_color(c : unsigned char)Actualiza_tiempo(t : unsigned int)Actualiza_porcentaje(p : float)Actualiza_intermedios(numero : unsigned char)Actualiza_puntero_intermedios(p : unsigned int)operator=(f Fase) : Faseoperator==(f Fase) : bool
Figura 3.2-14. Clase “Fase”
• Atributos de la clase “Fase”:
60
Modelado orientado a objetos
o cod_fase : Identifica unívocamente cada fase.
o color : Estado que tiene la señal en la fase.
o tiempo : Duración de la fase en segundos.
o porcentaje : Tanto por ciento de duración de la fase respecto al ciclo
total.
o numero_intermedios : Número de tiempos intermedios de los que
dispone la fase.
o puntero_intermedios : Índice de la lista de intermedios en el que
comienzan los intermedios correspondientes a la fase.
• Métodos de la clase “Fase” :
Los métodos de esta clase son los correspondientes a la obtención y
modificación de los valores de los atributos, por lo que su significado es
suficientemente claro y no se detallará.
3.2.3.1.1.5 Clase “Codigo_fase”
Este código se utiliza para diferenciar a una fase concreta del resto de fases.
Codigo_fasenumero_fase : unsigned charCod_senal : Codigo_senal
Numero_fase() : unsigned charCod_senal() : Codigo_senalActualiza_fase(numero : unsigned char)Actualiza_senal(codigo : Codigo_senal)operator=(c : Codigo_fase) : Codigo_faseoperator==(c : Codigo_fase) : bool
Figura 3.2-15. Clase “Codigo_fase”
• Atributos de la clase “Codigo_fase”:
61
Modelado orientado a objetos
o numero_fase : Número que identifica a la fase dentro de la señal
correspondiente.
o cod_senal : Código de la señal a la que pertenece la fase.
• Métodos de la clase “Codigo_fase”:
Los métodos son los habituales en el manejo de los atributos.
3.2.3.1.1.6 Clase “Intermedio”
Los tiempos intermedios son tiempos fijos que garantizan la no ocurrencia
simultánea de cambios de rojo a verde para grupo diferentes.
Intermediocod_intermedio : Codigo_intermedioduracion : unsigned charcolor : unsigned char
Cod_intermedio() : Codigo_intermedioDuracion() : unsigned charColor() : unsigned charActualiza_duracion(d : unsigned char)Actualiza_color(c : unsigned char)Actualiza_codigo(c : Codigo_intermedio)operator=(i : Intermedio) : Intermediooperator==(i : Intermedio) : bool
Figura 3.2-16. Clase “Intermedio”
• Atributos de la clase “Intermedio”:
o cod_intermedio : Código que identifica al intermedio.
o duracion : Tiempo en segundos que dura el intermedio.
o color : Estado asignado al tiempo intermedio.
• Métodos de la clase “Intermedio”:
Los métodos son los habituales en el manejo de atributos y en el manejo de
instancias de dicha clase.
3.2.3.1.1.7 Clase “Codigo_intermedio”
62
Modelado orientado a objetos
Este código permite identificar unívocamente a los tiempos intermedios.
Codigo_intermediocod_intermedio : unsigned intcod_fase : Codigo_fase
Cod_intermedio() : unsigned intCod_fase() : Codigo_faseActualiza_numero_intermedio(n : unsigned int)Actualiza_codigo_fase(c : Codigo_fase)operator=(c : Codigo_intermedio) : Codigo_intermediooperator==(c : Codigo_intermedio) : bool
Figura 3.2-17. Clase “Codigo_intermedio”
• Atributos de la clase “Codigo_intermedio”:
o cod_intermedio : Identifica los distintos tiempos intermedios
pertenecientes a una misma fase.
o cod_fase : Identifica la fase a la que pertenece el intermedio.
• Métodos de la clase “Codigo_intermedio”:
Los habituales en el manejo de atributos.
3.2.3.1.1.8 Clase “Senal_semaforica”
Un semáforo es un dispositivo físico que regula el desplazamiento de vehículos
en el interior de una intersección.
63
Modelado orientado a objetos
Senal_semaforica
e : Estructuradesfase : unsigned intlista_fases : Lista_inf <Fase>lista_intermedios : Lista_inf <Intermedio>
Senal_semaforica()Inicial izacion()Desfase() : unsigned intNumero_fases() : unsigned charNumero_senales() : unsigned charCiclo() : unsigned intLista_fases() : Lista_inf <Fase>Lista_intermedios() : Lista_inf <Intermedio>Valor_estructura() : EstructuraAdd_fase(f : Fase)Add_intermedio(i : Intermedio)Actual iza_estructura(es : Estructura)Actual iza_desfase(d : unsigned int)Actual iza_l ista_fases(lista_f : Lista_inf <Fase>)Actuaiza_lista_intermedios(l ista_i : Lista_inf <Intermedio>)operator=(s : Senal_semaforica) : Senal_semaforicaoperator==(s : Senal_semaforica) : boolDestruir_l ista()Borrar_l ista()Procesar_cadena_importacion(cadena : char*, descripcion : int*, numero : unsigned int, ....) : boolImportar_senal(nombre : char*, numero_elementos : unsigned int*, .....) : boolSalvar_senal(nombre : char*)Salvar_senal(nombre : char*, modo : char*)Cargar_senal(nombre : char*) : boolCargar_senal_cont(F1 : FILE *) : boolSalvar_senal_cont(F1 : FILE*)Exportar_senal(nombre : char*)Procesar_cadena_exportacion(descripcion : int*, F1 : FILE*) : boolEstado_senal(senal : unsigned int, instante_simulacion : float) : unsigned charObtener_intermedios(fase : unsigned char) : intModificar_fase(fase : unsigned char, segundos : unsigned int)Modificar_intermedio(fase : unsigned char, intermedio : unsigned int, segundos : unsigned int)Modificar_intermedio(intermedio : Intermedio)Modificar_fase(fase : Fase)Datos_segundos(fas : int*, inte : int*, segundos : float, despl : bool, fase_ant : int, inte_ant : int) : boolModificar_intermedios_fase_final (fase : unsigned char, intermedio : int, sg_total : int, sg : int)Modificar_intermedios_mitad(fase : unsigned char, intermedio : int, sg_total : int, sg : int)Modificar_intermedios_final(fase : unsigned char, fase_sig : unsigned char, ....t)Modificar_fase_inter(fase : unsigned int, fase_sig : unsigned int, intermedio : int, ....) : intModificar_intermedio(senal : int, fase : int, intermedio : int, sg : int, final : bool, Posterior : bool)Modificar_fase_intermedio_fin(fase : int, sg : int)Obtener_tiempo(intermedio : int, fase : int) : intTiempos_intermedios(fase : unsigned char) : unsigned intRedimension_caja(nuevo_ciclo : unsigned int) : unsigned intActivar_estructura()Desactivar_estructura()Actual iza_porcentajes()
Figura 3.2-18. Clase “Senal_semaforica”
• Atributos de la clase “Senal_semaforica”:
o e : Estructura a la que pertenece la señal semafórica.
o desfase : Tiempo de desfase entre los distintos semáforos.
o lista_fases : Lista de las fases que pertenecen a la señal semafórica.
o lista_intermedios : Lista de los tiempos intermedios que pertenecen a la
señal semafórica.
64
Modelado orientado a objetos
• Métodos de la clase “Senal_semaforica”:
o void Inicializacion (void) : Crea las listas correspondientes a la señal
semafórica.
o Senal_semaforica operator= (Senal_semaforica s) : Permite la copia de
una instancia de la clase senal_semaforica en otra del mismo tipo.
o bool operator== (Senal_semaforica s) : Permite la comparación entre
dos instancias de la misma clase.
o void Destruir_lista (void) : Destruye las listas correspondientes a la
señal semafórica.
o void Borrar_lista() : Borra las listas correspondientes a la señal
semafórica.
o bool Procesar_cadena_importacion (char* cadena, int* descripcion,
unsigned int numero, Lista_inf<Intermedio>* lista_int,
Lista_inf<Fase>* lista_fas, unsigned int* numero_estructuras,
unsigned int cod_nodo, FILE* F1) : Procesa una línea de un fichero en
la que se encuentra información sobre la señal semafórica.
o bool Importar_senal (char* nombre, unsigned int* numero_elementos,
unsigned int elemento, unsigned int cod_nodo) : Con esta función se
obtiene toda la información almacenada en un archivo acerca de las
estructuras de un nodo. Para procesar el archivo hace uso del método
anterior.
o void Exportar_senal (char *nombre) : Nos permite exportar una señal
de la estructura contenida en la señal semafórica a un determinado
archivo.
o bool Procesar_cadena_exportacion (int *descripcion,FILE *F1) : Nos
permite introducir datos en un archivo en una línea determinada. Es
usado por el método anterior.
o unsigned char Estado_senal (unsigned int senal, float
instante_simulacion) : Devuelve el estado de la señal semafórica
teniendo en cuenta el instante de simulación y la señal de la que se
desea ver el estado que tiene.
65
Modelado orientado a objetos
o unsigned int Redimension_caja (unsigned int nuevo_ciclo) : Permite
cambiar el tiempo de ciclo de una estructura.
El resto de métodos no se comentan por ser los habituales en el manejo de
atributos y de los elementos constituyentes de una señal semafórica, tales como: las
fases, intermedios,etc…
3.2.3.1.2 Diagrama de clases del paquete “Grupo Semafórico”
El siguiente diagrama muestra las clases que componen el paquete, así como su
interrelación.
Codigo_estructura Punto(from Viario)Estructura1 1
+identifica a
1 1 10..* 1
+regula a
0..*
Senal_semaforica
Codigo_intermedio
Codigo_senal
1..*
1
+pertenece a
1..*
1
0..*1 0..*
+se asigna a1
Codigo_fase
Intermedio
1
1
+identifica a
1
1
Fase
1
1..*
+contiene a
1
1..*
1
1
+identidica a
1
1
1..*1 1..*
+contiene a
1Signal(from Algoritmo coordinación)
1..*1 1..*
+se compone de
1
Figura 3.2-19. Diagrama de clases “Grupo semafórico”
66
Modelado orientado a objetos
3.2.3.2 Paquete de datos “Algoritmo coordinación”
En este paquete se encuentran las clases que se encargan de almacenar los datos
para la posterior generación del modelo de coordinación, así como las encargadas de
generar dicho modelo. El modelo al mismo tiempo que se genera se va escribiendo en
un archivo de texto interpretable por el actor externo “xa”, que se encargará de resolver
el modelo planteado.
3.2.3.2.1 Descripción de las clases del paquete “Algoritmo coordinación”
3.2.3.2.1.1 Clase “Signal”
Esta clase permite almacenar los datos de una señal necesarios para su
coordinación, es decir, el ciclo y las fases de la misma.
Signalciclo_signal : unsigned intsenal : Lista_inf <Fase>senal_i : Lista_inf <Intermedio>
Signal()Leer_ciclo() : unsigned intLeer_lista() : Lista_inf <Fase>Leer_lista_i() : Lista_inf <Intermedio>Actualiza_ciclo(tiempo : unsigned int)Actualiza_lista(sen : Lista_inf <Fase>)Actualiza_lista_i(sen_i : Lista_inf <Intermedio>)operator=(s : Signal) : Signaloperator==(s : Signal) : bool
Figura 3.2-20. Clase “Signal”
• Atributos de la clase “Signal”:
o ciclo_signal : Indica el valor del ciclo de la señal cuyos datos
necesarios para su coordinación se almacenan en esta clase.
o senal : Contiene una lista con las fases de la señal, éstas serán
necesarias para su coordinación más adelante.
67
Modelado orientado a objetos
• Métodos de la clase “Signal”:
Los métodos de esta clase son los habituales en el manejo de los atributos, con lo
que su significado es evidente y por tanto, se omite su explicación.
3.2.3.2.1.2 Clase “Datos_modelo”
Esta clase almacena todos lo datos suministrados por el usuario, tales como:
distancia entre semáforos, velocidad máxima permitida en el tramo que separa a dos
semáforos, etc.., y que son necesarios para resolver el modelo de coordinación.
Datos_modelok : floatdistancia : Lista_inf <float>velocidad_max1 : Lista_inf <float>velocidad_max2 : Lista_inf <float>velocidad_min1 : Lista_inf <float>velocidad_min2 : Lista_inf <float>cambiove_max1 : Lista_inf <float>cambiove_max2 : Lista_inf <float>cambiove_min1 : Lista_inf <float>cambiove_min2 : Lista_inf <float>
Datos_modelo()Leer_valor_k() : floatLeer_elemento_distancia(i : unsigned int) : floatLeer_elemento_velocidad_max1(i : unsigned int) : floatLeer_elemento_velocidad_max2(i : unsigned int) : floatLeer_elemento_velocidad_min1(i : unsigned int) : floatLeer_elemento_velocidad_min2(i : unsigned int) : floatLeer_elemento_cambiove_max1(i : unsigned int) : floatLeer_elemento_cambiove_max2(i : unsigned int) : floatLeer_elemento_cambiove_min1(i : unsigned int) : floatLeer_elemento_cambiove_min2(i : unsigned int) : floatInsertar_valor_k(ka : float)Insertar_elemento_distancia(dis : float)Insertar_elemento_velocidad_max1(vel_max1 : float)Insertar_elemento_velocidad_max2(vel_max2 : float)Insertar_elemento_velocidad_min1(vel_min1 : float)Insertar_elemento_velocidad_min2(vel_min2 : float)Insertar_elemento_cambiove_max1(cvel_max1 : float)Insertar_elemento_cambiove_max2(cvel_max2 : float)Insertar_elemento_cambiove_min1(cvel_min1 : float)Insertar_elemento_cambiove_min2(cvel_min2 : float)Borrar_datos()
Figura 3.2-21. Clase “Datos_modelo”
68
Modelado orientado a objetos
• Atributos de la clase “Datos_modelo”:
o k : Contiene el valor de la proporción entre los anchos de banda
existentes en ambos sentidos de la circulación de la avenida a coordinar
: “inbound” y “outbound”.
o distancia : Lista que contiene la distancia que hay entre todos los
tramos existentes en la avenida a coordinar. Entendiéndose por tramo el
trozo de avenida comprendido entre dos señales luminosas de tráfico.
o velocidad_max1 : Lista que contiene la velocidad máxima permitida a
los conductores entre los distintos tramos existentes en la avenida y en
el sentido definido como “outbound”.
o velocidad_max2 : Lista que contiene la velocidad máxima permitida a
los conductores entre los distintos tramos existentes en la avenida y en
el sentido definido como “inbound”.
o velocidad_min1 : Lista que contiene la velocidad mínima permitida a
los conductores entre los distintos tramos existentes en la avenida y en
sentido definido como “outbound”.
o velocidad_min2 : Lista que contiene la velocidad mínima permitida a
los conductores entre los distintos tramos existentes en la avenida y en
sentido definido como “inbound”.
o cambiove_max1 : Lista que contiene el cambio en la velocidad máxima
permitida a los conductores entre los distintos tramos existentes en la
avenida y en sentido definido como “outbound”.
o cambiove_max2 : Lista que contiene el cambio en la velocidad máxima
permitida a los conductores entre los distintos tramos existentes en la
avenida y en sentido definido como “inbound”.
o cambiove_min1 : Lista que contiene el cambio en la velocidad mínima
permitida a los conductores entre los distintos tramos existentes en la
avenida y en sentido definido como “outbound”.
o cambiove_min2 : Lista que contiene el cambio en la velocidad mínima
permitida a los conductores entre los distintos tramos existentes en la
avenida y en sentido definido como “inbound”.
69
Modelado orientado a objetos
• Métodos de la clase “Datos_modelo”:
o Datos_modelo() : Constructor que se encarga de crear las listas que
conforman los atributos de la clase.
o void Borrar_datos() : Método que se ocupa de borrar las listas que
conforman los atributos de la clase.
El resto de métodos no se detallarán por ser su uso el común para la
gestión de los atributos.
3.2.3.2.1.3 Clase “Coordina_signal”
Es esta la clase más importante, debido a que genera el archivo con el modelo de
coordinación que se le pasará más tarde a la “xa” para que lo resuelva. Para ello se sirve
de la lista de señales que contiene y de los datos almacenados en la clase
“Datos_modelo”.
Coordina_signalciclo_max : unsigned intcilco_min : unsigned intsignal_group : Lista_inf <Signal>
Coordina_signal()Leer_ciclo_max() : unsigned intLeer_ciclo_min() : unsigned intLeer_lista() : Lista_inf <Signal>Numero_elementos() : unsigned intInsertar_senal(sig : Signal)Borrar_senal(i : unsigned int)Borra_lista()Extraer_senal(indice : unsigned int) : SignalGenera_archivo(nombre : AnsiString, dato : Datos_modelo)
Figura 3.2-22. Clase “Coordina_signal”
• Atributos de la clase “Coordina_signal”:
o ciclo_max : Contiene el valor del ciclo más alto de las señales que se
van a coordinar.
o ciclo_min : Contiene el valor del ciclo más bajo de las señales que se
van a coordinar.
70
Modelado orientado a objetos
o Signal_group : Es una lista de todas las señales que se van a coordinar.
Cada elemento de esta lista es un objeto de la clase signal, es decir,
contiene el ciclo de la señal y sus fases.
A continuación se va a describir sólo aquellos métodos que por su especial
funcionalidad tienen cierto interés.
• Métodos de la clase “Coordina_signal”:
o Coordina_signal() : Constructor que crea la lista de señales, es decir,
reserva memoria para la misma.
o void Inserter_senal(Signal sig) : Este método además de introducir una
señal nueva en la lista, compara el ciclo de esta señal con el de las ya
existentes para que en caso de que éste sea el menor actualizar el valor
del atributo ciclo_min y en caso de ser el mayor actualizar el valor del
atributo ciclo_max.
o void Genera_archivo(AnsiString nombre,Datos_modelo dato) : Método
que haciendo uso de la lista de señales de la clase y de los datos
provistos por el usuario a través del objeto “dato”, genera el archivo que
contiene el modelo de programación lineal usado para la coordinación
de señales semafóricas y que será resuelto por la “xa”.
71
Modelado orientado a objetos
3.2.3.2.2 Diagrama de clases del paquete “Algoritmo coordinación”
El siguiente diagrama muestra las clases que componen el paquete, así como su
interrelación.
Fase(from Grupo semafórico)Signal
1..*1
+pertenece a
1..*
+se compone de
1
Datos_modeloCoordina_signal
1..*
0..*
+pertenece a 1..*
+se compone de 0..*11 1
+hace uso de
1
Figura 3.2-23. Diagrama de clases “Grupo semafórico”
3.2.3.3 Paquete de datos “Interfaz gráfica”
Este paquete contiene las clases que posibilitan la comunicación entre la
aplicación y el usuario de la misma. Esta comunicación se realiza a través de una serie
de elementos tales como botones, cajas, listas de elementos, etc.., contenidos en un
formulario que se genera al iniciar la aplicación y se destruye al cerrarla.
3.2.3.3.1 Descripción de las clases del paquete “Interfaz gráfica”
3.2.3.3.1.1 Clase “Senal_elegida”
Esta clase permite manipular la lista formada por las señales elegidas por el
usuario para ser coordinadas. Facilita la interacción entre el usuario y la aplicación por
permitir la inclusión y la exclusión de señales de distintas cajas en la lista a coordinar.
72
Modelado orientado a objetos
Senal_elegidanumero_caja : AnsiStringnumero_estructura : AnsiStringnumero_senal : AnsiString
Actualiza_caja(caja : AnsiString)Actualiza_estructura(estructura : AnsiString)Actualiza_senal(senal : AnsiString)Numero_caja() : AnsiStringNumero_estructura() : AnsiStringNumero_senal() : AnsiStringoperator=(sen : Senal_elegida) : Senal_elegidaoperator==(sena : Senal_elegida) : bool
Figura 3.2-24. Clase “Senal_elegida”
• Atributos de la clase “Senal_elegida”:
o numero_caja : Contiene el número de la caja, asociada a un nodo del
viario, de la cual proviene la señal elegida.
o numero_estructura : Contiene el número de la estructura, asociada a
una caja, de la cual proviene la señal elegida.
o numero_senal : Contiene el número de la señal, asociada a una
estructura, elegida.
• Métodos de la clase “Senal_elegida”:
Los métodos de esta clase no se van a explicar porque son los habituales en
el manejo de los atributos.
3.2.3.3.1.2 Clase “Coordinacion_interactiva”
Esta clase es la encargada de generar el formulario, a través del cual el usuario
se comunicará con la aplicación. Este formulario está formado por una serie de botones
y cajas que facilitan al usuario la interacción con el programa.
A continuación, se detallará la clase completa, por carecer gran parte de los
atributos y métodos asociados a éstos de interés, dado que hacen referencia a los
elementos del paquete VCL.
73
Modelado orientado a objetos
Coordinacion_interactivainfo : Datos_modelolista_senales : Coordina_signalgrafica : Caja_interactivacaja : Lista_inf <Senal_semaforica>senales : Lista_inf <Senal_elegida>
Generar_formulario(padre : TWinControl*)Extraer_senal(nodo : unsigned int, senal : unsigned int, ....., tiempo_ciclo : unsigned int *) : boolResuelve_modelo_xa(nombre_entrada : AnsiString, nombre_salida : AnsiString *) : boolEvento_sel_nodo(Sender : TObject*)Activacion_seleccion_nodo(context : Contexto*)Sel_nodo(Sender : TObject*, Button : TMouseButton, Shift : TShiftState, X : int, Y : int)
Figura 3.2-25. Clase “Coordinacion_interactiva”
• Atributos de la clase “Coordinacion_interactiva”:
o info : Atributo que recoge los datos necesarios para la coordinación,
tales como: distancia entre tramos, velocidad máxima entre tramos,
etc… y que son suministrados por el usuario por medio del formulario.
o lista_senales : Lista que almacena las señales seleccionadas por el
usuario.
o grafica : Atributo que nos permite la representación gráfica de una
estructura perteneciente a una caja semafórica determinada.
o caja : Lista que contiene las estructuras presentes en la caja asociada al
nodo seleccionado.
o senales : Lista que almacena los datos de localización de las señales
seleccionadas para su coordinación, tales como: caja en la que se
encuentra, estructura a la que pertenece y número de la misma dentro de
esa estructura.
Recordar que sólo se han descrito los atributos más relevantes de esta
clase.
• Métodos de la clase “Coordinacion_interactiva”:
o void Generar_formulario (TWinControl *padre) : Genera en tiempo de
ejecución el formulario a través del cual el usuario se comunica con la
aplicación.
74
Modelado orientado a objetos
o bool Extraer_senal (unsigned int nodo,unsigned int senal,unsigned int
estructura,Lista_inf <Fase> *lista_f,Lista_inf <Intermedio> *lista_i,
unsigned int *tiempo_ciclo) : Método que nos permite extraer una señal
de una caja determinada y de una estructura específica dentro de la
misma. La señal estará compuesta por sus fases, intermedios y el
tiempo de su ciclo.
o bool Resuelve_modelo_xa (AnsiString nombre_entrada,AnsiString
*nombre_salida) : Método que resuelve el modelo de coordinación
contenido en el archivo indicado, el cual, tiene una estructura específica
que permite a la “xa” su interpretación. La solución se devuelve en otro
archivo para ser procesada mas tarde.
o void_fastcall Evento_sel_nodo (TObject *Sender) : Activa la función de
selección de nodo.
o void Activacion_seleccion_nodo (Contexto context*) : Gestiona los
movimientos del ratón a lo largo del viario.
o void_fastcall Sel_nodo (TObject *Sender, TMouseButton Button,
TShiftState Shift, int X, int Y) : Muestra el nodo seleccionado por el
usuario a través del viario.
75
Modelado orientado a objetos
3.2.3.3.2 Diagrama de clases del paquete “Grupo Semafórico”
El siguiente diagrama muestra las clases que componen el paquete, así como su
interrelación.
Senal_elegida
Senal_semaforica(from Grupo semafórico)
Datos_modelo(from Algoritmo coordinación)
Coordina_signal(from Algoritmo coordinación) Coordinacion_interactiva
1
1..*
1
1..*
1..*
1
1..*
1
11 11111 1+contiene a+contiene a
Figura 3.2-26. Diagrama de clases “Coordinacion_interactiva”
3.2.3.4 Paquete de datos “Lista”
El paquete de datos Lista contiene una clase parametrizada que sirve para crear
listas de instancias de otras clases, así como su manipulación. Entre las funciones que
pueden realizarse están la de añadir elemento, eliminar elemento, modificar elemento,
borrar lista,... En el siguiente gráfico se muestra el diagrama de clases de este paquete.
En realidad, cualquier clase que tenga sobrecargados los operadores necesarios, puede
ser parámetro de esta clase, por lo que solamente se muestra una relación en forma de
ejemplo.
76
Modelado orientado a objetos
3.2.3.4.1 Descripción de las clases del paquete “Lista”
3.2.3.4.1.1 Clase “Lista_inf”
Esta clase permite la organización de objetos de diversos tipos en una lista, de
forma que los datos pueden ser manejados con mayor facilidad. Los datos pueden ser
modificados, extraídos, eliminados,…
Lista_inflista : TList*
Crea_lista()Add_elemento(inf : Y)Lista() : TList *Insertar_elemento(posicion : Y, elemento : Y)Insertar_elemento_ind(elemento : Y, i : unsigned)Insertar_elemento_detras(elemento : Y, posicion : Y)Borrar_elemento(ele : Y)Borrar_elemento_indice(indice : unsigned int)Borrar_ultimo_elemento()Modificar_elemento(ele : Y)Modificar_elemento_indice(ele : Y, i : unsigned int)Borra_lista()Destruir_lista()Elemento(i : unsigned int) : YBuscar(el : Y) : unsigned intBuscar(elemento : Y, encontrado : bool *) : YNumero_elementos() : unsigned intGrabar_Informacion(nombre : char *)Cargar_Informacion(nombre : char *)Grabar_Informacion_cont(F1 : FILE *)Cargar_Informacion_cont(F1 : FILE *)operator=(l : Lista_inf) : Lista_inf
Y
Figura 3.2-27. Clase “Lista_inf”
77
Modelado orientado a objetos
• Atributos de la clase “Lista_inf”:
o lista: Lista de direcciones que mantendrá las posiciones de memoria de
los elementos que conformen la lista de objetos. Es una herramienta de
Borland que implementa métodos de inserción, eliminación y acceso a
los elementos, entre otros.
• Métodos de la clase “Lista_inf”:
o void Crea_lista(void): Método que inicializa la lista, reservando
memoria para la lista de punteros.
o void Add_elemento(Y inf): Añade el elemento inf a la lista al final de la
misma.
o void Lista(void): Devuelve el contenido de la lista de punteros y se usa
para saber si la lista está inicializada.
o void Insertar_elemento(Y posicion, Y elemento): Inserta el objeto
elemento en la posición ocupada por el elemento posicion. Éste último
y los posteriores se desplazarán para dejar hueco.
o void Insertar_elemento_ind(Y elemento, unsigned i): Inserta el objeto
elemento en la posición i.
o void Insertar_elemento_detras(Y elemento, Y posicion): Inserta el
objeto elemento en la posición posterior a la ocupada por el elemento
posicion. Los posteriores se desplazarán para dejar hueco.
o void Borrar_elemento(Y ele): Elimina de la lista el elemento ele.
o void Borrar_elemento_indice(unsigned int indice): Elimina de la lista el
elemento que se encuentra en la posición indice. Los índices de las
listas comienzan en el cero.
o void Modificar_elemento(Y ele): Modifica el elemento que es igual al
objeto ele por el nuevo ele. Esto puede parecer que no hace nada, pero
se explica con el hecho de que dos elementos para ser iguales, no han
de coincidir en cada uno de sus atributos, sino solamente en los
definidos en la sobrecarga del operados ‘= =’.
78
Modelado orientado a objetos
o void Modificar_elemento_indice(Y ele, unsigned int i): Reemplaza el
elemento con índice i por el elemento ele.
o void Borrar_lista(void): Elimina todos los elementos de la lista, pero al
contrario que el método Destruir_lista la lista sigue estando
inicializada.
o void Destruir_lista(void): Destruye la lista y cada uno de sus elementos.
o Y Elemento(unsigned int i): Devuelve el elemento situado en la posición
i (recordar que el primero está en la posición cero).
o unsigned int Buscar(Y ele): Devuelve el índice del elemento ele dentro
de la lista. Si no existe, devuelve el número de elementos de la lista.
o Y Buscar(Y elemento, bool* encontrado): Devuelve el elemento igual al
objeto elemento. La variable encontrado indicará si la búsqueda ha sido
realizada con éxito o no.
o unsigned int numero_elementos(void): Devuelve el número de
elementos en la lista.
o void Grabar_informacion(char* filename): Almacena la lista en el
archivo con nombre filename. Si el archivo existe, su contenido es
eliminado.
o void Grabar_informacion_cont(FILE* F1): Almacena la lista en el
archivo ya abierto y que es apuntado con el puntero F1. La información
se añade al final del archivo.
o void Cargar_informacion(char* filename): Recupera la lista del archivo
con nombre filename. El proceso busca los datos al principio del
mismo.
o void Cargar_informacion_cont(FILE* F1): Recupera la lista del
archivo ya abierto y que es apuntado con el puntero F1. Esta función se
usa cuando la información no esta al inicio del fichero. Es preciso que
el archivo se encuentre en la posición de inicio de la lista.
o Lista_inf operator= (Lista_inf l): Este método permite la copia de una
lista en otra lista del mismo tipo. Si la lista destino poseía datos (no
estaba vacía) los nuevos elementos serán añadidos al final de la misma.
79
Modelado orientado a objetos
3.2.3.4.2 Diagrama de clases del paquete “Lista”
El siguiente diagrama muestra las clases que componen el paquete, así como su
interrelación.
Signal(from Algoritmo coordinación)Lista_inf
0..*1
+pertenece a
0..*
+le pertenece
1
Y
Figura 3.2-28. Diagrama de clases del paquete Lista
3.2.3.5 Paquete de datos “VCL”
En este paquete se incluyen los componentes visuales de la librería de Borland
que se han usado para la generación de la interfaz gráfica. El siguiente diagrama
muestra algunos de esos componentes visuales. Todos son parte integrantes de la clase
Coordinacion_interactiva que representa un formulario. El resto de clases se
corresponden con botones, listas, etiquetas, paneles,...
TButton
TForm TPageControl
TGroupBox
TLabel
TListBox
TStringGrid TEdit
TMemo
TComboBox
TTabSheet
Coordinacion_interactiva(from Interfaz gráfica)
80
Modelado orientado a objetos
Figura 3.2-29. Diagrama de clases del paquete VCL
3.2.3.6 Paquete de datos “Viario”
Este paquete es utilizado para representar todos los componentes que conforman
el viario de una ciudad. Dicho viario será representado por un grafo formado por nodos
y tramos. En concreto existirá un tramo para cada sentido de circulación que tengan las
calles del viario, mientras que los nodos representan los cruces o intersecciones entre las
diferentes calles.
3.2.3.6.1 Descripción de las clases del paquete “Viario”
3.2.3.6.1.1 Clase “Contexto”
Esta clase agrupa todos los datos referentes al escenario de trabajo. De el se
extraen toda la información necesaria para representar el viario sobre el que se va a
trabajar. Posee muchos atributos y métodos. Se han descrito los más importantes.
Contextomapa : Mapaancho : floatalto : float
Ancho() : floatAlto() : float
Figura 3.2-30. Clase “Contexto”
• Atributos de la clase “Contexto”:
o Mapa: Instancia de la clase Mapa que contiene los datos referentes al
viario, entiéndanse nodos, tramos, longitudes,.... Es el atributo más
importante de la clase. Tiene visibilidad pública, por lo que es accesible
desde fuera de la clase.
o Ancho: Mantiene el ancho del mapa, para la representación gráfica del
viario.
81
Modelado orientado a objetos
o Alto: Contiene el alto del mapa, para la representación gráfica del
viario.
• Métodos de la clase “Contexto”:
o float Ancho(void): Devuelve el valor de la variable ancho.
o float Alto(void): Devuelve el valor de la variable alto.
3.2.3.6.1.2 Clase “Mapa”
Es la clase que contiene los datos de la red viaria. La clase se muestra en el
siguiente gráfico.
Mapacod_mapa : unsigned intnombre_mapa : char[255]Lista_nodos : Lista_inf<Punto>Lista_tramos : Lista_inf<Tramo>Lista_pm : TList*
Codigo() : unsigned intNombre_Mapa() : char*Actual iza_codigo(codigo : int)Actual iza_nombre_mapa(nombre : char*)Obtener_nodo(i : int) : PuntoObtener_tramo(i : int) : TramoLectura_pm(fichero : char*)Leer_nodos(nombre_fichero : char*)Leer_tramos(nombre_fichero : char*)Buscar_nodo(cod_nodo : unsigned int) : PuntoBuscar_tramo(cod_tramo : unsigned int) : Tramo
Figura 3.2-31. Clase “Mapa”
• Atributos de la clase “Mapa”:
o cod_mapa: Código que identifica el mapa que esta siendo utilizado.
o nombre_mapa: Nombre del mapa. Es una información aclaratoria del
mapa y complementaria al código del mapa.
o Lista_nodos: Lista de los nodos que componen la red viaria.
o Lista_tramos: Lista de los tramos que componen la red viaria y unen los
nodos de la misma.
82
Modelado orientado a objetos
o Lista_pm: Lista de los tramos que poseen detectores magnéticos de
tráfico.
• Métodos de la clase “Mapa”:
o unsigned int Codigo(void): Devuelve el valor del atributo cod_mapa.
o char* Nombre_Mapa(void): Devuelve el valor del atributo
nombre_mapa.
o void Actualiza_codigo(int codigo): Modifica el valor del atributo
cod_mapa.
o void Actualiza_nombre_mapa(char* nombre): Modifica el valor del
atributo nombre_mapa.
o Punto Obtener_nodo(int i): Devuelve el elemento i-ésimo de la lista de
nodos.
o Tramo Obtener_tramo(int i): Devuelve el elemento i-ésimo de la lista
de tramos.
o void Lectura_pm(char* fichero): Lee de un archivo de nombre fichero
la lista de tramos con detectores y la guarda en el atributo Lista_pm.
o void Leer_nodos(char*fichero): Carga la lista de nodos del archivo de
nombre fichero.
o void Leer_tramos(char*fichero): Carga la lista de tramos del archivo de
nombre fichero.
o Punto Buscar_nodo(unsigned int cod_nodo): Devuelve el nodo con
código de nodo igual a cod_nodo.
o Tramo Buscar_tramo(unsigned int cod_tramo): Devuelve el tramo con
código de nodo igual a cod_tramo.
83
Modelado orientado a objetos
3.2.3.6.1.3 Clase “Punto”
La clase Punto instancia objetos que representan a las intersecciones del viario.
Puntocod_nodo : unsigned intdescripcion : char[255]cod_estructura : unsigned inttipo : unsigned intcoord_x : floatcoord_y : float
Cod_Nodo() : unsigned intDescripcion() : char *Cod_Estructura() : unsigned intTipo() : unsigned intCoord_X() : floatCoord_Y() : floatActual iza_Cod_Nodo(u : unsigned int)Actual iza_Descripcion(cadena : char*)Actual iza_Cod_Estructura(u : unsigned int)Actual iza_Tipo(u : unsigned int)Actual iza_Coord_X(f : float)Actual iza_Coord_Y(f : float)operator=(p : Punto) : Puntooperator==(p : Punto) : bool
Figura 3.2-32. Clase “Punto”
• Atributos de la clase “Punto”:
o cod_nodo: Código del nodo que representa el objeto y lo diferencia del
resto de nodos de la red.
o descripcion: Cadena de texto que sirve de identificación del nodo. Es
informativa.
o cod_estructura: Estructura actual de funcionamiento del nodo.
o tipo: Variable que indica si el nodo es un centroide o no. Sólo los
centroides son origen o destino de viaje. El resto son de tránsito.
84
Modelado orientado a objetos
o coord_x: Variable que indica la coordenada x del nodo para su
representación gráfica.
o coord_y: Variable que indica la coordenada y del nodo para su
representación gráfica.
• Métodos de la clase “Punto”:
Los métodos de esta clase son los correspondientes a la obtención y
modificación de los valores de los atributos, por lo que su significado es
suficientemente claro y no se detallará. La sobrecarga de los operadores
posibilita la implementación de listas con objetos de esta clase como
elementos de la misma.
3.2.3.6.1.4 Clase “Datos_cruce”
Esta clase da información acerca de un nodo determinado, indicándo si el nodo
en cuestión tiene una caja semafórica asociada. Se describirá los atributos y métodos
más interesantes.
Datos_crucenodo : unsigned intdefinida_caja : bool
Actualiza_informacion(p : Punto)Actualiza_definida_caja(n : bool)Definida_caja() : boolNodo() : unsigned intActualiza_nodo(n : unsigned int)
Figura 3.2-33. Clase “Datos_cruce”
• Atributos de la clase “Datos_cruce”:
o nodo: Código del nodo al que pertenecen los datos del cruce.
o definida_caja: Atributo que indica si el nodo al que hacen referencia los
datos de la clase tiene caja semafórica asociada.
85
Modelado orientado a objetos
• Métodos de la clase “Datos_cruce”:
o void Actualiza_informacion(Punto p): Actualiza todos los datos de la
clase con la información del punto que se le pasa a la función. Por
defecto, sitúa el valor de definida_caja en falso.
o void Actualiza_definida_caja(bool n): Actualiza el valor del atributo
definida_caja.
o bool Definida_caja(): Devuelve el valor del atributo definida_caja.
o unsigned int Nodo(): Devuelve el valor del atributo nodo.
o void Actualiza_nodo(unsigned int n): Modifica el valor del atributo
nodo.
3.2.3.6.2 Diagrama de clases del paquete “Viario”
El siguiente diagrama muestra las clases que componen el paquete, así como su
interrelación.
86
Modelado orientado a objetos
Mapa
Contexto
1
1
1
1
Coordinacion_interactiva(from Interfaz gráfica)
1
1
+hace uso de
1
1
Datos_cruce
Punto0..*1 0..*1
1
1
1
1
+se relaciona con
Figura 3.2-34. Diagrama de clases del paquete Viario
4 Implementación del modelo e interfaz gráfica.
4.1 Introducción
Para la implementación del modelo y posterior resolución se ha optado por el
uso de un lenguaje orientado a objetos como es C++. Más concretamente se ha
empleado el entorno de programación que proporciona la herramienta C++ Builder, la
cual suministra un entorno de programación visual que facilita en gran medida el
empleo de un lenguaje como C++, que se caracteriza por tener una gran cantidad de
reglas y términos diferentes.
En este apartado se va a realizar una descripción muy breve de lo que es la
programación orientada a objetos y de aquellos componentes fundamentales que forman
parte de la misma.
87
Implementación del modelo e interfaz gráfica
La programación orientada a objetos (POO) se define como una técnica o estilo
de programación que utiliza objetos como bloque esencial de construcción. Un objeto es
una unidad que contiene datos y las funciones que operan sobre esos datos. Estos
objetos se corresponden con los elementos que debe utilizar el programa, como pueden
ser los tramos o los vehículos en el caso del simulador.
Una clase es una colección de objetos que poseen características y operaciones
comunes. En una clase se encuentra contenida toda la información necesaria para crear
nuevos objetos pertenecientes a esa misma clase.
Los objetos solamente pueden ser accedidos y manipulados por las operaciones
que previamente se hayan definido sobre su clase. Para evitar que dichos objetos sean
utilizados en otras operaciones, se utiliza una técnica denominada encapsulación, que
esconde los datos y sólo permite acceder a ellos de forma controlada.
Otros conceptos de interés en la POO son el polimorfismo que permite utilizar
un mismo nombre para un tipo genérico de acciones, y la herencia, mediante la cual un
objeto puede adquirir las propiedades de otro objeto.
4.2 Implementación del modelo
Para la resolución del problema se ha optado por implementar el segundo
modelo de los vistos en el apartado 3 de esta memoria, modelo extendido de
maximización del ancho de banda, que trata de obtener el mayor intervalo de tiempo
posible para que los vehículos puedan atravesar la avenida sin detenerse ante alguna
señal luminosa de tráfico.
Dicho modelo de programación lineal, coordina las señales de una avenida,
teniendo en cuenta que el flujo de tráfico puede ser más espeso en la dirección de salida
en un momento determinado o en la dirección de entrada en otro. Ésta situación se
modela a través de un factor de proporción que denominamos k. Además, este modelo
88
Implementación del modelo e interfaz gráfica
considera la velocidad a la que los conductores pueden transcurrir a lo largo de los
diferentes tramos formados por la distancia existente entre dos semáforos consecutivos,
limitándola superior e inferiormente. También nos permite controlar los cambios en la
velocidad de los vehículos para que estos no sean demasiados abruptos. Para
conseguirlo, lo que se hará será limitar inferior y superiormente el recíproco de la
velocidad.
El modelo se construirá de forma que sea interpretable por el programa de
optimización lineal, xa, que se usará para la resolución del problema de coordinación.
Dicho programa, recibe un archivo que contiene el problema de programación lineal
que se quiere resolver, y devuelve un archivo con la solución del mismo. Archivo, que
posteriormente será procesado para la obtención de los datos necesarios para la
presentación de la solución.
El diseño del programa va ser representado mediante los diagramas de flujo
correspondientes a la implementación en C++ de las funciones principales que
intervienen en él.
La estructura básica del programa de coordinación de señales de tráfico viene
determinada por el diagrama de flujo de la figura 5.2-1.
89
Implementación del modelo e interfaz gráfica
Figura 4.2-1 Estructura general del programa
En primer lugar se carga el escenario, del cual se obtendrá los nodos de la
avenida que se coordinará, después se obtienen los datos del modelo mediante la carga
de los archivos de cajas asociados a los nodos seleccionados y que contienen toda la
información acerca de las señales luminosas de tráfico que rigen a éstos. Los demás
datos necesarios para la construcción del modelo, se obtienen por medio de la
interacción entre el usuario y la interfaz gráfica. A continuación, se construye el archivo
que contiene el modelo de coordinación y que se le pasará a la xa para que resuelva el
problema lineal. Finalmente se presentan los resultados obtenidos al usuario.
Siguiendo el diagrama de flujo de la figura 4.2-1, se puede describir con más
detalles los bloques que lo conforman. Se comienza por describir el segundo bloque, ya
que en el primero, Carga Escenario, tan solo se obtienen los datos referentes a los
90
Implementación del modelo e interfaz gráfica
distintos nodos y tramos que componen el viario. En el segundo bloque el usuario
selecciona los nodos que forman parte de la avenida que se quiere coordinar, una vez
seleccionados éstos, se visualiza la caja semafórica asociada al nodo elegido o se le
asocia una en caso de no tener éste ninguna asociada. Tras visualizar la caja, se
selecciona la señal que se quiere coordinar y se extrae de la misma mediante el siguiente
método:
91
Implementación del modelo e interfaz gráfica
Inicio
Sí
nombre=Application->Exenamenombre_caja=nombre.SetLength(nombre.Length()-12)nombre_caja=nombre_caja+AnsiString(“datos\\Caja\\
N_”)+AnsiString(nodo)+AnsiString(“.caj”)extracion=senal_sen.Importar_senal(nombre_caja.c_str(),&n_ele
mentos,estructura,nodo)
!asociada
Extracion==false
senal_sen=caja.Elemento(estructura)extracion=true
No
return(extracion)Sí
lista_fase.Crea_lista()lista_intermedio.Crea_lista()
*tiempo_ciclo=senal_sen.Ciclo()lista_fase=senal_sen.Lista_fases()
lista_intermedio=senal_sen.Lista_intermedios()n_fases=(int)senal_sen.Numero_fases()
f_aux=n_fases*(senal)i=0
No
i<n_fases
fase_aux=Lista_fase.Elemento(f_aux+i)n_inte=n_inte+(int)fase_aux.Numero_in
termedios()lista_f->Add_elemento(fase_aux)
i++
Sí
i_aux=n_inte*(senal)j=0No
J<n_intelista_fase.Destruir_lista()
lista_intermedio.Destruir_lista()return(extracion)
j++
inte_aux=lista_intermedio.Elemento(i_aux+j)lista_i->Add_elemento(inte_aux)
Sí
No
Fin
Figura 4.2-2 Extracción de una señal determinada de una caja semafórica
92
Implementación del modelo e interfaz gráfica
Se puede comprobar en la figura 4.2-2, que para la extracción de la señal es
necesario saber si el nodo seleccionado tiene una caja asociada o no, puesto que de esto
depende el que la extracción se realice de un modo u otro. Esto se debe a que el formato
del archivo en el que se guardan los datos de las señales de una caja es diferente para
aquellos nodos que tienen una asociada. Una vez se ha extraído los datos de la caja del
nodo elegido, se obtienen los datos de la señal de una lista que contiene la información
acerca de las fases de las señales de la caja y de otra lista que contiene los datos de los
intermedios.
Conformada la lista de señales de la avenida que se quiere coordinar, se pasa a
resolver el modelo creado a partir de esta lista y de los datos referentes a distancia entre
tramos de la avenida y velocidades de los vehículos en los mismos, datos éstos,
obtenidos a través de la relación entre el usuario y la interfaz gráfica.
Hasta aquí llega el segundo bloque del diagrama de flujo de la figura 4.2-1, a
partir de ahora todos los métodos que se van a ver forman parte del tercer bloque de este
diagrama y son aquellos encargados de generar y resolver el modelo así como de
presentar los datos obtenidos al usuario.
Antes de mostrar a través del diagrama de flujo correspondiente el método que
se encarga de generar el modelo, se explica el formato del archivo en el cual se guardará
el modelo generado y que se le pasará a la xa para que lo resuelva. Para explicar el
formato de este archivo se usa el ejemplo que se muestra en la figura 4.2-3:
93
Implementación del modelo e interfaz gráfica
Figura 4.2-3 Ejemplo del formato de un archivo de entrada a la xa
Se observa en la figura 4.2-3, como en la cabecera del archivo se introduce el
título del modelo, cuya importancia es nula, el siguiente paso es indicar a la xa si lo que
se desea es maximizar o minimizar la función objetivo del problema, que para el
modelo usado será maximizar puesto que el objetivo de la coordinación es que las
bandas verdes a través de las cuales un vehículo puede atravesar la avenida sin
detenerse sean lo más anchas posibles. A continuación, se desarrolla la función objetivo
en la que además de indicar la proporción en la cual participan las variables del
problema se indica si alguna de ellas ha de ser un numero entero, lo que se expresa
mediante la situación de la variable entre paréntesis, como en el caso de M1 en el
ejemplo. Tras expresar la función objetivo, se exponen las restricciones del problema,
en éstas, deben de estar las variables a la izquierda de la igualdad y la parte numérica a
94
Implementación del modelo e interfaz gráfica
la derecha. En la parte final del modelo, se expresan como restricciones los posibles
valores que pueden tomar las variables del problema.
Una vez explicado el formato que deben de tener los archivos que contienen el
problema lineal a resolver, se puede describir el método que los genera mediante su
diagrama de flujo:
95
Implementación del modelo e interfaz gráfica
Inicio
DecimalSeparator='.'nombre=street + ".lp"
archivo=fopen(nombre.c_str(),"w+t")fprintf(archivo,"..TITLE\n")
fprintf(archivo," Coordinacion semaforica deavenida\n\n")
fprintf(archivo,"..OBJECTIVE MAXIMIZE\n")auxiliar=" B1 + B2 + 0 Z + \n"
l=0
l<signal_group.Numero_elementos()
auxiliar+=" + 0 W1" + AnsiString(l+1)auxiliar+=" + 0 W2" + AnsiString(l+1)
Sí
l<signal_group.Numero_elementos()-1
auxiliar+=" + 0 T1" + AnsiString(l+1)auxiliar+=" + 0 [M" + AnsiString(l+1)
auxiliar+="] + 0 T2" +AnsiString(l+1) + " +\n"
Sí
l++
No
fprintf(archivo,auxiliar.c_str()) fprintf(archivo,"\n\n")fprintf(archivo,"..CONSTRAINTS\n")
auxiliar="R1: B2 - " + AnsiString(dato.Leer_valor_k()) + " B1 = 0"fprintf(archivo,auxiliar.c_str())
fprintf(archivo,"\n") auxiliar="R2: Z >= " + AnsiString(1.0/ciclo_max)
fprintf(archivo,auxiliar.c_str()) fprintf(archivo,"\n")
auxiliar="R3: Z <= " + AnsiString(1.0/ciclo_min)fprintf(archivo,auxiliar.c_str())
fprintf(archivo,"\n") aux=4
i=0
i<signal_group.Numero_elementos()
No
senal_aux=signal_group.Elemento(i)fases_senal.Crea_lista()
fases_senal=senal_aux.Leer_lista()n_fases=fases_senal.Numero_eleme
ntos()j=0
Sí
j<n_fases
auxiliar="R" + AnsiString(aux) + ": B1 >= 0"fprintf(archivo,auxiliar.c_str())
fprintf(archivo,"\n") aux=aux+1
auxiliar="R" + AnsiString(aux) + ": B2 >= 0"fprintf(archivo,auxiliar.c_str())
fprintf(archivo,"\n") fases_senal.Destruir_lista() fclose(archivo)
Fin
No
Sí
J++
No
Notciclo=senal_aux.Leer_ciclo()
ri=(tiempo*1)/tciclolista_rojos->Add_elemento(ri)
i++
96
Implementación del modelo e interfaz gráfica
fase_senal=fases_senal.Elemento(j)
color=fase_senal.Color()
color=='B'
Sí
suma=fase_senal.Tiempo()tiempo=tiempo+suma
Sí
No
i!=0
anterior=ri-anteriorauxiliar="R" + AnsiString(aux) + ": (W1" + AnsiString(i)
auxiliar+=" + W2" + AnsiString(i) + ") - (W1" + AnsiString(i+1)auxiliar+=" + W2" + AnsiString(i+1) + ") + (T1" + AnsiString(i)
auxiliar+=" + T2" + AnsiString(i) + ") - M" + AnsiString(i)auxiliar+=" = " + AnsiString(anterior)
fprintf(archivo,auxiliar.c_str())fprintf(archivo,"\n")
aux=aux+1
Sí
i<signal_group.Numero_elementos()-1
No
auxiliar="R" + AnsiString(aux) + ": T1" + AnsiString(i+1) + " - " +AnsiString(dato.Leer_elemento_distancia(i)/dato.Leer_elemento_velocidad_max1(i)) + " Z >= 0"
fprintf(archivo,auxiliar.c_str()) fprintf(archivo,"\n")
aux=aux+1 auxiliar="R" + AnsiString(aux) + ": T1" + AnsiString(i+1) + " - " +
AnsiString(dato.Leer_elemento_distancia(i)/dato.Leer_elemento_velocidad_min1(i)) + " Z <= 0"fprintf(archivo,auxiliar.c_str())
fprintf(archivo,"\n") aux=aux+1
auxiliar="R" + AnsiString(aux) + ": T2" + AnsiString(i+1) + " - " +AnsiString(dato.Leer_elemento_distancia(i)/dato.Leer_elemento_velocidad_max2(i)) + " Z >= 0"
fprintf(archivo,auxiliar.c_str()) fprintf(archivo,"\n")
aux=aux+1 auxiliar="R" + AnsiString(aux) + ": T2" + AnsiString(i+1) + " - " +
AnsiString(dato.Leer_elemento_distancia(i)/dato.Leer_elemento_velocidad_min2(i)) + " Z <= 0"fprintf(archivo,auxiliar.c_str()) fprintf(archivo,"\n")
aux=aux+1 auxiliar="R" + AnsiString(aux) + ": T1" + AnsiString(i+1) + " >= 0"
fprintf(archivo,auxiliar.c_str()) fprintf(archivo,"\n") aux=aux+1
auxiliar="R" + AnsiString(aux) + ": T2" + AnsiString(i+1) + " >= 0" fprintf(archivo,auxiliar.c_str())
fprintf(archivo,"\n") aux=aux+1
Sí
i==0
No
di_anterior=dato.Leer_elemento_distancia(i) Sí
i>0 &&i<signal_group.Numero_
elementos()-1
No
Sí
No
97
Implementación del modelo e interfaz gráfica
di_actual=dato.Leer_elemento_distancia(i) auxiliar="R" + AnsiString(aux) + ": " + AnsiString(di_anterior/di_actual) + " T1" + AnsiString(i+1)
auxiliar+=" - T1" + AnsiString(i) + " - " +AnsiString(di_anterior*(dato.Leer_elemento_cambiove_max1(i-1))) + " Z <= 0"
fprintf(archivo,auxiliar.c_str())fprintf(archivo,"\n")
aux=aux+1 auxiliar="R" + AnsiString(aux) + ": " + AnsiString(di_anterior/di_actual) + " T1" + AnsiString(i+1)
auxiliar+=" - T1" + AnsiString(i) + " - " +AnsiString(di_anterior*(dato.Leer_elemento_cambiove_min1(i-1))) + " Z >= 0"
fprintf(archivo,auxiliar.c_str()) fprintf(archivo,"\n")
aux=aux+1 auxiliar="R" + AnsiString(aux) + ": " + AnsiString(di_anterior/di_actual) + " T2" + AnsiString(i+1)
auxiliar+=" - T2" + AnsiString(i) + " - " +AnsiString(di_anterior*(dato.Leer_elemento_cambiove_max2(i-1))) + " Z <= 0"
fprintf(archivo,auxiliar.c_str())fprintf(archivo,"\n")
aux=aux+1 auxiliar="R" + AnsiString(aux) + ": " + AnsiString(di_anterior/di_actual) + " T2" + AnsiString(i+1)
auxiliar+=" - T2" + AnsiString(i) + " - " +AnsiString(di_anterior*(dato.Leer_elemento_cambiove_min2(i-1))) + " Z >= 0"
fprintf(archivo,auxiliar.c_str()) fprintf(archivo,"\n")
aux=aux+1di_anterior=di_actual
Sí
Sí
anterior=ri ri=1-ri
auxiliar="R" + AnsiString(aux) + ": W1" + AnsiString(i+1) + " + B1 <= " + rifprintf(archivo,auxiliar.c_str())
fprintf(archivo,"\n") aux=aux+1
auxiliar="R" + AnsiString(aux) + ": W2" + AnsiString(i+1) + " + B2 <= " + rifprintf(archivo,auxiliar.c_str())
fprintf(archivo,"\n") aux=aux+1
auxiliar="R" + AnsiString(aux) + ": W1" + AnsiString(i+1) + " >= 0"fprintf(archivo,auxiliar.c_str())
fprintf(archivo,"\n") aux=aux+1
auxiliar="R" + AnsiString(aux) + ": W2" + AnsiString(i+1) + " >= 0"fprintf(archivo,auxiliar.c_str())
fprintf(archivo,"\n") aux=aux+1 tiempo=0 n_fases=0
No
Figura 4.2-4 Método que crea el archivo que contiene el problema lineal de
coordinación
Como se puede ver en el diagrama de flujo, al mismo tiempo que el modelo se
crea según el patrón legible por la xa se va escribiendo el archivo de entrada a ésta. Este
método crea un archivo con un nombre específico y con la extensión “.lp”, el cual, se
pasa como parámetro a la función que resuelve el problema lineal. Dicha función
determina si la solución al problema aportada por la xa a través de un fichero de salida
es óptima o por el contrario, es irrealizable.
Antes de describir la función que resuelve el problema, se va a explicar el
formato del archivo de salida de la xa mediante un ejemplo:
98
Implementación del modelo e interfaz gráfica
Figura 4.2-5 Primera parte del archivo de salida de la xa
Lo primero que se ve en el archivo de salida es el modelo que se acaba de
resolver, tal y como se escribió en el archivo de entrada, después se presentan las
estadísticas del modelo y la información de si el modelo tiene solución optima o no, y
en caso de tenerla (como en el ejemplo de la figura 4.2-5) el valor óptimo de la función
objetivo.
El objetivo de la función que se encarga de resolver el modelo, no sólo es el de
llamar a la xa, si no también el de determinar si el modelo planteado tiene solución
óptima. Para ello, como se puede comprobar en el diagrama de flujo de la figura 4.2-6,
se procesa el archivo de salida de la xa en busca de la cadena de caracteres formada por
las letras “OPT” de la palabra “óptima” (ver figura 4.2-5), ya que esta sucesión de letras
tan sólo aparece en el archivo de salida cuando el problema presenta solución.
A continuación se muestra el diagrama de flujo de la función de la que se acaba
de hablar:
99
Implementación del modelo e interfaz gráfica
Inicio
nombre_aux=nombre_entrada num_c=nombre_aux.Length() num_c=num_c-3 nombre_aux.SetLength(num_c) *nombre_salida=nombre_aux + ".dat"
nombre=Application->ExeName nombre=nombre.SetLength(nombre.Length() - 12) auxiliar=nombre + "xa.exe"
result = spawnl(P_WAIT,auxiliar.c_str(),auxiliar.c_str(), "Modeloxa.lp", "output","Modeloxa.dat",NULL) auxiliar=*nombre_salida
nombre=nombre + *nombre_salida *nombre_salida=nombreF1=fopen(nombre.c_str(),"rt")
auxiliar!="|"fgets (cadena,2,F1)
auxiliar=AnsiString(cadena)Sí
auxiliar=="O"
fgets (cadena,2,F1)auxiliar=AnsiString(cadena)
auxiliar==" "
fgets (cadena,2,F1)auxiliar=AnsiString(cadena)
auxiliar=="P"
fgets (cadena,2,F1)auxiliar=AnsiString(cadena)
auxiliar==" "
fgets (cadena,2,F1)auxiliar=AnsiString(cadena)
auxiliar=="T"fclose(F1) return(true)
fclose(F1) return (false)
Sí
Sí
Sí
Sí
Sí
Fin
No
No
Figura 4.2-6 Método que resuelve el problema lineal de coordinación
100
Implementación del modelo e interfaz gráfica
Una vez que se comprueba la viabilidad del problema planteado, se pasa al
análisis del archivo de salida para obtener los valores de las variables para la solución
óptima dada. Antes de describir el método que se encarga de procesar el archivo, se
describirá la segunda parte del archivo de salida mediante el ejemplo de la figura 4.2-7.
Figura 4.2-7 Segunda parte del archivo de salida de la xa
Como se puede ver en la figura el archivo de salida presenta en una tabla el valor
de todas las variables así como su coste. Hay que comentar que esta tabla sólo aparece
cuando el problema planteado tiene solución. Esta parte del archivo se encuentra por
debajo de la parte mostrada en la figura 4.2-5. Además de las partes mostradas del
archivo de salida, hay una tercera parte que no se muestra por carecer de interés para los
objetivos de este trabajo, que muestra como se cumplen las restricciones y el valor de
las variables del problema dual.
Se muestra ahora el diagrama de flujo del método que se encarga de realizar el
procesado del archivo que se acaba de comentar:
101
Implementación del modelo e interfaz gráfica
Inicio
F1=fopen(nombre_archivo.c_str(),"rt")
auxiliar!="|"
fgets (cadena,2,F1)auxiliar=AnsiString(cadena)
Sí
retorno!=2
No
fgets (cadena,2,F1)auxiliar=AnsiString(ca
dena)
auxiliar=="\n"
retorno++
Sí
Sí
No
num_senales=Numero_elemento_ListBox_senal()num_senales=num_senales*5
filas=num_senales/2 num_senales=filas
i=0
No
i<num_senales
primero=falsej=1
Sí
j<9
fscanf(F1,"%s",cadena)caracter=cadena[0]
Sí
J++
No
i++
No
102
Implementación del modelo e interfaz gráfica
(caracter=="|" ||caracter=="I") &&
primero
fin++
Sí
fin==2
No
fclose(F1)return
j==2
Sí
No
auxiliar=AnsiString(cadena)var_auxiliar.Actualiza_nombre(auxiliar)
j==3
Sí
No
auxiliar=AnsiString(cadena)filas=auxiliar.ToDouble()
var_auxiliar.Actualiza_valor(filas) variables->Add_elemento(var_auxiliar)
primero=true
j==6
Sí
No
auxiliar=AnsiString(cadena)var_auxiliar.Actualiza_nombre(auxiliar)
j==7
Sí
No
auxiliar=AnsiString(cadena)filas=auxiliar.ToDouble()
var_auxiliar.Actualiza_valor(filas) variables->Add_elemento(var_auxiliar)
Sí
No
NoNo
103
Implementación del modelo e interfaz gráfica
retorno=0fin=0
retorno!=3
fgets (cadena,2,F1)auxiliar=AnsiString(cadena)
Sí
auxiliar=="\n"
retorno++
Sí
No
No
fclose(F1)
Fin
No
Figura 4.2-8 Método que procesa el archivo de salida de la xa
En el diagrama de flujo de la figura 4.2-8 se ve como se va obteniendo los
valores de las variables de la tabla del archivo de salida y se van almacenando en un
lista para después poder calcular los desfases que deben tener las señales entre sí para
maximizar el ancho de banda.
Por último, en este bloque se procede a la presentación de los resultados, es
decir, el modelo de coordinación, el ancho de banda en ambas direcciones, el tiempo de
ciclo y el desfase de cada una de las señales con respecto a la primera.
Hasta aquí llega todo lo referente a la implementación del modelo, en la que se
ha visto en detalle aquellas funciones cuyo interés es más destacado, a partir de ahora se
entra en la descripción de la interfaz gráfica con la cual interactúa el usuario.
104
Implementación del modelo e interfaz gráfica
4.3 Interfaz gráfica
A continuación se realiza una descripción de la interfaz gráfica a través de la
cual el usuario va a poder plantear el problema de coordinación, resolver dicho
problema y visualizar la solución del mismo. Para la descripción se va a usar una serie
de capturas de pantalla que facilitarán la compresión de la misma.
Se inicia el programa global sobre tráfico en el que se encuentra enmarcado este
trabajo, a continuación se procede a la carga del escenario en el cual se encuentra la
avenida cuyas señales luminosas de tráfico se quieren coordinar. Ahora, se selecciona la
acción que sobre el escenario se quiere realizar, en este caso, la coordinación
semafórica, como se puede ver en la figura 4.3-1.
Figura 4.3-1 Muestra la selección de nuestra aplicación
105
Implementación del modelo e interfaz gráfica
Una vez dentro de la aplicación desarrollada, se encuentra una pantalla con tres
pestañas, en la primera pestaña se tiene todo lo necesario para seleccionar los nodos
pertenecientes a la avenida que se quiere coordinar, así como lo necesario para
seleccionar las señales que se van a coordinar.
Zona de elección de nodos
Minimapas Elección de señales de la caja visualizada
Figura 4.3-2 Pantalla de selección de los nodos cuyas señales se van a coordinar
Como se puede ver en la figura 4.3-2, se tiene una zona en la que hay una lista
con todos los nodos que hay en el escenario cargado, para seleccionar un nodo se puede
buscar a través de los minimapas o bien en la lista. Una vez elegidos los nodos que
conforman la avenida a coordinar, se visualizan las cajas asociadas a los mismos, es
decir, las señales semafóricas que rigen dichos nodos. Puede ocurrir que un nodo no
106
Implementación del modelo e interfaz gráfica
tenga asociada ninguna caja, en cuyo caso, la aplicación permite importar una y en caso
de que se quiera, asociársela tal y como se observa en la figura 4.3-3. En el supuesto de
que se haya asociado la caja importada al nodo elegido, se tiene luego la posibilidad de
deshacer esta asociación, por lo que la aplicación permite importar, asociar y eliminar la
asociación entre una caja y un nodo.
Figura 4.3-3 Aplicación que permite importar una caja a un nodo
Para facilitar la elección de la señal que se quiere coordinar, se puede ver un
gráfico de las señales que componen la caja semafórica pulsando sobre la pestaña
“Representación caja”, tal y como se puede apreciar en la figura 4.3-4.
107
Implementación del modelo e interfaz gráfica
Figura 4.3-4 Representación gráfica de una caja semafórica asociada a un nodo
Una vez que hemos confeccionado la lista de señales que se quieren coordinar se
pasa a la fase de introducción de los datos de distancia entre tramos, velocidades
máximas y mínimas entre los mismos y cambios en la velocidad máximos y mínimos,
datos éstos, necesarios para la construcción del modelo lineal de maximización de
ancho de banda. Para introducir los datos se selecciona la pestaña “Ancho de banda”
que muestra a una pantalla en la que se encuentran cuadros de texto donde se pueden
introducir los datos y una zona en la que se expone la solución al problema de
coordinación. En esta zona, se puede observar en la figura 4.3-5 que por defecto
muestra el modelo lineal que se le pasa a la xa para que lo resuelva.
108
Implementación del modelo e interfaz gráfica
Zona de introducción de datos
Zona de presentación de resultados
Figura 4.3-5 Interfaz para la introducción de datos y presentación de resultados
A través de las pestañas de la zona de presentación de resultados se obtiene los
aspectos más importantes de la solución al problema de coordinación, así de este modo
se puede optar por visualizar el modelo construido a partir de las señales a coordinar y
de los datos suministrados a la interfaz como ocurre en la figura 4.3-5, por visualizar el
tiempo de ciclo adecuado así como los anchos de banda en la dirección de salida y
entrada a la avenida para la solución óptima dada por la xa, o bien visualizar a través de
la pestaña “Desfase” de la zona de presentación de resultados, el tiempo que hay que
retrasar las señales respecto a la primera para conseguir que la coordinación sea óptima
para el problema planteado, como se puede ver en la figura 4.3-6.
109
Implementación del modelo e interfaz gráfica
Figura 4.3-6 Presentación de los resultados de desfase entre las señales
Como se ha visto la interfaz no presenta ningún tipo de complicación y tan sólo
hay que conocer la construcción del problema para el manejo correcto y útil de los
resultados.
110
Implementación del modelo e interfaz gráfica
5 Pruebas del sistema
En este capítulo se va a realizar diferentes pruebas de la aplicación creada con el
fin de mostrar la finalidad de la misma. Se llevará a cabo dos tipos de pruebas, la
primera tratará de demostrar que el programa utilizado por la aplicación para la
resolución del problema de programación lineal, xa, funciona correctamente; mientras
que el segundo tipo de prueba mostrará la utilidad de la aplicación para un caso real
situado en la ciudad de Móstoles, de la cual, se tiene los datos referentes a la señales
reguladoras de tráfico de las avenidas donde se va a realizar la coordinación.
5.1 Prueba de funcionamiento de la XA
En este apartado se demostrará el correcto funcionamiento de la xa, programa
que usa la aplicación para resolver el problema lineal de coordinación.
Para realizar esta demostración se va a resolver por un lado, un modelo de
coordinación mediante la aplicación desarrollada y por otro, se resolverá el mismo
modelo usando la utilidad de resolución de problemas lineales que se encuentra en el
programa Excel asociado al paquete de Microsoft Office y que se denomina Solver. A
continuación se describirá el modelo que se va a resolver mediante ambas aplicaciones.
Para demostrar la validez de la xa se va a realizar la coordinación de señales
luminosas de tráfico situadas en una avenida del escenario que se va a usar. Este
escenario está compuesto por 1345 nodos, de los cuales, sólo se utilizarán tres, donde se
suponen ubicados los semáforos que se van a coordinar. Además, estos nodos estarán
unidos por dos tramos de los 4422 que conforman el escenario, y de los que se conocen
su longitud, así como la velocidad a la que los vehículos podrán circular por ellos.
Dicho escenario se puede ver en la siguiente figura:
111
Pruebas del sistema
Figura 5.1-1 Escenario de la prueba de validez
Los nodos que se han seleccionado para la coordinación son el 586-585-584, a
los cuales, se le han asignado una caja de forma que: nodo 586 → caja 23, nodo 585 →
caja 21 y nodo 584 → caja 22. De cada caja se extrae una señal, así pues de la caja 23 se
toma la señal 2, de la caja 21 se coge la señal 1 y de la caja 22 se extrae la señal 1. La
representación gráfica de estas señales se puede observar en la siguiente figura:
112
Pruebas del sistema
Caja 23
Caja 21
Caja 22
Señales elegidas de su caja correspondiente
Señal elegida en esta caja
Figura 5.1-2 Representación gráfica de las señales a coordinar
A través de una tabla se exponen los datos de distancia entre los tramos que unen
los nodos, las velocidades máximas y mínimas a las que se va a poder circular por las
mismas y los cambios en la velocidad máximos y mínimos (esto evita que los cambios
en la velocidad del vehículo sean bruscos), que junto con los datos del tiempo en rojo y
el ciclo de las señales extraídas de las cajas, permiten conformar el modelo de
programación lineal con el que se resuelve el problema de coordinación.
113
Pruebas del sistema
Tramos del nodo 1 al nodo 2
del nodo 2 al nodo 3
Distancia (m) 75 70 Velocidad máxima outbound (m/s) 11.11 9.72 Velocidad máxima inbound (m/s) 11.11 9.72 Velocidad mínima outbound (m/s) 9.72 8.33 Velocidad mínima inbound (m/s) 9.72 8.33 Cambio velocidad máxima outbound (s/m) 0.015 Cambio velocidad máxima inbound (s/m) 0.015 Cambio velocidad mínima outbound (s/m) 0.01 Cambio velocidad mínima inbound (s/m) 0.01
Tabla 5.1-1 Datos de distancia, velocidades y cambios en la velocidad
Con todos los datos de los que se disponen junto con el dato de la constante de
proporcionalidad entre el ancho de banda de salida y entrada, k = 3 para este caso, se
puede construir el modelo de programación lineal cuya solución proporciona el ancho
de banda verde en ambas direcciones. El modelo que se usa es el del problema
extendido de maximización del ancho de banda que se explicó en el apartado 2.3.2. De
manera que el problema lineal generado es el siguiente:
114
Pruebas del sistema
Figura 5.1-3 Programa lineal de maximización del ancho de banda
A continuación se expone la solución al problema aportada por ambas
aplicaciones.
5.1.1 Solución aportada por la XA
A través de la interfaz gráfica explicada en el apartado 4, se crea el modelo de
coordinación mediante la selección de los nodos (ver figura 5.1-4) y de las señales de
las cajas asociadas a estos.
115
Pruebas del sistema
Nodos y tramos que vamos a coordinar
Figura 5.1-4 Avenida que vamos a coordinar
Tras introducir los datos de distancia y de velocidades se pasa a resolver el
problema usando la xa, obteniéndose los siguientes valores de las variables:
B1 B2 Z W11 W21 T11 M1
0.16667 0.50000 0.01250 0.14091 0.00000 0.08708 0.00000
T21 W12 W22 T12 M2 T22 W13 W23
0.08708 0.15329 0.04000 0.09002 0.00000 0.09002 0.33333 0.00000
Tabla 5.1.-2 Valor de las variables en el óptimo
116
Pruebas del sistema
Conociendo el valor de las variables se obtiene el valor de lo datos que interesan
mediante las fórmulas explicadas en los apartados 2.3.2 y 2.3.2.1. Estos son el ciclo, el
ancho de banda en ambas direcciones y el desfase de una señales con otras.
Ciclo señales Ancho banda
salida
Ancho banda
entrada
Desfase señales
1-2
Desfase señales
1-3
80 13.3336 40 18.2392 25.2056
Tabla 5.1-3 Valor de los datos de interés
Ahora se representa gráficamente como quedan las señales luminosas de tráfico
una vez han sido coordinadas, es decir, habiéndole aplicado el retraso calculado
anteriormente.
Figura 5.1-5 Representación gráfica de la coordinación
117
Pruebas del sistema
Por tanto, un vehículo que llegue al primer semáforo dentro de la banda puede
atravesar la avenida conformada por los tres semáforos sin detenerse en ninguno y
circulando a la velocidad determinada por el usuario en cada tramo. Cabe comentar que
se considera cualquier tiempo que no sea rojo como tiempo durante el cual se puede
atravesar el semáforo sin detenerse.
A continuación se obtiene la solución al problema haciendo uso del Solver, que
será la misma que se obtiene mediante la xa, lo que confirma que ésta es una aplicación
válida para su uso en el programa aquí desarrollado.
5.1.2 Solución aportada por el Solver de Excel
Antes de mostrar la solución que se obtiene mediante esta utilidad se realizará
una descripción básica del funcionamiento de la misma para facilitar su comprensión.
5.1.2.1 Funcionamiento básico del Solver
Para la descripción de esta utilidad se va a usar un ejemplo práctico que se
muestra a continuación:
Max Z = 10 X1 + 8 X2
Sujeto a:
30X1 +20X2 <= 120
2X1 + 2X2 <= 9
4X1 + 6X2 <= 24
X1, X2 >=0
La única dificultad que se tiene es la de modelar el problema dentro del Excel, y
eso, es muy fácil. Por supuesto, hay infinidad de maneras de hacerlo, aquí se propone
una.
118
Pruebas del sistema
Se activa Excel y en una hoja:
• Se ubican las celdas que se corresponderán con el valor de las
variables de decisión; en éste caso, las celdas B6 y C6, se les da un
formato para diferenciarlas de las demás, aquí azul oscuro (ver figura
5.1-6). Se ubica también, las celdas que contendrán los costes de las
variables de decisión, B4 y C4, y se llenan con sus respectivos
valores, 10 y 8. Aunque éste último paso, se podría omitir y dejar los
coeficientes definidos en la celda de la función objetivo, así es mejor
para los análisis de sensibilidad y para que la hoja quede portable
para otro programa.
• Se ubica la celda que se corresponderá con la función objetivo (celda
objetivo), la B3. En ella se escribe la fórmula que representa a la
función objetivo, en éste caso, será el coeficiente de X1 (en B4) por
el valor actual de X1 (en B6) mas el coeficiente de X2 (en C4) por el
valor actual de X2 (en C6) O sea: =$B$4 * $B$6 + $C$6 * $C$4.
• Coeficientes para la primera restricción: se pueden escribir en la
misma columna de las variables de decisión; en las celdas B7 y C7,
con los valores 30 y 20, seguido del sentido de la desigualdad (≤) y
de su correspondiente RHS: 120. A la derecha se ubicará el valor
actual de consumo de la restricción, ella se escribirá en función de las
variables de decisión y de los coeficientes de la restricción. Esta
celda, la utilizará Solver como la restricción real cuando se le indique
que el valor de ésta celda no puede sobrepasar la de su
correspondiente RHS. De nuevo será el valor del coeficiente por el de
la variable:=B7 * $B$6 + C7 * $C$6. Nótese que ahora B7 y C7 no
tienen el signo $, ya que una vez que se haya escrito ésta celda, se
podrá arrastrar hacia abajo para que Excel escriba la fórmula
automáticamente. Se repite los pasos anteriores para las demás
restricciones.
119
Pruebas del sistema
Figura 5.1-6 Representación del problema en la hoja de cálculo de Excel
Ahora para resolverlo se debe hacer click en Herramientas->Solver,
obteniéndose una pantalla como la de la figura 5.1-7. Lo primero que hay que hacer es
especificar la celda objetivo, B3 en este caso, y el propósito: maximizar. A
continuación, se selecciona las celdas que van a cambiar como consecuencia de la
resolución del problema, es decir, el valor de las variables, que en este caso serán B6 y
C6. Esto se puede llevar a cabo bien escribiendo el nombre de las celdas en el recuadro
Cambiando las celdas, bien señalándolas en la hoja de cálculo directamente.
Figura 5.1-7 Configuración de los parámetros del Solver
120
Pruebas del sistema
Y ahora para las restricciones se hace click en agregar:
Figura 5.1-8 Agregar restricción a los parámetros del Solver
Como se puede ver en Referencia de la celda se introduce la celda en la cual el
Solver calculará el valor de la restricción. A continuación, se especifica el sentido de la
restricción ≤, ≥ ó =, aquí también se puede especificar el tipo de variable, que por
defecto es continua, pero se puede escoger "Int" para entera o "Bin" para binaria. En el
recuadro de la derecha se establece la cota. Aquí se escribirá 120 pero mejor se escribe
$E$7 para que quede direccionado a la celda que contiene el 120, lo que permite poder
después cambiarlo y volver a encontrar la respuesta a manera de análisis de sensibilidad.
Se repite éste paso para las otras dos restricciones.
La condición por la que una variable no puede ser negativa hay que incluirla
manualmente del siguiente modo:
Figura 5.1-9 Condición de no negatividad
121
Pruebas del sistema
El cuadro de diálogo debe quedar de la siguiente manera:
Figura 5.1-10 Resultado de la configuración de los parámetros del Solver
De este modo, con una hoja de cálculo de Excel y la utilidad Solver, se puede
escribir problemas lineales de manera muy flexible y resolverlos fácilmente.
Hasta aquí llega esta breve explicación de esta utilidad del Excel que facilita la
comprensión de la demostración de validez de la xa que a continuación se muestra.
5.1.2.2 Solución obtenida mediante el Solver
Mediante una hoja de cálculo de Excel se construye el problema lineal y como
se ha explicado en el punto anterior se resuelve con el Solver, obteniéndose el siguiente
resultado:
122
Pruebas del sistema
Figura 5.1-11 Hoja de cálculo con el problema lineal de coordinación
Se comprueba que la solución aportada por el Solver es la misma que la aportada
por la aplicación desarrollada, basada en la xa, aunque se observa que el valor de
algunas variables es diferente. Esto se debe a que el problema tiene más de una solución
óptima, es decir, hay una arista de la región admisible en la que todos sus puntos son
solución. Depende del método de resolución que use el programa, el que éste nos de una
u otra solución. En cualquier caso el valor de la función objetivo es el mismo en todas
las soluciones posibles.
Este resultado demuestra la validez de la xa como programa de resolución de
problemas lineales. Del mismo modo demuestra también el buen funcionamiento de la
aplicación desarrollada.
123
Pruebas del sistema
5.2 Prueba de la aplicación sobre un escenario real
En este punto se procede a la coordinación de dos avenidas situadas en un
escenario real como es la ciudad de Móstoles y de las que se conoce el número de
señales luminosas de tráfico y como se rigen éstas.
Las dos avenidas que se coordinan son la avenida de Carlos V y la avenida de
Alfonso XII que se observan en la figura 5.2-1. Hay que comentar que los datos de los
que se disponen de las avenidas y de las señales luminosas que las rigen se han obtenido
mediante medición manual, lo que quiere decir que están sujetos a ligeras variaciones
con respecto a los reales. Además esto provoca que no se conozca la distribución de los
intermedios de las señales con lo que la distribución de los tiempos se realizará de
manera aleatoria entre fases e intermedios.
Figura 5.2-1 Plano de las avenidas a coordinar
124
Pruebas del sistema
5.2.1 Prueba realizada en la avenida Carlos V
Se comienza por describir los datos que sobre la avenida se conocen, es decir, el
número y el color de las fases de las señales, así como la distancia existente entre los
distintos semáforos que rigen la avenida. También se exponen las limitaciones de
velocidad que se pondrán entre señal y señal, y la relación de proporción entre el ancho
de banda de entrada y salida. Por último se mostrará la solución propuesta por la
aplicación.
Antes de ver las señales que rigen esta avenida, hay que comentar que al
desconocer las fases, los intermedios y el comienzo del ciclo de la señal, se ha puesto
uno al azar que no obedece a ninguna norma preestablecida.
A continuación se ven las señales semafóricas que se van a coordinar:
Figura 5.2-2 Señales que rigen la avenida Carlos V
125
Pruebas del sistema
Conocidas las señales se muestran los datos de velocidades, cambios de
velocidad y distancias que se van a aplicar a la avenida a coordinar.
Tramos del nodo 1 al nodo 2
del nodo 2 al nodo 3
Distancia (m) 156 182 Velocidad máxima outbound (m/s) 12.5 9.72 Velocidad máxima inbound (m/s) 12.5 9.72 Velocidad mínima outbound (m/s) 11.11 8.33 Velocidad mínima inbound (m/s) 11.11 8.33 Cambio velocidad máxima outbound (s/m) 0.03 Cambio velocidad máxima inbound (s/m) 0.03 Cambio velocidad mínima outbound (s/m) 0.023 Cambio velocidad mínima inbound (s/m) 0.023
Tabla 5.2-1 Límites de velocidad, cambios de velocidad y distancia
El valor que se usa de la constante de proporcionalidad entre el ancho de banda
de entrada y salida es el de k = 1.
Con estos datos y habiendo creado las cajas que contienen las señales reales que
regulan la avenida de Carlos V, se pasa a resolver el problema haciendo uso de la
aplicación desarrollada. Para hacer uso de ésta se ha cargado un escenario cualquiera ya
que no se dispone del propio de la ciudad de Móstoles, y elegido tres nodos al azar a los
que se le han asociado momentáneamente las cajas creadas. Tras elegir las señales de
las cajas, se introducen los datos que se muestran en la tabla 5.2-1 y se resuelve el
modelo generado que se muestra en la siguiente figura:
126
Pruebas del sistema
Figura 5.2-3 Modelo lineal de coordinación de la avenida Carlos V
La resolución de este modelo genera unos resultados que se aprecian en la
siguiente tabla:
B1 B2 Z W11 W21 T11 M1
0.25076 0.25076 0.01111 0.34924 0.34924 0.15173 1.00000
T21 W12 W22 T12 M2 T22 W13 W23
0.13867 0.00000 0.00000 0.22353 0.00000 0.20829 0.07147 0.07147
Tabla 5.2-2 Solución del problema lineal de coordinación de la avenida Carlos V
127
Pruebas del sistema
Mediante la manipulación de estos resultados y la utilización de la fórmula que
proporciona el desfase que debe de haber entre una señal y otra para que el ancho de
banda de salida y entrada sea el obtenido, se obtienen los siguientes valores de interés:
Ciclo señales Ancho banda
salida
Ancho banda
entrada
Desfase señales
1-2
Desfase señales
1-3
90 22.5706 22.5706 13.6570 26.1386
Tabla 5.2-3 Datos de interés para la coordinación
Ya se esta en disposición de poder mostrar el resultado gráfico que se genera
como consecuencia de la aplicación de los desfases a las señales luminosas de tráfico
que regulan la avenida que se ha coordinado:
Figura 5.2-4 Resultado gráfico de la coordinación de la avenida Carlos V en la dirección
outbound
128
Pruebas del sistema
Por tanto, todos los vehículos que alcancen el primer semáforo dentro del ancho
de banda verde pueden atravesar la avenida sin detenerse a una velocidad prefijada para
cada tramo, lo que provoca que el tráfico sea más fluido por no producirse
aglomeraciones de vehículos en las señales luminosas de tráfico.
5.2.2 Prueba realizada en la avenida Alfonso XII
Al igual que en el ejemplo anterior se comenzará por mostrar las señales que
rigen la avenida en cuestión, que en este caso serán cuatro. La distribución de las fases y
los intermedios es al azar, ya que como ocurría en la avenida anterior se desconoce el
orden de los mismos dentro del ciclo de funcionamiento.
Así pues, las señales a coordinar quedan del siguiente modo:
Figura 5.2-5 Señales que rigen la avenida Alfonso XII
129
Pruebas del sistema
Conocidas las señales se muestran los datos de velocidades y distancia que se
van a aplicar a la avenida a coordinar:
Tramos 1-2 2-3 3-4
Distancia (m) 220 210 312
Velocidad máxima outbound (m/s) 12.5 9.72 9.72
Velocidad máxima inbound (m/s) 12.5 9.72 9.72
Velocidad mínima outbound (m/s) 11.11 8.33 8.33
Velocidad mínima inbound (m/s) 11.11 8.33 8.33
Cambio velocidad máxima outbound (s/m) 0.03 0
Cambio velocidad máxima inbound (s/m) 0.03 0
Cambio velocidad mínima outbound (s/m) 0.023 0
Cambio velocidad mínima inbound (s/m) 0.023 0
Tabla 5.2-4 Límites de velocidad y distancia
El valor que se usa de la constante de proporcionalidad entre el ancho de banda
de entrada y salida es el de k = 1.
Con todos los datos disponibles se creará a través de nuestra aplicación el
programa lineal cuya solución permite coordina las señales de la avenida en cuestión. El
modelo propuesto por la aplicación es el siguiente:
130
Pruebas del sistema
Figura 5.2-6 Modelo lineal de coordinación de la avenida Alfonso XII
131
Pruebas del sistema
La resolución de este modelo genera unos resultados que se aprecian en la
siguiente tabla:
B1 B2 Z W11 W21 T11 M1 T21 W12 W22
0.2396 0.2396 0.0105 0.1772 0.1804 0.2090 1.0000 0.2090 0.0000 0.0000
T12 M2 T22 W13 W23 T13 M3 T23 W14 W24
0.2660 0.0000 0.2660 0.1271 0.1271 0.3951 1.0000 0.3951 0.0000 0.0000
Tabla 5.2-5 Solución del problema lineal de coordinación de la avenida Alfonso XII
Mediante la manipulación de estos resultados y la utilización de la fórmula que
proporciona el desfase que debe de haber entre una señal y otra para que el ancho de
banda de salida y entrada sea el obtenido, se obtienen los siguientes valores de interés:
Ciclo señales Ancho
banda
salida
Ancho
banda
entrada
Desfase
señales 1-2
Desfase
señales 1-3
Desfase
señales 1-4
94.7867 22.7099 22.7099 19.5033 39.3118 59.1203
Tabla 5.2-6 Datos de interés para la coordinación de esta avenida
Ya se puede mostrar el resultado gráfico que se genera como consecuencia de la
aplicación de los desfases a las señales luminosas de tráfico que regulan la avenida que
se ha coordinado:
132
Pruebas del sistema
Figura 5.2-7 Resultado gráfico de la coordinación de la avenida Alfonso XII en la
dirección outbound
Se comprueba que para este caso un vehículo no es capaz de atravesar la avenida
en un solo ciclo de las señales, si no que cuando llega a la cuarta señal ya se encuentra
en el segundo ciclo de la misma. Sin embargo, atraviesa la avenida sin detenerse ya que
alcanza la cuarta señal en el tiempo en verde de su segundo ciclo.
133
Conclusiones y extensiones
6 Conclusiones y extensiones
Es este capítulo se realiza un resumen del trabajo realizado en el proyecto,
comentando las principales conclusiones a las que se ha llegado y proponiendo posibles
extensiones al trabajo realizado.
6.1 Conclusiones
El objetivo del trabajo consistía en desarrollar una aplicación capaz de coordinar
las señales semafóricas que rigen la circulación de vehículos en una avenida.
Se ha podido comprobar que la coordinación de señales haciendo uso del
modelo de coordinación de maximización del ancho de banda verde, depende mucho de
los límites impuestos en las variables. De esta forma, para limitar el valor del tiempo de
ciclo se ha usado para el límite inferior el valor del ciclo de la señal con dicho valor más
bajo, y para el superior el resultado de la suma del valor del ciclo de la señal con dicho
valor más alto y el tiempo que tarda un vehículo en atravesar la avenida. Hay que
comentar que para calcular el tiempo que tarda un vehículo en atravesar la avenida se
han usado los límites inferiores de velocidad para cada tramo.
En principio se pueden coordinar el número de señales que el usuario desee, sin
embargo, cuanto mayor es ese número, mayor es la complejidad del problema y más
difícil resulta encontrar una solución óptima al mismo. Por lo tanto, se puede decir que
más de cuatro señales resulta casi imposible coordinarlas.
Una limitación que presenta el modelo es la imposibilidad de coordinar en
ambas direcciones una avenida irregular, es decir, una en la cual las distancias entre los
dispositivos reguladores de tráfico son distintas para cada dirección de la avenida.
En el caso de que las señales a coordinar presenten distinto ciclo, cabe comentar,
que para aquellas cuyo ciclo es inferior al proporcionado en la solución como óptimo, se
repite su ciclo hasta alcanzar el valor de dicho ciclo. Mientras que para aquellas señales
cuyo ciclo es superior al óptimo, se le reduce un tanto por ciento equitativo entre sus
distintas fases.
134
Conclusiones y extensiones
La principal novedad que presenta el modelo usado para la coordinación, es la
posibilidad que éste ofrece de dar mayor prioridad a un sentido de circulación sobre el
otro. Es decir, al coordinar dicho modelo en ambas direcciones de la avenida se puede
elegir que dirección permitirá el paso de un número mayor de vehículos sin detenerse
ante ninguna señal reguladora de tráfico. Esta particularidad, se consigue mediante el
valor que se le asigna al parámetro K, de forma, que si éste es mayor que uno los
vehículos que circulan en la dirección marcada como inbound dispondrán de mayor
tiempo para cruzar la avenida sin detenerse, mientras que si es menor que uno serán
aquellos que circulan en la dirección marcada como outbound los que dispongan de más
tiempo.
En el capítulo 1 se realizó una breve introducción sobre la coordinación de
señales semafóricas y los sistemas inteligentes de transporte. Además, se habló de los
objetivos del proyecto y se describió tanto el viario como las cajas semafóricas.
En el capitulo 2 se explicaron tres de los modelos de maximización de ancho de
banda verde más importantes en la actualidad, donde uno de ellos ha sido el usado para
desarrollar la aplicación.
El capítulo 3 comprende el modelado orientado a objetos de los algoritmos
diseñados e implementados. En concreto, se han incluido y documentado los diagramas
pertenecientes a UML (Unified Modelling Language) que sirven para la especificación
de dichos procesos.
El capítulo 4 incluye la descripción de los aspectos más importantes de la
aplicación mediante el uso de diagramas de flujo, así como una descripción de los
interfaces diseñados para la misma.
El capítulo 5 muestra las pruebas realizadas sobre el programa diseñado con el
fin de mostrar su correcto funcionamiento.
Se ha desarrollado una interfaz gráfica que permite al usuario seleccionar de
forma clara y sencilla una avenida de un escenario real y coordinar las señales
135
Conclusiones y extensiones
semafóricas que rigen a la misma. Además permite al usuario la gestión de la asociación
de cajas semafóricas a nodos del escenario.
6.2 Posibles extensiones
Entre las posibles extensiones, cabe destacar la que tiene en cuenta, para la
coordinación de las señales, los flujos de tráfico procedentes de las calles
perpendiculares a la avenida a coordinar. Para tener en cuenta estos flujos, se puede
desarrollar otro modelo de coordinación visto en el capítulo 3, modelo multi-banda, en
el que los anchos de banda de los distintos tramos de la avenida tienen un tamaño
distinto.
También se puede considerar el hecho de darle la posibilidad al usuario de elegir
entre varios métodos de coordinación, con el fin de que el usuario pueda seleccionar la
complejidad del problema, lo que supone obtener una solución más o menos factible a
la realidad del tráfico actual.
Por último, otra de las posibles extensiones es la de dar al usuario la posibilidad
de elegir como se calculará el tiempo que tarda un vehículo en atravesar la avenida.
Como se explicó anteriormente, esto se usaba para calcular el límite superior del tiempo
de ciclo que tendrán las señales coordinadas. En nuestra aplicación se usa el límite
inferior de la velocidad que puede desarrollar el vehículo en cada tramo para atravesar
la avenida sin detenerse, que es la opción más conservadora de entre las posibles, sin
embargo, en la extensión se podría permitir elegir entre usar el límite inferior, el límite
superior, o bien la media entre ambos límites. Con esto se conseguiría ajustar en mayor
o menor medida el tamaño que ha de tener el ciclo de las señales para obtener un ancho
de banda verde máximo.
136
Bibliografía
7 BIBLIOGRAFÍA
James Rumbaugh, Ivar Jacobson, Grady Booch. El lenguaje unificado de
modelado, manual de referencia. Addison Wesley.
Grady Booch, James Rumbaugh, Ivar Jacobson. El lenguaje unificado de
modelado. Addison Wesley.
Francisco Charte. Programación en Builder C++. Editorial Anaya.
Nathan H. Gartnert, Susan F. Assmannt, Fernando Lasaga, and Dennis L. Hout.
A multi-band approach to arterial traffic signa optimisation. Department of Civl
Engineering and Department of Mathematics, University of Lowell, Lowell, MA
01854, U.S.A.
Chang E.C.P. (1988) Program for optimizing left turn phase sequence in multi-
arterial closed networks. Transpn. Res. Rec., 1181, 61-67.
Chang E.C.P., Messer C.J. and Cohen S.L. (1986) Directional weighting for
maximal bandwidth arterial signal optimization programd. Transpn. Res. Rec.,
1057, 10-19.
Cohen S.L. (1983) Concurrent use of MAXBAND and TRANSYT signal timing
programs for arterial signal optimization. Transpn. Res. Rec., 906, 81-84.
Cohen S.L. and Liu C.C. (1986) The bandwidth-constrained TRANSYT signal-
optimization program. Transpn. Res. Rec., 1057, 1-7.
Federal Highway Administration (FHWA) (1980) Traffic Network Analysis with
NETSIM. Implementation Package FHWA-IP-80-3, U.S. Dept. of Transportation,
Washington, D.C.
137
Bibliografía
Gartner N.H., Assman S.F., Lasaga F., and Hou D. (1989) Multiband Arterial
Progression: A New Desing Scheme for Arterial Traffic Signal Control. Report
prepared for Massachusetts Department of Public Works. Research Foundation,
University of Lowell, Lowell, MA, January 1989.
Hisai M. (1987) Delay-minimizing control and bandwidth-maximizing control of
coordinated traffic signals by dynamic programming. In Transportation and Traffic
Theory ( Edited by N.H. Gartner and N.H.M. Wilson). Elsevier, NY.
Jhon D. C. Little. The synchronization of traffic signals by mixed-integer linear
programming. Massachusetts Institute of Technology, Cambridge, Massachusetts.
138