UNIVERSIDAD CENTRAL DEL ECUADOR
FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA
CARRERA DE INGENERÍA INFORMÁTICA
SISTEMA PARA USO Y CONTROL DE LA FLOTA VEHICULAR DE LA
UNIVERSIDAD CENTRAL DEL ECUADOR
TRABAJO DE GRADUACIÓN PREVIO LA OBTENCIÓN DEL TITULO DE
INGENIERO INFORMÁTICO
AUTOR: VILCA LINCANGO WLADIMIR ARSECIO
TUTOR: ING.CARRILLO FLORES RENÉ ALFONSO
QUITO-ECUADOR
2015
ii
DEDICATORIA
Dedico el siguiente trabajo de tesis a Dios por guiarme en cada momento de mi vida,
en la consecución de mis objetivos, metas y logros, a la vez que me motiva para ser
un persona cada vez más responsable en el transcurso de la vida.
A mi amada madre María Rosa Lincango por su apoyo, amor y paciencia, sin ella, no
sería posible alcanzar este logro que desde la infancia me formó, con carácter,
valores y responsabilidad; a mis hermanos que con sus consejos han sido
fundamentales a lo largo de mi vida personal y profesional.
Dedico a mi amigos/as y mi familia, que en todo momento fue muy importante.
iii
AGRADECIMIENTO
Agradecemos la valiosa colaboración del Ing. René Carrillo, MSc como director de
tesis, a los revisores Ing.Giovanny Moncayo, MSc e Ing. Mario Morales, MSc por
su apoyo, guía y comentarios durante el desarrollo de la tesis, a todos los catedráticos
que desempeñan sus funciones en la Facultad de Ingeniería Ciencias Físicas y
Matemáticas a la Biblioteca y sus colaboradores que supieron ayudarnos en el
desarrollo académico, de igual manera Dirección General Administrativa y su
personal administrativo por su valiosa colaboración .
Wladimir Arsecio Vilca Lincango
iv
AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL
Yo, Wladimir Arsecio Vilca Lincango en calidad de autor del trabajo de
investigación o tesis realizada sobre SISTEMA PARA USO Y CONTROL DE LA
FLOTA VEHICULAR DE LA UNIVERSIDAD CENTRAL DEL ECUADOR por
la presente autorizó a la UNIVERSIDAD CENTRAL DEL ECUADOR, hacer uso de
todos los contenidos que me pertenecen o de parte de los que contiene esta obra, con
fines académicos o de investigación.
Los derechos que como autor me corresponde, con excepción de la presente
autorización, seguirán vigentes a mi favor, de conformidad con lo establecido en los
5, 6, 8,19 y demás pertinentes de la ley de Propiedad intelectual y su Reglamente.
Quito, a los 13 del mes de Agosto de 2015
Wladimir Arcesio Vilca Lincango
C.C. 171447858-1
v
vi
INFORME SOBRE LA CONCLUSIÓN DEL TRABAJO DE GRADUACIÓN
SISTEMA DE CONTROL Y USO PARA LA FLOTA VEHICULAR DE LA
UNIVERSIDAD CENTRAL DEL ECUADOR
1.-Antecedentes:
Con oficio 003-2015-DC del 06 de enero de 2015, el Director de la carrera de
Ingeniería informática designa al Docente de la carrera de Ingeniería Informática de
la Facultad Ciencias Físicas y Matemáticas de la Universidad Central de Ecuador
Ing. René Alfonso Carrillo Flores, MSc que en calidad de TUTOR analice, dirija y
oriente el trabajo de graduación titulado ¨SISTEMA PARA USO Y CONTROL
DE LA FLOTA VEHICULAR DE LA UNIVERSIDAD CENTRAL DEL
ECUADOR¨ presentado por el señor Vilca Lincango Wladimir Arcesio con el
objeto de obtener el título de Ingeniero informático, y que emita un informe sobre la
ejecución del mismo a su finalización.
2.-Desarrollo del Trabajo de Graduación:
Para dar cumplimiento a lo ordenado se procedió a instruir la elaboración del trabajo
y el graduado realizo bajo mi supervisión las siguientes actividades.
Inició la recopilación del material bibliográfico utilizado para el desarrollo
del trabajo de Graduación, consistente básicamente reglamentos, normas y
leyes para el control de vehículos del sector público.
Realizo utilizando software libre tanto a nivel de entorno de desarrollo como
de base de datos.
Corrigió las observaciones realizadas en varias reuniones a los capítulos y al
programa del trabajo de graduación.
Se procedió a verificar el funcionamiento del programa mediante las pruebas
realizadas cumpliendo con el objetivo planteado.
Atentamente,
Ing. René Alfonso Carrillo Flores, MSc.
CATEDRÁTICO DE LA CARRERA DE INGENERIA INFORMATICA
vii
viii
CONTENIDO
DEDICATORIA .......................................................................................................... ii
AGRADECIMIENTO ................................................................................................ iii
AUTORIZACIÓN DE AUTORÍA INTELECTUAL ................................................. iv
INFORME SOBRE LA CONCLUSIÓN DEL TRABAJO DE GRADUACIÓN ...... vi
CONTENIDO ........................................................................................................... viii
RESUMEN ................................................................................................................. xii
CAPITULO I ................................................................................................................ 1
INTRODUCCIÓN ....................................................................................................... 1
1 Planteamiento del Problema ................................................................................. 3
1.1 Formulación del Problema. ........................................................................... 3
1.2 Interrogantes de la Investigación .................................................................. 4
1.3 Objetivo General .......................................................................................... 4
1.4 Objetivos Específico ...................................................................................... 4
1.5 Justificación ................................................................................................... 5
1.6 Alcances y Limitaciones. .............................................................................. 6
1.7 Identificación de variables ............................................................................. 7
1.8 Hipótesis ........................................................................................................ 7
CAPITULO II .............................................................................................................. 8
2 Antecedentes ........................................................................................................ 8
2.1 Fundamento Teórico ...................................................................................... 8
2.2 Fundamentación Legal ................................................................................. 9
2.3 Categoría Fundamentales ............................................................................ 15
2.4 Área vehicular Universidad Central del Ecuador ....................................... 18
2.5 Herramientas de Desarrollo. ........................................................................ 19
2.5.1 Entorno de Desarrollo Integrado (IDE) para Java................................ 19
2.5.2 Lenguaje de Programación ................................................................... 21
2.5.3 API de persistencia para Java (JPA) .................................................... 24
2.5.4 JavaServer Faces(JSF) ......................................................................... 37
2.5.5 PrimeFaces ........................................................................................... 40
2.6 Arquitectura Tecnológica. .......................................................................... 40
2.6.1 Modelo-Vista –Controlador ................................................................. 41
ix
2.7 Servidor JBoss ............................................................................................. 43
2.8 PostgresSQL ................................................................................................ 44
2.9 Metodología de Desarrollo de Software XP ................................................ 46
2.10 Diseñador de Reportes ................................................................................. 53
CAPITULO III ........................................................................................................... 55
3 Desarrollo del Proyecto ...................................................................................... 55
3.1 Planeación ................................................................................................... 55
3.2 Diseño .......................................................................................................... 65
3.3 Desarrollo .................................................................................................... 67
3.4 Pruebas ........................................................................................................ 67
CAPITULO IV ........................................................................................................... 71
CONCLUSIONES ..................................................................................................... 71
RECOMENDACIONES ............................................................................................ 72
Bibliografía ................................................................................................................ 73
Glosario de términos .................................................................................................. 75
ANEXOS ................................................................................................................... 77
ANEXO A .............................................................................................................. 78
ANEXO B .............................................................................................................. 84
x
LISTA DE FIGURAS
Figura 1.Máquina Virtual Java ................................................................................... 24
Figura 2 Entity Manager ............................................................................................ 26
Figura 3.Motor de Persistencia .................................................................................. 28
Figura 4 Arquitectura ORM. ...................................................................................... 29
Figura 5.Mapeo de Entidad ........................................................................................ 30
Figura 6.Arquitectura JPA ......................................................................................... 32
Figura 7.Estructura Sentencia JPQL .......................................................................... 35
Figura 8.Arquitectura de Hibernate............................................................................ 36
Figura 9.Arquitectura completa de Hibernate ............................................................ 37
Figura 10.jsf Arquitectura .......................................................................................... 39
Figura 11.modelo-vista-controlador ........................................................................... 41
Figura 12.Ciclo de vida MVC .................................................................................... 42
Figura 13.Servidor Jboss ............................................................................................ 43
Figura 14 Metodología de XP ................................................................................... 48
Figura 15 Historia del cliente ..................................................................................... 49
Figura 16.Actor .......................................................................................................... 55
Figura 17.Caso de Uso ............................................................................................... 56
Figura 18.Asociación ................................................................................................. 56
Figura 19.Dependencia .............................................................................................. 56
Figura 20.Gerneralizacion .......................................................................................... 56
Figura 21.Administrar Cuentas de Usuarios .............................................................. 57
Figura 22.Informacion Vehículos .............................................................................. 59
Figura 23.Facultades Vehículo................................................................................... 61
Figura 24.Elaboracion Salvoconducto ....................................................................... 63
Figura 25.Modelo Entidad –Relación ........................................................................ 69
Figura 26.Modelo Físico ............................................................................................ 70
xi
LISTA DE TABLAS
Tabla 1.Usuario .......................................................................................................... 78
Tabla 2.Licencia Tipo ................................................................................................ 78
Tabla 3.Roles.............................................................................................................. 78
Tabla 4.Acceso ........................................................................................................... 79
Tabla 5.Menu ............................................................................................................. 79
Tabla 6.Estado Usuario .............................................................................................. 79
Tabla 7.Facultad ......................................................................................................... 79
Tabla 8.Vehiculo ........................................................................................................ 80
Tabla 9.Marca ............................................................................................................ 80
Tabla 10.Modelo ........................................................................................................ 80
Tabla 11.Marca- Modelo ............................................................................................ 81
Tabla 12.Color............................................................................................................ 81
Tabla 13.Tipo Vehículo ............................................................................................. 81
Tabla 14.Estado .......................................................................................................... 81
Tabla 15.Estado Vehículo .......................................................................................... 82
Tabla 16.Provincia ..................................................................................................... 82
Tabla 17.Salvoconducto ............................................................................................. 82
Tabla 18.Historial salvoconducto............................................................................... 83
xii
RESUMEN
SISTEMA PARA USO Y CONTROL DE LA FLOTA VEHICULAR DE LA
UNIVERSIDAD CENTRAL DEL ECUADOR
La Universidad Central del Ecuador ha visto la necesidad de mejorar, optimizar y
controlar de mejor manera los vehículos pertenecientes a la Institución.
Considerando que actualmente este sector realiza sus actividades en forma semi
automática, existen impactos negativos relacionados a materiales y recurso humano.
De igual forma la información tiende a ser inconsistente lo que hace difícil la toma
de decisiones.
Siendo el área vehicular un parte fundamental dentro sus actividades, un sistema de
control y uso vehicular, representa un factor importante para manejar la información
del área vehicular ya que mejorará la velocidad de procesamiento, la recuperación de
la información será rápida y eficiente, existirá seguridad de los datos.
Debido a lo expuesto, la Institución tiene la necesidad administrativa de automatizar
completamente el control y uso de su flota vehicular.
DESCRIPTORES:
SISTEMA DE CONTROL VEHICULAR UCE/ POSTGRES SQL / API DE
PERSISTENCIA PARA JAVA (JPA) / SERVIDOR JBOSS / ENTORNO DE
DESARROLLO INTEGRADO (IDE) PARA JAVA / PRIMEFACES /
JAVASERVER FACES (JSF)
xiii
ABSTRACT
CONTROL SYSTEM FOR THE VEHICULAR FLEET OF THE
UNIVERSIDAD CENTRAL DEL ECUADOR
Universidad Central del Ecuador has seen the need to improve, optimize and control
the use of institutional vehicles. The fact that nowadays this sector carries out its
activities in a semi-automatic fashion, brings forward certain negative impacts
related to materials and human resources. Similarly, vehicle information tends to be
inconsistent, thus hindering the decision-making process.
Give that the vehicular area is a fundamental part in the University’s activities, a
control system for vehicular use represents an important factor in managing
information relative to the vehicular area and may help improve precessing speed,
information recovery will be fast and more efficient and data will be handled in a
safer manner.
Under this premise, the Institution has the administrative obligation to completely
automate the control and use of its vehicular fleet.
KEYWORDS :
VEHICULAR CONTROL SYSTEM UCE / POSTGRESQL /JAVA PERSISTENCE
API (JPA)/JBOSS SERVER / INTEGRATED DEVELOPMENT ENVIRONMENT
(IDE) FOR JAVA /PRIMEFACES / JAVASERVER FACES (JSF)
xiv
xv
1
CAPITULO I
INTRODUCCIÓN
La Universidad Central del Ecuador autoriza la movilización de sus vehículos a
través de un documento denominado salvoconducto, dicho documento es emitido por
la institución luego de seguir los siguientes pasos:
La autoridad de la facultad solicita el uso de un vehículo para la movilización
fuera de la Institución, al Vicerrector Administrativo y Financiero, esto a
través de un oficio dirigido al Director de la Dirección mencionada.
El Vicerrector Administrativo y Financiero aprueba el oficio mencionado,
notificando a la Dirección General Administrativa.
La Dirección General Administrativa elabora el salvoconducto y entrega al
conductor.
Ante esta realidad la Universidad Central del Ecuador, tiene como centro de atención
mejorar la información y el servicio.
El sistema muestra de manera atractiva, rápida y transparente, información al
usuario, brinda acceso a reportes importantes, ofrece servicios como consultas,
ingresos, modificaciones y eliminaciones de información.
En los primeros capítulos de este documento se hace una presentación del problema a
investigar y resolver, el estado actual del control de la información Dirección
General Administrativa de la Universidad Central del Ecuador, la base legal y teórica
en la que se apoya el proyecto, también se plantean los objetivos generales y
específicos del proyecto, la justificación del trabajo realizado y el alcance del sistema
para el desarrollo del presente proyecto.
2
En los capítulos posteriores, se detalla el análisis de la información obtenida, los
requerimientos solicitados, conclusiones y recomendaciones
Se plantea la propuesta donde consta la factibilidad, la justificación de la utilización
de herramientas y tecnología a usar tanto del sistema operativo, base de datos y
aplicación en que se desarrolló el sistema de control y uso para la flota vehicular de
la Universidad Central del Ecuador el diseño del sistema a implementarse, el diseño
de interacción de los diagramas UML, como son: los diagramas de casos de uso.
3
1 Planteamiento del Problema
La Universidad Central del Ecuador, se encuentra equipada de vehículos
(automóviles, camionetas, volquetas, buses, furgonetas) que prestan servicios para el
normal desenvolvimiento de las actividades de la Institución, bienes que necesitan un
control administrativo permanente y riguroso. Así como también es necesario llevar
un registro detallado de la información de los vehículos y su constante movilización
para un control administrativo.
Para la salida de un vehículo de las inmediaciones en Universidad Central del
Ecuador, es necesario la obtención de un documento designado con el nombre de
salvoconducto, el mismo que es entregado al chofer de la facultad o Centro
correspondientes, luego de realizar varios procesos, esto para que pueda salir y
circular el vehículo, en el documento se detallan información del vehículo, tales
como placas, año, modelo, también las fechas de salida, fechas de retorno, motivos
de uso entre los más destacados para control interno.
El inadecuado manejo de la administración de los vehículos en la institución,
dificulta el registro de entrada y salida de los mismos.
Actualmente la Universidad Central del Ecuador no cuenta con ningún sistema
informático propio que controle administrativamente el uso vehicular, lo cual da
como resultado una operación ineficiente.
1.1 Formulación del Problema.
La información obtenida mediante forma visual y entrevista personal con la persona
encargada de imprimir el documento en la Dirección General Administrativa, de las
diferentes facultades y Centros de la Universidad Central de Ecuador, se pudo
conocer que el proceso para elaborar el salvoconducto, por la autoridad de la
Dirección se lo realiza de forma semi-manual.
En el caso de la Universidad Central de Ecuador, se pudo constatar que la Dirección
General Administrativa, es quien elabora el salvoconducto tiene varios
inconvenientes como se los detalla a continuación.
4
La obtención de información de los vehículos, como el número de placas,
marca, modelo, color, etc. Se lo realiza mediante una fotocopia de la
matricula vehicular.
Al momento de realizar el documento, se necesita conocer la información del
conductor asignado, lo cual se hace mediante una fotocopia de la licencia de
conducir, esto genera una pérdida de tiempo y desperdicio de recursos en la
Dirección.
La acumulación de información se la realiza de forma física, es decir en
carpetas que reposan en la Dirección.
El salvoconducto se los lleva en plantillas en EXEL del paquete de Microsoft
Office 2007.
Esto tiene grandes inconvenientes de precisión, manejo y comprensión, además no
proporciona datos automáticos y exactos sobre los vehículos, así como de los
conductores, es decir, que la Institución no cuenta en el momento con ningún sistema
informático propio.
1.2 Interrogantes de la Investigación
1.- ¿Se puede desarrollar una herramienta informática, para la automatización de
procesos administrativos en el control y uso de vehículos en la Dirección General
Administrativa?
2.- ¿Qué impacto tiene la construcción de un software de control, en la
administración de vehículos de la Dirección General Administrativa?
1.3 Objetivo General
Desarrollar un sistema de control administrativo vehicular en la Dirección
General Administrativa de la Universidad Central del Ecuador
1.4 Objetivos Específico
Determinar los requerimientos necesarios, para la realización del sistema
de control dentro del Universidad Central del Ecuador.
Desarrollar el sistema informático que controle y gestione la información
en el área vehicular de la Universidad Central del Ecuador.
5
1.5 Justificación
Los vehículos pertenecientes al sector público, como es el caso de la Universidad
Central del Ecuador, están destinados únicamente para uso oficial, es decir para el
desempeño de funciones públicas.
Para la movilización de los vehículos oficiales, fuera de la sede donde los
funcionarios ejercen habitualmente sus actividades laborales, las Órdenes de
Movilización también conocidos como salvoconductos, serán emitidas por la
máxima autoridad de la institución perteneciente.
La presente investigación se justifica, debido que la Dirección General
Administrativa de la Universidad Central de Ecuador, carece de un control
administrativo sobre la información del parque automotor, actualmente manejan
archivos físicos, es decir, copias de matrículas, licencias en papel y plantillas de
Word, Excel en una computadora de la Dirección; por separado, y no llevan un
registro sobre el área vehicular, obteniendo así resultados adversos para la
institución.
La Universidad Central del Ecuador buscando siempre el mejoramiento en la calidad
de servicios, para sus actividades desea implementar un sistema de control
administrativo, lo cual es de suma importancia porque permitirá reducir los costos en
el área, con la finalidad de lograr satisfacer sus necesidades.
De este Proyecto se beneficiarán, en primer lugar la Dirección General
Administrativa de la Universidad Central del Ecuador, que tendrá mayor control del
área vehicular e información más exacta, lo cual permitirá reducir el tiempo de
elaboración del salvoconducto, generando una mejor calidad de su servicio.
También se aprovechara la tecnología con la cuenta la institución, para automatizar
la información del área vehicular
6
1.6 Alcances y Limitaciones.
Alcance
El alcance del diseño y desarrollo del sistema de control vehicular , prestará
servicio a la Dirección General Administrativa de la Universidad Central del
Ecuador para el área vehicular.
El sistema de control administrativo vehicular, constará de un módulo seguro-
dad, módulo elaboración de salvoconducto, módulo de vehículos y conducto-
res entre lo más destacados.
Administrar información preliminar
- Registrar y administrar cuentas de usuarios
- Registrar y administrar la información de Marcas y Modelos de
Vehículos
- Registrar y administrar los Tipos de Vehículos.
- Registrar y administrar las facultades o Centros.
Limitación
El presente trabajo se realizará para la Universidad Central del Ecuador
dentro de la Dirección General Administrativa.
La aplicación informática no proporcionara geo localización de los vehículos.
La aplicación no constará de módulos respecto a actividades operativas de
los vehículos, tales como estado del vehículo en su parte mecánica,
mantenimiento a talleres.
La aplicación no contralar ni administra partes, piezas o repuesto de los
vehículos.
La aplicación no contempla el mantenimiento preventivo ni correctivo de
vehículos.
7
1.7 Identificación de variables
Variable independiente
Software de Control
Variable dependiente
Mejorar el servicio en el área vehicular de la Universidad Central de Ecuador
1.8 Hipótesis
El desarrollo de un sistema de control a los vehículos dentro Dirección General
Administrativa mejorará el funcionamiento, tanto en el departamento Administrativo
como en el área vehicular, además ayudara a brindar un mejor y mayor servicio a la
Dirección.
8
CAPITULO II
2 Antecedentes
Las modernas organizaciones deben estar preparadas, para enfrentar grandes
desafíos. En un mundo globalizado y digitalizado, que día tras día genera nueva
tecnológica cabe hablar sobre la Automatización, que no es sino una amplia variedad
de sistemas y procesos que operan con mínima intervención del ser humano.
Para lograr esto, las Instituciones deben tener sistemas informáticos que constituyan
un elemento, fundamental y de gran importancia en su desarrollo de actividades.
La Dirección General Administrativa de la Universidad Central del Ecuador presenta
la necesidad de contar con una herramienta de control administrativo vehicular,
debido a que bajo el área administrativa, se encuentra el control y administración
de todos los vehículos que son propiedad de la Institución, tomando en cuenta que
dentro del área vehicular están contemplados automóviles, buses, camionetas,
camiones, volquetas, furgonetas.
2.1 Fundamento Teórico
Como antecedente investigativo en la Universidad Central del Ecuador, no sea
realizado un análisis previo sobre la implantación de un sistema de control para uso
de vehículos oficiales.
En la biblioteca de la Facultad de Ingeniería, Ciencias Físicas y Matemáticas de la
Universidad Central del Ecuador se han examinado, averiguado las tesis perfiles de
graduación y como consecuencia se logró los siguientes temas que tiene similitud al
tema planteado en la Universidad Central del Ecuador.
Como “Control y Mantenimiento preventivo de vehículos para la Empresa
Metropolitana de Alcantarillado y Agua Potable Quito EMAAP-Q” software
realizado por los Ingenieros Franco Vinicio, Hidalgo Williams ,Oñate Sonia ,este
tema tiene semejanza con el actual proyecto que se encuentra en desarrollo, para
destacar lo significativo de la tesis es que servirá de soporte para realizar
investigaciones que oriente al correcto desarrollo del sistema de control
administrativo en el área vehicular de la Universidad Central del Ecuador.
9
Previo a una investigación realizada, existen diferentes medios de consulta como en
direcciones electrónicas, bibliotecas, se puede contar con la suficiente información
bibliográfica que servirá de ayuda para el desarrollo del presente trabajo, lo que hace
factible su realización
2.2 Fundamentación Legal
Reglamento de Utilización, Mantenimiento, Movilización, Control y Determinación
de Responsabilidades, de los Vehículos del Sector Público y de las Entidades de
Derecho Privado que disponen de Recursos Públicos en los Términos Previstos por
el Artículo 211 de la Constitución Política y en el Artículo 4 de la Ley Orgánica de la
Contraloría General del Estado del Ecuador.
CONSIDERANDO:
Que, el Acuerdo 025 CG, publicado en el Registro Oficial 378 de 17 de octubre de
2006, dicta el Reglamento General Sustitutivo para el Manejo y Administración de
Bienes del Sector Público;
Que, el Reglamento General para la aplicación de la Ley Orgánica de Transporte
Terrestre, Tránsito y Seguridad Vial, fue reformado mediante Decreto Ejecutivo
1196, publicado en el Segundo Suplemento del Registro Oficial 731 de 25 de junio
de 2012;
Que, se han dictado diversas disposiciones que regulan la movilización de los
automotores oficiales; y,
En ejercicio de las facultades que le confieren los artículos 212 número 3, de la
Constitución de la República y 31 número 22 de la Ley Orgánica de la Contraloría
General del Estado
10
ACUERDA
Expedir el siguiente Reglamento para el Control de los Vehículos del Sector
Público y de las Entidades de Derecho Privado que disponen de Recursos
Públicos.
Art. 1.- Ámbito de aplicación.-
Se sujetan a las disposiciones del presente reglamento, los dignatarios, autoridades,
funcionarios, administradores, servidores y trabajadores de las instituciones del
Estado, señaladas en el artículo 225 de la Constitución de la República del Ecuador.
DE LOS SERVIDORES Y TRABAJADORES RESPONSABLES
Art. 3.- Servidores y/o trabajadores responsables.- Son responsables del
cumplimiento de las normas contenidas en este acuerdo, los servidores públicos y
privados descritos en el artículo 1 del presente reglamento, a cuyo cargo se
encuentren los vehículos institucionales y quienes los conduzcan.
Para efectos de la aplicación de esta normativa se entenderá por:
Titular de la gestión administrativa.- El servidor que dirige la gestión
administrativa de la entidad.
Titular de una unidad administrativa.- Servidor que dirige cualquier unidad
administrativa de la entidad.
Encargado o responsable de la unidad de transportes.- El servidor encargado de
la organización y control del parque automotor institucional.
Conductor.- El servidor y/o trabajador facultado para conducir un vehículo
automotor oficial, así como, quien guía, dirige o maniobra un vehículo remolcado.
Mecánico.- El servidor bajo cuya responsabilidad se encuentra a cargo el chequeo,
mantenimiento y reparación de los vehículos.
11
DE LOS CONDUTORES
Art. 4.- Conducción de los vehículos.-
Los vehículos oficiales deben ser conducidos por choferes profesionales. Por
excepción, previa autorización y bajo responsabilidad de la máxima autoridad o su
delegado, vehículos con acoplados de hasta 1.75 toneladas de carga útil, pueden ser
conducidos por servidores públicos que se movilicen para el cumplimiento de sus
funciones y que tengan Licencia Tipo B (no profesional), a quienes se los
considerará también responsables de su cuidado, mantenimiento preventivo básico y
del cumplimiento de las leyes y reglamentos vigentes para el sector público y de
tránsito, transporte terrestre y seguridad vial.
DE LA MOVILIZACIÓN Y MANTENIMIENTO VEHICULAR
Art. 5.- Movilización de los vehículos oficiales y excepciones.-
Ningún vehículo oficial podrá circular sin la respectiva orden de movilización y con
justificación expresa de la necesidad institucional.
Se excluyen de la norma contenida en el inciso anterior, los vehículos del servicio de
ambulancias de las unidades de salud del Ministerio de Salud Pública, Instituto
Ecuatoriano de Seguridad Social, IESS, Cruz Roja Ecuatoriana, Cuerpo de
Bomberos, Secretaría Nacional de Gestión de Riesgos, Sola, Fuerzas Armadas,
Policía Nacional, Comisión de Tránsito del Ecuador y de los cuerpos de seguridad y
vigilancia de los Gobiernos Autónomos Descentralizados, Regionales,
Metropolitanos y Municipales; además, los vehículos utilizados para el
mantenimiento de los sistemas de redes eléctricas, telefónicas, agua potable,
alcantarillado, obras públicas; los automotores del Sistema Integrado de Seguridad
Ciudadana ECU 911, y aquellos que sean indispensables para atender casos de
emergencia y para mantener la continuidad y regularidad de los servicios públicos.
12
DE LA ORDEN DE MOVILIZACIÓN
Art. 6.- Solicitud de orden de movilización.-
El titular de la unidad administrativa o su delegado, autorizarán el desplazamiento
del servidor en días y horas laborables; para tal propósito, la orden de movilización
se tramitará en formatos propios de la entidad.
DE LA RESPONSABILIDAD DEL CUSTODIO DEL VEHÍCULO
Art. 8.- Custodia del vehículo.-
El conductor asignado es responsable de la custodia del vehículo durante el tiempo
que dure la comisión. Las llaves del automotor permanecerán en su poder.
Cuando los vehículos se destinen a comisiones fuera de las horas de la jornada
ordinaria de trabajo, días feriados y/o fines de semana, o cuando implique el pago de
viáticos y/o subsistencias, la responsabilidad por el cuidado, protección y
mantenimiento básico del mismo, corresponderá al conductor. Si las labores a
cumplirse sobrepasan el plazo de treinta días, con los justificativos correspondientes,
se asignará el vehículo mediante acta de entrega recepción, suscrita por el encargado
de la unidad de transportes de la entidad y el conductor autorizado.
El conductor autorizado es responsable de verificar la vigencia de la matrícula
vehicular y del Seguro Obligatorio de Accidentes de Tránsito, SOAT, las
condiciones del vehículo y que sus partes y accesorios se encuentren completos al
momento de recibirlo, de lo cual dejará constancia en el formulario correspondiente
de entrada y salida de vehículos, debiendo entregarlo en igual forma.
Al término de la jornada de trabajo o de la comisión, los vehículos deben guardarse
en los patios de la institución o en los garajes autorizados, cuya ubicación será
informada por escrito y con antelación a la Contraloría General del Estado.
En los días y horas no laborables, el guardia de turno o el servidor encargado,
registrará la hora de entrada o salida de los vehículos, con la firma del conductor y no
permitirá la salida de los automotores sin la correspondiente orden de movilización.
13
Art. 10.- Abastecimiento de combustible y lubricantes.-
El servidor responsable de la unidad de transportes, debe establecer el control de
consumo del combustible, con referencia hecha al rendimiento medio de kilómetros
por litro, de acuerdo a cada tipo de vehículo, modelo, entre otros.
Para el abastecimiento de combustible, se utilizarán formularios con formato
específico para asegurar el debido control.
DE LOS VEHÍCULOS
Art. 11.- Distribución de los vehículos.-
El encargado o responsable de la unidad de transportes, debe asignar las unidades
automotrices con criterio técnico y atendiendo las necesidades institucionales.
Art. 14.- Identificación de los vehículos.-
Los vehículos deben identificarse plenamente con el nombre de la entidad y/o con el
logotipo institucional, de haberlo, ubicados en los costados de cada automotor. Se
exceptúan aquellos vehículos que, por razones de seguridad previamente calificada
por la máxima autoridad de la entidad o su delegado, se considere que no deben
llevar ningún tipo de distintivo, así como aquellos determinados en el segundo y
cuarto inciso del artículo 2 de este reglamento. En cualquier caso, el conductor debe
portar los documentos de identificación del automotor.
Los vehículos oficiales deben matricularse a nombre de la respectiva entidad y portar
sus placas, tal como lo previene la Ley Orgánica de Transporte Terrestre, Tránsito y
Seguridad Vial y su reglamento. Ver fundamento legal1
ACCIONES DE CONTROL Y SANCIONES
Art 15.- Acciones de control vehicular.-
Las acciones de control del uso de vehículos oficiales serán dispuestas por el
Contralor General del Estado o su delegado y ejecutadas por servidores de la
Contraloría y de las unidades de auditoría interna; se realizarán con el apoyo de la
Policía Nacional, la Comisión de Tránsito del Ecuador y de los cuerpos de seguridad
y vigilancia de los Gobiernos Autónomos Descentralizados, regionales,
metropolitanos y municipales, en sus respectivas jurisdicciones
1 Controlaría General del Estado ,(2014),AcuerdoN°005, Recuperado de http://ai.espe.edu.ec/wp-
content/uploads/2014/09/Acuerdo-005-CG-2014-Reglamento-para-el-control-vehiculos-del-sector-
Publico.pdf
14
Art. 16.- Retiro de órdenes de movilización.-
El servidor que participe en el control vehicular, está autorizado para retirar las
órdenes de movilización que no cumplan con lo dispuesto en los artículos 5 y 6 de
este reglamento, cuyas novedades las presentará al titular de la unidad encargada de
la acción de control, una vez concluida ésta
Art. 20.- Causales y sanción administrativa.-
Sin perjuicio de la responsabilidad civil culposa o indicios de responsabilidad penal a
que hubiere lugar, los sujetos referidos en el artículo 1 del presente reglamento, que
incurrieren en las faltas administrativas detalladas en este artículo, serán sancionados
de la siguiente manera:
I Multas:
a. Utilizar la orden de movilización en asuntos distintos a los autorizados: de cinco a
quince salarios básicos unificados para el trabajador en general
b. Solicitar u otorgar órdenes de movilización sin causa justificada, sin tener
competencia para ello, o con carácter permanente, indefinido y sin restricciones: de
quince a veinte salarios básicos unificados para el trabajador en general.
c. Utilizar los vehículos prescindiendo de la orden de movilización, o usando una
caducada, o con carácter permanente o por tiempo indefinido: de quince a veinte
salarios básicos unificados para el trabajador en general.
d. Autorizar la salida de un vehículo en malas condiciones o con desperfectos
mecánicos: de quince a veinte salarios básicos unificados para el trabajador en
general.
e. Evadir o impedir, de cualquier forma, la acción de control de los vehículos
oficiales: veinte salarios básicos unificados para el trabajador en general2.
2Controlaría General del Estado ,(2014),AcuerdoN°005, Recuperado de http://ai.espe.edu.ec/wp-
content/uploads/2014/09/Acuerdo-005-CG-2014-Reglamento-para-el-control-vehiculos-del-sector-
Publico.pdf
15
2.3 Categoría Fundamentales
Automatización
El término automatización se ha utilizado para describir sistemas no destinados a la
fabricación en los que dispositivos programados o automáticos pueden funcionar de
forma independiente o semiindependiente del control humano. La automatización se
utiliza para efectuar diversas tareas con más rapidez o mejor de lo que podría hacerlo
un ser humano.
Uso de la automatización en la informática
Hoy en día los sistemas de información conforman un marco de dependencia
tecnológica determinante en procura de resolver innumerables problemas a mediano
y a largo plazo, dejando de lado el corto plazo por considerarlo imposible de
concretar.
Los altos costos representados por los servicios informáticos en empresas e
instituciones dificultan la labor operacional, que como sabemos siempre está
intentando mejorar su calidad laboral a diario para poder liberarse de la incesante
rutina a la que se ve sometido.
Información
La información está compuesta de signos y señales que se han colocado en un
contexto significativo y útil y se ha comunicado a un receptor generando inteligencia
y conocimiento que le ayuda a quien la utiliza a tomar decisiones, poder de
evaluación, reducir la incertidumbre, revelar alternativas, estimular acciones,
anticipar el futuro o eliminar aspectos irrelevantes en una organización o institución.
Información Interna
En todo proceso de toma decisiones se necesita información externa. Sin embargo
para que dicha información pueda ser dirigida por los gestores requiere que sea
tratada internamente. Además, es necesario que la información pueda fluir por los
canales de la institución para que obtenga el máximo provecho por parte de la
organización.
Diferencia entre dos tipos de información interna: los conocimientos y la
información operacional. La información operacional es la generada por la
organización debido al funcionamiento rutinario de la empresa, institución; mientras
16
el conocimiento es el resultado de la fusión de la información interna y externa, que
genera beneficios para las empresas organizaciones e instituciones.
Sistemas
Generalmente los sistemas en sí tienen varios conceptos, entre los cuales podemos
anotar los siguientes:
- Un sistema es un conjunto de partes o elementos organizados y relacionados
que interactúan entre sí para lograr un objetivo. Los sistemas reciben
(entrada) datos, energía o materia del ambiente y proveen (salida)
información, energía o materia.3
- Un sistema es una mezcla de componentes que actúan unidos y realizan un
propósito determinado. El sistema no necesariamente es físico. El concepción
de sistema se aplica a fenómenos abstractos y dinámicos, tales como en el
campo de la economía.
- Del latín systema, un sistema es módulo ordenado de elementos que se
encuentran interrelacionados y que interactúan entre sí. El concepto se utiliza
tanto para definir a un conjunto de conceptos como a objetos reales dotados
de organización.4
Características
Entre las principales características que tienen los sistemas son:
Sistema es un todo organizado y complejo.
Un sistema puede ser físico o concreto, puede ser abstracto o
conceptual (un software).
Todo sistema tiene uno o algunos propósitos los cuales tratan siempre
de alcanzar un objetivo.
El ambiente es el medio en externo que envuelve física o
conceptualmente a un sistema. El sistema tiene interacción con el
ambiente, del cual recibe entradas y al cual se le devuelven salidas. El
ambiente también puede ser una amenaza para el sistema.5
3Alegsa, L, (2014),Recuperado de http://www.alegsa.com.ar/Dic/sistema.php
4Definicion de,(2008)Recuperado de http://definicion.de/sistema/
5Alegsa, L, (2014),Recuperado de http://www.alegsa.com.ar/Dic/sistema.php
17
Tipos de sistemas
Según la relación que establecen con el medio ambiente:
Sistemas cerrados: no presenta un cambio con el medio ambiente que los rodea, son
impenetrable a cualquier influencia ambiental. No reciben ningún recurso extremo.
Sistemas abiertos: estos sí establecen intercambios con el medio ambiente que los
rodea. Para lograr esto se valen de salidas y entradas por medio de las que
intercambian, de manera constante, energía y materia con el medio ambiente. Este
vínculo que se establece hace que los sistemas abiertos deban ser sumamente
adaptativos a las cualidades del ambiente del cual dependen, sino es así, no logran la
supervivencia. Esta dependencia con lo ajeno hace que no puedan existir de forma
aislada y que deban adaptarse por medio de la organización y del aprendizaje a los
cambios externos. 6
En cuanto a su constitución, pueden ser físicos o abstractos:
Sistemas físicos o concretos: compuestos por equipos, maquinaria, objetos y
cosas reales. Es lo que se conoce como Hardware.
Sistemas abstractos: compuestos por conceptos, planes, hipótesis e ideas.
Muchas veces solo existen en el pensamiento de las personas. Es lo que se
conoce como Software.
Control
Para empezar a hablar de control administrativo tenemos que empezar desde el
término controlar.
Con el avance de la tecnología las empresas, instituciones se vuelven más complejas
y más modernas, el problema del control aumenta. Por tanto se debe tener un
conocimiento bien fundado en el tema de controlar.
El control es un proceso esencialmente regulador que mide y evalúa el desempeño y
toma la acción correctiva cuando se necesita, para que el control sea efectivo debe
desarrollarse como una unidad y aplicarse en todo tiempo a la empresa o Institución
El control se apoya en la aprobación, fiscalización e inspección de las variables
organizativas.
6tipo de.org,(2010) ,tipo de sistemas, Recuperado de http://www.tiposde.org/general/727-sistemas/
18
El control es importante porque establece medidas para corregir las actividades, de
tal forma que se alcancen los planes exitosamente, determina y analiza rápidamente
las causas que puede originar desviaciones para que no vuelvan a presentarse en el
futuro, reduce costos y ahorra tiempo al evitar errores, su aplicación incide directa
mente en la racionalización de la administración consecuentemente en el logro de la
productividad de todos los recursos.
Definición de Control
El control es el proceso de verificar el desempeño de distintas áreas o funciones de
una organización. Usualmente implica una comparación entre un rendimiento
esperado y un rendimiento observado, para verificar si se están cumpliendo los
objetivos de forma eficiente y eficaz y tomar acciones correctivas cuando sea
necesario
Vehículo
Existen varias definiciones para los vehículos entre las cuales tenemos:
Un vehículo es un medio que permite el traslado de un lugar a otro. Respecto
de personas u objetos se hace referencia a vehículos de transporte como por
ejemplo tren, automóvil, camión, carro, barco, avión, bicicleta y motocicleta,
entre otros.
Especiales Vehículo a motor que sirve, normalmente, para el transporte de
personas o cosas o de ambas a la vez, o para la tracción de otros vehículos
con aquel fin. Se excluyen de esta definición los vehículos
2.4 Área vehicular Universidad Central del Ecuador
Esta sección se encuentra bajo el área administrativa de la Universidad Central del
Ecuador, se encarga del control y administración de todos los vehículos que son
propiedad de la Institución, tomando en cuenta que dentro del área vehicular se toma
en cuenta como vehículos a automóviles, camionetas, camiones pequeños ,furgonetas
además controla los recursos y la utilización de los automotores.
La Dirección General Administrativa encargada de la emisión de permisos para las
diferentes facultades como centros pertenecientes a la Universidad Central del
Ecuador
19
2.5 Herramientas de Desarrollo.
El sistema propuesto para el desarrollo contempla la implementación de un sistemas
de código abierto Por tal motivo, el aplicativo se basa en el lenguaje de programación
Java, en el entorno de desarrollo integrado Eclipse Kepler, API de persistencia JPA ,
motor de base de datos PostgreSQL, y como herramienta para la generación de
Reportes de usuario final se utilizará JasperReport. Además se manejará la
metodología de desarrollo programación extrema XP que ofrece un conjunto de
técnicas para desarrollar y resolución de problemas puntuales y de corto alcance.
2.5.1 Entorno de Desarrollo Integrado (IDE) para Java
“Los IDEs (Integrated Development Environment) son un conjunto de herramientas
para el programador, que suelen incluir en una misma suite, un buen editor de
código, administrador de proyectos y archivos, enlace transparente a compiladores y
debuggers e integración con sistemas controladores de versiones”7
Son varias las opciones de entornos de desarrollo integrado para Java, entre los
principales podemos en listar :
BlueJ: Un entorno de desarrollo libre de Java diseñado para principiantes.
Eclipse: desarrollado por la Fundación Eclipse, es libre y de código abierto,
Jbuilder: Es IDE de desarrollo libre, Es un software creado en 1995.
NetBeans : Entorno desarrollo entre los más populares, gratuito y de código
abierto.
Otros
Eclipse
La plataforma Eclipse consiste en un Entorno de Desarrollo Integrado (IDE,
Integrated Development Environment) de código abierto y extensible8.Cuenta con
numerosas herramientas de desarrollo de software. Facilita las tareas de edición,
compilación y ejecución de programas durante su fase de desarrollo.
Eclipse fue desarrollado inicialmente por IBM como el sucesor de su familia de
herramientas para VisualAge. Eclipse en la actualmente es ahora desarrollado por
la Fundación Eclipse, una organización independiente sin ánimo de lucro que
7En Wikipedia,(2011),lenguaje de programación, Recuperado de
https://www.wikipedia.org/wiki/Lenguaje_de_programación 8Iniciándose en la plataforma eclipse , (2012), Recuperado de
http://www.atenas.cult.cu/rl/informatica/manuales/sl/introduccion_al_SL/eclipse.html
20
impulsa una comunidad de código abierto y un conjunto de productos
complementarios, capacidades y servicios, que tiene por objeto de proporcionar una
plataforma robusta, escalable y de calidad para el realizar software.
Características
Las características principales que tiene el Entorno de Desarrollo Integrado Eclipse
son:
- Contiene de un editor de textos con opciones para el resaltado de sintaxis.
-Consigue la compilación de archivos en tiempo real.
- Emplea toda clase de asistentes para crear proyectos, clases, etc.
- IDE que permite el uso de extensiones para extender su funcionalidad.
- Porta un exhaustivo control de las versiones con la herramienta CVS.
Ventajas
- Este Entorno de desarrollo es universal no solo sirve para java, también se
puede usar con otros lenguajes de programación como son C/C++, Cobol,
Jsp, Php, Perl, etc.
- Ahorro de memoria que otros entornos de desarrollo.
- Contiene versiones para casi cualquier sistema operativo entre ellos linux y
windows.
- Contiene alternativas de multilenguaje.
- Ahorra mucho espacio en el disco duro.
- Es fácil de llevar.
- Se puede laborar varios espacios de trabajo.
- Contiene un excelente asistente de etiquetas.
Eclipse Kepler
Plataforma de desarrollo de código abierto basada en Java. En lanzamiento de la
versión Eclipse Kleper se realizó 26 de junio 2013. Fue diseñada para ser extendida
de forma indefinida a través deplug-ins. Si bien los proyectos que conforman Kleper
son de código abierto, el principal motor detrás de la liberación es fomentar una
mayor adopción comercial.
21
2.5.2 Lenguaje de Programación
Lenguaje artificial que permite ser usado para controlar el comportamiento de una
máquina, en especialmente una computadora. Se componen de un conjunto de reglas
sintácticas y semánticas que permiten expresar instrucciones que luego serán
interpretadas.
Luciano,(2008), Entorno de desarrollo Integrado:“Pueden usarse para
crear programas que controlen el comportamiento físico y lógico de una máquina,
para expresar algoritmos con precisión, o como modo de comunicación humana.”9
Visión general de la plataforma Java
La tecnología Java se usa para desarrollar aplicaciones para un amplio alcance de
entornos, desde dispositivos del consumidor hasta sistemas empresariales
heterogéneos que satisfacen sus necesidades.
El lenguaje Java
Como en cualquier lenguaje de programación, Java tiene su propia estructura, reglas
de sintaxis y paradigma de programación. El paradigma de programación del
lenguaje Java se apoya en el concepto de programación orientada a objetos (OOP),
que las funciones del lenguaje soportan.
Estructuralmente, el lenguaje Java se realiza mediante paquetes. Un paquete es el
mecanismo de espacio de nombres del lenguaje Java. Dentro de los paquetes se
encuentran las clases y dentro de las clases se encuentran métodos, variables,
constantes, entre otros que son necesarios para el lenguaje y funcionamiento.
Características de Java
Un lenguaje simple lenguaje basado en C++ pero donde se eliminan varias
de las características OOP que se utilizan esporádicamente y que creaban
frecuentes problemas a los desarrolladores. Esta eliminación de causas de
error y problemas de mantenimiento facilita y reduce el coste del desarrollo
de software.
Orientado al objeto Java como tecnología da buen soporte a las técnicas de
desarrollo OOP y en resumen a la reutilización de componentes de software.
9Luciano,(2008),Entorno de desarrollo Integrado java,http://luauf.com/2008/05/13/entornos-de-
desarrollo-integrado-para-java/
22
Distribuido Java se ha diseñado para trabajar en ambiente de redes y
contienen una variedad de biblioteca de clases para la utilización del
protocolo TCP/IP, incluyendo HTTP y FTP. El código Java tiene la facilidad
de manipular a través de recursos URL con la misma facilidad que C y C++
utilizan recursos locales.
Interpretado El compilador Java traduce cada fichero fuente de clases a
código de bytes, que puede ser interpretado por todas las máquinas que den
soporte a un visualizador de que funcione con Java. Este Bytecode no es
específico de una máquina determinada, por lo que no se compila y enlaza
como en el ciclo clásico, sino que se interpreta.
Solido En el código Java no se fractura fácilmente ante errores de
programación. Así la fragilidad que existe en la declaración y manejo de
tipos en C y C++ se torna en restricciones en Java, donde no es posible la
conversión forzada (cast) de enteros en punteros y no ofrece soporte a los
punteros que permitan saltarse reglas de manejo de tipos. Así en Java no es
posible escribir en áreas arbitrarias de memoria ni realizar operaciones que
corrompan el código. En resumen general se eliminan muchas de las
posibilidades de ofrecía el C y C++.
Seguro Java funciona en ambiente de redes el tema de seguridad debe
interesar en sobremanera. Las mismas características antes descritas que
evitan la corrupción de código evitan su manipulación.
Portable Java al ser de arquitectura neutral es altamente portable, pero esta
característica puede verse de otra desde otra perspectiva como: Los tipos
estándares (int, float...) están igualmente implementados en todas las
máquinas por lo que las operaciones aritméticas funcionaran igual en todas
las máquinas.
Dinámico Java al utiliza un sistema de interfaces da resultado, los programas
Java pueden permitir nuevos métodos y variables en un objeto de biblioteca
sin afectar a los objetos dependientes.
Robusto Java fue diseñado para realizar software altamente fiable. Para ello
proporciona numerosas comprobaciones en compilación y en tiempo de
ejecución.
23
Tiene disponibilidad de un amplio conjunto de bibliotecas (packages,
conjuntos de clases) El desarrollo de aplicaciones con Java incluye la
posibilidad de utilizar el amplio conjunto de clases que Sun pone a
disposición del profesional y con las cuales es posible realizar, prácticamente,
cualquier tipo de aplicación. En esta amplia posibilidad, se encuentran clases
para la creación de interfaces gráficas, gestión de red, multitarea, acceso a
datos etc.
¿Empezar a desarrollar en java?
JDK (Java Development Kit - Kit de desarrollo de Java).-Es un software que
provee herramientas de desarrollo para la realización de programas en java.
Los programas más sobresalientes son;
Appletviewer.-Visor de applet para generar sus vistas previas, ya que un
applet carece de método main y no se puede ejecutar con el programa java
Javac .- Es el compilador de JAVA
Java .- Es el intérprete de JAVA.
Javadoc.- Genera la documentación de las clases java de un programa.
Para realizar cualquier aplicación Java en cualquier sistema operativo es necesario
tener instalado el JRE (Java RunTime Environment - Entorno de desarrollo de Java).
El JRE se compone de herramientas necesarias como la máquina virtual de java
(java.exe) y el conjunto de librerías estándar de Java. El JDK incluye a JRE.
Máquina Virtual de Java (JVM).-Es el entorno en el que se efectúalos programas Java
.La JVM interpreta los códigos byte del mismo modo en que una CPU interpretaría
las instrucciones del lenguaje del conjunto. La diferencia es que la JVM es un
software escrito específicamente para una plataforma particular. La JVM es el
corazón del principio "escrito una vez, ejecutado en cualquier lugar" del lenguaje
Java. 10.
JVM están disponibles para plataformas principales como son Linux y Windows y se
han implementado subconjuntos del lenguaje Java en las JVM para teléfonos
móviles.
10
Steven, P,(2012),Introducción a lenguaje Java, Recuperado
dehttp://www.ibm.com/developerworks/ssa/java/tutorials/j-introtojava1/
24
Etapas para la ejecución de un programa:
El siguiente grafico representa los pasos para crear y ejecutar un programa Java.
Figura 1.Máquina Virtual Java
Se describe las etapas:
Edición: Radica en crear un archivo de código fuente que contiene texto escrito en
el lenguaje de programación Java. Este proceso se lo realiza utilizando cualquier IDE
de java. como antes descritos.
Compilación: Con la compilación se convierte el código fuente a un código
intermedio que la máquina virtual de java puede entender, este conjunto de
instrucciones recibe el nombre de bytecodes y se guardan en un archivo cuya
extensión es .class.
Interpretación: La máquina virtual de java es la encargada de interpretar el byteco
de dando lugar a la ejecución del programa.
2.5.3 API de persistencia para Java (JPA)
Java Persistence API es el standard de Java encargado de automatizar dentro de lo
posible la persistencia de nuestros objetos en base de datos.
Para esto, une ideas y conceptos de los principales frameworks de persistencia,
como son Hibernate, Toplink y JDO. El mapeo o reconocimiento objeto-relacional
(es decir, la relación entre entidades Java y tablas de la base de datos, consultas,
queries con nombre, etc.) se realiza mediante anotaciones en las propias clases de
entidad. JPA involucra el término persistencia.
25
La persistencia o el almacenamiento permanente, es una de las necesidades básicas de
cualquier sistema de información de cualquier tipo. En primera instancia, se propuso
que el programa tratara los datos haciendo consultas directas a la base de datos.
Posteriormente, se propone trabajar con objetos, pero las bases de datos tradicionales
no admiten esta opción.
Debido a esta circunstancia, aparecieron los motores de persistencia, cuya función es
traducir entre los dos formatos de datos: “de registros a objetos y de objetos a
registros. Persistir objetos Java en una base de datos relacional implica serializar un
árbol de objetos Java en una base de datos de estructura tabular y viceversa. Esencial
es la necesidad de mapear objetos Java para optimizar velocidad y eficiencia de la
base de datos.”11
Unidad de Persistencia. Se define como un conjunto de todas las entidades (clases)
que son gestionadas por la instancia del EntityManager en una aplicación. Este
conjunto de clases de entidad representa los datos contenidos en una la base de
datos.
La persistencia puede tener 4 estados diferentes:
Transient: Un objeto recién creado que no ha sido unido con el gestor de
persistencia.
Persistent: Un objeto enlazado con la sesión (Todos los cambios serán persistentes).
Detached: Un objeto persistente que sigue en memoria después de que termina la
sesión: existe en java y en la base de datos.
Removed: Un objeto marcado para ser descartado o eliminado de la base de datos:
existe en java y se borrará de la base de datos al terminar la sesión.
JPA - Entity Manager
Para las situaciones en donde se requiera de los servicios de un EJB container (como
por ejemplo JBoss o WebLogic application server), el API JPA provee el Container-
managed entity manager.
11
ejemplo TIW ,(2013) ,Interfaz de Persistencia, Recuperado de
http://www.lab.inf.uc3m.es/~a0080802/RAI/jpa.html
26
EntityManager
Gestor de recursos que mantiene la colección activa de objetos de entidad que está
utilizando la aplicación. EntityManager opera la interacción y metadatos de bases de
datos para las correlaciones relacionales de objetos. Una instancia de un
EntityManager representa un contexto de persistencia. Una aplicación en un
contenedor puede obtener el EntityManager mediante inyección en la aplicación o
buscándolo en el espacio de nombres del componente Java. Si la aplicación gestiona
su persistencia, el EntityManager se obtiene desde EntityManagerFactory.
Figura 2 Entity Manager
Interfaces JPA
javax.persistence.Persistence: Posee métodos estáticos que permite obtener una
instancia de Entity Manager Factory de forma independiente al vendedor de la
implementación de JPA. Una clase de inicialización que va proporcionar un método
estático para la creación de una Entity Manager Factory.
javax.persistence.EntityManagerFactory: Permite crear objetos de EntityManager
utilizando el patrón de diseño del Factory. Este objeto en tiempo de ejecución
representa una unidad de persistencia particular. Generalmente va a ser manejado
como un singleton y proporciona métodos para la creación de instancias
EntityManager.
javax.persistence.EntityManagerFactory: La clase javax.persistence.Entity es una
anotación Java que se coloca a nivel de clases Java serializarles y que cada objeto de
una de estas clases anotadas representa un registro de una base de datos.
javax.persistence.EntityManager: Es la interfaz primordial de JPA utilizada para la
persistencia de las aplicaciones. Cada Entity Manager puede realizar operaciones
CRUD (Create, Read, Update, Delete) sobre un conjunto de objetos persistentes. Es
un objeto único, no compartido que representa una unidad de trabajo particular para
27
el acceso a datos. Proporciona métodos para manejar el ciclo de vida de las instancias
entidad y para crear instancias Query.
javax.persistence.Query: Esta interface javax.persistence.Query está implementada
por cada vendedor de JPA para hallar objetos persistentes manejando cierto criterio
de búsqueda. JPA estandariza el soporte para consultas utilizando Java Persistence
Query Language (JPQL) y Structured Query Language (SQL). Podemos obtener una
instancia de Query desde una instancia de un Entity Manager.
javax.persistence.EntityTransaction: Cada instancia de Entity Manager tiene una
relación de uno a uno con una instancia de javax.persistence.EntityTransaction,
permite realizar operaciones sobre datos persistentes de manera que agrupados
formen una unidad de trabajo transaccional, en el que todo el grupo sincroniza su
estado de persistencia en la base de datos o todos fallan en el intento, en caso de
fallo, la base de datos quedará con su estado original. Maneja el concepto de todos o
ninguno para mantener la integridad de los datos.12
Especificación JPA:
El Java Persistence API (JPA) es una especificación de Sun Microsystems para la
persistencia de objetos Java a cualquier base de datos relacional.13
JPA abarca tres áreas;
-El API JPA: un conjunto de clases e interfaces que están dentro del
paquetejavax.pesistence que serán empleadas por la capa de negocio para operar con
los objetos persistentes. Se calcula que con la utilización de este API, en vez de las
clásicas instrucciones JDBC para acceso a los datos se puede conseguir un
considerable ahorro en el código de la capa de negocio.
- Mapeo objeto-relacional: Es la relación entre entidades Java y tablas de la base de
datos. Contiene la información que permite especificar al motor de persistencia la
manera en que se deben mapear los objetos con las tablas de la base de datos.
- Java Persistence Query Language (JPQL): La especificación incluye un lenguaje
de manipulación de objetos, conocido como JPQL puede definir operaciones de
tratamiento de objetos. Su sintaxis es similar a la del lenguaje SQL estándar, pero
adaptadas al tratamiento de objetos.
12
ejemplo TIW ,(2013) ,Interfaz de Persistencia Recuperado de
http://www.lab.inf.uc3m.es/~a0080802/RAI/jpa.html 13
ejemplo TIW ,(2013) ,Interfaz de Persistencia Recuperado
dehttp://www.lab.inf.uc3m.es/~a0080802/RAI/jpa.html
28
Entidades
Es un objeto de dominio de persistencia. Usualmente, una entidad representa una
tabla en el modelo de datos relacional y cada instancia de esta entidad corresponde a
un registro en esa tabla.
El estado de persistencia de una entidad se representa a través de campos persistentes
o propiedades persistentes. Estas propiedades utilizan anotaciones para el mapeo de
estos objetos en la base de datos.
El estado persistente de una entidad puede ser accesible a través de variables de
instancia a la entidad o bien a través de las propiedades de estilo de JavaBean.
Motor de Persistencia
Ventajas
El motor de persistencia aprovecha de los dos modelos:
- De la programación orientada a objetos aprovecha las ventajas de flexibilidad,
mantenimiento, reusabilidad.
- Del uso de una base de datos relacional se aprovecha de su madurez y su
estandarización así como de las herramientas relacionales que hay en ella.
Con un motor de persistencia se reduce considerablemente el código, por lo tanto el
desarrollo de la aplicación es menos costoso y su mantenimiento es más sencillo
Un motor de persistencia es una capa de software que transforma los objetos de la aplicación en registros de una base de datos relacional.
Cuando la aplicación desea enviar un objeto llama al motor de persistencia, que traduce el objeto a registros y llama a la base de datos para que guarde registros. cuando la aplicación quiere recuperar un objeto, la base de datos recupera los registros correspondientes, los cuales son traducidos en formato de objeto por el motor de persistencia.
Figura 3.Motor de Persistencia
29
Mapeo Objeto-Relacional (Object/Relational Mapping - ORM):
Técnica de programación para convertir datos entre el sistema de tipos utilizado en
un lenguaje de programación orientado a objetos y es muy utilizado en base de datos
relacional, con un motor de persistencia.
Admite manejar datos en base de datos relacionales mediante objetos.
- Facilita el desarrollo de aplicaciones basadas en base de datos relacionales (todo
son objetos).
- Permite persistencia de objetos de forma muy transparente.
- Unifica las tareas de mantenimiento de datos relacionales con la base de datos.
- Impide que el código sea dependiente de características específicas de un gestor de
base de datos concreto.
Arquitectura ORM
Ventajas
Celeridad para el desarrollo. La mayoría de las herramientas actualmente permiten la
creación del modelo por medio del esquema de la base de datos, leyendo el esquema,
nos crea el modelo correspondiente.
Conceptualización con la base de datos. Al emplear un sistema ORM, lo que
conseguidos es independizar totalmente del sistema de Base de datos que
utilicemos, y así si en un futuro debemos de cambiar de motor de bases de datos,
tendremos la seguridad de que este cambio no nos afectará a nuestro sistema,
siendo el cambio más sencillo ahorrado de manera significativa.
Figura 4 Arquitectura ORM.
30
Reutilización. Permite utilizar los métodos de un objeto de datos desde distintas
zonas de la aplicación, incluso desde aplicaciones distintas.
Seguridad. Los ORM suelen implementar sistemas para obviar tipos de ataques
como pueden ser los SQL injections.
Mantenimiento del código. Nos permite el mantenimiento del código debido a la
correcta ordenación de la capa de datos, haciendo que el mantenimiento del
código sea mucho más sencillo.
Lenguaje propio para realizar las consultas. Estos sistemas de mapeo traen su
propio lenguaje para hacer las consultas a la base de datos, lo que hace que los
usuarios dejen de utilizar las sentencias SQL para que pasen a utilizar el
lenguaje propio de cada herramienta.
El mapeo es la configuración que se tiene que escribir de modo que cada parte de la
entidad esté debidamente relacionada con algún elemento de la base de datos. Se
muestra un ejemplo la entidad Vehículos propio del presente trabajo.
Figura 5.Mapeo de Entidad
31
A continuación se describe los elementos intervenidos en la Figura.5
@Entity: Esta anotación se le indica al motor de persistencia que esta Clase es una
entidad que debe persistir en la base de datos. Todas entidades deberán irá
acompañada de la anotación @Entity la cual aparecerá por encima del nombre de la
clase.
La clase “Vehículo” se ha anotado con @Entity, lo cual informa al proveedor de
persistencia que cada instancia de esta clase es una entidad.
@Table: Con esta anotación se usa para nombrar a la tabla de la base de datos. La
anotación@Table que acompaña a la clase indica que la tabla de la base de datos
donde se persistirán los datos de las entidades “vehículos” es la tabla con nombre
Vehículo.
@Id: Esta anotación permite definir al atributo como la clave primaria de la entidad.
Dicho atributo irá acompañado por la anotación @Id.
@NamedQuery: Determina una consulta con nombre estático.
@GeneratedValue: La identidad de una entidad debe ser gestionada por el
proveedor de persistencia, así que será dicho proveedor quien le asigne un valor la
primera vez que almacene la entidad en la base de datos. Para tal efecto, se añade a la
propiedad de identidad la anotación @GeneratedValue. El atributo strategy dicta el
modo en que se generarán los nuevos identificadores, su valor se corresponde con los
de la enumeración javax.persistence.GenerationType:
AUTO: Delega al sistema gestor de base datos la elección del generador de
Identificadores. En Mysql es siempre una columna auto_ increment y en
Postgres o Oracle es una secuencia.
SEQUENCE: Usa una secuencia de base de datos para generar los
identificadores
@Column: Para cada atributo tiene una anotación @Column que indica el nombre
de la columna vinculada al atributo. Además la anotación @Column permite
especificar una serie de datos acerca de las propiedades de la columna (null, length,
etc.).Entre otros.
32
El mapeo objeto/relacional se hace mediante anotaciones en las propias clases de la
entidad.
Las anotaciones pueden aplicarse a clases, métodos o atributos. Generalmente las
anotaciones JPA se clasifican en dos categorías:
- Anotaciones de Mapeo Físico: Describen esquemas físicos de base de datos,
tablas, columnas, índices, etc. (@Table, @Column, etc.).
@Colulmn Sirve para especificar que la clave está asociada a un atributo de la tabla.
Aprovecharemos para indicar si puede ser nulo, si existe un límite de caracteres, etc.
- Anotaciones de Mapeo Lógico: Se utiliza para describir el modelo de objeto,
asociaciones de clase, etc.(@OneToOne, @OneToMany, etc).
@OneToOne. Las relaciones uno a uno utilizan anotaciones de la persistencia de
java.
@OneToManyLas relaciones uno a muchos utilizan anotaciones de la persistencia de
java "OneToMany" en los campos o propiedades persistente.
Arquitectura JPA
Figura 6 : Relación entre los componentes principales de la Arquitectura de JPA
A continuación se describe los componentes principales de la arquitectura de JPA:
Figura 6.Arquitectura JPA
33
-Persistence: La clase javax.persistence.Persistence contiene métodos estáticos de
ayuda para obtener una instancia de EntityManagerFactory.
-EntityManagerFactory: clase javax.persistence.EntityManagerFactory nos permite
crear objetos de EntityManager utilizando el patrón de diseño del Factory.
-EntityManager:La clase javax.persistence.EntityManager es la interfaz principal de
JPA utilizada para la persistencia de las aplicaciones. Gestiona el acceso a la base de
datos.EntityManager permite realizar operaciones como (Crear, leer, Actualizar,
Borrar) sobre un conjunto de objetos persistentes. Además esta interfaz ofrece los
métodos con los que se interactúa con el entorno de persistencia (Control de
Transacciones, Gestión del Ciclo de vida de las entidades, creación de
consultas/query).
-Entity: La clase javax.persistence.Entity es una anotación Java que se coloca a nivel
de clases Java y que cada objeto de una de estas clases anotadas representa un
registro de una base de datos relacionada.
-EntityTransaction: Cada instancia de EntityManager tiene una relación de uno a
uno con una instancia de javax.persistence.EntityTransaction, permite operaciones
sobre datos persistentes de manera que agrupados formen una unidad de trabajo
transaccional, en el que todo el grupo sincroniza su estado de persistencia en la base
de datos o todos fallan en el intento, en caso de fallo, la base de datos quedará con su
estado original. Maneja el concepto de todos o ninguno para mantener la integridad
de los datos
-Query: La interface javax.persistence.Query está implementada por cada vendedor
de JPA para localizar objetos persistentes manejando cierto criterio de búsqueda.
JPA estandariza el soporte para consultas utilizando Java Persistence Query
Language (JPQL) y Structured Query Language (SQL). Podemos obtener una
instancia de Query desde una instancia de un EntityManager.
Métodos de la interfaz EntityManager
La interfaz EntityManager define una serie de métodos que permiten manejar el ciclo
de vida de las entidades de una aplicación14
Estos métodos incluyen:
-persist (): Cuando se ha creado e inicializado una instancia de una entidad, se
invoca al método persist (Object) del EntityManager, que recibe como parámetro el
14
laboratorio Integración de sistemas ,(2012.), Taller de sistemas de información Recuperado de
https://www.fing.edu.uy/inco/cursos/tsi/TSI2/2012/teorico/tsi2-05-persistencia.pdf
34
objeto de una clase y lo persiste en la base de datos. Esta operación permitirá insertar
los datos de la entidad en la base de datos y la llevará al estado Gestionada.15
-Búsqueda () : permite buscar una Entidad por su clave primaria. Cuando se hace la
llamada a este método, el EntityManager lanza una instrucción SQL de tipo Select a
la base de datos para recuperar los datos de la instancia asociada a la clave primaria
proporcionada como parámetro. Una vez recuperados los datos, crea una instancia, la
rellena con los datos yla devuelve al programa.
-remove (): La operación EntityManager.remove (Object) recibe un objeto de una
clase, y lo elimina de la base de datos. Después de realizar esta operación, el objeto
queda en estado Eliminada. Al terminar la transacción, se ejecuta una sentencia
DELETE.16
-refresh(): La operación EntityManager.refresh (Object) recibe un objeto de una
clase y sincroniza su estado con el de la base de datos. Es decir, actualiza el objeto
obteniendo los valores de sus atributos y relaciones de la base de datos. Si la
instancia se encuentra en estado Desconectada al llamar a refresh (), pasará de nuevo
a Conectada tras invocar al método.
-merge(): La operación EntityManager.merge (Object) sincroniza el estado de un
objeto en la base de datos. Por lo tanto, pasará al estado Gestionada la instancia que
se le proporcione como parámetro, actualizando la base de datos con los datos de la
entidad. Al terminar la transacción, se ejecuta una sentencia UPDATE.17
15
laboratorio Integración de sistemas ,(2012.), Taller de sistemas de información Recuperado de
http://www.fing.edu.uy/inco/cursos/tsi/TSI2/2012/teorico/tsi2-05-persistencia.pdf 16
laboratorio Integración de sistemas ,(2012),Taller de sistemas de información, Recuperado de
http://www.fing.edu.uy/inco/cursos/tsi/TSI2/2012/teorico/tsi2-05-persistencia.pdf 17
laboratorio Integración de sistemas ,(2012),Taller de sistemas de información, Recuperado de
Fuente http://www.fing.edu.uy/inco/cursos/tsi/TSI2/2012/teorico/tsi2-05-persistencia.pdf
35
Lenguaje de consulta de persistencia de Java
PQL está preparado para el lenguaje de consulta de persistencia de Java. Se utiliza
para crear consultas contra entidades para almacenar en una base de datos
relacional. JPQL está desarrollado en base a la sintaxis SQL. Pero no afectará
directamente a la base de datos.
JPQL puede obtiene datos mediante la cláusula SELECT, puede utilizar cláusula
UPDATE y DELETE.
Estructura de consulta
JPQL es muy semejante a la sintaxis utilizada en SQL. Tener SQL como sintaxis es
una ventaja porque SQL es simple y siendo ampliamente utilizado. SQL
directamente con la base de datos relacional tablas, registros y campos, mientras que
JPQL trabaja con Java clases e instancia.
Una consulta JPQL puede obtener una entidad objeto en lugar de campo conjunto
de resultados de una base de datos, al igual que con SQL. El JPQL consulta
estructura como sigue.
Figura 7.Estructura Sentencia JPQL
Características de JPQL:
- La cláusula FROM maneja nombres de Entidades.
- Nombres de campos usan notación Java: Entidad. Atributo.
- Los elementos manejados en WHERE o devueltos por SELECT son siempre
objetos.
- Se permiten consultas de tipo SELECT, UPDATE y DELETE
36
Hibernate
Es una herramienta que permite el mapeo objeto/relacional que se utiliza en
ambientes Java. Además no solo se encarga del mapeo de clases Java a tablas de la
base de datos (y de regreso), adicionalmente maneja los queries y recuperación de
datos, lo que ahorra de forma significativa el tiempo de desarrollo que de otra forma
gastaríamos manejando los datos de forma manual con SQL y JDBC, encargándose
de esta forma de alrededor del 95% de las tareas comunes relacionadas con la
persistencia de datos, manejando todos los problemas relativos con la base de datos
particular con la que estemos trabajando, de forma transparente.
El siguiente grafico brinda una perspectiva a alto nivel de la arquitectura de
Hibernate:
Figura 8.Arquitectura de Hibernate
37
La arquitectura "completa" abstrae la aplicación de las APIs de JDBC/JTA y permite
que Hibernate se encargue de los detalles.
Figura 9.Arquitectura completa de Hibernate
2.5.4 JavaServer Faces(JSF)
JavaServer Faces (JSF) es una tecnología y framework para aplicaciones Java
basadas en web que simplifica el desarrollo de interfaces hacia el usuario en
aplicaciones Java EE.
JSF como tecnología incluye:
Contiene un conjunto de APIs para representar componentes de una interfaz
de usuario y administrar su estado, manejar eventos, validar entrada, definir
un esquema de navegación de las páginas.
Un conjunto por defecto de componentes para la interfaz de usuario.
Dos bibliotecas de etiquetas personalizadas para JavaServer Pages que
permiten expresar una interfaz JavaServer Faces dentro de una página JSP.
Un modelo de eventos en el lado del servidor.
Administración de estados.
Controla los Beans administrados.
38
La tecnología JSF es un marco para el desarrollo, la construcción de componentes de
la interfaz de usuario del servidor de lado y utilizarlos en una tecnología de
aplicación. Esta tecnología web se radica en la arquitectura Modelo Vista
Controlador (MVC) para la separación de la lógica de la presentación.
Una aplicación realizada con JSF es semejante a cualquier otra aplicación web
basada en la tecnología de Java; que se ejecuta en un contenedor de servlets Java y
contiene.
Componentes JavaBeans como modelos que contienen funcionalidad y los
datos específicos de la aplicación.
Una biblioteca de etiquetas personalizadas para la representación de los
controladores de eventos y validadores para la aplicación.
Una biblioteca de etiquetas personalizadas para la prestación de los
componentes de interfaz de usuario.
Elementos de interfaz de usuario representado como objetos con estado en el
servidor.
Clases de ayuda del lado del servidor
Validadores, controladores de eventos y controladores de navegación.
Contiene archivo de recursos de configuración de aplicaciones para la
configuración de recursos de la aplicación.
39
Las principales implementaciones de la tecnología JSF son:
JSF Reference Implementation de Sun Microsystems.
MyFaces proyecto de Apache Software Foundation.
RichFaces, Primeface de Jboss. Trae componentes adicionales para crear
aplicaciones más llamativas.
ICEfaces Contiene diversos componentes para interfaces de usuarios más
enriquecidas.
Figura 10.jsf Arquitectura
40
2.5.5 PrimeFaces
Es una librería de componentes para JavaServer Faces (JSF) de código abierto que
cuenta con un conjunto de componentes enriquecidos que facilitan la creación de las
aplicaciones web18
El punto fuerte e interesante de PrimeFaces es la sencillez de instalación y lo poco
pesado que es. El mantenerlo liviano, sin complicaciones a la hora de instalarlo, es
decir, sin dependencias ni configuraciones complicadas, hace que podamos estar
usándolo de forma muy rápida.
Algunas características de PrimeFaces
Un conjunto interesante de componentes (editor HTML, autocompletado,
gráficas,…)
Soporte para Ajax, basándose en el estándar JSF 2.0 Ajax API
Sin dependencias, ni configuraciones, además de ser muy fácil de usar.
Un verdadero apoyo para interfaces de usuario sobre dispositivos móviles, nos
provee de un kit para esta falta.
Múltiples temas de a paciencia, preparado para usar.
La documentación, para mi forma de entender, está muy currada y organizadita
Amplia difusión del framework, con lo cual existe una comunidad que respalda
al proyecto.
2.6 Arquitectura Tecnológica.
La arquitectura que se utilizara en el presente trabajo es Modelo Vista Controlador
(MVC); en el lado del servidor se implementara Jboss es un servidor de aplicaciones
J2EE de código abierto, con base datos Postgres, contara con toda la infraestructura
necesaria para su correcto funcionamiento; por su parte del lado del cliente se
requiere únicamente que estos cuenten con un Navegador Web compatible.
18
PrimeFaces,(2005),Wikipedia, Recuperado de https://es.wikipedia.org/wiki/PrimeFaces
41
Aplicaciones Web
En la plataforma Java EE, componentes Web proporcionan las capacidades de
extensión dinámicos para un servidor web. Componentes Web pueden ser servlets
Java, páginas web implementados con tecnología JavaServer Faces, puntos finales de
servicios web, o páginas JSP. La interacción entre un cliente web y una aplicación
web que usa un servlet. El cliente envía una solicitud HTTP al servidor web. Un
servidor web que implementa la tecnología Java Servlet y JavaServer Pages
convierte la petición en un objeto HTTPServletRequest.
Figura 11.modelo-vista-controlador
2.6.1 Modelo-Vista –Controlador
MVC (por sus siglas en inglés) es un patrón de diseño de arquitectura de software
usado especialmente en aplicaciones que manejan gran cantidad de datos y
transacciones complejas donde se requiere una mejor separación de conceptos
para que el desarrollo esté estructurado de una mejor manera, permitiendo la
programación en diferentes capas de manera paralela e independiente. MVC
sugiere la separación del software en 3 estratos: Modelo, Vista y Controlador, los
cuales serán explicados en breve:
42
1. Modelo
Es la representación de la información que maneja la aplicación, interactúa
mediante jdbc a través de la capa de presentación con el servidor de base de
datos a utilizar.
2. Vista
Es la representación del modelo en forma gráfica utilizable para la interacción
con el usuario.
3. Controlador
Responsable de la lógica operacional de negocio. Traslada las peticiones de la
capa de vista a la de modelo, y según la respuesta, la redirección o no a la
capa vista. Carga objetos y opera de forma permanente.
Ciclo de vida de MVC
El ciclo de la vida de MVC es normalmente representado por las 3 capas anteriores
descritas.
La siguiente figura representa el ciclo de vida de MVC:
Figura 12.Ciclo de vida MVC
Ventajas y Desventajas de MVC
Las principales ventajas de hacer uso del patrón MVC son:
La independencia del Modelo de la Vista, es decir, separar los datos de la
representación visual de los mismos.
Es mucho más sencillo agregar múltiples representaciones es de los mismos
datos o información.
Facilita agregar nuevos tipos de datos según sea requerido por la aplicación
43
ya que eso facilitan independientes del funcionamiento de las otras capas.
Permite el mantenimiento en caso de errores.
Crean dependencia de funcionamiento.
Las des ventajas de seguir el planteamiento de MVC
La cantidad de archivos a mantener y desarrollar se incrementa de manera
considerablemente.
La independencia de conceptos en capas agrega complejidad al sistema.
2.7 Servidor JBoss
JBoss es un servidor de aplicaciones J2EE de código abierto implementado en Java
puro. Al estar basado en Java, JBoss puede ser utilizado en cualquier sistema
operativo que lo soporte.
Las características destacadas de JBoss incluyen:
Es un producto de licencia de código abierto.
Cumple los estándares.
Confiable a nivel de empresa u organizaciones
Incrustable, orientado a arquitectura de servicios.
Flexibilidad consistente
Figura 13.Servidor Jboss
44
2.8 PostgresSQL
Una base de datos es un conjunto de datos almacenados que se definen una sola vez,
y que son diseñadas para satisfacer los requerimientos de información de una
empresa u organización.
PostgreSQL es un sistema de gestión de bases de datos objeto-relacional, distribuido
bajo licencia BSD y con su código fuente disponible libremente.19
PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de multi
hilos para garantizar la estabilidad del sistema. Un fallo en uno de los procesos no
afectará el resto y el sistema continuará funcionando.
Y por su licencia libre, cualquier persona puede usar, modificar y distribuir
PostgreSQL de manera libre y gratuita para cualquier propósito
Breve historia de Postgres
El Sistema Gestor de Bases de Datos Relacionales Orientadas a Objetos conocido
como PostgreSQL, está obtenido del paquete Postgres escrito en Berkeley. Con cerca
de una década de desarrollo tras él, PostgreSQL es el gestor de bases de datos de
código abierto más avanzado hoy en día, ofreciendo control de concurrencia multi-
versión, soportando casi toda la sintaxis SQL (incluyendo sub consultas,
transacciones, y tipos y funciones definidas por el usuario), contando también con un
abanico de conjunto de enlaces con lenguajes de programación.
Características
Bases de datos de nivel empresarial u organizacional.
Multiplataforma: admitida en los sistemas operativos más populares,
incluyendo GNU/Linux, UNIX ( Mac OS X, Solaris, Tru64) y Windows.
Altamente escalable tanto en la cantidad de datos que puede administrar
como en el número de usuarios concurrentes que puede manejar.
Procedimientos almacenados (en diferentes lenguajes)
Almacenamiento de objetos binarios grandes, incluyendo imágenes, sonido y
video.
Recursos de interfaces de programación nativas para C/C++, Java, .Net, Perl,
Python, Ruby, Tcl, ODBC, entre otros.
De almacenamiento confiable, consistente, robusto.
19
Martínez ,R,(2013) ,Postgres-es, Recuperado dehttp://www.postgresql.org.es/sobre_postgresql
45
De manipulación potente, flexible y eficiente
Presenta soporte completo en Atomicidad, Consistencia, Aislamiento,
Durabilidad.
Atomicidad: En una transacción o se realizan todas las operaciones correctamente o
no se realiza ninguna. Si una parte de la transacción falla, falla toda la transacción y
el estado de base de datos no se modifica. Esto garantiza que “una transacción
incompleta” no puede existir.20
Consistencia: Permite que la base de datos jamás se queda en un estado intermedio
de una transacción. Si una base de datos queda consistente antes de ejecutarse la
transacción debe seguir siendo consistente después de ejecutarse la transacción.
Aislamiento: Mantiene separadas las transacciones de usuarios distintos hasta que
éstas han terminado.
Durabilidad: Es la propiedad que asegura que una vez realizada la operación, ésta
persistirá y no se podrá deshacer aunque falle el sistema.
PostgreSQL contiene todo lo referente a un gestor de Base de Datos Relacional:
-Procedimientos almacenados
- Disparadores (triggers).
- Vistas (views).
- Reescritura de consultas.
- Integridad Referencial.
- Reglas (Rules).
- Restricciones (Constraints)
- Orientación a objetos con herencia de tablas.
Ventajas
-Menor coste de mantenimiento.
- Mayor seguridad.
- Bajo costo.
- Instalación ilimitada.
- Mayores tiempos de desarrollo.
- Multiplataforma.
- Diseñado para ambientes de alto volumen.
20
Martínez, R,(2013) ,Postgres-es, Recuperado dehttp://www.postgresql.org.es/sobre_postgresql
46
2.9 Metodología de Desarrollo de Software XP
HISTORIA
La programación extrema (XP) es un enfoque de la ingeniería de software creado
por Kent Beck, autor del libro sobre la materia, Extreme Programming Explained:
Embrace Change (1999). Se encuentra entre los más destacado de los procesos ágiles
de desarrollo de software. Al igual que éstos, la programación extrema se diferencia
de las metodologías tradicionales principalmente en que pone más énfasis en la
adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los
cambios de requisitos sobre la marcha de un software, son un aspecto natural,
inevitable e incluso deseable del desarrollo de proyectos. Admiten que ser capaz de
adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es
una aproximación mejor y más realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los
requisitos.
Es una metodología de desarrollo de software de forma ágil existente, como parte
fundamental se centrada en potenciar las relaciones interpersonales como clave para
el éxito en desarrollo de software, fomentando el trabajo en equipo, preocupándose
por el aprendizaje de los desarrolladores, y favoreciendo un buen clima de trabajo.
Su objetivo es aumentar la productividad al desarrollar software.
CARACTERÍSTICAS XP
Metodología fundamentada en prueba y error.
Fundamentada en Valores y Prácticas
Ágil para el desarrollo.
Principales valores XP
Comunicación
Sencillez
Retroalimentación
Valentía
47
Comunicación
“Todos son parte del equipo y nos comunicamos cara a cara todos los días.
Trabajamos juntos en todo, desde los requerimientos hasta la programación. En
equipo crearemos la mejor solución al problema.”21
Esta metodología eliminar con este esquema, la comunicación se realiza mediante de
transferencia de conocimientos en reuniones constantes frente a frente entre usuarios
y programadores, lo que le da a ambos una visión compartida del sistema.
Sencillez
“Desarrollaremos lo que sea solicitado y necesario, pero no más que eso. De esa
forma, se maximiza el valor de la inversión realizada. Nos dirigiremos a nuestro
objetivo a pasos simples y pequeños, mitigando las fallas a medida que ocurran.
Crearemos algo de lo cual podamos sentirnos orgullos y que pueda mantenerse en el
largo plazo a costos razonables.”22
Esta metodología empieza desarrollando las soluciones más sencillas posibles
necesarias para solventar los requerimientos que se están analizando en ese instante,
aumentando funcionalidad extra más tarde, en la medida en que se avanza y se
obtiene más información de los problemas.
Retroalimentación
Concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor
oportunidad de dirigir el esfuerzo eficientemente.
Valentía
Diseñar y desarrollar para hoy y no para después, evitando así hacer énfasis en el
diseño en disminuyendo de todo lo demás.
Inspeccionar constantemente el código y modificar lo, de tal manera que futuros
cambios se puedan implementar más fácilmente.
21
Pmoinformatica.com, (2012), La Oficina de Proyectos de Informática ,Recuperado de
,http://www.pmoinformatica.com/2012/11/los-5-valores-de-la-programacion.html 22
Pmoinformatica.com, (2012), La Oficina de Proyectos de Informática ,Recuperado de
http://www.pmoinformatica.com/2012/11/los-5-valores-de-la-programacion.html
48
Figura 14 Metodología de XP
PLANEACIÓN
La planeación es la etapa inicial del proyecto en la metodología XP. Esta etapa se
comienza a interactuar con el cliente y el grupo de desarrollo para descubrir
necesidades del sistema.
En esta etapa está compuesta de los elementos, los cuales son los siguientes.
Historias de usuario, velocidad del proyecto, iteraciones, entregas pequeñas,
reuniones, roles en XP, traslado del personal y ajuste a XP.
Historias de usuario
El sistema es desarrollado para el cliente, por lo tanto que, el usuario es quien
decide que tareas realizará la aplicación.
• Las historias de usuario tienen el mismo propósito que los casos de uso.
• Son descritas por los propios clientes, tal y como ven las necesidades del
sistema.
49
Figura 15 Historia del cliente
Velocidad del proyecto
Es una medida de la capacidad que tiene el trabajo de programadores para evacuar
las historias del usuario en una determinada iteración. Esta medida se calcula
totalizando el número de historias entregadas por usuario.
Recordar que la velocidad del proyecto ayuda a determinar la cantidad de historias
que se pueden implementar en las siguientes iteraciones, aunque no de manera
exacta.
Interacción
La metodología XP, la producción del sistema se divide en etapas para facilitar su
realización. Por lo general, los proyectos constan de más de tres etapas, las cuales
toman el nombre de iteraciones, de allí se obtiene el concepto de metodología
50
iterativa. El tiempo ideal de una iteración es de una a tres semanas, con cada
iteración se define un módulo o conjunto de historias que se van a implementar.
Entregas
El tiempo de una iteración varía entre unas y tres semanas, al final de la cual habrá
una entrega de los avances del producto, estos deberán ser completamente
funcionales. Estas entregas deben caracterizarse por ser frecuentes.
Reuniones
En esta metodología XP se necesita de una revisión continua del plan de trabajo. A
pesar de ser una metodología que evita la documentación exagerada, es muy estricta
en la organización del trabajo.
DISEÑO
En la metodología XP solo se diseñan aquellas historias de usuario que el cliente ha
seleccionado para la iteración actual por dos motivos importantes:
Primero se considera que no es posible tener un diseño completo del sistema y sin
errores desde el principio.
Segundo es que dada la naturaleza variante del proyecto, al realizar un diseño muy
extenso en las fases iniciales del proyecto para luego modificarlo, se considera un
desperdicio de tiempo.
Simplicidad
Parte muy importantes de la filosofía XP es la simplicidad en todos los aspectos.
Se considera que un diseño sencillo se logra más rápido y se implementa en
menos tiempo, por lo cual esto es lo que se busca en esta metodología.
Metáfora del Sistema
Se trata de realizar la implementación de la arquitectura de sistema en una “historia”
con la cual se les da a los programadores una misma visión sobre el proyecto
además de brindarles un primer vistazo muy completo a los nuevos integrantes del
grupo para hacer su adaptación más rápida.
51
Tarjetas CRC
La principal funcionalidad que tienen estas, es ayudar a dejar el pensamiento
procedimental para incorporarse al enfoque orientado a objetos.
Soluciones Puntales
El equipos de programadores se enfrentan a requerimientos de los clientes (en este
caso historias de usuario)
La metodología XP aborda este problema, se trata de una pequeña aplicación
completamente desconectada del proyecto con la cual se intenta explorar el
problema y propone una solución potencial.
Refactorización
La refactorización en el código pretende conservarlo tan sencillo y fácil de mantener
como sea posible. En cada inspección realizada que se encuentre alguna redundancia,
funcionalidad no necesaria o aspecto en general por corregir, se debe rehacer esa
sección de código con el fin de lograr las metas de sencillez tanto en el código en sí
mismo como en la lectura y mantenimiento posterior.
DESARROLLO
El desarrollo es un proceso que se realiza en forma paralela con el diseño y la cual
está sujeta a varias observaciones por parte de XP consideradas controversiales por
algunos expertos tales como la rotación de los programadores o la programación en
parejas.
Cliente siempre presente
Parte fundamental en la metodología de XP es que el cliente esté siempre presente o
disponible. No solamente para solucionar las dudas del grupo de programadores,
debería ser parte de éste. En este sentido se convierte en gran ayuda al solucionar
todas las dudas que puedan surgir, especialmente frente a frente, para garantizar
que lo implementado cubre con las necesidades planteadas en las historias de
usuario.
52
Codificación primera prueba
Una de las ventajas de crear una prueba antes que el código es que permite
identificar los requerimientos de dicho código. Es decir, al escribir primero las
pruebas se encuentran de una forma más sencilla y con mayor claridad todos los
casos especiales que debe considerar el código a implementar.
Programación en parejas
En la metodología XP cuando se trabaja en parejas se obtiene un diseño de mejor
calidad y un código más organizado y con menores errores que si se trabajase solo,
además de la ventaja que representa contar con un compañero que ayude a
solucionar inconvenientes en tiempo de codificación, los cuales se presentan con
mucha frecuencia al momento de programar.
Integración Secuencial
La metodología XP propone que se emplee un esquema de turnos con el cual solo
una pareja de programadores integre a vez. Con lo cual se tiene plena seguridad de
cuál es la última versión liberada y se le podrán hacer todas las pruebas para
garantizar que funcione correctamente.
Integración frecuentes
XP propone que se deben hacer integraciones cada pocas horas y siempre que sea
posible no debe transcurrir más un día entre una integración y otra. De esta forma
se garantiza surjan problemas como que un programador trabaje sobre versiones
obsoletas de alguna clase.
PRUEBAS
La metodología XP enfatiza mucho los aspectos relacionados con las pruebas,
clasificándolas en diferentes tipos y funcionalidades específicas, indicando quién,
cuándo y cómo deben ser implementadas y ejecutadas.
Del buen uso de las pruebas depende el éxito de otras prácticas, tales como
la propiedad colectiva del código y la refactorización.
Cuando se tienen bien implementadas las pruebas no habrá temor de
modificar el código del otro programador en el sentido que si se daña alguna
sección, las pruebas mostrarán el error y permitirán encontrarlo.
XP considera que se debe ser muy estricto con las pruebas. Sólo se deberá liberar
una nueva versión si esta ha pasado con el cien por ciento de la totalidad de las
pruebas.
53
Pruebas Unitarias
La implementación de pruebas unitarias completas facilitan la liberación continua
de versiones por cuanto al implementar algo nuevo y actualizar la última versión,
solo es cuestión de ejecutar de forma automática las pruebas unitarias ya creadas
para saber que la nueva versión no contiene errores.
Pruebas de aceptación
La metodología XP, con templa pruebas de aceptación que son pruebas de caja
negra, que representan un resultado esperado de determinada transacción con el
sistema. Para que una historia de usuario se considere aprobada, deberá pasar todas
las pruebas de aceptación elaboradas para dicha historia.
Pruebas funcionales o de aceptación son supervisadas por el cliente basándose en los
requerimientos tomados de las historias de usuario.
Ventajas
• Programación organizada.
• Menor taza de errores.
• Satisfacción del programador
• Se evita de gran manera la documentación con en RUP
Desventajas
• Es recomendable emplearlo solo en proyectos a corto plazo.
• Altas comisiones en caso de fallar
2.10 Diseñador de Reportes
Una parte fundamental en general de los sistemas es a la hora de mostrar la
información resultante de los procesos de las aplicaciones, principalmente, cuando
esto implica tomar decisiones comerciales o gerenciales.
En la actualidad, existen diversas librerías y herramientas dedicadas (varias de ellas,
Open Source) para la rápida generación de reportes. Una de ellas es la librería
JasperReport, una de las más conocidas e interesantes, que, combinada con
herramientas para el diseño, facilita y agiliza la generación, la pre-visualización y la
impresión de los reportes.
54
JasperReports es una librería de creación de informes que tiene la habilidad de
entregar contenido enriquecido al monitor, a la impresora o ficheros PDF,
HTML, XLS, CSV y XML23
Es precisamente una poderosa herramienta para generar reportes en java, con la
habilidad de producir contenido completo para la pantalla, directo para impresora o
en diferentes formatos de archivo. Está completamente escrito en java y es libre
Funcionamiento de JasperReports
El usuario diseña el reporte codificándolo en XML de acuerdo a las etiquetas y
atributos definidos en un archivo llamado jasperreports.dtd (parte de JasperReports).
Usando XML el usuario define completamente el reporte, describiendo dónde
colocar texto, imágenes, líneas, rectángulos; cómo adquirir los datos; cómo realizar
ciertos cálculos para mostrar totales, etc.
Este archivo fuente XML debe ser compilado para obtener un reporte real. La
versión compilada del fuente es nombrada "archivo jasper" (este termina con .jasper).
Un Archivo jasper es el compilado de un código fuente. Cuando se tiene un archivo
jasper, se necesita otra cosa para producir un reporte: “datos”. Para proporcionar
estos registros al “jasperengine” se necesita presentarlos usando una interfaz especial
específica llamada JRDataSource. Una fuente de datos + un Archivo jasper = un
“archivo print”. Un “archivo print” puede exportarse en muchos formatos como PDF,
HTML, RTF, XML, XLS, CVS, etc. Jasper tiene disponible un visualizador especial
para desplegar la vista previa de un reporte; diseñado para aplicaciones tradicionales
de Java basadas en Swing.
Alguna de las principales características.
- Tiene diseño del informe flexible.
- Se puede presentar datos textualmente o gráficamente.
- Los desarrolladores pueden proporcionar datos de múltiples maneras.
- Se puede aceptar datos de múltiples fuentes de datos.
- Puede generar marcas de agua. (Una marca de agua es como una imagen
secundaria que se coloca sobre la imagen principal)
- Puede generar sub informes.
- Es capaz de exportar informes a una variedad de formatos.
23
JasperReports,(2014),Wikipedia, Recuperado de https://es.wikipedia.org/wiki/JasperReports
55
CAPITULO III
3 Desarrollo del Proyecto
El propósito de este documento consiste en definir con claridad los requerimientos
del aplicativo “SISTEMA PARA USO Y CONTROL DE LA FLOTA
VEHICULAR DE LA UNIVERSIDAD CENTRAL DEL ECUADOR”.
El aplicativo se basa principalmente en cumplir con los objetivos administrativos de
Dirección General Administrativa Universidad Central Del Ecuador; es por ello, que
el sistema permitirá gestionar y emitir el documento habilitante para la circulación
de un vehículo de la flota vehicular de la institución.
3.1 Planeación
En la metodología XP al permitir en su fase inicial ser muy semejante a los casos
de uso en dicha metodología se llamas historias de usuario, a continuación se detalla
los casos de uso del presente proyecto.
Especificación de casos de uso
Los casos de uso son parte del análisis, nos ayudan a describir qué es lo que el
sistema debe hacer desde el punto de vista de los usuarios. Es decir, describen un uso
del sistema y cómo este interactúa con el usuario.
Un diagrama de casos de uso consta de los siguientes elementos:
Actor.
Casos de Uso.
Relaciones de Uso, Herencia y Comunicación
Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar
el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente
representa a una persona en particular, sino más bien la labor que realiza frente al
sistema.
Figura 16.Actor
56
Casos de Uso es una operación/tarea específica que se realiza tras una orden de
algún agente externo, sea desde una petición de un actor o bien desde la invocación
desde otro caso de uso.
Relaciones de Uso, Herencia y Comunicación
- Asociación Es el tipo de relación más básica que indica la invocación desde
un actor o caso de uso a otra operación (caso de uso). Dicha relación se
denota con una flecha simple.
- Dependencia o Instanciación Es una forma muy particular de relación entre
clases, en la cual una clase depende de otra, es decir, se instancia (se crea).
Dicha relación se denota con una flecha punteada
- Generalización Este tipo de relación es uno de los más utilizados, cumple
una doble función dependiendo de su estereotipo, que puede ser de Uso
(<<uses>>) o de Herencia (<<extends>>).
Figura 17.Caso de Uso
Figura 18.Asociación
Figura 19.Dependencia
Figura 20.Gerneralizacion
57
Caso de Uso: Administrar Cuentas de Usuarios
Figura 21.Administrar Cuentas de Usuarios
Descripción Breve: En este caso de uso se describe el proceso que se realiza para la
administración de cuentas de usuarios; así como también la asignación de permisos a
los usuarios. Esta información está relacionada a las Tablas “Usuarios”, “Menu"
"Rol".
Los usuarios del sistema de control y uso para la flota vehicular de la Universidad
Central del Ecuador son .Administrador del sistema, Responsable del área vehicular
en la Dirección General Administrativa.
Flujo básico de Eventos:
- El Administrador para iniciar la sesión debe ingresar el nombre de usuario y
la clave.
- Accede a toda las opciones en un panel izquierdo de la aplicación
Crear cuentas de usuario
- El administrador observara campos listo para el ingreso
- El sistema pide introducir los datos de la cuenta.
- El administrador introduce los datos.
58
- Al finalizar guarda la información presionando el botón Guardar.
Asignar Permisos:
El administrador elige la opción “Rol” para asignar a cada usuario el rol
correspondiente a las páginas o formulario que se desea tenga acceso.
Actualizar Datos de Usuario
El administrador busca y selecciona la cuenta de Usuario.
- Una vez cargada la información, presiona el icono [Actualizar] para habilitar los
campos de actualización.
- El administrador actualiza los datos.
- Al finalizar guarda la información presionando el botón Actualizar.
Eliminar Usuario.
El administrador busca y selecciona la cuenta de Usuario.
- Una vez cargada la información, presiona el botón [Eliminar].
- El administrador observara el mensaje de confirmación
- La cuenta de usuario es eliminada.
Flujos Alternativos:
- Cancelar el ingreso, actualización o anulación de la información.
- Salir del Sistema
Precondiciones:
- Tener previamente registrada la cuenta de usuario del Administrador con permisos
para administrar todo el sistema.
- Tener registrado los nombres de los formularios del Sistema.
Pos condiciones:
- Los usuarios quedan registrados en la base de datos del sistema.
- Cada usuario debe tener asignado permisos a los formularios que le corresponda
tener acceso.
59
Caso de Uso: Administrar información de Marcas y
Modelos de Vehículos
Figura 22.Informacion Vehículos
Descripción Breve: En este caso de uso se describe el proceso de administración de
Marcas y Modelos de Vehículos Las tablas que se involucran en este proceso son
“Marcas”,”Modelo”,”Vehiculo”.
El Administrador del Sistema es la persona encargada de realizar el registro,
búsqueda, actualización y eliminación de Marcas y Modelos de Vehículos.
Flujo Básico de Eventos:
Registrar Marcas y Modelos de Vehículos:
- El Administrador ingresa al sistema, selecciona del menú “Vehículo Marca”
- El sistema pide introducir los datos de la Marca y de los modelos de vehículos.
- El administrador ingresa los datos de la Marca. Además, cada marca puede tener
uno o varios modelos de vehículos.
- Al pulsar el botón Guardar de este formulario, se cargará. de esta manera quedarán
guardadas las marcas con sus respectivos modelos de vehículos.
60
Para el manejo adecuado de la información, es recomendable establecer estándares
para los modelos de los vehículos, en relación a las características que serán
incluidas en el nombre o descripción del mismo.
Actualizar información de Marcas y Modelos:
- El administrador busca y selecciona la Marca.
- Una vez cargada la información, presiona el botón Actualizar para habilitar los
campos de actualización
- El administrador actualiza los datos de la Marca y de los modelos.
- Al finalizar actualizar la información presionando el botón actualizar.
Eliminar una Marca:
- El administrador busca y selecciona la Marca.
- Una vez cargada la información, presiona el botón Eliminar.
- El administrador debe observar el mensaje de confirmación.
- La marca eliminada.
Flujos Alternativos:
- Cancelar el ingreso, actualización o eliminación del registro.
- Salir del Sistema.
Pos condiciones:
Las marcas y modelos de Vehículos quedarán registrados de tal manera que puedan
ser seleccionados en el Formulario “Vehículos”.
61
Caso de Uso: Administrar información de Facultades, Vehículo.
Descripción Breve: En este caso de uso se describe el proceso de administración de
Facultades, Vehículos Las tablas que se involucran en este proceso son
“Facultad”,”Vehículo”.
El Administrador del Sistema es la persona encargada de realizar el registro,
búsqueda, actualización y eliminación Facultad, Vehículos.
Flujo Básico de Eventos:
Registrar Facultad:
- El Administrador ingresa al sistema, selecciona del menú “Facultad”
- El sistema pide introducir los datos de la Facultad y de los datos respectivos.
- El administrador ingresa los datos de la Facultad.
- Al pulsar el botón Guardar de este formulario, se cargará. De esta manera quedarán
guardada las facultades.
Figura 23.Facultades Vehículo
62
Actualizar información de Facultad:
- El administrador busca y selecciona la Facultad.
- Una vez cargada la información, presiona el botón Actualizar para habilitar los
campos de actualización
- El administrador actualiza los datos de la Facultad.
- Al finalizar actualizar la información presionando el botón actualizar.
Eliminar una Marca:
- El administrador busca y selecciona la Facultad.
- Una vez cargada la información, presiona el botón Eliminar.
- El administrador debe observar el mensaje de confirmación.
- La Facultad eliminada.
Flujos Alternativos:
- Cancelar el ingreso, actualización o eliminación del registro.
- Salir del Sistema.
Pos condiciones:
Las Facultades quedarán registrados de tal manera que puedan ser seleccionados en
el Formulario “Vehículos”.
63
Caso de Uso: Elaborar de Salvoconducto.
Descripción Breve: En este caso de uso se describe el proceso de elaboración de
salvoconducto,Las tablas que se involucran en este proceso son
“Facultad”,”Vehículo”.”Usuario”,”Salvoconducto Vehículo”.
El Jefe departamental en el Sistema es la persona encargada de realizar la
elaboración del salvoconducto.
Flujo Básico de Eventos:
Registrar Cuerpo de Permiso:
- El Jefe departamental ingresa al sistema, selecciona del menú “Salvoconducto
Vehículo”
- El sistema pide introducir los datos de la Salvoconducto, Vehículoy fecha y
actividades de mismo.
- Al pulsar el botón Guardar de este formulario, se cargará. De esta manera quedarán
Guardado en la base de datos y en historial del mismo.
Figura 24.Elaboracion Salvoconducto
64
Velocidad del proyecto
Metodología XP
• Sirve de ayuda para estimar la cantidad de historias de usuario a implementar
en una determinada iteración.
El número de historias de usuario representado por los casos de uso realizadas por
iteración permitió implementar la velocidad del proyecto debido que no todas tenían
el mismo nivel de dificultad y por tanto el mismo requerimiento de horas de
desarrollo. También se notó que fue donde más historias de usuario se evacuaron.
Interacción
Metodología XP
• La duración de una iteración varía entre una y tres semanas
• Cada iteración se define como un módulo o conjunto de historias
implementar.
En el presente proyecto fue dividido en tres iteraciones, por lo cual se obtuvo un
total de tres entregas para las cuales se desarrollaron partes de la aplicación
completamente funcionales.
Este orden se eligió debido a la naturaleza del negocio del cliente y la importancia
que tiene para él la prestación del servicio.
Las entregas fueron planeadas con fechas para su realización y la mayoría se
cumplieron para dichas fechas, la reunión para la última entrega no se pudo realizar
el día que se tenía planeado, por disponibilidad del cliente debido a su horario
laboral.
Reunión
Metodología XP
• La realización de una reunión al comenzar el día laboral
• Esta reunión se realizará en el sitio de trabajo del equipo
Para el presente trabajo las reuniones se realizó al finalizar el día debido al horario
de usuario y el lugar de las reuniones se mantuvo en la Dirección General
Administrativa.
65
3.2 Diseño
El diseño se realiza durante todo el tiempo de vida del proyecto, siendo
constantemente revisado y muy probablemente modificado debido a cambios
presentados durante el desarrollo del proyecto.
Simplicidad
Metodología XP
• Diseño sencillo
Se acogió la recomendación de la metodología XP, de modo que sólo invirtiendo el
tiempo exclusivamente necesario en elaboración de diagramas y diseño de interfaz
gráfica.
Metáfora del sistema
Metodología XP
• Plasmar la arquitectura del sistema en una “ historia”.
Debido que la aplicación es sencilla y de fácil comprensión tanto para los
desarrolladores como para el cliente, no se requirió del empleo de una metáfora,
manteniendo todos los nombres en contexto con una aplicación
Tarjeta CRC
Metodología XP
• Su principal utilidad es dejar el enfoque procedimental y entrar al modelo
orientado a objetos.
Las tarjetas fueron la base del modelo Entidad Relación, elaborado para modelar la
base de datos. Cada Tarjeta CRC se convirtió en un objeto, sus responsabilidades en
métodos públicos y sus colaboradores en llamados a otras clases.
66
Soluciones Puntuales
Metodología XP
• Se trata de una prueba que se hace para resolver un problema técnico o de
diseño.
Para implementarlas pruebas tal como la metodología XP las recomienda se debió
recurrir a una librería especialmente al momento de diseñar el reporte. Se requirió
de una herramienta que permitiera crear reportes impresos de calidad de una forma
sencilla. La mejor solución fue JasperReport
Funcionalidad Mínima.
Metodología XP
• El adicionar funcionalidades que no se han acordado para la iteración con
lleva una pérdida de tiempo que es inaceptable.
En esta parte de la fase fue logrado gracias a la claridad que se tenía en términos de
los objetivos que se debían cumplir durante cada una de las iteraciones, claridad.
Además que en el proyecto presentado se realizó por un desarrollador y no hubo
tentación de crear alguna funcionalidad adicional de las acordadas.
Reciclaje
Metodología XP
• Se conserva el código sencillo.
Con el transcurso del desarrollo del sistema, se revisó constantemente el diseño de
la misma surgiendo situaciones que no fueron tomadas en cuenta al comienzo del
proyecto en el diseño general. Como medida a estos problemas se optó por la
refactorización de las partes afectadas, buscando las soluciones más convenientes y
sencillas, conservando la simplicidad del código.
Una de estas situaciones se refirió a la decisión que se tomó para crear una tabla de
estado del vehículo y ser liberado por el administrador.
67
3.3 Desarrollo
En la metodología XP el proceso es muy diferente. Prácticamente desde un inicio se
realiza la codificación, favoreciendo el logro del objetivo de estar haciendo entregas
frecuentemente al cliente.
Disponibilidad del Cliente
Metodología XP
• El cliente debe estar disponible en el sitio de trabajo.
• El cliente es fundamental para solucionar dudas frente a frente.
Para el presente proyecto, el cliente no podía desplazarse a ninguno de los lugares de
trabajo del programador dado que debía cumplir un su horario de trabajo en
institución, por tanto se acordó realizar vistas al trabajo antes de su entrada laboral.
Unidad de Pruebas
Metodología XP
• Escribir pruebas primero permite identificar los casos especiales que deberá
pasar el código
En el presente desarrollo se optó por probar solo aquellas clases que ejecutan la
lógica del negocio, que en definitiva son las más importantes y de las cuales se debe
tener garantía de estar muy bien construidas.
Debido que el presente proyecto se realizó por un solo desarrollador las
programaciones en parejas e integración no se detalla, se mantuvo la unicidad tanto
el programador como en las versiones manejada.
3.4 Pruebas
La metodología XP resalta en la realización de un sin número de pruebas a lo largo de
todo el proyecto, con el fin de mantener la realización de lo planteado en el diseño. En
este proceso no sólo participa el equipo de desarrollo, también es importante la
participación del cliente, sobre todo en las pruebas de aceptación.
68
Pruebas unitarias
Metodología XP
• Las pruebas deben ser escritas antes que los métodos.
• Su implementación y ejecución deben consumir el menor tiempo posible.
En el presente proyecto la experiencia fue conveniente realizar la pruebas individu
almente, debido a que se producían errores. Se descubrió que este inconveniente
estaba relacionado con la base de datos y no con los métodos, lo que al principio del
proyecto aplicó dificultad al evaluar si un método había pasado o no la prueba. Una
vez que se descubrió este error se empezó a ejecutar las pruebas por grupos en lugar
de ejecutarlas todas de una vez. De esta forma no había problemas de comunicación
con la base de datos y se garantizaba que si una prueba fallaba era solo por errores de
lógica.
Pruebas de aceptación
Metodología XP
• Al encontrar un error debe escribirse primero la prueba antes que corregirlo
En presente proyecto se encontró errores en las interfaces gráficas, estos tipos de
inconvenientes fueron solucionados mediante pruebas manuales, es decir, sin la
ayuda de la herramienta.
69
Modelo Entidad –Relación
Figura
Figura 25.Modelo Entidad –Relación
70
Modelo Físico
Figura 26.Modelo Físico
71
CAPITULO IV
CONCLUSIONES
- El desarrollo del sistema ha permitido dar seguimiento a los procesos
dentro de la institución, enfocadas en las necesidades reales de los usuarios y
en la administración eficiente de las actividades y recursos en La Dirección
General Administrativa de la Universidad Central del Ecuador.
- El sistema informático permite gestionar y controlar los procesos que
diariamente se realizan en el área vehicular de la Universidad Central del
Ecuador, desde la recepción del oficio aprobado, proceso que implica la
captura de los datos tanto del vehículo, solicitante, autoridad y finalmente la
elaboración del documento.
- Las herramientas informáticas y la metodología de desarrollo utilizadas en
este aplicativo, han permitido la construcción de un software orientado a
cubrir las necesidades dela Institución, como una herramienta que hará el
trabajo sea más fácil y productivo.
- El acceso a la información se realizó de manera fácil para los usuarios.
72
RECOMENDACIONES
Se describe una serie de recomendaciones lo cual permitirá asegurar el correcto
funcionamiento del sistema de control y uso para la flota vehicular de la Universidad
Central del Ecuador.
- Con el fin de dar cumplimiento a los objetivos planteados, es primordial la
participación activa de los actores involucrados; por lo que, la función que
desempeñe cada uno de ellos debe estar claramente definida, de tal manera,
que se facilite la entendimiento con los procesos establecidos en el aplicativo.
- Para facilitar el trabajo de elaboración del documento (Salvoconducto),
donde se detalla varios campos; es recomendable tener previamente cargada
la información preliminar (Provincias de destino, vehículos, marcas, modelos,
facultades o centros, autoridades).
- Para la elaboración de un documento (Salvoconducto) ,el oficio deber estar
previamente autorizado por la autoridad competente.
- En base al oficio aprobado se procederá a la elaboración del salvoconducto
con los datos y responsables respectivamente.
- Cada nueva compra de un vehículo o respectiva modificación deberá ser
registrado en sistema.
73
Bibliografía
1.- PINLA, K. (2006), Apuntes de Metodología y Redacción, México, Primera
Edición.
2.-SABINO, C. (1994). Como Hacer una Tesis, Segunda Edición. Editorial
panapoca, Caracas- Venezuela.
3.- PARDINAS, F, Metodología y Técnicas de investigación en las ciencias
sociales. 12 Edición. México.
4.-FRANCO, V., HIDALGO,W., OÑATE, S.(2002),Control y Mantenimiento de
vehículos para la empresa metropolitana de alcantarillado y agua potable Quito
EMAAP-Q,Tesisdepregrado. UCE. , Quito.
5. - KING,G,(2009), “Hibernate”
https://docs.jboss.org/hibernate/orm/3.6/reference/es-ES/html/architecture.html
6.- JasperReports. En Wikipedia, Recuperado 10 de Febrero 2014
https://es.wikipedia.org/wiki/JasperReports
7.-Contraloria General del Estado del Ecuador, “Reglamento de Utilización,
Mantenimiento, Movilización, Control y Determinación de Responsabilidades, de los
Vehículos del Sector Publico ”, Acuerdo 005-CG-2014 Reglamento para el control
vehículos del sector Publico.pdf
8.-ALEGSA,L, (2014),“Diccionario de Informática” En Wikipedia Recuperado 05
de marza 2014 http://www.alegsa.com.ar/Dic/sistema.php
9.-tipo de.org,(2010) “tipo de sistemas”
http://www.tiposde.org/general/727-sistemas
10.-lenguajde de programación. En Wikipedia, Recuperado 15 marzo 20
http://wikipedia.org/wiki/Lenguaje_de_programación.
11.- LUCIANO,(2008) “Entorno de desarrollo”
http://luauf.com/2008/05/13/entornos-de-desarrollo-integrado-para-java
74
12.- ALEGSA,L,(2014),“definición de sismas”
http://www.alegsa.com.ar/Dic/sistema.php
13.-STEVEN, P,(2012)“conceptos básicos de
programación”http://www.ibm.com/developerworks/ssa/java/tutorials/j-introtojava1
14. TIW,(2013) “Interfaz de Persistencia”-
http://www.lab.inf.uc3m.es/~a0080802/RAI/jpa.html
15.-laboratorio Integración de sistemas , (2012.),“ Taller de sistemas de
información” http://www.fing.edu.uy/inco/cursos/tsi/TSI2/2012/teorico/tsi2-05-
persistencia.pdf
16.-MARTINEZ , R,(2013),“Postgres-es”
http://www.postgresql.org.es/sobre_postgresql
17.-Pmoinformatica.com, (2012)," La Oficina de Proyectos de Informática "
http://www.pmoinformatica.com/2012/11/los-5-valores-de-la-programacion.html
75
Glosario de términos
Jdbc.-es sinónimo de java detalles base una conectividad, que es un API Java
estándar para la conectividad de base de datos independiente entre el lenguaje de
programación Java y una amplia gama de bases de datos.
Vehículo.-Aparato con o sin motor que se mueve sobre el suelo, en el agua o el aire
y sirve para transportar cosas o personas, especialmente el de motor que circula por
tierra.
Salvoconducto.- Documento expedido por la autoridad para permitir el tránsito libre
y sin riesgo de su portador.
J2EE.-es una plataforma de programación parte de la Plataforma Java, para
desarrollar y ejecutar software de aplicaciones en el lenguaje de programación Java.
API.-La interfaz de programación de aplicaciones
Eclipse.-Es uno de los entornos Java más utilizados a nivel profesional.
VisualAge.-era el nombre de una familia de computadora integrado entornos de
desarrollo de IBM
Servlets.-Los servlets son clases de lenguaje de programación Java que procesan
dinámicamente peticiones y construyen respuestas
Compilador.- Es un programa informático que traduce un programa escrito en un
lenguaje de programación a otro lenguaje de programación, generando un programa
equivalente que la máquina será capaz de interpretar.
Debuggers.- Es un programa usado para probar y depurar (eliminar los errores) de
otros programas
javax.persistence.Persistence.- Contiene métodos estáticos de ayuda para obtener
una instancia de Entity Manager Factory de una forma independiente al vendedor de
la implementación de JPA. Una clase de inicialización que va proporcionar un
método estático para la creación de una Entity Manager Factory
76
ORM: Object Relational Mapping - Mapeo Relacional de Objetos
XP: programación extrema de sea
UML: Lenguaje Unificado de Modelado
Sistema de Gestión de Bases de Datos: Son un tipo de software dedicado a servir
de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan
Stakeholders: Cualquier persona interesada afectada y/o implicada con el
funcionamiento del sistema o software.
77
ANEXOS
78
ANEXO A
MANUEL TÉCNICO
DICCIONARIO DE DATOS
Nombre de Tabla: Usuario
Descripción: Almacena la información de los usuarios que accederá al sistema.
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
USER_COD serial Identificador único
USER_NOMBRE Variable characters 20 Nombre de usuario
USER_APELLIDO Variable characters 20 Apellido de usuario
USER_LOGIN Variable characters 15 nombre de ingreso
USER_PASS Variable characters 15 contraseña
USER_EMAIL Variable characters 60 correo del usuario
USER_CELULAR Number 10 N º de celular
USER_CEDULA Number 10 N º de cedula del usuario Tabla 1.Usuario
Nombre de Tabla: Licencias Tipo
Descripción: Almacena la información tipo de licencias de los usuarios.
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
COD_LICENCIA_TIPO Serial Identificador único
LICEN_TIPO_NOMBRE Variable characters 8 Nombre licencia
LICEN_TIPO_DESCRIPCION Variable characters 50 Descripción del tipo de licencia Tabla 2.Licencia Tipo
Nombre de Tabla: Roles
Descripción: Almacena la información tipo de rol dentro del sistema.
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
ID_ROL Serial Identificador único
NOMBRE_ROL Variable characters 40 Nombre rol
DESCRIP_ROL Variable characters 100 descripción breve del rol Tabla 3.Roles
79
Nombre de Tabla: Acceso
Descripción: Almacena la información de acceso al sistemas.
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
ACCESO_COD serial Código de acceso Tabla 4.Acceso
Nombre de Tabla: Menú
Descripción: Almacena la información del menú del sistema.
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
MENU_COD Serial Identificador único
MENU_NOMB Variable characters 100 Nombre de menú.
MENU_URL Variable characters 100 Link del menú. Tabla 5.Menu
Nombre de Tabla: Estado Usuario
Descripción: Almacena la información de los estados del usuario.
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
COD_ESTADO_USER Serial Identificador único
ESTADO_NOMBRE Variable characters 20 Nombre de estado de usuario Tabla 6.Estado Usuario
Nombre de Tabla: Facultad
Descripción: Almacena la información la facultad o centro de la institución
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
UCE_FACUL_COD Serial Identificador único
UCE_FACUL_NOMBRE Variable characters 100 Nombre de la Facultad o Centro
UCE_FACUL_DIRECCION Variable characters 100 Dirección de la Facultad
UCE_FACUL_TELEFONO Variable characters 10 Teléfono
UCE_FACUL_MAIL Variable characters 50 Correo de la facultad Tabla 7.Facultad
80
Nombre de Tabla: Vehículo
Descripción: Almacena la información de los vehículos
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
VEH_COD Serial Identificador único
VEH_FECHA_CADUCA Date Fecha de matriculación
VEH_ANIO Number 4 Año de vehículo
VEH_PAIS_ORIGEN Variable characters 30 País de origen
VEH_PLACA Variable characters 10 Placa de vehículo
VEH_NUM_MOTOR Variable characters 30 Numero de Motor
VEH_CILINDRAJE Variable characters 8 Numero Cilindraje
VEH_NUM_CHASIS Variable characters 30 Numero Chasis
VEH_TONELAJE Number 6 Tonelaje
VEH_NUM_CAPACIDAD Number 2 Número de pasajeros
VEH_MATRICULA Variable characters 10 Numero de matricula Tabla 8.Vehiculo
Nombre de Tabla: Marca
Descripción: Almacena la información de las marcas de los vehículos
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
COD_MARCAS Serial Identificador único
MAR_VEH Variable characters 30 Nombre de marca Tabla 9.Marca
Nombre de Tabla: Modelo
Descripción: Almacena la información de los modelos de los vehículo.
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
COD_MODEL Serial Identificador único
MODE_VEHI Variable characters 30 Nombre Modelo Tabla 10.Modelo
81
Nombre de Tabla: Marca Modelo
Descripción: Almacena la información marca y modelo.
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
COD_MARCA_MODELO Serial Identificador único Tabla 11.Marca- Modelo
Nombre de Tabla: Color Descripción: Almacena la información de los colores de
los vehículos
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
COD_COLORES Serial Identificador único
COLORES_VEHI Variable characters 20 Nombre de Color Tabla 12.Color
Nombre de Tabla: Tipo Vehículo
Descripción: Almacena la información de los tipo de vehículo.
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
COD_TIPOS Serial Identificador único
TIPOS_VEHI Variable characters 20 Nombre Tipo de vehículo Tabla 13.Tipo Vehículo
Nombre de Tabla: Estado
Descripción: Almacena la información el estado.
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
COD_ESTADO Serial Identificador único
TIPOS_VEHI Variable characters 20 Nombre Tipo de vehículo Tabla 14.Estado
82
Nombre de Tabla: Estado Vehículo
Descripción: Almacena la información de los estado del vehículo
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
COD_ESTADO_VEHI Serial Identificador único
ESTADO_VEHI_FECHA_REGISTRO Date Fecha de registro
DESCRIPCION Variable characters 100 Descripción de estado Tabla 15.Estado Vehículo
Nombre de Tabla: Provincia
Descripción: Almacena la información de los provincias
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
COD_PROVINCIA Serial Identificador único PROVIN _CODIFICACION Variable characters 2 Código de la provincia
PROVIN_NOMBRE Variable characters 35 Nombre de la provincia Tabla 16.Provincia
Nombre de Tabla: Salvoconducto
Descripción: Almacena la información de los salvoconducto
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
COD_SCVEHI Serial Identificador único
SCVEHI_FECHA_EMISION Date Fecha emisión del documento
SCVEHI_FECHA_CADUCA Date Fecha de caducidad del documento
SCVEHI_ACTIVIDAD Variable characters 80 Actividad a realizar
SCVEHI_DESCRIPCION Variable characters 300 Descripción del actividad
SCVEHI_KM_ENTRADA Integer KM De entrada
SCVEHI_KM_SALIDA Integer KM de Salida
SCVHEI_NUM_OFICIO Variable characters 11 Núm. de oficio aprobado
SCVHE_ORIGEN Variable characters 20 Lugar de salida
SCVVEHI_OCUPANTES Number Núm. de ocupantes
USER_COD_CHOFER Number Datos de chofer asignado
USER_COD_AUTORIDAD Number Datos de Autoridad
USER_COD_ELABORA Number Datos usuario elaboro de documento
SCVEHI_FECHA_AUTORIZA Date Fecha de autorización
SCVEHI_ESTADO Variable characters 16 Estado de documento Tabla 17.Salvoconducto
83
Nombre de Tabla: Historial Salvoconducto
Descripción: Almacena la información de lo historial del salvoconducto.
NOMBRE CAMPO TIPO DE DATO TAMAÑO DESCRIPCION
COD_HISTORIAL Serial Identificador único
HISTORIAL_DETALLLE Variable characters 100 Detalle del historial
HISTORIAL_FECHA_REG Date Fecha de registro Tabla 18.Historial salvoconducto
Políticas de respaldo
Base de datos
La aplicación scvuce está realizada en la base de datos Postgres debido la cual debe
realizar un manteamiento de la misma. La misma que se ecuentra en la dirección:
SCVUCE\SCVUCE-SOFTWARE con el nombre de BD_SCVUCE.backup en el cd
entregado.
Instalación y configuración
Los manuales de instalación y de configuración se encuentran en: SCVUCE\
SCVUCE-MANUALES. Con sus respectivos nombres en el cd entregado
84
ANEXO B
Oficio aprobado por la Autoridad de la Universidad Central del Ecuador
