Embed Size (px)
Citation preview
i
DISEÑO DE UN SISTEMA DE INFORMACIÓN PARA REPRESENTAR ESPACIALMENTE EL NIVEL DE CONGESTIÓN EN EL SISTEMA DE TRANSPORTE
MASIVO TRANSMILENIO A PARTIR DE LA UBICACIÓN REPORTADA POR LOS USUARIOS.
ANDRÉS FERNANDO DÍAZ GUZMÁN
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
ESPECIALIZACIÓN EN INGENIERÍA DE SOFTWARE BOGOTÁ, COLOMBIA
2015
ii
DISEÑO DE UN SISTEMA DE INFORMACIÓN PARA REPRESENTAR ESPACIALMENTE EL NIVEL DE CONGESTIÓN EN EL SISTEMA DE TRANSPORTE
MASIVO TRANSMILENIO A PARTIR DE LA UBICACIÓN REPORTADA POR LOS USUARIOS.
Presentado por:
ANDRÉS FERNANDO DÍAZ GUZMÁN
TESIS REALIZADA COMO REQUISITO PARA OPTAR AL TÍTULO DE ESPECIALISTA EN INGENIERÍA DE SOFTWARE
Director: Ph.D SANDRO JAVIER BOLAÑOS CASTRO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR COLOMBIA
2015
iii
ADVERTENCIA
UNIVERSIDAD FRANCISCO JOSÉ DE CALDAS Especialización en Ingeniería de Software
Bogotá, D.C. – 2015
Todos los contenidos de esta tesis son producto de la contribución intelectual del autor, los datos y referencias a materiales ya publicados están debidamente identificados con su respectivo crédito e incluidos en las referencias bibliográficas y en las citas que se mencionan y en los casos que así lo requiera, contamos con las debidas autorizaciones de quienes poseen los derechos patrimoniales.
Por lo anterior declaro que todos los materiales que se presentan están totalmente libres de
derechos de propiedad intelectual, exonerando de responsabilidades a la Universidad Distrital Francisco José de Caldas.
En virtud de lo previsto en los artículos 76 t 77 de la ley 23 de 1982 de la República de
Colombia y las demás normas internacionales sobre Derechos de Autor, y en caso de ser publicada la Tesis por la Universidad; está podrá disponer en toda su extensión para realizarse en forma electrónica (digital).
Por medio de la presente autorizo a la Universidad Distrital Francisco José de Caldas para
publicar en formato digital con las seguridades pertinentes, tanto en red local como en la gran red Internet, en sitio web de la Universidad o en hosting especial para ello, siempre y cuando se haga sin fines de lucro y con el fin de divulgar el conocimiento a la comunidad académica y científica nacional e internacional de acuerdo con las condiciones establecidas, a fin que la investigación realizada pueda continuar y ser ampliada en caso necesario.
Para constancia de lo anteriormente expuesto, se firma esta declaración: Firma: _______________________ Nombre: Andrés Fernando Díaz Guzmán C.C. 80.055.783
iv
Universidad Distrital Francisco José de Caldas Especialización en Ingeniería de Software
Andrés Fernando Díaz Guzmán
Tesis presentada para optar el título de Especialista en Ingeniería de Software
__________________________ __________________________ __________________________
__________________________ Director
__________________________ __________________________ __________________________
__________________________ Jurado
__________________________ __________________________ __________________________
__________________________ Jurado
Bogotá, D.C., 2015
v
AGRADECIMIENTOS
Deseo expresar mi gratitud a los Ingenieros Daniel Romero y Javier Mosquera, pues su
apoyo incondicional me permitió realizar este proyecto; agradezco también al director de la
especialización, Ingeniero Sandro Javier Bolaños Castro, a las Ingenieras Lilian Bejarano Garzón
y Amalia Carrillo, por su admirable dedicación y colaboración.
vi
DEDICATORIA
Dedico este esfuerzo a Dios, quien me fortalece para afrontar las adversidades.
A Sandra, Estefanía y Kamila, ellas son la motivación más importante de mi vida.
vii
RESUMEN
Proyecto de grado radicado ante la Facultad de Ingeniería de la Universidad Distrital
Francisco José de Caldas para optar al título de Especialista en Ingeniería de Software. El
proyecto aborda la definición arquitectural para el desarrollo de un sistema de información, que
mediante dispositivos smart mobile se nutra y presente el nivel de congestión en el sistema de
transporte público Transmilenio.
El proyecto involucra conceptos de arquitectura empresarial (Togaf versión 9), ingeniería de
software (modelo de vistas 4 + 1 y metodología de desarrollo XP), y leguajes para modelamiento
(UML y Archimate) con los cuales se construyó el diseño arquitectural de la herramienta, que
permite mitigar la congestión del sistema de transporte ocasionada por el uso inadecuado del
sistema, o por deficiencia de información que permita planificar los traslados a través del sistema
de transporte masivo.
viii
TABLA DE CONTENIDO
CAPITULO 1 ................................................................................................................................ 15
1.1 Introducción.................................................................................................................... 15
1.2 Justificación .................................................................................................................... 15
1.2.1 Metodológica ....................................................................................................15
1.2.2 Practica .............................................................................................................16
1.3 Objetivos ........................................................................................................................ 16
1.3.1 Objetivo General ...............................................................................................16
1.3.2 Objetivos Específicos ........................................................................................16
CAPITULO 2 ................................................................................................................................ 18
2.1 Estudio del problema ...................................................................................................... 18
2.1.1 Planteamiento del problema ..............................................................................18
2.1.2 Formulación del Problema.................................................................................18
2.1.3 Sistematización del Problema ............................................................................18
CAPITULO 3 ................................................................................................................................ 20
3.1 Marco Teórico ................................................................................................................ 20
3.2 Marco Conceptual ........................................................................................................... 21
3.2.1 Sistema de Información Geográfica ...................................................................21
3.2.2 Business Model Canvas .....................................................................................22
ix
3.2.3 Factores de expansión .......................................................................................23
3.2.4 MVC .................................................................................................................24
3.2.5 Introducción a Servicios Web ............................................................................24
3.2.6 Internet .............................................................................................................26
3.2.7 Software Libre ..................................................................................................26
3.2.8 Bases de Datos NoSQL .....................................................................................27
3.2.9 UML .................................................................................................................28
3.2.10 Arquitectura de Software .................................................................................28
3.2.11 Ingeniería de Tránsito .....................................................................................30
3.2.12 Moovit (www.moovitapp.com/es/) ..................................................................32
3.2.13 Waze (http://www.waze.com) .........................................................................32
3.2.14 Here (http://www.here.com) ............................................................................33
3.2.15 Bing Maps (http://www.bing.com/maps/) ........................................................33
3.2.16 TomTom (http://www.tomtom.com/livetraffic) ...............................................33
3.3 Marco Espacial ............................................................................................................... 34
3.4 Marco Temporal ............................................................................................................. 34
CAPITULO 4 ................................................................................................................................ 35
4.1 Tipo de Estudio ............................................................................................................... 35
4.2 Método de Investigación ................................................................................................. 35
4.3 Modelo de Vistas 4+1 ..................................................................................................... 36
4.3.1 La Arquitectura Lógica .....................................................................................36
4.3.2 La Vista de Procesos .........................................................................................38
x
4.3.3 Vista de Desarrollo ............................................................................................41
4.3.4 Arquitectura Física ............................................................................................44
4.3.5 Escenarios .........................................................................................................46
4.3.6 Correspondencia entre las Vistas .......................................................................48
4.3.7 Confeccionando el Modelo ................................................................................54
4.3.8 Documentación de la Arquitectura .....................................................................57
4.4 Metodología eXtreme Programming(XP) ........................................................................ 58
4.4.1 Fases de gestión del proyecto ............................................................................58
4.4.2 Desarrollo del proyecto .....................................................................................61
4.5 Fuentes y Técnicas para Recolección de Información ...................................................... 65
4.5.1 Fuentes Primarias ..............................................................................................65
4.5.2 Fuentes Secundarias ..........................................................................................66
4.5.3 Recolección de la Información ..........................................................................66
4.5.4 Tratamiento de la Información...........................................................................67
CAPITULO 5 ................................................................................................................................ 68
5.1 Diseño Arquitectural ....................................................................................................... 68
5.1.1 Introducción ......................................................................................................68
5.1.2 Alcance .............................................................................................................71
5.1.3 Delimitaciones ..................................................................................................71
5.1.4 Lienzo de modelo de negocio ............................................................................71
5.1.5 Requerimientos Funcionales ..............................................................................73
5.1.6 Requerimientos no Funcionales .........................................................................74
xi
5.1.7 Vista de Escenarios ...........................................................................................75
5.1.8 Vista Lógica ......................................................................................................76
5.1.9 Vista de Despliegue...........................................................................................80
5.1.10 Vista de Procesos ............................................................................................82
5.1.11 Vista Física .....................................................................................................85
5.1.12 Mockup ..........................................................................................................86
5.2 Diseño de la Base de Datos ............................................................................................. 87
5.2.1 Variables ...........................................................................................................87
5.2.2 Modelo Entidad-Relación ..................................................................................88
5.2.3 Sistema de Referencia .......................................................................................90
5.2.4 Sistema de Almacenamiento Geográfico ...........................................................90
5.3 Roadmap ........................................................................................................................ 92
5.3.1 Planificación de Actividades .............................................................................92
5.3.2 Cuadro de Costos ..............................................................................................92
CONCLUSIONES ......................................................................................................................... 94
PROSPECTIVA ............................................................................................................................ 95
BIBLIOGRAFÍA ........................................................................................................................... 96
12
TABLA DE ILUSTRACIONES
Ilustración 1. Modelo de "4 + 1" vistas ....................................................................................................36
Ilustración 2. Notación para la vista lógica ..............................................................................................38
Ilustración 3. Notación para el diagrama de procesos ...............................................................................40
Ilustración 4.Diagrama (parcial) de procesos para Télic PBX ..................................................................42
Ilustración 5. Notación para el diagrama de desarrollo .............................................................................43
Ilustración 6. Notación para el diagrama físico ........................................................................................45
Ilustración 7. Diagrama físico de PABX ..................................................................................................45
Ilustración 8. Una pequeña arquitectura física de PABX con emplazamiento de procesos ........................46
Ilustración 9. Diagrama físico para un PABX más grande incluyendo emplazamiento de procesos..........47
Ilustración 10. Mapeo de la vista lógica a la vista de procesos .................................................................52
Ilustración 11. Punteo de un documento de Arquitectura de Software ......................................................57
Ilustración 12. Esquema metodológico ....................................................................................................58
Ilustración 13. Punto de vista cooperación de Aplicación ........................................................................69
Ilustración 14. Punto de Vista Comportamiento de Aplicación ................................................................70
Ilustración 15. Artefactos de la vista de escenarios ..................................................................................75
Ilustración 16. Diagrama de casos de uso ................................................................................................76
Ilustración 17. Artefactos de la vista lógica .............................................................................................76
Ilustración 18. Diagrama de clases del servidor de aplicaciones ...............................................................77
Ilustración 19. Diagrama de clases de la aplicación mobile ......................................................................78
Ilustración 20. Diagrama de secuencia "Registrar Usuario .......................................................................79
Ilustración 21. Diagrama de secuencia "Autenticar Usuario" ...................................................................79
Ilustración 22. Diagrama de secuencia "Consulta Congestión Sistema"....................................................80
13
Ilustración 23. Diagrama de secuencia "Informar Anomalías" .................................................................80
Ilustración 24. Artefactos de la vista de despliegue ..................................................................................81
Ilustración 25. Diagrama de componentes ...............................................................................................81
Ilustración 26. Artefactos de la vista de procesos .....................................................................................82
Ilustración 27. Diagrama de actividades consulta de congestión estación .................................................83
Ilustración 28.Diagrama de actividades consultar congestión y tiempo de llegada bus..............................84
Ilustración 29. Artefactos de la vista física ..............................................................................................85
Ilustración 30. Diagrama de Despliegue ..................................................................................................85
Ilustración 31 Prototipo de aplicación. .....................................................................................................86
Ilustración 32. Diagrama del modelo E-R ................................................................................................88
Ilustración 33. Diagrama de planificación de actividades .........................................................................92
Ilustración 34. Costos recurso humano ....................................................................................................93
14
LISTA DE TABLAS
Tabla 1. Acta de avances del proyecto. ....................................................................................................61
Tabla 2. Planificación de Iteraciones. ......................................................................................................61
Tabla 3. Planificación de Historias. .........................................................................................................62
Tabla 4. Planificación de Tareas. .............................................................................................................62
Tabla 5. Planeación de Bases de Datos. ...................................................................................................63
Tabla 6. Implementación de recursos al sistema Bases de Datos. .............................................................64
Tabla 7. Pruebas de base de datos ............................................................................................................64
Tabla 8. Planificación de Pruebas ............................................................................................................65
Tabla 9. Parámetros de la proyección cartesiana, Ciudad Bogotá datum MAGNA-SIRGAS ....................90
15
CAPITULO 1
1.1 Introducción
El presente documento expone el modo en que se abordará el diseño de una herramienta que
tiene por propósito brindar información sobre el estado de operación y nivel de congestión del
sistema de transporte masivo Transmilenio, a partir de información georeferenciada adquirida de
los usuarios del mismo.
1.2 Justificación
1.2.1 Metodológica
Los problemas derivados de la congestión vehicular tienen tanta importancia a nivel
mundial, que empresas como Microsoft, Google, Apple y Nokia implementaron o adquirieron
sistemas para monitorear y representar el tránsito vehicular en las principales ciudades del
mundo.
En la ciudad de Bogotá se ha evidenciado que el nivel de congestión en el sistema de
transporte masivo Transmilenio ha aumentado de forma significativa con el paso de los años,
debido a lo anterior se puede considerar un referente el uso de aplicaciones que permitan mejorar
la planificación del uso de estos sistemas de trasporte por parte de los usuarios.
El diseño de un sistema de información para los usuarios del transporte masivo de la ciudad
de Bogotá que opere como canal de comunicación sobre el estado de operación y el nivel de
congestión del mismo mejorará la toma de decisión de los usuarios del sistema de trasporte al
momento de acceder a cualquiera de las estaciones de servicio.
16
1.2.2 Practica
El sistema de transporte Transmilenio cuenta con un centro de control de la operación a
través del cual se supervisa continuamente el funcionamiento del sistema. Dicho control se puede
realizar, ya que los buses se encuentran dotados con equipos GPS, computadores y sistemas de
comunicación que permite integrar a los conductores, las estaciones, el centro de control y los
inspectores del sistema. En adición, el sistema está equipado con un circuito cerrado de
televisión, el cual permite monitorear el comportamiento de los usuarios del sistema, y
simultáneamente inspeccionar la operación.
La tecnología y el despliegue logístico con que cuenta el sistema, tienen un valor económico
muy alto, el cual debería reducirse en la medida que la empresa Transmilenio destine estos
recursos para involucrar al usuario como parte de la solución. Actualmente los recursos se
invierten para controlar cuando el sistema está congestionado, más no se enfocan en intentar
reducir la congestión, por tal razón se deben construir soluciones del lado del usuario para su
beneficio.
1.3 Objetivos
1.3.1 Objetivo General
Diseñar un sistema de información para plataformas móviles, que permita dimensionar y
representar el nivel de congestión en el sistema Transmilenio a partir de la localización reportada
por los diferentes usuarios en la ciudad de Bogotá.
1.3.2 Objetivos Específicos
1. Calcular el índice de congestión a partir de posiciones reportadas desde dispositivos
smart mobile en buses, estaciones y taquillas.
17
2. Diseñar un modelo de datos espaciales, mediante la adquisición de las posiciones
reportadas desde los dispositivos smart mobile, que se encuentren en las zonas de
interés, para reporte de información de congestión e identificación de rutas.
3. Identificar las rutas de los articulados en modo pasivo, a través del geoprocesamiento
de posiciones reportadas, para enriquecer la información ofrecida a los usuarios de la
herramienta.
18
CAPITULO 2
2.1 Estudio del problema
2.1.1 Planteamiento del problema
El sistema de transporte masivo Transmilenio, atiende la mayor demanda de viajes dentro de
la ciudad, las cifras oficiales de la subgerencia técnica y de servicios de Transmilenio S.A.
informa que un día típico viajan 2.180.000 usuarios aproximadamente, y de este universo el
45,62% de los pasajeros, ingresan al sistema por 20 de las 137 estaciones que lo componen lo
cual representa el 15% de las estaciones disponibles.
El ingreso de los 995.544 (45,62%) usuarios por el 15% de las estaciones, evidencia el
desconocimiento por parte de los usuarios, sobre el acceso y uso adecuado del servicio de
transporte, factor que se amplía debido a la ausencia de un canal de comunicación adecuado que
informe al usuario, sobre el estado de operación y nivel de congestión del sistema.
2.1.2 Formulación del Problema
¿El nivel de congestión en el sistema Transmilenio podrá reducirse mediante su
dimensionamiento y presentación a través de un sistema de información?
2.1.3 Sistematización del Problema
¿Podrá el sistema de información mejorar las condiciones de acceso y prestación del
servicio?
19
¿Podrá el sistema de información permitir al usuario elegir la hora y la estación más
adecuadas para ingresar al Transmilenio?
¿Podrá el sistema de información aportar a la construcción de la cultura ciudadana en
materia de uso y conservación del Transmilenio?
20
CAPITULO 3
3.1 Marco Teórico
El artículo 1 de la constitución política en su titulo 1 enuncia entre otros elementos
importantes, que el estado Colombiano ha sido fundado en el respeto de la dignidad humana, el
trabajo y la solidaridad de las personas que lo integran, además destaca la prevalencia del interés
general sobre el interés particular.
Según el artículo 2 de la constitución, el fin del estado consiste en facilitar la participación de
todos los ciudadanos en las decisiones que afecten su vida económica, política, administrativa y
cultura, asegurando la convivencia pacífica y la vigencia de un orden justo para sus habitantes.
De acuerdo a lo anterior, las congestiones presentadas en el sistema de trasporte masivo
Transmilenio en la ciudad de Bogotá D.C, vulneran algunos de los principios y derechos
establecidos en la constitución política para la dignidad y el beneficio de los colombianos, dichos
problemas se originan en gran medida debido al desconocimiento de la ciudadanía sobre el estado
de operación y congestión de las estaciones de servicio de Transmilenio, lo que lleva a que el
usuario no pueda planificar un uso adecuado del servicio valiéndose de información inmediata
sobre el estado de congestión de los buses, las estaciones y las zonas de taquillas.
El auge de las aplicaciones informáticas, específicamente las aplicaciones móviles se debe
primordialmente a la facilidad de acceso a dispositivos tipo Smart y la confianza que genera la
tecnología para solucionar problemas específicos en las ciudades. Aunque son múltiples las
aplicaciones disponibles para apoyar los temas relacionados con movilidad y sitios de interés, en
Bogotá son pocas las que ofrecen servicios que informen el estado y la congestión del sistema
21
Transmilenio, unido a esto, los servicios disponibles son deficientes porque se basan en el
concepto de redes sociales, en donde el propósito fundamental tiene un enfoque hacia el beneficio
económico del proveedor de la tecnología restando importancia al beneficio de la comunidad
objetivo a la cual va dirigida la solución.
3.2 Marco Conceptual
3.2.1 Sistema de Información Geográfica
Un sistema de información geográfica es una herramienta informática que utilizamos para
estudiar eventos que ocurren en nuestro planeta, los cuales pueden tener origen natural, o son
consecuencia de la intervención del hombre; finalmente buscamos entender la relación de los
eventos con el entorno donde acontecen, con el fin de controlar el modo en que estos transcurren
o el impacto en la humanidad y demás seres vivientes.
Los Sistemas de Información Geográfica (SIG) surgieron en la década del 60, a partir del
avance en distintas áreas vinculadas con la informática, la geografía, la cartografía y la
información. Si bien su historia es relativamente reciente, la tecnología de los SIG ha tenido un
crecimiento muy importante y muy acelerado desde sus primeros años y hoy, puede observarse
una amplia y muy variada utilización en distintas áreas de nuestra sociedad.
En relación al tema de tránsito y transporte, las aplicaciones SIG más frecuentes son:
Localización: Aplicaciones en las cuales el usuario puede consultar rutas, y diferentes
sitios de interés.
Rutas Óptimas: Aplicaciones diseñadas para asistir al usuario en la elección de la ruta que
mejor se ajuste a ciertas determinantes, usualmente se habla de costo y tiempo. Para la
22
realización de análisis de este tipo se involucran avanzadas técnicas estadísticas y
matemáticas.
3.2.2 Business Model Canvas1
El modelo de negocios Canvas en reconocido a nivel internacional como una herramienta de
análisis empresarial muy útil. Este modelo fue creado por Alexander Osterwalder, y tiene por
propósito definir el modelo de negocio mediante su segmentación en nueve módulos básicos, los
cuales reflejan la lógica que debe seguir una empresa para aumentar los ingresos y definir su
propuesta de valor, involucrando los elementos principales del negosio (clientes, oferta,
infraestructura y viabilidad).
Los nueve módulos son:
Segmentos de clientes: Una empresa debe orientarse a uno o varios segmentos de
clientes.
Propuestas de valor: El objetivo es resolver problemas de los clientes y satisfacer sus
necesidades con propuestas de valor.
Canales: Es la forma cómo se distribuirá o cómo se hará llegar a los clientes la
propuesta de valor.
Relaciones con los clientes: Son los mecanismos para establecer y mantener
relaciones con cada segmento de clientes.
Fuentes de ingresos: Se establece cuáles son los ingresos generados por la propuestas
de valor.
Recursos clave: Se indican cuáles son los recursos o activos necesarios para obtener y
entregar la propuesta de valor. 1 Cordero, Carlos (2012). Defina su negocio en nueve pasos con el modelo canvas. Consultado el 28 de Junio
de 2015, de http://www.elfinancierocr.com/pymes/Defina-negocio-pasos-Modelo-Canvas_0_207579716.html.
23
Actividades principales: Se enumeran las actividades que son fundamentales para
producir y entregar la propuesta de valor.
Alianzas clave: Debido a que algunas actividades se externalizan y algunos recursos
se adquieren fuera de la empresa, es necesario saber cuáles alianzas con proveedores,
distribuidores y otras empresas pueden ayudar a esos propósitos.
Estructura de precio: El modelo de negocios exitoso obtiene ingresos y beneficios,
cubriendo los costos sin impedir que los clientes adquieran el producto o servicio.
3.2.3 Factores de expansión
De acuerdo a la teoría de muestreo el factor de expansión es la capacidad que tiene cada
individuo seleccionado en una muestra probabilística para representar el universo en el cual está
contenido. Es decir, es la magnitud de representación que cada selección posee para describir una
parte del universo de estudio.
Cuando el diseño es MAS se asume que individuos dentro de una misma unidad de muestreo
tienen la misma capacidad de representar al universo en consideración, en tanto que diferentes
unidades de muestreo deben reflejar lo mejor posible la densidad y distribución del universo
estudiado.
Todas las pautas anteriores se logran con la construcción u obtención de marcos muéstrales
que deben proveer información fiel sobre las características demográficas principales del universo
que se pretende estudiar; además debe permitir de alguna forma, ubicar a todos y cada uno de los
individuos pertenecientes a dicho universo.
24
3.2.4 MVC
El Modelo-Vista-Controlador (MVC) es un patrón de arquitectura de software que separa los
datos y la lógica de negocio (Modelo) de una aplicación de la interfaz de usuario (Vista) y el
módulo encargado de gestionar los eventos y las comunicaciones (Controlador).
3.2.5 Introducción a Servicios Web
La Internet (WWW – World Wide Web) tuvo acogida entre los habitantes de las metrópolis
mundiales a comienzos de los años 90 a pesar que en sus inicios pocas personas tenían acceso al
contenido de la red, que en su momento, estaba conformado con documentos de tipo confidencial.
Dado el potencial que ofreció esta novedad, inició el intercambio de información de diferentes
temáticas, facilitado por la visualización de contenidos a través del lenguaje de hipertexto
(HTML - HyperText Markup Language) el cual vinculaba la información para que pudiera ser
buscada y consultada por usuarios de todo el mundo.
En la siguiente etapa, las organizaciones encontraron en esta tecnología la oportunidad de
administrar y distribuir información entre clientes, pero las herramientas disponibles no eran
suficientes para implementar soluciones que asegurarán las nacientes transacciones del comercio
electrónico; ante esta necesidad surgió un protocolo para transmitir información privada vía
Internet (SSL – Secure Socket Layers).
Las expectativas de los usuarios fueron cada vez mayores y exigentes respecto a la variedad
y temporalidad de la información en las organizaciones, las cuales a su vez afrontaban el reto de
conectar sus diferentes sistemas para mejorar la productividad (Bases y bodegas de datos,
planeación de recursos (ERP - Enterprise Resource Planning) y gestión de clientes (CRM -
25
Customer Relationship Management)). La integración de estos sistemas (EAI - Enterprise
Application Integration) fue posible a través de protocolos desarrollados en cada organización
mediante el uso de frameworks, y a pesar de haber sido útiles, fueron soluciones costosas que
adicionalmente presentaban muchas dificultades técnicas a la hora de integrar sistemas internos y
externos.
En el siguiente nivel, las demandas del mercado exigieron que las organizaciones mejoraran
la capacidad de respuesta a proveedores, socios y clientes, y que en la cadena de la productividad,
las transacciones se realizaran en doble sentido con mayor agilidad y seguridad. Este nivel de
integración se alcanzó mediante el desarrollo de soluciones empresa a empresa (B2B – Business
to Business), cuya fortaleza se basó en la utilización del XML (Extensible Markup Language)
como lenguaje para representar datos.
El XML aportó múltiples beneficios, sin embargo, las estrategias B2B habían llevado al
desarrollo de aplicaciones cuya arquitectura frecuentemente era de difícil adaptación a la
dinámica del negocio, por tal razón las expectativas de crecimiento del negocio estaban
determinadas por el avance de las aplicaciones. En consecuencia y para superar estas
limitaciones, el concepto de arquitectura orientada a servicios (SOA – Service Oriented
Architecture) se presenta y se define como un método de diseño, desarrollo, despliegue y gestión
en la red. Los objetivos de la arquitectura SOA son: mejorar la estructuración, articulación
flexible, y la normalización de la funcionalidad de negocios entre aplicaciones. La
implementación de la arquitectura SOA tiene como eje tecnológico la utilización de XML y los
Servicios Web.
26
La World Wide Web Consortium define los Servicios Web como: “…un sistema de software
diseñado para soportar interacción interoperable máquina a máquina sobre una red. Este tiene una
interface descrita en un formato procesable por una máquina (específicamente WSDL). Otros
sistemas interactúan con el servicios web en una manera prescrita por su descripción usando
mensajes SOAP, típicamente enviados usando HTTP con una serialización XML en relación con
otros estándares relacionados con la web”. Se puede definir de manera más sencilla como un
conjunto de tecnologías estándares de software para el intercambio de datos entre aplicaciones
tales como SOAP (Simple Object Access Protocol), WDSL (Web Services Description
Language) y UDDI (Universal Description, Discovery and Integration). Estos pueden ser
desarrollados en una gran variedad de lenguajes para ser implementados sobre muchos tipos de
redes de computadores. The Organization for the Advancement of Structured Information
Standards y el World Wide Web Consortium son los responsables de la estandarización y
arquitectura de los servicios web.
3.2.6 Internet
Internet es un conjunto descentralizado de redes de comunicación interconectadas que
utilizan la familia de protocolos TCP/IP, lo cual garantiza que las redes físicas heterogéneas que
la componen funcionen como una red lógica única, de alcance mundial.
3.2.7 Software Libre
Según la FSF (Free Software Foundation), software libre es el software que respeta la
libertad de los usuarios y la comunidad. En grandes líneas, significa que los usuarios tienen la
libertad para ejecutar, copiar, distribuir, estudiar, modificar y mejorar el software. Un programa
es software libre si los usuarios tienen las cuatro libertades esenciales: libertad de ejecutar el
programa como se desea, con cualquier propósito; libertad de estudiar cómo funciona el
27
programa, y cambiarlo para que haga lo que usted quiera (el acceso al código fuente es una
condición necesaria para ello); libertad de redistribuir copias para ayudar a su prójimo y libertad
de distribuir copias de sus versiones modificadas a terceros.
3.2.8 Bases de Datos NoSQL
Las bases de datos NoSQL son sistemas de almacenamiento de información que no cumplen
con el esquema entidad-relación. Mientras que las tradicionales bases de datos relacionales basan
su funcionamiento en tablas, joins y transacciones. Las bases de datos NoSQL no imponen una
estructura de datos en forma de tablas y relaciones entre ellas sino que proveen un esquema
mucho más flexible.
Las bases NoSQL son adecuadas para una escalabilidad realmente enorme, y tienden a
utilizar modelos de consistencia relajados, no garantizando la consistencia de los datos, con el fin
de lograr una mayor performance y disponibilidad. A esto se agrega el inconveniente de que no
tienen un lenguaje de consulta declarativo, por lo que requiere de mayor programación para la
manipulación de los datos.
En general se pueden mencionar Sistemas NoSQL clasificados en cuatro categorías:
Framework Map-Reduce
Usado por aplicaciones que hacen procesamiento analítico online OLAP, por ejemplo
Hadoop.
Almacenamiento Clave-Valor.
Sistemas que tienden al procesamiento de transacciones online - OLTP, por ejemplo:
Google, BigTable, Amazon Dynamo, Cassandra, Voldemort, HBase.
Almacenamiento de Documentos
Por ejemplo: CouchDB, MongoDDB, SimpleDB
28
Sistemas de base de datos Gráficas
Por ejemplo: Neo4j, FlockDB, Pregel.
Con respecto al almacenamiento en columnas que en general son tratados como Sistemas
NoSQL, no son más que una forma de organización de un sistema de base de datos relacional. Sin
embargo por la alta performance para cierto tipo de aplicaciones son considerados como del tipo
almacenamiento Clave-Valor.
3.2.9 UML
“UML (Lenguaje Unificado de Modelado) permite a los creadores de sistemas generar
diseños que capturan sus ideas en una forma convencional y de fácil comprensión para
comunicarlas a otras personas”.
3.2.10 Arquitectura de Software
Según el estándar ISO 42010 la arquitectura de software es el proceso de concebir, definir,
expresar, documentar y certificar la implementación y mejora de un sistema a través de su ciclo
de vida. Adicionalmente según ese estándar los sistemas se representan a través de sus conceptos
fundamentales o propiedades en su ambiente representadas en sus elementos, relaciones, y los
principios de su diseño y evolución.
En los siguientes numerales se listan algunos conceptos básicos utilizados en el desarrollo
del proyecto.
3.2.10.1 Interesados
Un interesado o Stakeholder Persona, equipo, organización o sus clases, que tienen algún
interés en un sistema.
29
3.2.10.2 Preocupaciones
Una preocupación o Concern es un interés en un sistema relevante a uno o más interesados, a
continuación se listan ejemplos típicos de interesados y sus preocupaciones:
Gerencia de alto nivel: ¿Cómo podemos asegurar que nuestras políticas son seguidas
en el desarrollo y operación de los procesos y sistemas? ¿Cuál es el impacto de las
decisiones en las distintas áreas de la empresa (persona, finanzas, IT, etc.)?
Gerente operacional: Responsable de la explotación o el mantenimiento: Por
ejemplo, ¿De Cuales tecnologías nuevas se requiere preparación? ¿Hay alguna
necesidad de adaptar los procesos de mantenimiento? ¿Cuál es el impacto de los
cambios de las aplicaciones existentes? ¿Qué tan seguros son mis sistemas?
Gerente de proyecto: Responsable del desarrollo de nuevas aplicaciones: ¿Cuáles son
los dominios relevantes y sus relaciones? ¿Cuál es la dependencia de los procesos de
negocio de las aplicaciones a ser construidas? ¿Cuál es su desempeño esperado?
Desarrollador: ¿Cuáles son las modificaciones respecto de la situación actual que
necesitan ser realizadas?
3.2.10.3 Puntos de Vista
Cada interesado tiene unas preocupaciones que pueden ser exclusivos o comunes a otros
interesados, dichas preocupaciones se deben caracterizar desde distintas perspectivas o vistas de
arquitectura. El estándar de representación de dichas vistas se denomina un punto de vista.
Los puntos de vista se clasifican de acuerdo a su propósito en:
Diseño: Los puntos de vista de diseño dan soporte a los arquitectos y diseñadores en
el proceso de diseño, desde las plantillas iniciales hasta el diseño detallado.
30
Típicamente los tipos de puntos de vista de diseño consisten en diagramas, como
aquellos utilizados por ejemplo en UML.
Decisión: Los puntos de vista apoyan a los gerentes en el proceso de toma de
decisiones a través de la revisión de las relaciones transversales de arquitectura,
típicamente a través de proyecciones e intersecciones de los distintos modelos,
aunque también por medio de técnicas analíticas. Ejemplos típicos son las tablas de
referencia cruzadas, mapas de paisaje (Landscape), listas y reportes.
Informe: Los puntos de vista de informe ayudan a informar a cualquier interesado de
la arquitectura empresarial, con el objetivo de lograr un entendimiento, lograr
compromisos, y convencer a detractores. Ejemplos típicos son ilustraciones,
animaciones, caricaturas, etc.
3.2.11 Ingeniería de Tránsito
Uno de los problemas más graves que afronta la administración distrital es el de la
movilidad, basta con ver el comportamiento del flujo vehicular sobre cualquier vía arterial a
cualquier hora del día, o ver las constantes críticas realizadas por diferentes actores de nuestra
sociedad contra el mencionado problema.
El problema tiene como causa principal la inversa proporción entre oferta vial y la demanda
vehicular. La oferta vial se puede definir como la cantidad máxima de vehículos que pueden
desplazarse sobre la malla vial, y la demanda vehicular se define como la cantidad de vehículos
que requieren desplazarse sobre un determinado sistema vial u oferta vial (Cal y Mayor R,
Rafael; Cárdenas G, James, 2007) Siendo el déficit de vías la principal causa del problema de
movilidad, existen además otros hechos que acentúan el problema, y serán abordados durante la
ejecución de la presente investigación.
31
Según Cal y Mayor y Cárdenas (2007), las posibles soluciones al problema de la movilidad se
pueden agrupar en tres categorías:
La primera, es la solución Integral que consiste es construir sistemas viales modernos que
estén en capacidad de atender la demanda proyectada de crecimiento demográfico y del parque
automotor; un sistema de vías jerarquizadas y una amplia malla vial secundaria. Requiere además
la readecuación de las zonas residenciales, las de espacio público y las de estacionamiento. Esta
solución es imposible de implementar en Bogotá, debido a que la reestructuración demandaría
demoler múltiples elementos de la estructura urbana, adicionalmente estos procesos de
renovación requieren la inversión de grandes cantidades de dinero. Los casos de éxito conocidos
se han llevado a cabo con un alto porcentaje de inversión del sector privado (Sistema de
concesiones viales, Chile 1991).
La segunda, es la solución parcial de alto costo que implica la adecuación en las
intersecciones de las vías, el ensanchamiento de las mismas y la incorporación de sistemas
integrados de transporte multimodales; esta solución no se centra en aumentar la oferta vial, sino
en aumentar la fluidez de desplazamiento sobre la estructura actualmente disponible mediante la
reducción de intersecciones. Para el caso de Bogotá, los proyectos que se enmarcan en esta
categoría son: la ampliación de las redes de Transmilenio, construcción de puentes (vehiculares y
peatonales), glorietas y pasos a desnivel.
La tercera, es la solución parcial de bajo costo que consiste en maximizar el
aprovechamiento de la infraestructura disponible a través de: semaforización electrónica,
educación al conductor y al peatón a cerca del respeto de las normas de tránsito, aplicación del
reglamento de tránsito, organización del transporte público, desestimulo en el uso del vehículo
32
particular, reducción del parque automotor en horas pico, y la implementación de sistemas de
monitoreo y medición en pro de canalizar la inversión de los recursos.
3.2.12 Moovit (www.moovitapp.com/es/)
Es una aplicación gratuita de gestión de transporte público que se encuentra disponible en
más de 30 ciudades de diez países y cuenta con más de un millón de descargas en dispositivos
móviles. La aplicación permite a los viajeros compartir datos sobre el servicio de la red de
transporte o sobre la propia experiencia del viaje. A través de la aplicación se puede conocer la
información habitual sobre el sistema de transporte público que rige en cada ciudad.
Los usuarios pueden compartir diversos aspectos relacionados con el servicio, como por
ejemplo: accidentes, desvíos de rutas, retrasos o comodidad. En ese sentido es similar a Waze,
aunque sin lo intuitivo de la aplicación mencionada.
Al tener esa similitud con Waze, Moovit puede funcionar como una red social. La aplicación
permitirá crear valoraciones del servicio obteniendo información de los usuarios a través de
colaboración abierta. Esos datos se comparan con los servicios de información oficiales y el
resultado final determina la mejor ruta, según el tránsito en tiempo real y teniendo en cuenta las
diferentes opciones. Este cruce de datos, le dan más precisión a la aplicación para brindar un
mejor servicio en términos de tiempo de llegada, retraso o disturbios en la vía.
3.2.13 Waze (http://www.waze.com)
Fue lanzada en Octubre de 2.010 y se basa en una Red Social que a través de teléfonos
móviles dotados con antena GPS y acceso a Internet reporta en tiempo real la velocidad y
ubicación de cada usuario, estos datos recolectados en forma pasiva permiten a WAZE alimentar
un mapa de tránsito vehicular al cual adicionalmente se le pueden agregar comentarios y fotos de
33
eventos que afectan la movilidad, para que otros usuarios de la aplicación puedan elegir la ruta de
tránsito más adecuada.
3.2.14 Here (http://www.here.com)
Esta aplicación fue desarrollada por NOKIA para competir con Google en dispositivos
móviles con sistema operativo android, y en esencia, ofrece los mismos servicios, salvando las
marcadas diferencias que se derivan de los sistemas operativos sobre los cuales opera.
3.2.15 Bing Maps (http://www.bing.com/maps/)
Servicio de mapas para navegadores web, desarrollado por Microsoft bajo la expectativa de
consolidarse como el mayor rival de Google Maps en plataformas desktop, que al final, no logró
la acogida esperada por cada uno de los aspectos en que el servicio de mapas Google le superaba
con amplia ventaja, como la calidad y vigencia de las imágenes satelitales, la oferta de servicios
limitada a pocas ciudades del mundo y, una apariencia simple que fácilmente podía confundirse
con la de un sistema obsoleto.
3.2.16 TomTom (http://www.tomtom.com/livetraffic)
El servicio de mapas ofrecido por esta aplicación, está enfocado principalmente para ser
consumido a través de dispositivos de navegación, y a través de estos se puede conocer el estado
del tránsito en tiempo real y establecer rutas alternativas.
El auge de este tipo de aplicaciones se debe primordialmente a la facilidad de acceso a
dispositivos móviles tipo Smart y la confianza que genera la tecnología para solucionar
problemas específicos en las ciudades. Aunque son múltiples las aplicaciones disponibles para
apoyar los temas relacionados con movilidad y sitios de interés, en Bogotá son pocas las que
ofrecen servicios, y unido a esto, los servicios disponibles son deficientes porque se basan en el
34
concepto de redes sociales, donde el propósito tiene un enfoque hacia el lucro económico y bajo
beneficio social.
3.3 Marco Espacial
El diseño del estudio será llevado a cabo en la ciudad de Bogotá D.C.
3.4 Marco Temporal
El diseño de la solución propuesta en este documento comprenderá un periodo de ejecución
comprendido entre Enero y Junio de 2015.
35
CAPITULO 4
4.1 Tipo de Estudio
Esta investigación se centrará en el diseño de una herramienta informática, teniendo en
cuenta el funcionamiento de otras herramientas existentes para procesar eventos similares, donde
es fundamental el control de las variables relacionadas a concurrencia y congestión.
Lo anterior implica, que este estudio se enmarque en el holotipo de investigación proyectivo,
puesto que el resultado esperado es una propuesta de diseño.
La metodología de investigación para este proyecto será la siguiente:
1. Identificación y definición del problema.
2. Definición de variables.
3. Diseño de modelo de base de datos
4. Diseño del sistema
5. Elaboración y sustentación de resultados
4.2 Método de Investigación
La norma ISO/IEC/IEEE 42010 “Systems and software engineering — Architecture
description” es un estándar internacional para la descripción de sistemas de software, en la cual se
definen los requisitos que debe cumplir un diseño, por tanto, se empleará el modelo de vistas de
Kruchten (Modelo 4 + 1) para elaborar dicha representación arquitectural, ya que este modelo
adopta el estándar IEEE 1471 y en la ISO 42010 este modelo se referencia como guía.
36
4.3 Modelo de Vistas 4+12
La arquitectura del software se trata de abstracciones, de descomposición y composición, de
estilos y estética. También tiene relación con el diseño y la implementación de la estructura de
alto nivel del software.
Los diseñadores construyen la arquitectura usando varios elementos arquitectónicos elegidos
apropiadamente. Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad y
performance del sistema, así como también otros requisitos no funcionales tales como
confiabilidad, escalabilidad, portabilidad y disponibilidad del sistema.
Ilustración 1. Modelo de "4 + 1" vistas
4.3.1 La Arquitectura Lógica
La arquitectura lógica apoya principalmente los requisitos funcionales –lo que el sistema
debe brindar en términos de servicios a sus usuarios. El sistema se descompone en una serie de
abstracciones clave, tomadas principalmente del dominio del problema en la forma de objetos o
2 Artículo publicado en IEEE Software 12(6), Noviembre 1995, pp. 42-50. Traducido por María Cecilia
Bastarrica en Marzo 2006.
37
clases de objetos. Aquí se aplican los principios de abstracción, encapsulamiento y herencia. Esta
descomposición no solo se hace para potenciar el análisis funcional, sino también sirve para
identificar mecanismos y elementos de diseño comunes a diversas partes del sistema.
Usamos el enfoque de Booch/Rational para representar la arquitectura lógica, mediante
diagramas de clases y templates de clase3s. Un diagrama de clases muestra un conjunto de clases
y sus relaciones lógicas asociaciones, uso, composición, herencia y similares. Grupos de clases
relacionadas pueden agruparse en categorías de clases. Los templates de clases se centran en cada
clase individual; enfatizan las operaciones principales de la clase, e identifican las principales
características del objeto. Si es necesario definir el comportamiento interno de un objeto, esto se
realiza con un diagrama de transición de estados o diagrama de estados. Los mecanismos y
servicios comunes se definen como utilities de la clase.
4.3.1.1 Notación
La notación para la vista lógica se deriva de la notación de Booch. Esta se simplifica
considerablemente de tal modo de tener en cuenta solamente los ítems relevantes para la
arquitectura. En particular, los numerosos adornos disponibles son bastante inútiles a este nivel de
diseño. Existen diferentes herramientas para apoyar el diseño lógico de la arquitectura.
3 Grady Booch. Object-Oriented Analysis and Design with Applications. Benjamin-Cummings Pub. Co.,
Redwood City, California, 2nd edition, 1993.
38
Ilustración 2. Notación para la vista lógica
4.3.1.2 Estilo
El estilo usado para la vista lógica es el estilo de orientación a objetos. La principal guía para
el diseño de la vista lógica es el intentar mantener un modelo único y coherente de objetos a lo
largo de todo el sistema, para evitar la especialización prematura de las clases y mecanismos
particulares o de un procesador.
4.3.2 La Vista de Procesos
La arquitectura de procesos toma en cuenta algunos requisitos no funcionales tales como el
desempeño y la disponibilidad. Se enfoca en asuntos de concurrencia y distribución, integridad
del sistema, de tolerancia a fallas. La vista de procesos también específica en cuál hilo de control
se ejecuta efectivamente una operación de una clase identificada en la vista lógica.
La arquitectura de procesos se describe en varios niveles de abstracción, donde cada nivel se
refiere a distintos intereses. El nivel más alto la arquitectura de procesos puede verse como un
39
conjunto de redes lógicas de programas comunicantes (llamados “procesos”) ejecutándose en
forma independiente, y distribuidos a lo largo de un conjunto de recursos de hardware conectados
mediante un bus, una LAN o WAN. Múltiples redes lógicas pueden usarse para apoyar la
separación de la operación del sistema en línea del sistema fuera de línea, así como también para
apoyar la coexistencia de versiones de software de simulación o de prueba.
Un proceso es una agrupación de tareas que forman una unidad ejecutable. Los procesos
representan el nivel al que la arquitectura de procesos puede ser controlada tácticamente (i.e.,
comenzar, recuperar, reconfigurar, y detener). Además, los procesos pueden replicarse para
aumentar la distribución de la carga de procesamiento, o para mejorar la disponibilidad.
4.3.2.1 Partición
El software se particiona en un conjunto de tareas independientes: hilo de control separado que
puede planificarse para su ejecución independiente en un nodo de procesamiento.
Podemos entonces distinguir:
tareas mayores son elementos arquitectónicos que pueden ser manejados en forma
unívoca. Se comunican a través de un conjunto bien definido de mecanismos de
comunicación inter-tarea: servicios de comunicación sincrónicos y asincrónicos basados
en mensajes, llamados a procedimientos remotos, difusión de eventos, etc. Las tareas
mayores no debieran hacer suposiciones acerca de su localización con otras tareas dentro
de un mismo proceso o un mismo nodo de procesamiento.
tareas menores son tareas adicionales introducidas localmente por motivos de
implementación tales como actividades cíclicas, almacenamiento en un buffer, time-out,
40
etc.). Pueden implementarse en Ada por ejemplo, o como hilos de control liviano (hilos).
Pueden comunicarse mediante rendezvous o memoria compartida.
El flujo de mensajes y la carga de procesos pueden estimarse en base al diagrama de
procesos. También es posible implementar una vista de procesos “vacía”, con cargas dummy para
los procesos y medir entonces su performance en el sistema objetivo4.
4.3.2.2 Notación
La notación que usamos para la vista de procesos se expande de la notación originalmente
propuesta por Booch para las tareas de Ada y se centra solamente en los elementos
arquitectónicamente relevantes.
Ilustración 3. Notación para el diagrama de procesos
4 A. R. Filarey, W. E. Royce, R. Rao, P. Schmutz, and L. Doan-Minh. Software First: Applying Ada
Megaprogramming Technology to Target Platform Selection Trades. In TRI-Ada, pages 90–101, 1993.
41
Hemos usado el producto Universal Network Architecture Services (UNAS) de TRW para
diseñar e implementar un conjunto de procesos y tareas (con sus respectivas redundancias) como
redes de procesos. UNAS contiene una herramienta –el Software Architects Lifecycle
Environment (SALE) – el cual apoya dicha notación. SALE permite describir gráficamente la
arquitectura de procesos, incluyendo la especificación de las posibles rutas de comunicación
inter-tareas del cual se puede generar automáticamente el correspondiente código fuente Ada o
C++. La generación automática de código permite hacer cambios fácilmente a la vista de
procesos.
4.3.2.3 Estilo
Varios estilos podrían servir para la vista de procesos. Por ejemplo, tomando la taxonomía de
Garlan y Shaw5 tenemos: tubos y filtros, o cliente/servidor, con variantes de varios clientes y un
único servidor o múltiples clientes y múltiples servidores. Para sistemas más complejos, podemos
usar un estilo similar a la forma de agrupación de procesos del sistema ISIS descrito por Kenneth
Birman con otra notación y otras herramientas6.
4.3.3 Vista de Desarrollo
La vista de desarrollo se centra en la organización real de los módulos de software en el
ambiente de desarrollo del software. El software se empaqueta en partes pequeñas –bibliotecas de
programas o subsistemas– que pueden ser desarrollados por uno o un grupo pequeño de
5 David Garlan and Mary Shaw. An Introduction to Software Architecture. Advances in Software Engineering and Knowledge Engineering, 1, 1993. World Scientific Publishing Co. 6 Kenneth P. Birman and Robbert Van Renesse. Reliable Distributed Computing with the Isis Toolkit. Wiley-
IEEE Computer Society Press, April 1994.
42
desarrolladores. Los subsistemas se organizan en una jerarquía de capas, cada una de las cuales
brinda una interfaz estrecha y bien definida hacia las capas superiores.
Ilustración 4.Diagrama (parcial) de procesos para Télic PBX
La vista de desarrollo tiene en cuenta los requisitos internos relativos a la facilidad de
desarrollo, administración del software, reutilización y elementos comunes, y restricciones
impuestas por las herramientas o el lenguaje de programación que se use. La vista de desarrollo
apoya la asignación de requisitos y trabajo al equipo de desarrollo, y apoya la evaluación de
costos, la planificación, el monitoreo de progreso del proyecto, y también como base para
analizar reuso, portabilidad y seguridad. Es la base para establecer una línea de productos.
La vista de desarrollo de un sistema se representa en diagramas de módulos o subsistemas
que muestran las relaciones exporta e importa. La arquitectura de desarrollo completa solo puede
describirse completamente cuando todos los elementos del software han sido identificados. Sin
embargo, es posible listar las reglas que rigen la arquitectura de desarrollo – partición,
agrupamiento, visibilidad– antes de conocer todos los elementos.
43
4.3.3.1 Notación
Tal como se muestra en la ilustración 6, usamos una variante de la notación de Booch
limitándonos a aquellos ítems relevantes para la arquitectura.
Ilustración 5. Notación para el diagrama de desarrollo
El ambiente de desarrollo Apex de Rational apoya la definición e implementación de la
arquitectura de desarrollo, la estrategia de capas antes descrita, y el cumplimiento de las reglas de
diseño. Se puede dibujar la arquitectura de desarrollo en Rational Rose a nivel de módulos y
subsistemas, en ingeniería hacia adelante y reversa a partir de código fuente Ada y C++.
4.3.3.2 Estilo para la vista de desarrollo
Recomendamos adaptar el estilo de capas para la vista de desarrollo, definido en 4 a 6
niveles de subsistemas. Cada capa tiene una responsabilidad bien definida. La regla de diseño es
44
que un subsistema en una cierta capa solo puede depender de subsistemas que estén o bien en la
misma capa o en capas inferiores, de modo de minimizar el desarrollo de complejas redes de
dependencias entre módulos y permitir estrategias de desarrollo capa por capa.
4.3.4 Arquitectura Física
Mapeando el software al hardware
La arquitectura física toma en cuenta primeramente los requisitos no funcionales del sistema
tales como la disponibilidad, confiabilidad (tolerancia a fallas), performance (rendimiento), y
escalabilidad. El software se ejecuta sobre una red de computadores o nodos de procesamiento (o
tan solo nodos). Los variados elementos identificados –redes, procesos, tareas y objetos–
requieren ser mapeados sobre los variados nodos. Esperamos que diferentes configuraciones
puedan usarse: algunas para desarrollo y pruebas, otras para emplazar el sistema en varios sitios
para distintos usuarios. Por lo tanto, el mapeo del software en los nodos requiere ser altamente
flexible y tener un impacto mínimo sobre el código fuente en sí.
4.3.4.1 Notación para la arquitectura física
Los diagramas físicos pueden tornarse muy confusos en grandes sistemas, y por lo tanto
toman diversas formas, con o sin el mapeo de la vista de procesos.
45
Ilustración 6. Notación para el diagrama físico
UNAS de TRW nos brinda los medios de datos para mapear la arquitectura de procesos en la
arquitectura física permitiendo realizar una gran cantidad de clases de cambios en el mapeo sin
modificar el código fuente.
Ilustración 7. Diagrama físico de PABX
46
Ejemplo de diagrama físico. La ilustración 8 muestra una configuración de hardware posible
para un gran PABX, mientras que las Figuras 9 y 10 muestran el mapeo de la arquitectura de
procesos en dos arquitecturas físicas diferentes, que corresponden a un PABX pequeño y uno
grande, respectivamente. C, F y K son tres tipos de computadores de diferente capacidad que
soportan tres tipos diferentes de ejecutables.
4.3.5 Escenarios
Todas las partes juntas
Ilustración 8. Una pequeña arquitectura física de PABX con emplazamiento de procesos
47
Ilustración 9. Diagrama físico para un PABX más grande incluyendo emplazamiento de procesos
Los elementos de las cuatro vistas trabajan conjuntamente en forma natural mediante el uso
de un conjunto pequeño de escenarios relevantes –instancias de casos de uso más generales– para
los cuales describimos sus scripts correspondientes (secuencias de interacciones entre objetos y
entre procesos) tal como lo describen Rubin y Goldberg7. Los escenarios son de alguna manera
una abstracción de los requisitos más importantes. Su diseño se expresa mediante el uso de
diagramas de escenarios y diagramas de interacción de objetos.
Esta vista es redundante con las otras (y por lo tanto “+1”), pero sirve a dos propósitos
principales:
7 Kenneth S. Rubin and Adele Goldberg. Object behavior analysis. Communications of the ACM, 35(9):48–62,
1992.
48
• Como una guía para descubrir elementos arquitectónicos durante el diseño de arquitectura
tal como lo describiremos más adelante
• Como un rol de validación e ilustración después de completar el diseño de arquitectura, en
el papel y como punto de partido de las pruebas de un prototipo de la arquitectura.
4.3.5.1 Notación para escenarios
La notación es muy similar a la vista lógica para los componentes (ver ilustración 3), pero
usa los conectores de la vista de procesos para la interacción entre objetos (ver ilustración 4).
Nótese que las instancias de objetos se denotan con líneas solidas. Para el diagrama lógico,
capturamos y administramos los diagramas de escenarios de objetos usando Rational Rose.
4.3.6 Correspondencia entre las Vistas
Las distintas vistas no son completamente ortogonales o independientes. Los elementos de
una vista están conectados a los elementos de las otras vistas siguiendo ciertas reglas y heurísticas
de diseño.
4.3.6.1 De la vista lógica a la vista de procesos
Identificamos varias características importantes de las clases de la arquitectura lógica:
Autonomía: ¿Los objetos son activos, pasivos o protegidos?
– un objeto activo toma la iniciativa de invocar las operaciones de otros objetos o sus
propias operaciones, y tiene el control completo sobre la invocación de sus
operaciones por parte de otros objetos.
– un objeto pasivo nunca invoca espontáneamente ninguna operación y no tiene
ningún control sobre la invocación de sus operaciones por parte de otros objetos.
49
– un objeto protegido nunca invoca espontáneamente ninguna operación pero ejecuta
cierto arbitraje sobre la invocación de sus operaciones.
Persistencia: ¿Los objetos son permanentes o temporales? ¿Qué hacen ante la falla de
un proceso o un procesador?
Subordinación: ¿La existencia o persistencia de un objeto depende de otro objeto?
Distribución: ¿Están el estado y las operaciones de un objeto accesibles desde varios
nodos de la arquitectura física, y desde varios procesos de la arquitectura de
procesos?
En la vista lógica de la arquitectura consideramos que cada objeto es activo y potencialmente
“concurrente”, i.e. teniendo comportamiento en paralelo con otros objetos, y no prestamos más
atención al grado preciso de concurrencia que requerimos para alcanzar este efecto. Por lo tanto,
la arquitectura lógica tiene en cuenta solo el aspecto funcional de los requisitos.
Sin embargo, cuando definimos la arquitectura de procesos, implementar cada objeto con su
propio hilo de control (e.g., su propio proceso Unix o tarea Ada) no es muy práctico en el estado
actual de la tecnología debido al gran sobrecarga que esto impone. Más aún, si los objetos son
concurrentes, deberá haber alguna forma de arbitraje para invocar sus operaciones.
Por otra parte, ser requiere múltiples hilos de control por varias razones:
Para reaccionar rápidamente a ciertas clases de estímulos externos, incluyendo
eventos relativos al tiempo
Para sacar partido de las múltiples CPUs en un nodo, o los múltiples nodos en un
sistema operativo
50
Para aumentar la utilización de la CPU, asignando la CPU a otras actividades
mientras algún hilo de control está suspendido esperando que otra actividad finalice
(e.g., acceso a cierto dispositivo externo, o acceso a otro objeto activo)
para priorizar actividades (y potencialmente mejorar la respuesta)
para apoyar la escalabilidad del sistema (con procesos adicionales que compartan la
carga)
para separar intereses entre las diferentes áreas del software
para alcanzar una mayor disponibilidad del sistema (con procesos de backup)
Usamos dos estrategias concurrentemente para determinar la cantidad correcta de
concurrencia y definir el conjunto de procesos que se necesitan. Considerando el conjunto de
posibles arquitecturas físicas, podemos proceder o bien:
Inside-out Comenzando a partir de la arquitectura lógica: definir las tareas agentes que
multiplican un único hilo de control entre múltiples objetos activos de una clase; los objetos cuya
persistencia o vida está subordinada a un objeto activo también se ejecutan en ese mismo agente;
muchas clases que requieren ser ejecutadas con mutua exclusión, o que requieren solo un
pequeño procesamiento comparten el mismo agente. Este agrupamiento prosigue hasta que se
reducen los procesos hasta un número razonablemente pequeño que aún permite distribución y
uso de los recursos físicos.
Outside-in Comenzando con la arquitectura física: identificar los estímulos externos
(requerimientos) al sistema, definir los procesos cliente para manejar los estímulos y procesos
servidores que solo brindan servicios y que no los inician; usar la integridad de los datos y las
51
restricciones de serialización del problema para definir el conjunto correcto de servidores, y
asignar objetos a los agentes cliente y servidor; identificar cuáles objetos deben ser distribuidos.
El resultado es el mapeo de las clases (y sus objetos) en un conjunto de tareas y procesos de
la arquitectura de procesos. Típicamente existe una tarea agente para una clase activa con algunas
variaciones: varios agentes para una clase dada para aumentar el rendimiento, o varias clases
mapeadas en un mismo agente porque sus operaciones se no se invocan frecuentemente o para
garantizar su ejecución secuencial.
Nótese que esto no es un proceso lineal y determinístico que nos lleva a una arquitectura de
procesos optima; requiere una serie de iteraciones para lograr un compromiso aceptable. Hay
numerosas otras formas de hacerlo, tal como lo establecen por ejemplo Birman et al8, o Witt et
al9. El método preciso a usar en la construcción del mapeo está fuera del alcance de este artículo,
pero podemos ilustrarlo con un pequeño ejemplo.
La Figura 13 muestra cómo un pequeño conjunto de clases de un sistema de control de
tráfico aéreo hipotético puede mapearse en procesos.
8 Kenneth P. Birman and Robbert Van Renesse. Reliable Distributed Computing with the Isis Toolkit. Wiley-
IEEE Computer Society Press, April 1994. 9 Bernard I. Witt, Terry Baker, and Everett W. Merrit. Software Architecture and Design–Principles, Models,
and Methods. Van Nostrand Reinhold, New York, 1994.
52
Ilustración 10. Mapeo de la vista lógica a la vista de procesos
La clase vuelo se mapea a un conjunto de agentes de vuelo: existen muchos vuelos a
procesar, una alta tasa de estímulos externos, el tiempo de respuesta es crítico, la carga debe
distribuirse entre múltiples CPUs. Más aún, los aspectos de persistencia y distribución del
procesamiento aéreo se difieren a un servidor de vuelos, el cual está duplicado por motivos de
disponibilidad.
Un perfil de vuelo o una liquidación siempre están subordinadas a un vuelo, y a pesar que
son clases complejas, ellas comparten los mismos procesos que la clase vuelo. Los vuelos se
distribuyen en varios procesadores, de forma notable para el despliegue y las interfaces externas.
Una clase sectorización, que establece una partición del espacio aéreo para la asignación de
jurisdicción de controladores de vuelos, debido a sus restricciones de integridad puede ser
53
manejada solamente por un agente único, pero puede compartir el proceso servidor con el vuelo:
las modificaciones son infrecuentes.
Localización y espacio aéreo y otra información aeronáutica estática son objetos protegidos,
compartidos entre muchas otras clases, y raramente modificados; se mapean en su propio
servidor, y se distribuye a otros procesos.
4.3.6.2 De la lógica al desarrollo
Una clase se implementa generalmente como un módulo, por ejemplo un tipo de la parte
visible de un paquete Ada. Las clases grandes se descomponen en múltiples paquetes.
Colecciones de clases íntimamente relacionadas –categorías de clases– se agrupan en
subsistemas. Deben también considerarse otras restricciones para la definición de subsistemas
tales como la organización del equipo de desarrollo, el tamaño esperado del código (típicamente
5K a 20K SLOC por subsistema), grado de reuso esperado, principio de distribución en capas
(visibilidad), políticas de liberación, y administración de la configuración. Por lo tanto,
generalmente terminamos con una vista que no tiene necesariamente una relación uno a uno con
la vista lógica.
Las vistas lógica y de desarrollo son muy cercanas, aunque se refieren a distintos asuntos.
Hemos encontrado que cuanto mayor es el proyecto, mayor es también la distancia entre estas dos
vistas. Similarmente para las vistas de procesos y física: cuanto mayor el proyecto, mayor es la
distancia entre estas vistas.
54
4.3.6.3 De procesos a físico
Los procesos y grupos de procesos se mapean sobre el hardware físico disponible en varias
configuraciones para pruebas o distribución. Birman describe algunos esquemas elaborados para
realizar este mapeo dentro del proyecto Isis.
Los escenarios se relacionan esencialmente con la vista lógica, en términos de cuáles clases
se usan y con la vista de procesos cuando las interacciones entre objetos involucran más de un
hilo de control.
4.3.7 Confeccionando el Modelo
No toda arquitectura de software requiere las “4+1” vistas completas. Las vistas que no son
útiles pueden omitirse de la descripción de arquitectura, tales como la vista física si hay un único
procesador, y la vista de procesos si existe un solo proceso o programa. Para sistemas muy
pequeños, es posible que las vistas lógica y de desarrollo sean tan similares que no requieran
descripciones independientes. Los escenarios son útiles en todas las circunstancias.
4.3.7.1 Proceso Iterativo
Witt et al. Indican 4 fases para el diseño de arquitectura: bosquejo, organización,
especificación y optimización, subdivididos en 12 pasos10. Indican que puede ser necesario algún
tipo de backtrack. Creemos que este enfoque es muy “lineal” para proyectos ambiciosos y
novedosos. Al final de las cuatro fases se tiene muy poco conocimiento para validar la
arquitectura. Abogamos por un desarrollo más iterativo, donde la arquitectura se prototipa, se
10 Bernard I. Witt, Terry Baker, and Everett W. Merrit. Software Architecture and Design–Principles, Models,
and Methods. Van Nostrand Reinhold, New York, 1994.
55
prueba, se mide, se analiza y se refina en sucesivas iteraciones. Además de permitir mitigar los
riesgos asociados a la arquitectura, este desarrollo tiene otros beneficios asociados para el
proyecto: construcción en equipo, entrenamiento, familiarización con la arquitectura, adquisición
de herramientas, ejecución de procedimientos y herramientas, etc. (Hablamos de un prototipo
evolutivo, que crece lentamente hasta convertirse en el sistema, y no de un prototipo desechable,
exploratorio.) Este enfoque iterativo también permite refinar los requisitos, madurarlos y
comprenderlos más profundamente.
Un enfoque dirigido por escenarios La funcionalidad más crítica del sistema se captura en
forma de escenarios (o casos de uso). Críticos se refiere a: funciones que son las más importantes,
la razón de existir del sistema, o que tienen la mayor frecuencia de uso, o que presentan cierto
riesgo técnico que debe ser mitigado.
Comienzo:
Se elige un pequeño número de escenarios para cierta iteración basado en el riesgo y
la criticidad. Los escenarios pueden sintetizarse para abstraer una serie de requisitos
de usuario.
Se bosqueja una arquitectura. Los escenarios se describen para identificar las
abstracciones mayores (clases, mecanismos, procesos, subsistemas) como lo indican
Rubin y Goldberg –descomponiéndolos en secuencias de pares (objeto, operación).
Los elementos de la arquitectura descubiertos se ponen en las 4 vistas de
arquitectura: lógica, de procesos, de desarrollo y física.
Se implementa la arquitectura, se prueba, se mide, y se analiza para detectar errores
o potenciales mejoras.
Se recogen las lecciones aprendidas.
56
Loop:
La siguiente iteración puede entonces comenzar mediante:
Reestudiando los riesgos,
Extendiendo la paleta de escenarios a considerar,
Seleccionando una serie de escenarios que permitirán mitigar el riesgo o cubrir una
mayor parte de la arquitectura.
Entonces:
Intentar describir los escenarios de la arquitectura preliminar,
Descubrir elementos de arquitectura adicionales, o algunos cambios que es necesario
aplicar a la arquitectura para dar cabida a estos escenarios,
Actualizar las 4 vistas de arquitectura,
Revisar los escenarios existentes basándose en los cambios,
Actualizar la implementación (el prototipo de la arquitectura) para dar apoyo al
nuevo conjunto extendido de escenarios,
Probar y medir bajo sobrecarga en lo posible en el ambiente de ejecución objetivo,
las 5 vistas se revisan para detectar potenciales simplificaciones, reutilización,
Actualizar las guías de diseño y justificación del mismo,
Recoger las lecciones aprendidas.
End loop
El prototipo inicial de la arquitectura evoluciona hasta convertirse en el sistema real. Con
suerte, luego de 2 o 3 iteraciones, la arquitectura se vuelve estable: no se encuentran nuevas
abstracciones mayores, ni subsistemas, ni procesos, ni interfaces. El resto de la historia está
57
dentro de la tónica del diseño, donde de hecho, el desarrollo puede continuar usando métodos y
procesos muy similares.
La duración de estas iteraciones varía considerablemente: con el tamaño del proyecto, con el
número de personas involucradas y su familiaridad con el dominio y el método, y con el grado de
novedad del sistema con respecto a la organización de desarrollo. Por lo tanto la duración de una
iteración puede ser de 2 a 3 semanas para un pequeño proyecto (e.g. 10KSLOC), o entre 6 y 9
meses para un gran sistema de comando y control (e.g. 700KSLOC).
4.3.8 Documentación de la Arquitectura
La documentación producida durante el diseño de la arquitectura se captura en dos
documentos:
Un Documento de Arquitectura del Software, cuya organización sigue las “4+1”
vistas (ver la figura 14 por un punteo típico)
Un documento de Guías del Diseño del Software, que captura (entre otras cosas) las
decisiones de diseño más importantes que deben respetarse para mantener la
integridad de la arquitectura del sistema.
Ilustración 11. Punteo de un documento de Arquitectura de Software
58
4.4 Metodología eXtreme Programming(XP)
Para garantizar un buen diseño del sistema, basado en refinamiento, se empleará como
metodología de desarrollo el eXtreme Programming (XP), aprovechando el principio de
adaptabilidad y la orientación a procesos ágiles.
En la metodología XP, se habla de Iteraciones, de Historias y de Tareas, entendiéndose estas
primeras como fases, las segundas como requerimientos y las terceras como las actividades que
se deben realizar para cada requerimiento, en la ¡Error! No se encuentra el origen de la
referencia. se muestra el diagrama general de la estructura de desglose de trabajo del ciclo de un
proyecto típico manejado según XP.
4.4.1 Fases de gestión del proyecto
Ilustración 12. Esquema metodológico
PROYECTOS DE DESARROLLO DE SOFTWARE
59
4.4.1.1 Gestión del proyecto
En la fase inicial del proyecto se hace un acercamiento global del proyecto que se quiere
realizar, en este punto se presentan las necesidades y el nivel de importancia de cada una de las
actividades requeridas.
4.4.1.1.1 Planificación del Proyecto
En la planificación del proyecto se toman todas las necesidades obtenidas y se determinan
las diferentes iteraciones a desarrollar.
Planificación Inicial: Durante esta etapa, se recopilará, analizará y clasificará la
información asociada a la prestación del servicio de transporte masivo en Bogotá.
Iteraciones: En este documento de presentación se mostrará una descripción de las
historias llevadas a cabo en esta iteración, junto con sus pruebas funcionales, capturas
de pantalla y finalmente las incidencias que hubo en esta iteración.
Historia: En este nivel de la metodología se definirán las Historias ò requerimientos
pertenecientes a cada iteración o fase.
Tarea: Serán las diferentes actividades que se van a realizar para poder llevar a cabo
una historia.
4.4.1.2 Implementación
El proceso de implementación consiste en llevar a cabo cada uno de las fases planeadas
dentro de la gestión del proyecto, en estas se abordan los temas relacionados con la base de datos,
las interfaces, la modulación del sistema a desarrollar y los diferentes reportes que se requieran
para cumplir con lo establecido en la gestión.
60
Una vez finalizado el desarrollo de cada ítem de gestión propuesto se deben realizar pruebas
del desarrollo.
4.4.1.2.1 Bases de datos
La base de datos debe estar obligatoriamente incluida en la planificación de la gestión del
proyecto, ya que es indispensable contar con ésta para el desarrollo del sistema de información.
Planificación: Para el desarrollo de la base de datos en necesario conocer los
diferentes módulos que se requieren implementar en el sistema a desarrollar, para
esto en indispensable conocer los diferentes requerimientos del software, además es
indispensable definir en este punto el motor de bases de datos que se implementará
en el sistema.
Implementación: El proceso de implementación de la base de la base de datos consta
de la elaboración del modelo entidad relación, los script necesarios para la creación
real de la base de datos, cumpliendo con todas las características identificadas en el
MER propuesto, por último de la implementación surge el diccionario de datos del
sistema, que debe ser incluido en la documentación técnica del proyecto.
Pruebas: En las pruebas de bases de datos consiste en identificar que las entidades de
la base de datos creada cubren todas las necesidades de los diferentes requerimientos
indicados para el proyecto a desarrollar.
4.4.1.2.2 Elaboración de código fuente
Actividad en la cual se lleva a cabo la construcción de las funcionalidades de las cuales se
compone el sistema.
61
4.4.2 Desarrollo del proyecto
4.4.2.1 Gestión
En el transcurso de la gestión del proyecto se utiliza el formato del acta de avances mostrado
en la Tabla 1; tal formato sirve como herramienta para registrar las reuniones a realizar tanto
internas como externas, que se utilizan como guía para registrar el estado del proyecto y la
planeación hecha en cada reunión
Tabla 1. Acta de avances del proyecto. Acta de Avances de Desarrollo del Proyecto
Fecha: Hora Inicio: Hora Fin:
Participantes: Lista de participantes de la reunión.
Temas de Avance: ítems de temas a tratar en la reunión.
Compromisos: Nuevas actividades que surgen durante la reunión y se asigna a un responsable.
Conclusiones: Resultado al que se llega una vez revisados los ítems propuestos en los temas de avance.
4.4.2.2 Planificación del proyecto
Los siguientes son los diferentes formatos a través de los cuales se realizará la entrega formal
de la planificación del proyecto.
Tabla 2. Planificación de Iteraciones. Planificación de Iteraciones
62
Iteración:1
Usuario: Usuario(s) responsable(s) de esta fase o iteración
Nombre Iteración: Nombre de la iteración o fase.
Prioridad en negocio: (Alta/ Media / Baja)
Riesgo en desarrollo: (Alta/ Media / Baja)
Historias estimadas: #
Programadores responsables: Nombre de los programadores o personas responsables de las historias de esta fase.
Descripción: Descripción detallada de la iteración
Lista de Historias Estimadas: Todas las posibles historias que se estimen para esta iteración
Observaciones: Todas las observaciones que se tengan de iteración.
Tabla 3. Planificación de Historias. Planificación de historias [Usuario]
Número:1 Usuario: Usuario que interviene en la actividad Nombre historia: Nombre de la historia o requerimiento Prioridad en negocio: (Alta/ Media / Baja)
Riesgo en desarrollo: (Alta/ Media / Baja)
Tareas estimadas: #
Iteración asignada: #
Programador responsable: Nombre del programador o persona responsable de la actividad
Descripción: Descripción detallada de la Historia
Observaciones: Todas las observaciones que se tengan de la historia o requerimiento.
Tabla 4. Planificación de Tareas. Planificación de tareas
63
Número tarea: 2
Número historia: 1
Puntos estimados: 5
Nombre tarea: Nombre de la tarea a realizar
Fecha inicio: dd / mes / aaaa Fecha fin: dd / mes / aaaa
Programador responsable: Equipo o persona responsable
Descripción: Comprobación que la definición establecida para la base de datos admite los campos que se leen del fichero de entrada, realizando las oportunas modificaciones.
4.4.2.3 Implementación
Para el desarrollo del proyecto teniendo en cuenta la metodología planteada XP se dividirá la
etapa de implementación en: bases de datos, interfaces y pruebas. Cada una de estas etapas tiene
un ciclo interno de planeación, implementación y pruebas. De esta manera se asegura el
mantenimiento de un correcto ciclo de vida de acuerdo a los lineamientos planteados en la
planeación inicial.
4.4.2.3.1 Bases de datos
Planeación: En la planeación de la base de datos, se analizan las entidades necesarias
para cumplir con cada una de las iteraciones planeadas en el documento de gestión.
En la Tabla 5 se muestra la plantilla del formato a utilizar en la planeación.
Tabla 5. Planeación de Bases de Datos. Planeación de Bases de datos
Nombre del Módulo Entidades de BD Relacionadas
Observaciones
Ciudades
Departamentos Ciudades
La entidad ciudades incluye como llave foránea la llave primaria de la entidad departamentos.
64
Implementación: Para la implementación de la base de datos se definen los scripts de
las tablas identificadas en la planeación y su correspondiente MER Tales artefactos
se registran en un documento cuya plantilla se muestra en la Tabla 6.
Tabla 6. Implementación de recursos al sistema Bases de Datos. Implementación de recursos al sistema [Bases de Datos]
Nombre historia: Nombre de la historia o requerimiento
Iteración asignada: # Numero historia: # Tareas cumplidas con este agregado:
Programador responsable: Nombre del programador o persona responsable de la actividad
Descripción: Descripción detallada del módulo agregado
Respaldos: Scripts correspondientes a las entidades agregadas.
Imagen del modelo agregado al sistema:
• Pruebas: La pruebas de integridad de las bases de datos a diseñar e implementar se
registran en un documento cuya plantilla se muestra en la Tabla.
Tabla 7. Pruebas de base de datos
Pruebas de Bases de datos
Módulo Normalización
Adecuada Llaves primarias, Foráneas e índices
definidos
Diccionario de datos definido para la tabla
Observaciones
Si No Si No Si No
65
4.4.2.4 Pruebas
Muestra el entregable formal de la etapa en el cual se detallan: Número de tarea, historia e
interacción, encargado de la prueba, nombre de tarea, descripción, datos de entrada, resultado
esperado y evaluación de la prueba. Dichas pruebas se registran en un documento cuyo formato
se muestra en la ¡Error! No se encuentra el origen de la referencia..
Tabla 8. Planificación de Pruebas
Planificación de pruebas
Número tarea: 2 Número historia: 1 Iteración:1
Encargado de prueba: Equipo o persona responsable Nombre de tarea: Desarrollo / Corrección / Mejora / Verificación
Descripción: Descripción de las funcionalidades que presenta la tarea a testear.
Condiciones de ejecución: Condiciones iníciales para poder ejecutar correctamente la tarea.
Datos de entrada: Datos o parámetros de entrada para la el correcto funcionamiento de la tarea.
Resultado esperado: Resultado esperado después de realizar la prueba con las entradas establecidas.
Evaluación de la prueba: Evaluación del resultado obtenido en la prueba realizada.
4.5 Fuentes y Técnicas para Recolección de Información
Para la elaboración de la propuesta del sistema de información, se debe recolectar
información e investigar sobre el modo de operación de modelos utilizados para solucionar
problemas asociados a tránsito y transporte.
4.5.1 Fuentes Primarias
Secretaría Distrital de Movilidad (www.movilidadbogota.gov.co/)
66
Calle 13 No. 37 - 35
Transmilenio S.A. (www.transmilenio.gov.co/)
Av. Dorado No. 66-63
Ph.D Sandro Javier Bolaños Castro.
4.5.2 Fuentes Secundarias
- Archivo digital de noticias de los diarios de mayor circulación
- Cámara de comercio de Bogotá (http://www.ccb.org.co/Investigaciones-Bogota-y-
Region/Desarrollo-Urbano-y-Movilidad/Movilidad/Transporte-publico-y-privado)
(Universidad de los Andes. (https://sur.uniandes.edu.co/index.php/proyectos-
internos/45-pe-observatorio-movilidad)
SOMMERVILLE, Ian. Ingeniería del Software. Séptima Edición. Madrid: Pearson
Education S.A., 2005 ISBN: 84-7829074-5.
GRACIA, Joaquín. Patrones de diseño: Diseño de software orientado a objetos.
Zaragoza, 2003 [disponible en línea]
4.5.3 Recolección de la Información
La información para adelantar esta propuesta de grado se obtuvo mediante entrevista
presencial con los actores expertos en procesos relacionados con movilidad en Bogotá D.C., del
Observatorio de movilidad de la Universidad de los Andes, e información publicada en los
portales web de la Secretaría Distrital de Movilidad, la Cámara de Comercio de Bogotá,
Transmilenio S.A., Diarios El Tiempo, El espectador y La República.
67
4.5.4 Tratamiento de la Información
Como se explicó anteriormente se escogió el proceso XP como método de desarrollo para el
proyecto debido a que esta técnica se adapta a equipos de desarrollo de software pequeños,
orientados a la obtención de un producto con características de calidad, sin rigurosidad en la
documentación asociada al proceso de desarrollo más allá de la estrictamente requerida.
Todo proceso de desarrollo de software se puede dividir en cuatro grandes fases:
Especificación de requerimientos
Diseño y desarrollo
Pruebas
Despliegue y mantenimiento.
Estas fases generarán información relevante para realizar el análisis en cada etapa del
proyecto y a su vez servirá como entrada a la siguiente fase, según corresponda. Por este motivo
es necesaria la definición de un estándar en la administración de la información manejada en todo
el proceso de desarrollo del producto.
La información manejada en todo el proceso de desarrollo se divide en dos grandes
categorías:
Documentos de desarrollo: se deben elaborar actas de reunión, los requerimientos
estarán definidos en los formatos de iteraciones, historias y tareas, en adición, se
diligenciarán todos los formatos establecidos preliminarmente.
Código fuente: La codificación del diseño planteado en la plataforma de desarrollo
seleccionada.
68
CAPITULO 5
5.1 Diseño Arquitectural
5.1.1 Introducción
En el Distrito Capital, la prestación del servicio de transporte masivo se encuentra a cargo de
la empresa de transporte del tercer milenio, Transmilenio S.A. a la cual, adicionalmente se le
delegó la misión de prestar dicho servicio bajo estándares de calidad, eficiencia y sostenibilidad.
Las funciones que desempeña Transmilenio S.A. están enmarcadas en un perfil de
administración para la prestación del servicio, pues la operación es llevada a cabo a través de
operadores (empresas contratistas), los cuales son elegidos mediante procesos licitatorios. De esta
manera, el recurso humano de la empresa se encarga de gestionar los recursos recaudados,
planificar la prestación del servicio y realizar seguimiento y control al cumplimiento de la
programación por parte de los contratistas.
El dinero que se recauda en las ventanillas por concepto de venta de pasajes es reunido por
transportadoras de valores, para consignarse en las arcas de una fiducia responsable de distribuir
el dinero entre Transmilenio S.A., los operadores y las empresas encargadas del recaudo.
Este flujo no tiene incidencia directa sobre el control de la operación, pero es importante
reflejar, en primera instancia, la sostenibilidad económica del sistema, y posteriormente, que el
modo en que se realiza, genera congestión en las taquillas de las estaciones en horas pico.
Los molinetes para control de acceso, ubicados a las entradas de las estaciones, registran el
ingreso y salida de los usuarios al sistema. Este dato se registra para luego combinarse con el dato
69
de inicio-fin de viajes, y de esta manera se consolidan estadísticas que permiten dimensionar la
demanda que debe cubrirse para cada ruta en cada estación, a lo largo del día.
Con base en la estimación calculada, se realiza la asignación de buses y frecuencias por ruta,
proceso controlado a través del SAE, sistema de control de la operación de la organización.
En la siguiente ilustración se aprecia la alineación de los diferentes sistemas involucrados
para la prestación del servicio.
Ilustración 13. Punto de vista cooperación de Aplicación
Al estar limitados a la supervisión de la ejecución y resultados de la operación, los sistemas
con que cada contratista gestiona sus funciones se constituyen en herramientas que aportan
información consolidada a la aplicación principal de Transmilenio, lo cual impide a la empresa
conocer el estado y comportamiento de cada uno de los procesos en tiempo real.
70
Ilustración 14. Punto de Vista Comportamiento de Aplicación
Finalmente, los usuarios del sistema de transporte masivo reciben un servicio planificado
con la tendencia de uso de estos, lo cual permite evidenciar errores recurrentes de este modelo de
planificación:
Condiciones climáticas, ocasionan que se reduzca el uso del servicio durante el
evento, y al finalizar, la demanda se acumule.
Eventos públicos, aumentan de forma inesperada la demanda del servicio, los
cuales son atendidos solo cuando el servicio ya ha sido afectado.
Lo anterior refleja la necesidad de establecer mecanismos que permitan a la empresa
replantear la planificación de la operación, pero esto es posible conociendo la demanda del
servicio en tiempo real, y al mismo tiempo, informando el estado del servicio a los usuarios antes
del ingresar al sistema de transporte, permitiéndoles planificar su viaje dadas las condiciones.
71
5.1.2 Alcance
El sistema de información se diseñará, a partir de la localización capturada y reportada en
modo pasivo con el GPS de los dispositivos móviles permitirá consultar el nivel de congestión en
las estaciones, zonas de taquilla y vehículos del sistema a través de una salida cartográfica que se
actualizará a intervalos de tiempo cortos, dicha salida se consultará mediante dispositivos móviles
o equipos de escritorio.
El sistema no será una herramienta predictiva o similar, solo realizará algoritmos matemáticos
que conlleven a estadísticas con los cuales se asignará una simbología de colores a cada elemento
del sistema, de modo que visualmente sea fácil para el usuario identificar la estación y el
momento más adecuado para ingresar al sistema.
5.1.3 Delimitaciones
El sistema de información se limitará a las redes troncales del sistema Transmilenio, dadas
las condiciones preferenciales de carriles exclusivos de tránsito, las cuales simplifican el estudio
del problema, implicando que sistemas alimentadores, híbridos y del SITP serán excluidos.
El modo de captura pasivo implica que el usuario no interactúa con el sistema para calificar
o aportar valores, ya que estos pueden estar afectados por el estado de ánimo del usuario y
fácilmente distorsionarían la representación del nivel de congestión.
5.1.4 Lienzo de modelo de negocio
72
73
5.1.5 Requerimientos Funcionales
5.1.5.1 Nivel Sistema
5.1.5.1.1 Captura de posición de usuario dentro del sistema
Se requiere que el sistema capture en modo pasivo, la posición de un usuario dentro del
Sistema Transmilenio (ST), para lo cual deberá evitar reportar posiciones fuera de las
instalaciones del ST, evitando consumo innecesario del plan de datos.
5.1.5.1.2 Activación automática del GPS
Se requiere que la aplicación active automáticamente la localización a través de la antena
GPS, cuando esta se ejecute, controlando el hecho que algunos dispositivos no están equipados
con dicho sistema o en algunos casos los usuarios los configuran para evitar compartir ubicación.
5.1.5.1.3 Procesamiento de posiciones reportada en el ST
Se requiere que aplicar cálculos estadísticos que permitan transformar el número de
posiciones concurrentes en índices de ocupación, en función de variables como demanda usuarios
y hora del día.
5.1.5.1.4 Identificación de ruta asignada a buses del ST
Se requiere que el sistema posea la capacidad de identificar la ruta que cubre cada bus dentro
del ST, a partir de las paradas que realiza en los vagones de las estaciones, evitando participación
humana errada y garantizado la representación de congestión para cada bus.
5.1.5.1.5 Representación de Congestión
Se requiere que el sistema actualice el nivel de congestión para cada nodo del ST, en función
de la demanda y la hora, teniendo como en cuenta que hay estaciones de mayor demanda y que la
hora también determina el número de personas que se movilizan en el sistema.
74
5.1.5.2 Nivel Usuario
5.1.5.2.1 Consulta de nivel de Congestión
El sistema debe representar el nivel de congestión del nodo seleccionado por el usuario.
5.1.6 Requerimientos no Funcionales
5.1.6.1 Usabilidad
La aplicación debe ser de fácil uso para el usuario, de tal modo que no represente reto alguno
para su operación, puesto que la interfaz de aplicación estará en el dispositivo móvil orientada a
Usuarios sin ningún conocimiento avanzado.
La aplicación debe ofrecer un tiempo de respuesta inferior a 5 segundos. El dispositivo
móvil debe mostrar el estado de congestión, es decir, representar el nivel de congestión en
función de las variables del sistema.
5.1.6.2 Seguridad
El sistema debe garantizar que no a través de este, no se realicen accesos no deseados a los
dispositivos y que no se extraiga información adicional a la posición.
5.1.6.3 Mantenibilidad
Se debe estructurar el diseño con enfoque a módulos, para garantizar una fácil codificación y
mantenimiento.
5.1.6.4 Aplicación de estándares de diseño
El diseño del sistema deberá abordar estándares de diseño en materia de seguridad (ISO-
27000), arquitectura (ISO-42000) y para procesos del ciclo de vida (ISO 12207)
75
5.1.6.5 Comunicación
La comunicación entre el dispositivo smart y el sistema se realizará a través de un protocolo
de intercambio web.
5.1.7 Vista de Escenarios
Ilustración 15. Artefactos de la vista de escenarios
El sistema permitirá a usuarios de la aplicación, autenticarse previo registro, para acceder a
la información relacionada con el estado y nivel de congestión del sistema Transmilenio, la cual
es dimensionada a partir de las posiciones reportadas por otros usuarios en modo pasivo,
implicando que la disponibilidad de información dependa de la contribución de una red de
usuarios.
76
5.1.7.1 Diagrama de Casos de uso
Ilustración 16. Diagrama de casos de uso
5.1.8 Vista Lógica
Ilustración 17. Artefactos de la vista lógica
77
5.1.8.1 Diagrama de Clases
Ilustración 18. Diagrama de clases del servidor de aplicaciones
78
Ilustración 19. Diagrama de clases de la aplicación mobile
79
5.1.8.2 Diagramas de secuencias
Ilustración 20. Diagrama de secuencia "Registrar Usuario
Ilustración 21. Diagrama de secuencia "Autenticar Usuario"
80
Ilustración 22. Diagrama de secuencia "Consulta Congestión Sistema"
Ilustración 23. Diagrama de secuencia "Informar Anomalías"
5.1.9 Vista de Despliegue
81
Ilustración 24. Artefactos de la vista de despliegue
5.1.9.1 Diagrama de Componentes
Ilustración 25. Diagrama de componentes
82
5.1.10 Vista de Procesos
Ilustración 26. Artefactos de la vista de procesos
83
5.1.10.1 Diagrama de Actividades
Ilustración 27. Diagrama de actividades consulta de congestión estación
84
Ilustración 28.Diagrama de actividades consultar congestión y tiempo de llegada bus
85
5.1.11 Vista Física
Ilustración 29. Artefactos de la vista física
5.1.11.1 Diagrama de Despliegue
Ilustración 30. Diagrama de Despliegue
86
5.1.12 Mockup
Ilustración 31 Prototipo de aplicación.
87
5.2 Diseño de la Base de Datos
5.2.1 Variables
5.2.1.1 Hora
Variable aleatoria continua y no negativa, utilizada para registrar el momento en que un
evento ocurre. El dominio de la variable se encuentra definido por el horario de prestación del
servicio de transporte masivo.
5.2.1.2 Capacidad Bus
Variable cuantitativa y finita, utilizada para representar el nivel de ocupación de un bus del
servicio de transporte masivo Transmilenio. Su límite superior está definido por el tipo de bus.
5.2.1.3 Capacidad de Vagón
Variable cuantitativa y finita, utilizada para representar el nivel de ocupación de un vagón
del servicio de transporte masivo Transmilenio. Su límite superior está definido por el tipo de
estación.
5.2.1.4 Factor de expansión
Esta variable cuantifica el número de usuarios del sistema Transmilenio, que representan los
usuarios del sistema de información. Esta variable depende directamente de otras variables como
la hora y la estación.
5.2.1.5 Nivel de congestión
Es la variable que permite dimensionar la relación inversa entre la oferta del servicio del
mismo. Se considera que la congestión existe solo cuando la demanda es mayor o igual a la oferta
del servicio.
88
5.2.2 Modelo Entidad-Relación
Ilustración 32. Diagrama del modelo E-R
5.2.2.1 Usuario
Usuario del sistema, representado por esta entidad, y es el único que se relaciona en modo
dinámico con las demás entidades del modelo.
5.2.2.2 Bus
Entidad dinámica del sistema, que representa los vehículos en los cuales viajan los pasajeros
del ST. Dicha relación se materializa a través de los vagones basados en la entidad Ruta.
5.2.2.3 Estación
Entidad principal del modelo, por cuanto se articula (como nodo) con los demás entidades.
Representa las estaciones construidas en las troncales del ST.
89
5.2.2.4 Ruta
Representa el recorrido que realiza un bus sobre las redes del ST, tiene restricción de
operación por horario y su asignación a la entidad Bus tiene relación directa con los Vagones en
las estaciones.
5.2.2.5 Zona Abordaje
Comprende el espacio aledaño a los vagones donde se estacionan los buses para permitir el
acceso y descenso de usuarios.
5.2.2.6 Vagón
Entidad que representa una parte de la entidad Estación, físicamente es la sección donde se
abordan o descienden los pasajeros a los buses. Articula las entidades Bus, Pasajero y Ruta.
5.2.2.7 Ocupa Vagón
Entidad en la cual se registra la ubicación de un usuario dentro de un vagón.
5.2.2.8 Estadística Vagón
Entidad que contiene el factor de expansión para un vagón, referenciado a una ubicación y
hora.
5.2.2.9 Ocupa Bus
Entidad en la cual se registra la ubicación de un usuario dentro de un bus.
5.2.2.10 Estadística Bus
Entidad que contiene el factor de expansión para un bus, referenciado a una ruta y hora.
5.2.2.11 Registro Bus
Entidad en la que se registra la hora en la que una bus parte de una estación.
90
5.2.3 Sistema de Referencia
La infraestructura de datos espaciales del Distrito Capital (IDEC@) definió como sistema de
referencia para la interoperabilidad de información, el datum MAGNA-SIRGAS, configurando la
altura del plano de proyección en 2550 mts. MAGNA-SIRGAS, configurando la altura del plano
de proyección en 2550 mts., La proyección en la base de datos espaciales deberá ajustarse con
los siguientes parámetros:
Tabla 9. Parámetros de la proyección cartesiana, Ciudad Bogotá datum MAGNA-SIRGAS
Sistema de Coordenadas Geográficas Sistema de Coordenadas Proyectado
Nombre CGS_CartMAGBOG Nombre PCS_CartMAGBOG
Datum CGS_CartMAGBOG Proyección Transversa Mercator
Elipsoide GRS80 modificado Falso Norte 109 320,965
Semieje Mayor 6378137 + 2550 = 6380687 Falso Oeste 92 334,879
Semieje Menor 6359293,7644731188 Meridiano Central -74,146591667
Achatamiento (1/f) 298,257222101
Meridiano de Referencia Greenwich Latitud de referencia 4,680486111
Longitud 0º 0’ 0’’ Factor de Escala 1
Unidad Angular Degree Unidad lineal Metro
Radianes por unidad 0,017453292519943299 Metros por unidad 1
5.2.4 Sistema de Almacenamiento Geográfico
El formato de almacenamiento para la información geográfica definida en la base de datos
Oracle es ST_GEOMETRY. Este tipo de almacenamiento extiende las capacidades de la base de
datos proporcionando almacenamiento para elementos geográficos (puntos, líneas, y polígonos),
aprovechando con mayor eficiencia los recursos de la base de datos y la compatibilidad con
91
características como replicación y particionamiento, proporcionando mayor rapidez a la hora de
acceder a los datos.
92
5.3 Roadmap
5.3.1 Planificación de Actividades
Ilustración 33. Diagrama de planificación de actividades
5.3.2 Cuadro de Costos
Para el desarrollo del sistema de información, se propone el siguiente equipo de trabajo:
5.3.2.1 Director de proyecto
Magister en informática con énfasis en administración de proyectos, responsable de la
gestión y administración de recursos económicos.
93
5.3.2.2 Arquitecto de software
Magister en informática con énfasis en arquitectura de software, responsable de la validación
y seguimiento del diseño del sistema, es responsable además de la ejecución operativa del
proyecto.
5.3.2.3 Desarrollador senior
Especialista en geomática con énfasis en ingeniería de software, responsable de liderar y
apoyar el proceso de codificación del sistema de información.
5.3.2.4 Desarrollador junior
Profesional en informática responsable de la codificación del sistema de información.
Ilustración 34. Costos recurso humano
94
CONCLUSIONES
Involucrar al ciudadano en el diseño de estrategias de planificación de procesos,
garantiza el cubrimiento de detalles de importancia para el usuario que pueden ser
irrelevantes para la empresa.
Brindar información del estado del STPT puede mejorar el modo en que los pasajeros
utilizan el sistema.
Es fundamental poner al servicio del usuario, la tecnología instalada en el sistema y
modernizar el canal de presentación de información
95
PROSPECTIVA
El sistema está diseñado para brindar información básica a los usuarios del sistema de
transporte masivo Transmilenio, permitiéndoles conocer el estado de congestión y operatividad
del mismo. Dicha estructura puede ser aprovechada por la gerencia de operación de Transmilenio
para contar con una nueva herramienta de referencia en cuanto a la congestión de las estaciones y
buses se refiere y de esta manera mejorar las decisiones en su logística de despacho de rutas del
servicio.
La calidad de la información suministrada y por ende la calidad del servicio ofrecido por la
herramienta, puede maximizarse si la información base se complementa con los datos reales de la
operación y con las series históricas del servicio, lo cual solo es posible, a través del
establecimiento de acuerdos con la administración de la secretaria de movilidad y la empresa
Transmilenio S.A.
96
BIBLIOGRAFÍA
CAL Y MAYOR R, Rafael; CÁRDENAS G, James. Ingeniería de Tránsito. 8ª Edición, AlfaOmega grupo editor S.A., México, 2004.
GARBER, Nicholas J. Ingeniería de tránsito y carreteras. Editorial Thomson, México, 2005 CARDOSO, Jorge. Semantic web services: theory, tools, and applications, IGI Global, Estados
Unidos, 2007. TABOR, Robert. Servicios Web XML de microsoft.NET, Prentice Hall, Madrid, 2002. TOMLINSON, Roger. Pensando en SIG, Planificación del Sistema de Información Geográfica
Dirigida a Gerentes, 3ª Edición. ESRI Press, Estados Unidos, 2007. RUMBAUGH, James; JACOBSON, Ivar; BOOCH, Grady. El lenguaje unificado de modelado.
2ª Edición, Pearson Educación, Estados Unidos, 2004. ESRI Press. Dictionary of GIS. Terminology, ESRI Press, Estados Unidos, 2000. SOMMERVILLE, Ian. Ingeniería del Software. Séptima Edición. Madrid: Pearson Education
S.A., 2005 ISBN: 84-7829074-5. GRACIA, Joaquin. Patrones de diseño: Diseño de software orientado a objetos. Zaragoza, 2003
[disponible en linea] http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php.
ROJAS, Miguel David. Administración para Ingenieros. Cuarta Edición. Bogotá: Ecoe Ediciones,
2008 ISBN 978-958-648-554-8. GRANOLLERS, Toni. LORÉS, Jose. Diseño de sistemas interactivos centrados en el usuario.
Primera Edición. Barcelona: Editorial OUC, 2005 ISBN: 84-9788-320-9. CALERO, Coral. MORAGA, Mª Ángeles. PIATTINI, Mario. Calidad del producto y proceso
software. Primera Edición. Madrid: RA-MA Editorial., 2010 ISBN: 978-84-7897-961-5. KIMMEL, Paul, Manual de UML, Guía de Aprendizaje, México: MC Graw Hill Interamericana
Editores, 2006 ISBN: 970-10-5899-2 CANO, Fernández Lago, Gestión de Proyectos con TIC´s, Bogotá: Ediciones de la U, 2010,
ISBN: 978-958-994-908-5 CAMPO, Arranz Raquel, Gestión de Proyectos, Bogotá: Ediciones de la U, 2013,
97
ISBN: 978-958-762-165-5 PEÑA, Valenzuela Daniel, Aspectos Legales de Internet y del Comercio Electrónico, 2001,
Bogotá: Dupre Editores Ltda, ISBN: 958332066-8
