System for configuration programming

This application claims priority to U.S. Provisional Application Ser. No. 60/274,333 filed Mar. 8, 2001.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to application software and systems for creating software applications. More particularly, it relates to a data model oriented system, which allows rapid creation of software applications based upon modules for handling a finite set of data patterns.

2. Discussion of the Related Art

Generally, systems for creating software applications require extensive time from highly experienced programmers. Each part or feature of a software application has to be designed, coded, compiled, and debugged. Then, the parts have to be tested to ensure that they operate together. Since most applications included may different parts, the procedure is very complex. Many applications also need to operate with existing third party resources and tools. In creating a software application, interfaces must be created for each third party resource or tool. Furthermore, a software application is dependent upon a specific platform or operating environment. In order to transfer the application to another platform requires complete reprogramming.

<figref idref="DRAWINGS">FIG. 1</figref> illustrates a traditional approach to application programming which incorporates specific programming with third party resources and tools <b>130</b>. Tools and resources <b>130</b> may include other programs, communication capabilities and/or specific hardware to be utilized with the application. Typically, application programming is functionality driven. The programmer seeks to create certain functions to be performed by the application. The functions depend upon the hardware and software resources which are to be utilized by the application. In this regard, the application is platform dependent because it is developed for a specific programming environment. The functions then need to be coordinated with the data of the application. The coordination is typically done by creating and initializing specific data structures within the programming of the application.

<figref idref="DRAWINGS">FIG. 1</figref> illustrates a data centric understanding of traditional application programming. In this known system <b>100</b>, the data to be created, modified or utilized by the application is represented as various application data models <b>110</b>. The functionality of the application requires a set of interfaces <b>120</b> between the application data models <b>110</b> and resources and tools <b>130</b> that provide the functionality. For example, database interface programming is required to interface with each database; Graphic User Interface (GUI) programming is required to interface with each GUI; transport interface programming is required to interface with each transport tool; and so forth. The resources and tools <b>130</b> utilized in the application come in various forms and choices and require the interface programming <b>120</b> to be specific to those forms or choices. For example, in choosing a transport, the application model may use one or more popular transport tools such as Java Messaging Service (JMS), e-mail, fax, and File Transfer Protocol (FTP). Each transport tool has a specific Application Program Interface (API). Furthermore, the interface programming <b>120</b> needs to be specific to the application data models <b>110</b>. Thus, if changes are made to the application data models <b>110</b>, then corresponding changes are required for all of the interface programming <b>120</b> for that application. Since the data definitions are part of the application code, any changes have to be made with lines of code, which must be compiled and debugged before it can be used. Also, additional programming is required to convert data in an old format to a new format required by the changed application program.

A programmer usually needs to understand the operating and programming environment of the resources and tools to interface with them. This typically requires a highly specialized and skilled programmer(s) to perform the various tasks of programming. Highly skilled programmers are difficult to train and retain. In addition, the various but disparate programs need to operate homogeneously for the application model to operate smoothly with the various resources and tools. However, such integration is difficult to achieve and exemplifies the development complexity of interfacing one or more application models to the various resources and tools.

Therefore, a need exists for a data independent, application programming system which does not require reprogramming based upon data changes. A need exists for a system which simplifies the programming process to allow reuse of previously created code. A need further exists for a system which is platform independent. A need exists for a system which allows common interfaces with third party resources.

SUMMARY OF THE INVENTION

The deficiencies of the prior art are substantially overcome by the present invention which provides a data model based system for programming. The system of the present invention is based upon a fixed set of data patterns or objects: primitive, class and object array. The data patterns can also be recursively defined. A set of service modules is created for performing various functions with respect to different data patterns. The service modules are organized to provide program flow from one module to another. In order to create an application within the system of the present invention, a data model is created which represents all of the data of the application as corresponding data patterns. The service modules are then selected and organized to provide desired functionality in conjunction with the data model. In this manner, applications can be created quickly from preexisting modules.

