Logo Studenta

APLICACIAÔÇN-MAÔÇVIL-PARA-REPORTE-Y-SEGUIMIENTO-DE-BACHES-Y-COLADERAS-EN-LA-CIUDAD-DE-MAÔÇXICO

Vista previa del material en texto

INSTITUTO POLITÉCNICO NACIONAL 
 
 
 
 UNIDAD PROFESIONAL INTERDISCIPLINARIA 
 DE INGENIERÍA Y CIENCIAS SOCIALES 
 Y ADMINISTRATIVAS 
 
 
 
DESARROLLO DE APLICACIONES WEB Y MÓVILES CON 
 JAVA 
 
 
 
APLICACIÓN MÓVIL PARA REPORTE Y SEGUIMIENTO 
DE BACHES Y COLADERAS EN LA CIUDAD DE MÉXICO 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 CIUDAD DE MÉXICO 2018 
 No DE REGISTRO N7.308 
 
 
 
T E S I N A 
 
 
 
 
QUE PARA OBTENER EL TÍTULO DE 
I N G E N I E R O E N I N F O R M Á T I C A 
 
P R E S E N T A N 
LUIS ALBERTO FRAGOSO MARTÍNEZ 
JOSÉ ALBERTO GALÁN OSORIO 
BENJAMÍN ALEJANDRO GARCÍA ROMO 
JULIO SEGUNDO HERNÁNDEZ 
 
 
 
 
EXPOSITORES 
LIC. RICARDO ARMANDO MACHORRO REYES 
LIC. CARLOS OLICÓN NAVA 
LIC. ROCIO BUSTAMANTE TRANQUILINO 
ÍNDICE 
Resumen.................................................................................................................................i 
Introducción.............................................................................................................................ii 
Capítulo I Marco Metodológico.........................................................................................................1 
1.1 Planteamiento del problema .........................................................................................................1 
1.2 Objetivo General ...........................................................................................................................1 
1.3 Objetivos Específicos ....................................................................................................................1 
1.4 Técnicas e instrumentos de medición ...........................................................................................2 
1.5 Justificación ..................................................................................................................................3 
Capítulo II Marco Referencial............................................................................................................5 
2.1 Antecedentes……………...............................................................................................................5 
Capítulo III Marco Teórico ………………………………………………………...……………………….8 
3.1 Descripción del proyecto ...............................................................................................................8 
3.2 Arquitectura...……………………....................................................................................................8 
3.3 Software y tecnologías empleadas..............................................................................................11 
Capítulo IV Resultados y análisis de la información de campo.……………………………………49 
4.1 Resultado ....................................................................................................................................49 
4.2 Análisis...…………………….........................................................................................................51 
Capítulo V Propuesta de solución y resultados...........................................................................53 
5.1 Planeacion…………….................................................................................................................53 
5.2 Propuesta de Solución................................................................................................................55 
5.2.1 Diagrama de caso de uso general………………………………………………………...55 
5.2.2 Diagrama caso de uso login………………………………………………….…………….55 
5.2.3 Diagrama caso de uso recuperar password.……………………………….…………….58 
5.2.4 Diagrama caso de uso registro.…………………………………………………….…..….60 
5.2.5 Diagrama caso de uso activar cuenta…………....……………………………………….62 
5.2.6 Diagrama caso de uso reportar……………...…………………………………………….64 
5.2.7 Diagrama caso de uso consultar reportes.……………………………………………….66 
5.3 Solución Técnica………………..…………………………………………………………..……….….68 
5.4 Componentes..............................................................................................................................68 
5.5 Programación..............................................................................................................................68 
5.6 Pruebas…………………………………………………………………………………….………….....70 
5.7 Diagrama entidad relación …….…………………………………………………………….…………71 
5.8 Diagrama de clases…………………………………………………………………….……………….73 
5.9 Diagrama de despliegue……………………………………………………………………….……….74 
5.10 Manual de Operación………...……………………………………………………………….……….75 
Conclusiones...................................................................................................................................83 
Bibliografía.......................................................................................................................................84 
Anexos………...…………………………….……………………………………….………………...……87 
 
 
 
 
 
 
 
 
 
 
 
 
 
i 
 
Resumen 
 
La Ciudad de México está compuesta por 100 millones de metros cuadrados de concreto asfáltico, 
20 millones corresponden a vialidades primarias que deben ser atendidas por el Gobierno Capitalino 
y 80 millones por las delegaciones, en estas vialidades existen aproximadamente un promedio de 
90 mil baches de los cuales únicamente se tiene el reporte del 50% de ellos por lo cual los 
automovilistas se ven afectados diariamente con estos problemas en las vías públicas. 
 
Se realizó una aplicación móvil la cual está basada en la tecnología de Android y Java y conexión 
con bases de datos SQL. El proyecto está enfocado para que sea utilizado por cualquier usuario que 
desee reportar un bache o coladera que encuentre en su tránsito por las avenidas principales de la 
Ciudad de México esto para tener un mejor control de la información del tiempo promedio de la 
respuesta de las autoridades para resolver los incidentes reportados y tener una estadística de las 
incidencias con las que se deben lidiar diariamente. 
 
 
 
 
 
 
 
 
 
 
 
 
 
ii 
 
Introducción 
 
Hoy en día las opciones para reportar desperfectos en las vialidades no son del todo funcionales 
para la población de la ciudad de México. Centrándonos únicamente en la aplicación Bache24, esta 
no permite realizar reportes en vías secundarias, ni generar reportes sobre coladeras, baches 
provocados por fugas de agua (ya que estos reportes pertenecen al Sistema de Aguas de la Ciudad 
de México) y tampoco nos permite tener un control del tiempo de respuesta para fallas reportadas, 
es una aplicación muy básica para las necesidades de la población. 
 
Lo que se pretende con la aplicación que será desarrollada por nosotros es tener un mejor manejo 
y control de la información en tiempo real y fácil de comprender por los usuarios que la utilicen y así 
puedan estar informados sobre la situación de los desperfectos en las vialidades. 
 
Con base en los fundamentos y conocimientos adquiridos, esta se desarrollará en JAVA versión 1.7 
con framework Spring. Tendrá una arquitectura multicanal ya que, aunque en esta fase nos 
centraremos en la plataforma móvil se plantea desarrollar una arquitectura basada en servicios REST 
que permita la evolución del sistema hacia los diversos canales que se deseen. 
 
El sistema constará de dos componentes principales: la capa Front, donde se centrará el desarrollo 
para el dispositivo móvil y la parte Back, que será un servidor que oferte un conjuntode APIs REST. 
Para la comunicación entre estos 2 componentes, se utilizará el patrón MVC. 
 
 
 
 
 
 
 
 
iii 
 
En el capítulo uno se habla de la problemática y los puntos específicos que se tiene con respecto a 
los baches existentes en la ciudad de México y como son abordados por nuestra parte por medio de 
la aplicación que se desarrolló. 
 
En este capítulo se ven los antecedentes, lo datos relevantes en la actualidad y las estadísticas con 
respecto a esta problemática, se toma como punto de partida esta información y se crea una 
aplicación que es específica en los puntos vulnerables que se obtienen. 
 
 El capítulo tres se abordan temas técnicos y específicos de las herramientas y lenguajes de 
programación que se utilizan para el desarrollo y la funcionalidad de la aplicación. Se habla acerca 
también de las tecnologías empleadas para el desarrollo del sistema y finalmente ventajas y 
desventajas con todos los conceptos definidos. 
 
En el capítulo cuatro se muestran y analizan las cifras obtenidas sobre el proceso y la soluciones a 
los desperfectos reportados en la CDMX y la percepción de los ciudadanos sobre el proceso de 
reporte y la atención de los mismos. 
 
El capítulo cinco se trata del proceso de diagramación y definición de requerimiento, tablas y 
procesos en el que están basados los flujos de la aplicación desarrollada, como también los tiempos 
y las pruebas que se realizan. 
 
 
 
 
 
 
 
 
1 
 
Capítulo I Marco Metodológico 
 
En este capítulo abordamos la importancia de llevar un control de los baches y coladeras en la 
Ciudad de México haciendo una delimitación, como también los puntos específicos y como son 
solucionados con esta aplicación y el objetivo general al que se llega. 
 
1.1 Planteamiento del problema 
 
Actualmente no se tiene una manera óptima para realizar el seguimiento de un reporte de 
desperfecto en las vialidades de la CDMX. Aunque actualmente se puede reportar un desperfecto 
mediante la App Bache24, se tienen muchos impedimentos para que el usuario realice el seguimiento 
de su reporte hasta la atención del mismo. Aquí es donde surge la necesidad de desarrollar una 
aplicación móvil capaz de realizar reportes y seguimientos no sólo de baches sino también de 
coladeras abiertas que afectan a las vías de circulación de la CDMX. Estos reportes se almacenarán 
en una base de datos donde se permitirá llevar la puntuación sobre el mismo folio cada que una 
persona realice un reporte de un desperfecto que ya existe, con el fin de poder realizar estadísticas 
sobre las fallas más reportadas en el día o conocer desde cuando esta reportada por primera vez 
una falla y que seguimiento han dado para solucionarlo, igualmente nos permitirá tener un control 
del tiempo de respuesta sobre los reportes generados. 
 
1.2 Objetivo General 
 
Analizar, diseñar e implementar una aplicación móvil para sistemas Android, que permita a las 
personas que transiten por las vialidades de la ciudad de México reportar la ubicación de 
desperfectos viales tales como baches y/o coladeras abiertas. Esta aplicación además permitirá la 
puntuación de reportes ya existentes sobre dichas afectaciones, esto con la finalidad de ofrecer 
reportes de criticidad. 
 
