Patent Application
20070022126
The present disclosure relates generally to a method and apparatus for updating a catalog, and more particularly, to a method and apparatus for updating an asset catalog.
Computer applications, such as computer readable codes and/or data manipulation programs, can be designed and/or operated within a design environment that typically includes a computer and a graphically interfaced system design tool. System design tools typically include a software program that allows a user to design an application or manipulate data using an interrelated function-based approach within a graphical environment. Such system design tools usually include programmed structural relationships to organize underlying data stored in databases with interface objects displayed within a graphical user interface. Typically, such structural relationships include information to organize the interface objects within a taxonomy. As new data is introduced into the design environment, the programmed structural relationships within the system design tool must also be updated to avoid the underlying data from becoming asynchronous and/or to ensure the system design tool operates properly with the new data.
A method of updating underlying data within a system design tool is disclosed in U.S. Pat. No. 6,330,006 (“the '006 patent) issued to Goodisman. The '006 patent describes a method and apparatus for synchronizing interface objects of a graphic user interface with underlying data. The method and apparatus includes a system design tool aware of the structure of some of the underlying data and configured to determine the structure of underlying data with which it is not aware. Specifically, the design tool of the '006 patent enables a user to bind structural properties with previously unknown underlying data within the design tool to synchronize the information displayed in a graphic user interface and the information contained within a data source. The design tool is further configured to allow the user to manipulate the interface objects within the graphical user interface in accordance with the underlying application of the design environment.
Although the system design tool above may allow new data to be added to the system design tool, each introduction of new data requires a corresponding update to the design tool and potentially a significant degree of user expertise. Specifically, as new data is introduced into the design environment for which the system design tool is unaware of a corresponding underlying structural relationship, a user must bind the new data and a corresponding interface object within the system design tool. Because the structural relationship of the underlying data is retained in the design tool, a change in data requires the system design tool to be updated; either by binding by a user or within the system design tool program code by, for example, an update. Additionally, a user may need to be trained on how to bind data and interface objects and/or may need to be aware of the underlying data and how it should relate to the interface objects. New objects may be added frequently and, as such, changes in structural relationships may also frequently change. Frequent updates of the system design tool can be cumbersome, time consuming, and/or require special knowledge of the user.
The disclosed method and apparatus for updating an asset catalog is directed to overcoming one or more of the problems set forth above.
In one aspect, the present disclosure is directed to a method for updating a product catalog. The method includes receiving a plurality of first assets into the catalog, each first asset having at least one hierarchy tag. The method further includes adding at least a second asset having a hierarchy tag into the catalog. The method still further includes organizing the plurality of first assets and the at least second asset in a hierarchy. The catalog is accessible by a design tool.
In another aspect, the present disclosure is directed to a method for updating an asset repository. The method includes organizing a plurality of first assets within an asset catalog in accordance with reusable asset specifications in a hierarchy. The method further includes adding a plurality of first assets to the repository from the catalog. The method still further includes organizing the plurality of first assets in the repository in accordance with reusable asset specifications at least partially based on the hierarchy within the catalog.
In a further aspect, the present disclosure is directed to a design environment including a system design tool, an asset catalog having a plurality of first assets wherein the plurality of first assets are organized in accordance with reusable asset specifications in a first hierarchy, and at least one asset repository having a plurality of second assets. The plurality of second assets is a subset of the plurality of first assets. The plurality of second assets is organized in a second hierarchy. The system design tool is configured to functionally relate at least two assets of the plurality of second assets.
Computer 12 may include a general purpose computer configured to operate executable computer code. Computer 12 may include one or more input devices, such as, for example, a keyboard (not shown) or a mouse (not shown) to introduce user inputs into computer 12; one or more data manipulation devices, such as, for example, databases (not shown) or software programs (not shown) to transfer and/or alter user inputs; and one or more communication devices, such as, for example, a modem (not shown) or a network link (not shown) to communicate inputs and/or outputs with system design tool 14. It is contemplated that computer 12 may further include additional and/or different components, such as, for example, a memory (not shown), a communications hub (not shown), a data storage (not shown), a printer (not shown), an audio-video device (not shown), removable data storage devices (not shown), or other components known in the art. It is also contemplated that computer 12 may communicate with system design tool 14 via, for example, a local area network (“LAN”), a hardwired connection, and/or the Internet. It is further contemplated that computer 12 may include a plurality of computers each configured to communicate with system design tool 14.
System design tool 14 may be configured to communicate with computer 12, asset catalog 16, and asset repository 18 to functionally transfer and/or interconnect assets within a graphical user interface (“GUI”) (not shown). Specifically, system design tool 14 may be configured to add a second plurality of assets 22 to asset repository 18 from a first plurality of assets 20 in asset catalog 16 and to select a subset of assets 24 from asset repository 18 and functionally interconnect subset of assets 24. System design tool 14 may further be configured to generate software code at least partially based on the functionally interconnected subset of assets 24 and output the software code to computer 12. It is contemplated that system design tool 14 may be configured as a click and drag interface, where user inputs select icons within the GUI and selectively move the icons to interconnect assets; a read-write interface, where user inputs write commands within the GUI to interconnect assets; a drop down table interface, where user inputs select assets from organized tables within the GUI to functionally interconnect assets; or other graphical interfaces known in the art. It is contemplated that the generated software code may be a computer readable code and may be written in a known software format, such as, for example, a software flash file. It is also contemplated that the illustration of system design tool 14 interconnecting subset of assets 24 is for clarification purposes only and system design tool 14 may, within system limits, functionally interconnect any number of assets. It is further contemplated that system design tool 14 may be stored within the memory of computer 12 and/or within the memory of each of a plurality of computers 12 and may be configured to communicate with asset catalog 16 and asset repository 18 over the Internet.
Asset catalog 16 may include first plurality of assets 20 and may be configured to store and/or link to the location of first plurality of assets 20 and interact with system design tool 14. Asset catalog 16 may embody a database or other data manipulation table known in the art. Asset catalog 16 may store and/or organize first plurality of assets 20 in a hierarchy in accordance with reusable asset specifications (“RAS”). It is contemplated that first plurality of assets 20 stored and/or linked within asset catalog 16 may include, within practical limits, any number of assets. It is also contemplated that asset catalog 16 may directly be accessible by computer 12 via the Internet, such as, for example, without computer 12 communicating with system design tool 14.
Asset repository 18 may include second plurality of assets 22 and may be configured to store and/or link to the location of second plurality of assets 22 and interact with system design tool 14. Asset repository 18 may embody a database or other data manipulation table known in the art. Second plurality of assets 22 may, for example, form a subset of first plurality of assets 20, may embody assets designed by user 100, and/or may include assets from any known asset collection having one or more assets therein. Asset repository 18 may store and/or organize second plurality of assets 22 in a hierarchy in accordance with RAS. It is contemplated that second plurality of assets 22 stored and/or linked within asset repository 18 may include, within practical limits, any number of assets. It is also contemplated that asset repository 18 may include a plurality of asset repositories 18′ each configured to store a plurality of assets. It is also contemplated that asset repository 18 may be stored within the memory of computer 12, within a memory of a computer server (not shown), and/or may be accessible by system design tool 14 via the Internet. It is further contemplated that asset repository 18 may embody a single asset repository and may be configured to be accessible by a plurality of computers 12 and/or a plurality of system design tools 14.
Asset 200 may specify required artifacts 202 and declare specific use contexts for asset 200. Assets, in general, may be described using at least three dimensions: granularity, variability, and articulation. Granularity may describe how many particular problems and/or solutions a particular asset addresses. For example, simple assets may offer a single solution or address a single well-defined problem. As granularity increases, an asset may address multiple problems. Variability may describe the degree to which a user may alter the asset. For example, invariable assets may be fixed and unalterable. As variability increases, a user may be able to edit and alter an asset to meet specific user demands. Articulation may describe the degree of completeness of the artifacts 202 in providing a solution. For example, non-complex artifacts 202 may specify a solution, but may not provide the solution. As articulation increases, an artifact 202 may specify and implement a solution in connection with other supporting workproducts.
Asset 200 may include a software component. Asset 200 may be configured as a sub-routine to provide a software solution to a software problem. Specifically, asset 200 may include artifacts 202 configured to perform a sub-routine of a computer executable routine. Asset 200 may be configured to be interconnected with other software and/or hardware assets and may be configured to accept inputs, perform an algorithm, and deliver outputs. For example, asset 200 may accept inputs from another software and/or hardware asset, perform an algorithm with the accepted inputs to manipulate, change, and/or modify the accepted inputs, and deliver outputs to yet another software and/or a hardware asset. Artifacts 202 may include a description of the problem the sub-routine solves, the sub-routine, the required inputs, the delivered outputs, and/or other workproducts.
Asset 200 may further include a hierarchy tag 206 configured as one of artifacts 202. Hierarchy tags 206 may include a ranking indicator configured to designate the associated asset 200 within a hierarchy relative to other assets. For example, hierarchy tag 206 may indicate asset 200 as a simple asset, e.g., an asset having a low granularity, and accordingly may be configured to provide a ranking indicator to organize asset 200 below other assets having higher granularity. Similarly, hierarchy tag 206 may additionally and/or alternatively indicate the asset 200 with a particular solution and/or particular problem. Accordingly, hierarchy tag 206 may be configured to provide a ranking indicator to organize asset 200 relative to other assets according to types of solutions and/or problems. For example, an asset may provide a solution to control a particular hardware component and may be organized with assets providing similar solutions and may not be organized with assets providing dissimilar solutions. It is contemplated that hierarchy tag 206 may include any ranking indicator to organize asset 200 relative to other assets. It is also contemplated that asset 200 may include a plurality of hierarchy tags.
Manifest file 204 may reference artifacts 202 and may be configured as an eXtensible Markup Language (“XML”) document. Manifest file 204 may be configured to associate artifacts 202 with one another and/or asset 200 with other assets. It is contemplated that asset 200, including one or all of artifacts 202 and/or manifest file 204, may be packaged into a single archive file, such as, for example, using a Zip compression algorithm. Such a packaging may make distribution of asset 200 easier because of decreased file size and/or pre-management of the complexity of the asset.
The disclosed method and apparatus for updating asset catalog 16 may be applicable to any design environment. The disclosed method and apparatus may provide less cumbersome and less time consuming updating of products within an asset catalog and may enable more frequent updates thereof. The operation of design environment 10 and, more particularly, system design tool 14 is explained below.
Design environment 10 may be configured to generate a software code to control a hardware component 102. The generated software code may include an embedded code that is transferred from computer 12 to hardware component 102 and may be configured to operate, monitor, and/or manipulate hardware component 102. For example, the generated software code may embody a sub-routine to monitor outputs from a temperature sensor and output a true-false value to a light emitting diode (“LED”) indicator. It is contemplated that the generated software may include a code necessary to operate hardware components, such as, for example, sensor monitoring, hydraulic valve control, engine control, work implement control, and/or any other hardware control. It is also contemplated that the generated software code may include a code to operate, control, and/or interact with other software codes. It is further contemplated that the generated software code may be transferred to hardware component 102, via flash transfer protocol as is known in the art, directly from computer 12 and/or indirectly from computer 12 via secondary computer devices, such as, for example, other computers, computer servers, and/or other known computer devices.
The following operation of system design tool 14 is illustrated with reference to the addition of new assets to asset catalog 16 and the updating of asset catalog 16 and the corresponding updating of asset repository 18. It is noted that the explanation below is for clarification purposes only, and the method and apparatus may be applicable for any change in assets within an asset catalog.
First plurality of assets 20 may be uploaded into asset catalog 16 in a manner known in the art, such as, for example, data entry. First plurality of assets 20 may be uploaded by a system administrator upon initialization of asset catalog 16 and/or periodically. First plurality of assets 20 may be organized within asset catalog 16 based upon their respective hierarchy tags and may be configured into a hierarchy tree. As new assets having a hierarchy tag are subsequently added into asset catalog 16, the hierarchy tree therein may be automatically updated via an organizing algorithm and/or by an administrator during uploading. It is contemplated that first plurality of assets 20 may be organized in a hierarchy in a manner known in the art, such as, for example, database ranking.
System design tool 14 may access first plurality of assets 20 in response to user inputs communicated from computer 12. Specifically, a user may browse through first plurality of assets 20 and functionally select desired assets therefrom to be moved into asset repository 18. For example, user 100 may be interested in some of first plurality of assets 20 and may, via system design tool 14 and, in particular, the GUI, functionally select that some of first plurality of assets 20 be transferred into asset repository 18 and/or functionally indicate that some of first plurality of assets 20 may in the future be transferred into asset repository 18. As a result, user 100 may functionally establish second plurality of assets 22 within asset repository 18.
System design tool 14 may access assets 20 in asset catalog 16 and/or assets 22 in asset repository 18 in response to user inputs communicated from computer 12 to establish subset of assets 24. System design tool 14 may display subset of assets 24 in the GUI, user 100 may select one or more of subset of assets 24, and user 100 may direct system design tool 14 to functionally interconnect the selected assets of subset of assets 24.
For example, user 100 may access system design tool 14 via computer 12 in order to generate a software code to operate a warning LED based on a temperature sensor. User 100 may access, via the GUI of system design tool 14, a list or table of available assets 200 configured to provide solutions to the problem of operating an LED. Specifically, user 100 may browse through second plurality of assets 22 via a hierarchy to select desired assets. For example, user 100 may browse through assets 22 to find and select several assets configured to output a constant true value signal based upon a first received input, monitor a sensor output and convert the output into a communication signal, and/or perform other sub-routines available and or desired from second plurality of assets 22.
Referring to
User 100 may use a similar selection process to select other assets, such as, a temperature sensor asset and/or other assets desired and/or necessary to operate the LED. It is contemplated that system design tool 14 may display within the GUI other necessary and/or potentially desirable assets from within second plurality of assets 22 and/or first plurality of assets 20. For example, if user 100 selects a constant true value output asset, system design tool 14 may be configured to automatically display a plurality of other assets compatible with, necessary for, and/or desirable to be interconnected with a constant true value output asset.
As assets 200 are designed and/or modified, assets 20 in asset catalog 16 may need to be modified, removed, and/or new assets may need to be added. For example, if an intermittent indicator sub-routine has been developed subsequent to the development of a constant indicator sub-routine, a new asset for the intermittent indicator sub-routine may need to be added into asset catalog 16. As a result, the hierarchy of assets 20 may change. Referring to
For another example, if constant indicator assets are discontinued, such assets may need to be removed from asset catalog 16. As a result, the hierarchy of assets 20 may change. Specifically, the hierarchy class labeled “Constant Indicators” may be removed from within the above referenced “Output Devices” hierarchy. Similar to adding a new hierarchy class (discussed above), the new hierarchy may be organized within asset catalog 16 automatically and/or by an administrator when the discontinued constant indicator assets are removed from the plurality of assets 20 within asset catalog 16. As a result, user 100 may be unable to open the hierarchy class labeled “Constant Indicators” and select an asset therein even though the system design tool 14 itself has not been updated. It is contemplated that discontinued assets removed from asset catalog 16 may remain within asset repository 18 if such an asset was transferred to asset repository 18 prior to the asset being discontinued.
Similarly, because asset 200 may include hierarchy tag 206, if asset 200 is transferred into asset repository 18, a hierarchy therein will automatically be organized at least partially based on hierarchy tag 206 and the hierarchy tag of the other assets within asset repository 18. Specifically, the hierarchy within asset repository 18 operates and functions similar to asset catalog 16 as described above.
Because assets are organized in a hierarchy in asset catalog 16, as new assets are developed and previous assets are discontinued and/or modified, system design tool 14 may display the new hierarchy in the GUI to user 100 without the system design tool 14 being updated and/or reprogrammed. As a result, updating assets for use within a system design tool may be simpler, less time consuming, and/or be performed more frequently.
It will be apparent to those skilled in the art that various modifications and variations can be made to the disclosed method and apparatus of updating an asset catalog. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed method and apparatus of updating an asset catalog. It is intended that the specification and examples be considered as exemplary only, with a true scope being indicated by the following claims and their equivalents.
