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.
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.
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.
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.
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 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.
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.
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:
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.
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.