Design Data Management System and Associated Method

This invention relates generally to data management systems for computers. More particularly, it relates to a graphically oriented data management system that allows a user to encapsulate software tools and the design data on which such tools operate into a single entity referred to herein as a design object. Once encapsulated, the design data is managed through a graphical interface.

Management of data in a computer system, especially in the field of design automation, can be a complex task. Software tools such as text editors, schematic editors, and circuit simulators are employed in the process of designing products with a computer system. To work efficiently, one must not only be knowledgeable on how these software tools operate, but must also be intimately familiar with the operating system of the computer on which the tools involved run. Typically a tool must communicates with several data files in the process of performing its task. Using the commands of the operating system, one collects the relevant files and then applies the tool. The output of the tool is usually several additional data files, each of which has a filename. These additional files are then managed (copied, moved, etc) by typing the filename at an operating system command line that appears on the display terminal. To compound the complexity, multiple versions of the design data are often created by a user as his product design evolves. Each version of the design data produced by a tool may be related to specific versions of data produced by other tools. The user must then somehow keep track of this versioned data to provide for the release of a consistent group of files defining the overall product design. Effective data management thus requires thorough knowledge of the operating system, of the tool, of the files that a tool requires, and of the files that a tool produces.

One attempt to simplify management of such data is suggested by the graphical user interface provided by the Apple Macintosh computer. Each data file is represented by a file icon rather than a textual file name. To manage a file, one simply selects and opens the associated icon. Similar graphical user interfaces include Microsoft Windows, Hewlett-Packard Vue, and Sun Desktop.

Although these interfaces offer some advantage over the prior data management techniques, they have their own drawbacks which make them unsuitable for use with many tools. For example, although the data files are represented graphically, each icon represents only one data file. Opening the icon thus opens only the one associated file. One would still have to keep track of multiple data files in some manner before they could be used with a tool that required or produced such multiple data files. Moreover, none of these interfaces provides for easily tracking and managing multiple versions of design data.

FIG. 1 is a view of a computer system in which a data management system according to the invention may operate.

FIG. 2 is a view of a design object according to the invention.

FIG. 3 illustrates the storage of multiple versions of a design object.

FIG. 4 illustrates the use of references to record associations between design objects.

FIG. 5 is a flowchart illustrating the process for encapsulating data into a design object.

FIG. 6 is a view of an instance of a data type design object.

FIG. 7 is a view of an instance of a tool type design object, referred to herein as a tool viewpoint.

FIG. 8 illustrates the use of qualification and termination scripts with a tool viewpoint.

FIG. 9 illustrates a file system directory that contains tool viewpoints.

FIG. 10 is a view of a group of related design object instances referred to herein as a configuration.

FIG. 11 illustrates operations that may be performed on the design management system on a configuration.

FIG. 12 is a screen display showing the different portions of the design management system interface for managing design objects.

The following described embodiment of the invention is a computer program presently implemented in C++, an object oriented programming language. The program is designed to run on conventional computer or workstation systems such as the system shown in FIG. 1, which include a video terminal with display screen 20, computer 22 with memory, keyboard 24 and mouse 26. It should be understood, however, that the invention is not limited to this embodiment. Based on the following description, the invention could as well be implemented equivalently by one skilled in the art in a number of high level programming languages, including C and Pascal, or in hardware embodiments as well.

To assist in describing the invention, terms that have a special meaning are defined in a glossary, attached hereto as Appendix A. These terms, although unfamiliar one their faces, are well understood in the art.

The Design Object

Referring to FIG. 2, the basic element of a data management system according to the invention is the design object. A design object provides a means of organizing design data into a single entity which can be represented to, and manipulated by, users of the data management system. An object represents a set of files (indicated at 28) in the computer file system that may be treated as a single entity. The set of files that make up a design object is called the fileset. Rather than present the user with a complex set of physical files that describe various related aspects of a design, the design object presents the user with a single, representative element within the file system upon which to perform design tasks. A user can view, and invoke software design tools upon, a design object by interacting with this single representative entity, independent of the number and location of actual physical files that make up the fileset of the design object.

Using design objects, the data management system provides the user with an object-oriented view of the design data. A design object is defined by its type, such as a document type (indicated at 30). A design object's type provides a means to differentiate between design objects, and to determine which design tools can operate on the data that comprises the design object. A design object instance is a physical specimen of a particular type, such as instance 32 in FIG. 2. Each instance of a design object has a name (indicated at 33). Design objects are identified uniquely within the data management system by specifying a name and an object type.

