Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
1 ANALISIS DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE INFORMACIÓN PARA LA GESTIÓN DE ALQUILER Y MANTENIMIENTO DE VEHICULOS. YESID ORDUZ NAVARRETE UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS. FACULTAD DE INGENIERÍA. PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS. BOGOTÁ. 2016 2 ANALISIS DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE INFORMACIÓN PARA LA GESTIÓN DE ALQUILER Y MANTENIMIENTO DE VEHICULOS. YESID ORDUZ NAVARRETE Proyecto de Pasantía para optar al título de Ingeniero de Sistemas. Director Interno: Ing. Joaquín Javier Meza Docente Universidad Distrital. Director Externo: Ing. Hals Rodríguez Santamaría. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS. FACULTAD DE INGENIERÍA. PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS. BOGOTÁ. 2016 3 Tabla de contenido INTRODUCCIÓN………………………………………………………...2 1. FORMULACIÓN DEL PROBLEMA………………….………………....3 1.1.Descripción del Entorno……………………….…….….….………….3 1.2. Definición del Problema……………………………….…..………….3 2. JUSTIFICACION……………………………………………..…….….….4 2.1. Justificación Operativa……………………………………..…..……..4 2.2. Justificación Académica………………………………...…...……….5 3. OBJETIVOS…………………………………………………..…...………6 3.1. OBJETIVO GENERAL…………………………….…...……………6 3.2. OBJETIVOS ESPECÍFICOS……………………..…………………..6 4. ALCANCES Y LIMITACIONES…………………………………………7 4.1. ALCANCES…………………………………………………………..7 4.2. LIMITACIONES………………………………………...……………8 4.3.PARTICIPANTES EN EL PROYECTO………………..…………….8 5. MARCO REFERENCIAL….……………………………………………..9 5.1. Conceptos Relacionados con el Diseño de la Aplicación…......….…..9 5.1.1. Patrones de Diseño……………………………………….…..……..9 5.1.2. Ventajas de los patrones………………………………….………10 5.1.3. Modelo Vista Controlador……………………………..…………11 5.1.4. Arquitectura De Tres Capas…………………………..………….14 5.2.MARCO TEÓRICO…..………………………………….….……….16 5.2.1. FRAMEWORK………………………………………....…………16 5.2.2. Arquitectura……………………………………………...…………18 5.2.2.1. Modelo……….…………………………………………………..18 5.2.2.2. Vista……………………………………………….……………..18 5.2.2.3. Controlador……………………………………..………………..18 5.2.3. Estructura…………………………………………………………..19 5.2.3.1. Lógica………………………………………………..…………..19 5.2.4. Framework Laravel………………………….……….……………20 5.2.4.1. Componentes De Laravel……………….………………...……..21 5.2.4.2. Arquitectura Laravel……………………………………..….…..22 5.2.4.2.1. Ciclo De Vida De Una Solicitud……………………..……..…22 5.2.4.2.2. Estructura De La Aplicación………………………..…………23 5.2.4.2.3. Serviceproviders (Proveedores De Servicio)………….....……24 5.2.4.2.4.ServiceContainer……………………………………....……….25 5.2.4.2.5. Contratos (Contracts)………………….…………………..…..26 5.2.4.2.6. Facade………………………………..………………….……..27 5.5.5. Características De Laravel……………………………...………….27 6. DISEÑO METODOLOGICO…………………….……………….…..…29 6.1.Conocimiento Global de la Empresa…………….…………………..29 6.1.1.Reseña Histórica………………………………………………..….29 6.1.2. Objetivos de la organización……………………………...……….30 6.1.3. Definición de la Actividad de la Empresa…………………………31 6.1.4. Misión…………………………………………………………….32 6.1.5. Evaluación de la Misión……………………………….…………32 4 6.1.6. Matriz DOFA………………………………………..……………33 7. DESARROLLO DE SOFTWARE………………………….……………34 7.1. Fases Del Proyecto…………………………………………..………34 7.1.1. Fase de Inicio………………………….……….……………..……34 7.1.2. Modelado del Sistema………………….……..….…………….….34 7.1.3. Escenarios………………………….……….…………….…….….35 7.1.4. Fase de Elaboración……….……………….……..…………….….37 7.1.4.1 Actores Del Sistema………………….…………………………..38 7.1.4.2.Especificaciones De Casos De Uso………………….…………..40 8. MODELOS DE ANALISIS Y DISEÑO…………………………...…….43 8.1. Clases conceptuales………………………………………………….44 8.2. Modelo Entidad – Relación……………………………...…………..45 8.2.1. Diccionario de datos…………………………………...…………..46 8.3. Modelo de despliegue………………………………..………………54 8.4. Modelo vista controlador…………………………………………….55 8.5. Fase de construcción….……………………………………….....….56 8.5.1. Interfaces………..…...……………………………………...……..57 8.5.1.1. Interfaz de ingreso de usuarios al sistema……………………….57 8.5.1.2. Interfaz gestionar conductor…………………………………..…58 8.5.1.3. Interfaz gestionar vehículo…………………………………..…..58 8.5.1.4. Interfaz ver facturas…………………………………………..….59 8.5.1.5. Interfaz registrar daño de vehículo…………………..…………..59 8.5.1.6. Interfaz solicitud de alquiler……………………………………..60 8.5.1.7. Interfaz agendar vehículo………………………………………..60 8.5.1.8. Interfaz ingresar cliente…………………………...……………..61 8.5.1.9. Interfaz ingresar vehículo a taller………………………………..61 8.5.1.10. Interfaz entregar vehículo……………………………………....62 8.5.1.11.Interfaz registrar arreglo de vehículo……………………..…….62 8.5.2. Interfaces definitivas…………………………………………...….63 8.5.2.1. Interfaz de ingreso al sistema……………………………………63 8.5.2.2. Interfaz para cambiar el password……………………………....64 8.5.2.3. Interfaz de cambio de password…………………………………65 8.5.2.4. Interfaz de inicio del sistema…………………………………....65 8.5.2.5. Interfaz formulario de ingreso de solicitud……………………..66 8.5.2.6. Detalle de solicitud…………………………………………..….67 8.5.2.7. Interfaz lista de chequeo de salida de vehículo………………….68 8.5.2.8. Interfaz lista de chequeo de entrega de vehículo…………….….70 8.5.2.9. Interfaz de factura sin novedades…………………………..……72 8.5.2.10. Interfaz de factura con novedades……………………………...73 8.5.2.11. Interfaz de visualización de facturas generadas………………..74 8.5.2.13. Interfaz de visualización de vehículos………………………....74 8.5.2.14. Interfaz de visualización de clientes…………………………...75 8.5.2.15. Interfaz actualización de los datos de clientes………………....75 8.5.2.16. Interfaz de registro de nuevos clientes…………………………76 9. CONCLUSIONES………………………………………………………..77 10. BIBLIOGRAFIA…………………………………………...…………….78 5 INTRODUCCIÓN Este trabajo de pasantía es realizado en la empresa ORION TECHNOLOGIES que se dedica al desarrollo de soluciones en sistemas, esta empresa convoco a estudiantes de último semestre de Ingeniería de Sistemas interesados en realizar su trabajo de grado en la modalidad de pasantía, llevando a cabo el proceso de selección de la persona idónea para realizar el proyecto. Las actividades que se dispusieron fueron bajo la dirección del Ingeniero coordinador del proyecto en la empresa. En este proyecto se diseñó e implemento una aplicación para el manejo de alquiler de vehículos en una empresa de transportes (TRANSPORTES ZAMBRANO) para la empresa ORION TECHNOLOGIES. Este sistema consiste en un software para manejar los procesos de alquiler y mantenimiento de vehículos, haciendo modelado, integración, monitoreo y control de los procesos operativos llevados a cabo por los actores que intervienen en cada una de las capas del negocio. Se Utilizó la metodología basada en los principios de Análisis y diseño orientado a objetos, también la metodología RUP de diseño y desarrollo de software establecido en UML para realizar el análisis de requerimientos, diseñar y elaborar casos de uso, prototipos, para su posterior desarrollo. 6 1. FORMULACIÓN DEL PROBLEMA 1.1. Descripción del Entorno TRANSPORTE ZAMBRANO es una empresa dedicada al servicio de transporte fluvial, terrestre de pasajeros y carga, también se dedica al alquiler de vehículos, con más de 10 años de experiencia prestando sus servicios en la zona del Magdalena medio, siempre ha pensado en la satisfacción de los clientes; teniendo proyectado expandir sus servicios a nivel nacional. Al ser fundada TRANSPORTE ZAMBRANO se propuso dos metas principales ofrecer un excelente servicio y crecer, pero después de diez años el desarrollo y crecimiento no ha sido el planeado, debido a factores que afectan a la mayoría de las empresas de este sector como la competencia, problemas económicos y de orden público del país, etc.; en ese tiempotrabajando la empresa no se había preocupado por al manejo de su información y procesos, los cuales son llevados de forma casi manual y sin ninguna estructura que facilite su registro, control y búsqueda cuando sea requerido. 1.2. Definición del Problema En el momento de comenzar con el proyecto la empresa venía realizando su trabajo de la misma forma que lo hacía cuando fue fundada hace 10 años, es decir llevando toda la información y registros de forma manual, las bases de datos de sus clientes y proveedores estaban registradas en libros lo que impedía llevar un control total de sus operaciones, el control de los alquileres, así como todos los datos que tienen que ver y se desprenden de cada operación realizada. Desde la parte administrativa no se había reconocido la importancia que tiene poder acceder a la información de 7 forma rápida y eficiente, esta imposibilidad que tenía la empresa dificultaba que tuviera una operación eficiente. A pesar de tener una estructura organizativa relativamente simple los procesos administrativos, y operativos que efectúa no lo son, no contaba con ningún sistema de información con el que pudiera hacer un seguimiento continuo de la información que era actualizada constantemente en las áreas administrativas y operativas, lo cual permitía factores de riesgo en la obtención de los objetivos organizacionales. La ausencia de algún sistema le da paso a que se presenten y repitan los problemas que siempre ha tenido la empresa, no poder controlar la gran cantidad de información diversa que se maneja esto genera retardos, mala toma de decisiones y acciones a nivel táctico y operativo, que van en deterioro del cumplimiento de los objetivos que tiene la empresa. 2. JUSTIFICACION 2.1. Justificación Operativa Se justifica la implementación de un software para el manejo del alquiler de vehículos para la empresa Transportes Zambrano el cual permitirá, una vez desarrollado en su totalidad y en óptimo funcionamiento, entre otros beneficios la automatización de la actividad principal de la empresa coordinando las funciones y procedimientos de personas y sistemas, mejora continua en la ejecución de procesos al facilitar el acceso a la información, facilita la cooperación directa y el compromiso conjunto de los empleados en la realización de sus labores. Proporciona una disponibilidad mayor de la información en el momento justo que es requerida alcanzando un control efectivo de las actividades de la empresa, eliminar la dificultad de recopilar la información en lugares distantes, evitado errores pérdidas 8 de tiempo y recursos en los procedimientos que se llevan a cabo además de su mejoramiento continuo. Por tal motivo, es necesario que la empresa, cuente con este sistema, que permite controlar identificar, evaluar y manejar de manera efectiva el proceso de alquiler de vehículos; minimizando los inconvenientes que han impedido su crecimiento. 2.2. Justificación Académica El proyecto recogió las herramientas de conocimiento adquiridas durante el transcurso la carrera, en particular de aquellas áreas relativas al desarrollo de software, métodos, procedimientos, y aquellas que tienen que ver con el diseño y modelado de Software para manejo de procedimientos en arquitectura web de tres capas, procurando una adaptación de esos modelos académicos a las condiciones y particularidades propias del entorno de la empresa. En ese aspecto se ubica también la motivación principal del trabajo en el sentido de entendimiento y responsabilidad que como estudiante participé del proyecto posee frente al objetivo, realizándolo a través de la pasantía como modalidad de trabajo de grado 9 3. OBJETIVOS 3.1. OBJETIVO GENERAL Diseñar desarrollar e implementar una aplicación computacional mediante framework libre y PHP software que permita el manejo y gestión del alquiler de vehículos sobre infraestructuras livianas, minimizando los procesos y procedimientos actuales. 3.2. OBJETIVOS ESPECÍFICOS Realizar el análisis de procesos que se llevan a cabo en Transporte Zambrano. Unificar las actividades del negocio y coordinar las acciones y procedimientos de personas y sistemas en torno al trabajo. Facilitar búsqueda rápida de los datos fundamentales para el desarrollo diario de las actividades del negocio. Aumentar la cooperación directa y el compromiso conjunto de los trabajadores de la empresa en el paso para la optimización de los procesos operativos del negocio. Implementar una solución que facilite el procesamiento de las entradas de información rápidamente, así como la codificación de acuerdo a las necesidades. 10 Aumentar el nivel de rendimiento en todas las operaciones del negocio para garantizar la satisfacción del cliente. 4. ALCANCES Y LIMITACIONES A continuación, se especifican los alcances del proyecto teniendo en cuenta el tiempo, el área que va a ocupar y la formulación del problema. 4.1. ALCANCES Los alcances son: Definir los diagramas de flujo para la empresa. Generar los modelos de análisis y diseño del software para manejar los alquileres de vehículos y el mantenimiento de los mismos en Transportes Zambrano. Diseñar la base de datos para el software de sistema de información Diseñar una interfaz gráfica amigable para los usuarios del software Tomar la información desde las fases de moldeamiento o implementación e introducir cambios de ser necesario en los procesos. 11 4.2. LIMITACIONES Las limitaciones son: Debe contemplarse las implicaciones de los siguientes puntos críticos: La solución será compatible con los equipos de la empresa. La solución debe adaptarse a la normativa de protección de información, seguridad en las trasmisiones de datos, etc. No será un Sistema que permita establecer Normatividad ni Estatutos. No permitirá realizar análisis contable ni financiero de la empresa. El Sistema no se aplicará Directamente a la Gestión de calidad, Aunque permite ajustar los procesos como parámetros de la normatividad ISO 9001. 4.3. PARTICIPANTES EN EL PROYECTO Se incluye el personal que designó empresa Orion Technologies para supervisar el desarrollo de proyecto además de los partícipes directos, revisores, director interno u otros participantes que se estimen convenientes para proporcionar los requisitos y validar el sistema. Director interno: Ingeniero Joaquín Javier Meza docente de la Universidad Distrital acompañamiento durante todo el desarrollo y avance del proyecto 12 Director externo: Ingeniero Hals Rodríguez Santamaría designado por la empresa para supervisar y asesorar en todo el desarrollo del proyecto. Analista de Sistemas. El perfil establecido es: Ingeniero en Informática con conocimientos de UML, labor que llevo a cabo el pasante Yesid Orduz Analistas - Programadores. Con experiencia en el entorno de desarrollo del proyecto, con el fin de que los prototipos puedan ser lo más cercanos posibles al producto final. Este trabajo realizado por el pasante Yesid Orduz. Ingeniero de Software. El perfil establecido es: Alumno que pertenezca al Proyecto Curricular de ingeniería de Sistemas realizando labores de gestión de requisitos, gestión de configuración, documentación y diseño de datos. Labor realizada por le pasante Yesid Orduz. 5. MARCO REFERENCIAL 5.1. Conceptos Relacionados Con El Diseño De La Aplicación 5.1.1. Patrones de Diseño El diseño es un modelo del sistema, realizado con una serie de principios y técnicas, que permite describir el sistema con el suficiente detalle como para ser implementado. Pero los principios y reglas no son suficientes, en el contexto de diseño se puede observar que los diseñadorese ingenieros de software tienen esquemas y estructuras de solución que usan numerosas veces en función del contexto del problema. El patrón es un esquema de solución que se aplica a un tipo de problema, esta aplicación del patrón no es mecánica, sino que requiere de adaptación y matices. Los patrones se clasifican según el propósito para el que han sido definidos: 13 Creacionales: solucionan problemas de creación de instancias. Nos ayudan a encapsular y abstraer dicha creación. Estructurales: solucionan problemas de composición (agregación) de clases y objetos. De Comportamiento: soluciones respecto a la interacción y responsabilidades entre clases y objetos, así como los algoritmos que encapsulan. Según el ámbito se clasifican en patrones de clase y de objeto: Catálogo de patrones de diseño de Gamma et al. (1994) 5.1.2. Ventajas de los patrones La clave para la reutilización es anticiparse a los nuevos requisitos y cambios, de modo que los sistemas evolucionen de forma adecuada. Cada patrón permite que algunos aspectos de la estructura del sistema puedan cambiar independientemente de otros aspectos. Facilitan la reusabilidad, extensibilidad y mantenimiento. Un patrón es un esquema o micro arquitectura que supone una solución a problemas (dominios de aplicación) semejantes (aunque los dominios de problema pueden ser muy diferentes e ir desde una aplicación CAD a un cuadro de mando 14 empresarial). Interesa constatar una vez más la vieja distinción entre dominio del problema (donde aparecen las clases propias del dominio, como cuenta, empleado, coche o beneficiario) y el dominio de la solución o aplicación (donde además aparecen clases como ventana, menú, contenedor o listener). Los patrones son patrones del dominio de la solución. También conviene distinguir entre un patrón y una arquitectura global del sistema. Por decirlo en breve, es la misma distancia que hay entre el diseño de un componente (o módulo) y el análisis del sistema. Es la diferencia que hay entre el aspecto micro y el macro, por ello, en ocasiones se denomina a los patrones como "microarquitecturas".1 En resumen, un patrón es el denominador común, una estructura común que tienen aplicaciones semejantes. Esto también ocurre en otros órdenes de la vida. Por ejemplo, en nuestra vida cotidiana aplicamos a menudo el esquema saludo- presentación-mensaje-despedida en ocasiones diversas, que van desde un intento de ligar hasta dar una conferencia (si todavía no cree que existan patrones o que no son útiles intente ligar con el esquema despedida-mensaje-presentación-saludo, a ver qué ocurre). 5.1.3. Modelo Vista Controlador Para el diseño de aplicaciones con sofisticadas interfaces se utiliza el patrón de diseño Modelo-Vista-Controlador. La lógica de un interfaz de usuario cambia con más frecuencia que los almacenes de datos y la lógica de negocio. Se trata de realizar un diseño que desacople la vista del modelo, con la finalidad de mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor medida en la lógica de negocio o de datos. ___________________________ 1Tomado de: http://inggabrielrodriguezmolinares.blogspot.com.co/2012/03/patrones-de-desarrollo-de- software.html 15 Elementos del patrón: Modelo: datos y reglas de negocio Vista: muestra la información del modelo al usuario Controlador: gestiona las entradas del usuario http://revistatelematica.cujae.edu.cu/index.php/tele/article/viewFile/15/10 Un modelo puede tener diversas vistas, cada una con su correspondiente controlador. Un ejemplo clásico es el de la información de una base de datos, que se puede presentar de diversas formas: diagrama de tarta, de barras, tabular, etc.1 El modelo es el responsable de: o Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento. o Definir 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". o Llevar un registro de las vistas y controladores del sistema. o Si se está ante un modelo activo, notificar a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero ___________________________ 1Tomado de: revistatelematica.cujae.edu.cu/index.php/tele/article/viewFile/15/10 16 batch que actualiza los datos, un temporizador que desencadena una inserción, etc). El controlador es responsable de: o Recibir los eventos de entrada (un clic, un cambio en un campo de texto, etc.). o Contener las 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 ()". Una petición al modelo puede ser "Obtener tiempo de entrega (nueva orden de venta)". Las vistas son responsables de: o Recibir datos del modelo y la muestra al usuario. o Tener un registro de su controlador asociado (normalmente porque además lo instancia). o Poder 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). Un ejemplo de MVC con un modelo pasivo (aquel que no notifica cambios en los datos) es la navegación web, que responde a las entradas del usuario, pero no detecta los cambios en datos del servidor. 17 http://revistatelematica.cujae.edu.cu/index.php/tele/article/viewFile/15/10 Pasos: El usuario introduce el evento. El Controlador recibe el evento y lo traduce en una petición al Modelo (aunque también puede llamar directamente a la vista). El modelo (si es necesario) llama a la vista para su actualización. Para cumplir con la actualización la Vista puede solicitar datos al Modelo. El Controlador recibe el control. 5.1.4. Arquitectura De Tres Capas La programación por capas es una arquitectura cliente-servidor en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, solo se ataca al nivel requerido sin tener que revisar entre código mezclado. Un buen ejemplo de este método de programación sería el modelo de interconexión de sistemas abiertos. https://es.wikipedia.org/wiki/Cliente-servidor https://es.wikipedia.org/wiki/Modelo_de_interconexi%C3%B3n_de_sistemas_abiertos 18 Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que basta con conocer la API que existe entre niveles. En el diseño de sistemas informáticos actual se suelen usar las arquitecturas multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten).1 Capas y niveles 1. Capa de presentación: la que ve el usuario (también se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" (entendible y fácil de usar) para el usuario. Esta capa se comunica únicamente con la capa de negocio.2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación. 3. Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio. ___________________________ 1Tomado de: http://www.academia.edu/10102692/Arquitectura_de_n_capas https://es.wikipedia.org/wiki/Abstracci%C3%B3n_(programaci%C3%B3n_orientada_a_objetos) https://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones https://es.wikipedia.org/wiki/Dise%C3%B1o https://es.wikipedia.org/wiki/Sistema_inform%C3%A1tico https://es.wikipedia.org/wiki/Arquitectura_software https://es.wikipedia.org/wiki/Arquitectura_software https://es.wikipedia.org/wiki/Programa_(computaci%C3%B3n) https://es.wikipedia.org/wiki/Base_de_datos 19 Todas estas capas pueden residir en un único ordenador, si bien lo más usual es que haya una multitud de ordenadores en donde reside la capa de presentación (son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o más ordenadores. Así, si el tamaño o complejidad de la base de datos aumenta, se puede separar en varios ordenadores los cuales recibirán las peticiones del ordenador en que resida la capa de negocio. 5.2. MARCO TEÓRICO Con el fin de alcanzar cada uno de los objetivos propuestos, se plantea una metodología basada en: RUP (Rational Unified Proccess) la cual utiliza UML como lenguaje de Modelado Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo proceso iterativo e incremental), todos los artefactos son objeto de modificaciones a lo largo del proceso de desarrollo, con lo cual, sólo al término del proceso podríamos tener una versión definitiva y completa de cada uno de ellos. 5.2.1. FRAMEWORK La palabra inglesa "framework" (infraestructura, armazón, marco) define, en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar1. En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte ___________________________ 1Tomado de: https://es.wikipedia.org/wiki/Framework https://es.wikipedia.org/wiki/Ordenador https://es.wikipedia.org/wiki/Desarrollo_de_software https://es.wikipedia.org/wiki/Software 20 de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto. Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio, y provee una estructura y una especial metodología de trabajo, la cual extiende o utiliza las aplicaciones del dominio Los frameworks tienen como objetivo principal ofrecer una funcionalidad definida, auto contenida, siendo construidos usando patrones de diseño, y su característica principal es su alta cohesión y bajo acoplamiento. Para acceder a esa funcionalidad, se construyen piezas, objetos, llamados objetos calientes, que vinculan las necesidades del sistema con la funcionalidad que este presta. Esta funcionalidad, está constituida por objetos llamados fríos, que sufren poco o ningún cambio en la vida del framework, permitiendo la portabilidad entre distintos sistemas. Frameworks conocidos que se pueden mencionar por ejemplo son Spring Framework, Hibernate, donde lo esencial para ser denominados frameworks es estar constituidos por objetos casi estáticos con funcionalidad definida a nivel grupo de objetos y no como parte constitutiva de estos, por ejemplo en sus métodos, en cuyo caso se habla de un API o librería. Algunas características notables que se pueden observar: La inversión de control: en un framework, a diferencia de las bibliotecas, el flujo de control no es dictado por el programa que llama, sino por el mismo.21 La funcionalidad o comportamiento predeterminado: un marco tiene un comportamiento predeterminado. Este comportamiento por defecto debe ser un comportamiento útil, definido e identificable. Su extensibilidad: un marco puede ser ampliado para proporcionar una funcionalidad específica. El frame, en general, no se supone que deba ser modificado, excepto en cuanto a extensibilidad. Los usuarios pueden ampliar sus características, pero no deben ni necesitan modificar su código. 5.2.2. Arquitectura https://es.wikipedia.org/wiki/Programa_(computaci%C3%B3n) https://es.wikipedia.org/wiki/Biblioteca_(programaci%C3%B3n) https://es.wikipedia.org/wiki/Lenguaje_interpretado https://es.wikipedia.org/wiki/Arquitectura_de_software https://es.wikipedia.org/wiki/Spring_Framework https://es.wikipedia.org/wiki/Spring_Framework https://es.wikipedia.org/wiki/Hibernate https://es.wikipedia.org/wiki/Inversi%C3%B3n_de_control https://es.wikipedia.org/wiki/Framework#cite_note-framework-2 https://es.wikipedia.org/wiki/Extensibilidad 21 Dentro de este aspecto, podemos basarnos en el modelo–vista–controlador o MVC (Controlador => Modelo => Vista), ya que debemos fragmentar nuestra programación. Tenemos que contemplar estos aspectos básicos en cuanto a la implementación de nuestro sistema: 5.2.2.1. Modelo Este miembro del controlador maneja las operaciones lógicas, y de manejo de información (previamente enviada por su ancestro), para resultar de una forma explicable y sin titubeos. Cada miembro debe ser meticulosamente llamado, con su correcto nombre y en principio, con su verdadera naturaleza: el manejo de información, su complementación directa. 5.2.2.2. Vista Al final, a este miembro de la familia le corresponde dibujar, o expresar la última forma de los datos: la interfaz gráfica que interactúa con el usuario final del programa (GUI). Después de todo, a este miembro le toca evidenciar la información obtenida hasta hacerla llegar al controlador. Solo (e inicialmente), nos espera demostrar la información. 5.2.2.3. Controlador Con este apartado podemos controlar el acceso (incluso todo) a nuestra aplicación, y esto puede incluir: archivos, scripts, y/o programas; cualquier tipo de información que permita la interfaz. Así, podremos diversificar nuestro contenido de forma dinámica, y estática (a la vez); pues, solo debemos controlar ciertos aspectos (como se ha mencionado antes). https://es.wikipedia.org/wiki/Modelo%E2%80%93vista%E2%80%93controlador https://es.wikipedia.org/wiki/Programaci%C3%B3n https://es.wikipedia.org/wiki/Controlador https://es.wikipedia.org/wiki/Interfaz_gr%C3%A1fica_de_usuario https://es.wikipedia.org/wiki/Aplicaci%C3%B3n_inform%C3%A1tica https://es.wikipedia.org/wiki/Archivo_(computaci%C3%B3n) https://es.wikipedia.org/wiki/Guion_(inform%C3%A1tica) https://es.wikipedia.org/wiki/Aplicaci%C3%B3n_inform%C3%A1tica https://es.wikipedia.org/wiki/Interfaz 22 5.2.3. Estructura Dentro del controlador, modelo o vista, se pueden manejar datos,y depende de cada uno cómo interpretar y manejar esos datos. Se sabe que el único dato de una dirección estática web es: conseguir un archivo físico en el disco duro o de Internet, etcétera e interpretado o no, el servidor responde. El modelo, al igual que el controlador y la vista, maneja todos los datos que se relacionen consigo (solo es el proceso medio de la separación por capas que ofrece la arquitectura MVC). Y solo la vista, puede demostrar dicha información. Con lo cual ya se ha generado la jerarquía de nuestro programa: Controlador, Modelo y Vista. 5.2.3.1. Lógica Al parecer, debemos inyectar ciertos objetos dentro de sus parientes en esta aplicación, solo así compartirán herencia y coherencia en su aplicación. Rápidamente, para una aplicación web sencilla debemos establecer estos objetos: Una base (MVC) https://es.wikipedia.org/wiki/Disco_duro https://es.wikipedia.org/wiki/Internet https://es.wikipedia.org/wiki/Servidor https://es.wikipedia.org/wiki/Jerarqu%C3%ADa https://es.wikipedia.org/wiki/Aplicaci%C3%B3n_web https://es.wikipedia.org/wiki/Modelo_Vista_Controlador 23 Controlador: este debe ser capaz de manejar rutas, archivos, clases, métodos y funciones. Modelo: es como un script habitual en el servidor, solo que agrupado bajo un 'modelo' reutilizable. Vista: como incluyendo cualquier archivo en nuestra ejecución, muy simple. Un sistema Ruteador: con él podemos dividir nuestras peticiones sin tantas condicionales. Cargador 5.1.4. FRAMEWORK LARAVEL Para la implementación del sistema se trabajara directamente con Laravel un Framework desarrollado para implementar aplicaciones en PHP. Laravel es un framework de código abierto para desarrollar aplicaciones y servicios web con PHP 5. Su filosofía es desarrollar código PHP de forma elegante y simple, evitando el "código espagueti". Fue creado en 2011 y tiene una gran influencia de frameworks como Ruby on Rails, Sinatra y ASP.NET1 Laravel tiene como objetivo ser un framework que permita el uso de una sintaxis elegante y expresiva para crear código de forma sencilla y permitiendo multitud de funcionalidades. Intenta aprovechar lo mejor de otros frameworks y aprovechar las características de las últimas versiones de PHP.2. Gran parte de Laravel está formado por dependencias, especialmente de Symfony, esto implica que el desarrollo de Laravel dependa también del desarrollo de sus dependencias ___________________________ 1Tomado de: http://cayab.com.mx/laravel-framework-para-php/ 24 5.1.4.1. COMPONENTES DE LARAVEL Lo basico: El framework posee lo que ya imaginamos: Router, Models, Layouts, Views, Controllers, etc. Para los templates utiliza un engine propio que se llama Blade, que tiene algunos helpers copados. Artesano: Cliente de consola que permite ejecutar comandos propios del framework. Es muy versátil, potente e incluso nos permite extenderlo creando nuestras propias tareas para que estén disponibles desde este cliente.1. Compositor: Esto permite modificar y agregar los paquetes que queramos incluso permitiéndonos generar paquetes nuestros, configurarlos en el composer son e incluirlos en nuestra aplicación con un composer update. Tal es el uso y los beneficios de Composer que Laravel utiliza muchos paquetes de otros frameworks como Symfony (Artisan es una extensión de su consola) entre otros.. Migraciones: Lo que incorpora Laravel es la posibilidad de llevar un control de versiones también de nuestra base de datos. Esto, combinado con un sistema de seeding nos permite tener nuestra aplicación descargada y funcionando en unos pocos comandos. Recursos: se incorpora el concepto de resource permitiéndonos programar nuestros controladores como si fueran un API Rest y que sean consumidos de la misma forma. Es decir que para agregar un elemento hacemos un POST /resource, para obtener un listado un GET /resource, para obtener un elemento GET /resource/{id}, etc. Esto nos permite liberar y consumir nuestra aplicación como un API sin tener que modificar nada, y dándonos la posibilidad de integrarla y de que sea integrada por otros sistemas. ORM: Object-Relational Mapping para nuestra base de datos. Nos permite interactuar con nuestra base de datos como si cada tabla fuera un Modelo, respetando más fielmente la división MVC. 25 5.1.4.2. ARQUITECTURA LARAVEL 5.1.4.2.1. CICLO DE VIDA DE UNA SOLICITUD El punto de entrada de todas las peticiones a una aplicación Laravel es el archivo public/index.php. Todas las peticiones son dirigidas a este archivo por la configuración del servidor web (Apache / Nginx). El archivo index.php no contiene mucho código. Más bien, es un simple punto de entrada para cargar el resto del framework.1 El archivo index.php carga la definición del autoloader generado por Composer y luego retorna una instancia de la aplicación de Laravel desde el script bootstrap/app.php. HTTP / Console Kernels A continuación, la petición de entrada es enviada al núcleo HTTP o bien al núcleo de consola, dependiendo del tipo que sea dicha petición de entrada a la aplicación. Estos dos núcleos son el lugar central por el pasan todas las peticiones. El núcleo HTTP extiende de la clase Illuminate\Foundation\Http\Kernel, que define un array de configuraciones de arranque que serán lanzadas antes de que la petición sea ejecutada. Service Providers Los service providers son la clave del arranque de una aplicación Laravel. Se crea una instancia de la aplicación, se registran los service providers y se interpreta la solicitud con la aplicación ya arrancada. De forma predeterminada, el AppServiceProvider está casi vacío. Este provider es un buen lugar para añadir los elementos de arranque de la aplicación e incluso ___________________________ 1Tomado de: http://laraveles.com/docs/5.0/lifecycle 26 bindings del service container. Por supuesto, para aplicaciones grandes, puedes crear varios service providers más específicos. 5.1.4.2.2. ESTRUCTURA DE LA APLICACIÓN La estructura por defecto de la aplicación Laravel está destinada a proporcionar un buen punto de partida tanto para aplicaciones grandes como para aplicaciones pequeñas. Aun así, se puede de organizar la aplicación. Laravel no impone casi ninguna restricción respecto a donde se encuentra una clase en el proyecto, siempre y cuando Composer sea consciente de ella para poder cargarla al arrancar de la aplicación. El directorio raíz El directorio raíz de una nueva instalación nueva de Laravel contiene una serie de directorios: El directorio app, contiene el código base de tu aplicación. La directorio bootstrap contiene unos archivos que arrancar el marco de trabajo y configuran carga automática, así como una carpeta de caché que contiene algunos archivos de marco para la optimización del rendimiento de arranque genera. El directorio config, como su nombre indica, contiene todos los archivos de configuración de tu aplicación. El directorio resources contiene sus puntos de vista , los activos brutos ( LESS, SASS , CoffeeScript ) , y los archivos de localización . El directorio storage contiene plantillas compiladas de Blade, sesiones basadas en archivos, archivos de caché y otros archivos generados por el framework. 27 El directorio tests contiene pruebas de sus pruebas automatizadas. Un ejemplo es el de PHPUnit fuera de la caja. El directorio vendor contiene sus dependencias del compositor. El directorio de la aplicación El directorio app viene con una variedad de directorios adicionales, tales como Console, Http, y Providers. Piensa en los directoriosConsole y Http como proveedores de un API al "core" de la aplicación. El protocolo HTTP y CLI son mecanismos (pasarelas) para interactuar con tu aplicación, pero en realidad no contienen lógica de la aplicación.El directorio Console contiene todos tus comandos de Artisan, mientras el directorio Http contiene tus controladores, filtros y peticiones. 5.1.4.2.3. SERVICE PROVIDERS (PROVEEDORES DE SERVICIO) Los proveedores de servicios son el centro de toda la configuración de arranque de Laravel. Tu propia aplicación, al igual que todos los servicios del núcleo de Laravel, también tiene su configuración de arranque mediante proveedores de servicios. Writing Service Providers Todos los proveedores de servicios extienden de la clase Illuminate\Support\ServiceProvider. Esta clase abstracta requiere que al menos definas el método register en tu proveedor. Dentro del método register, sólo se debe obligar a las cosas en el contenedor de servicios Registrar proveedores Todos los proveedores están registrados en el archivo de configuración config/app.php. Este archivo contiene un array de proveedores del 28 cual puedes obtener un listado de nombres de tus proveedores de servicios. Por defecto, este array también incluye un conjunto de proveedores de servicios del núcleo de Laravel. Estos proveedores inicializan los componentes del núcleo de Laravel, tales como el proveedor de correos, colas, caché y otros. Proveedores diferidos Laravel compila y almacena una lista de todos los servicios ofrecidos por proveedores de servicios diferidos, junto al nombre de su clase proveedora del servicio. Entonces, sólo cuando se intenta resolver alguno de estos servicios, Laravel carga el proveedor de servicio. 5.1.4.2.4. SERVICE CONTAINER El contenedor de servicios laravel es una poderosa herramienta para la gestión de las dependencias de la clase y la realización de la inyección de dependencia. La inyección de dependencia es una frase de fantasía que en esencia significa esto: dependencias de clase se " inyecta" en la clase a través del constructor o , en algunos casos , los métodos de "ajuste " . Binding (enlazar) Casi todos los enlaces de container de servicio se registrarán dentro de los proveedores de servicios; Sin embargo, no hay necesidad de obligar a las clases en el recipiente si no dependen de ninguna interfaces. El contenedor no necesita ser instruido cómo construir estos objetos, ya que se puede resolver de forma automática este tipo de objetos "concretas" que utilizan los servicios de reflexión de PHP. Binding A Singleton http://laraveles.com/docs/5.1/providers http://laraveles.com/docs/5.1/providers 29 El método Singleton se une a una clase o interfaz en el container que sólo debe ser resuelto de una vez, y luego esa misma instancia será devuelto en llamadas posteriores en el container Binding Instances Podrías enlazar una instancia de un objeto existente al container utilizando el método instance. Se retornará esa misma instancia en llamadas posteriores al container Enlazando (binding) interfaces a implementaciones Una de las características del service container es su capacidad para enlazar una interfaz a una implementación determinada. Binding contextual En ocasiones puedes tener dos clases que utilizan la misma interfaz, pero quieres inyectar implementaciones diferentes a cada clase. Por ejemplo, cuando nuestro sistema recibe un nuevo Pedido, podemos querer lanzar un evento vía PubNub en lugar de Pusher. Laravel provee una simple y fluida interfaz para definir este comportamiento 5.1.4.2.5. CONTRATOS (CONTRACTS) Los Contracts de Laravel son un conjunto de interfaces que definen los principales servicios proporcionados por el framework. Por ejemplo, a Illuminate\Contracts\Queue\ define los métodos necesarios para poner en cola trabajos, mientras que Illuminate\Contracts\Mail\Mailer contract define los métodos necesarios para el envío de correo electrónico. Cada Contract tiene una implementación correspondiente proporcionada por el framework. Por ejemplo, laravel proporciona una implementación de cola con una http://www.pubnub.com/ 30 variedad de conductores, y una implementación de cliente de correo que es alimentado por SwiftMailer . Todos los Contract de Laravel se encuentran en su propio repositorio de GitHub. Esto proporciona un punto de referencia rápida para todos los contratos disponibles, así como un paquete único, disociada que pueden ser utilizados por los desarrolladores de paquetes. 5.1.4.2.6. FACADE Fachadas proporcionan una interfaz de "estática" a las clases que están disponibles en la aplicación del contenedor de servicios . Laravel incluye muchas fachadas, las "fachadas" de laravel sirven Como un "Proxy estático" para clases subyacentes en el contenedor de servicios, proporcionando el beneficio de una sintaxis concisa y expresiva, Manteniendo mayor estabilidad y flexibilidad que los métodos tradicionales estáticos. En el contexto de una aplicación Laravel, una facade es una clase que provee acceso a un objecto desde el contenedor. El mecanismo que hace que esto funcione es la clase Facade. fachadas de laravel , y cualquier fachadas personalizadas que cree , se extenderán a la clase 5.1.5. CARACTERÍSTICAS DE LARAVEL Modularidad: Laravel se ha construido utilizando más de 20 librerías diferentes fuertemente integradas con el gestor de dependencias Composer Testeabilidad: construido para facilitar el testeo, Laravel tiene con varios asistentes (helpers) que ayudan a visitar las rutas de testeo, navegando por el HTML resultante para asegurar que los métodos que se llaman desde las diferentes clases sean correctos, e incluso a impersonar a los usuarios. https://github.com/illuminate/contracts http://laraveles.com/docs/5.1/container 31 Enrutamiento (routing): Laravel proporciona una extrema flexibilidad en la definición de las rutas de la aplicación. Inspirado en la filosofía de los micro- frameworks Sinatra y Silex. Todavía más, es posible adjuntar funciones de filtro que se ejecuten en rutas específicas. Gestor de configuración: frecuentemente la aplicación se ejecutará en diferentes entornos, esto quiere decir que tanto la base de datos como credenciales o dominios serán diferentes si se ejecutan el local en el entorno de test o en los servidores de producción. Laravel nos permite definir configuraciones separadas para cada uno de los entornos. Confeccionador de consultas y ORM (Object Relational Mapper): cuando se instala Laravel viene con un constructor de consultas, este nos permite lanzar consultas a la base de datos con una sintaxis PHP de métodos enlazados, en lugar de tener que escribir la SQL completa. Además proporciona un ORM y una implementación de Registro Activo (ActiveRecord) llamado Eloquent, que permite definir modelos interconectados. Estos componentes son compatibles con bases de datos tales como PostgreSQL, SQLite, MySql, MS SQL Server. Confeccionador esquema, migraciones y repoblaciones: inspirado por la filosofía Rails, estas características permiten definir un esquema de base de datos dentro de PHP y mantener un registro de los cambios para así ayudar en la migración de base de datos. Las repoblaciones (Seeding) permiten poblar las tablas seleccionadas de una base de datos una vez realizada la migración para de esta forma rellenar con datos las tablas.1 Motor de plantillas: Laravel viene con Blade, un lenguaje ligero de plantillas con el cual se pueden crear diseños anidados con bloques predefinidos en el que el contenido se inserta dinámicamente. Además Blade guarda en caché los archivos generados. Email: con la clase Mail que es un derivado de la librería SwiftMailer, Laravel proporciona una forma muy sencilla de enviar e-mails, con contenido HTML y adjuntos. ___________________________ 1Tomado de: http://www.bcnbit.com/laravel-4-resumen-para-principiantes-parte-i/ 32 Autenticación: Laravel viene con las herramientas para crear en toda web un formulario de registro,autenticación e incluso envio de contraseñas a usuarios que no la recuerden. Redis: es un sistema de almacenamiento clave-valor en memoria que tiene fama de ser extremadamente rápido. Colas: Laravel se integra con diversos servicios de colas, tales como Amazon SQS o IronMQ, para permitir el aplazamiento de tareas que son muy intensivas en recursos, así por ejemplo podemos enviar una gran cantidad de e-mails ejecutando esta tarea en segundo plano en lugar de hacer que el usuario espere delante de la pantalla. 6. DISEÑO METODOLOGICO 6.1. Conocimiento Global De La Empresa 6.1.1. Reseña Histórica Fundada en el año 2004, Transportes Zambrano con más de 10 años de combinada experiencia de nivel profesional para transportar carga y pasajeros y en los últimos 5 años también con el alquiler de vehículos prestando un servicio bueno a sus clientes. La empresa ofrece los servicios de un equipo de conductores y mecánicos expertos, además de los funcionarios administrativos personas con experiencia y compromiso de ofrecer el mejor servicio a sus clientes. Desde su creación la empresa ha venido mejorando poco a poco sus procesos y servicios, cuenta entre sus clientes a empresas de varios sectores que avalan su calidad y cumplimiento. Aplican sus conocimientos para ofrecer un servicio que responde a necesidades específicas. Además de especializarse en los sectores empresariales ya que está avalada por el ministerio de transporte. Estructura organizativa 33 Tomado organigrama Transportes Zambrano 6.1.2. Objetivos de la Organización Objetivos de TRANSPORTES ZAMBRANO Cumplir las responsabilidades individuales para fortalecer la imagen institucional. Desarrollar con efectividad las tareas encomendadas Emprender actuaciones bajo criterios de discerniendo ético en la gestión institucional Se entregan resultados de calidad en base a la planificación institucional Desarrollar con efectividad las tareas encomendadas Demostrar vocación de servicio y sentido de pertenencia frente a la entidad, ejerciendo el liderazgo necesario para dar cumplimiento a los objetivos de la organización, respetando el medio ambiente. Aplicar la cultura de calidad en el servicio, ofreciendo una amplia cobertura, que permita responder efectivamente frente a las exigencias del mercado de un mundo globalizado. Gerente Subgerente cordinador mantenimiento cordinador alquiler cordinador de transporte conductores Tesoreria Contaduria Secretaria 34 Cooperación permanente y continua en el desarrollo en los procesos de la organización y en las relaciones interpersonales con los clientes y usuarios. 6.1.3. Definición de la Actividad de la Empresa TRANSPORTES ZAMBRANO es una empresa dedicada al transporte de mercancías y personas, se dedica a ofrecer a sus clientes los servicios de transporte de pasajeros, carga y alquiler de vehículos de acuerdo con las necesidades específicas de cada uno de ellos, también tiene proyectado ampliar más su parque automotor para ofrecer un mejor servicio. Su actividad principal es el transporte de personas, de ahí se desprenden otras actividades relacionadas como el transporte de mercancía y el alquiler de vehículos. 6.1.4. Misión TRANSPORTE FLUVIAL ZAMBRANO & H S.A.S, es una empresa de Transporte Fluvial y Terrestre de personal, que cuenta con un equipo humano de óptima calidad que trabaja siempre pensando en la satisfacción de nuestros clientes, ofrecemos los mejores servicios buscando siempre la excelencia para llegar a un nivel de servicio que nos permite alcanzar un desarrollo integral como persona y como empresa. Participamos activamente en el desarrollo socio-económico de la región, convirtiéndonos en aliados estratégicos de nuestros clientes, proporcionando soluciones a medida de sus necesidades. Así garantizamos un desempeño industrial y comercial exitoso en medio de una competencia cada vez más fuerte. 35 6.1.5. Evaluación de la Misión Clientes “…trabaja siempre pensando en la satisfacción de nuestros clientes” – puede ser cualquier cliente no limite su población objetivo Producto o servicio “…proporcionando soluciones a medida de sus necesidades” – Soluciones tecnológicas de acuerdo al negocio del cliente Mercado Cualquier empresa o persona que quiera una solución tecnológica para su negocio. Tecnología No aplica Interés por la supervivencia, crecimiento y rentabilidad “…buscando siempre la excelencia para llegar a un nivel de servicio que nos permite alcanzar un desarrollo integral como persona y como empresa.” se evidencia el interés de sobrevivir al mercado cambiante y globalizado, también el interés por crecer teniendo rentabilidad. Filosofía “…ofrecemos los mejores servicios buscando siempre la excelencia” – Apoyar a sus clientes a la consecución de los objetivos de negocio propios ofreciendo calidad en el servicio. Concepto de sí misma No Aplica Interés por la imagen pública “Participamos activamente en el desarrollo socio-económico de la región, convirtiéndonos en aliados estratégicos de nuestros clientes” – Preocupación por la región donde trabaja y la imagen ante sus clientes Interés por el empleado No Aplica 6.1.6. Matriz DOFA Esta sección tiene como objetivo conocer cuáles son las fortalezas y debilidades dentro de la empresa, identificar que amenazas y oportunidades que presentan en su contexto. Con esto obtendremos una claridad de las necesidades actuales en la empresa 36 Herramientas utilizadas desactualizadas Amplia experiencia en el sector Demoras en la atención Cumplimiento de las necesidades del cliente Falta de seguimiento a los procesos Personal idóneo Reconocimiento de los clientes Oportunidades Debilidades Fortalezas Conocer mucho más los requerimientos del cliente * Incentivar la generación de evaluación de desempeño por parte del cliente y documentar los resultados * Hacer seguimiento de procesos en todos los niveles Estar actualizados con las herramientas usadas * Identificar futuros requerimientos del cliente con anterioridad para realizar propuestas de innovación Hacer seguimiento de cada cliente mediante herramientas actualizadas Aprovechar las herramientas tecnologías Crecimiento de la población y empresas en el sector Atención personalizada al cliente Amenazas Evaluación de desempeño por parte del cliente * Hacer seguimiento de procesos para evitar demoras * Provocar participación activa en los espacios de socialización y capacitación de los empleados en la retroalimentación de la empresa donde se propongan ideas de mejora * generar estrategias de comercialización para competir en el mercado * tener en cuenta con anterioridad los cambios en el mercado Hacer evaluación y proyección de costos con más anterioridad Costo de la gasolina Competencia de nuevas empresas grandes y pequeñas Situación de orden público de la zona 7. DESARROLLO DE SOFTWARE 7.1. FASES DEL PROYECTO A continuación se indican y describen cada uno de las fases a seguir en el proyecto. Esta lista constituye la configuración de RUP desde la perspectiva de artefactos, y que utilizaremos para este proyecto. 37 Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo proceso iterativo e incremental), todos los artefactos1 son objeto de modificaciones a lo largo del proceso de desarrollo, con lo cual, sólo al término del proceso podríamos tener una versión definitiva y completa de cada uno de ellos. 7.1.1. Fase de Inicio En esta fase se desarrolló el Análisis de requerimientos: se estudian los requisitos del sistema y se desarrollan, detallando los casos generales y los especiales, los cuales se evaluarán dentrode la oficina de Orion Technologies para posibles ajustes. Esta etapa contempla, por supuesto, Casos de uso del Sistema, Secuencias y Colaboraciones, se hizo un refinamiento del Plan de Desarrollo del Proyecto, la aceptación del cliente / usuario del artefacto Visión y el Plan de Desarrollo marcaron el final de esta fase. 7.1.2. Modelado del Sistema El modelado del negocio se basa en los diagramas principales de modelo de casos de uso del negocio para cada cliente del Sistema. La empresa interactúa con distintos elementos externos, entre los que se identifican el Cliente (persona entidad encargada de hacer los pedidos), el vendedor (persona encargada de las ventas), el proveedor (persona o entidad que provee los insumos) y el técnico (se encarga de ensamblar y reparar equipos). 7.1.3. Escenarios Gerente 1 Se define como artefacto un producto de una iteración en el ciclo de desarrollo en la metodología RUP: desde un código software hasta documentos técnicos. 38 Cliente Secretaria Agregar vehículo 39 Coordinador Coordinador mantenimiento Conductor de mantenimiento Mecánico Supervisor Taller 40 7.1.4. Fase de Elaboración En esta fase se analizan los requisitos y se desarrolla un prototipo de arquitectura (incluyendo las partes más relevantes y / o críticas del sistema). Al final de esta fase, todos los casos de uso correspondientes a requisitos que serán implementados en la primera versión de la fase de Construcción deben estar analizados y diseñados (en el Modelo de Análisis / Diseño). La revisión y aceptación del prototipo de la arquitectura del sistema marca el final de esta fase.. 7.1.4.1. Actores Del Sistema Un actor es una persona, sistema o dispositivo que interactúa con el sistema, iniciando, recibiendo los resultados o participando en algunas de las acciones de un caso de uso. Por lo general representa un rol. Los actores utilizados para las especificaciones definidas a partir de los siguientes numerales son: PERFIL 1 Gerente Descripción Persona previamente seleccionada, encargada de: Ingresar nuevos conductores al sistema Agregar nuevo vehículo al stock Consultar las facturas de arreglos de vehículos. Hacer consultas de información variada. Gerencia de la empresa Comentarios Ninguno 41 Actor perfil 1 Actor perfil 2 Actor perfil 3 PERFIL 2 Secretaria Descripción Persona previamente seleccionada, encargada de: Ingresar solicitud de alquiler Recibir solicitudes de alquiler. Elaborar la facturas de venta Responder emails. Atender solicitudes de los clientes Consultar información l acerca de los insumos en el inventario Ingresar clientes nuevos Comentarios Ninguno PERFIL 3 Cliente Descripción Persona, encargada de: Solicitar productos al vendedor Hacer el pago de sus pedidos. Comentarios Ninguno PERFIL 3 Coordinador Descripción Persona previamente seleccionada, encargada de: Coordinar las labores de su área Entregar vehículos Recibir vehículos Comentarios Ninguno PERFIL 3 Mecánico 42 7.1.4.2. Especificaciones De Casos De Uso Las especificaciones de casos de uso están divididas según el subsistema al que pertenezcan: UC-01 Solicitar alquiler Descripción El sistema recibe el requerimiento del alquiler por parte del cliente. Precondición ninguna. Secuencia Normal Paso Acción 1 El cliente hace la solicitud del alquiler. 2 El cliente del sistema entra a la opción de menú: crear nueva solicitud de alquiler 3 El cliente entra toda la información correspondiente a la solicitud. Descripción Persona o entidad, previamente seleccionada encargada de: Reparar vehículos Prevenir daños Registrar daños Registrar reparación Responder por garantías. Dar asesorías técnicas Comentarios Ninguno PERFIL 3 Supervisor taller Descripción Persona o entidad, previamente seleccionada encargada de: Supervisar ingreso de vehículos Supervisar salida de vehículos Agregar empresas Comentarios Ninguno 43 4 Termina el proceso de mostrarle al cliente la Creación exitosa de la solicitud. Pos condición El sistema queda listo para ingresar nueva solicitud Excepciones paso Acción 4 El vehículo no está disponible. 3 En caso de que falte información al ingreso del, el Sistema informará al Cliente que falta ingresar un Campo. Rendimiento Paso Tiempo 4 30 segundos Comentarios ninguna UC-02 Consultar solicitud de alquiler Descripción El sistema la consulta. Precondición El solicitante es un Actor PERFIL1 el cual esta previamente validado en el sistema. Secuencia Normal Paso Acción 1 El sistema verifica el Perfil del Solicitante. 2 El usuario del sistema entra a la opción de menú: consultar 3 Termina el proceso de mostrarle al usuario la información Pos condición El sistema queda listo para ingresar nueva búsqueda Excepciones paso Acción 3 Información no disponible. Rendimiento Paso Corta De Tiempo 4 2 segundos Comentarios ninguna UC-03 Agendar vehículo Descripción El sistema agenda un vehículo Precondición Solicitud de alquiler Secuencia Normal Paso Acción 1 El usuario del sistema ingresa al módulo de agenda vehículo . 2 El usuario del sistema entra a la opción de menú: crear nueva solicitud de alquiler 3 El sistema muestra al usuario la Creación exitosa. Pos condición El sistema queda listo para ingresar nueva solicitud Excepciones paso Acción 1 Solicitud previa de alquiler Rendimiento Paso Tiempo 4 30 segundos Comentarios ninguna 44 UC-04 Facturar servicio Descripción El sistema realiza la factura por el pago de un servicio. Precondición Solicitud de alquiler. Secuencia Normal Paso Acción 1 El usuario del sistema ingresa al módulo de facturación. 2 El usuario del sistema ingresa los datos solicitados 3 Termina el proceso de mostrarle al usuario la Creación exitosa de la factura. Pos condición El sistema queda listo para ingresar nueva solicitud Excepciones paso Acción 1 Solicitud de alquiler. Rendimiento Paso Tiempo 4 30 segundos Comentarios ninguna UC-05 Lista de chequeo recepción de vehículo Descripción El usuario ingresa el estado de un vehículo que llega. Precondición ninguna Secuencia Normal Paso Acción 1 El usuario del sistema ingresa al módulo de ingresar vehículo . 2 El usuario del sistema ingresa los datos solicitados del vehículo 3 Termina el proceso de mostrarle al usuario el ingreso exitoso del vehículo. Pos condición El sistema queda listo para ingresar nueva solicitud Excepciones paso Acción 1 Vehículo no registrado . Rendimiento Paso Tiempo 4 15 minutos Comentarios ninguna UC-06 Consultar daños de vehículo Descripción El usuario consulta los daños registrados de un vehículo Precondición El Vehículo debe haber ingresado previamente Paso Acción 45 Secuencia Normal 1 El usuario del sistema ingresa al módulo de buscar vehículo . 2 El usuario del sistema ingresa los datos solicitados del vehículo 3 Termina el proceso de mostrarle al usuario la información correspondiente al vehículo buscado. Pos condición El sistema queda listo para ingresar nueva solicitud Excepciones paso Acción 1 Vehículo no registrado . Rendimiento Paso Tiempo 4 15 segundos Comentarios ninguna UC-07 Registrar daños de vehículo Descripción El usuario ingresa los daños de un vehículo Precondición El Vehículo debe haber ingresado previamente Secuencia Normal Paso Acción 1 El usuario del sistema ingresa al módulo de buscar vehículo . 2 El usuario del sistema ingresa los datossolicitados del vehículo 3 Termina el proceso con el registro de la información correspondiente al vehículo buscado. Pos condición El sistema queda listo para ingresar nueva solicitud Excepciones paso Acción 1 Vehículo no registrado . Rendimiento Paso Tiempo 4 15 segundos Comentarios ninguna 8. MODELOS DE ANALISIS Y DISEÑO A continuación se presentan los modelos definidos en RUP como modelo de datos y modelo de análisis / diseño. Constará de un diagrama de clases en el que se muestran tan sólo las clases generadas a partir de los casos de uso incorporados a la aplicación hasta la segunda iteración de la fase de construcción, y de un modelo de datos (modelo relacional) donde se muestran las entidades que participan en las relaciones definidas en él. 46 8.1. Clases conceptuales Diagrama de Clases Modelo de dominio En este modelo de clases podemos ver los objetos del dominio del problema, o sea objetos que tienen una equivalentes al área de la aplicación. Así es como el usuario debe identificar los todos los conceptos, las relaciones entre todas las entidades comprendidas en el ámbito del dominio del problema, y podemos identificar los atributos. Es importante aclarar que aquí no se trata de un conjunto que corresponden a clases software, u objetos software con compromisos. Diagrama realizado con ArgoUML 47 8.2. Modelo Entidad – Relación 48 8.2.1. Diccionario de datos Alquiler Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idalquiler INT(11) ✔ ✔ ✔ fechainicio DATETIME ✔ fechafin DATETIME ✔ costo FLOAT ✔ estado TINYINT(4) ✔ clientes_idclientes INT(11) ✔ Aseguradora Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idaseguradora INT(11) ✔ ✔ ✔ aseguradora VARCHAR(45) NULL Checklist Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default vehiculos_alquiler_idv ehiculosalquiler INT ✔ item_checklist_iditem INT ✔ calificacion TINYINT fecha_calificacion DATETIME idchk INT ✔ ✔ observacion VARCHAR(45) 49 Clientes Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idclientes INT(11) ✔ ✔ ✔ nombres VARCHAR(45) ✔ apellidos VARCHAR(45) ✔ documento INT(11) ✔ telefono VARCHAR(45) ✔ correo VARCHAR(45) NULL cargo VARCHAR(45) ✔ empresas_idempresa INT(11) ✔ usuarios_Idusuario INT(11) ✔ detalle_mantenimiento Column name DataType Primary Key Not Null Uniqu e Index Binary Column Unsigned Data Auto Incremental Default iddetallemantenimiento INT(11) ✔ ✔ ✔ costo INT(11) ✔ Id_mecanico INT(11) ✔ mantenimiento_idmante nimiento INT(11) ✔ mecanicos_idmecanico INT(11) ✔ tipo_mantenimiento_idti po_mantenimiento INT ✔ detalle_partes Column name DataType Primar y Key Not Null Uniqu e Index Binary Colum n Unsigne d Data Auto Incremental Default detalle_mantenimiento_i ddetallemantenimiento INT(11) ✔ ✔ partes_vehiculo_idPartes _Vehiculo INT(11) ✔ ✔ observacion TEXT ✔ imagen_antes VARCHAR(100) correctivo VARCHAR(100) imagen_despues VARCHAR(100) 50 empleados Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idempleado INT(11) ✔ ✔ ✔ nombres VARCHAR(45) ✔ apellidos VARCHAR(45) ✔ documento INT(11) ✔ telefono INT(11) ✔ fecha_nacimiento DATE ✔ correo VARCHAR(45) ✔ licencia VARCHAR(45) ✔ contacto_emergencia VARCHAR(45) ✔ Estado_civil_idEstado_civil INT(11) ✔ tiposangre INT(11) ✔ tipolicencia VARCHAR(4) ✔ eps_ideps INT(11) ✔ empresas Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idempresa INT(11) ✔ ✔ ✔ razonsocial VARCHAR(45) ✔ NIT VARCHAR(45) ✔ representante VARCHAR(45) ✔ telefono VARCHAR(45) ✔ correo VARCHAR(45) ✔ eps Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default ideps INT(11) ✔ ✔ ✔ eps VARCHAR(45) ✔ especialidad Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default 51 idEspecialidad INT(11) ✔ ✔ ✔ Especialidad VARCHAR(45) NULL estado Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idestado INT(11) ✔ ✔ ✔ estado VARCHAR(45) ✔ mantenimiento Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idmantenimiento INT(11) ✔ ✔ ✔ Fecha_ingreso DATE ✔ Fecha_entrega DATE ✔ vehiculos_idvehiculo INT(11) ✔ taller_idtaller INT(11) ✔ estado INT seguros Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idSeguros INT(11) ✔ ✔ ✔ Fecha_expedicion DATETIME ✔ Fecha_caducidad DATETIME ✔ Radicado VARCHAR(45) ✔ aseguradora_idaseguradora INT(11) ✔ tipo_seguro_idtipo_seguro INT(11) ✔ vehiculos_idvehiculo INT(11) ✔ marca Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idmarca INT(11) ✔ ✔ ✔ marca VARCHAR(45) ✔ mecanicos 52 Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idmecanico INT(11) ✔ ✔ ✔ nombre VARCHAR(45) ✔ apellido VARCHAR(45) NULL migrations Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default migration VARCHAR(255) ✔ batch INT(11) ✔ municipio Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idmunicipio INT(11) ✔ ✔ ✔ municipio VARCHAR(45) ✔ partes_vehiculo Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idpartes_vehiculo INT(11) ✔ ✔ ✔ nombre_parte VARCHAR(60) ✔ periodicidad_mantenimiento INT rol Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idrol INT(11) ✔ ✔ ✔ rol VARCHAR(45) ✔ sobrecosto Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default vehiculos_alquiler_idvehiculosalquiler INT ✔ ✔ monto INT ✔ tipo_sobrecosto_idtipo_sobrecosto INT ✔ ✔ solicitud Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idsolicitud INT(11) ✔ ✔ ✔ fechainicio DATE ✔fechafinal DATE ✔ 53 alquiler_idalquiler INT(11) ✔ tiene_conductor TINYINT ✔ modoentrega TINYINT ✔ modorecepcion TINYINT ✔ taller Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idtaller INT(11) ✔ ✔ ✔ nombre VARCHAR(45) NULL telefono VARCHAR(45) ✔ direccion VARCHAR(45) ✔ NIT VARCHAR(45) ✔ representantelegal VARCHAR(45) ✔ especialidad_idEspecialidad INT(11) ✔ municipio_idmunicipio INT(11) ✔ tipo_seguro Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idtipo_seguro INT(11) ✔ ✔ ✔ tipo_seguro VARCHAR(45) NULL tipo_sobrecosto Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idtipo_sobrecosto INT ✔ ✔ tipo_sobrecostocol VARCHAR(45) ✔ tipovehiculo Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idtipo INT(11) ✔ ✔ ✔ tipovehiculo VARCHAR(45) NULL 54 tipovehiculo_por_solicitud Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default tipovehiculo_idtipo INT(11) ✔ ✔ solicitud_idsolicitud INT(11) ✔ ✔ numero VARCHAR(45) ✔ usuarios Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default Idusuario INT(11) ✔ ✔ ✔ username VARCHAR(32) ✔ password VARCHAR(64) ✔ email VARCHAR(320) ✔ rol_idrol INT(11) ✔ vehiculos Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default idvehiculo INT(11) ✔ ✔ ✔ matricula VARCHAR(45) ✔ modelo VARCHAR(45) ✔ capacidad VARCHAR(45) ✔ cilindraje VARCHAR(45) ✔ chasis VARCHAR(45) ✔ costocomercial VARCHAR(9) ✔ imagen VARCHAR(45) ✔ tipo_vehiculo_idtipo INT(11) ✔ marca_idmarca INT(11) ✔ color_idcolor INT(11) ✔ consumo VARCHAR(45) vehiculos_alquiler Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default 55 vehiculos_idvehiculo INT(11) alquiler_idalquiler INT(11) ✔ modoentrega TINYINT modorecepcion TINYINT empleados_idempleado INT(11) tiene_conductor TINYINT ✔ kilometrajeinicial FLOAT ✔ kilometrajefinal FLOAT idvehiculosalquiler INT ✔ ✔ ✔ vehiculos_estado Column name DataType Primary Key Not Null Unique Index Binary Column Unsigned Data Auto Incremental Default vehiculos_idvehiculo INT(11) ✔ estado_idestado INT(11) ✔ fecha DATE ✔ idve VARCHAR(45) ✔ ✔ 56 8.3. Modelo de despliegue Este es un diagrama estructurado que muestra la arquitectura del sistema desde el punto de vista de la distribución de los artefactos del software en los destinos de despliegue. El diagrama muestra la configuración de nodos de procesamiento en tiempo de ejecución y las instancias de componentes y objetos que se encuentran dentro de esos nodos. Los componentes representan manifestaciones de ejecución de unidades de código. Diagrama realizado con ArgoUML 57 8.4. Modelo vista controlador Ese modelo se compone de tres componentes que son: el modelo, la vista y el controlador, es decir, por un lado define elementos para la representación de la información, y por otro lado para la interacción del usuario, esto permite separar los componentes del software dependieno de su trabajo que realizan. El Modelo: En esta capa se trabaja con los datos, y contiene las peticiones para acceder y actualizar el estado de la información. Los datos están guardados en la base de datos, entonces en esta capa tendremos todas las funciones que accederán a las tablas y realizan las ordenes selects, updates, inserts, etc. La Vista: es la representacion visual de los datos, interpreta el codigo de la aplicación en las interfaces de usuario En la vista generalmente trabajamos con los datos, sin embargo, no se realiza un acceso directo a éstos. Las vistas requerirán los datos a los modelos y ellas se creará la salida, tal como la aplicación requiera. El Controlador: Esta es la capa que sirve de conexión entre las vistas y los modelos, respondiendo a los eventos que puedan solicitarse para generar las necesidades de nuestra aplicación. Desde esta capa no se manipulan directamente datos, ni se muestra ningún tipo de salida, sino lo que hace es servir de enlace entre los modelos y las vistas para implementar las diversas necesidades del desarrollo. 58 Diagrama realizado con ArgoUML 8.5. Fase de construcción Durante la fase de construcción se terminan de analizar y diseñar todos los casos de uso, refinando el Modelo de Análisis / Diseño. Se codifica el sistema detallado previamente, en base al análisis y diseño realizado en las fases anteriores, esta etapa es la más importante ya que se creará la base de datos y se desarrollarán los diferentes módulos para el Sistema, el producto se construye en base a 2 iteraciones, cada una produciendo una versión a la cual se le aplican las pruebas y se valida con el cliente / usuario. Se comienza la elaboración de material de apoyo al usuario. 59 8.5.1. Interfaces A continuación se presentan los prototipos de las interfaces gráficas de usuario diseñadas para demostrar la funcionalidad de la aplicación. Cabe Citar que se presentan únicamente los prototipos de interfaces de usuario al cliente además incluyen funcionalidades de una futura segunda fase de construcción del sistema. Los modelos y diseños de las interfaces prototipo y finales son propiedad de la empresa ORION TECNOLOGIES. 8.5.1.1. Interfaz de ingreso de usuarios al sistema 60 8.5.1.2. Interfaz gestionar conductor 8.5.1.3. Interfaz gestionar vehículo 61 8.5.1.4. Interfaz ver facturas 8.5.1.5. Interfaz registrar daño de vehículo 62 8.5.1.6. Interfaz solicitud de alquiler 8.5.1.7. Interfaz agendar vehículo 63 8.5.1.8. Interfaz ingresar cliente 8.5.1.9. Interfaz ingresar vehículo a taller 64 8.5.1.10. Interfaz entregar vehículo 8.5.1.11. Interfaz registrar arreglo de vehículo 65 8.5.2. Interfaces definitivas Las siguientes interfaces corresponden a los diseños finales aprobados por el cliente, este diseño posee una funcionalidad mejorada significativamente en cuanto a su usabilidad. Cabe anotar que por pedido del cliente para esta fase no se contempla el trabajo con roles para cada actividad, por lo tanto en esta primera fase todo el proceso de alquiler lo realiza un solo usuario. 8.5.2.1. Interfaz de ingreso al sistema Mediante esta interfaz el usuario puede ingresar al sistema escribiendo su email y password y presionando el botón login. El usuario puede dar clic en el link olvidaste tu password, para ir a la interfaz de recuperación de clave. 66 8.5.2.2. Interfaz para cambiar el password En esta interfaz el usuario
Compartir