Furthermore, in the system of the present invention, the modules provide the interaction between data and resources. In this manner, the application is resource independent. A change in a resource, such as a hardware platform, merely requires selection of an appropriate module for interfacing with that resource. The system of the present invention further uses a hierarchical approach for organizing modules to allow enhanced use for rapid software creation. Thus, many functions can be performed without limitations from the specific resources of the system.

BRIEF DESCRIPTION OF THE DRAWINGS

For better understanding of the invention, reference is made to the drawings which are incorporated herein by reference and in which:

<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram illustrating a conventional approach to interfacing application models having data models to various third party resources and tools;

<figref idref="DRAWINGS">FIG. 2</figref> is a schematic diagram of a development platform for application creation in accordance with an embodiment of the invention;

<figref idref="DRAWINGS">FIG. 3</figref> is a schematic diagram of a module for creating a data model in accordance with an embodiment of the invention;

<figref idref="DRAWINGS">FIG. 4</figref> is a schematic diagram of an object API module in accordance with an embodiment of the invention; and

<figref idref="DRAWINGS">FIG. 5</figref> illustrates an example of an event driven flow in accordance with an embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention is a data-oriented system for rapid creation of application programs. The system is based upon the principle that all data can be modeled by a finite set of data patterns. Stored service object modules provide desired functionality based upon the known data patterns. The service objects maintain the interfaces to desired resources and provide a unified interface. In order to create an application in accordance with the present invention, the creator only needs to create a data model of the application data based upon the finite set of data patterns, select appropriate service object modules for providing desired functionality, and determine the flow or order of operation of the service objects. If specific functionality is required beyond that provided by exiting service object, new service objects can be created. The new service objects become part of the system and can be utilized for future programming.

In general, the components that comprise an application program according to the present invention are: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0020">a data model;</li><li id="ul0002-0002" num="0021">service objects defining functions to be performed on the object models of the data model; and</li><li id="ul0002-0003" num="0022">flow logic linking the service objects and object models to perform utility functions (or business functions).</li></ul></li></ul>

The data model describes data structures representing the application data based upon basic data patterns. The service objects, which are software components, provide the functional or business processes of the application. These software components are linked into a flow to invoke services and/or to operate on the data and interface with resources. The manner in which the software components are linked is the flow logic of the application model. Results of the functional or business processes performed on the data model can be presented in a form compatible to a physical device (such as a computer monitor or a printer) or in a form compatible to an application software in memory. The components and operation of an application program according to the present invention can be better understood in relation to the process for creating the application program.

In a development platform of the present invention, a classifier defines a data model as a specific set of object models corresponding to application data based upon a finite number of basic data patterns. The object models define all application data within the limitations of the basic data patterns. Furthermore, the object models can be defined recursively to create complex data structures using the basic data patterns. In addition, the development platform has a set of selectable service objects that perform various functions/services on object models. At run time, the service objects recognize the basic data patterns within an object model and selectively operate in accordance with the defined the basic data patterns. Since the operation of the service objects is independent of the application data, changes in application data does not require changes to the service objects. The service objects usually represent functions/services that provide for the interfacing with the various third party resources and tools. The bridge between the development platform and the Application Programming Interfaces (APIs) of the third party resources and tools can be performed by storing and implementing service objects that are compatible with the third party APIs and are also compatible with the defined object model of the data model.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates a development platform <b>200</b> according to an embodiment of the present invention. The development platform <b>200</b> can be used to create application software in accordance with an embodiment of the present invention. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, the development platform <b>200</b> has two principal components, an object development module <b>210</b> and an object application programs interface (API) module <b>220</b>. The development platform <b>200</b> may be implemented as software/firmware embedded in a processor executable medium such as Read Only Memory (ROM), Random Access Memory (RAM), Flash memory, magnetic and optical disk and disk drives and the like. The development platform <b>200</b> may also be implemented in hardware such as application specific integrated circuit (ASIC) and the like. The processor executable medium also includes carrier signals containing processor executable instructions therein.

