Patent Description:
In modern computing languages such as JavaScript and TypeScript, software application development can be conveniently achieved by developing code as a series of separate "packages" stored in a package repository and managed by a package manager. The code packages are assembled into the complete version of the source code and compiled just before run-time. Changes to the code are made by editing the relevant code packages. The package-based approach makes version control and error tracking easier and enables different developers or different teams of developers to easily work on different aspects of the code.

Certain types of applications require the involvement of a subject matter specialist who may not necessarily be a coding expert. Examples include enterprise resource planning (ERP) applications which require the expertise of business analysts in specifying application elements such as "business objects" and accountancy applications such as payroll applications which require the expertise of payroll tax experts (e.g. those who are familiar with the legal and accountancy technicalities associated with payroll calculations).

Even though use of package-based code development improves application development (particularly where frequent changes are required) it is nonetheless necessary to modify code using conventional code editors. Such code editors require coding expertise to use. In order to make changes to the code, subject matter experts (e.g. business analysts or payroll tax experts) must also be coding experts or must be assisted by a coding expert.

It is desirable to provide a technique for updating code, particularly code relating to large enterprise-class software applications, that requires a reduced level of coding expertise.

<CIT> discloses attribute-based automated business rule identification techniques.

<CIT> discloses techniques for generating and deploying business rules in a business rule management system (BRMS).

<NPL>, discloses a Java extension (named @Java) with a richer annotation model that supports code block and expression annotations as well as dynamically evaluated members.

In accordance with a first aspect of the invention, there is provided a system for modifying source code. The system comprising a repository for storing code, and a first code editor operable to: access source code stored in the repository, said source code for implementing a software application or part of a software application and annotated by one or more decorators, wherein the source code is written in TypeScript code; identify from the source code one or more TypeScript decorator declarations; identify decorator definition code associated with each TypeScript decorator declaration; identify metadata code defined in the decorator definition code and associated with the implementation of the application; present the metadata code on a user interface; receive metadata modification data input by a user of the first code editor; and modify the metadata code in accordance with the metadata modification data. The source code defines a plurality of application elements of the software application and each application element is associated with one or more attributes, each attribute defined by metadata code in the decorator definition code corresponding to the TypeScript decorator declaration associated with the application element, wherein the one or more TypeScript decorator declarations modify, at run time, code features of the source code with which they are associated, said code features defining application elements of the software application.

Optionally, the first code editor is operable to modify the metadata code by downloading a copy of the source code, modifying the metadata code of the copy of the source code in accordance with the metadata modification data and uploading a modified copy of the source code to the repository.

Optionally, each attribute is defined by a class property annotated by one or more decorators.

Optionally, the decorator definition code defines one or more functions and the metadata code comprises variables associated with the functions.

Optionally, the system further comprises a second code editor, said second code editor comprising a conventional code editor operable to enable a user to edit the code stored in the code repository.

Optionally, the first code editor is run on a first client device and the second code editor is run on a second client device.

Optionally, the code repository is run on an application server and the first client device and second client device are connected to the application server via a data network.

In accordance with a second aspect of the invention, there is provided a computer-implemented method of modifying source code stored in a repository. The source code is annotated by one or more decorators and for implementing a software application or part of a software application. The method comprising: accessing source code stored in the repository, wherein the source code is written in TypeScript code; identifying from the source code one or more TypeScript decorator declarations; identifying decorator definition code associated with each TypeScript decorator declaration; identifying metadata code defined in the decorator definition code and associated with the implementation of the application; presenting the metadata code on a user interface; receiving metadata modification data input by a user; and modifying the metadata code in accordance with the metadata modification data. The source code defines a plurality of application elements of the software application and each application element is associated with one or more attributes, each attribute defined by metadata code in the decorator definition code corresponding to the TypeScript decorator declaration associated with the application element, wherein the one or more TypeScript decorator declarations modify, at run time, code features of the source code with which they are associated, said code features defining application elements of the software application.

