Integration Protocols of D-Cubed

This page describes how D-Cubed’s component products, the 2D DCM, 3D DCM and
EHLC (collectively referred to as Components on the
remainder of this page) are integrated into an application. All of
D-Cubed’s Components have similar interfaces and a common
integration architecture, therefore the information on this page is relevant to
all three products.

D-Cubed’s Components are licensed by software development
organisations for integration into their own end-user products. Customers
include companies writing applications for commercial sale or in-house usage.
D-Cubed does not develop end-user products, therefore we have no conflicts of
interest with customers who license our technologies. The Components can
be integrated into existing, or newly developed, products.

Our Components make very few assumptions about the data
structures used in the host system. The definitions of the geometry are held in
the application and accessed by the Components through a
simple and compact interface. Therefore, use of the Components does
not require the application to re-define its geometric data structures. Hence,
they are compatible with any 2D or 3D application, based on a solid, surface or
wireframe geometric definition.

Great care has been taken in the design of the interfaces to ensure that
integration into an end-user application is an efficient process. Typical
integrations take one software development engineer between 3 and 9 months for
the DCM, and between 1 and 4 weeks for the EHLC. D-Cubed also provides  to undertake an integration into
an application. Our experienced consultants can use their wide range of
expertise in application development and Component integration
on many projects in the geometric modelling field.

All Components have been written specifically to be
integrated into any geometry based application. They are coded in C++ and
supplied with integral C++ and C interfaces. They are designed to be used with
any application written in C++, C, or any other high level language which
supports a C calling structure.

 

 

All Components are available on PCs running under Windows
95 and Windows NT, and workstations from DEC, Hewlett Packard, IBM, Silicon
Graphics and Sun, running under UNIX. The typical DCM object library size is
around 1 Mbyte on a PC and between 2 and 6 MBytes on different workstations.
The typical EHLC object library size is less than 1 MByte on all platforms.

We supply demonstration applications based on the 2D and 3D DCM in
executable form. These are useful for DCM evaluation, training and the
generation of ideas for applications.

Integration architecture

The following diagram illustrates the links between an application and
the Components:


 

Software structure for a typical Component integration

Fundamental to understanding how the Components integrate
with an application is an understanding of where the model data is located and
how it is accessed.

The long-lived model data is held within the application independently of
the Components. Hence, an integration does not require major
modifications to the application’s existing data structures. This is the reason
why the Components can be integrated easily into a wide
range of different applications.

Specific information concerning the model is held by the application. When
the Components are asked to perform their functions they
request from the application all the   data that is
necessary to determine a solution.

The Components share the application’s model data. If
Component is not being used, the application can operate
independently.

 

The storage of the application’s data to a model file is defined and
controlled by the application, again independently from the Components.
When the model is received by the application, the Component data
structures are reconstructed easily and quickly by calling the relevant Component interface
functions.

The Components and application communicate with each
other by means of pointers (addresses) to their data. An application adds data
to the Components by passing to them pointers to its own
data structures. A Component returns to the application a
pointer to the equivalent data in the Component.

The application passes Component pointers through
the Component interface in order to make enquiries
concerning the data in a Component. The Component passes
application pointers through the Frustum interface in order
to make enquiries concerning the data in the application. (The word ‘Frustum’,
outside of its D-Cubed usage, refers to the base of a
statue. In the context of our Components, the Frustum interface
lies at the base of a typical Component integration
diagram, hence its name).

Component pointers do not have to be recorded by the
application when it stores its models. They can be recreated easily when the
application next makes use of that Component.

Leave a Reply

Your email address will not be published. Required fields are marked *