HK1149348B - Method, device and system for assembling a software package - Google Patents

Description

Method, device and system for assembling software package

The present application is a divisional application of an invention patent application having an application date of 2004, 10/14, application number of 200480032632.0, entitled "system and method for building a software suite".

RELATED APPLICATIONS

This application claims priority from U.S. provisional patent application serial No.60/518,285, filed on 7/11/2003.

Technical Field

The present invention relates generally to personal computers.

Background

Personal computer (e.g., Sony's VAIO)A computer) contains a set of custom software components created for each project's built specification. In other words, some computers must have a first set of software, such as word processing software, audio-visual software, while another group of computers may be designated with a second, different set of software, thereby providing more options to the customer. As used herein, a "software suite" refers to a complete and complete collection of software for a computer, as well as components distributed to, for example, various vendors and test teams, which are assembled together as part of the overall project distribution.

Creating each custom program group requires many steps involving a plurality of programs separated from each other. Heretofore, when assembling the individual programs of a program suite, engineers had to manually locate the desired programs from one or more central databases and copy the programs onto, for example, an optical disk for loading the software onto a computer. These operations are time consuming and require manual intervention in order to build a newly specified program suite from scratch. Further, since "build" is not automatic, errors and inconsistencies inevitably occur in such "build".

It has been observed that it is desirable to provide an automated method of assembling a software suite for a computer group. However, as further recognized herein, an assembler may not have the expertise of a programming language (e.g., C + +). The present invention therefore recognizes the need to provide a method for automatically assembling a software suite without requiring formal programming knowledge.

Disclosure of Invention

A method of assembling a software package for a computer includes presenting an XML structure to a user and allowing the user to use the structure to construct an XML script that defines the contents of the software package. The method also includes parsing the script to submit the C + + software code and executing the C + + software code to automatically assemble the content into a software package.

In a preferred embodiment, the structure is a class in an object-oriented programming environment. The class may be presented to the user in a class window on a computer display for selection by the user. During execution, the user may be prompted to enter information related to, for example, the identification of the software package.

In another aspect, a system for automatically assembling and loading at least two software applications into a software package onto a computer includes an object-oriented method for identifying a hierarchy of applications in a script. The system also includes a method of parsing scripts into executable code. A method for executing code to automatically assemble a software package is provided.

In yet another aspect, a software system includes a model component that contains an object oriented Application Programming Interface (API) that can be used to generate a list of software applications. The controller component communicates with the model component and contains an analysis program that parses the list into code for execution to automatically assemble the application into a software package. The view component communicates with the controller component to present the object classes to the user for use in generating the list.

Drawings

The details of the present invention, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:

FIG. 1 is a block diagram of the present system;

FIG. 2 is a block diagram of a software architecture;

FIG. 3 is a flow chart of a general logic unit of the present invention;

FIG. 4 is a diagram illustrating an XML script hierarchy diagram; and

FIG. 5 is a screen shot illustrating a user display.

Detailed Description

Referring initially to FIG. 1, a system is shown, generally designated 10, which includes a load definition computer 12, the load definition computer 12 having one or more input devices 14 (e.g., a mouse, a keyboard, etc.) and one or more output devices 16 (e.g., a computer monitor, a printer, a network, etc.). The load computer 12 communicates with one or more sources of software applications (e.g., load database 18) to assemble the applications into a suite or package of programs that can be copied, for example, to an optical disk 20 for loading the software applications onto a target computer, such as, for example, SonyVAIOOn the computer's laptop computer 22.

Fig. 2 shows a software architecture executable by the loading computer 12, and fig. 3 shows the main functionality of the architecture in a non-limiting flow chart format. As shown in FIG. 2, the software may include a model component 24, a controller component 26, and a view component 28. The model component 24 contains a system Application Programming Interface (API), which is the best XML object-oriented structure for generating software application listings. Thus, an API is a set of functions that provide a common window command for programming automation. The model component 24 is essentially a tool box and a library of information that contains several functions from document processing and program execution to message display and database 18 access.

More specifically, the model component 24 creates a Dynamic Link Library (DLL) file that is understandable by the Microsoft corporation's ". NET" system in accordance with the disclosure below. The model component 24 is also a repository for all XML object classes that the user may select for the application. Additionally, model component 24 may include a control portion with adapters for generic wrapper functions to enable raw C + + data type structures (e.g., "int" and "char^*") are converted into objects, respectively^*And String^*. It also has a setup class that can be used to record the results of any command execution. This may actually be achieved by C + + functions within the class. Each API command may be a function within a single (single) class or may be implemented as an individual (individual) class.

The controller module 26 contains all the business logic behind the system language structure, which includes variable descriptions and conditional statements, and represents a parser that parses a list of applications received from a user into code for execution to automatically assemble the applications into software packages. To this end, the controller module 26 incorporates minimal coupling between the viewing component 28 and the model component 24 and provides a clear separation between the two. If the code is converted to either of the other two components, the controller module 26 does not need to be recompiled.

The view module 28 is a user interface that allows access to the model component 24 through the controller component 26 to present object classes to a user for use in generating a list or script that defines applications to be assembled into a software package. There may be two views, one for program execution only and debugging that may be run on the command line, and the other for a user interface for creating, editing, and executing system scripts. Both may receive input from an XML script or otherwise through API selection within the interface.

Fig. 3 shows the overall logic of the embedded system 10. Beginning at block 30, the desired functionality in, for example, an XML-based object class is placed in the model component 24. At block 32, the view component 28 is invoked to present the user with a class of functionality, which will be discussed further below, on the monitor 16 shown in FIG. 1. At block 34, the user may select different classes to generate a script or list of applications to be assembled into a software package or suite of software. Once completed, the logic passes to block 36 to execute the script by parsing the XML into executable code (e.g., C + +) and then executing the code, automatically retrieving and assembling the applications identified in the script into software packages according to the instructions contained in the script (e.g., the locations of certain applications may be discovered). As part of execution, the user may be prompted with variable names, values, and other information (e.g., package name, etc.).

FIG. 4 illustrates that a script 38 generated according to the principles described above can be hierarchical and therefore treated as a hierarchical sequence of commands that are combined to form an executable program. All commands within the script are conveniently verified using a master file of all possible commands called document type definitions or DTDs. The syntax is guaranteed to be correct by verifying all commands in the XML script against the DTD before execution.

As described above, parsing XML into, for example, C + + can be done within the controller component 26, with the controller component 26 handling all system language constructs. In some embodiments, the authentication of the script may be handled using Microsoft corporation's NET system API class XMLValidating reader, which reads the XML grammar into memory one node at a time from beginning to end for authentication. The API class XPathNavigator of NET, which uses the W3C document object model or DOM [3], can be used to accomplish the actual parsing. Unlike XMLTextREADER, which only allows XML code to be parsed forward, DOM also allows backward navigation. For most basic system commands, only forward parsing is sufficient, but for high-level commands that require conditional statements or loops, backward parsing is also required, which means DOM style parsing and keeping the entire code in memory.

Thus, both basic and advanced types of commands can be provided. The base command may be used when it comes from the model component 24. They may be independent of any language structure and in fact make up most of the system API. High-level commands, on the other hand, require additional XML parsing, which may require multiple calls to the same command. In addition, some high-level commands (e.g., conditional and loop statements) allow for nested commands. The hierarchical structure of the XML script 38 shown in FIG. 4 generally resembles a tree. Depending on the script layout, the structure may be shallow and represent one or more shrubs, or deep and represent a tree or forest. Indeed, FIG. 4 describes the nesting capabilities applied to conditional statements as well as to the XML script itself. The illustration in fig. 4 is presented in the same way as in a script, the figure being read from left to right and top to bottom.

In some embodiments, to track forward and backward navigation through nested commands, it is necessary to know the depth and current node. During script execution, return values may be recorded to determine the desired path. Undesired paths are discarded. This is achieved by recording information in a set of stacks. The current pointer to the node is moved deeper into the tree by parsing the conditional statement. The current depth after the conditional statement is executed is pushed onto the stack. When the pointer is moved deeper through nested conditional statements or shallower after completion, the current depth is pushed or popped from the stack, respectively. In addition, there are several similar stacks to track return values per condition. Although there may be four stacks for conditional statements, both IF and ELSE statements use one to track depth and one to track return values. By comparing the value of the current node to the current value in the stack, system 10 is able to understand even the most complex nesting structure.

The present invention recognizes that two scenarios may arise in which class structure must be known. The first is required for the user interface to display the names and parameters of all system API commands. Second, as required by the controller module 26, the controller module 26 dynamically interprets the system API command parameters during execution to pass input and invoke commands.

FIG. 5 shows an exemplary user interface 40 in which a list 42 of system APIs (which are essentially functional classes) is presented in the right-hand grid section and parameters of an exemplary message box command are presented in the bottom grid section 44. Parameters for other commands may also be displayed in the bottom grid area by scrolling the right grid area up or down. A toolbar 46 may also be conveniently provided. A main grid area 50 may also be provided.

Each system API command does not necessarily require a separate parsing function within the controller 26 to process a variable number of parameters for each command, but rather shares the generic parsing function of the NET API to dynamically interpret and invoke the system API commands. This can be achieved through an object-oriented component concept called introspection and dynamic calls. Input taken from the XML script is dynamically passed to system API commands to make dynamic calls. This means that the input (XML script) can be changed without recompiling the controller component 26. Typically, without applying these concepts, the parameter values would be fixed for static calls through a regular application. Only high-level commands require an explicit, separate parsing function.

NET internal procedure calls have been mentioned above. The system APIs, referenced either directly or indirectly, are fully contained within the model component 24. All API commands that are not directly contained within the model component 24 are required to have wrapper functions that point the controller components 26 to their respective locations. In some cases, many nested wrapper functions may be required, which reuse existing, almost unmodified code and programming efforts. In some embodiments, the reuse of language independent code may be facilitated through Microsoft corporation's Component Object Model (COM).

In some non-limiting embodiments, no user interface is provided that requires the addition of logic. Once a part is registered, the part can be applied as if the code were directly within the relevant class in the model part 24. Data entry into the database 18 shown in fig. 1 may be facilitated by COM objects having a user interface containing GUI fields specific to their tasks. It may be a single functional block, but it is not a complete application itself, but an object, e.g. an application block containing user interaction and back-end functionality. It cannot be used as such and must therefore be placed in a container before use. The present system 10 provides such a container called a ControlForm. The class is basically a window with two buttons-OK and Cancel. The actual functionality comes from one or more exchangeable COM objects placed in a control form container. As an example of its polymorphism, the container object is a window that requests entry of data for entry of the database 18 on one occasion and entry of data for selection of an item in the database 18 on another occasion. The use of a container showing swappable components means that the common container logic and OK and Cancel buttons need not be located within each COM component. It also means that more than one part can be displayed on the same table if desired and without having to specifically create a unique new table and part.

In accordance with the principles of the present invention, each system API command preferably returns a value that tells whether the command executed correctly, making it possible to parse the high-level structure according to Boolean true or false. In addition to the required Boolean return values, each command may return nearly infinite values that are specific to the command. The ArrayList structure of NET makes this possible by storing data as a dynamically scalable array of objects. Objects may be generic.

The Arraylist return structure may be held in memory only temporarily. For each command executed by the XML script, its return structure is replaced by the return structure of the next command. This requires that any return values be saved immediately after the system API command is executed. This process is performed automatically when high-level system commands are executed. When using user-defined variables, the user may manually save the return values from memory into the variables.

In some embodiments, four methods of accounting for user-defined variables may be provided. The first is the AddVariable command through the system API, which requires the placement of variable names and values into the script before running. The variable types are stored as a string and each parameter inside the commands is first read as a string and later converted to another type by the current system command or by another system command.

A second way to specify a variable is to command promptaddrvariable through a system API, which is similar to AddVariable, but which only prompts the user when it is used for execution of the variable value. The variable name is still specified within the script and is fixed at run-time.

A third way to specify a variable is through the System API command AddVarFromMem, which stores a return value according to a specified location in the ArrayList return structure of the previous command. This requires some knowledge of the previous command and the available return structures.

A fourth method of specifying variables is addmultiplelfrommem, which is similar to AddVarFromMem, but allows all return values of a previous command to be stored in multiple user-defined variables.

By using AddVarFromMem or addmultiplefrom, the temporarily stored return value can be retained in memory while the program is running. By using a combination of the four commands described above, a user can specify and assign a variable to a value, read user input into a variable, and assign the variable to the output of another command.

The system specific language commands may include "If", "For", and "While". System API commands may include copyFolder, deleteFolder, RenameFolder copyFile, deleteFile, RenameFile, Executeprogram, AddRegKey, RemoveRegKey, CreateFile, WriteToFile, AddInisection, RemoveIniSection, AddIniKey, RemoveIniKey, Settings, SetStatus, MsgBox, IsFile, IsDir, IsInFile, IsRegKey, IsRegValue, IsIniSection, IsIniKey, IsNT.

Presented below are some so-called "use cases," which represent scripts that are not formally XML formatted.

1.1 creating an INI Profile

Description Create INI file or files for a given recovery tool

Use Case identifier B1

Author

Date 5/01/2003

Revised

Actors Release Engineer

Pre-conditions FI-％Project name％-PAC File-BOM is locked

Actions(Use AddVarToText after each command)

Run Program to generate INI script files

open VSMS database

Query Project(GetProject)

open FI-project-Pac File BOM(GetBOMData？)

Assign Pac Files(AutoAssignPACFiles)

Update multiplie(set all to compressed)(SetARCDCompressed？)

open Program to generate INI script files

Generate ARCD recovery media Scripts(GenerateARCDScripts)

Select Drive to generate files to

View Scripts(Optional)

Check-in INI configuration files(Checkin)

Upload to VSMS database(UploadFiles)

Send Release Mail for INI(DumpText)

Subject＝VAIO INI FILES RELEASE NOTIFICATION ％ project

name％

％phase％

Project

PC Model

Build

INI File name and unique identifier

list changes from last build

Post-conditions Tested during PAC File Creation process

Includes Check-In

Upload

Extends

Generalizes

1.2 creating Pac File (Package packing software)

Description Creates PAC file(s)for software recovery tools

Use Case identifier B2

Author

Date 5/01/2003

Revised

Actors Release Engineer

Pre-conditions INI file(s)created

Actions Copy files to local drive

Open browser

Browse to ARCD Scripts directory

Execute program to copy individual software locally from the network

(ExecuteProgram)

Verify files are copied to local drive

Execute program to package each directory(ExecuteProgram)

Check-in PAC File(s)(CheckIn)

Upload to VSMS database(UploadFiles)

Send Release Mail for PAC File(s)(DumpText)

Subject＝VAIO PAC FILES RELEASE NOTIFICATION ％ project

name％

％phase％

Project

PC Model

Phase

DMI information

#PAC Files

PAC File Names

Changes from Last Build

Known Issues

Special Notes

Post-conditions Must be tested during software download and recovery

process

Includes Create INI

Check-In

Upload PAC File(s)

Extends Create-INI

Generalizes

1.3 creating RDVD recovery media

Description Creates RDVD(s)for HDD Recovery machines that have

DVD drives

Use Case identifier B5

Author

Date 5/02/2003

Revised

Actors Release Engineer

Pre-conditions Pac File(s)，INI File(s)，and Image File(s)are

created

Actions Create PAC File(s)

Create Recovery Partition

Test Recovery Functionality

Copy files to local drive

Copy PI Contents Local

Copy Foundation Image files(s)local

Delete the Minint Folder

Copy RDVD Boot files to Local

Create ISO File(s)

Create master RDVD(s)

Test

Check-in RDVD(s)

Turn-in RDVD(s)to Software Librarian

Send Release Mail for RDVD

Subject＝VAIO RDVD FILES RELEASE NOTIFICATION ％ project

name％

％phase％

Project

PC Model

Phase

Image Unique identifier

RDVD Unique identifier

Recovery partition Unique identifier

DMI information

Version

Media

Volume Labels

Changes from Last Build

Known Issues

Special Notes

Post ISO File(s)

Post-conditions Must be tested with the correct machine(s)，DMI

information

Includes Check-In

Post ISO(not created yet)

Extends None

Generalizes None

1.4 creating HRCD recovery media

Description Creates HRCD(s)for HDD Recovery machines that do not

have DVD drives

Use Case identifier B6

Author

Date 5/02/2003

Revised

Actors Release Engineer

Pre-conditions Pac File(s)，INI File(s)，and Image File(s)are created

Actions Create PAC File(s)

Create Recovery Partition

Test Recovery Functionality

Create master HRCD(s)

Create ISO File(s)

Test

Check-in HRCD(s)

Turn-in HRCD(s)to Software Librarian

Send Release Mail for HRCD

Subject＝VAIO HRCD FILES RELEASE NOTIFICATION ％ project

name％

％phase％

Project

PC Model

Phase

Image Unique identifier

HRCD Unique identifier

Recovery Partition Unique identifier

DMI information

Version

Media

Volume Labels

Changes from Last Build

Known Issues

Special Notes

Post ISO File(s)

Post-conditions Must be tested with the correct machine(s)，DMI

information

Includes Check-In

Post ISO(not created yet)

Extends None

Generalizes None

1.5 registration

Description Check in any item into VSMS database

Use Case identifier S1

Author

Date 5/02/2003

Revised

Actors Release Engineer

Pre-conditions None

Actions Check-in an item

Open VSMS database

Select Software Release/Submit

Select Vendor

Select Component/Release Name

Click Submit

Fill in the form completely with all applicable data

Click Submit

Post-conditions None

Includes None

Extends None

Generalizes None

1.6 Loading into VSMS database

Description Upload an item to the appropriate locations

Use Case identifier S2

Author

Date 5/02/2003

Revised

Actors Release Engineer

Pre-conditions Item is checked in to VSMS database

Actions Open VSMS database

Select Software Release/Query

Select Vendor

Select Component/Release Name

Click on the Unique identifier for the Item

Select view item

Click on Upload

Follow on screen prompts

Post-conditions None

Includes None

Extends None

Generalizes None

1.7 Loading ISO File

Description Upload an item to the appropriate locations

Use Case identifier S2

Author

Date 5/02/2003

Revised

Actors Release Engineer

Pre-conditions None

Actions Check-in an item

Open VSMS database

Select Software Release/Query

Select Vendor

Select Component/Release Name

Click Submit

Post-conditions None

Includes None

Extends None

Generalizes None

While the particular SYSTEM AND METHOD FOR BUILDING A SOFTWARE SET, as herein shown and described in detail, is fully capable of attaining the above-described objects of the invention, it is to be understood that it is the presently preferred embodiment of the present invention and is thus representative of the subject matter which is broadly contemplated by the present invention, that the scope of the present invention fully encompasses other embodiments which may become obvious to those skilled in the art, that the scope of the present invention is not limited by any other means, except as may be required by the appended claims, in which reference to an element in the singular is intended to mean "only one" (unless explicitly so stated), but rather "one or more". It is not necessary for a device or method to address each and every problem sought to be solved by the present invention, for it to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. To the extent not expressly defined herein, the claims are to be given all ordinary and accustomed meanings that are not irreconcilable with the present specification and file of the application.

Claims (10)

1. A method for assembling a software package, comprising:

presenting an XML structure to a user, the structure being a class in an object-oriented programming environment that can be used to obtain an application;

allowing the user to construct an XML script using the structure, the script defining the contents of the software package to contain applications available through the structure used by the user to construct the script;

parsing the script to provide software code; and

the software code is executed to automatically assemble at least two applications defined by the script into a software package.

2. The method of claim 1, comprising: at least some of the classes are presented in a class window (42) of a computer display (40) for selection by a user.

3. The method of claim 1, comprising: prompting for information relating to at least an identification of the software package.

4. An apparatus for assembling a software package, comprising:

means for presenting an XML structure to a user, the structure being a class in an object-oriented programming environment that can be used to obtain an application;

means for allowing said user to construct an XML script using said structure, said script defining the contents of said software package to contain applications available through the structure used by the user to construct the script; and

means for parsing the script to provide software code;

means for executing the software code to automatically assemble at least two applications defined by the script into a software package.

5. A system for assembling a software package for a computer, the system comprising:

a model component (24) comprising an object-oriented Application Programming Interface (API) for generating a list of at least two software applications;

a controller component (26) in communication with the model component (24) and containing an analysis program that parses the list into code for execution to automatically assemble the at least two software applications into a software package; and

a viewing component (28) in communication with the controller component (26) to present object classes for obtaining applications to a user for use in generating a list,

wherein directly or indirectly referenced application programming interfaces are contained within the model component (24) and application programming interfaces not directly contained within the model component (24) have wrapper functions that point the controller components (26) to their respective locations.

6. The system of claim 5, wherein the list contains storage locations associated with the application.

7. The system of claim 5, wherein the API is XML-based.

8. The system of claim 7, wherein the code is C + +.

9. The system of claim 8, comprising: means for presenting at least some of the classes in a class window (42) of a computer display (40) for selection thereof by a user.

10. The system of claim 9, comprising: means for prompting for information relating to at least an identification of the software package.