In accordance with a third aspect of the invention, there is provided a simplified code editor for modifying source code stored in a repository. The source code is annotated by one or more decorators and for implementing a software application or part of a software application. The code editor is operable to: access source code stored in the repository, said source code for implementing a software application or part of a software application and annotated by one or more decorators, wherein the source code is written in TypeScript code; identify from the source code one or more TypeScript decorator declarations; identify decorator definition code associated with each TypeScript decorator declaration; identify metadata code defined in the decorator definition code and associated with the implementation of the application; present the metadata code on a user interface; receive metadata modification data input by a user of the code editor; and modify the metadata code in accordance with the metadata modification data. The source code defines a plurality of application elements of the software application and each application element is associated with one or more attributes, each attribute defined by metadata code in the decorator definition code corresponding to the TypeScript decorator declaration associated with the application element, wherein the one or more TypeScript decorator declarations modify, at run time, code features of the source code with which they are associated, said code features defining application elements of the software application.

In accordance with a fourth aspect of the invention, there is provided a computer program comprising instructions which when performed by a suitably programmed computer, control the computer to implement a code editor in accordance with the third aspect of the invention.

In accordance with aspects of the present technique, a modified code editor is provided which is adapted to enable a user without a high degree of coding expertise to access and modify data from a specially structured source code. Specifically, the modified code editor enables such a user to readily interact with, and modify, metadata code. Typically, the metadata code is associated with an application that the source code implements.

Metadata code is code within the source code that defines application "metadata". Metadata, broadly speaking, is data that specifies information about how other data is handled or processed by the application. Certain application metadata for example specifies how the application operates on certain input data. Other application metadata, for example, specifies how data is stored within the system. An example of metadata in the context of an enterprise resource planning (ERP) application is data defining business rules which define attributes of business objects. An example of metadata in the context of a payroll calculation applications is data defining the conditions and formulas that define how individual payroll calculations (e.g. tax contributions, pension contributions etc) are calculated. Other examples of application metadata include data that specifies how data is persisted in application databases (table names, column names etc) and how data is exposed in a Web API (which classes and which properties are exposed etc).

Users who may be required to make changes to application metadata may typically be experts on the subject matter that the metadata relates to (for example, tax experts for payroll applications), but not coding experts.

In accordance with aspects of the technique, the source code is annotated with a plurality of decorators and is structured so that metadata code, associated with the application which the source code implements, is defined within corresponding decorator definition code. Advantageously, the modified code editor uses this structure to readily isolate the metadata code from the rest of the source code. In this way, with no coding expertise required from the user, the conventionally complex task of identifying metadata code from source code and, if necessary, making changes to the metadata code, is greatly simplified.

Advantageously, this technique can be implemented without the need of complicated "abstracting" mechanisms normally required to simplify coding tasks. The technique simply requires the provision of a modified code editor and that decorators are used to annotate the source code and metadata code is defined in the corresponding decorator definition code.

Advantageously, in certain embodiments, the metadata code can be written in the same programming language as the remainder of the source code. Advantageously, this can further simplify the implementation of the application.

Various further features and aspects of the invention are defined in the claims.

Embodiments of the present invention will now be described by way of example only with reference to the accompanying drawings where like parts are provided with corresponding reference numerals and in which:.

<FIG> provides a schematic diagram depicting the development and deployment of a conventional enterprise-class cloud-based application.

Expert software developers use developer devices <NUM> running code editing tools to create and modify source code for implementing instances of the application.

During development, source code is stored in a code repository <NUM> enabling the software developers to collaborate on the development of the source code. The source code repository <NUM> is typically provided by a code development environment enabling the source code under development to be tested, error-checked and subject to version control.

Once a piece of source code has been completed and error checked it is published as a code package to a package repository <NUM> under the control of a package manger <NUM>. An instance of a typical enterprise-class application involves the combination of source code from multiple code packages. The particular code packages used will depend on the requirement of the instant of the application.

An application server <NUM> has running thereon an application manager <NUM> which receives requests from client devices <NUM> for access to an instance of the application. On receipt of such a request, the application manager <NUM> communicates a request to the package manager <NUM> for the relevant code packages required to deploy the particular instance of the application. The package manager <NUM> communicates assembled code from the relevant code packages to the application manager <NUM> which then instantiates an instance of the application <NUM>.

