Method and mechanism for a task oriented XML data model

[0002] This application is related to commonly assigned co-pending application Ser. No. 09/413,609, to Christina P. Lau, entitled “Method and Mechanism for a Task Oriented Data Model”, filed the same day as the present application.

[0003] The present invention relates to object oriented programming systems, and more particularly to a task oriented structure for a data model.

[0004] Traditionally in the computer programming arts, program code and data have been kept separate. For example, in the well-known C programming language, units of program code are called functions, and units of data are called structures. In C the functions and structures are not formally connected, that is, a function can operate on more than one type of data structure, and more than one function can operate on the same structure.

[0005] Object-oriented programming, in contrast, deals with objects, in which program code and data are merged into a single indivisible entity or “object”. An object is an instance of an implementation and an interface, which models a real-world entity. The object is implemented as a computational entity that encapsulates state and operations and responds to requests. The data and methods are implemented internally in the object. A business object for example is an object containing business methods (i.e. logic) and state that is intended for use within business applications.

[0006] Objects are built using an application program commonly referred to as an object builder tool. The object builder is a program which is used to define the business objects and generate the necessary definition and implementation files in IDL (Interface Definition Language), C++ and/or Java, as will be understood by those skilled in the programming arts.

[0007] Object builders utilize a data model which provides a template of the data structure for the objects. Object-oriented data models can be adapted to a wide range of different models by changing the definitions of meta-data, such as the objects and the task trees. Meta-data as will be understood by those skilled in the art comprises the self-descriptive information that can describe both services and information. With meta-data new services can be added to a system and discovered at run-time.

[0008] The object builder in the Component Broker™ toolkit from IBM utilizes a proprietary data model known as the Common Data Model (CDM), which is implemented as a binary file. In the object builder tool for Component Broker™, objects are processed by performing sets of user-defined operations in the form of task trees.

[0009] The binary file format of the Common Data Model yields some advantages such as rapid saving and loading of the data model. However, these advantages are offset by a number of disadvantages. First, the binary format of the Common Data Model or CDM is not human readable and as such the data model can only be examined by using the user interface in the object builder or by viewing the code generated from the binary file. Second, the data model must be imported or exported in its entirety, i.e. component parts of the data model cannot be imported or exported. This makes it much more time-consuming to perform impact analysis and to compare different model-generated outcomes. I-or example, to compare the modeling results obtained by modifying one object, it is usually necessary to import or export the entire data model, even though the data model is substantially unchanged in any respect other than the slightly altered object.

[0010] This problem has been addressed in other data models by using a proprietary language, for example, the known Rational Rose tool utilizes a Rose mdl format file to represent the meta-data for the data model. Because the mdl format has been well publicized, objects using the mdl format can be designed and analyzed by any modeling tool which supports mdl. Using a proprietary language such Rose mdl, the meta-data is organized so that the component parts of the data model, such as objects and task trees, can be imported and exported at various different levels of generality. However, using a proprietary language limits the interoperability between the data model and other tools as these other tools will need to use parsers that are compatible with the proprietary language in order to retrieve meta-data from the data model.

[0011] Accordingly, there remains a need for generating a data model which is not confined to a proprietary language.

[0012] The present invention provides a mechanism for a task oriented data model for a development tool in an object oriented programming system.

[0013] According one aspect of the invention, the meta-data of the data model is represented using an open standard. Advantageously, by representing the meta-data using an open standard, conventional parsers for the open standard may be used to retrieve the meta-data. According to this aspect of the present invention, the data model takes the form of a document file expressed in Extensible Markup Language or XML. XML comprises a simplified subset of the Standardized Generalized Markup Language or SGML. Like SGML, but unlike other subsets of SGML such as Hypertext Markup Language (HTML), XML permits (i) users to add new defined tags to the tag set at will; and (ii) XML documents to be properly nested within one another to an arbitrary extent. In accordance with this aspect of the invention, the import and export utility in the object builder is implemented to express the data model as an XML document wherein the data elements are arranged according to a meta data model. According to this aspect of the invention, the meta data model comprises a Document Type Definition or DTD in XML.

[0014] According to another aspect of the invention, the data model incorporates a task oriented structure which mirrors the user interface in the object builder. The task tree for the user interface is represented using containment relationships defined by XML constructs specified in the Document Type Definition, i.e. the meta data model. For example, the properties and values in the SmartGuides™ under the Component Broker™ toolkit are represented according to this aspect of the invention as a tag with an identical label and value format. Advantageously, this task oriented data structure allows users to quickly locate and recognize the data element of interest in the data model. In addition, the task oriented structure of the data model provides the capability to export and import data elements with varying degrees of granularity.

