Análisis del Estado del Arte en el desarrollo de Aplicaciones Móviles mediante Desarrollo Dirigido por Modelos. Estevan Gómez, email:
[email protected] Universidad Tecnológica Equinoccial
Métodos secundarios:
Abstract
•
Se pretende realizar un análisis de los diferentes estudios que hay a nivel mundial sobre la aplicabilidad del Desarrollo Dirigido por Modelos en Aplicaciones Móviles.
• •
El Desarrollo de Software Dirigido por Modelos (DSDM) es una propuesta para la construcción de software en la que se les atribuye a los modelos el papel principal de todo el proceso, frente a las propuestas tradicionales basadas en lenguajes de programación, plataformas de objetos y componentes software.
Se aplicarán Métodos Secundarios, los cuales permiten sintetizar la evidencia obtenida en estudios primarios. realizados Revisiones sistemáticas de la literatura (SLRs) Mapeos sistemáticos de la literatura (SMSs)
Introducción El Desarrollo Orientado a Modelos, ofrece el potencial para transformar automáticamente aplicaciones de un alto nivel de abstracción, en sistemas ejecutables.
Los Modelos en diferentes niveles de abstracción surgen con el propósito de agilizar el proceso de construcción de software, lo cual es un movimiento centrado en el uso de modelos en diferentes niveles de abstracción. Se tiene actualmente entre las principales propuestas en este sentido aquellas como: la Arquitectura Dirigida por Modelos y el Desarrollo de Software Dirigido por Modelos (MDA y MDSD, por sus siglas en ingles). En este trabajo se hace una revisión de la literatura a cerca de estas dos propuestas. Describe sus principios fundamentales, trabajo orientado a conformar la fundamentación teórica de las dos propuestas y las principales herramientas que implementan el desarrollo conducido por modelos.
Sobre esta cuestión, Bran Selic (“The Pragmatics of model-Driven Software Development”), argumenta que la tecnología de modelado ha madurado al punto de que puede ofrecer un impulso significativo en todos los aspectos del desarrollo de software. También argumenta que en una creciente área de aplicaciones, se puede generar mucho del código de aplicación, directamente de los modelos. La automatización no quita la necesidad de creatividad. Formaliza las soluciones existentes y eleva el nivel al cual se puede aplicar la creatividad, dando de esta forma a los desarrolladores un impulso. Se debe pensar ahora como se puede producir desarrolladores que piensen en un nivel de abstracción por encima de los lenguajes de programación o tecnología de moda
Palabras Claves: Desarrollo Dirigido por Modelos, MDD, aplicaciones móviles. Desarrollo de software para Móviles.
1
de Aplicaciones móviles construidas bajo MDD? [3] Cómo influiría el MDD en el Desarrollo de Aplicaciones Móviles?
Método De Investigación Planificación de la Revisión
Descripción: Seleccionar los documentos al Desarrollo dirigido por Modelos de tamaño y complejidad similar Asignar las mismas tareas a cada tratamiento Tratar de aliviar tanto como sea posible las amenazas a la validez Si hubiera necesidad de enviar algún tipo de cuestionario para recabar información se debería tomar en cuenta: o Preparar pre-cuestionarios para recopilar la experiencia de los sujetos o Preparar post-cuestionarios para recopilar el feedback de los sujetos o Preparar el material en el lenguaje nativo de los sujetos
DETALLE Se desarrolla una clasificación de la literatura: papers, libros publicaciones y estudios con la finalidad de ver aquellas fuentes que permitan establecer una compararcion de MDD con otros métodos de desarrollo de software y su aplicabilidad para el desarrollo de aplicaciones móviles. Desarrollando la Revisión Realizaremos un estudio piloto para chequear el material Hacer una estimación precisa del tiempo de duración: Aproximadamente 3 semanas en este proceso. Estimular a los sujetos para que participen: Inicialmente por tratarse del analisi preliminar
DESARROLLO PORQUE? La mayoría de la investigación comienza, o debe comenzar con una revisión de la literatura de algún tipo. A menos que una revisión de la literatura es exhaustiva y justa, es de poco valor científico Una revisión sistemática sintetiza el trabajo existente de una manera que sea justa y parece ser justa
1) DIFERENCIA ENTRE MDA Y MDSD Aunque MDA y MDSD son comunidades diferentes comparten el mismo propósito: la utilización de modelos para desarrollar software. Mientras que MDSD se ocupa la utilización de los modelos para el desarrollo de software, MDA se enfoca en definir los estándares para desarrollar software haciendo uso intensivo modelos. Se pudiera decir que MDA es la estandarización de MDSD.
PREGUNTAS DE INVESTIGACION:
La diferencia ente MDA y MDSD ha sido expuesta por diversos autores e investigadores. Mellor [25] plantea que MDA se puede percibir como un conjunto de estándares cuya aplicación concreta es el desarrollo de software dirigido por modelos, y la principal actividad de MDSD es la construcción de herramientas que privilegian el desarrollo mediante la utilización de modelos. Selic [26] afirma que
[1] Puede utilizarse el Paradigma Desarrollo Dirigido por Modelos para el Desarrollo de Aplicaciones Moviles? [2] Que tipos de análisis se han realizado y que permitan el trabajo
2
los métodos y herramientas que soporten tanto a MDA como a MDSD deben especificar transformaciones automáticas entre diversos modelos, diferenciando así los dos términos. Frank [27] plantea que el desarrollo de software guiado por modelos,
2) FUNDAMENTACIÓN TEÓRICA GENERAL MDA y MDSD son enfoques complementarios que usan el modelo como directriz del desarrollo. MDA por ser un conjunto de estándares promovidos por OMG, se caracteriza por tener bases teóricas fuertes, mientras que MDSD por ser una iniciativa en manos de una numerosa comunidad de investigación, se centra prioritariamente en el desarrollo de herramientas que facilitan la automatización del desarrollo.
MDA EN EL CONTEXTO DE ESTÁNDARES DE OMG En este entorno, los modelos independientes de la plataforma que incluyen los estándares de modelado de OMG, se pueden desarrollar utilizando plataformas abiertas o propietarias como CORBA, Java, .NET, XMI/ XML y plataformas basadas en la Web (ver Ilustracion 1). Sin embargo, la tendencia dominante para el modelo dependiente de la plataforma es la utilización de java, debido a los recursos y facilidades de esta plataforma. Adicionalmente, a medida que surgen nuevas tecnologías, MDA desarrolla rápidamente las especificaciones pertinentes, de forma que facilita el proceso de integración. Se concluye que MDA es más que un middleware, ofrece una solución integral y estructurada para la interoperabilidad y portabilidad de aplicaciones en el futuro [29], [30]
tiene que ver con los modelos usados por arquitectos y programadores para alimentar generadores de código, son técnicas que también están bajo el marco de MDSD, pero que no pueden ser correctamente denominadas MDA. Dirk [28] afirma que el desarrollo de software conducido por modelos MDSD, reúne el conjunto de tecnologías que usan los modelos para desarrollar, en consecuencia MDA, es la arquitectura definida por OMG para soportar MDD. En conclusión, aunque MDA y MDSD son enfoques diferentes, los dos privilegian el uso del modelo como 'lenguaje de desarrollo'. MDSD ha existido mucho antes que MDA como práctica de desarrollo y como investigación para generar métodos, técnicas, herramientas y constructos teóricos basados en modelos. MDA por su
De los estándares que conforman el núcleo de MDA, el Common Warehouse Model CWM requiere atención especial ya que proporciona las pautas para la gestión e integración datos, como se muestra en la siguiente sección.
Ilustración 1
parte ha hecho un gran esfuerzo por estandarizar la amplia pero poco uniforme actividad de desarrollar software conducido por Modelos MDSD.
3
3) MODELO COMÚN DE BODEGAJE CWM
XML) y API de acceso para metadatos de bodegaje compartidos (CWM IDL) [35]
Es un estándar de la OMG para bodegas de datos, que define la especificación de modelado de metadatos para objetos relaciónales, no-relacionales, multidimensionales y otros objetos del ambiente de bodega de datos. Abarca el ciclo de vida completo de diseño, construcción y gestión de aplicaciones y el apoyo a la gestión del ciclo de vida [1]
Conducting the review La revisión se ha realizado en parte encontrando algunos elementos de comparación entre los diferentes autores. -
CWM especifica las interfaces que habiiitan el intercambio de metadatos de bodegas de datos e inteligencia de negocios entre artefactos de bodegaje de datos, en ambientes distribuidos heterogéneos, tales como herramientas, plataformas y repositorios [31], [32], [33]
Algunos trabajan con el Paradigma y presentan alguna alternativa Otros generan una teoría a través de otras soluciones ya establecidas En otros aspectos los autores nos ilustran la forma como utilizar y desarrollar aplicaciones móviles aplicando Android.
Consideraciones A fin de poder establecer una clasificación adecuada se considera recomendable clasificar las fuentes de acuerdo a los tipos de temas:
CWM se basa en tres estándares que conforma el núcleo de la arquitectura del repositorio de metadatos de OMG [34].
a) Contextos
• Lenguaje de modeiado unificado (UML). Lenguaje prioritariamente gráfico que permite definir y representar modelos y meta-modelos del sistema, modelos de diseño y modelos de información.
b) Desarrollo dirigido en Modelos c) Aplicaciones Móviles De esa forma se puede estructurar una estrategia que elimine algún material que puede ser irrelevante.
• Faciiidad meta-objeto (MOF). Es un estándar que permite definir modelos de metadatos y modelos de modelos. Provee herramientas con interfaces programables para almacenar y acceder metadatos en un repositorio.
4) MDA para el Desarrollo sensible al contexto La arquitectura Model Driven (MDA) [72] predice que todo lo que se puede modelar. La diferente niveles de abstracción proporcionadas por la MDA son relevantes para diseño de sistemas porque los requisitos de los diferentes sistemas son tratados por diferentes niveles.
• Intercambio de metadatos XML (XMI). Estándar que permite intercambiar metadatos presentados como archivos en formato XML. Una especificación CWM incluye componentes básicos y un conjunto de metamodelos. Los componentes básicos de de CWM se muestran en la figura 2 y son los siguientes: metamodelo CWM, formato de intercambio para metadatos de bodegaje compartidos (CWM DTD), formato de intercambio para el metamodelo (CWM
Para cada nivel hay alguna representación normas formalismo. MOF (Fondo para el Meta-objeto) es el formalismo OMG utilizado para el metametamodelo la representación, la parte 4
superior de la capa de abstracción también llamada capa M3. Para M2 o capa metamodelo, UML es la solución más utilizada OMG para el desarrollo de metamodelos de propósito general , define modelos del mundo real. M0, la capa inferior, se reserva para los casos de aplicación de software o código. Diferentes lenguajes de representación pueden ser creados y aplicar en estos niveles de abstracción para representar conceptos
Concepto de punto de vista empresarial: se centra en el dominio del negocio y el proceso que son la base para el desarrollo del sistema. Las reglas de negocio, procesos, funciones, especificaciones artefactos y las relaciones son algunos de los aspectos tratados por este punto de vista.
Punto de vista computacional: describe los detalles de implementación, como componentes, objetos, sus interacciones e interfaces descripciones.
Hay algunos lenguajes de transformación (QVT de egOMG) también se utilizan para transformar los modelos de nivel más abstracto que el código de aplicación. EDOC-CEPA se basa en el enfoque de MDA y es el formalismo que utilizamos para aplicaciones sensibles al contexto de modelado por sus características inherentes y
Información punto de vista: define la información semántica, representación y limitaciones, generalmente representado en UML. Ingeniería punto de vista se centra en las características distribuidas y proporciona soporte para código de implementación. Sin embargo, no se centra en la plataforma utilizada para la implementación En el punto de vista de la tecnología, se definen las opciones de plataforma de destino y hardware elementos. En nuestra arquitectura se desarrollaron algunos puntos de vista de la definición, la interpretación y la adaptación de las actividades de contexto y sensibles al contexto La arquitectura nombrada como CSOA (Service-Oriented Architecture Contexto sensible al contexto) ofrece un servicio, de contexto, de adaptación, de composición y vistas empresariales.
Ilustración 2
distribuidas por el hecho de que es más cercano a la plataforma de servicios web que facilita las especificaciones de mapeo.
El negocio, Contexto y Composición Vistas se expresan mediante modelos PIM, es decir, estos modelos abstractos plataformas detallan la Vista de Negocio, se basa en la perspectiva de la Empresa EDOC y se centra en la lógica de negocio, funciones y actividades.
(Samyr Vale1, 2013) Propone un metamodelo para Service Oriented Architecture sensible al contexto expresado en EDOC-ECA [76]. EDOC-ECA es MDA apoyó y presentó diferentes conceptos de punto de vista para el desarrollo de software:
5
comportamiento solución en relación con el metamodelo), en esencia, que ha "codificado" el modelo de solución (de forma gratuita). El elemento de aplicación no debe contener ninguna invocación o biblioteca específica de plataforma. Este es el punto clave que hay que entender, si crea un metamodelo sin elementos de implementación y se intenta guardar el comportamiento en el propio metamodelo, es muy probable que no vaya a funcionar bien.
5) Meta Modelos El metamodelo es la arquitectura de la información conceptual que clasifica la información que podemos utilizar para construir soluciones, entender dominios de problemas, y crear prácticas que aseguran que construimos el sistema que debemos construir. La definición de un "modelo de solución" es en realidad un síntoma de por qué los enfoques de modelado no han alcanzado el nivel de atención que se merecen. La forma de modelar el problema puede estar relacionado con la forma en que el modelo de la especificación funcional y sin embargo, no guardan relación con la forma de construir la solución. El modelado es bueno, pero demasiado de él puede resultar difícil conseguir todos los involucrados
Entonces y sólo entonces, usted debe comenzar a entender cómo (y) se puede modelar el dominio del problema y, posiblemente, atarlas con el modelo de solución. Se proponen entonces un enfoque impulsado Ingeniería Modelo exitoso (pasos del 1 al 7):
Es por eso que "se centran en el metamodelo con el que se va a construir la solución". Este es el mayor retorno de la inversión. Se puede utilizarla para crear un modelo de solución, pero que puede resultar demasiado trabajo. Lo que se trata es de tratar de labrarse un camino pragmático a la ingeniería impulsada modelo exitoso, sin prescindir del Modelado.1 Básicamente, lo que yo se propone que si se crea un metamodelo de solución que incluye elementos "aplicación" (que contienen
1
Ilustración 3
6) Problemáticas de la transformación en los enfoques centrados en modelos La transformación de modelos les permite a los desarrolladores construir modelos con la representación del problema y transformarlos sucesivamente hasta llegar a un sistema computacional que funcione. Esta promesa realizada en la mayoría de los
es su de el
http://www.ebpml.org/blog/130.htm
6
recientes enfoques metodológicos potencia enormemente las posibilidades de reutilizar elementos propios del desarrollo de software, como son objetos, componentes, patrones y frameworks (Larman, 2005), para la generación casi automática de aplicaciones de software. Una de las estrategias típicas de transformación se fundamenta en construir un modelo basado en un metamodelo de origen al que se le aplican unas reglas de transformación definidas, y se transforma en un modelo que se basa en un metamodelo destino (Bézivin, 2004).
multimedia, hasta MID (Mobile Internet Devices o dispositivos de acceso a internet), pasando por controladores para el ocio o incluso herramientas médicas de monitorización. Se trata de un chip desarrollado por la empresa Embedded Alley que permite instalar Android en sistemas basados en el chip Au1250, desarrollado por RMI. Concretamente lograron portar el modo de ejecución actual de motor Java que incorpora Android (en lugar de contar con el estándar JME cuenta con una máquina virtual propia, denominada Dalvik) a instrucciones MIPS, de tal forma que sean compatibles con los controladores, por ejemplo, de Nintendo Wii, entre otros”
7) Desarrollo Dirigido por Modelos y Su Aplicación al Desarrollo de Aplicaciones Móviles
Proceso para Generar Aplicaciones Android:
El software para Android está ganando rápidamente cuota de mercado con sus aplicaciones para una variedad de dispositivos como smarthphones, tablets, televisores o sistemas de entretenimiento.[1] La diversidad de los segmentos del mercado, un aumento en el número de nuevos dispositivos y la demanda de diferentes usuarios están obligando a los fabricantes de dispositivos y proveedores de aplicaciones a introducir alta calidad de productos innovadores en plazos más cortos.
El proceso deberá permitir generar aplicaciones Android a partir de la metodología de NDT. NDT define transformaciones que indican cómo conseguir cada modelo a partir de la definición de requisitos, es decir en un primer lugar se define el modelo CIM con especificación de los requisitos, y a continuación se diseña el modelo independiente de la plataforma (PIM). Los modelos de NDT se definen con perfiles UML en la herramienta EA permitiendo modelar las fases de desarrollo en particular el modelo de requisitos, modelo de contenidos, modelo de Navegación y modelo e procesos. Una vez definido el modelo PIM se realizará la transformación hacia el modelo PSM, y posteriormente se realiza una trasformación de modelo a texto.
PC WORLD nos dice2 “A partir de mayo, un nuevo chip permitirá instalar esta plataforma en más tipos de dispositivos personales. La competencia de Android continúa su expansión. Lejos de conformarse con el mercado de los Smartphones, a partir del próximo mes de mayo, un chip embebido en otro tipo de dispositivos personales, permitirá instalar el sistema operativo de Google. Entre estos dispositivos se encontrarían desde reproductores
El estándar de facto del lenguaje de las transformaciones de modelo a texto para su diseño se denomina MOF Model to Text Transformation Lenguage (mof2text). Algunas de las ventajas del lenguaje mof2text es que no sólo permite la
2
http://www.pcworld.com.mx/Articulos/3984.ht m
7
generación de código para muchas plataformas diferentes partiendo de un mismo modelo, sino que además permite la generación automática de cualquier representación textual del modelo.
Tambien se puede utilizar el Framework de NDT Las ventajas de Xtend son una mejor integración con el marco xtext, que sea más flexible, ya que las plantillas y el comportamiento se manejan en los métodos y Xtend utiliza un Java como el lenguaje que ofrece muchas características para facilitar la construcción del generador. Inconvenientes son ningún apoyo para la manipulación de código generado y que utiliza un lenguaje de propósito general que conduce a un marco no estandarizado. La decisión que se debe tomar es la herramienta para desarrollar los generadores. Se tienen dos opciones. Bien podríamos usar Xtend o Acceleo Los beneficios de Acceleo por otro lado son una buena integración en Eclipse y el apoyo de la funcionalidad de desarrollo como la depuración, seguimiento y localización, el apoyo de las regiones protegidas que permiten la manipulación cómoda del código generado, construcción del generador nativo y se aplica del modelo MOF a texto Transformación estándar según lo especificado por el OMG. Inconvenientes de Acceleo son que es más estática ya que se basa plantilla y difíciles de integrar en un entorno modelo de múltiples
MD² - Model-driven Mobile Development El desarrollo del marco MD² consistió básicamente tres pasos. En primer lugar general la arquitectura tiene que ser especificada. Basado en la arquitectura del lenguaje tenía que ser escrito. El lenguaje ofrece, junto a una gramática que los modeladores tienen que cumplir, el metamodelo de modelos de aplicaciones que pueden ser modelados con MD². Se requiere este metamodelo para el tercer paso, que es el desarrollo de los generadores. Para desarrollar los generadores, se optó por un enfoque basado en el prototipo. Esto significa que primero desarrollamos aplicaciones prototípicas directamente para Android y iOS. Estos prototipos deben ser representativos y cumplir con la arquitectura general. Más tarde estos prototipos serán utilizados para desarrollar los generadores. Por lo tanto, primero analiza los prototipos de partes independientes de un determinado modelo y siempre será el mismo. Trasladamos estas partes a las bibliotecas. Las otras partes construyen la base para el desarrollo de los generadores. Tomamos una parte tras otra y las transformamos en código generable mediante la identificación de las piezas en función del modelo y permitir que ellos se generaren basándose en el modelo de entrada.3
Uso Eficiente de Recursos Al mismo tiempo, la reducción de presupuestos destinados al desarrollo y un entorno económico difícil hacen altamente necesario el uso eficiente de los recursos para el desarrollo. Con diseños de productos integrados cada vez más complejos y reducción de los ciclos de vida del producto, el desarrollo eficiente se ha convertido en algo esencial. La aparición del desarrollo dirigido por modelos (MDD) ha hecho posible acelerar el proceso de desarrollo. Con el desarrollo dirigido por modelos (MDD) los ingenieros del software pueden comprender y analizar con mayor claridad las necesidades, definir las
Herramientas de Desarrollo Las Herramientas que se pueden utilizar son Eclipse para el desarrollo de Aplicaciones Android, y Xcode para Aplicaciones iOs . 3
http://wwu-pi.github.io/md2-web/res/MD2Documentation.pdf
8
especificaciones de diseño, generación de casos de prueba del sistema y generación de código automática para la
Generar código Android beneficiándose de la propuesta metodológica NDT con las herramienta de NDT-Suite ayudara a mejorar la productividad, así como el tiempo de comercialización y reduciendo los costes de desarrollo. NDT proporcionará un entorno bastante cómodo, obteniendo de esta forma, una única relación modelocódigo de NDT-Android. El uso de la metodología conectara los requisitos, el diseño y el código además gracias NDT-Suite también se podrá generar automáticamente la documentación y las pruebas
8) Propuesta Metodológica NDT Se basa en un conjunto de metamodelos, que resultan transparentes para el grupo de desarrollo, que da soporte al proceso de desarrollo.
Cuida la trazabilidad de los requisitos desde la captura hasta el análisis, ofreciendo un procesos sistemático de desarrollo basado en transformaciones formales descritas con QVT que lleva hasta la implementación. Al trabajar con UML, es una propuesta que fácilmente puede incorporarse a otros entonos metodológicos, como Métrica. NDT ha tenido y está teniendo una gran aplicabilidad práctica en empresas y proyectos reales. En los últimos años, la metodología NDT ha evolucionado para permitir su uso en entornos prácticos, siendo hoy por hoy una de las mejores propuestas metodológicas para abordar el desarrollo de cualquier proyectos software, y en particular proyectos software orientados a la WEB.4
Esta iniciativa, abre una nueva línea de investigación en el grupo IWT2 (Ingeniería y Web y Testing Temprano) que está alineado con tendencias actuales en el marco internacional de investigación. NDT es hoy en día una metodología de desarrollo reconocida a nivel internacional y también muy aplicada en el mundo empresarial, puesto que ha sido asumida por diferentes empresas.
8.a. Detalles sobre NDT y Android. NDT es una propuesta que sustentada sobre el paradigma de la Ingeniería guiada por modelos 5(MDE) y ofrece un entorno útil y sencillo que se basa en un conjunto de metamodelos, que resultan transparentes para el grupo de desarrollo, que da soporte al proceso.
Ciclo de vida de NDT
8.b. Metodología NDT El proceso de NDT se centra en una detallada fase de ingeniería de requisitos guiada por objetivos, que contempla tanto la captura, como la definición y la verificación de requisitos [3]. El proceso
4
5
http://www.iwt2.org/web/opencms/IWT2/ndt/ ?locale=es
http://www.iwt2.org/web/opencms/IWT2/inde x.html
9
comienza definiendo los objetivos y en base a éstos se describe un proceso por el que se pueden capturar y definir los diferentes requisitos del sistema. Éstos son clasificados y tratados dependiendo de la tipología a la que pertenezcan.
modelo básico de interfaz abstracta. Estos modelos básicos deben ser estudiados por el grupo de analistas y podrán ser modificados si se estima oportuno. Sin embargo, un cambio en alguno de estos modelos puede ser fuente de un error o incongruencia cometida durante la ingeniería de requisitos o puede generar cambios en otros modelos. Por ello, tras los procesos de generación de los modelos básicos, NDT ofrece una guía con todos los cambios que se pueden realizar y en qué medida afectan a otros modelos del sistema o a la propia definición de requisitos.
8.c. División de Requisitos con NDT : Requisitos de almacenamiento de información, de actores funcionales, de interacción y no funcionales. Una vez validados estos requisitos, el proceso de NDT propone generar tres modelos: el modelo conceptual, que representa mediante un diagrama de clases la estructura estática del sistema; el modelo de navegación, que representa mediante un conjunto de diagramas de clases la forma en que se podrá navegar en el sistema; y el modelo de interfaz abstracta, que mediante un conjunto de prototipos evaluables permitirá mostrar cómo se va a interactuar con el sistema.
9) Influencia de Android. El poder de la estructura de aplicaciones de Android que radica en la forma de traducir la Web en aplicaciones móviles [2]. Esto no significa que la plataforma disponga de un potente navegador y que esté limitada a JavaScript y a recursos del lado del servidor, sino que es la base de su funcionamiento y de la interacción del usuario con el dispositivo móvil están enfocados en modelos de navegación. La forma de navegar de un usuario móvil en la plataforma es fundamental para su éxito comercial. Las plataformas que reproducen la experiencia del escritorio en un dispositivo móvil son aceptadas por una parte de los usuarios. Para facilitar la reutilización de código y agilizar el proceso de desarrollo, las aplicaciones Android se basan en componentes.
La característica más destacable del proceso propuesto por NDT es que el paso de especificación de requisitos a estos modelos se hace de una manera sistemática e independiente. Es una manera sistemática porque NDT define algoritmos que indican cómo conseguir cada modelo a partir de la definición de requisitos. Y es independiente porque, a pesar de que existen relaciones entre los modelo, hecho que es imposible de evitar puesto que todos se refieren a un mismo sistema, no es necesario conseguir el modelo conceptual para conseguir el modelo de navegación o el de interfaz abstracta. Desde los requisitos se definen tres procesos que permiten conseguir estos tres modelos. A estos modelos que se consiguen de manera sistemática se les denomina modelos básicos.
Los componentes pueden ser de 4 tipos:
Así se tendrá el modelo básico conceptual, el modelo básico de navegación y el 10
Actividades. Son interfaces visuales esperando alguna acción del usuario. El contenido visual de cada actividad lo proporcionan una serie de objetos derivados de la clase View. Android proporciona muchos de estos objetos prediseñados como botones, selectores, menús. Servicios. Los servicios no tienen interfaz gráfica. Un ejemplo sería la reproducción de una canción. Para una aplicación reproductora
podríamos tener varias actividades para mostrar listas de canciones o un reproductor con botones, pero el usuario esperará que la canción siga sonando aún al salir de la aplicación,(terminar la actividad), por lo que esta aplicación deberá controlar un servicio para que se reproduzca la música. Receptores de Eventos. Estos componentes simplemente están escuchando a que se produzcan determinados eventos (batería baja, cambio del idioma del dispositivo, la descarga de una imagen nueva...) Proveedores de contenidos. Permite que una aplicación ponga ciertos datos a disposición de otras aplicaciones. Además, todas las aplicaciones Android deben tener un fichero AndroidManifest.xmldonde se definan todos los componentes de la aplicación así como los permisos que requiere, o los recursos y librearías que utiliza. NDT define transformaciones que indican cómo: Conseguir cada modelo a partir de la definición de requisitos, es decir en un primer lugar se define el modelo CIM con especificación de los requisitos, y a continuación se diseña el modelo independiente de la plataforma (PIM). Los modelos de NDT se definen con perfiles UML en la herramienta EA permitiendo modelar las fases de desarrollo en particular el modelo de requisitos, modelo de contenidos, modelo de navegación y modelo e procesos. Una vez definido el modelo PIM se realizará la transformación hacia el modelo PSM, y posteriormente se realiza una trasformación de modelo a texto
Ilustración 4
Reportando la Revision: Se realiza la revision de diferenes autores El reúso de software es una de las estrategias que se considera promisoria para que la industria de software pueda enfrentar el reto de desarrollar productos con niveles de calidad y productividad adecuados en un contexto de negocio altamente complejo y dinámico y con acelerados cambios tecnológicos. El uso de plantillas, componentes de granularidad gruesa, patrones de diseño, arquitecturas de referencia, frameworks, entre otros, son mecanismos cada vez más utilizados por los desarrolladores de software.
Importancia de los modelos en MDA A. Encontramos varios conceptos del modelado, como una de las estrategias básicas del desarrollador para entender un problema y proponer una solución, es ampliamente aceptado en la ingeniería de software, mucho antes del surgimiento de MDA. Sin embargo, la aplicación del modelado en la práctica diaria presenta problemas como los enunciados a continuación: a. Los modelos se usan solo como documentación. Los modelos no funcionan como un artefacto activo
11
b.
c.
que contribuya en el proceso de desarrollo. Existen vacíos entre el modelo y la implementación de los sistemas. Los cambios en el modelo no se reflejan en el código y los cambios en el código no se reflejan en los modelos, sólo se genera el código de los modelos la primera vez y nunca se actualiza. No hay una adecuada mezcla de modelos. Vistas desconectadas de un sistema (desconexión horizontal) y grupos de modelos desconectados (desconexión vertical).
maduración, las organizaciones ya están empezando a obtener beneficios reales y los fabricantes están demostrando su interés en esta área, por lo que las herramientas son cada vez mejores. Tal situación ha llevado a que los enfoques centrados en modelos estén siendo utilizados en diversos frentes 5) NDT surge como una alternativa válida a tomar en cuenta para la automatización de transformaciones, ya que tiene una suite muy completa que puede ser usada en futuras investigaciones.
Referencias [1] Atkinson, R.C. & Shiffrin, R.M. (1968). Human memory: A proposed system and its control processes. En Spence, K.W. & Spence, J.T. (Eds.) The psychology of learning and motivation, 2 (pp. 89–195). New York: Academic Press. [2] Dey, A.K. & Abowd,G.D (1999). Towards a better understanding of context and contextawareness. Technical report,Georgia Institute of Technology. [3] Gardner, H. (2001). La inteligencia reformulada. Las inteligencias múltiples en el siglo XXI. Caps.3, 6 y 7. pp.39-56, 89-124. Barcelona: Paidos. [4] Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63 (2), 81-97. [5] Schunk, D. H. (1997). Procesamiento de la Información. En Teorías del aprendizaje (pp. 143189).Segunda Edición. México: Prentice Hall Hispanoamericana. [6] Singhal, M.& Shukla (2012), A. Implementation of Location based Services in Android using GPS and Web Services. IJCSI International Journal of Computer Science Issues, 9 (2).
Conclusiones 1) En el desarrollo de SLR ha sido importante la clasificación y ordenamiento de las fuentes , así como desarrollar el proceso de una manera sistemática, de forma tal que nos permita: a) Realizar una revisión adecuada del Estado del Arte b) Establecer una respuesta adecuada a las preguntas de investigación c) Lograr conclusiones que sean adecuadas para el trabajo 2) Sera necesario escoger la Herramienta para poder lograr un desarrollo eficiente y que permita la utilización del Paradigma de Desarrollo Dirigido por Modelos. 2) Para la creación de las aplicaciones Android será indispensable trabajar con la definición de: Actividades , Servicios y Receptores de Eventos 3) Para el desarrollo de un Nuevo Proyecto será necesario definir un equipo de trabajo que permita trabajar paralelamente en Aplicaciones Android, como en iOs. 4) A pesar de que los enfoques centrados en modelos se encuentran aún en fase de 12
[7] LAUDON, Kennet and LAUDON, Jane. Sistemas de información Gerencial: Administración de la Empresa Digital. Pearson Ed. 2008. [8] ROSS, Jeanne; WEILL, Peter; ROBERTSON, David. Enterprise architecture as strategy: creating a foundation for business execution. Harvard Business Scholl Press, 2010 [9] OMG Object Management Group. Model-Driven Architecture Home Page, 2011 (en línea), http:// vwvw.omg.org/mda/index.htm [10]DEN HAAN, J. 8 Reasons Why ModelDriven Approaches (will) Fail [documento en línea]. 2008. http://www.infoq.com/articles/8reasons-why-MDE-fails [consulta: 06072010] [ Links ] [11]DE LARA, J. AToM3 A Tool for Multiformalism Meta-Modelling [documento en línea]. 2006. http://atom3.cs.mcgill.ca/ [consulta: 672010] [ Links ]. [12]DREY, Z. et al. Kermeta language Reference manual. s. l.: IRISA, 2010. [ Links ] [13]OBJECT MANAGEMENT GROUP. Meta Object Facility (MOF) Core Specification v2.0. [documento en línea]. 2006. http://www.omg.org/spec/ MOF/2.0/PDF/ [consulta: 06-07-2010] [ Links ]. [14]QUINTERO, J. y PÉREZ, J. Estrategias para la definición de una técnica de modelado para arquitecturas de referencia. Memorias del XII Workshop IDEAS, 2009. [ Links ] [15]THE ECLIPSE FOUNDATION. ATL User Guide [documento en línea]. 2006. http://wiki. eclipse.org/ATL/User_Guide [consulta: 06072010] [ Links
13
