UNIVERSIDAD AUSTRAL DE CHILE ESCUELA DE INGENIERIA EN ...
171
UNIVERSIDAD AUSTRAL DE CHILE SEDE PUERTO MONTT ESCUELA DE INGENIERIA EN COMPUTACION SISTEMA WEB PARA TALLER MECÁNICO Y CONTROL DE FLOTA DE TRANSPORTES JEN Seminario de Titulación para optar al título de Ingeniero en Computación PROFESOR PATROCINANTE: Sra. Claudia Zil Bontes CARLOS A. BARRÍA SOTO PUERTO MONTT – CHILE 2012
Transcript of UNIVERSIDAD AUSTRAL DE CHILE ESCUELA DE INGENIERIA EN ...
UNIVERSIDAD AUSTRAL DE CHILE
SEDE PUERTO MONTT
ESCUELA DE INGENIERIA EN COMPUTACION
SISTEMA WEB PARA TALLER MECÁNICO Y CONTROL DE FLOTA DE
TRANSPORTES JEN
Seminario de Titulación para
optar al título de Ingeniero en
Computación
PROFESOR PATROCINANTE:
Sra. Claudia Zil Bontes
CARLOS A. BARRÍA SOTO
PUERTO MONTT – CHILE
2012
Agradecimientos
Durante todos estos años son muchas las personas que han participado
en mi formación como profesional y a quienes quiero expresar mi gratitud por el
apoyo y la confianza que me han prestado.
En primer lugar, quiero agradecer a mis padres por todo el apoyo
incondicional que siempre me brindaron, sobre todo en los malos momentos. A
mi hermana por su apoyo y cariño en todos los momentos. También a toda mi
familia: mis abuelas, mis tíos, mis tías, mis primas y mis primos.
A mis amigos, los cuales han estado presentes en todos los momentos.
Desde muy pequeños hemos compartido grandes momentos y grandes
experiencias las cuales nos han llevado a formarnos como las personas que
somos hoy en día.
A la profesora Claudia Zil, por su excelente disposición para estar
siempre apoyándome como patrocinante de este proyecto, y a don Fernando
Toledo, quien confió en mis capacidades profesionales.
Finalmente, a Fran. Gracias por acompañarme en este último proceso de
mi vida universitaria, por tus palabras de aliento cuando las fuerzas flaqueaban,
y por todo tu cariño que me entregas.
ÍNDICE
1 INTRODUCCIÓN ....................................................................................... 1
2 OBJETIVOS .............................................................................................. 4
2.1 OBJETIVO GENERAL ................................................................................... 4
2.2 OBJETIVOS ESPECÍFICOS ............................................................................ 4
3 PLANTEAMIENTO DEL PROBLEMA....................................................... 6
3.1 ANTECEDENTES ........................................................................................ 6
3.1.1 Definición del Problema ....................................................................... 6
3.1.2 Esfuerzos Anteriores ............................................................................ 8
3.1.3 Solución Propuesta ............................................................................ 11
3.2 JUSTIFICACIÓN ........................................................................................ 19
3.2.1 Situación sin proyecto ........................................................................ 19
3.2.2 Situación con proyecto ....................................................................... 21
3.3 DELIMITACIÓN ......................................................................................... 22
4 METODOLOGÍA ...................................................................................... 23
5 RECURSOS ............................................................................................. 25
5.1 HARDWARE ............................................................................................. 25
5.2 SOFTWARE ............................................................................................. 25
6 ANÁLISIS DEL SISTEMA ....................................................................... 27
6.1 INTRODUCCIÓN ........................................................................................ 27
6.2 CARACTERÍSTICAS GENERALES DEL PROYECTO .......................................... 27
6.3 IDENTIFICACIÓN DE USUARIOS .................................................................. 30
6.4 ARQUITECTURA DEL SISTEMA ................................................................... 30
6.5 MODELO DE CASOS DE USOS ................................................................... 33
6.5.1 Modelo de Casos de Usos: Taller Mecánico, Módulo Inventario........ 35
6.5.2 Modelo de Casos de Usos: Taller Mecánico, Módulo Mantenciones . 36
6.5.3 Modelo de Casos de Usos: Taller Mecánico, Módulo Control de
Combustible .................................................................................................... 37
6.5.4 Modelo de Casos de Usos: Taller Mecánico, Módulo Administración 38
6.5.5 Modelo de Casos de Usos: Control de Acceso, Modulo Entrada ....... 41
6.5.6 Modelo de Casos de Usos: Control de Acceso, Modulo Salida ......... 42
6.5.7 Modelo de Casos de Usos: Control de Acceso, Modulo Reportes ..... 43
7 DISEÑO DEL SISTEMA .......................................................................... 44
7.1 DISEÑO DE LA BASE DE DATOS ................................................................. 44
7.2 MODELO CONCEPTUAL DE DATOS ............................................................. 45
7.2.1 Especificación de Entidades .............................................................. 45
7.2.2 Identificación de relaciones ................................................................ 48
7.2.3 Identificación de atributos en una entidad o relación ......................... 50
7.2.4 Diagrama de Entidad-Relación .......................................................... 59
7.3 MODELO LÓGICO DE DATOS ..................................................................... 60
7.3.1 Transformación del Modelo Conceptual al Modelo Lógico ................. 60
7.3.2 Modelo Físico de datos ...................................................................... 61
7.3.3 Claves Primarias y Foráneas ............................................................. 72
7.4 DISEÑO DE INTERFAZ DE USUARIO ............................................................ 73
7.4.1 Requerimientos del Cliente ................................................................ 73
7.4.2 Prototipo de Interfaz propuesta .......................................................... 73
8 DESARROLLO DE LA PLATAFORMA .................................................. 76
8.1 MODELO DE CLASES DEL FRAMEWORK ...................................................... 76
8.2 ZEND FRAMEWORK .................................................................................. 79
8.2.1 Características Principales del Framework ........................................ 79
8.2.2 Comparación con otros Framework para PHP ................................... 81
8.3 CONTROL DE VERSIONES CON SVN .......................................................... 82
8.4 PRIMERA ITERACIÓN ................................................................................ 83
8.4.1 Creación del Layout de la Interfaz ...................................................... 83
8.4.2 Desarrollo Control de Usuarios .......................................................... 86
8.4.3 Creación Módulo Control de Acceso .................................................. 89
8.5 SEGUNDA ITERACIÓN ............................................................................... 99
8.5.1 Desarrollo Módulo de Inventario ........................................................ 99
8.5.2 Implementación Módulo de Mantenciones ....................................... 115
8.5.3 Creación Módulo Control de Carga de Combustible ........................ 123
8.5.4 Desarrollo Módulo de Administración ............................................... 130
8.6 TERCERA ITERACIÓN.............................................................................. 142
8.6.1 Creación de Gráficos ....................................................................... 142
8.6.2 Pruebas y Corrección de Errores ..................................................... 146
9 CONCLUSIONES .................................................................................. 150
10 BIBLIOGRAFÍA ..................................................................................... 153
ÍNDICE DE FIGURAS
Figura 1: Representación gráfica del funcionamiento del modelo vista
controlador. ....................................................................................................... 14
Figura 2: Comparación entre distintos framework de PHP. .............................. 15
Figura 3: Diagrama de funcionamiento del sistema, según cliente. .................. 29
Figura 4: Diagrama de conexión entre el servidor y los clientes. ...................... 31
Figura 5: Diagrama del patrón de diseño Modelo, Vista, Controlador. .............. 32
Figura 6: Caso de Uso. Actor Taller Mecánico y módulos respectivos. ............ 34
Figura 7: Caso de Uso. Actor Control de Acceso y módulos respectivos. ........ 34
Figura 8: Caso de Uso Taller Mecánico y sus funcionalidades. ........................ 35
Figura 9: Caso de Usos de las mantenciones del taller mecánico. ................... 36
Figura 10: Caso de Uso del control de combustible, taller mecánico. ............... 37
Figura 11: Caso de Uso, módulo administración del taller mecánico................ 39
Figura 12: Caso de Uso módulo administración, taller mecánico. .................... 40
Figura 13: Caso de Uso control de acceso, módulo entrada. ........................... 41
Figura 14: Caso de Uso control de acceso, módulo salida. .............................. 42
Figura 15: Caso de Uso módulo reportes, control de acceso. .......................... 43
Figura 16: Diagrama Entidad-Relación. ............................................................ 59
Figura 17: Prototipo pantalla de mantenciones. ................................................ 74
Figura 18: Prototipo pantalla Ingreso de existencia. ......................................... 74
Figura 19: Prototipo pantalla Entrada-Control de acceso. ................................ 75
Figura 20: Modelo de Clases, parte 1. .............................................................. 77
Figura 21: Modelo de Clases, parte 2. .............................................................. 78
Figura 22: Tabla comparativa de Zend con otros framework. ........................... 81
Figura 23: Layout página de inicio. ................................................................... 84
Figura 24: Parte de código Layout. ................................................................... 85
Figura 25: Layout y menú control de acceso. ................................................... 86
Figura 26: Layout y menú taller mecánico. ....................................................... 86
Figura 27: Parte código función login. ............................................................... 87
Figura 28: Código Form Usuario. ...................................................................... 88
Figura 29: Vista login usuario............................................................................ 89
Figura 30: Parte código EntradaController. ....................................................... 90
Figura 31: Parte código formulario Salida. ........................................................ 91
Figura 32: Vista Index, Entrada......................................................................... 93
Figura 33: Vista index, Entrada. ........................................................................ 94
Figura 34: Vista ingresar Entrada. .................................................................... 95
Figura 35: Vista index, Salida. .......................................................................... 96
Figura 36: Vista Agregar, Salida. ...................................................................... 97
Figura 37: Vista Buscar, Entrada. ..................................................................... 98
Figura 38: Parte de Controlador Rubro. .......................................................... 101
Figura 39: Vista index, rubro. .......................................................................... 102
Figura 40: Lista de rubros. Vista index. ........................................................... 103
Figura 41: Función add, RubroController. ....................................................... 104
Figura 42: Vista add, RubroController ............................................................. 105
Figura 43: Vista editar Rubro. ......................................................................... 106
Figura 44: Vista Eliminar Rubro. ..................................................................... 106
Figura 45: Vista Buscar rubro. ........................................................................ 107
Figura 46: Vista index familia. ......................................................................... 108
Figura 47: Vista agregar familia. ..................................................................... 109
Figura 48: Vista index repuestos. .................................................................... 110
Figura 49: Vista agregar repuesto. .................................................................. 111
Figura 50: Código función getRepuesto, Modelo de datos. ............................ 112
Figura 51: Vista buscar repuesto. ................................................................... 113
Figura 52: Vista Salida Repuesto. ................................................................... 114
Figura 53: Parte de código controlador de mantención. ................................. 116
Figura 54: Vista index, mantención. ................................................................ 117
Figura 55: Código función getMantencion. ..................................................... 118
Figura 56: Vista ficha mantención. .................................................................. 119
Figura 57: Formulario agregar mantención. .................................................... 120
Figura 58: Código función getMantencion. ..................................................... 121
Figura 59: Vista buscar mantención. ............................................................... 122
Figura 60: Función getCarga. ......................................................................... 123
Figura 61: Parte de código vista index carga de combustible. ........................ 124
Figura 62: Interfaz vista index, carga de combustible. .................................... 125
Figura 63: Código función addCarga. ............................................................. 126
Figura 64: Vista agregar carga de combustible............................................... 126
Figura 65: Código vista buscar carga de combustible. ................................... 127
Figura 66: Código resultados de búsqueda de carga. .................................... 128
Figura 67: Vista buscar carga de combustible. ............................................... 129
Figura 68: Código vista index camiones. ........................................................ 131
Figura 69: Interfaz lista de camiones. ............................................................. 131
Figura 70: Función getCamion. ....................................................................... 132
Figura 71: Vista ficha camión. ......................................................................... 133
Figura 72: Vista Agregar Camión. ................................................................... 134
Figura 73: Código vista alertas. ...................................................................... 135
Figura 74: Interfaz vista Alerta. ....................................................................... 136
Figura 75: Vista index conductores. ................................................................ 137
Figura 76: Función addAction, ChoferController. ............................................ 138
Figura 77: Interfaz vista agregar conductor. ................................................... 139
Figura 78: Vista buscar conductores. .............................................................. 140
Figura 79: Código vista graficar. ..................................................................... 143
Figura 80: Vista graficar. ................................................................................. 144
Figura 81: Código función graficarAction. ....................................................... 144
Figura 82: Gráfico, Cargas más elevadas. ...................................................... 145
ÍNDICE DE TABLAS
Tabla 1: Complejidad dominio Ingeniería de Software. ..................................... 17
Tabla 2: Especificación de Identidades. ............................................................ 47
Tabla 3: Identificación de relaciones. ................................................................ 50
Tabla 4: Atributos y descripción de la tabla ayudante. ...................................... 51
Tabla 5: Atributos y descripción de la tabla conductor. ..................................... 52
Tabla 6: Atributos y descripción de la tabla Salida. ........................................... 52
Tabla 7: Atributos y descripción tabla Entrada. ................................................. 53
Tabla 8: Atributos y descripción tabla Camión. ................................................. 54
Tabla 9: Atributos y descripción s tabla Carga. ................................................. 54
Tabla 10: Atributos y descripción de tabla Mantención. .................................... 55
Tabla 11: Atributos y descripción de tabla Servicentro. .................................... 55
Tabla 12: Atributos y descripción de la tabla Repuesto. ................................... 56
Tabla 13: Atributos y descripción de tabla Familia. ........................................... 56
Tabla 14: Atributos y descripción de tabla Rubro.............................................. 57
Tabla 15: Atributos y descripción tabla Mecánico. ............................................ 57
Tabla 16: Atributos y descripción de tabla Proveedor. ...................................... 58
Tabla 17: Atributos y descripción de tabla Herramienta. ................................... 58
Tabla 18: Atributos y características de la tabla ayudante. ............................... 62
Tabla 19: Atributos y características de la tabla conductor. .............................. 62
Tabla 20: Atributos y características de la tabla Salida. .................................... 63
Tabla 21: Atributos y características tabla Entrada. .......................................... 64
Tabla 22: Atributos y características tabla Camión. .......................................... 65
Tabla 23: Atributos y características tabla Carga. ............................................. 66
Tabla 24: Atributos y características de tabla Mantención. ............................... 67
Tabla 25: Atributos y características de tabla Servicentro. ............................... 67
Tabla 26: Atributos y características de la tabla Repuesto. .............................. 68
Tabla 27: Atributos y características de tabla Familia. ...................................... 68
Tabla 28: Atributos y características de tabla Rubro. ........................................ 68
Tabla 29: Atributos y características tabla Mecánico. ....................................... 69
Tabla 30: Atributos y características de tabla Proveedor. ................................. 69
Tabla 31: Atributos y características de tabla Herramienta. .............................. 70
Tabla 32: Atributos y características de tabla SalidaElemento. ........................ 70
Tabla 33: Atributos y características de la tabla SalidaRepuesto. .................... 71
Tabla 34: Atributos y características de la tabla Usuario. ................................. 71
Tabla 35: Tablas, sus claves primarias y foráneas. .......................................... 72
SÍNTESIS
Este documento describe el análisis, diseño y desarrollo del Sistema de
Control de Flotas. El sistema fue hecho para la empresa Transportes Jen
ubicada en Puerto Montt. Esta compañía transporta diferentes productos como
abarrotes, caramelos, alimentos congelados, entre otros.
El objetivo principal de este proyecto es desarrollar una aplicación web
para el control del inventario del taller mecánico, el control de combustible y el
control de las mantenciones del vehículo.
La metodología utilizada en el desarrollo de esta aplicación fue
Programación Extrema ya que esta es una metodología ágil. Las herramientas
usadas en el desarrollo del sistema son: Sistema operativo Ubuntu 12.04, Zend
Framework, Php5, MySQL v5.524, Html, Ajax, PowerDesigner, entre otros.
SYNTHESIS
This document describes the analysis, design and development of the
System of Control of Fleet. The system was made for the Transportes Jen
Company located in Puerto Montt. This company transports different products
like foodstuff, candies, frozen foods and others.
The main target of this project is develop a web application for control the
garage’s inventory, control the fueling and control the vehicle’s maintenance.
The methodology used in the develop of this application was Xtream
Programming because this is an agile methodology. The tools are used to
develop this system are: Ubuntu 12.04 OS, Zend Framework, PHP5, MySQL
v5.5.24, html, Ajax, PowerDesigner and others.
1
1 Introducción
Hoy en día debido al desarrollo que está teniendo nuestro país, y en
especial en la región, muchas ciudades y pueblos aledaños a Puerto Montt
están teniendo un gran crecimiento. Por este motivo, se han creado muchas
empresas que se dedican al transporte de productos y mercadería a lo largo del
país y la región.
Dentro de este grupo de empresas se encuentra Transportes Jen
Limitada, empresa que nace en mayo de 2001 y que le brinda apoyo logístico a
Comercial Binder. Así, Transportes Jen se dedica principalmente al traslado de
abarrotes, confites, productos congelados y otros alimentos.
Esta empresa cuenta con una flota cercana a 40 “camiones ¾” entre los que
se encuentran camiones especializados para transportar productos congelados.
Además cuenta con un taller mecánico en el cual se le realizan las mantenciones
periódicas a los camiones de la flota, cambiando o realizando las mantenciones de
las partes que sean necesarios.
2
Sin embargo, el control del inventario del taller mecánico y de toda la
información relacionada con las mantenciones se realiza sólo a través de
planillas Excel, por lo que se transforma en un trabajo que toma muchos
minutos debido a la gran cantidad de planillas existentes.
Además, hoy en día no hay un control en el kilometraje de los camiones
por lo que no se sabe si los camiones recorren solamente las distancias que
hay entre la empresa y los destinos de los productos, o se dirigen a otros
destinos.
Por los motivos mencionados anteriormente, nace la idea de desarrollar
un sistema que le permita a la empresa llevar el control de la información del
inventario del taller mecánico, de las mantenciones que se realizan y que
permita obtener distintos tipos de reportes.
El presente documento presenta el planteamiento del problema los
cuales fueron recopilados al momento de realizar el estudio del problema. Se
detallarán los antecedentes de éste y su justificación. Junto a esto también se
presentará la metodología utilizada para desarrollar la solución del problema.
3
También se detallará el análisis que se realizó para desarrollar el sistema
web, y los distintos diseños creados para éste. Además se expondrá paso a
paso lo que se realizó en cada iteración del desarrollo de la plataforma. En un
ámbito más técnico se presenta la complejidad con la cual se llevó cabo este
proyecto y las herramientas que se utilizaron.
4
2 Objetivos
2.1 Objetivo general
Desarrollar una plataforma web para controlar el inventario del taller
mecánico y el sistema de control de flota de Transportes Jen.
2.2 Objetivos específicos
Para lograr una plataforma que se adapte a las necesidades de la
empresa que se han señalado en el presente documento será necesario lo
siguiente:
- Controlar la cantidad de herramientas, equipos y repuestos del taller
mecánico de la empresa. Además también de tener un registro de las
marcas, tipo de herramientas, entre otros.
- Controlar datos importantes de cada camión de la empresa: fechas
importantes (revisión técnica, mantenciones, cambios de aceite, entre
otros), ficha de cada camión, ficha de cada mantención realizada, entre
otros.
5
- Controlar principales datos del camión en el acceso de la empresa: en la
salida patente, kilometraje, chofer, destino(s) y en la entrada el kilometraje
de regreso.
- Generar reportes en formato Excel, pdf y/u otros donde se pueda ver el
rendimiento de cada vehículo, los repuestos existentes u otro dato
importante de analizar para la empresa.
6
3 Planteamiento del Problema
3.1 Antecedentes
3.1.1 Definición del Problema
Transportes Jen es una empresa que se dedica al transporte de mercadería
con presencia entre Temuco y Chiloé, y que le presta servicios a Comercial Binder.
Esta empresa cuenta con una flota cercana a 40 “camiones ¾” entre los que se
encuentran camiones especializados para transportar productos congelados.
Esta empresa además cuenta con un taller mecánico en el cual se le
realizan las mantenciones periódicas a los camiones de la flota, cambiando o
realizando las mantenciones de las partes que sean necesarios. Por lo tanto, en el
taller existen gran cantidad de repuestos los cuales están clasificados por marca de
vehículo, por el tipo de repuesto, repuestos para algunas máquinas, materiales de
ferretería, aceites para vehículos, etc.
7
Para cualquier empresa es muy importante controlar el inventario de todo lo
que se tiene, para que no existan pérdidas y se aumenten los gastos en insumos
de manera innecesaria. Sin embargo en esta empresa no existe una forma clara,
ordenada y rápida de contabilizar y saber la existencia de los repuestos y
herramientas.
Por otro lado, para la empresa también necesita controlar la información
relacionada con las mantenciones que se le realizan a los vehículos. Es decir, se
necesitan controlar los repuestos que fueron ocupados para eliminarlos del
inventario, el valor de los insumos utilizados y la(s) persona(s) que realizó la
mantención para tener un costo asociado por mano de obra. De esta forma se
tendrá un valor total del costo de la mantención.
Junto a lo anterior, al mantener una información actualizada y real de las
mantenciones que se le realizan a cada camión también ayuda para saber el
estado de los camiones existentes. También se puede saber el rendimiento que
está teniendo cada vehículo, la vida útil de cada repuesto, etc. Toda esta
información es necesaria para saber en qué momento se necesita dar de baja un
camión.
8
Finalmente, hoy en día no hay un control en el kilometraje de los camiones.
Es decir, los camiones en un día o en una entrega pueden salir hacia un destino,
pero no hay ninguna forma actualmente que busque controlar la distancia recorrida
por los vehículos por lo que al salir de la empresa pueden ir hacia otros destinos lo
que aumentaría el consumo de combustible, o demorando el viaje haciendo
paradas innecesarias, lo que disminuiría la cantidad de entregas que se pueden
realizar durante un día.
3.1.2 Esfuerzos Anteriores
Los problemas que se describieron anteriormente no sólo están
presentes en Transportes Jen, sino que son problemas que ya han tenido otras
empresas de transportes.
Por este motivo, muchas empresas desarrolladoras de software se han
interesado en crear aplicaciones que se dediquen a la gestión y el control de
flotas para que de esta forma las empresas de transportes puedan tener mejor
información para la toma de decisiones.
9
En el país hay muchas empresas que ofrecen sistemas que realizan
estas tareas entre los cuales se pueden encontrar:
• Eugcom Informática: El software que ofrece esta empresa ubicada en
Santiago tiene gran cantidad de características donde las principales son:
agenda de vencimientos, control de choferes, control de entradas y salidas,
control de reparaciones y estudio de costo de combustibles
[EugcomInformática].
• Inducom: La aplicación desarrollada por esta empresa aparte de tener
como funciones principales las mismas que el software de la empresa anterior,
tiene como gran característica que se puede tener el control de la flota de
camiones por GPS. Esto aumenta el control, pero de la misma forma aumentan
los costos [Inducom].
• Citymovil: El sistema de control de flota de esta empresa cuenta con los
siguientes servicios principales: control y seguimiento, generación de ruta
mínima, control de huella digital y calidad de conducción [CityMovil].
• Wisetrack: Wisetrack Report es la aplicación desarrollada por esta
empresa que tiene entre sus principales funciones: gestión de flota, actividades
de flota y sensores [WiseTrack].
10
Como se puede ver, actualmente en el país existen distintas alternativas
que cumplen con los requisitos que solicita la empresa para cubrir sus
necesidades. Sin embargo estas alternativas existentes tienen algunas
características que podrían ser un problema para la empresa.
En primer lugar, todas estas aplicaciones son privadas. Por lo tanto, para
poder utilizarlos la empresa deberá comprar la aplicación a la respectiva
empresa.
Junto a esto, estos softwares además de contar con las funcionalidades
que necesita la empresa tiene otras las cuales no se ajustan a la realidad de la
empresa por lo que se estaría pagando demasiado dinero por un software que
no necesitan en su totalidad.
Finalmente, por los motivos mencionados anteriormente para la empresa
es una buena alternativa contar con un sistema desarrollado especialmente
para ellos con las funcionalidades hechas a su medida y a la realidad de la
empresa, con costos muy inferiores en comparación con las aplicaciones de las
empresas mencionadas anteriormente.
11
Por otro lado, Transportes Jen ha intentado resolver estos problemas de
distintas formas. En primer lugar, actualmente en la empresa se tiene el
inventario del taller mecánico en planillas Excel. Este muchas veces no cuenta
con toda la información ya que no se va actualizando a medida que se realizan
las mantenciones. En segundo lugar, se mantiene una planilla Excel por cada
camión donde se almacena la ficha de cada camión y las mantenciones que se
le realizan a este, por lo cual se consume mayores recursos de los necesarios.
Por último, la empresa para poder sacar reportes de cualquier tipo debe
revisar una gran cantidad de archivos y planillas, estudiarlas, sacar la
información que requieren, y muchas veces llevarla a otras planillas para sacar
los reportes necesarios. Por lo tanto, para la toma de decisiones se realiza una
tarea muy compleja.
3.1.3 Solución Propuesta
Dado los problemas presentados anteriormente para Transportes Jen, es
muy importante dar una solución lo antes posible, para de esta forma ahorrar
tiempo en realizar la consulta de la información e impedir el gasto innecesario
de dinero.
12
Desde esa perspectiva, lo que se propone es desarrollar una plataforma
web en la cual se pueda manejar y controlar todos los aspectos que se
mencionaron anteriormente: el inventario del taller mecánico, el sistema del
control de flota y el control de acceso (entrada-salida) a la empresa, para así
cubrir totalmente las necesidades de la empresa.
El inventario del taller mecánico tendrá la posibilidad de agregar, borrar o
editar insumos, herramientas, mecánicos, camiones. Junto a esto, le permitirá al
usuario buscar en el inventario de acuerdo a algún parámetro que el seleccione
lo que arrojará una lista con los resultados encontrados.
El módulo del sistema de control de flota tendrá dos secciones:
mantenciones y control de combustible. En la sección de mantenciones, se
podrán ingresar todas las mantenciones realizadas registrando datos
importantes para la empresa como patente, fecha de ingreso, fecha de salida,
repuestos utilizados y mecánicos que participaron en el trabajo. De esta forma
se generará una ficha de la mantención donde se podrá ver la misma
información, pero con los gastos asociados (valor de los repuestos y valor de
horas-hombre de los mecánicos).
13
En la sección de control de combustibles se podrá agregar, editar, borrar
y buscar los registros de llenado de estanque de combustible de los camiones,
donde se almacenará el servicentro, patente, fecha, cantidad combustible,
valor, entre otros datos de importancia.
Habrá también otro módulo de reportes donde se podrá sacar gráficos
y/o tablas según sea la elección del usuario. Se podrán ver los vehículos con
más gasto de combustible, con más mantenciones realizadas, las mantenciones
más costosas, entre otras.
Finalmente, tendrá el módulo de control de acceso. En esta parte de la
plataforma se registrará cada vez que salga patente, fecha y hora de salida,
destino(s), odómetro, chofer, número de orden de despacho y un campo para
observaciones que se puedan realizar. Al momento de ingresar se registrará el
chofer, odómetro, patente, fecha y hora de ingreso y un campo para
observaciones.
La realización de este proyecto consta de dos etapas. La primera etapa
es la de análisis y diseño, en la cual se analizarán los requerimientos que han
sido obtenidos en reuniones previas lo cual dará como resultado el diseño de la
base de datos de la plataforma y el diseño preliminar de la interfaz del usuario.
14
La segunda etapa del proyecto es la de codificación, en la cual una vez
terminada la primera etapa se comenzará a generar la interfaz diseñada y a
conectar esta con la base de datos. Para esto se utilizará un framework del
lenguaje de programación seleccionado para el desarrollo (PHP) que trabaje
con el modelo vista controlador [Pavón2008]. Ver figura 1.
Figura 1: Representación gráfica del funcionamiento del modelo vista controlador.
Existe una gran oferta de framework para PHP, unos más maduros que
otros, con más documentación que otros o con mejor rendimiento que otros.
15
Igualmente en Internet se puede encontrar una gran cantidad de información
comparativa y, en general, opiniones sobre cual es superior al resto.
El framework que se seleccionó para realizar el desarrollo del sistema se
llama Zend Framework. Es un framework opensource para PHP, y es 100%
orientado a objetos. Se seleccionó este framework ya que existe una buena
documentación, tiene una gran cantidad de componentes, incluido algunos de
Microsoft, Google y Adobe, y soporta PHP5. Ver Figura 2.
Figura 2: Comparación entre distintos framework de PHP.
16
Se implementará la solución en una plataforma web ya que tiene una
serie de ventajas entre las que se encuentran:
- Movilidad: Al encontrarse la plataforma en un servidor de la empresa
se puede acceder a esta desde cualquier computador que se conecte
a la red y que tenga sólo un navegador web sin necesidad de instalar
un programa.
- Flexibilidad: Permite realizar modificaciones o agregar nuevas
funcionalidades de forma relativamente rápida, sin necesidad de tener
que modificar el código fuente de un programa completo.
- Multiplataforma: Desde cualquier sistema operativo se podrá acceder
a la plataforma.
El equipo de trabajo está compuesto por la profesora de la escuela de
Ingeniería en Computación Sra. Claudia Zil quien será la responsable de dirigir
el proyecto. También participará el alumno tesista, quien tendrá la labor de
analizar, diseñar e implementar la plataforma web.
17
3.1.3.1 Tabla de Complejidad del Dominio Ingeniería de Software
Dominio Ingeniería de Software
Valor Detalle según tabla
Parámetro Concepto Nota
Nivel de
programación Nominal 4.5
- Arquitectura en capas.
Control de errores. Uso de
nomenclatura de programación.
- Uso de patrones de diseño
comunes.
Nivel matemático Baja 2.5
- Operaciones de cálculo
predefinidas en librerías.
Operaciones con
manejo de datos Nominal 4.5
- Transacciones
- Concurrencia Simple
Operaciones para
gestión de interfaz de
usuario
Alta 5.5
- Modelamiento y/o gráficos 2D.
- Uso de herramientas y
tecnologías que faciliten la
usabilidad en entornos web
(AJAX).
Uso de buenas
prácticas Alta 5.5
- Control de versiones de
software y de modelos (o todo
lo que pueda llevar a entregar
una nueva versión de software).
Promedio Nominal 4.5
Tabla 1: Complejidad dominio Ingeniería de Software.
18
Detalle de tabla de complejidad
Nivel de programación: Se programará de acuerdo a la arquitectura en capas,
es decir en la capa reglas de negocio que es donde se establecen las reglas
que deben cumplirse, la capa de presentación en la cual se encuentra la
interfaz de usuario y la capa de datos en donde se encuentran los datos y es la
encargada de acceder a éstos. También se usará una nomenclatura de
programación y se documentará el código. Finalmente se usará el patrón de
diseño MVC.
Nivel matemático: Para la implementación de la plataforma se deben realizar
cálculos matemáticos para obtener el rendimiento del vehículo, la vida útil de
estos, los costos de una mantención, etc. Para lograr esto se utilizarán
operaciones predefinidas en las librerías del lenguaje de programación.
Operaciones con manejo de datos: La plataforma web utilizará una base de
datos en la cual se almacenará toda la información. Para el manejo de los datos
se utilizarán transacciones (procedimientos almacenados) y además la
plataforma debe utilizar concurrencia simple ya que esta debe ser multiusuario,
es decir, más de un usuario pueden ingresar a la plataforma y realizar algún
cambio que se vea reflejado en la base de datos por lo cual esto debe ser
controlado.
19
Operaciones para gestión de interfaz de usuario: En primer lugar para tener
una página web dinámica y aumentar la interactividad, velocidad y usabilidad de
la aplicación se va a utilizar AJAX, lo que permite realizar cambios en las
páginas sin necesidad de recargarla, entre otros beneficios. Además para
presentar diversos reportes a petición del cliente como por ejemplo rendimiento
del vehículo, vida útil de estos, vehículos con mayores mantenciones, entre
otros. Se deberán implementar gráficos 2D.
Uso de buenas prácticas: Se utilizará como herramienta de control de
versiones SVN (Subversión). Esta herramienta mantiene un registro de todos
los cambios realizados en los archivos de un proyecto.
3.2 Justificación
3.2.1 Situación sin proyecto
Actualmente en Transportes Jen se tiene el inventario en un archivo
Excel. El archivo no representa lo que realmente existe en el taller mecánico ya
que muchas veces se ocupan los insumos y la información no es actualizada en
el Excel.
20
Además en relación a la ficha de los vehículos y las mantenciones que se
le realizan a éstos, hoy en día en la empresa se tiene un archivo Excel por cada
camión lo que representa a la ficha del vehículo. Por lo tanto se tiene alrededor
de 40 planillas diferentes solo para tener la ficha del camión por lo que al
momento de requerir algún tipo de información de estas planillas se hace un
trabajo bastante engorroso. Junto a lo anterior, los costos asociados a las
mantenciones como lo son el valor de los insumos utilizados y de la mano de
obra, debe ser calculada por el jefe del taller de mecánico de forma manual ya
que no está automatizado de ninguna manera.
También para la toma de decisiones se hace muy importante los distintos
reportes que se pueden obtener. Esto se hace analizando las diferentes
planillas Excel que se tienen, lo que hace que en algunas oportunidades se
tenga que trabajar con 3 o 4 planillas distintas ya que la información se
encuentra almacenada de esa forma.
Finalmente, en el control de acceso de la empresa no existe ningún
respecto al destino y el kilometraje que tienen los camiones que abandonan el
recinto por lo cual han existido robos de mercadería, combustible e insumos.
21
3.2.2 Situación con proyecto
Con el proyecto que se desea desarrollar se cubrirán todas las
necesidades que se describieron en el punto anterior.
En primer lugar, se tendrá un inventario totalmente actualizado en
relación a los insumos que se han utilizado en las mantenciones y los que
realmente se encuentran en el taller.
También se tendrán las fichas de los vehículos en la base de datos, por
lo tanto no existirán las cerca de 40 planillas distintas. El proyecto permitirá
realizar búsquedas por distintos parámetros por lo que encontrar la información
que se necesita será sencillo y rápido. A esto se le suma que los costos que
están asociados a las mantenciones ya sea por el valor de los insumos y por el
costo de la mano de obra será calculado de forma automática por la plataforma
por lo que se le alivianará el trabajo al jefe del taller mecánico, teniendo así más
tiempo para desarrollar otras actividades.
22
Por otra parte, se podrán generar diversos tipos de reportes de acuerdo a
los parámetros que el administrador estime conveniente o desee estudiar. Se
podrán obtener distintos gráficos y tablas lo cual para la toma de decisiones de
la empresa será de mucha ayuda.
Por último, se implementará un control en el acceso del recinto de la
empresa donde se verificarán algunos datos del camión al momento que
abandone y que ingrese a la planta. Esto evitará la situación que se da
actualmente de pérdida de mercadería, combustible y otros.
3.3 Delimitación
En la plataforma no se agregarán los datos existentes en las planillas
Excel. Sólo se trabajará con los datos necesarios para realizar las pruebas
estimadas para confirmar el correcto funcionamiento del software.
El software será instalado solamente en el servidor de la empresa, por lo
tanto podrán trabajar en la plataforma sólo las personas que tengan acceso a
este servidor. La plataforma no tendrá salida hacia Internet.
23
4 Metodología
Con el objetivo de estructurar, planificar y controlar el proceso de
desarrollo de software se utiliza con frecuencia alguna de las distintas
metodologías de desarrollo.
Para este caso en particular se decide utilizar una metodología de
desarrollo ágil [Canós2007], “Extreme Programming” específicamente
[Fernández2002]. Esta, es una metodología ligera de desarrollo de software que
se basa en la simplicidad, la comunicación y la realimentación o reutilización del
código desarrollado.
Esta metodología consiste en implementar algunas fases o iteraciones.
Además hay una frecuente interacción del equipo de programación con el
cliente, corregir los errores antes de añadir una nueva funcionalidad y
simplicidad en el código.
24
Los beneficios de utilizar esta metodología es que se realiza una
planificación que el cliente conoce, permite definir con claridad los objetivos de
cada iteración, permite tener retroalimentación con los clientes lo cual es muy
útil para el correcto desarrollo de la plataforma y la presión de realizar un buen
trabajo está a lo largo de todo el proyecto y no se resume a una entrega final.
Este proyecto contemplará 3 iteraciones: en la primera iteración se
realizará lo que se relaciona con la página de inicio, autentificación, el control de
acceso a la planta y el inventario del taller. La segunda iteración incluirá lo
relacionado con las mantenciones y fichas de los vehículos. En la última
iteración se trabajará con los reportes.
25
5 Recursos
5.1 Hardware
Para el desarrollo de la plataforma se utilizará un notebook marca Dell,
modelo Inspiron N4030, el cual tiene las siguientes características:
- Procesador: Intel Core i3 2,53 Ghz.
- Memoria: 3 GB DDR3.
- Disco Duro: 500GB, 5400RPM.
5.2 Software
Los diferentes softwares que se van a utilizar para desarrollar el sistema
son:
- Sistema operativo Ubuntu 12.04
- Mysql será el motor de base de datos.
- Html y PHP como lenguajes de programación.
- Ajax: Técnica de desarrollo web para crear aplicaciones dinámicas.
26
- Zend Framework: Framework de desarrollo para PHP basado en MVC.
- Power Designer: Software dedicado al diseño de distintos modelos.
- Balsamiq Mockups: Software para la creación de prototipos de interfaz.
27
6 Análisis del Sistema
6.1 Introducción
El desarrollo de este proyecto surge a partir de la necesidad de
Transportes Jen, de poder contar con un sistema el cual le permita llevar un
control de forma más detallada, eficaz y ordenada de la información que
respecta a su flota de camiones. Esto debido al constante crecimiento de la
industria, de la cantidad de camiones, mantenciones y transportes, los cuales
han crecido en estos últimos años.
6.2 Características generales del proyecto
La plataforma deberá tener un diseño amigable y fácil de usar, permitiendo
así que todos los usuarios puedan familiarizarse rápidamente con el sistema sin
necesidad de saber con anterioridad herramientas computacionales.
El sistema debe tener la capacidad de controlar de manera eficiente el
inventario del taller mecánico de la empresa, donde cuenta con todo tipo de
equipos, herramientas y repuestos.
28
Además se debe ingresar una ficha de cada vehículo, proveedor y
empleado de la empresa, para así poder sacar distintos reportes de información
que se podrán obtener a partir de la información ingresada. De los vehículos se
quiere ver la patente, motor, número de chasís, marca, modelo, año y
kilometraje. De los proveedores se quiere controlar Rut, la dirección, nombre y
teléfono. De los empleados se quiere manejar nombre, Rut, teléfono, numero de
calzado, talla y sueldo.
También se tiene que registrar las mantenciones que se le realizan a los
distintos vehículos que tiene la empresa: el mecánico a cargo, la fecha de
entrada del vehículo, fecha de salida, kilometraje con el cual ingreso. Junto con
lo anterior, ver detalladamente los repuestos que se utilizan y el costo total de
cada mantención.
Por otra parte, se guardará en la plataforma toda la información referente
a la carga de combustibles que realiza cada chofer a cada vehículo: fecha,
servicentro, litros cargados, valor por litro. Esto para evitar el robo de
combustible.
29
Finalmente, el sistema debe poder controlar el acceso al recinto (entrada y
salida) donde se registrará la información del vehículo tal como: conductor,
patente, fecha, hora, destino, entre otros.
El usuario principal de esta plataforma realizó un diagrama donde
represento las características que debe contener el sistema. (Ver Figura 3).
Figura 3: Diagrama de funcionamiento del sistema, según cliente.
30
6.3 Identificación de Usuarios
Debido a las características del sistema, y la información que se maneja
en éste, se analiza que los usuarios que tendrán interacción con la plataforma
serán principalmente dos.
El primero será el encargado de ingresar, editar, borrar y obtener reportes
de toda la información que tiene relación con la parte del taller mecánico de la
empresa. El segundo estará a cargo de controlar los datos de los vehículos en
el acceso del recinto.
6.4 Arquitectura del Sistema
Para desarrollar un sistema de estas características existen distintos tipos
de arquitectura. En este caso particular se decidió utilizar la arquitectura cliente-
servidor. En el servidor de la empresa, el cual se encuentra conectado a
Internet, se tendrá instalado servidor web Apache, motor de base de datos
MySQL y la plataforma web en Windows Server 2003.
31
De este modo, cualquier cliente que se encuentre conectado a Internet o a
la misma red interna de la empresa a la cual se encuentra conectado el
servidor, tendrá acceso al sistema web. (Ver Figura 4).
Figura 4: Diagrama de conexión entre el servidor y los clientes.
Junto a la arquitectura cliente-servidor, se utilizará el patrón de diseño
MVC. Este patrón consiste en tener tres capas de programación, tres objetos
diferentes: el modelo, la vista y el controlador. (Ver Figura 5).
32
Figura 5: Diagrama del patrón de diseño Modelo, Vista, Controlador.
El Modelo es donde se maneja la información. El modelo en sí son los
datos puros que puestos en contexto del sistema proveen de información al
usuario o a la aplicación misma. Esta capa también es conocida como reglas de
negocios.
La Vista es la representación gráfica de los datos que se encuentra
disponible para la interacción con el usuario. En el caso de esta plataforma, la
vista es una página html con contenido dinámico sobre el cual el usuario puede
realizar distintas operaciones.
33
Y finalmente, el controlador el cual es el encargado de manejar y
responder las solicitudes del usuario a través de la capa Vista, procesando la
información necesaria y modificando la capa Modelo en caso de ser necesario.
6.5 Modelo de Casos de Usos
Luego de tener los requisitos de la plataforma, las principales
características del sistema y de los usuarios que interactuarán con éste se
modelarán los distintos diagramas de casos de usos, para así además tener
una mejor visión de la relación que habrá entre los distintos actores con las
funcionalidades de la plataforma.
Como se presentó anteriormente, los dos tipos de usuarios presentes en
el sistema tendrán acceso a distintos módulos y por ende podrán realizar
distintas funcionalidades. Ver Figuras 6 y 7.
A continuación se presentarán una representación de la interacción que
tendrán los actores de la plataforma con cada uno de los módulos, de forma
general, para luego verlo detalladamente.
34
Figura 6: Caso de Uso. Actor Taller Mecánico y módulos respectivos.
Figura 7: Caso de Uso. Actor Control de Acceso y módulos respectivos.
35
6.5.1 Modelo de Casos de Usos: Taller Mecánico, Módulo Inventario
Figura 8: Caso de Uso Taller Mecánico y sus funcionalidades.
Para clasificar las existencias del inventario existen las familias y para
clasificar las familias existen los rubros. Por este motivo se pueden crear, editar
y eliminar rubros, familias y existencias del inventario. (Ver Figura 8).
36
Los datos que se desean controlar para un rubro es el nombre. Para el
caso de la familia es su nombre y el rubro al cual pertenece. De una existencia
lo que se quiere almacenar es la familia a la cual pertenece, el proveedor, un
código dado por el administrador, su nombre, unidad de medida, la cantidad
que hay en stock y su valor unitario.
6.5.2 Modelo de Casos de Usos: Taller Mecánico, Módulo
Mantenciones
Figura 9: Caso de Usos de las mantenciones del taller mecánico.
37
En este módulo el usuario puede listar, agregar una mantención con los
datos que se solicitaron en la toma de requerimientos, editarlas y eliminar las
mantenciones en caso que sean necesarios. (Ver Figura 9).
En el caso de las mantenciones los datos a controlar son el camión al
cual pertenece la mantención, el mecánico que realizó la mantención, la fecha
de entrada al taller, la fecha de salida de éste, la descripción del problema,
alguna observación y el kilometraje del camión.
6.5.3 Modelo de Casos de Usos: Taller Mecánico, Módulo Control de
Combustible
Figura 10: Caso de Uso del control de combustible, taller mecánico.
38
En esta sección el usuario puede agregar, editar y eliminar un
servicentro, para luego poder seleccionarlo al momento de agregar un nuevo
control de combustible. Además puede listar, agregar, editar y eliminar las
cargas de combustible con los datos solicitados en la toma de requerimientos.
(Ver Figura 10).
Para un servicentro se quiere almacenar solamente su nombre. En el
caso de una carga de combustible se quiere controlar son: servicentro en el
cual se hizo la carga, la patente del camión, fecha, hora, cantidad de litros,
número de guía, valor unitario del litro, kilometraje del camión y la ciudad.
6.5.4 Modelo de Casos de Usos: Taller Mecánico, Módulo
Administración
En este módulo se desea administrar la información relacionada con los
vehículos y los proveedores de la empresa. (Ver Figura 11).
En el caso de los proveedores se desea manejar el nombre, el rut,
teléfono y dirección. De los vehículos se desea controlar la patente, marca,
modelo, año, kilometraje, fecha de revisión técnica, fecha de cambio de aceite,
número de chasís y número de motor.
39
Figura 11: Caso de Uso, módulo administración del taller mecánico.
El usuario maneja la información que tiene relación con los vehículos de
la empresa y con los proveedores de ésta.
40
Figura 12: Caso de Uso módulo administración, taller mecánico.
Junto a lo anterior, en el mismo módulo de administración el actor que
interactúa con el sistema puede controlar la información referente al personal
(conductores, mecánicos y ayudantes) y de las herramientas del taller. (Ver
Figura 12).
41
Para el personal se desea controlar el nombre, rut, sueldo, teléfono de
contacto, número de calzado y talla de vestuario. Para las herramientas lo que
se desea guardar es el nombre, código, cantidad y valor de unidad.
6.5.5 Modelo de Casos de Usos: Control de Acceso, Modulo Entrada
Figura 13: Caso de Uso control de acceso, módulo entrada.
El usuario de este rol en esta sección agrega las entradas de los
vehículos al recinto de la empresa. (Ver Figura 13).
En una entrada la información que se desea controlar es el camión, el
conductor, el ayudante, kilometraje del camión, fecha, hora y alguna
observación.
42
6.5.6 Modelo de Casos de Usos: Control de Acceso, Modulo Salida
Figura 14: Caso de Uso control de acceso, módulo salida.
El usuario de este rol en esta sección agrega las entradas de los
vehículos al recinto de la empresa. (Ver Figura 14).
En este caso lo que se desea almacenar es patente del camión,
conductor, ayudante, fecha, hora, kilometraje, observación y el destino.
43
6.5.7 Modelo de Casos de Usos: Control de Acceso, Modulo
Reportes
Figura 15: Caso de Uso módulo reportes, control de acceso.
El actor en este módulo puede listar, editar, eliminar y buscar entradas y
salidas según lo requiera. (Ver Figura 15).
44
7 Diseño del Sistema
7.1 Diseño de la Base de Datos
En esta parte del proyecto, y luego de tener identificado todos los
requisitos entregados en diversas reuniones con el cliente, y de tener modelado
los distintos modelos de casos de usos, se tiene el panorama más claro para
poder desarrollar el diseño de la base de datos.
El modelo que se debe crear debe ser capaz de satisfacer las
necesidades que se han expresado en el capitulo anterior. Para esto se
realizarán tres diseños distintos:
• Modelo Conceptual de Datos
• Modelo Lógico de Datos
• Modelo Físico de Datos
45
7.2 Modelo Conceptual de Datos
El modelado o diseño conceptual de datos es la primera fase del
desarrollo de base de datos. Este diseño se divide en dos etapas: la primera es
el análisis de los requisitos y la segunda es la generación del esquema
conceptual.
El modelo utilizado para graficar el esquema conceptual, es el llamado
modelo entidad-relación. Este es un modelo de datos que se basa en el mundo
real del sistema que se quiere desarrollar, que consiste en un conjunto de
objetos básicos llamadas entidades y las relaciones entre estos objetos.
7.2.1 Especificación de Entidades
Para entender de mejor forma el sistema que se desea desarrollar, se
debe identificar las entidades que participan en este.
Una entidad es un objeto real o abstracto que existe o puede existir en el
sistema y del cual se quiere guardar información. Esta información se conoce
como atributos de la entidad.
46
Nombre Entidad
Descripción
Ayudante
Tiene la información de los ayudantes
de los conductores de camiones.
Conductor
Guarda la información de los
conductores de los camiones de la
empresa.
Salida
Contiene los datos que se registran
cuando un camión abandona el
recinto.
Entrada
Almacena los datos que se entregan
cuando un camión ingresa al recinto.
Camión
Registra la información referente a
cada camión de la empresa.
Carga
Contiene los datos que se requieren
almacenar para controlar las cargas
de combustible.
Mantención
Guarda los valores que se desean
almacenar de cada una de las
mantenciones que se le realizan a
cada camión en el taller mecánico de
la empresa.
47
Servicentro
Tiene la información que tiene
relación con los lugares en los cuales
se cargan combustible.
Repuestos
Es cada una de las partes de los
camiones que existen en el inventario
del taller mecánico de la empresa.
Familia
Es la clasificación de los Repuestos.
Rubro
Es la forma en que se clasifican las
familias.
Mecánico
Guarda la información de los
encargados de realizar las
mantenciones de los vehículos en el
taller mecánico.
Proveedor
Contiene los datos de las empresas
que le venden insumos para el taller
de la empresa.
Herramienta
Almacena la información de las
herramientas utilizadas y existentes
en el inventario.
Tabla 2: Especificación de Identidades.
48
7.2.2 Identificación de relaciones
Se entiende por relación a la asociación entre dos o más entidades. Hay
distintos tipos de relaciones, y se clasifican de acuerdo a la cardinalidad
existente entre las entidades. Los tipos de relaciones por cardinalidad que
existen son tres: Relación Uno a Uno, Relación Uno a Muchos y Relación
Muchos a Muchos.
La relación uno a uno, se da cuando un registro de una tabla sólo puede
estar relacionado con un único registro de la otra tabla y viceversa. La relación
uno a muchos, es la que se tiene cuando un registro de la tabla secundaria sólo
puede estar relacionado con un único registro de la tabla principal y un registro
de la tabla principal puede estar relacionado con más de un registro de la tabla
secundaria. La relación muchos a muchos existe cuando un registro de una
tabla puede estar relacionado con más de un registro de la otra tabla y
viceversa.
La tabla que se presenta a continuación, muestra las relaciones que hay
entre las distintas entidades de la aplicación. (Ver Tabla 3).
49
Entidad
Relación
Entidad
Cardinalidad
Ayudante
Tiene
Salida
1:N
Ayudante
Tiene
Entrada
1:N
Conductor
Tiene
Salida
1:N
Conductor
Tiene
Entrada
1:N
Camión
Hace
Salida
1:N
Camión
Hace
Entrada
1:N
Conductor
Realiza
Carga
1:N
Carga
Pertenece
Camión
N:1
Carga
Se_realiza
Servicentro
N:1
Mantención
Pertenece
Camión
N:1
50
Mantención
Ocupa
Repuestos
1:N
Mecánico
Realiza
Mantención
1:N
Rubro
Contiene
Familia
1:N
Familia
Contiene
Repuesto
1:N
Proveedor
Entrega
Repuesto
1:N
Proveedor
Entrega
Herramienta
1:N
Tabla 3: Identificación de relaciones.
7.2.3 Identificación de atributos en una entidad o relación
Luego que se tienen identificadas las entidades y las relaciones se
procede a identificar cada uno de los atributos de cada entidad. Además se
agrega una pequeña descripción del atributo, tipo, si es que el atributo tiene
alguna restricción y si es que el atributo puede ser nulo. (Ver Tabla 4 a Tabla
17).
51
Ayudante
Atributo Descripción
Nombre
Nombre del Ayudante.
Rut
Rut del Ayudante.
Sueldo
Sueldo del Ayudante.
Teléfono
Teléfono de contacto.
NumCalzado
Número de calzado.
TallaVestuario
Talla de vestuario.
Tabla 4: Atributos y descripción de la tabla ayudante.
Conductor
Atributo
Descripción
Nombre
Nombre del Conductor.
Rut
Rut del Conductor.
Sueldo
Sueldo del Conductor.
52
Teléfono
Teléfono de contacto.
NumCalzado
Número de calzado.
TallaVestuario
Talla de vestuario.
Tabla 5: Atributos y descripción de la tabla conductor.
Salida
Atributo Descripción
IdCamion
Identificador del Camión.
IdChofer
Identificador de Conductor.
IdAyudante
Identificador de Ayudante.
Fecha
Fecha de Salida.
Hora
Hora de Salida.
Kilometraje
Kilometraje del vehículo.
Observación
Observación que se desee ingresar.
Destino
Destino del vehículo.
Tabla 6: Atributos y descripción de la tabla Salida.
53
Entrada
Atributo Descripción
IdCamion
Identificador del Camión.
IdChofer
Identificador de Conductor.
IdAyudante
Identificador de Ayudante.
Fecha
Fecha de Entrada.
Hora
Hora de Entrada.
Kilometraje
Kilometraje del vehículo.
Observación
Observación que se desee ingresar.
Tabla 7: Atributos y descripción tabla Entrada.
Camión
Atributo
Descripción
Patente
Patente del Vehículo.
Marca
Marcha del Vehículo.
Modelo
Modelo del Vehículo.
Año
Año del Vehículo.
54
Kilometraje
Kilometraje del Vehículo.
RevisiónTécnica
Fecha de vencimiento de Revisión
Técnica.
CambioAceite
Fecha de Vencimiento de Cambio de
Aceite.
NumChasis
Número de Chasis del Vehículo.
NumMotor
Número de motor del vehículo.
Tabla 8: Atributos y descripción tabla Camión.
Carga
Atributo Descripción
IdCamion Identificador del Camión.
IdChofer Identificador de Conductor.
IdServicentro
Identificador Servicentro.
Fecha Fecha de Salida.
Hora Hora de Salida.
Kilometraje Kilometraje del vehículo.
NumGuía Número de guía de carga.
Litros Litros Cargados
ValorUnitario Valor Unitario de cada litro.
Ciudad Ciudad donde se realizó la carga.
Tabla 9: Atributos y descripción s tabla Carga.
55
Mantención
Atributo Descripción
IdCamion
Identificador del Camión.
IdMecanico
Identificador de Mecánico.
FechaEntrada
Fecha de Entrada al taller.
FechaSalida
Fecha de Salida del taller.
Kilometraje
Kilometraje del vehículo.
Observación
Observación que se desee ingresar.
DesProblema
Descripción del problema que presenta.
Tabla 10: Atributos y descripción de tabla Mantención.
Servicentro
Atributo Descripción
Nombre
Nombre de Servicentro.
Tabla 11: Atributos y descripción de tabla Servicentro.
56
Repuesto
Atributo Descripción
IdFamilia
Identificador de la familia a la que pertence.
IdProveedor
Identificador de Proveedor.
Código
Código del repuesto.
Nombre
Nombre del repuesto.
Medida
Unidad de Medida del repuesto.
Cantidad
Cantidad de stock.
Valor
Valor de la unidad.
Tabla 12: Atributos y descripción de la tabla Repuesto.
Familia
Atributo Descripción
IdRubro
Identificador del rubro al que pertenece.
Nombre
Nombre de Familia.
Tabla 13: Atributos y descripción de tabla Familia.
57
Rubro
Atributo Descripción
Nombre
Nombre de Rubro.
Tabla 14: Atributos y descripción de tabla Rubro.
Mecánico
Atributo Descripción
Nombre
Nombre de Mecánico.
Rut
Rut del Mecánico.
Sueldo
Sueldo del Mecánico.
Telefono
Teléfono de contacto.
NumCalzado
Número de Calzado.
TallaVestuario
Talla de Vestuario.
Tabla 15: Atributos y descripción tabla Mecánico.
58
Proveedor
Atributo Descripción
Nombre
Nombre de Proveedor.
Rut Número de Rut.
Telefono
Número de teléfono.
Dirección
Dirección del proveedor.
Tabla 16: Atributos y descripción de tabla Proveedor.
Herramienta
Atributo Descripción
Nombre
Nombre de Herramienta.
Código
Código de Herramienta.
Cantidad
Cantidad de herramientas en stock.
Valor
Valor Unitario
Tabla 17: Atributos y descripción de tabla Herramienta.
59
7.2.4 Diagrama de Entidad-Relación
Figura 16: Diagrama Entidad-Relación.
60
7.3 Modelo Lógico de Datos
7.3.1 Transformación del Modelo Conceptual al Modelo Lógico
Una vez que se tiene el modelo conceptual de datos, se debe obtener el
modelo lógico de datos. Para cumplir este objetivo, en general se deben realizar
las siguientes tareas:
• Eliminar relaciones N:N
• Eliminar relaciones complejas
• Eliminar relaciones recursivas
• Eliminar relaciones con atributos
• Eliminar atributos multivalóricos
• Eliminar relaciones 1:1
• Eliminar relaciones redundantes
Viendo el modelo conceptual que se desarrolló en la etapa anterior, se
puede observar que no existe ninguna de las relaciones que se deben eliminar.
Por lo tanto el modelo lógico de datos se puede crear directamente desde el
modelo conceptual.
61
7.3.2 Modelo Físico de datos
7.3.2.1 Transformación del Modelo Lógico al Modelo Físico
El modelo físico de datos es la creación y desarrollo de la base de datos
de la aplicación. Para este sistema se decidió utilizar el motor de base de datos
MySQL versión 5.5.24, ya que es un motor Open Source y tiene características
que la hacen un herramienta fácil de utilizar y de migrar en caso que sea
necesario. Además tiene compatibilidad con gran cantidad de lenguajes de
programación en caso que se necesite agrandar la base de datos y realizar otra
aplicación.
7.3.2.2 Tipos de datos
Ayudante
Atributo Descripción Tipo Restricción Valor Nulo
Nombre
Nombre del
Ayudante.
Varchar(40) No No
Rut
Rut del
Ayudante.
Varchar(12) No No
Sueldo
Sueldo del
Ayudante.
Varchar(10) No No
62
Teléfono
Teléfono de
contacto.
Varchar(15) No No
NumCalzado
Número de
calzado.
Integer No No
TallaVestuario
Talla de
vestuario.
Varchar(5) No No
Tabla 18: Atributos y características de la tabla ayudante.
Conductor
Atributo Descripción Tipo Restricción Valor Nulo
Nombre
Nombre del
Conductor.
Varchar(40) No No
Rut
Rut del
Conductor.
Varchar(12) No No
Sueldo
Sueldo del
Conductor.
Varchar(10) No No
Teléfono
Teléfono de
contacto.
Varchar(15) No No
NumCalzado
Número de
calzado.
Integer
No
No
TallaVestuario
Talla de
vestuario.
Varchar(5) No No
Tabla 19: Atributos y características de la tabla conductor.
63
Salida
Atributo Descripción Tipo Restricción Valor Nulo
IdCamion
Identificador
del Camión.
Integer
No No
IdChofer
Identificador de
Conductor.
Integer
No No
IdAyudante
Identificador de
Ayudante.
Integer
No No
Fecha
Fecha de
Salida.
Date
No No
Hora
Hora de Salida.
Time
No No
Kilometraje
Kilometraje del
vehículo.
Integer
No No
Observación
Observación
que se desee
ingresar.
Text
No
No
Destino
Destino del
vehículo.
Varchar(50)
No
No
Tabla 20: Atributos y características de la tabla Salida.
Entrada
Atributo Descripción Tipo Restricción Valor Nulo
IdCamion
Identificador
del Camión.
Integer
No No
IdChofer
Identificador de
Conductor.
Integer
No No
IdAyudante
Identificador de
Ayudante.
Integer
No No
64
Fecha
Fecha de
Entrada.
Date
No No
Hora Hora de
Entrada.
Time
No No
Kilometraje
Kilometraje del
vehículo.
Integer
No
No
Observación
Observación
que se desee
ingresar.
Text
No
No
Tabla 21: Atributos y características tabla Entrada.
Camión
Atributo Descripción Tipo Restricción Valor Nulo
Patente
Patente del
Vehículo.
Varchar(7)
No
No
Marca
Marcha del
Vehículo.
Varchar(20)
No
No
Modelo
Modelo del
Vehículo.
Varchar(20)
No
No
Año
Año del
Vehículo.
Varchar(4)
No
No
Kilometraje
Kilometraje del
Vehículo.
Time
No
No
RevisiónTécnica
Fecha de
vencimiento de
Revisión
Técnica.
Date
No
No
65
CambioAceite
Fecha de
Vencimiento de
Cambio de
Aceite.
Date
No
No
NumChasis
Número de
Chasis del
Vehículo.
Integer(20)
No
No
NumMotor
Número de
motor del
vehículo.
Integer(20)
No
No
Tabla 22: Atributos y características tabla Camión.
Carga
Atributo Descripción Tipo Restricción Valor Nulo
IdCamion
Identificador
del Camión.
Integer
No No
IdChofer
Identificador de
Conductor.
Integer
No No
IdServicentro
Identificador
Servicentro.
Integer
No No
Fecha
Fecha de
Salida.
Date
No No
Hora
Hora de Salida.
Time
No No
Kilometraje
Kilometraje del
vehículo.
Integer
No
No
66
NumGuía
Número de
guía de carga.
Varchar(20)
No
No
Litros
Litros
Cargados
Float
No
No
ValorUnitario
Valor Unitario
de cada litro.
Integer
No
No.
Ciudad
Ciudad donde
se realizó la
carga.
Varchar(20)
No
No
Tabla 23: Atributos y características tabla Carga.
Mantención
Atributo Descripción Tipo Restricción Valor Nulo
IdCamion
Identificador
del Camión.
Integer
No No
IdMecanico
Identificador de
Mecánico.
Integer
No No
FechaEntrada
Fecha de
Entrada al
taller.
Date
No
No
FechaSalida
Fecha de
Salida del
taller.
Date
No
No
Kilometraje
Kilometraje del
vehículo.
Integer
No No
67
Observación
Observación
que se desee
ingresar.
Text
No
No
DesProblema
Descripción del
problema que
presenta.
Text
No
No
Tabla 24: Atributos y características de tabla Mantención.
Servicentro
Atributo Descripción Tipo Restricción Valor Nulo
Nombre
Nombre de
Servicentro.
Varchar(30)
No
No
Tabla 25: Atributos y características de tabla Servicentro.
Repuestos
Atributo Descripción Tipo Restricción Valor Nulo
IdFamilia
Identificador de
la familia a la
que pertence.
Integer
No
No
IdProveedor
Identificador de
Proveedor.
Integer
No
No
Código
Código del
repuesto.
Integer
No
No
Nombre
Nombre del
repuesto.
Varchar(40)
No
No
68
Medida
Unidad de
Medida del
repuesto.
Varchar(20)
No
No
Cantidad
Cantidad de
stock.
Integer
No
No
Valor
Valor de la
unidad.
Integer
No
No
Tabla 26: Atributos y características de la tabla Repuesto.
Familia
Atributo Descripción Tipo Restricción Valor Nulo
IdRubro
Identificador
del rubro al
que pertenece.
Integer
No
No
Nombre
Nombre de
Familia.
Varchar(50)
No
No
Tabla 27: Atributos y características de tabla Familia.
Rubro
Atributo Descripción Tipo Restricción Valor Nulo
Nombre
Nombre de
Rubro.
Varchar(50)
No
No
Tabla 28: Atributos y características de tabla Rubro.
69
Mecánico
Atributo Descripción Tipo Restricción Valor Nulo
Nombre
Nombre de
Mecánico.
Varchar(30)
No
No
Rut
Rut del
Mecánico.
Varchar(12)
No
No
Sueldo
Sueldo del
Mecánico.
Integer
No
No
Telefono
Teléfono de
contacto.
Integer
No
No
NumCalzado
Número de
Calzado.
Integer
No
No
TallaVestuario
Talla de
Vestuario.
Varchar(3)
No
No
Tabla 29: Atributos y características tabla Mecánico.
Proveedor
Atributo Descripción Tipo Restricción Valor Nulo
Nombre
Nombre de
Proveedor.
Varchar(50)
No
No
Rut Número de
Rut.
Varchar(15)
No
No
Telefono Número de
teléfono.
Varchar(15)
No
No
Dirección Dirección del
proveedor.
Varchar(30)
No
No
Tabla 30: Atributos y características de tabla Proveedor.
70
Herramienta
Atributo Descripción Tipo Restricción Valor Nulo
Nombre
Nombre de
Herramienta.
Varchar(50)
No
No
Código
Código de
Herramienta.
Integer
No
No
Cantidad
Cantidad de
herramientas
en stock.
Integer
No
No
Valor
Valor Unitario
Varchar(11)
No
No
Tabla 31: Atributos y características de tabla Herramienta.
SalidaElemento
Atributo Descripción Tipo Restricción Valor Nulo
IdPersonal
Identificador
del Personal.
Integer
No
No
IdRepuesto
Identificador
del elemento.
Integer
No
No
Cantidad
Cantidad de
elementos
entregados.
Integer
No
No
Fecha
Fecha de la
entrega.
Date
No
No
Tabla 32: Atributos y características de tabla SalidaElemento.
71
SalidaRepuesto
Atributo Descripción Tipo Restricción Valor Nulo
IdCamion
Identificador
del Camión.
Integer
No
No
IdRepuesto
Identificador
del repuesto.
Integer
No
No
Cantidad
Cantidad de
repuestos
entregados.
Integer
No
No
Fecha
Fecha de la
salida.
Date
No
No
Tabla 33: Atributos y características de la tabla SalidaRepuesto.
Usuario
Atributo Descripción Tipo Restricción Valor Nulo
NomUsuario
Nombre del
Usuario.
Varchar(20)
No
No
Password
Contraseña del
usuario.
Varchar(6)
No
No
Perfil
Perfil del
Usuario.
Integer
No
No
Tabla 34: Atributos y características de la tabla Usuario.
72
7.3.3 Claves Primarias y Foráneas
Tabla Clave Primaria Clave Foránea
Ayudante IdAyudante No
Camión IdCamión No
Carga
IdCarga
IdServicentro
IdCamión
IdChofer
Chofer IdChofer No
Entrada
IdEntrada
IdCamión
IdChofer
IdAyudante
Familia IdFamilia IdRubro
Herramienta IdHerramienta No
Mantención IdMantención IdCamión
IdMecánico
Mecánico IdMecánico No
Proveedor IdProveedor No
Repuesto IdRepuesto IdFamilia
IdProveedor
Rubro IdRubro No
Salida IdSalida IdCamión
IdChofer
IdAyudante
SalidaElemento IdSalidaElemento IdRepuesto
IdPersonal
SalidaRepuesto IdSalidaRepuesto IdRepuesto
IdCamión
Servicentro IdServicentro No
Usuario IdUsuario No
Tabla 35: Tablas, sus claves primarias y foráneas.
73
7.4 Diseño de Interfaz de Usuario
7.4.1 Requerimientos del Cliente
Para la aplicación que se desea realizar el cliente no tenía grandes
requerimientos. Principalmente lo que requería era una plataforma que sea algo
agradable a la vista, que no aburra luego de utilizarla un tiempo considerable, y
que sea fácil de utilizar, que no se requiera tener grandes conocimientos, que
sea intuitivo.
7.4.2 Prototipo de Interfaz propuesta
Teniendo en cuenta lo anterior, se utilizó un software para confeccionar un
prototipo de la interfaz de la aplicación. De esta forma se crearon todas las
pantallas que tendría la aplicación con cada uno de los elementos cubriendo
todas las necesidades.
Así se tuvo de una forma rápida y más precisa que es lo que la empresa
quería para su interfaz y se pudo llegar al objetivo. A continuación se presentan
algunas de las pantallas del prototipo presentadas en la reunión. (Ver Figuras
17, 18 y 19).
74
Figura 17: Prototipo pantalla de mantenciones.
Figura 18: Prototipo pantalla Ingreso de existencia.
75
Figura 19: Prototipo pantalla Entrada-Control de acceso.
76
8 Desarrollo de la Plataforma
8.1 Modelo de Clases del Framework
El modelo de clases es el diagrama principal para el análisis de diseño.
Presenta las clases que serán utilizadas dentro del sistema y las relaciones
que existen entre ellas.
En las clases, se muestra detalladamente el nombre de la clase, los
atributos y las operaciones o métodos que éstas tienen. En el caso de las
relaciones, éstas pueden ser de herencia, de composición, de agregación,
dependencia y asociación.
En este caso, se presenta el diagrama de clases que se creó para la
aplicación presentando las relaciones existentes entre las diversas clases de la
aplicación, y los atributos y métodos que tienen estas clases.
77
Figura 20: Modelo de Clases, parte 1.
78
Figura 21: Modelo de Clases, parte 2.
79
8.2 Zend Framework
8.2.1 Características Principales del Framework
Zend es un framework de código abierto para desarrollar aplicaciones y
servicios web utilizando PHP 5.3 o mayores. Zend utiliza 100% código orientado
a objetos y utiliza la mayor parte de las nuevas características de PHP 5.3.
Ofrece un conjunto robusto y de alto rendimiento de la aplicación MVC,
una abstracción de base de datos que es simple de usar y un componente de
formularios que implementan HTML5 que usan validaciones y filtros.
Zend Framework tiene un directorio organizado de la siguiente forma:
• Application
o Controllers
o Models
� DbTable
o Views
� Filters
� Helpers
� Scripts
80
• Library
• Public
o Images
o Scripts
o Styles
En la carpeta Controllers se guardan todos los controladores del sistema,
en la carpeta DbTable que se encuentra dentro de la carpeta Models se crean
los modelos que son los que realizan las consultas a la base de datos, en la
carpeta Scripts que está dentro de la carpeta Views, van los archivos de las
vistas.
Por último en la carpeta Public, se encuentran las carpetas Images,
Scripts y Styles, que es donde se guardan las imágenes, javascripts y css
respectivamente.
81
8.2.2 Comparación con otros Framework para PHP
Zend, en general tiene características muy similares a otros framework
para PHP. Sin embargo, tiene algunas cosas que se puede realizar de una
forma más sencilla, mientras otras pueden resultar bastante más complejas de
realizar comparándolo con otros framework. Todo esto se podrá ver más
adelante cuando se comente el desarrollo de la aplicación.
A continuación se puede ver un cuadro comparativo de Zend con otros
framework, donde se ven las diferentes características que estos pudieran o no
soportar.
Figura 22: Tabla comparativa de Zend con otros framework.
82
8.3 Control de Versiones con SVN
Una buena práctica para el desarrollo de una aplicación es el control de
versiones, es decir, controlar las modificaciones que se le hacen a los archivos
por si se desea deshacer algún cambio. Para esto se desea utilizar Subversión,
quien trabaja replicando el modelo cliente-servidor.
Uno o más clientes se conectan a un servidor que tiene la última copia del
proyecto, como también copia de sus versiones anteriores, lo que se llama
repositorio. El cliente pide la última versión disponible para trabajar y luego que
se realizan los cambios, se sincronizan las copias con el repositorio.
Existen operaciones:
• “svn checkout”: obtiene una copia local de la última versión.
• “svn update”: indica los cambios que existen entre la copia de
trabajo y la copia del repositorio.
• “svn status”: muestra los ficheros donde existen cambios.
• “svn commit”: envía al repositorio los cambios que se hicieron en la
copia de trabajo.
83
8.4 Primera Iteración
8.4.1 Creación del Layout de la Interfaz
Layout es una palabra que se utiliza en el desarrollo web para denominar
la estructura que se define para una página web. Un layout es una plantilla que
se presenta en tablas o espacios en blancos desde la cual el sitio web se
comienza a desarrollar.
Para el presente proyecto se realizó un layout en el cual se tiene el título
de la página web, el menú principal que va variando dependiendo del contenido
del sitio, y el contenido propiamente tal.
En el primer caso, se tiene el layout de la página de inicio la cual consta
solamente de un título y el contenido. No tiene un menú navegable. A
continuación se presenta una imagen donde se ve con mayor claridad. (Ver
Figura 21).
84
Figura 23: Layout página de inicio.
Para poder tener este código fuente se tuvo que programar una página
PHP la cual tiene cierta estructura donde se encuentra el header (parte superior
del sitio), los script de javascript que fueron utilizados, el cuerpo de página y el
pie de página.
En la imagen que se presenta a continuación se puede ver parte del
código que se utilizó para desarrollar el layout que se mostró en la imagen
anterior. (Ver Figura 22).
85
Figura 24: Parte de código Layout.
Además en el layout se debieron crear dos menús. Un menú para la
sección del taller mecánico de la empresa, y otro menú para el control de
acceso de la planta.
Estos menús permiten navegar por las distintas páginas de las secciones
según corresponda, permitiendo así llegar al usuario de forma directa y rápida a
cualquier funcionalidad que este requiera. A continuación se pueden ver los
distintos menús. (Ver Figura 23 y 24).
86
Figura 25: Layout y menú control de acceso.
Figura 26: Layout y menú taller mecánico.
8.4.2 Desarrollo Control de Usuarios
En esta parte del proyecto se debió desarrollar un controlador
(UsuarioController), un modelo (tabla Usuario de la base de datos), un form
(Usuario) y la vista en la cual se muestra el formulario.
El controlador tiene una función llamada “loginAction” la cual es la que se
encarga de verificar que el nombre de usuario y la contraseña estén
correctamente ingresados, para que así pueda ingresar a la plataforma. De
modo contrario muestra un mensaje de error. (Ver Figura 25).
87
Figura 27: Parte código función login.
En el form se crea el formulario en cual se solicita el nombre de usuario,
la contraseña para que pueda ingresar al sitio y el botón “ingresar” con el cual
se enviará la información ingresada al controlador para verificar que los datos
son correctos. A continuación se puede ver el código del form desarrollado. (Ver
Figura 26).
88
Figura 28: Código Form Usuario.
Finalmente se creó la vista “login” para los usuarios, en la cual se muestra
junto con el layout, el form creado anteriormente. La vista final que se presenta
al usuario se puede ver a continuación.
89
Figura 29: Vista login usuario.
8.4.3 Creación Módulo Control de Acceso
Para el desarrollo de este módulo de la aplicación se debieron utilizar dos
controladores (EntradaController y SalidaController), además de las respectivas
tablas de la base de datos (Entrada y Salida). Junto a esto, se debió desarrollar
un form para cada controlador (form Entrada y form Salida) y las vistas
correspondientes para mostrar cada formulario.
En ambos controladores se definieron distintas acciones: indexAction,
addAction, editAction, deleteAction y buscarAction, en las cuales se realizan
distintas acciones según la necesidad.
90
A continuación se muestra parte del código de EntradaController. Cabe
mencionar que el controlador de Salida, se desarrolló de forma similar al de
entrada por lo que no se mostrará parte de su código. (Ver Figura 28).
Figura 30: Parte código EntradaController.
También se crearon los form de Entrada y Salida, para así poder mostrar
los formularios correspondientes cuando se quieran ingresar a la plataforma la
información de uno u otro.
91
Ambos formularios se diferencian únicamente en que el formulario de
Salida requiere un campo más para poder registrar el destino que tendrá el
vehículo que va saliendo del recinto. A continuación se puede ver parte del
código del formulario Salida.
Figura 31: Parte código formulario Salida.
92
Para poder mostrar en un ComboBox una lista de por ejemplo la patente
de los camiones que están ingresados en la base de datos, en primer lugar se
deben obtener todos los camiones y sus patentes, lo cual se hace con el
método “getCamionList”. Luego, al momento de crear el ComboBox o Select, se
le pasa esta lista de camiones como parámetro a la función “addMultiOptions”.
Finalmente se desarrolló la interfaz donde se muestran los datos o
formularios que se requieran según las vistas a la cual corresponda (agregar,
editar, eliminar, index o buscar).
De las 5 vistas desarrolladas las dos más importantes y que puede ser
interesante ver son las vistas index y la vista buscar, ya que es en las cuales
hay una mayor cantidad de elementos a considerar. A continuación se
presentará el código de la vista index de Entrada, en el cual se listan todas las
entradas que se han ingresado. (Ver Figura 30).
93
Figura 32: Vista Index, Entrada.
Por último, después de ver todos los archivos que se debieron crear para
realizar este módulo se puede ver cada una de las vistas desarrolladas y que
serán las que finalmente verá el usuario que utilizará el sistema.
94
En primer lugar se tiene la vista index de entrada, el cual muestra la lista
de las entradas ya ingresadas. (Ver Figura 31).
Figura 33: Vista index, Entrada.
Aquí se puede ver una lista con la patente del camión que ingresó, el
conductor, ayudante, kilometraje y la fecha. También se tiene una columna
“editar” la cual muestra el formulario de ingreso, pero con la información de la
entrada para poder editarla, y se tiene una columna “borrar” con la cual se borra
la entrada seleccionada.
Además para ingresar una entrada se tiene la vista agregar. Aquí se
muestra un formulario con distintos campos a rellenar por parte del usuario.
(Ver Figura 32).
95
Figura 34: Vista ingresar Entrada.
Por otro lado, se tiene la vista index de las salidas en dónde se ve la lista
de las salidas ingresadas. Los datos que se ven en esta vista son la patente,
conductor, ayudante, fecha y observación. Además de la columna editar, que
permite realizar las modificaciones de la salida seleccionada y la columna
borrar. (Ver Figura 33).
96
Figura 35: Vista index, Salida.
También se desarrolló la vista agregar salida. Aquí se muestra el
formulario creado anteriormente donde se deben ingresar los datos de la salida
del vehículo, los cuales se insertarán en la base de datos. Estos datos
solicitados son la patente del vehículo, conductor, ayudante, kilometraje del
vehículo, destino, fecha, hora, observación y el botón ingresar, que es el que
envía la información ingresada hacia el controlador, quien es el encargado de
manejar la información en la base de datos, a través de los métodos creados en
el modelo.
A continuación se puede ver la vista de agregar salida, que es la que se
le presenta finalmente al usuario.
97
Figura 36: Vista Agregar, Salida.
Finalmente, se desarrolló la vista buscar tanto como para el controlador
entrada como para el controlador salida. La búsqueda se puede realizar por
fecha, conductor o patente. Los resultados son mostrados en una tabla donde
los datos que se muestran son patente, conductor, kilometraje y fecha de
entrada o salida según corresponda.
En la siguiente imagen se muestra la vista que se presenta finalmente en
la aplicación, la cual es de la misma forma tanto para la entrada como para la
salida de los vehículos.
98
Figura 37: Vista Buscar, Entrada.
99
8.5 Segunda Iteración
8.5.1 Desarrollo Módulo de Inventario
Una funcionalidad de gran importancia para el taller mecánico de la
empresa es el tener controlado de forma instantánea y que refleje lo que
realmente se tiene en el taller es el control del inventario.
Para el control de las existencias, éstas pertenecen a diferentes familias y
su vez, las familias son parte de rubros. Es decir, para el correcto
funcionamiento de esta etapa se utilizaron 3 tablas de la base de datos: rubro,
familia y repuesto.
En cuanto a los controladores, se desarrollaron tres controladores de
acuerdo a cada tabla de la base de datos utilizada: RubroController,
FamiliaController y RepuestoController. En cada controlador están definidas las
funciones para listar, agregar, editar, borrar y buscar cualquiera de estos
elementos a través de la interfaz de usuario.
100
Por otro lado, se crearon los modelos (Rubro, Familia y Repuesto) en los
cuales se establecieron los métodos que interactúan con la base de datos de la
plataforma los cuales permiten insertar, editar, eliminar, o realizar distintas
consultas.
Además se desarrolló las vistas necesarias para que el usuario pueda
utilizar cada una de funcionalidades que tiene la plataforma. En otras palabras,
se crearon cada una de las vistas necesarias, las cuales envían la información
al controlador y este permite el paso de información entre la base de datos y la
vista correspondiente.
En la imagen (Ver Figura 36) se puede ver parte del código del controlador
rubro, donde se encuentran las funciones “indexAction”, “buscarAction”,
“addAction”, “editAction” y “deleteAction”. Cada una de estas funciones realiza
acciones en la base de datos a través de diferentes métodos definidos en el
DbTable Rubro, el cual es parte del modelo.
101
Figura 38: Parte de Controlador Rubro.
Luego que se tiene creado el controlador, se desarrollaron cada una de las
vistas para que el usuario pueda utilizar las funcionalidades. Estas vistas son:
index, add, edit, delete y buscar.
102
En la imagen (Ver Figura 37) se presenta el código de la vista index de
rubro en la cual se listan los rubros existentes en la base de datos. Se realiza
un foreach para recorrer los rubros, y luego se muestra el nombre de éste.
Además se agrega una columna para editar y otra para borrar, en las
cuales se entrega como parámetro el identificador del rubro para que se puedan
realizar estas acciones en la base de datos.
Figura 39: Vista index, rubro.
103
Finalmente, el resultado de todo lo anterior que se traduce en la interfaz
que se le presenta al usuario se ve en la imagen siguiente:
Figura 40: Lista de rubros. Vista index.
De forma similar se implementa también la vista para agregar un rubro en
la base de datos. Se crea en el controlador la función “add” que es quién
obtiene los datos del formulario “Rubro” y a través del método “addRubro” que
fue implementado en el modelo DbTable “Rubro”, inserta los datos en la base
de datos de la aplicación.
104
A continuación se puede ver el código de la función “addAction” del
controlador rubro.
Figura 41: Función add, RubroController.
Ahora, se presenta el formulario para ingresar rubro que se le presenta
finalmente al usuario:
105
Figura 42: Vista add, RubroController
De la misma forma que se ha descrito anteriormente, creando las
funciones en el controlador las cuales obtienen la información y utilizan métodos
creados en el modelo de datos, se muestran las vistas correspondientes tanto
para editar, eliminar y buscar.
El código de estas funciones y vistas no se mostrará detalladamente
como si se ha hecho con las otras funciones ya que son creadas y se utilizan de
igual manera que las ya mostradas, por lo que solamente se mostrará cual es el
resultado final del desarrollo.
106
En primer lugar, para editar un rubro luego de que se listan y se presiona
en “editar” la vista para el usuario es la siguiente:
Figura 43: Vista editar Rubro.
Luego, para eliminar un rubro determinado se presiona en “eliminar” de la
fila correspondiente al rubro seleccionado, y aparece el mensaje de
confirmación para el usuario.
Figura 44: Vista Eliminar Rubro.
107
Y por último, para que un usuario pueda buscar un rubro correspondiente
la vista que se le presenta es la siguiente:
Figura 45: Vista Buscar rubro.
Aquí, el usuario puede buscar por el nombre del rubro (o parte de éste) y
luego se le presenta una lista con todas las coincidencias que se encontraron
en la tabla “Rubro” de la base de datos.
Luego de esto, de la misma forma que se implementó la sección para
manejar la información de los rubros, se desarrolló la sección para agregar,
editar, eliminar y buscar las familias de los rubros en la base de datos.
108
Se utilizaron los controladores respectivos en los cuales se crearon las
funciones que permitían la interacción con la base de datos a través de los
modelos que corresponden. Junto a esto, se crearon cada una de las vistas
para que los usuarios puedan interactuar con la plataforma. A continuación se
presentan los resultados de cada una de las vistas.
Figura 46: Vista index familia.
Para agregar familia se debe selección el rubro al cual pertenece y luego
se debe ingresar el nombre de la familia.
109
Figura 47: Vista agregar familia.
En cuanto a la sección de los repuestos, se desarrolló de la misma forma
que las secciones anteriores. Se creó el controlador “repuesto” el cual se
encarga de la conexión con el modelo de datos. Se encuentran definidas las
funciones indexAction, buscarAction, addAction, editAction y deleteAction.
Además se creó un formulario “Repuesto” el cual es el que se le muestra
en la vista “add” al usuario para que pueda agregar a la base de datos un nuevo
repuesto.
110
Y Luego, para que el usuario pueda interactuar en el sistema se debieron
crear las vistas respectivas para cada acción. Por lo tanto se crearon las vistas
index, add, edit, delete y buscar.
La vista index es la que muestra la lista de los repuestos que se
encuentran en la base de datos. Los datos mostrados en esta lista son: número
de factura, familia, nombre repuesto, cantidad, valor unidad y total. Además de
las columnas que permiten editar y borrar algún repuesto en específico. (Ver
Figura 46).
Figura 48: Vista index repuestos.
111
Luego para agregar un repuesto que haya sido comprado a la base de
datos de la aplicación se presenta un formulario donde se deben ingresar todos
los campos solicitados. (Ver Figura 47).
Figura 49: Vista agregar repuesto.
Por último, para buscar algún repuesto en nuestra base de datos se creó
otra vista donde se puede buscar ya sea por familia, nombre de repuesto o
número de factura.
112
Esto es llevado a través del controlador hacia el modelo de datos, donde
por medio de la función “getRepuesto” (Ver Figura 48) se obtienen el o los
resultados de la operación.
Figura 50: Código función getRepuesto, Modelo de datos.
113
Finalmente, se tiene la vista que se le muestra al usuario para que pueda
realizar la búsqueda mencionada anteriormente. (Ver Figura 49).
Figura 51: Vista buscar repuesto.
Además a solicitud del jefe del taller mecánico de la empresa, quién será
el principal usuario de esta plataforma, en este módulo se implementó una
sección en la cual se ingresarán las “salidas de repuestos”. Es decir, se
ingresarán los repuestos que han sido ocupados, por lo tanto han sido restados
del inventario de la base de datos.
114
Entonces, en esta sección se tiene la siguiente vista que permite tener
actualizado el control del inventario del taller mecánico. (Ver Figura 50).
Figura 52: Vista Salida Repuesto.
Esta parte funciona de la misma forma que las anteriores, utilizando el
controlador respectivo que se conecta con el modelo de datos, insertando la
información entregada por el usuario en el formulario visto anteriormente.
115
8.5.2 Implementación Módulo de Mantenciones
Este módulo, junto al anterior, es uno de los de mayor importancia para la
empresa ya que es aquí donde tendrán controlada las mantenciones y los
gastos que genera cada vehículo para la empresa.
En primer lugar se creó el controlador “Mantención” donde están
definidas las funciones buscarAction, fichaAction, indexAction, addAction,
editAction y deleteAction.
En el controlador es donde se conecta con el modelo de datos, que es
donde están implementados los métodos que insertan, eliminan o realizan
consultas a la base de datos.
En la imagen que viene a continuación (Ver Figura 51) se puede ver
parte del código del controlador Mantención, específicamente el código de la
función buscar. Se ve que se obtiene la información que se quiere buscar, el
criterio por cual se desea buscar y luego se hace un llamado al método
getMantencion del modelo de datos (Mantención).
116
Figura 53: Parte de código controlador de mantención.
Luego, para poder listar las mantenciones que se encuentran en la base
de datos se utiliza la función del controlador “indexAction”. Además se
desarrolló un método en el modelo de datos “Mantención” el cual permite
obtener estas mantenciones llamado “getMantencion”.
117
Finalmente la vista index donde se presentan las mantenciones que ya
están en la base de datos, se presenta a continuación.
Figura 54: Vista index, mantención.
Además, a través de esta vista el usuario tiene acceso a editar la
información de la mantención que desee, eliminar alguna mantención en
particular o ver la ficha de alguna mantención en específica, haciendo click
sobre la patente de la mantención correspondiente.
118
Para ver la ficha de la mantención se creó la función ficha en el
controlador, la cual a través del método “getMantencion” definida en el modelo
de datos, obtiene los datos de una mantención en particular. En este método se
realizan distintos joins para poder obtener los datos necesarios para el usuario.
Figura 55: Código función getMantencion.
La vista que tiene el usuario en la ficha de la mantención es la que viene
a continuación, donde se puede ver detalladamente el mecánico que participó
en esta, la fecha de entrada, la fecha de salida, repuestos utilizados, etc.
119
Figura 56: Vista ficha mantención.
Por otro lado, para que se puedan agregar mantenciones a la aplicación
se debió crear un formulario al cual se le dio el nombre de “Mantenciones”. Aquí
se encuentran label, select, element text, element textArea y un botón para
poder dar solución a los requerimientos.
120
La vista del formulario para que el usuario pueda insertar una nueva
mantención es la siguiente:
Figura 57: Formulario agregar mantención.
Por último, se implementó la funcionalidad de buscar mantención. Para
esto se definió la función buscar en el controlador la cual utiliza la función
“getMantencion” del modelo de base de datos. (Ver Figura 56).
121
Figura 58: Código función getMantencion.
122
El usuario puede buscar por tres criterios: patente de vehículo, mecánico
que realizó la mantención o fecha de entrada al taller mecánico. Finalmente la
vista para realizar la búsqueda es la siguiente:
Figura 59: Vista buscar mantención.
Aquí el resultado que arroja es una lista con la o las coincidencias
encontradas donde se muestra la patente, fecha de entrada, fecha de salida y
mecánico. Además se puede revisar la ficha mostrada anteriormente de cada
uno de los resultados encontrados.
123
8.5.3 Creación Módulo Control de Carga de Combustible
Este módulo es el encargado de controlar la información que tiene relación
con la carga de combustibles a los vehículos de la empresa.
Para el desarrollo de este módulo se creó un controlador llamado
CargaController en el cual están definidas varias funciones. En primer lugar
está indexAction la cual permite listar las cargas que se han ingresado a la base
de datos. Para eso utiliza la función getCarga (Ver Figura 58) que se encuentra
definida en el modelo de datos, y la cual se encarga de obtener desde la base
de datos cada una de la cargas.
Figura 60: Función getCarga.
124
Luego de obtener la información de la base de datos, se entrega la
información a la vista index (Ver Figura 59 y 60), la cual se encarga de
mostrársela al usuario.
Figura 61: Parte de código vista index carga de combustible.
125
Figura 62: Interfaz vista index, carga de combustible.
Como se puede ver en la imagen, se muestra el servicentro en el cual fue
realizada la carga, la patente, kilometraje, conductor, fecha, número de guía,
cantidad de litros, valor del litro y costo total de la carga. Además de la columna
para poder editar o eliminar alguna carga en específica.
Otra función que se encuentra en el controlador es “addAction”. Esta
función es la que se encarga de insertar en la base de datos la carga ingresada
por el usuario utilizando la función addCarga del modelo de datos. (Ver Figura
61).
126
Figura 63: Código función addCarga.
Entonces, el formulario que ve el usuario para poder ingresar una carga
de combustible a la plataforma es el siguiente:
Figura 64: Vista agregar carga de combustible.
127
Y por último, otra función que se creó en el controlador Carga es
“buscarAction”. Esta función se encarga de buscar en la base de datos la
información ingresada por el usuario, a través de la función “getCarga”. La
función “getCarga” busca en la base de datos la información que el usuario
desea y según el criterio que éste ha ingresado.
Luego la información es pasada a la vista a través del controlador. El
código de la vista buscar es el siguiente:
Figura 65: Código vista buscar carga de combustible.
128
Luego, los resultados son mostrados en una tabla donde se muestra el
servicentro, patente, conductor, fecha, guía, litros y valor del litro. A
continuación se muestra el código de la vista.
Figura 66: Código resultados de búsqueda de carga.
129
Finalmente, se obtiene la vista que se le presenta al usuario para que
pueda realizar la búsqueda que necesita. (Ver Figura 65).
Figura 67: Vista buscar carga de combustible.
130
8.5.4 Desarrollo Módulo de Administración
En este módulo de la aplicación, el usuario puede crear, editar y eliminar
camión, ayudante, conductor, mecánico, herramienta y proveedor de la
empresa.
Primero, para poder realizar cada una de las acciones de un camión se
debió crear un controlador para éste, llamándole CamiónController. En este
controlador se encuentran definidas las funciones buscarAction, fichaAction,
indexAction, addAction, editAction, alertaAction y deleteAction.
La función indexAction se comunica con el modelo de datos (Camiones) y
ahí se obtienen todos los camiones que se encuentran en la base de datos.
Luego se comunica con la vista que es donde se muestra la lista de camiones.
El código de la vista index se puede ver en la imagen que se presenta a
continuación:
131
Figura 68: Código vista index camiones.
Luego, este código da como resultado la interfaz que se le presenta al
usuario que se puede ver en la siguiente imagen:
Figura 69: Interfaz lista de camiones.
132
En esta lista, se tiene la patente, marca y modelo del vehículo, además
de dos columnas que nos permiten editar o borrar la información del vehículo
que se desee.
También en esta interfaz se tiene la posibilidad de llegar a la ficha de un
vehículo donde se muestran los principales datos del vehículo junto con las
mantenciones que se le han realizado. Para esto se creó la función fichaAction
en el controlador del camión. Esta función va a realizar una consulta al modelo
de datos a través de la función getCamion (Ver Figura 68) que se encuentra
definida en el DbTable Camiones.php.
Figura 70: Función getCamion.
133
De esta forma, se obtiene la vista de la ficha de cada camión la cual se
puede ver en la siguiente imagen.
Figura 71: Vista ficha camión.
Otra función que se encuentra definida en CamionController es
addAction. Esta función es la que se encarga de agregar un nuevo camión a la
base de datos. Para eso se creó un formulario llamado Camión que solicita
patente, marca, modelo, año, kilometraje, fecha de revisión técnica, fecha de
cambio de aceite, número de chasís y número de motor del vehículo.
Además se creó la función addCamión en el modelo de datos
Camiones.php, la cual se encarga de insertar la información de cada uno de los
campos en la base de datos.
134
Luego, se debió desarrollar la vista para poder obtener la interfaz la cual
es presentada al usuario y desde la cual se realiza cada una de las acciones.
(Ver Figura 70).
Figura 72: Vista Agregar Camión.
También para los camiones se decidió desarrollar una vista para poder
ver las alertas de los vehículos: vencimiento de revisión técnica y vencimiento
de cambio de aceite. Esta vista es utilizada como página principal del módulo
taller mecánico.
135
Para esto se implementó la función alertaAction en el controlador
Camión, la cual obtiene la lista de todos los camiones que existen en la base de
datos. Después, se desarrolló la vista alerta, en la cual solo se muestran los
vehículos que tienen como fecha de vencimiento de la revisión técnica o cambio
de aceite como máximo en dos semanas más a contar desde la fecha actual.
Figura 73: Código vista alertas.
136
Luego, la interfaz que se le presenta al usuario como página de inicio del
módulo del taller mecánico es la siguiente.
Figura 74: Interfaz vista Alerta.
Junto a lo anterior, en la sección de administración se puede crear,
editar, eliminar y buscar los conductores de la empresa. Para ello se desarrolló
un controlador de nombre ChoferController. Aquí se implementaron algunas
funciones que permiten realizar las acciones nombradas anteriormente.
137
En primer lugar, se tiene la función indexAction la cual muestra una lista
de los conductores que se han ingresado a la base de datos, junto a sus
principales datos. Esta función se comunica con el modelo de datos a través de
Chofer.php creado en aplication->model->DbTable.
Luego utiliza la vista que se creó en aplication->views->scripts->chofer
llamada index para mostrar los datos obtenidos. Un ejemplo de lo anterior se
muestra en la siguiente imagen:
Figura 75: Vista index conductores.
En esta vista, junto a los datos del conductor se tienen dos columnas las
cuales permiten editar o borrar la información del que se desee.
138
Por otro lado, se debió implementar la función para agregar un nuevo
conductor a la base de datos de la aplicación, la cual se llama addAction (Ver
Figura 74). Esta función obtiene los datos que se ingresan en la vista “add” y
utiliza la función addChofer que se encuentra definida en el modelo de datos
Chofer, para insertar la información en la base de datos.
Figura 76: Función addAction, ChoferController.
139
También se debió crear un formulario en el cual el usuario debe ingresar
la información que se quiere insertar en la base de datos. Este formulario tiene
como nombre Chofer.php, y solicita el nombre, rut, sueldo, teléfono, número de
calzado y talla de vestuario. La interfaz se muestra a continuación:
Figura 77: Interfaz vista agregar conductor.
Junto a esto, se tiene la posibilidad de buscar los conductores que se
encuentran la base de datos. Para realizar esto, se implemento la función
buscarAction en el controlador.
140
Esta función se encarga de realizar la búsqueda en la base de datos a
través de la función getChofer, la cual se encuentra definida en Chofer.php del
modelo de datos.
Luego se debió crear la interfaz necesaria para que el usuario pueda
realizar la búsqueda, donde se le solicita la información que quiere buscar
además del criterio, ya sea el nombre o el rut. (Ver Figura 76).
Figura 78: Vista buscar conductores.
141
Todo lo que se ha realizado anteriormente, se realiza de forma similar
para crear, editar, eliminar o buscar los ayudantes, mecánicos, herramientas o
proveedores de la empresa.
Lo que va cambiando son los nombres de cada uno de los controladores,
modelos de datos, funciones del modelo de datos, y de las vistas de cada uno
de estos, pero en general se implementan y funcionan de la misma forma, por lo
que no se volverá a explicar.
También, los resultados de la interfaz son similares. Son creados de la
misma forma, manteniendo en layout y los formularios.
142
8.6 Tercera Iteración
8.6.1 Creación de Gráficos
Una funcionalidad interesante en la aplicación es que el usuario puede
crear distintos gráficos según lo que desee ver, para así tener de una forma de
comparación entre distintos elementos.
Se decidió implementar dos tipos de gráficos: gráfico de barras y gráficos
de tortas, los cuales pueden ser seleccionados por el usuario al momento de
crear el gráfico.
Los criterios que se pueden graficar son 6: cargas más elevadas en
dinero, los camiones con más mantenciones, las mantenciones más costosas
en dinero, los repuestos más utilizados, los camiones con más tiempo detenidos
en el taller mecánico y los camiones con mayor kilometraje.
Estos gráficos se encuentran implementados en el módulo de control de
combustible. Para esto, se debió crear una función en el controlador de carga
debido a que en este módulo es donde se encuentra implementado, y luego se
debió crear la vista correspondiente para que el usuario pueda seleccionar el
tipo de gráfico y el criterio a graficar. El código de la vista que se le presenta al
usuario es el siguiente:
143
Figura 79: Código vista graficar.
A continuación se puede ver la interfaz a la cual tiene acceso el usuario
para crear el gráfico.
144
Figura 80: Vista graficar.
Luego los datos de esta vista se van hacia el controlador a la función
“graficarAction” (Ver Figura 79), donde a través de otra función llamada
getGrafico definida en el modelo de datos se hacen las consultas necesarias en
la base de datos para obtener el gráfico.
Figura 81: Código función graficarAction.
145
Finalmente, se tiene como resultado el gráfico que selecciona el usuario
como muestra la siguiente figura:
Figura 82: Gráfico, Cargas más elevadas.
146
8.6.2 Pruebas y Corrección de Errores
El objetivo de realizar pruebas es encontrar algún error en la aplicación
para así determinar situaciones en donde algo pasa cuando no debe pasar y
viceversa.
Por este motivo, para encontrar errores en la plataforma se decidió
realizar pruebas de caja negra. Esto, no considera la codificación dentro de sus
parámetros a evaluar, es decir, que no están basadas en el conocimiento del
diseño interno del programa. Estas pruebas se enfocan en los requerimientos
establecidos y en la funcionalidad del sistema.
De esta manera, se realizaron diferentes pruebas para cada uno de los
formularios para comprobar que sucedía lo que realmente debía suceder. De
esta forma se encontraron problemas al momento de ingresar información en
los formularios o al momento de dejarlos en blanco. Los problemas encontrados
y sus soluciones se pasan a describir a continuación.
147
• Ingresar Salida, Control de Acceso: Al momento de ingresar una salida
en el módulo de control de acceso se solicita entre otros datos la fecha y
la hora. Estas en la base de datos se ingresan con un determinado
formato. Al momento que el usuario no ingresaba el formato requerido
por la base de datos la información que se almacenaba quedaba como
00-00-00 y 00:00:00. Para corregir este problema se debió crear un
método que colocara la fecha y la hora en el formato que corresponde.
• Ingresar Entrada, Control de Acceso: Se presenta el mismo problema
que se detallo anteriormente, y se solucionó de la misma forma.
• Agregar Proveedor, Administración: Aquí se solicita nombre, rut, teléfono
y dirección del proveedor. Se debió crear un validador para corroborar
que el rut está escrito correctamente ya que aceptaba cualquier cadena
de números.
• Agregar Mecánico, Administración: Al igual que la función agregar
proveedor, en el formulario se solicita el rut entre otros datos. El
problema era el mismo y fue solucionado de idéntica forma.
148
• Agregar Mantención: En este formulario se encontró el problema que se
solicita la fecha de entrada y fecha de salida del vehículo del taller
mecánico. Si no se ingresaba la fecha en el formato que acepta la base
de datos se ingresaba como fecha 00-00-00. Para solucionar este
problema se utilizó un método que convierta la fecha que se ingresa al
formato utilizado por la base de datos.
• Agregar Conductor: El problema que se presenta en este formulario es el
mismo encontrado en agregar mecánico, es decir, el rut que se solicita
podía no estar en el formato correcto. Por lo tanto se decidió utilizar un
validador para comprobar que el rut este correctamente escrito.
• Agregar Carga de Combustible: El error que se encontró en este
formulario es que se al momento de ingresar la fecha y la hora si no
estaba en el mismo formato que utiliza la base de datos, se ingresaba
como datos 00-00-00 y 00:00, respectivamente. De esta forma se
utilizaron validadores para cerciorarse que el formato de la fecha y la
hora sean correctos.
149
• Agregar Camión: Aquí se encontró que la patente del vehículo aceptaba
cualquier formato, por lo que se comenzó a utilizar un validador y así
asegurarse que la patente este el formato correcto. Además que los
campos correspondientes a fechas: año, revisión técnica y cambio de
aceite, estén ingresados en el formato adecuado para la base de datos.
• Agregar Ayudante: Del mismo modo que agregar conductor, se detectó
un problema al momento de ingresar un rut incorrecto. Por esto se
comenzó a utilizar un validador para tener la seguridad que el formato es
el correcto.
Además en todos los formularios se comprobó lo que sucedía en caso
que se dejará un campo en blanco y se quisiera guardar la información. En
primer lugar, se obtuvo que se llenara de “null” la base de datos. Por este
motivo se decidió colocar mensajes en caso que se encuentren campos vacíos
e impedir que se insertara la información en la base de datos.
150
9 Conclusiones
Cada día la tecnología avanza con mayor rapidez, por lo que cada vez es
más fácil para las empresas hacer uso de elementos sin necesidad de gastar
grandes sumas de dinero.
Dentro del desarrollo de esta aplicación se utilizaron solamente
herramientas Open Source, es decir libres de pago por lo que para la empresa
no significó un gran gasto. Además se utilizó el servidor que la empresa ya
tenía en sus instalaciones, por lo que no tuvieron que comprar un nuevo
hardware.
De esta forma se logró dar solución satisfactoriamente a los problemas y
requerimientos que tenia la empresa para esta plataforma:
• Se controla la cantidad, marca, tipo, valor y otros datos de herramientas y
repuestos del taller.
• Se tiene una ficha de cada vehículo de empresa y una ficha de cada
mantención realizada. Además de controlar datos importantes como la
fecha de revisión técnica y cambios de aceite.
151
• Se controla el acceso de los vehículos en el acceso de la empresa.
• Se generan reportes en formato de gráficos, donde se pueden comparar
datos significativos para la empresa.
El desarrollo de aplicación no tuvo grandes problemas, ya que la
metodología de desarrollo se caracteriza por funcionar muy bien ante los
cambios de forma ágil. El diseño de la arquitectura en capas fue bastante
simple de utilizar y entender, ya que se conocía con anterioridad. Esto además
ayuda de gran forma si se quieren realizar futuras mejoras y modificaciones al
sistema.
El framework utilizado tiene algunas diferencias con otros existentes,
haciendo más difícil y de más bajo nivel algunos procedimientos para lograr
obtener resultados requeridos. Sin embargo, luego de un estudio acabado del
tema se logra entender la forma de funcionamiento de Zend, logrando lo que se
desea.
152
Finalmente, se recomienda seguir trabajando en el sistema para darle
otras funcionalidades que serían interesantes implementar.
Establecer mayor seguridad para la creación de usuarios, indicándole
perfiles y opciones que el usuario pueda o no tener acceso, sería interesante
implementarlo a medida que la empresa vaya creciendo. Esto no era prioridad
actualmente ya que los usuarios que utilizaran el software son sólo de 2 tipos.
Además se recomienda respaldar diariamente ya que nunca se sabe
cuando se podrá necesitar una copia. También, mantener la seguridad de su
servidor utilizando correctamente antivirus y firewall para evitar pérdidas de
información, e incluso un firewall físico.
Por último, ingresar los datos diariamente para que la base de datos y la
aplicación puedan reflejar lo que realmente ocurre en la realidad. Lo hecho
hasta ahora de nada servirá si es que finalmente los datos no reflejan lo que
ocurre en la empresa.
153
10 Bibliografía
[Pavón2008] Pavón, Juan. El patrón Modelo-Vista-Controlador (MVC).
Disponible en:
http://www.fdi.ucm.es/profesor/jpavon/poo/2.14.MVC.pdf
[Canós2007] Canós, José. Metodologías Ágiles en el Desarrollo de Software.
Disponible en:
http://www.willydev.net/descargas/prev/TodoAgil.Pdf
[Fernández2002] Fernández, Gerardo. Introducción a Extreme Programming.
Disponible en:
www.dsi.uclm.es/asignaturas/42551/trabajosAnteriores/Presentacion-XP.pdf
[EugcomInformática] EugCom Informática. Disponible en:
http://www.eugcom.cl/flotas.html
[Inducom] Inducom. Disponible en:
inducom.cl/portal/index.php?option=com_content&task=view&id=28&Itemid=33
154
[CityMovil] CityMovil. Disponible en:
www.citymovil.cl
[WiseTrack] WiseTrack. Disponible en:
http://www.wisetrack.cl/producto.php?id=8
[Sparks2007] Sparks, Geofrey. El Modelo de Casos de Usos.
Disponible en:
http://www.exa.unicen.edu.ar/catedras/modysim/teoria/casos_de_uso_a.pdf
[Storti2007] Storti, Guillermo. Modelo Entidad Relacion.
Disponible en:
http://www.belgrano.esc.edu.ar/matestudio/carpeta_de_access_introduccion.pdf
[ZendFramework] ZendFramework. Disponible en:
http://framework.zend.com/