[0015] According to an aspect of the invention, there is provided a task oriented data structure embodied in a program storage device for an object oriented application program, the object oriented application program having a user interface comprising a plurality of items, said items defining a sequence of tasks for creating one or more objects, said data structure comprising: (a) a data model expressed in the form of a document according to a meta data language; (b) said data model including a plurality of data elements; (c) each of said data elements corresponding to one of the tasks in said sequence of tasks; and (d) said data elements being arranged according to a meta data model, wherein said meta data model mirrors the sequence of tasks defined in the user interface. Said meta data model may means for validating each of said data elements and the arrangement of said data elements. Further, said meta data language may comprise XML or Extensible Markup Language, and said data elements being arranged according to containment constructs specified in said meta data model. Said means for validating may also comprise a Document Type Definition specified in XML. And, said containment constructs may comprise tag definitions according to XML.

[0016] There is also provided, in an application program for creating objects, the application program having a user interface comprising a plurality of items, said items defining a sequence of tasks for creating the objects, and said application program including an export utility for exporting document files, a export utility comprising: (a) means for exporting a document file expressed in a meta data programming language; and (b) wherein said document file comprises a plurality of data elements, each of said data elements corresponding to one of the tasks in said sequence of tasks, and said data elements being arranged according to a meta data model, wherein said meta data model mirrors the sequence of tasks defined in the user interface. Said meta data model may also include means for validating each of the data elements included in said document file. Said document file may also be expressed in XML or Extensible Markup Language, and said data elements being arranged according to containment constructs specified in said meta data file. And, said means for validating may comprise a Document Type Definition specified in XML.

[0017] According to another aspect of the invention, there is provided a computer program product for an object oriented application program for creating objects, the application program having a user interface comprising a plurality of items, said items defining a sequence of tasks for creating the objects, and said application program including an export utility for exporting document files, said computer program product comprising a program storage device; means recorded on said program storage device for instructing a computer to perform the steps of, (a) outputting a document file, said document file being expressed according to a meta data programming language; and (b) said document file comprising a plurality of data elements, each of said data elements corresponding to one of the tasks in said sequence of tasks, and said data elements being arranged according to a meta data model, wherein said meta data model mirrors the sequence of tasks defined in the user interface. Said meta data model may include means for validating each of the data elements in said document file. Said meta data language may comprise XML or Extensible Markup Language, and said data elements being arranged according to containment constructs specified in said meta data model. And, said means for validating may comprise a Document Type Definition specified in XML.

[0018] There is also provided a computer system for creating objects in an object oriented application program, the application program having a user interface comprising a plurality of items, said items defining a sequence of tasks for creating the objects, and said application program including an export utility for exporting document files, said computer system comprising: (a) means for outputting a document file, said document file being expressed according to a meta data programming language; and (b) said document file comprising a plurality of data elements, each of said data elements corresponding to one of the tasks in said sequence of tasks, and said data elements being arranged according to a meta data model, wherein said meta data model mirrors the sequence of tasks defined in the user interface. Said meta data model may include means for validating each of the data elements in said document file. Said meta data language may also comprise XML or Extensible Markup Language, and said data elements being arranged according to containment constructs specified in said meta data model. And, said means for validating may comprise a Document Type Definition specified in XML.

[0019] Reference will now be made to the accompanying drawings which show, by way of example, preferred embodiments of the present invention, and in which:

[0020] FIG. 1 is a diagrammatic representation of the main window of an object builder of the type suitable for a task oriented data model according to the present invention; and

[0021] FIG. 2 shows the main window of the Component Broker object builder with an exemplary display of a user-defined interface object which has been selected.

[0022] The present invention comprises a task oriented structure for a data model suitable for object oriented programming. According to the invention, the task oriented data structure is implemented using the open standard language XML (Extensible Markup Language). The data model for an object is expressed as an XML document which is defined according to a meta data model. According to the invention, the meta data model is implemented as a Document Type Definition or DTD in XML. The XML document is compatible with the export and import utilities in development tools (e.g. object builder tool). It is a feature of the present invention that the task oriented structure mirrors the user interface in the object builder or development tool. In the following description, the task oriented data structure is described in the context of an object builder application which is in the “toolkit” for IBM's Component Broker software package.

[0023] Reference is first made to FIG. 1, which shows in diagrammatic form an object builder tool 10 in the Component Broker toolkit. The object builder tool 10 is an application program which provides an integrated development environment for software developers. As shown in FIG. 1, the object builder tool 10 comprises a main window 20 having four panes denoted by 21, 22, 23, and 24 respectively. The main view pane 21 on the left side of the window 20 provides the main view which is a task tree view. The main view pane 21 is also the context for the content displayed in the three other panes 22, 23, and 24.