The package-based approach to application deployment allows instances of the application to be customised for different users by the selection of relevant code packages. Further, the use of package-based code development enables multiple software developers to collaborate on the development of source code for different code packages.

However, the technique for developing source code described with reference to <FIG> requires that the software developers are expert coders and in particular have the expert skills necessary to use the complex code editing tools conventionally used to write and modify the source code.

This is a drawback in the development and deployment of certain types of applications, particular those that include critical components that depend in part on being developed and updated by subject matter experts who may not be coding experts.

Such subject matter experts are typically required to ensure that metadata associated with the application is correctly defined and updated.

Many different types of enterprise class applications require subject matter experts to ensure that application metadata is correctly defined and updated.

Two particular examples of such applications include enterprise resource planning (ERP) applications and payroll applications.

A typical ERP application comprises application elements such as "business objects". Examples of business objects include for example "customer", "sales order", "product", "invoice" etc. Each such business object application element is associated with one or more attributes, for example, one or more business rules defining the properties of the business object. For example, the business rules may encode control rules that are applied before a new customer or a new order can be entered into a system running the ERP application.

The business rules associated with a business object are critical to the functionality provided by a typical ERP application and are therefore normally defined by a subject matter expert such as a business analyst. However, such business analysts, are rarely coding experts which means that whenever source code defining business rules needs to be written or updated, both a business analyst and an expert software developer are required or a business analyst who is also an expert software developer is required.

Payroll application development also typically requires the input of non-coding experts. A typical payroll application requires a payroll calculation engine to be implemented which comprises application elements, specifically "pay plan" elements. Examples of such pay plan elements include income tax deductions, pension contributions, holiday pay entitlements and so on. Such application elements are defined by various attributes (i.e. the formulas and conditions which define the pay plan elements). Ensuring that the source code is up to date to provide the correct attributes (i.e. the formulas and conditions which define the pay plan elements) is essential to the correct implementation of an instance of a payroll application and must be overseen by a subject matter expert i.e. a payroll expert such as an accountant familiar with the jurisdiction in which the instance of the application is going to be deployed. Again, it is unlikely that such a subject matter expert is also a coding expert.

In accordance with examples of the invention, a technique is provided that enables a simplified code editing tool to be implemented which can be readily used by a non-coding expert to update source code, and in particular application metadata defined in the source code. Moreover, the simplified code editing tool can be readily integrated into the application deployment and development environment described with reference to <FIG>.

<FIG> provides a schematic diagram of a system for implementing a code editing technique in accordance with certain embodiments of the invention.

A repository <NUM>, provided for example by a conventional code repository contains a code package <NUM> comprising source code <NUM> defining an application or a part of an application.

The repository <NUM> is typically run on a suitably programmed server device and the source code is typically written in TypeScript.

The source code is "annotated" by one or more decorators.

More specifically, code features of the source code, for example classes, class properties, functions etc, defining elements of the application (application elements), are associated with decorator declarations, which, at compile time, modify the code feature with which they are associated.

The source code <NUM> further comprises decorator definition code <NUM> associated with each decorator declaration. The decorator definition code <NUM> specifies metadata code which defines an attribute associated with the application element to which the decorator relates. For example, a class property of a class is annotated by a decorator and when loaded, the class property is modified in accordance with the metadata specified in the decorator definition code associated with the decorator annotating the class property.

In this way, metadata associated with an application element is determined based on the decorator definition code <NUM>, and in particular the metadata code of the decorator definition code <NUM>.

The system further comprises a first client device <NUM>, provided by a suitable computing device, for example a personal computer, connected via a data network <NUM> to the repository <NUM>. The first client device <NUM> has running thereon software providing a simplified code editing tool.

The simplified code editing tool is arranged to access (e.g. download to local storage) the source code <NUM> and identify from the downloaded code package the decorator definition code <NUM> specifying the metadata code <NUM> defining the various application element attributes.

The simplified code editing tool is further arranged to identify the metadata code <NUM> and present this on an interface provided by the simplified code editor.

The metadata code is typically presented on a suitable interface displayed on a display of the client device <NUM>. The interface enables a user to make changes to the metadata code using conventional user input means (e.g. a mouse and keyboard).

