ES2877195T3 - Despliegue de aplicaciones - Google Patents

Despliegue de aplicaciones Download PDF

Info

Publication number
ES2877195T3
ES2877195T3 ES19174168T ES19174168T ES2877195T3 ES 2877195 T3 ES2877195 T3 ES 2877195T3 ES 19174168 T ES19174168 T ES 19174168T ES 19174168 T ES19174168 T ES 19174168T ES 2877195 T3 ES2877195 T3 ES 2877195T3
Authority
ES
Spain
Prior art keywords
code
additional
class
package
definition
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES19174168T
Other languages
English (en)
Inventor
Bruno Claude Jean-Marie Jouhier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sage SAS
Original Assignee
Sage SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sage SAS filed Critical Sage SAS
Application granted granted Critical
Publication of ES2877195T3 publication Critical patent/ES2877195T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/51—Source to source
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G06F9/44526—Plug-ins; Add-ons
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/31—Programming languages or programming paradigms
    • G06F8/315—Object-oriented languages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/72—Code refactoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Devices For Executing Special Programs (AREA)
  • Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)

Abstract

Un método para desplegar una aplicación que comprende: publicar un primer paquete de código en un registro de paquetes; publicar uno o más paquetes de código adicionales en el registro de paquetes; ensamblar el código fuente de la aplicación mediante la combinación del primer paquete de código con uno o más de los paquetes de código adicionales del registro del paquete según las dependencias especificadas en un archivo de manifiesto de la aplicación, en donde el primer paquete de código comprende código que especifica una primera definición de una clase y al menos uno de los uno o más paquetes de código adicional comprende código que especifica una definición adicional de la clase, en donde la definición adicional de la clase comprende: fusión de prototipos de modo que en la compilación la primera definición de la clase y la definición adicional de la clase se carguen como una sola clase, en donde la fusión de prototipos comprende el uso de una función decoradora para incorporar, tras la carga, el código que especifica la primera definición de la clase con el código que especifica la definición adicional de la clase, y aumento de módulo de modo que la primera y las definiciones adicionales de la clase sean tratadas como una sola clase fusionada por las herramientas de desarrollo, en donde el aumento de módulo comprende el uso de una instrucción de "declare module" de TypeScript; comprendiendo el método además: escribir el primer paquete de código y uno o más paquetes de código adicional en TypeScript, donde el primer paquete de código y el uno o más paquetes de código adicionales se transpilan a JavaScript antes de publicarse en el registro de paquetes.

Description

