modelo arquitectural para aplicaciones …bibcyt.ucla.edu.ve/edocs_bciucla/repositorio/tgmqa... ·...
TRANSCRIPT
i
UNIVERSIDAD CENTROCCIDENTAL
“LISANDRO ALVARADO”
MODELO ARQUITECTURAL PARA APLICACIONES MÓVILES USANDO
EL ENFOQUE DE LÍNEAS DE PRODUCCIÓN DINÁMICA DE SOFTWARE
ELIEMAR PASTORA GÓMEZ VARGAS
Barquisimeto, 2011
ii
UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO"
DECANATO DE CIENCIAS Y TECNOLOGÍA
POSTGRADO EN CIENCIAS DE LA COMPUTACIÓN
MODELO ARQUITECTURAL PARA APLICACIONES MÓVILES USANDO
EL ENFOQUE DE LÍNEAS DE PRODUCCIÓN DINÁMICA DE SOFTWARE
Trabajo presentado para optar al grado de Magister Scientiarum
en Ciencias de la Computación Mención Ingeniería de Software
Por: ELIEMAR PASTORA GÓMEZ VARGAS
Barquisimeto, 2011
iii
MODELO ARQUITECTURAL PARA APLICACIONES MÓVILES USANDO
EL ENFOQUE DE LÍNEAS DE PRODUCCIÓN DINÁMICA DE SOFTWARE
Por: ELIEMAR PASTORA GÓMEZ VARGAS
Trabajo de Grado Aprobado
_______________________ ______________________ (Jurado 1) (Jurado 2)
_______________________ (Jurado 3)
Barquisimeto, ___ de __________ de 2011
iv
DEDICATORIA
A Dios Todopoderoso, por su infinita misericordia
v
AGRADECIMIENTOS
A mis padres, hermanos, sobrinas, amigos y demás familiares que con paciencia
me han acompañado en esta travesía, que me apoyan y me alientan a seguir, a ellos
mis más sinceros agradecimientos, debido a que son el motor que impulsa mi vida.
A la Universidad Centroccidental Lisandro Alvarado por impartir conocimientos
dentro y fuera de sus aulas de clases formando así excelentes profesionales y
ciudadanos dignos. En especial al personal de postgrado por su colaboración.
Al Dr. Rodolfo Canelón, por su particular forma de hacer ver la realidad, por su
dedicación y sobre todo por su amistad.
A Leiban Rivero, buen esposo, excelente compañero de clases y compañero de
vida, especialmente al bebé que está por nacer, extensión de nuestras vidas y fuente
de inspiración para alcanzar las metas planteadas.
A la Fundación Nadbio, organización donde laboro por su apoyo incondicional y
también a los compañeros de trabajo que definitivamente se convierten en miembros
de una familia especial.
vi
ÍNDICE GENERAL
Página
DEDICATORIA .................................................................................................... iv AGRADECIMIENTOS .......................................................................................... v ÍNDICE DE TABLAS ......................................................................................... viii ÍNDICE DE FIGURAS .........................................................................................iix RESUMEN .............................................................................................................. x INTRODUCCIÓN .................................................................................................. 1 CAPÍTULO I EL PROBLEMA
Planteamiento del Problema .................................................................................. 4 Objetivos .............................................................................................................. 8
Objetivo General ............................................................................................... 8 Objetivos Específicos ........................................................................................ 8
Justificación e Importancia .................................................................................... 9 Alcances y Limitaciones ..................................................................................... 10
CAPÍTULO II MARCO TEÓRICO
Antecedentes ....................................................................................................... 12 Antecedentes de modelos arquitecturales para aplicaciones móviles ................ 12 Antecedentes de Líneas de producción dinámica de software .......................... 15
Bases Teóricas .................................................................................................... 20 Arquitectura de Software ................................................................................. 20 Reutilización de Software ................................................................................ 23 Ingeniería de dominio ...................................................................................... 24 Ingeniería de la aplicación ............................................................................... 26 SPEM 2 ........................................................................................................... 26 InDoCaS: Un proceso para la Ingeniería del dominio basado en calidad de software .......................................................................................................... 28 Líneas de Producción de software (LPS) ......................................................... 35 Líneas de Producción Dinámicas de software (LPDS) ..................................... 37 Gestión de Variabilidad ................................................................................... 42 Aplicaciones Móviles ...................................................................................... 46 Calidad de Software: Estándar ISO 25010 ....................................................... 47
Operacionalización de las Variables .................................................................... 50 CAPÍTULO III MARCO METODOLÓGICO
Naturaleza del estudio ......................................................................................... 53 Fases del Estudio ................................................................................................ 53 Fase I: Diagnóstica .............................................................................................. 54
Población y Muestra ........................................................................................ 54
vii
Procedimiento ................................................................................................. 54 Técnicas e Instrumentos de Recolección de Datos ........................................... 55
Fase de Factibilidad ............................................................................................ 55 Factibilidad Técnica ............................................................................................ 55 Factibilidad Económica ....................................................................................... 56 Factibilidad Social .............................................................................................. 56
CAPÍTULO IV PROPUESTA DEL ESTUDIO
Justificación ........................................................................................................ 57 Objetivos ............................................................................................................ 58
Objetivo General ............................................................................................. 58 Objetivos Específicos ...................................................................................... 58
Descripción de la Propuesta ................................................................................ 59 Estructura del modelo propuesto ......................................................................... 60 Definición de la actividad y sus artefactos ........................................................... 63
Actividad A_02a: Generar modelos dinámicos ................................................ 63 Artefacto 4.1: Conjunto de puntos de variación dinámicos .............................. 64 Artefacto 4.2: Conjunto de Características Dinámicas ..................................... 65 Artefacto 4.3: Informe de Decisión .................................................................. 67
Enfoque de líneas de producción dinámica de software ....................................... 67 Requisitos de Referencia ................................................................................. 67 Clasificación de las líneas de producción dinámicas de software ..................... 69 Estrategia de Adaptación y Reconfiguración ................................................... 70
Caso de Estudio .................................................................................................. 72 Dominio: Aprendizaje de idiomas asistido por móviles (MALL) ..................... 72 Identificación de Requisitos ............................................................................ 78 Obtener modelo de similitudes y variabilidad .................................................. 79 Generar modelos dinámicos ............................................................................ 82 Identificación de propiedades de calidad ......................................................... 85 Obtener modelo de calidad asociado al dominio .............................................. 88 Identificar estilos arquitecturales ..................................................................... 89
CAPÍTULO V CONCLUSIONES Y RECOMENDACIONES
Conclusiones ....................................................................................................... 91 Recomendaciones ............................................................................................... 93
GLOSARIO DE TÉRMINOS .............................................................................. 94 REFERENCIAS BIBLIOGRÁFICAS ................................................................. 96 ANEXOS A. Currículo vitae del autor ................................................................................ 102
viii
ÍNDICE DE TABLAS Tabla Pág.
1 Resumen de los antecedentes…………………………………………….. 18 2 Arquitectura y UML……………………………………………………… 22 3 Esquema de actividad InDoCaS………………………………………….. 30 4 Esquema de artefacto InDoCaS………………………………………….. 31 5 Lista de actividades para análisis del dominio InDoCaS………………… 34 6 Operacionalización de las variables a estudiar…………………………... 52 7 Actividad A_02a: Generar modelos dinámicos …………………………... 64 8 Artefacto A: Conjunto de puntos de variación dinámicos...……………... 65 9 Artefacto B: Conjunto de características dinámicas……....……………... 66 10 Artefacto C: Informe de decisión………………….……....……………... 67 11 Requisitos de Referencia…………………………...……....……………... 67 12 Clasificación de las líneas de producción dinámicas de software………... 69 13 Actividades del proceso InDoCaS aplicadas al dominio MALL………… 77 14 Lista de requisitos funcionales del dominio……………………………… 78 15 Lista de requisitos no funcionales del dominio…………………………... 79 16 Conjunto de Características…...………………………………………….. 80 17 Conjunto de puntos de variación…………………………………………. 80 18 Conjunto minimal de requisitos funcionales y no funcionales…………… 81 19 Conjunto de puntos de variación dinámicos……………………………... 82 20 Conjunto de características dinámicas ………………………….………... 83 21 Informe de decisión……………………………………......……………... 84 22 Lista de requisitos funcionales con su propiedad de calidad……………... 85 23 Lista de requisitos no funcionales con su propiedad de calidad………...... 86 24 Modelo de calidad asociado al dominio…………...……....……………... 88 25 Estilos Arquitecturales…………………………………………..………... 90
ix
ÍNDICE DE FIGURAS Figura Pág.
1 Modelo 4+1 Vistas de Arquitectura de Software…………………………. 22 2 Reutilización de Software………………………………………………… 24 3 Modelo de proceso para el desarrollo de software basado en
componentes……………………………………………………………… 25 4 Marco de trabajo general con SPEM 2…………………………………… 28 5 Disciplinas del proceso InDoCaS………………………………………… 29 6 Análisis del Domino InDoCaS…………………………………………… 32 7 Diagrama de actividades para el análisis del dominio InDoCaS………… 33 8 Modelo básico de una línea de productos de software…………………… 35 9 Proceso de línea de producción dinámica de software…………………… 39 10 Línea de producción dinámica de software conectada…………………… 40 11 Línea de producción dinámica de software desconectada……………….. 41 12 Ejemplo del modelo de características…………………….…………….. 45 13 Enfoques de calidad de software………………………………….……… 48 14 Características y sub-características de calidad interna y externa…..…… 49 15 Características y sub-características de calidad en uso…………...……… 50 16 Notación de Variabilidad añadidos a SPEM 2……….…………...……… 60 17 Lista de actividades para la disciplina de análisis del dominio InDoCaS
especializada……………………………………………………………… 61 18 Diagrama de actividades para la disciplina análisis del dominio InDoCaS
especializada ……………………………………...……………………… 62 19 Notación para características dinámicas.…………….…………...……… 66 20 Estrategia de Reconfiguración……………………….…………...……… 70 21 Estrategia de Adaptación…………………………….…………...……… 72
x
UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO"
DECANATO DE CIENCIAS Y TECNOLOGÍA
POSTGRADO EN CIENCIAS DE LA COMPUTACIÓN
MODELO ARQUITECTURAL PARA APLICACIONES MÓVILES USANDO
EL ENFOQUE DE LÍNEAS DE PRODUCCIÓN DINÁMICA DE SOFTWARE
Autor(a): Ing. Eliemar Pastora Gómez Vargas
Tutor(a): Dr. Rodolfo Antonio Canelón Osal
RESUMEN La arquitectura de software, consta de un conjunto de patrones y abstracciones coherentes que proporcionan un marco referencial para guiar la construcción de aplicaciones. Los productos de software que comparten ciertas características se denominan familias de productos, para éstas la arquitectura es importante puesto que fortalece el desarrollo de productos similares a partir de un diseño y la reutilización de activos de software. Las aplicaciones móviles, en particular, implican un desarrollo de software altamente dinámico, distribuido, móvil, inalámbrico y con procesamientos heterogéneos sobre un gran número de plataformas restringidas por escasos recursos, estas aplicaciones requieren adaptarse tanto a las capacidades de acceso en diversos dispositivos como a diferentes contextos, conservando consistencia y utilidad. Estos requisitos de variabilidad y adaptabilidad en el software representan un reto interesante dentro de la ingeniería de software. Por otro lado, las líneas de producción de software, han aparecido como un enfoque cuyo objetivo es crear diferentes versiones de software a partir de una infraestructura común, del mismo modo como se hace en el sector industrial. La siguiente investigación, tiene como propósito proponer un modelo arquitectural para aplicaciones móviles usando el enfoque de líneas de producción dinámica de software, incorporando atributos de calidad. Se basa en una metodología de proyecto factible como una propuesta en la línea de investigación de Ciencias de la Computación mención Ingeniería de Software. Para lograr el objetivo se estudiará el proceso de líneas de producción dinámica de software, se especializará el proceso de Ingeniería de dominio en su disciplina análisis del dominio presentado en InDoCaS, un proceso para la ingeniería del dominio basado en calidad de software y se experimentará sobre el dominio de aprendizaje de idiomas asistido por móviles (MALL, por sus siglas en inglés). Palabras Claves: Arquitectura de software, aplicaciones móviles, calidad de software, ingeniería de dominio, líneas de producción dinámicas de software.
1
INTRODUCCIÓN
En los últimos años se ha incrementado el uso de dispositivos móviles, los
teléfonos celulares por ejemplo, han dejado de ser sólo instrumentos de transmisión
de voz para convertirse en aparatos capaces de procesar y transmitir información.
Actualmente el desarrollo de sistemas para escenarios móviles se ha difundido
considerablemente, con una variedad que van desde las orientadas a empresas,
pasando por las de uso personal, sin dejar de lado aquellas utilizadas simplemente
para el entretenimiento.
Estas tecnologías permiten a sus usuarios desplazarse, sin renunciar a las
funcionalidades y los recursos de conexión. Estos cambios han permitido el acceso a
todo tipo de información en cualquier lugar y momento, posibilitando la computación
en múltiples y variados contextos. Sin embargo, las condiciones actuales, están
relacionadas no sólo con las propiedades del equipo sino con el usuario e incluso con
el entorno, convirtiéndose en requisitos volátiles que advierten ciertas capacidades
adaptables.
Debido a esta situación, emergen desafíos interesantes dentro de la ingeniería de
software para el desarrollo de aplicaciones que deben evolucionar rápidamente y la
acción de analizar el diseño antes comenzar a escribir una sola línea de código, es sin
lugar a dudas, un punto que no puede ser menospreciado. El modelado de una
arquitectura de software a nivel conceptual permite al arquitecto decidir asuntos que
tendrán influencia a lo largo de todo el ciclo de vida de la aplicación.
Por otro lado, las líneas de producción de software, han aparecido como un
enfoque cuyo objetivo es crear diferentes versiones de software a partir de una
infraestructura común, del mismo modo como se hace en el sector industrial. En el
mundo actual, donde lo constante es el cambio, las líneas de producción de software
2
pueden ayudar a las empresas a superar los problemas causados por la escasez de
recursos humanos, la variabilidad de las aplicaciones o la diversidad de requisitos.
Organizaciones de todo tipo y tamaño han descubierto que un enfoque de línea de
producción de software, cuando se aplica adecuadamente, puede producir muchos
beneficios y en última instancia, dar a las organizaciones ciertas ventajas
competitivas.
Considerando a las líneas de producción dinámica de software como una instancia
o caso particular de las líneas de producción de software, se tiene que, el propósito de
esta investigación radica en proponer un modelo arquitectural para aplicaciones
móviles usando estas últimas. Un modelo arquitectural se entiende como la
infraestructura que soporta los requisitos comunes que comparten los productos de
software de la línea de producción, se hace énfasis en que la línea sea dinámica,
precisamente por la presencia de la adaptabilidad y se pretende medir los atributos de
calidad de los productos a través de un modelo de calidad, que se obtiene en etapas
tempranas del desarrollo.
Es propio señalar que en la ingeniería de las líneas de producción de software se
distinguen dos procesos principales: a) Ingeniería del dominio: cuyos productos son
componentes de software, requisitos reutilizables y configurables, modelos de
análisis y diseño y b) Ingeniería de la aplicación: del cual se derivan productos
individuales de la familia de productos, construidos usando un subconjunto de
artefactos de software compartidos.
En consecuencia, se trabajará en la ingeniería del dominio en su disciplina análisis
del dominio, siguiendo un proceso para la ingeniería del dominio basado en calidad
de software denominado InDoCaS, el cual será especializado, para trabajar con las
líneas de producción dinámicas de software agregando variabilidad en el método y
construyendo los activos de software necesarios.
3
Además, de esta introducción el presente proyecto está estructurado de la siguiente
manera:
En el Capítulo I, se inicia con planteamiento del problema, la situación que genera
el trabajo de investigación, se describen los objetivos tanto el general como los
específicos, se menciona la justificación, importancia, alcances y limitaciones,
representando estos elementos las bases que conducen la investigación.
El Capítulo II, denominado marco teórico, señala los antecedentes y bases teóricas
que apoyan el conocimiento sobre el tema de estudio. Se describen entre otros tópicos
los siguientes: arquitectura de software, el proceso para la ingeniería del dominio
basado en calidad de software InDoCaS, líneas de producción de software,
variabilidad y calidad de software, terminando este capítulo con el sistema de
variables y su respectiva operacionalización.
En el Capítulo III, se detallan los aspectos metodológicos respecto a la naturaleza
de la investigación y las fases diagnóstica y de factibilidad propias de un proyecto
factible.
El Capítulo IV, llamado propuesta del estudio, describe la propuesta de la
investigación, cuya estructura fundamentada en el proceso para la ingeniería del
dominio basado en calidad de software InDoCaS, expresa la forma de especializar
dicho proceso de manera que sea útil en el enfoque de desarrollo de línea de
producción de dinámica de software y se experimenta el resultado sobre un dominio
particular de las aplicaciones móviles.
Finalmente, en el Capítulo V se mencionan las conclusiones y recomendaciones
del trabajo de investigación así como sus aportes y estudios futuros.
4
CAPÍTULO I
EL PROBLEMA
Planteamiento del Problema
En las organizaciones, buena parte del negocio se apoya en los sistemas
informáticos. Esta especie de dependencia se hace notable en numerosos sectores de
la sociedad, lo que se traduce en un marcado esfuerzo por mejorar el desarrollo de
sistemas para satisfacer necesidades. Las tecnologías móviles, por su parte, han
evolucionado en los últimos años, lo que genera un crecimiento en el mercado de
dispositivos móviles, permitiendo que lleguen a más personas a menor costo. La
utilidad que se les da a tales dispositivos es variada, incluyen la recreación, el medio
de comunicación, la aplicación empresarial, aplicaciones de aprendizaje, entre otras,
propiciando de esta manera una evolución en el desarrollo de aplicaciones de
software para este tipo de tecnologías.
Es de hacer notar, que durante los últimos años se ha incrementado el uso de los
dispositivos móviles y según ciertos estudios “se multiplicará por cinco en el mercado
mundial para el año 2011” (Bellé y García, 2008), lo que plantea nuevos retos a los
departamentos de tecnologías de información de las compañías. Asimismo, un
estudio presentado por Cavesein1, destacó que “durante el año 2007, de los 23.8
millones de usuarios de los servicios móviles en el país, consumieron cerca de 37
millones de dólares en servicios de valor agregado diferentes a la voz y al popular
SMS” (Tomás, 2009). Por otro lado, Venezuela concluyó el 2008 con una mercado
1 Cavesein: Cámara Venezolana de Servicios de Integración
5
móvil de 97% comparado con el 87% de fines del 2007 según datos del mismo
estudio, lo que indica que Venezuela no es la excepción.
En efecto, el principal atractivo de estos equipos es la movilidad, el acceso a la
información y funcionalidad a cualquier hora y lugar, posibilitando así la
computación en múltiples y variados contextos. Sin embargo, las condiciones del
tiempo real, están relacionadas no sólo con las características de hardware (ancho de
banda, disponibilidad del servidor, nivel de conectividad, restricciones de pantalla,
entre otros) sino también relacionadas con el usuario (localización, necesidades,
tareas a realizar, perfil entre otros) e incluso con el entorno del móvil (día de la
semana, horas, condiciones ambientales), dichas características son en su mayoría
muy volátiles y requieren de ciertas capacidades de adaptación, es decir, las
aplicaciones móvil “deben adaptarse tanto a las capacidades de acceso en diversos
dispositivos como a diferentes contextos, conservando consistencia y utilidad” según
menciona (Canelón et al, 2007).
Esta situación permite reflejar que la adaptación en las aplicaciones móviles
supone un reto importante, un reto sobre adaptabilidad. Ésta se puede definir como
“la capacidad de cambiar la funcionalidad de un producto automáticamente sin la
interacción de los usuarios, este grado de autonomía implica el uso de técnicas que
proporcionen el conocimiento o la capacidad de razonamiento para adaptarse en
tiempo de ejecución” (Canelón et al, 2009)b.
Más aún, los usuarios están acostumbrados a ciertos servicios y resulta difícil
satisfacer sus necesidades más recientes. En este escenario aparecen nuevas
necesidades, cada vez más desafiantes y complejas que las anteriores, que obligan a
soluciones que deben ser puestas en servicio con mayor rapidez y menor costo.
Cabe resaltar que, en general las aplicaciones de software están en constante
evolución debido, no sólo a los cambios en los procesos de negocio y al incremento
en las expectativas de los clientes, sino también a los continuos cambios en las
6
plataformas de desarrollo, lenguajes de programación, tecnologías, los requisitos
mismos entre otros. Para evitar que las aplicaciones comiencen a perder vigencia y
progresivamente aumente su complejidad, es necesario que “las actividades de
configuración y mantenimiento de las mismas sean parte integral de los procesos que
rigen su ciclo de vida de construcción, lo cual constituye uno de los principales
problemas de los procesos de desarrollo tradicionales”, según (Mens et al, 2005).
De lo anterior, es propio mencionar el aspecto de variabilidad, conocida como “la
capacidad de cambiar o personalizar un sistema de software”, según (Ye y Liu, 2005).
El manejo de la variabilidad en etapas tempranas del desarrollo, se centra en el
proceso de dirigir productos nuevos de una manera tal que sea posible reutilizar
componentes del producto y diferenciarlos con costos y tiempo disminuidos. La
familia de producto consta de componentes y estructuras reutilizables tanto como sea
posible.
En otras palabras, la versatilidad que proporcionan las aplicaciones acrecienta en
cierta medida la complejidad del desarrollo, tal como lo afirma (Canelón et al, 2007)
“…la heterogeneidad incrementa los costos de desarrollo de dichas aplicaciones”.
Esta complejidad se pone de manifiesto en el diseño, los tiempos de presentación en
el mercado, los tiempos y esfuerzos de desarrollo, especialmente los costos de
implementación, la calidad del producto de software y la satisfacción del usuario.
Por lo tanto, se hace necesario el estudio de un modelo arquitectural basado en
líneas de producción de software, que permite a una organización determinar y
reutilizar activos de software para la creación eficiente de aplicaciones móviles
adaptables que comparten algunas similitudes, pero que varían en conocimiento y
formas de manejo. A esto se le denomina, gestión de la variabilidad entre productos
miembros de una misma familia.
Se hace énfasis en el uso de las líneas de producción dinámicas de software,
puesto que derivan productos de software autónomos que se ejecutan sobre diversos
7
dispositivos móviles empleando una base común de componentes adaptables y
reutilizables en lugar de implementaciones de cada sistema de un modo separado,
siendo apropiado diseñar dichas aplicaciones como miembros de una familia de
productos configurables y con calidad.
Por otra parte, la calidad de software se define como “la totalidad de rasgos y
características de un producto de software que le confieren su aptitud para satisfacer
necesidades explícitas o implícitas” (ISO/IEC, 2001). Para especificar claramente los
requisitos explícitos o implícitos, se han definido modelos de calidad, tales como
ISO/IEC2 25010 (ISO/IEC, 2009), el cual puede ser utilizado para determinar los
requisitos de calidad y proporcionar bases para cuantificarlos en términos de medidas
específicas. Los modelos de calidad, en general, “son estructuras jerárquicas, donde
las características de calidad de alto nivel son refinadas en subcaracterísticas, hasta
identificar propiedades o atributos medibles” (Canelón et al, 2009)a.
En atención a lo anteriormente expuesto, se propone un modelo arquitectural
basado en líneas de producción dinámicas de software para abordar los aspectos de
adaptabilidad, variabilidad y calidad en aplicaciones móviles siguiendo el proceso
para la ingeniería del dominio basado en calidad de software InDoCaS.
Por consiguiente, se plantean como interrogantes de esta investigación las
siguientes:
¿Cuáles son los requisitos mínimos que expresan adaptabilidad y calidad en el
dominio de aplicaciones móviles?
¿De qué manera el enfoque de las líneas de producción dinámica beneficia el
desarrollo de aplicaciones móviles?
¿Cuál es el modelo arquitectural planteado para la línea de producción
dinámica de software?
2 ISO/IEC: siglas de International Organization for Standardization / International Electrotechnical Commission
8
¿Cómo validar la arquitectura para asegurar que es consistente al conjunto de
requisitos mínimos de una familia de producto?
Partiendo de las interrogantes expuestas anteriormente, surge la necesidad de crear
un modelo arquitectural para aplicaciones móviles utilizando un enfoque de líneas de
producción de software. Dichas interrogantes obtendrán sus respuestas a través de los
objetivos específicos de la presente investigación.
Objetivos
Objetivo General
Proponer un modelo arquitectural para aplicaciones móviles usando el enfoque de
líneas de producción dinámica de software.
Objetivos Específicos
1. Especificar los requisitos mínimos que manifiestan adaptabilidad y calidad en
aplicaciones móviles.
2. Presentar el enfoque de líneas de producción dinámica de software para el
manejo de variabilidad en el desarrollo de aplicaciones móviles
3. Desarrollar el modelo arquitectural para aplicaciones móviles especializando el
proceso InDoCaS para el manejo de las líneas de producción dinámica de software.
4. Proponer una arquitectura para el dominio de aprendizaje de idiomas asistido
por móviles (MALL3).
3 MALL: siglas de Mobile Assisted Language Learning
9
Justificación e Importancia
La presente investigación fundamenta su justificación en la obtención de un
modelo arquitectural que garantice adaptabilidad en aplicaciones móviles y que ayude
a cumplir los objetivos principales de un línea de producción de software que son
capitalizar las similitudes y gestionar la variabilidad para reducir el tiempo, esfuerzo,
costo, complejidad del manejo, mantenimiento de diversas variaciones en diferentes
productos, necesidad de respuestas rápidas a demandas continuas de clientes y
mercado. Además, este enfoque permite describir no sólo un sistema de software,
sino un conjunto de productos de software en el mismo dominio.
Por otro lado, construir una arquitectura para una línea de producción que se
adapta dinámicamente a los cambios en los requisitos, implica asegurar la
configuración del producto en tiempo de ejecución, esto es útil en otros dominios
emergentes como la computación ubicua, la robótica, la domótica o la inteligencia
ambiental cuyas solicitudes están aumentando en complejidad demandando mayor
grado de adaptación de sus sistemas de software.
Además, la utilidad de las aplicaciones en general se mide en función de la calidad
de las funciones que presta. Por ello, este trabajo se enfoca en un modelo de calidad
para el dominio de las aplicaciones móviles, usado para construir la propuesta
arquitectural y así asegurar la calidad de los productos de software, en etapas
tempranas del desarrollo.
Ahora bien, se espera que los resultados de esta investigación sean de importancia
en el área de aplicaciones para dispositivos móviles, líneas de producción dinámicas
de software e ingeniería del dominio, siendo modelo de referencia para impulsar
nuevos proyectos, en beneficio de la comunidad científica debido a que sus objetivos
permiten la difusión de nuevo conocimiento.
10
En beneficio además de la industria de desarrollo de software, que puede
incorporar este modelo arquitectural como parte de sus activos de software en los
ambientes de desarrollo, puesto que el uso de modelos arquitecturales permite ahorrar
tiempos de desarrollo lo que se traduce en disminución en los tiempos de entrega y
costos asociados al producto.
Finalmente al usuario de dispositivos móviles quien podría experimentar la
reducción de tiempo en las versiones y actualizaciones de sus aplicaciones o servicios
y un aumento en la calidad de los mismos.
Alcances y Limitaciones
El alcance del presente estudio se ajusta a la presentación de un modelo
arquitectural para aplicaciones móviles basado en una línea de producción dinámica
de software, que garantice propiedades de adaptabilidad y calidad en aplicaciones
móviles. Gestionando a través del enfoque de líneas de producción de software los
aspectos asociados a la variabilidad.
Para caracterizar el dominio se ajusta un proceso para la ingeniería de dominio,
llamado InDoCaS 4 de forma tal que sea útil para el desarrollo de software bajo el
enfoque de líneas de producción dinámicas de software. Posteriormente se sigue el
proceso de línea de producción dinámica de software, donde se adicionan las
estrategias de adaptación y reconfiguración al proceso tradicional de líneas de
producción de software, para conseguir productos de software que se adapten en
tiempo de ejecución, es decir, que se adaptan dinámicamente.
Con esto, se examinan los estilos arquitecturales que aportan solución al dominio,
para luego generar el modelo arquitectural, finalmente se examina la arquitectura
4 InDoCaS: proceso para la Ingeniería de Domino basado en Calidad de Software
11
propuesta haciendo uso del dominio el dominio de aprendizaje de idiomas asistido
por móviles (MALL).
En lo que respecta a las limitaciones, se observan brechas en las actividades que
guían la obtención del modelo arquitectural para la línea de producción dinámica de
software, careciendo de los artefactos necesarios para obtener los activos de software
asociados a la línea de producción. Además se tratan las limitaciones que son propias
de las aplicaciones móviles.
12
CAPÍTULO II
MARCO TEÓRICO
Antecedentes
Diversos esfuerzos se han realizado, para crear aplicaciones a través del enfoque
de líneas de producción de software, con la finalidad de reducir los tiempos de
entrega, los esfuerzos y el costo de desarrollo así como también aumentar la calidad,
la gestión de variabilidad, las ventajas competitivas y la prestación de servicios de los
sistemas informáticos en general. Esto se debe, entre otras cosas, a que las líneas de
producción de software hacen una sistemática reutilización de la arquitectura de
software.
Para la elaboración de este proyecto de investigación se hizo necesaria la revisión
bibliográfica y de trabajos de grado en cuanto a modelos arquitecturales para
aplicaciones móviles y líneas de producción dinámicas de software, con el fin de
constituir un grupo de antecedentes válidos relacionados con las variables en estudio.
Antecedentes de modelos arquitecturales para aplicaciones móviles
La arquitectura de software debe describir la estructura de alto nivel del software.
Generalmente, esta estructura se define de una manera más comprensible si se
utilizan distintos modelos o vistas, a continuación se citan los antecedentes de los
modelos arquitecturales para aplicaciones móviles.
13
Se comienza citando, Canelón et al (2009)a, en una investigación acerca de
interfaces dinámicas en dispositivos móviles, cuya finalidad era explicar por qué usar
el patrón mediator como una posible solución al problema de las interfaces dinámicas
implementándolo a través de los agentes móviles, asimismo incorpora un modelo
para evaluar plataformas de desarrollo e incorpora un caso de estudio sobre el
dominio del comercio móvil.
Los autores comprobaron que el uso de los agentes móviles en la implementación
del patrón mediator, hace que la aplicación pueda funcionar en distintos dispositivos
para diferentes servicios, sin que el usuario note cómo se comunica el dispositivo con
tales servicios disponibles. En el mismo trabajo se presenta patrones de diseño para
agentes clasificándolos en patrones de migración, patrones de tareas y patrones de
interacción.
Esta investigación sirve de apoyo al presente proyecto ya que presenta
características similares con el objeto de estudio puesto que muestra un sistema
multiagente para tratar el problema de las interfaces dinámicas en dispositivos
móviles, problema que tiene propiedades de adaptabilidad.
No obstante se limita a presentar la arquitectura para el caso de las interfaces
dinámicas en particular, sin atacar otras características de las aplicaciones móviles,
mientras que en esta investigación se intentan abordar un conjunto de requisitos y
propiedades de calidad comunes a una familia de productos de software.
En ese mismo año, Canelón y otros (2009)c, definen un modelo de calidad para el
dominio de aplicaciones móviles sensibles al contexto. La importancia de este
modelo es la especificación de los requisitos de calidad para el producto final del
software y éste también puede ser usado para una evaluación cuantitativa de todos los
productos de software durante el proceso de desarrollo.
El nivel de servicio requerido se especifica de acuerdo a un modelo de calidad.
Este modelo se define utilizando una clasificación denominada RECLAMO 5 y el
5 RECLAMO: siglas de Requirements Classification Model
14
estándar ISO/IEC 25010 es usado para identificar los requisitos de calidad y para
especificar un modelo de calidad.
La investigación anterior es de importancia para este proyecto, puesto que muestra
cómo especificar los requisitos agregándole atributos de calidad ajustados al estándar
ISO/IEC 25010. Además el dominio seleccionado (aplicaciones móviles sensibles al
contexto) coincide con las características de adaptabilidad que se desean abordar en
este estudio. Sin embargo existen limitaciones en el proceso utilizado para la
obtención del modelo arquitectural basado en los requisitos de las aplicaciones
móviles.
Para el año siguiente, Canelón (2010) en su tesis doctoral logra detallar un proceso
para la ingeniería del dominio basado en calidad de software con una aplicación al
dominio del aprendizaje móvil sensible al contexto. Dicho proceso denominado
InDoCaS, tiene por objetivo obtener una arquitectura base para una familia de
productos de software con un enfoque de líneas de producción de software.
Para esta investigación es muy importante este antecedente puesto que los
productos de software derivados del análisis del dominio son fácilmente reutilizables
y ajustables a otro dominio en particular, y el enfoque de líneas de producción de
software da la posibilidad de extender el modelo hacia una línea dinámica de
software.
Sin embargo, en la disciplina análisis del dominio, de donde se deriva el modelo
arquitectural, no se generan los activos de software necesarios para construir la
arquitectura base para una línea de producción dinámica de software, por lo que no
puede ser usado en su totalidad.
15
Antecedentes de Líneas de producción dinámica de software
Los sistemas de software tratan un creciente número de requisitos, requisitos que a
su vez evolucionan con el tiempo. Para operar con éxito en estas circunstancias, las
aplicaciones deben ser capaces de adaptarse de forma autónoma a las diversas
limitaciones y situaciones de forma autónoma. El enfoque de líneas de producción de
software puede ser utilizado con éxito para ofrecer dicha flexibilidad, pero para ser
realmente eficaz sus capacidades deben evolucionar para hacer trabajar los sistemas
en tiempo de ejecución. En los últimos años, esta rama de sistemas de software se ha
consolidado como líneas de producción dinámica de software.
En una Línea de Producción Dinámica de Software se manejan diversas variantes
del software, los puntos de variación están vinculados de manera flexible, pero todo
esto se hace en tiempo de ejecución, lo que significa que la derivación producto
entero es completamente automático. Estas líneas, están fuertemente relacionadas con
temas de investigación actuales, como los sistemas de autogestión, autonomía y
sistemas ubicuos. Sin embargo, combina técnicas de Línea de Producción de
Software, ingeniería de dominio, ingeniería de aplicación, métodos y procesos como
base conceptual. A continuación se citan los antecedentes de líneas de producción
dinámicas de software que apoyan la presente investigación.
Se inicia con, Cetina y otros (2008), quienes se enfocan en presentar una ontología
acerca de las líneas de producción dinámicas de software, desde un punto de vista
arquitectural. Clasifica las líneas en conectadas y desconectadas, de acuerdo al
mecanismo de adaptación del producto configurable y para aprovechar las ventajas de
ambos tipos propone un enfoque híbrido llamado mixto.
El aporte a esta investigación radica en la definición y clasificación de las líneas
de producción dinámica de software, presentando una infraestructura base para
desarrollarlas. Define incluso los elementos involucrados en el desarrollo de la línea
16
dinámica, establece una clara comparación con las líneas de producción habituales y
las caracteriza desde la perspectiva de la línea y la perspectiva del producto
configurable que se genera.
Sin embargo, el estudio se limita a presentar los elementos de una línea de
producción dinámica, sin mencionar el proceso de desarrollo de la misma, el análisis
diseño e implementación, con sus activos de software como modelos, ni la gestión de
variabilidad tanto en el producto cómo en la línea.
Más adelante, Canelón y otros (2009)b, muestran una posible solución al problema
de las interfaces dinámicas en dispositivos móviles utilizando el enfoque de líneas de
producción dinámicas de software, propuesto por Cetina y otros (2008). La
arquitectura base planteada, consiste en una combinación entre el patrón mediator
implementado con agentes móviles, que incorpora además un modelo de calidad para
evaluar las plataformas de desarrollo y se aplica la solución a un caso de estudio en el
dominio de comercio móvil.
En dicha investigación, el sustento es más tangible ya que se utilizan los conceptos
de líneas de producción dinámicas de software, presentando la construcción de la
estructura básica de la línea dinámica de software y proponiendo una arquitectura de
agentes que se ajusta a las actividades de decisión y reconfiguración propias de las
líneas dinámicas.
No obstante, en este enfoque de línea de producción dinámica de software no se
hace mención sobre el proceso de desarrollo, cuáles son las actividades que generan
los activos de software de la línea y se limita a presentar una solución arquitectural
para el requisito de interfaces dinámicas en dispositivos móviles únicamente.
Poco después, Parra y Otros (2009), construyen una línea de producción dinámica
de software sensible al contexto llamada “CAPucine”, para desarrollar aplicaciones
orientadas a servicios y adaptarlas en tiempo de ejecución de acuerdo con su contexto
de uso. Se basa en dos fases para derivar el producto. La primera fase usa los activos
17
que representan las características de la familia, modelos que se componen y
transforman para generar el producto. La segunda fase realiza la adaptación dinámica,
introduciendo los activos que operan en tiempo de ejecución, que se componen de
tres tipos de datos: cuándo, dónde y qué cambio cambiar.
En este sentido, esta investigación es favorable puesto que se enfrenta a los
desafíos del desarrollo de sistemas móviles orientados a servicios y sensibles al
contexto. Para crear productos, propone una selección de funciones de acuerdo con la
variabilidad y las necesidades de los usuarios. Para adaptar los productos, hace uso de
la información de contexto y la capacidad de adaptación se modela con CADAs. Se
combinan además, con una plataforma genérica para cambiar la estructura y el
comportamiento del producto de forma dinámica.
Sin embargo, los esfuerzos de esta investigación están orientados a la derivación
del producto, en una primera fase se realiza la selección de características y se crea
una versión del producto, mientras que la segunda fase es un proceso iterativo donde
se usa una plataforma genérica, a la escucha de los cambios en el entorno para
adaptar los productos, es propio preguntar de qué forma se seleccionan las
características y cómo se caracteriza el dominio de las aplicaciones móviles sensibles
al contexto.
Queda claro que, este no es el primer estudio en abordar adaptación dinámica en
aplicaciones móviles. Se basa, incorpora y extiende de trabajos de investigación
anteriores. Sin embargo, se destaca porque ofrece una solución arquitectural derivada
del análisis del dominio en la disciplina de ingeniería de dominio con un enfoque de
líneas de producción dinámica de software que se puede extender a otros dominios
con una aplicación en aplicaciones móviles.
En la tabla 1 se resumen los antecedentes planteados en esta sección, se describen
los objetivos, aportes y limitaciones de cada antecedente asociado con cada variable
del estudio.
6 CADAS: siglas Context Aware Dynamic Adaptation
18
Tabla 1: Resumen de los antecedentes
Variable Antecedente Objetivos Aporte Limitaciones M
odel
o A
rqui
tect
ural
pa
ra a
plic
acio
nes
móv
iles
Canelón R., Gómez E., y Rivero L.
(2009)a. Interfaces dinámicas en dispositivos
móviles. Publicado en: Revista
“Ciencias al día”. Decanato de
ciencias. UCLA. Año 2009
Explicar por qué usar el patrón mediator como una posible solución al problema de las interfaces dinámicas implementándolo a través de los agentes móviles.
Contribuye con la creación de una arquitectura multiagente para resolver un problema de comunicación entre dispositivos y aplicaciones móviles
Se limita a presentar una arquitectura como posible solución para el caso de las interfaces dinámicas en particular.
Canelón R., Losavio F. y
Matteo A. (2009) c. Modelo conceptual para modelación de aplicaciones
móviles sensibles al contexto. Rev. Fac. Ing. UCV,
vol.24, no.2, p.93-103. ISSN 0798-
4065
Definir un modelo de calidad para el dominio de aplicaciones móviles sensibles al contexto.
Presenta cómo especificar los requisitos agregándole atributos de calidad ajustados al estándar ISO 25010, para aplicaciones móviles sensibles al contexto.
Existen limitaciones en el proceso utilizado para la obtención del modelo arquitectural basado en los requisitos de las aplicaciones móviles.
Canelón R (2010) Un proceso para la
ingeniería del dominio basado en
calidad de software. Una aplicación al dominio del
aprendizaje móvil sensible al
contexto. Tesis Doctoral. UCV
Obtener una arquitectura base para una familia de productos a través de un proceso para la ingeniería de dominio cuyas disciplinas principales son el análisis y el diseño del dominio.
Aporta un proceso para la ingeniería del dominio basado en calidad de software, siguiendo un enfoque de líneas de producto de software que se puede extender a líneas de producción dinámica de software.
Existe limitación en el análisis del dominio para obtención de los activos software necesario en la creación de líneas de producción dinámica de software.
Líne
a de
pro
ducc
ión
Din
ámic
a de
softw
are
Cetina C., Trinidad P., Pelechano V. y
Ruiz-Cortés A. (2008). An
Architectural Discussion on
DSPL. 2nd International Workshop on
Dynamic Software
Presentar una ontología acerca de las líneas de producción dinámicas de software, desde un punto de arquitectural-
Define y clasifica las líneas de producción dinámica de software, presentando una infraestructura base para desarrollarlas.
No hace mención sobre el proceso de desarrollo de la línea de producción dinámica, ni presenta cómo obtener los activos de software.
19
Product Lines
Canelón, R., Gómez, E. y Quintero, G.
(2009) b. Construcción de
Interfaces dinámicas en aplicaciones
móviles utilizando un enfoque LPDS.
4CCC. UNAB-UIS.
Bucaramanga- Colombia.
Muestran una posible solución al problema de las interfaces dinámicas en dispositivos móviles utilizando el enfoque de líneas de producción dinámicas de software.
Presenta la construcción de la estructura básica de una línea dinámica de software y propone una arquitectura de agentes ajustada a las actividades de decisión y reconfiguración de las líneas dinámicas.
No hace mención del proceso de desarrollo de la línea dinámica, limitándose a presentar una solución arquitectura sólo para el requisito de las interfaces dinámicas.
Parra, C.; Blanc, X.; Duchien, L.; Pessemier, N. y
Carton, P. (2009). CAPucine: A
Context-Aware Dynamic Software
Product Line. INRIA.
Universidad de Lille.
Construir una línea de producción dinámica de software sensible al contexto, para desarrollar aplicaciones orientadas a servicios y adaptarlas en tiempo de ejecución de acuerdo con su contexto de uso
El soporte radica en el desarrollo de sistemas móviles orientados a servicios y sensibles al contexto, de forma dinámica y autónoma.
Los esfuerzos de esta investigación están orientados a la derivación del producto, dejando a consideración los activos de software de las etapas de análisis y diseño de la línea de producción dinámica de software
Fuente: Autora de la investigación
Con base en estas experiencias y en vista del éxito logrado por las líneas de
producción dinámicas de software, se plantea el diseño de un modelo arquitectural
para aplicaciones móviles usando un enfoque de calidad basado en este grupo de
antecedentes.
20
Bases Teóricas
Arquitectura de Software
Una arquitectura de software se selecciona y diseña en base a objetivos y
restricciones. Según (Pressman et al, 2006), arquitectura de software se define como
“estructura jerárquica de los componentes del programa (módulos), la manera en que
los componentes interactúan y la estructura de datos que van a utilizar los
componentes”. Sin embargo, en un sentido más amplio, los «componentes» se pueden
generalizar para representar los elementos principales del sistema y sus interacciones.
De aquí que la arquitectura represente entonces la base de un sistema de software
y que deba ser construida pensando en satisfacer tanto las necesidades actuales, como
en proporcionar al software las capacidades necesarias para permitir su
mantenimiento y evolución de acuerdo a las necesidades del negocio y las solicitudes
de los clientes.
Cada escenario plantea retos, condiciones y necesidades diferentes, la arquitectura
de software debe plantear las herramientas, personas, presupuesto, conocimiento y
tiempo que se necesita para cada escenario. Antes de editar una sola línea de código
para implementar una solución es importante conocer la arquitectura de software,
como menciona un arquitecto de software “Programar sin una arquitectura en mente
es como explorar una gruta sólo con una linterna, no sabes dónde estás, dónde has
estado ni hacia dónde vas” Danny Thorpe.
Modelos Arquitecturales
El diseño arquitectónico se puede representar mediante uno o más modelos
diferentes. En (Pressman et al, 2006) se realiza la siguiente clasificación:
21
Los modelos estructurales: representan la arquitectura como una colección
organizada de componentes de programa.
Los modelos del marco de trabajo: aumentan el nivel de abstracción del diseño en
un intento de identificar los marcos de trabajo (patrones) repetibles del diseño
arquitectónico que se encuentran en tipos similares de aplicaciones.
Los modelos dinámicos: tratan los aspectos de comportamiento de la arquitectura
del programa, indicando cómo puede cambiar la estructura o la configuración del
sistema en función de los acontecimientos externos.
Los modelos de proceso: se centran en el diseño del proceso técnico de negocios
que tiene que adaptar el sistema.
Los modelos funcionales: se pueden utilizar para representar la jerarquía
funcional de un sistema
El modelo 4+1 vistas
Los diagramas a través de los cuales se representa el diseño y distribución del
software, pueden mostrar diferentes vistas de un mismo sistema y de las condiciones
que existen en el entorno donde se despliega.
El modelo 4+1 vistas “es una propuesta que establece las diferentes perspectivas a
través de las cuales se puede representar el diseño y arquitectura de un sistema de
software” (Krutchen, P, 1995). Este modelo define 4 vistas principales, que se
muestran en la figura 1. Vista Lógica: modelo de objetos, clases, entidad – relación,
etc. Vista de Proceso: modelo de concurrencia y sincronización. Vista de Desarrollo:
organización estática del software en su entorno de desarrollo (librerías,
componentes, etc.). Vista Física: modelo de correspondencia software - hardware
(aspectos de distribución en máquinas, por ejemplo).
22
Figura 1. Modelo 4+1 Vistas de Arquitectura de Software.
Esta propuesta presenta su propio esquema de modelado, sin embargo, la notación
más reconocida para el modelamiento de sistemas de software es UML7. Cabe
destacar que, UML nace casi a la vez que el modelo 4+1, por lo que en un origen no
existía una clara relación entre ambos, lo que a menudo produce confusión al
diseñador que en la actualidad quiere modelar una arquitectura con ambas
herramientas. A modo de resumen la translación se presenta en la tabla 2:
Tabla 2. Arquitectura y UML Vista UML Escenarios Casos de Uso Lógica Clases, de Estados y Colaboración Desarrollo Componentes Física Despliegue Procesos Actividad, Estados, Secuencia
Arquitecto de Software
Según (IEEE 1471, 2010) su significado es “la persona, equipo u organización
responsable por la arquitectura del sistema que se está llevando a cabo”, se encarga
de decidir a qué nivel, con qué estrategia, y qué herramientas son necesarias para
realizar una implementación que satisfaga los requisitos funcionales y no funcionales
de los sistemas.
7 UML: siglas de Unified Modeling Language
23
Además debe ser una persona o equipo capaz de identificar las necesidades de los
negocios, las habilidades de su equipo de trabajo, y la viabilidad de las tecnologías
disponibles para el desarrollo de software.
Un buen arquitecto debe estar en capacidad de entender todas las condiciones a las
que será sometido un sistema y proponer una solución acorde a cada escenario en
particular. Por lo tanto, la madurez de un arquitecto dará a las aplicaciones que tenga
a su cargo, una especificación coherente, para enfrentar un conjunto de riesgos mucho
más reducido que en el caso de un arquitecto aprendiz.
Reutilización de Software
Cuando en la industria de software los productos tienen requisitos cada vez más
complejos y dinámicos, y los tiempos para desarrollarlos son cada vez menores; la
reutilización y el bajo acoplamiento entre los componentes cobran vital importancia.
La reutilización del software se define como “el uso sistemático de los activos de
software existentes para la construcción de otros nuevos o para modificar los
existentes” (Duarte et al, 2002). Los activos de software desde este punto de vista
puede ser código fuente, ejecutables, plantillas de diseño, COTS (Comercial-Off-The-
Shelf) , componentes de terceros o componentes de código abierto OSS (Open Source
Software), arquitecturas de todo el software y sus componentes que forman una línea
de producto o familia de productos.
Según (Duarte et al, 2002) Los procesos de desarrollo basados en la reutilización
de software se clasifican en:
Desarrollo para reutilización. Este tipo de desarrollo, se hace pensando en la
reutilización, es decir, en la adaptación o construcción de componentes con el
propósito de ser reutilizados en futuras aplicaciones.
24
Desarrollo con reutilización. Este tipo de desarrollo consiste en la
generación de nuevos productos software integrando y reutilizando un conjunto de
componentes existentes de forma directa o pasando por un proceso de adaptación.
Apareciendo así dos tipos de ingeniería véase figura 2. La Ingeniería de dominio:
centrada en análisis, especificación e implementación de activos reutilizables de
software relativos a un dominio, y la Ingeniería de aplicación: orientada hacia la
construcción o desarrollo de productos individuales que satisfacen un conjunto de
requisitos y restricciones (expresados por un usuario específico), basándose en la
reutilización de componentes existentes y en el conocimiento del dominio.
Figura 2. Reutilización de Software (Duarte et al, 2002).
A continuación se describen las principales características de ambos procesos de
ingeniería.
Ingeniería de dominio
La ingeniería de dominio definida por (Clements, 2001) como “desarrollo central
de activos de software (core asset development), es responsable de desarrollar los
elementos comunes al dominio”. Este desarrollo se obtiene al estudiar el dominio,
definir su alcance (requisitos) dentro del mercado objetivo del desarrollo, definir los
rasgos (features), implementar los activos de software (core assets) reutilizables y su
mecanismo de variabilidad, y establecer cómo es el plan de producción.
25
Estos activos de software pueden ser modelos, arquitecturas, componentes y
artefactos de software en general, que podrán ser usados en el desarrollo de múltiples
productos de software relacionados con dicho dominio. Para facilitar la identificación
de los activos a reutilizar, la ingeniería de dominios se pueden usar repositorios que
permiten la organización, selección y mantenimiento de dichos activos.
La ingeniería de dominio se puede definir como el “proceso clave que se necesita
para el diseño sistemático de una arquitectura y de un conjunto de elementos software
reutilizables que pueden ser usados en la construcción de una familia de aplicaciones
relacionadas o subsistemas” (Montilva, 2006).
La ingeniería de dominio abarca tres actividades principales (ver figura 3):
Análisis de dominio. Proceso de generación de conocimiento.
Diseño del dominio. Especificación de la infraestructura.
Implementación del dominio. La implementación de la infraestructura.
Figura 3. Modelo de procesos para el desarrollo de software basado en
componentes.
26
Ingeniería de la aplicación
La ingeniería de aplicación definida por (Clements, 2001) como “desarrollo de
productos (product development). Sus objetivos incluyen desarrollar los productos
para clientes concretos, a partir de los recursos basados no en los requisitos del
dominio, sino en requisitos concretos de clientes”. Para ello, este segundo proceso
utiliza los recursos creados por el anterior.
Cabe destacar que, consiste en construir sistemas basados en los resultados de la
ingeniería del dominio y la misma permite coleccionar, organizar y almacenar
experiencias previas en la construcción de sistemas en la forma de activos
reutilizables en un dominio particular. Tiene como propósito “el desarrollo de
aplicaciones basado en la reutilización de activos de software producidos a través de
la ingeniería de dominio” (Montilva, 2006). Durante la ingeniería de la aplicación, se
derivan productos individuales desde la familia de productos, construidos usando un
subconjunto de artefactos de software compartidos.
La ingeniería de la aplicación está compuesta de tres actividades representadas en
la anterior figura 3, de las cuales cada uno utiliza artefactos de la ingeniería del
dominio y genera artefactos para la ingeniería de la aplicación
SPEM 2
A continuación se muestra un estándar de metamodelado que sirve para
representar procesos de ingeniería de software, se define Proceso Software como
“Un conjunto coherente de políticas, estructuras organizacionales, tecnologías,
procedimientos y artefactos que son necesarios para concebir, desarrollar, instalar y
mantener un producto software” (Ruiz y Verdugo, 2008).
SPEM 2 (Software & Systems Process Engineering Metamodel Specification,
v2.0) sirve para definir procesos de desarrollo de software y sistemas y sus
27
componentes. “Su alcance se limita a los elementos mínimos necesarios para definir
dichos procesos sin añadir características específicas de un dominio o disciplina
particular” (Ruiz y Verdugo, 2008); pero sirve para métodos y procesos de diferentes
estilos, culturas, niveles de formalismo, o modelos de ciclos de vida.
SPEM 2 se encuadra dentro de la Ingeniería de Procesos de Software, que es un
área de la Ingeniería de Software dedicada a “la definición, implementación,
medición y mejora de los procesos de Ingeniería de Software”.
No es un lenguaje de modelado de procesos en general, ya que está orientado a los
procesos software. No provee conceptos propios para modelado del comportamiento,
pero incluye mecanismos para encajar el método externo elegido (diagramas de
actividad de UML 2, BPMN/BPDM, entre otros).
La idea central de SPEM 2 para representar procesos está basada en tres elementos
básicos: rol, productos y tarea. Las tareas representan el esfuerzo a hacer, los roles
representan quien lo hace y los productos representan las entradas que se utilizan en
las tareas y las salidas que se producen.
La idea central subyacente es que un modelo de proceso consiste, básicamente, en
decir quién (rol) realiza qué (tarea), a partir de unas entradas (productos de trabajo)
obtener unas salidas (productos de trabajo).
SPEM 2 puede ser una importante ayuda para que las empresas que llevan a cabo
proyectos de software puedan enfrentar mejor los problemas relacionados con los
procesos.
Además de un metamodelo para ingeniería de procesos, SPEM 2 también es un
marco de trabajo conceptual que provee los conceptos necesarios para modelar,
documentar, presentar, publicar, gestionar, intercambiar y realizar métodos y
procesos software. Por ello, está destinado a ingenieros de procesos, jefes de
proyectos, gestores de proyectos y programas; que son responsables de mantener e
implementar procesos para sus organizaciones o para proyectos concretos.
28
La Figura 4 muestra un resumen del marco de trabajo general de SPEM, es decir,
de los escenarios más habituales de su uso.
Figura 4. Marco de trabajo general con SPEM 2 (Ruiz y Verdugo, 2008).
InDoCaS: Un proceso para la Ingeniería del dominio basado en calidad de software
El proceso denominado InDoCaS, es un proceso para la ingeniería de dominio
que puede ser utilizado en el enfoque de desarrollo de líneas de producto de software,
el cual puede ser aplicado para un dominio específico y los activos de software
producidos pueden ser reutilizados para generar un producto de una familia particular
del dominio.
El objetivo final es “obtener una arquitectura base para una familia del dominio,
las disciplinas principales de este proceso son el análisis y el diseño del dominio”
(Canelón, 2010). Se considera dominio como una familia de sistemas de software que
tienen características comunes.
Según (Canelón, 2010), La estructura del proceso está basada en lo siguiente:
29
RECLAMO (Requirement Clasification Model): Modelo de clasificación de
requisitos propuesto por Chirinos y otros. (Chirinos et al., 2004).
ISO/IEC 25010: El Estándar Internacional que describe un modelo bipartito
para la calidad del producto de software. (ISO/IEC, 2009).
Un proceso para el análisis del dominio para construir el modelo de calidad
propuesto por Losavio y otros. (Losavio et al., 2008).
FODA (Feature-Oriented Domain Analisys): análisis del dominio orientado a
rasgos, desarrollado por el SEI (Software Engineering Institute) para el modelo de
variabiliad. (Kang et al., 1990).
Un proceso general para el diseño arquitectónico del dominio propuesto por
Hofmeister y otros. (Hofmeister et al., 2007).
ADD (Attribute-Driven Design Method): Método de diseño dirigido por
atributos, usado para la formulación de escenarios de calidad. (Bass et al., 2003).
ATAM (Architecture Tradeoff Analysis Method): Método para elegir una
arquitectura para un sistema, utilizado en InDoCaS para la evaluación arquitectural.
Para la presentación de este proceso, se utiliza la notación SPEM 2, en la figura 5
se muestran las disciplinas del proceso InDoCaS, mencionadas anteriormente.
Figura 5. Disciplinas del proceso InDoCaS (Canelón, 2010).
30
A continuación nos centramos únicamente en la ingeniería de dominio ya que es la
disciplina que está relacionada con el presente trabajo de investigación, puesto que el
análisis del dominio proporciona una base arquitectural o un modelo de arquitectura
que es específica cuando se considera hacer en una familia del dominio.
Análisis del Dominio (InDoCaS)
La fase de análisis del dominio del proceso InDoCaS es fundamental para el
desarrollo de las líneas de producción de software, ya que allí se definen los aspectos
comunes a todas las familias del dominio y los aspectos particulares de cada una de
ellas. “Este subproceso permite la caracterización del dominio, identifica las
propiedades de calidad que deben ser garantizadas y define el modelo de calidad
asociado al mismo que brinda soporte al resto de las fases” (Canelón, 2010).
Se considera en general, que los requisitos no funcionales, expresados en términos
de requisitos de calidad, son cruciales para el diseño arquitectural específicamente
cuando las aplicaciones deben responder a situaciones críticas y a cambios en el
entorno.
Cabe destacar que InDoCaS, define su propia nomenclatura para describir las
actividades y artefactos que forman parte de las disciplinas del proceso (Análisis y
Diseño), que se muestran a continuación en las tablas 3 y 4:
InDoCaS ACTIVIDAD DESCRIPCIÓN
Nombre de la Actividad: Responsable: Objetivo: Nro. De Identificación Tipo documento generado Técnica(s) utilizada(s) Artefactos de Entrada Artefactos de Salida
Tabla 3. Esquema de Actividad InDoCaS
31
Como se observa en la tabla 3, en el caso de las actividades se utiliza: el Nombre
de la Actividad, Responsable, Objetivo, un número ordinal para el Nro. De
Identificación, que sirve para futuras referencias, tipo de documento generado (lista,
esquema, modelo, diagrama, tabla entre otros), la Técnica(s) Utilizada(s) para la
construcción de la actividad, los Artefactos de Entrada que se necesitan para la
actividad y los Artefactos de salida producidos en la actividad.
InDoCaS
ARTEFACTO DESCRIPCIÓN Nombre: Constructor: Objetivo: Nro. De Identificación ACTIVIDAD Nro. De Identificación ARTEFACTO Formato Asociado
Tabla 4. Esquema de Artefacto InDoCaS
Por su parte en la tabla 4, se muestran los elementos para definir un artefacto
InDoCaS a saber: Nombre del artefacto, Constructor responsable, un número ordinal
para el Nro. De Identificación ACTIVIDAD para asociarlo a la actividad en
referencia, un número ordinal para el Nro. De Identificación ARTEFACTO que hace
referencia al artefacto y el formato asociado al tipo de documento generado (lista,
esquema, modelo, diagrama entre otros).
A continuación se define el análisis del dominio, utilizando SPEM 2, figura 6, la
cual está integrada por seis actividades: Identificación de requisitos, Obtener modelo
de similitudes y variabilidad, Identificación de propiedades de calidad, Obtener
modelo de calidad asociado al dominio, Creación de escenarios de calidad del
dominio e Identificar estilos arquitecturales para el dominio.
32
Figura N° 6. Análisis del dominio InDoCaS (Canelón, 2010)
En la figura 7, se muestra el diagrama de actividades de la disciplina análisis del
dominio, en el cual se muestran las entradas y las salidas de cada una de las
actividades y la secuencia de ejecución, del mismo modo se indica qué técnicas
intervienen en cada una de las actividades.
33
Figura N° 7. Diagrama de actividades para el análisis del dominio InDoCaS
(Canelón, 2010)
En el siguiente cuadro, cuadro 5, se resumen las actividades de la disciplina
análisis del dominio, los artefactos de entrada a cada actividad y los artefactos que
produce la misma, así como la(s) técnica(s) asociada(s).
34
Nro. Actividad Artefactos de Entrada Artefactos de Salida Técnica
A_01 Identificación de Requisitos
- Modelo conceptual del dominio. - Reclamo.
- Lista de requisitos funcionales. - Lista de requisitos no funcionales.
RECLAMO
A_02 Obtener el modelo de similitudes y variabilidad
- Modelo conceptual del dominio. - Lista de requisitos funcionales. - Lista de requisitos no funcionales.
- Conjunto de características. - Conjunto minimal de requisitos funcionales y no funcionales. - Conjunto de puntos de variación
FODA
A_03 Identificación de propiedades de calidad
- Modelo conceptual del dominio. - Conjunto minimal de requisitos funcionales y no funcionales. - Losavio et al., 2008.
- Lista de requisitos funcionales y propiedades de calidad asociadas. - Lista de requisitos no funcionales y propiedades de calidad asociadas.
ISO/IEC 25010
A_04 Obtener modelo de calidad del dominio
- Lista de requisitos funcionales y propiedades de calidad asociadas. - Lista de requisitos no funcionales y propiedades de calidad asociadas.
- Modelo de calidad del dominio como.
ISO/IEC 25010
A_05 Creación de escenarios de calidad del dominio
- Modelo de calidad del dominio como. - Lista de requisitos funcionales y propiedades de calidad asociadas. - Lista de requisitos no funcionales y propiedades de calidad asociadas. - Conjunto minimal de requisitos funcionales y no funcionales.
- Escenarios de calidad. ADD
A_06 Identificar los estilos arquitecturales para el dominio
- Conjunto minimal de requisitos funcionales y no funcionales. - Modelo de calidad del dominio como.
- Estilos arquitecturales.
Experticia del
Arquitecto
Tabla 5. Lista de actividades para el análisis del dominio InDoCaS
35
Líneas de Producción de software (LPS)
Las líneas de producción de software se refieren a técnicas de ingeniería para crear
un portafolio de sistemas de software similares, a partir de un conjunto compartido de
activos de software, usando un medio común de producción" (Krueger, 2006).
Por otro lado, también se define como "un conjunto de sistemas de software que
comparten un conjunto común y gestionado de aspectos que satisfacen las
necesidades específicas de un segmento de mercado y que son desarrollados a partir
de un conjunto común de activos fundamentales de software de una manera
preestablecida", véase figura 8. (Clements y Northrop, 2002).
Figura N° 8 Modelo básico de una línea de productos de software (Clements y Northrop 2001).
Activos de Software: Colección de partes de software (requisitos, diseños,
componentes, casos de prueba, etc.) que se configuran y componen de una manera
prescrita para producir los productos de la línea
Decisiones de Productos: modelos de decisiones describen los aspectos variables
y opcionales de los productos de la línea. Cada producto de la línea es definido por un
conjunto de decisiones (decisiones del producto).
36
Proceso de producción: Establece los mecanismos o pasos para componer y
configurar productos a partir de los activos de entrada. Las decisiones del producto se
usan para determinar qué activos de entrada utilizar y cómo configurar los puntos de
variación de esos activos.
Productos de software: Conjunto de todos los productos que pueden o son
producidos por la línea de productos.
En resumen una línea de producción de software y la familia del dominio tiene un
conjunto de aspectos gestionados que son comunes a todos los miembros cuyos
productos son desarrollados a partir de un conjunto de activos de software
reutilizables. Entendiendo por familia de productos de software aquellas cuyos
aspectos comunes son compartidos por todos los productos y cuyos aspectos
variables establecen diferencias entre ellos.
El objetivo principal de una LPS es: reducir el tiempo, esfuerzo, costo y
complejidad de crear y mantener los productos de la línea mediante:
La capitalización de los aspectos comunes de la línea de productos.
La consolidación y reutilización de los activos de entrada a la línea.
El manejo de los aspectos variables de los productos de la línea a través de los
puntos de variación de los activos y los modelos de decisión.
Beneficios de la Línea de producción
Reducción en el tiempo promedio de creación y entrega de nuevos productos.
Reducción en el número promedio de defectos por producto.
Reducción en el esfuerzo promedio requerido para desarrollar y mantener los
productos.
Reducción en el costo promedio de producción de los productos.
37
Incremento en el número total de productos que pueden ser efectivamente
desplegados y mantenidos.
Reducción en el tiempo de entrega (time-to-market) y el tiempo de retorno
(time-to-revenue) de nuevos productos.
Mejoras en el valor competitivo del producto.
Márgenes mayores de ganancias.
Mejor calidad de los productos.
Mejoras en la reputación de la empresa.
Mayor escalabilidad del modelo de negocios en términos de productos y
mercados.
Mayor agilidad para expandir el negocio a nuevos mercados.
Reducción de riesgos en la entrega de productos.
Líneas de Producción Dinámicas de software (LPDS)
Una línea de producción dinámica de software es una línea de producción de
software cuyos productos son sistemas adaptables, es decir, que podría rápidamente
adaptarse cuando los cambios se producen en su entorno (Hallsteinsen, 2006).
La principal motivación para la línea de producción es simplificar el diseño y
mantenimiento de familias de sistemas, orientando las necesidades de las aplicaciones
con costos rentables y tiempos de desarrollo adecuados. Así mismo, el objetivo de las
líneas de producción dinámicas, es poder generar software adaptable y autónomo.
Las líneas de producción dinámicas de software se han aplicado con éxito en
dominios tales como casas inteligentes, dispositivos móviles o sistemas multimedia,
estas líneas de producción centran sus esfuerzos en generar productos altamente
adaptables o autónomos, es decir, generar productos configurables cuya autonomía
permita volver a su reconfiguración y así beneficiarse de una constante actualización.
38
El proceso de las líneas de producción dinámicas de software
El proceso de las líneas de producción dinámicas difiere en las actividades
adicionales que se utilizan para generar un producto configurable. La capacidad de
reconfiguración implica el uso de dos actividades para su control: Analizador y Re-
configurador (Cetina et al, 2008).
Analizador: Conoce toda la estructura de un Producto Configurable para
tomar la decisión sobre que características deben ser activadas y desactivadas; posee
un artefacto decision maker, que se encarga de capturar toda la información que
sugiere un cambio en su entorno, provenientes de censores externos de información o
incluso de un usuario
Re-configurador: Es responsable de la ejecución de la decisiones tomadas en
analizador, utilizando el estándar de las líneas de producción de software en enlace de
tiempo de ejecución.
Por lo tanto, un Producto Configurable puede ser considerado como una
extensión de los productos habitulaes de líneas de producción de software, donde no
hay características obligatorias, pero deben estar presentes obligatoriamente decision
maker encargado de captar la información que genera cambios en el entorno, re-
configurador y el resto de características enlazadas en tiempo de ejecución. Como
consecuencia de ello una nueva característica puede ser añadida a un producto
existente o incluso una característica existente puede ser actualizada en tiempo de
ejecución.
En la figura 9, se observa la interacción de estos elementos, desde los triggers de
adaptación los cuales alertan al sistema de cambios en el ambiente o condiciones del
producto o peticiones del usuario que desencadenan un proceso de reconfiguración o
adaptación del producto configurable al contexto.
39
.
Figura N° 9. Proceso de línea de producción dinámica de software (Canelón et al, 2009c)
Según señala (Cetina et al., 2008) existen dos tipos de líneas de producción
dinámicas de software:
Conectadas: Se mantienen en contacto con los productos con el fin de enviar
actualizaciones de ellos. Estas actualizaciones del producto permiten hacer frente a
los cambios de contexto. La figura 10 muestra los pasos para enviar una actualización
desde la línea dinámica al producto configurable:
1. El producto configurable detecta un cambio relevante que inicia el proceso de
adaptación, tanto los cambios en el entorno, como los cambios en el dispositivo e
incluso los cambios en el usuario pueden disparar un proceso de adaptación.
2. El producto configurable envía la información a la línea de prodiccióm,
opcionalmente el mismo producto puede pre-procesar la información para luego
enviarla.
3. La línea de producción incorpora la información adquirida a los requisitos del
producto y luego calcula una nueva variante del mismo.
40
a. Si no hay variantes que satisfagan el requisito, la línea notifica al producto que
el proceso de adaptación no puede llevarse a cabo.
4. La línea de producción genera la actualización para el producto, la cual puede
ser toda una variante calculada o la diferencia entre la anterior y la nueva.
5. La línea de producción envía la actualización al producto configurable.
6. El producto configurable se actualiza a sí mismo.
Figura N° 10. Línea de producción dinámica de software Conectada.
(Canelón et al, 2009c)
Desconectadas: Producen Productos Configurables, que puede reconfigurarse por
sí mismo, para hacer frente a los cambios contextuales. En comparación con las líneas
conectadas, los Productos Configurables se reconfigura por sí mismo sin ningún
contacto con las líneas de producción dinámicas de software, ya que se
complementan con el conocimiento de variabilidad y componentes inactivos con el
fin de realizar la reconfiguración.
Por su parte, en la figura 11 muestra cómo se ejecuta la reconfiguración con un
tipo de línea de producción dinámica desconectada:
41
1. El producto configurable detecta un cambio relevante que inicia el proceso de
adaptación, tanto los cambios en el entorno, como los cambios en el dispositivo e
incluso los cambios en el usuario pueden disparar un proceso de adaptación.
2. El producto configurable calcula una nueva configuración para tratar el
cambio detectado.
a. Si no hay configuración que satisfaga el requisito, el proceso de
adaptación falla.
3. El mismo producto configurable aplica la configuración calculada. Las
operaciones de reconfiguración implican, primero, iniciar y/o detener componentes y
segundo, establecer las conexiones entre ellos.
Figura N° 11. Línea de producción dinámica de software Desconectada.
(Canelón et al, 2009c)
42
Gestión de Variabilidad
La variabilidad es particularmente relevante en el campo de las líneas de
productos software. La variabilidad entre productos de una línea de productos puede
ser expresada en términos de características (Kang et al., 1998). Una característica es
una unidad lógica de comportamiento que es especificada por un conjunto de
requisitos funcionales o de calidad (Bosch, 2000).
Uno de los elementos clave para una línea de producción de software es la
representación y gestión de la variabilidad. La variabilidad ha sido descrita como la
habilidad de un sistema software o artefacto para ser cambiado, personalizado o
configurado para usarse en un contexto particular.
La ingeniería de la línea de producción de software se pretende soportar un grupo
de productos. Esos productos pueden atender diferentes clientes individuales o
diferentes segmentos de mercado. La variabilidad es un concepto clave en cualquiera
de esas aproximaciones.
En lugar de entender cada uno de los sistemas individuales, se observa a la línea
de producto como un todo y la variación entre los sistemas individuales. Esta
variabilidad debe ser definida, representada, explotada e implementada, a través de la
del proceso de desarrollo de la línea.
Cuando se gestiona la variabilidad en una línea, se necesitan distinguir tres tipos
de características (feature) principales:
Comunes: una característica (funcional o no funcional) puede ser común a todos
los productos en la línea de producto. Esta es implementada como parte de la
plataforma.
Variables: una característica puede ser común a algunos productos, pero no a
todos. Entonces debe ser explícitamente modelada como una posible variabilidad y
43
debe ser implementada en una forma que permita tenerla en solamente los productos
seleccionados.
Específicos del producto: una característica puede ser parte de solamente un
producto. Tales especialidades son escasamente requeridas por el mercado, pero si
por los intereses de los clientes individuales.
Mientras las características comunes y variables se manejan esencialmente en la
ingeniería del dominio, las características específicas del producto son manejadas
exclusivamente en la ingeniería de la aplicación.
La variabilidad puede describirse mediante una notación gráfica que conforma un
diagrama de variabilidad. La notación gráfica usada en (Pohl et al., 2005) y en
(Bachmann et al., 2003) consiste en los siguientes elementos:
Punto de variabilidad: describe donde existen diferencias en los productos
finales. El descubrimiento de los puntos de variabilidad se realiza durante el proceso
del diseño de la arquitectura como opciones para implementar las variaciones
identificadas durante los procesos de requisitos o variaciones normales durante el
diseño.
Variante: las diferentes posibilidades que existen para instanciar un punto de
variación son llamadas variantes. Un punto de variabilidad está definido a través de
sus variantes. La identificación de la variabilidad es una actividad continua, porque
un producto puede variar de muchas maneras, al identificar las variantes en cualquier
tiempo durante el proceso de desarrollo. Algunas variantes son identificadas durante
la elicitación de los requisitos de la línea de productos, otras, durante el diseño de la
arquitectura, y otras durante la implementación.
Dependencias de variabilidad: son usadas para cualificar las diferentes
elecciones (variantes) que son posibles en un punto de variación. La notación incluye
una cardinalidad que determina cuantas variantes pueden ser seleccionadas
44
simultáneamente. Las dependencias de variabilidad pueden ser tres: alternativa
<<alternative>>, opcional <<optional>> y obligada <<mandatory>>.
Dependencias de restricciones: describen las dependencias entre ciertas variantes
seleccionadas. Existen dos formas de restricciones: o Requiere <<requires>>.- la
selección de una variante puede requerir la selección de otra variantes (quizás en un
punto de variabilidad diferente) o Exluye <<excludes>>.- la selección de una variante
puede prohibir la selección de otra variante (quizás en un punto de variabilidad
diferente)
Un modelo único de variabilidad y funcionalidad por sí mismo representa con
dificultad todo el significado de la variabilidad en la ingeniería de la LPS, ya que
dicho modelo sería muy confuso, al incluir todas las restricciones y plasmar la
funcionalidad de los sistemas. Esto ocasiona que no exista una forma estándar para
representar la variabilidad.
FODA: Análisis del dominio Orientado a Rasgos Algunos métodos, tales como FODA (análisis del dominio Orientado-Rasgo). El
método de análisis FODA desarrollado por el (SEICMU, 1990) es uno de los
principales métodos de partida en el terreno del desarrollo de Líneas de Producción.
Examinando los diferentes sistemas de software relacionados, el análisis de dominio
permite obtener una descripción genérica de los requisitos y una forma de
implementarlos. El resultado de aplicar FODA es una familia de productos más que
un producto individual, produciendo un modelo del dominio con la flexibilidad
suficiente para reflejar las diferentes posibilidades que existan, y una arquitectura
estándar para desarrollar componentes software. Las fuentes del análisis del dominio
son, en FODA, la documentación publicada sobre el dominio, los estándares, las
aplicaciones existentes y los expertos. FODA organiza las capacidades (lo que
observa el usuario final) de la familia de productos constituyendo jerarquías en forma
de árbol. Las capacidades o características comunes se colocan en los nodos raíz del
45
árbol. Cada variante sobre estas características comunes implica una rama en el árbol.
La ventaja de esta técnica es que se recogen en un único modelo todas las posibles
variaciones que hay en la familia de productos y que se identifican claramente. Las
capacidades pueden ser obligatorias, opcionales o alternativas (ver figura 6).
Figura N° 12. Ejemplo del modelo de características (Canelón et al, 2007)
Así mismo, (Kuu et al., 2000) ha profundizando en los resultados de FODA y
propone un modelo de organización de requisitos para líneas de producción en forma
jerárquica que contenga todos los requisitos de todos los miembros de la familia de
productos. En la raíz del árbol estarían los requisitos básicos y comunes a todos los
productos, incluyendo los requisitos no estrictamente funcionales que afectan a la
globalidad de los sistemas (calidad, rendimiento, entre otros). Para confeccionar la
jerarquía de requisitos, distingue entre objetivos de diseño y decisiones de diseño.
Los objetivos de diseño son cualidades que el sistema que se va a implementar debe
de satisfacer, con independencia de que sean muy generales o más concretas. Las
decisiones de diseño reflejan las soluciones que se han dado para implementar el
dominio, en otras palabras, la arquitectura de la línea de producción.
46
Aplicaciones Móviles
Las aplicaciones móviles difieren de las aplicaciones de desktop estándar, en el
sentido de que estas imponen varios desafíos para el desarrollo de software. Deben
ser ejecutadas en dispositivos heterogéneos, con recursos limitados y conexiones
transitorias. Los dispositivos móviles, son usados en escenarios complejos como:
exploración visual, monitoreo ambiental, manejo de tráfico en vías libres, operaciones
militares estratégicas, situaciones de daños y desastres naturales.
Este conjunto de desafíos, al cual se le denomina Prism (Programming In the
Small and Many), hace referencia al desarrollo de software altamente distribuido,
dinámico, móvil, generalmente inalámbrico y con procesamientos heterogéneos
sobre un gran número de plataformas restringidas por recursos escasos (Medvidovic,
2003). Las aplicaciones móviles sensibles al contexto, en particular, deben adaptarse
tanto a las capacidades de acceso en diversos dispositivos como a diferentes
contextos, conservando consistencia y utilidad.
Se define al contexto como cualquier información que puede ser usada para
caracterizar la situación de entidades (usuario, lugar u objeto) que son consideradas
relevantes en la interacción entre un usuario y una aplicación, incluyendo al usuario y
a la aplicación (Dey et al., 2001). La información está clasificada en tres ambientes:
computacional (procesadores, dispositivos de entrada y salida, capacidad de red,
recursos de interacción, conectividad), del usuario (localización, preferencias/perfil
del usuario, situación social), físico (iluminación, nivel de ruido). Por lo tanto una
aplicación adaptable o adaptativa se reconfigura por si misma dinámicamente de
acuerdo a su contexto de uso.
Para desarrollar este tipo de aplicaciones es preciso definir los requisitos, en este
caso requisitos funcionales; como por ejemplo, la facilidad de compartir datos en un
ambiente colaborativo, que implica la disponibilidad de dichos datos en un ambiente
con conexiones no siempre disponibles, ni seguras; por lo tanto para garantizar la
47
disponibilidad de los datos y de las conexiones implica considerar la disponibilidad
como propiedad de calidad asociada al requisito funcional.
Un requisito no funcional es por ejemplo, la minimización del recurso respecto al
consumo de la batería, el cual es imperativo en el dominio de las aplicaciones
móviles, en particular la propiedad de calidad eficiencia está asociada a este requisito.
La movilidad se refiere a tener los datos, los dispositivos y las aplicaciones en
cualquier momento y lugar. El desarrollo de aplicaciones móviles conlleva una
variedad de consideraciones de acuerdo al propósito y escenario para el que van a ser
utilizadas. Entre estas consideraciones se pueden mencionar: el tipo de aplicación, los
sistemas operativos y las plataformas disponibles, las características de los
dispositivos (pantalla, memoria, procesador, audio, batería, navegación, impresión
entre otros), limitaciones en la conectividad incluso en el lenguaje de los
navegadores.
Calidad de Software: Estándar ISO 25010
En la actualidad los sistemas basados en computadoras son fundamentales para
casi todos los ámbitos de la vida de las personas y su correcto funcionamiento es
La calidad del software se define como el conjunto total de características de un
sistema que le confieren la capacidad de satisfacer las necesidades establecidas y las
necesidades implícitas de los usuarios, desde donde se extraen una serie de
parámetros básicos que deben tomarse en cuenta, al desarrollar software de calidad.
Si se desea construir productos y servicios de buena calidad para el consumidor
será necesario especificar: qué calidad de producto o servicio se requiere (calidad que
desea el cliente), una planificación que incorpore calidad en el diseño y métodos de
producción que permitan calidad en el desarrollo.
A finales de la década del 80 e inicios del 90 se hizo énfasis en los conceptos de
calidad de producto y satisfacción del usuario desde diversos enfoques,
48
particularmente a la valoración y certificación de la calidad de procesos de
producción de software; como lo son CMM (Capability Maturity Model) modelo de
evaluación de procesos desarrollado por la Universidad Carneige-Mellon, SPICE
(Software Process Improvement and Capability Determination) modelo para la
mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y
productos de software, SQUID (Software Quality in the Development Process),
modelo que apoya el control, planificación y evaluación de la calidad de software
entre otros; sin embargo, también es conocido que los modelos de calidad ya eran
reconocidos en la comunidad científica al final de la década del 70 como los descritos
por McCall y Boehm.
Por su parte, la Organización Internacional para la Estandarización ISO publicó el
estándar ISO-IEC 9126-1, en el año 2001. De acuerdo a las debilidades encontradas
en este estándar, se hizo una revisión y se generó el ISO/IEC 25010 publicado en
octubre del 2009. El mismo, es parte de la serie de estándares SQuaRE y fue
preparado por el Comité Técnico Conjunto ISO/IEC JTC 1, Subcomité SC 7 de
Ingeniería de Software y Sistemas
El Estándar Internacional ISO/IEC 25010 describe un modelo bipartito para la
calidad del producto de software el cual se presenta en la figura 13:
Figura N° 13. Enfoques de calidad (ISO/IEC, 2001)
49
Calidad interna y externa: la Calidad Interna, proporciona una visión de la “caja
blanca” del software y trata las características del producto de software que están
disponibles durante el desarrollo. Está relacionada con las características estáticas del
software y tiene un impacto en la calidad externa del software, que tiene a su vez un
impacto en la calidad funcional. Así mismo, la Calidad externa, proporciona una
visión de la “caja negra” del software y trata las características relacionadas con la
ejecución del software.
La primera parte del modelo especifica ocho características para la calidad interna
y externa como se muestra en la figura 14, que se subdividen más a fondo en sub-
características, que se manifiestan externamente cuando el software se utiliza como
parte de un sistema informático, y es resultado de las cualidades internas del software.
Este estándar internacional no elabora el modelo para la calidad interna y externa de
bajo del nivel de sub-características.
Figura N° 14. Características y sub-características de calidad interna y externa
(ISO/IEC, 2009)
Calidad en el uso: Es una medida de la calidad del sistema en su ambiente
operacional para usuarios específicos que realizan tareas específicas. La calidad
funcional del software es la capacidad de permitir la misma en su ambiente
operacional para ejecutar tareas específicas que realizan los usuarios.
50
La segunda parte del modelo especifica cinco características de la calidad en uso,
como se muestra en la figura 15, que es el efecto combinado para el usuario de las
ocho características de la calidad del producto de software. Las características
definidas son aplicables a todo tipo de software.
Un modelo de la calidad se puede utilizar para apoyar la especificación y la
evaluación del software de diversas perspectivas por aquellas personas asociadas al
proceso de adquisición, requisitos, desarrollo, uso, evaluación, soporte,
mantenimiento, garantía de calidad y auditoria del software. Puede, por ejemplo, ser
utilizado por los desarrolladores, adquirentes, personal evaluador de la garantía de
calidad y evaluadores independientes, particularmente aquellos responsables de
especificar y de evaluar la calidad del producto de software
Figura N° 15. Características y sub-características de calidad en uso (ISO/IEC,
2009)
Operacionalización de las Variables
De acuerdo con la literatura se entiende por variable los referentes axiológicos a
partir de los cuales se procede a valorar una realidad y por indicadores los fenómenos
medibles, seleccionados convenientemente en términos del levantamiento de
51
información. Mientras que las dimensiones representan las áreas de conocimiento que
integran la variable y de la cual se desprenden los indicadores
A continuación, se definen las variables del estudio de manera conceptual y
operacional:
Variables conceptuales
Modelo Arquitectural para aplicaciones móviles: se define como un conjunto
de patrones y abstracciones coherentes que proporcionan el marco de referencia
necesario para guiar la construcción de aplicaciones móviles.
Línea de producción dinámica de software: es una técnica de ingeniería para
crear aplicaciones de software similares a partir de un conjunto compartido de activos
de software, usando un medio común de producción.
Variables Operacionales
Para efectos de la operacionalización de las variables conceptuales se procedió de
la siguiente manera:
La variable “Modelo Arquitectural para aplicaciones móviles” se operacionalizó
considerando dos dimensiones, la dimensión Arquitectura de Software y la dimensión
Aplicaciones Móviles. La dimensión arquitectura de software está conformada por los
estilos arquitecturales, importancia y calidad de software. Por su parte la dimensión
aplicaciones móviles está compuesta por caracterización y desarrollo.
Consecutivamente, la variable “Línea de producción dinámica de software” se
operacionalizó considerando dos dimensiones: la dimensión desarrollo de software y
la dimensión Ingeniería del dominio. La primera está formada por: Procesos de
desarrollo, Familia de productos y Reutilización de software. Mientras que la
segunda, está constituida por: Análisis del dominio, utilizando el proceso InDoCaS,
Modelos de Variabilidad y Activos de software
52
En la tabla Nº 6 se presenta el resumen de la Operacionalización de las variables
en estudio.
Tabla 6: Operaciónalización de las variables a estudiar Objetivo General Variable Dimensiones Indicadores
Proponer un modelo arquitectural para aplicaciones móviles usando el enfoque de líneas de producción dinámica de software.
Modelo Arquitectural para aplicación móvil
Arquitectura de Software
Estilos arquitecturales Importancia Calidad de Software
Aplicaciones Móviles
Caracterización Desarrollo de aplicaciones
Línea de producción dinámica de software
Desarrollo de Software
Procesos de desarrollo Familia de productos Reutilización de software
Ingeniería del dominio
Análisis del dominio (InDoCaS) Modelos de Variabilidad Activos de software
Fuente: Autora de la investigación
53
CAPÍTULO III
MARCO METODOLÓGICO
Naturaleza del estudio
El presente estudio se enmarca en la modalidad de proyecto factible, la cual es
definido por la Universidad Pedagógica Experimental Libertador (UPEL, 2006),
como sigue: “consiste en la investigación, elaboración y desarrollo de una propuesta
de un modelo operativo viable para solucionar un problema, requisitos o necesidades
de organizaciones o grupos sociales; puede referirse a la formulación de políticas,
programas, tecnología, métodos o proceso”.
Este proyecto factible está apoyado en una monográfica documental. Según el
Manual para la Presentación de Trabajo de Grado de la Universidad Centroccidental
Lisandro Alvarado (UCLA, 2002) se entiende por investigación monográfica
documental: “estudio de problemas de tipo teórico - práctico, con el propósito de
ampliar y profundizar el conocimiento de su naturaleza. Se basa principalmente en
fuentes bibliográficas, documentales y estudios comparados de análisis de problemas
que ocurren en la práctica”.
Fases del Estudio
Los proyectos factibles se desarrollan en tres fases, señala (UPEL, 2006) con
el fin de cumplir con los requisitos involucrados en este tipo de proyectos.
54
Fase I: Diagnóstica En esta fase se espera conseguir los elementos que describen las necesidades
reales del proyecto de investigación.
Población y Muestra Según la Universidad Santa María (Santa María, 2005), por “población se
entiende el conjunto de todas las unidades (personas, cosas) que concuerdan con una
serie de especificaciones”. En este orden de ideas, la población estará representada
por todas las aplicaciones móviles que se adaptan al contexto, o que son sensibles al
contexto.
Por su parte, la muestra estará representada por el dominio de aplicaciones para el
aprendizaje de idiomas asistido por móviles (MALL), que se presenta como un
subconjunto de aplicaciones que se adaptan al contexto del usuario.
Procedimiento
En cuanto al procedimiento de la investigación, se comenzó haciendo una revisión
bibliográfica para la consecución de los objetivos.
En primer lugar, se estableció seguir proceso InDoCaS para realizar un análisis
del dominio con calidad de software, puesto que la finalidad de este proceso es
precisamente obtener un modelo de arquitectural para un dominio en específico con
características de calidad.
Seguidamente, se analizó el enfoque de desarrollo de las líneas de producción de
dinámicas de software, para aplicaciones móviles, a través de la caracterización y
clasificación de las mismas para incorporar las actividades necesarias al proceso
InDoCaS y llevar a feliz término la construcción del modelo arquitectural.
Finalmente, se ejecutó el proceso para el desarrollo de las actividades y artefactos
en el dominio de aprendizaje de idiomas asistido por móviles.
55
Técnicas e Instrumentos de Recolección de Datos
Las técnicas de recolección de información según (Balestrini, 2005) “son los
métodos usados para extraer resultados que le den forma a la investigación
respondiendo de manera certera a los objetivos planteados”. En función de los
objetivos definidos en el presente estudio se propone un modelo arquitectural para
aplicaciones móviles usando un enfoque de línea de producción dinámica de
software,
Para cumplir con ello, se aplican las técnicas de revisión bibliográfica que
permitan abordar y desarrollar los requisitos técnicos de esta investigación, así como
consultas en Internet, técnicas de resumen, subrayado, presentación de cuadros,
ilustraciones, diagramas, que permitirán de forma teórica apoyar la investigación.
Fase de Factibilidad
Consiste en determinar la posibilidad de diseñar la propuesta, en función de los
siguientes criterios:
Factibilidad Técnica
Desde el punto de vista tecnológico, el desarrollo de un modelo arquitectural,
requiere de recursos de hardware y software.
Respecto al software es perfectamente factible el uso de "licencias libres"
propuestas por el Gobierno Nacional Venezolano en el año 2001. Se sugiere
entonces, un Sistema Operativo GNU/GPL como por ejemplo Ubuntu 2009 o
superior, licencia libre. Aunque podría instalarse en Sistemas Operativos de carácter
propietario por ser un modelo transportable a cualquier plataforma (WINDOWS,
SOLARIS, entre otros).
El lenguaje de modelado a emplear para diseñar la arquitectura es ACME
utilizando un Plugin para Eclipse Galileos. Este lenguaje tiene su ventaja, porque es
56
multiplataforma, es decir, se puede desarrollar en el sistema operativo Linux e
implantarse en el sistema operativo Windows, Mac, entre otros.
Por otro lado, los costos computacionales de hardware son bajos debido a las
características técnicas de sistema operativo y del entorno de desarrollo que soporta el
lenguaje de diseño arquitectural SPEM 2.
Factibilidad Económica
En lo que respecta a la adquisición de licencias de software para el desarrollo del
proyecto, se observa la reducción de dicho costo al utilizar las tecnologías libres
(open source) presentes en el mercado. De este modo, es factible económicamente
desarrollar el modelo arquitectural para aplicaciones móviles.
Factibilidad Social
En lo referente a la factibilidad social, el uso de modelos arquitecturales en el
desarrollo de software, permiten el crecimiento de la sociedad respecto a los
conocimientos de computación, tecnología y desarrollo de software
Tomando en cuenta el punto anterior, si se desea implantar el modelo
arquitectural, habría que agregar el entrenamiento y elaboración de manuales del
usuario para la utilización de la arquitectura en una plataforma de desarrollo.
De acuerdo a lo expresado anteriormente se puede concluir entonces que el
proyecto tiene garantizado su desarrollo, ya que es factible de manera técnica,
económica y social.
57
CAPÍTULO IV
PROPUESTA DEL ESTUDIO
Justificación
La adaptación en una línea de producción de software está relacionada con el
rediseño y reconfiguración de la arquitectura y componentes de la aplicación en
tiempo de diseño donde se cambian requisitos funcionales y no funcionales. Por su
parte, la adaptación en una línea de producción dinámica de software sucede en
tiempo de ejecución cuando los recursos y las condiciones del contexto cambian. Para
dar un ejemplo, las aplicaciones pueden reaccionar dinámicamente a las fluctuaciones
de la conexión de red, a la capacidad de la batería, a nuevos dispositivos o servicios
que emergen o simplemente a los cambios en las preferencias del usuario.
Bajo esta premisa, el modelo arquitectural, basado en el enfoque de líneas de
producción dinámicas de software, propuesto en la presente investigación representa
una arquitectura para un dominio de aplicaciones móviles en particular. Los
principios de la arquitectura de software son importantes para guiar los procesos de
desarrollo, incluso para asegurar que los productos de software incluyan
características de calidad como: Escalabilidad (capacidad de las aplicaciones para
cambiar su tamaño o configuración para adaptarse a las circunstancias cambiantes),
Heterogeneidad (variedad de dispositivos, sistemas operativos, aplicaciones e
interfaces de usuario) e Integridad (privacidad y seguridad que brindan las
aplicaciones) por mencionar algunas propiedades de calidad que se pueden asegurar
en etapas tempranas del desarrollo de aplicaciones.
58
Asimismo, representa un aporte significativo en la línea de investigación de
Ciencias de la Computación mención Ingeniería de Software puesto que podría
incentivar nuevas investigaciones en esta área, facilitando el aprendizaje acerca de
arquitectura de software, guías para la construcción de software, ingeniería de
dominio, líneas de producción dinámicas de software, reutilización de componentes
en familias de productos de software e inclusive se podría utilizar este modelo como
marco de referencia e introducirle las adaptaciones necesarias para el logro de otros
objetivos en otras áreas y así disfrutar las ventajas que ofrece el enfoque de líneas de
producción como reducción de costos, esfuerzos y tiempos de desarrollo entre otros.
Objetivos
Objetivo General
Proponer un modelo arquitectural para aplicaciones móviles basado en líneas de
producción dinámica de software con un enfoque de calidad.
Objetivos Específicos
Analizar y diseñar el enfoque de líneas de producción dinámica de software, para
el desarrollo de aplicaciones móviles.
Diseñar las actividades y artefactos en la disciplina análisis del dominio del
proceso ingeniería de dominio InDoCaS que conducen a la creación del modelo
arquitectural.
Ejecutar el proceso para el desarrollo de las actividades y artefactos en el dominio
de aprendizaje de idiomas asistido por móviles (MALL).
59
Descripción de la Propuesta
En esta investigación se propone un modelo arquitectural para apoyar el diseño de
aplicaciones que se adaptan dinámicamente. Se aplican los conceptos de: procesos de
desarrollo, reutilización de activos de software, ingeniería de dominio, modelos de
variabilidad y líneas de producción dinámicas de software, para definir la forma en
que dichas aplicaciones se adaptan en tiempo de ejecución a los cambios del entorno.
En particular, la gestión de variabilidad se lleva a cabo en dos dimensiones: en
primer lugar se hace variar la disciplina de análisis del dominio, del proceso de
desarrollo y en segundo la línea de producción dinámica de software.
La variabilidad en el proceso se expresa en la disciplina de análisis del dominio,
del proceso InDoCaS, modelado bajo el estándar SPEM 2 donde se agrega un punto
de variación permitiendo que el proceso se transforme y se ajuste a las líneas de
producción dinámicas o no.
Por su parte, la variabilidad en la línea de producción se manifiesta usando el
modelo de características (features model) para las líneas de producción habituales y
el modelo de variabilidad ortogonal para las líneas dinámicas de software
La propuesta consiste entonces, en la especialización del proceso InDoCaS en la
disciplina de análisis del dominio, específicamente en la actividad “Obtener modelo
de similitudes y variabilidad”, a la cual se le agrega una actividad opcional
denominada “Generar modelos dinámicos” y los artefactos necesarios para trabajar
con las líneas de producción dinámica de software, como: Requisitos de referencia,
Conjunto de puntos de variación dinámicos, Conjunto de características dinámicas y
el informe de decisión que serán detallados en la siguiente sección.
60
Estructura del modelo propuesto
El modelo propuesto en este trabajo de investigación, está basado en las
actividades definidas por el proceso InDoCaS (Canelón, 2010), en su disciplina
análisis del dominio la cual se especializa al incorporar un punto de variación a la
actividad “Obtener modelo de similitudes y variabilidad” y agregar la actividad
variante “Generar modelos dinámicos” asociando además los artefactos: Requisitos
de referencia, Conjunto de puntos de variación dinámicos, Conjunto de
características dinámicas y el informe de decisión.
Puesto que cada organización tiene sus propias características, incluso cada
proyecto en particular las tiene, es necesario adaptar los modelos de procesos y
metodologías antes de aplicarlos, incorporando modificaciones para que el proceso se
ajuste mejor a los requisitos de software.
La forma de hacer variar los procesos es a través de la variación de sus métodos,
es decir, variando el método, varía el proceso. Por esta razón, se utiliza en el enfoque
de líneas de producción, para también gestionar la variabilidad en el proceso
InDoCaS, con esto se pueden establecer familias de procesos y crear además Líneas
de Procesos software, partiendo del buen uso de las similitudes entre procesos y
explotando las diferencias entre ellos.
El estándar SPEM 2, proporciona una notación particular para mostrar la
variabilidad en los procesos. En la figura 16 se muestra dicha notación.
Figura N° 16. Notación de Variabilidad añadidos a SPEM 2.
61
En la figura 16, se listan las actividades para el análisis del dominio del proceso
InDoCaS utilizando el estándar SPEM 2 y resaltando las modificaciones
mencionadas anteriormente.
Figura N° 17. Lista de actividades para la disciplina de análisis del dominio InDoCaS especializada.
62
Con la adición de esta actividad y sus artefactos se puede asegurar la construcción
de un modelo arquitectural para aplicaciones que se adaptan dinámicamente al
entorno en tiempo de ejecución y de esta manera, ajustarnos al enfoque de líneas de
producción dinámica de software. En la figura 18, se muestra el diagrama de
actividades de la disciplina análisis del dominio especializada, incorporando la
actividad y sus artefactos resaltados en amarillo.
Figura N° 18. Diagrama de actividades para la disciplina análisis del dominio
InDoCaS especializada.
63
Definición de la actividad y sus artefactos
A continuación, se define la actividad adicional y cada uno de los artefactos
involucrados en el proceso, así mismo las actividades y artefactos se ajustan al
estándar definido por InDoCaS para facilitar su presentación y seguimiento.
Actividad A_02a: Generar modelos dinámicos
Como se ha mencionado anteriormente, las líneas de producción dinámica de
software son un caso particular de las líneas de producción habituales, cuya finalidad
es producir sistemas que se adapten en tiempo de ejecución, en respuesta a los
cambios del ambiente, a través de ciertos procesos de adaptación ya sea por
reconfiguración autónoma del producto o por actualización de la línea.
Para tal propósito se hace variar la actividad “Obtener modelo de similitudes y
variabilidad” con el objetivo de conocer si dentro del artefacto “conjunto minimal de
requisitos” se encuentran propiedades de adaptación a los cambios de contexto o
flexibilidad ante los cambios de usuario, es decir, propiedades que desencadenen en
un proceso de reconfiguración del producto, comparándolo con el artefacto
“requisitos de referencia”. En caso de que existan tales requisitos, se ejecuta la
actividad “Generar modelos dinámicos” que se ha identificado con el número
A_02a, para reflejar la variación de la actividad A_02 de InDoCaS y no interferir en
su secuencia de numeración.
En primer lugar, se construye el artefacto “conjunto de puntos de variación
dinámico” a partir del “modelo de características” y del “conjunto de puntos de
variación” al cual se le adicionan las variantes y las relaciones de dependencia
correspondientes entre puntos de variación y variantes.
Seguidamente se elabora el “conjunto de características dinámicas”, usando un
meta-modelo de variabilidad ortogonal, propuesto por (Helleboogh et al, 2009), para
al manejo de la variabilidad en las líneas dinámicas de producción.
64
Finalmente se elabora el “informe de decisión” compuesto por la justificación
sobre la línea de producción dinámica de software, las estrategias de adaptación, las
estrategias de reconfiguración y la sobrecarga del producto configurable.
En la tabla 7, que se muestra a continuación, se resume la definición de la
actividad adicional.
Tabla 7: Actividad A_02a: Generar modelos dinámicos. InDoCaS ACTIVIDAD DESCRIPCIÓN Nombre de la Actividad: Generar modelos dinámicos Responsable: Analista de Requisitos
Objetivo: Identificar el tipo de línea de producción y generar los modelos dinámicos correspondientes
Nro. Identificación: A_02a Tipo de documento generado: Modelos
Técnica(s) utilizada(s): Usar el conjunto de puntos de variación y adicionar variantes para luego crear el meta-modelo de variabilidad ortogonal
Artefacto(s) de entrada: Conjunto de puntos de variación, Conjunto de características.
Artefacto(s) de salida: Conjunto de puntos de variación dinámicos, Conjunto de características dinámicas, Informe de decisión.
Asimismo, se presenta en tablas con formato de InDoCaS, los artefactos
generados por la actividad adicional. Es propio señalar que se han identificado los
artefactos adicionales con los números 4.1, 4.2 y 4.3, para reflejar que son productos
opcionales del proceso InDoCaS y no interferir en la secuencia de numeración de
artefactos que se presenta originalmente
Artefacto 4.1: Conjunto de puntos de variación dinámicos
Este artefacto es una expansión del artefacto Nro. 4 de InDoCaS llamado
“conjunto de puntos de variación” al cual se le anexan las variantes, que serán de
utilidad en la construcción del modelo de variabilidad extendido para características
dinámicas. En la tabla 8 se presenta la definición de dicho artefacto.
65
Tabla 8: Artefacto 4.1: Conjunto de puntos de variación dinámicos. InDoCaS ARTEFACTO DESCRIPCIÓN Nombre: Conjunto de puntos de variación dinámicos Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: A_02ª Nro. Identificación ARTEFACTO: 4.1 Formato Asociado:
Característica Punto de Variación Variante
Artefacto 4.2: Conjunto de Características Dinámicas
Los modelos de características dinámicos son una extensión de los actuales
modelos de características (feature) y proveen una notación especializada para
especificar el dinamismo de las líneas de producción y las limitaciones o restricciones
en tiempo de ejecución. Según (Dinkelaker, 2010) las restricciones dinámicas
permiten expresar:
i) Que la activación de una característica dinámica requiere que otra de las
características dinámicas se activa también. Esta restricción se denomina
<<implies>> en los modelos dinámicos y permite a los diseñadores modelar los
requisitos sobre la lógica de reconfiguración de una línea dinámica de software.
ii) Dos características no deben activarse simultáneamente, al restringirlas con la
restricción <<exclude>>. Esta limitación permite restringir el funcionamiento del
sistema de activación de ambas funciones, si un diseñador considera que su
combinación es perjudicial.
iii) La relación <<preceed>>, declara que se permite la interacción entre
características y establece una estrategia de resolución, que concede prioridad de una
función sobre otra. La precedencia no es exclusiva, por lo tanto todas las
66
características se activan, pero en los puntos de variación la precedencia define un
orden en el que las características se llevan a cabo.
En la figura 19, se muestra la representación visual de un modelo de
características dinámico y la posible relación (constraints). Las características
dinámicas se representan con líneas de borde punteado. Asimismo restricciones
dinámicas se modelan mediante flechas discontinuas.
Figura N° 19. Notación para características dinámicas.
Cabe destacar que, es factible las relaciones entre las características y estáticas,
pudiéndose usar las mismas relaciones (constraints) entre ellas.
En la tabla 9, se presenta el artefacto.
Tabla 9: Artefacto 4.2: Conjunto de características dinámicas. InDoCaS ARTEFACTO DESCRIPCIÓN Nombre: Conjunto de características dinámicas Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: 4.2 Nro. Identificación ARTEFACTO: A_02ª Formato Asociado:
67
Artefacto 4.3: Informe de Decisión
El informe de decisión es un documento que justifica el uso de las líneas de
producción dinámica de software. La estructura del artefacto C y su contenido se
presentan a continuación en la tabla 10.
Tabla 10: Artefacto 4.3: Informe de decisión. InDoCaS ARTEFACTO DESCRIPCIÓN Nombre: Informe de decisión Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: A_02ª Nro. Identificación ARTEFACTO: 4.3 Formato Asociado: El informe de decisión se expresa mediante un documento compuesto por la justificación sobre la línea de producción dinámica de software, las estrategias de adaptación, las estrategias de reconfiguración y la sobrecarga del producto configurable
Enfoque de líneas de producción dinámica de software
En esta sección se establecen los requisitos de referencia, se clasifican las líneas
de producción dinámica de software de acuerdo al mecanismo de adaptación del
producto y se explica la estrategia seleccionada para atacar adaptación y
reconfiguración en esta investigación.
Requisitos de Referencia
A continuación, en la tabla 10, se presentan un conjunto de requisitos de
referencia, de posibles adaptaciones que se pueden abordar con la estrategia de líneas
de producción dinámica de software:
Tabla 11: Requisitos de Referencias Tipo Nombre del
Requisito Descripción del Requisito
Mecanismo de Adaptación
1. Actualización del producto
El producto obtiene las actualizaciones desde la SPL para ejecutar la adaptación.
2.Reconfiguración del producto
El producto se reconfigura a sí mismo para ejecutar la adaptación.
3. Mixto El producto aplica mecanismos de reconfiguración y de actualización dependiendo del requisito.
68
Requisitos de Adaptación
4. Delegación de la interfaz de usuario
Transferencia de (parte de) la funcionalidad de interfaz de usuario a otro dispositivo. Por ejemplo, al conducir un vehículo a un usuario móvil puede tener la opción de conectar el dispositivo móvil el equipo a bordo del coche con el fin de habilitar un modo de interacción de manos libres con el dispositivo móvil
5. Presentación de la interfaz de usuario
Ajuste de la interfaz de usuario de tal manera que se optimiza para las condiciones del contexto actual. Por ejemplo, sobre la base de las condiciones de luz ambiente de su localización, un dispositivo móvil puede ajustar el brillo de la pantalla
6. Amplitud de Funciones
Ampliación de la funcionalidad de una aplicación mediante el acceso a las nuevas componentes de software o hardware. Por ejemplo, una aplicación que controla el cine en casa en una sala de estar puede extender su funcionalidad, si un hardware nuevo plug-in se ha añadido para el control de las luces de la habitación
7. Amplitud de datos
Reaccionar a la calidad de intercambio dinámico de un flujo de datos. Por ejemplo, un vídeo aplicación de conferencia puede ser que desee para adaptarse a diferentes características de la red, tales como disponibles ancho de banda y latencia mediante el ajuste de la resolución y el color de fondo del video
8. Disponibilidad de la red
Adaptarse a las diferentes tecnologías de redes móviles, por ejemplo, GPRS, WLAN, Bluetooth, etc. Por ejemplo, un dispositivo móvil puede cambiar de una conexión inalámbrica cuando el usuario está en la oficina con una conexión GPRS cuando el usuario abandona el edificio
9. Seguridad Ajuste el modo de seguridad basada en el contexto de ejecución. Por ejemplo, la comunicación a través de un enlace de comunicación GPRS requiere cifrado fuerte, pero cuando el usuario vuelve a la la oficina y se conecta a la WLAN local, el cifrado puede ser apagado, con el consiguiente ahorro de recursos en el dispositivo
10. Modalidad del Software
Cambiar entre diferentes modos específicos de la aplicación de las operaciones. Por ejemplo, un sistema de streaming de vídeo puede seleccionar diferentes algoritmos de compresión en función de las tarifas de datos y la calidad de comunicación
11. Replicación y sincronización de datos
Automatizar la replicación y sincronización de datos tanto en el espacio y en el tiempo. Por ejemplo, cambiar de local de datos a una base de datos del servidor cuando el enlace de comunicación es rápida y barata, o aplazar la descarga de documentos de gran tamaño hasta que la red es lo suficientemente rápido o económica.
12. Cambios en las preferencias de usuario
Atender las necesidades cambiantes y preferencias del usuario durante la aplicación ciclo de vida. Por lo tanto, las necesidades y preferencias del usuario deben ser consideradas como parte del contexto. Por ejemplo, el usuario lo desea, puede especificar las prioridades de aplicación diferentes para situaciones diferentes,como el trabajo y el ocio
69
Clasificación de las líneas de producción dinámicas de software
Varios enfoques para desarrollar los productos configurables se han presentado a
través de la literatura, en esta investigación se muestran tres categorías de acuerdo al
mecanismo de adaptación del producto. Dichas categorías se describen desde la
perspectiva de la línea y desde la perspectiva del producto. En la tabla 12 se resume el
resultado de la clasificación.
En la perspectiva de la línea se estudian las técnicas de extensión incorporadas a
una línea de producción de software para convertirla en una línea de producción
dinámica y alcanzar la adaptación del producto, estudiando los siguientes criterios:
Mecanismo de adaptación, Contacto entre la línea y el producto configurable y el
Manejo de la variabilidad.
Desde la perspectiva del producto se estudian las ventajas y desventajas que tienen
agregar adaptación al producto y se consideran los siguientes criterios: Capacidad de
Adaptación, Grado de autonomía y sobrecarga computacional.
Tabla 12: Clasificación de las líneas de producción dinámicas de software
Criterio Líneas de producción de software conectadas
Líneas de producción de software desconectadas
Líneas de producción de software mixtas
Pers
pect
iva
de la
Lín
ea
1. Mecanismo de Adaptación
El producto configurable obtiene las actualizaciones desde la línea para ejecutar la adaptación
El producto configurable se reconfigura a sí mismo para ejecutar la adaptación
El mecanismo de adaptación depende de un escenario dinámico. En escenarios de involución el producto configurable aplica mecanismos de reconfiguración y en escenarios de evolución el producto configurable aplica mecanismos de actualización
2. Contacto entre la línea y el producto
Es necesaria la conexión bidireccional entre la línea dinámica y el producto. Si la conexión no está disponible la adaptación no se instaura.
No es necesaria la conexión entre la línea y el producto. La adaptación depende sólo de los recursos del mismo.
No es estrictamente necesaria para alcanzar algunos niveles de adaptación, aunque es necesaria para alcanzar adaptabilidad total.
3. Manejador de
variabilidad
Solo la línea está a cargo de manejar la variabilidad
Solo el producto está a cargo de manejar la variabilidad
Ambas cosas, tanto el producto como la línea están a cargo de la variabilidad
70
Pers
pect
iva
del p
rodu
cto
1. Capacidad de Adaptación
Mientras más alcance tenga la línea más adaptable será el producto.
Mientras mayor conocimiento de variabilidad tenga el producto más adaptable será.
Mientras más alcance tenga la línea más adaptable será el producto.
2. Grado de Autonomía
El producto depende de la línea para ejecutar adaptación, sin embargo, si la conexión no es posible el producto se comporta como un producto clásico.
El producto no depende de la línea para ejecutar la adaptación.
Se garantiza cierto nivel de adaptabilidad, incluso si la conexión entre la línea y el producto no fuera posible.
3. Sobrecarga computacional
La sobrecarga del PC depende de: 1) La comunicación con la línea, y 2) La instalación en línea de las actualizaciones.
La sobrecarga depende de: 1) El análisis de variabilidad, y 2) La reconfiguración en línea.
En el peor de los casos depende de: 1) El análisis de variabilidad local, 2) La comunicación con la línea, y 3) La instalación en línea de las actualizaciones.
Estrategia de Adaptación y Reconfiguración
Para efectos de esta investigación se utilizará el enfoque de adaptación mixta, en
las líneas de producción dinámica de software. En la figura 19 se muestra la estrategia
de reconfiguración, donde se aplican mecanismo de actualización en escenarios de
evolución, es decir, escenarios donde el producto no se puede reconfigurar a sí mismo
y se hace desde la línea a través de la adición de la propiedad deseada. Y se aplican
mecanismos de reconfiguración en escenarios de involución, es decir, la activación y
desactivación de propiedades que posee el producto configurable.
Figura N° 20. Estrategia de Reconfiguración.
71
Por su parte, en la figura 20 se muestra la estrategia de adaptación de una línea de
producción dinámica mixta, obsérvese lo siguiente:
1. El producto configurable detecta un cambio relevante que inicia el proceso de
adaptación, tanto los cambios en el entorno, como los cambios en el dispositivo e
incluso los cambios en el usuario pueden disparar un proceso de adaptación.
2. El producto configurable calcula una nueva configuración para tratar el
cambio detectado.
a. Si no hay configuración que satisfaga el requisito, el producto
configurable delega la adaptación a la línea.
b. La línea incorpora la información adquirida a los requisitos del producto
y calcula una nueva variante del producto.
i. Si no hay variante que satisfaga el producto, la línea notifica al
producto y el proceso de adaptación falla.
c. La línea genera la actualización del producto.
d. La línea envía la actualización al producto configurable.
e. El producto se actualiza a sí mismo usando la actualización de la línea y
el proceso de adaptación termina.
3. El producto configurable se actualiza a sí mismo aplicando la configuración
calculada. El proceso de reconfiguración implica: 1) Iniciar/Detener los activos y 2)
establecer la conexión entre ellos.
72
Figura N° 21. Estrategia de Adaptación.
Caso de Estudio
En esta sección se presenta el dominio de aprendizaje de idiomas asistido por
móviles sensible al contexto, que se utiliza para ejecutar el proceso de InDoCaS
especializado y así mostrar las actividades y artefactos que se obtienen.
Dominio: Aprendizaje de idiomas asistido por móviles (MALL)
El aprendizaje electrónico de idiomas asistido por móviles MALL es una
aproximación para el aprendizaje de idiomas a través del uso de dispositivos móviles,
un subconjunto del aprendizaje móvil y del aprendizaje de idiomas asistido por
computadoras CALL8. El dominio MALL implica el uso de tecnologías móviles, que
permitan soportar aprendizaje de idiomas.
8 CALL: siglas de Computer Assisted Language Learning
73
En MALL los participantes son capaces de acceder material para el aprendizaje
de idiomas y comunicarse con sus profesores, es decir acceso ubicuo (adaptable al
contexto) para aprender en cualquier momento y lugar que el usuario tenga
recepción.
A efectos del aprendizaje electrónico el usuario no necesita estar sentado en un
aula de clases o computador para acceder al material de estudio. Esto le ayuda
mejorar los niveles del idioma justo antes o después de una conversación en el
lenguaje que se aprende. El uso de dispositivos móviles permite capitalizar nuevas
dinámicas de aprendizaje electrónico donde usuarios comparten el proceso de
aprendizaje de idiomas en pequeños grupos de manera sincronizada (Nah et al.,
2008).
En (Kloper et al., 2002) se proponen 5 propiedades de los dispositivos móviles
que hacen única la calidad que pueden incorporar en el proceso de enseñanza-
aprendizaje:
1. Portabilidad, tamaño y peso de los dispositivos móviles, que significa que
ellos pueden ser tomados en diferentes sitios o desplazarse en diferentes lugares.
2. La interacción social mediante el intercambio de datos y colaboración con
otros aprendices puede ocurrir cara a cara.
3. Los dispositivos móviles sensibles al contexto pueden agrupar y responder a
datos reales o simulados en su localización, ambiente y tiempo actual.
4. La conectividad a una red compartida se puede crear conectando los
dispositivos móviles a un servidor de datos, otros dispositivos o una red común.
5. La configuración individual para las actividades difíciles se puede ajustar a
cada participante.
Diferentes investigadores se han avocado a investigar el potencial de enseñanza de
idiomas usando dispositivos móviles (Godwin-Jones, 2004) (Kadyte, 2003) (Tan y
74
Liu, 2004). El proyecto INLET (Pincas, 2004), desarrolló una innovadora aplicación
móvil para que turistas aprendieran el idioma griego en los juegos olímpicos de
Atenas. El sistema incorporó un numero de facilidades para aprender a usar frases de
griego en varias categorías tales como “BASICO” (saludos, números, palabras
básicas), “DONDE” (frases para preguntar direcciones, viajando en bus, taxi y tren),
“CUANDO” (preguntas de tiempo, hoy, ahora, mañana), “DEPORTES
OLIMPICOS” (nombre de los juegos, atletas, entre otros) y “COMPRAR”
(preguntando precios, monedas, expresiones como caro, barato, entre otros). Los
usuarios solicitaban en el aeropuerto de Atenas, dónde se podían registrar para
enviar/recibir mensajes gratis y continuamente recibían frases prácticas cada día en
sus móviles, pudiendo también requerir traducciones desde otros idiomas al griego.
Las características fundamentales definidas para el aprendizaje de idiomas usando
dispositivos móviles implica el uso de anuncios y diarios. El registro de anuncios,
sugiere el significado al participante a través de colecciones de datos introspectivos
igual a proporcionar una clara imagen de lo que el participante atiende más que otros
métodos importantes (Al-Hejin, 2008). Así mismo, ofrece directrices para el
diseñador y desarrollador de software para aprendizaje móvil de idiomas donde
adiciona el aviso del participante a la reflexión y meta-conocimiento. La información
que contiene el aviso puede ser usada como un recordatorio para el participante y por
supuesto el acto de formular la entrada para su diario puede ayudar a consolidar su
nuevo conocimiento.
Para ejemplificar, un anuncio en el aprendizaje del idioma inglés en el cual los
verbos que tienen vocales abiertas centrales como: “Catherine (feel) felt sad when her
father passed away”, “our company (deal) dealt with many european countries 1999”,
son distintas formas que podría tomar la estructura de un anuncio donde los verbos
“felt”, “dealt” en los dos primeros ejemplos mostrarían el conocimiento del idioma
que tiene el estudiante y a través del tag sobre el verbo podría obtener información
acerca del uso de estas expresiones. Así que, en el siguiente aviso: “Try: Sam (keep)
75
keep keeped/kepted in his garage”, mostraría recomendaciones que sobre el uso del
verbo “keep” la aplicación pondría a disposición del estudiante.
Por otro lado, el uso de los diarios de aprendizaje para idiomas relaciona la
oportunidad de aprendizaje de idiomas usando móviles y considera los beneficios del
modelaje del conocimiento del participante en este contexto. Los diarios permiten
detalles no estructurados dentro del idioma del participante, sugiriendo cómo registrar
elementos avisados al mismo tiempo que se facilito usando el dispositivo móvil y
como modelar anuncios de un modo más sistemático que pueda incrementar el
proceso de aprendizaje en contextos móviles.
Los diarios de aprendizaje son usados por varias partes envueltas en el contexto
del idioma que se aprende y se definen como casos de estudio en primera persona
(Bailey, 1991) y pueden proveer dentro del participante conocimiento explícito de su
proceso de aprendizaje. El participante registra aspectos de su aprendizaje en su
diario, el cual puede incluir sus apreciaciones, sentimientos y actitudes acerca de su
aprendizaje o características del idioma que puede apreciar. Estos diarios son
apreciables en ambientes donde los aprendices tienen cierto grado de autonomía, es
decir la libertad de tomar decisiones acerca de su aprendizaje, tales como tomar
responsabilidades para objetivos, contenido, progreso y método de aprendizaje
(Palfreyman y Smith, 2003).
El diario puede ser parte del proceso formal de aprendizaje, pero este puede
también ser una actividad informal o complementaria. Los diarios de aprendizaje son
hechos por:
Estudiantes, para ayudar a enfocar su atención en sus estrategias para
aprendizaje del idioma (Oxford et al., 1996), incrementa sus habilidades para percibir
el lenguaje (Allison, 1998) y promover la reflexión en el segmento del idioma
(Simard, 2004).
76
Profesores, para fomentar una reflexión del enfoque en el medio de monitores
(Flowerdew, 1998).
Investigadores, para proveer ejemplos del potencial del enfoque de diarios
(Schmidt y Frota, 1986).
Adicionalmente, los profesores usan los diarios de estudiantes o aprendices para
ayudarlos a mejorar el entendimiento que necesitan sus estudiantes (Teng Sze Mei,
2003) y enlazar que debe realizarse entre diarios y blog (Suzuki, 2008).
De manera que, a continuación se determinan características adicionales
relevantes que la familia de aplicaciones de aprendizaje electrónico de idiomas debe
presentar:
Un grupo de dificultades típicas de un idioma escogido que pueda ayudar en
el diseño de un ambiente para indicar directrices de dificultades específicas de
aprendizaje. Estos elementos pueden ser: formas de expresiones, preguntas, verbos
modales, preposiciones, localizaciones específicas, entre otros.
Consideraciones de procesamiento de características en diferentes estados del
aprendizaje que pudieran asistir en la identificación de elementos más generales.
Familiarización con el concepto de anuncios en el aprendizaje de lenguajes y
resaltar sus beneficios, esto puede ser hecho mostrando video de participantes que
utilicen anuncios.
La literatura diaria de aprendizaje del idioma, podría ayudar en la
familiarización de como los participantes pueden naturalmente registrar
explícitamente características del idioma.
Inclusión de eventos en un modelo simple de aprendizaje, que permita
definiciones y revisiones en su diario de aprendizaje.
Servicios de administradores de contenidos dinámicos en sus diarios.
Los anuncios pueden ser más motivadores y efectivos si son combinados con
oportunidades de comunicación con otros. Permitiendo discusiones de conocimiento
77
cara a cara entre participantes-participantes y participantes-profesores que puedan
facilitarse usando mensajes instantáneos y redes sociales.
Servicios de comunicación entre participante y participante, participante y
profesor.
Compartimiento de datos entre miembros de grupos, círculos sociales,
comunidades y subculturas.
Sensores para los servicios sensibles al contexto (ubicación geográfica, físicos
luz, redes) en el ambiente que interactúan con el participante.
Colaboración usando tableros de anuncios, servicios de mensajería instantánea
tipo chat que permitan observar expresiones particulares y poder usar herramientas de
comunicación para preguntar cosas acerca de ellas.
Análisis del Dominio MALL
Luego de la descripción del dominio de aprendizaje de idiomas asistido por
móviles, a continuación se aplicará InDoCaS a este dominio, en la tabla 13 se
muestra el conjunto de actividades del análisis de la ingeniería del dominio, nótese
que fue agregada la actividad variante A_02a “Generar modelos dinámicos” y
suprimida la actividad A_05, “Creación de escenarios de calidad del dominio”.
Tabla 13. Actividades del modelo de procesos InDoCaS aplicados al dominio
Actividad Nombre de la actividad Artefacto Tabla resultante
A_01 Identificación de requisitos 1, 2 14, 15
A_02 Obtener modelo de similitudes y variabilidad 3, 4, 5 16, 17, 18
A_02a Generar modelos dinámicos 4.1, 4.2, 4.3 19, 20, 21
A_03 Identificación de propiedades de calidad 6, 7 22, 23
A_04 Obtener modelo de calidad asociado al dominio 8 24
A_06 Identificar los estilos arquitecturales para el dominio 10 25
78
Identificación de Requisitos
En esta actividad se desarrollan dos artefactos a saber: Lista de requisitos
funcionales y no funcionales del dominio y se muestran en las tablas 14 y 15
respectivamente, a partir de la descripción del dominio que se presentó anteriormente.
Tabla 14. Lista de requisitos funcionales del dominio MALL
InDoCaS ARTEFACTO DESCRIPCIÓN Nombre: Lista de requisitos funcionales del dominio Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: A_01 Nro. Identificación ARTEFACTO: 1
Nro. Identificación Descripción del requisito funcional
1
Administrar un conjunto de dificultades típicas de un idioma que pueda ayudar en el diseño de un ambiente para indicar directrices de dificultades específicas de aprendizaje como: formas de expresiones, preguntas, verbos modales, preposiciones, localizaciones específicas, entre otros.
2 Procesamiento de características en diferentes estados del aprendizaje que pudieran asistir en la identificación de elementos más generales.
3 Uso de anuncios en el aprendizaje de lenguajes y resaltar sus beneficios, esto puede ser hecho mostrando video de participantes que utilicen anuncios.
4 Servicios de administradores de contenidos dinámicos en sus diarios.
5 Permitir discusiones de conocimiento cara a cara entre participantes-participantes y participantes-profesores.
6 Uso de tableros de anuncios y servicios de mensajería instantánea tipo chat que permitan observar expresiones particulares y poder usar herramientas de comunicación para preguntar cosas acerca de ellas.
7 La literatura diaria de aprendizaje del idioma, podría ayudar en la familiarización de como los participantes pueden naturalmente registrar explícitamente características del idioma
8 Servicios de comunicación entre participante y participante, participante y profesor.
9 Inclusión de eventos en un modelo simple de aprendizaje, que permita definiciones y revisiones en su diario de aprendizaje.
-
Seguidamente, se expresan los requisitos no funcionales definidos con
RECLAMO.
79
Tabla 15. Lista de requisitos no funcionales del dominio MALL
InDoCaS ARTEFACTO DESCRIPCIÓN Nombre: Lista de requisitos no funcionales del dominio Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: A_01 Nro. Identificación ARTEFACTO: 2
Nro. Identificación
Reglas del Negocio asociadas al dominio
Requisitos no funcionales derivados de las reglas del negocio
Políticas
1
Uso de protocolos de comunicación de redes, ancho de banda
- Cumplimiento de estándares, normativas con el fin de garantizar el servicio requerido. - Minimización en el consumo de recursos del dispositivo (batería, capacidad de almacenamiento, tamaño del display etc.)
Procesamiento
2
Los servicios se ejecutan en diversidad de dispositivos
- Servicios de comunicación entre participante y participante, participante y profesor. - Servicios de compresión de datos dependiendo de las tarifas de descarga y la calidad de comunicación
3 El usuario selecciona los servicios a compartir
- Compartimiento de datos entre miembros de grupos, círculos sociales, comunidades y subculturas. - Cambiar de servidor de datos de local a remoto dependiendo de la conexión a red - Suspender una descarga de datos hasta que la velocidad de la red sea lo suficientemente buena.
4 Los servicios responden dinámicamente
Sensores para los servicios sensibles al contexto (ubicación geográfica, físicos luz, redes) en el ambiente que interactúan con el participante.
Implementación
5 Presentación de la interfaz de usuario
- Sobre la base de las condiciones de luz ambiente de su localización, un dispositivo móvil puede ajustar el brillo de la pantalla - Cambiar el modo de la interfaz (seleccionar audio o video)
6 Restricción de miembros del grupo
- Se permite el acceso únicamente a estudiantes y profesores de la clase.
Obtener modelo de similitudes y variabilidad
En esta actividad, se define el conjunto de requisitos mínimos y obligatorios en las
familias de aprendizaje de idiomas asistido por móviles, usando FODA, consiguiendo
tres artefactos: conjunto de características, conjunto de puntos de variación y
80
conjunto minimal de requisitos funcionales y no funcionales. El modelo de
características se presenta a continuación en la tabla 16.
Tabla 16. Conjunto de características
InDoCaS
ARTEFACTO DESCRIPCIÓN Nombre: Conjunto de características (features) Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: A_02 Nro. Identificación ARTEFACTO: 3
A continuación se obtienen los puntos de variación, los cuales describen dónde
existen diferencias en los productos finales, expresan la variabilidad en las
características y se presenta en la tabla 17.
Tabla 17. Conjunto de puntos de variación
InDoCaS
ARTEFACTO DESCRIPCIÓN Nombre: Conjunto de puntos de variación Constructor: Analista de Requisitos
81
Nro. Identificación ACTIVIDAD: A_02 Nro. Identificación ARTEFACTO: 4
Característica Punto de Variación Compartir datos: los dispositivos móviles formaran una red ad-hoc que se conectará entre ellos para intercambiar información y para proporcionar otros servicios a los usuarios.
Esta característica depende en gran medida de la conexión a la red y la trasmisión de datos de los participantes del curso de idiomas. En la descarga de datos es posible utilizar algoritmos de compresión y descarga dependiendo de la conexión
Reconfiguración Dinámica de Interfaces, se debe considerar los requisitos particulares de los participantes y sus dispositivos.
Se puede hacer una en el software que corre en el móvil, sin necesidad de reconfiguración en caso de ejecutarse localmente. Ajuste dinámico a los accesorios conectados al dispositivo.
Sincronización de datos: cambiar de servidor local a remoto dependiendo de la conexión a la red.
El dispositivo detecta las características de la red y se ajusta dinámicamente.
Seguidamente, se presenta el conjunto de requisitos mínimos y obligatorios de la
familia de aplicaciones de aprendizaje de idiomas asistido por móviles (MALL),
descrito por el artefacto “conjunto minimal de requisitos funcionales y no
funcionales” que se muestra en la tabla 18.
Tabla 18. Conjunto minimal de requisitos funcionales y no funcionales
InDoCaS
ARTEFACTO DESCRIPCIÓN
Nombre: Conjunto minimal de requisitos funcionales y no funcionales
Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: A_02 Nro. Identificación ARTEFACTO: 5
Nro. Identificación Descripción del requisito funcional 1 Gestión de Datos: Los datos deben ser transmitidos completa y
correctamente. 2 Gestión de información: gestión de la información de participantes y
profesores. 3 Uso de anuncios en el aprendizaje de lenguajes y resaltar sus beneficios,
esto puede ser hecho mostrando video de participantes que utilicen
82
anuncios. 4 Servicios de administradores de contenidos dinámicos en sus diarios. 5 Servicios de comunicación entre participante y participante, participante
y profesor.
Nro. Identificación
Descripción del requisito no funcional
1 - Minimización en el consumo de recursos del dispositivo (batería, capacidad de almacenamiento, tamaño del display etc.)
2 - Servicios de compresión de datos dependiendo de las tarifas de descarga y la calidad de comunicación
3 - Servicios de comunicación entre participante y participante, participante y profesor.
4 - Compartimiento de datos entre miembros de grupos, círculos sociales, comunidades y subculturas.
5 - Sensores para los servicios sensibles al ambiente que interactúan con el participante.
6 - Cambiar el modo de la interfaz dependiendo de los accesorios conectados al dispositivo
7 - Sobre la base de las condiciones de luz ambiente de su localización, un dispositivo móvil puede ajustar el brillo de la pantalla
8 - Se permite el acceso únicamente a estudiantes y profesores de la clase. 9 - Los servicios deben adaptarse al usuario
10 - Facilidad en la selección e instalación de los servicios seleccionados 11 - Reconfiguración dinámica de interfaces
Puesto que existen requisitos en el dominio que coinciden con los requisitos de
referencia, lo que supone posibles adaptaciones que se pueden abordar con la
estrategia de líneas de producción dinámica de software, se procede a ejecutar la
actividad “Generar modelos dinámicos”.
Generar modelos dinámicos Se inicia con el artefacto 4.1 “Conjunto de puntos de variación dinámicos” una
extensión del artefacto 4, al cual se le anexan las características dinámicas conocidas
como variante de los puntos de variación. Se muestra a continuación en la tabla 19.
Tabla 19: Conjunto de puntos de variación dinámicos. InDoCaS ARTEFACTO DESCRIPCIÓN
83
Nombre: Conjunto de puntos de variación dinámicos Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: A_02a Nro. Identificación ARTEFACTO: 4.1 Formato Asociado:
Característica Punto de Variación Variante Compartir datos: los dispositivos móviles formaran una red ad-hoc que se conectará entre ellos para intercambiar información y para proporcionar otros servicios a los usuarios.
Esta característica depende en gran medida de la conexión a la red y la trasmisión de datos de los participantes del curso de idiomas. En la descarga de datos es posible utilizar algoritmos de compresión y descarga dependiendo de la conexión
Forma de conexion: Bluetooth, WLAN, Algoritmos de compresión de datos. Activación colaboración de anuncios y diarios de estudio.
Reconfiguración Dinámica de Interfaces, se debe considerar los requisitos particulares de los participantes y sus dispositivos.
Se puede hacer una en el software que corre en el móvil, sin necesidad de reconfiguración en caso de ejecutarse localmente. Ajuste dinámico a los accesorios, conectados al dispositivo.
Iluminación de la pantalla en caso de poca luz. En caso de sitios ruidosos aumentar volumen Detección de accesorios y uso plug-play
Sincronización de datos: cambiar de servidor local a remoto dependiendo de la conexión a la red.
El dispositivo detecta las características de la red y se ajusta dinámicamente.
Ajuste al ancho de banda. Suspensión de descargas dependiendo de la calidad de red
A partir de los puntos de variación y sus variantes es posible construir ahora el
conjunto de características dinámicas asociadas al dominio, haciendo uso de un
modelo de características extendido para tal fin. Obsérvese la tabla 20 donde se
especifica el artefacto 4.2
Tabla 20: Conjunto de características dinámicas. InDoCaS ARTEFACTO DESCRIPCIÓN Nombre: Conjunto de características dinámicas Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: 4.2 Nro. Identificación ARTEFACTO: A_02a Formato Asociado:
84
Tabla 21: Informe de decisión. InDoCaS ARTEFACTO DESCRIPCIÓN Nombre: Informe de decisión Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: A_02ª Nro. Identificación ARTEFACTO: 4.3 Formato Asociado: Justificación: Se justifica el uso de las líneas de producción dinámicas de software, puesto que en el dominio en estudio (MALL) existen requisitos que surgen de la intersección entre los requisitos minimales del dominio y los requisitos de referencia presentados en la tabla 11 de esta investigación. Estrategias de adaptación: Se sugiere una estrategia de adaptación mixta, donde tanto la línea de producción como el poseen capacidad de adaptarse a los cambios del entorno utilizando los modelos de variabilidad. Estrategias de reconfiguración: Se recomienda una reconfiguración dual basada en la adaptación propia de los servicios a los dispositivos y en la actualización de servicios sin que el usuario note cómo sucede la activación y desactivación de características de las aplicaciones, lo que reduce la sobrecarga computacional, debido a que se da en casos poco probables.
85
Identificación de propiedades de calidad
Tabla 22: Lista de requisitos funcionales con sus propiedades de calidad. InDoCaS ARTEFACTO DESCRIPCIÓN
Nombre: Lista de requisitos funcionales con sus propiedades de calidad.
Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: A_03 Nro. Identificación ARTEFACTO: 6 Formato Asociado:
Nro. Identificación
Requisitos Funcionales Características de calidad ISO/IEC 25010
Atributos (Características)
1
Gestión de Datos: Los datos deben ser transmitidos completa y correctamente.
Confiabilidad - Disponibilidad Eficiencia - Comportamiento en el tiempo Funcionalidad - Preciso
Atributo: Tiempo de espera. Métrica: valor en rango [1..5] Atributo: consumo de recurso para cada dispositivo Métrica: porcentaje [0..1] Atributo: tiempo de completitud de tareas Métrica: valor en rango [1..10]
2
Gestión de información: gestión de la información de participantes y profesores.
Usabilidad - Reconocido como adecuado - Operabilidad Portabilidad - Adaptabilidad
Proporción de las funcionalidades que son entendidas correctamente por los participantes Proporción de las funciones que pueden adaptar los participantes y profesores
3
Uso de anuncios en el aprendizaje de lenguajes y resaltar sus beneficios, esto puede ser hecho mostrando video de participantes que utilicen anuncios.
Compatibilidad - Coexistencia
Intercambio de datos entre profesores y participantes.
4 Servicios de administradores de contenidos dinámicos
Usabilidad - Reconocido como adecuado.
Proporción de las funcionalidades que son entendidas
86
en sus diarios. - Operabilidad correctamente por los participantes
5
Servicios de comunicación entre participante y participante, participante y profesor.
Confiabilidad - Disponibilidad Compatibilidad - Coexistencia
Atributo: Tiempo de espera. Métrica: valor en rango [1..5] Tasa de intercambio de datos.
Tabla 23: Lista de requisitos no funcionales con sus propiedades de calidad.
InDoCaS ARTEFACTO DESCRIPCIÓN
Nombre: Lista de requisitos no funcionales con sus propiedades de calidad.
Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: A_03 Nro. Identificación ARTEFACTO: 7 Formato Asociado:
Nro. Identificación
Reglas del negocio asociadas
al Dominio
Requisitos no funcionales
derivado de las reglas del negocio
Propiedades de calidad asociado a los requisitos no funcionales ISO/IEC 25010
Atributo (Característica) ISO/IEC 13236
Políticas
1
Uso de protocolos de comunicación de redes, ancho de banda.
Cumplir con estándares, normativas con el fin de garantizar el servicio requerido.
Confiabilidad Disponibilidad
Atributo: tiempo de servicio agregado
Procesamiento
2
Los servicios se ejecutan en una diversidad de dispositivos, cada uno con configuraciones y funcionalidades diferentes.
Las funciones deben adaptarse a las características de los dispositivos.
Portabilidad Adaptabilidad Instalabilidad Reemplazable
Proporción de las funciones que pueden adaptar los participantes y profesores Atributo: Tiempo de espera. Métrica: valor en rango [1..5]
3 Los servicios deben ser garantizados
Hacer posible el acceso a los servicios, lo cual
Confiabilidad Disponibilidad
Atributo: tiempo de servicio agregado
87
dentro del área de cobertura.
implica, ancho de banda apropiado y garantizar las conexiones móviles, teniéndose que solventar problemas de redes. Tiempo de transmisión apropiado. Tiempos de respuesta adecuados dentro de un rango establecido.
Eficiencia Comportamiento en el tiempo
Atributo: Tiempo de espera. Métrica: valor en rango [1..5]
4
El usuario selecciona los servicios disponibles en el área de cobertura.
Ofrecer funcionalidades que respondan a las necesidades de los usuarios. Facilidad en la selección de los servicios ofrecidos.
Funcionalidad Apropiado Preciso Usabilidad Operabilidad
Atributo: Tiempo de completitud de tareas. Proporción de las funcionalidades que son entendidas correctamente por los participantes
5
Los dispositivos se conecten y desconectan dinámicamente a la red.
Garantizar la disponibilidad del servicio al conectarse.
Confiabilidad Disponibilidad
Atributo: Tiempo de espera agregado
Implementación
6
Personalización e instalación de los servicios en el dispositivo del usuario.
Los servicios deben adaptarse al usuario. Instalación transparentemente de los servicios al usuario. Los servicios deben adaptarse a las capacidades
Funcionalidad Apropiado Portabilidad Instalabilidad Adaptabilidad
Atributo: tiempo de completitud de tareas. Proporción de las funciones que pueden ser adoptadas por el usuario
88
del dispositivo
7
Los usuarios deben acceder los servicios independientemente del procesador del dispositivo, por ejemplo un navegador.
La interacción entre el usuario y el dispositivo debe ser sencilla y fácil de usar.
Usabilidad Operabilidad
Proporción de las funcionalidades que son entendidas correctamente por los participantes
8
La interfaz de usuario se debe adaptar al dispositivo en uso.
Reconfiguración dinámica de Interfaces, se deben considerar requerimientos especiales de usuarios y las capacidades de los dispositivos involucrados.
Portabilidad Adaptabilidad
Proporción de las funciones que pueden ser adoptadas por el usuario
Obtener modelo de calidad asociado al dominio
El modelo de calidad del dominio representa la calidad de un producto de software
del dominio como una expresión acerca de la capacidad del software de ejecutar u
mantener un nivel de servicio especificado, y se resume a continuación en la tabla 24.
Tabla 24: Modelo de calidad asociado al dominio. InDoCaS ARTEFACTO DESCRIPCIÓN Nombre: Modelo de calidad asociado al dominio. Constructor: Analista de Requisitos Nro. Identificación ACTIVIDAD: A_04 Nro. Identificación ARTEFACTO: 8 Formato Asociado:
89
Identificar estilos arquitecturales
Previo a la identificación de los estilos arquitecturales que conforman los estilos
arquitecturales que conforman el artefacto estilos arquitecturales de las aplicaciones
MALL, se consideran los artefactos “conjunto minimal de requisitos funionales y no
funcionales y el modelo de calidad” donde se presentan características que deben ser
satisfechas por los estilos arquitecturales, en particular requisitos como:
Reconfiguración dinámica de interfaces, se deben tener en cuenta los
requisitos especiales de los usuarios y las capacidades de los dispositivos
involucrados. Portabilidad(Adaptabilidad).
Las funciones deben adaptarse a las características de los dispositivos.
Portabilidad(Adaptabilidad).
Los servicios deben adaptarse a las características de los dispositivos y al
perfil de estudiantes y profesores. Adaptar el contenido de los cursos de idiomas a los
grupos y ambientes. Portabilidad (Adaptabilidad, Instalabilidad, Reemplazable).
Esta situación afianzan los estilos MAS9 (basados en invocación implícita) y
Multicapas (SOA10, modelos cliente-servidor), descritos brevemente a continuación:
MAS basados en invocación implícita: arquitecturas basadas en agentes de
software, ampliamente utilizadas en aplicaciones distribuidas. Los Agentes de
9 MAS: siglas de Multiple Agent System 10 SOA: siglas de Service-Oriented Architecture
90
software son entidades que pueden actuar en nombre de otra entidad y que poseen
ciertas propiedades deseables como autonomía, flexibilidad (Reactividad-
Adaptabilidad, Proactividad, Comunicabilidad-Sociabilidad), continuidad temporal,
movilidad (Agentes móviles), capacidad de Razonamiento / Aprendizaje y Seguridad
/ Confiabilidad. (Yaguez, 2007). Los sistemas MAS ejecutan acciones sobre la
arquitectura para manejar cambios requeridos por las modificaciones y aseguran,
algunos aspectos de calidad.
Multicapas: las arquitecturas de software basadas en componentes ofrecen
una gran posibilidad de satisfacer los requisitos de reconfiguración dinámica y el
ensamblaje de componentes dinámicos establecidos. Debido a que son los elementos
principales de los sistemas distribuidos, éstos ofrecen servicios a otros componentes
que pueden requerir servicios en tiempo de ejecución.
Por lo antes expuesto, se utilizan los estilos arquitecturales MAS (basados en
invocación implícita) y Multicapas (SOA, modelos cliente-servidor) como miembros
del artefacto estilos arquitecturales que se presenta en la tabla 25.
Tabla 25: Estilos Arquitecturales. InDoCaS ARTEFACTO DESCRIPCIÓN Nombre: Estilos arquitecturales. Constructor: Arquitecto de Software y Analista de requisitos Nro. Identificación ACTIVIDAD: A_06 Nro. Identificación ARTEFACTO: 10 MAS (Basados en invocación implícita) Multicapas (SOA, modelos cliente-servidor)
Este es el modelo arquitectural propuesto para las aplicaciones de aprendizaje de
idiomas asistido por móviles MALL, y se completa la disciplina de análisis del
dominio del proceso de Ingeniería de dominio propuesto por InDoCaS.
91
CAPÍTULO V
CONCLUSIONES Y RECOMENDACIONES
Conclusiones
Después de realizar el modelo arquitectural para aplicaciones móviles basado en el
enfoque de líneas de producción dinámica de software, se llegan a las siguientes
conclusiones:
1. Los sistemas de software están sujetos a la evolución, a las actualizaciones
dinámicas, debido a cambios en los requisitos del cliente, contexto de uso o la
tecnología.
2. Una Línea de Producción Dinámica de Software se diseña para apoyar
explícitamente, los escenarios de actualización dinámica. Como consecuencia, la
variabilidad y el modelo de variabilidad asociado a estos sistemas no son estáticos
3. Gracias al proceso para la ingeniería del dominio basado en calidad de
software InDoCaS, es posible obtener una arquitectura base con calidad para una
familia de productos.
4. Se hizo necesaria la especialización del proceso InDoCaS, agregando
actividades y artefactos a su disciplina análisis del dominio para ajustar el proceso a
las líneas de producción dinámica de software.
5. Se experimentó el proceso en el dominio de Aprendizaje de idiomas asistido
por móviles (MALL), estudiando algunos requisitos dinámicos, se puede concluir que
es viable su uso en otros dominios o en otras investigaciones similares.
92
6. Se destaca que la pericia de un arquitecto es de suma importancia en todo el
proceso de ingeniería de dominio, lo que representa un inconveniente al momento de
ejecutar el proceso, puesto que ciertas decisiones como la escogencia de los patrones
y estilos arquitecturales depende del punto de vista del arquitecto y su experiencia.
7. Es propio señalar que el activo de software denominado “Requisitos de
referencia”, con el cual se comparan los requisitos minimales del dominio y decidir si
se trata de una línea habitual o dinámica, se puede extender a las necesidades propias
de cada proyecto, incluso se pueden sugerir soluciones arquitecturales para cada
requisito.
93
Recomendaciones
Tomando en cuenta el estudio, sus conclusiones y hallazgos se considera
conveniente lo siguiente:
1. Concluir el proceso InDoCaS, para las líneas de producción dinámicas de
software, en sus disciplinas de diseño e implementación del dominio, para de esta
manera completar el proceso de ingeniería de dominio.
2. Crear repositorios para requisitos, arquitecturas, catálogo de patrones y estilos,
y anexarlos a las actividades proceso InDoCaS, esto permite realizar una trazabilidad
de los activos de software de una línea de producción y organizar la reutilización.
3. Elaborar una herramienta automatizada que permita manejar con facilidad las
actividades y artefactos presentes en el proceso InDoCaS.
4. Aplicar la propuesta a otros dominios, esto puede proporcionar información
valiosa. Mediante el estudio de un grupo heterogéneo, la experiencia del usuario
puede ser evaluada para comprobar en qué medida el sistema se comporta como se
esperaba
5. Manejar la variabilidad en líneas de Producción usando aspectos, es decir,
usar aspectos dinámicos, los modelos de tiempo de ejecución de los aspectos, así
como la detección y resolución de las interacciones de los aspectos.
94
GLOSARIO DE TÉRMINOS
ADL (Architecture description language) Lenguaje de descripción de
arquitectura: Lenguaje (gráfico, textual, o ambos) para describir un sistema de
software en términos de sus elementos arquitectónicos y las relaciones entre ellos.
Estilo Arquitectural: Una especialización de los elementos y tipos de relación, en
combinación con un conjunto de restricciones sobre cómo pueden ser utilizados.
Véase patrón arquitectural.
Característica (feature): Abstracción funcional distintiva e identificable que
puede ser empaquetada, implementada, probada, distribuida y mantenida. Son, por
tanto, objetos de primera clase en el desarrollo de software orientado a un dominio
Patrón Arquitectural: Descripción de elementos y tipos de relación, en
combinación con un conjunto de restricciones sobre cómo se utilizan.
ADD (Attribute-Driven Design Method) Método de diseño dirigido por atributos:
Enfoque para definir una arquitectura de software, al basar el proceso de diseño sobre
los atributos de calidad del sistema.
Componente: Entidades tales como clientes, servidores, bases de datos, filtros y
capas de un sistema jerárquico. Son además, una parte encapsulada del sistema de
software, donde cada uno tiene una interfaz.
Conector: Itinerario de tiempo de ejecución de la interacción entre dos o más
componentes.
Atributo de Calidad: Característica de un producto por el cual se juzga la calidad
de algunos actores o partes interesadas. Los requisitos de calidad tales como los de
rendimiento, seguridad, modificabilidad, confiabilidad y facilidad de uso tienen una
influencia significativa en la arquitectura de software de un sistema.
Puntos de Sensibilidad: Propiedad de uno o más componentes (y / o relaciones de
componentes) que es crítica para lograr una respuesta de calidad en particular.
95
Aquellos puntos en particular donde un pequeño cambio puede tener un gran impacto
sobre la arquitectura.
Stakeholder (Actor del Sistema): Persona que tiene interés especial sobre la
arquitectura.
Tradeoff (Relaciones de intercambio): Propiedad que afecta a más de un atributo
y es un punto de sensibilidad de más de un atributo
Dominio: Área de conocimiento o de actividad caracterizada por un conjunto de
conceptos y terminología comprensible para los profesionales en esa área.
Análisis del dominio: Proceso para capturar y representar la información sobre las
aplicaciones en un dominio, específicamente las características comunes, las
variaciones, y las razones de la variación.
Arquitectura de Software: Infraestructura del sistema, que incluyen elementos de
software, las propiedades externamente visibles de esos elementos, y las relaciones
entre ellos.
Activos de Software: Colección de partes de software (requisitos, diseños,
componentes, casos de prueba, arquitecturas, entre otros.) que se configuran y
componen de una manera prescrita para producir los productos de la línea.
Familia de productos de software: Conjunto de productos de software asociados a
un dominio determinado.
96
REFERENCIAS BIBLIOGRÁFICAS
Al-Hejin, B. (2008). Attention and awareness: Evidence from cognitive and second language acquisition research. College, Columbia University Working Papers. journal.tc-library.org
Allison, D. (1998). Investigating learners’ course diaries as explorations of language. Sage Publications. Journal Language Teaching Research
Bachman F., Goedicke M., Leite J., Nord R., Pohl K., Ramesh B., y Vilbig A. (2003). Meta-model for representing variability in product family development. In Proceedings in the 5th International Workshop on Product Family Engineering (PFE’5), pp. 66-80, 2003.
Bailey, K. (1991). Diary studies of classroom language learning: The doubting game and the believing game. works.bepress.com
Balestrini, M. (2005). Cómo se elabora el proyecto de investigación. 3ª edición. Caracas: B.L Consultores.
Bass L., Clements, P. y Kazman, R (2003) Software Architecture in Practice. SEI Series in Software Engineering. Addison-Wesley,.
Bellé, A y García C., Jaime. (2008). Movilidad Corporativa 2008: el reto de la gestión. IDC. Madrid. España.
Bosch J. (2000) Design & Use of Software Architectures: Adopting and Envolving a Product-Line Approach. Addison-Wesley, 2000.
Canelón R., Gómez, E. y Quintero, G. (2009) b. Construcción de Interfaces dinámicas en aplicaciones móviles utilizando un enfoque DSPL. Cuarto Congreso Colombiano de computación 4CCC. UNAB-UIS. Bucaramanga- Colombia.
Canelón R., Gómez E., y Rivero L. (2009)a. Interfaces dinámicas en dispositivos móviles. Publicado en: Revista “Ciencias al día”. Decanato de ciencias. UCLA. Año 2009.
Canelón R., Losavio F. y Matteo A. (2007). Modeling Quality of adaptative mobile user interfaces. Revista de la facultad de Ingenieria U.C.V Vol 22, N°1, pp 45-59.
97
Canelón R., Losavio F. y Matteo A. (2009) c. Modelo conceptual para modelación de aplicaciones móviles sensibles al contexto. Rev. Fac. Ing. UCV, vol.24, no.2, p.93-103. ISSN 0798-4065.
Canelón Rodolfo. (2010). Un proceso para la ingeniería de dominio basado en calidad de software. Una aplicación al dominio del aprendizaje móvil sensible al contexto. Universidad Central de Venezuela
Cetina C., Trinidad P., Pelechano V. y Ruiz-Cortés A. (2008). An Architectural Discussion on DSPL. 2nd International Workshop on Dynamic Software Product Lines (DSPL08).
Chirinos L., Losavio F., Matteo A. (2004). Identifying Quality-Based Requierements. Informations system Management. Editorial: Auerbach Publications.
Clements, P. y Northrop, L.M. (2001). Software product lines: Practices and Patterns. Addison-Wesley.
Clements, P., Kazman, R., Klein, M. (2002). Evaluating Software Architecture Methods and Case Studies. SEI Series in Software Engineering. Addison-Wesley.
Cota A. (1994). Ingeniería de Software. Soluciones Avanzadas. pp. 5-13
Deng G., Schmidt D. C., Gokhale A., Gray J., Lin Y., y Lenz G. (2008). Evolution in Model-Driven Software Product-line Architectures", Designing Software-Intensive Systems: Methods and Principles, Edited by Dr. Pierre F. Tiako, Idea Group Inc (IGI).
Dewayne E, Perry y Alexander L. Wolf. (1992). Foundations for the study of software architecture. ACM SIGSOFT Software Egineering Notes. 17(4), pp. 40-52
Dey, A.K., Abowd, G.D., Salber, D.A. (2001). A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. Human-Computer Interactions. Pág. 97-166.
Dinkelaker, T., Mitschke, R., Fetzer, K y Mezini, M. (2010). A Dynamic Software Product Line Approach using Aspect Models at Runtime. - First Workshop on Aspect Model. dsal.cl
Duarte, K., Guizzardi, G., de Almeida Falbo, R. (2002). An Ontological Approach to Domain Engineering. Proceedings of the 14th international conference on Software engineering and knowledge engineering. ACM: p. 351-358.
98
Feng Y., y Jun Z. (2001). Wireless Java Programming with Java 2 Micro Edition. L/D 004.438 JAVA FEN. Capítulo 2 y 3.
Flowerdew, J. (1998). Language learning experience in L2 teacher education. Teachers of English to Speakers of Other Languages, Inc.(TESOL)
Frakes W. y Kang K. (2005). Software Reuse Research: Status and Future. IEEE transactions on software engineering, vol. 31 no. 7.
Godwin-Jones, B. (2004). Emerging technologies. Language in action: From webquests to virtual realities. Language Learning & Technology. llt.msu.edu.
Gomaa, H. y Hussein, M. (2004). Dynamic Software Reconfiguration in software product families. Software Product-Family Engineering. Pág. 435-444.
Gomez, O. (2005). Desarrollo de aplicaciones para dispositivos móviles utilizando J2ME. Universidad de Guadalajara.
Griss M. L. (1998). Domain Engineering and Reuse. Hewleet-Packard. Pages 53-54.
Hallsteinsen, S.; Stav, E.; Solberg, A. y Floch, J. (2006). Using product line techniques to build adaptive systems. Software Product Line Conference, 2006 10th International. Pág., 10 pp.–, 21-24.
Helleboogh A., Weyns, D., Schmid, K., Holvoet, T., Schelfthout, K. (2009). Adding Variants on-the-fly: Modeling Meta-Variability in Dynamic Software Product Lines. Institute of Computer Science, University of Hildesheim, Alemania.
Hernández, R.; Fernández, C. y Baptista, P. (2006). Metodología de la Investigación. 4ª edición. México: McGraw-Hill Interamericana, S.A.
Hofmeister, C., Kruchten, P., Nord, R., Obbink, H., Ran, A., America, P. (2007). A general model of software architecture design derived from five industrial approaches. The journal of system and software. Pág. 106-126. Elsevier inc.
IEEE 1471. (2004). IEEE Recommended Practice for Architectural Description of Software. Intensive Systems –Description. 2004.
ISO/IEC 25010 (2009). Software Engineering–Software Product Quality Requirements and Evaluation (SQuaRE) – Quality model and guide.
ISO/IEC 9126-1 (2001). Software Engineering – product quality part 1. Quality model.
99
Jacobson, I. (1998). Applying UML in The Unified Process. Presentación. Rational Software. Presentación disponible en http://www.rational.com/uml como UMLconf.zip
Kadyte, V. (2003). Learning can happen anywhere: a mobile system for language learning. Learning with mobile devices. Citeseer.
Kang K. C., Cohen S. G., Hess J. A., Novak W. E., y Peterson A. S. (1998). Feature-Oriented Domain Analysis (FODA). Feasibility Study. Technical Report CMU/SEI-90-TR21 (ESD-90-TR-222), Software Engineering Institute, Carnegie-Mellon University, Pittsburgh, Pennsylvania 15213, 1990.
Karlsson, E.-A. (1995). Software Reuse: A Holistic Approach. John Wiley & Sons, Ltd., West Sussex, England.
Kloper, E., Square, K y Jenkins, H. (2002). Environmental Detectives:PDA’s as a windows into a virtual simulated world. IEEE Computer Society.
Kruchten, P. (1995). "Architectural Blueprints--The 4+1 View Model of Software Architecture". IEEE Software, Institute of Electrical and Electronics Engineers. November pp. 42-50.
Krueger, C. (2006). Introduction to the Emerging Practice Software Product Line Development. METHODS & TOOLS. Fall 2006 (Volume 14 - number 3).
Lee, J. y Kang, K. C. (2006). A feature-oriented approach to developing dynamically reconfigurable products in product line engineering. Software Product Line Conference. Pág., 131-140.
Losavio, F., Matteo, A., Rahamut, R. (2008). Unifying Quality Standards to Capture Architectural Knowledge for Web Services Domain. DMS 2008: 65-70.
Medvidovic, N., Mikic-Rakic, M., Mehta, N., Malek, R. (2003). Software Architectural support for handheld computing, Computer, pp. 66-73
Mens, T., Wermelinger, M., Ducasse, S., Demeyer, S., Hirschfeld, R., and Jazayeri, M. (2005). Challenges in Software Evolution. Eighth International Workshop on Principles of Software Evolution
Montilva J., Arapé N., y Colmenares J. (2006). Desarrollo de Software Basado en Componentes. Publicado en las Actas del IV Congreso de Automatización y Control (CAC03), Mérida
100
Nah, Ki-Chune., White, P y Sussex, R. (2008). The potencial of using mobile pone to Access the internte for learning EFL Listening Skills within a Korean Context. ReCALL 20 (3)
Oxford, RL., Lavine, RZ., Felkins, G., Hollaway, ME y Saleh, A. (1996). Telling their stories: Language students use diaries and recollection. Language learning strategies around the world: Cross-cultural perspectives.
Palfreyman, D. y Smith, R.C. (2003). Learner autonomy across cultures: Language education perspectives. Palgrave Macmillan. ISBN 1403903549.
Parra, C.; Blanc, X.; Duchien, L.; Pessemier, N. y Carton, P. (2009). CAPucine: A Context-Aware Dynamic Software Product Line. INRIA. Universidad de Lille.
Pincas A. (2004) Using mobile support for use of Greek during the Olympic Games. Proceedings of M-Learn Conference.
Pohl K., Bockle G., y Van der Linden F. (2005). Software Product Line Engineering: Foundations, Principles and Techniques. Springer.
Pressman, R. (2006). Ingeniería de Software: Un enfoque práctico. Mc Graw Hill. Madrid-España.
Reynoso C. (2004). Introducción a la Arquitectura de Software. Universidad de Buenos aires. Argentina.
Ruiz, F y Verdugo, J. (2008). Guía de Uso de SPEM 2 con EPF Composer. IDC. Universidad de Castilla – La Mancha. Escuela Superior de Informática Departamento de Tecnologías y Sistemas de Información. España
Schmidt, R. and Frota, S. (1996). Developing basic conversational ability in a second language: A case study of an adult learner of Portuguese. Journal Talking to learn: Conversation in second language acquisition.
Simard, D.(2004). Using diaries to promote metalinguistic reflection among elementary school students. Journal Language Awareness
Suzuki, R. (2004). Diaries as introspective research tools: From Ashton-Warner to Blogs. Journal TESL-EJ
Tan, TH y Liu TY. (2004). The mobile-based interactive learning environment (MOBILE) and a case study for assisting elementary school English learning. Computer.org
101
Teng Sze Mei. (2003). The Use of Learner Diaries in the Teaching of English as a Second Language. Teaching English to students from China. Singapore Univ Pr
Tomás, J. (2009). Penetración móvil alcanza 97% al cierre del 2008. Conatel.
Trinidad P., Ruiz-Cortés A., y J.P. na. (2007). Mapping feature models onto component models to build dynamic software product lines. International Workshop on Dynamic Software Product Line,.
Trinidad, P.; Benavides, D.; Durán, A.; Ruiz-Cortés, A. y Toro, M. (2008). Automated error analysis for the agilization of feature modeling. Journal of Systems and Software. Pág. 883–896.
Universidad Centroccidental Lisandro Alvarado. UCLA. (2002). Manual para la Presentación de Trabajo de Grado. Barquisimeto. Material Mimeografiado.
Universidad Pedagógica Experimental Libertador. UPEL. (2006). Manual de trabajos de grado de especialización, maestría y tesis doctorales. Cuarta Edición. Barquisimeto, Venezuela.
Universidad Santa María. (2005). Normas para la Elaboración, Presentación y Evaluación de los trabajos especiales de grado. Caracas, Venezuela.
White, J., Schmidt, D.C., Wuchner, E. y Nechypurenko A. (2007). Automating product-line variant selection for mobile devices. Software Product Line Conference. 11th International. Pág 129–140.
Yaguez J. (2007). Arquitecturas y Middleware de Comunicaciones.
Ye H. y Liu H. (2005). Approach to modelling feature variability and dependencies in software product lines. IEE Proceedings online no. 20045007.
102
A. CURRÍCULO VITAE DEL AUTOR Eliemar Pastora Gómez Vargas Cursante del Postgrado en Ciencias de la Computación Mención Ingeniería de software de la Uiversidad Centroccidental “Lisandro Alvarado”. Nació en Barquisimeto, Estado Lara, el 14 de Noviembre de 1982. Realizó estudios de Educación primaria en la Escuela Básica “Los Crepúsculos”, Barquisimeto-Venezuela. Seguidamente cursó sus estudios de Educación Secundaria en el Liceo “Dr. Fortunato Orellana” y la Educación Diversificada en el Liceo “Rafael Villavicencio”, Barquisimeto-Venezuela, donde obtiene el título de Bachiller en Ciencias. Posteriormente inicia su carrera universitaria en la Universidad Centroccidental “Lisandro Alvarado” allí obtiene el título de “Ingeniero en Informática” en el año 2006. Entre tanto, obtiene los certificados de: Operador de Windows 95, Office 97 avalado por el Centro G&T Sistemas C.A en Sep. 2.000, Inglés avalado por FUNDAUC en Ago. 2.001, Mantenimiento de Equipos de Computación avalado por Marchán Computación en Jul. 2.002, Borland Delphi avalado por Centro G&T Sistemas C.A en Ene. 2003, Asistente Administrativo avalado por Proyecto Aprenda Barquisimeto en Jul. 2.004, Electrónica Básica avalado por IUTEPAL – Cabudare en Oct. 2.004, Configuración de Tarjetas Madres avalado por IUTEPAL – Cabudare en Nov. 2.004, Manejo Básico de Sistemas Operativos MSDOS avalado por IUTEPAL – Cabudare en Mar. 2.005, Actualización de partes y pieza del Computador avalado por IUTEPAL – Cabudare en Abr. 2.005, Lenguaje de Programación Java avalado por UCLA – Decanato de Ciencias en Jun. 2.005, Tecnología de Servidores avalado por UCLA – Decanato de Ciencias en Jul. 2.005, Microsoft Project avalado por UCLA – Decanato de Ciencias en Jul. 2.005, Linux Segundo Nivel avalado por UCLA – Decanato de Ciencias en Jul. 2.005, Mantenimiento de Micros avalado por IUTEPAL – Cabudare en Dic. 2.005, Introducción al PHP avalado por Fundacite Lara en Ago. 2.005, PHP Avanzado avalado por Fundacite Lara en Sep. 2.005, Primeros Auxilios avalado por la Brigada de Emergencia Brisas del Aeropuerto en Mar. 2.006, Formación de Equipos y Motivación avalado por Audiconsult S.A en Sep. 2.007 Administración de Base de Datos Libres avalado por Fundacite Lara en Jun. 2008, Gestión del Talento Humano avalado por UNEFA en Nov. 2008. Ha obtenido reconocimientos por la excelencia académica, entre los que se destacan Cuadro de Honor UCLA Lapso 2005 – I Nov. 2006. Cuadro de Honor UCLA Lapso 2004 – II Nov. 2006 Cuadro de Honor UCLA Lapso 2004 – I Sep. 2005. Cuadro de Honor UCLA Lapso 2000– II Sep. 2005 y Por haber obtenido la calificación sobresaliente de 19 y 20 puntos en las siguientes asignaturas: Ingles I, DHP II, DHP III, Contabilidad I, Ingeniería Económica I, Programación No Numérica en la carrera Ingeniería en Informática. Posee experiencia laboral como Desarrollador Web en PROSALAFA desde Sep. 2005 a Feb. 2006, como Desarrollador Web en Audiconsult SA desde Feb. 2006 a Jun. 2007, como Analista Programador en Universidad Centroccidental Lisandro Alvarado desde Jul. 2007 a Dic.2008, como Analista Programador en Fundación Nadbio desde Ene.2009 - Dic. 2009, actualmente se desempeña como jefe del departamento de sistemas de la Fundación Nadbio desde Ene. 2010.