All design object types map to one of two possible basic types. A data object is a type of design object created and edited by tool objects. A tool object is a type of design object that creates and edits data objects. The relationship between the two basic objects is such that each data object understands which tool objects can operate upon it (including one tool type specified as the default tool type), and each tool object understands which data objects it can operate upon. An infinite number of data and tool object types can be defined by adding certain attributes to the basic types, as will be described.

Referring now to FIG. 3, design objects can be versioned, or unversioned. Each time an object is edited, a new representation of the object, called a sequence version, is written out to physical disk storage within computer 22. Versioned objects have the ability to save previous representations of themselves, thus maintaining a history of the design creation process for the object. Unversioned objects maintain only a single representation, the most current one, of themselves on disk (in effect, no history is kept). Each design object type has an associated version depth, which is the number of previous versions of the object to maintain on disk. In FIG. 3, the version depth is two. Versions of an object that exceed the specified version depth for the object type are automatically removed from disk when a new version is written. This is called version pruning. The version depth of a versioned object is set to two, by default, but can range from one to infinity. In FIG. 3, versions V1 and V3 were deleted as additional versions were added on top of them. Version V2 is a frozen version, version V4 is the back-up version, and version V5 is the current version. The version depth of an unversioned object is always one, and cannot be changed since no history is kept for unversioned objects.

Design object versions can be frozen, such as version V2. Freezing a version of a design object prevents the version from being manually deleted or automatically deleted by the version pruning mechanism. Frozen versions are useful for keeping specific back versions of an object in the system. Later, if a frozen version is no longer desired, it can be unfrozen, which then makes it susceptible to version pruning if the design object history exceeds the specified version depth for the object type.

In addition to the attributes that define design object identity (name and type), users of the data management system, as well as tools, can define additional design object attributes. Such attributes are called metadata, or additional data that describes some aspect of the design object. Two types of metadata can be added to a design object: properties and references.

Referring again to FIG. 2, property is a name/value pair that can be attached to a design object. Property names and values are implemented as character strings. These properties provide additional information about the design object, such as when the object was last written to disk, what design tool performed the last edit on the design object, what user owns the design object, or an indication of the status of the object in the design process (prototype, approved, released, etc.). The properties may also be object type specific (as indicated at 34) or version specific (as indicated at 36). The data management system provides a means to add,.modify, and delete design object properties. It also provides a means to view design object properties on any particular design object version of interest.

Referring now to FIGS. 2 and 4, a reference (indicated at 37) provides a means for establishing a relationship among design objects such as instances 38 and 40, thus associating one design object with another. A reference is implemented as a character string record that contains the pathname to the referenced object, the type of the referenced object, and the version number of the referenced object.

Any design object in the data management system can be associated with any other design object in the system by creating a reference from one object to the other object. A document that describes a particular aspect of a design may be associated with that design aspect by creating a reference from the design to the descriptive document (or vice versa). The data management system provides a means to add, modify and delete references between design objects. It also provides a means to view design object references on any particular design object version of interest.

Properties can be attached to references. Such properties can be used to establish the intent, or semantic, of the reference. For example, a reference from a design schematic to a design document has a much different meaning than a reference from that same schematic to one of its logic symbols. Properties attached to a reference provide the mechanism for storing the meaning of the reference. The data management system provides a means to add, modify, and delete properties on references between design objects. It also provides a means to view properties on design object references on any particular design object version of interest.

All metadata is stored on a per-object basis in a file called the attribute file. The attribute file, indicated at 42 in FIG. 1, is an ASCII file that is comprised of a number of lines of text. The contents of the attribute file define the available metadata for each version of the object, and for the object as a whole. The information contained within each line is indicated by the first character in the line, called a tag. The following types of tagged lines are used to indicate specific information in an attribute file:

continuation

attribute header

sequence version

fileset member

object version header

reference

property

A line may be continued on the next line by making the next line a continuation line.

Attribute header, sequence version, reference, object version header, and property lines must appear in the following sequence. Comments in the pseudocode below are indicated by "//" at the beginning of the comment:

Type Definition and Registration

Design objects are known to the data management system by their type. Hence, there must exist a method of defining a design object type. This method is called encapsulation. FIG. 5 illustrates the different steps in the process of encapsulation for creating new types of data and tool objects. Encapsulated data types define the set of available tools that can be used within the system. One or more type definitions are contained in a type registry, which is a binary file readable by the design management system.

As mentioned previously, all design object types map to one of two possible basic types - data object type or tool object type. An infinite number of data and tool object types can be defined using the two basic types by adding certain attributes to the basic types. Properties, described previously, are used in the type definition to implement these attributes.

