Skip to main content
main-content

Über dieses Buch

Computer-aided design syst,ems have become a big business. Advances in technology have made it commercially feasible to place a powerful engineering workstation on every designer's desk. A major selling point for these workstations is the computer­ aided design software they provide, rather than the actual hardware. The trade magazines are full of advertisements promising full menu design systems, complete with an integrated database (preferably "relational"). What does it all mean? This book focuses on the critical issues of managing the information about a large design project. While undeniably one of the most important areas of CAD, it is also one of the least understood. Merely glueing a database system to a set of existing tools is not a solution. Several additional system components must be built to create a true design management system. These are described in this book. The book has been written from the viewpoint of how and when to apply database technology to the problems encountered by builders of computer-aided design systems. Design systems provide an excellent environment for discovering how far we can generalize the existing database concepts for non-commercial applications. This has emerged as a major new challenge for database system research. We have attem­ pted to avoid a "database egocentric" view by pointing out where existing database technology is inappropriate for design systems, at least given the current state of the database art. Acknowledgements.

Inhaltsverzeichnis

Frontmatter

1. Computer-Aided Design Tools and Systems

Abstract
Creating large, complex systems is one of the most demanding tasks undertaken by humankind. To design a state-of-the-art microcomputer, a high performance computer system, a modern petroleum refinery, or a supersonic jetliner requires the talents of a large number of individuals (e.g., engineers, managers, technicians), coordinated into a team, making extensive use of sophisticated tools to complete the job. Much of what is designed today could not even be attempted without the pervasive use of computers. Computers automatically generate portions of the design, check the correctness of hand generated portions, and keep track of the data describing the design, especially as it evolves over time.
Randy H. Katz

2. Survey of Engineering Design Applications

Abstract
Before discussing the kinds of engineering data found in the design environment in the next chapter, we first review the unique systems requirements for effective engineering data management. While existing database systems provide many of the needed facilities, they by no means provide them all. Database systems have evolved to provide excellent support for commercial data processing applications, but engineering design applications are not quite the same. One of the great challenges to the database research community is to understand how existing database techniques can be applied, refined, or generalized for the engineering design environment.
Randy H. Katz

3. Design Data Structure

Abstract
In this chapter, we will examine different ways of describing the representational and structural details of a design. Since the representational details are typically domain specific, we will limit the discussion to one design domain, namely VLSI design. We then describe several proposed and implemented design data models. These provide structures for organizing the design description within and across representations, for incorporating interface specifications, and for representing design versions and alternatives. A more detailed description of one such model, the Object Data Model, will be presented in the next chapter.
Randy H. Katz

4. The Object Model

Abstract
In this chapter, we give a detailed description of a semantic data model for design data called the Object Model. It defines the basic primitives from which the design data structure is formed. As we have seen in the previous chapter, many different schemes are possible, but similar themes are readily apparent. These include: (1) an applications interface based on the manipulation of “objects”, which are structured collections of data, rather than individual records; (2) explicit support for design alternatives and versions, with operations to access the design description at a particular point in time; and (3) the critical importance of interface descriptions as a part of the design description. The objective of the Object Model is to make the design as self describing as possible, thus enabling the design management system to assist in keeping its description consistent. It is interesting to note that a new draft standard interchange language, called EDIF (Electronic Design Interchange Format), is just beginning to emerge from the CAD system community, and bears a strong resemblance to the model presented in this chapter.
Randy H. Katz

5. Design Transaction Management

Abstract
A transaction is a sequence of operations that together perform a unit of work, and leave the database in a consistent state. A set of constraints are in force at the beginning of the transaction and again at its end, but they are not enforced during the lifetime of the transaction. A key difference between the design environment and a conventional database environment is that the definition of design self-consistency is significantly more complex. For example, an airplane design is “consistent” only if the airplane can still fly with its redesigned wing. In general, these constraints can only be guaranteed by invoking complicated checking programs such as simulation tools.
Randy H. Katz

6. Design Management System Architecture

Abstract
A central theme of this book is that an integrated design database is needed before a collection of design tools can be forged into a truly integrated design system. In this chapter, we present an architecture for a prototype design management system. Recall that a design management system is much more than a database system: it is responsible for choosing the data structure for representing the design and for providing an appropriate interface to this structure for design tools. The structures of the system’s storage, recovery, concurrency control, and design validation subsystems are described. Special applications programs that manipulate the structure of the design, a design browser and a system assembler, are also discussed.
Randy H. Katz

7. Conclusions

Abstract
Design databases, as viewed from a database systems perspective, are still a relatively unexplored territory. In this subsection, we discuss a number of database techniques that could apply to data management problems in the design environment if they are suitably generalized.
Randy H. Katz

8. Annotated Bibliography

Without Abstract
Randy H. Katz
Weitere Informationen