The object development module <b>210</b> translates the data of an application model <b>110</b> in a manner that is generic to the development platform <b>200</b>. In particular, the data model of the application model is defined as a set of object models based upon basic data patterns. The classification method will be described with reference to FIG. <b>3</b>. This allows various functions of the object API module <b>220</b> to be applied to the object models based on the basic patterns.

With reference to <figref idref="DRAWINGS">FIG. 3</figref> in conjunction with <figref idref="DRAWINGS">FIG. 2</figref>, the object development module <b>210</b> creates a data dictionary <b>230</b> which defines the object models. <figref idref="DRAWINGS">FIG. 3</figref> illustrates a process for creation of the data dictionary <b>230</b>. The process includes a classifier <b>232</b>, a data dictionary database <b>234</b> and a data dictionary manager <b>236</b>. The data dictionary <b>230</b> is developed to represent the data for specified application data. Turning to the classifier <b>232</b>, generally a data model <b>310</b> can be defined from a potentially infinite number of possible data formats. However, in accordance with the invention, these possible data formats can be classified as object models <b>330</b>. The object models are based upon a finite number of basic data patterns recognized in the development platform <b>200</b>. The classifier <b>232</b> performs this task by classifying a data model <b>310</b> into a set of object models <b>330</b> having the following basic data patterns:

primitive;

class; and

object array.

A primitive represents a basic element. It can be data such as Boolean, Short, Integer, Long, Float, Double, Date, Time, Date &amp; Time, Currency, Business Calendar, Alphanumeric Characters, Big Integer and so forth. A class represents structured data. It is composed of multiple attributes, each of which is also one of the basic data patterns. An object array is an array with a set of objects, all having the same basic data pattern, as its child elements. It should be noted that a characteristic of the class and object array types is their recursive nature. An attribute of a class or element of an object array can be another class or object array. This recursiveness of certain object types provide for creation of a complex data model from a finite set of basic data patterns.

Using the classification method described above, a finite number of possible data patterns used to define a data model <b>310</b> that can have a potentially infinite number of possible variations. Thus, only a finite number of data patterns in the object models <b>330</b> need to be interpreted. The classifier <b>232</b> can operate in various ways. It can be a program which receives information regarding the data model <b>310</b> corresponding to the application model <b>110</b> and automatically map the data model <b>310</b> to an appropriate set of object models <b>330</b>. Alternatively, a programmer could simply use a text editor program to enter information defining the object models <b>330</b> in a format recognized by the system. Preferably, the development platform <b>200</b> includes an interactive program to aid a user in creating appropriate object models <b>330</b> for a data model <b>310</b>.

Once properly classified, the object models <b>330</b> are stored in the data dictionary database <b>234</b>. Again, the data dictionary database may take many forms. An example of the data dictionary database <b>234</b> with definitions for different object models <b>330</b> is provided in the appendix hereto. The object models <b>330</b> in the data dictionary database <b>234</b> must be uniquely identified so that they can be properly accessed. The unique identification can be done with a unique name or a unique identification number (ID) in the data dictionary database <b>234</b>.

With the object models <b>330</b> stored in the data dictionary database <b>234</b>, the object API module <b>220</b> can now be utilized to select and organize the various functions to be performed on the data of the object models <b>330</b>.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates service objects within the object API module <b>220</b>. The service objects comprise device manager sub-modules <b>410</b>₁-<b>410</b>_Nthat are functional/business blocks to perform a function or a process on data of the object models <b>330</b>. Generally, the service objects of the object API module <b>220</b> are a collection of device managers <b>410</b>₁-<b>410</b>_Nthat have adopted many system functions and third party APIs to build a layer of service objects <b>420</b>₁-<b>420</b>_Mthat performs functions/services on the object models <b>330</b>. Specifically, a finite number of services is identified for each resource or tool (e.g., graphic user interface (GUI), database, transport, transaction and etc.) and a service object <b>420</b>₁-<b>420</b>_Mis created for each service that a device manager <b>410</b>₁-<b>410</b>_Nis to provide. Each service object <b>420</b>₁-<b>420</b>_Mis designed to perform a particular service one of the object models <b>330</b>.