[0024] As shown in FIG. 1, the main view pane 21 comprises a “Framework Interfaces” item (or element) 110, a “User-Defined Business Objects” item 120, a “User-Defined Compositions” item 130, a “User-Defined Data Objects” item 140, a “DBA-Defined Schemas” item 150, a “User-Defined PA Schemas” item 160, a “Non-IDL Type Objects” item 170, a “Build Configuration” item 180, an “Application Configuration” item 190, a “Container Definition” item 200, a “Default Homes” item 210, and a “FlowMark” item 220.

[0025] The content of the other three panes 22, 23 and 24 in the window 10 depends on the selected item or element in the main view pane 21. Referring to FIG. 2, an item from “User-Defined Business Objects” item 120, specifically “Account”, has been selected. In turn, the second pane 22 displays an inheritance graph for the Account item, and the third pane 23 shows the methods and attributes for the Account item. When one of the methods appearing in the third pane 23 is selected, the implementation of that method is shown in the fourth pane 24.

[0026] It will be appreciated that the object builder tool 10 utilizes a task tree structure. As shown in FIG. 1, the “User-Defined Business Objects” item 120 has a user interface which is organized as a task tree structure. The task-oriented structure of the user interface forces a user to follow a specified sequence in order to create a business object, i.e. an object containing business methods (logic) and data (state) that is intended for use within business applications. As will now be described, the data model according to the present invention comprises a task oriented structure which mirrors the user interface. The data model includes all the persistent meta-data which is used by the object builder tool 10.

[0027] Referring to FIG. 1, and specifically the main view pane 21, the task tree structure for the “User-Defined Business Objects” item 120 comprises a file item or element 121, a module item 122, an interface item 123, a key helper item 124, a copy helper item 125, a business object implementation item 126, and a data object item 127. The “User-Defined Data Objects” item 140 is also organized in a task tree structure and comprises a file item 141, a module item 142, and a interface item 142. Similar task tree structures are provided for the “DBA-Defined Schemas” item 150, the “Non-IDL Types Objects” item 170, the “Build Configuration” item 180, the “Application Configuration” item 190, and the “Container Definition” item 200.

[0028] According to the task tree structure for the “User-Defined Business Objects” item 120, a business object is created by the following sequence of steps: (1) create file; (2) create module; (3) create interface; (4) create key helper; (5) create copy helper; and (6) create implementation.

[0029] The first step performed by a user involves creating a file. The object builder 10 generates the file as an IDL (Interface Definition File). As will be understood by one skilled in the art, IDL is a contractual, neutral and declarative language that specifies an object's boundaries and its interfaces, e.g. the aspects of the object that are accessible to the public. IDL provides operating system and programming language independent interfaces to all services and components that reside on a bus as defined according to the CORBA (Common Object Request Broker Architecture) standard. The second step is optional and allows a user to define a module which comprises a grouping of interfaces. The third step performed by the user involves defining the public interface for the user-defined business object. The fourth step involves creating a key helper which comprises an object which provides a copy of the “identity” of the business object. The fifth step involves creating an object which duplicates everything about the business object, not just its identity. The sixth step comprises implementing the specific behaviour, i.e. methods, for the business object.

[0030] Similarly, according to the task tree structure for the “User-Defined Data Objects” item 140, a data object is created according to the following sequence of steps: (1) create file; (2) create module; and (3) create interface. A data object is an object that provides an object-oriented rendering of the application data.

[0031] According to the present invention, the data model comprises a task oriented structure which preserves the sequence of steps followed by a user during the creation of the object. The data content of the object, i.e. instance of data, is expressed by the object builder tool in the form of a text document. Since the data model mirrors the exact order in which the object was created by the user, the data model provides a structure from which the user interface of the object builder tool can be inferred. Because the user interface is implicit in the organization of the data model, the data model can be imported by another tool by simply following or scripting the data structure.

[0032] According to another aspect of the invention, the task oriented data model is implemented using the meta-data language XML (i.e. Extensible Markup Language) and a meta data model is implemented in the form of a Document Type Definition or DTD which is also expressed in XML. XML is a meta-data language which is self-descriptive of both services and information. In the context of the present invention, a meta data implementation is preferred because the data can be generically validated by reading or importing the data. The DTD (i.e. meta data model) is used for validating the correctness of the data model which is expressed in the form of an XML document.

[0033] According to this aspect of the present invention, the meta data model for the “User-Defined Business Objects” item 120 is specified in form of a Document Type Definition in XML as shown below.

