-
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