1.3 Objetivos específicos 
 
 Almacenar y mostrar información sobre de defectos viales dados de alta. 
 Información en tiempo real de estadísticas de reportes realizados. 
 Seguimiento del detalle de lo que pasa con el bache/coladera reportado. 
 Obtener información crítica con respecto a las estadísticas de zonas más afectadas. 
2 
 
1.4 Técnicas e instrumentos de medición 
 
El proyecto estará enfocado en un estudio descriptivo, en él se plantearán el control, las 
estadísticas y contabilizaciones de desperfectos que se tienen en la Ciudad de México cuando se 
transita por las vialidades primarias. Todo esto tomando como apoyo la información de los 
incidentes reportados por los usuarios para generar estadísticas diarias, mensuales y una jerarquía 
de los baches/coladeras más puntuadas en el sistema, poder consultar de igual forma en qué lugar 
se tiene el mayor índice de reportes de desperfecto, cuánto tiempo dedica el gobierno en ser 
atendido un reporte de bache/coladera o si el desperfecto aun no es atendido, indicar cuánto 
tiempo lleva reportado. Con esto se agiliza el flujo de la información y que los usuarios estén al 
tanto de lo sucedido. 
 
Se va a realizar un diseño de investigación que implica observar y describir el comportamiento de 
una o más variables del objeto a estudiar sin influir de ninguna manera sobre ellas. El objetivo de 
investigación serán los ciudadanos de la Ciudad de México quienes son los que están implicados 
directamente en la aplicación a desarrollar. 
 
Lo que se va a analizar es lo siguiente. Véase figura 1.1: 
1. Puntuación de reporte de baches y coladeras. 
2. Control de los baches y coladeras reportados. 
3. Control de tiempo de repuesta de reparación. 
4. Control de estatus del reporte. 
5. Estadísticas de zonas más reportadas. 
 
3 
 
 
 
Figura 1.1 Proceso de Modulación de Aplicación 
Fuente: Elaboración Propia 
 
1.5 Justificación 
 
En datos revelados por dos encuestas de percepción ciudadana de calidad de vida aplicada en la 
Ciudad de México en 2013 y 2014 se destaca, entre otros, la insatisfacción ciudadana en temas 
urbanos relacionados con el espacio público (disponibilidad y condiciones), las vialidades (estado, 
infraestructura y eficiencia), al igual que, con el desempeño por parte de las autoridades del gobierno 
de la ciudad ante estos temas-problema. 
 
Específicamente en el tema de pavimentación se halla que, en 2013, el 35% de los ciudadanos 
respondió que la pavimentación de las calles empeoró mucho/algo y en 2014 este porcentaje pasó 
a 40.3%. En 2013, el 68% de los encuestados respondió estar nada/poco satisfecho con el estado 
de las calles y el 57% se expresó como nada/poco satisfecho con la eficiencia de las vialidades. 
Porcentajes que se incrementaron en 2014 a 73% y 62% respectivamente. Por otra parte, en 2013 
4 
 
el 76% de los encuestados consideraron que el gobierno del Distrito Federal hacía poco/nada para 
resolver los problemas mencionados, siendo similares estas respuestas en 2014, con un 80%. En 
general, se calificó la calidad de vida en 2014 con 3.79 sobre 5, un tanto más baja que en 2013, 
cuando fue de 3.85 sobre 5. 
 
Derivado de las cifras proporcionadas con anterioridad, se plantea el desarrollo de una aplicación 
móvil para sistema Android que permita reportar y dar seguimiento a los baches y/o coladeras 
abiertas en las vías de circulación vehicular de la CDMX. 
 
Con esta aplicación se ayudará a la CDMX a ser más eficientes al momento de realizar el alta de 
reporte por algún desperfecto vial y su seguimiento, además de ayudar a generar estadísticas del 
volumen ciudadano que reporta el mismo desperfecto y el tiempo de atención de los mismos. 
 
Al desarrollar una aplicación en JAVA, podemos ofrecer una alternativa atractiva para la CDMX y la 
ciudadanía, debido a su bajo costo y muy alta eficiencia en la solución a los desperfectos en las 
vialidades que se les presentan, ya que muchos ciudadanos actualmente al desconocer los 
beneficios que este tipo de aplicaciones les pueden brindar, prefieren continuar realizando los 
reportes que en su momento no son atendidos. 
 
 
 
 
 
 
 
 
 
 
 
 
5 
 
Capítulo II Marco Referencial 
 
Este capítulo hace referencia de la visión que se tiene del universo de datos obtenidos y estadísticas 
hasta el día de hoy, para tomar como punto de partida esta información y crear una aplicación que 
sea específica en los puntos vulnerables que se tienen. 
 
2.1 Antecedentes 
 
La Secretaría de Obras y Servicios (SOBSE) del Distrito Federal y cada una de las 16 delegaciones 
son las autoridades de gobierno encargadasdel mantenimiento de vialidades y bacheo de la ciudad, 
estando repartida su responsabilidad de acuerdo a la escala/importancia de la vialidad. A la SOBSE 
le corresponde el mantenimiento de las vialidades primarias, mientras que a los gobiernos 
delegacionales les compete el mantenimiento de las vialidades secundarias, calles locales, puentes 
peatonales y reductores de velocidad. En este sentido, su acción es necesaria y complementaria 
para contar con calles y vialidades óptimas para el uso, tránsito peatonal y vehicular. 
 
A pesar que estas instancias de gobierno cuentan con la asignación anual de recurso presupuestal 
para obtener la provisión de material de trabajo (mezclas asfálticas) y emprender acciones al 
respecto, el estado de deterioro y la presencia de baches que ostentan las calles de la ciudad, hace 
cuestionar la existencia de dichos rubros o de autoridades responsables de los servicios urbanos, 
como también de alguna autoridad de control o esquema de contraloría ciudadana que vigile la 
gestión pública. 
 
No obstante, esta percepción, existen tanto las autoridades como los recursos. En lo relacionado con 
estos últimos, se encuentra que ninguna de las delegaciones invierte más del tres por ciento de su 
presupuesto total de egresos anual para la adquisición de “mezcla asfáltica templada”, material de 
uso obligatorio para obra pública, ni para los rubros de “mantenimiento, conservación y rehabilitación 
en vialidades secundarias”, según su actual Programa Operativo Anual (POA) 2015. Esto parece ser 
insuficiente, al implicar existencia de vialidades sin atender y sin mejoras por un semestre o más. 
 
Asimismo, se hallan notables diferencias en los requerimientos de material por parte de las 
delegaciones. Por ejemplo, Iztacalco para este 2015 no solicitó material a pesar de contar con una 
trama completamente urbanizada, mientras que Álvaro Obregón, Gustavo Madero, Magdalena 
Contreras, Tláhuac, Tlalpan, Xochimilco y Milpa Alta, con extensiones importantes de suelo de 
conservación, han realizado pedidos considerables en los últimos tres años. De igual modo, estos 
6 
 
pedidos no son estables o regulares. Se conoce que de 2012 a 2014 el promedio de material pedido 
por las delegaciones fue de 175,643.44 toneladas (t), cantidad que prácticamente se duplica para 
este 2015 según el pedido inicial de asfalto, que es de 322,148 t. Siendo, el 39% de mezclas 
asfálticas requerido por la delegación Iztapalapa (126,100 t), seguido por las delegaciones Coyoacán 
con 18% (58,410 t) y Gustavo Madero con 10% (32,460 t). Véase figura 2.1. 
 
Figura 2.1. Requerimiento de mezclas asfálticas por delegación 2012-2014 
(Toneladas) 
Fuente: Planta de Asfalto oficio, 2014. 
 
Por otra parte, la SOBSE desde el 1 noviembre de 2014 inició el Programa Especial de Bacheo con 
tecnología de alta presión en vialidades primarias y secundarias de la ciudad, con un presupuesto 
de 100 millones de pesos sin aportes de las delegaciones beneficiadas. La meta planteada, tapar 92 
mil baches (250 en vialidades primarias y 585 en vialidades secundarias) en 60 días. Si bien en 
algunas vialidades ya se evidencian las acciones, en muchas otras todavía no hay resultados. De 
hecho, el porcentaje de avance actual registrado por la SOBSE es de 47%. 
 
Actualmente para poder reportar estas fallas se pueden realizar los siguientes procedimientos: 
 Llamar al 072: Con esta opción podremos levantar un reporte vía telefónica al cual le 
asignaran un número de folio y recibirás un correo electrónico con los datos del reporte. Se 
necesita proporcionar el nombre y la dirección de quien reporta, así como la localización del 
desperfecto. En caso de ser una vía secundaria se pasa a la Delegación correspondiente. 
 Centros de Servicios y Atención Ciudadana: Con esta opción es necesario acudir a las 
oficinas para realizar el reporte en los horarios establecidos (9:00 a 14:00 hrs.) y de igual 
7 
 
manera proporcionar nombre, dirección, teléfono y correo electrónico de quien acude a 
reportar, así como la localización del desperfecto. 
 Bache24: Esta es una aplicación desarrollada por el Gobierno de la Ciudad de México para 
levantar reportes únicamente de baches y solo funciona en vías primarias. Es necesario 
registrarse en la aplicación para poder realizar un reporte o dar seguimiento a los reportes 
vigentes. Algunas veces se llega a bloquear a los usuarios por realizar reportes que no son 
baches. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
8 
 
Capítulo III Marco teórico 
 
Este capítulo trata los aspectos conceptuales de manejo de servicios web, java, dominio de 
informática, UML entre otros, se describen las diferentes modelos de servicio, por último, se 
presentan las tecnologías empleadas para el desarrollo del sistema y finalmente ventajas y las 
desventajas con todos los conceptos definidos. 
 
3.1 Descripción del Proyecto 
 
