1

SLMINAk CN
Design and Implementation of Graphics Applications in
Mechanical Engineering using Object-Oriented
Techniques in C++
ZC?A 8lZvl /ML CAu/CAM 8oll no 130
Sub[ecL CCS uaLe 24/10/2011


1.1 INTRODUCTION & OB1ECTIVES
The aim oI this seminar is to present new developments in the area oI applying
object-oriented technology oI C to designing and implementing soItware
systems Ior computer graphics and Computer Aided Design (CAD) applications in
mechanical engineering. In particular, we use C to create graphical and
numerical building blocks which can then be assembled to Iorm portable, Ilexible
and cost-eIIective solutions to a number oI real-liIe problems where graphics plays
an essential role.
C is becoming the language oI choice Ior many applications. One oI the reasons
Ior 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 soItware without
having to do a rewrite. In Iact, C can be used as a 'better C' by using the
improved syntax style and type checking Ieatures. But C can also be used to
write object-oriented applications, thus oIIering programmers and organisations
many advantages, such as:
O Improved soItware quality.
O $horter lead times.
O ore reusable soItware.
O $atisIied customers.
In this seminar we shall be concentrating on applying C to applications where
graphics and presentation issues play an important role. ost graphics applications
at the present time are written in C (see Ior example, the series oI books in the
Graphics Gems series Irom 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.
2

any oI the successIul graphics and CAD packages in the marketplace date Irom
the 1970's and 1980's. ost oI these were developed in procedural languages such
as C, Pascal or Fortran and the design and implementation usually consisted oI
some kind oI top-down process decomposition approach. The resulting products
were diIIicult to extend and to maintain; Iurthermore, it took a lot oI eIIort to
extract and reuse parts oI such systems, mainly due to the Iact that potentially
reusable designs and code were interwoven with the contexts in which the soItware
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 oI 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 Iorm oI Object Request Brokers
(Orbs), OLE(Object linking and embedding) and other interoperability standards.
In other words, no longer will we have to deal with large and inIlexible programs
but instead we shall be able to buy soItware components Irom diIIerent 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. These are based on the s experiences in
C, CAD and computer graphics.

We discuss the Iollowing important issues:
O Creating truly reusable class libraries and components in C
O &sing C to create interesting real-liIe applications
O Applying object-oriented analysis and design techniques to improve quality

The advantages oI using this approach lie in the areas oI improved soItware,
shorter lead times (due to the reusability oI C classes) and better customer
satisIaction. Furthermore, it Iosters an engineering Irame oI mind in the sense that
soItware 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 oI the
beneIits oI object-oriented technology should be warned however, that they must
prepare themselves well Ior the transition Irom a procedural Irame oI mind to one
where concepts and domain knowledge are the most important parts oI the
soItware liIecycle.

3

1.2 PROBLEMS FACED BY CAD
Computer Aided Design (CAD) originated in the 1960's and its use was mainly
conIined to those companies which could aIIord to purchase mainIrame computers
and the corresponding peripherals such as plotters, high-resolution terminals and oI
course the CAD soItware which allowed the engineer to create a design. A typical
single-user station could cost anything Irom 0.5 million dollars to 4 million dollars.
InterIaces between the CAD soItware and other applications (such as those Ior
manuIacturing (CA) and Iinite element stress programs (FE)) were written on
a one-oII basis. This meant that proprietary product data exchange translators
needed to be written between each pair oI applications. The main problem with this
type oI translator is that in a system oI n applications n(n-1) interIace programs are
needed. Furthermore, changes in the data Iormat oI one application (new data types
added, new structure etc) implied that all the interIaces using that application
needed to be modiIied and retested. The alternative to this ad-hoc strategy is to
create a public domain neutral intermediate Iormat. Each CAD system vendor
should then provide a so-called pre-processor Ior writing this neutral Iile and a
post-processor Ior reading Irom the neutral Iile. This is an improvement to the Iirst
strategy since in a system on n applications only 2n interIaces need to be written.
There are a number oI industry-standard neutral Iile Iormats in widespread use,
such as IGE$, VDA and $ET. There are also a number oI vendor-speciIic
speciIications, oI which AutoCAD's DXF is probably the most popular.
Neutral Iormats provide their own set oI problems. The main ones are:
O It takes time to develop them.
O They usually to restrictive standards; CAD systems outgrow the standard
very quickly.
O They do not cover all issues in all CAD systems.
O They are not as eIIicient as direct translators and loss oI inIormation can
occur.

With the advent oI 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 interIaces. The advent oI suitable network protocols such as
DECnet and TCP/IP only meant that data could be copied Irom one machine to
another one but the problem oI interoperability between applications still
remained.
In order to solve many oI the problems associated with both direct translators and
neutral Iile Iormats a meeting was held in Washington DC in July 1984 and it was
here that the I$O TC184/$C4 was born which was later to become the $TEP
standard. The architecture oI $TEP is based on the AN$I/$PARC standard and
consists oI the Iollowing layers or levels:
4

O The External Level: this is the layer which represents the inIormation
relevant to a speciIic application. This corresponds to the application and
how it is viewed.
O The Conceptual Level: this layer contains the inIormation which describes
the domain under discussion.
O The Internal Level: the layer which is responsible Ior implementing the
conceptual scheme. This usually takes the Iorm oI a computer Iile system.

This approach has the advantage that it allows multiple views and implementations
Ior an application to be deIined. This is equivalent to the separation oI concerns
principle which can be Iound in the works oI the computer scientists Parnas and
Dijkstra and which has been implemented as the odel View Controller (VC) in
languages such as $malltalk and C. The general principle is starting to Iind its
way into object-oriented soItware development and progress has been made to
generalize the principle so that it also works in the design phase oI the soItware
liIecycle. Thus, the principles underlying the $TEP standard are compatible with
emerging techniques Ior object-oriented soItware construction. In particular, the
layering approach promotes portability and allows complex applications to be
developed in a manageable Iashion. Another advantage oI this approach is that it
allows interoperable applications to be constructed due to the encapsulation
between the diIIerent layers.
There is nothing sacred about partitioning an application into 3 layers as above.
$ome 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 oI more than 400 C classes
and it was Iound necessary to create a 'uses' hierarchy in order to manage
complexity and also to ensure that the system is as Ilexible as possible. The uses
hierarchy is set up as a client-server system with classes at the higher levels using
the services oI classes at lower levels. Furthermore, it is possible to integrate
CADObject with other applications because oI the neutral policy adopted. Layer 5
is the only layer that has to be modiIied in such a way that interoperability is
achieved.
any companies are beginning to realize that OOP oIIers many advantages Ior
soItware development Ior CAD. Contrary to popular belieI, writing soItware Ior
CAD is diIIicult because attention needs to be paid to a number oI areas such as
the construction and manipulation oI 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 Irom its environment (which is volatile).
The main volatile elements in an application are typically:
O The user interIaces (Windows, DO$, otiI)


O The underlying database (RDB$, ODB$, proprietary)
O The algorithms and data structures being used in the application.
The reason that we wish to have this separation oI concerns is that applications
need to work under diIIerent types oI hardware and soItware environments. In
order to achieve these ends, we apply the VC paradigm or one oI its variations.
This can be done in C by using the so-called multiple polymorphism principle or
by the creation oI abstract data views and abstract data objects. A number oI major
CAD vendors are already working on object-oriented versions oI their products.
For example, AutoDesk has released its object-oriented version oI the popular
CAD system AutoCAD and it is be possible to create drawing with in-built
'intelligence' which is made possible by the Iact that its CAD drawings contain
embedded objects.
1.3 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 speciIic
needs. The language chosen was called AutoLisp, a dialect oI the artiIicial
intelligence language Lisp. The advantage oI using AutoLisp lies in the Iact that it
interIaces directly with the AutoCAD drawing database and that results can
immediately be visualised. The disadvantages oI AutoLisp are:
O It is proprietary to AutoCAD; it cannot be used outside AutoCAD.
O It is diIIicult to Iind programmers with AutoLisp experience.
O It is not object-oriented.
or Lhese (and oLher) reasons we shall see a shlfL from AuLoLlspbased
appllcaLlons Lo Lhose whlch are developed ln C and C++ 1o Lhls end AuLodesk
has alread lnLroduced Lhe AuS llbrar (AuLoCAu uevelopmenL SsLem) whlch
allows developers Lo wrlLe appllcaLlons ln C for AuLoCAu 1he llbrar works
well however slnce C ls noL ob[ecLorlenLed lL Lakes a long Llme Lo wrlLe LesL
and debug appllcaLlons uslng Lhls ssLem urLhermore slnce Lhe llbrar ls
wrlLLen ln C and all lLs funcLlons use CsnLax lL Lakes qulLe a whlle for AuLoLlsp
programmers Lo geL use Lo lL ln parLlcular memor managemenL ln C ls noL
auLomaLlc (as lL ls ln AuLoLlsp where garbage collecLlon Lakes place) and lL ls
Lhe responslblllL of Lhe programmer Lo perform hls own memor allocaLlon
and deallocaLlon 1hls can lead Lo man errors and problems
ln order Lo overcome Lhe problems wlLh C we advocaLe uslng C++ ln fuLure
appllcaLlons work Slnce C++ ls an exLenslon of C we do noL have Lo Lhrow
awa code LhaL had prevlousl been wrlLLen ln C lnsLead new appllcaLlons ln
C++ can lncorporaLe Lhese legac ssLems lnLo Lhem b creaLlng socalled
wrappers whlch hlde much lowlevel deLall We see LhaL C++ ls belng Laken


serlousl when we look aL Lhe upcomlng verslons of AuLoCAu (sLarLlng wlLh
verslon 13) ln whlch ob[ecLorlenLed Lechnlques pla a cruclal role AuLodesk ls
provldlng sulLes of C++ bulldlng blocks whlch can be used b developers ln
order Lo speed up developmenL A C++ class llbrar whlch can be used on Lop
of AuLoCAu and whlch enables Lhe sofLware developer Lo bulld exLenslble
appllcaLlons for mechanlcal and elecLrlcal englneerlng Lhe process lndusLr
and faclllLles managemenL
1.4 PROGRAMMING USING CLASS IN AUTOCAD
AutoCad can be reprogrammed by its AutoLisp Language. You can customize your
commands and menus.
DXF_overview

DXF stands for Drawing Interchange Format. A subset of the AutoCad containing
only block reference, attribute, and end-of-sequence objects. This can be read in
any text editor. The primary purpose of the dxf files are to be used in
CNC (Computer Numerical Control) machines. These are only AutoCad file extension
that
CNC machine database can read. This is very much useful to the companies which
are_using_CAD/CAM .

First create a simple class :
01 class CreateDxf
2 ,
03 public:
04 CreateDxf();
05 ~CreateDxf();
06
07
08 void DxfBegin ();
09 void DxfEnd ();
10 // you can add more functions to create more drawings.
11 void Circle(float,float,float);
12 ,;
mplementation of the class CreateDxf with its comments:

01 CreateDxf::~CreateDxf()
02 ,


03
cout <<"Destructor called..." << endl;
04

05 ,
06
void CreateDxf::DxfBegin ()
07 ,
08 // Creation of an output stream object in text mode.
09 // Header section of every dxf file.
10 ofstream To_Dxf ("Drawing1.dxf", ios::out);
11

12 To_Dxf << 0 << endl;
13
To_Dxf << "SECTIJN" << endl;
14 To_Dxf << 2 << endl;
15
To_Dxf << "ENTITIES" << endl;
16

17 To_Dxf.close();
18 ,
19
void CreateDxf::DxfEnd ()
20 ,
21 // Creation of an output stream objet in text mode.
22 // end of sequence objects of dxf file.
23 ofstream To_Dxf ("Drawing1.dxf", ios::app);
24

25 To_Dxf << 0 << endl;
26
To_Dxf << "ENDSEC" << endl;
27 To_Dxf << 0 << endl;
28 To_Dxf << "EJF";
29

30 To_Dxf.close();
31 ,
32

33
void CreateDxf::Circle (float radius, float x, float y)
34 ,
35 // Propeties of a circle not bound in any AutoCAd version
36 //In AutoCAD 2000 we can have more less 4000 lines of code here.
37

38 // Creation of an output stream objet in text mode.
39

40 ofstream To_Dxf ("Drawing1.dxf", ios::app);
41

42 // Draw the circle
43 To_Dxf << 0 << endl;
44
To_Dxf << "CIRCLE" << endl;
45 To_Dxf << 8 << endl;


46
To_Dxf << 0 << endl; // Layer number (default layer in
autocad)
47 To_Dxf << 10 << endl; // XYZ is the Center point of circle
48
To_Dxf << x << endl; // X in UCS (User Coordinate
System)coordinates
49 To_Dxf << 20 << endl;
50
To_Dxf << y << endl; // Y in UCS (User Coordinate
System)coordinates
51 To_Dxf << 30 << endl;
52
To_Dxf << 0.0 << endl; // Z in UCS (User Coordinate
System)coordinates
53 To_Dxf << 40 << endl;
54 To_Dxf << radius << endl; // radius of circle
55