The metadata code can be presented in any suitable way. In certain examples, the metadata code is in a suitable simplified notation such as JSON (JavaScript Object Notation) and edited via a suitable text editor provided on the interface displayed on the display of the client device.

In certain examples the metadata code can be presented on the interface in an even simpler manner, for example in a form with checkboxes, combo boxes, and text fields. In such examples, the user does not even need to be familiar with object notation such as JSON and can modify the metadata code with simple "point and click" actions. A rich code editor can be provided for more complex cases.

The interface thus allows a user to make changes to the metadata code and, responsive to this, the simplified code editing tool makes corresponding changes to the decorator definition code in the local version of the source code <NUM> thereby creating a modified version of the source code <NUM>. The simplified code editor then uploads the modified version of the code package to the repository <NUM>.

In certain embodiments, the simplified code editor is arranged such that modifications to the code can be made directly to the copy of the code package stored in the repository <NUM> rather than downloading a copy and modifying it locally and then uploading the modified copy.

The system further comprises a second client device <NUM> which can also be provided by a suitable computing device such as a personal computer and is also connected to the repository <NUM> via the data network. The second client device <NUM> has running thereon a conventional code editing tool (for example Visual Studio Code). The conventional code editing tool is arranged to access (e.g. download to local storage) the source code <NUM> and provide an interface enabling a user to modify the source code in a conventional way and then upload the modified version of the source code to the repository <NUM>. In certain embodiments, modifications to the code can be made directly to the copy of the code package stored in the package repository rather than downloading a copy and modifying it locally and then uploading the modified copy.

<FIG> provides a schematic diagram depicting the arrangement of a code package suitable for use with the technique described with reference to <FIG>.

In particular, <FIG> shows an ERP application code package <NUM> which comprises source code <NUM>. The source code <NUM> defines a number of application elements of an ERP application. As described above, in use, when modifications to the source code <NUM> have been made, the source code is incorporated into the ERP application code package and published to a package repository. The code package is combined with other code packages for instantiating, an instance of the ERP application.

In one example, the application elements that the source code <NUM> defines are "business objects". Each business object is associated with one or more attributes, for example "business rules". These attributes define the behaviour of business objects when the ERP application is instantiated. The attributes are defined by metadata and particularly metadata code. In a typical deployment, the metadata defining the business rules may need frequent modification by a business analyst.

Examples of typical business objects include "customer", "sales order", "product", "invoice". Some business objects may comprise further properties (i.e. comprise further application elements). For example, a "product" business object may have further properties such as "code", a "description", a "category", a "supplier", a "brand".

Examples of typical business rules for the business object "product" include, for example, control rules defining which properties are mandatory before a new product can be entered into a system running the ERP application, for example validity ranges for dates, decimal precision for quantities and so on.

The source code <NUM> includes code defining one or more classes 304a, 304b, 304c, 304d.

The code defining each class typically contains code defining a number of class properties 305a, 305b, 305c, 305d.

Typically, each class property is associated with a business object or business object properties. For example, with reference to <FIG>, the first class property code 305a defines a first business object; the second class property code 305b defines a second business object; the third class property code 305c defines a third business object; and the nth class property code 305d defines an nth business object. As described above, each business object is defined by various attributes, i.e. business rules. These business rules are defined by business rule metadata (i.e. metadata defining the properties of a business object).

The business rule metadata associated with each business object, rather than being defined directly in the source code are instead incorporated into the class property definitions by the insertion in the code of TypeScript decorator declarations 306a, 306b, 306c, 306d and corresponding decorator definition code 307a, 307b, 307c, 307d. The decorator definition code 307a, 307b, 307c, 307d comprises business rule metadata code defining the business rules.

As is known in the art, a decorator is a TypeScript declaration which can be associated with the declarations of other code features such as example class declarations.

A decorator can be associated with a class declaration by declaring the decorator directly before the class declaration or within the class declaration (as depicted schematically in <FIG>). If associated with a class declaration, at run time, the class will be modified in accordance with the decorator. Modifications applied to a class by a decorator are dependent on the decorator definition which is defined in decorator definition code 307a, 307b, 307c, 307d.

