Patent Application
20070282875
The above needs are at least partially met through provision of the schema specified computable specification method and apparatus described in the following detailed description, particularly when studied in conjunction with the drawings, wherein:
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.
Generally speaking, pursuant to these various embodiments, one provides a schema that specifies, at least in part, constraints with respect to structure and content to be imposed with respect to corresponding schema-based documents. This schema is then used to specify a computable specification for a command line interface to be used with a particular corresponding component. By one approach this computable specification comprises at least one facility specification. This facility specification in turn comprises, at least in part, at least one of an operating parameter (or parameters) as pertain to the particular corresponding component and/or a method (or methods) that are capable of being effected via the particular corresponding component. This computable specification is then used to derive at least one of a corresponding command line interface implementation for the particular corresponding component and/or a graphical user interface for a corresponding management application.
By one approach this schema comprises an extensible markup language (XML) schema. If desired, one may also employ the computable specification to also derive a requirements statement for the corresponding command line interface implementation, test cases for the corresponding command line interface implementation, user documentation for the corresponding command line interface implementation, and so forth.
So configured, the resultant command line interface can comprise a data driven structure. This, in turn, permits the behavior of the command line interface to be readily altered by simply altering the computable specification. This becomes particularly convenient and controlled when the schema itself yields an XML-based command line interface. This results in a command line interface design process that is considerably faster and less prone to error than prior activities in this regard. In particular, many of the existing problems with inconsistencies between the resultant implementation, the user documentation, and the test cases can be dramatically reduced. This in turn results in reduced cycle time, improved accuracy, and an improved user experience as well.
These and other benefits may become clearer upon making a thorough review and study of the following detailed description. Referring now to the drawings, and in particular to
This process 100 then provides for use 102 of that schema to specify a computable specification for a command line interface to be used with a particular corresponding component (comprising physical or logical devices such as, but not limited to, any of a wide variety of telecommunications and networking platforms such as packet data serving nodes (PDSNs) and the like). By one approach this computable specification comprises, at least in part, at least one facility specification (and perhaps more typically a plurality of facility specifications) (where “facilities” are understood in the art to comprise a logical functional entity within a component and are often comprised of corresponding settings (such as items that can be configured by an operator such as timers, thresholds, and Boolean values), statistics (such as items that are typically read-only items that measure certain operators/operations within or performance of the corresponding facility), and alarms (as correspond, for example, to various specified alarm states for certain aspects of a facility).
By one approach this facility specification can further comprise, at least in part, at least one illustrative sequence of command line interface commands that will serve to effect an identified corresponding result. In addition, or in lieu thereof, in some cases it may be helpful if such a facility specification comprises, at least in part, at least one user-discernable information-conveying object such as, but not limited to, a text string, a graphic object, and so forth.
It may also be helpful, at least in some application settings, for the facility specification to further comprise identification of at least one otherwise-available schema-based feature that is to be excluded from a particular facility specification. This can be important when the provided schema offers a relatively rich field of candidate capabilities and opportunities and where it may be important to restrict a particular computable specification from containing an inappropriate reference to or reliance upon a particular capability or opportunity.
Such facility specifications may comprise, at least in part, at least one of an operating parameter(s) and/or a method(s). Such an operating parameter will typically pertain, for example, to the particular corresponding component while the method will typically be one that is capable of being effected via the particular corresponding component.
With momentary reference to
Referring again to
In addition, if desired, this process will also optionally provide for using 104 the computable specification to derive additional related elements. For example, one may use the computable specification to derive a requirements statement for the corresponding command line interface implementation for the particular corresponding component. A requirements statement such as this, in turn, can be highly useful when facilitating subsequent changes to the command line interface as this derived requirements statement can serve as a highly accurate and readily available starting point for effecting the anticipated change.
As another example, the computable specification can be used to derive test cases for the corresponding command line interface implementation for the particular corresponding component. More particularly, this can comprise deriving test cases by using the computable specification to automatically derive such things as a test script and/or a test program for the corresponding command line interface implementation.
As yet another example, the computable specification can be used to derive user documentation for the corresponding command line interface. Such user documentation can comprise any of a wide variety of documentation examples including but not limited to online help-based documentation, hypertext markup language (HTML)-based web pages that comprise user documentation, and so forth.
Making momentary reference again to
Those skilled in the art will appreciate that the above-described processes are readily enabled using any of a wide variety of available and/or readily configured platforms, including partially or wholly programmable platforms as are known in the art or dedicated purpose platforms as may be desired for some applications. Referring now to
This illustrative platform 300 comprises a memory 301 and a processor circuit 302. The memory 301 has the aforementioned computable specification stored therein. The processor circuit 302, in turn, is operably coupled to the memory 301 and is configured and arranged to use the computable specification as taught herein to thereby provide computable specification-based derived output. For example, this processor circuit 302 can use the stored computable specification to derive a corresponding command line interface implementation for a given corresponding component and/or a graphical user interface as desired. Such a processor circuit 302 may also be configured and arranged to derive the other elements as were described above if desired.
Those skilled in the art will recognize and understand that such an apparatus 300 may be comprised of a plurality of physically distinct elements as is suggested by the illustration shown in
A more specific embodiment will now be presented for the sake of illustration. Those skilled in the art will recognize that the details of this example are for illustrative purposes only and are not to be taken as an exhaustive representation of all possible embodiments.
In this example the schema comprises an XML schema. Those skilled in the art will understand that this XML schema is flexible enough to cover multiple logically independent components of, for example, a same device or device family. This schema will be shown to permit an XML designation of a command line interface definition; more particularly, such an XML file can comprise the basis of a formal specification, an implementation, one or more test cases, and user documentation.
Generally speaking, there are two major types of XML files. Facility Specification files specify the facility details per the product's requirements and Command and Dictionary files that provide the System Manager (SM) information about the command structure and other details necessary to execute the various commands (as used herein, “System Manager” will be understood to refer to the main component (such as a host blade or other suitable processing platform) that hosts the command line interface for a given system). The Facility Specifications may comprise a single source for all detailed information regarding the component facilities, their parameters, and custom commands. These may be engineered by, for example, a research and development team and will serve as a source for many different elements including but not limited to automatic generation of the command line interface documentation, simulating the command line interface commands for use in usability studies, and automatically generating System Manager Command and Dictionary XML files.
If desired, the System Manager XML files can be automatically generated from the Facility Specifications using a code generator tool of choice and no direct editing of the Command and Dictionary files is necessary. Those skilled in the art will understand and recognize that corresponding code can also be prepared by hand if desired, though this may result in a loss of efficiency and/or accuracy with respect to the overall process or resultant deliverable.
In this embodiment the XML file essentially comprises a non-ambiguous specification. The following concepts are assumed in this example for the command line interface under discussion:
A facility may contain a set of parameters that are used to provision the facility's operational characteristics or that represent other useful operational information. It is also anticipated that a facility may not have any parameters at all. It is also possible that some facilities may represent information that is tabular in nature. For example an Internet Protocol Address Pool facility may manage more than one Internet Protocol Address Pool. A tabular facility can specify key parameter(s) that uniquely identify a specific item in the facility. For example, an Internet Protocol Address Pool facility can use the name parameter as a key. In this embodiment all commands related to a specific item in a tabular facility will require the key parameter(s) name and value to be entered.
Parameters may be organized into well-known groups such as statistics, settings, or alarms to thereby provide a convenient mechanism for the operator to view, display, or otherwise consider all the parameters within a specific group. In this embodiment, the majority of the command line interface commands are related to showing or setting the parameters of a facility. A facility may also contain a set of unique commands (such as the aforementioned methods) or verbs that are useful only for that specific facility. For example some facilities may have a command to reset their statistical counters.
Although the XML-based Facility Specification is a formal specification regarding facilities and their parameters, keys, and custom methods, this specification need not directly specify the actual syntax of the commands used in the command line interface. In this embodiment, all command line interface commands follow this common syntax:
The actual commands are derived by the information in the facility specification.
At the highest level each facility XML specification file in this embodiment identifies one or more facilities each using an id attribute to specify a unique identifier for the specific facility. This is illustrated in Table 1 shown below.
The opening <facility . . . > tag may contain other attributes as described below. Any general text between the opening and closing <facility . . . > tags is considered the facility description that is used for documentation and manual-page style help commands. Within a facility, parameters, methods, samples, and usage messages may be specified.
The attributes set forth in Table 2 shown below are specified within the opening <facility . . . > tag.
Parameters in this embodiment, in turn, are specified within the opening and closing <facility> tags as illustrated by the contents of Table 3 shown below.
In this embodiment the attributes set forth in Table 4, presented below, are specified within the opening <parameter . . . > tag:
If desired, parameters may be grouped by enclosing the appropriate <parameter . . . > specifications within <group> tags as suggested by the contents of Table 5 presented below:
By one approach, individual parameters are precluded from inclusion in multiple groups.
With some facilities having multiple entries it may be desirable to show multiple entries in a tabular fashion. If desired, all parameters that specify the summary=“width[alignment]” attribute could be automatically included in a special parameter group with a group-id of ‘summary’. The command line interface process could then display this special group in a tabular manner. An illustrative example appears in Table 6 presented below:
When a facility is tabular in nature it may also be possible and/or useful to enclose parameters within <keys> tags that identifies the key parameters. An illustrative example appears below in Table 7.
Methods as described above may be specified within the opening and closing <facility> tags as per Table 8 shown below.
To exemplify in detail, Table 9 sets forth illustrative attributes that may be specified in this embodiment within the opening <method . . . > tag.
As noted above, it may be desirable to specifically exclude certain otherwise available content when practicing these teachings. Excluded entries can be used to formally acknowledge objects that are to be excluded from a resultant command line interface (though the exclusion entry will preferably have no affect on the command line interface itself). That is, these entries can primarily serve to track the decisions being made with respect to such object exclusion. In this illustrative embodiment certain Mobile Internet Protocol objects are to be excluded and are specified within the opening and closing <facility> tags as suggested by the content of Table 10 shown below.
It may also be helpful to the reader's understanding to also describe the design of System Manager command and dictionary XML files. In this illustrative embodiment there is a single XML formatted file for each context (such as, for example, system.xml, pdsn.xml, and routing-instance.xml). These files can be automatically generated using an automated code generation tool of choice and/or by hand as may be appropriate in a given application setting. Table 11, shown below, demonstrates that, at a highest level, the content XML file identifies the context and contains two major segments as well (in this case, command and dictionary).
In this embodiment the command section defines all the valid commands for the context in tree form. The dictionary section, in turn, contains detailed information about each facility along with its parameters and methods. The command tree section can define all valid command line interface commands by modeling the segments of the valid commands in tree form. This would allow, of course, efficient command parsing and command completion capabilities.
Table 12 shown below represents such a construct, where the first level (i.e., <command> in the depicted example) operates as a verb and where each XML tag represents the keyword that is required to be entered to invoke that specific command. (The specific example provided in Table 12 illustrates two commands: activating a system alarm cutoff and adding a bios filename.)
As already noted above, the dictionary section contains detailed information about each facility along with its parameters and methods. To illustrate, Table 13 presents an example where all tags immediately below <dictionary> represent each facility in the context.
As noted earlier, each facility may have one or more parameter and/or method specifications. Table 14 presents an illustrative example in this regard (the parameters will be in the order as found in the original source facility XML specification and the tag for each parameter is formed using “parameter:parameter-id” while the tag for each method is formed using “method:method-id.”)
Although the XML facility specification is a formal specification regarding facilities, their parameters, keys, and custom methods, they do not directly specify the actual syntax of the command line interface commands. Instead, this XML content is interpreted to facilitate derivation of those actual commands. The general design of all command line interface commands may be as follows:
where the meanings of these expressions are set forth in Table 15 below:
In many cases it may be preferable to use “grouping” at a facility level to identify the settings and/or statistics rather than specifying a settings or statistics sub-facility. This allows, for example, a higher-level facility “show facility-id statistics” command to show the statistics for the facility and all sub-facilities.
In any event, Table 16 presents various rules that may be employed to determine the commands to be associated with a given facility.
Those skilled in the art will recognize that the specifics provided above are illustrative in nature and that a given designer may well chose different implementation details to suit the needs and/or limitations of a given application setting. Consequently, the specific values, definitions, field names, abbreviations, and so forth presented above are to be viewed as a non-exhaustive listing and without any intent to otherwise limit the ambit of these teachings.
Those skilled in the art will recognize that a wide variety of modifications, alterations, and combinations can be made with respect to the above described embodiments without departing from the spirit and scope of the invention, and that such modifications, alterations, and combinations are to be viewed as being within the ambit of the inventive concept.