The following steps, indicated by numerals in FIG. 5, define the process of creating a data type.

1. Choose the behavior desired for the data type. This can be done by specifying additional or new behavior by writing specialized type code, or by inheriting an existing set of behavior from another object type. No type code is given, and the name of the base type from which to derive behavior is specified.

2. Choose a name for the data type. The name is a character string of arbitrary length.

3. Choose whether the object is versioned, or unversioned. If the object is versioned, then the property name ddms.sub.13 versioned.sub.-- object is added to the type.

4. Choose or create a default tool type for the data type (52). An instance of this tool type is invoked by default when a default open operation (double-click of the mouse 26 button) is performed on a data object of the type being defined. The default tool type is indicated by the addition of the property default.sub.-- tool<tool type> to the type.

5. Create a symbol to graphically represent the data type (54). This symbol is called an icon. The data management system user would recognize the data type by visualizing its associated icon on the graphical display screen of the computer. Icons are defined by the addition of two properties to the type:

large.sub.-- icon <pathname of icon file, glyph character>

small.sub.-- icon <pathname of icon file, glyph character>

where:

pathname of icon file is a character string that indicates the location in the computer system of the file containing the icon, and glyph character is the representative character within the icon file

The large.sub.-- icon property indicates the icon to be displayed when using an iconic display navigation mode within data management system. The small.sub.-- icon property indicates the icon to be displayed when using the list display navigation mode within data management system.

6. Define the fileset for the data type. For example, FIG. 6 shows an example of a data object instance named "test" of object type "cube". The user would visualize object "test" in the data management system as an icon representing type "cube" name "test". The fileset is defined by the addition of the property fileset def <>fileset specification> to the type, as follows:

The following steps define the process of creating a tool type:

1. Choose a name for the tool type. The name is a character string of arbitrary length.

2. Create a symbol to graphically represent the tool type (54). This symbol is called an icon. The data management system user would recognize the tool type by visualizing its associated icon on the graphical display screen of the computer. Icons are defined by the addition of two properties to the type:

large.sub.-- icon <pathname of icon file, glyph character>

small.sub.-- icon <pathname of icon file, glyph character>

where pathname of icon file is a character string that indicates the location in the computer system of the file containing the icon, and, glyph character is the representative character within the icon file.

The large.sub.-- icon property indicates the icon to be displayed when using an iconic display navigation mode within data management system. The small.sub.-- con property indicates the icon to be displayed when using the list display navigation mode within data management system.

3. Define a set of data types upon which this tool type can operate. This set is defined by the addition of the property valid.sub.-- tools.sub.-- list.sub.-- <data types> to the tool type. The information in <data types> can be one or more data types, indicated by data type name, separated by a blank space. The tool type being defined can either create or edit instances of data types in the data type list. The tool is restricted to operate only on data types in this list. The tool can be indicated as the default tool by one or more of the data types in this list.

There is no requirement to define a fileset for a tool type, since all tool instances have the same structure on disk.

Once these data and tool types are defined, they must be loaded into the data management system to be known by the system. A method exists to make these defined types known to the data management system. This method is called type registration, indicated by blocks (56) and (58) in FIG. 5.

Data and tool types are contained in files called type registries. A type registry can contain one or more data and/or tool type definitions. The contents of a type registry (the data and tool types) can be loaded into the data management system by causing the data management system to read the contents of the type registry into program memory. The contents of all type registries read by the data management system are held in a data structure called the type manager.

After a type registry is loaded, all the types contained in the registry are known to the data management system. The data management system can, at this time, recognize instances of data and tool types as defined in the type definitions for those types, and can invoke tools on data to create or edit instances of the data. The tool invocation process in the data management system includes a means of controlling the invocation and termination sequence for the tool.

Referring to FIG. 7, an instance 80 of a tool (called a tool viewpoint) is shown. A tool viewpoint controls the invocation and termination of a tool (FIG. 8). For each tool, a qualification script is used to define to the data management system how to invoke (start) the tool. This script is written in a procedural programming language of a kind known in the art, which is provided as part of the operating environment within the data management system. The qualification script 82 gathers information from the data management system about the data object upon which to invoke the selected tool, such as the name of the data object, and its type. Based on the object name and type, decisions can be made about how to invoke the tool, if choices exist. Some examples might be:

"Only invoke this tool if certain steps in the design process have been completed . . . "

"Invoke this tool in the background . . . "

