Design and Implementation of Graphics Applications using Object-Oriented Techniques in C++

Part 1: Tactics, strategies and vision

Summary

The aim of this article is to present new developments in the area of applying object-oriented technology to designing and implementing software systems for computer graphics and Computer Aided Design (CAD) applications. In particular, we use C++ to create graphical and numerical building blocks which can then be assembled to form portable, flexible and cost-effective solutions to a number of real-life problems where graphics plays an essential role.
This article concludes with a preview of the articles which will appear in the X Advisor in 1996 and which deal in more detail with the topics presented here.

In order to give a feeling for future articles we concentrate on Computer Aided Design (CAD) problems. Future articles will concentrate on other aspects of computer graphics.

 

Introduction and Objectives

C++ is becoming the language of choice for many applications. One of the reasons for its success is that it is compatible with C. This means that new applications which need to be written in C++ can use old-style C libraries and software without having to do a rewrite. In fact, C++ can be used as a 'better C' by using the improved syntax style and type checking features. But C++ can also be used to write object-oriented applications, thus offering programmers and organisations many advantages, such as:

 

In this article we shall be concentrating on applying C++ to applications where graphics and presentation issues play an important role. Most graphics applications at the present time are written in C (see for example, the series of books in the Graphics Gems series from Academic Press) while C++ is slowly beginning to make inroads in certain places. We shall see a gradual transition to C++ in the coming years as the developer community becomes acquainted with the object-oriented paradigm.

Many of the successful graphics and CAD packages in the marketplace date from the 1970's and 1980's. Most of these were developed in procedural languages such as C, Pascal or Fortran and the design and implementation usually consisted of some kind of top-down process decomposition approach. The resulting products were difficult to extend and to maintain; furthermore, it took a lot of effort to extract and reuse parts of such systems, mainly due to the fact that potentially reusable designs and code were interwoven with the contexts in which the software was to operate. The only alternative to copying the code and editing it to suit the new situation was to do a complete rewrite. This resulted in much code duplication, longer lead times and missed opportunities.

The advent of the object-oriented paradigm (and C++ in particular) allows us to create applications which can be easily customised, extended and reused in a changing world. Customers are demanding applications which be easily plugged into other applications. We see this trend in the form of Object Request Brokers (Orbs), OLE and other interoperability standards. In other words, no longer will we have to deal with large and inflexible programs but instead we shall be able to buy software components from different vendors and where we can combine these components to create applications which suit our own needs. This will be achieved by applying object-oriented and interoperability standards to application development. To this end, it is our intention to shed some light on these issues in this and future articles in this journal. These are based on the author's experiences in C++, CAD and computer graphics.
We discuss the following important issues:

 

The advantages of using this approach lie in the areas of improved software, shorter lead times (due to the reusability of C++ classes) and better customer satisfaction. Furthermore, it fosters an engineering frame of mind in the sense that software development places more emphasis on analysing and comprehending a given problem domain and less on the low-level programming details. This is not to say that C++ is not important. Organisations wishing to take advantage of the benefits of object-oriented technology should be warned however, that they must prepare themselves well for the transition from a procedural frame of mind to one where concepts and domain knowledge are the most important parts of the software lifecycle.

 

The Problems Facing Computer Aided Design (CAD)

Computer Aided Design (CAD) originated in the 1960's and its use was mainly confined to those companies which could afford to purchase mainframe computers and the corresponding peripherals such as plotters, high-resolution terminals and of course the CAD software which allowed the engineer to create a design. A typical single-user station could cost anything from 0.5 million dollars to 4 million dollars. Interfaces between the CAD software and other applications (such as those for manufacturing (CAM) and finite element stress programs (FEM)) were written on a one-off basis. This meant that proprietary product data exchange translators needed to be written between each pair of applications. The main problem with this type of translator is that in a system of n applications n(n-1) interface programs are needed. Furthermore, changes in the data format of one application (new data types added, new structure etc) implied that all the interfaces using that application needed to be modified and retested. The alternative to this ad-hoc strategy is to create a public domain neutral intermediate format. Each CAD system vendor should then provide a so-called pre-processor for writing this neutral file and a post-processor for reading from the neutral file. This is an improvement to the first strategy since in a system on n applications only 2n interfaces need to be written. There are a number of industry-standard neutral file formats in widespread use, such as IGES, VDA and SET. There are also a number of vendor-specific specifications, of which AutoCAD's DXF is probably the most popular.
Neutral formats provide their own set of problems. The main ones are:

 

With the advent of virtual memory machines (such as Prime and VAX systems) the situation did not improve very much and engineering operations still had to write and maintain these interfaces. The advent of suitable network protocols such as DECnet and TCP/IP only meant that data could be copied from one machine to another one but the problem of interoperability between applications still remained.
In order to solve many of the problems associated with both direct translators and neutral file formats a meeting was held in Washington DC in July 1984 and it was here that the ISO TC184/SC4 was born which was later to become the STEP standard. The architecture of STEP is based on the ANSI/SPARC standard (see [Tsichritzis78]) and consists of the following layers or levels:

 

