Design data management system and associated method

Abstract

A system and method for organizing design data in a computer system so that multiple data files can be represented and manipulated as a single entity, referred to herein as a design object. Each design object is represented graphically by a symbol on a computer display screen. Associated with the multiple data files of a design object is a software design tool such as a text editor or schematic editor. The tool may be applied to work on the data files of the design object when the design object is opened. Opening a design object is typically done by positioning the screen cursor over the symbol and then using a mouse or keyboard to open the symbol and thereby the data files and tool. Data files grouped in a design object are thus much simpler to manage than separate data files that a user must first identify, retrieve and collect before applying a tool.

Claims

We claim:

1. In a computer automated design system having a display, memory and multiple software tools for operating on data files representing a design, a method of managing design data for ease of manipulation by a user, the method comprising the following steps:

providing in memory a design object type that includes a fileset definition of multiple data files representing related but distinct aspects of the design object type;

creating an instance of the design object type, the data files of the instance each containing design data on a related aspect of a particular design represented by the instance;

providing on the display a symbol visible to a user which represents the instance;

associating with the design object type a software tool that is invoked upon opening of the instance; and

in response to an opening of the instance, opening all of the data files in the fileset corresponding to the instance and combining the data of the data files to provide the particular design and invoking the associated software tool for communication with the data files.

2. The method of claim 1 wherein representing each instance of the design object with a symbol comprises displaying an icon on the display screen.

3. The method of claim 1 in which the computer system contains files not represented by a defined object type, wherein such files are represented by design objects of a default type.

4. The method of claim 1 wherein the step of defining a design object type comprises executing a tool adapted for constructing design objects.

5. The method of claim 1 including representing multiple versions of the fileset by the design object, the multiple versions accessible for selective manipulation.

6. The method of claim 1 including editing an instance of the design object data type.

7. The method of claim 1 wherein associating with the design object type a software tool includes associating a default tool.

8. The method of claim 1 wherein associating with the design object type a software tool includes providing a list of tools from which a tool is chosen for association.

9. The method of claim 1 including attaching properties to the design object type.

10. In a computer automated design system having a display, memory and multiple software tools for operating on data files representing a design, apparatus for managing design data for ease of manipulation by a user, comprising:

means for providing in memory a design object type that includes a fileset definition of multiple data files representing related but distinct aspects of the design object type;

means for creating an instance of the design object type, the data files of the instance each containing design data on a related aspect of a particular design represented by the instance;

means for providing on the display a symbol visible to a user which represents the instance;

means for associating with the design object type a software tool that is invoked upon opening of the instance;

means for opening, in response to an opening of the instance, all of the data files in the fileset corresponding to the instance and combining the data of the data files to provide the particular design; and

means for invoking the associated software tool for communication with the data files.

11. The apparatus of claim 10 wherein the means for providing a symbol on the display comprises means for displaying an icon on the display.

12. The apparatus of claim 10 wherein the computer system contains files not represented by a defined object type, wherein such files are represented by design objects of a default type.

13. The apparatus of claim 10 wherein the means for providing a design object type comprises a software tool adapted for constructing design object types.

14. The apparatus of claim 10 including means for representing multiple versions of the fileset by the design object type, the multiple versions accessible for selective manipulation.

15. The apparatus of claim 10 including means for editing an instance of the design object data type.

16. The apparatus of claim 10 wherein the associated software tool is a default tool.

17. The apparatus of claim 10 wherein the associated software tool is chosen from a list of tools.

18. The apparatus of claim 10 including means for attaching properties to the design object type.

Description

TECHNICAL FIELD

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.

BACKGROUND OF THE INVENTION

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.

SUMMARY OF THE INVENTION

BRIEF DESCRIPTION OF THE DRAWINGS

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.