[0034] As shown above the meta data model comprises a Document Type Definition (DTD) which specifies the set of required and optional elements, and their attributes, for the data models which are expressed as XML documents. In addition, the DTD specifies the names of the tags and the relationships among elements in the data model, i.e. XML document. It will also be appreciated that the task tree elements for the “User-Defined Business Objects” item 120 are expressed using containment relationships in the Document Type Definition shown above. For example, the file element or item 121 is defined as <!ELEMENT BOFile(Comments| . . . |Uuid)*>, and the module item 122 is defined as <!ELEMENT Module (#PCDATA| . . . Uuid)*>. Similarly, in the DTD the “attributes” of the object are defined as <!ELEMENT Attribute (Type |Initializer| . . . )*>, and the “methods” of the object are defined as <!ELEMENT Method (ReturnType| . . . )*>. The specific syntax of the meta data model expressed in the above DTD will be within the understanding of those familiar with XML.

[0035] Next, the meta data model according to the present invention for the “Non-IDL Type Objects” item 170 is specified in the form a Document Type Definition as shown below.

[0036] The specific syntax of the meta data model for the “Non-IDL Type Objects” item as expressed in the above DTD will be within the understanding of those familiar with XML.

[0037] The meta data model according to the present invention for the “Build Configuration” item 180 is specified in the form of a Document Type Definition as shown below.

[0038] The specific syntax of the meta data model for the “Build Configuration” item as shown in the above DTD will be within the understanding of those familiar with XML.

[0039] The meta data model according to the present invention for the “Application Configuration” item 190 is specified in the form of a Document Type Definition as shown below.

[0040] The specific syntax of the meta data model for the “Application Configuration” item as shown in the above DTD will be within the understanding of those familiar with XML.

[0041] The meta data model according to the present invention for the “Container Definition” item 200 is specified in the form of a Document Type Definition as shown below.

[0042] The specific syntax of the meta data model for the “Container Definition” item as shown in the above DTD will be within the understanding of those familiar with XML.

[0043] The DTD's shown above provide the meta data models which define the content and arrangement of the data models (i.e. XML documents) generated by the object builder tool 10, and the specified tags provide a mechanism for interpreting the data elements expressed in the XML document. When an XML document is imported by an object builder tool or some other XML compatible tool, the XML document is parsed and rendered according to the specifications in the meta data model, i.e. the DTD. Because the DTD provides a description of the data model, an application can validate that the XML document conforms to its specified structure, i.e. data model. This validation can be automated as the XML language is machine readable.

[0044] The task oriented data model for the object builder as specified in the DTD's above allows the data to be exported and imported with the following granularity: (1) the entire data model; (2) all business objects under the task tree for the “User-Defined Business Objects” item 120 (FIG. 1); (3) a single Business Object unit; (4) all data objects under the task tree for the “User-Defined Data Objects” item 140 (FIG. 1); (5) a single Data Object unit; (5) all schemas under the task tree for the “DBA-Defined Schemas” item 150 (FIG. 1); (6) all nonIDL types under the task tree for the “Non-IDL Type Objects” item 170 (FIG. 1); (7) all makefiles under the task tree for the “Build Configuration” item 180 (FIG. 1); (8) all application families under the task tree for the “Application Configuration” item 190 (FIG. 1); (9) all containers under the task tree for the “Container Definition” item 200 (FIG. 1).

[0045] Advantageously, the human-readable form of the data model (i.e. the XML document) and the meta data model (i.e. the DTD) allow a user to directly examine the data model and quickly locate the data element or item of interest.

[0046] The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. For example, while the task oriented data model was described in the context of an XML implementation, it will be understood that implementations using other meta data language specifications can be used. Therefore, the presently discussed embodiments are considered to be illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

[0047] The invention may be implemented as a computer program product comprising a program storage device and means recorded on said program storage device for instructing a computer to perform the steps of the invention and as a data structure embodied in a program storage device. Such a program storage device may include diskettes, optical discs, tapes, CD-ROMS, hard drives, memory including ROM or RAM, computer tapes or other storage media capable of storing a computer program.

[0048] The invention may also be implemented in a computer system. In a preferred embodiment, a system is provided comprising a computer program operating on a data processing system, with the computer program embodying the method of the invention and producing an output of the method on a display or output device. Data processing systems include computers, computer networks, embedded systems and other systems capable of executing a computer program. A computer includes a processor and a memory device and optionally, a storage device, a video display and/or an input device. Computers may equally be in stand-alone form (such as the traditional desktop personal computer) or integrated into another apparatus (such as a cellular telephone).

[0049] While this invention has been described in relation to preferred embodiments, it will be understood by those skilled in the art that changes in the details of processes and structures may be made without departing from the spirit and scope of this invention. Many modifications and variations are possible in light of the above teaching. Thus, it should be understood that the above described embodiments have been provided by way of example rather than as a limitation and that the specification and drawing are, accordingly, to be regarded in an illustrative rather than a restrictive sense.