El proyecto está destinado a la ciudadanía con acceso a dispositivos móviles y que tengan necesidad 
de reportar un desperfecto vial en la CDMX. Mediante el uso de esta aplicación se busca optimizar 
el proceso de reporte de desperfectos viales, ofreciendo una interfaz amigable e intuitiva para el 
usuario mediante el uso de la tecnología JAVA y de manera adicional proporcionar estadísticas útiles 
sobre los reportes generados y la solución de los mismos. 
 
3.2 Arquitectura 
 
Para el desarrollo de la aplicación, la arquitectura está basada en un sistema multicanal bajo el 
modelo vista controlador (MVC), donde se tiene un componente que expondrá servicios RESTful los 
cuales están de manera agnóstica a quien los consume, es decir; representan el concepto de negocio 
no la funcionalidad de un consumidor en específico. La gestión del código del sistema asi como las 
dependencias necesarias para su correcto funcionamiento serán gestionadas mediante GIT y Maven 
respectivamente. 
 
Modelo Vista Controlador (MVC) 
 
Es un estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, 
y la lógica de control en tres componentes distintos. 
 
Se trata de un modelo muy maduro y que ha demostrado su validez a lo largo de los años en todo 
tipo de aplicaciones, y sobre multitud de lenguajes y plataformas de desarrollo. 
 
El Modelo que contiene una representación de los datos que maneja el sistema, su lógica de negocio, 
y sus mecanismos de persistencia. 
9 
 
 
La Vista, o interfaz de usuario, que compone la información que se envía al cliente y los mecanismos 
interacción con éste. 
 
El Controlador, que actúa como intermediario entre el Modelo y la Vista, gestionando el flujo de 
información entre ellos y las transformaciones para adaptar los datos a las necesidades de cada uno. 
 
El modelo es el responsable de: 
 
 Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente 
del sistema de almacenamiento. 
 Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: 
"Si la mercancía pedida no está en el almacén, consultar el tiempo de entrega estándar del 
proveedor". 
 Lleva un registro de las vistas y controladores del sistema. 
 Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda 
producir un agente externo (por ejemplo, un fichero por lotes que actualiza los datos, un 
temporizador que desencadena una inserción, etc.). 
 
El controlador es responsable de: 
 
 Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.). 
 Contiene reglas de gestión de eventos, del tipo "SI Evento Z, entonces Acción W". Estas 
acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las 
vistas puede ser una llamada al método "Actualizar()". 
Las vistas son responsables de: 
 
 Recibir datos del modelo y los muestra al usuario. 
 Tienen un registro de su controladorasociado (normalmente porque además lo instancia). 
 Pueden dar el servicio de "Actualización()", para que sea invocado por el controlador o por 
el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos 
por otros agentes). 
 
Flujo MVC 
 
El flujo que sigue el control generalmente es el siguiente: 
 
10 
 
El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un 
botón, enlace, etc.) 
El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción 
solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un 
gestor de eventos (handler) o callback. 
 
El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a 
la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del 
usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando 
que encapsula las acciones y simplifica su extensión. 
 
El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista 
obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los 
cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El 
modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón 
Observador para proveer cierta dirección entre el modelo y la vista, permitiendo al modelo notificar 
a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a 
los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no 
pasa objetos de dominio (el modelo) a la vista, aunque puede dar la orden a la vista para que se 
actualice. 
 
La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente. 
 
Multicanalidad 
 
El término multicanalidad se refiere a tener la capacidad de proveer una funcionalidad de negocio 
por diferentes medios de comunicación, esto con la finalidad de poder aumentar la capacidad de 
alcance de cara a un consumidor. 
 
Este enfoque comenzó a tomar fuerza en los años 2000 cuando se intentó tener convergencia entre 
distintos medios de comunicación (email, fax, SMS) con la evolución de la tecnología este enfoque 
ha cambiado y se ha adaptado a las nuevas formas de comunicación actuales como la web, apps 
móviles, video llamadas, redes sociales, etc. 
 
La importancia de la multicanalidad es permitirle al consumidor el acercamiento con la oferta y/o 
producto por el canal donde él lo decida, con esto se busca generar identidad y acercamiento con el 
consumidor. 
 
11 
 
Los principales CRMs ya soportan la multicanalidad en un único repositorio, para realizar todas las 
consultas cruzadas que se deseen. 
 
En este contexto, el cliente puede, por ejemplo, ponerse en contacto con la empresa presentándose 
en un punto de venta, llamando por teléfono fijo o móvil, enviando un fax o SMS (incluso un 
Whatsapp), visitando el sitio web corporativo, enviando un e-mail al servicio de atención, pidiendo 
ser contactado por un comercial, estableciendo una videoconferencia, o solicitando información por 
correo tradicional. 
 
¿Qué beneficios aporta? 
 
1. Mejora del servicio general a los clientes. 
2. Incremento de la confianza de los clientes tradicionales. 
3. Adquisición de nuevos clientes en nuevos segmentos o nichos de mercado. 
4. Mayor flujo de información hacia y desde el cliente. 
5. Mayores posibilidades de lograr la fidelización y el engagement o vinculación. 
6. Generación de nuevas vías de venta e incremento de la participación de mercado. 
7. Mejora general de la calidad y el valor añadido de la relación con los clientes. 
 
En síntesis, la multicanalidad favorece la interacción con los clientes y, al mismo tiempo, permite a 
las empresas recoger de forma directa y en el momento los cambios del mercado. 
 
3.3 Software y tecnologías empleadas 
 
Las tecnologías empleadas para el desarrollo de esta app son las que a continuación se detallan. 
 
JAVA 
 
Java es un lenguaje de programación creado por Sun Microsystems, (empresa que posteriormente 
fue comprada por Oracle) para poder funcionar en distintos tipos de procesadores. Su sintaxis es 
muy parecida a la de C o C++, e incorpora como propias algunas características que en otros 
lenguajes son extensiones: gestión de hilos, ejecución remota, etc. El código Java, una vez 
compilado, puede llevarse sin modificación alguna sobre cualquier máquina, y ejecutarlo. Esto se 
debe a que el código se ejecuta sobre una máquina hipotética o virtual, la Java Virtual Machine, que 
se encarga de interpretar el código (ficheros compilados .class) y convertirlo a código particular de 
la CPU que se esté utilizando (siempre que se soporte dicha máquina virtual). 
12 
 
Hoy en día, puede encontrar la tecnología Java en redes y dispositivos que comprenden desde 
Internet y superordenadores científicos hasta portátiles y teléfonos móviles; desde simuladores de 
mercado en Wall Street hasta juegos de uso doméstico y tarjetas de crédito: Java está en todas 
partes. 
 
VERSIONES Y DISTRIBUCIONES DE JAVA 
 
Java, como la mayoría de los lenguajes, ha sufrido diversos cambios a lo largo de su historia. 
Además, en cada momento han coexistido distintas versiones o distribuciones de Java con distintos 
fines. Actualmente puede considerarse que el Java vigente se denomina Java 2 y existen 3 
distribuciones principales de Java 2, con ciertos aspectos comunes y ciertos aspectos divergentes. 
 
 Estas tres distribuciones son: 
 
a) J2SE o simplemente Java SE: Java 2 Standard Edition o Java Standard Edition. Orientado al 
desarrollo de aplicaciones cliente / servidor. No incluye soporte a tecnologías para internet. Es la 
base para las otras distribuciones Java y es la plataforma que utilizaremos nosotros en este curso 
por ser la más utilizada. 
b) J2EE: Java 2 Enterprise Edition. Orientado a empresas y a la integración entre sistemas. Incluye 
soporte a tecnologías para internet. Su base es J2SE. 
c) J2ME: Java 2 Micro Edition. Orientado a pequeños dispositivos móviles (teléfonos, tabletas, etc.). 
 
VERSIONES DE JAVA: 
 
JDK 1.0 (23 de enero de 1996) 
 
JDK 1.1 (19 de febrero de 1997). Una reestructuración intensiva del modelo de eventos AWT 
(Abstract Windowing Toolkit), clases internas (inner classes), JavaBeans, JDBC (Java Database 
Connectivity), para la integración de bases de datos, RMI (Remote Method Invocation). 
 
