Method and system for assembling and utilizing components in component object systems6957417Abstract A design tool for assembling component objects to form an object-based computer system application includes a declarative user input interface mechanism and a design engine. The declarative user input interface mechanism provides an input structure for the input of user declarations specifying operative interactions between component objects. The design engine automatically generates, in response to input user declarations, an application design definition modeling an application infrastructure for managing component object interactions. The design engine automatically generates, in response to input user declarations, a match between an application view field definition and a parameter of an associated component object operations. A runtime tool includes an application engine which is responsive to an application design definition and is operative at runtime automatically to create application view instances from respective application view definitions for managing runtime component object interactions for the applications. Claims 1. A method for forming an object-based computer system comprising: Description FIELD OF THE INVENTION
In the object-oriented model, objects provide access to objects via units of software functionality, usually referred to as operations or methods. An operation is generally thought of as having two parts, namely an external definition and an internal implementation. The internal implementation is specified as algorithms or rules and turned into an executing unit via suitable tools. The algorithm may act on the particular object to which the operation belongs and may also invoke any operation of any other object within the scope of the system, subject to any constraints of the system. However, to a client which requires access to a component object, the internal implementation is of little interest. Indeed, it is often only physically present in the computing environment as compiled computer code. In contrast, a client which requires access to an operation would have at least some part of the external definition of the operation available. The mechanism varies with the object system, but at some level it is possible to discover how the operation is invoked and what it does. The external definition of an operation, of a specific object, may also include the object to which it applies, and may also include a number of additional parameters or argument definitions. Typically, the parameters are defined in the formal syntax of the object system. Other defined information may also be available such as non-formal descriptions of the parameters, formal and non-formal descriptions of the operation, formal and non-formal precondition information. FIG. 2 of the accompanying drawings is a schematic representation of this. Parameters define elements which will either be used (inputs), returned (outputs), or used and returned (inputs and outputs) by the operation. In general, the definition of parameters is limited only by the scope of the system, i.e. a parameter can potentially be any object or data type value within the scope of the system. For example, suppose an operation to return information about the "Orders a Customer has Placed" is required. This could be defined as an operation called, say "List Orders for Customer", for which the customer is a required input parameter, and for which outputs include a list of orders, a count of the total number of orders and the last order fulfilled. FIG. 3 of the accompanying drawings is a schematic representation of this. To carry out some user task or function in an application which utilises a component object system, the use of one or more operations is required, often from different objects (components). In most cases, for the task to be achieved, information output by one operation is required as input to another operation to achieve some overall effect. For example, with reference to FIG. 4 of the accompanying drawings, a "List Orders for Customer" operation 20 might also be used in conjunction with a "List Customers" operation 22, a "Customer Details" operation 24, an "Add New Order for Customer" operation 26, and a "Total Invoice for Customer" operation 28. Given such a set of operations, application designers typically write computer algorithms (the 'glue' between operations) to carry out the flows or information or information mappings as part of the process of assembling a new component or application. In addition, the designer must ensure that required input information is available in the right format for an operation to run successfully. For example, a "List Orders for Customer" operation 20 might require a single "Customer ID" as an integer data type, but a "List Customers" operation 22 may supply a list of values as string data types. FIG. 4 illustrates this glue as flow lines having arrow heads between operations. When the application is run, information is passed along the flow lines in accordance with the defined algorithms. Apart from ensuring an accurate mapping of information between relevant operations, the designer also needs to provide a user interface for the end user to have an understanding of and to be able to interact with the component objects being used by the application. In addition to writing computer algorithms to pass information between the operations, the designer will normally use some internal, intermediate representation of the information encompassed within the scope of that set of operations. Frequently, the designer will use language or environment features such as variables, arrays or collections to organise these intermediate representations. Part or all of these representations are typically translated to the human-computer interface to provide the user with an understanding of the state of the objects and to allow the user to interact with the objects. FIG. 5 of the accompanying drawings illustrates this as arrowhead lines between the operations identified in FIG. 4 and a user interface 30. For example, the designer may define algorithms to present the list of customers returned by the "List Customers" operation 22 in the computer user interface and translate the user interface representation of the chosen customer into the input parameters of the "List Orders for Customer" operation 20. The outputs of this operation will in turn be presented in the computer user interface. When considering user interface representations, the designer must also comprehend and provide a mechanism for managing the interaction of related information from operations. For example, in an application which shows a list of customers and a list of orders for a customer, if the end user changes, the selected customer of the application should refresh the list of orders by running a suitable operation. In general, therefore, the designer must provide a mechanism which:
It will be appreciated from the above that the development of new applications, even using components which are ready for assembly, is a complex task requiring significant software development times by skilled engineers. Accordingly, an aim of the invention is to provide a mechanism which will enable application development times to be further reduced. In particular, an aim of the invention is to facilitate the generation of applications from component objects. SUMMARY OF THE INVENTION In accordance with an aspect of the invention, there is provided a design tool for assembling component objects to form an object-based computer system application, the design tool comprising: a declarative user input interface mechanism configured to be operable to provide an input structure for inputting user declarations specifying operative interactions between component objects; and a design engine configured to be operable automatically to generate, in response to input user declarations, an application design definition modelling an application infrastructure for managing component object interactions. The use of a declarative user input interface mechanism and a design engine enables a user readily to describe an intended application by means of declarative statements and automatically to generate an application design definition from those declarations, which application design definition then models the application infrastructure for managing component object interactions. This removes the need for a designer to write specific program code to link components. The use of declarative statements facilitates the automation of the application assembly process, facilitates application verification and maintenance. Preferably, the design engine is configured to be operable automatically to generate, in response to input user declarations, at least one application view definition for managing component object interactions, and to cause the application design definition to reference at least one application view definition. In this manner, a plurality of application definitions, each representing an application view, can be associated with an application design. Preferably, an application view definition comprises one or more fields, the design engine being configured automatically to generate, in response to input user declarations, at least one application view field definition for detailing a field of the at least one application view definition. The application definition can, in this manner, be implemented as a table in a database. Preferably, the design engine is configured automatically to generate, in response to user input declarations, at least one operation usage definition to specify an effect a component object operation has on one or more of the application view definitions. Preferably also, the design engine is configured automatically to generate, in response to input user declarations, an event definition of an operation usage triggered by an application view definition event. More preferably, the design engine is configured automatically to generate, in response to input user declarations, a match between the application view field definition and a parameter of an associated component object operation. These mechanisms facilitate the many-to-many linkages which are needed between objects to control information flow between those objects. In accordance with another aspect of the invention, there is provided a runtime tool comprising an application engine responsive to an application design definition modelling an application infrastructure for managing component object interactions, wherein the application engine is configured to be operable at runtime automatically to create application view instances from respective application view definitions for managing runtime component object interactions for the application. The runtime tool is thereby able to interpret the application design definition in order to generate application view instances for managing runtime component object interactions. Preferably, the application engine is configured to be operable at runtime to provide automated management of data values provided to operation, and data values provided by operations when the operations are invoked by an application view instance. More preferably, the application engine is configured to reference the application view definitions to provide one or more of the following functions:
In accordance with another aspect of the invention, there is provided a user interface configuration tool for automatically configuring a user interface based on an application design definition modelling an application infrastructure for managing component object interactions, the tool being configured to be operable to cause an application engine to interact with the application design definition for creating application view instances from respective application view definitions and for managing application data, the tool also being configured to be operable to display values held in the application view instances and to permit operations to be invoked. In accordance with a further aspect of the invention, there is provided a method of assembling component objects to form an object-based computer system application in a computer system, the method comprising: The invention further provides a method of automated management of object interactions in a computer system, comprising:
In accordance with yet a further aspect of the invention there is provided a method of automatically configuring a user interface based on an application design definition modelling an application infrastructure for managing component object interactions, the method comprising:
In another aspect the invention provides a design tool program on a data storage medium the design tool program being for assembling component objects to form an object-based computer system application and comprising: a declarative user input interface mechanism configured to be operable to provide an input structure for inputting user declarations specifying operative interactions between component objects; and a design engine configured to be operable automatically to generate, in response to input user declarations, an application design definition modelling an application infrastructure for managing component object interactions. In a further aspect the invention provides a runtime tool program on a data storage medium, the runtime tool program comprising an application engine responsive to an application design definition modelling an application infrastructure for managing component object interactions, wherein the application engine is configured to be operable at runtime automatically to create application view instances from respective application view definitions for managing runtime component object interactions for the application. In yet a further aspect the invention provides an object-based computer system comprising a design tool program, the design tool program being for assembling component objects to form an object-based computer system application and comprising: a declarative user input interface mechanism configured to be operable to provide an input structure for inputting user declarations specifying operative interactions between component objects; and a design engine configured to be operable automatically to generate, in response to input user declarations, an application design definition modelling an application infrastructure for managing component object interactions. In yet a further aspect the invention provides an object-based computer system comprising: an object-based computer system application; an application design definition modelling an application infrastructure for managing component object interactions, the application design definition having been generated by a design engine in response to input user declarations; and an application engine responsive to the application design definition and operable at runtime automatically to create application view instances from respective application view definitions for managing runtime component object interactions for the application. BRIEF DESCRIPTION OF THE DRAWINGS Exemplary embodiments of the invention are described hereinafter, by way of example only, with reference to the accompanying drawings, in which: FIG. 1 is a schematic representation of components and an application; FIG. 2 is a schematic representation of an operation definition; FIG. 3 is an example of an operation definition; FIG. 4 is a schematic representation of information flows between operations; FIG. 5 is a schematic representation of information flows between operations and a user interface; FIG. 6 is a schematic representation of the interaction of operations and a user interface via an application view in accordance with an embodiment of the invention; FIGS. 7A-7C are general example of schematic block diagrams of the Application Design concept embodied in the invention; FIG. 8 illustrates a Application Definition detail of FIG. 7; FIG. 9 illustrates an Application View detail of FIG. 7; FIG. 10 illustrates a Component detail of FIG. 7; FIG. 11 illustrates Attribute Views for an Operation Activity Detail of FIG. 7; FIG. 12 represents an Application View Field Match detail of FIG. 7; FIG. 13 illustrates an Operation Usage detail of FIG. 7; FIG. 14A illustrates an Operation Usage with a Listing Effect; FIG. 14B illustrates another Operation Usage, this time having a Listing Effect on one Application View and a Detail Effect on another Application View; FIG. 15 is a table representing Event Type versus Operation Effects; FIG. 16 illustrates a Reset Event which triggers an Operation Usage; FIGS. 17A-17C are schematic block diagrams of a particular embodiment corresponding generally to FIG. 7; FIG. 18 is a schematic block diagram of a Object System for Application View Design; FIG. 19 is a Object System for Runtime Data Management; FIG. 20 illustrates a main window of an Application Design Tool; FIG. 21 illustrates a window showing Application View Definition properties; FIG. 22 is a window for Operation Usages; FIG. 23 is a window for Match Editing; FIG. 24 is a window for a first Application Design Step; FIG. 25 is a window for a second Application Design Step; FIG. 26 is a window for a third Application Design Step; FIG. 27 is a window for a fourth Application Design Step; FIG. 28 is a window for a fifth Application Design Step; FIG. 29 is a window for a sixth Application Design Step; FIG. 30 is a window for a seventh Application Design Step; FIG. 31 is a flow diagram showing the initiation of a run-time Application Engine; FIG. 32 is a flow diagram describing an Event Monitoring process; FIG. 33 is a flow diagram describing a Run Operation Usage Event process; FIG. 34 is a flow diagram describing the processing of Operation Effects for an Operation Usage; FIG. 35 is a flow diagram for Application View Event processing; FIG. 36 is a flow diagram for Clearing Dependent Application Views; FIG. 37 is a flow diagram for Processing the Event Triggers of an Application View Event; FIG. 38 is a flow diagram for External Application View Events; FIG. 39 represents an extended MON to hold Application View Design information; FIG. 40 is a schematic diagram representing the architecture of an Integration Assist mechanism (IA) Object Server; FIG. 41 is a schematic diagram representing an Architecture of a Visual Basic Application incorporating the invention; FIG. 42 illustrates a main window of an IA test tool; FIG. 43 illustrates a Layout Manager user interface; FIG. 44 illustrates the result of designer customisation; FIG. 45 illustrates components of an application at runtime and a sequence of actions in running an operation; and FIG. 46 is a schematic representation of a multicomputer distributed computing system on which an embodiment of the present application may be implemented. DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments of the invention as described hereinafter provide methods and systems for declaratively specifying relationships between parameters of different operations of the same or different objects, the organisation of an intermediate representation of the parameters of operations for the purpose of user interface display in an application and the effects operations have on related information, and how operations are triggered in response to certain user interface events. These characteristics are defined by means of structure termed described herein as an Application View Definition. An individual instance (in the object sense) of an Application Definition (note "instance" loosely means a copy based on a template) is referred to as an Application Instance or Application View. These terms are also used interchangeably herein. FIG. 6 is a schematic illustration of the interaction of operations and a user interface by means of an Application View 32. The term "Data Region", which appears in the drawings, is also used loosely to refer to an Application View Definition and an Application View Instance in a particular embodiment of the invention. Application View Definitions have a number of characteristics. In particular, an Application View Definition provides a way of specifying an intermediate representation of information for use with user interfaces. Application View Definitions generated in accordance with the invention are typically specified so as to provide a one-to-one mapping to the user interface elements of an application. They detail how operation parameters should flow between each other, via Application Views. They detail how the running of operations effects related Application Views, and how the Application Views should respond to user interface events. They detail when it is possible to run an operation which utilises information from Application Views. An embodiment of the invention provides a mechanism for the automated creation of Application Views from their respective Application View Definitions and the automated management of the actual data values provided by operations when they are invoked. This mechanism is termed the Application (View) Engine, or Run-time Engine. In an embodiment of the invention, the Application Engine can be deployed as part of an end application. An embodiment of the Application Engine can perform one or more of the following functions by referencing the Application View Definitions:
In an embodiment of the invention, the specification of an Application View Definition can be provided as a structural layer independent from the user interface elements. It can then be reused with other user interface element arrangements, whilst preserving the mapping of information flows between operations. This means that specifications can be shared between applications which conform to the same underlying object computing model. Since Application View Definitions provide for a declarative mapping of operation parameters, Application View Definitions are easy to maintain and can be subject to automated testing and verification methods. An embodiment of the invention can be used as a method (perhaps with CASE tool support) during the analysis and design of computer systems. The method would involve:
In the following, there follows a description of examples of Application View Designs as generated in accordance with embodiments of the invention. FIG. 7 is a schematic block diagram of a general example of an Application Design model 40 in accordance with the invention. It will be understood that the general representation of FIG. 7 is merely one possible example and many changes, modifications and/or additions could be made in other embodiments of the invention. In FIG. 7, each block represents an entity type. The relationship between entity types is depicted by relationship lines in accordance with standard notation. Each entity type can be thought of as having a common set of properties, namely:
There are three basic sections to the model 40 shown in FIG. 7. The Application View Design area 42 covers the entity types used to hold the definition of Application Views. The Component Description 44 covers the features of components exploited by Application Views. The Runtime Data Management area 46 describes the objects which hold actual instances of Application Views. The Application View Design 42 and Component Description 44 areas capture the information which describes the composition of Application Views, and their relationship to a description of specific components. The Repository 48 is used as a starting point or "root object" for the Application Views. There can in principle be many Application Designs (each made up of potentially many Application Views). Consequently, it is advantageous to think of the collection of Application Designs being available from some artefact, such as the Repository 48. The Repository 48 is said optionally to hold {481} zero, one or more Application Designs. The Repository object can be manifested in a computer system by persistent storage capable of holding one or more Application Designs. An Application Design 50 holds design information pertinent to one application. This object conceptually provides the root object for a description of all elements which describe the composition and workings of the user interface components within an application which are visible to, or working on behalf of, some user. Any Application Design is expected to contain {501} zero, one or more Application View Definitions 52 and to contain {502} zero, one or more Operation Usages 66. As Application View Definitions 52 may be presented to the user, it is useful to hold them in a user-specified sequence (symbol s). FIG. 8 is an entity model fragment and corresponding instance diagram for an Application Design. An Application View Definition 52 is contained in {501} or utilised by one or more specific Application Designs 50. FIG. 7 shows one Application View Definition 52 for ease of representation purposes only. Typically, an Application Design 50 will contain many Application View Definitions 52, with each one being used for a different purpose. Each Application View Definition 52 is detailed by {521} one or more Application View Field Definitions 52. This can be compared to a database table being described by a series of columns. Further, an Application View Definition 52 may be based on {561} a specific Component 56. FIG. 7 assumes that there is only one Component 56 for ease of representation, although in fact an Application View Definition may be based on a plurality of Components 56. An individual instance of an Application View Definition 52 is referred to as an Application View 80. The model allows there to be many instances {522} of a specific Application View Definition 52, but typically there will only be one. An Application View 80 inherits the properties of its Application View Definition 52. An Application View 80 can be created from its corresponding definition at any time. However, it is useful to think of an Application View 80 being created from the corresponding Application View Definition 52 by the Application Engine at runtime. An Application View Definition 52 can have the following properties:
An Application View Field Definition 54 details {521} a specific Application View Definition 52. In principle, the same Application View Field Definition 54 could provide details for many Application View Definitions 52, but FIG. 7 illustrates only one Application Field Definition 54 associated with the Application View Definition 52 for ease of representation. FIG. 9 represents the composition of an Application View. An individual instance of an Application View Field Definition 54 is referred to as an Application View Field 84. The purpose of an Application View Field Definition 54 is to describe the nature of values which may occur in an Application View Field 84. Each element of the description is held as a property (or other related entity type). The nature of the elements being described is dependent upon the particular implementation, but the following properties are typical of those which are used to describe general characteristics:
The Application View Field Definition 54 may be based on {601} an Attribute 60. In that case, the value of its properties will reflect that of the Attribute or at least obey a set of transformation rules which allow values to coexist. For example, the length property value may be smaller than that of the Attribute 60 in which case any Application View Field Value could be copied into an instance of an Attribute 60 without transformation. However, reversing the action and copying from an Attribute instance into an Application View Field 54 would require transformation rules to reduce the length of any value. A Component 56 is an artefact which provides the user with a set of services to carry out some task. The state of any Component 56 may be reflected in properties associated with the Component 56, although these properties themselves may be accessed by services, depending on a particular implementation. Where objects implement Components 56, the Operations 58 of an object implement the services of a Component 56, and its properties are expressed as Attributes 60. An Operation 58 is a unit of functionality associated with {563}, and operating on, a specific Component 56. In software, Operations 58 are manifested as computer code, and associated with an object by underlying mechanisms of the operating system or environment. FIG. 10 is a schematic representation representing the relationship of a Component 56 to Attributes 60 and Operations 58. An Operation 58 may also provide {581} or use a number of additional parameters or Attribute Views 62. These are used to supply values to and/or from the Operation 58. One or more Attributes 60 describe {562} a Component 56. Each element of the description is held as a property (or other related entity type). The nature of the elements being described is dependent on the particular implementation, but the following properties are typical of those for describing general characteristics:
An Attribute View 62 holds the definition of information to be passed to/from an Operation 58. In general, each Operation 58 may provide {581} zero, one or more Attribute Views 62. Attribute Views 62 have a number of properties to describe the information to be passed. This includes those of the Attribute 60 itself and also properties to capture:
Other properties are likely to be needed depending on specific implementation needs. FIG. 11 is a schematic representation showing Attribute Views 62 for the Operation 58 activity detail. It is to be noted that one number relates {602} to an Attribute 60 of an activity, whilst the other number relates {602} to an Attribute 60 of a project. The properties of an Attribute View 62 reflect that of the Attribute 60 the Attribute View is representing. Thus, an Attribute View 62 is thought of as being a view of {602} an Attribute 60 which in turn describes a Component 56, but not necessarily the one which the Operation 58 services. At runtime, whenever an Operation 58 is run, a set of Attribute Views 62 for an Operation 58 are manifested as {621} Attribute View Instances. An Application View Field Match object 64 defines the flow of information between Application View Field Definitions 54 and Attribute Views 62. Any Operation Usage 66 includes {661} a set of Application View Field Matches 64 for that particular Operation Usage 66. An individual Application View Field Match object 64 is matched from {541} a particular Application View Field Definition and is matched to {622} a specific attribute view. FIG. 12 is a schematic representation of the matching of Attribute Views 62 to Application View Fields. An Application View Field Match 64 provides a number of definitions:
An Overwrite Property of the Application View Field Match 64 is applicable only to each Application View Field Match against Attribute Views of an input type and indicates whether any value supplied from an external source should be taken in preference to any current value held in an Application View Field 84 when values are mapped into an Operation's input Attribute Views 62 immediately prior to running the Operation 58. The default is not to allow overwrite except for Operation Usages 66 with an Operation Effect 68 of type Update or Add Row. The Operation Usage object resolves the inherent many-to-many relationship between the Operation object 58 and the Application View Definition object 52 since a specific Operation 58 may be used by many Application View Definitions 52 and a specific Application View Definition 52 may make use of many Operations 58. FIG. 13 is a schematic representation of one Operation 58 with two Operation Usages 66 providing different Application View Field Matches 64. An individual Operation Usage 66 includes {661} a set of Application View Field Matches 64. The same Operation 58 may occur more than once as an Operation Usage 66 with each current Operation Usage 66 having a different set of Application View Field Matches 64. Each Operation Usage 66 will produce {662} some effect (Operation Effect object 68) on the Application View Definition 52. An Operation Usage 66 provides a number of rules including: Operation Usages 66 can have different effects on different Application View Definitions 52. There are several causes for these effects:
A particular classification scheme is provided for the type of effect produced. Each effect type is represented by a different Operation Effect object 68. A constraint imposed for simplicity is that each Operation Usage 66 may produce more than one Operation Effect 68; but only one per Operation Usage 66 and Application View Definition 52 pairing (i.e. an Operation Usage 66 has only one Operation Effect 68 on a specific Application View Definition 52). Generally, when an Operation Effect 68 is produced from the running of an Operation Usage's Operation 58, the Operation Effect 68 will raise {681} an Application View Event 70. The Event 70 is defined by {523} the Application View Definition 52 and typically causes some change in state of the Application View 80 (e.g., Reset or Clear). The set of Effect types described above is not exhaustive, and other effects could be added or a different scheme devised. A Listing Operation Effect 68 is one which causes Application View Fields 84 to be cleared of current values and replaced with new values from the Attribute Views 62 of the Operation 58. Typically, an Operation Usage 66 having Application View Field Matches 64 return a list or set of values for each Application View Field Definition 54 is classified as causing a Listing Operation Effect. However, any Operation Usage 66 could be said to cause this effect. FIG. 14A is a schematic representation of an Operation Usage 66 with a Listing Effect 68 for which it raises {681} a Clear Event 70 on an Application View 80. When a Listing Operation Effect 68 is produced, it raises {681} a Clear-type Application View Event 70. This Event 70 clears all values from the Application View 80 prior to any new values being mapped into it. A Detail Operation Effect 68 is one which causes information about the current row in the Application View 80 to be refreshed or expanded. Application View Field Matches 64 which return values from the Operation 58 are mapped into the current row. When a Detail Operation Effect 68 is produced, it may optionally raise a "Position On" type Application View Event 70. FIG. 14B is a schematic representation of an Operation Usage 66 having a Listing Effect 68 on one Application View 80 and a Detail Effect 68 on another Application View 80. An Update Operation Effect 68 is one which causes values in the current row of an Application View 80 to be updated. Application View Field Matches 64 which represent input values are provided with any new values and Application View Field Matches which return values from the operation are mapped into the current row. An Add Row Operation Effect 68 is one which causes the used row property of the Application View 80 to be increased by one and values returned from Application View Field Matches 64 to be mapped into that new row. Conceptually, there is no difference whether the new values are added at the end of the Application View 80 below the current row or above the current row. However, facilities supplied by an implementation would need to distinguish these cases. When an Add Row Operation Effect 68 is produced, it raises an "Expand" type Application View Event 70. A Delete Row Operation Effect 68 is one which causes the used row property of the Application View 80 to be decreased by one and values in the current row to be removed. Any values returned via Application View Field Matches 64 into the Application View are ignored. When a Delete Row Operation Effect 68 is produced, it raises a "Contract" type Application View Event 70. For any Operation Usage 66, Application View Definition pairing which does not cause any other effect, the Operation Effect 68 is of an Unclassified type. A Clearing Operation Effect 68 runs a Clear Event 70 on the specified Application View 80. Similarly, a Resetting Operation Effect 68 runs a Reset Event on the specified Application View 80. In general, internal or external stimuli to an Object may cause certain Events on that Object to occur. A non-exhaustive set of events for the Application View Object has been illustrated. Externally, the Application View Events 70 are raised by {681} Operation Effects 68. Internally, Application View Events 70 are signalled by the Application Engine (at runtime). When an Application View Event 70 occurs, it triggers {701} any Operation Usages 66 that are activated by {721} Event Triggers 72. For example, the "Position On" Event 70 might trigger an Operation Usage 66 to fetch more details about the subject of the current row. The Event 70 can trigger zero, one or more Operation Usages 66. FIG. 15 is a table representing Event Type versus Operation Effects, where X is an allowed combination, DEP is allowed on dependent Application Views, Input uses only input values and Update relates to an Input Attribute View that may contain user supplied values. The asterisk identifies a single default listing operation. In this example each event type is represented by a different Application View Event Object. In the following, various Application View Event Types are described with an indication of the rules which relate to those event types. Rules
Rules
Rules
Rules
Rules
Rules
Rules
The Event Trigger Object 72 resolves the inherent many-to-many relationship between Application View Events 70 and Operation Usages 66. Any Application View Event 70 may trigger many Operation Usages 66 and an Operation Usage 66 may activate many Application View Events 70. Accordingly, any Application View Event 70 may trigger {701} a defined sequence of Event Triggers 72. FIG. 16 represents a Reset Event 70 which triggers an Operation Usage 66. It should be noted that the same Operation Usage 66 has a Listing Effect 68 which raises a Clear Event 70. There has, therefore, now been described the Application View Design and Component Description areas of a general model for Application Views of FIG. 7, the Application View Design and Component Description areas being modeled during the design stage of an application. There will now be described the Runtime Data Management area of FIG. 7. The area describing Runtime Data Management models the objects used to hold actual Application Views 80 during execution of the system. In the implementation, this information is stored either in memory, for the life of the application, or in a database to provide persistence. The object entitled Application View 80 is the object which holds the data for an Application View Definition 52 based on the structure defined by the Application View Definition 52 and its Application View Field Definitions 54. The Application View Row object 82 holds specific data for an instance of information, matching the Rows of the Application View Definition 52. The Application View Field object 84 holds the data for a Field information, based on the Application View Field Definition 52. The Row/Field Entry object 86 relates to a specific element in a row, such as a value for some field. This object maps 861 to Attribute View Instances 88 according to the mapping rules described in the Application View Field Match 64. An Attribute View Instance object 88 is the manifestation 621 of a Attribute View 62 at execution time. This is the actual object described by the Attribute View, with values for its properties based on values made available at execution time. The values flow between an Attribute View Instance and an Attribute Field based on the mapping rules described in the Application View Field Match 64. FIG. 17 is an example of a specific implementation of the model illustrated in FIG. 7. The specific implementation of FIG. 17 has much in common with the general example of FIG. 7. The Runtime Data Management area 46 is in fact identical for the FIG. 17 implementation and FIG. 7 example, and it has therefore not been reproduced in FIG. 17. The majority of changes (described below) with respect to FIG. 7 are for reasons of efficiency of implementation. The particular implementation described with respect to FIG. 17 was designed to integrate with Texas Instrument's Arranger environment. The Component Description area 44 is replaced by an Arranger Objects area 44. The component description objects overlap with the Arranger objects. The Repository entity type 48 is used as a starting point or "root object" for the Application Definitions. It is part of the Arranger model and has the same properties as for the example of FIG. 7. In the implementation of FIG. 17, a maximum of one Application Design 50 is defined by {481} the Repository 48, rather than the many of the example of FIG. 7. The Application Design 50 object of FIG. 17 has the same properties and relationships as the Application Design object 50 of FIG. 7. The Application View Definition object 52 of FIG. 17 differs from the Application View Definition Object 52 of FIG. 7 in that it implements the following properties:
Max Rows, Used Rows, Current Row are not implemented as properties in the implementation of FIG. 17. Max Rows is maintained instead on the Application View Field Match object 54. Used Rows is maintained by the Application Engine in in-memory storage for each Application View during the running of the system. Current Row is maintained by the Application Engine in in-memory storage for each Application View 80 during the running of the system. The Application View Field Definition differs from the Application View Field Definition Object 54 of FIG. 7 in that it implements the following properties:
Data Type, Decimal Places, Default Value, Is Case Sensitive, Length, Permitted Values are not implemented as properties on the object, but instead the same properties on the corresponding Attribute are used. The relationship 'is matched to' between Application View Field Definition 54 and Application View Field Match 64 has been replaced by two relationships 'supplies import for' {542} and 'uses exports from' {642}. These two relationships perform the same function, but maintain a separation of field matches used for inputs (imports) and those used for outputs (exports). This provides the Application Engine with a quicker lookup mechanism. In this implementation, Arranger's Entity Type object 56 is substituted for the Component 56 in the example of FIG. 7. In the Arranger product, some Entity Types are categorised as Business Object Types. The properties of Entity Types that Application Views make use of are:
The relationships that Application views make use of are:
The Operation entity type 58 is a standard feature of the Arranger product. No new relationships or properties need to be defined here. In the Arranger product, only Entity Types of the category Business Object Types are serviced by Operations 56. No properties (apart from the operation name) are used directly by the system. However the running of an operation is delegated entirely to the Arranger system, so that in this respect the standard properties are used. The Attribute is a standard object of the Arranger product. No new relationships or properties have been added for Application Views. The properties that Application Views make use of are:
The relationships that Application views make use of are:
The properties of the Attribute are not used directly, but are instead supplied by the Arranger product via the Attribute View object 62. The Attribute View is a standard object of the Arranger product. No new relationships or properties need to be added here. The Arranger product organises Attribute Views into two separate sets; one for inputs (called import views) and one for outputs (called export views). In addition, there is an organisation within a view set to allow grouping of contextually related items. Attribute Views may optionally be placed in a Group View. In an import or export set, there can be many Group Views. Typically a Group View will be used to identify a set of Attribute Views which supply a number of values (called a Repeating Group View in Arranger terminology). The properties that Application Views make use of are:
The Application View Field Match also implements the following properties:
A Transformation Rule is not implemented as part of the Application View Definition. The user is provided instead with a programmatic exit to allow them to define their own rules as needed. The Operation Usage 66 implements the following properties:
For Implementation Rules, only one Repeating Group View of an operation usage can be mapped into any one Application View. The Operation Effect 68 also implements the following properties:
The Category property indicates the Effect that the Operation Effect object represents. There are the following differences in the classification scheme: An Instance Effect represents the Input Operation Effect. An Unused Effect provides a new category to represent the state of any Attribute View before a match has been specified for it. Any Attribute Views which are not matched are associated with an Operation Effect having this classification. Clearing and Resetting Effects are not implemented in this embodiment of the invention. In this implementation, some constraints are placed on the classification of operations; for example only an operation which has an export repeating Group View of cardinality >1 can be classified as a listing operation. The Application View Event 70 also implements the following properties:
The Category property indicates the Event type that the Application View Event object represents. The Reset and Position Event is not implemented as a value. The same net effect as a Reset and Position Event is achieved in software for an Application View since the default behaviour of Reset is to set the current row counter to the first row in the table (and thus trigger the Position On event). In the generalised embodiment all dependent tables are cleared if Application View is cleared (via a clear event). The ClearDependants property allows this default behaviour to be changed. There is no restriction as to the Effect type of Operation Usage(s) that an event can trigger. Relaxing the rules allows the user to have any operation usage run when an event occurs. The Event Trigger object is as for the general embodiment of FIG. 7. The Runtime Data Management is implemented with runtime data management information held either as in memory objects, or as tables in a database. The mechanism used depends on design considerations for the target environment. For example, on specific implementation for Visual Basic 4.0, the information is stored in an Access database since Access databases have a high degree of interoperability with Visual Basic. In the particular implementation;
FIG. 18 is an alternative schematic representation of the Application View Design of FIG. 17. FIG. 19 is a schematic representation of the runtime objects for runtime data management. In a preferred embodiment which uses Microsoft Corporation's OLE component technology, an Object Server, termed herein the Integration Assistant Object Server, or the Integration Assistant Mechanism Object Server (IA Object Server) provides all these services to support the design and runtime aspects of Application Views. Thus, there are two broad types of service supported, those to create and maintain Application View Definitions (Application View Design Information) at design time, and those to manage Application Views during the process of executing operations (Runtime Data Management) used at runtime. The Object Server provides the services illustrated as OLE Automation Objects. Thus FIG. 18 shows the OLE object structure manifested by the IA Object Server for the manipulation of Application View Design information. These objects, together with the methods and properties are available as an OLE Automation Interface which is herein referred to as the Integration Assistant Interface (IA). FIG. 19 shows the OLE object structure manifested by the IA Object Server for runtime data management. The following section describes the methods and properties of each object in the IA Object Server. The Administrator object 80 is the root object of the IA Object Server. It provides access to the objects which describe Application Views and offers administrative services to maintain the state of the Object Server. The Administrator has the property:
The Administrator provides the following functions:
The Application Design object 50 has the property of:
The Application Design object 50 provides the following functions:
The Application View Definition object 52 has properties of:
The Application View Definition object 84 provides the following functions:
The Application View Field Definition object 54 has properties of:
The Application View Field Definition object 54 provides the following functions:
The Application View Field Match object 64 has properties of:
The Application View Field Match object 64 provides the following functions:
The Operation Usage object 66 has properties of:
The Operation Usage object 66 provides the following functions:
The Operation Effect object 68 has properties of:
The Operation Effect object 68 provides the following functions:
The Application View Event object 70 has properties of:
The Application View Event object 70 provides the following functions:
As mentioned above, a preferred embodiment of the invention is implemented using Microsoft Corporation's OLE component technology. The IA Object Server is designed to be a replaceable component. Any other component which offers equivalent OLE objects, methods and properties can be substituted. The significance of this is that it allows object servers which have interactions with systems other than Arranger to be provided. The Arranger product itself is also implemented using Microsoft OLE technology to implement a network of objects which hold information defining business objects, their operations and parameters often referred to as Meta Data. This navigable network of objects collectively referred to as a Meta-object Network or MON. The network of OLE objects of the Arranger product implements can be persistently stored in a file (or other objects), and used by the Arranger tools as needed. The Arranger MON was extended in order to capture objects in the Application View Design area 42. The Arranger Object Server provides two OLE interfaces to the MON, called the Business Task Interface (BTI) and the Open Repository Interface (ORI). These interfaces provide access to the objects via a set of OLE methods and properties. These methods and properties are represented in FIG. 39. The Metadata for the Arranger product was extended for an embodiment of the invention to hold all objects and relationships represented in FIG. 17. This has the effect of providing persistent storage of the Application View Definitions via Arranger standard mechanisms and making them available via Arranger's OLE automation interfaces. The IA Object Server allows Arranger's OLE automation interfaces internally to create and maintain objects in the MON in line with the object structures it presents externally via the IA interface. This architecture allows changes to be made to the structure and functionality offered by the IA Interface during development without disturbing the Arranger product, but has the benefit of storage and management of the Metadata associated with the Application Views within an existing mechanism. Alternatives to this would be to store the data associated with Application View Design information separately or to implement the IA Interface as part of the Arranger Object Server. The various objects shown in FIG. 18 are operative at the design stage to act, in effect, as a database of information relating to an Application Design. This information is gathered via an Application Design Tool, which presents a user interface to the user to allow them to manipulate the concepts of Application Design to the IA Object server. The Application Design Tool provides various window menus to a user to assist the user in the performing these tasks by means of declaratory statements for defining the Application View. The architecture of tools for manipulating Application Views is illustrated in FIG. 40. Tools have access to the IA interface and the interfaces of Arranger. Tools which manipulate Application Views at runtime require access to the specific Runtime Data Management System being used. The IA tools implement the logical services and user interface layers of a three-layer architecture. The three-layer architecture includes a data layer, which supports the management data or objects pertinent to the system, a logic layer which supports all the services of the system which use the data layer (and within them all the rules associated with the use of the data) and a user interface layer which permits user interaction and representation of the objects pertinent to the system. FIG. 20 is an example of a main window for a design tool user interface. The display area shows an icon for each Application View Definition. The choice of icon is dependent upon the types of Operation Effect objects associated with the Application View Definition. Note that in the Drawings, the User Interface Application View Definitions are referred to as Data Regions. In the following, various menu options presented to the user are described. The main window provides a user with a file menu including options as indicated below:
The Object Server also provides standard operating system edit and view menus. The Object Server further provides a Tools menu. Under the tools menu there are provided:
The Operation Usage window 22 shows operation usages within the Application Design, or for a particular Application View Definition, depending on menu choice from the main window. This window's menu (see FIG. 22) is provided with a structure and mode of user interaction similar to those of the main window. There is an Operation File Menu providing options as indicated below:
There are Operations Edit and View Menus, an Operations Tools Menu and an Operations Help Menu. A Match Editor Window (FIG. 23) is provided which allows users to create, maintain, or just visualise the Application View Field Match objects for a given Operation Usage to Application View Field Definitions. Using drag and drop gestures with a mouse, it is possible to provide a number of different functions: The DA Mechanism (Application View Wizard) referred to above provides a process-driven facility for users to build and augment Application View Definitions. It does this by providing a highly directed, process driven User Interface that represents Application View Design information. The process of building Application View Definitions is divided into a number of discrete steps. It provides the user with suggestions and defaults, derived by rules and heuristics, for the values of parameters required at each step of the process. It also provides the ability to construct and aid construction of Application View Definitions (and attendant objects) or to augment existing ones. It also provides the ability to interact with other aspects of the overall system. The rules and heuristics of the DA Mechanism are based on common patterns and practices used by developers in the construction of Arranger components, prior to the use of those components in constructing Application View Definitions. The implementation of the DA Mechanism, therefore, is specialised to embody those rules and heuristics. If these working practices were changed, or other information made available, the rules and heuristics would necessarily change to reflect that. If a DA Mechanism were built for another component object system, the overall structure of the approach (steps) might be similar, but Arranger concepts would clearly have no meaning. The DA Mechanism is architectured as an object server, with a user interface, as illustrates in FIG. 24. The DA Mechanism itself is self-contained, except for its use of the IA Object Server to be described in more detail below. Step-specific information is shown in the majority of the window area of the graphical interface of the DA Mechanism. The choice of iconic representation for an Application View Definition is dependent on the types of Operation Effect objects associated with it. The description area is used to show the description associated with the user selected items. A set of push-buttons provide the user with control over the movement between steps (Next, Back), the ability to abort a session (Cancel), the ability to have the DA Mechanism complete the process using defaults and suggestions as given responses (Finish), and access to an online help system (Help). The DA Mechanism dynamically evaluates user input to the values required by the current Step and enables or disables user access to the push buttons Next, Back and Finish depending on the state of the system. Typically, the user is not able to press the Next push button until all the values required by a Step are solicited from the user. The DA Mechanism is initialised in one of two modes by a calling program. It is either invoked in an "Add New Mode" or in an "Edit Mode". The Add New Mode is used when the calling program wants the DA Mechanism to start with a new Application View Definition and Edit Mode when it wants the DA Mechanism to start with an existing Application View Definition. In both cases, all manipulation of Application View Design information is done via an instance of the IA Object Server which is handed to the DA Mechanism when it is invoked via a method on its OLE interface. In the following, functional elements of the seven steps of the DA Mechanism are described which effect in part or as a whole Application Views. It does not describe functionality that is present to support the User Interface or its manipulation. Step 1—Identifying the Application View Definition. The user interface in Step 1 is illustrated in FIG. 24. The primary purpose of this step is to solicit a name for a new Application View Definition, to solicit an optional description for the Application View Definition and/or to allow the user to select a Business Object Type (i.e., a component) which this Application View Definition may (optionally) be based on. To assist in this task, the Wizard provides the following functions: On completing Step 1, the DA Mechanism creates the Application View Definition 52 for the name supplied and if a Business Object Type was chosen, the based-on relationship is established to the Business Object Type between it and the Application View Definition. The DA Mechanism also adds the description for any Application View Definition supplied by the user. Step 2—Choose a Listing Operation. The user interface to Step 2 is illustrated in FIG. 25. The primary purpose of this step is to solicit the name of an Operation of a type Listing which will act on the Application View Definition. A Listing Operation may be thought of as one which supplies values to one or more (typically many) rows in an Application View. When using Arranger, this is any operation which has an export Repeating Group View of cardinality greater than 1. In the Information View structure of an Operation, there may be more than one Repeating Group View. Operations which have this characteristic are said to offer multiple Listing Views. If an Operation offers multiple Listing Views, then these alternatives are distinguished for the user. The DA Mechanism assists functionality in this step by: The following rules and heuristics are used to provide user suggestions for Listing operations:
On completion of the user input to Step 2, the DA Mechanism carries out the following operations including:
For an Application View Definition 'based on' a Business Object Type, the heuristics here are, for each export Attribute View of the chosen Repeating Group View of the Operation Usage: For Application View Definition with no 'based on' a Business Object Type, the heuristics here are, for each export Attribute View of the chosen Repeating Group View of the Operation Usage: Step 3—Choose Auxiliary Operations. The user interface to Step 3 is illustrated in FIG. 26. The primary purpose of this Step is to allow the user to select other Operations of interest which have some effect on the current Application View Definition. An Operation can be said to have some effect on an Application View Definition if one of its Attribute Views is an Attribute of a current Application View Field Definition, or one of its Attribute Views is the same Object Type as the Application View Definition is based on, or one of its Attribute Views is of the same Entity Type as that of a current Application View Field Definition. The DA Mechanism provides functionality to help these tasks by listing Operation Usages that may have some effect. The DA Mechanism identifies candidate Auxiliary Operations by examining (by default) the MON and analysing its current state by using rules and heuristics to suggest zero, one or more Auxiliary Operations. For an Application View Definition with associated Object Type, Operations of the Object Type associated with the Application View Definition are suggested which have one or more non-repeating Attribute Views which are of Attributes of the Object Type and do not already have one or more occurrences of Operation Usages already matched to this Application View Definition. For Application View Definitions without associated Object Types, Operations are suggested which do not already have one or more occurrences of Operation Usages already matched to the Application View Definition and have one or more non-Repeating Attribute Views whose Attributes are currently represented as Application View Field Definitions in the Application View Definition and/or have one or more non-Repeating Attribute Views which are of the same Entity Type as that of a current Application View Field Definition. The user may provide a classification of the Operation Effect Type for each candidate Operation selected by placing an operation under the appropriate heading. In the user interface 26, "Retrieves a row" represents a Detail effect type operation, "Updates a row" represents a Update effect type operation, "Creates a row" represents a Add Row effect type operation and, "Deletes a row" represents a Delete Row effect type operation. On completion of the user input to Step 3, the DA Mechanism carries out the following Operations (assuming the user has selected one or more Auxiliary Operations). For each selected Operation, the DA Mechanism creates an Operation Usage for the selected Operation. The Operation Usage Type is set to the Type specified by the User. If the type is 'Detail', or 'Update', this Operation is associated as being 'triggered by' the 'Position On' Application View Event. This Operation Usage is appended to the end of any existing sequence of Event Triggers for the Application View Event. It matches the Operation Usage to the Application View Definition. This is handled differently depending on whether the Application View Definition is based on a Business Object Type. For an Application View Definition with associated Business Object Type, the matching heuristics are, for each non-Repeating Attribute View of the Operation Usage: For an Application View Definition without associated Business Object Type, the matching heuristics are substantially the same as for an Application View Definition with associated Business Object Type, with the exception of heuristic 2, which is replaced by: Step 4—Resolve Required Import Attribute Views. The user interface for Step 4 is illustrated in FIG. 27. The primary purpose of this Step is to allow the user to resolve the source of required import Attribute Views of Operation Usages for which the DA Mechanism has not yet resolved a match. For each required import Attribute View, the user may choose whether the system should create a new Application View Definition (with appropriate current Application View Field Definition) and match the Attribution Field to that Application View Field Definition, use an existing Application View Definition (with appropriate an Application View Field Definition) and match the Attribution View to that Application View Field Definition, and/or ignore the need for a match for the Attribute View. The DA Mechanism provides support for these tasks by the following functionality:
On completion of user input to Step 4, the DA Mechanism carries out selected resolution for each required Attribute View. If the user has marked an Attribute View to be ignored, no changes are made. If more than one Application View Field Definition exists and the user has not elected a preference, then the system uses the first one in the list. Step 5—the user interface to Step 5 is illustrated in FIG. 28. The primary purpose of this Step is:
The DA Mechanism provides the following functionality to help this task by: The DA mechanism examines (by default) the MON to look for an Repeating Group View whose Attribute Views are unmatched to an Application View Field Definition. The following Rules are used to suggest a use for each Repeating Group View:
On completion of user input to Step 5, the DA Mechanism carries out selective resolution for each Repeating Group View. When the suggestion is other than "ignored", the system will process each Repeating Group View as follows:
Step 6—Editing Application View Field Definitions. The user interface to Step 6 is illustrated in FIG. 29. The primary purpose of this Step is to allow the user to edit various aspects of the Application View Field Definitions of the current Application View Definition. The user may:
The DA Mechanism ensures that:
On completion of user input to Step 6, the DA Mechanism ensures that the Application Design reflects the selected edit changes. Step 7—Completion. The user interface to Step 7 is illustrated in FIG. 30. The primary purpose of this Step is to allow the user to select other unfinished Application View Definitions (those created by Step 4 or 5 to be taken through the DA Mechanism process). If no other Application View Definitions were created, the system merely allows the user to exit the system. If no other Application View Definition was selected, the DA Mechanism terminates its current session and returns the associated IA Object Server to the calling program. If an Application View Definition is selected, the DA Mechanism is invoked again, this time in the "Edit" mode. The DA Mechanism can be invoked to augment the Operations of an existing Application View Definition, from itself in a recursive fashion, or by calling programs. In the edit mode, the DA Mechanism uses a set of heuristics to assess the state of the Application View Definition and to choose an appropriate Starting Step. Apart from the evaluation of the Starting Step, the DA Mechanism proceeds as per the process outlined above. The heuristics used to determine a Starting Step are as follows:
There has therefore been described the generation of the Application View Definitions using the Application Design Tool and DA Mechanism, both of which use the underlying services of the IA Object Server. The operation of the Application (Runtime) engine, which corresponds to the Runtime Data Management Object 96 of FIG. 19 and automatically creates and manages Application View instances from their respective Application View Definitions will now be described. FIG. 31 is a flow diagram illustrating the initialisation of the Application Engine. The aim of this process is to create the Runtime Data Management Objects for the corresponding Application View Definitions in a specific Application Design. After initiation (Step 100), in Step 101, the Application Design object is made available to the Application Engine. In Step 102, a test is made whether the Application Design contains at least one Application View Definition. If not, the process terminates (Step 103). Otherwise, in Step 104, an instance of the Application View Definition object is created in Runtime data storage and the properties of the Application View are set to reflect that of the Application View Definition. In step 105, for each Application View Field Definition which details the Application View Definition, an instance of the Application View Field Definition object is created in Runtime Data storage and the properties of the Application View Field are set to reflect that of the Application View Field Definition. In step 106, with reference to the Applicat | ||||||