DETAILED DESCRIPTION

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:

    ______________________________________
    //The following line is required first to define the design
    //object identity and file format
    <attribute.sub.-- header.sub.-- line>
    //One or more instances of the following group of lines are
    //required to define the version history of the object.
    //Version history can be listed in any order.
    <sequence.sub.-- version.sub.-- line>
                    // Sequence version record
    <property.sub.-- line>
                    // zero or more following each
                    // sequence version - these are
                    // the sequence version properties.
    <fileset.sub.-- member.sub.-- line>
                    // <fileset.sub.-- size> following each
                    // sequence version -
                    // these identify the names of the
                    // files in the fileset.
        . . .       // Repeat group for past versions.
    //Zero or more instances of the following group of lines are
    //required to define references for each sequence version. No
    //object version header for a particular sequence version
    //means that the sequence version of the object has no object
    //properties or references. The versioned object information
    //for the current version is defined first.
    <object version.sub.-- line>
                    // References for the current
                    version
    <property.sub.-- line>
                    // zero or more following
                    the object
                    // version line
                    // these are the design object
                    // properties.
    <reference.sub.-- line>
                    // one or more
    <property.sub.-- line>
                    // zero or more following each
                    // reference line - these
                    // are the references properties
        . . .       //Repeat group for past versions
    The fields of each line are separated by whitespace. The first
    field after the tag may follow the tag immediately. Items
    enclose in brackets [ ] are optional (zero or one). Objects
    enclosed in braces { } are repeated (zero or many).
    Definition of continuation line:
    <continuation.sub.-- line>::=
    .backslash.<additional.sub.-- attributes.sub.-- for.sub.-- previous.sub.--
    line>
    Definition of attribute header line:
    <attribute.sub.-- header.sub.-- line ::= A <file.sub.-- format version>
    <released.sub.-- flag>
    <object.sub.-- type.sub.-- name>
    <object.sub.-- uid> <current.sub.-- version.sub.--
    number><version.sub.-- depth>
    where:
    <file.sub.-- format.sub.-- version> ::= <unsigned>
    <released.sub.-- flag> ::=r u
                    //r-> released, u -> unreleased
    <object.sub.-- type.sub.-- name> ::= <string>
    <object.sub.-- uid> ::= <ascii .sub.-- uid>
    <current.sub.-- version .sub.-- number> ::= <unsigned>
    <version.sub.-- depth> ::= <unsigned>
    note:
    (1)<ascii.sub.-- uid> is a uuid encoding supplied by the
    uuid.sub.-- $encode( ) routine in the idl/c/uuid.h include file
    supplied on the host computer system.
    Definition of sequence version line:
    <sequence.sub.-- version.sub.-- line> ::=
    V <uid.sub.-- valid.sub.-- flag> <sequence.sub.-- _
    version.sub.-- number>
    <fileset.sub.-- size> [<sequence.sub.-- version.sub.-- uid>]
    where:
    <uid.sub.-- valid.sub.-- flag> ::= v i
                    v ->uid valid, i ->uid invalid
    <sequence.sub.-- version.sub.-- number> ::= <unsigned>
    <sequence .sub.-- version.sub.-- uid> ::= <ascii.sub.-- uid>
    <fileset.sub.-- Size> ::= <unsigned>
    note:
    (1) <sequence.sub.-- version.sub.-- uid>
    is only present if <uid.sub.-- valid.sub.-- flag>
    == V
    (2) <fileset.sub.-- size> in the header gives the number of
    <fileset.sub.--
    member.sub.-- line> lines to follow
    Definition of fileset member line:
    <fileset.sub.-- member.sub.-- line> ::=
    F <member.sub.-- type> <sequence.sub.-- version.sub.--
    number>
    <file.sub.-- name>
    where:
    <member.sub.-- type> ::=
                    // file, container, symlink, or
    f c s o         // opaque
    Definition of object version line:
    <object.sub.-- version.sub.-- line> ::=
    O <sequence.sub.-- version.sub.-- number>
    Definition of reference line:
    <reference.sub.-- line> ::=
    R <reference.sub.-- flags> <ref.sub.-- handle>
    <reference.sub.-- Path>
    <sequence.sub.-- version.sub.-- number> <object.sub.-- type_name>
    [<sequence.sub.-- version.sub.-- uid>] [<object.sub.-- uid>]
    where:
    <reference.sub.-- flags> ::=
    <reference.sub.-- state><pathname.sub.-- type>
    <deferred><no.sub.-- uid><seq.sub.-- version.sub.-- uid.sub.-- valid>
    <reference.sub.-- state> ::-
                    // current (default), read-only
    c r f           // or fixed
    <pathname.sub.-- type> ::=
                    // hard, soft (default), in-
    h s m y         // memory, non-filesys
    <deferred> ::= d p
                    // deferred (default), non-
                    // deferred
    <no.sub.-- uid> ::= u n
                    // object uid present, no object
                    // uid (default)
    <seq.sub.-- version.sub.-- uid.sub.-- valid> ::= v i
                       // seq vers uid valid, no seq
                       // vers uid (default)
    <ref.sub.-- handle> ::= <unsigned>
    <reference.sub.-- Path> ::= <pathname>
    Definition of property line:
    <property.sub.-- line>::=
    P <property.sub.-- name> <property.sub.-- value>
    where:
    <property.sub.-- name> ::= <string>
    <property.sub.-- value> ::= <string>
    An example of the contents of an attribute file that corresponds
    to the definitions presented is given below:
    A 1 u Eddm.sub.-- sheet 4ed48f3l6000.0d.00.01.66.d0.00.00.00 1 2
    V v 1 1 4ed490809000.0d.00.01.66.d0.00.00.00 1
    P user Fred
    F f 1 sheet1.eddm.sub.-- 1
    O 1
    P date.sub.-- created 90/12/21
    R csduv 3 /idea/user/this/is/the/usual/path 2 Eddm.sub.-- part
    .backslash.4ed4908eb000.0d.00.01.66.d0.00.00.00
    4ed491c4d000.0d.00.01.66.d0.00.00.00
    ______________________________________

    ______________________________________
    <fileset specification> ::=
    <extension>!<occurrence>!member type>
    where:
    <extension> ::= <string>
                      // the leaf of the file
                      system pathname
    <occurrence> ::= kro
                    key, required or optional
    <member type> ::= fcs
                    file, container or symbolic link
    ______________________________________

                  APPENDIX A
    ______________________________________
    Glossary of Terms
    attributes
    Information associated with a design object to define
    its characteristics. Standard attributes define the
    object type and identity. Additional user.sub.-- defined
    attributes can be added to objects using properties for
    storing data and references for storing design
    associations.
    attribute file
    A special file contained within a design object used to
    store all attribute information about that design
    object. This information includes object type,
    identity (user ID), user.sub.-- defined properties, and design
    object references. An attribute file can be identified
    by its .attr suffix.
    behavior
    A design object has a behavior which is a set of
    operations that can be performed by the object. The
    basic set of operations that can be performed by all
    design objects is defined by a type named Ddms.sub.-- do.
    configuration
    A collection of design objects that describe a design.
    These objects can be related by containment and
    reference.
    configuration object
    A special type of design object that specifies how a
    configuration is built. A configuration object is
    versioned, it references primary and secondary design
    objects, and records build rules for each primary
    design object.
    contaiment hierarchy
    The organization of design objects held in containers.
    A container may hold containers which in turn may hold
    other containers, creating a hierarchy of container
    objects. A directory structure is a containment
    hierarchy because the system treats directories as
    containers by default.
    container
    A special design object for containing other desion
    objects. By default, the design management system
    treats file system directories as containers. File
    system containers enhance basic directory functionality
    because they are design objects which can have
    attributes attached to them.
    Design Data Configuration Management
    The process of managing configurations. Design Data
    Configuration Management performs tasks such as
    copying, moving, and releasing a design.
    Design Management Environment (DME)
    The name for all design management facilities including
    integrated design data configuration management,
    navigation, tool invocation, and the type registration.
    Design manager
    A graphical interface to the Design Management
    Environment. The Design manager provides access to
    design tools and data and allows a user to manage
    design configurations (collections of design objects).
    The Design Manager supports three primary tasks:
    design navigation, tool invocation, and design data
    configuration management.
    design object
    A typed collection or grouping of all the files
    representing some aspect of design data. The design
    object behavior is defined by its type. Using the
    design management system, a design object provides a
    single consistent entity that a user can operate on
    (e.g. invoke a tool, copy, move, release, . . .).
    encapsulation
    The process of integrating design tools or design data.
    Encapsulation controls how tools and data are used
    without affecting the tool or data itself.
    file
    A unit of storage, regardless of the form of the
    repository within which the unit of storage resides.
    fileset
    A collection of files which taken together comprises
    all aspects and versions of a design object.
    frozen version
    A version of a design object that cannot be deleted by
    the version depth mechanism. Frozen versions are used
    to save a particular version.
    instance
    An actual specimen of a particular type of design
    object.
    leaf
    A leaf is the name of the tool or data in the file
    system, without any pathname. For example, given the
    filename /usr/tmp/ginko/doc.sub.-- mgc, the leaf is doc.sub.-- pgc.
    navigation
    The process of traversing the containment hierarchy and
    reference structure of design objects. Using two
    windows, one can view both containers and references
    simultaneously.
    properties
    Attributes that store tool- and user-defined
    information about a design object or a reference.
    Properties consist of a name and a value. Examples
    include the name of the engineer assigned to the
    project paired with his phone extension, as in Joe
    Smith, ext. 2449, or the current release status of a
    design object paired with a release number. For
    example, Beta Release, 15.2.
    qualification script
    A program script that runs prior to invoking a tool.
    The purpose of the qualification script is to gather
    and evaluate tool arguments, validate tool invocation,
    and enforce workflow policies or procedures (if
    desired).
    references
    Attributes that describe an association between design
    objects. Both design tools and the user can create
    references. one can define a references to either an
    explicit version of a design object or the current
    version. Properties can be added to references to
    store information about the reference.
    registrar
    A tool used to register (declare) design tools and data
    with the Design Environment. One must register new
    tools and data with the type registry or the Design
    Manager will not recognize them. The Registrar is a
    graphical tool that does not require knowledge of C++
    to perform the registration process.
    registration
    The process of describing and defining information
    about how a design tool or data is encapsulated into
    the Design Environment. Registration is done with the
    registrar.
    registry
    A file that contains type definitions for design data
    objects and tool viewpoints.
    session window
    The outermost bounded area bordered by a rectangle box.
    It is within this area that one operates the Design
    Manager.
    termination script
    An optional program script that runs in the Design
    Manager session after the design tool has terminated
    its process. This script performs cleanup functions
    required by the design tool. The termination script
    also provides the Design Manager with essential
    configuration management information, when needed.
    tool
    Software created for a specific task. Examples of
    design tools include text editors and schematic
    editors. The Design Manager represents tools with
    icons.
    toolbox
    A container where tool viewpoints are kept. An
    arbitrary number of toolboxes can exist.
    toolbox search rule
    Specifies the order in which toolboxes are searched.
    The order determines which tool viewpoints are
    displayed in the Tool window. Given two tool
    viewpoints with the same name but in different
    toolboxes, the first tool viewpoint found is the one
    displayed.
    tool invocation
    The process of opening a tool. Both tool-centered
    (invoke the tool) and data-centered (open the data)
    methods of tool invocation are available using the
    Design Manager.
    tool viewpoint
    An encapsulation of a design tool that provides the
    user with a particular view of that tool. A tool
    viewpoint defines the manner in which a design tool is
    invoked and terminated. One can have multiple tool
    viewpoints to the same tool, each invoking the tool in
    a different way.
    type
    A description of the attributes of a data design object
    or tool viewpoint. Type information includes the file
    extensions for the files in the object and the icon
    used to display the object in the Design Manager.
    version
    A specific representation of a design object at a
    specific point in time. If one changes a design
    object's data and saves it to disk, one creates a new
    version of the design object.
    version depth
    A design object attribute that specifies the number of
    versions, including the current version, that are kept
    after changes are made to the data Detl Dscrp Buffer Contains An Invalid
    Char: <(see version).
    Version depth can be set from one to infinity.
    versioned object
    An object that uses a copy-on-write file manager. When
    saved to disk, a versioned object creates a new version
    of itself, saving the previous version.
    termination script
    A program script that runs after the design tool has
    terminated its process. This script performs cleanup
    functions required by the design tool. The termination
    script also provides the Design Manager with essential
    configuration management information, when needed.
    ______________________________________


              APPENDIX B
    ______________________________________
    Operations Defining Design Object Behavior
    ______________________________________
    Naming operations:
    uido;
    // Return the Id of this object.
    name( );
    // Return the name of this object.
    do.sub.-- pathname( );
    // Return the full design object pathname of this object.
    type( );
    // Return this object's type.
    Fileset Management:
    fileset.sub.-- size( );
    // Return the number of files in this object's fileset.
    file( );
    // Return the name of a file in the design object's file
    set.
    // file.sub.-- mode( );
    // Return the file mode (key, required, optional) for the
    requested file.
    file.sub.-- type( );
    // Return the file type (container, file, link) for the
    requested file.
    fileset.sub.-- Member( );
    // Return a file object for a requested file.
    complete .sub.-- fileset( );
    // Get a file objects for all files in the fileset.
    size( );
    // Return the size of the object in persistent store.
    Containment:
    do.sub.-- container( );
    // Return the container which holds this design object.
    is.sub.-- container( );
    // Test for whether this object can physically contain other
    objects.
    object.sub.-- entry.sub.-- names( );
    // Return name and type information about all contained
    objects.
    check.sub.-- conflict( );
    // Check the given container for conflicts with the new
    object.
    Session support:
    lock( );
    // Get a lock for this design object.
    lock.sub.-- as( );
    // Generate a new persistent object with a new name and
    grab a lock.
    locked( );
    // Return the state of the design object lock.
    unlock( );
    // Remove the lock for this design object.
    lock.sub.-- type( );
    // Return the lock type (exclusive, shared) for this object.
    lock .sub.-- .sub.-- mode( );
    // Return the lock mode (create version, annotate, no
    modify).
    lock.sub.-- mode( );
    // Set the lock mode for this object.
    lock.sub.-- location( );
    // Get a lock for a design object at the requested location.
    unlock.sub.-- location( );
    // Unlock a lock obtained from lock.sub.-- location( ).
    resync( );
    // Update this in.sub.-- memory image to the true current version.
    save( );
    // Make the private session part of the design object
    public.
    forget( );
    // Forget the session part of the design object.
    repair( );
    // Attempt to repair any damage to this object.
    Initialization:
    constructor( );
    // Create a new object.
    connect( );
    // Connect (initialize) another object.
    disconnect( );
    // Remove from memory.
    initialize( );
    // Fully initialize the design object.
    do.sub.-- initialize( );
    // Initialize the design object for basic design object
    operations.
    pre.sub.-- initialize( );
    // Set up required state for required for base
    implementations to work.
    Versions:
    version.sub.-- depth( );
    // Return the value for the version depth attribute.
    version.sub.-- depth( );
    // Set the value for the version depth attribute.
    apply.sub.-- version.sub.-- depth( );
    // Try to apply version depth pruning.
    sequence.sub.-- version( );
    // Return a sequence version record for this instance.
    create.sub.-- seq.sub.-- version( );
    // Create the next sequence.sub.-- version of this object.
    next.sub.-- sequence.sub.-- version( );
    // Return the next sequence version following the given
    sequence version.
    prev.sub.-- sequence.sub.-- version( )
    // Return the.sub.-- sequence version immediately preceding the
    given version.
    delete.sub.-- sequence.sub.-- version( );
    // Delete the given sequence version.
    revert( );
    // Roll the design object back one sequence version.
    check.sub.-- sequence.sub.-- version( );
    // Check to ensure that the data for the specified version
    still exists.
    current.sub.-- sequence.sub.-- number( );
    // Return id information about this object's current
    sequence version.
    set.sub.-- design.sub.-- object.sub.-- version( );
    // Set the version number of the current version of the
    design object.
    Reference:
    reference( );
    // Query for a reference record.
    add.sub.-- reference( );
    // Add a reference to this design object.
    reference.sub.-- object( );
    // Return a Ref (persistent pointer) for the referenced
    design object.
    virtual void remove.sub.-- reference( );
    // Remove the specified reference from the reference list.
    change.sub.-- references( );
    // Change Uids and pathnames of references held by this
    object.
    next.sub.-- reference( );
    // Return the next reference following the given reference.
    prev .sub.-- reference( );
    // Return the reference preceding the given reference.
    Design Management support:
    copy( );
    // Copy a sequence version of this design object.
    copy.sub.-- all( );
    // Copy this design object.
    move( );
    // Move this design object.
    dtor( );
    // Destroy this object.
    freeze( );
    // Freeze the specified sequence version.
    unfreeze( );
    // Unfreeze the specified sequence version.
    frozen( );
    // TRUE if this sequence version is frozen.
    released( );
    // TRUE if this instance is released.
    release( );
    // Set this object's release state.
    Miscellaneous:
    get.sub.-- protection( );
    // Return the protections for the specified design object.
    set.sub.-- protection( );
    // Set the file system protections for the specified design
    object.
    modified.sub.-- time( );
    // Time when the object's data was last modified.
    exists( );
    // Check if the specified design object exists.
    complete( );
    // Check if this object has all the requisite pieces.
    ______________________________________

• Inventors
  Voll, Robert; Berg, William C.; Sergent, Brad; Stevens, Sam;
• Assignee
  Mentor Graphics Corporation (Wilsonville, OR)
• Published
  Aug-27-1996
• Current US Classes:
  700/182
  707/103R
  707/104.1
• Application #
  396336
• International Classes
  G06F 017/30
• Field of Search
  395/600 364/474.24 364/490 364/491
• Examiner
  Black; Thomas G.
• Agent
  Klarquist, Sparkman, Campbell, Leigh & Whinston
• US Patent References:
  4357635
  4558413
  4939507
  5050105
  5162992
  5212792