J2SE 1.2 (8 de dieciembre de 1998 - Nombre clave Playground. Esta y las siguientes versiones 
fueron recogidas bajo la denominación Java 2 y el nombre "J2SE" (Java 2 Platform, Standard 
Edition), reemplazó a JDK para distinguir la plataforma base de J2EE (Java 2 Platform, Enterprise 
Edition) y J2ME (Java 2 Platform, Micro Edition). 
13 
 
 
La palabra reservada (keyword) strictfp. 
Reflexión en la programación. 
La API gráfica ( Swing) fue integrada en las clases básicas. 
La máquina virtual (JVM) de Sun fue equipada con un compilador JIT (Just in Time) por primera vez. 
Java Plug-in. 
Java IDL, una implementación de IDL (Interfaz para Descripción de Lenguaje) para la 
interoperabilidad con CORBA 
Colecciones (Collections) 
 
2SE 1.3 (8 de mayo de 2000) - Nombre clave Kestrel. 
 
La inclusión de la máquina virtual de HotSpot JVM (la JVM de HotSpot fue lanzada inicialmente en 
abril de 1999, para la JVM de J2SE 1.2) 
RMI fue cambiado para que se basara en CORBA. 
JavaSound 
Se incluyó el Java Naming and Directory Interface (JNDI) en el paquete de librerías principales 
(anteriormente disponible como una extensión). 
Java Platform Debugger Architecture (JPDA) 
 
J2SE 1.4 (6 de febrero de 2002) - Nombre ClaveMerlin. 
 
Este fue el primer lanzamiento de la plataforma Java desarrollado bajo el Proceso de la Comunidad 
Java como JSR 59. Los cambios más notables fueron: comunicado de prensalista completa de 
cambios. 
 
Palabra reservada assert (Especificado en JSR 41.) 
Expresiones regulares modeladas al estilo de las expresiones regulares Perl. 
Encadenación de excepciones Permite a una excepción encapsular la excepción de bajo nivel 
original. 
14 
 
Non-blocking NIO (New Input/Output) (Especificado en JSR 51.) 
Logging API (Specified in JSR 47.) 
API I/O para la lectura y escritura de imágenes en formatos como JPEG o PNG 
Parser XML integrado y procesador XSLT (JAXP) (Especificado en JSR 5 y JSR 63.) 
Seguridad integrada y extensiones criptográficas (JCE, JSSE, JAAS) Java Web Start incluido (El 
primer lanzamiento ocurrió en marzo de 2001 para J2SE 1.3) (Especificado en JSR 56.) 
 
 
J2SE 5.0 (30 de septiembre de 2004) - Nombre clave: Tiger. (Originalmente numerado 1.5, esta 
notación aún es usada internamente.[4]) Desarrollado bajo JSR 176, Tiger añadió un número 
significativo de nuevas características comunicado de prensa. Plantillas (genéricos) - provee 
conversion de tipos (type safety) en tiempo de compilación para colecciones y elimina la necesidad 
de la mayoría de conversion de tipos (type casting). (Especificado por JSR 14.) 
 
Metadatos - también llamados anotaciones, permite a estructuras del lenguaje como las clases o los 
métodos, ser etiquetados con datos adicionales, que puedan ser procesados posteriormente por 
utilidades de proceso de metadatos. (Especificado por JSR 175.) 
 
Autoboxing/unboxing - Conversiones automáticas entre tipos primitivos (Como los int) y clases de 
envoltura primitivas (Como Integer). (Especificado por JSR 201.) 
 
Enumeraciones - la palabra reservada enum crea una typesafe, lista ordenada de valores (como 
Dia.LUNES, Dia.MARTES, etc.). Anteriormente, esto solo podía ser llevado a cabo por constantes 
enteras o clases construidas manualmente (enum pattern). (Especificado por JSR 201.) 
 
Varargs (número de argumentos variable) - El último parámetro de un método puede ser declarado 
con el nombre del tipo seguido por tres puntos (e.g. void drawtext(String... lines)). En la llamada al 
método, puede usarse cualquier número de parámetros de ese tipo, que serán almacenados en un 
array para pasarlos al metodo. 
 
Bucle for mejorado - La sintaxis para el bucle for se ha extendido con una sintaxis especial para iterar 
sobre cada miembro de un array o sobre cualquier clase que implemente Iterable, como la clase 
estándar Collection, de la siguiente forma: 
15 
 
 
void displayWidgets (Iterable widgets) { for (Widget w : widgets) { w.display(); } } Este ejemplo itera 
sobre el objeto Iterable widgets, asignando, en orden, cada uno de los elementos a la variable w, y 
llamando al método display() de cada uno de ellos. (Especificado por JSR 201.) 
Java SE 6 (11 de diciembre de 2006) - Nombre clave Mustang. Estuvo en desarrollo bajo la JSR 270. 
En esta versión, Sun cambió el nombre "J2SE" por Java SE y eliminó el ".0" del número de 
versión.[5]. Está disponible en http://java.sun.com/javase/6/. Los cambios más importantes 
introducidos en esta versión son: 
 
Incluye un nuevo marco de trabajo y APIs que hacen posible la combinación de Java con lenguajes 
dinámicos como PHP, Python, Ruby y JavaScript. 
Incluye el motor Rhino, de Mozilla, una implementación de Javascript en Java. 
Incluye un cliente completo de Servicios Web y soporta las últimas especificaciones para Servicios 
Web, como JAX-WS 2.0, JAXB 2.0, STAX y JAXP. 
Mejoras en la interfaz gráfica y en el rendimiento. 
 
Java SE 7 - Nombre clave Dolphin. En el año 2006 aún se encontraba en las primeras etapas de 
planificación. Se espera que su desarrollo dé comienzo en la primavera de 2006, y se estima su 
lanzamiento para 2008. 
 
Soporte para XML dentro del propio lenguaje 
Un nuevo concepto de superpaquete 
Soporte para closures 
Introducción de anotaciones estándar para detectar fallos en el software. 
 
Además de los cambios en el lenguaje, con el paso de los años se han efectuado muchos más 
cambios dramáticos en la librería de clases de Java (Java class library) que ha crecido de unos pocos 
cientos de clases en JDK 1.0 hasta más de tres mil en J2SE 5.0. APIs completamente nuevas, como 
Swing y Java2D, han sido introducidas y muchos de los métodos y clases originales de JDK 1.0 
están desaprobados. 
 
ANDROID 
 
16 
 
Android es un sistema operativo desarrollado para teléfonos móviles, antes de su llegada ya se 
contaba con otros sistemas dedicados a este segmento entre los que destacan IOS, Symbian y 
Blackberry OS. La principal diferencia en su diseño es que está basado en Linux, pero ¿Esto qué 
significa? Representa el primer sistema operativo libre, gratuito y multiplataforma. 
El sistema operativo Android de Google es una de las pruebas tecnológicas más recientes de cómo 
el código abierto puede convertirse en el planteamiento más exitoso a la hora de plantear los últimos 
avances del sector. 
 
En la actualidad, y tras pasar por distintas fases e incontables versiones, Android es el sistema 
operativo más utilizado en el mercado de los dispositivos móviles, como en smartphones y tablets. 
Son muchas marcas las que lo utilizan y su perfeccionamiento está llegando a elevados niveles de 
calidad. El interés que despierta se ha visto replicado en otro tipo de dispositivos, llegando también 
al mercado de los ordenadores portátiles. 
 
El sistema permite poder desarrollar aplicaciones en un lenguaje que no es más que una variación 
del lenguaje JAVA, adicional proporciona interfaces para acceder a las funciones del teléfono (GPS, 
agenda, cámara, etc.). A pesar de estas bondades era un sistema casi desconocido hasta que en 
2005 fue adquirido por el gigante Google, el primer punto de quiebre para su completo despegue fue 
que en el año 2007 se lanzó la Open Handset Alliance donde se proporcionó la primera versión de 
Android con su SDK con lo que se abría la puerta para que cualquier persona con las habilidades 
mínimas de programación pudiera crear sus propias aplicaciones. 
 
El historial de versiones del sistema operativo Android se inició con el lanzamiento de 
Android beta en noviembre de 2007. La primera versión comercial (de prueba), Android 1.0, fue 
lanzada en septiembre de 2008. Android es un sistema operativo móvil desarrollado por Google y 
la Open Handset Alliance, y ha visto un número de actualizaciones a su sistema operativo base 
desde su lanzamiento original. Estas actualizaciones típicamente corrigen fallos de programa y 
agregan nuevas funcionalidades. Desde abril de 2009, las versiones de Android han sido 
desarrolladas bajo un nombre en clave y sus nombres siguen un orden alfabético: Cupcake, Donut, 
Éclair, Froyo, Gingerbread, Honeycomb, Ice Cream Sandwich, Jelly Bean, KitKat, Lollipop, 
Marshmallow, Nougat lanzado en agosto de 2016 y el ya anunciado "Android Oreo". 
 
https://es.wikipedia.org/wiki/Android
https://es.wikipedia.org/wiki/Fases_del_desarrollo_de_software#Beta
https://es.wikipedia.org/wiki/Sistema_operativo_m%C3%B3vil
https://es.wikipedia.org/wiki/Google
https://es.wikipedia.org/wiki/Open_Handset_Alliance
https://es.wikipedia.org/wiki/Parche_(inform%C3%A1tica)
https://es.wikipedia.org/wiki/Error_de_software
https://es.wikipedia.org/wiki/Nombre_en_clave
https://es.wikipedia.org/wiki/Android_Oreo
17 
 
Nombre código Número de versión Fecha de lanzamiento 
Nivel de 
API 
Android 1.01 1.0 23 de septiembre 2008 1 
Android 1.11 1.1 9 de febrero 2009 2 
Cupcake 1.5 27 de abril de 2009 3 
Donut 1.6 
15 de 
septiembre de 2009 
4 
Eclair 2.0–2.1 26 de octubre de 2009 5-7 
Froyo 2.2–2.2.3 20 de mayo 2010 8 
Gingerbread 2.3–2.3.7 6 de diciembre 2010 9–10 
Honeycomb2 3.0–3.2.6 22 de febrero de 2011 11–13 
Ice Cream 
Sandwich 
4.0–4.0.5 18 de octubre2011 14–15 
Jelly Bean 4.1–4.3.1 9 de julio de 2012 16–18 
KitKat 
4.4–4.4.4, 4.4W–
4.4W.2 
31 de octubre de 2013 19–20 
Lollipop 5.0–5.1.1 12 de noviembre de 2014 21–22 
Marshmallow 6.0–6.0.1 5 de octubre de 2015 23 
https://es.wikipedia.org/wiki/Anexo:Historial_de_versiones_de_Android#Android_1.0_(API_1)
https://es.wikipedia.org/wiki/Anexo:Historial_de_versiones_de_Android#Android_1.0_(API_1)
https://es.wikipedia.org/wiki/23_de_septiembre
https://es.wikipedia.org/wiki/2008
https://es.wikipedia.org/wiki/Anexo:Historial_de_versiones_de_Android#Android_1.1_(API_2)
https://es.wikipedia.org/wiki/Anexo:Historial_de_versiones_de_Android#Android_1.1_(API_2)
https://es.wikipedia.org/wiki/9_de_febrero
https://es.wikipedia.org/wiki/2009
https://es.wikipedia.org/wiki/Android_Cupcake
https://es.wikipedia.org/wiki/27_de_abril
https://es.wikipedia.org/wiki/2009
https://es.wikipedia.org/wiki/15_de_septiembre
https://es.wikipedia.org/wiki/15_de_septiembre
https://es.wikipedia.org/wiki/2009
https://es.wikipedia.org/wiki/Android_Eclair
https://es.wikipedia.org/wiki/26_de_octubre
https://es.wikipedia.org/wiki/2009
https://es.wikipedia.org/wiki/Android_Froyo
https://es.wikipedia.org/wiki/20_de_mayo
https://es.wikipedia.org/wiki/2010
https://es.wikipedia.org/wiki/Android_Gingerbread
https://es.wikipedia.org/wiki/6_de_diciembre
https://es.wikipedia.org/wiki/2010
https://es.wikipedia.org/wiki/Android_Honeycomb
https://es.wikipedia.org/wiki/Android_Honeycomb
https://es.wikipedia.org/wiki/22_de_febrero
https://es.wikipedia.org/wiki/2011
https://es.wikipedia.org/wiki/Android_Ice_Cream_Sandwich
https://es.wikipedia.org/wiki/Android_Ice_Cream_Sandwich
https://es.wikipedia.org/wiki/18_de_octubre
https://es.wikipedia.org/wiki/2011
https://es.wikipedia.org/wiki/Android_Jelly_Bean
https://es.wikipedia.org/wiki/9_de_julio
https://es.wikipedia.org/wiki/2012
https://es.wikipedia.org/wiki/Android_KitKat
https://es.wikipedia.org/wiki/31_de_octubre
https://es.wikipedia.org/wiki/2013
https://es.wikipedia.org/wiki/Android_Lollipop
https://es.wikipedia.org/wiki/12_de_noviembre
https://es.wikipedia.org/wiki/2014
https://es.wikipedia.org/wiki/Android_Marshmallow
https://es.wikipedia.org/wiki/5_de_octubre
https://es.wikipedia.org/wiki/2015
18 
 
Nombre código Número de versión Fecha de lanzamiento 
Nivel de 
API 
Nougat 7.0 - 7.1.2 15 de junio de 2016 24-25 
Oreo 8.0 21 de agosto de 2017 
26 
 
 
 
Tabla 1. Versiones de Android 
MySQL 
 
MySQL es un sistema de gestión de bases de datos relacional desarrollado bajo licencia dual 
GPL/Licencia comercial por Oracle Corporation y está considerada como la base datos open source 
más popular del mundo,12 y una de las más populares en general junto a Oracle y Microsoft SQL 
Server, sobre todo para entornos de desarrollo web. 
 
MySQL fue inicialmente desarrollado por MySQL AB (empresa fundada por David Axmark, Allan 
Larsson y Michael Widenius). MySQL A.B. fue adquirida por Sun Microsystems en 2008, y ésta a su 
vez fue comprada por Oracle Corporation en 2010, la cual ya era dueña desde 2005 de Innobase 
Oy, empresa finlandesa desarrolladora del motor InnoDB para MySQL. 
 
Al contrario de proyectos como Apache, donde el software es desarrollado por una comunidad 
pública y los derechos de autor del código están en poder del autor individual, MySQL es patrocinado 
por una empresa privada, que posee el copyright de la mayor parte del código. Esto es lo que 
posibilita el esquema de doble licenciamiento anteriormente mencionado. La base de datos se 
distribuye en varias versiones, una Community, distribuida bajo la Licencia pública general de GNU, 
versión 2, y varias versiones Enterprise, para aquellas empresas que quieran incorporarlo en 
productos privativos. Las versiones Enterprise incluyen productos o servicios adicionales tales como 
herramientas de monitorización y soporte oficial. En 2009 se creó un fork denominado MariaDB por 
algunos desarrolladores (incluido algunos desarrolladores originales de MySQL) descontentos con 
el modelo de desarrollo y el hecho de que una misma empresa controle a la vez los productos MySQL 
y Oracle Database.3 
 
https://es.wikipedia.org/wiki/Android_Nougat
https://es.wikipedia.org/wiki/15_de_junio
https://es.wikipedia.org/wiki/2016
https://es.wikipedia.org/wiki/Android_Oreo
https://es.wikipedia.org/wiki/21_de_agosto
https://es.wikipedia.org/wiki/2017
19 
 
Está desarrollado en su mayor parte en ANSI C y C++.4 Tradicionalmente se considera uno de los 
cuatro componentes de la pila de desarrollo LAMP y WAMP. 
Su principal lenguaje de consulta es Transact-SQL, una aplicación de las normas ANSI / ISO 
estándar Structured Query Language (SQL) utilizado por ambas Microsoft y Sybase. Características 
de Microsoft SQL Server: 
 Soporte de transacciones. 
 Escalabilidad, estabilidad y seguridad. 
 Soporta procedimientos almacenados. 
 
Este sistema incluye una versión reducida, llamada MSDE con el mismo motor de base de datos, 
pero orientado a proyectos más pequeños, que en su versión 2005 pasa a ser el SQL Express 
Edition, que se distribuye en forma gratuita, el sistema utiliza la misma, pero en su versión 2008. 
 
MySQL 5.6 es la mejor versión de la base de datos de código abierto más popular del mundo y 
proporciona un nuevo conjunto de funciones avanzadas diseñadas para permitir a aquellos que están 
construyendo la próxima generación de aplicaciones y servicios basados en la Web y embebidos. 
Este documento técnico ofrece una visita guiada a través de las características y mejoras clave y 
proporciona ejemplos y recursos para apoyar los detalles técnicos y la implementación. Al leer usted 
ganará una comprensión de lo que diferencia a MySQL 5.6 de las versiones anteriores: 
 Mejor rendimiento y escalabilidad 
 Motor de almacenamiento InnoDB mejorado para transacciones más eficaces 
 Optimizador mejorado para lograr mejores tiempos de ejecución de consultas y diagnósticos 
 Mejor disponibilidad de aplicaciones con cambios en DDL/esquema en línea 
 Mejor agilidad para desarrolladores con acceso NoSQL con API de Memcached a InnoDB 
 Replicación mejorada para lograr implementaciones de alto rendimiento y de autorreparación 
 Esquema de rendimiento mejorado para una mayor instrumentación y monitoreo 
 
JSON 
 
JavaScript Object Notation (JSON) es un formato basado en texto estándar para representar datos 
estructurados en la sintaxis de objetos de JavaScript. Es comúnmente utilizado para transmitir datos 
en aplicaciones web (por ejemplo: enviar algunos datos desde el servidor al cliente, así estos datos 
pueden ser mostrados en páginas web, o vice versa). 
 
20 
 
Al diseñar una aplicación que se comunicará con un equipo remoto, se debe seleccionar un protocolo 
para el formato e intercambio de los datos. Existe una variedad de opciones abiertas y 
estandarizadas y la elección ideal depende de los requisitos de las aplicaciones y de la funcionalidad 
preexistente. 
 
JSON es un formato de datos basado en texto que sigue la sintaxis de objeto de JavaScript, 
popularizado por Douglas Crockford. Aunque es muy parecido a la sintaxis de objeto literal de 
JavaScript, puede ser utilizado independientemente de JavaScript, y muchos ambientes de 
programación poseen la capacidad de leer (analizar; parse) y generar JSON. 
 
Los JSON son cadenas - útiles cuando se quiere transmitir datos a través de una red. Debe ser 
convertido a un objeto nativo de JavaScript cuando se requiera acceder a sus datos. Ésto no es un 
problema, dado que JavaScript posee un objeto global JSON que tiene los métodos disponibles para 
convertir entre ellos. 
 
Un objeto JSON puede ser almacenado en su propio archivo, que es básicamente sólo un archivo 
de texto con una extension .json, y una MIME type de application/json. 
 
JSON (JavaScript Object Notation) es un formato de intercambio de datos abierto y basado en texto 
nació como una alternativa a XML, el fácil uso en javascript hagenerado un gran número de 
seguidores de esta alternativa. Una de las mayores ventajas que tiene el uso de JSON es que puede 
ser leído por cualquier lenguaje de programación. Por lo tanto, puede ser usado para el intercambio 
de información entre distintas tecnologías. 
 
Lo bueno de JSON es su sencillez, un mensaje con formato según el estándar está compuesto de 
un único objeto o matriz de nivel superior. Los valores de elementos de matriz y objetos pueden ser 
objetos, matrices, cadenas, números, valores booleanos (verdadero y falso) o nulo. 
 
HTML/CSS 
 
Cascading Style Sheets y traducido, hoja de estilo en cascada o CSS, es un lenguaje usado para 
definir y crear la presentación de un documento estructurado escrito en HTML o XML. Con él puedes 
trabajar fácilmente en la nube. La idea que subyace tras su desarrollo consiste en separar la 
21 
 
estructura de un documento, de su presentación. Esto quiere decir, que con CSS resulta muy fácil 
cambiar el aspecto de una página web. 
 
Así, a los elementos de la página web creados con HTML se les dará la apariencia que se desee 
utilizando CSS: colores, espacios entre elementos, tipos de letra, separando de esta forma la 
estructura de la presentación. 
 
Esta separación entre la estructura y la presentación es muy importante, ya que permite que sólo 
cambiando los CSS se modifique completamente el aspecto de una página web. Esto posibilita, entre 
otras cosas, que los usuarios puedan usar hojas de estilo personalizadas (como hojas de estilo de 
alto contraste o de accesibilidad). 
El W3C define las especificaciones del estándar CSS. Después, los navegadores intentan 
implementar esas especificaciones, para que las páginas web se vean igual en todos ellos. 
 
Los navegadores cada vez cumplen más y mejor el estándar CSS. Por ejemplo: Internet Explorer 6 
cumplía el estándar en sólo un 12% mientras que Internet Explorer 9 lo cumple en un 95%. Por eso 
se deben maquetar las páginas web siguiendo el estándar CSS y no las especificaciones de un 
navegador determinado. También hay que procurar mantener actualizado el navegador, ya que a 
medida que van cumpliendo el estándar, van añadiendo funcionalidades que antes no tenían. 
 
Por esta razón es el lenguaje principalmente usado por parte de los navegadores web de internet y 
por los desarrolladores, para elegir múltiples opciones de presentación como colores, tipos y 
tamaños de letra, entre otros. Es un lenguaje sumamente intuitivo y sencillo una vez que se aprende, 
ya que para su definición siempre se hace uso de un identificador de etiqueta HTML y luego se indica 
con qué aspecto se quieren mostrar las etiquetas que aparezcan en un documento. 
 
En cuanto a HyperText Markup Language, lenguaje de marcas de hipertexto, mejor conocido como 
HTML, es un lenguaje de marcado para la elaboración de páginas web en sus diferentes versiones. 
Define una estructura básica y un código (el código HTML) para la definición de contenido de una 
página web, como texto, imágenes, videos, entre otros. Es el estándar que se ha impuesto en la 
visualización de sitios web y es el que todos los navegadores actuales han adoptado. 
 
 
 
22 
 
GIT 
 
Git, es un software de control de versiones diseñado por Linus Torvalds. se define como control de 
versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto 
o una configuración del mismo es decir a la gestión de los diversos cambios que se realizan sobre 
los elementos de algún producto o una configuración. 
 
Fue creado pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de 
aplicaciones cuando éstas tienen un gran número de archivos de código fuente, es decir nos 
proporciona las herramientas para desarrollar un trabajo en equipo de manera inteligente y rápida y 
por trabajo nos referimos a algún software o página que implique código el cual necesitemos hacerlo 
con un grupo de personas. 
 
El diseño de Git resulta de la experiencia del diseñador de Linux, Linus Torvalds, manteniendo una 
enorme cantidad de código distribuida y gestionada por mucha gente, que incide en numerosos 
detalles de rendimiento, y de la necesidad de rapidez en una primera implementación. 
 
Entre las características más relevantes se encuentran: 
 Fuerte apoyo al desarrollo no lineal, por ende rapidez en la gestión de ramas y mezclado de 
diferentes versiones. Git incluye herramientas específicas para navegar y visualizar un historial 
de desarrollo no lineal. Una presunción fundamental en Git es que un cambio será fusionado 
mucho más frecuentemente de lo que se escribe originalmente, conforme se pasa entre varios 
programadores que lo revisan. 
 Gestión distribuida. Al igual que Darcs, BitKeeper, Mercurial, SVK, Bazaar y Monotone, Git le da 
a cada programador una copia local del historial del desarrollo entero, y los cambios se propagan 
entre los repositorios locales. Los cambios se importan como ramas adicionales y pueden ser 
fusionados en la misma manera que se hace con la rama local. 
 Los almacenes de información pueden publicarse por HTTP, FTP, rsync o mediante un 
protocolo nativo, ya sea a través de una conexión TCP/IP simple o a través de cifrado SSH. Git 
también puede emular servidores CVS, lo que habilita el uso de clientes CVS pre-existentes y 
módulos IDE para CVS pre-existentes en el acceso de repositorios Git. 
 Los repositorios Subversion y svk se pueden usar directamente con git-svn. 
 Gestión eficiente de proyectos grandes, dada la rapidez de gestión de diferencias entre archivos, 
entre otras mejoras de optimización de velocidad de ejecución. 
 Todas las versiones previas a un cambio determinado, implican la notificación de un cambio 
posterior en cualquiera de ellas a ese cambio (denominado autenticación criptográfica de 
historial). Esto existía en Monotone. 
https://es.wikipedia.org/wiki/Linux
https://es.wikipedia.org/wiki/Linus_Torvalds
https://es.wikipedia.org/wiki/Darcs
https://es.wikipedia.org/wiki/BitKeeper
https://es.wikipedia.org/wiki/Mercurial
https://es.wikipedia.org/w/index.php?title=SVK&action=edit&redlink=1
https://es.wikipedia.org/wiki/Bazaar_(software)
https://es.wikipedia.org/wiki/Monotone
https://es.wikipedia.org/wiki/HTTP
https://es.wikipedia.org/wiki/File_Transfer_Protocol
https://es.wikipedia.org/wiki/Rsync
https://es.wikipedia.org/wiki/SSH
https://es.wikipedia.org/wiki/CVS
https://es.wikipedia.org/wiki/Monotone
23 
 
 Resulta algo más caro trabajar con ficheros concretos frente a proyectos, eso diferencia el 
trabajo frente a CVS, que trabaja con base en cambios de fichero, pero mejora el trabajo con 
afectaciones de código que concurren en operaciones similares en varios archivos. 
 Los renombrados se trabajan basándose en similitudes entre ficheros, aparte de nombres de 
ficheros, pero no se hacen marcas explícitas de cambios de nombre con base en supuestos 
nombres únicos de nodos de sistema de ficheros, lo que evita posibles, y posiblemente 
desastrosas, coincidencias de ficheros diferentes en un único nombre. 
 Realmacenamiento periódico en paquetes (ficheros). Esto es relativamente eficiente para 
escritura de cambios y relativamente ineficiente para lectura si el reempaquetado (con base en 
diferencias) no ocurre cada cierto tiempo. 
 
Órdenes básicas 
 
git fetch: 
Descarga los cambios realizados en el repositorio remoto. 
 
git merge <nombre_rama>: 
Impacta en la rama en la que te encuentras parado, los cambios realizados en la rama 
“nombre_rama”. 
 
git pull: 
Unifica los comandos fetch y merge en un único comando. 
 
git commit -am "<mensaje>": 
Confirma los cambios realizados. El “mensaje” generalmente se usa para asociar al commit una 
breve descripción de los cambios realizados. 
 
git push origin <nombre_rama>: 
Sube la rama “nombre_rama” al servidor remoto. 
 
git status: 
Muestra el estado actual de la rama, como los cambios que haysin commitear. 
 
git add <nombre_archivo>: 
24 
 
Comienza a trackear el archivo “nombre_archivo”. 
 
git checkout -b <nombre_rama_nueva>: 
Crea una rama a partir de la que te encuentres parado con el nombre “nombre_rama_nueva”, y luego 
salta sobre la rama nueva, por lo que quedas parado en esta última. 
 
git checkout -t origin/<nombre_rama>: 
Si existe una rama remota de nombre “nombre_rama”, al ejecutar este comando se crea una rama 
local con el nombre “nombre_rama” para hacer un seguimiento de la rama remota con el mismo 
nombre. 
 
git branch: 
Lista todas las ramas locales. 
 
git branch -a: 
Lista todas las ramas locales y remotas. 
 
git branch -d <nombre_rama>: 
Elimina la rama local con el nombre “nombre_rama”. 
 
git push origin <nombre_rama>: 
Commitea los cambios desde el branch local origin al branch “nombre_rama”. 
 
git remote prune origin: 
Actualiza tu repositorio remoto en caso que algún otro desarrollador haya eliminado alguna rama 
remota. 
 
git reset --hard HEAD: 
Elimina los cambios realizados que aún no se hayan hecho commit. 
 
25 
 
git revert <hash_commit>: 
Revierte el commit realizado, identificado por el “hash_commit”. 
 
UML 
 
UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los 
elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de 
facto de la industria, debido a que ha sido concebido por los autores de los tres métodos más usados 
de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. 
 
En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la 
industria como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y 
desarrolladores. 
 
Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que 
incorpora las principales ventajas de cada uno de los métodos particulares en los que se basa: 
Booch, OMT y OOSE. UML ha puesto fin a las llamadas “guerras de métodos” que se han mantenido 
a lo largo de los 90, en las que los principales métodos sacaban nuevas versiones que incorporaban 
las técnicas de los demás. Con UML se fusiona la notación de estas técnicas para formar una 
herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo orientado 
a objetos. 
 
Las grandes aplicaciones empresariales los que ejecutan aplicaciones de negocios, y mantener una 
empresa va deben ser algo más que un grupo de módulos de código. Ellos deben estructurarse de 
una manera que permite la escalabilidad, seguridad y ejecución robusta bajo condiciones de estrés, 
y su estructura debe ser definido con suficiente claridad para que los programadores de 
mantenimiento puedan encontrar y corregir un error que aparece mucho después de los autores 
originales se han trasladado a otros proyectos. Es decir, estos programas deben ser diseñados para 
trabajar perfectamente en muchas áreas, y la funcionalidad de negocio no es el único (aunque sin 
duda es el núcleo esencial). Por supuesto, una arquitectura bien diseñada beneficia a cualquier 
programa, y no sólo los más grandes, ya que hemos señalado aquí. Mencionamos grandes 
aplicaciones en primer lugar porque la estructura es una forma de lidiar con la complejidad, por lo 
que los beneficios de la estructura (y de modelado y diseño, como demostraremos) compuesto como 
el tamaño de la aplicación aumenta de tamaño. Otra ventaja de la estructura es que permite la 
reutilización de código: El tiempo de diseño es el momento más fácil de estructurar una aplicación 
26 
 
como un conjunto de módulos o componentes independientes. Con el tiempo, las empresas a 
construir una biblioteca de modelos de componentes, cada uno representando una aplicación 
almacenada en una biblioteca de módulos de código. Cuando otra aplicación necesita la misma 
funcionalidad, el diseñador puede importar rápidamente su módulo de la biblioteca. Al tiempo de 
codificación, el desarrollador puede simplemente importar lo más rápidamente el módulo de código 
en la aplicación. 
 
El modelado es el diseño de aplicaciones de software antes de la codificación. 
 
El modelado es una parte esencial de grandes proyectos de software, y útil para proyectos medianos 
e incluso pequeños también. Un modelo juega el papel análogo en el desarrollo de software que 
planos y otros planes (los mapas de sitio, elevaciones, modelos físicos) juegan en la construcción 
de un rascacielos. Utilizando un modelo, los responsables del éxito de un proyecto de desarrollo de 
software puede asegurar a sí mismos de que la funcionalidad del negocio es completa y correcta, se 
satisfacen las necesidades de los usuarios finales, y el diseño del programa es compatible con los 
requisitos de escalabilidad, robustez, seguridad, extensibilidad, y otras características, antes de la 
implementación en el código hace que los cambios difíciles y costosos de realizar. Las encuestas 
muestran que los grandes proyectos de software tienen una gran probabilidad de fracaso de hecho, 
es más probable que una aplicación de software grande no va a cumplir todos sus requisitos a tiempo 
y dentro del presupuesto de que tendrá éxito. Si se está utilizando uno de estos proyectos, que tiene 
que hacer todo lo posible para aumentar las probabilidades de éxito, y el modelado es la única 
manera de visualizar su diseño y compararla con los requisitos antes de que su equipo empieza a 
código. 
 
Elevar el nivel de abstracción 
 
Modelos nos ayudan por dejarnos trabajar a un nivel más alto de abstracción. Un modelo puede 
hacer esto al ocultar o enmascarar los detalles, llevando a cabo el panorama general, o centrándose 
en diferentes aspectos del prototipo. En UML 2.0, puede alejar una vista detallada de una aplicación 
en el entorno en el que se ejecuta, la visualización de las conexiones a otras aplicaciones o zoom, 
aún más, a otros sitios. Como alternativa, puede centrarse en diferentes aspectos de la aplicación, 
tales como el proceso de negocio que automatiza, o una vista de reglas de negocio. La nueva 
capacidad de los elementos del modelo nido, añadido en UML 2.0, apoya este concepto 
directamente. 
 
27 
 
Del OMG Unified Modeling Language ™ (UML) ayuda a especificar, visualizar y documentar 
esquemas de sistemas de software, incluyendo su estructura y diseño, de manera que cumpla con 
todos estos requisitos. (Puede utilizar UML para el modelado de negocios y modelado de otros 
sistemas que no son de software también.) El uso de cualquiera de la gran cantidad de herramientas 
basadas en UML en el mercado, se pueden analizar los requisitos de su aplicación en el futuro y 
diseñar una solución que se encuentra con ellas, que representa los resultados utilizando trece tipos 
de diagramas estándar de UML 2.0. 
 
Puede modelar casi cualquier tipo de aplicación, que se ejecuta en cualquier tipo y combinación de 
hardware, sistema operativo, lenguaje de programación, y la red, en UML. Su flexibilidad le permite 
modelar aplicaciones distribuidas que utilizan casi cualquier middleware en el mercado. Basa en 
conceptos orientados a objetos fundamentales, incluyendo la clase y operación, es un paso natural 
para lenguajes orientados a objetos y entornos tales como C ++, Java, y la reciente C #, pero se 
puede usar para modelar aplicaciones no OO, así, por ejemplo, Fortran, VB, o COBOL. Perfiles UML 
(es decir, subconjuntos de UML a medida para fines específicos) le ayudan modelo transaccional, 
en tiempo real, y los sistemas de alta disponibilidad en una forma natural. 
 
UML Y MODEL DRIVEN ARCHITECTURE DE OMG (MDA) 
 
Hace algunos años, el mayor problema que enfrenta un desarrollador al iniciar un proyecto de 
programación distribuida era encontrar un middleware con la funcionalidad que necesitaba, que 
funcionó en los equipos y sistemas operativos que se ejecutan en su tienda.Hoy, frente a una 
vergonzosamente rica variedad de plataformas middleware, el desarrollador tiene tres diferentes 
problemas de middleware: En primer lugar, la selección de uno; En segundo lugar, conseguir que 
funcione con las otras plataformas ya desplegados no sólo en su propia tienda, sino también los de 
sus clientes y proveedores; y tercero, la interfaz con un nuevo "Algo casi perfecto" cuando una nueva 
plataforma llega y atrapa la imaginación de los analistas y, necesariamente, los CIO en todas partes. 
 
Con su rica paleta y middleware independencia, UML forma una base de OMG de Architecture Model 
Driven (MDA®). De hecho, un modelo UML puede ser independiente de la plataforma o específico 
de la plataforma, como queramos, y el proceso de desarrollo MDA utiliza estas dos formas: Cada 
estándar MDA o aplicación se basa, normativamente, en un modelo independiente de la plataforma 
(PIM), que representa su funcionalidad empresarial y el comportamiento de manera muy precisa, 
pero no incluye los aspectos técnicos. Desde el PIM, herramientas de desarrollo compatibles con 
MDA siguen OMG-estandarizados asignaciones para producir uno o más modelos específicos de la 
plataforma (PSM), también en UML, una para cada plataforma de destino que elija el desarrollador. 
28 
 
(Este paso de conversión es altamente automatizado, pero no es magia: Antes de la herramienta 
produce un PSM, el desarrollador debe realizar anotaciones en el PIM base para producir una forma 
más específica, pero todavía PIM independiente de la plataforma que incluye detalles de la 
semántica deseados, y guía a las opciones que la herramienta tendrá que hacer Debido a las 
similitudes entre plataformas middleware de un género determinado -.-basa componente, o basados 
en la mensajería, por ejemplo -. esta guía se puede incluir en un PIM sin hacerle específico de la 
plataforma. 
 
Aun así, los desarrolladores tendrán que afinar los PSM producidos en cierta medida, más en los 
primeros días de la MDA, pero cada vez menos como herramientas y algoritmos de antemano. 
 
El PSM contiene la misma información que una aplicación, pero en la forma de un modelo UML en 
lugar de ejecutar código. En el siguiente paso, la herramienta genera el código que se ejecuta desde 
el PSM, junto con otros archivos necesarios (incluidos los archivos de definición de interfaz, si es 
necesario, archivos de configuración, archivos make, y otros tipos de archivo). Después de dar a los 
desarrolladores la oportunidad de entregar con precisión el código generado, la herramienta ejecuta 
los archivos make para producir una aplicación final de despliegue. 
 
Aplicaciones de MDA son componibles: Si importa PIM para los módulos, servicios, u otras 
aplicaciones de MDA en su herramienta de desarrollo, puede dirigirla para generar llamadas a través 
de lo que sea interfaces y protocolos necesarios, incluso si éstos corren multiplataforma. Y 
aplicaciones de MDA son a prueba de futuro: Cuando un nuevo "Algo casi perfecto" viene en el 
mercado, los miembros OMG generarán y estandarizar una asignación a ella, y su proveedor 
actualizará su herramienta permitida por la MDA para incluirlo. Aprovechando estos acontecimientos, 
usted será capaz de generar invocaciones de plataforma cruzada a la nueva plataforma, e incluso el 
puerto de MDA sus aplicaciones existentes a la misma, de forma automática utilizando sus PIM 
existentes. 
 
Pasos para el desarrollo de una aplicación basada en UML. 
 
Seleccionar una metodología: Una metodología define formalmente el proceso que se utiliza para 
reunir los requisitos, analizarlos, y el diseño de una aplicación que se encuentra con ellos en todos 
los sentidos. Hay muchas metodologías, cada uno diferente de alguna manera o maneras de los 
otros. Hay muchas razones por las que la metodología puede ser mejor que otro para su proyecto 
en particular: Por ejemplo, algunos son más adecuados para las aplicaciones empresariales de gran 
29 
 
tamaño, mientras que otros están diseñados para diseñar pequeños sistemas embebidos o críticas 
para la seguridad. Por otro eje, algunos métodos mejor soporte un gran número de arquitectos y 
diseñadores que trabajan en el mismo proyecto, mientras que otros funcionan mejor cuando es 
utilizado por una sola persona o un pequeño grupo OMG, como una organización independiente del 
proveedor, no tiene una opinión sobre cualquier metodología. 
 
Seleccione una herramienta de desarrollo de UML: Dado que la mayoría (aunque no todos) las 
herramientas basadas en UML implementar una metodología particular, en algunos casos puede no 
ser práctico para recoger una herramienta y luego tratar de usarlo con una metodología que no fue 
construido para. (Para otras combinaciones de herramienta / metodología, esto podría no ser un 
problema, o podría ser fácil de solucionar). 
Sin embargo, algunas metodologías se han aplicado en múltiples herramientas para que esto no es 
estrictamente un entorno de una sola elección. 
 
Es posible encontrar una herramienta tan bien adaptado a su aplicación u organización que usted 
está dispuesto a cambiar las metodologías con el fin de usarlo. Si ese es el caso, seguir adelante - 
nuestro consejo para elegir una metodología primero es general, y no puede aplicarse a un proyecto 
específico. Otra posibilidad: Usted puede encontrar una metodología que le guste, que no está 
implementado en una herramienta que se adapte a su tamaño del proyecto, o su presupuesto, por 
lo que tiene que cambiar. Si cualquiera de estos casos sucede a usted, trate de elegir una 
metodología alternativa que no difiere demasiado de la que originalmente te preferido. 
 
 Al igual que con las metodologías, OMG no tiene una opinión o calificación de las herramientas de 
modelado basado en UML, pero sí tenemos enlaces a una serie de listas aquí. Estos le ayudarán a 
empezar a hacer su elección. 
 
Obtener Formación: Usted y su personal (a menos que la suerte de contratar a arquitectos UML-
experiencia) necesita un entrenamiento en UML. Lo mejor es obtener una formación que enseña 
cómo usar su herramienta elegida con su metodología elegida, normalmente proporcionada por el 
proveedor o bien la herramienta o metodólogo. 
 
Si decide no ir a esta ruta, echa un vistazo a la página de entrenamiento de OMG para un curso que 
se adapte a sus necesidades. Una vez que has aprendido UML, puede convertirse en un OMG-UML 
Certificado Profesional - marque aquí para obtener más información. 
 
30 
 
El resultado del Proceso Unificado fue un UML, Lenguaje de Modelo Unificado, es un "lenguaje de 
modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, 
para detallar los artefactos en el sistema y para documentar y construir. 
 
En otras palabras, es el lenguaje en el que está descrito el modelo. UML no es programación, solo 
se diagrama la realidad de una utilización en un requerimiento. Ayuda al usuario a entender la 
realidad de la tecnología y la posibilidad de que reflexione antes de invertir y gastar grandes 
cantidades en proyectos que no estén seguros en su desarrollo, reduciendo el coste y el tiempo 
empleado en la construcción de las piezas que constituirán el modelo. 
 
Una vista es simplemente un subconjunto de UML, que modela construcciones que representan un 
aspecto de un sistema. Las vistas se pueden dividir en tres áreas: clasificación, estructural, 
comportamiento dinámico y gestión del modelo. 
 
La clasificación estructural describe los elementos del sistema y sus relaciones con otros elementos. 
Incluyen clases, casos de uso, componentes, nodos y elementos que proporcionan la base sobre la 
cual se construye el comportamiento dinámico. Clasificación de vistas: Estática, casos de uso y de 
implementación. 
 
El comportamiento dinámico describe el sistema en el tiempo. Se puede describir como serie de 
cambios a las fotos del sistema dibujadasa partir de la cisión estática. Estas incluyen: vista de la 
máquina de estados, vista de actividad y la vista de interacción. 
 
La gestión del modelo describe la organización de los propios modelos en unidades jerárquicas. Los 
paquetes especiales incluyen a los modelos y los subsistemas. La vista de gestión del modelo cruza 
las otras vistas y las organiza para el trabajo de desarrollo y el control de configuración. 
 
Vista de los casos de uso 
 
La vista de los casos de uso modela la funcionalidad del sistema según los perciben los usuarios 
externos, llamados actores. Un caso de uso es una unidad coherente de funcionalidad expresada 
como transacción entre los actores y el sistema. El propósito de la vista de casos de uso es enumerar 
a los actores y los casos de uso, y demostrar que actores participan en cada caso de uso. La Figura 
3.1 muestra un diagrama de casos de uso. 
31 
 
 
 Fig. 3.1. Diagrama de casos de uso 
Fuente: Demian, 2011. 
Vistas Físicas 
 
Las vistas físicas modelan la estructura de la implementación de la aplicación por sí misma, su 
organización en componentes, y su despliegue en nodos de ejecución. Estas vistas proporcionan 
una oportunidad de establecer correspondencias entre las clases y componentes de implementación 
de nodos. Hay dos vistas físicas: la vista de implementación y la vista de despliegue. Véase la figura 
3.2. 
 
 
Figura 3.2 Vistas Físicas UML 
FUENTE: Manuela Gordillo Bellido, 2008. 
32 
 
La vista de despliegue representa la disposición de las instancias de componentes de ejecución en 
instancias de nodos, un nodo es un recurso de ejecución, tal como una computadora, dispositivo o 
memoria esta vista permite determinar las consecuencias de la distribución u de la asignación de 
recursos. 
 
Las vistas de despliegue se representan en diagramas de despliegue, véase Figura 3.3, esté modela 
la arquitectura en tiempo de ejecución de un sistema, este diagrama muestra los tipos de nodos del 
sistema y los tipos de componentes que contienen. Un nodo se representa como un cubo. 
 
 
 
 
 
Fig. 3.3 Diagrama de despliegue 
Fuente: W3im.com, 2017. 
 
33 
 
Vista de actividades 
 
Un grafo de actividades es una variante de una máquina de estados, que muestras las actividades 
de computación implicada en la ejecución de un cálculo. Un estado de actividad representa una 
actividad; un paso en el flujo de trabajo o la ejecución de una operación. Un grafo de actividades 
describe grupos secuenciales y concurrentes de actividades. Los grafos de actividades se muestran 
en diagramas de actividades. 
 
Los parámetros de entrada y de salida de una acción se pueden mostrar usando las relaciones de 
flujo que conecta la acción y un estado de flujo del objeto. La Figura 3.4 muestra un diagrama de 
actividades. 
 
 
Fig. 3.4 Diagrama de actividades 
Fuente: Carlos UNAM, 2017. 
 
34 
 
Diagramas de Interacción 
 
Los diagramas de interacción son modelos que describen como grupos de objetos colaboran para 
conseguir algún fin. Estos diagramas muestran objetos, así como los mensajes que se pasan entre 
ellos dentro del caso de uso, los diagramas de interacción capturan el comportamiento de un caso 
de uso. 
 
Se expresan de dos maneras: 
1. diagramas de secuencia 
2. diagramas de colaboración 
 
 
 
Diagrama de Secuencia 
 
Un diagrama de secuencia muestra una interacción, que representa la secuencia de mensajes entre 
instancias de clases, componentes, subsistemas o actores. El tiempo fluye por el diagrama y muestra 
el flujo de control de un participante a otro. Utilice diagramas de secuencia para visualizar instancias 
y eventos, en lugar de clases y métodos. En el diagrama, puede aparecer más de una instancia del 
mismo tipo. También puede haber más de una ocurrencia del mismo mensaje. 
 
Muestra los objetos participantes en la interacción por sus líneas de vida, y los mensajes que 
intercambian entre ellos al correr del tiempo, sin embargo, no muestra los enlaces entre los objetos. 
 
Un diagrama de secuencias muestra las interacciones expresadas en función del tiempo. En 
concreto muestra los objetos participantes y los mensajes que intercambian entre ellos a lo largo del 
tiempo. Los diagramas de secuencias son más apropiados para especificar restricciones de 
interacción en tiempo real y tiene dos dimensiones, la vertical que representa el tiempo, y la horizontal 
que representa los distintos objetos. Véase figura 3.5. 
35 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 3.5 Diagrama de Secuencia. 
Fuente: Microsoft, 2017. 
 
Diagrama de Colaboración 
 
El diagrama de colaboración es una alternativa al diagrama de secuencia para modelar los 
escenarios del sistema. Aunque los diagramas de secuencia facilitan la visión del flujo cronológico 
de eventos, los diagramas de colaboración permiten mostrar enlaces entre objetos, valores de 
atributo y visibilidad. Los diagramas de colaboración son buenos para comprender todos los efectos 
sobre un objeto dado y también para el diseño de procedimientos. 
 
El diagrama de colaboración muestra cómo las instancias específicas de las clases trabajan juntas 
para conseguir un objetivo común. Implementa las asociaciones del diagrama de clases mediante el 
paso de mensajes de un objeto a otro. También muestra las relaciones sobre los objetos sin mostrar 
la dimensión temporal de dichas relaciones y la secuencia de los mensajes vendrá dada por números 
de secuencia. 
 
36 
 
Una colaboración puede estar asociada a una clase, a un método, (implementación de una 
operación), o a la realización de un caso de uso: Se está describiendo una implementación estos 
elementos internamente. 
 
Los objetos se representan mediante rectángulos y los nombres se subrayan. Se representan 
también los enlaces estáticos, instancias de asociaciones y elementos transitorios, como un 
argumento de una operación. Véase figura 3.6. 
 
 
Figura 3.6 Diagrama de Secuencia. 
Fuente: IBM, 2017. 
 
Diagrama de Clases 
 
Los diagramas de clases de UML pueden utilizarse para una gran variedad de propósitos: 
Para proporcionar una descripción de los tipos que se utilizan en un sistema y se pasan entre sus 
componentes que no tenga nada que ver con su implementación. 
37 
 
 
Por ejemplo, en el código .NET, el tipo Pedido de menú podría implementarse en la capa del negocio; 
en XML, en las interfaces entre los componentes; en SQL, en la base de datos, y en HTML, en la 
interfaz de usuario. Aunque estas implementaciones tengan un nivel de detalle diferente, la relación 
entre el tipo Pedido de menú y otros tipos, como Menú y Pago, es siempre la misma. El diagrama de 
clases de UML permite analizar estas relaciones con independencia de las implementaciones. 
Para clarificar el glosario de términos que se utiliza en la comunicación entre la aplicación y los 
usuarios y en las descripciones de las necesidades de los usuarios. Véase figura 3.7 
Relación con otros diagramas 
Un diagrama de clases de UML normalmente se crea junto con otros diagramas de modelado para 
proporcionar descripciones de los tipos que utilizan. En cada caso, la representación física de los 
tipos no está implícita en ninguno de los diagramas: diagrama de actividades, diagrama de 
secuencia, diagrama de componentes y diagrama de casos de uso. 
 
 
 
 
 
 
 
 
 
 
Figura 3.7 Diagrama de Clase. 
Fuente: Microsoft, 2017. 
 
 
 
38 
 
Modelo entidad-relación 
 
Es un modelo del que se dispone para diseñar esquemas que posteriormente debemos de 
implementar en un gestor de Base de datos. Este modelo se representa a través de diagramas y 
está formado por varios elementos. 
 
Dispone de un diagrama que ayuda a entender los datos y como se relacionan entre ellos, debe ser 
completado con un pequeño resumen con la lista de atributos y las relaciones de cada elemento. 
Entidad: Las entidades representan cosas u

Otros materiales