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


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


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]


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


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


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


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


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.


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.


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.


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


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]


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.


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


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.


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.


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]


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.


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


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.


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.


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


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]


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


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.


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.


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


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.


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.


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.


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.


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.


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.


47

Figura 3.4: Estación de paso para pasajeros


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,


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


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


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


Figura 3.7: Riel de tipo Vignol.


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.


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.


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.


53

Figura 3.11: Aparatos de vía (Sapo)


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.



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


3.3.2.3.- Líneas de Tránsito General, Urbanas y Sub-urbanas


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.


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,


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.


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.


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


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


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



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


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.


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



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


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.


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.

http://es.wikipedia.org/wiki/Analista


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


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.


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.


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.


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.


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:


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.


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.


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.


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.


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.


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.


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.


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.


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


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


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


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.


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


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


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


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.


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.


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.


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.


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.


98


Figura 6.10: Caso de Uso: Elaborar Surcos de Trenes

Código: CU-3

Nombre:


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.


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.


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.


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


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.


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


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


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


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


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


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


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


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


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


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


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


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.


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


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


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


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


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.


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


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


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


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


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


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


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.


130

Figura 8.8: Diagrama de Clases: Paquete Trenes


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


132

En la Figura 8.10 se muestra el diagrama de clases del paquete Remoting.

Figura 8.10: Diagrama de Clases: Paquete Remoting


133

En la Figura 8.11 se muestra el diagrama de clases del paquete Forms.

Figura 8.11: Diagrama de Clases: Paquete Forms


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


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


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


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


IdTrenTipos nvarchar 5 No PK


Prioridad smallint 2 No


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


IdItinerario int 4 No PK



IdEstOrigen smallint 2 Si FK

IdEstDestino smallint 2 Si FK

Estado tinyint 1 Si


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


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


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


Distancia real 4 Si

Estado tinyint 1 Si

TipoBoletin tinyint 1 Si


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


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


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.


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”




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.


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 );

}


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”



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”




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”




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.


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 );

}

}

}

}


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;

}


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 );

}


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;


}

else

{



}

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;


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;

}


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”



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.


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;

}


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”




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”



Figura 9.13: Identificación de componentes a partir de la clase Solucion


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”



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”




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”




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”




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


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


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.


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


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

http://www.gwrr.com/

http://www.todotrenes.com/


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


172

iii. Pantalla con Información de Cruzamientos y Pasos de Trenes de una Simulación


173

iv. Pantalla con Ampliación Realizada al Gráfico de una Simulación


174

Documents

Sistema para Cruzamientos de Trenes