One feature of the service object <b>420</b>₁-<b>420</b>_Mis that it performs a function/service on one or more object models <b>330</b> based on the pattern information of the object models <b>330</b> from the data dictionary database <b>234</b>. During operation, prior to the performance of a service object, the object API module <b>220</b> calls the data dictionary manager <b>236</b>, which manages all the object models <b>330</b> that are stored in the data dictionary database <b>234</b>. The object API module <b>220</b> accesses the object models <b>330</b> in the data dictionary database <b>234</b> which are relevant to the operation of the service object to determine the data patterns of those object model <b>330</b>. Once the determination is made, the object API module <b>220</b> passes the data patterns to the pertinent service object that is to perform the functional/service process. Because there are only a finite number of data patterns with which an object model <b>330</b> can be represented, a service object <b>420</b>₁-<b>420</b>_Mhaving a finite set of functions/services can be designed to address each possible data pattern of the object models <b>330</b>. Therefore, once the data pattern of an object model <b>330</b> has been identified, a dispatching takes place within the service object <b>420</b>₁-<b>420</b>_Mto perform an appropriate function/service process for the data pattern of a particular object model <b>330</b>. Since object models <b>330</b> can be defined recursively, the appropriate function/service process could also be recursive.

It should be noted that because the object model <b>330</b> is processed based on the identified pattern, a change in the object model <b>330</b> will be recognized by the object API module <b>220</b> at runtime when it interrogates the data dictionary database <b>234</b> via the data dictionary manager <b>236</b> and this information is passed to the service object <b>420</b>₁-<b>420</b>_Mprior to the service object's <b>420</b>₁-<b>420</b>_Mperformance. The service object <b>420</b>₁-<b>420</b>_Mbeing informed of the changed pattern processes the object model <b>330</b> in accordance with the changed pattern. This feature is advantageous in that it allows the data model <b>310</b> (and thus, the separate object models <b>330</b>) to be dynamically altered, which will be detected and the object models <b>330</b> are processed accordingly. Specifically, the service object <b>420</b>₁-<b>420</b>_Mperforming processes on an object model <b>330</b> will recognize the current data patterns and dynamically alter its process to adapt to the modified object model <b>330</b>. The features described above allows for the runtime reconfiguration of the data model <b>310</b> of the application model <b>110</b>, which is advantageous over a previously known method that requires the program codes to be reprogrammed, linked, compiled and debugged whenever the data model <b>310</b> is modified.

Another aspect of the invention is the event driven approach between the application model <b>110</b> and the service objects <b>420</b>₁-<b>420</b>_M, or program flow. Specifically, the data model <b>310</b> (in object model <b>330</b> form) and associated service objects <b>420</b>₁-<b>420</b>_Mare configured based on flow to link services, where various utility functions (business functions) that are performed on the object model <b>330</b> are event driven by data change and/or event and not code driven as in previously known programming approaches. According to one aspect of the invention, the object models <b>330</b> and service objects <b>420</b>₁-<b>420</b>_Mare linked such that one or more data changes in an object model <b>330</b> causes specified service objects <b>420</b>₁-<b>420</b>_Mto be notified of the data changes. With reference to <figref idref="DRAWINGS">FIG. 5</figref>, the object model <b>530</b> may include a data change registry <b>532</b> that provides for any service object (such as service object A) to register for notification on various data changes. When a data change occurs at the object model <b>530</b>, the registered service object (service object A) is notified and the service object determines if the data change is a change that requires processing. If the service object so determines then the service object performs a process based on the data change. According to the aspect of the invention, the object model notifies the relevant service objects of the data change but does not actively cause the service objects to perform a process due to the data change. Instead, the service object makes that determination upon receiving notification. Additionally, a process performed by the service object may also cause a data change that affects other service objects (such as service object B). In this instance, the service object may be configured to trigger a notification to other service objects upon execution or completion.