This approach has the advantage that it allows multiple views and implementations for an application to be defined. This is equivalent to the separation of concerns principle which can be found in the works of the computer scientists Parnas and Dijkstra and which has been implemented as the Model View Controller (MVC) in languages such as Smalltalk and C++ (see [Duffy95], [Duffy96]). The general principle is starting to find its way into object-oriented software development and progress has been made to generalize the principle so that it also works in the design phase of the software lifecycle (see [Cowan95]). Thus, the principles underlying the STEP standard are compatible with emerging techniques for object-oriented software construction. In particular, the layering approach promotes portability and allows complex applications to be developed in a manageable fashion. Another advantage of this approach is that it allows interoperable applications to be constructed due to the encapsulation between the different layers (see [Zweben95]).

There is nothing sacred about partitioning an application into 3 layers as above. Some systems use a 5-layer strategy (such as CADObject, a reusable C++ class library which was designed in our company) while 4-layer schemes are also common. The CADObject 5-layer schema consists of more than 400 C++ classes and it was found necessary to create a 'uses' hierarchy in order to manage complexity and also to ensure that the system is as flexible as possible. The uses hierarchy is set up as a client-server system with classes at the higher levels using the services of classes at lower levels. Furthermore, it is possible to integrate CADObject with other applications because of the neutral policy adopted. Layer 5 is the only layer that has to be modified in such a way that interoperability is achieved.
Many companies are beginning to realize that OOT offers many advantages for software development for CAD. Contrary to popular belief, writing software for CAD is difficult because attention needs to be paid to a number of areas such as the construction and manipulation of geometric and non-geometric objects, their representation and user interactions with the system. Furthermore, complex mathematical algorithms need to be designed and integrated into the application. It is important to separate the application from its environment (which is volatile). The main volatile elements in an application are typically:

 

The reason that we wish to have this separation of concerns is that applications need to work under different types of hardware and software environments. In order to achieve these ends, we apply the MVC paradigm or one of its variations. This can be done in C++ by using the so-called multiple polymorphism principle (see [Duffy95]) or by the creation of abstract data views and abstract data objects (see [Cowan95]). A number of major CAD vendors are already working on object-oriented versions of their products. For example, AutoDesk has released its object-oriented version of the popular CAD system AutoCAD and it is be possible to create drawing with in-built 'intelligence' which is made possible by the fact that its CAD drawings contain embedded objects.

 

Software Development and AutoCAD

AutoCAD is a CAD package which emerged in the 1980's as a PC product. The package allowed the programmer to customize it according to his own specific needs. The language chosen was called AutoLisp, a dialect of the artificial intelligence language Lisp. The advantage of using AutoLisp lies in the fact that it interfaces directly with the AutoCAD drawing database and that results can immediately be visualised. The disadvantages of AutoLisp are:

 

For these (and other) reasons we shall see a shift from AutoLisp-based applications to those which are developed in C and C++. To this end, Autodesk has already introduced the ADS library (AutoCAD Development System) which allows developers to write applications in C for AutoCAD. The library works well; however, since C is not object-oriented it takes a long time to write, test and debug applications using this system. Furthermore, since the library is written in C and all its functions use C-syntax it takes quite a while for AutoLisp programmers to get use to it. In particular, memory management in C is not automatic (as it is in AutoLisp where garbage collection takes place) and it is the responsibility of the programmer to perform his own memory allocation and deallocation. This can lead to many errors and problems.
In order to overcome the problems with C, we advocate using C++ in future applications work. Since C++ is an extension of C we do not have to throw away code that had previously been written in C. Instead, new applications in C++ can incorporate these 'legacy' systems into them by creating so-called wrappers which hide much low-level detail. We see that C++ is being taken seriously when we look at the upcoming versions of AutoCAD (starting with version 13) in which object-oriented techniques play a crucial role. Autodesk is providing suites of C++ building blocks which can be used by developers in order to speed up development. Our own company has produced 'CADObject', a C++ class library which can be used on top of AutoCAD and which enables the software developer to build extensible applications for mechanical and electrical engineering, the process industry and facilities management.

 

Design Issues

One of the weaknesses in current object-oriented technology is that there is little awareness of what constitutes good C++ design. Most books on C++ concentrate on the 'grunge' details of C++ syntax while at the same time they tend to neglect important design issues such as robustness, portability and efficiency. Books on analysis, on the other hand tend to concentrate on more theoretical issues with the result that they lose their relevance when applied to real-life problems. In short, there is a gap between the analysis and implementation phases of the software lifecycle and this needs to be bridged. In order to bridge this gap, we can take a number of measures. First, since OO is relatively new, a lot of people are under the impression that they have to reinvent the wheel all over again. We must not forget that OO is not an end in itself but is just one set of techniques which help us (if applied properly) produce better software. Design techniques which originated in the works of Parnas, Dijkstra and others should and can be applied to solving problems using C++. Furthermore, a number of books have appeared which help us solve real-life problems. We discuss many of these issues in the forthcoming articles.

 

