Prueba Velneo Gratis

Te ofrecemos todo el poder de Velneo durante 1 mes para desarrollar la aplicación que tu empresa necesita.

Saber más
Thank you! Check your email for confirmation.

InDeep multiplataforma V7

INTRODUCCIÓNDurante la vConference celebrada en Enero del presente año, en la que se presentó el nuevo producto V7, se hizo especial hincapié en la multiplataforma, presentándola como una de las características claves del nuevo producto. La multiplataforma es la clave del concepto, de la implementación, del diseño, del marketing y en definitiva del éxito de V7.El presente documento pretende mostrar los elementos clave, tanto tecnológicos como de arquitectura, que dotan a V7 de esta característica esencial y tan esperada: la posibilidad de crear aplicaciones que puedan ser ejecutadas sobre distintas plataformas sin que el desarrollador tenga que emplear ni una sola línea de código en ello.MULTIPLATAFORMA: ¿DE QUÉ?Al ser la plataforma Velneo un "conjunto de aplicaciones" diseñadas para "desarrollar y ejecutar otras aplicaciones" el concepto de multiplataforma debe estar adecuadamente definido en todos sus posibles aspectos.Lo que se va a portar a otros sistemas son los propios ejecutables que conforman la plataforma Velneo V7 (vServer, vClient, vDevelop …). Habrá una serie de versiones de cada uno de estos ejecutables, y cada conjunto de ellos permitirá utilizar las funcionalidades de V7 en una serie de combinaciones de sistema / hardware.Por su parte las aplicaciones desarrolladas usando V7 son multiplataforma "per se", ya que podría decirse que realmente son otros (vServer, vClient…) los que interactúan con el sistema y el hardware. Esto, además de conseguir que las aplicaciones desarrolladas con V7 sean multiplataforma, sin que los desarrolladores tengan ni siquiera que pensar en ello, permite que sean ínter operables también de forma transparente; esto quiere decir que el conjunto de archivos que constituyen una aplicación desarrollada con V7 (el equivalente de los antiguos archivos ".map") es único, pudiendo obtenerse con una cualquiera de las versiones de vDevelop para distintas plataformas, ponerse a servir con vServer en cualquier otra plataforma distinta o igual a la anterior, y accederse con distintos vClients desde todas las plataformas soportadas a la vez.MULTIPLATAFORMA: ¿CÓMO?La necesidad de la multiplataforma es inherente a los sistemas de la información desde el propio nacimiento de la informática. Podemos considerar que existen tres grandes aproximaciones a la resolución de esta necesidad:

  • a) Programación múltiple: programar y mantener código separado para cada plataforma que se desee soportar. Solución directa, sencilla y de buen rendimiento. Problemas principales: complejidad en el desarrollo (debemos enfrentarnos a las particularidades de todos los sistemas), complejidad del mantenimiento y, sobre todo, pérdida de unicidad del código, ya que inevitablemente irán apareciendo aspectos particulares que en un sistema se resuelven de una manera y en otros de otro, y que a lo largo de las sucesivas versiones irán produciendo código cada vez más distinto entre las distintas plataformas.
  • b) Programación virtual: programar para un único entorno hardware / software abstracto: máquina virtual. Nuestro código estará soportado en todas aquellas plataformas que implementen esta máquina virtual. Solución elegante y fácil de mantener e implementar. Problema principal: pérdida muy acusada de rendimiento. A esto se añade el hecho de que los desarrolladores están restringidos al uso exclusivo de los recursos que la máquina virtual pone a su disposición, y a hacerlo con las herramientas, y de la manera, que los desarrolladores de la máquina virtual decidan. El ejemplo clásico de máquina virtual es Java, pero el .NET framework de Microsoft también se acoge a esta filosofía, estando de hecho pensado para poder portar los desarrollos elaborados usando .NET a las diversas plataformas soportadas por Microsoft (x86, 64 bits, equipos con Windows CE, equipos con XP embebed…) sin "casi" cambiar el código.
  • c) Programación dividida: separar en programación la funcionalidad que "deseamos" implementar de la que "necesitamos" implementar. La que deseamos implementar, por regla general, no estará atada a ningún hardware ni sistema en concreto y conceptualmente será portable a cualquier sistema. La que necesitamos implementar incluye la interacción con el hardware y con el sistema. Para esta última, imprescindible pero que no es la clave del valor añadido de nuestra aplicación, se buscan soluciones externas de alta garantía y rendimiento que soporten la multiplataforma. Evidentemente la solución escogida afectará a la manera en que implementemos nuestra funcionalidad propia. Se trata de una solución de compromiso inteligente entre las dos anteriores, ya que tiene sus dos ventajas principales (obtenemos aplicaciones finales que interactúan directamente con cada sistema, y externalizamos el problema de la ejecución en otros sistemas y hardware), sin sus dos inconvenientes fundamentales (no se pierde la unicidad del código y no hay merma en el rendimiento).

