Post on 05-Feb-2021
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja
AREA TÉCNICA
TITULACIÓN DE INGENIERO EN SISTEMAS INFORMÁTICOS Y
COMPUTACIÓN
Desarrollo de una solución software para automatizar la lecturación y bloqueo de medidores de GLP para los clientes de Instalaciones Centralizadas de la C.E.M. LOJAGAS, empleando
arquitectura 3 capas y metodología RUP. TRABAJO DE FIN DE TITULACIÓN
A
AUTOR: Valladolid Zhingre, Roberto Carlos
DIRECTOR: Guamán Coronel, Daniel Alejandro, Mgs.
LOJA – ECUADOR
2014
ii
APROBACIÓN DEL DIRECTOR DEL TRABAJO DE FIN DE TITULACIÓN
Magister.
Daniel Alejandro Guamán Coronel
DOCENTE DE LA TITULACIÓN
De mi consideración:
El presente trabajo de fin de titulación: “Desarrollo de una solución software para
automatizar la lecturación y bloqueo de medidores de GLP para los clientes de
Instalaciones Centralizadas de la .C.EM. LOJAGAS, empleando arquitectura 3 capas y
metodología RUP" realizado por Valladolid Zhingre Roberto Carlos, ha sido orientado y
revisado durante su ejecución, por cuanto se aprueba la presentación del mismo.
Loja, noviembre del 2014
f). . . . . . . . . . . . . . . . . . . . . . . . . .
iii
DECLARACIÓN DE AUTORIA Y CESIÓN DE DERECHOS
Yo Valladolid Zhingre Roberto Carlos declaro ser autor del presente trabajo de fin de
titulación: Desarrollo de una solución software para automatizar la lecturación y bloqueo de
medidores de GLP para los clientes de Instalaciones Centralizadas de la .C.EM. LOJAGAS,
empleando arquitectura 3 capas y metodología RUP, de la Titulación Ingeniero en Sistemas
Informáticos y Computación, siendo Daniel Alejandro Guamán Coronel director del
presente trabajo; y eximo expresamente a la Universidad Técnica Particular de Loja y a sus
representantes legales de posibles reclamos o acciones legales. Además certifico que las
ideas, conceptos, procedimientos y resultados vertidos en el presente trabajo investigativo,
son de mi exclusiva responsabilidad.
Adicionalmente declaro conocer y aceptar la disposición del Art. 67 del Estatuto Orgánico
de la Universidad Técnica Particular de Loja que en su parte pertinente textualmente dice:
“Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones,
trabajos científicos o técnicos y tesis de grado que se realicen a través, o con el apoyo
financiero, académico o institucional (operativo) de la Universidad”
f.................................................
Autor: Valladolid Zhingre Roberto Carlos
Cédula: 0704935048
iv
DEDICATORIA
El presente trabajo, símbolo del aprendizaje y alcance de
nuevos conocimientos, les dedico a todos mis seres queridos, a
mis padres por el apoyo que siempre me han brindado, a mis
hermanos y en especial a una persona maravillosa que ha
estado a mi lado de manera incondicional durante el transcurso
de esta etapa de mi vida, que ha confiado en mí y es mi principal
fuente de motivación, Jhoana.
El Autor.
v
AGRADECIMIENTO
En el presente trabajo símbolo del esfuerzo y superación, dejo
constancia el más sincero agradecimiento hacia mis padres
Roberto Valladolid y Fanny Zhingre, quienes me alientan a
alcanzar mis objetivos y han sido ejemplo de constancia y
superación; así mismo a mis hermanos Jonathan y Estefanía por
permitirme ser ejemplo para ellos; de igual forma a mis familiares
cercanos que contribuyeron a cumplir esta meta.
A mi director de Tesis Mgs. Daniel Guamán por su acertada
dirección, su disponibilidad de tiempo y su gran apoyo en el
transcurso del presente proyecto.
A la C.E.M. LOJAGAS, a todos sus empleados por brindarme su
confianza y apoyo incondicional, en especial al Gerente Ing.
James Loaiza por darme el apoyo necesario para cumplir con
este objetivo y al Ing. Juan Pablo Feijoo por su inmenso apoyo
para el cumplimiento de éste proyecto.
Gracias a todos ustedes, ahora es posible cumplir con una de
las metas propuestas al inicio de esta etapa universitaria.
El Autor.
vi
ÍNDICE DE CONTENIDOS
CARATULA……………………………………………………………………………………i
APROBACIÓN DEL DIRECTOR DEL TRABAJO DE FIN DE TITULACIÓN ............. ii
DECLARACIÓN DE AUTORIA Y CESIÓN DE DERECHOS ...................................... iii
DEDICATORIA .............................................................................................................. iv
AGRADECIMIENTO ...................................................................................................... v
ÍNDICE DE CONTENIDOS ........................................................................................... vi
RESUMEN ...................................................................................................................... 1
ABSTRACT .................................................................................................................... 2
INTRODUCCIÓN............................................................................................................ 3
CAPÍTULO I: MARCO TEÓRICO ................................................................................. 5
1. Introducción. ......................................................................................................... 6
1.1 Metodología RUP. .......................................................................................... 6
1.1.1. Definiciones de RUP. .................................................................................... 6
1.1.2. Dimensiones de RUP. ................................................................................... 7
1.1.3. Características esenciales de RUP. .......................................................... 10
1.1.4. Ciclo de Vida de RUP. ................................................................................. 12
1.1.5. Artefactos de RUP. ...................................................................................... 13
1.2. Phonegap. ..................................................................................................... 15
1.2.1. Apache Córdova .......................................................................................... 16
1.3. Android. ......................................................................................................... 17
1.3.1. Versiones de Android ................................................................................. 19
1.4. Arquitectura de Software ............................................................................ 20
1.4.1. La importancia de la Arquitectura de Software ....................................... 20
1.4.2. Consideraciones claves para el diseño de la Arquitectura de
Software ...................................................................................................................... 21
1.4.3. Patrones de Arquitectura de software. ..................................................... 23
1.4.3.1. Patrón Arquitectónico MVC........................................................................ 24
1.4.4. Estilos de Arquitectura de software. ......................................................... 26
1.4.5. Cuadro Comparativo de los Estilos de Arquitecturas de Software. ..... 28
1.4.6. Selección del Estilo de Arquitectura de Software. .................................. 29
1.4.7. Estilo de Arquitectura en Capas. ............................................................... 31
CAPÍTULO 2: DEFINICIÓN DEL PROBLEMA Y ANÁLISIS INICIAL. ...................... 33
2. Introducción ................................................................................................. 34
vii
2.1. Descripción del Proceso Actual. ............................................................... 34
2.2. Problemática. ............................................................................................... 36
2.3. La Posible Solución. ................................................................................... 37
2.4. La Solución Ideal. ........................................................................................ 39
2.5. Beneficios de la Solución. .......................................................................... 43
2.6. Resultados Esperados. ............................................................................... 43
CAPÍTULO 3: DESARROLLO DE LA SOLUCIÓN .................................................... 45
3. Introducción. ................................................................................................. 46
3.1. Metodología de Desarrollo de Software. .................................................. 46
3.2. Fases de la Metodología de Desarrollo de Software............................... 46
3.3. Fase de Inicio. .............................................................................................. 47
3.3.1. Estudio del Proceso Actual. ....................................................................... 48
3.3.2. Entrevistas. .................................................................................................. 48
3.3.3. Observación Directa.................................................................................... 49
3.3.4. Documento de Visión. ................................................................................. 49
3.3.4.1. Definición del Problema Actual. ................................................................ 49
3.3.4.2. Involucrados del Proyecto. ........................................................................ 50
3.3.5. Especificación de Requerimientos. .......................................................... 51
3.3.5.1. Perspectiva de la Solución Software. ....................................................... 52
3.3.5.2. Características de la Solución Software. ................................................. 52
3.6. Fase de Elaboración.................................................................................... 53
3.6.1. Especificación de Casos de Uso. .............................................................. 54
3.6.2. Arquitectura de Software Propuesta. ........................................................ 55
3.6.3. Descripción del Patrón Arquitectónico MVC. .......................................... 56
3.6.3.1. Modelo. ......................................................................................................... 56
3.6.3.2. Vista. ............................................................................................................. 57
3.6.3.3. Controlador. ................................................................................................. 57
3.6.4. Implantación física del Patrón Arquitectónico MVC. .............................. 58
3.7. Fase de Construcción. ................................................................................ 58
3.7.1. Vista. ............................................................................................................. 59
3.7.1.1. Diseño de la Interfaz de Usuario ................................................................ 59
3.7.2. Controlador. ................................................................................................. 63
3.7.3. Modelo. ......................................................................................................... 65
3.8. Fase de Transición. ..................................................................................... 68
CAPÍTULO 4: PRUEBAS DE VALIDACIÓN .............................................................. 69
viii
4. Introducción. ................................................................................................. 70
4.1. Tipos de Pruebas. ........................................................................................ 70
4.2. Estrategia de Pruebas. ................................................................................ 70
4.3. Herramientas para Pruebas. ....................................................................... 72
4.4. Configuración del Ambiente de Pruebas .................................................. 72
4.5. Ejecución y Resultados de las Pruebas. ................................................... 73
4.5.1. Pruebas Unitarias. ........................................................................................ 73
4.5.2. Pruebas de Integración ............................................................................... 74
4.5.3. Pruebas de Sistema. .................................................................................... 75
4.5.4. Pruebas Funcionales. .................................................................................. 76
4.6. Métricas del Producto de Software. ........................................................... 76
4.6.1. Métricas en la etapa de Análisis. ................................................................ 77
4.6.2. Métricas en la etapa de Diseño e Implementación................................... 79
4.6.2.1. Eficacia de la eliminación de defectos. ..................................................... 79
CAPÍTULO 5: CONCLUSIONES, RECOMENDACIONES Y TRABAJOS
FUTUROS .................................................................................................................... 81
CONCLUSIONES......................................................................................................... 82
RECOMENDACIONES ................................................................................................ 83
TRABAJOS FUTUROS ............................................................................................... 84
BIBLIOGRAFÍA ............................................................................................................ 85
GLOSARIO................................................................................................................... 88
ANEXO A: PROCESO DE LECTURACIÓN Y BLOQUEO DE MEDIDORES DE
GLP............................................................................................................................... 90
ANEXO B: CRONOGRAMA DE LECTURACIONES. ................................................ 91
ANEXO C: PLANILLA DE LECTURACIONES. ......................................................... 92
ANEXO D: DOCUMENTO DE VISIÓN........................................................................ 93
ANEXO E: DOCUMENTO DE ESPECIFICACIÓN DE REQUERIMIENTOS .......... 105
ANEXO F: DOCUMENTO DE ESPECIFICACIÓN DE CASOS DE USO ................ 117
ANEXO G: DOCUMENTO DE ARQUITECTURA DE SOFTWARE ........................ 125
ANEXO H: DOCUMENTO DE PLAN DE PRUEBAS ............................................... 137
ANEXO I: MANUAL DE USUARIO ........................................................................... 167
1
RESUMEN
El presente proyecto de tesis ha sido desarrollado para automatizar el registro de
lecturaciones y bloqueos de medidores de GLP de los clientes de Instalaciones
Centralizadas, el mismo que se realizaba de una forma manual y empleaba demasiado
tiempo en la toma de lecturas, bloqueos y registro en el sistema informático de la compañía,
lo que implicaba el retraso en el proceso de Facturación de los clientes por consumo
mensual de GLP al Granel.
Este proyecto se ha sustentado en el: desarrollo e implementación de una aplicación
móvil Android, que permita automatizar el procedimiento de lecturación y bloqueo
de medidores de GLP, el mismo que se ha desarrollado utilizando la metodología de
desarrollo de software RUP, cumpliendo con los entregables establecidos en cada fase y
ejecutando las iteraciones necesarias para satisfacer las necesidades del cliente,
brindando un producto software de calidad. Además se ha utilizado el patrón arquitectónico
MVC para el desarrollo de la solución software, con la finalidad de otorgar a la compañía
Lojagas un producto de software escalable, flexible y de fácil mantenimiento.
PALABRAS CLAVES: Lecturación, Bloqueos, Medidores, Android, Instalaciones
Centralizadas, GLP, Arquitectura 3 capas, MVC, RUP, Oracle, Artefactos, Entregables.
2
ABSTRACT
This thesis project has been develop to automate the registration of lecturaciones and
blockades of meters GLP the customers Centralized Facilities, the same as is perform in a
manual way and employ in decision too reading, block and long into the computer system
of the company, implying the delay in the process of billing customer by monthly
consumption of GLP Bulk.
This project is supported in: the development and implementation of an Android mobile
application, that allow automates procedure of lecturacion and blocks of meters GLP,
the same that was developed using the software development methodology RUP, meeting
with established deliverables in each phase and running the necessary iterations to meet
customer needs, providing a software product quality. In addition, we have used the MVC
architecture pattern for the development of the software solution, in order to give the
company Lojagas a product scalable, flexible and easy to maintain software.
KEYWORDS: Lecturacion, Blocks, Meters, Android, Installations Centralized, GLP, 3-tier
architecture, MVC, RUP, Oracle, Artifacts, Deliverables.
3
INTRODUCCIÓN
El presente proyecto de tesis consiste en desarrollar e implementar una aplicación
móvil que permita registrar todas las lecturaciones mensuales de los medidores de
GLP desde un dispositivo móvil, con el propósito de reducir los tiempos de respuesta en
la toma de lecturaciones, eliminar el tiempo empleado en el ingreso de dichas tomas hacia
el sistema informático de la compañía, además optimizar el proceso de lecturación y
bloqueo de medidores de GLP, ofreciendo un servicio de calidad para los clientes de
Instalaciones Centralizadas.
Este proyecto es de suma importancia ya que le permitirá a la C.E.M. LOJAGAS
automatizar el procedimiento de lecturación y bloqueo de medidores de GLP, que se basa
en el registro de lecturación que indica el medidor de GLP en los departamentos de los
clientes de Instalaciones Centralizadas, evitando generar las planillas de lecturación y
registrar cada una de estas en el sistema informático de la compañía, además de no
ingresar las lecturaciones en el sistema empresarial, si no realizarla a través de la solución
software para una inmediata facturación hacia los clientes de Instalaciones Centralizadas.
Esta iniciativa del presente proyecto nace del departamento de Tecnologías de la
Información y Comunicaciones (TIC) de la C.E.M. LOJAGAS, que consiste en hacer uso
de los dispositivos inteligentes para realizar el registro de lecturaciones y bloqueos de
medidores de GLP.
Este proyecto tiene como objetivo principal: desarrollar e implementar una solución
software que automatice el registro de lecturaciones y bloqueos de medidores de
GLP para los clientes de Instalaciones Centralizadas, utilizando como tecnología base
la infraestructura de TI de la compañía Lojagas. Para dar alcance a este objetivo se debe
dar cumplimiento a los siguientes objetivos específicos:
Definir la problemática para garantizar un adecuado análisis de la solución software
y conocer el estado actual del problema.
Desarrollar e Implementar los artefactos necesarios de la metodología de desarrollo
de software RUP que permitan garantizar un producto software de calidad.
4
Seleccionar e implementar una arquitectura que brinde una estructura sólida en la
construcción de la solución software.
Implementar el patrón arquitectónico modelo vista controlador para el desarrollo de
la solución software.
Construir una aplicación móvil que permita automatizar el registro de lecturaciones
y bloqueos de medidores de GLP de forma ágil y eficiente.
Realizar un plan de pruebas que valide los requerimientos del usuario y los
escenarios de la solución software.
La estructura de este proyecto está compuesta por los siguientes capítulos:
Capítulo 1: Contiene el marco teórico que proporciona una visión general de los temas a
abordar en el proyecto como: metodología de desarrollo de software, selección de la
arquitectura de software, tecnologías y herramientas utilizadas en el desarrollo de la
solución.
Capítulo 2: Este capítulo está compuesto por: “proceso de lecturación y bloqueo de
medidores de GLP” que actualmente ejecuta la compañía, problemática actual, análisis de
la solución, beneficios de la solución y resultados esperados al implementar la presente
solución software.
Capítulo 3: Este capítulo contiene el desarrollo de la solución que cumple con las fases de
la metodología de desarrollo de software y contiene la implementación de la arquitectura
seleccionada.
Capítulo 4: Este capítulo contiene las pruebas y resultados que validan la solución
software del presente proyecto.
Capítulo 5: Este capítulo contiene las conclusiones, recomendaciones y trabajos futuros
que se presentan en el presente proyecto.
En el transcurso del presente proyecto se brindaron todas las facilidades por parte de la
compañía Lojagas, proporcionando la información necesaria para el conocimiento del
proceso y problemática actual, además se facilitó el uso de la infraestructura de TI para la
implementación y las pruebas respectivas de la solución software, así mismo como el
apoyo económico para la adquisición de una Tablet Samsung Tab3 para la implementación
y puesta en marcha de la solución software.
Cabe indicar que para dar a conocer las ideas más importantes en el texto, éste será
resaltado con negrita y/o cursiva.
5
CAPÍTULO I: MARCO TEÓRICO
6
1. Introducción.
En la actualidad se cuenta con diversos tipos de metodologías para el desarrollo de
software, lo que puede ocasionar un gran problema al momento de saber cuál utilizar a la
hora de diseñar software, para esto es necesario conocer las diversas metodologías
existentes y conocer cómo funciona cada una y así poder elegir correctamente la más
adecuada para nuestro proyecto. En el presente proyecto se ha seleccionado a RUP como
metodología para el desarrollo de software, debido a que maneja un proceso de desarrollo
netamente iterativo que permite definir los requerimientos en cada fase, de esta manera se
tiene un producto software que cumple los requerimientos que se proponen por parte del
cliente, además de ser flexible en el proceso brindando lo que se conoce como “mejores
prácticas” dirigidas para la fase de diseño y procesos de negocio, ayudando a mitigar los
riesgos de forma temprana y continua, (para mayor detalle del por qué se escogió esta
metodología, diríjase a la sección 1.1.1 del presente capítulo).
Por otra parte una de las grandes expectativas que tienen los desarrolladores al día de hoy,
es el mundo de los dispositivos móviles y la gran pregunta que se generan es: en qué
plataforma desarrollar, la facilidad al desarrollar, en que lenguaje desarrollar, en fin escoger
una plataforma se puede volver algo complicado de analizar. Debido a estas inquietudes,
existe un framework que permite desarrollar aplicaciones móviles para diferentes
plataformas como: iOS, Android, Blackberry, Windows Phone, WebOS, etc, a partir de
código HTML5, JavaScript y CSS3, además cuenta con una API que permite el acceso a
componentes del dispositivo como la cámara, red, notificaciones, GPS, etc.
El presente capítulo proporciona un marco teórico que profundiza en la metodología de
desarrollo de software, sus características esenciales, el ciclo de vida y los artefactos a ser
utilizados en la solución software, así mismo se describe el uso del framework Phonegap
como herramienta para el desarrollo de la aplicación móvil basada en Android, además se
realiza el análisis para la adecuada selección de la arquitectura de software, lo cual es
importante recopilar para el desarrollo del presente proyecto.
1.1 Metodología RUP.
1.1.1. Definiciones de RUP.
El autor (Belloso Cicilia, 2009), menciona que “los orígenes de RUP se remontan al modelo
espiral original de Barry Boehm, Ken Hartman uno de los contribuidores claves de RUP
colaboró con Boehm en la investigación. Entre los años 1987 a 1995 Jaconson fundó la
compañía Objetoty AB y lanza en proceso de desarrollo Objectory (Abreviatura de Object
Factory). En 1995 Rational Software es comprada por Objectory AB, propiedad de
7
Jacobson RUP fue el resultado de una convergencia de Rational Approach y Objectory,
proceso desarrollado por el fundador de Objectory Ivar Jacobson. El primer resultado de
esta fusión fue el Rational Objectory Process, la primera versión de RUP fue puesta al
mercado en 1998, siendo arquitecto el jefe Philippe Kruchten. También se conoce por este
nombre al software desarrollado por Rational de IBM, al cual incluye información
entrelazada de diversos artefactos y descripciones de diversas actividades, está incluido
en el Rational Method Composer (RMC) que permite la personalización de acuerdo a
necesidades de proyecto” de software.
“Las siglas RUP en inglés significan Rational Unified Process, un producto del proceso
de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y
responsabilidades dentro de una organización del desarrollo. Su meta es asegurar la
producción del software de alta calidad que resuelve las necesidades de los usuarios
dentro de un presupuesto y tiempo establecidos”, según el autor (Rueda Chacón, 2006).
En opinión de estos autores, se puede analizar que la metodología de desarrollo de
software RUP permitirá implementar de manera ordenada y eficiente todos los artefactos
para un buen desarrollo de software, produciendo un producto software estructurado y de
calidad. Es por esto que se ha seleccionado esta metodología de desarrollo de software en
vista a su eficiencia y flexibilidad en plazos y presupuesto, además de la experiencia
obtenida en el transcurso de la carrera, lo que ha permitido conocer los entregables
necesarios que validen el proyecto y el cumplimiento de estos hacia el cliente.
Con el uso de esta metodología la compañía podrá conocer los artefactos elaborados
en cada fase de desarrollo y que podrán ser utilizados para próximas versiones o
cambios sustanciales en el proyecto. De esta manera se lleva cabo la elaboración y
construcción de la solución software enmarcándose dentro de cada fase de la metodología
de desarrollo de software.
1.1.2. Dimensiones de RUP.
El Rational Unified Process RUP dentro de su ciclo de vida presenta dos dimensiones
según el autor (Vargas Cano, 2014), los mismos que se presentan a continuación.
Eje horizontal: Es considerado el eje de los aspectos dinámicos en que se
representa las características del ciclo de vida, expresado en fases, iteraciones e
hitos.
8
Eje vertical: Representa los aspectos estáticos en que se describe el proceso en
términos de componentes, disciplinas, flujos de trabajo, actividades, artefactos y
roles.
Como se observa en Figura 1, varía el enfoque de cada disciplina en el eje vertical (flujos
de control de proceso), con respecto a cada una de las fases del eje horizontal, en ciertos
plazos de tiempo. Esto nos indica que en las iteraciones más tempranas como: modelo de
negocios y requisitos se emplea más tiempo en definir el alcance y los requisitos del
proyecto, mientras que en las últimas iteraciones pasamos más tiempo en la
implementación, pruebas y despliegue del proyecto.
Figura 1. Dimensiones de RUP Fuente: (Vargas Cano, 2014)
Cada disciplina del eje vertical conlleva flujos de trabajo que no son otra cosa que una
secuencia de pasos para la culminación de cada fase de la metodología de desarrollo de
software. Estas disciplinas se dividen en dos grupos: primario o de proceso y de apoyo, las
cuales se describen a continuación:
Grupo Primario: Son las disciplinas necesarias para la realización de un proyecto
de software, aunque para proyectos no muy grandes se pueden omitir algunas
disciplinas, entre las que tenemos:
Modelado de negocios.
Requisitos.
Análisis y diseño.
Implementación.
9
Pruebas.
Despliegue.
Grupo de Apoyo: Son las que como su nombre lo indica, sirven de apoyo al grupo
primario y especifican otras características para la realización de un proyecto de
software, entre las que tenemos:
Configuración y manejo del cambio.
Administración o gestión del proyecto.
Entorno.
Para el desarrollo del presente proyecto no se tomarán en cuenta todas las disciplinas del
ciclo de vida de la metodología de desarrollo de software RUP. Se tomará en cuenta las
disciplinas necesarias que faciliten el rápido desarrollo de la solución software y que
no comprometan el tiempo de entrega de la misma.
Para un mejor entendimiento de las disciplinas antes mencionadas, a continuación se
presenta una breve descripción de cada una de estas para el desarrollo de la solución
software:
Requisitos: Tiene como objetivo establecer lo que la solución software debe hacer,
es decir especificar los requerimientos, definir los límites y realizar una estimación
breve del costo y tiempo empleado en el proceso de desarrollo de software.
Análisis y Diseño: Define la arquitectura de la solución software y tiene como
objetivo trasladar los requisitos en especificaciones de implementación, haciendo
uso de los artefactos de la metodología de desarrollo de software RUP.
Implementación: Asume como objetivos: implementar el diseño, probar las
funcionalidades, integrar los componentes y utilizar un modelo de implementación
para entender cómo se organiza la solución software.
Pruebas: Toma como objetivo verificar la integración de las funcionalidades de la
solución software, además de verificar que todos los requisitos han sido
implementados y asegurar que los defectos han sido resueltos.
Despliegue: Asegura que la solución software esté preparado para el uso del
cliente, empaquetarlo e instalarlo y proceder a su entrega y recepción.
Considerando lo antes descrito, se trabajará con las disciplinas del grupo primario
como son: requisitos, análisis y diseño, implementación, pruebas y despliegue que
10
son las necesarias para la construcción y desarrollo de la presente solución
software. En el Capítulo 3 se describe el desarrollo de estas disciplinas enmarcadas en
las fases de la metodología de desarrollo de software RUP.
1.1.3. Características esenciales de RUP.
Al hablar de las características de la metodología de desarrollo de software RUP, ésta se
centra en la definición de procesos, tareas y herramientas que requieren de una
documentación detallada para conocer todo el proyecto, además se caracteriza por ser
iterativa e incremental y guiarse por casos de uso. A continuación el autor (Vargas Cano,
2014), expone las siguientes características esenciales de la metodología RUP:
Dirigido por los casos de uso: Los casos de uso son una técnica de captura de
requisitos que involucra a todos los usuarios del proyecto; definiendo un caso de
uso como un fragmento de funcionalidad del sistema y que representan los
requisitos funcionales del sistema. Los casos de uso son utilizados como artefacto
que permite establecer el comportamiento deseado del sistema, además de validar
y verificar la arquitectura empleada en el sistema.
Proceso centrado en la arquitectura: Los casos de uso deben encajar en la
arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de
todos los casos de uso requeridos. Esto provoca que tanto la arquitectura como los
casos de uso deban evolucionar en paralelo durante todo el proceso de desarrollo
de software, esto se debe hacer tomando en cuenta que la arquitectura es un
artefacto utilizado para diseñar, construir, gestionar y evolucionar el desarrollo del
sistema.
Proceso iterativo e incremental: La estrategia que propone RUP es tener un
proceso iterativo e incremental en donde el trabajo se divide en partes más
pequeñas o mini proyectos, permitiendo el equilibrio entre los casos de uso y la
arquitectura que se vaya logrando durante cada mini proyecto, así durante todo el
proceso de desarrollo. Cada mini proyecto se puede ver como una iteración, que
involucra pasar por los flujos de trabajo como requisitos, análisis, diseño,
implementación y pruebas; del cual se produce un crecimiento en el producto
software.
En opinión a las características esenciales de la metodología de desarrollo de software
RUP, en el presente proyecto se hará uso de la característica dirigido por los casos
de uso, ya que no sólo se utilizará como herramienta para especificar los requisitos
11
funcionales de la solución software, sino que servirán como guía para el diseño e
implementación de la solución software, además proporcionará un hilo conductor durante
todo el proceso de desarrollo y permitirá establecer trazabilidad entre los artefactos
generados en cada una de las fases de la metodología de desarrollo. También se hará uso
de la característica proceso centrado en la arquitectura, tomando en cuenta las
interacciones necesarias en los casos de uso y en las especificaciones de requerimientos
del usuario; estos artefactos servirán de base para la arquitectura de software, permitiendo
una evolución en paralelo de estas disciplinas durante el proceso de desarrollo. Asimismo
se hará uso de la característica proceso iterativo e incremental, que se tomará en cuenta
para llevar a cabo las iteraciones necesarias dentro de cada una de las disciplinas del ciclo
de vida de la metodología de desarrollo de software, es decir cumplir con las disciplinas de
los flujos fundamentales como: requisitos, análisis y diseño, implementación, pruebas e
integración, como se muestra en la Figura 2, hasta obtener un producto software
implementado y liberado para el uso de la compañía Lojagas.
Figura 2. Iteración de RUP
Fuente: (Vargas Cano, 2014)
Según el autor (Vargas Cano, 2014), “el proceso iterativo e incremental consta de una
secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total,
pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada
iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos
requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Toda la
retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes
iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por completo con
la versión actual del producto”.
En opinión de este autor se pudo analizar que cada iteración permitirá evolucionar la
arquitectura y la implementación de los requisitos funcionales de la solución software,
12
además en el desarrollo del presente proyecto se ejecutarán iteraciones de forma
incremental hasta obtener una solución software que satisfaga al cliente y cumpla con los
objetivos planteados para el desarrollo del presente proyecto.
1.1.4. Ciclo de Vida de RUP.
El autor (Torres, 2009), menciona que “el ciclo de vida del software del Proceso Unificado
de Desarrollo (RUP) se descompone en cuatro fases secuenciales (Inicio, Elaboración,
Construcción y Transición), cada una concluida por un objetivo principal; cada fase es
esencialmente un periodo de tiempo entre dos objetivos importantes. Al final de cada fase
se lleva a cabo una valoración para determinar si los objetivos de la fase se han alcanzado”.
“Visto desde una perspectiva de gestión de proyectos, es decir el punto de vista de
negocios, el ciclo de vida del software se organiza a los largo de cuatro fases principales”
según el autor (Kruchten, 1996). A continuación se describen las fases del ciclo de vida de
RUP. 1
1. Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del
proyecto con los patrocinadores, identificar los riesgos asociados al proyecto,
proponer una visión muy general de la arquitectura de software y producir el plan
de fases y el de iteraciones posteriores.
2. Fase de Elaboración: En esta fase se seleccionan los casos de uso que permiten
definir la arquitectura base del sistema, se realiza la especificación de los casos de
uso seleccionados y el primer análisis del dominio del problema, se diseña la
solución preliminar.
3. Fase de Construcción o Desarrollo: El propósito de ésta fase es completar la
funcionalidad del sistema, para ello se deben clarificar los requerimientos
pendientes, administrar los cambios de acuerdo a las evaluaciones realizadas por
los usuarios, además se realizan las mejoras para el proyecto.
4. Fase de Transición o Cierre: El propósito de esta fase es asegurar que el software
esté disponible para los usuarios finales, ajustar los errores y defectos encontrados
en las pruebas de aceptación, capacitar a los usuarios y proveer soporte técnico
necesario. Se debe verificar que el producto cumpla con las especificaciones
entregadas por las personas involucradas en el proyecto.
1 http://www.unix.eng.ua.edu/~crutcher/class/cs600/papers/A_Rational_Development_Process.pdf
http://www.unix.eng.ua.edu/~crutcher/class/cs600/papers/A_Rational_Development_Process.pdf
13
El ciclo de vida del proceso de desarrollo de software RUP, se descompone en las cuatro
fases mencionadas anteriormente, en la que en cada extremo de una fase se realiza una
evaluación para determinar si los objetivos de la fase se han cumplido, una vez cumplida
la fase se procede a la siguiente fase luego de una evaluación satisfactoria de la fase
anterior, como se refleja en la Figura 3.
Figura 3. Fases de RUP. Fuente: (Kruchten, 1996).
Para la solución software del presente proyecto se hará uso de las cuatro fases del
ciclo de vida de RUP, en la que cada fase se evaluará en función de la entrega y
cumplimiento de los artefactos correspondientes a cada fase, realizando las
iteraciones necesarias para la entrega de un producto software de calidad.
1.1.5. Artefactos de RUP.
El autor (Rueda Chacón, 2006), menciona que “los artefactos son el resultado parcial o
final que es producido y usado por los actores durante el proyecto. Son las entradas y
salidas de las actividades realizadas por estos actores, los cuales utilizan y van
produciendo estos artefactos para tener guías. Un artefacto pueden ser un documento, un
modelo o un elemento de modelo”.
“Las actividades tienen artefactos de entrada y de salida, un artefacto es un producto de
trabajo de un proceso; los trabajadores utilizan artefactos para realizar actividades y
producen artefactos como resultados de sus actividades. Los artefactos son
responsabilidad de un único trabajador y promueven la idea de que toda pieza de
información en el proceso debe ser responsabilidad de un rol específico, un trabajador es
el propietario de un artefacto, pero otros trabajadores pueden usarlo y tal vez modificarlos
si tienen permisos para ello”, según el autor (Belloso Cicilia, 2009).
En opinión a estos autores, se pudo analizar que los artefactos se desarrollan dentro de
las disciplinas del ciclo de vida de la metodología de desarrollo de software, el desarrollo
14
de los artefactos depende del personal involucrado en el proceso de desarrollo, ya sean
desarrolladores, analistas o arquitectos de software. Esto permitirá el entendimiento de
todo el proceso de desarrollo y el cumplimiento de las cuatro fases de la metodología.
RUP en cada una de sus fases realiza una serie de artefactos que sirven para comprender
de mejor manera tanto el análisis como el diseño de un sistema2. En la Figura 4 se muestra
los artefactos a ser elaborados en las cuatro fases del Proceso Unificado de Rational RUP
como Inicio, Elaboración, Construcción y Transición empleados en el desarrollo de la
presente solución software.
Figura 4. Fases y artefactos de RUP. Fuente: (Valladolid Zhingre, 2014).
Para el desarrollo y cumplimiento de las cuatro fases de la metodología de desarrollo de
software RUP, se cumplirán con los siguientes artefactos:
Fase de Inicio:
o Documento de visión (Ver Anexo D).
o Documento de Especificación de requerimientos (Ver Anexo E)
Fase de Elaboración:
2 http://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP
FASES DE RUP
Fase de Inicio
Documento de Visión
Especificación de Requerimientos
Fase de Elaboración
Especificación de casos de uso
Arquitecura de Software
Vista Lógica
Diagrama de Clases
Modelo Entidad Relación
Vista de Implementación
Diagrama de Secuencia
Diagrama de Estados
Diagrama de Colaboración
Vista deProcesos
Diagrama de Actividad
Vista de Despliegue
Diagrama de Despliegue
Fase de Construcción
Desarrollo de la solución software
Fase de Transición
Manual de Usuario
http://procesosdesoftware.wikispaces.com/METODOLOGIA+RUP
15
o Documento de Especificación de casos de uso (Ver Anexo F)
o Documento de Arquitectura de software (Ver Anexo G)
Fase de Construcción:
o Desarrollo de la solución software (Ver Capítulo 3).
Fase de Cierre o Transición:
o Documento de Plan de Pruebas (Ver Anexo H).
o Manual de usuario (Ver Anexo I).
Estos artefactos son documentos que representan el inicio y final de las disciplinas del ciclo
de vida del proceso de desarrollo de software, el cumplimiento de cada uno de estos
artefactos se realizarán ejecutando las iteraciones necesarias que podrán garantizar el
efectivo desarrollo de la solución software, alineándose a la arquitectura de software
seleccionada.
1.2. Phonegap.
En la actualidad existen muchas herramientas disponibles para el desarrollo de
aplicaciones móviles multiplataforma, entre las cuales está Phonegap, considerada una de
las más usadas, la más completa, robusta y la que mejor documentación tiene, según el
autor (Tunaroza Saavedra, 2014).
Phonegap es un marco de código abierto para la construcción rápida de aplicaciones
móviles multiplataforma utilizando HTML5, JavaScript y CSS3 según (PhoneGap, 2012).
Además los autores (Singh & Palmieri, 2011), menciona que Phonegap es una solución útil
para la construcción de aplicaciones multiplataforma usando tecnologías web modernas.
En la Figura 5, se muestra el funcionamiento y la composición de las aplicaciones con
Phonegap, aplicaciones que están constituidas con HTML5, JavaScript y CSS3, las
mismas que se empaquetan con Phonegap para dar salida a una aplicación híbrida para
dispositivos móviles multiplataforma.
Figura 5. Funcionamiento de Phonegap
Fuente: (PhoneGap, 2012)
16
El autor (Siles, 2013), menciona que “Phonegap está realizado sobre Apache Córdova y
fue creado por Nitobi en el 2008, actualmente es propiedad de Adobe y crea las
llamadas aplicaciones híbridas a mitad del camino entre las nativas y las puramente web,
esto lo consigue a partir de una serie de APIs que permiten controlar características de los
dispositivos como el acelerómetro, la cámara, las notificaciones o la geolocalización”.
En base a las opiniones de estos autores, se puede analizar que Phonegap es una
plataforma abierta que permite desarrollar aplicaciones para dispositivos móviles con
tecnologías conocidas y compila las aplicaciones creadas con su entorno para seis
sistemas operativos: Apple iOS, Google Android, BlackberryOS, WebOS, Windows Mobile
y Symbian. Para el desarrollo de la solución software del presente proyecto se utilizará el
framework Phonegap de uso libre y gratuito para el desarrollo de la aplicación de
lecturación y bloqueo de medidores de GLP, con lo que se dispondrá de una aplicación
flexible, dinámica e intuitiva, ya que su desarrollo se basa en el uso de tecnologías libres
como HTML5, Javascript y CSS3 proporcionando un diseño compacto y amigable para el
usuario.
1.2.1. Apache Córdova
Apache Córdova es un conjunto de APIs que permite a los desarrolladores acceder a las
funciones nativas del dispositivo móvil, como la cámara o el acelerómetro desde
JavaScript. Combinando con frameworks de UI como jQuery Mobile, Dojo Mobile o Sencha
Touch, lo que permite a las aplicaciones Smartphone ser desarrolladas con HTML5, CSS3
y JavaScript según (Cordova, 2013). Córdova ofrece un conjunto de bibliotecas de
JavaScript que pueden ser invocadas con código específico desde el dispositivo mediante
código JavaScript.
Apache Córdova está en la mayoría de plataformas móviles al igual que de los APIs
disponibles para estas plataformas, como se muestran en la Tabla 1.
17
Tabla 1. APIs disponibles para plataformas móviles.
API’s
iPh
on
e /
iPh
on
e 3
G
iPh
on
e
3G
S y
más
rec
ien
te
An
dro
ide
Bla
ck
berr
y O
S 6
.0 +
Bla
ck
berr
y 1
0
Acelerómetro Cámara Brújula - - Contactos Expediente Geolocalización Medios de comunicación - Red Notificación (Alerta)
Notificación (Sonido) Notificación (Vibraciones) Almacenamiento
Fuente: (PhoneGap, 2012).
La mayoría de APIs de Apache Córdova están disponibles en plataformas móviles como
Android, iPhone y Blackberry. Las plataformas que no soportan estos APIs, es debido a las
restricciones que poseen en su hardware o software.
Para el desarrollo de la solución software en el presente proyecto, se tomará en cuenta
solamente el uso de los siguientes APIs:
Geolocalización: Esta api será utilizada para proporcionar información acerca de
la ubicación en parámetros de latitud y longitud de las residencias de los clientes
de Instalaciones Centralizadas, por medio del Sistema de Posicionamiento Global
(GPS).
Red: Esta api será utilizada para verificar el estado de la red del dispositivo móvil,
con el objetivo de hacer uso efectivo de la aplicación móvil.
Notificación (Alerta): Esta api será utilizada para presentar notificaciones visuales
en el dispositivo móvil, como por ejemplo mensajes visuales que confirmen las
acciones que se realizan en el dispositivo.
1.3. Android.
Según el autor (Nieto Gonzales, 2011), “Android es un sistema operativo inicialmente
pensado para teléfonos móviles, al igual que iOS, Symbian y BlackBerry OS. Lo que lo
hace diferente es que está basado en Linux, un núcleo de sistema operativo libre,
gratuito y multiplataforma”. El sistema permite programar aplicaciones en una variación
de Java llamada Dalvik. El sistema operativo Android proporciona todas las interfaces
18
necesarias para desarrollar aplicaciones que accedan a las funciones del teléfono como
GPS, llamadas, agenda, etc.), de una forma muy sencilla en un ambiente de programación
muy conocido como es Java.
Android es un sistema operativo de código libre el cual en los últimos años ha incrementado
exponencialmente su participación en el mercado, convirtiéndose en una de las
plataformas líderes en ventas de equipos y contando con la mayor cantidad de aplicaciones
disponibles para descargar, según el autor (Iskandar Morine, 2013).
Hoy en día los teléfonos inteligentes ejecutan varios sistemas operativos como: Android
OS, BlackBerry, Symbian, iOS, MeeGo y Windows Phone. A medida que el mercado de
teléfonos inteligentes en todo el mundo continúa madurando, para el 2014 se espera un
crecimiento de 19.3% con respecto a 2013 según el autor (Richter, 2014). Se espera
pequeños cambios para que Android mantenga su posición como el sistema dominante,
mientras que iOS de Apple es favorito para estabilizar su cuota de mercado en torno al
15% como se puede observar en la Figura 6.
Figura 6. Sistemas operativos móviles más usados. Fuente: (Richter, 2014).
En base a las opiniones antes mencionadas se puede analizar que Android es
especialmente popular por ser de uso libre, gratuito y multiplataforma respecto a los
teléfonos inteligentes de Apple como el iPhone. El desarrollo de aplicaciones en Android
se ha convertido en uno de los campos de mayor interés para desarrolladores y empresas
de desarrollo de software, con el objetivo de proponer productos innovadores y de gran
alcance para la mayoría de los usuarios.
19
1.3.1. Versiones de Android
En la Tabla 2, se muestra información acerca del uso de las diferentes versiones del
sistema operativo Android, en la que se pone de manifiesto que “la versión de Android Jelly
Bean que ya tiene más de un año al día de hoy, es la versión más usada con un 55% en
los dispositivos móviles que poseen este sistema operativo, de ahí le sigue la versión
Gingerbread con un 16% y en última posición la versión Froyo con un 1% en los dispositivos
móviles actuales.” 3
Tabla 2. Versiones del sistema operativo Android.
VERSIÓN CODENAME API DISTRIBUCIÓN
2.2 Froyo 4 1,0% 2.3.3 – 2.3.7 Gingerbread 10 16.2% 3.2 Panal 13 0,1% 4.0.3 – 4.0.4 Ice Cream Sandwich 15 13,4% 4.1.x 4.2.x 4.3
Jelly Bean 16 17 18
33,5% 18,8% 8,5%
4.4 Kitkat 19 8,5
Fuente: (Developers, Android, 2014).
En la Figura 7, se puede observar que la versión Jelly Bean es la más utilizada por los
usuarios Android con un 60.8%, que comprende desde la versión 4.1 hasta la 4.3, luego la
versión Gingerbear es la más usada con el 16,2% y el resto de versiones posee un 23%
de uso por los usuarios, según (Developers, Android, 2014).
Figura 7. Distribución de versiones android. Fuente: (Developers, Android, 2014)
En vista a que Android se ha convertido en el sistema operativo más utilizado para
dispositivos móviles en la actualidad; para el desarrollo del presente proyecto se hará uso
de éste sistema operativo móvil, para el desarrollo e implementación de la aplicación móvil.
Cabe resaltar que la solución software trabajará sobre la versión 2.2 Froyo o superior, por
3 http://developer.android.com/about/dashboards/index.html
http://developer.android.com/about/dashboards/index.html
20
lo que podrá trabajar sin ningún inconveniente con las versiones superiores de Android
como Ice Cream Sandwich, Jelly Bean y Kitkat.
1.4. Arquitectura de Software
El autor (Kazman, 2011), menciona que la arquitectura de software es importante como
una disciplina debido a que los sistemas de software crecen, de tal forma que resulta muy
complicado que sean diseñados, especificados y entendidos por un solo individuo. Uno de
los aspectos que motivan el estudio en este campo es el factor humano en términos de
inspecciones de diseño, comunicación a alto nivel, desarrollo, reutilización de componentes
y comprobación a alto nivel de diseños alternativos.
La arquitectura de software, es el proceso de definición de una solución estructurada que
cumple con todos los atributos de calidad, tales como el rendimiento, seguridad y facilidad
administración. Se trata de una serie de decisiones basadas en una amplia gama de
factores en que cada una de estas decisiones puede tener impacto considerable en la
calidad, el funcionamiento, el mantenimiento y el éxito en general de la aplicación, según
los autores (Conery, Rob; Hanselman, Scott; Phil, Haack; Guthrie, Scott, 2009).
De acuerdo al Software Engineering Institute (SEI), la Arquitectura de Software se refiere
a las estructuras de un sistema, compuesta de elementos con propiedades visibles de
forma externa y las relaciones que existen entre ellos según el autor (Cervantes, 2010). El
término “elementos” dentro de la definición del SEI, puede referirse a distintas entidades
relacionadas con el sistema; los elementos pueden ser entidades que existen en tiempo de
ejecución (objetos, hilos), entidades lógicas que existen en tiempo de desarrollo (clases,
componentes) y entidades físicas (nodos, directorios). Por otro lado, las relaciones entre
elementos dependen de propiedades visibles de los elementos, quedando ocultos detalles
de implementación. Finalmente cada conjunto de elementos relacionados de un tipo
particular corresponde a una estructura distinta, de ahí que la arquitectura está compuesta
por distintas estructuras.
1.4.1. La importancia de la Arquitectura de Software
Al igual que cualquier otra estructura compleja, el software debe ser construido sobre una
base sólida y estructurada, el no considerar escenarios claves por la falta de diseño o en
su defecto despreciar consecuencias a largo plazo, pueden poner en riesgos las
aplicaciones de software. Los riesgos expuestos por la mala arquitectura incluye software
inestable e incapaz de ser apoyo a las soluciones de software en la empresa, de abordar
21
futuros requisitos o es difícil implementar y gestionar en un entorno de producción, según
los autores (Conery, Rob; Hanselman, Scott; Phil, Haack; Guthrie, Scott, 2009).
Según el autor (Cervantes, 2010) “la arquitectura de software es de especial importancia
ya que la manera en que se estructura un sistema tiene un impacto directo sobre la
capacidad de este para satisfacer lo que se conoce como atributos de calidad del sistema”.
Atributos de calidad como el desempeño, que tiene que ver con el tiempo de respuesta del
sistema en las peticiones que se hacen, usabilidad, que tiene que ver con qué tan sencillo
les resulta a los usuarios realizar operaciones en el sistema, o bien la modificabildiad, que
tiene que ver con qué tan simple resulta introducir cambios en el sistema. Los atributos de
calidad son parte de los requerimientos no funcionales del sistema y representan
características que deben expresarse de forma cuantitativa.
En opinión de estos autores, se puede concluir que la arquitectura de software permitirá
comprender, organizar y comunicar las estructuras que componen un sistema, con el
propósito de satisfacer los atributos de calidad como: desempeño, usabilidad, seguridad,
además de servir de guía para el desarrollo de la solución software. Con la arquitectura de
software se define de manera abstracta los componentes de un sistema, los procesos de
información, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser
implementada en una arquitectura física, que consiste en determinar en qué ordenador o
componente físico tendrá asignada cada tarea de ejecución.
1.4.2. Consideraciones claves para el diseño de la Arquitectura de Software
Las principales decisiones que se debe tomar en cuenta para el diseño de la arquitectura
de software, son los factores importantes a medida que comienza y se desarrolla el diseño
de la arquitectura según los autores (Conery, Rob; Hanselman, Scott; Phil, Haack; Guthrie,
Scott, 2009); a continuación se mencionan estos:
Determinar el tipo de aplicación.
Determinar la estrategia de implementación.
Determinar las tecnologías apropiadas.
Determinar los atributos de calidad.
Para una mayor comprensión de los presentes factores, a continuación se realiza una
breve descripción de cada uno de ellos:
22
Determinar el tipo de aplicación.
Elegir el tipo de aplicación apropiada es parte clave del proceso de diseño de la
arquitectura de software, su elección se rige por sus necesidades e infraestructura
limitada. Este punto cubre los siguientes tipos de aplicaciones básicas como:
Aplicaciones diseñadas para dispositivos móviles.
Aplicaciones de cliente enriquecido diseñados para funcionar principalmente en
un terminal cliente.
Aplicaciones dinámicas de internet, diseñadas para ser desplegados a través
de internet, que apoya una rica interfaz de usuario.
Aplicaciones de servicio diseñados para apoyar la navegación entre
componentes de la aplicación.
Aplicaciones web diseñadas para funcionar principalmente en un servidor
completamente conectado a escenarios.
Determinar la estrategia de implementación.
La aplicación puede ser desplegada en una variedad de ambientes, cada uno con su
conjunto específico de restricciones, tales como la separación física de los
componentes a través de servidores. Existen varios patrones de implementación que
tienen beneficios comunes y consideraciones para una serie de escenarios distribuidos
y no distribuidos en que se debe equilibrar los requisitos de la aplicación con los
requisitos de hardware.
Determinar las tecnologías apropiadas.
Los factores claves a considerar para el uso de la tecnología son; el tipo de aplicación
que se desarrollará, la forma de implementación y los estilos arquitectónicos. La
selección de la tecnología también se toma en cuenta en las políticas de la
organización, las limitaciones de la infraestructura y el uso de los recursos.
Determinar los atributos de calidad.
En todos los diseños de aplicaciones se deben considerar la seguridad y el rendimiento,
pero cada diseño no se debe tomar únicamente la interoperabilidad o escalabilidad,
sino entender sus necesidades y el despliegue de escenarios para que la aplicación
use los atributos de calidad necesarios para su diseño.
23
Por lo antes descrito, en el Anexo G se realizará el diseño respecto a la vista lógica,
vista de implementación, vista conceptual y vista física que componen la
arquitectura de software empleada en el desarrollo de la solución software.
1.4.3. Patrones de Arquitectura de software.
Los patrones de arquitectura expresan el esquema fundamental de organización para los
sistemas de software, proveen un conjunto de subsistemas predefinidos, especifican sus
responsabilidades e incluyen reglas y guías para organizar las relaciones entre ellos. Los
patrones de arquitectura representan el nivel más alto en el sistema de patrones propuesto
en Pattern Oriented Software Architecture4, según el autor (Welicki, Leon, 2012), como se
muestra en la Figura 8.
Figura 8. Patrones según el nivel de detalle. Fuente: (Developers, Android, 2014)
El autor (Welicki, Leon, 2012) menciona que es importante destacar que esta división no
es absoluta ni totalmente comprehensiva, dado que no incluye a otros patrones de amplia
aceptación y utilización como los de análisis, integración de aplicaciones, pruebas, etc.
Según el autor (Ayala Wilson, 2011), “los patrones de arquitectura están orientados a
representar los diferentes elementos de componentes en una solución software y las
relaciones entre ellos. A diferencia de los patrones de diseño de software que están
orientados a objetos y clases (patrones creacionales, estructurales, de comportamiento, de
interacción, etc.), los patrones de arquitectura están a un mayor nivel de abstracción”.
4 http://msdn.microsoft.com/es-es/library/bb972251.aspx
http://msdn.microsoft.com/es-es/library/bb972251.aspx
24
Los patrones de arquitectura forman parte de la llamada Arquitectura de Software
(arquitectura lógica de un sistema)5, que de forma resumida comprende:
El diseño de más alto nivel de la estructura del sistema.
Los patrones y abstracciones necesarios para guías la construcción del software de
un sistema.
Los fundamentos para que analistas, diseñadores, programadores, beta testers,
etc., trabajen en una línea común que permita cubrir restricciones y alcanzar los
objetivos del sistema.
Los objetivos del sistema, no solamente funcionales, si no de mantenimiento,
auditoría, flexibilidad e interacción con otros sistemas.
Las restricciones que limitan la construcción del sistema acorde a las tecnologías
disponibles para su implementación.
En base a las opiniones de estos autores, se puede analizar que un patrón arquitectónico
expresa un esquema estructural organizacional para un sistema de software, comprende
los subsistemas, sus funcionalidades e interrelaciones entre los componentes del sistema.
Un patrón arquitectónico no es una arquitectura como tal, sino más bien un concepto de
captura de elementos esenciales de una arquitectura de software a un nivel mayor de
abstracción que los patrones de diseño.
1.4.3.1. Patrón Arquitectónico MVC.
Según el autor (Fernandéz Portero, 2011), “MVC son las siglas del Model-View-Controller
(Modelo-Vista-Controlador)”, el cual es un patrón de arquitectura del software descrito en
1979 por el Noruego Trygve Reenskaug. El punto principal de MVC es dividir la aplicación
en tres capas reales: una para datos, otra para la lógica de negocio y otra para la
presentación consiguiendo que sea mantenible, escalable y reutilizable.
El patrón MVC es un patrón de arquitectura de las aplicaciones de software que separa la
lógica del negocio, de la interfaz de usuario y del acceso a datos. Incrementa la reutilización
y la flexibilidad a cambios6, según el autor (Pavón Mestras, 2010).
5 http://jmaw.blogspot.com/2011/04/h2-margin-bottom-0.html 6 https://www.fdi.ucm.es/profesor/jpavon/poo/2.14.MVC.pdf
http://jmaw.blogspot.com/2011/04/h2-margin-bottom-0.htmlhttps://www.fdi.ucm.es/profesor/jpavon/poo/2.14.MVC.pdf
25
A continuación se presenta el funcionamiento del patrón arquitectónico MVC en
aplicaciones web, java swing y el framework phonegap, que se utilizará para el desarrollo
e implementación de la aplicación de lecturación y bloqueo de medidores de GLP.
MVC en aplicaciones Web:
o Vista: Representa la página HTML.
o Controlador: Representa el código que obtiene datos dinámicamente
o Modelo: Es la información almacenada en una base de datos o en XML,
junto con las reglas de negocio que transforman esa información teniendo
en cuenta las acciones de los usuarios.
MVC en Java Swing:
o Vista: Conjunto de objetos de clases que heredan de java.awt.component.
o Controlador: Es el thread de tratamiento de eventos, que captura y propaga
los eventos a la vista y al modelo
o Modelo: Modelo que define el desarrollador según el desarrollo de la
aplicación.
MVC en Phonegap:
o Vista: Representa la vista del usuario hacia la aplicación móvil haciendo uso
de HTML5 y CSS3.
o Controlador: El controlador responde a los eventos de la Vista e invoca
peticiones al Modelo haciendo uso de JavaScript y Ajax.
o Modelo: Representa la lógica de la aplicación que interactúa con la base de
datos, realizando transacciones de información mediante PHP.
Phonegap al hacer uso de tecnologías web como HTML5, CSS3 y JavaScript, es posible
construir aplicaciones móviles adaptadas al patrón arquitectónico MVC. Esto se lo puede
realizar mediante el uso de cualquier framework MVC como Backbone.js, Ember.js,
Knockout.js, JavaScript MVC, Angular.js7 o mediante el desarrollo propio de cada una de
los componentes de este patrón arquitectónico.
Para el desarrollo del presente proyecto, se hará uso de este patrón arquitectónico que
permitirá la construcción de la solución software de forma escalable y mantenible ya que
permitirá la separación de la lógica del negocio, de la interfaz de usuario y del acceso a
datos, además ayudará a controlar de mejor manera los recursos del dispositivo móvil
7 http://www.codejobs.biz/es/blog/2013/04/11/los-5-mejores-frameworks-mvc-de-javascript#sthash.czlTqMH8.dpbs
http://www.codejobs.biz/es/blog/2013/04/11/los-5-mejores-frameworks-mvc-de-javascript#sthash.czlTqMH8.dpbshttp://www.codejobs.biz/es/blog/2013/04/11/los-5-mejores-frameworks-mvc-de-javascript#sthash.czlTqMH8.dpbs
26
como la carga de datos y los recursos de red, debido a que el modelo se implementará
físicamente de manera independiente de la Vista y el Controlador, construyendo una
aplicación flexible y eficiente para el usuario. Con el uso de este patrón arquitectónico la
aplicación móvil estará compuesta por la Vista y el Controlador, los mismos que se
empaquetarán en la aplicación móvil mediante el framework Phonegap. Para mayor detalle
del desarrollo e implementación del presente proyecto con el uso del patrón arquitectónico
MVC refiérase al Capítulo 3.
1.4.4. Estilos de Arquitectura de software.
Un estilo de arquitectura de software es un conjunto de principios que proporcionan un
marco abstracto para una familia de sistemas. Un estilo arquitectónico mejora el
particionamiento y promueve la reutilización del diseño, proporcionando soluciones a los
problemas recurrentes en el diseño del proyecto, se puede pensar al estilo de arquitectura
como un patrón que dan forma a una aplicación según los autores (Conery, Rob;
Hanselman, Scott; Phil, Haack; Guthrie, Scott, 2009).
Garlan y Shaw definen un estilo de arquitectura como: “Una familia de sistemas en términos
de un patrón de organización estructural, más en concreto, un estilo arquitectónico
determina el vocabulario de los componentes y los conectores que se pueden utilizar. Uno
de los beneficios más importantes es que proporciona un lenguaje común para varios
sistemas” según los autores (Conery, Rob; Hanselman, Scott; Phil, Haack; Guthrie, Scott,
2009). En la Tabla 3 se muestra las principales áreas de interés correspondientes a los
estilos arquitectónicos:
Tabla 3. Estilos de Arquitectura de Software
CATEGORÍA ESTILOS DE ARQUITECTURA
Comunicación Arquitectura Orientada a Servicios (SOA), Bus de Mensajes.
Despliegue Arquitectura Cliente/Servidor, N-Niveles, 3-Niveles Dominio Dominio de Diseño Estructura Arquitectura Basada en Componentes, Orientada a
Objetos, Arquitectura en capas.
Fuente: (Conery, Rob; Hanselman, Scott; Phil, Haack; Guthrie, Scott, 2009).
Para el desarrollo del presente proyecto se tomará en cuenta un estilo de arquitectura ideal
para la solución software, que optimice el diseño y construcción de todas las estructuras
que lo compongan. Para esto es necesario realizar una correcta selección del estilo de
arquitectura de software; es por esto que en la Tabla 4 se realiza una breve descripción de
los estilos arquitectónicos antes mencionados:
27
Tabla 4. Descripción de los estilos arquitectónicos
ESTILO DE ARQUITECTURA
DESCRIPCION
Cliente/Servidor Divide el sistema en dos aplicaciones, en la que el cliente realiza las solicitudes al servidor. En muchos casos, el servidor es una base de datos con la lógica de la aplicación representando como procedimientos almacenados.
Arquitectura basada en componentes
Descompone el diseño de la aplicación en funciones reusables o componentes lógicos, que establecen interfaces de comunicación bien definidos.
Arquitectura en capas Particiones de la aplicación en grupos aislados (capas). Bus de mensaje Es un estilo de arquitectura que describe el uso de un sistema de
software que puede recibir y enviar mensajes a través de uno o varios canales de comunicación, por lo que las aplicaciones pueden interactuar sin necesidad de conocer los detalles específicos entre sí.
N-niveles / 3-niveles Divide funcionalidad en segmentos separados de la misma manera que el estilo de arquitectura en capas, pero con cada nivel siento situado en un equipo físicamente independiente.
Orientado a objetos Un paradigma diseño basado en la división de responsabilidades para una aplicación o sistemas en objetos reutilizables y autosuficientes, cada uno con los datos y el comportamiento relevante para el objeto.
Arquitectura orientada a servicios (SOA)
Se refiere a las aplicaciones que exponen y consumen la funcionalidad como un servicio mediante el paso de mensajes o protocolos de comunicación.
Fuente: (Conery, Rob; Hanselman, Scott; Phil, Haack; Guthrie, Scott, 2009).
El objetivo de la descripción de los presentes estilos arquitectónicos es seleccionar, utilizar
y aprovechar al máximo un estilo de arquitectura de software que garantice el
funcionamiento y desempeño óptimo de la solución software a desarrollarse. Para esto se
debe considerar la infraestructura de TI de la compañía, las seguridades a nivel de
servidores y redes de comunicaciones, además de la utilización de tecnologías libres que
no representen costos por producción ni de mantenimiento para la compañía Lojagas.
A continuación se hace una breve explicación del porqué los presentes estilos de
arquitectura de software no se enmarcan dentro del desarrollo de la solución software:
Bus de Mensajes: La solución software no necesita comunicarse con otro tipo de
aplicaciones, ya sea por medio de protocolos de red o paso de mensajes, por lo
tanto no es aplicable este estilo de arquitectura para el desarrollo de la presente
solución software.
N-niveles / 3-niveles: Este estilo de arquitectura es de similares características que
el estilo de arquitectura en capas, a diferencia que este estilo, cada nivel de capas
se deben ubicar en servidores diferentes para aumentar en mayor grado la
seguridad por cada nivel, por lo tanto no es aplicable ya que la solución software se
debe adaptar a la infraestructura de TI de la compañía y esta no cuenta con la
infraestructura necesaria para la implementación de este estilo de arquitectura.
28
Orientado a objetos: Este estilo de arquitectura no es aplicable para la solución
software ya que su desarrollo se basa en Phonegap que es HTML5, JavaScript y
SCC, realizando la programación por medio de funciones JavaScript y Ajax.
Orientado a servicios (SOA): Este estilo de arquitectura no es adecuada para el
desarrollo del presente proyecto, ya que no se ofrecerá servicios adicionales por
medio de este estilo de arquitectura, además que la compañía actualmente no
cuenta con la infraestructura ni las seguridades adecuadas para la implementación
de servicios tipo Web Service.
1.4.5. Cuadro Comparativo de los Estilos de Arquitecturas de Software.
Una vez descartados los estilos de arquitecturas que no se enmarcan dentro del desarrollo
de la solución software en el presente proyecto, a continuación en la Tabla 5 se presenta
un cuadro comparativo de los posibles estilos de arquitectura a ser tomados en cuenta para
la estructura, desarrollo e implementación de los componentes de la solución software.
Tabla 5. Cuadro comparativo de los estilos de arquitecturas de software.
CLIENTE/SERVIDOR BASADA EN COMPONENTES
ARQUITECTURA EN CAPAS
Objetivo El cliente solicita los recursos y el servidor responde a la solicitud del cliente.
Enfoque de ingeniería de software para el diseño y desarrollo del sistema por componentes.
Separación de la capa de presentación, capa de negocios y la capa de datos.
Componentes Cliente
Servidor
Arquitectura basada en componentes de software (ddl).
Capa de presentación
Capa de negocios
Capa de datos
Característica principal
El servidor se vuelve polivalente, al responder directamente a todas las solicitudes del cliente.
La aplicación se construye en base al desarrollo y utilización de los diferentes componentes de software.
Permite distribuir la creación de una aplicación en niveles, en donde cada grupo de trabajo está totalmente abstraído del resto de niveles.
Ventajas Mayor seguridad Acceso a datos
centralizado. Fácil Mantenimiento Soporta muchos
clientes
Facilidad de despliegue de la arquitectura
Reducción de costos Componentes
Reutilizables.
Mantenibilidad Escalabilidad Flexibilidad Disponibilidad
Desventajas Genera mayor tráfico en la red.
Carece de extensibilidad, escalabilidad y robustez.
Dificultad en el acoplamiento de componentes
Complejidad en combinar componentes.
Dificultad en el diseño de cada capa.
El procesamiento de una capa puede retardar el procesamiento de otras.
Fuente: (Conery, Rob; Hanselman, Scott; Phil, Haack; Guthrie, Scott, 2009).
29
1.4.6. Selección del Estilo de Arquitectura de Software.
Tomando en cuenta la Tabla 5, donde se realiza la comparación entre los estilos de
arquitectura de software seleccionados como: cliente/servidor, basado en componentes y
en capas, a continuación se realiza una valoración por cada estilo arquitectónico de
acuerdo a los atributos de calidad mencionados por el autor (Perez Escobar, 2013).
Escalabilidad: Es la capacidad de expandirse en usuarios o incrementar la
capacidad del sistema sin realizar cambios.
Rendimiento: Se mide en término de la respuesta del sistema a ciertas
funcionalidades como pueden ser la velocidad de respuesta al recibir una petición
o procesar una información.
Seguridad: Es la característica que evita el acceso no autorizado o accidental de
usuarios. Es medido en función de la probabilidad de daño o riesgo a la seguridad,
número o porcentaje de daños clasificados por tipo y severidad.
Eficiencia: Es una medida de la eficiencia en el uso de los recursos del sistema y
se mide en términos de uso de memoria, ancho de banda, espacio en disco o
disponibilidad de capacidad del procesar durante las operaciones.
Disponibilidad: Está relacionada con la habilidad de acceder al sistema bajo
factores que lo afectan durante el respaldo, recuperación o reinicio y se mide como
el porcentaje del tiempo en que el sistema puede estar disponible.
Flexibilidad: Es la capacidad de adaptación para aumentar, extender o expandirse
con usuarios adicionales. Es medido en función del esfuerzo, duración o costo de
agregar o modificar componentes específicos.
En la Tabla 6, se realiza la valoración de los estilos arquitectónicos en función de los
atributos de calidad antes mencionados, en lo que se puede concluir que el estilo
arquitectónico cliente/servidor estará siempre disponible para el cliente, que únicamente
realiza las peticiones al servidor, de igual forma responde a las solicitudes bajo cualquier
circunstancia. Este estilo arquitectónico es flexible ya que puede expandirse o incrementar
considerablemente el número de usuarios que realiza las peticiones hacia el servidor,
además se aplica un mayor grado se seguridad que se concentra únicamente en el servidor
que a la vez se refleja en el cliente, En cambio el servidor no responde adecuadamente al
incremento de forma escalable por parte de los usuarios que realizan demasiadas
solicitudes al servidor, así mismo disminuye su rendimiento en procesar información y al
usar muchos recursos, lo que se vuelve deficiente al consumir mayor ancho de banda,
aumento de memoria y disco duro del servidor.
30
En cambio el estilo arquitectónico basado en componentes estará disponible el sistema
por la facilidad de despliegue de los componentes en responder a cualquier eventualidad
presentada en el servidor. Es escalable debido a la reutilización y aumento de
componentes que reflejan las funcionalidades y por lo tanto permite un mayor grado de
participación de los usuarios que acceden al sistema. Pero este estilo arquitectónico puede
bajar el rendimiento del sistema, debido a que un mal acoplamiento de los componentes
permite la disminución de solicitudes por parte del cliente, además de volverse inseguro
por el bajo grado de efectividad en que se aplica la seguridad en todo el sistema.
Tabla 6. Valoración de los estilos de arquitectura de software.
ES
TIL
OS
DE
AR
QU
ITE
CT
UR
A
DIS
PO
NIB
ILD
IAD
ES
CA
LA
BIL
IDA
D
FL
EX
IBIL
DIA
D
RE
ND
IMIE
NT
O
SE
GU
RID
AD
EF
ICIE
NC
IA
CLIENTE/SERVIDOR
-
-
-
BASADA EN COMPONENTES
- -
ARQUITECTURA EN CAPAS
Fuente: (Conery, Rob; Hanselman, Scott; Phil, Haack; Guthrie, Scott, 2009).
En cambio el estilo arquitectónico en capas permite tener un mayor grado de
disponibilidad del sistema, debido a la distribución en capas que provee de forma efectiva
la separación de funcionalidades, lo que permite la disponibilidad en cualquiera de sus
capas. Este estilo arquitectónico es escalable debido al aumento en número de capas, lo
que permite una mejor distribución de las responsabilidades del sistema y por lo tanto un
mejor desempeño que se ve reflejado en el incremento de usuarios que acceden y realizan
transacciones de forma simultánea. Este estilo de arquitectura no solo se presenta el
número de capas, sino que también se distribuye cada capa en máquinas físicas o en una
misma máquina, comunicándose con los componentes de otras capas a través de
interfaces bien definidas. Además de ser flexible al aplicar cambios en cualquiera de sus
capas, lo que se ve reflejado en el rendimiento del sistema al responder de mejor manera
las solicitudes por parte de los usuarios, lo que le permite ser eficiente distribuyendo los
recursos de hardware y software, aplicando seguridades en las capas requeridas.
Con esto se puede concluir que la arquitectura en capas es el que mejor se adapta a la
solución software del presente proyecto, debido a la disponibilidad, escalabilidad y
31
flexibilidad en la implementación de la solución software, además presenta un mejor
rendimiento e implementación de las seguridades según las capas requeridas, ya que
permite el uso eficiente de los recursos de hardware y software.
Por lo antes descrito, a continuación se hace una breve descripción del estilo de
arquitectura empleado para el desarrollo de la solución software del presente proyecto.
1.4.7. Estilo de Arquitectura en Capas.
Los autores (Mark, Ahmad, & Tento, 2011), menciona que la arquitectura en capas es en
realidad un estilo de programación donde el objetivo principal es separar los diferentes
aspectos del desarrollo, tales como las cuestiones de presentación, lógica de negocio,
mecanismos de almacenamiento.
La arquitectura por capas es una de las técnicas más comunes que los arquitectos de
software que utilizan para dividir sistemas de software complicados. Al pensar en un
sistema en términos de capas, se imaginan los principales subsistemas de software
ubicados de la misma forma que las capas de un pastel, donde cada capa descansa sobre
la inferior, según el autor (Guerrero, 2012)
Es por esto que la programación por capas es una arquitectura que separa en tres niveles
la programación de un sistema en capa de presentación, capa de negocios y capa de datos.
Una de las ventajas es que el desarrollo se puede llevar a cabo en varios niveles y caso de
ocurrir algún cambio en los requerimientos del usuario, solo se realiza el mantenimiento al
nivel correspondiente, según el autor (Arenas Paredes, 2011), como se muestra en la
Figura 9.
Figura 9. Arquitectura en tres capas Fuente: (Arenas Paredes, 2011)
32
Capa de presentación
En la capa de presentación se encuentra todo el diseño del sistema, es decir la
parte que el usuario visualiza, la cual sirve de medio de comunicación para receptar
y capturar la información.
En esta capa no se desarrolla ninguna validación sobre las funcionalidades que
presente la aplicación, ya que se encargará únicamente de la presentación de la
información, la cual debe tener la característica de ser amigable, entendible y fácil
de uso para el usuario.
Capa de negocio
En esta capa se ubica la parte lógica, donde se ejecutan las peticiones del usuario
y se envían las respuestas tras el proceso; por lo que se podría decir que es una
vía de comunicación entre la IU y la lógica de negocios.
Capa de datos
En esta capa residen los datos y es la encargada de acceder a los mismos, es decir
que se reciben los argumentos y se devuelven los resultados por medio de la capa
correspondiente hacia los usuarios finales.
Para el desarrollo del presente proyecto, el patrón arquitectónico Modelo Vista Controlador
MVC trabajará de forma conjunta con el estilo arquitectónico 3 capas que la conforman: la
capa de presentación, capa lógica de negocios y capa de datos, de tal forma que su
acoplamiento en conjunto permita emplear una arquitectura sólida y compacta que facilite
la escalabilidad y productividad del sistema. El uso del estilo de arquitectura 3 capas en el
presente proyecto se describen en el Capítulo 2, como parte de la posible solución de
software.
33
CAPÍTULO 2: DEFINICIÓN DEL PROBLEMA Y ANÁLISIS INICIAL.
34
2. Introducción
El conocimiento a detalle del proceso, por medio de herramientas de capturas de
información como entrevistas o encuestas, sirve para conocer y analizar toda la
problemática del proceso de investigación, llegando a proponer soluciones que resuelvan
el problema planteado y alcanzar a validar sus objetivos y resultados.
En el presente capítulo se describe el proceso de lecturación y bloqueo de medidores de
GLP que actualmente ejecuta la compañía, también se detalla la problemática que existe
en el proceso, asimismo se menciona las alternativas de la solución software a través del
análisis y diseño del proyecto, y se describe los beneficios obtenidos en la implantación de
la solución propuesta.
2.1. Descripción del Proceso Actual.
La Compañía de Economía Mixta LOJAGAS fue constituida en la ciudad de Loja el 8 de
diciembre de 1990, en un esfuerzo conjunto entre inversionistas locales y la empresa
estatal Petroecuador, con la finalidad de racionalizar la actividad de envasado y
comercialización de gas licuado de petróleo (GLP) en el país, descongestionando y
descentralizando las operaciones del sector. El 1 de octubre de 1991, Lojagas inició sus
operaciones en la Planta Envasadora que se instaló en el cantón de Catamayo, a 35km de
la provincia de Loja. Desde entonces, la Compañía ha logrado fortalecer su infraestructura
operativa efectuando grandes inversiones en tecnificación y modernización de sus
instalaciones