The advantages of C++

The main advantages of using C++ as opposed to C or AutoLisp lie in the support it offers for writing classes. Once a class is written it can be used in many different applications without change. In other words, we do not have to reinvent the wheel by copying chunks of code, modifying it and then retesting. The classes can be used without any change whatsoever! Furthermore, code written in C++ tends to be more easily maintained than code which is written in non-object oriented languages.
C++ is fast becoming the de facto standard programming language. The compiler runs on many different hardware platforms and high-schools and universities are training students in its use. In this sense we can expect a good supply of well-trained software engineers and programmers who are able to write C++ applications for AutoCAD.

 

Migrating to C++

We have stated that C++ offers many advantages to the software developer. These advantages come at a price, however. Learning C++ is easy for the C programmer but applying it correctly and efficiently requires a different way of thinking about problem-solving than how you would do it in AutoLisp. It takes about 2 years before you start to get the hang of it! In order to use C++ effectively, we propose the following migration plan:

 

Furthermore, you need a 'champion' in the organisation who is convinced that object-oriented technology is the way to go and who has the full support of management. The real benefits of using C++ will become clear after the first project has been finished when classes can be stored for reuse in later projects.

Object-oriented is here to stay and it is bound to become the standard computing paradigm; the choice is up to you, either you start moving to C++ or you will be left with outdated and inflexible products in two to three years time.

 

A preview of the forthcoming articles

This article serves as the starting point for a series or articles in which we develop our ideas for creating graphics applications using C++. Each article devotes attention to one particular application area and to a number of software techniques which we think are useful. In particular, the articles will cover the following issues:

 

The articles will deal with the following design, implementation and application issues:

 

Conclusions

C++ is becoming the language of choice for graphics applications and we discussed some of the trends taking place in this field. We shall see the emergence of graphics applications which consist of pluggable components and which can easily be customised to suit specific situations. In this way we hope to see the industry maturing from one in which monolithic and inflexible systems will gradually be replaced by interoperable component technology.

 

About the author

Daniel J. Duffy works for Datasim BV, Amsterdam and has been involved in software development using C++ for CAD and computer graphics applications since 1989. He has a Ph.d. in numerical mathematics from Trinity College, Dublin and is chief architect of CADObject(2d, 3d), a portable toolkit library consisting of 600 C++ classes for two-dimensional and three-dimensional graphics applications. He may be reached at dduffy@datasim.nl.

Daniel Duffy has been working in the IT industry since 1979. His interests lie in applying the object-oriented paradigm to engineering and scientific problems.

 

References

  1. [CADObject95] Datasim BV CADObject User's Manual version 3.0 1996.
  2. [Cowan95] D. D. Cowan, C. J. P. Lucena "Abstract Data Views: An Interface Specification Concept to Enhance Design for Reuse", IEEE Transactions on Software Engineering March 1995.
  3. [Duffy95] Daniel J. Duffy "From Chaos to Classes - Software Development in C++", McGraw-Hill London 1995.
  4. [Duffy96] Daniel J. Duffy "Quality Applications in C++", SIGS Publishing New York 1996.
  5. [Foley87] J. D. Foley et al "Computer Graphics - Principles and Practice", Addison Wesley Reading MA 1987.
  6. [Gamma95] E. Gamma et al "Design Patterns - Elements of Reusable Object-Oriented Software", Addison-Wesley Publishing Company 1995.
  7. [Neider93] J. Neider et al "OpenGL Programming Guide", Addison-Wesley Reading MA 1993.
  8. [OpenGL92] The OpenGL Architecture review Board "OpenGL Reference Manual", Addison Wesley Reading MA 1992.
  9. [Peterson94] J. W. Peterson "Tessellation of NURB Surfaces", in Graphics Gems I, edited by Paul S. Heckbert, Academic Press Boston USA 1994.
  10. [Strauss93] P. S. Strauss "IRIS Inventor, a 3D graphics toolkit", in Object-Oriented Programming Systems, Languages and Applications, Conference Proceedings, pp. 192-200, Washington D.C., September 1993 ACM Press.
  11. [Tsichritzis78] D. Tsichritzis, A. Klug (eds) "The ANSI/X3/SPARC DBMS framework: report of the study group on database management systems", Information Systems, Volume 3 (173-191), Pergamon Press Oxford UK 1978.
  12. [Watt89] A. Watt "Fundamentals of Three-Dimensional Computer Graphics", Addison-Wesley Wokingham UK 1989.
  13. [Wilt94] N. Wilt "Object-Oriented Ray Tracing in C++", John Wiley & Sons, New York 1994.
  14. [Zweben95] S. H. Zweben, S. H. Edwards, B. W. Weide, J. E. Hollingsworth "The Effects of Layering and Encapsulation on Software Development Cost and Quality" IEEE Transactions on Software Engineering March 1995.

 

[ Homepage | Articles ]