Patent Application
20070011690
1. Field of the Invention
The present invention relates generally to a software interface and more particularly to a generic architecture for a software interface that is applicable to a variety of different software controlled systems.
2. Description of the Related Art
Application Programming Interfaces (APIs) are public interfaces to software products that are being published so that external clients, e.g., application programs, may interact with the software product. There are a lot of challenges when defining APIs because it is highly desirable that they be:
Some of the above requirements conflict with others making it very difficult to satisfy all of them. For example, having a small set of stable APIs is often incompatible with providing enough interfaces to satisfy the client's needs present and future.
The present invention provides a generic architecture for a software interface, e.g., an API, that satisfies all of the above requirements so that it can be applied to any software product. The software interface of the present invention provides an interface to software components of a system that is operable under the control of software. The interface includes a plurality of interface areas related to each other in a hierarchical manner. Each interface area provides an interface to the software components through one or more interface methods.
The interface methods are generically defined methods and include a data handling method, an action method, and a navigation method. The data handling method includes the methods for setting and retrieving a value of a parameter. The action method includes the methods for executing a specific method for carrying out operations on the system through the software components. The navigation method includes methods for navigating to a specific interface area.
A token is associated with each of the interface methods to specifically define the method that is to be carried out. A token for the data handling method specifically identifies the parameter that is to be set or retrieved. A token for the action method specifically identifies the method that is to be executed. A token for the navigation method specifically identifies the destination interface area.
So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
The API 101 and the software module 102 are illustrated in further detail in
The data handling method includes the methods for setting and retrieving a value of a parameter. The data handling methods have the following syntax:
data=area.getX(token); and
area.setX(token, data),
where area is an interface area; “token” is a key (e.g., a string) identifying the parameter that is being set or retrieved; “data” is the value of the parameter identified by the token; and “X” is a data type abbreviation, for example S for string, L for long, D for double, Sarray for string list, etc.
The action method includes the methods for retrieving and executing a specific method for carrying out operations on the system through the software components. The action methods have the following syntax:
area.invoke(token)
where area is an interface area; and “token” is a key that identifies the specific method that is to be carried out. The specific method that is to be carried out might require information that was specified using the setx method described above.
The navigation method includes methods for navigating to a specific interface area. The navigation method has the following syntax:
anotherArea=area.getArea(token)
where area is an interface area; “token” is a key that identifies the specific interface area to which navigation is desired; and anotherArea is the destination interface area. In some cases, an interface area may have several area objects, each of which is uniquely identifiable. A method such as, getNamedArea(token, id name), is a convenient shortcut for accessing one such area object. In the same way, when an interface area is a list of area objects, a method such as, next( ), can be used to iterate through the list.
Since the interface areas are organized hierarchically, it is possible to use shortcuts when navigating the interface areas. One possibility is to allow a token to be a combination of individual tokens. If the tokens are strings, for example, a separator (e.g., “.”) can be used to delimit different hierarchy levels. In that case, a token such as “human.body.skeleton.bone” can be used to get to a specific interface area (bone) without stepping through each level of the hierarchy. This approach may be extended to allow any level of the hierarchy to be a named area so that, by executing the method, “human.body.skeleton.cubitus.length,” the length of the “cubitus” bone can be obtained without navigating through the areas.
Each of the interface areas 210, 220, 221, 230 of the simplified API 102 has a name associated with it and a set of interface methods that are available to be used at the respective interface area. Table 1 provides the names of the interface areas, the interface methods that are available to each, and the tokens associated with each of the interface methods.
At the interface area 210, one interface method, getArea, is available. Using this method, navigation to either the ExecuteEngine interface area 220 or the TestProgram interface area 230 is possible. The following script illustrates how this is done:
exec=CAP.getArea(“ExecuteEngine”); or
tp=CAP.getArea(“TestProgram”).
From the interface area 220, another traversal down the hierarchy to the interface area 221 is possible using the command:
execsub=exec.getArea(“ExecuteRegion”).
It is also possible to directly navigate to the interface area 220 using the command:
execsub=CAP.getArea(“ExecuteEngine.ExecuteRegion”).
At the interface area 220, several data handling methods and the invoke method are available. The getL and setL methods are used to retrieve and set the test execution time out value in the parameter “TimeOut.” The getS and setS methods are used to retrieve and set the name of a synchronization trigger in the parameter “SyncName.” The invoke method is used in conjunction with either the “GenerateSync” token or the “WaitForSync” token. The invoke method used with the “GenerateSync” token generates the synchronization trigger identified in the parameter “SyncName.” The invoke method used with the “WaitForSync” token waits for the synchronization trigger identified in the parameter “SyncName” until a time out period specified in the parameter “TimeOut” is reached. The following script illustrates the usage of these methods:
exec=CAP.getArea(“ExecuteEngine”);
exec.setS(“SyncName”, “MyGenerateSync”);
exec.invoke(“GenerateSync”);
exec.setS(“SyncName”, “MyWaitForSync”);
exec.setL(“TimeOut”, maxTimeout);
exec.invoke(“WaitForSync”);
At the interface area 230, several data handling methods and the invoke method are available. The getS and setS methods are used to retrieve and set the name of a file in the parameter “FileName.” The invoke method is used in conjunction with either the “Load” token or the “Unload” token. The invoke method used with the “Load” token loads the file identified in the parameter “FileName” into memory. The invoke method used with the “Unload” token unloads the file identified in the parameter “FileName” from the memory. The following script illustrates the usage of these methods:
exec=CAP.getArea(“TestProgram”);
exec.setS(“FileName”, “MyTestFile”);
exec.invoke(“Load”);
exec.invoke(“Unload”);
In order to perform some operations, a client (e.g., an application program) may have to make several successive calls to an area object. This has an impact on the area servant (i.e., the server resources assigned to the area object) because in a multi-threaded environment, the same servant could be called from different threads associated with different clients that would be passing different data. To address this need, a new servant object is created each time a getArea( ) or getNamedArea( ) is received. This allows servants to behave independently for different clients. The servants can collect data passed by the client, then perform an action generating new pieces of information and store them so that the client can retrieve them later on.
One side effect of this approach is that lots of servants will be created and at some point they must be disposed of. The hierarchical arrangement of the areas provides for a simple solution. Since an area servant is always obtained from another area servant and since area servants are client independent, it is very easy to establish a parent/child relationship between the area servants. A parent area servant would keep track of the child area servants that it has created through getArea( ) or getNamedArea( ) calls and a child area servant would remember the parent area servant that created it. This way a servant area when being destroyed can first destroy all of its child area servants and then tell its parent servant to disregard it.
On the client side, the above arrangement allows the client to define scopes in which it is getting and using area objects. The client enters the scope using an area object that is the entry point of the hierarchy of area objects. When the client is exiting the scope and does not need to keep the area objects any longer, it can simply tell the server to destroy (e.g., by using invoke (“Delete”)) the top parent area object that was used as the entry point and all the servants that were created during the scope execution would also be destroyed. If a client wants to use this scope destruction mechanism but also be able to hold onto a specific area object that has been created within the scope, a getArea(token) call can be used with a special token (e.g., “Clone”) that would bypass the default parent-child mechanism. The client is then responsible to ensure that the servant gets disposed of when appropriate.
The architecture described herein is conceptually very simple but its usability is directly dependent on how good and clear the software system's model and rules are. Indeed, the area hierarchy is a representation of the software system's model and the tokens and the order in which successive calls must be made to perform an operation are clearly related to the software system's rules. The challenge is not in the definition and maintenance of the interfaces anymore, but in the definition of the software system's model and rules and their representation using meaningful area and token names.
A significant advantage of this architecture is that new token and area names can be added using standard plug-in mechanism without impacting the interface itself. Since an area is always obtained from another one, it is possible to add a new area to the product using a registration mechanism, for example. As a result, the software system's model and rules can evolve and include new features without impacting the interface itself and with minimum impact on existing client's implementation.
A conventional software interface employs multiple software objects and each object has attributes and methods associated with only that particular object. To use each object, the application programmer needs to know the attributes and methods associated with that object, as well as the correct syntax for using that object. In situations where the software interface is relatively large and complex, this places an undesirable burden upon the application programmer to have knowledge of a large number of object methods and their syntax.
By contrast, in the software interface according to the present invention, the interface methods are not individually associated with the objects that make up the software interface areas. Instead, each interface method is capable of being used with different interface areas (i.e., area objects). Furthermore, each interface method is generic and is capable of being used with different software systems. Therefore, with the software interface according to the present invention, the knowledge burden placed upon the application programmer is greatly reduced.
Another example of a possible hierarchy of interface areas in the context of the electronic device test system is shown in Table 2. The area hierarchy is organized to relate the structure and functionality of the system components and software components of the test system. In the example, the root area is named electronicDeviceTester and has several areas below it in the hierarchy: testExecute, testProgram, and resultManager. The root area is the initial access point to the other interface areas. The areas below the root area divide the functionality of the software interface into logical groupings based on the architecture of the software module and the test system. The testExecute area provides access to software components that control the execution of tests on the test system. The testProgram area provides access to the details of the test being run by the test system. The resultManager area provides access to the results and to manipulation of the results of the test.
The root area, electronicDeviceTester, comprises three tokens for use with the interface method, getArea( ). The three tokens identify the areas that are below the root area: testExecute, testProgram, and resultManager.
The testExecute area comprises tokens for use with the getX/setX method, such as testTime and testName, and tokens for use with the invoke( ) method, such as startTest, and waitTest. The token testTime represents the time to start, or the duration of, a particular test. The token testName represents the identity of the test to be run. The invoke(“startTest”) method executes a sequence of program instructions that starts the execution of the test identified by the token testName. The invoke(“waitTest”) method suspends the test identified by the token testName.
The testProgram area comprises the testActionName token and the testActionTime token for use with the getX/setX method. The testActionName token identifies a particular action to be taken during a test, and testActionTime token identifies the duration of the test.
The resultManager area comprises the resultName token for use with the getX/setX method and the resultDisplay token for use with the invoke( ) method. The resultName token identifies a particular test result, and the invoke(“resultDisplay”) method executes a sequence of program instructions to display the particular test result stored in resultName on an output monitor.
The software interface according to the present invention is described above in the context of a test system. It is to be understood that the software interface according to the present invention may be used in a software-controlled system of any type.
While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.