By arranging source code, for example ERP application source code, as described above, and in particular by defining ERP application metadata using decorators, code relating to the ERP application metadata (e.g. the business object rules) can be readily isolated from the rest of the source code. Advantageously, the use of decorators in this way can be used to provide a convenient and simplified mechanism to make changes to the ERP application metadata.

As described above, the simplified code editing tool can be arranged to analyse the source code and use the decorator declarations as markers to identify the decorator definition code (within which the ERP application metadata is located) and then extract the relevant metadata code (i.e. metadata code relating to the business rules of the business objects).

The simplified code editor can then present the ERP application metadata code on a simplified user interface enabling a user, who is not a coding expert, to make relevant modifications (e.g. update the business rules etc). Moreover, once the modifications to the ERP application metadata are made, they can be readily "injected" back into the source code by the simplified code editing tool simply updating the relevant parts of the decorator definition code in accordance with the modifications made by the user.

Such a simplified code editing tool is particularly appropriate for a coding non-expert who must update specific parts of the code (e.g. the business rules). This is because, to use the simplified code editing tool to update the ERP application metadata, the coding expertise that would normally be required to manually isolate and modify relevant parts of the code (i.e. the business rules metadata) using a conventional code editor is not required because the tool itself isolates and identifies the metadata. To operate such a simplified code editor, it is only necessary to understand the ERP application metadata (JSON code specifying business rules). Such a simplified code editor can be readily operated by, for example an accounting expert who is not a coding expert.

Furthermore, advantageously, by adopting the structure explained with reference to <FIG> (i.e. whereby each business object rule is associated with a class property) the variables of the business object rule can be accessed as properties of a "typed" object. This means that useful features can be included in the simplified editing tool including autocomplete (e.g. Microsoft IntelliSense).

Further, if variables of the business object rule are renamed, this update can be made in all other references to that variable negating the need to provide a separate parser or cross-reference engine. Further, the code can be more reliably validated when compiled.

<FIG> depicts an example pay plan code package <NUM> arranged in accordance with certain examples of the technique and suitable for use with the technique described with reference to <FIG>. The pay plan code package can be used to implement an application providing a payroll calculation engine. The application receives employee data, performs payroll calculations and generates corresponding payroll data.

The pay plan code package comprises code defining a number of pay plan elements corresponding to part of the payroll data output. For example, one pay plan element may relate to net salary, another to income tax amount, another to pension contribution and so on.

Each pay plan element is defined by one or more functions.

These functions implement the various formulas and conditions necessary to determine the output associated with the pay plan element. The formulas and conditions are typically updated by modifying the variables of the functions. These variables of the functions are metadata (pay plan metadata) - that is, they define how data (e.g. the employee pay data) is processed by the payroll application.

The pay plan code package <NUM> comprises pay plan source code <NUM> which comprises code which implements the pay plan. The pay plan source code <NUM> is typically stored in a code repository as it is developed/modified. When the source code is finalised, it is published to a package repository.

The pay plan source code <NUM> typically includes code defining one or more classes 404a, 404b, 404c, 404d.

The code defining each class typically contains code defining a number of class properties 405a, 405b, 405c, 405d. Typically, each class property is associated with a pay plan element. For example, with reference to <FIG>, the first class property code 405a defines a first pay plan element; the second class property code 405b defines a second pay plan element; the third class property code 405c defines a third pay plan element; and the nth class property code 405d defines an nth pay plan element. As described above, each value or values defined by a pay plan element are determined by various formulas and conditions. These formulas and conditions are defined by pay plan metadata (i.e. the variables associated with the functions that define the formulas and conditions).

The formulas and conditions associated with the pay plan elements, rather than being defined directly in the source code are instead incorporated into the class property definitions by the insertion in the code of TypeScript decorator declarations 406a, 406b, 406c, 406d and corresponding decorator definition code 407a, 407b, 407c, 407d. The decorator definition code 407a, 407b, 407c, 407d comprises pay plan metadata code defining the pay plan metadata.

