Patent Application
20140372973
Aspects of the present disclosure relate to computer programming paradigms, and more particularly, to methods and systems for generating data-driven objects for use in software development.
Virtually all software today is designed based on an object-oriented programming paradigm that conceptualizes the logic of a software application into self-sustaining concepts known as “objects”. An object is an entity or item that combines data and associated operations commonly referred to as methods that may be used to manipulate the data. Object-oriented programming languages, such as C++, Java, and Python, generate executable software applications by combining objects together into a structured network to form a complete software program. As a result, any software generated from an object-oriented paradigm is implemented in a manner that inextricably links the object operational code and the data on which it acts. Accordingly, in order to make any modifications to the software, developers must redesign or otherwise modify significant portions of both the code and the data representation, and subsequently recompile the modified code to generate new executable applications, all of which may be time consuming, labor intensive, and expensive.
In contrast, a data-driven programming is another type of programming paradigm in which data is processed by code using standardized techniques. When employing a data-driven programming paradigm, operational code is distinguished from the data structures on which it acts. Further, both the operational code and the data structures are implemented so that developers can make changes to the logic of the program by only editing the data structure.
It may be desirable to have a mechanism with appropriate architectural support that enables the generation of object-oriented type objects in accordance with a data-driven programming paradigm for use in the development of software applications. It is with these concepts in mind, among others, that various aspects of the present disclosure were conceived.
One aspect of the present disclosure involves systems for defining generic data objects. The system includes at least one processor configured to define one or more generic objects in a standard data format and generate an application implemented based on the one or more generic objects. The at least one processor is further configured to update the one or more generic objects by modifying a data representation corresponding to at least one of the one or more generic objects, thereby changing the functionality of the application without generating a new version of the application.
Aspects of the present disclosure include methods for defining generic data objects. The method is executable by at least one processor. The method includes defining one or more generic objects in a standard data format. The method also includes generating an application implemented based on the one or more generic objects. The method includes updating the one or more generic objects in the standard data format by modifying a data representation corresponding to at least one of the one or more generic objects, thereby changing the functionality of the application without generating a new version of the application.
Aspects of the present disclosure include non-transitory computer-readable mediums encoded with instructions for defining generic data objects. The instructions executable by a processor defining one or more generic objects in a standard data format. The methods include generating an application implemented based on the one or more generic objects. The methods include updating the one or more generic objects in the standard data format by manipulating an aspect of an object representation corresponding to at least one of the one or more generic objects, thereby changing the functionality of the application without generating a new version of the application.
Aspects of the present disclosure may be better understood and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings. It should be understood that these drawings depict only typical embodiments of the present disclosure and, therefore, are not to be considered limiting in scope.
Aspects of the present disclosure include systems and methods for generating generic data patterns or structures that may be used to generate data-driven objects for subsequent use in software development. In various aspects, objects, as understood in the context of an object-oriented programming paradigm, may be defined or redefined as one or more data-driven objects, such as a domain object and a corresponding attribute object, both of which may be used to design the anticipated behavior of a software application. Subsequently, any modifications, updates, or changes made to the data-driven objects used to define the behavior of the application will automatically be represented within the execution of the application, without having to make any modifications to the logical aspects of the application, such as to the application's functions or routines, and further, without having to generate new executable code corresponding to the application, such as for example, by engaging in compilation procedures.
The Object-oriented programming paradigm defines a set of interacting objects for the purpose of solving a software problem. Each individual object contains encapsulated data fields that can store data (attributes that describe the object) and corresponding methods or procedures for interacting with the data. For example, such object methods may include checks and safeguards that are specific to the types of data the object contains. An object can also offer simple-to-use, standardized methods for performing particular operations on its data, while concealing the specifics of how those tasks are accomplished. Thus, objects can be thought of as wrapping data within a set of functions designed to ensure that the data is used appropriately and to assist in that use. Objects are generally implemented to interact with other objects, and are combined to design complete computer programs. Accordingly, an object-oriented software program may be viewed as a collection of interacting objects.
Object-oriented programs generally contain different types of objects, each type corresponding to a particular individual, identifiable item, unit, or entity, either real or abstract. For example, an object may correspond to an abstract concept, such as a specific kind of complex data to be managed, or alternatively, to a real-world object such as a bank account or a bicycle. Moreover, such an object-oriented program might contain multiple copies of each type of object, one for each of the real-world objects the program is dealing with. For example, one could imagine a software application including one bank account object for each real-world account at a particular bank. Each copy of the bank account object would be identical in the methods it offers for manipulating or reading its corresponding data, but the data inside each object would differ reflecting the different history of each account.
Although object-oriented programming has become ubiquitous, the use of such a software paradigm may present many challenges. In particular, when an application developer decides to update a particular object of a given software application, such as, for example, making a modification to the object's data representation (i.e., adding and/or removing data fields), any other objects within the software application that are currently interacting with the particular object may fail, if the modified version of the particular object is incompatible with the other objects. Such a problem can occur when, for example, the developer of the other objects is unable to anticipate the data representation changes that the developer of the particular object is currently implementing, or may implement in the future. Thus, any changes to object-oriented programs may require continuous redevelopment of multiple objects within a given software program, and frequent regeneration of executable versions of the software application (i.e. recompilation due to the modifications made to objects and logical code), as the representation of data is often inextricably linked to the logical aspects of the program. Stated differently, a change to the data representation (i.e., the data fields) of an object within a software application may require developers to redesign and recompile the logical portions of the software application.
Aspects of the present disclosure enable developers the ability to successfully modify the representation of data within an object without having to change the logical implementation of the software application to which the data pertains. By employing data-driven programming techniques, and in particular, by generating data-driven objects that effectively decouple the data of a object from its logical components (e.g. methods), developers can continuously modify, update, or otherwise extend an application by only changing the data representation of objects, all of which may be automatically recognizable by the logical aspects of the application.
An illustrative method and/or process for generating data-driven objects is depicted in
As illustrated in
The attribute object may correspond to one of the attributes listed within the generated domain object, and may include a data representation in the form of one or more data fields, such as a name data field, a value data field, a type data field, among others. For example, referring to the dog example, the attribute “breed” may correspond to an attribute object including a name data field containing a specific name for the breed of dog, a value data field, a type data field, etc.
As illustrated in
Any generated generic data-driven data objects may be implemented in a standard data format, such as according to an extensible markup language (“XML”), which is a particular type of markup language defining a set of rules for encoding documents in a machine-readable format. Typically, XML documents form a tree structure that starts at a “root/parent” element and branches to one or more “child” elements. Accordingly, the domain object and attribute object may be defined according to such XML standards, as are understood by one of ordinary skill in the art. Although the domain objects and attribute objects have been described as being implemented in accordance with XML standards, such an implementation is not intended to be limiting in any way. Rather, it is contemplated that other types of data formats may be implemented, some of which include JavaScript object notation (“JSON”), ordered graph data language (“OGDL”), comma-separated values (“CSV”), and yet another markup language (“YAML”), among others.
As illustrated in
Referring again to
A user may access a client device 222 to interact with the generated interfaces and provide input and/or receive output, such as the source code described above. The client device 222 may be a personal computer, work station, server, mobile device, mobile phone, tablet device, processor, and/or other processing device capable of implementing and/or executing server processes, software, applications, etc. Additionally, the client device 222 may include one or more processors that process software or other machine-readable instructions and may include a memory to store the software or other machine-readable instructions and data. The client device 222 may also include a communication system to communicate with the various components of the processing device 212 via a wireline and/or wireless communications, such as through a network 218, such as the Internet, an intranet, an Ethernet network, a wireline network, a wireless network, a mobile communications network, and/or another communication network.
Any software generated from the source code, which may be any type of software application, applet, program, source code, and the like, may process, analyze, and/or otherwise access the generated data-driven objects. The source code may include, for example, functions, routines, or processes that access, interpret, and manipulate any generated generic data-driven objects. In one particular embodiment, the generated application may be a graphical user-interface including various interactive elements, such as buttons, forms, fields, selections, inputs, streams, etc., that are data-driven by the generic data objects generated by the processing device 212.
Often, changes, updates, modifications, etc. may be made to data-driven objects that have been previously defined. For example, a developer may make one or more changes to various aspects of a data object for a variety reasons. For example, referring to the telecommunication service provider example above, the provider may want to modify a product, such as the private line product currently being offered to customers. In particular, the provider may want to modify the definition of the product as originally defined within the data-driven object. Thus, referring again to
In response to the received modification, the various interfaces generated to enable customers to order products may be automatically modified to display the data contained within the data-driven objects (operation 108). Stated differently, the generated user-interfaces may be dynamically data-driven by any modifications received by the processing device 212. The dynamic behavior occurs within the data contained within the data-driven objects. Thus, when a modification to a data-driven object is received, any software, such as a generated user-interface presenting or otherwise consuming the data object, will automatically be updated and/or comply with the modification.
Main memory 504 can be Random Access Memory (RAM) or any other dynamic storage device(s) commonly known in the art. Read-only memory 506 can be any static storage device(s) such as Programmable Read-Only Memory (PROM) chips for storing static information such as instructions for processor 502. Mass storage device 507 can be used to store information and instructions. For example, hard disks such as the Adaptec® family of Small Computer Serial Interface (SCSI) drives, an optical disc, an array of disks such as Redundant Array of Independent Disks (RAID), such as the Adaptec® family of RAID drives, or any other mass storage devices, may be used.
Bus 501 communicatively couples processor(s) 502 with the other memory, storage and communications blocks. Bus 501 can be a PCI/PCI-X, SCSI, or Universal Serial Bus (USB) based system bus (or other) depending on the storage devices used. Removable storage media 505 can be any kind of external hard drives, floppy drives, IOMEGA® Zip Drives, Compact Disc-Read Only Memory (CD-ROM), Compact Disc-Re-Writable (CD-RW), Digital Video Disk-Read Only Memory (DVD-ROM), etc.
Embodiments herein may be provided as a computer program product, which may include a machine-readable medium having stored thereon instructions which may be used to program a computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, floppy diskettes, optical discs, CD-ROMs, magneto-optical disks, ROMs, RAMs, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions. Moreover, embodiments herein may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., modem or network connection).
As shown, main memory 504 is encoded with object application 550-1 that supports functionality as discussed above and as discussed further below. For example, in one embodiment, the object application 550-1 may include or otherwise implement the various processes and/or instructions described herein. Object application 550-1 (and/or other resources as described herein) can be embodied as software code such as data and/or logic instructions (e.g., code stored in the memory or on another computer-readable medium such as a disk) that supports processing functionality according to different embodiments described herein. During operation of one embodiment, processor(s) 502 accesses main memory 504 via the use of bus 501 in order to launch, run, execute, interpret, or otherwise perform the logic instructions of the object application 550-1. Execution of object application 550-1 produces processing functionality in object process 550-2. In other words, the object process 550-2 represents one or more portions of the object application 550-1 performing within or upon the processor(s) 502 in the computer system 500.
The description above includes example systems, methods, techniques, instruction sequences, and/or computer program products that embody techniques of the present disclosure. However, it is understood that the described disclosure may be practiced without these specific details. In the present disclosure, the methods disclosed may be implemented as sets of instructions or software readable by a device. Further, it is understood that the specific order or hierarchy of steps in the methods disclosed are instances of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the method can be rearranged while remaining within the disclosed subject matter. The accompanying method claims present elements of the various steps in a sample order, and are not necessarily meant to be limited to the specific order or hierarchy presented.
While the present disclosure has been described with reference to various embodiments, it will be understood that these embodiments are illustrative and that the scope of the disclosure is not limited to them. Many variations, modifications, additions, and improvements are possible. More generally, embodiments in accordance with the present disclosure have been described in the context of particular implementations. Functionality may be separated or combined in blocks differently in various embodiments of the disclosure or described with different terminology. These and other variations, modifications, additions, and improvements may fall within the scope of the disclosure as defined in the claims that follow.