Esta tercera vía es la que se ha seguido en el desarrollo de V7. El elemento crítico en este tipo de implementación es, por supuesto, la elección de la solución externa para la portabilidad a múltiples plataformas. Tras analizar muchas de las soluciones existentes, tanto a nivel de arquitectura como a nivel de implementación, se ha decidido finalmente utilizar el framework de desarrollo para C++ de QT, perteneciente a la empresa Trolltech, y usada entre otros por HP, IBM, Siemens y la NASA.MULTIPLATAFORMA: ARQUITECTURALa arquitectura de desarrollo surgida del uso de QT como framework de trabajo es la siguiente:El código desarrollado en C++ hace uso intensivo la API de QT, allá donde las aplicaciones clásicas harían uso de frameworks específicos para Windows (como MFC) o Linux (Xt, Motif, Athena…). De esta manera se obtiene un código completo unificado en todas las plataformas soportadas, ya que la API de QT es única para todos ellos, e incluye todo el interfaz gráfico y de comunicación entre procesos. De hecho es la propia API de QT la que vincula en tiempo de diseño las funciones apropiadas de las API de bajo nivel de cada plataforma (API de Win32, Xlib y Carbon). Esto también nos asegura un elevado rendimiento en las aplicaciones desarrolladas con V7, ya que entre nuestro código y la ejecución del mismo por parte del sistema operativo sólo hay una capa intermedia: la API nativa de cada sistema. La arquitecturas tradicionales para conseguir la multiplataforma hacen uso de al menos dos capas intermedias, ya que las APIs que ofrecen no se comunican directamente con las APIs de bajo nivel de cada sistema, sino que lo hacen con uno o varios frameworks de cada sistema (por ejemplo, en lugar de comunicarse con la API nativa de Windows o con Xlib, se comunican previamente con MFC o con Motif).En cuanto a la arquitectura de ejecución de la plataforma, que es a la que realmente están sujetas las aplicaciones desarrolladas por V7, responde al siguiente esquema, derivado del anterior al tener en cuenta las características especiales de QT en cuanto a disposición del framework como librerías:Lo que este arquitectura implica es que una vez que tenemos en uso los distintos ejecutables que componen la plataforma V7 para cada sistema, la ejecución de los mismos es directa: el ejecutable de V7, basado en QT, obtenido para cada sistema, interactúa directamente con la API de bajo nivel de dicho sistema, de la misma manera que un ejecutable programado únicamente para ese sistema haría.El uso de QT es transparente para el usuario de los ejecutables que componen la plataforma V7 (los desarrolladores de V7), y por supuesto para los usuarios finales de las aplicaciones desarrolladas con V7. Sin embargo existen una serie de diferencias estructurales muy importantes que es interesante resaltar. Dos son los aspectos fundamentales, relacionados con la multiplataforma, en que el uso de QT hace diferente a V7 de otras aplicaciones estándar:Estructura de clases: la API de QT proporciona un conjunto jerárquico de clases de las que se derivan todos los demás objetos y propiedades usados en el desarrollo de V7. Este conjunto es el que limita el propio concepto de multiplataforma: para aquellos elementos no contemplados por ninguna de estas clases el soporte en los distintos sistemas debe ser programado específicamente.Signals and slots: el mecanismo de comunicación entre procesos típico de las aplicaciones gráficas desarrolladas para entornos Windows (mecanismo de eventos) no es portable a otros sistemas; es por esto motivo que QT implementa un sistema propio denominado "Signals and slots". QT se ocupa de la implementación a bajo nivel de este modo de comunicación dentro de cada plataforma soportada.MULTIPLATAFORMA: LAS EXCEPCIONESLas limitaciones comentadas en el uso de la jerarquía de clases propia de QT se traducen en la posibilidad de que ciertas características, para las cuales QT no brinda soporte, puedan estar soportadas desde Velneo en algunas plataformas y en otras no. Por ejemplo, el acceso al puerto serie no está soportado por QT. La tecnología Velneo implementa, en la V7, el acceso al puerto serie bajo sistemas en plataformas Windows x86; es muy posible que también para sistemas UNIX POSIX-compatibles (Linux, IRIX, AIX…) y para sistemas MacOS X (tanto Power PC como Intel) se ofrezca este soporte para acceder al puerto serie, aunque aún no está decidido si en la V7 o en alguna revisión posterior.Aquellas limitaciones de QT en la portabilidad a otros sistemas / arquitecturas que la propia tecnología Velneo decida no solucionar en sus versiones comerciales, podrían ser resueltas mediante el uso de plugins o de otros componentes externos desarrollados por los propios usuarios.MULTIPLATAFORMA : ¿DÓNDE ?En cuanto a los sistemas soportados estos, lógicamente, estarán definidos, en primera instancia, por aquellos que sean soportados por QT en cada momento.Plataformas soportadas hoy en día, con las limitaciones mencionadas:

  • i)Windows: las diferentes versiones de Windows, incluyendo Windows Vista y Windows para 64 bits.
  • ii) Linux estándar como binario (se paquetizará sólo para las principales distribuciones: Debian, Red Hat, Suse…)
  • iii) Múltiples Unix: FreeBSD, Solaris / SUN, AIX, HP-UX, IRIX…
  • iv) Mac tanto sobre Power PC como sobre Intel.
Regístrate ahora y nuestro equipo se pondrá en contacto muy pronto