WO2015092519A1 - Systems and methods for developing application programs - Google Patents

Systems and methods for developing application programs Download PDF

Info

Publication number
WO2015092519A1
WO2015092519A1 PCT/IB2014/002787 IB2014002787W WO2015092519A1 WO 2015092519 A1 WO2015092519 A1 WO 2015092519A1 IB 2014002787 W IB2014002787 W IB 2014002787W WO 2015092519 A1 WO2015092519 A1 WO 2015092519A1
Authority
WO
WIPO (PCT)
Prior art keywords
application program
widgets
widget
source code
collator
Prior art date
Application number
PCT/IB2014/002787
Other languages
English (en)
French (fr)
Inventor
Anuraag Ravi VAIDYA
Abhi Jayant SHAH
Original Assignee
Kronosis Hyper Technologies Private Limited
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 Kronosis Hyper Technologies Private Limited filed Critical Kronosis Hyper Technologies Private Limited
Publication of WO2015092519A1 publication Critical patent/WO2015092519A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0633—Workflow analysis
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

  • the present subject matter relates to application programs and, more particularly but not exclusively, to systems and methods for developing application programs.
  • An application program may be understood as a computer program that performs an intended task. Examples of the application program include banking applications, database applications, such as employee record maintenance applications, and shopping portals.
  • implementation of an application program involves multiple stages, such as planning, development, and deployment and maintenance.
  • the planning stage includes requirement analysis to gather information pertaining to the end result, i.e., the intended task. Subsequently, a team of developers works on the requirements captured in the planning stage to develop the application program.
  • the development of an application program may include multiple steps, for example, designing of user interface, structuring of associated databases, development of underlying logic of the application program, and compilation of code corresponding to the application program. Typically, all the steps in the development stage are performed manually by a developer.
  • FIG. 1 illustrates a network environment for developing an application program, in accordance with an embodiment of the present subject matter
  • Fig. 2 illustrates various components of an application program development system, in accordance with an embodiment of the present subject matter.
  • FIG. 3a-3d illustrates structure of various components of an application program and the application program development system, in accordance with an embodiment of the present subject matter
  • FIG. 4 illustrates a structure of a widget unit of the application program development system, in accordance with an embodiment of the present subject matter
  • FIG. 5 illustrates components of a concurrent checker of the application program development system, according to an embodiment of the present subject matter
  • FIG. 6 illustrates components of a collator of the application program development system, according to an embodiment of the present subject matter
  • FIG. 7 illustrates a method for developing an application program, according to an embodiment of the present subject matter.
  • Fig. 8 illustrates a method for creating the application program, according to an embodiment of the present subject matter.
  • An application program may be understood as a set of instructions, which when executed perform an intended task.
  • the application programs may be developed for a variety of purposes, for example, banking purposes, such Internet banking, running an automated teller machines (ATM) machines, and updating user account; gaming and entertainment, corporate finance management, enterprise resource planning, supply chain management, learning management, Customer relationship management, customer portals, big data (big data solutions) management, and for shopping portals, business intelligence, and analytics applications.
  • banking purposes such Internet banking, running an automated teller machines (ATM) machines, and updating user account
  • gaming and entertainment corporate finance management, enterprise resource planning, supply chain management, learning management, Customer relationship management, customer portals, big data (big data solutions) management, and for shopping portals, business intelligence, and analytics applications.
  • the application program may be considered to include multiple sections.
  • a section may include a program corresponding to a given functionality, which may be realized through one or more widgets.
  • a program structure may be" considered to be analogous to a folder, which may hold widgets and may keep a record of inter-connections between widgets.
  • a widget corresponds to a pre-developed code snippet that generates a source code, upon deployment, the source code being task specific. On execution of the source code a task, such as manipulation, representation, storage, retrieval, and obfuscation of information, is performed.
  • the pre-developed code snippet may be configurable, for example, the pre-developed code snippets may use user inputs and inputs received from other widgets to generate the source code. Additionally, the widgets may also be provided by way of a widget pack, which is a collection of a plurality of widgets that perform a task, such as a login task. Further, the generated source code may vary based on application requirement and user inputs.
  • the development of the application program may involve development of, various other components, such as databases, and layout of the sections and the databases, may also be defined.
  • a user such as a developer, may provide various inputs to perform an action.
  • Each action may have an action ID associated with it and based on the action ID a development unit corresponding to the action may be selected.
  • development of an application program involves development of multiple features or components, and one or more of such components may be developed using a development unit. Examples of the development unit includes, but are not limited to, a project setting units, a structures unit, a databases unit, a widgets and widget packs unit, a sections unit, a fields unit, and a layouts unit.
  • the multiple development units may be provided in an action manager, which may be configured to analyze a received action and provide the received action to one of the development units, based on the action ID. For example, in case the action pertains to selection of a widget, the action may be provided to the widgets and the widget packs unit for further analysis. In another example, in case the action pertains to creation of a database, the action may be provided to the database unit for further analysis.
  • the corresponding development unit may check for validity of the action, based on validation rules.
  • the validation rules may include checks for, for example, inclusion of special characters and syntax related errors.
  • the validation rules may check for issues, such as hacking and basic errors.
  • a dual validation is performed, once at user end, i.e., client side validation, and if validated at the client end, the action is again validated at server end. Further, the action may be performed, if the action is validated at both the client and the server side.
  • the user may initially create one or more database(s) corresponding to the application program using the database unit.
  • the database may be based on relational database management systems (RDMS) or non- relational database management systems.
  • RDMS relational database management systems
  • the database may be, for example, MySQL ® , SQL ® , NoSQL, Oracle ® , or Hadoop ® .
  • the databases may be working one same or different RDMS.
  • a first database may be in MySQL ®
  • a second database may be in SQL ®
  • a third database may be in NoSQL ® .
  • a structure of the databases may be created or modified using the structures unit; and various fields that may be included in tables of the databases may be created or modified using the fields unit.
  • the user may create or modify the sections of the application program using the sections unit. Upon creating sections, the user may select one or more widgets from a plurality of widgets, based on application requirements. For example, in case records are to " be added, deleted, or modified in a database, a corresponding widget may be added to that section.
  • the widgets may be used for handle emailing, scheduling tasks, injecting custom native code, creating forms, importing/exporting documents, manipulation files, and managing servers.
  • the user may select the desired widget and corresponding code may be added to the application program, upon deployment.
  • a skeleton may be provided by way of the databases unit and the user may create the databases with minimal inputs.
  • the widgets may have standalone architecture and may work without a compiler, i.e., the underlying code of the widgets may be free from errors.
  • the actions may be checked in parallel. In other words, even before the application is collated, the actions may be checked for errors and conflicts concurrently, to ensure that there are minimum changes at the final stage.
  • the section may be checked for probable errors and conflicts, based on error and caution rules.
  • the error and caution rules provide rule for comprehensively checking the conflicts among various widgets, errors pertaining to the databases, layouts, structures and the sections. Thus, certain errors or cautions that may have not been picked by the validation rules are identified during concurrent checking.
  • the application program may be collated.
  • the collation may be performed before the application program is deployed on a target device. Further, the collation may include generation of a source code corresponding to the one or more selected widgets and appending of the source code in corresponding section of the application program.
  • the source code may be generated based on the target programming language selected in the project options. If the selected programming language is C#.NET, then the source code can be generated for C# .NET programming platform. Accordingly, the source code may be generated in the selected programming language, and the generated code can be executed in accordance with the target programming language's specification.
  • the present subject matter provides for development of application programs with minimal human intervention, thereby reducing the chances of human errors and reducing the time, both human and computational, required for application development process. Additionally, the use of multiple checkers and validators provide for reduction in errors. Further, the reduction in such errors may provide better performance of the application program and in turn the computing device hosting the application program. In addition to reduction in errors, the present subject matter reduces the time required to develop an application program with the use of widgets. As mentioned earlier, the widgets are pre- developed collections of source code that can be attached to the application program being developed. Thus, the widgets form a part of application source code. Further, the widgets are customizable and induce a smooth functioning of the desired tasks and functionalities in the application program. Thus, a developer may not have to write a code for a given task and may append the required code using widgets, which may be modified based on user inputs.
  • Fig. 1 illustrates a network environment 100 implementing an application program development system 105, according to an embodiment of the present subject matter.
  • the application program development (APD) system 105 may assist a plurality of user, such as developer, in developing an application program.
  • the users may access the APD system 105 through their respective user devices 1 10, such as a user device 1 10-1, a user device 1 10- 2,.. and a user device 1 10-n.
  • the user devices 1 10 may access the APD system 105 through a network 1 15.
  • the network 1 15 may be a wireless or a wired network, or a combination thereof.
  • the network 1 15 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and such.
  • the network 1 15 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), Transmission Control Protocol/Internet Protocol (TCP/IP), Virtual network, and cloud networks, etc., to communicate with each other.
  • HTTP Hypertext Transfer Protocol
  • HTTPS HTTP Secure
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • Virtual network Virtual network, and cloud networks, etc.
  • the user devices 1 10 and the APD system 105 may be implemented as a computing device, such as desktop computers, hand-held devices, laptops or other portable computers, tablet computers, and the like.
  • the APD system 105 may include a processor 120, interfaces 125, memory 130, modules 135, and data 140.
  • the processor 120 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that manipulate signals based on operational instructions.
  • the processor(s) is configured to fetch and execute computer- readable instructions stored in the memory.
  • processors may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software.
  • the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared.
  • explicit use of the term "processor” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), non-volatile storage.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • ROM read only memory
  • RAM random access memory
  • the interface(s) may include a variety of software and hardware interfaces that allow the APD system 105 to interact with user devices 1 10, and other computing devices, such as web servers and external repositories, such as database 145.
  • the memory 130 may be coupled to the processor 120 and may include any computer-readable medium known in the art including, for example, volatile memory (e.g., RAM), and/or non-volatile memory (e.g., EPROM, flash memory, etc.)
  • volatile memory e.g., RAM
  • non-volatile memory e.g., EPROM, flash memory, etc.
  • the modules 135 include routines, programs, objects, components, data structures, and the like, which perform particular tasks or implement particular abstract data types.
  • the modules 135 further include modules that supplement applications on APD system, for example, modules of an operating system.
  • the modules 135 can be implemented in hardware, instructions executed by a processing unit, or by a combination thereof.
  • the processing unit can comprise a computer, a processor, such as the processor 120, a state machine, a logic array or any other suitable devices capable of processing instructions.
  • the processing unit can be a general- purpose processor which executes instructions to cause the general-purpose processor to perform the tasks or, the processing unit can be dedicated to perform the functions.
  • the modules 135 may be machine-readable instructions (software) which, when executed by a processor/processing unit, perform any of the described functionalities.
  • the machine-readable instructions may be stored on an electronic memory device, hard disk, optical disk or other machine-readable storage medium or non-transitory medium.
  • the machine-readable instructions can be also be downloaded to the storage medium via a network connection.
  • the data serves, amongst other things, as a repository for storing data that may be fetched, processed, received, or generated by one or more of the modules.
  • the module(s) 135 includes, for example, a server- action manager 150-1 , a server-layout manager 155-1 , a collator 157, a change management unit 160, a server- concurrent checker 165-1 , and other module(s) 170.
  • the other module(s) include programs that supplement applications or functions performed by an infrastructure support optimization system, such as the APD system 105.
  • the data 140 serves, amongst other things, as a repository for storing data obtained and processed by one or more module(s) 135.
  • the data 140 includes, for example, subscription data 175, widgets and widget packs 180, projects data 185, and other data 190.
  • the other data 190 includes data generated as a result of the execution of one or more modules in the other module(s) 170.
  • a user may corresponding user device, say user device 1 10, may access the APD system 105 to develop an application program.
  • development of an application program includes both creation and modification of the application program.
  • the user may access the APD system 105 to create a new application program or may modify an already created application program, which may be stored in the projects data 185.
  • the application program may include codes pertaining to various sections, each section including codes to achieve desired functionalities, codes for desired layouts, and codes for associating the application program to one or more databases, such as the database 145.
  • the user may perform an action, which may be provided to the action manager 150.
  • the action manager 150 may include a server side component 150-1 and a client side component 150-2.
  • the server side component may be referred to as server-action manager 150-1 and the client side component may be referred the client-action manager 150-2.
  • the client-action manager 150-2 may be provided on the user device 110. Further, the server-action manager 150-1 and the client-action manager 150-2 may be collectively referred to as the action manger 150.
  • each component of the action manager 150 may include a plurality of development units as will be explained in detail with reference to description to Fig. 2.
  • Each development unit may assist in developing an attribute, such as database, logic, and layout of the application program.
  • the received action may be first analyzed at the client-action manager 150-2, and based on the analysis, may be provided to a development unit for validation.
  • the action may be provided to a widgets and widget packs unit (shown in Fig. 2).
  • the user may then provide the inputs to configure one or more widgets based on application program requirements.
  • pre-developed code snippets corresponding to the widgets may be stored in the widget and widget packs 180.
  • the action may be provided to a layouts unit (shown in Fig. 2).
  • the layouts unit may be interfaced with a client- layouts manager 155-2 to develop the layout of the application program.
  • the layouts manager 155 may include the client-layouts manager 155-2 and a server layouts manager 155-1.
  • the client layouts manager 155-2 may assist in developing the layouts at the client side and the server layouts manager 155-1 may assist in developing the layouts at the server side.
  • the APD system 105 provides a user-friendly interface, where users can create, for example, "blocks” or "shapes" on the screen using client layouts manager 155-2.
  • the server layout manager 155-1 may validate whether right data have been passed through the client layouts manager 155-2, and if appropriate, it may be determined whether parameters that define the created layout have been included or not. If validated, the data pertaining to the layouts may be stored in projects data 185, which may include a unit for layouts.
  • the action may be provided to corresponding development unit for assisting the user in developing the application program. Further, if a received action is validated at the client-action manager 150-2, the action may be passed to the server-action manager 150-1, where again similar analysis and validation may be performed. The actions may be performed on the application program and may be stored in the projects data 185. For example, the user may provide multiple actions through the client action manager 150-2 and the actions may be auto saved or may be saved based on user input. Upon saving, the actions may be validated by the client-action manager 150-2 and if validated, are provided to the server- action manager 150-1.
  • the concurrent checker 165 may also have a client side component, a client- concurrent checker 165-2, and the server concurrent checker 165-1.
  • client action manager 150-2, the client layouts manager 155-2, and the client concurrent checker 165-2 have been illustrated in user device 1 10-1, however it will be appreciated that the client-action manager 150-2 may be provided in other user devices 1 10 as well.
  • the actions may be checked for probable conflicts and errors by the concurrent checker 165, before the collation of the application program, i.e., before the generation of the application source code.
  • the concurrent checker 165 may check for probable conflicts and errors based on errors and caution rules.
  • the client concurrent checker 165-2 may periodically call the server-concurrent checker 165-1 to receive an updated list of errors and cautions, which may have been identified by the server- concurrent checker 165-1 previously.
  • the updated list of the errors and cautions may help the user is avoiding such errors in future actions.
  • the errors may relate to incorrect widget settings. For example, in a file manipulation widget, if "Create a file” is selected, and although the widget asks "which file” or "how to find the file", the value may be left blank by the user; then in such a case the widget may report this to the concurrent checker 165 in the next checking cycle that in the File Manipulation widget, "which file” parameter has been left blank.
  • the user may select a Fetch Records widget to get records from the database and the user may select a database that has no structures in it. Further, the user may save the changes and move further. In this case, the Fetch Records widget may report to the concurrent checker 165 that the "Which database should be used" is not suitable.
  • some widgets, while configuring, the user may be requested to "select a section" in their configuration options. If the user selects a section, which is different from the section that the widget resides in and saves the widget and later the selected section deleted. The widget may find an invalid section selection for one of its options, which will be reported to the concurrent checker 165. [0043] Further, the errors may relate to incorrect project settings.
  • the errors may relate to incorrect section hierarchy. Such an error may be identified when a section has a duplicate name, or only symbols, etc.
  • a portion or whole of the application program may be collated using the collator 157 anytime during the development process.
  • the collator 157 may collate source codes corresponding to various sections of the application program and upon collation may provide the collated code to a compiler (not shown in the figures) for compiling the application program.
  • the collator 157 may collate the source codes pertaining to the selected section.
  • the collation may include, among other things, initiating execution of widgets to generate corresponding source codes, gathering source code generated by various widgets, appending the source codes in a corresponding section to generate a source code of the selected portion in an organized and clean format, as will be explained in detail in subsequent figures.
  • the selected portion may include all the sections of the application program.
  • the source code of the application program may be referred to as application source code.
  • the collated application program may be deployed on a target device using the change management unit 160.
  • the change management unit 160 may store each deployment instance of the application program as a version for future use.
  • the change management unit 160 may provide a list of the deployments for a current project. For instance, if the user has deployed the project ten times using the system 100, the list may ten entries, where each entry may be treated as a different version. Further, the change management unit 160 may allow the user to deploy each version separately.
  • the change management unit 160 will be explained in detail with reference to description of Fig. 2.
  • the functionality of the APD system 105 may be provided as a paid service to the users. Further, the users may be provided the option to subscribe to one of the packages. In an example, higher the monetary value paid by the user, wider the range of functionalities may be provided. For instance, based on the package, the number of widgets made available to a user may increase and the number of application programs that a user can develop may increase.
  • the information pertaining to user subscription may be stored in the subscription data 175, which may used by one of the other modules 170 to gather information pertaining to the user.
  • a widget and widget packs unit may provide access to the user to a given set of widgets and/or widget packs and may be allowed to develop a predetermined number of application programs.
  • the APD system 105 may include a locale manager
  • the locale manager may allocate numbers to the messages, i.e., set of codes, written in default-set or primary language, and allows the widgets to use numbers to represent these messages, so that the application program can be programmed to display messages in any supported language selected by the user.
  • the locale manager may support Unicode and may provide for display of messages in any vernacular language.
  • the APD system 105 may provide the user a cell-grid view, where the first row may allow a different language to be selected in columns except the first.
  • A2 can be English
  • A3 can be Spanish
  • the first column may be reserved for string IDs.
  • messages pertaining to or translated in that column's selected language can be typed or copy pasted. Accordingly, each message is associated with a string ID. Users can use that string ID to represent a message that is available in different languages.
  • the application program that is generated may have all the messages in all the added languages.
  • the messages that appear on the user device may be dependent on a language selected by the user.
  • the widgets also allow changing the language on the user side using the string IDs.
  • Fig. 2 schematically illustrates various components of the APD system 105, in accordance with an embodiment of the present subject matter, according to an embodiment of the present subject matter.
  • the user device 110 may be interfaced with the action manager 150, the layouts manager 155, the collator 157, the concurrent checker 165, and the change management unit 160.
  • every action provided by the user may have an action ID associated with it.
  • the action ID may correspond to a development unit to which it relates to.
  • the action manager 150 may include multiple development units, such as a project settings unit 204, a databases unit 206, a structures unit 208, a sections unit 210, a programs unit 212, a layouts unit 214, a widgets and widget packs unit 216, and a fields unit 218.
  • development units such as a project settings unit 204, a databases unit 206, a structures unit 208, a sections unit 210, a programs unit 212, a layouts unit 214, a widgets and widget packs unit 216, and a fields unit 218.
  • the action manager 150 may identify the corresponding development unit and information pertaining to the action IDs may be stored in the other data 190. Further, each of the development units may validate the received action using the validation rules.
  • the validation rules may include checks for, for example, inclusion of special characters and syntax related errors.
  • action manager 150 For the sake of brevity, the foregoing description of the action manager 150 is explained in general without referring to the client and server components; however it will be appreciated the description may be valid for both the client and the server components. Further, in various implementations, only server-action manager 150-1 or only client action manager 150-2 may be provided.
  • the action is provided to the project setting unit 204.
  • the project settings unit 204 may validate the action based on corresponding validation rules. For instance, the validation rules may return an error in case name of a project is not of a predetermined character length or includes a restricted character.
  • the project setting units 204 may provide details pertaining to all the projects being handled by the user and interface the each project with a corresponding project file.
  • the project file may include various details, such as date of creation, date of last modification, list of various sections, structures, and associated databases.
  • the action is provided to the databases unit 206.
  • the databases unit 206 may validate the action based on corresponding validation rules. Further, the action may relate to database attributes illustrated in Fig. 3a. As illustrated, the databases unit 206 may assist the user in actions relating to the database attributes, such as a database name 305- 1 , structures 305-2, a platform 305-3, and database flag(s) 305-4.
  • the user may provide inputs pertaining to each of the database attributes, such as name of the database to be created and underlying platform, such as ORACLE ® and SQL ® .
  • the provision of choosing the platform of the database provides for platform independent creation of the application programs, i.e., the user may not be restricted to select only a particular platform for the database. Additionally, in case back-up database is created, the back-up database may be of a different platform as compared to the main database. Thus, the present matter provides the flexibility of choosing the platform of the databases to be created. Further, the user may also provide actions to modify the name or the platform of the databases already created.
  • the user may also provide inputs pertaining to the database flags 305-4, which may include special instructions for advanced users.
  • a database '#ND' informs a deployer 224 to not deploy the database while initial deployment. This may be useful in case the user wants to deploy the database himself.
  • a database flag '#NC informs the collator 157 to not create the databases at all.
  • a database flag '#CP " 123456"' informs the deployer 224 to change the database password to 123456 after deployment.
  • the database may include multiple tables, which are provided by way of the structures 305-2.
  • the structures may be understood as set of data containers that can hold information in different columns. Each column may become a table's field upon deployment and each structure may become a database table on deployment.
  • the database tables are used for several purposes, such as storing customer lists, phone numbers, user-access permissions, error logs, and in many situations, customer- provided data. Accordingly, a database may be understood as a set that holds various structures.
  • the actions pertaining to the structures 305-2 may be processed using the structures unit 208.
  • the structures unit 208 may validate and process the actions pertaining to the structure attributes illustrated in Fig. 3b.
  • the structure 305-2 may include a structure name 310-1 , field(s) 310-2, structure flag(s) 310-3, and structure element(s) 310-4.
  • the structure name 310-1 and structure flags 310-3 may be considered to be similar to database name 305-1 and database flags 310-4.
  • the structure elements 310-4 may include, for example, keys 315-1 and attributes 315-2.
  • the keys 315-1 may aid in defining keys, such as primary keys and foreign keys.
  • attributes refer to information that is requested for a particular database, structure, field, section, or widget etc.
  • attributes for databases may be:
  • attributes for structures may be:
  • the fields 310-2 indicate the various columns to be added in the structure 305-2.
  • the fields 310-2 may in turn include field attributes, for example, field name 320-1, field type 320-2, field size 320-3, field default 320-4, field order 320-5, and field flags 320-6.
  • field name 320-1 relates to name of the field name, such as employee name and salary
  • field type 320-2 indicates the data type, such as strings, numeric, and alphanumeric, to be populated in a field
  • the field size 320-3 indicates the data size of data to be populated, such as character length
  • fields default 320-4 indicate the default value that is to be added, in case no value is provided by the user
  • field order 320-5 indicates the order in which various fields should be added in a structure
  • field flags 320-6 are similar to structure flags 310-3 and indicate special instructions that may be provided for advance users.
  • the structures unit 208 is interfaced with both the databases unit 206 and the fields unit 218.
  • the actions pertaining to fields may be provided to the fields unit 218 for further processing and analysis.
  • the databases unit 206, the structures unit 208, and the fields unit 218 simplify the process of database creation, by using the entered information and translating it into physical databases and tables, and data- columns.
  • the structures and fields may be used by the widgets and widget packs unit 216 to link and filter information.
  • An example of a pseudo code in JSON format for creation of a structure is provided below:
  • the sections unit 210, the programs unit 212, and the widgets and widget packs unit 216 assist in developing the various sections of the application program.
  • the action is provided to corresponding development unit for further analysis and validation.
  • the action may be provided to the sections unit 210.
  • Sections may be understood as sets of different parts of an application program that are converted into individual pages, upon deployment. Further, a section may include programs that hold a desired functionality, which may be brought through the widgets.
  • a program may be considered to be a collection of pieces of codes that are present in a single source-code file.
  • Development of a section may include defining of various section attributes, for example, a section name 325-1 , a section description 325-2, a section layout 325-3, a parent section 325-4, a program 325-5 corresponding to the section, and section flags 325-6.
  • the sections name 325-1 indicates a name of a section.
  • the section description 325-2 indicates a description of a section provided by a user. The user may provide such descriptions, for example, to avoid confusion among similar sections.
  • the parent section 325- 4 indicates a section to which a current section may refer to.
  • Program 325-5 may be automatically created upon creation of sections. However, the programs 325-5 may be created manually as well.
  • the section flags 325-6 may be understood to be similar to flags defined above.
  • the section layout 325-3 may indicate a layout to be developed for a section of the application program.
  • the sections unit 210 may couple to the layouts unit 214, which in turn may be coupled to the layouts manager 155.
  • an action pertaining to creation or modification of a section may be provided to the sections unit 210, which may process and validate the action. Accordingly, the user may only need to provide information pertaining to one or more section attributes and a section may be created and/or modified accordingly.
  • the layouts may be accessed by the collator 157 to apply the designs to sections.
  • the layouts manager 155 may be used to create an interface for a "Create Employee" section.
  • each section may include a program 325-5, which in turn may include one or more widgets 330 as illustrated in Fig. 3d. Further, the widgets 330 may be developed using the widget and widget packs unit 216. As illustrated in Fig. 2, the sections unit 210 may be interfaced with the programs unit 212, which in turn may be coupled to the widgets and widget packs unit 216.
  • the widgets and widget packs unit 216 hereinafter referred to as widgets unit 216. Further, the widgets unit 216 may provide a user with a list of widget and widget packs, where each widget 330 corresponds to a pre- developed code snippet to achieve a desired functionality.
  • Examples of the widgets 330 include widget for multiple database connections, query generators, add records to database, delete records from a database, fetch records from a database, modify records from a database, accept user input through fields, session management, file manipulation, file input/output, string manipulation, array manipulation, data manipulation, logical manipulation, mathematics, communications, information exchangers, graphical user interface (GUI) messaging, data exchangers, import/export, uniform resource locator (URL) flow, charts and graphs, conditions and loops, big-data widgets, NoSQL database widgets, and API connectors.
  • GUI graphical user interface
  • the query generator widget may be used for generating insert, select, update, delete, truncate, and alter queries;
  • the file manipulation generator widget may be used to create, delete, move files and folders, check permissions, get list of files and folders;
  • the string manipulations widget may be used to declare string variables, store or read data from the variables, perform string specific operations, such as find and replace, find indexes, and substrings;
  • the big-data widgets may aid in storing data using big-data storage techniques.
  • the widgets 330 may be provided by way of a widget pack.
  • the widget pack may include multiple widgets 330 to achieve a desired functionality.
  • widget packs include, but are not limited to, login pack, registration pack, user permission pack, add, edit, delete, display data pack, search and filter pack, business reports pack, data logging and error reporting pack, scheduled database backups pack, newsletter subscription pack, interactive calendar pack, hints and tooltips pack, client-side localization pack.
  • the login pack widget pack may be used for creating a login mechanism, which may involve multiple sections and widgets.
  • the login pack may include database access widgets, fetch records widgets, array manipulation widgets, and GUI messaging widgets, and login- success widgets, login-failure widgets, forgot-password widgets, and login form widgets.
  • the widgets may be spread across various sections and which may be linked together at the time of collation of the application program.
  • the business reports pack may be used for creating financial and project management reports.
  • a user may select a widget pack corresponding to that functionality thereby saving on time and efforts.
  • a user may configure the widgets 330, using the widgets unit
  • the widgets may be configured, for instance, the user may provide inputs pertaining to layout of the form, fields in the form, the database on which the data is to be placed and the like.
  • the user may provide details, such as number of data channels, filtering options for each data channel, and server IP addresses.
  • the two widgets may be interlinked to achieve the desired functionality.
  • an action pertaining to a widget may be provided to the widgets unit 216.
  • widget attributes such as a localization information 335-1, an internal name 335-2, client side configuration attributes 335-3, and server side configuration attributes 335-4 may be defined by a user, such as an application developer, based on user preferences.
  • attributes refer to information that is requested for a particular database, structure, field, section, or widget, etc.
  • the internal name 335-2 may be a name of widget provided by a user for widget and may be different from a pre-stored widget name.
  • the client side configuration attributes 335-3 may include option name 340-1, element type 340-2, group name 340-3, localization information 340-4, option name 340-5, and option value 340-6. Further, server side configuration attributes 335- 4 may include option name 345-1 and option type 345-2.
  • the action manager 150 provides for validation and analysis of received actions to develop the application program. Further, as mentioned before, a dual validation may be performed, i.e., once at the client side, or to say the user device 100, and once at the server side, or to say the APD system 105. Once both the validations are positive, the action being tested may be executed and may be added to the project file. However, in case, the client-action manager 150-2 ascertains that the received action is not valid, the action may be dropped and an error may be logged.
  • an action is validated by the client-action manager 150-2; however the action is not validated by the server- action manager 150-1 , the action may not be: executed and may be dropped. Additionally, the client-action manager 150-2 may temporarily store the actions prior to sending the actions for server- side validation.
  • the client-action manager since the validators at the client-action manager will not permit and invalid action to be added, there is a very low probability that an action will reach the server validators without being properly validated and approved by the client-side validators. Therefore, the client side may assume that its validators are reliable, and it will allow the user to perform actions without bothering him to save them after every few steps.
  • the action manager 150 also provides for reversal of an action, i.e., undoing an action, based on action identifiers. Such a provision lets the user to modify the steps that were taken while creating the application program. Such steps may relate to, for example, sections, structures, fields, databases, and widgets.
  • the actions manager 150 may prompt the user to provide inputs that aid in determining the action identifiers corresponding to such actions. For instance, the user may provide a delete operation for deleting a section or a layout. Accordingly, based on the inputs, the selected actions may be deleted from the projects file stored in the projects data 185.
  • the deletion of actions using the actions managers 150 ensures that unchecked, erroneous, and incomplete codes are not kept in the application program to have zero or minimal syntax error-potential; and therefore is different from simple un-doing of changes on a source-code of an application program. For example, since, all the actions are validated before being saved at the APD system 105, which in turn ensures that only validated actions can affect or make changes to the application program. Therefore, unchecked and erroneous codes may not be generated. Further, the action reversal functionality may be provided at both client and server end only difference being in their coding technique / technicality, such as programming language, etc. [0074] Thus, the users can use the action reversal functionality of the actions manager
  • the actions manager 150 provides for recording of all actions performed by the user including, but not limited to, creation, editing, and deletion of sections, structures, databases, layouts, widgets, and programs, etc., so that the user, if he wishes, may revert to an action in order to undo certain undesired additions or changes.
  • the layouts manager 155 in addition to development of databases and underlying logic, the user is also provided with the option of developing layout of various sections. The same may be achieved using the layouts manager 155. As illustrated in Fig. 2, the layouts manager 155 is coupled to the layouts unit 214, which in turn is coupled to the sections unit 210 and the programs unit 212.
  • the layouts manager 155 allows the users to design, develop, and include various layouts and business reports in the application program. For example, the layouts manager 155 assist the user in developing reports, graphical user interfaces, and attractive Hyper Text Markup Language (HTML) designs powered with JavaScript.
  • HTML Hyper Text Markup Language
  • the layouts manager 155 allows the users to define the layout style, layout type and layout settings to allow maximum flexibility.
  • the layouts manager 155 also allows the users to drag and drop various user-interface components, configure functionality and physical appearance of the user-interface components, form fields, data fields, and text fields to pages.
  • the layouts manager 155 accepts and exchange data from/to the widgets.
  • the data provided by the user is automatically recognized and based on the available content, the data is fit onto a layout according to the user-specified format.
  • the available content can be an HTML output, a text output, an image source, a link, depending on which widget is sending it.
  • the content goes in specific data holders. Each data holder has a specialized GUI component and has its own configuration just as widgets do, except that they don't need to be executed on the server.
  • the layouts may be dynamic in nature for allowing changes. However, there may also be a static version that can be exported in a digital document format, such as portable document format (PDF), doc, docx, or xls.
  • PDF portable document format
  • the layouts manager 155 may develop a layout based on inputs provided by the user regarding various layout features, such as documents, scopes, pallets, data holders, and themes.
  • a document may be understood to be a collection of scopes that holds them in one set.
  • a document can be treated as one printable page.
  • a document may have no fixed size and may be stretched without pixel-blurring to any extent depending on the content.
  • the layout manager 155 may implement vector graphics technique to avoid pixel blurring.
  • a document may be printed and exported in any standardized size.
  • a scope may be understood to be a collection of pallets that holds them in one set.
  • a scope like the document, may have no defined width, but it may have a defined height according to the requirement.
  • the scope of a document can also be stretched according to size of the document.
  • the scope may be themed using theme manager component of the layouts manager 155.
  • the scope may have a priority associated with it, may allow the layout manager 155 to arrange scopes in the order of relevance.
  • the priority may be provided by the user.
  • the priority may also be over-ridden by widgets. For instance, in certain cases, a widget can be- used in specific circumstances when a scope needs to be brought on the top of the page, or a certain kind of sorting of scopes needs to be achieved.
  • a pallet may be understood to be a collection of data-holders and fields arranged, for example, horizontally and/or vertically, according the design specification provided by a user. Further, the pallet may not be rasterized. The pallet may be defined in terms of percent values that describe their width and height. Further, the pallet can have width and height values, according to the design specification. This in turn may allow the users to create layouts as per the desired layout style. Further, a pallet can be themed according to styles specified in corresponding parent scope. Similar to scopes, the pallets may have priority defined, but it may be overridden by the surrounding components as per relevance.
  • a data holder may be understood to be a data receiver packed with scripts that receive data from the widgets.
  • Examples of data holders include, but are not limited to, buttons, menus, icons, labels, lists, tabs, graphs, charts, and customized GUI components inherited from one another.
  • the user may provide inputs indicating what data is to be provided to which data holder.
  • the data-holders may be generated using client-side script, such as Javascript and the data holders, when executed, may render HTML CSS as an output.
  • the data holders may be used to import the data to the sections, during runtime, by source code of the widgets included in the sections. For instance, data-holders may accept inputs and pass the input to the collated section file.
  • the imported data may then be used for performing a required task, for instance, to draw a bar graph.
  • the data holder may hold any data type, based on the design specification provided by the user.
  • the data holder may have fields arranged as per priority, which may allow the layouts manager 155 to arrange fields as per relevance.
  • the data holders may provide for changing settings, for example, width, height, and theme combinations.
  • the user may through the layouts managers 155 using the data holders can set certain permissions, such as AllowResize, AllowArrange, AllowSort, Allowlnvert, AllowTranspose, AllowCopy, in order to allow or disallow end users from manipulating the outlook and information stored in the data holders.
  • the data holders may have two parameters, one being a data holder program and other being the data.
  • the data holder program parameter may be provided on the client side and may indicate how the data holder should behave.
  • the data holders may be code snippets, which may be available at the client-layout manager 155-2 to allow dynamic access to the layouts.
  • the data parameter may be used while executing the data-holder program.
  • There may be various types of data holders, such as tabular data holder, image data holder, textual data holder, and graphical data holder.
  • the tabular data holder may contain another tabular data holder, image data holder, textual data holder, graphical data holder, or actual tabular data.
  • Tabular data holders can be arranged column-wise, sorted, shuffled, inverted, transposed, copied, and pasted.
  • the tabular data holders form HTML ⁇ table> tags, which may be created and changed dynamically.
  • the image data holder may include an image.
  • the image can be from a relative or absolute URL, or direct data encoded using a binary-to-text encoding technique, such as Base64.
  • Image data holders allow the end users to rotate, change the brightness and contrast, scale, crop, and save the image based on the user-specified settings.
  • the textual data holders may include only textual data.
  • the textual data holders may allow change of character casing, font-size, and text decoration operations.
  • graphical data holder may include graphs, charts, and other graphical components.
  • the data holders may be understood to include three segments, an appearance segment, a hierarchy segment, and an event segment.
  • the appearance segment may be used to store user-interface settings, such as sizes and ratios.
  • the user-interface settings may be typically set by the user while designing a layout.
  • the sizes and ratios may be used to determine the sizing of the component in a layout.
  • the layouts are vector based, the layouts can be scaled to infinite resolutions, except when they have raster based backgrounds.
  • the hierarchy segment may be used to inherit traits from a parent data holder.
  • a data holder may inherit from another data holder.
  • new data holders may be created from the previously created ones without having to start from scratch, thereby saving on time and resources.
  • the layouts for various windows that open on clicking a tab already provided on the menu may be created using the concept of inheritance.
  • a bar graph data holder may include some basic components, such as labels and buttons.
  • a bar graph may include labels containing the legend of notations that may inform the users of different aspects of a bar graph using titles and colors. The titles included in a bar graph are typically provided using "Label" data holder, and the buttons typically provided using "Buttons” data holders.
  • each data holder has its own events, the inherited data holders events are imported while linking one data holder to another.
  • the events of inherited data holders may be kept intact or may be overridden as needed; which in turn allows the data holders to perform their functions regardless of programming demands received by inherited data holders.
  • the event segment may include overridden client-side script events, such as Javascript events.
  • each data holder may offer blank functions, which may be executed by the data holders during when an overridden client-script event is encountered.
  • there may be a blank function which may be executed after each click on a certain part of the visible component of a dataholder and the user may change the blank portion, if required.
  • the newly mentioned code may be executed during each click instead.
  • a button can be programmed to refresh the page after the click, or it can be programmed to submit the input specified in a form to a specific section upon click, etc.
  • the data holders may be Javascript objects and may be programmable, i.e., user-specific events may be associated with the objects.
  • the objects may be programmed using Document Object Model (DOM).
  • DOM Document Object Model
  • the DOM may be used to link data holders to widgets in a project. Accordingly, widgets, when collated, may import data to the user device. The data may be imported to user-specified data holders.
  • the programmable events or the overridden client-side scripts may provide the users an opportunity to configure a data holder to behave in a certain way.
  • the event segment may also include pre-programmed events, which may be reserved for internal use only.
  • the pre-programmed events ensure that a data holder behaves in a desired way.
  • An example of a pre-programmed event of a "Button" data holder is a hover event, which is used to change the appearance of the button upon hovering in order to give the impression of change of state of the button from "active" to "hovered”.
  • the pre-programmed counterparts of a data holder may be executed first followed by a corresponding programmable event. Consider a click event on a bar graph data holder.
  • the preprogrammed click event will be fired first, followed by the programmable click event.
  • the programmable click event can be configured by the user to do a specific task, such as fire an explicit function of a widget, or perform actions mentioned in GUI widgets.
  • a theme can be prepared using the theme manager component.
  • the theme manager component provides for selection of backgrounds and borders with the desired colors, which in turn may be applied to the pallets.
  • the theme manager component also provides for creating cascading style sheets and applying them automatically without manual programming.
  • the user may provide inputs, which may pertain to color shades, textures, borders, relative sizes, ratios, etc., to the layouts unit 214, which in turn may provide the same to the layouts manager 155, which may assist in developing the layout.
  • priority of one or more of the layout features may be overridden by the user using the client-action manager 150-2 and a widget, such as a GUI widget. This may allow most relevant content to be shown at the top of the page.
  • the layout rendering may be performed by web browser engine of the user device 1 10 and the actions of sorting and organizing may be performed by the client-layouts manager 155-2.
  • the client-layouts manager 155-2 may sort all the documents in ascending order of priority. Further, each document may be drawn into a loop. For instance, if a page has three documents, then the documents will be drawn one by one, one below another, based on the priority.
  • each document all the scopes may be sorted in the ascending order of priority. Further, all the scopes in a document may be drawn in a loop. Finally, in each scope, all pallets may be arranged in the ascending order of priority and then each pallet is drawn. Further, the selected themes may be associated with the scopes and the pallets.
  • Width ⁇ width%>
  • Width ⁇ width%>
  • the concurrent checker 165 contains a server side component and a client side component for checking for probable errors and cautions as will be explained in detail with reference to description of Fig. 5.
  • the code may be collated and generated using the collator 157; and may be deployed using the change management unit 160.
  • the change management unit 160 allows the users to collate a project several times after making one slot of changes and to retrieve the previously collated projects, if desired.
  • the change management unit 160 may also employ a version control functionality, which may store the application program for a project as one version as against traditional way of storing the project as a set of written codes. Traditionally, version control tools store individual files that may or may not be changed; however, the change management unit 160 holds all actions and the corresponding results that were a part of the project before the project was collated in the project data 185.
  • the change management unit 160 allows the user to go back and forth between critical changes without tampering the integrity of the application program by changing the source code. Further, the input from the user may indicate to collate the application program with new settings, or use an existing change saved previously.
  • an application program relates to generation of a list including employees in a firm.
  • the user may develop and subsequently deploy the application program on the firm's server.
  • the time of deployment and the date of deployment of the application program may be stored by the change management unit.
  • the change management unit may store certain new features, such as petty cash transactions.
  • the user may re-open the application program using the APD system 105, to create the Petty cash functionality, and deploy again. Again, upon making the change, an entry is added to the Change Management along with the date.
  • the change management unit 160 is interfaced with a deployer 224, a collator initiator 220, and a collator 157.
  • the collator 157 may be configured to collate and generate source code of a selected portion of the application program or entire application program, based on the user input.
  • the user may provide the input to the collator initiator 220, which may analyze the input to determine whether a portion or the entire application program is to be collated.
  • the user may be allowed to collate the entire application program only when the concurrent checker 165 returns no errors and cautions.
  • the collator initiator 220 may create a collator thread on the fly.
  • the collator thread would perform the similar function as that of the collator 157 but only on the portions selected by the user.
  • the collator thread collates and subsequently provides for testing of the selected portions on a testbed server.
  • the collator thread created on the fly i.e., an auxiliary collator, allows the user to select the sections he wants to collate.
  • the auxiliary collator copies the project in temporary storage of the server, removes the section that the user did not select, and only keeps the sections that were selected, in the application program.
  • the selected portion is then collated by the collator 157 and subsequently, the deployer 224 deploys the collated code on the testbed server.
  • the user may provide a request to collate and test a selected portion of the application program. This allows simultaneous testing to be possible after completion of each section and, the configuration of all the widgets contained within it.
  • the user may provide a request for final collation to generate the source code of the application program and for subsequent compilations.
  • the user may provide a request to the deployer 224 to deploy the application source code, i.e., the application program on a target device.
  • Fig. 4 illustrates the widget unit 216 of the APD system 105, according to an embodiment of the present subject matter.
  • the widget unit 216 allows for selecting and configuring of the widgets, such as the widget 330.
  • the widgets allow manipulations on several factors, such as database connections, encryption techniques, user redirection, browser recognition, maps integration, geo-location recognition, linking with other application programming interfaces (APIs), managing user sessions, files manipulation, interlinking sections, data conversion, signal processing, data mining, data projection, and code injection.
  • APIs application programming interfaces
  • the widget unit 216 may include a client side component, referred to as a client- widget unit 405-1 , and a server side component, referred to as a server-widget unit 405-2.
  • the client-side widget unit 405-1 may include a client side validator 410-1 and may be coupled to a temporary storage 415.
  • each development unit may validate the action, based on corresponding validation rules. Accordingly, the client-side validator 410-1 validates the received action to ensure that the action does not include, for example, basic errors, such as syntax errors, and to provide protection against hacking and other malicious activities.
  • the temporary storage 415 may include actions pertaining to the widgets before the action is provided to the server-widget unit 405-2.
  • the temporary storage 415 may include user inputs for configuring a widget and errors identified by the client-side validator 410-1.
  • the action may be provided to the server-widget unit 405-2.
  • the server-widget unit 405-2 may include a server side validator 410-2, error logging unit 420, and a configuration assistance unit 425.
  • the server side validator 410-2 like the client side validator 410-1 , validates the received action, based on the validation rules. This ensures dual validation of the received action for better security and efficient utilization of resources. In case validation check returns any validation error, the identified error may be stored in the error logging unit 420, and may be shared with the user device 1 10.
  • the data stored at the client side may be manipulated. Therefore, although an error that ideally should have been identified at the client-side, but is not caught during client side validation, due to hacking or manipulation attack, can be detected at the server side.
  • the configuration assistance unit 425 may assist the user in configuring the widgets. For example, based on user inputs including configuration details a widget or a widget pack from among a plurality of the widgets and the widget packs may be selected.
  • the configuration details may pertain to various widget attributes, such as name and value.
  • the configuration details may be stored and, when the application program is deployed, a source code of the widget may be generated based the configuration details. For example, in case the user selects an if-then-else widget, the pre-developed code of the widget may already include the logic of if-then-else, and the user may only need to provide the values for the various conditions, like, what value to pick if a parameter has a given value. Further, the configuration assistance unit 425 may regulate a smooth functionality of the computing system by defragmenting client-side temporary storage time-to-time.
  • the server- widget unit 405-2 may also be coupled to the collator 157 and the concurrent checker 165.
  • the concurrent checker 165 may check for probable errors and conflicts pertaining to widgets, based on the error and cautions rules. Referring to the example mentioned above regarding if-then-else widget, in said example, the user may indicate that when a particular condition is met, go to another widget. Thus, a widget may be linked to another widget. In such a case, the concurrent checker 165 may check whether linking the current widget with another widget may result in a conflict and accordingly may return an error to the user. Accordingly, the concurrent checker 165 may continue checking for such errors and conflicts, before the application program is collated, to ensure compilation process is smooth and efficient.
  • codes of various widgets may be collated using the collator 157.
  • the widgets unit 216 may interface with the collator 157 to generate corresponding codes of the selected widgets.
  • the widget units 216 may provide information pertaining to selected widgets and corresponding configuration details, and accordingly the collator may generate the source code.
  • Fig. 5 illustrates various components of the concurrent checker 165 of the
  • the concurrent checker 165 may include the server-concurrent checker 165-1 and the client- concurrent checker 165-2.
  • the server-concurrent checker 165-1 implements checking processes for both errors and cautions. Further, the server-concurrent checker 165-1 may collect results, for example, in an array, which may include the identified errors and cautions.
  • an algorithmic prediction of a likely fault may trigger a caution
  • an absolute prediction through general knowledge and hard-coded rules, may result in errors.
  • cautions are generated heuristically, i.e., intuitively; while errors are generated using known rules that will surely detect a fault. For example, using a sign in wrong place your equation may trigger a caution; while an error may be triggered when a value is divided by zero.
  • a caution may be different from an error as in case an error is identified, the user may not be allowed to proceed to collation, partial or complete, while in case a caution is identified, the user may still be allowed to proceed to collation process.
  • the user in case an error is detected, the user may be requested to rectify the error before the application program is collated, while in case of a caution, the user may be allowed to proceed to the collation without to make any change to address the caution.
  • the server-concurrent checker 165-1 may include, for example, a project checker 505 and a widgets checker 510.
  • the project checker 505 may loop through each of the components, such as sections, structures, databases, and layouts, of the application program except for widgets.
  • the project checker 505 may loop through each of the components to check for errors and cautions, based on the error and caution rules.
  • the error and caution rules may include checks for duplication of components, such as sections, structures, databases, or layouts; checks for properties of the components for possible restricted characters that are known to cause errors on server operating systems; checks for aborted, or left alone components, such as databases left without any structures, or structures without any fields in them.
  • the project checker 505 may check for errors and cautions for each component and may return a collection of errors and cautions identified in various components of a given portion of the application program.
  • the errors and cautions may be stored and may be provided to the client-concurrent checker 165-2, when requested.
  • the errors and cautions pertaining to widgets may be obtained by the widgets checker 510.
  • the widget checker 510 may initiate a widget with the user provided inputs, and upon initiating, the widget may call a validation function to provide probable conflicts and errors. Since every widget may correspond to a code that performs a unique task, the widgets checker 510 may not have specific conditions to match. In other words, based on individual widget requirement, corresponding probable error and caution rules may already be included in the widgets, which may be triggered by the widgets checker 510. Accordingly, widgets checker 510 may rely on individual widgets to provide inputs to the widgets checker 510 about possible errors, and cautions caused due to invalid widget configuration. Thus, new widgets may be added to the APD system 105 or previously added widgets may be modified without performing changes to the concurrent checker 165.
  • the widgets checker 510 may trigger each widget added in various sections of a selected portion of the application program to perform a check, based on the corresponding errors and cautions rules.
  • the received list of errors and cautions which is an updated array of errors and cautions, may be stored and provided to the client-concurrent checker 165-2, when requested.
  • an error may be identified when a conflicts among interlinked widgets is determined.
  • a caution may be returned, when it is determined that addition of a widget in a section may impact performance of the application program and may make the application program unstable. Additionally, there may be certain errors and cautions that may be determined by the widgets checker independently.
  • the client-concurrent checker 165-1 may include a server requester
  • the server requester 515 may periodically call the server-concurrent checker 165-1 , based on a trigger received from the timer 520.
  • the timer 520 after a predetermined time interval, may provide an input to the server requester 515, which in turn may request the server-concurrent checker 165-1 to provide an updated list of errors and cautions.
  • the updated list of errors and cautions may include a list of all errors and cautions identified so far for a given application program.
  • the list may be stored in the storage unit 525, such as a browser cache of the user device 1 10. Further, the list may be provided using graphical elements, such as icons or designs in the GUI. Additionally, the various entries in the list may also include details pertaining to the items that resulted in the error or the caution, which in turn may allow the user to keep a watch on the conflicts and may help in reducing the errors.
  • the concurrent checker 165 checks for conflicts and errors among various components of the application program and not the actual code, as the concurrent checker 165 performs the check, before collation and compilation, i.e., before the generation of actual source code.
  • the concurrent checker 165 also may not require the code to be in execution as in traditional debuggers.
  • the concurrent checker 165 may provide for reduction in number of errors. For example, in conventional APD processes, the compilation may provide multiple instances of the similar errors. However, in the present APD process, since the concurrent checker 165 continues to work in the background and checks for errors and conflicts in parallel to development process; therefore the users are informed about the errors in advance. Further, as the user would now have the prior information pertaining to errors, similar errors may be avoided.
  • Fig. 6 illustrates various components of the collator 157 of the APD system
  • the collator 157 based on the user inputs and pre-stored code snippets, generates a source code of the application program.
  • the collator 157 may create separate files according to the sections and store in the projects. data 185.
  • the collator 157 may merge the sections, if required.
  • the collator 157 may communicate with the selected widgets to request corresponding source code. Based on the inputs provided by the user regarding configuration of the widget, a corresponding source code is generated by the widget and provided to the collator 157.
  • the source code may be placed into the corresponding files.
  • the collator 1-57 may also reformat the generated code for maximum readability. As the widgets generate code that will be valid but may contain no spacing between lines, etc., therefore to make the code readable, the collator 157 may reformat the code without changing the underlying logic of the code. Finally, the collator 157 may generate scripts containing commands that would create the required databases, tables, and fields. These files may be used by the deployer 224 to create databases automatically on the target device.
  • the collator 157 may be interfaced with the deployer 224 and may include a collator handle 605, a collation recurser 610, a project collator 615, a program collator 620, and a widget collator 625.
  • the collator handle 605 may function as a common platform for other development units to communicate to each other.
  • the collator handle 605 may allow the server-side component of widgets and other development units to access shared memory space for easy information exchange.
  • the collator handle 605 may include a collator stack, a collator access list, collator errors, collator flags, and current data.
  • the collator stack may be shared memory for the widgets and the widgets may use collator stack, for example, for storing variable names and common values.
  • the collator access list may be shared list-style memory for the widgets and may be used by the project collator 615, the program collator 620, and the widget collator 625 for references of the source code files.
  • the collator errors may be shared memory for storing errors and cautions encountered during collating process, the collator flags may correspond to expert instructions for expert use, and current data may be reference to the current section being accessed, and references to current program and widget as well.
  • the project collator 615 may loop through all the sections and create a directory hierarchy for keeping source code organized.
  • the project collator 615, while looping through sections, may also create empty files in which the source code for that section can be placed.
  • the project collator 615 creates initial entries containing project related data in the collator handle 605.
  • the project related data include all information pertaining to the application program, such as information pertaining to sections, structures, fields, databases, widgets, widget-packs, and localization.
  • An example of pseudo code for the project collator 615 is provided below:
  • the project collator 615 may call the program collator 620 for each section in the loop.
  • the program collator 620 may loop through all the widgets included in the program and gather source code of each widget.
  • the source code provided by each widget may be appended into the section file.
  • the path of the section files may be stored in the collator handle 605.
  • the program collator 620 may assemble the source code of the widgets in the program.
  • the program collator may call the widget collator 625.
  • the widget collator 625 may ensure that the widget's server side script is existent and is valid.
  • the widget collator 625 may request the configuration assistance unit 425 to provide widget configuration details.
  • the widget configuration details may be provided by the widget collator 625 to a corresponding widget, which may generate a source code, based on the configuration details provided in a user input.
  • the widget collator 625 may call the widget recurser 610 to aid in collation of source code of the widgets, if required.
  • the collation recurser 610 may allow one widget to request another widget to be collated on demand.
  • the collation recurser 610 may be used in cases where one widget needs the source code from another widget. For example, the collation recurser may be used while collating an if-else widget.
  • the if-else widget allows users to add conditional checks and balances.
  • the if-else widget may request the user for a list of conditions and details pertaining actions that are to be performed if those conditions are met. In certain cases, the user may add other widgets in between multiple conditions.
  • the collator recurser 610 may ascertain, for each of the widgets, whether a widget refers to another widget and collate a source code of another widget to the source code of the widget, when the widget refers to another widget.
  • each widget may have a code generator function, which when called by the widget collator 625 may generate the source code based on the configuration details for particular combinations of sections, structures, fields, databases, and layouts. Further, the widget collator 625 may return the generated source code in multiple segments, for example, a GUI segment, server-side segment, and a dependency segment.
  • the GUI segment may include client-side scripts that perform specific tasks on the client-side machine, such as on a browser or an application residing on the client machine.
  • the GUI segment may also include names of the files in which GUI Code should be placed in, based inputs received from the widgets.
  • the server-side segment includes generated server-side scripts that perform specific tasks on server machine.
  • the server-side segment also includes the names of files that the widget recommends the server-side code should be placed in.
  • the dependency segment includes information corresponding to dependency of code generated by a widget. For example, if a widget generates a code that requires a third- party library, or a different section to be loaded beforehand, at the time of execution, the program collator 620 assembles these dependencies based on data included in the dependency segment.
  • the project collator 615 may trigger the deployer 224 to reformat the source code placed in section files.
  • the deployer 224 may close all the files opened by the program collator 620, and may create an archive including directory-hierarchy and source code files. To generate the archive, the deployer 224 may open each file and may reformat the source code for the ease of readability. The deployer 224 may provide the path of the archive to the user to make the assembled source code of the application program available to the user for download.
  • the collator 157 may request the user to select retrieval mode.
  • the retrieval mode may indicate a mode in which the user would like to retrieve the application source code.
  • the retrieval mode indicates that the retrieval is to be done using traditional HTTP download.
  • the retrieval mode may indicate that the application source code may be uploaded to the user's server directly using File Transfer Protocols (FTP) or secure shell (SSH) protocols. Accordingly, the application source code may be deployed on the target device.
  • FTP File Transfer Protocols
  • SSH secure shell
  • the application program may be tested in a test environment may by a testing team and if any errors or irregularities in functionality with respect to what was finalized in the planning stage are found, the user may re-open the project file in the APD system 105 and make the required changes.
  • the inputs provided by the user for a selected widget may also be checked for errors and cautions by the selected widget.
  • Each widget may include corresponding errors and cautions, and may provide the identified errors and cautions to the error logging unit 420.
  • the error logging unit 420 may be interfaced with the server-concurrent checker 165-1 and may in turn provide the errors and cautions for further action.
  • payment gateway integration, design (4 man hours for designs, 1 1 database, and an additional (40 for payment gateway man hour for Payment module for managing integration) Gateway widgets and packs, transaction records (1 for transaction and 0.2 man hours for
  • Fig. 7 illustrates a method 700 for developing an application program
  • FIG. 8 illustrates a method 800 for generating an application program, according to an embodiment of the present subject matter.
  • the order in which the methods is described is not intended to be construed as a limitation, and any number of the described methods blocks can be combined in any order to implement the methods or any alternative methods. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof. [00133]
  • the methods may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types.
  • the methods may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
  • program storage devices or computer readable medium, for example, digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions, where said instructions perform some or all of the steps of the described methods.
  • the program storage devices may be, for example, digital memories, magnetic storage media, such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.
  • the method 700 may be performed by the
  • the application program may include multiple sections, where a section may include codes for various components, such as widgets, databases, and layouts. However, it will be understood that the certain sections may be left empty as well.
  • an action pertaining to development of an application program from a user device is received.
  • the development may include creation of a new application program or modification, which may include addition, deletion, and alteration, of any component, such as databases, structures, sections, and widgets, of the application program.
  • the action may include details for configuring a component, such as a database associated with the application program and one or more widgets.
  • a development unit of an action manager such as the action manager 150 corresponding to the received action is determined.
  • the development unit may be determined using an action ID associated with the development unit.
  • the received action is validated by at least one of a client-side and a server-side.
  • the received action may be validated using the validation rules.
  • the received action may be validated by the determine development unit.
  • inputs provided in the action may be analyzed for probable cautions and errors, based on error and caution rules. Further, the inputs may be stored and may be used for generating a source code during deployment process. The action may be analyzed for probable cautions and errors as and when the actions are validated and before the final collation and compilation process. In an example, the check for probable errors and cautions may be performed at the server-side of the concurrent checker 165 and may be provided to the client-side on a periodic basis.
  • a selected portion of the application program is collated, based on a collation request.
  • the selected portion may correspond to a specific portion of the application program or the entire source code.
  • the collation request may indicate whether a portion or the entire application program is to be collated.
  • collation may include assembling of source code of various sections of the application program. Further, the collation may also include compilation of the assembled source code.
  • the application program or to say, the application source code may be deployed on a target device for further actions, such as testing. Further, each deployed version of the application program may be stored for future use.
  • the method 800 may be performed by the
  • APD system 105 to assist a user in creating a new application program.
  • one or more databases to be associated with the application program may be created, based on inputs received for database attributes, such as the database name 305-1 , the structures 305-2, the platform 305-3, and the database flag(s) 305- 4.
  • database attributes such as the database name 305-1 , the structures 305-2, the platform 305-3, and the database flag(s) 305- 4.
  • one or more structures for each of the databases may be created, based on inputs provided for structure attributes, such as the structure name 310-1 , the field(s) 310-2, the structure flag(s) 310-3, and the structure element(s) 310-4.
  • structure attributes such as the structure name 310-1 , the field(s) 310-2, the structure flag(s) 310-3, and the structure element(s) 310-4.
  • one or more fields for each of the structures may be created, based on inputs provided for field attributes, such as the field name 320-1 , the field type 320- 2, the field size 320-3, the field default 320-4, the field order 320-5, and the field flags 320-6.
  • one or more sections of the application program may be created, based on inputs received for various section attributes, such as the section name 325-1 , the section description 325-2, the section layout 325-3, the parent section 325-4, the corresponding program 325-5, and the section flags 325-6.
  • At block 825 at least one of one or more widgets and one or more widget packs are added to the sections, based on user input.
  • the user input may indicate selection of widgets and widget packs from among a plurality of widgets and widget packs.
  • the received actions are checked for validation errors, and probable cautions and errors.
  • a validator of a corresponding development unit may check for validation errors, as mentioned at block 715. Further, the check pertaining to probable conflicts and errors may be performed by the concurrent checker 165, as indicated at block 720.
  • the sections may be collated to generate a source code of the application program. Further, it will be understood that any time during development process, the user may collate a selected portion of the application program as well.
  • the collated source code of the application program may be deployed on a target device specified by the user.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Educational Administration (AREA)
  • Development Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Stored Programmes (AREA)
PCT/IB2014/002787 2013-12-16 2014-12-16 Systems and methods for developing application programs WO2015092519A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN3944/MUM/2013 2013-12-16
IN3944MU2013 IN2013MU03944A (enrdf_load_stackoverflow) 2013-12-16 2014-12-16

Publications (1)

Publication Number Publication Date
WO2015092519A1 true WO2015092519A1 (en) 2015-06-25

Family

ID=53402188

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2014/002787 WO2015092519A1 (en) 2013-12-16 2014-12-16 Systems and methods for developing application programs

Country Status (2)

Country Link
IN (1) IN2013MU03944A (enrdf_load_stackoverflow)
WO (1) WO2015092519A1 (enrdf_load_stackoverflow)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019139911A1 (en) * 2018-01-09 2019-07-18 Justdo, Inc. Scripting language computer program modification methodology, system and software
CN110989983A (zh) * 2019-11-28 2020-04-10 深圳航天智慧城市系统技术研究院有限公司 一种零编码的应用软件快速构建系统
WO2021101546A1 (en) * 2019-11-21 2021-05-27 Schlumberger Technology Corporation Widget delivery workflow system and method
WO2024249205A1 (en) * 2023-05-26 2024-12-05 Dtcc Digital (Us) Inc. System and method for building server-driven user interface (sdui) mobile applications using no-code/low-code application builder

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113419710B (zh) * 2021-06-25 2024-03-15 北京悟空出行科技有限公司 小程序的开发方法、装置、电子设备和介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5495567A (en) * 1992-11-06 1996-02-27 Ricoh Company Ltd. Automatic interface layout generator for database systems
US20080109785A1 (en) * 2004-01-16 2008-05-08 Bailey Bendrix L Graphical Program Having Graphical and/or Textual Specification of Event Handler Procedures for Program Objects
US20090055757A1 (en) * 2007-08-20 2009-02-26 International Business Machines Corporation Solution for automatically generating software user interface code for multiple run-time environments from a single description document
US20110088011A1 (en) * 2009-10-14 2011-04-14 Vermeg Sarl Automated Enterprise Software Development

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5495567A (en) * 1992-11-06 1996-02-27 Ricoh Company Ltd. Automatic interface layout generator for database systems
US20080109785A1 (en) * 2004-01-16 2008-05-08 Bailey Bendrix L Graphical Program Having Graphical and/or Textual Specification of Event Handler Procedures for Program Objects
US20090055757A1 (en) * 2007-08-20 2009-02-26 International Business Machines Corporation Solution for automatically generating software user interface code for multiple run-time environments from a single description document
US20110088011A1 (en) * 2009-10-14 2011-04-14 Vermeg Sarl Automated Enterprise Software Development

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019139911A1 (en) * 2018-01-09 2019-07-18 Justdo, Inc. Scripting language computer program modification methodology, system and software
US11003441B2 (en) 2018-01-09 2021-05-11 Justdo, Inc. Scripting language computer program modification methodology, system and software
US11461092B2 (en) 2018-01-09 2022-10-04 Justdo, Inc. Scripting language computer program modification methodology, system and software
US11704116B2 (en) 2018-01-09 2023-07-18 Justdo, Inc. Scripting language computer program modification methodology, system and software
WO2021101546A1 (en) * 2019-11-21 2021-05-27 Schlumberger Technology Corporation Widget delivery workflow system and method
US12073211B2 (en) 2019-11-21 2024-08-27 Schlumberger Technology Corporation Widget delivery workflow system and method
CN110989983A (zh) * 2019-11-28 2020-04-10 深圳航天智慧城市系统技术研究院有限公司 一种零编码的应用软件快速构建系统
WO2024249205A1 (en) * 2023-05-26 2024-12-05 Dtcc Digital (Us) Inc. System and method for building server-driven user interface (sdui) mobile applications using no-code/low-code application builder

Also Published As

Publication number Publication date
IN2013MU03944A (enrdf_load_stackoverflow) 2015-09-25

Similar Documents

Publication Publication Date Title
US10127250B2 (en) Data transformation system, graphical mapping tool and method for creating a schema map
US10324609B2 (en) System for providing dynamic linked panels in user interface
US9201558B1 (en) Data transformation system, graphical mapping tool, and method for creating a schema map
AU2014201573A1 (en) Improved data integration tool
WO2015092519A1 (en) Systems and methods for developing application programs
Prettyman Learn PHP 7
Gaspar et al. Mastering Flask Web Development: Build Enterprise-grade, Scalable Python Web Applications
Barton Talend open studio cookbook
WO2022221610A1 (en) Automated authoring of software solutions from a data model
Morris Resilient Oracle PL/SQL
Sheldon et al. Professional Visual Basic 2012 and. NET 4.5 Programming
Kumar ADempiere 3.6 Cookbook
Anbazhagan Mastering Entity Framework Core 2.0: Dive into entities, relationships, querying, performance optimization, and more, to learn efficient data-driven development
Drogin Microsoft Dynamics NAV Development Quick Start Guide: Get Up and Running with Microsoft Dynamics NAV
Dickinson Grails 1.1 web application development
Duldulao et al. Spring Boot and Angular: Hands-on full stack web development with Java, Spring, and Angular
Naik Learning Linux Shell Scripting: Leverage the power of shell scripts to solve real-world problems
Shomnikov SAP Data Services 4. x Cookbook
Hecksel et al. Getting Started with Oracle Data Integrator 11g: A Hands-On Tutorial
Krishnan Oracle ADF 11gR2 development beginner's guide
Price C# 7 and. NET Core: Modern Cross-Platform Development
Walker Software Development on the SAP HANA Platform
Gorman Pentaho Reporting 3.5 for Java Developers
Constable SAS programming for Enterprise Guide users
Kimmel Professional DevExpress ASP. NET Controls

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14871127

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14871127

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 02.02.2017)

122 Ep: pct application non-entry in european phase

Ref document number: 14871127

Country of ref document: EP

Kind code of ref document: A1