The decorator definition code 407a, 407b, 407c, 407d defines the decorators used in the pay plan source code <NUM>. The decorator definition code 407a, 407b, 407c, 407d specifies the functions that define the formulas and conditions associated with the pay plan elements (these formulas and conditions are typically expressed as TypeScript functions). In this way, the data associated with a pay plan that typically requires frequent updating by a non-coding expert (i.e. the pay plan metadata specifying the variables of the functions that define the formulas and conditions) is entirely contained within the decorator definition code.

Examples of the technique have been described above with reference to an ERP application and a payroll application. It will be understood however that the technique can be applied to many other types of application where application elements are defined by attributes that are defined by metadata. Other examples include applications which comprise functionality for generating user interfaces. Specifically, the technique can be used to develop and modify code associated with an application providing a graphical user interface. The source code defining such an application defines application elements such as graphical elements for display.

Examples of such graphical elements include for example pages, input fields, buttons, tables, graphs, etc. Each such graphical element is associated with one or more attributes, for example, one or more graphical properties defining how the graphical element is displayed. In accordance with examples of the technique, source code defining a code package relating to such a graphical user interface application comprises a plurality of decorator declarations and corresponding decorator declaration code. Each decorator declaration is associated with a graphical element and the corresponding decorator declaration code defines metadata which specifies the graphical properties associated with that graphical element. Other examples of metadata in this context include presentation attributes like choice of colour or font, and presentation rules such as rules that enable/disable components in response to clicks or selections made by the user.

<FIG> provides a flow diagram of a process for modifying source code undertaken by a simplified code editor running on a client device in accordance with certain embodiments of the invention. The process described with reference to <FIG> is typically provided by software running on the client device.

The code is arranged as described above, i.e. comprising source code annotated by one or more decorators and defining decorator definition code defining metadata code associated with each decorator.

At a first step S501, the code editor connects, typically via a suitable data network, to a repository and at a second step S502 downloads source code. At a third step S503, the code editor controls the client device to store the copy of the source code downloaded on to local storage on the client device. At a fourth step S504, the code editor analyses the code in the code package to identify decorators annotating the source code. At a fifth step S505, the code editor identifies the decorator definition code associated with the corresponding decorators. At a sixth step S506 the code editor identifies and extracts the metadata code in the decorator definition code and at a seventh step S507 presents the metadata code on a user interface. At an eight step S508, the code editor receives user input for modifying the metadata code (metadata modification data) and at a ninth step S509, the code editor makes corresponding modifications to the decorator definition code. At a tenth step <NUM>, the code editor controls the client device to upload the modified source code to the repository.

It will be understood that the system depicted in <FIG> can be implemented in any suitable way. For example, the client devices can be provided by any suitable computing device such as a personal computer or client server connected, via a suitable data connection, such as the internet, to an application server on which the code repository is implemented. The client devices and the application server may be in different physical locations or the same physical location. It will be understood that the computing device typically includes components including a central processing unit (CPU), physical data storage, I/O components, and network components. Similarly, the application server can be implemented in any suitable way. For example, the application server can be provided by one or more hardware server units or can be provided by a cloud-based server implementation.

Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of similar features. The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"); the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations).

Claim 1:
A system for modifying source code (<NUM>, <NUM>), said system comprising
a repository (<NUM>) for storing code, and
a first code editor operable to:
access source code stored in the repository, said source code for implementing a software application (<NUM>) or part of a software application and annotated by one or more decorators, wherein the source code is written in TypeScript code;
identify from the source code one or more TypeScript decorator declarations (306a-d, 406a-d);
identify decorator definition code (307a-d, 407a-d) associated with each TypeScript decorator declaration;
identify metadata code (<NUM>) defined in the decorator definition code and associated with the implementation of the application;
present the metadata code on a user interface;
receive metadata modification data input by a user of the first code editor; and
modify the metadata code in accordance with the metadata modification data;
wherein the source code defines a plurality of application elements of the software application and each application element is associated with one or more attributes, each attribute defined by metadata code in the decorator definition code corresponding to the TypeScript decorator declaration associated with the application element, wherein the one or more TypeScript decorator declarations modify, at run time, code features of the source code with which they are associated, said code features defining application elements of the software application.