Continuing with <figref idref="DRAWINGS">FIG. 5</figref>, a flow process of an event driven approach is illustrated in accordance with the invention. At stage <b>1</b>, a data change has occurred in the object model <b>530</b>. The object model <b>530</b> accesses the data change registry <b>532</b> to determine which service objects should be notified of the data change (the service objects have previously registered for notification of the various data changes). Once the determination is made, the object model <b>530</b> notifies the pertinent service objects of the data change. At stage <b>2</b>, service object A receives notification that a data change has occurred. The service object A determines whether the data change requires performance of a process and if so, service object A performs the process. At stage <b>3</b>, the service object A outputs the result of the process which may have caused further data change in the object model and may affect other service objects. In one embodiment, the object model A reviews its data change registry to determine if the data change requires notification to other service objects. In this instance, the service object A determines that service object B requires notification and notifies service object B of the data change. At stage <b>4</b>, the service object B receives a notification from service object A and determines whether the data change is of the type that requires processing. If so, the function B block performs the required process and outputs the result of the process. This flow process may be repeated for other service objects until the flow process triggered by the data change has been satisfied.

Turning back to <figref idref="DRAWINGS">FIG. 2</figref>, the object API Module <b>220</b> interface bridges with the specific APIs of the resources and tools of the third party. In accordance with one embodiment, the classification method (e.g., primitive, class, object array) that sets the finite set of object models of data models is iterated against the third party APIs to determine which object models are recognized by the third party APIs. For instance, the classification method is iterated against a transport tool JMS, wherein a list of object models that are recognized by the JMS is compiled and device drivers based on the object models are built and stored within the object API module. Thus, when an object model of a data model is to be interfaced with JMS, the object API module determines which device driver can be used to allow the object model to be interfaced. Alternatively, the object models that allow for the interface with JMS, for example, may be stored in the object API module and when an object model of a data model is to be interfaced with JMS, the classifier begins an iteration process on the object model that transforms the object model pattern into one recognized by the JMS. The transformed model is then interfaced with JMS.

According to one aspect of the invention, for each service object, a fixed pattern of input and output parameters can be defined so that all the service objects have uniform APIs, thereby significantly simplifying the programming logic.

According to various aspects of the invention, a programming tool may take a data model of the application model and perform an iterative process using classification of primitive, class and object array to define a pattern that describes the data model, which is stored in the data dictionary as an object model. A complete change in the data model may require the re-use of the programming tool to define an object model; however certain alterations and modifications may be performed by a data dictionary Editor that implements the changes during the runtime. Because there are finite services available in the object API module, the service objects may be displayed in templates of a GUI that are dragged and dropped into programs during creation of the application module. In one embodiment, the language that is used to construct an application model may be Extensible Markup Language (XML) but other languages may be used to construct the application model.

The present invention is not limited to a development platform which operates as described above. Rather, any development process can be used within the meaning of the present invention which creates a set of object models for representing data and a set of service objects for performing functions with respect to the object models.

Embodiments of the invention provides various benefits such as reduced programming time, reduced programming code size and programming may be performed by less specialized programmers. Having thus far described at least one illustrative embodiment of the invention, various alterations, modifications and improvements will readily occur to those skilled in the art. Such alterations, modifications and improvements are intended to be within the scope and spirit of the invention. Accordingly, the foregoing description is by way of example only and is not intended as limiting. Accordingly, the invention is defined by the following claims and equivalents thereof.