Descarga la aplicación para disfrutar aún más
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
Compartir