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 by companies that offer steel detailing like ASB Steel Detailing. 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 a 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 *