Sistema para Cruzamientos de Trenes
-
Upload
hernan-torrez -
Category
Documents
-
view
42 -
download
4
description
Transcript of Sistema para Cruzamientos de Trenes
SISTEMA PARA OPTIMIZACION
DE CRUZAMIENTOS DE TRENES
HERNAN TORREZ V.
Santa Cruz – Bolivia
Abril 2008
INDICE DE CONTENIDO
INDICE DE CONTENIDO ................................................................................... 2
INDICE DE FIGURAS ........................................................................................ 6
PARTE I: EL ENTORNO DEL PROYECTO ...................................................... 9
CAPITULO 1: ANTECEDENTES ......................................................................... 11
1.1.- ANTECEDENTES ....................................................................................... 11
1.1.1- Hitos Históricos ........................................................................................ 11
1.1.2.- Antecedentes en Estados Unidos............................................................. 13
1.1.3.- Antecedentes en el continente Africano .................................................. 14
1.1.4.- Antecedentes en Australia ....................................................................... 14
1.1.5.- Antecedentes en el continente Asiático ................................................... 15
1.1.6.- Antecedentes en América Latina............................................................. 15
1.1.7.- Antecedentes en Bolivia .......................................................................... 16
1.1.8.- Antecedentes en el Oriente Boliviano ..................................................... 18
1.2.- ACTUALIDAD ............................................................................................. 18
1.2.1.- Nuevas formas de Energía....................................................................... 19
1.2.2.- Trenes de Alta Velocidad ........................................................................ 19
1.2.3.- Transporte Intermodal ............................................................................. 20
1.3.- FERROVIARIA ORIENTAL S.A. ............................................................. 22
1.3.1.- Misión ..................................................................................................... 24
1.3.2.- Visión ...................................................................................................... 24
1.3.3.- Objetivos Estratégicos ............................................................................. 25
1.3.4.- Servicios .................................................................................................. 25
1.3.5.- Cifras y Datos de la Gestión 2005 ........................................................... 27
1.3.6.- Responsabilidad Social ........................................................................... 28
CAPITULO 2: OBJETIVOS DEL PROYECTO .................................................. 34
2.1.- DESCRIPCION DEL PROBLEMA Y JUSTIFICACION ...................... 34
2.1.1.- Planeamiento de Cruzamientos de Trenes .............................................. 34
2.2.- OBJETIVOS DEL PROYECTO ................................................................ 40
2.2.1.- Objetivo General ..................................................................................... 40
2.2.2.- Objetivos Específicos .............................................................................. 40
2.3.- ALCANCE DEL PROYECTO ................................................................... 41
2.3.1.- Cruzamiento de Trenes............................................................................ 41
Indice de Contenidos
2.3.2.- Salida de Trenes ...................................................................................... 41
2.3.3.- Elaboración de Surcos ............................................................................. 41
PARTE II: MARCO TEORICO Y METODOLOGICO ....................................... 42
CAPITULO 3: EL FERROCARRIL ...................................................................... 43
3.1.- TRENES ........................................................................................................ 43
3.1.1.- Locomotoras o Material Tractivo ............................................................ 44
3.1.2.- Material Rodante ..................................................................................... 44
3.2.- ESTACIONES .............................................................................................. 45
3.2.1.- Tipos de Estaciones ................................................................................. 46
3.3.- VIAS FERREAS ........................................................................................... 48
3.3.1.- Elementos de la Infraestructura ............................................................... 48
3.3.2.- Tipos de Vía ............................................................................................ 54
CAPITULO 4: RESOLUCION DE PROBLEMAS MEDIANTE TECNICAS
HEURISTICAS ......................................................................................................... 56
4.1.- RESOLUCION DE UN PROBLEMA MEDIANTE BUSQUEDA
HEURISTICA ....................................................................................................... 57
4.1.1.- Elementos de un Problema de Búsqueda ................................................ 57
4.1.2.- Modelización ........................................................................................... 58
4.1.3.- Problemas Multimodales ......................................................................... 58
4.1.4.- Problemas con Restricciones ................................................................... 59
4.2.- METODO DE BUSQUEDA: BUSQUEDA EXHAUSTIVA .................... 60
4.3.- PROBLEMA DE ENCONTRAR LA RUTA MÁS CORTA DE UNA
CIUDAD A OTRA ................................................................................................ 61
4.3.1.- Elementos del Problema .......................................................................... 61
4.3.2.- Solución Mediante Búsqueda Exhaustiva y Backtracking ...................... 62
4.4.- PROBLEMA DE CRUZAMIENTO DE TRENES ................................... 64
CAPITULO 5: EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE
.................................................................................................................................... 68
5.1.- DEFINICION DEL PROCESO UNIFICADO .......................................... 69
5.2.- FASES Y FLUJOS DE TRABAJO ............................................................ 73
Indice de Contenidos
PARTE III: DESARROLLO DEL PROYECTO ................................................. 85
CAPITULO 6: MODELO DEL NEGOCIO Y CAPTURA DE REQUISITOS . 86
6.1.- MODELO DEL NEGOCIO ........................................................................ 86
6.1.1.- Modelo de Casos de Uso del Negocio .................................................... 87
6.1.2.- Modelo de Objetos del Negocio .............................................................. 87
6.2.- CAPTURA DE REQUISITOS COMO CASOS DE USO ........................ 93
6.2.1.- Identificación y Especificación de Actores ............................................. 93
6.2.2.- Identificación de Casos de Uso ............................................................... 94
6.2.3.- Priorización de Casos de Uso .................................................................. 94
6.2.4.- Especificación de Casos de Uso .............................................................. 95
6.2.5.- Diagrama General de Casos de Uso ...................................................... 101
CAPITULO 7: ANALISIS DEL PROYECTO .................................................... 102
7.1.- ANALISIS DE LA ARQUITECTURA .................................................... 102
7.2.- ANALISIS DE CASOS DE USO .............................................................. 103
7.3.- ANALISIS DE CLASES ............................................................................ 110
7.3.1.- Clases de Interfaz .................................................................................. 110
7.3.2.- Clases de Control .................................................................................. 113
7.3.3.- Clases de Entidad .................................................................................. 116
7.4.- ANALISIS DE PAQUETES ...................................................................... 117
7.4.1.- Dependencia entre Paquetes .................................................................. 117
7.4.2.- Diagramas de Clases por Paquete ......................................................... 118
CAPITULO 8: DISEÑO DEL PROYECTO ....................................................... 121
8.1.- DISEÑO DE LA ARQUITECTURA ....................................................... 121
8.1.1.- Identificación de Nodos y Componentes .............................................. 121
8.2.- DISEÑO DE CASOS DE USO .................................................................. 122
8.3.- DIAGRAMAS DE CLASES ...................................................................... 129
8.4.- DISEÑO DE DATOS ................................................................................. 135
CAPITULO 9: IMPLEMENTACION Y PRUEBAS DEL PROYECTO ......... 140
9.2.- TRANSFORMACION DE LOS MODELOS DE DISEÑO ................... 142
Indice de Contenidos
9.3.- IDENTIFICACIÓN DE LOS COMPONENTES.................................... 142
9.3.1.- Componentes a partir de la clase Tren .................................................. 142
9.3.2.- Componentes a partir de la clase TrenEnTransito ................................ 143
9.3.3.- Componentes a partir de la clase Recorrido .......................................... 146
9.3.4.- Componentes a partir de la clase Estacion ............................................ 146
9.3.5.- Componentes a partir de la clase EstadoTransito.................................. 147
9.3.6.- Componentes a partir de la clase Motor ................................................ 154
9.3.7.- Componentes a partir de la clase Cruzamiento ..................................... 156
9.3.8.- Componentes a partir de la clase Paso .................................................. 156
9.3.9.- Componentes a partir de la clase Solucion............................................ 157
9.3.10.- Componentes a partir de la clase Server ............................................. 158
9.3.11.- Componentes a partir de la clase Simulacion ..................................... 158
9.3.12.- Componentes a partir de la clase Graficador ...................................... 159
9.3.13.- Componentes a partir de la clase Service ............................................ 160
9.4.- IDENTIFICACIÓN DE SUBSISTEMAS DE IMPLEMENTACION .. 161
9.4.1.- Subsistema Trenes ................................................................................. 161
9.4.2.- Subsistema Heurística ........................................................................... 162
9.4.3.- Subsistema Remoting ............................................................................ 162
9.4.4.- Subsistema ClienteT .............................................................................. 162
9.4.5.- Subsistema TrafService ......................................................................... 163
9.5.- PLANIFICACION DE LAS PRUEBAS .................................................. 163
9.6.- PRUEBAS DE UNIDAD ............................................................................ 163
9.7.- PRUEBAS DE INTEGRACION .............................................................. 164
9.8.- PRUEBAS DE SISTEMA .......................................................................... 164
CONCLUSIONES .......................................................................................... 165
FUENTES DE INFORMACION ...................................................................... 166
ANEXO A: PANTALLAS DEL SISTEMA ...................................................... 170
INDICE DE FIGURAS
Figura 1.1: Locomotora construída por George Stephenson en 1825 ....................................................... 12 Figura 1.2: Tren de Gran Velocidad Francés ............................................................................................ 20 Figura 1.3: Ruta cubierta por la Empresa Ferroviaria Oriental ............................................................... 22 Figura 1.4: Vagones para transporte de productos químicos pertenecientes a la empresa Ferroviaria
Oriental ...................................................................................................................................................... 23 Figura 1.5: Trenes en la Terminal Ferroviaria de Puerto Quijarro .......................................................... 23 Figura 1.6: Locomotora con vagones de carga de la empresa Ferroviaria Oriental ................................ 24 Figura 1.7: Ferrobús perteneciente a la empresa Ferroviaria Oriental .................................................... 27 Figura 1.8: Niños aprendiendo con el Tren de Vida .................................................................................. 29 Figura 1.9: Revista “Sobre Rieles” ........................................................................................................... 30 Figura 1.10: Mapa Ferroviario elaborado por la empresa Ferroviaria Oriental ..................................... 31 Figura 1.11: Vagón-Tanque acondicionado para el transporte de agua ................................................... 32 Figura 2.1: Cruzamiento de trenes............................................................................................................. 35 Figura 2.2: Puesto de Control de Trenes de la Empresa Ferroviaria Oriental ......................................... 36 Figura 2.3: Gráfico de Regulación de Trenes ............................................................................................ 37 Figura 2.4: Estación Ferroviaria de Cotoca .............................................................................................. 38 Figura 2.5: Estación Ferroviaria de San José ........................................................................................... 38 Figura 3.1: Vagón jaula para el transporte de ganado ............................................................................. 45 Figura 3.2: Vagón para transporte de contenedores perteneciente a Ferroviaria Oriental ...................... 45 Figura 3.3: Disposición de una estación de pasajeros .............................................................................. 46 Figura 3.4: Estación de paso para pasajeros ............................................................................................ 47 Figura 3.5: Vía Férrea, sector Este ........................................................................................................... 48 Figura 3.10: Riel utilizada por Ferroviaria Oriental................................................................................. 49 Figura 3.6: Antiguos rieles de vientre de pez ............................................................................................. 50 Figura 3.7: Riel de tipo Vignol ................................................................................................................... 50 Figura 3.8: Acopio de Balasto ................................................................................................................... 51 Figura 3.9: Vía Férrea con durmientes de hormigón ................................................................................ 52 Figura 3.10: Tirafondo: utilizado para la sujeción de la vía ..................................................................... 52 Figura 3.11: Aparatos de vía (Sapo) .......................................................................................................... 53 Figura 3.12: Semáforo para desvío ............................................................................................................ 53 Figura 3.13: Ancho de Vía ......................................................................................................................... 54 Figura 4.1: Problema de determinación de ruta ........................................................................................ 61 Figura 4.2: Primer solución hallada siguiendo los nodos cuyo costo de ruta sea meno ........................... 62 Figura 4.3: Después de explorar todos los nodos, se da con la solución óptima ...................................... 63 Figura 4.4: Proyección de Cruzamientos entre dos trenes ........................................................................ 64 Figura 4.5: El ferrobús espera en la primera estación al tren de pasajeros ............................................. 65 Figura 4.6: El tren de pasajeros espera en la segunda estación al ferrobús ............................................. 66 Figura 5.1: Elementos de los Casos de Uso ............................................................................................... 70 Figura 5.2: Fases o flujos de iteración ...................................................................................................... 73 Figura 5.3: Porcentajes de duración y esfuerzo típicos necesarios ........................................................... 79 Figura 5.4: Flujos de Trabajo Fundamentales .......................................................................................... 80 Figura 6.1: Modelo de Casos de Uso del Negocio ..................................................................................... 87 Figura 6.2: Diagrama de Actividades: Graficar Recorrido ....................................................................... 88 Figura 6.3: Diagrama de Actividades: Realizar Proyección ..................................................................... 90 Figura 6.4: Diagrama de Actividades: Determinar Horario de Salida ..................................................... 90 Figura 6.5: Diagrama de Actividades: Elaborar Surcos de Trenes ........................................................... 91 Figura 6.6: Diagrama de Actividades: Consultar Horario de Llegada de tren a estación ........................ 92 Figura 6.7: Priorización de Casos de Uso ................................................................................................. 95 Figura 6.8: Caso de Uso: Realizar Proyección ......................................................................................... 96
Indice de Figuras
Figura 6.9: Caso de Uso: Determinar Horario de Salida ......................................................................... 97 Figura 6.10: Caso de Uso: Elaborar Surcos de Trenes ............................................................................. 98 Figura 6.11: Caso de Uso: Consultar Hora de Llegada de trenes a estaciones ........................................ 99 Figura 6.12: Caso de Uso: Graficar Recorrido ....................................................................................... 100 Figura 6.13: Diagrama de Paquetes ........................................................................................................ 101 Figura 7.1: Diagrama de Paquetes .......................................................................................................... 102 Figura 7.2: Diagrama de Colaboración: Realizar Proyección ................................................................ 104 Figura 7.3: Diagrama de Colaboración: Determinar Horario de Salida ................................................ 105 Figura 7.4: Diagrama de Colaboración: Elaborar Surcos de Trenes ..................................................... 106 Figura 7.5: Diagrama de Colaboración: Consultar Hora de Llegada de trenes a estaciones ................ 107 Figura 7.6: Diagrama de Colaboración: Graficar Recorrido ................................................................. 108 Figura 7.7: Diagrama de Colaboración: Resolver Simulación ............................................................... 109 Figura 7.8: Análisis de la clase FrmMain................................................................................................ 110 Figura 7.9: Análisis de la clase FrmElegirTren ...................................................................................... 111 Figura 7.10: Análisis de la clase FrmNewSimSimpl ................................................................................ 111 Figura 7.11: Análisis de la clase FrmNewtrenHVar ................................................................................ 112 Figura 7.12: Análisis de la clase Server .................................................................................................. 113 Figura 7.13: Análisis de la clase Simulacion ........................................................................................... 113 Figura 7.14: Análisis de la clase Motor ................................................................................................... 114 Figura 7.15: Análisis de la clase EstadoTransito .................................................................................... 114 Figura 7.16: Análisis de la clase TrenEnTransito ................................................................................... 115 Figura 7.17: Análisis de la clase Cruzamiento ........................................................................................ 115 Figura 7.18: Análisis de la clase Paso ..................................................................................................... 116 Figura 7.19: Análisis de la clase BRecorrido .......................................................................................... 116 Figura 7.20: Diagrama de Dependencia entre Paquetes ......................................................................... 117 Figura 7.21: Diagrama de Clases por Paquete. Paquete: Trenes ........................................................... 118 Figura 7.22: Diagrama de Clases por Paquete. Paquete: Remoting ....................................................... 119 Figura 7.23: Diagrama de Clases por Paquete. Paquete: Heurística ..................................................... 119 Figura 7.24: Diagrama de Clases por Paquete. Paquete: Gráficos ........................................................ 119 Figura 7.25: Diagrama de Clases por Paquete. Paquete: Forms ............................................................ 120 Figura 7.26: Diagrama de Clases por Paquete. Paquete: TrafService .................................................... 120 Figura 8.1: Diagrama de Despliegue ....................................................................................................... 122 Figura 8.2: Diagrama de Secuencia: Realizar Proyección...................................................................... 123 Figura 8.3: Diagrama de Secuencia: Determinar Horario de Salida ...................................................... 124 Figura 8.4: Diagrama de Secuencia: Elaborar Surcos de Trenes ........................................................... 125 Figura 8.5: Diagrama de Secuencia: Consultar Hora de Llegada de trenes a estaciones ...................... 126 Figura 8.6: Diagrama de Secuencia: Graficar Recorrido ....................................................................... 127 Figura 8.7: Diagrama de Secuencia: Resolver Simulación ..................................................................... 128 Figura 8.8: Diagrama de Clases: Paquete Trenes ................................................................................... 130 Figura 8.9: Diagrama de Clases: Paquete Heurística ............................................................................. 131 Figura 8.10: Diagrama de Clases: Paquete Remoting ............................................................................ 132 Figura 8.11: Diagrama de Clases: Paquete Forms ................................................................................. 133 Figura 8.12: Diagrama de Clases: Paquete Gráficos .............................................................................. 134 Figura 8.13: Diagrama de Clases: Paquete TrafService ......................................................................... 134 Figura 8.14: Diseño de Datos. Tabla: TTren ........................................................................................... 135 Figura 8.15: Diseño de Datos. Tabla: TEstacion .................................................................................... 136 Figura 8.16: Diseño de Datos. Tabla: TTren_Tipos ................................................................................ 136 Figura 8.17: Diseño de Datos. Tabla: TItinerario ................................................................................... 137 Figura 8.18: Diseño de Datos. Tabla: TItinerario_Estacion ................................................................... 137 Figura 8.19: Diseño de Datos. Tabla: TBoletin_Tren ............................................................................. 138 Figura 8.20: Diseño de Datos. Tabla: TBoletin_Recorrido ..................................................................... 139 Figura 9.1: Identificación de componentes a partir de la clase Tren ...................................................... 143 Figura 9.2: Identificación de componentes a partir de la clase TrenEnTransito .................................... 144 Figura 9.3: Segmento de código dentro de TrenEnTransito, método AvanzarSgteEstacion ................... 145
Indice de Figuras
Figura 9.4: Identificación de componentes a partir de la clase Recorrido .............................................. 146 Figura 9.5: Identificación de componentes a partir de la clase Estacion ................................................ 147 Figura 9.6: Identificación de componentes a partir de la clase EstadoTransito ..................................... 148 Figura 9.7: Segmento de código dentro de EstadoTransito, método GetSgteCruzamiento ..................... 150 Figura 9.8: Segmento de código dentro de EstadoTransito, método AvanzarHastaCruzar .................... 153 Figura 9.9: Identificación de componentes a partir de la clase Motor .................................................... 154 Figura 9.10: Método GetSolution dentro del componente Motor.cs ........................................................ 155 Figura 9.11: Identificación de componentes a partir de la clase Cruzamiento ....................................... 156 Figura 9.12: Identificación de componentes a partir de la clase Paso .................................................... 157 Figura 9.13: Identificación de componentes a partir de la clase Solucion .............................................. 157 Figura 9.14: Identificación de componentes a partir de la clase Server ................................................. 158 Figura 9.15: Identificación de componentes a partir de la clase Simulacion .......................................... 159 Figura 9.16: Identificación de componentes a partir de la clase Graficador .......................................... 160 Figura 9.17: Identificación de componentes a partir de la clase Service ................................................ 161 Figura 9.18: Identificación del subsistema Trenes .................................................................................. 161 Figura 9.19: Identificación del subsistema Heuristica ............................................................................ 162 Figura 9.20: Identificación del subsistema Remoting .............................................................................. 162 Figura 9.21: Identificación del subsistema ClienteT................................................................................ 162 Figura 9.22: Identificación del subsistema TrafService ........................................................................... 163 i. Pantalla con Simulación Realizada sobre el Tráfico Actual de Trenes .......................................... 170 ii. Pantalla Para Añadir/Editar Trenes de una Simulación ................................................................ 171 iii. Pantalla con Información de Cruzamientos y Pasos de Trenes de una Simulación ....................... 172 iv. Pantalla con Ampliación Realizada al Gráfico de una Simulación ................................................ 173
PARTE I
EL ENTORNO DEL
PROYECTO
Compitiendo con medios de transporte más modernos, el transporte por ferrocarril
debe usar sus recursos materiales y humanos con eficiencia y para lograrlo debe hacer uso
de las nuevas tecnologías y las facilidades que éstas brindan.
11
CAPITULO 1
ANTECEDENTES
ara una mejor comprensión de las funciones de la empresa, repasaremos brevemente
los hechos históricos que dieron origen al ferrocarril y la incursión de éste en
diferentes regiones del mundo.
1.1.- ANTECEDENTES
A continuación, diversos hitos históricos que dieron inicio al ferrocarril.
1.1.1- Hitos Históricos
El primer transporte de viajeros sobre "carriles de hierro" se realizó en 1801 con
vagones tirados por caballos, entre las localidades inglesas de Wandsworth y
Croydon.
Los dos principios mecánicos, guiado de ruedas y uso de fuerza motriz, fueron
combinados por primera vez por el ingeniero de minas inglés Richard Trevithick,
quien el 24 de febrero de 1804 logró adaptar la máquina de vapor,
P
Capítulo 1: Antecedentes
12
que se utilizaba desde principios del siglo XVIII para bombear agua, para que tirara
de una locomotora que hizo circular a una velocidad de 8 Km. por hora arrastrando
cinco vagones, cargados con 10 t de acero y 70 hombres sobre una vía de 15 Km. de
longitud de la fundición de Pen-y-Darren, en el sur de Gales.
Transcurrieron dos décadas durante las cuales se desarrollaron los raíles de hierro
fundido que soportaban el peso de una locomotora de vapor. La potencia necesaria
para arrastrar trenes, en lugar de uno o dos vagones, se aseguró colocando una
locomotora de vapor sobre dos o más ejes con las ruedas unidas mediante bielas.
La primer vía férrea pública del mundo, la línea Stockton-Darlington, en el noreste
de Inglaterra, dirigida por George Stephenson (considerado el padre del ferrocarril
moderno por las investigaciones que realizó, junto con su hijo Robert), se inauguró
en 1825. Durante algunos años esta vía sólo transportó carga; en ocasiones también
utilizaba caballos como fuerza motora. Ver Figura 1.1
Figura 1.1: Locomotora construída por George Stephenson en 1825.
Fuente: [TODOTRENES]
Capítulo 1: Antecedentes
13
La primera vía férrea pública para el transporte de pasajeros y de carga que
funcionaba exclusivamente con locomotoras de vapor, fue la de Liverpool-
Manchester, inaugurada en 1830. También fue dirigida por George Stephenson, en
esta ocasión con ayuda de su hijo Robert Stephenson.
El éxito comercial, económico y técnico de la línea Liverpool-Manchester
transformó el concepto de vías férreas, y no sólo en Gran Bretaña. Algo que antes se
veía como medio para cubrir recorridos cortos, beneficioso sobre todo para la
minería, se consideraba ahora capaz de revolucionar el transporte de largo recorrido,
tanto de pasajeros como de mercancías. Se había pensado que cualquiera podría,
previo pago de un peaje, poner un tren sobre las vías férreas, igual que se hacía con
los barcos en los canales; pero el volumen de tráfico entre Liverpool y Manchester
pronto demostró que el uso de una vía fija debía controlarse desde una central y que
era preciso mantener una distancia segura entre los trenes mediante algún sistema de
señalización.
En 1914 ya existía casi, excepto en Escandinavia, la red de vías férreas que hoy
tiene Europa, una vez terminados los túneles de la gran vía transalpina: el Mount
Cenis (o Frejus) entre Francia e Italia en 1871, el San Gotardo en Suiza en 1881, el
Alberg en Austria en 1883 y en Suiza también el Simplon en 1906 y el Lotschberg
en 1913. [TODOTRENES]
1.1.2.- Antecedentes en Estados Unidos
En Estados Unidos el desarrollo del ferrocarril se vio iniciado por el deseo de llegar
al interior del país desde las ciudades de la costa este, fundadas por los primeros
colonos británicos. Tras la inauguración en 1830, en Charleston, Carolina del Sur,
del primer ferrocarril de vapor para pasajeros, la construcción de vías férreas pronto
avanzó hacia el oeste desde todos los rincones de la costa este.
En 1850 el continente tenía ya 14.500 Km. de vías férreas. En la década siguiente un
número cada vez mayor de empresas privadas construyó más vías férreas que en el
Capítulo 1: Antecedentes
14
resto del mundo, con lo que el total de Estados Unidos pasó a más de 48.300 Km.;
Chicago, en el Medio Oeste, convertido de pequeña población a gran ciudad, fue la
plataforma de una rápida expansión hacia el sur y el oeste.
La idea de enlazar el este de los Estados Unidos con la costa del Pacífico, se vio
fomentada por los pioneros establecidos en la costa oeste que decidieron a su vez
iniciar la construcción del ferrocarril hacia el este, convirtiéndose la empresa de
ambos tendidos en una carrera por conseguir el mayor número de kilómetros hasta
el punto de encuentro, lo que convirtió la construcción del ferrocarril en una gesta
más que en una obra de ingeniería. Diez mil obreros de la Union Pacific salen en
diciembre de 1865 de Omaha al encuentro de los doce mil de la Central Pacific que
partieron en enero de 1863 de Sacramento. El encuentro tuvo lugar el 10 de mayo de
1869 en Promontory Point. [TODOTRENES]
1.1.3.- Antecedentes en el continente Africano
Las primeras vías férreas cortas de África fueron construidas entre 1860 y 1870 por
las diversas potencias coloniales del continente para facilitar la explotación de los
recursos minerales. Los grandes desarrollos se produjeron a partir de 1880, cuando
el estadista y financiero británico Cecil Rhodes, previendo el potencial del
ferrocarril para fomentar el comercio en el continente, trató de tender una vía férrea
desde Ciudad del Cabo, en Sudáfrica, hasta un enlace con la recién terminada vía
férrea de El Cairo-Suez, en Egipto. El proyecto sólo llegó hasta el Congo Belga
(hoy Zaire), unos treinta años después, pero estimuló la construcción de otras líneas
troncales en el interior. [TODOTRENES]
1.1.4.- Antecedentes en Australia
En Australia no se adoptó un ancho común, sino que las concesiones se repartieron
en vía estrecha y ancha, con lo que después fue necesaria una amplia y costosa
conversión para establecer una ruta básica interprovincial para cargas de 1.435 mm.
de ancho y eliminar los lentos transbordos. La construcción del ferrocarril
Capítulo 1: Antecedentes
15
australiano comenzó en serio a partir de 1870, porque la corriente de emigrantes que
hizo pasar la población del país de 400.000 personas en 1850 a más de 3,25
millones en 1890 exigía un mejor transporte para llegar al interior del país. En los
últimos treinta años del siglo XIX, la longitud de los ferrocarriles australianos pasó
de apenas 1.600 Km. a unos 19.300 Km. [TODOTRENES]
1.1.5.- Antecedentes en el continente Asiático
La red de ferrocarriles mejor organizada de toda Asia surgió en la India, donde a
principios de la década de 1850 un previsor Gobernador General británico, Lord
Dalhousie, promovió la rápida construcción de líneas troncales que llegaban al
interior desde los puertos. La primera línea de costa a costa de la India, desde
Bombay hasta Calcuta, se terminó en 1870. Con el estímulo de las prósperas
agricultura e industria indias, en 1913 el país había conseguido 56.300 Km. de
ferrocarril, mucho más por kilómetro cuadrado que Australia o África.
Japón, hostil a toda influencia extranjera durante el régimen feudal de los samuráis,
cambió de golpe cuando el emperador recuperó su poder en 1867 y pidió ayuda a
Occidente para iniciar la construcción de las vías férreas en el último cuarto del
siglo XIX.
En China, fue la derrota sufrida a manos japonesas en 1895 lo que la empujó a
iniciar el tendido de sus líneas troncales. [TODOTRENES]
1.1.6.- Antecedentes en América Latina
La primera línea ferroviaria fue la de La Habana-Güines que con una longitud de 90
Km. fue inaugurada el 10 de noviembre de 1837, al ser Cuba en ese entonces
provincia española de ultramar, también se la considera la primer línea ferroviaria
española.
El siguiente ferrocarril se inauguró el 15 de septiembre de 1850 en México. Se
trataba de un tramo de menos de 20 Km. que unía el puerto de Veracruz con la
Capítulo 1: Antecedentes
16
vecina población de San Juan. Más tarde, en 1873, se completó la línea que unía el
famoso puerto con la capital del país.
El primer ferrocarril en Sudamérica, fue el de Caldera a Copiapó, en Chile,
construido el año 1852.
Las inversiones importantes para el desarrollo de las redes ferroviarias en América
Latina se realizaron a través de concesiones que otorgaban los gobiernos en especial
a empresarios británicos y estadounidenses, como ocurrió en Argentina. En 1857 se
inauguró el primer ferrocarril de ese país con el propósito de enlazar los centros de
producción ganadera y minera con el puerto desde donde se exportaba la materia
prima a Europa y Estados Unidos.
En términos generales el inconveniente de los ferrocarriles en América Latina hasta
las primeras décadas del siglo XX fue que se desarrollaron en función del comercio
con el exterior, más que como una vía interna de comunicación. [TODO TRENES]
1.1.7.- Antecedentes en Bolivia
El primer tramo ferroviario en territorio boliviano, fue el de Mejillones a Caracoles,
inaugurado el 30 de enero de 1873, destruido por el terremoto del 9 de Mayo de
1877. La primera locomotora del malogrado ferrocarril tenía por nombre “La
Boliviana”. Otro proyecto para unir Antofagasta con El Carmen, fue inaugurado el
20 de diciembre de 1873, la locomotora llevó el nombre del presidente de Bolivia,
Dr. Tomás Frías. [SOBRERIELES, 2006]
El desarrollo de las carreteras en Bolivia data de 1945, con la construcción del
tramo Santa Cruz – Cochabamba y paralelamente se dio inicio al desarrollo del
transporte ferroviario en otras zonas del país.
El 06 de Octubre de 1964 mediante Decreto Supremo Nº 06909, se creó la
EMPRESA NACIONAL DE FERROCARRILES “ENFE”, en base a las líneas que
pertenecían a las empresas privadas: Ferrocarril Antofagasta - Bolivia (Sección
Capítulo 1: Antecedentes
17
Boliviana) y The Bolivian Railway Company y las que correspondían a los antiguos
ferrocarriles estatales, siendo el objetivo crear una sola unidad estatal de servicios
de transporte ferroviario. Inicialmente la empresa estuvo conformada por las líneas
andinas y posteriormente fueron incluidas las líneas del ferrocarril de la Red
Oriental, junto con su material rodante y tractivo, el cual data entre 1950 y 1985.
[INTRANET]
En 1996 el gobierno de Bolivia emprendió el proceso de capitalización de ENFE, en
ese momento la empresa tenía dos redes que no estaban unidas entre sí en territorio
boliviano:
i. La Red Occidental
Con 2.166 Km. un eje que corre de Norte a Sur desde la ciudad de La
Paz hasta Villazón en la frontera con Argentina, de este eje se
desprenden seis ramales:
FC. La Paz – Guaqui.
FC. Viacha - Charaña (La Paz -Arica).
FC. Uyuni – Antofagasta.
FC. Oruro-Cochabamba-Aiquile.
FC. Machamarca – Uncia.
FC. Rio Mulatos - Potosi - Sucre – Tarabuco.
ii. La Red Oriental
1.285 Km. tiene el epicentro en Santa Cruz de la que salen los tres
ramales:
FC. Santa Cruz – Yacuiba.
Capítulo 1: Antecedentes
18
FC. Santa Cruz – Quijarro.
FC. Santa Cruz - Santa Rosa – Yapacani.
1.1.8.- Antecedentes en el Oriente Boliviano
El desarrollo del ferrocarril en el Oriente Boliviano empezó con el tramo construido
entre Santa Cruz y Yacuiba en 1949 para transporte hacia los puertos del Atlántico a
través de Argentina. Después le siguieron el tramo entre Santa Cruz y Quijarro en
1958 para el transporte hacia los puertos del Atlántico en Brasil. [INTRANET]
En la década de los años 70 se dio inicio a la construcción del Ferrocarril Santa Cruz
– Puerto Busch, el cual solo fue concluido hasta Yapacaní siendo actualmente
operable solo hasta Montero, mismo que tenía por objeto principal lograr el
desarrollo a través de la integración amazónica. [INTRANET]
1.2.- ACTUALIDAD
En la actualidad el Ferrocarril trata de competir en comodidad y largo recorrido trata de
competir ya no con el automóvil sino con el avión.
Los avances en la suspensión en los engranajes y la supresión de las uniones de las vías
gracias a la técnica de la soldadura continua de los carriles hacen que los trenes de
pasajeros se deslicen con gran suavidad. Son comunes los vagones equipados con diversas
características que brindan una mejor experiencia a los pasajeros, como ser: aislamiento
acústico, aire acondicionado, música ambiental, servicios de telefonía, etc.
Entre otros de los cambios y mejoras más significativas que nos llevaron a los trenes
actuales podemos encontrar los que se mencionan a continuación.
Capítulo 1: Antecedentes
19
1.2.1.- Nuevas formas de Energía
Un inconveniente de la locomotora de vapor es la interrupción de servicio por las
paradas técnicas que impone su frecuente mantenimiento. Por esta causa y por la
fuerte competencia del transporte por carretera surgida en la segunda mitad del siglo
XX, el transporte por ferrocarril tuvo que reajustar sus costes, operación que se vio
favorecida con la utilización de nuevas energías como alternativa al vapor.
Así empieza la era de las locomotoras equipadas con motor diesel, que precisan
menor tiempo de mantenimiento y sobre todo las de tracción eléctrica, que pueden
funcionar sin descanso durante días. Con estas técnicas la explotación de una línea
llega al máximo rendimiento, al hacer los trenes mayor número de viajes con tiempo
mínimo de entretenimiento, lo que equivale a mantener las líneas con una máxima
ocupación. Este índice se ve más favorecido cuando el tren está remolcado por una
locomotora eléctrica que cuando lo está por una de vapor. Con este principio
económico, empezó la decadencia del vapor en favor del desarrollo del diesel y de
la electrificación de las líneas. [TODOTRENES]
1.2.2.- Trenes de Alta Velocidad
Desde la década del 60 se empezaron a desarrollar trenes de alta velocidad para
poder competir con el transporte aéreo y de carretera. Actualmente se utilizan trenes
con velocidad máxima del orden de los 300 km/h, y con velocidad promedio (o
velocidad comercial) también elevada.
Capítulo 1: Antecedentes
20
Figura 1.2: Tren de Gran Velocidad Francés
Por ejemplo, el TGV (Train à Grande Vitesse o tren a gran velocidad) de la Figura
1.2, desarrollado y operado por la compañía de ferrocarriles nacional francesa,
conecta París con otras ciudades de Francia y con países vecinos como el Reino
Unido, Suiza y Bélgica. El TGV es uno de los trenes convencionales en operación
más veloces del mundo. En condiciones especiales de prueba, alcanzó velocidades
de 515,3 km/h, un récord mundial en 1990. En servicio comercial, el TGV opera a
velocidades de hasta 320 km/h.
A finales del año 2005 el Gobierno de México anunció que durante el transcurso del
año 2006 licitarán la construcción del que sería el primer tren de alta velocidad en
Latinoamérica. El trayecto tendrá 600 km. de extensión y enlazará a Guadalajara
con la Ciudad de México. [TODOTRENES]
1.2.3.- Transporte Intermodal
Para llenar un tren se necesita un volumen grande de productos. Sólo cuando se
dispone de carga suficiente en volumen y frecuencia para llenar uno que vaya desde
la estación de origen sin paradas hasta la estación de destino, el ferrocarril muestra
su poder competitivo. Así surgen los llamados trenes completos dedicados al
Capítulo 1: Antecedentes
21
transporte de mineral, carburantes, automóviles u otros productos, o los recientes
trenes postales.
Siguiendo esta línea de llenar un tren a base de paquetería se concibe el transporte
intermodal o mixto, desarrollado a partir de la creación del contenedor, un envase
metálico modulado de un tamaño suficiente para adaptar uno o dos cajones de este
tipo tanto a la plataforma de un camión como a la de un vagón ferroviario. En los
contenedores se acopla la mercancía de menor tamaño ganando en tiempo de
manipulación, transporte y reparto. Con este sistema los contenedores llegan por
carretera hasta las estaciones ferroviarias, llamadas terminales de carga, donde se
pueden ir apilando, y posteriormente pasan a los trenes mercantes donde se
transportan, después de un largo recorrido, hasta otra terminal desde la que se hace
la distribución de mercancía (en los contenedores) mediante camiones, siguiendo un
camino inverso al de recogida.
En los países desarrollados, estas terminales intermodales tienen un alto grado de
mecanización con pórticos grúa y otros avances tecnológicos para conseguir que el
transbordo de la carga del tren a camiones y remolques, y viceversa, sea un servicio
ágil que favorezca el transporte con este sistema, que hoy resuelta competitivo para
el ferrocarril, a partir de una distancia que se estima en unos 800 Km. de transporte.
[TODOTRENES]
Capítulo 1: Antecedentes
22
1.3.- FERROVIARIA ORIENTAL S.A.
Ferroviaria Oriental S.A. es la principal empresa privada de servicios públicos integrales de
cargas de comercio exterior, importaciones y exportaciones, que conecta el rico entorno
agrícola que rodea a Santa Cruz y la región productora de gas natural del Sur boliviano con
la República Argentina, y hacia el Este con el Brasil y los mercados internacionales a través
de los embarques que operan en la Hidrovía Paraguay-Paraná. [GYW]
Nacida como producto del proceso de capitalización, opera a partir del 14 de Marzo de
1996 y está constituida bajo escritura Pública de Constitución de una Sociedad de
Economía Mixta Nº 3.134/95. [TESIS1, 2004]
En total cuenta con 1243 Km. de vía, 643 hacia el Este, 539Km. hacia el Sur y 61 Km.
hacia el Norte (Ver Figura 1.3).
Figura 1.3: Ruta cubierta por la Empresa Ferroviaria Oriental.
Capítulo 1: Antecedentes
23
Fuente: [GYW]
Ferroviaria Oriental cuenta con 463 empleados, 28 Locomotoras y más de 1.000 unidades
para el transporte de productos de diversas características (bodegas multiuso, tolvas
graneleras, vagones tanques como el de la figura 1.4, contenedores refrigerados, tolvas
balasteras, jaulas ganaderas, etc.) y la capacidad de transportar grandes volúmenes de carga
garantizando la integridad y seguridad de las mismas. [INTRANET]
Figura 1.4:
Vagones para
transporte de
productos
químicos
pertenecientes a la
empresa
Ferroviaria
Oriental.
Fuente: Intranet de
la empresa
Figura 1.5: Trenes en la
Terminal Ferroviaria de
Puerto Quijarro.
Fuente: Intranet de la
empresa
Capítulo 1: Antecedentes
24
Figura 1.6: Locomotora con vagones de carga de la empresa Ferroviaria Oriental.
Fuente: Intranet de la empresa
Actualmente, los accionistas de la empresa son:
Las administradoras bolivianas de fondos y pensiones, en representación del pueblo
de Bolivia.
Los trabajadores ferroviarios.
Trenes Continentales, liderada por Genesee & Wyoming Inc., una corporación
estadounidense con mas de 100 años de experiencia en administración ferroviaria,
que opera ferrocarriles en Estados Unidos, Canadá, México, Australia y Bolivia.
1.3.1.- Misión
Proveer servicios terrestres de transporte seguros, eficientes y de calidad.
1.3.2.- Visión
Empresa líder de transporte terrestre en América del Sur.
Capítulo 1: Antecedentes
25
1.3.3.- Objetivos Estratégicos
Incrementar la participación de mercado en el transporte terrestre de la
región a través de servicios mejorados y desarrollo de nuevas opciones
logísticas, tanto ferroviarias como de servicios complementarios, que
satisfagan plenamente las necesidades de los clientes.
Expandir los servicios más allá de las propias líneas de tal manera de captar
nuevos mercados de transporte terrestre y proveer servicios adicionales que
sean sinérgicos con los actuales y que apoyen las oportunidades de negocio
de nuestros clientes.
Mejorar permanentemente las prácticas de operación en cada aspecto de
nuestros servicios, con el propósito de satisfacer la demanda del mercado de
manera cada vez más competitiva.
Realizar todas las operaciones con el más alto nivel de seguridad practicable
y preservación del medio ambiente para el beneficio de nuestros
clientes, trabajadores y del público en general.
Preservar y acrecentar el interés de los clientes, empleados y el público en
general en el largo plazo, de manera que permita crear progreso para el
ferrocarril y toda la gente ligada a sus operaciones.
1.3.4.- Servicios
Son básicamente dos: transporte de carga y de pasajeros.
i. Transporte de Carga
El transporte de carga tiene tres importantes componentes: Exportación,
Importación y regional.
Capítulo 1: Antecedentes
26
Las exportaciones, representan el 43,50% del total transportado, los
principales productos transportados son soya, y derivados, y en una menor
proporción minerales, azúcar, algodón y fréjol. [INTRANET]
Las importaciones, contribuyen con un 40,65% del total transportado, los
principales productos corresponden a tubos de fierro, diesel, oil, trigo en
grano, papel, fierro y materiales de construcción.
La carga regional que tiene una participación del 15,85%, se compone en lo
fundamental por el transporte de cemento 53% y en proporciones menores
ganado vacuno, productos derivados del petróleo y legumbres.
[INTRANET]
ii. Transporte de Pasajeros
Para el transporte de pasajeros se ofrece un parque de coches que operan con
Itinerarios tanto para el región Este como para la región Sur. Los servicios
ofrecidos son: Ferrobuses (ver Figura 1.7), Expreso Oriental (con aire
acondicionado, música ambiental, coche comedor y snack) y Tren Regional
(para las comunidades del Oriente y Chaco boliviano). [INTRANET]
Capítulo 1: Antecedentes
27
Figura 1.7:
Ferrobús
perteneciente a
la empresa
Ferroviaria
Oriental.
Fuente:
Intranet de la
empresa
1.3.5.- Cifras y Datos de la Gestión 2005
En 2005, Ferroviaria Oriental transportó más de 1,3 millones de toneladas de carga,
volumen que representa el 94% más de lo transportado hace diez años por la
empresa estatal. Del total de carga transporta por la empresa, el 65% representa
carga de exportación, equivalente a más del 50% del total de las exportaciones no
tradicionales de Santa Cruz y un tercio de las nacionales. Por este motivo, esta
empresa es considerada por la comunidad empresarial, como El Ferrocarril de la
Exportación.
En el área de pasajeros, el año pasado los tres servicios de Ferroviaria Oriental, el
Tren Regional, Expreso Oriental y la línea de Ferrobuses, en conjunto transportaron
571.700 pasajeros, cifra que representa más del doble de lo transportado por la
empresa estatal.
Capítulo 1: Antecedentes
28
De esta manera, Ferroviaria Oriental se constituye en la principal promotora de los
destinos turísticos de la ruta ferroviaria, como ser San José de Chiquitos, Roboré y
Pantanal Boliviano, con un programa específico para este fin, denominado Nuestra
Ruta, Nuestros Destinos.
En esta gestión, la empresa ejecutó una inversión de $us. 6,26 millones, con lo cual
los desembolsos acumulados desde 1996 a diciembre de 2005 suman $us. 83
millones. Cerca del 60% de la inversión de la empresa ha estado destinada al
mantenimiento y mejoramiento de la infraestructura ferroviaria, es decir,
construcción de nuevos puentes, alcantarillas, construcción de nuevas estaciones y
refacción de estaciones históricas, cambio de durmientes, balastado de vía, colocado
de tirafondos y clips para darle mayor estabilidad a la vía férrea, entre otros.
[CARTAINF, 2006]
1.3.6.- Responsabilidad Social
La empresa se preocupa por que sus operaciones se realicen de forma segura,
preservando la integridad física de todas las personas y evitando dañar al medio
ambiente.
Se busca brindar a los trabajadores condiciones de trabajo aceptables, velando así
por su salud y seguridad.
A continuación se describen brevemente algunos de los proyectos puestos en
marcha por Ferroviaria Oriental.
1.3.6.1.- Tren de Vida
Más de 4.000 niños de 32 colegios de 12 comunidades de la vía férrea
recibieron al “Tren de Vía” el año pasado, el programa de responsabilidad
social de Ferroviaria Oriental de educación sobre seguridad vial y conciencia
ambiental, que utiliza herramientas interactivas computarizadas en el
Capítulo 1: Antecedentes
29
proceso enseñanza aprendizaje. En la Figura 1.8 se puede observar a niños
aprendiendo sobre seguridad vial.
Figura 1.8: Niños aprendiendo con el Tren de Vida.
Fuente: [SOBRERIELES, 2006]
1.3.6.2.- Nuestras Rutas, Nuestros Caminos
Con el objetivo de incentivar el desarrollo económico de los pueblos
aledaños a la vía férrea, la empresa lanzó su programa “Nuestra Ruta,
Nuestros Destinos” que promueve los destinos turísticos de San José de
Chiquitos, La Cuna de la Cruceñidad; Roboré, el Paraíso Escondido; el
Pantanal Boliviano, Santuario Ecológico; el Chaco Boliviano, un lugar para
disfrutar, destacando sus atractivos naturales y culturales.
Para ello, se han producido videos turísticos, trípticos, afiches y banners que
se difunden en los trenes, estaciones y en todo el entorno del ferrocarril,
además de hoteles, agencias de viaje y operadores de turismo de todo el país.
En la Figura 1.9 se pueden observar ejemplares de la revista Sobre Rieles.
Capítulo 1: Antecedentes
30
Figura 1.9: Revista “Sobre Rieles”. Fuente: [CARTAINF, 2006]
1.3.6.3.- Nuevo Mapa Ferroviario
En un esfuerzo por contribuir a la tradición de la elaboración de mapas, la
empresa editó el Mapa Ferroviario de Bolivia, que no sólo documenta las
dos redes del país (la Oriental y la Andina), sino los proyectos de desarrollo
ferroviario. El mapa está siendo distribuido a las instituciones públicas,
privadas y de la sociedad civil, del país (Superintendencia, Alcaldías,
Comités Cívicos, entre otras). El plano fue elaborado después de 15 años, del
último que publicó la Empresa Nacional de Ferrocarriles. En la figura 1.10
se puede observar un ejemplar del mismo.
Capítulo 1: Antecedentes
31
Figura 1.10: Mapa
Ferroviario elaborado
por la empresa
Ferroviaria Oriental.
Fuente:
[SOBRERIELES, 2006]
1.3.6.4.- Agua para El Chaco
El año pasado, Ferroviaria Oriental firmó una Alianza Estratégica de
Solidaridad Social, con la Cooperativa de Agua y Alcantarillado de Santa
Cruz (Saguapac), la Prefectura del Departamento de Santa Cruz y la ex
Delegación Presidencial para la Reforma y Mejora de la Capitalización, a fin
de ejecutar el Proyecto de Solidaridad Social “Agua para el Chaco”, para
beneficiar a unas mil familias de siete comunidades guaraníes del Chaco
cruceño.
Para ejecutar este acuerdo, Ferroviaria Oriental reacondicionó seis vagones
tanques (Ver Figura 1.11) para el trasporte de agua y desde mayo a
Capítulo 1: Antecedentes
32
diciembre de 2005 se trasportaron 106 vagones tanques al Sur haciendo un
total de 3.117 metros cúbicos de agua potable de Saguapac.
Figura 1.11: Vagón-Tanque acondicionado para el transporte de agua.
Fuente: [SOBRERIELES, 2006]
Capítulo 1: Antecedentes
33
Capítulo 2: Objetivos del Proyecto
34
CAPITULO 2
OBJETIVOS DEL PROYECTO
n el presente capítulo se detallarán los problemas observados en la empresa y se
especificarán los objetivos generales y específicos del proyecto, así como también el
alcance del mismo.
2.1.- DESCRIPCION DEL PROBLEMA Y JUSTIFICACION
Los problemas observados y a los que se quiere dar solución con el desarrollo del proyecto
son los siguientes:
2.1.1.- Planeamiento de Cruzamientos de Trenes
En prácticamente todos los tramos de la red que administra la empresa Ferroviaria
Oriental, el tipo de vía es simple, es decir sólo cabe un tren a la vez en un mismo
punto y el tránsito es en dos direcciones en esa única vía.
Para evitar que los trenes que van en direcciones opuestas colisionen, el encuentro
de éstos debe realizarse en lugares, en su mayoría estaciones, que cuenten con vías
E
Capítulo 2: Objetivos del Proyecto
35
alternativas. De esta forma, uno de los trenes espera en una de las vías mientras el
otro pasa y sigue su recorrido.
Figura 2.1: Cruzamiento de trenes. Fuente: Elaboración propia
En la vía hacia el Brasil, en la que hay 33 estaciones; en un lapso de 12 horas se
producen alrededor de 30 encuentros de trenes. Los trenes de carga, que son los que
más tiempo pasan en espera al tener menor preferencia y urgencia de llegar a su
destino, suelen estar en el mismo lapso de tiempo y por este motivo de 1 a 4 horas
parados.
Como se comprenderá, debido al número de encuentros que se producen y al tiempo
de espera que cada uno de ellos puede llegar a implicar, es de mucha importancia la
forma en la que se planifiquen los cruzamientos de trenes (la elección de los trenes
que deberán parar y esperar, el lugar donde deberán hacerlo, etc.) ya que de esto
dependerá el tiempo que los trenes pasen esperando y como consecuencia la
disponibilidad de las vías, razones que representan un gasto para la empresa.
Capítulo 2: Objetivos del Proyecto
36
Figura 2.2: Puesto de Control de Trenes de la Empresa Ferroviaria
Oriental. Fuente: Intranet de la empresa.
Actualmente, para llevar a cabo los cruzamientos, en el Puesto de Control de Trenes
(Figura 2.2) se realiza el llenado de una tabla (Figura 2.3) en donde se trazan líneas
que corresponden a los tramos de vía recorridos por los trenes (eje vertical) y el
instante de tiempo en el que lo hacen (eje horizontal). De esta manera, las
intersecciones de líneas que se vayan formando corresponden a encuentros de trenes
que están por producirse. Sabiendo que trenes se van a encontrar, se elige a uno de
ellos para que espere al otro en una de las estaciones.
Capítulo 2: Objetivos del Proyecto
37
Figura 2.3: Gráfico de Regulación de Trenes. Fuente: Elaboración propia,
basado en tablas reales proporcionadas por el Puesto de Control de Trenes.
Algunos factores que se toman en cuenta para determinar la estación de encuentro y
cuál de los trenes debe esperar son:
a) Preferencia entre Trenes: Por ejemplo, un tren de pasajeros tiene más
preferencia que uno de carga.
b) Futuros Cruzamientos: Puede ser preferible hacer esperar más de lo
que a simple vista parezca necesario a ciertos trenes o en estaciones que
no parezcan las más adecuadas, pero evitando de esta forma
cruzamientos que impliquen más adelante tiempos de espera mayores.
c) Capacidad de Estaciones: Puede darse el caso de que la segunda vía de
una estación esté ya ocupada o que, aún estando libre, el largo de la
Capítulo 2: Objetivos del Proyecto
38
misma no cubra el largo de ninguno de los trenes que se quiere hacer
cruzar.
Mientras que las principales estaciones, además de una segunda vía,
cuentan con varios desvíos; las más chicas cuentan con sólo una vía
además de la principal.
Figura 2.4: Estación Ferroviaria de Cotoca. Cuenta con solo una vía alternativa.
Fuente: Puesto de Control de Trenes de la empresa Ferroviaria Oriental
Figura 2.5: Estación Ferroviaria de San José. Fuente: Puesto de Control de
Trenes de la empresa Ferroviaria Oriental
Actualmente, realizar el cruzamiento de trenes es una tarea tediosa, por el hecho de
que se realiza de forma completamente manual y por que comúnmente el itinerario
sufre modificaciones debidas a diferentes causas (retraso de trenes, problemas en la
vía, etc.), entonces los encuentros que se tenían planeados se ven alterados sobre la
marcha.
Capítulo 2: Objetivos del Proyecto
39
Entre los beneficios que aportaría una herramienta que elabore inteligentemente el
plan de cruzamientos de trenes se encuentran los siguientes:
Reducción del tiempo ocioso del personal de la empresa y de
locomotoras y vagones al reducirse el tiempo que los trenes pasan
esperando por un cruzamiento.
Mayor disponibilidad de las vías, al haber menos trenes en espera.
Reducción de costos por los beneficios mencionados anteriormente.
Ya que cada tren en espera significa un costo para la empresa, es de
esperar que los gastos de la empresa por este motivo se verían
también reducidos.
Aliviaría el trabajo del personal del Puesto de Control de Trenes,
reduciéndolo en áreas para las que una herramienta informática
resulta más adecuada.
2.1.2.- Salidas de Trenes
Mientras los trenes de pasajeros tienen horarios establecidos de salida, los trenes de
carga salen en el momento en que esté lista la carga, locomotora, tripulación, etc.,
muchas veces sin prever los cruzamientos que va a tener este tren por salir en ese
momento. Cuando esto ocurre, el tren puede provocar cruzamientos y tiempos de
espera para otros trenes o para él mismo que se hubieran podido evitar de haber
salido en otro horario.
2.1.3.- Programación de Surcos
Un surco corresponde al desplazamiento de un tren de un punto a otro de la línea.
Programar un surco para un tren significa establecer el horario de salida y paso por
cada una de las estaciones para ese tren, considerando las paradas que tenga que
realizar por cruzamientos u otros motivos.
Capítulo 2: Objetivos del Proyecto
40
Actualmente los únicos trenes que tienen surcos establecidos son los de pasajeros
(Ver anexo), por la necesidad que hay de saber con seguridad el momento en el que
pasarán por cada una de las estaciones.
Realizar esta programación de forma manual es una tarea demasiado tediosa, que
puede llegar a demorar incluso semanas. Siendo la parte más difícil justamente la
forma de realizar los cruzamientos.
2.2.- OBJETIVOS DEL PROYECTO
Para una mejor comprensión de los objetivos que se pretenden alcanzar con este proyecto,
éstos han sido divididos en un objetivo general y otros específicos.
2.2.1.- Objetivo General
Desarrollar un Sistema que mejore el control y desempeño de las terminales
minimizando los tiempos de permanencia de trenes en las estaciones.
2.2.2.- Objetivos Específicos
Analizar el proceso actual mediante el que se realizan los cruzamientos
de trenes e identificar las formas posibles de optimizarlo.
Integrar el Sistema a desarrollar con los que ya existen en la empresa y
con los cuales hace falta que interactúe.
Identificar o diseñar los algoritmos a utilizar para la parte inteligente del
Sistema.
Elaborar el Sistema de acuerdo a los requisitos establecidos.
Capítulo 2: Objetivos del Proyecto
41
2.3.- ALCANCE DEL PROYECTO
Dentro de los procesos que deberá realizar el sistema, se encuentran:
2.3.1.- Cruzamiento de Trenes
El Sistema deberá calcular y mostrar los cruzamientos de trenes que vayan a
producirse y la mejor forma de realizarlos, minimizando el tiempo de espera de los
mismos en las estaciones.
2.3.2.- Salida de Trenes
El sistema deberá permitir buscar un horario óptimo de salida para un tren dado,
según el tráfico que haya en ese momento, optimizando los tiempos de espera por
los cruzamientos que se vayan a producir con la salida de ese tren.
2.3.3.- Elaboración de Surcos
El Sistema deberá permitir elaborar programaciones de surcos de trenes.
PARTE II
MARCO TEORICO
Y
METODOLOGICO
CAPITULO 3
EL FERROCARRIL
e entiende por ferrocarril, en el sentido amplio del término, el sistema de transporte
terrestre guiado sobre carriles de cualquier tipo. Con “ferrocarril” se entiende entonces
todo el conjunto de elementos que forman este medio de transporte: Trenes, Estaciones,
Vías Férreas, etc. Dichos elementos son los que serán tratados brevemente en el presente
capítulo.
3.1.- TRENES
Un tren es una composición de vagones y locomotoras. Tren es el nombre que se le da fuera
del ámbito ferroviario, dentro de éste la palabra tren se aplica a una composición formada,
con una estación de salida, un horario y un itinerario establecido. Por ejemplo el Tren 14
que parte todos los lunes, miércoles y viernes de Santa Cruz a Quijarro.
Por contrapartida a la composición de un tren, dos o más vehículos acoplados entre sí por
cualquier circunstancia (maniobras interiores en la estación por clasificación, agrupación de
vehículos estacionados, etc.) pero que no forman la composición de un tren propiamente
dicha, se denominan corte de material.
S
Capítulo 3: El Ferrocarril
44
3.1.1.- Locomotoras o Material Tractivo
Se denomina locomotora al material rodante con motor, denominado material
tractivo, que se utiliza para dar tracción a los trenes siendo, por tanto, una parte
fundamental de este.
La locomotora a vapor fue la primera en utilizarse. Actualmente existen
locomotoras diesel y eléctricas, siendo éstas últimas las más avanzadas y las que
mayores velocidades de desplazamiento permiten.
3.1.2.- Material Rodante
El material rodante es aquel material que no tiene capacidad tractora pero sí puede
llevar carga comercial. Se suele dividir por el tipo transporte para el que está
destinado:
o Coches, son los vehículos remolcados destinados al transporte de viajeros en
trenes de viajeros. El nombre específico de este tipo de material es coche.
o Furgones, son los vehículos que circulan en trenes de viajeros trasportando
mercancía o personal que desempeña su servicio en ellos, pero al que no
tienen acceso los viajeros.
o Vagones, son los vehículos remolcados que transportan mercancía en trenes
de mercancías se llaman vagones; se suelen clasificar por el tipo de
mercancía que pueden trasportar.
Capítulo 3: El Ferrocarril
45
En las siguientes figuras (3.1 y 3.2) se pueden observar algunos tipos de vagones.
Figura 3.1: Vagón jaula para el
transporte de ganado
Fuente: [TODOTRENES]
Figura 3.2: Vagón para
transporte de
contenedores
perteneciente a
Ferroviaria Oriental
Fuente: [INTRANET]
3.2.- ESTACIONES
Las estaciones comprenden las áreas del Ferrocarril, donde se atienden los servicios
públicos de carga y pasajeros, contiguos, en ocasiones, a zonas destinadas a servicios
propios de inspección, mantenimiento, aprovisionamiento y formación de trenes de carga y
pasajeros. Los diferentes tipos de estaciones, según su función, son las estaciones de tráfico
de viajeros, de carga y mixtos, que serán detallados a continuación.
Capítulo 3: El Ferrocarril
46
3.2.1.- Tipos de Estaciones
Principalmente se distinguen los tipos de estaciones siguientes:
3.2.1.1.- Estaciones de viajeros
La misión de las terminales de viajeros o pasajeros es la de
recepción y expedición de trenes de viajeros así como la
transferencia de viajeros desde los vehículos ferroviarios a otros
medios de transporte o viceversa. Se puede ver un ejemplo en la
Figura 3.3.
Figura 3.3: Disposición de una estación de pasajeros
Fuente: [VIASFERREAS, 2001]
En estaciones de paso para pasajeros, que son la mayoría, los trenes de
carga deben pasar sin detenerse empleando otras vías exclusivas para
circulación hasta la estación de carga, como se ilustra en la figura. Por otra
parte el mínimo servicio público sobre vía troncal, se establece mediante un
corto andén y una caseta con tejado, o la caja de un carro fuera de servicio,
acondicionado para proteger contra la intemperie, al reducido pasaje de una
pequeña comunidad, que aborda trenes locales mediante las señales del
usuario, Se puede ver un ejemplo en la Figura 3.4.
Capítulo 3: El Ferrocarril
47
Figura 3.4: Estación de paso para pasajeros
Fuente: [VIASFERREAS, 2001]
3.2.1.2.- Estaciones de Carga o Mercancías
La función de las estaciones de carga en el manejo y distribución a sus
diferentes destinos, tales como ciudades vecinas, industrias con vías
particulares o el trasbordo de la carga desde los vagones a otros medios de
transporte. Los componentes principales de las terminales de carga son las
siguientes:
Patios o parques de recepción, expedición y estacionamiento de
material, ordenación, formación y descomposición de trenes, los
cuales están formados por las instalaciones de la vía,
comunicaciones, señalización y todas las demás instalaciones
precisas para el tráfico de los trenes en la terminal. Se llama patio al
conjunto de vías que sirven en la repartición de los carros a
diferentes destinos y/o a escapes para las empresas a las cuales les
llegan grandes cargas por medio de este servicio de transporte.
Edificios, muelles y otros departamentos necesarios para
la explotación comercial de la terminal.
Accesos a la terminal y aparcamientos.
Los tipos de terminales de carga según las mercancías que se transporten
pueden ser: de trenes directos, los cuales tienen origen, destino y horarios fijos,
Capítulo 3: El Ferrocarril
48
circulan con carácter regular y, por lo general, sin paradas intermedias; de
detalle, para paquetería, servicios de correos y equipajes sin propietarios e
intermodal, para el transporte de contenedores o vagones especiales.
3.2.1.3.- Estaciones de Tráfico Mixto
En este tipo de estaciones, las terminales de viajeros y mercancías no están
separadas claramente la una de la otra. Ambas terminales están compuestas de
los departamentos que se detallan en los tipos de estaciones.
3.3.- VIAS FERREAS
Se denomina vía férrea a la parte de la infraestructura ferroviaria, formada por el conjunto
de elementos que conforman el sitio por el cual se desplazan los trenes.
Son el elemento esencial de la infraestructura
ferroviaria, como se puede observar en la
Figura 3.5, están compuestas básicamente de
carriles apoyados sobre traviesas que se
disponen dentro de una capa de balasto. Para
su construcción es necesario realizar
movimiento de suelos y diferentes tipos de
obras: puentes, alcantarillas, muros de
contención, drenes, etc.
Figura 3.5: Vía Férrea, sector
Este. Fuente: [INTRANET]
En las vías modernas se complementa la infraestructura básica con sistemas de señalización
y, en el caso de líneas electrificadas, con el tendido eléctrico que provee de energía a las
locomotoras.
3.3.1.- Elementos de la Infraestructura
Capítulo 3: El Ferrocarril
49
Entre los elementos utilizados para la construcción de vías férreas se encuentran los
siguientes:
3.3.1.1- Riel o Carril
Se denominan carriles o rieles a los elementos metálicos sobre los que se desplazan
las ruedas de los trenes, los cuales se disponen como una de las partes
fundamentales de las vías férreas.
Los rieles se obtienen por laminación del acero en bruto, hasta obtener barras con el
perfil requerido, las que se cortan en tramos de 18 a 25 m. Para realizar el montaje
se disponen las barras sobre los durmientes, y se unen entre sí mediante eclisas y
bulones, sujetándose al durmiente mediante algún sistema de fijación.
También se ajusta la trocha y se
alinea y nivela el conjunto, luego
de lo cual es usual, en las vías
modernas, quitar las eclisas y
bulones para sustituirlas por
uniones soldadas. De esta forma
se eliminan las juntas, punto en
el cual se produce el mayor
desgaste.
Figura 3.10: Riel utilizada por
Ferroviaria Oriental.
Fuente: [INTRANET]
Los rieles después de diversas formas en su sección transversal han venido a quedar
representadas en dos formas; la de doble cabeza (tipo Stephenson) y la de base plana
(tipo Vignol). Los primeros se conocen también por riel de cojinetes, como se
ilustra en la Figura 3.6, por que se monta sobre cojinetes, que son los que aseguran
Capítulo 3: El Ferrocarril
50
su estabilidad; se empleó mucho en el continente Europeo. No están tan extendidos
por el mundo como los de base plana (Figura 3.7).
Figura 3.6: Antiguos rieles de vientre de pez, sobre dados de piedra
Fuente: [VIASFERREAS, 2001]
Figura 3.7: Riel de tipo Vignol.
Fuente: [VIASFERREAS, 2001]
3.3.1.2- Balasto o Balastro
El balasto es la capa de piedra partida que se tiende sobre la explanación o
plataforma y sirve de asiento a los durmientes.
Se obtiene por trituración de rocas sanas y debe cumplir ciertas especificaciones en
cuanto a calidad del material madre y en su granulometría. Se transporta en
camiones hasta donde puede ser cargado en trenes especiales con tolvas que
permiten su descarga en la vía. En la Figura 3.8 se puede observar un acopio de
balasto.
Capítulo 3: El Ferrocarril
51
Figura 3.8: Acopio de Balasto
Fuente: [WIKIPEDIA]
El balasto de vía tiene la función de dar estabilidad a la vía férrea, haciendo que
permanezca con la geometría dada durante su construcción y sanear el asiento de la
vía, ya que con el balasto se forma una capa permeable.
Adicionalmente cumple otras dos funciones importantes: distribuye las presiones
que trasmite la vía al terreno, haciendo que sean admisibles para este, y permite el
drenaje del agua de lluvia, evitando que se deteriore el conjunto.
3.3.1.3- Durmientes o Traviesas
Tienen como función principal dar apoyo a los carriles, trasmitiendo el peso del
material rodante al balasto y, por intermedio de este, al suelo. También cumplen la
función de mantener la separación entre carriles con un valor fijo denominado
trocha, y la función de dar peso al conjunto, de manera que la geometría inicial del
trazado se mantenga en la mayor medida posible. Los durmientes mayormente
utilizados son de madera, siendo también usados los de hormigón como los de la
Figura 3.9. Para las vías Bolivianas tenemos en general las siguientes dimensiones
200 cm., y su sección transversal es un rectángulo de base 24 cm. y 12 cm. de altura.
Capítulo 3: El Ferrocarril
52
Figura 3.9: Vía Férrea con
durmientes de hormigón.
Fuente: [VIAS FERREAS]
3.3.1.4- Sujeción de Riel o de Vía
Las sujeciones del riel son elementos que hacen posible la continuidad estructural de
la vía.
Las funciones de las sujeciones, son: Fijar los rieles a los durmientes, asegurar la
invariabilidad del ancho de la vía y Facilitar la transferencia de las cargas estáticas y
dinámicas del material rodante. Se puede apreciar un ejemplar en la Figura3.10.
Figura 3.10: Tirafondo: utilizado
para la sujeción de la vía.
Fuente: [INTRANET]
3.3.1.5- Aparatos de Vía
Los aparatos de vía tienen por objeto realizar bien el desdoblamiento o el cruce de
las vías, aún cuando adoptan formas variadas, derivan todas ellas de los aparatos
fundamentales: el desvío, que permite el paso de los vehículos de una vía sobre otra
y la entrevía, que permite realizar la conexión entre dos vías. A continuación un
ejemplo de aparato de vía.
Capítulo 3: El Ferrocarril
53
Figura 3.11: Aparatos de vía (Sapo)
Fuente: [VIASFERREAS, 2001]
3.3.1.6- Señalización
Se conoce bajo el nombre de señales el conjunto de aparatos y signos claros y
precisos, que tienen por objeto controlar, asegurar y proteger el movimiento de
trenes, hacer conocer al personal las previsiones y el estado de la línea, a fin de
garantizar que el tráfico sea satisfactorio y sin riesgos.
Las señales según la Resolución Ministerial N° 224-74 y 320-74 de la Republica de
Bolivia, se clasifican en: señales fijas, transitorias, con brazos, con banderas y luces
de color, con campana, pito de boca, silbato y petardos. [VIASFERREAS, 2001]
A continuación, en la Figura 3.12 se muestra un semáforo para desvío. El brazo
horizontal con la luz roja significa “Peligro, Pare”. El brazo en ángulo de 45° hacia
abajo con la luz amarilla indica “Ingreso a desvío”. El brazo en posición vertical
hacia abajo con la luz verde indica “Vía Libre”.
Figura 3.12: Semáforo para desvío.
Fuente: [VIASFERREAS, 2001]
Capítulo 3: El Ferrocarril
54
3.3.2.- Tipos de Vía
En la actualidad no se cuenta con una clasificación unificada de las líneas del ferrocarril,
debido a que las mismas presentan una gran variedad en sus características. Tomando en
cuenta algunos puntos de vista, se pueden clasificar en:
3.3.2.1.- Líneas Principales y Secundarias
Las líneas principales son aquellas que forman las grandes líneas tróncales, y las
líneas secundarias las que complementan la red formada por las anteriores dando así
un sistema completo de líneas férreas.
3.3.2.2.- Líneas de Vía Angosta y Vía Ancha
El ancho o trocha de vía, es la separación entre rieles, el cual debe coincidir con la
separación entre ruedas del material rodante, como se muestra en la figura a
continuación.
Figura 3.13: Ancho de Vía
Fuente: [VIASFERREAS, 2001]
3.3.2.3.- Líneas de Tránsito General, Urbanas y Sub-urbanas
Capítulo 3: El Ferrocarril
55
Esta es una clasificación relativa al servicio público que prestan. Así se
tiene que las líneas de tránsito general corresponden al servicio nacional o
internacional de larga distancia.
Las líneas suburbanas son aquellas que comunican una población con sus
zonas de influencia cercanas.
Las líneas urbanas son las que prestan servicio dentro de las poblaciones,
ya sean estos servicios efectuados sobre la superficie, como los tranvías,
subterráneos o elevados, y como los metropolitanos.
Existen también líneas de servicio particular que corresponden a las líneas
dedicadas exclusivamente al servicio de algunas empresas de carácter
privado, tales como las líneas mineras.
56
CAPITULO 4
RESOLUCION DE PROBLEMAS MEDIANTE TECNICAS
HEURISTICAS
e denomina heurística a la capacidad de un sistema para realizar de forma inmediata
innovaciones positivas para sus fines. La capacidad heurística es un rasgo
característico de los humanos, desde cuyo punto de vista puede describirse como el arte y
la ciencia del descubrimiento y de la invención o de resolver problemas mediante la
creatividad y el pensamiento lateral o pensamiento divergente. [WIKIPEDIA]
De acuerdo con ANSI/IEEE, la heurística trata de aquellos métodos o algoritmos
exploratorios para la resolución de problemas en los que las soluciones se descubren por la
evaluación del progreso logrado en la búsqueda de un resultado final. Se trata de métodos
en los que, aunque la exploración se realiza de manera algorítmica, el progreso se logra por
la evaluación puramente empírica del resultado. Se gana eficacia, sobre todo en términos de
eficiencia computacional, a costa de la precisión.
Las técnicas heurísticas no aseguran soluciones óptimas sino solamente soluciones válidas,
aproximadas; y frecuentemente no es posible justificar en términos estrictamente lógicos la
validez del resultado.
S
Capítulo 4: Resolución de Problemas Mediante Técnicas Heurísticas
57
4.1.- RESOLUCION DE UN PROBLEMA MEDIANTE BUSQUEDA HEURISTICA
Si resulta que un problema se puede efectuar como problema de búsqueda, en muchos
casos se puede reducir a un problema de hallar un máximo o mínimo, o sea, un óptimo.
Sólo va a funcionar esto en el caso de que se pueda calcular la bondad de una solución: la
solución del problema será aquella, o aquellas, que optimicen una función de bondad, ajuste
o evaluación; en muchos casos, por lo tanto, un problema de búsqueda se puede reducir a
un problema de optimización (maximización o minimización).
Formalmente, entonces, una heurística es una función matemática, h(n) definida en los
nodos de un árbol de búsqueda, que sirve como una estimación del coste del camino más
económico de un nodo dado hasta el nodo objetivo.
4.1.1.- Elementos de un Problema de Búsqueda
Los elementos básicos que definen a un problema de búsqueda son los estados y las
acciones:
Estado inicial, desde donde se parte para la solución del problema.
Conjunto de Operadores, es el conjunto de posibles acciones que el sistema
puede emprender.
El espacio de conjunto de estados de un problema es el conjunto de todos
los estados que pueden alcanzarse a partir del estado inicial mediante
cualquier secuencia de acciones.
Prueba de meta es lo que el sistema aplica a la descripción de un estado para
decidir si se trata de un estado meta. El estado meta se produce cuando se
encuentra una posible solución.
Función costo de ruta, es la función objetivo que se buscará minimizar,
mediante ésta se asigna un costo a una ruta determinada. Este costo es la
suma de los costos de cada una de las acciones individuales que se
emprendan a lo largo de la ruta.
Capítulo 4: Resolución de Problemas Mediante Técnicas Heurísticas
58
4.1.2.- Primer Paso en la Resolución de un Problema Mediante Búsqueda:
Modelización
Es el primer paso necesario para resolver un problema, no se trabaja directamente
con el mundo real, sino que se realiza un modelo del problema. En ese modelo, se
extraen las características fundamentales del mismo, es decir sólo aquellas que
tienen una importancia para el desarrollo del problema, y se eliminan todas las que
no tienen tanta importancia. Si nos trasladamos al problema de los cruzamientos de
trenes, habrán características o datos que resultan de interés: velocidad de recorrido,
largo de los trenes, capacidad de las estaciones, etc. Al contrario, otros datos
podrían tener menos importancia o ser irrelevantes: tonelaje de los trenes, número
de pasajeros, etc.
En todo caso, sólo se puede resolver un problema si se tiene un modelo del mismo;
la solución al problema real será tanto más adecuada cuanto más cercano sea el
modelo al problema real, pero la solución a un problema lo es sólo en el sentido que
es una solución al modelo del problema.
Modelos diferentes del problema darán soluciones diferentes del mismo. Pero casi
siempre será mejor encontrar una solución aproximada a un modelo exacto que
encontrar una solución exacta a un modelo aproximado.
4.1.3.- Problemas Multimodales
Un problema multimodal es un problema que tiene varios máximos, todos ellos de
la misma jerarquía, pero también se aplica a aquellos problemas que tienen varias
soluciones posibles.
En general, casi todo problema de búsqueda, formulado como un problema de
optimización, suele tener varios máximos, pero uno de ellos es mejor que el resto, y
se denomina máximo global. El resto son máximos locales; es decir, se puede
definir una vecindad alrededor de ellos en la cual son máximos globales. Sin
embargo, en muchos casos, todos los máximos globales tienen la misma jerarquía,
Capítulo 4: Resolución de Problemas Mediante Técnicas Heurísticas
59
bien por tener el mismo valor numérico, o bien porque se establezca un criterio de
mejor que tal que no se pueda decidir cuál de ellos es mejor que otro.
Podemos tener, por ejemplo, una solución que implique el menor tiempo de espera
de los trenes en conjunto; otra en donde el itinerario de los trenes de pasajeros se
vea afectado de la menor forma posible, aunque eso signifique un tiempo de espera
mayor para los otros tipos de trenes y como consecuencia al total del conjunto; otra
en donde se minimice el combustible usado, etc. Algunos de estos criterios podrían
tener menos importancia que los demás (por ejemplo el uso de combustible), en
cambio podría ser difícil decidir la importancia entre los otros.
4.1.4.- Problemas con Restricciones
Un problema que satisface restricciones es un tipo especial de problema que
satisface algunas propiedades estructurales adicionales además de los requisitos
básicos de los problemas en general. [IARTIFICIAL, 1996]
En este tipo de problemas, los estados se definen mediante los valores de un
conjunto de variables y la prueba de meta especifica un conjunto de restricciones
que los valores deben satisfacer.
Con todo lo anterior, se debe tener en cuenta lo siguiente:
El estado inicial será el estado en el que todas las variables todavía no están
asignadas.
Los operadores asignarán un valor a las variables.
La prueba de meta deberá verificar que todas las variables estén asignadas y
se satisfagan todas las restricciones.
La función de evaluación deberá tener en cuenta el incumplimiento de
restricciones, en cuyo caso podrá ser sustituida ésta por otra función en la
que las regiones “no alcanzables” sean alcanzables, o asignarse un valor
numérico al incumplimiento de dicha restricción.
Capítulo 4: Resolución de Problemas Mediante Técnicas Heurísticas
60
4.2.- METODO DE BUSQUEDA: BUSQUEDA EXHAUSTIVA
Dentro de un árbol de búsqueda, la decisión de qué nodos expandir y en qué turnos viene
dada por la estrategia de búsqueda que se utilice.
En algunos problemas donde el espacio de búsqueda es suficientemente pequeño y
enumerable, se pueden usar métodos de búsqueda exhaustiva o enumerativas: se examinan
una por una todas las soluciones posibles, y se da por buena aquella que tenga el máximo o
mínimo valor de la función objetivo.
El problema con la búsqueda exhaustiva no sólo es que no siempre sea factible, sino que su
mal comportamiento con respecto al aumento de tamaño del espacio de búsqueda, y el
hecho de que necesite una cantidad de memoria de ordenador proporcional al tamaño del
problema, hace que no se pueda aplicar en la mayor parte de los casos. Sin embargo, en
algunos casos puede ser útil; por ejemplo, en la fase final de la resolución del problema
cuando el subespacio de búsqueda esté suficientemente acotado.
En este tipo de búsqueda se puede usar técnicas como el backtracking para mantener el
costo de ruta de la mejor solución y de esa forma descartar partes del espacio de búsqueda
que se va a recorrer.
Capítulo 4: Resolución de Problemas Mediante Técnicas Heurísticas
61
4.3.- PROBLEMA DE ENCONTRAR LA RUTA MÁS CORTA DE UNA
CIUDAD A OTRA
Suponiendo que sólo queremos viajar entre dos ciudades (en el ejemplo de la Figura 4.1 de
A hacia E) y para ello necesitamos saber cuál es el recorrido o combinación de ciudades
que nos garantiza el menor número de kilómetros a recorrer.
Figura 4.1: Problema de determinación
de ruta.
Fuente: Elaboración Propia
4.3.1.- Elementos del Problema
Los elementos de este problema serían los siguientes:
Estado inicial
La ciudad desde donde se inicia el recorrido.
Conjunto de Operadores
Los operadores son los recorridos de una ciudad a otra.
El espacio de conjunto de estados
Es el conjunto de recorridos posibles que se pueden realizar.
Prueba de meta
La prueba de meta verifica si se llegó a la ciudad que se tenía como destino.
Función costo de ruta
D
B
E
C
A
15
2
8
10
20
7
Capítulo 4: Resolución de Problemas Mediante Técnicas Heurísticas
62
Esta función indica lo acertado de una ruta, sería igual al número de
kilómetros recorridos.
4.3.2.- Solución Mediante Búsqueda Exhaustiva y Backtracking
Se empieza a expandir el árbol por los nodos cuyo costo de ruta sea menor hasta dar
con la primera solución (en el ejemplo de la Figura 4.2, la combinación de ciudades
ABE con un costo de ruta de 18). Mantendremos esta solución como la mejor para
compararla con cada nueva solución que haya, actualizándola si procede.
Figura 4.2: Primer solución hallada siguiendo los nodos cuyo costo de ruta sea
menor. Fuente: Elaboración Propia
Para mejorar la eficiencia se poda los nodos de los cuales sabemos que no nos
llevarán a ninguna solución mejor que la mejor solución actual. Si para una solución
parcial se tiene que costo de ruta ≥ mejor-costo, podemos podarla y no continuar
con ella ya que todas las soluciones en su subárbol tendrán un costo mayor o igual
que costo de ruta y por tanto que mejor-costo. Siguiendo con el ejemplo anterior se
Capítulo 4: Resolución de Problemas Mediante Técnicas Heurísticas
63
puede ver en la Figura 4.3 la poda realizada y la solución óptima hallada al final de
la búsqueda.
Figura 4.3: Después de explorar todos los nodos, se da con la solución óptima
Fuente: Elaboración Propia
Capítulo 4: Resolución de Problemas Mediante Técnicas Heurísticas
64
4.4.- PROBLEMA DE CRUZAMIENTO DE TRENES
Los elementos del problema de cruzamiento de trenes son los siguientes:
Estado inicial
Es la disposición de trenes en un momento dado, desde el cual nos queremos
anticipar a los cruzamientos que van a producirse. En la siguiente figura se
puede apreciar un cruzamiento que va a producirse entre un Ferrobús (línea
color naranja) y un tren de pasajeros (línea color azul).
Figura 4.4: Proyección de Cruzamientos entre dos trenes
Fuente: Elaboración Propia
Conjunto de Operadores
Básicamente, las acciones que puede sugerir el sistema son dos: la estación
en la que debe realizarse el cruzamiento y el tren que debe esperar en dicha
estación.
Capítulo 4: Resolución de Problemas Mediante Técnicas Heurísticas
65
Para el ejemplo de la figura anterior hay, en el menor de los casos, dos
operaciones que pueden realizarse, cada una de ellas produce un
determinado tiempo de espera para uno de los trenes y afecta de una forma
diferente a los siguientes cruzamientos:
El ferrobús espera en la primera estación al tren de pasajeros
(Figura 4.5).
El tren de pasajeros espera en la segunda estación al ferrobús
(Figura 4.6).
Figura 4.5: El ferrobús espera en la primera estación al tren de
pasajeros: La demora es de poco más de 30 minutos
Fuente: Elaboración Propia
Capítulo 4: Resolución de Problemas Mediante Técnicas Heurísticas
66
Figura 4.6: El tren de pasajeros espera en la segunda estación al
ferrobús: El tiempo de espera es de poco más de 50 minutos
Fuente: Elaboración Propia
El espacio de conjunto de estados
Es el conjunto de todas las posibles soluciones a las que puede llegar el
sistema, algunas serán más eficientes, otras producirán tiempos de espera
mayores, etc.
Prueba de meta
En este caso todas las acciones o rutas son consideradas soluciones válidas,
por lo que la búsqueda podría terminar después de hallar la mejor ruta (o
conjunto de acciones) para el primer cruzamiento que se presente. Sin
embargo, es conveniente proseguir con la búsqueda ya que, aunque la ruta
hallada parezca la más eficiente, ésta podría no ser la mejor a largo plazo
debido a que los futuros cruzamientos varían con cada acción que se realice.
Por este motivo la prueba de meta podría ser un límite en el nivel de
exploración de la búsqueda. Por ejemplo, tomar en cuenta sólo los
cruzamientos que se produzcan en las siguientes 12 horas.
Capítulo 4: Resolución de Problemas Mediante Técnicas Heurísticas
67
Función costo de ruta
Indica lo acertado de una solución, estaría en función a los siguientes
valores:
o Tiempo total de espera de los trenes.
o Tiempo de retraso producido para los trenes que tienen que cumplir
con un itinerario (por ejemplo los de pasajeros).
( ) ∑ ( )
Adicionalmente se deben tener en cuenta las restricciones del problema, una de ellas es la
capacidad de las estaciones. No siempre un tren podrá esperar en una estación, ya que el
largo de la vía secundaria podría no alcanzar a cubrir el largo del tren.
68
CAPITULO 5
EL PROCESO UNIFICADO DE DESARROLLO DE
SOFTWARE
n estos días, dada la importancia de la información como recurso estratégico que
ayuda a generar ventajas competitivas para las empresas, se tiende a construir
sistemas cada vez más grandes y complejos donde intervienen equipos de trabajos
formados por numerosas personas con distintas funciones y roles. Tal situación lleva a
definir mecanismos que ayuden a administrar esos grandes proyectos: programar las
actividades en tiempo y forma, coordinar las actividades de cada integrante del equipo, y
ofrecer criterios para permitir un control y medición de estas actividades.
Sea cual fuese el tamaño del sistema, es necesario siempre apoyarse en un proceso de
análisis y diseño.
A continuación se describirá un proceso para encarar proyectos de desarrollo de software
denominado Proceso Unificado de Desarrollo de Software, que abarca las actividades
E
Capítulo 5: El Proceso Unificado de Desarrollo de Software
69
necesarias para transformar los requisitos de los distintos usuarios en un Sistema
Informático.
5.1.- DEFINICION DEL PROCESO UNIFICADO
El Proceso Unificado de Desarrollo de Software o simplemente Proceso Unificado, es un
marco de desarrollo de software iterativo e incremental. En general, un marco de desarrollo
son las recomendaciones acerca de qué pasos seguir para transformar los requisitos del
usuario en un sistema.
El Proceso Unificado utiliza el Lenguaje Unificado de modelado (Unified Modeling
Language, UML) para preparar todos los esquemas de un sistema software.
5.2.- CARACTERISTICAS
Los aspectos fundamentales que definen este proceso son:
5.1.1.- Dirigido por Casos de Uso
Las necesidades del cliente no son fáciles de detectar, esto lleva a utilizar algún
modo de capturar esas necesidades y comunicarlas a los diferentes integrantes del
proyecto.
Los Casos de Uso indican cómo debería interactuar el sistema con los usuarios o
con otros sistemas para conseguir un objetivo específico. Normalmente, en los casos
de usos se evita el empleo de términos técnicos, prefiriendo en su lugar un lenguaje
más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia
junto a los analistas para el desarrollo de casos de uso.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
70
La idea es que cada iteración tome un conjunto de casos de uso o escenarios y
desarrolle todo el camino a través de las distintas disciplinas: diseño,
implementación, prueba, etc.
Los diagramas de casos de uso sirven para especificar la comunicación y el
comportamiento de un sistema mediante su interacción con los usuarios y/o otros
sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y
los casos de uso en un sistema. Los diagramas de casos de uso se utilizan para
ilustrar los requerimientos del sistema al mostrar cómo reacciona en respuesta a
eventos que se producen en el mismo.
Figura 5.1: Elementos de los Casos de Uso
Fuente: [WIKIPEDIA]
Los elementos que componen los Casos de Uso e ilustrados en la Figura 5.1 son:
Actores
Un actor es el rol o función que asume una persona, sistema o entidad que
interactúa con el sistema que estamos construyendo. Tiene la propiedad de
Capítulo 5: El Proceso Unificado de Desarrollo de Software
71
ser externo a este. Hay que tener en cuenta que un usuario puede acceder al
sistema como distintos actores.
Casos de Uso
Como se ha dicho antes, un caso de uso es una secuencia de interacciones
entre un sistema y alguien o algo que usa alguno de sus servicios. Ese
alguien o algo es el actor. Tienen una representación gráfica de óvalos.
Los Casos de Uso tienen varias ventajas, entre las cuales podemos mencionar:
La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa
la intención que tiene el actor (su usuario) al hacer uso del sistema.
Como técnica de extracción de requerimientos permite que el analista se
centre en las necesidades del usuario, qué espera éste lograr al utilizar el
sistema, evitando que la gente especializada en computación dirija la
funcionalidad del nuevo sistema basándose solamente en criterios
tecnológicos.
A su vez, durante la extracción, el analista se concentra en las tareas
centrales del usuario describiendo por lo tanto los casos de uso que mayor
valor aportan al negocio. Esto facilita luego la priorización de los
requerimientos
5.1.2.- Centrado en la arquitectura
La arquitectura describe los cimientos del sistema que son necesarios para
comprenderlo, desarrollarlo y producirlo. El objetivo de la elaboración es construir
una arquitectura sólida para que a partir de la misma podamos realizar la
construcción total del sistema.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
72
A la hora de ir pasando por las distintas fases del proyecto, los desarrolladores
utilizaran la arquitectura como guía general y los distintos diagramas, más
detallados, para realizar su trabajo.
El Proceso Unificado asume que no existe un modelo único que cubra todos los
aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que
definen la arquitectura de software de un sistema. La analogía con la construcción es
clara, cuando construyes un edificio existen diversos planos que incluyen los
distintos servicios del mismo: electricidad, fontanería, etc.
5.1.3.- Iterativo e incremental
La estrategia que propone el Proceso Unificado es tener un proceso iterativo e
incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos.
Permitiendo que el equilibrio entre Casos de Uso y Arquitectura se vaya logrando
durante cada mini proyecto, así durante todo el proceso de desarrollo.
El Proceso Unificado está compuesto de cuatro fases denominadas Inicio,
Elaboración, Construcción y Transición. Cada una de estas fases es a su vez
dividida en una serie de iteraciones.
Cada mini proyecto se puede ver como una iteración (un recorrido más o menos
completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene
un incremento que produce un crecimiento en el producto.
Una iteración puede realizarse por medio de una cascada, como se muestra en la
figura. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño,
Implementación y Pruebas), también existe una planificación de la iteración, un
análisis de la iteración y algunas actividades específicas de la iteración. Al finalizar
se realiza una integración de los resultados con lo obtenido de las iteraciones
anteriores.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
73
Figura 5.2: Fases o flujos de iteración
Fuente: [WIKIPEDIA]
Cada iteración aborda una parte de la funcionalidad total, pasando por todos los
flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza
cuando termina. Se puede determinar si han aparecido nuevos requisitos o han
cambiado los existentes, afectando a las iteraciones siguientes. Durante la
planificación de los detalles de la siguiente iteración, el equipo también examina
cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la
retroalimentación de la iteración pasada permite reajustar los objetivos para las
siguientes iteraciones. Se continúa con esta dinámica hasta que se haya finalizado
por completo con la versión actual del producto
5.2.- FASES Y FLUJOS DE TRABAJO
En el Proceso Unificado están las fases de desarrollo o flujos de iteración y los flujos de
trabajo fundamentales. Cada fase es un proyecto en sí mismo, y constituye una pasada por
los flujos de trabajo fundamentales.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
74
5.2.1.- Fases de Desarrollo
Las fases son: Inicio, Elaboración, Construcción y Transición. Las mismas se
detallan a continuación.
5.2.1.1.- Inicio
Durante la fase de inicio se define el modelo del negocio y el alcance del
proyecto. Se identifican todos los actores y Casos de Uso, y se diseñan los
Casos de Uso más esenciales (aproximadamente el 20% del modelo
completo). Se desarrolla, un plan de negocio para determinar que recursos
deben ser asignados al proyecto.
Los objetivos de esta fase son:
Establecer el ámbito del proyecto y sus límites.
Encontrar los Casos de Uso críticos del sistema, los escenarios
básicos que definen la funcionalidad.
Mostrar al menos una arquitectura candidata para los escenarios
principales.
Estimar el coste en recursos y tiempo de todo el proyecto.
Estimar los riesgos, las fuentes de incertidumbre.
Los resultados de la fase de inicio deben ser:
Un documento de visión: Una visión general de los requerimientos
del proyecto, características clave y restricciones principales.
Modelo inicial de Casos de Uso (10-20% completado).
Un glosario inicial: Terminología clave del dominio.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
75
El caso de negocio.
Lista de riesgos y plan de contingencia.
Prototipos exploratorios para probar conceptos o la arquitectura
candidata.
5.2.1.2.- Elaboración
El propósito de la fase de elaboración es analizar el dominio del problema,
establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y
eliminar los mayores riesgos.
En esta fase se construye un prototipo de la arquitectura, que debe
evolucionar en iteraciones sucesivas hasta convertirse en el sistema final.
Este prototipo debe contener los Casos de Uso críticos identificados en la
fase de inicio. También debe demostrarse que se han evitado los riesgos más
graves.
Los objetivos de esta fase son:
Definir, validar y cimentar la arquitectura.
Completar la visión.
Crear un plan fiable para la fase de construcción. Este plan puede
evolucionar en sucesivas iteraciones. Debe incluir los costes si
procede.
Demostrar que la arquitectura propuesta soportará la visión con un
coste razonable y en un tiempo razonable.
Al terminar deben obtenerse los siguientes resultados:
Capítulo 5: El Proceso Unificado de Desarrollo de Software
76
Un modelo de Casos de Uso completo al menos hasta el 80%: todos
los casos y actores identificados, la mayoría de los casos
desarrollados.
Requisitos adicionales que capturen los requisitos no funcionales y
cualquier requisito no asociado con un Caso de Uso específico.
Descripción de la arquitectura software.
Un prototipo ejecutable de la arquitectura.
Lista de riesgos y caso de negocio revisados.
Plan de desarrollo para el proyecto.
Un caso de desarrollo actualizado que especifica el proceso a seguir.
En esta fase se debe tratar de abarcar todo el proyecto con la profundidad
mínima. Sólo se profundiza en los puntos críticos de la arquitectura o riesgos
importantes.
5.2.1.3.- Construcción
La finalidad principal de esta fase es alcanzar la capacidad operacional del
producto de forma incremental a través de las sucesivas iteraciones. Durante
esta fase todos los componentes, características y requisitos deben ser
implementados, integrados y probados en su totalidad, obteniendo una
versión aceptable del producto.
Los objetivos concretos incluyen:
Minimizar los costes de desarrollo mediante la optimización de
recursos y evitando el tener que rehacer un trabajo o incluso
desecharlo.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
77
Conseguir una calidad adecuada tan rápido como sea práctico.
Conseguir versiones funcionales (alfa, beta, y otras versiones de
prueba) tan rápido como sea práctico.
Los resultados de la fase de construcción deben ser:
Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e
Implementación).
Arquitectura íntegra (mantenida y mínimamente actualizada).
Riesgos Presentados Mitigados.
Plan del Proyecto para la fase de Transición.
Manual Inicial de Usuario (con suficiente detalle).
Prototipo Operacional beta.
Caso del Negocio Actualizado.
5.2.1.4.- Transición
La finalidad de la fase de transición es poner el producto en manos de los
usuarios finales, para lo que se requiere desarrollar nuevas versiones
actualizadas del producto, completar la documentación, entrenar al usuario
en el manejo del producto, y en general tareas relacionadas con el ajuste,
configuración, instalación y facilidad de uso del producto.
Algunas de las tareas que debe incluir esta fase son:
Prueba de la versión Beta para validar el nuevo sistema frente a las
expectativas de los usuarios.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
78
Funcionamiento paralelo con los sistemas legados que están siendo
sustituidos por nuestro proyecto.
Conversión de las bases de datos operacionales.
Entrenamiento de los usuarios y técnicos de mantenimiento.
Traspaso del producto a los equipos de marketing, distribución y
venta.
Los principales objetivos de esta fase son:
Conseguir que el usuario se valga por si mismo.
Un producto final que cumpla los requisitos esperados, que funcione
y satisfaga suficientemente al usuario.
Los resultados de la fase de transición son:
Prototipo Operacional.
Documentos Legales.
Caso del Negocio Completo.
Línea de Base del Producto completa y corregida que incluye todos
los modelos del sistema.
Descripción de la Arquitectura completa y corregida.
Las iteraciones de esta fase irán dirigidas normalmente a conseguir
una nueva versión.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
79
La duración y esfuerzo dedicado en cada fase es variable dependiendo de las
características del proyecto. En la tabla se muestran porcentajes que frecuentemente son
necesarios.
Inicio
Elaboración
Construcción
Transición
Esfuerzo
5 %
20 %
65 %
10%
Tiempo
Dedicado
10 %
30 %
50 %
10%
Figura 5.3: Porcentajes de duración y esfuerzo típicos necesarios
Fuente: [RUP02, 2000]
5.2.2.- Flujos de Trabajo Fundamentales
Un flujo de trabajo es una relación de actividades que nos producen unos resultados
observables. Los flujos de trabajo fundamentales son: Modelo del Negocio, Captura de
Requisitos, Análisis, Implementación y Pruebas.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
80
Figura 5.4: Flujos de Trabajo Fundamentales
Fuente: [RUP02, 2000]
A continuación se describen cada uno de ellos de forma detallada.
5.2.2.1.- Modelo del Negocio
Con este flujo de trabajo pretendemos llegar a un mejor entendimiento de la
organización donde se va a implantar el producto.
Los objetivos del modelo del negocio son:
Entender la estructura y la dinámica de la organización para la cual el
sistema va ser desarrollado (organización objetivo).
Entender el problema actual en la organización objetivo e identificar
potenciales mejoras.
Asegurar que clientes, usuarios finales y desarrolladores tengan un
entendimiento común de la organización objetivo.
Derivar los requisitos del sistema necesarios para apoyar a la
organización objetivo.
Para lograr estos objetivos, el modelo de negocio describe como desarrollar
una visión de la nueva organización, basado en esta visión se definen
procesos, roles y responsabilidades de la organización por medio de un
modelo de Casos de Uso del negocio y un Modelo de Objetos del Negocio.
Complementario a estos modelos, se desarrollan otras especificaciones tales
como un Glosario.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
81
5.2.2.2.- Captura de Requisitos
Este es uno de los flujos de trabajo más importantes, porque en él se
establece qué tiene que hacer exactamente el sistema que construyamos. En
esta línea los requisitos son el contrato que se debe cumplir, de modo que los
usuarios finales tienen que comprender y aceptar los requisitos que
especifiquemos.
Los objetivos de este flujo de trabajo son:
Establecer y mantener un acuerdo entre clientes u otras personas
relacionadas con las actividades de la empresa sobre lo que el sistema
podría hacer.
Proveer a los desarrolladores un mejor entendimiento de los
requisitos del sistema.
Definir el ámbito del sistema.
Proveer una base para la planeación de los contenidos técnicos de las
iteraciones.
Proveer una base para estimar costos y tiempo de desarrollo del
sistema.
Definir una interfaz de usuarios para el sistema, enfocada a las
necesidades y metas del usuario.
Los requisitos se dividen en dos grupos. Los requisitos funcionales
representan la funcionalidad del sistema. Se modelan mediante diagramas de
Casos de Uso. Los requisitos no funcionales representan aquellos atributos
que debe exhibir el sistema, pero que no son una funcionalidad específica.
Por ejemplo requisitos de facilidad de uso, fiabilidad, eficiencia,
portabilidad, etc.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
82
Para capturar los requisitos es preciso entrevistar a todos los interesados en
el proyecto, no sólo a los usuarios finales, y anotar todas sus peticiones. A
partir de ellas hay que descubrir lo que necesitan y expresarlo en forma de
requisitos.
En este flujo de trabajo, y como parte de los requisitos de facilidad de uso, se
diseña la interfaz gráfica de usuario. Para ello habitualmente se construyen
prototipos de la interfaz gráfica de usuario que se contrastan con el usuario
final.
5.2.2.3.- Análisis
El análisis consiste en obtener una visión del sistema que se preocupa de ver
qué hace, de modo que sólo se interesa por los requisitos funcionales.
El resultado del flujo de trabajo del análisis es el modelo del análisis, que es
un modelo de objetos conceptual que analiza los requisitos mediante su
refinamiento y estructuración. El objetivo de refinar y estructurar los
requisitos es conseguir una comprensión mas precisa de los mismos y su
descripción.
5.2.2.4.- Diseño
El diseño es un refinamiento del análisis que tiene en cuenta los requisitos no
funcionales, en definitiva cómo cumple el sistema sus objetivos.
En el diseño se modela el sistema y se encuentra su forma (incluida la
arquitectura) para dar soporte a todos los requisitos. El principal resultado
del diseño es el modelo de diseño, que consiste en colaboraciones de clases,
que pueden ser agregadas en paquetes y subsistemas. El mismo que procura
conservar la estructura del sistema impuesta por el análisis.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
83
5.2.2.5.- Implementación
En este flujo de trabajo se implementan las clases y objetos en ficheros
fuente, binarios, ejecutables y demás. Además se deben hacer las pruebas de
unidad: cada implementador es responsable de probar las unidades que
produzca. El resultado final de este flujo de trabajo es un sistema ejecutable.
En cada iteración habrá que hacer lo siguiente:
Planificar qué subsistemas deben ser implementados y en que orden
deben ser integrados, formando el Plan de Integración.
Cada implementador decide en que orden implementa los elementos
del subsistema.
Si encuentra errores de diseño, los notifica.
Se prueban los subsistemas individualmente.
Se integra el sistema siguiendo el plan.
La estructura de todos los elementos implementados forma el modelo de
implementación. La integración debe ser incremental, es decir, en cada
momento sólo se añade un elemento. De este modo es más fácil localizar
fallos y los componentes se prueban más a fondo. En fases tempranas del
proceso se pueden implementar prototipos para reducir el riesgo. Su utilidad
puede ir desde ver si el sistema es viable desde el principio, probar
tecnologías o diseñar la interfaz de usuario. Los prototipos pueden ser
exploratorios (desechables) o evolutivos. Estos últimos llegan a
transformarse en el sistema final.
Capítulo 5: El Proceso Unificado de Desarrollo de Software
84
5.2.2.6.- Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que
estamos desarrollando, pero no para aceptar o rechazar el producto al final
del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.
Sus objetivos son:
Encontrar y documentar defectos en la calidad del software.
Generalmente asesora sobre la calidad del software percibida.
Provee la validación de los supuestos realizados en el diseño y
especificación de requisitos por medio de demostraciones concretas.
Verificar las funciones del producto de software según lo diseñado.
Verificar que los requisitos tengan su apropiada implementación.
Las actividades de este flujo comienzan pronto en el proyecto con el plan de
prueba (el cual contiene información sobre los objetivos generales y
específicos de las prueba en el proyecto, así como las estrategias y recursos
con que se dotará a esta tarea), o incluso antes con alguna evaluación durante
la fase de inicio, y continuará durante todo el proyecto.
PARTE III
DESARROLLO DEL
PROYECTO
86
CAPITULO 6
MODELO DEL NEGOCIO Y CAPTURA DE REQUISITOS
na de las primeras etapas dentro del proceso de desarrollo del Software es la captura
de requisitos. Con la introducción del estándar UML, los requisitos funcionales del
software se capturan, básicamente, utilizando diagramas de casos de uso, en los que se
representan las funcionalidades del sistema y las entidades externas con las que interactúa.
6.1.- MODELO DEL NEGOCIO
A continuación se presentan los modelos definidos en el Proceso Unificado como
modelo de negocio: de Casos de Uso del Negocio y de los Objetos del Negocio.
U
Capítulo 6: Modelo del Negocio y Captura de Requisitos
87
6.1.1.- Modelo de Casos de Uso del Negocio
Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores
externos, permite situar al sistema en el contexto organizacional haciendo énfasis en
los objetivos.
Este modelo se representa con un Diagrama de Casos de Uso usando estereotipos
específicos para este modelo. A continuación, en la Figura 6.1, el Modelo de Casos
de Uso del Negocio.
Figura 6.1: Modelo de Casos de Uso del Negocio
Fuente: Elaboración Propia
6.1.2.- Modelo de Objetos del Negocio
Es un modelo que describe la realización de cada caso de uso del negocio,
estableciendo los actores internos, la información que en términos generales
Capítulo 6: Modelo del Negocio y Captura de Requisitos
88
manipulan y los flujos de trabajo (workflows) asociados al caso de uso del negocio.
Para la representación de este modelo se utilizan Diagramas de Colaboración (para
mostrar actores externos, internos y las entidades (información) que manipulan,
Diagramas de Clases para mostrar gráficamente las entidades del sistema y sus
relaciones, y Diagramas de Actividad para mostrar los flujos de trabajo.
En las Figuras 6.2 a 6.6 se pueden ver los diagramas de actividades utilizados para
modelar los flujos de trabajo actuales del área del problema.
Graficar Recorrido
Una vez el maquinista informa al Puesto de Control de Tráfico su llegada a una
de las estaciones, el Controlador registra esa información en el Sistema de
Operaciones y actualiza el Gráfico de Regulación de Trenes.
Figura 6.2: Diagrama de Actividades: Graficar Recorrido
Capítulo 6: Modelo del Negocio y Captura de Requisitos
89
Realizar Proyección
Según la información proporcionada por el Sistema de Operaciones, los
Controladores de Tráfico realizan la proyección del recorrido de los trenes para
tener de forma estimada el horario de llegada de los mismos a las siguientes
estaciones.
Capítulo 6: Modelo del Negocio y Captura de Requisitos
90
Figura 6.3: Diagrama de Actividades: Realizar Proyección
Determinar Horario de Salida de un Tren de Carga
Para determinar el horario de salida de un tren de carga, la Jefatura de Tráfico
tiene que tener en cuenta una serie de factores e información proporcionada por
otras áreas de la empresa, como ser: estado de la carga (hora estimada en la que
puede estar lista), disponibilidad de vagones, disponibilidad de locomotoras, etc.
Figura 6.4: Diagrama de Actividades: Determinar Horario de Salida
Capítulo 6: Modelo del Negocio y Captura de Requisitos
91
Elaborar Surcos de Trenes
Los surcos de trenes son hechos por la Gerencia de Operaciones en base a
información y requerimientos proporcionados por la Jefatura de Tráfico y las
Jefaturas de Estación.
Figura 6.5: Diagrama de Actividades: Elaborar Surcos de Trenes
Capítulo 6: Modelo del Negocio y Captura de Requisitos
92
Consultar Horario de Llegada de Tren a Estación
Las diferentes estaciones pueden requerir esta información, la cual es
proporcionada por los Controladores de Tráfico en base a información dada por
el Sistema de Operaciones.
Figura 6.6: Diagrama de Actividades: Consultar Horario de Llegada de tren
a estación
Capítulo 6: Modelo del Negocio y Captura de Requisitos
93
6.2.- CAPTURA DE REQUISITOS COMO CASOS DE USO
Los requisitos del proyecto se detallaran mediante la utilización de casos de uso. Primero se
identifican y especifican los actores del sistema, describiendo los roles que cumplen en su
interacción con el sistema, luego se identifican y especifican los casos de uso y finalmente
se presenta el diagrama general de casos de uso completo.
6.2.1.- Identificación y Especificación de Actores
Para el desarrollo del proyecto se identificaron los siguientes actores:
Controlador de Tráfico
Representa al personal encargado de dirigir el tráfico de trenes en el Puesto
de Control de Trenes (PCT) y que constantemente está comunicándose con
los trenes y estaciones.
Jefatura de Tráfico
Dependiente de la Gerencia de Operaciones, es la directa responsable del
tráfico de trenes. Los Controladores son dependientes de esta jefatura.
Jefatura de Estación
Es la que dirige las operaciones de la empresa en una estación.
Sistema Operaciones
Este actor es el sistema encargado de manejar la información relacionada
con los trenes, locomotoras y vagones; sus recorridos, estados, ubicaciones,
etc.
Atención de Clientes
El departamento, dependiente de la Gerencia de Operaciones, que administra
la distribución de vagones a los clientes.
Capítulo 6: Modelo del Negocio y Captura de Requisitos
94
Gerencia Operaciones
El ente encargado de dirigir toda el área de operaciones de la empresa.
Maquinista
Es la persona que maneja la locomotora. Es ayudada por un auxiliar de
maquinista.
6.2.2.- Identificación de Casos de Uso
A continuación se presentan los casos de uso identificados:
Modulo de Trenes
o Proyectar Recorrido
o Determinar Hora de Salida
o Elaborar Surcos de Trenes
o Consultar Hora de Llegada de trenes a estaciones
Modulo de Gráficos
o Graficar Recorrido
6.2.3.- Priorización de Casos de Uso
A continuación, en la Figura 6.7, los Casos de Uso a desarrollar para el proyecto, los
actores que intervienen y la prioridad asignada a cada uno de ellos.
Capítulo 6: Modelo del Negocio y Captura de Requisitos
95
Código Nombre Actores Prioridad
CU-1 Realizar Proyección
Controlador de Tráfico, Sistema
Operaciones A
CU-2
Determinar Hora de Salida
Jefatura Tráfico, Jefatura
Estación, Mecánica, Atención de
Clientes
B
CU-3 Elaborar Surcos de Trenes
Jefatura Tráfico, Gerencia
Operaciones B
CU-4 Consultar Hora de Llegada de trenes
a estaciones
Jefatura Estación, Controlador
de Tráfico, Sistema Operaciones C
CU-5
Graficar Recorrido
Controlador de Tráfico,
Maquinista, Sistema de
Operaciones
A
A = Esencial B = Moderado C = No Influyente
Figura 6.7: Priorización de Casos de Uso
6.2.4.- Especificación de Casos de Uso
A continuación se hace una descripción detallada de los Casos de Uso, mediante una
tabla, donde se incluyen: el propósito del caso de uso, los actores involucrados y el
flujo de eventos.
Capítulo 6: Modelo del Negocio y Captura de Requisitos
96
Realizar Proyección
Figura 6.8: Caso de Uso: Realizar Proyección
Código: CU-1
Nombre:
RealizarProyección
Propósito
Proyectar el recorrido de los trenes resolviendo los
cruzamientos que se produzcan
Actores
Controlador de Tráfico, Sistema Operaciones
Iniciador
Controlador de Tráfico
Flujo
1. El Controlador de Tráfico irá introduciendo al
Sistema de Operaciones los horarios en que los
trenes vayan pasando por las estaciones.
2. Se recogen los datos introducidos al Sistema de
Operaciones.
3. Se procede a la búsqueda de soluciones para los
cruzamientos y pasos de tren que se produzcan con
los trenes en tránsito.
4. Se proyecta el recorrido de los trenes, incluyendo las
paradas por cruzamientos y pasos de tren.
5. Se muestra gráficamente el recorrido proyectado.
Capítulo 6: Modelo del Negocio y Captura de Requisitos
97
Determinar Horario de Salida
Figura 6.9: Caso de Uso: Determinar Horario de Salida
Código: CU-2
Nombre:
Determinar Hora de Salida
Propósito
Establecer el horario de salida para un tren de carga,
previendo otras llegadas y salidas de trenes de la estación
Actores
Jefatura Tráfico, Jefatura Estación, Mecánica, Atención
Cliente
Iniciador
Jefatura de Tráfico
Flujo
1. Obtener información sobre el estado de la carga.
2. Obtener información sobre la disponibilidad de
vagones.
3. Obtener información sobre el estado y disponibilidad
de locomotoras.
4. En base a la información obtenida, determinar un o
rango horario de salida.
5. Dentro del rango de horario elegido, determinar el
horario de salida que minimice los tiempos de espera
de los trenes producidos por los cruzamientos y
pasos de trenes.
Capítulo 6: Modelo del Negocio y Captura de Requisitos
98
Elaborar Surcos de Trenes
Figura 6.10: Caso de Uso: Elaborar Surcos de Trenes
Código: CU-3
Nombre:
Elaborar Surcos de Trenes
Propósito
Elaborar la planificación de salidas diarias de trenes
Actores
Gerencia Operaciones, Jefatura de Tráfico, Jefatura de
Estación
Iniciador
Gerencia de Operaciones
Flujo
1. La pantalla muestra una lista de trenes disponibles.
2. El usuario puede elegir los trenes con los que quiere
realizar los surcos pasándolos a una segunda lista.
3. En una segunda pantalla se puede establecer el día,
hora y estación de salida para los trenes elegidos.
4. En una tercera pantalla se muestran los trenes
elegidos e información de los mismos.
5. El usuario puede: Realizar la simulación o introducir
algunas condiciones para la simulación.
Si se elije realizar la simulación, el sistema realizará la
planificación de surcos con los horarios elegidos,
resolviendo los cruzamientos y pasos de trenes.
Entre las condiciones para la simulación están: modificar
el itinerario de los trenes y establecer una solución con
anterioridad para un cruzamiento dado.
Capítulo 6: Modelo del Negocio y Captura de Requisitos
99
Consultar Hora de Llegada de trenes a estaciones
Figura 6.11: Caso de Uso: Consultar Hora de Llegada de trenes a estaciones
Código: CU-4
Nombre:
Consultar Hora de Llegada de trenes
a estaciones
Propósito
Informar a las Estaciones, cuando éstas lo requieran, de la
hora estimada de llegada de los trenes
Actores
Jefatura Estación, Controlador de Tráfico, Sistema
Operaciones
Iniciador
Jefatura Estación
Flujo
1. Puede ser que ya se haya realizado ya una
proyección.
Si es que no es así, se realiza la proyección, resolviendo
los cruzamientos y pasos de trenes.
2. La pantalla mostrará una lista de los trenes.
3. Seleccionando el tren correspondiente, se mostrará el
recorrido o pasos por estación previstos para ese tren
según la última proyección realizada.
Capítulo 6: Modelo del Negocio y Captura de Requisitos
100
Graficar Recorrido
Figura 6.12: Caso de Uso: Graficar Recorrido
Código: CU-5
Nombre:
Graficar Recorrido
Propósito
Graficar el recorrido de los trenes a medida que estos
avanzan por las estaciones
Actores
Controlador de Tráfico, Maquinista, Sistema de Operaciones
Iniciador
Maquinista, Controlador de Tráfico, Sistema de Operaciones
Flujo
1. Obtener los trenes en tránsito.
2. Para cada tren, obtener su respectivo Boletín con la
fecha y hora de paso por cada una de las estaciones.
3. Graficar el recorrido realizado por los trenes.
Capítulo 6: Modelo del Negocio y Captura de Requisitos
101
6.2.5.- Diagrama General de Casos de Uso
Figura 6.13: Diagrama de Paquetes
102
CAPITULO 7
ANALISIS DEL PROYECTO
l análisis consiste en obtener una visión del sistema que se preocupa de ver qué hace,
de modo que sólo se interesa por los requisitos funcionales. Se parte de los
requerimientos descritos en la Captura de Requisitos, los cuáles se analizan, refinan y
estructuran.
7.1.- ANALISIS DE LA ARQUITECTURA
En la Figura 7.1 se detalla el Diagrama de Paquetes que especifica la manera en la que se
ha organizado el proyecto.
Figura 7.1: Diagrama de Paquetes
Fuente: Elaboración Propia
E
Capítulo 7: Análisis del Proyecto
103
7.2.- ANALISIS DE CASOS DE USO
A continuación (Figuras 7.2 a 7.7) se utilizan diagramas de colaboración donde se observan
cómo los objetos interactúan unos con otros para el mismo fin, esto se describe
textualmente en los flujos de sucesos descritos para cada diagrama de colaboración.
Capítulo 7: Análisis del Proyecto
104
i. Realizar Proyección
El usuario, mediante una interfaz cliente, solicita al Sistema realizar la proyección
del recorrido de trenes. La solicitud llega a Server, primero para recuperar
información sobre el estado de los trenes en tránsito y después para realizar la
simulación en sí. Una vez obtenido el resultado, la solución es mostrada y los
recorridos de la misma son graficados.
Figura 7.2: Diagrama de Colaboración: Realizar Proyección
Capítulo 7: Análisis del Proyecto
105
ii. Determinar Horario de Salida
El usuario, mediante una interfaz cliente, solicita al Sistema realizar una búsqueda
de horario para una salida de tren, el formulario FrmNewTrenHVar es mostrado, en
él se ingresan los datos necesarios para la búsqueda y se envía la orden a Server para
efectuar la misma. Una vez obtenido, el resultado es mostrado al usuario en el
formulario principal (FrmMain).
Figura 7.3: Diagrama de Colaboración: Determinar Horario de Salida
Capítulo 7: Análisis del Proyecto
106
iii. Elaborar Surcos de Trenes
Después de solicitar una nueva simulación desde el menú del formulario principal
(FrmMain), el usuario ingresa la información necesaria para los surcos en el
formulario FrmNewSimSimpl. La solicitud es mandada a Server, quien a su vez
iniciará los objetos necesarios y ordenará la simulación. Una vez obtenidos, el
resultado es mostrado y los surcos de trenes graficados en el formulario principal.
Figura 7.4: Diagrama de Colaboración: Elaborar Surcos de Trenes
Capítulo 7: Análisis del Proyecto
107
iv. Consultar Hora de Llegada de trenes a estaciones
La solicitud la realiza el usuario a través del formulario principal, la consulta es
hecha sobre la última proyección realizada y el resultado mostrado en el mismo
formulario principal.
Figura 7.5: Diagrama de Colaboración: Consultar Hora de Llegada de trenes a
estaciones
Capítulo 7: Análisis del Proyecto
108
v. Graficar Recorrido
Los gráficos de los recorridos de trenes son hechos por objetos de la clase
Graficador. A su vez se crean objetos TrenLine (líneas de recorrido en el gráfico),
cada uno de los cuales corresponde a un tren en tránsito.
Figura 7.6: Diagrama de Colaboración: Graficar Recorrido
Capítulo 7: Análisis del Proyecto
109
vi. Resolver Simulación
Diferentes tareas realizadas por el Sistema requieren de realizar una simulación del
recorrido de los trenes. La misma se inicia desde Server (objeto encargado de
interactuar con los clientes), sigue por Simulacion, hasta llegar a Motor, donde
residen los algoritmos de búsqueda heurística utilizados para la simulación.
Figura 7.7: Diagrama de Colaboración: Resolver Simulación
Capítulo 7: Análisis del Proyecto
110
7.3.- ANALISIS DE CLASES
En esta sección se identifican los atributos de las clases del análisis, indicándose el tipo de
las mismas, sus atributos, operaciones y una pequeña descripción de la función que
cumplen.
7.3.1.- Clases de Interfaz
En las siguientes figuras (7.8 a 7.11) el análisis de las clases de interfaz, utilizadas
para la interacción con el usuario.
Figura 7.8: Análisis de la clase FrmMain
Nombre:
FrmMain
Tipo:
Formulario
Responsabilidad:
Formulario principal desde donde el usuario interactúa con
el sistema.
Atributos:
_id, _server, _grafSim
Operaciones:
NuevaSimulacion, ConsultarHoraLlegada, BuscarHorario,
RealizarProyeccion
Capítulo 7: Análisis del Proyecto
111
Figura 7.9: Análisis de la clase FrmElegirTren
Figura 7.10: Análisis de la clase FrmNewSimSimpl
Nombre:
FrmElegirTren
Tipo:
Formulario
Responsabilidad:
Este formulario se utiliza como diálogo para seleccionar
uno de los trenes en tránsito
Atributos:
_result, _trenes
Operaciones:
ShowDialog, btnOk, btnCancel
Nombre:
FrmNewSimSimpl
Tipo:
Formulario
Responsabilidad:
Desde este formulario se crea una nueva simulación y se
elijen los trenes que van a estar en ella.
Atributos:
_server, _trenesElegidos
Operaciones:
ShowDialog, btnCerrar_Click, btnCancel_Click,
MostrarInfoTren
Capítulo 7: Análisis del Proyecto
112
Figura 7.11: Análisis de la clase FrmNewtrenHVar
Nombre:
FrmNewTrenHVar
Tipo:
Formulario
Responsabilidad:
Desde este formulario se elije un tren y establecen las
condiciones para la búsqueda de un horario de salida para el
mismo.
Atributos:
_result, _server
Operaciones:
ShowDialog, btnOk_Click, btnCancel_Click
Capítulo 7: Análisis del Proyecto
113
7.3.2.- Clases de Control
En las siguientes figuras (7.12 a 7.18) el análisis de las clases de Control, que
contienen la lógica del negocio y los algoritmos utilizados para efectuar las
simulaciones.
Figura 7.12: Análisis de la clase Server
Figura 7.13: Análisis de la clase Simulacion
Nombre:
Server
Responsabilidad:
Es responsable de atender las peticiones de los clientes.
Atributos:
_simulaciones, _nClientes
Operaciones:
BuscarHorario, NuevaSimulacion, ResolverSimulacion,
RecuperarTrenesEnTransito
Nombre:
Simulación
Responsabilidad:
Maneja toda la información concerniente a las simulaciones
Atributos:
_motor
Operaciones:
BuscarHorario, Solve
Capítulo 7: Análisis del Proyecto
114
Figura 7.14: Análisis de la clase Motor
Figura 7.15: Análisis de la clase EstadoTransito
Nombre:
Motor
Responsabilidad:
Contiene los algoritmos de búsqueda utilizados para
resolver las simulaciones.
Atributos:
_simulacion
Operaciones:
Init, Solve, GetSolution
Nombre:
EstadoTransito
Responsabilidad:
Maneja toda la información relacionada con el tránsito de
trenes en un momento dado.
Atributos:
_simulacion, _fechaHora, _trenes
Operaciones:
GetTrenes, AgregarSolucion, GetSgteCruzamiento,
GetSgteAlcance
Nombre:
TrenEnTransito
Capítulo 7: Análisis del Proyecto
115
Figura 7.16: Análisis de la clase TrenEnTransito
Figura 7.17: Análisis de la clase Cruzamiento
Responsabilidad: Representa a un tren en circulación
Atributos:
_idBoletin, _transito, _recorrido, _ultEst, _vagones,
_locomotoras
Operaciones:
GetRecorridoItinerario
Nombre:
Cruzamiento
Responsabilidad:
Representa a un cruzamiento entre dos trenes.
Atributos:
_trenA, _trenB, _fhEncuentro, _ptoEncuentro, _soluciones
Operaciones:
GetSoluciones
Nombre:
Paso
Responsabilidad:
Representa a un paso de tren.
Capítulo 7: Análisis del Proyecto
116
Figura 7.18: Análisis de la clase Paso
7.3.3.- Clases de Entidad
A continuación, en la Figura 7.19, el análisis de la clase de entidad BRecorrido.
Figura 7.19: Análisis de la clase BRecorrido
Atributos:
_trenAtr, _trenDel, _fhEncuentro, _ptoEncuentro,
_soluciones
Operaciones:
GetSoluciones
Nombre:
BRecorrido
Responsabilidad:
Representa el itinerario de los trenes. Los tiempos que
demoran de una estación a otra.
Atributos:
_idEstacion, _itiLlegada, _itiSalida
Operaciones:
GetRecorridos
Capítulo 7: Análisis del Proyecto
117
7.4.- ANALISIS DE PAQUETES
Una arquitectura flexible asegura la consistencia del sistema y ayuda a acomodar cambios
futuros, siendo la estructura de paquetes del sistema una parte importante de la misma.
A continuación se presenta el análisis de los paquetes del proyecto, la dependencia entre
ellos y las clases que contienen.
7.4.1.- Dependencia entre Paquetes
En la siguiente figura se muestra la dependencia de los paquetes del proyecto, que
fueron identificados en el Análisis de la Arquitectura (sección 7.2).
Figura 7.20: Diagrama de Dependencia entre Paquetes
Capítulo 7: Análisis del Proyecto
118
7.4.2.- Diagramas de Clases por Paquete
A continuación (Figuras 7.21 a 7.26) se utilizan diagramas de clases por paquete,
para representar las clases necesarias para llevar a cabo los casos de uso descritos en
la captura de requisitos.
Figura 7.21: Diagrama de Clases por Paquete. Paquete: Trenes
Capítulo 7: Análisis del Proyecto
119
Figura 7.22: Diagrama de Clases por Paquete. Paquete: Remoting
Figura 7.23: Diagrama de Clases por Paquete. Paquete: Heurística
Figura 7.24: Diagrama de Clases por Paquete. Paquete: Gráficos
Capítulo 7: Análisis del Proyecto
120
Figura 7.25: Diagrama de Clases por Paquete. Paquete: Forms
Figura 7.26: Diagrama de Clases por Paquete. Paquete: TrafService
121
CAPITULO 8
DISEÑO DEL PROYECTO
l diseño es un refinamiento del análisis que tiene en cuenta los requisitos no
funcionales, en definitiva cómo cumple el sistema sus objetivos. El resultado de este
capítulo es un modelo del sistema hecho de tal forma que cumpla con los requisitos
especificados anteriormente.
8.1.- DISEÑO DE LA ARQUITECTURA
El objetivo del diseño de la arquitectura es esbozar el modelo de diseño mediante la
identificación de nodos y componentes.
8.1.1.- Identificación de Nodos y Componentes
Los diagramas de despliegue sirven para modelar el hardware para el sistema y el
software instalado en ese hardware. Entre los elementos usados en un diagrama de
E
Capítulo 8: Diseño del Proyecto
122
despliegue están: los nodos (cubos), los componentes (cajas rectangulares con dos
rectángulos saliendo desde el lado izquierdo) y las asociaciones. A continuación, en
la Figura 8.1, el diagrama de despliegue del sistema.
Figura 8.1: Diagrama de Despliegue
8.2.- DISEÑO DE CASOS DE USO
Para el diseño de casos de uso se utilizan diagramas de secuencia donde se pueden observar
cómo los objetos del diseño interactúan unos con otros, sus procesos, mensajes entre ellos y
el orden en que ocurren. Estos permiten mostrar un escenario de ejecución simple de forma
gráfica. A continuación (Figuras 8.2 a 8.7) los diagramas de secuencia según los casos de
uso identificados para el sistema.
Capítulo 8: Diseño del Proyecto
123
i. Realizar Proyección
El usuario, mediante una interfaz cliente, solicita al Sistema realizar la proyección
del recorrido de trenes. La solicitud llega a Server, primero para recuperar
información sobre el estado de los trenes en tránsito y después para realizar la
simulación en sí. Una vez obtenido el resultado, la solución es mostrada y los
recorridos de la misma son graficados.
Figura 8.2: Diagrama de Secuencia: Realizar Proyección
Capítulo 8: Diseño del Proyecto
124
ii. Determinar Horario de Salida
El usuario, mediante una interfaz cliente, solicita al Sistema realizar una búsqueda
de horario para una salida de tren, el formulario FrmNewTrenHVar es mostrado, en
él se ingresan los datos necesarios para la búsqueda y se envía la orden a Server para
efectuar la misma. Una vez obtenido, el resultado es mostrado al usuario en el
formulario principal (FrmMain).
Figura 8.3: Diagrama de Secuencia: Determinar Horario de Salida
Capítulo 8: Diseño del Proyecto
125
iii. Elaborar Surcos de Trenes
Después de solicitar una nueva simulación desde el menú del formulario principal
(FrmMain), el usuario ingresa la información necesaria para los surcos en el
formulario FrmNewSimSimpl. La solicitud es mandada a Server, quien a su vez
iniciará los objetos necesarios y ordenará la simulación. Una vez obtenidos, el
resultado es mostrado y los surcos de trenes graficados en el formulario principal.
Figura 8.4: Diagrama de Secuencia: Elaborar Surcos de Trenes
Capítulo 8: Diseño del Proyecto
126
iv. Consultar Hora de Llegada de trenes a estaciones
La solicitud la realiza el usuario a través del formulario principal, la consulta es
hecha sobre la última proyección realizada y el resultado mostrado en el mismo
formulario principal.
Figura 8.5: Diagrama de Secuencia: Consultar Hora de Llegada de trenes a
estaciones
Capítulo 8: Diseño del Proyecto
127
v. Graficar Recorrido
Los gráficos de los recorridos de trenes son hechos por objetos de la clase
Graficador. A su vez se crean objetos TrenLine (líneas de recorrido en el gráfico),
cada uno de los cuales corresponde a un tren en tránsito.
Figura 8.6: Diagrama de Secuencia: Graficar Recorrido
Capítulo 8: Diseño del Proyecto
128
vi. Resolver Simulación
Diferentes tareas realizadas por el Sistema requieren de realizar una simulación del
recorrido de los trenes. La misma se inicia desde Server (objeto encargado de
interactuar con los clientes), sigue por Simulacion, hasta llegar a Motor, donde
residen los algoritmos de búsqueda heurística utilizados para la simulación.
Figura 8.7: Diagrama de Secuencia: Resolver Simulación
Capítulo 8: Diseño del Proyecto
129
8.3.- DIAGRAMAS DE CLASES
Los diagramas de clases constituyen el pilar del análisis y diseño. En UML, los diagramas
de clases muestran las clases del sistema, sus relaciones, y las operaciones y atributos de las
clases.
En la Figura 8.8 se muestra el diagrama de clases del paquete Trenes.
Capítulo 8: Diseño del Proyecto
130
Figura 8.8: Diagrama de Clases: Paquete Trenes
Capítulo 8: Diseño del Proyecto
131
En la Figura 8.9 se muestra el diagrama de clases del paquete Heurística.
Figura 8.9: Diagrama de Clases: Paquete Heurística
Capítulo 8: Diseño del Proyecto
132
En la Figura 8.10 se muestra el diagrama de clases del paquete Remoting.
Figura 8.10: Diagrama de Clases: Paquete Remoting
Capítulo 8: Diseño del Proyecto
133
En la Figura 8.11 se muestra el diagrama de clases del paquete Forms.
Figura 8.11: Diagrama de Clases: Paquete Forms
Capítulo 8: Diseño del Proyecto
134
En la Figura 8.12 se muestra el diagrama de clases del paquete Gráficos.
Figura 8.12: Diagrama de Clases: Paquete Gráficos
En la Figura 8.13 se muestra el diagrama de clases del paquete TrafService.
Figura 8.13: Diagrama de Clases: Paquete TrafService
Capítulo 8: Diseño del Proyecto
135
8.4.- DISEÑO DE DATOS
El diseño de la base de datos se realiza con el fin de eliminar información redundante.
Generalmente contiene la misma información de las clases, sus atributos y relaciones entre
ellas. A continuación las tablas utilizadas desde el sistema e información sobre sus campos:
tipos de dato, tamaño, si permiten o no valores nulos y si sirven de llave primaria (PK) o
foránea (FK).
A continuación (Figuras 8.14 a 8.20) se muestra el diseño de las diferentes tablas utilizadas
en el Sistema.
Tabla: TTren
Descripción: Almacena información concerniente a los trenes.
Figura 8.14: Diseño de Datos. Tabla: TTren
Atributo Tipo de Dato Tamaño Nulo Llave
Nrotren nvarchar 10 No PK
Descripción nvarchar 30 Si
IdTrenTipos nvarchar 5 Si FK
Dias nvarchar 7 Si
HoraSalida datetime 8 Si
IdItinerario int 4 Si FK
Estado tinyint 1 Si
Capítulo 8: Diseño del Proyecto
136
Tabla: TEstacion
Descripción: Alamacena información conerniente a las estaciones.
Figura 8.15: Diseño de Datos. Tabla: TEstacion
Tabla: TTren_Tipos
Descripción: Almacena información relacionada con los tipos de trenes que existen.
Figura 8.16: Diseño de Datos. Tabla: TTren_Tipos
Atributo Tipo de Dato Tamaño Nulo Llave
IdEstacion smallint 2 No PK
Estacion nvarchar 30 Si
Sigla nvarchar 6 Si
Sector nvarchar 1 Si
Tipo tinyint 1 Si
Kmp float 8 Si
LargoDesvio smallint 2 No
Atributo Tipo de Dato Tamaño Nulo Llave
IdTrenTipos nvarchar 5 No PK
Descripción nvarchar 30 Si
Prioridad smallint 2 No
Capítulo 8: Diseño del Proyecto
137
Tabla: TItinerario
Descripción: Almacena los información relacionada al itinerario de los trenes.
Figura 8.17: Diseño de Datos. Tabla: TItinerario
Tabla: TItinerario_Estacion
Descripción: Almacena información relacionada con el itinerario de los trenes y los
tiempos que estos emplean en recorrer las estaciones correspondientes.
Figura 8.18: Diseño de Datos. Tabla: TItinerario_Estacion
Atributo Tipo de Dato Tamaño Nulo Llave
IdItinerario int 4 No PK
Sector nvarchar 1 Si
Descripción nvarchar 60 Si
IdEstOrigen smallint 2 Si FK
IdEstDestino smallint 2 Si FK
Estado tinyint 1 Si
Atributo Tipo de Dato Tamaño Nulo Llave
IdItinerario int 4 No PK
IdEstacion smallint 2 No PK FK
TiempoParada int 4 Si
TiempoRecorrido int 4 Si
OrdenLogico tinyint 1 Si
ParadaObligada int 4 Si
Capítulo 8: Diseño del Proyecto
138
Tabla: TBoletin_Tren
Descripción: Almacena información sobre los boletines de trenes. Siempre que sale un tren
se crea un boletín.
Figura 8.19: Diseño de Datos. Tabla: TBoletin_Tren
Atributo Tipo de Dato Tamaño Nulo Llave
IdBoletin bigint 8 No PK
NroTren nvarchar 10 Si FK
fechaHoraSalida dateTime 8 Si
FechaHoraLlegada dateTime 8 Si
IdEstOrigen smallint 2 Si FK
IdEstDestino smallint 2 Si FK
IdEstTermino smallint 2 Si FK
Sector nvarchar 1 Si
Distancia real 4 Si
Estado tinyint 1 Si
TipoBoletin tinyint 1 Si
Capítulo 8: Diseño del Proyecto
139
Tabla: TBoletin_Recorrido
Descripción: Almacena información sobre los recorridos de los trenes y los tiempos que
éstos desarrollaron. Por cada boletín se crea uno para cada estación del recorrido.
Figura 8.20: Diseño de Datos. Tabla: TBoletin_Recorrido
Atributo Tipo de Dato Tamaño Nulo Llave
IdBRecorrido bigint 8 No PK
IdBoletin bigint 8 No FK
IdEstacion smallint 2 Si FK
ItinerarioLlegada datetime 8 Si
ItinerarioSalida datetime 8 Si
FechaHoraLlegada datetime 8 Si
FechaHoraSalida datetime 8 Si
140
CAPITULO 9
IMPLEMENTACION Y PRUEBAS DEL PROYECTO
a implementación es la realización de la aplicación, la realización de las
especificaciones técnicas o algoritmos para obtener un programa, sistema de
computación o componente de software.
Después de implementado, se puede creer que éste funciona correctamente cuando en
realidad no es así. Es por esta razón que una gran parte del desarrollo de software se enfoca
a una cultura de calidad, de asegurarse de crear software que no tenga defectos, de diseñar
los detalles importantes para evitar que hayan malas interpretaciones. Sin embargo, aunque
la cultura de calidad es lo más importante, no es suficiente y es preciso realizar pruebas que
garanticen que los sistemas funcionan de la manera correcta.
Lo que se quiere mostrar en este capitulo es, empezando con el resultado del diseño, la
implementación del el sistema en forma de componentes, archivos de código, ejecutables,
etc. Se expondrá todos los aspectos relacionados con la implementación del sistema, tales
como ser: el código fuente en un lenguaje de programación y la definición de la base de
datos utilizando un Sistema de Gestión de Base de Datos (SGBD). Además se detallarán
todos los aspectos relacionados con las pruebas del sistema, las cuales son un elemento
L
Capítulo 9: Implementación y Pruebas del Proyecto
141
crítico para garantizar la funcionalidad y calidad del mismo, además de representar una
revisión final de las especificaciones y requisitos.
9.1.- DESCRIPCION DE LAS HERRAMIENTAS DE DESARROLLO
Para la implementación y desarrollo del sistema se utilizaron las siguientes herramientas:
i. Entorno de Desarrollo: Visual Studio 2005
Es un entorno de desarrollo integrado (IDE, por sus siglas en inglés) para la
plataforma .Net. Soporta varios lenguajes de programación tales como: Visual
C++, Visual C#, Visual Basic .Net; y se han desarrollado extensiones para
muchos otros.
.Net es una plataforma de desarrollo con énfasis en la transparencia de redes,
con independencia de plataforma de hardware y que permite un desarrollo
rápido de aplicaciones.
ii. Lenguaje de Programación: C#
Es un lenguaje de programación orientado a objetos desarrollado y
estandarizado por Microsoft como parte de su plataforma .Net, que después fue
aprobado como un estándar como un estándar ECMA e ISO. Se escogió este
lenguaje por la amplia difusión que ha ganado en los últimos años y por la
familiaridad que se tiene con él.
iii. Sistema de Gestión de Base de Datos: SQL Server 2000
Es capaz de poner a disposición de muchos usuarios grandes cantidades de datos
de manera simultánea. Incluye además un potente entorno gráfico de
administración. Es el Sistema Gestor de Base de Datos usado por el Sistema de
Operaciones de la empresa Ferroviaria Oriental.
iv. Sistema Operativo: Microsoft Windows Server 2003
Es un sistema operativo de la familia Windows para servidores. En términos
generales se puede considerar como un Windows XP modificado, no con menos
Capítulo 9: Implementación y Pruebas del Proyecto
142
funciones, sino que éstas están deshabilitadas por defecto para obtener un mejor
rendimiento y para centrar el uso del procesador en las características de
servidor.
9.2.- TRANSFORMACION DE LOS MODELOS DE DISEÑO EN
CODIGO
Para la implementación en un lenguaje de programación orientado a objetos es necesaria la
escritura de código fuente para la Definición de las Clases y la Definición
9.3.- IDENTIFICACIÓN DE LOS COMPONENTES
Para la identificar los componentes existen dos formas:
A partir de clases activas.
A partir de los subsistemas identificados durante el diseño.
A continuación, la identificación de componentes a partir de las clases del análisis y diseño.
9.3.1.- Componentes a partir de la clase Tren
A partir de la clase activa Tren se pueden identificar componentes de estereotipo:
<<File>>: Componente “Tren.cs”
En la figura 9.1 se puede observar el diagrama de componentes correspondiente con
sus respectivas especificaciones en las notas.
Capítulo 9: Implementación y Pruebas del Proyecto
143
Figura 9.1: Identificación de componentes a partir de la clase Tren
9.3.2.- Componentes a partir de la clase TrenEnTransito
A partir de la clase activa TrenEnTransito se pueden identificar componentes de
estereotipo:
<<File>>: Componente “TrenEnTransito.cs”
En la figura 9.2 se puede observar el diagrama de componentes correspondiente con
sus respectivas especificaciones en las notas.
Capítulo 9: Implementación y Pruebas del Proyecto
144
Figura 9.2: Identificación de componentes a partir de la clase TrenEnTransito
A continuación, en la Figura 9.3, la implementación de uno de los métodos dentro
de la clase TrenEnTransito.
Capítulo 9: Implementación y Pruebas del Proyecto
145
Figura 9.3: Segmento de código dentro de TrenEnTransito, método
AvanzarSgteEstacion
public void AvanzarSgteEstacion()
{
if ( _ultEst.Equals( this.Destino ))
{
return;
}
DateTime regFHLlegada = this._fhSgteLlegada;
_ultEst = _sgteEst;
_sgteEst = GetSgteEstacion();
//
// Tiempos de salida y sgte llegada según itinerario
//
DateTime itiNewSalida = TrenEnTransito.GetItinerarioSalida( this );
DateTime itiSgteLlegada = TrenEnTransito.GetItiSgteLlegada( this );
TimeSpan diferencia = TimeSpan.Zero;
if ( _ultEst.Equals( this.Destino )) // el tren llegó a destino
{
RegistrarRecorrido( _ultEst, regFHLlegada, regFHLlegada );
return;
}
diferencia = diferencia.Add( TimeSpan.FromMinutes( this.Atraso ));
diferencia = diferencia.Add( this.PrimerAtraso );
_fhUltSalida = itiNewSalida.Add( diferencia );
_fhSgteLlegada = itiSgteLlegada.Add( diferencia );
_itinerarioSalida = itiNewSalida;
_fechaHora = _fhUltSalida;
_kmEstimado = _ultEst.Kmp;
//
// Dejar o recoger vagones y locomotoras que tengan que
// quedarse o subir en la estacion por la que pasa el tren
//
DejarVagones( _ultEst );
DejarLocomotoras( _ultEst );
RecogerVagones( _ultEst );
RecogerLocomotoras( _ultEst );
//
// Registrar recorrido
//
RegistrarRecorrido( _ultEst, regFHLlegada, _fhUltSalida );
}
Capítulo 9: Implementación y Pruebas del Proyecto
146
9.3.3.- Componentes a partir de la clase Recorrido
A partir de la clase activa Recorrido se pueden identificar componentes de
estereotipo:
<<File>>: Componente “Recorrido.cs”
En la figura 9.4 se puede observar el diagrama de componentes correspondiente con
sus respectivas especificaciones en las notas.
Figura 9.4: Identificación de componentes a partir de la clase Recorrido
9.3.4.- Componentes a partir de la clase Estacion
A partir de la clase activa Estacion se pueden identificar componentes de
estereotipo:
<<File>>: Componente “Estacion.cs”
En la figura 9.5 se puede observar el diagrama de componentes correspondiente con
sus respectivas especificaciones en las notas.
Capítulo 9: Implementación y Pruebas del Proyecto
147
Figura 9.5: Identificación de componentes a partir de la clase Estacion.
9.3.5.- Componentes a partir de la clase EstadoTransito
A partir de la clase activa EstadoTransito se pueden identificar componentes de
estereotipo:
<<File>>: Componente “EstadoTransito.cs”
En la figura 9.6 se puede observar el diagrama de componentes correspondiente con
sus respectivas especificaciones en las notas.
Capítulo 9: Implementación y Pruebas del Proyecto
148
Figura 9.6: Identificación de componentes a partir de la clase EstadoTransito.
A continuación, segmentos de código dentro del componente EstadoTransito.cs. Los
métodos: GetSgteCruzamiento y AvanzarHastaCruzar.
Capítulo 9: Implementación y Pruebas del Proyecto
149
private Cruzamiento GetSgteCruzamiento()
{
ArrayList cruzamientos = new ArrayList();
Cruzamiento result = null;
DateTime fhPrimerCruz = DateTime.MaxValue;
foreach ( TrenEnTransito trenA in TrenesEnTransito )
{
foreach ( TrenEnTransito trenB in TrenesEnTransito )
{
if ( trenA != trenB && trenA.Direccion !=
trenB.Direccion && !ResueltoAntes( trenA, trenB,
cruzamientos ))
{
TrenEnTransito tren1, tren2;
tren1 = trenA;
tren2 = trenB;
if ( tren1.KmActualEstimado >
tren2.KmActualEstimado )
{
continue;
}
if ( tren1.UltimaEstacion.Kmp >
tren2.UltimaEstacion.Kmp ||
tren1.Destino.Kmp < tren2.Destino.Kmp )
continue;
if ( tren1.UltimaEstacion.Equals( tren1.Destino
) || tren2.UltimaEstacion.Equals( tren2.Destino
))
{
continue;
}
if ( YaResuelto( trenA, trenB ))
continue;
double x, y;
TrenEnTransito tren1c = tren1.Clone( this );
TrenEnTransito tren2c = tren2.Clone( this );
if ( !HacerAvanzarHastaCruzar( tren1c, tren2c,
out x, out y, fhPrimerCruz ))
{
continue;
}
if ( tren1.Destino.Kmp >= x &&
tren2.Destino.Kmp <= x )
{
DateTime fhEncuentro = (
tren1c.FechaHora > tren2c.FechaHora
? tren1c.FechaHora.AddHours( y )
: tren2c.FechaHora.AddHours( y ));
if ( fhEncuentro < fhPrimerCruz )
{
fhPrimerCruz = fhEncuentro;
}
Cruzamiento c = new Cruzamiento(
_sector, tren1, tren2, x, y,
fhEncuentro, this );
c.CalcularEstacionesCruzam();
cruzamientos.Add( c );
}
}
}
}
Capítulo 9: Implementación y Pruebas del Proyecto
150
Figura 9.7: Segmento de código dentro de EstadoTransito, método
GetSgteCruzamiento, en donde se obtiene el siguiente cruzamiento a producirse.
//
// result debe quedar con el cruzamiento que se va a
// producir primero
//
if ( cruzamientos.Count > 0 )
{
Cruzamiento sgteC = (Cruzamiento)cruzamientos[ 0 ];
foreach ( Cruzamiento c in cruzamientos )
{
if ( c.FHEncuentro < sgteC.FHEncuentro )
sgteC = c;
}
result = sgteC;
}
return result;
}
Capítulo 9: Implementación y Pruebas del Proyecto
151
private bool HacerAvanzarHastaCruzar( TrenEnTransito tren1,
TrenEnTransito tren2, out double x, out double y,
DateTime fhPrimerCruz )
{
x = 0;
y = 0;
// Igualar tiempos. Con precision de estaciones
//
if ( tren1.FechaHora > tren2.FechaHora )
{
while ( tren1.FechaHora > tren2.FechaHora )
{
if ( tren2.SiguienteEstacion != null &&
(tren2.SiguienteEstacion.Equals(
tren1.SiguienteEstacion ) ||
tren2.SiguienteEstacion.Equals(
tren1.UltimaEstacion ) ||
tren2.UltimaEstacion.Equals(tren1.UltimaEstacion)
))
{
break;
}
tren2.AvanzarSgteEstacion();
if (tren2.LlegoDestino()) return false;
}
}
else
{
while ( tren1.FechaHora < tren2.FechaHora )
{
if ( tren1.SiguienteEstacion != null &&
(tren1.SiguienteEstacion.Equals(
tren2.SiguienteEstacion ) ||
tren1.SiguienteEstacion.Equals(
tren2.UltimaEstacion ) ||
tren1.UltimaEstacion.Equals(tren2.UltimaEstacion))
)
{
break;
}
tren1.AvanzarSgteEstacion();
if ( tren1.LlegoDestino() ) return false;
}
}
// Una vez los dos trenes estan con la misma hora
// hacerlos avanzar hasta que crucen
//
DateTime fhTransito = this.FechaHora;
DateTime fhTren1SgteLleg = tren1.FechaHSgteLlegada;
DateTime fhTren2SgteLleg = tren2.FechaHSgteLlegada;
while ( tren1.SiguienteEstacion.Kmp < tren2.UltimaEstacion.Kmp &&
tren2.SiguienteEstacion.Kmp > tren1.UltimaEstacion.Kmp )
{
if ( fhTransito >= fhTren1SgteLleg )
{
tren1.AvanzarSgteEstacion2();
if ( tren1.UltimaEstacion.Equals( tren1.Destino ))
{
return false;
}
fhTren1SgteLleg = tren1.FechaHora.Add(
tren1.TiempoPrevSgteEst );
}
Capítulo 9: Implementación y Pruebas del Proyecto
152
if ( fhTransito >= fhTren2SgteLleg )
{
tren2.AvanzarSgteEstacion2();
if ( tren2.UltimaEstacion.Equals( tren2.Destino ))
{
//
// uno de los trenes llega antes a su destino
return false;
}
fhTren2SgteLleg = tren2.FechaHora.Add(
tren2.TiempoPrevSgteEst );
}
fhTransito = ( fhTren1SgteLleg > fhTren2SgteLleg
? fhTren2SgteLleg : fhTren1SgteLleg );
//
// Poda
if ( tren1.FechaHora > fhPrimerCruz &&
tren2.FechaHora > fhPrimerCruz )
{
return false;
}
}
// Hasta aqui los trenes estan en dos estaciones seguidas
//
if (tren1.FechaHSgteLlegada < tren2.FechaHUltSalida &&
tren1.FechaHSgteLlegada > tren2.FHUltimaLlegada)
{
DateTime fh1 = (tren1.FechaHora > tren2.FechaHora ?
tren1.FechaHora : tren2.FechaHora);
x = tren2.UltimaEstacion.Kmp;
y = ((TimeSpan)tren1.FechaHSgteLlegada.Subtract(fh1))
.TotalHours;
return true;
}
else if (tren2.FechaHSgteLlegada < tren1.FechaHUltSalida &&
tren2.FechaHSgteLlegada > tren1.FHUltimaLlegada)
{
DateTime fh1 = (tren1.FechaHora > tren2.FechaHora ?
tren1.FechaHora : tren2.FechaHora);
x = tren1.UltimaEstacion.Kmp;
y = ((TimeSpan)tren2.FechaHSgteLlegada.Subtract(fh1))
.TotalHours;
return true;
}
Estacion est1, est2;
if ( tren1.UltimaEstacion.Kmp < tren2.UltimaEstacion.Kmp )
{
est1 = tren1.UltimaEstacion;
est2 = tren2.UltimaEstacion;
}
else
{
est1 = tren2.UltimaEstacion;
est2 = tren1.UltimaEstacion;
}
double v1 = tren1.GetVelocidad( est1, est2 );
double v2 = tren2.GetVelocidad( est2, est1 );
double km1 = tren1.UltimaEstacion.Kmp;
double km2 = tren2.UltimaEstacion.Kmp;
double km1Ini = km1, km2Ini = km2;
Capítulo 9: Implementación y Pruebas del Proyecto
153
Figura 9.8: Segmento de código dentro de EstadoTransito, método
AvanzarHastaCruzar, en donde se calcula el momento y punto de encuentro entre dos
trenes que van a cruzar
// Igualar la posicion de los trenes con respecto al tiempo
//
double recPrev;
TimeSpan dif;
if ( tren1.FechaHora > tren2.FechaHora ) // igualar tren2
{
dif = tren1.FechaHora.Subtract( tren2.FechaHora );
recPrev = v2 * dif.TotalHours;
km2 = km2 - recPrev;
}
else // igualar tren1
{
dif = tren2.FechaHora.Subtract( tren1.FechaHora );
recPrev = v1 * dif.TotalHours;
km1 = km1 + recPrev;
}
// calcular punto y momento del encuentro
//
x = ( v1 * km2 + v2 * km1 ) / ( v1 + v2 );
y = ( x - km1 ) / v1;
return true;
}
Capítulo 9: Implementación y Pruebas del Proyecto
154
9.3.6.- Componentes a partir de la clase Motor
A partir de la clase activa Motor se pueden identificar componentes de estereotipo:
<<File>>: Componente “Motor.cs”
En la figura 9.9 se puede observar el diagrama de componentes correspondiente con
sus respectivas especificaciones en las notas.
Figura 9.9: Identificación de componentes a partir de la clase Motor
A continuación, en la Figura 9.10, la implementación del método GetSolution
dentro de la clase Motor.
Capítulo 9: Implementación y Pruebas del Proyecto
155
Figura 9.10: Método GetSolution dentro del componente Motor.cs
private EstadoTransito GetSolution(EstadoTransito t, EstadoTransito mejorT,
int limH, ref bool end )
{
EstadoTransito result = null;
end = false;
if (t == null)
{
return mejorT;
}
if (limH > 0 && t.Nivel > limH )
{
return t;
}
Cruzamiento cruzam = t.NextCruzamiento();
Paso paso = t.GetSgteAlcance();
ArrayList soluciones;
if (cruzam == null && paso == null)
{
end = true;
return t;
}
soluciones = new ArrayList();
soluciones.AddRange(cruzam.GetSoluciones(_sim.SolucionesP));
soluciones.AddRange(paso.GetSoluciones(_sim.SolucionesP));
//
// Ordenar según Hora de ejecución de la Solución
//
soluciones.Sort();
DejarSolucionesCoherentes(soluciones);
foreach (Solucion s in soluciones)
{
if (s.Estacion == null)
{
break;
}
EstadoTransito newT = t.Clone();
EstadoTransito candidate = null;
newT.AgregarSolucion(s);
if (mejorT != null && newT.H >= mejorT.H) // poda
{
continue;
}
candidate = GetSolution(newT, mejorT, limH, ref end);
if (mejorT == null || candidate.H < mejorT.H)
{
mejorT = candidate;
}
}
return mejorT;
}
Capítulo 9: Implementación y Pruebas del Proyecto
156
9.3.7.- Componentes a partir de la clase Cruzamiento
A partir de la clase activa Cruzamiento se pueden identificar componentes de
estereotipo:
<<File>>: Componente “Cruzamiento.cs”
En la figura 9.11 se puede observar el diagrama de componentes correspondiente
con sus respectivas especificaciones en las notas.
Figura 9.11: Identificación de componentes a partir de la clase Cruzamiento
9.3.8.- Componentes a partir de la clase Paso
A partir de la clase activa Paso se pueden identificar componentes de estereotipo:
<<File>>: Componente “Paso.cs”
En la figura 9.12 se puede observar el diagrama de componentes correspondiente
con sus respectivas especificaciones en las notas.
Capítulo 9: Implementación y Pruebas del Proyecto
157
Figura 9.12: Identificación de componentes a partir de la clase Paso
9.3.9.- Componentes a partir de la clase Solucion
A partir de la clase activa Solucion se pueden identificar componentes de
estereotipo:
<<File>>: Componente “Solucion.cs”
En la figura 9.13 se puede observar el diagrama de componentes correspondiente
con sus respectivas especificaciones en las notas.
Figura 9.13: Identificación de componentes a partir de la clase Solucion
Capítulo 9: Implementación y Pruebas del Proyecto
158
9.3.10.- Componentes a partir de la clase Server
A partir de la clase activa Server se pueden identificar componentes de estereotipo:
<<File>>: Componente “Server.cs”
En la figura 9.14 se puede observar el diagrama de componentes correspondiente
con sus respectivas especificaciones en las notas.
Figura 9.14: Identificación de componentes a partir de la clase Server
9.3.11.- Componentes a partir de la clase Simulacion
A partir de la clase activa Simulacion se pueden identificar componentes de
estereotipo:
<<File>>: Componente “Simulacion.cs”
En la figura 9.15 se puede observar el diagrama de componentes correspondiente
con sus respectivas especificaciones en las notas.
Capítulo 9: Implementación y Pruebas del Proyecto
159
Figura 9.15: Identificación de componentes a partir de la clase Simulacion
9.3.12.- Componentes a partir de la clase Graficador
A partir de la clase activa Graficador se pueden identificar componentes de
estereotipo:
<<File>>: Componente “Graficador.cs”
En la figura 9.16 se puede observar el diagrama de componentes correspondiente
con sus respectivas especificaciones en las notas.
Capítulo 9: Implementación y Pruebas del Proyecto
160
Figura 9.16: Identificación de componentes a partir de la clase Graficador
9.3.13.- Componentes a partir de la clase Service
A partir de la clase activa Service se pueden identificar componentes de estereotipo:
<<File>>: Componente “Service.cs”
En la figura 9.17 se puede observar el diagrama de componentes correspondiente
con sus respectivas especificaciones en las notas.
Capítulo 9: Implementación y Pruebas del Proyecto
161
Figura 9.17: Identificación de componentes a partir de la clase Service
9.4.- IDENTIFICACIÓN DE SUBSISTEMAS DE IMPLEMENTACION
Los paquetes detallados en la etapa de análisis son utilizados para identificar los
subsistemas dentro del modelo de implementación. Cabe recordar que cada uno de los
subsistemas de implementación está compuesto por los componentes que fueron descritos
anteriormente. A continuación, los distintos subsistemas identificados.
9.4.1.- Subsistema Trenes
A partir del paquete Trenes se puede identificar el subsistema del mismo nombre, el
cual está conformado por los siguientes componentes: “Tren.cs”,
“TrenEnTransito.cs”, “EstadoTransito”, “Estacion.cs”, “Vagon.cs”, “Recorrido.cs”
y “Locomotora.cs”.
Figura 9.18: Identificación del subsistema Trenes
Capítulo 9: Implementación y Pruebas del Proyecto
162
9.4.2.- Subsistema Heurística
A partir del paquete Heuristica se puede identificar el subsistema del mismo
nombre, el cual está conformado por los siguientes componentes: “Motor.cs”,
“Solucion.cs”, “Paso.cs” y “Cruzamientos.cs”.
Figura 9.19: Identificación del subsistema Heuristica
9.4.3.- Subsistema Remoting
A partir del paquete Remoting se puede identificar el subsistema del mismo nombre,
el cual está conformado por los siguientes componentes: “Server.cs” y
“Simulacion.cs”.
Figura 9.20: Identificación del subsistema Remoting
9.4.4.- Subsistema ClienteT
A partir del paquete ClienteT se puede identificar el subsistema del mismo nombre,
el cual está conformado por el componente “Graficador.cs” ademas de los
componentes de formularios “FrmMain.cs”, “FrmNewSimSimpl.cs”,
“FrmEscogerTrenes.cs”.
Figura 9.21: Identificación del subsistema ClienteT
Capítulo 9: Implementación y Pruebas del Proyecto
163
9.4.5.- Subsistema TrafService
A partir del paquete TrafService se puede identificar el subsistema del mismo
nombre, el cual está conformado por los siguientes componentes: “Server.cs” y
“Simulacion.cs”.
Figura 9.22: Identificación del subsistema TrafService
9.5.- PLANIFICACION DE LAS PRUEBAS
Para el presente proyecto se han realizado tres tipos de pruebas de unidad, de Integración y
de Sistemas. Las pruebas de unidad consisten en probar los componentes implementados
como unidades individuales; en las pruebas de integración se verificaron que los
componentes interaccionen entre si de manera adecuada y consistente, por ultimo en las
pruebas de sistema se verifico que el sistema trabaje correctamente como un todo.
9.6.- PRUEBAS DE UNIDAD
En las pruebas de unidad se revisa que una unidad de código fuente funcione
correctamente. Si no se dispone de los recursos para hacer una prueba de unidad completa
se deben seleccionar los módulos críticos y los que tengan una elevada complejidad en
ciclos y sólo esos deben probarse.
Se construyeron casos diferentes para los métodos más importantes y se sometieron a
pruebas para comprobar su correcto funcionamiento.
Capítulo 9: Implementación y Pruebas del Proyecto
164
9.7.- PRUEBAS DE INTEGRACION
Las pruebas de integración se refieren a las pruebas de todos los elementos unitarios que
componen un proceso. El objetivo es verificar que un gran conjunto de partes de software
funcionan juntos.
Se utilizaron los casos de uso como referencia para las pruebas de integración, ya que las
realizaciones de los casos de uso describen la interacción y relación de los diferentes
componentes individuales (métodos) probados en las pruebas de unidad.
9.8.- PRUEBAS DE SISTEMA
Las pruebas de sistema se usan para probar que el sistema funciona correctamente como un
todo. Cada prueba de sistema prueba principalmente combinaciones de casos de uso
instanciados bajo condiciones diferentes. Estas condiciones incluyen diferentes
configuraciones de hardware (procesadores, memoria principal, discos duros), diferentes
niveles de carga, diferente numero de actores, etc. Se sometió el sistema a pruebas con
diferentes equipos y sistemas operativos, siendo el único requisito el Framework de .Net
para la plataforma donde se quiera tener ejecutándose el sistema.
165
CONCLUSIONES
Se puede concluir que la aplicación ha sido desarrollada según los requerimientos
establecidos y cubriendo las expectativas que se tenían del mismo.
El sistema grafica el recorrido de trenes en tránsito y permite realizar simulaciones del
recorrido de éstos, resolviendo los cruzamientos y pasos de tren, minimizando los tiempos
de permanencia de los trenes en las estaciones tomando en cuenta las restricciones de las
mismas y las diferentes preferencias entre trenes.
El sistema permite también simular las salidas de trenes en diferentes horarios con el
objetivo de hallar un horario óptimo de salida para los mismos.
Además se pueden realizar las programaciones de surcos, que consisten en simulaciones
desde cero en donde el operador añade a gusto trenes en diferentes días y horarios.
También se han identificado varias funcionalidades que podrían añadirse, como ser la
posibilidad de graficar un determinado periodo de tráfico pasado. Debido a que la
Superintendencia de Transporte podría pedir esta información. Actualmente se guardan las
tablas de circulación de trenes realizadas manualmente por los controladores, pero el
sistema podría tener a disposición esta información de una manera más rápida y en un
formato que resulte más cómodo mediante su exportación a archivos de imágenes.
166
FUENTES DE INFORMACION
BIBLIOGRAFIA
[CARTAINF, 2006] Ferroviaria Oriental S.A.
Carta Informativa Semestral de la Empresa
Año 2, No. 2, Febrero 2006
[SOBRERIELES, 2006] Ferroviaria Oriental S.A.
Revista “Sobre Rieles”
Febrero, 2006
[TESIS1, 2004] Universidad Autónoma Gabriel René Moreno
“Sistema de Monitoreo de trenes mediante GPS y
SIG”,
Ing. Yamil Romero.
[METOD, 2003] Mc Graw Hill
“Metodología de la Investigación”
Roberto Hernández Sampieri, Carlos Fernández
Collado, Pilar Baptista Lucio
Fuentes de Información
167
[IARTIFICIAL, 1996] Prentice Hall
“Inteligencia Artificial: Un Enfoque Moderno”
Stuart Russell, Peter Norvig
León Clavijo Guido
[HEURISTIC, 2004] Springer
“How to Solve It: Modern Heuristics”
Zbigniew Michalewicz, David B. Fogel
2004
[PRESSMAN, 1997] Mc Graw Hill
“Ingeniería del Software: Un enfoque práctico”
Presuman, Roger S.
Madrid, 1997
[RUP01, 2003] Addison Wesley
“The Rational Unified Process Made Easy - A
Practitioner's Guide to the RUP”
Per Kroll, Philippe Kruchten
2003
[RUP02, 2000] Addison Wesley
Fuentes de Información
168
“The Rational Unified Process: An Introduction”
Philippe Kruchten
2000
[VIASFERREAS, 2001] Universidad Mayor de San Simón
“Vías Férreas”
Primera Edición 2001
León Clavijo Guido
SITIOS WEB
[INTRANET] Ferroviaria Oriental S.A.
Intranet de la empresa
[GYW] Genesee & Wyoming Inc.
http://www.gwrr.com
[WIKIPEDIA] Wikipedia
www.wikipedia.com
Enciclopedia colaborativa de carácter libre.
[TODOTRENES] Web “Todo Trenes”
http://www.todotrenes.com
Web dedicada a los ferrocarriles
Fuentes de Información
169
ENTREVISTAS
Entrevistas a personal de la empresa:
Ing. Juan Carlos Revollo, Gerente de Operaciones
Armando Quiroga, Jefe de Tráfico
Julio Cesar Tardío, Jefe del Puesto de Control de Trenes
Ing. Enrique Alarcón, Sub-Gerente de Operaciones
Elvis Velasco, anterior Jefe del Puesto de Control de Trenes
Ing. Yamil Romero, Jefe del Área de Telecomunicaciones
Ing. Dante Montero, Jefe del Área de Desarrollo y Tecnología
Wilson Barba Escalante, Controlador de Tráfico
Rosendo Rivero Justiniano, Controlador de Tráfico
Carlos Flores Do Santos, Controlador de Tráfico
Wilson Ivanov Sulzer, Controlador de Tráfico
Daniel Añez Salazar, Controlador de Tráfico
Ivo Velasco Suarez, Controlador de Tráfico
Fernando Argota Moreno, Controlador de Tráfico
Denner Torrez Barrerro, Controlador de Tráfico
170
ANEXO A
PANTALLAS DEL SISTEMA
i. Pantalla con Simulación Realizada sobre el Tráfico Actual de Trenes
Anexo A: Pantallas del Sistema
171
ii. Pantalla Para Añadir/Editar Trenes de una Simulación
Anexo A: Pantallas del Sistema
172
iii. Pantalla con Información de Cruzamientos y Pasos de Trenes de una Simulación
Anexo A: Pantallas del Sistema
173
iv. Pantalla con Ampliación Realizada al Gráfico de una Simulación
Fuentes de Información
174