DESCRIPCIÓN
Despliegue de aplicaciones
Campo técnico
La presente invención se refiere a sistemas y métodos para desplegar aplicaciones. En particular, pero no exclusivamente, las realizaciones de la presente invención se refieren a técnicas para desplegar aplicaciones extensibles desarrolladas por múltiples desarrolladores independientes.
Antecedentes
Cada vez más, es deseable desarrollar aplicaciones de software modernas de clase empresarial para que sean "extensibles". Esto significa que se crean de tal manera que se puedan modificar/ampliar para satisfacer las necesidades particulares de diferentes usuarios finales. Esta modificación generalmente se logra al incorporar en el "código base" de la aplicación (el software que define la funcionalidad principal de la aplicación) un código "adicional" que modifica o extiende la funcionalidad principal de la aplicación. El desarrollo extensible significa que diferentes instancias de la aplicación se pueden personalizar e implementar fácilmente para diferentes usuarios.
Por lo general, para aplicaciones grandes y complejas, se pueden usar varias secciones de código adicional. Por lo general, diferentes terceros desarrolladores desarrollan diferentes secciones de código complementario.
Por consiguiente, al desarrollar y desplegar dichas aplicaciones, se suelen emplear técnicas de desarrollo "desacopladas" mediante las cuales se desarrollan diferentes secciones de código adicional por separado del código base y diferentes aplicaciones, que comprenden diferentes selecciones de código adicional, se ensamblan y despliegan de forma independiente entre sí.
Las técnicas modernas de desarrollo de software, como la compilación "en tiempo de ejecución", mediante la cual el código se carga y compila durante la implementación, permiten que el desarrollo desacoplado se lleve a cabo de manera fácil y conveniente.
Al desarrollar aplicaciones grandes y complejas, particularmente aplicaciones que comprenden código desarrollado por varias partes diferentes, es importante reducir el riesgo de que surjan conflictos entre el código base y el código desarrollado posteriormente (por ejemplo, código adicional). Este riesgo es generalmente mayor cuantas más secciones de código adicional se utilizan en una aplicación desplegada y más frecuentemente se actualizan las secciones de código adicional y el código base.
Para mejorar la productividad, facilitar la autodocumentación, mejorar la productividad y reducir la posibilidad de que surjan conflictos, el código base y el código adicional se pueden escribir mediante el uso de un lenguaje escrito estáticamente como C#. La escritura estática, mediante la cual se verifica la escritura de variables como parte del proceso de compilación, reduce la posibilidad de que los errores de tipo en el código de la aplicación causen errores en tiempo de ejecución cuando se despliega la aplicación.
Sin embargo, el uso de un lenguaje escrito de forma estática impone restricciones en la forma en que se desarrolla el código. Por ejemplo, a menudo es útil que la funcionalidad especificada en una clase en el código base se extienda en el código adicional.
Las funciones de codificación de software, como las "clases parciales", están disponibles en lenguajes como C#, lo que permite que las clases definidas en una sección de código se amplíen en otra sección de código.
Sin embargo, en lenguajes como C#, todo el código que contribuye a una clase determinada debe compilarse y vincularse en un solo ensamblado. Esta restricción hace que el desarrollo de código en un entorno de desarrollo desacoplado, donde el código base y el código complementario se desarrollen idealmente de forma independiente entre sí, sea más difícil.
Sería deseable proporcionar técnicas que aprovechen los beneficios de la escritura estática al tiempo que reduzcan las restricciones que la escritura estática normalmente impone al desarrollo de software desacoplado.
Es un objetivo de ciertas realizaciones de la invención abordar este deseo.
El documento "Anonymous: 'Decorator pattern - Wikipedia', 10 de mayo de 2018 (10-05-2018), XP055628319, recuperado de Internet: URL:https://en.wikipedia.org/w/index.php?title=Decorator_pattern&oldid=840551181 [recuperado el 02-10-2019]" describe un conocimiento general común sobre el "patrón decorador".
El documento US 2002/178435 A1 (ALLISON DAVID S [EE.UU.]) 28 de noviembre de 2002 (28-11-2002) describe la extensión de un elemento de programa (por ejemplo, función, clase, enumeración) incluido en el código fuente escrito en un lenguaje de programación tipado dinámicamente y publicado en un repositorio compartido sin alterar el código fuente.
Compendio de la invención
La invención se define en las reivindicaciones independientes adjuntas, las realizaciones preferidas se definen en las reivindicaciones dependientes adjuntas.
Según ciertas realizaciones de la invención, se proporciona una técnica que mejora la forma en que se desarrolla una aplicación extensible en un entorno de desarrollo desacoplado. La técnica permite que la característica útil de las "clases parciales" esté disponible para su uso en aplicaciones que se ensamblan mediante un administrador de paquetes. Más específicamente, las clases parciales se pueden implementar en paquetes de código desarrollados de forma independiente, mientras se escriben en un lenguaje de tipado estático (TypeScript) que no admite clases parciales de forma nativa.
Específicamente, la técnica permite que una clase se defina parcialmente en un paquete de código base y luego se extienda en un paquete de código adicional al tiempo que permite que el desarrollo del paquete de código adicional se lleve a cabo independientemente del desarrollo del paquete de código base. Desde la perspectiva de un desarrollador que desarrolla un paquete de código adicional, la clase parece estar extendida (por ejemplo, desde un editor de código), mientras que la definición de la clase en el paquete de código base no se ve afectada. Además, esta flexibilidad de desarrollo se proporciona en un entorno de desarrollo de tipo estático cuyo uso reduce la probabilidad de que surjan conflictos entre paquetes desarrollados por separado. El uso de la escritura estática tiene otras ventajas, como la detección temprana de errores de codificación, la mejora de la función de autocompletado en los editores de código y la facilidad de refactorización del código.
De manera ventajosa, la presente técnica puede implementarse en virtud de modificaciones menores a la definición de clase en el paquete de código adicional.
En determinadas realizaciones, el paquete de código base y el paquete de código adicional se escriben en TypeScript antes de transpilarse a JavaScript. Al combinar TypeScript con una técnica para implementar clases parciales, se proporciona ventajosamente un modelo de extensibilidad bien desacoplado donde los paquetes de código adicional se pueden usar muy fácilmente para personalizar las clases existentes en un entorno "seguro" para los desarrolladores en virtud del hecho de que TypeScript se escribe estáticamente.
C# es un lenguaje convencional de tipo estático que admite clases parciales. Sin embargo, C# no permite que las clases parciales se extiendan a través de los límites del paquete de código. Específicamente, C# no permite que una clase definida en un paquete de código base publicado en un repositorio de paquetes se defina adicionalmente (amplíe) en un paquete de código adicional también publicado en el repositorio de paquetes.
Otros lenguajes que admiten clases parciales (por ejemplo, Ruby) normalmente no se escriben estáticamente. En las reivindicaciones se definen varias características y aspectos adicionales de la invención.
Breve descripción de los dibujos
Las realizaciones de la presente invención se describirán ahora a modo de ejemplo únicamente con referencia a los dibujos adjuntos, en donde las piezas similares se proporcionan con los números de referencia correspondientes y en donde:
la figura 1 proporciona un diagrama esquemático de un entorno de desarrollo de aplicaciones;
la Figura 2 proporciona un diagrama esquemático simplificado que proporciona una representación simplificada de un sistema para ensamblar y compilar código de aplicación mediante el uso de un administrador de paquetes y para implementar una instancia de la aplicación en un servidor de aplicaciones;
la figura 3 proporciona un ejemplo de uso de una clase parcial según el ejemplo de la invención;
la figura 4 proporciona un diagrama de flujo de un método según realizaciones de la invención, y
la figura 5 proporciona un diagrama esquemático simplificado de un sistema para implementar una técnica según ciertas realizaciones de la invención.
Descripción detallada
La Figura 1 proporciona un diagrama esquemático que muestra de forma simplificada la forma en que se desarrollan e implementan las instancias de una aplicación de software de clase empresarial moderno para múltiples usuarios diferentes.
Un desarrollador de aplicaciones 101 desarrolla y publica los recursos (por ejemplo, código de software y bibliotecas de datos) asociados con la aplicación en una "plataforma en la nube" 102. Estos recursos pueden denominarse "código base" de la aplicación, ya que proporcionan la funcionalidad principal asociada con la aplicación.
Los desarrolladores externos 103, 104, 105 desarrollan recursos "adicionales" (por ejemplo, código de software y bibliotecas de datos adicionales) que amplían u optimizan la aplicación para usuarios particulares. Por ejemplo, el código base puede estar relacionado con el software de contabilidad y un recurso adicional desarrollado por el primero de los terceros puede proporcionar un código de software o bibliotecas de datos adicionales que optimizan la aplicación de contabilidad para los usuarios que usan la aplicación de contabilidad en un entorno minorista. Otro recurso adicional puede proporcionar software o bibliotecas de datos adicionales que optimizan la aplicación de contabilidad para los usuarios que utilizan la aplicación de contabilidad en un entorno de fabricación. Otro recurso adicional puede proporcionar software y bibliotecas de datos adicionales que se relacionan con las prácticas contables en un país o jurisdicción en particular. Los desarrolladores externos 103, 104, 105 también publican los recursos adicionales en la plataforma en la nube 102.
Los usuarios de la aplicación 106, 107, 108 descargan el código base proporcionado por el desarrollador de la aplicación 101 junto con los recursos adicionales apropiados proporcionados por los desarrolladores externos 103, 104, 105 y ensamblan y compilan una versión de la aplicación según sus requisitos. Algunos usuarios de la aplicación pueden ensamblar una versión de la aplicación que incluye el código base y los recursos adicionales de varios desarrolladores externos. Además, el código base y los recursos adicionales pueden depender de recursos de otras fuentes. Por consiguiente, cualquier despliegue dado de la aplicación puede comprender códigos de software y bibliotecas de datos de múltiples fuentes diferentes y que normalmente se pueden haber desarrollado de forma independiente.
Para gestionar el desarrollo y el despliegue de dichas aplicaciones, se puede utilizar un administrador de paquetes. Un administrador de paquetes es una herramienta que permite almacenar diferentes componentes ("paquetes") de una aplicación en un repositorio central (el registro de paquetes) y luego reunirlos (ensamblarlos) para crear un código fuente que se puede compilar para proporcionar instancias de la solicitud. El administrador de paquetes gestiona las "dependencias", p. ej. rastrea qué paquetes dependen de otros paquetes para funcionar correctamente.
La figura 2 proporciona un diagrama esquemático simplificado que proporciona una representación simplificada de un sistema para ensamblar y compilar código de aplicación mediante el uso de un administrador de paquetes y para implementar una instancia de la aplicación en un servidor de aplicaciones.
Se proporciona un registro de paquetes 201. Según las técnicas convencionales, los paquetes de códigos relacionados con una aplicación se cargan y almacenan en el registro de paquetes 201.
En el registro de paquetes 201 se almacena un paquete de código base 202 que comprende datos que proporcionan el código base de una aplicación. El paquete de código base 202 incluye un archivo de manifiesto de dependencias 203 que especifica recursos (por ejemplo, archivos de código o datos) de otros paquetes de los que depende el código base, es decir, datos de otros paquetes que deben incluirse con el código base para que el código base se compile con éxito para formar el código de la aplicación.
También se almacena en el registro de paquetes 201 un primer paquete de código adicional 204 y un segundo paquete de código adicional 205. El primer y segundo paquetes de código adicional comprenden datos que proporcionan un código adicional que se agregará al código base para producir una versión del código de la aplicación que se va a compilar. Este paquete de código adicional comprende código que normalmente amplía la funcionalidad del código en el paquete de código base. Normalmente, el paquete de código adicional se puede desarrollar (escribir) y probar por separado del paquete de código base.
El primer paquete de código adicional 204 comprende un archivo de manifiesto de dependencias 206 que especifica recursos (por ejemplo, archivos de código o datos) de otros paquetes de los que depende el código complementario del primer paquete de código adicional 204. De manera similar, el segundo paquete de código adicional 205 comprende un archivo de manifiesto de dependencias 207 que especifica recursos (por ejemplo, archivos de código o datos) de otros paquetes de los que depende el código complementario del segundo paquete de código adicional 205.
El sistema comprende además un administrador de paquetes 209 que está adaptado para ensamblar el código de la aplicación a partir del código y los recursos en varios paquetes almacenados en el registro de paquetes. El administrador de paquetes 209 lee un archivo de manifiesto de la aplicación 210 que especifica las dependencias de la aplicación (por ejemplo, los paquetes de código complementario que deben incluirse con el código base para que la aplicación se compile según los requisitos del usuario).
El código JavaScript ensamblado por el administrador de paquetes 209 según el archivo de manifiesto de la aplicación 210 es recibido por un servidor 212 dispuesto para ejecutar la aplicación. El servidor 212 incluye un motor 213 que recibe, carga y compila el código JavaScript del administrador de paquetes 209. Esta compilación es una compilación "en tiempo de ejecución" (JIT) que se realiza mientras se carga el código JavaScript.
Muchos lenguajes de programación informáticos modernos orientados a objetos admiten la característica de "clases" que definen una plantilla para crear "objetos".
Por lo general, la definición de una clase es autónoma dentro de un fragmento de código fuente determinado. Sin embargo, en ciertos ejemplos, se pueden utilizar "clases parciales". Una clase parcial es una clase que se define en dos o más lugares (por ejemplo, en diferentes partes de un código fuente o en más de un archivo). Mediante el uso de clases parciales, se reúnen múltiples definiciones de clases en tiempo de compilación y el compilador se adapta para convertir las múltiples definiciones de clases en una sola clase.
Con referencia al entorno de desarrollo descrito con referencia a la figura 2, para soportar la extensibilidad y el desarrollo desacoplado, es deseable que una clase definida en el paquete de código base pueda extenderse en los diversos paquetes de código complementario.
Sin embargo, el uso de lenguajes escritos estáticamente como C# es difícil de lograr porque la escritura estática de C# requiere que una definición de clase se compile y se vincule en un solo ensamblado. Es decir, no es posible definir la misma clase en diferentes paquetes.
Según ciertos ejemplos de la invención, se proporciona una técnica que permite utilizar un lenguaje de escritura estática, específicamente TypeScript, para permitir la implementación de clases parciales a través de los límites del paquete. TypeScript no admite clases parciales de forma nativa, sin embargo, según ciertos ejemplos de la invención, se ha reconocido que ciertas características disponibles al escribir código en TypeScript se pueden usar para implementar una característica que es efectivamente equivalente a la característica de clases parciales proporcionada por otros lenguajes escritos estáticamente como C#. Además, debido a la vinculación tardía del código escrito en TypeScript y, a diferencia de C#, se puede definir una sola clase en más de un paquete de código. Por otro lado, a diferencia de otros lenguajes en donde las clases parciales pueden estar disponibles, pero no están escritas estáticamente (por ejemplo, Ruby), la escritura estática se puede conservar durante el desarrollo.
Por lo tanto, según ciertos ejemplos de la invención, con referencia a la figura 2, el paquete 202 de código base puede contener datos de código que definan una clase y uno de los paquetes de código adicional, por ejemplo, el primer paquete de código adicional 204 puede incluir datos de código que especifiquen aspectos adicionales de esa clase.
El código adicional de definición de clase en el primer paquete de código adicional 204 se puede desarrollar e implementar independientemente del paquete de código base 202. Cuando el motor de compilación carga y compila el código de la aplicación, los aspectos de la clase definida en el primer y segundo paquete adicional se compilan como si fueran una sola clase.
Una técnica según ciertos ejemplos de la invención se describe adicionalmente con referencia a la figura 3.
La figura 3 representa parte del contenido de un repositorio de paquetes del tipo descrito con referencia a la figura 2. Específicamente, el repositorio de paquetes incluye un paquete de código base A 301 que incluye datos de código 302 que proporcionan código base para una aplicación y un archivo de manifiesto de dependencias 303 El código base 302 del paquete de código base A 301 incluye datos de código de definición de clase 304 que proporcionan una definición de la Clase ABC 304.
El registro de paquetes incluye además el paquete de código adicional B 305 que incluye datos de código que proporcionan el código adicional 306 para ampliar la funcionalidad de la aplicación, y un archivo de manifiesto de dependencias 307. El código adicional especifica la funcionalidad adicional que se incluirá de forma selectiva en instancias de la aplicación. Los datos de código 308 incluyen datos de código de definición de clase 308 que proporcionan una definición adicional de la Clase ABC 304.
La figura 3 muestra además un archivo de manifiesto de la aplicación 309 que incluye el código de dependencias de la aplicación 310 que especifica las dependencias de la aplicación. El código de dependencias de la aplicación 310 generalmente se escribe en JSON y especifica que la aplicación, cuando la ensambla el administrador de paquetes, debe incluir el código del paquete de código base A 301 combinado con el paquete de código adicional B 305.
El código del paquete de código base A 301, el paquete de código adicional B 305 se escriben en TypeScript y se transpilan a JavaScript cuando se cargan en un registro de paquetes.
Según las realizaciones de la invención, se emplean dos técnicas específicas para implementar clases parciales en el paquete de código base A 301 y el paquete de código adicional B. Estas dos técnicas específicas son la fusión de prototipos y el aumento de módulos.
Para implementar esta técnica, en el paquete de código base A, en los datos de código de definición de clase 304, la clase ABC se define de la manera normal, por ejemplo (nota, la numeración de línea de código de línea usada en el fragmento de código siguiente se incluye simplemente para permitir referencia a líneas individuales de código):
1. export class ABC {
2. helio () { consolé.log('helio'); }
Este código define la clase "ABC".
En el paquete de código adicional B 305, los datos de código de definición de clase 308, la clase ABC se define adicionalmente mediante el uso del siguiente código:
4. import { ABC as ABCBase } from 'packageA;
5. import { extend } from './decorators';
6 .
7. Qextend(ABCBase)
8. export class ABC {
9. private base = this as any as ABCBase;
10. world() { consolé.log (this.base.helio () ' worid'); }
11. }
12.
13. declare module 'packageA' {
14. interface ABCBase extend ABC { }
15. }
En esta definición de clase, la clase ABC se importa del paquete de código base A y se le asigna un alias localmente como "ABCBase" (línea de código 4.). Además, la función "extend" se importa desde un archivo de definición de decorador (./decorators) (línea de código 5.).
La función "extend" del archivo de definición del decorador comprende el siguiente código:
16. export function extend(base: Function) {
17. return function (cía: any) {
18. Obj ect.getOwnPropertyNames(cla.prototype)
20. .forEach(k => {
21. if (k === 'constructor' || k === 'base') return;
22. if (!base.prototype[k])
23. base.prototype[k] = cía.prototype[k];
24. }) ;
La función de decorador de JavaScript (línea de código 7) se utiliza para complementar la definición del paquete A de código base de clase ABC para incluir la funcionalidad adicional especificada en las líneas de código 9 y 10.
En virtud de esta codificación, se implementa la "fusión de prototipos" mediante la cual la funcionalidad de la clase ABC definida en el paquete de código base A puede complementarse con el código del paquete de código adicional B 305. Cuando el paquete de código base A y el paquete de código adicional B se ensamblan y luego se compilan y cargan dinámicamente, la clase ABC, aunque está definida en dos paquetes separados, se trata como una sola clase. En otras palabras, las dos definiciones de la clase ABC se cargan como una sola clase.
Sin embargo, el código del paquete de código adicional B 305 incluye además las líneas de código 13 y 14 que implementan una acción de aumento de módulo. La declaración de módulo (es decir, la instrucción "declare module") se utiliza normalmente para declarar los tipos de datos y las funciones exportadas por un módulo. Sin embargo, en este caso se usa para agregar propiedades y métodos a una clase exportada por otro módulo. Esto tiene el efecto de alterar la definición de la clase ABC en todo el código que lo importa del paquete A porque la directiva modifica la definición de la clase ABC del paquete A al añadirle las propiedades y métodos de la clase ABC definidos en el paquete B.
En virtud del aumento del módulo, las herramientas de desarrollo como el transpilador, el editor de código y el depurador tratarán las dos definiciones de la clase ABC como una sola clase fusionada.
Por ejemplo, al escribir código en un editor de código que importa el paquete de código complementario B 305, un desarrollador "verá" las dos clases (es decir, la definición de la clase ABC del paquete base A y la definición de la clase ABC del paquete adicional B) como si fueran una sola clase. Por ejemplo, en un editor de código, el desarrollador puede ingresar:
26. newABC().helio () ;
27. newABC(). world () ;
y ambas líneas de código se considerarán válidas aunque "hello()" y "world()" son funciones que provienen de definiciones de clases en archivos diferentes. Además, en un entorno de desarrollo en donde se implementa la finalización de código inteligente, el editor propondrá tanto "hello()" como "world()" como posibles finalizaciones después de haber introducido "new ABC().".
Mientras tanto, la extensión de la clase ABC en el paquete de código adicional B no tiene ningún impacto en la definición de la clase ABC en el paquete de código base. Por ejemplo, si un desarrollador diferente usara el paquete de código base A pero no importara el paquete adicional B, entonces no vería ningún cambio en la funcionalidad de la clase ABC más allá de lo que está definido en el paquete de código base. Además, siempre que la definición de la clase ABC no se elimine o se elimine algún aspecto de esta, el código base en sí puede cambiarse/actualizarse sin ningún efecto sobre la funcionalidad proporcionada por los módulos adicionales que amplían aún más la clase ABC.
Normalmente, cuando se utiliza esta técnica, se aplica naturalmente una política mediante la cual se puede agregar funcionalidad a una definición de clase (ya sea en el código base o en el código adicional) pero, para evitar conflictos, no se puede eliminar.
La figura 4 representa un método según ciertas realizaciones de la invención. En un primer paso S401, se escribe el código base que incluye una definición base de una clase ABC. La definición base de la clase se escribe de forma convencional. El código base está escrito en TypeScript. En un segundo paso S402, se escribe el código adicional, que complementa el código base, que incluye una definición adicional de la clase ABC que amplía la funcionalidad de la clase. La definición adicional de la clase ABC usa una función decoradora para implementar la fusión de prototipos al combinar la definición base de la clase ABC con una definición adicional de la clase ABC e implementa el aumento de módulo mediante el uso de la instrucción "declare module". El código adicional está escrito en TypeScript. En un tercer paso S403, el código base se transpila de TypeScript a JavaScript y se publica en un registro de paquetes como un paquete de código base. En un cuarto paso S404, el código adicional se transpila de TypeScript a JavaScript y se publica en el registro de paquetes como un paquete de código adicional. En un quinto paso S405, un administrador de paquetes ensambla el código fuente de la aplicación según las dependencias especificadas en un archivo de manifiesto de la aplicación. El ensamblaje del código fuente de la aplicación incluye el paquete de código base y el paquete de código adicional. En un sexto paso S406, el código ensamblado se comunica a un servidor de aplicaciones y en un séptimo paso S407 el servidor de aplicaciones carga y compila el código fuente mediante el uso de un motor JavaScript. En un octavo paso S408, el código de aplicación compilado se ejecuta en el servidor de aplicaciones.
La figura 5 proporciona un diagrama esquemático simplificado que muestra un sistema para implementar una técnica según ciertas realizaciones de la invención y para implementar el método descrito con referencia a la figura 4.
El sistema comprende un sistema desarrollador de código base 501 que comprende un aparato que permite a un desarrollador de código base escribir código TypeScript que define el código base de una aplicación. Normalmente, el sistema desarrollador de código base 501 comprende uno o más dispositivos informáticos en donde se ejecuta software que proporciona un entorno de desarrollo de código tal como un "entorno de desarrollo integrado" (IDE).
El sistema comprende además un sistema desarrollador de código adicional 502. El sistema desarrollador de código adicional 502 corresponde al sistema desarrollador de código base 501, p. ej., comprende un aparato que le permite a un desarrollador adicional escribir código TypeScript que define el código adicional para la aplicación, que normalmente comprende uno o más dispositivos informáticos en donde se ejecuta un entorno de desarrollo de código como un "entorno de desarrollador integrado" (IDE). Aunque no se muestra, normalmente el sistema puede incluir varios sistemas desarrolladores de código adicional independientes, cada uno de los cuales escribe código adicional independiente
Como se describió anteriormente, las clases definidas en el código base escrito mediante el uso del sistema desarrollador de código base 502 pueden definirse adicionalmente en el código adicional escrito en el sistema desarrollador de código adicional 502 mediante el uso de una función decoradora para implementar la fusión de prototipos e implementar el aumento de módulo mediante el uso de una instrucción “declare module”.
El código base escrito mediante el uso del sistema desarrollador de código base 501 y al definir una o más clases, y el código adicional escrito mediante el uso del sistema desarrollador de código adicional 502 y que comprende más definiciones de una o más clases, se transpilan de TypeScript a JavaScript por un transpilador 503 y luego se publican en un registro de paquetes 504.
El sistema incluye además un sistema desarrollador de aplicaciones 505. El sistema desarrollador de aplicaciones corresponde al sistema desarrollador de código base 501 y al sistema desarrollador de código adicional 502 descritos anteriormente, p. ej., que comprende uno o más dispositivos informáticos en donde se ejecuta un entorno de desarrollo de código tal como un "entorno de desarrollo integrado" (IDE). El sistema desarrollador de aplicaciones permite que un desarrollador de aplicaciones escriba directivas de ensamblaje de aplicaciones, incluido un archivo de manifiesto de la aplicación, para implementar una instancia particular de una aplicación. Como se describió anteriormente, el archivo de manifiesto de la aplicación especifica paquetes de código adicional particulares del registro de paquetes 504 para incluirlos en la implementación de la instancia de la aplicación. El sistema desarrollador de aplicaciones 505 está vinculado a un administrador de paquetes 506. El código de ensamblaje de la aplicación que incluye el archivo de manifiesto de la aplicación se comunica al administrador de paquetes 506 que ensambla el código fuente JavaScript a partir del código base y el código adicional en el registro de paquetes según el manifiesto de la aplicación. Este código fuente de JavaScript se comunica a un servidor de aplicaciones 507 y se compila y carga mediante un motor de JavaScript 508 que se ejecuta en el servidor de aplicaciones y, por lo tanto, se implementa una instancia de la aplicación en el servidor de aplicaciones 507.
Se entenderá que las partes componentes del sistema descrito con referencia a la figura 5 pueden implementarse de cualquier forma apropiada conocida en la técnica. En ciertas realizaciones, las partes componentes del sistema representadas en la figura 5 son designaciones lógicas y la funcionalidad proporcionada por uno o más componentes partes del sistema puede ser proporcionada por un solo dispositivo informático o a través de múltiples dispositivos informáticos. Por ejemplo, en determinadas realizaciones, la funcionalidad asociada con el transpilador, el registro de paquetes (por ejemplo, almacenamiento de paquetes de códigos) y el administrador de paquetes, puede proporcionarse mediante software que se ejecuta en un aparato informático programado adecuadamente, proporcionado, por ejemplo, por un servidor de aplicaciones o varios servidores de aplicaciones conectados. En ciertas realizaciones, la funcionalidad asociada con el transpilador y/o el registro de paquetes y/o el administrador de paquetes puede ser proporcionada por el mismo aparato informático que proporciona la funcionalidad asociada con uno del sistema desarrollador de código base, sistema desarrollador de código adicional o sistema desarrollador de código de aplicación.
En determinadas realizaciones, el administrador de paquetes está adaptado para garantizar que el código y los artefactos de metadatos de los paquetes de códigos adicionales se implementen en directorios separados. Una vez extraídos, los artefactos son inmutables. Pueden ser reemplazados en su conjunto por otra versión, pero no pueden modificarse in situ.
En ciertas realizaciones, al escribir código adicional, se respeta una convención mediante la cual se pueden agregar nuevos elementos (por ejemplo, tablas, columnas, clases, métodos, controladores de eventos, etc.) pero los elementos existentes no se reemplazan ni eliminan.
En ciertas realizaciones, se respeta una convención de nomenclatura al escribir código adicional. Se asigna un prefijo único a cada desarrollador de código adicional (por ejemplo, la parte responsable del desarrollo de un complemento, como un proveedor) y cada desarrollador de código adicional antepone a todos sus elementos agregados a una clase su prefijo seguido de un signo de $. Si la definición de clase en el código base no usa un signo $ (excepto en la primera posición), se puede evitar la probabilidad de que surjan conflictos de nombres.
En los ejemplos descritos anteriormente, se ha descrito cómo una clase definida en código a partir de un paquete de código base puede extenderse mediante código en un solo paquete de código adicional. Sin embargo, las realizaciones de la técnica también pueden usarse para extender una clase definida en un paquete de código base mediante el uso de definiciones de múltiples paquetes de código adicional.
Además, la técnica también se puede utilizar para ampliar una clase definida en un primer paquete de código adicional con código de un segundo paquete de código adicional.
Todas las características descritas en esta memoria descriptiva (incluidas las reivindicaciones adjuntas, el resumen y los dibujos) y/o todos los pasos de cualquier método o proceso descritos de este modo, pueden combinarse de cualquier manera, excepto combinaciones en donde al menos algunas de dichas características y/o pasos sean mutuamente excluyentes. Cada característica descrita en esta memoria descriptiva (incluidas las reivindicaciones adjuntas, el resumen y los dibujos) puede ser reemplazada por características alternativas que tengan un propósito idéntico, equivalente o similar, a menos que se indique expresamente lo contrario. Por lo tanto, a menos que se indique expresamente lo contrario, cada característica descrita es solo un ejemplo de una serie genérica de características equivalentes o similares. La invención se define en las reivindicaciones adjuntas.
Con respecto al uso de sustancialmente cualquier término en plural y/o singular en este documento, los expertos en la técnica pueden traducir del plural al singular y/o del singular al plural según sea apropiado para el contexto y/o aplicación. Las diversas permutaciones de singular/plural pueden establecerse expresamente en este documento por motivos de claridad.
Los expertos en la técnica entenderán que, en general, los términos utilizados en el presente documento, y especialmente en las reivindicaciones adjuntas, se entienden generalmente como términos "abiertos" (por ejemplo, el término "que incluye" debe interpretarse como "que incluye, pero no se limita a”, el término “tiene” debe interpretarse como “tiene al menos", el término “incluye” debe interpretarse como “incluye, pero no se limita a", etc.). Los expertos en la técnica entenderán además que si se pretende un número específico de una indicación de reivindicación introducida, dicha intención se indicará explícitamente en la reivindicación y, en ausencia de dicha indicación, dicha intención no está presente. Por ejemplo, como ayuda para la comprensión, las siguientes reivindicaciones adjuntas pueden contener el uso de las frases introductorias "al menos uno" y "uno o más" para presentar las descripciones de las reivindicaciones. Sin embargo, el uso de tales frases no debe interpretarse en el sentido de que la introducción de una indicación de reivindicación por los artículos indefinidos "un" o "una" limita cualquier reivindicación particular que contenga dicha indicación de reivindicación introducida a realizaciones que contengan solo una de dichas indicaciones, incluso cuando la misma reivindicación incluye las frases introductorias "uno o más" o "al menos uno" y artículos indefinidos como "un" o "una" (p. ej., "un" y/o "una" debe interpretarse como "al menos uno" o “uno o más"); lo mismo es válido para el uso de artículos definidos utilizados para introducir indicaciones de reivindicaciones. Además, incluso si se indica explícitamente un número específico de una indicación de reivindicación introducida, los expertos en la técnica reconocerán que dicha indicación debe interpretarse en el sentido de al menos el número indicado (por ejemplo, la simple recitación de "dos recitaciones", sin otros modificadores, significa al menos dos indicaciones, o dos o más indicaciones).
Se apreciará que en la presente memoria se han descrito varias realizaciones de la presente descripción con fines ilustrativos, y que se pueden realizar diversas modificaciones sin apartarse del alcance de la presente descripción tal como se define en las reivindicaciones adjuntas. Por consiguiente, las diversas realizaciones descritas en la presente memoria no pretenden ser limitantes, donde el alcance real está indicado mediante las siguientes reivindicaciones.

Claims (8)

REIVINDICACIONES
1. Un método para desplegar una aplicación que comprende:
publicar un primer paquete de código en un registro de paquetes;
publicar uno o más paquetes de código adicionales en el registro de paquetes;
ensamblar el código fuente de la aplicación mediante la combinación del primer paquete de código con uno o más de los paquetes de código adicionales del registro del paquete según las dependencias especificadas en un archivo de manifiesto de la aplicación, en donde
el primer paquete de código comprende código que especifica una primera definición de una clase y al menos uno de los uno o más paquetes de código adicional comprende código que especifica una definición adicional de la clase, en donde la definición adicional de la clase comprende:
fusión de prototipos de modo que en la compilación la primera definición de la clase y la definición adicional de la clase se carguen como una sola clase, en donde la fusión de prototipos comprende el uso de una función decoradora para incorporar, tras la carga, el código que especifica la primera definición de la clase con el código que especifica la definición adicional de la clase, y
aumento de módulo de modo que la primera y las definiciones adicionales de la clase sean tratadas como una sola clase fusionada por las herramientas de desarrollo, en donde el aumento de módulo comprende el uso de una instrucción de "declare module" de TypeScript; comprendiendo el método además:
escribir el primer paquete de código y uno o más paquetes de código adicional en TypeScript, donde el primer paquete de código y el uno o más paquetes de código adicionales se transpilan a JavaScript antes de publicarse en el registro de paquetes.
2. Un método según la reivindicación 1, que comprende además cargar y ejecutar el código fuente de la aplicación ensamblado en un servidor de aplicaciones.
3. Un método según la reivindicación 2, que comprende cargar y compilar el código fuente de la aplicación ensamblada mediante un motor JavaScript.
4. Un método según cualquier reivindicación precedente, en donde el primer paquete de código es un paquete de código base que especifica el código base asociado con la aplicación.
5. Un método según cualquier reivindicación precedente, en donde el uno o más paquetes de código adicionales son paquetes de código adicional que especifican un código adicional que especifica una funcionalidad adicional que se incluirá selectivamente en instancias de la aplicación.
6. Un sistema para desplegar una aplicación que comprende:
un registro de paquetes que comprende un primer paquete de código y uno o más paquetes de código adicionales y un administrador de paquetes que funciona para ensamblar el código fuente de la aplicación al combinar el primer paquete de código con uno o más de los paquetes de código adicionales del registro de paquetes según las dependencias especificadas en un archivo de manifiesto de la aplicación, en donde
el primer paquete de código comprende código que especifica una primera definición de una clase y al menos uno del uno o más paquetes de código adicionales comprende código que especifica una definición adicional de la clase, donde la definición adicional de la clase comprende:
fusión de prototipos de modo que en la compilación la primera definición de la clase y la definición adicional de la clase se carguen como una sola clase, en donde la fusión de prototipos comprende el uso de una función decoradora para incorporar, tras la carga, el código que especifica la primera definición de la clase con el código que especifica la definición adicional de la clase, y
aumento de módulo de modo que la primera y las definiciones adicionales de la clase sean tratadas como una sola clase fusionada por las herramientas de desarrollo, en donde el aumento de módulo comprende el uso de una instrucción de "declare module" de TypeScript; en donde
el primer paquete de código y el uno o más paquetes de código adicionales están escritos originalmente en TypeScript, y en donde el sistema comprende además:
un transpilador adaptado para transpilar el primer paquete de código y el uno o más paquetes de código adicionales de TypeScript a JavaScript y publicar el primer paquete de código transpilado y el uno o más paquetes de código adicionales en el registro de paquetes.
7. Un sistema según la reivindicación 6, que comprende además un servidor de aplicaciones, comprendiendo dicho servidor de aplicaciones un motor, en donde el servidor de aplicaciones funciona para recibir el código fuente de la aplicación ensamblado desde el registro de paquetes y el motor está adaptado para cargar y ejecutar el código de aplicación ensamblado.
8. Un sistema según la reivindicación 7, en donde el motor es un motor JavaScript.
ES19174168T 2018-05-16 2019-05-13 Despliegue de aplicaciones Active ES2877195T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB1807929.3A GB2573775A (en) 2018-05-16 2018-05-16 Application Deployment

Publications (1)

Publication Number Publication Date
ES2877195T3 true ES2877195T3 (es) 2021-11-16

Family

ID=62623282

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19174168T Active ES2877195T3 (es) 2018-05-16 2019-05-13 Despliegue de aplicaciones

Country Status (6)

Country Link
US (1) US10970084B2 (es)
EP (1) EP3570159B1 (es)
AU (1) AU2019203416B2 (es)
CA (1) CA3043207C (es)
ES (1) ES2877195T3 (es)
GB (1) GB2573775A (es)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220091844A1 (en) * 2020-08-02 2022-03-24 Drexel University System for achieving insights through interactive facet-based architecture recovery (i-far)
US20230185544A1 (en) * 2021-12-14 2023-06-15 Google Llc User-defined Secure Remote Code Execution from No-code Platforms
CN114546534B (zh) * 2022-02-28 2023-11-24 百果园技术(新加坡)有限公司 一种应用页面启动方法、装置、设备及介质

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6637020B1 (en) * 1998-12-03 2003-10-21 International Business Machines Corporation Creating applications within data processing systems by combining program components dynamically
US6874143B1 (en) * 2000-06-21 2005-03-29 Microsoft Corporation Architectures for and methods of providing network-based software extensions
CN1561482A (zh) * 2001-08-24 2005-01-05 布鲁克斯自动控制公司 应用程序类扩展
US6925640B2 (en) * 2001-10-12 2005-08-02 Sun Microsystems, Inc. Method and apparatus for extending a program element in a dynamically typed programming language
US7305666B2 (en) * 2003-07-23 2007-12-04 Microsoft Corporation Description language for an extensible compiler and tools infrastructure
US7657899B2 (en) * 2005-03-09 2010-02-02 Computer Associates Think, Inc. Dynamic creation of proxy software objects at time of execution
US8533692B2 (en) * 2005-12-30 2013-09-10 Sap Ag Dynamic software enhancement parameters
US20180262388A1 (en) * 2006-09-25 2018-09-13 Weaved, Inc. Remote device deployment
US8762976B2 (en) * 2007-03-09 2014-06-24 Microsoft Corporation Static extensibility models with dynamic languages and scripts
US8381177B2 (en) * 2007-09-28 2013-02-19 Texas Instruments Incorporated Method and system of performing Java language class extensions
US8707286B2 (en) * 2008-12-12 2014-04-22 Sap Ag Unique context-based code enhancement
JP5396979B2 (ja) * 2009-04-10 2014-01-22 日本電気株式会社 ソフトウェア開発支援装置、システム、ソフトウェア開発支援装置の機能拡張方法、及びプログラム
US8738755B2 (en) * 2011-09-09 2014-05-27 International Business Machines Corporation Providing external access to service versions via a bundle framework
US9542178B2 (en) * 2012-11-09 2017-01-10 Sap Se In-place definition of software extensions
US9563412B2 (en) * 2013-03-13 2017-02-07 Microsoft Technology Licensing, Llc. Statically extensible types
US9588742B2 (en) * 2013-09-20 2017-03-07 Oracle International Corporation Rule-based automatic class generation from a JSON message
US10223142B2 (en) * 2015-04-03 2019-03-05 Oracle International Corporation System and method for supporting javascript activities in a process defined by a process execution language for execution in a SOA middleware environment
US9542173B2 (en) * 2015-05-15 2017-01-10 Sap Se Dependency handling for software extensions

Also Published As

Publication number Publication date
CA3043207C (en) 2021-06-15
CA3043207A1 (en) 2019-11-16
US10970084B2 (en) 2021-04-06
GB2573775A (en) 2019-11-20
EP3570159A1 (en) 2019-11-20
EP3570159B1 (en) 2021-04-21
GB201807929D0 (en) 2018-06-27
AU2019203416A1 (en) 2019-12-05
US20190391823A1 (en) 2019-12-26
AU2019203416B2 (en) 2023-04-27

Similar Documents

Publication Publication Date Title
ES2877195T3 (es) Despliegue de aplicaciones
US20090064196A1 (en) Model based device driver code generation
US20080209316A1 (en) System and method of implementing an extensible command-line interface
Robby et al. Slang: The SIREUM programming language
ES2908651T3 (es) Instrucciones reducidas para generar direcciones de variables globales
Bezzubikov et al. Automatic dynamic binary translator generation from instruction set description
Darwin Java cookbook: problems and solutions for Java developers
Clow et al. AngularJS vs. Angular (Old vs. New)
Steyer Building web applications with Vue. js: MVVM patterns for conventional and single-page websites
Gustedt Modular C
Gulati et al. Understanding Core JUnit 5
Kamkin et al. MicroTESK: An Extendable Framework for Test Program Generation
Chupilko et al. Maintaining ISA specifications in MicroTESK test program generator
Heinen et al. Simple vs. Complex OBCP: Experience and Solutions for managing On-Board Control Procedures
Pollak et al. Testing Your Code
Daverveldt LLVM-based ρ-VEX compiler
Dea et al. JavaFX and Jigsaw
Tatarnikov An approach to instruction stream generation for functional verification of microprocessor designs
Dabir Gradle Essentials
Weber et al. Exchanging the Target-Language in Existing, Non-Metamodel-Based Compilers
Krikava et al. Solving the TTC'14 FIXML Case Study with SIGMA
Kaes Direct Abstraction
Mazzeranghi Panda: a Pattern-based Programming System for Automatic Code Generation.
Balbaert et al. Learning Dart
Gong et al. Reference Designs