56 To_Dxf.close();
57

58 ,
Driverprogram to create such object.
int main()
Driver program:
01
int main()
02

03 , string str;
04
float rad, x = 0.0,y = 0.0;
05

06 CreateDxf Draw;
07

08
cout <<"Enter radius of circle" <<endl;
09
getline (cin,str);
10 stringstream(str) rad;
11

12 // This is 2D Drawing so no need to enter Z axis coordinate
13
cout <<"Enter X coordinate of circle" <<endl;
14
getline (cin,str);
15 stringstream(str) x;
16

17
cout <<"Enter Y coordinate of circle" <<endl;
18
getline (cin,str);
19 stringstream(str) y;
20

21 Draw.DxfBegin();
22 Draw.Circle (rad,x,y );
23 Draw.DxfEnd();
24



25
return 0;
26

27 ,
1.5 DESIGN ISSUES
One oI the weaknesses in current object-oriented technology is that there is little
awareness oI what constitutes good C design. ost books on C concentrate
on the 'grunge' details oI C syntax while at the same time they tend to neglect
important design issues such as robustness, portability and eIIiciency. 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-liIe problems. In short,
there is a gap between the analysis and implementation phases oI the soItware
liIecycle and this needs to be bridged. In order to bridge this gap, we can take a
number oI measures. First, since OO is relatively new, a lot oI people are under the
impression that they have to reinvent the wheel all over again. We must not Iorget
that OO is not an end in itselI but is just one set oI techniques which help us (iI
applied properly) produce better soItware. Design techniques which originated in
the works oI Parnas, Dijkstra and others should and can be applied to solving
problems using C. Furthermore, a number oI books have appeared which help
us solve real-liIe problems.
1.6 ADVANTAGES OF C++
The main advantages oI using C as opposed to C or AutoLisp lie in the support
it oIIers Ior writing classes. Once a class is written it can be used in many diIIerent
applications without change. In other words, we do not have to reinvent the wheel
by copying chunks oI code, modiIying 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 Iast becoming the de Iacto standard programming language. The compiler
runs on many diIIerent hardware platIorms and high-schools and universities are
training students in its use. In this sense we can expect a good supply oI well-
trained soItware engineers and programmers who are able to write C
applications Ior AutoCAD.
C deals with the Iollowing design, implementation and application issues:
O Design patterns and graphics: what, why, when and how
O Two-dimensional graphics applications
O Three-dimensional graphics applications
O Test case: &sing CADObject and OpenGL Ior CAD/CA (metal industry)
O Test case: Imaging
O Test case: 3d classes, curves and surIace modelling
10