The choices presented depend on those possible for the particular tool invocation scheme. Successful execution of the qualification script causes a new process to be created on the computer, and the tool to begin running in that new process. UNIX vfork and exec calls are used to create the new process, and start the tool. The tool 80 then creates or edits the data associated with the data object. Multiple processes can be executed by a single qualification script.

For each tool, a termination script 84 can optionally exist. This script is also written in the procedural programming language. The termination script 84 defines how to "clean up" after the tool executes to completion. A termination script can be used to control or cause actions to occur based on how the tool executed, how it terminated (normally, or with some error condition), or to clean up temporary data that might remain after the tool completes. Termination scripts start execution with a snapshot of the data environment available at the time the tool process was invoked, in effect, restoring the context at the time the tool was invoked. This can be used to pass data from the qualification script to the termination script for processing after completion of the tool.

The Design Management System Environment

Referring to FIG. 12, the data management system includes an interface that provides capabilities for managing (i.e. organizing and manipulating) design data represented by design objects. The data management system can manage individual objects, but also provides facilities to manage groups of objects as an interrelated entity.

As discussed above, the data management system provides a mean for dynamically extending the number of design object types known to the environment. This is done by causing the data management system to perform a file system read operation on a type registry file, the result of this operation being the loading of the types contained in the registry into the data management system. The object types read into the system can be data types and/or tool types.

Once the data management system contains the necessary object type definition, it can recognize design objects within the computer filesystem through a process called object recognition. Object recognition occurs when the user goes to a container, the process of going to a particular container being known as navigation. The container may contain various entities, such as files, links or other containers. The object recognition algorithms in the data management system group together appropriate filesystem entities within a container into design objects, according to the type definitions loaded into the data management system type manager. If design objects are found in a container, the appropriate icon that represents the design object is displayed to the user in a window called the Navigator Window 100. A navigator can display objects in either an iconic form, using the large icon defined in the type definitions for the objects in either an iconic form, using the large icon defined in the type definitions for the objects, or in a list form using the small icon defined in the type definitions for the objects.

Two modes of navigation are provided. Navigation-by-containment allows for recursive descent and ascent through the design object hierarchy by selecting a design object that is a container design object and performing an Explore Contents to push down into the object hierarchy. Navigation-by-reference allows for the recursive traversal of the design object reference hierarchy by selecting a design object that has references and performing an Explore References to traverse across the object reference hierarchy. In both navigation modes, the user can return to the last location visited in either hierarchy by performing an Explore Parent. Each of the Explore operations (as well as Go To, which jumps to a specified location) is performed by clicking on the appropriate button arrow in the navigator window 100.

Design tools can also be dynamically added to the tools provided by the data management system. Tool type definitions are read into the data management system by reading them from a type registry, as noted. Instances of tool types (the tools themselves, such as a schematic editor or a text editor) are added to the data management system by specifying the location in the filesystem of a toolbox, as illustrated in FIG. 9. A toolbox is a file system directory that contains tool viewpoints. A toolbox is used to organize tool viewpoints into groups that make logical sense to the user (e.g. all simulation tools are in one toolbox, all editing tools in another, all tools from a particular tool vendor in another, etc.). All unique tools are displayed to the user in a centralized view window within the data management system called a Tool Window indicated at 101 in FIG. 9.

Tools can be invoked to create or edit data objects several ways.

If the user performs a double-click of the left mouse button while holding the location cursor over an icon in a Navigator Window 100, the default tool will be invoked for the design object represented by the icon.

If the user performs a single-click of the left mouse button while holding the screen cursor over an icon in the navigator window 100 (performing a select of the object), and then performs an Open command, a list of valid tools is displayed. The list of valid tools as defined is derived from the input+data information on the type definition for all tools currently loaded into the data management system. From the list of valid tools, the user would select a single tool for execution.

If the user performs a double-click, or a single-click/Open while holding the location cursor over an icon in the Tools Window, the tool will invoke on a blank, or untitled, data object. For those tools where this is not possible, the tool can prompt the user for a data object by adding the appropriate query to the qualification script for the tool.

The data management system provides a means of deleting one or more objects from the environment. Object deletion involves deletion of the fileset members associated with the design object from the filesystem. Object deletion is performed by selecting an object and executing a Delete Object command.

The data management system provides a means of adding and deleting references between design objects. References are added by selecting an object, calling the command to add a reference, and specifying the target object to reference. Deleting a reference involves selection of the reference from a list of possible references on a selected object, and performing a Delete Reference command.

The data management system provides a means of creating, editing and deleting properties on both design objects and references. A property name/value pair can be added by selecting an object or reference and performing either an Add, Edit, or Delete Property command.