O &sing numerical algorithms Ior computer graphics applications
O $oItware improvement under Windows NT and &NIX
1.7 MIGRATING TO C++
C oIIers many advantages to the soItware developer. These advantages come at
a price, however. Learning C is easy Ior the C programmer but applying it
correctly and eIIiciently requires a diIIerent way oI thinking about problem-solving
than how you would do it in AutoLisp. It takes about 2 years beIore you start to get
the hang oI it! In order to use C eIIectively, we propose the Iollowing migration
plan:
O Learn object-oriented concepts.
O Learn the syntax oI C (C uses the same syntax!).
O Learn C.
O Choose a non-critical pilot project to be developed in C.
O &se outside help in the early stages oI the project.
Furthermore, you need a 'champion' in the organisation who is convinced that
object-oriented technology is the way to go and who has the Iull support oI
management. The real beneIits oI using C will become clear aIter the Iirst
project has been Iinished when classes can be stored Ior 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 us, either we start moving to C or we will be leIt
with outdated and inIlexible products in two to three years time.
1.8 CONCLUSION
C is becoming the language oI choice Ior graphics applications. We shall see the
emergence oI graphics applications which consist oI pluggable components and
which can easily be customised to suit speciIic situations. In this way we hope to
see the industry maturing Irom one in which monolithic and inIlexible systems will
gradually be replaced by interoperable component technology.