The data management system provides a means for displaying information about a selected object within the environment. After selecting an object, the Report Info command is performed, which lists:

the object name;

the object type;

the physical location of the object in the computer filesystem;

the version of the object about which information is being displayed;

the version depth of the object (how many back versions to save);

the protection status of the object (can I read or write the object?);

the lock status of the object (can the object be accessed, or is it locked?);

the release status of the object (is the object part of a released configuration?);

the date the object was last modified (written to disk);

the properties on the object; and

the references from this object to other objects in the environment.

The data management system provides a means of making a copy of an object to another location in the filesystem. Either the entire object, or a specific version of the object, can be copied. This is performed by doing a Copy Object command on a selected object. References between objects that are part of the set of copied objects are automatically modified to point to the copied objects at their new locations.

The data management system provides a means of moving an object from one location to another in the filesystem. A version of an object cannot be moved separately; the entire object must be moved. Move is performed by doing a Move Object command on a selected object. References between objects that are part of the set of moved objects are automatically modified to point to the moved objects at their new locations.

The data management system provides a means of changing the name of an object by selecting the object and performing a Change Name command.

The data management system provides a means of changing the version depth of an object by selecting the object and performing a Change Version Depth command. This allows the user to control how much history to save on a per-object basis.

The data management system provides a means of changing the access protections of an object by selecting the object and performing a Change Protection command. Read, write, and execute protections can be modified. These protections map to the standard permissions found on UNIX systems.

The data management system provides a means of grouping a set of design objects into an entity that can be manipulated as a whole. This group of related objects is called a configuration and is illustrated in FIG. 10 at 102. Objects in a configuration are related through either containment or reference. A configuration object is a type of object used to keep track of related objects within a configuration. The configuration object uses the reference and property capabilities of the data management system to perform grouping of objects in the configuration.

Objects added directly to the configuration by a user action are called primary objects, such as objects 104 and 106. Primary objects usually represent some significant, or primary, piece of design data to which other data is related.

Objects added to the configuration as a result of being related to a particular primary object are called secondary objects, such as objects 108, 110, 112 and 114. The configuration object uses a set of rules specified per primary object to determine what secondary objects to include in the configuration. These rules specify the following:

1. The version of the primary object to be included in the configuration. This specific version is used to determine what secondary objects to include. The default version of the primary object includes the current version.

2. The containment traversal rule. By default, if the primary object is a container object (i.e. it contains other design objects), the containment hierarchy is recursively descended and any objects within the hierarchy are added to the configuration as secondary objects. Optionally, the rule could be specified such that contained objects are not included in the configuration.

3. The reference traversal rule. By default, if the primary object has references to other objects, the reference hierarchy is recursively traversed and any referenced objects within the hierarchy are added to the configuration as secondary objects. Optionally, the rule could be specified such that referenced objects are not included in the configuration.

Filters to apply to the list of secondary objects generated from Rule 2 and Rule 3, above. These filters limit the number of secondary objects added to the configuration by either causing secondary objects to be excluded, or causing secondary objects to be included. Filters can be specified in four ways:

1. Containment pathname filtering allows the user to specify certain objects be included or excluded from the configuration based on their filesystem pathname.

2. Object type filtering allows the user to specify that only certain types of design objects be included or excluded.

3. Object property filtering allows the user to limit the objects that are included or excluded based on design objects properties and their values.

Once a list of primary objects has been added and the build rules are specified, a build operation is performed. The build operation takes the list of primary objects, applies the inclusion and/or exclusion rules specified per primary, and creates a list of secondary objects, adding them automatically to the configuration. Objects are added to the configuration by creating a reference from the configuration object to the primary or secondary object to be included.

After a configuration 102 is built, a certain set of data management system configuration operations can be performed on the configuration, as shown in FIG. 11.

The configuration can be locked to prevent design objects in the configuration from being changed during additional configuration operations.

The objects in a configuration 102 can be copied as a set to another area of the filesystem, and can be marked to prevent their further evolution. This process is called release. All relationships between objects in the old location are maintained in the new location. References between objects that are part of the set of released objects are automatically modified to point to the released objects at their new locations.

The objects in the configuration 102 can be frozen. Frozen design objects have been described earlier in this document. Unfreezing of configurations is also provided.

The objects in the configuration 102 can be deleted. This causes all objects called out in the configuration to be removed from the filesystem.

Having illustrated and described the principles of the invention in a preferred embodiment, it should be apparent to those skilled in the art that the invention can be modified in arrangement and detail without departing from such principles. We claim all modifications coming within the spirit and scope of the following claims.